And Franchise Colleges
HSQ - DATABASES & SQL
09 ER Decomposition of Many-to-Many
Section 09
ER Decomposition Of Many To Many
1
Decomposition of a Many to Many Relationship
•
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 ....
Section 09
ER Decomposition Of Many To Many
2
Example : Many PARTS supplied by Many SUPPLIERS
p#
p1
p1
p2
p3
p3
p4
p4
p4
pdesc
4mb simm
4mb simm
850mb HD
1gb HD
1gb HD
20” Mtr
20” Mtr
20” Mtr
cost
10
10
175
199
199
699
699
699
ENTITIES :
rrp
20
20
249
278
278
899
899
899
s#
s1
s4
s1
s2
s5
s1
s2
s5
sname
CMM
INGRAM
CMM
ABC
Comp. R. Us
CMM
ABC
Comp. R. Us
saddress
Newcastle
Redcar
Newcastle
Darlington
Darlington
Newcastle
Darlington
Darlington
PARTS, SUPPLIERS
RELATIONSHIP : many parts supplied by many suppliers.
ER MODEL :
Section 09
PARTS
supplied
by
ER Decomposition Of Many To Many
SUPPLIERS
3
OCCURRENCE DIAGRAM :
P#
S#
p1
s1
p2
s2
p3
s3
p4
s4
s5
The relationship between PARTS and SUPPLIES cannot be directly mapped
into tables because of the variable number of links.
Parts->Supplier Link
p1
s1, s4
p2
s1
p3
s2, s5
p4
s1, s2, s5
Section 09
Supplier->Parts Link
s1
p1, p2, p4
s2
p3, p4
s3
s4
p1
s5
p3, p4
ER Decomposition Of Many To Many
4
supplied
by
PARTS
SUPPLIERS
BECOMES
PART
PART
p# pdesc
p1 4mb simm
p2 850mb HD
p3 1gb HD
p4 20” Mtr
Section 09
*
cost
10
175
199
699
rrp
20
249
278
899
PART-SUPP
part-supp
p# s#
p1 s1
p1 s4
p2 s1
p3 s2
p3 s5
p4 s1
p4 s2
p4 s5
*
SUPPLIER
s# sname
s1 CMM
s2 ABC
s3 SIMMTECH
s4 INGRAM
s5 Comp. R. Us
SUPPLIER
saddress
Newcastle
Darlington
Hartlepool
Redcar
Darlington
* THE RELATIONSHIPS BECOME REDUNDANT
ALL LINKAGE ER
IS Decomposition
DONE THROUGH
THE NEW ENTITY PART-SUPP 5
Of Many To Many
•
m:n MANY-to-MANY Relationship
staff#, lname, room, ext.
LECTURER
staff# student#
lectures
student#, sname, saddress
STUDENT
– Enterprise Rule :
• ‘MANY LECTURERS LECTURES MANY STUDENTS
• ‘MANY STUDENTS LECTURED by MANY LECTURER
– Occurrence Diagram :
LECTURER
lectures
L1
L2
L3
L4
L5
L6
STUDENT
S1
S2
S3
S4
Sn
Section 09
ER Decomposition Of Many To Many
6
Example : Many LECTURERS lectures Many STUDENTS
staff# student#
student#, sname, saddress
staff#, lname, room, ext.
LECTURER
lectures
STUDENT
– Enterprise Rule :
• MANY LECTURERS LECTURES MANY STUDENTS
• MANY STUDENTS LECTURED by MANY LECTURER
– Occurrence Diagram :
LECTURER
lectures
L1
L2
L3
L4
L5
L6
STUDENT
S1
S2
S3
S4
Sn
Section 09
ER Decomposition Of Many To Many
7

Skeleton Tables : Simple Solution
LECTURER(staff#, lname, room, ext)
lectures(staff#, student#)
STUDENT(student#, sname, saddress)


Populated Tables
using links from occurrence diagram & sample data to show relationship)
LECTURER
staff# lname
L1
ALBERT
L2
BLOGGS
L3
COATES
L4
GREEN
L5
JONES
L6
SMITH
Section 09
lectures
room ext
staff# student#
A4 12
L1
S3
B2 18
L3
S1
C1 22
L5
Sn
A3 11
L1
S2
D1 53
L1
S4
A5 18
L1
S1
L2
S1
S1Many
ER Decomposition OfL3
Many To
DEPARTMENT
student# sname
S1
bloggs
S2
jones
S3
green
S4
smith
Sn
zues
8



Skeleton Tables : Foreign Key Solution (MS ACCESS)
m:n cannot be represented by foreign key import
MS ACCESS cannot map m:n relationships


Populated Tables
using links from occurrence diagram & sample data to show relationship)
LECTURER
staff# lname
L1
ALBERT
L2
BLOGGS
L3
COATES
L4
GREEN
L5
JONES
L6
SMITH
room ext student#
A4 12 S1, S2, S3, S4
B2 18 S1
C1 22 S1
A3 11 S1
D1 53 Sn
A5 18
STUDENT
student# sname
S1
bloggs
S2
jones
S3
green
S4
smith
Sn
zues
staff
L1, L2, L3, L4
L1
L1
L1
L5
VARIABLE LENGTH RECORDS ARE GENERATED!!!
Section 09
SOLUTION - DECOMPOSE
M:N
to 1:M
ER Decomposition
Of Many
To and
ManyM:1
9
– 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 MODEL
staff#, lname, room, ext
LECTURER
staff#, student#
lecturers
staff#, student#
staff#, student#
proj-supp
councels
STUDENT
Section 09
student#,
ER Decomposition Of Many
To Manysname
10
FIRST CUT DATA MODEL : LECTURER STUDENT
m:n not decomposed
staff#, lname, room, ext
LECTURER
staff#, student#
lecturers
staff#, student#
staff#, student#
proj-supp
councels
STUDENT
student#, sname
Section 09
FIRST CUT TABLES : LECTURER STUDENT
LECTURER (@staff#, lname, room, ext)
STUDENT (@student, sname)
lectures (@staff#, @student#)
proj-spec (@staff#, @student#)
councels (@staff#, @student#)
ER Decomposition Of Many To Many
11
SECOND CUT LECTURER STUDENT MODEL
m:n decomposed
staff#, lname, room, ext
LECTURER
*
staff#, student#
staff#, student#
LECTURES
staff#, student#
proj-supp
councels
STUDENT
*
student#, sname
TABLES : LECTURER STUDENT
Simple Solution
LECTURER (@staff#, lname, room, ext)
STUDENT (@student, sname)
LECTURES (@staff#, @student#)
proj-spec (@staff#, @student#)
councels (@staff#, @student#)
Section 09
TABLES : LECTURER STUDENT
USING FOREING KEY DESIGN
LECTURER (@staff#, lname, room, ext)
STUDENT (@student, sname, proj-suppstaff#,
councel-staff#)
LECTURES (@staff#, @student#)
ER Decomposition Of Many To Many
12
Example : Many CUSTOMERS hires Many CARS
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.
Section 09
ER Decomposition Of Many To Many
13
Car
Car
For_a
Contracts
_for_a
Current_
Contract
Takes_
out_a
Customer
Entities
Customer
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.
Section 09
ER Decomposition Of Many To Many
14
• Note how the original participation conditions are preserved.
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
For_a
Contract
Takes_
out_a
Customer
Section 09
ER Decomposition Of Many To Many
15
Why does Decomposition work?
Patient
•
m
Attends
m
A&E Dept
A possible Entity Occurrence Diagram
Patient
P3
P7
P21
P5
P17
Section 09
Attends
A&E Dept
AE4
AE29
AE3
ER Decomposition Of Many To Many
16
•
Giving each Attendance a unique number:
– Each instance of a relationship between Patient and A&E Dept
Patient
P3
P7
Attendance
A3
A1
A6
A&E Dept
AE4
AE29
P21
A9
A7
P5
A8
AE3
P17
•
The Attendance Entity is revealed. A new Complex Entity.
Section 09
ER Decomposition Of Many To Many
17
The New Complex Entity
•
Decomposing the original m:m relationship gives:
Patient
1
by
m
Attendancem
at
1
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
18
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 NAME
ATTRIBUTES
IDENTIFIER
DESCRIPTION
Section 09
ER Decomposition Of Many To Many
19
Example
Decompose the Many to Many relationship
•
•
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.
Section 09
ER Decomposition Of Many To Many
20
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
21
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
22
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
E2
P9
Program
E123
120
85
100
finishdate
01.06.93 11.11.93
E2
E101
E22
E2
P4
P9
P11
P9
Design
Design
Test
test
E101
E101
E345
..
300
60
40
..
250
128
0
..
200
56
40
..
06.03.93 21.08.93
01.06.93 10.02.94
10.10.93 17.10.93
..
..
It does not make sense to have the same assignment repeated with a different finish-date.
Section 09
ER Decomposition Of Many To Many
23
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#
E2
E2
E101
E22
E2
Section 09
P9
P4
P9
P11
P9
superviso
r
E123
program
design
E101
design
E101
test
E345
E123
program
Role
hrsalloc
120
300
60
40
120
hrs-so-far
85
250
128
0
85
hrs-rec start-date finishdate
100
01.06.93 11.11.93
200
06.03.93 21.08.93
56
01.06.93 10.02.94
40
10.10.93 17.10.93
100
01.06.93 11.08.93
ER Decomposition Of Many To Many
24
The Best Identifier??
•
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
Section 09
ER Decomposition Of Many To Many
25
•
•
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).
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.
Section 09
ER Decomposition Of Many To Many
26
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
27
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
28
End of Lecture
Section 09
ER Decomposition Of Many To Many
29