The problem of translating view updates to database updates is considered. Both databases and views are modeled as data abstractions. A data abstraction consists of a set of states and of a set of primitive update operators representing state transition functions. It is shown how complex update programs can be built from primitive update operators and how view update programs are translated into database update programs. Special attention is paid to a class of views that we call “consistent.” Loosely speaking, a consistent view is a view with the following property: If the effect of a view update program on a view state is determined, then the effect of the corresponding database update is unambiguously determined. Thus, in order to know how to translate a given view update into a database update, it is sufficient to be aware of a functional specification of such a program. We show that consistent views have a number of interesting properties with respect to the concurrency of (high-level) update transactions. Moreover we show that the class of consistent views includes as a subset the class of views that translate updates under maintenance of a constant complement. However, we show that there exist consistent views that do not translate under constant complement. The results of Bancilhon and Spyratos [6] are generalized in order to capture the update semantics of the entire class of consistent views. In particular we show that the class of consistent views is obtained if we relax the requirement of a constant complement by allowing the complement to decrease according to a suitable partial order.

Properties and update semantics of consistent views

A database description framework is introduced that accounts for static constraints, that is, constraints on what data can be stored,as well as transition constraints, that is, constraints on how data can be updated. Two levels of specification are considered. At the first level of specification, a database description Dl does not indicate how the database will be updated. Transition constraints are then specified with the help of a variant of Temporal Logic. By contrast, at the second level of specification, a database description D2 includes a set of built-in update operations, which are described by their properties. The advantages accrued from this approach are twofold: first-level specifications give a stable description of constraints, while second-level specifications suggest a strategy to enforce constraints.

/pdf/a-temporal-framework-for-database-specifications-3uslx4oncg.pdf

A Temporal Framework for Database Specifications

As the complexity of engineering design projects increases and the objectives for their performance become more demanding, there is growing interest in integrated databases that support a broad range of applications and various forms of automated entry. This paper is a tutorial on the design and implementation of integrated design databases. It addresses a variety of functional issues, including subsystem integration, maintaining consistency among concurrent users and various system architectures.

/pdf/database-facilities-for-engineering-design-3og4rqy242.pdf

Database facilities for engineering design

Data quality in information systems

A new generation computer is expected to be the knowledge processing system of the future. However, many aspects are yet unknown regarding this technology, and a number of fundamental concepts, directly concerning knowledge processing system design need investigation, such as knowledge, data, inference, communication, information management, learning, and human interface.

Multi-layer logic—A predicate logic including data structure as knowledge representation language

Data abstractions were originally conceived as a specification tool in programming. They also appear to be useful for exploring and explaining the capabilities and shortcomings of the data definition and manipulation facilities of present-day database systems. Moreover they may lead to new approaches to the design of these facilities. In the first section the paper introduces an axiomatic method for specifying data abstractions and, on that basis, gives precise meaning to familiar notions such as data model, data type, and database schema. In a second step the various possibilities for specifying data types within a given data model are examined and illustrated. It is shown that data types prescribe the individual operations that are allowed within a database. Finally, some additions to the method are discussed which permit the formulation of interrelationships between arbitrary operations.

Wolfgang H. Wohlleber

Papers

Data abstractions for database systems