1. Athabasca University Under Development for COMP 200 Gary Novokowsky
Data Normalization
Athabasca University
Under Development for COMP 200
Gary Novokowsky
Gary Novokowsky, Athabasca University

2. Gary Novokowsky, Athabasca University
Non-Normalized Data
Contains duplicate non-key items
Notice how the table on the next slide (broken to fit on a slide), contains duplicate data in almost every single column of the table.
Gary Novokowsky, Athabasca University

3. Non-Normalized Student Data
Gary Novokowsky, Athabasca University

4. Gary Novokowsky, Athabasca University
1NF – First Normal Form
First remove repeated fields.
Accomplish this by breaking the original table into two separate tables.
Note how the first table on the following page has the repeating fields removed.
The second table has a concatenated key. Although items repeat in the first two columns, they never repeat when combined. Even though they are two separate columns, you may think of them as a single column because when combined they form a single, unique key.
Although the Course Name field contains repeating fields notice how it is never associated with the same key. This is because the concatenated (or combined) key is unique for each row that contains duplicate data in the Course Name field.
Gary Novokowsky, Athabasca University

5. Gary Novokowsky, Athabasca University
1NF – First Normal Form
Key = STUDENT ID #
Both STUDENT ID # and COURSE # are foreign
keys and together form a concatenated key
Although “Data Structures” is repeated in the Course Name column, one instance is associated with the key , COMP 272 and one is associated with the key , COMP 272, different concatenated keys.
Gary Novokowsky, Athabasca University

6. Gary Novokowsky, Athabasca University
2NF – Second Normal Form
Ensure all non-key attributes (data items), are identified by the full key. I.E., there should be no components in a concatenated key that are not required to uniquely identify the data items.
The Course table from the previous slide contains a Course # field which identifies the Course Name, but Course Name does not require the Student # part of the concatenated key for identification.
We now split the Course table into two tables (Course table and Grade table) to arrive at 2NF as shown in the next slide.
Gary Novokowsky, Athabasca University

7. Gary Novokowsky, Athabasca University
2NF – Second Normal Form
Grades has a concatenated key
made up of two foreign keys.
Course # remains the key for this table.
Gary Novokowsky, Athabasca University

8. Gary Novokowsky, Athabasca University
3NF – Third Normal Form
Ensure all non-key attributes (data items), are independent of other non-key attributes in the table.
An examination of our tables shows this is a problem in the Student-Programme table because the Programme Name and Programme Description fields are dependent on Programme # field.
Resolve this issue by splitting the first table into two tables – the Student table and the Programme table.
Note how the key field from the Programme table, Programme #, must remain as part of the Student table in order to form a link between the two tables. If this field were to be left out there would be no relationship between the Programme table and the rest of the database tables.
Gary Novokowsky, Athabasca University

9. Gary Novokowsky, Athabasca University
3NF – Third Normal Form
Gary Novokowsky, Athabasca University