CSC-313 Advanced Database Systems

Lecture 2
Normalization
By
Farah
Shaheen

Acknowledgement:
Department of Information Technology – The UniversityLecture slides material from
of Haripur
Stuart Russell
 Normalization
 The task of database design starts with unnormalized
set of relations.
 The process of producing a simpler and more reliable
database structure.
 Create a suitable set of relations for storing data.
 Different stages of normalization known as normal
forms.
 1st NF, 2nd NF, 3rd NF, 4th NF, 5th NF
 Each normal form has a certain conditions.

Department of Information Technology – The University of Haripur

15
 Functional Dependency
 Functional dependency is a relationship between
attributes.
 It means that, if the value of one attribute is known, it is possible
to obtain the value of another attribute.
 Example,
 Relation: STUDENT
 STUDENT (Reg#, StudentName, Class, Email)
 If value of Reg# is known, it is possible to obtain the value of
StudentName.
 An attribute (StudentName) is functionally dependent on
attribute Reg#. Or Reg# determines the value of
StudentName
 Reg# StudentName

Department of Information Technology – The University of Haripur

16
 Functional Dependency
 Generally, An attribute B is functionally dependent on attribute
A, if the value of A determines the value of B.

 If A and B are attributes or sets of attributes of relations R, B is

functionally dependent on A if each value of A in R has exactly
one associated value of B in R.

 It is possible to determine all the three fields using Reg#,

 Reg# StudentName, Class, Email

Department of Information Technology – The University of Haripur

16
 1st Normal Form
 A relation is in the 1st normal form if it does not contain a
repeating group.
 Repeating Group: is a set of one or more data items that may
occur a variable number of times in a tuple.
 Every Attribute is atomic.
 Every tuple should be unique.
 Each cell in a relation should contain only one value.
Accountant Skill Skill Proficienc Accountan Accountan Group Group City Group
Number Number Category y Number t Name t Age Number Superviso
r

21 113 Systems 3 Ali 55 52 ISD Babar

35 113 Systems 5 Daud 32 44 LHR Ghafoor

179 Tax 1
204 Audit 6

50 179 Tax 2 Chohan 40 44 LHR Ghafoor

77 148 Consulting 6 Zahid 52 52 ISD Babar

179 Tax 6

Department of Information Technology – The University of Haripur

16
 1st Normal Form
 Convert the relation into normal form, repeating groups should
be removed.
Primary Key

Group
Accountant Skill Skill Proficienc Accountan Accountan Group
Group City Superviso
Number Number Category y Number t Name t Age Number
r

21 113 Systems 3 Ali 55 52 ISD Babar

35 113 Systems 5 Daud 32 44 LHR Ghafoor

35 179 Tax 1 Daud 32 44 LHR Ghafoor

35 204 Audit 6 Daud 32 44 LHR Ghafoor

50 179 Tax 2 Chohan 40 44 LHR Ghafoor

77 148 Consulting 6 Zahid 52 52 ISD Babar

77 179 Tax 6 Zahid 52 52 ISD Babar

Department of Information Technology – The University of Haripur

16
 Problems in 1st Normal Form
 Update Anomaly:
 Suppose the user want to change the name of Accountant Number 35 to “M. Daud”.
He has to the name in all records in which Accountant Number 35 appears. This
process of updating can be very lengthy.
 Insert Anomaly:
 Suppose the user wants to add another skull number in the table. It is not possible
until an Accountant with that skill exists because both Skill Number and Accountant
Number are used as primary key in the above table.
 Delete Anomaly:
 Suppose the user wants to delete the record of supervisor Ghafoor. If he deletes the
whole record in which Ghafoor appears, the information about Accountants will also
be lost.

Department of Information Technology – The University of Haripur

16
 Full Functional Dependency
 In a relation R, attribute B of R is fully functionally dependent on an
attribute or set of attributes A of R is functionally dependent on A but not
functionally dependent on any other proper subset of A.
 Suppose there is a relation MARKS as follows:
 MARKS (Reg#, Subject, Marks)
 Assume that one student is studying many subjects. Both Reg# and
Subject are required to determine a particular marks. It can be written as:
 Reg#, Subject  Marks
 Here, marks is fully functionally dependent on both fields because it is
not functionally dependent on either Reg# or Subject alone.

Department of Information Technology – The University of Haripur

16
 2nd Normal Form
 A relation is in 2nd NF, if
 1) It is in 1st NF
 2) All it`s nonkey attributes are fully functionally dependent on the whole
key. It means that none of non-key attributes are related to a part of key.
 The previous relation is in 1st NF. But some attributes which are not
depending on the whole primary key.
 Example: Accountant Name, Accountant Age and group information is
determined by Accountant Number and is no dependent in Skill Number.

Department of Information Technology – The University of Haripur

16
 2nd Normal Form
 Here is the relation created from the previous relation, which all attributes
are fully dependent in primary key Accountant Number.

Primary Key

Accountant Accountant Accountant Group Group

Group City
Number Name Age Number Supervisor

21 Ali 55 52 ISD Babar

35 Daud 32 44 LHR Ghafoor

50 Chohan 40 44 LHR Ghafoor

77 Zahid 52 52 ISD Babar

Department of Information Technology – The University of Haripur

16
 2nd Normal Form
 Similarly, another relation Skill  The attributes of all relations are
can be created in which all the fully dependent on the primary
fields are fully dependent on the keys.
primary key as follows:
Primary Key

Accountant
Skill Number Proficiency
Primary Key Number

21 113 3
Skill
Skill Category
Number 35 113 5

113 Systems 35 179 1

179 Tax 35 204 6

204 Audit 50 179 2

77 148 6
148 Consulting
77 179 6

Department of Information Technology – The University of Haripur

16
 Transitive Dependency
 A condition in which an attribute in which an attribute is dependent on an
attribute that is not part of the primary key.
 Example: Suppose there is a relation BOOK as follows:
 BOOK(BookID, BookDescription, CategoryID, CategoryDescription)
 We can write,
 BookIDCategoryID, CategoryID CategoryDescription
 A transitive dependency occours when one non-key attribute determines
another non-key attribute.
 In the above example, BookID determines CategoryID and CategoryID
determines CategoryDescription.
 CategoryDesacription is transitively dependent on BookID attribute.
Department of Information Technology – The University of Haripur
16
 3rd Normal Form
 A relation is in 3rd normal form if,
 1) It is in 2nd normal form.
 2) if no non-key attribute is dependent on another non-key attribute. It means that all non-key
attributes are functionally dependent only on primary key. (No transitive dependency in a
relation).
 The accountant table in 2 nd NF contains some attributes which are depending on non-key
attributes, for example, Group City, and Group Supervisor are depending on a non-key field
Group Number.

Department of Information Technology – The University of Haripur

16
 3rd Normal Form
Primary Key

Accountant Accountant Accountant Group

Number Name Age Number

21 Ali 55 52

35 Daud 32 44

50 Chohan 40 44

77 Zahid 52 52

The second table is created from the Accountant table in 1st NF is as follows.

Primary Key

Group Group
Group City
Number Supervisor

52 ISD Babar

44 LHR Ghafoor

Department of Information Technology – The University of Haripur

16
 3rd Normal Form
The skill and Proficiency tables in 2nd NF contains no attributes, which is depending on a non-key attributes.
It is already in 3rd NF.

Primary Key

Accountant
Skill Number Proficiency
Primary Key Number

21 113 3
Skill
Skill Category
Number 35 113 5

113 Systems 35 179 1

179 Tax 35 204 6

204 Audit 50 179 2

77 148 6
148 Consulting
77 179 6

Department of Information Technology – The University of Haripur

16
 Boyce-codd Normal Form (BCNF)
 A relation is in BCNF if and only if every determinant is a candidate key.
 Identify all determinants and make sure that all these determinants are candidate keys.
Primary Key

ProjectID PartID QuantityUsed PartName

 Dependencies:
101 P01 20 CD-R
 (ProjectID, PartID)QtyUsed 112 P05 6 Zip Disk

 PartIDPartName 194 P01 12 CD-R

 PartNamePartID 194 P02 1

Box floppy
disks
 Assume PartName is unique 194 P05 3 Zip Disk

 Satisfies 2nd NF
 No transitive dependencies, so the relation is in 3 rd NF
 PartID and PartName are ignored by 3 rd NF rule because they are both key attributes.

Department of Information Technology – The University of Haripur

16
 Boyce-Codd Normal Form (BCNF)
Primary Key

ProjectID PartID QuantityUsed

101 P01 20

112 P05 6

194 P01 12

194 P02 1

194 P05 3

Primary Key

PartID PartName

P01 CD-R

Box floppy
P02
Disks

P05 Zip disk

Department of Information Technology – The University of Haripur

16
 4th Normal Form
 Multi-valued dependencies exist when a relation has at least three attributes, two of them are
multi-valued and their values depend on only the third attribute.
 For example, R(A, B, C). Multivalued dependencies exists if:
• 1. A determines multiple values of B
• 2. A determines multiple values of C
• 3. B and C are independent of each other.
 Multivalued dependencies: StudentID Subject Interest
 StudentIDSubject 100 Math Reading
 StudentIDInterest 100 Accounting Reading

100 Math Tennis

100 Accounting Tennis

150 Economics Jogging

Department of Information Technology – The University of Haripur

16
 4th Normal Form
Anomalies are:
Suppose StudentID 100 decides to take another course “Economics”. It
requires the addition of two tuples i.e., one with combination of Reading and
one with combination of Tennis as follows:

100 Econmics Reading

100 Economics Tennis

Similarly, if a student wants to drop a subject, all tuples containing that

particular subject have to be deleted.

Department of Information Technology – The University of Haripur

16
 4th Normal Form
Create two relations, each will contain data for only one multivalued attribute.

StudentID Subject StudentID Interest

100 Math 100 Reading

100 Accounting 100 Tennis
150 Economics 150 Jogging

Department of Information Technology – The University of Haripur

16
 Lossless Join Dependency
• A property of decomposition that ensures that no spurious tuples are
generated when relations are reunited through a natural join operation.

• A relation that is decomposed during normalization can be rejoined by

using Joins to produced the original data.

• Decomposition may be in more than 2 relations.

• Lossless join dependency ensures that id the decomposed relations are

reunited, data is not lost and no additional tuples are generated.

Department of Information Technology – The University of Haripur

16
 5th Normal Form
• A relation is in 5th normal form of it has no join dependency.

• A relation decomposed into two relations must have lossless join

Property, which ensures that no spurious or extra tuples are
generated when relations are reunited through a natural join.

A relation R is in 5NF if and only if it satisfies the following conditions:

1. R should be already in 4NF.
2. It cannot be further non loss decomposed (join dependency).

Department of Information Technology – The University of Haripur

16