In database normalization, what does Third Normal Form require?

In database normalization, what does Third Normal Form require?

• A. 3NF requires 2NF and no transitive dependencies among non-key attributes.
• B. 3NF requires 1NF and fixed schema.
• C. 3NF requires no functional dependencies.
• D. 3NF requires only primary key dependencies.

Answer: (A)

In Third Normal Form, the focus is on removing transitive dependencies after ensuring the table is in Second Normal Form. A transitive dependency occurs when a non-key attribute depends on another non-key attribute, which itself depends on the key. So, being in 3NF means the relation is in 2NF and there are no transitive dependencies among non-key attributes. This ensures that non-key attributes do not rely on each other to convey information about the key, which reduces redundancy. A helpful way to think about it is: for every functional dependency X → Y that you have in the table, either X must be a superkey (so the dependency is directly tied to identifying the row), or Y must be a prime attribute (one that’s part of a candidate key). In practice, if a non-key attribute depends on another non-key attribute, you should decompose to remove that chain of dependency, preserving data consistency and reducing duplication. For example, if a table has StudentID, StudentName, City, and State, and City depends on StudentID while State depends on City, then State transitively depends on StudentID. Splitting into separate tables for students and for city/state information eliminates this transitive link and brings the schema into 3NF. Why the other descriptions are not correct: 3NF is not about eliminating all functional dependencies, nor about a fixed schema or only dependencies from the primary key. It specifically targets transitive dependencies and relies on the idea that dependencies should either come from a superkey or involve prime attributes.

In Third Normal Form, the focus is on removing transitive dependencies after ensuring the table is in Second Normal Form. A transitive dependency occurs when a non-key attribute depends on another non-key attribute, which itself depends on the key. So, being in 3NF means the relation is in 2NF and there are no transitive dependencies among non-key attributes. This ensures that non-key attributes do not rely on each other to convey information about the key, which reduces redundancy.

A helpful way to think about it is: for every functional dependency X → Y that you have in the table, either X must be a superkey (so the dependency is directly tied to identifying the row), or Y must be a prime attribute (one that’s part of a candidate key). In practice, if a non-key attribute depends on another non-key attribute, you should decompose to remove that chain of dependency, preserving data consistency and reducing duplication.

For example, if a table has StudentID, StudentName, City, and State, and City depends on StudentID while State depends on City, then State transitively depends on StudentID. Splitting into separate tables for students and for city/state information eliminates this transitive link and brings the schema into 3NF.

Why the other descriptions are not correct: 3NF is not about eliminating all functional dependencies, nor about a fixed schema or only dependencies from the primary key. It specifically targets transitive dependencies and relies on the idea that dependencies should either come from a superkey or involve prime attributes.