1. Lecture 9 Handling Many to Many Relationships INFO 1408 Database Design Concepts

2. 2 Handling Many:Many Relationships Aims: To demonstrate how to decompose many:many (M:M) relationships To explain why M:M relationships need to be decomposed. Introduce other types of relationships

3. 3 M:M Relationships A M:M relationship between 2 entity types must be decomposed into two 1:M relationships.

4. 4 StudentModule chooses MM Becomes ModuleStudent Module Choice makes is for M M 1 1

5. 5 The Decomposition Rule AB r MM Becomes AB M M 1 1

6. 6 Or - AB r MM Becomes AB M M 1 1

7. 7 Naming Naming the new entity type and the new relationships is sometimes not easy Consider what it is representing If all else fails, concatenate/ join the names of the 2 original entity types (e.g. Student Module).

8. 8 Exercise Decompose this M:M relationship to form two 1:M relationships: Assign the new entity and relationship types suitable names. Doctor Patient examines M M

9. 9 Solution

10. 10 Identifiers We have seen that an entity must have an Identifier The new entity type created by decomposition needs an identifier Start with a composite of the Identifiers of the 2 original entity types Need to consider carefully whether this will uniquely identify every occurrence of the new entity type.

11. 11 Identifiers cont. For the second example: Doctor(doctor#,.... ) Patient(patient#,... ) Examination (Doctor#patient#,..) Is this a suitable identifier?.

12. 12 Identifiers cont. To decide if an identifier is suitable: Think of some other attributes for the entity: Is one pair of doctor#, patient# values associated with just one value of each of these attributes?.

13. 13 To decide if an identifier is suitable: Think of some other attributes for the entity: Is one pair of doctor#, patient# values associated with just one value of each of these attributes?. No

14. 14 Could a patient see the same doctor more than once?

15. 15 Could a patient see the same doctor more than once? Yes – So add date Examination (doctor#,patient#date, … )

16. 16 Could a patient see the doctor more than once in a day?

17. 17 Could a patient see the doctor more than once in a day? Yes ( not common) so add time Examination (doctor#,patient#date,time..)

18. 18 This is getting a little complicated maybe we should add a new key field examination number Examination (Examination# doctor#, patient#, date, time,..) Note patient# and doctor# now foreign keys

19. 19 Why Decompose? Student(student#, name,...) Module(module#, description,...) How do we know which students are taking which modules?. We don ’ t StudentModule chooses MM Back to the first example Look at the original M:M relationship:

20. 20 Why Decompose? cont. Decomposing gives us a new table: Student Module (student#, module#,...................) Is this a suitable identifier ? Now we can list which student has chosen which module.

21. 21 Exercise Actor (actor#, name,...) Play (play#, title,...) Decompose this M:M relationship Assign the new entity type an appropriate name and think of some additional attributes for it Assign the new entity type a suitable identifier. Actor Play appears _in MM

22. 22 Solution Actor (actor#, name … ) Play ( play#, name, writer, length … ) Production (actor#, play#, first_performance_date, director, venue/theatre_name... etc!)

23. 23 Common Decomposition problem Many decomposition entities represent business transactions ( or pieces of paper) E.G booking, order, They may be very difficult to name-

24. 24 Common decomposition problem- example Orderline (product#,order#, …) The orderline represents each line of the order

25. 25 Other types of relationships Recursive relationships An individual entity can have a relationship with an entity of the same type

26. 26 Another example- Estate agents It is possible to have more than one relationship between two entities

27. 27 Summary We have looked at decomposition of m:m relationships. Discussed how to identify a unique identifier Introduced recursive relationships Introduced multiple relationships between entities

28. 28 References Data Analysis for database Design By D R Howe