Home > Articles > Data > SQL

  • Print
  • + Share This
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:

SQL
create view accounts (title, advance, gross_sales)
as
select title_id, advance, price * ytd_sales
from titles
where price > 15
 and advance > 5000

The rows visible through accounts are these:

SQL
select * 
from accounts
title  advance      gross_sales
====== ============ ===========
PC8888      8000.00   163800.00
TC7777      8000.00   122809.05
PC1035      7000.00   377101.00
PS2106      6000.00     1887.00
TC3218      7000.00    15356.25
PS1372      7000.00    15596.25
[6 rows]

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.

SQL
update accounts
set title = 'PC0000' 
where title = 'PC8888' 

select *
from accounts
title    advance gross_sales
====== ============ ===========
PC0000      8000.00   163800.00
TC7777      8000.00   122809.05
PC1035      7000.00   377101.00
PS2106      6000.00     1887.00
TC3218      7000.00    15356.25
PS1372      7000.00    15596.25
[6 rows]

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
create view categories (Category, Average_Price)
as 
select type, avg(price)
from titles
group by type

Here's what the view data looks like:

SQL
select * 
from categories
Category     Average_Price
============ =============
popular_comp         41.48
business             23.73
psychology           25.70
mod_cook             21.49
trad_cook            30.96
(NULL)              (NULL)
[6 rows]

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:

Adaptive Server Anywhere
update oaklanders
set FirstName = 'Sylvia'
where FirstName = 'Stearns'
select *
from oaklanders
FirstName LastName       Book
========= ============== ============================================
Marjorie  Green          The Busy Executive's Database Guide
Sylvia    MacFeather     Cooking with Computers: Surreptitious 
                         Balance Sheets
Marjorie  Green          You Can Combat Computer Stress!
Dick      Straight       Straight Talk About Computers
Livia     Karsen         Computer Phobic and Non-Phobic Individuals: 
                         Behavior Variations
Sylvia    MacFeather     Computer Phobic and Non-Phobic Individuals: 
                         Behavior Variations
[6 rows]
Oracle
SQL> update oaklanders
 2 set FirstName = 'Sylvia'
 3 where FirstName = 'Stearns';
ERROR at line 3:
ORA-01779: cannot modify a column which maps to a non key-preserved table

Reverse the UPDATE to restore MacFeather's first name.

  • + Share This
  • 🔖 Save To Your Account