Database Normalisation Databases Database Normalisation

Learning Objectives Design simple relational databases to the third normal form (3NF).

Database Normalization A technique for designing relational database tables to minimize duplication of information which can lead to inconsistencies, leading to a loss of data integrity.

Example of Database Normalisation

Example Database A database is designed to store data about students at a college and the subjects that they study. All students are based in a tutor group A tutor supervises all the students in their tutor group, can only be a tutor of one form and a form has only one tutor Each subject has one subject teacher only Students study a number of subjects

Un-Normalised Form (UNF) A relation with repeating groups (fields which are duplicated an unknown number of times) which have their own primary keys. (i.e. many to many relationships) The next table is in un-normalised form.

Table: StudentSubject StudentID Student Name Tutor SubjectID Subject Level Teacher Grade 0001 Tom SAN PHYA2 CHEA2 GENAS Physics Chemistry Gen. Studies A AS MEB DIL B E 0002 Joe GEOAS FREAS Geography French ROG HEN C 0003 Samir COMA2 MATA2 GENA2 Computing Maths VAR COR D A* Repeating groups Un-Normalised Form (UNF): The table has rows/records/tuples which contain a repeated group of attributes (which have their own primary keys, in this case -SubjectID) that represent the subjects each student studies. Underlined field is the primary key.

UNF Table description / shorthand notation / design: Table: StudentSubjects (StudentID, StudentName, TutorGroup, Tutor, (SubjectID, Subject, Level,SubjectTeacher, Grade)) The words in brackets separated by a , = Fields / Columns / Attributes Underlined Field = Primary Key Inner brackets = Repeating group (many to many relationships) Some websites / books also underline the primary key of the repeating group e.g. the SubjectID in this case. I will not here as it is I believe it is confusing when thinking about 1NF – see next slides. Subject Student studied by study

First Normal Form (1NF) Remove repeating groups (and their primary keys). Expand the primary key to include the unique key of the repeating group (concatenated / combination / compound primary key).

Table: StudentSubject StudentID SubjectID Student Name Tutor Group Subject Level Teacher Grade 0001 PHYA2 Tom 6 SAN Physics A CHEA2 Chemistry MEB B GENAS Gen. Studies AS DIL E 0002 GEOAS Joe 7 Geography ROG C FREAS French HEN 0003 COMA2 Samir Computing VAR D MATA2 Maths COR GENA2 A* First Normal Form (1NF): Repeating groups have been removed and the primary key has now been expanded to include SubjectID (StudentID + SubjectID = StudentID/SubjectID), therefore the primary key no longer repeats. I have placed these 2 fields side by side but this is not necessary, I have only done this to make it easier to see the new primary key.

1NF Table description / shorthand notation / design: Table: StudentSubject (StudentID, StudentName, TutorGroup, Tutor, SubjectID, Subjects, Level, SubjectTeacher, Grade) Primary key = StudentID + SubjectID = StudentID/SubjectID Note the fields used for the combined primary key do not have to be shown together, just underlined. This is why I did not underline before in UNF but even if you did, the inner brackets show the group repetition in UNF and they are no longer in the notation above for 1NF.

Table: Student Table: Subject StudentID/ SubjectID StudentID/ You can also move the repeating group attributes into a new table at this stage. StudentID Student Name Tutor Group 0001 Tom 6 SAN 0002 Joe 7 MEB 0003 Samir Table: Student (StudentID, StudentName, TutorGroup, Tutor) Table: Subject (StudentID, SubjectID, Subject, Level, SubjectTeacher, Grade) Dashed underline indicates a Foreign key (a non-primary key in one table which is the primary key of another table). Table: Subject StudentID SubjectID Subject Level Teacher Grade 0001 PHYA2 Physics A SAN CHEA2 Chemistry MEB B GENAS Gen. Studies AS DIL E 0002 GEOAS Geography ROG C FREAS French HEN 0003 COMA2 Computing VAR D MATA2 Maths COR GENA2 A* There is a one-to-many relationship with Student being the ‘one side’ table and Subject being the ‘many side‘ table. The primary key StudentID in the Student table links to the foreign key StudentID in the Subject table. studies studies StudentID/ SubjectID StudentID/ SubjectID Subject Student studied by studied by

2NF Definition A relation that is in 1NF and every non-primary key attribute is fully dependent on the primary key (no partial dependencies are allowed). Do any of the fields in the table depend on only a portion of the primary key? Yes = Not 2NF No = 2NF

Not in 2NF because: StudentID SubjectID Student Name Tutor Group Subject, Level, SubjectTeacher depend on the SubjectID but not on the StudentID, and, StudentName, TutorGroup, Tutor depend on the StudentID but not on the SubjectID. Only the Grade depends on the entire concatenated / combination primary key (StudentID + SubjectID). StudentID SubjectID Student Name Tutor Group Subject Level Teacher Grade 0001 PHYA2 Tom 6 SAN Physics A CHEA2 Chemistry MEB B GENAS Gen. Studies AS DIL E 0002 GEOAS Joe 7 Geography ROG C FREAS French HEN 0003 COMA2 Samir Computing VAR D MATA2 Maths COR GENA2 A*

To convert a table to 2NF, you must: Duplicate each portion of the concatenated / combination primary key into another table and move any fields that depend wholly on the duplicated portion into this table. Leaving the concatenated / combination primary key and any fields that wholly depend on it, in the original table; also identify each portion as a foreign key. In this case: SubjectID, Subject, Level & SubjectTeacher. StudentID, StudentName, TutorGroup & Tutor. duplicated moved StudentID SubjectID Student Name Tutor Group Subject Level Teacher Grade 0001 PHYA2 Tom 6 SAN Physics A CHEA2 Chemistry MEB B GENAS Gen. Studies AS DIL E 0002 GEOAS Joe 7 Geography ROG C FREAS French HEN 0003 COMA2 Samir Computing VAR D MATA2 Maths COR GENA2 A*

2NF Table: Grade Table: Student Table: Subject StudentID SubjectID Grade 0001 PHYA2 A CHEA2 B GENAS E 0002 GEOAS C FREAS 0003 COMA2 D MATA2 GENA2 A* StudentID Student Name Tutor Group 0001 Tom 6 SAN 0002 Joe 7 MEB 0003 Samir Dashed underline indicates a Foreign key (a non-primary key in one table which is the primary key of another table). All fields are fully dependent on the entire primary key of their respective tables. Table: Subject SubjectID Subject Level Teacher PHYA2 Physics A SAN CHEA2 Chemistry MEB GENAS Gen. Studies AS DIL GEOAS Geography ROG FREAS French HEN COMA2 Computing VAR CHEAS MATA2 Maths COR GENA2 There is a one-to-many relationship with Student being the ‘one side’ table and Grade being the ‘many side‘ table. The primary key StudentID in the Student table links to the foreign key StudentID in the Grade table (similarly for SubjectID in the Student & Grade tables). given awarded achieves SubjectID/ Grade StudentID/ Grade Subject Grade Student shows achieved by

SubjectID/ Grade Subject Grade Subject Grade Entity / Table Link given SubjectID/ Grade Subject Grade shows Entity / Table Link Entity / Table Note that SubjectID/Grade is not a table/entity, it is just a way of showing how the tables/entities Subject and Grade are linked. It is also possible to show only the tables and assume there is a link (the primary key - SubjectID - from Subject is duplicated in Grade and is known as the foreign key in Grade). Due to the primary key of Grade now being StudentID/SubjectID, there are now many SubjectIDs in Subject to one StudentID/SubjectID in Grade. The table without a combination primary key forms (in this case Subject) the many side and the table with a combination primary key (in this case Student) forms the one side. given Subject Grade shows

StudentID/ Grade Grade Student Grade Student Entity / Table given StudentID/ Grade Grade Student shows Entity / Table Entity / Table Link Note that StudentID/Grade is not a table/entity, it is just a way of showing how the tables/entities Grade and Student are linked. It is also possible to show only the tables and assume there is a link (the primary key - StudentID - from Student is duplicated in Grade and is known as the foreign key in Grade). Due to the primary key of Grade now being StudentID/SubjectID, there are now many StudentIDs in Student to one StudentID/SubjectID in Grade. The table with a combination primary key (in this case Grade) forms the one side and the table without a combination primary key forms (in this case Student) the many side. given Grade Student shows

2NF Table description / shorthand notation / design: Table: Student (StudentID, StudentName, TutorGroup, Tutor) Table: Subject (SubjectID, Subject, Level, SubjectTeacher) Table: Grade (SubjectID, StudentID, Grade) given awarded achieves SubjectID/ Grade StudentID/ Grade Subject Grade Student shows achieved by

3NF Definition A relation that is in 1NF and 2NF, and if no non-key field is dependent on another non-key field (i.e. no one to one relationships).

Table: Student Student TutorGroup Tutor Table Student is not in 3NF because: TutorGroup is dependent on Tutor and Tutor is dependent on TutorGroup. Table: Student StudentID Student Name Tutor Group 0001 Tom 6 SAN 0002 Joe 7 MEB 0003 Samir Student TutorGroup Tutor To convert the table to 3NF, you must: Duplicate one of the non-key fields that depends on another non-key field into another table and move all other non-key fields that depend on another non-key field into this table (in this case: duplicate TutorGroup & move Tutor). Use the duplicated field as the primary key of the new table and as a foreign key in the original table.

Tables: Subject & Grade were already in 3NF. Table: Student 3NF Dashed underline indicates a Foreign key (a non-primary key in one table which is the primary key of another table). StudentID Student Name Tutor Group 0001 Tom 6 0002 Joe 7 0003 Samir Table: Grade StudentID SubjectID Grade 0001 PHYA2 A CHEA2 B GENAS E 0002 GEOAS C FREAS 0003 COMA2 D MATA2 GENA2 A* Table: Subject SubjectID Subject Level Teacher PHYA2 Physics A SAN CHEA2 Chemistry MEB GENAS Gen. Studies AS DIL GEOAS Geography ROG FREAS French HEN COMA2 Computing VAR CHEAS MATA2 Maths COR GENA2 Table: Tutor Tutor Group 6 SAN 7 MEB Tables: Subject & Grade were already in 3NF. Third Normal Form (3NF): Each table relates to only 1 entity, has only 1 primary key and there are no repeating non-key fields.

3NF Table description / shorthand notation / design: Table: Student (StudentID, StudentName, TutorGroup) Dashed underline indicates a Foreign key (a non-primary key in one table which is the primary key of another table). Table: Tutor (TutorGroup, Tutor) Table: Subject (SubjectID, Subject, Level, SubjectTeacher) Table: Grade (SubjectID, StudentID, Grade) Student Tutor_TutorGroup

Normalisation Summary UNF The table has rows which contain repeated groups of attributes (which have their own primary keys). 1NF Remove repeating groups (and their primary keys). Expand the primary key to include the unique key of the repeating group (concatenated / combination primary key). 2NF Duplicate each portion of the concatenated / combination primary key into another table and move any fields that depend wholly on the duplicated portion into this table. Leaving the concatenated / combination primary key and any fields that wholly depend on it, in the original table; also identify each portion as a foreign key. 3NF Duplicate one of the non-key fields that depends on another non-key field into another table and move all other non-key fields that depend on another non-key field into this table (in this case: duplicate TutorGroup & move Tutor). Use the duplicated as the primary key of the new table and as a foreign key in the original table.

Plenary When a customer orders flowers, an order form has to be completed. The order form is shown on the next slide.

CUSTOMER ORDER Order Number: Date: / / Customer Number: QUANTITY FLOWER ID

Plenary Create a table in UNF, called ORDER, which contains all the attributes shown on the order form. Explain why it is not normalised.

Plenary ORDER (OrderNumber, CustomerNumber, Date, (Quantity), (FlowerID)) ORDER is not normalised as it is has repeating groups.

Plenary Show this data model in 1NF, 2NF and finally 3NF.

Plenary Remove the repeating groups to obtain 1NF. ORDER (OrderNumber, CustomerNumber, Date, Quantity, FlowerID)

Plenary CustomerNumber and Date are not dependent on FlowerID so remove them to another table to obtain 2NF. ORDER (CustomerNumber, Date) FLOWERORDER (OrderNumber, FlowerID, Quantity) This is also in 3NF.

Plenary The owner of a flower shop uses a relational database to store information about orders placed by customers, and the types of flower in stock. One entity is defined as CUSTOMERS. List the attributes which you identify as belonging to this entity.

Plenary Forename, Surname Address1, Address2, County Postcode Date of last order Credit limit