Eerm mapping c++
-
Upload
shriram-desai -
Category
Education
-
view
108 -
download
1
description
Transcript of Eerm mapping c++
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)