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

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 M:M Relationships A M:M relationship between 2 entity types must be decomposed into two 1:M relationships.

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

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

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

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

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 Identifiers cont. For the second example: Doctor(doctor#,.... ) Patient(patient#,... ) Examination (Doctor#patient#,..) Is this a suitable identifier?.

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 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 Could a patient see the same doctor more than once?

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

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

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 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 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 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 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 Solution Actor (actor#, name … ) Play ( play#, name, writer, length … ) Production (actor#, play#, first_performance_date, director, venue/theatre_name... etc!)

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 Common decomposition problem- example Orderline (product#,order#, …) The orderline represents each line of the order

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

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

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 References Data Analysis for database Design By D R Howe