Tietokannan normalisointi

Tietokannan normalisointi on vaiheittainen malli, jota seuraamalla saadaan relaatiotietokannan rakenne parhaiten tukemaan tietojen ehjää tallennusta ja tiedon tehokasta saatavuutta. Vaiheet vähentävät tiedon redundanssia (samaa tietoa tallennettaisiin useaan kertaan) ja parantavat tallennetun tiedon eheyden (keskinäisen konsistenssin) säilymistä.

Kuitenkin monista relaatiotietokannoista puuttuu puhdas erottelu tietokannan loogisen rakenteen ja tiedon fyysisen tallennuksen toteutustavan välillä, jolloin kyselyt täydellisesti normalisoituun tietokantaan voivat olla suoritukseltaan hitaita. Siinä tapauksessa denormalisointia voidaan käyttää tehokkuuden parantamiseen – tällöin saavutetun tehokkuuden hintana on tiedon eheyden hallinan vaikeutuminen.

Lyhyt yhteenveto normaalimuodoista

Relaatiotietokannan taulun sanotaan olevan tietyssä normaalimuodossa, jos se täyttää kyseisen normaalimuodon ehdot. Normalisointi toteutetaan järjestämällä taulu_(tietokanta)rakenne uudestaan siten, että ehto toteutuu. Tämä tapahtuu siirtämällä attribuutteja toiseen jo olemassa olevaan tauluun tai luomalla uusi taulu.

Normaalimuodot on järjestetty niin, että järjestysluvultaan seuraava normaalimuoto esittää aina vahvemman ehdon kuin edellinen. Lisäksi pitää täyttää myös jokaisen järjestysluvultaan pienemmän normaalimuodon ehdot. Relaatiomallin kehittäjän Edgar F. Coddin alkuperäinen julkaisu määritti kolme ensimmäistä, mutta jälkikäteen on määritelty lisää normaalimuotoja.

Yleisesti käytännön toteutuksissa tietokantaa pidetään normalisoituna, jos se täyttää ehdot kolmanteen normaalimuotoon asti.

Ensimmäinen normaalimuoto (1NF) vaatii, että tietokannan jokaisen taulun sarakkeiden eli relaatioiden attribuuttien arvot ovat atomisia (toisin sanoen moniarvoiset attribuutit on poistettava – esimerkiksi numeroarvo on atominen, kun taas lista numeroita ei ole). Normalisointi tehdään siirtämällä moniarvoiset attribuutit omiin erillisiin tauluihinsa.

Toinen normaalimuoto (2NF) kieltää ei-avainattribuuttien ei-triviaalit funktionaaliset riippuvuudet avainehdokkaan osaan.

Jos jokaisen taulun avain koostuu vain yhdestä attribuutista, tietokanta käytännössä täyttää suoraan toisen normaalimuodon. Jos kantaan kuuluu tauluja joiden avainehdokas koostuu monesta attribuutista, on niiden osalta tarkistettava, että mikään attribuutti, joka ei ole avain, ei saa olla osittain funktionaalisesti riippuva mistään avainehdokkaasta. Jos attribuutti on riippuvainen koko avaimesta, ei siis pelkästään osa-avaimesta, se saa sijaita taulussa (2NF) mukaisesti.

Kolmas normaalimuoto (3NF) kieltää attribuuteilta, jotka eivät ole avaimia, ei-triviaalit toiminnalliset riippuvuudet muihin kuin avainehdokkaiden superjoukkoon.

Tämä tarkoittaa sitä, että taulun ei-avainkenttien pitää riippua avainkentistä. Jos taulussa on kentät PartID, Valmistaja ja Valmistajan osoite, niin taulu ei täytä kolmatta normaalimuotoa. Valmistajan osoite ja itse osa eivät millään lailla riipu toisistaan. Valmistajan tiedot (esimerkiksi osoite ja muut) pitää viedä toiseen tauluun.

Boyce-Coddin normaalimuoto (BCNF) on kolmatta normaalimuotoa tiukempi määrittely. Millään attribuutilla ei saa olla riippuvuutta muualle kuin kokonaiseen avainattribuuttiin (pois lukien triviaalit riippuvuudet, kuten A->A).

Neljäs normaalimuoto (4NF) kieltää ei-triviaalit riippuvuudet attribuuttijoukoilta muihin kuin ehdokasavainten superjoukkoon.

Viides normaalimuoto (5NF or PJ/NF) kieltää ei-triviaalit liitosriippuvuudet, jotka eivät seuraa avainrajoitteista.

Arvoalue-avain normaalimuoto (Domain Key Normal Form) vaatii, että kaikki rajoitteet johdetaan arvoalue- ja avainrajoitteista.