2 Andmebaaside loomise protsess
Andmebaasi loomine on pikk protsess. Selleks tuleb läbida järgnevad etapid:
- Nõuete analüüs
- Andmebaasi mudeli loomine
- Vaadete loomine
- Andmebaasi andmetega täitmine
- Rakenduse loomine
- Rakenduse ning andmebaasi omavaheline sidumine
Selles peatükis räägime me täpsemalt esimesest kahest etapist.
Nõuete analüüs
Nõuete analüüsi all tuleks selgelt sõnastada, mida peaks loodav andmebaas võimaldama. Selleks tuleb end loodava andmebaasi temaatikaga kurssi viia ning välja selgitada konkreetse teema nõuded, reeglid ning tavad.
Näiteks kui luua andmebaas õpilaste, õpetajate ning kursuste kohta (sh kes mis kursusel õpib), tuleks mõelda sellele, et kas ka õpetaja võib olla õpilase rollis? Mõeldes gümnaasiumi peale, siis ilmselt mitte, kuid näiteks ülikoolis on see päris tavaline, et ka õppejõud ise osaleb mõnel ülikooli pakutaval kursusel. Kui aga sellele kohe alguses mõtlemata vale struktuuriga andmebaas luua, ilmneb hiljem probleeme, sest ükski õpetaja ei saa ise ühtegi kursust võtta.
Selleks, et konkreetse andmebaasi nõudeid paika panna, võiks alustada põhiliste objektide ja nähtuste välja selgitamisega. Näiteks luues andmebaasi suurele ostuketile, tuleks kindlasti mõelda poodidele, töötajatele, klientidele, toodetele jne.
Seejärel võiks mõelda nende objektide ja nähtuste vahelistele seostele. Näiteks töötaja töötamine poes, toote ostmine kliendi poolt jne.
Oluline on mõelda ka sellele, kui spetsiifiliseks peab andmebaasis kajastatuga minema. Näiteks võib-olla pole suure ostuketi jaoks oluline, kas töötajal on lapsi või mitte, seega seda ei peaks andmebaasis kajastama.
Kõik eelnevad sammud on äärmiselt olulised selleks, et andmebaas vastaks reaalsetele vajadustele ning ootustele. Alles siis, kui nõuded on välja selgitatud, võib minna edasi andmebaasi mudeli loomise juurde.
Andmebaasidega seotud mõisted
Selleks, et rääkida andmebaasi mudeli loomisest, tuleb esmalt selgitada lahti mõningad mõisted:
- Olem – reaalselt eksisteeriv ning identifitseeritav asi või nähtus (nt konkreetne isik, konkreetne toode jne).
- Olemitüüp – kogum sarnaseid olemeid (nt isik, toode jne).
- Tunnus – tunnused kirjeldavad andmebaasides olemitüüpe (nt isiku korral eesnimi, perenimi, sugu). Tunnuste väärtused kirjeldavad/esindavad olemeid (nt ‘Oskar’, ‘Ohakas’, ‘mees’).
- Võti – neid tunnuseid, mille väärtused identifitseerivad olemi üheselt, nimetatakse olemi võtmetunnusteks. Ehk siis võti on mingisugune tunnuste komplekt, mille väärtust teades oskan ma kindlaks teha, millise olemiga on tegu.
- Primaarvõti – minimaalne tunnuste hulk, mille abil oskan ma kindlaks teha, millise olemiga on tegu. Näiteks Eesti kodaniku puhul oleks primaarvõtmeks isikukood, sest isikukood on igal inimesel erinev ehk see aitab meil ühte kindlat inimest määratleda.
- Seos – seosed eksisteerivad olemitüüpide vahel. Seoseid klassifitseeritakse selle järgi, mitu ühe olemitüübi olemit saavad olla seotud teise olemitüübi olemiga. Näiteks klient saab osta mitut toodet, kuid iga ost on seotud ühe kindla kliendiga. Seega olemitüübi Klient ning olemitüübi Ost vahel on 1:n ehk üks-mitmele seos. Samas olemitüübi Toode ning olemitüübi Klient vahel on n:m ehk mitu-mitmele seos, sest üks klient saab osta mitut toodet ning ühte toodet saab osta mitu erinevat klienti. On olemas ka 1:1 ehk üks-ühele seoseid. Selliseks seoseks on näiteks abielu Euroopas – mõlemal abielu osapoolel on parajasti üks abikaasa.
Andmebaasi mudeli loomine
Räägime nüüd sellest, milline üldse üks andmebaas välja näeb.
Andmebaas koosneb erinevatest tabelitest. Üldiselt pole andmed andmebaasis kunagi vaid ühes tabelis, vaid need on jagatud mitme väiksema tabeli vahel. Lisaks tabelitele on andmebaasis kirjeldatud ka tabelite vahelised seosed. Tabeleid ning nendevahelisi seosed on hea vaadelda andmebaasi mudeli abil. All on näide lihtsustatud andmebaasi mudelist, mis võiks kirjeldada poes ostu tegemist.
Kuna me soovime infot talletada nii kliendi, toote, kui ka konkreetse ostu kohta, olemegi loonud kolm eri tabelit, mis kirjeldavad olemitüüpe Klient, Ost ning Toode.
Nagu näha, siis tabelis Klient on kolm tunnust – id, eesnimi ja perenimi. Tunnuse id kõrval on näha võtmekest, mis näitab, et tegu on primaarvõtmega, seega tunnuse id abil on võimalik ühte konkreetset klienti üheselt tuvastada. Samuti on tabelis Klient tunnused eesnimi ning perenimi.
Miks me aga tuvastame ühte konkreetset klienti täisarvulise tunnuse id abil, mitte näiteks isikukoodi abil? Seda seetõttu, et me ei taha, et primaarvõtme väärtus sõltuks välismaailmast. Päriseluline tunnus primaarvõtmena on alati potentsiaalne veakoht andmebaasis. Näiteks kui kasutaja sisestab oma isikukoodi valesti, võib see kattuda mõne teise isiku isikukoodiga, mis omakorda tähendab seda, et meie primaarvõti ei määra olemit üheselt. Samuti võib juhtuda, et mõnel kliendil üldse polegi isikukoodi, mida siis teha? Lisaks eelnevale on eri riikide isikukoodid teadupärast erinevad. Näiteks Ameerika Ühendriikides on isiku identifitseerimiseks kasutusel sotsiaalkindlustuse number (ingl social security number), mis on 9-kohaline arv, kuid Eesti isikukood koosneb 11 numbrist. Kõikide selliste probleemide vältimiseks on mõistlik primaarvõtmeks valida tunnus, mis ei sõltu välismaailmast. Antud juhul on meil selliseks tunnuseks id, mille väärtused on täisarvud. Lisades andmebaasi uusi olemeid ehk kirjeid saame me alati tunnuse id väärtuseks määrata täisarvu, millega ühegi muu andmebaasis oleva kirje id väärtus ei kattu. Sellega oleme me alati taganud primaarvõtme unikaalsuse ja järelikult saamegi me selle tunnuse abil olemit üheselt määrata. Üldiselt pannakse sellise tunnuse nimeks id.
Sellel samal põhjusel on ka igal teisel mudelil oleval olemitüübil primaarvõtmeks tunnus id.
Tabelis Toode on sarnaselt tabelile Klient väli id, mis on primaarvõti. Seega tunnuse id abil saame üheselt määratleda ühte kindlat toodet. Samuti on olemitüübil Toode tunnused nimi, ühikuhind ja ühik. Ühik on oluline seetõttu, et osade toodete korral ühik muutub. Näiteks banaane ostes on ühikuks kg, kuid šokolaadi ostes räägime me tükihinnast.
Mudelil olev kolmas tabel Ost on selleks, et üks klient saaks osta mitut toodet ning et ühte toodet saaks osta mitu klienti. Alati kui meil on kuskil n:m seos (antud juhul olemitüüpide Klient ja Toode vahel), tuleks luua uus tabel, mis hoiaks mõlema n:m seoses oleva olemitüübi (antud juhul Klient ja Toode) primaarvõtmeid. Seda seetõttu, et mitu-mitmele seoseid ei saa muul moel andmebaasides kirjeldada – me ei saa lihtsalt viidata tabelist Klient konkreetsele tootele, sest sel juhul saaks klient osta vaid ühte toodet ning me ei saa viidata tabelist Toode ühele konkreetsele kliendile, sest sel juhul saaks toodet osta vaid üks klient. Luues aga uue olemitüübi Ost, saame me hoopis kaks 1:n seost – olemitüüpide Klient ja Ost vahel ning olemitüüpide Toode ja Ost vahel.
Enesekontroll
Vaata allolevat andmebaasi mudelit ning vasta küsimustele.
