- En relation kommer att vara i 3NF om den är i 2NF och inte innehåller något transitivt partiellt beroende.
- 3NF används för att minska datadupliceringen. Det används också för att uppnå dataintegriteten.
- Om det inte finns något transitivt beroende för icke-primära attribut, måste relationen vara i tredje normalform.
En relation är i tredje normalform om den har minst ett av följande villkor för varje icke-trivialt funktionsberoende X → Y.
- X är en supernyckel.
- Y är ett primärt attribut, dvs varje element i Y är en del av någon kandidatnyckel.
Exempel:
arraylistmetoder
EMPLOYEE_DETAIL tabell:
EMP_ID | EMP_NAME | EMP_ZIP | EMP_STATE | EMP_CITY |
---|---|---|---|---|
222 | Harry | 201010 | UPP | Noida |
333 | Stephan | 02228 | USA | Boston |
444 | Och | 60007 | USA | Chicago |
555 | Katharine | 06389 | Storbritannien | Norwich |
666 | John | 462007 | MP | Bhopal |
Supernyckel i tabellen ovan:
{EMP_ID}, {EMP_ID, EMP_NAME}, {EMP_ID, EMP_NAME, EMP_ZIP}....so on
Kandidatnyckel: {EMP_ID}
Icke-primära attribut: I den givna tabellen är alla attribut utom EMP_ID icke-prime.
Här är EMP_STATE & EMP_CITY beroende av EMP_ZIP och EMP_ZIP beroende av EMP_ID. De icke-primära attributen (EMP_STATE, EMP_CITY) är transitivt beroende av supernyckel (EMP_ID). Det bryter mot regeln om tredje normalform.
Det är därför vi måste flytta EMP_CITY och EMP_STATE till den nya tabellen, med EMP_ZIP som en primär nyckel.
preity zinta
ANSTÄLLDA tabell:
EMP_ID | EMP_NAME | EMP_ZIP |
---|---|---|
222 | Harry | 201010 |
333 | Stephan | 02228 |
444 | Och | 60007 |
555 | Katharine | 06389 |
666 | John | 462007 |
EMPLOYEE_ZIP-tabell:
EMP_ZIP | EMP_STATE | EMP_CITY |
---|---|---|
201010 | UPP | Noida |
02228 | USA | Boston |
60007 | USA | Chicago |
06389 | Storbritannien | Norwich |
462007 | MP | Bhopal |