FUNDAMENTALS OF

DATABASE SYSTEMS
LESSON 3: The ER Model

Nguyễn Thị Hậu

University of Engineering and Technology,
Vietnam National University in Hanoi (UET-VNU)
[email protected]
 Outline
• 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
• ER Diagram for COMPANY Schema

Nguyen Thi Hau - DBMS Chapter 3-2

 Some of the Currently Available Automated Database
Design Tools

COMPANY TOOL FUNCTIONALITY

Visio Visio Enterprise Data modeling, design and reengineering Visual Basic
and Visual C++
Draw.io Free online tool https://about.draw.io/entity-relationship-diagrams-
with-draw-io/

Nguyen Thi Hau - DBMS Chapter 3-3

 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.

Nguyen Thi Hau - DBMS Chapter 3-4

 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.

Nguyen Thi Hau - DBMS Chapter 3-5

 ER Model Concepts
• Basis of an entity relationship diagram (ERD)
• ERD depicts the:
– Conceptual database as viewed by end user
– Database’s main components
• Entities
• Attributes
• Relationships
• Entity - Refers to the entity set and not to a
single entity occurrence

Nguyen Thi Hau - DBMS Chapter 3-6

SUMMARY OF ER-DIAGRAM
NOTATION FOR ER SCHEMAS

Nguyen Thi Hau - DBMS 7

ATTRIBUTES

Nguyen Thi Hau - DBMS 8

 Types of Attributes
• 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}.

Nguyen Thi Hau - DBMS Chapter 3-9

 Types of Attributes
• 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)}.

A hierarchy of composite attributes

Nguyen Thi Hau - DBMS Chapter 3-10
 Types of Attributes
• Stored vs Derived attributes: In some cases, two
(or more) attribute values are related—for example,
the Age and Birth_date attributes of a person. For a
particular person entity, the value of Age can be
determined from the current (today’s) date and the
value of that person’s Birth_date. The Age attribute is
hence called a derived attribute and is said to be
derivable from the Birth_date attribute, which is
called a stored attribute.

Nguyen Thi Hau - DBMS 11

ENTITIES

Nguyen Thi Hau - DBMS 12

 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 COMPANY entity type.

Nguyen Thi Hau - DBMS Chapter 3-13

 Key Attributes
• 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.

Nguyen Thi Hau - DBMS Chapter 3-14

 ER DIAGRAM – Entity Types are:
EMPLOYEE, DEPARTMENT, PROJECT, DEPENDENT

Nguyen Thi Hau - DBMS Chapter 3-15

 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

Nguyen Thi Hau - DBMS Chapter 3-16

 Weak Entity Type is: DEPENDENT
Identifying Relationship is: DEPENDENTS_OF

Nguyen Thi Hau - DBMS Chapter 3-17

RELATIONSHIP

Nguyen Thi Hau - DBMS 18

 Relationships and Relationship Types
• 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.

Nguyen Thi Hau - DBMS Chapter 3-19

Example relationship instances of the WORKS_FOR
relationship between EMPLOYEE and DEPARTMENT

Nguyen Thi Hau - DBMS 20

 Relationships and Relationship Types
• The degree of a relationship type is the number of participating
entity types. Both MANAGES and WORKS_ON are binary
relationships.
• A relationship type of degree two is called binary, and one of
degree three is called ternary.

Nguyen Thi Hau - DBMS Chapter 3-21

Relationships and Relationship Types
• More than one relationship type can exist with the same
participating entity types.
• For example, MANAGES and WORKS_FOR are distinct
relationships between EMPLOYEE and DEPARTMENT, but
with different meanings and different relationship instances.

Nguyen Thi Hau - DBMS Chapter 3-22

 ER DIAGRAM – Relationship Types are:
WORKS_FOR, MANAGES, WORKS_ON, CONTROLS,
SUPERVISION, DEPENDENTS_OF

Nguyen Thi Hau - DBMS Chapter 3-23

 Constraints on Relationships

• Constraints on Relationship Types

– ( Also known as ratio constraints )
– Maximum Cardinality
• One-to-one (1:1)
• One-to-many (1:N) or Many-to-one (N:1)
• Many-to-many
– Minimum Cardinality (also called participation
constraint or existence dependency constraints)
• zero (optional participation, not existence-dependent)
• one or more (mandatory, existence-dependent)

Nguyen Thi Hau - DBMS Chapter 3-24

 Total vs partial participation
• The participation of EMPLOYEE in WORKS_FOR
is called total participation, meaning that every
entity in the total set of employee entities must be
related to a department entity via WORKS_FOR.
Total participation is also called existence
dependency.
• The participation of EMPLOYEE in the MANAGES
relationship type is partial, meaning that some or
part of the set of employee entities are related to some
department entity via MANAGES, but not
necessarily all.
Nguyen Thi Hau - DBMS 25
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.

Nguyen Thi Hau - DBMS Chapter 3-26

Recursive Relationship Type is: SUPERVISION
(participation role names are shown)

Nguyen Thi Hau - DBMS Chapter 3-27

 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.

Nguyen Thi Hau - DBMS Chapter 3-28

Attribute of a Relationship Type is:
Hours of WORKS_ON

Nguyen Thi Hau - DBMS Chapter 3-29

 Structural Constraints –
one way to express semantics
of relationships
Structural constraints on relationships:
 Cardinality ratio (of a binary relationship): 1:1, 1:N, N:1,
or M:N
SHOWN BY PLACING APPROPRIATE NUMBER ON THE
LINK.
 Participation constraint (on each participating entity
type): total (called existence dependency) or partial.
SHOWN BY DOUBLE LINING THE LINK

NOTE: These are easy to specify for Binary Relationship

Types.

Nguyen Thi Hau - DBMS Chapter 3-30

 Alternative (min, max) notation for relationship structural
constraints:
 Specified on each participation of an entity type E in a relationship type R
 Specifies that each entity e in E participates in at least min and at most max
relationship instances in R
 Default(no constraint): min=0, max=n

 Must have minmax, min0, max 1

 Derived from the knowledge of mini-world constraints

Examples:
 A department has exactly one manager and an employee can manage at most
one department.
– Specify (0,1) for participation of EMPLOYEE in MANAGES

– Specify (1,1) for participation of DEPARTMENT in MANAGES

 An employee can work for exactly one department but a department can have
any number of employees.
– Specify (1,1) for participation of EMPLOYEE in WORKS_FOR

– Specify (0,n) for participation of DEPARTMENT in WORKS_FOR

Nguyen Thi Hau - DBMS Chapter 3-31
The (min,max) notation relationship
constraints

(0,1) (1,1)

(1,1) (1,N)

Nguyen Thi Hau - DBMS Chapter 3-32

Nguyen Thi Hau - DBMS Chapter 3-33
 Relationships of Higher Degree

 Relationship types of degree 2 are called binary

 Relationship types of degree 3 are called ternary and of
degree n are called n-ary
 In general, an n-ary relationship is not equivalent to n
binary relationships

Nguyen Thi Hau - DBMS Chapter 3-34

 Home work
Exercise 1:
Consider the following set of requirements for a UNIVERSITY database that is used to keep track of
students’ transcripts.
a. The university keeps track of each student’s name, student number, Social Security number,
current address and phone number, permanent address and phone number, birth date, sex, class
(freshman, sophomore,...,graduate),major department, minor department (if any),and degree
program (B.A., B.S., ..., Ph.D.). Some user applications need to refer to the city, state, and ZIP
Code of the student’s permanent address and to the student’s last name. Both Social Security
number and student number have unique values for each student.
b. Each department is described by a name, department code, office number, office phone number,
and college. Both name and code have unique values for each department.
c. Each course has a course name, description, course number, number of semester hours, level,
and offering department. The value of the course number is unique for each course.
d. Each section has an instructor, semester, year, course, and section number. The section number
distinguishes sections of the same course that are taught during the same semester/year; its values
are 1, 2, 3, ...,up to the number of sections taught during each semester.
e. A grade report has a student, section, letter grade, and numeric grade (0, 1,2,3,or 4).
Design an ER schema for this application, and draw an ER diagram for the schema. Specify key
attributes of each entity type, and structural constraints on each relationship type. Note any unspecified
requirements, and make appropriate assumptions to make the specification complete.
Nguyen Thi Hau - DBMS 35
 Home work
Exercise 2:
Consider a MAIL_ORDER database in which employees take orders for parts from
customers. The data requirements are summarized as follows:
• The mail order company has employees, each identified by a unique employee
number, first and last name, and Zip Code.
• Each customer of the company is identified by a unique customer number, first
and last name, and Zip Code.
• Each part sold by the company is identified by a unique part number, a part
name, price, and quantity in stock.
• Each order placed by a customer is taken by an employee and is given a unique
order number. Each order contains specified quantities of one or more parts.
Each order has a date of receipt as well as an expected ship date. The actual ship
date is also recorded.
Design an Entity-Relationship diagram for the mail order database and build the
design using a data modeling tool.

Nguyen Thi Hau - DBMS 36

 Home work
Exercise 3:
Consider a MOVIE database in which data is recorded about the movie industry.
The data requirements are summarized as follows:
• Each movie is identified by title and year of release. Each movie has a length in
minutes. Each has a production company, and each is classified under one or
more genres (such as horror, action, drama, and so forth). Each movie has one
or more directors and one or more actors appear in it. Each movie also has a
plot outline. Finally, each movie has zero or more quotable quotes, each of
which is spoken by a particular actor appearing in the movie.
• Actors are identified by name and date of birth and appear in one or more
movies. Each actor has a role in the movie.
• Directors are also identified by name and date of birth and direct one or more
movies. It is possible for a director to act in a movie (including one that he or
she may also direct).
• Production companies are identified by name and each has an address. A
production company produces one or more movies.
Design an Entity-Relationship diagram for the movie database and enter the design
Nguyen Thi Hau - DBMS 37
using a data modeling tool.