Entity Relationship (ER) Diagram

• ER diagram or Entity Relationship diagram is a conceptual model that gives

the graphical representation of the logical structure of the database.
• It shows all the constraints and relationships that exist among the different
components.

Components of ER Diagram

An ER diagram is mainly composed of following three components:

• Entity

• Attributes

• Relationship

Example

Consider the following Student table.

Roll_no Name Age

1 Akshay 20

2 Rahul 19

3 Pooja 20

4 Aarti 19

This complete table is referred to as “Student Entity Set” and each row
represents an “entity”.

Representation as ER Diagram

The above table may be represented as ER diagram as:

1|Page
Here,
• Roll_no is a primary key that can identify each entity uniquely. • Thus, by
using student’s roll number, a student can be identified uniquely.

Entity Sets in ER Diagram

An entity set is a set of same type of entities.

An entity refers to any object having:

• Either a physical existence such as a particular person, office, house or car.

• Or a conceptual existence such as a school, a university, a company or a job.

Types of Entity Sets

An entity set may be of the following two types. These are:

• Strong Entity Set

• Weak Entity Set

1. Strong Entity Set

• A strong entity set is an entity set that contains sufficient attributes to

uniquely identify all its entities.
• In other words, a primary key exists for a strong entity set. • Primary
key of a strong entity set is represented by underlining it.

2|Page
Symbols Used

• A single rectangle is used for representing a strong entity set. • A diamond

symbol is used for representing the relationship that exists between two
strong entity sets.
• A single line is used for representing the connection of the strong entity
set with the relationship set.
• A double line is used for representing the total participation of an entity
set with the relationship set.
• Total participation may or may not exist in the relationship.

Example

Consider the following ER diagram.

In this ER diagram,

• Two strong entity sets “Student” and “Course” are related to each other. •
Student ID and Student name are the attributes of entity set “Student”. Student
ID is the primary key using which any student can be identified uniquely.
• Course ID and Course name are the attributes of entity set “Course”. Course
ID is the primary key using which any course can be identified uniquely.
• Double line between Student and relationship set signifies total participation.
It suggests that each student must be enrolled in at least one course.
• Single line between Course and relationship set signifies partial participation.
It suggests that there might exist some courses for which no enrolments are
made.

3|Page
2. Weak Entity Set
• A weak entity set is an entity set that does not contain sufficient attributes
to uniquely identify its entities.
• In other words, a primary key does not exist for a weak entity set. •

However, it contains a partial key called as a discriminator. •

Discriminator can identify a group of entities from the entity set. •

Discriminator is represented by underlining with a dashed line.
Symbols Used
• A double rectangle is used for representing a weak entity set. • A double
diamond symbol is used for representing the relationship that exists
between the strong and weak entity sets and this relationship is known as
identifying relationship.
• A double line is used for representing the connection of the weak entity
set with the relationship set.
• Total participation always exists in the identifying relationship.
Example
Consider the following ER diagram.

In this ER diagram,

• One strong entity set “Building” and one weak entity set “Apartment” are
related to each other.
• Strong entity set “Building” has building number as its primary key. • Door
number is the discriminator of the weak entity set “Apartment”. This is
because door number alone cannot identify an apartment uniquely as there
may be several other buildings having the same door number.

4|Page
 • Double line between Apartment and relationship set signifies total
participation. It suggests that each apartment must be present in at least
one building.
• Single line between Building and relationship set signifies partial
participation. It suggests that there might exist some buildings which has
no apartment.

NOTE

• The combination of discriminator and primary key of the strong entity set
makes it possible to uniquely identify all entities of the weak entity set.
• Thus, this combination serves as a primary key for the weak entity set. •
Clearly, this primary key is not formed by the weak entity set completely.

To understand more clearly, consider the following example. To uniquely

identify any apartment,

• First, building number is required to identify the particular building. •

Secondly, door number of the apartment is required to uniquely identify the
apartment.

Thus,
Primary key of Apartment
= Primary key of Building + Its own discriminator
= Building number + Door number

Differences between Strong Entity Set and Weak Entity Set

Strong Entity Set Weak Entity Set

A single rectangle is used for the A double rectangle is used for the
representation of a strong entity representation of a weak entity set.
set.

5|Page
 It contains sufficient attributes to It does not contain sufficient attributes to
form its primary key. form its primary key.

A diamond symbol is used for the A double diamond symbol is used for the
representation of the relationship that representation of the identifying
exists between the two strong entity relationship that exists between the strong
sets. and weak entity set.
A single line is used for the A double line is used for the representation
representation of the connection of the connection between the weak entity
between the strong entity set and the set and the relationship set.
relationship.
Total participation may or may not Total participation always exists in the
exist in the relationship. identifying relationship.

Important Note

• In ER diagram, weak entity set is always present in total participation

with the identifying relationship set.
• So, we always have the picture like shown here.

6|Page
 Attributes in ER Diagram
In ER diagram,
• Attributes are associated with an entity set.

• Attributes describe the properties of entities in the entity set. • Based on the
values of certain attributes, an entity can be identified uniquely which is
called primary key.
• There exists a specific domain or set of values for each attribute from
where the attribute can take its values.

Types of Attributes

In ER diagram, attributes associated with an entity set may be of the following

types.

1. Simple Attributes
Simple attributes are those attributes which cannot be divided further.

Example

Here, all the attributes are simple attributes as they cannot be divided further.

7|Page
2. Composite Attributes

Composite attributes are those attributes which are composed of many other
simple attributes.

Example

Here, the attributes “Name” and “Address” are composite attributes as they
are composed of many other simple attributes.

3. Single Valued Attributes

Single valued attributes are those attributes which can take only one value for a
given entity from an entity set.

Example

Here, all the attributes are single valued attributes as they can take only one
specific value for each entity.

8|Page
4. Multi Valued Attributes

Multi valued attributes are those attributes which can take more than one value
for a given entity from an entity set.

Example

Here, the attributes “Mob_no” and “Email_id” are multi valued attributes as
they can take more than one values for a given entity.

5. Derived Attributes

Derived attributes are those attributes which can be derived from other
attribute(s).

Example

Here, the attribute “Age” is a derived attribute as it can be derived from the
attribute “DOB”.

9|Page
6. Key Attributes

Key attributes are those attributes which can identify an entity uniquely in an
entity set.

Example

Here, the attribute “Roll_no” is a key attribute as it can identify any student
uniquely.

Relationship in ER Diagram
A relationship is defined as an association among several entities.
Example

‘Enrolled in’ is a relationship that exists between entities Student and Course.

Relationship Set

A relationship set is a set of relationships of same type.

Example

Set representation of above ER diagram is:

10 | P a g e
Degree of a Relationship Set

The number of entity sets that participate in a relationship set is termed as the
degree of that relationship set. Thus,

Degree of a relationship set = Number of entity sets participating in a

relationship set

Types of Relationship Sets

On the basis of degree of a relationship set, a relationship set can be classified into
the following types.

• Unary relationship set

• Binary relationship set

• Ternary relationship set

• N-ary relationship set

1. Unary Relationship Set

Unary relationship set is a relationship set where only one entity set participates
in a relationship set.

Example

One person is married to only one person

2. Binary Relationship Set

Binary relationship set is a relationship set where two entity sets participate in a
relationship set.

11 | P a g e
Example

Student is enrolled in a Course.

3. Ternary Relationship Set

Ternary relationship set is a relationship set where three entity sets participate in
a relationship set.

Example

4. N-ary Relationship Set

N-ary relationship set is a relationship set where ‘n’ entity sets participate in a
relationship set.

Cardinality in ER Diagram
Cardinality Constraint

Cardinality constraint defines the maximum number of relationship instances

in which an entity can participate.

12 | P a g e
Types of Cardinality Ratios

There are 4 types of cardinality ratios. These are:

• Many-to-Many cardinality (m:n)

• Many-to-One cardinality (m:1)

• One-to-Many cardinality (1:n)

• One-to-One cardinality (1:1)

1. Many-to-Many Cardinality

By this cardinality constraint,

• An entity in set A can be associated with any number (zero or more) of
entities in set B.
• An entity in set B can be associated with any number (zero or more) of
entities in set A.

Symbol Used

Example
Consider the following ER diagram.

Here,
• One student can enrol in any number (zero or more) of courses.

• One course can be enrolled by any number (zero or more) of students.

13 | P a g e
2. Many-to-One Cardinality

By this cardinality constraint,

• An entity in set A can be associated with at most one entity in set B. • An
entity in set B can be associated with any number (zero or more) of entities
in set A.

Symbol Used

Example
Consider the following ER diagram.

Here,
• One student can enrol in at most one course.

• One course can be enrolled by any number (zero or more) of students.

14 | P a g e
3. One-to-Many Cardinality

By this cardinality constraint,

• An entity in set A can be associated with any number (zero or more) of
entities in set B.
• An entity in set B can be associated with at most one entity in set A.

Symbol Used

Example
Consider the following ER diagram.

Here,
• One student can enroll in any number (zero or more) of courses.

• One course can be enrolled by at most one student.

15 | P a g e
4. One-to-One Cardinality

By this cardinality constraint,

• An entity in set A can be associated with at most one entity in set B. •
An entity in set B can be associated with at most one entity in set A.

Symbol Used

Example
Consider the following ER diagram.

Here,
• One student can enrol in at most one course.

• One course can be enrolled by at most one student.

16 | P a g e
 Participation Constraints in DBMS
Participation constraints define the least number of relationship instances in
which an entity must compulsorily participate.

Types of Participation Constraints

There are two types of participation constraints. These are:

• Total participation

• Partial participation

1. Total Participation

• It specifies that each entity in the entity set must compulsorily participate

in at least one relationship instance in that relationship set. • That is why, it is

also called as mandatory participation. • Total participation is represented

using a double line between the entity set and relationship set.

Example

Here,
• Double line between the entity set “Student” and relationship set “Enrolled
in” signifies total participation.
• It specifies that each student must be enrolled in at least one course.

17 | P a g e
2. Partial Participation

• It specifies that each entity in the entity set may or may not participate in
the relationship instance in that relationship set.
• That is why, it is also called as optional participation.

• Partial participation is represented using a single line between the entity set
and relationship set.

Example

Here,
• Single line between the entity set “Course” and relationship set “Enrolled in”
signifies partial participation.
• It specifies that there might exist some courses for which no enrolments
are made.

How to Create an ER Diagram

Now, we will learn how to create an ER Diagram. Following are the steps to
create an ER Diagram:

18 | P a g e
Steps to Create an ER Diagram
Let’s study the steps with an ER Diagram Example.

In a university, a Student enrolls in Courses. A student must be assigned to at

least one or more Courses. Each course is taught by a single Professor. To
maintain instruction quality, a Professor can deliver only one course.

Step 1: Entity Identification

We have three entities. These are:

• Student

• Course

• Professor

Step 2: Relationship Identification

We have the following two relationships. These are:
• The student is assigned a course

• Professor delivers a course

Step 3: Cardinality Identification

From the problem statement we know that,

• A student can be assigned multiple courses

• A Professor can deliver only one course

19 | P a g e
Step 4: Identify Attributes

• You need to study the files, forms, reports, data currently maintained by
the organization to identify attributes. You can also conduct interviews
with various stakeholders to identify attributes.
• Initially, it’s important to identify the attributes without mapping them to
a particular entity.
• Once, you have a list of Attributes, you need to map them to the identified
entities.
• Ensure an attribute is to be paired with exactly one entity. If you think an
attribute should belong to more than one entity, use a modifier to make
it unique.
• Once the mapping is done, identify the primary Keys. If a unique key is
not readily available, create one.
Entity Primary Key Attribute
Student Student_ID StudentName
Professor Employee_ID ProfessorName
Course Course_ID CourseName

For Course Entity, attributes could be Duration, Credits, Assignments, etc. For the
sake of ease, we have considered just one attribute.

Step 5: Create the ERD Diagram

A more modern representation of ER Diagram of our Example.

20 | P a g e
Best Practices for Developing Effective ER Diagrams
Here are some best practice or example for Developing Effective ER Diagrams.
These are:
• Eliminate any redundant entities or relationships.

• You need to make sure that all your entities and relationships are properly
labelled.
• There may be various valid approaches to an ER diagram. You need to make

sure that the ER diagram supports all the data you need to store. • You
should assure that each entity only appears a single time in the ER diagram.
• Name every relationship, entity, and attribute are represented on your
diagram.
• Never connect relationships to each other.

• You should use colours to highlight important portions of the ER diagram.

Example ER Model

21 | P a g e
 Enhanced ER Model
Using the ER model for bigger data creates a lot of complexity while designing a
database model, So, in order to minimize the complexity Generalization,
Specialization, and Aggregation were introduced in the ER model and these were
used for data abstraction in which an abstraction mechanism is used to hide details
of a set of objects. Some of the terms were added to the Enhanced ER Model, where
some new concepts were added. These new concepts are:

22 | P a g e
 • Generalization

• Specialization

• Aggregation

Generalization

• Generalization is the process of extracting common properties from a set

of entities and creating a generalized entity from it.
• It is a bottom-up approach in which two or more entities can be generalized
to a higher-level entity if they have some attributes in common.

Example

• For Example, STUDENT and FACULTY can be generalized to a higher-

level entity called PERSON as shown in Figure.
• In this case, common attributes like P_NAME, and P_ADD become part of
a higher entity (PERSON), and specialized attributes like S_FEE become
part of a specialized entity (STUDENT).

Specialization

• In specialization, an entity is divided into sub-entities based on its

characteristics.
• It is a top-down approach where the higher-level entity is specialized into
two or more lower-level entities.

23 | P a g e
Example

• For Example, an EMPLOYEE entity in an Employee management system

can be specialized into DEVELOPER, TESTER, etc. as shown in Figure.
• In this case, common attributes like E_NAME, E_SAL, etc. become part of
a higher entity (EMPLOYEE), and specialized attributes like TES_TYPE
become part of a specialized entity (TESTER).

Specialization

Aggregation

• An ER diagram is not capable of representing the relationship between an

entity and a relationship which may be required in some scenarios. • In those

cases, a relationship with its corresponding entities is aggregated into a
higher-level entity.
• Aggregation is an abstraction through which we can represent relationships as
higher-level entity sets.

Example

• For Example, an Employee working on a project may require some

machinery. So, REQUIRE relationship is needed between the
relationship WORKS_FOR and entity MACHINERY.

24 | P a g e
 • Using aggregation, WORKS_FOR relationship with its entities
EMPLOYEE and PROJECT is aggregated into a single entity and
relationship REQUIRE is created between the aggregated entity and
MACHINERY.

Converting ER Diagrams to Tables

After designing an ER Diagram,
• ER diagram is converted into the tables in relational model. • This is
because relational models can be easily implemented by RDBMS like
MySQL, Oracle etc.

Following rules are used for converting an ER diagram into the tables.

Rule-01: For Strong Entity Set with Only Simple Attributes

• A strong entity set with only simple attributes will require only one table in
relational model.
• Attributes of the table will be the attributes of the entity set. • The
primary key of the table will be the key attribute of the entity set.

25 | P a g e
Example

Roll_no Name

Schema: Student (Roll_no, Name)

Rule-02: For Strong Entity Set with Composite Attributes

• A strong entity set with any number of composite attributes will require only
one table in relational model.
• While conversion, simple attributes of the composite attributes are taken
into account and not the composite attribute itself.

Example

26 | P a g e
 Roll_no First_name Last_name House_no Street City

Schema: Student (Roll_no, First_name, Last_name, House_no, Street, City)

Rule-03: For Strong Entity Set with Multi Valued Attributes

• A strong entity set with any number of multi valued attributes will require
two tables in relational model.
• One table will contain all the simple attributes with the primary key. •
Other table will contain the primary key and all the multi valued
attributes.

Example

Roll_no City

Roll_no Mobile_no

27 | P a g e
Rule-04: Translating Relationship Set into a Table

• A relationship set will require one table in the relational model. •

Attributes of the table are:
✓ Primary key attributes of the participating entity set
✓ Its own descriptive attributes if any.
✓ Set of non-descriptive attributes will be the primary key.

Example

Emp_no Dept_id since

Schema: Works in (Emp_no, Dept_id, since)

Primary Key will be: {Emp_no, Dept_id}

NOTE

If we consider the overall ER diagram, three tables will be required in

relational model:
• One table for the entity set “Employee”

• One table for the entity set “Department”

• One table for the relationship set “Works in”

28 | P a g e
Rule-05: For Binary Relationships with Cardinality Ratios
The following four cases are possible.

• Case-01: Binary relationship with cardinality ratio m:n

• Case-02: Binary relationship with cardinality ratio 1:n

• Case-03: Binary relationship with cardinality ratio m:1

• Case-04: Binary relationship with cardinality ratio 1:1

Case-01: For Binary Relationship with Cardinality Ratio m:n

Here, three tables will be required.

• A (a1, a2)

• R (a1, b1)

• B (b1, b2)

Case-02: For Binary Relationship with Cardinality Ratio 1:n

Here, two tables will be required.

• A (a1, a2)

• BR (a1, b1, b2)

NOTE: Here, combined table will be drawn for the entity set B and relationship
set R.

29 | P a g e
Case-03: For Binary Relationship with Cardinality Ratio m:1

Here, two tables will be required.

• AR (a1, a2, b1)

• B (b1, b2)

NOTE: Here, combined table will be drawn for the entity set A and relationship
set R.

Case-04: For Binary Relationship with Cardinality Ratio 1:1

Here, two tables will be required. Either combine ‘R’ with ‘A’ or ‘B’.
Way-01
• AR (a1, a2, b1)

• B (b1, b2)

Way-02
• A (a1, a2)

• BR (a1, b1, b2)

30 | P a g e
Thumb Rules to Remember

While determining the minimum number of tables required for binary relationships
with given cardinality ratios, following thumb rules must be kept in mind.
• For binary relationship with cardinality ration m:n, separate and

individual tables will be drawn for each entity set and relationship. • For
binary relationship with cardinality ratio either m:1 or 1:n, always
remember “many side will consume the relationship” i.e. a combined
table will be drawn for many side entity set and relationship set. • For
binary relationship with cardinality ratio 1:1, two tables will be required. You
can combine the relationship set with any one of the entity sets.

Rule-06: For Binary Relationship with Both Cardinality

Constraints and Participation Constraints

• Cardinality constraints will be implemented as discussed in Rule-05. •

Because of the total participation constraint, foreign key acquires NOT
NULL constraint i.e., now foreign key cannot be null.

Case-01: For Binary Relationship with Cardinality Constraint and Total

Participation Constraint from One Side.

Because cardinality ratio = 1:n, so we will combine the entity set B and
relationship set R. Then, two tables will be required:
• A (a1, a2)

• BR (a1, b1, b2)

Because of total participation, foreign key a1 has acquired NOT NULL

constraint, so it can’t be null now.

31 | P a g e
Case-02: For Binary Relationship with Cardinality Constraint and Total
Participation Constraint from Both Sides

If there is a key constraint from both the sides of an entity set with total
participation, then that binary relationship is represented using only single table.

Here, only one table is required.

• ARB (a1, a2, b1, b2)

Rule-07: For Binary Relationship with Weak Entity Set

Weak entity set always appears in association with identifying relationship

with total participation constraint.

Here, two tables will be required:

• A (a1, a2)

• BR (a1, b1, b2)

32 | P a g e
Practice Problems Based on Converting Er Diagram to Tables
Problem-01

Find the minimum number of tables required for the following ER diagram in
relational model.

Solution

Applying the rules, minimum 3 tables will be required:

• MR1 (M1, M2, M3, P1) [Rule 06, Case 01 – Total Participation] • P
(P1, P2)
• NR2 (P1, N1, N2) [Rule 07, Weak Entity with Total Participation]

Problem-02

Find the minimum number of tables required to represent the given ER diagram
in relational model.

33 | P a g e
Solution

Here,
• The Relationship with Entity A, Entity B, and Relationship R1 is m:1.

Entity A is in the Many (m) side and Entity B is in the One (1) side. • The
Relationship with Entity A, Entity C, and Relationship R2 is m:1. Entity A
is in the Many (m) side and Entity C is in the One (1) side. • The
Relationship with Entity B, Entity C, and Relationship R3 is m:n.

Applying the rules, minimum 4 tables will be required:

• AR1R2 (a1, a2, b1, c1) [Rule 05, Case 03 – m:1 (Many Side)] • B
(b1, b2) [Rule 05, Case 03 – m:1 (One Side)]
• C (c1, c2) [Rule 05, Case 01 – m:n (One Side)]

• R3 (b1, c1) [Rule 05, Case 01 – m:n]

Problem-03

Find the minimum number of tables required to represent the given ER diagram
in relational model.

34 | P a g e
Solution

Applying the rules, minimum 5 tables will be required:

• BR1R4R5 (b1, b2, a1, c1, d1)

• A (a1, a2)

• R2 (a1, c1)

• CR3 (c1, c2, d1)

• D (d1, d2)

Problem-04

Find the minimum number of tables required to represent the given ER diagram
in relational model.

Solution
Here,
• The Relationship with Entity E1, Entity E2, and Relationship R1 is 1:n.

Entity E1 is in the One (1) side and Entity E2 is in the Many (n) side. • The
Relationship with Entity E3, Entity E2, and Relationship R2 is m:1. Entity
E2 is in the Many (m) side and Entity E3 is in the One (1) side.

Applying the rules, minimum 3 tables will be required:

• E1 (a1, a2)

• E2R1R2 (b1, b2, b3, a1, c1)

• E3 (c1, c2)
35 | P a g e
Problem-05

Find the minimum number of tables required to represent the given ER diagram
in relational model.

Solution
Applying the rules that we have learnt; minimum 6 tables will be required:

• Account (Ac_no, Balance, b_name) [Rule 06, Case 01 – Total Participation

with 1:n relationship (Many Side)]
• Branch (b_name, b_city, Assets) (One Side)

• Loan (L_no, Amt, b_name) [Rule 06, Case 01 – Total Participation with 1:n
relationship (Many Side)]
• Borrower (C_name, L_no) [m:n Relationship]

• Customer (C_name, C_street, C_city) [m:n Relationship]

• Depositor (C_name, Ac_no) [m:n Relationship]

36 | P a g e