The Relational Model and
Normalization
The Relational Model
Page 113
Broad, flexible model
Basis for almost all DBMS products
E.F. Codd defined well-structured
normal forms of relations,
normalization
Relational Data Model
A relational data model organizes data as a
set of relations, or two-dimensional tables.
A relation is viewed as a two-dimensional
table, with following properties:
Each column contains values about the same
attribute, and each table cell must be simple
Each column has a distinct name (attribute
name), and the order of columns is immaterial
Each row is distinct, duplicate rows are not
allowed
The sequence of the rows is immaterial
An Example Relation
Key
Candidate
Key
Foreign
Key
Non-key
Attribute
Non- key
Attribute
Employee Employee
Number
Name
28719
Smith Tom
Department
Number
172
Salary
18,000
Date
Started
12/03/84
53730
Jones Bill
044
20,000
01/05/83
79313
Ropley Ed
044
11,000
18/09/81
51616
Fair Carolyn
090
50,000
05/12/79
61930
Hall Albert
090
25,000
21/06/82
Terminology in a
Relation
Tuple - a row or record
Column - values of an attribute
Domain - a set of possible values for
an attribute
Terminology in a Relation
Key
primary key (unique ID)
Concatenated key - use two or more
attributes to identify a record (e.g.. Student
ID & Course ID to identify a Grade record)
Foreign key (cross reference key)
a foreign key is a non-key attribute in one
relation that also appears as a primary key
in another relation
An E-R Model for
Student Registration
System
Attributes
Course
Number
Instructor ID
Description
Name
Room
Course
1
Teaches
Rank
Instructor
1
Advises
M
Course Enrollment
Course
Number
Grade
M
M
Student
Number
Student
Student
Number
Major
Student
Name
Covert E-R Model to
Relational Tables
Create one table for each entity
with key and attributes
Introduce foreign key into the
many side to represent 1:m
relation
A Relational Model For
Student Registration
System
Course Table
Course ID
Description
Credit
Instructor ID
Instructor Table
Instructor ID
Instructor Name
Rank
Student Table
Student ID
Student Name
Major
Enrollment Table
Course ID
Student ID
Grade
Advisor ID
Relational Database
Advantages
Easy to understand and use
Powerful data manipulation capability
Implicit association to meet different needs. Flexible,
best for DSS
Normalization theory for database design
Disadvantages
Redundantly store keys as logical pointers for
implementing relationship
Inefficiency for high-volume transaction processing
Lack of semantic quality control
Equivalent Relational
Terms
Page 114
Figure 5-1
2000 Prentice Hall
Normalization
Reduce complex user views to a
set of small, stable data structures
Eliminate errors and
inconsistencies related to the
adding, deleting or updating of
record occurrences
Modification Anomalies
Insertion anomalies - cannot add a
record because of a missing value for
one or more fields
Deletion anomalies - the deletion of a
record causes an unintended deletion of
information
Update anomalies - updating as made
needlessly complicated due to
redundancy
Functional Dependence
Given a relation R, attribute Y of R
is functionally dependent on
attribute X of R if and only if,
whenever two tuples of R agree on
their X- value, they must
necessarily agree on their Y-value.
We write R.X --> R.Y
Example:
(Student ID, Student Name, Course ID, Course Title, Grade)
Student ID --> Student Name,
Course ID --> Course Title
Student ID -?-> Course ID
Course Title -?-> Student Name
Student ID -?-> Grade
Course ID -?-> Grade
Normal Forms
A relation is said to be in a
particular normal form if it satisfies
a certain specified set of
constraints
Normal Forms
1 NF (no repeating groups)
2 NF (no partial dependencies)
3 NF (no transitive dependencies)
Boyce-Codd NF
4 NF (no multi-value dependencies)
5 NF
Domain-Key NF
First Normal Form
A relation is in first normal form if it
contains no repeating groups
First Normal Form
An un-normalized relation contains
repeating groups
First Normal Form
Grade Report with repeating group of courses for
each student
(Student ID, Student Name, Campus Address,
Major, Course ID, Course Title, Instructor Name,
Instructor Location, Grade)
Remove repeating group
(Student ID, Student Name, Campus Address,
Major) (3NF)
(Student ID, Course ID, Course Title, Instructor
Name, Instructor Location, Grade) (1NF)
First Normal Form
Second Normal Form
A relation is in second normal
form if it is already in first
normal form and any partial
functional dependencies on the
primary key have been
removed
Second Normal Form
A
partial functional dependencies on the primary key
A
Second Normal Form
(Student ID, Course ID, Course Title, Instructor
Name, Instructor Location, Grade) (1NF)
Primary key is Student ID + Course ID
Student ID + Course ID --> Grade
Course ID --> Course Title (partial dependency)
Removing partial dependencies
(Student ID, Course ID, Grade) (3NF)
(Course ID, Course Title, Instructor Name,
Instructor Location ) (2NF)
Second Normal Form
Third Normal Form
A relation is in third normal form
if it is already in second normal
form and contains no transitive
dependencies
transitive dependency - One
nonkey attribute is dependent on
one or more nonkey attributes
Third Normal Form
A
transitive dependencies
A
Third Normal Form
(Course ID, Course Title, Instructor Name,
Instructor Location ) (2NF)
Course ID --> Instructor Name --> Instructor
Location
Instructor Name is nonkey
Instructor Location is dependent on Instructor
Name
Remove transitive dependency
(Course ID, Course Title, Instructor Name) (3NF)
(Instructor Name, Instructor Location ) (3NF)
Third Normal Form
Third Normal Form
if it is in second normal form and
has no transitive dependencies
Figure 5-7
2000 Prentice Hall
Practice: Mountain View
Community Hospital
Mountain View Community Hospital
Physician Report
Physician: A Campbell
Specialty: Internal Medicine
Date
Patient-Code
Patient-Name
Procedure
Charge
---------------------------------------------------------------------------------------------10/17/96 32968
Baker, Marry S. Examination
35.00
X-ray
75.00
10/17/96 39271
Emery, Nancy
Examination
35.00
Chemotherapy 50.00
10/18/96 32968
Baker, Marry S. Examination
35.00
----------------------------------------------------------------------------------------------
Normalize a table
Report (Doctor Name, Specialty, Date, Patient Code,
Patient Name, Procedure Name, Charge)
Analyzing functional dependency:
Assume no duplicate Doctor Name. Otherwise
introduce a doctor ID
Assume no duplicate Procedure Name. Otherwise
introduce a Procedure code
Assume charge is determined by procedure.
Assume a patient may visit a doctor more than
once during the same day.
Answer
Doctors (Doctor ID, Doctor Name, Specialty)
Patients (Patient Code, Patient Name)
Visit (Visit ID Doctor ID, Patient Code, Date)
Treatment (Visit ID, Procedure ID)
Procedure (Procedure ID, Procedure Name,
Charge)
Here the Visit ID is automatically generated by
the system
A E-R Model for
Hospital Treatment Charge
Procedure
ID
Doctor ID
Description
Name
Rate
Specialty
Procedure
Doctor ID
M
Treatment
Visit ID
Procedure
ID
Visit ID
Date/Time
Doctors
M
Patients
Visit
Patient
Code
1
Patient
Code
Patient
Name
E-R model improvement
criteria vs. Normalization
Each entity must have a key (simple or
Theory
composite) (basic requirement of a
relational table)
Introduce composite entity to convert a m:n
relation into two 1:m relations. Introduce a
composite key (the way of presenting m:n
relationships in relational database)
Convert a multivalued attribute into an
attribute entity or weak entity (1 NF)
E-R model improvement
criteria vs. Normalization
Make
theory
each entity represent a simple
object or concept (2 NF and 3NF)
Divide complex entity into several
related simple entities (2 NF and 3 NF)
Make each attribute associate with only
one entity unless it is a foreign key (3
NF)
A good E-R model usually satisfies 3 NF.
Boyce-Codd Normal
Form
if every determinant is a candidate key
Figure 5-8
2000 Prentice Hall
Boyce-Codd Normal Form
(Student, Major, Advisor) (3NF)
or (Student, Advisor, Major) (1NF)
Student may have more than one major
with one advisor in each major
Student + Major Advisor
Student + Advisor Major
Advisor Major (Advisor determines major but Advisor
is not candidate key)
(Student, Advisor) (BCNF)
(Advisor, Major) (BCNF)
Boyce-Codd Normal Form
A relation is in BCNF if and only if it is in 3NF
and every determinant is a candidate key
A determinant is any attribute (simple or
composite) on which some other attribute is
fully functionally dependent
Situation:
1. Multiple candidate keys
2. Those candidate keys are composite
3. The candidate keys are overlapped
Fourth Normal Form
A relation is in fourth normal form if it is in
BCNF and contains no multivalued
dependencies
Multivalued Dependency
There are three attributes (e.g. A,B,C) in a
relation.
For each value of A there is a well-defined set
of value of B and a well-defined set of value of
C.
The set of value of B is independent of the set
of value of C, and vice versa.
Fourth Normal Form
(Course, Instructor, Textbook)
(BCNF)
One course is taught by several
instructors
One course uses the same set of
textbooks by each instructor
(Course, Textbook) (4NF)
(Course, Instructor) (4NF)
Fourth Normal Form
Course
Instructor
Textbook
1ka3
David
Intro. Web
design
1ka3
Smith
Intro. Web
design
1ka3
David
Intro. Access
1ka3
Smith
Intro. Access
Course
Instructor
Course
Textbook
1ka3
David
1ka3
Intro. Web design
1ka3
Smith
1ka3
Intro. Access
Fifth Normal Form
?
Page 125
Fifth Normal Form
Every join dependency is a
consequence of its relation keys
A non 5NF: Person-using-skills-onjobs (Person, Skill, Job)
5 NF: Has-skill (Person, Skill)
Need-skill (Skill, Job)
Assigned-to-job (Person, Job)
Domain Key Normal
Form
if every constraint on the relation
is a logical consequence of the
definition of keys and domains
Constraint a rule governing
static values of attributes
Key unique identifier of a
tuple
Domain
Page 125
description of an
attributes allowed values
Example of non DK/NF
Enrollment (Student ID, Course ID, Grade)
Key constraint: Student ID + Course ID --> Grade
Domain constraint:
Student ID: 7 digits, Course ID: 3 digits, Grade:
A,B,C,D,F,P
General constraint
If Course ID < 900 then Grade in {A,B,C,D,F}
else Grade in {P,F}
Since the general constraint cannot be inferred from
key constraint or domain constraint, it is not a
DK/NF.
Remarks on Normalization
The notions of dependency and
normalization are semantic in
nature
The normalization guidelines
should be regarded primarily as a
discipline to help the database
design
Limitations of
normalization
may not natural, e.g. zip code, area code for
phone #
May ignore operational considerations: need not
change, may change over time. e.g. (order# ,
prod# ,description, unit-price, quantity)
Difficult to enforce integrity control
(Order#, Prod#, quantity)
(Prod#, Description, Unit-price)
Prod# may not be valid.
Now the integrity control is provided by relational
DBMS
Denormalization
Normalization is only one of many database
design goals.
Normalized (decomposed) tables require
additional processing, reducing system
speed.
Normalization purity is often difficult to
sustain in the modern database
environment. The conflict between design
efficiency, information requirements, and
processing speed are often resolved through
compromises that include denormalization.
