Functional

Dependency &
Normalization
 Dependen
• A dependency
cy in a whe
information
occurs stored in database n
the
uniquely determines other information
same storedtabl
in
the same table. database e
 Functional
• A
Dependency
functional dependency is defined as a
constraint between two sets of attributes in a
relation from a database.

• Given a relation R, a set of attributes X in R is

said to functionally determine another
attribute Y, also in R, (written X → Y)
if and only if each X value is associated with at
most one Y value.
• A Functional Dependency describes a
relationship between
attributes within a single relation.

• An attribute is functionally dependent on another if we

can use the value of one attribute to determine the value
of another.
• We the arrow symbol → to indicate a
use
dependency.
functional
X → Y is read X functionally determines
Y
 In other
words….
X is the determinant set and Y is the dependent
attribute. Thus, given a tuple and the values of
the attributes in X, one can determine the
corresponding value of the Y attribute.
Functional Dependence
(FD)
Functional Dependence
(FD)
 Fully Functional
S_No. Name Status City
S1 Dependency
Suneet 10 Jalandhar
S2 Ankit 10 Amritsar
S3 Amit 30 Amritsar
 Examp
le
S_No. Name Status City
 Supplier S1 Suneet 20 Qadian

Records S2 Ankit 30 Amritsar

S3 Amit 30 Amritsar

P_No. Name Color Weight City  Part

P1 Nut Red 12 Qadian Records
S_No. P_No. Qty.
P2 Bolt Green 17 Amritsar
S1 P1 250
P3 Screw Blue 17 Jalandhar
S1 P2 300
P4 Screw Red 14 Qadian
S1 P3 500
S2 P1 250
 Shipment S2 P2 500

Records S3 P2 300
 Key
•
s
key is a set of attributes that uniquely identifies
an entire tuple, a functional dependency
allows us to express constraints that uniquely
identify the values of certain attributes.

• However, a candidate key is always a

determinant, but a determinant doesn’t need to
be a key.
 Normalizati
on
• Data normalization is a technique of
organizing the data in database.
• Normalization of data can be defined as a
process during which redundant relation
schemas are decomposed by breaking up
their attributes into smaller relation
schemas that process desirable
properties.
Objectives of
Normalization
Normal
Forms
 First Normal
•
Form
A relation is said to be in 1NF if and only if
every cell/entry of the relation has at most
a single value. In other words “a relation is
in
1NF if and only if all underlying
contain
domainsatomic values or single value
only.”
•The objective of normalizing a table is to
remove its repeating groups and ensure
that all entries of the resulting table have
at most a single value.
 Example: Unnormalized
e r
table
Cours Course Name Teache Roll
No
Name System
Used
Hourly
Rate
Total
Hours
Code Name
C1 Visual Basic ABC 100 A1 P –I 20 7
101 A2 P – II 30 3
102 A3 Celeron 10 6
103 A4 P – IV 40 1
C2 Oracle & Dev DEF 100 A1 P –I 20 7
104 A5 P – III 35 3
105 A6 P – II 30 1
101 A2 P – II 30 2
C3 C++ KJP 106 A7 P – IV 40 3
107 A8 P – IV 40 2
108 A9 P –I 20 1
C4 Java Kumar 109 A10 Cyrix 20 2
 Approaches to normalize
table
• In general, there are two basic
approaches to normalize tables.
 STUDENT
(Flattening)
(Normalized
Course Course Name Teacher Roll Name System Hourly Total
Code Name
Table)
No Used Rate Hours
C1 Visual Basic ABC 100 A1 P –I 20 7
C1 Visual Basic ABC 101 A2 P – II 30 3
C1 Visual Basic ABC 102 A3 Celeron 10 6
C1 Visual Basic ABC 103 A4 P – IV 40 1
C2 Oracle & Dev DEF 100 A1 P –I 20 7
C2 Oracle & Dev DEF 104 A5 P – III 35 3
C2 Oracle & Dev DEF 105 A6 P – II 30 1
C2 Oracle & Dev DEF 101 A2 P – II 30 2
C3 C++ KJP 106 A7 P – IV 40 3
C3 C++ KJP 107 A8 P – IV 40 2
C3 C++ KJP 108 A9 P –I 20 1
C4 Java Kumar 109 A10 Cyrix 20 2
Approaches to normalize
table
 STUDENT
(Decomposition)
COUR (Normalized Table)
Course
Code
Roll
No
Name System
Used
Hourly
Rate
Total
Hours
Course SE
Course Name Teacher
Code Name C1 100 A1 P–I 20 7

C1 Visual Basic ABC C1 101 A2 P – II 30 3

C2 Oracle & Dev DEF C1 102 A3 Celeron 10 6

C3 C++ KJP C1 103 A4 P – IV 40 1

C4 Java Kumar C2 100 A1 P–I 20 7

C2 104 A5 P – III 35 3
C2 105 A6 P – II 30 1
COURSE_STUD C2 101 A2 P – II 30 2
ENT C3 106 A7 P – IV 40 3
C3 107 A8 P – IV 40 2
C3 108 A9 P–I 20 1
PK =
C4 109 A10 Cyrix 20 32
(Course_code, 3
 Anomalies in 1NF
• Relations
Redundancies in 1NF relations lead to a variety of data
anomalies.
1. Insert anomalies:
We cannot insert the information about the student
until he joins any course e.g. we cannot store
information about the roll no 110 until he join any
course, similarly we are unable to store the
information about the course until there is a student
who enroll into that course.
These anomalies occur because course_code, rollno is the
composite key and we cannot insert null in any of
these two attributes.
 Anomalies in 1NF
Relations
2. Update anomalies:
This relation is also susceptible to update anomalies
because the course in which a student studies may appear
many times in the table. If a teacher moves to another
course, we are now faced with two problems: we either
search the entire table looking for that teacher and update
his or her course_code value or we miss one or more
tuples of that STUDENT and end up with an inconsistent
database. For small tables, this type of anomaly may not
seem to be much of a problem.
But for larger tables this may cause the problem of
inconsistency.
 Anomalies in 1NF
3.
Relations
Delete anomalies:
This relation experiences deletion anomalies whenever we
delete the last tuple of a particular student. In this case, we
not only delete the course information that connects that
student to a particular course, but also lose other
information about the system on which this student works.
Let us consider, the case where we have to delete the
information of student having rollno 109, then we also lose
the information about course_code C4 . Also if we have to
delete the information of java course we lose the
information about the student Kumar.
 Second Normal Form
• (2NF)
A relation R is in 2NF if and only if it is in
1NF and every non-key attribute is fully
functional dependent on the primary key.
Name

RollNo
System_Used

Functional
Cours_Code Hourly_Rate
Dependence
Course_Name
Diagram

Total Hrs. Teacher_Nam

e
 Second Normal Form
(2NF)
• A resultant database of 1NF Course_Code
not
does above rule, because non-
attribute
satisfy Name, key
s
Hourly_Rate areSystem_Used
not fully dependent and
on the
primary key (Course_Code, Rollno) because
Name, System_Used and Hourly_Rate are
functional dependent on Rollno and Rollno is a
subset of the primary key so it does not hold
the law of fully functional dependence.
 Rule to convert 1NF to
• 2NF
Consider a relation where a primary key
consists of attributes A and B. These two
attributes determine all other attributes.
• Attribute C is fully dependent on the key.
• Attribute D is partially dependent on the
because we only need attribute A to
key
functionally determine it.
•Attributes C and D are non-key
attributes.
 Rule to convert 1NF to
• 2NF
The rule is to replace the original relation
by two new relations. The first new
relation has three attributes: A, B and C.
The primary key of this relation is (A, B)
i.e. the primary key of the original relation.
The second relation has A and D as its
only two attributes. Observe that attribute
A has been designated, as the primary
key of the second relation and that
attribute D is now fully dependent on the
 Rule to transform 1NF to
2NF

A*
A* A*
B
Convert B D
* To
*
C
C
D
1N 2N
F F
 Second Normal Form
HOURS_ASSIG (2NF)
STUDENT_SYSTEM_CH
NED
Cours ARGE
Roll Name System Hourly
Roll Total
e No Hours No Used Rate
Code
100 A1 P–I 20
C1 100 7 COUR
C1 101 3 101 A2 P – II 30 Cours SE
Course Teacher
C1 102 6 102 A3 Celeron 10 e Name Name
103 A4 P – IV 40 Code
C1 103 1
Visual
C2 100 7 100 A1 P–I 20 C1 ABC
Basic
C2 104 3 104 A5 P – III 35
Oracle
105 A6 P – II 30 C2 DEF
C2 105 1 & Dev
C2 101 2 101 A2 P – II 30
106 A7 P – IV 40 C3 C++ KJP
C3 106 3
107 A8 P – IV 40 C4 Java Kumar
C3 107 2
C3 108 1 108 A9 P–I 20
C4 109 2 109 A10 Cyrix 20
 Removal of
Anomalies of
• Insert Anomalies: It is now possible to
1NF Relations
insert the information about the student
who does not join any course e.g. we can
store the information about the Rollno 110
who does not join any course in
STUDENT_SYSTEM_CHARGE
database. Similarly now we are able to
store the information about the course
which has no enrolled student e.g. we can
store that C1 course is of Visual Basic in
COURSE table.
 Removal of
Anomalies of
1NF Relations
• Updat Anomalies: Now, it is
e
change the teacher possible
for a particular
to course
in the COURSE table through a single
modification. So, no data inconsistency will
arise.
•Delete Anomalies: in the revised
structure, we can delete the information of
student having Rollno 109 without losing
the information about his course i.e. C4.
 Anomalies in
• Relations 2NF
in 2NF are still to
subject
anomalies. Let us assume that the data
system
on which a student works functionally
determines the hourly rate charged from
the student i.e.
System_Used  Hourly_Rate
•Dueto this fact the anomalies
will occur in case of 2NF.
 Anomalies in 2NF
• Insert Relations
Anomalies: Insertion anomalies
occur in the Student_System_Charge
relation. For example, consider a situation
where we would like to set in advance the
rate to be charged from the students for a
particular system. We can not insert this
info. Until there is a student assigned to
that type of system because Rollno is the
primary key for this relation and we can
not insert the null value into it.
 Anomalies in
2NF
• Update Anomalies: Update will
also occur in the Student_System_Charge
anomalies
relation because there may be several
students which are working on the same
type of the system. If the Hourly_Rate for
a particular system changes, we need to
make sure that the corresponding rate is
changed for all the students that work on
that type of system. Otherwise, the
database may end up in an inconsistent
state.
 Anomalies in
2NF
• Delete Anomalies: Delete anomalies will
also occur in the
Student_System_Charge relation. This
type of anomaly occurs whenever we
delete the tuple of a student who happens
to be the only student left which is
working on a particular system. In this
case, we will also lose the information
about the rate that we charge for that
particular system.
 Prime and nonprime
attributes
• An attribute of a relation schema R is
called Prime attribute if it is a member of
some candidate key of R.
• An attribute is called non prime if it is not a
prime attribute i.e. it is not the member of
any candidate key.
 Third Normal Form
• A relation
(3NF)
R is in 3NF if and if
following
only conditions are the
simultaneously:
satisfied
–R is already in 2NF
–No nonprime attribute functionally determines any
other non-prime attribute Or No nonprime attribute is
transitively dependent on the key
•The objective of transforming
relations into 3NF is to remove all transitive
dependencies.
 Third Normal Form
(3NF) Functional
Name
Dependence
Diagram
RollNo System_Used RollNo  System_Used
System_Used 
Hourly_Rate
Hourly_Rate
It Means RollNo 
Hourly_Rate
Rule to Resolve Transitivity
Dependence
A*
A* B
B Convert
To B C

C 2N 3N
F F
 Third Normal Form
Roll System
(3NF)
STUDENT_SYSTEM_CHARGE
Name
STUDENT_SYSTEM
Hourly Roll Name System
No Used Rate No Used
100 A1 P–I 20 100 A1 P–I
CHARGES
System Hourly
101 A2 P – II 30 101 A2 P – II
Used Rate
102 A3 Celeron 10 102 A3 Celeron
Celeron 10
103 A4 P – IV 40 103 A4 P – IV
Cyrix 20
100 A1 P–I 20 Convert 100 A1 P–I
To P–I 20
104 A5 P – III 35 104 A5 P – III
P – II 30
105 A6 P – II 30 105 A6 P – II
P – III 35
101 A2 P – II 30 101 A2 P – II
P – IV 40
106 A7 P – IV 40 106 A7 P – IV
107 A8 P – IV 40 107 A8 P – IV
108 A9 P–I 20 108 A9 P–I
109 A10 Cyrix 20 2N 109 A10 Cyrix 3N
 Removal of
Anomalies of
2NF In
• Insert Anomalies: Relations
the revised structure
of STUDENT_SYSTEM and CHARGES,
it is possible to insert in advance the rate
to be charged from the students for a
particular system.
• Update Anomalies: If the Hourly_Rate for
a particular system changes, we need
only to change a single record in
CHARGES database for that particular
system.
 Removal of
Anomalies of
2NF Relations
• Delete Anomalies: We delete the tuple of
a student who happens to be the only
student left which is working on a
particular system without losing the
information about the rate that we charge
for that particular system.
 Anomalies in
3NF
• The relations in 3NF are suceptible to data
anomalies particularly when the relations
have two overlapping candidate keys or
when a non-prime attribute functionally
determines a prime attribute. Let us
consider the example which illustrate
these anomalies:
 Anomalies in
3NF
• We can take a case of Supplier_Part
Table having following attributes:
Supplier_Part(Sno, Sname, Pno, Qty)
Lets suppose that Sname is
unique for each Sno as shown
below: Sno Sname Pno Qty
S1 Rahat P1 300
S2 Raju P2 200
S1 Rahat P3 100
S2 Raju P1 200
 Anomalies in
3NF
• This relation has two candidate keys:
(Sno, Pno) and (Sname, Pno) that overlap
on the attribute Pno. The relation is in
3NF because there is single nonprime
attribute.
• The relation is susceptible to update
anomalies e.g. if one of the supplier
changes its name, then we have to make
multiple changes which is equal to the
number part supplied by that particular
 Steps of
Normalization
Step 1. Create Unnormalized Relation
1N
Step 2. Separate Repeating & Non-
F
repeating Attributes

2N Step 3. Remove Partial Dependencies

F
3N Step 4. Remove Transitive
F Dependencies
4N Step 5. Remove Multi-Valued
F Dependencies
Step 6. Decompose Table Such That
5N Further Decomposition is not
F Possible
 Conclusion
1. Database designing is critical to the successful implementation of a
database management system that meets the data requirements of
an enterprise system.
2. Normalization helps produce database systems that are cost-
effective and have better security models.
3. Functional dependencies are a very important component of the
normalize data process
4. Most database systems are normalized database up to the third
normal forms.
5. A primary key uniquely identifies are record in a Table and cannot
be null
6. A foreign key helps connect table and references a primary key