Eheys tietokannassa (2-A)

Seuraavassa on lueteltu useita mekanismeja, joilla voidaan edistää tietokannan säilymistä eheänä. Kannattaa huomata, että useimmat näistä on tarkoitettu vahingossa tapahtuvien eheysrikkeiden torjumiseen.

  • Eheyden tarkistus kenttiä syötettäessä: joko
    • kenttäkohtaisesti asetetun ehdon perusteella, esim. arvon oltava numeerinen joltain väliltä, päivämäärä, tai sen on täytettävä jokin sanastollinen ehto; tai
    • kokonaisuuden perusteella. Yksinkertaisimmillaan avaimeksi määritellyn kentän pitää olla erisuuri eri tietueissa, tai tietynlaisten tehtävänimikkeiden kohdalla palkalla on tietyt rajat. Tällaisten yhtä tilaa koskevien rajoitusten ohella voidaan rajoittaa tilasiirtymiä, eli tietojen muutokset voivat edellyttää joitain alkuehtoja ja/tai joitain muita muutoksia (esim. tilausrajan alitus aiheuttaa tilauksen, joka pitää merkitä tietokantaan). Tällaisissa on yhtäältä kyse siitä, miten tietokannan eheys on määritelty (siis tavallaan tietoturvapoliittinen kysymys), ja toisaalta miten hallintajärjestelmä pystyy ottamaan kaiken huomioon.

  • Kaksivaiheinen päivitys: aikomus ja päätös ('intent & commitment'). Yksinkertaisesti tulkittuna tämä on varsin yleinen eheysmekanismi? .

Tietokannan tapauksessa on usein kyse siitä, että niputetaan monivaiheinen kokonaisuus (transaktio), jossa toimen keskeytyminen tai muiden väliintulo voisi särkeä eheyden. Aikomusvaiheessa, mikäli tietokannan commit-lippu ei ole ylhäällä,
    • tehdään tarvittavat valmistelut: tiedoston avaukset, muuttujien tilanvaraukset, ...
    • kerätään kaikki tarpeellinen tieto ja tehdään laskutoimet, mutta ei vielä muuteta mitään.
    • nostetaan commit-lippu ja siirrytään päätösvaiheeseen. Päätösvaiheessa kirjoitetaan uudet arvot, tehdään lokimerkinnät ja lasketaan lippu. Jos aikomusvaiheen aikana tulee keskeytys, tietokanta on säilynyt eheänä ja vaihe voidaan uusia. Jos päätösvaihe keskeytyy, ongelmia voi tulla, mutta ne voidaan oikaista tekemällä kaikki kirjoitukset uudestaan.

Aikomusvaihe kuvaa tietokannan hallintajärjestelmän toimia eikä esim. matkatoimiston käyttöliittymän ääressä tehtyä pohdintaa: Siinä vaiheessa, kun esim. paikkavaraus varsinaisesti aiotaan tehdä, hallintajärjestelmä voi estää lipun avulla muita edes lukemasta samaa tietoa ja jos tieto mahdollistaa varauksen (eli paikka tosiaan on vielä vapaa), aikomusvaihe pääsee eteenpäin.

  • Muutosloki, eräänlainen "on-line backup", joka mahdollistaa "undo"-toiminnon, eli tehtyjen muutosten peruuttamisen -- enemmän tai vähemmän pitkälle historiaan. Mekanismi on tuttu monista tekstureista, mutta sitä voi soveltaa laajemminkin jolloin peruuttaminen on mahdollista myös täysimittaisen vahingon jälkeen -- vaikka sitten varmuuskopion ja paperilla olevan lokin avulla.

  • Muu redundanssi:
    • Muutoksen kohteena olevan tietokantataulun tai tiedoston alkuperäinen versio voi olla kopioituna levyllä, kunnes suoritetaan talletus tai operaatio on kokonaan valmis, jolloin uusi versio korvaa vanhan. Tätä voi kutsua "varovaisen korvaamisen menetelmäksi".
    • Operoinnin aikana voidaan säännöllisin väliajoin tehdä varmistustalletuksia rinnakkaiseen tiedostoon, joka istunnon päätyttyä joko hävitetään tai jätetään. Tällaista redundanssia voi kutsua varjotiedoksi.
    • Päivityksen kohteena olevia työtiedostoja voi olla useitakin. "Varjon" sijasta niissä (eikä itse kannassa) onkin tuoreimmat versiot, joista viimeisin vain aika ajoin yhdistetään kantaan ("differentiaali-menetelmä", jollainen voi olla muutoslokinkin takana).

  • Kirjoitusoikeuden rajoitukset voidaan joutua erittelemään tarkemmin kuin yleensä tiedostoissa: mahdollisia vakiotoimiahan ovat tietueen lisääminen tai poistaminen, vanhan tiedon muuttaminen tai pelkkä uuden liittäminen jatkoksi. Rakenteen muuttaminen esim. lisäämällä uusia kenttä tai poistamalla vanhoja ei yleensä kuulu tavallisen käyttäjän toimiin, eivätkä myöskään pääsyoikeuksien muutokset.

Tietokantoihin keskittyvillä kursseilla (esim. JY? ) esitellään lisäksi oikeaoppisia relaatiotietokannan rakenneperiaatteita, joilla edistetään mm. eheyden säilymistä. Niiden huomioiminen on hyvän ohjelmoinnin periaatteisiin rinnastettava perusedellytys em. eheysmekanismien hyödyllisyydelle. Yksi näiden ns. normalisointivaiheiden tavoitteita on redundanssin vähentäminen tietokannasta, mutta siinä on siis kyse eri tason asiasta kuin edellä mainitussa redundanssin lisäämisessä. Turvalliseen ohjelmointiin? liittyy myös tietokantaan syötettävän tiedon sanitointi ( vrt. "hyökkäysskenaario"? ).

-- JukkaKoskinen?

SivuTiedotLaajennettu edit

Vaativuus Perus
Valmius Valmisteilla
Tyyppi Ydin
Luokitus Uhkat
Mitä Luottamuksellisuus
Miltä Ihmisetön uhka
Missä Organisaatio
Kuka Tite-ammattilainen
Milloin Ennakolta
Miksi Hyvä tapa
Print version |  PDF  | History: r2 < r1 | 
Topic revision: r2 - 26 Sep 2010 - 11:10:18 - MarkoHelenius
 

TUTWiki

Copyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TUTWiki? Send feedback