SA0951a
Enhanced
Entity-Relationship
Modelling
(EERM)
and
Mapping
Reading:
e.g. Connolly/Begg (4th ed): Chapter 12 – Enhanced ERM; Mapping: “Step
6”
Rob et al: Chapter 6.1 (Advanced data modelling), Chapter 11.2 "Step 6".
1
Some limitations of ERMs


ERM’s are fine for traditional applications
But what about complex databases?
–

Enhanced ERM (EERM) supports additional
concepts
–
–
2
CAD/CAM, GIS, OIS etc
Specialisation/generalisation
Uses the UML notation
Specialisation/Generalisation


Ties into Object Oriented design
This extension uses
–
–
–
–
Superclasses
Subclasses
Attribute inheritance
Constraints


3
Participation
Disjoint
Super/Subclasses

Generalisation is the Superclass concept
–

An entity with one or more distinct subgroupings
Specialisation is the Subclass concept
–
An entity of a distinct subgrouping
Superclass
Staff

FullTime
4
PartTime
Subclasses
Continued …..

Staff has a superclass/subclass relationship
–
–

With 2 subclasses
The relationship is ONE-TO-ONE
The super/subclass structure
–
–
–
–
Avoids modelling different attributes in the same
entity
Avoids therefore nulls
Models common attributes in the superclass
Models unshared attributes in the subclasses
Staff

5
FullTime
PartTime
A word on Attribute Inheritance
Which attributes are
Inherited by Entity1.3.2?
Entity1
A
B
C

Entity1.1
D
E
F
Entity1.2
G
H
Entity1.3
I
J

Entity1.3.1
K
6
A) A,B,C,I,J
B) I,J
C) A,B,C
D) L
Entity1.3.2
L
Real Example
Staff
id
name
Age

Full-Time
salary
holidays
generalisation
Part-Time
hourlyRate
contractType
specialisation
7
Poor Example 1
Staff
id
name
age

Full-Time
salary
sex
8
generalisation
Part-Time
hourlyRate
sex
WHY is this a poor example?
A salary should be in the Staff entity
specialisation
B sex should be in the Staff entity
C name and age should be in both sub-classes
D There shouldn’t be two sub-classes
Poor Example 2
Staff
id
name
age

Full-Time
salary
holidays
generalisation
Car
registration
colour
specialisation
What is the problem here?
9
Constraints

Participation
–




10
A subclass member is always also a member of the superclass
Mandatory participation (of a superclass member in a subclass
member):
 A superclass member must be a member of a subclass
Optional participation (of a superclass member in a subclass
member):
 A superclass member need not be a member of any
subclass
Disjoint {OR}
– When a superclass member is a member of only one subclass
Non-disjoint {AND}
– A superclass member may a member of more than one
subclass (also called overlapping)
Constraints continued …




Disjoint represented by an ‘OR’
Non-disjoint (overlapping) represented by ‘AND’
Disjoint constraint only used for a hierarchy with more
than one subclass
So 4 possibilities for constraints shown on EERM:
–
{Mandatory, OR}

–
{Mandatory, AND}

–
May belong to one subclass or none
{Optional, AND}

11
Must belong to one or more subclasses
{Optional, OR}

–
Must belong to exactly one subclass
May belong to any number of subclasses
Simple Example
Staff
id
name
Age

Full-Time
Salary
holidays
{Mandatory, OR}
Part-Time
hourlyRate
contractType
“Every member of staff must be either full time or part time”
12
If the logic changed to …..
Staff
id
name
Age

Full-Time
Salary
holidays
13
{Optional, OR}
Part-Time
hourlyRate
contractType
Which statement is correct?
A
a member of staff may be full and part time
B
a member of staff has to be at least part-time
C
a member of staff must be neither full nor part-time
D
a member of staff may be either full or part time
Example
Which of these is true?
A) A reader could be both Student and Staff
B) A student could be taught and research
C) Every reader is a member of Staff
D) A student is always a research student
Reader
readerNo {PK}
name
firstName
lastName
address
{Optional, And}
Student
Staff
matricNo
email
email
department
1..3
{Mandatory, Or}
14
TaughtStudent
ResearchStudent
course
department
Supervises
0..*
Example ctd
Which of these is true?
A) ResearchStudent is a subclass of Staff
B) Staff is a superclass of ResearchStudent
C) Staff may supervise TaughtStudent
D) A ResearchStudent must be supervised by
up to 3 Staff
Reader
readerNo {PK}
name
firstName
lastName
address
{Optional, And}
Student
Staff
matricNo
email
email
department
1..3
{Mandatory, Or}
15
TaughtStudent
ResearchStudent
course
department
Supervises
0..*
Example explanation

Reader
A reader may be
readerNo {PK}
student, staff, or
name
both, but need not
firstName
be either

lastName
address
Each Student must
be either a taught or
{Optional, And}
a research student

Student
Each research
student has one to
three supervisors
Staff
matricNo
email
email
department
1..3
{Mandatory, Or}
16
TaughtStudent
ResearchStudent
course
department
Supervises
0..*
Example: Library EERM
Book
BookCopy
ISBN {PK}
author [1..*]
title
mainTitle
Has
1
copyID {PPK}
1..20 loanType
Reader
Borrows
0..*
readerNo {PK}
0..*
purchaseDate
firstName
dateOut
shelf
subTitle
returnDate
publisher
year
name
\dueDate
lastName
address
\fine
{Optional, And}
Student
We have already mapped
most of this – so how
do we map the superand subclasses?
17
Staff
matricNo
email
email
department
1..3
{Mandatory, Or}
TaughtStudent
ResearchStudent
course
department
Supervises
0..*
Mapping super- and subclasses
–
–

Treat superclasses like strong entities (step 1)
Treat subclasses like weak entities (step 2)
Deal with the relationship in Step 6:
–
–
–
4 possible ways, guidelines below
If using several relations, all include same PK
designer makes final decision
Mandatory
Overlapping Single relation
{And}
With one or more
discriminators to indicate
subclass membership
Disjoint
Many relations:
{Or}
One for each combined
superclass/subclass
18
Optional
Two relations:
One for superclass, one for
all subclasses (includes
discriminator field(s))
Many relations:
One for superclass
One for each subclass
Reader
Step 6 Example 1
readerNo {PK}
name
firstName
lastName
address
{Optional, And}
Student


Work from the
bottom: consider
Student and its
subclasses first.
Staff
matricNo
email
email
department
1..3
{Mandatory, Or}
TaughtStudent
ResearchStudent
course
department
{Mandatory, Or}
suggests
one relation for each combined super/subclass
19 What results from this?
Supervises
0..*
Reader
Step 6 ctd
readerNo {PK}
name
firstName
lastName
address
{Optional, And}
TaughtStudent
ResearchStudent
matricNo
email
course
matricNo
email
department
Staff
email
department
1..3
0..*



20
Supervises
Now deal with Reader superclass
From previous work, this currently has three subclasses:
Staff,
TaughtStudent,
ResearchStudent
Reader
readerNo {PK}
Which mapping?
1. Which is recommended here?
2. Which is totally unsuitable here?
3. Which do you prefer?
name
firstName
lastName
address
{Optional, And}
TaughtStudent
ResearchStudent
matricNo
email
course
matricNo
email
department
Staff
email
department
1..3
0..*
A




Reader(readerNo, firstN, lastN, addr)
TaughtStudent (readerNo*, matNo, email, course)
ResearchStudent (readerNo*, matNo, email, dept)
Staff(readerNo*,email, dept)
Supervises
B

Reader(readerNo, firstN, lastN, addr, matNo, stuEmail,
course, stuDept, staffEmail, staffDept, tStu?, rStu?, staff?)
C

TaughtStudent(readerNo*, firstN, lastN, addr, matNo, email, course)
ResearchStudent(readerNo*, firstN, lastN, addr, matNo, email, dept)
Staff(readerNo*, firstN, lastN, address,email, dept)


D
21


Reader(readerNo, firstN, lastN, addr)
ReaderDetails(readerNo*, matNo, stuEmail, course, stuDept,
staffEmail, staffDept, tStu?, rStu?, staff?)
Step 6 Example ctd
Now consider Reader with Staff and
 {Optional, And}
TaughtStudent, ResearchStudent “subclasses”
suggests one relation
for the superclass and
one for all subclasses
combined:
Reader
readerNo {PK}
name

firstName
lastName
address
{Optional, And}
TaughtStudent
ResearchStudent
matricNo
email
course
matricNo
email
department
Staff
email
department
1..3
0..*

Reader(readerNo,
firstName, lastName,
address)
ReaderDetails
(readerNo*, matricNo,
studentEmail, course,
stuDept, staffEmail,
staffDept,
tStu?, rStu?, staff?)
Supervises
22
Flags indicate subclass
membership explicitly
Step 6 Example ctd


The two tables suggested are clumsy – and will have lots of nulls.
Discard that option and use method for {Optional, Or} instead: use
one relation for the superclass and one for each subclass:

Reader
readerNo {PK}

name
firstName
lastName

address
{Optional, And}
TaughtStudent
ResearchStudent
matricNo
email
course
matricNo
email
department
Staff
email
department
1..3
0..*
Supervises
23

Reader(readerNo, firstName,
lastName, address)
TaughtStudent
(readerNo*, matricNo, email,
course)
ResearchStudent
(readerNo*, matricNo, email,
department)
Staff(readerNo*, email,
department)

This works nicely, also for
implementing Supervises
relationship.
Example Summary
After mapping is completed, the relational model consists of 9
relations:
Author(ISBN*, authorName)
Book(ISBN, mainTitle, subtitle, publisher, year)
BookCopy(ISBN*, copyID, loanType, purchaseDate, shelf)
Borrows(CopyID*, ISBN*, ReaderNo*, dateOut, returnDate)
Reader(readerNo, firstName, lastName, address)
Staff(readerNo*, email, department)
ResearchStudent(readerNo*, matricNo, email, department)
TaughtStudent(readerNo*, matricNo, email, course)
Supervises(rStudentReaderNo*, staffReaderNo*)
24
Key Points

EERM
Expands ERM
– Follows UML standard
 Super/subclass structure; Attribute inheritance
– One-to-one relationship between super/subclasses
– Subclasses can be hierarchical or shared
– Participation and disjoint constraints used
{Mandatory, Or}, {Optional, And} etc
Mapping: 9 Step procedure includes EERM extension:
– In steps 1&2, treat superclasses as strong entities,
subclasses as weak entities
– Use Step 6 for fine tuning - may change relations
–

25
Reading

Connolly and Begg “Database Solutions”
–
–

Connolly and Begg “Database Systems”
–
–
–

–
–
26
Chapter 11 for ERM
Chapter 12 for Enhanced ERM
Chapter 16 for mapping
Rob et al "Database Systems"
–

Chapter 7 for ERM
Chapter 11 for Enhanced ERM
Chapter 5 for ERM
Chapter 6 for EERM
Chapter 11.2 for mapping
Any other database main text book will offer help but will use a
slightly different notation
What’s coming up?

After completing (E)ERM modelling ….
–
We look at Normalisation




We shall then go back into Oracle
And really start learning SQL
Coming up later:
–
–
27
Any database textbook will have a chapter on this
There will be a class test covering modelling,
mapping and normalisation held either just before or
just after Christmas
You will be allowed to bring one A4 sheet of notes
(double-sided)