DAVID M. KROENKE’S
DATABASE CONCEPTS, 2nd Edition
Chapter Four
Data Modeling and the
Entity-Relationship Model
Chapter Objectives
• Learn the basic stages of database
development
• Understand the purpose and role of a data
model
• Know the principal components of the E-R data
model
• Understand how to interpret both traditional
and UML-style E-R diagrams
• Learn to construct traditional E-R diagrams
• Know how to represent 1:1, 1:N, N:M, and
binary relationships with the E-R model
DAVID M. KROENKE’S DATABASE CONCEPTS, 2nd Edition
© 2005 Pearson Prentice Hall
4-2
Chapter Objectives
(continued)
• Know how to represent recursive relationships
with the E-R model
• Understand two types of weak entities and
know how to use them
• Learn how to create an E-R diagram from
source documents
DAVID M. KROENKE’S DATABASE CONCEPTS, 2nd Edition
© 2005 Pearson Prentice Hall
4-3
Three Stages of Database
Development
• Requirements Stage
• Design Stage
• Implementation Stage
DAVID M. KROENKE’S DATABASE CONCEPTS, 2nd Edition
© 2005 Pearson Prentice Hall
4-4
The Requirements Stage
• Sources of requirements
– User Interviews
– Forms
– Reports
– Queries
– Use Cases
– Business Rules
DAVID M. KROENKE’S DATABASE CONCEPTS, 2nd Edition
© 2005 Pearson Prentice Hall
4-5
Requirements Become the
E-R Data Model
• After the requirements have been
gathered, they are transformed into
an Entity Relationship (E-R) Data
Model
• E-R Models consist of
– Entities
– Attributes
– Identifiers
– Relationships
DAVID M. KROENKE’S DATABASE CONCEPTS, 2nd Edition
© 2005 Pearson Prentice Hall
4-6
Entities
• An entity is something that users want
to track
– CUSTOMER
– PROJECT
– EMPLOYEE
– STUDENT
DAVID M. KROENKE’S DATABASE CONCEPTS, 2nd Edition
© 2005 Pearson Prentice Hall
4-7
Instance versus Classes
• An entity class is a description of the
structure and format of the
occurrences of the entity
• An entity instance of a specific
occurrence of an entity class
DAVID M. KROENKE’S DATABASE CONCEPTS, 2nd Edition
© 2005 Pearson Prentice Hall
4-8
Instance versus Classes
Entity
Class
CUSTOMER
CustID
CustName
12735
Smither, Inc
78124
Jackson Co.
Two
Entity
Instances
DAVID M. KROENKE’S DATABASE CONCEPTS, 2nd Edition
© 2005 Pearson Prentice Hall
4-9
Attributes
• Entities have attributes that describe
the entity’s characteristics
– ProjectName
– StartDate
– ProjectType
– ProjectDescription
• Attributes have a data type and
properties
DAVID M. KROENKE’S DATABASE CONCEPTS, 2nd Edition
© 2005 Pearson Prentice Hall
4-10
Identifiers
• Entity instances have identifiers
• An identifier will identify a particular
instance in the entity class
– SocialSecurityNumber
– StudentID
– EmployeeID
DAVID M. KROENKE’S DATABASE CONCEPTS, 2nd Edition
© 2005 Pearson Prentice Hall
4-11
Identifier Types
• Uniqueness
– Identifiers may be unique or nonunique
– If the identifier is unique, the data value for the
identifier must be unique for all instances
• Composite
– A composite identifier consists of 2 or more
attributes
• E.g., OrderNumber & LineItemNumber are both
required
DAVID M. KROENKE’S DATABASE CONCEPTS, 2nd Edition
© 2005 Pearson Prentice Hall
4-12
Relationships
• Entities can be associated with one
another in relationships
• Relationship degree defines the
number of entity classes participating
in the relationship
– Degree 2 is a binary relationship
– Degree 3 is a ternary relationship
DAVID M. KROENKE’S DATABASE CONCEPTS, 2nd Edition
© 2005 Pearson Prentice Hall
4-13
Degree 2 Relationship - Binary
LOCKER
DAVID M. KROENKE’S DATABASE CONCEPTS, 2nd Edition
© 2005 Pearson Prentice Hall
EMPLOYEE
4-14
Degree 3 Relationship - Ternary
DEALER
MODEL
MAKE
DAVID M. KROENKE’S DATABASE CONCEPTS, 2nd Edition
© 2005 Pearson Prentice Hall
4-15
One-to-One
Binary Relationship
• 1:1 (one-to-one)
– A single entity instance in one entity
class is related to a single entity instance
in another entity class
DAVID M. KROENKE’S DATABASE CONCEPTS, 2nd Edition
© 2005 Pearson Prentice Hall
4-16
One-to-One
Binary Relationship
• An employee may have no more than one
locker; and
• A locker may only be accessible by one
employee
LOCKER
DAVID M. KROENKE’S DATABASE CONCEPTS, 2nd Edition
© 2005 Pearson Prentice Hall
1:1
EMPLOYEE
4-17
One-to-Many
Binary Relationship
• An employee may only work for one
department; and
• A department has several employees
DEPARTMENT
DAVID M. KROENKE’S DATABASE CONCEPTS, 2nd Edition
© 2005 Pearson Prentice Hall
1:N
EMPLOYEE
4-18
Many-to-Many
Binary Relationship
• An employee may have several skills; and
• A particular skill may be held by several
employees
SKILL
DAVID M. KROENKE’S DATABASE CONCEPTS, 2nd Edition
© 2005 Pearson Prentice Hall
N:M
EMPLOYEE
4-19
One-to-Many
Unary Relationship
• An employee may be managed by one
other employee
• A employee may manage several
employees
EMPLOYEE
DAVID M. KROENKE’S DATABASE CONCEPTS, 2nd Edition
© 2005 Pearson Prentice Hall
1:N
4-20
Cardinality
• Each of the three types of binary
relationships shown above have
different maximum cardinalities
• Minimum cardinalities also exist.
These values typically assume a
value of Mandatory (one) or Optional
(zero)
DAVID M. KROENKE’S DATABASE CONCEPTS, 2nd Edition
© 2005 Pearson Prentice Hall
4-21
One-to-One Binary Relationship
with Minimum Cardinality
• An employee must have one locker; and
• A locker may be accessible by one or zero
employees
LOCKER
|
DAVID M. KROENKE’S DATABASE CONCEPTS, 2nd Edition
© 2005 Pearson Prentice Hall
1:1
0
EMPLOYEE
4-22
Weak Entity
• A weak entity is an entity that cannot exist
in the database without the existence on
another entity
• For example, an employee’s dependents
cannot exist in a database without the
employee existing in the database
EMPLOYEE
|
DAVID M. KROENKE’S DATABASE CONCEPTS, 2nd Edition
© 2005 Pearson Prentice Hall
1:N
0
DEPENDENT
4-23
ID-Dependent Weak Entities
• An ID-Dependent weak entity is a
weak entity that must include the
identifier of its parent entity as part of
its composite primary key
BUILDING
|
DAVID M. KROENKE’S DATABASE CONCEPTS, 2nd Edition
© 2005 Pearson Prentice Hall
1:N
0
APARTMENT
4-24
Weak Entity Identifier:
Non-ID-dependent
• A non-ID-dependent weak entity may
have a single or composite identifier,
and the identifier of the parent entity
will be a foreign key
PATIENT
|
DAVID M. KROENKE’S DATABASE CONCEPTS, 2nd Edition
© 2005 Pearson Prentice Hall
1:N
0 PERSCRIPTION
4-25
Weak Entity Identifier:
ID-Dependent
• An ID-dependent weak entity has a
composite identifier
– The first part of the identifier is the
identifier for the strong entity
– The second part of the identifier is the
identifier for the weak entity itself
PROJECT
|
DAVID M. KROENKE’S DATABASE CONCEPTS, 2nd Edition
© 2005 Pearson Prentice Hall
1:N
0
ASSIGNMENT
4-26
Weak Entity Relationships
• The relationship between a strong
and weak entity is termed an
identifying relationship if the weak
entity is ID-dependent
• The relationship between a strong
and weak entity is termed a nonidentifying relationship if the weak
entity is non-ID-dependent
DAVID M. KROENKE’S DATABASE CONCEPTS, 2nd Edition
© 2005 Pearson Prentice Hall
4-27
Unified Modeling Language
Entity-Relationship Diagrams
• Unified Modeling Language (UML) is
a set of structures and techniques for
modeling and designing objectoriented programs (OOP) and
applications
DAVID M. KROENKE’S DATABASE CONCEPTS, 2nd Edition
© 2005 Pearson Prentice Hall
4-28
Unified Modeling Language
Entities
ENTITY_NAME
List of Attributes
Identifier
DAVID M. KROENKE’S DATABASE CONCEPTS, 2nd Edition
© 2005 Pearson Prentice Hall
4-29
Unified Modeling Language
Relationships
1..1
Mandatory One
0..1
Optional One
0..*
Optional Many
1..*
Mandatory Many
DAVID M. KROENKE’S DATABASE CONCEPTS, 2nd Edition
© 2005 Pearson Prentice Hall
4-30
UML E-R Diagram Example
• An employee must report to one
department; and
• A department may have zero or many
employees
EMPLOYEE
EmployID
EmployName
Phone
EmployID is identifier
DAVID M. KROENKE’S DATABASE CONCEPTS, 2nd Edition
© 2005 Pearson Prentice Hall
DEPARTMENT
0..*
DeptID
1..1 DeptName
Location
DeptID is identifier
4-31
UML Weak Entity
EMPLOYEE
EmployID
EmployName
Phone
EmployID is identifier
DAVID M. KROENKE’S DATABASE CONCEPTS, 2nd Edition
© 2005 Pearson Prentice Hall
DEPENDENT
1
0..N
DepSSN
DepName
DepAge
DepSSN is identifier
4-32
DAVID M. KROENKE’S
DATABASE CONCEPTS, 2nd Edition
End of Presentation on Chapter Four
Data Modeling and the
Entity-Relationship Model