Normaalimuodot

Aiemmassa luvussa todettiin, että normalisoidun relaation rakenne vähentää turhaa toisteisuutta sekä auttaa välttämään ristiriitaisuuksien syntymistä datassa. Normalisointi ei kuitenkaan ole kaksiarvoinen käsite: relaatio ei ole vain joko normalisoimaton tai normalisoitu. Mahdollisia poikkeamia ja toisteisuuksia on erilaisia, ja joskus eri tapauksissa voidaan hyväksyä, että jokin relaation rakenne on enemmän "optimoitu" kuin toinen.

Relaatioiden normalisointi määritellään ja suoritetaan tasoittain. Normaalimuoto on joukko relaation rakenteeseen liittyviä vaatimuksia, joita relaatio voi täyttää. Vaatimukset esitellään yleensä funktionaalisten riippuvuuksien kautta. Relaatio, joka täyttää tietyn normaalimuodon vaatimukset, saa normaalimuodon mukaisia takeita poikkeamien sietokyvystä tai olemassaolosta. Normaalimuotoja on useita; tässä luvussa esitellään seuraavat normaalimuodot niiden vahvuusjärjestyksessä:

1. Ensimmäinen normaalimuoto (1NF)
2. Toinen normaalimuoto (2NF)
3. Kolmas normaalimuoto (3NF)
4. Boyce/Codd-normaalimuoto (BCNF)
5. Neljäs normaalimuoto (4NF)

Korkeammat normaalimuodot tarjoavat vahvempia takeita poikkeamien puuttumisesta tai sietokyvystä. Ensimmäinen normaalimuoto on perusmuoto, jonka jokaisen relaatiomallin mukaisen tietokannan tulee täyttää. Seuraavat muodot määritellään aina edeltävien muotojen kautta: relaatio joka täyttää 3NF täyttää myös 2NF, ja relaatio, joka täyttää 2NF täyttää myös 1NF.

Normalisointi on aina relaatiokohtainen prosessi, eikä kaikkien tietokannan relaatioiden ei tarvitse olla samassa normaalimuodossa. Normalisointi myös yleensä suoritetaan tasoittain: ensin varmistetaan 1NF vaatimukset, sitten 2NF, jne. kunnes relaatio on normalisoitu halutulle tasolle. Jos relaatio ei täytä normaalimuodon vaatimuksia, relaatio voi korjata esimerkiksi jakamalla relaatio kahdeksi tai useammaksi relaatioksi. Jaot ja muutokset tulee kuitenkin tehdä niin, että kohdealueen dataa ei katoa.

Seuraavaksi esitellään neljän ensimmäisen normaalimuotojen vaatimuksia sekä ohjeet relaation saattamiseksi niihin. Mainittakoon, että tässä materiaalissa annetut vaatimukset eivät ole formaaleja, vaan ovat eri kirjailijoiden muotoilujen ([34], [13], [21]) perusteella tehtyjä yhteenvetoja.

Ennen jokaista muotoa esitellään esimerkkitaulu ja pohditaan, millaisia poikkeamia taulussa voi syntyä.

Ensimmäinen normaalimuoto

Ensimmäinen normaalimuoto liittyy siis Luvussa 3.1 esiteltyihin relaatiomallin perusominaisuuksiin. Esimerkin mukaisiin ongelmiin voidaan päästä ainakin SQL-spesifikaation mukaisissa tietokannoissa, sillä spesifikaatio esimerkiksi ei vaadi, että taululla olisi perusavainta. Lisäksi monen arvon säilyttäminen yhdessä sarakkeessa johtaa helposti tietokannan käytön ongelmiin.

Ensimmäisen normaalimuoto käytännössä vaatii, että taulu on suunniteltu relaatiomallin sääntöjen mukaisesti.

Jos relaatio ei täytä 1NF:ää, korjausvaiheet ovat:

1. Jaa moniarvoiset attribuutit niin, että jokaiselle arvolle tulee oma rivi.
2. Tarvittaessa lisää attribuutteja niin, että jokainen on selkeää tietotyyppiä.
3. Valitse sopiva perusavain.

Toinen normaalimuoto

Toisen normaalimuotoon tarvitaankin jo funktionaalisia riippuvuuksia. Tarkemmin, 2NF liittyy siihen, miten relaatiossa olevien funktionaalisten riippuvuuksien määräävä joukko ja relaation perusavain liittyvät toisiinsa.

Huomaa, että 2NF:ssä tulee tarkastaa vain ne funktionaaliset riippuvuudet, joiden määräävässä joukossa on mukana kaikki perusavaimeen kuuluvat attribuutit. Sellaiset riippuvuudet, jonka määräävässä joukossa on perusavaimeen kuulumattomia attribuutteja, eivät riko 2NF:ää. Seurauksena, jos relaation perusavaimessa on vain yksi attribuutti, relaatio on aina 2NF:ssä.

Toinen tapa ajatella 2NF on: perusavaimen ja perusavaimeen kuulumattomien attribuuttien välisen funktionaalisen riippuvuuden tulee olla epätriviaali (eli ei voi johtaa päättelysäännöistä). Erityisesti perusavainta ei voida jakaa osiin niin, että jotain perusavaimeen ja muiden attribuuttien riippuvuuksia säilyisi.

Jos relaatio ei täytä 2NF, sen saa korjattua tekemälle jokaiselle 2NF:ää rikkovalle funktionaaliselle riippuvuudelle oman relaation, jossa on funktionaaliseen riippuvuuden osapuolina olevat attribuutit. Määräävästä joukosta tulee uuden relaation perusavain.

Kolmas normaalimuoto

Kolmannen normaalimuodon ytimessä ovat ns. transitiiviset funktionaaliset riippuvuudet, eli riippuvuudet, jotka riippuvat perusavaimesta epäsuorasti toisen attribuutin kautta. Yllä olevassa esimerkissä käyttäjätyyppi riippuu bonustasosta ({bonustaso} -> {käyttäjätyyppi}), joka puolestaan riippuu perusavaimesta ({käyttäjätunnus} -> {bonustaso}). Eli voidaan sanoa, että käyttäjätyyppi riippuu transitiivisesti käyttäjätunnuksesta; se voidaan merkitä seuraavasti:

{käyttäjätunnus} -> {bonustaso} -> {käyttäjätyyppi}

Toisin sanoen 3NF vaatii, että jokainen perusavaimeen kuulumaton attribuutti riippuu vain perusavaimesta. Ainoat funktionaaliset riippuvuudet, jotka 3NF käytännössä sallii, on avainehdokkaista johtuvat riippuvuudet.

Huomaa erityisesti, että vaikka 2NF:n vaatimukset automaattisesti täyttyvät relaatioissa, joissa on vain yhden attribuutin perusavain, 3NF:n vaatimus ei välttämättä päde.

3NF:n vaatimus voi halutessaan muotoilla myös transitiivisen riippuvuuden määritelmän kautta: relaatio on 3NF:ssä, jos mikään relaatioon perusavaimeen kuulumaton attribuutti ei ole transitiivisesti riippuvainen relaation perusavaimesta.

Jos relaatio ei ole 3NF:ssä, se korjataan käytännössä tekemällä rikkoville funktionaalisille riippuvuuksille omat relaatiot. Taas, tässä tapauksessa voi käyttää omaa harkintaa sen mukaan, kuinka monta relaatiota tekee.

Boyce/Codd-normaalimuoto

Boyce/Codd-normaalimuoto on vain pieni muunnelma 3NF:stä, joka karsii pois lopullisetkin "puutteelliset" riippuvuudet. Esitellään heti alkuun BCNF:n määritelmä vertailuksi:

Huomaa vaatimusero 3NF:n ja BCNF:n välillä:

• 3NF: "Kaikki relaation perusavaimeen kuulumattomat attribuutit riippuvat vain, ainoastaan ja kokonaan perusavaimesta eikä mistään muusta attribuutista."
• BCNF: "Kaikki relaation attribuutit riippuvat vain, ainoastaan ja kokonaan jostain avainehdokkaasta eikä mistään muusta attribuutista."

Huomaa, että BCNF vaatii, että relaatiosta tunnistetaan kaikki avainehdokkaat (eli attribuuttijoukot, jotka yksilöivät relaation kaikki muut attribuutit). Muista, että perusavain on myös avainehdokas. Toisaalta BCNF:n määritelmä on hieman yleisempi ja voi olla helpompi muistaa.

Käytännössä ero BCNF:n ja 3NF:n välillä on hyvin pieni. Hyvin usein 3NF:ssä olevat relaatiot ovat myös BCNF:ssä. Yleensä BCNF menee rikki tapauksissa, jossa relaatiossa on useampi "päällekkäinen" avainehdokas, eli jotkut attribuutit esiintyvät useassa eri avainehdokkaassa.

Katsotaan kuitenkin eräs esimerkki, jossa 3NF pätee, mutta BCNF ei.

Neljäs normaalimuoto

Yleensä BCNF riittää tosi hyvin normalisointiin. Tietyille tauluille, jotka mallintavat moniarvoista dataa, funktionaalisen riippuvuuden määritelmä ei tunnistamaan poikkeamia.

Yllä olevassa esimerkissä sarakkeilla ei ole funktionaalisia riippuvuuksia. Voidaanko silti jotain sanoa siitä, miten sarakkeet liittyvät toisiinsa? Esimerkkitaulusta voidaan todeta, että:

• Palikka-mallilla on vain tasan kaksi keskusmuistivaihtoehtoa: 4 GB tai 8 GB. Keskusmuistivaihtoehdot eivät riipu prosessorimallista tai näytönohjainmallista.
• Samoin Möykky-mallilla on tasan kaksi keskusmuistivaihtoehtoa: 32 GB 64 GB eikä sekään riipu prosessorista tai näytönohjaimesta.
• Vastaavasti malleilla on tasan kaksi vaihtoehtoa prosessorimalli-sarakkeen arvolle, samoin näytönohjainmalli-sarakkeelle eivätkä niiden arvot riipu suoraan toisistaan.

Funktionaalisessa riippuvuudessa attribuutti voi yksilöidä jonkun toisen attribuutin yksittäisiä arvoja. Tässä esimerkissä ei ole niin, mutta ollaan lähellä: attribuutti malli yksilöi attribuutin keskusmuisti arvojoukon. Toisin sanoen, jos tiedetään malli, voidaan tietää, mitä keskusmuistin vaihtoehtoja sillä on. Yleistetään tämä huomio määritelmään:

Yllä olevan esimerkin perusteella voidaan siis todeta, että {malli} ->> {keskusmuisti}, {malli} ->> {prosessorimalli} ja {malli} ->> {näytönohjain}. Toisin sanoen, keskusmuistin (tai prosessorimallin tai näytönohjaimen) mahdolliset arvovaihtoehdot riippuvat vain mallista eikä mistään muusta attribuutista.

Tämän määritelmän pohjalta voidaan esittää neljännen normaalimuodon vaatimukset:

Huomaa, että 4NF koskee vain epätriviaaleja riippuvuuksia. Tämän johdosta 4NF soveltuu käytännössä vain tauluihin, joissa on enemmän kuin kaksi saraketta. Rajoituksen takia myös binääristä N-M -suhdetta mallintavat taulut täyttävät 4NF.

Käytännössä 4NF voi mennä rikki vain, jos tietokannan suunnitteluvaiheessa samalla taululla yritetään mallintaa monta N-M -suhdetta samanaikaisesti. Jos transformoinnin suorittaa oikein ja sääntöjen mukaan, taulussa ei pitäisi esiintyä epätriviaaleja moniarvoisia riippuvuuksia lainkaan.

Loppusanat normalisoinnista

Tätä materiaalia varmasti lukee kolme eri selkeää joukkoa: tulevat ohjelmoijat sekä tietokantojen ylläpitäjät, tulevat tutkijat sekä tietokantojen suunnittelijat ja niitä, jotka mahdollisesti pysyttelevät kaukana tietokannoista tämän materiaalin jälkeen (toivottavasti ei kuitenkaan tämän materiaalin johdosta).

Ohjelmoijat ja ylläpitäjät: Normalisoinnin tarkastelu voi olla hankalaa, ja se vaatii kohdealueen hyvää ymmärtämistä. Normalisointia voisi oikeastaan tiivistää pitkälti kahteen pääsääntöön, jonka perusteella tauluja kannattaa suunnitella:

• Tauluun tulee tallentaa vain kohteeseen välittömästi liittyviä tietoja.
  • Esimerkiksi opiskelijan postitoimipaikka on postinumeroon liittyvä tieto, ei opiskelijan. Jos taulu tallentaa eri kohteiden tietoja, se viestii tarpeesta luoda oma taulu.
• Kunkin tiedon päivitys tulee tapahtua vain yhteen paikkaan.
  • Esimerkiksi jos opiskelijalle vaihtuu postinumero, ja sen takia pitää päivittää sekä postinumero että postitoimipaikka kahdesta eri sarakkeesta, se viestii tarpeesta luoda oma taulu.

Seuraamalla näitä kahta sääntöä pääsee hyvin pitkälle tietokannan suunnittelussa.

Tutkijat ja suunnittelijat: Käsitteellinen mallintaminen on erittäin kannattavaa. Jos ER-kaavio on tehty kohdealueen tarpeita huomioiden ja transformointi suoritettu oikeaoppisesti, tuloksena on usein 3NF tai jopa BCNF toteuttavia relaatioita.

Mainittakoon, että normaalimuotoja on todellisuudessa muitakin. Jotkin niistä ovat vaativuudeltaan käsiteltyjen normaalimuotojen välissä, mutta useimmat ovat käsiteltyjä normaalimuotoja vahvempia. Erityisesti viides normaalimuoto vaatisi formaalia tarkastelua.

Normalisointi on pyritty tässä luvussa esittämään mahdollisimman yksinkertaisesti menemättä liian formaaleihin määritelmiin. Tässä luvussa esitellyt määritelmät eivät ole suinkaan virallisia; tarkasta määritelmästä kiinnostuneet voivat jatkaa aiheeseen tutustumista esimerkiksi Elmasrin ja Navathen kirjassa [15].

Muut lukijat: Toivottavasti tämä ei ollut liian raskas luku 😅. Olennaisin asia, joka pitäisi jäädä mieleen on, että taulujen rakenteella voidaan vaikuttaa tietokannan helppokäyttöisyyteen sekä "idioottivarmuuteen". Toisaalta mitä enemmän tietoja jakaa eri tauluihin, sitä hitaammat tietokantakyselyt ovat. Lisäksi nykyisissä tietokannanhallintajärjestelmissä normalisointi 2NF:n yli voi jopa lisätä levytilan käyttöä [36]. Siispä voi todeta, että oikeastaan normalisointi ei ole aina edes kannattavaa. Nykyään tallennustila on varsin halpaa, ja käyttäjät haluavat yhä nopeampia sovelluksia. Siinä mielessä voi olla perusteltua lisätä vähän toisteisuutta dataan jos se vähentää tietokantakyselyiden määrää ja monimutkaisuutta. Puhutaankin jopa tietokantojen denormalisoinnista: tauluja jätetään normalisoimatta tai muutetaan alempaan normaalimuotoon jotta kyselyt olisivat nopeampia.