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