impossible: we do not know what the student number is, what the identification of the instructor is, etc. SQL forbids users to update views based on more than one table (as STC is). Even if such updates would have an unambiguous effect on the base tabular variable, this rule rejects any such update. Only some views based on exactly one tabular variable can be updated. It is the responsibility of the database administrator to grant to the user the right to update a view only if that view can be updated. If a view can be updated, then its behavior is somewhat different from the base tabular variable on which the view is built. An update made to a view may cause one or several tuples to vanish from the view, whenever we retrieve the tuples of the view. Example 5.23.3 Consider the view uppergr defined by:
create view UPPERGR as select * from GRADES where grade > 75;
If we wish to examine the tuples that satisfy the definition of the view we use the construction:
select * from UPPERGR;
that returns the result:
STNO EMPNO CNO SEM YEAR GRADE ---------- ----------- ----- ------ ---------- ---------2661 019 cs110 FALL 1999 80 3566 019 cs110 FALL 1999 95 5544 019 cs110 FALL 1999 100 3566 019 cs240 SPRING 2000 100 2415 019 cs240 SPRING 2000 100 5571 234 cs410 SPRING 2000 80 1011 019 cs210 FALL 2000 90 3566 019 cs210 FALL 2000 90 5571 019 cs210 SPRING 2001 85 1011 056 cs240 SPRING 2001 90 4022 056 cs240 SPRING 2001 80 2661 234 cs310 SPRING 2001 100
The update construction:
update UPPERGR set grade = 70 where stno = ’2661’ and empno = ’019’ and cno = ’cs110’ and sem = ’FALL’ and year = 1999;
makes the first row disappear, since it no longer satisfies the definition of the view. Indeed, if we use again the same query on UPPERGR, we obtain:
STNO EMPNO CNO SEM YEAR GRADE ---------- ----------- ----- ------ ---------- ---------3566 019 cs110 FALL 1999 95 5544 019 cs110 FALL 1999 100