 Database Systems: The Complete
Book
 Solutions for Chapter 3 

Solutions for Section 3.1
Solutions for Section 3.2
Solutions for Section 3.3
Solutions for Section 3.4
Solutions for Section 3.5
Solutions for Section 3.6
Solutions for Section 3.7
Solutions for Section 3.1
Exercise 3.1.2(a)
We can order the three tuples in any of 3! = 6 ways.
Also, the columns can be ordered in any of 3! = 6 ways.
Thus, the number of presentations is 6*6 = 36.
Return to Top
Solutions for Section 3.2
Exercise 3.2.1
Customers(ssNo, name, address, phone)
Flights(number, day, aircraft)
Bookings(ssNo, number, day, row, seat)
Being a weak entity set, Bookings' relation has the keys for Customers
and Flights and Bookings' own attributes.
Notice that the relations obtained from the toCust
and
toFlt
relationships are unnecessary.
They are:
toCust(ssNo, ssNo1, number, day)
toFlt(ssNo, number, day, number1, day1)
That is, for toCust, the key of Customers is paired with the key for
Bookings.
Since both include ssNo
, this attribute is repeated with
two different names, ssNo and ssNo1.
A similar situation exists for toFlt.
Exercise 3.2.3
Ships(name, yearLaunched)
SisterOf(name, sisterName)
Return to Top
Solutions for Section 3.3
Exercise 3.3.1
Since Courses is weak, its key is number and the
name of its department.
We do not have a relation for GivenBy.
In part (a), there is a relation for Courses and a relation for
LabCourses that has only the key and the computerallocation
attribute.
It looks like:
Depts(name, chair)
Courses(number, deptName, room)
LabCourses(number, deptName, allocation)
For part (b), LabCourses gets all the attributes of
Courses, as:
Depts(name, chair)
Courses(number, deptName, room)
LabCourses(number, deptName, room, allocation)
And for (c), Courses and LabCourses are combined, as:
Depts(name, chair)
Courses(number, deptName, room, allocation)
Exercise 3.3.4(a)
There is one relation for each entity set, so the number of relations is
e.
The relation for the root entity set has a attributes, while the
other relations, which must include the key attributes, have a+k
attributes.
Return to Top
Solutions for Section 3.4
Exercise 3.4.2
Surely ID is a key by itself.
However, we think that the attributes x, y, and z together form another
key.
The reason is that at no time can two molecules occupy the same point.
Exercise 3.4.4
The key attributes are indicated by capitalization in the schema below:
Customers(SSNO, name, address, phone)
Flights(NUMBER, DAY, aircraft)
Bookings(SSNO, NUMBER, DAY, row, seat)
Exercise 3.4.6(a)
The superkeys are any subset that contains A1.
Thus, there are 2^{n1} such subsets, since each of the n1 attributes
A2 through An may independently be chosen in or out.
Return to Top
Solutions for Section 3.5
Exercise 3.5.1(a)
We could try inference rules to deduce new dependencies until we are
satisfied we have them all.
A more systematic way is to consider the closures of all 15 nonempty
sets of attributes.
For the single attributes we have A+ = A, B+ = B, C+ = ACD, and D+ = AD.
Thus, the only new dependency we get with a single attribute on the left
is C>A.
Now consider pairs of attributes:
AB+ = ABCD, so we get new dependency AB>D.
AC+ = ACD, and AC>D is nontrivial.
AD+ = AD, so nothing new.
BC+ = ABCD, so we get BC>A, and BC>D.
BD+ = ABCD, giving us BD>A and BD>C.
CD+ = ACD, giving CD>A.
For the triples of attributes, ACD+ = ACD, but the closures of the other
sets are each ABCD.
Thus, we get new dependencies ABC>D, ABD>C, and BCD>A.
Since ABCD+ = ABCD, we get no new dependencies.
The collection of 11 new dependencies mentioned above is:
C>A, AB>D, AC>D, BC>A, BC>D, BD>A, BD>C, CD>A, ABC>D, ABD>C,
and BCD>A.
Exercise 3.5.1(b)
From the analysis of closures above, we find that AB, BC, and BD are
keys.
All other sets either do not have ABCD as the closure or contain one of
these three sets.
Exercise 3.5.1(c)
The superkeys are all those that contain one of those three keys.
That is, a superkey that is not a key must contain B and more than one
of A, C, and D.
Thus, the (proper) superkeys are ABC, ABD, BCD, and ABCD.
Exercise 3.5.3(a)
We must compute the closure of A1A2...AnC.
Since A1A2...An>B is a dependency, surely B is in this set, proving
A1A2...AnC>B.
Exercise 3.5.4(a)
Consider the relation
This relation satisfies A>B but does not satisfy B>A.
Exercise 3.5.8(a)
If all sets of attributes are closed, then there cannot be any
nontrivial functional dependencies.
For suppose A1A2...An>B is a nontrivial dependency.
Then A1A2...An+ contains B and thus A1A2...An is not closed.
Exercise 3.5.10(a)
We need to compute the closures of all subsets of {ABC}, although there
is no need to think about the empty set or the set of all three
attributes.
Here are the calculations for the remaining six sets:
 A+ = A
 B+ = B
 C+ = ACE
 AB+ = ABCDE
 AC+ = ACE
 BC+ = ABCDE
We ignore D and E, so a basis for
the resulting functional dependencies for ABC are:
C>A and AB>C.
Note that BC>A is true, but follows logically from C>A, and therefore
may be omitted from our list.
Return to Top
Solutions for Section 3.6
Exercise 3.6.1(a)
In the solution to Exercise 3.5.1 we found that there are 14 nontrivial
dependencies, including the three given ones and 11 derived
dependencies.
These are:
C>A, C>D, D>A, AB>D, AB> C,
AC>D, BC>A, BC>D, BD>A, BD>C, CD>A, ABC>D, ABD>C,
and BCD>A.
We also learned that the three keys were AB, BC, and BD.
Thus, any dependency above that does not have one of these pairs on the
left is a BCNF violation.
These are:
C>A, C>D, D>A, AC>D, and CD>A.
One choice is to decompose using C>D.
That gives us ABC and CD as decomposed relations.
CD is surely in BCNF, since any twoattribute relation is.
ABC is not in BCNF, since AB and BC are its only keys, but C>A is a
dependency that holds in ABCD and therefore holds in ABC.
We must further decompose ABC into AC and BC.
Thus, the three relations of the decomposition are AC, BC, and CD.
Since all attributes are in at least one key of ABCD, that relation is
already in 3NF, and no decomposition is necessary.
Exercise 3.6.1(b)
(Revised 1/19/02)
The only key is AB.
Thus, B>C and B>D are both BCNF violations.
The derived FD's BD>C and BC>D are also BCNF violations.
However, any other nontrivial, derived FD will have A and B on the left,
and therefore will contain a key.
One possible BCNF decomposition is AB and BCD.
It is obtained starting with any of the four violations mentioned
above.
AB is the only key for AB, and B is the only key for BCD.
Since there is only one key for ABCD, the 3NF violations are the same,
and so is the decomposition.
Return to Top
Solutions for Section 3.7
Exercise 3.7.1
Since A>>B, and all the tuples have the same value for attribute A, we
can pair the Bvalue from any tuple with the value of the remaining
attribute C from any other tuple.
Thus, we know that R must have at least the nine tuples of the form
(a,b,c), where b is any of b1, b2, or b3, and c is any of c1, c2, or
c3.
That is, we can derive, using the definition of a multivalued
dependency, that each of the tuples (a,b1,c2), (a,b1,c3), (a,b2,c1),
(a,b2,c3), (a,b3,c1), and (a,b3,c2) are also in R.
Exercise 3.7.2(a)
First, people have unique Social Security numbers and unique birthdates.
Thus, we expect the functional dependencies ssNo>name and
ssNo>birthdate hold.
The same applies to children, so we expect childSSNo>childname and
childSSNo>childBirthdate.
Finally, an automobile has a unique brand, so we expect
autoSerialNo>autoMake.
There are two multivalued dependencies that do not follow from these
functional dependencies.
First, the information about one child of a person is independent of
other information about that person.
That is, if a person with social security number
s has a tuple with cn,cs,cb, then if
there is any
other tuple t for the same person, there will also
be another tuple that agrees with t except that it has
cn,cs,cb in its components for the child name, Social Security
number, and birthdate.
That is the multivalued dependency
ssNo>>childSSNo childName childBirthdate
Similarly, an automobile serial number and make are independent of any
of the other attributes, so we expect the multivalued dependency
ssNo>>autoSerialNo autoMake
The dependencies are summarized below:
ssNo > name birthdate
childSSNo > childName childBirthdate
autoSerialNo > autoMake
ssNo >> childSSNo childName childBirthdate
ssNo >> autoSerialNo autoMake
Exercise 3.7.2(b)
We suggest the relation schemas
{ssNo, name, birthdate}
{ssNo, childSSNo}
{childSSNo, childName childBirthdate}
{ssNo, autoSerialNo}
{autoSerialNo, autoMake}
An initial decomposition based on the two multivalued dependencies would
give us
{ssNo, name, birthDate}
{ssNo, childSSNo, childName, childBirthdate}
{ssNo, autoSerialNo, autoMake}
Functional dependencies force us to decompose the second and third of
these.
Exercise 3.7.3(a)
Since there are no functional dependencies, the only key is all four
attributes, ABCD.
Thus, each of the nontrvial multivalued dependencies A>>B and A>>C
violate 4NF.
We must separate out the attributes of these dependencies, first
decomposing into AB and ACD, and then decomposing the latter into AC and
AD because A>>C is still a 4NF violation for ACD.
The final set of relations are AB, AC, and AD.
Exercise 3.7.7(a)
Let W be the set of attributes not in X, Y, or Z.
Consider two tuples xyzw and xy'z'w' in the relation R in question.
Because X >> Y, we can swap the y's, so xy'zw and xyz'w' are in R.
Because X >> Z, we can take the pair of tuples xyzw and xyz'w' and swap
Z's to get xyz'w and xyzw'.
Similarly, we can take the pair xy'z'w' and xy'zw and swap Z's to get
xy'zw' and xy'z'w.
In conclusion, we started with tuples xyzw and xy'z'w' and showed that
xyzw' and xy'z'w must also be in the relation.
That is exactly the statement of the MVD X >> YunionZ.
Note that the above statements all make sense even if there are attributes in
common among X, Y, and Z.
Exercise 3.7.8(a)
Consider a relation R with schema ABCD and the instance
with four tuples abcd, abcd', ab'c'd, and ab'c'd'.
This instance satisfies the MVD A >> BC.
However, it does not satisfy A >> B.
For example, if it did satisfy A >> B, then because the instance
contains the tuples abcd and ab'c'd, we would expect it to contain abc'd
and ab'cd, neither of which is in the instance.
Return to Top