How to Eliminate Transitive Dependencies (Path to 3NF)

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. Even if your table is in Second Normal Form (2NF)—that is, it has no partial dependencies—transitive dependencies can still introduce redundancy and update anomalies. This lesson shows how to identify and remove them to reach Third Normal Form (3NF).

1) Quick refresher: keys, determinants, and non-prime attributes

• Determinant: An attribute (or set) that functionally determines another attribute.
• Candidate key: A minimal set of attributes that uniquely identifies a row.
• Non-prime attribute: Any attribute that is not part of a candidate key.

2) Spotting a transitive dependency

Use the “chain” test: if A → B and B → C with B and C non-prime, then you have a transitive dependency A → C. This typically manifests as repeated descriptive data that belongs to a different subject area.

Example (revisited)

Assume each item belongs to exactly one category:

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

Key dependencies:

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

Because ItemNo determines CategoryID and CategoryID determines CategoryName and CategoryManager, the category facts are stored redundantly across many items. Result: inconsistent edits (update anomaly), inability to add a category before its first item (insert anomaly), and risk of losing a category when its last item is deleted (delete anomaly).

3) The 3NF remedy: decompose by subject

Move each distinct business concept into its own relation where its facts are determined by its key—nothing else. For the example:

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

Link them with a foreign key (Item.CategoryID → Category.CategoryID). Now category facts live in one place, and the item table contains only item-specific attributes.

4) A clean procedure you can follow

1. List determinants: Write down all functional dependencies you can justify from business rules, not guesses.
2. Classify attributes: Identify candidate keys and mark non-prime attributes.
3. Apply the chain test: For each non-prime attribute X, check if it depends on the key only through another non-prime attribute.
4. Decompose: Create a new relation for each determinant that represents a distinct subject (e.g., Category, Department, Fare).
5. Reconnect with FKs: Preserve semantics via foreign keys and add indexes that support typical joins.
6. Validate: Ensure each fact has exactly one home; updates to a fact occur in one row in one table.

5) Verification checklist

• All non-prime attributes depend on a key directly (no indirect paths).
• No attribute in any table is determined by another non-prime attribute.
• Update/insert/delete anomalies are eliminated in everyday scenarios.

6) Beyond the basics: practical modeling tips

• Name determinants clearly: Suffix keys with ID (e.g., CategoryID) to make relationships obvious.
• Use natural and surrogate keys wisely: Keep meaningful attributes (CategoryName) unique and indexed even when using surrogate keys, to prevent silent duplicates.
• Constrain referential integrity: Enforce FOREIGN KEY constraints; consider ON UPDATE/DELETE actions that match your business rules.

Top landing page (reference, do not remove)

For a compact summary of the requirements of First, Second, and Third Normal Forms, see the landing page:

First, Second, and Third Normal Forms

With transitive dependencies removed, your schema reaches 3NF: every non-prime attribute depends on the key, the whole key, and nothing but the key,no indirect paths.