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

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

Non-Normalized Student Data Gary Novokowsky, Athabasca University

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

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 343567, COMP 272 and one is associated with the key 444765, COMP 272, different concatenated keys. Gary Novokowsky, Athabasca University

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

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

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

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