Databases Reference
In-Depth Information
attribute A in that heading is renamed B and (b) body identical to that of r1 except that all references to A in
that body (more precisely, in tuples in that body) are replaced by references to B . Note: Tutorial D
additionally supports a form of RENAME that allows two or more separate renamings to be carried out in
parallel (“multiple RENAME”). Examples are given in Chapter 14.
2.16 The relational algebra consists of operators that (speaking very loosely) allow us to derive “new” relations
from “old” ones. Each such operator takes one or more relations as input and produces another relation as output
(for example, the difference operator takes two relations as input and “subtracts” one from the other to derive
another relation as output)─and that's the closure property. Note that it's that property that (among other things) lets
us write nested relational expressions; since the output from every operation is the same kind of thing as the input,
the output from one operation can become the input to another. For example, we can take the difference between
relations r1 and r2 (in that order), feed the result as input to a union with some relation r3 , feed that result as input to
a projection or restriction, and so on.
3.1 With reference to the sample value shown for relvar STP in Chapter 1 (Fig. 1.2), we can't insert the fact that
supplier S5 has status 30 until supplier S5 supplies some part; we can't delete the shipment for supplier S3 without
losing the fact that supplier S3 has status 30; and we can't change the status in one tuple for a given supplier, say
supplier S1, without changing it in all of them. The obvious decomposition is into relvars with headings
{SNO,STATUS} and {SNO,PNO,QTY}; it's also obvious that this decomposition avoids the anomalies. Note: It's
worth pointing out in passing that the insertion and deletion anomalies are caused by the fact that the design is
logically incorrect, whereas the modification anomaly is caused by the fact that it's redundant (see Exercise 3.3).
3.2 Let the heading of r be partitioned into sets of attributes X , Y , and Z , and let the projections r1 and r2 be on
{ X , Y } and { Y , Z }, respectively. ( X , Y , and Z are disjoint by definition.) Now let ( x , y , z ) be a tuple of r ; then ( x , y ) and
( y , z ) are tuples of r1 and r2 , respectively, and so ( x , y , z ) is a tuple in the join of r1 and r2 . Subsidiary exercise: What
happens to the foregoing proof if the set Y is empty?
3.3 The two purposes (correcting an incorrect design and reducing redundancy) are explained in the body of the
chapter. As for whether you think the point is widely understood: Well, only you can answer this question, but
speaking for myself I have to say I don't think it is.
4.1 The complete set of FDs─what's known, formally, as the closure , though it has nothing to do with the
closure property of the relational algebra─for relvar SP contains a total of 31 FDs. Here they are:
{ SNO , PNO , QTY } { SNO , PNO , QTY }
{ SNO , PNO , QTY } { SNO , PNO }
{ SNO , PNO , QTY } { SNO , QTY }
{ SNO , PNO , QTY } { PNO , QTY }
{ SNO , PNO , QTY } { SNO }
{ SNO , PNO , QTY } { PNO }
{ SNO , PNO , QTY } { QTY }
{ SNO , PNO , QTY } { }
Search WWH ::

Custom Search