Databases Reference
In-Depth Information
opportunity to try and set the record straight. The basic point is this: Orthogonality says relvars shouldn't have
overlapping meanings; it doesn't say relvars shouldn't have the same heading (or, more generally, headings that
“overlap”). Here's a simple example, due to Hugh Darwen, that illustrates the difference. Consider the predicates
Employee ENO is on vacation
and
Employee ENO is awaiting phone number allocation
. The obvious design for
this situation involves two relvars of degree one that look like this (in outline):
ON_VACATION { ENO }
KEY { ENO }
NEEDS_PHONE { ENO }
KEY { ENO }
Clearly, the very same tuple can appear in both of these relvars at the same time. But even if it does, those
two appearances represent two different propositions, and there's no redundancy involved, and no violation of
orthogonality.
Observe now that there's a difference in kind between the example just discussed and the light vs. heavy
parts examples (relvars LP and HP) illustrated in Figs. 14.2 and 14.3, earlier in this chapter. In the latter case, as we
saw earlier, we can write a formal constraint, to the effect that the WEIGHT value has to lie in a certain range, that a
given tuple has to satisfy in order for it to be accepted into LP or HP or both. However, there's no formal constraint
we can write that a given tuple has to satisfy in order for it to be accepted into ON_VACATION or NEEDS_
PHONE or both. If the user asserts that a certain tuple is to be inserted into, say, ON_VACATION, then the system
simply has to trust the user; there's no check it can perform to ascertain that the tuple does indeed belong in
ON_VACATION instead of (or as well as) NEEDS_PHONE.
Here's another example, also due to Hugh Darwen, that might also mistakenly be thought to violate
orthogonality but in fact doesn't. We're given three relvars that look like this (in outline):
9
EARNS { ENO , SALARY }
KEY { ENO }
SALARY_UNK { ENO }
KEY { ENO }
UNSALARIED { ENO }
KEY { ENO }
Sample values are shown in Fig. 14.4.
EARNS SALARY
_
UNK UNSALARIED
┌─────┬────────┐ ┌─────┐ ┌─────┐
│ ENO │ SALARY │ │ ENO │ │ ENO │
├═════┼────────┤ ├═════┤ ├═════┤
│ E1 │ 85,000 │ │ E2 │ │ E4 │
│ E3 │ 70,000 │ └─────┘ └─────┘
└─────┴────────┘
Fig. 14.4: Relvars EARNS, SALARY_UNK, and UNSALARIED─sample values
9
The example illustrates a recommended approach (discussed in detail in
SQL and Relational Theory
) to dealing with “missing information” in
relational designs.
