section 1010 er problems and styles1 hsq - databases & sql and franchise colleges 10 er problems...
TRANSCRIPT
Section 10 10 ER Problems and Styles 1
HSQ - DATABASES & SQL
And Franchise Colleges
10 ER Problems and StylesBy MANSHA NAWAZ
Section 10 10 ER Problems and Styles 2
Introduction: Recursive Relationships
• Entities may have relationships with themselves:
• The Enterprise Rule:– A component may be composed of 0,1,m other components– A component may be part of 0,1 components
• This is called a Recursive relationship.
ComponentIs
composed of
m
1
Section 10 10 ER Problems and Styles 3
1:1 Recursive Relationships
• Enterprise rule:– A Twin has exactly one Twin.– The enterprise is the same in both
directions.
TwinIs
the twin of
1
1
• Very difficult - all other examples turn out to be twins of some kind.
• Can you think of another example??? ??
1
1
Section 10 10 ER Problems and Styles 4
1:1 Recursive Relationships - continued
• Another useful example
• Enterprise rule:– A Child has 0,1 Twins.– The enterprise rule is the same in
both directions.
ChildIs
the twin of
1
1
Operation Precedes / succeeds
1
1• Enterprise rule:
An Operation has 0,1 Preceding Operations.
An Operation has 0,1 Succeeding Operations.
• A linked list structure ...
• These three examples are particularly useful as most 1:1 recursives are an example of one of these.
Section 10 10 ER Problems and Styles 5
1:m Recursive Relationships
• Can you see a problem with this?
The boss has to manage themselves!
• Notice one ‘leg’ of the relationship has a role name.– This is very effective in making recursive relationships understandable.
• Enterprise rule:A employee manages 0,1,m employees
A employee is managed by exactly 1 employeeEmployee Manages
1
m
Manager
Section 10 10 ER Problems and Styles 6
1:m Recursive Relationships continued ...
• Enterprise rule:
A Major-component is composed of 0,1,m Minor-components
A Minor-component is part of 0,1 Major-components
• Here we can see the advantage of roles names.
Component Is part of1
m
Major-component
Minor-component
• Many end with non-obligatory membership class.
Section 10 10 ER Problems and Styles 7
m:m Recursive Relationships
• Enterprise rule:A Major-component is composed of 0,1,m Minor-components
A Minor-component is part of 0,1,m Major-components
• Decomposing ...
Component Is part ofmm
Major-component
Minor-component
• What do we need to do with m:m relationships?
Complex entity
Component
is
11
Major-component
Minor-component
in
mSub-
Componentm
Section 10 10 ER Problems and Styles 8
m:m Recursive Relationships continued ...
• Remember that when you have a complex entity you need to determine:– Name , Attributes, Primary Key (Identifier), Description
• This may be much more difficult for a recursive complex entity.– However, the is composed of model above is quite useful generally.– Some possible versions of the above as table types.
Sub-component(minor.component#, major.component#, quantity required, ..)
or ...
Sub-component(minor.component#, major.component#, assembly-sequence, ..)
Could the second one be used to represent written documents??
Component
is
11
Major-component
Minor-component
in
mSub-
Componentm
Section 10 10 ER Problems and Styles 9
Connection Traps
• So far modelling looks very attractive.– A powerful tool based around a simple diagramming technique.– However, there are some pitfalls for database designers.– Generally these pitfalls are due to wrongly interpreting the meaning of
relationships.– Poor design of complex entities usually results in significant connection trap
problems.
• Careful design of complex entities, together with an approach of working outwards from complex (transactional) entities helps to eliminate connection trap problems. (Work back from the money! - see below)
Cinema Film
at
1 mSeason
of
1m
Showing
inm
1
Section 10 10 ER Problems and Styles 10
Fan Traps
• In this version of the previous model can we:– Determine which Cinema and Film relates to a particular Showing?
• Can we:– Determine all the Showings in a particular Season?– Determine the Season for a particular Showing?
• We can:– Find the appropriate Cinema and Film for any Showing or Season.– We can only relate a Showing to all the Seasons in a particular Cinema.– We can only relate a Showing to all the Seasons for a particular Film.
• These are called Fan Traps.
Cinema Film
at
1 mSeason
of
1m
Showingin
m
1
of
m
1
Fan Trap Fan Trap
Section 10 10 ER Problems and Styles 11
Avoiding Fan Traps
• Does this version of the ERD avoid the previous problems?• So significant fan traps can be avoided by re-designing the relationships.• Again: Careful design of complex entities, together with an approach of
working outwards from complex (transactional) entities helps to eliminate connection trap problems. (Work back from the money!)
Cinema Film
at
1 mSeason
of
1m
Showing
inm
1
Section 10 10 ER Problems and Styles 12
Non-Significant Fan Traps
• Why don’t we care about the Fan Trap shown?
• Stars are related to all Seasons, Showings and Cinema where their Films are shown.
• All Seasons and Showings are related to all the Stars in the Film shown.
• It is not a trap at all. – These patterns often occur at the edges of ERDs.
FilmCinema
at
1 mSeason
of
1m
Showing
inm
1
Non-Significant Fan Trap
Star
inm
1
Actor
is1
m
Section 10 10 ER Problems and Styles 13
Chasm Traps
• This looks reasonable but has some hidden problems.– We would assume we can always find the regiment a soldier is in.
RegimentSoldierin
m 1Platoon
in
1m
SoldierS4
S11S3
S19S9S2S6
Platoon
P1
P2
P3
Regiment
R1
R2
• S2 is the Regimental Sergeant Major (not in a platoon) - which regiment is he in?– OOPS - you can tell him the system doesn’t know what regiment he is in…...
Section 10 10 ER Problems and Styles 14
Chasm Traps - Removing
• Usually such problems can be solved by re-designing the relationships or adding new relationships.
• The above solution, adding a new relationship, resolves this problem.– In another scenario a similar problem may be solved by just re-designing
(swapping around) the relationships.
RegimentSoldierm 1
Platoonin
1m
in
in
m 1
Section 10 10 ER Problems and Styles 15
All data model can be conveyed by Entity Relationship Diagram (ERD)All data model can be conveyed by Entity Relationship Diagram (ERD)
Commonly used structure is the NETWORK style ERD. Commonly used structure is the NETWORK style ERD.
Good ERDs should also try and utilises the following styles.Good ERDs should also try and utilises the following styles.
This section covers popular styleThis section covers popular style
ERD STYLES
Section 10 10 ER Problems and Styles 16
HIERARCHY STYLE ERDHIERARCHY STYLE ERD
LIVINGCREATURE
is a
PERSON
male type
MALE FEMALE
female
type
c#, cdesc
c#
c# c#
Section 10 10 ER Problems and Styles 17
SET TYPESET TYPE
EMPLOYEETYPEemp_type
Consider the entity employee and the following data set :
EMPLOYEReno ename esalary etype e1 Smith 12k lecturere2 Jones 12k lectueree3 Brown 7k deane4 Green 10k lecturer
EMPLOYER emp_type EMPLOYEE_TYPEeno ename esalary eno etypeno etypeno etype e1 Smith 12k e1 et1 et1 lecturere2 Jones 12k e2 et1 et2 dean e3 Brown 7k e3 et2e4 Green 10k e4 et1
EMPLOYEE
EMPLOYEE
We can ALSO map the above data into a set type ERD as follows :
Section 10 10 ER Problems and Styles 18
SET OPERATIONSET OPERATION
MALE
STAFF
sex
FEMALE ENGINEERING STAFF
STAFF
position
BUSINESS STAFF
S#, SNAME, SADDRESS, STEL
S# S#
S#, SNAME, SADDRESS, STEL
S# S#
UNION OBTAINED BY JOINING ALL DATA FROM SET TYPE TABLES. ie jjoin keys from MALE and FEMALE tables join keys from ENGINEERING and BUSINESS tables
UNION = SET(A)+SET(B) INTERSECTION OBTAINED BY SELECTING DATA WHICH ONLY EXISTS IN ALL SET TYPE TABLESie select all records which exist in both MALE and FEMALE tables select all records which exist in both ENGINEERING and BUSINESS tables
INTERSECTION = SET(A)-SET(B)
WE ARE THEREFORE ABLE TO USE SET THEORY TO OBTAIN SELECTIVE LISTS.
Section 10 10 ER Problems and Styles 19
SUB SETSUB SET
(decomposition)
FULLPROFESSORS
PROFESSORS
by rank
ASSOCIATEPROFESSORS
ASSISTANTPROFESSORS
P#, PNAME, PADDRESS, PTEL
P#P# P#
Section 10 10 ER Problems and Styles 20
ALTERNATIVEALTERNATIVE
SET MODELSET MODEL
FULL PROFESSORS
PROFESSORS
associate
ASSOCIATEPROFESSORS
ASSISTANTPROFESSORS
assistantfull
P#, PNAME, PADDRESS, PTEL
P# P# P#
Section 10 10 ER Problems and Styles 21
SUPERTYPES and SUB TYPESSUPERTYPES and SUB TYPES
A company operate cars, lorries and buses; furthermore these are the only typeA company operate cars, lorries and buses; furthermore these are the only typevehicles it operates. vehicles it operates.
Suppose we are developing a data model for this company.Suppose we are developing a data model for this company.
One possible solution would be to use SET TYPE (92) and One possible solution would be to use SET TYPE (92) and to have tables VEHICLE and VEHICLE TYPE to indicate CAR, LORRY or BUS.to have tables VEHICLE and VEHICLE TYPE to indicate CAR, LORRY or BUS.
VEHICLETYPEveh_type
VEHICLE veh_type VEHICLE_TYPEvno reg vno vtypeno vtypeno vtype V1 Smith V1 B B BUSV2 Jones V2 B C CAR V3 Brown V3 C L LORRYV4 Green V4 L
VEHICLE
Section 10 10 ER Problems and Styles 22
However each vehicle type in reality requires different attributes. However each vehicle type in reality requires different attributes. ie A bus would require passenger capacityie A bus would require passenger capacity A lorry would require tonnage and no’ of axlesA lorry would require tonnage and no’ of axles
Furthermore each of the vehicle types may require different relationship Furthermore each of the vehicle types may require different relationship participation. participation.
ie BUS services a ROUTEie BUS services a ROUTE EMPLOYEE keeps a CAREMPLOYEE keeps a CAR EMPLOYEES can drive VEHICLES EMPLOYEES can drive VEHICLES
A SOLUTION WOULD BE TO USE THE ALTERNATIVE SET MODEL (95)A SOLUTION WOULD BE TO USE THE ALTERNATIVE SET MODEL (95)
THE MODEL BELOW IS WITHOUT THE DIAMOND NOTATION THE MODEL BELOW IS WITHOUT THE DIAMOND NOTATION
IT MAKES USE OF SUPERTYPES & SUB TYPESIT MAKES USE OF SUPERTYPES & SUB TYPES
Section 10 10 ER Problems and Styles 23
VEHICLE
CAR LORRY BUS
EMPLOYEE ROUTE
keeps can drive is served by
ER MODEL - VEHICLESER MODEL - VEHICLES
REDRAW THE ABOVE ER DIAGRAM USING THE DIAMOND NOTATION.REDRAW THE ABOVE ER DIAGRAM USING THE DIAMOND NOTATION.
NOTE : THIS STYLE IS NOT MODELLED BY ASCENT
Section 10 10 ER Problems and Styles 24
Section 10 10 ER Problems and Styles 25
EXISTENCEEXISTENCE
DEPENDENCEDEPENDENCE
EMPLOYEE
emp - nok
NEXT OF KIN
E#, ENAME, EADDRESS, ETEL
NOK#, NOKNAME, NOKADDRESS, NOKTEL
E#, NOK#
PRECEDENCEPRECEDENCE
RELATIONSHIPRELATIONSHIP
ORDER
DESPATCH
order-despatch
O#, OTOTAL, ODATE
D#, DDATE
O#, D#
Section 10 10 ER Problems and Styles 26
WEAK ENTITY TYPEWEAK ENTITY TYPE
(OPTIONAL entities shown in double box)
EMPLOYEE
DEPENDENT
ID
E#, ENAME, EADDRESS, ETEL
D#, DNAME, DADDRESS, DTEL
E#, D#
NOTE : THIS STYLE IS NOT MODELLED BY ASCENT
Section 10 10 ER Problems and Styles 27
HIGH-LEVEL ENTITY TYPEHIGH-LEVEL ENTITY TYPE : Style 1
(relationship types defined on relationships)
PRODUCT CUSTOMERshipping
performed by
AGENT
SEE TERNARY RELATIONSHIP for improvements to above model.
‘Products are shipped to customer. Shipping is performed by a Shipping Agent.’
P#, Pname, Pdesc C#, Cname, Caddress, Ctel
A#, Aname, Aaddress, Atel
S#, Sdate
A#, S#
NOTE : THIS STYLE IS NOT MODELLED BY ASCENT
Section 10 10 ER Problems and Styles 28
HIGH-LEVEL ENTITY TYPEHIGH-LEVEL ENTITY TYPE : Style 2
(relationship types defined on relationships)
PRODUCT CUSTOMERshippingperformed by
AGENT
P#, Pname, Pdesc C#, Cname, Caddress, CtelP#, C# S#, A#S#, Sdate
A#, Aname, Aaddress, Atel
SEE TERNARY RELATIONSHIP for improvements to above model.
NOTE : THIS STYLE IS NOT MODELLED BY ASCENT
Section 10 10 ER Problems and Styles 29
TERNARY RELATIONSHIP TYPETERNARY RELATIONSHIP TYPE
(multi relationship types)
PRODUCT CUSTOMERshipping
AGENT
P#, Pname, Pdesc C#, Cname, Caddress, Ctel
A#, Aname, Aaddress, Atel
P# C#, A#
Section 10 10 ER Problems and Styles 30
SHIPPING
shipmentPRODUCT CUSTOMER
AGENT
C#, Cname, Caddress, CtelP#, Pname, Pdesc
A#, Aname, Aaddress, Atel
S#, Sdate
S#, P#, C#, A#
NOTE : THIS STYLE IS NOT MODELLED BY ASCENT
QUAD RELATIONSHIP TYPEQUAD RELATIONSHIP TYPE
Section 10 10 ER Problems and Styles 31
RECURSIVE RELATIONSHIP TYPERECURSIVE RELATIONSHIP TYPE(mapping onto one entity types)
EMPLOYEE
manages
E#, ENAME, EADDRESS, ETEL
managerE#, workerE#
NOTE : THIS STYLE IS NOT MODELLED BY ASCENT
SEE BINARY relationship to model this in ASCENT..
TEAM plays
Section 10 10 ER Problems and Styles 32
BINARY RELATIONSHIPSBINARY RELATIONSHIPS
EMPLOYEE
MANAGER
supervise
(Used to improve recursive relationships.)
E#, ENAME, EADDRESS, ETEL
manager worker E# E#
manager E#
Section 10 10 ER Problems and Styles 33
BINARY RELATIONSHIPS using SUPER & SUB TYPES – Employee ExampleBINARY RELATIONSHIPS using SUPER & SUB TYPES – Employee Example
(Used to improve recursive relationships.)
EMPLOYEE
MANAGER WORKER
contracts
supervises
REDRAW THE ABOVE ER DIAGRAM USING THE DIAMOND NOTATION.REDRAW THE ABOVE ER DIAGRAM USING THE DIAMOND NOTATION.
NOTE : THIS STYLE IS NOT MODELLED BY ASCENT
Section 10 10 ER Problems and Styles 34
Section 10 10 ER Problems and Styles 35
TWO OR MORE RELATIONSHIPS BETWEEN ENTITIESTWO OR MORE RELATIONSHIPS BETWEEN ENTITIES
ITEM
CUSTOMER
returned by
sold to
I#, Iname, Idesc
C#, Cname, Caddress, Ctel.
I#, C#, Qty, date I#, C#, Qty, date
Section 10 10 ER Problems and Styles 36
ERD SAMPLES
Ascent Resources
Ascent S/W and ERD Solutions
Installing Ascent At Home
Using Ascent - ER Modeling
Library of Free Data Models
Section 10 10 ER Problems and Styles 37
End of Lecture