Scribd
Upload
18 views

Normalization.docx

The document discusses database normalization, which aims to eliminate anomalies such as update, deletion, and insert anomalies to maintain data consistency. It outlines the different normal forms: First Normal Form (1NF) requires atomic values, Second Normal Form (2NF) mandates that non-prime attributes depend fully on the primary key, and Third Normal Form (3NF) eliminates transitive dependencies. Additionally, Boyce-Codd Normal Form (BCNF) is introduced as a stricter version of 3NF, ensuring that for every functional dependency, the left side must be a superkey.

Uploaded by

nagargojevaishnav34
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
18 views

Normalization.docx

The document discusses database normalization, which aims to eliminate anomalies such as update, deletion, and insert anomalies to maintain data consistency. It outlines the different normal forms: First Normal Form (1NF) requires atomic values, Second Normal Form (2NF) mandates that non-prime attributes depend fully on the primary key, and Third Normal Form (3NF) eliminates transitive dependencies. Additionally, Boyce-Codd Normal Form (BCNF) is introduced as a stricter version of 3NF, ensuring that for every functional dependency, the left side must be a superkey.

Uploaded by

nagargojevaishnav34
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 9

Normalization

If a database design is not perfect, it may contain anomalies, which are like a bad dream for any
database administrator. Managing a database with anomalies is next to impossible.
● Update anomalies − If data items are scattered and are not linked to each other
properly, then it could lead to strange situations. For example, when we try to update one
data item having its copies scattered over several places, a few instances get updated
properly while a few others are left with old values. Such instances leave the database in
an inconsistent state.
● Deletion anomalies − We tried to delete a record, but parts of it was left undeleted
because of unawareness, the data is also saved somewhere else.
● Insert anomalies − We tried to insert data in a record that does not exist at all.
Normalization is a method to remove all these anomalies and bring the database to a consistent
state.

First Normal Form


First Normal Form is defined in the definition of relations (tables) itself. This rule defines that
all the attributes in a relation must have atomic domains. The values in an atomic domain are
indivisible units.

We re-arrange the relation (table) as below, to convert it to First Normal Form.

Each attribute must contain only a single value from its pre-defined domain.
Second Normal Form
Before we learn about the second normal form, we need to understand the following −
● Prime attribute − An attribute, which is a part of the candidate-key, is known as a
prime attribute.
● Non-prime attribute − An attribute, which is not a part of the prime-key, is said to be a
non-prime attribute.
If we follow second normal form, then every non-prime attribute should be fully functionally
dependent on prime key attribute. That is, if X → A holds, then there should not be any proper
subset Y of X, for which Y → A also holds true.

We see here in Student_Project relation that the prime key attributes are Stu_ID and Proj_ID.
According to the rule, non-key attributes, i.e. Stu_Name and Proj_Name must be dependent
upon both and not on any of the prime key attribute individually. But we find that Stu_Name
can be identified by Stu_ID and Proj_Name can be identified by Proj_ID independently. This is
called partial dependency, which is not allowed in Second Normal Form.

We broke the relation in two as depicted in the above picture. So there exists no partial
dependency.
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.

teacher_i
subject teacher_age
d

111 Maths 38

111 Physics 38

222 Biology 38

333 Physics 40

Chemistr
333 40
y

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


For a relation to be in Third Normal Form, it must be in Second Normal form and the following
must satisfy −

● No non-prime attribute is transitively dependent on prime key attribute.


● For any non-trivial functional dependency, X → A, then either −
o X is a superkey or,
o A is prime attribute.
We find that in the above Student_detail relation, Stu_ID is the key and only prime key
attribute. We find that City can be identified by Stu_ID as well as Zip itself. Neither Zip is a
superkey nor is City a prime attribute. Additionally, Stu_ID → Zip → City, so there
exists transitive dependency.
To bring this relation into third normal form, we break the relation into two relations as follows

Boyce-Codd Normal Form


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_nationality emp_dept dept_type dept_no_of_emp


1001 Austrian Production and planning D001 200

1001 Austrian stores D001 250

design and technical


1002 American D134 100
support

1002 American Purchasing department D134 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_id emp_nationality

1001 Austrian
1002 American

emp_dept table:

dept_no_of_em
emp_dept dept_type
p

Production and planning D001 200

stores D001 250

design and technical support D134 100

Purchasing department D134 600

emp_dept_mapping table:

emp_id emp_dept

1001 Production and planning


1001 stores

1002 design and technical support

1002 Purchasing department

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}

This is now in BCNF as in both the functional dependencies left side part is a key.

You might also like