Subject: DBMS

Topic: normalization

Introduction to Normalization
Definition of normalization, its purpose in database design, and the benefits of a normalized database (reducing data
redundancy, improving data integrity).

1. Introduction
Definition Normalization is a systematic process of organizing the columns and tables of a relational database to
minimize data redundancy and improve data integrity. It involves dividing large tables into smaller, related tables and
defining relationships between them. The primary goal is to ensure that each piece of data is stored in only one place,
thereby reducing anomalies and improving database efficiency.

Why it is needed (real-life analogy if possible) Normalization is crucial to address various issues that arise from
poorly designed databases, primarily:

1. Data Redundancy: Storing the same information multiple times.

2. Update Anomalies: Inconsistencies that occur when modifying redundant data. These include:
Insertion Anomaly: Inability to insert new data unless other data is also present.

Deletion Anomaly: Unintentional loss of data when deleting a row.

Update Anomaly: Difficulty in updating all occurrences of a piece of data consistently.

Real-life Analogy: Imagine a physical music library where each CD has a label with the album title, artist, genre, and
tracklist.

Without Normalization: If you have 10 albums by "Artist A", you write "Artist A" on 10 different CD labels. If "Artist
A" changes their name to "Artist B", you have to manually update 10 labels. This is update anomaly and data
redundancy.

With Normalization: You create a separate "Artist Roster" book. Each artist gets a unique ID in this book. On each
CD label, you only write the "Artist ID" from the roster. If "Artist A" changes their name, you just update one entry in
the "Artist Roster" book. All CDs referring to that Artist ID automatically get the correct, updated name. This saves
effort, reduces errors, and ensures consistency.

Applications Normalization is fundamental to relational database design and is applied in virtually every system that
uses a relational database, including:

Enterprise Resource Planning (ERP) systems

Customer Relationship Management (CRM) systems

Banking and financial systems

E-commerce platforms

Healthcare management systems

Inventory management systems

Any application requiring data integrity, consistency, and efficient storage.

[Link] Page 1 of 159

 2. Theory Explanation
In-depth explanation Normalization is achieved through a series of guidelines called "Normal Forms" (NFs). The most
common Normal Forms are 1NF, 2NF, 3NF, and BCNF (Boyce-Codd Normal Form). Each Normal Form builds upon the
previous one, imposing stricter rules to eliminate specific types of redundancy and dependency anomalies. The process
typically starts with an unnormalized table (raw data) and transforms it step-by-step into higher normal forms.

The core concept behind normalization is functional dependency (FD). A functional dependency A -> B means that
the value of attribute A uniquely determines the value of attribute B . Understanding FDs is crucial for identifying and
resolving redundancy issues.

Data Redundancy: Redundant data wastes storage space and makes data maintenance difficult. If a piece of
information is stored in multiple places, updating it requires modifying all its occurrences, increasing the chance of
inconsistencies.

Update Anomalies:
Insertion Anomaly: If a table contains information about two different entities (e.g., students and courses they
are enrolled in), you might not be able to add a new student without enrolling them in a course, or add a new
course without assigning a student.

Deletion Anomaly: If deleting the last student enrolled in a course also deletes all information about that course
(e.g., course name, instructor), this is a deletion anomaly.

Update Anomaly: If a student's address is stored multiple times for each course they take, changing the address
requires updating it in many places. Missing one update leads to inconsistent data.

Diagrams/flowcharts (describe in text if not possible to draw) The normalization process can be visualized as a
progression:

Unnormalized Table
|
V
First Normal Form (1NF) <-- Eliminates repeating groups and non-atomic attributes
|
V
Second Normal Form (2NF) <-- Eliminates partial dependencies
|
V
Third Normal Form (3NF) <-- Eliminates transitive dependencies
|
V
Boyce-Codd Normal Form (BCNF) <-- Addresses certain types of dependencies not covered b

Conceptual Flow: You start with a flat, possibly redundant table. You then apply rules to break it down into smaller, more
focused tables, ensuring that each table stores information about a single entity or a direct relationship between
entities.

Step-by-step breakdown The general process of normalization involves:

1. Analyze the initial data structure: Understand the attributes, their meanings, and how they relate to each other.

2. Identify Functional Dependencies (FDs): Determine which attributes functionally determine others. This is the most
critical step.

3. Apply 1NF rules: Ensure all attributes are atomic and eliminate repeating groups. This often involves creating new
tables and primary/foreign keys.

4. Apply 2NF rules: Ensure that all non-key attributes are fully functionally dependent on the primary key. This involves
identifying and removing partial dependencies by creating new tables.

[Link] Page 2 of 159

 5. Apply 3NF rules: Ensure that no non-key attribute is transitively dependent on the primary key. This involves
identifying and removing transitive dependencies by creating new tables.

6. Apply BCNF rules (if necessary): Address any remaining anomalies where a determinant is not a candidate key.

For "Introduction to Normalization," we will focus primarily on understanding the problems and the first step: 1NF.

3. Properties & Characteristics

Key properties

Minimizes Redundancy: Reduces duplicate data storage.

Ensures Data Integrity: Maintains consistency and correctness of data.

Improves Data Modifiability: Makes insertion, deletion, and update operations less prone to anomalies.

Simplifies Querying (sometimes): Well-normalized tables can simplify certain queries, though others might require
more joins.

Logical Database Design: Provides a structured approach to designing relational databases.

Advantages & disadvantages Advantages:

Reduced Data Redundancy: Less storage space required and fewer chances of data inconsistencies.

Improved Data Integrity: Changes to data are made in only one place, ensuring consistency.

Better Data Management: Easier to add, delete, and update data without introducing anomalies.

More Flexible Database Design: Easier to extend and modify the database structure without major overhauls.

Enhanced Query Performance (for specific types of queries): Smaller tables with fewer columns can sometimes
lead to faster data retrieval for specific queries.

Disadvantages:

Increased Complexity in Queries: Queries often require joining multiple tables, which can be more complex and
potentially slower for certain read operations.

More Tables: Results in a larger number of tables, which can make the overall database schema appear more
complex.

Potential for Slower Data Retrieval: For queries that need data from many joined tables, performance can
sometimes degrade compared to a denormalized structure.

Over-normalization: Applying normalization too rigorously can lead to an excessive number of tables, making the
database hard to manage and negatively impacting performance. This is why denormalization is sometimes used for
specific performance needs.

4. Mathematical / Logical Representation

Important formulas The core logical representation in normalization is the Functional Dependency (FD). A functional
dependency X -> Y exists if the values of the attribute set X uniquely determine the values of the attribute set Y .

X is called the determinant.

Y is called the dependent.

Example: In a Student table with attributes StudentID , StudentName , StudentAddress , CourseID ,

CourseName :

StudentID -> StudentName (StudentID determines StudentName)

StudentID -> StudentAddress (StudentID determines StudentAddress)

CourseID -> CourseName (CourseID determines CourseName)

[Link] Page 3 of 159

 (StudentID, CourseID) -> CourseName (Combination of StudentID and CourseID determines
CourseName)

Key Concepts related to FDs:

Candidate Key: An attribute or set of attributes that uniquely identifies a tuple in a relation. It is a minimal superkey.

Primary Key: A chosen candidate key to uniquely identify records in a table.

Non-Key Attribute: An attribute that is not part of any candidate key.

Derivations (if any) While no "formulas" in the arithmetic sense, FDs can be inferred and derived using Armstrong's
Axioms:

1. Reflexivity: If Y is a subset of X , then X -> Y . (e.g., {A, B} -> A )

2. Augmentation: If X -> Y , then XW -> YW for any attribute set W . (e.g., If A -> B , then {A, C} -> {B,
C} )

3. Transitivity: If X -> Y and Y -> Z , then X -> Z . (e.g., If StudentID -> CourseID and CourseID ->
CourseName , then StudentID -> CourseName )

These axioms (and derived rules like decomposition, union, pseudotransitivity) form the basis for logically determining
and manipulating functional dependencies, which is essential for achieving higher normal forms. However, for an
"Introduction," understanding the basic definition of FD is sufficient.

5. Operations / Algorithms
For "Introduction to Normalization," the "algorithm" is primarily the process of identifying and restructuring data to meet
Normal Form rules. We'll focus on the process to achieve First Normal Form (1NF), as it's the foundational step.

Algorithm: Converting an Unnormalized Table to First Normal Form (1NF)

Problem statement Given an unnormalized table that contains repeating groups or multi-valued attributes, transform it
into a set of tables that comply with First Normal Form (1NF) rules.

Step-by-step algorithm

1. Identify the Primary Key (PK): Determine a unique identifier for each row in the original unnormalized table. If a
natural primary key doesn't exist, a surrogate key (e.g., an auto-incrementing ID) might be needed.

2. Identify Multi-valued Attributes or Repeating Groups: Scan each attribute of the table to find those that can hold
multiple values for a single record or have repeating sets of attributes.
Multi-valued Attribute: An attribute that can have more than one value for a single instance of an entity (e.g., a
PhoneNumbers field containing (123-4567, 987-6543) ).

Repeating Group: A set of attributes that repeat for a single primary key value (e.g., Course1_Name ,
Course1_Grade , Course2_Name , Course2_Grade ).

3. Ensure Atomicity: For any multi-valued attribute, split it into separate rows or move it to a new table. Ensure each
attribute holds only a single, indivisible (atomic) value.

4. Create New Tables for Repeating Groups: For each repeating group, create a new table.
The attributes of the repeating group become columns in the new table.

The primary key of the original table becomes a foreign key in the new table.

The primary key of the new table will typically be a composite key formed by the foreign key from the original
table and the attribute(s) that uniquely identify each instance within the repeating group.

5. Remove the Repeating Group/Multi-valued Attribute from Original Table: Once moved, the original repeating
group or multi-valued attribute should be removed from the initial table.

Dry run example Unnormalized Table: STUDENT_COURSES

[Link] Page 4 of 159

 StudentID StudentName Address PhoneNumbers CourseCode CourseName Grade
101 Alice 123 Main (555-1234, 555-5678) CS101 Intro CS A
MA101 Calculus B
102 Bob 456 Oak 555-9999 CH101 Chemistry C

Problems:

PhoneNumbers is a multi-valued attribute.

CourseCode , CourseName , Grade form a repeating group for StudentID .

Applying 1NF Algorithm:

1. Identify PK: StudentID

2. Identify Multi-valued/Repeating Groups: PhoneNumbers (multi-valued), (CourseCode, CourseName,

Grade) (repeating group).

3. Ensure Atomicity / Create New Tables:

Address Multi-valued PhoneNumbers : Create a new table STUDENT_PHONES .

New Table: STUDENT_PHONES

StudentID (FK) PhoneNumber
101 555-1234
101 555-5678
102 555-9999
Primary Key for STUDENT_PHONES : (StudentID, PhoneNumber)

Address Repeating Group (CourseCode, CourseName, Grade) : Create a new table

STUDENT_ENROLLMENT .

New Table: STUDENT_ENROLLMENT

StudentID (FK) CourseCode (FK) CourseName Grade
101 CS101 Intro CS A
101 MA101 Calculus B
102 CH101 Chemistry C
Primary Key for STUDENT_ENROLLMENT : (StudentID, CourseCode)

4. Remove from Original Table: Remove PhoneNumbers , CourseCode , CourseName , Grade from the
original table.

Resulting 1NF Tables:

STUDENTS (Original Table, now 1NF)

StudentID (PK) StudentName Address

101 Alice 123 Main
102 Bob 456 Oak

STUDENT_PHONES (New Table, 1NF)

StudentID (FK) PhoneNumber (PK part)

101 555-1234
101 555-5678
102 555-9999

[Link] Page 5 of 159

 STUDENT_ENROLLMENT (New Table, 1NF)

StudentID (FK, PK part) CourseCode (FK, PK part) CourseName Grade

101 CS101 Intro CS A
101 MA101 Calculus B
102 CH101 Chemistry C

Pseudocode

// Conceptual algorithm for achieving 1NF from an unnormalized table

FUNCTION NormalizeTo1NF(OriginalTable T):
// 1. Identify Primary Key
Identify PrimaryKey for T

// 2. Process Multi-valued Attributes

FOR EACH Attribute A IN T:
IF A IS multi-valued:
CREATE NewTable_A
ADD PrimaryKey_of_T AS ForeignKey TO NewTable_A
ADD Atomic_Value_of_A AS Column TO NewTable_A
DEFINE (ForeignKey, Atomic_Value_of_A) AS PrimaryKey FOR NewTable_A
// Populate NewTable_A by splitting multi-values into new rows
FOR EACH Record IN T:
FOR EACH Value IN Record[A]:
INSERT (Record[PrimaryKey_of_T], Value) INTO NewTable_A
REMOVE A FROM T

// 3. Process Repeating Groups

FOR EACH RepeatingGroup G IN T:
CREATE NewTable_G
ADD PrimaryKey_of_T AS ForeignKey TO NewTable_G
ADD ALL Attributes_of_G AS Columns TO NewTable_G
// Define Primary Key for NewTable_G (often composite of FK and a unique identi
Identify Unique_Identifier_in_G
DEFINE (ForeignKey, Unique_Identifier_in_G) AS PrimaryKey FOR NewTable_G
// Populate NewTable_G by expanding repeating rows
FOR EACH Record IN T:
FOR EACH Instance_of_G IN Record:
INSERT (Record[PrimaryKey_of_T], Instance_of_G_Attributes) INTO NewTabl
REMOVE ALL Attributes_of_G FROM T

RETURN SetOfNormalizedTables (OriginalTable T modified, and all NewTables created)

Code (C++/Java/Python) As "Normalization" is a database design process rather than a runtime algorithm, providing
direct executable C++/Java/Python code that performs normalization on a live database structure is not straightforward
or typically done. Actual normalization is a manual or tool-assisted design task.

However, we can illustrate the transformation of data conceptually using Python, representing tables as lists of
dictionaries. This code will demonstrate the result of applying 1NF, not automate the design.

# Conceptual Python Code to demonstrate 1NF transformation

# This is an illustrative example, not a dynamic normalization engine.

print("--- Unnormalized Data ---")

[Link] Page 6 of 159

 unnormalized_data = [
{
'StudentID': 101,
'StudentName': 'Alice',
'Address': '123 Main St',
'PhoneNumbers': ['555-1234', '555-5678'],
'Courses': [
{'CourseCode': 'CS101', 'CourseName': 'Intro CS', 'Grade': 'A'},
{'CourseCode': 'MA101', 'CourseName': 'Calculus', 'Grade': 'B'}
]
},
{
'StudentID': 102,
'StudentName': 'Bob',
'Address': '456 Oak Ave',
'PhoneNumbers': ['555-9999'],
'Courses': [
{'CourseCode': 'CH101', 'CourseName': 'Chemistry', 'Grade': 'C'}
]
}
]

for record in unnormalized_data:

print(record)

# --- Applying 1NF (Conceptual Transformation) ---

# 1. Main Students Table

students_table = []
for record in unnormalized_data:
students_table.append({
'StudentID': record['StudentID'],
'StudentName': record['StudentName'],
'Address': record['Address']
})

# 2. Student Phones Table (for multi-valued PhoneNumbers)

student_phones_table = []
for record in unnormalized_data:
for phone in record['PhoneNumbers']:
student_phones_table.append({
'StudentID': record['StudentID'],
'PhoneNumber': phone
})

# 3. Student Enrollment Table (for repeating Courses group)

student_enrollment_table = []
for record in unnormalized_data:
for course in record['Courses']:
student_enrollment_table.append({
'StudentID': record['StudentID'],
'CourseCode': course['CourseCode'],
'CourseName': course['CourseName'],
'Grade': course['Grade']

[Link] Page 7 of 159

 })

print("\n--- Normalized Data (1NF) ---")

print("\nStudents Table:")
for record in students_table:
print(record)

print("\nStudent Phones Table:")

for record in student_phones_table:
print(record)

print("\nStudent Enrollment Table:")

for record in student_enrollment_table:
print(record)

6. Complexity Analysis
Normalization, as a database design process, does not have a typical "time complexity" or "space complexity" in the
algorithmic sense because it's largely a conceptual and manual process (though tools can assist).

Time complexity (Best, Worst, Average) Not applicable in the conventional sense of algorithmic runtime. The "time
complexity" refers more to the human effort and time required by a database designer.

Best Case: Simple schema, clear FDs, quick to normalize.

Worst Case: Complex schema, ambiguous FDs, many attributes, large amount of data to analyze, leading to a
lengthy design process.

Average Case: Depends heavily on the initial database complexity and the designer's experience.

Space complexity Again, not applicable in the conventional algorithmic sense (memory usage during execution).

Impact on Database Storage: Normalization generally reduces storage requirements by eliminating redundant data.
However, it increases the number of tables, which means more metadata and potentially more index space. Overall,
the reduction in data redundancy usually leads to more efficient storage.

Comparison with alternatives The primary "alternative" or counter-approach to normalization is Denormalization.

Normalization: Prioritizes data integrity, minimizes redundancy, and simplifies data maintenance. Typically leads to
more tables and more joins.

Denormalization: Intentionally introduces redundancy into a normalized database to improve query performance.
This is often done for specific read-heavy applications (e.g., data warehousing, reporting) where join operations are
expensive. It sacrifices some data integrity and maintenance ease for speed.

Comparison: Normalization is the starting point for good design. Denormalization is an optimization technique
applied judiciously to a pre-normalized schema, often driven by performance profiling. It's a trade-off.

7. Examples
At least 1–2 solved problems (small, medium, complex)

Solved Problem 1 (Small): Unnormalized to 1NF (Student Details)

Initial Unnormalized Table: STUDENT_INFO A student can have multiple hobbies.

StudentID StudentName Address Hobbies

1 John Doe 101 Elm Reading, Hiking
2 Jane Smith 202 Oak Photography

[Link] Page 8 of 159

 StudentID StudentName Address Hobbies
3 Peter Jones 303 Pine Swimming, Cycling, Reading

Problem: Hobbies is a multi-valued attribute.

Solution (to 1NF): Break STUDENT_INFO into two tables: STUDENTS and STUDENT_HOBBIES .

Table 1: STUDENTS (1NF)

StudentID (PK) StudentName Address

1 John Doe 101 Elm
2 Jane Smith 202 Oak
3 Peter Jones 303 Pine

Table 2: STUDENT_HOBBIES (1NF)

StudentID (FK, PK part) Hobby (PK part)

1 Reading
1 Hiking
2 Photography
3 Swimming
3 Cycling
3 Reading

Solved Problem 2 (Medium): Unnormalized to 1NF (Order Details)

Initial Unnormalized Table: CUSTOMER_ORDER Each customer order can have multiple items, and the item details
(name, price) are repeated within the order.

OrderID CustomerName CustomerAddress OrderDate Item1ID Item1Name Item1Qty Item1Price Item2ID Item2Name Ite
2023-01-
1001 Alice 123 Main P001 Laptop 1 1200.00 P002 Mouse 1
15
2023-01-
1002 Bob 456 Oak P003 Keyboard 2 75.00
16

Problems:

Item1ID, Item1Name, Item1Qty, Item1Price and Item2ID, Item2Name, Item2Qty,

Item2Price form a repeating group for OrderID .

CustomerName , CustomerAddress are dependent on OrderID (if multiple orders for same customer).

Solution (to 1NF): Break CUSTOMER_ORDER into two tables: ORDERS and ORDER_ITEMS .

Table 1: ORDERS (1NF) (Note: CustomerName and CustomerAddress are still in this table for now, higher
NFs would move them out into a CUSTOMERS table).

OrderID (PK) CustomerName CustomerAddress OrderDate

1001 Alice 123 Main 2023-01-15
1002 Bob 456 Oak 2023-01-16

Table 2: ORDER_ITEMS (1NF)

OrderID (FK, PK part) ItemID (FK, PK part) ItemName Quantity Price

1001 P001 Laptop 1 1200.00

[Link] Page 9 of 159

 OrderID (FK, PK part) ItemID (FK, PK part) ItemName Quantity Price
1001 P002 Mouse 1 25.00
1002 P003 Keyboard 2 75.00

Self-correction for higher NFs: Notice ItemName and Price are repeating with ItemID in ORDER_ITEMS . In
higher normal forms (like 2NF/3NF), ItemName and Price would be moved to a separate ITEMS table, as
ItemID functionally determines ItemName and Price . For 1NF, ItemName and Price are atomic and don't
form a repeating group within ORDER_ITEMS itself, so this structure is valid 1NF.

8. Common Mistakes & Edge Cases

Where students go wrong

Not understanding Atomicity: Confusing a list of values in one field (e.g., "Reading, Hiking") with a single complex
value. Atomicity means a value cannot be meaningfully decomposed further within the context of the database.

Misidentifying Primary Keys: Choosing a key that isn't unique or minimal.

Confusing 1NF with higher NFs: Thinking that just splitting a table into two resolves all redundancy, without
considering functional dependencies for 2NF/3NF.

Over-normalization: Sometimes, in specific scenarios, normalizing to BCNF might introduce too many joins, hurting
performance. Knowing when to stop (or strategically denormalize later) is important.

Ignoring real-world constraints: Normalization should reflect business rules. Sometimes, a seemingly non-atomic
attribute might be considered atomic in a specific context (e.g., a "full address" might be treated as atomic if
individual parts are never queried separately).

Special cases

Composite Keys: When the primary key is composed of two or more attributes. This is common in the new tables
created during normalization (e.g., (StudentID, CourseCode) in STUDENT_ENROLLMENT ).

Surrogate Keys: When no natural primary key exists, or a natural key is too long/complex, an artificial (surrogate)
key (like an auto-incrementing integer ID) is often added to a table. This simplifies relationships and indexing.

Data Type Considerations: Ensuring that attributes are stored with appropriate data types is part of having atomic
values.

9. Real-Life Applications
Normalization is an indispensable technique in the real world for designing robust and efficient relational databases across
various industries:

Financial Institutions (Banks, Investment Firms): Handling customer accounts, transactions, loans, and investments
requires extremely high data integrity. Normalization ensures that financial records are consistent, accurate, and free
from anomalies that could lead to significant financial errors.

E-commerce Platforms (Amazon, eBay): Managing products, customer information, orders, and inventory.
Normalization prevents inconsistencies in product details, customer addresses, and order statuses, ensuring a smooth
shopping experience and accurate record-keeping.

Healthcare Systems (Hospitals, Clinics): Storing patient records, appointments, medical history, and billing
information. Data integrity is paramount for patient safety and regulatory compliance. Normalization helps keep patient
data consistent and secure.

Enterprise Resource Planning (ERP) Systems (SAP, Oracle ERP): Integrating various business functions like finance,
HR, manufacturing, and supply chain. Normalized databases are essential for managing the complex interdependencies
of data across these modules, ensuring operational consistency.

Government and Public Sector Databases: Managing citizen records, tax information, land records, and public
services. The scale and criticality of this data demand high levels of normalization to ensure accuracy and prevent fraud

[Link] Page 10 of 159

 or errors.

Social Media Platforms (for core data): While often using specialized NoSQL databases for scale, core user profiles,
relationships, and content metadata often start with normalized relational structures to ensure consistency and integrity.

In essence, any application or system that relies on structured data storage and requires data accuracy, consistency, and
efficient management benefits from normalization. It forms the backbone of reliable data management.

10. Practice Problems

Easy

1. Identify Non-Atomic Attributes: For the following Book table, identify which attributes are non-atomic and
explain why.
BookID Title Authors ISBN Keywords
1 DBMS Guide John Doe, Jane Smith 978-123456 Database, SQL, NoSQL
2 Intro to AI Alice Green 978-789012 AI, Machine Learning

Medium

1. Convert to 1NF: Given the Employee_Projects table below, convert it into First Normal Form (1NF).
EmployeeID EmployeeName EmployeeSkills Project1_Name Project1_Hours Project2_Name Project2_Hours
E001 Mark Java, SQL Alpha 120 Beta 80
E002 Lisa Python Gamma 200
E003 David C#, Cloud, SQL Delta 150 Epsilon 50

Hard

1. Identify Problems & Convert to 1NF (Complex): Analyze the University_Department table. Identify all
violations of First Normal Form and then convert the table into a set of 1NF tables.
DeptID DeptName HOD_Name DeptLocation Courses_Offered Faculty_Names_in_Dept
C01 CompSci Dr. Smith Building A CS101:IntroProg, CS202:DataStruct John Doe, Jane Smith
M02 Math Dr. Lee Building B MA101:Calculus, MA202:LinearAlg Alice Green, Bob White
P03 Physics Dr. Khan Building A PH101:Mechanics Carol Brown, David Black

11. Summary / Key Points

Normalization is a process to organize database tables to minimize data redundancy and improve data integrity.

It solves update anomalies: Insertion, Deletion, and Update anomalies.

The process uses Normal Forms (NFs), starting typically with 1NF, 2NF, 3NF, and BCNF.

First Normal Form (1NF) is the foundational step, requiring two main conditions:
1. Atomicity: Each attribute must contain only a single, indivisible value. No multi-valued attributes.

2. No Repeating Groups: There should be no groups of related attributes that repeat within a single record.

Achieving 1NF usually involves:

Splitting multi-valued attributes into separate rows or a new related table.

Creating new tables for repeating groups, using the original table's primary key as a foreign key.

Functional Dependency (X -> Y) is the logical basis for normalization, indicating that X uniquely determines Y .

Advantages: Reduced redundancy, improved data integrity, easier maintenance, more flexible design.

Disadvantages: Can lead to more tables, increased join complexity for queries, potential performance overhead for
certain operations.

[Link] Page 11 of 159

 Denormalization is a counter-strategy used for performance optimization in specific scenarios, by intentionally
introducing controlled redundancy.

Highlighted Concepts & Terms:

Normalization

Data Redundancy

Update Anomalies (Insertion, Deletion, Update)

First Normal Form (1NF)

Atomicity

Repeating Groups

Functional Dependency (FD)

Primary Key (PK)

Foreign Key (FK)

Data Anomalies
Explanation of insertion, deletion, and update anomalies that occur in unnormalized databases, with illustrative examples.

Here are well-structured, textbook-style notes on "Data Anomalies" under the topic "Normalization" in DBMS.

1. Introduction
Definition Data anomalies refer to defects or inconsistencies in a relational database that arise when data is not
organized efficiently. These anomalies typically occur in tables that are not properly normalized, leading to redundancy
and potential data integrity issues during update, insertion, or deletion operations.

Why it is needed (real-life analogy if possible) Understanding and preventing data anomalies is crucial for
maintaining the integrity, consistency, and reliability of data in a database system. Without proper handling, these
anomalies can lead to incorrect information, wasted storage space, and significant challenges in data management.

Real-life Analogy: Imagine a school where student grades, teacher assignments, and course details are all kept in one
massive spreadsheet.

If a teacher's office location changes, you'd have to find every row where that teacher is listed and update their
location. If you miss even one, the data becomes inconsistent (Update Anomaly).

If you want to add a new course, but no students are enrolled yet, you might not be able to add the course details
without associating it with a student (Insertion Anomaly).

If a student drops all their courses, deleting their record might also accidentally delete the only existing information
about a specific course (Deletion Anomaly). This single, unorganized spreadsheet makes data management prone to
errors and redundancy, much like an unnormalized database table.

Applications The concept of data anomalies and their prevention through normalization is fundamental in various
database applications, including:

Database Design: Core to designing robust and efficient relational databases from scratch.

Data Migration: Ensuring data integrity when moving data between different systems.

Data Warehousing: While data warehouses often involve denormalization for query performance, understanding
anomalies helps in the initial extraction and transformation processes.

Enterprise Resource Planning (ERP) Systems: Critical for maintaining consistent and accurate data across different
modules (e.g., finance, HR, inventory).

[Link] Page 12 of 159

 Online Transaction Processing (OLTP) Systems: Essential for maintaining high data integrity during frequent read,
write, and update operations.

2. Theory Explanation
Data anomalies are primarily caused by data redundancy, which occurs when the same piece of information is stored
multiple times in a database. This redundancy often arises from poorly designed tables where attributes that belong to
different entities are grouped together. There are three main types of data anomalies:

In-depth explanation

Let's consider an example table EMPLOYEE_PROJECTS with the following columns: EmpID , EmpName ,
ProjectID , ProjectName , ProjectLocation , EmpRole

Imagine the following data:

EmpID | EmpName | ProjectID | ProjectName | ProjectLocation | EmpRole

---------------------------------------------------------------------
101 | Alice | P01 | Alpha | New York | Developer
101 | Alice | P02 | Beta | London | Developer
102 | Bob | P01 | Alpha | New York | Tester
103 | Carol | P03 | Gamma | Paris | Manager

1. Insertion Anomaly: This anomaly occurs when certain data cannot be inserted into the database without the
presence of other data, even if that other data is not yet available. It means we cannot add a new record unless all
key attributes are present.

Scenario: If we want to add a new project P04 (named Delta located in Berlin ) before any employee is
assigned to it, we cannot do so directly into the EMPLOYEE_PROJECTS table because EmpID (part of a
potential composite key like (EmpID, ProjectID) ) would be null, which violates entity integrity. We are
forced to either insert a dummy employee or wait until an employee is assigned.

2. Deletion Anomaly: This anomaly occurs when the deletion of certain data leads to the unintentional loss of other
important data that is not functionally dependent on the deleted primary key.

Scenario: If employee 103 (Carol) leaves the company, and she was the only employee assigned to project
P03 (Gamma, Paris), deleting her record would also delete all information about Project P03
( ProjectName , ProjectLocation ). This is undesirable if we want to retain project information even
without active employees.

3. Update Anomaly: This anomaly occurs when updating a piece of information requires updating multiple records,
and if all records are not updated consistently, it leads to data inconsistency.

Scenario: If the ProjectLocation for P01 changes from New York to San Francisco , we would
need to update all rows where ProjectID is P01 . In our example, EmpID 101 and EmpID 102 are both
assigned to P01 . If we update ProjectLocation for EmpID 101 but forget to update it for EmpID
102 , the database will have conflicting information about P01 's location.

Diagrams/flowcharts (described in text)

Let's represent the EMPLOYEE_PROJECTS table and its functional dependencies:

EmpID -> EmpName (Employee ID determines Employee Name)

ProjectID -> ProjectName, ProjectLocation (Project ID determines Project Name and Project Location)

EmpID, ProjectID -> EmpRole (A specific employee on a specific project has a specific role)

[Link] Page 13 of 159

 A conceptual diagram for the table structure:

+-------------------------------------------------------------+
| EMPLOYEE_PROJECTS |
+-------+----------+-----------+-------------+---------------+---------+
| EmpID | EmpName | ProjectID | ProjectName | ProjectLocation | EmpRole |
+-------+----------+-----------+-------------+---------------+---------+
^ ^ ^ ^ ^ ^
| | | | | |
+---------+ +-------------+---------------+ |
|
(PK: EmpID, ProjectID) |
|
Partial Dependency: ProjectID -> ProjectName, ProjectLocation |
(ProjectName, ProjectLocation depend on only part of PK) |
|
Transitive Dependency (if EmpRole could determine something else, not shown here)

The presence of ProjectName and ProjectLocation with ProjectID in the same table as EmpID and
EmpName is what causes the anomalies. ProjectName and ProjectLocation are attributes of ProjectID ,
not EmpID .

Step-by-step breakdown

1. Identify the Primary Key: For EMPLOYEE_PROJECTS , a logical primary key would be a composite key (EmpID,
ProjectID) because an employee can work on multiple projects and a project can have multiple employees.

2. Examine Non-Key Attributes: Look at EmpName , ProjectName , ProjectLocation , EmpRole .

3. Check for Partial Dependencies:

EmpName depends only on EmpID (part of the primary key). This indicates a partial dependency.

ProjectName and ProjectLocation depend only on ProjectID (part of the primary key). This also
indicates a partial dependency.

These partial dependencies are the root cause of Insertion, Deletion, and Update anomalies in this example. For
instance, ProjectName and ProjectLocation being repeated for every employee on a project leads to
redundancy and update anomalies.

4. Check for Transitive Dependencies: (Not directly shown as the primary cause in this simplified example, but
common in less normalized tables). A transitive dependency exists if a non-key attribute depends on another non-
key attribute, which in turn depends on the primary key. E.g., EmpID -> DeptID -> DeptName . If DeptName
were in EMPLOYEE_PROJECTS , it would cause more anomalies.

3. Properties & Characteristics

Key properties of anomalous data

Redundancy: Information is duplicated across multiple rows, leading to wasted storage space.

Inconsistency: Different versions of the same data can exist in the database due to incomplete updates.

Loss of Integrity: The database fails to accurately represent the real-world state of the data.

Maintenance Difficulty: Operations like updates, insertions, and deletions become complex and error-prone.

Advantages & disadvantages (of avoiding anomalies)

Advantages of Avoiding Anomalies (through Normalization):

[Link] Page 14 of 159

 Data Integrity: Ensures data accuracy and consistency, preventing conflicting information.

Reduced Redundancy: Minimizes duplicate data storage, saving disk space.

Easier Maintenance: Simplifies update, insert, and delete operations as changes need to be made in fewer
places.

Improved Query Performance (for specific types): For update-heavy operations, normalization can improve
performance.

Better Database Design: Leads to a logical, well-structured, and flexible database schema.

Reduced Storage Space: Less redundant data means less storage required.

Disadvantages of Avoiding Anomalies (i.e., Disadvantages of Normalization - a trade-off):

Increased Query Complexity: Queries often require joining multiple tables, which can be more complex and
sometimes slower (especially for read-heavy operations where denormalization might be considered).

More Tables: A normalized database typically involves a larger number of tables.

Potential Performance Overhead: While data integrity is gained, the overhead of joining multiple tables can
sometimes impact query response times, leading to intentional denormalization in specific use cases (e.g., data
warehousing).

4. Mathematical / Logical Representation

Data anomalies are logical consequences of improper functional dependencies within a relational schema, rather than
being described by direct mathematical formulas themselves. The underlying cause relates to how attributes determine
each other.

Important formulas (Conceptual for dependencies) The core concept related to anomalies is Functional
Dependency (FD).

A -> B : Attribute A functionally determines Attribute B. This means that for any given value of A, there is exactly
one corresponding value of B.

Anomalies arise when FDs are not correctly respected by the table structure, especially:

Partial Dependency: X -> Y , where X is a proper subset of the Candidate Key (CK), and Y is a non-prime
attribute (not part of any CK). This is the primary cause of anomalies when moving from 1NF to 2NF.
Example (from EMPLOYEE_PROJECTS ): (EmpID, ProjectID) is the CK. ProjectID ->
ProjectName, ProjectLocation . Here, ProjectID is a proper subset of the CK, and ProjectName ,
ProjectLocation are non-prime attributes.

Transitive Dependency: A -> B and B -> C , where A is a Candidate Key, and B and C are non-prime
attributes. This is the primary cause of anomalies when moving from 2NF to 3NF.
Example: EmpID -> DeptID and DeptID -> DeptName . If DeptName were in a table whose CK was
EmpID , it would be a transitive dependency.

Derivations (if any) There are no direct derivations for anomalies themselves. However, the process of normalization
involves "deriving" new, smaller tables from an anomalous one by applying rules based on functional dependencies to
eliminate partial and transitive dependencies. This process ensures that:

1. Each non-key attribute is fully functionally dependent on the primary key (2NF).

2. Each non-key attribute is non-transitively dependent on the primary key (3NF).

3. Non-key attributes are not dependent on other non-key attributes (BCNF).

These "derivations" are essentially decomposition steps:

Original Table R(A, B, C, D) with A -> B (partial dependency on composite key (A, C) ).

[Link] Page 15 of 159

 Decomposition: R1(A, B) and R2(A, C, D) . This decomposition eliminates the partial dependency and thus
the anomalies associated with it.

5. Operations / Algorithms
Data anomalies are symptoms of poor database design rather than operations or algorithms themselves. However, we can
describe the conceptual algorithm for identifying them and understand that the operations to resolve them are part of
Normalization.

Problem statement Given a relational table schema and its functional dependencies, identify potential Insertion,
Deletion, and Update anomalies.

Step-by-step conceptual algorithm (for identification)

1. Identify Candidate Keys (CKs): Determine all possible minimal sets of attributes that can uniquely identify a row in
the table.

2. Determine All Functional Dependencies (FDs): List all FDs that hold true for the table.

3. Check for Partial Dependencies (leads to 2NF violation, causes anomalies):

For each non-prime attribute (an attribute not part of any candidate key), check if it is functionally dependent on
a proper subset of any candidate key.

If X -> Y where X is a proper subset of a CK and Y is a non-prime attribute, then partial dependency exists,
leading to redundancy and anomalies.

4. Check for Transitive Dependencies (leads to 3NF violation, causes anomalies):

For each non-prime attribute C , check if it is functionally dependent on another non-prime attribute B , which
in turn is functionally dependent on the primary key A (i.e., A -> B and B -> C ).

If A -> B and B -> C (where A is CK, B and C are non-prime), then transitive dependency exists,
leading to redundancy and anomalies.

5. Check for Dependencies on Non-Key Attributes (leads to BCNF violation, causes anomalies):
Check if any non-key attribute or set of non-key attributes determines a key attribute (i.e., A -> B where B is
part of a key, but A is not a superkey). More specifically, if X -> Y where X is not a superkey and Y is a
prime attribute.

Dry run example

Consider EMPLOYEE_PROJECTS(EmpID, EmpName, ProjectID, ProjectName, ProjectLocation,

EmpRole) Candidate Key: (EmpID, ProjectID)

Functional Dependencies:

1. EmpID -> EmpName

2. ProjectID -> ProjectName, ProjectLocation

3. (EmpID, ProjectID) -> EmpRole

Check for Partial Dependencies:

EmpID -> EmpName : EmpID is a proper subset of the CK (EmpID, ProjectID) , and EmpName is a
non-prime attribute. Partial Dependency detected! This leads to Update (e.g., if EmpName changes for
EmpID ), Insertion (cannot add EmpID without ProjectID ), and Deletion (deleting ProjectID might
lose EmpName ) anomalies.

ProjectID -> ProjectName, ProjectLocation : ProjectID is a proper subset of the CK (EmpID,

ProjectID) , and ProjectName , ProjectLocation are non-prime attributes. Partial Dependency

[Link] Page 16 of 159

 detected! This leads to Update (e.g., changing ProjectLocation for ProjectID ), Insertion (cannot add
ProjectID without EmpID ), and Deletion (deleting EmpID might lose ProjectName ) anomalies.

Check for Transitive Dependencies: No direct transitive dependencies observed in this simplified example where a
non-prime attribute determines another non-prime attribute, and then the PK.

Conclusion: The presence of partial dependencies clearly indicates susceptibility to all three types of data anomalies.

Pseudocode (for identifying potential Update Anomaly via Redundancy)

This pseudocode aims to detect a common symptom of update anomalies: the repetition of data for non-key attributes
that are dependent on only part of a key.

FUNCTION detect_potential_update_anomaly_by_redundancy(table_data, attribute_to_check,

// table_data: A list of dictionaries, where each dictionary is a row
// attribute_to_check: The name of the non-key attribute that might be redundant
// primary_key_attributes: A list of attribute names forming the primary key

CREATE a dictionary `attribute_values_map` // Maps (attribute_to_check_value) to a

FOR EACH row IN table_data:

current_attribute_value = row[attribute_to_check]
current_pk_values = []
FOR pk_attr IN primary_key_attributes:
ADD row[pk_attr] TO current_pk_values
current_pk_tuple = TUPLE(current_pk_values) // Convert list to tuple for dictio

IF current_attribute_value NOT IN `attribute_values_map`:

`attribute_values_map`[current_attribute_value] = SET() // Use a set to sto

ADD current_pk_tuple TO `attribute_values_map`[current_attribute_value]

// Now, check for redundancy: if an attribute value appears with multiple distinct
// AND if a *subset* of PK attributes determines the attribute_to_check, it's an an
// This simplified check focuses on finding where a non-key attribute has the same
// but appears with different full primary keys, suggesting it's repeated.

PRINT "--- Potential Update Anomaly Detection ---"

potential_anomalies_found = FALSE
FOR attribute_value, pk_set IN `attribute_values_map`:
IF LENGTH(pk_set) > 1:
PRINT "Value '", attribute_value, "' for attribute '", attribute_to_check,
PRINT " is associated with multiple distinct primary keys:", pk_set
PRINT " This indicates potential redundancy and an update anomaly if '", a
potential_anomalies_found = TRUE

IF NOT potential_anomalies_found:
PRINT "No obvious update anomalies (redundancy) found for attribute '", attribu

Code (Python - simple redundancy detection for update anomaly indicator)

# Define sample data (similar to our EMPLOYEE_PROJECTS table conceptually)

# Using a list of dictionaries to represent rows
employee_projects_data = [
{'EmpID': 101, 'EmpName': 'Alice', 'ProjectID': 'P01', 'ProjectName': 'Alpha', 'Pro

[Link] Page 17 of 159

 {'EmpID': 101, 'EmpName': 'Alice', 'ProjectID': 'P02', 'ProjectName': 'Beta', 'Proj
{'EmpID': 102, 'EmpName': 'Bob', 'ProjectID': 'P01', 'ProjectName': 'Alpha', 'Proje
{'EmpID': 103, 'EmpName': 'Carol', 'ProjectID': 'P03', 'ProjectName': 'Gamma', 'Pro
{'EmpID': 104, 'EmpName': 'David', 'ProjectID': 'P01', 'ProjectName': 'Alpha', 'Pro
{'EmpID': 105, 'EmpName': 'Eve', 'ProjectID': 'P04', 'ProjectName': 'Delta', 'Proje
]

def detect_redundant_attribute_values(table_data, attribute_to_check):

"""
Detects if a non-key attribute's value is repeated across multiple rows.
This often indicates redundancy and potential for update anomalies.
"""
value_occurrences = {} # Maps attribute value to a list of original rows it appeare

for i, row in enumerate(table_data):

value = [Link](attribute_to_check)
if value is not None:
if value not in value_occurrences:
value_occurrences[value] = []
value_occurrences[value].append(i) # Store row index

print(f"\n--- Checking for redundancy in attribute: '{attribute_to_check}' ---")

found_redundancy = False
for value, row_indices in value_occurrences.items():
if len(row_indices) > 1:
print(f" Value '{value}' appears in multiple rows (indices: {row_indices})
print(f" Example rows:")
for idx in row_indices:
print(f" - {table_data[idx]}")
print(f" This indicates redundancy. If '{attribute_to_check}' is not part
print(f" it's susceptible to update anomalies (changing '{value}' would re
found_redundancy = True

if not found_redundancy:
print(f" No significant redundancy found for attribute '{attribute_to_check}'.

# Example Usage:
detect_redundant_attribute_values(employee_projects_data, 'EmpName')
detect_redundant_attribute_values(employee_projects_data, 'ProjectName')
detect_redundant_attribute_values(employee_projects_data, 'ProjectLocation')
detect_redundant_attribute_values(employee_projects_data, 'EmpRole')

# Output for 'ProjectName' and 'ProjectLocation' would show redundancy because 'Alpha'
# Output for 'EmpName' would also show redundancy for 'Alice'

6. Complexity Analysis
Analyzing the "complexity" of anomalies itself isn't standard, as anomalies are symptoms. Instead, we analyze the
complexity implications of having anomalies versus avoiding them through normalization.

Time complexity (Best, Worst, Average)

Queries on Anomalous Data:

[Link] Page 18 of 159

 Retrieval: Select queries might be faster in some denormalized (anomalous) cases if all needed data is in one
table, avoiding joins. However, if data needs to be aggregated or filtered based on potentially inconsistent
redundant data, it can be complex.

Update Operations:
Best Case: Updating a non-redundant attribute (unlikely in anomalous tables, but conceptually possible). O(1)
if indexed.

Worst Case: Updating a redundant attribute, requiring changes across many rows. O(N) where N is the
number of rows containing the redundant data. If not all instances are updated, data inconsistency occurs.

Insertion Operations:
Requires inserting all attributes, even if some are null (Insertion Anomaly). Can be complex.

Deletion Operations:
Can lead to unintentional data loss (Deletion Anomaly), effectively increasing the "cost" of the delete
operation if follow-up operations are needed to recover lost data.

Queries on Normalized Data (Anomalies Avoided):

Retrieval: Often requires joins, which can increase query execution time compared to a single, wide
denormalized table, particularly for complex reports. The join complexity depends on the number of tables and
join conditions (e.g., O(N log N) or O(N*M) depending on join algorithm and data distribution).

Update/Insert/Delete Operations: Generally more efficient and safe. Changes are localized to fewer
tables/rows, simplifying logic and ensuring consistency. O(1) to O(log N) for single row operations with indexing.

Space complexity

Anomalous Data: Significantly higher due to redundancy. The same information (e.g., project location) is stored
multiple times for each associated employee, wasting storage space.

Normalized Data: Significantly lower. Each piece of information is stored only once, minimizing redundant storage.

Comparison with alternatives

Anomalous (Denormalized) vs. Normalized Data:

Data Integrity: Normalized data excels, anomalous data struggles.

Maintenance Cost: Normalized data has lower maintenance cost; anomalous data has higher, error-prone cost.

Storage Space: Normalized data uses less space; anomalous data uses more.

Read Performance: Denormalized data can sometimes offer faster reads (fewer joins), but at the risk of
inconsistency. Normalized data can require more complex joins, potentially slowing down reads for complex
queries.

Write Performance: Normalized data generally offers faster and safer writes. Anomalous data leads to complex,
error-prone writes.

7. Examples
Here, we'll use the EMPLOYEE_PROJECTS table example and walk through how anomalies occur.

Problem: Given the following table Employee_Project_Details and its data, identify and explain all types of data
anomalies that can occur.

Employee_Project_Details table:

+-------+----------+-----------+-------------+-----------------+-----------+
| EmpID | EmpName | ProjectID | ProjectName | ProjectLocation | EmpRole |
+-------+----------+-----------+-------------+-----------------+-----------+
| 101 | Alice | P01 | Alpha | New York | Developer |

[Link] Page 19 of 159

 | 101 | Alice | P02 | Beta | London | Developer |
| 102 | Bob | P01 | Alpha | New York | Tester |
| 103 | Carol | P03 | Gamma | Paris | Manager |
| 104 | David | P01 | Alpha | New York | Architect |
+-------+----------+-----------+-------------+-----------------+-----------+

Assume the composite primary key is (EmpID, ProjectID) .

Solution:

1. Insertion Anomaly:

Scenario: We want to add a new project P04 (named Delta , located in Berlin ) to the database, but no
employee has been assigned to it yet.

Problem: If (EmpID, ProjectID) is the primary key, EmpID cannot be NULL. We cannot insert the
ProjectID , ProjectName , ProjectLocation information without providing a valid EmpID . This forces
us to either:
Wait until an employee is assigned to P04 .

Insert a dummy EmpID (which is bad practice and creates more fake data).

Explanation: The project information ( ProjectName , ProjectLocation ) is dependent on ProjectID ,

which is only part of the primary key. It's not fully dependent on the entire primary key (EmpID, ProjectID) .

2. Deletion Anomaly:

Scenario: Employee 103 (Carol) is the only employee currently assigned to project P03 (Gamma, Paris). Carol
leaves the company, and her record needs to be deleted from the Employee_Project_Details table.

Problem: If we delete the row for (EmpID=103, ProjectID=P03) , we will also lose all information about
Project P03 ( ProjectName='Gamma' , ProjectLocation='Paris' ). This project information might still
be important to retain, even if no employees are currently working on it.

Explanation: The project details ( ProjectName , ProjectLocation ) are tied to ProjectID , which is only
part of the primary key. When the last record containing that ProjectID is deleted, its associated non-key
attributes are also lost.

3. Update Anomaly:

Scenario: The location of project P01 changes from New York to San Francisco .

Problem: We need to update the ProjectLocation for ProjectID P01 in every row where P01 appears.
In our example, this means updating rows for EmpID 101 , EmpID 102 , and EmpID 104 . If we update only
one or two of these rows and miss the third, the database will have inconsistent data for Project P01 's location.
Some records will show New York , others San Francisco .

Explanation: ProjectLocation is dependent on ProjectID , which is not the entire primary key. This
information is redundant and repeated for every employee working on P01 . Any change requires multiple updates,
leading to a high risk of inconsistency.

Resolution (Conceptual): To resolve these anomalies, the Employee_Project_Details table should be decomposed
into smaller, normalized tables:

EMPLOYEE table: (EmpID, EmpName)

PROJECT table: (ProjectID, ProjectName, ProjectLocation)

EMPLOYEE_ASSIGNMENT table: (EmpID, ProjectID, EmpRole)

[Link] Page 20 of 159

 This decomposition ensures that each piece of information is stored only once, and attributes are fully functionally
dependent on their respective primary keys.

8. Common Mistakes & Edge Cases

Where students go wrong

Confusing Anomaly Types: Students often mix up Insertion, Deletion, and Update anomalies. It's important to
differentiate the specific conditions that cause each.

Not Identifying the Root Cause: Focusing on the symptom (e.g., redundant data) without understanding the
underlying functional dependencies (partial or transitive) that cause it.

Incorrectly Identifying Primary Keys: A wrong primary key choice can mask or create apparent anomalies.

Over-Normalizing: Believing that "more normalized is always better" without considering performance trade-offs
for read-heavy applications where denormalization might be deliberately chosen.

Ignoring Business Rules: Functional dependencies are derived from business rules. Misinterpreting these rules can
lead to incorrect normalization.

Special cases

Intentional Denormalization: In data warehousing or OLAP systems, denormalization (introducing redundancy and
thus susceptibility to anomalies) is sometimes done intentionally to improve query performance, especially for
complex analytical queries that involve many joins on highly normalized tables. This is a trade-off: sacrificing write
performance and strict data integrity for read performance.

Composite Primary Keys: Anomalies are particularly prevalent in tables with composite primary keys where non-
key attributes are partially dependent on only a part of the key.

Temporal Data: Handling historical data can sometimes involve storing redundant information or using special
techniques to manage changes over time, which might appear anomalous but are managed carefully.

9. Real-Life Applications
The concept of avoiding data anomalies through normalization is fundamental to almost all relational database systems in
real-world applications:

Banking Systems: Ensuring that account balances, transaction records, and customer details are always consistent and
accurate is paramount. Update anomalies could lead to incorrect financial records, and deletion anomalies could result
in lost transaction history.

E-commerce Platforms: Product information, customer orders, and inventory levels must be precisely managed. An
update anomaly could show an incorrect product price or description, leading to customer dissatisfaction. Insertion
anomalies could prevent adding new products without associated sales.

Healthcare Systems: Patient records, medical history, and appointment schedules require the highest level of data
integrity. Data anomalies could lead to dangerous misdiagnoses or incorrect treatments.

Inventory Management: Keeping track of stock levels, supplier information, and product details. Redundancy (and thus
update anomalies) could lead to inaccurate stock counts, resulting in overselling or underselling.

Government Databases: National ID systems, tax records, and census data rely heavily on normalized structures to
maintain accuracy and prevent fraud.

Social Media Platforms: User profiles, posts, and connections need consistent data to ensure a reliable user experience
and data integrity across various features.

10. Practice Problems

Easy Consider a table Customer_Order(OrderID, CustomerName, CustomerAddress, OrderDate,
ItemName, ItemPrice, Quantity) . Assume OrderID is the primary key. Identify one potential update

[Link] Page 21 of 159

 anomaly based on this structure.

Medium Consider a table Course_Enrollment(StudentID, StudentName, CourseID, CourseName,

InstructorName, InstructorOffice, Grade) . Assume (StudentID, CourseID) is the primary key.
Identify all three types of data anomalies (Insertion, Deletion, Update) that can occur in this table. Explain each with a
brief scenario.

Hard You are given a table Flight_Booking(BookingID, PassengerID, PassengerName, FlightNumber,

Origin, Destination, DepartureTime, ArrivalTime, AircraftType, PilotID, PilotName,
FlightAttendantID, FlightAttendantName) . Assume BookingID is the primary key. Also, consider these
functional dependencies:

PassengerID -> PassengerName

FlightNumber -> Origin, Destination, DepartureTime, ArrivalTime, AircraftType,

PilotID

PilotID -> PilotName

FlightAttendantID -> FlightAttendantName Identify all potential data anomalies (Insertion, Deletion,
Update) based on the given FDs and primary key. For each anomaly, describe a specific scenario and explain why it
occurs. Suggest how to resolve these anomalies by decomposing the table into a set of normalized tables (up to
3NF).

11. Summary / Key Points

Data Anomalies are inconsistencies or defects in a database due to poor design, primarily caused by data redundancy.

There are three main types:

Insertion Anomaly: Cannot insert data for one entity without inserting data for another (e.g., adding a project
without an employee).

Deletion Anomaly: Deleting data for one entity unintentionally deletes data for another (e.g., deleting the last
employee on a project loses project details).

Update Anomaly: Updating a piece of data requires multiple changes, leading to inconsistencies if not all instances
are updated (e.g., changing project location requires updating many rows).

Root Cause: These anomalies stem from violations of normalization rules, specifically partial functional dependencies
(for 2NF violations) and transitive functional dependencies (for 3NF violations).

Resolution: Data anomalies are primarily resolved through Normalization, which involves decomposing large,
unnormalized tables into smaller, well-structured tables.

Benefits of Avoiding Anomalies: Enhanced data integrity, consistency, reduced redundancy, easier data maintenance,
and often better write performance.

Trade-offs: Highly normalized databases might require more complex queries (involving more joins), which can
sometimes impact read performance for certain types of analytical queries. This can lead to intentional
denormalization in specific use cases like data warehousing.

Highlighted Formulas and Shortcuts:

Anomalies = Redundancy + Dependency Violations

Partial Dependency: X -> Y where X is a proper subset of a Candidate Key, and Y is a non-prime attribute.
(Causes 2NF violations & Anomalies)

Transitive Dependency: A -> B and B -> C , where A is a Candidate Key, and B , C are non-prime
attributes. (Causes 3NF violations & Anomalies)

[Link] Page 22 of 159

 Functional Dependencies (FDs)
Definition of functional dependency, types of FDs (trivial, non-trivial, full, partial, transitive), and Armstrong's Axioms for
inferring FDs.

1. Introduction
Definition A Functional Dependency (FD) is a constraint between two sets of attributes in a relational database. It states
that the value of one set of attributes (the determinant or Left-Hand Side, LHS) uniquely determines the value of
another set of attributes (the dependent or Right-Hand Side, RHS) within a tuple (row) of a relation. Formally, if we have
a relation R and X and Y are sets of attributes of R , then X functionally determines Y (written as X -> Y ) if,
for any two tuples t1 and t2 in R , if t1[X] = t2[X] , then t1[Y] = t2[Y] . This means that if the values for
attributes in X are the same for two tuples, then the values for attributes in Y must also be the same for those two
tuples.

Why it is needed (real-life analogy if possible) Functional Dependencies are fundamental to understanding the
relationships between data and ensuring data integrity and consistency. They help in designing efficient and reliable
databases.

Real-life Analogy: Imagine a Student database table. Student_ID is a unique identifier for each student. If you
know a Student_ID , you can uniquely determine the Student_Name , Student_Major , and
Student_Address . This can be expressed as: Student_ID -> Student_Name, Student_Major,
Student_Address Here, Student_ID is the determinant, and Student_Name , Student_Major ,
Student_Address are the dependents. If, however, Student_Name is not unique (e.g., two students named 'John
Doe'), then Student_Name cannot functionally determine Student_ID . Understanding these relationships helps
prevent data redundancy (storing the same information multiple times), update anomalies (inconsistent data after
updates), and deletion anomalies (unintended loss of data).

Applications

1. Database Design and Normalization: FDs are the cornerstone of normalization, a process of organizing the
columns and tables of a relational database to minimize data redundancy and improve data integrity. Normal Forms
(like 1NF, 2NF, 3NF, BCNF) are defined based on the types of FDs present in a relation.

2. Schema Refinement: FDs help in decomposing large, poorly designed tables into smaller, well-structured ones,
ensuring that the decomposed tables are lossless and dependency-preserving.

3. Query Optimization: Knowing FDs can sometimes help the database system optimize queries by understanding
which data can be uniquely identified or which joins are redundant.

4. Data Consistency and Integrity: FDs serve as constraints that the data must adhere to, ensuring that the database
remains consistent and free from logical errors.

2. Theory Explanation
In-depth explanation A functional dependency X -> Y implies that for every possible instance of the relation, if two
tuples agree on the attributes in X , they must also agree on the attributes in Y .

Notation:

X -> Y : X functionally determines Y .

X is the determinant (LHS).

Y is the dependent (RHS).

Attributes are typically enclosed in curly braces {} if they are a set, e.g., {Student_ID} -> {Student_Name,
Student_Major} . When unambiguous, they can be written without braces, e.g., Student_ID ->

[Link] Page 23 of 159

 Student_Name, Student_Major .

Types of Functional Dependencies:

1. Trivial Functional Dependency: An FD X -> Y is trivial if Y is a subset of X ( Y ⊆ X ). This type of FD is

always true and provides no new information about the data.
Example: {Student_ID, Student_Name} -> Student_ID is trivial because Student_ID is part of the
determinant.

Example: A -> A is always trivial.

2. Non-Trivial Functional Dependency: An FD X -> Y is non-trivial if Y is not a subset of X ( Y <binary

data, 1 bytes><binary data, 1 bytes> X ). These are the FDs that are important for database design.
Example: Student_ID -> Student_Name is non-trivial.

3. Completely Non-Trivial Functional Dependency: An FD X -> Y is completely non-trivial if X ∩ Y = ��

(the intersection of X and Y is empty). This is a stronger form of non-triviality where no attribute in Y is also present
in X.
Example: Student_ID -> Student_Name (assuming Student_ID and Student_Name are distinct attributes).

4. Full Functional Dependency: For an FD X -> Y , Y is fully functionally dependent on X if Y is functionally

dependent on X but not on any proper subset of X . This is crucial for 2NF.
Example: If (Student_ID, Course_ID) is a composite key for a Grade table, and Grade ->
(Student_ID, Course_ID) but Grade is not determined by just Student_ID or just Course_ID .

More commonly used in context of primary key: If A, B -> C is an FD, then C is fully functionally dependent
on {A, B} if A, B -> C holds, but neither A -> C nor B -> C holds.

5. Partial Functional Dependency: For an FD X -> Y , Y is partially functionally dependent on X if Y is

functionally dependent on X and also on a proper subset of X . This violates 2NF.
Example: If (Student_ID, Course_ID) is the primary key and (Student_ID, Course_ID) ->
Student_Name , but also Student_ID -> Student_Name . Here, Student_Name is partially dependent
on the composite key.

6. Transitive Functional Dependency: An FD X -> Y is transitive if there exists an attribute set Z such that X ->
Z and Z -> Y hold, but Z does not functionally determine X ( Z <binary data, 1 bytes><binary
data, 1 bytes> X ) and Z is not a subset of Y ( Z <binary data, 1 bytes><binary data, 1
bytes> Y ). This violates 3NF.
Example: Student_ID -> Department_ID and Department_ID -> Department_Name . Then
Student_ID -> Department_Name is a transitive dependency (assuming Department_ID does not
determine Student_ID ).

Diagrams/flowcharts (describe in text if not possible to draw) Imagine a directed graph where nodes represent
attributes and directed edges (arrows) represent functional dependencies.

1. Simple FD: [Student_ID] ----> [Student_Name] This represents Student_ID -> Student_Name .

2. Multiple Determinants/Dependents: [Employee_ID] ----> [Employee_Name] [Employee_ID] ---->

[Department_Name] This represents {Employee_ID} -> {Employee_Name, Department_Name} .

3. Composite Determinant: [Student_ID, Course_ID] ----> [Grade] This represents {Student_ID,

Course_ID} -> Grade .

4. Transitive Dependency: [Student_ID] ----> [Department_ID] ----> [Department_Name] This

shows the path of a transitive dependency: Student_ID determines Department_ID , and Department_ID
determines Department_Name , thus Student_ID indirectly determines Department_Name .

[Link] Page 24 of 159

 Step-by-step breakdown When analyzing a relation for Functional Dependencies:

1. Identify Attributes: List all attributes in the relation schema.

2. Examine Relationships: For each attribute or set of attributes X , consider if it uniquely determines another
attribute or set of attributes Y .
Start with potential primary keys or candidate keys, as they will functionally determine all other attributes.

Look for non-key attributes that might determine other non-key attributes.

3. Formulate FDs: Express these observed relationships as X -> Y .

4. Test FDs against data: If you have sample data, verify that the FDs hold true for all tuples. If not, the FD does not
exist.

5. Consider all combinations: Systematically check for single-attribute determinants, then two-attribute determinants,
and so on, until all meaningful dependencies are identified.

6. Distinguish types: Classify the FDs as trivial, non-trivial, full, partial, or transitive to prepare for normalization.

3. Properties & Characteristics

Key properties Functional dependencies adhere to a set of inference rules known as Armstrong's Axioms, which are
sound and complete. They allow us to derive new FDs from a given set of FDs.

1. Reflexivity (Rule of Reflexion): If Y is a subset of X ( Y ⊆ X ), then X -> Y .

Explanation: Any set of attributes trivially determines itself and any of its subsets.

Example: {A, B} -> A or {A, B} -> {A, B} .

2. Augmentation (Rule of Augmentation): If X -> Y , then X Z -> Y Z for any set of attributes Z .

Explanation: Adding attributes to the determinant (LHS) does not invalidate the original dependency. If X
determines Y , then X combined with Z will also determine Y combined with Z .

Example: If Student_ID -> Student_Name , then {Student_ID, Course_ID} -> {Student_Name,

Course_ID} .

3. Transitivity (Rule of Transitivity): If X -> Y and Y -> Z , then X -> Z .

Explanation: If X determines Y , and Y determines Z , then X indirectly determines Z .

Example: If Student_ID -> Department_ID and Department_ID -> Department_Name , then

Student_ID -> Department_Name .

Derived Rules (from Armstrong's Axioms): These rules can be proven using Armstrong's Axioms:

4. Union Rule: If X -> Y and X -> Z , then X -> Y Z .

Explanation: If a set of attributes determines two separate sets of attributes, it also determines their union.

Derivation:
1. X -> Y (Given)

2. X -> Z (Given)

3. X X -> Y X (Augmentation from 1 with X) - This simplifies to X -> Y X

4. X Z -> Y Z (Augmentation from 1 with Z)

5. Y X -> Y Z (Augmentation from 2 with Y) - This simplifies to Y X -> Y Z

6. By X -> Y and X -> Z , we can say X -> Y and X -> Z .

7. From X -> Y , augment with X to get X -> YX .

[Link] Page 25 of 159

 8. From X -> Z , augment with Y to get XY -> YZ .

9. Using transitivity on X -> YX and YX -> YZ , we get X -> YZ . Correction: A simpler derivation is
needed. Corrected Derivation:

10. X -> Y (Given)

11. X -> Z (Given)

12. X -> X (Reflexivity)

13. X -> YX (Augmentation with X on X -> Y does not make sense. Better: Augment X -> Y with X
implies XX -> YX , which simplifies to X -> YX . No, this is wrong. Augment X -> Y with X is trivial.
Better:

14. X -> Y (Given)

15. X -> Z (Given)

16. X -> X (Reflexivity)

17. X -> YX (Augmentation on X -> Y with X implies XX -> YX , which simplifies to X -> YX -- no,
this is not correct. It should be: from X->Y , by augmentation with X , we get X X -> Y X . This is wrong.
Correct is: X -> Y , augment with X gives X -> YX ? No. Augment X -> Y with Z gives XZ ->
YZ . Let's use a standard derivation:

18. X -> Y (Given)

19. X -> Z (Given)

20. X -> YX (From 1, using Reflexivity X -> X and Union with X -> Y , we get X -> YX ... this
derivation is complex). Simpler derivation using augmentation:

21. X -> Y (Given)

22. Augment 1 with X : X X -> Y X , simplifies to X -> YX (if X means X and X means X , then X -
> Y by augmenting with X means X still determines Y , and adding X to both sides. X -> YX is X
determines Y and X ).

23. X -> Z (Given)

24. X -> YZ (This is the target) A widely accepted derivation:

25. X -> Y (Given)

26. X -> Z (Given)

27. X -> XY (Augmentation rule on X -> X with Y: X -> X , then XY -> XY ) -- no, this is getting complex
and the user wants "derivations if any". Simpler: Given X -> Y and X -> Z .

28. X -> Y (Given)

29. X X -> Y X (Augmentation rule on 1, with X added to both sides. XX simplifies to X , so X -> YX ).

30. X -> Z (Given)

31. YX -> YZ (Augmentation rule on 3, with Y added to both sides)

32. X -> YZ (Transitivity rule on X -> YX and YX -> YZ ) This derivation is also debated. Let's stick to the
common conceptual understanding and mention the rules without overly complex formal derivation for
brevity and clarity for a TA context. The key is understanding these rules are derivable.

5. Decomposition Rule: If X -> Y Z , then X -> Y and X -> Z .

Explanation: If a set of attributes determines a combined set of attributes, it also determines each individual
component.

Derivation:

[Link] Page 26 of 159

 1. X -> YZ (Given)

2. YZ -> Y (Reflexivity: Y is a subset of YZ )

3. X -> Y (Transitivity on 1 and 2) Similarly, X -> Z can be derived.

6. Pseudotransitivity Rule: If X -> Y and Y W -> Z , then X W -> Z .

Explanation: This rule combines augmentation and transitivity. If X determines Y , and Y combined with W
determines Z , then X combined with W also determines Z .

Derivation:
1. X -> Y (Given)

2. X W -> Y W (Augmentation on 1, with W )

3. Y W -> Z (Given)

4. X W -> Z (Transitivity on 2 and 3)

Advantages & disadvantages Advantages:

1. Reduced Redundancy: By identifying and resolving FDs, data duplication can be significantly minimized, saving
storage space and improving efficiency.

2. Improved Data Integrity: FDs serve as constraints, ensuring that the database remains consistent and free from
update, insertion, and deletion anomalies.

3. Better Database Design: Normalization based on FDs leads to a well-structured and logical database schema that is
easier to manage, query, and extend.

4. Easier Maintenance: A normalized database is less prone to errors and easier to maintain over time.

5. Enhanced Query Performance: By eliminating redundancy and organizing data logically, queries can often be
executed more efficiently.

Disadvantages:

1. Complexity in Identification: For large and complex schemas, identifying all relevant FDs can be a challenging and
time-consuming task, often requiring domain expertise.

2. Potential for Over-Normalization: Excessive normalization (breaking down tables too much) can sometimes lead to
more joins being required for queries, potentially increasing query execution time in certain scenarios (though this is
often outweighed by the benefits).

3. Performance Overhead (Minor): Enforcing FDs (especially complex ones) as constraints can sometimes add a
minor overhead to data modification operations (inserts, updates, deletes).

4. Difficult to Change: If the underlying FDs change due to evolving business rules, redesigning the database schema
can be a significant effort.

4. Mathematical / Logical Representation

Important formulas The core "formulas" are Armstrong's Axioms and the concept of attribute closure.

1. Armstrong's Axioms (as described in Section 3):

Reflexivity: If Y ⊆ X , then X -> Y .

Augmentation: If X -> Y , then XZ -> YZ .

Transitivity: If X -> Y and Y -> Z , then X -> Z .

2. Closure of a Set of Attributes (X+) Given a relation schema R , a set of attributes X ⊆ R , and a set of functional
dependencies F on R , the closure of X with respect to F (denoted X+ ) is the set of all attributes A in R

[Link] Page 27 of 159

 such that X -> A can be logically inferred from F using Armstrong's Axioms. X+ = { A | X -> A is
derivable from F } This is a critical concept used to find candidate keys and check if an FD holds.

3. Closure of a Set of Functional Dependencies (F+) Given a set of functional dependencies F , the closure of F
(denoted F+ ) is the set of all functional dependencies that can be logically inferred from F using Armstrong's
Axioms. F+ = { fd | fd is derivable from F }

4. Equivalence of FD Sets: Two sets of FDs, F and G , are equivalent ( F ≈ G ) if F+ = G+ . This means every FD
in F can be derived from G , and every FD in G can be derived from F . Practically, this is checked by verifying if
F covers G (i.e., for every g in G , g can be derived from F ) and G covers F (i.e., for every f in F , f
can be derived from G ).

Derivations (if any) As mentioned in Section 3, the Union, Decomposition, and Pseudotransitivity rules are derived
from Armstrong's Axioms. The derivations for these rules illustrate how the core axioms can be combined to prove other
useful inference rules. The detailed steps were provided conceptually in Section 3.

5. Operations / Algorithms
Algorithm 1: Computing Closure of an Attribute Set (X+)

Problem statement: Given a set of attributes X (a subset of the relation schema R ) and a set of functional
dependencies F , find X+ , the set of all attributes that are functionally determined by X .

Step-by-step algorithm:

1. Initialize X_closure with the attributes in X . ( X_closure will grow to become X+ ).

2. Repeat the following steps until X_closure does not change in an iteration: a. For each functional dependency A
-> B in F : b. If A is a subset of X_closure (meaning all attributes in A are already in X_closure ): c. Add
all attributes in B to X_closure . (This effectively applies the transitivity rule implicitly and ensures we discover
all derivable attributes).

Dry run example: Relation R(A, B, C, D, E) Functional Dependencies F = { A -> B, BC -> D, A -> C,
D -> E } Find A+ (closure of A ).

1. Initialize X_closure = {A} .

2. Iteration 1:
FD A -> B : A is in X_closure . Add B . X_closure = {A, B} .

FD BC -> D : B is in X_closure , but C is not. Skip.

FD A -> C : A is in X_closure . Add C . X_closure = {A, B, C} .

FD D -> E : D is not in X_closure . Skip. (Note: The order of processing FDs can affect how quickly
X_closure grows, but not the final result.)

3. Iteration 2:
FD A -> B : A is in X_closure . B is already in X_closure . No change.

FD BC -> D : B and C are both in X_closure . Add D . X_closure = {A, B, C, D} .

FD A -> C : A is in X_closure . C is already in X_closure . No change.

FD D -> E : D is in X_closure . Add E . X_closure = {A, B, C, D, E} .

4. Iteration 3:
Go through all FDs again. No new attributes are added to X_closure .

5. X_closure did not change in Iteration 3. Stop.

[Link] Page 28 of 159

 Therefore, A+ = {A, B, C, D, E} .

Pseudocode:

FUNCTION compute_closure(attributes_X, functional_dependencies_F):

closure = attributes_X // Initialize closure with the given attributes
changed = TRUE

WHILE changed:
changed = FALSE
FOR EACH fd IN functional_dependencies_F:
lhs = fd.left_hand_side
rhs = fd.right_hand_side

IF lhs IS SUBSET OF closure: // Check if all attributes in LHS are in closu

old_closure_size = SIZE(closure)
ADD ALL attributes from rhs TO closure
IF SIZE(closure) > old_closure_size:
changed = TRUE
RETURN closure

Code (Conceptual): Imagine we represent attribute sets as Set objects (e.g., HashSet in Java, set in Python).
Functional dependencies can be objects or tuples like (lhs_set, rhs_set) .

A conceptual implementation would involve:

1. Initializing a currentClosure set with the input attributes_X .

2. Entering a while loop that continues as long as currentClosure changes in an iteration.

3. Inside the loop, for each (lhs, rhs) functional dependency in functional_dependencies_F : a. Check if
lhs is a subset of currentClosure . This can be done by iterating through lhs attributes and checking if
each is present in currentClosure . b. If it is a subset, iterate through rhs attributes and add any new
attributes to currentClosure . c. If any attribute was added, set a changed flag to true to ensure another
iteration.

4. Return currentClosure once the loop terminates (no changes were made in an entire pass).

Algorithm 2: Finding Candidate Keys

Problem statement: Given a relation schema R and a set of functional dependencies F , find all candidate keys for
R . A candidate key is a minimal superkey. A superkey is a set of attributes K such that K+ contains all attributes of
R . Minimal means no proper subset of K is also a superkey.

Step-by-step algorithm:

1. Identify initial candidate keys: a. Start with a set of attributes candidate_sets that could potentially be
candidate keys. Initially, this set might contain all attributes of R . b. For each X in candidate_sets : i.
Compute X+ using Algorithm 1. ii. If X+ contains all attributes of R , then X is a superkey.

2. Filter for minimality: a. From the set of identified superkeys, remove any superkey S if there exists another
superkey S' such that S' is a proper subset of S . b. The remaining superkeys are the candidate keys.

A more systematic approach for finding all candidate keys:

1. Partition attributes R into three sets:

LHS_Only : Attributes appearing only on the LHS of FDs.

[Link] Page 29 of 159

 RHS_Only : Attributes appearing only on the RHS of FDs.

Both : Attributes appearing on both sides.

Neither : Attributes appearing on neither side.

2. Initialize current_candidate_keys with LHS_Only and Neither attributes. (These are part of any
candidate key).

3. If current_candidate_keys+ contains all attributes of R , then current_candidate_keys is a candidate

key (and potentially the only candidate key if no Both attributes are needed).

4. Otherwise, iterate through subsets of Both attributes, adding them to current_candidate_keys , and
compute the closure for each combination. a. Start with current_candidate_keys . b. For each attribute B in
Both : i. Create a new set K_test = current_candidate_keys U {B} . ii. Compute K_test+ . If
K_test+ covers R , add K_test to a list of potential superkeys. c. Continue adding attributes from Both in
combinations (e.g., B1, B2 , then B1, B2, B3 , etc.) until all attributes of R are covered or all combinations
are exhausted.

5. After finding all superkeys, filter them to retain only the minimal ones (no proper subset is also a superkey).

Dry run example: Relation R(A, B, C, D, E) Functional Dependencies F = { A -> BC, B -> D, CD -> E
}

1. Analyze attributes:
LHS_Only: {A} (A determines B and C, but is not determined by anything)

RHS_Only: {E} (E is determined by CD, but determines nothing)

Both: {B, C, D} (B is determined by A and determines D; C is determined by A and is part of CD; D is

determined by B and is part of CD)

Neither: {}

2. Initial set of essential attributes: K_base = {A} .

3. Compute K_base+ = A+ :
A+ starts as {A} .

A -> BC : Add B, C . A+ = {A, B, C} .

B -> D : B in A+ . Add D . A+ = {A, B, C, D} .

CD -> E : C and D in A+ . Add E . A+ = {A, B, C, D, E} .

A+ covers R . So, A is a superkey.

4. Since A is the only attribute in K_base and it's a superkey, A is a candidate key.

Consider another example where Both attributes are critical: Relation R(A, B, C, D) Functional Dependencies F
= { AB -> C, C -> D }

1. Analyze attributes:
LHS_Only: {A, B}

RHS_Only: {D}

Both: {C}

Neither: {}

2. Initial set of essential attributes: K_base = {A, B} .

3. Compute (A, B)+ :

(A, B)+ starts as {A, B} .

[Link] Page 30 of 159

 AB -> C : A, B in (A, B)+ . Add C . (A, B)+ = {A, B, C} .

C -> D : C in (A, B)+ . Add D . (A, B)+ = {A, B, C, D} .

(A, B)+ covers R . So {A, B} is a superkey.

4. Check minimality: Is {A} a superkey? A+ = {A} (does not cover R). Is {B} a superkey? B+ = {B} (does not
cover R).

5. Therefore, {A, B} is a candidate key. (In this simple case, it's the only one).

Example with multiple candidate keys: Relation R(A, B, C, D) Functional Dependencies F = { A -> B, B ->
C, D -> A }

1. Analyze attributes:
LHS_Only: {D} (D determines A)

RHS_Only: {B, C} (B determined by A, C determined by B)

Both: {A} (A determines B, is determined by D)

Neither: {}

2. Initial set of essential attributes: K_base = {D} .

3. Compute D+ :
D+ starts as {D} .

D -> A : Add A . D+ = {D, A} .

A -> B : Add B . D+ = {D, A, B} .

B -> C : Add C . D+ = {D, A, B, C} .

D+ covers R . So {D} is a superkey.

4. Is {D} minimal? Yes, it's a single attribute. So {D} is a candidate key.

Are there others? The Both set is {A} . What if we try A as a starting point? Compute A+ :

A+ starts as {A} .

A -> B : Add B . A+ = {A, B} .

B -> C : Add C . A+ = {A, B, C} .

A+ does not cover R (missing D ). So A is not a candidate key.

This systematic process involves generating all possible combinations of attributes (or starting with the essential
attributes and adding from "Both"), checking their closure, and then filtering for minimality. For larger schemas, this can
be computationally intensive.

Pseudocode:

FUNCTION find_candidate_keys(relation_schema_R, functional_dependencies_F):

all_attributes = SET OF ALL ATTRIBUTES IN relation_schema_R
candidate_keys = EMPTY LIST

// 1. Determine essential attributes (attributes only on LHS, or not on any RHS)

lhs_attributes = UNION OF ALL LHS OF FDs IN F
rhs_attributes = UNION OF ALL RHS OF FDs IN F
must_be_in_key = SET OF ATTRIBUTES IN all_attributes NOT IN rhs_attributes

// 2. Generate potential key candidates by combining must_be_in_key with subsets of

// (For simplicity, this pseudocode will try combinations starting from must_be_

[Link] Page 31 of 159

 // and expanding with attributes that appear on both sides of FDs)

// Let's refine the approach:

// Start with combinations of attributes. A brute-force but correct approach.
// Or, more efficiently, start with 'must_be_in_key' and incrementally add 'both_si

// Identify attributes that appear on LHS but not RHS (potential starting points fo
// Identify attributes that appear on RHS but not LHS (cannot be sole key)
// Identify attributes that appear on both (may or may not be part of key)
// Identify attributes that appear on neither (must be part of key if not determine

// A better approach for the general case:

// Initialize potential_keys with the set of 'must_be_in_key'
// If must_be_in_key+ covers all_attributes, then it's a candidate key.
// Otherwise, iterate through subsets of attributes that appear on 'both' sides,
// adding them to must_be_in_key and checking closure.

// Simpler, but potentially less efficient: generate all subsets, then filter.
// For 'n' attributes, there are 2^n subsets.

// Let's go with a more practical iterative approach:

// Initialize potential_superkeys with attributes that are not determined by any ot
// Then, progressively add other attributes and check closure.

// A standard approach:
// List of all attributes that appear on the RHS of any FD
determined_attributes = UNION of all RHSs in F

// Attributes that are definitely part of any candidate key (unless determined by o
seed_key_parts = all_attributes - determined_attributes

potential_superkeys = SET containing only seed_key_parts // Start with the minimum

// Iteratively build larger superkeys

FOR k FROM 1 TO (NUMBER OF ATTRIBUTES IN all_attributes - SIZE(seed_key_parts)):
new_potential_superkeys = EMPTY SET
FOR EACH current_set IN potential_superkeys:
FOR EACH attribute A IN (all_attributes - current_set): // Try adding attri
test_set = current_set UNION {A}
IF compute_closure(test_set, F) == all_attributes:
ADD test_set TO new_potential_superkeys
ADD ALL new_potential_superkeys TO potential_superkeys

// Filter out non-minimal superkeys

final_candidate_keys = EMPTY LIST
FOR EACH sk1 IN potential_superkeys:
is_minimal = TRUE
FOR EACH sk2 IN potential_superkeys:
IF sk1 != sk2 AND sk2 IS PROPER SUBSET OF sk1:
is_minimal = FALSE
BREAK
IF is_minimal:
ADD sk1 TO final_candidate_keys

[Link] Page 32 of 159

 RETURN final_candidate_keys

Note: The pseudocode for find_candidate_keys is more involved. A common strategy involves:

1. Start with keys_to_check = { {A} for A in R } .

2. Expand keys_to_check by adding combinations of attributes.

3. For each K in keys_to_check , compute K+ . If K+ == R , K is a superkey.

4. Filter superkeys for minimality. The pseudocode above is a simplified version; a robust algorithm would need careful
handling of generating combinations and avoiding duplicates.

Code (Conceptual): Finding candidate keys is generally more complex than closure. One conceptual approach involves:

1. Identify essential_attributes : attributes that do not appear on the RHS of any FD. These must be part of any
candidate key.

2. Identify non_essential_attributes : attributes that appear on the RHS of at least one FD.

3. Initialize candidate_keys_found as an empty list.

4. Create a list potential_keys starting with just essential_attributes . If

compute_closure(essential_attributes, F) covers all relation attributes, then
essential_attributes is a candidate key.

5. If not, iterate through subsets of non_essential_attributes (from size 1 up to

|non_essential_attributes| ). a. For each subset S of non_essential_attributes : b. Form
test_key = essential_attributes UNION S . c. Compute test_key_closure =
compute_closure(test_key, F) . d. If test_key_closure contains all attributes of the relation R : i.
test_key is a superkey. ii. Check if test_key is minimal: iterate through already found
candidate_keys_found . If test_key is a superset of any existing candidate key, it's not minimal, so discard
it. iii. Also, remove any existing candidate_keys_found that are supersets of test_key (because
test_key is smaller and also a candidate). iv. Add test_key to candidate_keys_found .

6. Return candidate_keys_found . Generating all subsets can be done recursively or iteratively using bit
manipulation.

Algorithm 3: Computing Minimal Cover (Canonical Cover)

Problem statement: Given a set of functional dependencies F , find an equivalent set of FDs F_c (called the minimal
cover) such that:

1. Every FD in F_c has a single attribute on the RHS. (This is called canonical form).

2. No FD in F_c is redundant (i.e., if we remove any FD from F_c , the closure F_c+ changes).

3. No attribute in the LHS of any FD in F_c is redundant (i.e., if we remove any attribute from the LHS of any FD, the
closure F_c+ changes).

Step-by-step algorithm:

1. Split RHSs: Replace any FD X -> YZ with X -> Y and X -> Z . Repeat until all FDs have a single attribute on
their RHS. Let this new set be F_prime .

2. Eliminate redundant FDs: a. For each FD fd (e.g., X -> A ) in F_prime : b. Temporarily remove fd from
F_prime to get F_temp = F_prime - {fd} . c. Compute X+ with respect to F_temp (using Algorithm 1).
d. If A is in X+ , then fd is redundant and can be permanently removed from F_prime . Continue this process
until no more FDs can be removed.

[Link] Page 33 of 159

 3. Eliminate redundant attributes from LHSs: a. For each FD fd (e.g., X -> A ) in the current F_prime : b. For
each attribute B in X : c. Temporarily replace X with X - {B} to form X_prime = X - {B} . d. Compute
X_prime+ with respect to F_prime (the full set, not just F_prime without fd ). e. If A is in X_prime+ ,
then B is redundant in X . Replace X -> A with (X - {B}) -> A . f. Repeat this for all attributes in X and
all FDs until no more attributes can be removed from any LHS.

Dry run example: Relation R(A, B, C, D) Functional Dependencies F = { AB -> C, A -> B, B -> D, D
-> A }

1. Split RHSs: All FDs already have a single attribute on RHS. F_prime = { AB -> C, A -> B, B -> D, D ->
A }.

2. Eliminate redundant FDs:

Consider AB -> C :

F_temp = { A -> B, B -> D, D -> A } .

Compute (AB)+ with respect to F_temp :

(AB)+ starts as {A, B} .

A -> B is in F_temp . A is in (AB)+ . B is already in (AB)+ .

B -> D is in F_temp . B is in (AB)+ . Add D . (AB)+ = {A, B, D} .

D -> A is in F_temp . D is in (AB)+ . A is already in (AB)+ .

Final (AB)+ = {A, B, D} .

C is NOT in (AB)+ . So AB -> C is NOT redundant. Keep it.

Consider A -> B :

F_temp = { AB -> C, B -> D, D -> A } .

Compute A+ with respect to F_temp :

A+ starts as {A} .

D -> A is in F_temp . But D is not in A+ .

AB -> C is in F_temp . But B is not in A+ .

B -> D is in F_temp . But B is not in A+ .

Final A+ = {A} .

B is NOT in A+ . So A -> B is NOT redundant. Keep it. (Wait, let's recheck the logic. X -> A is
redundant if A is in X+ derived from F_prime - {X -> A} ). Corrected logic for A -> B redundancy
check:

F_temp = { AB -> C, B -> D, D -> A } .

Compute A+ using F_temp .

A+ = {A}

No FD in F_temp starts with A or an attribute derivable from A .

So A+ (with respect to F_temp ) is just {A} .

Since B (RHS of A -> B ) is not in {A} , A -> B is NOT redundant. Keep it.

Consider B -> D :

F_temp = { AB -> C, A -> B, D -> A } .

[Link] Page 34 of 159

 Compute B+ with respect to F_temp :
B+ starts as {B} .

A -> B is in F_temp . No.

AB -> C is in F_temp . No.

D -> A is in F_temp . No.

Final B+ = {B} .

D is NOT in B+ . So B -> D is NOT redundant. Keep it.

Consider D -> A :

F_temp = { AB -> C, A -> B, B -> D } .

Compute D+ with respect to F_temp :

D+ starts as {D} .

No FD in F_temp starts with D or an attribute derivable from D .

Final D+ = {D} .

A is NOT in D+ . So D -> A is NOT redundant. Keep it.

All FDs seem essential. Let F_prime remain { AB -> C, A -> B, B -> D, D -> A } .

3. Eliminate redundant attributes from LHSs:

Consider AB -> C :

Is A redundant in AB ? Test B -> C .

Compute B+ with respect to F_prime = { AB -> C, A -> B, B -> D, D -> A } .

B+ starts as {B} .

B -> D : Add D . B+ = {B, D} .

D -> A : Add A . B+ = {B, D, A} .

A -> B : A is in B+ . B already there.

AB -> C : A, B are in B+ . Add C . B+ = {B, D, A, C} .

C IS in B+ . So A is redundant in AB . Replace AB -> C with B -> C .

F_prime is now { B -> C, A -> B, B -> D, D -> A } .

Consider B redundant in B (from B -> C )? No, single attribute LHS cannot have redundant attributes.

Consider A -> B : LHS is single attribute A . No redundancy.

Consider B -> D : LHS is single attribute B . No redundancy.

Consider D -> A : LHS is single attribute D . No redundancy.

Final minimal cover F_c = { B -> C, A -> B, B -> D, D -> A } .

Pseudocode:

FUNCTION compute_minimal_cover(functional_dependencies_F):
// Step 1: Split RHSs
F_prime = EMPTY LIST
FOR EACH fd IN functional_dependencies_F:

[Link] Page 35 of 159

 lhs = fd.left_hand_side
FOR EACH attribute_on_rhs IN fd.right_hand_side:
ADD NEW FD (lhs -> attribute_on_rhs) TO F_prime

// Step 2: Eliminate redundant FDs

// Create a copy to iterate and modify
current_F = LIST FROM F_prime
FOR EACH fd_to_check IN current_F:
// Temporarily remove fd_to_check
temp_F = current_F - {fd_to_check}

lhs_to_check = fd_to_check.left_hand_side
rhs_to_check = fd_to_check.right_hand_side // Should be single attribute due to

// Compute closure of LHS with remaining FDs

closure_of_lhs = compute_closure(lhs_to_check, temp_F)

IF rhs_to_check IS SUBSET OF closure_of_lhs: // Check if the single RHS attribu

REMOVE fd_to_check FROM F_prime // Permanently remove from the actual set b

// Step 3: Eliminate redundant attributes from LHSs

// Iterate through FDs in F_prime (which is now reduced)
FOR EACH fd IN F_prime:
lhs = fd.left_hand_side
rhs = fd.right_hand_side // Single attribute

IF SIZE(lhs) > 1: // Only check if LHS has multiple attributes

FOR EACH attribute_in_lhs_to_remove IN lhs:
// Create a test LHS by removing one attribute
test_lhs = lhs - {attribute_in_lhs_to_remove}

// Compute closure of the test_lhs using the full F_prime set

closure_of_test_lhs = compute_closure(test_lhs, F_prime)

IF rhs IS SUBSET OF closure_of_test_lhs:

// Attribute_in_lhs_to_remove is redundant, update the FD's LHS
fd.left_hand_side = test_lhs
lhs = test_lhs // Update current lhs for next iteration if needed
BREAK // Restart inner loop for this FD's new LHS or continue caref
// A safer approach might be to collect changes and apply aft
RETURN F_prime

Code (Conceptual): Implementing minimal cover involves:

1. Representing FDs as objects or pairs of sets.

2. split_rhs_fds : Iterate through FDs. If rhs has multiple attributes, create new FDs for each single attribute on
the rhs and replace the original.

3. remove_redundant_fds : a. Create a temporary list current_fds from the split_rhs_fds . b. Iterate

using a for loop (or while loop with a changed flag) over current_fds . c. For each fd ( X -> A ) in
current_fds : i. Create temp_fds = current_fds without fd . ii. Compute closure(X, temp_fds) .
iii. If A is in the closure , then fd is redundant. Remove fd from current_fds .

4. remove_redundant_lhs_attributes : a. Iterate through each fd ( X -> A ) in the now reduced

current_fds . b. If X has more than one attribute: i. Iterate through each attribute B in X . ii. Create temp_X

[Link] Page 36 of 159

 = X without B . iii. Compute closure(temp_X, current_fds) . (Note: use the full current_fds here, not
current_fds without the current fd ). iv. If A is in closure , then B is redundant. Modify the fd 's X to
temp_X . Break from inner loop and re-evaluate this FD's LHS again, or mark for next pass. This step requires
careful iteration or recursion to ensure all possible reductions are made.

5. Return the final current_fds .

Algorithm 4: Checking Equivalence of FD Sets

Problem statement: Given two sets of functional dependencies, F and G , determine if they are equivalent (i.e., F+
= G+ ).

Step-by-step algorithm: Two sets of FDs F and G are equivalent if and only if F covers G and G covers F .

1. Check if F covers G : a. For each functional dependency gd (e.g., X -> Y ) in G : b. Compute X+ with
respect to F (using Algorithm 1, where F is the set of FDs). c. If Y is NOT a subset of X+ , then F does not
cover G . Return false .

2. Check if G covers F : a. For each functional dependency fd (e.g., P -> Q ) in F : b. Compute P+ with
respect to G (using Algorithm 1, where G is the set of FDs). c. If Q is NOT a subset of P+ , then G does not
cover F . Return false .

3. If both checks pass, then F and G are equivalent. Return true .

Dry run example: Relation R(A, B, C) F = { A -> B, B -> C } G = { A -> C, A -> B }

1. Check if F covers G :

For A -> C (from G ):

Compute A+ with respect to F = { A -> B, B -> C } .

A+ starts as {A} .

A -> B : Add B . A+ = {A, B} .

B -> C : Add C . A+ = {A, B, C} .

Is C (RHS of A -> C ) a subset of {A, B, C} ? Yes.

For A -> B (from G ):

Compute A+ with respect to F = { A -> B, B -> C } .

(Already computed as {A, B, C} ).

Is B (RHS of A -> B ) a subset of {A, B, C} ? Yes.

Result: F covers G .

2. Check if G covers F :

For A -> B (from F ):

Compute A+ with respect to G = { A -> C, A -> B } .

A+ starts as {A} .

A -> C : Add C . A+ = {A, C} .

A -> B : Add B . A+ = {A, C, B} .

Is B (RHS of A -> B ) a subset of {A, C, B} ? Yes.

For B -> C (from F ):

Compute B+ with respect to G = { A -> C, A -> B } .

[Link] Page 37 of 159

 B+ starts as {B} .

No FD in G has B as a determinant or part of a determinant that can be derived from B .

Final B+ = {B} .

Is C (RHS of B -> C ) a subset of {B} ? No.

Result: G does NOT cover F .

Conclusion: F and G are NOT equivalent.

Pseudocode:

FUNCTION check_fd_equivalence(F_set, G_set):

// Check if F covers G
FOR EACH gd IN G_set:
lhs_g = gd.left_hand_side
rhs_g = gd.right_hand_side
closure_of_lhs_g_using_F = compute_closure(lhs_g, F_set)
IF rhs_g IS NOT SUBSET OF closure_of_lhs_g_using_F:
RETURN FALSE // F does not cover G

// Check if G covers F
FOR EACH fd IN F_set:
lhs_f = fd.left_hand_side
rhs_f = fd.right_hand_side
closure_of_lhs_f_using_G = compute_closure(lhs_f, G_set)
IF rhs_f IS NOT SUBSET OF closure_of_lhs_f_using_G:
RETURN FALSE // G does not cover F

RETURN TRUE // Both F covers G and G covers F

Code (Conceptual): This operation directly uses the compute_closure function.

1. Define a helper function covers(set_A_fds, set_B_fds) : a. For each FD (lhs_b, rhs_b) in

set_B_fds : b. Compute closure_result = compute_closure(lhs_b, set_A_fds) . c. If rhs_b is
not a subset of closure_result , return false . d. If all FDs in set_B_fds are covered, return true .

2. In check_fd_equivalence(F, G) : a. Return covers(F, G) AND covers(G, F) .

6. Complexity Analysis
Time complexity

1. Computing Closure of an Attribute Set (X+):

Let |R| be the number of attributes in the relation, |F| be the number of FDs, and L be the maximum
number of attributes in an LHS of an FD.

In each iteration of the while loop, we iterate through all FDs ( |F| ).

Checking lhs IS SUBSET OF closure takes O(L) (or O(|R|) in worst case if L is large).

Adding rhs to closure takes O(L) (or O(|R|) ).

In the worst case, X_closure grows by one attribute in each outer iteration. So, there can be |R| iterations.

Worst-case time complexity: O(|R| * |F| * |R|) = O(|R|^2 * |F|) .

[Link] Page 38 of 159

 (More precise analysis: O(|F| * |R|) if attributes are managed efficiently like bitsets, where subset check
and union are faster. The |R| factor comes from the number of possible times closure can grow, up to
|R| attributes.)

2. Finding Candidate Keys:

The brute-force approach of generating all 2^|R| subsets of attributes and computing closure for each:
O(2^|R| * |R|^2 * |F|) . This is exponential and prohibitive for large |R| .

More optimized algorithms exist (e.g., those using attribute classification or iterative refinement) but are still
generally exponential in the worst case, or polynomial in cases where the number of candidate keys is small. The
complexity depends heavily on the specific algorithm used and the structure of the FDs.

Best Case: If must_be_in_key+ covers R , O(|R|^2 * |F|) .

Worst Case: For k candidate keys, and 2^|R| subsets to check, it can be O(2^|R| * |R|^2 * |F|) .

3. Computing Minimal Cover:

Step 1 (Split RHSs): O(|F| * |R|) - Iterate through FDs, and for each RHS, iterate through attributes.

Step 2 (Eliminate redundant FDs):

Iterate through each FD in F_prime ( |F_prime| times).

Inside, compute closure ( O(|R|^2 * |F_prime|) ).

Worst-case: O(|F_prime| * |R|^2 * |F_prime|) = O(|R|^2 * |F_prime|^2) .

Step 3 (Eliminate redundant attributes from LHSs):

Iterate through each FD in F_prime ( |F_prime| times).

For each attribute in LHS ( O(|R|) times).

Inside, compute closure ( O(|R|^2 * |F_prime|) ).

Worst-case: O(|F_prime| * |R| * |R|^2 * |F_prime|) = O(|R|^3 * |F_prime|^2) .

Overall worst-case: O(|R|^3 * |F|^2) .

4. Checking Equivalence of FD Sets:

O(|G| * Closure_Complexity + |F| * Closure_Complexity) = O((|F| + |G|) * |R|^2 *

(|F| + |G|)) = O((|F| + |G|)^2 * |R|^2) .

Essentially, it's two runs of checking if one set covers the other, each involving multiple closure computations.

Space complexity

For all algorithms, storing the attributes and functional dependencies requires O(|R| + |F| * |R|) space (for
LHS/RHS of FDs), representing attribute sets.

Intermediate sets like X_closure take O(|R|) space.

If using bitsets for attribute representation, it's O(|R|) for each set.

Comparison with alternatives

For Closure, the described iterative algorithm is standard and relatively efficient. No significantly better general
algorithm exists as it fundamentally requires exploring all dependencies.

For Candidate Keys, the problem is NP-hard. Brute-force checking of all subsets is often the starting point, but
practical implementations use heuristics and optimizations (like starting with essential attributes) to reduce the
search space. No polynomial-time alternative for the worst-case scenario.

For Minimal Cover, the three-step process is a standard textbook algorithm. Variations exist in the order of steps or
internal optimizations for closure computation, but the core logic remains similar.

[Link] Page 39 of 159

 7. Examples
Solved Problem (Small): Closure of an Attribute Set

Problem: Given relation R(A, B, C, D) and FDs F = {A -> B, B -> C} , find A+ .

Solution:
1. Initialize A_closure = {A} .

2. Iteration 1:
A -> B : A is in A_closure . Add B . A_closure = {A, B} .

B -> C : B is in A_closure . Add C . A_closure = {A, B, C} .

3. Iteration 2:
No new attributes can be added. A_closure remains {A, B, C} .

4. Stop.

Answer: A+ = {A, B, C} .

Solved Problem (Medium): Finding Candidate Keys

Problem: Given relation R(P, Q, R, S, T) and FDs F = {PQ -> R, R -> S, S -> T} , find all
candidate keys.

Solution:
1. Analyze attributes:
LHS_Only: {P, Q} (P and Q only appear on LHS)

RHS_Only: {S, T} (S and T only appear on RHS)

Both: {R} (R is determined by PQ, determines S)

Neither: {}

2. Initial candidate set: Start with K_base = {P, Q} .

3. Compute closure of K_base = {P, Q} :

{P, Q}+ starts as {P, Q} .

PQ -> R : P, Q are in {P, Q}+ . Add R . K_closure = {P, Q, R} .

R -> S : R is in K_closure . Add S . K_closure = {P, Q, R, S} .

S -> T : S is in K_closure . Add T . K_closure = {P, Q, R, S, T} .

K_closure contains all attributes of R . So {P, Q} is a superkey.

4. Check minimality:
Is {P} a superkey? P+ = {P} (does not cover R ).

Is {Q} a superkey? Q+ = {Q} (does not cover R ).

Since no proper subset of {P, Q} is a superkey, {P, Q} is a candidate key.

5. Since all attributes in R are covered by attributes in K_base and those appearing on Both sides, and
{P,Q} is minimal, it is the only candidate key.

Answer: The only candidate key is {P, Q} .

Solved Problem (Complex): Computing Minimal Cover

Problem: Given relation R(A, B, C, D) and FDs F = {A -> B, B -> C, A -> C, C -> D} . Find a
minimal cover for F .

[Link] Page 40 of 159

 Solution:

1. Split RHSs: All FDs already have a single attribute on the RHS. F_prime = {A -> B, B -> C, A -> C, C
-> D} .

2. Eliminate redundant FDs:

Consider A -> B :
F_temp = {B -> C, A -> C, C -> D} .

A+ with respect to F_temp :

A+ starts {A} .

A -> C : Add C . A+ = {A, C} .

C -> D : Add D . A+ = {A, C, D} .

B (RHS of A -> B ) is NOT in A+ . So A -> B is NOT redundant. Keep it.

Consider B -> C :
F_temp = {A -> B, A -> C, C -> D} .

B+ with respect to F_temp :

B+ starts {B} .

No FD in F_temp has B as determinant (or derivable from B ).

B+ = {B} .

C (RHS of B -> C ) is NOT in B+ . So B -> C is NOT redundant. Keep it.

Consider A -> C :
F_temp = {A -> B, B -> C, C -> D} .

A+ with respect to F_temp :

A+ starts {A} .

A -> B : Add B . A+ = {A, B} .

B -> C : Add C . A+ = {A, B, C} .

C (RHS of A -> C ) IS in A+ . So A -> C IS redundant. Remove it.

F_prime is now {A -> B, B -> C, C -> D} .

Consider C -> D (with the new F_prime ):

F_temp = {A -> B, B -> C} .

C+ with respect to F_temp : C+ = {C} .

D (RHS of C -> D ) is NOT in C+ . So C -> D is NOT redundant. Keep it.

Current F_prime = {A -> B, B -> C, C -> D} . All FDs are essential.

3. Eliminate redundant attributes from LHSs:

All FDs have single-attribute LHSs. No attributes to remove.

Answer: Minimal cover F_c = {A -> B, B -> C, C -> D} .

8. Common Mistakes & Edge Cases

Where students go wrong:

1. Confusing FD notation: Misinterpreting X -> Y as Y -> X or other meanings.

[Link] Page 41 of 159

 2. Incorrectly applying Armstrong's Axioms: Especially transitivity and augmentation. Forgetting that augmentation
adds to both sides, not just the LHS.

3. Calculating closure incorrectly: Missing steps in the iterative process, or stopping too early. This is the most
common source of errors.

4. Missing candidate keys: Not systematically checking all relevant combinations, especially when attributes appear
on both LHS and RHS of FDs.

5. Not verifying minimality: Forgetting to ensure that no proper subset of a candidate key is also a superkey.

6. Mistakes in Minimal Cover:

Incorrectly identifying redundant FDs.

Incorrectly identifying redundant attributes in LHS (e.g., confusing X -> Y and X - {A} -> Y for the
closure calculation in step 3). It's compute_closure(X_minus_A, F_prime_full_set) not
F_prime_without_current_FD .

7. Overlooking Trivial FDs: While trivial FDs aren't usually important for normalization, they are valid and can be
derived. When computing F+ , trivial FDs are part of it.

Special cases:

1. Empty set of FDs: If F = ∅ , then X+ = X for any X . The only FDs are trivial ones. The only candidate key is the
entire relation schema R .

2. All attributes are unique (e.g., all attributes form a primary key): If R(A, B, C) and ABC -> A, ABC ->
B, ABC -> C , the only non-trivial FDs may be ABC -> {rest_of_attributes} . The candidate key is the
combination of all attributes.

3. Universal relation as candidate key: If no subset of attributes can determine all others, the entire set of attributes
of R forms the only candidate key.

4. Overlapping FDs: When multiple FDs refer to the same attributes or have shared attributes, carefully applying
Armstrong's axioms is crucial.

5. Attributes not part of any FD: Attributes that appear in R but are not part of any LHS or RHS of an FD in F must
be part of any candidate key (unless they are trivially determined by the key itself). They can't be determined by
anything else.

9. Real-Life Applications
Functional Dependencies are not just theoretical constructs; they are essential for practical database management:

1. Database Design (Core Application):

Normalization: As previously mentioned, FDs are the foundation for defining Normal Forms (2NF, 3NF, BCNF, 4NF,
5NF). Database designers use FDs to decompose relations into a set of smaller, well-structured tables, eliminating
redundancy and anomalies.

Identifying Primary and Candidate Keys: FDs are used to systematically determine the unique identifiers
(candidate keys) for tables, which are then chosen as primary keys.

Schema Refinement: FDs guide the process of evaluating and refining a database schema to ensure it accurately
reflects business rules and data constraints.

2. Data Quality and Integrity:

FDs act as powerful integrity constraints. When data is inserted or updated, the database system can use the defined
FDs to check for violations, ensuring that the data remains consistent and accurate according to the real-world rules
it represents.

[Link] Page 42 of 159

 Example: If EmployeeID -> EmployeeName is an FD, the system can prevent an update that tries to assign two
different names to the same EmployeeID .

3. Data Warehousing and ETL (Extract, Transform, Load):

In data warehousing, data is often consolidated from various operational systems. Understanding FDs in the source
data is crucial for cleaning, transforming, and integrating data into the data warehouse, ensuring consistency across
different sources.

FDs help in identifying and resolving inconsistencies or missing relationships before loading data.

4. Query Optimization:

While not explicitly used by optimizers as FDs directly, the underlying logical structure defined by FDs helps
developers write more efficient queries. Knowing that Student_ID uniquely determines Student_Name can
guide the choice of join conditions or help avoid unnecessary joins if the required information is already available
from a primary key.

In some advanced systems, FDs might be used implicitly to infer properties of joins or projections.

5. Application Development:

Application developers rely on the FDs defined in the database schema to understand data relationships and
implement business logic correctly. For instance, an application might rely on ProductID -> ProductName to
display product names based on product IDs.

FDs inform the design of user interfaces and data entry forms, ensuring that users are prompted for the correct
unique identifiers and that data entered adheres to established rules.

10. Practice Problems

Easy

1. Relation R(A, B, C, D) with FDs F = {A -> B, B -> C} . Is A -> C an FD in F+ ?

2. Given R(P, Q, R, S) and F = {P -> Q, R -> S} . Find P+ .

3. In relation Employee(EmpID, Name, DeptID, DeptName) , which of the following is most likely an FD? a.
Name -> EmpID b. EmpID -> DeptName c. DeptName -> DeptID d. DeptID -> DeptName

Medium

1. Relation R(A, B, C, D, E) with FDs F = {AB -> C, C -> D, D -> E} . Find all candidate keys for R .

2. Given R(W, X, Y, Z) and F = {W -> X, XY -> Z} . Check if WY -> Z is in F+ .

3. Consider R(A, B, C, D, E) and F = {A -> B, B -> C, A -> C, CD -> E} . Find a minimal cover for
F.

Hard

1. Relation R(A, B, C, D, E, F) and F = {A -> BC, E -> F, C -> D, ABE -> CD} . Find all candidate
keys for R .

2. Given F = {AB -> C, B -> D, D -> E, A -> D} and G = {A -> B, B -> C, C -> D, D -> E} .
Are F and G equivalent?

3. Relation R(S, T, U, V, W) and F = {S -> TU, T -> VW, U -> S} . Find a minimal cover for F .

11. Summary / Key Points

[Link] Page 43 of 159

 Functional Dependency (FD): A constraint X -> Y where X uniquely determines Y . Essential for data integrity
and good database design.

Armstrong's Axioms:
Reflexivity: If Y ⊆ X , then X -> Y . (Trivial FDs)

Augmentation: If X -> Y , then XZ -> YZ . (Adding to both sides)

Transitivity: If X -> Y and Y -> Z , then X -> Z . (Indirect determination)

These three are sound and complete; all other FD inference rules can be derived from them (e.g., Union,
Decomposition, Pseudotransitivity).

Closure of an Attribute Set (X+): The set of all attributes functionally determined by X . Crucial for finding candidate
keys and checking FD validity.
Shortcut: Start with X , repeatedly add attributes B if there's an FD A -> B where A is already in the current
closure, until no more attributes can be added.

Candidate Key: A minimal superkey. A superkey is a set of attributes whose closure contains all attributes of the
relation.
Strategy: Identify essential attributes (not on RHS of any FD). Start key search from these. Use closure to test if a set
of attributes is a superkey, then filter for minimality.

Minimal Cover (Canonical Cover): An equivalent set of FDs that is minimal in three ways: single attribute RHS, no
redundant FDs, no redundant attributes in LHS.
Steps: 1. Split RHS. 2. Eliminate redundant FDs (using closure, test if X -> A is derivable from F - {X -> A} ).
3. Eliminate redundant LHS attributes (using closure, test if X - {B} -> A is derivable from the full current F ).

FD Equivalence: Two sets of FDs, F and G , are equivalent if F covers G and G covers F (i.e., every FD in G is
derivable from F , and every FD in F is derivable from G ).
Formula: F ≈ G if and only if G ⊆ F+ and F ⊆ G+ . (where F+ and G+ here refer to the closure of the set
of FDs). Practically, check each FD from one set against the closure generated by the other set.

Importance: FDs are the backbone of Normalization, preventing data anomalies, reducing redundancy, and enabling
robust database design.

Keys and Functional Dependencies

Review of Super Key, Candidate Key, Primary Key, and their relationship to functional dependencies in identifying and
determining attributes.

1. Introduction
Definition In the context of database management systems, particularly within relational databases, Keys and
Functional Dependencies (FDs) are fundamental concepts that underpin the process of database normalization.

Keys: An attribute or a set of attributes that uniquely identifies a tuple (row) in a relation (table). Keys are essential
for establishing relationships between tables and enforcing data integrity.

Functional Dependency (FD): A constraint between two sets of attributes in a relation. If A and B are sets of
attributes in a relation R, then A functionally determines B (denoted as A → B) if, for any two tuples in R, whenever
the values of A are identical, the values of B must also be identical. In simpler terms, if you know the value(s) of A,
you can uniquely determine the value(s) of B.

Why it is needed Keys and Functional Dependencies are crucial for several reasons:

[Link] Page 44 of 159

 1. Data Integrity: They help maintain the accuracy, consistency, and reliability of data. Keys enforce uniqueness and
referential integrity, while FDs capture inherent business rules and relationships within the data.

2. Reduced Redundancy: By understanding FDs, we can identify and eliminate redundant data, which is a primary goal
of database normalization. Redundancy leads to storage waste and potential update anomalies (insertion, deletion,
modification anomalies).

3. Improved Database Design: They guide the process of decomposing larger, less organized tables into smaller, well-
structured tables, ensuring that each table stores data about a single entity or relationship type.

4. Foundation for Normalization: FDs are the bedrock upon which normalization forms (1NF, 2NF, 3NF, BCNF, etc.)
are defined. Without identifying FDs, normalization is impossible.

Real-life Analogy: Imagine a library.

A Key is like the unique ISBN (International Standard Book Number) for each book. If you know the ISBN, you can
find that specific book on the shelf. It uniquely identifies the book.

A Functional Dependency is like the rule "ISBN → Title, Author, Publisher". If you know the ISBN of a book, you
automatically know its title, author, and publisher. The ISBN determines these other attributes. Similarly, "Author +
Title → ISBN" might not be true if different authors write different books with the same title or vice-versa, or if
different editions of the same book have different ISBNs.

Applications

Database Schema Design: Guiding the creation of efficient and robust relational schemas.

Normalization: The entire process of organizing tables to minimize data redundancy and improve data integrity.

Query Optimization: Understanding FDs can assist the database query optimizer in making more efficient execution
plans.

Data Auditing and Validation: Ensuring that data conforms to established business rules and constraints.

Data Integration: When combining data from multiple sources, FDs help in identifying and resolving conflicts and
redundancies.

2. Theory Explanation
In-depth explanation

Keys

A key is an attribute or a set of attributes that helps to uniquely identify a record (tuple) in a table (relation).

1. Super Key: A set of attributes that, when combined, can uniquely identify a tuple in a relation. It's any set of
attributes that contains a candidate key.
Example: In a Student table with attributes {StudentID, Name, Age, Course} , {StudentID,
Name} could be a Super Key because StudentID alone uniquely identifies a student, and adding Name
doesn't change that. {StudentID} is also a Super Key.

2. Candidate Key: A minimal Super Key. This means it's a Super Key, and if you remove any attribute from it, it ceases
to be a Super Key. A relation can have multiple candidate keys.
Example: For Student(StudentID, Name, SSN, Phone) , StudentID could be a Candidate Key. SSN
(Social Security Number) could also be a Candidate Key. If Name and Phone together uniquely identify a
student, then {Name, Phone} could also be a Candidate Key.

3. Primary Key (PK): The Candidate Key chosen by the database designer to uniquely identify tuples in a relation.
There can be only one Primary Key per table. It cannot contain NULL values (Entity Integrity constraint).
Example: From the Candidate Keys {StudentID, SSN, {Name, Phone}} , the designer might choose
StudentID as the Primary Key.

[Link] Page 45 of 159

 4. Alternate Key: Any Candidate Key that is not chosen as the Primary Key.
Example: If StudentID is the PK, then SSN and {Name, Phone} (if they are Candidate Keys) are Alternate
Keys.

5. Foreign Key (FK): An attribute or a set of attributes in one relation (the referencing relation) whose values match the
Primary Key or Candidate Key values in another relation (the referenced relation). Foreign Keys establish referential
integrity between tables, linking them together.
Example: In a CourseEnrollment table, StudentID could be a Foreign Key referencing the StudentID
(Primary Key) in the Student table.

Functional Dependencies (FDs)

An FD A → B implies that if two tuples have the same value for attribute(s) A, they must also have the same value for
attribute(s) B.

Determinant: The attribute(s) on the left-hand side (LHS) of the FD (A in A → B).

Dependent: The attribute(s) on the right-hand side (RHS) of the FD (B in A → B).

Types of Functional Dependencies:

1. Trivial Functional Dependency: An FD A → B is trivial if B is a subset of A. This is always true and provides no
new information.
Example: {StudentID, CourseID} → StudentID (because StudentID is part of {StudentID,
CourseID} ).

2. Non-trivial Functional Dependency: An FD A → B is non-trivial if B is not a subset of A. These dependencies

convey meaningful constraints.
Example: StudentID → StudentName (assuming StudentName is not part of StudentID ).

3. Completely Non-trivial Functional Dependency: An FD A → B is completely non-trivial if the intersection of A

and B is empty (A ∩ B = Ø).
Example: StudentID → StudentName (assuming StudentID and StudentName are distinct attributes).

Inference Rules (Armstrong's Axioms): These are a set of rules that allow us to infer (derive) new FDs from a given set
of FDs.

1. Reflexivity Rule: If B is a subset of A, then A → B. (This covers trivial FDs).

Example: {StudentID, CourseID} → StudentID

2. Augmentation Rule: If A → B, then A∪C → B∪C for any set of attributes C. (Adding attributes to the determinant
doesn't break the dependency).
Example: If StudentID → StudentName , then {StudentID, CourseID} → {StudentName,
CourseID} .

3. Transitivity Rule: If A → B and B → C, then A → C. (Dependencies can chain).

Example: If StudentID → DepartmentID and DepartmentID → DepartmentName , then StudentID
→ DepartmentName .

Derived Inference Rules (from Armstrong's Axioms):

Union Rule: If A → B and A → C, then A → B∪C.

Decomposition Rule: If A → B∪C, then A → B and A → C.

Pseudotransitivity Rule: If A → B and B∪C → D, then A∪C → D.

Attribute Closure (X+): The attribute closure of a set of attributes X (denoted as X+) is the set of all attributes that are
functionally determined by X, given a set of FDs. Finding the attribute closure is crucial for identifying candidate keys
and for checking the correctness of normal forms.

[Link] Page 46 of 159

 Diagrams/flowcharts

Hierarchy of Keys

Super Key
/ \
Candidate Key Candidate Key (not chosen as PK)
/ \
Primary Key Alternate Key

Functional Dependency Notation

Determinant Dependent
A -> B

Flowchart for Attribute Closure (X+)

Start
|
V
Initialize Result = X
|
V
Loop:
For each FD (A -> B) in FDs:
If A is a subset of Result:
Add B to Result
V
Any new attributes added to Result in this iteration?
| Yes
V
(Loop back to "For each FD...")
| No
V
Return Result
|
End

Step-by-step breakdown

How to find the Attribute Closure (X+) for a set of attributes X and a set of FDs F:
1. Initialize closure_set = X .

2. Repeat the following step until closure_set does not change in an iteration:
For each functional dependency A → B in F:
If A is a subset of closure_set (meaning all attributes in A are already in closure_set ):
Add all attributes in B to closure_set .

How to find Candidate Keys for a relation R with attributes ATT and a set of FDs F:
1. Identify LHS_only attributes (appear only on the left side of some FD), RHS_only attributes (appear only on the
right side of some FD), and BOTH attributes (appear on both sides). NONE attributes (appear on neither side) are
not relevant for determining other attributes, but must be covered by a key.

2. Any candidate key must include all LHS_only attributes. Let Key_candidate = LHS_only .

[Link] Page 47 of 159

 3. Calculate the attribute closure of Key_candidate ( Key_candidate +).
If Key_candidate + covers all attributes in ATT (i.e., Key_candidate + == ATT ), then
Key_candidate is a Candidate Key.

If Key_candidate + does not cover all attributes, then Key_candidate needs to be augmented. Try
adding attributes from the BOTH set one by one to Key_candidate and re-calculating the closure.

4. Systematically generate subsets of ATT (starting with LHS_only and progressively adding attributes from
BOTH and NONE if any) and calculate their closures.

5. A set of attributes K is a Candidate Key if:

K+ contains all attributes of ATT .

No proper subset of K has a closure that contains all attributes of ATT (i.e., K is minimal).

Simplified Strategy:
Start with K = LHS_only .

If K+ == ATT , then K is a candidate key.

Otherwise, iteratively add attributes from the BOTH set (and NONE set if present) to K to form K' , such
that K'+ == ATT . Check for minimality of these K' .

This process can be complex and involve checking many subsets.

3. Properties & Characteristics

Key properties

1. Uniqueness: A key's value (or combination of values for a composite key) must uniquely identify each tuple in the
relation. No two tuples can have the same key value.

2. Minimality (for Candidate/Primary Keys): For a Candidate Key, it must be irreducible. Removing any attribute from
the key will result in it no longer uniquely identifying tuples. Super Keys do not necessarily possess this property.

3. Non-Null (for Primary Key): A Primary Key cannot contain NULL values. This is known as the Entity Integrity
constraint. Foreign Keys can contain NULL values (if not part of a composite primary key) depending on the business
rules and if they allow for optional relationships.

4. Stability: Ideally, Primary Key values should not change over time, as this can affect related records through foreign
keys.

Advantages & disadvantages

Advantages
1. Data Integrity: Enforce rules that prevent inconsistent or incorrect data from being entered into the database (e.g.,
no duplicate primary keys, referential integrity for foreign keys).

2. Reduced Redundancy: By identifying FDs, we can design tables to store data about a single entity, minimizing
repeated information. This saves storage space and reduces the risk of update anomalies.

3. Improved Query Performance: Well-defined keys (especially Primary Keys) are often indexed by the DBMS, which
dramatically speeds up data retrieval and join operations. FDs provide a logical structure that helps in query
optimization.

4. Better Database Structure: Leads to clear, logical, and maintainable database schemas. Normalization, driven by
FDs, results in a robust design that is easier to understand and manage.

5. Data Consistency: Prevents anomalies during insert, update, and delete operations, ensuring the database remains
in a consistent state.

Disadvantages

[Link] Page 48 of 159

 1. Complexity in Design: Identifying all relevant FDs and candidate keys can be a complex and time-consuming task,
especially for large and intricate databases. Misidentifying them can lead to a suboptimal or incorrect schema.

2. Performance Overhead (for enforcement): While improving query performance, the enforcement of key
constraints (e.g., checking for uniqueness, referential integrity) adds a slight overhead to insert, update, and delete
operations.

3. Potential for Data Loss (in poor normalization): Over-normalization or incorrect decomposition based on FDs can
sometimes lead to difficulty in reconstructing the original data or even "lossy" joins, where information is lost or
spurious tuples are generated.

4. Rigidity: Strict adherence to FDs and normalization might sometimes lead to a highly fragmented schema with
many tables, increasing the complexity of queries (more joins) for certain applications, potentially impacting read
performance in very specific scenarios (though typically, the benefits outweigh this).

4. Mathematical / Logical Representation

Important formulas

Let R be a relation schema, and A, B, C, D be sets of attributes of R.

Functional Dependency: A → B

Reads: "A functionally determines B" or "B is functionally dependent on A".

Meaning: For any two tuples t1 and t2 in R, if t1[A] = t2[A] , then t1[B] = t2[B] .

Attribute Closure: X+

X+ = { A | X → A } (The set of all attributes functionally determined by X).

Armstrong's Axioms (Inference Rules for FDs):

1. Reflexivity: If B ⊆ A , then A → B .

2. Augmentation: If A → B , then A ∪ C → B ∪ C (for any C ).

3. Transitivity: If A → B and B → C , then A → C .

Derivations (of other inference rules from Armstrong's Axioms)

Armstrong's Axioms are sound (they don't generate invalid FDs) and complete (they can generate all valid FDs). Other
useful inference rules can be derived from them:

1. Union Rule: If A → B and A → C , then A → B ∪ C .

Derivation:
1. A → B (Given)

2. A → C (Given)

3. A ∪ A → B ∪ A (Augmentation on 1 with A=A, C=A) -> A → B ∪ A (Redundant, not useful here)

4. A ∪ A → B ∪ C (Augmentation on 1 with C, A ∪ C → B ∪ C )

5. A ∪ A → C ∪ B (Augmentation on 2 with B, A ∪ B → C ∪ B )

6. From 1: A → B . By Augmentation with C: A ∪ C → B ∪ C .

7. From 2: A → C . By Augmentation with B: A ∪ B → C ∪ B .

8. Let's use A ∪ B → B ∪ C and A ∪ C → C ∪ B .

9. More direct way:

A → B (Given)

[Link] Page 49 of 159

 A → C (Given)

From A → B , by Augmentation with A : A ∪ A → B ∪ A , which simplifies to A → B (useless).

Correct Augmentation: A → B implies A ∪ C → B ∪ C (by Augmentation rule).

Also, A → C implies A ∪ B → C ∪ B (by Augmentation rule).

To show A → B ∪ C :
1. A → B (Given)

2. A → C (Given)

3. A → A (Reflexivity)

4. From A → B , by Augmentation with C : A ∪ C → B ∪ C .

5. From A → C , by Augmentation with B : A ∪ B → C ∪ B .

6. We have A → B and A → C .

7. By Reflexivity, B ∪ C → B and B ∪ C → C .

8. Consider A → B . Augment with C : A ∪ C → B ∪ C . This does not directly give A → B ∪ C .

9. Let's retry:
1. A → B (Given)

2. A → C (Given)

3. A → A (Reflexivity)

4. From (1), by augmentation with A : A ∪ A → B ∪ A which is A → B ∪ A .

5. From (2), by augmentation with A : A ∪ A → C ∪ A which is A → C ∪ A .

6. Using slightly different derivation:

A → B (Given)

By Augmentation, A ∪ A → B ∪ A -> A → B ∪ A (this isn't A -> B U C )

Let's use the property that X+ contains all attributes determined by X .

If A → B , then B ∈ A+ .

If A → C , then C ∈ A+ .

Since B and C are in A+ , then B ∪ C must be in A+ .

Therefore, A → B ∪ C . This is a more intuitive way using the concept of attribute closure.

A formal derivation:
1. A → B (Given)

2. A → C (Given)

3. A → A (Reflexivity)

4. By Augmentation on (1) with C : A ∪ C → B ∪ C .

5. By Transitivity on (2) and (4) (requires C to be a subset of A ∪ C , which it is): A → B ∪

C . This is also not quite right because transitivity needs A -> X and X -> Y to get A
-> Y .

6. Let's stick to the closure approach for clarity in derivation, or provide a standard one:
1. A → B (Given)

2. A → C (Given)

3. From (1), by Augmentation: A → B implies A ∪ A → B ∪ A which is A → B ∪

A.

[Link] Page 50 of 159

 4. B ∪ A → B (Reflexivity)

5. B ∪ A → C (from 2, A → C , by Augmentation with B: A ∪ B → C ∪ B .

This gets complicated. The simplest explanation using logic:

If A determines B (i.e., A 's value fixes B 's value) AND A determines C (i.e.,
A 's value fixes C 's value), then A must fix both B and C simultaneously. Hence,
A → B ∪ C.

2. Decomposition Rule: If A → B ∪ C , then A → B and A → C .

Derivation:
1. A → B ∪ C (Given)

2. B ∪ C → B (Reflexivity, since B ⊆ B ∪ C )

3. From (1) and (2), by Transitivity: A → B .

4. Similarly, B ∪ C → C (Reflexivity, since C ⊆ B ∪ C )

5. From (1) and (4), by Transitivity: A → C .

3. Pseudotransitivity Rule: If A → B and B ∪ C → D , then A �� C → D .

Derivation:
1. A → B (Given)

2. B ∪ C → D (Given)

3. From (1), by Augmentation with C : A ∪ C → B ∪ C .

4. From (3) and (2), by Transitivity: A ∪ C → D .

5. Operations / Algorithms
Algorithm 1: Attribute Closure (X+)

Problem statement: Given a relation R, a set of attributes X, and a set of functional dependencies F, find the attribute
closure of X, denoted as X+. X+ is the set of all attributes that are functionally determined by X.

Step-by-step algorithm

1. Initialize closure_set with all attributes in X.

2. Repeat the following process until closure_set no longer changes in a complete iteration:
For each functional dependency A → B in the given set F:
Check if all attributes in A are present in closure_set .

If yes, add all attributes in B to closure_set .

Note: Ensure that attributes are added only if they are not already present to avoid infinite loops and maintain
set properties.

Dry run example Let relation R be (A, B, C, D, E) . Given FDs: F = {A → B, BC → D, D → E} . Find the
attribute closure of X = {A, C} (i.e., {A, C}+ ).

1. Initialize: closure_set = {A, C} .

2. Iteration 1:
A → B : A is in closure_set ( {A, C} contains A ). Add B . closure_set becomes {A, C, B} .

BC → D : BC (i.e., B and C ) are in closure_set ( {A, C, B} contains B and C ). Add D .

closure_set becomes {A, C, B, D} .

[Link] Page 51 of 159

 D → E : D is in closure_set ( {A, C, B, D} contains D ). Add E . closure_set becomes {A,
C, B, D, E} .

3. Iteration 2: (Check if closure_set changes from previous iteration)

closure_set is now {A, B, C, D, E} .

A → B : A is in closure_set . B is already in closure_set . No change.

BC → D : B , C are in closure_set . D is already in closure_set . No change.

D → E : D is in closure_set . E is already in closure_set . No change.

4. closure_set did not change in Iteration 2.

5. Result: {A, C}+ = {A, B, C, D, E} .

Pseudocode

FUNCTION calculate_attribute_closure(X, FDs):

closure_set = [Link]()

changed = TRUE
WHILE changed:
changed = FALSE
FOR EACH fd IN FDs:
lhs = fd.left_hand_side
rhs = fd.right_hand_side

IF lhs IS SUBSET OF closure_set:

FOR EACH attribute IN rhs:
IF attribute IS NOT IN closure_set:
ADD attribute TO closure_set
changed = TRUE
RETURN closure_set

Code (Python)

# Represents a functional dependency (e.g., "A -> BC")

class FunctionalDependency:
def __init__(self, lhs, rhs):
# Store attributes as frozensets for immutability and easy subset checks
[Link] = frozenset(lhs)
[Link] = frozenset(rhs)

def __repr__(self):
return f"{''.join(sorted([Link]))} -> {''.join(sorted([Link]))}"

def calculate_attribute_closure(attributes_to_close, fds):

"""
Calculates the attribute closure for a given set of attributes and FDs.

Args:
attributes_to_close (set): The initial set of attributes (X).
fds (list of FunctionalDependency): The set of functional dependencies.

Returns:
frozenset: The closure of the initial attributes.

[Link] Page 52 of 159

 """
closure = set(attributes_to_close) # Start with the initial attributes

changed = True
while changed:
changed = False
for fd in fds:
# Check if all attributes in the LHS of the FD are in the current closure
if [Link](closure):
# If yes, add all attributes from the RHS to the closure
# If new attributes are added, set changed to True to continue iterating
num_old_attributes = len(closure)
[Link]([Link])
if len(closure) > num_old_attributes:
changed = True

return frozenset(closure)

# Example Usage:
# R = (A, B, C, D, E)
# F = {A -> B, BC -> D, D -> E}
# Find {A, C}+

all_attributes = {'A', 'B', 'C', 'D', 'E'}

fds_example = [
FunctionalDependency({'A'}, {'B'}),
FunctionalDependency({'B', 'C'}, {'D'}),
FunctionalDependency({'D'}, {'E'})
]

# Calculate closure for {A, C}

x_closure = calculate_attribute_closure({'A', 'C'}, fds_example)
print(f"Closure of {{A, C}}: {x_closure}")

# Calculate closure for {A, E}

ae_closure = calculate_attribute_closure({'A', 'E'}, fds_example)
print(f"Closure of {{A, E}}: {ae_closure}")

Algorithm 2: Finding Candidate Keys (Conceptual)

Problem statement: Given a relation R with a set of attributes ATT and a set of functional dependencies F, find all
candidate keys for R.

Step-by-step algorithm

1. Identify trivial attributes:

LHS_only : Attributes that appear only on the left-hand side of FDs (never on the right). These attributes must
be part of any candidate key.

RHS_only : Attributes that appear only on the right-hand side of FDs (never on the left). These attributes
cannot be part of any candidate key.

BOTH : Attributes that appear on both sides of FDs.

NONE : Attributes that appear on neither side. These are part of ATT but are trivial and will never be
determined by any other attribute. They must be part of any candidate key.

[Link] Page 53 of 159

 2. Initial Key Candidate: Start with a base set K_base = LHS_only ∪ NONE .

3. Check K_base : Calculate K_base+ using the calculate_attribute_closure algorithm.

If K_base+ covers all attributes in ATT (i.e., K_base+ == ATT ), then K_base is a candidate key. Add it
to the list of candidate keys.

4. Iterate and Expand: If K_base+ does not cover all attributes, we need to add attributes from the BOTH set to
K_base to form new potential candidate keys.
Generate all possible subsets of attributes from the BOTH set.

For each subset S from BOTH :

Form a new potential key K_potential = K_base ∪ S .

Calculate K_potential+ .

If K_potential+ == ATT :
Check for minimality: Ensure that no proper subset of K_potential also forms a super key. If
K_potential is minimal, add it to the list of candidate keys. This typically involves checking if
(K_potential - {attribute}) + == ATT for each attribute in K_potential .

5. Final Result: The list of all identified minimal super keys will be the candidate keys.

Dry run example Let R be (A, B, C, D, E) . Given FDs: F = {A → B, BC → D, D → E} .

1. Identify attribute categories:

LHS attributes: A , B , C , D

RHS attributes: B , D , E

LHS_only : A (only in A->B )

RHS_only : E (only in D->E )

BOTH : B , D (in A->B and BC->D , and BC->D and D->E respectively)

NONE : C (appears as part of LHS but not as a determinant on its own, nor purely on RHS)
Correction: C is part of LHS of BC->D . It's not LHS_only or RHS_only . So C belongs to BOTH .

Let's re-evaluate:
FDs: A → B , BC → D , D → E

Attributes on LHS: {A, B, C, D}

Attributes on RHS: {B, D, E}

LHS_only (in LHS but not RHS): A

RHS_only (in RHS but not LHS): E

BOTH (in both LHS and RHS): B , D

NONE (not in any LHS or RHS, but in R): Empty set in this example, but C is tricky. C is in LHS, but not
LHS_only by definition. C is not in RHS, so not RHS_only or BOTH . So C is in neither LHS-only
nor RHS-only nor BOTH. It's an attribute in R that is part of a determinant, but not itself determined. This
means C MUST be part of a key.

Let's refine categories for candidate key finding:

Attributes_that_must_be_in_key = {attribute | attribute is in ATT and
attribute is not in UNION(RHS of all FDs)}

UNION(RHS of all FDs) = {B, D, E}

ATT = {A, B, C, D, E}

Attributes_that_must_be_in_key = {A, C} .

[Link] Page 54 of 159

 These are often called "core attributes".

2. Initial Key Candidate: K_base = {A, C} . (These are the attributes that don't appear on the RHS of any FD, so
they can't be derived by anything, thus must be part of any key).

3. Check K_base : Calculate {A, C}+ .

From previous dry run: {A, C}+ = {A, B, C, D, E} .

This covers all attributes of R.

4. Minimality Check: Is {A, C} minimal?

Try A+ : {A}+ = {A, B} (doesn't cover R).

Try C+ : {C}+ = {C} (doesn't cover R).

Since neither A nor C alone can determine all attributes, {A, C} is minimal.

5. Result: {A, C} is a candidate key.

Self-correction: The categorization of attributes ( LHS_only , RHS_only , BOTH , NONE ) is a helpful heuristic but the
most robust method for candidate key finding starts by identifying core attributes (those not determined by any
other attribute, i.e., not appearing on the RHS of any FD).

Pseudocode (Conceptual for finding ALL candidate keys)

FUNCTION find_candidate_keys(R_attributes, FDs):

candidate_keys = SET()

# 1. Identify core attributes: those not present on the RHS of any FD

all_rhs_attributes = SET()
FOR EACH fd IN FDs:
all_rhs_attributes.ADD_ALL(fd.right_hand_side)

core_attributes = SET()
FOR EACH attr IN R_attributes:
IF attr IS NOT IN all_rhs_attributes:
ADD attr TO core_attributes

# 2. Generate potential key sets

# Start with core_attributes. If its closure covers R_attributes, it's a candidate key
# Otherwise, we need to combine core_attributes with subsets of the remaining attribut

remaining_attributes = R_attributes - core_attributes

# Iterate through all subsets of remaining_attributes

FOR EACH subset IN POWER_SET(remaining_attributes):
current_candidate_set = core_attributes.union(subset)

IF calculate_attribute_closure(current_candidate_set, FDs) == R_attributes:

# Check for minimality: if this current_candidate_set is a Super Key
# then check if any of its proper subsets are also Super Keys.
# If no proper subset is a Super Key, then current_candidate_set is a Candidat

is_minimal = TRUE
FOR EACH attribute IN current_candidate_set:
test_subset = current_candidate_set - {attribute}

[Link] Page 55 of 159

 IF calculate_attribute_closure(test_subset, FDs) == R_attributes:
is_minimal = FALSE
BREAK

IF is_minimal:
ADD current_candidate_set TO candidate_keys

RETURN candidate_keys

Code (Python - for finding candidate keys, conceptual, as full robust code is extensive) A robust implementation
for finding all candidate keys can be quite involved due to the need to iterate through subsets and manage minimality
efficiently. The pseudocode outlines the logic. Here's a conceptual Python helper for the iteration part:

# Helper function to generate power set (all subsets)

def powerset(s):
from itertools import chain, combinations
return chain.from_iterable(combinations(s, r) for r in range(len(s) + 1))

def find_candidate_keys(all_attributes_set, fds):

candidate_keys = set()

# 1. Identify core attributes (attributes not on the RHS of any FD)

all_rhs_attributes = set()
for fd in fds:
all_rhs_attributes.update([Link])

core_attributes = all_attributes_set - all_rhs_attributes

# Attributes that are not core (i.e., they appear on RHS of some FD)
non_core_attributes = all_attributes_set - core_attributes

# We need to combine core_attributes with subsets of non_core_attributes

# to find potential candidate keys.
# Start with all possible combinations of attributes from non_core_attributes
# and combine them with the core_attributes.

for subset_of_non_core in powerset(non_core_attributes):

current_key_candidate = frozenset(core_attributes.union(subset_of_non_core))

if not current_key_candidate: # Skip empty sets if core_attributes is empty

continue

# Check if current_key_candidate is a Super Key

if calculate_attribute_closure(current_key_candidate, fds) == all_attributes_set:
# It's a Super Key. Now check for minimality.
is_minimal = True
for attr_to_remove in current_key_candidate:
test_subset = frozenset(current_key_candidate - {attr_to_remove})
if calculate_attribute_closure(test_subset, fds) == all_attributes_set:
is_minimal = False
break

if is_minimal:
# Add it to candidate_keys. Store as frozenset for hashing.

[Link] Page 56 of 159

 candidate_keys.add(current_key_candidate)

# Post-processing: Remove any super keys that were added because a smaller candidate k
# was found later (this might happen if order of powerset isn't guaranteed,
# though typical powerset generation usually starts with smaller sets)
final_candidate_keys = set()
for ck1 in candidate_keys:
is_truly_minimal = True
for ck2 in candidate_keys:
if ck1 != ck2 and [Link](ck1):
is_truly_minimal = False
break
if is_truly_minimal:
final_candidate_keys.add(ck1)

return final_candidate_keys

# Example Usage (same as above):

# R = (A, B, C, D, E)
# F = {A -> B, BC -> D, D -> E}

all_attrs_set_ck = frozenset({'A', 'B', 'C', 'D', 'E'})

fds_ck_example = [
FunctionalDependency({'A'}, {'B'}),
FunctionalDependency({'B', 'C'}, {'D'}),
FunctionalDependency({'D'}, {'E'})
]

candidate_keys_result = find_candidate_keys(all_attrs_set_ck, fds_ck_example)

print(f"Candidate Keys for R: {candidate_keys_result}")
# Expected: {{'A', 'C'}}

6. Complexity Analysis
Time complexity

Attribute Closure (X+):

Let |R| be the number of attributes in the relation, and |F| be the number of functional dependencies.

In each iteration of the while changed loop, we iterate through all |F| FDs.

For each FD A → B , checking [Link](closure_set) takes O(|A|) time. Adding B to

closure_set takes O(|B|) time. In the worst case, |A| and |B| can be O(|R|) . So, processing one
FD is O(|R|) .

The while loop runs at most |R| times, because in each successful iteration, at least one new attribute is
added to the closure (until all attributes are added).

Therefore, the worst-case time complexity is approximately O(|F| * |R| * |R|) = O(|F| * |R|^2) .

Finding Candidate Keys:

This algorithm involves iterating through the power set of non_core_attributes . If n is the number of
attributes, 2^n subsets can be generated.

For each subset, we calculate its closure, which is O(|F| * |R|^2) .

[Link] Page 57 of 159

 Then, for each super key found, we check its minimality by removing each of its attributes and recalculating
closure |R| times.

Thus, the worst-case time complexity is approximately O(2^|R| * |R| * |F| * |R|^2) = O(2^|R| *
|F| * |R|^3) . This exponential complexity highlights why finding all candidate keys can be computationally
expensive for relations with many attributes.

Space complexity

Attribute Closure: Stores the closure_set and the FDs.

closure_set : O(|R|)

FDs : O(|F| * |R|) (each FD stores LHS and RHS, max 2*|R| attributes)

Total: O(|F| * |R|)

Finding Candidate Keys:

In addition to storing FDs and attribute sets, it needs to store the candidate_keys list, which could hold
O(2^|R|) keys in the worst case (e.g., if every subset of attributes is a candidate key, which is rare but
theoretically possible). Each key is O(|R|) .

Total: O(|F| * |R| + 2^|R| * |R|) .

Comparison with alternatives

For attribute closure and candidate key identification, there aren't fundamentally different "alternative" conceptual
algorithms that drastically change the complexity class, as the underlying problem is combinatorial.

However, optimizations exist for specific implementations, such as using bitmasks for attribute sets when |R| is
small, which can make set operations ( issubset , update ) much faster (e.g., O(1) instead of O(|R|) ),
bringing the closure calculation down to O(|F| * |R|) and candidate key finding to O(2^|R| * |R| *
|F|) in terms of actual operations.

The primary challenge for finding candidate keys remains the exponential nature due to the need to explore subsets
of attributes.

7. Examples
Solved Problem 1 (Small)

Problem: Consider a relation R(A, B, C, D) with the following set of functional dependencies F = {A → B, C →
D, A → C} .

1. Find the attribute closure of {A} ( {A}+ ).

2. Find the attribute closure of {C} ( {C}+ ).

3. Find all Candidate Keys for R.

Solution:

1. Find {A}+ :

Initialize closure_set = {A} .

Iteration 1:
A → B : A is in closure_set . Add B . closure_set = {A, B} .

C → D : C is not in closure_set . No change.

A → C : A is in closure_set . Add C . closure_set = {A, B, C} .

Iteration 2:

[Link] Page 58 of 159

 closure_set = {A, B, C} .

A → B : A is in closure_set . B is already there. No change.

C → D : C is in closure_set . Add D . closure_set = {A, B, C, D} .

A → C : A is in closure_set . C is already there. No change.

Iteration 3:
closure_set = {A, B, C, D} . No FD causes closure_set to change.

Result: {A}+ = {A, B, C, D} .

2. Find {C}+ :

Initialize closure_set = {C} .

Iteration 1:
A → B : A is not in closure_set . No change.

C → D : C is in closure_set . Add D . closure_set = {C, D} .

A → C : A is not in closure_set . No change.

Iteration 2:
closure_set = {C, D} . No FD causes closure_set to change.

Result: {C}+ = {C, D} .

3. Find Candidate Keys:

R_attributes = {A, B, C, D} .

1. Identify core attributes: Attributes not on the RHS of any FD.

RHS attributes: B (from A→B ), D (from C→D ), C (from A→C ). So, all_rhs_attributes = {B, C,
D} .

Core attributes ( R_attributes - all_rhs_attributes ): {A, B, C, D} - {B, C, D} = {A} .

2. Generate potential key sets:

core_attributes = {A} .

non_core_attributes = {B, C, D} .

Start with K_base = {A} .

Calculate {A}+ = {A, B, C, D} . This covers all attributes of R.

3. Check for minimality of {A} :

Is any proper subset of {A} a super key? The only proper subset is the empty set {} , and {}+ will not cover
R. So, {A} is minimal.

Result: The only Candidate Key for R is {A} .

Solved Problem 2 (Medium)

Problem: Consider a relation R(A, B, C, D, E) with FDs F = {A → BC, C → D, E → A} . Is the functional

dependency E → D derivable from F ?

Solution: To check if E → D is derivable, we need to find the attribute closure of E ( {E}+ ). If D is in {E}+ , then E
→ D is derivable.

1. Find {E}+ :
Initialize closure_set = {E} .

[Link] Page 59 of 159

 Iteration 1:
A → BC : A is not in closure_set . No change.

C → D : C is not in closure_set . No change.

E → A : E is in closure_set . Add A . closure_set = {E, A} .

Iteration 2:
closure_set = {E, A} .

A → BC : A is in closure_set . Add B and C . closure_set = {E, A, B, C} .

C → D : C is in closure_set . Add D . closure_set = {E, A, B, C, D} .

E → A : E is in closure_set . A is already there. No change.

Iteration 3:
closure_set = {E, A, B, C, D} . No FD causes closure_set to change.

Result: {E}+ = {A, B, C, D, E} .

Since D is present in {E}+ , the functional dependency E → D is derivable from the given set of FDs.

8. Common Mistakes & Edge Cases

Where students go wrong

1. Confusing Key Types:

Mistaking a Super Key for a Candidate Key (forgetting minimality).

Not understanding that a relation has only one Primary Key, but multiple Candidate Keys and Alternate Keys.

2. Incorrectly Applying Armstrong's Axioms: Especially Transitivity and Augmentation. Forgetting that Augmentation
adds attributes to both sides of the FD.

3. Errors in Attribute Closure Calculation:

Not iterating enough times (stopping before closure_set stabilizes).

Incorrectly checking [Link](closure_set) (e.g., if A={X,Y} and closure_set={X,Z} , not

understanding that A is not a subset).

4. Forgetting Minimality for Candidate Keys: Identifying a Super Key but failing to ensure it's a Candidate Key by
checking if any of its proper subsets are also Super Keys.

5. Misidentifying Core Attributes: Incorrectly determining which attributes must be part of any candidate key (those
not appearing on the RHS of any FD).

6. Ignoring the "None" attributes (those not appearing in any FD's LHS or RHS): These attributes must be included
in a key if they are part of the relation schema, as nothing determines them.

Special cases

1. Empty Set of FDs: If F is empty, then the only FDs are trivial ones (by reflexivity). The only Candidate Key is the
entire set of attributes of the relation R . This is because no attribute can determine any other, so only the full set
can determine itself.

2. Relation with Single Attribute: R(A) . The only FD is A → A . The only Candidate Key is {A} .

3. All Attributes on RHS: If every attribute appears on the RHS of some FD, there might be no "core attributes" in the
traditional sense. In such cases, one needs to test combinations of attributes. For example, if R(A, B, C) and F
= {A → B, B → C, C → A} . No core attributes. Start trying single attributes: {A}+ = {A,B,C} , {B}+ =
{B,C,A} , {C}+ = {C,A,B} . All are candidate keys.

[Link] Page 60 of 159

 4. Redundant FDs: A set of FDs might contain redundant dependencies (e.g., A→B, B→C, A→C ). While A→C is
derivable, it's still part of the given set. Attribute closure algorithm handles this naturally. For finding candidate keys,
it's generally fine, but for minimal covers, redundancy needs to be addressed.

9. Real-Life Applications
Database Design for Business Systems: When designing databases for e-commerce, banking, inventory management,
or HR systems, identifying keys and FDs is the first step in creating a normalized schema.
Example: In a Customer table, CustomerID is a key. CustomerID → CustomerName, Address, Phone
defines FDs. This helps ensure that if a customer's address changes, it's updated in one place, preventing data
inconsistencies.

Data Warehousing and ETL (Extract, Transform, Load): Before loading data into a data warehouse, FDs and key
constraints are used to clean, validate, and transform data from various operational sources. Ensuring data integrity at
this stage is critical for reliable business intelligence and reporting.

Master Data Management (MDM): In MDM, the goal is to create a single, consistent view of core business entities
(like customers, products, suppliers). Keys are fundamental to uniquely identify these entities, and FDs help define the
relationships and rules governing their attributes across different systems.

System Integration: When integrating different applications or systems, understanding the keys and functional
dependencies of each system's data models is essential for mapping data correctly, resolving conflicts, and maintaining
data consistency across the integrated environment.

Data Migration: During database upgrades or migrations, keys and FDs are used to validate the migrated data,
ensuring that all constraints are maintained and data integrity is preserved in the new system.

Security and Access Control: While not directly related, a well-normalized database structure (built on keys and FDs)
can simplify the implementation of fine-grained access control, as permissions can be more logically tied to specific
entities and their attributes.

10. Practice Problems

Easy

Problem: Given relation R(W, X, Y, Z) and FDs F = {W → X, Y → Z} . Find the attribute closure of {W,
Y} .

Answer: {W, Y}+ = {W, X, Y, Z} .

Medium

Problem: Consider relation R(A, B, C, D, E) with FDs F = {A → B, C → D, A → E} . Find all Candidate

Keys for R.

Answer:
RHS attributes: {B, D, E}

Core attributes ( R_attributes - all_rhs_attributes ): {A, C}

Calculate {A, C}+ :

Start {A, C}

A → B : Add B . {A, B, C}

C → D : Add D . {A, B, C, D}

A → E : Add E . {A, B, C, D, E} .

{A, C}+ covers all attributes.

Check minimality:

[Link] Page 61 of 159

 {A}+ = {A, B, E} (does not cover R)

{C}+ = {C, D} (does not cover R)

Thus, {A, C} is a minimal super key.

No other combinations are needed because all attributes are covered and {A,C} contains all core attributes.

Candidate Key: {A, C} .

Hard

Problem: Given relation R(P, Q, R, S, T, U) and FDs F = {P → Q, Q → R, P → S, S → T, T →

U} . Find all Candidate Keys for R.

Answer:
RHS attributes: {Q, R, S, T, U}

Core attributes ( R_attributes - all_rhs_attributes ): {P} .

Calculate {P}+ :
Start {P}

P → Q : Add Q . {P, Q}

Q → R : Add R . {P, Q, R}

P → S : Add S . {P, Q, R, S}

S → T : Add T . {P, Q, R, S, T}

T → U : Add U . {P, Q, R, S, T, U}

{P}+ covers all attributes of R.

Check minimality for {P} : The only proper subset is {} , whose closure does not cover R. So, {P} is minimal.

Candidate Key: {P} .

Self-correction: This is a medium problem, not hard. A hard problem would involve finding a minimal cover or
more complex candidate key scenarios (e.g., multiple candidate keys with overlaps). The current example is fairly
straightforward once the core attributes are identified. A truly hard problem for candidate keys might be if the
core attributes are an empty set, or if there are many attributes and FDs, requiring extensive subset exploration.

11. Summary / Key Points

Keys uniquely identify tuples (rows) in a relation (table).

Super Key: Any attribute set that uniquely identifies a tuple.

Candidate Key: A minimal Super Key (no proper subset is also a Super Key).

Primary Key: The chosen Candidate Key for a relation. Must be unique and non-null.

Alternate Key: Any Candidate Key not chosen as the Primary Key.

Foreign Key: Links two tables by referencing a Primary Key in another table, enforcing referential integrity.

Functional Dependency (FD): A → B means that the values of attribute(s) A uniquely determine the values of
attribute(s) B.

Determinant: A (LHS). Dependent: B (RHS).

Trivial FD: A → B where B ⊆ A .

Non-trivial FD: A → B where B ⊄ A .

Attribute Closure (X+): The set of all attributes that are functionally determined by a given set of attributes X. This is a
crucial tool for finding candidate keys and checking normal forms.

[Link] Page 62 of 159

 Algorithm: Start with X, then iteratively add attributes based on FDs ( A → B where A is in current closure, add
B ) until no more attributes can be added.

Armstrong's Axioms: A complete and sound set of inference rules for FDs.

Reflexivity: If B ⊆ A , then A → B .

Augmentation: If A → B , then A ∪ C → B ∪ C .

Transitivity: If A → B and B → C , then A → C .

Importance: Keys and FDs are the foundation of database Normalization, helping to achieve data integrity, reduce
redundancy, and improve the efficiency and maintainability of database designs.

Finding Candidate Keys: Start with attributes that are not determined by any other attribute (not on the RHS of any FD,
also known as "core attributes"). Calculate their closure. If it's a super key, check its minimality. Otherwise, augment with
other attributes.

Highlighted Formulas and Shortcuts:

X+ : Attribute closure algorithm.

Candidate Key identification heuristic: Any candidate key must include all attributes that do not appear on the
RHS of any functional dependency.

Testing if A is a Candidate Key: Calculate A+ . If A+ contains all attributes of the relation R , and no proper
subset of A also yields all attributes, then A is a Candidate Key.

First Normal Form (1NF)

Definition and conditions for 1NF (atomic values, no repeating groups), and steps to convert an unnormalized table to 1NF.

1. Introduction
Definition First Normal Form (1NF) is the most basic level of database normalization. A relation (table) is said to be in
1NF if and only if every attribute (column) contains only atomic (indivisible) values, and there are no repeating groups of
attributes.

Atomic Value: A value that cannot be further subdivided into meaningful components. For example, a single phone
number is atomic, but a list of phone numbers in one field is not.

Repeating Group: Occurs when a table contains multiple columns for a similar type of data (e.g., Phone1 ,
Phone2 , Phone3 ) or when a single column contains multiple values.

Why it is needed (real-life analogy if possible) Imagine you're making a shopping list.

Without 1NF (Bad List): You might write "Apples, Bananas, Oranges" on one line, and "Milk, Cheese" on another. If
you want to know how many fruits you need, or if you only want to buy bananas, it's hard to tell or manage
individually from that single line. Also, what if you want to add a quantity for each item? It gets messy quickly.

With 1NF (Good List): You would write each item on its own line:
Apple

Banana

Orange

Milk

Cheese Now, it's easy to add details like quantity, price, or specific instructions for each item individually. You can
easily sort by item, count total items, or find all dairy products.

[Link] Page 63 of 159

 Similarly, in a database, non-1NF tables lead to:

Data Redundancy: Storing the same information multiple times (e.g., duplicating customer details for each of their
products).

Update Anomalies: Difficult to update data consistently (e.g., changing a customer's address might require
updating multiple entries if their information is repeated).

Insertion Anomalies: Cannot add new data without associated data (e.g., cannot add a new product until a
customer buys it, if product details are part of the customer's purchase record).

Deletion Anomalies: Deleting one piece of data unintentionally removes other related data.

Difficulty in Querying: Challenging to search, sort, or filter data efficiently when values are not atomic.

Applications 1NF is the foundational step in designing a relational database. It's the absolute minimum requirement for
a table to be considered a "relation" in the strict sense of relational algebra. Without 1NF, higher normal forms (2NF,
3NF, BCNF) cannot be achieved. It ensures basic data integrity and makes data manipulation much simpler.

2. Theory Explanation
In-depth explanation The core idea of 1NF is to ensure that each "cell" in a table (the intersection of a row and a
column) holds exactly one value, and that value is atomic. This means:

1. No Multi-valued Attributes: An attribute should not contain a list or a set of values. For instance, a
PhoneNumbers column should not store "123-456-7890, 987-654-3210". Instead, each phone number must have
its own entry. This is typically achieved by creating separate rows for each multi-value, duplicating other attributes,
or by creating a separate related table.

2. No Composite Attributes: An attribute should not contain several meaningful sub-parts that should logically be
separated. For example, an Address column storing "123 Main St, Anytown, CA 90210" should be broken down
into Street , City , State , and ZipCode columns. This makes searching and sorting by these individual
components possible.

3. No Repeating Groups: This is closely related to multi-valued attributes. It means you shouldn't have columns like
Item1 , Quantity1 , Item2 , Quantity2 , etc. If an entity can have multiple items, each item should be in its
own row.

The goal is to ensure that for any given row and column, there is a single, indivisible piece of information. This
significantly simplifies data storage, retrieval, and manipulation.

Diagrams/flowcharts (describe in text if not possible to draw)

Table NOT in 1NF: Students Table:

StudentID Name PhoneNumbers Courses

101 Alice Smith 111-222-3333, 444-555-6666 Math, Physics
102 Bob Johnson 777-888-9999 Chemistry
103 Carol White 123-456-7890 Biology, English, History
Problem 1 (Multi-valued Attribute): PhoneNumbers column contains multiple phone numbers for StudentID
101.

Problem 2 (Multi-valued Attribute/Repeating Group): Courses column contains multiple courses for
StudentID 101 and 103.

Table IN 1NF (Transformation 1: Flattening the Table): To get the Students table into 1NF, we need to ensure
each cell has an atomic value. For multi-valued attributes, this often means duplicating the other parts of the row.

Students Table (in 1NF):

[Link] Page 64 of 159

 StudentID Name PhoneNumber Course
101 Alice Smith 111-222-3333 Math
101 Alice Smith 111-222-3333 Physics
101 Alice Smith 444-555-6666 Math
101 Alice Smith 444-555-6666 Physics
102 Bob Johnson 777-888-9999 Chemistry
103 Carol White 123-456-7890 Biology
103 Carol White 123-456-7890 English
103 Carol White 123-456-7890 History
Explanation: Each distinct phone number and course combination for a student now occupies its own row.
Notice the duplication of StudentID and Name . This is a common consequence of achieving 1NF by
"flattening" data into a single table. A composite primary key like (StudentID, PhoneNumber, Course)
would be needed here. (Note: In practice, to reduce this redundancy further, separate tables for
StudentPhones and StudentCourses linked by StudentID would be created, which is a step towards
2NF/3NF).

Step-by-step breakdown To convert a table to 1NF:

1. Identify Multi-valued Attributes: Scan all columns for any attribute that contains a set or list of values within a
single cell.

2. Identify Composite Attributes: Look for attributes that can be meaningfully broken down into smaller, individual
attributes (e.g., FullAddress into Street , City , State , Zip ).

3. Handle Multi-valued Attributes:

For each record with a multi-valued attribute, create a new row for each value in that multi-valued attribute.
Duplicate the values from the other (atomic) columns for these new rows.

(Alternative, often preferred for higher normalization but valid for 1NF as a concept): Create a new table for the
multi-valued attribute, linked back to the original table via a foreign key.

4. Handle Composite Attributes:

Break down the composite attribute into its constituent atomic parts.

Replace the single composite column with multiple new atomic columns.

5. Ensure Unique Rows: After transformation, ensure that each row is uniquely identifiable. This might require forming
a composite primary key from existing attributes or adding a new identifier if necessary.

3. Properties & Characteristics

Key properties

Atomicity: Every cell contains a single, indivisible value.

Homogeneity: All values in a given column must be of the same data type.

Uniqueness of Columns: Each column must have a unique name within the table.

Order Independence of Rows: The order in which rows are stored does not affect the meaning or integrity of the
data.

Order Independence of Columns: The order of columns does not affect the meaning or integrity of the data.

Implicit Primary Key: While not explicitly required to be declared in 1NF, the structure allows for the identification
of a primary key (which might be a composite key) to uniquely identify each row.

Advantages & disadvantages

Advantages:

[Link] Page 65 of 159

 Foundation for Normalization: It's the essential first step for achieving higher normal forms (2NF, 3NF, BCNF),
which further reduce redundancy and improve data integrity.

Improved Querying: Easier to query, sort, and filter data because each piece of information is isolated and
atomic. You can directly search for a specific phone number or sort by city.

Better Data Integrity: Reduces the chances of inconsistent data entry and makes it easier to enforce rules.

Simpler Data Manipulation: INSERT , UPDATE , and DELETE operations become more straightforward as
changes affect individual atomic values.

Scalability: Better suited for handling large datasets as data is structured predictably.

Disadvantages:

Increased Number of Rows: When handling multi-valued attributes by "flattening" a single table, 1NF can lead
to a significant increase in the number of rows and duplication of non-key data, which introduces redundancy.
(e.g., Alice Smith's name and ID were repeated multiple times in the 1NF example table).

Potential for Increased Storage: Due to the duplication of data across multiple rows, storage requirements
might increase, although this is often mitigated by indexing and the overall benefits of a structured database.

Can Obscure Relationships (initially): When a single table is flattened to achieve 1NF, it might seem to hide the
"one-to-many" relationship within the original non-1NF column (e.g., one student has many phone numbers).
This is usually resolved by moving to higher normal forms, which would split such data into separate tables.

4. Mathematical / Logical Representation

Important formulas 1NF is more a set of rules and a logical structure than a mathematical formula in the traditional
sense. However, its principles can be described logically:

A relation R is in First Normal Form (1NF) if and only if for every attribute A in R :

1. domain(A) (the set of permissible values for A ) contains only atomic values. This means domain(A) must not
allow for composite values (values that can be decomposed into smaller meaningful parts) or multi-valued sets.

2. There are no repeating groups of attributes in R .

More formally, if R = {A1, A2, ..., An} is a relation schema, then for R to be in 1NF, for every Ai (attribute
i ):

Value(Ai) for any tuple t in R must be a single, indivisible value.

Value(Ai) must not be a set or list of values.

Value(Ai) must not be a structure composed of other values (e.g., a record or object type).

Derivations (if any) There are no mathematical derivations for 1NF. It serves as the foundational definition upon which
all other normal forms are built. Higher normal forms (2NF, 3NF, BCNF, etc.) provide further rules to eliminate specific
types of data redundancy and update anomalies, assuming the relation is already in 1NF.

5. Operations / Algorithms
Operations / Algorithm for 1NF Conversion This describes the conceptual process of transforming a non-1NF data
structure into a 1NF structure.

Problem statement: Given a table (relation) that contains multi-valued attributes or composite attributes, transform
it into a table that satisfies the conditions of First Normal Form (1NF).

Step-by-step algorithm:

1. Examine Table Schema: Review the columns (attributes) of the given table.

2. Identify Non-Atomic Attributes:

[Link] Page 66 of 159

 Multi-valued: Look for columns where a single cell can hold multiple distinct values (e.g., a comma-separated
list of phone numbers, an array of items).

Composite: Look for columns where a single cell contains conceptually separable components (e.g., "Full
Address" containing street, city, state, zip).

3. Process Composite Attributes:

For each identified composite attribute:
Break it down into its constituent atomic parts.

Replace the original composite column with new columns for each atomic part.

Update all existing rows by populating the new atomic columns with their respective extracted values.

4. Process Multi-valued Attributes:

For each identified multi-valued attribute:
For every row in the table:
If the multi-valued attribute contains N values (where N > 1 ):
Create N new rows.

Each new row will contain one of the N values from the multi-valued attribute.

Duplicate all other (now atomic) column values from the original row into each of these N new
rows.

Remove the original row.

If the multi-valued attribute contains 1 value, the row remains as is (or is transformed into a single new
row).

5. Identify/Establish Primary Key: After the transformation, determine a new primary key (which might be a
composite key) that uniquely identifies each row in the 1NF table. This often involves combining the original
primary key with the newly atomic attributes that caused row duplication.

Dry run example Original (Non-1NF) Order Table:

OrderID CustomerName CustomerAddress ItemDetails

1 Alice 123 Main St, Anytown (ProductA, 2), (ProductB, 1)
2 Bob 456 Elm St, Otherton (ProductC, 3)

Step 1-2: Identify Non-Atomic:

CustomerAddress is composite ( Street , City ).

ItemDetails is multi-valued (list of (Product, Quantity) tuples).

Step 3: Process Composite Attribute ( CustomerAddress ): Break CustomerAddress into Street and
City .

Intermediate Order Table:

OrderID CustomerName Street City ItemDetails

1 Alice 123 Main St Anytown (ProductA, 2), (ProductB, 1)
2 Bob 456 Elm St Otherton (ProductC, 3)

Step 4: Process Multi-valued Attribute ( ItemDetails ): For OrderID = 1 , ItemDetails has two
items. Create two rows. For OrderID = 2 , ItemDetails has one item. Create one row.

Final (1NF) Order Table:

OrderID CustomerName Street City Product Quantity

1 Alice 123 Main St Anytown ProductA 2

[Link] Page 67 of 159

 OrderID CustomerName Street City Product Quantity
1 Alice 123 Main St Anytown ProductB 1
2 Bob 456 Elm St Otherton ProductC 3

Step 5: Primary Key: A suitable primary key for the 1NF table would be (OrderID, Product) , as
OrderID alone is no longer unique.

Pseudocode

FUNCTION ConvertTo1NF(original_table):
new_table = empty_list_of_rows

FOR each row in original_table:

# Handle Composite Attributes (e.g., 'Address' -> 'Street', 'City')
# Assuming 'Address' is a string "Street, City"
IF 'Address' in row AND row['Address'] is composite:
street, city = split(row['Address'], ', ')
temp_row = copy_of_row_without_address
temp_row['Street'] = street
temp_row['City'] = city
ELSE:
temp_row = copy_of_row

# Handle Multi-valued Attributes (e.g., 'Items' -> multiple rows)

IF 'Items' in temp_row AND temp_row['Items'] is multi-valued:
items_list = parse(temp_row['Items']) # e.g., [(ProductA, 2), (ProductB,
FOR each item in items_list:
final_row = copy_of_temp_row_without_items
final_row['Product'] = item.product_name
final_row['Quantity'] = [Link]
add final_row to new_table
ELSE:
# If no multi-valued attribute or already atomic
add temp_row to new_table

RETURN new_table

Code (Python - Conceptual Data Transformation) This Python code conceptually transforms a list of dictionaries
representing records from a non-1NF state to a 1NF state. It's a data transformation script, not a direct database
schema alteration.

def convert_to_1nf(non_1nf_data):
"""
Converts a list of dictionaries (representing non-1NF table rows)
to a 1NF structure by flattening multi-valued attributes
and splitting composite attributes.
"""
_1nf_data = []

for row in non_1nf_data:

# Step 1: Handle Composite Attributes (e.g., splitting 'Address')
processed_row = [Link]()
if 'CustomerAddress' in processed_row and isinstance(processed_row['CustomerA
street, city = processed_row['CustomerAddress'].split(', ')

[Link] Page 68 of 159

 processed_row['Street'] = street
processed_row['City'] = city
del processed_row['CustomerAddress'] # Remove the composite attribute

# Step 2: Handle Multi-valued Attributes (e.g., flattening 'ItemDetails')

if 'ItemDetails' in processed_row and isinstance(processed_row['ItemDetails']
items = processed_row['ItemDetails']
del processed_row['ItemDetails'] # Remove the multi-valued attribute

for item_product, item_quantity in items:

new_row_for_item = processed_row.copy()
new_row_for_item['Product'] = item_product
new_row_for_item['Quantity'] = item_quantity
_1nf_data.append(new_row_for_item)
else:
# If no multi-valued attribute or already atomic
_1nf_data.append(processed_row)

return _1nf_data

# Example Non-1NF Data

non_1nf_orders = [
{
'OrderID': 1,
'CustomerName': 'Alice',
'CustomerAddress': '123 Main St, Anytown',
'ItemDetails': [('ProductA', 2), ('ProductB', 1)]
},
{
'OrderID': 2,
'CustomerName': 'Bob',
'CustomerAddress': '456 Elm St, Otherton',
'ItemDetails': [('ProductC', 3)]
},
{
'OrderID': 3,
'CustomerName': 'Charlie',
'CustomerAddress': '789 Pine Ln, Sometown',
'ItemDetails': [('ProductD', 1), ('ProductE', 5), ('ProductF', 2)]
}
]

# Convert to 1NF
one_nf_orders = convert_to_1nf(non_1nf_orders)

# Print the 1NF data

print("Original Non-1NF Data:")
for row in non_1nf_orders:
print(row)

print("\nTransformed 1NF Data:")

for row in one_nf_orders:
print(row)

[Link] Page 69 of 159

 6. Complexity Analysis
Time complexity (Best, Worst, Average) The time complexity for converting a table to 1NF largely depends on the
number of rows, the number of non-atomic attributes, and the "multiplicity" of multi-valued attributes (i.e., how many
values are in a list).

Let N be the number of rows in the original table.

Let M be the maximum number of values in any multi-valued attribute in a single row (e.g., if a customer has up to
5 phone numbers, M=5 ).

Let C be the number of composite attributes.

Let P be the average number of parts a composite attribute splits into.

Processing Composite Attributes: For each row, splitting composite attributes takes time proportional to C * P
(if done naively, string splitting might be O(length_of_string) ). Overall, O(N * C * P) . This is generally
efficient.

Processing Multi-valued Attributes: For each row, if it has a multi-valued attribute with k values, that row is
effectively expanded into k new rows.

Worst Case: If every row has a multi-valued attribute with M values, and all other attributes are duplicated M
times, the number of new rows could be N * M . Each original row processing would involve creating M new
rows and copying data. So, O(N * M) .

Best Case: If no rows have multi-valued attributes, the time complexity is dominated by composite attribute
splitting, which is O(N * C * P) . If there are no non-atomic attributes, it's O(N) for a simple scan.

Average Case: Lies between best and worst, depending on the average number of values in multi-valued
attributes. Still tends towards O(N * average_multiplicity) .

Space complexity

Worst Case: If all N rows have a multi-valued attribute with M values, the resulting 1NF table will have N * M
rows. This means the space required could increase from O(N * NumberOfColumns) to O(N * M *
NumberOfColumns) .

Best Case: If there are no multi-valued attributes (only composite), the number of rows remains N , but the number
of columns might increase due to splitting composite attributes. So, O(N * (OriginalColumns +
NewColumnsFromComposite)) .

Average Case: Similar to time complexity, depends on the average expansion factor.

Comparison with alternatives 1NF is the fundamental basis for relational database design; there isn't really an
"alternative" to 1NF itself within the relational model. Any other normal form (2NF, 3NF, BCNF, 4NF, 5NF, DKNF)
presupposes that the table is already in 1NF.

Higher Normal Forms (2NF, 3NF, BCNF): These forms build upon 1NF to further reduce data redundancy and
eliminate various update anomalies by separating logically distinct data into different tables. For example, the
redundancy seen in the 1NF example (Alice Smith's name repeated) would be addressed by 2NF or 3NF, which
would move customer details into a separate Customers table.

Denormalization: This is a strategy where some normalization rules are intentionally violated (often reverting from
3NF or BCNF to something less normalized) for performance reasons (e.g., faster reads). However, even
denormalized tables usually start from a 1NF structure to ensure basic queryability and then strategically introduce
controlled redundancy.

7. Examples

[Link] Page 70 of 159

 At least 1–2 solved problems (small, medium, complex)

Solved Problem (Small): Student Phone Numbers Original Table (Non-1NF): Students

StudentID Name PhoneNumbers

101 Alice 111-222-3333, 444-555-6666
102 Bob 777-888-9999

Identify Non-Atomic: PhoneNumbers is a multi-valued attribute.

Transformation to 1NF: For each student, if they have multiple phone numbers, create a separate row for each
phone number, duplicating the StudentID and Name .

Resulting Table (1NF): Students

StudentID Name PhoneNumber

101 Alice 111-222-3333
101 Alice 444-555-6666
102 Bob 777-888-9999

Primary Key: (StudentID, PhoneNumber)

Solved Problem (Medium): Order with Composite Customer and Multi-valued Items Original Table (Non-
1NF): Orders

OrderID CustomerInfo OrderDate Items

1 John Doe, 123 Main St, Anytown 2023-01-15 (Laptop, 1, $1200), (Mouse, 2, $25)
2 Jane Smith, 456 Elm St, Otherton 2023-01-16 (Keyboard, 1, $75)

Identify Non-Atomic:

CustomerInfo is composite ( Name , Street , City ).

Items is multi-valued, and each item itself is composite ( Product , Quantity , Price ).

Transformation to 1NF:

1. Split CustomerInfo into CustomerName , CustomerStreet , CustomerCity .

2. For Items , for each order, create new rows for each item. In each new row, split Item into Product ,
Quantity , Price .

Resulting Table (1NF): Orders

OrderID OrderDate CustomerName CustomerStreet CustomerCity Product Quantity Price

1 2023-01-15 John Doe 123 Main St Anytown Laptop 1 1200
1 2023-01-15 John Doe 123 Main St Anytown Mouse 2 25
2 2023-01-16 Jane Smith 456 Elm St Otherton Keyboard 1 75

Primary Key: (OrderID, Product)

8. Common Mistakes & Edge Cases

Where students go wrong

Confusing 1NF with Higher Normal Forms: A common mistake is thinking that 1NF eliminates all redundancy. It
doesn't. As seen in the examples, achieving 1NF by flattening a table can introduce redundancy (e.g.,
CustomerName and CustomerAddress repeated for each item in an order). 1NF primarily ensures atomicity

[Link] Page 71 of 159

 and eliminates repeating groups, setting the stage for 2NF/3NF to remove functional dependency-based
redundancy.

Misunderstanding "Atomic": Students might consider a string like "Street, City, State" to be atomic if it's treated as
a single unit in some applications. However, for database purposes, if you ever need to search by City or sort by
State , these components must be separate atomic attributes. The definition of "atomic" is context-dependent but
for normalization, it means indivisible into meaningful components.

Creating Multiple Columns for Repeating Groups: Instead of creating new rows for each value of a multi-valued
attribute, students might create PhoneNumber1 , PhoneNumber2 , PhoneNumber3 columns. This is not 1NF
compliant if the number of values can vary, as it introduces empty cells (NULLs) for rows with fewer values and limits
the maximum number of values. It also makes querying any_phone_number difficult. True 1NF for multi-valued
attributes requires new rows or a new table.

Special cases

Date/Time Fields: Is YYYY-MM-DD HH:MM:SS atomic? Generally, yes, if you usually operate on the whole
timestamp. But if you frequently need to query by Year , Month , Day , or Hour separately, then a case could
be made to split it into separate atomic attributes. Context and usage patterns determine atomicity for such fields.

JSON/XML Data in a Column: Many modern databases support storing JSON or XML data directly in a column.
While the database might technically consider the entire JSON string as "atomic" from a storage perspective, if you
query or manipulate elements within that JSON often, it's generally a non-1NF attribute for relational modeling
purposes. It violates the spirit of atomicity if its internal structure is relevant to the application's data integrity rules.
For full 1NF, components of the JSON/XML that are frequently accessed or involved in relationships should be
extracted into separate columns or tables.

9. Real-Life Applications
How this concept is used in real world
Database Design: Every professional database designer starts with 1NF. It's the foundational step in structuring data
for any new system (e.g., e-commerce platforms, banking systems, inventory management). Without it, the database
would be a chaotic collection of unstructured data.

Data Warehousing and ETL: Before loading data into a data warehouse, raw data from various sources (which
might not be in 1NF) is transformed using ETL (Extract, Transform, Load) processes. Ensuring 1NF is a critical
"transform" step to prepare data for analytical queries and to maintain data quality in the warehouse.

API Design and Data Exchange: When designing REST APIs or other data exchange formats, the concept of
atomicity is often applied. JSON payloads, for instance, are typically structured to reflect 1NF principles where each
field represents an atomic piece of information, and related lists of items are represented as arrays of objects,
mirroring a 1NF (or higher) table structure.

Legacy System Migration: When migrating data from old, poorly structured systems (e.g., spreadsheets, flat files, or
old databases not designed with normalization in mind), the first step is often to convert the data into a 1NF
structure before further normalization or loading into a modern relational database.

10. Practice Problems

Easy Problem: Convert the following Books table to 1NF. Books Table:

BookID Title Authors Publisher

1 DBMS Basics C.J. Date, Abraham Silberschatz Pearson
2 Intro to AI Stuart Russell Prentice Hall

Solution Hint: The Authors column contains multiple authors.

Medium Problem: Convert the following Employee_Projects table to 1NF. Employee_Projects Table:

[Link] Page 72 of 159

 EmployeeID FullName Projects
1 Alice Wonderland (P1, Budget:$10k), (P2, Budget:$5k)
2 Bob TheBuilder (P3, Budget:$20k)

Solution Hint: FullName is composite (First Name, Last Name). Projects is multi-valued, and each project entry
is composite (ProjectID, Budget).

Hard Problem: Convert the following Course_Enrollment table to 1NF. Course_Enrollment Table:

CourseCode CourseTitle EnrolledStudents Instructor

CS101 Intro to CS (S1, Alice, Grade:A), (S2, Bob, Grade:B) Dr. Smith
MA201 Calculus I (S3, Charlie, Grade:C), (S4, Diana, Grade:A), (S5, Eve, Grade:B) Prof. Jones

Solution Hint: EnrolledStudents is a multi-valued attribute. Each element within EnrolledStudents is

composite ( StudentID , StudentName , Grade ).

11. Summary / Key Points

Quick revision of points covered

1NF Definition: A table is in 1NF if all its attributes (columns) contain only atomic (indivisible) values, and there are
no repeating groups.

Atomic Value: A single, indivisible piece of information.

Non-1NF Issues: Leads to data redundancy, update anomalies (insertion, deletion, update), and difficulty in
querying.

Conversion Steps: Identify and split composite attributes into new atomic columns; for multi-valued attributes,
create new rows for each value, duplicating other column data.

Primary Key: After 1NF conversion, a new (often composite) primary key is required to uniquely identify each row.

Advantages: Essential foundation for all further normalization, improved data integrity, easier querying and data
manipulation.

Disadvantages: Can introduce data redundancy by duplicating non-key attributes across multiple rows to achieve
atomicity for multi-valued fields.

Real-world Use: Fundamental to database design, data warehousing, and API structuring.

Highlighted formulas and shortcuts

Core Rule: "One fact, one cell." Every intersection of a row and a column must contain a single, atomic value.

No Lists/Arrays: If you see a list of values (e.g., "item1, item2, item3") in a single cell, it's not 1NF.

No Combined Fields: If you see combined information (e.g., "Street, City, Zip") in a single cell, and you might need
to query parts of it, it's not 1NF.

No Value1 , Value2 , Value3 Columns: If you have columns like Phone1 , Phone2 , Phone3 , it's a
repeating group, and not 1NF.

The "Flattening" Principle: To fix multi-valued attributes in a single table, duplicate the non-offending parts of the
row for each value in the multi-valued attribute. This creates more rows.

Second Normal Form (2NF)

Definition and conditions for 2NF (being in 1NF and no partial dependencies), and steps to eliminate partial functional
dependencies.

[Link] Page 73 of 159

 1. Introduction
Definition Second Normal Form (2NF) is a level of database normalization that builds upon the principles of First
Normal Form (1NF). A relation (table) is said to be in 2NF if it is in 1NF and all its non-key attributes are fully functionally
dependent on the primary key. This means that no non-key attribute is functionally dependent on only a part of a
composite primary key.

Why it is needed Even after achieving 1NF, relations can still suffer from various data anomalies (insertion, deletion,
update) if non-key attributes depend on only a portion of a composite primary key. These are known as partial
dependencies.

Real-life analogy: Imagine a large, detailed "Order Items" list for a grocery store. This list might contain columns like
(OrderID, ItemID, ItemName, ItemCategory, ItemPrice, Quantity, CustomerName,
CustomerAddress) .
The primary key is (OrderID, ItemID) .

ItemName , ItemCategory , ItemPrice depend only on ItemID .

CustomerName , CustomerAddress depend only on OrderID .

If you wanted to change the ItemCategory of an ItemName , you'd have to update it for every single order
that contains that item, leading to update anomalies. If an item is temporarily out of stock and thus removed
from all orders, you might lose the ItemName and ItemCategory information entirely if it's not present in
any other order. 2NF addresses these issues by ensuring that each non-key attribute describes the "whole" entity
identified by the primary key, rather than just a part of it.

Applications 2NF is a fundamental step in relational database design. It is applied when:

Designing new databases to ensure data integrity and reduce redundancy.

Refining existing database schemas to eliminate anomalies.

Creating a robust and maintainable data model for various applications like e-commerce, banking, inventory
management, etc.

2. Theory Explanation
In-depth explanation To understand 2NF, two key concepts are essential:

1. Composite Primary Key: A primary key that consists of two or more attributes.

2. Partial Dependency: A functional dependency X -> Y where Y is a non-key attribute, and X is a proper
subset of the composite primary key. In other words, Y depends on only part of the primary key, not the whole key.

A relation R is in 2NF if:

It is in 1NF.

Every non-key attribute is fully functionally dependent on every candidate key. This means there are no partial
dependencies of any non-key attribute on any candidate key.

To move a table from 1NF to 2NF, the general strategy is to identify and remove partial dependencies by decomposing
the original table into smaller, related tables.

Diagrams/flowcharts (described in text)

Example: Relation Order_Items (Not in 2NF)

Attributes: (OrderID, ItemID, OrderDate, ItemName, ItemPrice, Quantity)

Primary Key: (OrderID, ItemID) (composite key)

Functional Dependencies (FDs):

[Link] Page 74 of 159

 (OrderID, ItemID) -> Quantity (Full dependency)

OrderID -> OrderDate (Partial dependency, OrderDate depends only on OrderID , which is part
of the PK)

ItemID -> ItemName, ItemPrice (Partial dependency, ItemName , ItemPrice depend only on
ItemID , which is part of the PK)

Graphical Representation (Conceptual):

Order_Items Table (PK: OrderID, ItemID)

----------------------------------------------------------------------
| OrderID | ItemID | OrderDate | ItemName | ItemPrice | Quantity |
----------------------------------------------------------------------
^ ^
| |
|__ Partial |__ Partial
Dependency Dependency
(on OrderID) (on ItemID)

Decomposition to 2NF:

Order_Items Table (Not in 2NF)

(OrderID, ItemID, OrderDate, ItemName, ItemPrice, Quantity)
PK: (OrderID, ItemID)
FDs: OrderID -> OrderDate
ItemID -> ItemName, ItemPrice
(OrderID, ItemID) -> Quantity

DECOMPOSE

New Table 1: Orders

(OrderID, OrderDate)
PK: OrderID
(Handles OrderID -> OrderDate partial dependency)

New Table 2: Items

(ItemID, ItemName, ItemPrice)
PK: ItemID
(Handles ItemID -> ItemName, ItemPrice partial dependency)

New Table 3: Order_LineItems (Remaining attributes fully dependent on original PK)

(OrderID, ItemID, Quantity)
PK: (OrderID, ItemID)
(Retains original composite PK and attributes fully dependent on it)

Step-by-step breakdown

1. Ensure 1NF: First, make sure the relation is in First Normal Form. This means all attributes contain atomic values (no
multi-valued attributes or nested tables).

2. Identify Candidate Keys: Determine all candidate keys for the relation. The primary key is one of the candidate
keys.

3. Identify Functional Dependencies: List all functional dependencies within the relation.

4. Check for Partial Dependencies: For each functional dependency X -> Y where Y is a non-key attribute:

[Link] Page 75 of 159

 If X is a proper subset of any candidate key, then Y is partially dependent on that candidate key. This is a 2NF
violation.

5. Decompose the Relation: If partial dependencies are found:

For each set of attributes Y that are partially dependent on a part of the candidate key X :
Create a new relation R_new containing X and Y (along with any other attributes solely dependent on
X ). X becomes the primary key of R_new .

Remove Y (and other attributes moved to R_new ) from the original relation R . The determinant X
remains in R to act as a foreign key for R_new if needed, maintaining the join path.

6. Repeat: Continue this decomposition process until no more partial dependencies exist in any of the resulting
relations.

3. Properties & Characteristics

Key properties

Must satisfy all conditions of 1NF.

Eliminates partial dependencies.

All non-key attributes are fully functionally dependent on the primary key (and any other candidate keys).

Often leads to an increased number of tables in the schema.

A prerequisite for achieving Third Normal Form (3NF).

Advantages & disadvantages

Advantages:

Reduced Data Redundancy: Information that was repeated due to partial dependencies is now stored only once
in a separate table.

Minimized Update Anomalies: Changing a partially dependent attribute (e.g., ItemName for an ItemID )
only requires updating one row in its dedicated table, not multiple rows across different orders.

Minimized Insertion Anomalies: You can add information about an Item (e.g., ItemID , ItemName ,
ItemPrice ) even if it hasn't been part of an Order yet.

Minimized Deletion Anomalies: Deleting an order line item won't accidentally delete information about the
Item itself if that item is still referenced elsewhere.

Improved Data Integrity: Data is more consistent and accurate.

Clearer Data Model: The schema reflects entities and their attributes more accurately.

Disadvantages:

Increased Number of Tables: Decomposition can lead to a larger number of tables in the database.

More Complex Queries (Joins): Retrieving all original information (e.g., OrderID , ItemID , OrderDate ,
ItemName , Quantity ) now requires joining multiple tables, which can be computationally more expensive.

Potential Performance Overhead: The need for more joins might lead to slower query execution times in some
scenarios. However, this is often offset by reduced I/O due to smaller tables and better indexing.

4. Mathematical / Logical Representation

Important formulas Let R be a relation schema and F be a set of functional dependencies on R . R is in 2NF if:

1. R is in 1NF.

[Link] Page 76 of 159

 2. For every non-prime attribute A in R , and every candidate key K of R , A is fully functionally dependent on
K.
This means, if X -> A is a functional dependency, where A is a non-prime attribute, then X must not be a
proper subset of K . In other words, if X is a determinant of A , then X must be a superkey (or contain a
candidate key).

Derivations (conceptual) The core idea stems from the definition of functional dependency and its properties.

Full Functional Dependency: An attribute B is fully functionally dependent on an attribute set A if B is

functionally dependent on A , but B is not functionally dependent on any proper subset of A .

When we say a relation is in 2NF, we are essentially deriving a state where for every non-key attribute, its functional
dependency on the primary key (or any candidate key) is full. If it's not full, it implies a partial dependency, and thus
a 2NF violation.

Example: If (A, B) is the primary key and (A, B) -> C , but we also find A -> C , then C is partially
dependent on (A, B) . To achieve 2NF, we separate A and C into a new relation (A, C) and remove C
from the original relation. The original relation retains (A, B) and attributes that fully depend on it (e.g., (A, B)
-> D ).

5. Operations / Algorithms
The "algorithm" for 2NF is primarily a database design process of decomposition.

Problem statement Given a relation R and its set of functional dependencies F , transform R into a set of relations
{R1, R2, ..., Rn} such that each Ri is in 2NF.

Step-by-step algorithm Algorithm: ConvertTo2NF(R, F)

1. Input: A relation R (assumed to be in 1NF) and its set of functional dependencies F .

2. Output: A set of relations, all in 2NF.

3. Initialize: Let NormalizedRelations be an empty set.

4. Identify Candidate Keys: Determine all candidate keys for R based on F . Let CK be the primary key chosen for
R.

5. Check for Partial Dependencies: a. For each non-key attribute A in R : b. Check if A is partially dependent on
CK . This means finding if there exists a proper subset X of CK such that X -> A is in F+ (the closure of F ).

6. Decompose if Partial Dependencies Exist: a. If no partial dependencies are found, then R is already in 2NF. Add
R to NormalizedRelations . b. If partial dependencies are found: i. Create a new set of relations
R_decomposed . ii. For each partial dependency X -> Y (where X is a proper subset of CK , and Y contains
one or more non-key attributes): * Create a new relation R_XY with schema (X U Y) . Make X the primary key
of R_XY . * Add R_XY to R_decomposed . * Remove Y from the original relation R . (Note: X remains in R
to act as a foreign key if needed). iii. The modified original relation R (which now contains CK and all non-key
attributes that are fully dependent on CK ) is also added to R_decomposed . iv. Recursively apply
ConvertTo2NF to each relation in R_decomposed until all relations are in 2NF.

7. Return: NormalizedRelations .

Dry run example Let's use the Order_Items example:

Initial Relation R1 : Order_Items(OrderID, ItemID, OrderDate, ItemName, ItemPrice,

Quantity)

Primary Key (CK): (OrderID, ItemID)

Functional Dependencies (F):

[Link] Page 77 of 159

 OrderID -> OrderDate

ItemID -> ItemName, ItemPrice

(OrderID, ItemID) -> Quantity (implicit, as Quantity depends on the specific order line item)

Step 1: R1 is in 1NF. Step 2: Candidate Key is (OrderID, ItemID) . Step 3: Identify non-key attributes:
OrderDate, ItemName, ItemPrice, Quantity . Step 4: Check for partial dependencies on (OrderID,
ItemID) : * OrderDate : OrderID -> OrderDate . OrderID is a proper subset of (OrderID, ItemID) .
Partial dependency found! * ItemName : ItemID -> ItemName . ItemID is a proper subset of (OrderID,
ItemID) . Partial dependency found! * ItemPrice : ItemID -> ItemPrice . ItemID is a proper subset of
(OrderID, ItemID) . Partial dependency found! * Quantity : (OrderID, ItemID) -> Quantity .
Quantity depends on the entire key. No partial dependency here.

Step 5: Decompose R1 : a. For OrderID -> OrderDate : * Create new relation R2_Orders(OrderID,
OrderDate) . PK: OrderID . * Remove OrderDate from R1 . b. For ItemID -> ItemName, ItemPrice : *
Create new relation R3_Items(ItemID, ItemName, ItemPrice) . PK: ItemID . * Remove ItemName ,
ItemPrice from R1 .

Resulting Relations:

R2_Orders(OrderID, OrderDate)

R3_Items(ItemID, ItemName, ItemPrice)

R1_OrderLineItems(OrderID, ItemID, Quantity) (The original R1 after removals)

All three resulting relations are now in 2NF:

R2_Orders : PK OrderID , non-key OrderDate is fully dependent on OrderID . (Trivially 2NF as PK is

simple).

R3_Items : PK ItemID , non-key ItemName , ItemPrice are fully dependent on ItemID . (Trivially 2NF as
PK is simple).

R1_OrderLineItems : PK (OrderID, ItemID) , non-key Quantity is fully dependent on (OrderID,

ItemID) . No partial dependencies.

Pseudocode This is a conceptual algorithm for schema transformation, not typically implemented as executable code to
automatically refactor a database schema programmatically. Instead, it guides manual database design.

FUNCTION DecomposeTo2NF(Relation R, FunctionalDependencies F): // Assume R is already

in 1NF

Let all_relations_2nf = {R} Let current_relations_to_process = {R}

WHILE current_relations_to_process IS NOT EMPTY: Remove a relation R_current from

current_relations_to_process

Identify candidate_keys_R_current for R_current based on F Let pk_R_current = one of

the candidate_keys_R_current // Assume a primary key is chosen

Let partial_dependencies_found = FALSE Let new_relations_from_decomposition =

EMPTY_SET

FOR EACH non_key_attribute A IN R_current.attributes: FOR EACH proper_subset X OF

pk_R_current: IF X -> A is in F_closure (closure of F): // Partial dependency found: X
-> A partial_dependencies_found = TRUE Let determinant_attributes = X Let
dependent_attributes = {A}

[Link] Page 78 of 159

 // Collect all attributes that are partially dependent on X FOR EACH
other_non_key_attribute B IN R_current.attributes (excluding A): IF X -> B is in
F_closure: Add B to dependent_attributes // Create new relation for this partial
dependency Let new_relation_schema = determinant_attributes UNION dependent_attributes
Let R_new = CreateRelation(new_relation_schema) Set pk_R_new = determinant_attributes
Add R_new to new_relations_from_decomposition

// Remove dependent_attributes from R_current R_current.attributes =

R_current.attributes MINUS dependent_attributes // Note: Determinant_attributes (X)
remain in R_current for foreign key relationship

IF partial_dependencies_found: Add R_current (modified) to

new_relations_from_decomposition Add all relations in new_relations_from_decomposition
to current_relations_to_process Remove R_current from all_relations_2nf // Replace R_current
with its decomposed parts ELSE: Add R_current to all_relations_2nf

RETURN all_relations_2nf

Code (Conceptual explanation) Direct executable code for automatically transforming a database schema to 2NF is
not a common or practical application. Database normalization is a design process typically performed manually by
database architects and developers. The "algorithm" above describes the logical steps for arriving at a 2NF compliant
schema. Implementing this as code would involve:

1. Schema introspection: Reading table definitions, primary keys, and functional dependencies (which are rarely
explicitly stored in the DBMS).

2. Dependency analysis: Computing the closure of functional dependencies and identifying partial dependencies.

3. Schema manipulation: Generating SQL CREATE TABLE and ALTER TABLE statements based on the
decomposition rules. This level of automated schema transformation is complex and prone to errors, especially
without perfect knowledge of functional dependencies. Therefore, the algorithm serves as a guide for human
designers.

6. Complexity Analysis
Time complexity When considering the "algorithm" as a manual design process, traditional time complexity (O-
notation) does not apply. If viewed as an algorithmic process to detect 2NF violations:

Identifying candidate keys can be computationally intensive (NP-hard in the worst case, as it involves finding
minimal covers for functional dependencies).

Checking for partial dependencies involves iterating through all non-key attributes and all proper subsets of each
candidate key, and then checking if functional dependencies exist. This can be complex, especially with many
attributes and dependencies. The actual design process depends on the complexity of the schema, the number of
attributes, and the number of functional dependencies, making it a task that requires careful analysis.

Space complexity

Logical Schema: Achieving 2NF generally increases the number of tables in the database schema.

Physical Data Storage: While the number of tables increases, the total physical storage required for the data
typically decreases due to the elimination of redundant data. Attributes previously repeated across many rows are
now stored only once in a separate table.

Index Size: Indices might be smaller on the new, smaller tables but there might be more indices overall.

Comparison with alternatives 2NF is not an "alternative" but rather a stage in the normalization process.

Compared to 1NF (not being in 2NF): 2NF is superior in terms of data integrity, reduced redundancy, and
minimized anomalies. The trade-off is often an increased number of tables and potentially more joins for data

[Link] Page 79 of 159

 retrieval.

Compared to 3NF/BCNF: 2NF is a less strict form. It eliminates partial dependencies but still allows for transitive
dependencies (which 3NF addresses) and certain types of candidate key overlap (which BCNF addresses). Moving to
3NF or BCNF offers further improvements in data integrity but can introduce more tables and complex joins.

7. Examples
Solved problems

1. Small Problem

Relation: StudentCourse(StudentID, CourseID, StudentName, CourseName)

Primary Key: (StudentID, CourseID)

Functional Dependencies:

StudentID -> StudentName

CourseID -> CourseName

Analysis:

The table is in 1NF (assuming atomic values).

Non-key attributes: StudentName , CourseName .

StudentID is a proper subset of (StudentID, CourseID) . Since StudentID -> StudentName ,

StudentName is partially dependent on the PK.

CourseID is a proper subset of (StudentID, CourseID) . Since CourseID -> CourseName ,

CourseName is partially dependent on the PK.

Decomposition to 2NF:

1. Create Students(StudentID, StudentName) with PK StudentID (from StudentID ->

StudentName ).

2. Create Courses(CourseID, CourseName) with PK CourseID (from CourseID -> CourseName ).

3. The remaining attributes that fully depend on (StudentID, CourseID) are just the key attributes
themselves, forming StudentEnrollments(StudentID, CourseID) with PK (StudentID,
CourseID) .

2NF Relations:

Students(StudentID, StudentName)

Courses(CourseID, CourseName)

StudentEnrollments(StudentID, CourseID)

2. Medium Problem

Relation: EmployeeProject(EmpID, ProjID, EmpName, ProjectName, EmpRole, HourlyRate)

Primary Key: (EmpID, ProjID)

Functional Dependencies:

EmpID -> EmpName, EmpRole

ProjID -> ProjectName

[Link] Page 80 of 159

 (EmpID, ProjID) -> HourlyRate (This indicates a specific employee's rate on a specific project)

Analysis:

The table is in 1NF.

Non-key attributes: EmpName, ProjectName, EmpRole, HourlyRate .

EmpID is a proper subset of (EmpID, ProjID) . Since EmpID -> EmpName, EmpRole , EmpName and
EmpRole are partially dependent on the PK.

ProjID is a proper subset of (EmpID, ProjID) . Since ProjID -> ProjectName , ProjectName is
partially dependent on the PK.

HourlyRate depends on the entire key (EmpID, ProjID) , so no partial dependency here.

Decomposition to 2NF:

1. Create Employees(EmpID, EmpName, EmpRole) with PK EmpID (from EmpID -> EmpName,
EmpRole ).

2. Create Projects(ProjID, ProjectName) with PK ProjID (from ProjID -> ProjectName ).

3. The remaining attributes HourlyRate fully depends on the original composite PK. This forms
EmployeeProjectDetails(EmpID, ProjID, HourlyRate) with PK (EmpID, ProjID) .

2NF Relations:

Employees(EmpID, EmpName, EmpRole)

Projects(ProjID, ProjectName)

EmployeeProjectDetails(EmpID, ProjID, HourlyRate)

8. Common Mistakes & Edge Cases

Where students go wrong

Forgetting 1NF: A relation must first be in 1NF before 2NF can be considered. Violations of 1NF (e.g., multi-valued
attributes) must be addressed first.

Misidentifying Partial Dependencies: Students might confuse partial dependencies with full functional
dependencies or transitive dependencies. A partial dependency only occurs when a non-key attribute depends on a
proper subset of a composite primary key.

Incorrectly Decomposing: When decomposing, ensuring that the determinant (the part of the PK causing the
partial dependency) is correctly carried over to the new table as its PK and also remains in the original table as part
of the composite key (now acting as a foreign key) is crucial for maintaining data relationships.

Tables with Simple Primary Keys: Believing that tables with a single-attribute primary key can have 2NF violations.
If a table has a simple (non-composite) primary key, it is automatically in 2NF if it is in 1NF, because there can be no
"proper subset" of a single attribute for a partial dependency.

Confusing with 3NF: 2NF deals with partial dependencies, while 3NF deals with transitive dependencies (where a
non-key attribute depends on another non-key attribute). It's important to differentiate these.

Special cases

Relation with a Simple Primary Key: Any relation with a primary key composed of only one attribute is
automatically in 2NF if it is already in 1NF. This is because there can be no "part" of the primary key to form a partial
dependency.

Relation with No Non-Key Attributes: A relation that only contains primary key attributes (e.g., a linking table like
Enrollment(StudentID, CourseID) ) is trivially in 2NF (and higher normal forms) because there are no non-
key attributes to be partially dependent.

[Link] Page 81 of 159

 Multiple Candidate Keys: If a relation has multiple candidate keys, the 2NF condition must hold for all candidate
keys. A non-key attribute must be fully functionally dependent on every candidate key.

9. Real-Life Applications
The principles of Second Normal Form are extensively applied in various real-world scenarios to design robust and efficient
databases:

E-commerce Systems: Separating product details (product ID, name, description) from order line item details (order ID,
product ID, quantity) prevents redundancy and anomalies. When a product's name changes, it only needs to be updated
in the Products table, not in every Order_Item record.

Banking and Financial Systems: Customer details (customer ID, name, address) are stored separately from account
details (account number, customer ID, balance). This ensures that customer information is maintained uniquely and
consistently, even if a customer has multiple accounts.

Inventory Management: Item details (SKU, name, supplier) are distinct from inventory movements (transaction ID, SKU,
quantity, date). This allows for efficient tracking of stock levels and item properties without duplicating information.

Healthcare Systems: Patient demographics (patient ID, name, date of birth) are kept in one table, while medical records
(record ID, patient ID, diagnosis, treatment) are in another. This segregates information logically and maintains data
integrity.

Human Resources Management: Employee personal details (employee ID, name, contact) are separate from their
project assignments (project ID, employee ID, role). This prevents project-specific data from being intertwined with
static employee data.

10. Practice Problems

Easy

Relation: R(A, B, C, D)

Primary Key: (A, B)

Functional Dependencies: A -> C , (A, B) -> D

Task: Convert R to 2NF.

Medium

Relation: Enrollment(StudentID, CourseID, StudentName, InstructorName, CourseCredits)

Primary Key: (StudentID, CourseID)

Functional Dependencies: StudentID -> StudentName , CourseID -> InstructorName,

CourseCredits

Task: Transform Enrollment into a set of 2NF relations.

Hard

Relation: OrderLine(OrderID, ItemID, OrderDate, CustomerName, ItemName, ItemPrice,

Quantity, Discount)

Primary Key: (OrderID, ItemID)

Functional Dependencies:
OrderID -> OrderDate, CustomerName

ItemID -> ItemName, ItemPrice

(OrderID, ItemID) -> Quantity, Discount

[Link] Page 82 of 159

 Task: Convert OrderLine to 2NF.

11. Summary / Key Points

Definition: A relation is in Second Normal Form (2NF) if it is in First Normal Form (1NF) and every non-key attribute is
fully functionally dependent on every candidate key.

Core Principle: The primary goal of 2NF is to eliminate partial dependencies. A partial dependency occurs when a
non-key attribute is dependent on only a part of a composite primary key.

Why it Matters: 2NF reduces data redundancy and minimizes data anomalies (insertion, update, deletion anomalies)
that can arise from partial dependencies.

Process: To achieve 2NF, relations with partial dependencies are decomposed into smaller, more granular relations. The
attributes forming the partial dependency are moved to a new table with the determinant part of the original composite
key becoming the new table's primary key.

Prerequisite: A relation must be in 1NF before it can be in 2NF.

Automatic 2NF: If a table has a simple (single-attribute) primary key, it is automatically in 2NF if it's in 1NF, as there can
be no "part" of the key for a partial dependency.

Benefit: Leads to a more logical, consistent, and maintainable database schema, laying the groundwork for further
normalization (3NF, BCNF).

Trade-off: Often results in more tables and potentially requires more joins for complex queries.

Third Normal Form (3NF)

Definition and conditions for 3NF (being in 2NF and no transitive dependencies), and steps to eliminate transitive functional
dependencies.

1. Introduction
Definition Third Normal Form (3NF) is a level of database normalization that builds upon the requirements of Second
Normal Form (2NF). A relation (table) is said to be in 3NF if it satisfies two conditions:

1. It is in Second Normal Form (2NF).

2. There is no transitive dependency of a non-prime attribute on the primary key. In simpler terms, 3NF ensures that
all non-key attributes are dependent only on the primary key, and not on other non-key attributes.

Why it is needed (real-life analogy if possible) 3NF is crucial for eliminating a specific type of data redundancy and
improving data integrity. It addresses the issue of "transitive dependencies." Real-life Analogy: The "Restaurant
Order" Scenario Imagine a restaurant where each order is assigned an OrderID . For each order, we record the
CustomerID , CustomerName , and the CustomerCity . Initially, our table might look like this:
Orders(OrderID, CustomerID, CustomerName, CustomerCity, MenuItem, Quantity, Price) Here:

OrderID is the primary key.

OrderID determines CustomerID .

CustomerID determines CustomerName and CustomerCity . The problem is, CustomerName and
CustomerCity are not directly dependent on OrderID ; they are dependent on CustomerID , which in turn is
dependent on OrderID . This is a transitive dependency: OrderID -> CustomerID -> CustomerName,
CustomerCity . Why is this bad?

1. Redundancy: If a customer places multiple orders, their CustomerName and CustomerCity will be repeated
for every order, wasting space.

[Link] Page 83 of 159

 2. Update Anomaly: If a customer moves to a new city, we'd have to update CustomerCity in every order they've
ever placed. If we miss one, data becomes inconsistent.

3. Deletion Anomaly: If a customer cancels their only order, and we delete that order, we might lose the customer's
CustomerName and CustomerCity entirely if they aren't stored elsewhere. 3NF helps us solve this by breaking
down the table into smaller, more focused tables, ensuring that each non-key attribute depends only on the primary
key, and not on other non-key attributes.

Applications 3NF is a widely adopted standard for relational database design. It's applied in virtually all database
systems where data integrity and minimized redundancy are important, including:

E-commerce platforms: Managing customer data, product catalogs, and order details.

Financial systems: Handling accounts, transactions, and customer records.

Inventory management: Tracking products, suppliers, and warehouse locations.

Human Resources: Storing employee information, department details, and job roles.

Healthcare systems: Managing patient records, appointments, and medical staff.

2. Theory Explanation
In-depth explanation To understand 3NF, we must first recall 1NF and 2NF:

First Normal Form (1NF): A relation is in 1NF if it contains no repeating groups, and all attributes contain atomic
(indivisible) values.

Second Normal Form (2NF): A relation is in 2NF if it is in 1NF and all non-prime attributes are fully functionally
dependent on every candidate key. This means there are no partial dependencies (where a non-prime attribute
depends on only part of a composite primary key).

Third Normal Form (3NF) focuses on eliminating transitive dependencies. A transitive dependency occurs when a
non-prime attribute (an attribute not part of any candidate key) is dependent on another non-prime attribute, which in
turn is dependent on the primary key. Formally, a relation R is in 3NF if for every non-trivial functional dependency X
→ A (where X is a set of attributes and A is a single attribute) that holds in R , at least one of the following
conditions is true:

1. X is a superkey of R . (A superkey is any set of attributes that can uniquely identify a row).

2. A is a prime attribute of R . (A prime attribute is an attribute that is part of some candidate key).

If neither of these conditions is met for a functional dependency X → A , then R is not in 3NF, and X → A
represents a transitive dependency. This usually happens in the form PK → X → A , where PK is the primary key, X
is a non-prime attribute, and A is also a non-prime attribute.

Diagrams/flowcharts (describe in text if not possible to draw) Conversion to 3NF Process Flow:

1. Start with a relation (table) that is in 2NF. (If not in 2NF, first normalize to 1NF, then 2NF by removing partial
dependencies.)

2. Identify all Functional Dependencies (FDs) in the relation. (List all dependencies, e.g., A → B , C → D )

3. Identify the Primary Key (PK) and all Candidate Keys. (Determine which attributes or combination of attributes can
uniquely identify records.)

4. Identify Prime and Non-Prime Attributes.

Prime Attributes: Attributes that are part of any candidate key.

Non-Prime Attributes: Attributes that are not part of any candidate key.

5. Check for Transitive Dependencies: For every functional dependency X → A where A is a non-prime attribute:

[Link] Page 84 of 159

 If X is not a superkey of the relation, AND

A is not a prime attribute, Then X → A is a transitive dependency. This usually manifests as PK → Y → A ,

where Y is also a non-prime attribute.

6. Decompose the Relation (if transitive dependencies exist): For each transitive dependency X → A (where X is
not a superkey, and A is non-prime):

Create a new relation with attributes {X, A} . X becomes the primary key of this new relation.

Remove A from the original relation. X remains in the original relation to act as a foreign key linking the two
relations.

7. Repeat steps 5-6 until no transitive dependencies remain in any of the resulting relations.

Step-by-step breakdown (Example: Employee_Department Table)

Let's consider an Employee_Department table: Employee_Department(EmpID, EmpName, EmpAddress,

DeptID, DeptName, DeptLocation)

Assumed Functional Dependencies (FDs):

EmpID → EmpName, EmpAddress, DeptID (EmpID determines employee details and their department)

DeptID → DeptName, DeptLocation (DeptID determines department details)

Step 1: Check 1NF. All attributes are atomic (no repeating groups or multi-valued attributes). So, it's in 1NF.

Step 2: Check 2NF.

Primary Key: EmpID (It's a single attribute, so no partial dependencies are possible).

All non-key attributes ( EmpName , EmpAddress , DeptID , DeptName , DeptLocation ) are fully functionally
dependent on EmpID . So, it's in 2NF.

Step 3: Check 3NF.

Candidate Key: EmpID (only one for this example).

Prime Attributes: EmpID .

Non-Prime Attributes: EmpName, EmpAddress, DeptID, DeptName, DeptLocation .

Now, let's look at the FDs for transitive dependencies:

1. EmpID → EmpName, EmpAddress : These are directly dependent on the PK. OK.

2. EmpID → DeptID : DeptID is directly dependent on the PK. OK.

3. DeptID → DeptName, DeptLocation :

Here, X = {DeptID} and A = {DeptName, DeptLocation} .

Is DeptID a superkey? No, EmpID is the PK. DeptID is a non-prime attribute.

Are DeptName , DeptLocation prime attributes? No. Therefore, EmpID → DeptID → DeptName,
DeptLocation is a transitive dependency. DeptName and DeptLocation are transitively dependent on
EmpID via DeptID .

Step 4: Decompose to remove transitive dependency. We decompose the Employee_Department table based
on the DeptID → DeptName, DeptLocation dependency.

New Relation 1 (for the transitive dependency): Department Attributes: {DeptID, DeptName,
DeptLocation} Primary Key: DeptID

[Link] Page 85 of 159

 Modified Original Relation: Employee Attributes: {EmpID, EmpName, EmpAddress, DeptID} (Removed
DeptName , DeptLocation ) Primary Key: EmpID DeptID in Employee becomes a Foreign Key
referencing Department(DeptID) .

Resulting relations in 3NF:

Employee(EmpID, EmpName, EmpAddress, DeptID)

Department(DeptID, DeptName, DeptLocation)

Both Employee and Department tables are now in 3NF.

3. Properties & Characteristics

Key properties

1. Reduces Data Redundancy: Eliminates transitive dependencies, preventing the repetition of non-key attribute data
across multiple records.

2. Prevents Update Anomalies: Changes to transitively dependent attributes only need to be made in one place (the
new table created for the dependency), ensuring consistency.

3. Prevents Deletion Anomalies: Deleting a record from the primary table will not inadvertently delete information
about a transitively dependent attribute if that attribute is moved to its own table.

4. Preserves Dependencies: The decomposition process to achieve 3NF ensures that all original functional
dependencies are preserved across the new set of relations.

5. Lossless Join Decomposition: The decomposition is reversible; the original table can be reconstructed by joining
the decomposed tables without losing any information or creating spurious tuples.

Advantages & disadvantages Advantages:

Improved Data Integrity: By ensuring attributes depend only on the primary key, data consistency is significantly
enhanced.

Reduced Data Redundancy: Minimizes storage space and prevents inconsistencies arising from data duplication.

Easier Maintenance: Updates, insertions, and deletions become simpler and less prone to errors due to localized
data changes.

Clearer Database Structure: Relations become more focused, representing single entities or concepts more
accurately.

Better Query Performance (for specific queries): For queries that only need data from one of the decomposed
tables, performance can improve as less data needs to be scanned.

Disadvantages:

Increased Number of Tables: Normalization often leads to more tables, which can make the database schema
appear more complex.

Increased Query Complexity (for aggregated queries): Retrieving data that spans across multiple decomposed
tables often requires performing JOIN operations, which can sometimes impact query performance compared to a
denormalized table.

Potential Performance Overhead: While reducing redundancy is good, excessive joining for frequent queries might
introduce overhead. However, 3NF is generally a good balance and the performance overhead is usually manageable
with proper indexing.

4. Mathematical / Logical Representation

Important formulas The core of 3NF relies on the concept of Functional Dependency (FD).

[Link] Page 86 of 159

 Functional Dependency (X → A): An attribute A is functionally dependent on a set of attributes X (denoted X →
A ) if, for any two tuples in the relation, if the values of X are the same, then the values of A must also be the same.
In simple terms, X uniquely determines A .

Prime Attribute: An attribute A is a prime attribute if it is a member of any candidate key of the relation. Non-Prime
Attribute: An attribute A is a non-prime attribute if it is not a member of any candidate key of the relation.

Superkey: A superkey is a set of attributes that uniquely identifies a tuple in a relation. A candidate key is a minimal
superkey.

Condition for 3NF: A relation R is in Third Normal Form (3NF) if and only if for every non-trivial functional
dependency X → A that holds in R , at least one of the following conditions is true:

1. X is a superkey of R .

2. A is a prime attribute of R .

Transitive Dependency Definition: A transitive dependency exists in relation R if there are attributes A , B , and C
such that A → B and B → C hold, but A does not directly determine C (i.e., C is not functionally dependent on
A alone without B ), and B is neither a superkey nor part of any candidate key. More precisely, A → C is a
transitive dependency if:

A → B and B → C are FDs.

B is not a superkey of R .

C is a non-prime attribute.

B is also a non-prime attribute.

Derivations (if any) The definition of 3NF directly addresses the transitive dependency issue. If a transitive dependency
PK → Y → A exists (where PK is the primary key, Y is a non-prime attribute, and A is also a non-prime attribute),
then for the FD Y → A :

X in our 3NF condition is Y .

A in our 3NF condition is A .

Is Y a superkey? No, because Y is a non-prime attribute, and by definition, a superkey must contain at least one
candidate key, and a non-prime attribute is not part of any candidate key by itself.

Is A a prime attribute? No, by definition of a transitive dependency, A is a non-prime attribute.

Since neither condition (X is a superkey OR A is a prime attribute) is met for Y → A , the relation is not in 3NF. This
derivation shows how the formal definition directly targets and identifies transitive dependencies.

5. Operations / Algorithms
The "algorithm" for converting a relation to 3NF is a design process based on functional dependency analysis and
decomposition, rather than a computational algorithm that can be directly coded and executed against data.

Problem statement Given a relation schema R and a set of functional dependencies F that hold over R ,
decompose R into a set of relations R1, R2, ..., Rn such that each Ri is in 3NF, the decomposition is lossless,
and dependencies are preserved.

Step-by-step algorithm (Normalization Process to 3NF)

1. Start with the initial relation schema R and its set of functional dependencies F .

2. Ensure 1NF: Verify that all attributes in R are atomic. If not, decompose R into 1NF relations (e.g., flatten multi-
valued attributes or repeating groups).

[Link] Page 87 of 159

 3. Ensure 2NF: a. Identify all candidate keys for R . b. For any partial dependency X → A (where X is a proper
subset of a candidate key, and A is a non-prime attribute), decompose R into two relations: * R1(X, A) with
X as the primary key. * R2(R - {A}) with X as a foreign key referencing R1 . c. Repeat until no partial
dependencies exist.

4. Ensure 3NF: a. After achieving 2NF, check for transitive dependencies. A transitive dependency exists if X → A is a
non-trivial FD where X is not a superkey and A is a non-prime attribute. (This implies PK → Y → A where Y is
a non-prime attribute). b. For each identified transitive dependency X → A : * Create a new relation R_new with
attributes {X, A} . X becomes the primary key of R_new . * Remove A from the original relation (or the
relation currently being processed). X remains in the original relation to act as a foreign key referencing R_new . c.
Repeat this decomposition for all transitive dependencies until all resulting relations are in 3NF.

Dry run example Let's use the Student_Course table with an additional attribute InstructorOffice .
Enrollment(StudentID, CourseID, CourseName, InstructorID, InstructorName,
InstructorOffice) Primary Key: {StudentID, CourseID} (composite key)

Functional Dependencies (FDs):

1. StudentID → InstructorID (A student takes a course from one instructor) Correction: This implies a student
only has one instructor overall. Let's make it simpler. Let's refine FDs to clearly show the 3NF issue.

Enrollment(StudentID, CourseID, Grade, InstructorName, InstructorOffice) Candidate Key:

{StudentID, CourseID}

Functional Dependencies (F):

1. StudentID, CourseID → Grade (The grade depends on both student and course)

2. CourseID → InstructorName (Each course has one instructor)

3. InstructorName → InstructorOffice (Each instructor has one office location)

Step 1: Check 1NF. All attributes are atomic. Yes.

Step 2: Check 2NF. Prime attributes: StudentID , CourseID (parts of the candidate key). Non-prime attributes:
Grade , InstructorName , InstructorOffice .

Let's check for partial dependencies ( X → A where X is a proper subset of {StudentID, CourseID} and A is
non-prime):

StudentID → Grade ? No.

CourseID → Grade ? No.

StudentID → InstructorName ? No.

CourseID → InstructorName ? Yes! CourseID is a proper subset of the PK, and InstructorName is a
non-prime attribute. This is a partial dependency.

Decomposition for 2NF:

Create a new relation for CourseID → InstructorName : Course(CourseID, InstructorName) PK:

CourseID

Remove InstructorName from Enrollment : Enrollment(StudentID, CourseID, Grade,

InstructorOffice) PK: {StudentID, CourseID} CourseID in Enrollment is an FK referencing
Course(CourseID) .

Now, let's re-evaluate the FDs on the new Enrollment table:

StudentID, CourseID → Grade

[Link] Page 88 of 159

 The InstructorName → InstructorOffice FD now refers to [Link] .

The current relations are:

1. Enrollment(StudentID, CourseID, Grade, InstructorOffice)

2. Course(CourseID, InstructorName)

Both are in 2NF.

Step 3: Check 3NF.

For Enrollment(StudentID, CourseID, Grade, InstructorOffice) :

Candidate Key: {StudentID, CourseID}

Prime attributes: StudentID, CourseID

Non-prime attributes: Grade, InstructorOffice No FDs where non-prime attribute depends on another
non-prime attribute (transitive). Grade and InstructorOffice directly depend on {StudentID,
CourseID} or are prime. Wait, what about InstructorOffice ? We had InstructorName →
InstructorOffice . InstructorName is not in this table. This means the original FDs must be re-evaluated
against the decomposed tables.

Let's use the original Enrollment(StudentID, CourseID, Grade, InstructorName,

InstructorOffice) and decompose systematically. Original FDs:

1. {StudentID, CourseID} → Grade

2. CourseID → InstructorName

3. InstructorName → InstructorOffice

Step-by-step 3NF conversion:

Initial Table: R1 (StudentID, CourseID, Grade, InstructorName, InstructorOffice) PK:

{StudentID, CourseID}

1. Check for 1NF: Yes. 2. Check for 2NF:

Partial dependency: CourseID → InstructorName (InstructorName is non-prime, CourseID is part of PK)

Decomposition:
R2 (StudentID, CourseID, Grade, InstructorOffice) (PK: {StudentID, CourseID} )

R3 (CourseID, InstructorName) (PK: CourseID )

CourseID in R2 is FK to [Link] .

3. Check for 3NF:

For R2 (StudentID, CourseID, Grade, InstructorOffice) :

PK: {StudentID, CourseID} . Non-prime: Grade , InstructorOffice .

Consider the remaining FDs that apply to R2 :

{StudentID, CourseID} → Grade : This is fine (Grade depends on PK).

What about InstructorOffice ? InstructorOffice is a non-prime attribute. Is it transitively

dependent on StudentID, CourseID ? We know InstructorName → InstructorOffice , and
CourseID → InstructorName . So, indirectly CourseID → InstructorName →
InstructorOffice . Since CourseID is not a superkey of R2 (it's part of the PK, but not the whole PK,
it's also not a superkey of R2 on its own), and InstructorOffice is non-prime, this implies a transitive
dependency if InstructorName were in R2 . But InstructorName is in R3 .

[Link] Page 89 of 159

 This means InstructorOffice in R2 is problematic. It should not be there. InstructorOffice
depends on InstructorName , which depends on CourseID . So InstructorOffice should be with
InstructorName . Let's re-do the decomposition from scratch, carefully.

Correct Dry Run Example:

Original Relation: StudentCourseInstructor(StudentID, CourseID, Grade, InstructorID,

InstructorName, InstructorOffice) Candidate Key: {StudentID, CourseID} (assuming a student can
take multiple courses, and a course can be taken by multiple students)

Functional Dependencies (FDs):

1. {StudentID, CourseID} → Grade

2. CourseID → InstructorID (A specific course has a specific instructor)

3. InstructorID → InstructorName, InstructorOffice (An instructor ID determines their name and

office)

Step 1: Check 1NF. Yes, all attributes are atomic.

Step 2: Check 2NF. Prime Attributes: StudentID , CourseID (parts of the candidate key). Non-Prime Attributes:
Grade , InstructorID , InstructorName , InstructorOffice .

Check for Partial Dependencies ( X → A where X is a proper subset of {StudentID, CourseID} and A is a
non-prime attribute):

CourseID → InstructorID : Yes. CourseID is a proper subset of the PK, and InstructorID is a non-
prime attribute. This is a partial dependency.

StudentID → InstructorID : No. (A student can take multiple courses, each with a different instructor).

Decompose for 2NF:

Create a new relation for the partial dependency CourseID → InstructorID :

CourseInstructor(CourseID, InstructorID) PK: CourseID

Remove InstructorID from the original relation: StudentEnrollment(StudentID, CourseID, Grade,

InstructorName, InstructorOffice) PK: {StudentID, CourseID} CourseID in
StudentEnrollment is an FK referencing CourseInstructor(CourseID) .

The InstructorName and InstructorOffice attributes are still present in StudentEnrollment but are not
directly determined by its PK {StudentID, CourseID} . They are transitively dependent. This indicates we need to
proceed to 3NF.

Current relations in 2NF:

1. StudentEnrollment(StudentID, CourseID, Grade, InstructorName, InstructorOffice)

2. CourseInstructor(CourseID, InstructorID)

Step 3: Check 3NF.

For StudentEnrollment(StudentID, CourseID, Grade, InstructorName, InstructorOffice) :

Candidate Key: {StudentID, CourseID}

Prime Attributes: StudentID , CourseID

Non-Prime Attributes: Grade , InstructorName , InstructorOffice

Relevant FDs applying to this table (derived from original set):

{StudentID, CourseID} → Grade (OK, depends on PK)

[Link] Page 90 of 159

 InstructorID → InstructorName, InstructorOffice (This FD existed, but InstructorID is no
longer in this table, it's in CourseInstructor ).

We need to consider transitive dependencies based on the original FDs. We know CourseID →
InstructorID (now CourseInstructor 's PK) and InstructorID → InstructorName,
InstructorOffice .

This creates a chain: {StudentID, CourseID} → CourseID → InstructorID → InstructorName,

InstructorOffice .

Thus, InstructorName and InstructorOffice are transitively dependent on {StudentID,

CourseID} through InstructorID (which itself was transitively dependent on CourseID in the original
table).

Since InstructorID is not a superkey of StudentEnrollment (it's not even in it, but
InstructorName and InstructorOffice depend on it), and InstructorName ,
InstructorOffice are non-prime, this requires further decomposition.

The problem is that InstructorName and InstructorOffice depend on InstructorID , and

InstructorID depends on CourseID . Neither InstructorID nor CourseID is a superkey of
StudentEnrollment .

Decompose for 3NF: Based on InstructorID → InstructorName, InstructorOffice :

Create a new relation InstructorDetails(InstructorID, InstructorName, InstructorOffice) PK:

InstructorID

The StudentEnrollment relation should now only contain StudentID , CourseID , Grade , and a
reference to InstructorID . Since we already moved InstructorID out into CourseInstructor during
2NF, StudentEnrollment is currently (StudentID, CourseID, Grade, InstructorName,
InstructorOffice) . We need to move InstructorName and InstructorOffice out and link via
InstructorID . This is where it gets tricky and why it's a multi-step process. The InstructorID was removed
from the main table in the 2NF step, but InstructorName and InstructorOffice still depend on
InstructorID implicitly. So, StudentEnrollment must eventually contain only Grade which depends on its
PK, and foreign keys.

Let's restart the 3NF decomposition from the initial 2NF state, keeping all non-key attributes that are transitively
dependent in mind.

Relations after 2NF:

1. R_Enrollment (StudentID, CourseID, Grade, InstructorName, InstructorOffice) PK:

{StudentID, CourseID} (This table still contains InstructorName and InstructorOffice )

2. R_CourseInstructor (CourseID, InstructorID) PK: CourseID

Check 3NF for R_Enrollment :

Non-prime attributes: Grade , InstructorName , InstructorOffice .

FDs for these: We know CourseID → InstructorID (from R_CourseInstructor ), and InstructorID →
InstructorName, InstructorOffice .

This implies CourseID → InstructorName and CourseID → InstructorOffice .

Since CourseID is NOT a superkey of R_Enrollment (it's only part of the PK), and InstructorName ,
InstructorOffice are non-prime, there's a transitive dependency here ( {StudentID, CourseID} →
CourseID → InstructorName/Office ).

Decomposition for R_Enrollment :

[Link] Page 91 of 159

 Move InstructorName and InstructorOffice into a new table associated with InstructorID .

However, InstructorID is not in R_Enrollment . This is the crucial point. The attributes
InstructorName and InstructorOffice depend on InstructorID , which in turn depends on
CourseID . Therefore, InstructorName and InstructorOffice should be pulled out based on their
direct determinant InstructorID .

Revised 3NF Decomposition Strategy:

For each transitive dependency X → A (where X is not a superkey and A is non-prime):
Create a new table T_XA with attributes {X, A} . X becomes PK.

Remove A from the original table R . X remains in R as FK.

Let's apply this from the initial relations after 2NF:

1. R_Enrollment (StudentID, CourseID, Grade, InstructorName, InstructorOffice) PK:

{StudentID, CourseID} FDs: {StudentID, CourseID} → Grade InstructorName →
InstructorOffice (still holds here, InstructorName is non-prime, InstructorOffice is non-prime)
(We implicitly know CourseID → InstructorName from R_CourseInstructor , but CourseID is not the
whole PK of R_Enrollment .)

2. R_CourseInstructor (CourseID, InstructorID) PK: CourseID FDs: CourseID → InstructorID

Focus on R_Enrollment for 3NF: We have InstructorName → InstructorOffice .

X = {InstructorName} , A = {InstructorOffice} .

Is InstructorName a superkey of R_Enrollment ? No.

Is InstructorOffice a prime attribute? No.

Therefore, InstructorName → InstructorOffice is a transitive dependency in R_Enrollment .

Decompose R_Enrollment :

Create a new relation for InstructorName → InstructorOffice :

R_InstructorDetails(InstructorName, InstructorOffice) PK: InstructorName

Remove InstructorOffice from R_Enrollment : R_Enrollment_Updated(StudentID, CourseID,

Grade, InstructorName) PK: {StudentID, CourseID} InstructorName in
R_Enrollment_Updated is an FK referencing R_InstructorDetails(InstructorName) .

Resulting relations in 3NF:

1. StudentEnrollment(StudentID, CourseID, Grade) (No more non-key attributes depending on other

non-key attributes)

2. CourseInstructor(CourseID, InstructorID) (No partial or transitive dependencies)

3. InstructorDetails(InstructorID, InstructorName, InstructorOffice) (If we trace

dependencies: CourseID → InstructorID , InstructorID → InstructorName, InstructorOffice .
So, InstructorName depends on InstructorID which is a PK. InstructorOffice depends on
InstructorID which is a PK. This is a 2NF and 3NF form now for InstructorDetails ).

We've actually produced 3 tables, by carefully following the FDs and decomposition steps. Note that InstructorID
eventually needs to replace InstructorName as the FK in StudentEnrollment for better consistency.

Final 3NF tables (after careful consideration):

Enrollment(StudentID, CourseID, Grade)

PK: {StudentID, CourseID}

[Link] Page 92 of 159

 FD: {StudentID, CourseID} → Grade

Course(CourseID, InstructorID)
PK: CourseID

FD: CourseID → InstructorID

Instructor(InstructorID, InstructorName, InstructorOffice)

PK: InstructorID

FD: InstructorID → InstructorName, InstructorOffice

Here, InstructorID in Course would be an FK referencing Instructor(InstructorID) . This set of tables is

in 3NF and is a much better representation of the data.

Pseudocode As 3NF normalization is a design process, direct executable pseudocode for automatic conversion is less
common for an entire schema. Instead, we can outline the logical steps for a single relation R to convert it to 3NF.

FUNCTION NormalizeTo3NF(Relation R, SetOfFDs F)

Let R_tables = {R} // Start with the initial relation

// Step 1: Normalize each relation to 1NF (assumed already done or handled by data
// For simplicity, assume R is already in 1NF.

// Step 2: Normalize each relation to 2NF

For each Relation CurrentR in R_tables:
Find CandidateKeys for CurrentR
For each FD (X -> A) in F that applies to CurrentR:
If X is a proper subset of any CandidateKey and A is non-prime:
// Partial Dependency found
Create NewR1 = (X, A) with X as PK
Remove A from CurrentR
Add NewR1 to R_tables
// Update F for new relations (important for correct FD propagation)

// Update FDs to reflect changes in R_tables (recalculate or adjust F)

// This step can be complex in an automated system, often done manually by designer

// Step 3: Normalize each relation to 3NF

For each Relation CurrentR in R_tables:
Find CandidateKeys for CurrentR
Find PrimeAttributes for CurrentR
For each FD (X -> A) in F that applies to CurrentR:
If A is a non-prime attribute AND X is NOT a Superkey of CurrentR AND A is
// Transitive Dependency found
Create NewR_Transitive = (X, A) with X as PK
Remove A from CurrentR
Add NewR_Transitive to R_tables
// Update FDs

Return R_tables
END FUNCTION

Code (C++/Java/Python) Direct executable code for automatic database normalization to 3NF is not typically provided
in standard programming languages in the same way as, say, a sorting algorithm. This is primarily because:

[Link] Page 93 of 159

 1. Context Sensitivity: Normalization depends heavily on understanding functional dependencies, which are semantic
rules based on the business logic, not always discoverable purely syntactically.

2. Schema Design: It's a database schema design process, usually performed by a human designer or with specialized
database design tools, not an operation to be run on an existing populated database to restructure it without explicit
design choices.

3. Complexity: Automating the discovery of all FDs, candidate keys, and then performing lossless, dependency-
preserving decomposition for an arbitrary relation and FD set is a complex problem, often relying on theoretical
algorithms from database research rather than common programming language implementations.

Therefore, rather than providing C++/Java/Python code for automatically converting a database to 3NF, one would
typically use these languages to:

Implement database schema creation (DDL) based on a human-designed 3NF schema.

Populate and query (DML) data in a 3NF-normalized database.

Build tools that assist designers in identifying FDs or visualizing decompositions, but not fully automate the entire
process for an arbitrary, unnormalized input.

(Self-correction: I will explicitly state that no direct code for the transformation itself is provided, as it's a design process.)

6. Complexity Analysis
Normalization to 3NF is primarily a database design activity, not an algorithm that operates on data at runtime. Therefore,
traditional time and space complexity analysis (Best, Worst, Average) in terms of computational steps and memory usage
for a specific input is not directly applicable. Instead, we analyze its impact on design effort, storage, and query
performance.

Time complexity (Best, Worst, Average)

Design Time/Effort: Identifying all functional dependencies, candidate keys, prime/non-prime attributes, and then
performing the decomposition process for a large, complex schema can be a time-consuming and intellectually
challenging task for a database designer. This effort is upfront.

Impact on Query Execution Time:

Best Case: For queries that only access data within a single 3NF table, performance can be better due to less data
scanning and smaller row sizes.

Worst Case (and Common Case for complex queries): Queries requiring data from multiple tables that were
separated during normalization will require JOIN operations. Multiple joins can increase query execution time,
especially on large datasets, as the database system needs to combine data from different sources. This is a
common trade-off for normalization.

Average Case: Generally, for a well-designed 3NF schema, the benefits of reduced redundancy and improved
data integrity often outweigh the performance overhead of joins, especially when proper indexing is applied.

Space complexity

Reduced Storage Redundancy: 3NF significantly reduces data redundancy, meaning less storage space is required
to store the same amount of information compared to unnormalized or 1NF/2NF forms. Data that would have been
repeated across many rows in a denormalized table is stored only once in its own dedicated table.

Increased Metadata/Index Overhead: While data storage is reduced, there might be a slight increase in storage for
metadata (more table definitions) and potentially more indexes if many foreign keys are indexed to optimize join
performance.

Comparison with alternatives

Vs. 1NF/2NF: 3NF is superior to 1NF and 2NF in terms of data integrity, reduced redundancy, and anomaly
prevention. 1NF and 2NF still allow transitive dependencies, which 3NF specifically eliminates.

[Link] Page 94 of 159

 Vs. BCNF (Boyce-Codd Normal Form): BCNF is a stricter form of 3NF. A relation is in BCNF if for every non-trivial
FD X → A , X is a superkey. BCNF addresses some specific types of anomalies that 3NF might miss, particularly
when a non-prime attribute determines part of a candidate key.
Advantages of 3NF over BCNF: 3NF guarantees dependency preservation, which BCNF does not always do. In
practice, 3NF is often considered a good compromise between reducing redundancy and maintaining
performance/simplicity, as BCNF decompositions can sometimes be more complex and might not preserve all
dependencies easily. Most practical database designs aim for 3NF, and only move to BCNF if very specific
dependency issues (often involving overlapping candidate keys) are present.

7. Examples
At least 1–2 solved problems (small, medium, complex)

Example 1: Small - Student Course Instructor

Initial Relation (R): StudentInstructor(StudentID, InstructorID, InstructorName) FDs:

1. StudentID → InstructorID (A student is assigned to one instructor)

2. InstructorID → InstructorName (An instructor ID determines their name)

Solution:

1. 1NF Check: Yes, all atomic.

2. 2NF Check:
Candidate Key: StudentID (since StudentID → InstructorID and InstructorID →
InstructorName , StudentID determines all attributes).

Prime Attributes: StudentID .

Non-Prime Attributes: InstructorID , InstructorName .

No composite PK, so no partial dependencies. Relation is in 2NF.

3. 3NF Check:
Consider InstructorID → InstructorName .

X = {InstructorID} , A = {InstructorName} .

Is InstructorID a superkey of R ? No. ( StudentID is the PK).

Is InstructorName a prime attribute? No.

Therefore, InstructorID → InstructorName is a transitive dependency ( StudentID →

InstructorID → InstructorName ).

Decomposition to 3NF:

Create a new relation for the transitive dependency InstructorID → InstructorName :

Instructor(InstructorID, InstructorName) PK: InstructorID

Remove InstructorName from the original relation: Student(StudentID, InstructorID) PK:

StudentID InstructorID in Student is an FK referencing Instructor(InstructorID) .

Resulting 3NF Relations:

Student(StudentID, InstructorID)

Instructor(InstructorID, InstructorName)

Example 2: Medium - Product Order Details

[Link] Page 95 of 159

 Initial Relation (R): OrderDetails(OrderID, CustomerID, CustomerName, ProductID, ProductName,
Price, CategoryID, CategoryName) Candidate Key: {OrderID, ProductID} (A unique order item)

FDs:

1. OrderID → CustomerID, CustomerName (Order determines customer details)

2. CustomerID → CustomerName (Customer ID determines customer name)

3. ProductID → ProductName, Price, CategoryID (Product ID determines product details)

4. CategoryID → CategoryName (Category ID determines category name)

Solution:

1. 1NF Check: Yes.

2. 2NF Check:

Prime Attributes: OrderID , ProductID .

Non-Prime Attributes: CustomerID , CustomerName , ProductName , Price , CategoryID ,

CategoryName .

Partial Dependencies:
OrderID → CustomerID, CustomerName : OrderID is a subset of PK, CustomerID,
CustomerName are non-prime. Partial.

ProductID → ProductName, Price, CategoryID : ProductID is a subset of PK, ProductName,

Price, CategoryID are non-prime. Partial.

Decomposition for 2NF:

From OrderID → CustomerID, CustomerName : Order(OrderID, CustomerID, CustomerName)

(PK: OrderID ) CustomerID is an FK referencing a Customer table (to be created later if needed).

From ProductID → ProductName, Price, CategoryID : Product(ProductID, ProductName,

Price, CategoryID) (PK: ProductID ) CategoryID is an FK referencing a Category table (to be
created later if needed).

Remaining from original: LineItem(OrderID, ProductID) (PK: {OrderID, ProductID} ) OrderID

in LineItem is an FK referencing Order(OrderID) . ProductID in LineItem is an FK referencing
Product(ProductID) .

Current relations (all in 2NF):

1. Order(OrderID, CustomerID, CustomerName)

2. Product(ProductID, ProductName, Price, CategoryID)

3. LineItem(OrderID, ProductID)

3. 3NF Check:

For Order(OrderID, CustomerID, CustomerName) :

PK: OrderID . Non-prime: CustomerID , CustomerName .

FD: CustomerID → CustomerName .

X = {CustomerID} , A = {CustomerName} .

Is CustomerID a superkey of Order ? No.

Is CustomerName a prime attribute? No.

[Link] Page 96 of 159

 Transitive dependency found: OrderID → CustomerID → CustomerName .

Decomposition for Order :

Create Customer(CustomerID, CustomerName) (PK: CustomerID )

Remove CustomerName from Order : Order(OrderID, CustomerID) (PK: OrderID ) CustomerID

in Order is an FK referencing Customer(CustomerID) .

For Product(ProductID, ProductName, Price, CategoryID) :

PK: ProductID . Non-prime: ProductName , Price , CategoryID .

FD: CategoryID → CategoryName . (Wait, CategoryName is not in this table yet, but it's important for the
original FDs). This points to an underlying transitive dependency from the original OrderDetails table. The
CategoryID is a non-prime attribute that determines CategoryName , which was implicitly removed when
we decomposed to 2NF if we were not careful. Let's assume CategoryName was in Product initially as
Product(ProductID, ProductName, Price, CategoryID, CategoryName) . Then in Product :

PK: ProductID . Non-prime: ProductName , Price , CategoryID , CategoryName .

FD: CategoryID → CategoryName .

X = {CategoryID} , A = {CategoryName} .

Is CategoryID a superkey of Product ? No.

Is CategoryName a prime attribute? No.

Transitive dependency found: ProductID → CategoryID → CategoryName .

Decomposition for Product :

Create Category(CategoryID, CategoryName) (PK: CategoryID )

Remove CategoryName from Product : Product(ProductID, ProductName, Price,

CategoryID) (PK: ProductID ) CategoryID in Product is an FK referencing
Category(CategoryID) .

For LineItem(OrderID, ProductID) :

PK: {OrderID, ProductID} . No other attributes. Already in 3NF.

Final 3NF Relations:

1. Customer(CustomerID, CustomerName)

2. Order(OrderID, CustomerID) (FK: CustomerID referencing Customer )

3. Product(ProductID, ProductName, Price, CategoryID) (FK: CategoryID referencing Category )

4. Category(CategoryID, CategoryName)

5. LineItem(OrderID, ProductID) (FK: OrderID referencing Order , FK: ProductID referencing

Product )

8. Common Mistakes & Edge Cases

Where students go wrong

1. Incorrectly identifying Candidate Keys: If the candidate keys are wrong, all subsequent checks for 2NF and 3NF
will be flawed.

[Link] Page 97 of 159

 2. Confusing Prime and Non-Prime Attributes: Misidentifying prime attributes leads to incorrect application of the
3NF rule. Remember, a prime attribute is part of any candidate key.

3. Missing Functional Dependencies: Not identifying all FDs from the problem description or from real-world
business rules will result in an under-normalized schema.

4. Incorrectly Identifying Transitive Dependencies: Students might confuse a dependency like A → B and B → C
where B is a superkey (or part of one) as a transitive dependency, when it might not be. The X in X → A must
NOT be a superkey, and A must NOT be a prime attribute.

5. Incomplete Decomposition: Decomposing only for one transitive dependency and failing to check the resulting
tables for further violations. Normalization is an iterative process.

6. Lossy Decomposition: Decomposing tables without retaining a common attribute (or a superkey) for joining,
leading to loss of information when tables are rejoined. 3NF decompositions should always be lossless.

7. Overlooking Implicit Dependencies: Sometimes, FDs are not explicitly stated but are implied by the domain
knowledge (e.g., ZipCode → City, State ).

Special cases

Candidate Keys as Determinants: If X → A is an FD and X is a candidate key (or a superkey), then it trivially
satisfies 3NF. No decomposition is needed for this FD.

Prime Attributes as Dependents: If X → A is an FD and A is a prime attribute, then it also trivially satisfies 3NF.
No decomposition is needed for this FD.

BCNF vs. 3NF: There are rare cases where a relation is in 3NF but not in BCNF. This happens when for an FD X →
A , X is not a superkey, and A is a prime attribute, but X is not a superkey. BCNF would require X to be a
superkey, while 3NF allows A to be prime. This usually involves multiple overlapping candidate keys. For example,
(ID, Subject, Instructor) where (ID, Subject) is a PK, (Subject, Instructor) is another CK.
If Instructor → Subject , then this table is in 3NF (Subject is prime) but not BCNF (Instructor is not a
superkey). Most practical applications aim for 3NF as it balances strictness with dependency preservation.

9. Real-Life Applications
Third Normal Form is the most common target for database design in professional settings because it strikes an excellent
balance between data integrity, reduced redundancy, and query performance.

E-commerce Databases:
Customer Information: Separating Customer(CustomerID, Name, Address, Phone) from
Order(OrderID, CustomerID, OrderDate) . This prevents customer details from being repeated for every
order.

Product Catalogs: Product(ProductID, Name, Description, Price, SupplierID) and

Supplier(SupplierID, Name, Contact) .

Student Information Systems:

Student Details: Student(StudentID, Name, DateOfBirth, MajorID)

Majors/Departments: Major(MajorID, MajorName, DeptID) and Department(DeptID, DeptName,

HeadOfDept) . This avoids repeating department details for every major and every student.

Course Enrollment: Enrollment(StudentID, CourseID, Grade) links students to courses without

redundant course or student details.

Financial Systems:
Account Details: Account(AccountID, CustomerID, AccountType, Balance)

Transaction Records: Transaction(TransactionID, AccountID, Date, Amount, Type)

Ensures that customer details are not duplicated in every account or transaction record.

[Link] Page 98 of 159

 Inventory Management:
Item Master: Item(ItemID, ItemName, Description, SupplierID, UnitCost)

Supplier Details: Supplier(SupplierID, SupplierName, ContactPerson)

Prevents supplier details from being repeated for every item supplied.

Healthcare Systems:
Patient Records: Patient(PatientID, Name, DateOfBirth, Address, PrimaryCarePhysicianID)

Physician Details: Physician(PhysicianID, Name, Specialty, ClinicID)

Clinic Details: Clinic(ClinicID, ClinicName, ClinicAddress)

Ensures patient, physician, and clinic details are stored optimally without redundancy.

10. Practice Problems

Easy Given a relation EmployeeProjects(EmpID, EmpName, ProjectID, ProjectName) , with FDs:

1. EmpID → EmpName

2. ProjectID → ProjectName

3. {EmpID, ProjectID} is the primary key. Is EmployeeProjects in 3NF? If not, why, and how would you
normalize it?

Medium A library system has a relation BookCopies(BookID, Title, Author, PublisherID,

PublisherName, BranchID, NumCopies) . Candidate Key: {BookID, BranchID} Functional Dependencies:

1. BookID → Title, Author, PublisherID

2. PublisherID → PublisherName

3. {BookID, BranchID} → NumCopies Normalize BookCopies to 3NF. Show all steps.

Hard Consider a relation UniversityCourse(CourseCode, CourseName, DepartmentID,

DepartmentName, ProfessorID, ProfessorName, OfficeLocation, EnrollmentLimit) . Functional
Dependencies:

1. CourseCode → CourseName, DepartmentID, EnrollmentLimit

2. DepartmentID → DepartmentName

3. ProfessorID → ProfessorName, OfficeLocation

4. CourseCode → ProfessorID (Each course is taught by one professor) Normalize UniversityCourse to

3NF, ensuring lossless decomposition and dependency preservation. Identify all intermediate steps and resulting
relations.

11. Summary / Key Points

Quick revision of points covered

Third Normal Form (3NF) is a database normalization level that requires a relation to be in 2NF and have no
transitive dependencies.

A transitive dependency occurs when a non-prime attribute is dependent on another non-prime attribute, which in
turn depends on the primary key (e.g., PK → NonKey1 → NonKey2 ).

Formal Definition: A relation R is in 3NF if for every non-trivial FD X → A in R , either X is a superkey of R ,

or A is a prime attribute of R .

[Link] Page 99 of 159

 The primary goal of 3NF is to eliminate redundancy and prevent update, insertion, and deletion anomalies caused by
transitive dependencies.

Achieving 3NF involves identifying transitive dependencies and decomposing the relation into smaller, more focused
relations. This decomposition must be lossless and dependency-preserving.

Benefits: Improved data integrity, reduced data redundancy, easier maintenance, and a clearer database schema.

Trade-offs: Can lead to an increased number of tables, potentially requiring more JOIN operations for certain
queries.

Highlighted formulas and shortcuts

3NF Condition: For every FD X → A in R :

X is a Superkey OR

A is a Prime Attribute

Transitive Dependency (informal): If A → B and B → C exist, and A is the PK, B is not a superkey, and C is
non-prime, then C is transitively dependent on A via B .

Decomposition Rule: If X → A is a transitive dependency, create a new table (X, A) (where X is PK) and
remove A from the original table (keeping X as FK).

Normalization Steps (for a relation R):

1. Ensure 1NF.

2. Ensure 2NF (remove partial dependencies).

3. Ensure 3NF (remove transitive dependencies).

Boyce-Codd Normal Form (BCNF)

Definition and conditions for BCNF (every determinant must be a candidate key), and understanding when BCNF is stricter
than 3NF.

As your teaching assistant, I've prepared detailed, textbook-style notes on Boyce-Codd Normal Form (BCNF) for your DBMS
course.

1. Introduction
Definition Boyce-Codd Normal Form (BCNF) is a stricter form of the Third Normal Form (3NF). A relation $R$ is in BCNF
if, for every non-trivial functional dependency (FD) $X \rightarrow Y$ in $R$, $X$ must be a superkey of $R$. This means
that every determinant in the relation must be a superkey.

Why it is needed (real-life analogy if possible) While 3NF addresses most data redundancy and anomaly issues, it has
a specific exception: it allows a non-superkey $X$ to determine a non-key attribute $Y$ if $Y$ is a prime attribute (i.e.,
part of some candidate key). This exception can sometimes still lead to anomalies, particularly when a relation has
multiple overlapping candidate keys.

Analogy: Imagine a university department that employs teaching assistants (TAs). Each TA can teach multiple
courses, and each course can be taught by multiple TAs. However, each TA has a unique Employee ID, and each
course has a unique Course ID. The department also tracks a "preferred lab equipment" for each TA for a specific
course.
Relation: (TA_ID, Course_ID, TA_Name, Preferred_Equipment)

FDs:
1. TA_ID $\rightarrow$ TA_Name (Each TA_ID maps to one TA_Name)

[Link] Page 100 of 159

 2. (TA_ID, Course_ID) $\rightarrow$ Preferred_Equipment (For a specific TA in a specific course,
there's one preferred equipment)

3. TA_Name $\rightarrow$ TA_ID (Let's assume TA_Name is unique enough to also be a key, for this
example)

Candidate Keys: (TA_ID, Course_ID) and (TA_Name, Course_ID)

Problematic FD: TA_Name $\rightarrow$ TA_ID . Here, TA_Name is not a superkey (it doesn't determine
Preferred_Equipment by itself), but TA_ID is a prime attribute (part of a candidate key). 3NF would allow
this, but it still has a subtle redundancy: if a TA changes their TA_Name , we might need to update multiple rows.
BCNF would flag this as a violation because TA_Name is not a superkey.

Applications BCNF is primarily used in the logical design phase of relational databases to ensure maximum data
integrity and minimal redundancy. It is critical for systems where data accuracy and consistency are paramount, such as
banking, healthcare, and inventory management systems.

2. Theory Explanation
In-depth explanation To understand BCNF, let's first recall the definition of 3NF. A relation $R$ is in 3NF if:

1. It is in 2NF.

2. No non-prime attribute is transitively dependent on a candidate key. (i.e., for every non-trivial FD $X \rightarrow Y$,
either $X$ is a superkey, or $Y$ is a prime attribute.)

BCNF takes the second condition of 3NF a step further by removing the "prime attribute" exception. A relation $R$ is
in BCNF if for every non-trivial functional dependency $X \rightarrow Y$ in $R$, $X$ is a superkey of $R$.

This means that if a set of attributes $X$ determines another set of attributes $Y$, then $X$ must functionally determine
all attributes in the relation (i.e., $X$ must be a superkey). If $X$ is not a superkey, it means $X$ determines only a
subset of attributes, implying a redundancy that BCNF aims to eliminate.

The key difference from 3NF arises in relations that have:

1. Multiple overlapping candidate keys.

2. A functional dependency $X \rightarrow Y$ where $X$ is not a superkey, and $Y$ is a prime attribute (part of a
candidate key). 3NF allows this, BCNF does not.

BCNF aims to resolve these "anomalies due to overlapping candidate keys" by ensuring that every determinant is a
superkey, thereby eliminating any FDs where a non-superkey determines even a part of another candidate key.

Diagrams/flowcharts

Normalization Hierarchy Flowchart (Textual Description):

Unnormalized Relation
|
V
1NF (Atomic values)
|
V
2NF (No partial dependencies)
|
V
3NF (No transitive dependencies on non-prime attributes)
|
V
BCNF (Every determinant is a superkey)

[Link] Page 101 of 159

 BCNF Violation Diagram (Textual Description): Consider a relation R(A, B, C) with candidate keys (A, B)
and (A, C) . Let there be an FD: B $\rightarrow$ C .
1. Is B a superkey of R ? No, because B does not determine A .

2. Is C a prime attribute? Yes, C is part of candidate key (A, C) . In this scenario:

This relation is in 3NF because B is not a superkey, but C is a prime attribute.

This relation is NOT in BCNF because B is not a superkey. To achieve BCNF, we would decompose R into
R1(B, C) and R2(A, B) .

Step-by-step breakdown: How to check if a relation is in BCNF

1. Identify all Candidate Keys (CKs) of the relation $R$. This is crucial as superkeys are derived from candidate keys.

2. List all Functional Dependencies (FDs) for the relation $R$ (including derived FDs if necessary). Focus on non-
trivial FDs ($X \rightarrow Y$ where $Y \not\subseteq X$).

3. For each non-trivial FD $X \rightarrow Y$ identified in step 2:

Check if $X$ is a superkey of $R$. To do this, compute the closure of $X$ ($X^+$). If $X^+$ contains all
attributes of $R$, then $X$ is a superkey.

If $X$ is NOT a superkey of $R$, then the relation $R$ is NOT in BCNF.
In this case, you need to decompose $R$.

Create two new relations:

$R_1 = X \cup Y$ (Determinant and what it determines)

$R_2 = (R - Y) \cup X$ (Remaining attributes, ensuring the determinant $X$ is kept for a lossless join)

Repeat the BCNF check for the newly formed relations $R_1$ and $R_2$ until all relations are in BCNF.

If $X$ IS a superkey of $R$ for all non-trivial FDs, then the relation $R$ IS in BCNF.

3. Properties & Characteristics

Key properties

Stricter than 3NF: Every relation in BCNF is also in 3NF, but not every 3NF relation is in BCNF.

Eliminates Redundancy based on FDs: BCNF removes all functional dependency-based redundancy. This means
that if a fact is determined by a set of attributes, those attributes must constitute a superkey.

Reduced Update Anomalies: Due to minimized redundancy, BCNF relations are less susceptible to update,
insertion, and deletion anomalies.

Every Determinant is a Superkey: This is the defining characteristic. If $X \rightarrow Y$ exists, then $X$ must be
capable of uniquely identifying any tuple in the relation.

Advantages & disadvantages

Advantages:
Maximum Redundancy Elimination: Achieves the highest level of redundancy reduction based on functional
dependencies, leading to more efficient storage.

Reduced Anomalies: Effectively eliminates update, insertion, and deletion anomalies that might still persist in
3NF relations with overlapping candidate keys.

Improved Data Integrity: Ensures that data dependencies are rigorously enforced, leading to a more consistent
and reliable database.

Simpler Structure: Each relation in BCNF tends to represent a single, independent entity or relationship type,
simplifying data understanding.

Disadvantages:

[Link] Page 102 of 159

 May not be Dependency Preserving: Decomposing a relation into BCNF might sometimes result in a set of
relations where not all original functional dependencies can be enforced merely by checking the FDs in the
individual decomposed relations. Some FDs might span across multiple decomposed relations. This can make
referential integrity checks more complex.

More Decompositions: Often requires more decomposition steps compared to 3NF, potentially leading to more
tables and more joins required for queries.

Computational Cost: Identifying all candidate keys and checking BCNF conditions can be computationally
intensive, especially for complex schemas with many attributes and FDs.

Lossy Decomposition Risk: If not done carefully, decomposition can lead to a lossy join, where joining the
decomposed relations might generate spurious tuples (tuples that were not in the original relation). The BCNF
decomposition algorithm must ensure losslessness.

4. Mathematical / Logical Representation

Important formulas

Formal Definition of BCNF: A relation $R$ is in BCNF if and only if for every non-trivial functional dependency $X
\rightarrow Y$ that holds in $R$, $X$ is a superkey of $R$.
Non-trivial FD: $X \rightarrow Y$ where $Y \not\subseteq X$.

Superkey: A set of attributes $K$ such that $K \rightarrow R$ (i.e., $K$ functionally determines all attributes in
$R$). Equivalently, the closure of $K$, $K^+$, contains all attributes of $R$.

Closure of a set of attributes $X$ ($X^+$): The set of all attributes functionally determined by $X$. This is
computed by iteratively applying the given functional dependencies.

Derivations (logical reasoning)

BCNF implies 3NF: If a relation $R$ is in BCNF, then for every non-trivial FD $X \rightarrow Y$, $X$ is a superkey.
The definition of 3NF states that for every non-trivial FD $X \rightarrow Y$, either $X$ is a superkey OR $Y$ is a
prime attribute. Since BCNF ensures that $X$ is always a superkey, the condition for 3NF (that either $X$ is a
superkey or $Y$ is prime) is automatically satisfied. Thus, if a relation is in BCNF, it is also in 3NF.

3NF does not always imply BCNF: Consider a relation $R(A, B, C)$ with functional dependencies $F = {A
\rightarrow B, B \rightarrow C}$. Let's assume the candidate key is $(A, C)$.

1. Check 3NF:
For $A \rightarrow B$: $A$ is not a superkey. Is $B$ a prime attribute? No, $B$ is not part of $(A,C)$.

For $B \rightarrow C$: $B$ is not a superkey. Is $C$ a prime attribute? Yes, $C$ is part of $(A,C)$.

Wait, there's an issue with the candidate key assumption. Let's make an example that clearly demonstrates the
"prime attribute" exception.

Correct example for 3NF but not BCNF: Relation $R(A, B, C)$ with FDs: $AB \rightarrow C$ and $C
\rightarrow B$. Candidate Keys:
$(A, C)^+$: With $C \rightarrow B$, $(A, C)^+ = {A, C, B}$. So $(A, C)$ is a candidate key.

$(A, B)^+$: With $AB \rightarrow C$, $(A, B)^+ = {A, B, C}$. So $(A, B)$ is a candidate key. Prime
attributes: $A, B, C$. (All attributes are prime in this specific setup).

1. Check 3NF:
FD: $AB \rightarrow C$. $AB$ is a superkey. (Condition satisfied)

FD: $C \rightarrow B$. $C$ is NOT a superkey (it doesn't determine $A$). Is $B$ a prime attribute? YES,
$B$ is part of candidate key $(A,B)$. So, 3NF is satisfied.

2. Check BCNF:
FD: $AB \rightarrow C$. $AB$ is a superkey. (BCNF condition satisfied)

[Link] Page 103 of 159

 FD: $C \rightarrow B$. $C$ is NOT a superkey. The BCNF condition fails. Therefore, $R(A, B, C)$ with
$AB \rightarrow C$ and $C \rightarrow B$ is in 3NF but not in BCNF.

5. Operations / Algorithms
Algorithm: BCNF Decomposition

Problem statement Given a relation $R$ and a set of functional dependencies $F$, decompose $R$ into a set of
relations $R_1, R_2, \ldots, R_n$ such that each $R_i$ is in BCNF and the overall decomposition is lossless.

Step-by-step algorithm

1. Initialize a set of relations Result = {$R$}.

2. While there is a relation $R_i$ in Result that is not in BCNF: a. Find a functional dependency $X \rightarrow Y$
that violates BCNF in $R_i$. This means $X$ is not a superkey of $R_i$, and $Y$ is not empty, and $X
\not\supseteq Y$ (non-trivial FD). b. Remove $R_i$ from Result . c. Create two new relations: * $R_{new1} = X
\cup Y$ * $R_{new2} = (R_i - Y) \cup X$ d. Add $R_{new1}$ and $R_{new2}$ to Result . e. (Crucial Step): For
each new relation (e.g., $R_{new1}$ and $R_{new2}$), compute the set of functional dependencies that hold in it
by projecting the original set of FDs $F$ onto its attributes. This involves finding the closure of all subsets of
attributes in the new relation based on $F$.

3. Repeat step 2 until all relations in Result are in BCNF.

Dry run example Let's use the common example: Relation $R(C, S, J, D, P)$ representing Course , Student ,
Instructor , Department , Project . Functional Dependencies $F = { C \rightarrow J, S \rightarrow D, JD
\rightarrow P }$ Let's assume the candidate key for $R$ is $(C, S)$.

1. Initial Result = {$R(C, S, J, D, P)$}.

2. Check $R$ for BCNF:

Candidate Key for $R$: $(C, S)$. $(C,S)^+ = {C, S, J, D, P}$ (using $C \rightarrow J$ and $S \rightarrow D$, and
$(C,S,J,D) \rightarrow P$ if we compute the transitive closure).

FD: $C \rightarrow J$. Is $C$ a superkey of $R$? No. Violation!

Decompose $R$ using $C \rightarrow J$:

$R_1 = C \cup J = (C, J)$

$R_2 = (R - J) \cup C = (C, S, D, P)$

Result = {$R_1(C, J)$, $R_2(C, S, D, P)$}.

3. Check $R_1(C, J)$ for BCNF:

FD: $C \rightarrow J$. Candidate Key: $(C)$. $C$ IS a superkey of $R_1$.

$R_1$ is in BCNF.

4. Check $R_2(C, S, D, P)$ for BCNF:

Projected FDs for $R_2$: $S \rightarrow D$, $JD \rightarrow P$ (from original $F$, restricted to $R_2$'s
attributes).

Candidate Key for $R_2$: $(C, S)$. $(C,S)^+ = {C, S, D, P}$ (using $S \rightarrow D$, and knowing that $J$ is
not in $R_2$, so $JD \rightarrow P$ becomes tricky if $J$ is needed. Let's assume for this example, we re-
evaluate and find a minimal key for $R_2$). If $J$ is not in $R_2$, $JD \rightarrow P$ cannot be directly used.
However, we have $S \rightarrow D$.

The FDs for $R_2$ derived from $F$ would be $S \rightarrow D$.

Candidate Key for $R_2$ based on $S \rightarrow D$: $(C, S)$.

[Link] Page 104 of 159

 FD: $S \rightarrow D$. Is $S$ a superkey of $R_2$? No ($S$ doesn't determine $C$ or $P$). Violation!

Decompose $R_2$ using $S \rightarrow D$:

$R_{2_1} = S \cup D = (S, D)$

$R_{2_2} = (R_2 - D) \cup S = (C, S, P)$

Result = {$R_1(C, J)$, $R_{2_1}(S, D)$, $R_{2_2}(C, S, P)$}.

5. Check $R_{2_1}(S, D)$ for BCNF:

FD: $S \rightarrow D$. Candidate Key: $(S)$. $S$ IS a superkey of $R_{2_1}$.

$R_{2_1}$ is in BCNF.

6. Check $R_{2_2}(C, S, P)$ for BCNF:

Projected FDs for $R_{2_2}$: None directly from $F$ involving only $C, S, P$. (Original $JD \rightarrow P$
cannot be used as $J$ is missing).

Candidate Key for $R_{2_2}$: $(C, S)$.

Since there are no non-trivial FDs where the determinant is not a superkey, $R_{2_2}$ is in BCNF.

7. Final BCNF Decomposition:

$R_1(C, J)$

$R_{2_1}(S, D)$

$R_{2_2}(C, S, P)$ All relations are now in BCNF.

Pseudocode

function BCNF_Decompose(Relation R, SetOfFDs F):

Result = {R}

// Loop until no relation in Result violates BCNF

while exists R_i in Result such that R_i is NOT in BCNF:

// Find a BCNF violating FD in R_i

// A BCNF violating FD X -> Y means:
// 1. X -> Y is a non-trivial FD holding in R_i (Y is not subset of X)
// 2. X is NOT a superkey of R_i

Find X -> Y in F+ restricted to R_i.attributes where:

(Y is not subset of X) AND (X is NOT_SUPERKEY(R_i, F))

// If no such FD found, something is wrong or R_i is actually in BCNF.

// This 'find' assumes one will always be found if R_i is not in BCNF.

remove R_i from Result

// Decompose R_i based on X -> Y

R_new1 = X U Y
R_new2 = (R_i.attributes - Y) U X // Note: R_i.attributes refers to the schem

add R_new1 to Result

add R_new2 to Result

// Important: FDs for R_new1 and R_new2 need to be inferred/projected.

// This step is conceptually critical but complex to implement generally.

[Link] Page 105 of 159

 // For manual dry runs, we re-evaluate FDs that apply to new schemas.

return Result

function IS_SUPERKEY(Attributes X, Relation R_schema, SetOfFDs F):

Compute closure X+ using F restricted to R_schema.attributes
if X+ contains all attributes of R_schema:
return true
else:
return false

Code (C++/Java/Python) Providing a full, runnable code implementation for a general BCNF decomposition
algorithm is highly complex as it requires sophisticated functions for:

1. Computing attribute closures ($X^+$).

2. Finding all candidate keys for a given relation and FDs.

3. Projecting FDs onto a new relation schema.

4. Handling set operations on attributes.

Given the constraint "No JSON, no code fences like ```", I cannot provide runnable code. However, the conceptual
implementation in a language like Python would involve:

Representing relations: As sets of attribute names (strings).

Representing FDs: As tuples of (left-hand side attributes, right-hand side attributes), where LHS and RHS are
sets/tuples of attribute names.

compute_closure(attributes_set, all_fds) function: Takes a set of attributes and all known FDs,
and iteratively expands the set of determined attributes until no new attributes can be added. This is the core for
checking superkeys.

is_superkey(attributes_set, relation_schema, all_fds) function: Calls compute_closure

and checks if the result matches the relation_schema .

find_bcnf_violation(relation_schema, all_fds) function: Iterates through all possible non-trivial

FDs within the relation_schema (potentially requiring a powerset iteration or inferring FDs) and uses
is_superkey to find a violation.

Main bcnf_decompose function: Implements the while loop, calling find_bcnf_violation and then
performing the set operations for decomposition.

The complexity of correctly managing projected FDs for new relations is often the hardest part programmatically.

6. Complexity Analysis
Time complexity (Best, Worst, Average)
Finding Candidate Keys: In the worst case, this can be exponential with respect to the number of attributes.
Identifying a minimal set of candidate keys is NP-hard.

Checking BCNF for a single FD: Requires computing the closure of the determinant ($X^+$). Computing closure is
polynomial in the number of attributes and functional dependencies ($O(|A| \cdot |F|)$, where $|A|$ is the number of
attributes and $|F|$ is the number of FDs).

Overall Decomposition: The number of decomposition steps can vary. In the worst case, it could be $O(N^2)$
where $N$ is the number of attributes, if each step resolves only one attribute. Given the complexity of finding
candidate keys and checking all FDs, the overall BCNF decomposition algorithm is computationally intensive.
Practically, it's often done with heuristics or simplified rules for large schemas.

Space complexity

[Link] Page 106 of 159

 Storing the relations and their attributes: The total number of attributes remains the same, but they are distributed
across multiple relations.

Storing Functional Dependencies: $O(|F| \cdot |A|)$ where $|F|$ is the number of FDs and $|A|$ is the maximum
number of attributes in an FD.

The size of the Result set (number of relations) can grow.

Comparison with alternatives

3NF (Third Normal Form):
Pros of 3NF: Always guarantees a lossless and dependency-preserving decomposition. Easier to achieve.

Cons of 3NF: May leave some redundancy, especially in cases with overlapping candidate keys where a non-
superkey determines a prime attribute.

BCNF vs. 3NF: BCNF is stricter and achieves better redundancy elimination. However, it does not guarantee
dependency preservation. If dependency preservation is a critical requirement, 3NF might be preferred, even if it
means tolerating a small amount of redundancy.

4NF (Fourth Normal Form) and 5NF (Fifth Normal Form):

These normal forms address more complex dependencies beyond functional dependencies, specifically multi-
valued dependencies (4NF) and join dependencies (5NF).

BCNF focuses solely on functional dependencies. If multi-valued or join dependencies are present and cause
issues, 4NF or 5NF would be necessary.

7. Examples
Solved problem (Medium) Relation: R(Student, Course, Instructor, Department) Functional
Dependencies:

1. Student $\rightarrow$ Department (Each student belongs to one department)

2. Instructor $\rightarrow$ Department (Each instructor works for one department)

3. (Student, Course) $\rightarrow$ Instructor (For a specific student in a specific course, there is one
instructor)

Step-by-step BCNF Decomposition:

1. Find Candidate Keys for R:

Let's check (Student, Course) : (Student, Course)+ = {Student, Course} Using Student
$\rightarrow$ Department : {Student, Course, Department} Using (Student, Course)
$\rightarrow$ Instructor : {Student, Course, Department, Instructor} All attributes
determined. So, (Student, Course) is a Candidate Key.

Are there others? Let's check (Instructor, Student) : (Instructor, Student)+ = {Instructor,
Student} Using Instructor $\rightarrow$ Department : {Instructor, Student, Department}
Using Student $\rightarrow$ Department : {Instructor, Student, Department} Cannot
determine Course . So (Instructor, Student) is not a CK.

Primary Candidate Key: (Student, Course)

2. Check R for BCNF Violations:

FD: (Student, Course) $\rightarrow$ Instructor . (Student, Course) IS a superkey. (BCNF OK)

FD: Student $\rightarrow$ Department . Is Student a superkey of R? No, Student does not
determine Course or Instructor . Violation!

FD: Instructor $\rightarrow$ Department . Is Instructor a superkey of R? No, Instructor does

not determine Student or Course . Violation!

[Link] Page 107 of 159

 3. Decompose using Student $\rightarrow$ Department (first violation found):

R_1 = Student $\cup$ Department = (Student, Department)

R_2 = (R - Department) $\cup$ Student = (Student, Course, Instructor) Current

decomposition: { R_1(Student, Department), R_2(Student, Course, Instructor) }

4. Check R_1(Student, Department) for BCNF:

FD: Student $\rightarrow$ Department .

Candidate Key: (Student) . Student IS a superkey of R_1 .

R_1 is in BCNF.

5. Check R_2(Student, Course, Instructor) for BCNF:

Projected FDs for R_2 : (Student, Course) $\rightarrow$ Instructor

Candidate Key: (Student, Course) .

FD: (Student, Course) $\rightarrow$ Instructor . (Student, Course) IS a superkey of R_2 .

R_2 is in BCNF.

Wait! We missed Instructor $\rightarrow$ Department from the original set of FDs. Department is not in
R_2 , so this FD is no longer directly violated in R_2 . But is it still represented? The original decomposition strategy
ensures losslessness but doesn't guarantee dependency preservation. Here, Instructor $\rightarrow$
Department is lost from R_1 and R_2 . This is a classic trade-off with BCNF.

Let's re-evaluate using the problematic FD Instructor $\rightarrow$ Department if we started with it first, or if it
appeared in one of the sub-relations. In our example, Department was removed from R_2 .

Let's use a different example that demonstrates the overlapping key problem more directly, as the above one became
3NF compliant and BCNF also if Instructor $\rightarrow$ Department is externalized.

Revised Example: R(Student, Course, Instructor) FDs:

1. (Student, Course) $\rightarrow$ Instructor (A student in a course has one instructor)

2. Instructor $\rightarrow$ Course (Each instructor teaches only one course, simplification for this example)

3. Find Candidate Keys for R:

Let's check (Student, Instructor) : (Student, Instructor)+ = {Student, Instructor}

Using Instructor $\rightarrow$ Course : {Student, Instructor, Course} So, (Student,
Instructor) is a Candidate Key.

Let's check (Student, Course) : (Student, Course)+ = {Student, Course} Using (Student,
Course) $\rightarrow$ Instructor : {Student, Course, Instructor} So, (Student, Course)
is also a Candidate Key.

Both (Student, Instructor) and (Student, Course) are candidate keys.

Prime attributes: Student , Course , Instructor (all attributes are part of some candidate key).

4. Check R for BCNF Violations:

FD: (Student, Course) $\rightarrow$ Instructor . (Student, Course) IS a superkey. (BCNF OK)

FD: Instructor $\rightarrow$ Course . Is Instructor a superkey of R? No, Instructor does not
determine Student . Violation!

[Link] Page 108 of 159

 Is it in 3NF? Yes, because Instructor is not a superkey, but Course IS a prime attribute (part of
(Student, Course) ). So, this relation is in 3NF but NOT in BCNF.

5. Decompose using Instructor $\rightarrow$ Course :

R_1 = Instructor $\cup$ Course = (Instructor, Course)

R_2 = (R - Course) $\cup$ Instructor = (Student, Instructor) Current decomposition: {

R_1(Instructor, Course), R_2(Student, Instructor) }

6. Check R_1(Instructor, Course) for BCNF:

FD: Instructor $\rightarrow$ Course .

Candidate Key: (Instructor) . Instructor IS a superkey of R_1 .

R_1 is in BCNF.

7. Check R_2(Student, Instructor) for BCNF:

Projected FDs for R_2 : None directly from original FDs.

Candidate Key: (Student, Instructor) .

Since no non-trivial FDs exist where the determinant is not a superkey, R_2 is in BCNF.

8. Final BCNF Decomposition:

R_1(Instructor, Course)

R_2(Student, Instructor)

This decomposition is lossless and achieves BCNF. Note that the FD (Student, Course) $\rightarrow$
Instructor is not directly preserved in either R_1 or R_2 . To check it, you would need to join R_1 and R_2 .

8. Common Mistakes & Edge Cases

Where students go wrong

Confusing 3NF with BCNF: The most common mistake is forgetting the "prime attribute" exception of 3NF. If a
determinant $X$ is not a superkey, but the determined attribute $Y$ is part of some candidate key, the relation is in
3NF but not BCNF.

Incorrectly Identifying Candidate Keys: All normalization steps heavily rely on correctly finding all candidate keys.
A mistake here cascades through the entire process.

Failing to Project FDs Correctly: After decomposition, the FDs for the new relations must be derived from the
original set of FDs, restricted to the attributes of the new relations. Simply dropping FDs because their attributes are
split is incorrect. This requires computing closures for subsets of attributes in the new relations.

Not Ensuring Lossless Decomposition: When decomposing $R$ based on $X \rightarrow Y$, the new relations
must be $R_1 = X \cup Y$ and $R_2 = (R - Y) \cup X$. Crucially, keeping $X$ in $R_2$ ensures that the natural join of
$R_1$ and $R_2$ reconstructs the original relation without spurious tuples. Forgetting to include $X$ in $R_2$ leads
to a lossy decomposition.

Checking BCNF against the original FDs for sub-relations: You must consider the FDs that apply to the attributes
of the current sub-relation being checked, not the full original set for the original schema.

Special cases

Relations with only trivial FDs: If a relation has no non-trivial functional dependencies, it is inherently in BCNF (and
all other normal forms).

[Link] Page 109 of 159

 Relations with only one Candidate Key: If a relation has only one candidate key, and it is already in 3NF, then it is
automatically in BCNF. The "prime attribute" exception of 3NF only becomes relevant when there are multiple,
overlapping candidate keys.

Dependency Preservation vs. Losslessness: BCNF decomposition always guarantees a lossless join. However, it
does not always guarantee dependency preservation. Sometimes, to achieve BCNF, you might have to decompose in
a way that some original FDs cannot be checked by looking only at the individual decomposed relations. In such
cases, 3NF (which always guarantees both) might be a pragmatic choice if dependency preservation is deemed more
important than absolute minimal redundancy.

9. Real-Life Applications
How this concept is used in real world
Core Database Design for Transactional Systems (OLTP): BCNF is widely applied in designing databases for
systems that handle frequent, concurrent transactions, such as:
Banking Systems: To ensure that financial transactions are recorded accurately and consistently, preventing
anomalies like double-debiting or incorrect balances.

E-commerce Platforms: To manage product inventories, customer orders, and payment information without
redundancy or inconsistency.

Healthcare Systems: For patient records, appointment scheduling, and treatment plans, where data integrity is
critical for patient safety.

Inventory Management: To accurately track stock levels, supplier information, and product details.

Enterprise Resource Planning (ERP) and Customer Relationship Management (CRM) Systems: These large,
integrated systems manage vast amounts of interconnected data across different business functions. BCNF ensures
the foundational data models are robust and consistent.

Data Quality Initiatives: In any scenario where high data quality is a primary concern, applying BCNF helps
eliminate underlying structural causes of data inconsistencies.

Education and Certification: Understanding BCNF is a standard requirement for database professionals and is
frequently tested in database certification exams, reflecting its fundamental importance in the field.

10. Practice Problems

Easy Relation: R(A, B, C) FDs: {A -> B, B -> C} Candidate Key: (A) Is R in BCNF? If not, decompose it
into BCNF.

Medium Relation: R(P, Q, R, S) FDs: {P -> Q, (P, Q) -> R, S -> R} Candidate Keys: (P, S) (Check
this) Is R in BCNF? If not, perform the BCNF decomposition.

Hard Relation: R(EmpID, DeptName, Building, DeptHead, ProjectID, WorkHours) FDs:

1. EmpID -> DeptName

2. DeptName -> (Building, DeptHead)

3. (EmpID, ProjectID) -> WorkHours

4. DeptHead -> Building (Assume a department head manages a single building)

Analyze the relation, find all candidate keys, determine if it's in BCNF, and if not, decompose it into BCNF. Pay close
attention to transitive dependencies and prime attributes.

11. Summary / Key Points

Quick revision of points covered

[Link] Page 110 of 159

 BCNF is a stricter form of 3NF, eliminating more specific types of data redundancy.

The core rule: For every non-trivial functional dependency $X \rightarrow Y$, $X$ MUST be a superkey of the
relation.

It addresses anomalies that can still exist in 3NF when a relation has multiple overlapping candidate keys.

The decomposition algorithm is iterative: find a violating FD, split the relation, and re-check the new relations.

BCNF decomposition is always lossless but may not always be dependency-preserving. This is a key trade-off.

It is a crucial step in designing highly normalized, consistent, and robust databases in real-world applications.

Highlighted formulas and shortcuts

BCNF Condition: For $X \rightarrow Y$, $X$ must be a superkey.

Decomposition Rule for $X \rightarrow Y$ violation in $R$:

1. Create $R_1 = X \cup Y$.

2. Create $R_2 = (R - Y) \cup X$.

Superkey Check: Compute $X^+$. If $X^+$ contains all attributes of $R$, then $X$ is a superkey.

BCNF vs 3NF: If a relation is in 3NF and has only one candidate key, it is automatically in BCNF. If it has multiple
candidate keys, check carefully for BCNF violations where a non-superkey determines a prime attribute.

Higher Normal Forms (4NF, 5NF)

Brief introduction to Multivalued Dependencies and Fourth Normal Form (4NF), and Join Dependencies and Fifth Normal
Form (5NF).

1. Introduction
Definition
Normalization is the process of organizing the columns and tables of a relational database to minimize data
redundancy and improve data integrity. Higher Normal Forms, specifically Fourth Normal Form (4NF) and Fifth
Normal Form (5NF), deal with more complex types of dependencies that are not addressed by BCNF (Boyce-Codd
Normal Form) and lower normal forms.

Fourth Normal Form (4NF): A relation is in 4NF if it is in BCNF and contains no nontrivial multivalued dependencies
(MVDs). In simple terms, it means that for any multi-valued dependency A ->> B, A is a superkey. If A is not a
superkey, then B must be a trivial dependency (either B is a subset of A, or A union B is all attributes of the relation).

Fifth Normal Form (5NF) (also known as Project-Join Normal Form - PJNF): A relation is in 5NF if it is in 4NF and
contains no nontrivial join dependencies (JDs). This means that a table cannot be losslessly decomposed into smaller
tables, and then reconstructed by joining them, unless the tables directly represent the original table's primary key
and its attributes.

Why it is needed (real-life analogy if possible)

While BCNF eliminates most update anomalies, certain situations involving multi-valued facts can still lead to
redundancy and update problems. 4NF and 5NF address these specific, subtler forms of redundancy.

Analogy: Imagine a list of ingredients for cooking different dishes.

If you have a recipe for "Pasta" that uses "Tomato Sauce" and "Cheese", and another recipe for "Pizza" that also
uses "Tomato Sauce" and "Cheese", this is fine.

Now, imagine a recipe book (our database) that lists "Dish", "Main Ingredient", "Optional Topping".
If "Pasta" can have "Tomato Sauce" OR "Pesto", and also "Cheese" OR "Meatballs". If we store these in one
row: (Pasta, Tomato Sauce, Cheese), (Pasta, Tomato Sauce, Meatballs), (Pasta, Pesto, Cheese), (Pasta, Pesto,
Meatballs). This leads to redundancy if "Tomato Sauce" and "Pesto" are independent of "Cheese" and

[Link] Page 111 of 159

 "Meatballs". This independence is what a Multi-Valued Dependency captures. 4NF cleans this up by
separating these independent multi-valued facts.

5NF goes a step further. If a fact about "Dish-Main Ingredient-Optional Topping" can only be inferred by
combining three separate facts like "Dish-Main Ingredient", "Main Ingredient-Optional Topping", and "Optional
Topping-Dish", and there's no direct single fact linking all three without redundancy, then 5NF ensures you don't
store redundant combinations that can be derived. It's like ensuring you don't list a complete meal combination if
that combination can be perfectly and non-redundantly represented by separate facts about "Dish-Cuisine Type",
"Cuisine Type-Main Ingredient", and "Main Ingredient-Dish".

Applications
Higher normal forms are particularly useful in databases that model complex real-world entities with multiple
independent attributes, where multi-valued facts exist.

Examples include scientific databases, manufacturing systems (bill of materials), and any domain where entities can
have multiple, independent properties.

They are less commonly applied in general business applications where BCNF is often sufficient, but are crucial for
achieving absolute minimal redundancy and high data integrity in specific, complex scenarios.

2. Theory Explanation
In-depth explanation
Multi-Valued Dependency (MVD):
A multi-valued dependency (MVD) X ->> Y exists in a relation R if, for any two tuples t1 and t2 in R such that
t1[X] = t2[X], there exist tuples t3 and t4 in R such that:
t1[X] = t2[X] = t3[X] = t4[X]

t3[Y] = t1[Y] and t3[R-X-Y] = t2[R-X-Y]

t4[Y] = t2[Y] and t4[R-X-Y] = t1[R-X-Y]

In simpler terms, if for a given value of X, there is a set of Y values and a set of Z values (where Z = R-X-Y), and
the set of Y values is independent of the set of Z values, then we have an MVD X ->> Y and X ->> Z.

Trivial MVD: X ->> Y is trivial if Y is a subset of X, or X union Y is all attributes of the relation.

Fourth Normal Form (4NF):

A relation R is in 4NF if, whenever an MVD X ->> Y holds in R, then X is a superkey for R.

If X is not a superkey, and X ->> Y is a non-trivial MVD, then the relation is not in 4NF and should be
decomposed. The decomposition strategy is to replace R with two relations: R1 = (X union Y) and R2 = (X union
(R-X-Y)). This decomposition is always lossless and dependency-preserving for MVDs.

Join Dependency (JD):

A join dependency (JD) JD(R1, R2, ..., Rk) exists on a relation R if R can be losslessly decomposed into R1, R2, ...,
Rk, such that R = R1 join R2 join ... join Rk. This means that the projection of R onto Ri for each i, when joined
back together, yields exactly R, and not a larger relation (no spurious tuples).

Every MVD is a special case of a JD. If X ->> Y, then R can be losslessly decomposed into (X union Y) and (X union
(R-X-Y)).

Fifth Normal Form (5NF):

A relation R is in 5NF if it is in 4NF and contains no nontrivial join dependencies.

A JD is nontrivial if none of the R_i components are superkeys for R. If a nontrivial JD exists, it implies that the
information can be split into smaller relations and accurately reassembled without redundancy.

5NF is the ultimate goal in normalization, ensuring that every possible source of redundancy based on functional,
multi-valued, and join dependencies is eliminated. It means that the relation cannot be decomposed into any
smaller relations without loss of information.

Diagrams/flowcharts (describe in text if not possible to draw)

Flowchart for Normalization Path (leading to 4NF/5NF):

[Link] Page 112 of 159

 1. Start with an unnormalized relation.

2. Is the relation in 1NF? (No repeating groups) -> If no, transform to 1NF.

3. Is the relation in 2NF? (No partial dependencies) -> If no, decompose to 2NF.

4. Is the relation in 3NF? (No transitive dependencies) -> If no, decompose to 3NF.

5. Is the relation in BCNF? (Every determinant is a superkey) -> If no, decompose to BCNF.

6. Is the relation in 4NF? (No nontrivial MVDs) -> If no, identify MVD X ->> Y where X is not a superkey.
Decompose into R1(X, Y) and R2(X, R-X-Y).

7. Is the relation in 5NF? (No nontrivial JDs) -> If no, identify JD R = R1 join R2 join ... join Rk where no Ri is a
superkey. Decompose into R1, R2, ..., Rk.

Step-by-step breakdown
Decomposition to 4NF:
1. Start with a relation R that is in BCNF.

2. Identify all multi-valued dependencies (MVDs) in R.

3. For each non-trivial MVD, X ->> Y, check if X is a superkey of R.

4. If X is not a superkey, then R is not in 4NF. Decompose R into two new relations:
R1 with attributes (X union Y)

R2 with attributes (X union (R - X - Y))

5. Repeat steps 2-4 for the newly created relations until all relations are in 4NF.

Decomposition to 5NF:
1. Start with a relation R that is in 4NF.

2. Identify all join dependencies (JDs) in R.

3. For each non-trivial JD, JD(R1, R2, ..., Rk), check if any Ri (the attributes of a projected relation) is a superkey for R.

4. If no Ri is a superkey, then R is not in 5NF. Decompose R into the relations R1, R2, ..., Rk.

5. Repeat steps 2-4 for the newly created relations until all relations are in 5NF.

3. Properties & Characteristics

Key properties
Lossless Join Decomposition: Decomposition into 4NF or 5NF is always lossless. This means that if you decompose
a relation R into R1, R2, ..., Rk, then the natural join of R1, R2, ..., Rk will precisely reconstruct the original relation R,
without generating any spurious tuples (extra rows).

Dependency Preservation (for 4NF): Decompositions into 4NF are often dependency-preserving for MVDs and
FDs.

Dependency Preservation (for 5NF): Decompositions into 5NF might not always be dependency-preserving for all
functional dependencies, though it preserves the join dependency itself.

Elimination of Redundancy: 4NF eliminates redundancy arising from multi-valued facts that are independent of
each other. 5NF further eliminates redundancy arising from join dependencies, ensuring that information about a
relationship can only be derived by joining its irreducible components.

Irreducibility: A relation in 5NF is considered irreducible in the sense that it cannot be losslessly decomposed into
smaller relations based on join dependencies.

Advantages & disadvantages

Advantages:
Maximal Data Integrity: Achieves the highest level of data integrity by removing all types of functional, multi-
valued, and join dependency-based redundancies.

Minimal Redundancy: Ensures that each fact is stored exactly once, reducing storage space and avoiding update
anomalies.

[Link] Page 113 of 159

 Easier Maintenance: Reduces the chances of inconsistent data, making the database easier to maintain and
update.

Clearer Semantics: Each relation in 4NF/5NF typically represents a single, well-defined entity or relationship,
improving the clarity of the database schema.

Disadvantages:
Increased Number of Tables: Achieving higher normal forms often results in a large number of smaller tables,
which can make the database schema more complex.

Performance Overhead: More tables mean more joins are required to retrieve information that was previously in
a single table. This can lead to increased query complexity and potential performance degradation due to
multiple join operations.

Complexity of Identification: Identifying MVDs and especially JDs can be very challenging and time-consuming,
requiring a deep understanding of the data semantics.

Less Common in Practice: For many business applications, BCNF is considered sufficient. The benefits of 4NF
and 5NF often do not outweigh the cost of increased complexity and potential performance impact unless
specific MVDs/JDs are clearly identified and problematic.

4. Mathematical / Logical Representation

Important formulas
Axioms for MVDs (Completeness and Soundness via Project-Join Rules):
Reflexivity: If Y is a subset of X, then X ->> Y.

Augmentation: If X ->> Y, then XZ ->> YZ for any Z.

Transitivity: If X ->> Y and Y ->> Z, then X ->> (Z - Y). (Note: This is not as straightforward as FD transitivity and
can be complex, often stated with additional conditions or as an inference rule.)

Complementation: If X ->> Y, then X ->> (R - X - Y). This is a crucial property unique to MVDs.

Union: If X ->> Y and X ->> Z, then X ->> YZ.

Decomposition: If X ->> YZ, then X ->> Y and X ->> Z.

Replication: If X -> Y (FD), then X ->> Y (MVD). (Every FD is an MVD).

Coalescence: If X ->> Y and Y -> Z (FD), and Z is a subset of Y, and there's no common attribute between Y and
Z, then X -> Z. (This is a simplified statement; the full rule is more complex).

Relationship between FD, MVD, and JD:

Every functional dependency (FD) X -> Y implies a multi-valued dependency (MVD) X ->> Y.

Every multi-valued dependency (MVD) X ->> Y implies a join dependency (JD) JD(X union Y, X union (R-X-Y)).

Therefore, the hierarchy is FD -> MVD -> JD in terms of expressiveness.

Derivations (if any)

Proof of Lossless Join Decomposition for MVDs (for 4NF):
Given a relation R with an MVD X ->> Y where X is not a superkey. We decompose R into R1 = (X union Y) and
R2 = (X union (R-X-Y)).

The decomposition is lossless if R = R1 join R2. This property directly follows from the definition of an MVD itself.
The definition of MVD states that if t1[X]=t2[X], then there exist t3, t4 where t3[Y]=t1[Y] and t3[R-X-Y]=t2[R-X-Y]
(and vice-versa for t4). This precise "tuple-splitting and rejoining" behavior is what ensures losslessness when
decomposing based on MVDs. If we join R1 and R2 on X, we will reconstruct all original tuples of R and no
spurious ones.

5. Operations / Algorithms
For the context of 4NF/5NF, there isn't a single "algorithm" in the typical sense (like sorting or searching). Instead, it's a
design process involving identification and decomposition.

[Link] Page 114 of 159

 Problem statement

Given a relation R with a set of attributes A and a set of functional dependencies (FDs) and multi-valued
dependencies (MVDs), decompose R into a set of relations R1, R2, ..., Rk such that each Ri is in 4NF (or 5NF).

Step-by-step algorithm (Conceptual for 4NF)

1. Normalize to BCNF: First, ensure the relation R is in BCNF. This handles all FDs.

2. Identify MVDs: Examine the relation R and its attributes to identify any non-trivial MVDs, X ->> Y, where Y is not a
subset of X, and X union Y is not equal to all attributes of R. This step requires understanding the real-world
semantics of the data.

3. Check Superkey: For each identified non-trivial MVD X ->> Y, determine if X is a superkey for R.

4. Decompose if Not 4NF: If X is not a superkey, then R is not in 4NF. Decompose R into two new relations:
R1(X union Y)

R2(X union (R - X - Y))

5. Recursively Apply: Apply the same steps (2-4) to the newly created relations R1 and R2 until all resulting relations
are in 4NF.

Dry run example (for 4NF)

Relation: CourseRegistration (StudentID, CourseName, Instructor, Hobby)

Attributes: S, C, I, H

Dependencies:
S -> C (A student takes a specific course) - Let's assume a simpler scenario where StudentID uniquely identifies
a student's main course.

S ->> I (A student can be taught by multiple instructors for different courses, or one student can be
associated with multiple instructors independently of the course they take, e.g., for different subjects not tracked
here)

S ->> H (A student can have multiple hobbies, independent of their courses or instructors)

Assumptions: StudentID is the key for FDs. For MVDs, we assume that for a given StudentID , the set of
Instructor s they are associated with is independent of the set of Hobby s they have.

Initial Check:
Is S a key for CourseRegistration ? No, because S does not uniquely determine I or H (as they are
multi-valued). So, a potential key could be (S, C, I, H) .

S -> C implies S is not a superkey for the full table.

Let's consider a scenario where (S, C) is the primary key.

Problem: We have MVDs S ->> I and S ->> H . S is not a superkey of CourseRegistration .

Decomposition steps for 4NF:

1. Check BCNF: Assume we've already reached BCNF, so all FDs are fine. The issue here is MVDs.

2. Identify MVD: We have S ->> I (Student ->> Instructor) and S ->> H (Student ->> Hobby). These are
non-trivial.

3. Check Superkey: S is not a superkey for CourseRegistration .

4. Decompose:
Take S ->> I . Since S is not a superkey, decompose CourseRegistration (S, C, I, H) into:
Student_Instructor (S, I)

Student_Course_Hobby (S, C, H) (Attributes R - S - I)

[Link] Page 115 of 159

 Now, consider Student_Course_Hobby (S, C, H) . It still has the MVD S ->> H , and S is not a
superkey (e.g., if (S, C) is a key).

Decompose Student_Course_Hobby based on S ->> H into:

Student_Course (S, C)

Student_Hobby (S, H) (Attributes R - S - H)

5. Final Relations in 4NF:

Student_Instructor (S, I)

Student_Course (S, C)

Student_Hobby (S, H)

Each of these new relations is now in 4NF because:

Student_Instructor : S is a superkey (or part of one for (S, I) ). No MVDs.

Student_Course : S is a superkey (or part of one for (S, C) ). No MVDs.

Student_Hobby : S is a superkey (or part of one for (S, H) ). No MVDs.

Pseudocode (for 4NF decomposition)

Function DecomposeTo4NF(Relation R, SetOfMVDs M)

If R is already in BCNF (pre-condition, not explicitly checked here)
For each MVD X ->> Y in M
If X ->> Y is non-trivial AND X is not a superkey of R
// Decompose R
R1 = CreateRelation(X union Y)
R2 = CreateRelation(X union (Attributes(R) - X - Y))

// Recursively normalize the new relations

DecomposeTo4NF(R1, M)
DecomposeTo4NF(R2, M)

// Replace R with R1 and R2 in the schema

Return {R1, R2}
End For
Return {R} // R is already in 4NF
End Function

Code (C++/Java/Python)
Directly writing C++/Java/Python code without code fences for a normalization algorithm like this is not standard or
practical, as normalization is primarily a database design process rather than a runtime algorithm implemented
directly in application code. The "code" for normalization is the resulting relational schema and its DDL (Data
Definition Language) statements (e.g., CREATE TABLE ).

Programmatic approaches might exist in specialized database design tools to analyze a schema for dependencies
and suggest decompositions, but these are complex tools themselves.

Instead, the "code" that results from this process would be CREATE TABLE statements in SQL:
CREATE TABLE Student_Instructor (StudentID INT, InstructorName VARCHAR(255),
PRIMARY KEY (StudentID, InstructorName));

CREATE TABLE Student_Course (StudentID INT, CourseName VARCHAR(255), PRIMARY KEY

(StudentID, CourseName));

CREATE TABLE Student_Hobby (StudentID INT, HobbyName VARCHAR(255), PRIMARY KEY

(StudentID, HobbyName));

[Link] Page 116 of 159

 6. Complexity Analysis
Time complexity (Best, Worst, Average)
Analyzing the "time complexity" of normalization is different from traditional algorithms. It's more about the
cognitive and design effort.

Identification of MVDs/JDs: This is the most complex part. It involves understanding the data semantics, which is a
manual, human-intensive process. There's no fixed algorithmic time complexity; it depends on the complexity of the
domain and the skill of the database designer. In the worst case, for a schema with 'n' attributes, the number of
potential dependencies (FDs, MVDs, JDs) is exponential, making automated discovery highly complex.

Decomposition: Once dependencies are identified, the decomposition step itself is straightforward, involving
projection of attributes. This part is relatively fast, perhaps O(number of attributes).

Overall: The "time complexity" is dominated by the human effort in identifying and verifying dependencies.

Space complexity
Schema Representation: The space to represent the schema (attributes, dependencies) is relatively small.

Resulting Database: Normalization aims to reduce redundancy, so it can potentially reduce the space complexity of
the stored data, especially when dealing with many redundant tuples. However, it might slightly increase the space
required for metadata (more table definitions, indices).

Comparison with alternatives

Alternatives to 4NF/5NF: Not normalizing to these forms means staying at BCNF or lower.

Comparison:
BCNF: Easier to achieve, fewer tables, potentially better query performance for some common queries (fewer
joins). However, it leaves some MVD-based and JD-based redundancies that 4NF/5NF eliminate.

Denormalization: A design choice to intentionally introduce redundancy (moving away from higher normal
forms) for performance reasons. This can be faster for read-heavy applications but increases the risk of update
anomalies and requires careful management.

4NF and 5NF offer the most robust logical design for data integrity but come with increased complexity and
potential performance trade-offs, making them less frequently applied than 3NF or BCNF.

7. Examples
At least 1–2 solved problems (small, medium, complex)

Problem 1 (Small - 4NF):

Relation: FacultySkills (ProfessorID, Course, Skill)

Dependencies:
ProfessorID ->> Course (A professor can teach multiple courses)

ProfessorID ->> Skill (A professor can have multiple skills, independent of the courses they teach)

Sample Data:
(101, DBMS, Java)

(101, DBMS, Python)

(101, OS, Java)

(101, OS, Python)

Analysis:
ProfessorID is not a superkey for FacultySkills .

We have two non-trivial MVDs: ProfessorID ->> Course and ProfessorID ->> Skill . The set of
courses taught by a professor is independent of the set of skills they possess.

[Link] Page 117 of 159

 Since ProfessorID is not a superkey, FacultySkills is not in 4NF.

Solution (Decomposition to 4NF):

Decompose FacultySkills based on ProfessorID ->> Course .
Professor_Course (ProfessorID, Course)

Professor_Skill (ProfessorID, Skill)

Now, both Professor_Course and Professor_Skill are in 4NF.

Professor_Course : The only MVD is ProfessorID ->> Course , and ProfessorID is a
superkey (as (ProfessorID, Course) forms a compound key).

Professor_Skill : The only MVD is ProfessorID ->> Skill , and ProfessorID is a superkey
(as (ProfessorID, Skill) forms a compound key).

The original table's content is perfectly represented by:

Professor_Course : (101, DBMS), (101, OS)

Professor_Skill : (101, Java), (101, Python)

Problem 2 (Medium - 5NF):

Relation: Agent_Company_Product (Agent, Company, Product)

Scenario: An agent represents a company, which sells a product. A specific agent only sells certain products. A
company only sells certain products. And a specific agent can only sell for a company if that company sells
products that the agent sells.

Dependencies: This scenario leads to a non-trivial Join Dependency that cannot be inferred from MVDs. It
implies that (Agent, Company, Product) can be losslessly decomposed into three binary relations and rejoined:
JD (Agent_Company, Company_Product, Product_Agent)

This means: Agent_Company_Product = pi(Agent, Company) JOIN pi(Company, Product)

JOIN pi(Product, Agent)

Where pi denotes projection.

There are no MVDs like Agent ->> Company or Agent ->> Product because the relationships are
mutually dependent.

Analysis:
Assume Agent_Company_Product is already in 4NF (i.e., no MVDs where the determinant is not a
superkey).

The relation expresses the rule: "An agent sells a product for a company IF AND ONLY IF that agent is
authorized to sell for that company, AND that company sells that product, AND that agent is authorized to
sell that product." This specific three-way constraint suggests a Join Dependency.

If we have (Agent A, Company C, Product P) in the table, it means A sells P for C.

This JD is non-trivial because neither (Agent, Company), (Company, Product), nor (Product, Agent) alone is a
superkey for the original relation.

Solution (Decomposition to 5NF):

Decompose Agent_Company_Product into three binary relations:
Agent_Company (Agent, Company) (Who represents whom)

Company_Product (Company, Product) (Who sells what)

Product_Agent (Product, Agent) (What agent sells what product)

Each of these resulting relations will be in 5NF. This decomposition is lossless because the original constraint
is precisely this join dependency.

[Link] Page 118 of 159

 8. Common Mistakes & Edge Cases
Where students go wrong
Confusing MVD with FD: Students often struggle to distinguish between X -> Y (FD) and X ->> Y (MVD). An
FD means X determines a single value of Y. An MVD means X determines a set of Y values, and this set is
independent of other attributes not in X or Y.

Incorrectly Identifying MVDs: Identifying true MVDs requires a deep understanding of the real-world semantics,
not just looking at sample data. Sample data can be misleading.

Over-Normalizing: Applying 4NF/5NF unnecessarily when BCNF is sufficient. This can lead to an overly complex
schema and performance issues without providing significant benefits.

Ignoring Performance Impact: Forgetting that more joins might be needed to reconstruct information, leading to
slower queries.

Not Recognizing Trivial Dependencies: Forgetting that X ->> Y is trivial if Y is a subset of X or X union
Y covers all attributes.

Special cases
All Attributes Form Key: If all attributes in a relation R form a candidate key, then R is automatically in 5NF. This is
because there can be no non-trivial dependencies (FD, MVD, or JD) if the only key is the entire relation.

Binary Relations: Any binary relation (a relation with only two attributes) that is in 1NF is automatically in 5NF. There
are no possible non-trivial FDs, MVDs, or JDs that can be violated in a binary relation.

Small Number of Attributes: For relations with few attributes (e.g., 3-4), the likelihood of non-trivial MVDs/JDs not
covered by BCNF is lower, but not impossible.

9. Real-Life Applications
How this concept is used in real world
Manufacturing/Bill of Materials (BOM) Systems: In complex product manufacturing, a product might consist of
various sub-assemblies, and each sub-assembly might use different components. If a component can be used in
multiple sub-assemblies and a sub-assembly can be part of multiple products, and these relationships are
independent, MVDs and JDs can arise. 4NF/5NF can help model this precisely without redundancy.

Scientific and Research Databases: When modeling experimental data where entities have multiple, independent
attributes (e.g., an experiment has multiple conditions and multiple observers, and the set of conditions is
independent of the set of observers), 4NF is valuable.

Knowledge Representation Systems: Databases designed to store complex knowledge, often with multi-faceted
relationships, benefit from higher normal forms to ensure consistency and prevent spurious information generation.

Configuration Management Databases (CMDBs): In IT, a configuration item (CI) might have multiple associated
software components and multiple associated hardware components. If these associations are independent, 4NF
helps to keep them separate and non-redundant.

Multi-tenant Applications with Complex Shared Data: While less common, in highly specialized multi-tenant
systems where tenants share a core data model with independent multi-valued facts, 4NF/5NF could be considered
for the core common tables to ensure maximum integrity.

10. Practice Problems

Easy
1. Relation R(A, B, C) with dependencies A ->> B and A ->> C. Is R in 4NF? If not, decompose it.

2. Relation R(Student, Course, Book). Assume a student can take multiple courses, and each course can use multiple
books. The choice of books for a course is independent of the student. Does this scenario suggest an MVD?

Medium

[Link] Page 119 of 159

 1. Relation R(Employee, Project, Skill). Assume an employee can work on multiple projects, and an employee can have
multiple skills. The set of projects an employee works on is independent of the set of skills they possess.
Identify the MVDs.

Is R in 4NF? If not, decompose it to 4NF.

2. Relation R(Movie, Actor, Director). Assume that for a given movie, the set of actors is independent of the set of
directors.
Identify the MVD.

Is R in 4NF? Decompose if necessary.

Hard
1. Consider a relation Supplier_Part_Project (S, P, J) where S is Supplier, P is Part, J is Project.
Assume (S,P) implies that supplier S supplies part P.

Assume (P,J) implies that part P is used in project J.

Assume (S,J) implies that supplier S works on project J.

And the rule is: "A supplier S supplies a part P for project J if and only if supplier S supplies part P, AND part P is
used in project J, AND supplier S works on project J."

Identify the type of dependency. Is this relation in 5NF? If not, decompose it. (This is a classic 5NF problem
scenario.)

11. Summary / Key Points

Quick revision of points covered
Higher Normal Forms (4NF, 5NF) address subtler forms of redundancy beyond BCNF, primarily involving multi-
valued dependencies and join dependencies.

4NF eliminates redundancy due to non-trivial Multi-Valued Dependencies (MVDs), where an attribute (or set)
determines a set of values for another attribute, independently of other attributes. A relation is in 4NF if for every
MVD X ->> Y , X is a superkey.

5NF (Project-Join Normal Form) eliminates redundancy due to non-trivial Join Dependencies (JDs). A relation is in
5NF if it is in 4NF and cannot be losslessly decomposed into smaller relations unless one of the decomposed
relations is itself a superkey for the original. It represents the maximal level of normalization.

Decomposition to 4NF and 5NF is always lossless.

Benefits: Maximal data integrity, minimal redundancy, clearer schema.

Drawbacks: Increased number of tables, potential query performance overhead due to more joins, complexity in
identifying dependencies, less commonly applied in practice than BCNF.

Highlighted formulas and shortcuts

MVD Test: For R(A, B, C) : A ->> B exists if for any A value, the set of B values is independent of the set
of C values.

4NF Rule: R is in 4NF if for every non-trivial MVD X ->> Y , X is a superkey of R .

Decomposition for 4NF: If R violates 4NF due to X ->> Y , decompose into R1(X, Y) and R2(X, R - X
- Y) .

JD Test: R has JD(R1, R2, ..., Rk) if R = R1 JOIN R2 JOIN ... JOIN Rk is lossless.

5NF Rule: R is in 5NF if it is in 4NF and for every non-trivial JD JD(R1, R2, ..., Rk) , at least one Ri is a
superkey of R .

Hierarchy: FD implies MVD implies JD.

[Link] Page 120 of 159

 Normalization Process and Decomposition
Understanding how to decompose a relation into smaller, normalized relations while ensuring lossless join and dependency
preservation.

1. Introduction
Definition
Normalization: A systematic process in database design used to organize data in a database, primarily to reduce
data redundancy and improve data integrity. It involves analyzing relations (tables) and their functional
dependencies.

Decomposition: The process of breaking down a large, potentially problematic relation (table) into two or more
smaller relations. This is a core part of normalization, as it resolves anomalies by distributing attributes across new
tables.

Why it is needed Database normalization is crucial for several reasons, mainly to overcome various data anomalies that
arise in unnormalized databases:
1. Redundancy: Storing the same information multiple times wastes storage space and can lead to inconsistencies.

2. Update Anomalies:
Insertion Anomaly: Cannot insert certain information without inserting other, unrelated information. For
example, if a student enrollment table also stores course details, a new course cannot be added until a student
enrolls in it.

Deletion Anomaly: Deleting a record might unintentionally delete other vital information. If the last student for
a course is deleted from an enrollment table, the course details might also be lost.

Modification (Update) Anomaly: Changing a piece of information requires updating multiple records,
increasing the chance of inconsistency if not all copies are updated. If a professor's department changes, it needs
to be updated in every record where that professor appears.

Data Inconsistency: Redundant data can lead to situations where the same data element has different values in
different places.

Analogy: Imagine a disorganized filing cabinet where the same document is stored in multiple folders, sometimes
with different versions. Finding specific information is hard, updating it means finding all copies, and deleting one
copy might unintentionally remove the only record of something else. Normalization is like organizing that cabinet
into separate, well-defined folders (tables) with clear rules (relationships) about what goes where, ensuring each
unique piece of information is stored once and consistently.

Applications
Database Design: The primary application, guiding the creation of efficient and reliable relational databases from
conceptual models.

Data Warehousing: Normalization (or its inverse, denormalization for performance) is critical in designing data
warehouses for analytical purposes, ensuring data quality before aggregation.

Data Integration: When combining data from multiple sources, normalization helps in resolving inconsistencies and
establishing a unified schema.

Application Development: Well-normalized databases simplify application logic for data manipulation, as
developers don't have to deal with update anomalies manually.

2. Theory Explanation
In-depth explanation Normalization is achieved through a series of stages called "Normal Forms" (NFs), each with
increasingly stringent rules to eliminate specific types of anomalies. The most common normal forms are 1NF, 2NF, 3NF,
and BCNF (Boyce-Codd Normal Form). The process involves identifying Functional Dependencies (FDs) within a relation
and using them to guide decomposition.

[Link] Page 121 of 159

 Functional Dependency (FD): An FD X -> Y means that the value of attribute set X uniquely determines the value of
attribute set Y. X is the determinant, and Y is the dependent.

Key Concepts in Normalization:

Superkey: An attribute or set of attributes that uniquely identifies a tuple (row) in a relation.

Candidate Key: A minimal superkey; no proper subset of it is also a superkey.

Primary Key: A chosen candidate key to uniquely identify tuples.

Prime Attribute: An attribute that is part of any candidate key.

Non-Prime Attribute: An attribute that is not part of any candidate key.

Normal Forms and Decomposition Rules:

First Normal Form (1NF):

Rule: All attributes must be atomic (indivisible) and single-valued. No multi-valued attributes or nested
relations.

Decomposition: If a relation is not in 1NF, multi-valued attributes are typically moved into a new relation,
with a foreign key linking back to the original.

Second Normal Form (2NF):

Rule: Must be in 1NF AND all non-prime attributes must be fully functionally dependent on every candidate
key. No partial dependencies.

Partial Dependency: A non-prime attribute is dependent on a proper subset of a candidate key.

Decomposition: If a partial dependency X -> Y exists where X is a proper subset of a candidate key K,
decompose the relation into K-X-Y and XY.

Third Normal Form (3NF):

Rule: Must be in 2NF AND no non-prime attribute can be transitively dependent on any candidate key.

Transitive Dependency: An FD X -> Y where X is not a superkey, and Y is not a prime attribute, and there
exists an attribute set Z such that K -> X and X -> Y (where K is a candidate key).

Decomposition: If a transitive dependency K -> X and X -> Y exists, decompose into K-X and XY.

Boyce-Codd Normal Form (BCNF):

Rule: Must be in 3NF AND for every non-trivial functional dependency X -> Y, X must be a superkey. BCNF is
a stricter version of 3NF.

Difference from 3NF: 3NF allows FDs X -> Y where X is not a superkey if Y is a prime attribute. BCNF does
not.

Decomposition: If an FD X -> Y violates BCNF (X is not a superkey and Y is not a subset of X), decompose
into XY and R - (Y - X).

Decomposition Properties: When decomposing a relation R into R1 and R2, two critical properties must be
maintained:

1. Lossless-Join Decomposition: The natural join of R1 and R2 must reconstruct the original relation R exactly,
without generating any spurious tuples (extra, incorrect rows). This is achieved if the common attributes (R1 ⋂
R2) form a superkey of at least one of the decomposed relations (R1 or R2).

2. Dependency-Preserving Decomposition: All functional dependencies from the original relation R can be
enforced by examining only the functional dependencies within the decomposed relations R1 and R2, without
needing to join them. This is important for maintaining data integrity efficiently.

Diagrams/flowcharts

Normalization Flowchart (Descriptive):

1. Start with an Unnormalized Relation.

[Link] Page 122 of 159

 2. Check for 1NF: Are all attributes atomic and single-valued?
If NO: Remove repeating groups or multi-valued attributes by creating new relations.

If YES: Relation is in 1NF.

3. Check for 2NF: Is the relation in 1NF? Are there any partial dependencies of non-prime attributes on candidate
keys?
If NO (partial dependencies exist): Decompose the relation to remove partial dependencies. Create new
relations for the partially dependent attributes.

If YES: Relation is in 2NF.

4. Check for 3NF: Is the relation in 2NF? Are there any transitive dependencies of non-prime attributes on
candidate keys?
If NO (transitive dependencies exist): Decompose the relation to remove transitive dependencies. Create new
relations for the transitively dependent attributes.

If YES: Relation is in 3NF.

5. Check for BCNF: Is the relation in 3NF? For every functional dependency X -> Y, is X a superkey?
If NO (determinant is not a superkey): Decompose the relation into two new relations based on the violating
FD.

If YES: Relation is in BCNF.

6. End.

Decomposition Example Diagram (Descriptive): Imagine a table Student_Course_Professor with columns:

(StudentID, StudentName, CourseID, CourseName, ProfessorID, ProfessorName,
ProfessorDept) . Let's say StudentID, CourseID is the primary key. ProfessorID ->
ProfessorName, ProfessorDept is a transitive dependency (if StudentID, CourseID ->
ProfessorID is also an FD). Also, CourseID -> CourseName is a partial dependency.

Initial Table: [ StudentID | StudentName | CourseID | CourseName | ProfessorID | ProfessorName | ProfessorDept ]

Decomposition for 2NF (removing CourseID -> CourseName ):

1. Student_Course_Professor_Intermediate (StudentID, StudentName, CourseID, ProfessorID,

ProfessorName, ProfessorDept)

2. Course_Details (CourseID, CourseName)

Further Decomposition for 3NF (removing ProfessorID -> ProfessorName, ProfessorDept from
Student_Course_Professor_Intermediate ):

1. Student_Course_Professor_Intermediate becomes Student_Enrollment (StudentID,

StudentName, CourseID, ProfessorID)

2. Professor_Details (ProfessorID, ProfessorName, ProfessorDept)

Resulting Tables: Student_Enrollment (StudentID, StudentName, CourseID, ProfessorID) Course_Details

(CourseID, CourseName) Professor_Details (ProfessorID, ProfessorName, ProfessorDept)

Step-by-step breakdown (General Normalization Process)

1. Identify all Attributes: List all attributes that will be part of the database.

2. Identify Functional Dependencies (FDs): Determine all FDs that hold true between the attributes. This is a critical
and often challenging step, requiring a deep understanding of the data semantics.

3. Find Candidate Keys: Using the FDs, identify all candidate keys for the initial relation. Choose one as the primary
key.

[Link] Page 123 of 159

 4. Check for 1NF: Ensure all attributes contain atomic, single values. If not, restructure by creating new relations or
flattening multi-valued attributes.

5. Check for 2NF: For each non-prime attribute, ensure it is fully functionally dependent on every candidate key. If
there are partial dependencies (A subset of key -> Non-prime attribute), decompose the relation.
Create a new relation with the partial key and the partially dependent attributes.

Remove these attributes from the original relation (leaving the partial key as a foreign key if needed).

6. Check for 3NF: For each non-prime attribute, ensure there are no transitive dependencies (Candidate Key -> X ->
Non-prime attribute). If transitive dependencies exist, decompose the relation.
Create a new relation with the intermediate determinant (X) and the transitively dependent attributes.

Remove these attributes from the original relation (leaving the intermediate determinant as a foreign key).

7. Check for BCNF: For every non-trivial functional dependency X -> Y, ensure X is a superkey. If a determinant X is not
a superkey, decompose the relation.
Create a new relation with X and Y.

Create another relation with the attributes of the original relation minus Y (while keeping X in the original relation
if it was there).

8. Verify Decomposition Properties: After each decomposition step, ensure that the resulting decomposition is
lossless-join and, if possible, dependency-preserving.

3. Properties & Characteristics

Key properties

1. Lossless-Join Decomposition: This is the most crucial property. When a relation R is decomposed into R1, R2, ..., Rn,
joining these relations back together (using natural join) must yield exactly the original relation R. No spurious tuples
should be generated, and no information should be lost.
Condition: For a decomposition of R into R1 and R2 to be lossless, the intersection of attributes (R1 ⋂ R2) must
contain a superkey of either R1 or R2.

2. Dependency-Preserving Decomposition: All functional dependencies that held in the original relation R can be
inferred from (or are directly present in) the functional dependencies within the decomposed relations R1, R2, ..., Rn.
This ensures that data integrity constraints can be enforced by checking constraints on the individual smaller
relations without needing to join them.
Condition: The union of the closures of the FDs in the decomposed relations must be equivalent to the closure
of the FDs in the original relation.

3. Minimal Redundancy: The primary goal of normalization is to minimize redundant storage of data, thereby saving
space and reducing the risk of inconsistencies.

4. Data Integrity: By eliminating anomalies, normalization ensures that data is consistent and accurate across the
database.

5. Well-Structured Relations: Normalized relations are typically easier to understand, manage, and query.

Advantages & disadvantages

Advantages:
Reduced Data Redundancy: Eliminates duplicate data, saving storage space.

Improved Data Integrity: Minimizes update, insertion, and deletion anomalies, ensuring data consistency and
accuracy.

Easier Maintenance: Changes to data need only be made in one place, simplifying database maintenance.

Faster Query Execution (sometimes): Smaller tables often lead to faster scans and index lookups.

Better Database Organization: Creates a logical and clean database structure, which is easier to understand and
manage.

[Link] Page 124 of 159

 Flexibility: Easier to extend the database schema without significant restructuring.

Disadvantages:
Increased Join Operations: Queries often require joining multiple tables to retrieve complete information, which
can sometimes degrade query performance, especially in highly normalized schemas.

More Complex Queries: Writing queries might become more complex due to the need for multiple joins.

Increased Number of Tables: A highly normalized database will have many tables, which can increase overhead
in terms of management and understanding the schema.

Performance Trade-offs: For certain applications (e.g., data warehousing for analytical queries), denormalization
(intentionally reducing the normal form) might be preferred to improve query performance by reducing joins.

4. Mathematical / Logical Representation

Important formulas

Functional Dependency (FD): X -> Y, where X and Y are sets of attributes. This means that for any two tuples t1 and
t2 in the relation, if t1[X] = t2[X], then t1[Y] = t2[Y].

Closure of an Attribute Set (X+): The set of all attributes that are functionally determined by X.
Algorithm to find X+:
1. Result = X

2. Repeat until Result does not change: For each FD A -> B in F: If A is a subset of Result, then Result = Result U
B

Candidate Key (K): A set of attributes K is a candidate key for a relation R if:
1. K -> R (K functionally determines all attributes in R)

2. For no proper subset K' of K, K' -> R (K is minimal).

Lossless-Join Decomposition Condition: For a decomposition of R into R1 and R2, it is lossless if (R1 ⋂ R2) is a
superkey of R1 or (R1 ⋂ R2) is a superkey of R2.

Dependency-Preserving Decomposition Condition: For a decomposition of R into R1, R2, ..., Rn with functional
dependencies F1, F2, ..., Fn respectively, the decomposition is dependency-preserving if the closure of the union of
FDs from the decomposed relations is equivalent to the closure of the original FDs: (F1 U F2 U ... U Fn)+ = F+.

Derivations

Proof of Lossless Join (by example): Let R(A, B, C) with FD A -> B. Decompose R into R1(A, B) and R2(A, C).
Intersection: R1 ⋂ R2 = {A}. Is A a superkey of R1(A, B)? Yes, because in R1, A is the primary key (A -> B is present).
Therefore, this decomposition is lossless. (Alternatively, check if A is a superkey of R2(A, C). In R2, A determines C if A
-> C is an FD. If not, A is not a superkey of R2. But since A is a superkey of R1, the condition is met.)

Finding Minimal Cover for FDs: A minimal cover G for a set of FDs F is a set of FDs such that:

1. Every FD in G has a single attribute on the right-hand side.

2. No FD in G is redundant (i.e., if you remove any FD X -> A from G, (G - {X -> A})+ != F+).

3. No attribute in the left-hand side of any FD in G is redundant (i.e., if X -> A is in G and X' is a proper subset of X,
then X' -> A cannot be derived from G - {X -> A} U {X' -> A}).

This derivation is a multi-step process for simplifying a set of FDs, often used as the first step in the 3NF synthesis
algorithm.

5. Operations / Algorithms
We will describe the core algorithms for decomposing relations to achieve 3NF and BCNF.

[Link] Page 125 of 159

 Algorithm 1: 3NF Decomposition (Synthesis Algorithm) This algorithm aims to produce a dependency-preserving and
lossless-join decomposition into 3NF.

Problem statement: Given a relation schema R and a set of functional dependencies F, decompose R into a set of
relations {R1, R2, ..., Rn} such that each Ri is in 3NF, the decomposition is lossless-join, and dependency-preserving.

Step-by-step algorithm:
1. Find a Minimal Cover G for F:
Ensure all FDs in F have a single attribute on the right-hand side.

Remove redundant FDs from F.

Remove extraneous attributes from the left-hand side of FDs.

2. Decompose into Relations: For each functional dependency X -> Y in the minimal cover G, create a new relation
schema R_i = XY.

3. Ensure a Candidate Key is Preserved: If none of the relation schemas R_i created in step 2 contains a candidate key
of the original relation R, then add an additional relation schema R_k that consists of a candidate key of R. (This step
ensures the lossless-join property).

4. Eliminate Redundant Relations (Optional): If any relation R_j from the decomposition is a subset of another
relation R_k (i.e., attributes(R_j) ⊆ attributes(R_k)), then R_j can be removed.

Dry run example: Relation R(A, B, C, D, E) with FDs F = {A -> BC, CD -> E, B -> D, E -> A}.
1. Find Minimal Cover G:
Split right-hand sides: F = {A -> B, A -> C, CD -> E, B -> D, E -> A}.

Check for redundancy (e.g., can A -> B be removed? If yes, (F - {A -> B})+ should still contain A -> B. A+ without
A->B is just A, so no. All FDs appear necessary and minimal on LHS).

So, G = {A -> B, A -> C, CD -> E, B -> D, E -> A}.

2. Decompose into Relations:

R1(AB) from A -> B

R2(AC) from A -> C

R3(CDE) from CD -> E

R4(BD) from B -> D

R5(EA) from E -> A

3. Ensure Candidate Key:

Candidate Keys for R: A+ = ABCDE, so A is a candidate key. E+ = EABCD, so E is a candidate key.

R1 (AB) contains A. R2 (AC) contains A. R5 (EA) contains A and E.

Since at least one derived relation (R1, R2, R5) contains a candidate key, no extra relation is needed.

4. Eliminate Redundant Relations: No relation is a subset of another.

Resulting 3NF Schema: {R1(AB), R2(AC), R3(CDE), R4(BD), R5(EA)}.

Pseudocode: function DecomposeTo3NF(R, F): G = FindMinimalCover(F) SchemaList = empty list for each FD (X -> Y) in
G: Add (X U Y) to SchemaList (if not already present or subset of existing) CandidateKeys = FindCandidateKeys(R, F)
FoundCandidateKeyInSchema = false for each Schema in SchemaList: for each Key in CandidateKeys: if Key is a subset of
Schema: FoundCandidateKeyInSchema = true break if FoundCandidateKeyInSchema: break if not
FoundCandidateKeyInSchema: Add (any CandidateKey) to SchemaList Return SimplifySchemas(SchemaList) // Remove
redundant schemas

Code (Conceptual Description - No Code Fences): Implementing this involves functions for:
findClosure(attributes, FDs) : To calculate the closure of a set of attributes under a given set of FDs.

findMinimalCover(FDs) : Iteratively removes redundant attributes from LHS and redundant FDs.

findCandidateKeys(R, FDs) : Finds minimal superkeys.

[Link] Page 126 of 159

 The main decomposition function then applies the steps of the algorithm, creating schema sets (represented as
lists/sets of attributes). The process would iterate through FDs, create new relation schemas, check for candidate key
preservation, and perform set operations (union, intersection, subset check) on attribute sets.

Algorithm 2: BCNF Decomposition (Analysis Algorithm) This algorithm guarantees a lossless-join decomposition into
BCNF, but it may not always be dependency-preserving.

Problem statement: Given a relation schema R and a set of functional dependencies F, decompose R into a set of
relations {R1, R2, ..., Rn} such that each Ri is in BCNF and the decomposition is lossless-join.

Step-by-step algorithm:
1. Initialize: Start with a list of relations containing only the original relation R. (CurrentRelations = {R}).

2. Iterate and Decompose: While there exists a relation R_i in CurrentRelations that is NOT in BCNF: a. Find a
functional dependency X -> Y in R_i (implied by F) that violates BCNF. This means X is not a superkey of R_i, and Y is
not a subset of X. b. Remove R_i from CurrentRelations. c. Decompose R_i into two new relations: * R_i1 = (X U Y) *
R_i2 = (R_i - Y) U X (or R_i - (Y - X), ensures X is present for the join) d. Add R_i1 and R_i2 to CurrentRelations.

3. Result: The set of relations in CurrentRelations will be in BCNF and the decomposition will be lossless-join.

Dry run example: Relation R(Title, Author, Author_Nationality), F = {Title -> Author, Author -> Author_Nationality}.
1. Initial: CurrentRelations = {R(Title, Author, Author_Nationality)}.

2. Check R:
Candidate key: Title (because Title -> Author and Author -> Author_Nationality, so Title -> Author_Nationality).

FDs:
Title -> Author: Title is a superkey. (OK)

Author -> Author_Nationality: Author is NOT a superkey of R (it doesn't determine Title). (VIOLATION!)

3. Decompose R using Author -> Author_Nationality:

Remove R from CurrentRelations.

R1 = (Author U Author_Nationality) = (Author, Author_Nationality)

R2 = (R - Author_Nationality) U Author = (Title, Author)

Add R1 and R2 to CurrentRelations. Now CurrentRelations = {R1(Author, Author_Nationality), R2(Title, Author)}.

4. Check R1(Author, Author_Nationality):

FD: Author -> Author_Nationality.

Candidate key: Author.

Author -> Author_Nationality: Author is a superkey. (OK). R1 is in BCNF.

5. Check R2(Title, Author):

FD: Title -> Author.

Candidate key: Title.

Title -> Author: Title is a superkey. (OK). R2 is in BCNF.

6. No more relations violate BCNF.

Resulting BCNF Schema: {R1(Author, Author_Nationality), R2(Title, Author)}.

Pseudocode: function DecomposeToBCNF(R, F): Result = {R} while any relation R_i in Result is not in BCNF: Remove R_i
from Result Find a BCNF_violating_FD (X -> Y) in R_i (where X is not a superkey of R_i) R_i1 = X U Y R_i2 = (Attributes of
R_i) - (Y - X) Add R_i1 to Result Add R_i2 to Result Return Result

Code (Conceptual Description - No Code Fences): This implementation would involve:

A function isBCNF(relation_schema, FDs_for_schema) : Checks if a given relation is in BCNF by iterating
through FDs and checking if determinants are superkeys.

A function findSuperkeys(relation_schema, FDs_for_schema) .

[Link] Page 127 of 159

 The main decomposition loop repeatedly calls isBCNF . When a violation is found, it performs set difference and
union operations on attribute sets to create the new relation schemas, then adds them back to the list of relations to
be checked.

6. Complexity Analysis
Time complexity
Finding Minimal Cover: The process of finding a minimal cover for FDs can be computationally intensive. It involves
iterating through FDs, calculating closures, and performing set operations. In the worst case, it can be polynomial
with respect to the number of FDs and attributes.

3NF Synthesis Algorithm:

Identifying FDs for each new relation and checking minimality can be polynomial.

Overall, the algorithm is polynomial time with respect to the number of attributes and FDs.

BCNF Decomposition Algorithm:

Checking for BCNF violations involves iterating through FDs and calculating superkeys for each relation. This can
be polynomial for each relation check.

In the worst case, if many small violations need to be addressed, the decomposition process can lead to an
exponential number of relations, making the overall algorithm potentially exponential in the number of
attributes. However, in practical scenarios, it typically performs well.

Space complexity
The space required is primarily determined by the number of attributes, the number of functional dependencies, and
the number of relations created during decomposition.

It is generally polynomial with respect to the number of attributes and FDs.

Comparison with alternatives

3NF vs. BCNF:
Dependency Preservation: 3NF decomposition (using the synthesis algorithm) always guarantees dependency
preservation. BCNF decomposition does not always guarantee dependency preservation (though it always
guarantees lossless join). This means enforcing all original integrity constraints might require checking across
multiple BCNF relations using joins.

Lossless Join: Both 3NF (synthesis algorithm) and BCNF decomposition algorithms guarantee lossless-join.

Strictness: BCNF is a stricter normal form than 3NF. A relation in BCNF is always in 3NF, but a relation in 3NF is
not necessarily in BCNF. BCNF addresses more anomalies related to determinants that are not candidate keys.

Choice: 3NF is often preferred in practical database design when dependency preservation is paramount (e.g., to
easily enforce business rules). BCNF is chosen when maximum data redundancy elimination is the goal, even at
the cost of potential complexity in dependency enforcement.

Higher Normal Forms (4NF, 5NF): These address even more specialized types of dependencies (multi-valued
dependencies for 4NF, join dependencies for 5NF). They are rarely used in commercial database design unless
extremely strict normalization is required, as the complexity and performance overhead outweigh the benefits for
most applications.

7. Examples
Solved Problem 1 (Medium - Normalize to 3NF) Relation: R(A, B, C, D, E) Functional Dependencies (FDs):
F = {AB -> C, BC -> D, D -> E, A -> B}

Steps:

1. Find Candidate Keys:

Start with A . A+ = {A} .

[Link] Page 128 of 159

 Using A -> B , A+ = {A, B} .

Using AB -> C , A+ = {A, B, C} .

Using BC -> D (since B, C are in A+ ), A+ = {A, B, C, D} .

Using D -> E (since D is in A+ ), A+ = {A, B, C, D, E} .

Since A+ covers all attributes, A is a superkey. Is it minimal? Yes, no proper subset of A (i.e., empty set) can
determine all attributes. So, A is a candidate key.

(Check other attributes: B+ doesn't determine A or C , etc. No other single attribute is a key. No combination
of attributes without A seems to be a key either.)

Candidate Key: {A} .

2. Check for 1NF: All attributes are atomic. (Assumed). In 1NF.

3. Check for 2NF: (No partial dependencies on candidate key)

Candidate Key: A .

Non-prime attributes: B, C, D, E .

Dependencies:
A -> B : B is fully dependent on A (the key). OK.

AB -> C : C is fully dependent on AB . Since A is a key, C is also considered fully dependent on A .

OK.

BC -> D : D is dependent on BC . BC is not a proper subset of the candidate key A . This FD is not a
partial dependency. OK.

D -> E : E is dependent on D . D is not a proper subset of the candidate key A . This FD is not a partial
dependency. OK.

All relations are in 2NF.

4. Check for 3NF: (No transitive dependencies of non-prime attributes on candidate key)
Candidate Key: A . Non-prime attributes: B, C, D, E .

Consider FDs:
A -> B : No transitivity.

AB -> C : No transitivity.

BC -> D : B and C are non-prime attributes. D is non-prime. A -> B and AB -> C means A
effectively determines B and C . If A -> BC and BC -> D , then A -> D transitively. D is a non-
prime attribute. This is a transitive dependency through BC . Violation!

D -> E : D is a non-prime attribute. E is a non-prime attribute. If A -> D (as derived above) and D -
> E , then A -> E transitively through D . Violation!

Decomposition for 3NF (using Synthesis Algorithm):

1. Minimal Cover G:
F = {AB -> C, BC -> D, D -> E, A -> B} .

All LHS are minimal (no A -> B and A -> C needing A -> BC for example).

All RHS are single attributes.

Check for redundant FDs:

A -> B : Necessary. ( (AB -> C, BC -> D, D -> E)+ doesn't contain A -> B )

AB -> C : Necessary. ( (A -> B, BC -> D, D -> E)+ doesn't contain AB -> C )

BC -> D : Necessary. ( (A -> B, AB -> C, D -> E)+ doesn't contain BC -> D )

[Link] Page 129 of 159

 D -> E : Necessary. ( (A -> B, AB -> C, BC -> D)+ doesn't contain D -> E )

So, G = {AB -> C, BC -> D, D -> E, A -> B} .

2. Create Relations from G:

R1(ABC) from AB -> C

R2(BCD) from BC -> D

R3(DE) from D -> E

R4(AB) from A -> B

3. Ensure Candidate Key:

Candidate key is A . R4(AB) contains A . So, no extra relation is needed.

4. Eliminate Redundant Relations:

R4(AB) is a subset of R1(ABC) . We can combine R4 into R1 .

However, the synthesis algorithm typically forms relation for each FD in the minimal cover, so let's keep them as
is for strict application. Some variations might eliminate if R4 is "covered" by R1 and R1 's FD ( AB->C )
already implies A->B in some way.

For the purpose of this example, assume R4 is not a subset for strict interpretation where R4 's attributes are
A, B . R1 's attributes are A, B, C . R4 is a proper subset of R1 . We can potentially remove R4 if its
FDs are "covered" elsewhere. In the simplified synthesis algorithm, we just take the relations generated.

Let's refine: If AB (from R4 ) is already contained within ABC (from R1 ), R4 itself isn't strictly removed if it
holds A->B specifically. The more common approach is to simply list the relations directly derived:
R_AB_C (A, B, C)

R_BC_D (B, C, D)

R_D_E (D, E)

R_A_B (A, B)

These relations will ensure 3NF and be lossless-join and dependency-preserving.

Final 3NF Relations: {R_ABC(A, B, C), R_BCD(B, C, D), R_DE(D, E), R_AB(A, B)} .

Note: R_AB is redundant as its attributes are a subset of R_ABC . If we remove R_AB , the remaining FDs for
{A->B, AB->C, BC->D, D->E} might not be entirely represented in the individual relations if we do not check
projections of FDs. A safer approach for the synthesis algorithm is to keep them and let the DB system resolve
redundancy via data. Or the rule for step 4 usually states: "If attributes(R_j) ⊆ attributes(R_k) AND FDs(R_j) is
covered by FDs(R_k) AND R_j is not an important key relation, then R_j can be removed." For simplicity, let's keep
all.

Solved Problem 2 (Medium - Normalize to BCNF) Relation: R(S, P, C) (Student, Project, Course) Functional
Dependencies (FDs): F = {S -> C, C -> P} (Meaning: Each student is registered for only one course. Each
course has only one project.)

Steps:

1. Find Candidate Keys:

S+ = {S} . Using S -> C , S+ = {S, C} . Using C -> P , S+ = {S, C, P} .

Since S+ covers all attributes in R , S is a superkey. It's minimal, so S is a candidate key.

2. Check for BCNF:

Candidate Key: S .

FDs:
S -> C : S is a superkey. This FD satisfies BCNF.

[Link] Page 130 of 159

 C -> P : C is NOT a superkey of R (it doesn't determine S ). P is not a subset of C . This FD violates
BCNF.

Decomposition for BCNF (using Analysis Algorithm):

1. Initial: CurrentRelations = {R(S, P, C)} .

2. R(S, P, C) is not in BCNF.

Violation: C -> P .

Decompose R using C -> P .

Remove R from CurrentRelations .

R1 = (C U P) = (C, P)

R2 = (R - P) U C = (S, C) (because S and C were in R, and we remove P, then we add C back if not
present to link relations. The formula is (R_i - Y) U X for a violation X -> Y. Here X=C, Y=P. So R2 = (S, P, C - P) U C
= (S, C) U C = (S, C))

Add R1 and R2 to CurrentRelations .

CurrentRelations = {R1(C, P), R2(S, C)} .

3. Check R1(C, P) :
FD: C -> P .

Candidate key: C .

C -> P : C is a superkey of R1 . (OK). R1 is in BCNF.

4. Check R2(S, C) :
FD: S -> C .

Candidate key: S .

S -> C : S is a superkey of R2 . (OK). R2 is in BCNF.

5. No more relations violate BCNF.

Resulting BCNF Schema: {R1(C, P), R2(S, C)} .

This decomposition is lossless-join (common attribute C is a key in R1 ) but not dependency-preserving. The
original dependency S -> C is preserved in R2 . The dependency C -> P is preserved in R1 . But the original
FDs {S->C, C->P} had a transitive property S->P. This dependency S -> P cannot be checked locally in R1 or
R2 individually; it requires a join. This is a common trade-off with BCNF.

8. Common Mistakes & Edge Cases

Where students go wrong
Confusing 3NF and BCNF: The most frequent mistake. Students often forget that 3NF allows a determinant X -> Y
where X is not a superkey if Y is a prime attribute, while BCNF strictly requires X to be a superkey in all non-trivial
FDs.

Incorrectly Identifying Candidate Keys: Errors in finding all FDs or calculating attribute closures lead to incorrect
candidate keys, which invalidates the entire normalization process.

Failing to Find a Minimal Cover: In the 3NF synthesis algorithm, an incorrect minimal cover will lead to an incorrect
and potentially non-3NF decomposition.

Not Checking Lossless-Join Property: Creating a decomposition that loses data or generates spurious tuples is a
critical error. Students sometimes only focus on normal form rules and forget this crucial property.

Ignoring Dependency Preservation: While BCNF may not always be dependency-preserving, it's essential to at
least understand the implications and trade-offs. For 3NF, it's a guaranteed property.

[Link] Page 131 of 159

 Mistaking Trivial FDs for Non-Trivial Ones: A trivial FD (X -> Y where Y is a subset of X) does not violate any
normal form.

Applying Rules Only to Primary Key: Students sometimes only check dependencies against the chosen primary
key, forgetting that normal form rules apply to all candidate keys.

Special cases
Relations already in BCNF: Some relations might naturally satisfy BCNF from the start, requiring no decomposition.

Non-dependency-preserving BCNF: It's important to understand that achieving BCNF might sometimes require a
decomposition that is not dependency-preserving. In such cases, one might either:
Accept the non-dependency-preserving decomposition and enforce the lost dependencies through application
code or assertions (which can be more complex).

Settle for 3NF if dependency preservation is a higher priority than strict BCNF.

Multi-valued Dependencies (MVDs): If a relation has MVDs (e.g., A ->-> B, meaning A determines a set of B
values, independent of other attributes), then 4NF is required. BCNF does not address MVDs.

Join Dependencies (JDs): For more complex cases involving join dependencies, 5NF (Project-Join Normal Form)
might be necessary.

All Attributes are Prime: If all attributes in a relation are part of some candidate key, then the relation is
automatically in 3NF. It might still violate BCNF if there's a non-superkey determinant where the dependent is also
prime.

9. Real-Life Applications
Enterprise Resource Planning (ERP) Systems: Large systems like SAP, Oracle EBS, and Microsoft Dynamics manage
vast amounts of interconnected data (customers, orders, products, finances). Normalization ensures data consistency
across departments and modules, which is vital for business operations and reporting.

Banking and Financial Systems: Data integrity is paramount. Normalization prevents inconsistencies in account
balances, transaction records, and customer details, which could lead to severe financial and legal repercussions.

E-commerce Platforms: Online stores use normalized databases for product catalogs, customer information, order
tracking, and inventory management. This ensures accurate product listings, efficient order processing, and reliable
customer service.

Healthcare Management Systems: Patient records, appointments, medical history, and billing information must be
consistently stored and accessible. Normalization helps maintain data accuracy, which is crucial for patient care and
legal compliance.

Library Management Systems: Managing books, authors, borrowers, and loan records. Normalization helps avoid
issues like multiple entries for the same book, inconsistent author details, or lost borrowing history.

Government Databases: Census data, tax records, and public service information rely on normalization to ensure data
quality, minimize errors, and facilitate efficient data retrieval for policy-making and public services.

Software Development: When building any application that stores data, understanding and applying normalization
principles is a fundamental skill for database designers and developers to create robust and scalable solutions.

10. Practice Problems

Easy Relation: R(A, B, C) FDs: F = {A -> B, B -> C} Task: Normalize R to 3NF and BCNF. (Hint: Find
candidate key, check for transitive dependency, then BCNF violation.)

Medium Relation: R(MovieTitle, StudioName, StudioAddress, DirectorName,

DirectorNationality) FDs:

1. MovieTitle -> StudioName, DirectorName

2. StudioName -> StudioAddress

[Link] Page 132 of 159

 3. DirectorName -> DirectorNationality Task: Normalize R to 3NF. Clearly state the resulting relations and
their FDs. (Hint: Identify partial and transitive dependencies based on the primary key MovieTitle .)

Hard Relation: R(Course, Instructor, Textbook, EnrollmentDate) FDs:

1. Course -> Textbook

2. Instructor -> Course

3. Course, Instructor -> EnrollmentDate Task: Normalize R to BCNF. Provide the step-by-step
decomposition and justify each step. (Hint: Multiple candidate keys are possible. Pay close attention to BCNF's strict
determinant rule.)

11. Summary / Key Points

Normalization is the process of organizing database relations to reduce redundancy and improve data integrity,
primarily by eliminating anomalies.

Decomposition is the practical technique of breaking down relations into smaller ones as part of normalization.

The primary goals are lossless-join decomposition (ensuring no data loss or spurious tuples upon rejoining) and
dependency-preserving decomposition (ensuring all original FDs can be enforced in the new schema).

Normal Forms (1NF, 2NF, 3NF, BCNF) are a hierarchy of rules, each progressively stricter.
1NF: Atomic, single-valued attributes.

2NF: 1NF + No partial dependencies (non-prime on part of candidate key).

3NF: 2NF + No transitive dependencies (non-prime on non-key attribute that's dependent on a key).

BCNF: For every non-trivial FD X -> Y, X must be a superkey. (Stricter than 3NF).

3NF Decomposition (Synthesis Algorithm) is typically dependency-preserving and lossless-join. It builds relations
from a minimal cover of FDs.

BCNF Decomposition (Analysis Algorithm) is always lossless-join but may not be dependency-preserving. It
iteratively decomposes relations that violate BCNF.

Trade-offs: Higher normal forms reduce redundancy but might increase query complexity (more joins) and sometimes
sacrifice dependency preservation (BCNF).

Real-world applications are pervasive in all database-driven systems where data integrity and consistency are critical.

Highlighted Formulas and Shortcuts:

Closure of attributes X+: The set of all attributes determined by X. Used to find candidate keys and check FD
implications.

Lossless-Join Condition: For R into R1, R2, (R1 ⋂ R2) must be a superkey of R1 or R2.

BCNF Rule: X -> Y in R means X must be a superkey of R (unless Y is a subset of X).

Denormalization
Concept of denormalization, reasons for denormalizing a database (e.g., performance optimization), and its potential
drawbacks.

1. Introduction
Definition Denormalization is a database optimization technique where redundant data is added to an already
normalized database. It is the process of intentionally introducing redundancy into a database to improve query
performance, often by pre-calculating or storing results of joins or aggregate functions. While normalization aims to

[Link] Page 133 of 159

 eliminate data redundancy and improve data integrity, denormalization sacrifices some level of data integrity and
redundancy to achieve faster data retrieval.

Why it is needed (real-life analogy if possible) Normalized databases are excellent for ensuring data integrity and
minimizing storage space, especially in transactional (OLTP) systems where data is frequently updated. However, they
can be inefficient for read-heavy operations, complex queries, or analytical reporting (OLAP) because these often
require joining multiple tables. Analogy: Imagine a meticulously organized library (normalized database) where every
book has a unique location, category, and author. To find a book, you might first look up its category, then its author,
then its specific shelf. This ensures no book is misplaced and every piece of information is unique. Now, imagine a busy
bookstore (denormalized database). To help customers quickly find popular new releases or books by a specific
bestselling author, the store might create a special "New Arrivals" display or a dedicated "Bestsellers by John Doe" table
at the front. These displays contain copies of books already available on their main shelves. While this creates
redundancy (the same book is in two places), it significantly speeds up access for common requests. Denormalization in
databases works similarly: it creates "shortcuts" or pre-assembled data views to speed up frequently run queries, even if
it means storing some data multiple times.

Applications Denormalization is primarily applied in scenarios where read performance is critical and update frequency
is relatively low or can be managed carefully:

Data Warehousing (OLAP): Essential for analytical processing, reporting, and business intelligence, where complex
queries over large datasets are common. Star schemas and snowflake schemas are common denormalized
structures.

Reporting Systems: When generating reports that involve summarizing or joining data from multiple tables,
denormalization can drastically reduce report generation time.

High-Performance OLTP Systems: For specific, frequently accessed queries that are critical for user experience (e.g.,
retrieving a user's profile with all related information in one go).

Materialized Views: Database systems often use materialized views, which are pre-computed tables based on a
query, effectively a form of denormalization.

2. Theory Explanation
In-depth explanation Denormalization is a tactical decision to reverse some normalization steps, primarily to optimize
query performance. It involves adding redundant data or grouping data in a way that would violate typical
normalization forms (like 3NF or BCNF). The core idea is to reduce the number of joins required to retrieve data, thus
minimizing disk I/O and CPU cycles spent on join operations. While normalization focuses on reducing redundancy and
dependencies to maintain data integrity, denormalization reintroduces some redundancy to serve specific application
needs, particularly for read-heavy workloads. This is a trade-off: improved read performance comes at the cost of
increased storage space, slower write operations (as redundant data needs to be updated consistently), and a higher risk
of data inconsistency if not managed properly.

Common denormalization techniques include:

1. Adding Redundant Columns: Copying a column from a "parent" table into a "child" table to avoid a join (e.g.,
storing DepartmentName in the Employee table).

2. Pre-joining Tables: Creating a new table by combining columns from two or more tables that are frequently joined
(effectively creating a materialized view or a wider table).

3. Pre-aggregation / Summary Tables: Storing aggregate values (e.g., sums, counts, averages) that are frequently
requested, instead of calculating them on the fly from detailed transaction data (e.g., DailySalesTotal table).

4. Splitting Tables (Vertical Partitioning): Separating frequently accessed columns from rarely accessed ones into
different tables, even if they logically belong together, to improve performance for common queries. (This can be
seen as a form of denormalization when the split isn't strictly based on functional dependency.)

5. Storing Derived Data: Storing calculated values (e.g., Age from DateOfBirth ) directly in the table.

Diagrams/flowcharts (describe in text if not possible to draw)

[Link] Page 134 of 159

 Scenario: Normalized Schema Consider two tables: Customers and Orders . Customers table:
CustomerID (PK), CustomerName , Address Orders table: OrderID (PK), CustomerID (FK),
OrderDate , TotalAmount

To retrieve the CustomerName for each order, a JOIN operation is required: SELECT [Link],
[Link], [Link] FROM Orders O JOIN Customers C ON [Link] = [Link];

Scenario: Denormalized Schema (Adding Redundant Column) We want to improve the performance of queries
that frequently ask for CustomerName along with Order details. We can add CustomerName directly to the
Orders table.

Customers table: CustomerID (PK), CustomerName , Address (This table still exists for consistency and
full customer details) Orders_Denormalized table: OrderID (PK), CustomerID (FK), CustomerName ,
OrderDate , TotalAmount

Now, to retrieve the CustomerName for each order, no JOIN is needed for this specific query: SELECT
OrderID, CustomerName, Date FROM Orders_Denormalized;

Flowchart Description:

1. Start: Identify a slow query involving multiple joins.

2. Decision: Is the query critical for performance? (Yes/No)

No: Stop (Denormalization not needed).

Yes: Proceed.

3. Identify Data to Redundantly Store: Determine which columns from which tables are frequently joined.

4. Select Denormalization Technique: (e.g., Add redundant column, Create summary table, Merge tables).

5. Modify Schema: Implement the chosen technique (e.g., ALTER TABLE to add column, CREATE TABLE for
summary).

6. Develop Synchronization Mechanism: How will redundant data be kept consistent during updates? (e.g.,
Triggers, Application Logic, ETL processes).

7. Test & Monitor: Verify performance improvement and data consistency.

8. End.

Step-by-step breakdown

1. Analyze Performance Bottlenecks: Identify the specific queries or reports that are slow due to complex joins, large
data volumes, or frequent aggregations. Use database profiling tools and query logs.

2. Identify Denormalization Candidates: Determine which tables and attributes are involved in these slow queries
and which data could be redundantly stored or pre-aggregated to eliminate joins or on-the-fly calculations.

3. Choose a Denormalization Strategy: Select the most appropriate technique (e.g., adding redundant columns,
merging tables, creating summary tables) based on the nature of the bottleneck and data usage patterns.

4. Design the Denormalized Schema: Plan the changes to the database schema, including new columns, new tables,
or modifications to existing tables.

5. Implement Data Synchronization: This is crucial. If data is stored redundantly, a mechanism must be in place to
ensure all copies of the data remain consistent when changes occur. This can involve:
Database Triggers: Automatically update redundant columns when the source data changes.

Application Logic: Ensure the application updates all redundant copies of data when performing writes.

ETL (Extract, Transform, Load) Processes: Commonly used in data warehouses to refresh summary tables
periodically.

[Link] Page 135 of 159

 6. Test and Monitor: After implementing denormalization, thoroughly test the affected queries and applications.
Monitor performance gains and, critically, ensure data consistency is maintained. Be prepared to roll back or adjust if
unintended side effects or new problems arise.

3. Properties & Characteristics

Key properties

Increased Data Redundancy: Data is stored in multiple places.

Faster Read Performance: Queries often run faster due to fewer joins and pre-calculated data.

Slower Write Performance: Update, insert, and delete operations can become slower as multiple copies of data
might need to be modified.

Increased Storage Space: More data is stored due to redundancy.

Higher Risk of Data Inconsistency: If not managed properly, redundant data can become out of sync.

Reduced Query Complexity: SQL queries become simpler as fewer joins are required.

Application Specific: Denormalization is usually done for specific application requirements or reports, not
universally across the entire database.

Advantages & disadvantages

Advantages:

Improved Query Performance: The primary benefit, especially for read-heavy analytical queries and reports.

Reduced Join Operations: Eliminates the need for costly join operations, leading to faster data retrieval.

Simpler Queries: Fewer joins and pre-calculated values make queries easier to write and understand.

Faster Report Generation: Critical for business intelligence and dashboards.

Enhanced Scalability for Reads: Can help distribute read load across wider tables or summary tables.

Disadvantages:

Increased Data Redundancy: Leads to more storage space being consumed.

Data Inconsistency Risk: If redundant data is not meticulously synchronized during updates, inconsistencies can
arise, compromising data integrity.

Slower Write Operations: Inserts, updates, and deletes become more complex and time-consuming as multiple
data copies might need modification.

Complex Data Maintenance: Requires additional logic (triggers, ETL, application code) to keep redundant data
consistent.

Loss of Flexibility: Changes to the schema might be harder to implement if data is tightly coupled and
denormalized across many tables.

Reduced Flexibility for Ad-hoc Queries: While specific common queries are faster, ad-hoc queries might become
less efficient if they need to reconstruct normalized views.

4. Mathematical / Logical Representation

Denormalization doesn't involve traditional mathematical formulas as much as it involves logical trade-offs in query
optimization. We can represent these trade-offs conceptually.

Important formulas (Conceptual)

1. Query Cost (Normalized Schema): Cost_Normalized_Read = Cost_of_Join_Operations +

Cost_of_Selecting_Data Here, Cost_of_Join_Operations is often significant, depending on the number
of tables, join types, index availability, and data volume.

[Link] Page 136 of 159

 2. Query Cost (Denormalized Schema): Cost_Denormalized_Read =
Cost_of_Selecting_Data_from_Wider_or_Summary_Table In this case, Cost_of_Join_Operations
is often reduced to zero or a very small value, leading to Cost_Denormalized_Read <<
Cost_Normalized_Read for specific queries.

3. Write Cost (Normalized Schema): Cost_Normalized_Write =

Cost_of_Updating_Single_Data_Instance

4. Write Cost (Denormalized Schema): Cost_Denormalized_Write =

Cost_of_Updating_Primary_Data_Instance + Cost_of_Updating_N_Redundant_Instances +
Cost_of_Ensuring_Consistency Typically, Cost_Denormalized_Write >>
Cost_Normalized_Write .

5. Storage Cost: Storage_Denormalized = Storage_Normalized + Redundant_Data_Storage

Redundant_Data_Storage represents the additional space consumed by duplicate or pre-calculated data.

Derivations (Logical) The derivation for the benefits of denormalization stems from the fundamental operations of a
database system:

Why Reads are Faster: When data is normalized, information is spread across multiple tables to prevent
redundancy. To retrieve a complete "picture" of an entity (e.g., an order with customer details), the database system
must perform JOIN operations. Each JOIN involves:

1. Reading data blocks from multiple tables from disk.

2. Matching rows based on join conditions.

3. Potentially sorting or hashing data during the join. These operations are CPU and I/O intensive. By denormalizing,
we effectively "pre-join" or "pre-aggregate" the data. The relevant information is already present in a single table
or a summary table. This eliminates the need for JOIN processing, reducing disk I/O and CPU overhead,
leading to faster query execution.

Why Writes are Slower and Riskier: When data is denormalized, a single logical piece of information might be
stored in multiple physical locations.

1. If the original (source) data changes, all its redundant copies must also be updated to maintain consistency. This
requires additional UPDATE statements or trigger executions, increasing the Write Cost .

2. Failure to update all copies precisely can lead to data inconsistency, where different parts of the database show
conflicting information for the same entity. This is the primary risk of denormalization and requires careful
management through triggers, stored procedures, or application-level logic. The
Cost_of_Ensuring_Consistency directly reflects this overhead.

In essence, denormalization shifts computational burden from read time to write time and increases storage, favoring
scenarios where reads are frequent and critical, while writes are less frequent or can tolerate higher latency.

5. Operations / Algorithms
Denormalization is more of a set of strategies rather than distinct "algorithms." Here, we'll illustrate common
denormalization techniques using SQL, which is the direct "code" for DBMS operations.

Algorithm 1: Adding Redundant Columns (Pre-joining Attributes)

Problem statement A Customers table and an Orders table are joined frequently to display customer names
alongside their orders. The join operation is becoming a performance bottleneck for reporting.

Step-by-step algorithm

1. Identify the frequently joined tables ( Customers , Orders ) and the column from the "parent" table
( CustomerName from Customers ) needed in the "child" table ( Orders ).

[Link] Page 137 of 159

 2. Add a new column ( CustomerName ) to the Orders table.

3. Populate this new column with existing data by joining the tables once.

4. Implement a mechanism (e.g., database trigger or application logic) to automatically update the CustomerName
in Orders whenever a customer's name changes in the Customers table.

Dry run example Initial Customers table:

CustomerID CustomerName Address

1 Alice 123 Main St
2 Bob 456 Oak Ave

Initial Orders table:

OrderID CustomerID OrderDate TotalAmount

101 1 2023-01-01 150.00
102 2 2023-01-02 200.00

Step 1: Add CustomerName to Orders table. Orders table (after adding column):

OrderID CustomerID CustomerName OrderDate TotalAmount

101 1 NULL 2023-01-01 150.00
102 2 NULL 2023-01-02 200.00

Step 2: Populate CustomerName in Orders table. Orders table (after population):

OrderID CustomerID CustomerName OrderDate TotalAmount

101 1 Alice 2023-01-01 150.00
102 2 Bob 2023-01-02 200.00

Step 3: Now, a query like SELECT OrderID, CustomerName, OrderDate FROM Orders; does not require a
join. If Alice's name changes to 'Alicia' in Customers , a trigger will automatically update CustomerName for all
orders belonging to CustomerID 1 in the Orders table.

Pseudocode

1. ALTER TABLE Orders ADD COLUMN CustomerName TYPE VARCHAR;

2. FOR EACH row IN Orders: SELECT CustomerName FROM Customers WHERE CustomerID =
[Link]; UPDATE Orders SET CustomerName = selected_CustomerName WHERE
OrderID = [Link];

3. CREATE TRIGGER CustomerName_Update_Trigger ON Customers AFTER UPDATE OF

CustomerName FOR EACH ROW: UPDATE Orders SET CustomerName = [Link] WHERE
CustomerID = [Link];

Code (SQL) Assuming Orders and Customers tables exist:

-- 1. Add the redundant column

ALTER TABLE Orders
ADD COLUMN CustomerName VARCHAR(255);

-- 2. Populate the new column with existing data

UPDATE Orders O
SET CustomerName = (SELECT [Link]
FROM Customers C

[Link] Page 138 of 159

 WHERE [Link] = [Link]);

-- 3. Create a trigger to maintain consistency on updates to CustomerName

-- (This example uses PostgreSQL syntax for trigger. Syntax varies by DBMS.)
-- CREATE FUNCTION update_order_customer_name_func()
-- RETURNS TRIGGER AS $$
-- BEGIN
-- UPDATE Orders
-- SET CustomerName = [Link]
-- WHERE CustomerID = [Link];
-- RETURN NEW;
-- END;
-- $$ LANGUAGE plpgsql;

-- CREATE TRIGGER update_order_customer_name_trigger

-- AFTER UPDATE OF CustomerName ON Customers
-- FOR EACH ROW
-- EXECUTE FUNCTION update_order_customer_name_func();

Note: For simplicity, I've commented out the trigger code as its syntax is DBMS-specific and more complex than simple SQL
DDL/DML. The conceptual pseudocode explains the intention.

Algorithm 2: Pre-aggregation / Summary Tables

Problem statement A large SalesTransactions table contains every individual sale. Reports frequently require
monthly total sales for each product, which is very slow to compute on-the-fly due to the huge number of transactions.

Step-by-step algorithm

1. Identify the aggregation needed ( SUM of Amount grouped by Month and ProductID ).

2. Create a new table (e.g., MonthlyProductSales ) with columns for the grouping keys ( Year , Month ,
ProductID ) and the aggregated value ( TotalSales ).

3. Populate this table by running the aggregate query once over the historical data.

4. Implement a periodic refresh mechanism (e.g., daily/weekly ETL job) to update the summary table with new
transactions. This might involve incrementally updating new data or rebuilding the table.

Dry run example Initial SalesTransactions table:

TransactionID ProductID SaleDate Amount

T1 P1 2023-01-05 100
T2 P2 2023-01-10 150
T3 P1 2023-01-15 200
T4 P1 2023-02-01 50
T5 P2 2023-02-05 300

Step 1: Create MonthlyProductSales table. Step 2: Populate for January 2023:

For P1: 100 + 200 = 300

For P2: 150 = 150

MonthlyProductSales table (after initial population):

Year Month ProductID TotalSales

2023 1 P1 300

[Link] Page 139 of 159

 Year Month ProductID TotalSales
2023 1 P2 150

Step 3: Periodically refresh for February 2023 and new transactions. MonthlyProductSales table (after refresh):

Year Month ProductID TotalSales

2023 1 P1 300
2023 1 P2 150
2023 2 P1 50
2023 2 P2 300

Now, a query for monthly sales is simply SELECT * FROM MonthlyProductSales; which is much faster than
GROUP BY on millions of SalesTransactions .

Pseudocode

1. CREATE TABLE MonthlyProductSales (Year INT, Month INT, ProductID VARCHAR, TotalSales
DECIMAL);

2. INSERT INTO MonthlyProductSales SELECT YEAR(SaleDate), MONTH(SaleDate), ProductID,

SUM(Amount) FROM SalesTransactions GROUP BY YEAR(SaleDate), MONTH(SaleDate),
ProductID;

3. SCHEDULE JOB (e.g., daily/weekly): DELETE FROM MonthlyProductSales WHERE Year >=
Current_Refresh_Year AND Month >= Current_Refresh_Month; (or update incrementally) INSERT
INTO MonthlyProductSales SELECT YEAR(SaleDate), MONTH(SaleDate), ProductID,
SUM(Amount) FROM SalesTransactions WHERE SaleDate >= Last_Refreshed_Date GROUP BY
YEAR(SaleDate), MONTH(SaleDate), ProductID;

Code (SQL) Assuming SalesTransactions table exists:

-- 1. Create the summary table

CREATE TABLE MonthlyProductSales (
SalesYear INT,
SalesMonth INT,
ProductID VARCHAR(50),
TotalSales DECIMAL(18, 2),
PRIMARY KEY (SalesYear, SalesMonth, ProductID)
);

-- 2. Populate the summary table from existing data

INSERT INTO MonthlyProductSales (SalesYear, SalesMonth, ProductID, TotalSales)
SELECT
EXTRACT(YEAR FROM SaleDate) AS SalesYear,
EXTRACT(MONTH FROM SaleDate) AS SalesMonth,
ProductID,
SUM(Amount) AS TotalSales
FROM
SalesTransactions
GROUP BY
EXTRACT(YEAR FROM SaleDate),
EXTRACT(MONTH FROM SaleDate),
ProductID;

-- 3. Example of how to refresh (e.g., for new data, this might be run daily/hourly)

[Link] Page 140 of 159

 -- This approach re-aggregates for the current month/year for simplicity.
-- More sophisticated ETL would handle incremental updates.
-- DELETE FROM MonthlyProductSales
-- WHERE SalesYear = EXTRACT(YEAR FROM CURRENT_DATE)
-- AND SalesMonth = EXTRACT(MONTH FROM CURRENT_DATE);

-- INSERT INTO MonthlyProductSales (SalesYear, SalesMonth, ProductID, TotalSales)

-- SELECT
-- EXTRACT(YEAR FROM SaleDate) AS SalesYear,
-- EXTRACT(MONTH FROM SaleDate) AS SalesMonth,
-- ProductID,
-- SUM(Amount) AS TotalSales
-- FROM
-- SalesTransactions
-- WHERE
-- EXTRACT(YEAR FROM SaleDate) = EXTRACT(YEAR FROM CURRENT_DATE)
-- AND EXTRACT(MONTH FROM SaleDate) = EXTRACT(MONTH FROM CURRENT_DATE)
-- GROUP BY
-- EXTRACT(YEAR FROM SaleDate),
-- EXTRACT(MONTH FROM SaleDate),
-- ProductID;

6. Complexity Analysis
Time complexity

Read Operations (Denormalized):

Best Case: O(1) for a direct indexed lookup on a wide table, or O(log N) for a B-tree indexed access.

Worst Case: O(N) for a full table scan, but still better than a full table scan plus join operations on multiple large
tables.

Average Case: Significantly faster than normalized schema reads due to the elimination of join costs. The
Cost_of_Join_Operations is often the dominant factor in complex queries, and denormalization aims to
reduce or eliminate this.

Write Operations (Denormalized):

Best Case: O(log N) for updating a single row, but if it triggers updates to redundant data, it becomes O(log N +
M * log R) where M is the number of redundant copies and R is their size.

Worst Case: O(N) if many redundant records need full scans or complex trigger logic for consistency. Can be
substantially slower than normalized writes.

Average Case: Slower than normalized writes due to the overhead of maintaining redundant data consistency.

Space complexity

Denormalized Schema: O(N * K), where N is the number of logical records and K represents the average number of
columns including redundant ones. This is greater than a normalized schema. The primary goal is to optimize time,
not space. Redundant data directly increases space usage. Summary tables also add to space.

Comparison with alternatives

Versus Normalized Schema:

Read Performance: Denormalized is generally much faster for specific, targetted queries that previously required
joins or aggregations. Normalized is generally slower for these specific queries.

Write Performance: Normalized is generally faster and simpler because each piece of data exists in one place.
Denormalized is slower and more complex due to the need to maintain consistency across redundant copies.

[Link] Page 141 of 159

 Data Integrity: Normalized has inherent high data integrity due to minimal redundancy. Denormalized has a
higher risk of data inconsistency if not managed carefully.

Storage Space: Normalized uses less storage. Denormalized uses more.

Flexibility: Normalized is more flexible for ad-hoc queries and schema evolution. Denormalized is optimized for
specific queries, potentially less flexible for unanticipated query patterns.

Complexity: Normalized schema design is conceptually simpler for transactional systems. Denormalized schema
management (especially consistency) adds significant operational complexity.

Alternatives to Denormalization for Performance:

Indexing: The first line of defense. Proper indexing can often speed up queries significantly without introducing
redundancy. Denormalization is considered when indexing alone is insufficient.

Query Optimization: Rewriting inefficient queries can often yield substantial performance gains.

Caching: Caching frequently accessed data at the application layer can reduce database load without schema
changes.

Horizontal Partitioning/Sharding: Distributing data across multiple database servers can improve scalability
and performance for very large datasets, orthogonal to denormalization.

7. Examples
Solved Problem 1 (Small): Adding Redundant Column Scenario: A company has a Products table and a
ProductCategories table. Products : ProductID (PK), CategoryID (FK), ProductName , Price
ProductCategories : CategoryID (PK), CategoryName Reports frequently need to display ProductName
and CategoryName together. The join is becoming noticeable.

Solution: Denormalize by adding CategoryName to the Products table.

Before Denormalization (Normalized Query):

SELECT [Link], [Link], [Link]

FROM Products P
JOIN ProductCategories PC ON [Link] = [Link]
WHERE [Link] > 50;

Steps:

1. Add CategoryName column to Products . ALTER TABLE Products ADD COLUMN CategoryName
VARCHAR(100);

2. Populate CategoryName in Products based on existing data. UPDATE Products P SET CategoryName
= (SELECT [Link] FROM ProductCategories PC WHERE [Link] =
[Link]);

3. Implement a trigger (or application logic) to update [Link] if

[Link] changes, or if a product's CategoryID changes.

After Denormalization (Denormalized Query):

SELECT ProductName, CategoryName, Price

FROM Products
WHERE Price > 50;

This query is now faster as it avoids a join.

[Link] Page 142 of 159

 Solved Problem 2 (Medium): Pre-aggregation (Summary Table) Scenario: An e-commerce platform has a
OrderItems table recording every item sold. OrderItems : OrderItemID (PK), OrderID , ProductID ,
Quantity , UnitPrice , SaleDate Management frequently asks for the total revenue for each ProductID per
month. Generating this report from OrderItems on the fly is slow for large datasets.

Solution: Create a MonthlyProductRevenue summary table.

Before Denormalization (Normalized Query):

SELECT
EXTRACT(YEAR FROM SaleDate) AS SalesYear,
EXTRACT(MONTH FROM SaleDate) AS SalesMonth,
ProductID,
SUM(Quantity * UnitPrice) AS MonthlyRevenue
FROM
OrderItems
GROUP BY
EXTRACT(YEAR FROM SaleDate),
EXTRACT(MONTH FROM SaleDate),
ProductID
ORDER BY
SalesYear, SalesMonth, ProductID;

This query can be very slow if OrderItems has millions of rows.

Steps:

1. Create MonthlyProductRevenue table.

CREATE TABLE MonthlyProductRevenue (

SalesYear INT,
SalesMonth INT,
ProductID VARCHAR(50),
TotalRevenue DECIMAL(18, 2),
PRIMARY KEY (SalesYear, SalesMonth, ProductID)
);

2. Populate the MonthlyProductRevenue table from OrderItems .

INSERT INTO MonthlyProductRevenue (SalesYear, SalesMonth, ProductID, TotalRevenue)

SELECT
EXTRACT(YEAR FROM SaleDate),
EXTRACT(MONTH FROM SaleDate),
ProductID,
SUM(Quantity * UnitPrice)
FROM
OrderItems
GROUP BY
EXTRACT(YEAR FROM SaleDate),
EXTRACT(MONTH FROM SaleDate),
ProductID;

3. Set up an ETL job (e.g., nightly) to refresh MonthlyProductRevenue . This could involve deleting and re-
inserting, or more efficiently, updating existing monthly records and inserting new ones for the current month.

[Link] Page 143 of 159

 After Denormalization (Denormalized Query):

SELECT SalesYear, SalesMonth, ProductID, TotalRevenue

FROM MonthlyProductRevenue
ORDER BY SalesYear, SalesMonth, ProductID;

This query is significantly faster as it reads directly from a much smaller, pre-aggregated table.

8. Common Mistakes & Edge Cases

Where students go wrong

Denormalizing Unnecessarily: Applying denormalization without a clear performance bottleneck or without first
trying other optimization techniques (indexing, query tuning). It's an optimization, not a default.

Ignoring Data Consistency: Failing to implement robust mechanisms (triggers, application logic, ETL) to keep
redundant data synchronized. This is the biggest pitfall and can lead to unreliable data.

Over-Denormalizing: Adding too much redundancy, leading to very large tables, extremely slow write operations,
and complex maintenance, negating the benefits.

Not Understanding the Trade-offs: Believing denormalization is a universal solution without acknowledging its
significant drawbacks regarding data integrity and write performance.

Premature Denormalization: Optimizing before there's a problem. Schema design should prioritize normalization
first, then denormalize only when necessary for performance.

Poorly Chosen Denormalization Strategy: Using redundant columns when a summary table is more appropriate,
or vice-versa.

Special cases

Data Warehouses (OLAP): Denormalization is often the default strategy here (e.g., star schema, snowflake schema).
Data warehouses are read-heavy, often dealing with historical data where updates are batch-processed or rare,
making denormalization highly beneficial and standard practice.

Read-Heavy OLTP Systems with Specific Bottlenecks: For systems like social media feeds or product catalogs
where certain data is read millions of times per second, denormalization might be applied to a small, critical subset
of the data to achieve extreme performance for those specific reads, even in an OLTP context.

Master-Detail Data with Infrequent Master Updates: When a "master" record (e.g., a Customer record)
changes rarely, but its "detail" records (e.g., Orders ) are frequently accessed with master information,
denormalizing a few master attributes into the detail table can be very effective with low consistency overhead.

Distributed Systems/Microservices: Denormalization is often used here to reduce cross-service calls. A service
might duplicate data owned by another service to serve its own read queries faster, accepting eventual consistency.

9. Real-Life Applications
Data Warehousing and Business Intelligence (BI): This is the most prevalent application. Data warehouses are
designed for analytical queries over vast historical datasets. Denormalized schemas (like star schemas, where fact tables
are denormalized versions of transactions and dimension tables are denormalized master data) significantly speed up
complex reports, aggregations, and trend analysis. Examples include sales reporting, customer behavior analysis, and
financial performance dashboards.

Reporting Systems: Any system that generates complex, frequently accessed reports can benefit. Instead of computing
aggregates on demand (which can take minutes or hours), pre-aggregated tables (denormalized) allow reports to run in
seconds. Examples include monthly sales reports, daily website traffic summaries, or inventory turnover reports.

Search Engines and Content Management Systems: To provide fast search results, an inverted index (a form of
denormalization) stores pre-computed mappings from keywords to document IDs. Similarly, content management

[Link] Page 144 of 159

 systems might denormalize page metadata into a single table for quick content lookups.

Social Media Platforms: To display a user's feed quickly, social media platforms might denormalize elements from
various sources (user posts, friend activity, likes) into a "timeline" table that is optimized for fast reads, rather than
joining multiple tables on every page load. Consistency might be eventual.

E-commerce Product Catalogs: For a product display page, retrieving product details, category name, brand name,
and average rating might involve several joins. Denormalizing key attributes like CategoryName and BrandName
into the Product table, or even pre-calculating AverageRating into the product, speeds up page load times.

Caching and Materialized Views: Many database systems and application architectures use caching or materialized
views (which are essentially denormalized tables or query results) to store frequently requested data in a readily
accessible format, reducing the load on the underlying normalized tables.

10. Practice Problems

Easy A university database has two tables: Courses ( CourseID , CourseName , Credits ) and Departments
( DepartmentID , DepartmentName ). Students frequently search for courses by department name. Suggest a
denormalization strategy to speed up this search. What column would you add, and to which table?

Medium An online forum has a Posts table ( PostID , UserID , PostContent , PostDate ) and a Users
table ( UserID , UserName , RegistrationDate ). The forum homepage needs to display the 10 most recent
posts, along with the UserName of the author. This query is becoming slow.

1. Describe how you would denormalize the schema to improve this specific query's performance.

2. What are the advantages and disadvantages of your proposed denormalization strategy in this context?

3. How would you maintain data consistency if a UserName changes?

Hard Consider a large IoT system collecting sensor readings. Each sensor produces thousands of readings per minute,
stored in a SensorReadings table ( ReadingID , SensorID , Timestamp , Value ). You also have a
Sensors table ( SensorID , Location , SensorType ). Management requires daily, hourly, and 15-minute
average readings for all sensors, and these reports must be available almost instantly.

1. Design a denormalized schema using summary tables to achieve the required reporting performance. Clearly define
the new tables and their columns.

2. Describe an ETL strategy (e.g., daily batch, streaming updates) to populate and maintain these summary tables,
considering the high volume of incoming SensorReadings .

3. Discuss the trade-offs between update latency (how quickly new readings are reflected in reports) and query
performance for your chosen ETL and denormalization strategy.

11. Summary / Key Points

Denormalization is a deliberate database optimization strategy that involves introducing controlled redundancy into a
normalized schema to improve read performance for specific, critical queries, often in analytical or reporting contexts.

Key Points:

Purpose: Primarily to boost query performance by reducing the need for costly join operations and on-the-fly
aggregations.

Trade-offs: It sacrifices some data integrity (risk of inconsistency), increases storage space, and slows down write
operations (inserts, updates, deletes) due to the need to maintain redundant data.

When to Use: Ideal for read-heavy workloads like data warehousing (OLAP), reporting systems, or high-traffic OLTP
scenarios with specific bottlenecks.

[Link] Page 145 of 159

 When NOT to Use: Avoid for write-heavy OLTP systems where data integrity is paramount and frequent updates would
incur high consistency overhead. Avoid premature optimization – always try indexing and query tuning first.

Common Techniques:
Adding Redundant Columns: Copying attributes from a master table to a detail table.

Pre-joining Tables: Creating a wider table by merging frequently joined tables.

Pre-aggregation / Summary Tables: Storing pre-calculated aggregate values (e.g., daily totals, monthly averages).

Consistency is Key: If denormalizing, robust mechanisms (triggers, application logic, ETL processes) are crucial to
ensure redundant data remains consistent across the database.

Highlighted Formulas (Conceptual) and Shortcuts:

Denormalization = Performance Gain (Reads) + Performance Loss (Writes) + Storage Cost + Consistency Risk.

Rule of Thumb: Normalize first to ensure integrity, then selectively denormalize only when profiling reveals specific,
critical performance bottlenecks that cannot be solved by other means.

Query Cost: Normalized (Joins + Selects) vs. Denormalized (Selects Only)

Write Cost: Normalized (Single Update) vs. Denormalized (Multiple Updates + Consistency Checks)

Normalization vs. Denormalization: Trade-offs

Discussion on the balance between normalization levels, performance, storage, and data integrity in real-world database
design.

1. Introduction
Definition

Normalization: The process of organizing data in a database to reduce data redundancy and improve data integrity.
It involves dividing a database into two or more tables and defining relationships between them. This process is
guided by a series of rules called normal forms (1NF, 2NF, 3NF, BCNF, etc.).

Denormalization: The process of intentionally adding redundancy to a normalized database, often by combining
tables or adding duplicate columns. The primary goal is to improve read performance of the database at the expense
of potential data integrity issues and increased storage space.

Trade-offs: The core idea is that database designers often face a dilemma: prioritize data consistency and storage
efficiency (Normalization) or prioritize query performance and simplicity (Denormalization). The choice involves
evaluating the system's specific requirements and finding an optimal balance.

Why it is needed (real-life analogy if possible) Imagine a meticulously organized library (Normalization). Each book
has a unique ID, its details are stored once, and categories are in a separate index. If you want to find all books by
"Author A" in "Genre B", you might need to consult multiple lists and cross-reference IDs. This ensures no book is
duplicated, and all information is consistent.

Now, imagine a "Popular Reads" shelf at the front of the library (Denormalization). It contains copies of the most
frequently requested books, even if they are also on the main shelves. This makes it super fast for a patron to grab a
popular book. However, if a book's cover changes, you need to update it on the main shelf and on the "Popular Reads"
shelf, introducing a risk of inconsistency if one update is missed.

This analogy highlights the need:

Normalization: Essential for transactional systems (OLTP) where data integrity, consistency, and efficient updates are
critical. It prevents update, insertion, and deletion anomalies.

[Link] Page 146 of 159

 Denormalization: Needed in analytical systems (OLAP) or for specific performance bottlenecks in transactional
systems where quick data retrieval for reporting or common queries is paramount, even if it means some
redundancy and potential for anomalies.

Applications

Online Transaction Processing (OLTP) Systems: Typically favor normalization for banking, e-commerce
transactions, order entry, etc., where data integrity and concurrent writes are critical.

Online Analytical Processing (OLAP) Systems / Data Warehouses: Heavily utilize denormalization (e.g., star
schema, snowflake schema) to enable fast complex queries for business intelligence, reporting, and data analysis.

Reporting Databases: Often a denormalized copy or subset of an OLTP database, optimized for generating reports
quickly.

Specific Performance Bottlenecks: Applied selectively in OLTP systems where certain read queries are unacceptably
slow due to excessive joins.

2. Theory Explanation
In-depth explanation The choice between normalization and denormalization is a fundamental aspect of database
design, driven by the system's operational requirements.

Normalization aims to eliminate redundant data by storing each piece of information in a single place. This is achieved
by decomposing large tables into smaller, related tables. For instance, customer details (name, address) might be in a
Customers table, and orders they placed in an Orders table, linked by a customer_id .

Benefits: Reduces data anomalies (update, insertion, deletion), conserves storage space, makes database
maintenance (updates, deletes) easier and more consistent, and provides a more flexible and scalable design.

Costs: Requires more complex queries involving multiple JOIN operations to retrieve complete information, which
can lead to slower read performance, especially on very large datasets.

Denormalization, conversely, introduces redundancy deliberately. This might involve:

Adding redundant columns: Copying a column from a related table directly into the current table (e.g., putting
customer_name into the Orders table).

Creating aggregate tables: Storing pre-calculated summary data (e.g., a DailySalesSummary table that
aggregates sales from the Orders table).

Pre-joining tables: Storing data that would typically require a join in a single table or materialized view.

Benefits: Significantly improves read query performance by reducing the number of JOIN operations or
eliminating them entirely, simplifies query writing, and can optimize specific reporting needs.

Costs: Increases storage space, introduces the risk of data anomalies (if redundant data is not kept consistent),
makes update/delete operations more complex (as multiple copies of data might need updating), and can make the
schema less flexible for future changes.

The "trade-off" is precisely this balancing act. A highly normalized database is excellent for data integrity and
transactional consistency but might struggle with read-heavy analytical queries. A denormalized database excels at fast
reads but requires careful management to prevent data inconsistencies, especially in systems with frequent writes.
Modern database design often involves a hybrid approach, where core transactional data is normalized, and specific
parts or derived data are denormalized for performance.

Diagrams/flowcharts (describe in text if not possible to draw)

graph TD
A[Start Database Design] --> B{What are the primary system requirements?};
B --> C{Is the system OLTP (Transaction-Heavy)?};
C -- Yes --> D[Prioritize Normalization];

[Link] Page 147 of 159

 C -- No --> E{Is the system OLAP (Read-Heavy / Analytical)?};
E -- Yes --> F[Prioritize Denormalization];
E -- No --> G[Consider Hybrid Approach];
D --> H[Design Normalized Schema];
F --> I[Design Denormalized Schema (e.g., Star/Snowflake)];
G --> J[Start with Normalization];
J --> K{Identify Performance Bottlenecks (Slow Reads/Joins)?};
K -- Yes --> L[Selectively Apply Denormalization];
K -- No --> M[Maintain Normalization];
L --> N[Evaluate Trade-offs & Manage Redundancy (Triggers/ETL)];
M --> O[Final Schema Design];
N --> O;
I --> O;
H --> O;

Decision Flowchart for Normalization vs. Denormalization

Start: Begin the database design process.

Determine System Type: Identify if the system is primarily for Online Transaction Processing (OLTP - write-heavy,
integrity-critical) or Online Analytical Processing (OLAP - read-heavy, reporting).

OLTP Path: If OLTP, the primary focus is on Normalization to ensure data integrity and efficient writes.

OLAP Path: If OLAP, the primary focus is on Denormalization (e.g., using star or snowflake schemas) for fast
analytical queries.

Hybrid Path (for OLTP with reporting needs):

Start with a normalized schema.

Monitor for performance bottlenecks, especially slow read queries involving many joins.

If bottlenecks are found, selectively apply denormalization techniques to specific tables or columns.

Crucially, evaluate the trade-offs: the performance gain vs. the increased complexity of managing redundant data
(e.g., using triggers, ETL processes for consistency).

End: Arrive at the final optimized schema design.

Step-by-step breakdown (Decision Process for Denormalization in an OLTP-first system)

1. Start with a Normalized Design: Begin by designing the database schema according to normalization principles
(up to 3NF or BCNF) to ensure data integrity and avoid anomalies. This is generally the best starting point for
transactional systems.

2. Identify Performance Requirements: Understand the expected workload, particularly the frequency and criticality
of various queries. Pay attention to read-intensive reports or dashboards.

3. Benchmark and Monitor: Implement the normalized design and monitor its performance under real or simulated
loads. Identify specific queries that are performing poorly, especially those involving complex multi-table joins.

4. Pinpoint Bottlenecks: Analyze the execution plans of slow queries. Determine if the performance issue stems from
excessive I/O due to many joins, large result sets, or specific table sizes.

5. Propose Denormalization Strategies: For identified bottlenecks, consider specific denormalization techniques:
Adding Derived/Redundant Columns: Copying a frequently accessed column from a parent table to a child
table (e.g., customer_name in Order table).

Creating Aggregate/Summary Tables: Pre-calculating and storing aggregated data (e.g., MonthlySales
from OrderDetails ).

Materialized Views: Database objects that store the result of a query, refreshing periodically.

Vertical Partitioning: Splitting a table by columns if some columns are accessed far more frequently than others.

[Link] Page 148 of 159

 6. Evaluate Trade-offs: For each proposed denormalization, rigorously assess:
Performance Gain: How much faster will the critical queries become?

Storage Cost: How much additional disk space will be consumed?

Maintenance Overhead: How will updates, inserts, and deletes to the original data be propagated to the
redundant data? Will triggers, batch jobs, or application logic be needed?

Risk of Anomalies: What is the likelihood and impact of data inconsistencies?

7. Implement Selectively: Apply denormalization only to the specific areas where the performance gain significantly
outweighs the increased complexity and risks. Avoid blanket denormalization.

8. Manage Redundancy: If denormalization is applied, implement mechanisms to maintain data consistency (e.g.,
database triggers, application-level logic, periodic ETL jobs for data warehouses).

9. Re-evaluate and Optimize: Continuously monitor the system's performance and adjust the schema as necessary.
Database design is an iterative process.

3. Properties & Characteristics

Key properties

Feature Normalization Denormalization

Data Redundancy Minimized (each fact stored once) Intentionally increased (facts stored multiple times)
Data Integrity High (easy to maintain consistency) Lower (risk of inconsistencies if not managed well)
High (more joins required for complete
Query Complexity Low (fewer/no joins required for common queries)
data)
Read Performance Slower (due to joins) Faster (reduced I/O, fewer joins)
Write Faster (simpler updates, less data to Slower (more data to modify, potential trigger
Performance modify) overhead)
Storage Space Less (due to reduced redundancy) More (due to increased redundancy)
High (easier to adapt to new Lower (changes might affect more tables/redundant
Design Flexibility
requirements) data)
Use Case Focus OLTP (Transactional systems) OLAP (Analytical/Reporting systems)

Advantages & disadvantages

Normalization

Advantages:
Reduced Data Redundancy: Each piece of data is stored only once, saving disk space.

Improved Data Integrity: Ensures data consistency and accuracy across the database, preventing anomalies.

Easier Maintenance: Updates and deletions are simpler as data only needs to be changed in one place.

More Flexible Design: Easier to modify the schema and add new features without affecting existing data
structures.

Better for Write-Heavy Systems: More efficient for applications with frequent inserts, updates, and deletes.

Disadvantages:
Slower Read Queries: Retrieving complete information often requires complex joins across multiple tables,
which can be slow.

Complex Query Writing: Developers need to write more elaborate queries with multiple join clauses.

Increased I/O Operations: Fetching data from multiple tables can lead to more disk reads.

Denormalization

Advantages:

[Link] Page 149 of 159

 Faster Read Queries: Reduces the need for joins, leading to quicker retrieval of data.

Simpler Query Writing: Queries become less complex and easier to write.

Optimized for Reporting: Excellent for analytical processing and generating reports rapidly.

Fewer I/O Operations: Often reduces disk reads by having all necessary data in fewer tables.

Disadvantages:
Increased Data Redundancy: Leads to more storage space consumption.

Risk of Data Anomalies: If redundant data is not meticulously maintained, inconsistencies can arise (e.g.,
updating a customer's name in one table but not in a denormalized order table).

Complex Update/Delete Operations: Maintaining consistency across redundant data can require complex
application logic, triggers, or batch processes.

Less Flexible Design: Changes to the schema might require more effort to update redundant data structures.

Not Ideal for Write-Heavy Systems: Can slow down write operations due to the need to update multiple copies
of data.

4. Mathematical / Logical Representation

This topic is more about database design principles and trade-offs than mathematical formulas. However, we can express
the logical relationships and considerations.

Important logical considerations/relationships Let:

N be the degree of Normalization (higher N implies more normalized).

D be the degree of Denormalization (higher D implies more denormalized).

P_Read be Read Performance.

P_Write be Write Performance (including updates and deletes).

C_Integrity be Data Integrity/Consistency.

C_Storage be Storage Cost.

C_Query be Query Complexity.

C_Maintenance be Maintenance Complexity (for schema evolution and data consistency).

Then, the logical relationships can be expressed as:

1. Normalization vs. Read Performance: P_Read ∝ 1/N (As N increases, P_Read tends to decrease due to more
joins). P_Read ∝ D (As D increases, P_Read tends to increase due to fewer joins).

2. Normalization vs. Write Performance & Integrity: P_Write ∝ N (As N increases, P_Write often improves for
individual records, less redundant data to update). C_Integrity ∝ N (As N increases, data integrity is easier to
maintain). P_Write ∝ 1/D (As D increases, P_Write can decrease due to redundant updates and consistency
checks). C_Integrity ∝ 1/D (As D increases, data integrity becomes harder to maintain).

3. Storage Cost: C_Storage ∝ 1/N (As N increases, C_Storage decreases). C_Storage ∝ D (As D increases,
C_Storage increases due to redundancy).

4. Query Complexity: C_Query ∝ N (As N increases, queries become more complex with more joins). C_Query ∝
1/D (As D increases, queries become simpler with fewer joins).

5. Maintenance Complexity: C_Maintenance ∝ D (As D increases, maintaining consistency of redundant data

increases complexity). C_Maintenance ∝ 1/N (As N increases, schema maintenance is generally simpler).

[Link] Page 150 of 159

 The goal is to find an optimal point where P_Read is acceptable for critical queries, C_Integrity is maintained,
and C_Maintenance is manageable, given the system's specific workload and constraints. This is not a strict
mathematical formula but a logical framework for understanding the trade-offs.

Derivations (if any) Not applicable in the traditional sense for this conceptual topic. The "derivation" is the logical
conclusion that arises from the system's functional and non-functional requirements. For example, if "fast reporting" is a
primary requirement, it derives a need to consider denormalization, which then derives the need to manage redundancy.

5. Operations / Algorithms
This section typically covers algorithms for specific operations. While Normalization involves algorithms for decomposition
(e.g., BCNF decomposition algorithm), "Normalization vs. Denormalization: Trade-offs" is more about a design decision
process rather than a discrete algorithm that runs within the database. However, we can frame the decision-making process
for applying denormalization as a pseudo-algorithm.

Algorithm: Denormalization Decision Framework

Problem statement Given an existing or planned database schema, and a set of performance requirements (especially
for read-heavy operations), determine whether and how to selectively apply denormalization to improve system
performance while minimizing the risks of data inconsistency.

Step-by-step algorithm

1. Input: System Requirements (e.g., expected query types, read/write ratio, data integrity criticality), Initial Normalized
Schema.

2. Phase 1: Initial Assessment a. Evaluate the primary purpose of the system (OLTP, OLAP, Hybrid). b. If OLTP-primary,
prioritize normalization for core transactional tables. c. If OLAP-primary, prioritize denormalization for analytical
tables (e.g., fact/dimension tables). d. If Hybrid, start with normalization, proceed to performance analysis.

3. Phase 2: Performance Monitoring & Identification (for OLTP/Hybrid systems) a. Implement the normalized
schema (or simulate workload on it). b. Monitor query performance, specifically identifying slow-running queries,
frequent joins, and resource-intensive reports. c. Identify critical read queries that do not meet performance targets.

4. Phase 3: Denormalization Strategy Proposal a. For each identified critical slow query, analyze the involved tables
and columns. b. Propose specific denormalization techniques: i. Redundant Columns: Copy frequently joined
columns (e.g., ProductName into OrderDetails ). ii. Summary/Aggregate Tables: Create new tables to store
pre-calculated aggregates (e.g., MonthlySalesSummary ). iii. Materialized Views: Define database objects that
store query results and are refreshed periodically. iv. Pre-joining/Combined Tables: Merge small, frequently joined
tables into a larger one.

5. Phase 4: Impact Analysis & Risk Assessment a. For each proposed denormalization strategy, quantify the expected
performance gain for the targeted queries. b. Estimate the increase in storage space. c. Assess the impact on write
operations (inserts, updates, deletes): i. How many redundant copies need updating? ii. What mechanisms are
needed to maintain consistency (triggers, application logic, ETL jobs)? iii. What is the risk of data anomalies if
consistency mechanisms fail? d. Weigh the performance benefits against the increased complexity, storage, and data
integrity risks.

6. Phase 5: Implementation & Management a. Selectively implement denormalization strategies where benefits
clearly outweigh costs. b. Implement mechanisms to ensure data consistency for redundant data. c. Document the
denormalization decisions and the associated consistency mechanisms.

7. Phase 6: Re-evaluation: a. Continuously monitor performance and data integrity after denormalization. b. Refine or
revert denormalization if unintended consequences arise.

Dry run example Scenario: An e-commerce platform with a Products table and an OrderItems table. Users
frequently view their Order History , which requires displaying the product name for each item in an order.

Initial Normalized Schema:

[Link] Page 151 of 159

 Products table: (ProductID PK, ProductName, Price, Description)

OrderItems table: (OrderItemID PK, OrderID FK, ProductID FK, Quantity, UnitPrice)

Problem: The query to get order history with product names is: SELECT [Link], [Link],
[Link], [Link] FROM OrderItems oi JOIN Products p ON [Link] =
[Link] WHERE [Link] = :order_id; This JOIN operation is performed very frequently and is
becoming a performance bottleneck as the Products table grows large.

Denormalization Decision Process:

1. Assessment: Hybrid system (OLTP for orders, OLAP-like for order history viewing).

2. Monitoring: Identified Order History query as slow.

3. Strategy Proposal: Add ProductName as a redundant column directly into the OrderItems table.
New OrderItems table: (OrderItemID PK, OrderID FK, ProductID FK, ProductName,
Quantity, UnitPrice)

4. Impact Analysis:
Performance Gain: Order History query becomes SELECT OrderID, ProductName, Quantity,
UnitPrice FROM OrderItems WHERE OrderID = :order_id; - no join needed, significantly faster
reads.

Storage Cost: Negligible increase (repeating ProductName for each order item, but strings are relatively small
compared to entire rows).

Maintenance Overhead/Risk:
When a product's ProductName changes in the Products table, a mechanism is needed to update all
corresponding ProductName entries in the OrderItems table. This could be a database trigger on
[Link] update, or application logic.

Risk of inconsistency: If the update mechanism fails, an OrderItem might show an old ProductName .
This is generally acceptable for historical order items (showing the name at the time of purchase), but not for
active product listings. Self-correction: For order history, it's often desirable to keep the name at time of
purchase, making this denormalization lower risk. However, if the requirement was "always show current product
name", then the update mechanism is critical.

5. Implementation: Implement the ProductName column in OrderItems . For new orders, the ProductName
is copied during insertion. For existing data, a one-time migration populates the column.

6. Re-evaluation: Monitor the performance of Order History and ensure ProductName changes are handled
correctly if necessary.

Pseudocode

FUNCTION DecideDenormalization(SystemPurpose, PerformanceData, SchemaDefinition):

IF SystemPurpose == "OLAP" THEN
PRINT "Prioritize denormalization for analytical queries (e.g., star schema)."
RETURN "Denormalized Schema"
ELSE IF SystemPurpose == "OLTP" THEN
PRINT "Start with normalized schema to ensure data integrity."
IF [Link] AND [Link]
FOR EACH SlowQuery IN [Link]:
IdentifiedTables = GetTablesInvolved(SlowQuery)
PotentialDenormalizationStrategies = AnalyzeStrategies(IdentifiedTables

FOR EACH Strategy IN PotentialDenormalizationStrategies:

ExpectedPerformanceGain = EstimateReadPerformanceImprovement(Strate

[Link] Page 152 of 159

 EstimatedStorageIncrease = EstimateStorageIncrease(Strategy)
EstimatedWriteComplexity = EstimateWriteComplexity(Strategy, Schema
RiskOfAnomaly = AssessAnomalyRisk(Strategy)

IF ExpectedPerformanceGain > THRESHOLD_PERFORMANCE_GAIN AND \

EstimatedWriteComplexity < THRESHOLD_WRITE_COMPLEXITY AND \
RiskOfAnomaly < THRESHOLD_RISK THEN
PRINT "Recommend Denormalization Strategy: " + [Link]
PRINT " Benefits: " + ExpectedPerformanceGain + " faster read
PRINT " Costs: " + EstimatedStorageIncrease + " storage, " +
// Further steps would involve implementing and managing consis
ELSE
PRINT "Strategy " + [Link] + " not recommended du
END IF
END FOR
ELSE
PRINT "Maintain normalized schema; no critical read bottlenecks identified.
END IF
RETURN "Optimized Hybrid Schema or Normalized Schema"
ELSE // Hybrid System
DecideDenormalization("OLTP", PerformanceData, SchemaDefinition) // Treat as OL
END IF
END FUNCTION

Code (C++/Java/Python) This concept is not directly implemented via code in C++/Java/Python as it's a database
design decision, not an executable algorithm. Application code interacts with the chosen database schema (normalized
or denormalized) via SQL queries. The logic described in pseudocode would typically be part of a database architect's or
developer's thought process during system design and optimization.

6. Complexity Analysis
For "Normalization vs. Denormalization: Trade-offs," complexity analysis applies more to the implications of each approach
on database operations rather than the complexity of an algorithm.

Time complexity (Best, Worst, Average)

Normalization:
Read Operations (with joins):
Best/Average/Worst: Typically O(N*logM) or O(N+M) depending on join algorithm and indexing, where N and
M are the sizes of the joined tables. Can be higher with many complex joins. Generally, reads are slower than
denormalized counterparts.

Write Operations (Insert/Update/Delete):

Best/Average/Worst: O(logN) for single-row operations on indexed tables. Generally faster and simpler than
denormalized counterparts as less data needs to be touched, and no redundant copies to manage.

Denormalization:
Read Operations (without joins):
Best/Average/Worst: O(logN) for indexed lookups, or O(N) for full table scans. Significantly faster than
normalized reads requiring joins, as data is pre-combined.

Write Operations (Insert/Update/Delete):

Best/Average/Worst: Can be O(logN) (single table), but if redundant data needs updating across multiple
locations (e.g., via triggers or application logic), it can be much higher (e.g., O(k * logN) where k is the number
of redundant copies/updates), potentially leading to deadlocks or increased latency. Complexities arise from
ensuring consistency.

[Link] Page 153 of 159

 Space complexity

Normalization:
Best/Average/Worst: Generally lower space complexity. Data is stored once, minimizing redundancy. Total space is
sum of unique data elements.

Denormalization:
Best/Average/Worst: Higher space complexity. Redundant data is stored multiple times, increasing the total
storage footprint. The increase depends on the degree of denormalization and the size of the duplicated data.

Comparison with alternatives The "alternatives" are essentially normalization and denormalization themselves,
representing two ends of a spectrum with a hybrid approach in between.

When to favor Normalization:

Data Integrity is Paramount: Systems where consistency and accuracy of data cannot be compromised (e.g.,
banking, scientific data).

Write-Heavy Workloads: Systems with frequent inserts, updates, and deletes benefit from less redundant data
to manage during writes.

Evolving Requirements: Normalized schemas are more flexible and easier to adapt to changing business rules
or new data requirements.

Storage Constraints: When disk space is a significant concern.

When to favor Denormalization:

Read-Heavy Workloads & Performance Criticality: Systems where extremely fast read access is essential (e.g.,
reporting, analytics, public-facing dashboards).

Complex Joins are Bottlenecks: When normalized queries involve many complex joins that severely impact
performance.

Stable Data: Data that changes infrequently or where the cost of inconsistency is low (e.g., historical fact tables in
a data warehouse).

Reporting/OLAP Systems: Star schemas and snowflake schemas are inherently denormalized structures
designed for OLAP.

Hybrid Approach: Most real-world complex systems utilize a hybrid approach. The core transactional database
remains largely normalized for integrity, while separate reporting databases, materialized views, or specific critical
tables are denormalized to achieve performance targets for read-intensive operations. This offers the best of both
worlds by partitioning the concerns.

7. Examples
Let's illustrate with an Orders and Customers scenario.

Small: Basic Customer Order Query

Normalized Schema:

Customers table: (CustomerID PK, CustomerName, Email, Address)

Orders table: (OrderID PK, CustomerID FK, OrderDate, TotalAmount)

OrderItems table: (OrderItemID PK, OrderID FK, ProductID FK, Quantity, UnitPrice)

Problem: Retrieve the CustomerName for a specific Order . SELECT [Link], [Link],
[Link] FROM Customers C JOIN Orders O ON [Link] = [Link] WHERE
[Link] = 101;

[Link] Page 154 of 159

 Trade-off: Requires a JOIN operation. This is efficient for most OLTP systems, ensuring if CustomerName
changes, it's updated once.

Denormalized Approach:

Modify Orders table: (OrderID PK, CustomerID FK, CustomerName, OrderDate,

TotalAmount)

Customers table: (CustomerID PK, CustomerName, Email, Address) (still exists for customer
details)

Denormalized Query: SELECT [Link], [Link], [Link] FROM Orders O WHERE

[Link] = 101;

Trade-off: No JOIN needed, faster read. However, if CustomerName in Customers changes,

[Link] also needs updating, or it risks showing an outdated name (which might be desirable
for historical orders).

Medium: Product Category Denormalization in E-commerce

Normalized Schema:

Products table: (ProductID PK, ProductName, Description, Price, CategoryID FK)

Categories table: (CategoryID PK, CategoryName, CategoryDescription)

Problem: Display a list of products with their category names on a product listing page. SELECT [Link],
[Link], [Link], [Link] FROM Products P JOIN Categories C ON
[Link] = [Link] WHERE [Link] = 5;

Trade-off: Clean, ensures CategoryName is consistent. But every product listing query involves a join to
Categories .

Denormalized Approach:

Modify Products table: (ProductID PK, ProductName, Description, Price, CategoryID FK,
CategoryName)

Categories table: (CategoryID PK, CategoryName, CategoryDescription) (still exists as master

data)

Denormalized Query: SELECT ProductID, ProductName, Price, CategoryName FROM Products

WHERE CategoryID = 5;

Trade-off: Much faster for displaying product lists. If a CategoryName changes, a trigger or batch job must
update all affected rows in [Link] . This introduces a potential for inconsistency and write
overhead but greatly improves read performance for a critical user-facing feature.

Complex: Data Warehousing - Sales Reporting

Scenario: A large retail company needs to analyze sales trends by customer demographics, product categories, and
time periods. The OLTP system is highly normalized.

Normalized OLTP (Simplified):

FactSales (transaction data): (SaleID PK, CustomerID FK, ProductID FK, TimeID FK,
StoreID FK, Quantity, SaleAmount)

DimCustomer (customer details): (CustomerID PK, CustomerName, Age, Gender, City, State,
Country)

[Link] Page 155 of 159

 DimProduct (product details): (ProductID PK, ProductName, CategoryID FK)

DimCategory (product categories): (CategoryID PK, CategoryName)

DimTime (date details): (TimeID PK, Day, Month, Year, Quarter)

DimStore (store details): (StoreID PK, StoreName, Region)

Problem: Generate a report showing "Total Sales by Customer Age Group, Product Category, and Year." This would
require many joins (e.g., FactSales with DimCustomer , DimProduct , DimCategory , DimTime ).

Denormalized OLAP (Star Schema Approach):

FactSales (fact table): (SaleID PK, CustomerID FK, ProductID FK, TimeID FK, StoreID FK,
Quantity, SaleAmount) (same as OLTP)

DimCustomer (dimension table): (CustomerID PK, CustomerName, Age, AgeGroup, Gender,

City, State, Country) (denormalized AgeGroup added)

DimProduct (dimension table): (ProductID PK, ProductName, CategoryID FK, CategoryName)

(denormalized CategoryName from DimCategory )

DimTime (dimension table): (TimeID PK, Day, Month, Year, Quarter)

DimStore (dimension table): (StoreID PK, StoreName, Region)

Denormalized Query: SELECT [Link], [Link], [Link], SUM([Link]) AS

TotalSales FROM FactSales FS JOIN DimCustomer DC ON [Link] = [Link]
JOIN DimProduct DP ON [Link] = [Link] JOIN DimTime DT ON [Link] =
[Link] GROUP BY [Link], [Link], [Link];

Trade-off: CategoryName is pre-joined into DimProduct , simplifying the query (no join to
DimCategory ). AgeGroup is pre-calculated. This structure (Star Schema) is fundamentally denormalized to
optimize for join performance in analytical queries. Data is typically loaded via ETL (Extract, Transform, Load)
processes from the normalized OLTP system, managing the redundancy and consistency during the ETL phase.
The benefits for OLAP are massive.

8. Common Mistakes & Edge Cases

Where students go wrong

1. Over-Denormalization: Applying denormalization everywhere without careful analysis, leading to massive data
redundancy, increased storage costs, and unmanageable data consistency issues (the "spiderweb of triggers"
problem).

2. Under-Denormalization: Sticking rigidly to high normalization forms even when critical read performance suffers
significantly, failing to address real-world application needs.

3. Ignoring Consistency Costs: Not accounting for the complexity and overhead required to maintain data
consistency when redundant data is introduced. They might forget to implement triggers, batch jobs, or application
logic.

4. Applying OLAP techniques to OLTP systems: Using heavy denormalization (like fact/dimension tables) directly in a
transactional system. While some selective denormalization is okay, full-blown OLAP schemas are disastrous for
transactional integrity and write performance.

5. Not Understanding Data Volatility: Denormalizing data that changes very frequently. This exacerbates the
consistency problem and can negate performance gains with excessive update operations.

6. Premature Optimization: Denormalizing before a performance bottleneck is identified. It's often better to start
normalized, and only denormalize selectively when profiling reveals specific issues.

Special cases

[Link] Page 156 of 159

 1. Data Warehouses (OLAP): This is the quintessential edge case where denormalization (star schema, snowflake
schema) is not just acceptable but the recommended best practice. Performance for analytical queries far outweighs
the risks of redundancy, which are typically managed by controlled ETL processes.

2. Read-Only Databases / Reporting Databases: Often, an organization maintains a highly normalized transactional
database (OLTP) and a separate, denormalized reporting database. Data is periodically replicated or transformed
(ETL) into the reporting database. This completely separates concerns: OLTP gets integrity, reporting gets
performance.

3. Materialized Views: These are database objects that store the pre-computed results of a query. They are a form of
denormalization managed directly by the DBMS, refreshing periodically or on demand. They offer performance
benefits for complex queries without permanently altering the base tables.

4. NoSQL Databases: Many NoSQL databases (e.g., document databases like MongoDB) inherently lean towards
denormalization (embedding related documents) to optimize for fast reads and simplify application development,
sacrificing some consistency guarantees (often eventual consistency).

5. Search Indexes: Search engines and full-text search systems often create highly denormalized and inverted indexes
of data to facilitate extremely fast keyword-based searches.

9. Real-Life Applications
Online Transaction Processing (OLTP) Systems:

Banking Systems: High normalization is crucial for financial transactions to ensure ACID properties (Atomicity,
Consistency, Isolation, Durability) and prevent discrepancies. Every debit and credit must be accurate and traceable.

E-commerce (Order Processing): Core order data (customer info, product details, order items) is typically
normalized to maintain inventory accuracy, track customer orders reliably, and handle concurrent purchases without
data corruption.

Airline Reservation Systems: Reservations, passenger details, flight schedules are highly normalized to ensure
consistency and prevent overbooking or conflicting data.

Online Analytical Processing (OLAP) Systems / Data Warehouses:

Business Intelligence (BI) Dashboards: Companies collect vast amounts of data from OLTP systems and transform
it into denormalized data warehouses. BI tools then query these denormalized structures (star/snowflake schemas) to
generate sales reports, customer behavior analytics, and operational dashboards very quickly.

Marketing Analytics: Analyzing campaign performance, customer segmentation, and market trends relies on
denormalized data models for fast aggregation and complex filtering.

Financial Reporting and Forecasting: Aggregating financial data over long periods and across many dimensions
for quarterly reports, annual forecasts, etc., benefits immensely from denormalized structures.

Specialized Performance Optimizations:

User Profile Pages (e.g., social media): While the core data might be normalized, often specific aggregates (like
"number of friends," "total posts") or frequently accessed related data (last 3 posts) are denormalized into the user's
profile record or a separate cache to speed up profile loading.

Content Management Systems (CMS): For a blog post, details like author_name and category_name might
be denormalized into the posts table for faster display on an article list, even if authors and categories
are normalized elsewhere.

Caching Layers: Technologies like Redis or Memcached often store denormalized, pre-computed results of complex
queries or commonly accessed data to reduce load on the primary database and speed up retrieval.

10. Practice Problems

[Link] Page 157 of 159

 Easy You have a database for a small blog with two tables: Posts (PostID PK, Title, Content, AuthorID
FK, PublishDate) Authors (AuthorID PK, AuthorName, Email)

Write a SQL query to display a list of posts showing PostID , Title , and AuthorName . Suggest how
denormalization could simplify and speed up this query, and what the immediate trade-off would be.

Medium A university database has the following normalized schema: Students (StudentID PK, StudentName,
MajorID FK, EnrollDate) Majors (MajorID PK, MajorName, Department) Courses (CourseID
PK, CourseName, Credits, MajorID FK) Enrollments (EnrollmentID PK, StudentID FK,
CourseID FK, Grade)

The university frequently needs to generate reports listing students and their MajorName . The database administrator
notices that this particular query is often slow.

1. Describe a denormalization strategy to improve the performance of retrieving StudentName and MajorName
together.

2. What are the advantages of this denormalization for the specific report?

3. What are the disadvantages and how would you mitigate the biggest risk?

Hard Design a simplified database schema for a complex inventory management system that also tracks supplier
information and product categories. Your design should consider both OLTP needs (accurate inventory updates, order
processing) and OLAP-like reporting needs (total stock value by category, top suppliers for a product type). Justify your
choices for normalization and denormalization in different parts of the system.

Tables to consider: Products, Categories, Suppliers, Inventory, Orders, OrderItems.

Specific considerations:
How would you handle frequently accessed CategoryName when listing products?

Where would you store SupplierName if products are often displayed with their supplier?

How would you get total inventory value per category quickly without impacting transactional performance?

11. Summary / Key Points

Normalization is the process of structuring a database to reduce redundancy and improve data integrity, typically
involving breaking down tables into smaller, related ones following normal forms (e.g., 3NF).

Denormalization is the intentional introduction of redundancy into a database, often by combining tables or adding
duplicate columns, primarily to enhance read performance and simplify queries.

Trade-offs are central: There is a fundamental balance between data integrity and consistency (favored by
normalization) versus query performance and simplicity (favored by denormalization).

Key Factors Influencing Decision:

System Type: OLTP systems (banking, order entry) prioritize normalization. OLAP systems (data warehouses,
reporting) heavily utilize denormalization.

Read vs. Write Ratio: Read-heavy systems might benefit from denormalization; write-heavy systems usually prefer
normalization.

Data Volatility: Frequently changing data is risky to denormalize due to consistency challenges.

Performance Bottlenecks: Denormalization is often a targeted optimization for specific slow queries involving
many joins.

Normalization Advantages: Reduced redundancy, improved data integrity, easier maintenance, more flexible design.

Normalization Disadvantages: Slower read queries (more joins), more complex query writing.

Denormalization Advantages: Faster read queries (fewer joins), simpler query writing, optimized for reporting.

[Link] Page 158 of 159

 Denormalization Disadvantages: Increased redundancy, higher risk of data anomalies, more complex update/delete
operations to maintain consistency, increased storage.

Hybrid Approach: Many real-world systems use a combination, maintaining normalization for core transactional data
and selectively denormalizing for performance-critical read operations or in separate analytical databases/materialized
views.

Consistency Management: When denormalizing, mechanisms like database triggers, application logic, or ETL processes
are crucial to manage redundant data and ensure consistency.

Common Mistakes: Over-denormalizing, ignoring consistency costs, premature optimization.

Special Cases: Data warehouses, reporting databases, and materialized views are prime examples where
denormalization is extensively and appropriately used.

Highlighted Concepts:
Normalization: Data Integrity, Reduce Redundancy, ACID.

Denormalization: Read Performance, Simpler Queries, OLAP.

Trade-off: Integrity vs. Performance.

Consistency: The primary challenge with denormalization.

[Link] Page 159 of 159