Databases Reference
In-Depth Information
better to generalize this term and use it to mean any decomposition that abides by the orthogonality principle. This
revised definition includes the earlier one as a special case.
EXERCISES
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?
