Second normal form

Second normal form (2NF), in database normalization, is a normal form. A relation is in the second normal form if it fulfills the following two requirements:
 * 1) It is in first normal form.
 * 2) It does not have any non-prime attribute that is functionally dependent on any proper subset of any candidate key of the relation (i.e. it lacks partial dependencies). A non-prime attribute of a relation is an attribute that is not a part of any candidate key of the relation.

Put simply, a relation (or table) is in 2NF if: If any regular (non-prime) attributes are predictable (dependent) on another (non-prime) attribute, that is addressed in third normal form.
 * 1) It is in 1NF and has a single attribute unique identifier (UID)(in which case every non key attribute is dependent on the entire UID), or
 * 2) It is in 1NF and has a multi-attribute unique identifier, and every regular attribute (not part of the UID) is dependent on all attributes in the multi-attribute UID, not just one attribute (or part) of the UID.

History
The second normal form was originally defined by E. F. Codd in 1971.

2NF and candidate keys
A functional dependency on a proper subset of any candidate key (UID) is a violation of 2NF. In addition to the primary key, the relation may contain other candidate keys; it is necessary to establish that no non-prime attributes (regular/non-UID attributes) have part-key dependencies (they're on any of these candidate keys/UIDs). Or put simply, if any regular attributes (non-UID attributes) are predictable from one attribute of the UID (or part of the UID), then it is not in 2NF.

Decomposition of 1NF into 2NF
To make a 1NF relation a 2NF relation, remove the functionally dependent attributes in the partial dependencies of the first normal form relation, and place those partial dependency dependent attributes in a relation where their corresponding determinant attributes are an entire candidate key.

Example
The following relation does not satisfy 2NF because:
 * There is a multi-attribute unique identifier: "Manufacturer" and "Model".
 * {Manufacturer country} is functionally dependent (predictable) on {Manufacturer}.
 * {Manufacturer country} is not part of a candidate key, so it is a non-prime attribute. (It is assumed that it is possible for two manufacturers in the same country to make a toothbrush with the same model name, so {Manufacturer country, Model} is not a candidate key even though in the current table the pair uniquely identify rows.)
 * {Manufacturer} is a proper subset of the {Manufacturer, Model} candidate key.

In other words, since {Manufacturer country} is a non-prime attribute functionally dependent on a proper subset of a candidate key, the relation is in violation of 2NF.

To make the design conform to 2NF, it is necessary to have two relations. To create these relations: As seen below, {Manufacturer country} is removed from the original table:
 * 1) Remove the functionally dependent attributes in the partial dependencies of the first normal form relation. In this example, {Manufacturer country} is the functionally dependent attribute which will be removed.
 * 2) Place those partial dependency-dependent attributes (i.e. {Manufacturer country}) in a relation where their corresponding determinant attributes are a candidate key (i.e. {Manufacturer}).

As seen below, the partial dependency is put into a new relation where the dependency can exist without being a partial dependency: