Databases Reference
In-Depth Information
that tuple
t
represents a “true fact,” then, in accordance with
The Closed World Assumption
, that tuple
t
must
necessarily appear in both relvars at the time in question (whence the redundancy, of course). In fact, we have
another EQD on our hands:
CONSTRAINT ... ( LP WHERE WEIGHT = 17.0 ) =
( HP WHERE WEIGHT = 17.0 ) ;
To say it again, the problem in the example is that we've allowed two relvars to have overlapping predicates.
Clearly, then, the principle we're looking for is going to say something along the lines of: Don't do that! Let's try
and state the matter a little more precisely:
Definition
(
first attempt
):
The Principle of Orthogonal Design
says that if relvars
R1
and
R2
are distinct,
then there must not exist a tuple with the property that if it appears in
R1
, then it must also appear in
R2
and
vice versa.
3
Note:
The term
orthogonal
here derives from the fact that what the principle effectively says is
that relvars should be independent of one another─which they won't be, if their meanings overlap in the
foregoing sense.
In what follows, I'll sometimes abbreviate the foregoing principle (or, rather, various versions of that principle) to
just
the orthogonality principle
, or sometimes just to
orthogonality
.
Aside:
As elsewhere in this topic, I might be accused of practicing a tiny deception in the foregoing. Take
another look at Fig. 14.3; in particular, take a look at the tuple for part P2. That tuple appears in both LP and
HP because it represents a true instantiation of the predicate for LP
and
a true instantiation of the predicate
for HP. Or does it? The instantiations of those predicates for part P2 are actually as follows:
LP:
Part P2 is named Bolt, has color Green and weight 17.0 (which is less than or equal to 17.0),
and is stored in city Paris.
HP:
Part P2 is named Bolt, has color Green and weight 17.0 (which is greater than or equal to
17.0), and is stored in city Paris.
These two propositions aren't the same! Of course, they're certainly equivalent to one another─but in order
to recognize that equivalence, we need to know that “17.0 ≤ 17.0” and “17.0 ≥ 17.0” are both true, and then
we need to apply a little logical reasoning. (The point is, what's obvious to us as human beings isn't
necessarily obvious to a machine, and for completeness I really ought to have spelled out the missing steps in
my argument.)
End of aside.
Now, adherence to the orthogonality principle in the light vs. heavy parts example would certainly avoid the
redundancies illustrated in Fig. 14.3. Note, however, that the principle as stated applies only to relvars like LP and
HP that have the very same heading, because of course it's impossible for the same tuple to appear in two different
relvars if the relvars in question have different headings. Thus, you might be thinking the orthogonality principle
isn't much use, because it's probably unusual in practice to have two relvars in the same database with the same
3
That “and vice versa” is important. Consider a revised version of the suppliers-and-parts database, in which (a) attribute QTY is dropped from
relvar SP and (b) another relvar, SAP, with heading {SNO,PNO} and predicate
Supplier SNO is able to supply part PNO
is added. Then there
might well be a constraint to the effect that a given tuple can appear in SP only if it also appears in SAP, and such a reasonable state of affairs
doesn't (and obviously shouldn't) constitute a violation of orthogonality.
