70 Chapter 5

7. Find the managerids of managers who control the largest amounts.

8. Find the enames of managers who manage only departments with budgets larger
than $1 million, but at least one department with budget less than $5 million.

Answer 5.4 The answers are given below:

1. SELECT E.ename, E.age

FROM Emp E, Works W1, Works W2, Dept D1, Dept D2
WHERE E.eid = W1.eid AND W1.did = D1.did AND D1.dname = ‘Hardware’ AND
E.eid = W2.eid AND W2.did = D2.did AND D2.dname = ‘Software’

2. SELECT W.did, COUNT (W.eid)

FROM Works W
GROUP BY W.did
HAVING 2000 < ( SELECT SUM (W1.pct time)
FROM Works W1
WHERE W1.did = W.did )

3. SELECT E.ename
FROM Emp E
WHERE E.salary > ALL (SELECT D.budget
FROM Dept D, Works W
WHERE E.eid = W.eid AND D.did = W.did)

4. SELECT DISTINCT D.managerid

FROM Dept D
WHERE 1000000 < ALL (SELECT D2.budget
FROM Dept D2
WHERE D2.managerid = D.managerid )

5. SELECT E.ename
FROM Emp E
WHERE E.eid IN (SELECT D.managerid
FROM Dept D
WHERE D.budget = (SELECT MAX (D2.budget)
FROM Dept D2))

6. SELECT D.managerid
FROM Dept D
WHERE 5000000 < (SELECT SUM (D2.budget)
FROM Dept D2
WHERE D2.managerid = D.managerid )
SQL: Queries, Constraints, Triggers 71

sid sname rating age

18 jones 3 30.0
41 jonah 6 56.0
22 ahab 7 44.0
63 moby null 15.0

Figure 5.1 An Instance of Sailors

7. SELECT DISTINCT tempD.managerid

FROM (SELECT DISTINCT D.managerid, SUM (D.budget) AS tempBudget
FROM Dept D
GROUP BY D.managerid ) AS tempD
WHERE tempD.tempBudget = (SELECT MAX (tempD.tempBudget)
FROM tempD)

8. SELECT E.ename
FROM Emp E, Dept D
WHERE E.eid = D.managerid GROUP BY E.Eid, E.ename
HAVING EVERY (D.budget > 1000000) AND ANY (D.budget < 5000000)

Exercise 5.5 Consider the instance of the Sailors relation shown in Figure 5.1.

1. Write SQL queries to compute the average rating, using AVG; the sum of the
ratings, using SUM; and the number of ratings, using COUNT.

2. If you divide the sum just computed by the count, would the result be the same
as the average? How would your answer change if these steps were carried out
with respect to the age field instead of rating?

3. Consider the following query: Find the names of sailors with a higher rating than
all sailors with age < 21. The following two SQL queries attempt to obtain the
answer to this question. Do they both compute the result? If not, explain why.
Under what conditions would they compute the same result?

SELECT S.sname
FROM Sailors S
WHERE NOT EXISTS ( SELECT *
FROM Sailors S2
WHERE S2.age < 21
AND S.rating <= S2.rating )
SELECT *
FROM Sailors S
SQL: Queries, Constraints, Triggers 83

PRIMARY KEY (snum, cname),

FOREIGN KEY (snum) REFERENCES Student),
FOREIGN KEY (cname) REFERENCES Class,),
CHECK (( SELECT COUNT (E.snum)
FROM Enrolled E
GROUP BY E.cname) >= 5),
CHECK (( SELECT COUNT (E.snum)
FROM Enrolled E
GROUP BY E.cname) <= 30))
(b) This constraint is already guaranteed because rooms are associated with
classes, and thus a new room cannot be declared without an associated class
in it.
(c) Create an assertion as follows:
CREATE ASSERTION TeachTwo
CHECK ( ( SELECT COUNT (*)
FROM Facult F, Class C
WHERE F.fid = C.fid
GROUP BY C.fid
HAVING COUNT (*) < 2) = 0)

(d) Create an assertion as follows:

CREATE ASSERTION NoTeachThree
CHECK ( ( SELECT COUNT (*)
FROM Facult F, Class C
WHERE F.fid = C.fid AND F.deptid 6= 33
GROUP BY C.fid
HAVING COUNT (*) > 3) = 0)

(e) Create an assertion as follows:

CREATE ASSERTION InMath101
CHECK (( SELECT COUNT (*)
FROM Student S
WHERE S.snum NOT IN ( SELECT E.snum
FROM Enrolled E
WHERE E.cname = ’Math101’)) = 0)
(f) The Class table should be modified as follows:
CREATE TABLE Class ( name CHAR(20),
meets at TIME,
room CHAR(10),
fid INTEGER,
84 Chapter 5

PRIMARY KEY (name),

FOREIGN KEY (fid) REFERENCES Faculty),
CHECK ( (SELECT MIN (meets at)
FROM Class) <>
(SELECT MAX (meets at)
FROM Class)))
(g) The Class table should be modified as follows:
CREATE TABLE Class ( name CHAR(20),
meets at TIME,
room CHAR(10),
fid INTEGER,
PRIMARY KEY (name),
FOREIGN KEY (fid) REFERENCES Faculty),
CHECK ((SELECT COUNT (*)
FROM ( SELECT C.room, C.meets
FROM Class C
GROUP BY C.room, C.meets
HAVING COUNT (*) > 1)) = 0))
(h) The Faculty table should be modified as follows:
CREATE TABLE Faculty ( fid INTEGER,
fname CHAR(20),
deptid INTEGER,
PRIMARY KEY (fnum),
CHECK ( (SELECT MAX (*)
FROM ( SELECT COUNT (*)
FROM Faculty F
GROUP BY F.deptid))
<2*
(SELECT MIN (*)
FROM ( SELECT COUNT (*)
FROM Faculty F
GROUP BY F.deptid))))
(i) The Faculty table should be modified as follows:
CREATE TABLE Faculty (fid INTEGER,
fname CHAR(20),
deptid INTEGER,
PRIMARY KEY (fnum),
CHECK ( ( SELECT COUNT (*)
FROM Faculty F
GROUP BY F.deptid
HAVING COUNT (*) > 10) = 0))
Schema Refinement and Normal Forms 263

(c) Both B → C and D → A cause BCNF violations. The decomposition: AD,

BC, BD (obtained by first decomposing to AD, BCD) is BCNF and lossless
and join-preserving.

3. (a) Candidate keys: ABC, BCD

(b) R is in 3NF but not BCNF.
(c) ABCD is not in BCNF since D → A and D is not a key. However if we split
up R as AD, BCD we cannot preserve the dependency ABC → D. So there
is no BCNF decomposition.

4. (a) Candidate keys: A

(b) R is in 2NF but not 3NF (because of the FD: BC → D).
(c) BC → D violates BCNF since BC does not contain a key. So we split up R
as in: BCD, ABC.

5. (a) Candidate keys: AB, BC, CD, AD

(b) R is in 3NF but not BCNF (because of the FD: C → A).
(c) C → A and D → B both cause violations. So decompose into: AC, BCD
but this does not preserve AB → C and AB → D, and BCD is still not
BCNF because D → B. So we need to decompose further into: AC, BD,
CD. However, when we attempt to revive the lost functioanl dependencies
by adding ABC and ABD, we that these relations are not in BCNF form.
Therefore, there is no BCNF decomposition.

Exercise 19.8 Consider the attribute set R = ABCDEGH and the FD set F = {AB →
C, AC → B, AD → E, B → D, BC → A, E → G}.

1. For each of the following attribute sets, do the following: (i) Compute the set of
dependencies that hold over the set and write down a minimal cover. (ii) Name
the strongest normal form that is not violated by the relation containing these
attributes. (iii) Decompose it into a collection of BCNF relations if it is not in
BCNF.

(a) ABC, (b) ABCD, (c) ABCEG, (d) DCEGH, (e) ACEH

2. Which of the following decompositions of R = ABCDEG, with the same set of

dependencies F , is (a) dependency-preserving? (b) lossless-join?

(a) {AB, BC, ABDE, EG }

(b) {ABC, ACDE, ADG }

Answer 19.8

1. (a) i. R1 = ABC: The FD’s are AB → C, AC → B, BC → A.

264 Chapter 19

ii. This is already a minimal cover.

iii. This is in BCNF since AB, AC and BC are candidate keys for R1. (In
fact, these are all the candidate keys for R1).
(b) i. R2 = ABCD: The FD’s are AB → C, AC → B, B → D, BC → A.
ii. This is a minimal cover already.
iii. The keys are: AB, AC, BC. R2 is not in BCNF or even 2NF because of
the FD, B → D (B is a proper subset of a key!) However, it is in 1NF.
Decompose as in: ABC, BD. This is a BCNF decomposition.
(c) i. R3 = ABCEG; The FDs are AB → C, AC → B, BC → A, E → G.
ii. This is in minimal cover already.
iii. The keys are: ABE, ACE, BCE. It is not even in 2NF since E is a proper
subset of the keys and there is a FD E → G. It is in 1NF . Decompose
as in: ABE, ABC, EG. This is a BCNF decompostion.
(d) i. R4 = DCEGH; The FD is E → G.
ii. This is in minimal cover already.
iii. The key is DCEH ; It is not in BCNF since in the FD E → G, E is a
subset of the key and is not in 2NF either. It is in 1 NF Decompose as
in: DCEH, EG
(e) i. R5 = ACEH; No FDs exist.
ii. This is a minimal cover.
iii. Key is ACEH itself.
iv. It is in BCNF form.

2. (a) The decomposition. { AB, BC, ABDE, EG } is not lossless. To prove this
consider the following instance of R:
{(a1 , b, c1 , d1 , e1 , g1 ), (a2 , b, c2 , d2 , e2 , g2 )}
Because of the functional dependencies BC → A and AB → C, a1 6= a2 if
and only if c1 6= c2 . It is easy to that the join AB ⊲⊳ BC contains 4 tuples:
{(a1 , b, c1 ), (a1 , b, c2 ), (a2 , b, c1 ), (a2 , b, c2 )}
So the join of AB, BC, ABDE and EG will contain at least 4 tuples, (actually
it contains 8 tuples) so we have a lossy decomposition here.

This decomposition does not preserve the FD, AB → C (or AC → B)

(b) The decomposition {ABC, ACDE, ADG } is lossless. Intuitively, this is
because the join of ABC, ACDE and ADG can be constructed in two steps;
first construct the join of ABC and ACDE: this is lossless because their
(attribute) intersection is AC which is a key for ABCDE (in fact ABCDEG)
so this is lossless. Now join this intermediate join with ADG. This is also
lossless because the attribute intersection is is AD and AD → ADG. So by
the test mentioned in the text this step is also a lossless decomposition.
266 Chapter 19

5. A → B, B → C, C → D; decompose into AB, AD and CD.

Answer 19.10

1. Candidate key(s): BD. The decomposition into BC and AD is unsatisfactory

because it is lossy (the join of BC and AD is the cartesian product which could
be much bigger than ABCD)

2. Candidate key(s): AB, BC. The decomposition into ACD and BC is lossless since
ACD ∩ BC (which is C) → ACD. The projection of the FD’s on ACD include C
→ D, C → A (so C is a key for ACD) and the projection of FD on BC produces
no nontrivial dependencies. In particular this is a BCNF decomposition (check
that R is not!). However, it is not dependency preserving since the dependency
AB → C is not preserved. So to enforce preservation of this dependency (if we
do not want to use a join) we need to add ABC which introduces redundancy. So
implicitly there is some redundancy across relations (although none inside ACD
and BC).

3. Candidate key(s): A, C. Since A and C are both candidate keys for R, it is already
in BCNF. So from a normalization standpoint it makes no sense to decompose R.
Further more, the decompose is not dependency-preserving since C → AD can no
longer be enforced.

4. Candidate key(s): A. The projection of the dependencies on AB are: A → B and

those on ACD are: A → C and C → D (rest follow from these). The scheme ACD
is not even in 3NF, since C is not a superkey, and D is not part of a key. This is
a lossless-join decomposition (since A is a key), but not dependency preserving,
since B → C is not preserved.

5. Candidate key(s): A (just as before) This is a lossless BCNF decomposition (easy

to check!) This is, however, not dependency preserving (B consider → C). So
it is not free of (implied) redundancy. This is not the best decomposition ( the
decomposition AB, BC, CD is better.)

Exercise 19.11 Consider a relation R that has three attributes ABC. It is decom-
posed into relations R1 with attributes AB and R2 with attributes BC.

1. State the definition of a lossless-join decomposition with respect to this example.

Answer this question concisely by writing a relational algebra equation involving
R, R1 , and R2 .

2. Suppose that B → C. Is the decomposition of R into R1 and R2 lossless-join?

Reconcile your answer with the observation that neither of the FDs R1 ∩ R2 →
R1 nor R1 ∩ R2 → R2 hold, in light of the simple test offering a necessary and
sufficient condition for lossless-join decomposition into two relations in Section
15.6.1.
276 Chapter 19

Exercise 19.28 Give an algorithm for testing whether a relation scheme is in BCNF.
The algorithm should be polynomial in the size of the set of given FDs. (The ‘size’ is
the sum over all FDs of the number of attributes that appear in the FD.) Is there a
polynomial algorithm for testing whether a relation scheme is in 3NF?

Answer 19.28 Incorrect question listed in the textbook. Please see solution to Ex-
ercise 19.27.

Exercise 19.29 Prove that the algorithm for decomposing a relation schema with a
set of FDs into a collection of BCNF relation schemas as described in Section 19.6.1
is correct (i.e., it produces a collection of BCNF relations, and is lossless-join) and
terminates.

Answer 19.29 First, we will repeat the algorithm so as to keep consistent notation:

1. Let X ⊂ R, A be a single atribute in R and X → A be a FD that causes a violation

of BCNF. Decompose into R − A and XA.

2. If either R − A or XA is not in BCNF, decompose them further by a recursive

application of this algorithm.

Proving the correctness of the algorithm is divided into 3 parts:

Proof that every Decomposition is Lossless:

For any decomposition of a relation R into R − A and XA that the algorithm
takes, it is trivially loseless by Thoerem 3 of this chapter. First, we claim that
T
(R − A) (XA) = X since: X ⊂ R by construction, and A is not in X (else
it would be a trivially functional dependency and not violate BCNF, which is
a contradiction). The given functional dependency X → A then implies X →
T
XA by the Union Rule, therefore (R − A) (XA) → XA and by Thoerem 3,
this decomposition is loseless. Note however, that this decomposition may not be
dependency preserving.

Proof that Algorithm Terminates:

Every decomposition of a Relation R that the algorithm performs produces rela-
tions R − A and XA with strictly fewer attributes then R. R − A has strictly
fewer attributes than R since by construction A is not null, and since the func-
tional dependency violates BCNF also by construction, A must be contained in
R, else the functional dependency would not be applicable to R. Further, XA has
strictly fewer attributes than R since by construction X ⊂ R and XA 6= R. This is
clear since if we assume that XA = R, then we can conclude that X is a superkey
because XA → R trivially and X → A, so that X → R from Transivitivty. This
Schema Refinement and Normal Forms 277

would contradict the assumption that the functional dependency violates BCNF,
leaving us to conclude that XA 6= R.

If we let n denote the number of attributes in the original relation R, then there
are at most (2n − 1) decompositions the algorithm will perform before it termi-
nates. Once a relation contains just a single attribute, it is in BCNF and cannot
be decomposed further since there are no non-trivial functional dependencies we
can apply to it that would violate BCNF.

Proof that every Relation in Final Set is in BCNF:

As discussed in the previous part of the problem, in the worst case the algorithm
decomposes R into a set of n unique single attribute relations where n is the number
of attributes in the original relation R. As also discussed above, each relation
is clearly in BCNF. The decomposition process may, and in most cases should,
terminate before we are down to all single attribute relations but irregardless, the
algorithm will only stop when all subsets of R are in BCNF.