Databases Reference
In-Depth Information
1.
The constraints specified by the various CONSTRAINT statements in the section before
last will all be enforced automatically, precisely because ST and SC are views of S.
2.
The compensatory actions from S to ST and SC will also happen automatically, again
because ST and SC are views of S; that is, updates to S will automatically be reflected
appropriately in ST or SC or both.
3.
The compensatory actions from ST and SC to S—these are the ones that are generally
thought of as the view updating rules as such—will also happen automatically, again
precisely because ST and SC are views of S. That is, updates to ST or SC are “really”
updates to the underlying relvar S, and so will automatically be visible in S, as well as in
ST or SC or both.
4.
A user who sees only views ST and SC can behave in all respects exactly as if those views
were base relvars—in fact, exactly as described in the previous section for the case in
which they actually were base relvars. To spell out the details, that user knows that
(a) DELETEs on either relvar cascade to the other; (b) INSERTs and key UPDATEs must
be “double updates”; (c) other UPDATEs behave normally; and (d) explicit assignments
must be logically equivalent to some sensible combination of the foregoing.
5.
By contrast, a user who sees, say, only view ST will clearly be limited in the operations he
or she is allowed to perform—again just like a user who sees only base relvar ST, when all
three relvars are base ones (again as described in the previous section). To be specific,
such a user won't be allowed to insert tuples into that relvar or to update supplier numbers
within that relvar (and possibly not to change STATUS values, either).
EXAMPLE 2: ANOTHER NONLOSS DECOMPOSITION
Now I want to consider a revised version—in a way, a generalized version—of Example 1.
Again I'll start with relvar S. This time, however, I'll add a constraint to the effect that the
functional dependency
(FD)
{ CITY }
→
{ STATUS }
