SQL and Relational Theory, 2nd Edition

MISCELLANEOUS ISSUES

There are a few further points to do with integrity that I need to cover somewhere but don’t fit very well into any of the preceding sections.

First of all, a constraint, since it’s basically a boolean expression that must evaluate to TRUE, is in fact a proposition (I more or less suggested as much in the previous section, but I never came out and stated it explicitly). To see that this is so, consider constraint CX1 once again from the section DATABASE CONSTRAINTS:

     CONSTRAINT CX1 IS_EMPTY ( S WHERE STATUS < 1 OR STATUS > 100 ) ;

The relvar name “S” here constitutes what logicians call a designator; when the constraint is checked, it designates a specific value—namely, the value of that relvar at the time in question. By definition, that value is a relation (s, say), and so the constraint effectively becomes:

     CONSTRAINT CX1 IS_EMPTY ( s WHERE STATUS < 1 OR STATUS > 100 ) ;

Clearly, the boolean expression here—which is really the constraint as such, “CONSTRAINT CX1” being little more than window dressing—is certainly either true or false, unequivocally, and that’s the definition of what it means to be a proposition (see Chapter 5).

Second, suppose relvar S already contains a tuple that violates constraint CX1 when the CONSTRAINT statement just shown is executed; then that execution must fail. More generally, whenever we try to define a new database constraint, the system must first check to see whether that constraint is satisfied by the database at that time; if ...