Professional Documents
Culture Documents
A B
Emp-Id is the only determinant (The attribute on the left hand side of the
arrow in a functional dependency) in this relation. All of the other attributes are
functionally dependent on EMP-ID.
NORMALIZATION
1
First Normal Form : -
The above table contains the repeating groups. The table can be
converted to the relation EMP by removing the multi-valued attributes. The
following table illustrates the EMP relation.
b) EMP Relation:
Emp_Id Name Salary Course_Title Date_Completed
100 Simpson 20000 Oracle 2/2/04
100 Simpson 20000 C 10/2/04
101 Blake 10000 Accounts 11/2/04
102 Chris 12000 C++ 13/2/04
2
102 Chris 12000 Java 14/2/04
103 Davis 10000 NetWorks 20/2/04
So, The above EMP relation in first normal form because the relation EMP
contains no multi-valued attributes.
A relation that is in first normal form will be in second normal form if any
one of the following conditions applies:
The above relation that is not in second normal form. The Primary Key for
this relation is the Composite Key Emp_Id, Course_Title. Therefore non-key
attributes Name and Salary are functionally dependent on part of the Primary
Key (Emp_Id) but not on Course_Title. These dependencies are shown in the
above figure.
So, the EMP relation to convert to second normal form, we decompose the
relation into new relations that satisfy one of the conditions described above.
The EMP relation is decomposed into the following EMPLOYEE and EMP_COURSE
relations.
EMPLOYEE
3
EMP_COURSE
SALES
Cust_Id Name Sales_Person Region
1 Srinvias Smith South
2 Jones Williams West
3 Ramu Smith South
4 Vasu Eagle East
5 Kishore Williams West
6 Ford Naren North
SALES
Cust_Id Name Sales_Person Region
Cust_Id is the Primary Key, so that all of the remaining attributes are
functionally dependent on this attribute. Region is functionally dependent on
Sales_Person and Sales_Person is functionally on Cust_Id. This is a transitive
dependemncy.
4
These anamolies arise as a result of the transitive dependency. The
transitive dependency can be removed by decomposing SALES into two
relations. The two relations SALES1 and SPERSON are shown in the following
figure.
SALES1 SPERSON
Cust_Id Name Sales_Person Sales_Person Region
1 Srinivas Smith Smith South
2 Jones Williams Williams West
3 Ramu Smith Eagle East
4 Vasu Eagle Naren North
5 Kishore Williams
6 Ford Naren
SPERSON
Sales_Person Region
SALES1
Cust_Id Name Sales_Person
When a relation has more than one candidate key, anomalies may result
even though that relation is in 3NF. For example, the STUDENT_ADVISOR
relation shown in figure(a). This relation has Student_Id, Major, Advisor and
Maj_GPA.
STUDENT_ADVISOR
Student_Id Major Advisor Maj_GPA
1 Physics Prasad 4.0
1 Computers Kumar 3.3
2 Maths Venkat 3.2
3 Computers Chandu 3.7.
4 Physics Prasad 3.5
5
Student_Id Major Advisor Maj_GPA
In the above figure (b), the Primary Key for this relation is the composite
key consisting of Student_Id and Major. Thus, the two attributes Advisor and
Maj_GPA are functionally dependent on this key. Major is functionally depending
on Advisor. So that is not a transitive dependency.
Anomalies in STUDENT_ADVISOR
The determinant Advisor becomes part of the composite Primary Key. The
attribute major in which functionally dependent on Advisor and a non-key
attribute.
You will discover that the new relation has a partial functional
dependency. So, the relation is in first normal form.
The two relations named STUDENT and ADVISOR with sample data are
shown in figure. You should verify that these relations are free of the anomalies.
6
STUDENT ADVISOR
Student_Id Advisor Maj_GPA Advisor Major
1 Prasad 4.0 Prasad Physics
1 Kumar 3.3 Kumar Computers
2 Venkat 3.2 Venkat Maths
3 Chandu 3.7 Chandu Computers
4 Prasad 3.5
OFFERING OFFERING
Course Instructor Textbook Course Instructor Textbook
Managemen Mohan Dennis Management Mohan Dennis
t Krishna Ritche Management Mohan Ritchie
Rama rao Management Krishna Dennis
Rajiv Ching Management Krishna Ritche
Finance Chang Management Rama rao Dennish
Management Rama rao Ritche
Finance Rajiv Ching
Finance Rajiv Chang
(a) Table of Courses, Instructors & Textboks (b) Relation in BCNF
This shows for each course the instructors who teach that course and the
textbooks that are used.
In the above figure (b) that table has been converted to a relation by
filling in all of the empty cells. So, that table offering in first normal form. The
Primary Key of this relation consists of all three Course, Instructor and Textbook
attributes. Since there are no determinants other than the Primar Key, so the
relation OFFERING in BCNF.
The relation contains all much redundant data. For example, suppose that
we want to add a third textbook. Robinson to the Management Course. This
change would require the addition of three new rows to the relation in figure(b).
The type of dependency shown in this example is called a multi-valued
dependency (there are at least three attributes A, B and C is a relation, and for
each value of A there is a well-defined set of values of B and a well-defined set
of values of C. However, the set of values of B is independent of set C and vice-
versa.)
7
TEACHER TEXT
Course Instructor Course Textbook
Management Mohan Management Dennis
Management Krishna Management Ritchie
Management Rama rao Finance Ching
Finance Rajiv Finance Chang
TEACHER contains the Course and Instructor attributes since each course
there is a well-defined set of instructors. The TEXT contains the attributes
Course and Textbook. However, there is no relation containing the attributes
instructor and course. Since these attributes are independent.
To explain this normal form let us consider the SPJ relation ship.
SPJ(S#,P#,J#)
S# P# J#
S1 P1 J2
S1 P2 J1
S2 P1 J1
S1 P1 J1
SP(S#,P#) PJ(P#,J#)
SPJ(J#,S#)
S# P# P# J# S# P# J#
8
S1 P1 P1 J2 S1 P1 J2
S1 P2 P2 J1 S1 P1 J1
S2 P1 P1 J1 S1 P2 J1
S2 P1 J2
S2 P1 J1
Join over P#
The resulting relation in join with the JS over (J#,S#)
JS(J#,S#) SPJ(S#,P#,J#)
J# S# S# P# J# S# P# J#
J2 S1 S1 P1 J2 S1 P1 J2
J1 S1 S1 P1 J1 S1 P1 J1
J1 S2 S1 P2 J1 S1 P2 J1
S2 P1 J2 S2 P1 J1
S2 P1 J1
The basic SPJ table into three projections and join those projections with
respect to their candidate keys. The above diagrams illustrate the project-join
operations.