Databases Reference
In-Depth Information
by “view definitions” I really mean the definitions of the
mappings
from the underlying
base relvar(s) to the views in question—in other words, the pertinent “view defining
expressions”).
Note:
Observe in particular that, e.g., changing the supplier number for some
supplier in S, say from S1 to S9, will cascade to either LS or NLS, whichever is applicable.
By contrast, recall from the section “Suppliers and Shipments” that such a cascade won't
happen with S and SP. But that's because the situation with S and SP is different: With S,
LS, and NLS, we're talking about what from the user's point of view is just an example of
controlled redundancy; with S and SP, such is not the case. (In fact, to pursue the point a
moment longer, the whole point about the view updating scheme I'm proposing is to make
the situation look to the user as if it
were
just a matter of controlled redundancy—
assuming, that is, that the user in question sees both the views as such and the relvars in
terms of which those views are defined. More particularly, telling the user about the
compensatory actions means we don't have to tell the user which relvars if any are base
ones and which ones if any are views.)
3.
The compensatory actions from LS and NLS to S—these are the ones that are generally
thought of as the view updating rules as such—also happen automatically, again precisely
because LS and NLS are views of S. That is, updates to LS or NLS are “really” updates to
the underlying relvar S, and so are automatically visible in S, as well as in LS or NLS or
both.
4.
Now consider a user who sees only views LS and NLS. Then I hope you can see that
the
user in question can behave in all respects exactly as if those views were base relvars
—in
fact, exactly as described in the case where they actually were base relvars, in the section
“The Motivating Example Continued,” earlier in this chapter. Which is, of course, the
object of the exercise.
Note in particular that, e.g., an attempt to change the supplier city for some supplier
in LS won't cause the tuple in question to “migrate” from LS to NLS—instead, it will fail
on a violation of
The Golden
Rule
. By contrast, such migration would probably have
been expected, and would probably have occurred, given traditional ad hoc approaches to
view updating.
13
5.
By contrast, a user who sees, say, only view NLS will clearly be limited in the operations
he or she is allowed to perform—again just like a user who sees only base relvar NLS,
13
See, e.g.,
Using the New DB2: IBM's Object-Relational Database System
, by Don Chamberlin (Morgan Kaufmann, 1996).
