Databases Reference
In-Depth Information
relational assignment alone.
5
Partly for pedagogic reasons, I prefer to state them in terms
of explicit INSERTs and DELETEs instead. But I must emphasize that my primary
concern in this topic is always just to get the formulations logically correct; I'm not very
interested at this stage in trying to find the simplest or most efficient formulations.
To elaborate on the previous point: I hope it's obvious in general that, as noted in Chapter
2, my overall goal is always to get the theory right first and not to worry about
implementation matters (not yet, at any rate). Doubtless there'll be issues of optimization
in any concrete implementation.
Note:
I'd like to mention one such issue here, however:
Whenever the phrase DELETE
d
FROM
R
appears, that
d
can safely be replaced by
d
INTERSECT
R
; likewise, whenever the phrase INSERT
i
INTO
R
appears, that
i
can safely
be replaced by
i
MINUS
R
. For simplicity, therefore, I'll assume throughout what follows,
without loss of generality, that these replacements have always been made, and hence that
d
MINUS
R
and
i
INTERSECT
R
are always both empty; in other words—previous
remarks on this point notwithstanding—I'll assume the rules as such never request
insertion of a tuple that's already present or deletion of one that isn't.
Consider a user
U
who sees all three relvars S, LS, and NLS and performs (say) a DELETE
on relvar S. Thanks to the delete rule on that relvar, then, that DELETE will cause tuples
to be deleted from both relvar LS and relvar NLS (in general).
That rule must therefore be
explicitly visible to user U
—for otherwise user
U
will perceive a violation of
The
Assignment Principle
(again, in general). To be specific, if user
U
isn't aware of that rule,
then that user will at least potentially see a change to the dbvar—i.e., the variable that's the
entire database—that's not exactly what he or she originally requested. Equivalently, that
user will see changes to variables LS and/or NLS that he or she didn't explicitly request at
all. Hence, (a) compensatory actions can't be wholly “under the covers” but must be
exposed to users (at least in some cases), and (b) users must be explicitly aware that the
updates they request are really shorthand for some extended series of operations—in fact,
for a certain multiple assignment (again, at least in some cases).
6
5
E,g., as follows: ON
<any update>
TO S : LS := S WHERE CITY = 'London', NLS := S WHERE CITY ≠ 'London'. Now,
you might think this style for formulating rules is attractive, if only because it seems to be much simpler than the explicit
INSERT and DELETE formulations that I prefer. However, my own opinion is that such simplification is mostly spurious.
Certainly it makes it more difficult to examine certain pragmatically important issues, such as how to respond to a “pure
INSERT” or “pure DELETE” request.
6
Observe that this state of affairs exactly parallels that in which a user who sees both relvar S and relvar SP is allowed to perform
(say) delete operations on relvar S, if those operations cascade to relvar SP.
