2NF – Second Normal Form

Second Normal Form (2NF) builds on First Normal Form by eliminating partial dependencies. A table is in 2NF if it is already in 1NF and every non-key attribute depends on the entire primary key, not just part of it. This rule becomes relevant only when a table has a composite primary key, that is, a primary key made up of more than one column.

To understand this clearly, consider the loan approval example after applying 1NF. Suppose we have a table representing repayments with a composite primary key such as (LoanID, RepayDate). This combination uniquely identifies each repayment record. However, if we include attributes like LoanAmount or CustomerName in that same table, those attributes depend only on LoanID, not on the full composite key (LoanID, RepayDate). They are not specific to an individual repayment date. This creates a partial dependency.

A partial dependency occurs when an attribute depends on only part of a composite key rather than the whole key. In relational design, this is undesirable because it introduces redundancy and update anomalies. For example, if LoanAmount is stored alongside each repayment record, the same loan amount would repeat for every repayment row. If the loan amount needed correction, multiple rows would require updates.

Second Normal Form resolves this issue by separating attributes based on their dependency. Attributes that depend only on LoanID should be moved into a Loan table. Attributes that depend on both LoanID and RepayDate should remain in the Repayment table. The result is cleaner separation: Loan information lives in one table, and repayment-specific information lives in another.

The rule is straightforward. Begin with a 1NF table. If the primary key is composite, examine each non-key attribute carefully. If any attribute depends on only part of the key, move it into a separate table where it fully depends on that table’s primary key.

It is important to note that 2NF concerns itself only with partial dependencies. It does not yet address transitive dependencies, where a non-key attribute depends on another non-key attribute. That issue is handled in Third Normal Form.

The transition from 1NF to 2NF represents a refinement in logical precision. Instead of merely ensuring atomic values, we now ensure correct dependency structure. Each table begins to represent a single concept more cleanly. Redundancy decreases, integrity improves, and the data model becomes structurally more disciplined.

With 2NF achieved, we are ready to address deeper dependency chains in Third Normal Form.