Scribd
Upload
126 views

A Normalisation Example: Mark Kelly Mckinnon Secondary College Based On Work by Robert Timmer-Arends

The document describes the process of normalizing a student database table to satisfy 1st, 2nd, and 3rd normal form requirements. It starts with a table that has repeating groups and is not in 1st normal form. It is split into multiple tables with composite primary keys to satisfy 1st and 2nd normal form. However, some fields depend on more than just the primary key, so it does not satisfy 3rd normal form. Another table is split off to finally satisfy all three normal forms.

Uploaded by

Desyerie Bonifacio
Copyright
© © All Rights Reserved
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
126 views

A Normalisation Example: Mark Kelly Mckinnon Secondary College Based On Work by Robert Timmer-Arends

The document describes the process of normalizing a student database table to satisfy 1st, 2nd, and 3rd normal form requirements. It starts with a table that has repeating groups and is not in 1st normal form. It is split into multiple tables with composite primary keys to satisfy 1st and 2nd normal form. However, some fields depend on more than just the primary key, so it does not satisfy 3rd normal form. Another table is split off to finally satisfy all three normal forms.

Uploaded by

Desyerie Bonifacio
Copyright
© © All Rights Reserved
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 36

A Normalisation Example

Mark Kelly
McKinnon Secondary College
Vceit.com
Based on work by Robert Timmer-Arends
Thanks
This example is based on Relational
Databases a simplified account by Robert
Timmer-Arends
Take the following table.

StudentID is the primary key.
Is it 1NF?
No. There are repeating groups (subject,
subjectcost, grade)
How can you make it 1NF?
Create new rows so each cell contains only
one value
But now look is the studentID primary
key still valid?
No the studentID no longer uniquely
identifies each row
You now need to declare studentID and subject
together to uniquely identify each row.

So the new key is StudentID and Subject.
So. We now have 1NF.
Is it 2NF?
Studentname and address are dependent
on studentID (which is part of the key)
This is good.
But they are not dependent on
Subject (the other part of the
key)
And 2NF requires
All non-key fields are
dependent on the ENTIRE
key (studentID + subject)
So its not 2NF
How can we fix it?
Make new tables
Make a new table for each primary key field
Give each new table its own primary key
Move columns from the original table to the
new table that matches their primary key
Step 1
STUDENT TABLE (key = StudentID)
Step 2
STUDENT TABLE (key = StudentID)
SUBJECTS TABLE (key = Subject)
Step 3
STUDENT TABLE (key = StudentID)
SUBJECTS TABLE (key = Subject)
RESULTS TABLE (key = StudentID+Subject)
Step 3
STUDENT TABLE (key = StudentID)
SUBJECTS TABLE (key = Subject)
RESULTS TABLE (key = StudentID+Subject)
Step 4 - relationships
STUDENT TABLE (key = StudentID)
SUBJECTS TABLE (key = Subject)
RESULTS TABLE (key = StudentID+Subject)
Step 4 - cardinality
STUDENT TABLE (key = StudentID)
SUBJECTS TABLE (key = Subject)
RESULTS TABLE (key = StudentID+Subject)
1
Each student can only appear
ONCE in the student table
Step 4 - cardinality
STUDENT TABLE (key = StudentID)
SUBJECTS TABLE (key = Subject)
RESULTS TABLE (key = StudentID+Subject)
1
1
Each subject can only appear
ONCE in the subjects table
Step 4 - cardinality
STUDENT TABLE (key = StudentID)
SUBJECTS TABLE (key = Subject)
RESULTS TABLE (key = StudentID+Subject)
1
1
8

A subject can be listed MANY
times in the results table (for
different students)
Step 4 - cardinality
STUDENT TABLE (key = StudentID)
SUBJECTS TABLE (key = Subject)
RESULTS TABLE (key = StudentID+Subject)
1
1
8

8

A student can be listed MANY
times in the results table (for
different subjects)
A 2NF check
STUDENT TABLE (key = StudentID)
SUBJECTS TABLE (key = Subject)
RESULTS TABLE (key = StudentID+Subject)
1
1
8

8

SubjectCost is only
dependent on the
primary key,
Subject
A 2NF check
STUDENT TABLE (key = StudentID)
SUBJECTS TABLE (key = Subject)
RESULTS TABLE (key = StudentID+Subject)
1
1
8

8

Grade is only dependent
on the primary key
(studentID + subject)
A 2NF check
STUDENT TABLE (key = StudentID)
SUBJECTS TABLE (key = Subject)
RESULTS TABLE (key = StudentID+Subject)
1
1
8

8

Name, Address are only
dependent on the
primary key
(StudentID)
But is it 3NF?
STUDENT TABLE (key = StudentID)
SUBJECTS TABLE (key = Subject)
RESULTS TABLE (key = StudentID+Subject)
1
1
8

8

So it is
2NF!
A 3NF check
STUDENT TABLE (key = StudentID)
SUBJECTS TABLE (key = Subject)
RESULTS TABLE (key = StudentID+Subject)
1
1
8

8

Oh oh
What?
A 3NF check
STUDENT TABLE (key = StudentID)
SUBJECTS TABLE (key = Subject)
RESULTS TABLE (key = StudentID+Subject)
1
1
8

8

HouseName is
dependent on both
StudentID +
HouseColour
A 3NF check
STUDENT TABLE (key = StudentID)
SUBJECTS TABLE (key = Subject)
RESULTS TABLE (key = StudentID+Subject)
1
1
8

8

Or HouseColour is
dependent on both
StudentID +
HouseName
A 3NF check
STUDENT TABLE (key = StudentID)
SUBJECTS TABLE (key = Subject)
RESULTS TABLE (key = StudentID+Subject)
1
1
8

8

But either way,
non-key fields are
dependent on MORE
THAN THE PRIMARY
KEY (studentID)
A 3NF check
STUDENT TABLE (key = StudentID)
SUBJECTS TABLE (key = Subject)
RESULTS TABLE (key = StudentID+Subject)
1
1
8

8

And 3NF says that
non-key fields must
depend on nothing
but the key
A 3NF check
STUDENT TABLE (key = StudentID)
SUBJECTS TABLE (key = Subject)
RESULTS TABLE (key = StudentID+Subject)
1
1
8

8

WHAT DO
WE DO?
Again, carve off the offending fields
SUBJECTS TABLE (key = Subject)
RESULTS TABLE (key = StudentID+Subject)
1
1
8

8

A 3NF fix
SUBJECTS TABLE (key = Subject)
RESULTS TABLE (key = StudentID+Subject)
1
1
8

8

A 3NF fix
SUBJECTS TABLE (key = Subject)
RESULTS TABLE (key = StudentID+Subject)
1
1
8

8

1
8

A 3NF win!
SUBJECTS TABLE (key = Subject)
RESULTS TABLE (key =
StudentID+Subject)
1
1
8

8

1
8

Or
The Reveal
Before
After
RESULTS TABLE (key = StudentID+Subject)
1
1
8

8

1
8

SUBJECTS TABLE (key = Subject)
The end
Thanks to Robert Timmer-Arends for the
scenario and staging of the normalisation

Mark Kelly
Vceit.com

You might also like