Entity Relationship Model

Rahma Bintey Mufiz Mukta

Lecturer
Department of CSE, CUET

Copyright 2009 Pearson Education, Inc. Publishing as Pearson Addison-Wesley

 Outline

Overview of the Database Design Process

Example Database Application (COMPANY)
ER Model Concepts
Entities and Attributes
Entity Types, Value Sets, and Key Attributes
Relationships and Relationship Types
Weak Entity Types
Roles and Attributes in Relationship Types
ER Model Notations, Naming Conventions, Design
Issues
ER Diagram for COMPANY Schema
1-2

Copyright 2009 Pearson Education, Inc. Publishing as Pearson Addison-Wesley

Overview of the Database Design
Process
Two main activities (see Figure 7.1, next slide):
Database schema design
Application programs design
Focus in this chapter on database schema
design
Given the database requirements, design the
conceptual schema for a database
Application programs design focuses on the
programs and interfaces that access and update
the database (considered part of software
1-3
engineering discipline)
Copyright 2009 Pearson Education, Inc. Publishing as Pearson Addison-Wesley
 1-4

Copyright 2009 Pearson Education, Inc. Publishing as Pearson Addison-Wesley

The Database Design Process
Requirements Analysis and Specification is in the
realm of Systems Analysis and Design
In this chapter, we assume it is already completed
This and next chapter focus on Conceptual Design
(see Figure 7.1)
Physical Design discussed in Chapter 17, after
presenting file structures and indexing (Chapters 11,
12)
Logical Design presented in Chapter 7

1-5

Copyright 2009 Pearson Education, Inc. Publishing as Pearson Addison-Wesley

The Entity-Relationship (ER) Model
ER model is a conceptual data model for database
design
Has an associated notation (ER schema diagrams) for
drawing/displaying the database schema
Many variations of ER model exists
Also, many extensions (see EER model)
Next slide (Figure 7.2) shows a complete ER schema
diagram for a COMPANY database
We will explain gradually how this design is created
First we introduce the requirements for the COMPANY
database
Then we present ER model concepts and diagrammatic
notation gradually, and design the schema step-by-step 1-6

Copyright 2009 Pearson Education, Inc. Publishing as Pearson Addison-Wesley

 1-7

Copyright 2009 Pearson Education, Inc. Publishing as Pearson Addison-Wesley

Example: COMPANY Database
Create a database schema design based on the
following (simplified) requirements for a
COMPANY Database:
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. A department may have several
locations.
Each department controls a number of
PROJECTs. Each project has a unique name,
unique number and is located at a single location. 1-8

Copyright 2009 Pearson Education, Inc. Publishing as Pearson Addison-Wesley

COMPANY Database (cont.)
The database will store each EMPLOYEEs name,
social security number (unique for each
employee), 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.
An employee can have DEPENDENTs.
For each dependent, the database keeps track of
their first name, sex, birthdate, and their
relationship to the employee (child, spouse, etc.). 1-9

Copyright 2009 Pearson Education, Inc. Publishing as Pearson Addison-Wesley

ER Model Concepts
Entities and Attributes
Entities: Specific objects or things in the mini-world that
are represented in the database.
Examples: the EMPLOYEE John Smith, the Research
DEPARTMENT, the ProductX PROJECT
Attributes: Properties used to describe an entity.
Examples: an EMPLOYEE entity may have the attributes
Name, SSN, Address, Sex, BirthDate
Data values: A specific entity has a value for each of its
attributes.
Example: An 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,
1-10

Copyright 2009 Pearson Education, Inc. Publishing as Pearson Addison-Wesley

Types of Attributes
Simple attribute (sometimes called atomic):
Each entity has a single value for the attribute. For example,
the SSN or Sex of an employee.
Composite attribute (also called compound):
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 (Figure 7.4, next slide).
Multi-valued attribute (also called repeating group or
collection):
An single entity may have multiple values for that attribute. For
example, Color of a CAR or PreviousDegrees of a STUDENT.
Denoted as {Color} or {PreviousDegrees}.
Derived Attribute The value of this type of attribute can be
derived from the values of other related attributes. 1-11

Copyright 2009 Pearson Education, Inc. Publishing as Pearson Addison-Wesley

 1-12

Copyright 2009 Pearson Education, Inc. Publishing as Pearson Addison-Wesley

Types of Attributes (cont.)
Composite and multi-valued attributes may be
nested (to any number of levels).
Example: PreviousDegrees of a STUDENT can
be a composite multi-valued attribute denoted by
{PreviousDegrees (College, Year, Degree, Field)}
Multiple PreviousDegrees values can exist for a
particular student
Each has four subcomponent attributes:
College, Year, Degree, Field

1-13

Copyright 2009 Pearson Education, Inc. Publishing as Pearson Addison-Wesley

Entity Types and Key
Attributes
Entities with the same basic attributes are
grouped (or typed) into an entity type.
Examples: EMPLOYEE or PROJECT.
Key attribute: an attribute of an entity type for
which each entity must have a unique (distinct)
value.
Example: SSN of EMPLOYEE, or PNUMBER
of PROJECT, or PNAME of PROJECT.

1-14

Copyright 2009 Pearson Education, Inc. Publishing as Pearson Addison-Wesley

Entity Types and Key Attributes (cont.)
A key attribute may be composite.
Example: VehicleTagNumber (also known as
LicensePlateNo) of a CAR is a key with two
components (LicNumber, State).
An entity type may have more than one key.
The CAR entity type may have two keys:
VehicleIdentificationNumber (popularly called VIN,
unique number stamped on each new car)
VehicleTagNumber (Number, State)
Each key is underlined in ER diagrams (see next
slides)
1-15

Copyright 2009 Pearson Education, Inc. Publishing as Pearson Addison-Wesley

Displaying an Entity type
In ER diagrams, the entity type name is
displayed in a rectangular box
Attributes are displayed in ovals
Each attribute is connected to its entity type
Components of a composite attribute are
connected to the oval representing the
composite attribute
Each key attribute is underlined
Multivalued attributes displayed in double
ovals
See CAR example (Figure 7.7(a)) on next slide
1-16

Copyright 2009 Pearson Education, Inc. Publishing as Pearson Addison-Wesley

 1-17

Copyright 2009 Pearson Education, Inc. Publishing as Pearson Addison-Wesley

 Entity Set
Each entity type will have a collection of
individual entities stored in the database
Called the entity set
Previous slide (Figure 7.7(b) show three CAR entities
in the entity set for CAR
Same name (CAR) refers to both entity type and entity
set
Object models (see Chapter 9) give different names to
the entity type and the entity set
Entity set changes over time as entities are created
and deleted represents current state of database
1-18

Copyright 2009 Pearson Education, Inc. Publishing as Pearson Addison-Wesley

 Initial Design of Entity Types
for the COMPANY Database Schema
Based on the requirements, we can identify four
initial entity types in the COMPANY database:
DEPARTMENT
PROJECT
EMPLOYEE
DEPENDENT
Initial design (Figure 7.8) on following slide, will be
refined into final design
Initial attributes shown are derived from the
requirements description
1-19

Copyright 2009 Pearson Education, Inc. Publishing as Pearson Addison-Wesley

 1-20

Copyright 2009 Pearson Education, Inc. Publishing as Pearson Addison-Wesley

Refining the initial design by
introducing Relationships

The initial design is typically not complete

Some aspects in the requirements will be
represented as relationships
ER model has three main concepts:
Entities (and their entity types and entity sets)
Attributes (simple, composite, multivalued)
Relationships (and their relationship types and
relationship sets)
We introduce relationship concepts next
1-21

Copyright 2009 Pearson Education, Inc. Publishing as Pearson Addison-Wesley

Relationships and Relationship Types
A relationship relates two or more distinct entities, with a
specific meaning.
For example, EMPLOYEE John Smith works on the
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.
1-22

Copyright 2009 Pearson Education, Inc. Publishing as Pearson Addison-Wesley

 Relationship Type vs. Relationship Set

Relationship Type:
Is the schema description of a relationship
Identifies the relationship name and the
participating entity types
Also identifies certain relationship constraints
Relationship Set:
The current set of relationship instances
represented in the database
The current state of a relationship type
1-23

Copyright 2009 Pearson Education, Inc. Publishing as Pearson Addison-Wesley

 1-24

Copyright 2009 Pearson Education, Inc. Publishing as Pearson Addison-Wesley

 Relationship Type
Previous figure displayed the relationship set
Each instance in the set relates individual
participating entities one from each participating
entity type
In ER diagrams, we represent the relationship type
as follows:
Diamond-shaped box is used to display a relationship
type
Connected to the participating entity types via straight
lines
Degree of a relationship type is the number of
participating entity types
1-25

Copyright 2009 Pearson Education, Inc. Publishing as Pearson Addison-Wesley

Refining the COMPANY Initial Design
by Including Relationships
By examining the requirements, attributes in the initial
design that refer to other entities are converted into
relationships (and removed from the entity types)
Some of these relationship attributes (Figure 7.8,
repeated on next slide) are:
The Department attribute of EMPLOYEE refers to the
DEPARTMENT entity that the employee WORKS_FOR
The Manager attribute of DEPARTMENT refers to the
EMPLOYEE entity who MANAGES the DEPARTMENT
The Supervisor attribute of EMPLOYEE refers to another
EMPLOYEE entity (this is called a recursive relationship)
Several other similar attributes are converted into
relationships can you identify those in next slide? 1-26

Copyright 2009 Pearson Education, Inc. Publishing as Pearson Addison-Wesley

 1-27

Copyright 2009 Pearson Education, Inc. Publishing as Pearson Addison-Wesley

Refining the COMPANY Initial Design
by Including Relationships (cont.)
Six relationship types are identified for the COMPANY
database schema (see Figure 7.2, repeated next slide)
All are binary relationships (degree 2)
Listed below with their participating entity types:
WORKS_FOR (between EMPLOYEE, DEPARTMENT)
MANAGES (also between EMPLOYEE, DEPARTMENT)
CONTROLS (between DEPARTMENT, PROJECT)
WORKS_ON (between EMPLOYEE, PROJECT)
SUPERVISION (between EMPLOYEE (as subordinate),
EMPLOYEE (as supervisor))
DEPENDENTS_OF (between EMPLOYEE, DEPENDENT)
1-28

Copyright 2009 Pearson Education, Inc. Publishing as Pearson Addison-Wesley

 1-29

Copyright 2009 Pearson Education, Inc. Publishing as Pearson Addison-Wesley

Discussion on Relationship Types
In the refined design, some attributes from the initial
entity types are refined into relationships:
Manager of DEPARTMENT -> MANAGES
Works_on of EMPLOYEE -> WORKS_ON
Department of EMPLOYEE -> WORKS_FOR
etc
In general, more than one relationship type can exist
between the same participating entity types
MANAGES and WORKS_FOR are distinct relationship
types between EMPLOYEE and DEPARTMENT
Different meanings and different relationship instances.
1-30

Copyright 2009 Pearson Education, Inc. Publishing as Pearson Addison-Wesley

Recursive Relationship Type
A relationship type with the same entity type participating
twice in two distinct roles
Example: the SUPERVISION relationship
EMPLOYEE participates twice in two distinct roles:
supervisor (or boss) role
supervisee (or subordinate) role
must distinguish the roles in a relationship instance
Each relationship instance ri relates two distinct
EMPLOYEE entities (see Figure 7.11, next slide):
One employee in supervisor role (labeled 1 in Fig. 7.11)
One employee in supervisee role (labeled 2 in Fig. 7.11)
1-31

Copyright 2009 Pearson Education, Inc. Publishing as Pearson Addison-Wesley

 1-32

Copyright 2009 Pearson Education, Inc. Publishing as Pearson Addison-Wesley

 Weak Entity Types
An entity type that does not have a key attribute on its own
A weak entity must participate in an identifying relationship type with
an owner (or identifying) entity type
Individual 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 (see Figure 7.2):
A DEPENDENT entity is identified by the dependents first name,
and the specific EMPLOYEE with whom the dependent is related
Name of DEPENDENT is the partial key
DEPENDENT is a weak entity type
EMPLOYEE is its identifying (owner) entity type via the
identifying relationship type DEPENDENT_OF
1-33

Copyright 2009 Pearson Education, Inc. Publishing as Pearson Addison-Wesley

Constraints on Relationships
Constraints on Relationship Types
Two main types of constraints on binary relationships
Cardinality Ratio (specifies maximum participation)
One-to-one (1:1)
One-to-many (1:N) or Many-to-one (N:1)
Many-to-many (M:N)
Existence Dependency Constraint (specifies minimum
participation) (also called participation constraint)
zero (optional participation, not existence-dependent)
one or more (mandatory participation, existence-dependent)

1-34

Copyright 2009 Pearson Education, Inc. Publishing as Pearson Addison-Wesley

Constraints on Relationships
(cont.)
Cardinality ration specified by labeling 1, M, or N to
relationship lines in ER diagrams.
See Figure 7.2, repeated in next slide
Total participation specified by double line, partial
participation by single line.
These constraints are derived from the real-world
meaning and characteristics of each relationship type
In some ER diagrammatic notation, it is common to
specify cardinality ration and participation constraint
jointly using (min, max) notation
Called (min, max) constraints or multiplicities
1-35

Copyright 2009 Pearson Education, Inc. Publishing as Pearson Addison-Wesley

 1-36

Copyright 2009 Pearson Education, Inc. Publishing as Pearson Addison-Wesley

Displaying a Recursive Relationship
Type in ER Diagrams
In 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 ER diagram, need to display role names to
distinguish participations (see Figure 7.2).
Role names can also be optionally displayed for
other relationship types
1-37

Copyright 2009 Pearson Education, Inc. Publishing as Pearson Addison-Wesley

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.
A value of HoursPerWeek depends on a particular
(employee, project) combination
Most relationship attributes are used with M:N
relationships
In 1:N relationships, they can be transferred to the
entity type on the N-side of the relationship
1-38

Copyright 2009 Pearson Education, Inc. Publishing as Pearson Addison-Wesley

 Thanks!!!

1-39

Copyright 2009 Pearson Education, Inc. Publishing as Pearson Addison-Wesley