0% found this document useful (0 votes)
9 views26 pages

14 - FDs and Normalization Part-1

Uploaded by

Bhavya
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
9 views26 pages

14 - FDs and Normalization Part-1

Uploaded by

Bhavya
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 26

Introduction to Functional

Dependencies
Let R be a relation and A & B be the sub-sets of
attributes of R, then B is said to be functionally
dependent on A if given A we can accurately
determine B.
If B is functionally dependent on A then it is
denoted as AB.
Example:
Emp_Project (Eid, EName, Proj_Name, Proj_No,
Proj_LOC, Hours)
The following FDs exists in above relation
1. Eid  EName
Given Id of employee we can find the name
of the employee corresponding to that Id.
2. Proj_No  Proj_Name, Proj_Loc
Given project number, we can find out the
project corresponding to that project number.
Similarly we can find project LOC from Proj_No.
3. {Eid, Proj_No}  Hours
Given Employee Id and project number on
which an employee is working, we can find no of
hours worked by each employee on a particular
project.
4. EName -->< EId
EName does not functionally determine EId
because there may be two employees with the
same name.
Fully Functional Dependency
Let R be the relation then an attribute B is said to
be fully functionally dependent on attribute A if it
is functionally dependent on A and not
functionally dependent on any proper subset of A.
The following FD
{Eid, Proj_No, Proj_LOC}  Hours, is not fully
functionally dependent on the set on the left hand
side because no of hours worked can also be
determined by a sub-set of set on left side of FD.
{Eid, Proj_No}  Hours, Hour is now fully
functionally dependent on Eid and Proj_No
because neither Eid nor proj_No alone can
determine number of hours worked by employee.
Trivial Functional Dependency

A FD is trivial if and only if the right hand side


attribute(s)
is a sub-set of the left hand side attribute(s),

AB, where B is sub-set of A

Example,
Customer_name  Customer_name
{Customer_name, loan_number} 
Customer_name
Non-Trivial Functional
Dependency
An FD in which at least one attribute on right
hand side of FD is not contained in left side
attributes of FD
AB, where B is not a sub-set of A
Example
{Eid, Proj_No}  Hours,
Here Hours is not a sub-set of {Eid, Proj_No}
NORMALIZATION

Normalization is a process by which we


efficiently organize data to achieve these
goals:
◦ Eliminating Redundancy,

◦ Ensuring data is stored in the correct


table,
◦ Eliminating need of restructuring the
database when data is added.
Normalization integrity
First Normal Form (1NF)

There are no repeating or duplicate fields.


Each cell contains only a single value.
Each record is unique
Identified primary key.
Example 1NF
Second Normal Form (2NF)

A relation is said to be in 2NF if it is in 1NF and


every non-prime attribute of R is fully
functionally dependent on primary key of R.
Another way to say this: A relation is in
second normal form if it is free from partial-
key dependencies
Relations that have a single attribute for a key
are automatically in 2NF.
Third Normal Form (3NF)

A relation is said to be in 3NF if it is in 2NF and


no non-prime attribute of R is transitivity
dependent on primary key of R.
Example of 1NF

Consider a table which is not in First normal form


Student Table :

Student Age Subject

Adam 15 Biology, Maths

Alex 14 Maths

Stuart 17 Maths
Example of 1NF

 Student Table1 following 1NF will be :

Student Age Subject


Adam 15 Biology
Adam 15 Maths
Alex 14 Maths
Stuart 17 Maths
Example of 2NF

Consider a table which is not in 2NF


Student Table1 :

Student Age Subject


Adam 15 Biology
Adam 15 Maths
Alex 14 Maths
Stuart 17 Maths
New Student_Table2
following 2NF will be : New Subject_Table
In Student Table the introduced for 2NF will be :
candidate key will In Subject Table the candidate
be Student column, because key will be {Student, Subject}
all other column i.e Age is column.
dependent on it.
Student Subject
Studen Age
t Adam Biology
Adam 15 Adam Maths
Alex 14
Alex Maths
Stuart 17
Stuart Maths

Now, both the above tables qualifies for Second Normal Form
and will never suffer from Update Anomalies. Although there
are a few complex cases in which table in Second Normal Form
suffers Update Anomalies, and to handle those scenarios Third
Normal Form is there.
Example of 3NF
Third Normal form applies that every non-prime
attribute of table must be dependent on primary
key, or we can say that, there should not be the
case that a non-prime attribute is determined by
another non-prime attribute. So this transitive
functional dependency should be removed from the
table and also the table must be in Second
Normal form. For example, consider a table with
following fields.
Student_Detail Table :

Student_i Student_nam DOB Stree city Stat Zip


d e t e
Example of 3NF
In this table Student_id is Primary key, but
street, city and state depends upon Zip. The
dependency between zip and other fields is
called transitive dependency. Hence to
apply 3NF, we need to move the street, city
and state to new table, with Zip as primary key.
Student_Detail Table1 :

Student_ Student_nam DOB Zip


id e
Address Table:

Zip Street city state


Third Normal Form
 For a relation to be in Third Normal Form, it
must be in Second Normal form and the
following must satisfy −
 No non-prime attribute is transitively
dependent on prime key attribute.
We find that in the above Student_detail relation,
Stu_ID is the key and only prime key attribute.
We find that City can be identified by Stu_ID as
well as Zip itself. Neither Zip is a superkey nor is
City a prime attribute. Additionally, Stu_ID → Zip
→ City, so there exists transitive dependency.
To bring this relation into third normal form, we
break the relation into two relations as follows −
END of Part-1
Sources

www.studytonight.com/dbms/database-
normalization.php
www.tutorialspoint.com/dbms/pdf/
database_normalization.pdf
www.tutorialspoint.com/dbms/
dbms_storage_system.htm

www.tutorialcup.com/dbms/boyce-codd-normal-form.ht
m
Other Books.

You might also like