Databases Reference
In-Depth Information
Well, as I've written elsewhere (see, e.g.,
The Relational Database Dictionary, Extended
Edition
, Apress, 2008):
By definition, the operators projection, join, and so on apply to relation values specifically. In particular, of
course, they apply to the values that happen to be the current values of relvars. It thus clearly makes sense to
talk about, e.g., the projection of relvar S on attributes {CITY,STATUS}, meaning the relation that results
from taking the projection on those attributes of the relation that's the current value of that relvar S. In some
contexts, however (normalization, for example), it turns out to be convenient to use expressions like “the
projection of relvar S on attributes {CITY,STATUS}” in a slightly different sense. To be specific, we might
say, loosely but very conveniently, that some
relvar
, CT say, is the projection of relvar S on attributes
{CITY,STATUS}—meaning, more precisely, that the value of relvar CT at all times is the projection on
those attributes of the value of relvar S at the time in question. In a sense, therefore, we can talk in terms of
projections of relvars per se, rather than just in terms of projections of current values of relvars. Analogous
remarks apply to all of the relational operations.
In other words, we do often talk in terms of (e.g.) restricting relvars as such; in particular, we do
so in the context at hand. Such a manner of speaking is somewhat inappropriate—not to say
sloppy—but it is at least succinct.
My second point is this. Among other things, I've considered the case in which S is a base
relvar and LS and NLS are (restriction) views of that base relvar. For completeness, I ought
really also to consider the inverse situation, in which LS and NLS are base relvars and S is a
view of those relvars. But then S would be a union view, and so I'll defer discussion of this case
to Chapter 10, where I'll be discussing union views in general. For now, let me just note the
point that, in a sense, updating through union and updating through restriction are two sides of
the same coin.
I'd like to close by reminding you of the following remarks (slightly paraphrased here)
from the end of Chapter 1. As I said in that chapter, the conclusions from the motivating
example are all rather obvious;
16
however, what I'm suggesting is that thinking of views as base
relvars “living alongside” the relvars in terms of which they're defined (as it were) is a fruitful
way to think about the view updating problem in general—indeed, not just a fruitful way, but a
way that I believe is logically correct. The basic idea is thus as follows: First, the view defining
expressions imply certain constraints; second, such constraints in turn imply certain
compensatory actions. To say it one more time, it's not my intent that those actions should have
to be specified explicitly by the DBA.
16
Obvious they might be, but (as we've seen) they do differ in certain respects from what might have been expected, and might
in fact have occurred, given traditional approaches to view updating. For example, in SQL, an attempt to change the supplier city
for some supplier in view LS will succeed (and will effectively cause the supplier in question to migrate to view NLS), unless
view LS was explicitly defined WITH CHECK OPTION.
