Andmebaasid I - Teema nr. 14

TTÜ: Andmebaaside projekteerimine (2012) © Erki Eessaar 

Teema 14. Andmebaaside projekteerimine 

(füüsilisest disainist töötava andmebaasi 

hooldamiseni) 

Sisukord 

1.Eesmärgid............................................................................................................1 

2.Klassikaline (kaskaadne) infosüsteemi arendusprotsess....................................2 

3.Füüsiline disain (järg)...........................................................................................2 

4. SQL-andmebaasi disain – kokkuvõte...............................................................21 

5. Realiseerimise (ehitamise) etapp.....................................................................26 

6. Rakendamise (üleviimise) etapp.......................................................................26 

7. Hoolduse etapp.................................................................................................26 

8. Mõisted..............................................................................................................27 

9. Kasutatud materjalid.........................................................................................27 

Joonised 

1.Eesmärgid............................................................................................................1 

2.Klassikaline (kaskaadne) infosüsteemi arendusprotsess....................................2 

3.Füüsiline disain (järg)...........................................................................................2 

4. SQL-andmebaasi disain – kokkuvõte...............................................................21 

5. Realiseerimise (ehitamise) etapp.....................................................................26 

6. Rakendamise (üleviimise) etapp.......................................................................26 

7. Hoolduse etapp.................................................................................................26 

8. Mõisted..............................................................................................................27 

9. Kasutatud materjalid.........................................................................................27 

1.Eesmärgid 

1. Anda lihtsustatud ülevaade andmebaasi arendustsükli viimastest etappidest. 

2. Selgitada denormaliseerimist ja sellest tulenevaid eeliseid ja probleeme. 

1


2.Klassikaline (kaskaadne) infosüsteemi 

arendusprotsess 

… hõlmab järjestikku toimuvaid etappe: 

• Strateegiline analüüs 

• Detailanalüüs 

• Disain 

• Realiseerimine (Ehitamine) 

• Rakendamine (Üleviimine) 

• Hooldus 

3.Füüsiline disain (järg) 

Kasutan denormaliseerimisest kirjutades SQLi termineid (baastabel, rida, veerg). 

3.1 Denormaliseerimine 

Loogilise disaini lõpuks peaksid tabelid olema viidud soovitavalt kuni viiendale 

normaalkujule. Selle eesmärk on vähendada andmete liiasust. 

Füüsilise disaini käigus võib (aga ei pea) toimuda valikuline tabelite 

denormaliseerimine. Denormaliseerimine on normaliseerimise pöördprotsess. 

Denormaliseerimine on protsess, mille käigus vähendatakse ühe või mitme 

andmebaasis oleva baastabeli (edaspidi tabeli) normaliseerituse astet. 

Denormaliseerimise tulemusel dubleeritakse veerge või ühendatakse tabeleid, et 

andmete otsimisel oleks vaja viia läbi vähem tabelite ühendamise operatsioone. 

Date (2007) esitab formaalse denormaliseerimise definitsiooni. Olgu R1, R2,..., 

Rn relvarid. Sellisel juhul tähendab nende denormaliseerimine järgmist. 

Relvarid asendatakse nende ühendiga R nii, et 

iga võimaliku R1, R2, ..., Rn vääruse r1, r2, ..., rn korral kehtib olukord, et 

tehes tehes projektsiooni R väärtuse r põhjal üle Ri atribuutide saadakse 

tulemuseks ri. 

Lähtutakse eeldusest, et andmebaasisüsteemilt nõuab ühendamise operatsiooni 

läbi viimine palju vaeva (andmebaasisüsteem peab viima läbi palju I/O 

(sisend/väljund) operatsioone) ja selle kasutamine mõjub andmebaasist andmete 

otsimiseks mõeldud lausete töökiirusele halvasti. 

Juhime tähelepanu, et kõrgel normaalkujul olevate baastabelite põhjal 

madalamatel normaalkujudel olevate vaadete loomine töökiiruse parandamisele 

kaasa ei aita, sest vaate põhjal päringut tehes peab andmebaasisüsteem ikkagi 

täitma vaate aluseks oleva päringu. 

2


Denormaliseerimise eesmärgiks on parandada päringute töökiirust. Samas 

tuuakse denormaliseerimisega tabelitesse sisse andmete liiasus, mille 

kaotamiseks viidi läbi normaliseerimine. 

Hoberman (2002, lk. 342–344) loetleb denormaliseerimisest tulenevaid 

probleeme. 

1. Ilmnevad andmete muutmise anomaaliad, mille pärast normaliseerimine ette 

võeti. 

2. Denormaliseerimine võib suurendada andmete muutmiseks kuluvat aega, 

sest tänu andmete liiasuse kasvule tuleb andmeid muuta mitmes erinevas 

tabelis või mitmes erinevas tabeli reas. Lighstone et al. (2007) märgib, et 

mitmed andmebaasisüsteemid pakuvad funktsionaalsust, mis võimaldab 

tabelites olevate andmete sünkroniseerimist (IBM DB2 Everyplace, Oracle 

Data Hubs, Oracle Streams, SQL Server Compare, SQL Server Everywhere 

Edition). Seda võib andmete kooskõlalisuse tagamiseks ära kasutada. 

3. Denormaliseerimine võib suurendada ka päringule vastuse saamise aega. 

See võib näiteks juhtuda, kui tabeli veergude hulk läheb nii suureks, et üks 

rida ei mahu ära ühte plokki. Sellisel juhul jaotub rida mitme erineva ploki 

vahel ning andmete lugemiseks ja muutmiseks kulub rohkem aega. Samuti 

võib põhjuseks olla, et kuigi read mahuvad ühte plokki ära, tuleb päringule 

vastuse saamiseks andmebaasisüsteemil vaadata läbi rohkem plokke. 

4. Denormaliseerimine suurendab andmemahte, sest andmete liiasus suureneb. 

Näiteks võib denormaliseerimise tulemusel tekkivates tabelites 100 märgiline 

stringi e. sõne ühe rea asemel olla viies reas. 

5. Denormaliseerimine võib põhjustada probleeme andmete kvaliteedis. Näiteks 

kui denormaliseerimise tulemusel tekkinud tabelis dubleeritakse inimese 

perenime mitmes reas, kuid andmete muutmisel tehakse muudatus vaid ühes 

reas, siis see tekitab vastuolu andmetes ja põhjustab andmete kvaliteedi 

vähenemise. 

6. Kunagi ei tuleks denormaliseerida ilma eelneva normaliseerimiseta. Vastasel 

juhul jääb arusaamine andmetest ja nende vahelistest seostest poolikuks. 

7. Denormaliseerimine vähendab süsteemi paindlikust ja laiendamise võimalusi. 

Täiendavad probleemid. 

• Date (2007) märgib, et denormaliseerimine võib muuta mõne päringu 

kirjutamise keerulisemaks. 

• Kui alustada andmebaasi loomist kohe denormaliseeritud andmetabelite 

tekitamisega, siis tähendab see, et ei leita andmete vahelisi seoseid ja 

andmete tegelikku tähendust. Tulemuseks on skeem, mille korrektsust ja 

infovajadustele vastavust on väga raske kontrollida ja mis väga suure 

tõenäosusega sisaldab selles osas puudusi. Date (2009) rõhutab, et 

andmebaasi disaini käigus tuleb kõigepealt viia läbi loogiline disain ja leida 

kõrge tasemeni normaliseeritud tabelid. Seejärel peaks toimuma füüsiline 

disain, kus loogilise disaini tulemuste põhjal projekteeritakse andmebaas 

konkreetse andmebaasisüsteemi võimalustest lähtuvalt. Denormaliseerimine 

toimub füüsilise disaini käigus. 

• Mida kõrgema tasemeni on tabelid normaliseeritud, seda lihtsam on nendes 

tabelites jõustada funktsionaalsetele-, multiväärtuslikele- ja 

3


ühendamissõltuvustele vastavaid kitsendusi. Selliste kitsenduste jõustamiseks 

piisab kõrge astmeni normaliseeritud tabelites võtmete deklareerimisest ja 

nende väärtuste unikaalsuse tagamisest. Denormaliseerimine omakorda 

tähendab, et nende kitsenduste jõustamine muutub keerukamaks ning võib 

SQL-andmebaasisüsteemides nõuda näiteks trigeri protseduuride kasutamist. 

Date (2007) rõhutab, et andmebaasis tuleb kitsendused jõustada ka siis, kui 

põhiliselt toimuvad selles andmebaasis lugemisoperatsioonid. Kitsendused 

määravad ära andmete tähenduse ja seda tähendust on vaja teada nii 

andmebaasi kasutajal (et andmetest aru saada) kui ka andmebaasisüsteemil 

(et optimeerida päringuid). 

• Denormaliseerimise tulemusel muutub andmebaasi kontseptuaalne skeem 

kasutaja jaoks ebaselgemaks. 

Näitena vaadake esimesel normaalkujul (kuid mitte kõrgematel normaalkujudel) 

oleva tabeli struktuuri ja kitsenduste kirjeldust. 

Töötaja_maja_inspekteerimine (maja_nr, kuupäev, kellaaeg, maja_aadress, 

kommentaar, töötaja_nr, eesnimi, auto_nr) 

Primaarvõti (maja_nr, kuupäev) 

Alternatiivvõti (töötaja_nr, kuupäev, kellaaeg) 

Alternatiivvõti (auto_nr, kuupäev, kellaaeg) 

Vaadates selle tabeli struktuuri ning kitsendusi ei ole võimalik lihtsalt aru saada, 

et kehtib reegel, mille kohaselt saab iga töötaja ühel päeval kasutada 

maksimaalselt ühte autot. Küll aga saab selle reegli kehtivusest aru, vaadates 

ühe algse tabeli täiendava normaliseerimise tulemusena leitud tabeli struktuuri 

ning kitsendusi. Nimetatud reegli jõustamiseks piisab võtme (töötaja_nr, 

kuupäev) deklareerimisest tabelis Töötaja_auto. 

Töötaja_auto(töötaja_nr, kuupäev, auto_nr) 

Primaarvõti (töötaja_nr, kuupäev) 

Välisvõti (töötaja_nr) Viitab Töötaja(töötaja_nr) 

• Pole selge, millal tuleb denormaliseerimine lõpetada – kas siis kui kõik/osa 

tabeleid on Boyce/Coddi normaalkujul, teisel normaalkujul ...? 

Lighstone et al. (2007) tõstab esile denormaliseerimise tekitatavaid probleeme, 

kui denormaliseerimist rakendada juba kasutuses olevas andmebaasis. 

• Denormaliseerimise järel tuleb üle kontrollida ja vajadusel muuta kõiki 

päringuid, mida on juba jõutud denormaliseeritud tabelite põhjal kirjutada. 

• Denormaliseerimise korral nõuab aega tabelite/relvaride reorganiseerimine ja 

vajalike andmete ülekandmine uutesse tabelitesse / relvaride väärtuste 

muutmine. 

Denormaliseerimise võimalust võiks kaaluda (see ei tähenda, et tingimata peab 

denormaliseerima) vaid tabelite puhul mida kasutatakse sageli päringutes 

ning milles andmete muutmised toimuvad harva. 

4


Selliste omadustega tabelid on näiteks andmeaida ja andmevaka 

andmebaasides. Seal hoitakse ajaloolisi andmeid mille põhjal tehakse keerukaid 

päringuid. Seetõttu rakendatakse sellist tüüpi andmebaaside tabelite struktuuri 

leidmisel sageli denormaliseerimist. 

Denormaliseerimise käigus tehtud otsused tuleb dokumenteerida. Mida 

täpsemalt tuleks kirja panna? 

• Tehtud muudatused võrreldes loogilise andmemudeliga. 

• Põhjused, miks denormaliseerimist kasutatakse. 

• Kui on võimalik denormaliseerida mitmel erineval viisil, siis tuleb 

dokumenteerida põhjendused, miks valiti mingi kindel viis. 

Denormaliseerimise juures sobib eriti hästi meelde tuletada vanasõna: Üheksa 

korda mõõda, üks kord lõika. Date (2009) märgib, et denormaliseerimine 

tuleks võtta ette kõige viimase abinõuna – siis, kui ükski teine töökiiruse 

parandamiseks ettevõetud tegevus ei ole loodetud tulemust andnud. 

Celko (1999) märgib, et denormaliseerimist võib kaaluda kui: 

denormaliseerimine ei kahjusta süsteemi kui terviku töökiirust 

(operatsiooni A kiirendamiseks läbiviidav denormaliseerimine, võib muuta 

operatsioonide B, C ja D täitmise palju aeglasemaks), 

denormaliseerimine ei kahjusta andmebaasi terviklikkust. 

Denormaliseerimise jaoks annab kasulikku informatsiooni CRUD maatriks: 

milliseid tabeleid kasutab kõige rohkem transaktsioone? 

ja transaktsioonanalüüs: 

 

 

millised on sagedasti käivitatavad päringud? 

kas ja kui sageli muudetakse andmeid tabelites, mille põhjal päringut 

tehakse? 

Näide: Näiteks olgu meil viiendal normaalkujul olevad tabelid: 

Isik (isikukood, perenimi, riigi_kood) 

Primaarvõti (isikukood) 

Välisvõti (riigi_kood) Viitab Riik (riigi_kood) 

Riik (riigi_kood, riigi_nimi) 

Primaarvõti (riigi_kood) 

Kuid kuna isiku andmeid kasutatakse sageli koos riigi nimega, kus ta elab, siis 

luuakse denormaliseerimise tulemusena tabel Isik, mis on teisel normaalkujul ja 

sisaldab ülekanduvat sõltuvust: 

Isik (isikukood, perenimi, tänav, riigi_kood, riigi_nimi) 

Primaarvõti (isikukood) 

Välisvõti (riigi_kood) Viitab Riik (riigi_kood) 

5


Riik (riigi_kood, riigi_nimi) 

Primaarvõti (riigi_kood) 

Funktsionaalsed sõltuvused denormaliseerimise tulemusena leitud tabelis Isik: 

- isikukood → {perenimi, riigi_kood, riigi_nimi} (sõltuvus primaarvõtmest) 

- riigi_kood → riigi_nimi (ülekanduv sõltuvus) 

Tabel Riik säilitatakse, et saaks registreerida andmeid riikide kohta (ka selliste 

kohta, kus ei ole teada ühtegi isikut, kelle andmeid andmebaasis registreerida). 

Tabelit Riik on vaja, et rakenduses oleks võimalik esitada isiku andmete 

registreerijale nimekiri riikidest, millega isikut võib seostada. 

Celko (1999) märgib, et on olemas kaks võimalikku denormaliseerimise 

strateegiat. 

- Asendada kõrge astmeni normaliseeritud tabelid denormaliseeritud 

tabelitega. 

- Lisada olemasolevasse kõrge astmeni normaliseeritud tabeleid sisaldavasse 

andmebaasi uued denormaliseeritud tabelid, mis täidetakse vastavalt 

vajadusele. Sellised tabelid võiksid olla hetktõmmised ehk materialiseeritud 

vaated. 

Denormaliseerimise käigus võib Connolli ja Begg (2001) põhjal teha järgnevaid 

tegevusi. 

• 1:M seosetüübi puhul mitte-võtmeveergude dubleerimine erinevates 

tabelites. Selle eesmärgiks on vähendada tabelite ühendamise vajadust. 

Näide: Koos õpingukavaga soovitakse sageli näha ka üliõpilase nime, kellele see 

õpingukava kuulub. Tüüpiline SQL lause on: 

SELECT Yliopilane.yliopilaskood, Yliopilane.perenimi, 

Opingukava.opingukava_id, Opingukava.loomise_aeg 

FROM Yliopilane, Opingukava 

WHERE Yliopilane.yliopilaskood = Opingukava.yliopilaskood; 

Kui tabelisse Opingukava lisada veerg perenimi, siis saaks SQL lauset 

lihtsustada ja ei peaks tegema päringut mitme tabeli põhjal: 

SELECT yliopilaskood, perenimi, opingukava_id, loomise_aeg 

FROM Opingukava; 

Eksisteerib funktsionaalne sõltuvus: 

yliopilaskood → perenimi. 

6


Kuna tegemist on ülekanduva sõltuvusega, siis see tabel on teisel, aga mitte 

kolmandal normaalkujul. 

Probleemid: 

- Kui põhitabelis (Yliopilane) dubleeritud veerus (perenimi) väärtus muutub, 

siis tuleb seda väärtust muuta ka seotud tabelis (Opingukava). Kui muudatust 

seotud tabelis ei tehta, tekib andmetesse vastuolu. 

- Kui tabelis Opingukava on üliõpilase kohta mitu rida, siis tuleb tagada, et 

üliõpilase perenimi on igas sellises reas ühesugune. 

- Tabelis Opingukava tuleb kas keelata perenime muutmine või siis kirjutada 

programm, mis kannab muudatused üle teistesse tabeli Opingukava 

ridadesse ja tabelisse Yliopilane. 

- Tuleb kirjutada programm kooskõla automaatseks tagamiseks ja muudatuste 

üleviimiseks. Selle programmi võib realiseerida trigerina. Selle programmi 

kirjutamine võtab aega ja programm on võimalik vigade allikas. 

- Veergude dubleerimisest tulenev andmemahu kasv. 

• 1:M seosetüübi puhul välisvõtme veergude dubleerimine erinevates 

tabelites. Selle eesmärgiks on vähendada tabelite ühendamise vajadust 

päringute tegemisel. 

a) 

Yliopilane 

------------------------- 

yliopilaskood (PK) 

perenimi 

Oppimine 

------------------------- 

oppimine_id (PK) 

yliopilaskood (FK) 

algus 

lopp 

Teadmiste_kontroll 

------------------------- 

kontroll_id (PK) 

oppimine (FK) 

toimumise_aeg 

tulemus 

b) 

Yliopilane 

------------------------- 

yliopilaskood (PK) 

perenimi 

Oppimine 

------------------------- 

oppimine_id (PK) 


algus 

lopp 

Teadmiste_kontroll 

------------------------- 

kontroll_id (PK) 

oppimine (FK) 


toimumise_aeg 

tulemus 

Joonis 1Välisvõtme veergude dubleerimine. 

Kui tüüpiline päring otsib üliõpilase ja tema teadmiste kontrolli andmed, siis 

esimesel juhul tuleb üliõpilase teadmiste kontrolli leidmiseks teha päring kolme 

tabeli põhjal: 

7


SELECT Tk.*, Y.perenimi 

FROM Yliopilane Y, Oppimine O, Teadmiste_kontroll Tk 

WHERE (Y.yliopilaskood=O.yliopilaskood) AND (O.oppimise_id=Tk.oppimine); 

Teisel juhul tuleb teha päring kahe tabeli põhjal: 

SELECT Tk.*, Y.perenimi 

FROM Yliopilane Y, Teadmiste_kontroll Tk 

WHERE (Y.yliopilaskood =Tk.yliopilaskood); 

Variant a) korral on Teadmiste_kontroll vähemalt Boyce/Coddi normaalkujul. 

Mille alusel saan seda väita? Iga mittetriviaalse, täieliku funktsionaalse sõltuvuse 

determinant on kandidaatvõti. 

kontroll_id → {oppimine, toimumise_aeg, tulemus} 

{oppimine, toimumise_aeg} → {kontroll_id, tulemus} 

See tabel on ka vähemalt neljandal normaalkujul tulenevalt järgmisest reeglist 

(vt. teema 9): Kui tabel on Boyce/Coddi normaalkujul ja mõni selle kandidaatvõti 

on lihtne, siis on see tabel ka neljandal normaalkujul (aga ei pruugi olla viiendal 

normaalkujul). Antud juhul on selleks võtmeks võti, mis hõlmab veergu 

kontroll_id. 

Variant b) korral ei ole Teadmiste_kontroll Boyce/Coddi normaalkujul. 

Funktsionaalsed sõltuvused on järgnevad. 

kontroll_id → {oppimine, toimumise_aeg, tulemus, yliopilaskood} 

{oppimine, toimumise_aeg} → {kontroll_id, tulemus, yliopilaskood} 

{yliopilaskood, toimumise_aeg} → {kontroll_id, tulemus, oppimine} 

oppimine → yliopilaskood 

Funktsionaalse sõltuvuse (oppimine → yliopilaskood) determinant ei ole 

kandidaatvõti. 

Probleemid: 

• Andmete liiasus. 

• Tuleb tagada, et andmebaasis ei tekiks andmete vastuolu. Teadmiste kontroll 

peab olema läbi Õppimise seotud sama Üliõpilasega, millega Teadmiste 

kontroll on seotud ka otse. 

• Klassifikaatorite tabelite ühendamine põhitabeliga (eelmise näite 

erijuht). 

Taolise tabelis on tavaliselt klassifikaatori kood, nimetus ja võibolla ka pikem 

kirjeldus. 

8


Kava_seisund 

------------------------------ 

kava_seisund_id (PK) 

nimetus 

Opingukava 

------------------------- 

opingukava_id (PK) 

kava_seisund (FK) 

loomise_aeg 

Joonis 2 Tüüpide (klassifikaatorite) tabel. 

Kava_seisund 

------------------------------ 

kava_seisund_id (PK) 

nimetus 

Opingukava 

------------------------- 


kava_seisund (FK) 

seisundi_nimetus 

loomise_aeg 

Joonis 3 Klassifikaatori tabeliga seotud tabeli denormaliseerimine. 

Klassifikaatori tabel säilib endiselt, sest selle abil saab kontrollida kasutajapoolset 

andmete sisestamist. 


kava_seisund → seisundi_nimetus. 

Kuna tegemist on ülekanduva sõltuvusega, siis see tabel on teisel, aga mitte 

kolmandal normaalkujul. 

Probleemid: 

Probleemid on samad, mida mainiti juba 1:M suhte puhul mitte-võtmeveergude 

dubleerimise juures. 

• M:N seosetüübi puhul veergude dubleerimine vahetabelis. Selle 

eesmärgiks on vähendada päringutes tabelite ühendamise vajadust. 

Opingukava 

------------------------- 


loomise_aeg 

Aine_opingukavas 

------------------------------------ 

opingukava_id(FK)(PPK) 

ainekood (FK)(PPK) 

Aine 

--------------------------- 

ainekood (PK) 

nimetus 

ainepunkte 

Joonis 4Denormaliseerimata vahetabel. 

Tüüpiline päring on: 

9


SELECT O.*, A.nimetus 

FROM Opingukava O, Aine_opingukavas Aa, Aine A 

WHERE (O.opingukava_id=Ao.opingukava_id) AND (Ao.ainekood=A.ainekood) 

Sellisel juhul võib tabelisse Aine_opingukavas lisada juurde veeru aine_nimetus. 

Opingukava 

------------------------- 


loomise_aeg 


------------------------------------ 



aine_nimetus 

Aine 

--------------------------- 

ainekood (PK) 

nimetus 

ainepunkte 

Joonis 5 Denormaliseeritud vahetabel. 

SELECT O.*, Ao.aine_nimetus 

FROM Opingukava O, Aine_opingukavas Aa 

WHERE (O.opingukava_id=Ao.opingukava_id) 


ainekood → aine_nimetus 

Kuna aine_nimetus ei sõltu mitte tervest primaarvõtmest vaid mõnest selle osast, 

siis on see tabel esimesel normaalkujul, aga ei ole teisel normaalkujul. 

10


Probleemid: 

Kontseptuaalsel tasemel esinev M:N suhe lahendatakse SQL-andmebaasis 

vahetabeliga, milles on kaks välisvõtme veergu. Seega on ka probleemid samad, 

mida mainiti juba 1:M suhte puhul mitte-võtmeveergude dubleerimise juures. 

• 1:1 seosetüübi puhul tabelite ühendamine. 

 

Leping 

lepingu_nr : Integer 

kehtivuse_algus : Date 

1 

koostatakse 

0..1 

 

Arve 

arve_nr : Integer 

summa : Currency 

tasumistähtaeg : Date 

Joonis 61:1 seosetüüp. 

+koostamise alus 

+koostamise tulemus 

Lighstone et al. (2007) toob näite denormaliseerimise kohta ka seoses 1:1 

seosetüüpidega. 

1:1 seosetüübi alusel luuakse loogilise disaini käigus tabelid. 

Leping (lepingu_nr, kehtivuse_algus) 

Primaarvõti (lepingu_nr) 

Arve (arve_nr, lepingu_nr, summa, tasumistähtaeg) 

Primaarvõti(arve_nr) 

Alternatiivvõti (lepingu_nr) 

Välisvõti (lepingu_nr) Viitab Leping (lepingu_nr) 

Tabelid Leping ja Arve on viiendal normaalkujul. 

Denormaliseerimise käigus võib kaaluda nende tabelite ühendamist ja luua 

tabeli. 

Leping (lepingu_nr, arve_nr, kehtivuse_algus, summa, tasumistähtaeg) 

Primaarvõti(lepingu_nr) 

Kuna võib leiduda lepinguid, millel pole arvet, siis ei saa loodud tabelis määrata 

(arve_nr) alternatiivvõtmeks (sest igas tabeli reas peab võtme väärtus olema 

määratud). 

Uues loodud tabelis Leping eksisteerib funktsionaalne sõltuvus: 

arve_nr → summa


Kuna arve_nr ei kuulu primaarvõtmesse, siis ei ole täidetud kolmanda 

normaalkuju reeglid. Denormaliseerimise tulemusel leitud tabel Arve on teisel 

normaalkujul, aga ei ole kolmandal normaalkujul. 

Toodud lahenduse puhul on oluline tähele panna, et olemitüübile Arve vastavad 

veerud tabelis Leping peavad olema mittekohustuslikud. 

Esitame näite selle kohta, et denormaliseerimine võib muuta mõningate 

päringute kirjutamise keerukamaks. Ülesandeks on leida erinevate arvete arv. 

Enne denormaliseerimist: 

SELECT Count(*) AS arv FROM Arve; 

Pärast denormaliseerimist: 

SELECT Count(*) AS arv FROM (SELECT arve_nr FROM Leping WHERE 

arve_nr IS NOT NULL); 

3.2 Liiasuse tekitamine 

Denormaliseerimine suurendab andmete liiasust. Samas mitte igasugune 

liiasuse tekitamine ei ole denormaliseerimine! 

Vaatleme näidet andmete liiasuse suurendamise kohta, mis ei tähenda 

denormaliseerimist. Tuleb märkida, et kirjanduses esitatakse järgnevaid näiteid 

ekslikult kui näiteid denormaliseerimise kohta. Tegelikult ei tähenda järgnevate 

disainimuudatuste tegemine denormaliseerimise rakendamist. 

• Tuletatavate väärtuste kasutamine. 

Opingukava 

------------------------- 


loomise_aeg 

ainepunktide_summa 


------------------------------------ 



aine_nimetus 

Aine 

--------------------------- 

ainekood (PK) 

nimetus 

ainepunkte 

Joonis 7 Tuletatud andmeid sisaldava veeru lisamine andmetabelisse. 

Näiteks võib tabelisse Opingukava lisada veeru, kus hoitakse sellese 

õpingukavasse kuuluvate õppeainete ainepunktide summat.


Selle väärtuse saaks ka välja arvutada SQL lausega: 

SELECT opingukava_id, loomise_aeg, SUM(ainepunkte) AS summa 

FROM Opingukava, Aine_opingukavas, Aine 

WHERE Opingukava.opingukava_id=Aine_opingukavas.opingukava_id AND 

Aine_opingukavas.ainekood=Aine.ainekood; 

Probleemid 

• Tabelis Opingukava hoitav ainepunktide_summa peab olema kooskõlas tabeli 

Aine_opingukavas põhjal leitava andmepunktides summa. Kooskõla 

kontrollimiseks ja tagamiseks tuleb kirjutada kontrollprotseduurid, mis 

käivitatakse tabelites Opingukava ja Aine_opingukavas toimuvate 

andmemuudatuste tulemusena (tuleb kasutada trigereid). 

• Aruande tabelite koostamine. 

Miks võiks olla vaja sellist tabelit luua? 

- Aruanne koostatakse mitme tabeli põhjal. 

- Aruande väljastamine peab toimuma kiiresti. 

Aruande väljastamise lihtsustamiseks laaditakse andmed aruande struktuurile 

vastavasse tabelisse. Aruande väljastamine on nüüd üks lihtne päring ühe tabeli 

põhjal. 

Oletame, et andmebaasis on järgnevad tabelid: 

Müük (müük_id, kuupäev) 

Primaarvõti (müük_id); 

Müügi_rida(müük_id, kauba_kood, kogus) 

Primaarvõti (müük_id, kauba_kood) 

Välisvõti (müük_id) Viitab Müük(müük_id); 

Selleks, et kiirendada müügiaruande koostamist, võib luua tabeli: 

Müügitulemused 

kauba jan feb mar apr may jun jul aug sep oct nov dec SUM 

_kood 

1 4 2 1 4 3 8 9 7 6 4 2 1 51 

2 5 3 3 3 4 2 9 8 5 3 1 0 46 

SUM 9 5 4 7 7 10 18 15 11 7 3 1 97 

Sellise tabeli võib luua hetktõmmise e. materialiseeritud vaatena. Sellisel juhul 

hoolitseb andmebaasisüsteem ise, et selles tabelis olevaid andmeid 

värskendatakse regulaarselt tabelites Müük ja Müügi_rida olevate andmete 

põhjal.


Seega ei ole normaliseerimine – imerelv. Tabelid võivad olla kõrgeima tasemeni 

normaliseeritud, kuid andmebaasis võib olla endiselt andmete liiasus. 

3.3 Denormaliseerimise algoritm 

Hoberman (2002, lk. 342 – 361) kirjeldab algoritmi "Denormalization Survival 

Guide", mis aitab otsustada, millised tabelid tuleb denormaliseerida ja millised 

mitte. Iga andmemudelis esitatud suhte kohta vastatakse küsimustikule. Igal 

küsimustiks sisalduval küsimusel on vastusevariandid. Iga variant annab teatud 

arv punkte. 

Suhte kontekstis sisaldab sõltuv tabel välisvõtit. Sõltuv tabel on välisvõtme kaudu 

seotud primaarse tabeliga (peremeestabeliga). 

Järgnevalt esitatakse selle algoritmi kasutatav küsimustik ja vaadeldakse lühikest 

näidet. 

Küsimus 

Mis tüüpi suhtega on 

tegemist peremeestabeli 

ja sõltuva tabeli vahel? 

Milline on ühe 

peremeestabeli reaga 

seotud sõltuva tabeli 

ridade arv? 

Kui palju veerge on 

peremeestabelis, jättes 

arvestamata 

primaarvõtme veerud? 

Kui tehakse päring 

sõltuva tabeli kohta, siis 

kui sageli soovitakse 

andmeid ka 

peremeestabelist? 

Kas peremeestabelisse 

on lähiajal plaanis lisada 

uusi veerge või siduda 

uusi tabeleid? 

Valik 

Osa-terviku (agregatsiooni või kompositsiooni) seos, 

hierarhia. Nt. tellimus sisaldab tellimuste ridu, kauba 

kategooria sisaldab alamkategooriaid. (20) 

Suhe võrdsete vahel. Kummalegi tabeli rida võib eksisteerida 

teise tabeli reast sõltumatult. Nt. õppejõud koostab 

dokumendi. (-10) 

Definitsioon. Peremeestabelis olevad andmed määravad 

sõltuvas tabelis olevate andmete tähenduse. Nt. õppeaine 

spetsifikatsioon ja õppeaine tegelik õpetamine. Kui 

olemitüüpide vahel on M:N seosetüüp, siis luuakse selle 

esitamiseks vahetabel. Suhe selle vahetabeli ja 

peremeestabeli vahel on defineeriv suhe.(-20) 

1 kuni 5 (20) 

5 kuni 100 (-10) 

100 ja rohkem (-20) 

Vähem kui 10 (20) 

10 kuni 20 (-10) 

Rohkem kui 20 (-20) 

Päringus soovitakse sageli andmeid peremeestabelist (30) 

Päringus ei soovita sageli andmeid peremeestabelist (-30) 

Jah (-20) 

Ei (20)


Kas peremeestabelis ja 

ja sõltuvas tabelis 

toimub ajaperioodis 

sarnane arv lisamisi ja 

muutmisi? 

KOKKU PUNKTE 

Jah (toimub sarnane arv lisamisi ja muutmisi) (20) 

Ei (ei toimu sarnane arv lisamisi ja muutmisi) (-20) 

Denormaliseerimise protsess. 

- Määra mudelil olevate suhete prioriteedid. 

- Vali suhted. 

- Vasta suhte kohta küsimustikule 

- Denormaliseeri suhtes osalevad tabelid, kui küsimustiku tulemus on 10 

punkti või rohkem. Selleks loo suhtes osalevate tabelite põhjal üks uus 

tabel. 

- Mine tagasi punkti 2, kuni kõik suhted on läbitud. 

Näide: 

Tudeng 

matrikli_nr 

eesnimi 

perenimi 

synni_aeg 

sugu 

aadress 

telefon 

e_mail 

Oppimine 

matrikli_nr (FK) 

aine_kood (FK) 

alguse_kuupaev 

eelregistreerimise_kuupaev 

lopetamise_kuupaev 

Aine 

aine_kood 

hindamisviis (FK) 

aine_seisund (FK) 

nimetus 

loomise_kuupaev 

kinnitamise_kuupaev 

ainepunkte 

loenguid 

laboreid 

harjutusi 

lyhisisu 

Aine_seisund 

aine_seisund 

nimetus 

kirjeldus 

Hindamisviis 

hindamisviis 

nimetus 

kirjeldus 

Joonis 8 Näidisandmebaasi struktuur enne denormaliseerimist.


Suhe: Aine-Aine_seisund (Aine_seisund on peremeestabel ja Aine on sõltuv 

tabel) 

Küsimus 

Valik 

Mis tüüpi suhtega on tegemist peremeestabeli ja Definitsioon. (-20) 

sõltuva tabeli vahel? 

Milline on ühe peremeestabeli reaga seotud sõltuva 100 ja rohkem (-20) 

tabeli ridade arv? 

Kui palju veerge on peremeestabelis, jättes 


arvestamata primaarvõtme veerud? 

Kui tehakse päring sõltuva tabeli kohta, siis kui Päringus soovitakse sageli 

sageli soovitakse andmeid ka peremeestabelist? andmeid peremeestabelist (30) 

Kas peremeestabelisse on lähiajal plaanis lisada Ei (20) 

uusi veerge või siduda uusi tabeleid? 

Kas peremeestabelis ja ja sõltuvas tabelis toimub Ei (ei toimu sarnane arv lisamisi 

ajaperioodis sarnane arv lisamisi ja muutmisi? ja muutmisi; klassifikaatorid 

registreeritakse juba enne 

andmete ülekandmist 

andmebaasi, õppeainete 

andmeid aga lisatakse 

regulaarselt) (-20) 

KOKKU PUNKTE 

10 

Otsus: Kaaluda denormaliseerimist 

Suhe: Aine-Hindamisviis (Hindamisviis on peremeestabel ja Aine on sõltuv 

tabel) 

Küsimus 

Valik 

Mis tüüpi suhtega on tegemist peremeestabeli ja Definitsioon. (-20) 







Kui tehakse päring sõltuva tabeli kohta, siis kui Päringus soovitakse sageli 

sageli soovitakse andmeid ka peremeestabelist? andmeid peremeestabelist (30) 

Kas peremeestabelisse on lähiajal plaanis lisada Ei (20) 


Kas peremeestabelis ja sõltuvas tabelis toimub Ei (ei toimu sarnane arv lisamisi 

ajaperioodis sarnane arv lisamisi ja muutmisi? ja muutmisi) (-20) 

KOKKU PUNKTE 

10 

Otsus: Kaaluda denormaliseerimist


Suhe: Tudeng – Oppimine (Tudeng on peremeestabel ja Oppimine on sõltuv 

tabel) 

Küsimus 

Valik 

Mis tüüpi suhtega on tegemist peremeestabeli ja Definitsioon (-20) 


Milline on ühe peremeestabeli reaga seotud sõltuva 5 kuni 100 (-10) (keskmine 


hinnang) 



Kui tehakse päring sõltuva tabeli kohta, siis kui 

sageli soovitakse andmeid ka peremeestabelist? 

Kas peremeestabelisse on lähiajal plaanis lisada 


Kas peremeestabelis ja sõltuvas tabelis toimub 

ajaperioodis sarnane arv lisamisi ja muutmisi? 

KOKKU PUNKTE 


Päringus soovitakse sageli 

andmeid peremeestabelist (30) 

Jah (-20) (ülikoolis on plaanis 

jätkata uute registrite 

väljatöötamist) 

Ei (ei toimu sarnane arv lisamisi 

ja muutmisi) (-20) 

-20 

Otsus: Mitte denormaliseerida 

Suhe: Aine – Oppimine (Aine on peremeestabel ja Oppimine on sõltuv tabel) 

Küsimus 

Valik 

Mis tüüpi suhtega on tegemist peremeestabeli ja Definitsioon.(-20) 





10 kuni 20 (-10) (tulenevalt 


sellest, et toimus 

denormaliseerimine) 

Kui tehakse päring sõltuva tabeli kohta, siis kui 

sageli soovitakse andmeid ka peremeestabelist? 

Kas peremeestabelisse on lähiajal plaanis lisada 


Kas peremeestabelis ja sõltuvas tabelis toimub 

ajaperioodis sarnane arv lisamisi ja muutmisi? 

KOKKU PUNKTE 

Päringus soovitakse sageli 

andmeid peremeestabelist (30) 

Jah (-20) (ülikoolis on plaanis 

jätkata uute registrite 

väljatöötamist) 

Ei (ei toimu sarnane arv lisamisi 

ja muutmisi) (-20) 

-60 

Otsus: Mitte denormaliseerida


Joonis 9 Näidisandmebaasi struktuur peale denormaliseerimist. 

Õppejõu seisukoht – ei denormaliseeriks. Miinuseid on rohkem kui plusse.


Parem lahendus oleks, kui andmebaasisüsteemid lubaksid tabelite andmeid 

ühendada sisemises skeemis, kuid kontseptuaalses skeemis jääksid tabelid 

lahku. 

Kontseptuaalne 

skeem 

Tabel 1 Tabel 2 

Sisemine 

skeem 

Tabeli 1 plokid 


Joonis 10 Lähteolukord. 

Kasutajad soovivad teha päringu ja näha päringu tulemuses nii tabelist 1 kui ka 

tabelist 2 võetud andmeid. 


skeem 

Tabel 1 + 

Tabel 2 

Sisemine skeem 


+ Tabeli 2 

plokid 

Joonis 11 Denormaliseerimise praktika tänapäeva SQL-andmebaasides. 

Paraku on tänapäeva SQL-andmebaasisüsteemides tavaline praktika, et 

kontseptuaalses skeemis olevatele elementidele vastab üks-ühele element


sisemises skeemis (direct image) (vt. Joonis 11). Tänu sellele ei ole tagatud 

andmete sõltumatus. Kui soovitakse muuta andmete organisatsiooni sisemisel 

tasemel, siis tänapäeva SQL-andmebaasisüsteemides ei jää paraku sageli muud 

üle, kui teha muudatusi kontseptuaalses skeemis (denormaliseerida). See ei ole 

hea lahendus. Joonis 12 esitab parema lahenduse probleemile, mida 

denormaliseerimise tulemusel üritatakse lahendada. Kui andmebaasisüsteem 

kasutaks Joonisel 12 esitatud lahendust, siis näiteks päringu: 

SELECT * 

FROM Tabel1 NATURAL JOIN Tabel2; 

läbiviimiseks peab andmebaasisüsteem viima läbi vähem I/O operatsioone 

võrreldes Joonis 11 esitatud lahendusega. 


skeem 

Tabel 1 Tabel 2 

Sisemine skeem 


+ Tabeli 2 

plokid 

Joonis 12 Õigem lahendus probleemidele, mida denormaliseerimisega 

püütakse lahendada.


4. SQL-andmebaasi disain – kokkuvõte 

Kasutusjuhtude 

mudel 

Infovajaduste 

nimekiri 

Pädevusalade 

nimekiri 

Ärireeglid 

Domeenimudel 

Sõnastik 


andmemudel 

Andmebaasioperatsioonide 

lepingud 

Seisundidiagramm 

Infosüsteemi 

rollide 

kirjeldused 

Reaalsete 

kasutusjuhtude 

kirjeldused 

Loogilise 

disaini 

andmemudel 

Transaktsioonanalüüs 

Tehnilised 

dokumendid 

andmebaasisüsteemi 

kohta 

Füüsilise disaini 

andmemudel 

Tabelite ja kitsenduste 

loomise laused 

Andmebaasiserveris 

talletatud 

rutiinid 

Trigerid 

Vaated 

Kasutajagruppide 

loomise laused 

Joonis 13 Mõnede olulisemate andmebaaside projekteerimisega seotud 

dokumentide omavahelised sõltuvused.


Eelneval joonisel näitab nool sõltuva tulemi poole. 

Strateegilise analüüsi üheks ülesandeks on süsteemi skoobi (piiride) leidmine 

ning süsteemi tükeldamine allsüsteemideks. Allsüsteemide leidmine tähendab 

tegelikult "jaga ja valitse" (Divide et impera) põhimõtte rakendamist, mille 

kohaselt jagatakse keeruline ülesanne lihtsamalt saavutatavateks 

alamülesanneteks. Selle asemel, et hakata süsteemi arendama kui monoliitset 

tervikut, on võimalik süsteemi arendada osade kaupa – olulisemad osad enne, 

vähem olulised osad hiljem. 

Detailanalüüsi üheks tulemuseks on kontseptuaalne andmemudel. 

Kontseptuaalne andmemudel on mittetehniline mudel, mille eesmärk on 

kirjeldada nõudmised loodavale andmebaasile (milliseid andmeid seal tuleks 

hoida) ja teha lugejatele võimalikult hästi selgeks andmebaasis hoitavate 

andmete tähendus (semantika). 

Detailanalüüsi üheks tulemuseks on ka andmetega seotud kitsenduste leidmine. 

Selliste kitsenduste leidmisel tuleb arvestada ärireeglitega. Traditsiooniliselt 

kontseptuaalse andmemudeli esitamiseks kasutatavad olemi-suhte diagrammid 

ei paku võimalusi keerukamate kitsenduste diagrammil kujutamiseks ja seetõttu 

tuleks need panna kirja tekstina. Andmetega seotud kitsenduste leidmine ning 

nende hilisem süsteemis jõustamine on väga oluline, sest see aitab parandada 

andmete kvaliteeti. Andmete kvaliteet aga peaks olema andmebaasi pidaja üks 

põhilisi eesmärke, sest halva kvaliteediga andmed põhjustavad halva 

kvaliteediga (valede) otsuste langetamise. 

Kontseptuaalse andmemudeli põhjal leitakse teisendusreegleid kasutades 

esimene variant SQL-andmebaasi (baas)tabelitest ja nende tabelitega seotud 

kitsendused, sealhulgas primaarvõtme, unikaalsuse ja välisvõtme kitsendused. 

Peale esialgsete tabelite leidmist, rakendatakse formaalseid protseduure tabelite 

struktuuri parandamiseks. 

• Täiendav normaliseerimine (sageli öeldakse lihtsalt normaliseerimine). 

• Ortogonaalse disaini printsiibi rakendamine. 

Normaliseerimise ja ortogonaalse disaini printsiibi rakendamise eesmärk on 

vähendada andmete liiasust ning sellest tulenevalt andmete muutmise 

anomaaliaid. Mida täpsem on olnud analüüs ja mida rohkem on kasutatud 

mustreid või universaalseid mudeleid, seda vähem tuleb andmebaasi struktuuris 

muudatusi teha. Ideaalis võiksid kõik tabelid olla normaliseerimise tulemusena 

viidud viiendale normaalkujule. Täiendav normaliseerimine ja ortogonaalse 

disaini printsiibi rakendamine ei taga andmete liiasusest täielikku lahtisaamist. 

See ei ole ka vajalik, kuid andmebaasi arendajad peavad tagama, et igasugune 

liiasus on kontrollitud – st. andmebaasis ei ole võimalik registreerida üksteisega 

vastuolus olevaid fakte. 

Andmebaasis olevate andmete kitsendustele vastamise tagamiseks võib 

SQL-andmebaasisüsteemides kasutada.


• Deklaratiivsed kitsendused. Ühe kindla tabeliga seotud kitsendused ja üldised 

kitsendused (viimaseid luuakse CREATE ASSERTION käsuga). 

• Andmebaasi trigeri protseduurid e. trigerid. 

Miks ikkagi kontrollida andmete kitsendustele vastavust andmebaasi tasemel? 

Vastavad kontrollid võiks ju kirjutada sisse loodavasse rakendusse. 

Andmete kitsendustele vastavuse kontroll ainult andmebaasi kasutavas 

rakenduses ei ole hea mõte. 

• Kui andmebaasi hakkab kasutama uus rakendus, tuleb sellesse kitsenduste 

kontroll sisse kirjutada. Kui rakenduste arv suureneb, muutub ka raskemaks 

kitsenduste muutmine (muudatus tuleb sisse viia mitmesse kohta). 

• Kui andmete poole pöördutakse otse (nt. läbi andmebaasi administreerimise 

programmi), siis ei kontrollita kitsendustest kinnipidamist. 

Mõningate kitsenduste kontrolli võib dubleerida ka rakenduses, sest see 

võimaldab kasutajale anda kiirema tagasiside (parem kasutusmugavus) ning 

väldib vigaste andmete edastamist üle arvutivõrgu (võrgu koormuse 

vähendamine). Kui kitsendust ei õnnestu andmebaasi tasemel jõustada, tuleb 

seda igal juhul teha rakenduses, sest nagu vanasõnagi ütleb – parem pool muna 

kui tühi koor. Kuid andmebaasis jõustatud kitsendus on nagu teine kaitseliin. Kui 

esimene kaitseliin murdub võite ikkagi olla kindlad, et ebakorrektsed andmed ei 

jõua andmebaasi. 

Detailanalüüsi üheks tulemuseks on andmebaasioperatsioonide lepingud, mis 

kirjeldavad. 

• Eeltingimused, mis peavad olema täidetud, et operatsiooni saaks käivitada. 

• Järeltingimused, mis kirjeldavad operatsiooni täitmise tulemusena 

andmebaasis toimunud muudatusi. 

Operatsioonidest rääkides tuuakse võrdlust teatri lavaga. Laval on asjad ja 

inimesed. Lavale lastakse eesriie ette ja tõstetakse üles (toimub operatsioon). 

Järeltingimustes pannakse kirja, mis on laval muutunud võrreldes eesriide 

langetamise eelse ajaga (millised muudatused on toimunud andmebaasis). 

Näiteks mõni inimene on juurde tulnud, mõni ära läinud ja asjad on oma kohti 

muutnud. Kui mõni asi või inimene jäi oma kohale, siis pole sellele vaja 

järeltingimuses viidata. Eeltingimustes on kirjas tingimused, mis peavad olema 

täidetud, et eesriide langetamist saaks läbi viia. 

Andmebaasioperatsioonid pakuvad funktsionaalsetele allsüsteemidele andmete 

kasutamise teenuseid. Iga andmebaasioperatsiooni kohta võiks luua omaette 

andmebaasiserveris talletatud rutiini (funktsiooni või protseduuri). Iga registri 

rutiinid võiks koondada eraldi paketti. 

Idee on selles, et andmebaasi poole pöörduv programm kutsub andmete 

kasutamiseks välja rutiini. See tähendab, et andmebaasi poole pöörduvas 

programmis e. rakenduses pole SQL lauseid. Rakenduse programmeerija ei pea


SQL lausete kirjutamisega vaeva nägema. SQL laused on koondatud 

andmebaasiserveris talletatud rutiinidesse. Seal on neid vajadusel lihtne muuta. 

Nende muutmine on andmebaasi programmeerija ülesanne. Andmebaasiserveris 

talletatud rutiinid kasutavad omakorda vaateid või pöörduvad otse tabelite poole. 

Rakenduse andmebaasi kasutus seisneb andmebaasiserveris talletatud rutiinide 

väljakutsumises. Rakenduses on rutiinide väljakutsed jaotatud 

transaktsioonidesse. Transaktsioon võib sisaldada ühe või mitme rutiini 

väljakutsumist. Rutiinis omakorda on üks või mitu SQL lauset. 

Detailanalüüsi oluliseks tulemuseks on ka põhiolemitüüpide seisundidiagrammid. 

Seisundidiagrammil kirjeldatakse põhiolemitüübi võimalikud seisundid ja 

võimalikud üleminekud ühest seisundist teise. Lisaks saab kirjeldada 

valvurtingimusi, mis peavad olema täidetud, et seisund saaks muutuda. 

Andmebaas peaks olema projekteeritud nii, et selle põhjal saab teha päringuid – 

"Leidke olemid, mis on seisundis X" (näiteks: Leidke arved, mis on seisundis 

kinnitatud.) Sellised päringud võib andmebaasis realiseerida vaadetena. 

Lisaks peaks kuidagi kontrolllima, et registreeritavad olemite 

seisundimuudatused vastavad seisundidiagrammis kirjeldatule. Selleks võib 

kasutada trigereid. 

Oletame, et meil on tabelid: 

Tellimuse_seisundi_liik(tellimuse_seisundi_liik_id, nimetus) 

Primaarvõti(tellimuse_seisundi_liik_id) 

Alternatiivvõti (nimetus) 

Tellimus(tellimus_id, summa, kuupäev, tellimuse_seisundi_liik_id) 

Primaarvõti(tellimus_id) 

Välisvõti (tellimuse_seisundi_liik_id) Viitab 

Tellimuse_seisundi_liik(tellimuse_seisundi_liik_id)


Koostamisel 

Tellimust ei soovita esitada 

Kustutatud 

[ Tellimuses on vähemalt üks rida; Igas reas on kauba kogus suurem kui 0 ] 

Esitatud 

Kliendihaldur 

veendub tellimuse 

korrektsuses ja 

täidetavuses 

Klient on esitanud enda kohta 

valeandmed; Tellimust pole 

võimalik täita. 

Kinnitatud 

Tellija ei tasu 

tähtajaks 

tellimuse eest 

Tühistatud 

Tellija tasub tellimuse eest 

Tasutud 

Tellitud kaup viiakse kliendile kohale 

Täidetud 

Joonis 14 Tellimuse seisundidiagramm. 

Tellimuse seisund ei saa muutuda suvaliselt ühest seisundist teise. 

Seisundidiagramm kirjeldab, millised seisundi üleminekud on lubatud. 

Andmebaasi mõttes on tegemist järeldusreeglitega – muudatus on lubatud vaid 

siis, kui on täidetud teatud tingimused. Näiteks. 

• Tellimuse saab kustutada SIIS ja AINULT SIIS, kui see on seisundis 

"Koostamisel". 

Paraku ei võimalda SQL keel järeldusreeglite deklaratiivset kirjeldamist 

andmebaasis (CREATE ja ALTER lausetes). Kontrolli läbiviimiseks tuleb 

kirjutada trigeri protseduur (triger). 

Triger võiks olla seotud tabeliga Tellimus ning kontrollida tellimuse seisundi 

muutmisel, kas taoline seisundi muutus on legaalne ning mittelegaalset


muudatust mitte lubada. Näiteks seisundis "koostamisel" olev tellimus saab 

minna seisundisse "esitatud" või selle võib kustutada. Seisundisse "esitatud" 

saab tellimus minna vaid siis, kui tellimusega on seotud mõni tellimuse rida ja 

kauba kogus sellel on suurem kui 0 (need on valvurtingimused). Seisundist 

"esitatud" saab tellimus minna seisundisse "kinnitatud" või "tühistatud", aga mitte 

seisundisse "koostamisel", "tasutud", "täidetud". Seisundis "esitatud", 

"kinnitatud", "tasutud", "täidetud" ja "tühistatud" olevat tellimust ei tohi kustutada. 

Sellise lahenduse probleem on, et lubatud seisundimuutused on programmi sisse 

kodeeritud. Äriprotsesside muutumisel tuleb programmi muuta. Paindlikum 

lahendus oleks lubatud seisundi üleminekute ja valvurtingimuste kirjeldamine 

andmebaasis (SQL-andmebaasi korral võiks nende kirjeldus olla mingis tabelis). 

Trigeri sündmuse tulemusel käivitunud protseduur loeb neid andmeid kontrolli 

läbiviimisel. Sellisel juhul pole vaja seisundidiagrammi muutumisel hakata 

programmi ümber kirjutama, vaid tuleb muuta andmebaasis seisundimuudatuste 

kirjeldusi. 

5. Realiseerimise (ehitamise) etapp 

Toimub eraldi disainitud allsüsteemide (andmebaaside ja rakenduste) lõplik 

realiseerimine ja integreerimine terviksüsteemi tasemel. Põhitegevusteks 

programmeerimine, testimine, loodud andmebaasi ja programmide 

integreerimine. 

6. Rakendamise (üleviimise) etapp 

Eesmärgiks on süsteemi ehitajate poolt realiseeritud terviksüsteemi üleviimine 

tellija keskkonda ning seal toimima panemine. Üheks oluliseks tegevuseks on 

siin andmete ülekandmine vana(de)st süsteemi(de)st uue süsteemi 

andmebaasi(desse). Seda nimetatakse andmesiirdeks. 

7. Hoolduse etapp 

Tellija keskkonnas toimiva süsteemi ülalhoidmine, vigade parandamine, jõudluse 

jälgimine, häälestamine, uute arendustööde käivitamine. See on pidev protsess. 

Andmebaasi toimimise tagamine, aga ka pisemate jooksvate 

paranduste/arendustööde tegemine, on andmebaasi administraatori ülesanne. 

Andmebaasi jõudluse jälgimisest ja häälestamisest saadav kasu on näiteks: 

- võib väheneda täiendava riistvara vajadus, 

- suurenev töökiirus parandab organisatsiooni töö efektiivsust ja suurendab 

klientide rahulolu.


Teisest küljest – madal töökiirus vähendab töötajate tööindu ja tekitab klientides 

rahulolematust. 

8. Mõisted 

Eesti keeles 

Denormaliseerimine 

Klassifikaatorite tabel 

Töötava süsteemi jälgimine ja 

häälestamine 

Inglise keeles 

Denormalization 

Lookup table 

Reference table 

Monitoring and tuning of operational 

system. 

9. Kasutatud materjalid 

1. Celko, J., 1999. Joe Celko's Data & Databases: Concepts in Practice. Morgan 

kaufmann Publishers, Inc. 1999. 382 p. 

2. Connolly, T.M. & Begg, C.E., 2001. Database Systems. A Practical Approach 

to Design, Implementation and Management. Third Edition. Pearson 

Education, 2001. 1236 p. 

3. Date, C.J., 2007. Logic and Databases. The Roots of Relational Theory. 

Trafford Publishing. 445 p. 

4. Date, C.J., 2009. SQL and Relational Theory. How to Write Accurate SQL 

Code. O'Reilly. 404 p. 

5. Hoberman, S., 2002. Data Modeler's Workbench: Tools and Techniques for 

Analysis and Design. Wiley Computer Publishing. 472 p. 

6. Lighstone, S., Teorey, T. & Nadeau, T., 2007. Physical database design. The 

databse professional's guide to exploiting indexes, views, storage, and more. 

Morgan Kaufmann Publishers. 427 p. 

7. Muller, R.J., 1999. Database Design for Smarties. Using UML for Data 

Modeling. Morgan Kaufmann Publishers. 442 p.

Andmebaasid I - Teema nr. 14

Create successful ePaper yourself

Delete template?

Save as template?