Chapter 3

DATA MODELING USING THE

ENTITY_RELATIONSHIP (ER ) MODEL .

Slide 3- 1
• 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
• ER Diagram for COMPANY Schema

Slide 3- 2
• Two main activities:
• Database design
• Applications design

• Focus in this chapter on 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

Slide 3- 3
Slide 3- 4
• 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.
Slide 3- 5
• We store each EMPLOYEE’s social security number, address,
salary, gender, 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 the employee.
Slide 3- 6
• Entities and Attributes
• Entities is a things in the real world with an independent
existence , that are represented in the database.
It can be object with Physical existence .
It can be object with Conceptual existence .

• For example, the EMPLOYEE John Smith, the Research

DEPARTMENT, the ProductX PROJECT ,
A University course….B.Tech

• Attributes are properties used to describe an entity.

• For example an EMPLOYEE entity may have the attributes
Name, SSN, Address, Gender, DOB
Slide 3- 7
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',
Gender ='M',
DOB='09-JAN-55‘
Each attribute has a value set (or data type) associated with it –
e.g. integer, string, enumerated type, …

Slide 3- 8
• Simple
• Each entity has a single atomic value for the attribute. For
example, SSN or Sex.
• Composite
• They can be divided into smaller subparts,which represent
basic attributes.
• 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.
Slide 3- 9
Slide 3- 10
• SINGLE VALUED VS MULTIVALUED Attributes
• Single valued : Ex : AGE
• Multivalued : An entity may have multiple values for that attribute.
• For example, Color of a CAR or Previous Degrees of a STUDENT.
• Denoted as {Color} or {Previous Degrees}
• STORED Vs DERIVED ATTRIBUTES
• NULL VALUES
• COMPLEX 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)}
• Multiple PreviousDegrees values can exist
• Each has four subcomponent attributes:
• College, Year, Degree, Field Slide 3- 11
• Entities with the same basic attributes, are grouped into an
entity type.
• For example, the entity type EMPLOYEE and PROJECT.

• Imp constraint on the entities is the KEY or Uniqueness

constraint on 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.

Slide 3- 12
• A key attribute may be composite.
• If a set of attributes satisfy this uniqueness property……
Composite Key.
• EX : Vehicle_Reg_no 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:
• Vehicle Identification Number (popularly called VIN)
• Vehicle_Reg_No (Number, State), ie license plate number.
• Each key is underlined inside the oval.
Slide 3- 13
• 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 CAR example on next slide

Slide 3- 14
Slide 3- 15
• Each entity type will have a collection of entities stored in the
database
• Called the entity set
• Previous slide shows three CAR entity instances in the entity set
for CAR
• Same name (CAR) used to refer to both the entity type and the
entity set
• Entity set is the current state of the entities of that type that are
stored in the database

Slide 3- 16
• Based on the requirements listed, we can identify four initial
entity types in the COMPANY database:
• DEPARTMENT
• PROJECT
• EMPLOYEE
• DEPENDENT

• Their initial design is shown on the following slide

• The initial attributes shown are derived from the requirements
description

Slide 3- 17
Slide 3- 18
• The initial design is typically not complete .

• Some aspects in the requirements will be represented as

relationships

• Whenever an attribute of one entity type refers to another entity

type…..then some RELATIONSHIP exists .
EX :- MGR of DEPARTMENT refers to employee who manages
the dept
• Controlling dept of PROJECT refers to the department
• These references are represented as RELATIONSHIPS.

Slide 3- 19
• We introduce relationship concepts next

• 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)

Slide 3- 20
• A relationship relates two or more distinct entities with a
specific meaning.
• For example, EMPLOYEE Ruby works on the ProductX
PROJECT,
• EMPLOYEE Franklin 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.
Slide 3- 21
It associates each employee with the department for which
the employee works .
Each relationship instance in WORKS_FOR associates one EMP
entity & one DEPT entity.
Slide 3- 22
• In the mini world represented above…..
• Employees e1,e3,e6 work for department d1
• Employees e2, e4 work for department d2

In ER diagrams …..
These relationship types are depicted by diamond shaped boxes
which are connected by straight lines to rectangular boxes
representing the participating entity types.

Slide 3- 23
Slide 3- 24
• Previous figures displayed the relationship sets
• 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

Slide 3- 25
 Degree of a Relationship type : The degree of a relationship
type is the number of participating entity types. WORKS_FOR
relationship is of degree 2.
• Degree 2 is called Binary .
• Degree 3 is called Ternary .
RELATIONSHIPS shown as ATTRIBUTES
The ex of WORKS_FOR relationship type…..
NOTE ………… We can think of an attribute called Department
in the entity type EMPLOYEE.
This itself will tell about emp e1 WORKS_FOR dept D1.

Slide 3- 26
• Each entity plays a particular role In a relationship.
• Role name signifies the role that a participating entity from entity
type plays.
• Ex: Works-For relationship…..
Employee plays the role of employee or worker, and
Department plays the role of dept or employer.

• When the SAME ENTITY type participates more than once in a

relationship type, in different roles….. such relationship types are
called recursive relationships.
• In such cases ROLE NAMES become essential .
• EX: SUPERVISION relationship type
Slide 3- 27
• In a Recursive relationship type…….

• Both participations are of 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.
Slide 3- 28
Slide 3- 29
• Relationship types usually have certain Constraints which limit
that which combination of entities can or cannot participate in a
relationship.
• These constraints are there from the real world.
• For Ex:- if the company has a rule that each employee must
work for exactly ONE department…..then this can be put in the
schema.

• These are Relationship CONSTRAINTS.

• Two main types of relationship constraints
• Cardinality ratio
• Participation Slide 3- 30
• The cardinality ratio for a relationship specifies the maximum
number of relationship instances that an entity can participate in.

Ex of 1: N Relationship :-
In the Works_For relationship type,
Employee : Department is of cardinality ratio N : 1
 Each dept can be related to ‘N’ employees; but an employee can
be related to (work for) only ONE department.

Ex of 1:1 Relationship :-
In the MANAGES relationship type ,
Employee : Department is of cardinality ratio 1:1 Slide 3- 31
The MANAGES relationship goes by a real-world constraint that….
at any point in time — an employee can manage one department
only, and a department can have one manager only.

Ex of M:N relationship :-
• In the Works_on relationship type,
Employee : Project is of cardinality ratio M:N
 Each employee can work_on ‘N’ projects ;
and a project can have ‘M’ number of employees.

Slide 3- 32
• The participation constraint specifies whether the existence of an
entity depends on its being related to another entity via the
relationship type.

• This constraint specifies the minimum number of relationship

instances that each entity can participate in.

• Two types of participation constraints…..

• Total participation
• Partial participation

Slide 3- 33
 If a company policy states that “ every employee must work for a
department, “
 An employee entity can exist only if it participates in
atleast ( minimum of ) ONE Works_For relationship instance.

 So every entity (e1,e2,e3….,en) in the TOTAL SET of employee

entities MUST be related to a dept entity via Works_For.

 So, participation of Employee in Works_For is called total

participation.

 Total participation is also called Existence dependency.

Slide 3- 34
 An employee entity can exist even if it does not participates in
atleast ( minimum of ) ONE relationship instance.

 So some or part of the set of employee entities (e1,e2,e3….,en)

in the TOTAL SET , can be related to a dept entity via
MANAGES.

 So, participation of Employee in Manages Relationship is called

Partial participation.

Manages relationship is between Employee and department.

Slide 3- 35
• MANAGES : A 1 : 1 relationship type between EMPLOYEE and
DEPARTMENT .
EMPLOYEE participation : Partial
DEPARTMENT participation : Total

• WORKS_FOR : A N : 1 relationship type between EMPLOYEE

and DEPARTMENT .
EMPLOYEE participation : Total
DEPARTMENT participation : Total

Slide 3- 36
• CONTROLS : A 1 : N relationship type between
DEPARTMENT and PROJECT .
DEPARTMENT participation is Partial.
PROJECT participation is Total .

WORKS _ON : A M : N relationship type between

EMPLOYEE and PROJECT .
EMPLOYEE participation is Total.
PROJECT participation is Total.

Slide 3- 37
• SUPERVISION : A 1 : N relationship type between
EMPLOYEE ( in supervisor Role ) and EMPLOYEE ( in
supervisee Role ) .
EMPLOYEE ( Supervisor Role) participation is
Partial.
EMPLOYEE ( Supervisee Role) participation is
Partial .

Slide 3- 38
• DEPENDENTS _ OF : A 1 : N relationship type between
EMPLOYEE and DEPENDENT .
EMPLOYEE participation is Partial.
DEPENDENT participation is Total .

Slide 3- 39
• By examining the requirements, six relationship types are
identified
• 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 supervisor), EMPLOYEE (as
supervisee))
• DEPENDENTS_OF (between EMPLOYEE, DEPENDENT)
Slide 3- 40
Slide 3- 41
• In the refined design, some attributes from the initial entity
types are refined into relationships:
• Manager of DEPARTMENT -> MANAGES
• Works_on_Project 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.

Slide 3- 42
• An relationship type whose with the same participating entity type in
distinct roles
• Example: The SUPERVISION relationship

• EMPLOYEE participates twice in two distinct roles:

• supervisor (or boss) role
• supervisee (or subordinate) role

• Each relationship instance relates two distinct EMPLOYEE entities:

• One employee in supervisor role
• One employee in supervisee role
Slide 3- 43
• 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:
• A DEPENDENT entity is identified by the dependent’s 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 entity type via the identifying relationship
type DEPENDENT_OF

Slide 3- 44
• Constraints on Relationship Types
• Constraints limit the possible combinations of entities that may
participate in the corresponding relationship .
• These constraints are determined from the real world situation.
• For ex:--
If the company has a rule that each employee MUST work for
exactly one department, then we can describe this constraint in the
schema.
TWO main types of RELATIONSHIP CONSTRAINTS …..

Slide 3- 45
Cardinality Ratio : It specifies the maximum no of relationship
instances that an entity can participate in.
Ex 1 : In WORKS_FOR relationship type,
EMPLOYEE : DEPARTMENT is of Cardinality ratio N : 1
An employee can be related to 1 department, but one
department can be related to any number of employees .

Ex 2 : In MANAGES relationship type ,

EMPLOYEE : DEPARTMENT is of Cardinality ratio 1 : 1
An employee can manage one department only , and
department can have ONE manager only.
Slide 3- 46
Ex 3 : In WORKS_On relationship type ,
EMPLOYEE : PROJECT is of Cardinality ratio M : N
An employee can work on several projects , and a PROJECT
can have many employees associated .

Slide 3- 47
• This constraint specifies whether the EXISTENCE of an ENTITY
depends on its being related to another entity via a relationship
type .
• This constraint specifies the minimum no of relationship
instances that each Entity can participate in , and is sometimes
called the minimum cardinality constraint.

TWO TYPES : --

• Total Participation
• Partial Participation
Slide 3- 48
Slide 3- 49
Slide 3- 50
Slide 3- 51
• 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

Slide 3- 52
Slide 3- 53
• Cardinality ratio (of a binary relationship): 1:1, 1:N, N:1, or
M:N
• Shown by placing appropriate numbers on the relationship edges.
• Participation constraint (on each participating entity type): total
(called existence dependency) or partial.
• Total shown by double line, partial by single line.
• NOTE: These are easy to specify for Binary Relationship Types.

Slide 3- 54
• 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 (signifying no limit)
• 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 (1,n) for participation of DEPARTMENT in WORKS_FOR

Slide 3- 55
Read the min,max numbers next to the entity
type and looking away from the entity type
Slide 3- 56
Slide 3- 57
• ER diagrams is one popular example for displaying database
schemas
• Many other notations exist in the literature and in various
database design and modeling tools
• Appendix A illustrates some of the alternative notations that
have been used
• UML class diagrams is representative of another way of
displaying ER concepts that is used in several commercial design
tools

Slide 3- 58
Slide 3- 59