Normalization
Normalization is the process of organizing data in a database to reduce redundancy and
improve data integrity. It is done in steps called normal forms (NF).Also reduce insertion,
deletion and updation anomalies.
Types of Normalization (Normal Forms)
1.First Normal Form (1NF)
2. Second Normal Form (2NF)
3. Third Normal Form (3NF)
4. Boyce-Codd Normal Form (BCNF)
5. Fourth Normal Form (4NF)
6. Fifth Normal Form (5NF) / Project-Join Normal Form
1. First Normal Form (1NF)
Rule:
● Each column should have atomic (indivisible) values
● No repeating groups or arrays
Example (Before 1NF):
StudentI Na
Courses
D me
Math,
1 Anil
English
Bee
2 Science
na
After 1NF:
StudentI Na Cour
D me se
1 Anil Math
Englis
1 Anil
h
Bee Scien
2
na ce
2. Second Normal Form (2NF)
Rule:
● Must be in 1NF
● No partial dependency (non-key attribute depending on part of a composite key)
Example (Before 2NF):
StudentI Cour StudentNa
D se me
1 Math Anil
Engli
1 Anil
sh
Composite Key = (StudentID, Course)
StudentName depends only on StudentID → partial dependency
After 2NF:
● Student(StudentID, StudentName)
● Enroll(StudentID, Course)
3. Third Normal Form (3NF)
Rule:
● Must be in 2NF
● No transitive dependency (non-key attribute depends on another non-key attribute)
Example (Before 3NF):
EmpI Nam DeptI DeptNa
D e D me
101 Ravi 10 Sales
Mee
102 20 HR
na
DeptName depends on DeptID, not directly on EmpID → transitive dependency
After 3NF:
● Employee(EmpID, Name, DeptID)
● Department(DeptID, DeptName)
4. Boyce-Codd Normal Form (BCNF)
Rule:
● Stricter version of 3NF
● Every determinant must be a candidate key
Example:
Suppose a table where a professor teaches only one course, but each course may be taught by
multiple professors:
ProfI Cour De
D se pt
DBM
P1 CS
S
DBM
P2 CS
S
Here, Course → Dept, but Course is not a candidate key (ProfID is). Hence, it violates
BCNF.
5.Fourth Normal Form (4NF)
Definition:
A relation is in 4NF if:
● It is in BCNF, and
● It has no non-trivial multivalued dependencies (MVDs) other than those where the
left side is a superkey.
Example (Not in 4NF):
Suppose we have a table of students, their courses, and languages they speak:
s
Cour Langua
i
se ge
d
1 C English
1 C German
1 Java English
1 Java German
Interpretation:
● Student 1 takes both C and Java.
● Student 1 knows both English and German.
● These two attributes (Course and Language) are independent — i.e., the student
takes all combinations.
Multivalued Dependencies:
● sid ↠ Course
● sid ↠ Language
These MVDs violate 4NF because sid is not a superkey of the full table.
✅ 4NF Decomposition:
Break into two relations:
● R1(sid, Course)
● R2(sid, Language)
Cour
sid
se
1 C
1 Java
s
Langua
i
ge
d
1 English
1 German
Now both are in 4NF: no non-trivial MVDs unless the LHS is a superkey.
6. Fifth Normal Form (5NF) / Project-Join Normal Form
Definition:
A relation is in 5NF if:
● It is in 4NF, and
● Every join dependency in the relation is implied by its candidate keys.
Example (Not in 5NF):
Consider a table:
Cour Instruct Locati
se or on
DB Alice Room1
DB Alice Room2
DB Bob Room1
DB Bob Room2
🤔 Interpretation:
● Any instructor can teach the course in any room.
This is a 3-way combination, but none of the pairs alone tells the full story.
We can decompose into:
● R1(Course, Instructor)
● R2(Course, Location)
● R3(Instructor, Location)
Then, when we join them all together again, we get back the original.
✅ 5NF Decomposition:
Cour Instruct
se or
DB Alice
DB Bob
Locati
Course
on
DB Room1
DB Room2
Instruct Locati
or on
Alice Room1
Alice Room2
Bob Room1
Bob Room2
Each relation is in 5NF, and rejoining restores the full data without redundancy.
Functional dependency:
o If Y ⊆ X, then X → Y is trivial.
1. Trivial Functional Dependency:
o Example: {RollNo, Name} → Name
2. Non-Trivial Functional Dependency:
o If Y is not a subset of X, then X → Y is non-trivial.
o Example: RollNo → Name
3. Fully Functional Dependency:
o Y is fully functionally dependent on X if it is dependent on the entire set of X,
not just a part.
o Example: In relation (StudentID, CourseID, Marks),
(StudentID, CourseID) → Marks is fully functional.
4. Partial Dependency:
o Y depends on only part of a composite key.
o Example: StudentID → Name (when composite key is StudentID + CourseID)
5. Transitive Dependency:
o If X → Y and Y → Z, then X → Z is transitive.
o Example: RollNo → DeptID and DeptID → DeptName implies RollNo →
DeptName
7.Consider a relation R(A, B, C, D) with the following functional dependencies
B→A
A→C
AB → D
D→AC
Perform the following
Identify the candidate keys
Normalize the relation into 3NF
Is the relation in BCNF? Justify
If not, decompose it into BCNF
1. Candidate Keys
Let’s compute attribute closures to determine candidate keys:
From a reliable normalization source:
● A⁺ = {A, C}
● B⁺ = {B, A, C, D} = ABCD, so B determines all attributes → B is a candidate key.
● For other subsets:
o AC⁺ = {A, C}
o AD⁺ = {A, C, D} = ACD
o CD⁺ = {C, A, D} = A C D
o ACD⁺ = A C D
None of these determine all of ABCD. Thus the only candidate key is {B}.
2. Normalize into 3NF
First, determine prime vs non-prime attributes:
● Prime attribute: appears in a candidate key → here, only B is prime.
● Non-prime attributes: A, C, D.
Check each FD against 3NF conditions:
3NF requires that for each dependency X → Y:
1. X is a superkey, or
2. Every attribute in Y is prime.
Let’s examine:
● B → A: B is a candidate key, so satisfies 3NF.
● A → C: A is not a superkey, and C is non-prime. → violates 3NF.
● AB → D: AB is a superset of key B, thus a superkey → satisfies 3NF.
● D → A C: D is not a superkey; and A, C are both non-prime → violates 3NF.
Hence, the relation is not in 3NF due to the violations from A → C and D → AC.
Decomposition into 3NF:
We decompose R to address these problematic dependencies:
1. For A → C: Create relation R1(A, C).
2. For D → A C: Create relation R2(D, A, C).
3. The remaining attributes and dependencies: keep a relation R3(B, A, D) capturing B
→ A and AB → D.
Thus we get:
● R1(A, C) with A → C (A is key).
● R2(D, A, C) with D → A C (D is key).
● R3(B, A, D) with B → A and B → D via AB → D (B is key).
Each of these relations is in 3NF, since in each, the left-hand side of every FD is a superkey.
This decomposition ensures dependency preservation and lossless-join property.
3. Is the original relation in BCNF?
Recall from definitions:
BCNF requires that for every FD X → Y, X must be a superkey (unless the dependency is
trivial
Let’s check:
● B → A: B is the key → OK.
● A → C: A is not a key → violates BCNF.
● AB → D: AB is a superkey → OK.
● D → A C: D is not a key → violates BCNF.
So the relation is not in BCNF due to the dependencies A → C and D → AC, whose left-
hand sides are not superkeys.
4. Decompose into BCNF
Following the standard BCNF decomposition process:
Step 1: Pick a violation, say A → C
● Compute A⁺ = {A, C}.
● Decompose R into:
o R₁(A, C)
o R' = R – (C) ∪ (A) = {A, B, D}
Step 2: Check R' (A, B, D) for BCNF violations
Functional dependencies in R':
● B → A, AB → D, and D → A (since D → AC implies D → A in R').
● B → A: B is a key for R'? Let’s compute B⁺ in R'(A, B, D):
o B⁺ = {B, A, then AB → D gives D} → B is a key. OK.
● AB → D: AB is a superkey → OK.
● D → A: D is not a key → violation.
Step 3: Decompose R' on D → A
● Compute D⁺ = {D, A}.
● Decompose R' into:
o R₂(D, A)
o R₃ = {D, B}
Now check:
● R₂(D, A) has D → A, and D is key → BCNF.
● R₃(B, D): check dependencies—only AB → D no longer relevant here; no nontrivial
FDs → trivially BCNF.
Final BCNF decomposition:
● R₁(A, C)
● R₂(D, A)
● R₃(B, D)
All are in BCNF, and together they preserve dependencies and support lossless-join
decomposition.
Summary Table
Step Outcome
Candidate Keys {B}
Is in 3NF? No; violations: A → C, D → AC
R1(A, C), R2(D, A, C),
3NF Decomposition
R3(B, A, D)
Is in BCNF? No; violations: A → C, D → AC
BCNF
R₁(A, C), R₂(D, A), R₃(B, D)
Decomposition
8. Compute to normal form using multivalued dependency. (16)
Soultion:
Normalize the given table into Fourth Normal Form (4NF) using multivalued
dependencies, need to address the redundancy caused by independent multivalued
attributes.
The table Student_Details(sid, Course, Skill) currently has sid determining
multiple Course values and multiple Skill values independently, which signifies a
multivalued dependency like sid ->-> Course and sid ->-> Skill.
To achieve 4NF, we decompose the original table into separate tables, each
representing a single multivalued dependency.
1. Identify Multivalued Dependencies:
● sid ->-> Course: A student (identified by sid) can take multiple courses, and these
courses are independent of the skills the student possesses.
● sid ->-> Skill: A student (identified by sid) can have multiple skills, and these
skills are independent of the courses the student takes.
2. Decompose the Table to Eliminate Multivalued Dependencies:
Based on these multivalued dependencies, we decompose
the Student_Details table into two new tables:
● Student_Courses table: This table will capture the sid to Course multivalued
dependency.
o Schema: Student_Courses (sid, Course)
o Content:
Sid Course
1 C
1 C++
2 Java
● Student_Skills table: This table will capture the sid to Skill multivalued
dependency.
o Schema: Student_Skills (sid, Skill)
o Content:
Sid Skill
1 English
1 German
2 English
2 French
Resulting Normalized Tables (in 4NF):
● Student_Courses (sid, Course)
● Student_Skills (sid, Skill)
Explanation of how this achieves 4NF:
By separating the Course and Skill attributes, which are independently multivalued
dependent on sid, into their own tables, we eliminate the non-trivial multivalued
dependencies in the original table. Each new table
(Student_Courses and Student_Skills) now contains only one multivalued
dependency (which is also a functional dependency in the context of these new
tables where the key is the combination of attributes, e.g., {sid, Course} and {sid,
Skill}), thus satisfying the conditions for Fourth Normal Form. This decomposition
reduces data redundancy and improves data integrity, preventing anomalies that
could arise from managing independent multivalued attributes within a single table.
