Normalization
the process of determining how much redundancy exists in a table
Last updated
the process of determining how much redundancy exists in a table
Last updated
Normalization is a schema/database design process that minimizes data duplication and enforces data integrity.
A simple definition for practical purposes is:
Separate each entity into its own table.
Separate each discrete attribute into its own column.
Uniquely identify each entity instance (row) using a primary key.
Use foreign key columns to link related entities.
In the first normal form, only single values are permitted at the intersection of each row and column; hence, there are no repeating groups.
To normalize a relation that contains a repeating group, remove the repeating group and form two new relations.
The PK of the new relation is a combination of the PK of the original relation plus an attribute from the newly created relation for unique identification.
Student_Grade_Report (StudentNo, StudentName, Major, CourseNo, CourseName, InstructorNo, InstructorName, InstructorLocation, Grade)
In the Student_Grade_Report table, the repeating group is the course information. A student can take many courses.
Remove the repeating group. In this case, it’s the course information for each student.
Identify the PK for your new table.
The PK must uniquely identify the attribute value (StudentNo and CourseNo).
After removing all the attributes related to the course and student, you are left with the student course table (StudentCourse).
The Student table (Student) is now in first normal form with the repeating group removed.
Student (StudentNo, StudentName, Major)
StudentCourse (StudentNo, CourseNo, CourseName, InstructorNo, InstructorName, InstructorLocation, Grade)
To add a new course, we need a student.
When course information needs to be updated, we may have inconsistencies.
To delete a student, we might also delete critical information about a course.
For the second normal form, the relation must first be in 1NF. The relation is automatically in 2NF if, and only if, the PK comprises a single attribute.
If the relation has a composite PK, then each non-key attribute must be fully dependent on the entire PK and not on a subset of the PK (i.e., there must be no partial dependency or augmentation).
To move to 2NF, a table must first be in 1NF.
The Student table is already in 2NF because it has a single-column PK.
StudentCourse (StudentNo, CourseNo, CourseName, InstructorNo, InstructorName, InstructorLocation, Grade)
When examining the Student_Course table, we see that not all the attributes are fully dependent on the PK; specifically, all course information. The only attribute that is fully dependent is grade.
Identify the new table that contains the course information.
Identify the PK for the new table.
CourseGrade (StudentNo, CourseNo, Grade)
CourseInstructor (CourseNo, CourseName, InstructorNo, InstructorName, InstructorLocation)
When adding a new instructor, we need a course.
Updating course information could lead to inconsistencies for instructor information.
Deleting a course may also delete instructor information.
To be in third normal form, the relation must be in second normal form. Also all transitive dependencies must be removed; a non-key attribute may not be functionally dependent on another non-key attribute.
Eliminate all dependent attributes in transitive relationship(s) from each of the tables that have a transitive relationship.
Create new table(s) with removed dependency.
Check new table(s) as well as table(s) modified to make sure that each table has a determinant and that no table contains inappropriate dependencies.
Course (CourseNo, CourseName, InstructorNo)
Instructor (InstructorNo, InstructorName, InstructorLocation)
At this stage, there should be no anomalies in third normal form.
Resources
