Databases Reference
In-Depth Information
CONCLUDING REMARKS
There are two final remarks I want to make. First, I haven't said quite all I want to say about
updating projection views as such—I'll come back to the topic briefly in Chapter 7, in the
section “Projection Views Revisited.” Second, I'd like to clarify something I ought perhaps to
have clarified much earlier ... In Chapter 1, I claimed that all views are updatable; in this chapter,
by contrast, I've said that certain updates on certain views don't work after all. As an extreme
case in point, view TC—defined as the projection of relvar S on STATUS and CITY, in the case
where the functional dependency {CITY} → {STATUS} doesn't hold—can't sensibly be
updated at all. So am I talking out of both sides of my mouth here? What exactly is going on?
Well, I did also say in Chapter 1 that I would elaborate later on “this very strong claim”
(the claim, that is, that all views are updatable). The point is this: It's
not
that certain views are
intrinsically nonupdatable. Rather, it's that certain updates on certain views fail because, if
they—the updates, that is—were accepted, they would cause some integrity constraint to be
violated (and no compensatory actions are in place to prevent such violations from occurring.)
Note that this state of affairs exactly parallels the situation with base relvars: Certain updates on
certain base relvars fail too, not because the relvar in question is intrinsically nonupdatable, but
because some integrity constraint would otherwise be violated. Inserting a tuple for a
nonexistent supplier into the shipments relvar SP is a case in point.
