Assignment 3- Normalization

Contents
1 Scenario 1: University Course Registration System 3

2 Unnormalized Form (UNF) 3

3 First Normal Form (1NF) 3

4 Second Normal Form (2NF) 3

4.1 Issues of partial dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4.2 Student Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4.3 Course Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4.4 Instructor Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4.5 Registration Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

5 Third Normal Form (3NF) 4

5.1 Registration Table (Updated) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5.2 Course Instructor Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

6 Final Normalized Schema 4

7 Scenario 2: Online Shopping Database Normalization 4

7.1 Step 1: Identify the Unnormalized Form (UNF) . . . . . . . . . . . . . . . . . . . . . . . . 4
7.2 Step 2: Convert to First Normal Form (1NF) . . . . . . . . . . . . . . . . . . . . . . . . . 5
7.3 Step 3: Convert to Second Normal Form (2NF) . . . . . . . . . . . . . . . . . . . . . . . . 5
7.3.1 Customer Table (2NF-compliant) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.3.2 Order Table (2NF-compliant) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.3.3 Order-Product Table (2NF-compliant) . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.3.4 Product Table (2NF-compliant) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.4 Step 4: Convert to Third Normal Form (3NF) . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.4.1 Final Tables in 3NF: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.4.2 Customer Table (3NF) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.4.3 Order Table (3NF) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.4.4 Order-Product Table (3NF) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.4.5 Product Table (3NF) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.4.6 Category Table (3NF) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

8 Final Outcome 7

9 Hospital Patient Record Normalization 8

9.1 1. Unnormalized Form (UNF) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.2 2. First Normal Form (1NF) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.3 3. Second Normal Form (2NF) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.3.1 Patient Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.3.2 Doctor Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.3.3 Treatment Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.3.4 PatientTreatment Table (Junction Table) . . . . . . . . . . . . . . . . . . . . . . . 9
9.4 4. Third Normal Form (3NF) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.4.1 Doctor Table (Modified) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.4.2 Specialization Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1
 9.4.3 Patient Table (Same as 2NF) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.4.4 Treatment Table (Same as 2NF) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.4.5 PatientTreatment Table (Same as 2NF) . . . . . . . . . . . . . . . . . . . . . . . . 10

10 Library Management System Normalization 10

10.1 1. Unnormalized Form (UNF) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.2 2. First Normal Form (1NF) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.3 3. Second Normal Form (2NF) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.3.1 Book Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.3.2 Member Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.3.3 Loan Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.4 4. Third Normal Form (3NF) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.4.1 Author Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.4.2 Book Table (Modified) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.4.3 Member Table (Same as 2NF) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.4.4 Loan Table (Same as 2NF) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

11 Employee Payroll System Normalization 12

11.1 1. Unnormalized Form (UNF) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
11.2 2. First Normal Form (1NF) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
11.3 3. Second Normal Form (2NF) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
11.3.1 Employee Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
11.3.2 Department Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
11.3.3 EmployeeDepartment Table (Junction Table) . . . . . . . . . . . . . . . . . . . . . 13
11.3.4 TaxBracket Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
11.4 4. Third Normal Form (3NF) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
11.4.1 TaxBracket Table (Modified) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
11.4.2 Employee Table (Modified) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
11.4.3 Department Table (Same as 2NF) . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
11.4.4 EmployeeDepartment Table (Same as 2NF) . . . . . . . . . . . . . . . . . . . . . . 14

2
1 Scenario 1: University Course Registration System
2 Unnormalized Form (UNF)

Student ID Student Name Course IDs Course Names Instructor IDs Instructor Names
S1 Alice C101, C102 DBMS, OOP I1, I2 Dr. Smith, Prof. Lee
S2 Bob C101 DBMS I1 Dr. Smith

• A student can enroll in multiple courses:

– Course ID and Course Name have multiple values in a row.
• A course can have multiple instructors:
– Instructor ID and Instructor Name have multiple values in a row.

3 First Normal Form (1NF)

To achieve 1NF, we must ensure atomicity (each cell contains a single value), meaning we separate
multivalued attributes into individual rows.

Student ID Student Name Course ID Course Name Instructor ID Instructor Name

S1 Alice C101 DBMS I1 Dr. Smith
S1 Alice C102 OOP I2 Prof. Lee
S2 Bob C101 DBMS I1 Dr. Smith

4 Second Normal Form (2NF)

4.1 Issues of partial dependencies
• Student Name depends only on Student ID (not the full composite key).

• Course Name and Instructor ID depend only on Course ID.

4.2 Student Table

Student ID Student Name

S1 Alice
S2 Bob

4.3 Course Table

Course ID Course Name

C101 DBMS
C102 OOP

4.4 Instructor Table

Instructor ID Instructor Name

I1 Dr. Smith
I2 Prof. Lee

3
4.5 Registration Table

Student ID Course ID Instructor ID

S1 C101 I1
S1 C102 I2
S2 C101 I1

5 Third Normal Form (3NF)

5.1 Registration Table (Updated)

Student ID Course ID
S1 C101
S1 C102
S2 C101

5.2 Course Instructor Table

Course ID Instructor ID
C101 I1
C102 I2

6 Final Normalized Schema

• Student(Student ID, Student Name)
• Course(Course ID, Course Name)
• Instructor(Instructor ID, Instructor Name)

• Registration(Student ID, Course ID)

• Course Instructor(Course ID, Instructor ID)

7 Scenario 2: Online Shopping Database Normalization

We will go through UNF → 1NF → 2NF → 3NF step by step.

7.1 Step 1: Identify the Unnormalized Form (UNF)

Theory: The Unnormalized Form (UNF) contains redundant and unstructured data where multiple
values exist in a single field. This violates the principle of atomicity.

4
 Order ID Customer Customer Product IDs Product Categories Quanti Price
ID Name Names ty
Shipping
Address
O101 C001 Ali Khan P001, P002 Laptop, Electronics 1, 2 1000, 50
Mouse
Lahore
O102 C002 Sara Malik P003 T-Shirt Clothing 3 20
Karachi
O103 C001 Ali Khan P004, P005 Book, Pen Books 2, 1 15, 2
Lahore

Issues in UNF:
• Multiple products in a single order (Product IDs, Product Names, Categories, Quantity, and Price
contain multiple values in a single row).

• Data redundancy (Customer details and shipping information are repeated).

7.2 Step 2: Convert to First Normal Form (1NF)

Theory: To achieve First Normal Form (1NF), we ensure atomicity by breaking multi-valued attributes
into separate rows. Each cell in the table should contain a single, indivisible value.

Order Customer Customer Product Product Category Quanti Price Shipping

ID ID Name ID Name ty Address
O101 C001 Ali Khan P001 Laptop Electronics 1 1000 Lahore
O101 C001 Ali Khan P002 Mouse Electronics 2 50 Lahore
O102 C002 Sara Malik P003 T-Shirt Clothing 3 20 Karachi
O103 C001 Ali Khan P004 Book Books 2 15 Lahore
O103 C001 Ali Khan P005 Pen Books 1 2 Lahore

Improvements in 1NF:
• Atomic values (each field contains a single value).
• Separate rows for each product in an order.

7.3 Step 3: Convert to Second Normal Form (2NF)

Theory: To achieve Second Normal Form (2NF), a table must first be in 1NF and have no partial
dependencies. A partial dependency occurs when a non-key attribute is functionally dependent on only
a proper subset of a composite primary key.
Identifying the Candidate Key: The composite primary key in 1NF is (Order ID, Product ID)
since:
• Order ID alone cannot uniquely identify a row (because an order can contain multiple products).
• Product ID alone cannot uniquely identify a row (because the same product can appear in different
orders).

Issues in 1NF:
• Customer Name and Shipping Address depend only on Customer ID (not on the full composite
key).
• Product Name, Category, and Price depend only on Product ID (not on the full composite key).

Breaking into Separate Tables: Now, we divide data into three tables to remove partial depen-
dencies:

5
7.3.1 Customer Table (2NF-compliant)

Customer ID Customer Name Shipping Address

C001 Ali Khan Lahore
C002 Sara Malik Karachi

7.3.2 Order Table (2NF-compliant)

Order ID Customer ID
O101 C001
O102 C002
O103 C001

7.3.3 Order-Product Table (2NF-compliant)

Order ID Product ID Quantity

O101 P001 1
O101 P002 2
O102 P003 3
O103 P004 2
O103 P005 1

7.3.4 Product Table (2NF-compliant)

Product ID Product Name Category Price

P001 Laptop Electronics 1000
P002 Mouse Electronics 50
P003 T-Shirt Clothing 20
P004 Book Books 15
P005 Pen Books 2

Improvements in 2NF:
• Customer details stored separately, reducing redundancy.

• Product details stored separately, avoiding duplication.

• Order-Product table links orders with products.

7.4 Step 4: Convert to Third Normal Form (3NF)

Theory: To achieve Third Normal Form (3NF), a table must first be in 2NF and have no transitive
dependencies. A transitive dependency occurs when a non-key attribute is functionally dependent on
another non-key attribute.
Issue in 2NF: Category depends on Product ID, not directly on the primary key of the Product
table.
Solution: Create a Separate Category Table: We now divide the Product Table further.

7.4.1 Final Tables in 3NF:

7.4.2 Customer Table (3NF)

Customer ID Customer Name Shipping Address

C001 Ali Khan Lahore
C002 Sara Malik Karachi

6
7.4.3 Order Table (3NF)

Order ID Customer ID
O101 C001
O102 C002
O103 C001

7.4.4 Order-Product Table (3NF)

Order ID Product ID Quantity

O101 P001 1
O101 P002 2
O102 P003 3
O103 P004 2
O103 P005 1

7.4.5 Product Table (3NF)

Product ID Product Name Price Category ID

P001 Laptop 1000 C001
P002 Mouse 50 C001
P003 T-Shirt 20 C002
P004 Book 15 C003
P005 Pen 2 C003

7.4.6 Category Table (3NF)

Category ID Category Name

C001 Electronics
C002 Clothing
C003 Books

Improvements in 3NF:
• No transitive dependencies.
• Category stored separately, reducing redundancy.

• Efficient and scalable database structure.

8 Final Outcome
Now, the database is in 3NF:

• No repeating groups (1NF)

• No partial dependencies (2NF)
• No transitive dependencies (3NF)
This structure eliminates redundancy and ensures data integrity, making the online shopping system
efficient.

7
9 Hospital Patient Record Normalization
9.1 1. Unnormalized Form (UNF)

PatientID PatientName DoctorID DoctorName Specialization TreatmentID Treat TreatDate

Name
101 Alice D01 Dr. John Cardiology T101 Angioplasty 2023-10-26
Smith Doe
101 Alice D01 Dr. John Cardiology T102 Medication 2023-10-27
Smith Doe
102 Bob John- D02 Dr. Jane Orthopedics T201 Physiotherapy 2023-10-26
son Lee
103 Carol D01 Dr. John Cardiology T301 ECG 2023-10-27
Williams Doe
103 Carol D01 Dr. John Cardiology T302 Medication 2023-10-28
Williams Doe
103 Carol D03 Dr. David Neurology T303 MRI 2023-10-29
Williams Kim

• Repeating Groups: A patient can have multiple treatments, leading to repeated pa-
tient and doctor information.

• Non-Atomic Fields: Although the fields themselves are generally atomic in this exam-
ple, the combination of multiple treatments per patient within the same rows leads
to logical non-atomicity.
• Data Redundancy: Patient and doctor details are repeated across multiple rows.

9.2 2. First Normal Form (1NF)

To convert to 1NF, we need to ensure each field contains atomic values and eliminate repeating groups.
This means each row should represent a single patient-treatment combination.

PatientID PatientName DoctorID DoctorName Specialization TreatmentID TreatName TreatDate

101 Alice D01 Dr. John Cardiology T101 Angioplasty 2023-10-26
Smith Doe
101 Alice D01 Dr. John Cardiology T102 Medication 2023-10-27
Smith Doe
102 Bob John- D02 Dr. Jane Orthopedics T201 Physiotherapy 2023-10-26
son Lee
103 Carol D01 Dr. John Cardiology T301 ECG 2023-10-27
Williams Doe
103 Carol D01 Dr. John Cardiology T302 Medication 2023-10-28
Williams Doe
103 Carol D03 Dr. David Neurology T303 MRI 2023-10-29
Williams Kim

9.3 3. Second Normal Form (2NF)

To convert to 2NF, we need to eliminate partial dependencies. This means creating separate tables for
patients, doctors, and treatments, and linking them using foreign keys.

9.3.1 Patient Table

PatientID PatientName
101 Alice Smith
102 Bob Johnson
103 Carol Williams

8
9.3.2 Doctor Table

DoctorID DoctorName Specialization

D01 Dr. John Doe Cardiology
D02 Dr. Jane Lee Orthopedics
D03 Dr. David Kim Neurology

9.3.3 Treatment Table

TreatmentID TreatmentName
T101 Angioplasty
T102 Medication
T201 Physiotherapy
T301 ECG
T302 Medication
T303 MRI

9.3.4 PatientTreatment Table (Junction Table)

PatientID DoctorID TreatmentID TreatmentDate

101 D01 T101 2023-10-26
101 D01 T102 2023-10-27
102 D02 T201 2023-10-26
103 D01 T301 2023-10-27
103 D01 T302 2023-10-28
103 D03 T303 2023-10-29

9.4 4. Third Normal Form (3NF)

To convert to 3NF, we need to eliminate transitive dependencies. A transitive dependency occurs when
a non-key attribute depends on another non-key attribute. In this case, Specialization depends on
DoctorID via DoctorName.

9.4.1 Doctor Table (Modified)

DoctorID DoctorName SpecializationID

D01 Dr. John Doe S01
D02 Dr. Jane Lee S02
D03 Dr. David Kim S03

9.4.2 Specialization Table

SpecializationID Specialization
S01 Cardiology
S02 Orthopedics
S03 Neurology

9.4.3 Patient Table (Same as 2NF)

PatientID PatientName
101 Alice Smith
102 Bob Johnson
103 Carol Williams

9
9.4.4 Treatment Table (Same as 2NF)

TreatmentID TreatmentName
T101 Angioplasty
T102 Medication
T201 Physiotherapy
T301 ECG
T302 Medication
T303 MRI

9.4.5 PatientTreatment Table (Same as 2NF)

PatientID DoctorID TreatmentID TreatmentDate

101 D01 T101 2023-10-26
101 D01 T102 2023-10-27
102 D02 T201 2023-10-26
103 D01 T301 2023-10-27
103 D01 T302 2023-10-28
103 D03 T303 2023-10-29

10 Library Management System Normalization

10.1 1. Unnormalized Form (UNF)

BookID BookTitle AuthorName Nationality MemberID MemberName LoanDate ReturnDate

B001 The Hobbit J.R.R. British M101 Alice John- 2023-10-26 2023-11-09
Tolkien son
B002 Pride and Jane British M102 Bob 2023-10-27 2023-11-10
Prejudice Austen Williams
B001 The Hobbit J.R.R. British M103 Carol 2023-10-28 2023-11-11
Tolkien Davis
B003 Dune Frank Her- American M101 Alice John- 2023-10-29 2023-11-12
bert son
B004 1984 George Or- British M102 Bob 2023-10-30 2023-11-13
well Williams

• Repeating Groups: A member can borrow multiple books, leading to repeated mem-
ber information.
• Data Redundancy: Book and author details are repeated across multiple rows.

• Potential Inconsistencies: If an author’s nationality changes, it would need to be

updated in multiple rows.

10.2 2. First Normal Form (1NF)

To convert to 1NF, we need to ensure each field contains atomic values and eliminate repeating groups.
This means each row should represent a single book-loan combination.

10
 BookID BookTitle AuthorName Nationality MemberID MemberName LoanDate ReturnDate
B001 The Hobbit J.R.R. British M101 Alice John- 2023-10-26 2023-11-09
Tolkien son
B002 Pride and Jane British M102 Bob 2023-10-27 2023-11-10
Prejudice Austen Williams
B001 The Hobbit J.R.R. British M103 Carol 2023-10-28 2023-11-11
Tolkien Davis
B003 Dune Frank Her- American M101 Alice John- 2023-10-29 2023-11-12
bert son
B004 1984 George Or- British M102 Bob 2023-10-30 2023-11-13
well Williams

10.3 3. Second Normal Form (2NF)

To convert to 2NF, we need to eliminate partial dependencies. This means creating separate tables for
books, members, and loans, and linking them using foreign keys.

10.3.1 Book Table

BookID BookTitle AuthorName Nationality

B001 The Hobbit J.R.R. Tolkien British
B002 Pride and Prej- Jane Austen British
udice
B003 Dune Frank Herbert American
B004 1984 George Orwell British

10.3.2 Member Table

MemberID MemberName
M101 Alice Johnson
M102 Bob Williams
M103 Carol Davis

10.3.3 Loan Table

BookID MemberID LoanDate ReturnDate

B001 M101 2023-10-26 2023-11-09
B002 M102 2023-10-27 2023-11-10
B001 M103 2023-10-28 2023-11-11
B003 M101 2023-10-29 2023-11-12
B004 M102 2023-10-30 2023-11-13

10.4 4. Third Normal Form (3NF)

To convert to 3NF, we need to eliminate transitive dependencies. In this case, AuthorNationality depends
on AuthorName.

10.4.1 Author Table

11
 AuthorName Nationality
J.R.R. Tolkien British
Jane Austen British
Frank Herbert American
George Orwell British

10.4.2 Book Table (Modified)

BookID BookTitle AuthorName

B001 The Hobbit J.R.R. Tolkien
B002 Pride and Prej- Jane Austen
udice
B003 Dune Frank Herbert
B004 1984 George Orwell

10.4.3 Member Table (Same as 2NF)

MemberID MemberName
M101 Alice Johnson
M102 Bob Williams
M103 Carol Davis

10.4.4 Loan Table (Same as 2NF)

BookID MemberID LoanDate ReturnDate

B001 M101 2023-10-26 2023-11-09
B002 M102 2023-10-27 2023-11-10
B001 M103 2023-10-28 2023-11-11
B003 M101 2023-10-29 2023-11-12
B004 M102 2023-10-30 2023-11-13

11 Employee Payroll System Normalization

11.1 1. Unnormalized Form (UNF)

EmployeeID Emp Name DepartID DeptName Salary TaxBracketID TaxRate TaxDeduction

E001 John Doe D101 Sales 60000 TB01 0.15 9000
E001 John Doe D102 Marketing 60000 TB01 0.15 9000
E002 Jane Smith D201 HR 75000 TB02 0.20 15000
E003 David Lee D101 Sales 50000 TB01 0.15 7500
E004 Emily D202 Finance 90000 TB03 0.25 22500
White
E004 Emily D102 Marketing 90000 TB03 0.25 22500
White

• Repeating Groups: Employees can belong to multiple departments, leading to repeated employee
and salary information.
• Data Redundancy: Tax bracket and tax deduction information is repeated for each employee-
department combination.

• Transitive Dependency: Tax deduction depends on the tax bracket via tax rate and salary,
creating unnecessary dependencies.

12
11.2 2. First Normal Form (1NF)
To convert to 1NF, we need to ensure each field contains atomic values and eliminate repeating groups.
This means each row should represent a single employee-department combination.

EmployeeID Emp Name Dept ID Dept Name Salary TaxBracketID TaxRate TaxDeduction
E001 John Doe D101 Sales 60000 TB01 0.15 9000
E001 John Doe D102 Marketing 60000 TB01 0.15 9000
E002 Jane Smith D201 HR 75000 TB02 0.20 15000
E003 David Lee D101 Sales 50000 TB01 0.15 7500
E004 Emily D202 Finance 90000 TB03 0.25 22500
White
E004 Emily D102 Marketing 90000 TB03 0.25 22500
White

11.3 3. Second Normal Form (2NF)

To convert to 2NF, we need to eliminate partial dependencies. This means creating separate tables for
employees, departments, and salary details, and linking them using foreign keys.

11.3.1 Employee Table

EmployeeID EmployeeName Salary TaxBracketID

E001 John Doe 60000 TB01
E002 Jane Smith 75000 TB02
E003 David Lee 50000 TB01
E004 Emily White 90000 TB03

11.3.2 Department Table

DepartmentID DepartmentName
D101 Sales
D102 Marketing
D201 HR
D202 Finance

11.3.3 EmployeeDepartment Table (Junction Table)

EmployeeID DepartmentID
E001 D101
E001 D102
E002 D201
E003 D101
E004 D202
E004 D102

11.3.4 TaxBracket Table

TaxBracketID TaxRate TaxDeduction

TB01 0.15 9000
TB02 0.20 15000
TB03 0.25 22500

13
11.4 4. Third Normal Form (3NF)
To convert to 3NF, we need to eliminate transitive dependencies. In this case, TaxDeduction depends on
TaxBracketID through TaxRate and Salary. to fully remove this transitive dependency, the taxDeduction
should be calculated when needed, not stored. However, if we need to store it, we would use the following
tables.

11.4.1 TaxBracket Table (Modified)

TaxBracketID TaxRate
TB01 0.15
TB02 0.20
TB03 0.25

11.4.2 Employee Table (Modified)

EmployeeID EmployeeName Salary TaxBracketID

E001 John Doe 60000 TB01
E002 Jane Smith 75000 TB02
E003 David Lee 50000 TB01
E004 Emily White 90000 TB03

11.4.3 Department Table (Same as 2NF)

DepartmentID DepartmentName
D101 Sales
D102 Marketing
D201 HR
D202 Finance

11.4.4 EmployeeDepartment Table (Same as 2NF)

EmployeeID DepartmentID
E001 D101
E001 D102
E002 D201
E003 D101
E004 D202
E004 D102

14