Employee Management
System
Submitted by :👇
Submmited to:
Debjani Das
prof. Priyanka Tripathi
Himmanshu
Rishikesh
Anand patidar
Tejram Borana
Priyanshu
Sachin Singh
Normalization
Normalization is a process of organizing the data in
database to avoid data redundancy, insertion anomaly, update
anomaly & deletion anomaly. Let’s discuss about anomalies
first then we will discuss normal forms with examples.
Example: Suppose a manufacturing company stores the employee details in
a table named employee that has four attributes: emp_id for storing
employee’s id, emp_name for storing employee’s name, emp_address for
storing employee’s address and emp_dept for storing the department details
in which the employee works. At some point of time the table looks like this:
Emp_id Emp_name Emp_address Emp_dept
101 Aman Indore D001
101 Aman Indore D002
185 Pankaj Ajmer D003
104 Suraj Bhopal D900
104 Suraj Bhopal D893
The above table is not normalized. We will see the problems that
we face when a table is not normalized.
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: Suppose a company wants to store the names and contact details of its
employees. It creates a table that looks like this:
Emp_id Emp_name Emp_address Emp_mobile
101 Aman Indore 8912312390
102 Ankit Bilaspur 8812121212
103 Pankaj Raipur 9900012222
104 Kamal Bhopal 7778881212
105 Suraj Panipat 8123450987
Two employees (Jon & Lester) 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 Jon
& Lester 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 Aman Indore 8912312390
102 Ankit Bilaspur 8812121212
102 Ankit Bilaspur 8812121212
103 Kamal Bhopal 7778881212
104 Suraj Panipat 8123450987
104 Suraj Panipat 8123450987
Second Normal Form
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: 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.
Emp_id Emp_name Emp_prof. Emp_age
101 Aman Data Analysis 38
101 Aman Programmer 38
102 Ankit Data Scientist 50
103 Suraj SDE 40
103 Suraj SDE 40
Candidate Keys: {teacher_id, subject}
Non prime attribute: teacher_age
To make the table complies with 2NF we can break it in two
tables like this:
teacher_details table:
Emp_id Emp_age Emp_id Emp_prof.
101 Data Analysis
101 38
101 Programmer
101 38
102 Data
102 50 Scientist
103 SDE
103 40
103 SDE
103 40
Now the tables comply with Second normal form (2NF).
A table design is said to be in 3NF if both the following conditions
Third
hold: Normal form (3NF)
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: Suppose a company wants to store the
complete address of each employee, they create a table
named employee_details that looks like this:
Emp_id Emp_na Emp_pin Emp_dis Emp_cit Emp_sta
me y te
101 sonu 235695 Indore indore M.P.
145 Aman 952641 Baliya kanpur U.P.
147 Ankit 269584 Urrapakkam Chennai TN
346 neeraj 458545 Dayal Bagh Agra UP
467 Suraj 455871 bhopal Sihor MP
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:
Emp_ Emp_ Emp_c Emp_s
Emp_id Emp_n Emp_pi pin dis ity tate
ame n
235695 Indore indore M.P.
101 sonu 235695
145 Aman 952641 952641 Baliya kanpur U.P.
147 Ankit 269584
269584 Urrapakk Chenn TN
am ai
346 neeraj 458545
467 Suraj 455871 458545 Dayal Agra UP
Bagh
455871 bhopal Sihor MP
Boyce Codd normal form
(BCNF)
It is an advance version of 3NF that’s why it is also
referred as 3.5NF. BCNF is stricter than 3NF. A table
complies with BCNF if it is in 3NF and for every
functional dependency X->Y, X should be the super
key of the table.
Example: Suppose there is a company wherein
employees work in more than one department.
They store the data like this:
Emp_id Emp_nati Emp_dept Dept_type Dept_emp
onality
1001 Indian Hardware D0023 200
1001 Indian Stores D0023 250
1002 American Technical C034 100
suport
1002 American production C034 600
Functional dependencies in the table above:
emp_id -> emp_nationality
emp_dept -> {dept_type, dept_no_of_emp}
Candidate key: {emp_id, emp_dept}
The table is not in BCNF as neither emp_id nor
emp_dept alone are keys.
To make the table comply with BCNF we can break the
table in three tables like this:
emp_nationality table: emp_dept table:
Emp_id Emp_nati Emp_dept Dept_type Dept_emp
onality
1001 Indian Hardware D0023 200
1002 American Stores D0023 250
Technical C034 100
suport
production C034 600
emp_dept_mapping table:
Emp_id Emp_dept
1001 Hardware
1001 Stores
1002 Technical suport
1002 production
Functional dependencies:
emp_id -> emp_nationality
emp_dept -> {dept_type, dept_no_of_emp}
Candidate keys:
For first table: emp_id
For second table: emp_dept
For third table: {emp_id, emp_dept}
Thank You
