Limitations of Second Normal Form

Second Normal Form (2NF) is a major milestone in the normalization process because it addresses a specific class of design defects: partial dependency in tables that use a composite primary key. When a relation is in 2NF, every non-key attribute is fully functionally dependent on the entire primary key (not just part of it).

That sounds like “the table is clean,” but 2NF is not the finish line. You can still have repeated values, insertion/deletion/modification anomalies, and update storms even after achieving 2NF. The reason is simple: 2NF focuses on the relationship between non-key attributes and the key, but it does not prevent dependencies among non-key attributes. Those are handled by 3NF (and beyond).

To make this concrete, consider the following “all-in-one” CD table:

CD (CDNo, Title, Price, CatNo, CatName, DistID)

Notice that CatNo and CatName repeat across multiple rows. This repetition is not just cosmetic—it creates classic anomalies:

1. Insertion anomaly: you cannot store a new category (for example, CatNo=1, CatName=YA-8) unless at least one CD exists in that category.
2. Deletion anomaly: deleting the last CD in a category can accidentally delete the only remaining record of that category’s description.
3. Modification anomaly: if a category name changes (say YA-8 gets renamed), you must update multiple rows, and missed updates create inconsistencies.

Even if you argued this table can be arranged into 2NF, it still contains a design smell: category description facts are mixed into CD facts. The normalization process is telling you that “category” is its own concept, and the table should be decomposed.

From a relational theory perspective, normalization is driven by functional dependencies (FDs). 2NF addresses only one pattern: non-key attribute depends on part of a composite key. But a relation can satisfy that rule and still violate other dependency constraints that cause anomalies.

In other words, 2NF answers: “Does every non-key attribute depend on the whole key?” It does not answer: “Do non-key attributes depend on other non-key attributes?” or “Are we storing multiple independent themes in one relation?”

1. Transitive dependencies are still allowed (2NF does not imply 3NF): If Key → A and A → B, then B is transitively dependent on the key. 2NF permits this, and transitive dependencies are a primary source of update anomalies.
2. Redundancy can still exist even without partial dependency: Repeated attributes (like category name or warehouse phone number) can appear because the table stores descriptive data that belongs to a referenced entity. 2NF does not force that descriptive data into a separate relation—3NF typically will.
3. Anomalies can persist in 2NF relations: 2NF reduces a set of problems, but it does not guarantee the absence of insertion/deletion/modification anomalies. Those anomalies are fundamentally about storing facts in the wrong place (or storing the same fact multiple times).
4. 2NF is silent on many real-world constraints: Functional dependencies capture many business rules, but databases also deal with multivalued attributes, optional relationships, derived values, and non-FD constraints (like “at most one active contract per employee”). Those require additional design and constraint work beyond normal forms.
5. Over-normalization is possible when applied mechanically: Normalization is a correctness tool first, not a performance tool. In practice, designers sometimes decompose aggressively without a clear dependency justification, which increases join complexity and can hurt query ergonomics. The fix isn’t “avoid normalization”—it’s to normalize based on real dependencies, then apply deliberate denormalization only when you can justify it and protect it with constraints.

A common “gotcha” is a table where the key is simple (not composite), so partial dependency isn’t even possible, yet anomalies still occur due to transitive dependency. Assume each new DVD title comes from one distributor, and each distributor has exactly one warehouse phone number:

Item (item_numb, title, distrib_numb, warehouse_phone_number)

Here, item_numb is the key. Because the key is not composite, the table is automatically in 2NF as long as it is in 1NF. But notice the implied dependencies:

item_numb → distrib_numb
distrib_numb → warehouse_phone_number
therefore: item_numb → warehouse_phone_number (transitively)

That transitive dependency causes the same anomalies you saw earlier:

1. Insertion anomaly: you cannot insert a distributor’s warehouse phone number until at least one item exists for that distributor.
2. Deletion anomaly: deleting the only item for a distributor deletes the only stored copy of the distributor’s phone number.
3. Modification anomaly: the warehouse phone number repeats for every item from the same distributor, so an update must touch multiple rows and can easily become inconsistent.

The key point: this relation can be in 2NF and still be poorly designed. That is the practical limitation of 2NF—it doesn’t stop transitive dependencies.

The usual next step is 3NF decomposition, separating distributor data into its own relation and referencing it from Item.

[1]functionally dependent: A one-way relationship between two attributes such that, for any unique value of one attribute, there is only one value of the other attribute.

[2]third normal form (3NF): A table is in third normal form if it is (1) in second normal form and (2) there is no transitive functional dependency of a non-key attribute on the primary key.