Functional Dependency Lesson Plan Using Flipped

Classroom Approach
Overview

The flipped classroom approach involves students learning new content at home and
applying that knowledge during class time. For a lesson on functional dependencies, this
approach ensures that students grasp the theoretical aspects beforehand and engage in
problem-solving and discussions in class.

Objectives

 Understand the concept of functional dependencies in databases.

 Identify functional dependencies in relational schemas.
 Apply the concept to normalize relational databases.

Pre-Class Preparation (Homework)

Video Lecture (15-20 minutes)

 Create or find a video that covers:

o Definition of functional dependency.
o Examples of functional dependencies.
o Importance of functional dependencies in database design.
o How to identify and use functional dependencies in normalization.

Reading Material

 Provide students with a textbook chapter or article on functional dependencies.

 Include real-world examples and case studies.

Quiz (10 questions)

 A short online quiz to assess understanding of the video and reading materials.
 Questions should cover definitions, identification, and examples of functional
dependencies.

In-Class Activities (60-90 minutes)

1. Review and Q&A (15 minutes)

 Begin with a quick review of the key concepts from the video and reading.
 Address any questions or confusion from the homework.

2. Group Activity: Identify Functional Dependencies (20 minutes)

  Divide students into small groups.
 Provide each group with a different relational schema.
 Task them with identifying all functional dependencies within their schema.
 Each group presents their findings to the class.

3. Class Discussion: Real-World Applications (15 minutes)

 Discuss how functional dependencies are used in real-world database design.

 Encourage students to share examples from their own experiences or readings.

4. Hands-On Activity: Normalization (30 minutes)

 Provide a set of unnormalized tables.

 In groups, students use identified functional dependencies to normalize the tables
to at least 3NF.
 Each group presents their normalized tables and explains their process.

5. Individual Exercise: Case Study Analysis (10 minutes)

 Give students a case study involving a database design problem.

 Ask them to identify functional dependencies and propose normalization steps.
 Discuss solutions as a class.

Post-Class Activities

Homework Assignment

 Provide a more complex set of tables to normalize as homework.

 Include questions that require explanation of the thought process behind
identifying functional dependencies and normalization steps.

Discussion Forum

 Set up an online discussion forum for students to post questions and discuss the
homework assignment.
 Encourage peer-to-peer interaction and support.

Follow-Up Quiz

 Conduct an online quiz a week later to reinforce learning and assess retention.

Assessment

Formative Assessment

 In-class activities and discussions.

  Group presentations and participation.
 Online quizzes before and after the class.

Summative Assessment

 Homework assignment on normalization.

 A final exam question on functional dependencies and normalization.

Resources

 Video lecture (created using tools like Screencast-O-Matic or YouTube).

 Textbook chapters or scholarly articles.
 Online quiz platform (e.g., Google Forms, Kahoot).
 Case studies and relational schemas for in-class activities.

Flipped Classroom Content on Functional Dependency

Video Lecture Script

Introduction: "Welcome to our lesson on functional dependencies. In this video, we will

explore what functional dependencies are, why they are important in database design, and
how to identify them in relational schemas."

Definition: "A functional dependency occurs when one attribute uniquely determines
another attribute within a relational database. For example, if we have a table of student
records, the student ID uniquely determines the student's name, date of birth, and
address."

Example: "Consider a table with columns for student ID, student name, and student
address. The student ID is a primary key, meaning it uniquely identifies each student.
Therefore, we can say that the student name and address are functionally dependent on
the student ID."

Importance: "Functional dependencies are crucial for ensuring data integrity and
avoiding redundancy in databases. They help us normalize databases, which means
organizing the tables to reduce redundancy and improve efficiency."

Identification: "To identify functional dependencies, look for relationships where one
attribute or a combination of attributes determines another attribute. For example, in a
sales database, an order ID might determine the customer ID, product ID, and order
date."
Normalization: "Using functional dependencies, we can normalize a database by
dividing tables into smaller, related tables. This process helps eliminate redundancy and
ensures data integrity. For instance, if we have a table with order details, we might
normalize it by creating separate tables for customers, products, and orders."

Conclusion: "Understanding functional dependencies is key to designing efficient and

reliable databases. In our next class, we will practice identifying functional dependencies
and using them to normalize tables. Make sure to complete the quiz and reading materials
before the class."

Reading Material Summary

Functional Dependencies:

 Definition and examples.

 Role in database design.
 How to identify functional dependencies.

Normalization:

 Process and importance.

 Steps to normalize a database.
 Examples of normalization from unnormalized form to 3NF.

Case Studies:

 Real-world examples of databases with identified functional dependencies.

 Discussion on how normalization improved database efficiency and integrity.

Pre-Class Quiz Sample Questions

1. What is a functional dependency?

2. Give an example of a functional dependency in a relational schema.
3. Why are functional dependencies important in database design?
4. How can you identify a functional dependency in a table?
5. What is normalization, and why is it important?
6. Describe the relationship between functional dependencies and normalization.
7. What does 1NF, 2NF, and 3NF stand for?
8. Give an example of a table in 1NF and how you would normalize it to 2NF.
9. What problems can arise if functional dependencies are not properly identified?
 10. How does normalization using functional dependencies improve database
efficiency?

By using this flipped classroom approach, students actively engage with the content
before class and spend valuable class time applying their knowledge through
collaborative activities and discussions.

4o
Normalization examples?
ChatGPT

Normalization Examples

Normalization is the process of organizing a database to reduce redundancy and improve

data integrity. Below are examples of normalization from an unnormalized form to 3NF
(Third Normal Form).

Unnormalized Form (UNF)

Consider a table storing order details in an unnormalized form:

OrderI CustomerNa CustomerAddr ProductI ProductNa Quantit Pric TotalPric

D me ess D me y e e
001 John Doe 123 Elm St P001 Widget A 2 $10 $20
001 John Doe 123 Elm St P002 Widget B 1 $15 $15
002 Jane Smith 456 Oak St P001 Widget A 3 $10 $30

Problems:

 Redundant data (CustomerName and CustomerAddress repeated for each order).

 Potential anomalies during insert, update, and delete operations.

First Normal Form (1NF)

In 1NF, we ensure that each column contains atomic (indivisible) values, and each entry
in a column is of the same type. The unnormalized table is already in 1NF.

OrderI CustomerNa CustomerAddr ProductI ProductNa Quantit Pric TotalPric

D me ess D me y e e
001 John Doe 123 Elm St P001 Widget A 2 $10 $20
001 John Doe 123 Elm St P002 Widget B 1 $15 $15
002 Jane Smith 456 Oak St P001 Widget A 3 $10 $30
Second Normal Form (2NF)

In 2NF, we eliminate partial dependencies; that is, no non-prime attribute should be

dependent on any proper subset of any candidate key.

To achieve 2NF, we need to separate the data into multiple tables. Here, OrderID and
ProductID together form the composite primary key.

1. Orders Table:

OrderID CustomerName CustomerAddress

001 John Doe 123 Elm St
002 Jane Smith 456 Oak St

2. OrderDetails Table:

OrderID ProductID Quantity Price TotalPrice

001 P001 2 $10 $20
001 P002 1 $15 $15
002 P001 3 $10 $30

3. Products Table:

ProductID ProductName
P001 Widget A
P002 Widget B

Third Normal Form (3NF)

In 3NF, we remove transitive dependencies; that is, no non-prime attribute should depend
on another non-prime attribute.

To achieve 3NF, we need to further decompose the tables if there are transitive
dependencies.

1. Customers Table:

CustomerID CustomerName CustomerAddress

C001 John Doe 123 Elm St
C002 Jane Smith 456 Oak St

2. Orders Table:

OrderID CustomerID
001 C001
OrderID CustomerID
002 C002

3. OrderDetails Table:

OrderID ProductID Quantity Price TotalPrice

001 P001 2 $10 $20
001 P002 1 $15 $15
002 P001 3 $10 $30

4. Products Table:

ProductID ProductName
P001 Widget A
P002 Widget B

Summary of Normalization Steps

1. UNF to 1NF:
o Ensure atomic values and consistent data types.
2. 1NF to 2NF:
o Remove partial dependencies by creating separate tables for entities (e.g.,
Orders, OrderDetails, Products).
3. 2NF to 3NF:
o Remove transitive dependencies by further decomposing tables to ensure
all non-prime attributes depend only on the primary key.

By following these steps, we achieve a normalized database that reduces redundancy,

improves data integrity, and enhances query performance.

4o
More normalization steps?
ChatGPT

Additional Normalization Steps: BCNF, 4NF, and 5NF

Beyond 3NF, databases can be further normalized to ensure even greater data integrity
and to handle more complex types of dependencies. These include Boyce-Codd Normal
Form (BCNF), Fourth Normal Form (4NF), and Fifth Normal Form (5NF).

Boyce-Codd Normal Form (BCNF)

BCNF is a stronger version of the 3NF. A table is in BCNF if it is in 3NF, and for every
one of its non-trivial functional dependencies X → Y, X is a super key.
Example:

Consider the following table:

CourseID Instructor Room

CS101 Dr. Smith Room 1
CS102 Dr. Jones Room 2
CS101 Dr. Smith Room 3

 Functional dependencies:
o (CourseID, Instructor) → Room
o Room → Instructor

The table is in 3NF but not in BCNF because Room is not a super key, yet it determines
Instructor. To convert it to BCNF, we split it:

1. CourseRoom Table:

CourseID Room
CS101 Room 1
CS102 Room 2
CS101 Room 3

2. RoomInstructor Table:

Room Instructor
Room 1 Dr. Smith
Room 2 Dr. Jones
Room 3 Dr. Smith

Fourth Normal Form (4NF)

A table is in 4NF if it is in BCNF and has no multi-valued dependencies, meaning that no

row should contain two or more independent and multivalued facts about an entity.

Example:

Consider a table storing information about projects and skills of employees:

EmployeeID Project Skill

E001 Project A Skill X
E001 Project A Skill Y
E001 Project B Skill X
  Multi-valued dependencies:
o EmployeeID →→ Project
o EmployeeID →→ Skill

To achieve 4NF, we split the table:

1. EmployeeProjects Table:

EmployeeID Project
E001 Project A
E001 Project B

2. EmployeeSkills Table:

EmployeeID Skill
E001 Skill X
E001 Skill Y

Fifth Normal Form (5NF)

A table is in 5NF if it is in 4NF and cannot be decomposed into any number of smaller
tables without loss of data. It deals with cases where information can be reconstructed
from smaller pieces but not directly from the original table.

Example:

Consider a table capturing contracts involving suppliers, parts, and projects:

SupplierID PartID ProjectID

S001 P001 PR001
S001 P002 PR001
S002 P001 PR002

To decompose it into 5NF, we ensure no join dependency is present:

1. SupplierParts Table:

SupplierID PartID
S001 P001
S001 P002
S002 P001

2. SupplierProjects Table:
SupplierID ProjectID
S001 PR001
S002 PR002

3. PartProjects Table:

PartID ProjectID
P001 PR001
P002 PR001
P001 PR002

Summary of Higher Normalization Steps

1. BCNF (Boyce-Codd Normal Form):

o Ensure every determinant is a super key.
2. 4NF (Fourth Normal Form):
o Remove multi-valued dependencies by splitting into multiple tables.
3. 5NF (Fifth Normal Form):
o Ensure no join dependency exists by decomposing tables further without
loss of data.

By following these additional steps, we ensure that the database design is robust, with
minimized redundancy and enhanced integrity even in complex s

More Examples of Boyce-Codd Normal Form (BCNF)

To further understand BCNF, let's consider a few more examples where a table is in 3NF
but not in BCNF, and see how it can be decomposed into BCNF.

Example 1: University Courses

Consider the following table:

CourseID Instructor Department

CS101 Dr. Smith Computer Science
CS102 Dr. Jones Computer Science
MATH101 Dr. Brown Mathematics

Functional Dependencies:

 CourseID → Instructor
 Instructor → Department

Problem:
  The table is in 3NF because each non-key attribute (Instructor, Department) is
fully dependent on the primary key (CourseID), and there are no transitive
dependencies.
 However, it is not in BCNF because Instructor determines Department, but
Instructor is not a super key.

Decomposition into BCNF:

1. Courses Table:

CourseID Instructor
CS101 Dr. Smith
CS102 Dr. Jones
MATH101 Dr. Brown

2. InstructorDepartment Table:

Instructor Department
Dr. Smith Computer Science
Dr. Jones Computer Science
Dr. Brown Mathematics

Example 2: Employee Projects

Consider the following table:

EmployeeID ProjectID ProjectManager

E001 P001 M001
E002 P002 M002
E001 P002 M002

Functional Dependencies:

 EmployeeID, ProjectID → ProjectManager

 ProjectID → ProjectManager

Problem:

 The table is in 3NF because each non-key attribute (ProjectManager) is fully

dependent on the primary key (EmployeeID, ProjectID), and there are no
transitive dependencies.
 However, it is not in BCNF because ProjectID determines ProjectManager, but
ProjectID is not a super key.

Decomposition into BCNF:

 1. EmployeeProjects Table:

EmployeeID ProjectID
E001 P001
E002 P002
E001 P002

2. ProjectManagers Table:

ProjectID ProjectManager
P001 M001
P002 M002

Example 3: Student Enrollments

Consider the following table:

StudentID CourseID Instructor

S001 CS101 Dr. Smith
S002 CS101 Dr. Smith
S003 MATH101 Dr. Brown

Functional Dependencies:

 StudentID, CourseID → Instructor

 CourseID → Instructor

Problem:

 The table is in 3NF because each non-key attribute (Instructor) is fully dependent
on the primary key (StudentID, CourseID), and there are no transitive
dependencies.
 However, it is not in BCNF because CourseID determines Instructor, but
CourseID is not a super key.

Decomposition into BCNF:

1. StudentCourses Table:

StudentID CourseID
S001 CS101
S002 CS101
S003 MATH101

2. CourseInstructors Table:
CourseID Instructor
CS101 Dr. Smith
MATH101 Dr. Brown

Key Points for BCNF Decomposition

1. Identify Functional Dependencies:

o Determine all functional dependencies in the table.
o Identify if there is any dependency where the determinant is not a super
key.
2. Check for BCNF Violation:
o If any determinant is not a super key, the table violates BCNF.
3. Decompose the Table:
o Split the table into two or more tables to eliminate the BCNF violation.
o Ensure that each table is now in BCNF, meaning every determinant is a
super key.

More Cases for Boyce-Codd Normal Form (BCNF)

Example 4: Employee Skills

Consider the following table:

EmployeeID Skill Department

E001 Java IT
E002 Python IT
E003 Excel HR
E001 Python IT

Functional Dependencies:

 EmployeeID, Skill → Department

 Skill → Department

Problem:
  The table is in 3NF because each non-key attribute (Department) is fully
dependent on the primary key (EmployeeID, Skill), and there are no transitive
dependencies.
 However, it is not in BCNF because Skill determines Department, but Skill is not
a super key.

Decomposition into BCNF:

1. EmployeeSkills Table:

EmployeeID Skill
E001 Java
E002 Python
E003 Excel
E001 Python

2. SkillDepartments Table:

Skill Department
Java IT
Python IT
Excel HR

Example 5: Supplier Products

Consider the following table:

SupplierID ProductID Region

S001 P001 North
S001 P002 North
S002 P001 South
S002 P003 South

Functional Dependencies:

 SupplierID, ProductID → Region

 ProductID → Region

Problem:

 The table is in 3NF because each non-key attribute (Region) is fully dependent on
the primary key (SupplierID, ProductID), and there are no transitive
dependencies.
 However, it is not in BCNF because ProductID determines Region, but ProductID
is not a super key.
Decomposition into BCNF:

1. SupplierProducts Table:

SupplierID ProductID
S001 P001
S001 P002
S002 P001
S002 P003

2. ProductRegions Table:

ProductID Region
P001 North
P002 North
P003 South

Example 6: Course Enrollment

Consider the following table:

StudentID CourseID InstructorID

S001 C101 I001
S002 C102 I002
S001 C102 I002
S003 C101 I001

Functional Dependencies:

 StudentID, CourseID → InstructorID

 CourseID → InstructorID

Problem:

 The table is in 3NF because each non-key attribute (InstructorID) is fully

dependent on the primary key (StudentID, CourseID), and there are no transitive
dependencies.
 However, it is not in BCNF because CourseID determines InstructorID, but
CourseID is not a super key.

Decomposition into BCNF:

1. StudentCourses Table:
StudentID CourseID
S001 C101
S002 C102
S001 C102
S003 C101

2. CourseInstructors Table:

CourseID InstructorID
C101 I001
C102 I002

Example 7: Room Scheduling

Consider the following table:

RoomID TimeSlot Instructor

R001 9-10AM Dr. Smith
R002 10-11AM Dr. Jones
R001 10-11AM Dr. Smith
R002 11-12PM Dr. Brown

Functional Dependencies:

 RoomID, TimeSlot → Instructor

 TimeSlot → Instructor

Problem:

 The table is in 3NF because each non-key attribute (Instructor) is fully dependent
on the primary key (RoomID, TimeSlot), and there are no transitive dependencies.
 However, it is not in BCNF because TimeSlot determines Instructor, but TimeSlot
is not a super key.

Decomposition into BCNF:

1. RoomTimeSlots Table:

RoomID TimeSlot
R001 9-10AM
R002 10-11AM
R001 10-11AM
R002 11-12PM
 2. TimeSlotInstructors Table:

TimeSlot Instructor
9-10AM Dr. Smith
10-11AM Dr. Jones
10-11AM Dr. Smith
11-12PM Dr. Brown

Key Points for BCNF Decomposition

1. Identify Functional Dependencies:

o Determine all functional dependencies in the table.
o Identify if there is any dependency where the determinant is not a super
key.
2. Check for BCNF Violation:
o If any determinant is not a super key, the table violates BCNF.
3. Decompose the Table:
o Split the table into two or more tables to eliminate the BCNF violation.
o Ensure that each table is now in BCNF, meaning every determinant is a
super key.

By analyzing these examples, you can see how to handle situations where tables are in
3NF but not in BCNF, and how to properly decompose them to achieve BCNF. This
ensures a robust database design that avoids redundancy and maintains data integrity.

More Examples of Fourth Normal Form (4NF)

Fourth Normal Form (4NF) deals with multi-valued dependencies, where a non-key
attribute depends on another non-key attribute independently of the primary key. A table
is in 4NF if it is in BCNF and contains no multi-valued dependencies.

Example 1: Employee Skills and Projects

Consider the following table:

EmployeeID Skill Project

E001 Java Project A
E001 Python Project A
E001 Java Project B
E002 Python Project B

Multi-Valued Dependencies:

 EmployeeID →→ Skill
 EmployeeID →→ Project
Problem:

 Each employee can have multiple skills and be involved in multiple projects
independently.

Decomposition into 4NF:

1. EmployeeSkills Table:

EmployeeID Skill
E001 Java
E001 Python
E002 Python

2. EmployeeProjects Table:

EmployeeID Project
E001 Project A
E001 Project B
E002 Project B

Example 2: Student Courses and Activities

Consider the following table:

StudentID Course Activity

S001 Math Chess Club
S001 Science Chess Club
S001 Math Debate Team
S002 Science Debate Team

Multi-Valued Dependencies:

 StudentID →→ Course
 StudentID →→ Activity

Problem:

 Each student can enroll in multiple courses and participate in multiple activities
independently.

Decomposition into 4NF:

1. StudentCourses Table:
StudentID Course
S001 Math
S001 Science
S002 Science

2. StudentActivities Table:

StudentID Activity
S001 Chess Club
S001 Debate Team
S002 Debate Team

Example 3: Product Suppliers and Warehouses

Consider the following table:

ProductID Supplier Warehouse

P001 Supplier A Warehouse 1
P001 Supplier B Warehouse 1
P001 Supplier A Warehouse 2
P002 Supplier B Warehouse 2

Multi-Valued Dependencies:

 ProductID →→ Supplier
 ProductID →→ Warehouse

Problem:

 Each product can be supplied by multiple suppliers and stored in multiple

warehouses independently.

Decomposition into 4NF:

1. ProductSuppliers Table:

ProductID Supplier
P001 Supplier A
P001 Supplier B
P002 Supplier B

2. ProductWarehouses Table:
ProductID Warehouse
P001 Warehouse 1
P001 Warehouse 2
P002 Warehouse 2

Example 4: Author Books and Awards

Consider the following table:

AuthorID BookTitle Award

A001 Book A Award 1
A001 Book B Award 1
A001 Book A Award 2
A002 Book C Award 2

Multi-Valued Dependencies:

 AuthorID →→ BookTitle
 AuthorID →→ Award

Problem:

 Each author can write multiple books and win multiple awards independently.

Decomposition into 4NF:

1. AuthorBooks Table:

AuthorID BookTitle
A001 Book A
A001 Book B
A002 Book C

2. AuthorAwards Table:

AuthorID Award
A001 Award 1
A001 Award 2
A002 Award 2

Example 5: Customer Purchases and Preferences

Consider the following table:

CustomerID Product Preference
C001 Product A Preference 1
C001 Product B Preference 1
C001 Product A Preference 2
C002 Product B Preference 2

Multi-Valued Dependencies:

 CustomerID →→ Product
 CustomerID →→ Preference

Problem:

 Each customer can buy multiple products and have multiple preferences
independently.

Decomposition into 4NF:

1. CustomerProducts Table:

CustomerID Product
C001 Product A
C001 Product B
C002 Product B

2. CustomerPreferences Table:

CustomerID Preference
C001 Preference 1
C001 Preference 2
C002 Preference 2

Key Points for 4NF Decomposition

1. Identify Multi-Valued Dependencies:

o Determine if there are any multi-valued dependencies where one attribute
depends on another non-key attribute independently of the primary key.
2. Check for 4NF Violation:
o If any non-key attribute is multi-valued and depends on another non-key
attribute independently, the table violates 4NF.
3. Decompose the Table:
o Split the table into two or more tables to eliminate the multi-valued
dependency.
o Ensure that each table now contains no multi-valued dependencies and is
in 4NF.
By analyzing these additional examples, you can see how to handle multi-valued
dependencies and properly decompose tables to achieve 4NF, ensuring a well-structured
and efficient database design.

4o

More Examples of Fifth Normal Form (5NF)

Fifth Normal Form (5NF), also known as Project-Join Normal Form (PJNF), addresses
issues where data redundancy arises due to join dependencies. A table is in 5NF if it is in
4NF and cannot be decomposed into any number of smaller tables without loss of data.

Example 1: Publisher-Author-Book

Consider the following table:

PublisherID AuthorID BookID

P001 A001 B001
P001 A002 B001
P002 A001 B002
P002 A003 B003

Join Dependencies:

 PublisherID + AuthorID + BookID

Problem:

 Each publisher can publish multiple books, and each book can have multiple
authors.

Decomposition into 5NF:

1. PublisherBooks Table:

PublisherID BookID
P001 B001
P002 B002
P002 B003

2. AuthorBooks Table:

AuthorID BookID
A001 B001
A002 B001
AuthorID BookID
A001 B002
A003 B003

3. PublisherAuthors Table:

PublisherID AuthorID
P001 A001
P001 A002
P002 A001
P002 A003

Example 2: Course-Teacher-Student

Consider the following table:

CourseID TeacherID StudentID

C001 T001 S001
C001 T002 S001
C002 T001 S002
C002 T003 S003

Join Dependencies:

 CourseID + TeacherID + StudentID

Problem:

 Each course can be taught by multiple teachers, and each teacher can have
multiple students.

Decomposition into 5NF:

1. CourseTeachers Table:

CourseID TeacherID
C001 T001
C001 T002
C002 T001
C002 T003

2. TeacherStudents Table:
TeacherID StudentID
T001 S001
T002 S001
T001 S002
T003 S003

3. CourseStudents Table:

CourseID StudentID
C001 S001
C002 S002
C002 S003

Example 3: Department-Project-Employee

Consider the following table:

DepartmentID ProjectID EmployeeID

D001 P001 E001
D001 P002 E001
D002 P001 E002
D002 P003 E003

Join Dependencies:

 DepartmentID + ProjectID + EmployeeID

Problem:

 Each department can handle multiple projects, and each project can have multiple
employees.

Decomposition into 5NF:

1. DepartmentProjects Table:

DepartmentID ProjectID
D001 P001
D001 P002
D002 P001
D002 P003

2. ProjectEmployees Table:
ProjectID EmployeeID
P001 E001
P002 E001
P001 E002
P003 E003

3. DepartmentEmployees Table:

DepartmentID EmployeeID
D001 E001
D002 E002
D002 E003

Example 4: Vendor-Product-Region

Consider the following table:

VendorID ProductID RegionID

V001 P001 R001
V001 P002 R001
V002 P001 R002
V002 P003 R002

Join Dependencies:

 VendorID + ProductID + RegionID

Problem:

 Each vendor can sell multiple products, and each product can be sold in multiple
regions.

Decomposition into 5NF:

1. VendorProducts Table:

VendorID ProductID
V001 P001
V001 P002
V002 P001
V002 P003

2. ProductRegions Table:
ProductID RegionID
P001 R001
P002 R001
P001 R002
P003 R002

3. VendorRegions Table:

VendorID RegionID
V001 R001
V002 R002

Example 5: Airline-Flight-Crew

Consider the following table:

AirlineID FlightID CrewID

A001 F001 C001
A001 F002 C001
A002 F001 C002
A002 F003 C003

Join Dependencies:

 AirlineID + FlightID + CrewID

Problem:

 Each airline can have multiple flights, and each flight can have multiple crew
members.

Decomposition into 5NF:

1. AirlineFlights Table:

AirlineID FlightID
A001 F001
A001 F002
A002 F001
A002 F003

2. FlightCrews Table:
FlightID CrewID
F001 C001
F002 C001
F001 C002
F003 C003

3. AirlineCrews Table:

AirlineID CrewID
A001 C001
A002 C002
A002 C003

Key Points for 5NF Decomposition

1. Identify Join Dependencies:

o Determine if there are any join dependencies where the table can be
reconstructed from smaller tables.
2. Check for 5NF Violation:
o If any join dependency exists that allows the table to be decomposed into
smaller tables without loss of data, the table violates 5NF.
3. Decompose the Table:
o Split the table into multiple tables that capture the join dependencies.
o Ensure that each table is now in 5NF, meaning it cannot be decomposed
further without loss of data.

By analyzing these additional examples, you can see how to handle join dependencies
and properly decompose tables to achieve 5NF, ensuring a highly normalized and
efficient database design.
Examples of Sixth Normal Form (6NF)

Sixth Normal Form (6NF) deals with temporal data and ensures that a table is
decomposed to the point where each constraint only involves one relationship between
key and non-key attributes. This form is relevant in temporal databases where the validity
of data is dependent on time. A table is in 6NF if it is in 5NF and all non-trivial join
dependencies are trivial.

Example 1: Employee Contract History

Consider the following table:

EmployeeID ContractID StartDate EndDate

E001 C001 2023-01-01 2023-06-30
E001 C002 2023-07-01 2023-12-31
E002 C001 2023-01-01 2023-06-30
E002 C003 2023-07-01 2023-12-31

Problem:

 We need to track employee contract history over time.

Decomposition into 6NF:

1. EmployeeContractStart Table:

EmployeeID ContractID StartDate

E001 C001 2023-01-01
E001 C002 2023-07-01
E002 C001 2023-01-01
E002 C003 2023-07-01

2. EmployeeContractEnd Table:

EmployeeID ContractID EndDate

E001 C001 2023-06-30
E001 C002 2023-12-31
E002 C001 2023-06-30
E002 C003 2023-12-31

Example 2: Product Price Changes

Consider the following table:

ProductID Price StartDate EndDate
P001 100 2023-01-01 2023-06-30
P001 120 2023-07-01 2023-12-31
P002 200 2023-01-01 2023-06-30
P002 180 2023-07-01 2023-12-31

Problem:

 We need to track price changes of products over time.

Decomposition into 6NF:

1. ProductPriceStart Table:

ProductID Price StartDate

P001 100 2023-01-01
P001 120 2023-07-01
P002 200 2023-01-01
P002 180 2023-07-01

2. ProductPriceEnd Table:

ProductID Price EndDate

P001 100 2023-06-30
P001 120 2023-12-31
P002 200 2023-06-30
P002 180 2023-12-31

Example 3: Room Booking Schedule

Consider the following table:

RoomID BookingID StartTime EndTime

R001 B001 2023-07-30 09:00:00 2023-07-30 11:00:00
R001 B002 2023-07-30 12:00:00 2023-07-30 14:00:00
R002 B003 2023-07-30 09:00:00 2023-07-30 11:00:00
R002 B004 2023-07-30 12:00:00 2023-07-30 14:00:00

Problem:

 We need to track room booking schedules with start and end times.

Decomposition into 6NF:

 1. RoomBookingStart Table:

RoomID BookingID StartTime

R001 B001 2023-07-30 09:00:00
R001 B002 2023-07-30 12:00:00
R002 B003 2023-07-30 09:00:00
R002 B004 2023-07-30 12:00:00

2. RoomBookingEnd Table:

RoomID BookingID EndTime

R001 B001 2023-07-30 11:00:00
R001 B002 2023-07-30 14:00:00
R002 B003 2023-07-30 11:00:00
R002 B004 2023-07-30 14:00:00

Example 4: Employee Role History

Consider the following table:

EmployeeID RoleID StartDate EndDate

E001 R001 2022-01-01 2022-12-31
E001 R002 2023-01-01 2023-06-30
E002 R001 2022-01-01 2022-12-31
E002 R003 2023-01-01 2023-06-30

Problem:

 We need to track employee role history over time.

Decomposition into 6NF:

1. EmployeeRoleStart Table:

EmployeeID RoleID StartDate

E001 R001 2022-01-01
E001 R002 2023-01-01
E002 R001 2022-01-01
E002 R003 2023-01-01

2. EmployeeRoleEnd Table:

EmployeeID RoleID EndDate

E001 R001 2022-12-31
EmployeeID RoleID EndDate
E001 R002 2023-06-30
E002 R001 2022-12-31
E002 R003 2023-06-30

Example 5: Product Warranty Period

Consider the following table:

ProductID WarrantyID StartDate EndDate

P001 W001 2023-01-01 2023-12-31
P001 W002 2024-01-01 2024-12-31
P002 W001 2023-01-01 2023-12-31
P002 W003 2024-01-01 2024-12-31

Problem:

 We need to track product warranty periods over time.

Decomposition into 6NF:

1. ProductWarrantyStart Table:

ProductID WarrantyID StartDate

P001 W001 2023-01-01
P001 W002 2024-01-01
P002 W001 2023-01-01
P002 W003 2024-01-01

2. ProductWarrantyEnd Table:

ProductID WarrantyID EndDate

P001 W001 2023-12-31
P001 W002 2024-12-31
P002 W001 2023-12-31
P002 W003 2024-12-31

Key Points for 6NF Decomposition

1. Identify Temporal Dependencies:

o Determine if there are any temporal dependencies where data validity is
dependent on time.
2. Check for 6NF Violation:
 oIf any non-key attribute depends on another attribute with a temporal
element, the table may violate 6NF.
3. Decompose the Table:
o Split the table into smaller tables that capture the temporal dependencies.
o Ensure
Temporal Database Examples

Temporal databases are used to manage data involving time aspects, such as valid time
and transaction time. These databases can track the history of data changes and handle
time-based queries. Here are some examples illustrating the use of temporal databases.

Example 1: Employee Salary History

A temporal database can store the salary history of employees over time.

Schema:

1. Employee Table:

EmployeeID Name
E001 Alice
E002 Bob

2. EmployeeSalary Table (with valid time):

EmployeeID Salary StartDate EndDate

E001 50000 2020-01-01 2020-12-31
E001 55000 2021-01-01 2021-12-31
E002 60000 2020-01-01 2020-12-31
E002 65000 2021-01-01 2021-12-31

Query Examples:

 Find the current salary of all employees.

sql
Copy code
SELECT EmployeeID, Salary
FROM EmployeeSalary
WHERE EndDate = '9999-12-31';

 Find the salary of employee E001 as of March 2021.

sql
Copy code
SELECT Salary
FROM EmployeeSalary
WHERE EmployeeID = 'E001'
AND '2021-03-01' BETWEEN StartDate AND EndDate;

Example 2: Product Price History

A temporal database can track the price changes of products over time.

Schema:

1. Product Table:

ProductID ProductName
P001 Widget A
P002 Widget B

2. ProductPrice Table (with valid time):

ProductID Price StartDate EndDate

P001 100 2020-01-01 2020-06-30
P001 120 2020-07-01 2020-12-31
P002 200 2020-01-01 2020-06-30
P002 180 2020-07-01 2020-12-31

Query Examples:

 Find the current price of all products.

sql
Copy code
SELECT ProductID, Price
FROM ProductPrice
WHERE EndDate = '9999-12-31';

 Find the price of product P001 on May 2020.

sql
Copy code
SELECT Price
FROM ProductPrice
WHERE ProductID = 'P001'
AND '2020-05-01' BETWEEN StartDate AND EndDate;

Example 3: Room Booking Schedule

A temporal database can manage the booking history of rooms.

Schema:

1. Room Table:

RoomID RoomName
R001 Conference Room 1
RoomID RoomName
R002 Conference Room 2

2. RoomBooking Table (with valid time):

RoomID BookingID StartDate EndDate

R001 B001 2023-07-30 09:00:00 2023-07-30 11:00:00
R001 B002 2023-07-30 12:00:00 2023-07-30 14:00:00
R002 B003 2023-07-30 09:00:00 2023-07-30 11:00:00
R002 B004 2023-07-30 12:00:00 2023-07-30 14:00:00

Query Examples:

 Find the current bookings of all rooms.

sql
Copy code
SELECT RoomID, BookingID
FROM RoomBooking
WHERE EndDate > CURRENT_TIMESTAMP;

 Find the bookings for room R001 on July 30, 2023.

sql
Copy code
SELECT BookingID
FROM RoomBooking
WHERE RoomID = 'R001'
AND '2023-07-30' BETWEEN DATE(StartDate) AND DATE(EndDate);

Example 4: Customer Membership History

A temporal database can track the membership history of customers over time.

Schema:

1. Customer Table:

CustomerID Name
C001 John Doe
C002 Jane Smith

2. Membership Table (with valid time):

CustomerID MembershipType StartDate EndDate

C001 Silver 2020-01-01 2020-12-31
C001 Gold 2021-01-01 2021-12-31
CustomerID MembershipType StartDate EndDate
C002 Silver 2020-01-01 2020-12-31
C002 Platinum 2021-01-01 2021-12-31

Query Examples:

 Find the current membership type of all customers.

sql
Copy code
SELECT CustomerID, MembershipType
FROM Membership
WHERE EndDate = '9999-12-31';

 Find the membership type of customer C001 on June 2021.

sql
Copy code
SELECT MembershipType
FROM Membership
WHERE CustomerID = 'C001'
AND '2021-06-01' BETWEEN StartDate AND EndDate;

Example 5: Product Availability History

A temporal database can manage the availability history of products over time.

Schema:

1. Product Table:

ProductID ProductName
P001 Widget A
P002 Widget B

2. ProductAvailability Table (with valid time):

ProductID Available StartDate EndDate

P001 Yes 2020-01-01 2020-06-30
P001 No 2020-07-01 2020-12-31
P002 Yes 2020-01-01 2020-06-30
P002 Yes 2020-07-01 2020-12-31

Query Examples:

 Find the current availability status of all products.

sql
Copy code
SELECT ProductID, Available
FROM ProductAvailability
WHERE EndDate = '9999-12-31';

 Find the availability status of product P001 on August 2020.

sql
Copy code
SELECT Available
FROM ProductAvailability
WHERE ProductID = 'P001'
AND '2020-08-01' BETWEEN StartDate AND EndDate;

Key Points for Temporal Database Design

1. Valid Time:
o This tracks the period during which a fact is true in the real world. Tables
will have StartDate and EndDate columns.
2. Transaction Time:
o This tracks the period during which a fact is stored in the database. Tables
will have TransactionStart and TransactionEnd columns.
3. Temporal Queries:
o Use temporal operators and constructs in SQL (e.g., BETWEEN,
CURRENT_TIMESTAMP) to handle time-based queries effectively.
4. Normalization:
o Ensure that the temporal aspects are normalized properly to avoid
redundancy and maintain data integrity.

By using temporal tables and querying them appropriately, you can effectively manage
and analyze time-based data, providing valuable insights into historical trends and future
predictions.
Denormalization is the process of deliberately introducing redundancy into a database
schema by merging tables or adding duplicate data. This can be done to optimize
performance, especially in read-heavy environments. Here are the key benefits of
denormalization:

Benefits of Denormalization

1. Improved Query Performance:

o Fewer Joins: By denormalizing, you reduce the number of joins needed to
retrieve data. This can speed up queries that would otherwise require
multiple table lookups.
o Faster Read Operations: Aggregated or pre-computed data can reduce
the need for complex calculations during query time, leading to faster read
operations.
2. Simplified Query Design:
o Simpler Queries: With denormalized tables, queries often become
simpler since the necessary data is available in fewer tables. This can
make it easier to write and maintain queries.
o Reduced Complexity: Querying a denormalized database can be less
complex compared to querying a highly normalized database with
multiple tables and relationships.
3. Enhanced Performance for Reporting and Analytics:
o Optimized for Reporting: Denormalized tables are often used in data
warehouses and OLAP systems where reporting and analytical
performance is crucial. Aggregated data can be accessed more quickly,
enhancing reporting performance.
o Pre-computed Aggregates: Denormalization can include pre-computed
aggregate values, which speeds up analytical queries that would otherwise
need to compute these values on the fly.
4. Reduced Database Overhead:
o Fewer Transactions: Since fewer tables are involved, the overhead
associated with managing transactions and maintaining referential
integrity can be reduced.
o Less Schema Management: Managing fewer tables and relationships can
reduce the complexity of schema management and maintenance.
5. Optimized for Read-heavy Workloads:
o Efficient Reads: In environments where read operations significantly
outweigh write operations, denormalization can provide significant
performance benefits. This is common in applications such as reporting
dashboards and data warehousing.
6. Reduced Latency in High-Volume Systems:
o Faster Access: For systems that experience high-volume traffic,
denormalization can reduce latency by minimizing the need for complex
joins and lookups, thus speeding up data retrieval.
Example of Denormalization

Normalized Schema:

1. Orders Table:

OrderID CustomerID OrderDate

1001 C001 2024-01-01
1002 C002 2024-01-02

2. Customers Table:

CustomerID CustomerName
C001 John Doe
C002 Jane Smith

3. OrderItems Table:

OrderID ProductID Quantity

1001 P001 2
1001 P002 1
1002 P003 5

Denormalized Schema:

1. OrdersDenormalized Table:

OrderID CustomerName OrderDate ProductID Quantity

1001 John Doe 2024-01-01 P001 2
1001 John Doe 2024-01-01 P002 1
1002 Jane Smith 2024-01-02 P003 5

Benefits Demonstrated:

 Improved Query Performance: Queries to get all order details along with
customer names can be executed faster because all relevant data is in a single
table.
 Simplified Queries: There’s no need to perform joins between orders, customers,
and order items tables. Queries are simpler and more straightforward.
 Reduced Latency: Accessing data for reports or dashboards is faster since there
are fewer joins and aggregations required.

Trade-offs
While denormalization provides these benefits, it comes with trade-offs:

 Increased Redundancy: Duplicate data can lead to increased storage

requirements and potential data inconsistency if not managed properly.
 Update Anomalies: Changes in data need to be updated in multiple places, which
can increase the risk of inconsistencies.
 Complex Maintenance: Managing and ensuring data consistency in
denormalized databases can be more complex, particularly when updates or
deletions occur.

In summary, denormalization can significantly enhance performance and simplify query

design in certain scenarios, especially for read-heavy applications and reporting systems.
However, it should be carefully balanced with the need for data consistency and
manageability.
Denormalization vs. Normalization

Normalization and denormalization are two contrasting approaches to database design,

each with its benefits and trade-offs. Here’s a detailed comparison:

Normalization

Definition: Normalization is the process of organizing data in a database to minimize

redundancy and improve data integrity. It involves dividing a database into two or more
tables and defining relationships between them.

Objectives:

 Eliminate Redundancy: Reduce the duplication of data across the database.

 Ensure Data Integrity: Maintain consistency and accuracy of data.
 Reduce Anomalies: Prevent anomalies such as update, insertion, and deletion
anomalies.

Benefits:

1. Data Integrity:
o Ensures consistency and accuracy through well-defined relationships and
constraints.
2. Reduced Redundancy:
o Minimizes data duplication, which can save storage and reduce update
anomalies.
3. Flexibility:
o Makes it easier to update, insert, and delete records without affecting other
records.

Drawbacks:

1. Complex Queries:
o Often requires multiple joins to retrieve related data, which can complicate
queries and impact performance.
2. Performance Overhead:
o Joins and data retrieval operations can be slower due to the need for
complex query processing.
3. Higher Complexity:
o The schema can become complex with many tables and relationships,
making it harder to manage.

Normal Forms (NF):

  1NF (First Normal Form): Ensures that each column contains atomic values and
each record is unique.
 2NF (Second Normal Form): Achieves 1NF and removes partial dependencies;
all non-key attributes are fully functionally dependent on the entire primary key.
 3NF (Third Normal Form): Achieves 2NF and removes transitive dependencies;
non-key attributes depend only on the primary key.
 BCNF (Boyce-Codd Normal Form): A stronger version of 3NF; every
determinant is a candidate key.
 4NF (Fourth Normal Form): Handles multi-valued dependencies; ensures that a
record doesn’t have more than one independent multi-valued dependency.
 5NF (Fifth Normal Form): Ensures that every join dependency is implied by
candidate keys.
 6NF (Sixth Normal Form): Deals with temporal data and ensures that each non-
key attribute is dependent on a single relationship over time.

Denormalization

Definition: Denormalization is the process of deliberately introducing redundancy into a

database by merging tables or including duplicate data. This is done to optimize
performance, particularly in read-heavy environments.

Objectives:

 Improve Query Performance: Reduce the need for complex joins and
aggregations.
 Simplify Query Design: Make queries simpler and more efficient by having all
necessary data in fewer tables.
 Enhance Performance for Reporting: Optimize for systems where reporting
and analytics are crucial.

Benefits:

1. Improved Read Performance:

o Reduces the need for multiple joins, speeding up query execution times.
2. Simplified Queries:
o Easier to write and maintain queries because all relevant data is available
in a single table.
3. Optimized for Reporting and Analytics:
o Pre-computed or aggregated data can improve performance for analytical
and reporting tasks.

Drawbacks:

1. Increased Redundancy:
 oData duplication can lead to increased storage requirements and potential
inconsistencies.
2. Update Anomalies:
o Changes need to be made in multiple places, increasing the risk of data
anomalies.
3. Complex Maintenance:
o Ensuring data consistency across denormalized tables can be more
challenging.

Typical Scenarios for Denormalization:

 Data Warehousing: Where large amounts of data are aggregated for reporting
and analysis.
 Read-heavy Systems: Applications where read operations are significantly more
frequent than write operations.
 Performance Optimization: Systems that need to optimize for specific
performance metrics, such as query response time.

Comparison

Aspect Normalization Denormalization

Minimize redundancy and Improve performance and simplify
Purpose
maintain data integrity. queries.
Data Minimal, achieved through Increased, achieved through
Redundancy splitting tables. merging tables.
Query Often complex due to multiple Simpler due to fewer tables and less
Complexity joins. joining.
Can suffer from slow query
Performance Generally faster read performance.
performance due to joins.
High, due to reduced duplication Lower, due to potential data
Data Integrity
and constraints. duplication.
Schema Can be complex with many tables
Often simpler with fewer tables.
Complexity and relationships.
Easier to manage data More complex due to the need to
Maintenance
consistency. maintain redundancy.

When to Use Each

 Normalization: Best for transactional systems (OLTP) where data integrity and
minimizing redundancy are critical. It suits systems with frequent updates, inserts,
and deletes.
  Denormalization: Best for analytical systems (OLAP) and reporting applications
where read performance is prioritized. It suits systems with complex queries or
reporting needs and high read-to-write ratios.

Both normalization and denormalization have their places in database design. The choice
between them depends on the specific requirements of the application, including
performance needs, data integrity requirements, and the nature of the operations
performed.