**Tredje normalform** (**3NF**) er en tilnærming til design av databaseskjema for relasjonsdatabaser som bruker normalisering for å redusere duplisering av data, unngå dataavvik, sikre referanseintegritet og forenkle dataforvaltning. Den ble definert i 1971 av Edgar F. Codd som også fant opp relasjonsmodellen for databasehåndtering.

En databaserelasjon (for eksempel en databasetabell) sies å tilfredsstille kravene til tredje normalform hvis alle attributtene (for eksempel databasekolonner ) er funksjonelt avhengige av kun én nøkkel, bortsett fra tilfellet med funksjonell avhengighet hvis høyre side er en primærattributt (et attributt som er strengt inkludert inni en nøkkel). Codd definerte dette som en relasjon på andre normalform hvor alle ikke-primære attributter bare avhenger av kandidatnøklene og ikke har en transitiv avhengighet av en annen nøkkel.

Et hypotetisk eksempel på manglende oppfyllelse av tredje normalform vil være en sykehusdatabase med en tabell over pasienter som inkluderer en kolonne for telefonnummeret til legen deres. (Telefonnummeret er avhengig av legen snarere enn pasienten, og vil derfor være bedre egnet for å lagres i en tabell over leger.) Det negative resultatet av et slikt design er at en leges nummer vil bli duplisert i databasen hvis de har flere pasienter, og dette vil både øke sjansen for inndatafeil og kostnad og risiko ved å oppdatere dette nummeret dersom det skulle endres. I motsetning ville en datamodell som tilfredsstiller tredje normalform bare lagret legens nummer én gang i en legetabell.

Codd innså senere at 3NF ikke eliminerte alle uønskede dataavvik, og utviklet i 1974 den sterkere Boyce–Codd normalformen for å løse dette.

Definisjoner
------------

  

Codd sin opprinnelige definisjon sier at en tabell er i tredje normalform hvis og bare hvis begge de følgende betingelser gjelder:

* Relasjonen R (tabellen) er i andre normalform (2NF)
* Ingen ikke-primærattributt til R er transitivt avhengig av primærnøkkelen

En *ikke-primær attributt* til R er en attributt som ikke tilhører noen kandidatnøkkel til R. En transitiv avhengighet er en funksjonell avhengighet der *X* → *Z* (*X* bestemmer *Z*) indirekte, i kraft av *X* → *Y* og *Y* → *Z* (hvor det ikke er slik at *Y* → *X* ).

I i 1982 gav Carlo Zaniolo en 3NF-definisjon som tilsvarer Codds, men er uttrykt annerledes. Denne definisjonen sier at en tabell er 3NF hvis og bare hvis for hver av dens funksjonelle avhengigheter *X* → *Y* så gjelder minst én av følgende betingelser:

* *X* inneholder *Y* (altså at *Y* er en delmengde av *X*, hvilket betyr at *X* → *Y* er en triviell funksjonell avhengighet)
* *X* er en supernøkkel
* Hvert element i *Y* \ *X* (mengdedifferansen mellom Y og X) er en *hovedattributt* (altså at hver attributt i *Y* \ *X* er inneholdt i en eller annen kandidatnøkkel).

For å omformulere Zaniolo sin definisjon enklere kan man si at relasjonen er 3NF hvis og bare hvis for hver ikke-triviell funksjonell avhengighet X → Y, så må X være en supernøkkel eller at *Y* \ *X* består av primærattributter. Zaniolo sin definisjon gir en klar følelse av forskjellen mellom 3NF og den mer stringente Boyce–Codd normalformen (BCNF). BCNF eliminerer ganske enkelt det tredje alternativet om at "hvert element i *Y* \ *X* er en hovedattributt".

"Bare nøkkelen"
---------------

En approksimasjon av Codd sin definisjon av 3NF har blitt gitt av Bill Kent, som sier at "hver ikke-nøkkelattributt må gi et fakta om nøkkelen, hele nøkkelen og ingenting annet enn nøkkelen". Denne huskeregelen suppleres av og til med utsaget "så hjelp meg, Codd".

Å kreve at det eksisterer en nøkkel sikrer at tabellen er 1NF; å kreve at ikke-nøkkelattributter er avhengige av hele nøkkelen sikrer 2NF; og å kreve at ikke-nøkkelattributter er avhengige av ingenting annet enn nøkkelen sikrer 3NF. Selv om denne frasen kan være en nyttig huskeregel så nevner den bare én enkelt nøkkel, hvilket betyr at den definerer noen nødvendige men ikke tilstrekkelege betingelser for å oppfylle 2NF og 3NF. Både 2NF og 3NF er like opptatte av alle kandidatnøkler av en tabell, og ikke bare én nøkkel.

Christoper John Date refererer til Kent sin huskeregel for 3NF som en "intuitiv og attraktiv karakteristikk", og bemerker at den med en liten tilpasning kan brukes som definisjon for den litt sterkere Boyce–Codd normalformen: "Hver attributt må representere et fakta om nøkkelen, hele nøkkelen og ingenting annet enn nøkkelen." 3NF-versjonen av definisjonen er svakere enn Date sin BCNF-variasjon, ettersom førstnevnte kun er opptatt av å sikre at *ikke-nøkkel*-attributter er avhengige av nøkler. Primær-attributter (som er nøkler eller deler av nøkler) må ikke være funksjonelt avhengige i det hele tatt; de representerer hver et fakta om nøkkelen i betydningen av å tilby deler av eller hele nøkkelen selv. 

(Denne regelen gjelder bare for funksjonelt avhengige attributter, siden bruk av den på alle attributter implisitt ville forby sammensatte kandidatnøkler, siden hver del av en slik nøkkel vil bryte med kravet om "hele nøkkelen".)

Et eksempel på en tabell som ikke oppfyller kravene i 3NF er:

Turneringsvinnere| Turnering | År | Vinner | Vinnerens fødselsdato |
| --- | --- | --- | --- |
| Indiana Invitational | 1998 | Al Fredrickson | 1975-07-21 |
| Cleveland Open | 1999 | Bob Albertson | 1968-09-28 |
| Des Moines Masters | 1999 | Al Fredrickson | 1975-07-21 |
| Indiana Invitational | 1999 | Chip Masterson | 1977-03-13 |

Fordi hver rad i tabellen må fortelle oss hvem som vant en bestemt turnering i et bestemt år er den sammensatte nøkkelen {Turnering, År} en minimal mengde med attributter som garantert identifiserer en rad unikt. Det vil si at {Turnering, År} er en kandidatnøkkel for tabellen.

Bruddet på 3NF oppstår fordi ikke-primær-attributten {Vinnerens fødselsdato} er transitivt avhengig av kandidatnøkkelen {Turnering, År} gjennom ikke-primær-attributtet {Vinner}. Det faktum at {Vinners fødselsdato} er funksjonelt avhengig av {Vinner} gjør tabellen sårbar for logiske inkonsistenser siden det ikke er noe som stopper samme person fra å vises med ulike fødselsdatoer på ulike rader.

For å uttrykke de samme faktaene uten å bryte 3NF er det nødvendig å dele tabellen i to:

|  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| 

Turneringsvinnere| Turnering | År | Vinner |
| --- | --- | --- |
| Indiana Invitational | 1998 | Al Fredrickson |
| Cleveland Open | 1999 | Bob Albertson |
| Des Moines Masters | 1999 | Al Fredrickson |
| Indiana Invitational | 1999 | Chip Masterson |

 | 

Vinnerens fødselsdato| Vinner | Fødselsdato |
| --- | --- |
| Chip Masterson | 1977-03-13 |
| Al Fredrickson | 1975-07-21 |
| Bob Albertson | 1968-09-28 |

 |

Oppdateringsavvik kan ikke forekomme i disse nye tabellene, fordi i motsetning til tidligere er {Vinner} nå en kandidatnøkkel i den andre tabellen. Dermed tillates det nå kun én verdi for {Fødselsdato} for hver {Vinner}.

Beregning
---------

En relasjon kan alltid dekomponeres i tredje normalform, altså at relasjonen R omskrives til projeksjoner R1, ... Rn hvis skjøt er lik den opprinnelige relasjonen. Videre mister ikke denne dekomponeringen noen funksjonell avhengighet i den forstand at hver funksjonelle avhengighet av R kan utledes fra de funksjonelle avhengighetene som holder på projeksjonene R1, ... Rn. Dessuten kan en slik dekomponering beregnes på polynomisk tid.

For å dekomponere en relasjon fra 2NF til 3NF bryter man tabellen inn i de kanoniske overdekkende funksjonelle avhengighetene, og lager deretter en relasjon for hver kandidatnøkkel av den opprinnelige relasjonen som ikke allerede var en delmengde av en relasjon i dekomponeringen.

Ekvivalens av Codd og Zaniolo sine definisjoner av 3NF
------------------------------------------------------

Definisjonen av 3NF gitt av Carlo Zaniolo i 1982, og gjengitt ovenfor, kan vises å være ekvivalent med Codd-definisjonen på følgende måte: La X → A være en ikke-triviell funksjonell avhengighet (altså at en X ikke inneholder A) og la A være en ikke-primær attributt. La også Y være en kandidatnøkkel til R. Da vil Y → X. Derfor er A ikke transitivt avhengig av Y hvis det er en funksjonell avhengighet X → Y hvis og bare hvis X er en supernøkkel av R.

Normalisering utover 3NF
------------------------

De fleste 3NF-tabeller er fri for anomalier grunnet oppretting, lesing, oppdatering og sletting. Enkelte typer 3NF-tabeller som man sjelden støter på i praksis blir imidlertid påvirket av slike anomalier; Dette er tabeller som enten kommer til under Boyce-Codd normalform (BCNF) eller (dersom de oppfyller BCNF) faller under de høyere normalformene 4NF eller 5NF.

Hensyn til bruk i rapporteringsmiljøer
--------------------------------------

Mens 3NF har vært sett på ideell for maskinbehandling kan den oppdelte naturen til datamodellen være vanskelig å intuitivt forstå for menneskelige brukere. Analytikk med spørring, rapportering og instrumentpanel har tradisjonelt vært tilrettelagt for ved hjelp av andre typer datamodeller som gir forhåndsberegnede analyser som trendlinjer, periode-til-dato-beregninger (måned-til-dato, kvartal-til-dato, år-til-dato), kumulative beregninger, grunnleggende statistikk (gjennomsnitt, standardavvik, glidende gjennomsnitt) og sammenlikninger med tidligere perioder (år siden, måned siden, uke siden). Noen eksempler er dimensjonsmodellering og utover dimensjonsmodellering, utflating av stjernemodeller via Apache Hadoop eller datavitenskap.

Se også
-------

* Attributt-verdi system

Referanser
----------

| * v
* d
* r
Databasenormalisering |
| --- |
| 
* Unormalisert form (UNF)
* Første normalform (1NF)
* Andre normalform (2NF)
* Tredje normalform (3NF)
* Elementær nøkkel normalform (EKNF)
* Boyce–Codd normalform (3.5NF / BCNF)
* Fjerde normalform (4NF)
* Femte normalform (5NF / PJNF)
* Domene–nøkkel normalform (DKNF)
* Sjette normalform (6NF)

 |
| Denormalisering |

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.
2. ↑  Codd, E. F. "Further Normalization of the Data Base Relational Model", p. 34.
3. ↑  Codd, p. 43.
4. ↑  Codd, p. 45–46.
5. ↑  Zaniolo, Carlo. "A New Normal Form for the Design of Relational Database Schemata". *ACM Transactions on Database Systems* 7(3), September 1982.
6. ↑  Abraham Silberschatz, Henry F. Korth, S. Sudarshan, *Database System Concepts* (5th edition), p. 276–277.
7. ↑  Kent, William. "A Simple Guide to Five Normal Forms in Relational Database Theory", *Communications of the ACM* 26 (2), Feb. 1983, pp. 120–125.
8. ↑  The author of a 1989 book on database management credits one of his students with coming up with the "so help me Codd" addendum. Diehr, George. *Database Management* (Scott, Foresman, 1989), p. 331.
9. ↑  Date, C. J. *An Introduction to Database Systems* (7th ed.) (Addison Wesley, 2000), p. 379.
10. ↑  Serge Abiteboul, Richard B. Hull, Victor Vianu: Foundations of Databases. Addison-Wesley, 1995.  ISBN 0201537710. Theorem 11.2.14.
11. ↑  Hammo, Bassam. «Decomposition, 3NF, BCNF» (PDF). Arkivert (PDF) fra originalen 15. mars 2023.
12. ↑  «Comparisons between Data Warehouse modelling techniques – Roelant Vos». *Roelant Vos*. 12 February 2013. Besøkt 5 March 2018.  Sjekk datoverdier i `|besøksdato=, |dato=` (hjelp)
13. ↑  «Hadoop Data Modeling Lessons | EMC». Besøkt 5 March 2018.  Sjekk datoverdier i `|besøksdato=` (hjelp)