Copyright © 2016 Ramez Elmasri and Shamkant B.

Navathe
 CHAPTER 14

Basics of Functional Dependencies

and Normalization for Relational
Databases

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 14- 2

Chapter Outline
 1 Informal Design Guidelines for Relational Databases
 1.1 Semantics of the Relation Attributes
 1.2 Redundant Information in Tuples and Update Anomalies
 1.3 Null Values in Tuples
 1.4 Spurious Tuples

 2 Functional Dependencies (FDs)

 2.1 Definition of Functional Dependency

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 14- 3

Chapter Outline
 3 Normal Forms Based on Primary Keys
 3.1 Normalization of Relations
 3.2 Practical Use of Normal Forms
 3.3 Definitions of Keys and Attributes Participating in Keys
 3.4 First Normal Form
 3.5 Second Normal Form
 3.6 Third Normal Form

 4 General Normal Form Definitions for 2NF and 3NF (For

Multiple Candidate Keys)

 5 BCNF (Boyce-Codd Normal Form)

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 14- 4

Chapter Outline
 6 Multivalued Dependency and Fourth Normal Form

 7 Join Dependencies and Fifth Normal Form

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 14- 5

1. Informal Design Guidelines for
Relational Databases (1)
 What is relational database design?
 The grouping of attributes to form "good" relation
schemas
 Two levels of relation schemas
 The logical "user view" level
 The storage "base relation" level
 Design is concerned mainly with base relations
 What are the criteria for "good" base relations?

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 14- 6

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 Noferferferfewrmal Form)
 - BCNF (Boyce-Codd Normal Form)
 Additional types of dependencies, further normal forms,
relational design algorithms by synthesis are discussed in
Chapter 15

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 14- 7

1.1 Semantics of the Relational
Attributes must be clear
 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 © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 14- 8

Figure 14.1 A simplified COMPANY
relational database schema

Figure 14.1 A
simplified COMPANY
relational database
schema.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 14- 9

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe
Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe
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 © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 14- 12

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe
EXAMPLE OF AN INSERT ANOMALY
 Consider the relation:
 EMP_PROJ(Emp#, Proj#, Ename, Pname,
No_hours)
 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 © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 14- 14

EXAMPLE OF A DELETE ANOMALY
 Consider the relation:
 EMP_PROJ(Emp#, Proj#, Ename, Pname,
No_hours)
 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 © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 14- 15

EXAMPLE OF AN UPDATE ANOMALY
 Consider the relation:
 EMP_PROJ(Emp#, Proj#, Ename, Pname,
No_hours)
 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 © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 14- 16

Figure 14.3 Two relation schemas
suffering from update anomalies

Figure 14.3
Two relation schemas
suffering from update
anomalies. (a)
EMP_DEPT and (b)
EMP_PROJ.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 14- 17

Figure 14.4 Sample states for
EMP_DEPT and EMP_PROJ
Figure 14.4
Sample states for EMP_DEPT
and EMP_PROJ resulting from
applying NATURAL JOIN to the
relations in Figure 14.2. These
may be stored as base relations
for performance reasons.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 14- 18

Guideline for 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 © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 14- 19

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 © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 14- 20

1.4 Generation of Spurious Tuples – avoid
at any cost
 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 © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 14- 21

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe
Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe
Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe
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. (See
Chapter 15).

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 14- 25

2. Functional Dependencies
 Functional dependencies (FDs)
 Are used to specify formal measures of the
"goodness" of relational designs
 Is a constarint between two set of attributes from
the database
 A set of attributes X functionally determines a set
of attributes Y if the value of X determines a
unique value for Y(Y is functionally dependent on
X) denoted as XY

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 14- 26

2.1 Defining Functional Dependencies
 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)
 Written as X  Y; can be displayed graphically on a
relation schema as in Figures. ( denoted by the arrow: ).
 FDs are derived from the real-world constraints on the
attributes

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 14- 27

Examples of FD constraints (1)
 Social security number determines employee
name

SSN  ENAME
 Project number determines project name and
location

PNUMBER  {PNAME, PLOCATION}
 Employee ssn and project number determines the
hours per week that the employee works on the
project

{SSN, PNUMBER}  HOURS

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 14- 28

Examples of FD constraints (2)
 An FD is a property of the attributes in the
schema R
 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 © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 14- 29

Defining FDs from instances
 Note that in order to define the FDs, we need to
understand the meaning of the attributes involved
and the relationship between them.
 An FD is a property of the attributes in the
schema R
 Given the instance (population) of a relation, all
we can conclude is that an FD may exist between
certain attributes.
 What we can definitely conclude is – that certain
FDs do not exist because there are tuples that
show a violation of those dependencies.
Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 14- 30
Figure 14.7 Ruling Out FDs
Note that given the state of the TEACH relation, we can
say that the FD: Text → Course may exist. However, the
FDs Teacher → Course, Teacher → Text and
Couse → Text are ruled out.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 14- 31

Figure 14.8 What FDs may exist?
 A relation R(A, B, C, D) with its extension.
 Which FDs may exist in this relation?

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 14- 32