CHAPTER 4 PART 2 - B:

LOGICAL DATABASE DESIGN &

THE RELATIONAL MODEL
(PART II - NORMALIZATION)

Modern Database Management

12th Edition
Jeff Hoffer, Ramesh Venkataraman,
Heikki Topi

Copyright © 2016 Pearson Education, Inc.

OBJECTIVES – PART 2
 Define terms
 List five properties of relations
 State two properties of candidate keys
 Define first, second, and third normal form
 Describe problems from merging relations
 Transform E-R and EER diagrams to relations
 Create tables with entity and relational
integrity constraints
 Use normalization to convert anomalous
tables to well-structured relations

Chapter 4 Copyright © 2016 Pearson Education, Inc. 4-2

 RELATION [REVIEW FROM PART I]
 A relation is a named, two-dimensional table of data.
 A table consists of rows (records) and columns (attributes or
fields).
 Requirements for a table to qualify as a relation:
 It must have a unique name.
 Every attribute value must be atomic (not multivalued, not composite).
 Every row must be unique (can’t have two rows with exactly the same
values for all their fields).
 Attributes (columns) in tables must have unique names.
 The order of the columns must be irrelevant.
 The order of the rows must be irrelevant.

NOTE: all relations are in 1st Normal form

Chapter 4 Copyright © 2016 Pearson Education, Inc. 4-3
CORRESPONDENCE WITH E-R MODEL
(FROM PART 1 W NEW ANNOTATION)
 Relations (tables) correspond with entity types or
with many-to-many relationship types.
 Rows correspond with entity instances or with many-
to-many relationship instances.
 Columns correspond with attributes.

 NOTE: The word relation (in relational database) is

NOT the same as the word relationship (in E-R
model).
 Relations: tables;
 relationships: interaction among tables (PK-FK pair)

Chapter 4 Copyright © 2016 Pearson Education, Inc. 4-4

DATA NORMALIZATION
(START OF NEW SLIDES)

 Normalization is a formal process for

deciding which attributes should be
grouped together in a relation so that all
anomalies are removed
 Normalization is based on normal forms
and functional dependencies
 Normal form: 1st, 2nd, 3rd
 Functional dependencies: full, partial,
transitive
Chapter 4 Copyright © 2016 Pearson Education, Inc. 4-5
DATA NORMALIZATION

 The process of decomposing relations

with anomalies
 to produce smaller, well-structured
relations
 Primarily a tool to validate and improve a
logical design so that it satisfies certain
constraints that
 avoid unnecessary duplication of data

 Four-point goals of normalization: P. 179

Chapter 4 Copyright © 2016 Pearson Education, Inc. 4-6
WELL-STRUCTURED RELATIONS
 A relation that
 contains minimal data redundancy and
 allows users to insert, delete, and update rows
 without causing data inconsistencies
 Goal is to avoid anomalies
 Insertion Anomaly–adding new rows forces user to create
duplicate data
 Deletion Anomaly–deleting rows may cause a loss of data
that would be needed for other future rows
 Modification Anomaly–changing data in a row forces
changes to other rows because of duplication
General rule of thumb: A table should pertain to only
one entity type Make one table contain ONLY ONE entity
Chapter 4 Copyright © 2016 Pearson Education, Inc. 4-7
 Figure 4.22 Steps in normalization

1NF

2NF

3NF 3rd normal form is

generally considered
sufficient

Chapter 4 Copyright © 2016 Pearson Education, Inc. 4-8

PURPOSE OF NORMALIZATION (2017 NEW)

 Normalization takes a “big”, clumsy table

(containing multiple themes/multiple logical
dependencies), and decompose it into several
smaller tables that are:
1. One theme/logical dependency in each
table;
2. Each “smaller” table is in full dependency;
3. With referential integrity among the related
tables
Above three: Final status of normalization
Chapter 4 Copyright © 2016 Pearson Education, Inc. 4-9
 FUNCTIONAL DEPENDENCIES AND KEYS
 Functional Dependency: The value of one
attribute (the determinant) determines the
value of another attribute (the determinee)
A determinant in a database table is any
attribute that you can use to determine the
values assigned to other attribute(s) in the same
row.
 If we call the determinant “D”, and other
Example:
attributes “A”, then
 Knowing D (value), we can know A (values)
P. 180
Notation  Denoted as: D  A
 Or: “Given a D-value, we can have a specific A-value”

Chapter 4 Copyright © 2016 Pearson Education, Inc. 4-10

FUNCTIONAL DEPENDENCIES AND KEYS
(CONT)
 Candidate Key:
A unique identifier. One of the candidate keys
will become the primary key
 E.g.
perhaps there is both credit card number and
SS# in a table…in this case both can be candidate
keys
 The determinant in a relation is a …
 Notation of functional dependencies
(Func. Dep.): P. 181, illustrated w Fig 4-23
 Note: Distinguish “curvy arrows” (Ref.
Integrity) and “straight arrows” (Func Dep)
Chapter 4 Copyright © 2016 Pearson Education,Example:
Inc. 4-11
 … ref.
integrity
arrows

Chapter 4 Copyright © 2016 Pearson Education, Inc. 4-12

DIFFERENTIAE FUNC. DEPEND. ARROWS FROM
REF INTEGRITY ARROWS (NEW 2017)

Perspective Func. Dep. Ref Integrity

Scope Within relation Across relations
Shape Straight line Curvy line
Connection Determinant FK  PK
 determinee
End points Every field/ ONLY between
attribute – ALL the PK/FK; only
fields must be TWO fields (FK,
involved PK) involved
Chapter 4 Copyright © 2016 Pearson Education, Inc. 4-13
 EXAMPLE–FIGURE 4-2B

Question–Is this a relation? Answer–Yes: Unique rows and

no multivalued attributes

Question–What’s the primary key? Answer–Composite: EmpID,

CourseTitle
Chapter 4 Copyright © 2016 Pearson Education, Inc. 4-14
 ANOMALIES IN THIS TABLE
1. Insertion–can’t enter a new employee without having
the employee take a class
2. Deletion–if we remove employee 140, we lose
information about the existence of a Tax Acc class
3. Modification–giving a salary increase to employee
100 forces us to update multiple records
Why do these anomalies exist?
Because there are two themes (entity types) in this
one relation: ____________ and _______
This results in data duplication and an unnecessary
dependency between the entities
Chapter 4 Copyright © 2016 Pearson Education, Inc. 4-15
 EXAMPLE–FIGURE 4-2B

Theme? Theme?

Chapter 4 Copyright © 2016 Pearson Education, Inc. 4-16

FULL DEPENDENCY (“FUNC DEP”)

 The dependency that departs from the

primary key (could be single-field or composite)
and ends at non-key attributes
 The legitimate dependency
 Relations ALWAYS have a full
dependency – every relation MUST have
There are not always partial or transitive
dependencies

Chapter 4 Copyright © 2016 Pearson Education, Inc. 4-17

 Figure 4.22 Steps in normalization
 From 1st normal form (1NF) to 2nd normal form
(2NF):
 Remove partial dependencies  2nd normal form
PD  Partial dependency (“PD”): when there are two
attributes working as the determinant (______
key), some determinees depend ONLY on one
PART of the key

A more general Not

definition of 2NF: always
exist
PP. 185-6
Chapter 4 Copyright © 2016 Pearson Education, Inc. 4-18
 Figure 4.22 Steps in normalization

 From 2nd normal form (2NF) to 3rd normal form

(3NF):
 Remove transitive dependencies  3rd normal
form
TD  Transitive dependency (“TD”): when there are
non-key attributes acting/behaving as a
determinant (of other attributes) - determinees
depend on a non-key attribute

Not
always
exist
Chapter 4 Copyright © 2016 Pearson Education, Inc. 4-19
PARTIAL, TRANSITIVE, AND FULL FUNCTIONAL
DEPENDENCIES
 Partial: Note the PK here has TWO PARTS
 Transitive: Like skipping a stone

 Full: non-key attributes FULLY depend on whole

set pf key attributes

Chapter 4 Copyright © 2016 Pearson Education, Inc. 4-20

EXISTENCE OF PARTIAL, TRANSITIVE, AND FULL
FUNCTIONAL DEPENDENCIES (NEW 2017)
 Full: non-key attributes FULLY depend on whole
set of key attributes (can be one field, can be 2+)
 ALL relations have full dependencies – always exist
 Partial: Note the PK here has TWO PARTS
 Onlywhen there is a ____________ key need we
examine for PD
 not always exist

 Transitive: Like skipping a stone

 Not always exist
Chapter 4 Copyright © 2016 Pearson Education, Inc. 4-21
FIRST NORMAL FORM
 No multivalued attributes
 Every attribute value is atomic
 Fig. 4-25 is not in 1st Normal Form
(multivalued attributes)  it is not a
relation.
 Fig. 4-26 is in 1st Normal form.
 All relations are in 1st Normal Form.

Chapter 4 Copyright © 2016 Pearson Education, Inc. 4-22

 23

Fig 4-25 Table with multivalued attributes, not in 1 NF

Note: this is NOT a relation

Chapter 4 Copyright © 2016 Pearson Education, Inc. 4-23

 24

Fig 4-26 Table w no multivalued attributes & w unique rows,

in 1NF
Repeat

Repeat

Note: this is a relation, but not a well-structured one

Chapter 4 Copyright © 2016 Pearson Education, Inc. 4-24

 25

ANOMALIES IN THIS TABLE (4-26)

 Insertion–if new product is ordered for order 1007 of
existing customer, customer data must be re-entered,
causing duplication
 Deletion–if we delete the customer 1006, we lose
information concerning dining table’s finish and price
 Update–changing the price of product ID 4 requires
update in multiple records

Why do these anomalies exist?

Because there are multiple themes (entity types) in
one relation. This results in duplication and an
unnecessary dependency between the entities
Chapter 4 Copyright © 2016 Pearson Education, Inc. 4-25
Intuitive examination for the “themes” in the following table

Attributes in Attributes in
Attributes in 3rd theme
1st theme 2nd theme

Chapter 4 Copyright © 2016 Pearson Education, Inc. 4-26

 27

SECOND NORMAL FORM

 1NF, PLUS every non-key attribute is fully

functionally dependent on the ENTIRE
primary key
 Every non-key attribute must be defined by the
entire key, not by only one part of the key

 No partial functional dependencies

 Discussion: “Entire primary key” implies that this key is a
________________ key?
 Therefore, 2NF is relevant only when the original relationship
is _____-to-_____? (hint: cardinality)
Chapter 4 Copyright © 2016 Pearson Education, Inc. 4-27
 Figure 4-27 Functional dependency diagram for INVOICE

OrderID  OrderDate, CustomerID, CustomerName, CustomerAddress

ProductID  ProductDescription, ProductFinish, ProductStandardPrice
OrderID, ProductID  OrderQuantity
Need to know not only
CustomerID  CustomerName, CustomerAddress func deps, but also the
TYPES of func deps

Therefore, NOT in 2nd Normal Form So, what is PD?

TD? FD?
Chapter 4 Copyright © 2016 Pearson Education, Inc. 4-28
 29

SECOND NORMAL FORM Exercise 1

1. Solution (p.185): create a new relation for
each primary key component attribute that
is determinant in a partial dependency
 That attribute is the primary key in the new relation
2. Move the non-key attributes that are
dependent on this primary key attribute
(“part”) from the old relation to the new
relation (remove them from the old relation)
 When A+B is key, (A+B) should c, d, e, f
 *IF* (A+B)f, and Ac,d; Be - violation
Chapter 4 Copyright © 2016 Pearson Education, Inc. 4-29
 Print 4-30 and 4-31 on
SECOND NORMAL FORM ONE sheet of paper
helps to visualize
 When A+B is key, then (A+B) should c, d, e, f
 IF (A+B)f, and Ac,d; Be - violation

1
3

A B C D E F

2 A is not key, B is not key;

A+B is key
Chapter 4 Copyright © 2016 Pearson Education, Inc. 4-30
 SECOND NORMAL FORM - SOLUTION
 IF (A+B)f, and Ac,d; Be – violation
 Solution: decompose to Relation (1), (2) , and
relation (3)

1 A B F

2 A C D

3 B E
Chapter 4 Copyright © 2016 Pearson Education, Inc. 4-31
 Print 4-32 and 4-33 on ONE sheet of paper helps to visualize
Figure 4-27 Functional dependency diagram for INVOICE

OrderID  OrderDate, CustomerID, CustomerName, CustomerAddress

ProductID  ProductDescription, ProductFinish, ProductStandardPrice
Partial dependency (PD)
OrderID, ProductID  OrderQuantity
CustomerID  CustomerName, CustomerAddress

NOT in 2nd Normal Form Remove PD

Chapter 4 Copyright © 2016 Pearson Education, Inc. 4-32
 Figure 4-28 Removing partial dependencies (PD)

Partial dependencies are removed, but there are still transitive

dependencies “In, and then out”

Chapter 4 Copyright © 2016 Pearson Education, Inc. 33 4-33

THIRD NORMAL FORM

 2NF PLUS no transitive dependencies (NO func

deps on non-primary-key attributes)
 Note: called transitive because the primary key is a
determinant for another attribute, which in turn is a
determinant for a third
 Wrong: Ac and c  d in a relation

A C D
 Solution (p186): Non-key determinant (“c”here) with
transitive dependencies go into a new relation; non-
key determinant becomes primary key in the new
table and stays as foreign key in the old table
 Dependents are REMOVED from the old relation
Chapter 4 Copyright © 2016 Pearson Education, Inc. 4-34
 35
Print 4-33 and 4-34 on ONE sheet of paper helps to visualize
Figure 4-29 Removing partial dependencies

Old relation
Getting it into
Third Normal
Form

New relation

Transitive dependencies are removed

Transitive dependency: Acd.

Solution: Ac, and also
cd , a separate, different relation
Chapter 4 Copyright © 2016 Pearson Education, Inc. 4-35
 36

PARTIAL VS TRANSITIVE DEPENDENCY (1)

 Partial: “part” of the key determines others;

 So only happens when there is a __________ key
 (A+B)  f; yet also exists B  e
 Func dep arrows: two arrows out from the
composite key should JOINTLY enter all non-key
fields; but in violation there are arrows coming out
from ONLY ONE PART of the composite key

A B E F
Chapter 4 Copyright © 2016 Pearson Education, Inc. 4-36
PARTIAL VS TRANSITIVE DEPENDENCY
 Transitive: Key determines non-key-1, and non-
key-1 determines non-key-2
 “You are NOT a key! So you can’t determine
others!”
 A (key)  c (non-key-1)  d (non-key-2)

 Func dep arrows: arrows come out ONLY from the

key; but in violation there are arrows also coming
out from a non-key attribute
A B C D

Chapter 4 Copyright © 2016 Pearson Education, Inc. 4-37

PARTIAL VS TRANSITIVE DEPENDENCY
1

2
A B C D E F G H
3

1: _________________________ dependency?

2: _________________________ dependency?

3: _________________________ dependency?
Chapter 4 Copyright © 2016 Pearson Education, Inc. 4-38
PARTIAL VS TRANSITIVE - NORMALIZED 39

2
A B C D E F 2NF

3 The central part of 3NF

1
A B F B 2 E

A C D
A C C D
3
3
Chapter 4 Copyright © 2016 Pearson Education, Inc. 4-39
PARTIAL VS TRANSITIVE DEPENDENCY
1
There is ALWAYS a
________ dependency;
A B C D E There may or may not be
_______ or ___________
dependencies.
3

1: _________________________ dependency?
3: _________________________ dependency?

Q: Will we have the issue of partial dependency in

this case?  conclusion re where would each exist
Chapter 4 Copyright © 2016 Pearson Education, Inc. 4-40
RECAP: IDENTIFY PD AND TD

 2NF: No partial dependency

 Implies: composite key
 Dependencies with the determinant being PART
of the composite key
 3NF: No transitive dependency
 Dependencies with the determinant being non-
key

A B C D E F G H

Chapter 4 Copyright © 2016 Pearson Education, Inc. 4-41

ANATOMY OF FUNCTIONAL DEPENDENCIES (1)

A B C D E F G H K

 [A+B] G, H - ?
B  C - ? Types?
 A  D, E, F - ?
D  E - ?
Chapter 4 Copyright © 2016 Pearson Education, Inc. 4-42
ANATOMY OF FUNCTIONAL DEPENDENCIES (2)

A B C D E F G H K

 A+B: 2 fields jointly have 1 arrow out

 A: 2 arrows out
 B: 2 arrows out
 D: 1 arrow in, 1 arrow out
 E: 2 arrows in
Chapter 4 Copyright © 2016 Pearson Education, Inc. 4-43
ANATOMY OF FUNCTIONAL DEPENDENCIES (3)

A B C D E F G H

 A: 1 arrow out
 B: 1 arrow in, 1 arrow out
 D: 1 arrow in, 1 arrow out
 C: 2 arrows in
 E: 2 arrows in
Chapter 4 Copyright © 2016 Pearson Education, Inc. 4-44
 45

Chapter 4 Copyright © 2016 Pearson Education, Inc. 4-45

 SIMPLE RULES BY EXAMINING ARROWS
Arrow wrt 1 field Field type/Dependency type

One arrow out

One arrow in
One in, one out
Two arrows out
Two arrows in
“No arrow”
Chapter 4 Copyright © 2016 Pearson Education, Inc. 4-46
RECAP REF INTEGRITY VS FUNC DEP:
THIS ARROW IS NOT “THAT ARROW”
1. The arrows we’re discussing here are about
_________ _________
2. In Part I of the chapter we also had curvy
arrows; those were about ___________
__________
 In “1” above, arrow starts from __________ and
ends at _____________ (in a _______ _______)
 In “2” above, arrow starts from __________ and
ends at _____________ (in a _______ _______)
 -- so, don’t confuse the two!
Chapter 4 Copyright © 2016 Pearson Education, Inc. 4-47
47
COMMON ERRORS IN NORMALIZATION (1)

Chapter 4 Copyright © 2016 Pearson Education, Inc. 4-48

COMMON ERRORS IN NORMALIZATION (2)

A A A1 A2 A3 A4 B1

B B1 B2 B3 B4 B5
B

W/o arrows, can you

tell the mistakes?
A A1 A2 A3 A4

B B1 B2 B3 A1 A4

Chapter 4 Copyright © 2016 Pearson Education, Inc. 4-49

COMMON ERRORS IN NORMALIZATION (3) (4)
 Common error #3:
 The number of functional dependencies in 1NF does not
match the number of relations in 3NF
 Example: In 1NF, 5 func. deps were identified; after
normalization, in 3NF there were only 4 relations (tables)
 Common error #4:
 The fields in the relations in 3NF are not organized in the
same relations (tables) as the fields were in their
corresponding func. deps in 1NF
 Example: Say in the original 1NF, the fields were identified
to belong to several func deps that they were grouped as:
A,C,D; B,E,F; A,B,G,H
 But in the final 3NFs, the relations contain fields as:
A,C,D,H; B,E,F; A,B,G
Chapter 4 Copyright © 2016 Pearson Education, Inc. 4-50
MERGING RELATIONS
 View Integration–Combining entities from multiple
ER models into common relations
 Issues to watch out for when merging entities from
different ER models:
 Synonyms–two or more attributes with different names
but same meaning
 Homonyms–attributes with same name but different
meanings
 Transitive dependencies–even if relations are in 3NF
prior to merging, they may not be after merging
 Supertype/subtype relationships–may be hidden prior to
merging

Chapter 4 Copyright © 2016 Pearson Education, Inc. 4-51

ENTERPRISE KEYS

 Primary keys that are unique in the

whole database, not just within a single
relation
 Corresponds with the concept of an
object ID in object-oriented systems

Chapter 4 Copyright © 2016 Pearson Education, Inc. 4-52

 Figure 4-31 Enterprise keys
a) Relations
with
enterprise
key

b) Sample
data with
enterprise
key

Chapter 4 Copyright © 2016 Pearson Education, Inc. 4-53

TO TELL A TD FROM A PD;
FD ALWAYS EXISTS
Watch the field where the arrow originates:
- If the arrow goes out from a NON-key field, this func
dep is TD;
o “From non-key to non-key”
- If the arrow goes out from PART of a composite key,
this func dep is PD (Partial);
o “From PART of a key to non-key”
o PD ONLY exists when/where there is a composite
key!
- There ALWAYS exists a Full Dependency
o “From key to non-key”
Chapter 4 Copyright © 2016 Pearson Education, Inc. 4-54