This chapter is from the book

Data Modification Through Views

Changing data through views is a thorny issue. The general problem, as
we'll demonstrate here, is that commands to change data in a view sometimes
can't be understood by SQL in an unambiguous way. Such updates are
disallowed by every version of SQL. In other words, some views are inherently
and logically not updatable.

There are other views that are logically updatable but that many versions of
SQL rule nonupdatable. Disallowing a wide range of data modification statements
makes for more severe restrictions but simplifies the rules about what you can
and cannot do. Other SQL implementations go to great lengths to let you make as
many kinds of changes as possible, in spite of the complications inevitably
introduced into rules about data modification.

The kinds of data modification statements that are allowed vary a great deal
from SQL to SQL, so treat the rules we give here as guidelines and check your
system's reference manuals for details.

The Rules According to ANSI

The ANSI standard declares that views are read-only (not modifiable) if the
CREATE VIEW statement contains any of the following:

DISTINCT in the select list

Expressions (computed columns, aggregates, functions, and so on) in the
select list

References to more than one tablein the FROM clause or in a
subquery or in a UNION clause

References to a view that is itself not updatable, either in the FROM
clause or in a subquery

A GROUP BY or HAVING clause

Some dialects of SQL are less restrictive than the ANSI standard; others may
be more restrictive. You can consult your reference manual, or you can
experiment. When you try to modify data through a view, SQL checks to make sure
that no restrictions are violated. If it detects a violation, it rejects the
data modification statement and informs you of an error.

The best way to understand the rationale for these restrictions is to look at
some examples of nonupdatable views.

Computed Columns

Let's start with the restriction that prohibits updating views with
columns derived from computed columns. The gross_sales column in the view
accounts is computed from the price and ytd_sales columns of the titles
table:

Think about what it would mean to update the gross_sales column. How could
the system deduce the underlying values for price or year-to-date sales from any
value you might enter? There's no way for the system to know, and
there's no way for you to tell it. Thus updates on this view are illegal.

SQL Variants

Theory aside, you may find you can update a column that is not computed in a
view that contains computed expressions, as long as it has a direct relationship
to an underlying column and no other rules are broken.

Use an UPDATE to change PC0000 back to PC8888, if this statement succeeded on
your system.

Aggregates

Now let's turn to a view with a column derived from an
aggregatethat is, a view whose definition includes a GROUP BY clause. Such
views (and any view derived from them) are called grouped views. A
variety of restrictions may apply to grouped views, depending on the particular
version of SQL you're using. Here's the view definition statement:

SQL

It would make no sense to insert rows into the view categories. To what group
of underlying rows would an inserted row belong? Updates on the Average_Price
column cannot be allowed either because there is no way to know from any value
you might enter there how the underlying prices should be changed.
Theoretically, updates to the Category column and deletions could be allowed,
but they are not supported by many versions of SQL.

Multiple Underlying Objects

Another restriction on view modifications disallows updates and insertions
through a view if the statement would modify columns that are derived from more
than one object. This is because updates and insertions on more than one object
in a single statement are never allowed.

Some systems allow you to modify the view if you change columns from only one
of the underlying tables. For example, if you want to change an author's
name through the oaklanders view (based on authors, titleauthors, and titles),
some systems let you do it because the name is stored in one table only. You
couldn't write an UPDATE statement that changed one column from titles and
one column from authors.

SQL Variants

Note how Adaptive Server Anywhere and Oracle handle the same query, updating
a noncomputed column through a multitable view: