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

Slides:



Advertisements
Similar presentations
Normalisation.
Advertisements

A Normalisation Example
RJP/RDA 1 /93 Relational Data Analysis (RDA) RDA organises all the system’s data items into a set of well NORMALISED relations. These should avoid: 1.
GCSE Computing#BristolMet Session Objectives# 21 MUST describe methods of validating data as it is input. SHOULD explain the use of key fields to connect.
Normalisation Ensuring data integrity in database design 1.
Athabasca University Under Development for COMP 200 Gary Novokowsky
From Class Diagrams to Databases. So far we have considered “objects” Objects have attributes Objects have operations Attributes are the things you record.
Database Design Conceptual –identify important entities and relationships –determine attribute domains and candidate keys –draw the E-R diagram Logical.
Database Fundamentals Lecture 5. The Design Process continued.
1 NORMALISATION. 2 Introduction Overview Objectives Intro. to Subject Why we normalise 1, 2 & 3 NF Normalisation Process Example Summary.
Chapter 5 Normalization Transparencies © Pearson Education Limited 1995, 2005.
Relational Data Analysis II. Plan Introduction Structured Methods –Data Flow Modelling –Data Modelling –Relational Data Analysis Feasibility Maintenance.
Project and Data Management Software
Normalization.
The Teacher Computing Database Design CP4 Revision.
VCE IT Theory Slideshows
Modelling Techniques - Normalisation Description and exemplification of normalisation.Description and exemplification of normalisation. Creation of un-normalised.
CREATE THE DIFFERENCE Normalisation (special thanks to Janet Francis for this presentation)
Cambridge TEC - Level 3 Certificate/Diploma IT. ICT Dept ScenarioLO1LO2LO3.
Concepts and Terminology Introduction to Database.
Avoiding Database Anomalies
Normalization A technique that organizes data attributes (or fields) such that they are grouped to form stable, flexible and adaptive entities.
A Normalisation Example Mark Kelly McKinnon Secondary College Vceit.com Based on work by Robert Timmer-Arends.
Normalisation Mia’s Sandwich Shop The Process Explained.
1 A Guide to MySQL 2 Database Design Fundamentals.
Deanery of Business & Computer Sciences Transformation of Logical Diagram into Database Design Language Lecture 6 Database Technology Level.
Normalization Transparencies
Switch off your Mobiles Phones or Change Profile to Silent Mode.
CORE 2: Information systems and Databases NORMALISING DATABASES.
MS Access: Creating Relational Databases Instructor: Vicki Weidler Assistant: Joaquin Obieta.
Normalization Information Systems II Ioan Despi. Informal approach Building a database structure : A process of examining the data which is useful & necessary.
1 Information Retrieval and Use Data Analysis & Data Modeling, Relational Data Analysis and Logical Data Modeling Geoff Leese September 2009.
Normal Forms through BCNF CPSC 356 Database Ellen Walker Hiram College (Includes figures from Database Systems by Connolly & Begg, © Addison Wesley 2002)
1 A Guide to MySQL 2 Database Design Fundamentals.
Customer Order Order Number Date Cust ID Last Name First Name State Amount Tax Rate Product 1 ID Product 1 Description Product 1 Quantity Product 2 ID.
CIS 210 Systems Analysis and Development Week 6 Part II Designing Databases,
Unit 4 Object Relational Modeling. Key Concepts Object-Relational Modeling outcomes and process Relational data model Normalization Anomalies Functional.
1 Transforming the Data Model into Relations (Tables) and Normalisation Students.
Lecture 5 Normalization. Objectives The purpose of normalization. How normalization can be used when designing a relational database. The potential problems.
Chapter 10 Normalization Pearson Education © 2009.
ITN Table Normalization1 ITN 170 MySQL Database Programming Lecture 3 :Database Analysis and Design (III) Normalization.
Entity-Relationship (E-R) Diagrams
Programming Logic and Design Fourth Edition, Comprehensive Chapter 16 Using Relational Databases.
Database Design Normalisation. Last Session Looked at: –What databases were –Where they are used –How they are used.
Normalization Data Design - Mr. Ahmad Al-Ghoul
Creating Databases Data normalization. Integrity and Robustness. Work session. Homework: Prepare short presentation on enhancement projects. Continue working.
Chapter 56 Relational Database Design Compiled by Eddie Moorcroft.
Database Terms t DBMS –Database Management System. A software used to organise, analyse, store, retrieve, and edit information. –e.g., Visual FoxPro, Access.
Sample Table Standard Notation Entity name in uppercase
Databases Flat Files & Relational Databases. Learning Objectives Describe flat files and databases. Explain the advantages that using a relational database.
Microsoft Access 2010 Chapter 11 Database Design.
NormalisationNormalisation Normalization is the technique of organizing data elements into records. Normalization is the technique of organizing data elements.
Logical Database Design and Relational Data Model Muhammad Nasir
Normalisation Unit 6: Databases. Just to recap  What is an Entity  What is an Attribute?
Normalisation FORM RULES 1NF 2NF 3NF. What is normalisation of data? The process of Normalisation organises your database to: Reduce or minimise redundant.
Normalisation Worked example for an Order Remember : The data should depend upon the key, the whole key and nothing but the key.
NORMALISATION OF DATABASES. WHAT IS NORMALISATION? Normalisation is used because Databases need to avoid have redundant data, which makes it inefficient.
Relational Databases – Further Study I think we’ve covered all you need to know for GCSE about relational databases I’m not aware of any practical coursework.
Flat file and relational databases Flat file database In a flat file database information is held in a single table. Student IDStudent name GenderDOBCourse.
Database, tables and normal forms
MIS 322 – Enterprise Business Process Analysis
© 2011 Pearson Education, Inc. Publishing as Prentice Hall
Examples of normalization
Entity relationship diagrams
Database Design ERD and Normalisation
Examples of normalization
Database Normalisation
Chengyu Sun California State University, Los Angeles
Chapter 14 Normalization Pearson Education © 2009.
Normalisation 1 Unit 3.1 Dr Gordon Russell, Napier University
Presentation transcript:

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

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.

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

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

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

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.

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.

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

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

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

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.

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

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

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

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

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

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

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

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

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) 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) 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) ORDER (CustomerNumber, Date) FLOWERORDER (OrderNumber, FlowerID, Quantity) 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