Relatsiooniline mudel
Mis on relatsiooniline mudel?
Relatsiooniline mudel saadakse ER mudelit teisendades järgides kindlat algoritmi. See mudel ei ole enam ettekujutus andmebaasist, vaid väljendab seda, milline meie andmebaas lõpuks täpselt välja näeb. Võrreldes ER mudeliga lisandub relatsioonilisse mudelisse primaarvõtmed, välisvõtmed ja atribuutide andmetüübid. Lisanduvad ka seoste tabelid juhul, kui tegu on mitu mitmele seosega. Alloleval skeemil on näha relatsioonilise mudeli näidist. Relatsiooni võib ette kujutada tabelina ning neid kahte mõistet võib siinkohal sünonüümideks pidada. Selles peatükis tutvume, mida tähendavad erinevad märgistused antud skeemil ja kuidas sellist mudelit luua.
Andmetüüpide määramine
Relatsioonilist mudelit luues määratakse ära tunnustele nende tüübid. Eelmises peatükis sai mainitud ka juba kahe tunnuse andmetüüpi. Tunnuse "finaalis" ja "ansambel" puhul oli selleks BIT. Seega nende puhul võib olla väärtusteks ainult 0 või 1, mis sümboliseerivad siis väärtusi false ja true.
Andmetüüpe tuleks hoolega määrata, sest hiljem, kui andmebaas juba valmis on tehtud, siis on neid keeruline muuta. Andmetüübi valik ei ole aga alati lihtne. Näiteks, mis on isikukoodi andmetüüp? Kuna see sisaldab ainult numbreid, siis võiks arvata, et tegu on täisarvuga, aga tegelikkuses tuleks sellele panna tüübiks VARCHAR. Seda sellepärast, et isikukood on küll üks pikk arv, aga sellega ei tehta kunagi arvule omaseid operatsioone nagu liitmine, lahutamine jne. Seega tuleks mõelda, mida selle tunnuse väärtused sümboliseerivad? Kas nendega peaks saama mingeid operatsioone teha ja milliseid? Mis võivad olla selle kõik võimalikud väärtused praegu ja tulevikus? Kui suureks või pikaks võivad väärtused minna? Kui leida nendele küsimustele vastused ja olla tutvunud erinevate andmetüüpidega õpiku esimeses peatükis, siis peaks olema tüüpide määramine lihtne.
AVA TEST
Mis oli võti?
Võtmeks kutsuti atribuuti või atribuutide komplekti, mille väärtused olid igal olemil unikaalsed. Selleks võis olla ka süsteemi poolt automaatselt genereeritud ID tunnus. Võtme kaudu on võimalik pärida antud olemi kohta ka ülejäänud info. Näiteks, kui riikide olemitüübis on võtmeks riigi_nimi, siis saab alati pärida riigi nimega ülejäänud info, mis käib selle riigi kohta. Kunagi ei saa vastuseks olla mitme riigi andmed, sest võti, ehk riigi nimi, peab olema unikaalne, st et sellele vastab tabelis ainult üks rida.
Nõrk ja tugev olem
On ka lubatud olukorrad, kus võti puudub. Neid olemeid kutsutakse nõrkadeks olemiteks. Tugevad olemid on kõik ülejäänud, ehk need, millel on võti. Nõrkade olemite loomisega on aga paar tingimust. Esiteks neid ei tohiks luua palju, vaid nii vähe kui võimalik. Lisaks sellele peab olema see nõrk olem seotud mingi tugeva olemiga, millel on võti. See on tarvilik selleks, et iga nõrga olemi eksemplar oleks siiski identifitseeritav, kui arvestada seotud tugeva olemi võtit + mõnda nõrga olemi enda tunnust. Nõrka olemit on võimalik siduda tugeva olemiga ainult eksistentsiaalselt, st et kui kustutada ära andmebaasist tugeva olemi eksemplar, siis kustuvad ka sellega seotud nõrga olemi eksemplarid.
Näiteks kujutame ette olukorda, kus firma hoiab iga töötaja laste kohta infot, et osata teha neile jõulupakke. Sellises olukorras on tugev olem "Töötajad" ja temaga on seotud nõrk olem "Lapsed". Töötajatel on mingisugune tunnus võtmeks nagu näiteks "isikukood", aga laste puhul, ei ole vaja isikukoodi salvestada. Ettevõtet huvitab ainult see, mis on laste nimed, sugu ja kui vanad nad on. Seega lapsel võti puudub, aga olemi eksemplarid on siiski identifitseeritavad näiteks tunnuste komplektiga lapsevanema_isikukood + lapse_nimi. Seda muidugi eeldusel, et ühe pere vanemad ei pane oma lastele identseid nimesid. Kui vanem lahkub ettevõttest ja eemaldatakse töötajate hulgast, siis kustuvad andmebaasist automaatselt ka tema laste kirjed.
Primaarvõti ja välisvõti
Primaarvõtmete ja välisvõtmete puhul kasutatakse tihti ka lühendeid PK (primaarvõti/primary key) ja FK (välisvõti/foreign key). Neid kasutatakse ka näite skeemidel.
Nagu eelmises peatükis öeldud, siis võtmega on identifitseeritav iga olem. Seda kutsutakse relatsioonilises mudelis primaarvõtmeks. Näiteks relatsioonis "Riigid" võib olla primaarvõtmeks tunnus "nimi", sest mitut ühesuguse nimega riiki ei eksisteeri.
Välisvõtmeks on relatsioonides mingi teise relatsiooni primaarvõtmed. Nende abil luuakse seoseid relatsioonide vahel ja ühel relatsioonil võib olla ka mitu välisvõtit. Selle tulemusel peaks olema igal relatsioonil vähemalt üks võti. Olgu see siis kas primaarvõti, välisvõti või mõlemad.
Tasub ka tähele panna, et kui mingi relatsiooni primaarvõti lisada teise relatsiooni külge välisvõtmeks, et luua nende vahel seos, siis selle primaarvõtme ja välisvõtme andmetüüp peab olema kindlasti sama. Nad siiski ju sisaldavad täpselt samu väärtusi.
Selleks, et paremini aru saada, kuidas see täpselt käib vaatleme iga seose tüübi kohta näidet. Järgnevates näidetes on kasutatud võtmena süsteemi enda poolt automaatselt genereeritud võtmeid.
1:1 seose implementatsioon
Kuna Eurovisiooni mudelis ei eksisteeri 1:1 seoseid, siis siinkohal kasutab uusi väljamõeldud relatsioone. Oletame, et meil on kaks relatsiooni "Tudengid" ja "ÕIS Kontod". Tudengil on tunnusteks "ID" ja "Nimi". ÕIS kontodel on tunnusteks "ID", "Kasutajanimi" ja "Parool". Nende kahe relatsiooni vahel on 1:1 seos, sest igal tudengil võib olla üks kasutaja ja iga kasutaja kuulub ühele tudengile.
Selleks, et realiseerida 1:1 seost, on vaja valida suvaliselt üks nendest relatsioonidest ja lisada selle primaarvõti välisvõtmeks teisele relatsioonile.
Seega üks võimalus on seos implementeerida järgnevalt:
Ja teine võimalus:
1:1 seose korral on ka mõistlik kaaluda, kas eraldi kahte relatsiooni on vaja või võib need liita, et oleks lihtsam teha päringuid. Sellisel juhul oleks:
1:N seose implementatsioon
1:N seose implementeerimiseks lisatakse N poolsesse relatsiooni välisvõti. Vaatleme relatsioone "Riigid" ja "Lauljad", kus on 1:N seos ehk igas riigis võib sündinud olla mitu lauljat, aga iga laulja saab sündinud olla ainult ühes riigis. Relatsioonide vahel luuakse seosed sellisel juhul nii, et relatsiooni "Lauljad" lisatakse üks lisa tunnus. Selle võimalikud väärtused on relatsiooni "Riigid" primaarvõtme väärtused. Näiteks võib selleks tunnuseks olla "Synniriik_ID", see ongi laenutuse välisvõti nüüd. Alloleval skeemil on välja toodud ka üks võimalik andmete seis antud relatsioonides. Läbi tunnuse "Synniriik_ID" (välisvõti) on võimalik leida üles riik, kus see laulja on sündinud. Nagu näha siis iga riik saab olla seotud mitme lauljaga, aga iga laulja saab olla seotud ainult ühe konkreetse riigiga. Lisaks kui mingil põhjusel peaks ühe riigi pealinn muutuma, siis on vaja see väärtus ära muuta ainult ühes kohas, sest lauljate sünniriike vaadatakse läbi riigi ID ja see jääb samaks.
Oletame, et sooritati järgmine päring: "Mis on laulja sünniriik, kelle ID on 2?". Sellisel juhul otsitakse esialgu relatsioonist "Lauljad" üles laulja, kelle ID on 2. Sellise ID-ga on selles näites laulja nimega "Mustu". Sooviti teada tema sünniriiki ja seetõttu vaadatakse järgmise sammuna selle laulja tunnust "Synniriik_ID". Selgub, et tegu on on välisvõtmega, mis loob seose relatsiooniga "Riigid". Sünniriigi üles leidmiseks võetakse see välisvõtme väärtus ja otsitakse üles relatsioonist "Riigid" riik, mille primaarvõtme väärtus on võrdne antud laulja sünniriigi väärtusega. Selleks riigiks on Soome.
N:M seose implementatsioon
N:M seose implementeerimisel luuakse uus seose relatsioon, kus on mõlema relatsiooni primaarvõtmed välisvõtmetena. Vaatleme nüüd relatsioone "Laulud" ja "Lauljad". Laul ja laulja on mitu mitmele seoses ehk N:M, sest laulul võib olla mitu lauljat ja laulja võib olla laulnud mitut laulu (eri aastatel). Alloleval näitel on näha tabelitest, et on juurde tehtud üks vahetabel/relatsioon "Esitamised", mille abil saab seostada mitut laulu lauljaga ja vastupidi. Esiteks on näha, et laul "Tuletorn" on esitatatud Maasu ja ja Varx'i poolt. Teisalt on näha ka, et Mustu esitas nii laulu "Roosiaed" kui ka "Torm".
Soovi korral saab ka uuele relatsioonile lisada juurde uusi tunnuseid nagu näiteks "Esitamise aeg".
Oletame, et sooritame järgmise päringu: "Kes laulsid laulu, mille nimi on "Tuletorn?". Sellise päringu puhul vaadeldakse seose relatsiooni ja otsitakse üles kõik read, kus on tunnuse "Laul_ID" väärtus võrdne laulu "Tuletorn" ID-ga. Selleks on teine ja kolmas rida. Nende puhul võetakse "Laulja_ID" väärtused ja otsitakse üles relatsioonist "Lauljad" lauljad, kelle ID on sellega võrdne. Selle tulemusel leitakse, et laulu "Tuletorn" esitasid Maasu ja Varx.
Analoogne arutelu toimuks ka kui me sooviks teada, milliseid laule on esitanud laulja nimega Mustu. Praeguse näite puhul on nendeks laulud nimega "Roosiaed" ja "Torm".
AVA TEST
Alamtabelid ja ülemtabelid
Kui tekitada seos kahe relatsiooni vahel, lisades ühe relatsiooni primaarvõtme välisvõtmeks teisele relatsioonile, siis kutsutakse ülemtabeliks primaarvõtmega relatsiooni ja alamtabeliks välisvõtmega relatsiooni. Kui kujutada neid seoseid relatsioonilises mudelis, siis on nii, et nooled lähevad alati välja alamtabelitest suunaga ülemtabelisse. Terminid tulenevad seoste omadustest. Vaatleme uuesti ülal toodud näidet.
Siin näites on ülemtabeliks "Riigid" ja alamtabeliks "Lauljad". Seose omaduste tõttu, kui muuta riikide tabelis näiteks nimi "Eesti" nimeks "Eesti Vabariik", siis muutub see automaatselt ka lauljate juures. See tähendab, et kui enne oleks pärinud Maasu sünniriigi nime, siis oleks väärtuseks olnud "Eesti", aga nüüd on selle väärtuseks "Eesti Vabariik". Seega selle seose juures on tabel "Riigid" nii-öelda ülem, sest seal andmeid muutes, muutuvad ka need väärtused lauljate puhul, kuigi lauljate tabelis muudatusi ei tehta. Vastupidi aga see ei kehti. Lauljate juures mingeid andmeid muutes ei muutu väärtused riikide tabelis.
AVA TEST
Relatsioonilise mudeli loomise algoritm
Loogilise mudeli teisendamine relatsiooniliseks mudeliks käib algoritmi järgi:
1. Samm
2. Samm
3. Samm
4. Samm
5. Samm
6. Samm
| << Loogiline mudel | Relatsioonilise mudeli loomise läbimäng >> |
| Andmebaaside administreerimine >> |