Recall from Chapter 5 that the predicate for any given relvar is the intended interpretation—loosely, the meaning—for that relvar. For example, the predicate for relvar S looks like this:
Supplier SNO is under contract, is named SNAME, has status STATUS, and is located in city CITY.
In an ideal world, then, this predicate would serve as “the criterion for acceptability of updates” on relvar S—that is, it would dictate whether a given update operation on that relvar can be accepted. But of course this goal is unachievable:
For one thing, the system can’t know what it means for a “supplier” to be “under contract” or to be “located” somewhere; to repeat, these are matters of interpretation. For example, if the supplier number S1 and the city name London happen to appear together in the same tuple, then the user can interpret that fact to mean that supplier S1 is located in London,[123] but there’s no way the system can do anything analogous.
For another, even if the system could know what it means for a supplier to be under contract or to be located somewhere, it still couldn’t know a priori whether what the user tells it is true! If the user asserts to the system (by means of some update operation) that there’s a supplier S6 named Lopez with status 30 and city Madrid, then there’s no way for the system to know whether that assertion is true. All the system can do is check that the user’s assertion doesn’t cause any integrity constraint to be violated. Assuming it doesn’t, the system will accept the user’s assertion and will treat it as true from that point forward (until such time as the user tells the system, by executing another update, that it isn’t true any more).
Thus, the pragmatic “criterion for acceptability of updates,” as opposed to the ideal one, is not the predicate but the corresponding set of constraints, which might thus be regarded as the system’s approximation to the predicate. Equivalently:
The system can’t enforce truth, only consistency.
Sadly, truth and consistency aren’t the same thing. To be specific, if the database contains only true propositions, then it’s consistent, but the converse isn’t necessarily so; if it’s inconsistent, then it contains at least one false proposition, but the converse isn’t necessarily so. Or to put it another way, correct implies consistent (but not the other way around), and inconsistent implies incorrect (but not the other way around)—where to say the database is correct is to say it faithfully reflects the true state of affairs in the real world, no more and no less.
Now let me try to pin down these notions a little more precisely. Let R be a base relvar, and let C1, C2, ..., Cm (m ≥ 0) be all of the database constraints, single relvar or multirelvar, that mention R. Assume for simplicity that each Ci is just a boolean expression (i.e., ignore the constraint names, for simplicity). Then the boolean expression
(C1) AND (C2) AND ... AND (Cm) AND TRUE
is the total relvar constraint for relvar R (but I’ll refer to it for the purposes of this book as just the constraint for R). Note that final “AND TRUE,” by the way; the implication is that in the unlikely event that no constraints at all are defined for a given relvar (i.e., m = 0), then the default is just TRUE.[124]
Now let RC be “the” relvar constraint for relvar R. Clearly, R must never be allowed to have a value that causes RC to evaluate to FALSE. This state of affairs is the motivation for (the first version of) what I like to call The Golden Rule:
No update operation must ever cause the relvar constraint for any relvar to evaluate to FALSE.
Now let DB be a database, and let R1, R2, ..., Rn (n ≥ 0) be all of the relvars in DB. Let the constraints for those relvars be RC1, RC2, ..., RCn, respectively. Then the boolean expression
(RC1) AND (RC2) AND ... AND (RCn) AND TRUE
is the total database constraint for DB (but I’ll refer to it for the purposes of this book as just the constraint for DB). And here’s a correspondingly extended—in fact, the final—version of The Golden Rule:
No update operation must ever cause the database constraint for any database to evaluate to FALSE.
Observe in particular that, in accordance with my position that all integrity checking must be immediate, The Golden Rule talks in terms of update operations, not transactions.
Now I can take care of a piece of unfinished business. I’ve said we can never trust the answers we get from an inconsistent database; here’s the proof. As we know, a database can be regarded as a collection of propositions. Suppose that collection is inconsistent; that is, suppose it implies that both p and NOT p are true, where p is some proposition. Now let q be any arbitrary proposition. Then:
From the truth of p, we can infer the truth of p OR q.
From the truth of p OR q and the truth of NOT p, we can infer the truth of q.
But q was arbitrary! It follows that any proposition whatsoever (even ones that are obviously false, like 1 = 0) can be shown to be “true” in an inconsistent system. Note: In case you’re still not convinced, let me refer you to the further discussion of this issue in Chapter 10.
[123] Or that supplier S1 used to be located in London, or that supplier S1 has an office in London, or that supplier S1 doesn’t have an office in London, or any of an infinite number of other possible interpretations (corresponding, of course, to an infinite number of possible relvar predicates).
[124] “Unlikely” is right; every relvar is supposed to be subject to a key constraint at the very least.