1

Entity-Relationship Model
 Objectives
2

In this class, student will learn:

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

 E-R Model
3

 Entity-Relationship model is a set of concepts and graphical

symbols that can be used to create conceptual schemas.
 Versions
 Original E-R model — Peter Chen (1976).
 Extended E-R model — Extensions to the Chen model.
 Information Engineering (IE) — James Martin (1990); it uses
“crow’s foot” notation, is easier to understand.
 IDEF1X — A national standard developed by the National
Institute of Standards and Technology.
 Unified Modeling Language (UML) — The Object
Management Group; it supports object-oriented
methodology

 ER model forms the basis of an ER diagram

Chen Notation (Peter Chen)
4
Extended ER Model – Extension to Chen
5
Information Engineering (IE) — James
Martin (1990); it uses “crow’s foot”
6
notation
IDEF1X
7
UML NOTATION (WE WILL USE THIS NOTATION
FOR STID3014)
8
ER diagram of Branch view of DreamHome
9
 Concepts of the ER Model
10

ERDs depict the ER model’s three main components:

Entity types

Relationship types

Attributes
 Entity Type
11

 Entity type
 Group of objects with same properties, identified by
enterprise as having an independent existence.
 Something that can be identified and the users want to
track

 Entity occurrence/instance
 Uniquely identifiable object of an entity type.
Examples of Entity Types
12
 CUSTOMER:
The Entity Class and Two Entity Instances
13
 14

ER diagram of Staff and Branch entity types

 Exercise
15

Can you propose the ENTITIES and ATTRIBUTES for an

online game
 Online game: PUBG(??)
Entity & Attributes
16

Player entity: Match entity: Kill entity:

Player ID (Primary key) Match ID (Primary key) 1. Kill ID (Primary key)
Player name Game ID (Foreign key) 2. Match ID (Foreign key)
Match start time 3. Killer ID (Foreign key)
Email address
Match end time 4. Victim ID (Foreign key)
Password Match duration 5. Kill time
Current score Number of players 6. Weapon used
Total kills Inventory entity: Ranking entity:
Total deaths 1. Inventory ID (Primary key) 7. Ranking ID (Primary key)
Total matches played 2. Player ID (Foreign key) 8. Player ID (Foreign key)
Game entity: 3. Item name 9. Game ID (Foreign key)
4. Item quantity 10. Rank
Game ID (Primary key)
Weapon entity:
Game type (e.g., solo, duo,
5. Weapon ID (Primary key)
squad)
6. Weapon name
Game map 7. Weapon damage
Game duration 8. Weapon accuracy
Game result (e.g., win, loss, 9. Weapon range
draw)
 Relationship Types
17

 Relationship type
 Set of meaningful associations among entity types.

 Relationship occurrence
 Uniquely identifiable association, which includes one
occurrence from each participating entity type.
Semantic net of Has relationship type
18
ER diagram of Branch19Has Staff relationship
 Relationship Types
20

Degree of a Relationship
 Number of participating entities in relationship.

Relationship of degree :
 two is binary
 three is ternary
 four is quaternary.
Binary relationship called POwns
21

Two entities have a binary relationship of degree two.

 Ternary relationship called Registers
22

Three entities have a ternary relationship of degree three.

Quaternary relationship called Arranges
23
 Relationship Types
24
 Recursive relationship
 Relationship type where same entity type participates more than
once in different roles.
 occurs when an entity has a relationship to itself
 Relationships may be given role names to indicate purpose that
each participating entity type plays in a relationship.
 Eg. Person is Married to Person
Employee Manages Employee
Student rooms- with student
Recursive relationship called Supervises with role names
25
Entities associated through two distinct
relationships with
26
role names
 Attributes
27

Attribute
 Property of an entity or a relationship type.
 describe an entity’s characteristics.

Attribute Domain
 Set of allowable values for one or more attributes.

Attributescan be classified as being: simple or

composite; single-valued or multi-valued; or
derived.
 EMPLOYEE:
Attributes in Entity Rectangle
28

attribute
 Attributes
29

Simple Attribute
 Attribute composed of a single component with an
independent existence (e.g. position and salary of the
Staff entity).

Composite Attribute
 Attribute composed of multiple components, each with
an independent existence (e.g. the address attribute
that subdivided into street, city, and postcode
attributes).
 Attributes
30

Single-valued Attribute
 Attribute that holds a single value for each occurrence
of an entity type. The majority of attributes are single-
valued (eg. Matric no, IC No)

Multi-valued Attribute
 Attribute that holds multiple values for each
occurrence of an entity type (e.g. a Branch entity may
have more than one TelephoneNo attribute).
 Attributes
31

Derived Attribute
 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 (e.g. the duration attribute is
calculated from start and finish attributes)
 Example: age, given date_of_birth
 Keys
32

Candidate Key

 Minimal set of attributes that uniquely identifies each

occurrence of an entity type (e.g. branchNo attribute is
the candidate key for the Branch entity and has the
distinct value for each branch entity occurrence).

A candidate key cannot contain a null value

Primary Key
33

 Candidate key selected to uniquely identify each

occurrence of an entity type. (e.g. staffNo and TaxNo)

 The choice of primary key is based on:

 attribute length
 minimal number of attributes required
 future certainty of uniqueness

 Candidatekey that is not selected as primary key

known as alternate key.
Composite Key
34

A candidate key that consists of two or more attributes

(e.g. Advertisement entity has attributes of
propertyNo, newspaperName, dateAdvert and cost).
ER diagram of Staff and Branch entities and their attributes
35
 Entity Type
36
Strong Entity Type
 Entity type that is not existence-dependent on some other entity
type.
 characteristic: each entity occurrence is uniquely identifiable
using the primary key attribute.
 referred as parent, owner or dominant entities.
Weak Entity Type
 Entity type that is existence-dependent on some other entity type.
 characteristic: each entity occurrence cannot be uniquely
identified using only the attributes associated with that entity
types.
 referred as child, dependent, or subordinates entities.
Strong entity type called Client and weak entity type
called Preference
37
Relationship called Advertises with attributes
38
 Structural Constraints
39

Main type of constraint on relationships is called

multiplicity.
Multiplicity - 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.
Represents policies (called business rules)
established by user or company.
 Structural Constraints
40

The most common degree for relationships is

binary.
Binary relationships are generally referred to as
being:
 one-to-one (1:1)
 one-to-many (1:*)
 many-to-many (*:*)
Semantic net of Staff Manages Branch relationship type
41
Multiplicity of Staff Manages Branch (1:1) relationship
42
Semantic net of Staff Oversees PropertyForRent relationship type
43
 Multiplicity of Staff Oversees
PropertyForRent (1:*)
44 relationship type
Semantic net of Newspaper Advertises
PropertyForRent 45relationship type
Multiplicity of Newspaper Advertises
PropertyForRent (*:*)
46 relationship
 Structural Constraints
47

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.
Semantic net of ternary Registers relationship with
values for Staff and Branch entities fixed
48
Multiplicity of ternary Registers relationship
49
Summary of multiplicity constraints
50
 Structural Constraints
51

Multiplicity is made up of two types of restrictions on

relationships: cardinality and participation.

Cardinality
 Describes maximum number of possible relationship
occurrences for an entity participating in a given
relationship type.
Participation
 Determines whether all or only some entity
occurrences participate in a relationship.
Multiplicity as cardinality and participation constraints
52
 Problems with ER Models
53

Problems may arise when designing a conceptual

data model called connection traps.
Often due to a misinterpretation of the meaning of
certain relationships.
Two main types of connection traps are called fan
traps and chasm traps.
 Problems with ER Models
54

Fan Trap
 Where a model represents a relationship between entity
types, but pathway between certain entity occurrences is
ambiguous.
Chasm Trap
 Where a model suggests the existence of a relationship
between entity types, but pathway does not exist between
certain entity occurrences.
An Example of a Fan Trap
55
 Semantic Net of ER Model with Fan Trap
56

At which branch office does staff number SG37

work?
Restructuring ER model
57 to remove Fan Trap
Semantic Net of Restructured ER Model with Fan
Trap Removed
58

SG37 works at branch B003.

An Example of a Chasm Trap
59
Semantic Net of ER Model with Chasm Trap
60

At which branch office is property PA14

available?
ER Model restructured to remove Chasm Trap
61
Semantic Net of Restructured ER Model with Chasm Trap Removed
62
 63

The End

End of Presentation