hsq - databases & sql

Section 10 10 ER Problems and Styles 1

HSQ - DATABASES & SQL

And Franchise Colleges

10 ER Problems and StylesBy MANSHA NAWAZ


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


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


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.


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


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.


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


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


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


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


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


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


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…...


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


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


HIERARCHY STYLE ERDHIERARCHY STYLE ERD

LIVINGCREATURE

is a

PERSON

male type

MALE FEMALE

female

type

c#, cdesc

c#

c# c#


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 :


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.


SUB SETSUB SET

(decomposition)

FULLPROFESSORS

PROFESSORS

by rank

ASSOCIATEPROFESSORS

ASSISTANTPROFESSORS

P#, PNAME, PADDRESS, PTEL

P#P# P#


ALTERNATIVEALTERNATIVE

SET MODELSET MODEL

FULL PROFESSORS

PROFESSORS

associate

ASSOCIATEPROFESSORS

ASSISTANTPROFESSORS

assistantfull

P#, PNAME, PADDRESS, PTEL

P# P# P#


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


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


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


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#


WEAK ENTITY TYPEWEAK ENTITY TYPE

(OPTIONAL entities shown in double box)

EMPLOYEE

DEPENDENT

ID


D#, DNAME, DADDRESS, DTEL

E#, D#



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#



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


SEE TERNARY RELATIONSHIP for improvements to above model.



TERNARY RELATIONSHIP TYPETERNARY RELATIONSHIP TYPE

(multi relationship types)

PRODUCT CUSTOMERshipping

AGENT

P#, Pname, Pdesc C#, Cname, Caddress, Ctel


P# C#, A#


SHIPPING

shipmentPRODUCT CUSTOMER

AGENT

C#, Cname, Caddress, CtelP#, Pname, Pdesc


S#, Sdate

S#, P#, C#, A#


QUAD RELATIONSHIP TYPEQUAD RELATIONSHIP TYPE


RECURSIVE RELATIONSHIP TYPERECURSIVE RELATIONSHIP TYPE(mapping onto one entity types)

EMPLOYEE

manages


managerE#, workerE#


SEE BINARY relationship to model this in ASCENT..

TEAM plays


BINARY RELATIONSHIPSBINARY RELATIONSHIPS

EMPLOYEE

MANAGER

supervise

(Used to improve recursive relationships.)


manager worker E# E#

manager E#


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.



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


ERD SAMPLES

Ascent Resources

Ascent S/W and ERD Solutions

Installing Ascent At Home

Using Ascent - ER Modeling

Library of Free Data Models

http://www-scm.tees.ac.uk:8002/users/u0000589/ssaweb/ERD.HTM

http://www-scm.tees.ac.uk:8002/users/u0000589/ssaweb/ERD.HTM

http://www.databaseanswers.org/data_models/index.htm


End of Lecture

hsq - databases & sql

Documents

below10 er problems

employee10 er problems

recursive complex entity

recursive relationshipscan

componentsa component

meaning of relationships

complex transactional

particular season