1. www.hope.ac.uk Deanery of Business & Computer Sciences Transformation of Logical Diagram into Database Design Language Lecture 6 Database Technology Level I

2. www.hope.ac.uk Deanery of Business & Computer Sciences 2 Aims To introduce the production of Database Design Language (DDL) from a Logical diagram. To introduce referential integrity rules. An overview of Normalisation – First Normal Form (1NF) – Second Normal Form (2NF) – Third Normal Form (3NF)

3. www.hope.ac.uk Deanery of Business & Computer Sciences 3 Database Design Language (DDL) Given an entity, “EntityName” with n attributes, the DDL structure is as follows – EntityName (PrimaryKey(s), attribute 1, attribute 2,…, attribute n ) We can also define foreign keys (FK) as follows with restrictions on operations we can/cant do : – FK ForeignKeyAttributeName →ParentEntityName Update→Cascade or Restrict Delete→Cascade or Restrict

4. www.hope.ac.uk Deanery of Business & Computer Sciences 4 Delete Rules – Applies to parent entity with related child entity instances tblPractice PIDPractice name P122Cherry Tree P144South Street P134Concourse tblPatient NHSNoPSnamePrID NH223ParkinsonP122 NH564ParkinsonP122 NH453DickensonP122 NH455JonesP134 Cascade: Always permits deletion of parent entity instance and deletes all matching instances in the child entity

5. www.hope.ac.uk Deanery of Business & Computer Sciences 5 Delete Cascade tblPractice PIDPractice name P122Cherry Tree P144South Street P134Concourse tblPatient NHSNoPSnamePrID NH223ParkinsonP122 NH564ParkinsonP122 NH453DickensonP122 NH455JonesP134 Delete To Cascade is to “track stages in succession ” Delete rule cascades down to child instances in This case

6. www.hope.ac.uk Deanery of Business & Computer Sciences 6 Delete Rules tblPractice PIDPractice name P134Concourse P144South Street tblPatient NHSNoPSnamePrID NH455JonesP134

7. www.hope.ac.uk Deanery of Business & Computer Sciences 7 Delete Restrict tblPractice PIDPractice name P122Cherry Tree P144South Street P134Concourse tblPatient NHSNoPSnamePrID NH223ParkinsonP122 NH564ParkinsonP122 NH453DickensonP122 NH455JonesP134 Delete You may not delete the practice entity instance only, as there are related records in table tblPatient Restrict: Permits deletion of parent entity instance only if there are no matching child entity instances

8. www.hope.ac.uk Deanery of Business & Computer Sciences 8 Delete Rules tblPractice PIDPractice name P122Cherry Tree P144South Street P134Concourse tblPatient NHSNoPSnamePrID NH223ParkinsonP122 NH564ParkinsonP122 NH453DickensonP122 NH455JonesP134 Delete Restrict: Permits deletion of parent entity “P144, South Street” instance since there are no matching child entity instances with P144

9. www.hope.ac.uk Deanery of Business & Computer Sciences 9 Delete Rules tblPractice PIDPractice name P122Cherry Tree P134Concourse tblPatient NHSNoPSnamePrID NH223ParkinsonP122 NH564ParkinsonP122 NH453DickensonP122 NH455JonesP134

10. www.hope.ac.uk Deanery of Business & Computer Sciences 10 Update Cascade- Applies to parent entity primary key with related child entity instances tblPractice PIDPractice name P122Cherry Tree P144South Street P134Concourse tblPatient NHSNoPSnamePrID NH223ParkinsonP122 NH564ParkinsonP122 NH453DickensonP122 NH455JonesP134 P333 Note: The foreign key in the child is created by migrating the primary Key from the parent entity. Restrict: only allowed if a parent record to be updated doesn’t get child orphans Cascade: Parent to child entities if they exist

11. www.hope.ac.uk Deanery of Business & Computer Sciences 11 Update Restrict tblPractice PIDPractice name P122Cherry Tree P144South Street P134Concourse tblPatient NHSNoPSnamePrID NH223ParkinsonP122 NH564ParkinsonP122 NH453DickensonP122 NH455JonesP134 P333 You may not update only the primary key of a practice entity instance if there are related records in table tblPatient

12. www.hope.ac.uk Deanery of Business & Computer Sciences 12 Logical to Database Design Language DDL (Schema) for Tutor Tutor (tutorID, firstName, surname, address1,address2, postcode, contractType, hourlyRate) firstName surname address1 address2 postcode contractType hourlyRate tutorID Tutor semester classRoom classDay classTime courseCode(fk) tutorID(fk) className Class Note that Sometimes the DDL is called a “schema” ALWAYS UNDERLINE the primary key(s) or Foreign keys

13. www.hope.ac.uk Deanery of Business & Computer Sciences 13 Logical to DDL DDL for Class Class (className, semester, classRoom, classDay,classTime, courseCode, tutorID) FK tutorID→Tutor update cascade delete restrict firstName surname address1 address2 postcode contractType hourlyRate tutorID Tutor semester classRoom classDay classTime courseCode tutorID(FK) className Class

14. www.hope.ac.uk Deanery of Business & Computer Sciences 14 Cumulative Design Student(studentID, sFirstName, sSurname, sAdd1, sAdd2, sAdd3, sPostcode, sTelephone, lastApplicationDate) Course (courseCode, title, cost) Tutor (tutorID, firstName, surname, address1, address2, postcode, contractType, hourlyRate) Class (className, semester, classroom, classDay, classTime, courseCode, tutorID) FK tutorID→Tutor Update Cascade, Delete Restrict FK courseCode→course Update Cascade, Delete Restrict StudentCourse (studentID, courseCode) FK studentID→Student Update Cascade, Delete Restrict FK courseCode→course Update Cascade, Delete Restrict StudentClass (StudentID, className) FK studentID→Student Update Cascade, Delete Restrict FK className→ Class Update Cascade, Delete Restrict

15. www.hope.ac.uk Deanery of Business & Computer Sciences 15 Normalisation What is normalisation? Normalisation is – a set of criteria – Each criteria is a rule for designing entities

16. www.hope.ac.uk Deanery of Business & Computer Sciences 16 Normalisation Why normalisation? Normalisation helps us to – improve the quality of entities – produce entities that have as little redundancy as possible – accommodate multiple values for types of data that require them – permit efficient updates of the data in the database – avoid the danger of losing data unknowingly

17. www.hope.ac.uk Deanery of Business & Computer Sciences 17 Normalisation How we use it in this course! We will use the normalisation rules up to third normal form.

18. www.hope.ac.uk Deanery of Business & Computer Sciences 18 First Normal Form (1NF) Definition of INF: Take an unnormalised relation and remove any repeating group to form a new entity, combining the original primary key with the primary key in the repeating group to form a new compound primary key.

19. www.hope.ac.uk Deanery of Business & Computer Sciences 19 First Normal form (1NF) You will need to check that each attribute will only need to hold one value, if more than one value is needed the entity is not in first normal form.

20. www.hope.ac.uk Deanery of Business & Computer Sciences 20 Example We record for the Medical Staff all the procedures they are qualified to carry out MedicalStaff MedStaffID MSFName MSSName MSAdd MSType MSProcedureID MSProcedure DeptID DeptName Database Design Language MedStaff (MedStaffID, MSFName, MSSName, MSAdd, MSType, MSProcedureID, MSProcedure, DeptID, DeptName)

21. www.hope.ac.uk Deanery of Business & Computer Sciences 21 Example Database Design Language ONF MedicalStaff (MedStaffID, MSFName, MSSName,MSAdd, MSType, DeptID, DeptName, (MSProcedureID, MSProcedure)) The entity is split into two separate entities. Both of which are in first normal form. Foreign Keys will be dealt with later. INF MedicalStaff (MedStaffID, MSFName, MSSName, MSAdd, MSType, DeptID, Deptname) StaffProcedure (MedStaffID, MSProcedureID, MSProcedure)

22. www.hope.ac.uk Deanery of Business & Computer Sciences 22 Second Normal Form (2NF) Definition of 2NF: "ensure that all non-key attributes are fully dependent on the whole of the primary key" i.e. remove all partial dependencies through the creation of new tables where there was a compound key.

23. www.hope.ac.uk Deanery of Business & Computer Sciences 23 Second Normal Form (2NF) Any entity with a single primary key is automatically second normal form. We apply the rule to any entity with a compound key.

24. www.hope.ac.uk Deanery of Business & Computer Sciences 24 Second Normal Form (2NF) Entities in first Normal Form MedicalStaff (MedStaffID, MSFName, MSSName, MSAdd, MSType, DeptID, DeptName) MedicalStaff is automatically 2NF as it has a single primary key. StaffProcedure (MedStaffID, ProcedureID, MSProcedure) StaffProcedure may not be in 2NF as it has a compound key and needs to be checked.

25. www.hope.ac.uk Deanery of Business & Computer Sciences 25 Second Normal Form Entities in first Normal Form MedicalStaff (MedStaffID, MSFName, MSSName, MSAdd, MSType, DeptID, DeptName) StaffProcedure (MedStaffID, ProcedureID, MSProcedure) The StaffProcedure entity is split into two separate entities. Both of which are in second normal form. 2NF MedicalStaff (MedStaffID, MSFName, MSSName, MSAdd, MSType, DeptID, DeptName) StaffProcedure (MedStaffID, ProcedureID) Procedure (ProcedureID, MSProcedure)

26. www.hope.ac.uk Deanery of Business & Computer Sciences 26 Third Normal Form Definition of 3NF: "ensure that all non-key attributes are mutually independent apart from candidate attributes" i.e. remove the dependencies between the non-key attributes through the creation of new tables.

27. www.hope.ac.uk Deanery of Business & Computer Sciences 27 Third Normal Form (3NF) An entity with no non key attributes is automatically in third normal form. An entity with only one non key attribute is automatically in third normal form.

28. www.hope.ac.uk Deanery of Business & Computer Sciences 28 Third Normal Form Entities in second Normal Form MedicalStaff (MedStaffID, MSFName, MSSName, MSAdd, MSType, DeptID, DeptName) StaffProcedure (MedStaffID, ProcedureID) Procedure (ProcedureID, MSProcedure) Medical Staff has more than one non key field so we must consider it against the rule for 3NF. StaffProcedure has no non key fields so is in 3NF. Procedure has one non key field so is in 3NF.

29. www.hope.ac.uk Deanery of Business & Computer Sciences 29 Third Normal Form Entities in second Normal Form MedicalStaff (MedStaffID, MSFName, MSSName, MSAdd, MSType, DeptID, DeptName) StaffProcedure (MedStaffID, ProcedureID) Procedure (ProcedureID, MSProcedure) In MedicalStaff there is a dependency between DeptID and DeptName therefore MedicalStaff is not in 3NF. DeptID DeptName

30. www.hope.ac.uk Deanery of Business & Computer Sciences 30 Third Normal Form Entities in third Normal Form MedicalStaff (MedStaffID, MSFName, MSSName, MSAdd, MSType, DeptID) Department (DeptID, DeptName) StaffProcedure (MedStaffID, ProcedureID) Procedure (ProcedureID, MSProcedure) We must now deal with the foreign keys in the relations.

31. www.hope.ac.uk Deanery of Business & Computer Sciences 31 Entities in Third Normal Form Department (DeptID, DeptName) MedicalStaff (MedStaffID, MSFName, MSSName, MSAdd, MSType, DeptID) FK DeptID → Department Update Cascade, Delete Restrict Procedure (ProcedureID, MSProcedure) StaffProcedure (MedStaffID, ProcedureID) FK MedStaffID → MedicalStaff Update Cascade, Delete Restrict FK ProcedureID → Procedure Update Cascade, Delete Restrict

32. www.hope.ac.uk Deanery of Business & Computer Sciences 32 Summary Introduction to Database design language. Use of update and delete rules Normalisation – First normal form – Second normal form – Third normal form Specification of Foreign keys in DDL

33. www.hope.ac.uk Deanery of Business & Computer Sciences 33 NEXT WEEK Noun identification table Conceptual E-R Diagram Conceptual Diagram script Business Rules Operations Logical model Database Design Language Normalisation.