Recall from Chapter 4 that the relvar predicate for a relvar is the intended interpretation loosely, the meaning for that relvar. For example, the predicate for relvar S looks like this:
In an ideal world, therefore, this predicate would serve as the criterion for acceptability of updates on relvar S that is, it would dictate whether a given INSERT or DELETE or UPDATE operation on that relvar can be accepted. But this goal is clearly unachievable:
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:
In other words: the system can't guarantee that the database contains only true propositions it can guarantee only that it doesn't contain anything that violates any constraint (meaning it contains no inconsistencies). Sadly, truth and consistency aren't the same thing. To be specific:
More succinctly, correct implies consistent (but not the other way around), and inconsistent implies incorrect (but not the other way around) where to say that 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 I'll get to views in just a moment and let C1, C2, . . . , Cn be all of the defined database constraints, single- or multi-relvar, that mention R. Assume for simplicity that each Ci is just a boolean expression (in other words, let's ignore the constraint names, for simplicity). Then the boolean expression: ( C1 ) AND ( C2 ) AND ... AND ( Cn ) 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 if no constraints are defined for a given relvar, the default is just TRUE. 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:
Now let V be a view. Then V too has a "total relvar constraint" (which I'll usually abbreviate to just the constraint for V, for simplicity), derived in an obvious manner from the constraints that apply to the relvars in terms of which V is defined. For example, let SC be the total constraint for base relvar S. Then the total constraint for view LS ("London suppliers") is: ( SC ) AND ( CITY = 'London' ) Now let DB be a database, and let DB contain relvars R1, R2, . . . , Rn (only). Let the constraints for those relvars be RC1, RC2, . . . , RCn, respectively. Then the total database constraint for DB, DBC say which I'll refer to for the purposes of this book as just the constraint for DB is the AND of all of those relvar constraints: ( RC1 ) AND ( RC2 ) AND ... AND ( RCn ) And here's a correspondingly extended (in fact, the final) version of The Golden Rule:
Observe in particular that in accordance with my position that all integrity checking must be immediate the 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:
But q was arbitrary! It follows that any proposition whatsoever (even obviously false ones like 1 = 0) can be shown to be true in an inconsistent system. |