UNIT2-DBMS

DBMS - ER Model Basic Concepts

The ER model defines the conceptual view of a database. It works around real-world entities
and the associations among them. At view level, the ER model is considered a good option
for designing databases.

Entity
An entity can be a real-world object, either animate or inanimate, that can be easily
identifiable. For example, in a school database, students, teachers, classes, and courses
offered can be considered as entities. All these entities have some attributes or properties that
give them their identity.

An entity set is a collection of similar types of entities. An entity set may contain entities with
attribute sharing similar values. For example, a Students set may contain all the students of a
school; likewise a Teachers set may contain all the teachers of a school from all faculties.
Entity sets need not be disjoint.

Attributes
Entities are represented by means of their properties, called attributes. All attributes have
values. For example, a student entity may have name, class, and age as attributes.

There exists a domain or range of values that can be assigned to attributes. For example, a
student's name cannot be a numeric value. It has to be alphabetic. A student's age cannot be
negative, etc.

Types of Attributes
 Simple attribute − Simple attributes are atomic values, which cannot be divided further. For
example, a student's phone number is an atomic value of 10 digits.
 Composite attribute − Composite attributes are made of more than one simple attribute. For
example, a student's complete name may have first_name and last_name.
 Derived attribute − Derived attributes are the attributes that do not exist in the physical
database, but their values are derived from other attributes present in the database. For
example, average_salary in a department should not be saved directly in the database, instead
it can be derived. For another example, age can be derived from data_of_birth.
 Single-value attribute − Single-value attributes contain single value. For example −
Social_Security_Number.
 Multi-value attribute − Multi-value attributes may contain more than one values. For
example, a person can have more than one phone number, email_address, etc.

These attribute types can come together in a way like −

 simple single-valued attributes

 simple multi-valued attributes
 composite single-valued attributes
 composite multi-valued attributes

Entity-Set and Keys

Key is an attribute or collection of attributes that uniquely identifies an entity among entity
set.

For example, the roll_number of a student makes him/her identifiable among students.

 Super Key − A set of attributes (one or more) that collectively identifies an entity in an entity
set.
 Candidate Key − A minimal super key is called a candidate key. An entity set may have
more than one candidate key.
 Primary Key − A primary key is one of the candidate keys chosen by the database designer
to uniquely identify the entity set.

Explore our latest online courses and learn new skills at your own pace. Enroll and become
a certified expert to boost your career.

Relationship
The association among entities is called a relationship. For example, an employee works_at a
department, a student enrolls in a course. Here, Works_at and Enrolls are called
relationships.

Relationship Set
A set of relationships of similar type is called a relationship set. Like entities, a relationship
too can have attributes. These attributes are called descriptive attributes.

Degree of Relationship
The number of participating entities in a relationship defines the degree of the relationship.

 Binary = degree 2
 Ternary = degree 3
 n-ary = degree

Mapping Cardinalities
Cardinality defines the number of entities in one entity set, which can be associated with the
number of entities of other set via relationship set.
 One-to-one − One entity from entity set A can be associated with at most one entity of entity
set B and vice versa.

 One-to-many − One entity from entity set A can be associated with more than one entities of
entity set B however an entity from entity set B, can be associated with at most one entity.

 Many-to-one − More than one entities from entity set A can be associated with at most one
entity of entity set B, however an entity from entity set B can be associated with more than
one entity from entity set A.

 Many-to-many − One entity from A can be associated with more than one entity from B and
vice versa.
 Print Page
Mapping from ER Model to Relational Model
Last Updated : 24 Sep, 2024





Converting an Entity-Relationship (ER) diagram to a Relational Model is a crucial

step in database design. The ER model represents the conceptual structure of a
database, while the Relational Model is a physical representation that can be
directly implemented using a Relational Database Management System (RDBMS)
like Oracle or MySQL. In this article, we will explore how to convert an ER
diagram to a Relational Model for different scenarios, including binary
relationships with various cardinalities and participation constraints.
Case 1: Binary Relationship with 1:1 cardinality with total participation of an
entity

Aiming for a top All India Rank in GATE CS/IT or GATE DA 2026? Our courses,
led by experts like Khaleel Sir, Chandan Jha Sir, and Vijay Agarwal Sir,
offer live classes, practice problems, doubt support, quizzes, and All India Mock
Tests—all in one place.
A person has 0 or 1 passport number and Passport is always owned by 1 person. So
it is 1:1 cardinality with full participation constraint from Passport.
First Convert each entity and relationship to tables. Person table corresponds
to Person Entity with key as Per-Id. Similarly Passport table corresponds to
Passport Entity with key as Pass-No. Has Table represents relationship between
Person and Passport (Which person has which passport). So it will take attribute
Per-Id from Person and Pass-No from Passport.
Person Has Passport

Per- Other Person Per- Pass- Pass- Other

Id Attribute Id No No PassportAttribute

PR1 – PR1 PS1 PS1 –

PR2 – PR2 PS2 PS2 –

PR3 –

Table
1
As we can see from Table 1, each Per-Id and Pass-No has only one entry in Has
Table. So we can merge all three tables into 1 with attributes shown in Table 2.
Each Per-Id will be unique and not null. So it will be the key. Pass-No can’t be key
because for some person, it can be NULL.
Other Person Other
Per-Id Pass-No
Attribute PassportAttribute

Table 2
Case 2: Binary Relationship with 1:1 cardinality and partial participation of
both entities
 A male marries
0 or 1 female and vice versa as well. So it is 1:1 cardinality with partial
participation constraint from both. First Convert each entity and relationship to
tables. Male table corresponds to Male Entity with key as M-Id. Similarly Female
table corresponds to Female Entity with key as F-Id. Marry Table represents
relationship between Male and Female (Which Male marries which female). So it
will take attribute M-Id from Male and F-Id from Female.
Male Marry Female

M-
Other Male Attribute M-Id F-Id F-Id Other FemaleAttribute
Id

M1 – M1 F2 F1 –

M2 – M2 F1 F2 –

M3 – F3 –

Table 3
As we can see from Table 3, some males and some females do not marry. If we
merge 3 tables into 1, for some M-Id, F-Id will be NULL. So there is no attribute
which is always not NULL. So we can’t merge all three tables into 1. We can
convert into 2 tables. In table 4, M-Id who are married will have F-Id associated.
For others, it will be NULL. Table 5 will have information of all females. Primary
Keys have been underlined.
Other Male
M-Id F-Id
Attribute

Table 4
F-Id Other FemaleAttribute

Table 5
Note: Binary relationship with 1:1 cardinality will have 2 table if partial
participation of both entities in the relationship. If atleast 1 entity has total
participation, number of tables required will be 1.
Case 3: Binary Relationship with n: 1 cardinality

In this scenario, every student can enroll only in one elective course but for an
elective course there can be more than one student. First Convert each entity and
relationship to tables. Student table corresponds to Student Entity with key as S-
Id. Similarly Elective_Course table corresponds to Elective_Course Entity with
key as E-Id. Enrolls Table represents relationship between Student and
Elective_Course (Which student enrolls in which course). So it will take attribute
S-Id from Student and E-Id from Elective_Course.
Student Enrolls Elective_Course

S- Other Student S- E- E- Other Elective

Id Attribute Id Id Id CourseAttribute

S1 – S1 E1 E1 –

S2 – S2 E2 E2 –

S3 – S3 E1 E3 –

S4 – S4 E1

Table 6
As we can see from Table 6, S-Id is not repeating in Enrolls Table. So it can be
considered as a key of Enrolls table. Both Student and Enrolls Table’s key is same.
We can merge it as a single table. The resultant tables are shown in Table 7 and
Table 8. Primary Keys have been underlined.
 Other Student
S-Id E-Id
Attribute

Table 7
E-Id Other Elective CourseAttribute

Table 8
Case 4: Binary Relationship with m: n cardinality

In this scenario, every student can enroll in more than 1 compulsory course and for
a compulsory course there can be more than 1 student. First Convert each entity
and relationship to tables. Student table corresponds to Student Entity with key as
S-Id. Similarly Compulsory_Courses table corresponds to Compulsory Courses
Entity with key as C-Id. Enrolls Table represents relationship between Student and
Compulsory_Courses (Which student enrolls in which course). So it will take
attribute S-Id from Person and C-Id from Compulsory_Courses.
Student Enrolls Compulsory_Courses

S- Other Student S- C- C- Other Compulsory

Id Attribute Id Id Id CourseAttribute

S1 – S1 C1 C1 –

S2 – S1 C2 C2 –

S3 – S3 C1 C3 –

S4 – S4 C3 C4 –
 Student Enrolls Compulsory_Courses

S4 C2

S3 C3

Table 9
As we can see from Table 9, S-Id and C-Id both are repeating in Enrolls Table. But
its combination is unique; so it can be considered as a key of Enrolls table. All
tables’ keys are different, these can’t be merged. Primary Keys of all tables have
been underlined.
Case 5: Binary Relationship with weak entity

In this scenario, an employee can have many dependents and one dependent can
depend on one employee. A dependent does not have any existence without an
employee (e.g; you as a child can be dependent of your father in his company). So
it will be a weak entity and its participation will always be total. Weak Entity does
not have key of its own. So its key will be combination of key of its identifying
entity (E-Id of Employee in this case) and its partial key (D-Name).
First Convert each entity and relationship to tables. Employee table corresponds to
Employee Entity with key as E-Id. Similarly Dependents table corresponds to
Dependent Entity with key as D-Name and E-Id. Has Table represents relationship
between Employee and Dependents (Which employee has which dependents). So it
will take attribute E-Id from Employee and D-Name from Dependents.
Employee Has Dependents

E- Other E- D-Name D-Name E- Other

Id Employee Id Id DependentsAttribute
 Employee Has Dependents

Attribute

E1 – E1 RAM RAM E1 –

E2 – E1 SRINI SRINI E1 –

E3 – E2 RAM RAM E2 –

E3 ASHISH ASHISH E3 –

Table 10
As we can see from Table 10, E-Id, D-Name is key for Has as well as Dependents
Table. So we can merge these two into 1. So the resultant tables are shown in
Tables 11 and 12. Primary Keys of all tables have been underlined.
E-Id Other Employee Attribute

Table 11
D-Name E-Id Other DependentsAttribute

Difference between Strong and Weak Entity

An entity is a “thing” or “object” in the real world. An entity contains attributes,
which describe that entity. So anything about which we store information is called
an entity. Entities are recorded in the database and must be distinguishable, i.e.,
easily recognized from the group. In this article, we will see the difference between
strong and weak entities.
What is a 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. The relationship of two strong entities is represented by a single
diamond. Various strong entities, when combined together, create a strong entity
set.
What is a 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. The relation
between one strong and one weak entity is represented by a double diamond. This
relationship is also known as an identifying relationship.
In ER models, strong entities can exist independently, whereas weak entities
depend on strong entities. If you want to solidify your understanding of ER
diagrams and entity relationships, the GATE CS Self-Paced Course covers
database concepts in-depth, including practical exercises on ER modeling
Difference Between Strong and Weak Entity
Strong Entity Weak Entity

Strong entity always has a primary While a weak entity has a partial discriminator
key. key.

Strong entity is not dependent on

Weak entity depends on strong entity.
any other entity.

Strong entity is represented by a Weak entity is represented by a double

single rectangle. rectangle.

Two strong entity’s relationship is While the relation between one strong and one
represented by a single diamond. weak entity is represented by a double diamond.

Strong entities have either total

A weak entity has a total participation constraint.
participation or partial participation.

Problems with ER Model.

The ER model is incomplete as any other data model. It is necessary to understand the reason for
its incompleteness because only then can we develop approaches to overcome the model's
limitations. Sometimes, a problem known as a connection trap occurs due to the misinterpretation
of the meaning of certain relationships.
There are two main types of connection models are:

1. Fan Traps
2. Chasm Traps

Both Fan and Chasm traps occur when it becomes impossible to retrieve all the necessary
information needed from the entire diagram.

1) Fan Traps
An ER model that represents a relationship between entity occurrences is ambiguous. Such a
model is said to be in a fan trap. A fan trap may exist where two or more one-to-many
relationships fan out from the same entity. The structure is of the form many to one/ one to many.
To understand the fan trap problem, let us consider an example of a company where each
department can have offices in different cities.

Each employee is associated with a single department because each employee works in only one
department. However, the departments are associated with multiple locations because
departments can have offices in difficult cities. To understand the problem more clearly, let us
examine some occurrences of relationships using a value for the primary key attributes of
EMPLOYEE, DEPARTMENT, AND LOCATION entities.
A problem arises if we want to determine which employee works at which location. For example.
If we want to know in which city does Vikram works.

We can only determine that the employee Vikram works in either Amritsar or Mumbai from the
current structure. The inability to answer the question specifically is because of mutual exclusion
of Employee and Location entity occurrences with department entity.

We can resolve this fan trap by reconstructing the ER model so that they now represent the
correct association between these entities.

With this reconstruction, we can now answer where employee Vikaram works? From the above,
it is clear that employee Vikram works at the Amritsar location and in the accounting department.

Advertisement

2) Chasm Traps
A chasm trap is another problem with the ER model, which occurs when a pathway does not exist
in all the related entities. A chasm trap may exist where there are one or more relationships with a
minimum multiplicity of zero forming part of the pathway between related entities.

To understand the chasm trap, consider the following entities and their corresponding
relationship.

A problem arises when we want to know which lockers are available in a branch. Here, we
consider an example of a bank where a single branch has one or more customers who avail zero
or more lockers to keep their belongings. We also assume that a customer uses not all customers
avail locker and not all lockers. Now let us examine some occurrences of the relationships using a
value for the primary key attributes of Bank_branch, Customer, and Locker entities to understand
the problem more clearly.
Suppose we want to know which bank's branch locker L212 is available. We will be unable to
find the answer as locker L212 has not yet been allocated. The inability to answer these questions
is a result of a chasm trap. It would be considered a loss of information.

To solve this problem, we need to identify the missing relationship that relates the bank_branch
entity with the locker entity it offers. This ensures that all the times the lockers associated with
each bank_branch are known, including those lockers that have yet not been allocated. The ER
diagram on adding this relationship would look like

Now let us examine the occurrences of the relationships using the values for the primary key
attribute of the given entities.
Generalization, Specialization and Aggregation in
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. These were
used for data abstraction. In which an abstraction mechanism is used to hide details
of a set of objects. In this article we will cover the concept of Generalization,
Specialization, and Aggregation with example.
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. For Example, STUDENT and FACULTY can be
generalized to a higher-level entity called PERSON as shown in Figure 1. 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).
Generalization is also called as ‘ Bottom-up approach”.
Aiming for a top All India Rank in GATE CS/IT or GATE DA 2026? Our courses,
led by experts like Khaleel Sir, Chandan Jha Sir, and Vijay Agarwal Sir,
offer live classes, practice problems, doubt support, quizzes, and All India
MockTests—all in one place.

Generalization

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. For Example, an EMPLOYEE entity in an Employee
management system can be specialized into DEVELOPER, TESTER, etc. as
shown in Figure 2. 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 is also called as ” Top-Down approch”.

Specialization

Inheritance: It is an important feature of generalization and specialization

 Attribute inheritance : It allows lower level entities to inherit the attributes of
higher level entities and vice versa. In diagram Car entity is an inheritance
of Vehicle entity ,So Car can acquire attributes of Vehicle. Example:car can
acquire Model attribute of Vehicle.
 Participation inheritance: Participation inheritance in ER modeling refers to
the inheritance of participation constraints from a higher-level entity
(superclass) to a lower-level entity (subclass). It ensures that subclasses adhere
to the same participation rules in relationships, although attributes and
relationships themselves are inherited differently. In diagram Vehicle entity has
an relationship with Cycle entity, but it would not automatically acquire the
relationship itself with the Vehicle entity. Participation inheritance only refers
to the inheritance of participation constraints, not the actual relationships
between entities.
Example of Relation

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

Aggregation

Representing Aggregation Via Schema

To represent aggregation, create a schema containing the following:
 Theprimary key to the aggregated relationship
 The primary key to the associated entity set
 Descriptive attribute, if exists
Reduction of ER diagram to Table
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.

The ER diagram is given below:

There are some points for converting the ER diagram to the table:

o Entity type becomes a table.

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

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

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

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

o 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:

Figure: Table structure

Entity in DBMS
Database Management System (DBMS) is an essential tool to manage data, but do you know how
important entities are in DBMS?
The role of the entity is the representation and management of data. In this article, we are going
to discuss entities in DBMS.

Entity:
An entity is referred to as an object or thing that exists in the real world. For example, customer,
car, pen, etc.

Entities are stored in the database, and they should be distinguishable, i.e., they should be easily
identifiable from the group. For example, a group of pens that are from the same company cannot
be identified, so they are only objects, but pens with different colours become unique and will be
called an entity like a red pen, green pen, blue pen, black pen, etc.

In a group of pens, we can easily identify any pen because of its different colours, so a pen of
different colours is an entity.

For extracting data from the database, each data must be unique in its own way so that it becomes
easier to differentiate between them. Distinct and unique data is known as an entity.

An entity has some attributes which depict the entity's characteristics. For example, an entity
"Student" has attributes such as "Student_roll_no", "Student_name", "Student_subject", and
"Student_marks".

Example of Entity in DBMS in tabular form:

Student_rollno Student_name Student_subject Student_marks

1 Robert English 85

2 Parker Mathematics 75

3 Harry Science 80

4 George Geography 70
Some entities are related to other entities in the table. For example, the "Student" entity is related
to the "University" entity. The ERD (Entity Relationship Diagram) model comes to light to
visually show the relationship between several entities.

Kinds of Entity:
There are two kinds of entities, which are as follows:

1. Tangible Entity:

It is an entity in DBMS, which is a physical object that we can touch or see. In simple words, an
entity that has a physical existence in the real world is called a tangible entity.

For example, in a database, a table represents a tangible entity because it contains a physical
object that we can see and touch in the real world. It includes colleges, bank lockers, mobiles,
cars, watches, pens, paintings, etc.

2. Intangible Entity:

It is an entity in DBMS, which is a non-physical object that we cannot see or touch. In simple
words, an entity that does not have any physical existence in the real world is known as an
intangible entity.

For example, a bank account logically exists, but we cannot see or touch it.

Entity Type:
A collection of entities with general characteristics is known as an entity type.

For example, a database of a corporate company has entity types such as employees, departments,
etc. In DBMS, every entity type contains a set of attributes that explain the entity.

The Employee entity type can have attributes such as name, age, address, phone number, and
salary.

The Department entity type can have attributes such as name, number, and location in the
department.

Kinds of Entity Type

There are two kinds of entity type, which are as follows:

1. Strong Entity Type: It is an entity that has its own existence and is independent.

The entity relationship diagram represents a strong entity type with the help of a single rectangle.
Below is the ERD of the strong entity type:
In the above example, the "Customer" is the entity type with attributes such as ID, Name, Gender,
and Phone Number. Customer is a strong entity type as it has a unique ID for each customer.

2. Weak Entity Type: It is an entity that does not have its own existence and relies on a strong
entity for its existence.

The Entity Relationship Diagram represents the weak entity type using double rectangles. Below
is the ERD of the weak entity type:

In the above example, "Address" is a weak entity type with attributes such as House No., City,
Location, and State.

The relationship between a strong and a weak entity type is known as an identifying relationship.

Using a double diamond, the Entity-Relationship Diagram represents a relationship between the
strong and the weak entity type.

Advertisement

Let us see an example of the relationship between the Strong entity type and weak entity type
with the help of ER Diagram:
Entity Set
An entity set is a group of entities of the same entity type.

For example, an entity set of students, an entity set of motorbikes, an entity of smartphones, an
entity of customers, etc.

Entity sets can be classified into two types:

1. Strong Entity Set:

In a DBMS, a strong entity set consists of a primary key.

For example, an entity of motorbikes with the attributes, motorbike's registration number,
motorbike's name, motorbike's model, and motorbike's colour.

Below is the representation of a strong entity set in tabular form:

Example of Entity Relationship Diagram representation of the above strong entity set:
2. Weak Entity Set:

In a DBMS, a weak entity set does not contain a primary key.

For example, An entity of smartphones with its attributes, phone's name, phone's colour, and
phone's RAM.

Below is the representation of a weak entity set in tabular form:

Example of Entity Relationship Diagram representation of the above weak entity set: