Databases Reference
In-Depth Information
Note:
In connection with the first of these additional constraints, I should explain that
Tutorial D
—at least, the version of
Tutorial D
I'm using in this topic—supports both dyadic
(infix) and
n
-adic (prefix) versions of certain relational operators, including union in particular
(also join, as we'll see in the next chapter). Thus, for example, the union of LS and NLS can be
expressed as either LS UNION NLS or (as above) UNION {LS,NLS}. In this topic, I'll use both
styles—whichever suits my purpose best at the time. As for the second of those “additional”
constraints, here I should explain that the
Tutorial D
expression DISJOINT {
r1
,
...
,
rn
} returns
TRUE if and only if no two of the argument relations
r1
, ...,
rn
have any tuples in common.
Incidentally (as you might recall from Chapter 1), this particular constraint, along with the
various key constraints, implies the following constraint as well:
CONSTRAINT ... DISJOINT { LS { SNO } , NLS { SNO } } ;
(“no supplier number appears in both LS and NLS”).
Important:
Observe how the foregoing constraints taken together ensure the information
equivalence I mentioned earlier; in fact, they serve to show how each of the two designs, S by
itself vs. the combination of LS and NLS, can be mapped into the other.
Aside:
Of course, a database that contains all three relvars obviously involves some
redundancy. Indeed, the foregoing constraints—at least, the multivariable ones—serve to
capture those redundancies in a formal way. As I've explained elsewhere, however (see
Database Design and Relational Theory
), such redundancy shouldn't cause any harm, just
so long as it's properly controlled. I'll elaborate on this point briefly in the next section
(“More on Compensatory Actions”).
End of aside
.
A note on terminology:
Several of the foregoing CONSTRAINT statements—to be
specific, all of the ones in which the boolean expression is of the form <
relation expression
> =
<
relation expression
>—effectively require a certain
equality dependency
to hold (i.e., to be
satisfied at all times). Here's a definition:
Definition:
An equality dependency (EQD for short) is a statement of the form
rx1
=
rx2
,
where the expressions
rx1
and
rx2
denote relations
r1
and
r2
, respectively, and
r1
and
r2
are of the same type. The EQD is satisfied if and only if the bodies of
r1
and
r2
are equal.
Equality dependencies in turn are an important special case of a more general phenomenon
known as
inclusion
dependencies:
