CHAPTER

8
Relational Database Design
This chapter presents the principles of relational database design. Undergradu-
ates frequently find this chapter difficult. It is acceptable to cover only Sections 8.1
and 8.3 for classes that find the material particularly difficult. However, a care-
ful study of data dependencies and normalization is a good way to introduce
students to the formal aspects of relational database theory.
There are many ways of stating the definitions of the normal forms. We have
chosen a style which we think is the easiest to present and which most clearly
conveys the intuition of the normal forms.

Exercises

8.19 Give a lossless-join decomposition into BCNF of schema R of Exercise 8.1.

Answer: From Exercise 8.6, we know that B → D is nontrivial and the
left hand side is not a superkey. By the algorithm of Figure 8.11 we derive
the relations {(A, B, C, E), (B, D)}. This is in BCNF.
8.20 Give a lossless-join, dependency-preserving decomposition into 3NF of
schema R of Practice Exercise 8.1.
Answer: First we note that the dependencies given in Practice Exercise 8.1
form a canonical cover. Generating the schema from the algorithm of Fig-
ure 8.12 we get

R′ = {(A, B, C), (C, D, E), (B, D), (E, A)}.

Schema (A, B, C) contains a candidate key. Therefore R′ is a third normal

form dependency-preserving lossless-join decomposition.
Note that the original schema R = (A, B, C, D, E) is already in 3NF. Thus,
it was not necessary to apply the algorithm as we have done above. The
single original schema is trivially a lossless join, dependency-preserving
decomposition.
67
68 Chapter 8 Relational Database Design

8.21 Normalize the following schema, with given constraints, to 4NF.

books(accessionno, isbn, title, author, publisher)

users(userid, name, deptid, deptname)
accessionno → isbn
isbn → title
isbn → publisher
isbn →→ author
userid → name
userid → deptid
deptid → deptname

Answer: In books, we see that

isbn →→ title, publisher, author

and yet, isbn is not a super key. Thus, we break books into

books accnno(accessionno, isbn)

books details(isbn, title, publisher, author)

After this, we still have

isbn →→ author

but neither is isbn a primary key of book details, nor are the attributes of
book details equal to {isbn} ∪ {author}. Therefore we decompose book details
again into

books details1(isbn, title, publisher)

books authors(isbn, author)

Similarly, in users,

deptid → deptname

and yet, deptid is not a super key. Hence, we break users to

users(userid, name, deptid)

departments(deptid, deptname)
 Exercises 69

We verify that there are no further functional or multivalued dependencies

that cause violation of 4NF, so the final set of relations are:

books accnno(accessionno, isbn)

books details1(isbn, title, publisher)
books authors(isbn, author) users(userid, name, deptid)
departments(deptid, deptname)

8.22 Explain what is meant by repetition of information and inability to repre-

sent information. Explain why each of these properties may indicate a bad
relational-database design.
Answer:

• Repetition of information is a condition in a relational database where

the values of one attribute are determined by the values of another
attribute in the same relation, and both values are repeated throughout
the relation. This is a bad relational database design because it
increases the storage required for the relation and it makes updating
the relation more difficult, and can lead to inconsistent data if updates
are done to one copy of the value, but not to another.
• Inability to represent information is a condition where a relationship
exists among only a proper subset of the attributes in a relation. This is
bad relational database design because all the unrelated attributes
must be filled with null values otherwise a tuple without the unrelated
information cannot be inserted into the relation.
• Inability to represent information can also occur because of loss of
information which results from the decomposition of one relation into
two relations, which cannot be combined to recreate the original
relation. Such a lossy decomposition may happen implicitly, even
without explicitly carrying out decomposition, if the initial relational
schema itself corresponds to the decomposition.

8.23 Why are certain functional dependencies called trivial functional depen-
dencies?
Answer: Certain functional dependencies are called trivial functional
dependencies because they are satisfied by all relations.
8.24 Use the definition of functional dependency to argue that each of Arm-
strong’s axioms (reflexivity, augmentation, and transitivity) is sound.
Answer: The definition of functional dependency is: a → b holds on R
if in any legal relation r (R), for all pairs of tuples t1 and t2 in r such that
t1 [a] = t2 [a], it is also the case that t1 [b] = t2 [b].
70 Chapter 8 Relational Database Design

Reflexivity rule: if a is a set of attributes, and b ⊆ a, then a → b.

Assume ∃ t1 and t2 such that t1 [a] = t2 [a]

t1 [b] = t2 [b] since b ⊆ a

a → b definition of FD
Augmentation rule: if a → b, and g is a set of attributes, then g a → g b.
Assume ∃ t1 , t2 such that t1 [g a] = t2 [g a]

t1 [g ] = t2 [g ] g ⊆ ga
t1 [a] = t2 [a] a ⊆ ga
t1 [b] = t2 [b] definition of a → b
t1 [g b] = t2 [g b] gb = g ∪ b
ga → gb definition of FD
Transitivity rule: if a → b and b → g , then a → g .
Assume ∃ t1 , t2 such that t1 [a] = t2 [a]

t1 [b] = t2 [b] definition of a → b

t1 [g ] = t2 [g ] definition of b → g
a → g definition of FD
8.25 Consider the following proposed rule for functional dependencies: If a →
b and g → b, then a → g . Prove that this rule is not sound by showing a
relation r that satisfies a → b and g → b, but does not satisfy a → g .
Answer: Consider the following rule: if A → B and C → B, then
A → C. That is, a = A, b = B, g = C. The following relation r is a
counterexample to the rule.
r: A B C
a1 b1 c1
a1 b1 c2
Note: A → B and C → B, (since no 2 tuples have the same C value,
C → B is true trivially). However, it is not the case that A → C since the
same A value is in two tuples, but the C value in those tuples disagree.
8.26 Use Armstrong’s axioms to prove the soundness of the decomposition rule.
Answer: The decomposition rule, and its derivation from Armstrong’s
axioms are given below:
if a → bg , then a → b and a → g .

a → bg given
bg → b reflexivity rule
a → b transitivity rule
bg → g reflexive rule
a → g transitive rule
8.27 Using the functional dependencies of Practice Exercise 8.6, compute B + .
 Exercises 71

Answer: Computing B + by the algorithm in Figure 8.8 we start with

r esult = {B}. Considering FDs of the form b → g in F , we find that
the only dependencies satisfying b ⊆ r esult are B → B and B → D.
Therefore r esult = {B, D}. No more dependencies in F apply now.
Therefore B + = {B, D}
8.28 Show that the following decomposition of the schema R of Practice Exercise
8.1 is not a lossless-join decomposition:

(A, B, C)
(C, D, E).

Hint: Give an example of a relation r on schema R such that

5 A, B, C (r ) 1 5C, D, E (r ) 6= r

Answer: Following the hint, use the following example of r :

A B C D E
a1 b1 c1 d1 e1
a2 b2 c1 d2 e2
With R1 = (A, B, C), R2 = (C, D, E) :

a. 5 R1 (r ) would be:
A B C
a1 b1 c1
a2 b2 c1

b. 5 R2 (r ) would be:
C D E
c1 d1 e1
c1 d2 e2

c. 5 R1 (r ) 1 5 R2 (r ) would be:
A B C D E
a1 b1 c1 d1 e1
a1 b1 c1 d2 e2
a2 b2 c1 d1 e1
a2 b2 c1 d2 e2

Clearly, 5 R1 (r ) 1 5 R2 (r ) 6= r . Therefore, this is a lossy join.

72 Chapter 8 Relational Database Design

8.29 Consider the following set F of functional dependencies on the relation

schema r (A, B, C, D, E, F ):

A → BCD
BC → DE
B→D
D→A

a. Compute B + .
b. Prove (using Armstrong’s axioms) that AF is a superkey.
c. Compute a canonical cover for the above set of functional depen-
dencies F ; give each step of your derivation with an explanation.
d. Give a 3NF decomposition of r based on the canonical cover.
e. Give a BCNF decomposition of r using the original set of functional
dependencies.
f. Can you get the same BCNF decomposition of r as above, using the
canonical cover?
Answer:
a. B → BD (third dependency)
BD → ABD (fourth dependency)
ABD → ABCD (first dependency)
ABCD → ABCDE (second dependency)
+
Thus, B = ABCDE
b. Prove (using Armstrong’s axioms) that AF is a superkey.
A → BCD (Given)
A → ABCD (Augmentation with A)
BC → DE (Given)
ABCD → ABCDE (Augmentation with ABCD)
A → ABCDE (Transitivity)
AF → ABCDEF (Augmentation with F)

c. We see that D is extraneous in dep. 1 and 2, because of dep. 3.

Removing these two, we get the new set of rules
A → BC
BC → E
B→D
D→A
Now notice that B + is ABCDE, and in particular, the FD B → E can
be determined from this set. Thus, the attribute C is extraneous in
 Exercises 73

the third dependency. Removing this attribute, and combining with

the third FD, we get the final canonical cover as :
A → BC
B → DE
D→A
Here, no attribute is extraneous in any FD.
d. We see that there is no FD in the canonical cover such that the set of
attributes is a subset of any other FD in the canonical cover. Thus,
each each FD gives rise to its own relation, giving
r1 (A, B, C)
r2 (B, D, E)
r3 (D, A)
Now the attribute F is not dependent on any attribute. Thus, it must
be a part of every superkey. Also, none of the relations in the above
schema have F, and hence, none of them have a superkey. Thus, we
need to add a new relation with a superkey.
r4 (A, F)

e. We start with
r(A, B, C, D, E, F)
We see that the relation is not in BCNF because of the first FD. Hence,
we decompose it accordingly to get
r1 (A, B, C, D) r2 (A, E, F)
Now we notice that A → E is an FD in F + , and causes r2 to violate
BCNF. Once again, decomposing r2 gives

r1 (A, B, C, D) r2 (A, F) r3 (A, E)

This schema is now in BCNF.
f. Can you get the same BCNF decomposition of r as above, using the
canonical cover?
If we use the functional dependencies in the preceding canonical
cover directly, we cannot get the above decomposition. However,
we can infer the original dependencies from the canonical cover,
and if we use those for BCNF decomposition, we would be able to
get the same decomposition.
8.30 List the three design goals for relational databases, and explain why each
is desirable.
Answer: The three design goals are lossless-join decompositions, de-
pendency preserving decompositions, and minimization of repetition of
74 Chapter 8 Relational Database Design

information. They are desirable so we can maintain an accurate database,

check correctness of updates quickly, and use the smallest amount of space
possible.
8.31 In designing a relational database, why might we choose a non-BCNF de-
sign?
Answer: BCNF is not always dependency preserving. Therefore, we may
want to choose another normal form (specifically, 3NF) in order to make
checking dependencies easier during updates. This would avoid joins to
check dependencies and increase system performance.
8.32 Given the three goals of relational-database design, is there any reason to
design a database schema that is in 2NF, but is in no higher-order normal
form? (See Practice Exercise 8.17 for the definition of 2NF.)
Answer: The three design goals of relational databases are to avoid

• Repetition of information
• Inability to represent information
• Loss of information.

2NF does not prohibit as much repetition of information since the schema
(A, B, C) with dependencies A → B and B → C is allowed under 2NF,
although the same (B, C) pair could be associated with many A values,
needlessly duplicating C values. To avoid this we must go to 3NF. Repetition
of information is allowed in 3NF in some but not all of the cases where it
is allowed in 2NF. Thus, in general, 3NF reduces repetition of information.
Since we can always achieve a lossless join 3NF decomposition, there is no
loss of information needed in going from 2NF to 3NF.
Note that the decomposition {(A, B), (B, C)} is a dependency-preserving
and lossless-loin 3NF decomposition of the schema (A, B, C). However,
in case we choose this decomposition, retrieving information about the
relationship between A, B and C requires a join of two relations, which is
avoided in the corresponding 2NF decomposition.
Thus, the decision of which normal form to choose depends upon how the
cost of dependency checking compares with the cost of the joins. Usually,
the 3NF would be preferred. Dependency checks need to be made with
every insert or update to the instances of a 2NF schema, whereas, only some
queries will require the join of instances of a 3NF schema.
8.33 Given a relational schema r (A, B, C, D), does A →→ BC logically imply
A →→ B and A →→ C? If yes prove it, else give a counter example.
Answer: A →→ BC holds on the following table:
 Exercises 75

r: A B C D
a1 b1 c1 d1
a1 b2 c2 d2
a1 b1 c1 d2
a1 b2 c2 d1
If A →→ B, then we know that there exists t1 and t3 such that t1 [B] = t3 [B].
Thus, we must choose one of the following for t1 and t3 :
• t1 = r1 and t3 = r3 , or t1 = r3 and t3 = r1 :
Choosing either t2 = r2 or t2 = r4 , t3 [C] 6= t2 [C].
• t1 = r2 and t3 = r4 , or t1 = r4 and t3 = r2 :
Choosing either t2 = r1 or t2 = r3 , t3 [C] 6= t2 [C].
Therefore, the condition t3 [C] = t2 [C] can not be satisfied, so the conjecture
is false.
8.34 Explain why 4NF is a normal form more desirable than BCNF.
Answer: 4NF is more desirable than BCNF because it reduces the repeti-
tion of information. If we consider a BCNF schema not in 4NF (see Practice
Exercise 7.16), we observe that decomposition into 4NF does not lose infor-
mation provided that a lossless join decomposition is used, yet redundancy
is reduced.