HNDComputing – DeMontfort University Ó DeMontfort University 2011
Handling Many to Many relationships wk5Database Design Concepts
Database Design ConceptsIMAT1408
Lecture 5
Handling Many to Many relationships
HNDComputing – DeMontfort University Ó DeMontfort University 2011
Handling Many to Many relationships wk5Database Design Concepts
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.
HNDComputing – DeMontfort University Ó DeMontfort University 2011
Handling Many to Many relationships wk5Database Design Concepts
3
M:M Relationships• A M:M relationship between 2 entity types must be decomposed into two 1:M relationships.
HNDComputing – DeMontfort University Ó DeMontfort University 2011
Handling Many to Many relationships wk5Database Design Concepts
4
Student Modulechooses
M M
Becomes
ModuleStudentModuleChoice
MM1 1
makesisfor
HNDComputing – DeMontfort University Ó DeMontfort University 2011
Handling Many to Many relationships wk5Database Design Concepts
5
The Decomposition Rule
A Br
M M
Becomes
A B
MM1 1
HNDComputing – DeMontfort University Ó DeMontfort University 2011
Handling Many to Many relationships wk5Database Design Concepts
6
Or -
A Br
M M
Becomes
A B
MM1 1
HNDComputing – DeMontfort University Ó DeMontfort University 2011
Handling Many to Many relationships wk5Database Design Concepts
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).
HNDComputing – DeMontfort University Ó DeMontfort University 2011
Handling Many to Many relationships wk5Database Design Concepts
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
HNDComputing – DeMontfort University Ó DeMontfort University 2011
Handling Many to Many relationships wk5Database Design Concepts
9
Solution
Doctor Patientexamines Patient at
M1Appointment attends
M 1
HNDComputing – DeMontfort University Ó DeMontfort University 2011
Handling Many to Many relationships wk5Database Design Concepts
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.
HNDComputing – DeMontfort University Ó DeMontfort University 2011
Handling Many to Many relationships wk5Database Design Concepts
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?.
HNDComputing – DeMontfort University Ó DeMontfort University 2011
Handling Many to Many relationships wk5Database Design Concepts
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?
•
HNDComputing – DeMontfort University Ó DeMontfort University 2011
Handling Many to Many relationships wk5Database Design Concepts
13
• Could a patient see the same doctor more than once?
• Examination (doctor#, patient#, ……………………..)
HNDComputing – DeMontfort University Ó DeMontfort University 2011
Handling Many to Many relationships wk5Database Design Concepts
14
• Could a patient see the doctor more than once in a day?
• Examination (doctor#, patient#,
………………………..)
HNDComputing – DeMontfort University Ó DeMontfort University 2011
Handling Many to Many relationships wk5Database Design Concepts
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?
HNDComputing – DeMontfort University Ó DeMontfort University 2011
Handling Many to Many relationships wk5Database Design Concepts
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:
HNDComputing – DeMontfort University Ó DeMontfort University 2011
Handling Many to Many relationships wk5Database Design Concepts
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.
HNDComputing – DeMontfort University Ó DeMontfort University 2011
Handling Many to Many relationships wk5Database Design Concepts
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
HNDComputing – DeMontfort University Ó DeMontfort University 2011
Handling Many to Many relationships wk5Database Design Concepts
19
Solution
Actor FilmMember of
M1Cast List Actors in
M 1
HNDComputing – DeMontfort University Ó DeMontfort University 2011
Handling Many to Many relationships wk5Database Design Concepts
20
Summary• We have looked at decomposition of M:M relationships• Discussed how to identify a unique identifier.
HNDComputing – DeMontfort University Ó DeMontfort University 2011
Handling Many to Many relationships wk5Database Design Concepts
21
ReferenceData Analysis for Database Design
by D R Howe