Chapter 3

Data Modeling Using the Entity-

Relationship (ER) Model

1
 Chapter Outline
The high-level conceptual model

ER Model Concepts

Entities, Attributes and Keys

Relationships, Associations and Constraints

ER Diagrams – Notation

Example database

Mapping ER models to Relational Tables

Slide
3- 2
 Overview of Database Design Process
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 access to the database
Generally considered part of software engineering

Slide
3- 3
 Overview of Data base Design
 Database design consists of several tasks: requirements analysis,
conceptual design, schema refinement, logical design, physical
design and tuning.
 In general, one has to go back and forth between these tasks to refine a database
design, and decisions in one task can influence the choices in another task.
 In developing a good design, one should ask: What are the important queries and
updates? What attributes/relations are involved?
 Why is database design important?
 A well-designed database facilitates data management and becomes a valuable
information generator.
 A poorly designed database is a breeding ground for uncontrolled data
redundancies.
 A poorly designed database generates errors that lead to bad decisions.

Slide
3- 4
 High-level Conceptual Model

Slide
3- 5
 Requirement Gathering & Analysis
Database designers carry out data gathering methods to

understand the requirements.

The output of this phase is concisely written set of users’

requirements.
These requirements should be specified in detail and

complete form
Functional requirements of the system are also identified at

this phase
Slide
3- 6
 Database Design
Is the process of modeling the solution domain

Conceptual design

Logical design

Physical design

Slide
3- 7
 Database Design…

 Conceptual Design

The process of constructing a model of the information used

in an enterprise, independent of all physical considerations.
 It is the source of information for the logical design phase.
 Community User’s view
The important activities are to identify
 Entities
 Attributes
 Relationships
 Constraints

 And based on these components develop the ER model

Slide
using ER diagrams to describe the data
3- 8
Finally, refinement of the schema is required to verify the
 Database Design…

Logical Design
The process of constructing a model of the information used
in an enterprise based on a specific data model (e.g.
relational), but independent of a particular DBMS and other
physical considerations.
Activities are:
 Normalization process
Collection of Rules to be maintained
 Discover new entities in the process
 Revise attributes based on the rules and the discovered
Entities

Slide
3- 9
 Database Design…

Physical Design
The process of producing a description of the
implementation of the database on secondary storage.
Describes the storage structures and access methods used to
achieve efficient access to the data.
Tailored to a specific DBMS system -- Characteristics are
function of DBMS and operating systems
Includes estimate of storage space
Activities are specifications of:
 internal storage structure
 Indexes
 Access paths
 File organizations of the databases
Slide
3- 10
 ER Model Concepts
 Entity-Relationship modeling is used to represent conceptual view of the
database
 Its purpose is to create an accurate reflection of the real world in a database.
 It gives us an intermediate step from which it is easy to define a database.
 The E-R data model is based on a perception of a real world that consists of
a set of basic objects called entities, and of relationships among these
objects.
 It was developed to facilitate database design by allowing the specification
of an enterprise schema, which represents the overall logical structure of a
database.
 The E-R data model is one of several semantic data models
 It is extremely useful in mapping the meanings and interactions of real-
world enterprises onto a conceptual scheme.
Slide
3- 11
 ER Model Concepts
Main components are:
 Entity Type or Set:
 An entity type is any type of object that we wish to store data about
 They are specific objects or things in the mini-world that are represented
in the database
 Attribute:
 is some quality about the entities that we are interested in
and want to hold on the database
 These are behaviors used to describe an entity
 Relationships:
 are communications among entities
 Constraints

Slide
3- 12
 ER….

An entity type (or entity class)

is a person, place, thing, event, or concept about which data is
collected
Each entity type shown in the conceptual model represents the
entire class for that entity
Corresponds to entire table, not row
Represented by rectangle
The name given to an entity type should always be singular
noun and descriptive
an entity is one individual/ member/ instance within an entity
type
For example, within the entity type STUDENT, Abebe might be
one entity
Slide
3- 13
 ER….

Attributes :

 Represents the property used to describe an entity or a relationship

 Are the characteristics of an entity that we are interested in.

 An attribute is a descriptor whose values are associated with individual

entities of a specific type

 Represented by Oval

 Each entity within the entity type will have the same set and number of

attributes, but in general different attribute values.

 We store the same type of facts (attributes) about every entity within the

entity type
Slide
3- 14
 ER …
 Entities and Attributes
Entities are specific objects or things in the mini-world that are
represented in the database.
 For example the EMPLOYEE John Smith, the Research
DEPARTMENT, the ProductX PROJECT
Attributes are properties used to describe an entity.
 For example an EMPLOYEE entity may have the attributes Name, ID,
Address, Sex, BirthDate
A specific entity will have a value for each of its attributes.
 For example a specific employee entity may have Name=Abebe
Kebede', ID='1234', Address ='731, Arada, AA', 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, …

Slide
3- 15
 Types of Attributes (1)
 Simple
Each entity has a single atomic value for the attribute. For example,
ID, Sex, etc.
 Composite
The attribute may be composed of several components. For example:
 Address(Apt#, House#, Street, City, State, ZipCode, Country), or
 Name(FirstName, MiddleName, LastName).
 Telephone (home, mobile, office)
 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 or
DependentName.
 Denoted as {Color} or {PreviousDegrees} or {DependentName}.

Slide
3- 16
 Types of Attributes …
 Derived
 The value is derived (computed) from the values of other
attributes.
• Age (current year – year of birth)
• Profit (earning-cost)
• G.P.A (grade point/credit hours)
 Stored : not possible to derive or compute
 Eg. Name, Address, ID, etc

 Single-valued : have only single value

 Eg. Name, sex, id. No. color_of_eyes (the value may change but
has only one value at one time)

Null Values
 attributes which are not applicable or which do not have
values.
Slide
3- 17
 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

Slide
3- 18
 Example of a composite attribute

Slide
3- 19
 Value sets of attributes
Are domains of attributes

Specify set of values that may be assigned to that

attribute for each individual entity

Eg. Age= {integer x such that: 16<= x<=90}

Value sets are not displayed in an ER diagram

Are specified using the data types of a programming

language
Slide
3- 20
 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, ID of EMPLOYEE.

 The key or uniqueness constraints on entities of an entity type is

enforced through key attributes

 They prohibit any two entities from having the same value for the

Slide
key attributes at the same time
3- 21
 Entity Types and Key Attributes
A key attribute may be composite.
VehiclePlateNumber is a key of the CAR entity type with
components (Number, City).
An entity type may have more than one key.
The CAR entity type may have two keys:
 VehicleIdentificationNumber
 VehiclePlateNumber

Each key is underlined

It prohibits any two entities from having the same
value for the key attribute at the same time
This is a constraint on all extensions of the entity type

Slide
3- 22
 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
Slide
3- 23 Derived attributes denoted by dotted ovals
 Entity is represented by a
containing the name of theRectangle
entity.

Connected entities are called relationship participants

Attributes are represented by Ovals and are

connected to the entity
by a line.

A derived attribute is indicated by a dotted line.

(……..).

Primary Keys are underlined.

Diamond
Slide
3- 24
Relationships are represented by
 Entity Type CAR with two keys and a
corresponding Entity Set

Slide
3- 25
 Example COMPANY Database
We need to create a database schema design based on
the following 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- 26
 Example COMPANY Database (Contd.)
We store each EMPLOYEE’s ID 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.

Slide
3- 27
 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

Slide
3- 28
 Initial Design of Entity Types:
EMPLOYEE, DEPARTMENT, PROJECT, DEPENDENT

Slide
3- 29
 Relationships, Associations and Constraints
A relationship relates two or more distinct entities
with a specific meaning.
For example, EMPLOYEE A B works on the ProductX
PROJECT, or EMPLOYEE X Y manages the Research
DEPARTMENT.
Relationships of the same type are grouped or typed
into a relationship type.
A relationship type R among n entity type E1, E2, …,
En is a relationship set among entities from these
entity types
For example, the WORKS_ON relationship type in which
EMPLOYEEs and PROJECTs participate, or the
Slide MANAGES relationship type in which EMPLOYEEs and
3- 30
DEPARTMENTs participate.
 Relationship Type
A relationship type R among n entity types E1,
…,En is a set of relationship instances ri, where
each ri associates n entities (e1,…,en), s.t. each ej Î
Ej. Informally, a relationship instance is an
association of entities, with exactly one entity from
each participating entity type.
The degree n of a relationship type is the number
of participating entity types.
In the ER model relationships are explicitly
represented.

Slide
3- 31
 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
Slide
The current state of a relationship type
3- 32
Relationship instances of the WORKS_FOR N:1 relationship between
EMPLOYEE and DEPARTMENT

Slide
3- 33
 Relationship instances of the M:N WORKS_ON
relationship between EMPLOYEE and PROJECT

Slide
3- 34
 Relationship type vs. relationship set

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- 35
  Example 1
 Build an ER Diagram for the following information:
 Students
 Have an Id, Name, Login, Age, Gpa
 Courses
 Have Number, Name, Credit Hours
 Students enroll in courses
 Receive a grade

Slide
3- 36
 Example 1 Answer

Name Login Age Id Name Credit

Id Gpa
Students Courses

Enrolled_In

Grade

Slide
3- 37
 Example 2
Build an ER Diagram for the following
information:
Patients
Name, Address, Phone #, Age
Drugs
Name, Manufacturer , Expiration Date
Patients are prescribed for drugs
Dosage, # Days

Slide
3- 38
 Example 2 Answer

Name Addr Phone Name Manuf Exp

Age
Patients Drug

Prescribed

Dosage #days

Slide
3- 39
 Degree, Roles and Constraints
The degree of a relationship type is the number of

participating entity types.

 Relationship types of degree 2 are called binary

 Relationship types of degree 3 are called ternary and

of degree n are called n-ary

 An n-ary relationship is not equivalent to n binary

relationships
Slide
3- 40
 Degree, Roles and Constraints
Each entity type in a relationship type plays a
particular role that is described by a role name.
Role names should be noted for every entity
type in a relation to distinguish participations
 Role names are especially important in
recursive relationship types where the same
entity participates in more
Employee
than one role:
Supervisor 1 N Supervisee

Supervision
Slide
3- 41
 Structural Constraints
Structural constraints of a relationship type:
 Cardinality ratio: Limits the number of relationship instances an
entity can participate in
 specifies maximum participation
 (Also known as multiplicity constraint)
 eg. 1:1, 1:N, M:N
 Participation constraint (Existence Dependency Constraint):
Determines whether the existence of an entity depends on its being related to
another entity via the relationship type
 If each entity of an entity type is required to participate in some
instance of a relationship type, then that participation is total;
otherwise, it is partial.
 specifies minimum participation
 zero (optional participation, not existence-dependent)
 one or more (mandatory participation, existence-dependent)
Slide
3- 42
 Structural Constraint Min, Max

A more complete specification of the

structural constraint on a relationship type
can be given by the integer pair (min, max),
which means an entity must participate in at
least min and at most max relationship
instances.

Slide
3- 43
 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 for Total,
Single otherwise
NOTE: These are easy to specify for Binary
Slide Relationship Types.
3- 44
 Many-to-one (N:1) Relationship

Slide
3- 45
 Many-to-many (M:N) Relationship

Slide
3- 46
 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)

Slide
3- 47
 ER DIAGRAM – Relationship Types are:
WORKS_FOR, MANAGES, WORKS_ON, CONTROLS, SUPERVISION, DEPENDENTS_OF

Slide
3- 48
 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 (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 (0,n) for participation of DEPARTMENT in WORKS_FOR
Slide
3- 49
 The (min,max) notation for relationship
constraints

Read the min,max numbers next to the entity type and looking away
from the entity type
Slide
3- 50
 COMPANY ER Schema Diagram using (min, max) notation

Slide
3- 51
 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.

Slide
3- 52
 Attributes of Relationship types
A relationship type can have attributes:
 For example, Hours 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 case of 1:1 or 1:N relationships, attributes can be migrated
to one of the participating entity types (on the N side of the
relationship)
 Where to place an attribute should be decided by the designer
Slide
3- 53
Example Attribute of a Relationship Type:
Hours of WORKS_ON

Slide
3- 54
 Recursive Relationship Type
A relationship type which is defined 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
Slide One employee in supervisee role
3- 55
 Displaying a recursive relationship
In a recursive relationship type.
Both participations are with 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, we need to display role names to
distinguish participations.

Slide
3- 56
 A Recursive Relationship Supervision`

Slide
3- 57
 Recursive Relationship Type is: SUPERVISION
(participation role names are shown)

Slide
3- 58
 Weak Entity Types
Are related to another entity type ( called identifying owner)
through a relationship type ( called identifying relationship), in
combination with values of a set of its own attributes (called partial
key).
A weak entity type has total participation constraint w.r.t. its
identifying relationship.
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- 59
 Summary of notation for ER diagrams

Slide
3- 60
 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
Constraints are harder to specify for higher-degree
relationships (n > 2) than for binary relationships

Slide
3- 61
 Discussion of n-ary relationships (n > 2)
In general, 3 binary relationships can
represent different information than a single
ternary relationship
If needed, the binary and n-ary relationships
can all be included in the schema design
In some cases, a ternary relationship can be
represented as a weak entity if the data model
allows a weak entity type to have multiple
identifying relationships (and hence multiple
owner entity types)
Slide
3- 62
 Examples

Slide
3- 63
 Discussion of n-ary relationships (n > 2)
If a particular binary relationship can be
derived from a higher-degree relationship at
all times, then it is redundant
For example, the TAUGHT_DURING
binary relationship in (see next slide) can be
derived from the ternary relationship
OFFERS (based on the meaning of the
relationships)

Slide
3- 64
 Another example of a ternary relationship

Slide
3- 65
 Displaying constraints on higher-degree
relationships
The (min, max) constraints can be displayed
on the edges – however, they do not fully
describe the constraints
Displaying a 1, M, or N indicates additional
constraints
An M or N indicates no constraint
A 1 indicates that an entity can participate in at
most one relationship instance that has a
particular combination of the other participating
entities
Slide In general, both (min, max) and 1, M, or N
3- 66
 Data Modeling Tools
A number of popular tools that cover conceptual
modeling and mapping into relational schema
design.
Examples: ERWin, S- Designer (Enterprise Application
Suite), ER- Studio, etc.
POSITIVES:
Serves as documentation of application requirements,
easy user interface - mostly graphics editor support
NEGATIVES:
Most tools lack a proper distinct notation for
relationships with relationship attributes
Mostly represent a relational design in a diagrammatic
Slide form rather than a conceptual ER-based design
3- 67
 ER Mapping
ER diagram focuses on representing the schema of the
database during the conceptual design
Relational model: represents the logical design of the
database
Seven steps to map ER to relation
1. Strong Entity Types:
For each entity E, create a relation R consisting of all
simple attributes of E
Only simple attributes of composite attribute should be
represented
Denote the key attributes of E as primary key of R

68
 ER Mapping
2. Weak Entity Types:
 For each weak entity type W with owner entity E, create a

relation R with all simple attributes of W

 Include the primary key of the relation R(E) as foreign key of

R
 Primary key of R is combination of partial key of W and

primary key of the owner relation R

 If there is a weak entity type E2 whose owner entity is another

weak entity E1, E1 should be mapped first to determine its

primary key
69
 ER Mapping
3. 1:1 binary relationship types:
 Identify the relations corresponding to the entity types that
participate in the relationship. Use one of the three possibilities.
 Foreign Key:
 Choose one of the relations and include as foreign key the primary key
of the other relation.
 Include all simple attributes of the relationship as well to this relation
 E.g employee manages department
 Merged relation:
 Merge the two entity types and the relationship into a single relation
 Use this when the participation of both entity types is total

 Cross-reference (relationship relation):

 Setup a separate relation R with the primary keys of the participating
relations R1 and R2
 Include all attributes of the relationship type
 The relation is termed as lookup table

70
 ER Mapping
4. 1:N binary relationship types:
 Identify the relation S denoting the entity from the N side of the

relationship type
 Include the primary key of the other relation denoting the entity

from the one side as foreign key in S

 Include any simple attributes of the relationship type in S

 E.g employee works-for department

 We can also use the cross-referencing approach. (create a separate

relation R with primary keys of the participating entity types as

attributes and setting as primary key of R key of the many side
entity)
71
 ER Mapping

4. Multivalued attributes:
 For each multivalued attribute M, create a separate relation R

 Include as attribute value that corresponds to A.

 If A is composite, include only the simple components as

attribute of R
 Include the primary key (P) of the entity type or relationship

type using A as foreign key in R

 Set as primary key of R, the combination of A and P

E.g color attribute of a car

72
 ER Mapping
6. M:N binary relationship types:
 Create a new relation R to represent the relationship type
 Include the primary keys of the participating entity types as
foreign key of R. these will be used as primary key for R
 Include any simple attribute of the relationship type
 Eg. Employee works-on project

7. N-ary relationship types:

 Create a new relation R to represent the relationship type
 Include as foreign key the primary keys of the relations
corresponding to the participating entity types
 Include any attributes of the relationship type
 The primary key of R is to be the combination of all the
foreign keys included except for a cardinality of 1
relationships
73
 Chapter Summary
ER Model Concepts: Entities, attributes, relationships
Constraints in the ER model
Using ER in step-by-step conceptual schema design
for the COMPANY database
ER Diagrams - Notation
Mapping ER to relational model

Slide
3- 74