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ä.
Tietokannan normalisointiin liittyviä perussääntöjä ovat:
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 hallinnan vaikeutuminen.
Esimerkiksi suomalaisesta henkilötunnuksesta pystyy näkemään henkilön sukupuolen (kuten myös syntymäajan), mutta tästä huolimatta sukupuoli usein tallennetaan omaan kenttäänsä. Täysin normalisoidun tietokannan - jossa tietoa ei useaan kertaan - tekeminen on usein epämielekästä johtuen arkielämän käytännöistä.
Tiedon hajauttaminen lisää loogisuutta, mutta vaikeuttaa mm. tietokantakyselyiden rakentamista.
Relaatiotietokannan taulun sanotaan olevan tietyssä normaalimuodossa, jos se täyttää kyseisen normaalimuodon ehdot. Normalisointi toteutetaan järjestämällä taulurakenne 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 neljänteen normaalimuotoon asti.
Esimerkki taulusta joka kuvastaa henkilöiden omistamia autoja (rekisteritunnukset)
Tämä tietokantataulu tulisi pilkkoa kahteen tauluun; toiseen jossa henkilöiden tiedot, ja toiseen heidän omistamat autonsa, jokainen omalle rivilleen.
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.
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.
Ylempi taulu purettuna:
Jos attribuutti Y on funktionaalisesti riippuvainen X:stä, merkitään X→Y .
Täten X:n arvosta riippuu myös Y:n arvot.
Jos relaatiossa(X,Y,Z): X→Y ja X→Z sekä Y→Z kun Y ei avainehdokas, niin relaatio on transitiivinen.
Riippuvuus saadaan purettua tekemällä relaatiot R(X, Y) ja R2(Y, Z).
Ensimmäiseen normaalimuotoon liittyvä ilmaisu "attribuutit ovat atomisia" on sikäli monitulkintainen, että
sovellusalueen näkökulmasta esimerkiksi lista numeroita voi olla atominen arvo. Esimerkiksi jos kyse on
mittaustuloksista eikä mittauksen yksittäisillä numeroilla ole tietokannassa mitään merkitystä, niin tuloslistan voidaan ajatella olevan atominen eikä siten 1. normaalimuotoa rikkova. Sen sijaan henkilötietokannassa attribuutti, joka koostuu listasta ihmisten etu- ja sukunimiä, on selvästi (monella tavalla) normaalimuotojen vastainen.