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 toisteisuutta (samaa tietoa tallennettaisiin useaan kertaan) ja parantavat tallennetun tiedon eheyden (keskinäisen konsistenssin) säilymistä.
Tietokannan normalisointiin liittyviä perussääntöjä ovat:
- Yhteen relaatioon tallennetaan vain siihen liittyvää dataa.
- Tieto ei ole useassa paikassa ja päivitys kohdistuu vain yhteen paikkaan per kohde.
Ongelmia
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
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
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
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
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
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 usein 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
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
Viides normaalimuoto (5NF tai PJ/NF) kieltää ei-triviaalit liitosriippuvuudet, jotka eivät seuraa avainrajoitteista.
Arvoalue–avain-normaalimuoto
Arvoalue–avain-normaalimuoto (Domain-key normal form, DK/NF) vaatii, että kaikki rajoitteet johdetaan arvoalue- ja avainrajoitteista.
Funktionaalinen riippuvuus
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
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]
Huomioita
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.
Katso myös
Lähteet
- Tietokantojen perusteet, suunnitteluteoria www.cs.helsinki.fi. Viitattu 16.2.2017.