Loeng 11 · Andmete (info) roll infosüsteemis

Eesmärk

Andmestruktuuride projekteerimise küsimus infosüsteemi tasandil on väga oluline ja mahukas. Informaatika osakonnas on pühendatud sellele eraldi kursus, IFI 6013 Andmebaaside projekteerimine. Käesolevas loengus vaatleme infosüsteemi andmete küsimusi peamiste mõistete ja põhimõtete tasandil, arvestades kuulajatega, kes ülalnimetatud kursust ei ole läbinud või ei läbi. Infosüsteemide arendusega tihedamalt kokkupuutuval inimesel on andmebaaside projekteerimise kursus praktiliselt vajalik.

Töötlus ja andmed

Töötlus (processing) ja andmed (data) on igasuguse infotöötluse kaks peamist, teineteisega lahutamatult seotud külge. kumb on tähtsam? eraldiseisva programmi kirjutamisel on töötlus sageli olulisem kui andmestruktuurid. programmeerimisel läheb põhiline osa tööst sageli andmeid teisendavate lausete ehk töötlusalgoritmi formuleerimisele. andmestruktuurid luuakse ja täiendatakse algoritmi väljatöötamise käigus. kuid selline suhe ei kehti kõigi programmeerimisülesannete juures. mõnikord on otstarbeka andmestruktuuri leidmine küllaltki raske, näiteks siis, kui andmete maht võib kujuneda suureks ning selle tõttu on vaja lahendada andmestruktuurile kiire juurdepääsu küsimus. samuti võib andmestruktuuri projekteerimine olla raskendatud kui andmete koosseis on dünaamiline (kiirelt muutuv või suure muutuste diapasooniga).

Infosüsteemi tasandil on töötluse ja andmete proportsioon sageli vastupidine. infosüsteemis on andmestruktuurid (infostruktuurid) sageli ”tähtsamad” ja töömahukamad kui nende andmete töötlusoperatsioonid.

Miks? peamine põhjus on tänapäeva infosüsteemidesse hõivatavate andmete suur maht ja keerukus.

Näiteks, väikese kaupluse kaubanomenklatuur võib koosneda tuhandetest ühikutest, mis kuuluvad sadadesse või tuhandetesse erinevatesse tüüpidesse. võimalik on ka see, et iga kaubaartikkel on unikaalne. kõik need erinevad kaubad tuleb kaupluse müügi- või laosüsteemis adekvaatselt registreerida. kaupadega tehtavaid operatsioone on aga suhteliselt väike arv, tõenäoliselt paarikümne ringis:

uue kaubatüübi kasutuselevõtmine

kauba lattu sissevõtmine

kauba müük

kauba tagastamine

kauba mahakandmine

valesti arvelevõetud kauba andmete korrigeerimine

kaubatüübi nimekirjast kustutamine

päringute tegemine laoseisude kohta

päringute tegemine müügi kohta

päringute tegemine lattu sissevõtmise kohta

jt.

Andmebaas – infosüsteemi süda

Väga oluliseks nähtuseks on andmetüüpide tavaliselt suhteliselt suurem stabiilsus töötlusoperatsioonide tüüpidega võrreldes. Lihtsustatult öeldes – andmete struktuur on enamasti stabiilsem (muutub harvemini) kui andmeid töötlevad programmid.

Näiteks, ehitusfirma võib kasvada ja arendada oma tööprotsesse, lisada oma infosüsteemi uusi võimalusi. Kuid ehitusmaterjalide kirjeldamine ettevõtte infosüsteemis ei tarvitse nendest muudatustest mõjutatud olla. Kaubandusettevõte võib laieneda ühest müügikohast mitme müügikohaga ettevõtteks või isegi kaupluste ketiks. Kuid kaubaartikleid kirjeldavad andmestruktuurid ettevõtte infosüsteemis ei tarvitse sellest muutuda.

See põhimõte on infosüsteemi väljatöötamisel väga oluline. Infosüsteemi projekteerimisel tuleb andme- (info-)struktuuridele pöörata väga tõsist tähelepanu. Hästi projekteeritud andmestruktuurid on süsteemi õnnestumisel üheks peamiseks teguriks. Püüelda tuleb stabiilse, tervikliku, hästi kasutatava, multifunktsionaalse andmestruktuuride kogumi (andmebaasi) poole.

Andmestruktuuri stabiilsus tähendab seda, et kirjeldatava objekti praktiliselt kõik olulised omadused (atribuudid) ja olulised seosed teiste objektidega on süsteemi projekteerimisel üles leitud, õigesti mõistetud ja andmestruktuuride kirjeldamise vahendite abil modelleeritud. Näide: Millised atribuudid on müügioperatsioonil? Müüdava kauba nimetus, müügi kuupäev – kas nendest piisab? Oluliste atribuutide kooslus sõltub kaupluse tööprotsessist, praktikast. Süsteemi analüüsi ülesanne on olulised atribuudid välja selgitada. Tihti esineb müügioperatsioonide juures erisusi. Näiteks, kaup võis olla veaga ja seda tuli kas kohapeal või hiljem parandada; või tehti allahindlust. Asju ”üldiselt” vaadates võib tegevus tunduda lihtne ja oluliste atribuutide hulk selge; kuid praktika on alati keerulisem.

Miks on andmestruktuuride stabiilsus oluline? Andmestruktuuri muutus juba töötavas süsteemis võib olla väga kulukas, seda nii programmide ümbertegemise kui ka andmete konverteerimise tõttu.

Andmestruktuuri terviklikkus (katvus) tähendab seda, et kõik olulised objektid on kirjeldatud (modelleeritud).

Andmestruktuuri kompaktsus on samuti väga oluline. Infosüsteemis hoitavatele andmetele tuleb leida selge, nn. normaliseeritud (minimaalsetele osastruktuuridele viidud) esitus. Näiteks, kinnisvara andmebaasis võib olla oluline paljude spetsialiseeritud atribuutide kasutusele võtmine, et kergendada kinnisvaraobjektide otsimist mitmete omaduste järgi.

Andmestruktuuri multifunktsionaalsuse all peame silmas seda, et objekti kirjeldus peab võimaldama objektiga teha kõiki reaalselt võimalikke operatsioone. Näiteks, kauplus võib jamüügi kõrval hakata tegelema ka hulgimüügiga (kaupade müügiga teistele kauplustele). Sellest tulenevad ilmselt muudatused kaupluse infosüsteemis – lisatakse hulgimüügi funktsionaalsus. Hästi projekteeritud andmebaasi korral saame hulgimüügi funktsionaalsuse lisada ilma andmestruktuure oluliselt ümber tegemata. (Jae- ja hulgimüük on ju paljuski sarnased).

Projekteerimine tulevikku arvestades

_ Hästi projekteeritud andmestruktuurides on andmete võimalikke kasutusi ka tulevikus ette nähtud _ . Andmestruktuure tuleb projekteerida mitte kitsalt, ainult hetkel teadaoleva funktsionaalsuse (programmidega realiseeritava töötluse) jaoks, vaid laiemalt, võttes võimaluse korral arvesse kõiki tulevikus võimalikke kasutusi. Miks? – Sest enamasti on kokkuvõttes odavam teha alguses rohkem tööd ja vältida hilisemaid muudatusi andmestruktuurides.

Andmete tsentraliseerimine

Üldiseks põhimõtteks on ühe andmeüksuse hoidmine ainult ühes kohas. Teiste sõnadega, andmete dubleerimist tuleb üldjuhul vältida.

Ebaefektiivne – andmed on mitmes eksemplaris ja vajavad koordineerimist:

Efektiivne – andmed on ühes eksemplaris:

Andmebaas

Andmete tsentraliseerimise põhimõte (dubleerimise kõrvaldamine, koondamine füüsiliselt ühte kohta) leiab kõige täielikuma väljenduse andmebaasis. Andmebaasiks võib praktikas nimetada ka üldse igasugust terviklikku, süstematiseeritud andmekogumit, eelkõige aga siiski spetsiaalse tarkvara – andmebaasitarkvara (DBMS Data Base Management System) abil hoitavat ja hallatavat andmekogumit. Väga sageli on infosüsteemis andmete peamiseks paigutuskohaks üks, tsentraalne andmebaas, mille andmetele kasutajad pääsevad ligi rakendusprogrammide ja klienditarkvara (klient s.o. andmebaasi peale ehitatud tarkvararakenduse poolt teenindatav kasutaja) abil. Suuremates süsteemides võib olla kasutusel mitu andmebaasi. Tihti ka veebisüsteemides, mis kasutaja vaatepunktist võivad näida lihtsa veebilehtede kogumina, on kasutusel andmebaas. Sellisel juhul veebilehti valmiskujul ei säilitata, vaid genereeritakse andmebaasis olevate andmete põhjal, vastavalt kasutajate pöördumisele veebisüsteemi poole (dünaamilised veebilehed). Andmete koondamine andmebaasi on infokäitluse tõhustamisel üks levinumaid strateegiaid.

Mitmekihilised süsteemid

Andmete vahetu töötlemise operatsioonid – andmete salvestamine, otsimine, reorganiseerimine, kustutamine, varundamine (varukoopiate tegemine), juurdepääsuõiguste haldus (andmete turvalisus) – on infosüsteemis sageli niivõrd töömahukad, et nende sooritamiseks eraldatakse eraldi serverarvuti (andmebaasiserver, database server). Rakendused (infosüsteemi funktsionaalsuse põhiosa ehk nn. äriloogikat (business logic) realiseerivad programmid) paigutatakse siis teise, rakenduste serverisse (application server). Kasutajad pöörduvad tänapäeval rakenduste poole üha rohkem veebilehitsejate vahendusel. Nii kujuneb süsteemi kolmekihiline ülesehitus (arhitektuur):

Süsteemide mitmekihiline ülesehitus on tähtis keerukuse vähendamise meetod; seda kasutatakse programmeerimises ja süsteemiarenduses laialdaselt.

Andmemudel

Andmemudel (data model) määratleb selle, kuidas valitud objektide hulka kirjeldama hakatakse. Teisiti öeldes, andmemudeliga määratakse milliseid andmeid süsteemis hakatakse hoidma.

Andmemudelite esitamiseks on võimalik kasutada rida tähistussüsteeme (formalisme). Nende seas on nii lihtsamaid kui ka keerukamaid.

_ Andmebaasi minevate andmete koosseis tuleb välja selgitada enne programmide kirjutamise alustamist _ . Stabiilne andmebaasi andmete nomenklatuur (infosüsteemi andmemudel) on tõhusa programmeerimistöö seisukohalt äärmiselt oluline. Andmebaasi struktuuri projekteerimine on süsteemiarenduse protsessis omaette tööetapp, õigemine protsess, mis käib süsteemi funktsionaalse ulatuse projekteerimisega käsikäes. Andmebaasi projekteerimine on oskust ja kogemust nõudev töö.

Sõltuvalt süsteemist võib andmemudeli maht kujuneda küllatki suureks. Andmebaasis võib olla 50-100 või rohkemgi andmetabelit, igas tabelist kümneid andmeelemente (atribuute). See tingib vajaduse andmete modelleerimist läbi viia mitmes etapis, koostades mitu erineva taseme andmemudelit.

Kontseptuaalne modelleerimine

Kõige kõrgema taseme andmemudelit (see tehakse kõige esimesena) nimetatakse sageli kontseptuaalseks mudeliks (conceptual model).

Kontseptuaalse andmemudeli väljatöötamise protsessi nimetatakse vastavalt kontseptuaalseks modelleerimiseks (conceptual modeling). Lähedased, kuid mitte tingimata samamahulised terminid on andmete modelleerimine (data modeling) ja infoloogiline modelleerimine (infological modeling).

Kontseptuaalset andmemudelit iseloomustab:

° kõrge abstratsioonitase

° sõltumatus konkreetsest andmebaasisüsteemist

° tähelepanu andmete omadustel, mitte sellel, kuidas neid salvestada

° lihtsamini mõistetav kui tehniline andmebaasimudel

° kasutatav kasutajatega suhtlemisel.

Kontseptuaalne modelleerimine soovitatakse teostada sõltumata sellest, kuidas ja milliste vahenditega (ühe või teise andmebaasisüsteemiga või hoopis failidega) andmete hoidmise vajadus lahendatakse. See võimaldab keskenduda andmete olemusele. Paremini mõistetud ja artikuleeritud andmete olemus annab stabiilsema andmete struktuuri.

Kontseptuaalne modelleerimine paigutub infosüsteemiarenduse elutsüklis süsteemi eeluuringu ja süsteemi analüüsi etappide lähedusse.

Mõned eksperdid soovitavad alustada süsteemi funktsionaalsuse (tegevuste, protsesside) väljaselgitamisest põhijoontes ja selle järel asuda kontseptuaalse modelleerimise juurde. Teised autorid rõhutavad fuktsionaalsuse ja andmete võrdset tähtsust ning soovitavad funktsionaalset modelleerimist ja kontseptuaalset modelleerimist läbi viia paralleelselt. See tähendab, et esialgne, abstraktne, ”suure pildi” andmemudel tehakse juba koos süsteemi esimese protsessimudeliga.

Kasutaja nõudmisi ehk vajadusi (User Requirements või Needs) sellise metoodika korral jagada kaheks:

° Nõudmised andmetele (Data Requirements)

° Funktsionaalsed nõudmised (Functional Requirements).

Kontseptuaalse modelleerimise selline rõhutamine aitab tagada, et kasutajate andmevajadused on arvesse võetud ning need vajadused pole omavahel konfliktis.

Näide. Andmemudeli fragment (valmistatud Oracle modelleerimisvahendi abil). Kirjeldatud on kaks objekti (Klient, Müük), nende objektide atribuudid (kirjeldavad tunnused) ja objektivaheline loogiline seos.

Näide. Tekstina (mitte diagrammina) esitatud kontseptuaalne mudel (fragment):

° Firma koosneb osakondadest. Igal osakonnal on nimi, koodnumber ning juhataja. Osakond võib paikneda mitmes asukohas.

° Osakond juhib teatud hulka projekte. Projektil on nimi ja number. Projekti tehakse ühes asukohas.

° Töötaja kohta tuleb salvestada nimi, isikukood, aadress, palk, sugu ja sünnikuupäev. Töötaja kuulub ühte osakonda, kuid võib töötada ka teiste osakondade projektides. Registreerime töötaja poolt igas projektis töötatud tundide arvu nädalas. Töötajal on ka ülemus.

° Töötajal võib olla ülalpeetavaid. Ülalpeetava kohta registreeritakse: nimi, sugu, sünnikuupäev ning suhe töötajaga.

Olem, atribuut, seos

Kontseptuaalse mudeli peamisteks elementideks on olemid, atribuudid ja seoses.

Olemiks (entity) võib olla põhimõtteliselt mistahes objekt. Eristada võib:

° füüsilise iseloomuga objekte, nt. isik, auto, maja, töötaja, …

° kontseptuaalse iseloomuga objekte, nt. ettevõte, töökoht, ülikool.

Tuleb eristada olemitüüpi (entity type) ja konkreetseid olemeid.

Atribuut (attribute) on olemit kirjeldav omadus. Konkreetse olemi atribuutidel on väärtused (value). Atribuudi võimalike väärtuse hulka nimetatakse domeeniks (domain of values). Atribuute liigitatakse: liht- ja liitatribuudid (simple, composite); ühe- ja mitmeväärtuselised (single-valued, multivalued); salvestatud ning tuletatud atribuudid (stored, derived).

Null value — tarvitatakse tähendustes: - pole rakendatav (n/a); - pole teada, puudub.

Võti (key) — üks või mitu atribuuti, mille väärtus(ed) üheselt identifitseerivad konkreetse olemi.

Seos (suhe) (relationship) on kindla tähendusega seos kahe olemitüübi vahel.

Näide. Seotud on ühelt poolt olemid Töötaja ja Töötamine, teiselt poolt Osakond ja Töötamine. Näidatud on seosed konkreetsete (üksikute) modelleeritavate objektide vahel.

Notatsioonid

Kontseptuaalsetes mudelites on levinud mitmed seoste tähistamise viisid:

° Peter Chen’i Entity-Relationship

° Information Engineering

° Barker’i notatsioon (kasutusel Oracle vahendites)

° IDEF1X

° UML (Unified Modeling Language)

Barker’i (Oracle) notatsioonis esitatud kontseptuaalsed mudelid (fragmendid):

Barker’i (Oracle) tähistused:

Information Engineering ’u ja Barker’i tähistuste võrdlus:

Andmebaasi projekteerimine

Kontseptuaalse modelleerimise järel jätkub infosüsteemi arendustöö andmete dimensioonis andmebaasi projekteerimisega (disainiga). Eristatakse loogilist ja füüsilist projekteerimist. Loogilise projekteerimise etapis koostatakse loogiline andmemudel, mis spetsifitseerib andmete realiseerimise valitud andmebaasisüsteemis. Füüsilise projekteerimise etapis koostatakse füüsiline andmemudel, mis määratleb tehnilised üksikasjad, mida loogiline andmemudel ei käsitle, näiteks sisemised mälustruktuurid, juurdepääsuteed, andmebaasi failide organisatsiooni.

Loogiline andmemudel peaks olema süsteemi kasutajale veel põhimõtteliselt arusaadav, kuid siiski rohkem spetsifitseeriv kui kontseptuaalne andmemudel.

Näide. Andmebaasi loogiline mudel, esitatud SQL keeles.

SQL KEEL

SQL (Structured Query Language) on väga efektiivne, matemaatilisel süsteemil relatsioonialgebral põhinev andmebaasikeel, mis on kujunenud de facto andmebaasistandard. SQL võimaldab andmeid kirjeldada, pärida ning uuendada. Lisavõimalused on turbeks (autoriseerimine), kooskõlalisuse kontrolliks (integrity constraints), transaktsioonide töötluseks. Päritolu: keel SEQUEL, IBM 1975.

Andmebaasi projekteerimine või infoarhitektuur?

Peamiselt veebisüsteemide levikuga seoses on populaarseks muutunud infoarhitektuuri mõiste. Sellest ja teistest mõistetest lähemalt järgmises loengus.

Probleemid/harjutused

Koosta valitud probleemala kohta kontseptuaalne mudel.

Kirjandus

° Veebis kättesaadavatest materjalidest tasub esile tuua hea praktilise käsitluse tõttu: Ambler S.W. Data Modeling 101

Jaotis 2.1 How are Data Models Used in Practice?:

Kontseptuaalne andmemudel (Conceptual data model)

Loogiline andmemudel (Logical data model)

Physical data model (Physical data model)

Jaotis 2.3 Common Data Modeling Notations: Ülevaatlik tabel olulisemate andmemodelleerimis-meetodite (Information Engineering, Barker’i/Oracle, IDEF1X, UML) notatsioonide võrdlusega. Samas ka meetodite lühiiseloomustused.

Jaotis 3. How to Model Data: Esitab andmemodelleerimise tüüptegevused:

olemitüüpide identifitseerimine
atribuutide identifitseerimine
nimesüsteemide valik (naming conventions)
seoste identifitseerimine
võtmete leidmine/omistamine
andmestruktuuride normaliseerimine
denormaliseerimine (efektiivsuse kaalutlustel).