SQL and Relational Theory

Chapter 8. SQL and Constraints

I’VE TOUCHED ON THE TOPIC OF INTEGRITY CONSTRAINTS OCCASIONALLY IN PREVIOUS CHAPTERS, BUT IT’S TIME TO GET MORE SPECIFIC. Here’s a rough definition, repeated from Chapter 1: An integrity constraint (constraint for short) is basically just a boolean expression that must evaluate to TRUE. Constraints in general are so called because they constrain the values that can legally appear as values of some variable; but the ones we’re interested in here are the ones that apply to database variables specifically. Such constraints fall into two broad categories, type constraints and database constraints; in essence, a type constraint defines the values that constitute a given type, and a database constraint further defines the values that can appear in a given database (where “further” means over and above the constraints imposed by the pertinent type constraints). As usual, in what follows I’ll discuss these concepts in both relational and SQL terms.

By the way, it’s worth noting that constraints in general can be regarded as a formal version of what some people call business rules. Now, this latter term doesn’t really have a precise definition (at least, not one that’s universally accepted); in general, however, a business rule is a declarative statement—emphasis on declarative—of some aspect of the enterprise the database is meant to serve, and statements that constrain the values of database variables certainly fit that loose definition. In fact, I’ll go further. ...