Summary

I've discussed two basic kinds of constraints, type constraints and database constraints. A type constraint defines the set of values that constitute a given type; in Tutorial D, it's specified as part of the definition of the type in question, and it's expressed in terms of a possrep (possible representation) for that type. The possrep itself imposes an a priori constraint on the type (and SQL doesn't support any type constraints apart from such a priori ones). Type constraints are checked as part of the execution of selector operators. As a digression, I elaborated on the notion of selectors and the related notion of THE_ operators, both of which are intimately related to the possrep notion.

Database constraints constrain the values that can appear in a given database (if they apply to just one relvar, they're sometimes referred to, informally, as relvar constraints). They're specified by means of a CONSTRAINT statement in Tutorial D or a CREATE ASSERTION statement in SQL, and they're supposed to be checked "at semicolons" (though they might not be, in SQL). Checking constraints at semicolons means checking them at the end of any statement that might cause them to be violated which basically means relational assignments, since relational assignment is fundamentally the only operation that can update the database. I gave a series of arguments for rejecting the conventional wisdom that multi-relvar constraints, at least, need not be checked until commit time (and in passing I briefly discussed the notion of semantic optimization). I also introduced the important idea of multiple assignment.

Next, I showed that "the" relvar constraint for relvar R might be regarded as the system's approximation to the relvar predicate for R; in particular, it serves as the criterion for acceptability of updates on R. "The system can't enforce truth, only consistency." The Golden Rule says:

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

I concluded by claiming that integrity constraints are absolutely vital. To me, in fact, they're what database systems are all about. To say it again: I don't care how fast your system runs if I can't trust the answers it gives me.