SQL and Relational Theory, 2nd Edition

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—and that’s effectively what a type constraint does. Now, in the case of system defined types, it’s the system that carries out this task, and there’s not much more to be said. In the case of user defined types, by contrast, there certainly is more to say, much more. So let’s suppose for the sake of the example that shipment quantities, instead of being of the system defined type INTEGER, are of some user defined type (QTY, say). Here then is a possible Tutorial D definition for that type:

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.

• Line 2 says 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,^[113] indicating that values of the type in question can possibly be represented in some specific way; and unlike physical representations, possible representations—which we usually abbreviate to just possreps—definitely are visible to the user (in the example, users do definitely know that quantities have a possrep called QPR). Note carefully, however, that there’s no suggestion that the specified possible representation is the same as any physical representation, whatever that happens ...