Second normal form

Last updated

Second normal form (2NF) is a level of database normalization defined by English computer scientist Edgar F. Codd. A relation (or a table, in SQL) is in 2NF if it is in first normal form (1NF) and contains no partial dependencies. A partial dependency occurs when a non-prime attribute (that is, one not part of any candidate key) is functionally dependent on only a proper subset of the attributes making up a candidate key. To be in 2NF, a relation must have every non-prime attribute depend on the whole set of attributes of every candidate key.

Contents

For instance, a relation with the composite key {Country, District} would violate 2NF if any attribute was added whose values' meanings didn't depend on both the Country and the District to which they applied. A CountryLeader attribute would vary between and provide information specific to each Country but not specific to each District, and would therefore depend on only half of the composite key. This would have several drawbacks, including that any leader would be redundantly duplicated for each District in their Country.

The purpose of normalization to 2NF is to reduce such redundancy and to make a database's structure generally more clear and flexible by organizing it by functional dependencies. 2NF and third normal form (3NF) were both defined in Codd's paper "Further Normalization of the Data Base Relational Model" in 1971, [1] a year after Codd defined 1NF in "A Relational Model of Data for Large Shared Data Banks" in 1970.[ citation needed ] All normal forms make up part of Codd's relational model of database design.

Example

Design which violates 2NF

The following relation in first normal form contains a composite key, {Manufacturer, Model}. The non-prime attribute ManufacturerCountry is functionally dependent on the attribute Manufacturer (as each Manufacturer will be associated with a separate ManufacturerCountry), but not on the attribute Model. Thus, ManufacturerCountry depends only on a proper subset of the key, {Manufacturer}, making it only partially dependent on the key and violating 2NF.

Toothbrush
ManufacturerModelManufacturerCountry
ForteX-PrimeItaly
ForteUltracleanItaly
Dent-o-FreshEZbrushUSA
BrushmasterSuperBrushUSA
KobayashiST-60Japan
HochToothmasterGermany
HochX-PrimeGermany

Design which complies with 2NF

To bring a relation already in 1NF in line with 2NF, any attributes which depend on only part of a composite key must be extracted to separate relations where the attributes they depend on compose the entirety of a candidate key. As seen below, the attribute ManufacturerCountry can be removed from the original Toothbrush relation and put into a new relation where the attribute Manufacturer makes up the full primary key. The new Country attribute thereby depends on the full key rather than only a part of it, and so the previous partial dependency has become a full dependency, putting both relations in 2NF.

Toothbrush
ManufacturerModel
ForteX-Prime
ForteUltraclean
Dent-o-FreshEZbrush
BrushmasterSuperBrush
KobayashiST-60
HochToothmaster
HochX-Prime
Manufacturer
ManufacturerCountry
ForteItaly
Dent-o-FreshUSA
BrushmasterUSA
KobayashiJapan
HochGermany

See also

References

  1. ↑ Codd, E. F. "Further Normalization of the Data Base Relational Model". (Presented at Courant Computer Science Symposia Series 6, "Data Base Systems", New York City, May 24–25, 1971.) IBM Research Report RJ909 (August 31, 1971). Republished in Randall J. Rustin (ed.), Data Base Systems: Courant Computer Science Symposia Series 6. Prentice-Hall, 1972.

Further reading

This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.