Tietokannan normalisoinnin kuvauksen perusteet

Tässä artikkelissa selitetään tietokannan normalisoinnin terminologia aloittelijoille. Terminologian perustiedot on hyvä olla hallussa, kun käsitellään relaatiotietokannan suunnittelua.

Normalisoinnin kuvaus

Normalisointi on menettely tietokannan tietojen järjestelemiseksi. Se sisältää taulukoiden luomisen ja suhteiden muodostamisen näiden taulukoiden välille niiden sääntöjen mukaisesti, jotka on suunniteltu sekä tietojen suojaamiseen että tietokannan joustavuuden lisäämiseen poistamalla redundanssit ja epäyhdenmukaiset riippuvuudet.

Tarpeettomasti toistetut tiedot hukkaavat levytilaa ja luovat ylläpitoongelmia. Jos useissa sijainneissa sijaitsevia tietoja on muutettava, tiedot on muutettava täsmälleen samalla tavalla kaikissa sijainnissa. Asiakasosoitteen muutos on helpompi toteuttaa, jos tiedot tallennetaan vain Asiakkaat-taulukkoon eikä mihinkään muualle tietokantaan.

Mikä on ”epäjohdonmukainen riippuvuus”? Vaikka on intuitiivista, että käyttäjä etsii Asiakkaat-taulukosta tietyn asiakkaan osoitetta, ei ehkä ole järkevää etsiä sieltä kyseiseen asiakkaaseen kutsuvan työntekijän palkkaa. Työntekijän palkka liittyy työntekijään – on riippuvainen hänestä – joten se pitäisi siirtää Työntekijät-taulukkoon. Epäjohdonmukaiset riippuvuudet voivat hankaloittaa tietojen käyttöä, koska tietojen etsimiseen ei välttämättä löydy polkua tai polku katkeaa.

Tietokannan normalisointiin on muutamia sääntöjä. Kutakin sääntöä kutsutaan "normaaliksi muodoksi". Jos ensimmäistä sääntöä noudatetaan, tietokannan sanotaan olevan "ensimmäisessä normaalissa muodossa". Jos kolme ensimmäistä sääntöä noudatetaan, tietokannan katsotaan olevan "kolmannessa normaalissa muodossa". Vaikka normalisoinnin muut tasot ovat mahdollisia, kolmatta normaalia lomaketta pidetään useimmissa sovelluksissa korkeimman tarvittavan tasona.

Kuten monissa muodollisissa säännöissä ja määrityksissä, reaalimaailman skenaariot eivät aina salli täydellistä vaatimustenmukaisuutta. Normalisointi vaatii yleisesti ottaen lisätaulukoita, mitä jotkut asiakkaat pitävät työläänä. Jos päätät kiertää yhtä normalisoinnin kolmesta ensimmäisestä säännöstä, varmista, että sovelluksesi ennakoi tästä johtuvat mahdolliset ongelmat, kuten tarpeettomasti toistetut tiedot ja epäjohdonmukaiset riippuvuudet.

Seuraaviin kuvauksiin sisältyy esimerkkejä.

Ensimmäinen normaalimuoto

  • Poista yksittäisissä taulukoissa toistuvat arvojen ryhmät.
  • Luo erillinen taulukko jokaiselle toisiinsa liittyvien tietojen joukolle.
  • Määritä perusavain jokaisen toisiinsa liittyvien tietojen joukon tunnistamiseksi.

Älä käytä useita kenttiä yhdessä taulukossa samankaltaisten tietojen tallentamiseen. Jos esimerkiksi haluat seurata varastokohdetta, joka voidaan toimittaa kahdesta mahdollisesta lähteestä, varastotietueessa voi olla kentät Toimittajakoodi 1 ja Toimittajakoodi 2.

Mitä tapahtuu, kun lisäät kolmannen toimittajan? Kentän lisääminen ei ole vastaus. se edellyttää ohjelma- ja taulukkomuokkauksia, eikä se sovi sujuvasti dynaamiseen määrään toimittajia. Sijoita sen sijaan kaikki toimittajan tiedot erilliseen taulukkoon nimeltä Toimittajat, ja linkitä sitten varastokohteet toimittajiin tuotenumeroavaimen avulla tai toimittajat varastokohteisiin toimittajan koodiavaimen avulla.

Toinen normaalimuoto

  • Luo erilliset taulukot useita tietueita koskevien arvojen joukoille.
  • Yhdistä nämä taulukot toisiinsa viiteavaimen avulla.

Tietueiden ei tule olla riippuvaisia mistään muusta kuin taulukon perusavaimesta (tarvittaessa yhdistelmäavaimesta). Esimerkkinä voidaan käsitellä asiakkaan osoitetta kirjanpitojärjestelmässä. Osoitetta tarvitaan Asiakkaat-taulukossa, mutta myös taulukoissa Tilaukset, Toimitukset, Laskut, Saamiset ja Perintä. Sen sijaan, että tallentaisit asiakkaan osoitteen erillisenä merkintänä kuhunkin taulukkoon, tallenna se yhteen paikkaan, joko Asiakkaat-taulukkoon tai erilliseen Osoitteet-taulukkoon.

Kolmas normaalimuoto

  • Poista kentät, jotka eivät ole riippuvaisia avaimesta.

Tietueen arvot, jotka eivät ole osa tietueen avainta, eivät kuulu taulukkoon. Yleisesti ottaen kentät kannattaa sijoittaa erilliseen taulukkoon aina, kun kenttäryhmän sisältö voi soveltua yhtä useampaan tietueeseen taulukossa.

Esimerkiksi Työntekijän rekrytointi -taulukkoon saattaa sisältyä ehdokkaan yliopiston nimi ja osoite. Tarvitset kuitenkin täydellisen luettelon yliopistoista ryhmäpostituksia varten. Jos yliopistojen tiedot on tallennettu Ehdokkaat-taulukkoon, ei ole mahdollista luetella yliopistoja, joista ei ole tällä hetkellä ehdokkaita. Luo erillinen Yliopistot-taulukko ja yhdistä se Ehdokkaat-taulukkoon yliopiston koodiavaimen avulla.

POIKKEUS: Kolmannen normaalin muodon noudattaminen, vaikka se teoriassa on toivottavaa, ei ole aina käytännöllistä. Jos tietokannassa on Asiakkaat-taulukko ja haluat poistaa kaikki mahdolliset kenttien väliset riippuvuudet, on luotava erilliset taulukot kaupungeille, postinumeroille, myyntiedustajille, asiakasluokille ja kaikille muille kohteille, jotka saatetaan toistaa useissa tietueissa. Teoriassa normalisointia kannattaa tavoitella. Monet pienet taulukot voivat kuitenkin heikentää suorituskykyä tai ylittää avointen tiedostojen ja muistin enimmäisrajat.

Saattaa olla tarkoituksenmukaisempaa käyttää kolmatta normaalimuotoa vain usein vaihtuvia tietoja varten. Jos joitakin toisistaan riippuvaisia kenttiä jää käyttöön, suunnittele sovelluksesi edellyttäen käyttäjää tarkistamaan kaikki liittyvät kentät, kun yhtä niistä muutetaan.

Muut normalisoinnin muodot

Neljäs normaali muoto, jota kutsutaan myös Boyce-Codd normaaliksi lomakkeeksi (BCNF), ja viides normaali muoto on olemassa, mutta sitä ei yleensä oteta huomioon käytännön suunnittelussa. Näiden sääntöjen sivuuttaminen saattaa heikentää tietokannan rakennetta, mutta sen ei pitäisi vaikuttaa toimintoihin.

Esimerkkitaulukon normalisointi

Nämä vaiheet havainnollistavat keksitylle opiskelijoiden taulukolle suoritettavaa normalisointia.

  1. Normalisoimaton taulukko:

    Opiskelijanro Ohjaaja Ohj-huone Kurssi1 Kurssi2 Kurssi3
    1022 Korhonen 412 101-07 143-01 159-02
    4123 Lehtinen 216 101-07 143-01 179-04
  2. Ensimmäinen normaalimuoto: ei toistuvia ryhmiä

    Taulukoilla tulee olla vain kaksi ulottuvuutta. Koska yhdellä opiskelijalla on useita kursseja, nämä kurssit tulee luetella erillisessä taulukossa. Kentät Kurssi1, Kurssi2 ja Kurssi3 yllä mainituissa tietueissa viittaavat suunnitteluongelmaan.

    Laskentataulukoissa käytetään usein kolmatta dimensiota, mutta taulukoiden ei pitäisi. Toinen tapa tarkastella tätä ongelmaa on yksi moneen -suhteessa, älä aseta yhtä puolta ja monia puolia samaan taulukkoon. Luo sen sijaan toinen taulukko ensimmäisessä normaalissa muodossa poistamalla toistuva ryhmä (Class#) seuraavassa esimerkissä esitetyllä tavalla:

    Opiskelijanro Ohjaaja Ohj-huone Kurssinro
    1022 Korhonen 412 101-07
    1022 Korhonen 412 143-01
    1022 Korhonen 412 159-02
    4123 Lehtinen 216 101-07
    4123 Lehtinen 216 143-01
    4123 Lehtinen 216 179-04
  3. Toinen normaalimuoto: Poista tarpeettomasti toistuvat tiedot

    Huomaa, että yllä olevassa taulukossa on kullekin Student#-arvolle useita Class#-arvoja. Class# ei ole toiminnallisesti riippuvainen Student# (perusavain), joten tämä suhde ei ole toisessa normaalissa muodossa.

    Seuraavat taulukot esittävät toista normaalimuotoa:

    Opiskelijat:

    Opiskelijanro Ohjaaja Ohj-huone
    1022 Korhonen 412
    4123 Lehtinen 216

    Rekisteröinti:

    Opiskelijanro Kurssinro
    1022 101-07
    1022 143-01
    1022 159-02
    4123 101-07
    4123 143-01
    4123 179-04
  4. Kolmas normaalimuoto: poista avaimesta riippumattomat tiedot

    Edellisessä esimerkissä Ohj-huone (ohjaajan toimiston numero) on toiminnallisesti riippuvainen Ohjaajan määritteestä. Ratkaisuna kyseinen määrite tulee siirtää Opiskelijat-taulukosta Henkilöstö-taulukkoon seuraavasti:

    Opiskelijat:

    Opiskelijanro Ohjaaja
    1022 Korhonen
    4123 Lehtinen

    Henkilöstö:

    Nimi Huone Osasto
    Korhonen 412 42
    Lehtinen 216 42