A

PROJECT REPORT
ON
“E-R DIAGRAM AND ITS NORMALIZATION”

SUBMITTED UNDER “DBMS ” TO THE

M.S.B.T.E. MUMBAI
IN PARTIAL FULFILLMENT OF THE REQUIREMENTS
FOR THE AWARD OF
DIPLOMA IN COMPUTER ENGINEERING
BY

MR. SHAIKH SHAHID MIRAJ MR. PUND SAURABH WALMIK

MR. SHINDE KETAN DILIP MR.SHELKE OMKAR KAILAS

Under the guidance of

Prof. M.V.Khasne

DEPARTMENT OF COMPUTER ENGINEERING SANJIVANI

RURAL EDUCATION SOCIETY’S SANJIVANI K.B.P.
POLYTECHNIC, KOPARGAON-423 603 2020 – 2021.

Subject Teacher Head of the Department Principal

M.V.Khasne G.N. JORVEKAR A.R. MIRIKAR

 Introduction

In these project we will learn about various types of e-r diagrams

and its normalization .
The e-r diagrams are of the following points

1 : Suppose a company wants to store the names and contact details of its
employees. It creates a table that looks like this:
2 Suppose a school wants to store the data of teachers and the subjects
they teach. They create a table that looks like this: Since a teacher can
teach more than one subjects, the table can have multiple rows for a
same teacher.

3 Suppose a company wants to store the complete address of each

employee, they create a table named employee_details that looks like
this:
 INDEX

Sr. No Title Page no

1) Introduction 4
2) Normalization 5
3) Types of Anmalies 6
4) Normalization of Table 7
5) E-R Diagram 10
6) Limitations and future Enhancement 11
7) Conclusion 12
8) References 13
Normalization:
After the conceptual model the logical representation of entities are created and
then before converting them into the tables with physical existence
normalization is carried out. Normalization is process by which the data
redundancy is nullified. The tables holding such data are split into several
atomic tables so that they become isolated and the data manipulations are carried
out in a propagative way i.e. A change in an entry point data in a relation makes
it triggered and reflected throughout the relations which frees tables from
modification anomalies, i.e. Insertion, updation and deletion anomalies.
Several levels of normalization exist in database design and are called
Normal Forms. They are First Normal Form (1NF), Second Normal Form (2NF)
and Third Normal form (3NF).
First Normal Form (1NF)
First Normal form is concerned with multiple valued attributes. For
the table to be in a first normal form it cannot contain multiple values for any
attributes.
Second Normal Form (2NF)
For the table to be in second normal form it is in 1NF and the non
key attributes of the table shouldn’t be partial dependent on any single element
of composite primary key.

Third Normal Form (3NF)

For the table to be in third normal form it is in 2NF and the non key
attributes shouldn’t have the transitive dependency on the primary key.
Types of Anomalies:
• Insertion anomaly:
Let us assume that a new department has been started by the organization but
initially there is no employee appointed for that department, then the tuple for
this department cannot be inserted into this table as the E# will have NULL,
which is not allowed as E# is primary key
This kind of a problem in the relation where some tuple cannot be inserted is
known as insertion anomaly
• Deletion anomaly:
Now consider there is only one employee in some department and that
employee leaves the organization, then the tuple of that employee has to be
deleted from the table, but in addition to that the information about the
department also will get deleted.
This kind of a problem in the relation where deletion of some tuples can lead to
loss of some other data not intended to be removed is known as deletion
anomaly
• Update anomaly:
Suppose the manager of a department has changed, this requires that the Dmgr#
in all the tuples corresponding to that department must be changed to reflect the
new status. If we fail to update all the tuples of the given department, then two
different records of employee working in the same department might show
different Dmgr# leading to inconsistency in the database
This is known as modification/update anomaly. The data redundancy cannot be
totally removed from the database, but there should be controlled redundancy.

First normal form (1NF)

As per the rule of first normal form, an attribute (column) of a table cannot hold
multiple values. It should hold only atomic values.
 • Example 1:
Suppose a company wants to store the names and contact details of its
employees. It creates a table that looks like this:

❖ E-R Diagram –

Emp_id Emp_name Emp_address Emp_mobile

101 Ketan New Delhi 8912312390

8812121212
102 Shahid Kanpur
9900012222
103 Saurabh Chennai 7778881212

9990000123
104 Omkar Bangalore
8123450987
 Two employees (Shahid & Omkar) are having two mobile numbers so the
company stored them in the same field as you can see in the table above.

This table is not in 1NF as the rule says “each attribute of a table must have
atomic (single) values”, the emp_mobile values for employees Shahid & Omkar
violates that rule.

To make the table complies with 1NF we should have the data like this:

Emp_id Emp_name Emp_address Emp_mobile

101 Ketan New Delhi 8912312390

102 Shahid Kanpur 8812121212

102 Shahid Kanpur 9900012222

103 Saurabh Chennai 7778881212

104 Omkar Bangalore 9990000123

104 Omkar Bangalore 8123450987

Second normal form (2NF)

A table is said to be in 2NF if both the following conditions hold:

• Table is in 1NF (First normal form)

• No non-prime attribute is dependent on the proper subset of any candidate
key of table.
An attribute that is not part of any candidate key is known as non- prime
attribute.
 • Example 2:
Suppose a school wants to store the data of teachers and the subjects they
teach. They create a table that looks like this: Since a teacher can teach more
than one subjects, the table can have multiple rows for a same teacher.

❖ E-R Diagram –

Teacher_id Subject Teacher_age

111 Maths 38
111 Physics 38

222 Biology 38
333 Physics 40

333 Chemistry 40
Candidate Keys: {teacher_id, subject}
Non prime attribute: teacher_age

The table is in 1 NF because each attribute has atomic values. However, it is not
in 2NF because non prime attribute teacher_age is dependent on teacher_id
alone which is a proper subset of candidate key. This violates the rule for 2NF
as the rule says “no non-prime attribute is dependent on the proper subset of any
candidate key of the table”.
To make the table complies with 2NF we can break it in two tables like this:
Teacher_details table:

Teacher_id Teacher_age

111 38

222 38

333 40

Teacher_subject table:

Teacher_id Subject
111 Maths
111 Physics
222 Biology
333 Physics
333 Chemistry

Now the tables comply with Second normal form (2NF).

Third Normal form (3NF)

A table design is said to be in 3NF if both the following conditions

hold:
 • Table must be in 2NF
• Transitive functional dependency of non-prime attribute on any super key
should be removed.

An attribute that is not part of any candidate key is known as non- prime
attribute.

In other words 3NF can be explained like this: A table is in 3NF if it is in 2NF
and for each functional dependency X-> Y at least one of the following
conditions hold:

• X is a super key of table

• Y is a prime attribute of table

An attribute that is a part of one of the candidate keys is known as prime

attribute.
 • Example 3:
Suppose a company wants to store the complete address of each employee,
they create a table named employee_details that looks like this:

❖ E-R Diagram –

Emp_id Emp_name Emp_zip Emp_state Emp_city Emp_district

1001 Ketan 282005 Maharashtra Shirdi Ahmednagar

1002 Shahid 222008 Maharashtra Kopargaon Ahmednagar

1006 Omkar 282007 Maharashtra Rahata Ahmednagar

1101 Saurabh 292008 Maharashtra Rahuri Ahmednagar

1201 Pushkar 222999 Maharashtra Kopargaon Ahmednagar

Super keys: {emp_id}, {emp_id, emp_name}, {emp_id, emp_name, emp_zip}…so

on
Candidate Keys: {emp_id}

Non-prime attributes: all attributes except emp_id are non-prime as they are not

part of any candidate keys.

Here, emp_state, emp_city & emp_district dependent on emp_zip. And,

emp_zip is dependent on emp_id that makes non-prime attributes (emp_state,
emp_city & emp_district) transitively dependent on super key (emp_id). This
violates the rule of 3NF.

To make this table complies with 3NF we have to break the table into two tables
to remove the transitive dependency:

• Employee table:

Emp_id Emp_name Emp_zip

1001 Ketan 282005
1002 Shahid 222008
1006 Omkar 282007

1101 Saurabh 292008

1201 Pushkar 222999

Employee_zip table:

Emp_zip Emp_state Emp_city Emp_district

282005 UP Agra Dayal Bagh

222008 TN Chennai M-City

282007 TN Chennai Urrapakkam

292008 UK Pauri Bhagwan

222999 MP Gwalior Ratan

 Conclusions

In these project we will learn about various types of e-r diagrams and its
normalization .
The e-r diagrams are of the following points

1 : Suppose a company wants to store the names and contact details of its
employees. It creates a table that looks like this:
2 Suppose a school wants to store the data of teachers and the subjects
they teach. They create a table that looks like this: Since a teacher can
teach more than one subjects, the table can have multiple rows for a
same teacher.

3 Suppose a company wants to store the complete address of each

employee, they create a table named employee_details that looks like
this:
 References
Www.google.com
Http://52.72.36.160/polycomp