The document discusses database normalization. It begins by defining normalization and describing its purpose in eliminating data redundancy and anomalies. The document then covers various normal forms including 1st normal form (1NF), 2nd normal form (2NF), 3rd normal form (3NF) and Boyce-Codd normal form (BCNF). It also defines key concepts like functional dependencies, full dependencies, partial dependencies and transitive dependencies. Examples are provided to illustrate the normalization process and how relations can be decomposed to remove anomalies through normalization.

1. FP304 DATABASE SYSTEM
DFC 2083
Database
Design
CHAPTER 3 : PART 3
ERD & NORMALIZATION
LECTURER : LIYANA BINTI MAT RANI

2. COURSE LEARNING
OUTCOME
CLO1 : Apply the fundamental concepts and
structure of database management and
relational data model in database
development process
CLO2 : Implement the relational database
design and modelling using entity
relationship (ER) model and normalization
concepts to derive a physical design for a
database.
CLO3 : Solve an organization’s requirements
by using the database query to manipulate a
database with an appropriate commercial
FP 304 – Database System

3. LEARNING OUTCOME
Define normalization.
Describe purpose of normalization in database
model.
Explain the importance of normalization in
database models
Define functional dependencies (FD).
Define transitive dependencies.
Describe the various types of normal forms:
a. First normal form (1 NF)
b. Second normal form (2 NF)
c. Third normal form (3 NF)
Identify the step in normalization process
Define Boyce-Codd Normal Form (BCNF).

4. INTRODUCTION
Usually in the software industry, ER Modelling is used by
designer as a requirement analysis tools. (which is to
analyse how many table, what is the data need, what is
the relationship among the data / table)
Database designed based on the ER model may contain
some amount of inconsistency, ambiguity(uncertainty)
and redundancy. To resolve these issues some amount of
requirement is required.
The refinement process of database design is referred as
Normalization.
A normalization involve building structure (like tables),
starting from the stage of identifying the
columns(attributes) associated in the table, it is also
called as Bottom-up approach.

5. INTRODUCTION (CONT)
Normalization is the process of decomposing
relations with anomalies to produce smaller AND
well structured relation.
It is a process for assigning attributes to entities to
determine whether the chosen entities, attributes
and primary keys are appropriate and suitable for
the system.
Normalization process can be divided into a few
levels called Normal Forms (NF). The NF that will be
covered in this subject are:
 1NF
 2NF
 3NF
 Boyce-Codd Normal Form (BCNF)

6. INTRODUCTION (CONT)
Basically normalization eliminate the duplicate
data and makes insert, update and delete
operations much more efficient in terms of
performance and space requirement to store
the data.
Almost all the database design are initially
based on ER modelling and later refined using
normalization technique before they are
physically created.

7. WHAT IS NORMALIZATION?
It is a systematic approach of decomposing tables to
eliminate data redundancy and undesirable
characteristics like Insertion, Update and Deletion
Anomalies.
It is a multi-step process that puts data into tabular
form by removing duplicated data from the relation
tables.
By doing NORMALIZATION:
 Redundancies can be reduced
 Anomalies can be eliminated
 Ensuring data dependencies make sense i.e data is
logically stored.

8. IMPORTANCE OF
NORMALIZATION
a. Improve system performance and
accuracy.
b. Support integrity and consistency of the
data
c. Save space, minimize redundancy and
eliminate anomalies.
d. The goal of normalization is to create a
set of relational tables that are free of
redundant data and that can be
consistently and correctly modified.

9. WHAT IS ANOMALIES?
Problems or difficulties that occur
when information is inserted, deleted
or updated.
Three types of update anomalies:
a. Insertion Anomalies
b. Deletion Anomalies
c. Modification Anomalies

10. PROBLEM WITHOUT
NORMALIZATION
Without Normalization, it becomes difficult to handle and update the
database without facing data loss. Insertion, Modification and Deletion
Anomalies are very frequent if Database is not Normalized.
Insertion Anomaly : Suppose for a new admission, we have a Student id (Stud_id),
name and address of a student but if student has not opted for any subjects yet
then we have to insert NULL there, leading to Insertion Anomaly.
Deletion Anomaly : If (Stud_id) 403 has only one subject and temporarily he
drops it, when we delete that row, entire student record will be deleted along
with it.
Modification Anomaly : To update address of a student who occurs twice or more
than twice in a table (see Adam’s record), we will have to
update Stud_Address column in all the rows, else data will become inconsistent.
Stud_id Stud_Name Stud_Address Subject_opted
401 Adam Bayan Lepas Database System
402 Aliah Balik Pulau Advance Java
403 Shaiful Teluk Kumbar Computing Maths
401 Adam Bayan Lepas Data Structure

11. DETERMINANT
A determinant in a database table is an attribute that can be
used to uniquely determine the values assigned to other
attribute in a row.
In this example EMP_ID is the determinant to other attributes in
the table .
Why ?
a. EMP_ID can be used to uniquely identify/determine the
attribute FNAME, LNAME and DOB.
b. FNAME & LNAME cannot determine the EMP_ID because the
firm may have employees that share the same first and/or
last name.
c. Similarly, the DOB field cannot determine the EMP_ID,
FNAME,LNAME because employees may share the same
EMP_ID FNAME LNAME DOB
123 Megan Brown 22/3/1996
124 John Tucker 22/3/1996
301 Lisa Mendala 22/4/1996
444 Faridah Kamil 22/6/1996

12. DETERMINANT (CONT)
Formal Definition : Attribute X can be define as
determinant if it uniquely determine the
attribute value Y in a given relationship or
entity.
The determinant not need to be a KEY
ATTRIBUTES (but most of them are key
attributes)
Usually dependency of the attribute is
represented as :
 X → Y (which means attribute X determine
attribute Y)

13. DETERMINANTS (CONT)
For example :
a. EMPID → FNAME, LNAME,DOB
b. ICNo → Name, Address, Birthdate
c. ISBN → Title, Author_Name
d. Mark → Grade

14. FUNCTIONAL DEPENDENCY
(FD)
Constraint between two attributes or two sets of
attributes.
For any relation R, attribute B is functionally
dependent on attribute A if, for every valid instance
of A, that value of A uniquely determines the value
of B.
The functional dependency of B on A is represented
by an arrow, as follows: A→ B.
An attribute may be functionally dependent on two
(or more) attributes rather than on a single
attribute.
Three type of Functional Dependency
a. Full Functional Dependency
b. Partial Functional Dependency
c. Transitive Functional Dependency

15. FUNCTIONAL DEPENDENCIES
(CONT)
Determinant
 the attribute or group of attributes on the left-
hand side of the arrow of a functional
dependency.

16. FULL FUNCTIONAL
DEPENDENCY
Indicates that if A and B are attributes of a
relation, B is fully functionally dependent on A,
but not on any proper subset of A.
Determinant
 the attribute or group of attributes on the left-hand
side of the arrow of a functional dependency.

17. FULL FUNCTIONAL
DEPENDENCY
staffNo sName position salary branchNo bAddress
100 Ahmad Manager 30000 B005 Penang
200 Sally Assistant 12000 B003 Kelantan
300 Zaidi Supervisor 18000 B003 Kelantan
400 Kumar Assistant 9000 B007 Seremban
500 Desmond Manager 24000 B003 Kelantan
600 Mei Lin Assistant 9000 B005 Penang
FD : staffNo  sName, position, salary,
brachNo, bAdress
Table : StaffBranch
The relation is not in full dependency because bAddress is
fuctionally dependent on branchNo
staffNo  sName, position, salary, brachNo
brachNo  bAddress

18. FULL FUNCTIONAL
DEPENDENCY
staffNo sName position salary branchNo
100 Ahmad Manager 30000 B005
200 Sally Assistant 12000 B003
300 Zaidi Supervisor 18000 B003
400 Kumar Assistant 9000 B007
500 Desmond Manager 24000 B003
600 Mei Lin Assistant 9000 B005
branchNo bAddress
B005 Penang
B003 Kelantan
B007 Seremban
Figure 1 :
Staff and Branch relations

19. PARTIAL DEPENDENCY
Occurs when an attribute is functionally
dependent on only a part of a multi-attribute
key (a key that is made up of more than one
field).
A table with only a single-attribute primary
key cannot exhibit partial dependency

20. PARTIAL DEPENDENCY
StudID StudNa
me
CourseID CourseTitle Mark Grade
10 Ali F3038 Database
System
60 B
20 Abu B2009 Discrete Math 87 A
20 Abu F3038 Database
System
87 A
40 Alia B2009 Discrete Math 62 B
FD : Stud_ID, Course_ID  StudName, Course_Title,
Marks, Grade
• Check one by one the non-determinant attributes.
(attribute on the right side)
• If there is/are attribute(s) on the right can be
determine by only one of the determinant, then the
partial dependency exist in the relation.
Remove Partial Dependency
StudID, CourseID Marks, Grade
StudID  StudName
CourseID Course_Title
Student-
Course

21. PARTIAL DEPENDENCY
StudID StudName
10 Ali
20 Abu
40 Alia
Student
Student_Cour
se
CourseID CourseTitle
F3038 Database
System
B2009 Discrete Math
StudID CourseID Mark Grade
10 F3038 60 B
20 B2009 87 A
20 F3038 87 A
40 B2009 62 B
Recall :
Normalization is a
systematic approach
of decomposing tables
to eliminate data
redundancy and
undesirable
characteristics like
Insertion, Update and
Deletion Anomalies.
Course

22. TRANSITIVE DEPENDENCY
(CONT)
Occurs when an attribute is functionally dependent on another
non-key attribute.
Happen when non-key attributed determine another non-key
attributes (hint : focus on the right side)
For example, if A → B and B → C, then A → C. That is, if B
depends on A, and C depends on B, then C depends on A. This
is called transitive dependency.
StudID, CourseID (A) Marks(B), Grade (C)
1. StudID, CourseID (A) Marks(B)
2. Marks(B)  Grade (C)
(Marks can be used to determine the grade right? So marks is
the non-key attribute that determine another non-key
attributes)
3. StudID, CourseID (A) Grade (C)
Therefore we need to remove the transitive dependency…
StudID, CourseID  Marks
Marks  Grade

23. TRANSITIVE DEPENDENCY
(CONT)
** From previous relation, these two relation
generated after removing the partial dependency has
transitive dependency.
StudID  StudName
CourseID  CourseTitle
It is because, to be in transitive dependency, there
must be at least :
a. 3 attributes.
b. The right side must have no less than 2 attributes.
Full dependency

24. TRANSITIVE DEPENDENCY
(CONT)
The final relation should be in below.
StudID, CourseID  Marks
Marks  Grade
StudID  StudName
CourseID Course_Title

25. TRANSITIVE DEPENDENCY
(C0NT)
StudID StudName
10 Ali
20 Abu
40 Alia
Student
Student_Cour
se
CourseID CourseTitle
F3038 Database
System
B2009 Discrete Math
StudID CourseID Mark
10 F3038 60
20 B2009 87
20 F3038 87
40 B2009 62
Course
Mark Grade
60 B
87 A
62 B
Grade

26. NORMALIZATION
Table with multivalued
attributes
First Normal
Form
Second Normal Form
Third Normal Form
Identify FFD
Remove repeating groups /
multivalued attributes
Remove partial
dependencies
Remove transitive
dependencies

28. UNNORMALIZED FORM (UNF)
A table that contains one or more repeating groups.
Nama ID Jab No
Tel
Kelas Tarikh
Pinja
m
Tujuan
Pinja
m
Peralatan Jum Cata
tan
Tarikh
Pohon
Nama
Pengesah
Tarikh
Sah
Afiq 2015
F201
6
JTMK 012-
345
678
9
DIP
6A
21/1/
16
Berlati
h
R01 - Raket
Badminton
R02 - Bulu
Tangkis
2
5
- 18/1/16 Tay 19/1/16
Aiman 2013
F201
7
JTMK 012-
987
456
32
DIP4A 22/1/
16
Riada
h
K01 - Kayak 2 - 22/1/16 Tay 19/1/16
UNF : PohonAlatSukan (Nama, ID, Jab, NoTel, Kelas, TarikhPinjam,
TujuanPinjam, Peralatan, Jum, Catatan, TarikhPohon, NamaPengesah,
TarikhSah)
Table: PohonAlatSukan

29. FIRST NORMAL FORM
Def : A relation in which the intersection of each row and column
contains one and only one value.
Nama ID Jab No
Tel
Kelas Tarikh
Pinjam
Tujua
n
Pinja
m
Kod
Alat
Peralatan Jum Cat
a
tan
Tarik
h
Poho
n
Nama
Penges
ah
Tarikh
Sah
Afiq 2015
F
2016
JTM
K
012-
345678
9
DIP
6A
21/1/16 Berla
tih
R01 Raket
Badminton
2 - 18/1
/16
Tay 19/1/16
Afiq 2015
F
2016
JTM
K
012-
345678
9
DIP
6A
21/1/16 Berla
tih
R02 Bulu Tangkis 5 - 18/1
/16
Tay 19/1/16
Aiman 2013
F
2017
JTM
K
012-
987456
3
DIP4
A
22/1/16 Riada
h
K01 Kayak 2 - 22/1
/201
6
Tay 19/1/16
UNF : PohonAlatSukan (Nama, ID, Jab, NoTel, Kelas, TarikhPinjam,
TujuanPinjam, KodAlat, Peralatan, Jum, Catatan, TarikhPohon,
NamaPengesah, TarikhSah)
Table: PohonAlatSukan

30. FIRST NORMAL FORM (1NF)
UNF to 1NF – Find the determinat.
1NF
FFD
ID, TarikhPinjam Nama, Jab, NoTel, Kelas,
TujuanPinjam, KodAlat, Peralatan, Jum, Catatan,
TarikhPohon, NamaPengesah, TarikhSah
1NF : PohonAlatSukan (Nama, ID, Jab, NoTel, Kelas,
TarikhPinjam, TujuanPinjam, KodAlat, Peralatan, Jum,
Catatan, TarikhPohon, NamaPengesah, TarikhSah)
However,
a. First normal form still contains redundant data.
b. Redundancy causes problem called update anomalies.

31. SECOND NORMAL FORM
(2NF)
Def : A relation is in first normal form (1NF)
and every non-candidate key attribute is fully
functionally dependent on any candidate key.
A table that is in first normal form and every
non-primary key attribute is fully dependent
on the primary key.
Involve in removing partial dependencies.

32. 1NF TO 2NF (REMOVE PARTIAL
DEPENDENCY)
1NF
FFD
ID, TarikhPinjam Nama, Jab, NoTel, Kelas, TujuanPinjam, KodAlat,
Peralatan, Jum, Catatan, TarikhPohon, NamaPengesah, TarikhSah
PohonAlatSukan (Nama, ID, Jab, NoTel, Kelas, TarikhPinjam, TujuanPinjam,
KodAlat, Peralatan, Jum, Catatan, TarikhPohon, NamaPengesah, TarikhSah)
2NF
FFD
ID, TarikhPinjam TujuanPinjam, KodAlat, Peralatan, Jum, Catatan,
TarikhPohon, NamaPengesah, TarikhSah
PohonAlatSukan (ID, TarikhPinjam, TujuanPinjam, KodAlat, Peralatan, Jum,
Catatan, TarikhPohon, NamaPengesah, TarikhSah)
PD
ID  Nama, Jab, NoTel, Kelas
Peminjam (ID, Nama, Jab, NoTel, Kelas)

33. ID Tarikh
Pinjam
Tujuan
Pinjam
Kod
Alat
Peralatan Jum Cata
tan
Tarikh
Pohon
Nama
Penges
ah
Tarikh
Sah
2015F
2016
21/1/16 Berlatih R01 Raket
Badminton
2 - 18/1/16 Tay 19/1/16
2015F
2016
21/1/16 Berlatih R02 Bulu Tangkis 5 - 18/1/16 Tay 19/1/16
2013F
2017
22/1/16 Riadah K01 Kayak 2 - 22/1/16 Tay 19/1/16
SECOND NORMAL FORM
(2NF)
Table: PohonAlatSukan
Nama ID Jab No
Tel
Kelas
Afiq 2015F2016 JTMK 012-3456789 DIP6A
Aiman 2013F2017 JTMK 012-9874563 DIP4A
Table: Peminjam

34. THIRD NORMAL FORM (3NF)
Def : A relation is in the first and second
normal form and in which no non-candidate-
key attribute is transitively dependent on any
candidate key.
All columns in a relational table are dependent
only upon the primary key.
Involve in removing transitive dependencies.

35. 2NF TO 3NF
2NF
FFD
ID, TarikhPinjam TujuanPinjam, KodAlat, Peralatan, Jum, Catatan,
TarikhPohon, NamaPengesah, TarikhSah
PohonAlatSukan (ID, TarikhPinjam, TujuanPinjam, KodAlat,
Peralatan, Jum, Catatan, TarikhPohon, NamaPengesah, TarikhSah)
PD
ID  Nama, Jab, NoTel, Kelas
Peminjam (ID, Nama, Jab, NoTel, Kelas)
3NF
TD
KodAlat  Peralatan
PeralatanSukan (KodAlat, Peralatan)
The non-key column,
KodAlat, is fully
dependent upon the key
(ID, TarikhPinjam)
Transitive Dependency
! Peralatan is
determined both by
the key ID,
TarikhPinjam and the
non-key column
KodAlat.

36. 2NF TO 3NF
Transitive dependency
ID, TarikhPinjam (A)  KodAlat (B)
KodAlat (B) Peralatan (C)
ID, TarikhPinjam (A) (A)  Peralatan (C)

37. 2NF TO 3NF
ID Tarikh
Pinjam
Tujuan
Pinjam
KodAlat Jum Catatan Tarikh
Pohon
Nama
Pengesah
Tarikh
Sah
2015F2016 21/1/16 Berlatih R01 2 - 18/1/16 Tay 19/1/16
2015F2016 21/1/16 Berlatih R02 5 - 18/1/16 Tay 19/1/16
2013F2017 22/1/16 Riadah K01 2 - 22/1/16 Tay 19/1/16
Table: PohonAlatSukan
Nama ID Jab NoTel Kelas
Afiq 2015F2016 JTMK 012-3456789 DIP6A
Aiman 2013F2017 JTMK 012-9874563 DIP4A
Table: Peminjam
KodAlat Peralatan Jumlah
R01 Raket Badminton 50
R02 Bulu Tangkis 100
K01 Kayak 10
Table: PeralatanSukan

38. BCNF
Advance version of the 3NF deal with
relational tables that has
 Multiple candidate keys
 Composite candidate keys
 Candidate keys that overlapped.

39. BOYCE-CODD NORMAL FORM
(BCNF)
Def : A relation is in BCNF of and only if every
determinant is a candidate key.
Advance version of normal form.
Based on the concept of determinants.
BCNF is considered to be part of 3NF. It is
perceived to be lower than 4NF but higher than
3NF.
However you may have a table that is in 3NF but
not in BCNF.