Database Design Concepts IMAT1408

HNDComputing – DeMontfort University Ó DeMontfort University 2011

Handling Many to Many relationships wk5Database Design Concepts

Database Design ConceptsIMAT1408

Lecture 5

Handling Many to Many relationships



2

Handling Many:Many RelationshipsAims:

–To demonstrate how to decompose many:many (M:M) relationships–To explain why M:M relationships need to be decomposed.



3

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



4

Student Modulechooses

M M

Becomes

ModuleStudent ModuleChoice

MM1 1

makes isfor



5

The Decomposition Rule

A Br

M M

Becomes

A B

MM1 1



6

Or -

A Br

M M

Becomes

A B

MM1 1



7

Naming• Naming the new entity type and the new relationships is sometimes not easy

• Often the old relationship name will help you name the new entity. In our example “chooses” became “choice”

• 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 Patientexamines

MM



9

Solution

Doctor Patientexamines Patient at

M1Appointment attends

M 1



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#, . . . )

So try Examination (doctor#, patient#, …..)Notice that doctor# and patient# are foreign keys (marked in bold type) as well as forming the new primary key

• 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

• Could a patient see the same doctor more than once?

• Examination (doctor#, patient#, ……………………..)



14

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

• Examination (doctor#, patient#,

………………………..)



15

• This is getting a little complicated - maybe we should add a new key field: examination number

• Examination (examination#, doctor#, patient#, date, time, ..)

• What does the underlining and bold type mean?



16

Why Decompose?

Student (student#, name, . . .)Module (module#, description, . . .)How do we know which students are taking which modules?We don’t.

Student Modulechooses

M M

Back to the first exampleLook at the original M:M relationship:



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 haschosen which module.



18

Exercise

Actor (actor#, name, . . .)Film (film#, 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 Filmappearsin

M M



19

Solution

Actor FilmMember of

M1Cast List Actors in

M 1



20

Summary• We have looked at decomposition of M:M relationships• Discussed how to identify a unique identifier.



21

ReferenceData Analysis for Database Designby D R Howe

Documents

Database Design Concepts IMAT1408