Databases Reference

In-Depth Information

from the {CITY,STATUS,SNAME} component without significant loss.) What's more, one consequence of

abiding by orthogonality is that the fourth of the normalization principles as given at the beginning of the

chapter─viz., that every projection should be needed in the reconstruction process─will automatically be satisfied

(and so there's a logical connection, of a kind, between orthogonality and normalization after all).

THE SECOND EXAMPLE REVISITED

Unfortunately, the third version of the orthogonality principle as defined in the previous section is still missing

something, and revisiting the light vs. heavy parts example shows what it is: It's missing that business about

restrictions. (In that example, the EQD wasn't between database relvars as such, nor between projections of such

relvars, but rather between certain restrictions of such relvars.) In other words, the third version of the principle

failed to subsume the second version. By contrast, the following formulation takes care of both the restriction issue

and the projection issue:

Definition
(
fourth attempt
): Let relvars
R1
and
R2
be distinct, and let the JD
{
X1
,...,
Xn
} be irreducible

with respect to
R1
. 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 and only if there exist restriction conditions
c1
and
c2
,

neither of
which is identically false, such that the equality dependency (
R1Y
WHERE
c1
) = (
R2Y
WHERE

c2
) holds.

THE FINAL VERSION

Believe it or not, there's still a small problem … Consider a version of the suppliers relvar—I'll call it SCC—with

attributes SNO, CITYA, and CITYB. Let SCC be subject to the constraint that for any given supplier, the CITYA

and CITYB values are identical.
Result:
Redundancy! Of course, this is a crazy design, but it's a possible one, and

it would be nice to extend the orthogonality principle to take care of such designs also. And the following final (?)

formulation should do the trick (I'll leave it as an exercise for you to figure out exactly how):

Definition
(
“final” version
): Let
R1
and
R2
be relvars (not necessarily distinct), and let the JD
{
X1
,...,
Xn
}

be irreducible with respect to
R1
. 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
(distinct from
Xi
, if
R1
and
R2
are one and the same) 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

and only if there exist restriction conditions
c1
and
c2
,
neither of
which is identically false, such that the

equality dependency (
R1Y
WHERE
c1
) = (
R2Y
WHERE
c2
) holds.

This version of the principle subsumes all previous versions.

A CLARIFICATION

I'm sorry to have to report that there's quite a lot of confusion in the literature over orthogonality, even though the

basic idea is so simple. I'm even sorrier to have to say the confusion is partly my fault─some of my previous

writings on this topic have been (not to put too fine a point upon the matter) flat wrong. So let me take this