Lecture 7

Enhanced Entity-Relationship Modelling

&

Advanced Normalisation

2

Lecture 7 – Part 1

Enhanced Entity-Relationship Modelling

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

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

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

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

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)

DoctorSurgeon Consultantis_surgeon is_consultant

Inefficient Representation

8

Specialization/Generalization – ExampleBachman’s Notation

Doctor

Surgeon Consultant

speciality specialism

doc_staffno

roomno

…

9

Specialization/Generalization – ExampleUML Notation

Doctor

Surgeon Consultant

speciality specialism

StaffnoRoomnoTelnoTraining_hospitalDate_qualified

10

AllStaff Relation Holding Details of all Staff

11

Specialization/Generalization of Staff Entity into Subclasses Representing Job Roles

12

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

13

EER Diagram with Shared Subclass and Subclass with its own Subclass

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

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

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

DreamHome Example - Staff Superclass with Supervisor and Manager Subclasses

18

DreamHome Example - Owner Superclass with PrivateOwner and BusinessOwner Subclasses

19

Converting Superclass/Subclass Relationship into Relational Model

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

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

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

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

Aggregation

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

25

Examples of Aggregation

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

Example of Composition

28

Lecture 7 – Part 2

Advanced Normalization

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

BCNF - Example

clientNo interviewDate interviewTime staffNo roomNo

CR76 13-May-05 10:30 SG5 G101

CR56 13-May-05 12:00 SG5 G101

CR74 13-May-05 12:00 SG37 G102

CR56 1-Jul-05 10:30 SG5 G102

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

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, roomNoFd2: staffNo, interviewDate, interviewTime clientNoFd3: roomNo, interviewDate, interviewTime staffNo, clientNoFd4: 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

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

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

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

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

4NF - Example