- With a View Toward Flexibility
- View Commands
- Advantages of Views
- How Views Work
- Data Modification Through Views
- Creating Copies of Data
- Summary
This chapter is from the book
This chapter is from the book
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.