Scribd
Upload
331 views3 pages

Student Table Normalization Guide

This document demonstrates the process of normalizing a student data table through three forms: 1) First normal form removes repeating groups by creating a separate table for student classes. 2) Second normal form eliminates redundant data by creating a separate table for the student-class relationships. 3) Third normal form removes attributes not dependent on the key by moving the advisor's room number to a faculty table.

Uploaded by

abdi
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
331 views3 pages

Student Table Normalization Guide

This document demonstrates the process of normalizing a student data table through three forms: 1) First normal form removes repeating groups by creating a separate table for student classes. 2) Second normal form eliminates redundant data by creating a separate table for the student-class relationships. 3) Third normal form removes attributes not dependent on the key by moving the advisor's room number to a faculty table.

Uploaded by

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

Operation Sheet 2 Normalizing an Example Table

These steps demonstrate the process of normalizing a fictitious student table.


1. Unnormalized table:

Student# Advisor Adv-Room Class1 Class2 Class3

1022 Jones 412 101-07 143-01 159-02

4123 Smith 216 201-01 211-02 214-01

2. First Normal Form: No Repeating Groups

Tables should have only two dimensions. Since one student has several classes, these classes
should be listed in a separate table. Fields Class1, Class2, and Class3 in the above records
are indications of design trouble.

Spreadsheets often use the third dimension, but tables should not. Another way to look at this
problem is with a one-to-many relationship, do not put the one side and the many side in the
same table. Instead, create another table in first normal form by eliminating the repeating group
(Class#), as shown below:
Student# Advisor Adv-Room Class#

1022 Jones 412 101-07

1022 Jones 412 143-01

1022 Jones 412 159-02

4123 Smith 216 201-01

4123 Smith 216 211-02

4123 Smith 216 214-01

3. Second Normal Form: Eliminate Redundant Data

Note the multiple Class# values for each Student# value in the above table. Class# is not
functionally dependent on Student# (primary key), so this relationship is not in second normal
form.
The following two tables demonstrate second normal form:
Students
Student# Advisor Adv-Room

1022 Jones 412

4123 Smith 216

Registration
Student# Class#

1022 101-07

1022 143-01

1022 159-02

4123 201-01

4123 211-02

4123 214-01

4. Third Normal Form: Eliminate Data Not Dependent On Key

In the last example, Adv-Room (the advisor's office number) is functionally dependent on the
Advisor attribute. The solution is to move that attribute from the Students table to the Faculty
table, as shown below:
Students
Student# Advisor

1022 Jones

4123 Smith

Faculty
Name Room Dept
Jones 412 42

Smith 216 42

You might also like