lecture 7 enhanced entity-relationship modelling & advanced normalisation
TRANSCRIPT
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