ER

Diagra
Presented by Rajni Jindal
m
Introduction

● Introduced in 1976 by Dr Peter Chen, a non-technical design method

works on conceptual level based on the perception of the real world.
● It consists of collections of basic objects, called entities and of
relationships among these entities and attributes which defines their
properties.
● E-R data model was developed to facilitate database design by
allowing specification of an enterprise schema that represents the
overall logical structure of a database.
● E-R model is very useful in mapping the meanings and interactions
of real-world enterprises onto a conceptual schema
● It is free from ambiguities and provides a standard and logical way
of visualizing the data.
● As basically it is a diagrammatical representation easy to understand even
by a non-technical user.
Entity
•ENTITY- An entity is a thing or an object in the real world
that is distinguishable from other object based on the values of
the attributes it possesses.
•An entity may be concrete, such as a person or a book, or it
may be abstract, such as a course, or a flight reservation.
• In ER diagram we cannot represent an entity, as entity is an
instant not schema, and ER diagram is designed to understand
schema
• In a relational model entity is represented by a row or a tuple
or a record in a table.
Types of Entity

➢ Tangible - Entities which physically exist in real world.

E.g. - Car, Pen, locker
➢ Intangible - Entities which exist logically. E.g. –
Account, video.
Entity
Set

Collection of same type of entities that share the same

properties or attributes.
• In an ER diagram an entity set is represented by a rectangle
• In a relational model it is represented by a separate table
Strong Entity:
● A strong entity is not dependent on any other entity in
the schema.
● A strong entity will always have a primary key.
● Strong entities are represented by a single rectangle.
Weak Entity:
A weak entity is dependent on a strong entity to ensure
its existence.
Unlike a strong entity, a weak entity does not have any
primary key. It instead has a partial discriminator key.
A weak entity is represented by a double rectangle.
ATTRIBUTES

• Attributes are the descriptive properties possessed by each member of

an entity set. For each attribute there is a set of permitted values
called domain.

• In an ER diagram attributes are represented by ellipse or oval

connected to rectangle.

• While in a relational model they are represented by independent

column. e.g. Instructor (ID, name, salary, dept_name)
Types of Attributes

• Single valued- Attributes having single value at any

instance of time for an entity. E.g. – Aadhar no,
dob.
• Multivalued - Attributes which can have more than one
value for an entity at same time. E.g. - Phone no,
email, address.

A multivalued attribute is represented by a double ellipse

in an ER diagram and by an independent table in a relational
model.
• Simple - Attributes which cannot be divided further into sub
parts. E.g. Age, Roll_No
• Composite - Attributes which can be further divided into sub
parts, as simple attributes.
A composite attribute is represented by an ellipse connected to
an ellipse and in a relational model by a separate column.
• Derived -The value of these types of attributes can be
derived from values of other Attributes. E.g. - Age
attribute can be derived from date_of_birth. the
derived attribute is represented by a dashed oval.

• Key Attribute - The attribute which uniquely identifies

each entity in the entity set is called the key
attribute. In ER diagram, the key attribute is
represented by an oval with underlying lines.
 Relationship Type and Relationship Set

A Relationship Type represents the association between entity types. For example,
‘Enrolled in’ is a relationship type that exists between entity type Student and Course. In ER
diagram, the relationship type is represented by a diamond and connecting the entities with
lines.
Degree of a relationship/relationship set:
• Means number of entities set(relations/tables)
associated(participate) in the relationship set. Most of the
relationship sets in a data base system are binary. Occasionally
however relationship sets involve more than two entity sets.
•Logically, we can associate any number of entities set in a
•relationship called N-ary Relationship.
•Unary
Relationship
One single entity set participate in a Relationship, means
two entities of the same entity set are related to each
other. These are also called as self - referential
Relationship set.
•Binary
Relationship
When there are TWO entities set participating in a relationship, the relationship is called a
binary relationship. For example, a Student is enrolled in a Course.
•Ternary
Relationship -
When three entities participate in a Relationship
N-ary (n degree):

• In the N-ary relationship, there are n types of entity that

associates. So, we can say that an N-ary relationship
exists when there are n types of entities.
Cardinality in DBMS

In database management, cardinality plays an important role. Here cardinality

represents the number of times an entity of an entity set participates in a
relationship set. Or we can say that the cardinality of a relationship is the number
of tuples (rows) in a relationship. Types of cardinality in between tables are:
● one-to-one
● one-to-many
● many-to-one
● many-to-many
 1. One-to-One

When each entity in each entity set can take part only once in the relationship, the cardinality
is one-to-one. Let us assume that a male can marry one female and a female can marry one
male. So the relationship will be one-to-one.
the total number of tables that can be used in this is 2.
Using Sets, it can be represented
as:
2. One-to-Many
•In one-to-many mapping as well where each entity can be related to more than one
relationship and the total number of tables that can be used in this is 2. Let us assume that
one surgeon deparment can accomodate many doctors. So the Cardinality will be 1 to M. It
means one deparment has many Doctors.
3. Many-to-One:

• When entities in one entity set can take part only once in
the relationship set and entities in other entity sets can
take part more than once in the relationship set,
cardinality is many to one.
Using Sets, it can be represented
as
 4. Many-to-Many:

When entities in all entity sets can take part more than once in the relationship cardinality is
many to many. Let us assume that a student can take more than one course and one course
can be taken by many students. So the relationship will be many to many.
the total number of tables that can be used in this is 3.
Using Sets, it can be represented
as:
Participation Constraint

Participation Constraint is applied to the entity participating in the relationship set.

1. Total Participation – Each entity in the entity set must participate in the relationship. If
each student must enroll in a course, the participation of students will be total. Total
participation is shown by a double line in the ER diagram.

2. Partial Participation – The entity in the entity set may or may NOT participate in the
relationship. If some courses are not enrolled by any of the students, the participation in the
course will be partial.
The diagram depicts the ‘Enrolled in’ relationship set with Student Entity set
having total participation and Course Entity set having partial participation.
Reduction of an E-R Schema to Tables
The database can be represented using the notations, and these notations can be reduced to a
collection of tables.

In the database, every entity set or relationship set can be represented in tabular form.
• We can represent a database that conforms to an E-R database schema by a collection of
tables.

• For each entity set and for each relationship set in the database, there is a unique table to
which we assign the name of the corresponding entity set or relationship set.

• Each table has multiple columns, each of which has a unique name.
Conversion ER to Table:

○ Entity type becomes a table.

In the given ER diagram, LECTURE, STUDENT, SUBJECT and COURSE forms

individual tables.

○ All single-valued attribute becomes a column for the table.

In the STUDENT entity, STUDENT_NAME and STUDENT_ID form the column of

STUDENT table. Similarly, COURSE_NAME and COURSE_ID form the column
of COURSE table and so on.
○ A key attribute of the entity type represented by the
primary key.

In the given ER diagram, COURSE_ID, STUDENT_ID, SUBJECT_ID,

and LECTURE_ID are the key attribute of the entity.
○ The multivalued attribute is represented by a separate
table.

In the student table, a hobby is a multivalued attribute. So it is

not possible to represent multiple values in a single column of
STUDENT table. Hence we create a table STUD_HOBBY with
column name STUDENT_ID and HOBBY. Using both the column, we
create a composite key.
○ Composite attribute represented by components.

In the given ER diagram, student address is a composite attribute. It

contains CITY, PIN, DOOR#, STREET, and STATE. In the STUDENT table,
these attributes can merge as an individual column.
○ Derived attributes are not considered in the table.

In the STUDENT table, Age is the derived attribute. It can be calculated at

any point of time by calculating the difference between current date and
Date of Birth.
Using these rules, you can convert the ER diagram to tables and columns
and assign the mapping between the tables. Table structure for the given ER
diagram is as below:
Extended ER Model:
As the complexity of data increased in the late 1980s, it became more and
more difficult to use the traditional ER Model for database modelling. Hence
some improvements or enhancements were made to the existing ER Model
to make it able to handle the complex applications better.

The basic E-R concepts can model most database features, some aspects of a
database may be more aptly expressed by certain extensions to the basic E-R model.

The extended E-R Concept

● Specialization
● Generalization
● Aggregation
Features of the EER Model
● EER generates designs that are more accurate to database schemas.
● The diagrammatic style is useful in displaying the EER schema.
● The modeling concepts that are included in the ER model are also included in the
EER model.
● The data properties and constraints reflected by the EER model are very precise.
● It incorporates the ideas of specialization and generalization.
● It is used to represent a collection of objects that are a union of distinct types of
objects.
Generalization

● Generalization is the process of extracting common properties

from a set of entities and create a generalized entity from it.
● Generalization is a "bottle-up approach" in which two or more
entities can be combined to form a higher level entity if they
have some attributes in common.
● Subclasses are combined to make a superclass.
● Generalization is used to emphasize the similarities among
lower-level entity set and to hide differences in the schema.
Example:
Consider we have 3 sub entities Car, Bus and Motorcycle. Now these
three entities can be generalized into one higher-level entity (or super
class) named as Vehicle.
Specialization

● Specialization is opposite of Generalization.

● In Specialization, an entity is broken down into sub-entities based
on their characteristics.
● Specialization is a "Top-down approach" where higher level entity is
specialized into two or more lower level entities.
● Specialization is used to identify the subset of an entity set that
shares some distinguishing characteristics
● Specialization can be repeatedly applied to refine the design of
schema.
● Normally, the superclass is defined first, the subclass and its related
attributes are defined next, and relationship set are then added.
● Depicted by triangle component labeled ISA
Aggregation

● Aggregation is used when we need to express a relationship

among relationships.
● Aggregation is an abstraction through which relationships are
treated as higher level entities.
● Aggregation is a process when a relationship between two
entities is considered as a single entity and again this single
entity has a relationship with another entity.
Example:
● Consider a ternary relationship works_on between Employee,
Branch and Job.
● An Employee works on a particular job at a particular branch.

Suppose we want to assign a manager for jobs performed by an employee at

a branch (i.e. want to assign managers to each employee, job, branch
combination)
● Need a separate manager entity-set.
● Relationship between each manager, employee, branch and job entity.
With Aggregation the ER diagram can be represented as

● An employee works on a particular job at a particular branch.

● An employee, branch, job combination may have an associated
manager.
Questions?

THANK YOU!