THE ENTITY

RELATION
DIAGRAM
LESSON 3
LEARNING
COMPETENCY
Document the program scope and limits according to project
standards [TLE_ICTCP9-12PLIIa-j-2]
Learning Objectives:
What am I learning?
 List the components of an Entity Relationship Diagram (ERD) that are
essential for defining the scope and limits of a database project.

Why am I learning it?

 Break down a database design project into its core entities and
relationships to determine the scope and identify any potential limits or
constraints.
2
LEARNING
COMPETENCY
Document the program scope and limits according to project
standards [TLE_ICTCP9-12PLIIa-j-2]

Learning Objectives:

How will I know when I have learned it?

• Develop a detailed Entity Relationship Diagram (ERD) and
accompanying documentation that clearly defines the program scope
and limits according to project standards.

3
Introduction to
ENTITY
RELATION
DIAGRAM
LESSON 3.1
 WHAT IS ERD?
An Entity Relationship Diagram is a diagram that
represents relationships among entities in a
database. It is commonly known as an ER
Diagram. An ER Diagram in DBMS plays a crucial
role in designing the database. Today’s business
world previews all the requirements demanded
by the users in the form of an ER Diagram. Later,
it's forwarded to the database administrators to
design the database.
 WHAT IS ERD?
An Entity Relationship Diagram (ER Diagram)
pictorially explains the relationship between
entities to be stored in a database.
Fundamentally, the ER Diagram is a structural
design of the database.
It acts as a framework created with specialized
symbols for the purpose of defining the
relationship between the database entities. ER
diagram is created based on three principal
components: entities, attributes, and
The following diagram showcases two entities -
Student and Course, and their relationship. The
relationship described between student and
course is many-to-many, as a course can be
opted by several students, and a student can opt
for more than one course. Student entity
possesses attributes - Stu_Id, Stu_Name &
Stu_Age. The course entity has attributes such as
Cou_ID & Cou_Name.
WHAT IS ER Model?
An Entity-Relationship Model represents
the structure of the database with the
help of a diagram. ER Modelling is a
systematic process to design a
database as it would require you to
analyze all data requirements before
implementing your database.
HISTORY OF ER Model?
Peter Chen proposed ER Diagrams in
1971 to create a uniform convention
that can be used as a conceptual
modeling tool. Many models were
presented and discussed, but none
were suitable. The data structure
diagrams offered by Charles Bachman
also inspired his model.
 Why Use ER Diagrams in
•
DBMS?
ER Diagram helps you conceptualize
the database and lets you know
which fields need to be embedded for
a particular entity.
• ER Diagram gives a better
understanding of the information to
be stored in a database
 Why Use ER Diagrams in
•
DBMS?
It reduces complexity and allows
database designers to build
databases quickly.
• It helps to describe elements using
Entity-Relationship models.
• It allows users to get a preview of the
logical structure of the database.
 Symbols Used in ER
•
Diagrams
Rectangles: This Entity Relationship
Diagram symbol represents entity
types
• Ellipses: This symbol represents
attributes
• Diamonds: This symbol represents
relationship types
 Symbols Used in ER
•
Diagrams
Lines: It links attributes to entity
types and entity types with other
relationship types
• Primary key: Here, it underlines the
attributes
• Double Ellipses: Represents multi-
valued attributes
 Components of ER Diagram
an ER Diagram based on three basic
concepts:
Entities Attributes Relationships
-One-to-One Relationships
-One-to-Many Relationships
-Weak Entity -Key Attribute
-Many-to-One Relationships
-Composite -Many-to-Many
Attribute Relationships
-Multivalued
Attribute
-Derived Attribute
1. Entities
An entity can be either a
living or non-living
component.
It showcases an entity as a
rectangle in an ER diagram.
Entities
For example, in a student study course,
both the student and the course are
entities.
WEAK Entity
An entity that makes reliance over
another entity is called a weak
entity

You showcase the weak entity as a

double rectangle in ER Diagram.
WEAK ENTITY
In the example below, school is a strong entity because it has
a primary key attribute - school number. Unlike school, the
classroom is a weak entity because it does not have any
primary key and the room number here acts only as a
discriminator.
2. attribute

An attribute exhibits the

properties of an entity.
attributes
You can illustrate an attribute with an
oval shape in an ER diagram.
Types of attribute
-KEY attribute
Key attribute uniquely
identifies an entity from an
entity set.

It underlines the text of a key

attribute.
Key attribute
For example: For a student entity, the roll
number can uniquely identify a student
from a set of students.
COMPOSITE attribute
An attribute that is composed
of several other attributes is
known as a composite
attribute.
composite attribute
An oval showcases the composite
attribute, and the composite attribute
oval is further connected with other
ovals.
multivalued attribute
Some attributes can possess
over one value, those attributes
are called multivalued
attributes.
multivalued attribute
The double oval shape is used to
represent a multivalued attribute.
multivalued attribute
For example, a customer entity allows only
one telephone number for each customer. If
a customer has more than one phone
number and wants all of them in the
database, then the customer entity cannot
handle them.
derived attribute
An attribute that can be derived
from other attributes of the entity is
known as a derived attribute. those
that may be computed from other
attributes, such as totals
derived attribute
In the ER diagram, the dashed oval
represents the derived attribute. For
example, if we have an attribute for birth
date then age is derivable.
3. Relationship
The diamond shape showcases a
relationship in the ER diagram.

It depicts the relationship

between two entities.
Relationship
In the example below, both the student and the
course are entities, and study is the relationship
between them.
One-to-One Relationship
When a single element of an
entity is associated with a single
element of another entity, it is
called a one-to-one relationship.
One-to-one Relationship
For example, a student has only one
identification card and an
identification card is given to one
person.
One-to-many Relationship
When a single element of an
entity is associated with more
than one element of another
entity, it is called a one-to-
many relationship
One-to-many Relationship
For example, a customer can place
many orders, but an order cannot be
placed by many customers.
many-to-one Relationship
When more than one element
of an entity is related to a
single element of another
entity, then it is called a many-
to-one relationship.
many-to-one Relationship
For example, students have to opt for a
single course, but a course can have
many students.
many-to-many
Relationship
Many-to-Many Relationship
When more than one element of
an entity is associated with more
than one element of another
entity, this is called a many-to-
many relationship.
many-to-one Relationship
For example, you can assign an
employee to many projects and a
project can have many employees.
How to Draw an ER
Diagram?
Below are some important points to draw ER
diagram:

• First, identify all the Entities. Embed all the

entities in a rectangle and label them properly.

• Identify relationships between entities and

connect them using a diamond in the middle,
illustrating the relationship. Do not connect
How to Draw an ER
Diagram?
Below are some important points to draw ER
diagram:

• Connect attributes for entities and label them

properly.
• Eradicate any redundant entities or
relationships.
• Make sure your ER Diagram supports all the data
Conclusion
ER Diagram in DBMS is widely
used to describe the conceptual
design of databases. It helps both
users and database developers to
preview the structure of the
database before implementing
the database.
 IN T R O D U C T I O
N T O
DATAB AS E
GN
LESSON 3.2
Database Design in DBMS
Database Design can be defined as a set
of procedures or collection of tasks
involving various steps taken to implement
a database.

However, depending on specific

requirements above criteria might change.
But these are the most common things
Following are some critical points to keep in
mind to achieve a good database design:
1.Data consistency and integrity must be
maintained.
2. Low Redundancy
3. Faster searching through indices
4. Security measures should be taken by
enforcing various integrity constraints.
5. Data should be stored in fragmented bits of
information in the most atomic format
possible.
Steps that a Database Designer can
take to Ensure Good Database Design

Step 1: Determine the goal of your database,

and ensure clear communication with the
stakeholders (if any). Understanding the
purpose of a database will help in thinking of
various use cases & where the problem may
arise & how we can prevent it.
Step 2: List down all the entities that will be
present in the database & what relationships
Steps that a Database Designer can
take to Ensure Good Database Design

Step 3: Organize the information into different

tables such that no or very little redundancy is
there.
Step 4: Ensure uniqueness in every table. The
uniqueness of records present in any relation is
a very crucial part of database design that helps
us avoid redundancy. Identify the key attributes
to uniquely identify every row from columns…
Steps that a Database Designer can
take to Ensure Good Database Design

You can use various key constraints to ensure the

uniqueness of your table, also keep in mind the
uniquely identifying records must consume as little
space as possible & shall not contain any NULL values.
Step 5: After all the tables are structured, and
information is organized apply Normalization Forms to
identify anomalies that may arise & redundancy that
can cause inconsistency in the database.
Primary Terminologies Used in
Database Design
Following are the terminologies that a person
should be familiar with before designing a
database:
•Redundancy: refers to the duplicity of the
data. There can be specific use cases when
we need or don’t need redundancy in our
Database. For ex: If we have a banking
system application then we may need to
Primary Terminologies Used in
Database Design
Following are the terminologies that a person
should be familiar with before designing a
database:
•Schema: is a logical container that
defines the structure & manages the
organization of the data stored in it. It
consists of rows and columns having
data types for each column.
Primary Terminologies Used in
Database Design
Following are the terminologies that a person
should be familiar with before designing a
database:
•Records/Tuples: is the same thing,
basically its where our data is stored
inside a table
•Indexing: is a data structure
technique to promote efficient
Primary Terminologies Used in
Database Design
Following are the terminologies that a person
should be familiar with before designing a
database:
•Data Integrity & Consistency:
Data integrity refers to the quality of
the information stored in our
database and consistency refers to
the correctness of the data stored.
Primary Terminologies Used in
Database Design
Following are the terminologies that a person
should be familiar with before designing a
database:
•Data Models: provide us with
visual modeling techniques to
visualize the data & the relationship
that exists among those data. Ex:
model, Network Model, Object
Primary Terminologies Used in
Database Design
Following are the terminologies that a person
should be familiar with before designing a
database:
•Functional Dependency: is a
relationship between two attributes of
the table that represents that the value
of one attribute can be determined by
another. Ex: {A -> B}, A & B are two
Primary Terminologies Used in
Database Design
Following are the terminologies that a person
should be familiar with before designing a
database:
•Transaction: is a single logical unit
of work. It signifies that some
changes are made in the database.
Primary Terminologies Used in
Database Design
Following are the terminologies that a person
should be familiar with before designing a
database:
•Schedule: defines the sequence of
transactions in which they’re
executed by one or multiple users.
Primary Terminologies Used in
Database Design
Following are the terminologies that a person
should be familiar with before designing a
database:
•Concurrency: refers to allowing
multiple transactions to operate
simultaneously without interfering
with one another.
 DATABASE DESIGN LIFE
CLYCLE

1. Requirement Analysis
It’s very crucial to understand the requirements of our application
so that you can think in productive terms. And imply appropriate
integrity constraints to maintain the data integrity & consistency.
 DATABASE DESIGN LIFE
CLYCLE
2. Logical & Physical Design
This is the actual design phase that involves
various steps that are to be taken while
designing a database. This phase is further
divided into two stages:

• Logical Data Model Design: This phase

consists of coming up with a high-level design
of our database based on initially gathered
 DATABASE DESIGN LIFE
CLYCLE
A high-level overview on paper is made of the
database without considering the physical level
design, this phase proceeds by identifying the
kind of data to be stored and what relationship will
exist among those data.
Entity, Key attributes identification & what
constraints are to be implemented is the core
functionality of this phase. It involves techniques
such as Data Modeling to visualize data,
 DATABASE DESIGN LIFE
CLYCLE
An Example of Physical
Design
 DATABASE DESIGN LIFE
CLYCLE

An Example of Logical
Design
 DATABASE DESIGN LIFE
CLYCLE
3. Data Insertion and testing for various
integrity constraints
Finally, after implementing the physical design of
the database, we’re ready to input the data & test
our integrity. This phase involves testing our
database for its integrity to see if something got
left out or, if anything new to add & then
integrating it with the desired application.
 DATABASE DESIGN LIFE
CLYCLE
Physical Design of Data Model: This
phase involves the implementation of
the logical design made in the previous
stage. All the relationships among data
and integrity constraints are
implemented to maintain consistency &
generate the actual database.
 DATABASE DESIGN LIFE
CLYCLE
Logical Data Model Design
The logical data model design defines
the structure of data and what
relationship exists among those data.
The following are the major components
of the logical design:
 DATABASE DESIGN LIFE
1. Data Models: Data modeling is a visual modeling technique
used to get a high-levelCLYCLE
overview of our database. Data models
help us understand the needs and requirements of our database by
defining the design of our database through diagrammatic
representation. Ex: model, Network model, Relational Model,
object-oriented data model.
 DATABASE DESIGN LIFE
CLYCLE
2. Entities are objects in the real world, which can have
certain properties & these properties are referred to as
attributes of that particular entity. There are 2 types of
entities: Strong and weak entity, weak entity do not have a
key attribute to identify them, their existence solely depends
on one 1-specific strong entity & also have full participation
in a relationship whereas strong entity does have a key
attribute to uniquely identify them.

Weak entity example: Loan -> Loan will be given to a

customer (which is optional) & the load will be identified by
the customer_id to whom the lone is granted.
 DATABASE DESIGN LIFE
CLYCLE
3. Relationships: How data is logically related to
each other defines the relationship of that data
with other entities. In simple words, the
association of one entity with another is defined
here.
A relationship can be further categorized into –
unary, binary, and ternary relationships.
• Unary: In this, the associating entity & the associated
entity both are the same. Ex: Employee Manages
themselves, and students are also given the post of monitor
 DATABASE DESIGN LIFE
• Binary: This is a very common relationship that
CLYCLE
you will come across while designing a database.
Ex: Student is enrolled in courses, Employee is
managed by different managers, One student
can be taught by many professors.
• Ternary: In this, we have 3 entities involved in a
single relationship. Ex: an employee works on a
project for a client. Note that, here we have 3
entities: Employee, Project & Client.
 DATABASE DESIGN LIFE
4. Attributes: Attributes are nothing but properties of a specific
CLYCLE
entity that define its behavior. For example, an employee can have
unique_id, name, age, date of birth (DOB), salary, department,
Manager, project id, etc.

5. Normalization: After all the entities are put in place and the
relationship among data is defined, we need to look for loopholes
or possible ambiguities that may arise.

Data Normalization is a basic procedure defined for databases to

eliminate such anomalies & prevent redundancy.
WRITTEN TASK 3

DATABASE ANALYSIS

Direction: Make a database design based on the

case studies we discussed in the previous lesson.
Break down the essential details into their core
entities and relationships.

74
WRITTEN TASK 3

1. School Management System

2. Online Retail Store
3. Hospital Management System
4. Library Management System
5. Employee Management System

75
 RUBRICS

CRITERIA DESCRIPTION SCORE

Identification of Tables, Accurately identifies all necessary
Fields & Relationships tables, fields and Relationship with 10
strong justification for each.
Clarity and Organization The analysis is exceptionally clear,
well-organized, and easy to follow 10
Justification and Analysis Provides thorough and insightful
justification for all identified
components, showing a deep 10
understanding of database design
principles.
TOTAL 30
PERFORMANCE CHECK
3
ENTITY RELATIONSHIP
DIAGRAM ANALYSIS

Direction: Develop a detailed Entity Relationship

Diagram (ERD) based on the case studies we
discussed in the previous lesson. Define the
necessary details according to project standards.

77
1. School Management System
2. Online Retail Store
3. Hospital Management System
4. Library Management System
5. Employee Management System

78
 RUBRICS

CRITERIA DESCRIPTION SCORE

Identification of Tables, Accurately identifies all necessary
Fields & Relationships tables, fields and Relationship with 10
strong justification for each.
Clarity and Organization The analysis is exceptionally clear,
well-organized, and easy to follow 10
Justification and Analysis Provides thorough and insightful
justification for all identified
components, showing a deep 10
understanding of entity relationship
diagram design principles.
TOTAL 30