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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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