Databases Reference
In-Depth Information
Finally, let me state for the record that the foregoing rules, as they apply to updates on
relvar SSP in particular, are essentially identical to the rules I gave for updating joins in Chapters
6 and 7. For that reason, I won't bother to go into details on what happens if (a) the user sees
just that relvar SSP or (b) that relvar SSP is a view and S and SP are base relvars. Suffice it to
say that, once again, everything works satisfactorily.
EXAMPLE 2: INFORMATION HIDING
Now let me revise the foregoing example and suppose that—as in our original suppliers-and-
parts database, in fact—it's not the case that every supplier has to supply at least one part. Then
information equivalence is lost; to be specific, the design consisting of relvars S and SP in
combination is capable of representing suppliers (such as supplier S5 in our usual set of sample
values for the suppliers-and-parts database) who currently supply no parts at all, while the design
consisting of just the join SSP obviously can't represent such information. (Equivalently, it's no
longer guaranteed that relvar S is equal to the projection of SSP, the join of S and SP, on SNO
and CITY. On the other hand, it's at least still true that relvar SP is equal to the projection of
that join on SNO, PNO, and QTY.)
Be that as it may, the following constraints among others apply to this revised form of the
database:
The usual key constraints all hold—{SNO} is a key for S and {SNO,PNO} is a key for
each of SP and SSP.
At any given time, the current value of SSP is equal to the join of the current values of S
and SP.
The FD {SNO} → {CITY} holds in SSP (also in S, of course).
A concrete example of a database value satisfying the foregoing conditions can be obtained
by extending Fig. 8.1 to reinstate the usual tuple for supplier S5 (see Fig. 8.2 overleaf, and
observe in particular that the relations shown as the current values of relvar SP and SSP in that
figure are the same as they were in Fig. 8.1).
