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).
Search WWH ::

Custom Search