Chapter 3 (Module 1)

Data Modeling Using the

Entity-Relationship Model
Using High-Level Conceptual
Data Models for Database
Design
Entity Relational Data Model
ER-Model describes data as
Entities
Attributes
Relationships
 Entities and Attributes
Entity is thing in the real world with
an independent existence.

Entity may be an object with a

physical existence. For example
person,car,house or employee

Entity may be an object with a

conceptual existence. For example a
company, a job, a university, course.
 Attributes
Attribute is the particular
properties that describe entity.
The attribute values that describe
each entity become a major part of
the data stored in the database.

For example
– Employee entity may be described by
Name, Eno, Age, Address, Salary and
Dno.
Attribute & Attribute Value

Attribute
Student

ID Name Semester Branch

1AY09CS002 Asha 5 CSE

1AY08IS030 Sharon 7 ISE

Attribute Value
 Attribute Type
 Atomic Attribute
 Composite Attributes
 Single-Valued
 Multi Valued
 Stored Attribute
 Derived Attribute
Atomic Attribute
• Atomic Attribute is an attribute that
is not divisible.
• Called Atomic or Simple Attributes.
• Example

Student
Atomic Simple

First Name Last Name Age

 Composite Attributes
• Composite Attributes can be divided into
smaller subparts, which represent more
basic attributes with independent
meanings.
Composite
Attribute

Address

Street Address

City
Pincode
Composite State
Attribute? Atomic
Attribute
 Single-Valued VS Multi
Valued Attributes
• Single-Valued : attribute
has a single value for a
particular entity

• Multi Value Attribute: has

multiple values
 Example

Attribute

Age Degree

A : 24 Years A : B.Sc.
B : 27 Years B : B.Sc, M.Sc., Dr. Eng.

Attribute Value
Stored VS Derived Attributed

• Stored Attribute
• Derived Attribute: an
attribute value can be
determined from another
attribute / related entity.
 Example
Attribute

Age Birth Day Stored Attribute

A : 24 Years A : 13 July 1980

B : 40 Years B : 23 Dec 1964

Derived Attribute
Attribute Value
 Complex Attributes
• Combination of multivalued attribute and composite attribute.
• Complex attributes are attributes that are nested in an arbitrary
way.
• For example, a person can have more than one residence, and
each residence can have more than one phone, therefore it is a
complex attribute that can be represented as:
• Multi-valued attributes are displayed between braces - {}
• Composite Attributes are represented using parentheses - ()
• E.g.
{AddressPhone({Phone(AreaCode, PhoneNumber)},
Address(StreetAddress(Number, Street, ApartmentNumber),
City, State, Zip))}
Entity Type, Entity Sets, Keys,
Value Set
• Entity type defines a collection (or set) of
entities that have same attributes.
- Each entity type in the database is
described by its name and attributes.
• Entity set is the collection of all entities of a
particular entity type in a database at any
point in time.
- The entity set usually referred to using
the same name as the entity type.
 Example
Entity Type
Entity Attributes
Student

ID Name Semester Branch

1AY09CS002 Asha 5 CSE

1AY08IS030 Sharon 7 ISE

Entity Set
• An Entity Type describes the Schema or
Intension for a set of entities

• The collection of entities of a particular entity

type is grouped into an entity set, is also called as
Extension of the entity type

• An entity type is represented in ER diagram as a

rectangular box enclosing the entity name.

• Attribute names are enclosed in ovals and are

attached to their entity type by straight lines.
 Key attribute of Entity type
• An important constraint on entities of an entity type is the uniqueness
constraint.
• An attribute whose values are distinct for each individual entity in the entity
set.
• The value of key attribute must be
– Unique
– Not Null
• The values of the key attribute can be used to identify each entity uniquely.
 Key Attributes of an Entity Type
• Sometimes a key can consist of several attributes
together, where the combination of attributes is
unique for a given entity. This is called a
composite key.
• Composite keys should be minimal, meaning that
all attributes must be included to have the
uniqueness property.
• Specifying that an attribute is a key of an entity
type means that the uniqueness property must
hold true for every entity set of the entity type.
 Entity Type
• Regular Entity Type
–Entity that do have a key attribute
• Weak Entity Type
– Entity that do not have key of their own.
– Depend on other entities
– Other entities are called owner entity
– Relationship between Owner and Weak
entities is called “identifying
relationship”
 Null Value
Some case a particular entity may not
have an applicable value for an
attribute.

Example
Degree attribute applied only to a
person with collage degree.

For this situations, a special value

called null is create.
Value Sets (Domains) of Attributes
• Each simple attribute of an entity is associates with a
domain of values, or value set, which specifies the
set of values that may be assigned to that attribute
for each entity.
• For example, date of birth must be before today’s
date, and after 01/01/1900, or the Student Name
attribute must be a string of alphabetic characters.
• Value sets are not specified in ER diagrams.
• Value sets are typically specified using the basic data
types available in the programming language.
Initial Conceptual Design of
the Company Database

CompanyData
base.docx
 Example
• Entity
– Employee
– Department
– Project
– Dependent
Relationship Type, Relationship
Set, Roles and Structural
Constraints
• There are several implicit relationship among
the various entity types.
• For example, the attribute Manager of
DEPARTMENT refers to an employee who
manages the department
• Controlling_departnemt of PROJECT refers to
the department that controls the project.
 Relationship Type
• Relationship type R among n entity types
E1,E2,…,En defines a set of association or
relationship set among entities from
these entity types.
• Mathematically,
 the relationship set R is a set of
relationship instances ri,
where each ri associates n individual entities
(e1,e2,…, en) and each entity ej in ri is a
member of entity type Ej,
1 ≤ j ≤ n.
Example relationship instances of the WORKS_FOR
relationship between EMPLOYEE and DEPARTMENT

EMPLOYEE WORKS_FOR DEPARTMENT

r1
e1   d1

e2 r2


e3 r3  d2


e4  r4
d3
e5 

r5
e6 
r6
e7 

r7
 Relationships and Relationship Types
• A relationship relates two or more distinct entities
with a specific meaning.
• For example,
- EMPLOYEE “John” works on the “ProductX”
PROJECT or
- EMPLOYEE “Franklin” manages the “Research”
DEPARTMENT.
• Relationships of the same type are grouped into a
relationship type.
• For example,
- WORKS_ON relationship type in which EMPLOYEEs
and PROJECTs participate, or
- MANAGES relationship type in which EMPLOYEEs
and DEPARTMENTs participate.
 Relationship Degree
• Degree of a relationship type is the
number of participating entity types.
• For example,
Degree of a Relationship among
Teacher and Student entities is two.
• Both MANAGES and WORKS_ON are
binary relationships.
• A relationship degree two and three are
called binary and ternary, respectively.
Role Names and Recursive Relationships
• Each entity type that participates in a relationship
type plays a particular role in the relationship.
• The role name shows the role that an particular
entity from the entity type plays in each
relationship.
• Example: In the Company diagram, in the
WorksFor relationship type, the employee plays the
role of employee or worker, and the department
entity plays the role of department or employer.
Role Names and Recursive Relationships
• In some cases the same entity participates more than once in
a relationship type in different roles.
• For example, the Supervision relationship type relates an
employee to a supervisor, where both the employee and
supervisor are of the same employee entity type, therefore
the employee entity participates twice in the relationship,
once in the role of supervisor, and once in the role of
supervisee.
• 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
EMPLOYEE SUPERVISION

2
e1 1 r1

2
e2 1

r2
e3 2

1
2 r3
e4 
1
1
e5 r4
 2
1
e6
r5

2
e7 

r6
 Constraint on Relationship
Types
• Two main Type of relationship
constraints
1. Cardinality ratio
(Ratio Constraint)
2. Participation
 Cardinality Ratios

• Cardinality ratio specifies the

maximum number of relationship
instances that an entity can
participate
–1 to 1 Relationship (1:1)
–1 to many relationship (1:N)
–Many to Many relationship (N:M)
 1:1 Relationship
E1

E2 R1
D1
E3
R2 D2
E4
D3
E5 R3
D4
E6
R4
E7

Entity E2
Entity E1
Relationship
1 to Many Relationship
E1

E2 R1
D1
E3
R2 D2
E4
D3
E5 R3
D4
E6
R4
E7

Entity D
Entity E
Relationship
Many to Many Relationship
E1

E2 R1
J1
E3
R2 J2
E4
J3
E5 R3
J4
E6
R4
E7

Entity J
Entity E
Relationship
 Participation Constraints and
Existence Dependencies
• Participation Constraints specified whether
the existence of an entity depends on its
being related to another entity via the
relationship type.
• It specifies the minimum number of
relationship instance that each entity can
participate in.
• Also called as minimum cardinality
constraint.
Participation Constraints

• Partial

• Total participation
(existence dependency)

• Cardinality Ratio and Participation constraints together called as

Structural Constraints of a relationship type.
 Total participation
E1

E2 R1
D1
E3
R2 D2
E4
D3
E5 R3
D4
E6
R4
E7

Entity D
Entity E
Relationship
Partial participation
E1

E2 R1
D1
E3
R2 D2
E4
D3
E5 R3
D4
E6
R4
E7

Entity E Entity D
Relationship
 Attributes of Relationship types
• A relationship type can have attributes.
• Some attributes may be determined by the
combination of participating entities in a
relationship instances, not by single entity.
• Such attributes must be specified as relationship
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.
 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
 Weak Entity Types
• Owner entity type is also called as Parent entity type or
Dominant type.
• Weak entity type is also called as Child entity type or
Subordinate entity type
• A weak entity has Partial key - set of attributes that can
uniquely identify weak entities that are related to the same
owner entity.
• Partial key sometimes called as Discriminator.
• In company database, Dependent entity is a weak entity type.
• If we assume that no two dependents of same employee ever
have the same first name, the attribute name of Dependent is the
Partial key.
• In worst case, a composite attribute of all the weak entity’s
attributes will be the partial key.
 Refining the ER Design for the
COMPANY Database
• The following relationship types can be
specified:
1.MANAGES, a 1:1 relationship type
2.WORKS_FOR, a 1:N relationship type
3.CONTROLS, a 1:N relationship type
4.SUPERVISION, a 1:N relationship type
5.WORKS_ON, a M:N relationship type
6.DEPENDENT_OF, a 1:N relationship type
Symbol

Entity

Weak Entity

Relationship
Identifying Relationship

Attribute

Key Attribute

Composite Attribute

Derived Attribute

MultiValued Attribute
 partial Total

E1 R E2

1 N
E1 R E2

Cardinality Ratio
ER Diagram for Company Database
 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.
 Alternative (min, max) notation for
relationship structural constraints
 Specified on each participation of an entity type E in a relationship
type R
 This notation involves associating a pair of integer numbers
(min,max) with each participation of an entity type E in a
relationship type R, where 0≤min≤max and max≥1.
 The number specifies that each entity e in E participates in at
least min and at most max relationship instances in R at any
point in time.
 Default(no constraint): min=0, max=n
 In this method, min=0 implies Partial participation and
min>0 implies total participation.
 This notation is more precise and easy to specify structural
constraints for relationship types of any degree
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
The (min,max) notation
relationship constraints
(0,1) (1,1)

(1,1) (1,N)
COMPANY ER Schema Diagram
using (min, max) notation
 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
 Case Study – ER Model For a
College Database
Assumptions :
• A college contains many departments
• Each department can offer any number of courses
• Many instructors can work in a department
• An instructor can work only in one department
• For each department there is a Head
• An instructor can be head of only one department
• Each instructor can take any number of courses
• A course can be taken by only one instructor
• A student can enroll for any number of courses
• Each course can have any number of students
 ER Diagram for College Database
Department
Location
Name

Department

Pre Requisite 1 1 1
Headed
Has
Offers by
Course#

N 1 N

N 1
Duration Is taught
Course Instructor
by

N
Course Instructor
Room#
Name Name

Enrolled Telephone#
by

Student
Date of Birth

Student# Student Name

Draw a ER Diagram for Banking
Database
ER DIAGRAM FOR A BANK DATABASE

© The Benjamin/Cummings Publishing Company, Inc. 1994, Elmasri/Navathe, Fundamentals of Database Systems, Second Edition