Teema 10. Loogiline disain. CASE

TTÜ: Loogiline disain. CASE (2012)© Erki EessaarTeema 10. Loogiline disain. CASESisukord1 Eesmärgid ......................................................................................................................... 32 Disain ................................................................................................................................ 33 Andmebaasi loogiline disain ............................................................................................. 43.1 Kontseptuaalse andmemudeli teisendamine ............................................................. 53.2 SQL-andmebaasi kirjelduse esitamine ...................................................................... 63.3 Tabelite leidmine ........................................................................................................ 63.3.1 Tugev olemitüüp ................................................................................................. 63.3.2 1:M binaarne seosetüüp ..................................................................................... 73.3.3 Nõrk olemitüüp ................................................................................................... 93.3.4 M:N binaarne seosetüüp .................................................................................... 93.3.5 1:1 binaarne seosetüüp .................................................................................... 123.3.6 Rekursiivne seosetüüp ..................................................................................... 143.3.6.1 1:1 rekursiivne seosetüüp ......................................................................... 143.3.6.2 1:M rekursiivne seosetüüp ........................................................................ 163.3.6.3 M:N rekursiivne seosetüüp ........................................................................ 163.3.7 Üldistusseos ..................................................................................................... 173.3.7.1 Variant 1 {Optional; Or} ............................................................................. 183.3.7.2 Variant 2 {Mandatory; And} ....................................................................... 183.3.7.3 Variant 3 {Optional; And} ........................................................................... 203.3.7.4 Variant 4 {Mandatory; Or} .......................................................................... 213.3.8 Seosetüüp, mille aste on kahest suurem .......................................................... 213.3.9 Välistav kaar ..................................................................................................... 223.3.9.1 Täieliku/tõelise kaare lahendus ................................................................. 233.3.9.2 Kaare lõhkumise lahendus ........................................................................ 243.3.9.3 Ühise / üldise kaare lahendus ................................................................... 243.3.10 Mitmeväärtuseline atribuut ............................................................................. 253.4 Kitsenduste kirjeldamine .......................................................................................... 273.4.1 Võtmed ............................................................................................................. 283.4.2 Veergude kohustuslikus ................................................................................... 313.4.3 Viidete terviklikkuse tagamine .......................................................................... 313.4.4 Tuletisatribuudid ............................................................................................... 353.4.5 Täiendavad kitsendused ................................................................................... 363.5 Tabelite disaini kvaliteedi hindamine ja parandamine .............................................. 373.6 Loogilise disaini andmemudeli näide ....................................................................... 383.7 Veel mõned soovitused ........................................................................................... 403.7.1 Klassifikaatorite haldus ..................................................................................... 403.7.2 Klassifikaatorite hoidmine SQL-andmebaasis .................................................. 413.7.3 Väärtuste puudumine ....................................................................................... 453.7.4 Seisundite klassifikaator ................................................................................... 453.7.5 Vektorkodeerimine e. semantiline kodeerimine. ............................................... 473.7.6 Vaba teksti väljad ............................................................................................. 494 Rakenduse loogiline disain ............................................................................................. 504.1 Kasutajaliideste loogiline projekteerimine ................................................................ 514.2 Transaktsioonide loogiline projekteerimine .............................................................. 545 CASE vahendid ............................................................................................................... 555.1 CASE vahendi kasutamisest tulenev võimalik kasu ................................................. 555.2 Üldised nõuded CASE vahenditele .......................................................................... 555.3 Andmete modelleerimise CASE-vahendite üldiseloomustus ................................... 611

5.4 Spetsiifilised nõuded andmete modelleerimiseks mõeldud CASEvahenditele .................................................................................................................... 625.5 Kuidas valida CASE vahendeid? ............................................................................. 626 Mõisted ........................................................................................................................... 637 Kasutatud materjalid ....................................................................................................... 64

TTÜ: Loogiline disain. CASE (2012)© Erki Eessaarteadmised disaini ja ehitamise kohta ning disainerile tulevad kasuksteadmised analüüsi ning projekteeritava süsteemi valdkonna kohta.Eristatakse loogilist ja füüsilist disaini.Loogiline disain tegeleb konkreetsest realisatsiooni- ja rakenduskeskkonnastsõltumatute, järelikult nende keskkondade jaoks spetsiaalselt optimeerimatalahenduste loomisega.Isotamm (1998) soovitab loogilise disaini tulemusena loodud mudelitnimetada rakendusmudeliks. Loogiline disain jaguneb: Andmebaasi loogiline disain, mille sisendiks on kontseptuaalneandmemudel. Sellele rakendatakse teisendusreeglid, et luua esialgneloogilise disaini andmemudel (loogiline andmemudel,andmebaasiskeemi kirjeldus). Loomulikult peab andmebaasi kavandajaselle esialgse mudeli üle vaatama ja tegema vajalikud parandused ningtäiendused. Andmebaasi kasutava rakenduse loogiline disain, mille sisendiks onkasutusjuhtude kirjeldused ja andmebaasioperatsioonide lepingud.Tulemuseks on reaalsete kasutusjuhtumite kirjeldused, ekraanivormidepildid ja transaktsioonide spetsifikatsioonid.Füüsiline disain optimeerib / häälestab loogilise disaini lahendusikonkreetsete “füüsiliste” keskkondade jaoks, st. konkreetsete riist- ja tarkvaraproduktide jaoks.3 Andmebaasi loogiline disainTuletame meelde, et terminit "andmemudel" kasutatakse kahes erinevastähenduses.Connolly ja Begg (2002) põhjal on andmebaasi loogiline disain protsess,mille käigus luuakse organisatsiooni loogiline andmemudel, mis põhinebmingil kindlal andmemudelil (nt. relatsiooniline mudel või SQL aluseks olevmudel), kuid mis on sõltumatu andmebaasisüsteemist või muudest füüsiliserealisatsiooniga seotud kaalutlustest.Loogilise disaini alguses tuleb lõplikult otsustada, millise andmemudeli(näiteks relatsiooniline) põhjal kavatsetakse andmebaas luua. Käesolevaskursuses teeme me tutvust SQL-andmebaasi loogilise disainiga. Järelikult onvalitud andmemudeliks SQLi aluseks olev andmemudel. Edaspidi kasutatakseSQLi termineid "tabel", "rida" ja "veerg". Kogu selle peatüki vältel kasutatakseterminit "tabel", et rääkida baastabelitest.Loogiline andmebaasi disain hõlmab. Loogilise andmemudeli koostamine. Andmebaasioperatsioonide loogiline projekteerimine.Loogiline andmemudel koostatakse kontseptuaalse andmemudeli põhjal.Erinevalt analüüsi tulemusena koostatud kontseptuaalsest andmemudelist,4

TTÜ: Loogiline disain. CASE (2012)© Erki Eessaarnähakse nüüd iga olemitüübi taga konkreetset tabelit. Loogilise disainitulemusena leitakse tabelite struktuur ja seotud kitsendused. Tabelid onsoovitav viia viiendale normaalkujule ja kontrollida, et nad rahuldavadortogonaalse andmebaasi disaini printsiipi.Lisaks hõlmab andmebaasi loogiline disain ka andmebaasioperatsioonideloogilist projekteerimist. Analüüsi käigus loodud andmebaasioperatsioonidelepinguid täiendatakse nii, et seal kasutataks tabelite ja veergude nimesid.Andmebaasioperatsioonide loogilise projekteerimise käigus tuleb kontrollida,kas kirjeldatud operatsioone on võimalik projekteeritud andmebaasi põhjal läbiviia.Andmebaasioperatsioon on andmete kasutamise elementaarteenus, midaandmebaas pakub selle poole pöörduvatele rakendustele. SQL-andmebaasikasutamise korral võib andmebaasioperatsiooni või ka mitu üheskooskasutatavat andmebaasioperatsiooni realiseerida ühe andmebaasiserveristalletatud rutiinina.SQL-andmebaasi loogilise disaini tegevused on:1. Kontseptuaalse andmemudeli muutmine – SQLi aluseks olevaandmemudeliga kokkusobimatute konstruktsioonide eemaldamineandmemudelist (valikuline – võib, kuid ei pruugi teha).2. Tabelite leidmine.3. Võtmete kitsenduste kirjeldamine.4. Tabelite disaini kvaliteedi hindamine ja parandamine.5. Andmebaasioperatsioonide loogiline projekteerimine.6. Disaini tulemuste ülevaatamine koos süsteemi tulevastekasutajatega.Kontseptuaalsest andmemudelist esialgse loogilise andmemudeli leidmist onvõimalik automatiseerida, sest eksisteerivad teisendusreeglid.3.1 Kontseptuaalse andmemudeli teisendamineConnolly ja Begg (2002) märgivad, et soovi korral võib enne loogiliseandmemudeli koostamise algust muuta lähtemudeliks olevat kontseptuaalsetandmemudelit.Muutmise eesmärgiks on eemaldada kontseptuaalsest andmemudelistkonstruktsioonid, mille põhjal loogilise andmemudeli elementide leidminenõuab suhteliselt keerukat teisendust. Tegemist on mittekohustusliku jaettevalmistava sammuga, mille tulemusena peaks esialgse loogiliseandmemudeli leidmine lihtsustuma.Võimalikud tegevused. Eemaldada binaarsed mitu-mitu (M:N) seosetüübid. Eemaldada rekursiivsed mitu-mitu (M:N) seosetüübid. Eemaldada seosetüübid, kus osaleb kolm või rohkem olemitüüpi. Eemaldada mitmeväärtuselised atribuudid.5

TTÜ: Loogiline disain. CASE (2012)© Erki EessaarBinaarsete mitu-mitu (M:N) seosetüüpide eemaldamiseks luuakse uusolemitüüp ja kaks uut üks-mitu (1:M) seosetüüpi.Olemitüübiga OT seotud rekursiivse mitu-mitu (M:N) seosetüübieemaldamiseks luuakse uus olemitüüp OT seos ja kaks uut üks-mitu (1:M)seosetüüpi olemitüüpide OT ja OT seos vahel. OT seos võimsus mõlemavaadeldava seosetüübi kontekstis on üks.Kolme või rohkemat olemitüüpi hõlmava seosetüübi eemaldamiseks luuakseuus olemitüüp ja seostatakse see 1:M seosetüüpide kaudu esialgsesseosetüübis osalenud olemitüüpidega.Mitmeväärtuseliste atribuutide eemaldamiseks luuakse atribuudile vastav uusolemitüüp, mis on 1:M seosetüübi kaudu seotud olemitüübiga, millesse seeatribuut enne kuulus.3.2 SQL-andmebaasi kirjelduse esitamineSQLi tabelite ja võtmete kirjelduse esitamiseks võib kasutada järgnevatesitusviisi:Tabeli nimi (veergude nimekiri)Primaarvõti (primaarvõtme poolt hõlmatud veergude nimekiri)Alternatiivvõti (alternatiivvõtme poolt hõlmatud veergude nimekiri)Välisvõti (välisvõtme poolt hõlmatud veergude nimekiri) Viitab Tabeli nimi(primaar- või alternatiivvõtme poolt hõlmatud veergude nimekiri)Pange tähele, et veergude nimekirjad ei ole mitte looksulgudes vaidümarsulgudes. See näitab, et SQL pöörab tähelepanu veergude järjekorraletabelites ja võtmetes.3.3 Tabelite leidmineLihtsustatult öeldes hakkab üldjuhul igale olemitüübile vastama üks tabel.Järgnevaid teisendusreegleid kirjeldavad Connolly ja Begg (2002). Eeldame,et kontseptuaalne andmemudel on esitatud kasutades olemi-suhtediagramme ning olemitüüpide, atribuutide ja seosetüüpide kirjeldusi. Eeldame,et andmebaas plaanitakse luua SQL-andmebaasina.3.3.1 Tugev olemitüüpTugeva olemitüübi OT põhjal luuakse tabel T. Iga OT üheväärtuseliseatribuudi põhjal lisatakse tabelisse T üks veerg. Veeru tüüp leitakse atribuuditüübi põhjal.Olemitüübi atribuutide põhjal, mis on unikaalsed identifikaatorid, leitakseprimaarvõtmed ja alternatiivvõtmed.6

TTÜ: Loogiline disain. CASE (2012)© Erki EessaarAmetameti_kood : Stringnimetus : StringJoonis 1 Olemitüübi näide.Joonis 1 esitatud olemitüübi põhjal leitakse baastabeli kirjeldus (edaspidilihtsalt tabel):Amet (ameti_kood, nimetus)Primaarvõti (ameti_kood)Alternatiivvõti (nimetus)See, et ameti_kood ja nimetus on unikaalsed identifikaatorid, ei paista olemisuhtediagrammilt välja, kuid see informatsioon on dokumenteeritudkontseptuaalses andmemudelis.Juhul kui kontseptuaalses andmemudelis ei ole informatsiooni olemitüübiunikaalsete identifikaatorite kohta ja ka loogilise andmemudeli koostajad eioska olemasolevate atribuutide põhjal võtmeid määrata, siis võib loodavastabelis võtta kasutusele surrogaatvõtme. Järgnevas näites on selleks(amet_id).Amet (amet_id, ameti_kood, nimetus)Primaarvõti (amet_id)Sellise lahenduse probleemiks on, et andmebaasis võivad jääda jõustamatasisulise tähendusega võtmed (antud juhul (ameti_kood) ja (nimetus)).3.3.2 1:M binaarne seosetüüpAmetameti_kood : Stringnimetus : Stringtöötamine10..*Töötajaisikukood : Stringeesnimi : Stringperenimi : Stringsünniaeg : Datesugu : Stringelukoht : StringJoonis 2 1:M binaarse seosetüübi näide.Joonis 2 esitab 1:M binaarse seosetüübi. 1:M tähendab, et tegemist on üksmitmeleseosega. Iga töötaja töötab täpselt ühel ametikohal. Igal ametikohaltöötab null või rohkem töötajat. Binaarne tähendab, et seosetüüp ühendabkahte olemitüüpi.Sellise seosetüübi abil ühendatud olemitüüpide põhjal luuakse eraldi tabelid.Ühte nendest tabelitest tuleb lisada välisvõtme veerud ja välisvõtme7

TTÜ: Loogiline disain. CASE (2012)© Erki Eessaarkitsendus. Välisvõti tuleb paigutada tabelisse, millele vastava olemitüübivõimsus vaadeldava seosetüübi kontekstis on üks.Joonis 2 kohaselt töötab iga töötaja täpselt ühes ametis. Seetõttu tuleb lisadavälisvõti olemitüübi Töötaja põhjal loodavasse tabelisse. Joonis 2 esitatudolemitüüpide ja seosetüüpide põhjal luuakse tabelid:Amet(ameti_kood,nimetus)Primaarvõti(ameti_kood)Alternatiivvõti(nimetus)Töötaja(isikukood, eesnimi, perenimi, sünniaeg,sugu, elukoht, ameti_kood)Primaarvõti (isikukood)Välisvõti (ameti_kood) Viitab Amet(ameti_kood)Miks on tabelis Töötaja välisvõtme veerg ameti_kood, aga mitte nimetus?Välisvõti peab viitama seotud tabeli kandidaatvõtmele (see tähendab, etseose loomiseks sobib nii ameti kood kui ka ameti nimetus), kuid levinudpraktika on luua seos kasutades primaarvõtit.Välisvõtme ja seose loomiseks kasutatava kandidaatvõtme veergudeandmetüübid peavad olema ühilduvad (ühte tüüpi). Kuna Töötajaosaluskohustus seosetüübis on kohustuslik (see tähendab, et iga töötajapeab olema seotud ühe ametiga, siis on tabeli Töötaja veerg ameti_koodkohustuslik veerg (sellele tuleb lisada NOT NULL kitsendus).Toote_klasstoote_klassi_kood : Integernimetus : String0..10..*Toodetoote_kood : Stringnimetus : Stringhind : DateJoonis 3 1:M binaarse seosetüübi näide.Joonis 3 kohaselt iseloomustab iga toodet null või üks toote klassi ja igassetoote klassi kuulub null või rohkem toodet. Joonis 3 esitatud olemitüüpide jaseosetüüpide põhjal luuakse tabelid:Toote_klass(toote_klassi_kood,nimetus)Primaarvõti(toote_klassi_kood)Alternatiivvõti(nimetus)Toode(toode_kood, nimetus, hind,toote_klassi_kood)Primaarvõti (toote_kood)Välisvõti (toote_klassi_kood) ViitabToote_klass(toote_klassi_kood)Kuna olemitüübi Toode osaluskohustus seosetüübis on mittekohustuslik (seetähendab, et toode võib kuid ei pruugi olla seotud ühe toote klassiga), siis ontabeli Toode veerg toote_klassi_kood mittekohustuslik veerg (tabelis Toodeolevas reas võib sellele veerule vastavas väljas väärtus puududa).8

TTÜ: Loogiline disain. CASE (2012)© Erki Eessaar3.3.3 Nõrk olemitüüpNõrga olemitüübi OT põhjal luuakse tabel T. Iga OT üheväärtuselise atribuudipõhjal lisatakse tabelisse T üks veerg. Veeru tüüp leitakse atribuudi tüübipõhjal.Primaarvõtit ei saa tabelis T enne määrata, kui on leitud T seosed teistetabelitega. Tabeli T primaarvõti hõlmab välisvõtme veerge, mille abil luuakseseosed teiste tabelitega.Tellimustellimuse_nrtäitmise_aeg : Date 10..*Tellimuse_ridakogus : Integerhind : Currency0..* 1Toodetoote_kood : Stringnimetus : Stringhind : DateJoonis 4 Olemi-suhte diagrammi näide.Joonis 4 esitatud diagrammil on tugevateks olemitüüpideks Tellimus ja Kaupning nõrk olemitüüp on Tellimuse_rida. Tellimuse rida ei saa eksisteerida ilmatellimuseta, millesse see kuulub ja tooteta, mille tellimust see kirjeldab.Olemitüübi Tellimuse_rida põhjal loodud tabeli Tellimuse_rida primaarvõtihõlmab välisvõtme veerge, mille abil luuakse seos tabelitega Tellimus jaToode.Tellimus (tellimuse_nr, täitmise_aeg)Primaarvõti (tellimuse_nr)Toode (toote_kood, nimetus, hind)Primaarvõti (toote_kood)Tellimuse_rida (tellimuse_nr, toote_kood, kogus, hind)Primaarvõti (tellimuse_nr, toote_kood)Välisvõti (tellimuse_nr) Viitab Tellimus (tellimuse_nr)Välisvõti (toote_kood) Viitab Toode (toote_kood)3.3.4 M:N binaarne seosetüüpMitu-mitmele binaarse seosetüübi põhjal, mis seob olemitüüpe OT1 ja OT2,tuleb luua vahetabel T. Selles tabelis peavad olema välisvõtme veerud, milleabil luuakse seosed OT1 ja OT2 põhjal loodud tabelitega. Tabeli T primaarvõtihõlmab eelnimetatud välisvõtme veerge ja võib vajadusel sisaldadatäiendavaid veerge.9

TTÜ: Loogiline disain. CASE (2012)© Erki EessaarÕppejõudisikukood : Stringõpetamine0..* 0..*Õppeaineainekood : StringJoonis 5 M:N binaarse seosetüübi näide.Joonis 5 kohaselt õpetab iga õppejõud nulli või rohkemat õppeainet. Igaõppeainet õpetab null või rohkem õppejõudu. Joonis 5 esitatud olemitüüpideja seosetüüpide põhjal luuakse tabelid:Õppejõud (isikukood)Primaarvõti (isikukood)Õppeaine (ainekood)Primaarvõti (ainekood)Õpetamine (isikukood, ainekood)Primaarvõti (isikukood, ainekood)Välisvõti (isikukood) Viitab Õppejõud (isikukood)Välisvõti (ainekood) Viitab Õppeaine (ainekood)Seosetüüp võib olla modelleeritud eraldiseisva olemitüübina.Õppejõudisikukood : Stringõpetamine0..*0..*Õppeaineainekood : StringÕpetaminealguse_aeg : Datelõpu_aeg : DateJoonis 6 Sidemeklassi näide.Joonis 6 paiknev sidemeklass esitab täiendava kitsenduse, mille kohaseltvõib iga õppejõud õpetada ühte ja sama õppeainet ainult üks kord. Seetõttuluuakse Joonis 6 esitatud olemitüüpide ja seosetüüpide põhjal tabelid:Õppejõud (isikukood)Primaarvõti (isikukood)Õppeaine (ainekood)Primaarvõti (ainekood)Õpetamine (isikukood, ainekood, alguse_aeg, lõpu_aeg)Primaarvõti (isikukood, ainekood)Välisvõti (isikukood) Viitab Õppejõud (isikukood)Välisvõti (ainekood) Viitab Õppeaine (ainekood)10

TTÜ: Loogiline disain. CASE (2012)© Erki EessaarNagu näete, on tabelis Õpetamine primaarvõtmeks isikukoodi ja ainekoodikombinatsioon. See tagab, et tabelis Õpetamine saab mistahes isikukoodi jaainekoodi kombinatsioon olla maksimaalselt ühes reas.Õppejõudisikukood : String10..*Õpetaminealguse_aeg : Datelõpu_aeg : Date0..*1Õppeaineainekood : StringJoonis 7 Seosetüübi modelleerimine eraldi olemitüübina.Joonis 7 esitatud diagrammil kohaselt puudub kitsendus, et õppejõud võibõpetada õppeainet ainult üks kord. Seetõttu luuakse Joonis 7 esitatudolemitüüpide ja seosetüüpide põhjal tabelid:Õppejõud (isikukood)Primaarvõti (isikukood)Õppeaine (ainekood)Primaarvõti (ainekood)Õpetamine (isikukood, ainekood, alguse_aeg, lõpu_aeg)Primaarvõti (isikukood, ainekood, alguse_aeg)Välisvõti (isikukood) Viitab Õppejõud (isikukood)Välisvõti (ainekood) Viitab Õppeaine (ainekood)Nagu näete, hõlmab tabeli Õpetamine primaarvõti nüüd ka veergualguse_aeg. Seetõttu on võimalik registreerida ühe õppejõu mitmekordsedõppeaine õpetamised, juhul kui need alanud erinevatel aegadel.Kui tabelit Õpetamine on kavas siduda mõne teise tabeliga, siis võib tabelisÕpetamine võtta kasutusele surrogaatvõtme, et vältida liitvälisvõtme tekkimist.Lihtvälisvõti hõlmab ühte veergu ning liitvälisvõti hõlmab rohkem kui ühteveergu.Õpetamine (õpetamine_id, isikukood, ainekood, alguse_aeg, lõpu_aeg)Primaarvõti (õpetamine_id)Alternatiivvõti (isikukood, ainekood, alguse_aeg)Välisvõti (isikukood) Viitab Õppejõud (isikukood)Välisvõti (ainekood) Viitab Õppeaine (ainekood)Kommentaar (õpetamine_id, tekst, lisamise_aeg)Primaarvõti (õpetamine_id, lisamise_aeg)Välisvõti (õpetamine) Viitab Õpetamine (õpetamine_id)Oletame, et soovime hakata registreerima õpetamiste kohta kommentaare.Tabelis Õpetamine on veerg õpetamine_id surrogaatvõtme veerg. TabelisKommentaar on välisvõti lihtvõti. Kui välisvõti on lihtvõti, siis see lihtsustabvõrreldes liitvälisvõtmega päringute tegemist ja vähendab andmemahte.11

TTÜ: Loogiline disain. CASE (2012)© Erki EessaarLiitvälisvõtmete kasutamise muudab keerukamaks ka asjaolu, et SQL lubabvälisvõtme deklareerimisel määrata, kui suures ulatuses peab välisvõtmeväärtus vastama seotud tabeli kandidaatvõtme väärtusele. Võimalikudmäärangud on MATCH SIMPLE (vaikimisi määrang), MATCH FULL jaMATCH PARTIAL. Määrang omab sisulist mõju, kui välisvõti on liitvõti javälisvõtme poolt hõlmatud veerud on mittekohustusliku (seal on lubatudNULLid). Kui kasutate liitvälisvõtit soovitame kasutades määrangut MATCHFULL. Sellisel juhul peab tabelis olev välisvõtme väärtus olema kas täiestimääramata (kõikidele välisvõtme veergudele vastavates väljades on NULLid)või võrduma seotud tabeli mõne kandidaatvõtme väärtusega. MATCHSIMPLE ja MATCH PARTIAL võimaldavad kasutada tabelites välisvõtmeväärtuseid, mis ainult osaliselt vastavad mõne seotud tabeli kandidaatvõtmeväärtusele.3.3.5 1:1 binaarne seosetüüpJuhul kui tegemist on seosetüübiga, mille osaluskohustus on mõlemas otsaskohustuslik, siis luuakse seosetüübis osalevate olemitüüpide põhjal üks tabel.Tabeli primaarvõti leitakse ühe olemitüübi unikaalse identifikaatori põhjal.Ülejäänud unikaalsete identifikaatorite põhjal leitakse alternatiivvõtmed. Juhul,kui kahe olemitüübi vahel on lisaks 1:1 seosetüübile ka 1:M seosetüüp, siisluuakse ikkagi kaks eraldi tabelit.Lepinglepingu_nr : Integerkehtivuse_algus : Date1koostatakse1Arvearve_nr : Integersumma : Currencytasumistähtaeg : Date+koostamise alusJoonis 8 1:1 binaarse seosetüübi näide.+koostamise tulemusJoonis 8 kohaselt koostatakse iga lepingu alusel täpselt üks arve ja iga arvekoostatakse täpselt ühe lepingu alusel. Joonis 8 esitatud olemitüüpide jaseosetüüpide põhjal luuakse tabelid:Leping (lepingu_nr, kehtivuse_algus, arve_nr, summa, tasumistähtaeg)Primaarvõti (lepingu_nr)Alternatiivvõti(arve_nr)Juhul kui tegemist on seosetüübiga, mille osaluskohustus on ühes otsaskohustuslik ja teises otsas mittekohustuslik, siis luuakse seosetüübisosalevate olemitüüpide põhjal kaks eraldi tabelit. Seose loomiseks vajalikudvälisvõtme veerud tuleb lisada tabelisse, millele vastava olemitüübi jaoks onvaadeldav seosetüüp kohustuslik.12

TTÜ: Loogiline disain. CASE (2012)© Erki EessaarLepinglepingu_nr : Integerkehtivuse_algus : Date1koostatakse0..1Arvearve_nr : Integersumma : Currencytasumistähtaeg : Date+koostamise alusJoonis 9 1:1 binaarse seosetüübi näide.+koostamise tulemusJoonis 9 kohaselt koostatakse iga lepingu alusel null või üks arvet ja iga arvekoostatakse täpselt ühe lepingu alusel. Joonis 9 esitatud olemitüüpide jaseosetüüpide põhjal luuakse tabelid:Leping (lepingu_nr, kehtivuse_algus)Primaarvõti (lepingu_nr)Arve (arve_nr, lepingu_nr, summa, tasumistähtaeg)Primaarvõti(arve_nr)Alternatiivvõti (lepingu_nr)Välisvõti (lepingu_nr) Viitab Leping (lepingu_nr)Pange tähele, et tabelisse Arve lisatud välisvõtme veerud kuuluvad kaalternatiivvõtmesse.• Tabeli Arve veerule lepingu_nr tuleb SQL-andmebaasis lisadaunikaalsuse kitsendus (UNIQUE), et iga lepinguga saaks sidudamaksimaalselt ühe arve.• Tabeli Arve veerule lepingu_nr tuleb SQL-andmebaasis lisadakohustuslikkuse kitsendus (NOT NULL), et igal arvel oleks seotud leping.Lahendi valiku tingib soov vältida tabelite veergudes NULLide kasutamist. Kuilisada tabelisse Leping välisvõtmena veerg arve_nr, siis:• Tabelis Leping võib mõnes reas arve number puududa.• Eeldame, arve tekib peale lepingu sõlmimist ja registreerimist. Uue arveregistreerimisel tuleb lisada rida tabelisse Arve ja muuta rida tabelisLeping (et luua seos arve ja lepingu vahel). Kui tabelis Arve onvälisvõtmena veerg lepingu_nr, siis piisab rea lisamisest tabelisse Arve.Juhul kui tegemist on seosetüübiga, mille osaluskohustus on mõlemas otsasmittekohustuslik, siis kummagi olemitüübi põhjal luuakse eraldi tabel. Välisvõtituleks lisada sellesse tabelisse, millesse lisatakse andmed hiljem. Kui poleinformatsiooni tabelitesse andmete lisamise järjekorra kohta, siis on vabavalik, kumma olemitüübi alusel loodud tabelisse välisvõti lisada.Juhime tähelepanu, et välisvõti läheb ainult ühte nendest tabelitest.SQL-andmebaasis tuleb välisvõtme poolt hõlmatud veergudele lisadaunikaalsuse kitsendus, et tagada 1:1 seos. Samas peavad välisvõtme poolthõlmatud veerud olema mittekohustuslikud.13

TTÜ: Loogiline disain. CASE (2012)© Erki EessaarLepinglepingu_nr : Integerkehtivuse_algus : Date0..1koostatakse0..1Arvearve_nr : Integersumma : Currencytasumistähtaeg : Date+koostamise alusJoonis 10 1:1 binaarse seosetüübi näide.+koostamise tulemusJoonis 10 kohaselt koostatakse iga lepingu alusel null või üks arvet ja igaarve koostatakse null või ühe lepingu alusel. Joonis 10 esitatud olemitüüpideja seosetüüpide põhjal luuakse tabelid:Leping (lepingu_nr, kehtivuse_algus)Primaarvõti (lepingu_nr)Arve (arve_nr, lepingu_nr, summa, tasumistähtaeg)Primaarvõti(arve_nr)Välisvõti (lepingu_nr) Viitab Leping (lepingu_nr)Kui leping luuakse üldjuhul enne arvet, siis tuleks välisvõti paigutadaolemitüübi Arve põhjal loodud tabelisse. (lepingu_nr) ei ole tabelis Arvealternatiivvõti, sest võib leiduda arveid, mille korral lepingu number ei oleteada. Samas peab tabelis Arve olema loodud veerule lepingu_nr unikaalsusekitsendus, sest iga leping saab olla seotud maksimaalselt ühe arvega.3.3.6 Rekursiivne seosetüüpRekursiivse seosetüübi mõlemas otsas on sama olemitüüp (OT) (erinevatesrollides). Rekursiivse seosetüübi korral luuakse olemitüübi OT põhjal üks tabelT.Rekursiivne seosetüüp kontseptuaalses andmemudelis näitab, etandmebaasis soovitakse hoida andmeid mingit tüüpi hierarhiate võivõrkstruktuuri moodustavate seoste kohta.3.3.6.1 1:1 rekursiivne seosetüüpIsikisikukood : Stringperenimi : String+jälgija11+jälgitavJoonis 11 1:1 rekursiivse seosetüübi näide.Kui seosetüübi osaluskohustus on mõlemas otsas kohustuslik, siis tuleb:14

TTÜ: Loogiline disain. CASE (2012)© Erki Eessaar• lisada tabelisse T välivõti, mis võib omada ainult sama tabeliprimaarvõtme väärtuseid. Välisvõtme veergudele tuleb anda nendetähendust täpsemalt kirjeldav nimi. Välisvõtme veergude nimed peavaderinema primaarvõtme veergude nimedest, sest tabelis ei tohi ollaühenimelisi veerge. Veergude nimetamisel võib kasutada rollide nimesid,mis kirjeldavad olemitüübi rolli seosetüübi kontekstis.• välisvõtme poolt hõlmatud veerud moodustavad ka alternatiivvõtme.Joonis 11 kohaselt on igal isikul täpselt üks jälgija, kes tema tegevusi jälgib jatäpselt üks jälgitav kelle tegevusi isik ise jälgib. Joonis 11 esitatud olemitüübija seosetüübi põhjal luuakse järgnev tabel:Isik (isikukood, perenimi, jälgija)Primaarvõti (isikukood)Alternatiivvõti (jälgija)Välisvõti (jälgija) Viitab Isik(isikukood)Isikisikukood : Stringperenimi : String+juhendatav0..1+juhendaja0..1Joonis 12 1:1 rekursiivse seosetüübi näide.Kui seosetüübi osaluskohustus on mõlemas otsas mittekohustuslik, siis tulebseosetüübi põhjal luua tabel, milles on kaks välisvõtit. Joonis 12 kohaselt onigal isikul null või üks juhendajat ja null või üks juhendatavat (keda see isik isejuhendab). Joonis 12 esitatud olemitüübi ja seosetüübi põhjal luuaksejärgnevad tabelid:Isik (isikukood, perenimi)Primaarvõti (isikukood)Juhendamine (juhendaja, juhendatav)Primaarvõti (juhendaja)Alternatiivvõti (juhendatav)Välisvõti (juhendaja) Viitab Isik(isikukood)Välisvõti (juhendatav) Viitab Isik(isikukood)Primaarvõti peab hõlmama kas veergu juhendaja või juhendatav. Õigupooleston see näide olukorrast, kus on raske ühte võtit teisele eelistada japrimaarseks kuulutada.Kui seosetüübi osaluskohustus on ühes otsas kohustuslik ja teises otsasmittekohustuslik, siis tuleb valida üks eelnevalt väljapakutud kahestlahendusest.15

TTÜ: Loogiline disain. CASE (2012)© Erki Eessaar3.3.6.2 1:M rekursiivne seosetüüpÜks-mitmele rekursiivse seosetüübi korral lisatakse tabelisse T välisvõti, misvõib omada ainult sama tabeli primaarvõtme väärtuseid. Välisvõtmeveergudele tuleb anda nende tähendust täpsemalt kirjeldav nimi.Isikisikukood : Stringperenimi : String+juhendatav0..*+juhendaja0..1Joonis 13 1:M rekursiivse seosetüübi näide.Joonis 13 kohaselt on igal isikul null või üks juhendajat ning null või rohkemjuhendatavat. Joonis 13 esitatud olemitüübi ja seosetüübi põhjal luuaksejärgnev tabel:Isik (isikukood, perenimi, juhendaja)Primaarvõti (isikukood)Välisvõti (juhendaja) Viitab Isik(isikukood)3.3.6.3 M:N rekursiivne seosetüüpMitu-mitmele rekursiivse seosetüübi korral luuakse seosetüübi põhjal tabel,milles on kaks välisvõtit.Isikisikukood : Stringperenimi : String+juhendatav0..*+juhendaja0..*Joonis 14 M:N rekursiivse seosetüübi näide.Joonis 14 kohaselt on igal isikul null või rohkem juhendajat ja null või rohkemjuhendatavat. Joonis 14 esitatud olemitüübi ja seosetüübi põhjal luuaksejärgnevad tabelid:16

TTÜ: Loogiline disain. CASE (2012)© Erki EessaarIsik (isikukood, perenimi)Primaarvõti (isikukood)Juhendamine (juhendaja, juhendatav)Primaarvõti (juhendaja, juhendatav)Välisvõti (juhendaja) Viitab Isik(isikukood)Välisvõti (juhendatav) Viitab Isik(isikukood)3.3.7 ÜldistusseosIsikisikukood : Stringeesnimi : Stringperenimi : Stringsünniaeg : Dateelukoht : StringÜliõpilaneüliõpilaskood : StringTöötaja0..* 1Ametameti_kood : Integernimetus : StringJoonis 15 Üldistusseose näide.Joonis 15 kohaselt on üliõpilane isik ja töötaja on isik. Isik on ülatüüp ningÜliõpilane ja Töötaja tema alamtüübid.Üldistusseosega seotud olemitüüpide põhjal tabelite leidmisel tuleb võttaarvesse üldistusseosega seotud kitsendused. Lisaks võib võtta arvesse üla- jaalamtüüpide atribuutide ja seosetüüpide arvud. Järgnevad disaini soovitusedpõhinevad ainult üldistusseosega seotud kitsendustel ning need pakkusidvälja Connolly ja Begg (2002).Kõikide järgnevate üldistusseose põhjal tabelite leidmise näidete korral tulebluua tabel Amet. Selle tabeli kirjeldust järgnevates näidetes ei korrata.Amet (ameti_kood, nimetus)Primaarvõti (ameti_kood)Alternatiivvõti (nimetus)17

TTÜ: Loogiline disain. CASE (2012)© Erki Eessaar3.3.7.1 Variant 1 {Optional; Or}• Osaluskohutus: {Optional}. Iga ülatüüpi kuuluv olem ei pea kuulumamõnda alamtüüpi. Näiteks võib leiduda isikuid, kes ei ole ei üliõpilasedega töötajad.• Kuuluvus: {Or}. Iga ülatüüpi olem võib kuuluda maksimaalselt ühtealamtüüpi. Näiteks iga isik võib olla kas üliõpilane või töötaja, aga mittemõlemat korraga.Kokkuvõtlikult, iga ülatüüpi kuuluv olem kuulub nulli või ühte alamtüüpi.Variandi 1 puhul soovitavad Connolly ja Begg (2002) luua ülatüübile vastavtabel, mis sisaldab ülatüübi atribuutidele vastavaid veerge. Iga alamtüüpikohta tuleb luua üks tabel, mis sisaldab vastava alamtüübi atribuutidelevastavaid veerge.Alamtüüpide põhjal loodud tabelitesse tuleb lisada välisvõtme veerud, et luuaseos ülatüübi põhjal loodud tabeliga. Need veerud on ühtlasi ka primaarvõtmeveerud.Joonis 15 esitatud olemitüüpide ja seosetüüpide põhjal luuakse tabelid:Isik (isikukood, eesnimi, perenimi, sünniaeg, elukoht)Primaarvõti (isikukood)Üliõpilane (isikukood, üliõpilaskood)Primaarvõti (isikukood)Alternatiivvõti(üliõpilaskood)Välisvõti (isikukood) Viitab Isik(isikukood)Töötaja (isikukood, ameti_kood)Primaarvõti (isikukood)Välisvõti (isikukood) Viitab Isik(isikukood)Välisvõti (ameti_kood) Viitab Amet (ameti_kood)SQL-andmebaasisüsteemi pakutavate vahenditega (deklaratiivsedkitsendused, trigerid) tuleb tagada, et iga isiku andmeid saab registreeridamaksimaalselt ühes alamtüüpide põhjal loodud tabelis.Pakutud variant võimaldab registreerida andmed isikute kohta, kes poleühtegi alamtüüpi, tabelis Isik. Kui isik on mõnda alamtüüpi, siisregistreeritakse tema andmed tabelis Isik ja lisaks veel ühele alamtüübilevastavas tabelis.3.3.7.2 Variant 2 {Mandatory; And}• Osaluskohutus: {Mandatory}. Iga ülatüüpi olem peab kuuluma ka mõndaalamtüüpi. Näiteks isik peab olema kas üliõpilane või töötaja.• Kuuluvus: {And}. Iga ülatüüpi olem võib kuuluda mitmesse alamtüüpi.Näiteks isik võib olla korraga nii üliõpilane kui ka töötaja.18

TTÜ: Loogiline disain. CASE (2012)© Erki EessaarKokkuvõtlikult, iga ülatüüpi kuuluv olem kuulub ühte või rohkemassealamtüüpi.Variandi 2 puhul soovitavad Connolly ja Begg (2002) luua ülatüübi ja sellegaseotud alamtüüpide põhjal ühe tabeli:• Loodava tabeli nimi tuletatakse ülatüübi nimest.• Loodav tabel sisaldab nii ülatüübi, kui ka kõigi alamtüüpide atribuutidelevastavaid veerge.• Kõik alamtüüpide atribuutide põhjal leitud veerud peavad olemamittekohustuslikud. See tähendab, et nendele vastavates ridade väljadesvõivad väärtused puududa.• Iga alamtüübi kohta lisatakse tabelisse kohustuslik (NOT NULLkitsendusega) tõeväärtuse tüüpi veerg, milles olev väärtus näitab, kasülatüüpi olem kuulub vastavasse alamtüüpi. Selliste veergude nimedtuletatakse alamtüüpide nimedest.Joonis 15 esitatud olemitüüpide ja seosetüüpide põhjal luuakse tabel:Isik (isikukood, eesnimi, perenimi, sünniaeg, elukoht, üliõpilaskood,ameti_kood, on_üliõpilane, on_töötaja)Primaarvõti (isikukood)Välisvõti (ameti_kood) Viitab Amet (ameti_kood)Üliõpilaskoodi ei saa näiteks primaarvõtmeks ega alternatiivvõtmeks valida,sest kõik selles tabelis registreeritavad isikud ei pruugi olla üliõpilased ja neilei ole üliõpilaskoodi.SQL-andmebaasisüsteemi pakutavate vahenditega (deklaratiivsedkitsendused, trigerid) tuleb tagada, et iga tabelis Isik oleva rea puhul onvähemalt ühes alamtüübi määramiseks mõeldud veerule (antud juhulon_üliopilane, on_töötaja) vastavas väljas väärtus TRUE.Esitatud lahenduse negatiivseks küljeks on mittekohustuslike veergudetekkimine tabelisse Isik. Seega on tabeli kasutajad sunnitud kokku puutumaNULLidega ja SQLi kolmevalentse loogikaga. Soovitame sellises olukorraskasutada hoopis varianti nr. 1. Lisaks tuleb andmebaasis jõustada kitsendus,et iga ülatüüpi olem peab kuuluma ühte või rohkemasse alamtüüpi.Kui iga ülatüüpi olem peab kuuluma ka kõikidesse alamtüüpidesse, siis võibka kasutada lahendust, mille kohaselt luuakse eraldi tabel nii ülatüübi kui kaiga alamtüübi põhjal. Alamtüüpidest tekkinud tabelid ühendatakse välisvõtmekaudu ülatüübist tekkinud tabeliga. Välisvõtme veerud lisatakse ülatüübipõhjal loodud tabelisse. Need välivõtme veerud kuuluvad kaalternatiivvõtmetesse.Joonis 15 esitatud olemitüüpide ja seosetüüpide põhjal luuakse sellisel juhultabelid:Üliõpilane (üliõpilaskood)Primaarvõti (üliõpilaskood)19

TTÜ: Loogiline disain. CASE (2012)© Erki EessaarTöötaja (töötaja_id, ameti_kood)Primaarvõti (töötaja_id)Välisvõti (ameti_kood) Viitab Amet (ameti_kood)Isik (isikukood, eesnimi, perenimi, sünniaeg, elukoht, üliõpilaskood,töötaja_id)Primaarvõti (isikukood)Alternatiivvõti (üliõpilaskood)Alternatiivvõti (töötaja_id)Välisvõti (üliõpilaskood) Viitab Üliõpilane (üliõpilaskood)Välisvõti (töötaja_id) Viitab Töötaja (töötaja_id)Veel üks variant on kasutada sama tabelite struktuuri kui {Optional; Or} korralkoos kitsendusega, mis kontrolliks, et isiku andmed on vähemalt ühes tabelisalamtüübile vastavate tabelite seas.3.3.7.3 Variant 3 {Optional; And}• Osaluskohutus: {Optional}. Iga ülatüüpi kuuluv olem ei pea kuulumamõnda alamtüüpi. Näiteks võib leiduda isikuid, kes ei ole ei üliõpilasedega töötajad.• Kuuluvus: {And}. Iga ülatüüpi olem võib kuuluda mitmesse alamtüüpi.Näiteks isik võib olla korraga nii üliõpilane kui ka töötaja.Kokkuvõtlikult, iga ülatüüpi kuuluv olem kuulub nulli või rohkemassealamtüüpi.Variandi 3 puhul soovitavad Connolly ja Begg (2002) luua kaks tabelit. Üksnendest sisaldab ülatüübi atribuutidele vastavaid veerge. Teine sisaldabkõikide alamtüüpide atribuutidele vastavaid veerge. Kõik alamtüüpideatribuutide põhjal leitud veerud peavad olema mittekohustuslikud. Tabelitenimed tuleb tuletada ülatüübi nimest.Lisaks lisatakse alamtüüpide põhjal loodud tabelisse iga alamtüübi kohtakohustuslik (NOT NULL kitsendusega) tõeväärtuse tüüpi veerg, milles olevväärtus näitab, kas ülatüüpi olem kuulub vastavasse alamtüüpi. Sellisteveergude nimed tuletatakse alamtüüpide nimedest.Alamtüüpide põhjal loodud tabelisse tuleb lisada välisvõtme veerud, et luuaseos ülatüübi põhjal loodud tabeliga. Need veerud on ühtlasi ka primaarvõtmeveerudJoonis 15 esitatud olemitüüpide ja seosetüüpide põhjal luuakse tabelid:Isik (isikukood, eesnimi, perenimi, sünniaeg, elukoht)Primaarvõti (isikukood)Isiku_detail (isikukood, üliõpilaskood, ameti_kood, on_üliõpilane, on_töötaja)Primaarvõti (isikukood)Välisvõti (isikukood) Viitab Isik(isikukood)Välisvõti (ameti_kood) Viitab Amet (ameti_kood)20

TTÜ: Loogiline disain. CASE (2012)© Erki EessaarSellise lahenduse negatiivseks küljeks on mittekohustuslike veergudetekkimine tabelisse Isiku_detail. Seega on tabeli kasutajad sunnitud kokkupuutuma NULLidega ja SQLi kolmevalentse loogikaga. Soovitame sellisesolukorras kasutada hoopis sama tabelite struktuuri kui {Optional; Or} korral.3.3.7.4 Variant 4 {Mandatory; Or}• Osaluskohutus: kohustuslik: {Mandatory}. Iga ülatüüpi olem peab kuulumaka mõnda alamtüüpi. Näiteks isik peab olema kas üliõpilane või töötaja.• Kuuluvus: {Or}. Iga ülatüüpi olem võib kuuluda vaid ühte alamtüüpi.Näiteks iga isik võib olla kas üliõpilane või töötaja, aga mitte mõlematkorraga.Kokkuvõtlikult, iga ülatüüpi kuuluv olem kuulub täpselt ühte alamtüüpi.Variandi 4 puhul soovitavad Connolly ja Begg (2002) luua iga alamtüübi kohtaeraldi tabeli, mis sisaldab nii ülatüübi atribuutidele vastavaid veerge, kui kavastava alamtüübi atribuutidele vastavaid veerge. Tabelite nimed tuletataksealamtüüpide nimedest. Ülatüübi põhjal eraldi tabelit ei looda.Joonis 15 esitatud olemitüüpide ja seosetüüpide põhjal luuakse tabelid:Üliõpilane (isikukood, eesnimi, perenimi, sünniaeg, elukoht, üliõpilaskood)Primaarvõti (isikukood)Alternatiivvõti (üliõpilaskood)Töötaja (isikukood, eesnimi, perenimi, sünniaeg, elukoht, ameti_kood)Primaarvõti (isikukood)Välisvõti (ameti_kood) Viitab Amet (ameti_kood)SQL-andmebaasisüsteemi pakutavate vahenditega (deklaratiivsedkitsendused, trigerid) tuleb tagada, et ühe ja sama isiku andmeid eisisestataks erinevatesse alamtüüpide põhjal loodud tabelitesse. Vastaseljuhul ei ole täidetud ortogonaalse andmebaasi disaini printsiip.Järgnev soovitus ei tulene üldistusseosega seotud kitsendustest – kuikontseptuaalses andmemudelis on ülatüübi tasemel seosetüübid (näiteksseosetüüp, mille üks osaline on Isik), siis võiks ikkagi kaaluda sama tabelitestruktuuri kasutamist kui {Optional; Or} korral – näiteks luua eraldi tabelid Isik,Töötaja ja Üliõpilane.3.3.8 Seosetüüp, mille aste on kahest suuremSeosetüüpi, mille aste on kahest suurem, võib esitada luues seosetüübipõhjal olemitüübi. Sellisel juhul saame kasutada binaarseid seosetüüpe ningtabelite leidmiseks saame kasutada binaarsete seosetüüpide kohta antudsoovitusi.21

TTÜ: Loogiline disain. CASE (2012)© Erki EessaarIsikisikukood : String1Projektprojekti_kood : Integer10..*Osaleminealguse_aeg : Datelõpu_aeg : Date0..*0..*1Rollrolli_kood : IntegerJoonis 16 Ternaarse seosetüübi esitamise näide.Joonis 16 kohaselt osalevad isikud projektides mingites rollides. OlemitüüpOsalemine esitab seosetüüpi, mille aste on kolm. Joonis 16 esitatudolemitüüpide ja seosetüüpide põhjal luuakse tabelid:Isik (isikukood)Primaarvõti (isikukood)Projekt (projekti_kood)Primaarvõti (projekti_kood)Roll (rolli_kood)Primaarvõti (rolli_kood)Osalemine (isikukood, projekti_kood, rolli_kood, alguse_aeg, lõpu_aeg)Primaarvõti (isikukood, projekti_kood, rolli_kood, alguse_aeg)Välisvõti (isikukood) Viitab Isik (isikukood)Välisvõti (projekti_kood) Viitab Projekt (projekti_kood)Välisvõti (rolli_kood) Viitab Roll (rolli_kood)3.3.9 Välistav kaarJoonis 17 kohaselt peab iga lepingu rida olema seotud kas teenuse võikaubaga, aga ei saa olla korraga seotud mõlemaga. Vastavate seosetüüpidekaarepoolses otsas asub olemitüüp Lepingu_rida. Kaarega seotudseosetüüpide realiseerimiseks on andmebaasi kavandajal erinevaidvõimalusi.22

TTÜ: Loogiline disain. CASE (2012)© Erki EessaarLepinglepingu_kood : Integersolmimise_kp : Date11..*Lepingu_ridakogus : Integerhind : Currency0..*{XOR}0..*0..1Kaupkauba_kood : Integernimi : Stringhind : Currencykogus_laos : Integer0..1Teenusteenuse_kood : Integernimi : Stringhind : CurrencyJoonis 17 Välistava kaare näide.3.3.9.1 Täieliku/tõelise kaare lahendusTäieliku/tõelise kaare lahenduse korral toimitakse järgnevalt:• Iga kaarega hõlmatud seosetüübi kohta tekitatakse eraldi mittekohustuslikveergude hulk seosetüübi kaarepoolses otsas asuva olemitüübi põhjalloodavas tabelis. Need veerud on ühtlasi ka välisvõtme veerud.• Kaare loogika (ühes reas tohivad olla väärtused vaid ühele eelnimetatudveergude hulgale vastavates väljades) tuleb realiseerida kasutadesSQL-andmebaasisüsteemi pakutavaid vahendeid (deklaratiivsedkitsendused, trigerid).Joonis 17 esitatud olemitüüpide ja seosetüüpide põhjal luuakse tabelid:Leping (lepingu_kood, solmimise_kp)Primaarvõti (lepingu_kood)Teenus (teenuse_kood, nimi, hind)Primaarvõti (teenuse_kood)Kaup (kauba_kood, nimi, hind, kogus_laos)Primaarvõti (kauba_kood)Lepingu_rida (rea_kood, teenuse_kood, kauba_kood, lepingu_kood, kogus,hind)Primaarvõti (rea_kood)Välisvõti (teenuse_kood) Viitab Teenus(teenuse_kood)Välisvõti (kauba_kood) Viitab Kaup(kauba_kood)Välisvõti (lepingu_kood) Viitab Leping(lepingu_kood)23

TTÜ: Loogiline disain. CASE (2012)© Erki EessaarNagu näete, on tabelis Lepingu_rida kaks välisvõtit, mille abil luuaksevastavalt seos tabelitega Kaup ja Teenus. Tabelis Lepingu_rida peavadveerud teenuse_kood ja kauba_kood olema mittekohustuslikud. (rea_kood)on surrogaatvõti.SQL-andmebaasisüsteemi pakutavate vahenditega (deklaratiivsedkitsendused, trigerid) tuleb tagada, et igal lepingul on vähemalt üks rida.3.3.9.2 Kaare lõhkumise lahendusKaare lõhkumise lahenduse korral luuakse iga kaarega hõlmatud seosetüübikohta eraldi tabel. Sellise lahenduse kasutamine on eelistatum, sest ei tekitabeleid kus on lubatud NULLid nagu täieliku/tõelise kaare lahenduse puhul.Tänu sellele pole tabelites Teenuse_lepingu_rida ja Kauba_lepingu_rida vajaprimaarvõtme veergu rea_kood, vaid saame kasutada liitvõtit (tuletagemeelde olemi terviklikkuse reeglit)Joonis 17 esitatud olemitüüpide ja seosetüüpide põhjal luuakse tabelid:Leping (lepingu_kood, solmimise_kp)Primaarvõti (lepingu_kood)Teenus (teenuse_kood, nimi, hind)Primaarvõti (teenuse_kood)Kaup (kauba_kood, nimi, hind, kogus_laos)Primaarvõti (kauba_kood)Teenuse_lepingu_rida (teenuse_kood, lepingu_kood, kogus, hind)Primaarvõti (teenuse_kood, lepingu_kood)Välisvõti (teenuse_kood) Viitab Teenus(teenuse_kood)Välisvõti (lepingu_kood) Viitab Leping(lepingu_kood)Kauba_lepingu_rida (kauba_kood, lepingu_kood, kogus, hind)Primaarvõti(kauba_kood, lepingu_kood)Välisvõti (kauba_kood) Viitab Kaup(kauba_kood)Välisvõti (lepingu_kood) Viitab Leping(lepingu_kood)SQL-andmebaasisüsteemi pakutavate vahenditega (deklaratiivsedkitsendused, trigerid) tuleb tagada, et igal lepingul on vähemalt üks rida.3.3.9.3 Ühise / üldise kaare lahendusÜhise/üldise kaare lahenduse korral lisatakse seosetüübi kaarepoolsestotsast tekitatud tabelisse kaks uut kohustuslikku veergu. Nendele veergudelvastavate väljade väärtused:• Seosetüübi teises otsas oleva tabeli nimi.24

TTÜ: Loogiline disain. CASE (2012)© Erki Eessaar• Sama tabeli primaarvõtme väärtus (kui primaarvõtmed on unikaalsed ülekõigi kaarega hõlmatud seosetüübiga seotud tabelite, võib tabelite nimedejaoks mõeldud veeru ära jätta).Leping (lepingu_kood, solmimise_kp)Primaarvõti (lepingu_kood)Teenus (teenuse_kood, nimi, hind)Primaarvõti (teenuse_kood)Kaup (kauba_kood, nimi, hind, kogus_laos)Primaarvõti (kauba_kood)Lepingu_rida (rea_kood, element, tüüp, kogus, hind, lepingu_kood)Primaarvõti (rea_kood)Alternatiivvõti (lepingu_kood, element, tüüp)Välisvõti (lepingu_kood) Viitab Leping(lepingu_kood)kauba_kood nimi hind kogus_laosK_1 Sony teler 5000 5K_2 Panasonicu teler 4500 3K_3 Samsungi teler 4700 10teenuse_kood nimi hindK_1 Pakkimine 50T_2 Kojuvedu 150rea_kood element tüüp kogus hind lepingu_kood1 K_1 K 2 10000 12 K_1 T 1 50 13 K_2 K 1 4500 2Tabeli Lepingu_rida veerus tüüp on kas väärtus "T" (nagu teenus) või "K"(nagu kaup).Veergude element ja tüüp puhul tuleb programmeerida kontrollprogrammid,mis tagavad viidete terviklikkuse reeglite täidetuse. Kuna see on töömahukas(ja suureneb vigade tegemise võimalus), siis soovitame ühise/üldise kaarelahendusest hoiduda.3.3.10 Mitmeväärtuseline atribuutMõnikord proovivad SQL-andmebaasi kavandajad luua mitmeväärtuseliseatribuudi põhjal niinimetatud veergude grupi.25

TTÜ: Loogiline disain. CASE (2012)© Erki EessaarVaatame selle kohta näidet. Igal töötajal on null või rohkem telefoninumbrit,millele helistades saab töötajaga kontakti võtta. Oletame, et olemitüübisTöötaja on mitmeväärtuseline atribuut telefon.Järgnevalt on esitatud võimalik tabel, mis sellise olemitüübi põhjal loogilisedisaini käigus leitakse. Nagu näete, on tabelis telefonide andmeteregistreerimiseks veerud telefon1, telefon2 ja telefon3.Töötaja (isikukood, perenimi, telefon1, telefon2, telefon3)Primaarvõti (isikukood)Sellise tabeli kasutamine pole hea lahendus (Celko, 2000). Mõnedküsimused, mida võib endale esitada:• Mis saab siis, kui töötajal on vähem kui kolm telefoninumbrit? Me võimekasutada mõnele veerule vastavates väljades NULLe, kuid siis tekivadprobleemid, mis seotud SQLi kolmevalentse loogikaga.• Mis saab siis, kui töötajal on rohkem kui kolm telefoninumbrit? Tulebmuuta tabeli struktuuri, lisades sinna näiteks uue veeru telefon4.• Mis saab siis, kui on vaja andmebaasi täiendada ja hakata registreerimainfot selle kohta, milliselt telefonilt saab inimest kergemini kätte ja milliseltraskemalt? Tabeli struktuuri tuleb muuta, lisades iga telefoni andmetehoidmiseks mõeldud veeru kohta tabelisse veel ühe veeru.Kitsenduste jõustamine on keeruline. Näiteks väga raske oleks jõustadakitsendust, et iga telefoninumber võib olla seotud ainult ühe töötajaga või kakitsendust, et konkreetne telefoninumber tohib olla seotud konkreetsetöötajaga ainult üks kord.Andmete otsimine nõuab keeruka ja mahuka süntaksiga päringutekasutamist. Näiteks olgu meil ülesanne: "Leidke kõik telefoninumbrid, misalgavad numbriga 6 ja isikud, kellega need telefoninumbrid on seotud".Ülesande lahendamiseks tuleb SQLis kirjutada järgnev hulgateoreetilisesumma leidmise operaatorit kasutav päring:SELECT isikukood, perenimi, telefon1 AS telefonFROM TöötajaWHERE telefon1 LIKE '6%'UNION SELECT isikukood, perenimi, telefon2 AS telefonFROM TöötajaWHERE telefon2 LIKE '6%'UNION SELECT isikukood, perenimi, telefon3 AS telefonFROM TöötajaWHERE telefon3 LIKE '6%';Mida rohkem on telefoni andmete hoidmiseks mõeldud veerge, sedamahukamaks see päring muutub. Kui lisandub uusi telefonide andmeteregistreerimiseks mõeldud veerge või mõni olemasolev veerg kustutatakse,siis tuleb muuta ka telefonide andmete otsimiseks mõeldud päringuid.26

TTÜ: Loogiline disain. CASE (2012)© Erki EessaarParem lahendus oleks luua olemitüübi OT mitmeväärtuselise atribuudi aluseluus tabel. See sisaldab välisvõtmena ka olemitüübi OT alusel loodud tabeliprimaarvõtmele vastavat veergu.Töötaja (isikukood, perenimi)Primaarvõti (isikukood)Telefon (isikukood, telefon)Primaarvõti (isikukood, telefon)Välisvõti (isikukood) Viitab Töötaja(isikukood)See disain on kergelt muudetav, kui muutuvad telefoninumbritega seotudreeglid.• Kui kehtestatakse reegel, et igal töötajal on maksimaalselt ükstelefoninumber, siis tuleb tabelis Telefon deklareerida unikaalseks(isikukood).• Kui kehtestatakse reegel, et iga telefoninumber tohib olla seotud ainult ühetöötajaga, siis tuleb tabelis Telefon deklareerida unikaalseks (telefon).Mõlemal juhul tuleb muuta ka tabeli Telefon primaarvõtit, et vältidasupervõtme deklareerimist (vt teema 5).Eelnevalt kirjeldatud otsinguülesande saab nende tabelite põhjal lahendadakasutades järgnevat ühendamise operaatori poole pöördumist sisaldavat SQLlauset.SELECT isikukood, perenimi, telefonFROM Töötaja INNER JOIN Telefon ON Töötaja.isikukood=Telefon.isikukoodWHERE telefon LIKE '6%';Seda lauset ei tule muuta vastavalt maksimaalsele töötajale lubatudtelefonide arvule. Seda lauset sobib kasutada nii siis, kui töötajatel onmaksimaalselt kaks telefoni kui ka siis, kui töötajatel on maksimaalselt kümmetelefoni.SQLi viimastel aastatel tehtud laiendused (objekt-relatsioonilisuse omadused)võimaldavad tabelites kasutada veerge mis on konstrueeritud multihulgatüüpi (inglise keeles multiset) või konstrueeritud massiivitüüpi. Sellist tüüpiveergude kasutamine on samuti üheks võimaluseks, kuidas mitmeväärtuselisiatribuute andmebaasis realiseerida.3.4 Kitsenduste kirjeldamineSamaaegselt tabelite kirjeldamisega, toimub loogilise andmebaasi disainikäigus andmebaasis jõustatavate kitsenduste kirjeldamine. Need kitsendusedtulenevad kontseptuaalses andmemudelis kirjeldatud kitsendustest.• Primaarvõtmed leitakse unikaalsete identifikaatorite põhjal.• Unikaalsuse nõuded leitakse unikaalsete identifikaatorite põhjal.• Välisvõtmed tulenevad seosetüüpidest.27

TTÜ: Loogiline disain. CASE (2012)© Erki Eessaar• Veergude kohustuslikkuse nõuded tulenevad unikaalsetestidentifikaatoritest, seosetüüpidega seotud kohustuslikkuse nõuetest võitäiendavatest kasutajate nõudmistest.• Samuti tuleb loogilise disaini käigus uurida, kuidas jõustada andmebaasikontseptuaalses andmemudelis kirjeldatud täiendavad kitsendused.Miks ikkagi kontrollida andmete kitsendustele vastavust andmebaasi tasemel?Vastavad kontrollid võiks ju kirjutada sisse loodavasse rakendusse.Andmete kitsendustele vastavuse kontroll ainult andmebaasi kasutavasrakenduses ei ole hea mõte:• Kui andmebaasi hakkab kasutama uus rakendus, tuleb sellessekitsenduste kontroll sisse kirjutada. Sellest tulenevalt:o Kui rakenduste arv suureneb, muutub ka raskemaks kitsendustemuutmine (muudatus tuleb sisse viia mitmesse kohta).o Arendaja peab tegema lisatööd, realiseerides kitsenduste kontrollikasutades erinevaid keeli, mida rakenduste loomiseks kasutatakse.o Arendaja võib unustada kitsenduse kas täielikult, või realiseerida sellekontrolli osaliselt. Viimane tähendab, et kui kitsenduse kontroll on vajalikerinevates alamprogrammides, siis võib arendaja unustada realiseeridakontrolli mõnes sellises alamprogrammis.o Erinevates rakendustes või sama rakenduse erinevates osades võibarendaja oskamatusest või tähelepanematusest tulenevalt luua ühe jasama reegli põhjal alamprogrammid, mis jõustavad erinevaid kitsendusi.o Ühe ja sama probleemi korduv lahendamine (kitsenduse jõustamiseksvajaliku koodi loomine) vähendab kokkuvõttes tööviljakust.• Samas ei ole võimalik teha päringuid, et leida süsteemis jõustatudkitsendusi. Miks sellised päringud on vajalikud? Paljud kitsendusedtulenevad ärireeglitest ja need reeglid võivad aja jooksul muutuda.Järelikult tuleb vastavad muudatused viia sisse ka tarkvarasüsteemi.Teisalt, kui kitsendus on loodud andmebaasis, siis selle kohta saab küsidapäringukeele abil andmeid andmebaasisüsteemi poolt peetavastandmebaasi süsteemikataloogist.• Kui andmete haldamine ei toimu läbi rakenduse (vaid näiteks läbiandmebaasi administreerimise programmi), siis ei kontrollita kitsendustestkinnipidamist. Näiteks pole rakenduses jõustatud kitsendustest abi, kuitoimub andmete laadimine andmebaasi kasutades andmebaasiadministreerimiseks mõeldud programme.Mõningate kitsenduste kontrolli võib dubleerida ka rakenduses, sest seevõimaldab kasutajale anda kiirema tagasiside (parem kasutusmugavus) ningväldib vigaste andmete edastamist üle arvutivõrgu (võrgu koormusevähendamine). Kui kitsendust ei õnnestu andmebaasi tasemel jõustada, tulebseda igal juhul teha rakenduses, sest nagu vanasõnagi ütleb – parem poolmuna kui tühi koor.3.4.1 VõtmedVõtme väärtus identifitseerib üheselt ühe tabeli rea. Olemitüübil võib olla mituatribuutide hulka, mille väärtused identifitseerivad unikaalselt iga sellesse28

TTÜ: Loogiline disain. CASE (2012)© Erki Eessaartüüpi kuuluva olemi. Sellised atribuutide hulgad tuleks kontseptuaalsesandmemudelis dokumenteerida kui unikaalsed identifikaatorid e. võtmed.Kontseptuaalses andmemudelis määratud unikaalsete identifikaatorite põhjalleitakse SQL-andmebaasi tabeleid kavandades kandidaatvõtmed. Ükskandidaatvõti valitakse primaarvõtmeks, ülejäänud kandidaatvõtmetestsaavad alternatiivvõtmed.SQL-andmebaasis deklareeritakse tabeli primaarvõti kasutades PRIMARYKEY kitsendust. SQL-andmebaasis deklareeritakse tabeli alternatiivvõtikasutades UNIQUE kitsendust ja määrates kõik võtme poolt hõlmatud veerudkohustuslikeks. Vaikimisi on SQLis tabeli veerud mittekohustuslikud (nendelevastavates ridade väljades on lubatud NULLid).Millised on soovitavad võtme omadused?• Tuttavlikkus – kasutaja jaoks omab võtme väärtust tähendust.• Lihtsus – võimalikult lühike (andmemahu mõttes) ja koosneb võimalikultvähestest komponentidest.• Stabiilsus – ei muutu aja jooksul.Võtmete puhul võib eristad ainult andmebaasis tabeli ridade unikaalsusetagamiseks mõeldud võtit e. surrogaatvõtit ja kasutajatele sisulist tähendustomavat võtit.Näiteks tabelis Töötaja on veergu töötaja_kood hõlmav võti surrogaatvõti, kuiselle võtme väärtus on kasutusel ainult tabeli ridade unikaalsuse tagamiseks.Tabelis Töötaja on veergu töötaja_kood hõlmav võti sisulise tähendusegavõti, kui selle väärtuseid kasutatakse töötajate eristamiseks ka väljaspoolandmebaasi.Miks kasutada surrogaatvõtit?Surrogaatvõti on lihtne. See hõlmab ühte (tavaliselt täisarvu tüüpi) veergu.Füüsilise disaini seisukohalt on oluline, et surrogaatvõtme puhul onvälisvõtmetest (primaarvõtme väärtus võib olla mõnes teises tabelisvälisvõtme väärtus) ja primaarvõtmele indeksi loomisest tulenevandmemahtude suurenemine võimalikult väike.Surrogaatvõti on stabiilne. Kuna surrogaatvõtme väärtus ei oma kasutajajaoks tähendust (ei ole tuttavlik), siis ei ole kasutajal vaja võtmeväärtuseid kamuuta ja seega ei pea andmebaasisüsteem muutma vastavaid väärtuseidvälisvõtmete kaudu seotud tabelites.Surrogaatvõtme väärtuseid võib andmebaasisüsteem ise genereerida.SQL-andmebaasisüsteemidega seoses on probleemiks, et arvujadageneraatoreid kirjeldati SQL standardis esmakordselt SQL:2003 standardiversioonis – kaua aega peale standardi esimese versiooni ilmumist.Tulemuseks on, et erinevates andmebaasisüsteemides on unikaalsete arvudegenereerimiseks erinevad võimalused ja käskude süntaks.Kontseptuaalses andmemudelis kirjeldatakse kasutajale sisulist tähendustomavad atribuudid. See tähendab, et kontseptuaalses andmemudelis ei29

TTÜ: Loogiline disain. CASE (2012)© Erki Eessaarnäidata surrogaatvõtmetele vastavaid atribuute. Vajadusel tuleb vastavvõtmeveerg lisada tabeli kirjeldusse loogilise disaini käigus.Miks siiski eelistada surrogaatvõtmetele sisulisi võtmeid?Võib juhtuda, et kasutades surrogaatvõtmeid, unustatakse deklareeridaunikaalsuse ja kohustuslikkuse kitsendused sisulise tähendusega atribuutide(näiteks isikukood, üliõpilaskood, auto registrinumber) põhjal loodudveergudele. Sellisel juhul on võimalik andmebaasis registreerida korduvaidandmeid ning tekib andmete liiasus. Näiteks, kui andmebaasisüsteem eikontrolli tabelis Isik isikukoodi unikaalsust, siis on võimalik registreerida ühe jasama isiku andmed mitmekordselt.Kokkuvõtlikud soovitused primaarvõtme valimiseks.1. Kui tabelil on mitu kandidaatvõtit, mille väärtused omavad sisulisttähendust ja on lihtvõtmed, siis valida primaarvõtmeks nende seastjärgmistele tingimustele vastav võti:• Kõige stabiilsem – väärtuste muutmine on kõige vähetõenäolisem.• Kõige lihtsam – sisaldab kõige vähem tekstisümboleid (tekstitüüpi veerupuhul) või on kõige väiksema maksimaalse väärtusega (arvutüüpi veerupuhul).• Millest on kasutajal kõige lihtsam aru saada.2. Kui tabelil on mitu kandidaatvõtit, mille väärtused omavad sisulisttähendust ning millest osa on lihtvõtmed ja osa liitvõtmed, siis validaprimaarvõtmeks mõni lihtvõti, kasutades eelmises punktis nimetatudkriteeriume.3. Kui tabeli kõik sisulist tähendust omavad kandidaatvõtmed on liitvõtmed,siis valida primaarvõtmeks liitvõti, kui see võti ei lähe välisvõtmeks mõneteise olemitüübi alusel loodavasse tabelisse. Vastasel juhul validaprimaarvõtmeks surrogaatvõti.4. Kui tuleb valida mitme liitvõtme vahel, siis lisakriteeriumiks on validaselline võti, kus osalevate veergude arv on minimaalne.5. Kõigi primaarvõtmeks mitte valitud kandidaatvõtmed (alternatiivvõtmed)tuleb samuti andmebaasis deklareerida.6. Kui kõikide tabelite primaarvõtmeks on surrogaatvõti, siis see viitabkergema vastupanu teed minekule. Disainiga pole viitsitud palju vaevanäha.7. Ärge mõelge ise välja uusi võtmeid, mille väärtusesse on kodeeritudinformatsioon.Toome näite probleemidest, mida sellise võtme kasutamine andmebaasikavandajale tekitab. Eesti Vabariigi isikukoodis sisaldub informatsioon isikusoo ja sünniaja kohta. Andmebaasi kavandajal tekib paratamatult küsimus,kas tabelis on vaja lisaks isikukoodile registreerida sugu ja sünniaeg ka eraldiveergudes?• Kui jah, siis tekib andmebaasis andmete liiasus ning tuleb tagada, etandmed ei oleks kunagi vastuolus (näiteks isikukoodi järgi on üks sünniaeg, aga sünni aja veerule vastavas väljas hoopis teistsugune). Tulebsaavutada kontrollitud andmete liiasus. Terviklikkuse reeglid isikukoodikontrollimiseks (näiteks et avastada sisestamise näpuvigu) on keerukad.30

TTÜ: Loogiline disain. CASE (2012)© Erki Eessaar• Kui ei, siis kuidas korraldada päringute tegemine isikute kohta sünni aja jasoo järgi? Isikukoodi struktuuri muutudes võib olla vajadus muuta ka neidpäringuid.Mõlemal juhul on vajalikud operaatorid, mis võimaldavad isikukoodiväärtusest eraldada isiku sünniaja ja soo andmed.3.4.2 Veergude kohustuslikusSQLi tabelites on lubatud veerud, millele vastavates ridade väljades onlubatud NULLid (väärtuse puudumine). Öeldakse, et sellised veerud onmittekohustuslikud. Kui soovitakse keelata veerus NULLide kasutamine, siistuleb seda SQL-andmebaasis eraldi deklareerida, kasutades NOT NULLkitsendust. Öeldakse, et veerud kus ei ole lubatud NULLide kasutamine, onkohustuslikud.Olemitüübi OT iga fakultatiivse üheväärtuselise atribuudi põhjal tuleb OTpõhjal loodud tabelisse lisada mittekohustuslik veerg.Olemitüübi OT iga kohustusliku üheväärtuselise atribuudi põhjal tuleb OTpõhjal loodud tabelisse lisada kohustuslik veerg.Olemitüübi OT iga mitmeväärtuselise atribuudi puhul tuleks luua eraldi tabel,kus kõik veerud on kohustuslikud (vt. peatükk 3.3.10 ). Juhul kuimitmeväärtuseline atribuut on kohustuslik, siis tuleb andmebaasis jõustadatäiendav kitsendus, et iga OT põhjal loodud tabeli rida peab olema seotudvähemalt ühe reaga tabelis, mis on loodud mitmeväärtuselise atribuudi põhjal.3.4.3 Viidete terviklikkuse tagamineSQL-andmebaasi loogilise disaini tulemusena tuleb leida tabelites olevadvälisvõtmed. Loogilise disaini tulemusena tuleb iga välisvõtme puhul kindlaksmäärata, kuidas peab andmebaasisüsteem reageerima, kui seoses sellevälisvõtmega tekib andmetes vastuolu viidete terviklikkuse reegliga. Selliseljuhul võib andmebaasisüsteem viia läbi kompenseerivaid tegevusi.Vaatleme näitena järgnevaid tabeleid:Töötaja (isikukood, perenimi)Primaarvõti (isikukood)Telefon (isikukood, telefon)Primaarvõti (telefon)Välisvõti (isikukood) Viitab Töötaja(isikukood)Tabelid Töötaja ja Telefon on seotud välisvõtme kaudu. Öeldakse, et sellevälisvõtme kontekstis on tabel Töötaja primaarne ja tabel Telefon sõltuv.Tabel, mis on ühe välisvõtme kontekstis primaarne võib olla teise välisvõtmekontekstis sõltuv ja vastupidi. Rekursiivse seosetüübi põhjal loodud tabelikorral on sama tabel korraga nii primaarne kui ka sõltuv.31

TTÜ: Loogiline disain. CASE (2012)© Erki EessaarMillal peab andmebaasisüsteem kontrollima andmete vastavust viideteterviklikkuse reeglile? Eeldame, et välisvõti loob seose primaarse tabeliprimaarvõtmega.Lisatakse rida sõltuvasse tabelisse – andmebaasisüsteem peab kontrollima,et välisvõtme väärtus oleks kas NULL (kui see on lubatud) või võrduks üheprimaarses tabelis oleva primaarvõtme väärtusega.Muudetakse välisvõtme väärtust sõltuvas tabelis – andmebaasisüsteem peabkontrollima, et muutuse järel oleks välisvõtme väärtus kas NULL (kui see onlubatud) või võrduks ühe primaarses tabelis oleva primaarvõtme väärtusega.Kustutatakse rida primaarsest tabelist – selleks, et vältida viidete terviklikkusereegliga vastuolus olevate andmete jõudmist andmebaasi, saab SQLstandardi kohaselt kasutada SQL-andmebaasisüsteemis järgmisi strateegiaid:• NO ACTION – andmebaasisüsteem ei ürita viidete terviklikkuse vigakompenseerida ning vea tekkimise tulemusena lükkabandmebaasisüsteem andmemuudatuse tagasi. NO ACTION on vaikimisistrateegia, mida rakendatakse, kui andmebaasi looja pole strateegiatmääranud.• RESTRICT – andmebaasisüsteem ei luba primaarses tabelis ridakustutada, kui leidub vähemalt üks selle reaga seotud rida sõltuvastabelis. Kokkuvõttes annavad NO ACTION ja RESTRICT sama tulemuse.• CASCADE – primaarses tabelis rea kustutamine tingib seotud ridadekustutamise sõltuvas tabelis. CASCADE strateegiat on sobilik kasutadasiis, kui olemi-suhte diagrammil on vastavate olemitüüpide vahelkompositsioon või üldistusseos.• SET NULL – primaarses tabelis rea kustutamine tingib vastavatevälisvõtme väärtuste kustutamise sõltuvas tabelis. SET NULL strateegiatsaab kasutada siis, kui välisvõtme veerud on mittekohustuslikud.• SET DEFAULT – primaarses tabelis rea kustutamine tingib vastavatevälisvõtme väärtuste asendamise vaikimisi väärtustega sõltuvas tabelis.SET DEFAULT strateegiat saab kasutada siis, kui välisvõtme veergudelon määratud vaikimisi väärtused. Peale vaikimisi väärtusega asendamistpeavad andmed rahuldama viidete terviklikkuse reeglit. Järelikult peabprimaarses tabelis olema rida, milles olev primaarvõtme väärtus langebkokku sõltuvas tabelis välisvõtme veergudele deklareeritud vaikimisiväärtustega.Muudetakse primaarse tabeli primaarvõtme väärtust – selleks, et vältidaviidete terviklikkuse reegliga vastuolus olevate andmete jõudmistandmebaasi, saab SQL standardi kohaselt kasutada SQLandmebaasisüsteemisjärgmisi strateegiaid:• NO ACTION – andmebaasisüsteem ei ürita viidete terviklikkuse vigakompenseerida ning vea tekkimise tulemusena lükkabandmebaasisüsteem andmemuudatuse tagasi. NO ACTION on vaikimisistrateegia, mida rakendatakse, kui andmebaasi looja pole strateegiatmääranud.• RESTRICT – andmebaasisüsteem ei luba primaarse tabeli reasprimaarvõtme väärtust muuta, kui leidub vähemalt üks selle reaga seotud32

TTÜ: Loogiline disain. CASE (2012)© Erki Eessaarrida sõltuvas tabelis. Kokkuvõttes annavad NO ACTION ja RESTRICTsama tulemuse.• CASCADE – primaarse tabeli reas primaarvõtme väärtuse muutminetingib vastavate välisvõtme väärtuste muutmise sõltuvas tabelis olevatesseotud ridades. CASCADE strateegiat on mõistlik kasutada, kuiprimaarvõti on sisulise tähendusega võti. Sellisel juhul võib andmebaasikasutajatel tekkida vajadus selle võtme väärtuseid muuta.• SET NULL – primaarse tabeli reas primaarvõtme väärtuse muutminetingib vastavate välisvõtme väärtuste kustutamise sõltuvas tabelisolevates seotud ridades. SET NULL strateegiat saab kasutada siis, kuivälisvõtme veerud on mittekohustuslikud.• SET DEFAULT – primaarse tabeli reas primaarvõtme väärtuse muutminetingib vastavate välisvõtme väärtuste asendamise vaikimisi väärtustegasõltuvas tabelis olevates seotud ridades. SET DEFAULT strateegiat saabkasutada siis, kui välisvõtme veergudel on määratud vaikimisi väärtused.Peale vaikimisi väärtusega asendamist peavad andmed rahuldama viideteterviklikkuse reeglit. Järelikult peab primaarses tabelis olema rida, millesolev primaarvõtme väärtus langeb kokku sõltuvas tabelis välisvõtmeveergudele deklareeritud vaikimisi väärtustega.Millised andmemuudatused ei tekita ühe vaadeldava välisvõtme kontekstisandmetesse vastuolu viidete terviklikkuse reegliga?• Kustutatakse rida sõltuvast tabelist.• Lisatakse uus rida primaarsesse tabelisse.Siinkohal tuletame aga veelkord meelde, et tabel mis on ühe välisvõtmekontekstis primaarne tabel võib olla teise välisvõtme kontekstis sõltuv tabel javastupidi. Andmebaasisüsteem peab andmete muudatuse kitsendustelevastavuse kontrollimisel arvestama kõigi välisvõtmetega.Vaatleme järgnevalt näiteid eelnevalt kirjeldatud strateegiate kohta. Nendesnäidetes on SQLi tabelite ja võtmete kirjeldusi täiendatud viidete terviklikkusekontrolli strateegia kirjeldusega.Näide 1:Töötaja (isikukood, perenimi)Primaarvõti (isikukood)Telefon (isikukood, telefon) Primaarvõti (telefon)Välisvõti (isikukood) Viitab Töötaja(isikukood) ON UPDATE CASCADE ONDELETE CASCADE• Rea kustutamisel tabelist Töötaja, kustutatakse seotud read tabelistTelefon.• Isikukoodi muutmisel tabelis Töötaja, muudetakse see isikukoodautomaatselt ka tabelis Telefon.Näide 2:Töötaja (isikukood, perenimi)Primaarvõti (isikukood)33

TTÜ: Loogiline disain. CASE (2012)© Erki EessaarTelefon (isikukood, telefon) Primaarvõti (telefon)Välisvõti (isikukood) Viitab Töötaja(isikukood) ON UPDATE NO ACTION ONDELETE NO ACTIONTöötaja (isikukood, perenimi)Primaarvõti (isikukood)Telefon (isikukood, telefon)Primaarvõti (telefon)Välisvõti (isikukood) Viitab Töötaja(isikukood) ON UPDATE RESTRICT ONDELETE RESTRICT• Rea kustutamisel tabelist Töötaja, ei luba andmebaasisüsteem ridakustutada, kui sellega on seotud üks või rohkem rida tabelis Telefon. Kuikustutataval real ei ole ühtegi seotud rida tabelis Telefon, siis lubabandmebaasisüsteem selle rea kustutada.• Isikukoodi muutmisel tabelis Töötaja, ei luba andmebaasisüsteemisikukoodi muuta, kui muudetav rida on seotud ühe või rohkema reagatabelis Telefon. Kui muudetaval real ei ole ühtegi seotud rida tabelisTelefon, siis lubab andmebaasisüsteem selles reas isikukoodi muuta.Näide 3:Töötaja (isikukood, perenimi)Primaarvõti (isikukood)Telefon (isikukood, telefon)Primaarvõti (telefon)Välisvõti (isikukood) Viitab Töötaja(isikukood) ON UPDATE SET NULL ONDELETE SET NULL• Rea kustutamisel tabelist Töötaja, kustutatakse tabeli Telefon veerustisikukood selle töötaja isikukoodid.• Isikukoodi muutmisel tabelis Töötaja, kustutatakse tabeli Telefon veerustisikukood selle töötaja isikukoodid.Näide 4:Töötaja (isikukood, perenimi)Primaarvõti (isikukood)Telefon (isikukood, telefon)Primaarvõti (telefon)Välisvõti (isikukood) Viitab Töötaja(isikukood) ON UPDATE SET DEFAULTON DELETE SET DEFAULT• Rea kustutamisel tabelist Töötaja, asendatakse tabelis Telefon selletöötaja isikukood veerule isikukood deklareeritud vaikimisi väärtusega.• Isikukoodi muutmisel tabelis Töötaja, asendatakse tabelis Telefon selletöötaja isikukood veerule isikukood deklareeritud vaikimisi väärtusega.34

TTÜ: Loogiline disain. CASE (2012)© Erki EessaarSoovitusi kompenseerivate tegevuste valikuks. Kasutage ON UPDATE CASCADE, kui primaarse tabeli primaarvõti onsisulise tähendusega võti, mille väärtuseid kasutatakse ka väljaspoolandmebaasi. Sellise võtme väärtused võivad muutuda, ehki ilmseltmitte väga sageli. Näiteks isikukoodi võib olla vaja muuta pealesoovahetusoperatsiooni. Kasutage ON DELETE CASCADE, kui kontseptuaalses andmemudelison välisvõtmele vastav seosetüüp kas kompositsioon või üldistusseos.3.4.4 TuletisatribuudidTuletisatribuudi puhul võib luua tabelid/veerud samade põhimõtete alusel, misülejäänud atribuutide korral. Kuid tuletisatribuutide puhul tuleb lisaks jõustadaandmebaasis kitsendused, mis tagavad, et mistahes sellise atribuudi väärtuson kooskõlas andmetega, mille põhjal see väärtus on leitud.Oletame, et olemitüübis Töötaja oli tuletisatribuut telefonide_arv, mille aluselloodi veerg telefonide_arv tabelisse Töötaja. Veerus telefonide_arv olevväärtus näitab telefoninumbrite arvu, millele helistades on võimalik töötajagakontakteeruda. Loomulikult saaksime selle arvu ka teada kui teeksime päringutabeli Telefon põhjal.Töötaja (isikukood, perenimi, telefonide_arv)Primaarvõti (isikukood)Telefon (isikukood, telefon)Primaarvõti (telefon)Välisvõti (isikukood) Viitab Töötaja(isikukood)Näiteks ei tohi olla võimalik, et tabelis Töötaja on andmed, mille kohaselt ontöötajal isikukoodiga K1 telefoninumbrite arv 2, samas kui päring tabeliTelefon põhjal annab töötaja K1 telefoninumbrite arvuks 3. Samuti tuleb luuaprogrammid, mis muudavad tuletisatribuudi põhjal loodud veerus olevatväärtust juhul, kui muutuvad andmed mille alusel see väärtus on leitud.Näiteks kui kustutatakse rida tabelist Telefon, peab vastava töötajatelefoninumbrite arv vähenema ühe võrra. Sellise ülesande lahendamiseksvõib kasutada andmebaasis trigereid. Kui sellised kontrollid on täies mahusloodud, siis öeldakse, et andmebaasis on kontrollitud andmete liiasus. Kuiselliseid kontrolle ei ole või need on ebapiisavad, siis on andmebaasiskontrollimatu andmete liiasus. Andmete liiasusest andmebaasis ei ole alativõimalik hoiduda ja see pole ka vajalik. Kuid igasugune andmete liiasusandmebaasis peaks olema kontrollitud.Tuletatud väärtuste andmebaasis hoidmine võib muuta mõne päringukoostamise kiiremaks ning võimaldada sellele kiiremini vastus saada. Samastuleb andmebaasi loomisel rohkem vaeva näha, et vältida vastuolulisteandmete andmebaasi sattumist.Veel üks võimalus tuletisatribuudi realiseerimiseks on võtta kasutusele vaade.Näiteks eeltoodud näite korral tuleks luua (baas)tabel Töötaja kus on veerudisikukood ja perenimi. Lisaks tuleb tabelite Töötaja ja Telefon põhjal luuavaade, milles on veerud isikukood, perenimi ja telefonide_arv.35

TTÜ: Loogiline disain. CASE (2012)© Erki Eessaar3.4.5 Täiendavad kitsendusedKontseptuaalses andmemudelis on paljud keerukamad kitsendused pandudkirja tekstilise spetsifikatsioonina. Selliste kitsenduste põhjal tuleb lõpuksvalmivas andmebaasis luua deklaratiivsed kontrollkitsendused võiprotseduursed kontrollprogrammid, mis ei lase nende kitsenduste vastueksivaid andmeid registreerida.Milliseid võimalusi pakub SQL täiendavate kitsenduste realiseerimiseksdeklaratiivsete kitsendustena? SQL-andmebaasis võib mõningate täiendavatekitsenduste jõustamiseks kasutada tabeli CHECK kitsendusi Taolinekitsendus on seotud baastabeliga ning selle kirjelduse oluline osa onotsingutingimus (inglise keeles search condition). Kui andmebaasis on loodudtabeliga T seotud CHECK kitsendus, siis ei luba andmebaasisüsteem lisadatabelisse T ühtegi rida, mille korral on nimetatud otsingutingimuse hindamisetulemus FALSE. Kui rea puhul on otsingutingimuse hindamise tulemus TRUEvõi UNKNOWN (tuletage meelde, et SQL kasutab kolmevalentset loogikat),siis ei takista see kitsendus rea tabelisse lisamist. Näiteks juhul kui tabeli Isikveerus sugu on võimalikud lubatud väärtused 0, 1, 2 ja 9, siis võib sellekitsenduse kontrolliks deklareerida tabeli loomise lauses:CHECK (sugu IN (0, 1, 2, 9))Kui üritame registreerida isikut kelle soo kood on 1, siis on otsingutingimusehindamise tulemus TRUE. Kui üritame registreerida isikut kelle soo kood onmääramata (NULL), siis on otsingutingimuse hindamise tulemus UNKNOWN.Kui üritame registreerida isikut kelle soo kood on 3, siis on otsingutingimusehindamise tulemus FALSE ning andmebaasisüsteem ei luba sellist ridatabelisse.Kontseptuaalses andmemudelis võivad mitmed kitsendused olla formuleeritudkujul Kui p Siis q – kui on täidetud tingimus p, siis peab olema täidetud katingimus q. Date (2007) märgib, et selle kitsenduse võib esitada implikatsioonisisaldava loogikaavaldisena p => q millega loogiliselt samaväärne avaldison:(NOT p) OR q. Taolist avaldist võib kasutada tabeli CHECK kitsenduses.Oletame, et tabelis Isik on veerud isikukood ja sugu. Veerus isikukood tulebregistreerida Eesti Vabariigi isikukood. Tabelis Isik on andmete liiasus, sestisikukoodi esimese numbri järgi on võimalik kindlaks teha millisest soost onisik. Selleks, et vältida vastuoluliste andmete sattumist andmebaasi, tulebjõustada kitsendused:o Kui isikukoodi esimene number kuulub hulka {1, 3, 5, 7, 9}, siis peabisiku soo tähis olema 1.o Kui isikukoodi esimene number kuulub hulka {0, 2, 4, 6, 8}, siis peabisiku soo tähis olema 2.Esimese kitsenduse täidetuse kontrollimiseks kasutatav CHECK kitsendusvõib olla järgmine.CHECK (NOT (substring(isikukood, 1, 1) IN ('1','3','5', '7', '9')) OR (sugu=1));Kitsenduses kasutatakse isikukoodist esimese märgi eraldamiseks funktsioonisubstring. Funktsiooni poole pöördumisel on vasakult esimeseks argumendiks36

TTÜ: Loogiline disain. CASE (2012)© Erki Eessaarveeru nimi. Selles veerus on stringid mille alamstringe otsitakse. Teineargument näitab mitmes stringi märk on otsitava alamstringi esimene märkning kolmas argument on alamstringi kuuluvate märkide arv.Kuidas saaks seda protsessi automatiseerida?Ideaalne andmebaasi projekteerimiseks kasutatav CASE vahend võimaldaksigast mudelisse kirja pandud kitsendusest genereerida automaatseltkitsenduse kontrolliks mõeldud programmikoodi (näiteks CHECK kitsendustedeklaratsioone ja trigereid). See aga eeldab kitsenduse formaalsetkirjeldamist, kasutades mingit spetsiaalkeelt, mis ei pruugi olla lihtsamvõrreldes programmeerimiskeelega milles see kitsendus realiseeritakse. Kuikitsendus on kirja pandud tavakeeles, siis ei oska tarkvara sellestprogrammikoodi genereerida.Teine probleem on, et erinevates andmebaasisüsteemides on võimalusedtaoliste kitsenduste jõustamiseks erinevad ja koodigeneraatorist tuleb igaandmebaasisüsteemi jaoks luua oma versioon. Lisaks on tänapäevaSQL-andmebaasisüsteemides väga piiratud võimalused deklaratiivsetekitsenduste loomiseks.Võib öelda, et mudelis kirjeldatud kitsendustest koodi genereerimine oneesmärk, mille poole liigutakse, kuid mis senimaani pole lõplikult lahendatud.3.5 Tabelite disaini kvaliteedi hindamine ja parandaminePeale seda, kui kontseptuaalse andmemudeli põhjal on leitud esialgneloogiline andmemudel, tuleb leitud tabelitele rakendada normaliseerimiseprotseduuri (vt. teema 9). Tabelid on soovitav viia viiendale normaalkujule.Samuti tuleb tabelite struktuuri ja andmebaasis jõustatud kitsendusi vajaduselparandada nii, et tabelid vastaksid ortogonaalse andmebaasi disaini printsiibinõudmistele (vt. teema 9).Normaliseerimine ja ortogonaalse disaini printsiibi põhimõtete rakendamineaitab vähendada andmebaasis andmete liiasust ja andmete liiasusesttulenevaid andmete muutmise anomaaliaid.37

TTÜ: Loogiline disain. CASE (2012)© Erki Eessaar3.6 Loogilise disaini andmemudeli näideEsitame järgnevalt loogilise andmemudeli võimaliku ülesehituse näite.Esitame UMLi klassidiagrammi baasil koostatud loogilise andmemudelidiagrammi (vt. Joonis 18). Kastid sellel tähistavad tabeleid. Iga tabeli kohtaesitatakse diagrammil nimi ja selles olevate veergude nimed ning nendeandmetüübid. PK tähendab, et veerg on hõlmatud primaarvõtme (primary key)poolt. NN tähendab, et veerg on kohustuslik (not null). FK tähendab, et veergon hõlmatud välisvõtme (foreign key) poolt. Mitteidentifitseeriv (inglise keelesnon-identifying) seos tähendab antud juhul, et õpingukava seisundi koodi eiole vaja kasutada, et identifitseerida õpingukavasid. Seega tabelisOpingukava olev välisvõtme veerg opingukava_seisundi_liik_R_kood, milleabil luuakse seos tabeliga Opingukava_seisundi_liik_R, ei ole hõlmatud tabeliOpingukava primaarvõtme poolt.Lisaks esitame tabelite spetsifikatsioonid (vt. Tabel 1–Tabel 3).Joonis 18 Loogilise andmemudeli diagrammi näide.Tabel 1 Tabelite spetsifikatsioon.Tabeli nimi Kuuluvus registrisse Millise olemitüübi, atribuudivõi seosetüübi põhjal onloodud?Opingukava Õpingukavade register Olemitüüp: ÕpingukavaOpingukava_seisundi_liik_R Klassifikaatorite register Olemitüübid:Õpingukava_seisundi_liik,Klassifikaator38

TTÜ: Loogiline disain. CASE (2012)© Erki EessaarTabel 2 Tabeli Opingukava_seisundi_liik_R veergude spetsifikatsioon.Veeru nimi Tüüp Välja Võimalikud Vaikeväärtus Kohustuslikpikkus väärtusedopingukava_ täisarvJahseisundi_liik_R_koodnimetus tekst 70 Jahkirjeldus tekst 1000 JahPrimaarvõti (opingukava_seisundi_liik_R_kood)Alternatiivvõti (nimetus)Tabel 3 Tabeli Opingukava veergude spetsifikatsioon.Veeru nimi Tüüp Välja Võimalikud Vaikeväärtus Kohustuslikpikkus väärtusedopingukava_id täisarv AutomaatseltJahgenereeritavtäisarv,samm=1matrikli_nr tekst 6 Jahsemester_id täisarv Jahopingukava_ täisarv 1Jahseisundi_liik_R_koodKui tabelisselisatakse uusrida, siisvaikimisiseotakseseeÕpingukavaesimeseloomisjärgseseisundiga.tyypopingukava_id täisarv Eiajapikenduse_lopp kuupäev EiPrimaarvõti (opingukava_id)Alternatiivvõti (matrikli_nr, semester_id)Välisvõti (matrikli_nr) Viitab Yliopilane(matrikli_nr) ON UPDATE CASCADEVälisvõti (semester_id) Viitab Semester(semester_id)Välisvõti (opingukava_seisundi_liik_R_kood) ViitabOpinguava_seisundi_liik_R(opingukava_seisundi_liik_R_kood) ON UPDATECASCADEVälisvõti (tyypopingukava_id) Viitab Tyypopingukava(tyypopingukava_id)Järelliide "_R" tabeli nimes Opingukava_seisundi_liik_R tähendab, et tegemiston klassifikaatori tabeliga (R nagu "reference data").Välisvõtmega seotud vaikimisi määrangud, mis kirjeldavad reaktsiooni viideteterviklikkuse reegli rikkumisele, on ON UPDATE NO ACTION ja ON DELETENO ACTION (vt. peatükk 3.4.3 ). Tabeli Opingukava_seisundi_liik_R veerusopingukava_seisundi_liik_R_kood on klassifikaatori arvulised väärtused, midakasutatakse ka väljaspool andmebaasi. On võimalik, et seda koodi on vajamuuta. Seetõttu kasutame välisvõtte deklareerimisel määrangut ON UPDATECASCADE. Miks ei kasuta me sama välisvõtme puhul määrangut ONDELETE CASCADE? Kujutlege, et keegi kustutab kogemata mõne39

TTÜ: Loogiline disain. CASE (2012)© Erki Eessaarõpingukava seisundi liigi klassifikaatori väärtuse. See võiks põhjustadasadade või tuhandete õpingukavade andmete kustutamise. Samas on niiÕpingukava kui ka Õpingukava_seisundi_liik tugevad olemitüübid jaõpingukava ei sõltu eksistentsiaalselt õpingukava seisundi liigist.Käesolevas näites oleme tabelite ja veergude nimedest eemaldanudtäpitähed. SQL-andmebaasisüsteemid seavad piiranguid selliste tähtedekasutamisele andmebaasiobjektide nimedes. Taolise tähtede asenduse võibteha loogilise disaini käigus, kuid selle võib jätta ka füüsilise disainiülesandeks, kui on teada täpne kasutatav andmebaasisüsteem.3.7 Veel mõned soovitusedJärgnevalt antakse soovitusi, mida tasub SQL-andmebaaside kavandamiselarvesse võtta.3.7.1 Klassifikaatorite haldusVabariigi valitsuse 9. oktoobri 2003. a määruse nr. 255 Klassifikaatoritesüsteemi kehtestamine kohaselt on klassifikaator "riigi või kohalikuomavalitsuse andmekogus kasutatav ühetüübilisi objekte teatud tunnuse võitunnuste hulga alusel liigitav ja üheselt identifitseeriv tähistuseeskiri."Tegelikult võib olla vaja klassifikaatoreid kasutada mistahes andmebaasides.Seega võime öelda, et klassifikaator on andmebaasis kasutatav ühetüübilisiobjekte teatud tunnuse või tunnuste hulga alusel liigitav ja üheseltidentifitseeriv tähistuseeskiri.Teisiti öeldes on klassifikaatorid "mistahes andmed, mida kasutatakseandmebaasis teiste andmete liigitamiseks või andmebaasis olevate andmeteseostamiseks väljaspool organisatsiooni vastutusala oleva informatsiooniga."(Chisholm, 2000).Infosüsteem peab võimaldama klassifikaatorite haldust. Klassifikaatoritehaldamise allsüsteem on infosüsteemi oluline administratiivne allsüsteem.Koos infosüsteemi väljatöötamisega leitakse ka vajalikud klassifikaatorid ningmääratakse kindlaks nende esialgne väärtuste hulk. Need andmed kantakseuude loodavasse andmebaasi esimeses järjekorras. Seejärel saab hakatasisestama andmeid, mida need klassifikaatorid iseloomustavad.Tavakasutajad ei saa ise klassifikaatoreid lisada ja muuta. Klassifikaatoritehaldamine toimub spetsiaalselt väljatöötatud eeskirja kohaselt ning selleks onoma vastutavad töötajad, kes vastutavad klassifikaatorite õigsuse eest ningvolitatud töötajad, kes reaalselt andmebaasi klassifikaatorite andmeidhaldavad (praktikas võib tegu olla ühtede ja samade isikutega). Klassifikaatorimuutmise aluseks võib olla klassifikaatori kasutaja ettepanek või vastavarahvusvahelise alusklassifikaatori muutumine.Klassifikaatorid võivad olla ulatuselt rahvusvahelised, regionaalsed,riigisisesed või organisatsioonisisesed. Näited rahvusvahelistestklassifikaatoritest on:• riikide klassifikaator – ISO 3166 Codes (Countries). Näiteks on standardikohaselt Eesti Vabariiki tähistav kahetäheline kood "EE" (Chisholm, 2000).40

TTÜ: Loogiline disain. CASE (2012)© Erki Eessaar• valuutade klassifikaator – ISO 4217 Codes (Currencies). Näiteks onstandardi kohaselt Eesti krooni tähistav 3-täheline kood "EEK" janumbriline kood 233 (Chisholm, 2000).• soo klassifikaator – ISO 5218 Codes (Human Sexes)Täheühend ISO tähistab rahvusvahelist standardiseerimisega tegelevatorganisatsiooni International Organization for Standardization.Statistikaameti kodulehelt (http://www.stat.ee/klassifikaatorid) on võimalikleida andmed Eestis kasutatavate majanduslike klassifikaatorite kohta.Enamik nendest on loodud tõlke või riigisisese versioonina rahvusvahelisteklassifikaatorite alusel.Kui erinevates süsteemides on kasutusel samasugused klassifikaatorid(samasuguste võimalike väärtustega), siis lihtsustab see tunduvalt nendesüsteemide vahel andmete vahetamist ja nendest süsteemidest pärit andmeteintegreerimist (näiteks andmeaitades). Klassifikaatorid on seega nagu ühinekeel, mis võimaldavad erinevatel süsteemidel üksteisest aru saada. Seega,kui hakatakse looma organisatsioonile infosüsteemi, siis tuleks kasutadamaksimaalselt rahvusvahelisi ja riigisiseseid klassifikaatoreid, selle asemel, etjalgratast leiutada ning töötada organisatsioonisiseseks kasutamiseks väljaklassifikaator, mis tegelikult on juba olemas.Vabariigi valitsuse 9. oktoobri 2003. a määruse nr. 255 Klassifikaatoritesüsteemi kehtestamine sätestab, et "Riigi- ja kohaliku omavalitsuse asutusedon kohustatud nende poolt hallatavates andmekogudes kasutamaandmekogude riiklikus registris registreeritud klassifikaatoreid. Muudeandmekogude puhul on klassifikaatorite kasutamine soovituslik."3.7.2 Klassifikaatorite hoidmine SQL-andmebaasisKuidas hoida klassifikaatoreid SQL-andmebaasis? Soovitav on luua igaklassifikaatori kohta eraldi tabel. Iga klassifikaatori väärtuse kohta võiks sellestabelis olla vähemalt tekstiline või numbriline kood, koodile vastav inimeselemõistetav nimetus ja väärtuse vabas vormis tekstiline kirjeldus.Struktuuri järgi võib klassifikaatoreid liigitada lineaarseteks (ühe tasemega) jahierarhilisteks (mitme tasemega ja puustruktuuri moodustav). Hierarhiliseklassifikaatori väärtuste hoidmiseks vajaliku tabeli loomisel lähtuge juhistest1:M rekursiivse seosetüübi põhjal tabeli loomise kohta (vt. peatükk 3.3.6.2 ).Vaatleme näitena tabeleid, mida on vaja lepingute andmete hoidmiseks. Igaleping on mingit liiki. Esitame järgnevalt lepingu liikide koodid ning neilevastavad nimetused (tegemist ei ole ametliku klassifikaatoriga, vaid näitega).• 1 – Ostuleping• 2 – Müügileping• 3 – Tööleping• 4 – Kindlustusleping• 5 – Tarneleping41

TTÜ: Loogiline disain. CASE (2012)© Erki EessaarIgal lepingul on hetkel kehtiv seisund. Need seisundid leitakse lepinguseisundidiagrammilt. Esitame järgnevalt lepingute seisundite liikide koodidning neile vastavad nimetused (tegemist ei ole ametliku klassifikaatoriga, vaidnäitega).• 1 – Koostamisel• 2 – Kinnitamisel• 3 – Kinnitatud• 4 – Peatatud• 5 – Tühistatud• 6 – ArhiveeritudNii lepingu liikide klassifikaator kui ka lepingu seisundi liikide klassifikaator onlineaarne klassifikaator. Sellise klassifikaatori väärtuse unikaalseksidentifikaatoriks klassifikaatori piires on nii kood kui ka nimetus.Andmebaasis võiks luua tabelid:Lepingu_liik_R (lepingu_liik_R_kood, nimetus, kirjeldus)Primaarvõti (lepingu_liik_R_kood)Alternatiivvõti (nimetus)Lepingu_seisundi_liik_R (lepingu_seisundi_liik_R_kood, nimetus, kirjeldus)Primaarvõti (lepingu_seisundi_liik_R_kood)Alternatiivvõti (nimetus)Leping(leping_id, sõlmimise_kuupäev, kehtivuse_alguse_aeg,kehtivuse_lõpu_aeg, kirjeldus, liik, kehtiv_seisund)Primaarvõti (leping_id)Välisvõti (liik) Viitab Lepingu_liik_R (lepingu_liik_R_kood) ON UPDATECASCADEVälisvõti (kehtiv_seisund) Viitab Lepingu_seisundi_liik_R(lepingu_seisundi_liik_R_kood) ON UPDATE CASCADEMillised on klassifikaatorite tabelite kasutamise eelised? Miks mitte lisadatabelisse Leping veerud, kus kasutaja saab vabas vormis tekstina panna kirjaandmed lepingu liigi ja lepingu seisundi kohta.• Andmebaasi kasutava rakenduse kasutajaliideses saab kasutajale näidatanimekirja klassifikaatori väärtustest. Kasutaja ei saa teha omaloomingutning registreerida lepinguid, mis on olematut liiki või on olematusseisundis.• Klassifikaatori väärtuse koodiga seotud nimetus ja kirjeldus muudavadselle koodi lõppkasutajale arusaadavaks.• Ühesuguste klassifikaatorite kasutamine erinevates süsteemides, muudabnendes süsteemides olevate andmete üheskoos kasutamise lihtsamaks.Klassifikaatorite väärtuseid ei maksa sisse kodeerida rakendusprogrammi,sest klassifikaator võib muutuda (näiteks lisanduvad uued väärtused) ning seenõuaks ka rakenduse ümberkirjutamist.Mõnikord üritatakse hoida kõikide klassifikaatorite väärtuseid ühes tabelis.Soovitame sellisest lahendusest hoiduda. Vaatleme järgnevalt kahte42

TTÜ: Loogiline disain. CASE (2012)© Erki Eessaarvõimalikku lahendust, kuidas hoida SQL-andmebaasis klassifikaatoriteandmeid.Organisatsioonis töötavad töötajad, kes on mingist soost ja saavad palkamingis valuutas. Iga valuuta kehtib käesoleval ajahetkel nullis või rohkemasriigis ning igas riigis kehtib käesoleval ajahetkel üks või rohkem valuutat.Üheks võimalikuks lahenduseks on kasutada universaalset klassifikaatoritetabelit (kutsume seda Lahendus 1) (vt. Joonis 19). Lisaks tuleb luua tabelKlassifikaatori_seos, et registreerida võimalikke seoseid klassifikaatoriteväärtuste vahel (näiteks seosed riikide ja valuutade vahel). Iga klassifikaatoriväärtus on mingit liiki. Ka klassifikaatori liik on klassifikaator (vaadakevälisvõtme veergu klassifikaatori_liik_id tabelis Klassifikaator, mis viitab samatabeli primaarvõtmele).Klassifikaatori ja Klassifikaatori_seose vahel on identifitseeriv seos (inglisekeeles identifying relationship), sest klassifikaatorite väärtuste vahelise seoseidentifitseerimiseks on vaja kasutada klassifikaatorite väärtusteidentifikaatoreid. Tabeli Klassifikaatori_seos primaarvõti hõlmab välisvõtmeveerge, mille abil luuakse seos tabeliga Klassifikaator. TabelileKlassifikaatori_seos vastav olemitüüp on nõrk olemitüüp.Veergudes, mille nime järelliide on "_ingl_k" hoitakse ingliskeelseid nimetusija kirjeldusi, mis võivad pärineda rahvusvahelisest klassifikaatorist.Teiseks lahenduseks on luua iga klassifikaatori (Sugu, Riik, Valuuta) kohtaeraldi tabel (kutsume seda Lahendus 2) (vt. Joonis 20).Tootajatootaja_kood : INTEGERperenimi : VARCHAR(50)palk : DECIMAL(10, 2)klassifikaator_sugu_id : INTEGERklassifikaator_palk_id : INTEGER0..*0..*11Klassifikaatori_seosklassifikaator_1_id : INTEGERklassifikaator_2_id : INTEGERklassifikaator_seose_liik_id : INTEGER0..*0..*0..* 111Klassifikaatorklassifikaator_id : INTEGERtekstiline_kood : VARCHAR(10)tekstiline_kood_2 : VARCHAR(10)numbriline_kood : INTEGERklassifikaatori_liik_id : INTEGERnimetus : VARCHAR(100)nimetus_ingl_k : VARCHAR(100)kirjeldus : VARCHAR(1000)kirjeldus_ingl_k : VARCHAR(1000)10..*Joonis 19 Universaalne klassifikaatorite tabel.43

TTÜ: Loogiline disain. CASE (2012)© Erki EessaarSugu_Rnumbriline_kood : SMALLINTnimetus : VARCHAR(50)nimetus_ingl_k : VARCHAR(50)kirjeldus : VARCHAR(1000)kirjeldus_ingl_k : VARCHAR(1000)10..*Tootajatootaja_kood : INTEGERperenimi : VARCHAR(50)sugu_numbriline_kood : SMALLINTvaluuta_tekstiline_kood : CHAR(3)palk : DECIMAL(10, 2)Riik_Rtekstiline_kood_2 : CHAR(2)tekstiline_kood_3 : CHAR(3)numbriline_kood : SMALLINTnimetus : VARCHAR(50)nimetus_ingl_k : VARCHAR(50)kirjeldus : VARCHAR(1000)kirjeldus_ingl_k : VARCHAR(1000)11..*0..*10..*1Valuuta_Rtekstiline_kood : CHAR(3)numbriline_kood : SMALLINTsymbol : VARCHAR(2)nimetus : VARCHAR(50)nimetus_ingl_k : VARCHAR(50)kirjeldus : VARCHAR(1000)kirjeldus_ingl_k : VARCHAR(1000)Riigi_valuutavaluuta_R_tekstiline_kood : CHAR(3)riik_R_tekstiline_kood_2 : CHAR(2)Joonis 20 Eraldi klassifikaatorite tabelid.Miks eelistada universaalset klassifikaatorite tabelit (Lahendus 1)?• Lahendus võib tunduda "paindlikum", sest jooksvalt saab lisada uusiklassifikaatoreid ilma andmebaasi struktuuri muutmata.• Andmebaasi loomisel tuleb teha vähem tööd, sest sõltumataklassifikaatorite arvust tuleb luua kaks tabelit.Miks eelistada lahendust, mille kohaselt luuakse iga klassifikaatori kohtaeraldi tabel (Lahendus 2)?• Erinevatel klassifikaatoritel on erinevad atribuudid. Lahenduse 1 korraltekib tabel kus on palju NULLe.• Koodidele saab jõustada täiendavaid deklaratiivseid kitsendusi. Näitekstabelis Riik_R veerus tekstiline_kood_3 olev väärtus peab alati koosnemakolmest tähemärgist.• Välisvõtmete poolt hõlmatud veergudes, mille abil luuakse seosedklassifikaatorite tabelitega, on kasutajale sisulise tähendusega väärtused.Näiteks Lahendus 1 korral on tabeli Tootaja veerus klassifikaator_palk_idtäisarv, millele vastavat klassifikaatori väärtuse koodi ja nimetust peabotsima tabelist Klassifikaator. Samas Lahendus 2 korral on tabeli Tootajaveerus valuuta_tekstiline_kood sisulise tähendusega väärtus (valuutakood).• Päringud on lihtsamad.Näide: Leia töötaja koodid ja nende soo numbrilised koodid.Lahenduse 1 korral oleks päring:44

TTÜ: Loogiline disain. CASE (2012)© Erki EessaarSELECT tootaja_kood, Klassifikaator.numbriline_kood ASsugu_numbriline_kood FROM Tootaja INNER JOIN Klassifikaator ONTootaja.klassifikaator_sugu_id=Klassifikaator.klassifikaator_id;Lahenduse 2 korral oleks päring:SELECT tootaja_kood, sugu_numbriline_kood FROM Tootaja;Näide: Leia riikide 2-tähelised tekstilised koodid ja eestikeelsed nimed.Lahenduse 1 korral oleks päring:SELECT Kl.tekstiline_kood AS tekstiline_kood_2, Kl.nimetus FROMKlassifikaator Kl INNER JOIN Klassifikaator AS Kl2 ONKl.klassifikaatori_liik_id=Kl2.klassifikaator_id WHERE Kl2.nimetus='Riik';Lahenduse 2 korral oleks päring:SELECT tekstiline_kood2, nimetus FROM Riik_R.Võib väita, et päringute lihtsustamiseks saab lahenduse 1 korral luuaerinevate klassifikaatorite jaoks vaated (virtuaalsed tabelid). Kuid miks siisüldse luua ühine baastabel?3.7.3 Väärtuste puudumineHoiduge nii palju kui võimalik NULLidest ridade väljades. Kasutagespetsiaalseid väärtuseid, et registreerida väärtuse puudumist ning sellepõhjuseid. Klassifikaatorite puhul võib selleks kasutada spetsiaalseidklassifikaatori väärtuseid (vt. Tabel 4). Lepingu liigi koodi 6 tuleb kasutada, kuiregistreeritakse andmed lepingu kohta, mille liik on teada, kuid see liik eikuulu teadaolevate liikide hulka. Lepingu liigi koodi 7 tuleb kasutada, kuiregistreeritakse andmed lepingu kohta mille liik ei ole teada.Tabel 4 Lepingu liikide klassifikaatori võimalikud väärtused.lepingu_liik_R_kood nimetus1 Ostuleping2 Müügileping3 Tööleping4 Kindlustusleping5 Tarneleping6 Muu leping7 Lepingu liik teadmata3.7.4 Seisundite klassifikaatorKasutage seisundite andmete registreerimiseks seisundite klassifikaatoreid.Oletame, et soovite hoida andmebaasis andmeid tellimuste kohta.Süsteemianalüüsi käigus on koostatud tellimuse seisundidiagramm (vt.Joonis 21).45

TTÜ: Loogiline disain. CASE (2012)© Erki EessaarKoostamiselKlient loobub tellimusestKustutatudKlient esitab tellimuse[ tellimuselvähemalt üks rida; igas reas kogussuurem kui 0 ]EsitatudKliendihaldur veendubtellimuse korrektsuses jatäidetavusesKliendihaldur avastab, etklient on esitanudvaleandmeid või tellimustpole võimalik täitaKinnitatudKlient ei tasutähtajaks tellimuseeestTühistatudKlient tasub tellimuse eestTasutudTellitud kaup viiaksekliendlile kohaleTäidetudJoonis 21 Tellimuse seisundidiagramm.Iga tellimuse kohta peab olema võimalik andmebaasis olevate andmete põhjalkindlaks teha, millises seisundis see tellimus parajasti viibib. Millised tabelidvõimaldavad kõige paremini seda eesmärki saavutada?Halvem lahendus on luua tabel:Tellimus(tellimuse_nr, on_koostamisel, on_esitatud, on_kinnitatud,on_tasutud, on_täidetud, on_tühistatud, on_kustutatud)Primaarvõti (tellimuse_nr)Veerud, mille eesliide on "on_" on tõeväärtuse tüüpi. Iga selline veerg vastabühele seisundile, milles tellimus võib viibida. Kui tabelis Tellimus olevas reason sellisele veerule vastavas väljas väärtus TRUE, siis selle rea poolt esitatavtellimus on vastavas seisundis. Sellise disaini probleemid on:• Seisundite hulga muutumisel tuleb muuta tabeli struktuuri• Tabeliga Tellimus seoses on vajalikud kitsendused, mis takistavadebakorrektsete andmete sattumist andmebaasi. Näiteks tellimus ei saaolla samal ajal koostamisel ja kustutatud. Järelikult ei tohi tabelis Tellimusolla ühtegi rida kus on_koostamisel=TRUE ja on_kustutatud=TRUE.Parem lahendus on luua tabelid:Tellimuse_seisundi_liik_R(tellimuse_seisundi_liik_R_kood, nimetus, kirjeldus)Primaarvõti (tellimuse_seisundi_liik_R_kood)Alternatiivvõti (nimetus)46

TTÜ: Loogiline disain. CASE (2012)© Erki EessaarTellimus (tellimuse_nr, tellimuse_seisundi_liik_R_kood)Primaarvõti (tellimuse_nr)Välisvõti (tellimuse_seisundi_liik_R_kood) ViitabTellimuse_seisundi_liik_R(tellimuse_seisundi_liik_R_kood);Tellimuse_seisundi_liik_R on seisundite klassifikaatori tabel. Andmed, midalisada tabelisse Tellimuse_seisundi_liik_R leitakse tellimuseseisundidiagrammi põhjal.Seisundidiagramm määrab ka lubatud seisundi üleminekud. Näiteks Joonis21 kohaselt on lubatud otsene üleminek seisundist koostamisel seisundisseesitatud. Samas ei ole lubatud otsene üleminek seisundist koostamiselseisundisse tasutud. Andmebaasis tuleks luua kitsendused, mis piiravadlubatud andmemuudatusi tabelis Tellimus. Üheks lahenduseks oleks luuatabel kus registreeritakse lubatud seisundi üleminekud. Samuti tuleb luuatrigerid, mis käivituvad andmete muutmisel tabelis Tellimus ning mille abilkontrollitakse (tabelis Lubatud_tellimuse_seisundi_muutus olevate andmetepõhjal), kas tellimuse seisundi muutus on lubatud või mitte. Juhul kui toimubmittelubatud seisundi üleminek, siis triger katkestab andmemuudatuse.Lubatud_tellimuse_seisundi_muutus(algseisund, lõppseisund)Primaarvõti (algseisund, lõppseisund)Välisvõti (algseisund) ViitabTellimuse_seisundi_liik_R(tellimuse_seisundi_liik_R_kood)Välisvõti (lõppseisund) ViitabTellimuse_seisundi_liik_R(tellimuse_seisundi_liik_R_kood);Sellise tabeli kasutamise korral pole vaja seisundidiagrammi muutumiselhakata trigerit ümber kirjutama, vaid tuleb muuta andmebaasisseisundimuudatuste kirjeldusi (tabelis Lubatud_tellimuse_ seisundi_muutus).3.7.5 Vektorkodeerimine e. semantiline kodeerimine.Vektorkodeerimine tähendab, et suur hulk informatsiooni koondatakse ühtestringi, kusjuures igas stringi positsioonis oleval sümbolil on oma tähendus.Näiteid vektorkodeerimise kasutamise kohta:• isikukood• õppeaine kood ülikoolis• lõputöö kood ülikoolisNäide: EV Isikukood – Esimene number määrab sünni sajandi ja isiku soo.Numbrid 2-7 määravad isiku sünni kuupäeva. 8-10 number on järjenumberühel ja samal päeval sündinuile. Üheteistkümnes number on kontrollnumber,mis arvutatakse standardis toodud eeskirja kohaselt.Üheks sellise kodeerimise puuduseks on asjaolu, et mingil hetkel võib tekkidavajadus seda kodeeringut muuta.47

TTÜ: Loogiline disain. CASE (2012)© Erki EessaarEsimene number:1 – 19. sajandil sündinud mees2 – 19. sajandil sündinud naine3 – 20. sajandil sündinud mees4 – 20. sajandil sündinud naine5 – 21. sajandil sündinud mees6 – 21. sajandil sündinud naine7 – 22. sajandil sündinud mees8 – 22. sajandil sündinud naine9 – 23. sajandil sündinud mees0(?) – 23. sajandil sündinud naine24 -ndal sajandil tekib probleem. Tuleb muuta koodi.Isikukoodi põhjal saab teada inimese sünniaja ja soo. Tekib küsimus, milliseidveerge peaks sisaldama isikute kohta käiv tabel.• Nii veerg isikukood, kui ka veerud sünniaeg ja sugu. Tekib andmeteliiasus. Tuleb kirjutada kontrollprotseduurid, mis kontrolliksid et isikukoodipõhjal leitavad sünniaeg ja sugu on samad kui veergudes sünniaeg jasugu.• Ainult veerg isikukood. Päringutes sünniaja ja soo põhjal tuleb hakatakasutama funktsioone. See muudab päringu formuleerimise keerukamaks.Funktsioonid tuleb ümber kirjutada, kui isikukoodi struktuuri peaksmuudetama. Mis saab siis, kui mingil hetkel otsustakse riigi poolt taolisest"intelligentsest" isikukoodist loobuda? Mis saab inimestest, kellel poleisikukoodi (välismaalased, illegaalid)?Näide: Lõputöö kood TTÜ-s koostatakse järgmiste reeglite kohaselt (juhendkinnitatud rektori 20.04.2006 käskkirjaga nr 57):• Lõputöö kood koosneb seitsmest sümbolist, milleks on numbrid ja tähed.• Koodi esimesed kolm sümbolit tähistavad struktuuriüksust (õppetool,lektoraat, asutus), kus lõputöö tehti. Struktuuriüksus määratakse lõputööjuhendaja järgi.• Koodi neljas sümbol tähistab lõputöö liiki, mis on üks järgnevatest:o 2 – diplomiõppe lõputööo 3 – rakenduskõrgharidusõppe lõputööo 4 – 3+2 õppekavade süsteemi bakalaureuseõppe lõputööo 5 – 4+2 õppekavade süsteemi bakalaureuseõppe lõputööo 6 – inseneriõppe lõputööo 7 – 3+2 õppekavade süsteemi magistriõppe lõputööo 8 – 4+2 õppekavade süsteemi magistriõppe lõputööo 9 – doktoritööo 0 – õpetajakoolituse lõputöö• Koodi viies kuni seitsmes sümbol on kõikidel lõputöödel 0LT.Näiteks, kui tegemist on 3+2 õppekava bakalaureuseõppe lõputööga, millejuhendaja on TTÜ Informaatikainstituudi, infosüsteemide õppetooli töötaja, siisoleks lõputöö kood IDU40LT.Näide: Oletame, et on vaja registreerida kauba andmeid, sealhulgas kaubakategooria. Iga kaup kuulub nulli või rohkemasse kategooriasse. Igassekategooriasse kuulub null või rohkem kaupa.48

TTÜ: Loogiline disain. CASE (2012)© Erki EessaarKaup(kauba_kood, nimetus, kogus, kategooria)Primaarvõti (kauba_kood)Süsteemianalüüs näitab, et praegusel hetkel on teada viis kaupadekategooriat. Tabeli Kaup veerus kategooria on lubatud sisestada fikseeritudpikkusega string (pikkusega viis märki), mis koosneb 0-dest ja 1-dest. Igapositsioon stringis tähistab ühte kategooriat. Kui sellel positsioonil on väärtus"1", siis kaup on antud kategoorias, ning kui positsioonis on väärtus "0" siiskaup ei ole antud kategoorias.Näiteks string "11010" näitab, et kaup on kategooriates "A", "B" ja "D". Kaupei kuulu kategooriasse "C" ja "E".Vektorkodeerimise puudused. Ilma dekodeerimise algoritmi teadmata on need andmed kasutajalekasutud. Andmete kasutamiseks mõeldud rakendus peaks need andmed "tõlkima"kasutajale arusaadavale kujule. Selliste andmete alusel otsimine ja päringu tulemuste sorteerimine võibnõuda funktsioonide kasutamist. See välistab omakorda paljudesandmebaasisüsteemides indeksi kasutamise otsingu läbiviimisel. Kodeeringu muutumine nõuab andmebaasi muutmist. Võib olla vajalikmuuta veeru pikkust ja sellega seotud kontrollkitsendusi (näitekskitsendust, mis kontrollib, et igas positsioonis võib olla vaid väärtus 0 ja 1).Samuti tuleb muuta kodeerimiseks ja dekodeerimiseks kasutatavaidprogramme ning võib olla vaja muuta kodeeritud andmeid kasutavaidprogramme.Kui kood on ametlikult kasutusele võetud, siis peab seda kasutama. Kuid ärgeise sarnaseid koode välja mõelge (vaadake kolmandat näidet).3.7.6 Vaba teksti väljadÜheks andmebaasides kohatavaks probleemiks on vabas vormis tekstisisestamist võimaldavate veergude liigne kasutamine. See viitabsüsteemianalüüsi puudulikkusele. Mõnikord võib algajailt andmebaasiprogrammeerijailt kuulda väidet, et juhul kui kasutajatel tekivad täiendavadnõudmised andmebaasi salvestatavate andmete osas, siis võib need andmedsalvestada vabas vormis kommentaarina. See ei ole hea lahendus, sestselliste andmete põhjal on võimatu teha täpseid päringuid.Kujutlege, et andmebaasis on registreeritud kommentaarid:Kommentaar1: "Arve kirjutati välja 21.01.2002. Arve maksti 25.01.2002"Kommentaar2: "Arve loodi 21. märts 2002. Arve tasutud 25.04.2002"Kommentaar3: " Arve tasutud 12.01.2003 Arve loodud: 21. märts 03. "Kommentaar4: " Tühistatud 12.01.2004"Kommentaar5: "2003-01-22 otsustati, et klient võib tasuda arve eest kahesosas"49

TTÜ: Loogiline disain. CASE (2012)© Erki EessaarKuidas siit andmebaasikeele päringuga leida arve maksmise kuupäevvõi arve loomise ja maksmise aja vaheline intervall päevades?Andmebaasi projekteerimise käigus peab püüdma maksimaalselt tulevasinõudmisi andmetele ette näha. Kui siiski tekib vajadus täiendavate andmetesalvestamise järgi, siis tuleb andmebaasi struktuuri ja kitsendusi täiendada, etvõimaldada uute andmete registreerimist.4 Rakenduse loogiline disainAndmebaasi projekteerimine eeldab ka andmebaasi kasutavate/uuendavaterakenduste projekteerimist (disaini). Andmebaasi rakendustena vaatamepraegu lihtsaid registri tüüpi rakendusi, mis realiseerivad elementaarseidandmete registreerimise ja päringu protsesse (teenuseid). Viimaseidkäsitleme andmebaasiliidestena.Andmebaasiliides koosneb kasutajaliidesest (nt. leheküljed, ekraanivorm,trükis) ning kasutajaliidese (sündmuste) kaudu käivitatavatest andmebaasitransaktsioonidest. Andmebaasi transaktsioonid on andmebaasioperatsioonide jadad.Lihtsa registritüüpi rakenduse kihid:KasutajaliidesTransaktsioonidAndmebaasi operatsioonidAndmedAndmebaasiliidesJoonis 22 Tarkvarasüsteemi kihiline arhitektuur.Tarkvarasüsteemide kihtide kohta lugege näiteks raamatut:Fowler, M. Patterns of Enterprise Application Architecture. Addison WesleyProfessional, 2002. 560 p.Registri tüüpi rakenduse loogiline disain sisaldab:• Kasutajaliideste loogiline projekteerimine.• Kasutajaliidese kaudu tehtud tegevuste käivitatavate transaktsioonideprojekteerimine. Üks transaktsioon võib koosneda mitmestandmebaasioperatsioonist. Andmebaasioperatsioonid võib realiseeridaandmebaasis loodud salvestatud protseduuridena.Rakendus koosneb erinevatest töökohtadest, mida kasutavad mingipädevusala liikmed oma töö-ülesannete läbiviimiseks.50

TTÜ: Loogiline disain. CASE (2012)© Erki Eessaar4.1 Kasutajaliideste loogiline projekteerimineKasutajaliidese loogilise projekteerimise käigus koostatakse reaalsetekasutusjuhtude kirjeldused.Soovitus! Reaalsete kasutusjuhtude kirjeldusi on mõtet koostada vaid kõigeolulisemate ja kriitilisema tähtsusega kasutusjuhtude kohta. Koostamine jamuutmine on üsnagi töömahukas.Kasutajaliidest loogiline projekteerimine toimub loogiliste töökohtade kaupa.Reaalne kasutusjuht kirjeldab süsteemi kasutamise protsessi konkreetselt,disainitaseme täpsusega, ekraanivormi väljade täitmise tasemel. Pöörataksetähelepanu sisend/väljund tehnoloogiatele. Näiteks kui kasutatakse graafilistkasutajaliidest, siis sisaldab reaalse kasutusjuhu kirjeldus süsteemi kasutajaja süsteemi omavahelise suhtluse kirjeldust, kusjuures viidataksekasutajaliidese elementidele, mida selle käigus kasutatakse. Reaalsekasutusjuhu tekstikirjeldus sisaldab samu komponente kui detailanalüüsis.Erinevus seisneb selles, et kirjeldatakse kasutajaliidese elementidekasutamist ja selle tulemusel käivituvad transaktsioonid.Selleks, et saaks luua reaalsete kasutusjuhtude mudelit, peavad olemaloodud analüüsitaseme kasutusjuhud. Reaalsed kasutusjuhud on kasulikudjuhul, kui arendajad või klient nõuavad väga detailset kasutajaliidese kirjeldustenne seda kui alustatakse realiseerimist.Kasutajaliidese disainimise käigus mõelge läbi navigatsioonisüsteem.Välisvõtmete väärtuse valiku realiseerimiseks kasutatakse liitbokse (ingl. k.combo box), loendibokse (ingl. k. list box) või hüpikaknaid. Välisvõtmeteväärtuste valik toimub üldjuhul nime järgi ka siis, kui seostavasse tabelissekirjutatakse kood või number (ka pärast väärtuse valimist peab ekraanilejääma näha nimi, mitte number). Kasutajaliidese osad peavad olemaomavahel loogiliselt seotud (näiteks tellimuste ja tellitud kaupadesisestamine). Kasutajaliidese disainimisel võib kasutada mustreid. Vaadakenäiteks:Tidwell, J. COMMON GROUND:A Pattern Language for Human-ComputerInterface Design [WWW]http://www.mit.edu/~jtidwell/interaction_patterns.html (02.05.2010)wu pattern language [WWW] http://www.trireme.com/WU/browse.htm(02.05.2010)51

TTÜ: Loogiline disain. CASE (2012)© Erki EessaarNäide:Joonis 23 Akna kujunduse diagramm.Joonis 23 esitab tegelikult aknakujunduse diagrammi. Aknakujundusediagramm defineerib akna, kui osa süsteemi kasutajaliidesest. See esitabakna üldise väljanägemise, kuid ei pea sisaldama kõiki pisemaid detaile.Tegemist on prototüübiga. Selle võib joonistada mõne joonistusvahendi abil(nt. Visio) või võib kasutada ka prototüübi ekraanivormide pilte.Järgnevalt on esitatud fragment reaalse kasutusjuhu kirjeldusest.Kasutusjuht: Õpingukava koostamineTüüp: Reaalne kasutusjuhtStsenaarium (tüüpiline sündmuste järjestus):1. Üliõpilane alustab õpingukava koostamist.2. Süsteem kontrollib kas üliõpilasel on õigus õpingukava esitamiseks(OP3.1). Õpingukava võib koostada või muuta semestri esimese kahenädala jooksul või dekaani nõusolekul ka hiljem.3. Süsteem kontrollib, kas üliõpilasel on juba loodud semestri õpingukava(OP3.2). Kui ei ole, siis loob uue õpingukava (OP3.3) ja registreeribõpingukava loomise sündmuse (OP0).4. Süsteem väljastab õpingukava koostamise maketi (avab joonisel 19näidatud ekraanivormi) koos üliõpilase nime ja üliõpilaskoodiga (väli D),52

TTÜ: Loogiline disain. CASE (2012)© Erki Eessaarkäesoleva semestriga (väli E) ja õpingukava hetke seisundiga (väli G)(OP3.4).5. Üliõpilane otsib õppeainet (vajutab nupule K) (käivitub kasutusjuhtõppeaine otsimine).6. Üliõpilane lisab uue õppeaine õpingukavasse.7. Süsteem kuvab õppeaine nime (väli N) ja õppeaine ainepunktide arvu(väli O) Samuti kuvatakse moodulite nimekirja (väli M) (OP3.5), kuhuõppeaine paigutada ja õppeainega antud semestril seotud piiranguid (väliJ) (OP3.6).Mõned soovitused kasutajaliidese disaini jaoks:• Arusaadavad pealkirjad.• Süsteemi seisund peab olema nähtav.• Navigeerimine süsteemis peab olema lihtne.• Väljad tuleb loogiliselt grupeerida.• Järjekindel terminoloogia ja lühendite kasutamine.• Vältida akna ülekuhjamist kasutajaliidese elementidega.• Vältida aknas liiga suure kasutamata ruumi jätmist.• Järjekindel ja mõõdukas värvide kasutamine.• Sisestusvälja väärtuse lisamisel peab kasutaja saama visuaalselt hinnata,kui palju sümboleid saab sellesse välja lisada.• Välisvõtme väärtuseid peab kasutaja saama valida.• Lihtne kursori liikumine. Tab-klahvi kasutamine.• Järjekindel graafiliste sümbolite kasutamine. Ühesuguse pildiga nupudpeavad tegema kogu rakenduse ulatuses ühte ja seda sama asja.• Kui graafilise sümboli tähendust tuleb eraldi seletada, kasutage selleasemel teksti.• Lühikorraldused peavad säilitama kõikjal oma tähenduse• Valikulised või siis kohustuslikud väljad tuleb selgelt esile tuua.Esiletoomine peab olema ühesugune kogu rakenduse ulatuses.• Kasutajatel tuleb aidata vigadest aru saada ja neid parandada.• Loetavad ja arusaadavad juhendid. Loetavad nii keelekasutuse kui kateksti suuruse ja liigendatuse mõttes).• Mittesobivate väärtuste sisestamise korral tuleb esitada veateade, misaitab kasutajal probleemist aru saada ja seda lahendada. Veateated võiblogida.53

TTÜ: Loogiline disain. CASE (2012)© Erki EessaarHalb näide: Ülikooli õppeinfosüsteemi tarkvarasüsteemi peamenüü.Ülikooli infosüsteemAineSemesterÕpingukavaEkraaninupule vajutadesavaneb aken, kus saabregistreerida andmeidsellesse tabelisseÕppimineÜliõpilaneÕppekavaAine õpingukavasOKJoonis 24 Halvasti kujundatud ekraanivormi näide.4.2 Transaktsioonide loogiline projekteerimineLuuakse transaktsioonide spetsifikatsioonid tekstilist ja/või graafilistkirjelduskeelt kasutades. Spetsifikatsioon nimetab andmebaasi operatsioonid,millest see transaktsioon koosneb. Iga transaktsioon tuleb siduda mõnekasutaja poolse toiminguga ekraanivormil.Transaktsioon on tegevus või tegevuste jada, mis küsib andmeidandmebaasist või muudab andmeid andmebaasis ja mida viib läbi kas ükskasutaja või rakendusprogramm. Transaktsioonist võib mõelda kuiandmebaasi operatsioonide jadast.Transaktsioon on tingitud reaalse maailma sündmusest, mille tulemusel tulebandmebaasist midagi otsida või viia andmebaasi olevad andmed kooskõllareaalses maailmas toimunud muutusega. Kui transaktsiooni ei suudetalõpetada, peab andmebaasisüsteem tagama, et kõik transaktsiooni pooltandmebaasis tehtud muudatused tühistatakse. Kui transaktsioon õnnestub,tuleb kõik tehtud muudatused andmebaasis salvestada.Üks transaktsioon võib hõlmata üht või mitut andmebaasioperatsiooni.Näide: Klient kannab pangas raha ühelt arvelt teisele.Transaktsioonide liigid.• Andmete küsimise transaktsioon.• Andmete muutmise transaktsioon.• Sega-transaktsioon (toimub nii andmete küsimine kui ka muutmine).54

TTÜ: Loogiline disain. CASE (2012)© Erki Eessaar5 CASE vahendidCASE tähendus:ComputerAided Assisted AutomatedSoftware SystemEngineeringCASE vahend on tarkvarasüsteem, mis aitab tarkvara arendajat ühe võirohkema tarkvara arendustsükli etapi jooksul.5.1 CASE vahendi kasutamisest tulenev võimalik kasu• Vähendab kulutusi, eriti seoses tarkvara hooldamisega.• Parandab tarkvara kvaliteeti.• Kiirendab arendusprotsessi.• Suurendab tootlikust.5.2 Üldised nõuded CASE vahenditele• Hea graafika.Võimaldab kirjeldada süsteemi kasutades mudeleid. Mudelitel on erinevatesitusviisid – diagrammid, tekst, maatriksid jne. Teisisõnu – mudel ei peaolema visuaalne (diagramm).• Peab olema võimalik mudeleid koguda, säilitada ja hallata.• Peab olema võimalik mudelite elemente sirvida (tavaliselt kuvataksemudelite elemente hierarhiatena).• Muudatuse tegemine mudeli elementi ühel mudelil kannab selle edasi kateistesse mudelitesse, kus seda mudeli elementi kajastatakse.• Peab olema võimalik mudeleid otsida ja visualiseerida.• Peab võimaldama automaatselt diagramme organiseerida, nii et oleksvõimalikult vähe ristuvaid jooni ja diagramm oleks võimalikult hästi loetav.• Peab olema võimalik informatsiooni vahetamine teiste CASE vahenditega(näiteks Extensible Metadata Intrchange e. XMI standardi alusel). Seetähendab, et ideaalis peaks olema võimalik mudeli importimine ühe CASEvahendi poolt mingisse spetsiaal-formaadis faili ning seejärel selle failisisselugemine mõne teise CASE vahendi poolt.• CASE vahend peaks võimaldama maksimaalselt projekteerija töödautomatiseerida. Selleks peab vahend võimaldama olemasolevatesmudelitest uute mudelite genereerimist. Sealjuures oleks hea kui kasutajasaaks ise määrata reegleid, mida genereerimise juures kasutatakse.• Peab olema võimalik genereerida ka järgnevat.• Aruanded. Kindlasti peaks vahend võimaldama genereeridaaruandeid HTML formaadis dokumentidena.55

TTÜ: Loogiline disain. CASE (2012)© Erki Eessaar• Rakendusmoodulid.• Testjuhud.• CASE vahend peaks olema integreeritud tekstitöötlus- jatabelarvutusprogrammidega, kuhu saab edastada mudeli põhjalgenereeritud dokumentatsiooni.• Peab olema võimalik olemasolevast andmebaasi skeemist või rakendusmoodulitestmudelite genereerimine.• Peab olema võimalik rakendusmoodulite ja andmebaasi skripti ningmudelite omavahelise kooskõla tagamine (sünkroniseerimine).• Peab olema võimalik mudelite kvaliteedi automaatne hindamine.• Peab olema võimalik mudelite omavahelise kooskõlalisuse hindamine jamudelite omavahelise kooskõlalisuse tagamine.• CASE vahend peab võimaldama kirjeldada süsteemi paralleelselt jamitmevaateliselt (modelleerimise kolmnurk).• CASE vahend peab aitama süsteemi mingi metoodika alusel arendada.Nt. Rational Rose kasutaja võib kuid ei pruugi süsteemi arendamiseljärgida Rational Unified Process (RUP) metoodikat.• Meta-CASE vahendites saavad kasutajad ise defineerida uusi süsteemimodelleerimiseks kasutatavaid keeli.• Arendajal peab olema võimalik defineerida uut liiki mudeli-elemente.• CASE vahend peab aitama rakendada standardeid (nt. UML).• Peab olema võimalik mudelite kuvamine erinevas notatsioonis e. erinevatähistusega. Nt. võib andmete modelleerimise CASE vahend võimaldadavaadata andmebaasi skeemi kirjeldust nii IE, IDEF1X ja UMLnotatsioonis.• Peaks olema võimalik mitme kasutaja üheaegne töö mudeliga. CASEvahend peab võimaldama mudelite versioonikontrolli ja integreerimist.Näiteks võib süsteemianalüüsi projektis iga analüütik töötada ühe kindlaallsüsteemi ja registriga. Kuid allsüsteem kasutab ka selliste allsüsteemideja registrite teenuseid, mida ta ise ei projekteeri. Kõigil analüütikutel peabvajadusel olema võimalik näha tervikmudelit.• CASE vahendiga peavad olema integreeritud modelleerimist juhendavadabimaterjalid.• CASE vahendiga võiks olla seotud mustrite või universaalsete mudeliteteek, kust modelleerija saaks uue mudeli koostamisel endale sobivaidmudeleid või nende alamosi valida.• CASE vahend peaks võimaldama simuleerida koostatud mudelite põhjaltulevase süsteemi tööd.• Peaks olema võimalik teha päringuid süsteemi kirjelduste põhjal, et leidakirjeldatavat süsteemi iseloomustavaid arvulisi suurusi (tarkvarameetrikateväärtuseid) (nt. olemitüüpide arv, kasutusjuhtude arv, allsüsteemide arvjne.)Näide 1:ERwin CASE on andmete modelleerimise jaoks mõeldud CASE vahend.Mudeli loomiseks saab kasutada nii reaalselt eksisteerivat andmebaasi kui kaandmebaasi loomiseks kasutatavat DDL (Data Definition Language) keelsetskripti. Valides menüüst Tasks käsu Reverse Engineer tuleb kõigepealtvalida uue mudeli loomisel aluseks võetav mall. Võib valida "Blank diagramm"56

TTÜ: Loogiline disain. CASE (2012)© Erki EessaarSeejärel käivitub dialoog:Joonis 25 Pöördprojekteerimise aken CASE vahendis ERwin.Selles aknas saab valida, millise andmebaasisüsteemi andmebaasis põhjalsoovite mudelit luua.Valides "Next" avaneb aken, kus on võimalik häälestada seda, kuidasandmebaasi või skripti põhjal andmemudel luuakse.57

TTÜ: Loogiline disain. CASE (2012)© Erki EessaarAndmemudeli saab sisse lugeda nii olemasolevast andmebaasi skeemist kui ka andmebaasiloomise skriptifailist.Juhul kui lugeda andmete kirjeldused sisse otse andmebaasist peab olema loodud ühendusvastava andmebaasiga. Seda saab teha menüüst Server käsuga Target Server. Seejäreltuleb luua ühendus vastava andmebaasiga.Joonis 26 Pöördprojekteerimise aken CASE vahendis ERwin.58

TTÜ: Loogiline disain. CASE (2012)© Erki EessaarNäide 2:CASE vahendi Rational-Rose võimaldab süsteemi modelleerida kasutadesvisuaalset modelleerimiskeelt UML.Joonis 27 CASE vahendi Rational-Rose töölaud.59

TTÜ: Loogiline disain. CASE (2012)© Erki EessaarJoonis 28 CASE vahendis Rational-Rose Data Definition Languageskripti genereerimine.Fragment tulemusest:CREATE TABLE Ruum (ruumi_nr SMALLINT NOT NULL,hotelli_nr SMALLINT NOT NULL,tyyp CHAR ( 1 ) NOT NULL,hind DECIMAL ( 7, 2 ) NOT NULL,CONSTRAINT PK_Ruum4 PRIMARY KEY (hotelli_nr, ruumi_nr),CONSTRAINT TC_Ruum3 CHECK (VALUE IN ("A","L")));CREATE TABLE Hotell (hotelli_nr SMALLINT NOT NULL,hotelli_nimi VARCHAR ( 50 ) NOT NULL,linn VARCHAR ( 30 ) NOT NULL,CONSTRAINT PK_Hotell5 PRIMARY KEY (hotelli_nr),CONSTRAINT TC_Hotell36 UNIQUE (hotelli_nimi));60

TTÜ: Loogiline disain. CASE (2012)© Erki EessaarALTER TABLE Ruum ADD CONSTRAINT FK_Ruum3 VÄLISVÕTI (hotelli_nr)VIITAB Hotell (hotelli_nr) ON DELETE NO ACTION ON UPDATE CASCADE;5.3 Andmete modelleerimise CASE-vahenditeüldiseloomustus• Andmemudeli esitus on mitmevaateline ja mitmetasemeline.• Kontseptuaalse andmemudelina, mis esitab nõudmised andmebaasile,kuid mitte andmebaasi tehnilist lahendust.• Loogilise andmemudelina. See on tehniline mudel, mis arvestabandmebaasi aluseks oleva andmemudeliga (nt. relatsiooniline mudelvõi SQL aluseks olev mudel). Loogilises andmemudelis ei arvestataveel konkreetse andmebaasisüsteemi eripäradega.• Füüsilise andmemudelina. See kirjeldab andmebaasi realisatsioonikonkreetses andmebaasisüsteemis.• Andmebaasikeele lausetena (nt. SQL laused, juhul kui andmebaasrealiseeritakse SQL-andmebaasisüsteemis).• CASE vahend peab võimaldama üleminekult ühelt tulemilt teisele:kontseptuaalne andmemudel => esialgne loogiline andmemudel =>esialgne füüsiline andmemudel => andmebaasikeele laused. Samutipeaks olema võimalik vastupidine genereerimine (pöördprojekteerimine,reverse engineering): andmebaasikeele laused=> füüsiline andmemudel=> loogiline andmemudel => kontseptuaalne andmemudel.• CASE-vahendid omavad liideseid andmebaasisüsteemidega füüsilisteandmemudelite üleviimiseks nendesse süsteemidesse (inglise keelesforward engineering).• CASE-vahendid omavad liideseid andmebaasisüsteemideandmestruktuuride kirjelduste sisselugemiseks ja nende alusel mudelitekoostamiseks (inglise keeles reverse engineering).• Üheks CASE vahendite oluliseks arengusuunaks on neile võime andmineviia läbi andmebaaside projekteerimist pooleldi automaatselt (Storey &Goldstein & Ullricht, 2002). Näiteks kasutaja paneb kirja süsteemikirjeldavad lausendid (lihtlaused) või ka ainult olulised olemitüübid jatarkvarasüsteem genereerib selle põhjal valmis esialgse olemi-suhtediagrammi, mida kasutaja siis parandada ja täiendada saab. Selleprotsessi käigus võidakse kasutaja andmebaasi mustrite (vt. teema 8)baasi ja ontoloogiaid. Ontoloogia kirjeldab mingis valdkonnaskasutatavaid mõisteid ja mõistete vahelisi seoseid. Andmebaasiprojekteerijat abistav süsteem peab saama kasutada ontoloogiaid nendevaldkondade kohta, mille jaoks projekteerijad andmebaase loovad.• Mõned näited selle kohta, kuidas andmebaasi projekteerimist osaliseltautomatiseeriv süsteem saab projekteerijat aidata.• Kui projekteerija leiab olemitüübi, siis oskab süsteem soovitada selleleatribuute. Projekteerija peab atribuutide nimekirjast valima väljasellised, mille kohta ta soovib hakata andmebaasis andmeid hoidma.• Süsteem oskab olemasolevate olemitüüpide nimekirja põhjal soovitadauusi olemitüüpe ja seosetüüpe. Näiteks kui projekteeritakse ülikoolikursuste registrit ja leitakse olemitüüp Kursus, siis oskab süsteemsoovitada, et kursus peab olema seotud Õppejõuga, kes seda kursust61

TTÜ: Loogiline disain. CASE (2012)© Erki Eessaarläbi viib. Kui leitakse olemitüüp Üliõpilane, siis võib süsteem soovitada,et mudelis peaks olema ka esitatud olemitüübid Osakoormusegaüliõpilane ja Täiskoormusega üliõpilane (osakoormusega üliõpilane onüliõpilane). Päringu näide: Vaadeldavaks mõisteks on Kursus jakontekstiks on Ülikool. Leida kõik vaadeldava mõistega etteantudkontekstis seotud mõisted ja nende vahelised seosed. Leitud mõistedon olemitüüpide kandidaadid ja nende vahelised seosed onseosetüüpide kandidaadid.5.4 Spetsiifilised nõuded andmete modelleerimiseks mõeldudCASE vahenditele• CASE vahend peab võimaldama süsteemi andmekoosseisu esitamist,kasutamist ja muutmist erinevatele projektis osalejatele just neile sobivasvaates.• Kontseptuaalne.• Loogiline.• Füüsiline.• CASE vahend peab omama liidest erinevate andmebaasisüsteemidega,et võimaldada:• andmemudelite ülekandmist andmebaasisüsteemi;• andmebaasi alusel andmemudeli koostamist.• Andmebaasi realiseerimiseks võimaldab CASE vahend kasutadaerinevaid meetodeid.• CASE vahend loob andmekirjelduskeele lausete skriptid, mida saabandmebaasisüsteemis käivitada andmestruktuuride loomiseks.• CASE vahend kasutab andmebaasi loomiseks otseliidestandmebaasisüsteemiga ning edastab andmebaasi loomiseks vajalikudlaused otse andmebaasisüsteemile.• CASE vahend peab võimaldama kirjeldada erinevaid andmebaasiobjekte.SQL-andmebaaside korra on lisaks baastabelitele nendeks ka näiteks:• kitsendused,• vaated,• trigerid,• arvujada generaatorid,• ...5.5 Kuidas valida CASE vahendeid?Mõned võimalikud valikukriteeriumid.• Erinevat tüüpi andmemudelite toetus – kas on võimalik luuakontseptuaalset-, loogilist-, füüsilist andmemudelit.• Erinevate andmebaasisüsteemide toetus (mille jaoks võimaldabandmebaasi luua).• Operatsioonisüsteemide toetus (kus CASE vahend võib töötada).• Mudelite automaatkontrolli võimalused.• Nimestandardite rakendamise võimalused – nt. kindlad reeglid tabelite,vaadete, kitsenduste nimetamisel.62

TTÜ: Loogiline disain. CASE (2012)© Erki Eessaar• Andmemudelitest andmebaasi genereerimise võimalused, erinevat tüüpiandmebaasiobjektide loomise toetus.• Pöördprojekteerimise (reverse engineering) tase.• Graafilise kasutajaliidese kvaliteet.• Andmevahetuse lihtsus/keerukus teiste CASE vahenditega ja teisteprogrammidega.• Aruannete genereerimise võimalused.• CASE-vahendi tööks vajaliku riist- ja tarkvara hind.• CASE-vahendi hind.Näiteid andmete modelleerimiseks mõeldud kommertssüsteemidest.• Sparx Systems Enterprise Architect• Sybase PowerDesigner• CA ERwin Data Modeler• IBM Rational Data Architect• IBM Rational Rose (with Data Modeler)• Datanamic DeZign for Databases• Embarcadero ER/Studio• Oracle DesignerTasuta vahenditest soovitan kindlasti tutvuda vahendiga DB-MAIN(http://www.db-main.eu/?q=en).6 MõistedEesti keelesAnalüüsTerviksüsteemi toimimismudelDisainLoogiline disainAndmebaasi kirjelduskeelFüüsiline disainAlamtüüpÜlatüüpTäielik/tõeline kaarÜhine / üldine kaarReaalne kasutusjuhtAknakujunduse diagrammPrototüüpPöördprojekteerimineInglise keelesAnalysisBusiness ModelDesignLogical designDatabase Definition LanguagePhysical designSubtypeSupertypeExplicit arcGeneric arcReal use caseWindow layout diagramPrototypeComputer Aided SystemEngineering (CASE)Forward engineeringReverse engineering63

TTÜ: Loogiline disain. CASE (2012)© Erki Eessaar7 Kasutatud materjalid1. Larman, C., 1997. Applying UML and Patterns : An Introduction to Object-Oriented Analysis and Design. 528 p.2. Celko, J., 2000. SQL for smarties: advanced SQL programming. 2 nd ed.Academic Press. 553 p.3. Connolly, T.M. & Begg, C.E., 2002. Database systems. A PracticalApproach to Design, Implementation and Management. Third Edition.Pearson Education. 1236 p.4. Isikukoodide moodustamise, väljajagamise ja andmise kord.Regionaalministri 7. jaanuari 2005. a määrus nr 4. [WWW]http://lex.andmevara.ee/estlex/kehtivad/AktTekst.jsp?id=65396(07.04.2006)5. Isotamm, A., 1998. Infosüsteemide projekteerimine. Tartu ÜlikooliKirjastus. 204 lk.6. Lõputööde kodeerimise juhend. TTÜ rektori käskkiri 20. aprill 2006 nr 57.7. Nikiforova, O. & Sukovskis, U., 2002. Framework for comparison ofsystem modeling tools. Databses and Information sytems. Proceedings ofthe Fifth International Baltic Conference, BalticDB&IS, June 3-6, 2002.Volume 1. p. 63-70.8. Muller, R.J., 1999. Database Design for Smarties. Using UML for DataModeling. Morgan Kaufmann Publishers, 1999. 442 p.9. Pascal, F., 2000. Practical Issues in Database Management. A Referencefor the Thinking Practicioner, Addison-Wesley. 256 p.10. Pascal, F., 2002. On surrogate vs. natural keys. Database debunkings[WWW] http://www.dbdebunk.com/page/page/857309.htm (14.02.2004)11. Storey, V.C. & Goldstein, R.C. & Ullricht, H., 2002. Naive Semantics toSupport Automated Database Design. IEEE Transactions of Knowledgeand Data Engineering, vol. 14, no. 1, Yanuary/February, 2002.64