Normalization

Normalize the Data Model

Normalization is a relational database concept, but its principles
apply to Conceptual Data Modelling.
 First Normal Form (1NF)
 All Attributes must be single-valued
 Second Normal Form (2NF)
 An attribute must be dependent upon its
entity’s entire unique identifier
 Third Normal Form (3NF)
 All non key attributes are mutually
independent and are fully dependent on
primary key
A normalized entity-relationship data model automatically translates into a
normalized relational database design!
First Normal Form
Single-valued attributes
First Normal Form Rule: All attributes must be singled-valued.
Validate that each attribute has a single value
for each occurrence of the entity. No
attribute should have repeating values.
CLIENT
#* identifier
* date contacted
Does the entity CLIENT comply with 1NF?

The attribute date contacted has multiple values, therefore the

entity CLIENT is not in 1NF.
First Normal Form (cont)

 If an attribute has multiple values, create an

additional entity and relate it to the original
entity with a M:1 relationship.

CONTACT for CLIENT

#* date contacted
#* identifier
o location
o result the
subject
of
Second Normal Form
Dependency on entire UID
Second Normal Form Rule: An attribute must be dependent upon
its entity’s entire unique identifier.
 Validate that each attribute is dependent on
its entity’s entire unique identifier. Each
specific instance of the UID must determine
a single instance of each attribute.
 Validate that an attribute is not dependent
upon only part of its entity’s UID.

COURSE Validate placement of the COURSE entity’s

#* code attributes
* name
* duration
* fee In this example, each instance of a course code determines
a specific value for name, duration, and fee. The
attributes are properly placed.
Second Normal Form (cont)

 Validate the placement of the attributes for the

ACCOUNT and BANK entities

ACCOUNT managed BANK

#* number by
#* number
* balance
* name
* date opened
* bank location the
manager
of

Are there any attributes which can be determined from a portion of

its entity’s UID?
Second Normal Form (cont)

 Validate the placement of the attributes for the

ACCOUNT and BANK entities

ACCOUNT managed BANK

#* number by
#* number
* balance
* name
* date opened
the * bank location
manager
of

Each instance of a BANK and account number determine specific

values of balance and date opened for each account. The attribute
bank location is misplaced. It is dependent on BANK but not on
account number and so should be an attribute of BANK.
Third Normal Form
No non-UID interdependencies
Third Normal Form Rule: No non-UID attribute can be dependent
upon another non-UID attribute.
 Validate that each non-UID attribute is not
dependent upon another non-UID attribute
 Move any non-UID attribute that is
dependent upon another non-UID attribute
ORDER
#* id Are any of the non-UID attributes for this
* date of order entity dependent upon another non-UID
* customer id
* customer name
attribute?
* state
Third Normal Form (cont)

ORDER The attributes customer name and state are

#* id
* date of order dependent on the customer id. Create another
* customer id entity called CUSTOMER with a UID of customer
* customer name id and place the attributes accordingly.
* state

ORDER CUSTOMER
#* id for #* id
* date of order * name
the * state
submitter
of
Exercise N-1
For the following E-R Model, evaluate each entity against the rules
of normalization, identify the misplaced attribute, and explain
what rule of normalization each misplaced attribute violates.
Optionally, re-draw the E-R diagram in third normal form.

ENROLLMENT for COURSE

grade code #* course number
teacher number course name
grade description completed teacher number
course name with department code
department name
for teacher name

assigned

STUDENT
#* student id
last name
first name
Exercise N-1 Solution-1NF

 Any repeating values?

COURSE
ENROLLMENT for #* course number
grade code course name
teacher number teacher number
grade description department code
completed department name
course name with teacher name
for

assigned There is no violation of

First Normal form, so
STUDENT the entities stay the same.
#* student id
last name
first name
Exercise N-1 Solution-2NF
 Any partial UID dependencies?

ENROLLMENT for COURSE

grade code #* course number
teacher number course name
grade description completed teacher number
course name with department code
department name
for teacher name

assigned
Yes! Teacher Number
STUDENT and Course Name, in the
#* student id
ENROLLMENT entity,
last name do not depend on both
first name the Course Number and
Student Id.
Exercise N-1 Solution-3NF

• Any transitive UID dependencies?

ENROLLMENT for COURSE

grade code #* course number
grade description course name
completed teacher number
with department code
department name
for teacher name

assigned
Yes! Grade Description is dependent
STUDENT on Grade Code, Department Name is
#* student id dependent on Department Number,
last name and Teacher name is dependent on
first name Teacher Number.
 Exercise N-1
Solution-Normalized Model
ENROLLMENT COURSE taught by TEACHER
for # * course number # * number
course name name
the
completed with teacher
of
offered by

DEPARTMENT
the offerer of
the receiver
# * number
of name

GRADE
assigned to # * code
description The ENROLLMENT entity
for
assigned
has no attributes of its own.
It is still considered an
STUDENT entity, since it participates
# * student id in 2 or more relationships.
last name
first name