Databases Reference
In-Depth Information
other department (?). But I seriously doubt whether users would want to have to deal with such convoluted, logic-
chopping arguments in practice.
EXAMPLE 8
Consider the design illustrated in Fig. 15.6 (a slightly revised, somewhat “RM/T-like” version of Fig. 14.4 from the
previous chapter):
EMP EARNS SALARY
_
UNK UNSALARIED
┌─────┐ ┌─────┬────────┐ ┌─────┐ ┌─────┐
│ ENO │ │ ENO │ SALARY │ │ ENO │ │ ENO │
├═════┤ ├═════┼────────┤ ├═════┤ ├═════┤
│ E1 │ │ E1 │ 85,000 │ │ E2 │ │ E4 │
│ E2 │ │ E3 │ 70,000 │ └─────┘ └─────┘
│ E3 │ └─────┴────────┘
│ E4 │
└─────┘
Fig. 15.6: An “RM/T design” for employees and salaries─sample values
The predicates for these relvars are as follows:
EMP:
Employee ENO is employed by the company.
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.
I observe now that either relvar SALARY_UNK or relvar UNSALARIED is redundant─any employee
represented in relvar EMP and not in relvar EARNS must be represented in exactly one of the other two; thus, we
could eliminate, say, relvar SALARY_UNK without any loss of information. Yet there doesn't seem to be any good
reason for choosing either of SALARY_UNK and UNSALARIED over the other as the one to be eliminated, and
considerations of symmetry would argue in favor of retaining both, and living with the redundancy (?).
Aside:
Symmetry is usually another good design principle. To quote Polya:
14
“Try to treat symmetrically
what is symmetrical, and do not destroy wantonly any natural symmetry.” But Example 8 and others like
it─Example 7 too, perhaps─show that symmetry and nonredundancy can sometimes be conflicting
objectives.
End of aside.
14
G. Polya:
How To Solve It
(2nd ed., Princeton University Press, 1971).
