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 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 Figure 14-2 and Figure 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):^[148]

     EARNS      { ENO , SALARY }
                KEY { ENO }

     SALARY_UNK { ENO }
                KEY { ENO }

     UNSALARIED { ENO }
                KEY { ENO }

Sample values are shown in Figure 14-4.

Figure 14-4. Relvars EARNS, SALARY_UNK, and UNSALARIED—sample values

The predicates for these three relvars are as follows:

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