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 .
Search WWH ::

Custom Search