Content deleted Content added
m Undid revision 799473945 by 223.255.225.67 (talk) |
Rescuing 1 sources and tagging 0 as dead.) #IABot (v2.0.9.5 |
||
| (47 intermediate revisions by 38 users not shown) | |||
Line 1:
{{Short description|Database stored query result set}}
In [[database theory]], a '''view''' is the [[result set]] of a ''stored'' [[Query language|query]] on the [[data]], which the [[database]] users can query just as they would in a persistent database collection object. This pre-established query command is kept in the database dictionary. Unlike ordinary ''base tables'' in a [[relational database]], a view does not form part of the [[database design|physical schema]]: as a result set, it is a virtual table computed or collated dynamically from data in the database when access to that view is requested. Changes applied to the data in a relevant ''underlying table'' are reflected in the data shown in subsequent invocations of the view. In some [[NoSQL]] databases, views are the only way to query data.▼
{{More citations needed|date=December 2023}}
▲In a [[database
Views can provide advantages over tables:
* Views can represent a subset of the data contained in a table. Consequently, a view can limit the degree of exposure of the underlying tables to the outer world: a given user may have permission to query the view, while denied access to the rest of the base table.<ref name="SQL-reference-groff-weinberg">{{cite book
| last1 = Groff
* Views can [[Join (SQL)|join]] and simplify multiple tables into a single virtual table.▼
| first1 = James R.
| last2 = Weinberg | first2 = Paul N.
| date = 1999
| title = SQL: The Complete Reference
| url = http://englishonlineclub.com/pdf/SQL%20-%20The%20Complete%20Reference%20[EnglishOnlineClub.com].pdf
| ___location = <!-- not stated -->
| publisher = Osborne/McGraw-Hill
| pages = 291–292
| isbn = 0072118458
}}</ref>
▲* Views can [[Join (SQL)|join]] and simplify multiple tables into a single virtual table.<ref name="SQL-reference-groff-weinberg" />
* Views can act as aggregated tables, where the [[database engine]] aggregates data ([[summation|sum]], [[average]], etc.) and presents the calculated results as part of the data.
* Views can hide the complexity of data. For example, a view could appear as
* Views take very little space to store; the database contains only the definition of a view, not a copy of all the data that it presents.
* Views structure data in a way that classes of users find natural and intuitive.<ref name="SQL-reference-groff-weinberg"/>
Just as a [[function (computing)|function]] (in programming) can provide [[Abstraction (computer science)|abstraction]], so can a database view. In another parallel with functions, database users can manipulate nested views, thus one view can aggregate data from other views. Without the use of views, the [[Database normalization|normalization]] of databases above [[second normal form]] would become much more difficult. Views can make it easier to create lossless join decomposition.
Line 14 ⟶ 26:
== Read-only vs. updatable views ==
Some systems support the definition of INSTEAD OF [[Database trigger|triggers]] on views. This technique allows the definition of other logic for execution in place of an insert, update, or delete operation on the views. Thus database systems can implement data modifications based on read-only views. However, an INSTEAD OF trigger does not change the read-only or updatable property of the view itself.
==Materialized views==
{{further|Materialized view}}
Various [[
Materialized views were introduced by [[Oracle Database]], while [[IBM == Equivalence ==
Line 27 ⟶ 41:
A view is equivalent to its source query. When queries are run against views, the query is modified. For example, if there exists a view named accounts_view with the content as follows:
<
-- accounts_view:
-------------
SELECT name,
Line 39 ⟶ 53:
JOIN accounts_table a
ON a.customer_id = c.customer_id
</syntaxhighlight>
then the application could run a simple query such as:
<
-- Simple query
------------
SELECT name,
balance
FROM accounts_view
</syntaxhighlight>
The RDBMS then takes the simple query, replaces the equivalent view, then sends the following to the [[query optimizer]]:
<
-- Preprocessed query:
------------------
SELECT name,
Line 66 ⟶ 80:
FROM table_customers c JOIN accounts_table a
ON a.customer_id = c.customer_id )
</syntaxhighlight>
The optimizer then removes unnecessary fields and complexity (for example
== See also ==
* [[Bidirectionalization]]
{{Databases}}
==References==
{{Reflist}}
{{DEFAULTSORT:View (Database)}}
| |||