Download presentation

Presentation is loading. Please wait.

Published byMiguel Stammer Modified over 4 years ago

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

3
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

4
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

5
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

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

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

8
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!

9
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

10
Simple Case 1 - example

11
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#*)

12
Simple Case 2 - example

13
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

14
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#*)

15
Simple Case 3 - example

16
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

17
Relationships to Relations Simple 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

18
Problem cases

19
Problem case 1 BA 1..1 1..* 1:N Mandatory 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#*, …)

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

21
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

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

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

24
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

25
Comprehensive list of signatures

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

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

28
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

29
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

30
Two alternative ideas

31
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

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

33
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

34
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

35
Hospital ER

36
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

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

38
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

39
Subtype Relationships We will return to these

Similar presentations

OK

Michael F. Price College of Business Chapter 6: Logical database design and the relational model.

Michael F. Price College of Business Chapter 6: Logical database design and the relational model.

© 2018 SlidePlayer.com Inc.

All rights reserved.

To make this website work, we log user data and share it with processors. To use this website, you must agree to our Privacy Policy, including cookie policy.

Ads by Google