Databases Reference
In-Depth Information
another way, the fact that the DBMS doesn't know the constraint is supposed to hold doesn't
mean it knows it isn't (if you follow me).
5
So the question becomes: What should the DBMS
do—(a) assume the constraint holds anyway, or (b) assume it doesn't? (Of course, it goes
without saying that it does have to operate on the basis of one or other of these two assumptions.)
Now, if the DBMS operates under assumption (a), it will do its best to ensure that suppliers are
represented in both ST and SC (if they're represented at all, that is), even though a supplier not
so represented won't cause a violation of
The Golden Rule
. (It won't cause a violation of
The
Golden Rule
precisely because the constraint hasn't been stated.) In fact, if the DBMS does
operate under assumption (a), the updating rules—the delete rules in particular—become exactly
the same as those for the strict one to one case, and that's the end of the discussion. So what
happens if it operates under assumption (b)?
Before I try to answer that question, let me just state for the record that assumption (b)
doesn't correspond to a constraint—it corresponds to the
absence
of a constraint. I mean, I hope
it's obvious that there's no formal CONSTRAINT statement we can write that says it's legal for
some supplier number to appear in ST and not SC or the other way around. (I mention this point
because in fact I've encountered people who apparently believe the opposite. If you're such a
person yourself, then I suggest you try writing such a CONSTRAINT statement. If you try this
exercise, I think it'll quickly convince you that what I'm saying here is correct—if you weren't
convinced already, that is.)
Be that as it may, let's take a closer look at assumption (b). Let's consider a concrete
example. Suppose we try to delete the tuple (S1,20,London) from S. Clearly, the DBMS could
achieve the desired effect by doing any of the following: 1. deleting the tuple (S1,20) from ST;
2. deleting the tuple (S1,London) from SC; or 3. doing both. In other words, we might consider
any of the following as a possible delete rule for S:
1.
Cascade the delete to just ST.
2.
Cascade the delete to just SC.
3.
Cascade the delete to both ST and SC.
Note:
There's a fourth possibility too, of course: Reject the delete entirely, on the grounds
that we don't know which of the other three options to choose. On the grounds that it's surely
desirable in general for user requests to succeed if they sensibly can, however, it seems
preferable to accept the delete and let it cascade appropriately—especially since cascading (more
specifically, cascading to both ST and SC, option 3) is the logically correct thing to do if
5
In symbols, NOT(
knows
(
p
)) doesn't imply
knows
(NOT(
p
)). Or as somebody or other once said: “Absence of evidence isn't
evidence of absence.” Mind you, if a certain constraint is supposed to hold but the DBMS hasn't been informed of that fact, then
the design is certainly incomplete, and errors of various kinds are certain to ensue. But such violations of good design principles
aren't exactly unknown in practice.
