1. Transformation of an ER Model into a Relational Database Schema Translating to Software

2. Two into one? ● ER model: two main concepts – Entity: with attributes ● Key, primary key, foreign key – Relationship ● Association between entities ● Relational model: just relations – Relation has heading and body – Implemented as a table in a relational database

3. Relationships and Relations ● Relationship – association between entities – semantic concept ● Relation – a mathematical object, – heading and a body, – implemented as a table in a relational database

4. Relations, Tables and ER ● Relations can represent entities as well relationships ● So entities and relationships are both implemented as tables in a relational database ● Sometimes we need to reorganize our ER model before translating it to a collection of relations

5. Two into one? ● From ER model with two main concepts – entities and relations ● To Relational model: just relations ● General rules to transform an ER model into a collection of relations ● Good implementations come from these and experience/inventiveness ● Inventiveness requires clear understanding of the relational model

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

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

8. Entities to Relations ● Start off by representing each entity class as a relation ● Add the attributes ● Indicate primary key Do it for hospital example

9. Relationships to Relations – Three simple cardinality signatures ● common ● easy to translate ● no problems – Some problem cases ● for illustration – A comprehensive list of signatures ● for revision and exercise ● for completeness – More later!

10. 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 added for illustration - not all justified by our spec.

11. Simple case 1 A(A#, …) B(B#, A#*, …) BA 1..10..*1..10..* 1:N Optional on the “many side” Rule Plant the primary key of the one side into the many side

12. Simple Case 1 - example

13. Simple case 2 A(A#, …) B(B#, …) BA 0..* N:M Optional 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#*)

14. Simple Case 2 - example

15. Simple Case 2 - comments ● Each row in the “intersection” relation represents a relationship instance ● The key is compound 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

16. Simple case 3 A(A#, …) B(B#, …) BA 0..10..* 1:N Optional 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#*)

17. Simple Case 3 - example

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

19. Relationships to Relations Simple Cases Summary ● Many-one, mandatory, (1..1, 0..*) – post key of “1” side into “many” side ● Many-one, optional, (0..1, 0..*) – create a new relation posting both keys to it – set PK to implement the multiplicity ● (the entity which can have only 1) ● Many-many, (0..*,0..*) – create a new relation posting both keys to it – set both as a joint PK of the new relation

20. Problem cases

21. Problem case 1 BA 1..1 1..* 1:N Both sides mandatory 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#*, …)

22. Problem Case 1 - example ModuleLecturer 1..11..*1..1

23. 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 some B ● Cannot enforce it ● Can check if rule is obeyed A[A#] == B[A#] ● Can query for As not found in B – query operators not found in tours – query lecturers not teaching

24. Problem case 2 BA 0..* 1..* N:M Mandatory on one side 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#*)

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

26. Problem cases - general ● These cases are less common ● 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

27. Comprehensive list of signatures

28. 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..11..*0..1 BA 1..11..*1..1

29. 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#*) BA 0..* 1..* 0..* BA 1..* BA

30. 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 Duplicates Not Null & No Duplicates No Duplicates No Duplicates BA 1..1

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

32. Two alternative ideas

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

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

35. 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 Sol n, “Step 1.7”, p147 et.seq. – DB Sys, Chapt. 8

36. Hospital ER 0..* 1..1 treats 0..* 1..1 occupies 0..* 0..1 inWard 0..* 0..1 inTheatre 0..*1..1undergoes 0..* 1..1 located 0..* 1..1 performs 0..* assists 0..* 0..1 supervises Consultant Surgeon Operation Theatre Nurse Ward Patient P Patient

37. Hospital ER

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

39. Null foreign key - example c.f. Simple case 3 - example there’s an alternative

40. Translation Summary ● Entities become relations ● Some relationships become relations ● 1..* is awkward – i.e. most mandatory participation ● These rules are not quite a “recipe” – design choices – ingenuity