Copyright © 2007 Ramez Elmasri and Shamkant B.

Navathe Slide 10- 1

Chapter 10
Functional Dependencies and
Normalization for Relational
Databases

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Chapter Outline
 1 Informal Design Guidelines for Relational Databases
 2 Functional Dependencies (FDs)
 2.1 Definition of FD
 2.2 Inference Rules for FDs
 2.3 Equivalence of Sets of FDs
 2.4 Minimal Sets of FDs
 3 Normalization of relations
 4 Normal forms

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 3

1 Informal Design Guidelines for
Relational Databases (1)

 What is relational database design?

 The grouping of attributes to form "good" relation
schemas
 Design is concerned mainly with base relations
 What are the criteria for "good" base relations?

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 4

Informal Design Guidelines for Relational
Databases (2)
 We first discuss informal guidelines for good relational
design
 Then we discuss formal concepts of functional
dependencies and normal forms
 - 1NF (First Normal Form)
 - 2NF (Second Normal Form)
 - 3NF (Third Normal Form)
 - BCNF (Boyce-Codd Normal Form)

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 5

1.1 Semantics of the Relation Attributes
 GUIDELINE 1: Informally, each tuple in a relation should
represent one entity or relationship instance. (Applies to
individual relations and their attributes).
 Attributes of different entities (EMPLOYEEs,
DEPARTMENTs, PROJECTs) should not be mixed in the
same relation
 Only foreign keys should be used to refer to other entities
 Entity and relationship attributes should be kept apart as
much as possible.
 Bottom Line: Design a schema that can be explained
easily relation by relation. The semantics of attributes
should be easy to interpret.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 6

1.2 Redundant Information in Tuples and
Update Anomalies

 Information is stored redundantly

 Wastes storage
 Causes problems with update anomalies
 Insertion anomalies
 Deletion anomalies
 Modification anomalies

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 7

 EXAMPLE OF AN UPDATE ANOMALY

 Consider the relation:

 EMP_PROJ(Emp#, Proj#, Ename, Pname, No_hours)
E1 P1 AA Billing 100
 Update Anomaly:
 Changing the name of project number P1 from
“Billing” to “Customer-Accounting” may cause this
update to be made for all 100 employees working on
project P1.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 8

 EXAMPLE OF AN INSERT ANOMALY

 Consider the relation:

 EMP_PROJ(Emp#, Proj#, Ename, Pname, No_hours)
E1 P1 AA Billing 100
 Insert Anomaly:
 Cannot insert a project unless an employee is assigned
to it.
 Conversely
 Cannot insert an employee unless an he/she is
assigned to a project.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 9

EXAMPLE OF AN DELETE ANOMALY

 Consider the relation:

 EMP_PROJ(Emp#, Proj#, Ename, Pname, No_hours)
E1 P1 AA Billing 100
 Delete Anomaly:
 When a project is deleted, it will result in deleting all
the employees who work on that project.
 Alternately, if an employee is the sole employee on a
project, deleting that employee would result in
deleting the corresponding project.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 10

Guideline to Redundant Information in
Tuples and Update Anomalies

 GUIDELINE 2:
 Design a schema that does not suffer from the
insertion, deletion and update anomalies.
 If there are any anomalies present, then note them
so that applications can be made to take them into
account.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 11

1.3 Null Values in Tuples
 GUIDELINE 3:
 Relations should be designed such that their
tuples will have as few NULL values as possible
 Attributes that are NULL frequently could be
placed in separate relations (with the primary key)
 Reasons for nulls:
 Attribute not applicable or invalid
 Attribute value unknown (may exist)
 Value known to exist, but unavailable

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 12

1.4 Spurious Tuples
 Bad designs for a relational database may result
in erroneous results for certain JOIN operations
 The "lossless join" property is used to guarantee
meaningful results for join operations

 GUIDELINE 4:
 The relations should be designed to satisfy the
lossless join condition.
 No spurious tuples should be generated by doing
a natural-join of any relations.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 13

Spurious Tuples (2)
 There are two important properties of decompositions:
a) Non-additive or losslessness of the corresponding join
b) Preservation of the functional dependencies.

 Note that:
 Property (a) is extremely important and cannot be
sacrificed.
 Property (b) is less stringent and may be sacrificed.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 14

2.1 Functional Dependencies (1)
 Functional dependencies (FDs)
 Are used to specify formal measures of the
"goodness" of relational designs
 And keys are used to define normal forms for
relations
 Are constraints that are derived from the meaning
and interrelationships of the data attributes
 A set of attributes X functionally determines a set
of attributes Y if the value of X determines a
unique value for Y. It denotes by X  Y

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 15

Functional Dependencies (2)
 X  Y holds if whenever two tuples have the same value
for X, they must have the same value for Y
 For any two tuples t1 and t2 in any relation instance r(R): If
t1[X]=t2[X], then t1[Y]=t2[Y]
 X  Y in R specifies a constraint on all relation instances
r(R)
 FDs are derived from the real-world constraints on the
attributes.
    is trivial if   

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 16

Examples of FD constraints (2)
 The constraint must hold on every relation
instance r(R)
 If K is a key of R, then K functionally determines
all attributes in R
 (since we never have two distinct tuples with
t1[K]=t2[K])

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 17

Example. A simplified COMPANY
relational database schema

SSN  ENAME

{Dnumber, Dlocation}  Dlocation is trivial

PNUMBER  {PNAME, PLOCATION}

{SSN, PNUMBER}  HOURS

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 18

2.2 Inference Rules for FDs (1)
 Given a set of FDs F, we can infer additional FDs that
hold whenever the FDs in F hold
 Armstrong's inference rules:
 IR1. (Reflexive) If Y  X, then X  Y

 IR2. (Augmentation) If X  Y, then XZ  YZ

 (Notation: XZ stands for X U Z)
 IR3. (Transitive) If X  Y and Y  Z, then X  Z

 IR1, IR2, IR3 form a sound and complete set of

inference rules
 These are rules hold and all other rules that hold can be
deduced from these

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 19

Inference Rules for FDs (2)
 Some additional inference rules that are useful:
 Decomposition: If X  YZ, then X  Y and X  Z
 Union: If X  Y and X  Z, then X  YZ
 Psuedotransitivity:
If X  Y and WY  Z, then WX  Z

 The last three inference rules, as well as any other

inference rules, can be deduced from IR1, IR2, and
IR3 (completeness property)

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 20

Closure of a Set of Functional Dependencies

 Closure of a set F of FDs is the set F+ of all FDs

that can be inferred from F. We denote the closure
of F by F+
 F  F+

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 21

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

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Closure of Attribute Sets
 Closure of a set of attributes X with respect to F
(denoted by X+F) is the set of all attributes that are
functionally determined by X.
X+F = { /     F+}
 X+F can be calculated by repeatedly applying IR1,
IR2, IR3 using the FDs in F
 Algorithm to compute X+F
result := ;
while (changes to result) do
for each    in F do
begin
if   result then result := result  
end
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe
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? 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
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe
 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.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

2.3 Equivalence of Sets of FDs
 Two sets of FDs F and G are equivalent if:
 Every FD in F can be inferred from G, and
 Every FD in G can be inferred from F
 Hence, F and G are equivalent if F+ =G+
 Definition (Covers):
 F covers G if every FD in G can be inferred from F
 (i.e., if G+ subset-of F+)
 F and G are equivalent if F covers G and G covers F
 a minimal cover of a set of functional dependencies E is
a minimal set of functional dependencies F that is
equivalent to E.
 We can always find at least one minimal cover F for any
set of dependencies E
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 26
2.4 Minimal Sets of FDs (1)
 A set of FDs is minimal if it satisfies the
following conditions:
1. Every dependency in F has a single attribute for
its RHS.
2. We cannot replace any dependency X  A in F
with a dependency Y  A, where Y proper-
subset-of X (Y subset-of X) and still have a set of
dependencies that is equivalent to F.
3. We cannot remove any dependency from F and
have a set of dependencies that is equivalent to
F.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 27

Minimal Sets of FDs (2)
 Every set of FDs has an equivalent minimal set
 There can be several equivalent minimal sets
 There is no simple algorithm for computing a
minimal set of FDs that is equivalent to a set F of
FDs
 To synthesize a set of relations, we assume that
we start with a set of dependencies that is a
minimal set.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 28

Algorithm for Finding a Minimal Cover F for a Set of Functional
Dependencies E

Input: A set of functional dependencies E.

1. Set F := E.
2. Replace each functional dependency X→{A1, A2, ..., An} in
F by the n functional dependencies X→A1, X→A2, ..., X→An.
3. For each functional dependency X→A in F for each attribute B
that is an element of X
if { {F – {X→A} } ∪ { (X – {B} ) →A} } is equivalent to F
then replace X→A with (X – {B} ) →A in F.
4. For each remaining functional dependency X→A in F
if {F – {X→A} } is equivalent to F,
then remove X→A from F.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 29

Example 1. given set of FDs be E : {B→A, D→A, AB→D}. Find
the minimal cover of E.
 All above dependencies are in canonical form (that is, they
have only one attribute on the right-hand side), so we have
completed step 1 of Algorithm.
 Determine if AB→D has any redundant attribute on the left-
hand side; that is, can it be replaced by B→D or A→D?
We have B→AB (i) (from B →A => BB → AB)
AB→D as given (ii).
From (i) and (ii) => B → D. Thus AB→D may be replaced by B→D
 We now have a set equivalent to original E, say E’ = {B→A,
D→A, B→D}
 In step 3 we look for a redundant FD in E.
From B → D and D → A => B → A. Hence B → A is redundant in E
 The minimal cover of E is {B→D, D→A}.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 30

Example 2. Given R = (A, B, C), F = {A  BC, B  C, A  B,
AB  C}. Find the minimal cover of F.
 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 minimal cover of F is: {A  B, B  C}

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

 Key definition based on FD

 Given R(A1, A2, . . ., An) and a FD set F

+ S  R is a superkey of R if S  R  F+

+ K  R is one of candidate keys of R if:

- K is a superkey
- for no   K,   R

32
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe
Algorithm for Finding a Key K for R Given a set F of Functional
Dependencies

 Input: A relation R and a set of functional dependencies F on

the attributes of R.
1. Set K := R.
2. For each attribute A in K
{compute (K – A)+ with respect to F;
if (K – A)+ contains all the attributes in R,
then set K := K – {A} };

 Notice, this algorithm determines only one key out of the

possible candidate keys for R; the key returned depends on
the order in which attributes are removed from R in step 2.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 33

Algorithm for Finding all candidate keys for R
Input: Given a set R of attributes and a set F of FD
Output: A set K of candidate keys of R
 Phase 1:

Find a set S of all super keys of R

S = {si / si  R }
by computing closures of (2n -1) not null subsets of R. if a
closure of any subset is equal to R that subset is a super key
of R.
 Phase 2 :

Find a set K of all candidate keys from the super key set by
removing any super key that is not minimum

34
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe
Algorithm for Finding all candidate keys for R (cont.)
Example: Given Q(R), R = {A, B, C, D, E, G} and
F = { f1: AE  C, f2 : CG  A, f3 : BD  G, f4: GA  E}
Find all candidate keys of Q(R).
- Phase 1:
computing closures of (2n -1) not null subsets of R.
ABCDEG XR X+F Siêu khóa
000001 G G
110100 ABD ABCDEG ABD

...
110110 ABDE ABDE

Note: if ABD is a super key then any set S  ABD is also a

super key.

35
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe
Algorithm for Finding all candidate keys for R (cont.)
- The result of phase 1:
S = { ABD, BCD, ABCD, ABDE, BCDE, ABCDE, ABDG,
BCDG, ABCDG, ABDEG, BCDEG, ABCDEG}
- The result of phase 2 : choose minimum sets in S.
K = { ABD, BDC}

36
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe
Improved Algorithm for Finding all candidate keys for R
 Comment:
If R is large, it takes a long time for computing closures of
(2n –1) subsets of R.
The above algorithm is improved as follows:
 Given A  R,
- A is called a source attribute if A is not in the right hand
side of any non trivial FD of F
The set of all source attributes denotes by N
- A is called a destination attribute if A is not a source
attribute and A is not in the left hand side of any non
trivial FD of F.
The set of all destination attributes denotes by D.

37
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe
Improved Algorithm for Finding all candidate keys for R
- The set of attributes which are not source or destination
attributes denotes by L.

 We have R = N U D U L và N , D , L are disjoined

- Note:
+ If K is a key of Q, K includes all source attributes and
does not include any destination attribute.
So K = N U Li , Li  L
KD=
+ If Xi is a super key and Xi  Xj, we need not to compute
closure of Xj because it is not a candidate key of Q.

38
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe
Improved Algorithm for Finding all candidate keys for R
Example: Given Q(R), R = {A, B, C, D, E, G} và
F = { f1: AE  C, f2 : CG  A, f3 : BD  G, f4: GA  E}
Find all candidate keys of Q
 N = {B,D}, D= , L = {A,C, E, G}

- Phase 1:
Compute closure of subsets of R.
L= X= N U li X+F Siêu
ACEG L khóa
0000 BD
0001 BDG

Note: if ABD is a super key, X  ABC is also a super key.

39
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe
3. Normalization of Relations
 Normalization:
 The process of decomposing unsatisfactory "bad"
relations by breaking up their attributes into
smaller relations

 Normal form:
 Condition using keys and FDs of a relation to
certify whether a relation schema is in a particular
normal form

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 40

A Lossy Decomposition

we cannot
reconstruct the
original
employee
relation -- we
lose information

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Example of Lossless-Join Decomposition
 Lossless join decomposition
 Decomposition of R = (A, B, C)
R1 = (A, B) R2 = (B, C)

A B C A B B C
 1 A  1 1 A
 2 B  2 2 B
r A,B(r) B,C(r)

A B C
A (r) B (r)
 1 A
 2 B

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Nonadditive/Lossless-join Decomposition
 A decomposition R into {R1, R2, ..., Rn} is Lossless-join if
r = R1 (r ) R2 (r ) … Rn (r )
 For the case of R = (R1, R2), we require that for all possible
relations r on schema R
r = R1 (r ) R2 (r )
 A decomposition of R into R1 and R2 is lossless join if at least one
of the following dependencies is in F+:
 R1  R2  R1

 R1  R2  R2

 The above functional dependencies are a sufficient condition for

lossless join decomposition; the dependencies are a necessary
condition only if all constraints are functional dependencies

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Testing for Nonadditive Join (1)

Input: A universal relation R, a decomposition D = {R1, R2, ...,

Rm} of R, and a set F of functional dependencies.
1. Create an initial matrix S with one row i for each relation Ri in
D, and one
column j for each attribute Aj in R.
2. Set S(i, j):= bij for all matrix entries.
3. For each row i representing relation schema Ri
for each column j representing attribute Aj
if (relation Ri includes attribute Aj) then set S(i, j):= aj

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

 Testing for Nonadditive Join (2)
4. Repeat the following loop until a complete loop execution results in no
changes to S:
for each functional dependency X→Y in F
for all rows in S that have the same symbols in the columns
corresponding to attributes in X
make the symbols in each column that correspond to an attribute in
Y be the same in all these rows as follows: If any of the rows has
an ‘a’ symbol for the column, set the other rows to that same ‘a’
symbol in the column. If no ‘a’ symbol exists for the attribute in any
of the rows, choose one of the ‘b’ symbols that appears in one of
the rows for the attribute and set the other rows to that same ‘b’
symbol in the column.
5. If a row is made up entirely of ‘a’ symbols, then the decomposition has the
nonadditive join property; otherwise, it does not.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

 Example
R = {Ssn, Ename, Pnumber, Pname, Plocation, Hours}, D = {R1, R2, R3}
R1 = EMP(Ssn, Ename), R2 = PROJ(Pnumber, Pname, Plocation)
R3 = WORKS_ON(Ssn, Pnumber, Hours).
F = {SsnEname; Pnumber{Pname, Plocation}; {Ssn, Pnumber}Hours}

Applying SsnEname and Pnumber{Pname, Plocation}

last row is all “a” symbols so we stop

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe
 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 +
 If it is not, then checking updates for violation of
functional dependencies may require computing
joins, which is expensive.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

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)

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

 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 = 

Repeat
for each Ri in the decomposition
t = (result  Ri)+  Ri
result = result  t
Until (result does not change)
 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)+
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe
Goals of Normalization
Let R be a relation scheme with a set F of functional
dependencies.
 Decide whether a relation scheme R is in “good”

form.
 In the case that a relation scheme R is not in “good”
form, decompose it into a set of relation scheme
{R1, R2, ..., Rn} such that
 each relation scheme is in good form
 the decomposition is a lossless-join decomposition
 Preferably, the decomposition should be dependency
preserving.
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe
4. Normal Forms

4.1. First Normal Form

 Attribute values permitted by 1NF are single
atomic (or indivisible) values.

 Considered to be part of the definition of relation

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 51

Example. Normalization into 1NF

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 52

4.2. Second Normal Form (1)
 Uses the concepts of FDs, primary key
 Definitions
 Prime attribute: An attribute of relation schema R that is
member of some candidate key of R
 Full functional dependency: a FD Y  Z where removal
of any attribute from Y means the FD does not hold any
more
 Examples:
 {SSN, PNUMBER}  HOURS is a full FD since neither
SSN  HOURS nor PNUMBER  HOURS hold
 {SSN, PNUMBER}  ENAME is not a full FD (it is called a
partial dependency ) since SSN  ENAME also holds

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 53

Second Normal Form (2)
 A relation schema R is in second normal form
(2NF) if every non-prime attribute A in R is fully
functionally dependent on every key of R

 R can be decomposed into 2NF relations via the

process of 2NF normalization

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 54

 4.3. Third Normal Form (1)
 Definition:
 Transitive functional dependency: a FD X  Z that
can be derived from two FDs X  Y and Y  Z
 Examples:

 SSN  DMGRSSN is a transitive FD

 Since SSN  DNUMBER and DNUMBER 
DMGRSSN hold
 SSN  ENAME is non-transitive
 Since there is no set of attributes X where SSN  X
and X -> ENAME
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 55
Third Normal Form (2)
 A relation schema R is in third normal form (3NF) if it is
in 2NF and no non-prime attribute A in R is transitively
dependent on the primary key
 R can be decomposed into 3NF relations via the process
of 3NF normalization
 NOTE:
 In X  Y and Y  Z, with X as the primary key, we consider
this a problem only if Y is not a candidate key.
 When Y is a candidate key, there is no problem with the
transitive dependency .
 E.g., Consider EMP (SSN, Emp#, Salary ).
 Here, SSN  Emp#  Salary and Emp# is a candidate key.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 56

Third Normal Form (3)
 alternative definition:
 A relation schema R is in third normal form (3NF)
if whenever a FD X  A holds in R, then either:
 (a) X is a superkey of R, or
 (b) A is a prime attribute of R
 (c) X  A is trivial (i.e., A  X)
 NOTE: Boyce-Codd normal form disallows
condition (b) above

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 57

Example. Normalizing into 2NF and 3NF (1)

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 58

Example. Normalization into 2NF and 3NF (2)

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 59

3NF Decomposition Algorithm
Let Fc be a canonical cover for F;
i := 0;
for each functional dependency    in Fc do
if none of the schemas Rj, 1  j  i contains  
then begin
i := i + 1;
Ri :=  
end
if none of the schemas Rj, 1  j  i contains a candidate key for R
then begin
i := i + 1;
Ri := any candidate key for R;
end
/* Optionally, remove redundant relations */
repeat
if any schema Rj is contained in another schema Rk
then /* delete Rj */
Rj = Ri
i=i-1;
until no more Rjs can be deleted
return (R1, R2, ..., Ri)
Note: Above algorithm ensures decomposition is dependency preserving and
lossless-join
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe
 3NF Decomposition: An Example
 Relation schema:
cust_banker_branch(customer_id, employee_id, branch_name, type )
 The functional dependencies for this relation schema are:
1. customer_id, employee_id  branch_name, type

2. employee_id  branch_name

3. customer_id, branch_name  employee_id

 We first compute a canonical cover

 branch_name is extraneous in the right hand side of the 1
st

dependency
 No other attribute is extraneous, so we get FC =

customer_id, employee_id  type

employee_id  branch_name
customer_id, branch_name  employee_id
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe
 3NF Decompsition Example (Cont.)
 The for loop generates following 3NF schema:
R1(customer_id, employee_id, type )
R2 (employee_id, branch_name)
R3 (customer_id, branch_name, employee_id)
 Observe that (customer_id, employee_id, type ) contains a
candidate key of the original schema, so no further relation
schema needs be added
 At end of for loop, detect and delete schemas, such as
(employee_id, branch_name), which are subsets of other
schemas
 result will not depend on the order in which FDs are

considered
 The resultant simplified 3NF schema is:
R1(customer_id, employee_id, type)
R2(customer_id, branch_name, employee_id)
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe
4.4. BCNF (Boyce-Codd Normal Form)
 A relation schema R is in Boyce-Codd Normal Form (BCNF) if
whenever an FD X  A holds in R, then X is a superkey of R
 Each normal form is strictly stronger than the previous one
 Every 2NF relation is in 1NF

 Every 3NF relation is in 2NF

 Every BCNF relation is in 3NF

 There exist relations that are in 3NF but not in BCNF

 The goal is to have each relation in BCNF (or 3NF)

Example schema not in BCNF:

instr_dept (ID, name, salary, dept_name, building, budget )

because dept_name building, budget

holds on instr_dept, but dept_name is not a superkey
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 63
 Decomposing a Schema into BCNF
 Suppose we have a schema R and a non-trivial dependency
  causes a violation of BCNF.
We decompose R into:
( U  )
(R-(-))
 In our example,

instr_dept (ID, name, salary, dept_name, building, budget )

  = dept_name

  = building, budget

and inst_dept is replaced by

 R1( dept_name, building, budget )

 R2( ID, name, salary, dept_name )

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

BCNF and Dependency Preservation
 Constraints, including functional dependencies, are
costly to check in practice unless they pertain to only
one relation
 If it is sufficient to test only those dependencies on
each individual relation of a decomposition in order to
ensure that all functional dependencies hold, then that
decomposition is dependency preserving.
 Because it is not always possible to achieve both
BCNF and dependency preservation, we consider a
weaker normal form, known as third normal form.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

 Testing for BCNF
 To check if a non-trivial dependency   causes a violation of BCNF
1. compute + (the attribute closure of ), and
2. verify that it includes all attributes of R, that is, it is a superkey of R.
 Simplified test: To check if a relation schema R is in BCNF, it suffices to
check only the dependencies in the given set F for violation of BCNF, rather
than checking all dependencies in F+.
 If none of the dependencies in F causes a violation of BCNF, then none

of the dependencies in F+ will cause a violation of BCNF either.

 However, simplified test using only F is incorrect when testing a
relation in a decomposition of R
 Consider R = (A, B, C, D, E), with F = { A  B, BC  D}

 Decompose R into R1 = (A,B) and R2 = (A,C,D, E)

 Neither of the dependencies in F contain only attributes from

(A,C,D,E) so we might be mislead into thinking R2 satisfies BCNF.

 In fact, dependency AC  D in F shows R2 is not in BCNF.
+

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

 Testing Decomposition for BCNF
 To check if a relation Ri in a decomposition of R is in BCNF,
 Either test Ri for BCNF with respect to the restriction of F to Ri
(that is, all FDs in F+ that contain only attributes from Ri)
 or use the original set of dependencies F that hold on R, but with
the following test:
 for every set of attributes   Ri, check that  (the
+

attribute closure of ) either includes no attribute of Ri- ,

or includes all attributes of Ri.
 If the condition is violated by some    in F, the

dependency
  (+ -  )  Ri
can be shown to hold on Ri, and Ri violates BCNF.
 We use above dependency to decompose Ri

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

 Example of BCNF Decomposition (1)
 class (course_id, title, dept_name, credits, sec_id, semester,
year, building, room_number, capacity, time_slot_id)
 Functional dependencies:
 course_id→ title, dept_name, credits
 building, room_number→capacity
 course_id, sec_id, semester, year→building, room_number,
time_slot_id
 A candidate key {course_id, sec_id, semester, year}.
 BCNF Decomposition:
 course_id→ title, dept_name, credits holds
 but course_id is not a superkey.

 We replace class by:

 course(course_id, title, dept_name, credits)

 class-1 (course_id, sec_id, semester, year, building,

room_number, capacity, time_slot_id)

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe
Example of BCNF Decomposition (2)
 course is in BCNF
 How do we know this?
 building, room_number→capacity holds on class-1
 but {building, room_number} is not a superkey for

class-1.
 We replace class-1 by:

 classroom (building, room_number, capacity)

 section (course_id, sec_id, semester, year,

building, room_number, time_slot_id)

 classroom and section are in BCNF.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

 BCNF and Dependency Preservation
It is not always possible to get a BCNF decomposition
that is dependency preserving
 R = (J, K, L )
F = {JK  L
LK}
Two candidate keys = JK and JL
 R is not in BCNF
 Any decomposition of R will fail to preserve
JK  L
This implies that testing for JK  L requires a
join
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe
Comparison of BCNF and 3NF
 It is always possible to decompose a relation
into a set of relations that are in 3NF such
that:
 the decomposition is lossless
 the dependencies are preserved
 It is always possible to decompose a relation
into a set of relations that are in BCNF such
that:
 the decomposition is lossless
 it may not be possible to preserve dependencies.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

 Design Goals
 Goal for a relational database design is:
 BCNF.

 Lossless join.

 Dependency preservation.

 If we cannot achieve this, we accept one of

 Lack of dependency preservation

 Redundancy due to use of 3NF

 Interestingly, SQL does not provide a direct way of specifying functional

dependencies other than superkeys.
Can specify FDs using assertions, but they are expensive to test, (and
currently not supported by any of the widely used databases!)
 Even if we had a dependency preserving decomposition, using SQL we
would not be able to efficiently test a functional dependency whose left
hand side is not a key.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Example a Boyce-Codd normal form but
Lack of dependency preservation

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 73

Example. A relation TEACH that is in 3NF
but not in BCNF

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 74

Achieving the BCNF by Decomposition (1)
 Two FDs exist in the relation TEACH:
 fd1: { student, course} -> instructor
 fd2: instructor -> course
 {student, course} is a candidate key for this relation and
that the dependencies shown follow the pattern in Figure
10.12 (b).
 So this relation is in 3NF but not in BCNF
 A relation NOT in BCNF should be decomposed so as to
meet this property, while possibly forgoing the
preservation of all functional dependencies in the
decomposed relations.
 (See Algorithm 11.3)

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 75

Achieving the BCNF by Decomposition (2)
 Three possible decompositions for relation TEACH
 {student, instructor} and {student, course}

 {course, instructor } and {course, student}

 {instructor, course } and {instructor, student}

 All three decompositions will lose fd1.

 We have to settle for sacrificing the functional dependency
preservation. But we cannot sacrifice the non-additivity property
after decomposition.
 Out of the above three, only the 3rd decomposition will not generate
spurious tuples after join.(and hence has the non-additivity property).
 A test to determine whether a binary decomposition (decomposition
into two relations) is non-additive (lossless) is discussed in section
11.1.4 under Property LJ1. Verify that the third decomposition above
meets the property.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 76

 End of chapter 6

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 77