Databases Reference
In-Depth Information
To all of the above, let me add that the problems are compounded by the fact that
no
possible update
on VPL1 has the same effect on the underlying relvars—on relvar PK in
particular—as the foregoing delete or insert on VPL2 does.
Clearly, then, there's something wrong with the “semantics not syntax principle.” Before I
try to pin down what it might be, however, I want to consider another related issue.
“SEMANTIC TRANSFORMATIONS”
In
SQL and Relational Theory
, I briefly describe an implementation technique called
semantic
optimization
. Here's a simple example, repeated from that earlier topic. Consider the expression
(SP JOIN S){PNO}. Now, the join here is based on the correspondence between a foreign key in
a referencing relvar, SP, and the pertinent target key in the referenced relvar, S. Thus, every SP
tuple does join to some S tuple, and every SP tuple therefore does contribute a part number to the
projection operation that produces the overall result. So there's no need to do the join!—the
expression can be reduced for evaluation purposes to just SP{PNO}. Note carefully, however,
that this transformation is valid only because of the semantics of the situation; with join in
general, each operand will include some tuples that have no counterpart in the other and so don't
contribute to the overall result, and transformations such as the one just shown therefore won't
be valid. But in the case at hand, every SP tuple necessarily does have a counterpart in S,
because a constraint—actually a foreign key constraint—is in effect that says that every
shipment must have a supplier, and so the transformation is valid after all.
Terminology:
A
transformation that's valid only because a certain constraint is in effect is called a semantic
transformation, and the resulting optimization is called a semantic optimization.
Given the foregoing, now consider the following example (“Example 3”). Suppose for
simplicity that relvar S has just one attribute, SNO, and relvar SP has just two attributes, SNO
and PNO (so both relvars are in fact “all key”). Fig. 14.2 shows some sample values.
S SP
┌─────┐ ┌─────┬─────┐
│ SNO │ │ SNO │ PNO │
├═════┤ ├═════┼═════┤
│ S1 │ │ S1 │ P1 │
│ S2 │ │ S1 │ P2 │
│ S5 │ │ S1 │ P3 │
└─────┘ │ S2 │ P2 │
└─────┴─────┘
Fig. 14.2: Relvars S and SP—sample values
Now consider two views, VSP1 and VSP2, whose defining expressions
exp1
and
exp2
are
as indicated here:
