Embed Size (px)
Citation preview
Transform an ER Model into a Relational Database Schema
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: *
Entities to Relations
• Start off by representing each entity class as a relation• Add the attributes• Indicate primary key
Operator (Code, Name, Tel)Tour (Id, Start, Visiting)
Relationships to RelationsThree Simple Cases
BA1..1 0..*1..1 0..*
One to manyOptional on the “many side”
Many to manyOptional on both sides
1:NOptional on both sides
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 - 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 - 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 RelationsTwo problem cases
One to manyMandatory on both sides
Many to manyMandatory on one sides
BA1..1 1..*
BA0..* 1..*
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..*
Can do no better than the optional casePlant the key of the ‘one’ side in the ‘many’ side
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
A(A, …)
B(B, …)
Many to manyMandatory on one of the sides
BA0..* 1..*
• Can do no better than the optional case– Plant both keys in a new relation with joint PK
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 SIGNATURESReference material
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
