David M. Kroenke and David J.

Auer
Database Processing
Fundamentals, Design, and Implementation

Chapter Five:
Data Modeling with the
Entity-Relationship Model

KROENKE AND AUER - DATABASE PROCESSING, 12th Edition © 2012 5-1

Pearson Prentice Hall
 Chapter Objectives
• To understand the two-phase data modeling/database
design process
• To understand the purpose of the data modeling process
• To understand entity-relationship (E-R) diagrams
• To be able to determine entities, attributes, and
relationships
• To be able to create entity identifiers
• To be able to determine minimum and maximum
cardinalities

KROENKE AND AUER - DATABASE PROCESSING, 12th Edition © 2012 5-2

Pearson Prentice Hall
 Chapter Objectives
• To understand variations of the E-R model
• To understand and be able to use ID-dependent and
other weak entities
• To understand and be able to use supertype/subtype
entities
• To understand and be able to use strong entity patterns
• To understand and be able to use the ID-dependent
association pattern
• To understand and be able to use the ID-dependent
multivalued attribute pattern

KROENKE AND AUER - DATABASE PROCESSING, 12th Edition © 2012 5-3

Pearson Prentice Hall
 Chapter Objectives
• To understand and be able to use the ID-dependent
archetype/instance pattern
• To understand and be able to use the line-item pattern
• To understand and be able to use the for-use-by pattern
• To understand and be able to use recursive patterns
• To understand the iterative nature of the data modeling
process
• To be able to use the data modeling process

KROENKE AND AUER - DATABASE PROCESSING, 12th Edition © 2012 5-4

Pearson Prentice Hall
 The Data Model
• A data model is a plan or blueprint for a
database design.
• A data model is more generalized and
abstract than a database design.
• It is easier to change a data model then it
is to change a database design, so it is the
appropriate place to work through
conceptual database problems.
KROENKE AND AUER - DATABASE PROCESSING, 12th Edition © 2012 5-5
Pearson Prentice Hall
 E-R Model
• Entity-Relationship model is a set of concepts and
graphical symbols that can be used to create conceptual
schemas.
• Versions:
– Original E-R model—by Peter Chen (1976)
– Extended E-R model—extensions to the Chen model
– Information Engineering (IE)—by James Martin (1990); it uses
“crow’s foot” notation, is easier to understand, and we will use it.
– IDEF1X—a national standard developed by the National Institute
of Standards and Technology [see Appendix B]
– Unified Modeling Language (UML)—by the Object Management
Group; it supports object-oriented methodology [see Appendix C]

KROENKE AND AUER - DATABASE PROCESSING, 12th Edition © 2012 5-6

Pearson Prentice Hall
 Entities
• Something that can be identified and the
users want to track:
– Entity class—a collection of entities of a
given type
– Entity instance—the occurrence of a
particular entity
• There are usually many instances of an
entity in an entity class.

KROENKE AND AUER - DATABASE PROCESSING, 12th Edition © 2012 5-7

Pearson Prentice Hall
 CUSTOMER:
The Entity Class and Two Entity Instances

KROENKE AND AUER - DATABASE PROCESSING, 12th Edition © 2012 5-8

Pearson Prentice Hall
 Attributes
• Attributes describe an entity’s
characteristics.
• All entity instances of a given entity class
have the same attributes, but vary in the
values of those attributes.
• Originally shown in data models as
ellipses.
• Data modeling products today commonly
show attributes in rectangular form.
KROENKE AND AUER - DATABASE PROCESSING, 12th Edition © 2012 5-9
Pearson Prentice Hall
 EMPLOYEE:
Attributes in Ellipses

KROENKE AND AUER - DATABASE PROCESSING, 12th Edition © 2012 5-10

Pearson Prentice Hall
 EMPLOYEE:
Attributes in Entity Rectangle

KROENKE AND AUER - DATABASE PROCESSING, 12th Edition © 2012 5-11

Pearson Prentice Hall
 Identifiers
• Identifiers are attributes that name, or identify, entity
instances.
• The identifier of an entity instance consists of one or
more of the entity’s attributes.
• Composite identifiers are identifiers that consist of two
or more attributes.
• Identifiers in data models become keys in database
designs.
– Entities have identifiers.
– Tables (or relations) have keys.

KROENKE AND AUER - DATABASE PROCESSING, 12th Edition © 2012 5-12

Pearson Prentice Hall
 Entity Attribute Display
in Data Models

KROENKE AND AUER - DATABASE PROCESSING, 12th Edition © 2012 5-13

Pearson Prentice Hall
 Relationships
• Entities can be associated with one another in
relationships:
– Relationship classes: associations among entity classes
– Relationship instances: associations among entity instances
• In the original E-R model, relationships could
have attributes, but today this is no longer done.
• A relationship class can involve two or more
entity classes.

KROENKE AND AUER - DATABASE PROCESSING, 12th Edition © 2012 5-14

Pearson Prentice Hall
 Degree of the Relationship
• The degree of the relationship is the number of
entity classes in the relationship:
– Two entities have a binary relationship of degree
two.
– Three entities have a ternary relationship of degree
three.

KROENKE AND AUER - DATABASE PROCESSING, 12th Edition © 2012 5-15

Pearson Prentice Hall
 Binary Relationship

KROENKE AND AUER - DATABASE PROCESSING, 12th Edition © 2012 5-16

Pearson Prentice Hall
 Ternary Relationship

KROENKE AND AUER - DATABASE PROCESSING, 12th Edition © 2012 5-17

Pearson Prentice Hall
 Entities and Tables
• The principle difference between an entity
and a table (relation) is that you can
express a relationship between entities
without using foreign keys.
• This makes it easier to work with entities in
the early design process where the very
existence of entities and the relationships
between them is uncertain.

KROENKE AND AUER - DATABASE PROCESSING, 12th Edition © 2012 5-18

Pearson Prentice Hall
 Cardinality
• Cardinality means “count,” and is
expressed as a number.
• Maximum cardinality is the maximum
number of entity instances that can
participate in a relationship.
• Minimum cardinality is the minimum
number of entity instances that must
participate in a relationship.
KROENKE AND AUER - DATABASE PROCESSING, 12th Edition © 2012 5-19
Pearson Prentice Hall
 Maximum Cardinality
• Maximum cardinality is the maximum
number of entity instances that can
participate in a relationship.
• There are three types of maximum
cardinality:
– One-to-One [1:1]
– One-to-Many [1:N]
– Many-to-Many [N:M]

KROENKE AND AUER - DATABASE PROCESSING, 12th Edition © 2012 5-20

Pearson Prentice Hall
 The Three Types of
Maximum Cardinality

KROENKE AND AUER - DATABASE PROCESSING, 12th Edition © 2012 5-21

Pearson Prentice Hall
 Parent and Child Entities
• In a one-to-many relationship:
– The entity on the one side of the relationship is called
the parent entity or just the parent.
– The entity on the many side of the relationship is
called the child entity or just the child.
• In the figure below, EMPLOYEE is the parent
and COMPUTER is the child:

KROENKE AND AUER - DATABASE PROCESSING, 12th Edition © 2012 5-22

Pearson Prentice Hall
 HAS-A Relationships
• The relationships we have been
discussing are known as HAS-A
relationships:
– Each entity instance has a relationship with
another entity instance.
• An EMPLOYEE has one or more COMPUTERs.
• A COMPUTER has one assigned EMPLOYEE.

KROENKE AND AUER - DATABASE PROCESSING, 12th Edition © 2012 5-23

Pearson Prentice Hall
 Minimum Cardinality
• Minimum cardinality is the minimum number of
entity instances that must participate in a
relationship.
• Minimums are generally stated as either zero or
one:
– IF zero [0] THEN participation in the relationship by
the entity is optional, and no entity instance must
participate in the relationship.
– IF one [1] THEN participation in the relationship by
the entity is mandatory, and at least one entity
instance must participate in the relationship.

KROENKE AND AUER - DATABASE PROCESSING, 12th Edition © 2012 5-24

Pearson Prentice Hall
 Indicating Minimum Cardinality
• As shown in the examples in a following
slide:
– Minimum cardinality of zero [0] indicating
optional participation is indicated by placing
an oval next to the optional entity.
– Minimum cardinality of one [1] indicating
mandatory (required) participation is
indicated by placing a vertical hash mark
next to the required entity.

KROENKE AND AUER - DATABASE PROCESSING, 12th Edition © 2012 5-25

Pearson Prentice Hall
 Reading Minimum Cardinality
• Look toward the entity in question:
– IF you see an oval THEN that entity is
optional (minimum cardinality of zero [0]).
– IF you see a vertical hash mark THEN that
entity is mandatory (required) (minimum
cardinality of one [1]).

KROENKE AND AUER - DATABASE PROCESSING, 12th Edition © 2012 5-26

Pearson Prentice Hall
 The Three Types of
Minimum Cardinality

KROENKE AND AUER - DATABASE PROCESSING, 12th Edition © 2012 5-27

Pearson Prentice Hall
 Data Modeling Notation:
IE Crow’s Foot I

KROENKE AND AUER - DATABASE PROCESSING, 12th Edition © 2012 5-28

Pearson Prentice Hall
 Data Modeling Notation:
IE Crow’s Foot 1:N

KROENKE AND AUER - DATABASE PROCESSING, 12th Edition © 2012 5-29

Pearson Prentice Hall
 Data Modeling Notation:
IE Crow’s Foot N:M

KROENKE AND AUER - DATABASE PROCESSING, 12th Edition © 2012 5-30

Pearson Prentice Hall
 ID-Dependent Entities
• An ID-dependent entity is an entity (child)
whose identifier includes the identifier of another
entity (parent).
• The ID-dependent entity is a logical extension or
subunit of the parent:
– BUILDING : APARTMENT
– PAINTING : PRINT
• The minimum cardinality from the ID-dependent
entity to the parent is always one.

KROENKE AND AUER - DATABASE PROCESSING, 12th Edition © 2012 5-31

Pearson Prentice Hall
 ID-Dependent Entities

KROENKE AND AUER - DATABASE PROCESSING, 12th Edition © 2012 5-32

Pearson Prentice Hall
 Weak Entities
• A weak entity is an entity whose existence
depends upon another entity.
• All ID-Dependent entities are considered
weak.
• There are also non-ID-dependent weak
entities.
– The identifier of the parent does not appear in
the identifier of the weak child entity.

KROENKE AND AUER - DATABASE PROCESSING, 12th Edition © 2012 5-33

Pearson Prentice Hall
 Weak Entities

KROENKE AND AUER - DATABASE PROCESSING, 12th Edition © 2012 5-34

Pearson Prentice Hall
 ID-Dependent and Weak Entities

KROENKE AND AUER - DATABASE PROCESSING, 12th Edition © 2012 5-35

Pearson Prentice Hall
 Subtype Entities
• A subtype entity is a special case of a
supertype entity:
– STUDENT :
UNDERGRADATE or GRADUATE
• The supertype contains all common
attributes, while the subtypes contain
specific attributes.
• The supertype may have a discriminator
attribute which indicates the subtype.
KROENKE AND AUER - DATABASE PROCESSING, 12th Edition © 2012 5-36
Pearson Prentice Hall
 Subtypes with a Discriminator

KROENKE AND AUER - DATABASE PROCESSING, 12th Edition © 2012 5-37

Pearson Prentice Hall
Subtypes: Exclusive or Inclusive
• If subtypes are exclusive, one supertype
relates to at most one subtype.
• If subtypes are inclusive, one supertype
can relate to one or more subtypes.

KROENKE AND AUER - DATABASE PROCESSING, 12th Edition © 2012 5-38

Pearson Prentice Hall
Subtypes: Exclusive or Inclusive

KROENKE AND AUER - DATABASE PROCESSING, 12th Edition © 2012 5-39

Pearson Prentice Hall
 Subtypes: IS-A Relationships
• Relationships connecting supertypes and
subtypes are called IS-A relationships,
because a subtype is a supertype.
• The identifier of the supertype and all of its
subtypes must be identical; i.e., the
identifier of the supertype becomes the
identifier of the related subtype(s).
• Subtypes are used to avoid value-
inappropriate nulls.
KROENKE AND AUER - DATABASE PROCESSING, 12th Edition © 2012 5-40
Pearson Prentice Hall
 IE Crow’s Foot Symbol Summary I

KROENKE AND AUER - DATABASE PROCESSING, 12th Edition © 2012 5-41

Pearson Prentice Hall
 IE Crow’s Foot Symbol Summary II

KROENKE AND AUER - DATABASE PROCESSING, 12th Edition © 2012 5-42

Pearson Prentice Hall
 Strong Entity Patterns:
1:1 Strong Entity Relationships

KROENKE AND AUER - DATABASE PROCESSING, 12th Edition © 2012 5-43

Pearson Prentice Hall
 Strong Entity Patterns:
1:1 Strong Entity Relationships

KROENKE AND AUER - DATABASE PROCESSING, 12th Edition © 2012 5-44

Pearson Prentice Hall
 Strong Entity Patterns:
1:N Strong Entity Relationships

KROENKE AND AUER - DATABASE PROCESSING, 12th Edition © 2012 5-45

Pearson Prentice Hall
 Strong Entity Patterns:
1:N Strong Entity Relationships

KROENKE AND AUER - DATABASE PROCESSING, 12th Edition © 2012 5-46

Pearson Prentice Hall
 Strong Entity Patterns:
N:M Strong Entity Relationships

KROENKE AND AUER - DATABASE PROCESSING, 12th Edition © 2012 5-47

Pearson Prentice Hall
 Strong Entity Patterns:
N:M Strong Entity Relationships

KROENKE AND AUER - DATABASE PROCESSING, 12th Edition © 2012 5-48

Pearson Prentice Hall
 ID-Dependent Relationships:
The Association Pattern

KROENKE AND AUER - DATABASE PROCESSING, 12th Edition © 2012 5-49

Pearson Prentice Hall
 ID-Dependent Relationships:
The Association Pattern

KROENKE AND AUER - DATABASE PROCESSING, 12th Edition © 2012 5-50

Pearson Prentice Hall
 ID-Dependent Relationships:
The Multivalued Attribute Pattern

KROENKE AND AUER - DATABASE PROCESSING, 12th Edition © 2012 5-51

Pearson Prentice Hall
 ID-Dependent Relationships:
The Multivalued Attribute Pattern

KROENKE AND AUER - DATABASE PROCESSING, 12th Edition © 2012 5-52

Pearson Prentice Hall
 ID-Dependent Relationships:
The Multivalued Attribute Pattern

KROENKE AND AUER - DATABASE PROCESSING, 12th Edition © 2012 5-53

Pearson Prentice Hall
 ID-Dependent Relationships:
The Multivalued Attribute Pattern

KROENKE AND AUER - DATABASE PROCESSING, 12th Edition © 2012 5-54

Pearson Prentice Hall
 ID-Dependent Relationships:
Composite Multivalued Attributes

KROENKE AND AUER - DATABASE PROCESSING, 12th Edition © 2012 5-55

Pearson Prentice Hall
 ID-Dependent Relationships:
Composite Multivalued Attributes

KROENKE AND AUER - DATABASE PROCESSING, 12th Edition © 2012 5-56

Pearson Prentice Hall
 ID-Dependent Relationships:
The Archetype/Instance Pattern
• The archetype/instance pattern occurs
when the ID-dependent child entity is the
physical manifestation (instance) of an
abstract or logical parent.
– PAINTING : PRINT
– CLASS : SECTION
– YACHT_DESIGN : YACHT
– HOUSE_MODEL: HOUSE

KROENKE AND AUER - DATABASE PROCESSING, 12th Edition © 2012 5-57

Pearson Prentice Hall
 ID-Dependent Relationships:
The Archetype/Instance Pattern

KROENKE AND AUER - DATABASE PROCESSING, 12th Edition © 2012 5-58

Pearson Prentice Hall
 ID-Dependent Relationships:
The Archetype/Instance Pattern

KROENKE AND AUER - DATABASE PROCESSING, 12th Edition © 2012 5-59

Pearson Prentice Hall
 Mixed Patterns:
The Line-Item Pattern

KROENKE AND AUER - DATABASE PROCESSING, 12th Edition © 2012 5-60

Pearson Prentice Hall
 Mixed Patterns:
The Line-Item Pattern

KROENKE AND AUER - DATABASE PROCESSING, 12th Edition © 2012 5-61

Pearson Prentice Hall
 Mixed Patterns:
Other Mixed Patterns
• Look for a mixed pattern where:
– A strong entity has a multivalued composite
group
– One of the elements of the composite group is
an identifier of another strong entity.

KROENKE AND AUER - DATABASE PROCESSING, 12th Edition © 2012 5-62

Pearson Prentice Hall
 Mixed Patterns:
Other Mixed Patterns

KROENKE AND AUER - DATABASE PROCESSING, 12th Edition © 2012 5-63

Pearson Prentice Hall
 Mixed Patterns:
Other Mixed Patterns

KROENKE AND AUER - DATABASE PROCESSING, 12th Edition © 2012 5-64

Pearson Prentice Hall
 Mixed Patterns:
The For-Use-By Pattern

KROENKE AND AUER - DATABASE PROCESSING, 12th Edition © 2012 5-65

Pearson Prentice Hall
 Mixed Patterns:
The For-Use-By Pattern

KROENKE AND AUER - DATABASE PROCESSING, 12th Edition © 2012 5-66

Pearson Prentice Hall
 Recursive Relationships
• A recursive relationship occurs when an
entity has a relationship to itself.

KROENKE AND AUER - DATABASE PROCESSING, 12th Edition © 2012 5-67

Pearson Prentice Hall
 Recursive Patterns:
1:1 Recursive Relationship

KROENKE AND AUER - DATABASE PROCESSING, 12th Edition © 2012 5-68

Pearson Prentice Hall
 Recursive Patterns:
1:N Recursive Relationship

KROENKE AND AUER - DATABASE PROCESSING, 12th Edition © 2012 5-69

Pearson Prentice Hall
 Recursive Patterns:
N:M Recursive Relationship

KROENKE AND AUER - DATABASE PROCESSING, 12th Edition © 2012 5-70

Pearson Prentice Hall
 Highline University
The College Report

KROENKE AND AUER - DATABASE PROCESSING, 12th Edition © 2012 5-71

Pearson Prentice Hall
 Highline University
First Data Model

KROENKE AND AUER - DATABASE PROCESSING, 12th Edition © 2012 5-72

Pearson Prentice Hall
 Highline University
The Department Report

KROENKE AND AUER - DATABASE PROCESSING, 12th Edition © 2012 5-73

Pearson Prentice Hall
 Highline University
Second Data Model

KROENKE AND AUER - DATABASE PROCESSING, 12th Edition © 2012 5-74

Pearson Prentice Hall
 Highline University
Second Data Model

KROENKE AND AUER - DATABASE PROCESSING, 12th Edition © 2012 5-75

Pearson Prentice Hall
 Highline University
Second Data Model

KROENKE AND AUER - DATABASE PROCESSING, 12th Edition © 2012 5-76

Pearson Prentice Hall
 Highline University
Second Data Model

KROENKE AND AUER - DATABASE PROCESSING, 12th Edition © 2012 5-77

Pearson Prentice Hall
 Highline University
The Department Student Report

KROENKE AND AUER - DATABASE PROCESSING, 12th Edition © 2012 5-78

Pearson Prentice Hall
 Highline University
Third Data Model

KROENKE AND AUER - DATABASE PROCESSING, 12th Edition © 2012 5-79

Pearson Prentice Hall
 Highline University
Sample Student Acceptance Letter

KROENKE AND AUER - DATABASE PROCESSING, 12th Edition © 2012 5-80

Pearson Prentice Hall
 Highline University
Fourth Data Model

KROENKE AND AUER - DATABASE PROCESSING, 12th Edition © 2012 5-81

Pearson Prentice Hall
 Highline University
Final Data Model

KROENKE AND AUER - DATABASE PROCESSING, 12th Edition © 2012 5-82

Pearson Prentice Hall
 David Kroenke and David Auer
Database Processing
Fundamentals, Design, and Implementation
(11th Edition)

End of Presentation:
Chapter Five

KROENKE AND AUER - DATABASE PROCESSING, 12th Edition © 2012 5-83

Pearson Prentice Hall
 All rights reserved. No part of this publication may be reproduced, stored in a
retrieval system, or transmitted, in any form or by any means, electronic,
mechanical, photocopying, recording, or otherwise, without the prior written
permission of the publisher. Printed in the United States of America.

Copyright © 2012 Pearson Education, Inc.  

Publishing as Prentice Hall

KROENKE AND AUER - DATABASE PROCESSING, 12th Edition © 2012 5-84

Pearson Prentice Hall