You are on page 1of 31

DATA BASE MANAGEMENT SYSTEMS

(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

You might also like