DT blogi

Lühike lugu sellest, kuidas võib paari lihtsa nupuvajutusega rikkuda aastate jooksul kogunenud andmed. Ja seda kõike põhjusel, et analüüsis jäeti vahele üks oluline peatükk, misjärel tellija saab asjast ühte ja teostaja teistmoodi aru.

Mis on kaskaadprotseduurid?

Andmebaasides on võimalik defineerida tabelite vahele loodud seostele kaskaadprotseduure. Näiteks kaskaaduuendus ja kaskaadkustutamine. Lihtne näide ka juurde.

Olgu meil kaks tabelit, näiteks arve ja arve_rida. Tabelis arve on arvete kohta põhiinfo. Ärikeeli rääkides on selles tabelis arvete päised. Tabelis arve_rida hoiame arvetele vastavaid arveridu. Tabelis arve_rida on väli nimega arve_id, mis vastab arvele, millele rida kuulub. Olgu arve ja arve_rida vahele defineeritud seos, mille ülemises otsas on arve tabeli arve_id ja alumises otsas tabeli arve_rida arve_id väli. Ja olgu seosele defineeritud kaskaadkustutamine. Kui tabelis arve kustutatakse rida, siis kustuvad tabelis arve_rida kõik need read, millel on sama arve_id, kui arve tabelist kustutatud real. See juhtub automaatselt ilma, et programmi kood peaks mingeid täiendavaid liigutusi tegema.

Andmebaaside korral, kus kaskaadprotseduurid puuduvad, mängitakse sarnane funktsionaalsus järgi süsteemi koodi tasemel, kui selleks peaks vajadus olema.

Kuidas tekib kulutuli?

Kõige hirmsamad andmemudelid, mida ma näinud olen, sisaldavad pea kõikide seoste otsas kaskaadkustutamist. Kasutajalt küsitakse enne kustutamist lihtsal kujul nõusolek ning kustutamise tegeliku tagajärje eest süsteem kasutajat ei hoiata.

Andmebaas

Vaatame järgmist fragmenti andmebaasist.

toote_tyyp -> toode -> toote_hind -> tellimuse_rida <- tellimus

Tabelis toote_tyyp hoiame me toodete tüüpe. Näiteks söök, jook, tööriistad jne. Tabelis toode on info konkreetsete toodete kohta. Iga tootega on seotud üks toote tüüp. Et tellimustes kajastuksid hinnad, mis tellimise hetkel kehtisid, siis on loodud tabel toote_hind. Iga tootega on seotud tema hindade ajalugu. Tabel tellimus sisaldab tellimusi. Iga tellimusega on seotud tellimuseread. Iga tellimuserida on seotud tellimuse esitamisel kehtinud toote hinnaga (hinna kaudu saame kätte ka tellimusereale vastava toote). Seega on tabel tellimuse_rida koht, kus tekib mitu-mitmele seos toodete ja tellimuste vahel.

Nüüd siis seoste juurde. Ülaltoodud viie tabeli vahel on neli seost. Nooltest tuleb aru saada nii. Nool algab tabeli juurest, mille ühele reale vastab noole suunas olevas tabelis mitu rida. Tellimusele vastab mitu tellimuserida, tootele mitu hinda jne. Ja olgu neile seostele defineeritud ka kaskaadkustutamine.

Kasutusliides

Halvim juhtum on see, kui ekraanivormid ei selgita enne kustutamist kasutajale kustutamise tegelikku ulatust. Kuskilt ei loe välja seda, kui kaugele kustutamisega minnakse, kui kasutaja nõusoleku annab.

Kasutaja vajutas Jah

Oletame, et kasutaja vajutas nüüd nuppu Jah ja andis seega nõusoleku kustutamiseks. Edasi juhtub järgnev:

• maha kustutatakse valitud tootetüüp,
• maha kustutatakse kõik valitud tüüpi tooted,
• maha kustutatakse kõigi kustutatud toodetega seotud hinnad,
• maha kustutatakse kõik kustutatud hindadega seotud tellimuseread.

Sellist asja kasutaja kindlasti ei oodanud. Tegelikes süsteemides on toodete tabel üks olulisemaid tabeleid. Selle tabeli külge on näiteks haagitud ka varustajad, arved, tshekid ja palju muud.

Kui suured on kahjud?

Ma toon nüüd näite selle kohta, kui palju ridu niimoodi kaotsi võib minna ja milline võib olla taastamist vajavate andmete hulk.

See, et kustus üks tootetüüp, pole kuigi oluline, sest järgnevad arvud muudavad arvu üks juba tühiselt pisikeseks. Oletame, et kustutati tootetüüp toiduained. Tooteid oli kokku näiteks 5000. Et andmebaasi on kasutatud paar aastat, siis on ka toodete hinnad jõudnud mitu korda muutuda. Kaotsi läks 25000 hinda. Tellimusi oli esitatud 2000, tellimuse keskmine ridade arv olgu 10. Kui toidukaubad moodustasid tellimustest 50%, siis läks tellimuseridu kaotsi 10000 tükki. Kokku saame siis ümmarguselt 40000 kadunud rida, mida kasutaja kustutada ei kavatsenud.

Positiivselt meelestatud inimesena loodan ma, et meie näitliku andmebaasi kasutaja on hoolikas ning tal on olemas ka varukoopia andmebaasist ning peale pisikest tõrget süsteemis on kahjustus likvideeritud. Kui aga varukoopiat poleks, siis läheks andmete taastamisega aega üks hea nädalake.

Kuidas kaskaasprotseduure korrektselt kasutada?

Kaskaadprotseduure kipuvad päris paljud arendajad käsitlema kui tehnilist vahendit, mis mingeid tegevusi andmebaasis hõlbustab. Kes püüab mulle vastu vaielda, lugegu eelmine peatükk aeglaselt ja hoolikamalt veelkord läbi. Kaskaadprotseduuride kasutamise otsus või õigemini põhi, millel see otsus langetada, sünnib analüüsi käigus.

Tootetüübi kustutamisele tuleks läheneda näiteks nii. Kui kustutatakse tootetüüp, siis tõenäoliselt ei soovi kasutaja kustutada kõiki tooteid, mis antud tüübi alla kuuluvad. Kaks varianti: kas kasutaja kustutab enne tooted maja või määrab neile lihtsalt teise grupi.

Kui on vajadus sellise kustutamise järgi nagu ma eelpool kirjeldasin, siis selliste õigustega kustutamine on mõttekas jätte juba administraatori rollis kasutajale, kes süsteemi tehnilist tausta tavakasutajatest paremini tunneb. Tegelikkuses sellist vajadust enamasti ei teki.

Kindlasti on võimalik ka see, et on süsteeme, kus on lubatud ilma tüübita tooted. Näiteks sisestab tooteid üks inimene ning nende klassifitseerimisega tegeleb teine. Et need inimesed võivad töötada erinevatel aegadel, siis tekib mingi ajaline lõik igal uuel tootel, kus see on ilma tüübita. Sellise süsteemi korral võib teha ka sellise reegli, et tootetüübi kustutamisel muutub antud tüüpi tooted tüübita toodeteks.

Kokkuvõtteks

Andmete kustutamine on kindlasti koht, kus süsteemi analüüsimisel tuleb pikem mõttepaus teha ning mõelda põhjalikult läbi reeglid, mille järgi ühest või teisest tabelist kustutamine aset leiab. Liiga pealiskaudse lähenemise korral võib juhtuda see, millest juttu eespool. Kuid võib juhtuda ka nii, et andmebaasi jäävad orbkirjed. See tähendab näiteks tootehindu, millele vastav toode on toodete tabelist kustutatud. Ja kõige lõpetuseks - osalege ka ise oma süsteemide analüüsis täies mahus. Sel juhul saate parima, mis teie valitud teostaja teile pakkuda suudab.

Kirjutas Gunnar, 23.10.2007 kell 23:00, teemal Andmebaasid. Jälgi selle postituse kommentaare läbi RSS-uudistevoo (feed). Lisa kommentaar või tagasisideviide (trackback) oma veebilehelt või blogist.