1. Lecture 7 Enhanced Entity-Relationship Modelling & Advanced Normalisation

2. 2 Lecture 7 – Part 1 Enhanced Entity-Relationship Modelling

3. 3 Introduction Limitations of basic concepts of the ER model and requirements to represent more complex applications using additional data modelling concepts. Most useful additional data modelling concepts of Enhanced ER (EER) model called: –specialization/generalization; –aggregation; –composition. EER diagram using UML.

4. 4 Specialization / Generalization Superclass – An entity type that includes one or more distinct subgroupings of its occurrences. Subclass – A distinct subgrouping of occurrences of an entity type. Superclass/subclass relationship is one-to-one. Superclass may contain overlapping or distinct subclasses. Not all members of a superclass need be a member of a subclass.

5. 5 Specialization / Generalization Attribute Inheritance – An entity in a subclass represents same real world object as in superclass, and may possess subclass-specific attributes, as well as those associated with the superclass.

6. 6 Specialization / Generalization Specialization – Process of maximizing differences between members of an entity by identifying their distinguishing characteristics. Generalization – Process of minimizing differences between entities by identifying their common characteristics.

7. 7 Specialization/Generalization - Example Doctor(doc_staffno, roomno, telno, training_hospital, date_qualified) Surgeon(sur_staffno, roomno, telno, training_hospital, date_qualified, speciality) Consultant(con_staffno, roomno, telno, training_hospital, date_qualified, specialism) Doctor SurgeonConsultant is_surgeonis_consultant Inefficient Representation

8. 8 Specialization/Generalization – Example Bachmans Notation Doctor SurgeonConsultant specialityspecialism doc_staffno roomno …

9. 9 Specialization/Generalization – Example UML Notation Doctor Surgeon Consultant speciality specialism Staffno Roomno Telno Training_hospital Date_qualified

10. 10 AllStaff Relation Holding Details of all Staff

11. 11 Specialization/Generalization of Staff Entity into Subclasses Representing Job Roles

12. 12 Specialization/Generalization of Staff Entity into Job Roles and Contracts of Employment

13. 13 EER Diagram with Shared Subclass and Subclass with its own Subclass

14. 14 Constraints on Specialization / Generalization Two constraints that may apply to a specialization/generalization: –participation constraints, –disjoint constraints. Participation constraint –Determines whether every member in superclass must participate as a member of a subclass. –May be mandatory or optional.

15. 15 Constraints on Specialization / Generalization Disjoint constraint –Describes relationship between members of the subclasses and indicates whether member of a superclass can be a member of one, or more than one, subclass. –May be disjoint or nondisjoint.

16. 16 Constraints on Specialization / Generalization There are four categories of constraints of specialization and generalization: –mandatory and disjoint; –optional and disjoint; –mandatory and nondisjoint; –optional and nondisjoint.

17. 17 DreamHome Example - Staff Superclass with Supervisor and Manager Subclasses

18. 18 DreamHome Example - Owner Superclass with PrivateOwner and BusinessOwner Subclasses

19. 19 Converting Superclass/Subclass Relationship into Relational Model

20. 20 Converting Superclass/Subclass Relationship into Relational Model Option 1 – Mandatory, Nondisjoint (And) AllOwner (ownerNo, address, telNo, fName, lName, bName, bType, contactName, pOwnerFlag, bOwnerFlag) {Mandatory, And}

21. 21 Converting Superclass/Subclass Relationship into Relational Model Option 2 – Optional, Nondisjoint (And) Owner (ownerNo, address, telNo) OwnerDetails (ownerNo*, fName, lName, bName, bType, contactName, pOwnerFlag, bOwnerFlag) {Optional, And}

22. 22 Converting Superclass/Subclass Relationship into Relational Model Option 3 – Mandatory, Disjoint (Or) PrivateOwner (ownerNo, fName, lName, address, telNo) BusinessOwner (ownerNo, bName, bType, contactName, address, telNo) {Mandatory, Or}

23. 23 Converting Superclass/Subclass Relationship into Relational Model Option 4 – Optional, Disjoint (Or) Owner (ownerNo, address, telNo) PrivateOwner (ownerNo*, fName, lName) BusinessOwner (ownerNo*, bName, bType, contactName) {Optional, Or}

24. 24 Aggregation Represents a has-a or is-part-of relationship between entity types, where one represents the whole and the other the part.

25. 25 Examples of Aggregation

26. 26 Composition Specific form of aggregation that represents an association between entities, where there is a strong ownership and coincidental lifetime between the whole and the part.

27. 27 Example of Composition

28. 28 Lecture 7 – Part 2 Advanced Normalization

29. 29 Boyce–Codd Normal Form (BCNF) BCNF - A relation is in BCNF if and only if every determinant (of a functional dependency) is a candidate key. Violation of BCNF is quite rare. Potential to violate BCNF may occur in a relation that: –contains two (or more) composite candidate keys; or –the candidate keys overlap (i.e. have at least one attribute in common).

30. 30 BCNF - Example clientNointerviewDateinterviewTimestaffNoroomNo CR7613-May-0510:30SG5G101 CR5613-May-0512:00SG5G101 CR7413-May-0512:00SG37G102 CR561-Jul-0510:30SG5G102 The relation ClientInterview stores information on client interviews by members of staff. The relation has 3 candidate keys: (clientNo, interviewDate), (staffNo, interviewDate, interviewTime), and (roomNo, interviewDate, interviewTime). The 3 composite candidate keys share a common attribute interviewDate

31. 31 BCNF - Example We select (clientNo, interviewDate) to be the primary key: ClientInterview (clientNo, interviewDate, interviewTime, staffNo, roomNo) The relation has the following functional dependencies: Fd1: clientNo, interviewDate interviewTime, staffNo, roomNo Fd2: staffNo, interviewDate, interviewTime clientNo Fd3: roomNo, interviewDate, interviewTime staffNo, clientNo Fd4: staffNo, interviewDate roomNo The determinants in Fd1, Fd2 and Fd3 are candidate keys but Fd4 is not. This means the relation is not in BCNF. As a consequence the relation may suffer from update anomalies. For example, to change the roomNo for staff SG5 on the 13-May-05 we must update two rows otherwise we will have inconsistency in the table.

32. 32 BCNF - Example To transform the relation to BCNF we must remove the violating functional dependency by splitting the original relation into two new relations: Interview (clientNo, interviewDate, interviewTime, staffNo) StaffRoom (staffNo, interviewDate, roomNo) Note: in creating these 2 BCNF relations we have lost Fd3, as the determinant for this dependency is no longer in the same relation. The decision of whether to stop at 3NF or BCNF is dependent on the amount of redundancy resulting from the presence of Fd4 and the significance of the loss of Fd3.

33. 33 Fourth Normal Form (4NF) MVD: Dependency between attributes (for example, A, B, and C) in a relation, such that for each value of A there is a set of values for B and a set of values for C. However, set of values for B and C are independent of each other: A B A C Possible existence of MVDs in a relation is due to 1NF and can result in data redundancy.

34. 34 Fourth Normal Form (4NF) MVD can be trivial or nontrivial. –MVD A B in relation R is defined as being trivial if (a) B is a subset of A or (b) A B = R. –MVD is defined as being nontrivial if neither (a) nor (b) are satisfied. –Trivial MVD does not specify a constraint on a relation, while a nontrivial MVD does specify a constraint.

35. 35 Fourth Normal Form (4NF) 4NF: a relation that is in BCNF and contains no nontrivial MVDs. The normalisation involves the removal of the MVD from the relation and placing the attribute(s) in a new relation along with a copy of the determinant(s).

36. 36 4NF - Example