Databases Reference
In-Depth Information
UPDATE ST WHERE SNO = 'S1' : { SNO := 'S9' } ;
Well, it's easy to see here that this UPDATE unfortunately fails (to be specific, it fails on a
Golden Rule
violation). As in the case of the suppliers and shipments example in the previous
chapter, in fact, it seems to me that here there's no alternative to writing out the necessary
multiple assignment explicitly, thus:
UPDATE ST WHERE SNO = 'S1' : { SNO := 'S9' } ,
UPDATE SC WHERE SNO = 'S1' : { SNO := 'S9' } ;
This “double UPDATE” succeeds, as you can easily confirm.
So: Despite this latter minor annoyance, it's still the case that (a) the two designs, S by
itself and the combination of ST and SC, are information equivalent, and hence that (b) for every
update on one, there's a logically equivalent update on the other that has the same overall effect.
So far, so good.
EXAMPLE 1 CONTINUED: THE PROJECTION RELVARS
Let's continue to assume that relvars S, ST, and SC are all base relvars (still no views yet). Now
consider a user who sees just the projection relvars ST and SC. That user:
1.
Knows the corresponding predicates:
ST:
Supplier SNO is under contract and has status STATUS.
SC:
Supplier SNO is under contract and is located in city CITY.
Is aware of all pertinent type information,
5
is aware of the fact that {SNO} is a key for
each of these relvars, and is aware of the following constraint:
CONSTRAINT ... ST { SNO } = SC { SNO } ;
2.
(This is the only constraint from the previous section that makes no mention of relvar S.)
5
I won't bother to keep saying this—you can just take it as true, wherever applicable, for all subsequent examples in the topic.
