Third Normal Form (3NF) in SQL - Time & Space Complexity
When we organize data using Third Normal Form, we split tables to reduce repeated information.
We want to know how this splitting affects the time it takes to get data back.
Analyze the time complexity of this SQL query joining normalized tables.
SELECT Orders.OrderID, Customers.CustomerName, Orders.OrderDate
FROM Orders
JOIN Customers ON Orders.CustomerID = Customers.CustomerID
WHERE Orders.OrderDate > '2023-01-01';
This query fetches orders with customer names after a certain date, joining two tables split by 3NF.
Look at what repeats when the query runs:
- Primary operation: Scanning Orders and matching Customers by CustomerID.
- How many times: Once for each order after the date filter.
As the number of orders grows, the query checks more rows and matches customers.
| Input Size (n) | Approx. Operations |
|---|---|
| 10 | About 10 order checks and 10 customer lookups |
| 100 | About 100 order checks and 100 customer lookups |
| 1000 | About 1000 order checks and 1000 customer lookups |
Pattern observation: The work grows roughly in direct proportion to the number of orders.
Time Complexity: O(n)
This means the time to run the query grows roughly in a straight line with the number of orders.
[X] Wrong: "Splitting tables into 3NF always makes queries slower because of joins."
[OK] Correct: While joins add steps, they avoid repeated data and can keep queries efficient, especially with indexes.
Understanding how normalization affects query time helps you design databases that balance speed and data quality.
"What if we added an index on CustomerID in both tables? How would the time complexity change?"
Practice
Solution
Step 1: Understand 3NF definition
3NF requires that non-key columns depend only on the primary key, not on other non-key columns.Step 2: Evaluate options
Every non-key column depends only on the primary key. correctly states this. The other options are incorrect descriptions of 3NF.Final Answer:
Every non-key column depends only on the primary key. -> Option AQuick Check:
3NF = Non-key columns depend only on primary key [OK]
- Confusing 3NF with limiting number of columns
- Thinking all columns must be unique
- Believing 3NF means one big table
Solution
Step 1: Identify 3NF compliance in table design
3NF requires separating data so non-key columns do not depend on other non-key columns. CustomerName depends on CustomerID, so it should be in a separate table.Step 2: Analyze options
CREATE TABLE Orders (OrderID INT PRIMARY KEY, CustomerID INT); CREATE TABLE Customers (CustomerID INT PRIMARY KEY, CustomerName VARCHAR(50)); splits Orders and Customers, following 3NF. CREATE TABLE Orders (OrderID INT PRIMARY KEY, CustomerID INT, CustomerName VARCHAR(50)); stores CustomerName in Orders, violating 3NF. The other options miss primary keys or mix data improperly.Final Answer:
CREATE TABLE Orders (OrderID INT PRIMARY KEY, CustomerID INT); CREATE TABLE Customers (CustomerID INT PRIMARY KEY, CustomerName VARCHAR(50)); -> Option CQuick Check:
Separate related data into tables = 3NF [OK]
- Putting dependent data in the same table
- Missing primary keys
- Ignoring data duplication issues
EmployeeID | EmployeeName | Department | DepartmentHeadWhat is the main reason this table violates 3NF?
Solution
Step 1: Identify dependencies in the table
DepartmentHead depends on Department, which is a non-key column, not on the primary key EmployeeID.Step 2: Check 3NF rules
3NF requires no non-key column depends on another non-key column. Here, DepartmentHead depends on Department, violating 3NF.Final Answer:
DepartmentHead depends on Department, not EmployeeID. -> Option AQuick Check:
Non-key depends on non-key = violates 3NF [OK]
- Thinking EmployeeName dependency breaks 3NF
- Assuming EmployeeID is not unique
- Confusing primary key with foreign key
StudentID | StudentName | Advisor | AdvisorOfficeThis table violates 3NF. What is the best way to fix it?
Solution
Step 1: Identify the 3NF violation
AdvisorOffice depends on Advisor, a non-key column, causing a transitive dependency violating 3NF.Step 2: Fix by separating dependent data
Creating a separate Advisor table with Advisor and AdvisorOffice removes the transitive dependency.Final Answer:
Create a separate Advisor table with Advisor and AdvisorOffice. -> Option BQuick Check:
Separate dependent data into own table to fix 3NF [OK]
- Just removing columns without restructuring
- Changing primary keys incorrectly
- Adding foreign keys without normalization
InvoiceID | ProductID | ProductName | SupplierID | SupplierNameTo convert this table into Third Normal Form (3NF), which of the following is the best approach?
Solution
Step 1: Identify transitive dependencies
ProductName depends on ProductID, and SupplierName depends on SupplierID, both non-key columns, causing 3NF violation.Step 2: Normalize by splitting tables
Creating separate Product and Supplier tables linked by IDs removes these dependencies and achieves 3NF.Final Answer:
Create separate tables for Products and Suppliers, linking them by IDs. -> Option DQuick Check:
Split related entities into tables to achieve 3NF [OK]
- Trying to keep all data in one table
- Using names as primary keys
- Removing columns without restructuring
Ready to prove it?
Pass the test and this pattern moves unknown
