1

SA0951aEnhanced

Entity-Relationship Modelling(EERM)

andMapping

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

2

Some limitations of ERMs

ERM’s are fine for traditional applications But what about complex databases?

– CAD/CAM, GIS, OIS etc

Enhanced ERM (EERM) supports additional concepts– Specialisation/generalisation– Uses the UML notation

3

Specialisation/Generalisation

Ties into Object Oriented design This extension uses

– Superclasses– Subclasses– Attribute inheritance– Constraints

Participation Disjoint

4

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

Staff

Full-Time

Part-Time

Superclass

Subclasses

5

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

Full-Time

Part-Time

6

A word on Attribute Inheritance

Entity1ABC

Entity1.1DEF

Entity1.2GH

Entity1.3IJ

Entity1.3.1K

Entity1.3.2L

Which attributes are Inherited by Entity1.3.2?

A) A,B,C,I,JB) I,JC) A,B,CD) L

7

Real Example

Staffid

nameAge

Full-Timesalary

holidays

Part-TimehourlyRate

contractType

generalisation

specialisation

8

Poor Example 1

Staffid

nameage

Full-Timesalary

sex

Part-TimehourlyRate

sex

generalisation

specialisation

WHY is this a poor example?A salary should be in the Staff entity B sex should be in the Staff entityC name and age should be in both sub-classesD There shouldn’t be two sub-classes

9

Poor Example 2

Staffid

nameage

Full-Timesalary

holidays

Carregistration

colour

generalisation

specialisation

What is the problem here?

10

Constraints

Participation– 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} Must belong to exactly one subclass

– {Mandatory, AND} Must belong to one or more subclasses

– {Optional, OR} May belong to one subclass or none

– {Optional, AND} May belong to any number of subclasses

12

Simple Example

Staffid

nameAge

Full-TimeSalary

holidays

Part-TimehourlyRate

contractType

{Mandatory, OR}

“Every member of staff must be either full time or part time”

13

If the logic changed to …..

Staffid

nameAge

Full-TimeSalary

holidays

Part-TimehourlyRate

contractType

{Optional, OR}

Which statement is correct?A a member of staff may be full and part timeB a member of staff has to be at least part-timeC a member of staff must be neither full nor part-timeD a member of staff may be either full or part time

14

Example

R e a d e r

re a d e rNo {P K }

n a m e

f irs tNa m e

la s tNa m e

a d d re ss

S tu d e n t

m a tr icNo

e m a il

S ta ff

e m a il

d e p a r tm e n t

R e se a rch S tu d e n t

d e p a r tm e n t

T a u g h tS tu d e n t

co u rse

{O p tio nal, And }

{M and ato ry, O r}

S up ervises

1 . .3

0 . .*

Which of these is true?A) A reader could be both Student and Staff B) A student could be taught and researchC) Every reader is a member of StaffD) A student is always a research student

15

Example ctd

R e a d e r

re a d e rNo {P K }

n a m e

f irs tNa m e

la s tNa m e

a d d re ss

S tu d e n t

m a tr icNo

e m a il

S ta ff

e m a il

d e p a r tm e n t

R e se a rch S tu d e n t

d e p a r tm e n t

T a u g h tS tu d e n t

co u rse

{O p tio nal, And }

{M and ato ry, O r}

S up ervises

1 . .3

0 . .*

Which of these is true?A) ResearchStudent is a subclass of StaffB) Staff is a superclass of ResearchStudentC) Staff may supervise TaughtStudentD) A ResearchStudent must be supervised by up to 3 Staff

16

Example explanation

R e a d e r

re a d e rNo {P K }

n a m e

f irs tNa m e

la s tNa m e

a d d re ss

S tu d e n t

m a tr icNo

e m a il

S ta ff

e m a il

d e p a r tm e n t

R e se a rch S tu d e n t

d e p a r tm e n t

T a u g h tS tu d e n t

co u rse

{O p tio nal, And }

{M and ato ry, O r}

S up ervises

1 . .3

0 . .*

A reader may be

student, staff, or

both, but need not

be either

Each Student must

be either a taught or

a research student

Each research

student has one to

three supervisors

17

Example: Library EERM

B o o k

ISB N {P K }

a u th o r [1 ..*]

t it le

m a in T itle

su b T itle

p u b lish e r

ye a r

B o o kC o p y

co p y ID {P PK }

lo a n T yp e

p u rch a se D a te

sh e lf

H as1 . .2 01

d a te O u t

re tu rn D a te

\d u e D a te

\fin e

B o rro ws

0 . .* 0 . .*

R e a d e r

re a d e rNo {P K }

n a m e

f irs tNa m e

la s tNa m e

a d d re ss

S tu d e n t

m a tr icNo

e m a il

S ta ff

e m a il

d e p a r tm e n t

R e se a rch S tu d e n t

d e p a r tm e n t

T a u g h tS tu d e n t

co u rse

{O ptio nal, And}

{M andato ry, O r}

Supe rvise s

1 . .3

0 . .*

We have already mapped most of this – so how do we map the super- and subclasses?

18

– 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 Optional

Overlapping {And}

Single relation With one or more discriminators to indicate subclass membership

Two relations: One for superclass, one for all subclasses (includes discriminator field(s))

Disjoint {Or}

Many relations: One for each combined superclass/subclass

Many relations: One for superclass One for each subclass

Mapping super- and subclasses

19

Work from the bottom: consider Student and its subclasses first.

{Mandatory, Or} suggests one relation for each combined super/subclass

What results from this?

R e a d e r

re a d e rNo {P K }

n a m e

f irs tNa m e

la s tNa m e

a d d re ss

S tu d e n t

m a tr icNo

e m a il

S ta ff

e m a il

d e p a r tm e n t

R e se a rch S tu d e n t

d e p a r tm e n t

T a u g h tS tu d e n t

co u rse

{O p tio nal, And }

{M and ato ry, O r}

S up ervises

1 . .3

0 . .*

Step 6 Example 1

20

Step 6 ctdR e a d e r

re a d e rNo {PK}

n a me

firs tNa me

la stNa me

a d d re ss

T a u g h tStu d e n t

ma tr icNo

e ma ilco u rse

Sta ff

e ma il

d e p a rtme n t

R e se a rch Stu d e n t

ma tr icNoe ma ild e p a rtme n t

{O p tio nal, A nd }

S up ervis es

1 . .30 . .*

Now deal with Reader superclass From previous work, this currently has three subclasses: Staff,

TaughtStudent, ResearchStudent

21

Reader(readerNo, firstN, lastN, addr) ReaderDetails(readerNo*, matNo, stuEmail, course, stuDept,

staffEmail, staffDept, tStu?, rStu?, staff?)

Which mapping?

Reader(readerNo, firstN, lastN, addr, matNo, stuEmail, course, stuDept, staffEmail, staffDept, tStu?, rStu?, staff?)

TaughtStudent(readerNo*, firstN, lastN, addr, matNo, email, course) ResearchStudent(readerNo*, firstN, lastN, addr, matNo, email, dept) Staff(readerNo*, firstN, lastN, address,email, dept)

1. Which is recommended here?2. Which is totally unsuitable here?3. Which do you prefer?

AA

BB

CC

DD

R eade r

reade rNo {PK}

name

firs tName

lastName

add ress

T augh tStuden t

ma tr icNo

ema ilcou rse

Sta ff

ema il

depa rtmen t

R esea rchStuden t

ma tr icNoema ildepa rtmen t

{O p tio nal, A nd }

S up ervis es

1 . .30 . .*

Reader(readerNo, firstN, lastN, addr) TaughtStudent (readerNo*, matNo, email, course) ResearchStudent (readerNo*, matNo, email, dept) Staff(readerNo*,email, dept)

22

Step 6 Example ctd

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

Now consider Reader with Staff and TaughtStudent, ResearchStudent “subclasses”

Flags indicate subclass membership explicitly

R eade r

rea de rNo {PK}

name

firs tName

la stName

add ress

T augh tStude n t

ma tr icNo

ema ilcou rse

Sta ff

ema il

depa rtmen t

R esea rchStu den t

ma tr icNoema ildepa rtmen t

{O p tio nal, A nd }

S up ervis es

1 . .30 . .*

23

Step 6 Example ctd

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.

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:

R e a d e r

re a d e rNo {PK}

n a me

firs tNa me

la stNa me

a d d re ss

T a u g h tStu d e n t

ma tr icNo

e ma ilco u rse

Sta ff

e ma il

d e p a rtme n t

R e se a rch Stu d e n t

ma tr icNoe ma ild e p a rtme n t

{O p tio nal, A nd }

S up ervis es

1 . .30 . .*

24

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

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

26

Reading

Connolly and Begg “Database Solutions”– Chapter 7 for ERM– Chapter 11 for Enhanced ERM

Connolly and Begg “Database Systems”– Chapter 11 for ERM– Chapter 12 for Enhanced ERM– Chapter 16 for mapping

Rob et al "Database Systems"– 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:

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