The IMPRESS DDT: a database design toolbox based on a formal specification language

The Database Design Tool prototype is being developed in the IMPRESS project (Esprit project 6355). The IMPRESS project started in May 1992 and aims at creating a low-level storage manager tailored for multimedia applications, together with a library of efficient operators, a programming environment, high-level design tools and methodology. The DDT is part of this last effort.\ud \ud The project focuses on the field of Technical Information Systems, where there is a need for tools supporting modeling of complex objects. Designers in this field usually use incremental design or step by step prototyping, because this seems to be best suited for users coping with complexity and uncertainty about their own needs or requirements. The IMPRESS DDT aims at supporting the database design part of this process

Automatic Verification of Transactions on an Object-Oriented Database

In the context of the object-oriented data model, a compiletime approach is given that provides for a significant reduction of the amount of run-time transaction overhead due to integrity constraint checking. The higher-order logic Isabelle theorem prover is used to automatically prove which constraints might, or might not be violated by a given transaction in a manner analogous to the one used by Sheard and Stemple (1989) for the relational data model. A prototype transaction verification tool has been implemented, which automates the semantic mappings and generates proof goals for Isabelle. Test results are discussed to illustrate the effectiveness of our approach

Towards Conceptual and Logical Modelling of NoSQL Databases

NoSQL databases support the ability to handle large volumes of data in the absence of an explicit data schema. On the other hand, schema information is sometimes essential for applications during data retrieval. Consequently, there are approaches to schema construction in, e.g., the JSON DB and graph DB communities. The difference between a conceptual and database schema is often vague in this case. We use functional constructs – typed attributes for a conceptual view of DB that provide a sufficiently structured approach for expressing semantics of document and graph data. Attribute names are natural language expressions. Such typed functional data objects can be manipulated by terms of a typed λ-calculus, providing powerful nonprocedural query features for considered data structures. The calculus is extendible. Logical, arithmetic, and aggregation functions can be included there. Conceptual and database modelling merge in this case

Functionally Specified Distributed Transactions in Co-operative Scenarios

Addresses the problem of specifying co-operative, distributed transactions in a manner that can be subject to verification and testing. Our approach combines the process-algebraic language LOTOS and the object-oriented database modelling language TM to obtain a clear and formal protocol for distributed database transactions meant to describe co-operation scenarios. We argue that a separation of concerns, namely the interaction of database applications on the one hand and data modelling on the other, results in a practical, modular approach that is formally well-founded. An advantage of this is that we may vary over transaction models to support the language combinatio

Object-Relational Impedance Mismatch: A Framework Based Approach

The term impedance mismatch was first used in 1984 to label problems that arise when a program uses a relational database for storage. For example, when transferring data from a relational database into a program any relational data structure is lost because a program operates at the row level. Consequently that data structure must somehow be reproduced when data is returned to a database. There are many such mismatches that cost time and effort to address. As new programming and database languages are introduced other kinds of impedance mismatch are anticipated. Traditional approaches are concerned with pragmatic solutions to specific problems of implementation. They do not address the underlying cause and offer little rationale for the claim to a "solution". The motivation for this dissertation is to understand the cause of these mismatches so it is then possible to address each of them in an appropriate way. Problem themes are introduced as a way to make sense of impedance mismatch. Such problems are not independent. Relationships between problem themes demonstrate the complex nature of impedance mismatch and they are used to identify three problems of particular significance. A structure to existing characterisations of impedance mismatch is identified and developed in order to organise the characterisations in a meaningful and useful way. This structure, based on four levels of abstraction, forms the foundation for a new framework. The framework recognises a separation of concerns between a program and a database across levels of abstraction. At each level is observed a particular kind of impedance mismatch. Through a dialogue about a correspondence at each level it is possible to understand and address each kind of mismatch in a structured and consistent way. A technique based on equivalence is introduced in support of a dialogue. The validity of the framework is demonstrated by identifying the cause of some significant mismatches. Across all the levels of the framework are explored both the cause of each mismatch and the effect of a solution. A four-stage process is described in support of an exploration and to inform others in the use of the framework. An option for change is linked to a conceptual problem not one of implementation and the fidelity and integrity of an existing solution is improved in a way that can be generalised for other solutions. New insights are also provided into the consequences of one solution. Understanding cause and effect in this level of detail is not available using an alternative framework described in the literature. However despite the improved understanding of an impedance mismatch and the consequences of a solution there is a limit to what can be achieved using the framework