Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations


Presentation on theme: "Databases Database Normalisation. Learning Objectives Design simple relational databases to the third normal form (3NF)."— Presentation transcript:

1 Databases Database Normalisation

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

3 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.

4 Example of Database Normalisation

5 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 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 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 Each subject has one subject teacher only Students study a number of subjects Students study a number of subjects

6 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) (i.e. many to many relationships) The next table is in un-normalised form.

7 Table: StudentSubject StudentIDStudent Name TutorSubjectIDSubjectLevelSubject Teacher Grade 0001TomSANPHYA2 CHEA2 GENAS Physics Chemistry Gen. Studies A AS SAN MEB DIL ABEABE 0002JoeMEBGEOAS FREAS Geography French AS ROG HEN CBCB 0003SamirSANCOMA2 CHEA2 MATA2 GENA2 Computing Chemistry Maths Gen. Studies AAAAAAAA VAR MEB COR DIL D C B A* 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. Repeating groups

8 UNF Table description / shorthand notation / design: Table: StudentSubjects (StudentID, StudentName, TutorGroup, Tutor, ( SubjectID, Subject, Level,SubjectTeacher, Grade ) ) Tutor, ( SubjectID, Subject, Level,SubjectTeacher, Grade ) ) The words in brackets separated by a, = Fields / Columns / Attributes The words in brackets separated by a, = Fields / Columns / Attributes Underlined Field = Primary Key Underlined Field = Primary Key Inner brackets = Repeating group (many to many relationships) 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. 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. StudentSubject studied by study

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

10 Table: StudentSubject StudentIDSubjectIDStudent Name Tutor Group TutorSubjectLevelSubject Teacher Grade 0001PHYA2Tom6SANPhysicsASANA 0001CHEA2Tom6SANChemistryAMEBB 0001GENASTom6SANGen. StudiesASDILE 0002GEOASJoe7MEBGeographyASROGC 0002FREASJoe7MEBFrenchASHENB 0003COMA2Samir6SANComputingAVARD 0003CHEA2Samir6SANChemistryAMEBB 0003MATA2Samir6SANMathsACORC 0003GENA2Samir6SANGen. StudiesADILA* 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.

11 1NF Table description / shorthand notation / design: Table: StudentSubject (StudentID, StudentName, TutorGroup, Tutor, SubjectID, Subjects, Level, SubjectTeacher, Grade) Tutor, SubjectID, Subjects, Level, SubjectTeacher, Grade) Primary key = StudentID + SubjectID = StudentID/SubjectID 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.

12 You can also move the repeating group attributes into a new table at this stage. Table: Student Table: Subject StudentIDStudent Name Tutor Group Tutor 0001Tom6SAN 0002Joe7MEB 0003Samir6SAN StudentIDSubjectIDSubjectLevelSubject Teacher Grade 0001PHYA2PhysicsASANA 0001CHEA2ChemistryAMEBB 0001GENASGen. StudiesASDILE 0002GEOASGeographyASROGC 0002FREASFrenchASHENB 0003COMA2ComputingAVARD 0003CHEA2ChemistryAMEBB 0003MATA2MathsACORC 0003GENA2Gen. StudiesADILA* Student Subject StudentID/ SubjectID studied by studies StudentID/ SubjectID studied by studies Table: Student (StudentID, StudentName, TutorGroup, Tutor) TutorGroup, Tutor) Table: Subject (StudentID, SubjectID, Subject, Level, SubjectTeacher, Grade) Level, SubjectTeacher, Grade) 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. Dashed underline indicates a Foreign key (a non-primary key in one table which is the primary key of another table).

13 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 Yes = Not 2NF No = 2NF No = 2NF

14 StudentIDSubjectIDStudent Name Tutor Group TutorSubjectLevelSubject Teacher Grade 0001PHYA2Tom6SANPhysicsASANA 0001CHEA2Tom6SANChemistryAMEBB 0001GENASTom6SANGen. StudiesASDILE 0002GEOASJoe7MEBGeographyASROGC 0002FREASJoe7MEBFrenchASHENB 0003COMA2Samir6SANComputingAVARD 0003CHEA2Samir6SANChemistryAMEBB 0003MATA2Samir6SANMathsACORC 0003GENA2Samir6SANGen. StudiesADILA* Not in 2NF because: 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 ).

15 To convert a table to 2NF, you must: StudentIDSubjectIDStudent Name Tutor Group TutorSubjectLevelSubject Teacher Grade 0001PHYA2Tom6SANPhysicsASANA 0001CHEA2Tom6SANChemistryAMEBB 0001GENASTom6SANGen. StudiesASDILE 0002GEOASJoe7MEBGeographyASROGC 0002FREASJoe7MEBFrenchASHENB 0003COMA2Samir6SANComputingAVARD 0003CHEA2Samir6SANChemistryAMEBB 0003MATA2Samir6SANMathsACORC 0003GENA2Samir6SANGen. StudiesADILA* duplicatedmoved 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.

16 2NF All fields are fully dependent on the entire primary key of their respective tables. StudentIDSubjectIDGrade 0001PHYA2A 0001CHEA2B 0001GENASE 0002GEOASC 0002FREASB 0003COMA2D 0003CHEA2B 0003MATA2C 0003GENA2A* SubjectIDSubjectLevelSubject Teacher PHYA2PhysicsASAN CHEA2ChemistryAMEB GENASGen. StudiesASDIL GEOASGeographyASROG FREASFrenchASHEN COMA2ComputingAVAR CHEASChemistryASMEB MATA2MathsACOR GENA2Gen. StudiesADIL Table: Subject Table: Grade 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 ). StudentIDStudent Name Tutor Group Tutor 0001Tom6SAN 0002Joe7MEB 0003Samir6SAN Table: Student Student Subject SubjectID/ Grade shows given Grade achieves achieved by StudentID/ Grade awarded Dashed underline indicates a Foreign key (a non-primary key in one table which is the primary key of another table).

17 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 SubjectID s 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. Grade Subject SubjectID/ Grade given Entity / Table Link shows Grade given Subject shows

18 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 StudentID s 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. StudentGrade StudentID/ Grade given Entity / Table Link shows Student given Grade shows

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

20 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). (i.e. no one to one relationships).

21 StudentIDStudent Name Tutor Group Tutor 0001Tom6SAN 0002Joe7MEB 0003Samir6SAN Table Student is not in 3NF because: TutorGroup is dependent on Tutor and Tutor is dependent on TutorGroup. Table: Student To convert the table to 3NF, you must: 1.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 ). 2.Use the duplicated field as the primary key of the new table and as a foreign key in the original table. TutorGroupTutor Student

22 3NF StudentIDStudent Name Tutor Group 0001Tom6 0002Joe7 0003Samir6 Third Normal Form (3NF): Each table relates to only 1 entity, has only 1 primary key and there are no repeating non-key fields. StudentIDSubjectIDGrade 0001PHYA2A 0001CHEA2B 0001GENASE 0002GEOASC 0002FREASB 0003COMA2D 0003CHEA2B 0003MATA2C 0003GENA2A* SubjectIDSubjectLevelSubject Teacher PHYA2PhysicsASAN CHEA2ChemistryAMEB GENASGen. StudiesASDIL GEOASGeographyASROG FREASFrenchASHEN COMA2ComputingAVAR CHEASChemistryASMEB MATA2MathsACOR GENA2Gen. StudiesADIL Table: Student Table: Subject Table: Grade Tables: Subject & Grade were already in 3NF. Tutor Group Tutor 6SAN 7MEB Table: Tutor Dashed underline indicates a Foreign key (a non-primary key in one table which is the primary key of another table).

23 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). 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) Tutor_TutorGroup Student

24 Normalisation Summary UNF The table has rows which contain repeated groups of attributes (which have their own primary keys). 1NF 1.Remove repeating groups (and their primary keys). 2.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 1. 1.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). 2. 2.Use the duplicated as the primary key of the new table and as a foreign key in the original table.

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

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

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

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

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

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

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

32 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.

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


Download ppt "Databases Database Normalisation. Learning Objectives Design simple relational databases to the third normal form (3NF)."

Similar presentations


Ads by Google