Transformation of an ER Model into a Relational Database Schema Translating to Software.
-
Upload
miguel-stammer -
Category
Documents
-
view
225 -
download
1
Transcript of Transformation of an ER Model into a Relational Database Schema Translating to Software.
Transformation of an ER Model into a Relational Database
Schema
Translating to Software
2 into 1 won’t go?
• ER model has 2 major concepts– Entities– Relationships
• Relational model has 1 major concept– Relation (table)
• There are general rules for translation– good implementations come from these and
experience/inventiveness– inventiveness requires clear understanding of
the relational model
How we do it
Entities– all become relations (tables)
Relationships– some become relations (tables)– some are implemented by use of PK, FK– some need additional coding
• using DBMS facilities
• using application code if necessary
– we know which by their cardinality signatures
Notation
• Primary key attribute(s): underline & bold
• Foreign key attributes: *
• #: Unique attribute indicator– traditional usage, helps identify keys in
simplified examples• A# is the PK of relation A
Entities to Relations
• Start off by representing each entity class as a relation
• Add the attributes
• Indicate primary key
Do it for hospital example
Hospital Example
PATIENT{P#,PName,PAddress,Dob,Sex}
P_PATIENT{P#}
WARD{W#,WType}
NURSE{N#,Name,Grade}
OPERATION{Op#,Type,Date,Time}
SURGEON{Sname,SAddress,Tel#}
CONSULTANT{Cname,Speciality}
THEATRE{T#,TheatreType}
Attributes addedfor illustration - not all justified by our spec.
Relationships to Relations
In lectures we will– Look at 3 simple cardinality signatures
• common
• easy to translate
• no problems
– Look at some problem cases• for illustration
– Look at a comprehensive list of signatures• for revision and exercise
• for completeness
– Return for more later!
Simple case 1
A(A#, …)
B(B#, A#*, …)
BA1..1 0..*1..1 0..*
1:NOptional on the “many side”
Rule• Plant the primary key of the one side into the
many side
Simple Case 1 - example
OperatorCode Name Tel. …
EOE Eastern & Oriental Express 2272068
DSH Dino Shipping 276922
TourID OperatorCode* Start Visiting …
1 EOE Singapore Bangkok
2 DSH Singapore Bintan
TourOperator
1..1 0..*1..1 0..*
Simple case 2
A(A#, …)
B(B#, …)
BA0..* 0..*0..*
N:MOptional on both sides
Rule• Create a relation to represent the relationship• Plant both primary keys in it as the joint primary
key
R(A#*, B#*)
Simple Case 2 - example
StudentSID Name Scheme …
1234 John Doe Maths
5678 Jane Black CS
ModuleCode Title …
CS123 Databases
MA111 Hard sums
CS456 Java
ModuleStudent
0..* 0..*0..* 0..*
TakesSID* Code*
5678 CS123
5678 CS456
Simple Case 2 - comments
• The existence of a tuple in the “intersection” relation is the relationship instance
• The key is joint because a student can only take a module once– SID as PK would let a student do only 1 module– CODE as PK would let a module have only 1
student
Simple case 3
A(A#, …)
B(B#, …)
BA0..1 0..*0..*
1:NOptional on both sides
Rule• Create a relation to represent the relationship• Plant both primary keys in it• Make the many side key the new PK
R(A#*,B#*)
Simple Case 3 - example
StudentSID Name Scheme …
1234 John Doe Maths
5678 Jane Black CS
SponsorCo Company …
AI ACME Inc
WT Wiztronics
SC Softco
Sponsoring SID* Co*
1234 WT
5678 AI
StudentSponsor
0..1 0..*0..1 0..*
Simple Case 3 - comments
• Again, the existence of a tuple in the “intersection” relation is the relationship instance
• The intersection PK is only one FK (student)– SID is PK so each student can have max 1
Sponsoring– CO not PK, Sponsor could have many
Sponsorings
Relationships to RelationsSimple Summary
Bring keys of associated entities together by– If there is a “one” side
• if Mandatory– posting key as foreign key into an existing “host” relation
• if Optional– creating a new relation posting both keys to it
– set PK to implement the multiplicity
» (the entity which can have only 1)
– If there are 2 “many” sides• creating a new relation posting both keys to it
• set both as a joint PK
Problem cases
Problem case 1
BA1..1 1..*
1:NMandatory on both sides
Situation• 1..* is our problem
– the tell-tale signature
• Can do no better than the optional case– Plant the key of A in B
A(A#, …)
B(B#, A#*, …)
Problem Case 1 - example
ModuleName Lecturer*
Databases Hardy
Law Bott
Maths Holstein
Robots Hardy
Lecturer
Alsberg
Bott
Hardy
Holstin
ModuleLecturer
1..1 1..*1..1 1..*
Problem case 1 - comments• How can we ensure that every instance of A
is involved in at least one relationship with a B?– i.e. every A# appears in B
• Cannot enforce it• Can check if rule is obeyed (rel. algebra)
A[A#] == B[A#]
• Can query for As not found in B– could query for operators not found in tours
– could list lecturers not teaching
Problem case 2
BA0..* 1..*
N:MMandatory on one of the sides
Situation• 1..* again• Can do no better than the optional case
– Plant the key of A and B in a new relation and joint PK
A(A#, …)
B(B#, …) R(A#*, B#*)
Problem case 2 - comments
• How can we ensure that every instance of A (every A#) is involved in at least one relationship with a B? (same question)
• Cannot enforce it (same problem!)
• Every A# must appear in R at last once
• Can check if rule is obeyed (rel. algebra)A[A#] == R[A#]
• Can query for As not found in R etc.
Problem cases - general
• These cases are the less common ones
• Often the constraints cannot be implemented for all time– modules and students before registration?
• Often left unimplemented– but with a mechanism to list breaches
• a query, run regularly or on demand
• Enforcing participation may just not be important
Comprehensive list of signatures
1:N Relationships
A(A#,...)B(B#, A#*,...)
A(A#,…)B(B#,…)
R(A#*,B#*)
A(A#,…)B(B#, A#*,…)
A(A#,…)B(B#,...) R(A#*,B#*)
BA
0..1 0..*0..1 0..*
BA
1..1 0..*1..1 0..*
BA
0..1 1..*0..1 1..*
BA
1..1 1..*1..1 1..*
Binary (M:N) Relationships
A(A#,…)B(B#,…)
R(A#*,B#*)
A(A#,...)B(B#,...)
A(A#,…)B(B#,…)
A(A#,…)B(B#,...) R(A#*,B#*)
R(A#*,B#*)
R(A#*,B#*)
BA
0..* 0..*0..* 0..*
BA
1..* 0..*1..* 0..*
BA
0..* 1..*0..* 1..*
BA
1..* 1..*1..* 1..*
Binary (1:1) Relationships
A(A#,…)B(B#,…)
R(A#*,B#*)or
R(A#*,B#*)
A(A#,…)B(B#, A#*…)
A(A#,…)B(B#, A#*…)
c.f. above A B Not Null &
No DuplicatesNot Null &
No Duplicates
NoDuplicates
NoDuplicates
BA
0..1 0..10..1 0..1
BA
1..1 0..11..1 0..1
BA
0..1 1..10..1 1..1
BA
1..1 1..11..1 1..1
Schema semantics
• For the 12 cases there are only 3 different relational schemas
• 1..* is the problem– ensuring minimal participation– (also 1..1)
• ensuring two way participation
• there may be a chicken and egg problem here– do we really want it?
– we may have only one entity really
Two alternative ideas
Idea 1
N:M and the Relational Model
• Just not supported
• We have always needed a third table
• Is that an entity we missed?– Matter of opinion (“takes” or “Registration”)
• May want to represent N:M on the ER– makes sense to the user
• Any N:M can be decomposed to two 1:N
M:N Decomposition
A(A#, …)
B(B#, …)This is exactly the same relational schema as for
the M:N relationship below.R(A#*, B#*, …)
Note: A pair of M:N’s leads to a fan trap.
BA
0..* 0..*0..* 0..*
A R
1..1 0..*
B
1..10..*0..* 1..11..1 0..*
Modified ER?
• After the ER model is agreed:– Make systematic changes to move it towards
the relational model• replace N:M
• replace optional 1:N
• C&B, recommend this stage– DB Soln, “Step 1.7”, p147 et.seq.– DB Sys, Chapt. 8
Hos
pita
l ER
0..*
1..1treats
0..*
1..1
occupies
0..*
0..1 inWard
0..*
0..1inTheatre
0..*1..1 undergoes
0..*
1..1
located
0..*
1..1
performs
0..*
0..*
assists
0..*
0..1
supervises
Consultant
Surgeon
Operation
Theatre
Nurse
Ward
Patient
P Patient
Hos
pita
l ER
0..*
1..1
0..1
1..1
0..*
1..1
0..*
1..1
0..*
1..1treats
0..*
1..1
occupies
0..*1..1 undergoes
0..*
1..1
located
0..*
1..1
performs
0..11..1
0..*
1..1
0..1 1..1
0..*
1..1
Consultant
Surgeon
Operation
TheatreWard
Patient
P Patient
assists
supervises
Nurse inTheatreinWard
Idea 2
Null foreign keys for “optional” 1:N
• We have been creating intersection relations
• We can treat it as the mandatory case but give the foreign key no value
• Lots of blanks where there is no relationship
Null foreign key - example
StudentSID Name Co* Scheme …
1234 John Doe Maths
5678 Jane Black AI CS
SponsorCo Company …
AI ACME Inc
WT Wiztronics
SC Softco
StudentSponsor
0..1 0..*0..1 0..*
c.f. Simple case 3 - example
there’s an alternative
Translation Summary(for now)
• Entities become relations
• Some relationships become relations
• 1..* is hard– i.e. most mandatory participation
• It is not quite a “recipe”– design choices– ingenuity
Subtype Relationships
We will return to these