Chapter 7: Normalization

Database System Concepts, 7th Ed.

©Silberschatz, Korth and Sudarshan
See www.db-book.com for conditions on re-use
 Outline

 Features of Good Relational Design

 Functional Dependencies
 Decomposition Using Functional Dependencies
 Normal Forms
 Functional Dependency Theory
 Algorithms for Decomposition using Functional Dependencies
 Decomposition Using Multivalued Dependencies
 More Normal Form
 Atomic Domains and First Normal Form
 Database-Design Process
 Modeling Temporal Data

Database System Concepts - 7th Edition 7.2 ©Silberschatz, Korth and Sudarshan
 ER versus Normalization

 Features of ER
 Entity sets and Relationship sets
 Mapping to tables
 Features of Normalization
 Sets of all attributes used in the database
 Distribution of the attributes to various tables

Database System Concepts - 7th Edition 7.3 ©Silberschatz, Korth and Sudarshan
Overview of Normalization
 Normalization Goal

 Given a set of attributes

R = {A1 , A2 , A3 …. An}
 Partition the attributes among M relations
 With no repetition of information
 Seems to be mission impossible.

Database System Concepts - 7th Edition 7.5 ©Silberschatz, Korth and Sudarshan
 Features of Good Relational Designs

 Consider the new relation in_dep that combines the instructor and
department tables

 There is repetition of information in the relation in_dep

 Need to use null values (if we add a new department with no instructors)
 This relation is NOT in good form

Database System Concepts - 7th Edition 7.6 ©Silberschatz, Korth and Sudarshan
 Good Form

 A relation is said to be in “good” form if:

 There is no repetition of information
 There is no need to use null values
 The definition is a bit vague but good enough for now.
 Goal:
 Devise a scheme to make sure that all tables are in good form

Database System Concepts - 7th Edition 7.7 ©Silberschatz, Korth and Sudarshan
 Decomposition

 The only way to avoid the repetition-of-information problem in the

in_dep schema is to decompose it into two schemas – instructor
and department schemas (which we used all along).
 Not all decompositions are good. Suppose we have a scheme:

employee(ID, name, street, city, salary)

and we decompose it into
employee1 (ID, name)
employee2 (name, street, city, salary)
The problem arises when we have two employees with the same
name
 The next slide shows how we lose information when we
decompose the relation employee -- we cannot reconstruct the
original employee relation -- and so, this is a lossy
decomposition.

Database System Concepts - 7th Edition 7.8 ©Silberschatz, Korth and Sudarshan
 A Lossy Decomposition

Database System Concepts - 7th Edition 7.9 ©Silberschatz, Korth and Sudarshan
 Lossless Decomposition

 Let R be a relation schema and let R1 and R2 form a decomposition

of R . That is R = R1 U R2
 We say that the decomposition is a lossless decomposition if
there is no loss of information by replacing R with the two relation
schemas R1 and R2
 Let r be any valid instance of R
 A decomposition is a lossless decomposition if
r =  R1 (r)  R2 (r)
 And conversely a decomposition is lossy if
r   R1 (r)  R2 (r)

Database System Concepts - 7th Edition 7.10 ©Silberschatz, Korth and Sudarshan
 Lossless Decomposition Example

 Decomposition of R = (A, B, C)
 Into
R1 = (A, B) R2 = (B, C)
 Example of a database instance

Database System Concepts - 7th Edition 7.11 ©Silberschatz, Korth and Sudarshan
 Lossless Decomposition

 Question – how do you know that a decomposition is lossless?

Database System Concepts - 7th Edition 7.12 ©Silberschatz, Korth and Sudarshan
 Functional Dependencies

 There are usually a variety of constraints (rules) on the data in the

real world.
 For example, some of the constraints that are expected to hold in
a university database are:
 Students and instructors are uniquely identified by their ID.
 Each student and instructor has only one name.
 Each instructor and student is (primarily) associated with only
one department.
 Each department has only one value for its budget, and only
one associated building.

Database System Concepts - 7th Edition 7.13 ©Silberschatz, Korth and Sudarshan
 Functional Dependencies (Cont.)

 An instance of a relation that satisfies all such real-world constraints

is called a legal instance of the relation;
 A legal instance of a database is one where all the relation instances
are legal instances
 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.
 A functional dependency is a generalization of the notion of a key.

Database System Concepts - 7th Edition 7.14 ©Silberschatz, Korth and Sudarshan
 Functional Dependencies Definition

 Let R be a relation schema

 Let
  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 - 7th Edition 7.15 ©Silberschatz, Korth and Sudarshan
 Functional Dependencies Example

 Consider r (A,B ) with the following instance of r.

A B
1 4
1 6
3 7

 On this instance,
 B  A hold;
 A  B does NOT hold,

Database System Concepts - 7th Edition 7.16 ©Silberschatz, Korth and Sudarshan
 Keys and Functional Dependencies

 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
 Functional dependencies allow us to express constraints that cannot be
expressed using superkeys. Consider the schema:
in_dep (ID, name, salary, dept_name, building, budget ).
We expect these functional dependencies to hold:
dept_name building
ID  building
but would not expect the following to hold:
dept_name  salary

Database System Concepts - 7th Edition 7.17 ©Silberschatz, Korth and Sudarshan
 Use of Functional Dependencies

 We use functional dependencies to:

 Test relations to see if they are legal under a given set of functional
dependencies.
 If a relation r is legal under a set F of functional dependencies, we
say that r satisfies F.
 Specify constraints on the set of legal relations
 We say that F holds on R if all legal relations on R satisfy the set
of functional dependencies F.
 Note: A specific instance of a relation schema may satisfy a functional
dependency even if the functional dependency does not hold on all legal
instances.
 For example, a specific instance of instructor may, by chance, satisfy
name  ID.

Database System Concepts - 7th Edition 7.18 ©Silberschatz, Korth and Sudarshan
 Closure of a Set of Functional Dependencies

 Given a set F set of functional dependencies, there are certain other

functional dependencies that are logically implied by F.
 If A  B and B  C, then we can infer that A  C
 etc.
 The set of all functional dependencies logically implied by F is the closure
of F.
 We denote the closure of F by F+.
 We will show later on how compute the closure of F

Database System Concepts - 7th Edition 7.19 ©Silberschatz, Korth and Sudarshan
 Trivial Functional Dependencies

 A functional dependency is trivial if it is satisfied by all instances of a

relation
 Example:
 ID, name  ID
 name  name
 In general,    is trivial if   

Database System Concepts - 7th Edition 7.20 ©Silberschatz, Korth and Sudarshan
 Lossless Decomposition

 We can use functional dependencies to show when a decomposition

is lossless.
 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 decomposition 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

Database System Concepts - 7th Edition 7.21 ©Silberschatz, Korth and Sudarshan
 Example

 R = (A, B, C)
F = {A  B, B  C)
 R1 = (A, B), R2 = (B, C)
 Lossless decomposition:
R1  R2 = {B} and B  BC
 R3 = (A, B), R4 = (A, C)
 Lossless decomposition:
R3  R4 = {A} and A  AB
 Notational Note:
 B  BC
is a shorthand notation for
 B  {B, C}

Database System Concepts - 7th Edition 7.22 ©Silberschatz, Korth and Sudarshan
 Dependency Preservation

 Testing functional dependency constraints each time the database is

updated can be costly
 It is useful to design the database in a way that constraints can be
tested efficiently.
 If testing a functional dependency can be done by considering just the
basic relations, then the cost of testing this constraint is low
 When decomposing a relation, it is possible that it is no longer
possible to do the testing without having to perform a Cartesian
Product.
 A decomposition that does not make it computationally hard to
enforce functional dependency is said to be dependency preserving.

Database System Concepts - 7th Edition 7.23 ©Silberschatz, Korth and Sudarshan
 Example

 R = (A, B, C)
F = {A  B, B  C}
 R1 = (A, B), R2 = (B, C)
 Lossless-join decomposition:
 Dependency preserving
 R3 = (A, B), R4 = (A, C)
 Lossless-join decomposition:
 Not dependency preserving
 Cannot check B  C without computing R1 R2

Database System Concepts - 7th Edition 7.24 ©Silberschatz, Korth and Sudarshan
 University Example

 Consider a schema:
dept_advisor(s_ID, i_ID, department_name)
 With function dependencies:
i_ID  dept_name
s_ID, dept_name  i_ID
 In the above design we are forced to repeat the department
name once for each time an instructor participates in a
dept_advisor relationship.
 To fix this, we need to decompose dept_advisor
 Any decomposition will not include all the attributes in
s_ID, dept_name  i_ID
 Thus, the composition is NOT dependency preserving

Database System Concepts - 7th Edition 7.25 ©Silberschatz, Korth and Sudarshan
 Design Goals when Decomposing a Relation

 Lossless join decomposition

 Dependency preserving decomposition

Database System Concepts - 7th Edition 7.26 ©Silberschatz, Korth and Sudarshan
Normal Forms
 Boyce-Codd Normal Form

 A relation schema R is in BCNF, with respect to a set F of functional

dependencies, if for all functional dependencies in F+ of the form

where   R and   R, at least one of the following holds:
    is trivial (i.e.,   )
  is a superkey for R

Database System Concepts - 7th Edition 7.28 ©Silberschatz, Korth and Sudarshan
 Boyce-Codd Normal Form Examples

 Example of a schema that is in BCNF:

instructor (ID, name, salary, dept_name)
because :
 ID  name, salary, dept_name
Is the only meaningful FD and ID is a superkey

 Example schema that is not in BCNF:

in_dep (ID, name, salary, dept_name, building, budget )
because :
 dept_name building, budget
 Holds on in_dep
 But --- dept_name is not a superkey

Database System Concepts - 7th Edition 7.29 ©Silberschatz, Korth and Sudarshan
 Decomposing a Schema into BCNF

 Let R be a schema that is not in BCNF. Let    be the FD

that causes a violation of BCNF.
 We decompose R into:
• ( U  )
• (R-(-))
 In our example of relation in_dep,
in_dep (ID, name, salary, dept_name, building, budget )
We have
  = dept_name
  = building, budget
and in_dep is replaced by
 ( U  ) = ( dept_name, building, budget )
 ( R - (  -  ) ) = ( ID, name, dept_name, salary )
 We are done!

Database System Concepts - 7th Edition 7.30 ©Silberschatz, Korth and Sudarshan
 Decomposing a Schema into BCNF (Cont.)

 In our example of the relation in_dep

in_dep (ID, name, salary, dept_name, building, budget )
we were done after one iteration of replacing the original relation
 In general, we may need to go through several iterations before we
are done.
 The full description of the decomposition algorithm will be presented
shortly.

Database System Concepts - 7th Edition 7.31 ©Silberschatz, Korth and Sudarshan
 BCNF and Dependency Preservation

 It is not always possible to achieve both BCNF and dependency

preservation
 Consider a schema:
dept_advisor (s_ID, i_ID, department_name)
 With functional dependencies:
i_ID  dept_name
s_ID, dept_name  i_ID
 dept_advisor is not in BCNF
 i_ID is not a superkey.
 Any decomposition of dept_advisor will not include all the attributes in
s_ID, dept_name  i_ID
 Thus, the composition is NOT be dependency preserving
 If we insist on dependency preserving, we must consider other normal
forms

Database System Concepts - 7th Edition 7.32 ©Silberschatz, Korth and Sudarshan
 Third Normal Form

 A relation schema R is in third normal form (3NF) if for all:

   in F +

at least one of the following holds:

    is trivial (i.e.,   )
  is a superkey for R
 Each attribute A in {  –  } is contained in a candidate key for R.
 NOTE: each attribute may be in a different candidate key
 If a relation is in BCNF it is in 3NF (since in BCNF one of the first two
conditions above must hold).
 Third condition is a minimal relaxation of BCNF to ensure dependency
preservation (will see why later).

Database System Concepts - 7th Edition 7.33 ©Silberschatz, Korth and Sudarshan
 3NF Example

 Consider a schema:
dept_advisor(s_ID, i_ID, dept_name)
 With function dependencies:
i_ID  dept_name
s_ID, dept_name  i_ID
 Two candidate keys = {s_ID, dept_name}, {s_ID, i_ID }
 We have seen before that dept_advisor is not in BCNF
 It is, however, is in 3NF
 s_ID, dept_name is a superkey
 i_ID  dept_name and i_ID is NOT a superkey, but:
 { dept_name} – {i_ID } = {dept_name } and
 dept_name is contained in a candidate key

Database System Concepts - 7th Edition 7.34 ©Silberschatz, Korth and Sudarshan
 Redundancy in 3NF

 Consider the schema R below, which is in 3NF

• R = (J, K, L )
• F = {JK  L, L  K }
• And an instance table:

 What is wrong with the table?

• Repetition of information
• Need to use null values (e.g., to represent the relationship l2, k2
where there is no corresponding value for J)

Database System Concepts - 7th Edition 7.35 ©Silberschatz, Korth and Sudarshan
 Comparison of BCNF and 3NF

 Advantages to 3NF over BCNF. It is always possible to obtain a 3NF

design without sacrificing losslessness or dependency preservation.
 Disadvantages to 3NF.
 We may have to use null values to represent some of the possible
meaningful relationships among data items.
 There is the problem of repetition of information.
 What should one use in practice? BCNF or 3NF?

Database System Concepts - 7th Edition 7.36 ©Silberschatz, Korth and Sudarshan
 How good is BCNF?

 There are database schemas in BCNF that do not seem to be

sufficiently normalized
 Consider a relation
inst_info (ID, child_name, phone)
 Where an instructor may have more than one phone and can have
multiple children
 Instance of inst_info

Database System Concepts - 7th Edition 7.37 ©Silberschatz, Korth and Sudarshan
 How good is BCNF? (Cont.)

 There are no non-trivial functional dependencies and therefore the

relation is in BCNF
 Repetition of information
 Insertion anomalies:
 if we add a phone 981-992-3443 to 99999, we need to add two tuples
(99999, David, 981-992-3443)
(99999, William, 981-992-3443)
 So, even if a relation is in BCNF it is not good enough.
 The search for a better one goes on

Database System Concepts - 7th Edition 7.38 ©Silberschatz, Korth and Sudarshan
 Higher Normal Forms
 It is better to decompose inst_info into:
 inst_child:

 inst_phone:

 This suggests the need for higher normal forms, such as Fourth
Normal Form (4NF).

Database System Concepts - 7th Edition 7.39 ©Silberschatz, Korth and Sudarshan
Functional-Dependency Theory
 Functional-Dependency Theory Roadmap

 We now consider the formal theory that tells us which functional

dependencies are implied logically by a given set of functional
dependencies.
 We then develop algorithms to generate lossless decompositions into
BCNF and 3NF
 We then develop algorithms to test if a decomposition is dependency-
preserving

Database System Concepts - 7th Edition 7.41 ©Silberschatz, Korth and Sudarshan
 Closure of a Set of Functional Dependencies

 Given a set F set of functional dependencies, there are certain

other functional dependencies that are logically implied by F.
 If A  B and B  C, then we can infer that A  C
 etc.
 The set of all functional dependencies logically implied by F is
the closure of F.
 We denote the closure of F by F+.

Database System Concepts - 7th Edition 7.42 ©Silberschatz, Korth and Sudarshan
 Closure of a Set of Functional Dependencies

 We can compute F+, the closure of F, by repeatedly applying

Armstrong’s Axioms:
 Reflexive rule: if   , then   
 Augmentation rule: if   , then     
 Transitivity rule: if   , and   , then   
 These rules are
 Sound -- generate only functional dependencies that actually
hold, and
 Complete -- generate all functional dependencies that hold.

Database System Concepts - 7th Edition 7.43 ©Silberschatz, Korth and Sudarshan
 Example of F+

 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 - 7th Edition 7.44 ©Silberschatz, Korth and Sudarshan
 Closure of Functional Dependencies (Cont.)

 Additional rules:
 Union rule: If    holds and    holds, then     holds.
 Decomposition rule: If     holds, then    holds and 
  holds.
 Pseudotransitivity rule: If    holds and     holds, then
    holds.
 The above rules can be inferred from Armstrong’s axioms.

Database System Concepts - 7th Edition 7.45 ©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 f1 and 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

 NOTE: We shall see an alternative procedure for this task later

Database System Concepts - 7th Edition 7.46 ©Silberschatz, Korth and Sudarshan
 Closure of Attribute Sets

 Given a set of attributes a, define the closure of a under F

(denoted by a+) as the set of attributes that are functionally
determined by a under F
 Algorithm to compute a+
result := a;
while (changes to result) do
for each    in F do
begin
if   result then
result := result  
end

Database System Concepts - 7th Edition 7.47 ©Silberschatz, Korth and Sudarshan
 Example of Closure of Attribute Sets

 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 and A  AG )
3. result = ABCGH (CG  H and CG  AGBC)
4. result = ABCGHI (CG  I and CG  AGBCH)
 Is AG a candidate key?
 Is AG a super key?
 Does AG  R? Is (AG)+  R
 Is any subset of AG a superkey?
 Does A  R? Is (A)+  R
 Does G  R? Is (G)+  R
 In general: check for each subset of size n-1

Database System Concepts - 7th Edition 7.48 ©Silberschatz, Korth and Sudarshan
 Uses of Attribute Closure

There are several uses of the attribute closure algorithm:

 Testing for superkey of relation scheme R
• 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 F+
• For each   R, we find the closure +, and for each S  +, we
output a functional dependency   S.

Database System Concepts - 7th Edition 7.49 ©Silberschatz, Korth and Sudarshan
Algorithms for Decomposition Using FD
BCNF
 BCNF Decomposition Algorithm

result := {R };
done := false;
compute F+;
while (not done) do
if (there is a schema Ri in result that is not in BCNF)
then begin
let    be a nontrivial functional
dependency that
holds on Ri such that   Ri is not in F+,
and    = ;
result := (result – Ri )  (,  )  (Ri –  ) ;
end
else done := true;

Note: each Ri is in BCNF, and decomposition is lossless-join.

Database System Concepts - 7th Edition 7.52 ©Silberschatz, Korth and Sudarshan
 Example of BCNF Decomposition

 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
 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)

Database System Concepts - 7th Edition 7.53 ©Silberschatz, Korth and Sudarshan
 BCNF Decomposition (Cont.)

 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.

Database System Concepts - 7th Edition 7.54 ©Silberschatz, Korth and Sudarshan
3NF
 Canonical Cover

 Suppose that we have a set of functional dependencies F on a relation

schema.
 Whenever a user performs an update on the relation, the database system
must ensure that the update does not violate any functional dependencies;
that is, all the functional dependencies in F are satisfied in the new
database state.
 If an update violates any functional dependencies in the set F, the system
must roll back the update.
 We can reduce the effort spent in checking for violations by testing a
simplified set of functional dependencies that has the same closure as the
given set.
 This simplified set is termed the canonical cover, denoted Fc
 We do not present the algorithm to compute Fc
 See textbook – Section 7.4.3

Database System Concepts - 7th Edition 7.56 ©Silberschatz, Korth and Sudarshan
 3NF Decomposition Algorithm

Let Fc be a canonical cover for F;

i := 0;
for each functional dependency    in Fc do
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 = R;;
i=i-1;
return (R1, R2, ..., Ri)

Database System Concepts - 7th Edition 7.57 ©Silberschatz, Korth and Sudarshan
 3NF Decomposition Algorithm (Cont.)

Above algorithm ensures

 Each relation schema Ri is in 3NF
 Decomposition is dependency preserving and lossless-join

Database System Concepts - 7th Edition 7.58 ©Silberschatz, Korth and Sudarshan
 3NF Decomposition: An Example

 Relation schema:
cust_banker_branch = (customer_id, employee_id, branch_name, type )
 The functional dependencies for this relation schema are:
 customer_id, employee_id  branch_name, type
 employee_id  branch_name
 customer_id, branch_name  employee_id
 We first compute a canonical cover
 branch_name is extraneous in the r.h.s. of the 1st 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

Database System Concepts - 7th Edition 7.59 ©Silberschatz, Korth and Sudarshan
 3NF Decompsition Example (Cont.)

 The for loop generates following 3NF schema:

(customer_id, employee_id, type )
(employee_id, branch_name)
(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:
(customer_id, employee_id, type)
(customer_id, branch_name, employee_id)

Database System Concepts - 7th Edition 7.60 ©Silberschatz, Korth and Sudarshan
 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.

Database System Concepts - 7th Edition 7.61 ©Silberschatz, Korth and Sudarshan
 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.

Database System Concepts - 7th Edition 7.62 ©Silberschatz, Korth and Sudarshan
Multivalued Dependencies
 Higher Normal Forms

 We saw before the relation:

inst_info(ID, child_name, phone_number)
which is in BCNF but still suffers from redundancy of data
 This example indicates that we may need to look for other
“normal” forms that do not suffer from the redundancy problem
 These normal forms require the use of more complex form of
dependencies among the various attributes

Database System Concepts - 7th Edition 7.64 ©Silberschatz, Korth and Sudarshan
 Multivalued Dependencies (MVD)

 Let R be a relation schema and let   R and   R. The

multivalued dependency
  
holds on R if in any legal relation r(R), for all pairs of tuples t1
and t2 in r such that t1[] = t2 [], there exist tuples t3 and t4 in
r such that:
t1[] = t2 [] = t3 [] = t4 []
t3[] = t1 []
t3[R – ] = t2[R – ]
t4 [] = t2[]
t4[R – ] = t1[R – ]

Database System Concepts - 7th Edition 7.65 ©Silberschatz, Korth and Sudarshan
 MVD -- Tabular representation
 Tabular representation of   

Database System Concepts - 7th Edition 7.66 ©Silberschatz, Korth and Sudarshan
 MVD (Cont.)

 Let R be a relation schema with a set of attributes that are partitioned

into 3 nonempty subsets.
Y, Z, W
 We say that Y  Z (Y multidetermines Z ) if and only if, for all
possible relations r (R )
 If
< y1, z1, w1 >  r and < y1, z2, w2 >  r
then
< y1, z1, w2 >  r and < y1, z2, w1 >  r
 Note that since the behavior of Z and W are identical it follows that
Y  Z if Y  W

Database System Concepts - 7th Edition 7.67 ©Silberschatz, Korth and Sudarshan
 Example
 In our example:
ID  child_name
ID  phone_number
 The above formal definition is supposed to formalize the notion
that given a particular value of Y (ID) it has associated with it a set
of values of Z (child_name) and a set of values of W
(phone_number), and these two sets are in some sense
independent of each other.
 Note:
 If Y  Z then Y  Z
 Indeed, we have (in above notation) Z1 = Z2

Database System Concepts - 7th Edition 7.68 ©Silberschatz, Korth and Sudarshan
 Use of Multivalued Dependencies
 We use multivalued dependencies in two ways:
1. To test relations to determine whether they are legal under a given
set of functional and multivalued dependencies
2. To specify constraints on the set of legal relations. We shall concern
ourselves only with relations that satisfy a given set of functional and
multivalued dependencies.
 If a relation r fails to satisfy a given multivalued dependency, we can
construct a relations r that does satisfy the multivalued dependency by
adding tuples to r.

Database System Concepts - 7th Edition 7.69 ©Silberschatz, Korth and Sudarshan
 Theory of MVDs

 From the definition of multivalued dependency, we can derive the

following rule:
 If   , then   
That is, every functional dependency is also a multivalued dependency
 The closure D+ of D is the set of all functional and multivalued
dependencies logically implied by D.
 We can compute D+ from D, using the formal definitions of functional
dependencies and multivalued dependencies.
 We can manage with such reasoning for very simple multivalued
dependencies, which seem to be most common in practice
 For complex dependencies, it is better to reason about sets of
dependencies using a system of inference rules (Chapter 28).

Database System Concepts - 7th Edition 7.70 ©Silberschatz, Korth and Sudarshan
 Fourth Normal Form
 A relation schema R is in 4NF with respect to a set D of functional and
multivalued dependencies if for all multivalued dependencies in D + of the
form   , where   R and   R, at least one of the following hold:
    is trivial (i.e.,    or    = R)
  is a superkey for schema R
 If a relation is in 4NF it is in BCNF

Database System Concepts - 7th Edition 7.71 ©Silberschatz, Korth and Sudarshan
 Restriction of Multivalued Dependencies

 The restriction of D to Ri is the set Di consisting of

 All functional dependencies in D+ that include only attributes of Ri
 All multivalued dependencies of the form
  (  Ri)
where   Ri and    is in D+

Database System Concepts - 7th Edition 7.72 ©Silberschatz, Korth and Sudarshan
 4NF Decomposition Algorithm

result: = {R};
done := false;
compute D+;
Let Di denote the restriction of D+ to Ri
while (not done)
if (there is a schema Ri in result that is not in 4NF) then
begin
let    be a nontrivial multivalued dependency that holds
on Ri such that   Ri is not in Di, and ;
result := (result - Ri)  (Ri - )  (, );
end
else done:= true;
Note: each Ri is in 4NF, and decomposition is lossless-join

Database System Concepts - 7th Edition 7.73 ©Silberschatz, Korth and Sudarshan
 Example

 R =(A, B, C, G, H, I)
D ={ A  B
B  HI
CG  H }
 R is not in 4NF since A  B and A is not a superkey for R
 Decomposition
a) R1 = (A, B) (R1 is in 4NF)
b) R2 = (A, C, G, H, I) (R2 is not in 4NF, decompose into R3 and
R 4)
c) R3 = (C, G, H) (R3 is in 4NF)
d) R4 = (A, C, G, I) (R4 is not in 4NF, decompose into R5 and
R 6)
 A  B and B  HI  A  HI, (MVD transitivity), and
 and hence A  I (MVD restriction to R4)
e) R5 = (A, I) (R5 is in 4NF)
f) R6 = (A, C, G) (R6 is in 4NF)

Database System Concepts - 7th Edition 7.74 ©Silberschatz, Korth and Sudarshan
Additional Issues
 Further Normal Forms

 Join dependencies generalize multivalued dependencies

 lead to project-join normal form (PJNF) (also called fifth
normal form)
 A class of even more general constraints, leads to a normal form
called domain-key normal form.
 Problem with these generalized constraints: are hard to reason
with, and no set of sound and complete set of inference rules
exists.
 Hence rarely used

Database System Concepts - 7th Edition 7.76 ©Silberschatz, Korth and Sudarshan
 Overall Database Design Process

We have assumed that a schema R is given

 R could have been generated when converting E-R diagram to a
set of tables.
 R could have been a single relation containing all attributes that
are of interest (called universal relation).
 R could have been the result of some ad hoc design of relations,
which we then test/convert to normal form.

Database System Concepts - 7th Edition 7.77 ©Silberschatz, Korth and Sudarshan
 ER Model and Normalization
 When an E-R diagram is carefully designed, identifying all entities
correctly, the tables generated from the E-R diagram should not need
further normalization.
 However, in a real (imperfect) design, there can be functional
dependencies from non-key attributes of an entity to other attributes of
the entity
 Example: an employee entity with
 Attributes
department_name and building,
 Functional dependency
department_name building
 Good design would have made department an entity
 Functional dependencies from non-key attributes of a relationship set
possible, but rare --- most relationships are binary

Database System Concepts - 7th Edition 7.78 ©Silberschatz, Korth and Sudarshan
 Denormalization for Performance

 May want to use non-normalized schema for performance

 For example, displaying prereqs along with course_id, and title
requires join of course with prereq
 Alternative 1: Use denormalized relation containing attributes of
course as well as prereq with all above attributes
 Faster lookup
 Extra space and extra execution time for updates
 Extra coding work for programmer and possibility of error in extra
code
 Alternative 2: use a materialized view defined a course prereq
 Benefits and drawbacks same as above, except no extra coding
work for programmer and avoids possible errors

Database System Concepts - 7th Edition 7.79 ©Silberschatz, Korth and Sudarshan
 Other Design Issues

 Some aspects of database design are not caught by normalization

 Consider a relation scheme:
earnings (company_id, year, amount )
 It could be replaced by a number of schemes:
earnings_2004, earnings_2005, earnings_2006, etc.,
all on the schema (company_id, earnings).
 The above schemes are in BCNF, but make querying across years
difficult and needs new table each year

Database System Concepts - 7th Edition 7.80 ©Silberschatz, Korth and Sudarshan
 Other Design Issues (Cont.)

 The relation scheme:

earnings (company_id, year, amount )
 Could be replaced by a scheme:
company_year (company_id, earnings_2004, earnings_2005,
earnings_2006)
 The above scheme is
 In BCNF, but also makes querying across years difficult and
requires new attribute each year.
 Is an example of a crosstab, where values for one attribute
become column names
 Used in spreadsheets, and in data analysis tools

Database System Concepts - 7th Edition 7.81 ©Silberschatz, Korth and Sudarshan
 Modeling Temporal Data

 Temporal data have an association time interval during which the

data are valid.
 A snapshot is the value of the data at a particular point in time
 Several proposals to extend ER model by adding valid time to
 Attributes, e.g., address of an instructor at different points in time
 Entities, e.g., time duration when a student entity exists
 Relationships, e.g., time during which an instructor was
associated with a student as an advisor.
 But no accepted standard
 Adding a temporal component results in functional dependencies like
ID  street, city
not holding, because the address varies over time
 A temporal functional dependency X  Y holds on schema R if the
functional dependency X  Y holds on all snapshots for all legal
instances r(R).

Database System Concepts - 7th Edition 7.82 ©Silberschatz, Korth and Sudarshan
 Modeling Temporal Data (Cont.)
 In practice, database designers may add start and end time attributes
to relations
 E.g., course(course_id, course_title) is replaced by
course(course_id, course_title, start, end)
 Constraint: no two tuples can have overlapping valid times
 Hard to enforce efficiently
 Foreign key references may be to current version of data, or to data at
a point in time
 E.g., student transcript should refer to course information at the
time the course was taken

Database System Concepts - 7th Edition 7.83 ©Silberschatz, Korth and Sudarshan
Additional Material
Proof of Correctness of 3NF Decomposition Algorithm
 Correctness of 3NF Decomposition Algorithm

 3NF decomposition algorithm is dependency preserving (since there is a

relation for every FD in Fc)
 Decomposition is lossless
 A candidate key (C ) is in one of the relations Ri in decomposition
 Closure of candidate key under Fc must contain all attributes in R.
 Follow the steps of attribute closure algorithm to show there is only
one tuple in the join result for each tuple in Ri

Database System Concepts - 7th Edition 7.86 ©Silberschatz, Korth and Sudarshan
 Correctness of 3NF Decomposition (Cont.)

 Claim: if a relation Ri is in the decomposition generated by the

above algorithm, then Ri satisfies 3NF.
 Proof:
 Let Ri be generated from the dependency   
 Let   B be any non-trivial functional dependency on Ri.
(We need only consider FDs whose right-hand side is a
single attribute.)
 Now, B can be in either  or  but not in both. Consider each
case separately.

Database System Concepts - 7th Edition 7.87 ©Silberschatz, Korth and Sudarshan
 Correctness of 3NF Decomposition (Cont.)

 Case 1: If B in :
 If  is a superkey, the 2nd condition of 3NF is satisfied
 Otherwise  must contain some attribute not in 
 Since   B is in F+ it must be derivable from Fc, by using attribute
closure on .
 Attribute closure not have used  . If it had been used,  must be
contained in the attribute closure of , which is not possible, since we
assumed  is not a superkey.
 Now, using  (- {B}) and   B, we can derive  B
(since    , and B   since   B is non-trivial)
 Then, B is extraneous in the right-hand side of  ; which is not
possible since   is in Fc.
 Thus, if B is in  then  must be a superkey, and the second
condition of 3NF must be satisfied.

Database System Concepts - 7th Edition 7.88 ©Silberschatz, Korth and Sudarshan
 Correctness of 3NF Decomposition (Cont.)

 Case 2: B is in .
 Since  is a candidate key, the third alternative in the definition of
3NF is trivially satisfied.
 In fact, we cannot show that  is a superkey.
 This shows exactly why the third alternative is present in the
definition of 3NF.
Q.E.D.

Database System Concepts - 7th Edition 7.89 ©Silberschatz, Korth and Sudarshan
Extra
 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 22: Object Based Databases)

Database System Concepts - 7th Edition 7.91 ©Silberschatz, Korth and Sudarshan
 First Normal Form (Cont.)

 Atomicity is actually a property of how the elements of the domain are

used.
 Example: Strings would normally be considered indivisible
 Suppose that students are given roll numbers which are strings of the
form CS0012 or EE1127
 If the first two characters are extracted to find the department, the
domain of roll numbers is not atomic.
 Doing so is a bad idea: leads to encoding of information in application
program rather than in the database.

Database System Concepts - 7th Edition 7.92 ©Silberschatz, Korth and Sudarshan
 End of Chapter 7

Database System Concepts, 7th Ed.

©Silberschatz, Korth and Sudarshan
See www.db-book.com for conditions on re-use