1. Eesmärgid. 2. Infosüsteemi arendamine. Joonised. TTÜ: Andmebaaside projekteerimine.

Transcription

1 Teema 7. Andmebaaside projekteerimine: strateegiline analüüs ja detailanalüüs Sisukord 1. Eesmärgid Infosüsteemi arendamine Arendusmetoodikad Strateegiline analüüs Detailanalüüs Tootmisettevõtte näide Kontseptuaalne andmemudel Mõisted Kasutatud materjalid...77 Joonised 1. Eesmärgid Infosüsteemi arendamine Arendusmetoodikad Strateegiline analüüs Detailanalüüs Tootmisettevõtte näide Kontseptuaalne andmemudel Mõisted Kasutatud materjalid Eesmärgid Anda ülevaade arendusmetoodikast, selle tähtsusest, komponentidest ja võimalikest väärkasutustest. Anda lihtsustatud, kuid terviklik ülevaade strateegilisest analüüsist ja detailanalüüsist. Kirjeldada kuidas tükeldada infosüsteemi allsüsteemideks. Näha ning mõista andmebaaside projekteerimist infosüsteemi tervikarendamise osana. Anda ülevaade kontseptuaalse andmemudeli koostamisest. 2. Infosüsteemi arendamine Ikka ja jälle üritavad arendustööga tegelevad vähekogenud inimesed edu saavutada tegevustikuga, mille nimi on "kodeeri ja paranda" (inglise keeles code and fix). Selle põhisisu on, et kui ülesanne käes kukutakse suure entusiasmiga kohe andmebaasi loomise lauseid ning andmebaasi kasutavat programmi kirjutama ilma, et lahendust eelnevalt läbi mõelda. Mingil hetkel (alati liiga hilja) hakatakse tegelema ka testimisega. Kui tegemist ei ole just ühe inimese väga väikses ülesandega, on läbikukkumine kindlustatud. 1

2 Andmebaasi projekteerimine, nagu igasugune projekteerimine, peab toimuma süstemaatiliselt! Andmebaas on infosüsteemi oluline osa. Infosüsteemi loomise käigus luuakse alati ka andmebaas. Seega infosüsteemi projekteerimine ja valmisehitamine sisaldab ka andmebaasi projekteerimist ja valmistegemist. Ei saa vaadata lahus infosüsteemi ja andmebaasi projekteerimist. Seetõttu vaadeldakse kogu kursuse käigus neid protsesse üheskoos. Tegelikult võib antud õppeaine pealkirja ümber sõnastada. Täpsem pealkiri oleks: "Intensiivse andmebaasikasutusega infosüsteemi projekteerimine" Infosüsteemi arendamiseks algatatakse üks või mitu projekti. Projekt on Mikli (1999) põhjal "kindla ajavahemiku ja finantsidega ning formuleeritud eesmärkidega ellu viidav muudatus või arendamine." Infosüsteemi arendamise käigus tuleb viia läbi järgmistele süsteemi loomissammudele vastavaid tegevusi. Strateegiline analüüs. Detailanalüüs. Disain. Realiseerimine (Ehitamine). Rakendamine (Üleviimine). Hooldamine. Samaaegselt (paralleelselt) viiakse läbi arendamist toetavaid tugitegevusi. Projekti dokumentides ja programmikoodis tehtavate muudatuste haldamine. Projektijuhtimine. Arendajate töökeskkonna (tööruumid, tarkvara, riistvara, arvutivõrk) loomine ja käigushoidmine. Süsteemi tulevaste kasutajate koolitamine. Süsteemiarenduse tulemuste kvaliteedi hindamine. Süsteemiarenduse käigus luuakse süsteemi mitmevaateline kirjeldus ning muudetakse seda kirjeldust üha täpsemaks (ja tehnilisemaks). Vaated, millele vastavad süsteemi kirjeldused koostada, on Sowa ja Zachman (1992) esitatud infosüsteemide arhitektuuri raamistiku põhjal. Andmevaade. Funktsioonide vaade. Võrgu vaade. Kasutajate vaade. Ajavaade. Eesmärkide vaade. 2

3 Need vaated ei ole alternatiivid. Süsteemi tuleb tervikliku pildi saamiseks kirjeldada kõikidest nendest vaadetest lähtuvalt. Süsteemi kirjeldatakse kasutades mudeleid ning mudelite koostamise protsessi nimetatakse modelleerimiseks. Mudel on reaalsuse lihtsustatud kirjeldus. Selleks, et erinevaid vaateid esitavad mudelid üheskoos tõesti annaksid tervikliku pildi süsteemist, tuleb tagada, et need mudelid on omavahel kooskõlas. Mudel võib olla visuaalne, tekstiline või kombineeritud. Enamasti koosnebki mudel visuaalsetest diagrammidest ja neid täpsustavatest tekstilistest kirjeldustest. Koostatud mudelite alusel luuakse töötav tarkvara. Süsteemi modelleerimiseks võib kasutada visuaalset modelleerimiskeelt UML (Unified Modeling Language) keelt. Samas ei ole UML kaugeltki ainuke võimalik keel, mida saab infosüsteemide (ja sealhulgas andmebaaside) projekteerimiseks kasutada. Andmebaasi projekteerimiseks (süsteemi andmevaate koostamiseks) võib kasutada objekti-rolli mudeleid ( Süsteemi mitmevaateliseks kirjeldamiseks võib näiteks kasutada objekti-protsessi modelleerimist ( või süsteemimaatrikseid. Analüüsi ja disaini käigus võib koostada andmebaasi ja andmebaasi kasutavate programmide prototüüpe. Prototüüp on (EVS-ISO/IEC 2382, 1998, põhjal) "süsteemi projekteerimise, töönäitajate ja kasutuspotentsiaali hindamiseks või nõuete paremaks mõistmiseks või määramiseks sobiv mudel või esialgne teostus." Prototüüpide tegemisel võib lähtuda erinevatest strateegiatest. Prototüüp võib olla mõeldud ideede kiireks testimiseks ja see heidetakse enne reaalse süsteemi ehitamist kõrvale (äravisatav prototüüp). Samas võib prototüübi täiendamise tulemusena samm-sammult valmida töötav tarkvarasüsteem (evolutsiooniline prototüüp). Tabel 1 Infosüsteemi ja andmebaasi loomissammude vastavustabel. Infosüsteemi loomissamm Strateegiline analüüs Detailanalüüs Disain Realiseerimine Rakendamine Hooldamine Andmebaasi loomissamm Nõuete kogumine Andmebaasi alamosade leidmine Projektide planeerimine Kontseptuaalne andmebaasi disain Nõuete kogumine Kontseptuaalne andmebaasi disain Loogiline andmebaasi disain Füüsiline andmebaasi disain Andmebaasi realiseerimine Andmebaasi rakendamine Andmebaasi hooldamine 3

4 Tabel 2 SQL andmebaasi loomissammude lühikirjeldus. Andmebaasi loomissamm Nõuete kogumine Kirjeldus Nii strateegilise kui detailanalüüsi käigus kogutakse kasutajate nõudeid infosüsteemile. Infosüsteemile esitatavaid nõudeid liigitatakse: Funktsionaalsed nõuded, mis kirjeldavad tegevusi mille läbiviimist peab (info)süsteem võimaldama (süsteemi oodatava funktsionaalsuse). Funktsionaalsete nõuete esitamiseks võib kasutada kasutusjuhtude mudelit. Funktsionaalsetest nõuetest tulenevad nõuded andmetele, mida nende tegevuste läbiviimiseks vaja läheb. Mittefunktsionaalsed nõuded. Robertson ja Robertson (1999) märgivad, et mittefunktsionaalsed nõuded kirjeldavad süsteemilt oodatavaid omadusi. Andmebaase puudutavad mittefunktsionaalsed nõuded on näiteks: - Nõuded süsteemi töökiirusele. Süsteemi töökiirust mõjutab oluliselt andmebaasisüsteemile edastatud korralduste täitmise kiirus. - Nõuded julgeolekule. Andmed on organisatsiooni oluline vara ning nende kaitsmiseks tuleb tarvitusele võtta kõikvõimalikud abinõud. - Nõuded süsteemi (sh. andmebaasi) muudatuste sisseviimise kiirusele. - Juriidilised nõuded (nt. milliseid seaduseid peab andmebaasi pidaja eriliselt arvesse võtma). Näiteks Eestis peab arvestama isikuandmete kaitse seadusega. Mittefunktsionaalsed nõuded pannakse kirja näiteks loendina. Andmebaasi alamosade leidmine Kasutajatelt informatsiooni kogumise meetodid: - Uuritakse organisatsiooniga seotud dokumente. Näiteks tutvutakse töötajate ametijuhenditega. - Andmebaasi tulevased kasutajad täidavad küsimustikke. - Jälgitakse andmebaasi tulevaste kasutajate tööd. - Tehakse intervjuusid tulevaste kasutajatega. - Uuritakse varem dokumenteeritud nõudeid teistele samatüübilistele organisatsioonidele. Strateegilise analüüsi käigus leitakse põhiolemitüübid (mõnikord kasutatakse ka terminit põhiobjektid), millele vastavaid andmeid hakatakse andmebaasis hoidma. Iga selline olemitüüp vastab mingile uuritavat organisatsiooni iseloomustavale olulisele mõistele. Igale põhiolemitüübile vastab alamosa andmebaasist ehk register. Suure süsteemi (andmebaasi) jagamine alamosadeks lihtsustab selle süsteemi kirjeldamist ja kirjeldusest ülevaate saamist ning võimaldab planeerida süsteemi alamosade arendamise järjekorda. 4

5 Andmebaasi loomissamm Projektide planeerimine Kontseptuaalne andmebaasi disain Kirjeldus Planeeritakse projektid mida on vaja andmebaasi valmistegemiseks. Tüüpiliselt projekteeritakse/ehitatakse ühe projekti käigus üks või mitu registrit aga mitte terve andmebaas. Lähtuvalt kasutaja nõuetest koostatakse kontseptuaalne andmemudel, mis on täiesti vaba kõigist realiseerimisega seotud kaalutlustest. Sellega kirjeldatakse detailselt nõuded selle kohta, milliseid andmeid tuleks andmebaasis hoida. Kontseptuaalses andmemudelis ei pöörata tähelepanu ühelegi realiseerimisega seotud asjaolule, nagu andmemudel, andmebaasisüsteem, riistvara jne. Loogiline andmebaasi disain Kontseptuaalse andmemudeli esitamiseks võib kasutada olemi-suhte diagramme, millele lisaks tuleb luua olemitüüpide, seosetüüpide ja atribuutide dokumentatsioon. Enne kui saab asuda andmebaasi loogilise disaini läbiviimise juurde tuleb lõplikult otsustada, millisel andmemudelil põhineva andmebaasisüsteemi abil on kavas andmebaas realiseerida. Esialgne valik on tehtud juba strateegilise analüüsi käigus, kui kirjeldati üks või mitu süsteemi tehnilise arhitektuuri varianti. Loogilise disaini käigus koostatakse andmebaasi tehniline kirjeldus vastavalt valitud andmemudelile. Kui otsustatakse kasutada SQLi aluseks olevat andmemudelit, siis kirjeldatakse loogilise disaini tulemusena tabelid, nende veerud ja tabelitega seotud kitsendused. Muuhulgas määratakse tabelite veergude tüübid (standardsed, mitte konkreetse andmebaasisüsteemiga seotud). Tabelite kvaliteedi parandamiseks (andmete liiasuse vältimiseks) tuleks tabelid viia viiendale normaalkujule et nad vastaksid ortogonaalse disaini printsiibis kirjeldatud reeglile. Normaliseerimine aitab vähendada andmete liiasust üksiku tabeli piires. Ortogonaalse disaini printsiibist kinnipidamine aitab vältida andmete liiasust üle erinevat tabelite. SQL andmebaasi loogilise disaini käigus toimub: - SQL andmebaasiga sobimatute konstruktsioonide eemaldamine kontseptuaalsest andmemudelist. (Valikuline) - Tabelite leidmine. - Tabelite viimine kuni viiendale normaalkujule. - Kontroll, kas kõik tabelid rahuldavad ortogonaalse disaini printsiipi. - Kitsenduste kirjeldamine. Loogilist andmemudelit võib füüsiliselt realiseerida mitmel erineval viisil. 5

6 Andmebaasi loomissamm Füüsiline andmebaasi disain Kirjeldus Füüsiline disain optimeerib / häälestab loogilise disaini lahendusi konkreetsete füüsiliste keskkondade jaoks. Enne kui saab asuda andmebaasi füüsilise disaini läbiviimise juurde tuleb lõplikult otsustada, millise andmebaasisüsteemi abil on kavas andmebaas realiseerida. Vähemalt SQL andmebaasisüsteemide puhul tuleb tõdeda, et erinevates andmebaasisüsteemides on küllaltki erinevad võimalused andmebaasi realiseerimiseks. Füüsiline disain andmete osas (andmete füüsiline projekteerimine) sisaldab: - Valitakse lõplikult välja kasutatav andmebaasisüsteem. Esialgne valik on tehtud juba strateegilise analüüsi käigus, kui kirjeldati üks või mitu süsteemi tehnilise arhitektuuri varianti. Eeldame, et kasutatakse SQL andmebaasisüsteemi. - Loogilise andmemudeli viimine konkreetse andmebaasisüsteemi tarkvara konteksti arvestades seal kasutatavat SQLi dialekti. - Andmetüüpide täpsustamine vastavalt valitud andmebaasisüsteemi võimalustele. - Tabelite valikulise denormaliseerimise (tabelite normaliseerituse astme vähendamise) kaalumine mõningate eriti tähtsate andmebaasioperatsioonide töökiiruse tõstmise eesmärgil. - Mitmesuguste füüsilise disaini objektide (indeksid, arvujada generaatorid, abitabelid, trigerid, rutiinid) kavandamine. Füüsilise disaini käigus kavandatakse ka andmebaasi füüsilise taseme organiseerimine. Ka selle puhul sõltuvad võimalused väga palju kasutatavast andmebaasisüsteemist. Näiteid küsimustest, millele tuleb füüsilise disaini käigus vastus leida: - Kas tabelid tuleks jagada füüsilisel tasemel sektsioonideks, mida saab paigutada erinevatesse failidesse ja kõvaketastele? - Kui suured peaksid olema andmeplokid, millesse füüsilisel tasemel andmeid salvestatakse? - Kui palju peaks andmeplokkides olema vaba ruumi? - Kas andmed peaksid olema andmefailides sorteeritud ning kui jah, siis milliste andmeväärtuste järgi sorteerimist läbi viia? - Kas ja milliseid andmeid tuleks pakkida? - Kas ja milliseid tabeli veerge tuleks indekseerida ning millist tüüpi indekseid tuleks kasutada? - Kas ja milliste veergude kohta peab andmebaasisüsteem koguma informatsiooni nendes veergudes olevate väärtuste jaotuse kohta (koostama histogramme)? s ja milliseid hetktõmmiseid tuleks kasutada päringute töökiiruse parandamiseks? 6

7 Andmebaasi loomissamm Andmebaasi realiseerimine Andmebaasi rakendamine Andmebaasi hooldamine Kirjeldus Andmebaasi loomiseks vajalike käsufailide koostamine ja nende käivitamine konkreetses andmebaasisüsteemis. Käsufailid sisaldavad SQL lauseid andmebaasiobjektide (näiteks baastabelid ja vaated) loomiseks. Kui projekteerimiseks kasutatakse CASE (Computer Aided System Engineering) vahendit, siis saab käsufailid automaatselt genereerida ja ka andmebaasisüsteemis käivitada. Samaaegselt toimub andmebaasi ja seda kasutavate programmide testimine. Testimine ei tõesta, et vigu ei ole ta tõestab et vead on olemas. Rakendamise käigus toimub loodud andmebaasi tellija juures töölerakendamine. Muuhulgas võib olla vajalik läbi viia andmesiire, mille käigus kantakse loodud andmebaasi andmed süsteemis varem kasutusel olnud andmebaasidest ja välistest allikatest. Andmebaasi töö jälgimine ja tagamine. See on andmebaasi administraatori (Database Administrator -DBA) ülesanne. - Tagatakse andmebaasi tõrgeteta töö (kasutajate haldamine, andmete varundamine ja taastamine jne.) - Jälgitakse andmebaasis toimuvate operatsioonide töökiirust ja vajadusel püütakse seda parandada (nt. indeksite lisamine ja kustutamine, rutiinides kasutatavate SQL lausete ümberkirjutamine, tabelite sektsioonideks jagamine, tabelite ja indeksite juhtparameetrite muutmine). Väga suure osa piisava töökiiruse tagamisest annab korrektne andmebaasi analüüs ja disain. - Andmebaasi väiksemate muudatuste sisseviimine. Tekib küsimus, kuidas neid süsteemiarenduse tegevusi organiseerida? Kose mudel e. veelange mudel (waterfall) Klassikalise kose mudeli alusel on süsteemi arendamine jaotatud üksteisele järgnevateks etappideks ning arenduse järgmist etappi ei alustata enne kui eelmine etapp on lõpetatud. Ühe arendustsükli läbimine tähendab kõigi järjestikuliste etappide läbimist. Ühe arendustsükli läbimine võib võtta aega 1-2 aastat. Nii andmebaas kui seda kasutav tarkvara valmivad arendustsükli lõpuks. Süsteemiarendus koosneb järgmistest järjestikulistest etappidest (loetelu on esitatud varasemast hilisema poole): 1. Strateegiline analüüs. 2. Detailanalüüs. 3. Disain. 4. Realiseerimine (Ehitamine). 5. Rakendamine (Üleviimine). 6. Hooldus. Nõuete kogumisest süsteemi töölerakendumiseni kulub palju aega ning vahepeal võivad nõuded süsteemile ja parimad võimalikud tehnilised lahendused olla muutunud. Näited probleemidest: 7

8 Nõuded peavad olema fikseeritud, enne kui arendamine saab jätkuda, kuid reaalses maailmas on nõuded muutuvad ja palju nõudeid tekib alles süsteemi esimese versiooni kasutamisel. Probleemid võivad ilmneda alles süsteemi testimise käigus. Töökiirust saab testida alles siis, kui süsteem on peaaegu valmis. Kasutaja näeb esimest korda töötavat süsteemi alles siis, kui see on peaaegu valmis. Kogu süsteem valmib korraga ja selle jaoks läheb vähemalt 1-2 aastat aega. Selle ajaga on kasutajate nõuded suure tõenäosusega muutunud. Strateegiline analüüs Detailanalüüs Disain Ehitamine Rakendamine aeg Joonis 1 Süsteemiarendus "kose" mudeli alusel. Hooldamine Kose mudeli puudustest ülesaamiseks on seda arendatud/teisendatud. Näiteks: Kose mudel koos kattuvate etappidega: lubatakse alustada järgmist etappi enne eelmise lõppu. Kui mingi etapi läbimise käigus ilmnevad probleemid, siis võib nende lahendamiseks teha tegevusi, mis kuuluvad eelmisesse etappi. Järkväljastusega elutsükkel: Fowler (2007) toob näite, et sellise mudeli alusel läbiviidavas projektis võidakse kasutada neli kuud analüüsiks ja projekteerimiseks koskstiilis, millele järgneb neli kahekuulist süsteemi iteratiivset versioonitsüklit. Evolutsiooniline prototüüpimine Koostatakse süsteemi prototüüp. Prototüüp on tarkvarasüsteem, mis simuleerib või animeerib teise süsteemi struktuuri, funktsionaalsust, tegevusi või esitust. Seda kasutajale ette näidates ja tema poolt nõutud muudatusi sisse viies arendatakse välja töötav süsteem. (Prototüüpimise kohta lugege dokumendist kataloogis "Lisamaterjal"). Spiraalne mudel süsteemiarendus koosneb arendustsüklitest, millest igaühe käigus projekteeritakse / realiseeritakse / testitakse süsteemi või mingit selle osa üha täpsemalt. 8

9 Iteratiivne mudel süsteemiarendus koosneb lühikestest arendustsüklitest, millest igaühe käigus projekteeritakse/ realiseeritakse/ testitakse süsteemi mingit omadust/ osa. Ka andmebaasi ei projekteerita / ehitata ühekorraga, vaid seda tehakse järk-järgult koos ülejäänud süsteemi kasvamisega. Iteratiivsel mudelil põhineva süsteemiarenduse metoodikate näideteks on näiteks Rationali unifitseeritud protsess (RUP) ja selle edasiarenduseks olev ettevõtte unifitseeritud protsess (EUP). Samuti järgib iteratiivset mudelit näiteks ekstreemprogrammeerimine. Esimest kahte võib isegi nimetada metoodikate perekonnaks, sest tegemist on raamistikega mis võimaldavad luua konkreetse projekti jaoks kõige sobivama metoodika. Viimastel aastatel on üha populaarsemaks muutunud agiilmetoodikad (näiteks ekstreemprogrammeerimine ja Scrum) (Leis, 2000). Taolisi metoodikaid on päris palju. Järgnevalt on nimetatud mõned nende põhiprintsiibid: Tarkvara arendamine iteratiivselt, kasutades lühikesi iteratsioone (1 2 nädalat). Minimalism dokumentatsiooniga ei tule üle pingutada. Loodav lahendus peab olema lihtne. "Pole vaja kelli ja vilesid". Väga sage ja varajane testimine. Sotsiaalsete väärtuste ja meeskonnatöö olulisuse rõhutamine. Väga oluline on tihe suhtlus tarkvara tellijaga ja tema esindajate poolne tagasiside loodava tarkvara kohta. Selle saavutamiseks võiks näiteks üks tellija esindaja pidevalt viibida süsteemi arendajate juures ja anda tagasisidet valminud tarkvaralahenduste kohta. 9

10 3. Arendusmetoodikad Antud kursuses räägitakse andmebaasi loomise metoodikast. Enne tuleks üritada mõista, mis asi see metoodika on. Cockburn (1997) loetleb valdkondi, mille kohta üks süsteemi arendamist juhendav metoodika peaks juhiseid andma: Tabel 3 Arendusmetoodika komponendid. Metoodika valdkond rollid oskused meeskonnad standardid töövahendid tegevused tulemused kvaliteet Valdkonna kirjeldus Metoodika peaks kirjeldama arendusprotsessis osalevad osapooled ning nende ülesanded. Rollide näiteks on projektijuht, ärianalüütik, andmete modelleerija, andmebaasi administraator. Metoodika peaks kirjeldama rollide täitjatelt oodatavad oskused. Metoodika peaks kirjeldama põhimõtted, kuidas süsteemiarenduse käigus kasutada grupitööd. Metoodika peaks loetlema standardid, mida tuleb süsteemiarenduse käigus jälgida. Metoodika peaks kirjeldama töövahendeid, mida süsteemiarenduse käigus võiks kasutada. Töövahendite on tarkvarapaketid aga ka näiteks mitmesugused küsimustikud, mis aitavad hinnata tehtud töö kvaliteeti. Metoodika peaks kirjeldama süsteemiarenduse jagunemise etappideks ja nende etappide käigus tehtavad tegevused. Metoodika peaks kirjeldama dokumendid, mis süsteemiarenduse käigus luuakse. Metoodika peaks kirjeldama meetodid süsteemiarenduse tulemuste kvaliteedi hindamiseks. Metoodikaid on väga erinevaid. Mõned neist on kompaktsed soovituste kogumid teised aga mahukad (monumentaalsed) kirjeldused, mis juhendavad süsteemiarenduse iga aspekti. Andmebaaside arendusprotsessi organiseerimine konkreetsetes firmades / projektides nõuab kaasaegsete arendusmetoodikate kasutamist. Andmebaaside arendusmetoodikad on alamhulk infosüsteemi kogu elutsüklit toetavatest metoodikatest, mida saab kasutada andmebaaside ehitamisel alates vajaduste defineerimisest/analüüsist läbi projekteerimise kuni füüsilise realiseerimiseni. Paljusid käesoleval ajal populaarseid arendusmetoodikaid iseloomustavad omadused nagu: - iteratiivne (st. süsteemi arendatakse osade kaupa); - kasutajat laialdaselt kaasahaarav; 10

11 - sisaldama taaskasutamist (dokumendimallide kasutamine, mustrite kasutamine, tarkvarakomponentide kasutamine). Kui otsitakse organisatsiooni jaoks andmebaaside arendusmetoodikat, tasub valida kergesti omandatav ja kasutatav ning elektrooniliselt realiseeritud protsess, mida arendusmeeskonnad saavad läbi võrgu kiiresti erinevates asukohtades rakendada. Andmebaasi ja seda kasutavate rakenduste ehitamise keerukust saab vähendada kasutades projektides läbiproovitud andmebaaside arendamise meetodeid. Sellised meetodid annavad edasi heade projektimeeskondade parimaid kogemusi ja praktikaid, võimaldavad oluliselt vähendada projektiga seotud riske ning tähtaegu ja tõsta projektitulemuste kvaliteeti. 3.1 Metoodika väärkasutused Metoodika vale kasutamine mõjutab väga suure tõenäosusega negatiivselt projekti tähtaegu. On üsna tavaline, et organisatsioonid kasutavad metoodikad kui protsessidiagramme või retsepte ilma ühtegi tegevust sisuliselt läbi mõtlemata. See võib lõppeda tohutu ajaraiskamisega, kui tehakse tegevusi ja toodetakse tulemusi mõistmata nende seost terviklahendusega. Metoodikaid on vaja häälestada konkreetsetele projektidele. Mittevajalikud tegevused ja tulemused tuleb projektiplaanist kustutada. Metoodikad, mis on liiga keerukad kasutada ja õppida, ei leia kuigi palju kasutamist projektimeeskondade poolt. Mõningad metoodikad sisaldavad tuhandeid projekti pisidetaile. Tihedate projekti ajagraafikute korral heidetakse sellised metoodikad kõrvale. Oluline on uuendada metoodikaid ajas. Uued projektikogemused ja parimad praktikad tuleb teatud ajavahemike tagant metoodikasse lülitada. 11

12 4. Strateegiline analüüs Järgnevalt räägitakse strateegilise analüüsi metoodikast, mis on välja töötatud TTÜ informaatikainstituudi töötajate poolt. Selle kohta lugege täiendavalt näiteks Rein Kuusiku artiklit ajakirjast A&A (Kuusik 2000). Metoodika koostamisel on lähtutud eeldustest, et organisatsioon vajab edukaks toimimiseks infosüsteemi. Infosüsteemi arendamine ei ole ühekordne pingutus vaid pidev protsess ning organisatsioon, mis infosüsteemi kasutab, peab arendamisest aktiivselt osa võtma. See tähendab, et süsteemi tulevased kasutajad peaksid osalema süsteemi toimimise aluseks olevate protsesside (äriprotsesside) kirjeldamisel. Süsteemi sellisel viisil edukalt arendamiseks peab olema paigas vundament, milleks on tervikpilt loodavast süsteemist. Nimetatud tervikpilt saadakse strateegilise analüüsi tulemusena. Süsteemi arendamise algul on probleemiks, et arvutisüsteemi kasutavat infosüsteemi ei ole või vana infosüsteem ei rahulda enam kasutajaid, kuid päris täpselt veel ei teata, mida uus süsteem peaks tegema. Strateegilise analüüsi käigus toimub piltlikult öeldes infosüsteemi projekteerimise ülesandega tutvumine ja esialgse lahendusplaani koostamine. Strateegilise analüüsi teostamisel on väga oluline oskus näha ette uuritava organisatsiooni arengut umbes 5 aasta perspektiivis. Näiteks oletame, et antud hetkel tegeleb uut infosüsteemi vajav ettevõte ainult hulgimüügiga. Kuid lähema paari aasta jooksul plaanib ta hakata tegelema ka jaemüügiga. Kui seda teadmist mitte arvesse võtta, siis on süsteemiarenduse tulemuseks infosüsteem, mida tuleb juba mõne aasta pärast hakata oluliselt muutma ja täiendama. Loodava süsteemi andmebaas tuleks üritada kavandada nii paindlik, et ta võimaldaks rahuldada ka tulevikus esilekerkivad nõuded. Suvalisel süsteemil on Isotamm (1998) põhjal kaks põhiomadust: - Mitteamorfsus, mis tähendab, et süsteemis on võimalik eristada iseseisvaid komponente, milleks on süsteemi elemendid ja elementidevahelised seosed. Süsteemil on struktuur ja ta ei ole amorfne. - Terviklikkus, mis tähendab, et suvaline süsteem on eristatav teistest süsteemidest, st. seosed süsteemi elementide vahel on tugevamad kui süsteemi ja teiste süsteemide vahel. Millised on strateegilise analüüsi põhilised tulemused? 1) Suure terviksüsteemi tükeldamine (dekomponeerimine) suhteliselt terviklikeks ja iseseisvalt arendatavateks allsüsteemideks. Samuti määratakse, kuidas need allsüsteemid üksteist kasutavad. Iga sellise allsüsteemi peaks saama arendada omaette projektina. Allsüsteemide leidmine võimaldab ühtlasi kindlaks määrata süsteemi kui terviku skoobi millistest elementidest süsteem koosneb ja millised elemendid jäävad uuritava süsteemi piiridest välja ning kuuluvad teistesse süsteemidesse. 2) Süsteemi arhitektuuri esialgne kirjeldamine. Larman (2002) defineerib arhitektuuri kui süsteemi ülesehituse, eesmärkide ja struktuuri kirjeldust. 12

13 Koostatavas arhitektuurivaates kirjeldatakse allsüsteemide paigutus erinevates asukohtades ja tehniline arhitektuur kasutatav tarkvara, riistvara, arvutivõrgud. On võimalik, et kirjeldatakse mitu erinevat arhitektuurilist lahendust millest süsteemi hilisema arendamise käigus valitakse kõige sobivam. 3) Arendamise strateegia loomine, milles määratletakse allsüsteemidele vastavad arendusprojektid, nende prioriteedid, ressursivajadused, riskid, projektorganisatsioon. Antakse esialgne hinnang sellele, millises osas tuleb süsteem lasta tellimustööna valmis teha ja millises osas võib kasutada olemasolevaid tarkvarasüsteeme. 4.1 Allsüsteemid Süsteemi jagamine allsüsteemideks võimaldab lihtsamalt süsteemi kui tervikut hallata, sest "teades osiste koostoimimist, on üksikute osiste arendamine palju lihtsam kui sellisteks osadeks jaotamata terviku arendamine (analoogiliselt tarkvaraarenduse/programmeerimise praktikaga, kus suure ülesande jaotamine väiksemateks tagab realisatsiooni lihtsustumise ja seega ka tulemuse parema kvaliteedi, s.o ülesande üldine keerukus väheneb)." (Kuusik, 2000). Vaatame terviksüsteemi näitena ülikooli õppeinfosüsteemi. Terviksüsteemi tükeldamisel allsüsteemideks leitakse TTÜ Informaatikainstituudis väljatöötatud käsitluse kohaselt paralleelselt kolme erinevat tüüpi allsüsteemid ja nende vahelised seosed. Pädevusalad. Funktsionaalsed allsüsteemid. Registrid. Organisatsiooniline tükeldus pädevusala allsüsteemideks. Pädevusala on konkreetse organisatsiooni juhi vastutuspiirkond. Pädevusala vastab mõnele organisatsiooni struktuuriüksusele, ametikohale või infosüsteemi kasutaja rollile. Igal pädevusalal on funktsioonid (ülesanded), mida ta peab täitma ja infovajadused (nõuded andmetele), mida ta peab kasutama. Mitu isikut võivad omada sama pädevusala ja üks isik võib omada mitut pädevusala. Ülikooli infosüsteemi pädevusalade näited. - Üliõpilase pädevusala. - Õppejõu pädevusala. - Dekanaadi juhataja pädevusala Pädevusalade kirjeldustest arenevad süsteemiarenduse käigus välja kasutajate töökohtade ja kasutajaliideste kirjeldused. Iga pädevusala kirjeldatakse koostöös selle pädevusala esindajatega (konkreetse isikutega kes hakkaksid seda süsteemi kasutama). Pädevusalade esindajaid küsitletakse ja nende tööd jälgitakse. Pädevusala esindajad peaksid pidevalt hindama enda pädevusala kohta koostatavaid mudeleid. 13

14 Väikese koolituse järel võiksid pädevusala esindajad ka ise koostada oma pädevusala kirjeldavaid mudeleid. Pädevusalasid kirjeldavad mudelid on aluseks infosüsteemi projekteerijatele (süsteemi arendamisega tegeleva IT firma esindajad), kes koostavad nende põhjal süsteemi funktsionaalse ja andmekeskse tükelduse. Loomulikult on kõigi allsüsteemide mudelite koostamise puhul vajalik tihe suhtlus projekteerijate ning süsteemi tellijate ja kasutajate vahel. Funktsionaalne tükeldus funktsionaalseteks allsüsteemideks. Funktsionaalne allsüsteem vastab ühele infosüsteemi põhifunktsioonile. Ülikooli infosüsteemi funktsionaalsete allsüsteemide näited. - Õppekavade arvestus. - Õpingukavade arvestus. - Õppetulemuste arvestus. - Õppeainete arvestus. - Tunniplaanide arvestus. - Üliõpilaste arvestus. - Töötajate arvestus. - Töötajate tööpanuse arvestus. - Funktsionaalsete allsüsteemide kirjeldustest arenevad süsteemiarenduse käigus välja rakendustarkvara moodulid, mis aitavad pädevusalade esindajatel oma ülesandeid täita. Andmekeskne tükeldus andmekeskseteks allsüsteemideks ehk andmekogudeks ehk registriteks. Registriks nimetame loogilist andmebaasi, milles hoitakse ühele iseseisvat elutsüklit omavale põhiolemitüübile vastavaid andmeid ning realiseeritakse selle olemitüübiga seotud elementaarsed registreerimise ja päringu teenused. Ülikooli infosüsteemi korral on põhiolemitüübid näiteks üliõpilane, õppekava ja õppeaine ning teenusteks näiteks uue õppekava sisestamine ja õppeaine otsing koodi või nimetuse järgi. Ülikooli infosüsteemi registrite näited. - Üliõpilaste register. - Õppejõudude register. - Õppekavade register. - Õppeainete register. - Õppetulemuste register. - Moriarty (2001) loetleb kõige põhilisemaid äriga seotud mõisteid: osapooled, asukohad, sündmused, lepingud, kontod, tooted ja teenused, turud, võimalused, ressursid, kliendid, müügid. Sellistele mõistetele vastavaid andmeid on vaja hallata peaaegu igas infosüsteemis ning seega võib igale sellisele mõistele vastata omaette register. 14

15 Registrite kirjeldustest arenevad süsteemiarenduse käigus välja andmebaasid, mida kasutab otseselt rakendustarkvara ja nende kaudu pädevusalade esindajad oma ülesannete täitmiseks. Registri tüüpi infosüsteemi põhiülesandeks on andmete registreerimine ja talletamine, et neid saaks vajadusel hiljem kasutada. Selline infosüsteem hõlmab lisaks registri andmebaasile ka sellega seotud funktsionaalsed ning pädevusala allsüsteemid. Registri tüüpi infosüsteeme vajavad näiteks riigi andmekogud, milleks on Eesti Vabariigi andmekogude seaduse põhjal riigi põhiregistrid, riiklikud registrid ja riigiasutuste peetavad muud andmekogud. 15

16 4.2 Allsüsteemide vahelised seosed Kuidas on erinevad allsüsteemid omavahel seotud? Registrites asuvad andmed, mida kasutavad funktsionaalsed allsüsteemid ja mis peavad aitama lõppkokkuvõttes infosüsteemi kasutajatel (pädevusalade esindajatel) oma ülesandeid täita. Funktsionaalsed allsüsteemid pakuvad teenuseid pädevusaladele ning oma töö läbiviimiseks kasutavad registrites olevaid andmeid. Funktsionaalsed allsüsteemid võivad registritesse andmeid lisada, registrites olevaid andmeid muuta, registrites olevaid andmeid kustutada ja lugeda registris olevaid andmeid. Igal registril on üks või mitu pädevusala, mille esindajad haldavad seda registrit loevad/lisavad/muudavad/kustutavad selles registris andmeid. Igal registril on null või rohkem pädevusala, mille esindajad ainult loevad andmeid sellest registrist. Pädevusalad suhtlevad registritega funktsionaalsete allsüsteemide kaudu. Tüüpiliselt on registris andmete haldamine (registri teenindamine) ühe funktsionaalse allsüsteemi ülesanne kuid registris olevaid andmeid loevad mitmed allsüsteemid. Eelnevast tulenevalt on infosüsteemi funktsionaalseid allsüsteeme võimalik leida põhiolemitüüpide põhjal. Igale põhiolemitüübile vastab register ning ka funktsionaalne allsüsteem mille kaudu toimub selle registri haldamine. Vaatleme järgnevalt näidet allsüsteemide vaheliste seoste kohta. Ülikooli infosüsteemi üheks allsüsteemiks on õpingukavade arvestus. Õpingukava on Tallinna Tehnikaülikooli õppetegevuse eeskirja kohaselt "õppuri poolt eelseisvaks semestriks valitud õppeainete loend, mida ta kohustub õppima; õppekava läbimise individuaalne tee semestrite kaupa." Üliõpilane peab esitama üldjuhul õpingukava iga semestri alguses. Õpingukavade allsüsteemi kasutavad üliõpilase, õppejõu ja dekanaadi sekretäri pädevusalad. Üliõpilane koostab õpingukava, õppejõud otsustab kas lubada üliõpilasel õppeainet õppida ning dekanaadi sekretär vaatab õpingukavade esitamise aruannet. Õpingukavade funktsionaalne allsüsteem haldab (teenindab) õpingukavade registrit, st. selle allsüsteemi kaudu toimub andmete lugemine/ lisamine/ muutmine/ kustutamine õpingukavade registris. Lisaks sellele loeb õpingukavade funktsionaalne allsüsteem andmeid erinevatest registritest nagu õppeainete register, üliõpilaste register, töötajate register ja õppetulemuste register. Näiteks õppeainete registris olevaid andmeid on vaja lugeda, sest õpingukava määrab ära semestris õpitavad õppeained. Õppetulemuste registris olevaid andmeid on vaja lugeda et teha kindlaks, kas üliõpilasel on õigus õppeainet oma õpingukavasse valida (nt. kas ta on edukalt õppinud õppeaine eelduseks olevat õppeainet). Nimetatud allsüsteemid moodustavad ühe (väikese) osa ülikooli infosüsteemist kui tervikust. 16

17 17

18 Andmebaaside projekteerimine. Dekanaadi sekretär kasutab kasutab Õppejõud kasutab Üliõpilane kasutab kasutab Dekanaadi sekretäri töökoht Õppejõu töökoht Üliõpilase töökoht Õpingukavade funktsionaalne allsüsteem loeb loeb haldab loeb loeb loeb haldab loeb Õppetulemuste register Töötajate register Õpingukavade Üliõpilaster register register õppimise tulemuseks saadakse Õppeainete register Õppetulemus Töötaja kinnitab Õpingukava esitab Üliõpilane Õppeaine paneb õppimisele hinde õpingukava sisaldab Joonis 2 Õpingukavade infosüsteemi jaotus allsüsteemideks. 18

19 4.3 Allsüsteemide liigitus Pädevusalasid võib liigitada vastavalt sellele kas nende pädevusalade esindajad: töötavad uuritavas organisatsioonis. Näiteks ülikooli infosüsteemis on üheks selliseks pädevusalaks õppejõud. ei tööta uuritavas organisatsioonis, kuid kasutavad selle teenuseid. Näiteks ülikooli infosüsteemis on sellisteks pädevusaladeks üliõpilane, kes õpib ülikoolis või haridusministeerium, mille esindajad soovivad saada ülikoolilt aruandeid. Funktsionaalseid allsüsteeme ja registreid (edaspidi allsüsteeme) on võimalik liigitada sisulisteks ja administratiivseteks e. tugisüsteemideks. Sisuline allsüsteem võimaldab viia läbi tegevusi milleks infosüsteemi vajav organisatsioon on otseselt ellu kutsutud. Näiteks ülikooli ülesandeks on õpetada üliõpilasi ja viia läbi teadustööd. Ülikooli infosüsteemi sisuliste funktsionaalsete allsüsteemide näited on õppekavade arvestus, õpingukavade arvestus, õppetulemuste arvestus, õppeainete arvestus, tunniplaanide arvestus ja üliõpilaste arvestus. Ülikooli infosüsteemi administratiivsete funktsionaalsete allsüsteemide näited on dokumentide arvestus, lepingute arvestus, ruumide arvestus ja töötajate arvestus. Administratiivsete allsüsteemide puhul on suurem võimalus, et leiduvad mustrid või universaalsed mudelid, mida selliste allsüsteemide kirjeldamiseks võib kasutada. Samuti on administratiivse allsüsteemi puhul suurem võimalus, et leidub rakenduspakette, mis pakuvad selliselt allsüsteemilt oodatavat funktsionaalsust. Soovitame tutvuda Koov (2001) poolt koostatud raamatuga, kus kirjeldatakse universaalseid programme (raamatupidamine, kliendihaldus, dokumendihaldus jne.), mingi tegevusvaldkonna (kauplus, hulgiladu, liising jne.) jaoks koostatud eriprogramme ning riigi ja kohaliku omavalitsuse töö hõlbustamiseks koostatud programme. Sellisel juhul tuleb otsustada, kas allsüsteemi valmistegemiseks tuleb kohandada olemasolevat rakenduspaketti või ehitada süsteem puhtalt uuritava organisatsiooni nõuetest lähtudes. Isotamm (1998) leiab, et rakenduspakettide kasutamise eelisteks on näiteks süsteemi kiire valmimine ja rakenduspaketi dokumentatsiooni olemasolu. Kui rakenduspakett vastab piisavalt hästi loodava infosüsteemi nõuetele ja ei vaja ulatuslikku kohandamist, siis on selle kasutamise hind ette teada ja võib kujuneda väiksemaks kui süsteemi nullist ehitamisel. Isotamm (1998) märgib, et rakenduspakettide kasutamise probleemideks on: paketi liigne üldisus, mis tingib vajaduse seda konkreetse organisatsiooni nõuetega kohandada; paketi müüjal pole aega ostja probleemidega põhjalikult tegeleda, sest tal on palju kliente; 19

20 paketi ostja soovidele vastav kohandamine nõuab üldjuhul müüja kaasabi ning selle eest tuleb eraldi maksta. Seega olemasoleva rakenduspaketi kasutamine ei pruugi alati olla kõige otstarbekam, sest selle konkreetse organisatsiooni nõuetega kohandamine võib osutuda liiga keeruliseks, aeganõudvaks ja kulukaks. 4.4 Nõuandeid süsteemi allsüsteemideks jagamiseks Allsüsteemideks jaotamise ülesandele ei ole ühte ainuõiget lahendust vaid on paremad ja halvemad lahendused. Kuid kui allsüsteemideks jagamine pole kõige paremini õnnestunud, siis võib loodud süsteemi toimimise käigus selguda, et süsteemi ei saa liigse keerukuse või ressursside vajaduse tõttu lisada uusi osi või viia sisse muudatusi see tähendab, et süsteemi ei saa edasi arendada (Kuusik, 2000). Võimalikult hea allsüsteemideks jaotuse saamiseks tuleb seega järgida parimaid praktikad. Allsüsteemide leidmise ja kirjeldamise tulemuste hindamiseks on edukalt rakendatavad tarkvara disaini printsiibid (Larman, 2002). Allsüsteemid ei tohiks olla liiga väikesed ega liiga suured. Näiteks registris hoitakse ühele põhiolemitüübile ja sellega seotud olemitüüpidele vastavaid andmeid. Probleem tekib muidugi sellega, mida lugeda põhiolemitüübiks. Kas kaupade register sisaldab kaubakategooriaid või tuleks eristada kaupade registrit ja kaubakategooriate registrit? Peenendamisega ei maksa liiale minna ja antud juhul piisaks ainult kaupade registrist. Kaubakategooria iseloomustab kaupa. Kui jagaksime andmebaasi alamosadeks nii, et iga olemitüübi kohta leidub omaette register, siis kaotaks registriteks jagamine oma mõtte. Allsüsteemid peaksid kõik olema suhteliselt ühesuguse suurusega. Näiteks kui ühe registri kirjeldamiseks tuleb kontseptuaalses andmemudelis esitada 30 olemitüüpi ja teise kirjeldamiseks tuleb esitada 3 olemitüüpi, siis ei ole ilmselt tegu sarnaste suurustega. Allsüsteemi elementidel peab olema kõrge sisemine sidusus (inglise keeles high cohesion). See tähendab, et funktsionaalse allsüsteemi korral peavad pakutavad teenused olema tihedalt üksteisega seotud, "käima ühe asja kohta". Näiteks iga funktsionaalne allsüsteem võiks võimaldada hallata (lugeda, lisada, muuta ja kustutada) ühe registri andmeid. Allsüsteemi sõltuvus teistest allsüsteemidest peaks olema võimalikult väike (inglise keeles low coupling). Selle eelised on järgnevad. Muutused teistes allsüsteemides mõjutavad allsüsteemi võimalikult vähe. Spetsifikatsiooni on lihtsam taaskasutada. Spetsifikatsioonist on lihtsam aru saada. 20

21 4.5 Strateegilise analüüsi tulemust kirjeldava dokumentatsiooni struktuur Järgnevalt esitatakse lihtsustatud nimekiri strateegilise analüüsi tulemusel loodavatest dokumentidest. Strateegilise analüüsi projekti spetsifikatsioon (taust, eesmärgid, oodatavad tulemused) Süsteemi üldvaade Organisatsiooni eesmärgid. Infosüsteemi eesmärgid. Lausendid. Põhiobjektid. Põhiprotsessid. Põhilised sündmused. Tegutsejad. Tükeldus allsüsteemideks: - Pädevusala allsüsteemide nimekiri. Selle saab leida tegutsejate nimekirja alusel. - Funktsionaalsed allsüsteemide nimekiri. Selle saab leida põhiprotsesside ja põhiobjektide nimekirja alusel. - Registri allsüsteemide nimekiri. Selle saab leida põhiobjektide nimekirja alusel Pädevusalade kirjeldused Iga pädevusala kohta koostatakse: Eesmärgid. Objektid, protsessid ja sündmused. Nimekiri funktsionaalsetest allsüsteemidest, mida ta kasutab. Nimekiri registritest, mida ta loeb ja haldab. Kasutusjuhtude mudel. Kirjeldatakse konkreetselt selle ühe pädevusalaga seotud kasutusjuhud. Kasutusjuhtumeid võib lasta kirjeldada pädevusala enda esindajatel ning mudel on abiks funktsionaalsete allsüsteemide kasutusjuhtude leidmisel. Domeenimudel. Pädevusala esindaja töövaldkonda kirjeldavad olulised mõisted ja nende mõistete vahelised seosed Funktsionaalsete allsüsteemide kirjeldused Iga funktsionaalse allsüsteemi kohta leitakse näiteks: Eesmärgid. Objektid, protsessid ja sündmused. 21

22 Nimekiri pädevusaladest, kes seda kasutavad. Registrid, mida see funktsionaalne allsüsteem loeb ja haldab. Funktsionaalse allsüsteemi põhiprotsesside kirjeldused tegevusdiagrammidena. Andmebaasi kasutuse eskiismudel (kasutusjuhtude mudel: diagrammid + tekstilised kirjeldused). Kasutusjuhtude diagrammil näidatakse "kriipsumehikestena" süsteemi võimalikke kasutajaid ehk tegutsejaid (mitte konkreetsed isikud, vaid pädevusalad), ning ovaalidena süsteemi kasutamise protsesse. Viimaseid saab tuletada süsteemi kasutust tingivatest sündmustest. Strateegilise analüüsi tulemusena pannakse enamike kasutusjuhtude tekstilised kirjeldused kirja lühiformaadis (nimi, tegutsejad, lühikirjeldus) ning kõige olulisemate kasutusjuhtude korral esitatakse tekstiline kirjeldus laiendatud formaadis. Laiendatud formaadis kasutusjuhu kirjeldus sisaldab järgmisi osi. - Kasutusjuhu nimi. - Tegutsejad. - Kasutusjuhu täitmise tulemusel saavutatav eesmärk. Siin võib välja tuua eesmärgid erinevate tegutsejate jaoks. - Lühikirjeldus, mis võtab paari lausega kasutusjuhu kokku. - Kasutusjuhu käivitav sündmus. - Eeltingimused, mis peavad olema täidetud, et kasutusjuhu võiks käivitada. - Järeltingimused, mis peavad olema täidetud, et kasutusjuhu võiks kuulutada edukalt lõppenuks. - Tüüpiline sündmuste käik e. põhistsenaarium. - Alternatiivsed (mitte-tüüpilised) süsteemi kasutamise stsenaariumid ehk laiendused. Iga alternatiivse stsenaariumi juures peaks olema viide põhistsenaariumi sammule kust võib see alternatiivne stsenaarium alata. Stsenaariumid pannakse kirja kasutaja ja süsteemi vahelise dialoogina. Domeenimudel, kus kirjeldatakse funktsionaalse allsüsteemi skoopi kuuluvad mõisted ja nendevahelised seosed. Kuna tegemist ei ole mitte andmemudeli vaid domeenimudeliga, siis on lubatud ka selliste mõistete/seoste esitamine, millele vastavaid andmeid ei ole vaja andmebaasis hoida. Domeenimudel on aluseks kontseptuaalse andmemudeli koostamisele ja samuti objekt-orienteeritud tarkvara disaini jaoks kandidaatklasside valimisele Registrite kirjeldused Kuidas kirjeldada strateegilise analüüsi dokumendis registreid? Iga registri kohta tuleks esitada: Taust, kus selgitatakse vabas vormis, milliseid andmeid hoitakse registris ning milleks seda registrit vaja läheb. Taoline mitteformaalne kõrgtaseme kirjeldus võimaldab huvilisel (näiteks infosüsteemi vajava organisatsiooni juhtkonna liikmel, kellel teadagi on alati liiga vähe aega) saada kiiresti registri olemusest ülevaade. Eesmärgid, mida register aitab saavutada. Eesmärkide sõnastamisel tuleks pidada silmas, et eesmärgid peaksid olema mõõdetavad, st. peale 22

23 registri realiseerimist peaks olema võimalik üheselt kindlaks teha kas eesmärk on täidetud või mitte (tõmmake näiteks paralleele poliitikute antavate lubadustega). Näide üldsõnalisest eesmärgist, mille täidetust on raske mõõta: Lihtsustada õpingukava registreerimist. Näide konkreetsest eesmärgist, mille täidetust on võimalik mõõta: Võimaldada registreerida kõiki sündmuseid (sündmuse toimumise aeg, sündmuse põhjustanud subjekt, seisund, millesse õpingukava läks sündmuse tulemusena), mis põhjustavad õpingukava seisundi muutumist. Pädevusalad mille esindajad pöörduvad (funktsionaalsete allsüsteemide kaudu) registri poole. Tuleb määrata kindlaks pädevusalad, mille esindajad haldavad seda registrit, st. loevad/lisavad/muudavad/kustutavad selles registris olevaid andmeid. Samuti tuleb määrata kindlaks pädevusalad, mille esindajad ainult loevad selles registris olevaid andmeid. Funktsionaalsed allsüsteemid mis pöörduvad registri poole. Tuleb määrata kindlaks, milliste funktsionaalsete allsüsteemide kaudu toimub selle registri andmete haldamine (lugemine/ lisamine/ muutmine/ kustutamine). Samuti tuleb määrata kindlaks, millised funktsionaalsed allsüsteemid ainult loevad selles registris olevaid andmeid. Registrite seosed pädevusalade ja funktsionaalsete allsüsteemidega võib esitada kasutades risttabeleid Infovajadused, mida registri poolt esitatav andmebaasi alamosa aitab rahuldada. Infovajadused on päringud millele andmebaasi põhjal soovitakse vastust. Seosed teiste registritega. Tuleb kirjeldada milliste teiste sama süsteemi registritega on vaadeldaval registril ühiseid olemitüüpe. Samuti tuleb teha kindlaks milliste teiste süsteemide registritega on sellel registril ühiseid olemitüüpe või toimub andmevahetus. Näiteks Joonis 3 põhjal on ülikooli infosüsteemis õpingukavade register ja töötajate register seotud õpingukava sündmuse kaudu. Iga õpingukava kohta tuleb registreerida sellega toimunud sündmused (loomine, esitamine, kinnitamine jne), sealhulgas ka andmed sündmuse põhjustaja kohta. Registrite projekteerimise käigus tuleb otsustada kas õpingukava sündmuse andmed kuuluvad töötajate registrisse, õpingukavade registrisse või moodustavad hoopis omaette registri. Töötaja kes põhjustas Õpingukava sündmus Õpingukava Töötajate register Õpingukavade register Joonis 3 Registrite omavahelise seose näide. 23

24 Kontseptuaalse andmemudeli eskiis, millel esitatakse kõige olulisemad olemitüübid ja seosetüübid. Eskiismudelis joonistatakse olemitüüpidele vastavad "kastid" ning nende olulistele seostele vastavad "kriipsud". Muude detailide (nagu olemitüüpide atribuudid, seosetüüpide omadused) valikuline kajastamine eskiismudelis on sageli kasulik, kuid omab paratamatult juhuslikku iseloomu ning pole seepärast kohustuslik. Strateegilise analüüsi käigus ei jää aega et allsüsteeme detailselt modelleerida ning see ei ole ka strateegilise analüüsi eesmärk. Kontseptuaalse andmemudeli koostamine viiakse lõpule detailanalüüsi käigus. Allsüsteemide leidmine võimaldab süsteemi paremini ja ülevaatlikumalt kirjeldada. Evitts (2000) märgib, et ülevaatlikul diagrammil võiks olla 7+/-2 omavahel loogiliselt seotud elementi. Näiteks registrite leidmine annab võimaluse koostada ülevaatlikud olemi-suhte diagrammid. Selle asemel, et koostada andmebaasi kui terviku kohta üks suur diagramm kus on kümneid või sadu elemente, saame iga registri kohta koostada üks või mitu eraldi diagrammi, mis rahuldavad Evitts (2000) esitatud nõudeid Muud dokumendid Allsüsteemide vahelised seoste paremaks esitamiseks võib kasutada risttabeleid (vt. Tabel 4 Tabel 6) või UMLi paketidiagramme. Tabel 4 Pädevusalade ja funktsionaalsete allsüsteemide vastavustabeli näide. Õppeainete arvestus Õpingukava de arvestus Üliõpilaste arvestus Üliõpilase pädevusala Õppejõu Dekanaadi sekretäri pädevusala pädevusala X X X X X X X X X X Tabel 4 lahtris näitab, et pädevusala kasutab selle funktsionaalse allsüsteemi teenuseid. Tabel 5 Pädevusalade ja registrite vastavustabeli näide. Õppeainete register Õpingukava de register Üliõpilaste register Üliõpilase pädevusala Õppejõu Dekanaadi sekretäri pädevusala pädevusala R R R CRUD RU R R R RU Mida tähendavad tähed Tabel 5 lahtrites? C (Create, loo) pädevusala esindajad lisavad registrisse andmeid. R (Read, loe) pädevusala esindajad loevad registrist andmeid. U (Update, muuda) pädevusala esindajad muudavad registris andmeid. 24

25 D (Delete, kustuta) pädevusala esindajad kustutatavad registrist andmeid. Tabel 6 Funktsionaalsete allsüsteemide ja registrite vastavustabeli näide. Õppeainete register Õpingukava de register Üliõpilaste register Õppeainete arvestus Õpingukavade Üliõpilaste arvestus arvestus CRUD R R CRUD RU R CRUD Mida tähendavad tähed Tabel 6 lahtrites? C (Create, loo) funktsionaalne allsüsteemi kaudu lisatakse registrisse andmeid. R (Read, loe) funktsionaalne allsüsteemi kaudu loetakse registrist andmeid. U (Update, muuda) funktsionaalne allsüsteemi kaudu muudetakse registris andmeid. D (Delete, kustuta) funktsionaalne allsüsteemi kaudu kustutatakse registrist andmeid. Tabel 5 ja Tabel 6 on CRUD maatriksi erijuhud (vt jaotis 5.4). Allsüsteemide vaheliste seoste esitamiseks võib kasutada ka paketidiagramme ehk paketiskeeme, kus näidatakse pakette ja nende sõltuvusi (vt. Joonis 4). Joonis 4 Allsüsteemide vaheliste seoste kujutamine klassidiagrammil. UMLis on võimalik pakettide abil grupeerida suvalisi UMLi elemente kokku üldisemateks üksusteks (Fowler, 2007). Paketti tähistab diagrammil sakiga kaust. Paketi nimeks on allsüsteemi nimi. Stereotüüp <<subsystem>> viitab, 25

26 et pakett tähistab allsüsteemi. Paketid võivad kuuluda teistesse pakettidesse, moodustades hierarhilise struktuuri. Näiteks Joonis 4 näitab paketil esitatud fraas "from Pädevusalad", et see pakett kuulub paketti Pädevusalad. Lisaks tuleb strateegilise analüüsi käigus koostada arhitektuuri ja arendusvaade. Nende alamdokumentide struktuuri antud kursuses ei esitata. Arhitektuurivaade. Kirjeldatakse allsüsteemide paigutus erinevates asukohtades ja tehniline arhitektuur tarkvara, riistvara, arvutivõrgud. Arendusvaade. Kirjeldatakse süsteemi loomiseks käivitatavad projektid, nende ajaline järjekord ja prioriteedid. Kirjeldatakse kasutatav projektorganisatsioon. Kirjeldatakse võimalikud arendamisega seotud riskid. Antakse esialgne hinnang arendamise maksumusele. 4.6 Projekti planeerimine Projekt on Mikli (1999) põhjal "kindla ajavahemiku ja finantsidega ning formuleeritud eesmärkidega ellu viidav muudatus või arendamine." Projekti omadused: toimub mingi ajaperioodi jooksul; hõlmab palju töid, mida tehakse erinevate projekti osaliste poolt; tööd selles on organiseeritud, mitte ei toimu kaootiliselt; on mõeldud eesmärgi saavutamiseks; kasutab meeskonnatööd. Strateegilise analüüsi üheks ülesandeks on süsteemi arendamise strateegia loomine, milles määratletakse süsteemi arendamiseks algatatavad projektid, nende prioriteedid, ressursivajadused, riskid ja projektorganisatsioon. Mikli (1999) põhjal on suurte projektide süsteemiarenduses kasutamisel üldjuhul viga selles, et arvutisüsteemi ei õnnestu kohe rakendada. See võib olla tingitud infosüsteemi vajava organisatsiooni vähesest valmisolekust või tulevaste kasutajate oskamatusest. Mitme projektiga arendamisel on aga probleemiks, kuidas jaotada süsteemi arendamine osadeks projektideks? Projektide leidmine ongi strateegilise analüüsi üheks eesmärgiks. Kui süsteemiarendus toimub kose mudeli alusel, siis strateegilisele analüüsile (vt. Joonis 1) järgneb kõikide allsüsteemide detailanalüüs, disain, ehitamine, rakendamine ja hooldamine. Kuid kuidas kasutada süsteemi arendamiseks üheskoos strateegilist analüüsi ja iteratiivsel mudelil põhinevat süsteemiarendust? Strateegilise analüüsi arendusvaates planeeritakse projektid infosüsteemi valmis tegemiseks. Üks projekt hõlmab ühe või mitme allsüsteemi analüüsi/disaini/ehitamist/rakendamist. Iga projekt võib omakorda koosneda lühikestest (2 6) nädalat iteratsioonidest, mille käigus projekteeritakse, ehitatakse ja rakendatakse mingi allsüsteemi osa. Lisaks võib olla vaja käivitada koolituse või andmete kvaliteedi parandamise projekte, et uuele süsteemile saaks üle minna. 26

27 süsteemi funktsionaalsus Allsüsteemide arendusprojekt Allsüsteemide arendusprojekt Strateegiline analüüs aeg Joonis 5 Süsteemiarendus mitme projektiga. Strateegilise analüüsi käigus tuleks määrata kindlaks ka projektide prioriteedid. Hoberman (2001) kirjeldab prioriteetide kolmnurka, mille abil saab määrata arendusprojekti üldisi eesmärke. Projekti tulemus on kõrge kvaliteediga Projektile kulub vähe aega Joonis 6 Projekti prioriteetide kolmnurk. Projekti kulud on väikesed Ideaalne oleks saavutada kõik kolm prioriteetide kolmnurgas esitatud eesmärki. Kuid see on võimatu ning maksimaalselt on võimalik saavutada kaks eemärki kolmest. Kõrge kvaliteediga tulemus saavutataks minimaalse ajaga. Sobilik projektide jaoks, mille tulemus on ülioluline näiteks teisi projekte ei saa alustada enne, kui see on lõppenud. Sellise projekti läbiviimiseks on vajalikud kõrgetasemelised täitjad ning suurepärane töökeskkond, ning see suurendab projekti läbiviimiseks vajalikke kulusid. Kõrge kvaliteediga tulemus saavutatakse minimaalse hinnaga. Sobilik projektide jaoks, kus on võimalik võtta arendamist rahulikult ja veenduda igal sammul, et ei kulutata liigseid ressursse. Minimaalse hinnaga tulemus saavutatakse minimaalse ajaga. Sobib prototüübi koostamise projektide jaoks, kus tuleb kiiresti teha valmis 27

28 esialgne lahendus, millele kasutajad saavad hakata andma oma hinnanguid. Seda kasutatakse näiteks kasutajate käest tarkvarasüsteemile esitatavate nõuete kogumiseks. 5. Detailanalüüs Detailanalüüsi eesmärkideks on: strateegilise analüüsi tulemustena saadud allsüsteemide täpsem analüüs ja modelleerimine; disaini ettevalmistamine; Detailanalüüsi käigus toimub valitud allsüsteemi(de) detailne toimimistasemeline (see tähendab sisuline, tehnilisest lahendustest sõltumatu) modelleerimine. Koostöös tellija ning tulevaste kasutajatega täpsustatakse strateegilise analüüsi käigus koostatud eskiismudeleid kõigi toimimistasemel vajalike detailide kättesaamiseni. Kui ollakse aru saanud ärivajadustest, on kasulik otsida turult mudeleid, valida sobiv ning kohandada oma organisatsioonile. See tähendab mustrite ja universaalsete mudelite kasutamist ja sellest tuleb juttu teemas nr Pädevusalade allsüsteemide kirjeldused Kirjelduse alguses on tausta, eesmärkide ning allsüsteemi seoste täpsustatud kirjeldus Objektivaade Pädevusala infovajadusi kirjeldav domeenimudel, kus on näidatud kontseptid, atribuudid, seosed Protsessivaade Pädevusala tööprotsesside kirjeldus, mis on esitatud kasutusjuhtude diagrammidena. Nendel on välja toodud kõik kasutusjuhud, milles antud pädevusala liige osaleb Sündmusvaade Pädevusala kasutusjuhtude tekstilised kirjeldused laiendatud formaadis (vt. funktsionaalse allsüsteemi kasutusjuhtude kirjeldusi). 28

29 5.2 Funktsionaalsete allsüsteemide kirjeldused Kirjelduse alguses on tausta, eesmärkide ning allsüsteemi seoste täpsustatud kirjeldus Objektivaade Allsüsteemi kirjeldav domeenimudel Protsessivaade Allsüsteemi põhiprotsessid kasutusjuhtude diagrammidena Sündmusvaade Tuleb täpsustada strateegilise analüüsi käigus leitud kasutusjuhtude kirjeldusi ning vajadusel lisada juurde uusi kasutusjuhte. Kõik kasutusjuhud tuleks kirjutada lahti laiendatud formaadis. Kasutusjuhtude tekstikirjelduste muutmisel ei tohi unustada teha vastavaid muudatusi kasutusjuhtude diagrammides. Laiendatud formaadis kasutusjuhu kirjelduses sisalduvad stsenaariumid kirjeldavad seansisiseseid sündmuseid. Detailanalüüsi tulemusena selgitatakse välja taolistele sündmustele reageerimiseks vajalikud andmebaasioperatsioonid. Andmebaasioperatsioonid kirjeldatakse registrite vaates lepingute abil. Stsenaariumitesse tuleb lisada viited andmebaasioperatsioonide lepingutele. 5.3 Registrite kirjeldused Kirjelduse alguses on tausta, eesmärkide ning allsüsteemi seoste täpsustatud kirjeldus Objektivaade Objektivaates esitatakse täpsustatud kontseptuaalne andmemudel. Kontseptuaalse andmemudeli võimalikud koostisosad: Olemi-suhte diagrammid (Siin tuleb näidata ka kõigi seoste nimed). Olemitüüpide definitsioonide tabel (olemitüübi nimi (ka aliased kui neid on), register kuhu olemitüüp kuulub, DEFINITSIOON). Atribuutide definitsioonide tabel (olemitüübi nimi, atribuudi nimi (ka aliased kui neid on), kirjeldus, näidisväärtused). Võib dokumenteerida ka: üldine andmetüüp ja pikkus - liht- või liitatribuut? 29

30 - ühe- või mitmeväärtuseline atribuut? - tuletatud atribuut? Kui jah, siis ka tuletusreeglid. - vaikimisi väärtus. Seosetüüpide definitsioonid: - seosetüübis osalevad olemitüübid, - seosetüübi võimsus, - seosetüübis osalevate olemitüüpide osaluskohustus Protsessivaade Detailanalüüsi tulemusena tuleb kirjeldada kasutusjuhtude mudeli koostamise käigus leitud andmebaasioperatsioone. Andmebaasioperatsioonide kirjeldamiseks võib kasutada lepingu formaati. Lepingud tuleks kirjutada kõige olulisemate ja keerulisemate operatsioonide kohta. Miks öeldakse, et operatsioon kirjeldatakse lepingu formaadis? Leping sätestab lepingu sõlminud osapoolte õigused ja kohustused. Operatsiooni kirjelduses vaadeldakse süsteemi kui musta kasti ning ei selgitata kuidas operatsiooni läbi viia (selle otsustamine on disaini ülesanne). Operatsiooni eeltingimused deklareerivad süsteemipoolseid kohustusi. See tähendab, et süsteem peab operatsiooni õnnestumiseks tagama, et eeltingimused on täidetud. Operatsiooni järeltingimused deklareerivad operatsioonipoolseid kohustusi. See tähendab, et kui süsteem täidab talle pandud kohustused, siis vastutasuks võib ta oodata, et operatsioon täidab omakorda talle pandud kohustused ja viib andmebaasis läbi järeltingimustes näidatud muudatused. Iga lepingu spetsifikatsioon sisaldab järgnevaid osi: Operatsiooni nimetus parameetritega. Eeltingimused. Kirjeldavad, millised andmed olemite ja seoste kohta peavad olema lisatud, muudetud või kustutatud, et operatsiooni saaks alustada. Järeltingimused. Kirjeldavad, millised andmed olemite ja seoste kohta peavad olema lisatud, muudetud või kustutatud, et operatsiooni võiks edukalt lõpetada. Larman (2002) toob näite teatri põhjal. Kujutlege, et viibite teatris ja jälgite laval toimuvat. Enne operatsiooni algust heidate pilgu lavale ja jätate meelde kuidas rekvisiidid ja näitlejad on lavale paigutatud. Operatsiooni ajal langeb lava ette eesriie, mis operatsiooni lõppedes uuesti üles tõstetakse. Nüüd on teie ülesanne kirja panna, mis on rekvisiitide ja näitlejate osas laval operatsiooni käigus muutunud (kes/mis on juurde tulnud, ümberpaigutatud või lavalt kadunud). Kasutus kasutusjuhtude poolt. Viited kasutusjuhtudele, mis antud operatsiooni kasutavad ja funktsionaalsetele allsüsteemidele, mida nimetatud kasutusjuhud kirjeldavad. Järgnevalt esitame näitena andmebaasioperatsiooni lepingu nimega Õpingukava loomine. Lepingu spetsifikatsioonis on kursiivis esitatud 30

31 kontseptuaalses andmemudelis kirjeldatud olemitüüpide nimed. Lepingu nime järel on sulgudes näidatud lepingu parameetrid. Näiteks operatsiooni poole pöördumisel peab parameetri üliõpilaneid väärtuseks olema üliõpilase unikaalne identifikaator. Õpingukava loomine (üliõpilaneid, semesterid, tüüpõpingukavaid) Eeltingimused: o Üliõpilane, Semester, Tüüpõpingukava ja Õpingukava_seisundi_liik on registreeritud. Järeltingimused: o On loodud Õpingukava. o Õpingukava on seotud Tüüpõpingukavaga, mille alusel õpingukava koostatakse. o Õpingukava on seotud Üliõpilasega, kes seda õpingukava koostab. o Õpingukava on seotud Semestriga, millal see õpingukava kehtib. o Õpingukava on seotud Õpingukava_seisundi_liigiga, mille puhul Õpingukava_seisundi_liik.nimetus="koostamisel". Millised on mõned olulised punktid, millele lepingu kirjutamisel tähelepanu pöörata? Andmebaasioperatsioonide identifikaatorid peavad olema lisatud kasutusjuhu laiendatud formaadis tekstilisse kirjeldusse. Lisaks operatsiooni sisu selgitavale nimele (nt Õpingukava koostamine) võib operatsiooni identifitseerimiseks võtta kasutusele mõne lühema identifikaatori (nt OP1), mida on mugavam kasutusjuhtude tekstikirjelduses kasutada. Lepingu järeltingimuses peab olema näidatud ka seoste tekkimine/kadumine Eel- ja järeltingimustes peab kasutama sama terminoloogiat kui kontseptuaalses andmemudelis. Lepingu järeltingimustes ei tule kirjeldada muutusi väljaspool andmebaasi nt. muudatus kasutajaliideses. Andmebaasioperatsioonide lepingute järeltingimustes tuleb kirjeldada ainult seda, mis andmebaasis operatsiooni tulemusel muutus. Seda mis jäi samaks ei ole vaja kirja panna! Iga seisundidiagrammil esitatud seisundi ülemineku kohta peab leiduma andmebaasioperatsioon, mille tulemusena tehakse andmebaasis muudatus, et seda seisundimuudatust registreerida. Andmebaasioperatsioonide kogumist võib mõelda kui liidesest, mille kaudu funktsionaalne allsüsteem kasutab registri allsüsteemi poolt pakutavaid teenuseid. Andmebaasioperatsioonid kapseldavad andmebaasi. Kapseldamine on objekt-orienteeritud disainist tuntud mõiste ja tähendab, et elemendi sisemist struktuuri peidetakse ja elementi saab kasutada ainult avaliku liidese kaudu. Kuidas liidese pakutavad teenused on realiseeritud pole teenuse kasutaja asi. Teisisõnu aitab kapseldamine peita ebaolulist informatsiooni teiste elementide eest. Kapseldamine võimaldab teenuse pakkumise mehhanismi muuta, jättes samal ajal avaliku liidese muutmata. Antud juhul on kapseldatavaks 31

32 elemendiks andmebaas. Andmebaasioperatsioonide lepingud defineerivad andmebaasi kasutamiseks mõeldud liidese. Näiteks SQL andmebaasis võib operatsioonid realiseerida andmebaasiserveris talletatud rutiinidena või vaadetena, mida kasutavad kõik andmebaasi poole pöörduvad programmid. Rutiinid ja vaated on andmebaasi programmeerija kontrolli all ja neid saab vajadusel muuta nii (näiteks optimeerida SQL lauseid), et kasutaja ei pea kuidagi muutma rutiini/vaate poole pöördumist Sündmusvaade Koostatakse registri põhiolemitüübi seisundidiagramm e. olekumasinaskeem, mis kirjeldab kõikvõimalikud seisundid, milles sellesse olemitüüpi kuuluvad olemid võivad viibida ning lubatud siirdeid e. üleminekuid ühest seisundist teise. Iga siire on põhjustatud mingi sündmuse poolt. Seisundidiagrammi kohta lugege täpsemalt M. Fowlery raamatu (Fowler, 2007) peatükist nr. 10. Seisundidiagramm peab vastama järgmistele reeglitele. Täpselt üks algne pseudoseisund Üks või mitu lõppseisundit. Seisunditel on nimed. Mõnikord jäetakse küll algsele pseudoseisundile nimi andmata. Igale seisundi üleminekule on kirjutatud sündmus, mis seda põhjustab. Algsest pseudoseisundist saab seisundi üleminekute kaudu mistahes teise seisundisse. Nõue andmebaasile: andmebaasis tehtud päringuga saab kindlaks teha olemi seisundi käesoleval ajahetkel. Järgnevalt esitatav olemi-suhte diagrammi fragment demonstreerib sellist andmebaasi struktuuri mis võimaldab registreerida andmeid nii objekti hetkeseisundi, kui ka selle seisundi muudatuste kohta. 32

33 Joonis 7 Olemi-suhte diagramm seisundi ajaloo registreerimise kohta. 5.4 CRUD maatriks Erinevat tüüpi mudelid esitavad erinevaid vaateid süsteemile. Mudelid peavad olema omavahel kooskõlas, et anda süsteemist korrektne ülevaade ning võimaldada luua korrektne süsteemi realisatsioon. Andmevaadet ja protsessivaadet esitavate mudelite omavahelise kooskõla kontrollimiseks võib kasutada CRUD maatriksit. Maatriksi nimi on akronüüm, mis tuleneb sõnadest "Create", "Read", "Update", "Delete". (Loo, Loe, Muuda, Kustuta). Akronüüm on mitme sõna algustähtedest moodustatud lühinimetus. Eeldame, et andmevaate esitamiseks kasutatav kontseptuaalne andmemudel sisaldab olemi-suhte diagramme ja protsessivaate kirjeldamiseks kasutatakse kasutusjuhtude mudelit. Sellisel juhul peab iga atribuudi/seosetüübi kohta leiduma kasutusjuht, kus:... on kirjeldatud toiming, mille käigus atribuut väärtustatakse/seos tekitatakse (Create).... on kirjeldatud toiming, mille käigus atribuudi väärtust/seost loetakse (Read). Näiteks, kui andmeid ainult luuakse, kuid ühegi kasutusjuhu käigus ei loeta, siis tekib küsimus, miks on vaja koguda andmeid mida keegi ei kasuta. Kui leidub kasutusjuht, mille käigus andmeid loetakse, kuid ühegi kasutusjuhu käigus neid andmeid ei looda, siis on selge, et süsteemi kirjeldus ei ole täielik. Lisaks võib leiduda kasutusjuht, kus:... on kirjeldatud toiming, mille käigus atribuudi väärtust/seost muudetakse (Update). 33

34 ... on kirjeldatud toiming, mille käigus atribuudi väärtus/seos kustutatakse (Delete). Kustutada tuleb andmed, mille kustutamist nõuab seadus, määrus või organisatsioonisisene praktika. Andmete kustutamist võib olla vaja sisestusvigade parandamiseks. Andmete kustutamist tuleb alati põhjalikult kaaluda, sest kustutatud andmeid võib tulevikus näiteks analüüsimise otstarbel vaja minna. Infosüsteemi võib luua nii, et enne operatiivandmete andmebaasist kustutamist laaditakse andmed andmeaita või andmevakka, et neid oleks võimalik hiljem analüüside läbiviimiseks kasutada. On võimalik, et isegi kui kasutajaliideses jäetakse kasutajale mulje, et ta andis kustutamise korralduse, siis tegelikult muudetakse kustutatava andmeobjekti seisundit ja see säilib andmebaasis. Kasutaja neid andmeid enam ei näe. CRUD maatriksi võib luua erineva täpsusega. Andmevaate võib maatriksis esitada näiteks registri, olemitüübi või atribuudi/seosetüübi täpsusega. Järgnevalt tuuakse näide olemitüübi täpsusega maatriksist. Protsessivaate võib esitada näiteks funktsionaalse allsüsteemi, kasutusjuhu või toimingu täpsusega. Järgnevalt tuuakse näide kasutusjuhu täpsusega maatriksist. Näide: Kasutusjuhud (protsessivaade) Lugejaks saamine Trükise laenutamine Trükise tagastamine Lugejaks oleku lõpetamine Trükis R, U R, U Lugeja C R R R, U Laenutamine C R, U R Olemitüübid (andmevaade) Joonis 8 CRUD maatriksi näide. Lugejaks saamise käigus registreeritakse andmebaasis uus lugeja (CREATE). Trükise laenutamise käigus loetakse (READ) trükise ja lugeja andmed. Seejärel registreeritakse andmebaasis uus laenutamine (CREATE). Lõpuks muudetakse trükise seisundit (UPDATE), näitamaks selle väljalaenutamist. Trükise tagastamise käigus loetakse (READ) kontrolli eesmärgil trükise, lugeja ja laenutamise andmed. Registreeritakse laenutamise tegelik 34

35 lõppemise aeg (UPDATE). Lõpuks muudetakse trükise seisundit (UPDATE) näitamaks, et trükist saab uuesti laenutada. Lugejaks oleku lõpetamise korral loetakse (READ) laenutamise andmeid, et teha kindlaks, ega ei ole veel lõppemata laenutusi. Seejärel loetakse lugeja andmed ning muudetakse lugeja seisundid (seisund:="arhiveeritud") (UPDATE). 35

36 6. Tootmisettevõtte näide Tabel 7 Tootmisettevõtte IS üldvaate fragment. Põhiobjektid Tellimus Toote kavand Plaan toote loomiseks Töövahendi kavand Töövahend Materjal Toode Saadetis Klient Töötaja Põhilised sündmused Klient esitab palve toote ostuks Tellimus kiidetakse heaks Tellimus lükatakse tagasi Tegemist on uudse tootega Laoseisu kontroll näitab, et laos on piisavalt toodet, et tellimust rahuldada Laoseisu kontroll näitab, et laos pole piisavalt toodet, et tellimust rahuldada Projekteerija lõpetab toote disaini Tootja palub luua vajalikud töövahendid Tootja palub materjale Insener lõpetab töövahendi disaini Tootja saab töövahendi valmis ja hankija saab materjali hangitud Tootja lõpetab tootmise Inspekteerija avastab loodud tootes vigu Klient saab ostetud toote kätte Töötaja alustab tööd Põhiprotsessid Müük Toote disain Planeerimine Töövahendite disain Materjalide hankimine Töövahendite tegemine Tootmine Kohaletoimetamine Töötajate haldamine Tegutsejad Klient Müüja Projekteerija Tootja Insener Hankija Inspekteerija Käskjalg Personalijuht 36

37 Tabel 8 Tootmisettevõtte IS võimalik tükeldus allsüsteemideks. Pädevusala allsüsteemid Kliendi pädevusala Müüja pädevusala Projekteerija pädevusala Tootja pädevusala Inseneri pädevusala Hankija pädevusala Inspekteerija pädevusala Käskjala pädevusala Personalijuhi pädevusala Registrid Tellimuste register Kavandite register Valmistoodete register Materjalide ja vahendite register Töötajate register Saadetiste register Klientide register... Funktsionaalsed allsüsteemid Müügi arvestus - Toote tellimuse registreerimine - Kliendi registreerimine -... Tootearenduse arvestus - Kavandi koostamine - Kavandi täiendamine -... Tootmise arvestus - Tootmise registreerimine - Valminud kauba registreerimine - Kadude registreerimine - Kvaliteedikontroll -... Materjalide arvestus - Tarnija registreerimine - Tellimuse koostamine - Materjalide vastuvõtt - Materjali inspekteerimine -... Töötajate arvestus - Töötaja registreerimine - Töötaja lahkumise registreerimine -... Saadetiste arvestus - Saadetise registreerimine - Kohaletoimetamise registreerimine... 37

38 7. Kontseptuaalne andmemudel Infosüsteemi projekteerimise käigus läbiviidava strateegilise ja detailanalüüsi olulises tulemuseks on kontseptuaalne andmemudel. Kontseptuaalne andmemudel on mittetehniline mudel, mis kirjeldab süsteemi baasandmeid. Ta kirjeldab nõudeid andmebaasile, aga mitte andmebaasi tehnilist realisatsiooni. Seega kontseptuaalses andmemudelis ei pöörata tähelepanu ühelegi andmebaasi realiseerimisega seotud asjaolule, nagu: andmemudel (näiteks relatsiooniline mudel), kasutatav andmebaasisüsteem, kasutatav riistvara platvorm, kasutatava arvutivõrgu ülesehitus, töökiiruse küsimused. Kontseptuaalne andmemudel on aluseks andmebaasi tehniliste kavandite loomisele, mis arvestavad andmemudeliga (näiteks relatsiooniline mudel) ning andmebaasi loomiseks kasutatava tarkvara- ja riistvara platvormiga (sealhulgas kasutatava andmebaasisüsteemiga). Kontseptuaalse andmemudeli esialgsed visandid e. eskiisid luuakse strateegilise analüüsi käigus ning mudeli koostamine viiakse lõpule detailanalüüsi käigus. Date (2003) nimetab kontseptuaalse andmemudeli koostamist andmebaasi semantiliseks modelleerimiseks. Semantiline mudel üritab kirjeldada süsteemi tähendust. Kontseptuaalne andmemudel kirjeldabki süsteemis säilitama hakatavate andmete tähendust, struktuuri ning andmetega seotud kitsendusi. Öeldakse ka, et kontseptuaalne andmemudel valmib andmebaasi kontseptuaalse disaini tulemusena. Kontseptuaalse andmemudeli oluliseks koostisosaks on visuaalne mudel (diagramm), mis kirjeldab andmebaasi kontseptuaalset struktuuri. Kaks levinud diagrammi tüüpi (ja tegelikult ka vastavat modelleerimise viisi) taolise informatsiooni esitamiseks on: Olemi-suhte diagramm (inglise keeles entity-relationship diagramm, ERD) Objekti-rolli mudel (inglise keeles object-role model, ORM) ( Kontseptuaalse andmemudeli võimalikku struktuuri kirjeldab järgmine valem: Kontseptuaalne andmemudel = andmebaasi kontseptuaalset struktuuri esitavad diagrammid + diagrammide elementide tekstilised spetsifikatsioonid (semantika kirjeldus) + andmetega seotud kitsenduste spetsifikatsioonid. Väga levinud meetodiks on kasutada kontseptuaalse andmebaasi disaini tulemuste esitamiseks olemi-suhte diagramme. Tänapäeval luuakse olemisuhte diagrammid sageli kasutades UMLi klassidiagramme. UML oli algselt mõeldud objekt-orienteeritud analüüsi ja disaini läbiviimiseks, kuid selle 38

39 laiendusmehhanismid võimaldavad teda kasutada universaalse keelena paljude modelleerimisülesannete lahendamiseks. 7.1 Olemi-suhte diagramm Väga levinud meetodiks on kasutada kontseptuaalse andmebaasi kirjeldamiseks olemi-suhte diagramme. Olemi-suhte diagrammid pakuti Peter Cheni poolt välja 1970-ndate keskel (Chen, 1976). Chen soovis luua esitusviisi, millega saaks modelleerida nii hierarhilisi-, võrk-, kui ka relatsioonilisi andmebaase pakuti välja laiendatud olemi-suhte diagramm (Theory et al., 1986). Muuhulgas võimaldas see laiendus kirjeldada üldistusseoseid. Aja jooksul on välja pakutud palju erinevaid märgisüsteeme e. notatsioone, mida saab kasutada olemi-suhte diagrammide joonistamiseks. Üks tuntud märgisüsteem on näiteks Richard Barkeri poolt väljapakutud Barkeri märgisüsteem (Barker, 1990). Selle võttis kasutusele Oracle Corporation integreerides selle arendusmetoodikaga Oracle*CASE ning CASE (Comupter Aided System Engineering) vahendiga Oracle Designer. Taolist märgisüsteemi kasutatakse ka näiteks L. Silverstoni koostatud universaalseid andmemudeleid esitavates raamatutes (Silverston, 2001a; Silverston, 2001b). Olemi-suhte diagramm on staatikadiagramm, mis kirjeldab süsteemi struktuuri aspekti. Haridusaste_liik nimetus : String Õppeaine_seisundi_liik nimetus : String +kõrgeim 1 saavutatud aste iseloomustab 0..* Õppejõud eesnimi : String perenimi : String sünniaeg : Date 1 0..* Õpetamine alguse_aeg : Date lõpu_aeg : Date 0..* +hetkel kehtiv seisund 1 0..* 1 iseloomustab Õppeaine ainekood : String nimetus : String pikk_kirjeldus : String ainepunkte : Double Joonis 9 Olemi-suhte diagrammi näide. Tänapäeval luuakse olemi-suhte diagrammid sageli kasutades UMLi klassidiagramme. UML oli algselt mõeldud objekt-orienteeritud analüüsi ja disaini läbiviimiseks, kuid selle laiendusmehhanismid võimaldavad teda kasutada universaalse keelena paljude modelleerimisülesannete lahendamiseks. 39

40 Käesolevas raamatus käsitleme me kontseptuaalse andmemudeli koostamist kasutades selleks UMLis loodud olemi-suhte diagramme Olemi-suhte diagrammi komponendid Olemi-suhte diagrammil esitatakse olemitüübid, olemitüüpide vahelised seosetüübid ning olemitüüpide atribuudid. Igale kontseptuaalses andmemudelis esitatud olemitüübile vastab reaalses maailmas (objektsüsteemis) eksisteeriv konkreetne või abstraktne objekt (asi, olem), mille kohta tuleb andmebaasis andmeid säilitada. Valiku aitavad teha modelleerija enda kogemused ning teiste arendajate kogemused mis võivad olla esitatud mustrite või taaskasutatavate mudelite abil Olemitüüp Olem: Suvaline konkreetne või abstraktne asi, mis eksisteerib, eksisteeris või võiks eksisteerida, kaasa arvatud nende asjade ühendused. Üksikuid olemeid olemi-suhte diagrammil ei esitata. Olemi-suhte diagrammil esitatakse olemite üldistused olemitüübid. Näiteks on olemid konkreetsed õppeained nagu "Andmebaaside projekteerimine" ainekoodiga IDU3381 ja "Andmebaaside programmeerimine" ainekoodiga IDU0120. Olemitüüp: Ühiste nimeliste omadustega olemite hulk. Võib öelda, et tegemist on reaalses maailmas eksisteerivate olemite üldistusega. Kontseptuaalses andmemudelis tuleb esitada sellised ja ainult sellised olemitüübid, millele vastavate olemite kohta soovitakse hakata hoidma andmebaasis andmeid. Segadust tekitab, et mõned allikad kasutavad termini "Olemitüüp" asemel terminit "Olem" ja termini "Olem" asemel terminit "Olemieksemplar". Olemi-suhte diagrammil esitatakse olemitüüp klassisümboli abil. Klassile võib määrata stereotüübi tõstmaks esile, et tegemist ei ole mitte tavalise tarkvaraklassiga, vaid see esitab kontseptuaalses andmemudelis olemitüüpi. Mis on stereotüüp? Stereotüüp on UMLi laiendusmehhanism, mis võimaldab luua uut tüüpi mudelielemente, tuletades neid olemasolevatest elementidest (nt. klass, atribuut, assotsiatsioon, pakett). Neil uutel elementidel on oma spetsiifilised omadused (sildid), semantika ja visuaalne tähistus. Joonis 9 oleval olemi-suhte diagrammil esitatakse olemitüübid Õppejõud, Õpetamine, Õppeaine, Haridusaste_liik ja Õppeaine_seisundi_liik. Nagu öeldud, võimaldab stereotüüp kasutada alternatiivset visuaalset tähistust. Joonis 10 esitatakse olemitüübid (Õppeaine_seisundi_liik ja Õppeaine), kasutades stereotüübi poolt määratud alternatiivset visuaalset tähistust. Segaduse vältimiseks on oluline, et ühes mudelis ei kasutataks läbisegi erinevaid visuaalseid tähistusi. 40

41 Joonis 10 Olemi-suhte diagrammi näide Seosetüüp Seos, suhe, side: Seos on tunnetatud ühendus olemite vahel. Üksikuid seoseid olemi-suhte diagrammil ei esitata. Olemi-suhte diagrammil esitatakse seoste üldistused seosetüübid. Näiteks: Õppejõud "Andres Mets" õpetab õppeainet "Tuumafüüsika" alates kuupäevast 1. september 2008 kuni kuupäevani 1. veebruar Seosetüüp e. suhtetüüp: Kontseptuaalses andmemudelis esitatav seosetüüp on selliste seoste üldistus, mille kohta tuleb andmebaasis andmeid säilitada. Olemi-suhte diagrammil esitatakse seosetüübid joontena. Seosetüübid võivad olla erinevat liiki (assotsiatsioon, osa-terviku seos, üldistusseos) ning nendest liikidest tuleb juttu edaspidi. Iga seosetüübi kohta tuleb kindlaks teha ning dokumenteerida ka selle omadused. Mis on ühe modelleerija jaoks seosetüüp, see on teise jaoks olemitüüp ja vastupidi. Näiteks süsteemi kirjeldava lause "Õppejõud õpetab õppeainet" põhjal võib leida olemitüübid Õppejõud ja Õppeaine. Kuid Õpetamine on võimalik modelleerida nii seosetüübina Õppejõud ja Õppeaine vahel kui ka olemitüübina. Kui seosetüübil on nimelisi omadusi, millele vastavaid andmeid tuleb andmebaasis hoida, siis tuleb see seosetüüp modelleerida olemitüübina. Antud juhul tuleks õpetamise kohta registreerida ka õpetamise alguse aeg ja lõpu aeg ning seetõttu on Joonis 9 esitatud ka olemitüüp Õpetamine. Roll: Roll kirjeldab olemitüübi tähendust seosetüübi kontekstis, milles ta osaleb. Rollid aitavad selgitada seosetüüpide tähendust. Olemi-suhte diagrammil esitatakse rollid seosetüüpide otstesse kirjutatud tekstina "+rollinimi". Eriti oluline on rollid määrata, kui kahe olemitüübi vahel on rohkem kui üks seosetüüp. Joonis 11 esitatud diagrammil on Töötaja ja Erakorraline kursus vahel kolm seosetüüpi. Iga erakorralise kursuse idee on pakutud välja null või ühe töötaja poolt, kes on rollis "õppejõud". Iga erakorraline kursuse idee on kinnitatud null või ühe töötaja poolt, kes on rollis "õppeosakonna töötaja". Iga erakorraline kursus on kinnitatud null või ühe töötaja poolt, kes on rollis "instituudi direktor". 41

42 0..1 pakub idee välja +õppejõud 0..* Töötaja õppeosakonna töötaja instituudi direktor kinnitab kinnitab 0..* Erakorraline kursus 0..* Joonis 11 Mitu seosetüüpi kahe olemitüübi vahel. Hotell : Olemitüüp (hotelli nimi) Sisaldab : Seosetüüp Ruum : Olemitüüp (ruumi nr.) Viru r1 1 Olümpia r2 r3 2 3 Olem Seos Joonis 12 Seosetüübi semantika. Seosetüübi aste: Seosetüübi aste on seosetüübis osalevate olemitüüpide (osaliste) arv. Seega näiteks: üheliikmelises e. unaarses seosetüübis osaleb üks olemitüüp (erinevates rollides) (vt. rekursiivne seosetüüp). kaheliikmeliikmelises e. binaarses seosetüübis osaleb kaks olemitüüpi. kolmeliikmelises e. ternaarses seosetüübis osaleb kolm olemitüüpi. Kõik Joonis 9 ja Joonis 11 esitatud seosetüübid on kaheliikmelised. Kaheliikmelised seosetüübid on olemi-suhte diagrammidel kõige levinumad. 42

43 Rekursiivne seosetüüp: Rekursiivne seosetüüp on seosetüüp, kus seosetüübi mõlemas otsas on osaliseks sama olemitüüp, kuid erinevates rollides. Rekursiivset seosetüüpi kutsutakse ka unaarseks seosetüübiks. Joonis 13 esitatud diagrammil on rekursiivne seosetüüp mille mõlemas otsas on sama olemitüüp (Töötaja), kuid erinevates rollides (ülemus, alluv). Diagrammi kohaselt on igal töötajal null või üks otsene ülemus ja null või rohkem otsest alluvat. Joonis 13 Rekursiivse seosetüübi näide. Mida tähendab märkmelehele kirjutatud "{Acyclic}"? Tegemist on kitsendusega, mille kohaselt töötajate vahelistes seostes ei tohi leiduda "tsükleid" (Miliauskaite ja Nemuraite, 2005). See tähendab, et töötaja ei tohi olla iseenda otsene ega kaudne ülemus (näiteks ülemuse ülemus) ja otsene ega kaudne alluv (näiteks alluva alluv). Taoliste kitsenduste leidmine ja dokumenteerimine on vajalik, sest tegemist on ärireeglitega millele vastavad kitsendused tuleb jõustada ka andmebaasis (andmebaasi kitsendustena). Kui joonistada olemi-suhte diagrammi UMLis, siis võib kitsenduste kirjapanemiseks kasutada UMLi formaalset objektikitsenduste keelt (Object Constraint Language e. OCL), aga seda võib kirja panna ka vabas vormis tekstina. UML 2.0 ei nõua kitsenduste kirjeldamisel kindla keele kasutamist. Nõutud on vaid, et kitsendus tuleb panna looksulgudesse {}. Millist keelt oleks soovitav kitsenduste kirjeldamiseks kasutada? Esitame järgnevalt näite OCL kitsendusest, mille kohaselt identifitseerib atribuudi tellimuse_nr väärtus unikaalselt iga olemitüüpi Tellimus kuuluvat olemit. Täpsemalt, tellimused t1 ja t2 on erinevad tellimused, kui nende tellimuse numbrid on erinevad. [context Tellimus] Tellimus.allInstances -> forall ( t1, t2 t1<>t2 implies t1.tellimuse_nr<>t2.tellimuse_nr) Kui kitsenduse kirjeldamiseks kasutada formaalset keelt, siis saab panna kitsenduse kirja täpselt ja üheselt arusaadavalt. Sellises keeles kitsenduste kirjeldusi suudab analüüsida ja interpreteerida ka tarkvarasüsteem. Samas, taolised kirjeldused pole ilma eriettevalmistuseta inimestele arusaadavad. Mudeleid peaksid üle vaatama ja nendest aru saama ka infosüsteemi tulevased kasutajad. Seega, kasulik oleks kitsendused dokumenteerida kahel viisil: Täpne ja formaalne kirjeldus kasutades näiteks OCLi. 43

44 Laiemale kasutajate ringile arusaadav tavakeelne kirjeldus. Vaatleme lauset: "Õppejõud õpetab õppeainet". Õppejõud ja Õppeaine on olemitüübid. Mis on ühe modelleerija jaoks seosetüüp, see on teise jaoks olemitüüp ja vastupidi. Näiteks süsteemi kirjeldava lihtlause e. lausendi "Üliõpilane õpib õppeainet" põhjal võib leida olemitüübid üliõpilane ja õppeaine. Kuid õppimine on võimalik modelleerida nii seosetüübina üliõpilane ja õppeaine vahel kui ka olemitüübina. Kui seosetüübil on atribuute, st. omadusi mille kohta tuleb andmebaasis andmeid hoida, siis tuleb see seosetüüp modelleerida olemitüübina. a) Õppejõud 1 0..* Õpetamine alguse_aeg : Date lõpu_aeg : Date 0..* 1 Õppeaine b) Joonis 14 Seosetüübi modelleerimise võimalused UMLi joonistatud olemi-suhte diagrammil. Variandi b puhul kasutatakse seosetüübi esitamiseks UMLi sidemeklassi (inglise keeles association class). Fowler (2007) kirjutab: "Sidemeklass lisab ühe lisakitsenduse, mis seisneb selles, et iga kahe sidemes osaleva objekti vahel saab olla vaid üks sidemeklassi isend." Variandid a ja b ei ole samaväärsed. Variandi b korral kehtib täiendav reegel, et üks õppejõud ei saa õpetada ühte õppeainet rohkem kui üks kord Atribuut Atribuut: Atribuut on "nimeline olemi omadus" (EVS-ISO/IEC 2382, 1998). Kontseptuaalses andmemudelis tuleb kirjeldada sellised atribuudid millele vastavaid andmeid soovitakse hakata andmebaasis hoidma. 44

45 Tüüp: Iga atribuut on mingit tüüpi. Atribuudi tüüp on võimalike väärtuste hulk mille hulgast saavad tulla atribuudi väärtused. Mitmel atribuudil võib olla ühesugune tüüp. Fakultatiivne atribuut: Fakultatiivne atribuut on atribuut, millel mõne olemi korral ei ole väärtust. Näiteks olemitüübi Isik atribuut võib olla neiupõlvenimi. Kuid atribuudil neiupõlvenimi saab olla väärtus vaid naissoost isikute korral. Kohustuslik atribuut: Kohustuslik atribuut on atribuut, millel iga olemi korral on vähemalt üks väärtus, mis on antud atribuudi tüüpi. Näiteks olemitüübi Isik atribuut võib olla sünniaeg. Igal isikul on sünniaeg. Üheväärtuseline atribuut: Üheväärtuseline atribuut on atribuut, millel on iga olemi kohta maksimaalselt üks väärtus, mis on antud atribuudi tüüpi. Näiteks igal isikul on vaid üks sünniaeg. Mitmeväärtuseline atribuut: Mitmeväärtuseline atribuut on atribuut, millel võib olla mõne olemi kohta rohkem kui üks väärtus, mis on antud atribuudi tüüpi.. Näiteks võib isikul olla üks või mitu telefoni või i aadressi. Kuidas modelleerida mitmeväärtuselist atribuuti? Modelleerida UMLis mitmeväärtuselise atribuudina. Modelleerida eraldi olemitüübina. Halb lahendus Isik isikukood : String eesnimi : String perenimi : String sünniaeg : Date elukoht : String 1 omab 0..* e_mail e_mail : String Parem lahendus Joonis 15 Mitmeväärtuselise atribuudi modelleerimine. Esimene lahendus on halb, sest ühel isikul võib olla rohkem või vähem kui kolm i aadressi. Tuletisatribuut: Tuletisatribuut on atribuut, mille väärtus on mingi arvutusreegli alusel arvutatav muude väärtuste põhjal (näiteks sama olemitüübi teiste atribuutide väärtustest). 45

46 Tuletisatribuudi nime ette tuleks UMLis joonistatud olemi-suhte diagrammil panna kaldkiips "/", et seda atribuuti tähistada. Samuti tuleb dokumenteerida arvutusreegel. Arvutusreegli võib panna kirja diagrammile paigutatud märkmelehele. Näiteks hotellis ruumi üheks ööpäevaks reserveerimise hind on arvutatav reserveeritava ruumi ühe päeva hinna ja reserveeritud päevade arvu kaudu. Akna pindala on arvutatav akna kõrguse ja laiuse kaudu. Aken akna_nr : String laius : Integer kõrgus : Integer / pindala : Double {pindala=laius*kõrgus} Joonis 16 Tuletisatribuudi näide. Tuletatud väärtuste andmebaasis hoidmise eelised: Kiirendab päringuid. Tuletatud väärtuste andmebaasis hoidmise puudused: Suureneb risk, et andmebaasi satuvad vastuolulised andmed 1. kõrgus*laius <> pindala Suurendab andmemahte Märgime, et vanuse esitamine tuletisatribuudina ei ole otstarbekas, sest vanus on pidevas muutumises ning seega tuleks selle atribuudi väärtust sagedasti muuta. Seetõttu oleks mõistlik hoida andmebaasis olemi sünni/loomise aega. Teades hetke kuupäeva ja kellaaega on selle põhjal võimalik alati korrektne vanus välja arvutada (eeldusel, et süsteemis on loodud operaator, mis võimaldab leida kahe ajahetke vahelise intervalli) Seosetüübi omadused Järk e. võimsus Osaluskohustus e. tugevus Need omadused tuleb määrata iga seosetüübis osaleva olemitüübi kohta. Tugevus Tugevus näitab vaadeldava seosetüübi ST ja selles osaleva olemitüübi OT kontekstis minimaalset (tüüpi ST kuuluvate) seoste arvu, milles peab osalema iga (tüüpi OT kuuluv) olem. Tugevuseks võib olla suvaline positiivne arv või 0. 46

47 Seosetüüp ST on olemitüübi OT jaoks kohustuslik, kui iga tüüpi OT kuuluv olem peab osalema vähemalt ühes tüüpi ST kuuluvas seoses (tugevus on suvaline positiivne arv). Seosetüüp ST on olemitüübi OT jaoks mittekohustuslik, kui on lubatud tüüpi OT kuuluvad olemid, mis ei osale üheski tüüpi ST kuuluvas seoses (tugevus on 0). Näiteks Joonis 17 on seosetüüp koostatakse olemitüübi Leping jaoks kohustuslik, sest iga leping peab olema seotud vähemalt ühe arvega. Samas on seosetüüp koostatakse olemitüübi Arve jaoks mittekohustuslik, sest võib leiduda arveid mis pole seotud ühegi lepinguga. Leping 0..1 koostatakse 1..* Arve +koostamise alus +koostamise tulemus Joonis 17 Seosetüübi kohustuslikkus. Näide: Hotell peab olema seotud ühe või mitme ruumiga. Seega seosetüüp Hotell ja Ruum vahel on Hotell jaoks kohustuslik. Ruumiga peab olema seotud üks hotell. Seega seosetüüp Hotell ja Ruum vahel on Ruum jaoks kohustuslik. Võimsus e. järk Võimsus näitab vaadeldava seosetüübi ST ja selles osaleva olemitüübi OT kontekstis maksimaalset (tüüpi ST kuuluvate) seoste arvu, milles võib osaleda üks (tüüpi OT kuuluv) olem. Järguks võib olla suvaline positiivne arv või * (piiramatu arvu korral). Näide: Hotell on seotud ühe või mitme ruumiga. Ruumiga on seotud üks hotell. Võimsus ruumi puhul on üks, ses konkreetne ruum osaleb ühes seoses hotelliga. Ruum on seotud ühe kindla hotelliga. Võimsus hotelli puhul on *, sest konkreetne hotell osaleb ühes või rohkemas seoses ruumidega. Hotellis on üks või mitu ruumi. Joonis 17 näitel on seosetüübi koostatakse kontekstis olemitüübi Leping tugevus 1 ja võimsus *. Seosetüübi koostatakse kontekstis on olemitüübi Arve tugevus 0 ja võimsus on 1. Tugevus ja võimsus koos määravad ära võimsustiku (inglise keeles multiplicty). Võimsustikud määratakse ära alumise ja ülemise piiriga ning seega määrab tugevus ära alapiiri ja võimsus ülapiiri. Kui ala- ja ülapiir on 47

48 sama võib kasutada ühte arvu. Järgnevalt esitame näiteid võimalikest võimsustikest. Tähistus Sõnaline selgitus 0..1 Null või üks 1..1 (või 1) Täpselt üks 0..* Null või rohkem 1..* Üks või rohkem Viis kuni kümme Võimsustikud esitavad kitsendusi mille põhjal luuakse andmebaasis kitsendusi. Erinevates notatsioonides esitatakse võimsustikke erinevalt. Näide: Isik kuulub omab Auto Isik omab null või rohkem autot Isik kuulub omab Auto Isik omab üks või rohkem autot Isik Isik Isik kuulub kuulub kuulub omab omab omab Auto Auto Auto Isik omab täpselt ühte autot Isik omab täpselt kahte autot Isik omab null või üks autot Joonis 18 Erinevad seoste tüübid esitatuna varesejalgade notatsioonis. Õppejõud peab õpetama ühte kuni nelja õppeainet. (1..4) Õppeainet võib õpetada üks õppejõud. (0..1) Joonis 19 Võimsustike näide. Iga lepingu alusel võib koostada ühe ja ainult ühe arve. (0..1) Iga arve võib olla koostatud ühe ja ainult ühe lepingu alusel. (0..1) Leping koostatakse Arve +koostamise alus +koostamise tulemus Joonis 20 Võimsustike näide. 48

49 Iga lepingu alusel võib koostada ühe ja ainult ühe arve. (0..1) Iga arve peab olema koostatud ühe ja ainult ühe lepingu alusel. (1) Leping koostatakse Arve +koostamise alus +koostamise tulemus Joonis 21 Võimsustike näide. Iga lepingu alusel peab koostama ühe ja ainult ühe arve. (1) Iga arve peab olema koostatud ühe ja ainult ühe lepingu alusel. (1) Leping koostatakse 1 1 Arve +koostamise alus +koostamise tulemus Joonis 22 Võimsustike näide. Iga lepingu alusel võib koostada ühe või mitu arvet. (0..*) Iga arve peab olema koostatud ühe ja ainult ühe lepingu alusel. (1) Leping koostatakse 1 0..* Arve +koostamise alus +koostamise tulemus Joonis 23 Võimsustike näide. Iga lepingu alusel peab koostama ühe või mitu arvet. (1..*) Iga arve peab olema koostatud ühe ja ainult ühe lepingu alusel. (1) Leping koostatakse 1 1..* Arve +koostamise alus +koostamise tulemus Joonis 24 Võimsustike näide. Sõltuvalt võimsustikest võib kahte olemitüüpi siduv kaheliikmeline seosetüüp olla: üks-ühele (1:1) seosetüüp (vt. Joonis 20, Joonis 21, Joonis 22); üks-mitmele (1:M) seosetüüp (vt. Joonis 19, Joonis 23, Joonis 24); mitu-mitmele (M:N) seosetüüp; 49

50 Olemi-suhte diagrammil võib esitada välistava kaare. Välistavat kaart saab kirjeldada, kui olemitüüp OT on seosetüüpide kaudu seotud kahe või rohkema olemitüübiga. Kaar esitab kitsenduse, et iga olemi puhul (mis on tüüpi OT) peavad eksisteerima täpselt ühte kaarega hõlmatud seosetüüpi kuuluvad seosed. Antud juhul peab iga lepingu rida olema seotud kas kauba või teenusega, aga mitte mõlemaga korraga. Teisisõnu, ei ole lubatud lepingu read, mis ei ole seotud ei kauba ega teenusega. Samuti ei ole lubatud lepingu read, mis on seotud nii kauba kui ka teenusega. Pange tähele, et seetõttu on iga lepingu rida seotud null või ühe teenusega ja null või ühe kaubaga, mitte täpselt ühe teenusega ja täpselt ühe kaubaga. Klient Leping Pakkuja Lepingu rida Teenus Kaup Joonis 25 Kaare esitamine olemi-suhte diagrammil, kasutades varesejalgade notatsiooni. Joonis 26Kaare esitamine UMLis joonistatud olemi-suhte diagrammil. Alamhulga kitsendus. UMLis saab esitada alamhulga kitsenduse (Halpin, 2001). Näite kohaselt saab iga isik olla vaid sellise komitee esimees, mille liige ta on (komitee esimeeste hulk on komitee liikmete alamhulk). Pange 50

51 tähele, et kuna igal komiteel on täpselt üks esimees, siis peab tänu alamhulga kitsendusele igal komiteel olema üks või rohkem liiget. Joonis 27Alamhulga kitsenduse esitamine UMLis joonistatud olemisuhte diagrammil Laiendatud olemi-suhte diagramm Üldistusseos Ülatüüp on olemitüüp, millel on üks või rohkem alamtüüpi. Iga alamtüüpi olem on ühtlasi ka ülatüüpi olem, kuid vastupidine ei pruugi alati kehtida (st. iga ülatüüpi olem ei ole alati ka alamtüüpi olem). Alamtüüpi olem pärib kõik ülatüüpi olemi seosed ja atribuudid. Seetõttu nimetatakse üldistusseost ka pärimisseoseks. Alamtüübil võivad (aga ei pruugi olla) olla võrreldes ülatüübiga täiendavad omadused (atribuudid) ja/või ta osaleb täiendavates seosetüüpides. Ühel ülatüübil võib olla mitu alamtüüpi. Ühel alamtüübil võib olla mitu ülatüüpi (mitmene pärimine). Näiteks ülatüübi Isik atribuutideks võivad olla isikukood, eesnimi, perenimi sünniaeg ja elukoht. Ülatüübi Isik alamtüübid võivad olla Üliõpilane ja Töötaja. Nii töötaja kui ka üliõpilane on isikud. Alamtüüp Töötaja osaleb seosetüübis olemitüübiga Amet. Alamtüübil Üliõpilane on atribuut üliõpilaskood. Üldistusseos ühendab omavahel ülatüübi ja selle alamtüübi. Diagrammil esitab seda ülatüüpi ja alamtüüpi ühendav joon. Selle joone ülatüübi poolses otsas on kolmnurk, mille tipp on suunatud ülatüübi poole. Kuidas sõnaliselt väljendada olemi-suhte diagrammil esitatud üldistusseost? Joonis 31 esitatud diagrammi kohaselt: Üliõpilane on isik. Töötaja on isik. Ülatüübiks/alamtüübiks olemine on suhteline olemitüüp, mis on ühe üldistusseose kontekstis ülatüüp võib olla teise üldistusseose kontekstis alamtüüp. Alamtüüp peab vastama järgmistele kriteeriumitele (Larman, 2002, lk. 399): Ülatüübi definitsioon peab 100% kehtima ka selle alamtüübi suhtes. Kõik alamtüüpi olemid on ka ülatüüpi. Üldistusseoste kaudu seotud olemitüübid moodustavad tüüpide hierarhia. Tüüpide hierarhiate leidmiseks võib kasutada spetsialiseerimise või üldistamise meetodit. 51

52 Spetsialiseerimine tähendab, et üritatakse leida olemitüüpe eristavaid omadusi. Näiteks leitakse olemitüüp Isik ja seejärel tehakse kindlaks, et isik võib olla nii füüsiline kui ka juriidiline isik. Üldistamine tähendab, et üritatakse minimeerida erinevusi olemitüüpide vahel ja leida nende ühiseid omadusi. Näiteks leitakse olemitüübid Ostutellimus ja Müügitellimus ja tehakse üldistus, et tegemist on Tellimusega ning veel üldisemalt Lepinguga ostjate ja müüjate vahel. Praktikas tuleb neid meetodeid modelleerimisel kasutada üheskoos. Joonis 28 Üldistusseose näide. Isik on ülatüüp ja Tootaja on alamtüüp. Seost loetakse järgnevalt: "Töötaja on Isik". Millal oleks kasulik leida ja mudelil esitada nii ülatüüp kui ka selle alamtüübid? Osa atribuute on ühised kõikidele alamtüüpidele ja need tuleks esitada ülatüübis. Osa atribuute aga on spetsiifilised mingile kindlale alamtüübile. Osa seosetüüpe on ühised kõikidele alamtüüpidele ja need tuleks esitada ülatüübi tasemel. Osa seosetüüpe aga on spetsiifilised mingile kindlale alamtüübile. Üldistuste hulk on kogum üldistusseoseid, mis üheskoos kirjeldavad, kuidas ülatüüpi mingil kindlal viisil alamtüüpideks jagada. Järgneval diagrammil esitatakse kaks üldistuste hulka, mille nimed on roll ja sugu. Ühte hulka kuuluvad üldistusseosed on visuaalselt kokku tõmmatud. Üldistuste hulk sugu jagab ülatüübi Isik alamtüüpideks vastavalt isiku soole. Üldistuste hulk roll jagab ülatüübi Isik alamtüüpideks vastavalt isiku rollile. Mõlemasse üldistuste hulka kuuluvate üldistusseoste korral on Isik ülatüüp. 52

53 Joonis 29 Üldistuste hulgad. Üldistusseostega koos tuleks ära määrata ka nendega seotud kitsendused (Connolly ja Begg, 2002). Nende kitsenduste alusel luuakse hiljem jällegi andmebaasi kitsendusi. Osaluskohustus määrab, kas iga ülatüüpi kuuluv olem peab kuuluma ka mõnda alamtüüpi: Kui iga ülatüüpi kuuluv olem peab kuuluma vähemalt ühte alamtüüpi, siis tähistatakse seda diagrammil {Mandatory}. Kui iga ülatüüpi kuuluv olem ei pea kuuluma mõnda alamtüüpi (see tähendab, et võib leiduda ülatüüpi kuuluvaid olemeid, mis ei kuulu ühtegi alamtüüpi, siis tähistatakse seda diagrammil {Optional}. Kuuluvus määrab maksimaalse alamtüüpide arvu kuhu ülatüüpi olem võib kuuluda: Kui iga ülatüüpi olem saab kuuluda maksimaalselt ühte alamtüüpi, siis tähistatakse seda diagrammil {Or}. Kui iga ülatüüpi olem saab kuuluda rohkem kui ühte erinevasse alamtüüpi, siis tähistatakse seda diagrammil {And}. Kuuluvuse kitsendust pole vaja esitada, kui ülatüübil on ainult üks alamtüüp. Osaluskohustuse ja kuuluvuse kitsendused tuleb esitada eraldi iga üldistuste hulga kohta. 53

54 Joonis 30 Üldistuste hulgad koos kitsendustega. Vaatleme Joonis 31 esitatud kitsendust "{Otional, And}". "Optional" tähendab, et võib leiduda isikuid, kes ei ole ei üliõpilased ega töötajad. "And" tähendab, et võib leiduda isikuid, kes on korraga nii üliõpilased kui ka töötajad. Pange tähele, et diagrammil võib, aga ei pea kitsendust kirjutama märkmelehele. Isik isikukood : String eesnimi : String perenimi : String sünniaeg : Date elukoht : String {Optional, And} Üliõpilane üliõpilaskood : String Töötaja 0..* 1 Amet nimetus : String Joonis 31 Üldistusseose näide. Oletame, et Joonis 31 oleks esitatud üldistusseosega seotud kitsendus "{Mandatory, Or}". "{Mandatory}" tähendab, et iga isik peab olema ka mingit alamtüüpi (üliõpilane, töötaja). "{Or}" tähendab, et isik saab olla kas üliõpilane või töötaja, aga mitte mõlemat korraga Osa-terviku seos Agregatsioon esitab osa-terviku seost olemitüüpide vahel kus üks olemitüüpidest esitab osa ja teine tervikut. Üks osa võib kuuluda mitmesse 54

55 tervikusse ning osa võib eksisteerida ka ilma tervikuta. Näiteks iga meeskond kuulub nulli või rohkemasse liigasse ja igasse liigasse peab kuuluma vähemalt kolm meeskonda. Larman (2002) märgib, et selline seos eksisteerib valdavalt abstraktsete, mitte füüsiliste objektide vahel. Diagrammil esitatakse agregatsiooni seosetüüpi tähistava joone otsas paikneva seest tühja rombina (valge rombina), mis paikneb tervikut esitava olemitüübi poolel. Joonis 32 esitatud diagrammil on tervikuks Liiga ja osaks Meeskond. Liiga 0..* 3..* Joonis 32 Agregatsiooni näide. Meeskond Kompositsioon on osa-terviku seose erijuhus, mille puhul peab osa rollis olev olem kuuluma täpselt ühte terviku rollis olevasse olemisse. Näiteks sõrmed on osa täpselt ühest käest (kui just pole tegu siiami kaksikutega) ja tellimuse rida on osa täpselt ühest tellimusest (vt. Joonis 33). Joonis 34 kohaselt peab iga konkreetne pilet olema kas täpselt ühe broneeringu osa või täpselt ühe ostu osa. Konkreetne pilet ei tohi korraga kuuluda nii mingisse broneeringusse kui ka ostu. Lisaks kehtestab kompositsioon reegli, et terviku rollis oleva olemi kustutamisel tuleb kustutada ka kõik sellele kuuluvad osa rollis olevad olemid (Fowler, 2007). Diagrammil esitatakse kompositsiooni seosetüüpi tähistava joone otsas paikneva täidetud rombina (musta rombina), mis paikneb tervikut esitava olemitüübi poolel. Joonis 33 esitatud diagrammil on Tellimus tervik ja Tellimuse rida selle osa. Tellimus 1 0..* Tellimuse_rida Joonis 33 Kompositsiooni näide. Ost Pilet * 0..* 0..1 Joonis 34 Kompositsiooni näide. Broneering Kui kahtlete, kas osa-tervikus seost esitada, siis Larman (2002) soovitab seda mitte teha. Millal osa-terviku seost kasutada (Larman, 2002)? Loogilises mõttes on tegu osa ja tervikuga. Osa ja tervik on seotud eluea kaudu. Osa ei saa eksisteerida ilma tervikuta. Sellisel juhul on tegu kompositsiooniga. Mõned terviku omadused (nt. asukoht) või käitumised (nt. kustutamine) kanduvad üle ka osadele. 55

56 7.1.3 Nimedest Kasutage olemitüüpide, atribuutide ja seosetüüpide nimetamisel sisulisi, infosüsteemi tulevastele kasutajatele arusaadavaid nimesid. Nii saavad ka nemad mudelite ülevaatamisel osaleda. Kasutage olemitüüpide nimedes ainsuse vorme, sest nii on hiljem lihtsam määrata seosetüüpidega seotud võimsustikke. Oletame, et süsteemi kirjeldavad lausendid: Iga õppejõud õpetab null või rohkem õppeainet. Iga õppeainet õpetab null või rohkem õppejõudu. Iga õppejõudu iseloomustab perenimi. Iga õppeainet iseloomustab nimi. Joonis 35 osas a) on ühe olemitüübi nimi mitmuses (Õppeained) ja sellest tulenevalt on võimsustiku määramisel langetatud vale otsus. Joonise osa b) esitab korrektse mudeli. a) Õppejõud perenimi : String õpetab Õppeained nimi : String Ebaõige võimsustik b) Õppejõud perenimi : String õpetab 0..* 0..* Õppeaine nimi : String Joonis 35 Võimsustike määramine. Ärge lähtuge nimetamisel andmebaasisüsteemide tehnilistest piirangutest nagu: nimi ei tohi olla pikem kui 30 märki, ei tohi sisaldada täpitähti. Pidage meeles, et kontseptuaalne andmemudel on mittetehniline mudel, mille põhjal võib luua tehnilise kavandi väga erinevate platvormide jaoks Ei ole ühte ainuõiget mudelit Rõhutame, et kontseptuaalse andmemudeli koostamisel võivad erinevad modelleerijad koostada sama lähteinformatsiooni põhjal erinevad mudelid, mis kõik annavad edasi vajaliku informatsiooni Oletame, et tuleb koostada kontseptuaalne andmemudel järgneva spetsifikatsiooni põhjal: Iga klient esitab null või rohkem tellimust. Iga tellimus on esitatud täpselt ühe kliendi poolt. Iga töötaja kinnitab null või rohkem tellimust. Iga tellimus kinnitatakse null või ühe töötaja poolt. Klient on isik. Töötaja on isik. Järgnev joonis esitab kaks võimalikku olemi-suhte diagrammi, mida sellise spetsifikatsiooni põhjal võib koostada. 56

57 a) b) Isik esitab +klient 1 0..* +töötaja * kinnitab Tellimus Isik Töötaja Klient 1 esitab 0..* Tellimus 0..1 kinnitab 0..* Joonis 36 Alternatiivsete modelleerimisviiside näide. Variandis a on näidatud olemitüüpide rollid seosetüüpide kontekstis. Variandis b aga esitatakse rollid olemitüüpidena. Nagu näete, on variant a) kompaktsem. Variant b võiks olla eelistatum kui olemitüüpidel Töötaja ja/või Klient on oma spetsiifilisi atribuute või seosetüüpe (mis ei käi kõigi isikute kohta). Samuti lihtsustab variant b) kitsenduste esitamist. Näiteks, kui kehtib reegel, et iga isik peab olema kas töötaja või klient, aga ta ei tohi olla mõlemat korraga, siis saab üldistusseosele lisada kitsenduse {Mandatory; Or} (vt. peatükk ). 57

58 7.1.5 Olemitüüpide liigitus Olemitüüpe on võimalik liigitada selle järgi, kuidas identifitseeritakse nendesse tüüpidesse kuuluvaid olemeid. Nõrk olemitüüp on olemitüüp, millesse kuuluvate olemite eksistents sõltub mõnda teise olemitüüpi kuuluvate olemite eksistentsist (Connolly ja Begg, 2002). Seda tüüpi olem ei saa eksisteerida ilma mõne teise olemita. Seda tüüpi olem ei saa eksisteerida ilma mõne teise olemita. Kui olemitüüp OT on nõrk, siis sellesse kuuluvate olemite identifitseerimiseks ei piisa OT atribuutide väärtustest. Sellise olemi identifitseerimiseks on vaja kasutada ka selle seoseid teiste olemitega. Näiteks on nõrgad olemitüübid: Joonis 9 esitatud olemitüüp Õpetamine. Õpetamine seob õppejõu ja õppeaine ning ei saa eksisteerida ilma, et eksisteeriksid õppejõud ja õppeaine. Joonis 31 esitatud olemitüübid Töötaja ja Üliõpilane. Töötaja ja üliõpilane on isikud. Error: Reference source not found esitatud olemitüüp Tellimuse_rida. Tellimuse rida on tellimuse osa ja ei saa eksisteerida ilma tellimuseta. Tugev olemitüüp on olemitüüp, millesse kuuluvate olemite eksistents ei sõltu mõnda teise olemitüüpi kuuluvate olemite eksistentsist (Connolly ja Begg, 2002). Näiteks Joonis 9 esitatud diagrammil on tugevad olemitüübid Haridusaste_liik, Õppejõud, Õppeaine ja Õppeaine_seisundi_liik. Kui olemitüüp OT on tugev, siis sellesse kuuluvate olemite identifitseerimiseks piisab OT atribuutide väärtustest. Näiteks konkreetse õppeaine identifitseerimiseks piisab atribuudi ainekood väärtusest. Codd (1979) esitab veel ühe võimaliku olemitüüpide liigituse: Kernel. Olemitüübid, millesse kuuluvad olemid võivad eksisteerida sõltumata teiste olemite olemasolust. Joonis 9 esitatud diagrammil on kernelid Haridusaste_liik, Õppejõud, Õppeaine ja Õppeaine_seisundi_liik. Kirjeldav olemitüüp. Seda tüüpi olemite peamine eesmärk on iseloomustada / kirjeldada teisi olemeid. Nende eksistents sõltub olemitest, mida nad iseloomustavad. Kirjeldava olemitüübi näiteks on Joonis 15 esitatud olemitüüp e_mail. Assotsiatsioon. Olemitüüp, mis esitab mitu-mitu seoseid. Joonis 9 esitatud diagrammil on assotsiatsioon Õpetamine. 58

59 viib läbi reserveerimise TTÜ: Andmebaaside projekteerimine Olemi-suhte diagrammi erinevad notatsioonid - Chen - Barker - IE (Information Engineering) - IDEF1X (Integration DEFinition for Information Modeling) - UML (Unified Modeling Language) Chen maja tänav linn postikood riik hotelli_ nimi aadress hotelli_nr eesnimi perenimi alguse_ aeg lopu_aeg kommentaar hind nimi sugu Hotell 1 Reserveerimine Isik isiku_nr Sisaldab M reserveeritakse reserveerib N o ruumi_nr Ruum M Külaline hind tüüp P sünni_ aeg külalise_ nr Amet 1 Töötab M Töötaja 1 M töötaja_ nr nimetus ameti_nr Juhendab Joonis 37 Olemi-suhte diagrammi esitus Chen i notatsioonis. 59

60 Barker Hotell # hotelli_nr *hotelli_nimi *aadress Amet #ameti_nr *nimetus töötab juhatab Isik #isiku_nr *eesnimi *perenimi sugu Töötaja #töötaja_nr juhataja Külaline #külalise_nr *sünni_aeg sisaldab viib läbi reserveerimise Ruum #hotelli_nr #ruumi_nr *tüüp *hind reserveeritakse Reserveerimine #külalise_nr #hotelli_nr #ruumi_nr #töötaja_nr *alguse_aeg lopu_aeg kommentaar hind reserveerib Joonis 38 Olemi-suhte diagrammi esitus Barkeri notatsioonis. 60

61 IE (Information Engineering) Amet ameti_nr nimetus ametis töötab / omab ametit Isik isiku_nr eesnimi perenimi sugu Hotell hotelli_nr hotelli_nimi aadress Töötaja töötaja_nr (FK) ameti_nr (FK) juhataja (FK) sisaldab / sisaldub viib läbi reserveerimise juhendab / juhendatakse Ruum hotelli_nr (FK) ruumi_nr tüüp hind reserveeritakse Reserveerimine külalise_nr (FK) hotelli_nr (FK) ruumi_nr (FK) töötaja_nr (FK) alguse_aeg lopu_aeg kommentaar /hind reserveerib Külaline külalise_nr (FK) sünni_aeg Joonis 39 Olemi-suhte diagrammi esitus IE notatsioonis IDEF1X (Integration DEFinition for Information Modeling) Amet ameti_nr nimetus ametis töötab / omab ametit Isik isiku_nr eesnimi perenimi sugu Hotell hotelli_nr hotelli_nimi aadress Töötaja töötaja_nr (FK) juhataja (FK) ameti_nr (FK) sisaldab / sisaldub viib läbi reserveerimise juhendab / juhendatakse Ruum hotelli_nr (FK) ruumi_nr tüüp hind reserveeritakse Reserveerimine külalise_nr (FK) hotelli_nr (FK) ruumi_nr (FK) töötaja_nr (FK) alguse_aeg lopu_aeg kommentaar /hind reserveerib Külaline külalise_nr (FK) sünni_aeg Joonis 40 Olemi-suhte diagrammi esitus IDEF1X notatsioonis. 61

62 Isik PK isiku_nr Hotell Amet eesnimi perenimi sugu PK hotelli_nr PK ameti_nr nimi maja tänav linn postikood riik nimetus Töötaja PK,FK1 töötaja _nr FK2 ameti_nr Ruum Reserveerimine PK PK,FK1 FK2 ruumi_nr hotell_id hind tüübi_nr PK,FK1 PK,FK1 PK,FK2 PK FK3 ruumi_nr hotell_id külalise_nr alguse_aeg lõpu_aeg kommentaar töötaja_nr Külaline PK,FK1 külalise_nr sünni_aeg Tüüp PK tüübi_nr nimetus Joonis 41 Olemi-suhte diagrammi esitus IDEF1X notatsioonis. 62

63 UML (Unified Modeling Language) Joonis 42 Olemi-suhte diagrammi esitus UML notatsioonis. Joonisel 42 olev diagramm on joonistatud CASE vahendiga Rational-Rose Olemi-suhte diagrammi puudused ja probleemid Diagrammi elementide (olemitüüpide, seosetüüpide, atribuut) tähenduses ja definitsioonides pole siiani täpselt kokku lepitud. Mis ühe jaoks on olemitüüp, see on teise jaoks atribuut või seosetüüp. Aegade jooksul on kasutusel olnud (ja on siiani) palju erinevaid notatsioone (märgisüsteeme), mida olemi-suhte diagrammide koostamiseks on kasutatud. Erinevates notatsioonides on diagrammidel lubatud erinevat tüüpi elemendid näiteks IE ja IDEF1X notatsioonis diagrammidel näidatakse välisvõtmeid. Pole piisavalt väljendusrikas. Palju informatsiooni (nt. andmetega seotud kitsenduste kohta) on võimalik esitada ainult diagrammiga kaasa tulevate tekstiliste kirjeldustega. 63