**Втора нормална форма** (2НФ) е нормална форма која се користи во нормализација на базите на податоци. 2НФ беше првично дефинирана со **E.F. Codd** во 1971 година.   

Една табела која е во прв нормален облик (1НФ) мора да ги исполни дополнителните критериуми за да се квалификува за втората нормална форма. Поточно: една табела е во 2НФ ако и само ако, таа е во 1НФ и ниеден не примарен атрибут не е зависен од било кое соодветно подмножество на било кој од кандидатите за клуч на табелата.  

Едноставно кажано, една табела е во 2НФ ако и само ако, тоа е во 1НФ и секој не-примарен атрибут на табелата е целосно зависен од кандидат клучот, или на друг не примарен атрибут.   

Имајте на ум дека кога една табела во 1НФ нема сложени кандидат клучеви (кандидат клучеви кои се состојат од повеќе од еден атрибут), табелата е автоматски во 2НФ.

Пример
------

Разгледајте ја табелата која ги опишува вештините на вработените:

Вештини на вработените| Вработен | Вештина | Местоположба на тековната работа |
| --- | --- | --- |
| Jones | Пишување | 114 Main Street |
| Jones | Стенографија | 114 Main Street |
| Jones | Резбање | 114 Main Street |
| Bravo | Чистење | 73 Industrial Way |
| Ellis | Алхемија | 73 Industrial Way |
| Ellis | Летање | 73 Industrial Way |
| Harrison | Чистење | 73 Industrial Way |

  

Ниту ("вработен") ниту ("вештина") не е кандидат клуч за табелата. Тоа е затоа што еден даден вработен можеби треба да се појави повеќе од еднаш (тој може да има повеќе вештини), и една дадена вештина можеби ќе треба да се појави повеќе од еднаш (може да биде поседувана од повеќе вработени). Само сложениот клуч ("вработен, вештина") се квалификува како кандидат клуч за табелата.   

Останатиот атрибут, "локација на тековната работа", е зависен само од дел на кандидат клучот, односно "вработен". Затоа табелата не е во 2НФ. Забележете го вишокот во начинот на претставување на "локација на тековната работа" : трипати е кажано дека Jones работи на 114 Main Street, и двапати дека Ellis работи на 73 Industrial Way. Овој вишок ја прави табелата ранлива (склона) да ажурира со аномалии: тоа е, на пример, можно да се аружира локацијата на работа на Jones во записите за "**пишување**" и "**стенографија**", а да не се аружира записот за "**резбање**". Добиените податоци би имплицирале контрадикторни одговори на прашањето "Која е сегашната работна локација на Џонс?"   

Алтернативата во 2НФ во овој дизајн би претставувала - истите информации но во две табели: табела "вработен"со кандидат клуч ("вработен") и табела "вештини на вработените" со кандидат клуч ("вработен", "вештини"):  


Вработени| Вработен | Местоположба на тековната работа |
| --- | --- |
| Jones | 114 Main Street |
| Bravo | 73 Industrial Way |
| Ellis | 73 Industrial Way |
| Harrison | 73 Industrial Way |

Вештини на вработените| Вработен | Вештина |
| --- | --- |
| Jones | Пишување |
| Jones | Стенографија |
| Jones | Резбање |
| Bravo | Чистење |
| Ellis | Алхемија |
| Ellis | Летање |
| Harrison | Чистење |

  

  

Ниту една од овие табели не може да страда од аномалии при аружирањето.
  

Но сепак, не се сите табели во 2НФ ослободени од аномалии при аружирањето. Еден пример на табела во 2НФ која страда од аномалии на аружирањето е:
  


Победници на турнеи| Турнеја | Година | Победник | Дата на раѓање на победникот |
| --- | --- | --- | --- |
| Des Moines Masters | 1998 | Chip Masterson | 14 Март 1977 |
| Indiana Invitational | 1998 | Al Fredrickson | 21 Јули 1975 |
| Cleveland Open | 1999 | Bob Albertson | 28 Септември 1968 |
| Des Moines Masters | 1999 | Al Fredrickson | 21 Јули 1975 |
| Indiana Invitational | 1999 | Chip Masterson | 14 Март 1977 |

  

Иако "победник" и "дата на раѓање на победникот" се определени од страна на целосниот клуч ("турнеја/година") а не само на дел од него, одредени комбинации "победник/дата на раѓање на победникот" се прикажани повеќепати на повеќе записи. Ова води кон аномалии при аружирањето: ако ажурирањата не се вршат постојано, одреден победник може да бидат прикажан како да има два различни датуми на раѓање. 
  

Основниот проблем е преодната (транзитивна) зависност на која "дата на раѓање на победникот" е главниот предмет. "Дата на раѓање на победникот" всушност зависи од "победник", кој пак зависи од клучот "турнеја/година". 
  

Овој проблем е упатен на третиот нормален облик (3НФ).

2НФ и кандидат клучеви
----------------------

Табела за која нема парцијални (делумни) функционални зависности од примарниот клуч е најчесто, но не секогаш, во 2НФ. Во прилог на примарниот клуч, табелата може да содржи и други кандидат клучеви; Неопходно е да се утврди дека ниедни не-примарни атрибути немаат делумни зависности на **било кој** од овие кандидат клучеви. 
  

Повеќе кандидат клучеви се појавуваат во следната табела: 
  


Модели на електрична четка за заби| Производител | Модел | Целосно име на моделот | Земја на производство |
| --- | --- | --- | --- |
| Forte | X-Prime | Forte X-Prime | Италија |
| Forte | Ultraclean | Forte Ultraclean | Италија |
| Dent-o-Fresh | EZbrush | Dent-o-Fresh EZBrush | САД |
| Kobayashi | ST-60 | Kobayashi ST-60 | Јапонија |
| Hoch | Toothmaster | Hoch Toothmaster | Германија |
| Hoch | X-Prime | Hoch X-Prime | Германија |

  

Дури и ако дизајнерот го има одредено примарниот клуч ("Целосно име на моделот"), табелата не е во 2НФ. (Производител, модел) е исто така кандидат клуч, и "Земјата на производство" е зависна од соодветното подмножество на "производител". За да се направи дизајнот да одговара на 2НФ, потребно е да се имаат две табели:
  


Производители на електрични четки за заби| Производител | Земја на производство |
| --- | --- |
| Forte | Италија |
| Dent-o-Fresh | САД |
| Kobayashi | Јапонија |
| Hoch | Германија |

  


Модели на електрична четка за заби| Производител | Модел | Целосно име на моделот |
| --- | --- | --- |
| Forte | X-Prime | Forte X-Prime |
| Forte | Ultraclean | Forte Ultraclean |
| Dent-o-Fresh | EZbrush | Dent-o-Fresh EZBrush |
| Kobayashi | ST-60 | Kobayashi ST-60 |
| Hoch | Toothmaster | Hoch Toothmaster |
| Hoch | X-Prime | Hoch X-Prime |

Наводи
------

1. ↑  Codd, E.F. "Further Normalization of the Data Base Relational Model."