Andmebaasi modelleerimine
Mis on andmebaasi mudel?
Andmebaasi implementeerimiseks luuakse see esialgu kavandina diagrammi kujul. Andmebaasi loomise protsessi käigus tekib kaks mudelit - ER mudel ehk olem-seose mudel ja relatsiooniline mudel. Mõlemad mudelid kujutavad graafina loodava andmebaasi struktuuri, aga neil on siiski oluline erinevus. Olem-seose mudel on abstraktne mudel päriselt loodavast andmebaasist. See mudel kirjeldab ära vajalikud olemitüübid, nende tunnused, nende vahelised seosed ja ei rohkemat muud. Neid tutvustatakse selles peatükis.
Päris andmebaasis on veel tunnuste tüübid, primaarvõtmed, välisvõtmed, vahetabelid jne. Algoritmi järgides saab teisendada ER mudeli relatsiooniliseks mudeliks, mis kirjeldab ka selle ära. Relatsiooniline mudel on juba palju detailsem ja see kujutab andmebaasi täpselt sellisena nagu ta päriselt on. Sellest mudelist räägib lähemalt aga järgmises peatükis.
Skeemil on näha näidet meie andmebaasi ER mudelist. Selles peatükis uurime, kuidas sellist mudelit koostada ja mida tähendavad erinevad märgistused antud mudelis.
Olem, atribuudid ja olemitüüp
Enne mudeli koostamist, peab teostama ärinõuete analüüsi. Ärinõuded ei ole vaid äridel, vaid ka organisatsioonidel, ühingutel jms. Need näitavad reegleid, mis selles valdkonnas kehtivad. Analüüsi läbi viimiseks peab enne teadma, millest ER mudel üldse koosneb. Andmemudeli põhimõisted on:
- Olem on mingi asi, isik, koht, objekt või ükskõik mingi muu ese, mille kohta soovitakse infot salvestada. Näiteks võib olla olemiks "Nukitsamees", kui me tahaks salvestada infot raamatute kohta. Olemid peavad üksteisest eristuma.
- Atribuut on olemi mingi konkreetne tunnus, mida soovitakse selles andmebaasis salvestada. Näiteks raamatu nimi, lehekülgede arv jms.
- Olemitüüp on kogum sarnaseid olemeid. Ühe olemitüübi kõikidel olemitel on samad atribuudid. Näiteks moodustavad olemid "Nukitsamees", "Harry Potter ja tarkade kivi", "Kuristik Rukkis" olemitüübi Raamatud. Neid kõiki saab iseloomustada sarnaste atribuutidega. Mõni atribuut võib olla mõnel olemil ka sisestamata. Olemitüübid võivad ka lõikuda omavahel. Näiteks kui on kaks olemit "Raamatukogu töötajad" ja "Laenutajad", siis on tõenäoline, et mõni töötajatest on ka laenutaja.
- Seosed on vajlikud selleks, et saaks lisada ühe olemitüübi nii-öelda atribuudiks teist olemitüüpi. Näiteks, kui on kaks olemitüüpi "Autod" ja "Margid". Võime mõelda, et mark on auto tunnus, aga kuna sama marki esineb paljudel olemitel, siis see tekitab andmeliiasust ja pigem oleks otstarbekas lisada margid eraldi olemitüübina ning siduda "Autod" ona "Margid". Sellega muutubki nagu olemitüüp "Margid" "Autode" olemi atribuudiks. Seostest räägib lähemalt selles peatükis hiljem ja seoste implementeerimist tutvustatakse relatsioonilise mudeli peatükis.
Andmebaasis kujutatakse olemeid tavaliselt tabelitena, kus tulpadeks on olemitüübi atribuudid. Seda tehakse ka Postgre SQLis. Tabeli iga rida kirjeldab olemit. Alloleval pildil on näha, milline näeks välja olem "Lauljad" tabeli kujul. Sellel olemitüübil on kolm olemit. Kusjuures, andmebaasis ei tohi ükski olem olla täiesti identne mõne teise olemiga.
Seega meenutavad olemitüübid andmebaasis Exceli tabeleid. Samas ei tohi neid kindlasti samaväärseks pidada. Näiteks andmebaasis saab atribuudi juurde salvestada ainult seda tüüpi andmeid nagu atribuut lubab. Seega kui oleme määranud, et andmetüüp on arv, siis ei saa tekkida tulpa, kus on salvestatud nii tekstilisi väärtusi kui ka arvulisi väärtusi.
Tihti aetakse segamini kaks terminit "atribuut" ja "andmed". Atribuut on olemit iseloomustav näitaja, mida saab mõõta ja vaadelda. Ülaltoodud näite puhul on atribuudiks nimi, sünniaeg, sugu ja ansambel. Andmeteks on aga konkreetsed väärtused nagu "Juhan Maasikas", "Anu Mustikas", "25.05.1990" jne.
Atribuutide nimetused peaksid olema võimalikult täpsed ja neid lugedes peaks saama koheselt aru, mis atribuudiga tegu on. See lihtsustab palju tulevikus andmebaasiga seotud tegevusi, st et andmebaasi haldav inimene ei pea minema alatasa dokumentatsiooni lugema ja vaatama, mida tähendab näiteks atribuut "a" või "b". Ka mõõtühik kirjutatakse atribuudi nimesse, sest kui on kirjas näiteks kaal, siis me ei tea, kas selles tulbas olevad arvud kirjeldavad kaalu grammides, kilogrammides või hoopis tonnides.
AVA TEST
Ärinõuete ja probleemi analüüs
Mudeli koostamiseks on vaja läbi viia ärinõuete ja probleemi analüüs. Analüüsi käigus tuleb selgelt ära sõnastada probleem, mida loodav andmebaas lahendama hakkab. Seda on kõige lihtsam teha, kui vestelda alguses tulevaste kasutajatega ja uurida neilt, mida nemad loodavalt süsteemilt saada tahaks. Vestluse käigus peaksid selguma detailsed nõuded, mida loodav andmebaas peab teha võimaldama. See tähendab, et kui kasutaja ütleb, et ta tahab näha statistikat, siis tuleks kindlasti uurida täpselt välja, millist statistikat ta näha tahab. Kõige lihtsam on panna probleem kirja küsimustena, millele peaks andmebaasist leidma vastused.
Samuti tuleb uurida kasutaja käest, millised on valdkonnas kehtivad reeglid. Näiteks kui koostada lõputööde andmebaasi, kas lõputööl võib olla üks või mitu juhendajat, üks või mitu autorit, kas üks inimene võib ka koostada mitu lõputööd ning kui jah, kas siis on võimalik ka samaaegselt seda teha.
Kui lahendatav probleem on selgelt ära sõnastatud ja ärinõuded on kaardistatud, siis saab teha ka ülevaate, mida andmebaas sisaldama peab. Nii saab teada mis olemitüübid on, mis on nende atribuudid e. tunnused ja kuidas olemid omavahel seotud on.
Näiteks, kui luuakse andmebaas lauluvõistluste jaoks, siis tõenäoliselt soovitakse seal hoida infot laulude, esinejate ja võistluste kohta. Ühegi lahendatava probleemi korral ei ole see loetelu üheselt määratud ja salvestama peaks sellist infot, mis on kohane just konkreetsele ülesandele. Tihti muutub see loetelu ka peale seda, kui andmebaas juba valmis on. Lihtsam on aga teha alguses korralik analüüs, et hiljem ei peaks olulisi muudatusi tegema. Seega on tähtis uurida ülesande tausta, siinkohal, kuidas lauluvõistlused täpselt toimuvad? Kas on võimalik, et riiki esindab mitu laulu? Kas võistlus saab korraga toimuda mitmes riigis? Kas riiki saab esindada mitu lauljat?
Olemite atribuutideks saavad mingid andmeväljad, mida on vaja, et rahuldada kasutajate soove. Näiteks lauljatel võivad olla atribuutideks: lavanimi, sünniaeg, sugu, ansambel ja sünniriik. Lauludel aga pealkiri, keel, kestus jne. Nende atribuutide abil saab pakkuda kasutajatele infot laulude ja lauljate kohta. Tunnuseid tuleks valida selle põhjal, mida tulevased kasutajad nõudnud on. Näiteks võib lauljate puhul lisada tunnuse "juuksevärv", aga kui ükski kasutaja selle info nägemist nõudnud pole, siis ei ole mõtet seda atribuuti ka andmebaasi lisada. Samuti tuleb kaaluda, mis on konkreetse olemitüübi puhul oleks otstarbekas kasutada. Inimesi iseloomustab ees- ja perenimi. Kui aga tegemist on lauljaga, siis paljud artistid kasutavad lavanime. Kui iseloomustame esinejat ees- ja perenime alusel, siis ei saa me lavanime ju lisada. Samuti ei saaks me lisada ansambleid.
Kui analüüsi tulemusena on leitud sobivad olemitüübid, siis tuleks neid omavahel võrrelda ja järgida järgmisi soovitusi:
- Olemitüüpe tuleks omavahel võrrelda ja otsustada, kas mõned neist saaks muuta üldisemaks, et ei tekiks andmete dubleerimist. Võib juhtuda, et mitmel olemitüübil on palju kattuvaid tunnuseid. Näiteks, kui sooviks salvestada andmebaasi lauljaid ja heliloojaid. Sellises olukorras võiks luua lauljatele ja heliloojatele ühise olemitüübi, sest tõenäoliselt paljud atribuudid neil kattuks. Samuti ei tekiks andmete dubleerimist, kui laulev helilooja on nii lauljate kui ka heliloojate olemitüübis. Selle kas konkreetne olem on laulule autoriks või esitajaks määrab ära nende vaheline seos. Võib olla ka mõlemat korraga.
- Kui mõnel olemitüübil on üksikuid kattuvaid atribuute, siis tuleks need tunnused esitada eraldi olemitüüpidena. Näiteks, olgu olukord, kus olemitüübil "Laulud" on atribuut nimega "riik", mis näitab, millist riiki antud laul esindab ja olemitüübil "Võistlused" on atribuut "riik", mis ütleks, mis riigis võistlus toimub. Sellises olukorras oleks mõistlik luua eraldi olemitüüp "Riigid" ja luua sellel seosed laulude ja võistluste olemitüüpidega.
Võtmed
Andmebaasis peaks olema iga olem identifitseeritav. See tähendab, et olemil peab olema selline tunnus või tunnuste komplekt, mille väärtused on kindlasti unikaalsed igal olemil. Sellist tunnust e. atribuuti või atribuutide komplekti kutsutakse võtmeks. Näiteks võib olla tudengi puhul võtmeks matriklinumber või isikukood, auto puhul auto registreerimisnumber, heliteosel autor ja pealkiri. Võtmeks ei saa aga olla inimese nimi, sünnikuupäev või keel, sest need ei ole unikaalsed väärtused, st et mitu olemit võib omada sama väärtust selle tunnuse puhul. Võtmeid on vaja ka selleks, et andmebaasis saaks tekitada seoseid olemite vahel. Selles peatükis tutvustatakse seoseid, aga seda, kuidas võtmete abil andmetes reaalselt seoseid luua, käsitletatakse relatsioonilise mudeli peatükis.
AVA TEST
Seosed
Kui olemitüübid on määratud, siis peab olema võimalik nende vahel ka seoseid luua. Seosed, nagu nimigi ütleb, seob olemeid omavahel mingi tegevusega. Näiteks laulud esindavad riiki ja laule esitavad lauljad. Kusjuures tasub ära märkida, et olemitüüp võib olla ka seoses iseendaga. Seda kutsutakse rekursiivseks seoseks. Näiteks võib osakond olla seotud osakonnaga (osakonna sees on väiksemad osakonnad).
Seoseid on kolme liiki:
- 1:1 seos
- 1:N seos
- N:M seos
Seoseid on lihtsam määrata, kui need lausetena kirja panna. Näiteks:
- Ühel riigil on üks lipp ja üks lipp kuulub ühele riigile. 1:1 seos
- Ühes riigis võib olla sündinud mitu lauljat ja iga laulja saab olla sündinud ühes riigis. 1:N seos
- Üks laulja võib esitada mitut laulu ja ühel laulul võib olla mitu esitajat. N:M seos
| << Sissejuhatus andmebaasidesse | ER mudeli loomise läbimäng >> |
| Relatsiooniline mudel >> |