0% found this document useful (0 votes)
0 views

dbms unit 3

The document provides a comprehensive overview of database normalization forms (1NF to 5NF) and their rules, including examples of how to convert tables to meet each normal form. It also explains key concepts such as primary keys, foreign keys, candidate keys, and super keys, along with definitions and examples. Additionally, it touches on dependency preservation, multivalued dependencies, join dependencies, and Domain-Key Normal Form (DKNF).

Uploaded by

pratikgjimt
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
0 views

dbms unit 3

The document provides a comprehensive overview of database normalization forms (1NF to 5NF) and their rules, including examples of how to convert tables to meet each normal form. It also explains key concepts such as primary keys, foreign keys, candidate keys, and super keys, along with definitions and examples. Additionally, it touches on dependency preservation, multivalued dependencies, join dependencies, and Domain-Key Normal Form (DKNF).

Uploaded by

pratikgjimt
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 9

Sure!

Here’s a simple and easy-to-understand explanation of all normal


forms (NF) in layman’s terms, with examples.

1NF (First Normal Form) – "Keep it Atomic"


� Rule: Each column should have only one value per row (no multiple
values in a single cell).
Example (Not in 1NF):
Student_ID Name Subjects
101 John Math, Science
102 Emma English, History
� Issue: The "Subjects" column has multiple values in one cell.
✅ Fix (Convert to 1NF):
Student_ID Name Subject
101 John Math
101 John Science
102 Emma English
102 Emma History

2NF (Second Normal Form) – "No Partial Dependencies"


� Rule: Remove partial dependencies, meaning every non-key column
should depend on the whole primary key, not just part of it.
✅ Only applies if there is a composite key (more than one column as the
primary key).
Example (Not in 2NF):
Student_ID Course Instructor
101 Math Mr. Smith
102 Science Ms. Jane
� Issue: If the primary key is (Student_ID, Course), then Instructor only
depends on Course, not on Student_ID.
✅ Fix (Convert to 2NF):
Break into two tables:

Student-Course Table

Student_ID Course
101 Math
102 Science
Course-Instructor Table

Course Instructor
Math Mr. Smith
Science Ms. Jane

Now, every column depends fully on the primary key.

3NF (Third Normal Form) – "No Transitive Dependencies"


� Rule: Remove transitive dependencies, meaning no column should
depend on another non-key column.
✅ Every column should depend only on the primary key, not on another
column that is not the key.
Example (Not in 3NF):
Employee_ID Name Department Department_Location
201 John HR 2nd Floor
202 Emma IT 3rd Floor
� Issue: Department_Location depends on Department, not directly on
Employee_ID.
✅ Fix (Convert to 3NF):
Break into two tables:

Employee Table

Employee_ID Name Department


201 John HR
202 Emma IT

Department Table

Department Department_Location
HR 2nd Floor
IT 3rd Floor

Now, Department_Location depends directly on Department, not


Employee_ID.

BCNF (Boyce-Codd Normal Form) – "Even Stronger 3NF"


� Rule: Every determinant (column that decides another column's value)
must be a super key (a unique identifier).
✅ BCNF is stricter than 3NF. It removes anomalies even when 3NF
seems okay but has extra dependencies.
Example (Not in BCNF):
Teacher Subject Department
Mr. A Math Science
Mr. B Physics Science
Mr. C History Arts
� Issue:

Teacher → Subject (Teacher determines the subject).

Department depends only on Subject, not Teacher.

✅ Fix (Convert to BCNF):

Teacher-Subject Table:

Teacher Subject
Mr. A Math
Mr. B Physics
Mr. C History

Subject-Department Table:

Subject Department
Math Science
Physics Science
History Arts

Now, all dependencies are correct.

4NF (Fourth Normal Form) – "Remove Multivalued Dependencies"


� Rule: If a column has multiple independent values, split into separate
tables to remove redundancy.
Example (Not in 4NF):
Student_ID Course Hobby
101 Math Chess
101 Math Music
101 Science Chess
101 Science Music
� Issue: Course and Hobby are independent but repeated.
✅ Fix (Convert to 4NF):

Student-Course Table:

Student_ID Course
101 Math
101 Science

Student-Hobby Table:

Student_ID Hobby
101 Chess
101 Music

Now, no redundancy!

5NF (Fifth Normal Form) – "Remove Join Dependencies"


� Rule: If breaking the table loses data when rejoining, keep it in one table.
✅ Used in complex databases with many relationships.

TL;DR – Simple Summary


Normal
Rule Fix
Form
No multiple values in a
1NF Break into separate rows
column
Remove attributes that depend on
2NF No partial dependencies
part of a composite key
No transitive Move indirectly dependent
3NF
dependencies columns to a new table
Every determinant must
BCNF Further decompose if necessary
be a super key
4NF No multivalued Split into separate tables
Normal
Rule Fix
Form
dependencies
5NF No join dependencies Used in very complex databases

Final Thought
If you're just starting, learning up to 3NF or BCNF is usually enough for
most databases! �
Would you like me to explain any part in even simpler terms? �

Dependency Preservation in DBMS


Dependency preservation is a key property in database normalization that
ensures functional dependencies (FDs) are maintained after decomposing
a relation (table) into smaller tables.

When a relation is decomposed into multiple smaller relations during


normalization, it is essential that:

All functional dependencies from the original relation are still enforced in
the decomposed tables.

The lossless join property is maintained (so no data is lost when joining
the tables back).

Multivalued Dependency (MVD) in DBMS


Multivalued Dependency (MVD) is a type of dependency in a relational
database where one attribute in a table uniquely determines multiple
values of another attribute, independent of other attributes.

Definition
A multivalued dependency (MVD) exists in a relation R(A, B, C) if:

For a fixed value of A, the values of B are independent of the values of C.

It is represented as:
A ⇝ B (A multidetermines B)

This means that for each value of A, there can be multiple values of B,
and multiple values of C, but B and C are independent of each other.
Join Dependency (JD)

A Join Dependency (JD) occurs when a table can be decomposed (split


into smaller tables) and then perfectly reconstructed (joined back) without
losing any data.

� A table has a Join Dependency if it can be split into two or more tables,
and when joined back, it gives the original table without extra or missing
records.

Domain-Key Normal Form (DKNF) – "The Ultimate Normal Form"

� Definition:

A table is in Domain-Key Normal Form (DKNF) if it follows all normal


forms (1NF, 2NF, 3NF, BCNF, 4NF, 5NF) and every constraint on the
table is based only on the domain (valid values) and keys.

In simpler terms, DKNF ensures that all business rules and constraints are
enforced using domain restrictions and keys, without relying on
additional functional dependencies.

Here’s a simple explanation of Primary Key, Foreign Key, Candidate


Key, and Super Key with easy-to-understand examples:

l Primary Key (PK) – "Unique Identifier"

A Primary Key is a column (or set of columns) that uniquely identifies


each row in a table.

It cannot have duplicate or NULL values.

✅ Example:
StudentID (PK) Name Age
101 John 20
102 Emma 22
� StudentID is the Primary Key because:
✔ It is unique for every student.
✔ It doesn’t allow NULL values.

m Foreign Key (FK) – "Link Between Tables"

A Foreign Key is a column in one table that refers to the Primary Key of
another table.

It is used to establish a relationship between two tables.

✅ Example:
Student Table:
StudentID (PK) Name Age
101 John 20
102 Emma 22
Course Table:
CourseID (PK) CourseName StudentID (FK)
C101 Math 101
C102 Science 102
� StudentID in the Course Table is a Foreign Key because it links to the
StudentID in the Student Table.

n Candidate Key – "Multiple Unique Options"

A Candidate Key is a set of columns that could be a Primary Key because


they are unique and not NULL.

A table can have multiple Candidate Keys, but only one is chosen as the
Primary Key.

✅ Example:
EmployeeID Email Phone Name
E001 [email protected] 9876543210 John
E002 [email protected] 8765432109 Emma
� Possible Candidate Keys:

EmployeeID (Unique and Not NULL)


Email (Unique and Not NULL)

Phone (Unique and Not NULL)

✔ We can choose one as the Primary Key (e.g., EmployeeID).


✔ The remaining are still Candidate Keys.

o Super Key – "Super Set of Keys"

A Super Key is any set of columns that can uniquely identify a row.

Every Primary Key and Candidate Key is a Super Key, but not every
Super Key is a Candidate Key.

Super Key can have extra unnecessary columns along with the unique
column.

✅ Example:
EmployeeID Email Phone Name
E001 [email protected] 9876543210 John
E002 [email protected] 8765432109 Emma
� Super Keys:
✔ (EmployeeID) – Minimal, so it’s a Candidate Key too.
✔ (Email) – Minimal, so it’s a Candidate Key too.
✔ (Phone) – Minimal, so it’s a Candidate Key too.
✔ (EmployeeID, Name) – Not minimal, because Name is unnecessary.
✔ (Email, Phone) – Not minimal, because one of them alone is enough.
Summary:
Key Type Definition Example

Primary A unique and non-null column that


StudentID in Student Table
Key identifies each row.

Foreign A column that links to a Primary StudentID in Course Table


Key Key in another table. (refers to Student Table)

Candidate All possible columns that could be


EmployeeID, Email, Phone
Key the Primary Key.

Any set of columns that uniquely


EmployeeID, Name or
Super Key identify a row (may contain extra
Email, Phone
columns).

Let me know if you want more examples or a deeper explanation! �

You might also like