Additional Constraint Examples

Additional Constraint Examples

The same constraint notation permits us to express far more than referential integrity. For instance, we can express any functional dependency as an algebraic constraint, although the notation is more awkward than the FD notation introduced in "Functional Dependencies".

Example 1 : Let us express the FD:

for the relation

MovieStar(name, address, gender, birthdate)

as an algebraic constraint. The idea is that if we make all pairs of Moviestar tuples (t1, t2), we must not find a pair that agree in the name component and disagree in the address component. To make the pairs we use a Cartesian product, and to search for pairs that violate the FD we use a selection. We then assert the constraint by equating the result to 0.

To begin, since we are taking the product of a relation with itself, we need to rename at least one copy, in order to have names  for the attributes of the product. For conciseness, let us use two new names, MS1 and MS2, to refer to the MovieStar relation. Then the FD can be expressed by the algebraic constraint:

In the above, MS1 in the product MS1 x MS2 is shorthand for the renaming:

and MS2 is a similar renaming of Moviestar.

Some domain constraints can also be expressed in relational algebra. Sometimes, a domain constraint simply requires that values for an attribute have a specific data type, such as integer or character string of length 30, so we may associate that domain with the attribute. On the other hand, sometimes a domain constraint involves particular values that we need for an attribute. If the set of acceptable values can be expressed in the language of selection conditions, then this domain constraint can be expressed in the algebraic constraint language.

Example 2 : Assume we wish to specify that the only legal values for the gender attribute of MovieStar are F and M. We can express this constraint algebraically by:

That is, the set of tuples in MovieStar whose gender component is equal to neither F nor M is empty.

In the end, there are some constraints that fall into none of the categories outlined in "The Modeling of Constraints", nor are they functional or multivalued dependencies. The algebraic constraint language lets us express many new kinds of constraints. We offer one example here.

Example 3 : Assume we wish to require that one must have a net worth of at least $10,000,000 to be the president of a movie studio. This constraint cannot be classified as a domain, single-value, or referential integrity constraint. Yet we can express it algebraically as follows. First, we need to theta-join the two relations

MovieExec (name, address, cert#, networth)
Studio (name, address, presC#)

using the condition that presC# from Studio and cert# from MovieExec are equal. That join combines pairs of tuples consisting of a studio and an executive, such that the executive is the president of the studio. If we select from this relation those tuples where  the net worth is less than ten million, we have a set that, according to our constraint, must be empty. Therefore, we may express the constraint as:

An other way to express the same constraint is to compare the set of certificates that represent studio presidents with the set of certificates that represent executives with a net worth of at least $10,000,000; the former must be a subset of the latter. The  containment

expresses the above idea.