1. Transform an ER Model into a Relational Database Schema

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

3. How we do it Entities Relationships all become relations (tables)
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

4. Notation Primary key attribute(s): underline & bold
Foreign key attributes: *

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

6. Relationships to Relations Three Simple CasesB A
1..1
0..*
One to many
Optional on the “many side”
Many to many
Optional on both sides
1:N
Optional on both sides

7. Simple Case 1 - example

8. Simple Case 2 - example

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

10. Simple Case 3 - example

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

12. Relationships to Relations Two problem cases
1..1
1..*
One to many
Mandatory on both sides B A
0..*
1..*
Many to many
Mandatory on one sides

13. Problem Case 1 - example Can do no better than the optional case
Module
Lecturer
1..1
1..*
Can do no better than the optional case
Plant the key of the ‘one’ side in the ‘many’ side

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

15. Problem case 2 Can do no better than the optional case R(A*, B*)
0..*
1..*
Many to many Mandatory on one of the sides
Can do no better than the optional case
Plant both keys in a new relation with joint PK
R(A*, B*)
A(A, …) B(B, …)

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

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

18. Comprehensive list of signatures
Reference material

19. 1:N Relationships A(A,…) B(B,…) R(A*,B*) A(A,…) B(B, A*,…) A(A,…)
0..1
1..*
R(A*,B*)
A(A,...)
B(B, A*,...) B A
1..1
1..*

20. Binary (M:N) Relationships
A(A,…)
B(B,…)
R(A*,B*)
A(A,…)
B(B,…)
R(A*,B*) B A
1..*
0..*
A(A,…)
B(B,...) B A
0..*
1..*
R(A*,B*)
A(A,...)
B(B,...) B A
1..*
R(A*,B*)

21. Binary (1:1) Relationships
R(A*,B*) or
A(A,…)
B(B,…)
A(A,…)
B(B, A*…) No
Duplicates
c.f. above A  B
Not Null &
No Duplicates
A(A,…)
B(B, A*…) B A
1..1