Scribd
Upload
19 views

2.4.2. Second Normal Form (2Nf) : Student# Studentname Dateofbirth Course# Coursename Prerequisite Durationindays

The document discusses second normal form (2NF) in database normalization. 2NF requires that a table be in 1NF and that all non-key attributes depend on the whole primary key. To satisfy 2NF, a student-course-result table is split into four tables: Student, Course, Result, and Exam_Date. While this removes partial dependencies, the Result table is still not fully normalized since a change to the grading system would require multiple record updates.

Uploaded by

crazz1
Copyright
© © All Rights Reserved
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
19 views

2.4.2. Second Normal Form (2Nf) : Student# Studentname Dateofbirth Course# Coursename Prerequisite Durationindays

The document discusses second normal form (2NF) in database normalization. 2NF requires that a table be in 1NF and that all non-key attributes depend on the whole primary key. To satisfy 2NF, a student-course-result table is split into four tables: Student, Course, Result, and Exam_Date. While this removes partial dependencies, the Result table is still not fully normalized since a change to the grading system would require multiple record updates.

Uploaded by

crazz1
Copyright
© © All Rights Reserved
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
You are on page 1/ 2

2.4.2.

Second Normal Form (2NF)


A relation is said to be in Second Normal Form if and only if:
It is in the First normal form, and
No partial dependency exists between non-key attributes and key
attributes.
Let us re-visit 1NF table structure.
Student# is key attribute for Student,
Course# is key attribute for Course
Student# Course# together from the composite key attributes for Result
relationship
Other attributes like StudentName (Student Name), DateofBirth,
CourseName, PreRequisite, DurationInDays, DateofExam, Marks and
Grade are non-key attributes.
To make this table 2NF complaint, we have to remove all the partial
dependence.
StudentName and DateofBirth depends only on Student#
CourseName, PreRequisite and DurationInDays depends only on Course#
DateofExam depends only on Course#
To remove this partial dependency we need to split Student_Course_Result
table into four separate tables, STUDENT, COURSEm RESULT and EXAM_DATE
tables as shown in Figure 2.8.
STUDENT Table COURSE Table
Student# StudentName DateofBirth Course# CourseName PreRequisite DurationInDays
101 Davis 4-Nov-86 M1 Basic Mathematics 11
102 Daniel 6-Nov-86 M4 Applied
Mathematics
M1 7
103 Sandra 2-Oct-88 H6 American History 4
104 Evelyn 22-Feb-86 C1 Basic Chemistry 5
105 Susan 31-Aug-85 C3 Bio Chemistry C1 11
106 Mike 4-Feb-87 B3 Botany 8
107 Juliet 9-Nov-86 P1 Basic Physics 8
108 Tom 7-Oct-86 P3 Nuclear Physics P1 13
109 Catherine 6-Jun-84 B4 Zoology 5

RESULT Table EXAM_DATE Table


Student# Course# Marks Grade Course# Dateof
Exam
101 M4 82 A M4 11-Nov-04
102 M4 62 C H6 22-Nov-04
101 H6 79 B C3 16-Nov-04
103 C3 65 B B3 26-Nov-04
104 B3 77 B P3 12-Nov-04
102 P3 68 B B4 27-Nov-04
105 P3 89 A
103 B4 54 D
105 H6 87 A
104 M4 65 B

Figure 2.8 : Second Normal Form


In the first table (STUDENT), the key attribute is Student# and all other
non-key attributes, StudentName and DateofBirth are fully functionally
dependant on the key attribute.
In the second table (COURSE), Course# is the key attribute and all the
non-key attributes, CourseName, PreRequisite and DurationInDays are
fully functionally dependant on the key attribute.
In the third table (RESULT) Student#Course# together are key attributes
and all other non-key attributes, Marks and Grade are fully functionally
dependant on the key attributes.

In the fourth table (EXAM_DATE) Course# is the key attribute and the
non-key attribute, DateofExam is fully functionally dependant on the key
attribute.
These four tables are also complaint with the First Normal Form
definition. Hence these four tables are in Second Normal Form (2NF).
At first look it appears like all our anomalies are taken away! Now we are
storing Student 103 and M4 record only once. We can insert prospective students and
courses at our will. We will update only once if we need to change any data in
STUDENT, COURSE tables. We can get rid of any course or student details by
deleting just one row.
Let us analyze the following table.
Student# Course# Marks Grade
101 M4 82 A
102 M4 62 C
101 H6 79 B
103 C3 65 B
104 B3 77 B
102 P3 68 B
105 P3 89 A
103 B4 54 D
105 H6 87 A
104 M4 65 B

Figure 2.9 : RESULT Table


We already concluded that:
All the attributes are atomic in nature.
No partial dependency exists between the key attributes and non-key
attributes.
RESULT table is n Second Normal Form (2NF).
Assume, at present, as per the university evaluation policy,
Student who score more than or equal to 80 marks are awarded with A
grade.
Student who score more than or equal to 65 up till 79 gets B grade.
Student who score more than or equal to 50 up till 64 fetches C grade.
Student who score marks less than 50 is only D grade.
The university management which is committed to improve the quality of
education, wants to change the existing grading system to a new grading system as
given below:
A+ grade for 95 and above
A grade for 85 to 94
B grade for 70 to 54
B- grade for 65 to 69
C grade for 55 to 64
D grade for 45 to 54
E grade for less than 44
In the present RESULT table structure,
We do not have an option to introduce new grades like A+, B- and E.
We need to do multiple updates on the existing records to bring them to
the new grading definition.
We will not be able to take away D grade if we want to.
2NF does not take care of all the anomalies and inconsistencies.

You might also like