LECTURE 3 - ERD

• Basic conventions and definitions

• Identifying Entities, Attributes and Relationships

• Intersection entity

• Multiple relationship

• Basic literature

• [Barker II] Barker R., CASE*Method: Entity Relationship Modelling, Addison-Wesley Pub. Comp., 1991

• Additional literature

• [Chen] Chen P.P., The entity-relationship modelling, ACM Transactions on Database Systems, 1976

• [De Marco] De Marco T. (1979) Structured analysis and system specification, Prentice Hall, Englewood Cliffs, NJ

• [Flynn] Flynn D.J., Fragoso Diaz O., Information Modelling, An International perspective, Prentice Hall, 1996

• [Martin] Martin J. (1989) Information Engineering, Prentice Hall, NJ

GHJ - PWR 1

INFORMATION MODELING

• Information modeling is an important activity in computer – based information systems development

• An information model concerns a part of an organization and its environment, representing the elements about which information is to be recorded and the way in which the information is to be processed

• Information models commonly take the form of an entity –relationship models, data flow diagrams and entity life histories.

GHJ - PWR 2

DATABASE DEVELOPING PHASES

GHJ - PWR 3

Construct conceptual model of mini world

Transformation of entity relationship modelto logical relational database

Normal Form Testing

Decision making about the Access Method and PhysicalStructure, e.g. Oracle, DB2, Informix

Tuning database

Mini world

These two phases will be the subject of our lecture

ENTITY RELATIONSHIP MODELING

Other structural methods of entity relationship modeling [De

Marco, Flynn, Martin, Yourdon]:

• Entity Relationship Modeling – IE, MAIN

• Logical data structure (LDS) – SSADM

• Conceptual data model (CDM) - MERISE

GHJ - PWR 4

Lecture based on:Barker R., CASE*Method: Entity Relationship Modelling,Addison-Wesley Pub. Comp., 1991

OBJECTIVES OF ENTITY RELATIONSHIP MODELING

• To provide an accurate model of information needs of an organization• which will act as a framework for:

• a development of a new or enhanced database of an information system.

• To provide a model independent• of any data storage and access method,

• to allow an objective design decision to be made about implementation techniques and coexistence with existing systems.

GHJ - PWR 5

WHAT ARE WE MODELING?

Information requirements, they support functional needs of an organization, knowledge about :

• organization and its environment

• organization actual states

• events from the past

• actions plan for the future

• organization rules and law

GHJ - PWR 6

BASIC TERMS

• Entity• type and instance

• identifier

• Attribute• attribute relationship cardinality

• attribute relationship optional

• Relationship• relationship constraints

• All methods correspond with the entity and attribute concepts.

GHJ - PWR 7

DEFINITION: ENTITY, ENTITY TYPE, ENTITY INSTANCE

• An entity represents an object of interest in an organization that may be real or abstract [Barker II, p. G1-3].

• An entity type represents a set or class of entities that share the same characteristics.

• An entity instance represents a particular entity that is a member of any entity set or class.

GHJ - PWR 8

EMPLOYEE/WORKER

The name for en entity must be one that represents a type or class of things that share the same characteristics. The name must be written in the singular form and shown in capital letters.

Mary Green, Paul Newman – these are two instances of this entity.

Entity type representation

Synonym to entity name

GHJ - PWR 9

INSTANCES OF THE REAL WORLD: CURRENT, FUTURE AND HISTORY

• Current: all rooms are associated with a hotel, but only some have one booking, and empty rooms are valid• Each hotel has its name• Each room has its number• Each booking has its indicator

• When we look at all bookings: current, past and future• Each room may have more

then one booking

Hotels Rooms Bookings

TYPE AND INSTANCE

• Entity, relationship, attribute and unique identifier are all definitions that represent a type or class of concept – not an instance

• Information model must equally accurately apply to each and every instance of an object

HOTEL

# name* address line* category* description

ROOM

# number* type* position

BOOKING

# indicator* dateo comment

Entity type

Relationship type

Attributetype

ATTRIBUTE AND VALUE

• An attribute is any property of an entity instance.

• An attribute type represents a set or class of entity properties, it is a name.

• Attribute name of entity EMPLOYEE: name, date of birth, address, profession.

• An attribute value: Kowalski, 1980-08-10, Wrocław, singer.

GHJ - PWR 12

An attribute name

Attribute – is any detail that serves to qualify, identify, classify, quantify or express the state of an entity.orAny description of a thing of significance.

Could be: text, numbers, a picture, a smell … [Barker II, p. 3-8]

EMPLOYEE

# number* name* date of birth* professiono address

* - mandatory attributes –their value must always be known

o - optional attributes – theirvalue may not be available forsome time

Attribute definition and presentation

An attribute name should be written in the singular formand in lowercase letters.Do not use the entity name as part of the attribute name.

GHJ - PWR 13

SIMPLE OR COMPOSITE ATTRIBUTE?

GHJ - PWR 14

Attribute address is composed of elementary data: street number town country post code

Conflict with data normalization!

Each street may have more then one number,each town may have more then one street,each country may have more then one town and so on.

But it is normally practical to model sometimes a one to manyrelationship concept called address or address line

DERIVED ATTRIBUTE?

• These are attributes whose value is never set by a user – it must be calculated

For example: number of tickets, this value could be derived by

counting TICKET entity instances

• Depending on how the database is designed this new value may be calculated or recalculated:• either each time the derived attribute is used• or each time its value updates

• When defining business functions, the analyst can then quote derived attributes in order to simplify the complexity of function logic

GHJ - PWR 15

UNIQUE IDENTIFIER (UID) AND PRESENTATION

• Each entity must be uniquely identifiable so that each instance of the entity is separate and distinctly identifiable from all other instances of that type of entity. For example: personal number, car registration number, credit card number [Barker II, pp.3-11; 3-13].

• Unique Identifier (UID) must be simple or composite?

• UID in its simplest form is an single attribute

• A composite identifier is made up of

• two or more attributes,

• one or more entities across relationships

• a combination of attributes and entities across relationships

• An attribute which is a potential unique identifier must be mandatory

GHJ - PWR 16

EMPLOYEE

# number* name* date of birth* professiono addressUID mark # and a bar across

contributing relationship line

BUSINESS RELATIONSHIP

• A relationship type represents a significant association in an organization between entity types, or between an entity type and itself

• A relationship instance represents a significant association between instances of entity types in an organization

• A relationship has a name – it needs to be unique, as more than one relationship may exist between the same entity types

GHJ - PWR 17

DEGREE OF RELATIONSHIPS

The number of entity types participating in a relation

• unary – an association between an entity and itself, a recursive relationship

• binary (IE, SSADM, CASE*Method) equals to two

• n - ary (MAIN, MERISE) more than two

GHJ - PWR 18

Allow only relationship a maximum of binary degreeBoth ends must be defined

Unary and binary degree in CASE*Method

COMPANY within

made up of

COMPANY ACCOUNT

owner of

owned by

Unary degree: ‘many to one’ optional recursive relationship

Binary degree: one to many optional relationship

GHJ - PWR 19

N-ary relationship concept

Customer Ordercomplaint

Department

M N

P

[MEIN Method]

GHJ - PWR 20

RELATIONSHIP ATTRIBUTES

• A relationship attribute is an attribute which is associated with a relationship. For example, the date on which that relationship started.

• CASE*Method, SSADM does not allow relationship attributes.

GHJ - PWR 21

CARDINALITY CONSTRAINTS - HOW MANY?

• The cardinality constraints of entity A in relationship R(AB) define the number of instances of entity B which may be related to one instance of entity A.

• A possible cardinality

- one to one (1:1)

- one to many (1:M)

- many to one (M:1)

- many to many (M:N)

• 1, M or N – the maximum number of entity instances that may or must

occur in order to participate in the relationship [IE]

GHJ - PWR 22

PARTICIPATION (OPTIONAL) CONSTRAINTS –TOTAL OR PARTIAL?

• The participation constraint represents the minimum number of

entity instances that must occur in order to participate in the

relationship

• Mandatory (total) participation• where all instances of entity A must participate in the relationship with

instances of entity B, the participation of A in the relationship R(AB) is termedmandatory

• Optional (partial) participation• where some, not necessarily all, instances of entity A may participate in

relationship R(AB) is termed optional

GHJ - PWR 23

PRESENTATION STYLE OF CARDINALITY AND PARTICIPATION CONSTRAINTS

A style in relationship R(A,B)

• Look Across (L) – presentation of cardinality constraints orparticipation of entity type A on site B

• Look Here (participation - P) – presentation of cardinality constraints or participation of entity type A on site A

GHJ - PWR 24

M:N

1:1

Look Across style cardinality constraints [CASE*Method]

qualified degree

1:N/N:1

VOYAGEPROJECT

COMPANY ACCOUNT

PART/PRODUCT

PURCHASER SELLER<=2

Cardinality constraints

ORDER

one to many

one to one

many to many

many to many

GHJ - PWR 25

LOOK HERE STYLE OF PARTICIPATION CONSTRAINTS [CASE*METHOD]

GHJ - PWR 26

Method Style Participation constraintsA B mandatory B A optional

CASE*Method PPROJECT VOYAGE

Participation constraints

total partial

Look across style cardinality constraints [IE]

Company Account

Project Voyage

Part Order

M:N

1:N/N:1

1:1

GHJ - PWR 27

Look across style cardinality constraints [MEIN]

Part Order

Company Account

Project Voyage1 1

1 N

M N

GHJ - PWR 28

y – cardinality relationship parameter: {1,N}Participation style [MERISE]

Part Order

Company Account

Project Voyage(x,1) (x,1)

(x,N) (x,1)

(x,N) (x,N)

1:1

1:N/N:1

M:NGHJ - PWR 29

Company Account

Project Voyage

Part OrderM:N

1:N/N:1

1:1

Look across style cardinality constraints [SSADM]

Customerqualified degree

2Seller

GHJ - PWR 30

GRAPHICAL REPRESENTATION OF RELATIONSHIP PARTICIPATION CONSTRAINTS

GHJ - PWR 31

Method Style Participation constraintsA B mandatory B A optional

PROJECT JOB ORDERIE L

MEIN - not defined

MERISE P PROJECT JOB ORDER

(1,y) (0,y)

PROJECT JOB ORDERSSADM P

FORMAL SYNTAX TO READ ANY RELATIONSHIP[BARKER II, PP. 3-5]

GHJ - PWR 32

ENTITY A ENTITY Bend-name-1

end-name-2

Each (and every)ENTITY-A

must bemay be

end-name-1 one and only one one or more

ENTITY-B

and conversely:

Each (and every)ENTITY-B

must bemay be

end-name-2one and only oneone or more

ENTITY-A

VALID BINARY RELATIONSHIPS [CASE*METHOD]

GHJ - PWR 33

invalid

rare

occasionally

invalid

early on in analysis

very often

VALID RECURSIVE RELATIONSHIPS[CASE*METHOD]

GHJ - PWR 34

very often, show hierarchies, classifications,″pig’s ear″

rare, show an alternative

early on in analysis

impossible, this is an infinite loop

impossible

ENTITY DEFINITION SUMMARY

• By the end of detailed analysis the information requirement, represented by an entity, needs each entity to be associated with• at least two attributes

• at least one relationship

• at least one identifier

• at least one usage by business function

GHJ - PWR 35

INTERSECTION ENTITY [CASE*METHOD]

• Many to many (M:N) relationships will be common during an early strategy or analysis stages. By the end of the analysis stage they should all be resolved.

• Many to many relationships are ambiguous

• An intersection entity resolves a many to many (M:N) binary relationship by breaking it into two relationships 1:M and inserting a new entity type between the two ends

• An intersection entity also solves the problem of relationship attributes presentation

GHJ - PWR 36

RULES FOR INTERSECTION ENTITY CREATION [CASE*METHOD]

• The created entity must be named, as suggested, by establishing the noun from one of the original relationship names, sometimes descriptive attributes are added

• The instances of the resulting intersection entity can only exist in the context of the two reference entities

• The participation of the intersection entity is mandatory and its cardinality with the participating entities is M:1

• The identifier of the intersection entity is a combination of the participating entities identifiers

GHJ - PWR 37

RESOLVING A M:N RELATIONSHIP WITH AN INTERSECTION ENTITY

GHJ - PWR 38

EMPLOYEE TASKset to

set for

EMPLOYEE TASK

SETTING

a) before

b) after# date from* date to

# number # code

# code# number

many to many optional relationship

many to onemandatory relationship

UID of SETTING

one to many optional relationship

Intersection entity

Reference entity

MULTIPLE RELATIONSHIP

GHJ - PWR 39

A multiple relationship is a relationship between more than two entity types, which is regarded as a unit or combination that cannot be split for semantic reasons [Flynn, p.59]

Using n-ary concept• MEIN• MERISEUsing binary concept• IE• SSADM• CASE*Method Oracle

Customer Job Ordercomplaint

Department

M N

P

N-ary relationship concept to multiple relationship

There is a combination of the entities: that a given customer has complained to a certain department concerning a certain job order

[MEIN method, Flynn, p.61]

GHJ - PWR 40

Binary relationship concept with participating three entity types

1. The binary relationship between a customer and a job order can record the fact that customers C1 and C2 complain about job order J1.2. The binary relationship between a job order and a department can record the fact that job order J1 is related to departments D1 and D2.3. The binary relationship between a customer and a department cannot help as, for example, customer C1 may have complained to department D1 concerning another job order J3.

The information we wish to record concerns all participating entities as a unit,the combination cannot be split [Flynn, pp. 62-63].

many to many optional relationship

DEPARTMENT

CUSTOMER JOB ORDER

GHJ - PWR 41

MULTIPLE RELATIONSHIP MODELING USING BINARY RELATIONSHIP CONCEPT

• N-ary approach

• nested binary approach

GHJ - PWR 42

RULES FOR N-ARY APPROACH USE

• Create an abstract entity type – a combination entity.

• Its name should be a combination of all participating entities.

• The participation of the abstract entity is mandatory and its cardinality with the participating entities is N:1

• The identifier is a combination of the participating entities identifiers

[Flynn, p.63]

GHJ - PWR 43

The meaning of an instance of COMPLAINT is that one customer complainsabout one job order to one department.

The required information is recorded as an instance of CUSTOMER, who is associated with several instances of COMPLAINT, each instance of which is associated with one instance of JOB ORDER and one instance of DEPARTMENT [Flynn, p. 63].

COMPLAINT

DEPARTMENTCUSTOMER JOB ORDER

N-ary approach to multiple relationship modeling

The combination entityis built from:

many to one mandatory relationship

UID of COMPLAINT

GHJ - PWR 44

RULES FOR NESTED BINARY APPROACH USE

• Create an abstract entity type – it groups together two entities and forms an abstract entity.

• Its name should be their combination.

• The participation of the abstract entity is mandatory and its cardinality with the nested entities is N:1, and its cardinality with the unnested entity is M:N

• The identifier is a combination of the nested entities identifiers.

[Flynn, pp. 65-66]

GHJ - PWR 45

Nested binary approach to

multiple relationship modeling

CUSTOMER and JOB ORDER are nested to form an abstract entity CUSTOMER JOB ORDER, with the meaning of an unique combination of one customer complaining about one job order.Then related to the third entity DEPARTMENT using the unnested binary many to many relationship.

The required information is recorded as an instance of DEPARTMENT, which is associated withseveral instances of CUSTOMER JOB ORDER, each instance of which is associated with oneinstance of CUSTOMER and JOB ORDER.

[Flynn, pp. 65-66]

CUSTOMER JOB ORDER DEPARTMENT

CUSTOMER JOB ORDER

unnested relationship entity DEPARTMENT is M:N

UID of CUSTOMER JOB ORDER

many to one mandatory relationship

The combination entity is built from:

GHJ - PWR 46

CONVERSION FROM CASE*METHOD NOTATION INTO MSVISIO „CROW’S FOOT”

GHJ - PWR 47

Semantic element of

the model concept

CASE*Method - Look Across and Look Here

StyleMs Visio - Look Across Style

one and only one single solid line two bars at end of line

or single bar

zero or one dotted line hollow dot and one bar

one or more Crow’sfoot at the end of

the solid line

one bar and crow’sfoot

zero, one or more Crow’sfoot at the end of

the dotted line

hollow dot and crow’s

foot

relationship between

mutually exclusive

entity types

exclusive arc black dot

unique identifier # PK – Primary Key

mandatory or optional

attribute

small '*' or 'o’‚ in front of

the name

* type

o date

bold or normal font

identifying or non-

identifying relationship

one bar using Look

Here or none

solid line or dotted line