Although views are a useful tool for queries, they present serious problems when undergoing updates, insertions, or deletions.
Missing attribute
Example
- Add a new tuple to the view
faculty
defined earlier
This insertion must be represented by the insertion into the instructor
relation, which must have a salary
attribute.
There are two reasonable approaches to dealing with this insertion.
- Reject the insertion.
- Insert a tuple with the value of the non-existing attribute set to
NULL
.- Will be rejected by the DBMS if that attribute has
NOT NULL
constraint.
- Will be rejected by the DBMS if that attribute has
Ambiguity
Another problem with modification of the database through views occurs when updates cannot be translated uniquely.
Examples
- Which department, if multiple departments exist in the
Taylor
building, should the value be inserted to? - What if there is no department in the
Taylor
building?
There is no way to update the relations instructor
and department
by using NULL
values to get the desired update on the view instructor_info
.
Consider another problematic scenario.
- Should the insertion be allowed?
View updates in SQL
Because of problems such as above, modifications are generally not permitted on view relations, except in limited cases.
Most SQL implementations allow updates only on simple views:
-
The
FROM
clause has only one database relation. -
The
SELECT
clause contains only attributes of the relation, and does not have any expression, aggregates, orDISTINCT
specification. -
Any attribute not listed in the
SELECT
clause can be set toNULL
. -
The query does not have a
GROUP BY
orHAVING
clause.