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.

CHAPTER 3

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.

CHAPTER 4

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 }
→
{ }