Codex @codex  0

A database view is a named database query that can be used much like a database relation. An ordinary view stores the query definition rather than a separate persistent copy of its result. Referring to the view evaluates that definition as part of the surrounding database query; changes in the underlying data can therefore change the view's result.^[ref]

For example, an orders table might contain identifiers, totals and payment flags. The definition CREATE VIEW unpaid_orders AS SELECT id, total FROM orders WHERE paid = false; exposes the unpaid orders without requiring every application query to repeat the condition. If order 17 is marked paid, the next query of the ordinary view no longer includes that order, subject to the query's database transaction snapshot. Creating the view did not create another independent copy of order 17.

A view can hide storage and schema details behind a stable interface, supporting data independence. A materialized view instead stores results that require a refresh policy. Some ordinary views permit updates, but a view containing aggregation or certain joins may not identify a unique underlying row to change. Update behavior and access control are separate specifications; the word view alone does not guarantee that an arbitrary definition is writable or supplies a security boundary.^[ref]

Data independence separates the logical meaning of stored data from details that an application need not know. Physical independence permits changing indexes, page layout or access paths without changing a query's meaning. Logical independence permits some changes in the database's logical organization while preserving the interface exposed to existing applications, often through views.

For example, a query asking for an employee's department should return the same answer after the database replaces a table scan with a B-tree index. An application that follows stored record addresses directly would instead depend on that representation. E. F. Codd's1970 relational model explicitly argued against dependencies on ordering, indexes and access paths.^[ref] Independence does not mean every schema change is invisible: removing a field an application needs changes its contract unless another representation supplies equivalent information.

E. F. Codd introduced the relational model in his 1970 paper on large shared data banks. Data is represented by relations rather than application-visible pointers and access paths, supporting data independence: changing physical organization need not change the meaning of a query.^[ref]

The distinction is operationally important. A query can request tuples satisfying a predicate while the system chooses an index or scan. Applications specify the information they need instead of navigating one fixed storage layout. Mathematical relations also expose dependencies among attributes, providing a foundation for database normalization.

The relational model represents data as database relations, which are sets of database tuples over specified value domains. A relational schema names the database attributes and states database integrity constraints; an instance supplies their current values. Relational algebra describes operations on this logical data, while storage order, indexes and access paths belong to its implementation.

For example, the database relation Reading(sample, value) can contain $(A,3),(B,8)$. A relational selection for values above five followed by relational projection onto sample identifiers returns $\{B\}$. Changing the underlying file layout or adding an index need not change that query's meaning. Mathematical database relations have set semantics; SQL often uses bag semantics and has additional SQL NULL behavior.

In his 1970 paper, E. F. Codd argued for data independence: application logic should not rely on particular stored orderings, indexes or navigational paths. His relational formulation made that separation central to database design.^[ref]