Databases Reference

In-Depth Information

but a key, since it's certainly irreducible. What's more, it's the
only
key, because every other subset of the heading

includes it as a proper subset.

4.11 Consider a relvar in the database catalog whose purpose is to record the FDs that hold in various relvars in

the database. Given that an FD is an expression of the form
X
→
Y
where
X
and
Y
are sets of attribute names (see

Chapter 5), a reasonable design for that catalog relvar is one with attributes R (relvar name), X (determinant), and Y

(dependant), and predicate
X
→
Y holds in R
. For any given value of R, then, the values of X and Y are relations of

degree one, whose tuples contain names of attributes of the relvar named R.

For another example, involving a “user relvar” instead of a relvar in the catalog, you might like to think about

the following problem:

I decided to throw a party, so I drew up a list of people I wanted to invite and made some preliminary soundings. The

response was good, but several people made their acceptance conditional on the acceptance of certain other invitees. For

example, Bob and Cal both said they would come if Amy came; Fay said she would come if Don and Eve both came;

Guy said he would come anyway; Hal said he would come if Bob and Amy both came; and so on. Design a database to

show whose acceptance is based on whose. (
With acknowledgments to Hugh Darwen.
)

It seems to me that a reasonable design here would involve a relvar with two attributes X and Y, both relation

valued, and predicate
The set of people X will attend if and only if the set of people Y will attend.
Subsidiary

exercise:
Can you think of any refinements you might want to make to this design? (
Hint:
Is it true that Bob will

attend if and only if Bob will attend?)

4.12 Well, I don't know what you conclude, but I know what I do. One thing I conclude is that we should always

be on our guard against getting seduced by the latest fad. I could say quite a lot more on this subject, but I don't

think this appendix is the appropriate place to do so.

4.13 There are two cases to consider: (a) The relation depicted is a sample value for some relvar
R
; (b) the relation

depicted is a sample value for some relational expression
rx
, where
rx
is something other than a simple relvar

reference (where a relvar reference is basically just the pertinent relvar name). In Case (a), double underlining

simply indicates that a primary key
PK
has been declared for
R
and the pertinent attribute is part of
PK
. In Case (b),

you can think of
rx
as the defining expression for some temporary relvar
R
(think of it as a view defining expression

and
R
as the corresponding view, if you like); then double underlining indicates that a primary key
PK
could in

principle be declared for
R
and the pertinent attribute is part of
PK
.

4.14 I assume for the sake of this exercise and the next that the relation shown in Fig. 4.1 is a sample value for a

relvar SPQ. Here then are
Tutorial D
formulations (not the only ones possible) of the two queries:

a.
( ( SPQ WHERE SNO = 'S2' ) UNGROUP ( PQ ) ) { PNO }

b.
( ( SPQ UNGROUP ( PQ ) ) WHERE PNO = 'P2' ) { SNO }

Observe that the first of these expressions involves a restriction followed by an ungrouping, while the second

involves an ungrouping followed by a restriction (there's the asymmetry).
Note:
The UNGROUP operator hasn't

been discussed prior to this point, but its semantics should be obvious from the foregoing examples. Basically, it's

used to map a relation with an RVA to one without such an attribute. (There's a GROUP operator too, for “going

the other way”─that is, mapping a relation without an RVA to one with one.) For further discussion, see
SQL and

Relational Theory
.