Entity Relationship (ER) Modeling

Chapter 4
 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 reconcile conflicting goals
 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
 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
 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
The Attributes of the
STUDENT Entity
 Domains
 Attributes have a domain:

 The attribute’s set of possible values

 Attributes may share a domain

 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
The CLASS Table (Entity)
Components and Contents
Attributes
 Composite attribute

 Simple attribute

 Single-value attribute

 Multivalued attributes
A Multivalued Attribute
in an Entity
 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
Splitting the Multivalued
Attribute into New Attributes
Components of the
Multivalued Attribute
A New Entity Set Composed of a
Multivalued Attribute’s Components
 Derived Attributes
 Attribute whose value may be calculated
(derived) from other attributes

 Need not be physically stored within the

database

 Can be derived by using an algorithm

Depiction of a Derived Attribute
 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
 Connectivity and
Cardinality
 Connectivity
 Used to describe the relationship classification
 Cardinality
 Expresses the specific number of entity
occurrences associated with one occurrence
of the related entity
 Established by very concise statements
known as business rules
Connectivity and
Cardinality in an ERD
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
 Strong (Identifying) Relationships
 Related entities are existence-dependent
A Weak (Non-Identifying)
Relationship Between COURSE and
CLASS
A Weak Relationship
Between COURSE and CLASS
 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
A Strong (Identifying) Relationship
Between COURSE and CLASS
An Optional CLASS Entity in the Relationship
PROFESSOR teaches CLASS
COURSE and CLASS
in a Mandatory Relationship
 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
A Weak Entity in an ERD
A Weak Entity in a
Strong Relationship
 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
Three Types of Relationships
The Implementation
of a Ternary Relationship
Recursive Relationships
 Relationship can exist between
occurrences of the same entity set

 Naturally found within a unary

relationship
An ER Representation
of Recursive Relationships
The 1:1 Recursive Relationship
“EMPLOYEE is Married to
EMPLOYEE”
Implementation of the M:N
Recursive “PART Contains PART”
Relationship
Implementation of the 1:M “EMPLOYEE
Manages EMPLOYEE” Recursive
Relationship
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
Converting the M:N Relationship
into Two 1:M Relationships
The M:N Relationship
Between STUDENT and CLASS
A Composite Entity in
an ERD
 Entity Supertypes and
Subtypes
 Generalization hierarchy
 Depicts a relationship between a higher-level
supertype entity and a lower-level subtype
entity

 Supertype entity
 Contains shared attributes

 Subtype entity
 Contains unique attributes
Nulls Created by Unique
Attributes
A Generalization
Hierarchy
Disjoint Subtypes
 Also known as non-overlapping
subtypes

 Subtypes that contain a subset of

the supertype entity set

 Each entity instance (row) of the

supertype can appear in only one
of the disjoint subtypes

 Supertype and its subtype(s)

maintain a 1:1 relationship
The EMPLOYEE/PILOT
Supertype/Subtype Relationship
A Generalization Hierarchy
with Overlapping Subtypes
A Comparison of ER
Modeling Symbols
The Chen Representation
of the Invoicing Problem
The Crow’s Foot Representation
of the Invoicing Problem
The Rein85 Representation
of the Invoicing Problem
The IDEF1X Representation
of the Invoicing Problem
Developing an ER
Diagram
 Database design is an iterative
rather than a linear or sequential
process

 Iterative process

 Based on repetition of processes

and procedures
A Supertype/Subtype Relationship
A Supertype/Subtype Relationship
in an ERD
Components of the ER Model
The Completed Tiny College
ERD
The Challenge of
Database Design:
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 the focus of database design
Various Implementations
of a 1:1 Recursive Relationship
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
 Summary (continued)
 ER symbols are used to graphically depict the
ER model’s components and relationships
 ERDs may be based on many different ER
models
 Entities can also be classified as supertypes
and subtypes within a generalization
hierarchy
 Database designers are often forced to make
design compromises