Chapter 3
Data Modeling Using the
Entity-Relationship (ER) Model
Copyright © 2004 Pearson Education, Inc.
FIGURE 3.1
A simplified diagram to
illustrate the main phases
of database design.
Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition
Copyright © 2004 Pearson Education, Inc.
Chapter 3-2
Example COMPANY Database
⚫ Requirements of the Company (oversimplified for
illustrative purposes)
– The company is organized into DEPARTMENTs.
Each department has a name, number and an
employee who manages the department. We keep
track of the start date of the department manager.
– Each department controls a number of PROJECTs.
Each project has a name, number and is located at a
single location.
Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition
Copyright © 2004 Pearson Education, Inc.
Chapter 3-3
Example COMPANY Database
(Cont.)
– We store each EMPLOYEE’s social security number,
address, salary, sex, and birthdate. Each employee
works for one department but may work on several
projects. We keep track of the number of hours per
week that an employee currently works on each
project. We also keep track of the direct supervisor of
each employee.
– Each employee may have a number of
DEPENDENTs. For each dependent, we keep track
of their name, sex, birthdate, and relationship to
employee.
Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition
Copyright © 2004 Pearson Education, Inc.
Chapter 3-4
FIGURE 3.2
An ER schema diagram for the COMPANY database.
Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition
Copyright © 2004 Pearson Education, Inc.
Chapter 3-5
ER Model Concepts
⚫ Entities and Attributes
– Entities are specific objects or things in the mini-world that are
represented in the database. For example the EMPLOYEE John
Smith, the Research DEPARTMENT, the ProductX PROJECT
– Attributes are properties used to describe an entity. For example an
EMPLOYEE entity may have a Name, SSN, Address, Sex,
BirthDate
– A specific entity will have a value for each of its attributes. For
example a specific employee entity may have Name='John Smith',
SSN='123456789', Address ='731, Fondren, Houston, TX',
Sex='M', BirthDate='09-JAN-55‘
– Each attribute has a value set (or data type) associated with it –
e.g. integer, string, subrange, enumerated type, …
Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition
Copyright © 2004 Pearson Education, Inc.
Chapter 3-6
FIGURE 3.3
Two entities, employee e1 and company c1, and their
attributes.
Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition
Copyright © 2004 Pearson Education, Inc.
Chapter 3-7
Types of Attributes (1)
⚫ Simple
– Each entity has a single atomic value for the attribute. For
example, SSN or Sex.
⚫ Composite
– The attribute may be composed of several components. For
example, Address (Apt#, House#, Street, City, State, ZipCode,
Country) or Name (FirstName, MiddleName, LastName).
Composition may form a hierarchy where some components are
themselves composite.
⚫ Multi-valued
– An entity may have multiple values for that attribute. For example,
Color of a CAR or PreviousDegrees of a STUDENT. Denoted as
{Color} or {PreviousDegrees}.
Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition
Copyright © 2004 Pearson Education, Inc.
Chapter 3-8
Types of Attributes (2)
⚫ In general, composite and multi-valued attributes may be
nested arbitrarily to any number of levels although this is
rare. For example, PreviousDegrees of a STUDENT is a
composite multi-valued attribute denoted by
{PreviousDegrees (College, Year, Degree, Field)}.
⚫ Another distinguished type of attribute is the derived
attribute. Unlike most attributes, whose values are stored,
derived attributes have values that can be calculated from
stored data.
Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition
Copyright © 2004 Pearson Education, Inc.
Chapter 3-9
Entity Types and Key Attributes
⚫ Entities with the same basic attributes are grouped or typed
into an entity type. For example, the EMPLOYEE entity type
or the PROJECT entity type.
⚫ An attribute of an entity type for which each entity must have
a unique value is called a key attribute of the entity type. For
example, SSN of EMPLOYEE.
⚫ A key attribute may be composite. For example,
VehicleTagNumber is a key of the CAR entity type with
components (Number, State).
⚫ An entity type may have more than one key. For example, the
CAR entity type may have two keys:
– VehicleIdentificationNumber (popularly called VIN) and
– VehicleTagNumber (Number, State), also known as license_plate
number.
Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition
Copyright © 2004 Pearson Education, Inc.
Chapter 3-10
ER DIAGRAM – Entity Types are:
EMPLOYEE, DEPARTMENT, PROJECT, DEPENDENT
Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition
Copyright © 2004 Pearson Education, Inc.
Chapter 3-11
Representing a Key with
Multiple Attributes
Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition
Copyright © 2004 Pearson Education, Inc.
Chapter 3-12
Relationships and Relationship
Types (1)
⚫ A relationship relates two or more distinct entities with a
specific meaning. For example, EMPLOYEE John Smith
works on the ProductX PROJECT or EMPLOYEE Franklin
Wong manages the Research DEPARTMENT.
⚫ Relationships of the same type are grouped or typed into a
relationship type. For example, the WORKS_ON relationship
type in which EMPLOYEEs and PROJECTs participate, or
the MANAGES relationship type in which EMPLOYEEs and
DEPARTMENTs participate.
⚫ The degree of a relationship type is the number of
participating entity types. Both MANAGES and
WORKS_ON are binary relationships.
Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition
Copyright © 2004 Pearson Education, Inc.
Chapter 3-13
Formal Definition of a Relationship Set
⚫ A relationship set is a mathematical relation on n
>= 2 (possibly non-distinct) entity sets
⚫ If E1, E2, …, En are entity sets, then a relationship
set R is a subset of the Cartesian product E 1 x E2 x
… x En
{(e1, e2, …, en) | e1 є E1, e2 є E2, …, en є En}
where (e1, e2, …, en) is one relationship
⚫ The Cartesian product is all possible associations
among the entities of the entity sets
⚫ What you actually get is some subset of all of the
associations that are possible
Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition
Copyright © 2004 Pearson Education, Inc.
Chapter 3-14
Example Relationship Set with n = 2
Person
(p1) Prof. M.
Owns
Pet (Animal)
r1
Convict (a1)
r2
Lizzie (a2)
r3
Elvis (a3)
(p2) Prof. U.
r4
Puppy (a4)
(p3) Ms. Vale
r5
Circuit (a5)
Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition
Copyright © 2004 Pearson Education, Inc.
Chapter 3-15
Example, continued
⚫ Any person could own any pet, but they don’t
⚫ Our relationship set contains the actual associations
showing who owns which pet
⚫ This is a binary relationship, because n = 2.
⚫ Fortunately, in the real world, most relationships of
interest turn out to be binary
⚫ All of the relationships in our Company example are
binary
⚫ If you had three entities involved in a relationship,
you’d have a ternary relationship. You would see
three entities (rectangles) linked to a single
relationship (diamond) on the ER diagram
Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition
Copyright © 2004 Pearson Education, Inc.
Chapter 3-16
FIGURE 3.10
Some relationship instances in the SUPPLY ternary
relationship set.
Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition
Copyright © 2004 Pearson Education, Inc.
Chapter 3-17
ER DIAGRAM – Relationship Types are:
WORKS_FOR, MANAGES, WORKS_ON, CONTROLS,
SUPERVISION, DEPENDENTS_OF
Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition
Copyright © 2004 Pearson Education, Inc.
Chapter 3-18
Weak Entity Types
⚫ An entity that does not have a key attribute
⚫ A weak entity must participate in an identifying relationship
type with an owner or identifying entity type
⚫ Entities are identified by the combination of:
– A partial key of the weak entity type
– The particular entity they are related to in the
identifying entity type
Example:
Suppose that a DEPENDENT entity is identified by the
dependent’s first name and birhtdate, and the specific
EMPLOYEE that the dependent is related to. DEPENDENT
is a weak entity type with EMPLOYEE as its identifying
entity type via the identifying relationship type
DEPENDENT_OF
Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition
Copyright © 2004 Pearson Education, Inc.
Chapter 3-19
Weak Entity Type is: DEPENDENT
Identifying Relationship is: DEPENDENTS_OF
Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition
Copyright © 2004 Pearson Education, Inc.
Chapter 3-20
More Relationships and Relationship
Types
⚫ We can also have a recursive relationship type.
⚫ Both participations are same entity type in different roles.
⚫ For example, SUPERVISION relationships between
EMPLOYEE (in role of supervisor or boss) and (another)
EMPLOYEE (in role of subordinate or worker).
⚫ In following figure, first role participation labeled with 1 and
second role participation labeled with 2.
⚫ In ER diagram, need to display role names to distinguish
participations.
Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition
Copyright © 2004 Pearson Education, Inc.
Chapter 3-21
Recursive Relationship Type is: SUPERVISION
(participation role names are shown)
Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition
Copyright © 2004 Pearson Education, Inc.
Chapter 3-22
Attributes of Relationship types
⚫ A relationship type can have attributes; for
example, HoursPerWeek of WORKS_ON; its
value for each relationship instance describes
the number of hours per week that an
EMPLOYEE works on a PROJECT.
Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition
Copyright © 2004 Pearson Education, Inc.
Chapter 3-23
Attribute of a Relationship Type is:
Hours of WORKS_ON
Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition
Copyright © 2004 Pearson Education, Inc.
Chapter 3-24
Constraints
⚫ Once we have identified entities and relationships,
we need to consider constraints
⚫ Constraints help to maintain the integrity and
accuracy of the DB
⚫ There are two types of constraints used in the ER
model, cardinality ratios and existence
dependencies (aka participation constraints)
⚫ Cardinality ratios express the number of entities to
which another entity can be associated via a
relationship set
⚫ For binary relationships, there are only four
possible cardinality ratios
Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition
Copyright © 2004 Pearson Education, Inc.
Chapter 3-25
One-to-One Cardinality Ratio
⚫ In a one-to-one (1:1) cardinality ratio, an entity in
one set is associated with at most one entity in
another
⚫ Example: husbands and wives
Husband
h1
h2
h3
Wife
w1
w2
w3
Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition
Copyright © 2004 Pearson Education, Inc.
Chapter 3-26
One-to-Many Cardinality Ratio
⚫ In a one-to-many (1:N) cardinality ratio, an entity in
the first set is associated with 0 or more entities in the
second set. However, those entities in the second set
can be associated with at most one entity in the first.
⚫ Example: biological fathers and children
Father
Child
f1
c1
c2
f2
c3
c4
c5
c6 (cloned)
Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition
Copyright © 2004 Pearson Education, Inc.
Chapter 3-27
Many-to-One Cardinality Ratio
⚫ A many-to-one (N:1) cardinality ratio is just
the reverse of the 1:N cardinality ratio. You
can think of whichever entity set you like as
being the first set. Just specify the direction
that makes sense for your application, and
then be consistent.
Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition
Copyright © 2004 Pearson Education, Inc.
Chapter 3-28
Many-to-Many Cardinality Ratio
⚫ In a many-to-many (N:M) cardinality ratio, entities of either
set may be associated with any number of entities in the
other
⚫ Example: nieces and aunts
(only uncles)
Niece
n1
n2
n3
n4
Aunt
a1
a2
a3
a4
a5 (only nephews)
Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition
Copyright © 2004 Pearson Education, Inc.
Chapter 3-29
Participation Constraints
⚫ Participation constraints indicate if an entity in one set must be
related to an entity in another
⚫ If so, there is total participation in the relationship
⚫ If not, there is partial participation in the relationship
⚫ Example: A bank customer may have an ATM card and use it to
make transactions, like withdrawing cash. The bank card has
total participation in the relationship, because every card must
belong to a customer. No cards are sitting around loose where
anyone can use them, unfortunately. The customer has partial
participation in the relationship. A bank customer doesn’t have to
have an ATM card. Maybe the customer just has a mortgage with
the bank.
⚫ Participation constraints are sometimes called existence
dependencies. The customer would still exist as a customer if he
didn’t have a card, but the card wouldn’t exist without the
customer who owned it.
Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition
Copyright © 2004 Pearson Education, Inc.
Chapter 3-30
Weak Entities Need Total Participation
⚫ A weak entity always has total participation
in some relationship with another entity
⚫ The other entity is called the identifying
owner of the weak entity
⚫ Since a weak entity has no key, this
connection allows weak entities to be
distinguished from each other
Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition
Copyright © 2004 Pearson Education, Inc.
Chapter 3-31
FIGURE 3.2
.
An ER schema diagram for the COMPANY database
Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition
Copyright © 2004 Pearson Education, Inc.
Chapter 3-32