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