Databases Reference
In-Depth Information
The predicates for these three relvars are as follows:
EARNS:
Employee ENO has salary SALARY.
SALARY_UNK:
Employee ENO has a salary, but we don't know what it is.
UNSALARIED:
Employee ENO doesn't have a salary.
Now, relvars SALARY_UNK and UNSALARIED do have the same heading─but even if the same tuple
could simultaneously appear in both, there wouldn't be any redundancy, because the appearances in question would
represent two different propositions. In fact, of course, the semantics of the situation are such that no tuple should
simultaneously appear in both, anyway (in other words, the relvars are disjoint). Here's the necessary integrity
constraint to express this fact:
CONSTRAINT ... IS_EMPTY ( SALARY_UNK JOIN UNSALARIED ) ;
(As explained in the answer to Exercise 6.4 in Appendix D, the
Tutorial D
expression
IS_EMPTY ( r )
returns TRUE if relation
r
is empty and FALSE otherwise.)
CONCLUDING REMARKS
In closing, I want to make a few further (and somewhat miscellaneous) observations on the concept of orthogonality
in general. First of all, the overall objective of orthogonal design, like that of normalization, is to reduce redundancy
and thereby to avoid certain update anomalies that might otherwise occur. In fact, orthogonality complements
normalization, in the sense that─loosely speaking─normalization reduces redundancy within relvars, while
orthogonality reduces redundancy across relvars.
What's more, orthogonality complements normalization in another way also. Consider once again the (bad)
decomposition of relvar S into its projections SNC and STC, as illustrated in Fig. 14.1. As we saw earlier, that
decomposition abided by all of the usual normalization principles; in other words, it was orthogonality, not
normalization, that told us the design was bad.
My next point is that, like the principles of normalization,
The Principle of Orthogonal Design
is basically
just common sense─but (again like normalization) it's formalized common sense, and the remarks I made in
Chapter 1 in connection with such formalization apply here also. As I said in that chapter:
What design theory does is [formalize] certain commonsense principles, thereby opening the door to the possibility of
mechanizing those principles (that is, incorporating them into computerized design tools). Critics of the theory often
miss this point; they claim, quite rightly, that the ideas are mostly just common sense, but they don't seem to realize it's a
significant achievement to state what common sense means in a precise and formal way.
My final point is this: Suppose we start with the usual parts relvar P, but decide for design purposes to
decompose that relvar into a set of restrictions, as in the light vs. heavy parts example. Then the orthogonality
principle tells us that the restrictions in question should be pairwise disjoint (also, of course, that their union─which
will in fact be a disjoint union─should take us back to the original relvar).
Note:
In previous writings, I've referred
to a decomposition that meets this requirement as an orthogonal decomposition. However, I now think it would be
