ENTITY RELATIONSHIP

MODEL
Title
 ENTITY RELATIONSHIP MODEL

Introduction:- The E-R model was introduced by P.P. Chen not only E-R model but also corresponding
diagramming techniques. In a database management system (DBMS), a group of similar information or
data, which is of interest to an organization is called an entity.

Components of E-R Models:

The E-R model consist of the following major components:
a) Entity
b) Attributes
c) Relationships
d) Key attributes
ENTITY:

An entity is a class of persons, places, objects, events or concepts about which we need to collect and store data .

Persons: Employee, customer, student, supplier etc.

Place: Branch office, Building, Room etc.
Objects: Book, machine, vehicle etc.
Events: Sale, Reservation, Registration, Order etc.
Concepts: Qualification, account, course, stock etc.

The instance of an entity is a single occurrences of that entity.

Example: The entity EMPLOYEE may have multiple instances or occurrences such as Raj, Mohan, Shiva, etc.

Entity set: An entity set is the collection of entities of the same type.
Example: the set of all employees of an organization can be called as the entity set employee. The set of all persons who are customer at a given bank, can be called as
the entity set Customer
ATTRIBUTES:

Each Entity can have a number of characteristics. The characteristics of an entity are called
attributes.
Example: an entity, say client, can have characteristics like Name address, phone number, balance
due etc.

Some attributes can be logically grouped into super attributes called compound attribute.
Example: An Employee’s name is a compound attribute consisting of first _name, middle_ name,
and last_ name
RELATIONSHIP:

There types of relationships exist among entities these are:

• One-to-one
• One-to-many
• Many-to many
Department Person

One-to one relationship(1:1):

Relationship is an association only between two entities.
Example: University each department has only one head of the department this is shows one-to-one
relationship between department and the person as head.
One-to-many Relationship(1:M):
When one entity is related to more than one entity.
Example: father may have many children but a child has one father. Another example two entity set
namely courses and teacher. If assume that more than one course is taught by one teacher.

Then relationship is one-to-many between teacher and courses.

Father Children Teacher Courses

1:M Relationships example
Many-to-many relationship (M:M):
A entities that may have relationship among each other.

Example:-one customer may buy many items and one item may be bought by many customers.
Another example is that a student can take many courses in a university, and many students can
register for a given course.
Customers Items Students Courses

Customers Items Students Courses

M:M Relationship example

KEY ATTRIBUTES:

The key attribute is an attribute that uniquely identifies an entity in the entity set. • Example: Employee_ code can be the key attribute for the entity set employee
because it uniquely identifies each employee entity.

SYMBOLS OF E-R MODEL:

E-R modeling use the following symbols:
Name Symbol Meaning
Rectangle Representing Entity Sets

Oval Representing Attributes

Diamond Representing Relationship among entity sets

Line Links attributes to entity and entity sets to relationship

ER DIAGRAM:

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
relationships.

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.
STRONG AND WEAK ENTITIES:

There are two types of entities namely, dependent entities also called weak entities and independent entities also
called strong entities or regular entities.

A weak entity set does not have sufficient attributes to from a primary key.
A weak entity set type is represented by a double outline rectangle.

Example: Consider an entity set type marks which represents the marks obtained by a students. Now the existence of
entity type student.
Example: Suppose a student say ‘Swati” Can have Many instances of marks say Eng_ marks, Sci_ marks, Maths_
marks etc. related to it. If the instance “Swati” is deleted, than all the entity marks dependent upon Swati.
 Student

Marks

Marks is dependent (weak) entity that is dependent on entity student.

Strong Entity:- An entity set which has a primary key is termed as a strong entity set. Example:- the
entity employee and student are strong entity because they have the primary keys Emp_no and
Adm_no.

Emp_no Adm_no

Employee Student
 DATA FLOW DIAGRAM

A data flow diagram (DFD) maps out the flow of information for any process or system. It uses
defined symbols like rectangles, circles and arrows, plus short text labels, to show data inputs,
outputs, storage points and the routes between each destination. Data flowcharts can range from
simple, even hand-drawn process overviews, to in-depth, multi-level DFDs that dig progressively
deeper into how the data is handled. They can be used to analyze an existing system or model a
new one. Like all the best diagrams and charts, a DFD can often visually “say” things that would
be hard to explain in words, and they work for both technical and nontechnical audiences, from
developer to CEO. That’s why DFDs remain so popular after all these years. While they work well
for data flow software and systems, they are less applicable nowadays to visualizing interactive,
real-time or database-oriented software or systems.
 DATA FLOW DIAGRAM COMPONENTS

• External Entities

• Process

• Data Store

• Data Flow
EXTERNAL ENTITIES:

An outside system that sends or receives data, communicating with the system being diagrammed.
They are the sources and destinations of information entering or leaving the system. They might be
an outside organization or person, a computer system or a business system. They are also known as
terminators, sources and sinks or actors. They are typically drawn on the edges of the diagram.
PROCESS:

Any process that changes the data, producing an output. It might perform computations, or sort
data based on logic, or direct the data flow based on business rules. A short label is used to describe
the process, such as “Submit payment.”
DATA STORE:

Files or repositories that hold information for later use, such as a database table or a membership
form. Each data store receives a simple label, such as “Orders.”
DATA FLOW:

The route that data takes between the external entities, processes and data stores. It portrays the
interface between the other components and is shown with arrows, typically labeled with a short
data name, like “Billing details.”

Symbol:
 DFD LEVELS AND LAYERS

A data flow diagram can dive into progressively more detail by using levels and layers, zeroing in
on a particular piece. DFD levels are numbered 0, 1 or 2, and occasionally go to even Level 3 or
beyond. The necessary level of detail depends on the scope of what you are trying to accomplish.
DFD LVL 0:

DFD Level 0 is also called a Context Diagram. It’s a basic overview of the whole system or process
being analyzed or modeled. It’s designed to be an at-a-glance view, showing the system as a single
high-level process, with its relationship to external entities. It should be easily understood by a wide
audience, including stakeholders, business analysts, data analysts and developers.
DFD LVL 1:

DFD Level 1 provides a more detailed breakout of

pieces of the Context Level Diagram. You will
highlight the main functions carried out by the
system, as you break down the high-level process
of the Context Diagram into its subprocesses.
DFD LVL 2:

DFD Level 2 then goes one step deeper into parts of

Level 1. It may require more text to reach the
necessary level of detail about the system’s
functioning.
 LOGICAL DFD VS. PHYSICAL DFD

Logical DFD Physical DFD

A Logical DFD visualizes the data flow that is A Physical DFD shows how the system is
essential for a business to operate. It focuses on actually implemented now, or how it will be.
the business and the information needed, not on For example, in a Logical DFD, the processes
how the system works or is proposed to work. would be business activities, while in a Physical
DFD, the processes would be programs and
manual procedures.
 EXAMPLE OF DFD

Logical DFD Physical DFD

THANK YOU