Section 09 ER Decomposition Of Many To Many 1
HSQ - DATABASES & SQL
And Franchise Colleges
09 ER Decomposition of Many-to-Many
Section 09 ER Decomposition Of Many To Many 2
• A MANY to MANY relationship can be decomposed into two ONE to MANY relationship.
• Decomposition of many to many relationships is a standard E-R technique.
• All many to many relationship types must be decomposed to form a complex entity as above.
• Mapping many to many relationship types back to reality often is very difficult ....
Decomposition of a Many to Many Relationship
Section 09 ER Decomposition Of Many To Many 3
p# pdesc cost rrp s# sname saddressp1 4mb simm 10 20 s1 CMM Newcastlep1 4mb simm 10 20 s4 INGRAM Redcarp2 850mb HD 175 249 s1 CMM Newcastlep3 1gb HD 199 278 s2 ABC Darlingtonp3 1gb HD 199 278 s5 Comp. R. Us Darlingtonp4 20” Mtr 699 899 s1 CMM Newcastlep4 20” Mtr 699 899 s2 ABC Darlingtonp4 20” Mtr 699 899 s5 Comp. R. Us Darlington
ENTITIES : PARTS, SUPPLIERS
RELATIONSHIP : many parts supplied by many suppliers.
PARTS SUPPLIERSsuppliedby
ER MODEL :
Example : Many PARTS supplied by Many SUPPLIERS
Section 09 ER Decomposition Of Many To Many 4
The relationship between PARTS and SUPPLIES cannot be directly mapped into tables because of the variable number of links.
Parts->Supplier Link Supplier->Parts Linkp1 s1, s4 s1 p1, p2, p4p2 s1 s2 p3, p4p3 s2, s5 s3p4 s1, s2, s5 s4 p1
s5 p3, p4
OCCURRENCE DIAGRAM :P#
p1
p2
p3
p4
S#
s1
s2
s3
s4
s5
Section 09 ER Decomposition Of Many To Many 5
PARTS SUPPLIERSsuppliedby
PART PART-SUPP SUPPLIER*
BECOMES
PARTp# pdesc cost rrpp1 4mb simm 10 20p2 850mb HD 175 249p3 1gb HD 199 278p4 20” Mtr 699 899
part-supp p# s# p1 s1 p1 s4 p2 s1 p3 s2 p3 s5 p4 s1 p4 s2 p4 s5
SUPPLIERs# sname saddresss1 CMM Newcastles2 ABC Darlingtons3 SIMMTECH Hartlepools4 INGRAM Redcars5 Comp. R. Us Darlington
* THE RELATIONSHIPS BECOME REDUNDANT * THE RELATIONSHIPS BECOME REDUNDANT ALL LINKAGE IS DONE THROUGH THE NEW ENTITY PART-SUPPALL LINKAGE IS DONE THROUGH THE NEW ENTITY PART-SUPP
*
Section 09 ER Decomposition Of Many To Many 6
staff#, lname, room, ext. student#, sname, saddressstaff# student#
LECTURER STUDENTlectures
LECTURER
L1L2L3L4L5L6
lectures STUDENT
S1S2S3S4
Sn
– Enterprise Rule :• ‘MANY LECTURERS LECTURES MANY STUDENTS• ‘MANY STUDENTS LECTURED by MANY LECTURER
– Occurrence Diagram :
• m:n MANY-to-MANY Relationship
Section 09 ER Decomposition Of Many To Many 7
staff#, lname, room, ext. student#, sname, saddressstaff# student#
LECTURER STUDENTlectures
LECTURER
L1L2L3L4L5L6
lectures STUDENT
S1S2S3S4
Sn
– Enterprise Rule :• MANY LECTURERS LECTURES MANY STUDENTS• MANY STUDENTS LECTURED by MANY LECTURER
– Occurrence Diagram :
Example : Many LECTURERS lectures Many STUDENTS
Section 09 ER Decomposition Of Many To Many 8
Skeleton Tables : Simple SolutionSkeleton Tables : Simple Solution
LECTURER(LECTURER(staff#staff#, lname, room, ext), lname, room, ext)
lectures(lectures(staff#staff#, , student#student#))
STUDENT(STUDENT(student#student#, sname, saddress), sname, saddress)
Populated Tables Populated Tables using links from occurrence diagram & sample data to show relationship)using links from occurrence diagram & sample data to show relationship)
LECTURERLECTURER lectureslectures DEPARTMENTDEPARTMENT
staff# lname room extstaff# lname room ext staff# student# staff# student# student# snamestudent# sname
L1 ALBERT A4 12L1 ALBERT A4 12 L1 S3L1 S3 S1 bloggsS1 bloggs
L2 BLOGGS B2 18L2 BLOGGS B2 18 L3 S1L3 S1 S2 jonesS2 jones
L3 COATES C1 22L3 COATES C1 22 L5 SnL5 Sn S3 greenS3 green
L4 GREEN A3 11L4 GREEN A3 11 L1 S2L1 S2 S4 smithS4 smith
L5 JONES D1 53L5 JONES D1 53 L1 S4L1 S4 Sn zuesSn zues
L6 SMITH A5 18 L6 SMITH A5 18 L1 S1L1 S1
L2 S1L2 S1
L3 S1L3 S1
Section 09 ER Decomposition Of Many To Many 9
Skeleton Tables : Foreign Key Solution (MS ACCESS)Skeleton Tables : Foreign Key Solution (MS ACCESS) m:n cannot be represented by foreign key importm:n cannot be represented by foreign key import MS ACCESS cannot map m:n relationshipsMS ACCESS cannot map m:n relationships
Populated Tables Populated Tables using links from occurrence diagram & sample data to show relationship)using links from occurrence diagram & sample data to show relationship)
LECTURERLECTURER STUDENTSTUDENT
staff# lname room ext student#staff# lname room ext student# student# sname staff student# sname staff
L1 ALBERT A4 12 S1, S2, S3, S4 S1 bloggs L1, L2, L3, L4L1 ALBERT A4 12 S1, S2, S3, S4 S1 bloggs L1, L2, L3, L4
L2 BLOGGS B2 18 S1 L2 BLOGGS B2 18 S1 S2 jones L1 S2 jones L1
L3 COATES C1 22 S1 L3 COATES C1 22 S1 S3 green L1S3 green L1
L4 GREEN A3 11 S1L4 GREEN A3 11 S1 S4 smith L1S4 smith L1
L5 JONES D1 53 Sn L5 JONES D1 53 Sn Sn zues L5Sn zues L5
L6 SMITH A5 18L6 SMITH A5 18
VARIABLE LENGTH RECORDS ARE GENERATED!!!VARIABLE LENGTH RECORDS ARE GENERATED!!!
SOLUTION - DECOMPOSE M:N to 1:M and M:1 SOLUTION - DECOMPOSE M:N to 1:M and M:1
Section 09 ER Decomposition Of Many To Many 10
staff#, student# staff#, student# staff#, student#
staff#, lname, room, ext
student#, sname
LECTURER
STUDENT
councelslecturers proj-supp
– We are able to map and model any number of relationships between entities.– Modelled below are the 3 different types of relationship covered in Section 04.– More entities can be linked to complete a data model of a system.
LECTURER STUDENT MODELLECTURER STUDENT MODEL
Section 09 ER Decomposition Of Many To Many 11
staff#, student# staff#, student# staff#, student#
staff#, lname, room, ext
student#, sname
LECTURER
STUDENT
councelslecturers proj-supp
FIRST CUT DATA MODEL : LECTURER STUDENTFIRST CUT DATA MODEL : LECTURER STUDENTm:n not decomposedm:n not decomposed
FIRST CUT TABLES : LECTURER STUDENTFIRST CUT TABLES : LECTURER STUDENTLECTURER (@staff#, lname, room, ext)LECTURER (@staff#, lname, room, ext)STUDENT (@student, sname)STUDENT (@student, sname)lectures (@staff#, @student#)lectures (@staff#, @student#)proj-spec (@staff#, @student#)proj-spec (@staff#, @student#)councels (@staff#, @student#)councels (@staff#, @student#)
Section 09 ER Decomposition Of Many To Many 12
staff#, student# staff#, student# staff#, student#
staff#, lname, room, ext
student#, sname
*
*
LECTURER
STUDENT
councelsproj-suppLECTURES
TABLES : LECTURER STUDENTTABLES : LECTURER STUDENTSimple SolutionSimple SolutionLECTURER (@staff#, lname, room, ext)LECTURER (@staff#, lname, room, ext)STUDENT (@student, sname)STUDENT (@student, sname)LECTURES (@staff#, @student#)LECTURES (@staff#, @student#)proj-spec (@staff#, @student#)proj-spec (@staff#, @student#)councels (@staff#, @student#)councels (@staff#, @student#)
TABLES : LECTURER STUDENTTABLES : LECTURER STUDENTUSING FOREING KEY DESIGNUSING FOREING KEY DESIGN LECTURER (@staff#, lname, room, ext)LECTURER (@staff#, lname, room, ext)STUDENT (@student, sname, proj-supp-STUDENT (@student, sname, proj-supp-staff#,staff#, councel-staff#)councel-staff#)LECTURES (@staff#, @student#)LECTURES (@staff#, @student#)
SECOND CUT LECTURER STUDENT MODELSECOND CUT LECTURER STUDENT MODEL m:n decomposedm:n decomposed
Section 09 ER Decomposition Of Many To Many 13
Customer (Customer_no, name, street, town, county, post_code)Car (reg_no, model, engine_size) Where would the data representing the date a car is hired out be held?As an attribute of Car? The identifier of Car is Reg_no. So, any reg_no can only
appear once in this entity. A car may be hired out many times so the reg_no would appear many times if Car had an attribute Date_out.
As an attribute of Customer? Does not make sense- the date a customer is hired out?
There is an entity missing. This is a typical feature of Many-many relationships
i.e. indicates incompleteness.
Example : Many CUSTOMERS hires Many CARS
Section 09 ER Decomposition Of Many To Many 14
Car
Customer
Contracts_for_a
Car
Customer
Current_ Contract
For_a
Takes_out_a
Entities Customer (Customer_no, name, street, town, county, post_code)
Car (reg_no, model, engine_size)
Current_Contract (reg_no, customer_no, date_out, date_in) • Identifier of new entity is a composite identifier made up from the identifiers of the two
original entities. • The new entity represents current contracts as a customer cannot hire the same car
again as the entity currently stands. • This new entity is now the home for the date_in, date_out attributes.• Note how the original participation conditions are preserved.
Section 09 ER Decomposition Of Many To Many 15
Entities Customer (Customer_no, name, street, town, county, post_code)
Car (reg_no, model, engine_size)
Contract (reg_no, customer_no, contract_date, date_out, date_in)
Adding a contract_date to the identifier of current_contract allows the same car to be hired to the same customer on a different date.
Car
Customer
Contract
For_a
Takes_out_a
Section 09 ER Decomposition Of Many To Many 16
Why does Decomposition work?
• A possible Entity Occurrence Diagram
AttendsPatient A&E Deptm m
PatientP3P7P21P5P17
A&E DeptAE4
AE29
AE3
Attends
Section 09 ER Decomposition Of Many To Many 17
• Giving each Attendance a unique number: – Each instance of a relationship between Patient and A&E Dept
PatientP3
P7
P21
P5
P17
A&E DeptAE4
AE29
AE3
AttendanceA3A1A6
A9A7
A8
• The Attendance Entity is revealed. A new Complex Entity.
Section 09 ER Decomposition Of Many To Many 18
The New Complex Entity
• Decomposing the original m:m relationship gives:
byPatient Attendance1 m m 1at A&E Dept
• Notice how easy and simple it is to name the two new relationships outwards from the Complex Entity.
• Also notice the pattern of the degree of association and membership class.
• Is decomposition easy? So where is the difficulty???
Section 09 ER Decomposition Of Many To Many 19
A Complex Entity Type Mapping Tool
• Decomposition of a many to many relationship type reveals a complex entity
– An entity with more than one attribute in its identifier. – It may be a simple entity type that has not been identified so far.– The new entity may be something obvious to a user but not to the data analyst or
equally something unfamiliar to both.
• You may be tempted simply to assign the complex entity a code or number as identifier, however:
– A complex entity always has a 'natural' composite identifier.– It is helpful to the understanding of a entity to know its ‘natural’ identifier even if we
eventually use a code instead.
• To use a complex entity in an ERD you need the following: ENTITY NAMEATTRIBUTESIDENTIFIER
DESCRIPTION
Section 09 ER Decomposition Of Many To Many 20
Example
• Appropriately name the new entity type.• Complex entity naming may be difficult.
– A weak name may initially be all that is possible at first such as Employee-Project. – An attempt should be made to find a 'good' name.
• Asymmetric viewing often provides useful clues– Something like "Assignment", "Task" or "Job" would hopefully be found.
Decompose the Many to Many relationship
Section 09 ER Decomposition Of Many To Many 21
Asymmetric Viewing Tool for Complex Entities (look both ways!)
• This is a Simple Tool to help in the mapping of complex entities
• The analyst often finds it difficult to decide what the complex entity represents in reality.
– Thus, in this example they cannot define an Assignment.– To put it another way, the analyst cannot say what it is a list of.– Using this tool the analyst examines the complex entity from the viewpoint of each
contributing entity in turn.
• Examining the diagram from the Employee viewpoint:– Assignment is a list of the projects that an employee is involved in and the roles
they have in those projects.
• Examining the diagram from the Project viewpoint:– Assignment is a list of the employees are involved in a project and the roles they
have in those projects.
Section 09 ER Decomposition Of Many To Many 22
Identifiers for Complex Entities
• Select appropriate identifier for the new entity type, often a composite of attributes.
– A composite of the Foreign Keys?
• For this example, [emp#,project#] seems appropriate at first. – Invent several new attributes for the new entity type. This aspect is essential.
• For example;
role, supervisor, hours-allocated, hours-so-far,
hours-required, date-started, finish-date.
• Asymmetric viewing is useful again in finding new attributes of the complex entity.
• For any entity type you wish to include in a database, you should be able to invent or observe appropriate attributes.
Section 09 ER Decomposition Of Many To Many 23
Checking the identifier of a Complex Entity• Draw up an appropriate relational table and create an example table
occurrence.– We have guessed that the identifier is [emp#, project#]
• Now simply invent a few reasonable rows using combinations of value of emp# and project# as instances of the identifier. An experiment!
– The experiment also works well with fewer attributes; just one additional attribute (other than the identifier) is usually sufficient.
• We then try to repeat one of the instances of the identifier in a new row.– We try to find out if different attribute values are possible for that row (illustrated
below in the first and last rows).
emp# Project# role Supervisor hrs-alloc hrs-so-far hrs-rec start-date finish-date
E2 P9 Program E123 120 85 100 01.06.93 11.11.93
E2 P4 Design E101 300 250 200 06.03.93 21.08.93E101 P9 Design E101 60 128 56 01.06.93 10.02.94E22 P11 Test E345 40 0 40 10.10.93 17.10.93E2 P9 test .. .. .. .. .. ..
It does not make sense to have the same assignment repeated with a different finish-date.
Section 09 ER Decomposition Of Many To Many 24
A ‘better’ Identifier
• The identifier [ emp#,project#] is clearly inadequate– It is possible that the same employee can have multiple roles on the same project.
• The identifier [ emp#,project#, role] now seems more sensible.
• Look at the new row below and work out why the above identifier is more appropriate.
emp# Project# Role supervisor
hrs-alloc
hrs-so-far hrs-rec start-date finish-date
E2 P9 program E123 120 85 100 01.06.93 11.11.93E2 P4 design E101 300 250 200 06.03.93 21.08.93
E101 P9 design E101 60 128 56 01.06.93 10.02.94E22 P11 test E345 40 0 40 10.10.93 17.10.93E2 P9 program E123 120 85 100 01.06.93 11.08.93
Section 09 ER Decomposition Of Many To Many 25
• Finally the entity can be documented as below:
ENTITY NAME Assignment
ATTRIBUTES emp#, project#, role, supervisor, hrs-alloc,
hrs-so-far, start-date, finish-date hrs-rec,
IDENTIFIER emp#,project#, role
DESCRIPTION etc.
• Repeat the process until your judgement is that the entity is well enough defined.
Never integrate an entity into a model if don't know it's identifier and some attributes
The Best Identifier??
Section 09 ER Decomposition Of Many To Many 26
• Consider the following identifiers for the 'Assignment' complex entity and their implications.
emp#,project#, role, start-date, supervisor, hrs-alloc, hrs-so-far, hrs-rec, finish-date
emp#,project#, start-date, role, supervisor, hrs-alloc, hrs-so-far, hrs-rec, start-date, finish-date
emp#,project#, role, sequence-number, supervisor, hrs-alloc, hrs-so-far, hrs-rec, start-date, finish-date
emp#,project#, sequence-number, role, supervisor, hrs-alloc, hrs-so-far, hrs-rec, start-date, finish-date
The sequence number simply implies a chronological order to an employee's assignments.
• The 'Assignment' problem solution is very general and other solutions are possible.– Perhaps an employee can be reassigned to a project for the same role (e.g. programming).
Section 09 ER Decomposition Of Many To Many 27
Summary
• Introduced Decomposition of m:m relationships to form Complex Entities.
• Explained that understanding Complex Entities can be difficult.
• Introduced Asymmetric Viewing (a long name for a simple idea).
• Showed that for any entity you need to know:
ENTITY NAME
ATTRIBUTES
IDENTIFIER
DESCRIPTION• Introduced a technique for verifying the identifiers of Complex Entities.
Section 09 ER Decomposition Of Many To Many 28
ERD SAMPLES
Ascent Resources
Ascent S/W and ERD Solutions
Installing Ascent At Home
Using Ascent - ER Modeling
Library of Free Data Models
Section 09 ER Decomposition Of Many To Many 29
End of Lecture
Top Related