Gradually, principles and mechanisms were developed that insulated database users from the details of the physical implementation. In the late 1960s, the first major step in this direction was the development of three-level architecture.
development and study of abstract, human-oriented models and interfaces for specifying the structure of stored data and for manipulating it.
The separation of the logical and physical levels of a database system is usually called the data independence principle. This is arguably the most important distinction between file systems and database systems. The second separation in the architecture, between external and logical levels, is also important. It permits different perspectives, or views, on the database that are tailored to specific needs. Views hide irrelevant information and restructure data that is retained.
A major issue connected with both separations in the architecture is the trade-off between human convenience and reasonable performance.
Indeed, the use of the relational model became widespread only when query optimization techniques made it feasible. More generally, as the field of physical database optimization has matured, logical models have become increasingly remote from physical storage.
a limited but extremely natural and commonly arising class of queries called conjunctive queries.
query composition and its relationship to database views. A main result here is that the rule-based conjunctive queries with equality are closed under composition.
Consider a database R, …, a query q can be used to define a
relation with new relation name S1, which can be used in subsequent
queries as any ordinary relation from R.
… composition of the query with the view definition … can be rewritten
views are specified as queries (or query programs). These may be materialized (i.e., a physical copy of the view is stored and maintained) or virtual (i.e., relevant information about the view is computed as needed). In the latter case, queries against the view generate composed queries against the underlying database.
Other data models have been proposed and implemented besides the relational model. The most prominent ones preceding the relational model are the hierarchical and network models
updating views: the interplay between views and updates is intricate … given IB, Iv, and update v on Iv, find an update u so that … the fundamental problem is the potential for ambiguity.
the correct translation of a view update easily depend on the semantics associated with the view as well as the notion of minimal change.
updating a database is essentially imperative programming. However, the persistence, size, and long life cycle of a database lead to perspectives somewhat different from those found in programming languages.
Query languages are not naturally suited to speak explicitly about change. In contrast, update languages use as building blocks simple statements expressing change, such as insertions, deletions, and modifications of tuples in the database.
One possibility is to build another procedural language based on tuple
insertions, deletions, and modifications, which includes relation
variables and an iterative construct. Another, … , datalog¬¬
In a sense, an update to a view is an incompletely specified update whose completion must be determined or selected.
Active databases and techniques have been shown to be useful for constraint main- tenance [Mor83, CW90, CTF88], incremental update of materialized views [CW91], and database security [SJGP90]; and they hold the promise of providing a new family of solutions to the view and derived data update problem [CHM94] (local post) and issues in database in- teroperability [CW93, Cha94, Wie92]. Another functionality associated with some active databases is query rewriting [SJGP90], whereby a query q might be transformed into a related query q′ before being executed.