Normalisation Example

Mosspark Community College Classlist

This represents a college's record of all the courses it offers - one document for each course.
Students may take several courses, and tutors may be in charge of more than one course.
You will notice that certain data repeats more than once (student no, student name, date of
birth, gender and last attendance date). This is therefore a complex entity, since different
courses will have different numbers of students. The structure needs to be converted into its
simple form.
The structure will be converted in stages - these stages are called Normal Forms.
Here is a summary of the Normal Forms:
Un-Normalised Form (UNF)
First Normal Form (1NF)
Second Normal Form (2NF)
Third Normal Form (3NF)
The 3NF version is the simple version of the structure, which can be implemented in the
database.

----------------------------------------------------------------



Un-Normalised Form (UNF)
list the attributes of the entity
identify the main key (course code) - this must be unique
identify the repeating group of attributes
identify the key from the repeating group
We carry out the process using a special document as shown below.
Note: Keys are denoted by (












Convert to First Normal Form (1NF)
Remove the repeating group of attributes to form a new entity
Add to it the original key
See below for this stage of Normalisation.

We now have two entities linked by the course code key. This means that each student in the
class is represented by an entry in the second table, so now there are no problems with varying
numbers of students.











Convert to Second Normal Form (2NF)
We have solved the problem of the inability to store the document in database tables, but have
introduced a new problem. Examine table two on the previous page. You will note that the
students' details (student no, name, date of birth, gender and last attendance date) are stored in
this table. However if the student enrolled on another course, then the same information would
be stored again in this table. We only need to store a student's details once in our database. This
situation has occurred because some of the non-key attributes in this table are referenced by
part of the table's key - not the whole key. So here is the rule to deal with this problem:
Examine tables with a composite key (a key made up of two parts)
For each non-key attribute, determine if its key is the first part, or the second part, or, if
neither, then the answer is both parts
Remove the partial key and its dependants to form new table
Note that in our example student name, date of birth and gender are referenced by student no,
while last attendance date is referenced by course code and student number (because it is the
date for that student on that particular course).

We now have three tables in our database. Note that the first table is already second normal
form because it only has a single-part key.

Convert to Third Normal Form (3NF)
Sometimes within an entity we can find that there exists a 'key' and 'dependant' relationship
between a group of non-key attributes. In our example on the previous page, it is obvious in
table one that this relationship exists between Tutor Id and Tutor Name. In this case they are
removed to form a new table. If we did not perform the 3NF conversion then the course tutor's
details (in this case, name only) would be repeated each time this tutor's courses were stored.
Here is the process:
Identify any dependencies between non-key attributes in each table
Remove them to form a new table
Promote one of the attributes to be the key of the new table
This becomes the foreign key link in the original table (shown with a *).

Our database is now completed.