Chapter 12

Entity-Relationship Modeling

Ahmed M. Zeki

ITIS 213
Objectives
 How to use Entity–Relationship (ER) modeling
in database design.
 Basic concepts associated with ER model.
 Diagrammatic technique for displaying ER
model using Unified Modeling Language
(UML).
 How to identify and resolve problems with ER
models called connection traps.
 How to build an ER model from a
requirements specification.

2 / 63
Introduction
 DB System Development Life Cycle
◦ Part of it:
 gather information about what the user require of a DB
system
 Analysis stage
 Documenting the requirement
 Next is the DB design stage
 Problem in DB design: designers,
programmers, and end users view data and
its use in different ways.

3 / 63
Introduction
 Hence we need to understand the nature of
the data and how it is used by the enterprise.
  We need to have a model for

communication that is non-technical and free

of ambiguities.
 The Entity-Relationship (ER) model is a top

down approach to DB design that begins by

identifying the important data called entities
and relationship between the data that must
be represented in the model. Then we add
attributes and constraints.
4 / 63
Introduction
 ER modeling is an important technique for
any DB designer to master and forms the
basis of the methodology.
 We will use a diagrammatic notation that uses

an increasingly popular OO modeling

language called the Unified Modeling
Language (UML) (Booch 1999).
 UML is the successor to a number of OO

analysis and design methods introduced in

the 1980s.

5 / 63
Entity Types
 Entity type: a group of objects with the same
properties, which are identified by the
enterprise as having an independent
existence.

 Entity type is the basic concept of the ER

model.

6 / 63
Entity Types
 An entity type has an independent existence
and can be objects with a physical or real
existence or objects with a conceptual or
abstract existence.

7 / 63
Entity Types
 Entity Occurrence: Uniquely identifiable
object of an entity type.

 Each entity type is defined by a name and a
list of properties.

 A DB normally contains many different entity

types.
◦ Examples of entity types are in the following figure
includes: Staff, Branch, ProperyForRent, and
PrivateOwner.

8 / 63
Fig 11.1

9 / 63
Entity Types
 Diagrammatic representation of entity types:
◦ Each entity type is shown as a rectangle labeled
with the name of the entity, which is normally a
singular noun.
◦ In UML, the first letter of each word in the entity
name is upper case (for example, Staff and
PropertyForRent.

 ER diagram of Staff
and Branch entity
types

10 / 63
Relationship Types
 Relationship type is a set of meaningful
associations among entity types.
◦ Each relationship type is given a name that
describes its function.
◦ Example in Fig11.1: POwns, which associates the
PrivateOwner and ProperyForRent entities

 Relationship occurrence is a uniquely

identifiable association, which includes one
occurrence from each participating entity
type.

11 / 63
Relationship Types
 Consider a relationship type called Has, which
represents an association between Branch
and staff entities, that is Branch Has Staff.

 Each occurrence of the Has relationship

associates one Branch entity occurrence with
one Staff entity occurrence.

12 / 63
Relationship Types
 Semantic net is an object-level model, which
uses the symbol  to represent entities and
the symbol  to represent relationship.

 Semantic net
showing individual
occurrences of the
Has relationship
type
Each Relationships
relationship
Each Branch
describes
are represented
and Staff
an association
entity
by lines
occurrences
Difficult to understand due to the level of
of single
that join
Branch
is represented
eachentity
participating
occurrence
using values
Branch
withfor
entity
a their PK
details.
with
single
the
attributes,
Staff
associated
entity
namely
occurrence.
StaffbranchNo
entity. and staffNo
13 / 63
Relationship Types
 We can more easily represent the relationship
between entities in an enterprise using the
concepts of the ER model.

 ER model uses a higher level of abstraction

by:
◦ Combining sets of entity occurrences into entity
types, and
◦ Combining sets of relationship occurrences into
relationship types.

14 / 63
Relationship Types
 ER diagram of “Branch
Has Staff” relationship
 Each relationship type

is shown as a line
connecting the associated entity types,
labeled with the name of the relationship.
 Normally a relationship is named using

◦ a verb, e.g. supervises, manages, or

◦ a short phrase including a verb like leasedBy
 A relationship name should be unique for a
given ER model.
15 / 63
Relationship Types
 A relationship is only labeled in one direction,
which normally means that the name of the
relationship only makes sense in one
direction
 For example: Branch Has Staff makes more

sense than Staff Has Branch

 So once the relationship name is chosen, an

arrow symbol is placed beside the name

indicating the correct direction for a reader to
interpret the relationship name (e.g Branch
Has Staff)
16 / 63
Degree of a Relationship
 Degree of a Relationship: Number of
participating entities in relationship.
◦ Two is binary
◦ Three is ternary
Complex relationships
◦ Four is quaternary

 The entities involved in a particular

relationship type are referred to as
participants in that relationship.

17 / 63
Degree of a Relationship
 Examples of Binary relationships
◦ The Has relationship
 Two participants

◦ The POwns relationship

18 / 63
Degree of a Relationship
 Examples of Ternary relationships
◦ The Registers relationship

19 / 63
Diagrammatic representation of
Complex Relationships
 UML notation uses a diamond to represent
relationships with degrees higher than binary.

 Name of the relationship inside the diamond

(with no directional arrow).

20 / 63
Degree of a Relationship
 Examples of Quaternary (Degree 4) relationships
◦ The Registers relationship

21 / 63
Recursive Relationship
 A relationship type where the same entity
type participates more than once in different
roles (sometimes called unary).
◦ Example: Supervises
 The supervisor is also a member of staff
 The staff entity
type participates
twice in the
relationship:
 Supervisor
 Supervisee

Relationships may be given role names

to indicate the purpose that each
participating entity type plays in a
22 / 63
relationship.
Recursive Relationship
 Role names may also be used when two
entities are associated through more than
one relationship.

 Example: the Staff and

Branch entity types are
associated through two
distinct relationships
called Manager and Has
◦ The use of the
relationship clarifies the
purpose of each relationship. 23 / 63
Recursive Relationship
1. In the case of Staff Manages Branch
◦ A member of staff (Staff entity) given the role name
‘Manager’ manages a branch (Branch entity) given
the role name ‘Branch Office’.
2. In the case of Branch
Has Staff
◦ A branch, given the role
name ‘BranchOffice’ has
staff given the role name
‘Member of staff’.

 Role names are usually not

required if the function of the participating entities in
a relationship is unambiguous.
24 / 63
Attributes
 Attribute: a property of an entity or a
relationship type.
◦ Staff: staffNo, name, position, salary
◦ A relationship type that associates entities can also
have attributes similar to those of an entity type.

 Attribute domain: set of allowable values for

one or more attributes.
 Attributes may share a domain. E.g: Branch,

PrivateOwner, and BusinessOwner share the

same domain.

25 / 63
Simple & Composite Attributes
 Simple attribute: an attribute composed of a
single component with an independent
existence. Sometimes called atomic attribute.
◦ Can’t be further subdivided into smaller
components. E.g position, salary
 Composite attribute: attribute composed of
multiple components, each with an
independent existence.
◦ Can be further divided to smaller components with
an independent existence of their own.
 Ex: Address: street, city, postcode

26 / 63
Single-valued and Multi-valued
Attributes
 Single-valued attribute: holds a single value
for each occurrence of an entity type.
◦ Majority of attributes are single-valued

 Multi-valued attribute: Attribute that holds

multiple values for each occurrence of an
entity type.
◦ Eg. Branch can have multiple tel numbers

27 / 63
Derived Attributes
 Attribute that represents a value that is
derivable from value of a related attribute, or
set of attributes, not necessarily in the same
entity type.
◦ The value for the duration attribute of the Lease
entity is calculated from the rentStart and
rentFinish attributes also of the Lease entity type.
 In some cases the value of an attribute is
derived from the entity occurrences in the
same entity type.
◦ Ex: the total number of staff (totalStaff) attribute of
the Staff entity type can be calculated by counting
the total number of Staff entity occurrences. 28 / 63
Derived Attributes
 Derived attributes may also involve the
association of attributes of different entity
types.
◦ Ex: the attribute called deposit of the Lease entity
type. The vaule of the deposit attribute is calculated
as twice the monthly rent for a property. Therefore,
the value of the deposit attribute of the Lease entity
type is derived from the rent attribute of the
PropertyForRent entity type.

29 / 63
Keys: Candidate Key
 The minimal set of attributes that uniquely
identifies each occurrence of an entity type
◦ E.g branchNo
◦ Has a distinct value
◦ Can’t contain a null

 An entity may have more than one candidate

key

30 / 63
Keys: Primary Key
 The candidate key that is selected to uniquely
identify each occurrence of an entity type

 The choice of PK for an entity is based on:

◦ Considerations of attribute length
◦ The minimal number of attributes required
◦ The future certainty of uniqueness

 A candidate key which is not selected as a

primary key is called Alternate Key.

31 / 63
Keys: Composite Key
 A candidate key that consists of two or more
attributes
◦ Whose values together are unique for each entity
occurrence but not separately
◦ E.g propertyNo & newspaperName
 Because many properties are advertised in many
newspapers on a given date.

32 / 63
Representation of Attributes
For single valued attributes
there is no need to use tags.
For composite attributes, we
list the name of the
composite attribute followed
below and indented

First letter of each

attribute: lower case. 1st For multi valued attributes use
letter of subsequent the range of values available of
words: upper case attribute [min..max]

Partial Primary Key:

Alternate Key: For more complex DB systems
{PPK}: if it is part of a
{AK} we just display the PK 33 / 63
composite key
Strong and Weak Entity Types
 Strong Entity Type: an entity type that is not
existence-dependent on some other entity
type.
◦ Ex (Fig 11.1): Staff, Branch, PropertyForRent and
Client entities
◦ Characteristic: each entity occurrence is uniquely
identifiable using the PK attributes of that entity
type.
 Sometimes called:
◦ Parent entity
◦ Owner entity
◦ Dominate entity
34 / 63
Strong and Weak Entity Types
 Weak Entity Type: An entity type that is
existence-dependent on some other entity
type.
◦ Each entity occurrence can’t be uniquely identified
using only the attributes associated with that entity
type.
◦ Ex: Preference
 Sometimes called:
◦ Child entity
◦ Dependent entity
◦ Subordinate entity

35 / 63
Strong and Weak Entity Types

We can only uniquely identify

each preference through the
relationship that a preference
has with a client who is
uniquely identifiable using the
PK for the Client entity type,
namely clientNo

36 / 63
Attributes on Relationships
 Attributes can be assigned to relationships
 Eg. Advertises: associates the Newspaper and

PropertyForRent types
◦ To record the date the property was advertised and
the cost, we associate this information with the
Advertises relationships as attributes called
dateAdvert and cost,
rather than with the
Newspaper or the
PropertyForRent entity.
◦ Ex. Manages (Fig 11.1)
 mgrStartDate Dashed line
 bonus
37 / 63
Attributes on Relationships
 The presence of one or more attributes
assigned to a relationship may indicate that
the relationship conceals an unidentified
entity type.
◦ Ex. The presence of the dateAdvert and cost
attributes on the Advertises relationship indicates
the presence of an entity called advert.

38 / 63
Structural Constraints
 The constraints should reflect the restrictions
on the relationships as perceived in the real
world.
◦ Eg. A property must have an owner
◦ Each branch must have staff

 The main type of constraint on relationships

is called multiplicity.

39 / 63
Multiplicity
 The number (or range) of possible
occurrences of an entity type that may relate
to a single occurrence of an associated entity
type through a particular relationship.

 It constraints the way that entities are related.

 It is a representation of the policies or

business rules.

 It is important to ensure that all appropriate

constraints are identified and represented.
40 / 63
Constraints
 1 to 1 (1:1)
◦ A member of staff manages a branch
 One to many (1:*)
◦ A member of staff overseas properties for rent
 Many to many (*:*)
◦ Newspapers advertise properties for rent

 Not all integrity constraints can be easily

represented in an ER model.
◦ The requirement that a staff receives an additional
day’s holiday for every year of employment, may be
difficult to represent in the ER model.
41 / 63
1-1 Relationship
 Examine precisely
the relationship in
the semantic net.
 A staff can manage

0 or 1 branch
◦ Min= 1
 Each branch is
managed by 1 staff
◦ Max = 1
 Min1& Max1  1:1
We may choose a relationship name
that makes sense in either direction 42 / 63
1:* Relationships
 A staff can oversee
0 or more properties
◦ Max = many
 For properties there
is a max of 1 staff
  1:*

43 / 63
*:* Relationships

We may choose a relationship name

that makes sense in either direction 44 / 63
Multiplicity for Complex Relationships
 Number (or range)
of possible
occurrences of an
entity type in an
n-ary relationship
when other (n-1)
values are fixed.
◦ When Staff/Branch
val are fixed  0..*
◦ When Staff/Client
val are fixed  1..1
◦ When Client/Branch
◦ Val are fixed  1..1
45 / 63
Summary of Ways to Represent
Multiplicity Constraints

46 / 63
Structural Constraints
 Cardinality: describes maximum number of
possible relationship occurrences for an
entity participating in a given relationship
type.
◦ Cardinality of a binary relationship is what we
referred to as:
 1:1
 1:*
 *:*
◦ Cardinality of a relationship appears as the max
values for the multiplicity ranges on either side of
the relationship
47 / 63
Structural Constraints

48 / 63
Structural Constraints
 Participation: Determines whether all or
only some entity occurrences participate in
a relationship
◦ If all  called mandatory participation
◦ If some  called optional participation

 The participation of entities in a relationship

appears as the min values for the multiplicity
ranges on either side of the relationship.

49 / 63
Structural Constraints
 Optional participation is represented as a
minimum value of 0 while mandatory
participation is shown as a minimum value of
1.

 The participation for a given entity in a

relationship is represented by the min value
on the opposite side of the relationship, i.e.
the min value for the multiplicity beside the
related entity.

50 / 63
Structural Constraints
 Ex: the optional participation for the Staff
entity in the Manages relationship is shown
as a min value of 0 for the multiplicity beside
the Branch entity and the mandatory
participation for the Branch entity in the
Manages relationship
is shown as a min
value of 1 for the
multiplicity beside
the Staff entity.

51 / 63
Problems with ER Models
(Connection Traps)
 Occur due to misinterpretation of the
meaning of certain relationships

 Fan Trap: where a model represents a

relationship between entity types, but
pathway between certain entity occurrences is
ambiguous.

52 / 63
Problems with ER Models
(Connection Traps)
 May exist where two or more 1:* relationships
fan out from the same entity. A potential fan
trap shows two 1:*

53 / 63
Problems with ER Models
(Connection Traps)
 This model represents the facts that a single
division operates one or more branches and
has one or more staff.

 The problem arises when we want to know

which members of staff work at a particular
branch.
◦ Eg. At which branch office does staff number SG37
work?

54 / 63
Problems with ER Models
(Connection Traps)
 We are unable to give a specific answer based
on the current structure. We can only
determine that staff number SG37 works at
Branch B003 or B007.
 This inability to answer this question

specifically is the result of a fan trap

associated with the misrepresentation of the
correct relationships between the Staff,
Division, and Branch entities.
 We resolve this fan trap by restructuring the

original ER model to represent the correct

association between these entities.
55 / 63
Problems with ER Models
(Connection Traps)

 SG37 works at branch B003.

56 / 63
Problems with ER Models
(Connection Traps)
 Chasm Trap: where a model suggests the
existence of a relationship between entity
types, but pathway does not exist between
certain entity occurrences.

 May occur where there are one or more

relationships with a min multiplicity of zero
(optional participation) forming part of the
pathway between related entities.

57 / 63
Problems with ER Models
(Connection Traps)
 This model represents the facts that a single
branch has one or more staff who oversee
zero or more properties for rent.

 We also note that not all staff oversee

property, and not all properties are overseen
by a member of staff.

58 / 63
Problems with ER Models
(Connection Traps)
 A problem arises when we want to know
which properties are available at each branch.
◦ Eg. at which branch is property number PA14
available?
 We are unable to answer this question, as this
property is not yet allocated to a member of
staff working at a branch.
 The inability to answer this question is

considered to be a loss of information and is

the result of a chasm trap.
 As we know a property must be available at a

branch,.
59 / 63
Problems with ER Models
(Connection Traps)
 The multiplicity of both the Staff and
PropertyForRent entities in the Oversees
relationship has a minimum value of zero,
which means that some properties can’t be
associated with a branch through a member
of staff.

60 / 63
Problems with ER Models
(Connection Traps)

61 / 63
Problems with ER Models
(Connection Traps)
 Therefore to solve this problem, we need to
identify the missing relationship, which in
this case is the Offers relationship between
the Branch and PropertyForRent entities.
 This model ensures that, at all times, the

properties associated with each branch are

known, including properties that are not yet
allocated to a member of staff.
 If we now examine occurrences of the Has,

Oversees, and Offers relationship types, we

are now able to determine that property
number PA14 is available at branch B007.
62 / 63
Problems with ER Models
(Connection Traps)

63 / 63