Databases Reference
In-Depth Information
CNO, TNO, XNO, and DAYS. When I first introduced that example, I said the predicate was
Teacher TNO spends
DAYS days with textbook XNO on course CNO
. But it would be more accurate to say it's as follows:
Course CNO can be taught by teacher TNO
and
Course CNO uses textbook XNO
and
Teacher TNO spends DAYS days with textbook XNO on course CNO.
Similarly, consider relvar SPJ from Chapters 9 and 10, with its attributes SNO, PNO, and JNO. When I first
introduced that example, I said the predicate was
Supplier SNO supplies part PNO to project JNO
. However, I think
it would be more accurate to say it's as follows:
Supplier SNO supplies part PNO
and
Part PNO is supplied to project JNO
and
Project JNO is supplied by supplier SNO
and
Supplier SNO supplies part PNO to project JNO.
To continue with this last example just a moment longer: As we know from Chapter 10, SPJ isn't in 5NF,
and the recommendation is therefore to decompose it into its “projection” relvars SP, PJ, and JS, with headings
{SNO,PNO}, {PNO,JNO}, and {JNO,SNO}, respectively. But what are the predicates for these three relvars? The
answer depends on what I referred to in Chapter 9 (in a footnote) as the full semantics of the situation. Consider
relvar SP, for example. If it's possible for a tuple (
s
,
p
) to appear in SP without a tuple for supplier
s
appearing in JS
or without a tuple for part
p
appearing in PJ, then the predicate for SP is simply
Supplier SNO supplies part PNO
.
But if the appearance of tuple (
s
,
p
) in SP means there must be both a tuple for supplier
s
in JS and a tuple for part
p
in PJ, then the predicate for SP is
Supplier SNO supplies part PNO to some (unspecified) project JNO
. Since the
second of these possibilities is more constraining than the first, it seems to me it would be prudent to assume the first
interpretation.
Example 10
See the discussion of Example 9 above.
Example 11
No further discussion provided.
Example 12
Let C1 be a customer and let the sum of payments for customer C1 be (say) $10,000. Then this very
proposition─
The sum of payments for customer C1 is $10,000
─is represented explicitly by the appearance of a tuple
for customer C1 in relvar TOTALS and implicitly by the appearance of the set of tuples for that same customer in
relvar PAYMENTS.
CONCLUDING REMARKS
In view of the discussions of the previous section, let's agree for simplicity that the only propositions we're
interested in are ones that aren't existentially quantified. I've claimed in this chapter, then, that a database certainly
involves redundancy if it contains two distinct representations of the same proposition. In particular, we don't want
