SQL Server 2012 : Normal Forms (part 2) - Second Normal Form

Second Normal Form (2NF)

The second normal form ensures that each attribute describes the entity. It's a dependency issue. Does the attribute depend on, or describe, the item identified by the primary key?

If the entity's primary key is a single value, this isn't too difficult. Composite primary keys can sometimes get into trouble with the second normal form if the attributes aren't dependent on every attribute in the primary key. If an attribute depends on one of the primary key attributes but not the other that is a partial dependency, which violates the second normal form.

For example, assume a database contains the table RegionalOfficeStore, whose primary key was a composite key including RegionalOfficeID and StoreID. Adding the regional phone number to the data model would violate the second normal form, as shown in Table 3. Because the primary key (PK) is a composite of both RegionalOffice and Store, and that the phone number is a permanent phone number for the regional office, a phone number isn't assigned for each store.

Table 3 Violating the Second Normal Form

The problem with this design is that the phone number is an attribute of the regional office but not the store, so the PhoneNumber attribute is only partially dependent on the entity's primary key.

An obvious practical problem with this design is that updating the phone number requires either updating multiple tuples or risking having two phone numbers for the same phone.

The solution is to remove the partially dependent attribute from the entity with the composite keys, and create an entity with a unique primary key for the store as shown in Table 4. This new entity is then an appropriate location for the dependent attribute.

Table 4 Conforming to the Second Normal Form

The PhoneNumber attribute is now fully dependent on the entity's primary key. Each phone number is stored in only one location, and no partial dependencies exist.