Scribd
Upload
2 views

DBMS_Normalization

The document explains DBMS normalization, detailing the four normal forms: 1NF, 2NF, 3NF, and BCNF, with examples illustrating how to achieve each form. Normalization aims to eliminate redundancy and enhance data consistency by ensuring that all attributes depend on the primary key without partial or transitive dependencies. The final summary table outlines the conditions for each normal form, emphasizing the importance of structured data storage.

Uploaded by

shub99gaikwad
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
2 views

DBMS_Normalization

The document explains DBMS normalization, detailing the four normal forms: 1NF, 2NF, 3NF, and BCNF, with examples illustrating how to achieve each form. Normalization aims to eliminate redundancy and enhance data consistency by ensuring that all attributes depend on the primary key without partial or transitive dependencies. The final summary table outlines the conditions for each normal form, emphasizing the importance of structured data storage.

Uploaded by

shub99gaikwad
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/ 5

DBMS Normalization with Examples

Normalization in DBMS (Basic Explanation with Examples)

Normalization helps in structuring a database to remove redundancy


and improve consistency.
Let's break down each normal form with simple examples.

1NF (First Normal Form) - Atomic Values


Rule: A table is in 1NF if all its attributes (columns) contain only
atomic values (indivisible values).

Example (Before 1NF - Not Atomic)


| Student_ID | Name | Subjects |
|------------|------|-----------------|
|1 | John | Math, Science |
|2 | Alice| English, History |

Problem: The Subjects column contains multiple values, violating


1NF.

Solution (Convert to 1NF)


| Student_ID | Name | Subject |
|------------|------|---------|
|1 | John | Math |
|1 | John | Science |
|2 | Alice| English |
|2 | Alice| History |

Now, each Subject is in a separate row. The table is in 1NF because


all values are atomic.

--------------------------------------------------------
2NF (Second Normal Form) - Full Functional Dependency
Rule: A table is in 2NF if:
1. It is in 1NF.
2. All non-key attributes depend fully on the primary key (no partial
dependency).

Example (Before 2NF - Partial Dependency)


| Order_ID | Product_ID | Product_Name | Customer_Name |
|----------|------------|--------------|--------------|
|1 | P1 | Laptop | John |
|2 | P2 | Phone | Alice |

Problem: Product_Name depends only on Product_ID, not on


Order_ID.

Solution (Convert to 2NF)


New Table 1: Orders
| Order_ID | Customer_Name |
|----------|--------------|
|1 | John |
|2 | Alice |

New Table 2: Products


| Product_ID | Product_Name |
|------------|--------------|
| P1 | Laptop |
| P2 | Phone |

New Table 3: Order_Products (Linking Table)


| Order_ID | Product_ID |
|----------|------------|
|1 | P1 |
|2 | P2 |
Now, Product_Name depends only on Product_ID, not Order_ID,
making it 2NF compliant.

--------------------------------------------------------

3NF (Third Normal Form) - No Transitive Dependency


Rule: A table is in 3NF if:
1. It is in 2NF.
2. There is no transitive dependency (non-key attributes should not
depend on other non-key attributes).

Example (Before 3NF - Transitive Dependency)


| Employee_ID | Name | Department_ID | Department_Name |
|------------|------|--------------|---------------|
|1 | John | D1 | HR |
|2 | Alice| D2 | IT |

Problem: Department_Name depends on Department_ID, not


Employee_ID.

Solution (Convert to 3NF)


New Table 1: Employees
| Employee_ID | Name | Department_ID |
|------------|------|--------------|
|1 | John | D1 |
|2 | Alice| D2 |

New Table 2: Departments


| Department_ID | Department_Name |
|--------------|---------------|
| D1 | HR |
| D2 | IT |
Now, Department_Name depends only on Department_ID, making it
3NF compliant.

--------------------------------------------------------

BCNF (Boyce-Codd Normal Form) - Stronger 3NF


Rule: A table is in BCNF if:
1. It is in 3NF.
2. Every determinant (a column that determines another column)
must be a candidate key.

Example (Before BCNF - Dependency Issue)


| Teacher_ID | Subject | Department |
|------------|---------|------------|
| T1 | Math | Science |
| T2 | Physics | Science |
| T3 | History | Arts |

Problem: Subject is not a primary key but determines Department,


violating BCNF.

Solution (Convert to BCNF)


New Table 1: Teachers
| Teacher_ID | Subject |
|------------|---------|
| T1 | Math |
| T2 | Physics |
| T3 | History |

New Table 2: Subjects


| Subject | Department |
|----------|-----------|
| Math | Science |
| Physics | Science |
| History | Arts |

Now, every determinant is a candidate key, making the table BCNF


compliant.

--------------------------------------------------------

Final Summary:
| Normal Form | Condition |
|------------|------------|
| 1NF | No repeating groups or multiple values in a column. |
| 2NF | No partial dependency (All non-key attributes depend fully on
the primary key). |
| 3NF | No transitive dependency (Non-key attributes should depend
only on the primary key). |
| BCNF | Stronger 3NF, every determinant must be a candidate key. |

This process ensures efficient data storage, avoids redundancy, and


improves consistency in databases.

You might also like