BTM 382 Database Management
Chapter 6:
Normalization of Database Tables
Chitu Okoli
Associate Professor in Business Technology Management
John Molson School of Business, Concordia University, Montral
Structure of BTM 382 Database
Week 1: Introduction and overview
Management
ch1: Introduction
Weeks 2-6: Database design
ch3: Relational model
ch4: ER modeling
ch6: Normalization
ERD modeling exercise
ch5: Advanced data modeling
Week 7: Midterm exam
Weeks 8-10: Database programming
ch7: Intro to SQL
ch8: Advanced SQL
SQL exercises
Weeks 11-13: Database management
ch2,12,14: Data models
ch13: Business intelligence and data warehousing
ch9,15,16: Selected managerial topics
Review of Chapter 6:
Normalization of Database Tables
What are dependencies between attributes in a table,
and how is tracing of dependencies used to
normalize tables?
What are the normal forms in a relational database?
Why and when would you consider denormalizing
tables in a relational database?
Problems with unnormalized tables
Needless redundancy, hence insert, update and
delete anomalies (inconsistencies)
Data updates are less efficient because tables are
larger
Indexing is less effective
Views (virtual tables) are more cumbersome
Understanding dependencies to be
able to properly normalize tables
Functional dependency
Functional dependency: AB or (A,B)(C,D)
B is functionally dependent on A means that if you know A, then there
you definitely know the correct value for B
E.g. Project.ID Project.Name
Also called determination: A determines B
Full functional dependency: (A,B)C where AC and BC
When all the attributes in a key are required for the determination (none is
optional)
E.g. (Project.ID, Project.Manager) Project.Name
Project.Manager is optionalthis is not a full functional dependency
E.g. (Project.Manager, Project.StartDate) Project.Name
This is a full functional dependency, assuming a manager can launch no
more than one project on a given date
Repeating group = multivalued
attribute
Attribute whose values contain multiple values (a list
or array of values), instead of a single value
Illegal in the relational model; troublesome for
normalization if you dont catch it
Two possible solutions
(e.g. Project.ID Project.Location):
1. Create multiple attributes for each possible value (e.g.
Project.Location1, Project.Location2, Project.Location3)
2. Create a new entity to store multiple possible values (e.g.
Location)
Multivalued dependency
Functional dependency: AB
Multivalued dependency: AB,C
A determines B and A determines C, but B and C have
nothing to do with each other
E.g. Project.ID Project.EmployeeID, Project.Location
Since a project might have multiple locations and multiple
employees work on a project, the EmployeeID and Location in
the same row might have nothing to do with each other
Usually indicates that one or more multivalued attributes
were not handled properly
Partial and transitive dependencies
Partial dependency: (A,B)(C,D) and BC
(A,B) is a candidate key (e.g. primary key)
C doesnt need both A and B to determine it; it only needs B
E.g. (Project.ID,Project.ManagerID) Project.Name
and Project.ID Project.Name
Transitive dependency: A(B,C) and BC
A is a candidate key
Technically speaking, a transitive dependency requires that B and C not be part of
any candidate key. However, if you expand the meaning to include even if they
are part of the key, then you will automatically avoid problems with BCNF
A determines C, but so does B, even though B is not a candidate
key
E.g. Project.ID (Project.Client,Project.Location)
and Project.Client Project.Location
The normal forms
Normalization of relations: https://youtu.be/NwcVv1cxflk
(note and 0:34 and 1:50)
Summary of attaining normal forms
1NF: Primary key identified and no multivalued attributes
Legitimate primary key selected (unique identifying key)
Only one value per table cell; no lists/arrays (multivalued attributes) in any table cell
If you split multivalued attributes off to separate tables, then you avoid 4NF violations
2NF: 1NF minus partial dependencies
All candidate key dependencies are fully functional
(A,B)C where AC and BC
3NF/BCNF: 2NF minus transitive dependencies
Only a candidate key determines any attribute
If A(B,C), then B C
There is a technical distinction between 3NF and BCNF, but if you keep this rule, then you
take care of both 3NF and BCNF
4NF: BCNF minus multivalued dependencies
Each row strictly describes just one entity
If you split multivalued attributes into separate tables to attain 1NF, then you also avoid
4NF violations
DKNF, 5NF, 6NF
relatively rare and often not worth the trouble normalizing, even if applicable
Dependency diagram:
Basic tool for normalization
Depicts all dependencies found in a given table structure
Gives birds-eye view of all relationships among tables
attributes
Makes it less likely that you will overlook an important
dependency
3NF vs BCNF
BCNF is only an issue
because of poor selection
of primary key for 1NF step
Regardless, dealing with all
dependencies resolves
table into BCNF
Fixing 4NF problem
The only reason a table
might be in 3NF/BCNF
but not in 4NF is
because two originally
multivalued attributes
existed at 1NF stage
Multivalued attributes
should always be placed
in separate tables, or be
split into multiple
attributes
If you do this in the first
step to resolve 1NF, you
will never have
problems with 4NF
Denormalization
Denormalization
Although normalization is important, processing speed
and efficiency are also important in database design
Summary of Chapter 6:
Normalization of Database Tables
Correctly identifying dependencies from the very
beginning is critical to properly normalize tables.
The most important normal forms are 1NF, 2NF, 3NF,
BCNF and 4NF.
Although normalization to 4NF is usually important, a
designer might sometimes want to denormalize a
table to a lower normal form.
Sources
Most of the slides are adapted from
Database Systems: Design, Implementation and
Management
by Carlos Coronel and Steven Morris. 11th edition
(2015) published by Cengage Learning. ISBN 13:
978-1-285-19614-5
Other sources are noted on the slides themselves
