Chapter 4

Entity Relationship (ER) Modeling

Database Systems:
Design, Implementation, and
Management
In this chapter, you will learn:

► How relationships between entities are defined and

refined, and how such relationships are incorporated
into the database design process

► How ERD components affect database design and

implementation

► How to interpret the modeling symbols for the four

most popular ER modeling tools

► That real-world database design often requires that

you resolve conflicting goals

2
The Entity Relationship (ER)
Model
► ER model forms the basis of an ER diagram
► ERD represents the conceptual database as viewed by end user
► ERDs depict the ER model’s three main components:
► Entities
► Attributes
► Relationships

3
Entities
► Refers to the entity set and not to a single entity occurrence
► Corresponds to a table and not to a row in the relational environment
► In both the Chen and Crow’s Foot models, an entity is represented by
a rectangle containing the entity’s name
► Entity name, a noun, is usually written in capital letters

4
Attributes
► Characteristics of entities
► In Chen model, attributes are represented by ovals and are
connected to the entity rectangle with a line
► Each oval contains the name of the attribute it represents
► In the Crow’s Foot model, the attributes are simply written in the
attribute box below the entity rectangle

5
The Attributes of the STUDENT Entity

6
 Domains
► Attributes have a domain: See e.g.
page 8…
► The attribute’s set of possible values

► A domain determines the type of data values that are permitted for
that attribute, and thus serves as an attribute constraint.

► E.g. Attribute domains can be very large (long company names), or

very short (such as the single-letter abbreviations for example S, M, L
can be used to indicate clothing sizes).

► Attributes may share a domain – e.g. address attribute for both Customer
& Agent can have similar type entries.
► Domain Types - SQL provides a number of domain types to assign to
attributes. The standard domain types include data values for characters,
numerals, currency, dates, times, and Boolean entries (a logical value of
either true or false).
► Choosing the correct domain type is critical to the accuracy of a
database.

7
 Domain: rules about what values are valid to attributes
●Database Systems: Design, Implementation, & Management, 6th Edition, Rob &
Coronel
8
Primary Keys

► Underlined in the ER diagram

► Key attributes are also underlined in frequently used table structure

shorthand

► Ideally composed of only a single attribute

► Possible to use a composite key:

► Primary key composed of more than one attribute

9
The CLASS Table (Entity)
Components and Contents

10
Attributes

11
12
A Multivalued Attribute in an Entity

13
 Resolving Multivalued Attribute
Problems
► Although the conceptual model can handle multivalued
attributes, you should not implement them in the
relational DBMS

► Within original entity, create several new attributes, one

for each of the original multivalued attribute’s
components
►Can lead to major structural problems in the table

► Create a new entity composed of original multivalued

attribute’s components

14
Splitting the Multivalued
Attribute into New Attributes

15
Components of the Multivalued Attribute

16
A New Entity Set Composed of a
Multivalued Attribute’s Components

17
Derived Attributes
► Attribute whose value may be calculated (derived) from other
attributes. E.g. Age can be derived from D.O.B or IC Number

► Need not be physically stored within the database

► Can be derived by using an algorithm

18
Relationships
► Association between entities
► Participants:
► Entities that participate in a relationship
► Relationships between entities always operate in both directions
► Relationship can be classified as 1:M
► Relationship classification is difficult to establish if you only know one
side

19
●Database Systems: Design, Implementation, & Management, 6th Edition, Rob &
Coronel
20
Connectivity and Cardinality
► Connectivity
► Used to describe the relationship classification
► Cardinality
► Expresses the minimum & maximum number of entity occurrences
associated with one occurrence of the related entity
► Established by very concise statements known as business rules

21
Connectivity and Cardinality in an ERD

22
RELATIONSHIP Strength
► Existence dependence
► Entity’s existence depends on the existence of one or more other entities
► Existence independence
► Entity can exist apart from one or more related entities
► Weak (non-identifying) relationships
► One entity is not existence-independent on another entity
► Exists if PK of related entity does not contain PK component of parent
entity
► Strong (Identifying) Relationships
► Related entities are existence-dependent
► Exists when PK of related entity contains PK component of parent entity

23
A Weak (Non-Identifying) Relationship
Between COURSE and CLASS

24
A Weak Relationship
Between COURSE and CLASS

No
CLASS_CODE

25
A Strong (Identifying) Relationship
Between COURSE and CLASS

26
Relationship Participation
► Optional:
► One entity occurrence does not require a corresponding entity occurrence
in a particular relationship

► Mandatory:
► One entity occurrence requires a corresponding entity occurrence in a
particular relationship

27
Relationship participation

28
An Optional CLASS Entity in the Relationship
PROFESSOR teaches CLASS

29
An Optional CLASS Entity in the
Relationship COURSE generates CLASS

30
COURSE and CLASS
in a Mandatory Relationship

31
Relationship Strength and
Weak Entities
► Weak entity meets two conditions
► Existence-dependent:
► Cannot exist without entity with which it has a relationship

► Has primary key that is partially or totally derived from the parent entity
in the relationship

► Database designer usually determines whether an entity can be

described as weak based on the business rules

Weak entities depend on some other entity type. They don't

have primary keys, and have no meaning in the diagram without their
parent entity.

32
A Weak Entity in an ERD

33
A Weak Entity in a Strong Relationship

34
Relationship Degree
► Indicates number of associated entities or participants
► Unary relationship
► Association is maintained within a single entity
► Binary relationship
► Two entities are associated
► Ternary relationship
► Three entities are associated

35
Three Types of Relationships

36
The Implementation
of a Ternary Relationship

37
Recursive Relationships

► Relationship can exist between occurrences of the same

entity set

► Naturally found within a unary relationship

38
An ER Representation of Recursive
Relationships (1:1, 1:M, M:N)

39
The 1:1 Recursive Relationship
“EMPLOYEE is Married to EMPLOYEE”

40
Implementation of the M:N Recursive
Relationship

41
Implementation of the 1:M “EMPLOYEE
Manages EMPLOYEE” Recursive Relationship

42
43
Composite Entities

► Also known as bridge entities

► Composed of the primary keys of each of the entities to

be connected

► May also contain additional attributes that play no role

in the connective process

44
Converting the M:N Relationship
into Two 1:M Relationships

45
The M:N Relationship
Between STUDENT and CLASS

46
A Composite Entity in an ERD

47
Developing an ER Diagram

► Database design is iterative rather than linear or

sequential process
► Iterative process
►Based on repetition of processes and
procedures – until user understands system flow

48
 Developing an ER Diagram

►Building an ERD usually involves the following

activities:
► Create detailed narrative of organization’s description of
operations (storyline)
► Identify business rules based on description of operations
► Identify main entities and relationships from business rules
► Develop initial ERD
► Identify attributes and primary keys that adequately
describe entities
► Revise and review ERD

49
 Developing an ER Diagram
► Tiny College
► Tiny College is divided into several schools
►Each school is composed of several departments
► Each department may offer courses
► Each department may have many professors assigned to it
► Each professor may teach up to four classes; each class is section of
course
► Student may enroll in several classes, but (s)he takes each class only
once during any given enrollment period
► Each department has several students
►Each student has only a single major and is associated with a single
department
► Each student has an advisor in his or her department
►Each advisor counsels several students
► The relationship between class is taught in a room and the room in the
building 50
Developing an ER Diagram

51
Developing an ER Diagram

52
Developing an ER Diagram

53
Developing an ER Diagram

54
Developing an ER Diagram

55
Developing an ER Diagram

56
Developing an ER Diagram

57
Developing an ER Diagram

58
Developing an ER Diagram

59
Developing an ER Diagram

60
Developing an ER Diagram

61
 Exercises: ERD

► Q1: Construct ERD for car insurance company whose

customers own one or more cars each. Each car has
associated with zero to any number of recorded
accidents.

► Q2: Construct an E-R diagram for a hospital with a set

of patients and a set of medical doctors. Associate with
each patient a log of the various tests and examinations
conducted.

●Database Systems: Design, Implementation, & Management, 6th Edition, Rob &
Coronel
62
Database Design Challenges:
Conflicting Goals

► Database design must conform to design standards

► High processing speeds are often a top priority in
database design
► Quest for timely information might be focus of
database design

63
Database Design Challenges:
Conflicting Goals (continued)

64
 Summary
► Entity relationship (ER) model
► Uses ER diagrams to represent conceptual database as viewed by the
end user
► Three main components
►Entities
►Relationships
►Attributes
► Includes connectivity and cardinality notations
► Connectivities and cardinalities are based on business rules
► ER symbols are used to graphically depict the ER model’s components and
relationships
► ERDs may be based on many different ER models
► Database designers are often forced to make design compromises
65