UNIT 1 ER Model 2025 -Entity Relationship (ER) Diagram

Database Management System (DBMS)
Sanjivani Rural Education Society’s
Sanjivani College of Engineering, Kopargaon-423603
(An Autonomous Institute Affiliated to Savitribai Phule Pune University, Pune)
NACC ‘A’ Grade Accredited, ISO 9001:2015 Certified
Department of Information Technology
(NBA Accredited)
Mr. R. N. Kankrale
Assistant Professor
SY IT

Entity-Relationship Model
• 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.
• https://www.gatevidyalay.com/er-diagrams/
DBMS – Unit-I: Part-I Mr. R. N. Kankrale Department of Information Technology

Components of ER diagram
• An ER diagram is mainly composed of following three components-
• Entity Sets
• Attributes
• Relationship Set
• 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-
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.

ER Diagram Symbols-
1. For Entity Sets-
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 or a company.

ER Diagram Symbols-
1. Strong Entity Set-
A strong entity set possess its own primary key.
It is represented using a single rectangle.
2. Weak Entity Set-
A weak entity set do not possess its own primary key.
It is represented using a double rectangle.

ER Diagram Symbols-
2. For Relationship Sets-
•Relationship defines an association among several entities.
•A relationship set is a set of same type of relationships.
A relationship set may be of the following two types-

ER Diagram Symbols-
. Strong Relationship Set-
•A strong relationship exists between two strong entity sets.
•It is represented using a diamond symbol.
2. Weak Relationship Set-
•A weak or identifying relationship exists between the strong and weak entity set.
•It is represented using a double diamond symbol.

ER Diagram Symbols-
3. For Attributes-
•Attributes are the properties which describes the entities of an entity set.
•There are several types of attributes.

ER Diagram Symbols-
3. For Attributes-
•Attributes are the properties which
describes the entities of an entity set.
•There are several types of attributes.
1.Simple attributes
2.Composite attributes
3.Single valued attributes
4.Multi valued attributes
5.Derived attributes
6.Key attributes

ER Diagram Symbols-
1. Simple Attributes-
Simple attributes are those attributes which can not be divided further.
Here, all the attributes are simple
attributes as they can not be divided
further.

ER Diagram Symbols-
2. Composite Attributes-
Composite attributes are those attributes which are
composed of many other simple attributes.
Here, the attributes “Name”
and “Address” are composite
attributes as they are
composed of many other
simple attributes.

ER Diagram Symbols-
3. Single Valued Attributes-
Single valued attributes are those attributes which can take only one value for a given entity from an
entity set.
Here, all the attributes are single valued attributes as they can take
only one specific value for each entity.

ER Diagram Symbols-
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.
Here, the attributes “Mob_no” and “Email_id” are multi valued attributes
as they can take more than one values for a given entity.

ER Diagram Symbols-
5. Derived Attributes-
Derived attributes are those attributes which can be derived from other attribute(s).

ER Diagram Symbols-
6. Key Attributes-
Key attributes are those attributes which can identify an entity uniquely in an entity set.
Here, the attribute “Roll_no” is a key attribute as it can identify any student
uniquely.

ER Diagram Symbols-
4. For Participation Constraints-
Participation constraint defines the least number of relationship
instances in which an entity has to necessarily participate.

ER Diagram Symbols-

ER Diagram Symbols-
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.

ER Diagram Symbols-
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.

ER Diagram Symbols-
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.

ER Diagram Symbols-
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
enrollments are made.

ER Diagram Symbols-
Relationship between Cardinality and Participation
Constraints-
Minimum cardinality tells whether the participation is partial or
total.
•If minimum cardinality = 0, then it signifies partial
participation.
•If minimum cardinality = 1, then it signifies total participation.
Maximum cardinality tells the maximum number of entities that
participates in a relationship set.

ER Diagram Symbols-
6. For Cardinality Constraints / Ratios-
Cardinality constraint defines the maximum number
of relationship instances in which an entity can
participate.

ER Diagram Symbols-
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.

ER Diagram Symbols-
Example-
Here,
•One student can enroll in any number (zero or more) of courses.
•One course can be enrolled by any number (zero or more) of
students.

ER Diagram Symbols-
2. Many-to-One Cardinality-
•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.

Example-
Consider the following ER diagram-
Here,
•One student can enroll in at most one course.
•One course can be enrolled by any number (zero or more) of
students.

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-
Here,
•One student can enroll in any number (zero or more) of courses.
•One course can be enrolled by at most one student.

4. One-to-One Cardinality-
•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-

ER Diagram Symbols-
Example-
Here,
•One student can enroll in at most one course.
•One course can be enrolled by at most one student.

ER Diagram Symbols-
5. For Specialization and
Generalization-
•Generalization is a process of
forming a generalized super class
by extracting the common
characteristics from two or more
classes.
•Specialization is a reverse process
of generalization where a super
class is divided into sub classes by
assigning the specific
characteristics of sub classes to
them.

Draw of ER model
https://www.tutorialspoint.com/construct-an-er-diagram-for-a-company-in-d
bms
Problem
Draw of ER model for company considering the following constraints −
In a company, an employee works on many projects which are controlled by
one department.
•One employee supervises many employees.
•An employee has one or more dependents.
•One employee manages one department.

Draw of ER model
Solution
Follow the steps given below to draw an ER model for the company −
Step 1 − Identify the entity sets
The entity set has multiple instances in a given business scenario.
As per the given constraints the entity sets are as follows:
•Employee
•Department
•Project
•Dependent

Draw of ER model
Step 2 − Identify the attributes for the given entities
•Employee The relevant attributes are name, ssn, sex, address,
−
salary.
•Department The relevant attributes are Name, number of
−
employees, location.
•Project The relevant attributes are number, name, location.
−
•Dependent The relevant attributes are name, sex, birth date,
−
relationship.

Draw of ER model
Step 2 − Identify the attributes for the given entities
•Employee The relevant attributes are name, ssn, sex,
−
address, salary.
•Department The relevant attributes are Name, number
−
of employees, location.
•Project The relevant attributes are number, name,
−
location.
•Dependent The relevant attributes are name, sex, birth
−
date, relationship.

ER Diagram Symbols-
Step 3 − Identify the Key attributes
•SSN is the key attribute for Employee.
•Number is the key attribute for the Department.
•Number is the key attribute for Project.
•Name is the key attribute for a dependent entity.

ER Diagram Symbols-
Step 4 − Identify the relationship between entity sets
Multiple employees work for a single department and
one department has multiple employees. Hence, the
relationship between employee and department is many
to one.

ER Diagram Symbols-
Single employee manages the entire department
and one department is handled by one manager.

ER Diagram Symbols-
Each department is controlled by the number of
projects and the number of projects handled by
a single department. Hence, the relationship
between department and project is one-to-
many..

Entity Relationship Modeling Examples
The Music Database
https://www.oreilly.com/library/view/learning-mysql/0596008643/ch04s04.html
The music database stores details of a personal music library, and could be
used to manage your MP3, CD, or vinyl collection. Because this database is for
a personal collection, it’s relatively simple and stores only the relationships
between artists, albums, and tracks. It ignores the requirements of many music
genres, making it most useful for storing popular music and less useful for
storing jazz or classical music.

We first draw up a clear list of requirements for our database:
•The collection consists of albums.
•An album is made by exactly one artist.
•An artist makes one or more albums.
•An album contains one or more tracks
•Artists, albums, and tracks each have a name.
•Each track is on exactly one album.
•Each track has a time length, measured in seconds.
•When a track is played, the date and time the playback began
(to the nearest second) should be recorded; this is used for
reporting when a track was last played, as well as the number of
times music by an artist, from an album, or a track has been
played.

You’ll notice that it consists of only one-to-many relationships:
one artist can make many albums, one album can contain many
tracks, and one track can be played many times. Conversely, each
play is associated with one track, a track is on one album, and an
album is by one artist. The attributes are straightforward: artists,
albums, and tracks have names, as well as identifiers to uniquely
identify each entity. The track entity has a time attribute to store
the duration, and the played entity has a timestamp to store when
the track was played.

The University Database
The university database stores details about university students, courses, the
semester a student took a particular course (and his mark and grade if he
completed it), and what degree program each student is enrolled in. The
database is a long way from one that’d be suitable for a large tertiary
institution, but it does illustrate relationships that are interesting to query,
and it’s easy to relate to when you’re learning SQL. We explain the
requirements next and discuss their shortcomings at the end of this section.

Consider the following requirements list:
The university offers one or more programs.
A program is made up of one or more courses.
A student must enroll in a program.

A student takes the courses that are part of her program.
A program has a name, a program identifier, the total credit points
required to graduate, and the year it commenced.
A course has a name, a course identifier, a credit point value, and the
year it commenced.

Students have one or more given names, a surname, a student identifier,
a date of birth, and the year they first enrolled. We can treat all given
names as a single object—for example, “John Paul.”
When a student takes a course, the year and semester he attempted it
are recorded. When he finishes the course, a grade (such as A or B) and a
mark (such as 60 percent) are recorded.
Each course in a program is sequenced into a year (for example, year 1)
and a semester (for example, semester 1).

The Flight Database
The flight database stores details about an airline’s fleet, flights, and
seat bookings. Again, it’s a hugely simplified version of what a real
airline would use, but the principles are the same.

Consider the following requirements list:
•The airline has one or more airplanes.
•An airplane has a model number, a unique registration number, and the
capacity to take one or more passengers.
•An airplane flight has a unique flight number, a departure airport, a
destination airport, a departure date and time, and an arrival date and time.
•Each flight is carried out by a single airplane.
•A passenger has given names, a surname, and a unique email address.
•A passenger can book a seat on a flight.

• https://www.guru99.com/er-diagram-tutorial-dbms.html

• 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
•Student
•Course
Professor
Step 2) Relationship Identification
We have the following two relationships
•The student is assigned a course
•Professor delivers a course

Step 3) Cardinality Identification
For them problem statement we know that,
•A student can be assigned multiple courses
•A Professor can deliver only one course

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 entities. 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
Once the mapping is done, identify the primary Keys. If a unique key
is not readily available, create one.

Best Practices for Developing Effective ER Diagrams
• Eliminate any redundant entities or relationships
• You need to make sure that all your entities and relationships are
properly labeled
• 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 colors to highlight important portions of the ER
diagram

Entity-Relationship Model
 Design Process
 Modeling
 Constraints
 E-R Diagram
 Design Issues
 Weak Entity Sets
 Extended E-R Features
 Design of the Bank Database
 Reduction to Relation Schemas
 Database Design

Design Approaches
 Entity Relationship Model (covered in this chapter)
 Models an enterprise as a collection of entities and relationships
 Entity: a “thing” or “object” in the enterprise that is distinguishable from other objects
– Described by a set of attributes
 Relationship: an association among several entities
 Represented diagrammatically by an entity-relationship diagram:
 Normalization Theory
 Formalize what designs are bad, and test for them

ER model -- Database Modeling
 The ER data mode was developed to facilitate database design by allowing specification of an enterprise
schema that represents the overall logical structure of a database.
 The ER model is very useful in mapping the meanings and interactions of real-world enterprises onto a
conceptual schema. Because of this usefulness, many database-design tools draw on concepts from the ER
model.
 The ER data model employs three basic concepts:
 entity sets,
 relationship sets,
 attributes.
 The ER model also has an associated diagrammatic representation, the ER diagram, which can express the
overall logical structure of a database graphically.

Entity Sets
 An entity is an object that exists and is distinguishable from other objects.
 Example: specific person, company, event, plant
 An entity set is a set of entities of the same type that share the same properties.
 Example: set of all persons, companies, trees, holidays
 An entity is represented by a set of attributes; i.e., descriptive properties possessed by all members of an
entity set.
 Example:
 instructor = (ID, name, street, city, salary )
course= (course_id, title, credits)
 A subset of the attributes form a primary key of the entity set; i.e., uniquely identifiying each member of the
set.

Entity Sets -- instructor and student
instructor_ID instructor_name student-ID student_name

Relationship Sets
 A relationship is an association among several entities
Example:
44553 (Peltier) advisor 22222 (Einstein)
student entity relationship set instructor entity
 A relationship set is a mathematical relation among n  2 entities, each taken from
entity sets
{(e1, e2, … en) | e1  E1, e2  E2, …, en  En}
where (e1, e2, …, en) is a relationship
 Example:
(44553,22222)  advisor

Relationship Set advisor

Relationship Sets (Cont.)
 An attribute can also be associated with a relationship set.
 For instance, the advisor relationship set between entity sets instructor and student may have the
attribute date which tracks when the student started being associated with the advisor

Degree of a Relationship Set
 binary relationship
 involve two entity sets (or degree two).
 most relationship sets in a database system are binary.
 Relationships between more than two entity sets are rare. Most relationships are binary. (More
on this later.)
 Example: students work on research projects under the guidance of an instructor.
 relationship proj_guide is a ternary relationship between instructor, student, and project

Mapping Cardinality Constraints
Mapping Cardinality Constraints
 Express the number of entities to which another entity can be associated via a relationship set.
 Most useful in describing binary relationship sets.
 For a binary relationship set the mapping cardinality must be one of the following types:
 One to one
 One to many
 Many to one
 Many to many

Mapping Cardinalities
Note: Some elements in A and B may not be mapped to any
elements in the other set
One to one One to many

Note: Some elements in A and B may not be mapped to any
elements in the other set
many to one many to many

Complex Attributes
Complex Attributes
 Attribute types:
 Simple and composite attributes.
 Single-valued and multivalued attributes
 Example: multivalued attribute: phone_numbers
 Derived attributes
 Can be computed from other attributes
 Example: age, given date_of_birth
 Domain – the set of permitted values for each attribute

Composite Attributes
Composite Attributes

Redundant Attributes
Redundant Attributes
 Suppose we have entity sets:
 instructor, with attributes: ID, name, dept_name, salary
 department, with attributes: dept_name, building, budget
 We model the fact that each instructor has an associated department using a
relationship set inst_dept
 The attribute dept_name appears in both entity sets. Since it is the primary key
for the entity set department, it replicates information present in the relationship
and is therefore redundant in the entity set instructor and needs to be removed.
 BUT: when converting back to tables, in some cases the attribute gets
reintroduced, as we will see later.

Weak Entity Sets
Weak Entity Sets
 Consider a section entity, which is uniquely identified by a course_id, semester, year,
and sec_id.
 Clearly, section entities are related to course entities. Suppose we create a
relationship set sec_course between entity sets section and course.
 Note that the information in sec_course is redundant, since section already has an
attribute course_id, which identifies the course with which the section is related.
 One option to deal with this redundancy is to get rid of the relationship sec_course;
however, by doing so the relationship between section and course becomes implicit
in an attribute, which is not desirable

Weak Entity Sets (Cont.)
 An alternative way to deal with this redundancy is to not store the attribute course_id in the
section entity and to only store the remaining attributes section_id, year, and semester.
However, the entity set section then does not have enough attributes to identify a
particular section entity uniquely; although each section entity is distinct, sections for
different courses may share the same section_id, year, and semester.
 To deal with this problem, we treat the relationship sec_course as a special relationship
that provides extra information, in this case, the course_id, required to identify section
entities uniquely.
 The notion of weak entity set formalizes the above intuition. A weak entity set is one
whose existence is dependent on another entity, called its identifying entity; instead of
associating a primary key with a weak entity, we use the identifying entity, along with extra
attributes called discriminator to uniquely identify a weak entity. An entity set that is not a
weak entity set is termed a strong entity set.

 Every weak entity must be associated with an identifying entity; that is, the weak entity set
is said to be existence dependent on the identifying entity set. The identifying entity set is
said to own the weak entity set that it identifies. The relationship associating the weak
entity set with the identifying entity set is called the identifying relationship.
 Note that the relational schema we eventually create from the entity set section does have
the attribute course_id, for reasons that will become clear later, even though we have
dropped the attribute course_id from the entity set section.

E-R Diagrams
E-R Diagrams

Entity Sets
Entity Sets
Entities can be represented graphically as follows:
•Rectangles represent entity sets.
•Attributes listed inside entity rectangle
•Underline indicates primary key attributes

Relationship Sets
Relationship Sets
 Diamonds represent relationship sets.

UNIT 1 ER Model 2025 -Entity Relationship (ER) Diagram

More Related Content

Similar to UNIT 1 ER Model 2025 -Entity Relationship (ER) Diagram (20)

More from RajendraKankrale1 (7)

Recently uploaded (20)

UNIT 1 ER Model 2025 -Entity Relationship (ER) Diagram