The Entity-Relationship

Model
MGIS 641

Koç University
 Learning objectives
● Define the terms, entity type, attribute, relationship,
cardinality, weak entity, gerund, generalisation, supertype,
subtype, inheritance
● Draw an entity-relationship (E-R) diagram to represent
common business situations
● Distinguish between unary, binary & ternary relationships
● Model multivalued attributes & repeating groups in an E-RD
● Model simple time-dependent data using time stamps in E-
RD
● Model ISA relationships in an E-RD
● Define four basic types of business rules in an E-RD
● List several advantages of locating business rules in the
repository, rather than in apps. programs
 Introduction
● E-R model remains the main stream approach for
conceptual data modeling
– relative ease of use
– CASE tool support
– Entities-relationships natural modeling way in the real world
● E-R model used as a tool for communication between
end-users & DB designers during analysis phase
– used to construct a conceptual data model - representation of
the structure of DB independent of DBMS S/W. row 3 of ISA IS
model
– Introduced by Chen no standard notation - evolving
DB development process
Planning

Enterprise data model

Analysis

Conceptual data model

Logical DB design

Logical data model

Physical DB design

Technology model

Implementation

DB & repositories
 Introduction to E-R model
● E-R model : A detailed, logical representation of the
entities, associations & data elements for an
organisation/business area
● An E-R model is normally expressed as an E-R
diagram which is a graphical representation of an E-R
model
– E-R model may also be used to represent enterprise data model a
well as conceptual data model (detailed E-RD)
– Major constructs of E-R D are entities, relationships & associated
attributes
 E-R notation
Basic symbols :

Entity Relationship
Primary keyAttributeMultivalued Gerund
attribute
Relationship degree :

Unary Binary
Ternary
elationship cardinality:
Mandatory 1 cardinality
ISA
Many(M) cardinality Class-subclass relationship
(1,2,.. ,many)

Optional 0 or 1 Exclusive
cardinality relationship
Optional zero-many
cardinality (0,1,2, ..., many)
 Entities
● Entity type (entity class): A collection of entities
that share common properties or characteristics
– e.g. Person : EMPLOYEE, STUDENT
Place : STATE, REGION, COUNTRY
Object : MACHINE, BUILDING
Event : SALE, REGISTRATION
Concept : ACCOUNT, COURSE
EMPLOYEE COURSE ACCOUNT

Entity Instance : A single occurrence of an entity type

Entity Type : EMPLOYEE Instance of EMPLOYEE
Attributes :EMPLOYEE NUMBER00-56-7778
NAME Ahmet Aslan
ADDRESS Cayir Cad. No.5
CITY Istinye
STATE Istanbul
ZIP 80860
 Attributes
● Attribute : A named property or characteristic of
an entity that is of interest to the organisation
– e.g. STUDENT : STUDENTNO., NAME, ADDRESS, PHONE NO.
AUTOMOBILE : VEHICLE ID, COLOUR, WEIGHT
EMPLOYEE : EMPLOYEE NO. , NAME, ADDRESS, SKILL

NAME SKILL
COLOUR
Candidate & primary keys
● Every entity type must have an attribute/set of
attributes that uniquely identifies each instance &
clearly distinguishes that instance from other
instances of the same type
● Candidate key : an attribute/combination of
attributes that uniquely identifies each instance of
an entity type
● e.g. STUDENT NO
Entity Type : GAME Entity Type : EMPLOYEE
Attributes Then EMPLOYEE No,
HOME TEAM NAME+ADDRESS => Candidate keys
VISITING TEAM
REFEREE
DATE
RESULT then HOME TEAM + VISTING TEAM =.> Candidate key
– Primary Key : A candidate key selected as the identifier
for an entity - may not be null
 Primary key selection
● Choose a candidate key which will not change its value
over the life of each instance of the entity type
– e.g. NAME+ADDRESS could change
● Choose a candidate key such that for each instance of
the entity, the attribute/combinations of attributes is
guaranteed to have valid values & not to be null
● e.g. GAME type DATE may be used but fixture may not
be ready
● Avoid the use of intelligent keys, whose structure
indicates classifications, locations ...
– e.g. first two digits may indicate warehouse location, but they
may change as the conditions change => invalid primary key
● Consider substituting single-attribute keys for large
composite
STUDENT NO keys
NAM ADDRESS PHONE NO
E
– e.g. HOME TEAM+VISITING TEAM => GAME NO
STUDENT
 Multivalued attributes
● Multivalued attribute : An attribute
that can have more than one value for each
entity instance
– During conceptual design highlight them
– Subsequently normalise entity data - remove
multivalued attributes & place them in a
separate entity type
ADDRESS SKILL
EMPLOYEE NO NAME

EMPLOYEE
 Relationships
● Relationship : An association between the
instances of one or more entity types that is of
interest to the organisation
– glue that holds the various E-R model components
together
– e.g. Registrar interested in tracking who has
completed what courses => relationship completes

STUDENT Completes COURSE

Many to many
 Relationships
STUDENT COURSE DATE
NO. TITLE COMPLETED
4545-5656 MGIS 641 JUNE 95
5676-7888 MGIS 641 SEPT 95
4545-5656 MGIS 642 OCT 94

Completed is not an attribute of STUDENT entity type since Student wi

4545-5656 has completed courses on different dates. It is not an attribu
RSE entity type since MGIS 641 may be completed on different dates.
a property of Completes relationship.

DATE COMPLETED

STUDENT Completes COURSE

 Degree of relationship
● Degree of a relationship : No. of
entities that participate in that relationship
– three common type of relationships
● Unary
● Binary

● Ternary

– e.g. Completes relationship between STUDENT &

COURSE is a degree two relationship as it involves two
entity types.
 Unary relationship
● Unary (recursive) relationship : relationship
between the instances of one entity type

is Has
PERSON married EMPLOYEE Manages ITEM Components
to

One-to-One One-to-many Many-to-many

QUANTITY
A B

V (1) X (1) Y (2) X (2) Y (1) Z (1)

U (3) V (2) U (3) V (2) V (1) W (2)

 Binary relationship
● Binary relationship : Relationship between the instances of
two entity classes.
– Most common type of relationship encountered

EMPLOYEE Is PARKING PLACE

Assigned

One-to-One
PRODUCT LINE Contains PRODUCT

One-to-many

STUDENT Registers COURSE

for
Many-to-many
 Ternary relationship
● Ternary relationship : Simultaneous relationship among the
entities of three entity types

QUANTITY

WAREHOUSE
VENDOR Ships

PART
 Gerunds
● Many-to-many relationships may have attributes
=> they may be entities in disguise
● Gerund (composite entity) : A many-to-many
relationship that a data modeler chooses to model
as an entity type with several associated one-to-
many relationships with other entity types
QUANTITY SHIPMENT NO

WAREHOUSE
VENDOR SHIPMENT

PART
 Gerunds
● In a binary relationship; relationship may be
represented as a gerund or entity
● For ternary/higher order relationships if any of
the relationships is not “many “ then
relationship cannot be shown as an entity

LOCATION ADMINISTER TREATMENT

Business rule :
PATIENT must always be
administered a given PATIENT
TREATMENT in the same
location

LOCATION ADMINISTER TREATMENT

lost business rule ! Three binary relationships <>

A ternary relationship
PATIENT
 Cardinalities in
relationships
● Cardinality : The number of instances of an
entity type that can (must) be associated with each
instance of any other entity type

MOVIE Is Stocked as MOVIE COPY

One-to-many
 Minimum & maximum
cardinalities
● Minimum cardinality : Minimum no. of instances
of an entity type that may be associated with each instance
of any other entity type
● Maximum cardinality : Maximum no. of instances
of an entity type that may be associated with each instance
of any other entity type

MOVIE Is Stocked as MOVIE COPY

max = one One-to-many

max = many
minimum = one minimum =0

(mandatory) (optional)
examples of cardinalities

PATIENT Has PATIENT HISTORY

Mandatory cardinalities

3
EMPLOYEE Is Assigned to PROJECT

One optional one mandatory

Is
PERSON married
to

Optional cardinalities
 Existence dependency
● Existence dependency : An instance of an entity
type cannot exist without the existence of an instance some
other (related) entity
– Existence dependency - result of mandatory one cardinality
● Weak entity : An entity type that has an existence
dependency

MOVIE Is Stocked as MOVIE COPY

 Identifying relationship
● Identifying relationship : A relationship in which the
primary key of the parent entity is used as part of
the primary key of dependent (child) entity

MOVIE NO MOVIE NAME MOVIE NO COPY NO

MOVIE Is Stocked as MOVIE COPY

Two benefits of an identifying relationship :

1) Data integrity. Existence dependencies are enforced since the prima
is shared - a weak entity cannot exist unless the parent entity exists
2) Ease of access of dependent entity. e.g. if Movie No + Copy No kno
movie copy can be located.
 Modeling multivalued
●
attributes
During later stages of conceptual design multi-
valued attributes are removed from the entities -
converted to a separate entity

ADDRESS SKILL
EMPLOYEE NO NAME

EMPLOYEE

ADDRESS SKILL NAME

EMPLOYEE NO NAME

EMPLOYEE Has SKILL

 Repeating groups
● Repeating Group : A Set of two or more multivalued
attributes that are logically related.
PATIENT CHART Date of Visit
Visit Physician Symptom
Patient No : 554545
1/5/96 Orkun Cold
Patient Name : OAY
2/5/96 Utku Fever
Address :K.U. Cayir Cd.
3/5/96 Arzu Soar Throat

NAME ADDRESS
PATIENT NO

PATIENT

DATE OF VISIT PHYSICIAN

SYMPTOM
 Repeating Group Removed

PATIENT NO NAME ADDRESS PATIENT NO

PATIENT Has PATIENT HISTORY

PHYSICIAN
DATE OF VISIT SYMPTOM
 Modeling Time Dependent Data
● Time Stamp : A time value that is associated
with any data value

PRICE EFFECTIVE DATE

PRODUCT NO

PRODUCT

PRICE EFFECTIVE DATE

PRODUCT NO

PRODUCT Has PRICE HISTORY

PRODUCT NO
 Generalisation
● Generalisation: The concept that some entities are subtypes of other more
general entities.
● Categorisation: The concept that the entity comes comes in various
subtypes.
● Supertype : A generic entity type that is subdivided into subtypes.
● Subtype : A subset of a supertype that shares common attributes.

NAME ADDRESS PHONE NO

EMPLOYEE NO

EMPLOYEE

ISA ISA

HRLY EMPLOYEE SLRD EMPLOYEE

EMPLOYEE NO HR RATE EMPLOYEE NO MTH LY

SALARY
● ISA Relationship : The relationship between each subtype and its supertype
● Exclusive relationship : The subtypes of a supertype are mutually
exclusive, and each instance of the supertype is categorised as exactly one subtype.
● Inheritance : When entity types are arranged in a hierarchy, each entity type
assumes the attributes and methods of its ancestors.(e.g. EMPLOYEE : SSN,
NAME , ADDRESS ; WORKER :SSN, DEPT ; MANAGER: SSN, TITLE)
● Exhaustive Subtype : (Not)All subtypes are defined for a supertype.
● Non-Exhaustive Subtype : Not all subtypes are defined for a supertype
● Non-Exclusive subtype : Subtypes may overlap, and an instance of of the
supertype may simultaneously belong to more than one subtype.
 Business Rules

● Business Rules : Specifications that preserve the integrity of the

logical data model.

1)Entity Integrity : Each instance of an entity type must have a non

Null unique identifier - Primary Key.

2)Referential Integrity Rules : Rules concerning the

relationships between entity types.

3) Domains: Constraints on valid values for attributes.

4) Triggering operations : Other business rules that protect the

validity of attribute values.

 Domains
● Domain : Set of values all data types and ranges of values an
attribute may assume.

AMOUNT DATE & TIME

PRODUCT NO

ACCOUNT WITHDRAWAL

BALANCE
Name: ACCT NO. Name : AMOUNT
Data Type : Text Data Type : Numeric
Format :AA-NNN Format :Fixed two decim
Uniqueness : Unique Uniqueness : Non-unique
Null : No null value Null : No null value
Range : 1M-20 M
 Triggering Operations
● Trigger : An assertion of a business rule that governs the validity
of data manipulation operations such as update , delete etc.

AMOUNT DATE & TIME

PRODUCT NO

ACCOUNT WITHDRAWAL

BALANCE
Rule: AMOUNT can not exceed ACCOUNT BALANCE
Event : Insert
Entity Name : WITHDRAWAL
Condition : AMOUNT > BALANCE
Action : Reject Transaction