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).