Professional Documents
Culture Documents
(DBM
NORMALIZATION
Content of this Session
What normalization is and what role it plays in the database
design process
About the normal forms 1NF, 2NF, 3NF
How normal forms can be transformed from lower normal
forms to higher normal forms
That normalization and ER modeling are used concurrently to
produce a good database design
That some situations require de-normalization to generate
information efficiently
Database Tables and Normalization
Normalization
Process for evaluating and correcting table structures to minimize
data redundancies
Reduces data anomalies
Works through a series of stages called normal forms:
First normal form (1NF)
Second normal form (2NF)
Third normal form (3NF)
2NF is better than 1NF; 3NF is better than 2NF
For most business database design purposes, 3NF is as high as we
need to go in normalization process
Highest level of normalization is not always most desirable
The Need for Normalization
Example: Company that manages building projects
Charges its clients by billing hours spent on each contract
Hourly billing rate is dependent on employees position
Periodically, report is generated that contains information
displayed in Table 5.1
The Need for Normalization (continued)
The Need for Normalization (continued)
Structure of data set in Figure 5.1 does not handle data very well
The table structure appears to work; report generated with ease
Unfortunately, report may yield different results depending on
what data anomaly has occurred
Anomalies
1. insert a new course s15, without any student enrolment
2. update course S11's description
3. delete sid 1
sid sname scourse course desc course_grade
1 abc S11,s12, s13 IMP A,B,C
2 pqr s13 VIP B
3 xyz s3 TIP A
The Normalization Process
Each table represents a single subject
No data item will be unnecessarily stored in more than one
table
All attributes in a table are dependent on the primary key
NF Definitions
1NF: A table is in 1NF if: it has a primary key and it has no
multi-valued attributes.
2NF: A table is in 2NF if: it is in 1NF and it has no partial
dependencies.
3NF: A table is in 3NF if: it is in 2NF and it has no transitive
dependencies. (When a non-key attribute depends on
another non-key attribute, it is called a transitive
dependency.)
STUDENT (Student-ID, Student-Name, Student-Phone)
Key attribute Non-key attributes
Examples of Tables Not in 1NF
STUDENT(Student-ID, Student-Name, Class-Code, Grade)
QUESTION: What normal form is the above table in
ANSWER: It is not normalized at all (or it is in 0NF)
because: It has multi-valued attributes:
Given one student ID,
Class-Code and Grade are multi-valued
sid sname scourse
course
desc
course_gra
de
1 abc
S11,s12,
s13 IMP A,B,C
2 pqr s13 VIP B
1 NF
sid sname scourse course desc course_grade
1 abc s11 IMP A
1 abc s12 IMP A
1 abc s16 IMP B
2 pqr s13 VIP B
3 xyz s3 TIP A
Examples of Tables Not in 2NF
ENROLLMENT(Student-ID, Class-Code, Class-Title, Grade)
QUESTION: What normal form is the above table in?
ANSWER: It is in 1NF
because: (1) It has no multi-valued attributes.
(2) However, it has partial dependency,
i.e., Class-Title depends on Class-Code only,
which is part of the key.
Functional Dependency
Functional Dependencies
Determinant
attribute
sid course Sid, course
Dependent
attribute
sname Course_desc grade
Examples of Tables Not in 3NF
CLASS (Class-Code, Class-Title, Instructor-ID, Instructor-Name)
QUESTION: What normal form is the above table in?
ANSWER: It is in 2NF
because: (1) It has no multi-valued attributes.
(2) It has no partial dependencies.
(3) However, it has a transitive dependency since
Instructor-Name depends on Instructor-ID.
2 NF
sid courseid Grade
1 s11 A
1 s12 A
1 s16 B
2 s13 B
3 s3 A
sid sname
1 Abc
2 Pqr
3 Xyz
course id course desc
s17 IMP
s11 VIP
s13 TIP
Transitive Dependency
sid recreation course course fee
1 tt 200
2 bb 300
3 swim 150
4 swim 150
Examples of Table in 3NF
ENROLLMENT (Class-Code, Student-ID, Grade)
QUESTION: What normal form is the above table in?
ANSWER: It is in 3NF
because: (1) It has no multi-valued attributes.
(2) It has no partial dependencies.
(3) It has no transitive dependencies.
A Simplified Process of Converting Tables to 3NF
1. Identify all functional dependencies, i.e., identify
determinants and their dependent fields.
2. Create tables such that every determinant
becomes the PK of the table and the dependent
fields become other columns of the same table.
2NF
sid recreation course course fee
sid recreation
3NF
recreation fee
A Simplified Process of Converting Tables to 3NF
EXAMPLE: PROJECT(Project#, Project-Name, Employee-ID,
Employee-Name, Employee-Project-Hours)
Step 1 - Identify Functional Dependencies:
Project# Project_Name
Employee-ID Employee-Name
Employee-ID, Project# Employee-Project-Hours
A Simplified Process of Converting Tables to 3NF
EXAMPLE: PROJECT(Project#, Project-Name, Employee-ID,
Employee-Name, Employee-Project-Hours)
Step 2 - Define Tables:
PROJECT (Project#, Project_Name)
EMPLOYEE (Employee-ID, Employee-Name)
PROJECT_ASSIGNMENT(Employee-ID, Project#, Employee-
Project-Hours)
BoyceCodd Normal Form
Eliminates all redundancy that can be discovered by
functional dependencies
But, we can create a normal form more restrictive
called 4NF
BoyceCodd Normal Form
A relation schema R is in BCNF with respect to a set F of
functional dependencies if, for all functional dependencies in
F+ of the form , where R and R, at least one of
the following holds:
is a trivial functional dependency (that is, ).
is a super key for schema R.
A database design is in BCNF if each member of the set of
relational schemas that constitute the design is in BCNF
Example
Customer-schema = (customer-name, customer-street,
customer-city)
customer-name customer-street customer-city
Branch-schema = (branch-name, assets, branch-city)
branch-name assets branch-city
Loan-info-schema = (branch-name, customer-name, loan-
number, amount)
loan-number amount branch-name
(customer-name: candidate key)
Loan-info-schema (not in BCNF)
Loan-info-schema= (Branch name, customer-name, loan-
number, amount)
(Downtown, John Bell, L-44, 1000)
(Downtown, Jane Bell, L-44, 1000)
Loan number is not a candidate key
However the functional dependency loan-number amount
is nontrivial.
Hence Loan-info-schema does not satisfy the definition of
BCNF.
BCNF Decomposition
The definition of BCNF can be used to directly test if a
relationship is in BCNF
If a relation is not in BCNF it can be decomposed to create
relations that are in BCNF
Example
borrower = (customer_id, load_number)
Is BCNF because no nontrivial functional dependency hold onto
it
loan = (loan_number, amount)
Has one nontrivial functional dependency that holds,
loan_numberamount, but loan_number is a superkey so
loan is in BCNF
3NF vs BCNF
BCNF requires that all nontrivial dependencies be of the form
, where is a super key
3NF relaxes this constraint a little bit by allowing nontrivial
functional dependencies
End of Session