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