Constraints and Predicates


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:

Supplier SNO is under contract, is named SNAME, has status STATUS, and is located in city CITY.

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:

  • 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,[*] but there's no way the system can do anything analogous.

    [*] 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 predicates).

  • 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, that there's a supplier S6 named Lopez with status 30 and city Madrid, 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 violate any integrity constraints. Assuming it doesn't, then 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 anymore).

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:

[*] Precisely for this reason, I've elsewhere used the term internal predicate to refer to constraints and the term external predicate to refer to what I'm here calling the relvar predicate.

The system can't enforce truth, only consistency.

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:

  • If the database contains only true propositions, then it's consistent, but the converse isn't necessarily so.

  • If the database is inconsistent, then it contains at least one false proposition, but the converse isn't necessarily so.

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:

No update operation must ever cause any relvar constraint to evaluate to FALSE.

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:

No update operation must ever cause any database constraint to evaluate to FALSE.

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:

  • 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 obviously false ones like 1 = 0) can be shown to be true in an inconsistent system.



Database in Depth
Database in Depth: Relational Theory for Practitioners
ISBN: 0596100124
EAN: 2147483647
Year: 2006
Pages: 127
Authors: C.J. Date

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net