Database in Depth

Chapter Six. Integrity Constraints

I've touched on the issue of integrity constraints at many points in preceding chap ters, but it's time to get more specific. Here first is 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 are so called because they constrain the values that can legally appear in some particular context. The ones we're interested in 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 defines the values that can appear in a given database.

By the way, it's worth noting right away that constraints in general can be regarded as a formal version of what some people call business rules . I'll touch on this point again in the next chapter.

Type Constraints

As we saw in Chapter 2, one of the things we have to do when we define a type is specify the values that make up that type. Here's an example:

  1  TYPE QTY
  2       POSSREP QPR
  3            { Q INTEGER
  4                    CONSTRAINT Q ≥ 0 AND Q ≤ 5000 } ;

Explanation:

• Line 1 just says we're defining a type called QTY ("quantities").

• Line 2 says that quantities have a possible representation called QPR. Now, physical representations are always hidden from the user, as we know from Chapter 2. However, Tutorial D requires every TYPE statement to include at least one POSSREP specification,^[*] indicating that values ...