Unit 2

Data Modeling Using the Entity-Relationship (ER)

Model
 ER Model

• An Entity–relationship model (ER model) describes the

structure of a database with the help of a diagram,
which is known as Entity Relationship Diagram (ER
Diagram).
• An ER model is a design or blueprint of a database that
can later be implemented as a database. 
• ER Model is based on the notion of real-world
entities and relationships among them.
• ER Model is best used for the conceptual design of
a database.
• ER Model is based on −
• Entities and their attributes, constraints.
• Relationships among entities.
• 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.
Example COMPANY Database
• 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 the employee.
Entities and Attributes
• Entities are specific objects or things in the mini-world
that are represented in the database.
• For example the 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, subrange, enumerated type, …
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).

• 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}.
 Types of Attributes (2)
• Derived attribute :Derived attributes are attributes
that contain values calculated from other
attributes. Age can be derived from the attribute
Birthdate.
• Composite and multi-valued attributes :
• 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
Entity Types and Key Attributes
• 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.
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.
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 CAR example on next slide
Entity Type CAR with two keys and a
corresponding Entity Set
Entity Set
• 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
 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
• Their initial design is shown on the following slide
• The initial attributes shown are derived from the
requirements description
Initial Design of Entity Types:
EMPLOYEE, DEPARTMENT, PROJECT, DEPENDENT
Refining the initial design by introducing
relationships

• The initial design is typically not complete

• Some aspects in the requirements will be
represented as relationships
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.
The degree of a relationship type is the number of
participating entity types.

• Unary (Recursive) relationship type is the relationship that involves

only one entity type.

• Binary relationship type: This relationship type has two entity types
link together. This is the most common relationship. Like
Works_On and Manages.

• Ternary relationship type: Three entity types link together.

Relationship instances of the WORKS_FOR N:1 relationship
between EMPLOYEE and DEPARTMENT
Relationship instances of the M:N WORKS_ON
relationship between EMPLOYEE and PROJECT
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
Relationship type vs. relationship set (2)

• 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
 Emp_no  Dept_id  since 

  
   
  
Refining the COMPANY database schema by
introducing relationships
• 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 subordinate),
EMPLOYEE (as supervisor))
• DEPENDENTS_OF (between EMPLOYEE, DEPENDENT)
ER DIAGRAM – Relationship Types are:
WORKS_FOR, MANAGES, WORKS_ON, CONTROLS, SUPERVISION, DEPENDENTS_OF
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

• 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.
Recursive Relationship Type
• 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
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:

• 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
Constraints on Relationships
• Constraints on Relationship Types
(Also known as ratio constraints)
• 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)
Displaying a recursive relationship
• 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 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.
A Recursive Relationship Supervision`
Recursive Relationship Type is: SUPERVISION
(participation role names are shown)
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
Example Attribute of a Relationship Type:
Hours of WORKS_ON
Notation for Constraints on
Relationships
• 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.
Summary of notation for ER diagrams