Define Transitive Dependencies

A transitive dependency exists when a non-key attribute depends on another non-key attribute, creating an indirect path from the key to that attribute. In notation: if A → B and B → C, then A → C. In relational design, this pattern causes redundancy and anomalies even after a table satisfies Second Normal Form (2NF). Third Normal Form (3NF) removes these transitive dependencies.

Core terms

• Determinant: An attribute (or set) on which another attribute is functionally dependent.
• Non-prime attribute: An attribute that is not part of any candidate key.
• Transitive dependency: A non-prime attribute depending on another non-prime attribute.

Example 1: Item & Category (classic illustration)

Assume each CD belongs to exactly one category:

Item(ItemNo, Title, Price, CategoryID, CategoryName, CategoryManager)

We can express the functional dependencies as:

ItemNo → Title, Price, CategoryID
CategoryID → CategoryName, CategoryManager

Because ItemNo → CategoryID and CategoryID → (CategoryName, CategoryManager), we also have ItemNo → (CategoryName, CategoryManager) via transitivity. Storing category name/manager in Item repeats that data for every item in the same category, inviting:

• Update anomaly: Changing a manager requires updating many rows.
• Insert anomaly: Can’t insert a new category without a first item.
• Delete anomaly: Deleting the last item can erase the only copy of the category data.

3NF decomposition

Item(ItemNo, Title, Price, CategoryID)
Category(CategoryID, CategoryName, CategoryManager)

Now non-prime attributes depend only on their keys, not through other non-prime attributes.

Example 2: Employees & Departments

Suppose we start with a combined table:

Employees(Employee_ID, Department_ID, Department_Name, Department_Head)

Dependencies:

Employee_ID → Department_ID
Department_ID → Department_Name, Department_Head

Again, Employee_ID transitively determines Department_Name and Department_Head through Department_ID.

3NF decomposition

Employees(Employee_ID, Department_ID)
Departments(Department_ID, Department_Name, Department_Head)

This removes transitive paths and centralizes department facts in one place.

Example 3: Passenger & Fare

Consider:

Passenger(PassengerId, Name, FareCode, FarePrice)

If a fare code has exactly one price:

FareCode → FarePrice

then PassengerId → FareCode and FareCode → FarePrice imply a transitive dependency from PassengerId to FarePrice.

3NF decomposition

Passenger(PassengerId, Name, FareCode)
Fare(FareCode, FarePrice)

How transitive dependencies arise after 2NF

2NF removes partial dependencies on a composite key. But even with a single-column key (or after 2NF), a table can still contain attributes that depend on other non-key attributes. That’s why achieving 3NF is the next step in a robust normalization process.

Practical checklist for data modelers

1. List determinants: Identify every attribute/set that determines others.
2. Test for transitivity: For each non-prime attribute X, ask whether X depends on the key only through another non-prime attribute.
3. Decompose by subject: Move each determinant (like CategoryID, Department_ID, FareCode) to its own table where it is the key.
4. Re-link with FKs: Use foreign keys to preserve relationships and enable joins.
5. Validate anomalies: Confirm that updates/inserts/deletes affect exactly one row per fact domain.

Compact reference

Definition:
A transitive dependency exists when a non-prime attribute depends on another non-prime attribute.

Goal (3NF): Every non-prime attribute depends on the key, the whole key, and nothing but the key (i.e., no transitive path).

By isolating determinants and removing transitive paths, you reduce redundancy, prevent inconsistencies, and make queries and maintenance more predictable, whcih are all hallmarks of a well-normalized design.