strateegiline analüüs ja detailanalüüs - ttü informaatikainstituut
strateegiline analüüs ja detailanalüüs - ttü informaatikainstituut
strateegiline analüüs ja detailanalüüs - ttü informaatikainstituut
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
TTÜ: Andmebaaside projekteerimine.<br />
Strateegiline analüüs <strong>ja</strong> detailanalüüs (2012)<br />
© Erki Eessaar<br />
Teema 7. Andmebaaside projekteerimine:<br />
<strong>strateegiline</strong> analüüs <strong>ja</strong> detailanalüüs<br />
Sisukord<br />
1. Eesmärgid......................................................................................................1<br />
2. Infosüsteemi arendamine..............................................................................1<br />
3. Arendusmetoodikad.....................................................................................10<br />
4. Strateegiline analüüs...................................................................................12<br />
5. Detailanalüüs...............................................................................................28<br />
6. Tootmisettevõtte näide................................................................................36<br />
7. Kontseptuaalne andmemudel......................................................................38<br />
8. Mõisted.........................................................................................................76<br />
9. Kasutatud mater<strong>ja</strong>lid....................................................................................77<br />
Joonised<br />
1. Eesmärgid......................................................................................................1<br />
2. Infosüsteemi arendamine..............................................................................1<br />
3. Arendusmetoodikad.....................................................................................10<br />
4. Strateegiline analüüs...................................................................................12<br />
5. Detailanalüüs...............................................................................................28<br />
6. Tootmisettevõtte näide................................................................................36<br />
7. Kontseptuaalne andmemudel......................................................................38<br />
8. Mõisted.........................................................................................................76<br />
9. Kasutatud mater<strong>ja</strong>lid....................................................................................77<br />
1. Eesmärgid<br />
• Anda ülevaade arendusmetoodikast, selle tähtsusest, komponentidest<br />
<strong>ja</strong> võimalikest väärkasutustest.<br />
• Anda lihtsustatud, kuid terviklik ülevaade strateegilisest analüüsist <strong>ja</strong><br />
detailanalüüsist.<br />
• Kirjeldada kuidas tükeldada infosüsteemi allsüsteemideks.<br />
• Näha ning mõista andmebaaside projekteerimist infosüsteemi<br />
tervikarendamise osana.<br />
• Anda ülevaade kontseptuaalse andmemudeli koostamisest.<br />
2. Infosüsteemi arendamine<br />
Ikka <strong>ja</strong> jälle üritavad arendustööga tegelevad vähekogenud inimesed edu<br />
saavutada tegevustikuga, mille nimi on "kodeeri <strong>ja</strong> paranda" (inglise keeles<br />
code and fix). Selle põhisisu on, et kui ülesanne käes kukutakse suure<br />
entusiasmiga kohe andmebaasi loomise lauseid ning andmebaasi kasutavat<br />
programmi kirjutama ilma, et lahendust eelnevalt läbi mõelda. Mingil hetkel<br />
(alati liiga hil<strong>ja</strong>) hakatakse tegelema ka testimisega. Kui tegemist ei ole just<br />
ühe inimese väga väikses ülesandega, on läbikukkumine kindlustatud.<br />
1
TTÜ: Andmebaaside projekteerimine.<br />
Strateegiline analüüs <strong>ja</strong> detailanalüüs (2012)<br />
© Erki Eessaar<br />
Andmebaasi projekteerimine, nagu igasugune projekteerimine, peab<br />
toimuma süstemaatiliselt!<br />
Andmebaas on infosüsteemi oluline osa. Infosüsteemi loomise käigus luuakse<br />
alati ka andmebaas. Seega infosüsteemi projekteerimine <strong>ja</strong> valmisehitamine<br />
sisaldab ka andmebaasi projekteerimist <strong>ja</strong> valmistegemist. Ei saa vaadata<br />
lahus infosüsteemi <strong>ja</strong> andmebaasi projekteerimist. Seetõttu vaadeldakse kogu<br />
kursuse käigus neid protsesse üheskoos.<br />
Tegelikult võib antud õppeaine pealkir<strong>ja</strong> ümber<br />
sõnastada. Täpsem pealkiri oleks:<br />
"Intensiivse andmebaasikasutusega<br />
infosüsteemi projekteerimine"<br />
Infosüsteemi arendamiseks algatatakse üks või mitu projekti. Projekt on Mikli<br />
(1999) põh<strong>ja</strong>l "kindla a<strong>ja</strong>vahemiku <strong>ja</strong> finantsidega ning formuleeritud<br />
eesmärkidega ellu viidav muudatus või arendamine."<br />
Infosüsteemi arendamise käigus tuleb viia läbi järgmistele süsteemi<br />
loomissammudele vastavaid tegevusi.<br />
• Strateegiline analüüs.<br />
• Detailanalüüs.<br />
• Disain.<br />
• Realiseerimine (Ehitamine).<br />
• Rakendamine (Üleviimine).<br />
• Hooldamine.<br />
Samaaegselt (paralleelselt) viiakse läbi arendamist toetavaid tugitegevusi.<br />
• Projekti dokumentides <strong>ja</strong> programmikoodis tehtavate muudatuste<br />
haldamine.<br />
• Projektijuhtimine.<br />
• Arenda<strong>ja</strong>te töökeskkonna (tööruumid, tarkvara, riistvara, arvutivõrk)<br />
loomine <strong>ja</strong> käigushoidmine.<br />
• Süsteemi tulevaste kasuta<strong>ja</strong>te koolitamine.<br />
• Süsteemiarenduse tulemuste kvaliteedi hindamine.<br />
Süsteemiarenduse käigus luuakse süsteemi mitmevaateline kirjeldus ning<br />
muudetakse seda kirjeldust üha täpsemaks (<strong>ja</strong> tehnilisemaks). Vaated, millele<br />
vastavad süsteemi kirjeldused koostada, on Sowa <strong>ja</strong> Zachman (1992) esitatud<br />
infosüsteemide arhitektuuri raamistiku põh<strong>ja</strong>l.<br />
• Andmevaade.<br />
• Funktsioonide vaade.<br />
• Võrgu vaade.<br />
• Kasuta<strong>ja</strong>te vaade.<br />
• A<strong>ja</strong>vaade.<br />
• Eesmärkide vaade.<br />
2
TTÜ: Andmebaaside projekteerimine.<br />
Strateegiline analüüs <strong>ja</strong> detailanalüüs (2012)<br />
© Erki Eessaar<br />
Need vaated ei ole alternatiivid. Süsteemi tuleb tervikliku pildi saamiseks<br />
kirjeldada kõikidest nendest vaadetest lähtuvalt. Süsteemi kirjeldatakse<br />
kasutades mudeleid ning mudelite koostamise protsessi nimetatakse<br />
modelleerimiseks. Mudel on reaalsuse lihtsustatud kirjeldus. Selleks, et<br />
erinevaid vaateid esitavad mudelid üheskoos tõesti annaksid tervikliku pildi<br />
süsteemist, tuleb tagada, et need mudelid on omavahel kooskõlas.<br />
Mudel võib olla visuaalne, tekstiline või kombineeritud. Enamasti koosnebki<br />
mudel visuaalsetest diagrammidest <strong>ja</strong> neid täpsustavatest tekstilistest<br />
kirjeldustest. Koostatud mudelite alusel luuakse töötav tarkvara.<br />
Süsteemi modelleerimiseks võib kasutada visuaalset modelleerimiskeelt UML<br />
(Unified Modeling Language) keelt. Samas ei ole UML kaugeltki ainuke<br />
võimalik keel, mida saab infosüsteemide (<strong>ja</strong> sealhulgas andmebaaside)<br />
projekteerimiseks kasutada. Andmebaasi projekteerimiseks (süsteemi<br />
andmevaate koostamiseks) võib kasutada objekti-rolli mudeleid<br />
(http://www.orm.net). Süsteemi mitmevaateliseks kirjeldamiseks võib näiteks<br />
kasutada objekti-protsessi modelleerimist<br />
(http://en.wikipedia.org/wiki/Object_Process_Methodology) või<br />
süsteemimaatrikseid.<br />
Analüüsi <strong>ja</strong> disaini käigus võib koostada andmebaasi <strong>ja</strong> andmebaasi<br />
kasutavate programmide prototüüpe. Prototüüp on (EVS-ISO/IEC 2382, 1998,<br />
põh<strong>ja</strong>l) "süsteemi projekteerimise, töönäita<strong>ja</strong>te <strong>ja</strong> kasutuspotentsiaali<br />
hindamiseks või nõuete paremaks mõistmiseks või määramiseks sobiv mudel<br />
või esialgne teostus."<br />
Prototüüpide tegemisel võib lähtuda erinevatest strateegiatest. Prototüüp võib<br />
olla mõeldud ideede kiireks testimiseks <strong>ja</strong> see heidetakse enne reaalse<br />
süsteemi ehitamist kõrvale (äravisatav prototüüp). Samas võib prototüübi<br />
täiendamise tulemusena samm-sammult valmida töötav tarkvarasüsteem<br />
(evolutsiooniline prototüüp).<br />
Tabel 1 Infosüsteemi <strong>ja</strong> andmebaasi loomissammude vastavustabel.<br />
Infosüsteemi<br />
loomissamm<br />
Strateegiline analüüs<br />
Detailanalüüs<br />
Disain<br />
Realiseerimine<br />
Rakendamine<br />
Hooldamine<br />
Andmebaasi loomissamm<br />
Nõuete kogumine<br />
Andmebaasi alamosade leidmine<br />
Projektide planeerimine<br />
Kontseptuaalne andmebaasi disain<br />
Nõuete kogumine<br />
Kontseptuaalne andmebaasi disain<br />
Loogiline andmebaasi disain<br />
Füüsiline andmebaasi disain<br />
Andmebaasi realiseerimine<br />
Andmebaasi rakendamine<br />
Andmebaasi hooldamine<br />
3
TTÜ: Andmebaaside projekteerimine.<br />
Strateegiline analüüs <strong>ja</strong> detailanalüüs (2012)<br />
© Erki Eessaar<br />
Tabel 2 SQL andmebaasi loomissammude lühikirjeldus.<br />
Andmebaasi<br />
loomissamm<br />
Nõuete<br />
kogumine<br />
Kirjeldus<br />
Nii strateegilise kui detailanalüüsi käigus kogutakse<br />
kasuta<strong>ja</strong>te nõudeid infosüsteemile. Infosüsteemile<br />
esitatavaid nõudeid liigitatakse:<br />
• Funktsionaalsed nõuded, mis kirjeldavad tegevusi mille<br />
läbiviimist peab (info)süsteem võimaldama (süsteemi<br />
oodatava funktsionaalsuse). Funktsionaalsete nõuete<br />
esitamiseks võib kasutada kasutusjuhtude mudelit.<br />
Funktsionaalsetest nõuetest tulenevad nõuded<br />
andmetele, mida nende tegevuste läbiviimiseks va<strong>ja</strong><br />
läheb.<br />
• Mittefunktsionaalsed nõuded. Robertson <strong>ja</strong> Robertson<br />
(1999) märgivad, et mittefunktsionaalsed nõuded<br />
kirjeldavad süsteemilt oodatavaid omadusi. Andmebaase<br />
puudutavad mittefunktsionaalsed nõuded on näiteks:<br />
- Nõuded süsteemi töökiirusele. Süsteemi töökiirust<br />
mõjutab oluliselt andmebaasisüsteemile edastatud<br />
korralduste täitmise kiirus.<br />
- Nõuded julgeolekule. Andmed on organisatsiooni oluline<br />
vara ning nende kaitsmiseks tuleb tarvitusele võtta<br />
kõikvõimalikud abinõud.<br />
- Nõuded süsteemi (sh. andmebaasi) muudatuste<br />
sisseviimise kiirusele.<br />
- Juriidilised nõuded (nt. milliseid seaduseid peab<br />
andmebaasi pida<strong>ja</strong> eriliselt arvesse võtma). Näiteks<br />
Eestis peab arvestama isikuandmete kaitse seadusega.<br />
Mittefunktsionaalsed nõuded pannakse kir<strong>ja</strong> näiteks<br />
loendina.<br />
Andmebaasi<br />
alamosade<br />
leidmine<br />
Kasuta<strong>ja</strong>telt informatsiooni kogumise meetodid:<br />
- Uuritakse organisatsiooniga seotud dokumente. Näiteks<br />
tutvutakse tööta<strong>ja</strong>te ametijuhenditega.<br />
- Andmebaasi tulevased kasuta<strong>ja</strong>d täidavad küsimustikke.<br />
- Jälgitakse andmebaasi tulevaste kasuta<strong>ja</strong>te tööd.<br />
- Tehakse intervjuusid tulevaste kasuta<strong>ja</strong>tega.<br />
- Uuritakse varem dokumenteeritud nõudeid teistele<br />
samatüübilistele organisatsioonidele.<br />
Strateegilise analüüsi käigus leitakse põhiolemitüübid<br />
(mõnikord kasutatakse ka terminit põhiobjektid), millele<br />
vastavaid andmeid hakatakse andmebaasis hoidma. Iga<br />
selline olemitüüp vastab mingile uuritavat organisatsiooni<br />
iseloomustavale olulisele mõistele. Igale põhiolemitüübile<br />
vastab alamosa andmebaasist ehk register. Suure süsteemi<br />
(andmebaasi) <strong>ja</strong>gamine alamosadeks lihtsustab selle<br />
süsteemi kirjeldamist <strong>ja</strong> kirjeldusest ülevaate saamist ning<br />
võimaldab planeerida süsteemi alamosade arendamise<br />
järjekorda.<br />
4
TTÜ: Andmebaaside projekteerimine.<br />
Strateegiline analüüs <strong>ja</strong> detailanalüüs (2012)<br />
Andmebaasi<br />
loomissamm<br />
Projektide<br />
planeerimine<br />
Kontseptuaalne<br />
andmebaasi<br />
disain<br />
Kirjeldus<br />
© Erki Eessaar<br />
Planeeritakse projektid mida on va<strong>ja</strong> andmebaasi<br />
valmistegemiseks. Tüüpiliselt projekteeritakse/ehitatakse<br />
ühe projekti käigus üks või mitu registrit aga mitte terve<br />
andmebaas.<br />
Lähtuvalt kasuta<strong>ja</strong> nõuetest koostatakse kontseptuaalne<br />
andmemudel, mis on täiesti vaba kõigist realiseerimisega<br />
seotud kaalutlustest. Sellega kirjeldatakse detailselt nõuded<br />
selle kohta, milliseid andmeid tuleks andmebaasis hoida.<br />
Kontseptuaalses andmemudelis ei pöörata tähelepanu<br />
ühelegi realiseerimisega seotud as<strong>ja</strong>olule, nagu<br />
andmemudel, andmebaasisüsteem, riistvara jne.<br />
Loogiline<br />
andmebaasi<br />
disain<br />
Kontseptuaalse andmemudeli esitamiseks võib kasutada<br />
olemi-suhte diagramme, millele lisaks tuleb luua<br />
olemitüüpide, seosetüüpide <strong>ja</strong> atribuutide dokumentatsioon.<br />
Enne kui saab asuda andmebaasi loogilise disaini<br />
läbiviimise juurde tuleb lõplikult otsustada, millisel<br />
andmemudelil põhineva andmebaasisüsteemi abil on<br />
kavas andmebaas realiseerida. Esialgne valik on tehtud<br />
juba strateegilise analüüsi käigus, kui kirjeldati üks või mitu<br />
süsteemi tehnilise arhitektuuri varianti. Loogilise disaini<br />
käigus koostatakse andmebaasi tehniline kirjeldus vastavalt<br />
valitud andmemudelile.<br />
Kui otsustatakse kasutada SQLi aluseks olevat<br />
andmemudelit, siis kirjeldatakse loogilise disaini tulemusena<br />
tabelid, nende veerud <strong>ja</strong> tabelitega seotud kitsendused.<br />
Muuhulgas määratakse tabelite veergude tüübid<br />
(standardsed, mitte konkreetse andmebaasisüsteemiga<br />
seotud). Tabelite kvaliteedi parandamiseks (andmete<br />
liiasuse vältimiseks) tuleks tabelid viia viiendale<br />
normaalkujule et nad vastaksid ortogonaalse disaini<br />
printsiibis kirjeldatud reeglile. Normaliseerimine aitab<br />
vähendada andmete liiasust üksiku tabeli piires.<br />
Ortogonaalse disaini printsiibist kinnipidamine aitab vältida<br />
andmete liiasust üle erinevat tabelite.<br />
SQL andmebaasi loogilise disaini käigus toimub:<br />
- SQL andmebaasiga sobimatute konstruktsioonide<br />
eemaldamine kontseptuaalsest andmemudelist.<br />
(Valikuline)<br />
- Tabelite leidmine.<br />
- Tabelite viimine kuni viiendale normaalkujule.<br />
- Kontroll, kas kõik tabelid rahuldavad ortogonaalse disaini<br />
printsiipi.<br />
- Kitsenduste kirjeldamine.<br />
Loogilist andmemudelit võib füüsiliselt realiseerida mitmel<br />
erineval viisil.<br />
5
TTÜ: Andmebaaside projekteerimine.<br />
Strateegiline analüüs <strong>ja</strong> detailanalüüs (2012)<br />
Andmebaasi<br />
loomissamm<br />
Füüsiline<br />
andmebaasi<br />
disain<br />
Kirjeldus<br />
© Erki Eessaar<br />
Füüsiline disain optimeerib / häälestab loogilise disaini<br />
lahendusi konkreetsete “füüsiliste” keskkondade <strong>ja</strong>oks. Enne<br />
kui saab asuda andmebaasi füüsilise disaini läbiviimise<br />
juurde tuleb lõplikult otsustada, millise<br />
andmebaasisüsteemi abil on kavas andmebaas<br />
realiseerida. Vähemalt SQL andmebaasisüsteemide puhul<br />
tuleb tõdeda, et erinevates andmebaasisüsteemides on<br />
küllaltki erinevad võimalused andmebaasi realiseerimiseks.<br />
Füüsiline disain andmete osas (andmete füüsiline<br />
projekteerimine) sisaldab:<br />
- Valitakse lõplikult väl<strong>ja</strong> kasutatav andmebaasisüsteem.<br />
Esialgne valik on tehtud juba strateegilise analüüsi<br />
käigus, kui kirjeldati üks või mitu süsteemi tehnilise<br />
arhitektuuri varianti.<br />
Eeldame, et kasutatakse SQL andmebaasisüsteemi.<br />
- Loogilise andmemudeli viimine konkreetse<br />
andmebaasisüsteemi tarkvara konteksti arvestades seal<br />
kasutatavat SQLi dialekti.<br />
- Andmetüüpide täpsustamine vastavalt valitud<br />
andmebaasisüsteemi võimalustele.<br />
- Tabelite valikulise denormaliseerimise (tabelite<br />
normaliseerituse astme vähendamise) kaalumine<br />
mõningate eriti tähtsate andmebaasioperatsioonide<br />
töökiiruse tõstmise eesmärgil.<br />
- Mitmesuguste füüsilise disaini objektide (indeksid,<br />
arvu<strong>ja</strong>da generaatorid, abitabelid, trigerid, rutiinid)<br />
kavandamine.<br />
Füüsilise disaini käigus kavandatakse ka andmebaasi<br />
füüsilise taseme organiseerimine. Ka selle puhul sõltuvad<br />
võimalused väga palju kasutatavast andmebaasisüsteemist.<br />
Näiteid küsimustest, millele tuleb füüsilise disaini käigus<br />
vastus leida:<br />
- Kas tabelid tuleks <strong>ja</strong>gada füüsilisel tasemel<br />
sektsioonideks, mida saab paigutada erinevatesse<br />
failidesse <strong>ja</strong> kõvaketastele?<br />
- Kui suured peaksid olema andmeplokid, millesse<br />
füüsilisel tasemel andmeid salvestatakse?<br />
- Kui palju peaks andmeplokkides olema vaba ruumi?<br />
- Kas andmed peaksid olema andmefailides sorteeritud<br />
ning kui <strong>ja</strong>h, siis milliste andmeväärtuste järgi<br />
sorteerimist läbi viia?<br />
- Kas <strong>ja</strong> milliseid andmeid tuleks pakkida?<br />
- Kas <strong>ja</strong> milliseid tabeli veerge tuleks indekseerida ning<br />
millist tüüpi indekseid tuleks kasutada?<br />
- Kas <strong>ja</strong> milliste veergude kohta peab andmebaasisüsteem<br />
koguma informatsiooni nendes veergudes olevate<br />
väärtuste <strong>ja</strong>otuse kohta (koostama histogramme)?<br />
s <strong>ja</strong> milliseid hetktõmmiseid tuleks kasutada päringute<br />
töökiiruse parandamiseks?<br />
6
TTÜ: Andmebaaside projekteerimine.<br />
Strateegiline analüüs <strong>ja</strong> detailanalüüs (2012)<br />
Andmebaasi<br />
loomissamm<br />
Andmebaasi<br />
realiseerimine<br />
Andmebaasi<br />
rakendamine<br />
Andmebaasi<br />
hooldamine<br />
Kirjeldus<br />
© Erki Eessaar<br />
Andmebaasi loomiseks va<strong>ja</strong>like käsufailide koostamine <strong>ja</strong><br />
nende käivitamine konkreetses andmebaasisüsteemis.<br />
Käsufailid sisaldavad SQL lauseid andmebaasiobjektide<br />
(näiteks baastabelid <strong>ja</strong> vaated) loomiseks. Kui<br />
projekteerimiseks kasutatakse CASE (Computer Aided<br />
System Engineering) vahendit, siis saab käsufailid<br />
automaatselt genereerida <strong>ja</strong> ka andmebaasisüsteemis<br />
käivitada. Samaaegselt toimub andmebaasi <strong>ja</strong> seda<br />
kasutavate programmide testimine. Testimine ei tõesta, et<br />
vigu ei ole – ta tõestab et vead on olemas.<br />
Rakendamise käigus toimub loodud andmebaasi telli<strong>ja</strong><br />
juures töölerakendamine. Muuhulgas võib olla va<strong>ja</strong>lik läbi<br />
viia andmesiire, mille käigus kantakse loodud andmebaasi<br />
andmed süsteemis varem kasutusel olnud andmebaasidest<br />
<strong>ja</strong> välistest allikatest.<br />
Andmebaasi töö jälgimine <strong>ja</strong> tagamine. See on andmebaasi<br />
administraatori (Database Administrator -DBA) ülesanne.<br />
- Tagatakse andmebaasi tõrgeteta töö (kasuta<strong>ja</strong>te<br />
haldamine, andmete varundamine <strong>ja</strong> taastamine jne.)<br />
- Jälgitakse andmebaasis toimuvate operatsioonide<br />
töökiirust <strong>ja</strong> va<strong>ja</strong>dusel püütakse seda parandada (nt.<br />
indeksite lisamine <strong>ja</strong> kustutamine, rutiinides kasutatavate<br />
SQL lausete ümberkirjutamine, tabelite sektsioonideks<br />
<strong>ja</strong>gamine, tabelite <strong>ja</strong> indeksite juhtparameetrite<br />
muutmine). Väga suure osa piisava töökiiruse<br />
tagamisest annab korrektne andmebaasi analüüs <strong>ja</strong><br />
disain.<br />
- Andmebaasi väiksemate muudatuste sisseviimine.<br />
Tekib küsimus, kuidas neid süsteemiarenduse tegevusi organiseerida?<br />
Kose mudel e. veelange mudel (waterfall) – Klassikalise kose mudeli<br />
alusel on süsteemi arendamine <strong>ja</strong>otatud üksteisele järgnevateks etappideks<br />
ning arenduse järgmist etappi ei alustata enne kui eelmine etapp on<br />
lõpetatud. Ühe arendustsükli läbimine tähendab kõigi järjestikuliste etappide<br />
läbimist. Ühe arendustsükli läbimine võib võtta aega 1-2 aastat. Nii<br />
andmebaas kui seda kasutav tarkvara valmivad arendustsükli lõpuks.<br />
Süsteemiarendus koosneb järgmistest järjestikulistest etappidest (loetelu on<br />
esitatud varasemast hilisema poole):<br />
1. Strateegiline analüüs.<br />
2. Detailanalüüs.<br />
3. Disain.<br />
4. Realiseerimine (Ehitamine).<br />
5. Rakendamine (Üleviimine).<br />
6. Hooldus.<br />
Nõuete kogumisest süsteemi töölerakendumiseni kulub palju aega ning<br />
vahepeal võivad nõuded süsteemile <strong>ja</strong> parimad võimalikud tehnilised<br />
lahendused olla muutunud. Näited probleemidest:<br />
7
TTÜ: Andmebaaside projekteerimine.<br />
Strateegiline analüüs <strong>ja</strong> detailanalüüs (2012)<br />
© Erki Eessaar<br />
• Nõuded peavad olema fikseeritud, enne kui arendamine saab jätkuda,<br />
kuid reaalses maailmas on nõuded muutuvad <strong>ja</strong> palju nõudeid tekib alles<br />
süsteemi esimese versiooni kasutamisel.<br />
• Probleemid võivad ilmneda alles süsteemi testimise käigus.<br />
• Töökiirust saab testida alles siis, kui süsteem on peaaegu valmis.<br />
• Kasuta<strong>ja</strong> näeb esimest korda töötavat süsteemi alles siis, kui see on peaaegu<br />
valmis.<br />
• Kogu süsteem valmib korraga <strong>ja</strong> selle <strong>ja</strong>oks läheb vähemalt 1-2 aastat<br />
aega. Selle a<strong>ja</strong>ga on kasuta<strong>ja</strong>te nõuded suure tõenäosusega muutunud.<br />
Strateegiline<br />
analüüs<br />
Detailanalüüs<br />
Disain<br />
Ehitamine<br />
Rakendamine<br />
aeg<br />
Joonis 1 Süsteemiarendus "kose" mudeli alusel.<br />
Hooldamine<br />
Kose mudeli puudustest ülesaamiseks on seda arendatud/teisendatud.<br />
Näiteks:<br />
• Kose mudel koos kattuvate etappidega: lubatakse alustada järgmist<br />
etappi enne eelmise lõppu. Kui mingi etapi läbimise käigus ilmnevad<br />
probleemid, siis võib nende lahendamiseks teha tegevusi, mis<br />
kuuluvad eelmisesse etappi.<br />
• Järkväl<strong>ja</strong>stusega elutsükkel: Fowler (2007) toob näite, et sellise mudeli<br />
alusel läbiviidavas projektis võidakse kasutada neli kuud analüüsiks <strong>ja</strong><br />
projekteerimiseks koskstiilis, millele järgneb neli kahekuulist süsteemi<br />
iteratiivset versioonitsüklit.<br />
Evolutsiooniline prototüüpimine – Koostatakse süsteemi prototüüp.<br />
Prototüüp on tarkvarasüsteem, mis simuleerib või animeerib teise süsteemi<br />
struktuuri, funktsionaalsust, tegevusi või esitust. Seda kasuta<strong>ja</strong>le ette näidates<br />
<strong>ja</strong> tema poolt nõutud muudatusi sisse viies arendatakse väl<strong>ja</strong> töötav süsteem.<br />
(Prototüüpimise kohta lugege dokumendist kataloogis "Lisamater<strong>ja</strong>l").<br />
Spiraalne mudel – süsteemiarendus koosneb arendustsüklitest, millest<br />
igaühe käigus projekteeritakse / realiseeritakse / testitakse süsteemi või<br />
mingit selle osa üha täpsemalt.<br />
8
TTÜ: Andmebaaside projekteerimine.<br />
Strateegiline analüüs <strong>ja</strong> detailanalüüs (2012)<br />
© Erki Eessaar<br />
Iteratiivne mudel – süsteemiarendus koosneb lühikestest arendustsüklitest,<br />
millest igaühe käigus projekteeritakse/ realiseeritakse/ testitakse süsteemi<br />
mingit omadust/ osa. Ka andmebaasi ei projekteerita / ehitata ühekorraga,<br />
vaid seda tehakse järk-järgult koos ülejäänud süsteemi kasvamisega.<br />
Iteratiivsel mudelil põhineva süsteemiarenduse metoodikate näideteks on<br />
näiteks Rationali unifitseeritud protsess (RUP) <strong>ja</strong> selle edasiarenduseks olev<br />
ettevõtte unifitseeritud protsess (EUP). Samuti järgib iteratiivset mudelit<br />
näiteks ekstreemprogrammeerimine. Esimest kahte võib isegi nimetada<br />
metoodikate perekonnaks, sest tegemist on raamistikega mis võimaldavad<br />
luua konkreetse projekti <strong>ja</strong>oks kõige sobivama metoodika.<br />
Viimastel aastatel on üha populaarsemaks muutunud agiilmetoodikad<br />
(näiteks ekstreemprogrammeerimine <strong>ja</strong> Scrum) (Leis, 2000). Taolisi<br />
metoodikaid on päris palju. Järgnevalt on nimetatud mõned nende<br />
põhiprintsiibid:<br />
• Tarkvara arendamine iteratiivselt, kasutades lühikesi iteratsioone (1–2<br />
nädalat).<br />
• Minimalism – dokumentatsiooniga ei tule üle pingutada. Loodav lahendus<br />
peab olema lihtne. "Pole va<strong>ja</strong> kelli <strong>ja</strong> vilesid".<br />
• Väga sage <strong>ja</strong> vara<strong>ja</strong>ne testimine.<br />
• Sotsiaalsete väärtuste <strong>ja</strong> meeskonnatöö olulisuse rõhutamine.<br />
• Väga oluline on tihe suhtlus tarkvara telli<strong>ja</strong>ga <strong>ja</strong> tema esinda<strong>ja</strong>te poolne<br />
tagasiside loodava tarkvara kohta. Selle saavutamiseks võiks näiteks üks<br />
telli<strong>ja</strong> esinda<strong>ja</strong> pidevalt viibida süsteemi arenda<strong>ja</strong>te juures <strong>ja</strong> anda<br />
tagasisidet valminud tarkvaralahenduste kohta.<br />
9
TTÜ: Andmebaaside projekteerimine.<br />
Strateegiline analüüs <strong>ja</strong> detailanalüüs (2012)<br />
© Erki Eessaar<br />
3. Arendusmetoodikad<br />
Antud kursuses räägitakse andmebaasi loomise metoodikast. Enne tuleks<br />
üritada mõista, mis asi see metoodika on.<br />
Cockburn (1997) loetleb valdkondi, mille kohta üks süsteemi arendamist<br />
juhendav metoodika peaks juhiseid andma:<br />
Tabel 3 Arendusmetoodika komponendid.<br />
Metoodika<br />
valdkond<br />
rollid<br />
oskused<br />
meeskonnad<br />
standardid<br />
töövahendid<br />
tegevused<br />
tulemused<br />
kvaliteet<br />
Valdkonna kirjeldus<br />
Metoodika peaks kirjeldama arendusprotsessis osalevad<br />
osapooled ning nende ülesanded. Rollide näiteks on<br />
projektijuht, ärianalüütik, andmete modelleeri<strong>ja</strong>,<br />
andmebaasi administraator.<br />
Metoodika peaks kirjeldama rollide täit<strong>ja</strong>telt oodatavad<br />
oskused.<br />
Metoodika peaks kirjeldama põhimõtted, kuidas<br />
süsteemiarenduse käigus kasutada grupitööd.<br />
Metoodika peaks loetlema standardid, mida tuleb<br />
süsteemiarenduse käigus jälgida.<br />
Metoodika peaks kirjeldama töövahendeid, mida<br />
süsteemiarenduse käigus võiks kasutada. Töövahendite<br />
on tarkvarapaketid aga ka näiteks mitmesugused<br />
küsimustikud, mis aitavad hinnata tehtud töö kvaliteeti.<br />
Metoodika peaks kirjeldama süsteemiarenduse<br />
<strong>ja</strong>gunemise etappideks <strong>ja</strong> nende etappide käigus tehtavad<br />
tegevused.<br />
Metoodika peaks kirjeldama dokumendid, mis<br />
süsteemiarenduse käigus luuakse.<br />
Metoodika peaks kirjeldama meetodid süsteemiarenduse<br />
tulemuste kvaliteedi hindamiseks.<br />
Metoodikaid on väga erinevaid. Mõned neist on kompaktsed soovituste<br />
kogumid teised aga mahukad (monumentaalsed) kirjeldused, mis juhendavad<br />
süsteemiarenduse iga aspekti.<br />
Andmebaaside arendusprotsessi organiseerimine konkreetsetes firmades /<br />
projektides nõuab kaasaegsete arendusmetoodikate kasutamist.<br />
Andmebaaside arendusmetoodikad on alamhulk infosüsteemi kogu elutsüklit<br />
toetavatest metoodikatest, mida saab kasutada andmebaaside ehitamisel<br />
alates va<strong>ja</strong>duste defineerimisest/analüüsist läbi projekteerimise kuni füüsilise<br />
realiseerimiseni.<br />
Paljusid käesoleval a<strong>ja</strong>l populaarseid arendusmetoodikaid iseloomustavad<br />
omadused nagu:<br />
- iteratiivne (st. süsteemi arendatakse osade kaupa);<br />
- kasuta<strong>ja</strong>t laialdaselt kaasahaarav;<br />
10
TTÜ: Andmebaaside projekteerimine.<br />
Strateegiline analüüs <strong>ja</strong> detailanalüüs (2012)<br />
© Erki Eessaar<br />
- sisaldama taaskasutamist (dokumendimallide kasutamine, mustrite<br />
kasutamine, tarkvarakomponentide kasutamine).<br />
Kui otsitakse organisatsiooni <strong>ja</strong>oks andmebaaside arendusmetoodikat, tasub<br />
valida kergesti omandatav <strong>ja</strong> kasutatav ning elektrooniliselt realiseeritud<br />
protsess, mida arendusmeeskonnad saavad läbi võrgu kiiresti erinevates<br />
asukohtades rakendada.<br />
Andmebaasi <strong>ja</strong> seda kasutavate rakenduste ehitamise keerukust saab<br />
vähendada kasutades projektides läbiproovitud andmebaaside arendamise<br />
meetodeid. Sellised meetodid annavad edasi heade projektimeeskondade<br />
parimaid kogemusi <strong>ja</strong> praktikaid, võimaldavad oluliselt vähendada projektiga<br />
seotud riske ning tähtaegu <strong>ja</strong> tõsta projektitulemuste kvaliteeti.<br />
3.1 Metoodika väärkasutused<br />
Metoodika vale kasutamine mõjutab väga suure tõenäosusega negatiivselt<br />
projekti tähtaegu. On üsna tavaline, et organisatsioonid kasutavad<br />
metoodikad kui protsessidiagramme või retsepte ilma ühtegi tegevust<br />
sisuliselt läbi mõtlemata. See võib lõppeda tohutu a<strong>ja</strong>raiskamisega, kui<br />
tehakse tegevusi <strong>ja</strong> toodetakse tulemusi mõistmata nende seost<br />
terviklahendusega.<br />
Metoodikaid on va<strong>ja</strong> häälestada konkreetsetele projektidele. Mitteva<strong>ja</strong>likud<br />
tegevused <strong>ja</strong> tulemused tuleb projektiplaanist kustutada.<br />
Metoodikad, mis on liiga keerukad kasutada <strong>ja</strong> õppida, ei leia kuigi palju<br />
kasutamist projektimeeskondade poolt. Mõningad metoodikad sisaldavad<br />
tuhandeid projekti pisidetaile. Tihedate projekti a<strong>ja</strong>graafikute korral heidetakse<br />
sellised metoodikad kõrvale.<br />
Oluline on uuendada metoodikaid a<strong>ja</strong>s. Uued projektikogemused <strong>ja</strong> parimad<br />
praktikad tuleb teatud a<strong>ja</strong>vahemike tagant metoodikasse lülitada.<br />
11
TTÜ: Andmebaaside projekteerimine.<br />
Strateegiline analüüs <strong>ja</strong> detailanalüüs (2012)<br />
© Erki Eessaar<br />
4. Strateegiline analüüs<br />
Järgnevalt räägitakse strateegilise analüüsi metoodikast, mis on väl<strong>ja</strong> töötatud<br />
TTÜ informaatikainstituudi tööta<strong>ja</strong>te poolt. Selle kohta lugege täiendavalt<br />
näiteks Rein Kuusiku artiklit a<strong>ja</strong>kir<strong>ja</strong>st A&A (Kuusik 2000).<br />
Metoodika koostamisel on lähtutud eeldustest, et organisatsioon va<strong>ja</strong>b<br />
edukaks toimimiseks infosüsteemi. Infosüsteemi arendamine ei ole ühekordne<br />
pingutus vaid pidev protsess ning organisatsioon, mis infosüsteemi kasutab,<br />
peab arendamisest aktiivselt osa võtma. See tähendab, et süsteemi tulevased<br />
kasuta<strong>ja</strong>d peaksid osalema süsteemi toimimise aluseks olevate protsesside<br />
(äriprotsesside) kirjeldamisel. Süsteemi sellisel viisil edukalt arendamiseks<br />
peab olema paigas vundament, milleks on tervikpilt loodavast süsteemist.<br />
Nimetatud tervikpilt saadakse strateegilise analüüsi tulemusena.<br />
Süsteemi arendamise algul on probleemiks, et arvutisüsteemi kasutavat<br />
infosüsteemi ei ole või vana infosüsteem ei rahulda enam kasuta<strong>ja</strong>id, kuid<br />
päris täpselt veel ei teata, mida uus süsteem peaks tegema. Strateegilise<br />
analüüsi käigus toimub piltlikult öeldes infosüsteemi projekteerimise<br />
ülesandega tutvumine <strong>ja</strong> esialgse lahendusplaani koostamine.<br />
Strateegilise analüüsi teostamisel on väga oluline oskus näha ette uuritava<br />
organisatsiooni arengut umbes 5 aasta perspektiivis. Näiteks oletame, et<br />
antud hetkel tegeleb uut infosüsteemi va<strong>ja</strong>v ettevõte ainult hulgimüügiga. Kuid<br />
lähema paari aasta jooksul plaanib ta hakata tegelema ka <strong>ja</strong>emüügiga. Kui<br />
seda teadmist mitte arvesse võtta, siis on süsteemiarenduse tulemuseks<br />
infosüsteem, mida tuleb juba mõne aasta pärast hakata oluliselt muutma <strong>ja</strong><br />
täiendama. Loodava süsteemi andmebaas tuleks üritada kavandada nii<br />
paindlik, et ta võimaldaks rahuldada ka tulevikus esilekerkivad nõuded.<br />
Suvalisel süsteemil on Isotamm (1998) põh<strong>ja</strong>l kaks põhiomadust:<br />
- Mitteamorfsus, mis tähendab, et süsteemis on võimalik eristada<br />
iseseisvaid komponente, milleks on süsteemi elemendid <strong>ja</strong><br />
elementidevahelised seosed. Süsteemil on struktuur <strong>ja</strong> ta ei ole amorfne.<br />
- Terviklikkus, mis tähendab, et suvaline süsteem on eristatav teistest<br />
süsteemidest, st. seosed süsteemi elementide vahel on tugevamad kui<br />
süsteemi <strong>ja</strong> teiste süsteemide vahel.<br />
Millised on strateegilise analüüsi põhilised tulemused?<br />
1) Suure terviksüsteemi tükeldamine (dekomponeerimine) suhteliselt<br />
terviklikeks <strong>ja</strong> iseseisvalt arendatavateks allsüsteemideks. Samuti<br />
määratakse, kuidas need allsüsteemid üksteist kasutavad. Iga sellise<br />
allsüsteemi peaks saama arendada omaette projektina. Allsüsteemide<br />
leidmine võimaldab ühtlasi kindlaks määrata süsteemi kui terviku skoobi –<br />
millistest elementidest süsteem koosneb <strong>ja</strong> millised elemendid jäävad<br />
uuritava süsteemi piiridest väl<strong>ja</strong> ning kuuluvad teistesse süsteemidesse.<br />
2) Süsteemi arhitektuuri esialgne kirjeldamine. Larman (2002) defineerib<br />
arhitektuuri kui süsteemi ülesehituse, eesmärkide <strong>ja</strong> struktuuri kirjeldust.<br />
12
TTÜ: Andmebaaside projekteerimine.<br />
Strateegiline analüüs <strong>ja</strong> detailanalüüs (2012)<br />
© Erki Eessaar<br />
Koostatavas arhitektuurivaates kirjeldatakse allsüsteemide paigutus<br />
erinevates asukohtades <strong>ja</strong> tehniline arhitektuur – kasutatav tarkvara,<br />
riistvara, arvutivõrgud. On võimalik, et kirjeldatakse mitu erinevat<br />
arhitektuurilist lahendust millest süsteemi hilisema arendamise käigus<br />
valitakse kõige sobivam.<br />
3) Arendamise strateegia loomine, milles määratletakse allsüsteemidele<br />
vastavad arendusprojektid, nende prioriteedid, ressursiva<strong>ja</strong>dused, riskid,<br />
projektorganisatsioon. Antakse esialgne hinnang sellele, millises osas<br />
tuleb süsteem lasta tellimustööna valmis teha <strong>ja</strong> millises osas võib<br />
kasutada olemasolevaid tarkvarasüsteeme.<br />
4.1 Allsüsteemid<br />
Süsteemi <strong>ja</strong>gamine allsüsteemideks võimaldab lihtsamalt süsteemi kui tervikut<br />
hallata, sest "teades osiste koostoimimist, on üksikute osiste arendamine<br />
palju lihtsam kui sellisteks osadeks <strong>ja</strong>otamata terviku arendamine<br />
(analoogiliselt tarkvaraarenduse/programmeerimise praktikaga, kus suure<br />
ülesande <strong>ja</strong>otamine väiksemateks tagab realisatsiooni lihtsustumise <strong>ja</strong> seega<br />
ka tulemuse parema kvaliteedi, s.o ülesande üldine keerukus väheneb)."<br />
(Kuusik, 2000).<br />
Vaatame terviksüsteemi näitena ülikooli õppeinfosüsteemi. Terviksüsteemi<br />
tükeldamisel allsüsteemideks leitakse TTÜ Informaatikainstituudis<br />
väl<strong>ja</strong>töötatud käsitluse kohaselt paralleelselt kolme erinevat tüüpi allsüsteemid<br />
<strong>ja</strong> nende vahelised seosed.<br />
• Pädevusalad.<br />
• Funktsionaalsed allsüsteemid.<br />
• Registrid.<br />
Organisatsiooniline tükeldus pädevusala allsüsteemideks. Pädevusala on<br />
konkreetse organisatsiooni juhi vastutuspiirkond. Pädevusala vastab mõnele<br />
organisatsiooni struktuuriüksusele, ametikohale või infosüsteemi kasuta<strong>ja</strong><br />
rollile. Igal pädevusalal on funktsioonid (ülesanded), mida ta peab täitma <strong>ja</strong><br />
infova<strong>ja</strong>dused (nõuded andmetele), mida ta peab kasutama. Mitu isikut võivad<br />
omada sama pädevusala <strong>ja</strong> üks isik võib omada mitut pädevusala.<br />
Ülikooli infosüsteemi pädevusalade näited.<br />
- Üliõpilase pädevusala.<br />
- Õppejõu pädevusala.<br />
- Dekanaadi juhata<strong>ja</strong> pädevusala.<br />
- ...<br />
Pädevusalade kirjeldustest arenevad süsteemiarenduse käigus väl<strong>ja</strong><br />
kasuta<strong>ja</strong>te töökohtade <strong>ja</strong> kasuta<strong>ja</strong>liideste kirjeldused.<br />
Iga pädevusala kirjeldatakse koostöös selle pädevusala esinda<strong>ja</strong>tega<br />
(konkreetse isikutega kes hakkaksid seda süsteemi kasutama). Pädevusalade<br />
esinda<strong>ja</strong>id küsitletakse <strong>ja</strong> nende tööd jälgitakse. Pädevusala esinda<strong>ja</strong>d<br />
peaksid pidevalt hindama enda pädevusala kohta koostatavaid mudeleid.<br />
13
TTÜ: Andmebaaside projekteerimine.<br />
Strateegiline analüüs <strong>ja</strong> detailanalüüs (2012)<br />
© Erki Eessaar<br />
Väikese koolituse järel võiksid pädevusala esinda<strong>ja</strong>d ka ise koostada oma<br />
pädevusala kirjeldavaid mudeleid. Pädevusalasid kirjeldavad mudelid on<br />
aluseks infosüsteemi projekteeri<strong>ja</strong>tele (süsteemi arendamisega tegeleva IT<br />
firma esinda<strong>ja</strong>d), kes koostavad nende põh<strong>ja</strong>l süsteemi funktsionaalse <strong>ja</strong><br />
andmekeskse tükelduse. Loomulikult on kõigi allsüsteemide mudelite<br />
koostamise puhul va<strong>ja</strong>lik tihe suhtlus projekteeri<strong>ja</strong>te ning süsteemi telli<strong>ja</strong>te <strong>ja</strong><br />
kasuta<strong>ja</strong>te vahel.<br />
Funktsionaalne tükeldus funktsionaalseteks allsüsteemideks.<br />
Funktsionaalne allsüsteem vastab ühele infosüsteemi põhifunktsioonile.<br />
Ülikooli infosüsteemi funktsionaalsete allsüsteemide näited.<br />
- Õppekavade arvestus.<br />
- Õpingukavade arvestus.<br />
- Õppetulemuste arvestus.<br />
- Õppeainete arvestus.<br />
- Tunniplaanide arvestus.<br />
- Üliõpilaste arvestus.<br />
- Tööta<strong>ja</strong>te arvestus.<br />
- Tööta<strong>ja</strong>te tööpanuse arvestus.<br />
- …<br />
Funktsionaalsete allsüsteemide kirjeldustest arenevad süsteemiarenduse<br />
käigus väl<strong>ja</strong> rakendustarkvara moodulid, mis aitavad pädevusalade<br />
esinda<strong>ja</strong>tel oma ülesandeid täita.<br />
Andmekeskne tükeldus andmekeskseteks allsüsteemideks ehk<br />
andmekogudeks ehk registriteks. Registriks nimetame loogilist andmebaasi,<br />
milles hoitakse ühele iseseisvat elutsüklit omavale põhiolemitüübile vastavaid<br />
andmeid ning realiseeritakse selle olemitüübiga seotud elementaarsed<br />
registreerimise <strong>ja</strong> päringu teenused.<br />
Ülikooli infosüsteemi korral on põhiolemitüübid näiteks üliõpilane, õppekava <strong>ja</strong><br />
õppeaine ning teenusteks näiteks uue õppekava sisestamine <strong>ja</strong> õppeaine<br />
otsing koodi või nimetuse järgi.<br />
Ülikooli infosüsteemi registrite näited.<br />
- Üliõpilaste register.<br />
- Õppejõudude register.<br />
- Õppekavade register.<br />
- Õppeainete register.<br />
- Õppetulemuste register.<br />
- …<br />
Moriarty (2001) loetleb kõige põhilisemaid äriga seotud mõisteid: osapooled,<br />
asukohad, sündmused, lepingud, kontod, tooted <strong>ja</strong> teenused, turud,<br />
võimalused, ressursid, kliendid, müügid. Sellistele mõistetele vastavaid<br />
andmeid on va<strong>ja</strong> hallata peaaegu igas infosüsteemis ning seega võib igale<br />
sellisele mõistele vastata omaette register.<br />
14
TTÜ: Andmebaaside projekteerimine.<br />
Strateegiline analüüs <strong>ja</strong> detailanalüüs (2012)<br />
© Erki Eessaar<br />
Registrite kirjeldustest arenevad süsteemiarenduse käigus väl<strong>ja</strong><br />
andmebaasid, mida kasutab otseselt rakendustarkvara <strong>ja</strong> nende kaudu<br />
pädevusalade esinda<strong>ja</strong>d oma ülesannete täitmiseks.<br />
Registri tüüpi infosüsteemi põhiülesandeks on andmete registreerimine <strong>ja</strong><br />
talletamine, et neid saaks va<strong>ja</strong>dusel hiljem kasutada. Selline infosüsteem<br />
hõlmab lisaks registri andmebaasile ka sellega seotud funktsionaalsed ning<br />
pädevusala allsüsteemid.<br />
Registri tüüpi infosüsteeme va<strong>ja</strong>vad näiteks riigi andmekogud, milleks on<br />
Eesti Vabariigi andmekogude seaduse põh<strong>ja</strong>l riigi põhiregistrid, riiklikud<br />
registrid <strong>ja</strong> riigiasutuste peetavad muud andmekogud.<br />
15
TTÜ: Andmebaaside projekteerimine.<br />
Strateegiline analüüs <strong>ja</strong> detailanalüüs (2012)<br />
© Erki Eessaar<br />
4.2 Allsüsteemide vahelised seosed<br />
Kuidas on erinevad allsüsteemid omavahel seotud? Registrites asuvad<br />
andmed, mida kasutavad funktsionaalsed allsüsteemid <strong>ja</strong> mis peavad aitama<br />
lõppkokkuvõttes infosüsteemi kasuta<strong>ja</strong>tel (pädevusalade esinda<strong>ja</strong>tel) oma<br />
ülesandeid täita. Funktsionaalsed allsüsteemid pakuvad teenuseid<br />
pädevusaladele ning oma töö läbiviimiseks kasutavad registrites olevaid<br />
andmeid. Funktsionaalsed allsüsteemid võivad registritesse andmeid lisada,<br />
registrites olevaid andmeid muuta, registrites olevaid andmeid kustutada <strong>ja</strong><br />
lugeda registris olevaid andmeid.<br />
Igal registril on üks või mitu pädevusala, mille esinda<strong>ja</strong>d haldavad seda<br />
registrit – loevad/lisavad/muudavad/kustutavad selles registris andmeid. Igal<br />
registril on null või rohkem pädevusala, mille esinda<strong>ja</strong>d ainult loevad andmeid<br />
sellest registrist. Pädevusalad suhtlevad registritega funktsionaalsete<br />
allsüsteemide kaudu. Tüüpiliselt on registris andmete haldamine (registri<br />
teenindamine) ühe funktsionaalse allsüsteemi ülesanne kuid registris olevaid<br />
andmeid loevad mitmed allsüsteemid.<br />
Eelnevast tulenevalt on infosüsteemi funktsionaalseid allsüsteeme võimalik<br />
leida põhiolemitüüpide põh<strong>ja</strong>l. Igale põhiolemitüübile vastab register ning ka<br />
funktsionaalne allsüsteem mille kaudu toimub selle registri haldamine.<br />
Vaatleme järgnevalt näidet allsüsteemide vaheliste seoste kohta. Ülikooli<br />
infosüsteemi üheks allsüsteemiks on õpingukavade arvestus. Õpingukava on<br />
Tallinna Tehnikaülikooli õppetegevuse eeskir<strong>ja</strong> kohaselt "õppuri poolt<br />
eelseisvaks semestriks valitud õppeainete loend, mida ta kohustub õppima;<br />
õppekava läbimise individuaalne tee semestrite kaupa." Üliõpilane peab<br />
esitama üldjuhul õpingukava iga semestri alguses.<br />
Õpingukavade allsüsteemi kasutavad üliõpilase, õppejõu <strong>ja</strong> dekanaadi<br />
sekretäri pädevusalad. Üliõpilane koostab õpingukava, õppejõud otsustab kas<br />
lubada üliõpilasel õppeainet õppida ning dekanaadi sekretär vaatab<br />
õpingukavade esitamise aruannet. Õpingukavade funktsionaalne allsüsteem<br />
haldab (teenindab) õpingukavade registrit, st. selle allsüsteemi kaudu toimub<br />
andmete lugemine/ lisamine/ muutmine/ kustutamine õpingukavade registris.<br />
Lisaks sellele loeb õpingukavade funktsionaalne allsüsteem andmeid<br />
erinevatest registritest nagu õppeainete register, üliõpilaste register, tööta<strong>ja</strong>te<br />
register <strong>ja</strong> õppetulemuste register. Näiteks õppeainete registris olevaid<br />
andmeid on va<strong>ja</strong> lugeda, sest õpingukava määrab ära semestris õpitavad<br />
õppeained. Õppetulemuste registris olevaid andmeid on va<strong>ja</strong> lugeda et teha<br />
kindlaks, kas üliõpilasel on õigus õppeainet oma õpingukavasse valida (nt.<br />
kas ta on edukalt õppinud õppeaine eelduseks olevat õppeainet). Nimetatud<br />
allsüsteemid moodustavad ühe (väikese) osa ülikooli infosüsteemist kui<br />
tervikust.<br />
16
TTÜ: Andmebaaside projekteerimine.<br />
Strateegiline analüüs <strong>ja</strong> detailanalüüs (2012)<br />
© Erki Eessaar<br />
17
Andmebaaside projekteerimine.<br />
Strateegiline analüüs <strong>ja</strong> detailanalüüs (2012)<br />
© Erki Eessaar<br />
Dekanaadi sekretär<br />
kasutab<br />
kasutab<br />
Õppejõud<br />
kasutab<br />
Üliõpilane<br />
kasutab<br />
kasutab<br />
Dekanaadi sekretäri<br />
töökoht<br />
Õppejõu töökoht<br />
Üliõpilase töökoht<br />
Õpingukavade funktsionaalne allsüsteem<br />
loeb<br />
loeb<br />
haldab<br />
loeb<br />
loeb<br />
loeb<br />
haldab<br />
loeb<br />
Õppetulemuste<br />
register<br />
Tööta<strong>ja</strong>te<br />
register<br />
Õpingukavade Üliõpilaster register<br />
register<br />
õppimise tulemuseks saadakse<br />
Õppeainete<br />
register<br />
Õppetulemus<br />
Tööta<strong>ja</strong><br />
kinnitab<br />
Õpingukava<br />
esitab<br />
Üliõpilane<br />
Õppeaine<br />
paneb õppimisele hinde<br />
õpingukava sisaldab<br />
Joonis 2 Õpingukavade infosüsteemi <strong>ja</strong>otus allsüsteemideks.<br />
18
TTÜ: Andmebaaside projekteerimine.<br />
Strateegiline analüüs <strong>ja</strong> detailanalüüs (2012)<br />
© Erki Eessaar<br />
4.3 Allsüsteemide liigitus<br />
Pädevusalasid võib liigitada vastavalt sellele kas nende pädevusalade<br />
esinda<strong>ja</strong>d:<br />
• töötavad uuritavas organisatsioonis. Näiteks ülikooli infosüsteemis on<br />
üheks selliseks pädevusalaks õppejõud.<br />
• ei tööta uuritavas organisatsioonis, kuid kasutavad selle teenuseid.<br />
Näiteks ülikooli infosüsteemis on sellisteks pädevusaladeks üliõpilane, kes<br />
õpib ülikoolis või haridusministeerium, mille esinda<strong>ja</strong>d soovivad saada<br />
ülikoolilt aruandeid.<br />
Funktsionaalseid allsüsteeme <strong>ja</strong> registreid (edaspidi allsüsteeme) on võimalik<br />
liigitada sisulisteks <strong>ja</strong> administratiivseteks e. tugisüsteemideks.<br />
Sisuline allsüsteem võimaldab viia läbi tegevusi milleks infosüsteemi va<strong>ja</strong>v<br />
organisatsioon on otseselt ellu kutsutud. Näiteks ülikooli ülesandeks on<br />
õpetada üliõpilasi <strong>ja</strong> viia läbi teadustööd. Ülikooli infosüsteemi sisuliste<br />
funktsionaalsete allsüsteemide näited on õppekavade arvestus, õpingukavade<br />
arvestus, õppetulemuste arvestus, õppeainete arvestus, tunniplaanide<br />
arvestus <strong>ja</strong> üliõpilaste arvestus.<br />
Ülikooli infosüsteemi administratiivsete funktsionaalsete allsüsteemide näited<br />
on dokumentide arvestus, lepingute arvestus, ruumide arvestus <strong>ja</strong> tööta<strong>ja</strong>te<br />
arvestus.<br />
Administratiivsete allsüsteemide puhul on suurem võimalus, et leiduvad<br />
mustrid või universaalsed mudelid, mida selliste allsüsteemide kirjeldamiseks<br />
võib kasutada. Samuti on administratiivse allsüsteemi puhul suurem võimalus,<br />
et leidub rakenduspakette, mis pakuvad selliselt allsüsteemilt oodatavat<br />
funktsionaalsust. Soovitame tutvuda Koov (2001) poolt koostatud raamatuga,<br />
kus kirjeldatakse universaalseid programme (raamatupidamine, kliendihaldus,<br />
dokumendihaldus jne.), mingi tegevusvaldkonna (kauplus, hulgiladu, liising<br />
jne.) <strong>ja</strong>oks koostatud eriprogramme ning riigi <strong>ja</strong> kohaliku omavalitsuse töö<br />
hõlbustamiseks koostatud programme.<br />
Sellisel juhul tuleb otsustada, kas allsüsteemi valmistegemiseks tuleb<br />
kohandada olemasolevat rakenduspaketti või ehitada süsteem puhtalt<br />
uuritava organisatsiooni nõuetest lähtudes. Isotamm (1998) leiab, et<br />
rakenduspakettide kasutamise eelisteks on näiteks süsteemi kiire valmimine<br />
<strong>ja</strong> rakenduspaketi dokumentatsiooni olemasolu. Kui rakenduspakett vastab<br />
piisavalt hästi loodava infosüsteemi nõuetele <strong>ja</strong> ei va<strong>ja</strong> ulatuslikku<br />
kohandamist, siis on selle kasutamise hind ette teada <strong>ja</strong> võib kujuneda<br />
väiksemaks kui süsteemi nullist ehitamisel.<br />
Isotamm (1998) märgib, et rakenduspakettide kasutamise probleemideks on:<br />
• paketi liigne üldisus, mis tingib va<strong>ja</strong>duse seda konkreetse<br />
organisatsiooni nõuetega kohandada;<br />
• paketi müü<strong>ja</strong>l pole aega ost<strong>ja</strong> probleemidega põh<strong>ja</strong>likult tegeleda, sest<br />
tal on palju kliente;<br />
19
TTÜ: Andmebaaside projekteerimine.<br />
Strateegiline analüüs <strong>ja</strong> detailanalüüs (2012)<br />
© Erki Eessaar<br />
• paketi ost<strong>ja</strong> soovidele vastav kohandamine nõuab üldjuhul müü<strong>ja</strong><br />
kaasabi ning selle eest tuleb eraldi maksta.<br />
Seega olemasoleva rakenduspaketi kasutamine ei pruugi alati olla kõige<br />
otstarbekam, sest selle konkreetse organisatsiooni nõuetega kohandamine<br />
võib osutuda liiga keeruliseks, aeganõudvaks <strong>ja</strong> kulukaks.<br />
4.4 Nõuandeid süsteemi allsüsteemideks <strong>ja</strong>gamiseks<br />
Allsüsteemideks <strong>ja</strong>otamise ülesandele ei ole ühte ainuõiget lahendust vaid on<br />
paremad <strong>ja</strong> halvemad lahendused. Kuid kui allsüsteemideks <strong>ja</strong>gamine pole<br />
kõige paremini õnnestunud, siis võib loodud süsteemi toimimise käigus<br />
selguda, et süsteemi ei saa liigse keerukuse või ressursside va<strong>ja</strong>duse tõttu<br />
lisada uusi osi või viia sisse muudatusi – see tähendab, et süsteemi ei saa<br />
edasi arendada (Kuusik, 2000).<br />
Võimalikult hea allsüsteemideks <strong>ja</strong>otuse saamiseks tuleb seega järgida<br />
parimaid praktikad. Allsüsteemide leidmise <strong>ja</strong> kirjeldamise tulemuste<br />
hindamiseks on edukalt rakendatavad tarkvara disaini printsiibid (Larman,<br />
2002).<br />
Allsüsteemid ei tohiks olla liiga väikesed ega liiga suured. Näiteks registris<br />
hoitakse ühele põhiolemitüübile <strong>ja</strong> sellega seotud olemitüüpidele vastavaid<br />
andmeid. Probleem tekib muidugi sellega, mida lugeda põhiolemitüübiks. Kas<br />
kaupade register sisaldab kaubakategooriaid või tuleks eristada kaupade<br />
registrit <strong>ja</strong> kaubakategooriate registrit? Peenendamisega ei maksa liiale minna<br />
<strong>ja</strong> antud juhul piisaks ainult kaupade registrist. Kaubakategooria iseloomustab<br />
kaupa. Kui <strong>ja</strong>gaksime andmebaasi alamosadeks nii, et iga olemitüübi kohta<br />
leidub omaette register, siis kaotaks registriteks <strong>ja</strong>gamine oma mõtte.<br />
Allsüsteemid peaksid kõik olema suhteliselt ühesuguse suurusega. Näiteks<br />
kui ühe registri kirjeldamiseks tuleb kontseptuaalses andmemudelis esitada<br />
30 olemitüüpi <strong>ja</strong> teise kirjeldamiseks tuleb esitada 3 olemitüüpi, siis ei ole<br />
ilmselt tegu sarnaste suurustega.<br />
Allsüsteemi elementidel peab olema kõrge sisemine sidusus (inglise keeles<br />
high cohesion). See tähendab, et funktsionaalse allsüsteemi korral peavad<br />
pakutavad teenused olema tihedalt üksteisega seotud, "käima ühe as<strong>ja</strong><br />
kohta". Näiteks iga funktsionaalne allsüsteem võiks võimaldada hallata<br />
(lugeda, lisada, muuta <strong>ja</strong> kustutada) ühe registri andmeid.<br />
Allsüsteemi sõltuvus teistest allsüsteemidest peaks olema võimalikult väike<br />
(inglise keeles low coupling). Selle eelised on järgnevad.<br />
• Muutused teistes allsüsteemides mõjutavad allsüsteemi võimalikult vähe.<br />
• Spetsifikatsiooni on lihtsam taaskasutada.<br />
• Spetsifikatsioonist on lihtsam aru saada.<br />
20
TTÜ: Andmebaaside projekteerimine.<br />
Strateegiline analüüs <strong>ja</strong> detailanalüüs (2012)<br />
© Erki Eessaar<br />
4.5 Strateegilise analüüsi tulemust kirjeldava<br />
dokumentatsiooni struktuur<br />
Järgnevalt esitatakse lihtsustatud nimekiri strateegilise analüüsi<br />
tulemusel loodavatest dokumentidest.<br />
Strateegilise analüüsi projekti spetsifikatsioon (taust, eesmärgid,<br />
oodatavad tulemused)<br />
4.5.1 Süsteemi üldvaade<br />
• Organisatsiooni eesmärgid.<br />
• Infosüsteemi eesmärgid.<br />
• Lausendid.<br />
• Põhiobjektid.<br />
• Põhiprotsessid.<br />
• Põhilised sündmused.<br />
• Tegutse<strong>ja</strong>d.<br />
• Tükeldus allsüsteemideks:<br />
- Pädevusala allsüsteemide nimekiri. Selle saab leida tegutse<strong>ja</strong>te<br />
nimekir<strong>ja</strong> alusel.<br />
- Funktsionaalsed allsüsteemide nimekiri. Selle saab leida<br />
põhiprotsesside <strong>ja</strong> põhiobjektide nimekir<strong>ja</strong> alusel.<br />
- Registri allsüsteemide nimekiri. Selle saab leida põhiobjektide nimekir<strong>ja</strong><br />
alusel.<br />
4.5.2 Pädevusalade kirjeldused<br />
Iga pädevusala kohta koostatakse:<br />
• Eesmärgid.<br />
• Objektid, protsessid <strong>ja</strong> sündmused.<br />
• Nimekiri funktsionaalsetest allsüsteemidest, mida ta kasutab.<br />
• Nimekiri registritest, mida ta loeb <strong>ja</strong> haldab.<br />
• Kasutusjuhtude mudel. Kirjeldatakse konkreetselt selle ühe pädevusalaga<br />
seotud kasutusjuhud. Kasutusjuhtumeid võib lasta kirjeldada pädevusala<br />
enda esinda<strong>ja</strong>tel ning mudel on abiks funktsionaalsete allsüsteemide<br />
kasutusjuhtude leidmisel.<br />
• Domeenimudel. Pädevusala esinda<strong>ja</strong> töövaldkonda kirjeldavad olulised<br />
mõisted <strong>ja</strong> nende mõistete vahelised seosed.<br />
4.5.3 Funktsionaalsete allsüsteemide kirjeldused<br />
Iga funktsionaalse allsüsteemi kohta leitakse näiteks:<br />
• Eesmärgid.<br />
• Objektid, protsessid <strong>ja</strong> sündmused.<br />
21
TTÜ: Andmebaaside projekteerimine.<br />
Strateegiline analüüs <strong>ja</strong> detailanalüüs (2012)<br />
© Erki Eessaar<br />
• Nimekiri pädevusaladest, kes seda kasutavad.<br />
• Registrid, mida see funktsionaalne allsüsteem loeb <strong>ja</strong> haldab.<br />
• Funktsionaalse allsüsteemi põhiprotsesside kirjeldused<br />
tegevusdiagrammidena.<br />
• Andmebaasi kasutuse eskiismudel (kasutusjuhtude mudel: diagrammid +<br />
tekstilised kirjeldused). Kasutusjuhtude diagrammil näidatakse "kriipsumehikestena"<br />
süsteemi võimalikke kasuta<strong>ja</strong>id ehk tegutse<strong>ja</strong>id (mitte<br />
konkreetsed isikud, vaid pädevusalad), ning ovaalidena süsteemi<br />
kasutamise protsesse. Viimaseid saab tuletada süsteemi kasutust<br />
tingivatest sündmustest. Strateegilise analüüsi tulemusena pannakse<br />
enamike kasutusjuhtude tekstilised kirjeldused kir<strong>ja</strong> lühiformaadis (nimi,<br />
tegutse<strong>ja</strong>d, lühikirjeldus) ning kõige olulisemate kasutusjuhtude korral<br />
esitatakse tekstiline kirjeldus laiendatud formaadis. Laiendatud formaadis<br />
kasutusjuhu kirjeldus sisaldab järgmisi osi.<br />
- Kasutusjuhu nimi.<br />
- Tegutse<strong>ja</strong>d.<br />
- Kasutusjuhu täitmise tulemusel saavutatav eesmärk. Siin võib väl<strong>ja</strong><br />
tuua eesmärgid erinevate tegutse<strong>ja</strong>te <strong>ja</strong>oks.<br />
- Lühikirjeldus, mis võtab paari lausega kasutusjuhu kokku.<br />
- Kasutusjuhu käivitav sündmus.<br />
- Eeltingimused, mis peavad olema täidetud, et kasutusjuhu võiks<br />
käivitada.<br />
- Järeltingimused, mis peavad olema täidetud, et kasutusjuhu võiks<br />
kuulutada edukalt lõppenuks.<br />
- Tüüpiline sündmuste käik e. põhistsenaarium.<br />
- Alternatiivsed (mitte-tüüpilised) süsteemi kasutamise stsenaariumid<br />
ehk laiendused. Iga alternatiivse stsenaariumi juures peaks olema viide<br />
põhistsenaariumi sammule kust võib see alternatiivne stsenaarium<br />
alata. Stsenaariumid pannakse kir<strong>ja</strong> kasuta<strong>ja</strong> <strong>ja</strong> süsteemi vahelise<br />
dialoogina.<br />
• Domeenimudel, kus kirjeldatakse funktsionaalse allsüsteemi skoopi<br />
kuuluvad mõisted <strong>ja</strong> nendevahelised seosed. Kuna tegemist ei ole mitte<br />
andmemudeli vaid domeenimudeliga, siis on lubatud ka selliste<br />
mõistete/seoste esitamine, millele vastavaid andmeid ei ole va<strong>ja</strong><br />
andmebaasis hoida. Domeenimudel on aluseks kontseptuaalse<br />
andmemudeli koostamisele <strong>ja</strong> samuti objekt-orienteeritud tarkvara disaini<br />
<strong>ja</strong>oks kandidaatklasside valimisele.<br />
4.5.4 Registrite kirjeldused<br />
Kuidas kirjeldada strateegilise analüüsi dokumendis registreid? Iga registri<br />
kohta tuleks esitada:<br />
• Taust, kus selgitatakse vabas vormis, milliseid andmeid hoitakse<br />
registris ning milleks seda registrit va<strong>ja</strong> läheb. Taoline mitteformaalne<br />
kõrgtaseme kirjeldus võimaldab huvilisel (näiteks infosüsteemi va<strong>ja</strong>va<br />
organisatsiooni juhtkonna liikmel, kellel teadagi on alati liiga vähe aega)<br />
saada kiiresti registri olemusest ülevaade.<br />
• Eesmärgid, mida register aitab saavutada. Eesmärkide sõnastamisel<br />
tuleks pidada silmas, et eesmärgid peaksid olema mõõdetavad, st. peale<br />
22
TTÜ: Andmebaaside projekteerimine.<br />
Strateegiline analüüs <strong>ja</strong> detailanalüüs (2012)<br />
© Erki Eessaar<br />
registri realiseerimist peaks olema võimalik üheselt kindlaks teha kas<br />
eesmärk on täidetud või mitte (tõmmake näiteks paralleele poliitikute<br />
antavate lubadustega). Näide üldsõnalisest eesmärgist, mille täidetust on<br />
raske mõõta: Lihtsustada õpingukava registreerimist. Näide konkreetsest<br />
eesmärgist, mille täidetust on võimalik mõõta: Võimaldada registreerida<br />
kõiki sündmuseid (sündmuse toimumise aeg, sündmuse põhjustanud<br />
subjekt, seisund, millesse õpingukava läks sündmuse tulemusena), mis<br />
põhjustavad õpingukava seisundi muutumist.<br />
• Pädevusalad mille esinda<strong>ja</strong>d pöörduvad (funktsionaalsete<br />
allsüsteemide kaudu) registri poole. Tuleb määrata kindlaks pädevusalad,<br />
mille esinda<strong>ja</strong>d haldavad seda registrit, st.<br />
loevad/lisavad/muudavad/kustutavad selles registris olevaid andmeid.<br />
Samuti tuleb määrata kindlaks pädevusalad, mille esinda<strong>ja</strong>d ainult loevad<br />
selles registris olevaid andmeid.<br />
• Funktsionaalsed allsüsteemid mis pöörduvad registri poole. Tuleb<br />
määrata kindlaks, milliste funktsionaalsete allsüsteemide kaudu toimub<br />
selle registri andmete haldamine (lugemine/ lisamine/ muutmine/<br />
kustutamine). Samuti tuleb määrata kindlaks, millised funktsionaalsed<br />
allsüsteemid ainult loevad selles registris olevaid andmeid. Registrite<br />
seosed pädevusalade <strong>ja</strong> funktsionaalsete allsüsteemidega võib esitada<br />
kasutades risttabeleid<br />
• Infova<strong>ja</strong>dused, mida registri poolt esitatav andmebaasi alamosa aitab<br />
rahuldada. Infova<strong>ja</strong>dused on päringud millele andmebaasi põh<strong>ja</strong>l<br />
soovitakse vastust.<br />
• Seosed teiste registritega. Tuleb kirjeldada milliste teiste sama<br />
süsteemi registritega on vaadeldaval registril ühiseid olemitüüpe. Samuti<br />
tuleb teha kindlaks milliste teiste süsteemide registritega on sellel registril<br />
ühiseid olemitüüpe või toimub andmevahetus. Näiteks Joonis 3 põh<strong>ja</strong>l on<br />
ülikooli infosüsteemis õpingukavade register <strong>ja</strong> tööta<strong>ja</strong>te register seotud<br />
õpingukava sündmuse kaudu. Iga õpingukava kohta tuleb registreerida<br />
sellega toimunud sündmused (loomine, esitamine, kinnitamine jne),<br />
sealhulgas ka andmed sündmuse põhjusta<strong>ja</strong> kohta. Registrite<br />
projekteerimise käigus tuleb otsustada kas õpingukava sündmuse<br />
andmed kuuluvad tööta<strong>ja</strong>te registrisse, õpingukavade registrisse või<br />
moodustavad hoopis omaette registri.<br />
Tööta<strong>ja</strong><br />
kes<br />
põhjustas<br />
Õpingukava<br />
sündmus<br />
Õpingukava<br />
Tööta<strong>ja</strong>te<br />
register<br />
Õpingukavade<br />
register<br />
Joonis 3 Registrite omavahelise seose näide.<br />
23
TTÜ: Andmebaaside projekteerimine.<br />
Strateegiline analüüs <strong>ja</strong> detailanalüüs (2012)<br />
© Erki Eessaar<br />
• Kontseptuaalse andmemudeli eskiis, millel esitatakse kõige olulisemad<br />
olemitüübid <strong>ja</strong> seosetüübid. Eskiismudelis joonistatakse olemitüüpidele<br />
vastavad "kastid" ning nende olulistele seostele vastavad "kriipsud".<br />
Muude detailide (nagu olemitüüpide atribuudid, seosetüüpide omadused)<br />
valikuline ka<strong>ja</strong>stamine eskiismudelis on sageli kasulik, kuid omab<br />
paratamatult juhuslikku iseloomu ning pole seepärast kohustuslik.<br />
Strateegilise analüüsi käigus ei jää aega et allsüsteeme detailselt<br />
modelleerida ning see ei ole ka strateegilise analüüsi eesmärk.<br />
Kontseptuaalse andmemudeli koostamine viiakse lõpule detailanalüüsi<br />
käigus.<br />
Allsüsteemide leidmine võimaldab süsteemi paremini <strong>ja</strong> ülevaatlikumalt<br />
kirjeldada. Evitts (2000) märgib, et ülevaatlikul diagrammil võiks olla 7+/-2<br />
omavahel loogiliselt seotud elementi. Näiteks registrite leidmine annab<br />
võimaluse koostada ülevaatlikud olemi-suhte diagrammid. Selle asemel,<br />
et koostada andmebaasi kui terviku kohta üks suur diagramm kus on<br />
kümneid või sadu elemente, saame iga registri kohta koostada üks või<br />
mitu eraldi diagrammi, mis rahuldavad Evitts (2000) esitatud nõudeid.<br />
4.5.5 Muud dokumendid<br />
Allsüsteemide vahelised seoste paremaks esitamiseks võib kasutada<br />
risttabeleid (vt. Tabel 4 – Tabel 6) või UMLi paketidiagramme.<br />
Tabel 4 Pädevusalade <strong>ja</strong> funktsionaalsete allsüsteemide vastavustabeli näide.<br />
Õppeainete<br />
arvestus<br />
Õpingukava<br />
de arvestus<br />
Üliõpilaste<br />
arvestus<br />
Üliõpilase pädevusala Õppejõu Dekanaadi sekretäri<br />
pädevusala pädevusala<br />
X X X<br />
X X X<br />
X X X<br />
X Tabel 4 lahtris näitab, et pädevusala kasutab selle funktsionaalse<br />
allsüsteemi teenuseid.<br />
Tabel 5 Pädevusalade <strong>ja</strong> registrite vastavustabeli näide.<br />
Õppeainete<br />
register<br />
Õpingukava<br />
de register<br />
Üliõpilaste<br />
register<br />
Üliõpilase pädevusala Õppejõu Dekanaadi sekretäri<br />
pädevusala pädevusala<br />
R R R<br />
CRUD RU R<br />
R R RU<br />
Mida tähendavad tähed Tabel 5 lahtrites?<br />
• C (Create, loo) – pädevusala esinda<strong>ja</strong>d lisavad registrisse andmeid.<br />
• R (Read, loe) – pädevusala esinda<strong>ja</strong>d loevad registrist andmeid.<br />
• U (Update, muuda) – pädevusala esinda<strong>ja</strong>d muudavad registris<br />
andmeid.<br />
24
TTÜ: Andmebaaside projekteerimine.<br />
Strateegiline analüüs <strong>ja</strong> detailanalüüs (2012)<br />
© Erki Eessaar<br />
• D (Delete, kustuta) – pädevusala esinda<strong>ja</strong>d kustutatavad registrist<br />
andmeid.<br />
Tabel 6 Funktsionaalsete allsüsteemide <strong>ja</strong> registrite vastavustabeli näide.<br />
Õppeainete<br />
register<br />
Õpingukava<br />
de register<br />
Üliõpilaste<br />
register<br />
Õppeainete arvestus Õpingukavade Üliõpilaste<br />
arvestus arvestus<br />
CRUD R R<br />
CRUD<br />
RU<br />
R<br />
CRUD<br />
Mida tähendavad tähed Tabel 6 lahtrites?<br />
• C (Create, loo) – funktsionaalne allsüsteemi kaudu lisatakse registrisse<br />
andmeid.<br />
• R (Read, loe) – funktsionaalne allsüsteemi kaudu loetakse registrist<br />
andmeid.<br />
• U (Update, muuda) – funktsionaalne allsüsteemi kaudu muudetakse<br />
registris andmeid.<br />
• D (Delete, kustuta) – funktsionaalne allsüsteemi kaudu kustutatakse<br />
registrist andmeid.<br />
Tabel 5 <strong>ja</strong> Tabel 6 on CRUD maatriksi erijuhud (vt <strong>ja</strong>otis 5.4). Allsüsteemide<br />
vaheliste seoste esitamiseks võib kasutada ka paketidiagramme ehk<br />
paketiskeeme, kus näidatakse pakette <strong>ja</strong> nende sõltuvusi (vt. Joonis 4).<br />
Joonis 4 Allsüsteemide vaheliste seoste kujutamine klassidiagrammil.<br />
UMLis on võimalik pakettide abil grupeerida suvalisi UMLi elemente kokku<br />
üldisemateks üksusteks (Fowler, 2007). Paketti tähistab diagrammil sakiga<br />
kaust. Paketi nimeks on allsüsteemi nimi. Stereotüüp viitab,<br />
25
TTÜ: Andmebaaside projekteerimine.<br />
Strateegiline analüüs <strong>ja</strong> detailanalüüs (2012)<br />
© Erki Eessaar<br />
et pakett tähistab allsüsteemi. Paketid võivad kuuluda teistesse pakettidesse,<br />
moodustades hierarhilise struktuuri. Näiteks Joonis 4 näitab paketil esitatud<br />
fraas "from Pädevusalad", et see pakett kuulub paketti Pädevusalad.<br />
Lisaks tuleb strateegilise analüüsi käigus koostada arhitektuuri <strong>ja</strong><br />
arendusvaade. Nende alamdokumentide struktuuri antud kursuses ei esitata.<br />
Arhitektuurivaade. Kirjeldatakse allsüsteemide paigutus erinevates<br />
asukohtades <strong>ja</strong> tehniline arhitektuur – tarkvara, riistvara, arvutivõrgud.<br />
Arendusvaade. Kirjeldatakse süsteemi loomiseks käivitatavad projektid,<br />
nende a<strong>ja</strong>line järjekord <strong>ja</strong> prioriteedid. Kirjeldatakse kasutatav<br />
projektorganisatsioon. Kirjeldatakse võimalikud arendamisega seotud riskid.<br />
Antakse esialgne hinnang arendamise maksumusele.<br />
4.6 Projekti planeerimine<br />
Projekt on Mikli (1999) põh<strong>ja</strong>l "kindla a<strong>ja</strong>vahemiku <strong>ja</strong> finantsidega ning<br />
formuleeritud eesmärkidega ellu viidav muudatus või arendamine." Projekti<br />
omadused:<br />
• toimub mingi a<strong>ja</strong>perioodi jooksul;<br />
• hõlmab palju töid, mida tehakse erinevate projekti osaliste poolt;<br />
• tööd selles on organiseeritud, mitte ei toimu kaootiliselt;<br />
• on mõeldud eesmärgi saavutamiseks;<br />
• kasutab meeskonnatööd.<br />
Strateegilise analüüsi üheks ülesandeks on süsteemi arendamise strateegia<br />
loomine, milles määratletakse süsteemi arendamiseks algatatavad projektid,<br />
nende prioriteedid, ressursiva<strong>ja</strong>dused, riskid <strong>ja</strong> projektorganisatsioon.<br />
Mikli (1999) põh<strong>ja</strong>l on suurte projektide süsteemiarenduses kasutamisel<br />
üldjuhul viga selles, et arvutisüsteemi ei õnnestu kohe rakendada. See võib<br />
olla tingitud infosüsteemi va<strong>ja</strong>va organisatsiooni vähesest valmisolekust või<br />
tulevaste kasuta<strong>ja</strong>te oskamatusest. Mitme projektiga arendamisel on aga<br />
probleemiks, kuidas <strong>ja</strong>otada süsteemi arendamine osadeks – projektideks?<br />
Projektide leidmine ongi strateegilise analüüsi üheks eesmärgiks.<br />
Kui süsteemiarendus toimub kose mudeli alusel, siis strateegilisele analüüsile<br />
(vt. Joonis 1) järgneb kõikide allsüsteemide detailanalüüs, disain, ehitamine,<br />
rakendamine <strong>ja</strong> hooldamine. Kuid kuidas kasutada süsteemi arendamiseks<br />
üheskoos strateegilist analüüsi <strong>ja</strong> iteratiivsel mudelil põhinevat<br />
süsteemiarendust? Strateegilise analüüsi arendusvaates planeeritakse<br />
projektid infosüsteemi valmis tegemiseks. Üks projekt hõlmab ühe või mitme<br />
allsüsteemi analüüsi/disaini/ehitamist/rakendamist. Iga projekt võib omakorda<br />
koosneda lühikestest (2–6) nädalat iteratsioonidest, mille käigus<br />
projekteeritakse, ehitatakse <strong>ja</strong> rakendatakse mingi allsüsteemi osa. Lisaks<br />
võib olla va<strong>ja</strong> käivitada koolituse või andmete kvaliteedi parandamise projekte,<br />
et uuele süsteemile saaks üle minna.<br />
26
TTÜ: Andmebaaside projekteerimine.<br />
Strateegiline analüüs <strong>ja</strong> detailanalüüs (2012)<br />
© Erki Eessaar<br />
süsteemi<br />
funktsionaalsus<br />
Allsüsteemide<br />
arendusprojekt<br />
Allsüsteemide<br />
arendusprojekt<br />
Strateegiline<br />
analüüs<br />
aeg<br />
Joonis 5 Süsteemiarendus mitme projektiga.<br />
Strateegilise analüüsi käigus tuleks määrata kindlaks ka projektide<br />
prioriteedid. Hoberman (2001) kirjeldab prioriteetide kolmnurka, mille abil<br />
saab määrata arendusprojekti üldisi eesmärke.<br />
Projekti tulemus on<br />
kõrge kvaliteediga<br />
Projektile kulub<br />
vähe aega<br />
Joonis 6 Projekti prioriteetide kolmnurk.<br />
Projekti kulud<br />
on väikesed<br />
Ideaalne oleks saavutada kõik kolm prioriteetide kolmnurgas esitatud<br />
eesmärki. Kuid see on võimatu ning maksimaalselt on võimalik saavutada<br />
kaks eemärki kolmest.<br />
• Kõrge kvaliteediga tulemus saavutataks minimaalse a<strong>ja</strong>ga. Sobilik<br />
projektide <strong>ja</strong>oks, mille tulemus on ülioluline – näiteks teisi projekte ei saa<br />
alustada enne, kui see on lõppenud. Sellise projekti läbiviimiseks on<br />
va<strong>ja</strong>likud kõrgetasemelised täit<strong>ja</strong>d ning suurepärane töökeskkond, ning<br />
see suurendab projekti läbiviimiseks va<strong>ja</strong>likke kulusid.<br />
• Kõrge kvaliteediga tulemus saavutatakse minimaalse hinnaga. Sobilik<br />
projektide <strong>ja</strong>oks, kus on võimalik võtta arendamist rahulikult <strong>ja</strong> veenduda<br />
igal sammul, et ei kulutata liigseid ressursse.<br />
• Minimaalse hinnaga tulemus saavutatakse minimaalse a<strong>ja</strong>ga. Sobib<br />
prototüübi koostamise projektide <strong>ja</strong>oks, kus tuleb kiiresti teha valmis<br />
27
TTÜ: Andmebaaside projekteerimine.<br />
Strateegiline analüüs <strong>ja</strong> detailanalüüs (2012)<br />
© Erki Eessaar<br />
esialgne lahendus, millele kasuta<strong>ja</strong>d saavad hakata andma oma<br />
hinnanguid. Seda kasutatakse näiteks kasuta<strong>ja</strong>te käest<br />
tarkvarasüsteemile esitatavate nõuete kogumiseks.<br />
5. Detailanalüüs<br />
Detailanalüüsi eesmärkideks on:<br />
• strateegilise analüüsi tulemustena saadud allsüsteemide täpsem analüüs<br />
<strong>ja</strong> modelleerimine;<br />
• disaini ettevalmistamine;<br />
Detailanalüüsi käigus toimub valitud allsüsteemi(de) detailne<br />
toimimistasemeline (see tähendab sisuline, tehnilisest lahendustest<br />
sõltumatu) modelleerimine. Koostöös telli<strong>ja</strong> ning tulevaste kasuta<strong>ja</strong>tega<br />
täpsustatakse strateegilise analüüsi käigus koostatud eskiismudeleid kõigi<br />
toimimistasemel va<strong>ja</strong>like detailide kättesaamiseni.<br />
Kui ollakse aru saanud äriva<strong>ja</strong>dustest, on kasulik otsida turult mudeleid, valida<br />
sobiv ning kohandada oma organisatsioonile. See tähendab mustrite <strong>ja</strong><br />
universaalsete mudelite kasutamist <strong>ja</strong> sellest tuleb juttu teemas nr. 8.<br />
5.1 Pädevusalade allsüsteemide kirjeldused<br />
Kirjelduse alguses on tausta, eesmärkide ning allsüsteemi seoste täpsustatud<br />
kirjeldus.<br />
5.1.1 Objektivaade<br />
Pädevusala infova<strong>ja</strong>dusi kirjeldav domeenimudel, kus on näidatud kontseptid,<br />
atribuudid, seosed.<br />
5.1.2 Protsessivaade<br />
Pädevusala tööprotsesside kirjeldus, mis on esitatud kasutusjuhtude<br />
diagrammidena. Nendel on väl<strong>ja</strong> toodud kõik kasutusjuhud, milles antud<br />
pädevusala liige osaleb.<br />
5.1.3 Sündmusvaade<br />
Pädevusala kasutusjuhtude tekstilised kirjeldused laiendatud formaadis (vt.<br />
funktsionaalse allsüsteemi kasutusjuhtude kirjeldusi).<br />
28
TTÜ: Andmebaaside projekteerimine.<br />
Strateegiline analüüs <strong>ja</strong> detailanalüüs (2012)<br />
5.2 Funktsionaalsete allsüsteemide kirjeldused<br />
© Erki Eessaar<br />
Kirjelduse alguses on tausta, eesmärkide ning allsüsteemi seoste täpsustatud<br />
kirjeldus.<br />
5.2.1 Objektivaade<br />
Allsüsteemi kirjeldav domeenimudel.<br />
5.2.2 Protsessivaade<br />
Allsüsteemi põhiprotsessid kasutusjuhtude diagrammidena.<br />
5.2.3 Sündmusvaade<br />
Tuleb täpsustada strateegilise analüüsi käigus leitud kasutusjuhtude kirjeldusi<br />
ning va<strong>ja</strong>dusel lisada juurde uusi kasutusjuhte. Kõik kasutusjuhud tuleks<br />
kirjutada lahti laiendatud formaadis. Kasutusjuhtude tekstikirjelduste<br />
muutmisel ei tohi unustada teha vastavaid muudatusi kasutusjuhtude<br />
diagrammides.<br />
Laiendatud formaadis kasutusjuhu kirjelduses sisalduvad stsenaariumid<br />
kirjeldavad seansisiseseid sündmuseid. Detailanalüüsi tulemusena<br />
selgitatakse väl<strong>ja</strong> taolistele sündmustele reageerimiseks va<strong>ja</strong>likud<br />
andmebaasioperatsioonid. Andmebaasioperatsioonid kirjeldatakse registrite<br />
vaates lepingute abil. Stsenaariumitesse tuleb lisada viited<br />
andmebaasioperatsioonide lepingutele.<br />
5.3 Registrite kirjeldused<br />
Kirjelduse alguses on tausta, eesmärkide ning allsüsteemi seoste täpsustatud<br />
kirjeldus.<br />
5.3.1 Objektivaade<br />
Objektivaates esitatakse täpsustatud kontseptuaalne andmemudel.<br />
Kontseptuaalse andmemudeli võimalikud koostisosad:<br />
• Olemi-suhte diagrammid (Siin tuleb näidata ka kõigi seoste nimed).<br />
• Olemitüüpide definitsioonide tabel (olemitüübi nimi (ka aliased kui neid<br />
on), register kuhu olemitüüp kuulub, DEFINITSIOON).<br />
• Atribuutide definitsioonide tabel (olemitüübi nimi, atribuudi nimi (ka aliased<br />
kui neid on), kirjeldus, näidisväärtused). Võib dokumenteerida ka:<br />
üldine andmetüüp <strong>ja</strong> pikkus<br />
- liht- või liitatribuut?<br />
29
TTÜ: Andmebaaside projekteerimine.<br />
Strateegiline analüüs <strong>ja</strong> detailanalüüs (2012)<br />
© Erki Eessaar<br />
- ühe- või mitmeväärtuseline atribuut?<br />
- tuletatud atribuut? Kui <strong>ja</strong>h, siis ka tuletusreeglid.<br />
- vaikimisi väärtus.<br />
• Seosetüüpide definitsioonid:<br />
- seosetüübis osalevad olemitüübid,<br />
- seosetüübi võimsus,<br />
- seosetüübis osalevate olemitüüpide osaluskohustus.<br />
5.3.2 Protsessivaade<br />
Detailanalüüsi tulemusena tuleb kirjeldada kasutusjuhtude mudeli koostamise<br />
käigus leitud andmebaasioperatsioone. Andmebaasioperatsioonide<br />
kirjeldamiseks võib kasutada lepingu formaati. Lepingud tuleks kirjutada kõige<br />
olulisemate <strong>ja</strong> keerulisemate operatsioonide kohta.<br />
Miks öeldakse, et operatsioon kirjeldatakse lepingu formaadis? Leping<br />
sätestab lepingu sõlminud osapoolte õigused <strong>ja</strong> kohustused.<br />
Operatsiooni kirjelduses vaadeldakse süsteemi kui musta kasti ning ei<br />
selgitata kuidas operatsiooni läbi viia (selle otsustamine on disaini ülesanne).<br />
Operatsiooni eeltingimused deklareerivad süsteemipoolseid kohustusi. See<br />
tähendab, et süsteem peab operatsiooni õnnestumiseks tagama, et<br />
eeltingimused on täidetud.<br />
Operatsiooni järeltingimused deklareerivad operatsioonipoolseid kohustusi.<br />
See tähendab, et kui süsteem täidab talle pandud kohustused, siis<br />
vastutasuks võib ta oodata, et operatsioon täidab omakorda talle pandud<br />
kohustused <strong>ja</strong> viib andmebaasis läbi järeltingimustes näidatud muudatused.<br />
Iga lepingu spetsifikatsioon sisaldab järgnevaid osi:<br />
• Operatsiooni nimetus parameetritega.<br />
• Eeltingimused. Kirjeldavad, millised andmed olemite <strong>ja</strong> seoste kohta<br />
peavad olema lisatud, muudetud või kustutatud, et operatsiooni saaks<br />
alustada.<br />
• Järeltingimused. Kirjeldavad, millised andmed olemite <strong>ja</strong> seoste kohta<br />
peavad olema lisatud, muudetud või kustutatud, et operatsiooni võiks<br />
edukalt lõpetada. Larman (2002) toob näite teatri põh<strong>ja</strong>l. Kujutlege, et<br />
viibite teatris <strong>ja</strong> jälgite laval toimuvat. Enne operatsiooni algust heidate<br />
pilgu lavale <strong>ja</strong> jätate meelde kuidas rekvisiidid <strong>ja</strong> näitle<strong>ja</strong>d on lavale<br />
paigutatud. Operatsiooni a<strong>ja</strong>l langeb lava ette eesriie, mis operatsiooni<br />
lõppedes uuesti üles tõstetakse. Nüüd on teie ülesanne kir<strong>ja</strong> panna, mis<br />
on rekvisiitide <strong>ja</strong> näitle<strong>ja</strong>te osas laval operatsiooni käigus muutunud<br />
(kes/mis on juurde tulnud, ümberpaigutatud või lavalt kadunud).<br />
• Kasutus kasutusjuhtude poolt. Viited kasutusjuhtudele, mis antud<br />
operatsiooni kasutavad <strong>ja</strong> funktsionaalsetele allsüsteemidele, mida<br />
nimetatud kasutusjuhud kirjeldavad.<br />
Järgnevalt esitame näitena andmebaasioperatsiooni lepingu nimega<br />
Õpingukava loomine. Lepingu spetsifikatsioonis on kursiivis esitatud<br />
30
TTÜ: Andmebaaside projekteerimine.<br />
Strateegiline analüüs <strong>ja</strong> detailanalüüs (2012)<br />
© Erki Eessaar<br />
kontseptuaalses andmemudelis kirjeldatud olemitüüpide nimed. Lepingu nime<br />
järel on sulgudes näidatud lepingu parameetrid. Näiteks operatsiooni poole<br />
pöördumisel peab parameetri üliõpilaneID väärtuseks olema üliõpilase<br />
unikaalne identifikaator.<br />
Õpingukava loomine (üliõpilaneID, semesterID, tüüpõpingukavaID)<br />
Eeltingimused:<br />
o Üliõpilane, Semester, Tüüpõpingukava <strong>ja</strong> Õpingukava_seisundi_liik on<br />
registreeritud.<br />
Järeltingimused:<br />
o On loodud Õpingukava.<br />
o Õpingukava on seotud Tüüpõpingukavaga, mille alusel õpingukava<br />
koostatakse.<br />
o Õpingukava on seotud Üliõpilasega, kes seda õpingukava koostab.<br />
o Õpingukava on seotud Semestriga, millal see õpingukava kehtib.<br />
o Õpingukava on seotud Õpingukava_seisundi_liigiga, mille puhul<br />
Õpingukava_seisundi_liik.nimetus="koostamisel".<br />
Millised on mõned olulised punktid, millele lepingu kirjutamisel tähelepanu<br />
pöörata?<br />
• Andmebaasioperatsioonide identifikaatorid peavad olema lisatud<br />
kasutusjuhu laiendatud formaadis tekstilisse kirjeldusse. Lisaks<br />
operatsiooni sisu selgitavale nimele (nt Õpingukava koostamine) võib<br />
operatsiooni identifitseerimiseks võtta kasutusele mõne lühema<br />
identifikaatori (nt OP1), mida on mugavam kasutusjuhtude tekstikirjelduses<br />
kasutada.<br />
• Lepingu järeltingimuses peab olema näidatud ka seoste<br />
tekkimine/kadumine<br />
• Eel- <strong>ja</strong> järeltingimustes peab kasutama sama terminoloogiat kui<br />
kontseptuaalses andmemudelis.<br />
• Lepingu järeltingimustes ei tule kirjeldada muutusi väl<strong>ja</strong>spool andmebaasi –<br />
nt. muudatus kasuta<strong>ja</strong>liideses.<br />
• Andmebaasioperatsioonide lepingute järeltingimustes tuleb kirjeldada ainult<br />
seda, mis andmebaasis operatsiooni tulemusel muutus. Seda mis jäi<br />
samaks ei ole va<strong>ja</strong> kir<strong>ja</strong> panna!<br />
• Iga seisundidiagrammil esitatud seisundi ülemineku kohta peab leiduma<br />
andmebaasioperatsioon, mille tulemusena tehakse andmebaasis<br />
muudatus, et seda seisundimuudatust registreerida.<br />
Andmebaasioperatsioonide kogumist võib mõelda kui liidesest, mille kaudu<br />
funktsionaalne allsüsteem kasutab registri allsüsteemi poolt pakutavaid<br />
teenuseid.<br />
Andmebaasioperatsioonid kapseldavad andmebaasi. Kapseldamine on<br />
objekt-orienteeritud disainist tuntud mõiste <strong>ja</strong> tähendab, et elemendi sisemist<br />
struktuuri peidetakse <strong>ja</strong> elementi saab kasutada ainult avaliku liidese kaudu.<br />
Kuidas liidese pakutavad teenused on realiseeritud pole teenuse kasuta<strong>ja</strong> asi.<br />
Teisisõnu aitab kapseldamine peita ebaolulist informatsiooni teiste elementide<br />
eest. Kapseldamine võimaldab teenuse pakkumise mehhanismi muuta, jättes<br />
samal a<strong>ja</strong>l avaliku liidese muutmata. Antud juhul on kapseldatavaks<br />
31
TTÜ: Andmebaaside projekteerimine.<br />
Strateegiline analüüs <strong>ja</strong> detailanalüüs (2012)<br />
© Erki Eessaar<br />
elemendiks andmebaas. Andmebaasioperatsioonide lepingud defineerivad<br />
andmebaasi kasutamiseks mõeldud liidese.<br />
Näiteks SQL andmebaasis võib operatsioonid realiseerida<br />
andmebaasiserveris talletatud rutiinidena või vaadetena, mida kasutavad kõik<br />
andmebaasi poole pöörduvad programmid. Rutiinid <strong>ja</strong> vaated on andmebaasi<br />
programmeeri<strong>ja</strong> kontrolli all <strong>ja</strong> neid saab va<strong>ja</strong>dusel muuta nii (näiteks<br />
optimeerida SQL lauseid), et kasuta<strong>ja</strong> ei pea kuidagi muutma rutiini/vaate<br />
poole pöördumist.<br />
5.3.3 Sündmusvaade<br />
Koostatakse registri põhiolemitüübi seisundidiagramm e. olekumasinaskeem,<br />
mis kirjeldab kõikvõimalikud seisundid, milles sellesse olemitüüpi kuuluvad<br />
olemid võivad viibida ning lubatud siirdeid e. üleminekuid ühest seisundist<br />
teise. Iga siire on põhjustatud mingi sündmuse poolt. Seisundidiagrammi<br />
kohta lugege täpsemalt M. Fowlery raamatu (Fowler, 2007) peatükist nr. 10.<br />
Seisundidiagramm peab vastama järgmistele reeglitele.<br />
• Täpselt üks algne pseudoseisund<br />
• Üks või mitu lõppseisundit.<br />
• Seisunditel on nimed. Mõnikord jäetakse küll algsele pseudoseisundile nimi<br />
andmata.<br />
• Igale seisundi üleminekule on kirjutatud sündmus, mis seda põhjustab.<br />
• Algsest pseudoseisundist saab seisundi üleminekute kaudu mistahes teise<br />
seisundisse.<br />
• Nõue andmebaasile: andmebaasis tehtud päringuga saab kindlaks teha<br />
olemi seisundi käesoleval a<strong>ja</strong>hetkel.<br />
Järgnevalt esitatav olemi-suhte diagrammi fragment demonstreerib sellist<br />
andmebaasi struktuuri mis võimaldab registreerida andmeid nii objekti<br />
hetkeseisundi, kui ka selle seisundi muudatuste kohta.<br />
32
TTÜ: Andmebaaside projekteerimine.<br />
Strateegiline analüüs <strong>ja</strong> detailanalüüs (2012)<br />
© Erki Eessaar<br />
Joonis 7 Olemi-suhte diagramm seisundi a<strong>ja</strong>loo registreerimise kohta.<br />
5.4 CRUD maatriks<br />
Erinevat tüüpi mudelid esitavad erinevaid vaateid süsteemile. Mudelid peavad<br />
olema omavahel kooskõlas, et anda süsteemist korrektne ülevaade ning<br />
võimaldada luua korrektne süsteemi realisatsioon.<br />
Andmevaadet <strong>ja</strong> protsessivaadet esitavate mudelite omavahelise kooskõla<br />
kontrollimiseks võib kasutada CRUD maatriksit. Maatriksi nimi on akronüüm,<br />
mis tuleneb sõnadest "Create", "Read", "Update", "Delete". (Loo, Loe,<br />
Muuda, Kustuta). Akronüüm on mitme sõna algustähtedest moodustatud<br />
lühinimetus. Eeldame, et andmevaate esitamiseks kasutatav kontseptuaalne<br />
andmemudel sisaldab olemi-suhte diagramme <strong>ja</strong> protsessivaate<br />
kirjeldamiseks kasutatakse kasutusjuhtude mudelit. Sellisel juhul peab iga<br />
atribuudi/seosetüübi kohta leiduma kasutusjuht, kus:<br />
• ... on kirjeldatud toiming, mille käigus atribuut väärtustatakse/seos<br />
tekitatakse (Create).<br />
• ... on kirjeldatud toiming, mille käigus atribuudi väärtust/seost loetakse<br />
(Read).<br />
Näiteks, kui andmeid ainult luuakse, kuid ühegi kasutusjuhu käigus ei loeta,<br />
siis tekib küsimus, miks on va<strong>ja</strong> koguda andmeid mida keegi ei kasuta. Kui<br />
leidub kasutusjuht, mille käigus andmeid loetakse, kuid ühegi kasutusjuhu<br />
käigus neid andmeid ei looda, siis on selge, et süsteemi kirjeldus ei ole täielik.<br />
Lisaks võib leiduda kasutusjuht, kus:<br />
• ... on kirjeldatud toiming, mille käigus atribuudi väärtust/seost<br />
muudetakse (Update).<br />
33
TTÜ: Andmebaaside projekteerimine.<br />
Strateegiline analüüs <strong>ja</strong> detailanalüüs (2012)<br />
© Erki Eessaar<br />
• ... on kirjeldatud toiming, mille käigus atribuudi väärtus/seos<br />
kustutatakse (Delete).<br />
Kustutada tuleb andmed, mille kustutamist nõuab seadus, määrus või<br />
organisatsioonisisene praktika. Andmete kustutamist võib olla va<strong>ja</strong><br />
sisestusvigade parandamiseks. Andmete kustutamist tuleb alati põh<strong>ja</strong>likult<br />
kaaluda, sest kustutatud andmeid võib tulevikus näiteks analüüsimise<br />
otstarbel va<strong>ja</strong> minna. Infosüsteemi võib luua nii, et enne operatiivandmete<br />
andmebaasist kustutamist laaditakse andmed andmeaita või andmevakka, et<br />
neid oleks võimalik hiljem analüüside läbiviimiseks kasutada.<br />
On võimalik, et isegi kui kasuta<strong>ja</strong>liideses jäetakse kasuta<strong>ja</strong>le mulje, et ta andis<br />
kustutamise korralduse, siis tegelikult muudetakse kustutatava andmeobjekti<br />
seisundit <strong>ja</strong> see säilib andmebaasis. Kasuta<strong>ja</strong> neid andmeid enam ei näe.<br />
CRUD maatriksi võib luua erineva täpsusega.<br />
• Andmevaate võib maatriksis esitada näiteks registri, olemitüübi või<br />
atribuudi/seosetüübi täpsusega. Järgnevalt tuuakse näide olemitüübi<br />
täpsusega maatriksist.<br />
• Protsessivaate võib esitada näiteks funktsionaalse allsüsteemi,<br />
kasutusjuhu või toimingu täpsusega. Järgnevalt tuuakse näide<br />
kasutusjuhu täpsusega maatriksist.<br />
Näide:<br />
Kasutusjuhud (protsessivaade)<br />
Luge<strong>ja</strong>ks<br />
saamine<br />
Trükise<br />
laenutamine<br />
Trükise<br />
tagastamine<br />
Luge<strong>ja</strong>ks oleku<br />
lõpetamine<br />
Trükis R, U R, U<br />
Luge<strong>ja</strong> C R R R, U<br />
Laenutamine C R, U R<br />
Olemitüübid<br />
(andmevaade)<br />
Joonis 8 CRUD maatriksi näide.<br />
• Luge<strong>ja</strong>ks saamise käigus registreeritakse andmebaasis uus luge<strong>ja</strong><br />
(CREATE).<br />
• Trükise laenutamise käigus loetakse (READ) trükise <strong>ja</strong> luge<strong>ja</strong> andmed.<br />
Seejärel registreeritakse andmebaasis uus laenutamine (CREATE).<br />
Lõpuks muudetakse trükise seisundit (UPDATE), näitamaks selle<br />
väl<strong>ja</strong>laenutamist.<br />
• Trükise tagastamise käigus loetakse (READ) kontrolli eesmärgil trükise,<br />
luge<strong>ja</strong> <strong>ja</strong> laenutamise andmed. Registreeritakse laenutamise tegelik<br />
34
TTÜ: Andmebaaside projekteerimine.<br />
Strateegiline analüüs <strong>ja</strong> detailanalüüs (2012)<br />
© Erki Eessaar<br />
lõppemise aeg (UPDATE). Lõpuks muudetakse trükise seisundit<br />
(UPDATE) näitamaks, et trükist saab uuesti laenutada.<br />
• Luge<strong>ja</strong>ks oleku lõpetamise korral loetakse (READ) laenutamise andmeid,<br />
et teha kindlaks, ega ei ole veel lõppemata laenutusi. Seejärel loetakse<br />
luge<strong>ja</strong> andmed ning muudetakse luge<strong>ja</strong> seisundid (seisund:="arhiveeritud")<br />
(UPDATE).<br />
35
TTÜ: Andmebaaside projekteerimine.<br />
Strateegiline analüüs <strong>ja</strong> detailanalüüs (2012)<br />
© Erki Eessaar<br />
6. Tootmisettevõtte näide<br />
Tabel 7 Tootmisettevõtte IS üldvaate fragment.<br />
Põhiobjektid<br />
• Tellimus<br />
• Toote kavand<br />
• Plaan toote loomiseks<br />
• Töövahendi kavand<br />
• Töövahend<br />
• Mater<strong>ja</strong>l<br />
• Toode<br />
• Saadetis<br />
• Klient<br />
• Tööta<strong>ja</strong><br />
Põhilised sündmused<br />
• Klient esitab palve toote ostuks<br />
• Tellimus kiidetakse heaks<br />
• Tellimus lükatakse tagasi<br />
• Tegemist on uudse tootega<br />
• Laoseisu kontroll näitab, et laos on<br />
piisavalt toodet, et tellimust rahuldada<br />
• Laoseisu kontroll näitab, et laos pole<br />
piisavalt toodet, et tellimust rahuldada<br />
• Projekteeri<strong>ja</strong> lõpetab toote disaini<br />
• Toot<strong>ja</strong> palub luua va<strong>ja</strong>likud töövahendid<br />
• Toot<strong>ja</strong> palub mater<strong>ja</strong>le<br />
• Insener lõpetab töövahendi disaini<br />
• Toot<strong>ja</strong> saab töövahendi valmis <strong>ja</strong> hanki<strong>ja</strong><br />
saab mater<strong>ja</strong>li hangitud<br />
• Toot<strong>ja</strong> lõpetab tootmise<br />
• Inspekteeri<strong>ja</strong> avastab loodud tootes vigu<br />
• Klient saab ostetud toote kätte<br />
• Tööta<strong>ja</strong> alustab tööd<br />
Põhiprotsessid<br />
• Müük<br />
• Toote disain<br />
• Planeerimine<br />
• Töövahendite disain<br />
• Mater<strong>ja</strong>lide hankimine<br />
• Töövahendite tegemine<br />
• Tootmine<br />
• Kohaletoimetamine<br />
• Tööta<strong>ja</strong>te haldamine<br />
Tegutse<strong>ja</strong>d<br />
• Klient<br />
• Müü<strong>ja</strong><br />
• Projekteeri<strong>ja</strong><br />
• Toot<strong>ja</strong><br />
• Insener<br />
• Hanki<strong>ja</strong><br />
• Inspekteeri<strong>ja</strong><br />
• Käsk<strong>ja</strong>lg<br />
• Personalijuht<br />
36
TTÜ: Andmebaaside projekteerimine.<br />
Strateegiline analüüs <strong>ja</strong> detailanalüüs (2012)<br />
© Erki Eessaar<br />
Tabel 8 Tootmisettevõtte IS võimalik tükeldus allsüsteemideks.<br />
Pädevusala allsüsteemid<br />
• Kliendi pädevusala<br />
• Müü<strong>ja</strong> pädevusala<br />
• Projekteeri<strong>ja</strong> pädevusala<br />
• Toot<strong>ja</strong> pädevusala<br />
• Inseneri pädevusala<br />
• Hanki<strong>ja</strong> pädevusala<br />
• Inspekteeri<strong>ja</strong> pädevusala<br />
• Käsk<strong>ja</strong>la pädevusala<br />
• Personalijuhi pädevusala<br />
Registrid<br />
• Tellimuste register<br />
• Kavandite register<br />
• Valmistoodete register<br />
• Mater<strong>ja</strong>lide <strong>ja</strong> vahendite register<br />
• Tööta<strong>ja</strong>te register<br />
• Saadetiste register<br />
• Klientide register<br />
• ...<br />
Funktsionaalsed allsüsteemid<br />
• Müügi arvestus<br />
- Toote tellimuse registreerimine<br />
- Kliendi registreerimine<br />
- ...<br />
• Tootearenduse arvestus<br />
- Kavandi koostamine<br />
- Kavandi täiendamine<br />
- ...<br />
• Tootmise arvestus<br />
- Tootmise registreerimine<br />
- Valminud kauba registreerimine<br />
- Kadude registreerimine<br />
- Kvaliteedikontroll<br />
- ...<br />
• Mater<strong>ja</strong>lide arvestus<br />
- Tarni<strong>ja</strong> registreerimine<br />
- Tellimuse koostamine<br />
- Mater<strong>ja</strong>lide vastuvõtt<br />
- Mater<strong>ja</strong>li inspekteerimine<br />
- ...<br />
• Tööta<strong>ja</strong>te arvestus<br />
- Tööta<strong>ja</strong> registreerimine<br />
- Tööta<strong>ja</strong> lahkumise registreerimine<br />
- ...<br />
• Saadetiste arvestus<br />
- Saadetise registreerimine<br />
- Kohaletoimetamise<br />
registreerimine<br />
• ...<br />
37
TTÜ: Andmebaaside projekteerimine.<br />
Strateegiline analüüs <strong>ja</strong> detailanalüüs (2012)<br />
© Erki Eessaar<br />
7. Kontseptuaalne andmemudel<br />
Infosüsteemi projekteerimise käigus läbiviidava strateegilise <strong>ja</strong> detailanalüüsi<br />
olulises tulemuseks on kontseptuaalne andmemudel.<br />
Kontseptuaalne andmemudel on mittetehniline mudel, mis kirjeldab süsteemi<br />
baasandmeid. Ta kirjeldab nõudeid andmebaasile, aga mitte andmebaasi<br />
tehnilist realisatsiooni. Seega kontseptuaalses andmemudelis ei pöörata<br />
tähelepanu ühelegi andmebaasi realiseerimisega seotud as<strong>ja</strong>olule, nagu:<br />
• andmemudel (näiteks relatsiooniline mudel),<br />
• kasutatav andmebaasisüsteem,<br />
• kasutatav riistvara platvorm,<br />
• kasutatava arvutivõrgu ülesehitus,<br />
• töökiiruse küsimused.<br />
Kontseptuaalne andmemudel on aluseks andmebaasi tehniliste kavandite<br />
loomisele, mis arvestavad andmemudeliga (näiteks relatsiooniline mudel) ning<br />
andmebaasi loomiseks kasutatava tarkvara- <strong>ja</strong> riistvara platvormiga<br />
(sealhulgas kasutatava andmebaasisüsteemiga). Kontseptuaalse<br />
andmemudeli esialgsed visandid e. eskiisid luuakse strateegilise analüüsi<br />
käigus ning mudeli koostamine viiakse lõpule detailanalüüsi käigus.<br />
Date (2003) nimetab kontseptuaalse andmemudeli koostamist andmebaasi<br />
semantiliseks modelleerimiseks. Semantiline mudel üritab kirjeldada süsteemi<br />
tähendust. Kontseptuaalne andmemudel kirjeldabki süsteemis säilitama<br />
hakatavate andmete tähendust, struktuuri ning andmetega seotud kitsendusi.<br />
Öeldakse ka, et kontseptuaalne andmemudel valmib andmebaasi<br />
kontseptuaalse disaini tulemusena.<br />
Kontseptuaalse andmemudeli oluliseks koostisosaks on visuaalne mudel<br />
(diagramm), mis kirjeldab andmebaasi kontseptuaalset struktuuri. Kaks<br />
levinud diagrammi tüüpi (<strong>ja</strong> tegelikult ka vastavat modelleerimise viisi) taolise<br />
informatsiooni esitamiseks on:<br />
• Olemi-suhte diagramm (inglise keeles entity-relationship diagramm,<br />
ERD)<br />
• Objekti-rolli mudel (inglise keeles object-role model, ORM)<br />
(http://www.orm.net)<br />
Kontseptuaalse andmemudeli võimalikku struktuuri kirjeldab järgmine valem:<br />
Kontseptuaalne andmemudel = andmebaasi kontseptuaalset struktuuri<br />
esitavad diagrammid + diagrammide elementide tekstilised spetsifikatsioonid<br />
(semantika kirjeldus) + andmetega seotud kitsenduste spetsifikatsioonid.<br />
Väga levinud meetodiks on kasutada kontseptuaalse andmebaasi disaini<br />
tulemuste esitamiseks olemi-suhte diagramme. Tänapäeval luuakse olemisuhte<br />
diagrammid sageli kasutades UMLi klassidiagramme. UML oli algselt<br />
mõeldud objekt-orienteeritud analüüsi <strong>ja</strong> disaini läbiviimiseks, kuid selle<br />
38
TTÜ: Andmebaaside projekteerimine.<br />
Strateegiline analüüs <strong>ja</strong> detailanalüüs (2012)<br />
© Erki Eessaar<br />
laiendusmehhanismid võimaldavad teda kasutada universaalse keelena<br />
paljude modelleerimisülesannete lahendamiseks.<br />
7.1 Olemi-suhte diagramm<br />
Väga levinud meetodiks on kasutada kontseptuaalse andmebaasi<br />
kirjeldamiseks olemi-suhte diagramme. Olemi-suhte diagrammid pakuti Peter<br />
Cheni poolt väl<strong>ja</strong> 1970-ndate keskel (Chen, 1976). Chen soovis luua<br />
esitusviisi, millega saaks modelleerida nii hierarhilisi-, võrk-, kui ka<br />
relatsioonilisi andmebaase. 1986 pakuti väl<strong>ja</strong> laiendatud olemi-suhte<br />
diagramm (Theory et al., 1986). Muuhulgas võimaldas see laiendus kirjeldada<br />
üldistusseoseid.<br />
A<strong>ja</strong> jooksul on väl<strong>ja</strong> pakutud palju erinevaid märgisüsteeme e. notatsioone,<br />
mida saab kasutada olemi-suhte diagrammide joonistamiseks. Üks tuntud<br />
märgisüsteem on näiteks Richard Barkeri poolt väl<strong>ja</strong>pakutud Barkeri<br />
märgisüsteem (Barker, 1990). Selle võttis kasutusele Oracle Corporation<br />
integreerides selle arendusmetoodikaga Oracle*CASE ning CASE (Comupter<br />
Aided System Engineering) vahendiga Oracle Designer. Taolist<br />
märgisüsteemi kasutatakse ka näiteks L. Silverstoni koostatud universaalseid<br />
andmemudeleid esitavates raamatutes (Silverston, 2001a; Silverston, 2001b).<br />
Olemi-suhte diagramm on staatikadiagramm, mis kirjeldab süsteemi struktuuri<br />
aspekti.<br />
<br />
Haridusaste_liik<br />
nimetus : String<br />
<br />
Õppeaine_seisundi_liik<br />
nimetus : String<br />
+kõrgeim<br />
1<br />
saavutatud<br />
aste<br />
iseloomustab<br />
0..*<br />
<br />
Õppejõud<br />
eesnimi : String<br />
perenimi : String<br />
sünniaeg : Date<br />
1<br />
0..*<br />
<br />
Õpetamine<br />
alguse_aeg : Date<br />
lõpu_aeg : Date<br />
0..*<br />
+hetkel kehtiv<br />
seisund<br />
1<br />
0..*<br />
1<br />
iseloomustab<br />
<br />
Õppeaine<br />
ainekood : String<br />
nimetus : String<br />
pikk_kirjeldus : String<br />
ainepunkte : Double<br />
Joonis 9 Olemi-suhte diagrammi näide.<br />
Tänapäeval luuakse olemi-suhte diagrammid sageli kasutades UMLi<br />
klassidiagramme. UML oli algselt mõeldud objekt-orienteeritud analüüsi <strong>ja</strong><br />
disaini läbiviimiseks, kuid selle laiendusmehhanismid võimaldavad teda<br />
kasutada universaalse keelena paljude modelleerimisülesannete<br />
lahendamiseks.<br />
39
TTÜ: Andmebaaside projekteerimine.<br />
Strateegiline analüüs <strong>ja</strong> detailanalüüs (2012)<br />
© Erki Eessaar<br />
Käesolevas raamatus käsitleme me kontseptuaalse andmemudeli koostamist<br />
kasutades selleks UMLis loodud olemi-suhte diagramme.<br />
7.1.1 Olemi-suhte diagrammi komponendid<br />
Olemi-suhte diagrammil esitatakse olemitüübid, olemitüüpide vahelised<br />
seosetüübid ning olemitüüpide atribuudid.<br />
Igale kontseptuaalses andmemudelis esitatud olemitüübile vastab reaalses<br />
maailmas (objektsüsteemis) eksisteeriv konkreetne või abstraktne objekt (asi,<br />
olem), mille kohta tuleb andmebaasis andmeid säilitada.<br />
Valiku aitavad teha modelleeri<strong>ja</strong> enda kogemused ning teiste arenda<strong>ja</strong>te<br />
kogemused mis võivad olla esitatud mustrite või taaskasutatavate mudelite<br />
abil.<br />
7.1.1.1 Olemitüüp<br />
Olem: Suvaline konkreetne või abstraktne asi, mis eksisteerib, eksisteeris või<br />
võiks eksisteerida, kaasa arvatud nende as<strong>ja</strong>de ühendused. Üksikuid olemeid<br />
olemi-suhte diagrammil ei esitata. Olemi-suhte diagrammil esitatakse olemite<br />
üldistused – olemitüübid. Näiteks on olemid konkreetsed õppeained nagu<br />
"Andmebaaside projekteerimine" ainekoodiga IDU3381 <strong>ja</strong> "Andmebaaside<br />
programmeerimine" ainekoodiga IDU0120.<br />
Olemitüüp: Ühiste nimeliste omadustega olemite hulk. Võib öelda, et<br />
tegemist on reaalses maailmas eksisteerivate olemite üldistusega.<br />
Kontseptuaalses andmemudelis tuleb esitada sellised <strong>ja</strong> ainult sellised<br />
olemitüübid, millele vastavate olemite kohta soovitakse hakata hoidma<br />
andmebaasis andmeid. Segadust tekitab, et mõned allikad kasutavad termini<br />
"Olemitüüp" asemel terminit "Olem" <strong>ja</strong> termini "Olem" asemel terminit<br />
"Olemieksemplar".<br />
Olemi-suhte diagrammil esitatakse olemitüüp klassisümboli abil. Klassile võib<br />
määrata stereotüübi tõstmaks esile, et tegemist ei ole mitte<br />
tavalise tarkvaraklassiga, vaid see esitab kontseptuaalses andmemudelis<br />
olemitüüpi. Mis on stereotüüp? Stereotüüp on UMLi laiendusmehhanism, mis<br />
võimaldab luua uut tüüpi mudelielemente, tuletades neid olemasolevatest<br />
elementidest (nt. klass, atribuut, assotsiatsioon, pakett). Neil uutel elementidel<br />
on oma spetsiifilised omadused (sildid), semantika <strong>ja</strong> visuaalne tähistus.<br />
Joonis 9 oleval olemi-suhte diagrammil esitatakse olemitüübid Õppejõud,<br />
Õpetamine, Õppeaine, Haridusaste_liik <strong>ja</strong> Õppeaine_seisundi_liik.<br />
Nagu öeldud, võimaldab stereotüüp kasutada alternatiivset visuaalset<br />
tähistust. Joonis 10 esitatakse olemitüübid (Õppeaine_seisundi_liik <strong>ja</strong><br />
Õppeaine), kasutades stereotüübi poolt määratud alternatiivset<br />
visuaalset tähistust. Segaduse vältimiseks on oluline, et ühes mudelis ei<br />
kasutataks läbisegi erinevaid visuaalseid tähistusi.<br />
40
TTÜ: Andmebaaside projekteerimine.<br />
Strateegiline analüüs <strong>ja</strong> detailanalüüs (2012)<br />
© Erki Eessaar<br />
Joonis 10 Olemi-suhte diagrammi näide.<br />
7.1.1.2 Seosetüüp<br />
Seos, suhe, side: Seos on tunnetatud ühendus olemite vahel. Üksikuid<br />
seoseid olemi-suhte diagrammil ei esitata. Olemi-suhte diagrammil esitatakse<br />
seoste üldistused – seosetüübid.<br />
Näiteks: Õppejõud "Andres Mets" õpetab õppeainet "Tuumafüüsika" alates<br />
kuupäevast 1. september 2008 kuni kuupäevani 1. veebruar 2009.<br />
Seosetüüp e. suhtetüüp: Kontseptuaalses andmemudelis esitatav<br />
seosetüüp on selliste seoste üldistus, mille kohta tuleb andmebaasis andmeid<br />
säilitada. Olemi-suhte diagrammil esitatakse seosetüübid joontena.<br />
Seosetüübid võivad olla erinevat liiki (assotsiatsioon, osa-terviku seos,<br />
üldistusseos) ning nendest liikidest tuleb juttu edaspidi. Iga seosetüübi kohta<br />
tuleb kindlaks teha ning dokumenteerida ka selle omadused.<br />
Mis on ühe modelleeri<strong>ja</strong> <strong>ja</strong>oks seosetüüp, see on teise <strong>ja</strong>oks olemitüüp <strong>ja</strong><br />
vastupidi. Näiteks süsteemi kirjeldava lause "Õppejõud õpetab õppeainet"<br />
põh<strong>ja</strong>l võib leida olemitüübid Õppejõud <strong>ja</strong> Õppeaine. Kuid Õpetamine on<br />
võimalik modelleerida nii seosetüübina Õppejõud <strong>ja</strong> Õppeaine vahel kui ka<br />
olemitüübina. Kui seosetüübil on nimelisi omadusi, millele vastavaid andmeid<br />
tuleb andmebaasis hoida, siis tuleb see seosetüüp modelleerida olemitüübina.<br />
Antud juhul tuleks õpetamise kohta registreerida ka õpetamise alguse aeg <strong>ja</strong><br />
lõpu aeg ning seetõttu on Joonis 9 esitatud ka olemitüüp Õpetamine.<br />
Roll: Roll kirjeldab olemitüübi tähendust seosetüübi kontekstis, milles ta<br />
osaleb. Rollid aitavad selgitada seosetüüpide tähendust. Olemi-suhte<br />
diagrammil esitatakse rollid seosetüüpide otstesse kirjutatud tekstina<br />
"+rollinimi". Eriti oluline on rollid määrata, kui kahe olemitüübi vahel on<br />
rohkem kui üks seosetüüp.<br />
Joonis 11 esitatud diagrammil on Tööta<strong>ja</strong> <strong>ja</strong> Erakorraline kursus vahel kolm<br />
seosetüüpi. Iga erakorralise kursuse idee on pakutud väl<strong>ja</strong> null või ühe tööta<strong>ja</strong><br />
poolt, kes on rollis "õppejõud". Iga erakorraline kursuse idee on kinnitatud null<br />
või ühe tööta<strong>ja</strong> poolt, kes on rollis "õppeosakonna tööta<strong>ja</strong>". Iga erakorraline<br />
kursus on kinnitatud null või ühe tööta<strong>ja</strong> poolt, kes on rollis "instituudi<br />
direktor".<br />
41
TTÜ: Andmebaaside projekteerimine.<br />
Strateegiline analüüs <strong>ja</strong> detailanalüüs (2012)<br />
© Erki Eessaar<br />
0..1 pakub idee väl<strong>ja</strong><br />
+õppejõud<br />
0..*<br />
<br />
Tööta<strong>ja</strong><br />
0..1<br />
+õppeosakonna<br />
tööta<strong>ja</strong><br />
0..1<br />
+instituudi direktor<br />
kinnitab<br />
kinnitab<br />
0..*<br />
<br />
Erakorraline kursus<br />
0..*<br />
Joonis 11 Mitu seosetüüpi kahe olemitüübi vahel.<br />
Hotell : Olemitüüp<br />
(hotelli nimi)<br />
Sisaldab :<br />
Seosetüüp<br />
Ruum : Olemitüüp<br />
(ruumi nr.)<br />
Viru r1<br />
1<br />
Olümpia<br />
r2<br />
r3<br />
2<br />
3<br />
Olem<br />
Seos<br />
Joonis 12 Seosetüübi semantika.<br />
Seosetüübi aste: Seosetüübi aste on seosetüübis osalevate olemitüüpide<br />
(osaliste) arv. Seega näiteks:<br />
• üheliikmelises e. unaarses seosetüübis osaleb üks olemitüüp<br />
(erinevates rollides) (vt. rekursiivne seosetüüp).<br />
• kaheliikmeliikmelises e. binaarses seosetüübis osaleb kaks olemitüüpi.<br />
• kolmeliikmelises e. ternaarses seosetüübis osaleb kolm olemitüüpi.<br />
Kõik Joonis 9 <strong>ja</strong> Joonis 11 esitatud seosetüübid on kaheliikmelised.<br />
Kaheliikmelised seosetüübid on olemi-suhte diagrammidel kõige levinumad.<br />
42
TTÜ: Andmebaaside projekteerimine.<br />
Strateegiline analüüs <strong>ja</strong> detailanalüüs (2012)<br />
© Erki Eessaar<br />
Rekursiivne seosetüüp: Rekursiivne seosetüüp on seosetüüp, kus<br />
seosetüübi mõlemas otsas on osaliseks sama olemitüüp, kuid erinevates<br />
rollides. Rekursiivset seosetüüpi kutsutakse ka unaarseks seosetüübiks.<br />
Joonis 13 esitatud diagrammil on rekursiivne seosetüüp mille mõlemas otsas<br />
on sama olemitüüp (Tööta<strong>ja</strong>), kuid erinevates rollides (ülemus, alluv).<br />
Diagrammi kohaselt on igal tööta<strong>ja</strong>l null või üks otsene ülemus <strong>ja</strong> null või<br />
rohkem otsest alluvat.<br />
Joonis 13 Rekursiivse seosetüübi näide.<br />
Mida tähendab märkmelehele kirjutatud "{Acyclic}"? Tegemist on<br />
kitsendusega, mille kohaselt tööta<strong>ja</strong>te vahelistes seostes ei tohi leiduda<br />
"tsükleid" (Miliauskaite <strong>ja</strong> Nemuraite, 2005). See tähendab, et tööta<strong>ja</strong> ei tohi<br />
olla iseenda otsene ega kaudne ülemus (näiteks ülemuse ülemus) <strong>ja</strong> otsene<br />
ega kaudne alluv (näiteks alluva alluv). Taoliste kitsenduste leidmine <strong>ja</strong><br />
dokumenteerimine on va<strong>ja</strong>lik, sest tegemist on ärireeglitega millele vastavad<br />
kitsendused tuleb jõustada ka andmebaasis (andmebaasi kitsendustena).<br />
Kui joonistada olemi-suhte diagrammi UMLis, siis võib kitsenduste<br />
kir<strong>ja</strong>panemiseks kasutada UMLi formaalset objektikitsenduste keelt (Object<br />
Constraint Language e. OCL), aga seda võib kir<strong>ja</strong> panna ka vabas vormis<br />
tekstina. UML 2.0 ei nõua kitsenduste kirjeldamisel kindla keele kasutamist.<br />
Nõutud on vaid, et kitsendus tuleb panna looksulgudesse {}.<br />
Millist keelt oleks soovitav kitsenduste kirjeldamiseks kasutada? Esitame<br />
järgnevalt näite OCL kitsendusest, mille kohaselt identifitseerib atribuudi<br />
tellimuse_nr väärtus unikaalselt iga olemitüüpi Tellimus kuuluvat olemit.<br />
Täpsemalt, tellimused t1 <strong>ja</strong> t2 on erinevad tellimused, kui nende tellimuse<br />
numbrid on erinevad.<br />
[context Tellimus]<br />
Tellimus.allInstances -> forAll ( t1, t2 | t1t2 implies<br />
t1.tellimuse_nrt2.tellimuse_nr)<br />
Kui kitsenduse kirjeldamiseks kasutada formaalset keelt, siis saab panna<br />
kitsenduse kir<strong>ja</strong> täpselt <strong>ja</strong> üheselt arusaadavalt. Sellises keeles kitsenduste<br />
kirjeldusi suudab analüüsida <strong>ja</strong> interpreteerida ka tarkvarasüsteem. Samas,<br />
taolised kirjeldused pole ilma eriettevalmistuseta inimestele arusaadavad.<br />
Mudeleid peaksid üle vaatama <strong>ja</strong> nendest aru saama ka infosüsteemi<br />
tulevased kasuta<strong>ja</strong>d. Seega, kasulik oleks kitsendused dokumenteerida kahel<br />
viisil:<br />
• Täpne <strong>ja</strong> formaalne kirjeldus kasutades näiteks OCLi.<br />
43
TTÜ: Andmebaaside projekteerimine.<br />
Strateegiline analüüs <strong>ja</strong> detailanalüüs (2012)<br />
• Laiemale kasuta<strong>ja</strong>te ringile arusaadav tavakeelne kirjeldus.<br />
© Erki Eessaar<br />
Vaatleme lauset: "Õppejõud õpetab õppeainet". Õppejõud <strong>ja</strong> Õppeaine on<br />
olemitüübid.<br />
Mis on ühe modelleeri<strong>ja</strong> <strong>ja</strong>oks seosetüüp, see on teise <strong>ja</strong>oks olemitüüp <strong>ja</strong><br />
vastupidi. Näiteks süsteemi kirjeldava lihtlause e. lausendi "Üliõpilane õpib<br />
õppeainet" põh<strong>ja</strong>l võib leida olemitüübid üliõpilane <strong>ja</strong> õppeaine. Kuid õppimine<br />
on võimalik modelleerida nii seosetüübina üliõpilane <strong>ja</strong> õppeaine vahel kui ka<br />
olemitüübina.<br />
Kui seosetüübil on atribuute, st. omadusi mille kohta tuleb andmebaasis<br />
andmeid hoida, siis tuleb see seosetüüp modelleerida olemitüübina.<br />
a)<br />
<br />
Õppejõud<br />
1<br />
0..*<br />
<br />
Õpetamine<br />
alguse_aeg : Date<br />
lõpu_aeg : Date<br />
0..*<br />
1<br />
<br />
Õppeaine<br />
b)<br />
Joonis 14 Seosetüübi modelleerimise võimalused UMLi joonistatud<br />
olemi-suhte diagrammil.<br />
Variandi b puhul kasutatakse seosetüübi esitamiseks UMLi sidemeklassi<br />
(inglise keeles association class). Fowler (2007) kirjutab: "Sidemeklass lisab<br />
ühe lisakitsenduse, mis seisneb selles, et iga kahe sidemes osaleva objekti<br />
vahel saab olla vaid üks sidemeklassi isend."<br />
Variandid a <strong>ja</strong> b ei ole samaväärsed. Variandi b korral kehtib täiendav reegel,<br />
et üks õppejõud ei saa õpetada ühte õppeainet rohkem kui üks kord.<br />
7.1.1.3 Atribuut<br />
Atribuut: Atribuut on "nimeline olemi omadus" (EVS-ISO/IEC 2382, 1998).<br />
Kontseptuaalses andmemudelis tuleb kirjeldada sellised atribuudid millele<br />
vastavaid andmeid soovitakse hakata andmebaasis hoidma.<br />
44
TTÜ: Andmebaaside projekteerimine.<br />
Strateegiline analüüs <strong>ja</strong> detailanalüüs (2012)<br />
© Erki Eessaar<br />
Tüüp: Iga atribuut on mingit tüüpi. Atribuudi tüüp on võimalike väärtuste hulk<br />
mille hulgast saavad tulla atribuudi väärtused. Mitmel atribuudil võib olla<br />
ühesugune tüüp.<br />
Fakultatiivne atribuut: Fakultatiivne atribuut on atribuut, millel mõne olemi<br />
korral ei ole väärtust. Näiteks olemitüübi Isik atribuut võib olla neiupõlvenimi.<br />
Kuid atribuudil neiupõlvenimi saab olla väärtus vaid naissoost isikute korral.<br />
Kohustuslik atribuut: Kohustuslik atribuut on atribuut, millel iga olemi korral<br />
on vähemalt üks väärtus, mis on antud atribuudi tüüpi. Näiteks olemitüübi Isik<br />
atribuut võib olla sünniaeg. Igal isikul on sünniaeg.<br />
Üheväärtuseline atribuut: Üheväärtuseline atribuut on atribuut, millel on iga<br />
olemi kohta maksimaalselt üks väärtus, mis on antud atribuudi tüüpi. Näiteks<br />
igal isikul on vaid üks sünniaeg.<br />
Mitmeväärtuseline atribuut: Mitmeväärtuseline atribuut on atribuut, millel<br />
võib olla mõne olemi kohta rohkem kui üks väärtus, mis on antud atribuudi<br />
tüüpi.. Näiteks võib isikul olla üks või mitu telefoni või e-maili aadressi.<br />
Kuidas modelleerida mitmeväärtuselist atribuuti?<br />
• Modelleerida UMLis mitmeväärtuselise atribuudina.<br />
• Modelleerida eraldi olemitüübina.<br />
Halb lahendus<br />
<br />
Isik<br />
isikukood : String<br />
eesnimi : String<br />
perenimi : String<br />
sünniaeg : Date<br />
elukoht : String<br />
1<br />
omab<br />
0..*<br />
<br />
e_mail<br />
e_mail : String<br />
Parem lahendus<br />
Joonis 15 Mitmeväärtuselise atribuudi modelleerimine.<br />
Esimene lahendus on halb, sest ühel isikul võib olla rohkem või vähem kui<br />
kolm e-maili aadressi.<br />
Tuletisatribuut: Tuletisatribuut on atribuut, mille väärtus on mingi<br />
arvutusreegli alusel arvutatav muude väärtuste põh<strong>ja</strong>l (näiteks sama<br />
olemitüübi teiste atribuutide väärtustest).<br />
45
TTÜ: Andmebaaside projekteerimine.<br />
Strateegiline analüüs <strong>ja</strong> detailanalüüs (2012)<br />
© Erki Eessaar<br />
Tuletisatribuudi nime ette tuleks UMLis joonistatud olemi-suhte diagrammil<br />
panna kaldkiips "/", et seda atribuuti tähistada. Samuti tuleb dokumenteerida<br />
arvutusreegel. Arvutusreegli võib panna kir<strong>ja</strong> diagrammile paigutatud<br />
märkmelehele.<br />
Näiteks hotellis ruumi üheks ööpäevaks reserveerimise hind on arvutatav<br />
reserveeritava ruumi ühe päeva hinna <strong>ja</strong> reserveeritud päevade arvu kaudu.<br />
Akna pindala on arvutatav akna kõrguse <strong>ja</strong> laiuse kaudu.<br />
<br />
Aken<br />
akna_nr : String<br />
laius : Integer<br />
kõrgus : Integer<br />
/ pindala : Double<br />
{pindala=laius*kõrgus}<br />
Joonis 16 Tuletisatribuudi näide.<br />
Tuletatud väärtuste andmebaasis hoidmise eelised:<br />
• Kiirendab päringuid.<br />
Tuletatud väärtuste andmebaasis hoidmise puudused:<br />
• Suureneb risk, et andmebaasi satuvad vastuolulised andmed<br />
1. kõrgus*laius pindala<br />
• Suurendab andmemahte<br />
Märgime, et vanuse esitamine tuletisatribuudina ei ole otstarbekas, sest<br />
vanus on pidevas muutumises ning seega tuleks selle atribuudi väärtust<br />
sagedasti muuta. Seetõttu oleks mõistlik hoida andmebaasis olemi<br />
sünni/loomise aega. Teades hetke kuupäeva <strong>ja</strong> kellaaega on selle põh<strong>ja</strong>l<br />
võimalik alati korrektne vanus väl<strong>ja</strong> arvutada (eeldusel, et süsteemis on<br />
loodud operaator, mis võimaldab leida kahe a<strong>ja</strong>hetke vahelise intervalli).<br />
7.1.1.4 Seosetüübi omadused<br />
• Järk e. võimsus<br />
• Osaluskohustus e. tugevus<br />
Need omadused tuleb määrata iga seosetüübis osaleva olemitüübi kohta.<br />
Tugevus<br />
Tugevus näitab vaadeldava seosetüübi ST <strong>ja</strong> selles osaleva olemitüübi OT<br />
kontekstis minimaalset (tüüpi ST kuuluvate) seoste arvu, milles peab<br />
osalema iga (tüüpi OT kuuluv) olem.<br />
Tugevuseks võib olla suvaline positiivne arv või 0.<br />
46
TTÜ: Andmebaaside projekteerimine.<br />
Strateegiline analüüs <strong>ja</strong> detailanalüüs (2012)<br />
© Erki Eessaar<br />
Seosetüüp ST on olemitüübi OT <strong>ja</strong>oks kohustuslik, kui iga tüüpi OT kuuluv<br />
olem peab osalema vähemalt ühes tüüpi ST kuuluvas seoses (tugevus on<br />
suvaline positiivne arv).<br />
Seosetüüp ST on olemitüübi OT <strong>ja</strong>oks mittekohustuslik, kui on lubatud tüüpi<br />
OT kuuluvad olemid, mis ei osale üheski tüüpi ST kuuluvas seoses (tugevus<br />
on 0).<br />
Näiteks Joonis 17 on seosetüüp koostatakse olemitüübi Leping <strong>ja</strong>oks<br />
kohustuslik, sest iga leping peab olema seotud vähemalt ühe arvega. Samas<br />
on seosetüüp koostatakse olemitüübi Arve <strong>ja</strong>oks mittekohustuslik, sest võib<br />
leiduda arveid mis pole seotud ühegi lepinguga.<br />
<br />
Leping<br />
0..1<br />
koostatakse<br />
1..*<br />
<br />
Arve<br />
+koostamise alus<br />
+koostamise tulemus<br />
Joonis 17 Seosetüübi kohustuslikkus.<br />
Näide:<br />
• Hotell peab olema seotud ühe või mitme ruumiga. Seega seosetüüp<br />
Hotell <strong>ja</strong> Ruum vahel on Hotell <strong>ja</strong>oks kohustuslik.<br />
• Ruumiga peab olema seotud üks hotell. Seega seosetüüp Hotell <strong>ja</strong> Ruum<br />
vahel on Ruum <strong>ja</strong>oks kohustuslik.<br />
Võimsus e. järk<br />
Võimsus näitab vaadeldava seosetüübi ST <strong>ja</strong> selles osaleva olemitüübi OT<br />
kontekstis maksimaalset (tüüpi ST kuuluvate) seoste arvu, milles võib osaleda<br />
üks (tüüpi OT kuuluv) olem.<br />
Järguks võib olla suvaline positiivne arv või * (piiramatu arvu korral).<br />
Näide:<br />
• Hotell on seotud ühe või mitme ruumiga.<br />
• Ruumiga on seotud üks hotell.<br />
• Võimsus ruumi puhul on üks, ses konkreetne ruum osaleb ühes seoses<br />
hotelliga. Ruum on seotud ühe kindla hotelliga.<br />
• Võimsus hotelli puhul on *, sest konkreetne hotell osaleb ühes või<br />
rohkemas seoses ruumidega. Hotellis on üks või mitu ruumi.<br />
Joonis 17 näitel on seosetüübi koostatakse kontekstis olemitüübi Leping<br />
tugevus 1 <strong>ja</strong> võimsus *. Seosetüübi koostatakse kontekstis on olemitüübi Arve<br />
tugevus 0 <strong>ja</strong> võimsus on 1.<br />
Tugevus <strong>ja</strong> võimsus koos määravad ära võimsustiku (inglise keeles<br />
multiplicty). Võimsustikud määratakse ära alumise <strong>ja</strong> ülemise piiriga ning<br />
seega määrab tugevus ära alapiiri <strong>ja</strong> võimsus ülapiiri. Kui ala- <strong>ja</strong> ülapiir on<br />
47
TTÜ: Andmebaaside projekteerimine.<br />
Strateegiline analüüs <strong>ja</strong> detailanalüüs (2012)<br />
© Erki Eessaar<br />
sama võib kasutada ühte arvu. Järgnevalt esitame näiteid võimalikest<br />
võimsustikest.<br />
Tähistus Sõnaline selgitus<br />
0..1 Null või üks<br />
1..1 (või 1) Täpselt üks<br />
0..* Null või rohkem<br />
1..* Üks või rohkem<br />
5..10 Viis kuni kümme<br />
Võimsustikud esitavad kitsendusi mille põh<strong>ja</strong>l luuakse andmebaasis<br />
kitsendusi.<br />
Erinevates notatsioonides esitatakse võimsustikke erinevalt.<br />
Näide:<br />
Isik<br />
kuulub<br />
omab<br />
Auto<br />
Isik omab null või<br />
rohkem autot<br />
Isik<br />
kuulub<br />
omab<br />
Auto<br />
Isik omab üks või<br />
rohkem autot<br />
Isik<br />
Isik<br />
Isik<br />
kuulub<br />
kuulub<br />
kuulub<br />
omab<br />
omab<br />
omab<br />
Auto<br />
Auto<br />
Auto<br />
Isik omab täpselt<br />
ühte autot<br />
Isik omab täpselt<br />
kahte autot<br />
Isik omab null või<br />
üks autot<br />
Joonis 18 Erinevad seoste tüübid esitatuna varese<strong>ja</strong>lgade notatsioonis.<br />
Õppejõud peab õpetama ühte kuni nel<strong>ja</strong> õppeainet. (1..4)<br />
Õppeainet võib õpetada üks õppejõud. (0..1)<br />
Joonis 19 Võimsustike näide.<br />
Iga lepingu alusel võib koostada ühe <strong>ja</strong> ainult ühe arve. (0..1)<br />
Iga arve võib olla koostatud ühe <strong>ja</strong> ainult ühe lepingu alusel. (0..1)<br />
<br />
Leping<br />
koostatakse<br />
0..1 0..1<br />
<br />
Arve<br />
+koostamise alus<br />
+koostamise tulemus<br />
Joonis 20 Võimsustike näide.<br />
48
TTÜ: Andmebaaside projekteerimine.<br />
Strateegiline analüüs <strong>ja</strong> detailanalüüs (2012)<br />
© Erki Eessaar<br />
Iga lepingu alusel võib koostada ühe <strong>ja</strong> ainult ühe arve. (0..1)<br />
Iga arve peab olema koostatud ühe <strong>ja</strong> ainult ühe lepingu alusel. (1)<br />
<br />
Leping<br />
koostatakse<br />
1 0..1<br />
<br />
Arve<br />
+koostamise alus<br />
+koostamise tulemus<br />
Joonis 21 Võimsustike näide.<br />
Iga lepingu alusel peab koostama ühe <strong>ja</strong> ainult ühe arve. (1)<br />
Iga arve peab olema koostatud ühe <strong>ja</strong> ainult ühe lepingu alusel. (1)<br />
<br />
Leping<br />
koostatakse<br />
1 1<br />
<br />
Arve<br />
+koostamise alus<br />
+koostamise tulemus<br />
Joonis 22 Võimsustike näide.<br />
Iga lepingu alusel võib koostada ühe või mitu arvet. (0..*)<br />
Iga arve peab olema koostatud ühe <strong>ja</strong> ainult ühe lepingu alusel. (1)<br />
<br />
Leping<br />
koostatakse<br />
1 0..*<br />
<br />
Arve<br />
+koostamise alus<br />
+koostamise tulemus<br />
Joonis 23 Võimsustike näide.<br />
Iga lepingu alusel peab koostama ühe või mitu arvet. (1..*)<br />
Iga arve peab olema koostatud ühe <strong>ja</strong> ainult ühe lepingu alusel. (1)<br />
<br />
Leping<br />
koostatakse<br />
1 1..*<br />
<br />
Arve<br />
+koostamise alus<br />
+koostamise tulemus<br />
Joonis 24 Võimsustike näide.<br />
Sõltuvalt võimsustikest võib kahte olemitüüpi siduv kaheliikmeline seosetüüp<br />
olla:<br />
• üks-ühele (1:1) seosetüüp (vt. Joonis 20, Joonis 21, Joonis 22);<br />
• üks-mitmele (1:M) seosetüüp (vt. Joonis 19, Joonis 23, Joonis 24);<br />
• mitu-mitmele (M:N) seosetüüp;<br />
49
TTÜ: Andmebaaside projekteerimine.<br />
Strateegiline analüüs <strong>ja</strong> detailanalüüs (2012)<br />
© Erki Eessaar<br />
Olemi-suhte diagrammil võib esitada välistava kaare. Välistavat kaart saab<br />
kirjeldada, kui olemitüüp OT on seosetüüpide kaudu seotud kahe või rohkema<br />
olemitüübiga. Kaar esitab kitsenduse, et iga olemi puhul (mis on tüüpi OT)<br />
peavad eksisteerima täpselt ühte kaarega hõlmatud seosetüüpi kuuluvad<br />
seosed.<br />
Antud juhul peab iga lepingu rida olema seotud kas kauba või teenusega, aga<br />
mitte mõlemaga korraga. Teisisõnu, ei ole lubatud lepingu read, mis ei ole<br />
seotud ei kauba ega teenusega. Samuti ei ole lubatud lepingu read, mis on<br />
seotud nii kauba kui ka teenusega. Pange tähele, et seetõttu on iga lepingu<br />
rida seotud null või ühe teenusega <strong>ja</strong> null või ühe kaubaga, mitte täpselt ühe<br />
teenusega <strong>ja</strong> täpselt ühe kaubaga.<br />
Klient<br />
Leping<br />
Pakku<strong>ja</strong><br />
Lepingu<br />
rida<br />
Teenus<br />
Kaup<br />
Joonis 25 Kaare esitamine olemi-suhte diagrammil, kasutades<br />
varese<strong>ja</strong>lgade notatsiooni.<br />
Joonis 26Kaare esitamine UMLis joonistatud olemi-suhte diagrammil.<br />
Alamhulga kitsendus. UMLis saab esitada alamhulga kitsenduse (Halpin,<br />
2001). Näite kohaselt saab iga isik olla vaid sellise komitee esimees, mille<br />
liige ta on (komitee esimeeste hulk on komitee liikmete alamhulk). Pange<br />
50
TTÜ: Andmebaaside projekteerimine.<br />
Strateegiline analüüs <strong>ja</strong> detailanalüüs (2012)<br />
© Erki Eessaar<br />
tähele, et kuna igal komiteel on täpselt üks esimees, siis peab tänu alamhulga<br />
kitsendusele igal komiteel olema üks või rohkem liiget.<br />
Joonis 27Alamhulga kitsenduse esitamine UMLis joonistatud olemisuhte<br />
diagrammil.<br />
7.1.2 Laiendatud olemi-suhte diagramm<br />
7.1.2.1 Üldistusseos<br />
Ülatüüp on olemitüüp, millel on üks või rohkem alamtüüpi. Iga alamtüüpi olem<br />
on ühtlasi ka ülatüüpi olem, kuid vastupidine ei pruugi alati kehtida (st. iga<br />
ülatüüpi olem ei ole alati ka alamtüüpi olem). Alamtüüpi olem pärib kõik<br />
ülatüüpi olemi seosed <strong>ja</strong> atribuudid. Seetõttu nimetatakse üldistusseost ka<br />
pärimisseoseks. Alamtüübil võivad (aga ei pruugi olla) olla võrreldes<br />
ülatüübiga täiendavad omadused (atribuudid) <strong>ja</strong>/või ta osaleb täiendavates<br />
seosetüüpides. Ühel ülatüübil võib olla mitu alamtüüpi. Ühel alamtüübil võib<br />
olla mitu ülatüüpi (mitmene pärimine).<br />
Näiteks ülatüübi Isik atribuutideks võivad olla isikukood, eesnimi, perenimi<br />
sünniaeg <strong>ja</strong> elukoht. Ülatüübi Isik alamtüübid võivad olla Üliõpilane <strong>ja</strong> Tööta<strong>ja</strong>.<br />
Nii tööta<strong>ja</strong> kui ka üliõpilane on isikud. Alamtüüp Tööta<strong>ja</strong> osaleb seosetüübis<br />
olemitüübiga Amet. Alamtüübil Üliõpilane on atribuut üliõpilaskood.<br />
Üldistusseos ühendab omavahel ülatüübi <strong>ja</strong> selle alamtüübi. Diagrammil<br />
esitab seda ülatüüpi <strong>ja</strong> alamtüüpi ühendav joon. Selle joone ülatüübi poolses<br />
otsas on kolmnurk, mille tipp on suunatud ülatüübi poole.<br />
Kuidas sõnaliselt väljendada olemi-suhte diagrammil esitatud üldistusseost?<br />
Joonis 31 esitatud diagrammi kohaselt: Üliõpilane on isik. Tööta<strong>ja</strong> on isik.<br />
Ülatüübiks/alamtüübiks olemine on suhteline – olemitüüp, mis on ühe<br />
üldistusseose kontekstis ülatüüp võib olla teise üldistusseose kontekstis<br />
alamtüüp.<br />
Alamtüüp peab vastama järgmistele kriteeriumitele (Larman, 2002, lk. 399):<br />
• Ülatüübi definitsioon peab 100% kehtima ka selle alamtüübi suhtes.<br />
• Kõik alamtüüpi olemid on ka ülatüüpi.<br />
Üldistusseoste kaudu seotud olemitüübid moodustavad tüüpide hierarhia.<br />
Tüüpide hierarhiate leidmiseks võib kasutada spetsialiseerimise või<br />
üldistamise meetodit.<br />
51
TTÜ: Andmebaaside projekteerimine.<br />
Strateegiline analüüs <strong>ja</strong> detailanalüüs (2012)<br />
© Erki Eessaar<br />
Spetsialiseerimine tähendab, et üritatakse leida olemitüüpe eristavaid<br />
omadusi. Näiteks leitakse olemitüüp Isik <strong>ja</strong> seejärel tehakse kindlaks, et isik<br />
võib olla nii füüsiline kui ka juriidiline isik.<br />
Üldistamine tähendab, et üritatakse minimeerida erinevusi olemitüüpide vahel<br />
<strong>ja</strong> leida nende ühiseid omadusi. Näiteks leitakse olemitüübid Ostutellimus <strong>ja</strong><br />
Müügitellimus <strong>ja</strong> tehakse üldistus, et tegemist on Tellimusega ning veel<br />
üldisemalt Lepinguga ost<strong>ja</strong>te <strong>ja</strong> müü<strong>ja</strong>te vahel.<br />
Praktikas tuleb neid meetodeid modelleerimisel kasutada üheskoos.<br />
Joonis 28 Üldistusseose näide.<br />
Isik on ülatüüp <strong>ja</strong> Toota<strong>ja</strong> on alamtüüp. Seost loetakse järgnevalt: "Tööta<strong>ja</strong> on<br />
Isik".<br />
Millal oleks kasulik leida <strong>ja</strong> mudelil esitada nii ülatüüp kui ka selle alamtüübid?<br />
• Osa atribuute on ühised kõikidele alamtüüpidele <strong>ja</strong> need tuleks esitada<br />
ülatüübis. Osa atribuute aga on spetsiifilised mingile kindlale alamtüübile.<br />
• Osa seosetüüpe on ühised kõikidele alamtüüpidele <strong>ja</strong> need tuleks esitada<br />
ülatüübi tasemel. Osa seosetüüpe aga on spetsiifilised mingile kindlale<br />
alamtüübile.<br />
Üldistuste hulk on kogum üldistusseoseid, mis üheskoos kirjeldavad, kuidas<br />
ülatüüpi mingil kindlal viisil alamtüüpideks <strong>ja</strong>gada. Järgneval diagrammil<br />
esitatakse kaks üldistuste hulka, mille nimed on roll <strong>ja</strong> sugu. Ühte hulka<br />
kuuluvad üldistusseosed on visuaalselt „kokku tõmmatud“. Üldistuste hulk<br />
sugu <strong>ja</strong>gab ülatüübi Isik alamtüüpideks vastavalt isiku soole. Üldistuste hulk<br />
roll <strong>ja</strong>gab ülatüübi Isik alamtüüpideks vastavalt isiku rollile. Mõlemasse<br />
üldistuste hulka kuuluvate üldistusseoste korral on Isik ülatüüp.<br />
52
TTÜ: Andmebaaside projekteerimine.<br />
Strateegiline analüüs <strong>ja</strong> detailanalüüs (2012)<br />
© Erki Eessaar<br />
Joonis 29 Üldistuste hulgad.<br />
Üldistusseostega koos tuleks ära määrata ka nendega seotud kitsendused<br />
(Connolly <strong>ja</strong> Begg, 2002). Nende kitsenduste alusel luuakse hiljem jällegi<br />
andmebaasi kitsendusi.<br />
Osaluskohustus määrab, kas iga ülatüüpi kuuluv olem peab kuuluma ka<br />
mõnda alamtüüpi:<br />
• Kui iga ülatüüpi kuuluv olem peab kuuluma vähemalt ühte alamtüüpi, siis<br />
tähistatakse seda diagrammil {Mandatory}.<br />
• Kui iga ülatüüpi kuuluv olem ei pea kuuluma mõnda alamtüüpi (see<br />
tähendab, et võib leiduda ülatüüpi kuuluvaid olemeid, mis ei kuulu ühtegi<br />
alamtüüpi, siis tähistatakse seda diagrammil {Optional}.<br />
Kuuluvus määrab maksimaalse alamtüüpide arvu kuhu ülatüüpi olem võib<br />
kuuluda:<br />
• Kui iga ülatüüpi olem saab kuuluda maksimaalselt ühte alamtüüpi, siis<br />
tähistatakse seda diagrammil {Or}.<br />
• Kui iga ülatüüpi olem saab kuuluda rohkem kui ühte erinevasse alamtüüpi,<br />
siis tähistatakse seda diagrammil {And}.<br />
Kuuluvuse kitsendust pole va<strong>ja</strong> esitada, kui ülatüübil on ainult üks alamtüüp.<br />
Osaluskohustuse <strong>ja</strong> kuuluvuse kitsendused tuleb esitada eraldi iga üldistuste<br />
hulga kohta.<br />
53
TTÜ: Andmebaaside projekteerimine.<br />
Strateegiline analüüs <strong>ja</strong> detailanalüüs (2012)<br />
© Erki Eessaar<br />
Joonis 30 Üldistuste hulgad koos kitsendustega.<br />
Vaatleme Joonis 31 esitatud kitsendust "{Otional, And}". "Optional" tähendab,<br />
et võib leiduda isikuid, kes ei ole ei üliõpilased ega tööta<strong>ja</strong>d. "And" tähendab,<br />
et võib leiduda isikuid, kes on korraga nii üliõpilased kui ka tööta<strong>ja</strong>d. Pange<br />
tähele, et diagrammil võib, aga ei pea kitsendust kirjutama märkmelehele.<br />
<br />
Isik<br />
isikukood : String<br />
eesnimi : String<br />
perenimi : String<br />
sünniaeg : Date<br />
elukoht : String<br />
{Optional, And}<br />
<br />
Üliõpilane<br />
üliõpilaskood : String<br />
<br />
Tööta<strong>ja</strong><br />
0..* 1<br />
<br />
Amet<br />
nimetus : String<br />
Joonis 31 Üldistusseose näide.<br />
Oletame, et Joonis 31 oleks esitatud üldistusseosega seotud kitsendus<br />
"{Mandatory, Or}". "{Mandatory}" tähendab, et iga isik peab olema ka mingit<br />
alamtüüpi (üliõpilane, tööta<strong>ja</strong>). "{Or}" tähendab, et isik saab olla kas üliõpilane<br />
või tööta<strong>ja</strong>, aga mitte mõlemat korraga.<br />
7.1.2.2 Osa-terviku seos<br />
Agregatsioon esitab osa-terviku seost olemitüüpide vahel kus üks<br />
olemitüüpidest esitab osa <strong>ja</strong> teine tervikut. Üks osa võib kuuluda mitmesse<br />
54
TTÜ: Andmebaaside projekteerimine.<br />
Strateegiline analüüs <strong>ja</strong> detailanalüüs (2012)<br />
© Erki Eessaar<br />
tervikusse ning osa võib eksisteerida ka ilma tervikuta. Näiteks iga meeskond<br />
kuulub nulli või rohkemasse liigasse <strong>ja</strong> igasse liigasse peab kuuluma<br />
vähemalt kolm meeskonda. Larman (2002) märgib, et selline seos eksisteerib<br />
valdavalt abstraktsete, mitte füüsiliste objektide vahel.<br />
Diagrammil esitatakse agregatsiooni seosetüüpi tähistava joone otsas<br />
paikneva seest tüh<strong>ja</strong> rombina (valge rombina), mis paikneb tervikut esitava<br />
olemitüübi poolel. Joonis 32 esitatud diagrammil on tervikuks Liiga <strong>ja</strong> osaks<br />
Meeskond.<br />
<br />
Liiga<br />
0..*<br />
3..*<br />
Joonis 32 Agregatsiooni näide.<br />
<br />
Meeskond<br />
Kompositsioon on osa-terviku seose erijuhus, mille puhul peab osa rollis olev<br />
olem kuuluma täpselt ühte terviku rollis olevasse olemisse. Näiteks sõrmed on<br />
osa täpselt ühest käest (kui just pole tegu siiami kaksikutega) <strong>ja</strong> tellimuse rida<br />
on osa täpselt ühest tellimusest (vt. Joonis 33). Joonis 34 kohaselt peab iga<br />
konkreetne pilet olema kas täpselt ühe broneeringu osa või täpselt ühe ostu<br />
osa. Konkreetne pilet ei tohi korraga kuuluda nii mingisse broneeringusse kui<br />
ka ostu.<br />
Lisaks kehtestab kompositsioon reegli, et terviku rollis oleva olemi<br />
kustutamisel tuleb kustutada ka kõik sellele kuuluvad osa rollis olevad olemid<br />
(Fowler, 2007).<br />
Diagrammil esitatakse kompositsiooni seosetüüpi tähistava joone otsas<br />
paikneva täidetud rombina (musta rombina), mis paikneb tervikut esitava<br />
olemitüübi poolel. Joonis 33 esitatud diagrammil on Tellimus tervik <strong>ja</strong><br />
Tellimuse rida selle osa.<br />
<br />
Tellimus<br />
1<br />
0..*<br />
<br />
Tellimuse_rida<br />
Joonis 33 Kompositsiooni näide.<br />
<br />
Ost<br />
<br />
Pilet<br />
0..1 0..* 0..*<br />
0..1<br />
Joonis 34 Kompositsiooni näide.<br />
<br />
Broneering<br />
Kui kahtlete, kas osa-tervikus seost esitada, siis Larman (2002) soovitab seda<br />
mitte teha. Millal osa-terviku seost kasutada (Larman, 2002)?<br />
• Loogilises mõttes on tegu osa <strong>ja</strong> tervikuga.<br />
• Osa <strong>ja</strong> tervik on seotud eluea kaudu. Osa ei saa eksisteerida ilma<br />
tervikuta. Sellisel juhul on tegu kompositsiooniga.<br />
• Mõned terviku omadused (nt. asukoht) või käitumised (nt. kustutamine)<br />
kanduvad üle ka osadele.<br />
55
TTÜ: Andmebaaside projekteerimine.<br />
Strateegiline analüüs <strong>ja</strong> detailanalüüs (2012)<br />
© Erki Eessaar<br />
7.1.3 Nimedest<br />
Kasutage olemitüüpide, atribuutide <strong>ja</strong> seosetüüpide nimetamisel sisulisi,<br />
infosüsteemi tulevastele kasuta<strong>ja</strong>tele arusaadavaid nimesid. Nii saavad ka<br />
nemad mudelite ülevaatamisel osaleda.<br />
Kasutage olemitüüpide nimedes ainsuse vorme, sest nii on hiljem lihtsam<br />
määrata seosetüüpidega seotud võimsustikke. Oletame, et süsteemi<br />
kirjeldavad lausendid: Iga õppejõud õpetab null või rohkem õppeainet. Iga<br />
õppeainet õpetab null või rohkem õppejõudu. Iga õppejõudu iseloomustab<br />
perenimi. Iga õppeainet iseloomustab nimi.<br />
Joonis 35 osas a) on ühe olemitüübi nimi mitmuses (Õppeained) <strong>ja</strong> sellest<br />
tulenevalt on võimsustiku määramisel langetatud vale otsus. Joonise osa b)<br />
esitab korrektse mudeli.<br />
a)<br />
<br />
Õppejõud<br />
perenimi : String<br />
õpetab<br />
0..1 0..1<br />
<br />
Õppeained<br />
nimi : String<br />
Ebaõige<br />
võimsustik<br />
b)<br />
<br />
Õppejõud<br />
perenimi : String<br />
õpetab<br />
0..*<br />
0..*<br />
<br />
Õppeaine<br />
nimi : String<br />
Joonis 35 Võimsustike määramine.<br />
Ärge lähtuge nimetamisel andmebaasisüsteemide tehnilistest piirangutest<br />
nagu: nimi ei tohi olla pikem kui 30 märki, ei tohi sisaldada täpitähti. Pidage<br />
meeles, et kontseptuaalne andmemudel on mittetehniline mudel, mille põh<strong>ja</strong>l<br />
võib luua tehnilise kavandi väga erinevate platvormide <strong>ja</strong>oks.<br />
7.1.4 Ei ole ühte ainuõiget mudelit<br />
Rõhutame, et kontseptuaalse andmemudeli koostamisel võivad erinevad<br />
modelleeri<strong>ja</strong>d koostada sama lähteinformatsiooni põh<strong>ja</strong>l erinevad mudelid,<br />
mis kõik annavad edasi va<strong>ja</strong>liku informatsiooni<br />
Oletame, et tuleb koostada kontseptuaalne andmemudel järgneva<br />
spetsifikatsiooni põh<strong>ja</strong>l: Iga klient esitab null või rohkem tellimust. Iga tellimus<br />
on esitatud täpselt ühe kliendi poolt. Iga tööta<strong>ja</strong> kinnitab null või rohkem<br />
tellimust. Iga tellimus kinnitatakse null või ühe tööta<strong>ja</strong> poolt. Klient on isik.<br />
Tööta<strong>ja</strong> on isik.<br />
Järgnev joonis esitab kaks võimalikku olemi-suhte diagrammi, mida sellise<br />
spetsifikatsiooni põh<strong>ja</strong>l võib koostada.<br />
56
TTÜ: Andmebaaside projekteerimine.<br />
Strateegiline analüüs <strong>ja</strong> detailanalüüs (2012)<br />
© Erki Eessaar<br />
a)<br />
b)<br />
<br />
Isik<br />
esitab<br />
+klient<br />
1 0..*<br />
+tööta<strong>ja</strong><br />
0..1 0..*<br />
kinnitab<br />
<br />
Tellimus<br />
<br />
Isik<br />
<br />
Tööta<strong>ja</strong><br />
<br />
Klient<br />
1<br />
esitab<br />
0..*<br />
<br />
Tellimus<br />
0..1<br />
kinnitab<br />
0..*<br />
Joonis 36 Alternatiivsete modelleerimisviiside näide.<br />
Variandis a on näidatud olemitüüpide rollid seosetüüpide kontekstis. Variandis<br />
b aga esitatakse rollid olemitüüpidena.<br />
Nagu näete, on variant a) kompaktsem. Variant b võiks olla eelistatum kui<br />
olemitüüpidel Tööta<strong>ja</strong> <strong>ja</strong>/või Klient on oma spetsiifilisi atribuute või seosetüüpe<br />
(mis ei käi kõigi isikute kohta). Samuti lihtsustab variant b) kitsenduste<br />
esitamist. Näiteks, kui kehtib reegel, et iga isik peab olema kas tööta<strong>ja</strong> või<br />
klient, aga ta ei tohi olla mõlemat korraga, siis saab üldistusseosele lisada<br />
kitsenduse {Mandatory; Or} (vt. peatükk 7.1.2.1).<br />
57
TTÜ: Andmebaaside projekteerimine.<br />
Strateegiline analüüs <strong>ja</strong> detailanalüüs (2012)<br />
© Erki Eessaar<br />
7.1.5 Olemitüüpide liigitus<br />
Olemitüüpe on võimalik liigitada selle järgi, kuidas identifitseeritakse<br />
nendesse tüüpidesse kuuluvaid olemeid.<br />
Nõrk olemitüüp on olemitüüp, millesse kuuluvate olemite eksistents sõltub<br />
mõnda teise olemitüüpi kuuluvate olemite eksistentsist (Connolly <strong>ja</strong> Begg,<br />
2002). Seda tüüpi olem ei saa eksisteerida ilma mõne teise olemita. Seda<br />
tüüpi olem ei saa eksisteerida ilma mõne teise olemita. Kui olemitüüp OT on<br />
nõrk, siis sellesse kuuluvate olemite identifitseerimiseks ei piisa OT<br />
atribuutide väärtustest. Sellise olemi identifitseerimiseks on va<strong>ja</strong> kasutada ka<br />
selle seoseid teiste olemitega.<br />
Näiteks on nõrgad olemitüübid:<br />
• Joonis 9 esitatud olemitüüp Õpetamine. Õpetamine seob õppejõu <strong>ja</strong><br />
õppeaine ning ei saa eksisteerida ilma, et eksisteeriksid õppejõud <strong>ja</strong><br />
õppeaine.<br />
• Joonis 31 esitatud olemitüübid Tööta<strong>ja</strong> <strong>ja</strong> Üliõpilane. Tööta<strong>ja</strong> <strong>ja</strong> üliõpilane<br />
on isikud.<br />
• Error: Reference source not found esitatud olemitüüp Tellimuse_rida.<br />
Tellimuse rida on tellimuse osa <strong>ja</strong> ei saa eksisteerida ilma tellimuseta.<br />
Tugev olemitüüp on olemitüüp, millesse kuuluvate olemite eksistents ei sõltu<br />
mõnda teise olemitüüpi kuuluvate olemite eksistentsist (Connolly <strong>ja</strong> Begg,<br />
2002). Näiteks Joonis 9 esitatud diagrammil on tugevad olemitüübid<br />
Haridusaste_liik, Õppejõud, Õppeaine <strong>ja</strong> Õppeaine_seisundi_liik.<br />
Kui olemitüüp OT on tugev, siis sellesse kuuluvate olemite identifitseerimiseks<br />
piisab OT atribuutide väärtustest. Näiteks konkreetse õppeaine<br />
identifitseerimiseks piisab atribuudi ainekood väärtusest.<br />
Codd (1979) esitab veel ühe võimaliku olemitüüpide liigituse:<br />
• Kernel. Olemitüübid, millesse kuuluvad olemid võivad eksisteerida<br />
sõltumata teiste olemite olemasolust. Joonis 9 esitatud diagrammil on<br />
kernelid Haridusaste_liik, Õppejõud, Õppeaine <strong>ja</strong> Õppeaine_seisundi_liik.<br />
• Kirjeldav olemitüüp. Seda tüüpi olemite peamine eesmärk on<br />
iseloomustada / kirjeldada teisi olemeid. Nende eksistents sõltub<br />
olemitest, mida nad iseloomustavad. Kirjeldava olemitüübi näiteks on<br />
Joonis 15 esitatud olemitüüp e_mail.<br />
• Assotsiatsioon. Olemitüüp, mis esitab mitu-mitu seoseid. Joonis 9 esitatud<br />
diagrammil on assotsiatsioon Õpetamine.<br />
58
viib läbi reserveerimise<br />
TTÜ: Andmebaaside projekteerimine.<br />
Strateegiline analüüs <strong>ja</strong> detailanalüüs (2012)<br />
© Erki Eessaar<br />
7.1.6 Olemi-suhte diagrammi erinevad notatsioonid<br />
- Chen<br />
- Barker<br />
- IE (Information Engineering)<br />
- IDEF1X (Integration DEFinition for Information Modeling)<br />
- UML (Unified Modeling Language)<br />
7.1.6.1 Chen<br />
ma<strong>ja</strong> tänav linn postikood riik<br />
hotelli_<br />
nimi<br />
aadress<br />
hotelli_nr<br />
eesnimi<br />
perenimi<br />
alguse_<br />
aeg<br />
lopu_aeg<br />
kommentaar<br />
hind<br />
nimi<br />
sugu<br />
Hotell<br />
1<br />
Reserveerimine<br />
Isik<br />
isiku_nr<br />
Sisaldab<br />
M<br />
reserveeritakse<br />
reserveerib<br />
N<br />
o<br />
ruumi_nr<br />
Ruum<br />
M<br />
Külaline<br />
hind<br />
tüüp<br />
P<br />
sünni_<br />
aeg<br />
külalise_<br />
nr<br />
Amet<br />
1<br />
Töötab<br />
M<br />
Tööta<strong>ja</strong><br />
1 M<br />
tööta<strong>ja</strong>_<br />
nr<br />
nimetus<br />
ameti_nr<br />
Juhendab<br />
Joonis 37 Olemi-suhte diagrammi esitus Chen’i notatsioonis.<br />
59
TTÜ: Andmebaaside projekteerimine.<br />
Strateegiline analüüs <strong>ja</strong> detailanalüüs (2012)<br />
© Erki Eessaar<br />
7.1.6.2 Barker<br />
Hotell<br />
# hotelli_nr<br />
*hotelli_nimi<br />
*aadress<br />
Amet<br />
#ameti_nr<br />
*nimetus<br />
töötab<br />
juhatab<br />
Isik<br />
#isiku_nr<br />
*eesnimi<br />
*perenimi<br />
¤ sugu<br />
Tööta<strong>ja</strong><br />
#tööta<strong>ja</strong>_nr<br />
¤ juhata<strong>ja</strong><br />
Külaline<br />
#külalise_nr<br />
*sünni_aeg<br />
sisaldab<br />
viib läbi<br />
reserveerimise<br />
Ruum<br />
#hotelli_nr<br />
#ruumi_nr<br />
*tüüp<br />
*hind<br />
reserveeritakse<br />
Reserveerimine<br />
#külalise_nr<br />
#hotelli_nr<br />
#ruumi_nr<br />
#tööta<strong>ja</strong>_nr<br />
*alguse_aeg<br />
¤ lopu_aeg<br />
¤ kommentaar<br />
¤ hind<br />
reserveerib<br />
Joonis 38 Olemi-suhte diagrammi esitus Barkeri notatsioonis.<br />
60
TTÜ: Andmebaaside projekteerimine.<br />
Strateegiline analüüs <strong>ja</strong> detailanalüüs (2012)<br />
© Erki Eessaar<br />
7.1.6.3 IE (Information Engineering)<br />
Amet<br />
ameti_nr<br />
nimetus<br />
ametis töötab /<br />
omab ametit<br />
Isik<br />
isiku_nr<br />
eesnimi<br />
perenimi<br />
sugu<br />
Hotell<br />
hotelli_nr<br />
hotelli_nimi<br />
aadress<br />
Tööta<strong>ja</strong><br />
tööta<strong>ja</strong>_nr (FK)<br />
ameti_nr (FK)<br />
juhata<strong>ja</strong> (FK)<br />
sisaldab /<br />
sisaldub<br />
viib läbi<br />
reserveerimise<br />
juhendab /<br />
juhendatakse<br />
Ruum<br />
hotelli_nr (FK)<br />
ruumi_nr<br />
tüüp<br />
hind<br />
reserveeritakse<br />
Reserveerimine<br />
külalise_nr (FK)<br />
hotelli_nr (FK)<br />
ruumi_nr (FK)<br />
tööta<strong>ja</strong>_nr (FK)<br />
alguse_aeg<br />
lopu_aeg<br />
kommentaar<br />
/hind<br />
reserveerib<br />
Külaline<br />
külalise_nr (FK)<br />
sünni_aeg<br />
Joonis 39 Olemi-suhte diagrammi esitus IE notatsioonis.<br />
7.1.6.4 IDEF1X (Integration DEFinition for Information Modeling)<br />
Amet<br />
ameti_nr<br />
nimetus<br />
ametis töötab /<br />
omab ametit<br />
Isik<br />
isiku_nr<br />
eesnimi<br />
perenimi<br />
sugu<br />
Hotell<br />
hotelli_nr<br />
hotelli_nimi<br />
aadress<br />
Tööta<strong>ja</strong><br />
tööta<strong>ja</strong>_nr (FK)<br />
juhata<strong>ja</strong> (FK)<br />
ameti_nr (FK)<br />
sisaldab /<br />
sisaldub<br />
viib läbi<br />
reserveerimise<br />
juhendab /<br />
juhendatakse<br />
Ruum<br />
hotelli_nr (FK)<br />
ruumi_nr<br />
tüüp<br />
hind<br />
reserveeritakse<br />
Reserveerimine<br />
külalise_nr (FK)<br />
hotelli_nr (FK)<br />
ruumi_nr (FK)<br />
tööta<strong>ja</strong>_nr (FK)<br />
alguse_aeg<br />
lopu_aeg<br />
kommentaar<br />
/hind<br />
reserveerib<br />
Külaline<br />
külalise_nr (FK)<br />
sünni_aeg<br />
Joonis 40 Olemi-suhte diagrammi esitus IDEF1X notatsioonis.<br />
61
TTÜ: Andmebaaside projekteerimine.<br />
Strateegiline analüüs <strong>ja</strong> detailanalüüs (2012)<br />
© Erki Eessaar<br />
Isik<br />
PK<br />
isiku_nr<br />
Hotell<br />
Amet<br />
eesnimi<br />
perenimi<br />
sugu<br />
PK<br />
hotelli_nr<br />
PK<br />
ameti_nr<br />
nimi<br />
ma<strong>ja</strong><br />
tänav<br />
linn<br />
postikood<br />
riik<br />
nimetus<br />
Tööta<strong>ja</strong><br />
PK,FK1<br />
tööta<strong>ja</strong> _nr<br />
FK2<br />
ameti_nr<br />
Ruum<br />
Reserveerimine<br />
PK<br />
PK,FK1<br />
FK2<br />
ruumi_nr<br />
hotell_id<br />
hind<br />
tüübi_nr<br />
PK,FK1<br />
PK,FK1<br />
PK,FK2<br />
PK<br />
FK3<br />
ruumi_nr<br />
hotell_id<br />
külalise_nr<br />
alguse_aeg<br />
lõpu_aeg<br />
kommentaar<br />
tööta<strong>ja</strong>_nr<br />
Külaline<br />
PK,FK1 külalise_nr<br />
sünni_aeg<br />
Tüüp<br />
PK<br />
tüübi_nr<br />
nimetus<br />
Joonis 41 Olemi-suhte diagrammi esitus IDEF1X notatsioonis.<br />
62
TTÜ: Andmebaaside projekteerimine.<br />
Strateegiline analüüs <strong>ja</strong> detailanalüüs (2012)<br />
© Erki Eessaar<br />
7.1.6.5 UML (Unified Modeling Language)<br />
Joonis 42 Olemi-suhte diagrammi esitus UML notatsioonis.<br />
Joonisel 42 olev diagramm on joonistatud CASE vahendiga Rational-Rose.<br />
7.1.7 Olemi-suhte diagrammi puudused <strong>ja</strong> probleemid<br />
• Diagrammi elementide (olemitüüpide, seosetüüpide, atribuut) tähenduses<br />
<strong>ja</strong> definitsioonides pole siiani täpselt kokku lepitud. Mis ühe <strong>ja</strong>oks on<br />
olemitüüp, see on teise <strong>ja</strong>oks atribuut või seosetüüp.<br />
• Aegade jooksul on kasutusel olnud (<strong>ja</strong> on siiani) palju erinevaid notatsioone<br />
(märgisüsteeme), mida olemi-suhte diagrammide koostamiseks on<br />
kasutatud. Erinevates notatsioonides on diagrammidel lubatud erinevat<br />
tüüpi elemendid – näiteks IE <strong>ja</strong> IDEF1X notatsioonis diagrammidel<br />
näidatakse välisvõtmeid.<br />
• Pole piisavalt väljendusrikas. Palju informatsiooni (nt. andmetega seotud<br />
kitsenduste kohta) on võimalik esitada ainult diagrammiga kaasa tulevate<br />
tekstiliste kirjeldustega.<br />
63
TTÜ: Andmebaaside projekteerimine.<br />
Strateegiline analüüs <strong>ja</strong> detailanalüüs (2012)<br />
© Erki Eessaar<br />
7.2 Kontseptuaalse andmemudeli koostamise meetodeid<br />
Kontseptuaalse andmemudeli võib esitada olemi-suhte diagrammi <strong>ja</strong><br />
olemitüüpide ning atribuutide dokumentatsiooni abil.<br />
Millised on kontseptuaalse andmemudeli loomise sammud, kui kasutatakse<br />
olemi-suhte diagramme? Connolly <strong>ja</strong> Begg (2002) nimetavad samme.<br />
• Täpsustatakse olemitüübid.<br />
• Täpsustatakse seosetüübid.<br />
• Määratakse kõik teadaolevad atribuudid <strong>ja</strong> seostatakse need<br />
olemitüüpidega.<br />
• Määratakse atribuutide tüübid.<br />
• Leitakse unikaalsed identifikaatorid.<br />
• Eemaldatakse mudelist liiasused.<br />
• Kontrollitakse mudeli kvaliteeti.<br />
7.2.1 Olemitüüpide <strong>ja</strong> seosetüüpide leidmine<br />
Olemitüüpide <strong>ja</strong> seosetüüpide leidmiseks võib kasutada järgmiseid meetodeid<br />
<strong>ja</strong> nende kombinatsioone.<br />
• Lausendite meetod.<br />
• Olemitüüpide suhestamise meetod.<br />
• Mustrite otsimise meetod.<br />
Vaatleme järgnevalt neid meetodeid lähemalt.<br />
7.2.1.1 Lausendite meetod<br />
Lausend on lihtlause, mis kirjeldab loodavat süsteemi. Lausend on abivahend,<br />
mis aitab süsteemi kergemini analüüsida. Lausend on üldistatud väide reaalse<br />
maailma olemite kohta.<br />
Täpsemalt nimetatakse lausendiks "alusest, öeldisest <strong>ja</strong> sihitisest või<br />
määrusest koosnevat lihtlauset juhtumil, kus on võimalik iga selle lause liiget<br />
käsitleda iseseisva omavahel suhestatud hulgana (elementide arv on suurem<br />
kui 2)." (Mikli, 1999)<br />
Kuidas kasutada lausendeid andmebaasi projekteerimiseks? Nimisõnadest<br />
tulenevad olemitüübid või atribuudid <strong>ja</strong> tegusõnades e. verbidest seosetüübid.<br />
Vaatleme näitena lausendeid dokumentide haldamise süsteemi kohta.<br />
Vaatleme näitena lausendeid dokumentide haldamise süsteemi kohta.<br />
• Dokument on mingit tüüpi.<br />
• Joonistus on dokument.<br />
• Aruanne on dokument.<br />
• Dokumendist on mitmeid koopiaid.<br />
• Dokument asub asukohas.<br />
• Riiul on asukoht.<br />
• Dokument on mingil teemal.<br />
• Isik on osapool.<br />
64
TTÜ: Andmebaaside projekteerimine.<br />
Strateegiline analüüs <strong>ja</strong> detailanalüüs (2012)<br />
© Erki Eessaar<br />
• Organisatsioon on osapool.<br />
• Osapool on dokumendi autor.<br />
• Osapool saab dokumendi koopia.<br />
• Isik töötab ametikohtadel.<br />
• Teatud tüüpi dokument tuleb saata teatud tüüpi ametikohal tööta<strong>ja</strong>le.<br />
Lausenditele vastav olemi-suhte diagramm, kus on täpsustatud ka<br />
seosetüüpide omadused.<br />
<br />
Asukoht<br />
<br />
Riiul<br />
<br />
Teema<br />
<br />
1 0..*<br />
Koopia<br />
0..*<br />
0..*<br />
0..* <br />
Autor<br />
1..*<br />
0..*<br />
<br />
Joonistus<br />
1<br />
1..*<br />
1..*<br />
<br />
Dokument<br />
0..*<br />
<br />
Aruanne<br />
1<br />
<br />
Dokumendi tüüp<br />
<br />
Organisatsioon<br />
0..*<br />
<br />
Osapool<br />
<br />
Isik<br />
0..*<br />
1..*<br />
<br />
Ametikoht<br />
0..*<br />
Joonis 43 Olemi-suhte diagrammi näide.<br />
Kontseptuaalse andmemudeli (sealhulgas olemi-suhte diagrammi)<br />
koostamisel võiks lähtuda järgnevatest põhimõtetest (Larman, 2002).<br />
• Kasutage olemitüüpide/atribuutide/seosetüüpide nimedena termineid, mis<br />
on kasutusel organisatsioonis millele andmebaasi luuakse.<br />
• Jätke vaatluse alt väl<strong>ja</strong> ebaoluline. Pidage meeles, et kontseptuaalses<br />
andmemudelis tuleb ka<strong>ja</strong>stada sellised <strong>ja</strong> ainult sellised olemitüübid /<br />
atribuudid / seosetüübid, millele vastavaid andmeid on va<strong>ja</strong> hoida<br />
andmebaasis.<br />
7.2.1.2 Olemitüüpide suhestamise meetod<br />
Olemitüüpide <strong>ja</strong> seosetüüpide leidmiseks võib kasutada ka olemitüüpide<br />
suhestamise meetodit. Olemitüüpide suhestamise meetodi kohaselt viiakse<br />
läbi olemitüüpide <strong>ja</strong> seosetüüpide nimistuline süntees. "Üheks mõtlemisviisiks<br />
modelleerimisel <strong>ja</strong> diagrammide koostamisel on objektide (andmeobjektide)<br />
nimistuline süntees <strong>ja</strong> nende hilisem suhestamine. Otsime <strong>ja</strong> kaardistame<br />
süsteemi mõisted, mis võiksid vastata olulistele andmeobjektidele." (Mikli,<br />
1999)<br />
Võib leiduda kategooriaid millele ei leita uuritava süsteemi korral ühtegi<br />
vastavat olemitüüpi või seosetüüpi. Iga seosetüüp või olemitüüp võib kuuluda<br />
mitmesse kategooriasse.<br />
65
TTÜ: Andmebaaside projekteerimine.<br />
Strateegiline analüüs <strong>ja</strong> detailanalüüs (2012)<br />
© Erki Eessaar<br />
Olemitüüpide suhestamise meetodi kasutamisel võib võtta aluseks<br />
olemitüüpide <strong>ja</strong> seosetüüpide kategooriate nimekir<strong>ja</strong>d. Larman (2002)<br />
kirjeldab selliste nimekir<strong>ja</strong>de kasutamist kui ühte domeenimudel koostamise<br />
meetodit. Domeenimudel on aluseks objekt-orienteeritud tarkvara disaini<br />
korral tarkvaraklasside leidmisele. Kuid selline meetod on edukalt rakendatav<br />
ka kontseptuaalse andmemudeli koostamisel.<br />
Kuidas leida kategooriatesse kuuluvaid olemitüüpe <strong>ja</strong> seosetüüpe? Tuleb<br />
uurida süsteemi kirjeldusi nagu organisatsiooniga seotud dokumendid,<br />
kasuta<strong>ja</strong>te intervjuude protokollid, lausendid, kasutusjuhtude tekstikirjeldused,<br />
domeenimudel, kasuta<strong>ja</strong>te infova<strong>ja</strong>duste (päringute) kirjeldused. Samuti tuleb<br />
kasutada oma teadmisi maailma <strong>ja</strong> reaalsete süsteemide toimimise kohta.<br />
Tabel 9 Olemitüüpide kategooriad.<br />
Olemitüübi<br />
kategooria (Larman,<br />
2002)<br />
füüsilised objektid<br />
spetsifikatsioonid,<br />
as<strong>ja</strong>de kirjeldused<br />
asukohad<br />
rollid<br />
konteinerid, mis<br />
sisaldavad teisi<br />
objekte<br />
as<strong>ja</strong>d konteineris<br />
teised arvuti või<br />
elektromehhaanilised<br />
süsteemid, mis on<br />
väl<strong>ja</strong>spool<br />
vaadeldavat<br />
süsteemi<br />
abstraktsed<br />
nimisõnad<br />
organisatsioonid (<strong>ja</strong><br />
nende alamosad)<br />
sündmused<br />
Näited lennunduse (Larman, 2002), ülikooli <strong>ja</strong><br />
dokumendihalduse süsteemi põh<strong>ja</strong>l<br />
Lennundus: lennuk<br />
Ülikool: õpik, õppevahend, auditoorium<br />
Dokument: koopia (füüsiliselt paberkand<strong>ja</strong>l), isik<br />
Lennundus: lennu kirjeldus<br />
Ülikool: õppeaine kirjeldus e. ainekaart<br />
Dokument: teema, dokumendi tüüp, ametikoht.<br />
Lennundus: lennu<strong>ja</strong>am<br />
Ülikool: auditoorium, õppeklass<br />
Dokument: asukoht, riiul<br />
Lennundus: piloot, reisi<strong>ja</strong><br />
Ülikool: õppejõud, õppetooli juhata<strong>ja</strong>, üliõpilane<br />
Dokument: autor<br />
Lennundus: lennuk<br />
Ülikool: auditoorium<br />
Dokument: riiul<br />
Lennundus: reisi<strong>ja</strong> (on lennukis)<br />
Ülikool: õppejõud, üliõpilane (on auditooriumis)<br />
Dokument: koopia (on riiulis)<br />
Lennundus: lennukontrolli keskus<br />
Lennundus: akrofoobia (kõrguse kartus)<br />
Dokument: osapool<br />
Lennundus: lennukompanii<br />
Ülikool: õppetool<br />
Dokument: organisatsioon<br />
Lennundus: õhku tõusmine, allakukkumine,<br />
hädamaandumine, korraline maandumine<br />
66
TTÜ: Andmebaaside projekteerimine.<br />
Strateegiline analüüs <strong>ja</strong> detailanalüüs (2012)<br />
Olemitüübi<br />
kategooria (Larman,<br />
2002)<br />
protsessid<br />
reeglid <strong>ja</strong> poliitikad<br />
kataloogid<br />
juhendid,<br />
dokumendid,<br />
raamatud<br />
finantsinstrumendid<br />
<strong>ja</strong> teenused<br />
© Erki Eessaar<br />
Näited lennunduse (Larman, 2002), ülikooli <strong>ja</strong><br />
dokumendihalduse süsteemi põh<strong>ja</strong>l<br />
Lennundus: lennule koha kinni panemine<br />
Ülikool: õppimine, teadmiste kontrolli läbiviimine,<br />
aine õpetamine<br />
Dokument: dokumendi koopia saatmine<br />
Lennundus: lennu tühistamise reeglid, lennule kinni<br />
pandud kohast loobumise reeglid<br />
Ülikool: eksmatrikuleerimise reeglid, hindamisreeglid<br />
Lennundus: lennuki osade kataloog<br />
Lennundus: lennuki parandamise juhend<br />
Ülikool: eksami läbiviimise juhend<br />
Dokument: dokument, joonistus, aruanne<br />
Olemitüüpide vaheliste seosetüüpide leidmiseks tuleb koostada seosetüüpide<br />
nimekiri, mõeldes erinevatele seosetüüpide kategooriatele. Seosetüübis<br />
osalevad olemitüübid valitakse olemitüüpide nimekir<strong>ja</strong>st. Seosetüüpide<br />
otsimise käigus on võimalik leida ka uusi olemitüüpe.<br />
Tabel 10 Seosetüüpide kategooriad.<br />
Seosetüübi kategooria Näited lennunduse (Larman, 2002), ülikooli <strong>ja</strong><br />
(Larman, 2002)<br />
dokumendihalduse süsteemi põh<strong>ja</strong>l<br />
A on B füüsiline osa Lennundus: tiib – lennuk<br />
A on B loogiline osa Lennundus: õhkutõusmine – lennureis<br />
A sisaldub füüsiliselt B-s Lennundus: reisikirjelduse dokument –<br />
reisikirjelduste kaust<br />
lennuki reisi<strong>ja</strong> – lennuk (lennuk on nagu<br />
konteiner, mis sisaldab reisi<strong>ja</strong>t)<br />
Dokument: koopia – asukoht<br />
A sisaldub loogiliselt B-s Lennundus: lend – lennuplaan<br />
A on B kirjeldus<br />
Lennundus: lennu kirjeldus (lennu<br />
spetsifikatsioon) – lend mingil konkreetsel<br />
päeval<br />
Dokument: dokument – koopia<br />
dokumendi tüüp – dokument<br />
A salvestatakse B-s Lennundus: reserveerimine – reisikirjeldus<br />
A on B liige<br />
Lennundus: piloot – lennufirma<br />
A on B<br />
Lennundus: lennukite hoolduse allüksus –<br />
organisatsiooniline lennufirma<br />
allüksus<br />
A kasutab või haldab B-d Lennundus: piloot – lennuk<br />
Dokument: autor – koopia<br />
osapool – koopia<br />
ametikoht – dokumendi tüüp<br />
A suhtleb B-ga<br />
A on seotud protsessiga<br />
B<br />
Lennundus: klienditeeninda<strong>ja</strong> – reisi<strong>ja</strong><br />
Lennundus: reisi<strong>ja</strong> – pileti ostmine<br />
67
TTÜ: Andmebaaside projekteerimine.<br />
Strateegiline analüüs <strong>ja</strong> detailanalüüs (2012)<br />
Seosetüübi kategooria<br />
(Larman, 2002)<br />
protsessid A <strong>ja</strong> B on<br />
seotud<br />
A järgneb B-le<br />
A on B omanik<br />
A on B üldistus<br />
© Erki Eessaar<br />
Näited lennunduse (Larman, 2002), ülikooli <strong>ja</strong><br />
dokumendihalduse süsteemi põh<strong>ja</strong>l<br />
Lennundus: pileti reserveerimine – pileti<br />
reserveerimise tühistamine, pileti reserveerimine<br />
– maksmine<br />
Lennundus: linn – linn (lennuk lendab linnast<br />
linna)<br />
Lennundus: lennufirma – lennuk<br />
Lennundus: transpordifirma – lennufirma<br />
Dokument: osapool – isik<br />
osapool – organisatsioon<br />
osapool – autor<br />
asukoht – riiul<br />
Kontseptuaalse andmemudeli koostamise käigus tuleb ka kindlaks määrata <strong>ja</strong><br />
kirjeldada seosetüüpide omadused.<br />
7.2.2 Seosetüüpide probleemid<br />
Millised on võimalikud olemi-suhte diagrammil seosetüüpidega tekkivad<br />
probleemid (inglise keeles connection trap problems)? Nende probleemide<br />
ühine tunnus on, et probleemse mudeli järgi kavandatud andmebaasis jääksid<br />
seosed teatud olemite vahel ebaselgeks.<br />
Tutvume kõigepealt lehviku probleemiga (inglise keeles fan-trap problem).<br />
Vaatleme näitena andmebaasi kus hoitavaid andmeid iseloomustavad<br />
lausendid: Tööta<strong>ja</strong> töötab harukontoris. Harukontor sisaldab osakondi<br />
(Connolly <strong>ja</strong> Begg, 2002). Joonis 44 esitatud olemi-suhte diagrammi põh<strong>ja</strong>l<br />
loodud andmebaasist ei saaks me teada, millises osakonnas tööta<strong>ja</strong> töötab.<br />
Tööta<strong>ja</strong> töötab küll ühes kindlas harukontoris, kuid harukontor sisaldab samal<br />
a<strong>ja</strong>l ka üks või rohkem osakonda.<br />
Joonis 44 "Lehviku probleemi" näide.<br />
Probleemi lahendamiseks tuleks luua andmebaas Joonis 45 esitatud olemisuhte<br />
diagrammi põh<strong>ja</strong>l. Pange tähele, et sellisel viisil loodud andmebaasist<br />
on võimalik endiselt üheselt teada saada millises harukontoris tööta<strong>ja</strong> töötab,<br />
sest iga tööta<strong>ja</strong> on seotud täpselt ühe osakonnaga <strong>ja</strong> iga osakond on seotud<br />
täpselt ühe harukontoriga.<br />
Joonis 45 "Lehviku probleemi" lahendus.<br />
68
TTÜ: Andmebaaside projekteerimine.<br />
Strateegiline analüüs <strong>ja</strong> detailanalüüs (2012)<br />
© Erki Eessaar<br />
Joonis 45 esitatud lahenduse eelduseks on, et iga tööta<strong>ja</strong> peab töötama<br />
täpselt ühes osakonnas. Kui leidub tööta<strong>ja</strong>id, kes töötavad küll harukontoris,<br />
kuid ei ole tööta ühegi osakonna alluvuses, siis tekib kuristiku probleem.<br />
Tutvume järgnevalt kuristiku probleemiga (inglise keeles chasm-trap<br />
problem). Vaatleme näitena andmebaasi kus hoitavaid andmeid<br />
iseloomustavad lausendid: Tööta<strong>ja</strong> töötab osakonnas. Tööta<strong>ja</strong> kasutab<br />
ametiautosid.<br />
Kui ametiautot pole veel tööta<strong>ja</strong> käsutusse antud, siis Joonis 46 esitatud<br />
olemi-suhte diagrammi põh<strong>ja</strong>l loodud andmebaasist ei saa teada, millisele<br />
osakonnale see auto kuulub.<br />
<br />
Osakond<br />
töötab<br />
1<br />
0..*<br />
<br />
Tööta<strong>ja</strong><br />
kasutab<br />
0..1<br />
+kasuta<strong>ja</strong><br />
Joonis 46 Kuristiku probleemi näide.<br />
0..*<br />
<br />
Ametiauto<br />
Probleemi lahendamiseks tuleks luua andmebaas Joonis 47 esitatud olemisuhte<br />
diagrammi põh<strong>ja</strong>l. Erinevalt Joonis 46 on ette nähtud täiendav<br />
seosetüüp olemitüüpide Osakond <strong>ja</strong> Ametiauto vahel. Ametiauto on seotud<br />
täpselt ühe osakonnaga <strong>ja</strong> seetõttu on teada milline osakond on selle omanik<br />
isegi siis, kui seda pole tööta<strong>ja</strong>ga seostatud.<br />
<br />
Osakond<br />
töötab<br />
1 0..*<br />
<br />
Tööta<strong>ja</strong><br />
+kasuta<strong>ja</strong><br />
0..1 kasutab<br />
0..*<br />
<br />
Ametiauto<br />
1<br />
+omanik<br />
omab<br />
Joonis 47 Kuristiku probleemi lahenduse näide.<br />
0..*<br />
Pange tähele, et võib kehtida ärireegel: Tööta<strong>ja</strong> võib kasutada ainult selle<br />
osakonna ametiautosid kus ta töötab. Kui selline reegel kehtib, siis tuleb see<br />
dokumenteerida <strong>ja</strong> andmebaasis kitsendusena jõustada.<br />
7.2.2.1 Mustrite otsimise meetod<br />
Otsitakse sama valdkonna kohta varem koostatud mudeleid, mida saaks uues<br />
projektis ära kasutada. Selliste mudelite kohta on olemas spetsiaalsed<br />
kataloogid (vt. teema 8).<br />
7.2.3 Atribuutide määramine <strong>ja</strong> olemitüüpidega seostamine<br />
Iga leitud olemitüübi kohta tuleb määrata kindlaks millistele selle olemitüübi<br />
omadustele vastavaid andmeid hakatakse andmebaasis säilitatama. Need<br />
omadused tuleb esitada atribuutidena. Olemitüübil on potentsiaalselt väga<br />
palju erinevaid omadusi. Seega iga atribuudi korral tuleb kaaluda, kas leitud<br />
atribuudi väärtuseid on va<strong>ja</strong> andmebaasis hoida. Näiteks kas andmebaasis on<br />
69
TTÜ: Andmebaaside projekteerimine.<br />
Strateegiline analüüs <strong>ja</strong> detailanalüüs (2012)<br />
© Erki Eessaar<br />
va<strong>ja</strong> hoida tööta<strong>ja</strong> perenime? Aga silmade värvi <strong>ja</strong> kinganumbrit? Kui tegemist<br />
on modelliagentuuriga, siis see võib olla täitsa va<strong>ja</strong>lik.<br />
Iga leitud atribuudi korral tuleb ka mõelda, kas leitud atribuut on seotud õige<br />
olemitüübiga. Näiteks loengu toimumise aeg ei ole õppejõu atribuut, sest<br />
õppejõud võib pidada loenguid erinevatel aegadel <strong>ja</strong> erinevates õppeainetes.<br />
Tellitud kauba kogus ei ole kauba atribuut, sest ühte kaupa võivad tellida<br />
paljud erinevad kliendid <strong>ja</strong> nendes tellimustes võib olla erinev kauba kogus.<br />
Iga leitud atribuudi korral tuleb ka mõelda, kas selle taga ei peitu iseseisev<br />
olemitüüp. Kui leitud "atribuudile" leiduvad veel omakorda atribuudid või<br />
soovitakse seda seosetüüpide kaudu siduda mõne teise olemitüübiga, siis<br />
mõistlik oleks see modelleerida eraldiseisva olemitüübina. Näiteks õppeainet<br />
õpetav õppejõud ei ole pigem õppeaine atribuut vaid eraldiseisev olemitüüp<br />
mille atribuudid on näiteks eesnimi, perenimi <strong>ja</strong> sünniaeg.<br />
Füüsilistele <strong>ja</strong> abstraktsetele objektidele vastavatel olemitüüpidel on sageli<br />
atribuudiks aeg. Näiteks üliõpilase on sünniaeg, õppekaval on loomise aeg <strong>ja</strong><br />
kinnitamise aeg.<br />
Sündmustele <strong>ja</strong> protsessidele vastavatel olemitüüpidel on kindlasti atribuudiks<br />
aeg. Sündmusel on toimumise aeg, protsessil on alguse aeg <strong>ja</strong> lõpu aeg.<br />
Kontseptuaalses andmemudelis kirjeldatakse kasuta<strong>ja</strong>le sisulist tähendust<br />
omavad atribuudid. See tähendab, et kontseptuaalses andmemudelis ei<br />
näidata surrogaatvõtmetele vastavaid atribuute.<br />
Oluline on rõhutada, et kontseptuaalses andmemudelis ei leita välisvõtme<br />
atribuute, sest välisvõtmed on seotud relatsioonilise mudeliga.<br />
Kontseptuaalse andmemudeli koostamisel aga ei peeta silmas ühtegi<br />
konkreetset andmemudelit. Kontseptuaalse andmemudeli põh<strong>ja</strong>l on võimalik<br />
koostada erinevaid andmebaasi tehnilisi kirjeldusi, mis põhinevad erinevatel<br />
andmemudelite. Näiteks objekt-orienteeritud andmebaasides luuakse seosed<br />
kasutades viitade kollektsioone <strong>ja</strong> mitte välisvõtmeid.<br />
Joonis 48 <strong>ja</strong> Joonis 49 esitavad ebakorrektseid olemi-suhte diagramme.<br />
Joonis 48 kohaselt on olemitüübis Tellimus nn. välisvõtme atribuut isikukood.<br />
Joonis 49 kohaselt on modelleeritud Isiku <strong>ja</strong> Tellimuse vaheline seosetüüp<br />
kasutades ainult atribuuti (isikukood). Joonis 50 esitab korrektse olemi-suhte<br />
diagrammi.<br />
Joonis 48 Ebakorrektse olemi-suhte diagrammi näide.<br />
70
TTÜ: Andmebaaside projekteerimine.<br />
Strateegiline analüüs <strong>ja</strong> detailanalüüs (2012)<br />
© Erki Eessaar<br />
Joonis 49 Ebakorrektse olemi-suhte diagrammi näide.<br />
Joonis 50 Seosetüüpide korrektne esitamine olemi-suhte diagrammil.<br />
Mitmeväärtuselise atribuudi puhul tuleb otsustada, kas modelleerida see:<br />
- atribuudina,<br />
- eraldi olemitüübina.<br />
Atribuutide otsimise käigus leitakse ka võimalikud tuletisatribuudid. Näiteks<br />
igal tellimusel on null või rohkem tellimuse rida. Olemitüübil Tellimus võib olla<br />
tuletisatribuut ridade_arv, mille väärtus näitab tellimusega seotud tellimuse<br />
ridade arvu.<br />
Connolly <strong>ja</strong> Begg (2002) soovitavad kõigepealt leida kasuta<strong>ja</strong>te nõuete põh<strong>ja</strong>l<br />
atribuutide nimekir<strong>ja</strong>. Seejärel tuleb hakata atribuute olemitüüpide juurde<br />
määrama. Kui üks atribuut kuulub mitme olemitüübi juurde, siis selle põhjus<br />
võib olla üks järgnevatest.<br />
• Oleme leidnud mitu olemitüüpi, mida saab üldistada. Näiteks nii olemitüübi<br />
Tööta<strong>ja</strong> kui ka Üliõpilane atribuut võib olla isikukood. Nende olemitüüpide<br />
üldistus on Isik ning isikukood peaks olema olemitüübi Isik atribuut.<br />
• Oleme leidnud olemitüüpide vahelise seosetüübi. Sellisel juhul tuleks<br />
atribuut seostada vaid ühe olemitüübiga ning tagada, et on loodud ka<br />
vastav seosetüüp. Näiteks nii olemitüübi Klient kui ka Tellimus atribuut<br />
võiks olla kliendi_perenimi. Sellisel juhul tuleks määrata kliendi_perenimi<br />
olemitüübi Klient atribuudiks ning lisada mudelisse seosetüüp, mis<br />
ühendab olemitüüpe Klient <strong>ja</strong> Tellimus.<br />
Sageli on raske otsustada kas modelleerida midagi olemitüübi, seosetüübi või<br />
atribuudina. Seetõttu võivad erinevad projekteeri<strong>ja</strong>d luua erinevaid mudeleid.<br />
Kogemused aitavad luua häid mudeleid. Teiste arenda<strong>ja</strong>te kogemustega<br />
tutvumiseks on kasulik uurida mustreid.<br />
Larman (2002) märgib domeenimudelite koostamisest kirjutades, et kui<br />
kahtled kas modelleerida midagi atribuudi või klassina, siis parem modelleeri<br />
see klassina. Sama nõuanne kehtib ka olemi-suhte diagrammi korral – kui<br />
kahtled kas modelleerida midagi olemitüübi või atribuudina, siis modelleeri<br />
see olemitüübina.<br />
71
TTÜ: Andmebaaside projekteerimine.<br />
Strateegiline analüüs <strong>ja</strong> detailanalüüs (2012)<br />
© Erki Eessaar<br />
7.2.4 Atribuutide tüüpide määramine<br />
Igale leitud atribuudile tuleb määrata tüüp. Tüüp on väärtuste hulk <strong>ja</strong> seeläbi<br />
kirjeldatakse võimalikud väärtused, mida atribuut võib omandada. Larman<br />
(2002) soovitab, et atribuutide tüübid võiksid põhiliselt olla lihtsad tüübid nagu<br />
stringitüüp, kuupäevatüüp või tõeväärtustüüp. Atribuudi dokumenteerimise<br />
juures on väga kasulik esitada üks või mitu selle atribuudi näidisväärtust.<br />
Näidisväärtused aitavad atribuudi tähendust paremini mõista.<br />
7.2.5 Unikaalsete identifikaatorite leidmine<br />
Iga leitud tugeva olemitüübi puhul tuleb määrata kindlaks üks või mitu<br />
unikaalset identifikaatorit. Unikaalne identifikaator hõlmab üks või mitu<br />
atribuuti nii, et nende atribuutide väärtused identifitseerivad unikaalselt iga<br />
vastavat tüüpi olemi.<br />
Kui olemitüüpi OT kuuluva olemi eksistents sõltub mõnest teisest olemist, siis<br />
on tegemist nõrga olemitüübiga. Sellise olemitüübi <strong>ja</strong>oks leitakse unikaalsed<br />
identifikaatorid alles andmebaasi loogilise disaini käigus.<br />
NB! Märkus. Harjutustundides kasutatakse CASE vahendit Rational Rose. Selle puuduseks<br />
on, et klassidiagrammi abil joonistatavas kontseptuaalses andmemudelis ei saa määrata<br />
unikaalseid identifikaatoreid nii, et neid arvestataks hiljem tabelite kirjelduste genereerimisel.<br />
Tabeli kirjelduse loomisel lisatakse igasse tabelisse automaatselt surrogaatvõtme veerg<br />
(selles veerus on unikaalsed, monotoonselt kasvavad arvulised väärtused). Seega tuleks<br />
kontseptuaalse andmemudeli juures dokumenteerida ainult sisulisi atribuute hõlmavad<br />
unikaalsed identifikaatorid <strong>ja</strong> pärast tabelite disaini juures asendada surrogaatvõtmed sisuliste<br />
võtmetega.<br />
Ideaalis peaks saama CASE vahendi abil kontseptuaalses andmemudelis kirjeldada iga<br />
olemitüübi kohta üks või mitu unikaalset identifikaatorit. Tabelite spetsifikatsiooni<br />
genereerimisel peaks saama määrata, millise unikaalse identifikaatori põh<strong>ja</strong>l luuakse<br />
primaarvõti.<br />
7.2.6 Mudelis olevate liiasuste eemaldamine<br />
Liiasuse kontrolli käigus vaadatakse üle üks-ühele (1:1) seosetüübiga seotud<br />
olemitüübid (vt. Joonis 51) <strong>ja</strong> otsustatakse, kas nende asemel ei võiks luua<br />
ühe olemitüübi (st. kas üks olemitüüp <strong>ja</strong> seosetüüp on üleliigsed) (Connolly <strong>ja</strong><br />
Begg, 2002). Uues olemitüübis oleksid kõik algsete olemitüüpide atribuudid.<br />
Antud juhul tuleks kaaluda, kas ei piisaks olemitüübist Kaup, millel on<br />
atribuudid nimetus <strong>ja</strong> kirjeldus.<br />
<br />
Kaup<br />
nimetus : String<br />
1<br />
1<br />
<br />
Kauba kirjeldus<br />
kirjeldus : String<br />
Joonis 51 1:1 seose näide.<br />
Liiasuste kontrolli käigus tuleb eemaldada ka üleliigsed seosetüübid.<br />
Seosetüüp on üleliigne, kui selle poolt kirjeldatavad andmed võib leida teiste<br />
seosetüüpide abil kirjeldatavate andmete põh<strong>ja</strong>l. Näiteks Joonis 52 esitatud<br />
seosetüüp osaleb olemitüüpide Üliõpilane <strong>ja</strong> Teadmiste kontroll vahel on<br />
72
TTÜ: Andmebaaside projekteerimine.<br />
Strateegiline analüüs <strong>ja</strong> detailanalüüs (2012)<br />
© Erki Eessaar<br />
üleliigne, sest seos konkreetse üliõpilase <strong>ja</strong> teadmiste kontrolli vahel tekib<br />
juba läbi õppimise. Üliõpilane ei tohi saata teadmiste kontrollile enda asemel<br />
kedagi teist.<br />
<br />
Üliõpilane<br />
1<br />
+kontrollitav 1 osaleb<br />
1<br />
0..*<br />
<br />
Õppimine<br />
1<br />
0..*<br />
1<br />
<br />
Õppeaine<br />
0..*<br />
0..*<br />
<br />
Teadmiste kontroll<br />
Joonis 52 Üleliigne seosetüüp.<br />
Kui säilitaksime seosetüübi osaleb, siis selle olemi-suhte diagrammi alusel<br />
loodud andmebaasis tuleb jõustada kitsendus, et iga teadmiste kontroll peab<br />
olema otse <strong>ja</strong> läbi õppimise seotud ühe <strong>ja</strong> sama üliõpilasega. Teisalt on<br />
mõningad päringud sellise mudeli alusel loodud andmebaasis lihtsamad.<br />
Näiteks kui soovime päringu tulemuses ühendada üliõpilase <strong>ja</strong> teadmiste<br />
kontrolli andmed, siis ei ole va<strong>ja</strong> päringu avaldises viidata relatsioonilisele<br />
muutu<strong>ja</strong>le/tabelile Oppimine.<br />
Kui taolisi liiasusi sisaldavate mudelite alusel luua andmebaas, siis esineb<br />
selles andmebaasis andmete liiasus. Näiteks oleks Joonis 84 alusel loodud<br />
andmebaasis võimalik tuletada väide üliõpilase teadmiste kontrollis osalemise<br />
kohta kahel erineval viisil.<br />
7.2.7 Mudeli kontroll<br />
Mudel peab olema kvaliteetne. Kuidas kontseptuaalse andmemudeli kvaliteeti<br />
kontrollida? Mudelit peab kontrollima nii sisulisest kui ka kasutatavuse<br />
aspektist.<br />
Kontseptuaalse andmemudeli koostamisega paralleelselt võidakse kirjeldada<br />
kasutusjuhte <strong>ja</strong> andmebaasioperatsioone. Kontseptuaalse andmemudeli<br />
kontrollimiseks tuleb selgitada, kas iga kasutusjuhu <strong>ja</strong><br />
andmebaasioperatsiooni läbiviimiseks on olemas va<strong>ja</strong>likud andmed. Selle<br />
kontrolli läbiviimiseks saab kasutada CRUD maatriksit.<br />
Samuti tuleb loodud mudel vaadata üle koos süsteemi tulevaste kasuta<strong>ja</strong>tega.<br />
Kui kontrollimise tulemusena ilmnevad probleemid, tuleb mudelit täiendada <strong>ja</strong><br />
kontrolli korrata.<br />
Kontseptuaalse andmemudeli sisuliseks kontrollimiseks võib vastata<br />
järgmistele küsimustele (vastus kõigile küsimustele peaks korrektse mudeli<br />
puhul olema "Jah").<br />
• Kas teadmine, mida mudel loob on süsteemi eesmärkide saavutamiseks<br />
piisav?<br />
73
TTÜ: Andmebaaside projekteerimine.<br />
Strateegiline analüüs <strong>ja</strong> detailanalüüs (2012)<br />
© Erki Eessaar<br />
• Kas iga olemitüübi/atribuudi/seosetüübi poolt loodav teadmine on<br />
süsteemi <strong>ja</strong>oks oluline?<br />
• Kas semantika dokumendis on kirjeldatud kõigi olemi-suhte diagrammidel<br />
olevate olemitüüpide <strong>ja</strong> atribuutide semantika?<br />
• Kas kõigile semantika dokumendis kirjeldatud olemitüüpidele/atribuutidele<br />
leidub vastav olemitüüp/atribuut olemi-suhte diagrammis?<br />
• Kas olemitüübi/atribuudi definitsioon aitab olemitüübi/atribuudi poolt<br />
esitatavast mõistest paremini aru saada – kas Te olete peale selle<br />
definitsiooni läbilugemist targem kui enne lugemist?<br />
• Iga atribuudi puhul küsige endalt järgmisi küsimusi.<br />
• Kas see atribuut on selle olemitüübi atribuut?<br />
• Kas on leitud väärtused mida atribuut võib omada – määratud atribuudi<br />
tüüp?<br />
• Kas olete kindel, et atribuuti ei pea esitama iseseisva olemitüübina?<br />
• Kas tuletisatribuudid on diagrammil selgelt väl<strong>ja</strong> toodud?<br />
• Kas olemitüüpides ei eksisteeri atribuutide gruppe? (Nt. aadress1,<br />
aadress2 <strong>ja</strong> aadress3 olemitüübis Isik. Nende põh<strong>ja</strong>l saab luua uue<br />
olemitüübi Aadress <strong>ja</strong> seostada see olemitüübiga Isik.)<br />
• Kas puuduvad välisvõtme atribuudid?<br />
• Iga seosetüübi puhul küsige endalt järgmisi küsimusi.<br />
• Kas iga seosetüübi (v.a üldistusseosed) puhul on määratud tugevus <strong>ja</strong><br />
võimsus?<br />
• Kas igale seosetüübile on antud arusaadav <strong>ja</strong> seosetüüpi kirjeldav nimi<br />
igal pool kus seda on va<strong>ja</strong>?<br />
• Kas olemitüüpide rollid seosetüübi kontekstis on määratud igal pool kus<br />
seda on va<strong>ja</strong>?<br />
• Kui kahe olemitüübi vahel on mitu seosetüüpi, kas siis iga sellise<br />
seosetüübi juures on näidatud vähemalt ühe olemitüübi roll?<br />
• Kas seosetüübi juures määratud olemitüüpide rollid aitavad paremini<br />
mudelit mõista?<br />
• Kas iga üldistusseose puhul on määratud osaluskohustus <strong>ja</strong> kuuluvus?<br />
• Kas seosetüübid on diagrammil seotud välistava kaarega, seal kus seda<br />
on va<strong>ja</strong>?<br />
• Kas mudelist ei eksisteeri lehviku <strong>ja</strong> kuristiku probleeme?<br />
• Kas mudelist on eemaldatud liiasused?<br />
Mudelite koostamisel tuleb pöörata tähelepanu ka nende kasutatavusele.<br />
Mudel on kommunikatsioonivahend, mis aitab süsteemiarenduses osale<strong>ja</strong>tel<br />
oma ideid arusaadavaks muuta. Kui mudel on halvasti loetav, siis ta ei täida<br />
oma eesmärki. Millele tuleks pöörata tähelepanu olemi-suhte diagrammi<br />
koostamisel?<br />
• Pange ühele diagrammile 7+/-2 elementi (olemitüüpi).<br />
• Suurem diagramm <strong>ja</strong>otage väiksemateks (ülekattega) diagrammideks.<br />
Ülekate tähendab, et mõni olemitüüp/seosetüüp võib olla mitmel<br />
diagrammil. See aitab luge<strong>ja</strong>l neid diagramme seostada.<br />
• Olemitüüp võib olla esitatud mitmel diagrammil, kuid näidake<br />
olemitüübi atribuute ainult ühel diagrammil.<br />
• Tõstke kõige kesksematele <strong>ja</strong> olulisematele mõistetele vastavad<br />
olemitüübid esile teise värviga <strong>ja</strong>/või suurema fondiga kui ülejäänud<br />
olemitüübid. Va<strong>ja</strong>dusel kasutage esiletõstmiseks rasvast teksti või<br />
74
TTÜ: Andmebaaside projekteerimine.<br />
Strateegiline analüüs <strong>ja</strong> detailanalüüs (2012)<br />
© Erki Eessaar<br />
rasvaseid jooni. Samas ärge muutke diagrammi kirjuks nagu<br />
pühademuna.<br />
• Kasutage projekti piires ühesuguseid kujundeid (nt. ristkülik olemitüübi<br />
esitamiseks).<br />
• Olemitüüpide nimed võiksid olla ainult ainsuses.<br />
• Mudeli koostamisel kasutage ühte keelt (näiteks eesti või inglise), aga<br />
mitte mitut keelt läbisegi.<br />
• Üldistusseose kolmnurk (mis on suunatud üldisema mõiste poole)<br />
peaks olema alati suunaga üles. See tagab, et ülatüüp on diagrammil<br />
esitatud ülalpool kui selle alamtüübid.<br />
• Hoiduge väga pikkadest joontest <strong>ja</strong> diagonaaljoontest.<br />
• Hoiduge joonte ristumisest.<br />
• Vältige olukorda, kus seosetüüpi tähistav joon ristub olemitüübi<br />
tähisega nii, et jääb mulje nagu oleksid vastav seosetüüp <strong>ja</strong> olemitüüp<br />
seotud (kuigi nad tegelikult ei ole).<br />
7.3 Objekti-rolli modelleerimine<br />
Nagu eelnevalt öeldud, pole olemi-suhte diagramm sugugi mitte ainuke<br />
võimalik diagrammi tüüp andmebaasi kontseptuaalse struktuuri kirjelduse<br />
esitamiseks.<br />
Ruum<br />
sisaldub/sisaldab<br />
Hotell<br />
(hotelli_nr)<br />
U<br />
Omab / Iseloomustab<br />
identifitseeritakse/identifitseerib<br />
Ruumi nr.<br />
Nimi<br />
Joonis 53 ORM diagrammi näide.<br />
• Tuntakse ka faktidel põhineva modelleerimisena. Projekteeri<strong>ja</strong> paneb kir<strong>ja</strong><br />
elementaarfakte, st. fakte mida ei saa enam <strong>ja</strong>gada väiksemateks<br />
faktideks. Ta võib selleks kasutada diagrammi või teksti. Iga selline fakt on<br />
tegelikult ärireegel.<br />
Faktitüüpide näited.<br />
• Hotell sisaldab ruumi.<br />
• Ruum omab ruumi numbrit<br />
75
TTÜ: Andmebaaside projekteerimine.<br />
Strateegiline analüüs <strong>ja</strong> detailanalüüs (2012)<br />
© Erki Eessaar<br />
• Hotelli identifitseerib nimi.<br />
• Mitmes hotellis võib olla ühesugune ruumi number.<br />
Faktitüüp on tegelikult lausend.<br />
• Võimaldab diagrammil visuaalselt esitada rohkem infot kui olemi-suhte<br />
diagramm.<br />
• Ei kasutata atribuudi mõistet. See on tegelikult eelis, sest sageli tekib<br />
modelleeri<strong>ja</strong>l küsimus kas modelleerida mõni reaalse maailma üldistus<br />
olemitüübi või atribuudina. See muudab mudeli ebastabiilseks, sest mingil<br />
hetkel võidakse otsustada modelleerida olem atribuudina või vastupidi.<br />
• Lisaks diagrammil esitatavatele faktitüüpidele esitatakse ka antud tüüpide<br />
faktide näited. See võimaldab kasuta<strong>ja</strong>tel mudelit paremini hinnata <strong>ja</strong><br />
sellest aru saada. Näidisfakt tähendab seda et fakti esitatav väide<br />
esitatakse koos näidisväärtustega. Näiteks: "Nii hotellis Viru kui ka Olümpia<br />
võib olla ruum number 212".<br />
• Modelleerimisvahendite poole pealt, mis seda kasutada võimaldavad võiks<br />
mainida MS Visiot.<br />
• Täpsemalt võib lugeda: http://www.orm.net või Terry Halpini raamatust:<br />
Halpin, T., 2001. Information Modeling and Relational Databases. From<br />
Conceptual Analysis to Logical Design. Morgan Kaufman Publishers, San<br />
Francisco.<br />
8. Mõisted<br />
Eesti keeles<br />
Andmebaasi arendamise metoodika<br />
Ainevaldkonna analüüs<br />
Strateegiline analüüs<br />
Detailanalüüs<br />
Kontseptuaalne andmebaasi disain<br />
Süsteemi tükeldamine<br />
(dekomponeerimine)<br />
Pädevusala allsüsteem<br />
Funktsionaalne allsüsteem<br />
Register<br />
Kasutusjuhtude mudel<br />
Olemi-suhte diagramm<br />
Andmebaasioperatsiooni leping<br />
Eeltingimus<br />
Järeltingimus<br />
Seisundidiagramm<br />
Olekudiagramm<br />
Lehviku probleem<br />
Kuristiku probleem<br />
Inglise keeles<br />
Database development methodology<br />
Subject area analysis<br />
Strategical analysis<br />
Detailed analysis<br />
Conceptual database design<br />
Decomposition<br />
Area of competence<br />
Functional subsystem<br />
Data subsystem, register<br />
Use-Case model<br />
Entity-relationship diagram<br />
Contract of database operation<br />
Precondition<br />
Postcondition<br />
State-transition diagram<br />
Connection trap<br />
Fan-trap<br />
Chasm-trap<br />
76
TTÜ: Andmebaaside projekteerimine.<br />
Strateegiline analüüs <strong>ja</strong> detailanalüüs (2012)<br />
9. Kasutatud mater<strong>ja</strong>lid<br />
© Erki Eessaar<br />
1. Andmekogude seadus [WWW]<br />
https://www.riigiteata<strong>ja</strong>.ee/ert/act.jsp?id=745339 (03.04.2007)<br />
2. Barker, R., 1990. CASE Method: Entity Relationship Modelling. Addison-<br />
Wesley Professional.<br />
3. Baskerville, R. & Pries-Heje, J., 2001. Racing the e-bomb: how the internet<br />
is redefining information systems development methodology // Realigning<br />
research and practice in information systems development The social and<br />
organizational perspective. IFIP TC8/WG8.2 Working Conference / N.L.<br />
Russo, B. Fitzgerald, J.I. DeGross. Boston : Kluwer Academic Publishers,<br />
2001. p. 49 – 68.<br />
4. Cockburn, A., 1997. The Methodology Space. Human and Technology.<br />
(WWW)<br />
http://members.aol.com/acockburn/papers/methyspace/methyspace.htm<br />
(14.03.2001)<br />
5. Codd, E. F. 1979. Extending the Database Relational Model to Capture<br />
More Meaning. ACM TODS 4, No. 4 (December 1979)<br />
6. Connolly, T. M. & Begg, C. E., 2002. Database systems. A Practical<br />
Approach to Design, Implementation and Management. Third Edition.<br />
Pearson Education. 1236 p.<br />
7. Chisholm, M., 2000. Managing Reference Data in Enterprise Databases:<br />
Binding Corporate Data to the Wider World. Morgan Kaufmann. 387 p.<br />
8. Date, C. J., 2003. An Introduction to Database Systems. Eighth Edition.<br />
Addison Wesley. 983 p.<br />
9. Eesti standard EVS-ISO/IEC 2382. Infotehnoloogia. Sõnastik. Lõppkavand<br />
(WWW) http://www.keeleveeb.ee (26.03.2008)<br />
10.Eriksson, H.-E. & Penker, M., 2000. Business Modeling with UML. Johhn<br />
Wiley & Sons, Inc. 459 p.<br />
11.Eriksson, H.-E., Penker, M., Lyons, B. & Fado, D., 2004. UML 2 Toolkit.<br />
Wiley Publishing. 511 p.<br />
12.Evitts, P., 2000. A UML Pattern Language. Macmillan Technical<br />
Publishing.<br />
13.Fowler, M., 2007. UMLi kontsentraat. Objektmodelleerimise standardkeele<br />
UML 2.0 lühijuhend. 3. redaktsioon. Cybernetica.<br />
14.Halpin, T., 2001. Information Modeling and Relational Databases. From<br />
Conceptual Analysis to Logical Design. Morgan Kaufman Publishers, San<br />
Francisco.<br />
15.Hoberman, S., 2002. Data Modeler's Workbench: tools and techniques for<br />
analysis and design. Wiley Computer Publishing. 472 p.<br />
16.Kuusik, R., 2000. Infosüsteemi isearendamise toimimismudel<br />
infoühiskonnas // A & A (2000) nr. 3, lk. 14-22.<br />
17.Larman, C., 1997. Applying UML and patterns : an introduction to objectoriented<br />
analysis and design. Upper Saddle River (N.J.) : Prentice Hall<br />
PTR. 507 lk.<br />
18.Larman, C., 2002. Applying UML and patterns : an introduction to objectoriented<br />
analysis and design, Second Edition, Prentice Hall, Upper Saddle<br />
River (N.J.). 627 lk.<br />
19.Leis, P., 2001. Agiilmetoodikad // A & A (2001) nr. 4.<br />
20.Mikli, T., 1999. Sissejuhatus infosüsteemidesse. Tallinna Tehnikaülikool.<br />
77
TTÜ: Andmebaaside projekteerimine.<br />
Strateegiline analüüs <strong>ja</strong> detailanalüüs (2012)<br />
© Erki Eessaar<br />
21.Miliauskaite, E. & Nemuraite, L. 2005. Representation of integrity<br />
constraints in conceptual models. Information Technology And Control,<br />
Kaunas, Technologi<strong>ja</strong>, 2005, Vol.34, No.4, pp. 355 – 365.<br />
22.Modeling Methodologies (WWW) http://www.aisintl.com/index.html<br />
(21.02.2002)<br />
23.Moriarty, T., 2001. Universal Acceptance. Look beyond unfamiliar words to<br />
see a better description of your business. Intelligent Enterprise Magazine,<br />
September 18, 2001.<br />
24.Muller, R. J., 1999. Database Design for Smarties. Using UML for Data<br />
Modeling. Morgan Kaufmann Publishers. 442 p.<br />
25.Robertson, S. & Robertson, J., 1999. Mastering the Requirements<br />
Process. Addison-Wesley.<br />
26.Silverston, L., 2001a. The Data Model Resource Book: A Library of<br />
Universal Data Models for All Enterprises. Revised Edition. Vol. 1. Wiley<br />
Computer Publishing.<br />
27.Silverston, L., 2001b. The Data Model Resource Book: A Library of<br />
Universal Data Models by Industry Types. Revised Edition. Vol. 2, Wiley<br />
Computer Publishing.<br />
28.Simsion, G. 2007. Data Modeling Theory and Practice. Technics<br />
Publications, LLC, New Jersey.<br />
29.Sowa, J. F. & Zachman, J. A., 1992. Extending and formalizing the<br />
framework for information systems architecture. IBM Systems Journal Vol.<br />
31, No. 3 (Jun. 1992), pp. 590-616.<br />
30.Teorey, T. J., Yang, D. & Fry, J. P., 1986. A logical design methodology for<br />
relational databases using the extended entity-relationship model. ACM<br />
Comput. Surv. Vol. 18, No. 2 (Jun. 1986), pp. 197 – 222.<br />
31.Vendelin, J., 2003. Rakenduste loomine andmebaasiga MS Access.<br />
Tallinna Tehnikaülikool, Informaatikainstituut. 60 lk.<br />
32.Wikipedia [WWW] http://en.wikipedia.org/wiki/Code_and_fix (21.03.2004)<br />
78
Change language