Databases Reference
In-Depth Information
relvars in question had the same heading. As the discussions of the present section have shown, however, we
can't limit our attention to that simple case alone.)
Recall from Chapter 6 that, in logic, something that's identically false (e.g., the boolean expression WEIGHT
≥ 17.0 AND WEIGHT < 17.0) is called a
contradiction
. Thus, the requirement that
c1
and
c2
not be
identically false can be stated thus: Neither
c1
nor
c2
is a contradiction in the logical sense.
THE FIRST EXAMPLE REVISITED
Now let's return to our motivating example, in which relvar S was decomposed “vertically” into its projections SNC
and STC on {SNO,SNAME,CITY} and {SNO,STATUS,CITY}, respectively. (The example of light vs. heavy
parts involved horizontal decomposition, of course.) Observe now that although SNC and STC are certainly of the
same degree, there's no way any given tuple can appear in both: Tuples in SNC have an SNAME attribute, while
tuples in STC have a STATUS attribute instead. What's more, there's no way we can simply rename (say) the
SNAME attribute in SNC to STATUS and thereby produce a relvar with the same heading as STC, because
SNAME in SNC is of type CHAR and STATUS in STC is of type INTEGER. (Renaming attributes changes
names
,
not types.) It follows that our second attempt at defining the orthogonality principle is still inadequate; in the case at
hand, in fact, it simply doesn't apply.
Recall now what the problem was with the foregoing design: The tuple (
s
,
c
) appears in the projection of
SNC on SNO and CITY if and only if that very same tuple (
s
,
c
) appears in the projection of STC on SNO and CITY.
That is, the following EQD holds:
CONSTRAINT ... SNC { SNO , CITY } = STC { SNO , CITY } ;
Let's agree to ignore the question of attribute renaming for the moment, since it isn't relevant to this
example. Then the crucial point is that this EQD holds, not between distinct database relvars as such, but rather
between distinct projections of the
same
database relvar: to be specific, projections arising from “vertical”
decomposition of that database relvar. But such doesn't have to be the case, of course─I mean, SNC and STC might
have been defined independently, as two completely distinct relvars, without there ever having existed (in the
designer's mind, so to speak) a relvar equal to their join. They might even be, not relvars in their own right, but
projections of two such distinct relvars. All of which leads to a third attempt at defining the orthogonality principle:
Definition
(
third attempt
): Let relvars
R1
and
R2
be distinct, and let the JD
{
X1
,...,
Xn
} be irreducible with
respect to
R1
.
8
Let there exist some
Xi
(1 ≤
i
≤
n
) and some possibly empty set of attribute renamings on the
projection,
R1X
say, of
R1
on
Xi
that maps
R1X
into
R1Y
, say, where
R1Y
has the same heading as some
subset
Y
of the heading of
R2
. Further, let the projection of
R2
on
Y
be
R2Y
. Then
The Principle of
Orthogonal Design
is violated by
R1
and
R2
if the equality dependency
R1Y
=
R2Y
holds.
Now, this looks a little complicated, but basically all it says is that no projection in any nonloss
decomposition of
R1
can be information equivalent to any projection of
R2
. Indeed, as you can probably see, much
of the complexity in the definition (what complexity there is) arises from the need to deal with the renaming issue.
For interest, here's a slightly simpler version of the definition that ignores that complication:
8
Note that this JD certainly holds in
R1
, by the definition of JD irreducibility (see Chapter 11).
