Relatsiooniline andmebaasi mudel

Relatsioonilisele andmebaasi mudelile pani aluse E.F. Codd (IBM) juba 1970 aastal. Selle idee kohaselt koosnevad andmebaasid, mida tähistatakse skeemides silindrina, ühest või enamast tabelist (table).

Iga tabel koosneb omakorda veergudest (columns) ja ridadest (rows).

Andmebaasi loojana lood tabeli, mis koondab mingi asja kohta täpseid andmeid ja annad talle unikaalse kirjeldava nime. Näiteks Klient, Auto, Hinne, Õpilane, Patsient jne. Andmebaaside loomisel nimetatakse seda olemiks (entity) – reaalselt eksisteeriv ja identifitseeritav asi või nähtus. Vahel nimetatakse seda ka objektiks.

Pildilt on näha, et olen lisanud veergudele pealkirjad, et mida kuhugi tuleb lisada ning seda nimetatakse tunnuseks või atribuudiks (attribute). Lisatud ridu nimetame kirjeteks (records)

• Igal atribuudil on kindel väärtus (values), milleks võib olla number, tekst, kuupäev, pilt, heli, video jne.
• Andmebaasides on see määratud vastava andmetüübiga (data type).
• Atribuudid võivad olla kohustuslikud (mandatory attribute) või valikulised (optional attribute)

Võtmed

Kui me vaatame eelmist tabelit, siis me näeme, et veergu võivad sattuda ühesuguseid andmeid. Aga kuidas siis eristada patsiente teineteisest. Vastasel korral määrame valele patsiendile vale ravi. Selleks on tabelile vaja uut atribuuti unikaalse identifikaatorga (unique identifier, UID). Inimeste puhul võib selleks olla isikukood, ID-kaardi number vms. Aga mis saaks kaupadest või teenustest? Sel juhul saab tekitada numbri, mis iga kirje puhul on ühe numbri võrra suurem.

Andmebaasides nimetatakse olemi eksemplari unikaalset tunnust võtmeks (key).

Nagu näeme, siis ühel olemi eksemplaril võib olla mitu võtit ja sellepärast määratakse kõige olulisem ehk primaarvõti (primary key). Ja kõiki teisi võtmeid nimetatakse sõbralikult võtmekandidaatideks (candidate key).

Seosed

Vaatame sama Patsient tabelit (olem) ja tahaksime juurde lisada uue atribuudi vaktsineerimiste kohta. Seni kuni kõik patsiendid piirduks ühe vaktsineerimisega, poleks probleemi. Aga kui ta on saanud rohkem vaktsiine? Lisaksime kõik andmed ühte lahtrisse?

See poleks mõistlik, sest sellise info töötlemine on keeruline. Teeme atribuute juurde? Aga nii tekiks liiga palju tühje lahtreid ja seegi pole hea mõte.

Parim lahendus on teha vaktsiinidest uus tabel (olem). Lõime andmed nüüd kaheks aga kuidagi oleks vaja nüüd need omavahel siduda. Andmebaasi loomises räägime siis seosest ehk suhtest (relationship). Suhteid on olemuselt kolm:

• üks-ühele (one-to-one) – tabeli kirjele saab vastata ainult üks teise tabeli kirje. Näiteks saab mees abielluda ainult ühe naisega… hetkel :)
• üks-mitmele (one-to-many) – kõige levinum seos, kus ühele kirjele saab vastata mitu kirjet. Vastupidi ei ole lubatud. Näiteks emal võib olla mitu last, aga lapsel ainult üks ema. Või näiteks klassi võib kuuluda mitu õpilast aga õpilane saab kuuluda ainult ühte klassi.
• mitu-mitmele (many-to-many) – palju seoseid on lubatud mõlematpidi. Näiteks poe arvel saab olla mitu toodet ja toodet saab lisada mitmele arvele. Või näiteks töötaja saab olla mitmes osakonnas ja osakonnas saab olla mitu töötajat. Mitu-mitmele seose puhul ei saa luua otse seost. Selle jaoks tehakse vahetabel

Mõni lisab siia ka neljanda seose, kus seost üldse pole.

Kuidas teada, milline suhe on, siis soovitan tõmmata jooni. Siis on näha, kuidas suhe peaks tekkima. Hetkel saan tõmmata jooni mõlemat pidi, seega saame öelda, et tekkis mitu-mitmele seos.

Seoseid saab luua läbi ühe tabeli primaarvõtme, mida uues tabelis nimetatakse välisvõtmeks (foreign keys). Mitu-mitmele seose puhul peame tekitama uue vahetabeli.

Antud seosest on näha, et millist vaktsiini on milline patsient saanud. Teeme ühe näite veel. Lisame perearsti tabeli ja seome selle patsiendiga. Kuna lubatud on ainult üks perearst patsiendi kohta, saame luua üks-mitmele seose.

Transaktsioonid

Tahan viidata veel ühele olulisele mõistele nagu transaktsioon. Nimelt, kui on vaja lisada või muuta andmebaasi kirjeid, siis on oluline, et need saaks tehtud. Kui tekib vähemalt üks probleem, siis katkestatakse kogu tegevus. Isegi kui tegevus eeldab näiteks 10 rea lisamist ja kuskil on mingi jama, siis ülejäänud üheksa jääb lisamata. Kuid see pole ainuke reegel. Transaktsiooni kontrollitakse ACID test abil:

• Atomicity – andmebaasitehingu jagamatus (atomaarsus). Tehingu mingi osa nurjumine tähendab kogu tehingu nurjumist, st andmebaasi olek jääb endiseks ja andmete terviklus on tagatud.
• Consistency – järjekindlus, väljendub selles, et iga tehing viib andmebaasi ühest lubatavast olekust teise, st kõik andmebaasi lisatavad andmed vastavad ettemääratud  kehtivusnõuetele
• Isolation – isoleeritus ehk reguleeritakse üheaegset andmete muutmist
• Durability – püsivus ehk garanteeritakse tehtud muudatuste püsimajäämine