CHAPTER 3

Data Modeling Using the

Entity-Relationship (ER) Model

Copyright © 2016 Ramez Elmasr and Shamkant B. Navathei Slide 1- 1

Chapter Outline
◼ Overview of 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 Diagrams - Notation

Copyright © 2016 Ramez Elmasr and Shamkant B. Navathei Slide 3- 2

Database Design
◼ Conceptual Database Design
◼ highest level of abstraction (only focus on types of data).

◼ entities, attributes, relationships.

◼ Logical Database Design

◼ bridges between conceptual and physical level

◼ more detailed representation, focusing on data

structures, relationships, and constraints.

◼ Physical Database Design
◼ designers make decisions about how the logical design

will be implemented on a specific DBMS.

◼ Considerations include indexing, storage, performance

optimization, and security measures.

Copyright © 2016 Ramez Elmasr and Shamkant B. Navathei Slide 3- 3
Overview of Database Design Process

◼ Two main activities:

◼ Database design
◼ Applications design
◼ Focus in this chapter on conceptual database
design
◼ To design the conceptual schema for a database
application
◼ Applications design focuses on the programs and
interfaces that access the database
◼ Generally considered part of software engineering
Copyright © 2016 Ramez Elmasr and Shamkant B. Navathei Slide 3- 4
Overview of Database Design Process

Copyright © 2016 Ramez Elmasr and Shamkant B. Navathei Slide 3- 5

Methodologies for Conceptual
Design
◼ Entity Relationship (ER) Diagrams (This Chapter)
◼ Enhanced Entity Relationship (EER) Diagrams
(Chapter 4)
◼ Use of Design Tools in industry for designing and
documenting large scale designs
◼ The UML (Unified Modeling Language) Class
Diagrams are popular in industry to document
conceptual database designs

Copyright © 2016 Ramez Elmasr and Shamkant B. Navathei Slide 3- 6

Example COMPANY Database
◼ We need to create a database schema design
based on the following (simplified) requirements
of the COMPANY Database:
◼ The company is organized into DEPARTMENTs.
Each department has a name, number and an
employee who manages (manager) 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.

Copyright © 2016 Ramez Elmasr and Shamkant B. Navathei Slide 3- 7

Example COMPANY Database
(Continued)
◼ The database will store each EMPLOYEE’s social
security number, address, salary, sex, and
birthdate.
◼ Each employee works for one department but may
work on several projects.
◼ The DB will keep track of the number of hours per
week that an employee currently works on each
project.
◼ It is required to keep track of the direct supervisor of
each employee.
◼ Each employee may have a number of
DEPENDENTs.
◼ For each dependent, the DB keeps a record of name,
sex, birthdate, and relationship to the employee. Slide 3- 8
Copyright © 2016 Ramez Elmasr and Shamkant B. Navathei
ER Model Concepts
◼ Entities and Attributes
◼ Entity is a basic concept for the ER model. Entities are
specific things or objects in the mini-world that are
represented in the database.
◼ For example: EMPLOYEE, DEPARTMENT, PROJECT
◼ Attributes are properties used to describe an entity.
◼ For example: an EMPLOYEE entity may have the attributes
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, date, enumerated type, …

Copyright © 2016 Ramez Elmasr and Shamkant B. Navathei Slide 3- 9

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, Phone number or Previous Degrees of a STUDENT.
◼ Denoted as {PhoneNumber} or {PreviousDegrees}.

Copyright © 2016 Ramez Elmasr and Shamkant B. Navathei Slide 3- 10

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)}
◼ Multiple PreviousDegrees values can exist
◼ Each has four subcomponent attributes:
◼ College, Year, Degree, Field

Copyright © 2016 Ramez Elmasr and Shamkant B. Navathei Slide 3- 11

Example of a composite attribute

Copyright © 2016 Ramez Elmasr and Shamkant B. Navathei Slide 3- 12

Entity Types and Key Attributes (1)
◼ Entities with the same basic attributes are
grouped or typed into an entity type.
◼ For example, the entity type EMPLOYEE
and PROJECT.
◼ 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.

Copyright © 2016 Ramez Elmasr and Shamkant B. Navathei Slide 3- 13

Entity Types and Key Attributes (2)
◼ A key attribute may be composite.
◼ VehicleTagNumber is a key of the CAR entity

type with components (Number, State).

◼ An entity type may have more than one key.
◼ The CAR entity type may have two keys:

◼ VehicleIdentificationNumber (popularly called VIN)

◼ VehicleTagNumber (Number, State), aka license
plate number.
◼ Each key is underlined (Note: this is different from
the relational schema where only one “primary”
key is underlined).
Copyright © 2016 Ramez Elmasr and Shamkant B. Navathei Slide 3- 14
 Entity Set
◼ Each entity type will have a collection of entities
stored in the database
◼ Called the entity set or sometimes entity collection

(collection of all
entity types)
A thing in a real-world with
independent existence. i.e.,
person, car
Entity (category)

◼ However, entity type and entity set may be given

different names
◼ Entity set is the current state of the entities of that
type that are stored in the database Slide 3- 15
Copyright © 2016 Ramez Elmasr and Shamkant B. Navathei
Value Sets (Domains) of Attributes
◼ Each simple attribute is associated with a value
set
◼ E.g., Lastname has a value which is a character
string of upto 15 characters
◼ Date has a value consisting of MM-DD-YYYY
where each letter is an integer
◼ A value set specifies the set of values associated
with an attribute

Copyright © 2016 Ramez Elmasr and Shamkant B. Navathei Slide 3- 16

Attributes and Value Sets
◼ Value sets are similar to data types in most
programming languages – e.g., integer, character
(n), real, bit
◼ Mathematically, an attribute A for an entity type E
whose value set is V is defined as a function
A : E -> P(V)
Where P(V) indicates a power set (which means all
possible subsets) of V. The above definition
covers simple and multivalued attributes.
◼ We refer to the value of attribute A for entity e as

A(e). Slide 3- 17
Copyright © 2016 Ramez Elmasr and Shamkant B. Navathei
Displaying an Entity type
◼ In ER diagrams, an entity type 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 the full ER notation in advance on the next
slide
Copyright © 2016 Ramez Elmasr and Shamkant B. Navathei Slide 3- 18
NOTATION for ER diagrams

Copyright © 2016 Ramez Elmasr and Shamkant B. Navathei Slide 3- 19

Entity Type CAR with two keys and a
corresponding Entity Set

Copyright © 2016 Ramez Elmasr and Shamkant B. Navathei Slide 3- 20

Example COMPANY Database (Recap)
◼ We need to create a database schema design
based on the following (simplified) requirements
of the 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.

Copyright © 2016 Ramez Elmasr and Shamkant B. Navathei Slide 3- 21

Example COMPANY Database (Recap)
◼ The database will store each EMPLOYEE’s social
security number, address, salary, sex, and
birthdate.
◼ Each employee works for one department but may
work on several projects.
◼ The DB will keep track of the number of hours per
week that an employee currently works on each
project.
◼ It is required to keep track of the direct supervisor of
each employee.
◼ Each employee may have a number of
DEPENDENTs.
◼ For each dependent, the DB keeps a record of name,
sex, birthdate, and relationship to the employee.Slide 3- 22
Copyright © 2016 Ramez Elmasr and Shamkant B. Navathei
Initial Conceptual 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
◼ Their initial conceptual design is shown on the
following slide
◼ The initial attributes shown are derived from the
requirements description
Copyright © 2016 Ramez Elmasr and Shamkant B. Navathei Slide 3- 23
Initial Design of Entity Types:
EMPLOYEE, DEPARTMENT, PROJECT, DEPENDENT

Copyright © 2016 Ramez Elmasr and Shamkant B. Navathei Slide 3- 24