Databases Reference
In-Depth Information
Following on from the previous point, an update explicitly requested by the user, together
with any compensatory actions carried out in connection with that update, must be regarded
in toto as a semantically atomic operation—a multiple assignment operation, to be precise.
Thus, no integrity checking must be done until that multiple assignment has been executed
in its entirety.
Note:
In general, as explained in Chapter 2, the individual assignments that
make up a multiple assignment can be thought of as being executed simultaneously. In the
case at hand, however, I'm going to assume for the purposes of this topic, where it makes
any difference, that the explicitly requested update is done first and the compensatory
actions are done second (maybe AFTER would be a better keyword than ON). Please note,
however, that this assumption is
not
logically required—it's just that it has the effect of
simplifying the formulation of the pertinent rules (usually).
A compensatory action, precisely because it is itself an update operation, might in general
cause certain further compensatory actions to be performed, and so on. In the case of a
DELETE on relvar S, for example, cascading the delete from S to LS will cause the
cascade delete rule from LS to S to be invoked in turn. Of course, this second cascade
won't have any effect in this particular example; however, it does raise the interesting
question of when cascading has to stop in general. I believe this issue deserves more study;
for the purposes of this topic, I'll adopt the pragmatic position that it stops when a
“fixpoint” is reached, meaning the database has reached a point when no further changes
occur.
7
Note:
If
U1
is the update requested by the user, and the compensatory action for
U1
causes another update request
U2
, which in turn causes another compensatory action to
be performed (etc.), then
U2
is “the explicitly requested update” as far as this latter
compensatory action is concerned—and so on, recursively. Of course, the complete set of
updates
U1
,
U2
, ... must still behave as a semantically atomic operation.
Eventually I want to examine the case in which LS and NLS are views and S is a base
relvar—but recall that, so far, all three relvars are base ones. Given that such is the case, I
now observe that compensatory actions such as the ones we've been discussing are
precisely what's needed to
control the redundancy
among such relvars. In other words, I
claim that compensatory actions would be needed anyway, in general, even if views as
such weren't supported at all.
Note:
Redundancy is said to be
controlled
if it does exist
(and the user is aware of it), but the task of “propagating updates” to ensure that it never
7
I apologize for my use of the slightly illogical term
fixpoint
here. It's not my coinage. More important, note the tacit
assumptions (a) that a fixpoint will indeed be reached, and moreover (b) that it's unique! To repeat, I believe this aspect requires
more study.
