14.1 Try stating the final version of The Principle of Orthogonal Design without looking back at the body of the chapter.

14.2 Consider the design of any database you happen to be familiar with. Does it involve any violations of The Principle of Orthogonal Design? Are there any constraints—especially “overlapping” ones—that ought to be stated declaratively but haven’t been?

14.3 Consider the second example in the section A CLARIFICATION (the one involving relvars EARNS, SALARY_UNK, and UNSALARIED). Do you think the design illustrated in that example is redundancy free?

14.4 Suppose we replace the suppliers relvar S by a set of relvars LS, PS, AS, ... (one for each distinct supplier city; the LS relvar, for example, contains tuples for suppliers in London only). These relvars all have the same attributes, viz., SNO, SNAME, and STATUS (there’s no need to keep the CITY attribute, because if we did its value would be constant throughout each relvar). Does this design violate orthogonality? Can you think of any other problems with it?

By the way, if we did keep the CITY attribute in relvars LS, PS, AS, etc., the design would actually violate the principles of normalization! Why so, exactly?