Chapter 7: Relational Database Design

Database System Concepts, 5th Ed.

©Silberschatz, Korth and Sudarshan
See www.db-book.com for conditions on re-use
 First Normal Form
 Domain is atomic if its elements are considered to be indivisible units
 Examples of non-atomic domains:
 Set of names, composite attributes
 Identification numbers like CS101 that can be broken up into
parts
 A relational schema R is in first normal form if the domains of all
attributes of R are atomic
 Non-atomic values complicate storage and encourage redundant
(repeated) storage of data
 Example: Set of accounts stored with each customer, and set of
owners stored with each account
 We assume all relations are in first normal form (and revisit this in
Chapter 9)

Database System Concepts - 5th Edition, July 28, 2005. 7.2 ©Silberschatz, Korth and Sudarshan
 First Normal Form (Cont’d)
 Example
 SupplierPart (S#, P#, status, city, Qty.)
 S#,p#  Qty
 S# city
 city  status
 S#status
 Insertion anomalies
 Can’t insert information about supplier until supplier supplies certain part
 Deletion anomalies
 If we delete first tuple of supplier we not only delete shipment information but
also information about supplier
 Updation anomalies
 The city value for a particular supplier appears many times and hence can lead
to inconsistency while updation

Database System Concepts - 5th Edition, July 28, 2005. 7.3 ©Silberschatz, Korth and Sudarshan
 Functional Dependencies
 Constraints on the set of legal relations.
 Require that the value for a certain set of attributes determines
uniquely the value for another set of attributes.
 Let R be a relation schema
  R and   R
 The functional dependency

holds on R if and only if for any legal relations r(R), whenever any two
tuples t1 and t2 of r agree on the attributes , they also agree on the
attributes . That is,
t1[] = t2 []  t1[ ] = t2 [ ]

Database System Concepts - 5th Edition, July 28, 2005. 7.4 ©Silberschatz, Korth and Sudarshan
 Functional Dependencies (Cont.)
 Example1: 1 4
 Consider r(A,B ) with the following instance of r. 1 5
 On this instance, A  B does NOT hold, but B  A does hold. 3 7
 Example2:
 Consider r(A,B,C,D ) with the following instance of r.
 On this instance, A  C hold, but C  A does NOT hold.

A B C D
a1 b1 c1 d1
a1 b2 c1 d2
a2 b2 c2 d2
a2 b3 c2 d3
a3 b3 c2 d4

Database System Concepts - 5th Edition, July 28, 2005. 7.5 ©Silberschatz, Korth and Sudarshan
 Functional Dependencies (Cont.)
 Functional Dependency can be
 Trivial
    is trivial if   
 Non trivial
    is non trivial if   
 A functional dependency is a generalization of the notion of a key.
 K is a superkey for relation schema R if and only if K  R
 K is a candidate key for R if and only if
 K  R, and
 for no   K,   R

Database System Concepts - 5th Edition, July 28, 2005. 7.6 ©Silberschatz, Korth and Sudarshan
 Closure of a Set of Functional
Dependencies
 Given a set F of functional dependencies, there are certain other
functional dependencies that are logically implied by F.
 For example: If A  B and B  C, then we can infer that A  C
 The set of all functional dependencies logically implied by F is the closure
of F.
 We denote the closure of F by F+.
 F+ is a superset of F.

Database System Concepts - 5th Edition, July 28, 2005. 7.7 ©Silberschatz, Korth and Sudarshan
 Closure of a Set of Functional
Dependencies

 We can find all of F+ by applying Armstrong’s Axioms:

 if   , then    (reflexivity)
 if   , then      (augmentation)
 if   , and   , then    (transitivity)
 If    holds and    holds, then     holds (union)
 If     holds, then    holds and    holds (decomposition)
 If    holds and     holds, then     holds
(pseudotransitivity)

Database System Concepts - 5th Edition, July 28, 2005. 7.8 ©Silberschatz, Korth and Sudarshan
 Example
 R = (A, B, C, G, H, I)
F={ AB
AC
CG  H
CG  I
B  H}
 some members of F+
 AH
 by transitivity from A  B and B  H
 AG  I
 by augmenting A  C with G, to get AG  CG
and then transitivity with CG  I
 CG  HI
 by augmenting CG  I to infer CG  CGI,
and augmenting of CG  H to infer CGI  HI,
and then transitivity

Database System Concepts - 5th Edition, July 28, 2005. 7.9 ©Silberschatz, Korth and Sudarshan
 Procedure for Computing F+
 To compute the closure of a set of functional dependencies F:

F+=F
repeat
for each functional dependency f in F+
apply reflexivity and augmentation rules on f
add the resulting functional dependencies to F +
for each pair of functional dependencies f1and f2 in F +
if f1 and f2 can be combined using transitivity
then add the resulting functional dependency to F +
until F + does not change any further

Database System Concepts - 5th Edition, July 28, 2005. 7.10 ©Silberschatz, Korth and Sudarshan
 Second Normal Form

 A relation R is in second normal form if and only if it is in 1st NF and

every non key attribute is irreducibly dependant on primary key
 So we decompose the relation of 1NF as
 (S# ,P#, Qty)
 (S#, City, Status)
 Insertion anomalies
 Can’t insert information about status of a city until supplier
resides in that city
 Deletion anomalies
 If we delete first tuple of supplier we not only delete Supplier
information but also information about status of a city
 Updation anomalies
 The city value appears many times and hence can lead to
inconsistency while updation

Database System Concepts - 5th Edition, July 28, 2005. 7.11 ©Silberschatz, Korth and Sudarshan
 Example (Convert it in 2NF)

Project Project Employee Employee Rate Rate

No. Name No. Name category

1203 Madagascar 11 Jessica A £90

travel site Brookes

1203 Madagascar 12 Andy B £80

travel site Evans

1203 Madagascat 16 Max Fat C £70

travel site

1506 Online 11 Jessica A £90

estate Brookes
agency
1506 Online 17 Alex B £70
estate Branton
agency

Database System Concepts - 5th Edition, July 28, 2005. 7.12 ©Silberschatz, Korth and Sudarshan
 We look for partial dependencies
We look for fields that depend on only part of the
key and not the entire key.

Field Project No Employee No

Project Name 

Employee 

Rate Category 

Rate 

We remove partial dependencies

The fields listed are only dependent on part of
the key so we remove them from the table.

Database System Concepts - 5th Edition, July 28, 2005. 7.13 ©Silberschatz, Korth and Sudarshan
 We create new tables
Clearly we can’t take the data out and leave it out
of our database. We put it into a new table
consisting of the field that has the partial
dependency and the field it is dependent on.
Looking at our example we will need to create
two new tables:

Dependent On Partially Dependent On Partially

Dependent Dependent
Project No Project Employee No Employee
Name Name
Rate
category
Rate

Database System Concepts - 5th Edition, July 28, 2005. 7.14 ©Silberschatz, Korth and Sudarshan
 We now have 3 tables:
Project No Project
Name
Project Employee
1023 Madagascar
No No
travel site
1023 11
1056 Online
1023 12 estate
agency
1023 16
Employee Employee Rate Rate
1056 11 No Name Category
1056 17 11 Jessica A £90
Brookes
12 Andy Evans B £80

16 Max Fat C £70

17 Alex A £80
Branton

Database System Concepts - 5th Edition, July 28, 2005. 7.15 ©Silberschatz, Korth and Sudarshan
 Third Normal Form
 A relation R is in third normal form if and only if it is in 2NF and every non key attribute is
non transitively dependant on primary key
 So we decompose the relation of 2NF as
 (S# , city)
 (City, Status)
 More Satisfactory
OR
 (S# , city)
 (s#, Status)
 Less Satisfactory
 Insertion anomalies
– Can’t insert information about status of a city until supplier resides in that
city
 Deletion anomalies
– If we delete first tuple of supplier we not only delete Supplier information but
also information about status of a city
 Updation anomalies
– The city value appears many times and hence can lead to inconsistency
while updation

Database System Concepts - 5th Edition, July 28, 2005. 7.16 ©Silberschatz, Korth and Sudarshan
 Employee Employee Rate
No Name Category

11 Jessica A Rate Rate

Brookes Category
A £90
12 Andy B
Evans B £80

16 Max Fat C C £70

17 Alex A
Branton

Database System Concepts - 5th Edition, July 28, 2005. 7.17 ©Silberschatz, Korth and Sudarshan
 Revise All NFs.
 1 NF:
 Attributes must be atomic.
 No two columns hold the same information
 No single column holds more than a single item
 Use Primary Key.
 2 NF:
 Relation R is in 1 NF.
 Every non key attribute is fully dependent on the P.K.
 3 NF:
 Relation R must be in 2NF.
 Every non-key attribute is non-transitively dependent on the P.K.

 Examples:

Database System Concepts - 5th Edition, July 28, 2005. 7.18 ©Silberschatz, Korth and Sudarshan
 Canonical Cover
 Sets of functional dependencies may have redundant dependencies
that can be inferred from the others
 For example: A  C is redundant in: {A  B, B  C}
 Parts of a functional dependency may be redundant
 E.g.: on RHS: {A  B, B  C, A  CD} can be simplified
to
{A  B, B  C, A  D}
 E.g.: on LHS: {A  B, B  C, AC  D} can be simplified
to
{A  B, B  C, A  D}
 canonical cover of F is a “minimal” set of functional dependencies
equivalent to F, having no redundant dependencies or redundant parts
of dependencies

Database System Concepts - 5th Edition, July 28, 2005. 7.19 ©Silberschatz, Korth and Sudarshan
 Closure of Attribute Sets
 Given a set of attributes  define the closure of  under F (denoted by
+) as the set of attributes that are functionally determined by  under
F

 Algorithm to compute +, the closure of  under F

result := ;
while (changes to result) do
for each    in F do
begin
if   result then result := result  
end

Database System Concepts - 5th Edition, July 28, 2005. 7.20 ©Silberschatz, Korth and Sudarshan
 Example of Attribute Set Closure
 R = (A, B, C, G, H, I)
 F = {A  B
AC
CG  H
CG  I
B  H}
 (AG)+
1. result = AG
2. result = ABCG (A  C and A  B)
3. result = ABCGH (CG  H and CG  AGBC)
4. result = ABCGHI (CG  I and CG  AGBCH)
 Is AG a candidate key?
1. Is AG a super key?
1. Does AG  R? == Is (AG)+  R
2. Is any subset of AG a superkey?
1. Does A  R? == Is (A)+  R
2. Does G  R? == Is (G)+  R

Database System Concepts - 5th Edition, July 28, 2005. 7.21 ©Silberschatz, Korth and Sudarshan
 Uses of Attribute Closure
There are several uses of the attribute closure algorithm:
 Testing for superkey:
 To test if  is a superkey, we compute +, and check if + contains
all attributes of R.
 Testing functional dependencies
 To check if a functional dependency    holds (or, in other
words, is in F+), just check if   +.
 That is, we compute + by using attribute closure, and then check
if it contains .
 Is a simple and cheap test, and very useful
 Computing closure of F
 For each   R, we find the closure +, and for each S  +, we
output a functional dependency   S.

Database System Concepts - 5th Edition, July 28, 2005. 7.22 ©Silberschatz, Korth and Sudarshan
 Extraneous Attributes
 Consider a set F of functional dependencies and the functional
dependency    in F.
 Attribute A is extraneous in  if A  
and F logically implies (F – {  })  {( – A)  }.
 Attribute A is extraneous in  if A  
and the set of functional dependencies
(F – {  })  { ( – A)} logically implies F.
 Example: Given F = {A  C, AB  C }
 B is extraneous in AB  C because {A  C, AB  C} logically
implies A  C (I.e. the result of dropping B from AB  C).
 Example: Given F = {A  C, AB  CD}
 C is extraneous in AB  CD since AB  C can be inferred even
after deleting C

Database System Concepts - 5th Edition, July 28, 2005. 7.23 ©Silberschatz, Korth and Sudarshan
 Testing if an Attribute is Extraneous

 Consider a set F of functional dependencies and the functional

dependency    in F.
 To test if attribute A   is extraneous in 
1. compute ({} – A)+ using the dependencies in F
2. check that ({} – A)+ contains ; if it does, A is extraneous in 
 To test if attribute A   is extraneous in 
1. compute + using only the dependencies in
F’ = (F – {  })  { ( – A)},
2. check that + contains A; if it does, A is extraneous in 

Database System Concepts - 5th Edition, July 28, 2005. 7.24 ©Silberschatz, Korth and Sudarshan
 Canonical Cover
 A canonical cover for F is a set of dependencies Fc such that
 F logically implies all dependencies in Fc, and
 Fc logically implies all dependencies in F, and
 No functional dependency in Fc contains an extraneous attribute, and
 Each left side of functional dependency in Fc is unique.
 To compute a canonical cover for F:
repeat
Use the union rule to replace any dependencies in F
1  1 and 1  2 with 1  1 2
Find a functional dependency    with an
extraneous attribute either in  or in 
If an extraneous attribute is found, delete it from   
until F does not change
 Note: Union rule may become applicable after some extraneous attributes
have been deleted, so it has to be re-applied

Database System Concepts - 5th Edition, July 28, 2005. 7.25 ©Silberschatz, Korth and Sudarshan
 Computing a Canonical Cover

 R = (A, B, C)
F = {A  BC
BC
AB
AB  C}
 Combine A  BC and A  B into A  BC
 Set is now {A  BC, B  C, AB  C}
 A is extraneous in AB  C
 Check if the result of deleting A from AB  C is implied by the other
dependencies
 Yes: in fact, B  C is already present!
 Set is now {A  BC, B  C}
 C is extraneous in A  BC
 Check if A  C is logically implied by A  B and the other dependencies
 Yes: using transitivity on A  B and B  C.
– Can use attribute closure of A in more complex cases
 The canonical cover is: AB
BC
Database System Concepts - 5th Edition, July 28, 2005. 7.26 ©Silberschatz, Korth and Sudarshan
 Lossless-join Decomposition
 A decomposition of R into R1 and R2 is lossless join if and
only if at least one of the following dependencies is in F+:
 R1  R2  R1
 R1  R2  R2

Database System Concepts - 5th Edition, July 28, 2005. 7.27 ©Silberschatz, Korth and Sudarshan
 Example
 R = (A, B, C)
F = {A  B, B  C)
 Can be decomposed in two different ways
 R1 = (A, B), R2 = (B, C)
 Lossless-join decomposition:
R1  R2 = {B} and B  BC
 Dependency preserving
 R1 = (A, B), R2 = (A, C)
 Lossless-join decomposition:
R1  R2 = {A} and A  AB
 Not dependency preserving
(cannot check B  C without computing R1 R2)

Database System Concepts - 5th Edition, July 28, 2005. 7.28 ©Silberschatz, Korth and Sudarshan
 Dependency Preservation

 Let Fi be the set of dependencies F + that include only attributes in

Ri.
 A decomposition is dependency preserving, if
(F1  F2  …  Fn )+ = F +

Database System Concepts - 5th Edition, July 28, 2005. 7.29 ©Silberschatz, Korth and Sudarshan
 Testing for Dependency Preservation

 To check if a dependency    is preserved in a decomposition of R into

R1, R2, …, Rn we apply the following test (with attribute closure done with
respect to F)
 result = 
while (changes to result) do
for each Ri in the decomposition
t = (result  Ri)+  Ri
result = result  t
 If result contains all attributes in , then the functional dependency
   is preserved.
 We apply the test on all dependencies in F to check if a decomposition is
dependency preserving
 This procedure takes polynomial time, instead of the exponential time
required to compute F+ and (F1  F2  …  Fn)+

Database System Concepts - 5th Edition, July 28, 2005. 7.30 ©Silberschatz, Korth and Sudarshan
 Example
 R = (A, B, C )
F = {A  B
B  C}
Key = {A}
 Decomposition R1 = (A, B), R2 = (B, C)
 Lossless-join decomposition
 Dependency preserving

Database System Concepts - 5th Edition, July 28, 2005. 7.31 ©Silberschatz, Korth and Sudarshan
 A Lossy Decomposition

Database System Concepts - 5th Edition, July 28, 2005. 7.32 ©Silberschatz, Korth and Sudarshan
 BCNF – Boyce/codd Normal Form
 3NF doesn’t deal with the situation if relation
 Had 2 or more candidate keys
 The candidate keys are composite
 Candidate keys are overlapping
 For Example
 Student_teacher_subject( Student, Subject, Teacher)
 Constraints are
– For each subject, each student of that subject is taught by only one teacher
» Student, Subject  Teacher
– Each teacher teaches only one subject( but subject is taught by several
teacher)
» Teacher  Subject
 Candidate keys can be
 Student, Subject
 Subject, Teacher
 A relation R is in BCNF if and only if every determinant is a candidate
key.

Database System Concepts - 5th Edition, July 28, 2005. 7.33 ©Silberschatz, Korth and Sudarshan
 BCNF – Boyce/codd Normal Form
 Insertion anomalies
 Can’t insert information about teacher teaches a subject until a
student is enrolled for that subject
 Deletion anomalies
 If we delete first tuple of a subject opted by a student we not
only delete Student information but also information about
teacher teaching that subject.
 Updation anomalies
 The subject value for a teacher appears many times and hence
can lead to inconsistency while updation
 So we decompose the relation as
 (Student, Teacher)
 (Teacher, Subject)

Database System Concepts - 5th Edition, July 28, 2005. 7.34 ©Silberschatz, Korth and Sudarshan
 Fourth Normal Form

Database System Concepts - 5th Edition, July 28, 2005. 7.35 ©Silberschatz, Korth and Sudarshan
 Fourth Normal Form

Database System Concepts - 5th Edition, July 28, 2005. 7.36 ©Silberschatz, Korth and Sudarshan
 Fourth Normal Form
 The above relation is in BCNF
 Still the above relation has lot of redundancy and hence can lead to update
anomalies
 The reason is the presence of multi valued dependencies
 Multi Valued Dependency
 Given a relation R with subset of attributes A,B and C, then we say that B
is multi dependant on A written as AB, if and only if the set of B values
matching a given AC value only depends on A value and is independent
on C Value.
 Course  teacher
 Each course has set of teachers which is not dependent on text
 Course  text
 Each course has set of text which is not dependent on teacher
 Fourth Normal Form
 A relation R is in 4NF if there exist a non trivial multivalued dependency
AB, then all attributes of R are functionally dependent on A.

Database System Concepts - 5th Edition, July 28, 2005. 7.37 ©Silberschatz, Korth and Sudarshan
 Fifth Normal Form

Database System Concepts - 5th Edition, July 28, 2005. 7.38 ©Silberschatz, Korth and Sudarshan
 Fifth Normal Form
 The above relation is in BCNF
 Still the above relation has lot of redundancy and hence can lead to update
anomalies
 The reason is the presence of join dependencies
 Join Dependency
 A relation R satisfies the Join D dependency
*(X, Y,…,Z)
if and only if it is the join of its projections on X, Y,..,Z where X, Y,..,Z are
subsets of the set of attributes of R.
*({supplier_number,partno}, {partno, project_number},
{project_no,supplier_number})
 Fifth Normal Form ( Projection join Normal Form)
 A relation R is in 5NF if and only if every non trivial join dependency is
implied by the candidate key of R( The join dependency *(X, Y,…,Z) is
implied if each X,Y…Z is superkey of R)

Database System Concepts - 5th Edition, July 28, 2005. 7.39 ©Silberschatz, Korth and Sudarshan