The document discusses enhanced entity-relationship modelling (EERM) and mapping EERMs to a relational database. It introduces concepts like generalization/specialization and subclasses. The key steps in mapping are: (1) treat superclasses as strong entities; (2) treat subclasses as weak entities; and (3) map the superclass-subclass relationships, typically using one table for each superclass and subclass. For the library example EERM, the optimal mapping results in 9 relations, including separate tables for each of the Reader subclasses: Staff, ResearchStudent, and TaughtStudent.

1. 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

2. Some limitations of ERMs
 ERM’s
are fine for traditional applications
 But what about complex databases?
–
CAD/CAM, GIS, OIS etc
 Enhanced
concepts
–
–
2
ERM (EERM) supports additional
Specialisation/generalisation
Uses the UML notation

3. Specialisation/Generalisation
 Ties
into Object Oriented design
 This extension uses
–
–
–
–
Superclasses
Subclasses
Attribute inheritance
Constraints
 Participation
 Disjoint
3

4. Super/Subclasses
 Generalisation
–
An entity with one or more distinct subgroupings
 Specialisation
–
is the Superclass concept
is the Subclass concept
An entity of a distinct subgrouping
Superclass
Staff

FullTime
4
PartTime
Subclasses

5. Continued …..
 Staff
–
–
With 2 subclasses
The relationship is ONE-TO-ONE
 The
–
–
–
–
has a superclass/subclass relationship
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

6. 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

7. Real Example
Staff
id
name
Age

Full-Time
salary
holidays
generalisation
Part-Time
hourlyRate
contractType
specialisation
7

8. 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

9. Poor Example 2
Staff
id
name
age

Full-Time
salary
holidays
generalisation
Car
registration
colour
specialisation
9
What is the problem here?

10. 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)

11. 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

12. 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

13. 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

14. 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
R eader
re a d e rN o {P K }
nam e
f ir s t N a m e
la s t N a m e
a d d re s s
{ O p t io n a l, A n d }
S tu d e n t
S ta ff
m a t r ic N o
e m a il
e m a il
d e p a rtm e n t
1 ..3
{ M a n d a to ry , O r}
T a u g h tS tu d e n t
c o u rs e
14
R e s e a rc h S tu d e n t
d e p a rtm e n t
S u p e r v is e s
0 ..*

15. 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
R eader
re a d e rN o {P K }
nam e
f ir s t N a m e
la s t N a m e
a d d re s s
{ O p t io n a l, A n d }
S tu d e n t
S ta ff
m a t r ic N o
e m a il
e m a il
d e p a rtm e n t
1 ..3
{ M a n d a to ry , O r}
T a u g h tS tu d e n t
c o u rs e
15
R e s e a rc h S tu d e n t
d e p a rtm e n t
S u p e r v is e s
0 ..*

16. Example explanation

R eader
A reader may be
re a d e rN o {P K }
student, staff, or
nam e
both, but need not
f ir s t N a m e
be either

la s t N a m e
a d d re s s
Each Student must
be either a taught or
{ O p t io n a l, A n d }
a research student

S tu d e n t
Each research
student has one to
three supervisors
S ta ff
m a t r ic N o
e m a il
e m a il
d e p a rtm e n t
1 ..3
{ M a n d a to ry , O r}
T a u g h tS tu d e n t
c o u rs e
16
R e s e a rc h S tu d e n t
d e p a rtm e n t
S u p e r v is e s
0 ..*

17. Example: Library EERM
Book
BookC opy
H as
IS B N { P K }
a u th o r [1 ..*]
t it le
m a in T it le
1
c o p y ID { P P K }
1 . . 2 0 lo a n T y p e
R eader
B o rro w s
0 ..*
0 ..*
p u r c h a s e D a te
s u b T it le
re tu rn D a te
p u b lis h e r
year
nam e
f ir s t N a m e
d a te O u t
s h e lf
re a d e rN o {P K }
d u e D a te
la s t N a m e
a d d re s s
f in e
{ O p tio n al, A n d }
S tu d e n t
We have already
mapped most of this –
so how do we map the
super- and
subclasses?
17
S ta ff
m a t r ic N o
e m a il
e m a il
d e p a rtm e n t
1 ..3
{ M an d ato ry , O r}
T a u g h tS tu d e n t
R e s e a r c h S tu d e n t
c o u rs e
d e p a r tm e n t
S u p e rvis e s
0 ..*

18. 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

19. R eader
Step 6 Example 1
re a d e rN o {P K }
nam e
f ir s t N a m e
la s t N a m e
a d d re s s
{ O p t io n a l, A n d }
S tu d e n t
S ta ff
m a t r ic N o

e m a il
Work from the
bottom: consider
Student and its
subclasses first.
e m a il
d e p a r tm e n t
{ M a n d a to ry , O r}
T a u g h tS tu d e n t
R e s e a r c h S tu d e n t
c o u rs e

1 ..3
d e p a rtm e n t
{Mandatory, Or}
suggests
one relation for each combined super/subclass
19 What results from this?
S u p e r v is e s
0 ..*

20. R eader
Step 6 ctd
re a d e rN o {P K }
nam e
f ir s t N a m e
la s t N a m e
a d d re ss
{ O p t io n a l, A n d }
T a u g h tS tu d e n t
R e s e a r c h S tu d e n t
m a t r ic N o
e m a il
c o u rse
m a t r ic N o
e m a il
d e p a rtm e n t
S ta ff
e m a il
d e p a rtm e n t
1 ..3
0 ..*



20
S u p e r v is e s
Now deal with Reader superclass
From previous work, this currently has three subclasses:
Staff,
TaughtStudent,
ResearchStudent

21. R eader
Which mapping?
1. Which is recommended here?
2. Which is totally unsuitable here?
3. Which do you prefer?
A




re a d e rN o {P K }
nam e
f ir s t N a m e
la s t N a m e
a d d re s s
{ O p t io n a l, A n d }
T a u g h tS tu d e n t
R e s e a rc h S tu d e n t
m a t r ic N o
e m a il
c o u rs e
m a t r ic N o
e m a il
d e p a r tm e n t
Reader(readerNo, firstN, lastN, addr)
TaughtStudent (readerNo*, matNo, email, course)
ResearchStudent (readerNo*, matNo, email, dept)
Staff(readerNo*,email, dept)
d e p a rtm e n t
1 ..3
0 ..*
S u p e r v is e s
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?)
S ta ff
e m a il

22. Step 6 Example ctd
Now consider Reader with Staff and

TaughtStudent, ResearchStudent “subclasses”
R eader
re a d e rN o {P K }
nam e
f ir s t N a m e

la s t N a m e
a d d re s s
{ O p t io n a l, A n d }
T a u g h tS tu d e n t
R e s e a rc h S tu d e n t
m a t r ic N o
e m a il
c o u rs e
m a t r ic N o
e m a il
d e p a rtm e n t
S ta ff
e m a il
d e p a r tm e n t
1 ..3
0 ..*
S u p e r v is e s
22

{Optional, And}
suggests one relation
for the superclass and
one for all subclasses
combined:
Reader(readerNo,
firstName, lastName,
address)
ReaderDetails
(readerNo*, matricNo,
studentEmail, course,
stuDept, staffEmail,
staffDept,
tStu?, rStu?, staff?)
Flags indicate subclass
membership explicitly

23. 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
re a d e rN o {P K }

nam e
f ir s t N a m e
la s t N a m e

a d d re s s
{ O p t io n a l, A n d }
T a u g h tS tu d e n t
R e s e a r c h S tu d e n t
m a t r ic N o
e m a il
c o u rs e
m a t r ic N o
e m a il
d e p a rtm e n t
S ta ff
e m a il
d e p a rtm e n t
1 ..3
0 ..*
23

S u p e r v is e s

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.

24. Example Summary
After mapping is completed, the relational model consists of 9
relations:
24
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*)

25. 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

26. Reading
 Connolly
–
–
Chapter 7 for ERM
Chapter 11 for Enhanced ERM
 Connolly
–
–
–

–
–
26
and Begg “Database Systems”
Chapter 11 for ERM
Chapter 12 for Enhanced ERM
Chapter 16 for mapping
Rob et al "Database Systems"
–

and Begg “Database Solutions”
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

27. What’s coming up?
 After
–
completing (E)ERM modelling ….
We look at Normalisation
 Any
database textbook will have a chapter on this
 We
shall then go back into Oracle
 And really start learning SQL
 Coming up later:
–
–
27
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)