ANDMEHALDUS JA ANDMEBAASID

Andmed ja modelleerimine

Andmete abstraktsioon ja vaatetasemed

Abstraktse andmetüübi all mõistetakse andmehulkade määratlusi ja nende andmetega teostatavate operatsioonide hulka. Andmetüüp on abstraktne, kuni ta pole seotud mingi konkreetse rakendusega, mis neid andmeid kasutab.

Andmete haldusprobleemid võib jagada kolmeks: salvestamine, modelleerimine ja juurdepääsemine. Juhtimise keerukust võib vähendada vaadeldes neid erinevaid aspekte eraldi. Selle eesmärgi saavutamiseks on kolmemõõtmeline mudel, mis eraldab füüsilise vaate, loogilise vaate ja kasutaja vaate saavutanud üldise tunnustuse.

Füüsiline vaade (physical level) tegeleb andmete salvestamise viisidega. Seda võib lihtsalt saavutada, delegeerides selle ülesande operatsioonisüsteemi failihaldussüsteemile või otsese ja optimaalse kettaseadmete haldusega.

Loogiline vaade (conceptual level) käsitleb, kuidas informatsioon struktureeritakse, defineerides seosed andmete vahel.

Kasutaja vaade (view level) käsitleb kasutajate juurdepääsu infole nii võimalike operatsioonide kui ka kasutajale kuvatava info struktuuri kontekstis. Lihtsamate rakenduste puhul võib see suuresti sarnaneda loogilisele vaatele, kuid kasutajamugavuse huvides saab kasutajavaadet vajadust mööda kohandada.

Nimetatud kolm vaadet on üksteisest sõltumatud ja võivad olla hallatavad erinevate isikute või subjektide poolt, muutes sellise käsitluse suhteliselt efektiivseks. Füüsiline vaade, näiteks on hallatav ABHS poolt ja kuulub seetõttu ABHS projekteerijate vastutusvaldkonda. Iga ABHS teostus põhineb igal konkreetsel juhul kompromissil teostuskiiruse, maksumuse ja stabiilsuse vahel. Loogilise ja kasutaja vaate teostus on otsustamise seisukohalt rohkem standardne, võimaldades andmebaasi projekteerijatel struktureerida andmebaasi vastavalt aja ja rakenduse nõuetele. [5]

Lisamaterjal abstraktsete andmete kohta [wikipedia.org]

Andmemudelite grupid

Levinumad andmemudelite grupid on objektipõhine loogiline mudel, kirjepõhine loogiline mudel ja füüsiline andmemudel.

Andmehalduses on kasutusel erinevaid mudeleid, mis erinevad üldistuse (abstraktsiooni) poolest alates füüsilistest andmetest kirjete mudeli suunas kuni objektimudelini. Füüsilised mudelid on piiratud andmete füüsilise esitluse arvesse võtmisega.
Füüsiline andmemudel tegeleb andmete projekteerimisega, mis arvestab konkreetse keskkonna (andmebaasiprogrammi arvuti) ja andmebaasihaldussüsteemi enda võimalustega.
Kirjetel põhinevad kirjemudelid kasutavad tavalist arhiveerimise praktikat, salvestades informatsiooni failides, mis koosneb kirjetest.
Objektidega seotud suurem üldistustase põhineb sõltuvusseostega seotud andmeobjektide (ühikute) eristamisel.

Lisamaterjal andmemudelite ja andmete modelleerimise kohta [wikipedia.org]

Kirjepõhiste hierarhilise andmemudeli ning võrkmudeli kirjeldus

Kirjepõhine loogiline mudel on sarnasem arhiveerimistegevusele, mida kasutati enne arvutiseerimise ajajärku. Võrreldes ER mudeliga, on kirje samaväärne olemiga, mis tagab, et ta esindab sama objektiga seotud informatsioonigruppi. Kui ER mudelis seda informatsioonigruppi kutsutakse atribuudiks (omaduseks), siis siin on tema nimi andmeväli (field). Erinevus on filosoofiline, kuna ER mudel teeb üldistuse defineerides olemi ja atribuudid.

Teine erinevus on viisis, kuidas suhteid (seoseid) defineeritakse ja hallatakse.

Esimene mudel on hierarhiline andmemudel, milles suhted on hierarhilised. Neid suhteid realiseeritakse viitade kaudu. Näiteks kirjes, mis defineerib töötaja on viide kirjete ahelale, mis sisaldab andmeid selle töötaja palgapaketist (või töötasustamise tingimustest), millises omakorda on viide väljamaksetele.

Selline skemaatiline lähenemisviis on jäik vaatamata oma lihtsusele, kuna sisemised piirangud tulenevad lihtsusest.

Võrgupõhine andmemudel, mis sisaldab paljude kirjete hulgas palju ristviiteid, loob tegeliku võrgustiku, mis on sarnane lingitud veebilehtedele, on veidi väiksema jäikusega. Võrgumudeli piiranguks või probleemiks on andmete uuendamisel uuendamist vajavad ristviidete haldamise raskused. Ilmselgelt tasakaalustab seda piirangut mitmete ristviidete suurem paindlikkus, mis omakorda võimaldab palju kiiremat kirjetevahelist navigeerimist, kui hierarhiline mudel.

Enamate mudelite olemasolu on põhjustanud erinevate nimede kasutamist sarnastele, kuid mitte identsetele põhimõtetele: seetõttu on võimalik kohata ABHS tooteid, milliseid endiselt kutsuvad ridasid kirjeteks, veergusid (või veergude ja ridade ristumiskohti) väljadeks ja üht unikaalset tunnust primaarvõtmeks (kasutatakse samu termineid, mis olem-seos mudeli korral). [5]

Objektipõhine loogiline mudel

Objektipõhised loogilise mudelid on olemi-seosemudel ja objektorienteeritud mudel.

Esimene objektidega seotud mudel sai nimeks olemi-seosemudel või objekti-seosemudel. (entity/relationship (E/R) model). Mudel algab objekti (olemi, andmeühiku) määratlusega. Näiteks personalihalduse kontekstis oleks objektiks või andmeühikuks töötaja. Objektidegruppi (ettevõtte töötajad) nimetatakse objektide hulgaks või andmeühikute hulgaks (entity set). Igat objekti iseloomustavad atribuudid ehk omadused (attributes), millised teda kirjeldavad. Töötaja omaduseks (atribuudiks) on näiteks tema töölevõtmise kuupäev. [5]

Konkreetse objektide või andmeühikute eristamiseks hulgas kasutatakse võtit, milleks on on üks objekti omadus. On olemas erinevaid võtmeid, kuid kõikide nende ülesandeks on objekti unikaalne eristamine objektide hulga sees.

Esimene võtmetüüp on nn.supervõti (superkey). Supervõti koosneb mitmest omadusest, mis muudab ta ülikülluslikuks, arvestades tema eesmärki. Supervõtme näiteks võiks olla omadustegrupist "kontonumber", "büroo nimetus" ja "sugu" koosnev võti. Kuna isiku kontonumber iseenesest on piisav isiku määratlemiseks, siis selline võti ongi ülikülluslik.

Võtme, mis võimaldab objekti üheselt määratleda ilma omaduste ülemäärase kasutamiseta, võib supervõtmest eraldada ja ta muutub primaarvõtme (primary key) kandidaatvõtmeks (candidate key). Ülaltoodud näites toodud kontonumber oleks hea kandidaatvõtme näide.Kui kandidaatvõtmeid on rohkem, kui üks, siis valitakse neist üks primaarvõtmeks. Töötaja näitel konstrueeritakse primaarvõti hoopis omadusest "töötaja number", sest ettevõtte sees on see omadus nagunii unikaalne ja iseloomustab töötajat rohkem, kui kontonumber, milline on aga parim primaarvõti pangaklientide eristamiseks.

Seos, suhe või sõltuvus on link, mis loob loogilise seose objektide või objektide hulkade vahel. Näiteks on ettevõttes olemas seos töötajate hulga ja nende töötasupakettide vahel. Igat suhet kirjeldatakse omaduste grupiga. Eeltoodud näite puhul võib töötasupaketi ja töötaja vahelise seose omadusteks olla töötaja number, kuu number ja aasta number. Kaks seosega lingitud omadust võivad olla eritasandilised, näiteks üks on valitsev (dominant) ja teine alluv (subordinate). Toodud näitest on töötaja number valitsev, sest ei saa maksta palka, kui pole töötajat. On muidugi ka vastupidine võimalik, sest töötasu palga näol ei maksta reeglina enne, kui töötaja on kuu aega töötanud.

Kardinaalsus on seose või suhte oluline omadus ja ta määratleb, milline on seotud andmeväljade vastavus. Suhe töötaja ja töötasupaketi vahel on „üks-mitmega" tüüpi, mis näitab, et üldisele töötajale vastab mitu töötasupaketti. Suhe, mis seob töötasupaketi suhtelise väljamaksega on „üks-ühene" seos, mis näitab, et töötasupakett peab vastama ühele ja ainult ühele väljamaksele (konkreetse isiku palgasumma).

Eraldi peaks vaatama „nõrku olemeid" ("weak entities") või olemeid, millistel puudub oma primaarvõti. Selliste olemite näiteks võib tuua pangadeposiidi, mille atribuudid on kogus (summa) ja kuupäev/kellaeg ehk ajatempel (timestamp). Pole võimalik määratleda primaarvõtit, kuna erinevad inimesed võivad teha samasuure hoiuse samal ajahetkel. Õigemini see olem omab mitu-ühega sõltuvust koos olemiga, mis kajastab pangkonto numbrit, millisele hoius paigutati, mis omakorda on konto primaarvõtmeks. Hoiuse primaarvõti koostataksegi atribuutidest hoiuse ajatempel ja olemi "konto" kontonumber.

Olemi-seosemudel on esimene ja kõige laialdasemalt kasutatav mudel, kuid ta pole ainuke loogiline mudel, sest objektorienteeritud keelte pealetungiga on ka objektorienteeritud andmebaasid (object-oriented databases (OODB, vastav eestikeelne lühend võiks olla OOAB)) laialt levinud. OOAB mõiste on tuletatud kasutades objektorienteeritud programmeerimise põhimõtteid koos andmete haldamise ja salvestamise võimega. OOAB kasutatakse andmehalduses keerukamate andmestruktuuride korral, kus ei piisa ainult omaduste loetelude haldusest, vaid kus on vaja sooritada salvestatud andmetega seotud tegevusi või toiminguid. [5]

OOAB üldpõhimõtted on samad, mis objektorienteeritud programmeerimisel:

• abstraktsioon ehk üldistus - omadus kirjeldada objektide funktsionaalseid külgi ja vältida tähelepanu pööramist detailide sisemisele teostusele
• kapseldus (encapsulation) või võime eraldada välised aspektid (funktsionaalsus) sisemisest esitlusest, kuna see pole ülemiste rakenduse kihtide seisukohalt oluline, on ta maskeeritud.

Mõlemad toodud aspektid võimaldavad selgitada (kasutada) abstraktse andmetüübi (abstract data types (ADT)) mõistet.

Objekte iseloomustavad atribuudid (andmed) ja tegevused (kuidas objekte on võimalik manipuleerida). Näiteks "tekst" tüüpi objektil on võimalik defineerida teksti lisamise operatsioon tekstide liitmise teel või mingi lõigu otsimine sellest tekstist. Sarnaselt olemite või olemite hulkadega, võib objekt kuuluda objektide klassi. On samuti võimalik määratleda, et objektid on ainsad klassi eksemplarid (või esindajad), mis esindavad mingit tuntud rakendust. Igal objektil on oma tunnus (OID - object identifier), mis on unikaalne kogu süsteemi ulatuses ja mis kujutab endast viidet objektile enesele.