Tietokannan normalisointi

Wikipediasta
Siirry navigaatioon Siirry hakuun

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 toisteisuutta (samaa tietoa tallennettaisiin useaan kertaan) ja parantavat tallennetun tiedon eheyden (keskinäisen konsistenssin) säilymistä.

Tietokannan normalisointiin liittyviä perussääntöjä ovat:

  1. Yhteen relaatioon tallennetaan vain siihen liittyvää dataa.
  2. Tieto ei ole useassa paikassa ja päivitys kohdistuu vain yhteen paikkaan per kohde.

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 ei ole toisteista tietoa – tekeminen on usein epämielekästä johtuen arkielämän käytännöistä.

Tiedon hajauttaminen lisää loogisuutta, mutta vaikeuttaa muun muassa tietokantakyselyiden rakentamista.

Lyhyt yhteenveto normaalimuodoista

[muokkaa | muokkaa wikitekstiä]

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.

Ensimmäinen normaalimuoto

[muokkaa | muokkaa wikitekstiä]

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 pääsääntöisesti ole). Normalisointi tehdään siirtämällä moniarvoiset attribuutit omiin erillisiin tauluihinsa.

Esimerkki taulusta joka kuvastaa henkilöiden omistamia autoja (rekisteritunnukset)

Henkilo_id Omistamat_autot
1 AAA-123, BBB-888
2 AAA-999, ABC-333

Tämä tietokantataulu tulisi pilkkoa kahteen tauluun; toiseen jossa henkilöiden tiedot, ja toiseen heidän omistamat autonsa, jokainen omalle rivilleen.

Toinen normaalimuoto

[muokkaa | muokkaa wikitekstiä]

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

[muokkaa | muokkaa wikitekstiä]

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

[muokkaa | muokkaa wikitekstiä]

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).

Boyce–Coddin normaalimuotoa nimitetään useinkenen mukaan? kolmanneksi normaalimuodoksi, sillä se on tiukempi kuin pelkkä 3NF. Se on myös relaatioiden viimeinen muoto, johon useimmiten pyritään - muiden ollessa harvinaisempia.

Klassinen esimerkki kolmannesta normaalimuodosta on osoitetiedot, jotka koostuvat Katuosoitteesta (O), Kaupungista (K) ja postinumerosta (P). Kolmannessa normaalimuodossa oleva relaatio/taulu olisi:

R1(Osoite, Kaupunki, Postinumero)

Koska osoitteen ja kaupungin yhdistelmästä saadaan selville postinumero (KO→P), sekä vastaavasti postinumerosta ja osoitteesta selville kaupunki (OP→K) ei tämä relaatio ole täydellisesti Boyce-Coddin normaalimuodossa. BCNF:ssä relaatio olisi hajotettu relaatioihin R1 ja R2 seuraavasti:

R1(Postinumero, Kaupunki) sekä R2(Kaupunki, Osoite)

Neljäs normaalimuoto

[muokkaa | muokkaa wikitekstiä]

Neljäs normaalimuoto (4NF) kieltää ei-triviaalit riippuvuudet attribuuttijoukoilta muihin kuin ehdokasavainten superjoukkoon. Yleinen esimerkki neljännestä normaalimuodosta on tilanne, jossa attribuutti A määrää B:n ja C:n arvot, niin että B ja C eivät ole toisistaan riippuvaisia (Moniarvoinen riippuvuus, engl. multivalued dependency).

A->>B ja A->>C

Siispä esimerkiksi jos oppilaitoksen kurssi määrittää tietyn joukon opettajia ja joukon opetustiloja, syntyy moniarvoinen riippuvuus. Tilanne voidaan kirjoittaa esimerkiksi näin:

Kurssikoodi->> Opettaja | Luokkatila

Neljännen normaalimuodon säännön mukaan, tämä tilanne on syytä purkaa pienempiin tauluihin tai lisäämään yksilöiviä tietoja. Kaikkien mahdollisten kurssikokoonpanojen esittäminen yhdessä taulussa ei ole mielekästä.

Mahdolliset kurssikokoonpanot
Kurssikoodi Opettaja Luokkatila
Matematiikka1 Pekka A100
Matematiikka2 Pekka B200
Biologia1 Sirkka A100
Biologia1 Sirkka A301

Ylempi taulu purettuna:

Kurssikoodi Opettaja
Matematiikka1 Pekka
Matematiikka2 Pekka
Biologia1 Sirkka

ja

Kurssikoodi Luokkatila
Matematiikka1 A100
Matematiikka2 B200
Biologia1 A100
Biologia1 A301

Viides normaalimuoto

[muokkaa | muokkaa wikitekstiä]

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

Arvoalue–avain-normaalimuoto

[muokkaa | muokkaa wikitekstiä]

Arvoalue–avain-normaalimuoto (Domain-key normal form, DK/NF) vaatii, että kaikki rajoitteet johdetaan arvoalue- ja avainrajoitteista.

Funktionaalinen riippuvuus

[muokkaa | muokkaa wikitekstiä]

Jos attribuutti Y on funktionaalisesti riippuvainen X:stä, merkitään X→Y. Tällöin Y:n arvosta voidaan yksikäsitteisesti päätellä X:n arvo.

Transitiivinen riippuvuus

[muokkaa | muokkaa wikitekstiä]

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). [1]

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.

  1. Tietokantojen perusteet, suunnitteluteoria www.cs.helsinki.fi. Viitattu 16.2.2017.