# Teema: Andmebaasi kavandamise sisulised küsimused

## Küsimus: Andmebaaside aine pöörab palju tähelepanu süsteemianalüüsile. Miks see on oluline?

**Vastus:**

Oma iseseisva töö projekti tegemise käigus tuleb Teil ennast panna süsteemianalüütiku rolli. Siin on 15.02.2017 Postimehes ilmunud artikkel analüüsi olulisusest süsteemide loomisel ning sellega seotud valikutest haridusmaastikul.
Tööelus võite puutuda infosüsteemide arendamisega kokku tellijana. Hästi toimiva infosüsteemi loomine algab õige ülesandepüstituse koostamisest. Elu näitab, et "IT-probleemide püstitamine ja kirjeldamine viisil, mis tagaks efektiivse tööprotsessi ja tõhusad lahendused", ei tule sageli nii hästi välja kui võiks. Seega ei jookse mööda külge maha oskus ülesandepüstitust (nõudeid) kirja panna. Arendaja rollis on jällegi vajalik oskus kirjapandud nõuetest aru saada.
Üheks suure infosüsteemi ebaõnnestunud arendamise näiteks on Ruumilise planeeringu infosüsteem (RPIS). See loodi detailplaneeringutete avaliku väljapaneku kättesaadavuse parandamiseks ning planeeringute kooskõlastamise kiiremaks, jälgitavamaks ja mugavamaks muutmiseks. Süsteemi arendatakse alates 2009. aastast, sellele on kulutatud peaaegu miljon eurot, kuid kasutajaid peaaegu ei ole. Kohalikud omavalitsused eelistavad teisi turul saadaolevaid süsteeme. Selle asemel, et hakata suure hooga nullist uut süsteemi tegema oleks tulnud kõigepealt aru saada, kas ning mida on vaja - võibolla oleks piisanud mõne turul oleva süsteemi kohandamisest. Sellistele küsimustele annab vastuse süsteemianalüüs. Võibolla oleks olnud ka abi tööprotsesside lihtsustamisest - sellega tegeleb ärianalüüs (business analysis), millega käesolev kursus ei tegele.
Jaakkola et al. (2016) kohaselt kasvavad nõuete kogumise (analüüsi) faasis tehtud vigade parandamiseks kuluv pingutus iga järgmise süsteemiarenduse faasiga kolm korda. Disaini faasis on neid 3, realiseerimise faasis 9 ja testimise faasis 27 korda kulukam parandada kui nõuete kogumise faasis.
Jaakkola, H., Henno, J., Welzer-Druzovec, T., Thalheim, B., Mäkelä, J., 2016. Why Information Systems Modelling Is Difficult. In SQAMIA. pp. 29– 39.
Ehk olete kuulnud sotsiaalkaitse infosüsteemi uue versiooni (SKAIS2) arendamise saagast. Praeguseks on kulud kasvanud kaugelt üle algselt planeeritu ja projekti lõppu ei paista. 2019. aasta jaanuaris kuulutati välja järjekordne riigihange süsteemi uute osade tegemiseks ning olemasolevate parandamiseks. Hanke dokumendid on avalikkusele kättesaadavad riigihangete registris ja neid tasub huvi korral sirvida selle pilguga, et:

kui mahukas on keerulise infosüsteemi kirjeldus,
milliseid dokumente peavad pakkumise koostajad, sh majandusinimesed oskama kirjutada,
milliseid dokumente peavad pakkumisele reageerijad ja ka hiljem analüütikud ning arendajad oskama lugeda.

Huvi korral vaadake näiteks "Lisa 3. Nõuded infosüsteemi dokumentatsioonile", "Lisa 2. Mittefunktsionaalsed nõuded", "Lisa 1. Arhitektuuri ülevaade". Mitmed soovitud dokumentidest (sh mittefunktsionaalsed nõuded, kuid mitte arhitektuuri kirjeldus) on ka iseseisva töö projektis.
"Lisa 5. Tehniline kirjeldus" esitatud tekstilise jutu süsteemilt oodatavatest funktsionaalsustest peab süsteemianalüütik oskama tõlkida täpsemate mudelite keelde (kasutusjuhtude mudelid, protsessimudelid, seisundidiagrammid, andmemudel jne).
"Lisa 11.1. Ärianalüüs" dokumendis on väljatoodud põhimõisted ja nende definitsioonid. Selleks, et midagi koos arendada on oluline, et kõik arendusest huvitatud osapooled mõistetest võimalikult täpselt ja ühtemoodi aru saavad. Teie projektis on selliseks mõistete kataloogiks kontseptuaalse andmemudeli osaks olev olemitüüpide ja atribuutide definitsioon.
Õppekavades, kus on "Andmebaasid I", on see praktiliselt ainus aine, mis puudutab süsteemianalüüsi. Seega kus siis veel kui mitte siin.
Lõpetuseks veel üks pildirida, mis illustreerib seda, mis võib süsteemi arendamise, sh analüüsi käigus valesti minna.

**Märksõnad:** süsteemianalüüs, analüütik, detailanalüüs, strateegiline analüüs, ärianalüüs, nõuded

## Küsimus: "Andmebaasid I" õppeaines kasutame infosüsteemi ja selle osaks oleva andmebaasi kirjeldamiseks UML modelleerimiskeelt.

Milliseid allikaid soovitate UMLiga tutvumiseks või selle kohta teadmiste värskendamiseks lugeda?

**Vastus:**

Ma olen ka koostanud ühe eestikeelse konspekti, mida huvilised saavad lugeda lisamaterjalide lehelt (kasutajanimi: SIS2 ja parool: SIS2) SELLEST MATERJALIST.
Raamatutest soovitan eestikeelset raamatut:
Fowler, M., 2007. UMLi kontsentraat. 3. redaktsioon. Objektmodelleerimise standardkeele UML2.0 lühijuhend. Cybernetica AS. [WWW] https://www.ester.ee/record=b2282809~S1*est
Kaanepilt: https://www.apollo.ee/umli-kontsentraat.html
Seda raamatut on paraku väga vähe saadaval. Kui näete kuskil pakkumist või saate laenutada, siis soovitan sellest kinni haarata.
UMList õigesti rääkimiseks vaadake palun eesti inglise-eesti standardipõhist tarkvaratehnika sõnastikku STATS, mis sisaldab ka UML terminoloogiat: https://stats.cyber.ee/
Järgnevatest allikatest leiate ingliskeelse ülevaate UML 2.X erinevatest diagrammitüüpidest:

Larman, C., 2013. Applying UML and patterns : an introduction to object-oriented analysis and design and iterative development, Prentice Hall. 703 p. [WWW] https://www.ester.ee/record=b2048056*est

Raamatut saab lugeda O'Reilly digitaalselt platvormilt SIIN

Kuidas kasutada O'Reilly digitaalset platvormi?




http://www.agilemodeling.com/essays/umlDiagrams.htm
https://www.uml-diagrams.org/


**Märksõnad:** tegevusdiagramm, kasutusjuhtude diagramm, seisundidiagramm, klassidiagramm, olemi-suhte diagramm, andmebaasi diagramm, olekumasin, olekumasina skeem

## Küsimus: Andmebaasis on tabelid, millesse võib olla vaja teha muudatusi. Osadel kasutajatel on muudatuste tegemise õigus, neil kellel pole, peaks olema aga võimalus muudatusi soovitada, need soovitused jõustuksid peale muutmisõigusega kasutaja heakskiitu.

See süsteem oleks inspireeritud sellest, kuidas toimivad pull request'id / merge request'ed GitHub ja GitLab keskkondades. Samasugune loogika on olemas ka näiteks Google Docsis (inimese saab lisada soovituse, mis vajab dokumeni omaniku heakskiitu).

Kasutaja ei pruugi siinjuures tähistada andmebaasi kasutajat, tegemist võib olla rakenduse kasutajatega, ehk siis kirjetega tabelis `User`.

Hea oleks, kui tegemist ei oleks mitte ühe tabeli spetsiifilise lahendusega, vaid üldise lahendusega, mida saaksid kasutada erinevad tabelid.

Kuidas võiks sellist asja PostgreSQLiga teha?

**Vastus:**

Üks võimalus oleks luua soovitatud muudatuste jaoks tabelid.Soovituse_seisundi_liik(soovituse_seisundi_liik_kood, nimetus)Primaarvõti (soovituse_seisundi_liik_kood)Alternatiivvõti (nimetus)Tabelis Soovituse_seisundi_liik on registreeritud seisundid "esitatud", "vastuvõetud" ja "tühistatud".Muutmise_soovitus (soovitus_id, skeemi_nimi, tabeli_nimi, veeru_nimi, võti, väärtus, soovituse_aeg, soovitaja, soovituse_seisundi_liik_kood)Primaarvõti (soovitus_id)Alternatiivvõti (skeemi_nimi, tabeli_nimi, veeru_nimi, võti, soovituse_aeg, soovitaja)Välisvõti (soovituse_seisundi_liik_kood) Viitab Soovituse_seisundi_liik(soovituse_seisundi_liik_kood)Välisvõti (soovitaja) Viitab Kasutaja (kasutaja_id)

Tabeli Muutmise_soovitus veerul soovituse_seisundi_liik_kood on vaikimisi väärtuseks seisundile "esitatud" vastav kood.
Tabeli Muutmise_soovitus veerul soovituse_aeg on vaikimisi väärtuseks ajatempli leidmiseks mõeldud funktsiooni poole pöördumine.
(skeemi_nimi, tabeli_nimi, veeru_nimi) identifitseerivad tabeli+veeru, kus soovitakse muudatust teha ning veerus võti olev väärtus identifitseerib rea tabelis, milles soovitakse muudatust teha.
Muutmise_soovitus veerg võti võiks näiteks olla massiivitüüpi text[][] ning seal oleks registreeritud võtmeveergude nimede ja nende väärtuste tekstiliste esituste paarid. Alternatiiv oleks see esitada JSON objektina ja siis oleks veerg võti tüüpi JSONB. Variant oleks ka kasutata tüüpi hstore, millesse kuuluvad väärtused on võti-väärtus paaride hulgad.
Tabeli Muutmise_soovitus veerg väärtus on tekstitüüpi (PostgreSQL puhul tüüpi TEXT), et registreerida soovitatud väärtuse tekstiline esitus. Kas soovituse esitamisel või ülevaatamisel tuleb kontrollida, et see on teisendatav sobivat tüüpi väärtuseks (a'la, keegi soovitab kuupäeva 31. veebruar 2022). Veeru tüübi saab kindlaks teha päringu abil INFORMATION_SCHEMA.columns süsteemikataloogi vaate põhjal, sest soovituse tabelis on skeemi, tabeli ja veeru nimi registreeritud.

Tabel Muutmise_soovitus on mõeldud selleks, et soovitada UPDATE operatsioone. Kui soovitada saaks ka ridade lisamist (INSERT) või kustutamist (DELETE), siis selleks looksin eraldi tabelid (Lisamise_soovitus ja Kustutamise_soovitus). Tabelis Kustutamise_soovitus ei ole vaja veerge veeru_nimi ja väärtus. Tabelis Lisamise_soovitus ei ole vaja veerge veeru_nimi ja võti. Veerus väärtus peab olema lisatava rea esitus (sõltuvalt kasutatavast tüübist kas massiivina, JSON objektina või võti-väärtus paaride hulgana).Keerukust soovituste ülevaatamisele lisab see, kui samale väljale/reale on tehtud mitu soovitust. Ilmselt peaks ülevaatajale kõiki näitama ja andma talle võimaluse ühe valida või enda poolt mingi kombineeritud väärtus sisestada.Edasiarenduseks on näiteks võimalus määrata, kas kasutajale või kasutajate rollile (mida võib omada mitu kasutajat) veerud, mille jaoks on tal üldse lubatud muudatusi soovitada.Kastutaja (kasutaja_id, ....)Primaarvõti (kasutaja_id)Kasutaja_roll (kasutaja_roll_kood, nimetus)Primaarvõti (kasutaja_roll_kood)Alternatiivvõti (nimetus)Kasutaja_rolli_omamine (kasutaja_id, kasutaja_roll_kood)Primaarvõti (kasutaja_id, kasutaja_roll_kood)Välisvõti (kasutaja_id) Viitab Kasutaja (kasutaja_id)Välisvõti (kasutaja_roll_kood) Viitab Kasutaja_roll (kasutaja_roll_kood)Muutmise_soovituse_luba (skeemi_nimi, tabeli_nimi, veeru_nimi, kasutaja_roll_kood)Primaarvõti (skeemi_nimi, tabeli_nimi, veeru_nimi, kasutaja_roll_kood)Kui soovitada saab ka ridade lisamist või kustutamist, tuleks luua ka tabelid Lisamise_soovituse_luba ja Kustutamise_soovituse_luba.Õiguste poolelt soovitaksin lahendust, kus igale rakenduse lõppkasutajale (mille kohta on rida tabelis Kasutaja) vastaks ka eraldi andmebaasi kasutaja (seda on muide tehtud selles näiteprojektis) nii nagu soovitakse  SELLES artiklis andmebaasipõhise turvalisuse tagamise mudeli kohta. See võimaldab teha nii, et rakenduse kasutajatel, kes saavad soovitada muudatusi, on INSERT õigus tabeli Muutmise_soovitus suhtes, kuid ei ole UPDATE õigust tabelite suhtes, mille jaoks muudatusi soovitatakse. Rakenduse kasutajatel, kes saavad ise otse muudatusi teha on UPDATE õigus muudetava tabeli suhtes, kuid ei ole INSERT õigust tabeli Muutmise_soovitus suhtes. Muudatuste kinnitamiseks võiks luua plpgsql keeles kirjutatud funktsiooni, mis koostab muudatuste soovituse andmete põhjal dünaamiliselt SQL lause, mille abil muudatus ära teha, käivitab selle lause ja muudab ühtlasi soovituse seisundit. Kui funktsioonis kasutada SECURITY DEFINER määrangut, siis saab teha nii, et ülevaatajal on funktsiooni käivitamise õigus, kuid tal ei ole muutmisõiguseid soovituste tabeli ja tegelike andmetega tabeli suhtes.

**Märksõnad:** PostgreSQL

## Küsimus: Kas kuskil on nähtav andmebaasitehnoloogiate suur pilt?

**Vastus:**

Suur pilt (1. juuni 2015 seisuga) erinevatest andmebaasitehnoloogiatest ning neid realiseerivatest tarkvarasüsteemidest.
Veel värskema versiooni saab küsida siit.
Siin aga on iga kuu uuendatav andmebaasisüsteemide populaarsuse indeks.

## Küsimus: Kas leidub kergesti kättesaadavat eestikeelset kirjandust SQL-andmebaaside kavandamisel ettetulevatest probleemidest ja nende lahendustest?

**Vastus:**

Tallinna Tehnikaülikooli üliõpilased on lõputöödena koostanud mustrite katalooge. Need lõputööd on kättesaadavad Tallinna Tehnikaülikooli digikogust. Muster on nimega kirjeldus, milles on esitatud probleem ja lahendus sellele probleemile. Samuti on kirjeldatud, millal seda lahendust rakendada ja kuidas rakendada lahendust uues kontekstis. Antimustrid, vastupidiselt, kirjeldavad probleemide halbu lahendusi, koos soovitustega, kuidas probleemi paremini lahendada.

Analüüsi mudelite antimustrid.
Disainimustrid üldistusseoste esitamise kohta SQL-andmebaasides.
Disainimustrid kitsenduste jõustamise kohta PostgreSQL andmebaasis.
Disainimustrid klassifikaatorite esitamiseks SQL-andmebaasides.
Mitmekeelsete SQL-andmebaaside disainimustrid.
Disainimustrid isikunimede hoidmiseks SQL‑andmebaasides.

Selles töös on hea ülevaade nii maailma rahvaste kultuurilisest rikkusest nimede andmisega seoses kui ka nimede hoidmise tehnilistest lahendustest.


Hierarhiliste andmete esitamine SQL-andmebaasides.
Graafide esitamine SQL-andmebaasides.
Infosüsteemi põhiolemite seisundite esitamine SQL-andmebaasides.
Mõned failide salvestamise disainimustrid SQL-andmebaasi kasutavate andmebaasirakenduste jaoks.

Mustrite teemaga seostub ka: Andmebaasi loogilise ja füüsilise disaini antimustrite esinemine mõnedes vaba tarkvara poolt kasutatavates SQL-andmebaasides.
Lisaks sellele on tehtud lõputöid, kus mustreid pole kirja pandud, kuid kus on uuritud andmebaaside disaine ja tehtud nendega eksperimente.

Mitme väite ühe andmeväärtusena esitamise eelised ja puudused SQL-andmebaasides.

Mõned uuritavad disainid kasutavad JSON, JSONB või massiivitüüpi veergu.
Lisan, et peale selle lõputöö kirjutamist on lisandunud PostgreSQLi arsenali jsonb_set funktsioon, mis muudab andmete muutmise lihtsamaks, st ei ole enam vaja tervet hierarhia väärtust uuesti andmebaasi kirjutada.


Universaalne andmebaasi disain ja selle probleemid.
Puuduvate andmete esitamine SQL-andmebaasides.
Sisulise tähendusega võtmed vs. surrogaatvõtmed SQL-andmebaasides.
Mõned võimalused ridade ajaloo säilitamiseks SQL-andmebaasides.
Denormaliseerimise praktika uurimine ühe SQL-andmebaasi näitel.
SQL-andmebaasides olevate andmebaasiobjektide nimetamine.

Töös keskendutakse kitsendustele, kuid tehakse ka üdisemaid tähelepanekuid nimede andmise kohta.


Andmebaasi optimeerimine ning selles toimuvate operatsioonide jõudluse analüüs ühe Oracle andmebaasi näitel.
Päringu filtri predikaadi automaatne lihtsustamine kahe SQL-andmebaasisüsteemi näitel.
Reapõhise ja veerupõhise andmete salvestamise võrdlus kahe SQL-andmebaasisüsteemi näitel.
Vaadete mõju päringute täitmisplaanide koostamisele kahe andmebaasisüsteemi näitel.
Isikute nime alusel otsimise erinevad võimalused PostgreSQLis.


**Märksõnad:** bakalureusetöö, magistritöö, teemad

## Küsimus: Kas puhta koodi põhimõtted on olulised ka andmebaaside korral?

**Vastus:**

Jah on!
O'Reilly digitaalse platvormi vahendusel pääsete Te ligi Robert C. Martini raamatule Clean Code (Kuidas kasutada O'Reilly digitaalset platvormi?).
Selle raamatu ideed kehtivad ning on olulised ka andmebaaside ja infosüsteemide ainete jaoks. See raamat jagab juhiseid vastutustundlikule arendajale.
Täpselt nii nagu vastutustundlik arendaja üritab luua võimalikult puhast rakenduse koodi, üritab ta ka luua puhast andmebaasikeele koodi ja puhtaid mudeleid. Üldine idee on täpselt sama! Suure tõenäosusega hakkate neid tehiseid ise tulevikus lugema. Või kui ei hakka ise, siis hakkab keegi teine. Puhast artefakti (tehist) on hea ja meeldiv lugeda, sellest saab kergesti aru ning kokkuvõttes on tehist tänu sellele lihtsam edasi arendada. Samal ajal "räpane" tehis võib küll oma hetke eesmärki täita (hetkel see "töötab" nagu vaja), aga halva arusaadavuse ning loetavuse tõttu on seda raske parandada ja edasi arendada. Sellised tehised vajavad refaktoreerimist. Refaktoreerimist vajavad kohad leiab üles halva lõhna järgi.
Eaglesoni seadus ütleb, et kui vaatasite viimati enda kirjutatud koodi rohkem kui kuus kuud tagasi, siis arusaamise mõttes võib see kood olla ka kellegi teise kirjutatud – arusaamiseks/meeldetuletamiseks tuleb sama palju vaeva näha. Mõned ütlevad, et Eagleson oli optimist ja tegelik ajaperiood on palju lühem. Mida puhtam kood, seda lihtsam on aru saada, mida olete ise kunagi teinud. Mida puhtam tehis, seda lihtsam on Teil ja teistel sellest aru saada.
Täpselt nagu on olemas halvasti lõhnav lähtekood, leidub ka:

halvasti lõhnavaid arhitektuure,
halvasti lõhnavaid disaine,
halvasti lõhnavaid andmebaasi disaine (Sama raamat elektrooniliselt) ja
halvasti lõhnavaid mudeleid. Mudelite halbadest lõhnadest annab ülevaate ka see bakalaureusetöö ja selle töö edasiarendusena loodud kataloog.

Kui Te ei taga enda loodavate tehiste puhtust, siis Te kogute tehnilist võlga. Tehniline võlg tähendab, et tehise muutmiseks on vaja liigselt pingutada. Nagu me kõik inimeste elust teame, siis võlg võib kiiresti kasvada ja kontrolli alt väljuda. Laenu võtta (võlgu jääda), võib teadlikult - lootuses, et see tasub ennast ära, aga see on risk. Samamoodi, kui näiteks inimene kodu ei korista ja selle käest ära laseb, siis kui ükskord keegi külla tuleb või on vaja see maha müüa, siis kulub selle uuesti üleslöömiseks väga palju aega ja vaeva.
Halvasti lõhnava mudeli illustratsiooniks on teatele lisatud ekraanipilt Enterprise Architect abil loodud modelleerimise projektist. Mudeli elemendid on seal süsteemitult segamini nagu puder ja kapsad ning mida suuremaks see projekt kasvab seda raskem oleks sealt vajalikku üles leida.

**Märksõnad:** puhas kood, clean code

## Küsimus: Kas saaksite tuua mõne näite valesti valitud väljapikkustest ja selle põhjustatud probleemidest?

**Vastus:**

Valed valikud võivad põhjustada kannatusi, segadust, lisatööd ja mainekadu (süsteemi omanikule): https://reisile.postimees.ee/4484884/reisija-pidi-lisatasu-maksma-sest-tema-nimi-ei-mahtunud-lennupiletile.
Antud näite korral oli isikunimede registreerimiseks mõeldud tekstiväljades lubatud maksimaalne märkide arv liiga väike. MS Accessis võiks veergude eesnimi ja perenimi väljapikkus olla 255 märki (maksimaalne võimalik suurus MS Accessis VARCHAR tüübi korral). Süsteemides, kus on lubatud suurem maksimaalne märkide arv (nt PostgreSQL ja Oracle), võiks see olla kuni 1000, sest mõned isikunimed on väga pikad. Samas oleks vale kasutada kõikide tekstitüüpi veergude puhul järjekindlalt maksimaalset võimalikkus väljapikkust või suurimat väärtust võimaldavat andmetüüpi ilma täiendavate kitsendusteta. Kui näiteks veerg perenimi on MS Accessis tüüpi Memo ilma kitsenduseta, et maksimaalne väärtus selles veerus võib olla kuni 1000 märki, siis see jätab skeemi lugejale (programmid, inimesed) vale mulje sellesse veergu oodatavatest andmetest.
Rusikareegel: valige iga veeru jaoks selline andmetüüp + täiendavate kitsenduste komplekt, et kõik vajalikud väärtused saaksid sellesse veergu salvestatud, kuid suurim võimalik väärtus oleks võimalikult väike.

**Märksõnad:** kitsendus, constraint

## Küsimus: Kas saaksite tuua näite mõnest andmebaasis puuduvast kitsendusest, mis on tekitanud probleeme?

**Vastus:**

Hea näite kahe silma vahele jäänud kitsendusest toob Amazoni asutaja ja boss Jeff Bezos. Amazoni algusaastatel avastas ta sellest vea, mis lasi kliendil tellida negatiivse arvu raamatuid, mille järel kanti raha kliendi krediitkaardile. Hr Bezos viskas ühel videol nalja, et ilmselt tuli siis jääda ootama, kuni klient neile raamatud saadab.

## Küsimus: Kas töövihiku järgi projekti tehes (X=teenus) peaks lisama kasutusjuhtude mudelisse kasutusjuhud teenuste broneerimise kohta?

**Vastus:**

EI!
See on õige, et kliendid võiksid saada teenuse tarbimiseks aja kinni panna (teenuse broneerida). Infosüsteemi kui terviku seisukohalt on see vajalik funktsionaalsus.
Mõelge sellele, millised oleksid võimalikud broneerimisega seotud kasutusjuhud.

Broneeri teenus (Klient)
Vaata oma broneeringuid (Klient)
Tühista oma broneering (Klient)
Broneeri teenus (Broneeringute haldur) (võib registreerida mistahes kliendi broneeringu)
Vaata kõiki broneeringuid (Broneeringute haldur) (võib vaadata mistahes kliendi broneeringut)
Tühista broneering (Broneeringute haldur) (võib tühistada mistahes kliendi broneeringu)
Teavita broneeringuga kliente (Broneeringute haldur) (erakorralise teate saatmine ühele või mitmele kliendile)
Vaata broneeringute kokkuvõtet (Juhataja)
...

Nagu näete, siis kasutusjuhte on palju. Küsimus on, millise funktsionaalse allsüsteemi alla need koondada. Kui "Teenuste funktsionaalse allsüsteemi" alla, siis selle kasutusjuhtude arv vähemalt kahekordistuks ja see allsüsteem kasvaks liiga suureks.
Miks see on halb? Samal põhjusel miks liiga suure meetodite arvuga klassi tegemine (tuntakse nime all "plekk" või "jumal-klass"). Sellisest allsüsteemist oleks raskem aru saada, seda oleks raskem arendada ja arenduse tulemusi taaskasutada. Seetõttu oleks õige paigutada eelnimetatud kasutusjuhud "Broneeringute funktsionaalse allsüsteemi" alla (vastab põhiobjektile Broneering). Seda allsüsteemi Te projektis detailselt ei käsitle. Seega pole ka vaja vastavaid kasutusjuhte kirja panna.

## Küsimus: Kas välisteks tegutsejateks võivad olla teised infosüsteemid?

**Vastus:**

Süsteemi välisteks tegutsejateks võivad olla teised infosüsteemid. Selle näiteks majutusasutuste valdkonnas on siseministri poolt 2017. aasta veebruaris esitatud plaan luua majutusasutuste külastajate register. Sellesse registrisse jõuaks automaatselt info kõigi Eesti majutusasutuste külastajate kohta. Registris toimuksid automaatsed päringud, mis otsivad riigile huvipakkuvaid isikuid (nt tagaotsitavaid). Kui vasteid ei saada, kustutakse inimese info omakorda ööpäeva jooksul. Plaani elluviimisega jätkati 2019. aasta sügisel, kui esitati turismiseaduse muutmise eelnõu, mis sellist registreerimist ette näeb. Eelnõu seletuskiri ütleb, et "Eelnõuga ei laiendata registreerimisel esitatavate majutusteenuse kasutajate andmete koosseisu. Isikuandmete kaitse nõuete paremaks täitmiseks luuakse majutusteenuse kasutajate andmekogu."
"Tänavu (2019) üheksa kuuga ööbis Eesti majutusettevõtetes pea 3 miljonit külastajat, nende passiandmed kirjutati üles ja tõsteti hotellis kuhugi seifi. Kehtinuks uue seaduseelnõuga plaanitavad muudatused, oleks politsei- ja piirivalveametil juba 3 miljonit sissekannet andmebaasis, mida saaks automaatselt võrrelda 12 andmekogu sisuga, alates töölubade ja Interpoli registrist ja lõpetades kehtivate isikutunnistuste omaga." (artikkel)
Võimalik lahendus on, et iga majutusasutuse infosüsteem realiseerib klientide andmeid pakkuva veebiteenuse. Majutusasutuste külastajate registri tarkvara pöördub regulaarselt selle veebiteenuse poole ja "tõmbab" majutusasutuste andmebaasidest külastajate andmeid kesksesse registrisse (näiteks JSON või XML dokumendina). Sellisel juhul on majutusasutuste külastajate register majutusasutuse infosüsteemi üks väline tegutseja.
Eesti riigi infosüsteemi moodustavad infosüsteemid vahetavad omavahel infot X-tee andmevahetuskihi kaudu. X-tee mustrikataloogis kirjeldatakse sellist andmete "tõmbamisel" põhinevat lähenemist mustris PM1: andmete päringu teenus. Andmeid omav infosüsteem on teenuse osutaja. Andmeid omaval infosüsteemil on päringutele vastamise teenus, mida andmeid vajav infosüsteem välja kutsub.
Võimalik on ka see, et majutusasutuse infosüsteemi tarkvara võtab ise regulaarselt külastajate registri tarkvaraga ühendust ja "lükkab" sinna külastajate andmeid. Sellisel juhul ei ole majutusasutuste külastajate register majutusasutuse infosüsteemi üks väline tegutseja.
Eesti riigi infosüsteemi moodustavad infosüsteemid vahetavad omavahel infot X-tee andmevahetuskihi kaudu. X-tee mustrikataloogis kirjeldatakse sellist andmete "lükkamisel" põhinevat lähenemist mustris PM2: andmete saatmise teenus. Andmeid omav infosüsteem on teenuse tarbija. Andmeid vajaval infosüsteemil on andmete vastuvõtu teenus, mida andmeid omav infosüsteem välja kutsub.
Pange selle uudise puhul tähele ka seda, et seadustega võivad olla ette nähtud reeglid, milliseid andmeid võib/peab kui kaua säilitama. Kui hakkate mistahes infosüsteemis mõtlema funktsionaalsusele "Kustuta X", siis tuleb selliste nõuetega arvestada. "Kuigi automaatsest registrist kustuvad inimese andmed üldjuhul ööpäevaga, siis majutusasutused ise peavad plaani kohaselt inimeste infot hoidma alles kaks aastat, et ametkonnad saaks vajadusel seda hiljem kontrollida."
Rääkides keskse külastajate registri tehnilisest realisatsioonist, siis järgnev pakub välja ühe võimaliku lahenduse. Andmebaasisüsteem PostgreSQL toetab JSON ja JSONB andmetüüpe (tabelites võivad olla seda tüüpi veerud ja nendes veergudes võivad olla JSON dokumendid). Külastajate andmed laetakse veebiteenuse poolt alla ja salvestatakse dokumentidena PostgreSQL andmebaasi. Nende andmete põhjal tehakse päringuid. Kui leitakse huvipakkuv isik, siis tema andmed kirjutatakse eraldi tabelisse, kus võibolla ei ole enam JSON/JSONB tüüpi veergu, vaid selle asemel, on isiku atribuutidele vastavad andmed (eesnimi, perenimi, isikukood, ...) eraldi veergudes. Huvipakkuvate isikute otsimiseks, nende andmete eraldi tabelisse tõstmiseks ja ülevaadatud külastajate andmete kustutamiseks luuakse andmebaasis funktsioonid. Neid funktsioone on vaja regulaarselt käivitada.
Kui soovite teha regulaarselt mingit tööd PostgreSQL andmebaasis (näiteks käivitada regulaarselt funktsiooni), siis tuleb selleks kasutada operatsioonisüsteemi vahendeid. Näiteks UNIXI-laadsetes operatsioonisüsteemides saab kasutada deemonit Cron, mis vastutab automaatsete operatsioonide eest. "Deemon on tagaplaanil jooksev programm, mis teostab teatud ettemääratud operatsioone kindlate ajavahemike tagant või vastuseks mingitele sündmustele." (Vallaste, http://www.vallaste.ee/)
Majutusasutuse infosüsteemi klientide funktsionaalses allsüsteemi kirjelduses oleks kasutusjuht "Lae alla külastajate andmed", mis on seotud tegutsejaga Majutusasutuste külastajate register.

## Küsimus: Kuidas eristada sisulisi ja administratiivseid allsüsteeme?

**Vastus:**

Funktsionaalsed allsüsteemid ning registrid liigituvad sisulisteks ja administratiivseteks. Fowler (2010) liigitab tarkvara tarbetarkvaraks (utility software) ja strateegilist eelist andvaks tarkvaraks (strategic software). Fowler hindab, et 95% tarkvarast on tarbetarkvara ja 5% strateegilist eelist andev tarkvara. Fowler võrdleb tarbetarkvara torustikuga - see peab olema olemas ja veatult töötama. Kuni probleeme ei ole, siis kasutajat ei huvita kus see on ja kuidas see seda teeb. Strateegiline tarkvara aitab ettevõttel edendada oma äri ja jõuda uutele turgudele. Selline tarkvara ja selle toetatav äri peaks andma organisatsioonile võistlejate ees eelise, tehes näiteks midagi paremini kui teised sama valdkonna ettevõtted teevad. Selle tarkvaraga seoses peaks toimuma innovatsioon. Leian, et administratiivsed allsüsteemid vastavad tarbetarkvarale ning sisulised allsüsteemid strateegilisele tarkvarale.

## Küsimus: Kuidas salvestada PostgreSQL andmebaasis tabelite muudatuste ajalugu? Lahendus peaks olema üldine, mitte ühe konkreetse tabeli spetsiifiline.

Kas siin artiklis toodud lahendus on mõistlik? https://www.cybertec-postgresql.com/en/tracking-changes-in-postgresql/

**Vastus:**

Andmebaasi kasutamise (sh andmemuudatuste jälgimist) nimetatakse auditeerimiseks (auditing). Andmebaasisüsteemid pakuvad sageli selleks erinevaid sisseehitatud võimalusi kuid kui neid ei ole või need pole sellised nagu vaja, siis trigerid on andmemuudatuste logimise realiseerimiseks sobilik valik. Artiklis pakutud lahendus on kahtlemata võimalik. Enne selle kasutusele võttu lugege palun siiski järgnevat.Trigeripõhiste lahenduste üldine probleem (mistahes andmebaasisüsteemis)

Kuna trigereid ei saa panna reageerima SELECT sündmustele, siis ei saa trigerite abil logida andmete vaatamist.

Trigeripõhise lahenduse üldine probleem PostgreSQLis

Kui andmemuudatus ebaõnnestub, siis tühistatakse andmebaasisüsteemi poolt kõik vastavast transaktsioonis tehtud andmemuudatused ja kõik nende poolt algatatud muudatused (sh käivitunud trigerite tehtud muudatused). Seega ei saa trigerite abil logida ebaõnnestunud muudatusi. Oracles saaks näiteks andmemuudatuse logimise realiseerida autonoomse transaktsioonina, mis tähendab, et logi kirjutamine õnnestub isegi siis, kui muudatus, mis logi kirjutamise algatas, ebaõnnestub ja rullitakse tagasi.

Konkreetse trigeripõhise lahenduse probleemid/nõrkused/mõttekohad.

Triger ei logi kõikide ridade kiiret kustutamist (TRUNCATE operatsioon).
Kui UPDATE lause reas midagi ei muuda, siis operatsiooni toimumise kohta registreeritakse kirje ikkagi.
UPDATE lause puhul logitakse ka need väljad, milles andmed ei muutunud.
Tuleks kaaluda, kas veergude old_val ja new_val puhul kasutada tüüpi JSON või JSONB (erinevus on väärtuse sisemises esitusviisis), arvestades kummagi eeliseid ja puuduseis. PostgreSQL juhendmaterjalides on igatahes öeldud:

"In general, most applications should prefer to store JSON data as jsonb, unless there are quite specialized needs, such as legacy assumptions about ordering of object keys."


Logitabeli maht läheb kiiresti väga suureks ja võiks mõelda selle sektsioonideks jagamisele (partitioning).

SIIN kirjeldatakse veel erinevaid võimalusi PostgreSQLi andmebaasis toimuvate andmekäitluse operatsioonide logimiseks. Juttu on:

andmebaasisüsteemi sisseehitatud logimise funktsionaalsusest (log_statement = all), mis tuleb administraatori poolt sisse lülitata,
universaalsest trigeripõhisest lahendusest (Audit trigger 91plus),

Küsimuses pakutud lahendusest eristab seda see, et saab logida TRUNCATE operatsioonide tulemusi, logitakse rohkem metaandmeid muudatuse kohta ja UPDATE operatsiooni puhul logitakse ainult muutunud väärtuseid.


pgAudit laiendusest.

Veel üheks lahenduseks ajalooliste andmete hoidmisel oleks disainida tabelid nii, et nendes saaks hoida ka ajaloolisi andmeväärtuseid. Sellist lähenemist pakub näiteks ankurmodelleerimine (siin on veidi eesti keeles). Põhimõtteliselt tekib selle kasutamisel iga olemitüübi atribuudi kohta eraldi tabel. Tabelite mugavamaks kasutamiseks luuakse vaated ja funktsioonid. Arendustööd aitab automatiseerida modelleerimiskeskkond, kus on muuhulgas ka koodigeneraator PostgreSQL jaoks (arendatud ühe meie ülikooli magistritöö tulemusena). Kui kartust tekitab see, et suure hulga tabelite ühendamine vähendab jõudlust, siis seda aitab kiirendada tabelite elimineerimise teisendus, mida oskab teha ka PostgreSQL. Selles lõputöös (on küll Oracle näitel, aga siiski) katsetatud ankurmodelleerimise andmebaasi.Selles magistritöös kirjeldatakse veel  ühte võimalust andmemuudatuste ajaloo säilitamiseks ja realiseeritakse märkimisväärne osa seda toetavast taristust (operaatorid, vaated, trigerid) PostgreSQL jaoks.

## Küsimus: Kui Enterprise Architect (EA) ei luba töötada DDLenhace-ga ja mudeli disain tuleb teha DDL-ga, siis kuidas kontrollida millised parameetrid peavad olema kohustuslikud ja millised PK või FK ning millistel parameetritel peab olema vaikimisi väärtus?

**Vastus:**

Atribuutide alusel tekkivate veergude kohustuslikkus
Atribuutide definitsiooni tabelis (jaotises 2.2.1 - peale olemi-suhte diagramme ja olemitüüpide definitsioone) peab iga atribuudi puhul kitsenduste osasse kirjutama, kui see on kohustuslik, st selle väärtus peab olema alati määratud - {Registreerimine on kohustuslik.} Lisaks tuleb Enterprise Architecti abil tehtud olemi-suhte diagrammides ära näidata, millised atribuudid on kohustuslikud (võimsustik (multiplicity) 1) ja millised mittekohustuslikud (võimsustik 0..1).
Kui teisendate kontseptuaalse andmemudeli SQL-andmebaasi disaini mudeliks, siis laias laastus vastab igale atribuudile eraldi tabeli veerg. Kui atribuut on kohustuslik, siis vastavale veerule tuleb deklareerida NOT NULL kitsendus. Kui atribuut ei ole kohustuslik, siis seda kitsendust ei ole. Kontseptuaalse andmemudeli mallis olevatest atribuutidest on mittekohustuslikud:

Isik.eesnimi
Isik.perenimi
Isik.elukoht
Amet.kirjeldus

Ülejäänud atribuudid on kohustuslikud (st vastavatel veergudel peab olema NOT NULL). Võimalik, et lisatud X atribuutide hulgas on ka mõni mittekohustuslik (nt kirjeldus või kommentaar), kuid see valik on juba Teie teha.
Seosetüüpide alusel tekkivate veergude kohustuslikkus
Mis puudutab välisvõtme veergude kohustuslikkust, siis see sõltub seosetüübi võimsustikest (multiplicity). Näide:
[Riik]-1-+isikukoodi riik-----------0..*-[Isik]
Iga isik on seotud täpselt ühe isikukoodi riigiga. Järelikult tabelisse Isik tekkival välisvõtme veerul riik_kood peab olema NOT NULL kitsendus.
[Riik]-0..1-+isikukoodi riik-----------0..*-[Isik]
Iga isik on seotud nulli või ühe isikukoodi riigiga. Järelikult tabelisse Isik tekkiv välisvõtme veerg riik_kood võib lubada NULLe.
Malli järgi projekti tehes peaks kõikidele välisvõtme veergudele deklareerima NOT NULL kitsenduse.
Vaikimisi väärtused
Vaikimisi väärtused on mugavusvahend, juhuks, kui paljudes/kõigis uutes ridades on ühesugune väärtus või ühesugusel viisil leitav väärtus. Vaikimisi väärtus ei ole kitsendus - sellest saab alati jõuga üle sõita. Malli järgi tehtavas projektis peaksid olema järgmised vaikimisi väärtused.

Välisvõtme veergudel, mis viitavad seisundiklassifikaatorite tabelitele (Isiku_seisundi_liik, Tootaja_seisundi_liik, Kliendi_seisundi_liik, X_seisundi_liik) - väärtus, mis näitab esimesena saadava seisundi koodi. Näiteks X korral on selleks seisundile "ootel" vastav kood, sest seisundidiagrammi alusel (vt jaotis 2.2.3) läheb iga X kõigepealt seisundisse "ootel". Need vaikimisi väärtused peavad olema tabelites Isik, Tootaja, Klient, X.
Isik.reg_aeg ja X.reg_aeg - avaldis, mille poole pöördumisel tagastatakse hetke kuupäev ja kellaaeg (näiteks MS Accessis Now()).
Klient.on_nous_tylitamisega - FALSE - tulenevalt vaikimisi andmekaitse põhimõttest.

Primaarvõtmed
Hästi kavandatud SQL-andmebaasi tabelis tuleb jõustada kõik kandidaatvõtmed - üks primaarvõtmena (PRIMARY KEY kitsendus) ülejäänud alternatiivvõtmetena (UNIQUE+NOT NULL kitsendus). Kontseptuaalses andmemudelis tuleb atribuutide definitsiooni kirja panna, kui mingi atribuut või atribuutide kombinatsioon on unikaalne identifikaator. Primaarvõti tuleb kas jõustada ühele nendest vastavate veergude alusel või defineerida surrogaatvõti. Surrogaatvõtme väärtused on süsteemi poolt genereeritud unikaalsed täisarvud, mida kasutatakse olemitele viitamiseks ainult tarkvarasüsteemi siseselt, mitte inimeste maailmas. Malli alusel tehtavas projektis on surrogaatvõti mõistlik ainult tabelis Isik - (isik_id). Ülejäänud tabelites saab valida sisulise võtme - näiteks tabelis Riik (riik_kood), tabelis X (X_kood) jne. Tabelites Klient ja Tootaja peaks primaarvõti (isik_id) kokku langema välisvõtmega, mis viitab tabelile Isik.
Välisvõtmed
Üks-mitmele seosetüübi korral tekib välisvõti mitu poolel olevasse tabelisse.
[Riik]-1-+isikukoodi riik-----------0..*-[Isik] - välisvõti on tabelis Isik.
Mitu-mitmele seosetüübi korral tekib vahetabel koos kahe välisvõtmega.

**Märksõnad:** teisendus, mudeliteisendus, DDLEnhanched, DDL_enhanced

## Küsimus: Kui tekstilist väärtust hoidev väli või olla ka tühi, kas parem on lubada NULL väärtust või tühja stringi? Kas võib olla põhjust lubada ka mõlemat?

**Vastus:**

Tabeli väljast võivad väärtused puududa erinevatel põhjustel. Näiteks väärtus ei ole veel andmete sisestajateni jõudnud või sellist väärtust kunagi ei tekigi.  Üheks põhjenduseks, miks lubada tekstilises veerus NULLi ja tühja stringi oleks see, et need kodeerivad erinevaid puudumise põhjuseid.Siiski võib kergesti juhtuda, et NULLid ja tühjad stringid satuvad tabelisse juhuslikult ja kokkuvõttes on vaja kirjutada keerukamaid päringu tingimusi.SELECT isik_id FROM Isik WHERE eesnimi='' OR eesnimi IS NULL;(leia isikud, kellel eesnimi puudub)SELECT isik_id FROM Isik WHERE eesnimi<>'' AND eesnimi IS NOT NULL;(leia isikud, kellel on eesnimi olemas), selle asemel, et kirjutada lihtsalt:SELECT isik_id FROM Isik WHERE eesnimi IS NULL;SELECT isik_id FROM Isik WHERE eesnimi IS NOT NULL;Minu soovitus:- Keelake tekstilises veerus tühjad stringid ja tühimärkidest koosnevad stringid.- Kui väärtused võivad puududa, siis lubage NULLe.- Kui tabelis on veerg, millele vastavasse välja teatud ridade puhul väärtust kunagi ei teki, siis tuleb parandada andmebaasi disaini.

liigutada veerg teise tabelisse ja muuta seal see veerg kohustuslikuks
või luua algses tabelis seda olukorda kirjeldavad kitsendused

Näiteks oletame, et tabelis Subjekt, kus on andmed nii füüsiliste isikute kui organisatsioonide kohta, on selline veerg nagu isiku isikukood. Parem oleks, kui oleks eraldi tabelid Osapool (isikute ja organisatsioonide ühiste atribuutide/seosetüüpide jaoks), Isik ja Organisatsioon. Veerg isikukood peaks olema tabelis Isik kohustuslik veerg. Kui tabelite struktuuri muutmine pole võimalik, siis tuleks jõustada reeglid nagu:



kui (organisatsiooni) registrikood on määratud, siis isikukood peab puuduma.
kui (isiku) isikukood on määratud, siis peab (organisatsiooni) registrikood puuduma.



P => QKui kehtib tingimus P, siis peab ka kehtima tingimus QLoogiliselt samaväärne kui: NOT (P) OR QCHECK (NOT (reg_kood IS NOT NULL) OR isikukood IS NULL)CHECK (NOT (isikukood IS NOT NULL) OR reg_kood IS NULL)Puuduvate andmete kohta saab pikemalt lugeda SIIT.

**Märksõnad:** puuduvad andmed, tühi string, empty string, allow zero length

## Küsimus: Küsimus kontseptuaalse andmemudeli kohta. Ma saan aru, et peame atribuute lisama X'le ja näiteks kliendile (on_nõus_tülitamisega), aga kuidas on erinevate standartsemate atribuutidega teiste olemitüüpide puhul. Nagu näiteks Töötaja_seisundi_liik, X_seisundi_liik või Riik: kas neile peaks ka lisama atribuudid nagu näiteks seisundi_liik_id, nimetus, kirjeldus. Vaadates vastuvõtuaegade näidisprojekti, siis seal näiteks pole neid atribuute kontseptuaalses andmemudelis välja toodud, kuid füüsilises disainis on. Samas X'i jaoks toome me ka kontseptuaalses andmemudelis selle koodi ja nimetuse välja. Seetõttu olen veidi segaduses ja lootsin, et ehk oleks võimalik natukene selgitust või suunamist saada sellele, missugused parameetrid lähevad kontseptuaalsesse andmemudelisse ning mis ainult füüsilisse disaini.

**Vastus:**


Kõikidel klassifikaatoritel (sh Riik, X_seisundi_liik, Töötaja_seisundi_liik jne) on pärimise kaudu atribuudid kood ja nimetus. Need atribuudid on kirjeldatud olemitüübis Klassifikaator ja alamtüüpide juures ei ole vaja neid uuest kirjeldada. Alamtüübi juures tuleb kirjeldada täiendavad atribuudid, mis on spetsiifilised konkreetsele alamtüübile - nii nagu Amet puhul on esitatud atribuut kirjeldus. Kirjeldusi on plaanis registreerida ainult ametite puhul, kuid mitte näiteks riikide ja töötaja seisundi liikide puhul. Teisendusreeglite rakendamise tulemusena tekivad taolisest kontseptuaalsest andmemudelist sellised tabelid nagu Töötaja_seisundi_liik (töötaja_seisundi_liik_kood, nimetus) ja Amet (amet_kood, nimetus, kirjeldus). Eraldi tabelit Klassifikaator ei looda, sest sellel oleks palju puuduseid.


Kontseptuaalne andmemudel kirjeldab nõudeid andmetele, mitte andmebaasi tehnilist realisatsiooni konkreetse andmemudeli põhjal ja konkreetses andmebaasisüsteemis. Kontseptuaalses andmemudelis EI ESITATA:- "välisvõtme" atribuute - näiteks riigi_kood EI OLE Isik atribuut,- "surrogaatvõtme" atribuute - näiteks kui isik_id väärtused on kasutusel tarkvara siseselt, kuid mitte lõppkasutajate maailmas, siis olemitüübi Isik puhul atribuuti isik_id ei kirjeldata.


X_kood on X atribuut seepärast, et see on sisuline ja tarkvara välises maailmas tähendust omav kood (nagu isikukood, auto registrikood, VIN kood, ainekood, üliõpilaskood jne). Kuna X_kood on sisuline atribuut, siis seda kirjeldatakse kontseptuaalses andmemudelis.






**Märksõnad:** kontseptuaalne andmemudel, olemi-suhte diagramm, atribuut, atribuudid

## Küsimus: Ma olen informaatika üliõpilane. Ma arvan, et kursuse töö töövihik on suur dokument mida keegi ei kasuta päris elus. Aine projekti tegemine on täielik ajaraisk, sest kogu info mida õppejõud näha tahab tuleb temalt ning kui ise sellest väga õppida ei saa. Milliseid kasulikke teadmisi, lisaks andmebaasidele, see projekt (informaatikutele) annab?

**Vastus:**

1. Üks võimalik viis, kuidas tarkvara tükeldada. Tükeldamine on vajalik tarkvara keerukusega toimetulekuks ja töö paremaks organiseerimiseks.2. Ülevaade võimalikest mudelitest, mida saab kasutada tarkvara kirjeldamiskes. Ka agiilne süsteemiarendus ütleb, et modelleerimine on vajalik. Tuleb luua mudeleid, millest on kasu, mitte linnukese pärast. Erinevates olukordades, võib olla kasu erinevatest mudelitest. Selleks, et osata otsustada, kas mingit tüüpi mudel mingis olukorras sobib või mitte, tuleb esmalt neid mudeli tüüpe teada. Samuti tuleb arendajal osata aru saada nõuetest ja seega ka mudelitest, mida võidakse kasutada nende nõuete väljendamiseks.3. Puhta koodi põhimõtted on universaalsed ja kehtivad ka mudelite ning andmebaasi disaini puhul.4. Andmebaasis kitsenduste loomine on üks kaitsva programmeerimise meetod. Kaitsev programmeerimine üritab tagada koodi toimist ka ettenägematute asjaolude ilmnemisel ja see aitab parandada süsteemi käideldavust ja turvalisust. Siin on raamat, mis on pühendatud kaitsvale andmebaasi programmeerimisele.Kirjutan järgnevalt täpsemalt ja toon näiteid.1. Tänapäeval on üheks lööksõnaks e "kuumaks teemaks" mikroteenuste arhitektuur. See tähendab, et tarkvara peaks koosnema üksteisest võimalikult vähe sõltuvatest "tükkidest" e teenustest, mida saaks arendada ülejäänud "tükkidest" võimalikult sõltumatult, mida saaks kerge vaevaga asendada uue realisatsiooniga ja mida ei peaks (palju) muutma, kui mõnes teises "tükis" midagi muutub. Iga funktsionaalse allsüsteemi saaks realiseerida mikroteenusena. Selle funktsionaalse allsüsteemi teenindatava registri saaks realiseerida rakenduse andmebaasina.Mikroteenused üritatakse luua üksteisest võimalikult sõltumatuna, eelistades dubleerimist üksteisest ilmutatud viisil sõltumisele. Andmebaaside mõttes tähendaks see, et erinevate teenuste andmebaasides dubleeritaks põhiandmeid (master data) nagu andmed klientide, toodete ja teenuste kohta ja klassifikaatoreid. Kommentaariks ütlen, et see võib tunduda teenuse autonoomsuse mõttes ahvatlev, kuid andmete dubleerimine tähendab suuremat tööd nende sünkroniseerimiseks (nii suuremat tööd arendajatel selle realiseerimiseks/testimiseks kui ka suuremat koormust süsteemile läbiviimisel) ja suuremat võimalust vastuoluliste väidete registreerimiseks. Kas see on sobiv hind või mitte jäägu igaühe enda otsustada ja kindlasti sõltub ka oludest. (Eesti) Riigi infosüsteemide kohta ütleb avaliku teabe seadus selge sõnaga: "§ 43 3.   Andmekogu asutamine (2) Keelatud on asutada ühtede ja samade andmete kogumiseks eraldi andmekogusid." Põhiobjektidest lähtuv allsüsteemide leidmine on üks võimalik viis mikroteenuste kindlaks määramiseks ja põhiobjekti elutsüklist lähtuv funktsionaalsuse leidmine on üks võimalik viis selle teenuse funktsionaalsuse tuvastamiseks. Kui soovida luua mikroteenused võimalikult autonoomsena ja vajadusel dubleerida andmeid erinevate teenuste andmebaasides, siis saaks teenused luua põhiobjektidele, mis vastavad transaktsioonilistele andmetele ning põhiandmetele ja klassifikaatoritele vastavaid andmeid erinevates andmebaasides dubleerida. Siin on näide hotelli infosüsteemi põhiobjektidest andmete liigituse järgi.2. See on väga vähetõenäoline, et mõni ettevõte kasutab süsteemide kirjeldamiseks just sellist dokumendi struktuuri nagu on aineprojektis. Kuid see, et mingil määral kasutatakse modelleerimist ja mudeleid ning mõnda antud projekti mudeli tüüpidest, on väga palju tõenäolisem.Hea allikas, kust saab lugeda erinevate aineprojekti mudelitüüpide kohta, on:

Larman, C., 2013. Applying UML and patterns : an introduction to object-oriented analysis and design and iterative development, Prentice Hall. 703 p.

Seda saab ka lugeda O'Reilly digitaalse platvormi kaudu elektrooniliselt.
Kuidas kasutada O'Reilly digitaalset platvormi?



See raamat on pühendatud objektorienteeritud analüüsile ja disainile (eesmärgiga luua objektorienteeritud programmeerimiskeeles tarkvara), kuid räägitakse ka arendusprotsessist. Mudelite koostamine ei ole mitte kuidagi vastuolus iteratiivse arendamisega. Lihtsalt mudeleid ei looda ühekorraga, vaid neid luuakse ja täiendatakse järk-järgult erinevate iteratsioonide käigus. Raamatus kirjutatakse muuhulgas põhjalikult:

klassidiagrammidest, mida kasutades luuakse valdkonnamudeleid (domain model),

Kontseptuaalne andmemudel ja valdkonnamudel on sugulased ja kontseptuaalse andmemudeli loomise võtted ning mustrid on kõik kasutatavad ka valdkonna klassidiagrammide koostamiseks. Sama kehtib ka antimustrite kohta, mis esitavad esmapilgul häid lahendusi, mis hiljem viivad probleemideni. Need klassidiagrammid on omakorda sisendiks tarkvaraklasside leidmisele (nii nagu kontseptuaalne andmemudel on sisendiks tabelite leidmisele),


seisundidiagrammidest,
tegevusdiagrammidest,
kasutusjuhtude mudelist,
süsteemi operatsioonide lepingutest

Need on sarnased andmebaasi operatsioonide lepingutega. Süsteemi operatsioonid kirjeldavad teenuseid, mida funktsionaalsed allsüsteemid (tarkvara) pakuvad pädevusaladele (lõppkasutajatele). Andmebaasi operatsioonid kirjeldavad teenuseid, mida andmebaasi alamosad (registrid) pakub funktsionaalsetele allsüsteemidele (tarkvarale).
Nii nagu süsteemi operatsioonide lepingutest tekivad tarkvara klasside meetodid, tekivad andmete muutmise operatsioonide lepingutest andmebaasiserveris talletatud rutiinid (funktsioonid ja protseduurid).
Operatsioonide lepingud võiksid huvi pakkuda ka seetõttu, et need lähtuvad lepingprojekteerimise (design by contract) põhimõttest. See põhimõte töötati välja seoses objektorienteeritud programmeerimiskeelega Eiffel ning lähtub tarkvara elementide käitumist viisil, mida ideaalis saaks hiljem kasutada tarkvara kontrollimiseks või koodi genereerimiseks. Sellel teemal mõtlejaid on teisigi (vaadake History alamosa Larmani raamatu süsteemi operatsioonide lepingute peatükist) ja nende idee on kasvanud välja arvutiteaduse (computer science) ringkondadest.



Järgnev raamat argumenteerib, miks kontseptuaalse andmemudeli ja andmebaasi disainimudeli loomine ei ole ka agiilse andmebaasi arenduse mõttes ajaraisk, vaid igati kasulik ettevõtmine.Burns, L., 2011. Building the Agile Database. How to Build a Successful Application Using Agile Without Sacrificing Data Management, Technics Publications. 276 p. CRUD maatrikseid on arvutiteaduses üritatud kasutada süsteemide struktuuri leidmiseks ja see on huvitav uurimissuund (vaadake näitena seda artiklit ja ka seda).3. Lugege näiteks siit, kuidas peaagu igale koodi halvale lõhnale vastab mingi analoogiline probleem seoses infosüsteemi/tarkvara mudelitega. Samamoodi esinevad andmebaasis ja tekitavad sellest arusaamisel, õppimisel, hooldamisel ja edasiarendamisel probleeme näiteks halvad andmebaasiobjektide nimed, kasutama andmebaasiobjektid, ebatäpsed kommentaarid, üleliigne dubleerimine ja järjekindlusetus disainiotsuste tegemisel.

**Märksõnad:** iseseisev töö, projekt, dokument, dokumentatsioon, mudelid, project, diagramm, diagrammid, puhas kood, allsüsteem, funktsionaalne allsüsteem, register, andmebaasioperatsioon, andmebaasioperatsioonide lepingud

## Küsimus: Meie töövihiku projekti teemaks on treeningute funktsionaalne allsüsteem. Dokumendi punktis 1.2.3 (Allsüsteemi poolt vajatavad registrid) me kirjutame, et kasutame saalide registrit. Kas see tähendab, et meie projekti kontseptuaalse andmemudeli osaks peab olema saalide registri olemi-suhte diagramm?

**Vastus:**

Jah!
Kommentaarid:
1.
Töövihiku korral, kui X=Treening, siis
Treening = Ainekaart
Öelda, et iga treening on seotud täpselt ühe saaliga oleks sama, kui öelda näiteks ÕISis "Andmebaasid I" ainekaardil, et seda õpetatakse ainult ruumis ICT-404. Tegelikult saab seda ainet õpetada paljudes ruumides. Võimalik on anda sellele seosetüübile uus tähendus ja öelda, et tegemist on eelistatud saaliga selle treeningu läbiviimiseks. Selleks saab mudelis määrata saali rolli selle seosetüübi kontekstis.
[Treening]-0..*-----+eelistatud saal-1-[Saal]
2. Igal põhiobjektil on elutsükkel ja infosüsteemis peab olema võimalik jälgida, millises seisundis on selle eksemplarid. Sellest sõltuvad süsteemis tehtavad tegevused. Näiteks ma ei tohiks saada siduda treeningut "Suletud" seisundis saaliga.
Seega peab kontseptuaalses andmemudelis olema:
[Saal]-0..*-----------1-[Saali seisundi liik]
Samuti tuleb treeningu registreerimise ja treeningu andmete muutmise andmebaasioperatsioonide eeltingimustes ära kirjeldada, millises seisundis saalidega saab treeningut siduda.
3. Võimalik lihtsustus on käsitleda saali klassifikaatorina. Sellisel juhul oleks mudelis Saal Klassifikaatori alamtüübiks ja eraldi saalide registrit pole äriarhitektuuris vaja. Selline lahendus sobib, kui saalide andmete haldamiseks tehtavad toimingud ei erine teiste klassifikaatorite andmete haldamiseks tehtud toimingutest ja saalide elutsükkel ei erine teiste klassifikaatorite elutsüklist. Sellisel juhul puudub mudelist olemitüüp Saali_seisundi_liik. 

## Küsimus: Meil on küsimus aadressi kohta. Kuidas on parem viis pakiautomaadi (kaupluse/kino/treeningsaali/...) aadressi andmebaasis salvestada? Me nägime, et Omniva lehel näidatakse seda niimoodi: "Ida-Viru maakond, Kohtla-Järve linn, Ahtme linnaosa, Maleva tn, 23". Tundub, et iga koma vahel on eraldi veerg, kuhu kirjutatakse andmed ja veerude nimed oleksid "asukoht_maakond, asukoht_linn, asukoht_linnaosa, asukoht_tänav, asukoht_tänava_nr". Kas me kasutame selle viisi, või saame parema loetavuse jaoks lihtsalt salvestada kogu stringi ühe veergu nimega "asukoht"?

**Vastus:**

Aadressiandmetel on keeruline struktuur ja palju erinevaid võimalikke komponente (riik, maakond, linn, vald, küla, talu, linnaosa, tänav, korter, hooneosa, ...). Erinevates riikides on võimalike komponentide hulk erinev. Kui ülesanne oleks pakkuda kasutajatele detailset aadresside otsimise võimalust, siis andmebaasi mõttes tähendaks see märkimisväärset hulka täiendavaid tabeleid, mille vahel komponentideks jagatud aadress ära jagada. Näitena on selle dokumendi jaotises 2.4 Eesti aadressiandmete süsteemi andmemudel. Kui eesmärk on pakkuda taustainfot pakiautomaadi kohta (nagu antud projektis), siis piisab vabatekstilisest atribuudist aadress."Sulgude ette" võib tõsta Maakonna. Maakond on klassifikaator.[Pakiautomaat]-0..*---------+asukoht-1-[Maakond]​Siit näete maakondade klassifikaatori väärtuseid. Kui pakiautomaadid võivad olla eraldi riikides, siis tõstaksin maakonna asemel "sulgude ette" riigi.​[Pakiautomaat]-0..*----------+asukoht-1-[Riik]Saaksite kasutada sama riikide klassifikaatorit, mis on juba seotud olemitüübiga Isik. Maakonna klassifikaatorit ma siis ei kasutaks, sest kõigis riikides ei pruugi olla haldusüksust "maakond" ning erinevate riikide maakondade üle võib olla raske arvet pidada.​    Kokkuvõttes oleks näite korral pakiautomaadi atribuudi aadress väärtuseks "Kohtla-Järve linn, Ahtme linnaosa, Maleva tn, 23" ning pakiautomaat oleks seotud maakonnaga Ida-Virumaa.

## Küsimus: Mida kujundab endast elementaarvõtme normaalkuju (EVNK)?

**Vastus:**

Kui ma vaatan C.J Date ja J. Celko töid, siis nad mainivad seda normaalkuju lühidalt, ajaloolise tagasivaate ja esitluse täielikkuse huvides. C.J. Date osundab, et EVNK-le viidatakse kirjanduses vähe.EVNK on kolmanda normaalkuju (3NK) ja Boyce/Coddi normaalkuju (BCNK) vahel - kui tabel on elementaarvõtme normaalkujul, siis on see ka kolmandal normaalkujul. Eesmärk on ikkagi jõuda Boyce/Coddi normaalkujuni. Muide, see artikkel, kus EVNK välja pakutakse, annab head 3NK ja BCNK definitsioonid. EVNK käsitleb olukorda, kui tabelil on rohkem kui üks liitvõti ja need võtmed osaliselt kattuvad (st neil on ühiseid veerge). Sellisel juhul võib kattuvates veergudes olla korduvaid andmeid.C. J. Date defineerib EVNK järgnevalt: "Tabel on elementaarvõtme normaalkujul (EVNK) siis ja ainult siis kui iga mittetriviaalse funktsionaalse sõltuvuse X=>Y korral on kas a) X tabeli supervõti või b) Y on mõne elementaarvõtme alamvõti. K on tabeli T elementaarvõti siis ja ainult siis kui tabelis T on selline veerg V, mille puhul funktsionaalne sõltuvus K=>{V} on mittetriviaalne ja täielik." (https://learning.oreilly.com/library/view/database-design-and/9781449330187/ch13.html#concluding_remarks-id4)J. Celko esitab tabeli sellele normaalkujule viimise kohta näite.https://learning.oreilly.com/library/view/joe-celkos-sql/9780123693792/9780123693792_ch02lev1sec5.html Aine_deklareerimine (yliopilaskood, ainekood, aine_nimetus)Primaarvõti (yliopilaskood, ainekood)Alternatiivvõti (yliopilaskood, aine_nimetus)Mittetriviaalsed täielikud funktsionaalsed sõltuvused selles tabelis:(yliopilaskood, ainekood) => aine_nimetus(yliopilaskood, aine_nimetus) => ainekoodainekood=>aine_nimetusaine_nimetus=>ainekoodÜlekanduvaid sõltuvusi selles tabelis ei ole ja seega on see tabel kolmandal normaalkujul.Leidub funktsionaalseid sõltuvusi, mille determinant ei ole kandidaatvõti ning seega pole see Boyce/Coddi normaalkujul.ainekood=>aine_nimetusaine_nimetus=>ainekoodLähemal vaatlemisel ilmneb, et tabelis võivad ainete andmed olla erinevates ridades dubleeritud, st selles tabelis on andmete liiasust, mida saaks täiendava normaliseerimisega vähendada.Tabeli elementaarvõtmed on minu arusaamise kohaselt.
(yliopilaskood, ainekood)
(sest leidub veerg aine_nimetus, nii et (yliopilaskood, ainekood) => aine_nimetus)
(yliopilaskood, aine_nimetus)
(sest leidub veerg ainekood, nii et (yliopilaskood, aine_nimetus) => ainekood)
Need on kandidaatvõtmed, st nende atribuutide pärisalamhulk ei ole enam võti. Järelikult eelnevalt välja kirjutatud neljast funktsionaalsest sõltuvusest kaks viimast ei rahulda EVNK tingimusi.Lahendus oleks luua tabelidAine (ainekood, aine_nimetus)Primaarvõti (ainekood)Alternatiivvõti (aine_nimetus)Aine_deklareerimine (yliopilaskood, ainekood)Primaarvõti (yliopilaskood, ainekood)Välisvõti (ainekood) Viitab Aine (ainekood)Need tabelid on ka BCNK-l.

**Märksõnad:** elementary key normal form, EKND, normaliseerimine, normalization

## Küsimus: Mida ma võiksin teada NoSQL süsteemidest?

**Vastus:**

Teemas 1 ja 11 on juttu NoSQL süsteemidest. Kes tahab nende kohta rohkem teada saada, siis võiks alustada sellest Martin Fowleri umbes tunni pikkusest videost. Kes eelistab lugeda, saab vaadata seda materjali, laenutada raamatukogust raamatu, mille kokkuvõtteks see materjal on või lugeda seda sama raamatut elektrooniliselt (Kuidas kasutada O'Reilly digitaalset platvormi?).
Hilisemast ajast tasub vaadata arvutiteadlase Michael Stonebrakeri ettekannet suurandmete ja nendega töötamise vahendite (sh NoSQL süsteemid) kohta.
Vastukaaluks positiivsele "uus ja lahe läikiv mänguasi" tüüpi käsitlusele võiksid huvilised vaadata ka 2013. aastast pärit artiklit "History repeats itself: sensible and NonsenSQL aspects of the NoSQL hoopla", mis annab minu arvates realistliku vaate NoSQL süsteemide headele ja mitte nii headele külgedele. Kokkuvõte artiklist - kes minevikku ei mäleta, on määratud selle vigu kordama (väide, mis kehtib igal elualal).
NoSQL and Technical Debt. Ajaveebi postitus, mis selgitab, miks NoSQL süsteemide ilmumine pole muutnud väärtusetuks SQLi ning andmebaaside projekteerimise õppimist. Nende oskuste puudumine on arendajatel võlg, mis tuleb hiljem intressidega tagasi maksta. NoSQL oma "skeemitute" andmetega loob tegelikult tehnilist võlga. Aina rohkemates NoSQL süsteemides saab andmebaasi tasemel kirjeldada ja jõustada andmebaasi struktuuri (näide) (kirjutamise skeemi e schema-on-write). Saadakse aru, et struktuur on eelis mitte puudus. Aina rohkemates NoSQL süsteemides saab kasutada deklaratiivset andmebaasikeelt (näide), mis paraku (SQL pole just kõige paremini disainitud keel) enamasti meenutab SQLi. Saadakse aru, et deklaratiivset keelt on palju kergem kasutada ja õppida kui imperatiivset. Irvhambad juba ütlevad, et NoSQL = Not Yet SQL.Siin on päris pikk ja põhjalik eestikeelne materjal, mille teine pool on pühendatud NoSQLil.

## Küsimus: Miks mitte luua klassifikaatoritele ühist tabelit Klassifikaator, kus on kõikide klassifikaatorite koodid ja nimetused?

**Vastus:**

Vastuse leiate selle artikli esimesest punktist.Selle ülevaate alajaotus "One True look-up Table" on pühendatud ühisele klassifikaatorite tabelile:https://www.red-gate.com/simple-talk/databases/sql-server/t-sql-programming-sql-server/look-up-tables-in-sql/Kes tunneb teema vastu sügavamat huvi võib vaadata bakalaureusetööd:
Vellemaa, A.S., 2015. Mõned disainimustrid klassifikaatorite esitamiseks SQL andmebaasides. Bakalaureusetöö. TTÜ Informaatikainstituut [WWW] https://digi.lib.ttu.ee/i/?3484.

## Küsimus: Miks on kasulik tükeldada infosüsteemi allsüsteemideks?

**Vastus:**

Juhin Teie tähelepanu Postimehe 21.02.2017 artiklile "Riigi olulisema infosüsteemi seis: tengelpung lõhki, kalender ribadeks, aga lootust on".
Paljude infosüsteemide arendamisel tekib kahjuks olukord, et arendus läheb oodatust kallimaks ja võtab eeldatust rohkem aega. Selles artiklis on sellise olukorra tekkimise ja põhjuste väga ilmekas kirjeldus Eesti pensionide ja sotsiaaltoetuste maksmise infosüsteemi (SKAIS) uue versiooni (SKAIS2) näitel. Seda infosüsteemi kasutatakse igapäevaselt 110 erinevat liiki toetuse ja pensioni maksmiseks kokku 700 000 inimesele. Kokkuvõtlikult:

Arenduse valmimine lükkus edasi vähemalt 1,5 aastat .
Projekt läks kallimaks vähemalt 1,5 miljonit.
Arendajad olid artikli kirjutamise ajaks maksnud riigile 180 000 eurot trahve.

Otsene seos käesoleva aine temaatikaga tekib sellest, et algselt asuti kogu keerulist süsteemi arendama tervikuna. See oli korraga närimiseks liiga suur suutäis. Tõmmake paralleele sellega, et võtate suu täis mingit kõva maiustust ja siis ei saa isegi hambaid liigutada.
Nüüdseks on otsustatud arendamist jätkata osade kaupa. Need osad vastavad funktsionaalsetele allsüsteemidele. Süsteemi jagamine allsüsteemideks võimaldab allsüsteemide arendamist järk-järgult, arenduse tellimist erinevate hangetega ja võimalik, et erinevatelt firmadelt - täpselt nii nagu nüüd plaanitakse. Kuna iga hanke tulemusena tuleb teha valmis väiksem "tükk", siis on ka tähtajad paremini saavutatavad.
11.08.2017 sai see lugu kurva jätku, kui tehti teatavaks, et riik katkestab lepingu süsteemi senise arendajaga ja kuulutab välja uue hanke. Kokkuvõttes läks arendus algselt plaanitust vähemalt kaheksa miljonit EURi kallimaks (algne plaanitud maksumus 7.1 miljonit EURi) ja valmimine lükkus viis aastat edasi.
15.04.2018 kirjutati, et uues SKAIS2 arendamise lepingus pandi paika eeldatav tööde kestus (neli aastat), kuid ei fikseeritud täpseid tähtaegu ega arendamise graafikut. Täpne ajagraafik pannakse paika pärast infosüsteemi arhitektuuri analüüsi. Näib, et see analüüs meenutab siin aines kirjeldatavat strateegilist analüüsi. Strateegiline analüüs määrab süsteemi skoobi, leiab arhitektuuri (või arhitektuuri variandid), tuvastab riskid ja paneb paika arendamise ajakava. Lepingus määrati ära üldine tegevuste järjekord:

SKAISi arhitektuuri analüüs,
olemasolevate teenuste vastavusse viimine uue arhitektuuriga,
uute teenuste arendamise alustamine.

28.01.2019 kirjutas ajakirjandus, et juba 15 miljonit maksma läinud projekti jätkamiseks kuulutati 2019. aasta jaanuari keskel välja riigihange mahus 8 miljonit eurot. Olemasolevad arenduspartnerid jätkavad tööd vastavalt sõlmitud lepingule. Uue hanke eesmärk on samaaegselt arendada täiendavat funktsionaalsust.25.09.2020 tegi ajakirjandus vahekokkuvõtte, et selleks ajaks on süsteemile kulunud 12 miljonit eurot, kuid lepinguid on töödele kokku 44 miljoni euro eest. Projektiga tegeleb kuus IT-ettevõtet. Mõned asjad nagu iseteeninduskeskkond koos proaktiivse (ennetava) perehüvitise teenusega on valmis jõutud.

## Küsimus: Miks on vaja klassifikaatorite funktsionaalset allsüsteemi?

**Vastus:**

Eluline näide, kuidas klassifikaatorite väärtuste hulk võib ajas täieneda. See näide on soo klassifikaatori kohta. Selliste täienduste tegemine (hetkel uute väärtuste lisamine) toimuks infosüsteemi äriarhitektuuri mõttes läbi klassifikaatorite funktsionaalse allsüsteemi. Kasutajatele esitatavate klassifikaatori väärtuste nimetused peaksid olema ühes inimkeeles.
Kui süsteem peaks võimaldama kasutajaliidese keelt muuta, siis lõppkasutaja jaoks peaks keele muutmisel muutuma nii kasutajaliidese kui klassifikaatori nimetuste keel. Viimase saavutamiseks on erinevaid SQL-andmebaasi disaine. Süsteemide mitmekeelsuse küsimusi puudutab ka järgnev töö:
Hövel, E., 2017. Mõned mitmekeelsete SQL-andmebaaside disainimustrid. Bakalureusetöö. TTÜ Tarkvarateaduse instituut [WWW] https://digi.lib.ttu.ee/i/?8271

## Küsimus: Miks suurte IT-süsteemide arendamine pahatihti ebaõnnestub?

**Vastus:**

2019. aasta sügisel avaldas riigikontroll aruande (kokkuvõte) selle kohta, miks riigi tarkvaraarenduse projektid (mis enamasti on suuremahulised) nii mõnigi kord ebaõnnestuvad. Viimasel ajal on selle kohta päris mitmeid näiteid.
See aruanne oli üheks ajendiks, miks Andres Kütt pidas 4. oktoobril 2019 Tallinna Tehnikaülikoolis avaliku loengu teemal "Õppetunnid suurtest IT projektidest".
Tundub, et riigikontrolli aruanne tabas valusalt närvi, sest arvajaid ning kaasamõtlejaid oli palju. Tõstaksin veel esile Kaimar Karu arvamusloo teemal "Riigi tarkvaraprojektide õnnestumise võimalikkusest".

**Märksõnad:** arendus, infosüsteem

## Küsimus: Millal kasutada kontseptuaalses andmemudelis kompositsiooniseost (seose ühes otsas on täidetud romb e täidetud teemant)?

**Vastus:**

Kompositsioon tähistab osa-terviku seost, kus osad sõltuvad eksistentsiaalselt tervikust e terviku kadumine/hävimine tähendab ka osade kadumist/hävimist.Romb oleks selle olemitüübi poolel, millesse kuuluva olemi kustutamine tingib seotud olemite kustutamise.[Käsi]<*>-1------------0..*-[Sõrm]NB! Pange tähele võimsustikku (0..*), sest mitte kõigil inimestel pole käel täpselt viite sõrme. Näiteks sellele küsimusele/vastusele lisatud joonisel (vt vastuse lõpust) on kompositsiooniseoseid kindlasti liiga palju.Mulle meeldib kõige rohkem nõuanne, et kui kahtled, siis jäta osaks/tervikuks olemine märkimata.Andmebaaside taustaga inimest võiks nende määramise juures aidata küsimus: Milliste seoste puhul kasutaksin ma SQL-andmebaasis ON DELETE CASCADE (e kustutades terviku kustuvad automaatselt ka selle osad)? Nende puhul võib (ei pea) UMLi klassidiagrammis kasutada täidetud rombi (kompositsiooni).Kindlasti kasutaksin mina seda joonisel oleva näite puhul vaid ühes kohas: Isik-Isik roll.Isik-Isiku roll puhul kasutaksin kontseptuaalses andmemudelis kompositsiooni ja SQL-andmebaasis ON DELETE CASCADE, sest tegemist on registri põhiobjekti ning sellega seotud selle sama registri mittepõhiobjektiga.Valikukoht on minu arvates, kas kasutada kontseptuaalses andmemudelis kompositsiooni ja andmebaasis ON DELETE CASCADE ka järgnevate puhul:Koer-Varjupaigas_viibimineKoer-Koera_tervise_ankeetKoer-AdopteerimisavaldusLoogiline oleks, et kas kasutada seda kõigi kolme puhul või mitte ühegi puhul.

**Märksõnad:** kompositsioon, UML, olemi-suhte diagramm

## Küsimus: Milleks läheb vaja kontseptuaalses andmemudelis olevaid olemitüüpide ja atribuutide definitsioonide tabeleid?

**Vastus:**

Kontseptuaalse andmemudeli (on ka Teie projektis) üheks osaks on olemitüüpide ja atribuutide definitsioonid. Seal tuleb täpselt lahti selgitada, milliste andmete vajadusele kontseptuaalne andmemudel osundab. Näiteks hotelli "ruum" - kas mõeldakse kõiki ruume (ka köök ja fuajee) või ainult ööbimiseks mõeldud numbritubasid või hoopis numbritubades sisalduvaid ruume (vannituba, hoiuruum, eluruum). Näiteks kauba "tootja" - kas mõeldakse brändi (nt Apple, Olympus) või hoopis tehast, mis selle kauba kokku paneb.
Kontseptuaalne andmemudel ning olemitüüpide ja atribuutide definitsioonid osutuvad näiteks kasulikuks siis, kui on vaja hakata andmeid integreerima - erinevates andmebaasides olevatest andmetest tervikpilti kokku panema. Siis on näiteks vaja aru saada, kas "Klient" andmebaasis A ja "Klient" andmebaasis B on üks ja sama asi või mitte.
Lõpetuseks näide tänasest päevast, mis osutab infosüsteemide vahelise koostöö ja andmete integreerimise vajadusele. Intervjuu ajal justiitsminister olnud Urmas Reinsalu hinnangul pole normaalne olukord, kus tagaotsitav võib saada endale autojuhiload kätte. "Esimene loogiline lahendus peaks e-riigis olema suuremate andmebaaside omavaheline seotus, et kui tagaotsitav isik ilmub kasvõi e-tervisesüsteemi, siis lööb punane tuluke põlema," leidis Reinsalu. (Reinsalu: korduvalt karistatud inimesi tuleks vähemal määral usaldada. ERR Uudised 10.03.2016)

## Küsimus: Millised on erinevad tabelite võtmete tüübid ja kuidas need on omavahel seotud?

**Vastus:**

Supervõtmel peab olema:
- unikaalsuse omadus.
 
Kandidaatvõtmel peab olema:
- unikaalsuse omadus JA
- mitteliiasuse omadus. Mitteliiasus tähendab, et sealt ei saa enam ühtegi veergu ilma unikaalsuse omadust kaotamata eemaldada.
 
Kõik kandidaatvõtmed on supervõtmed. Iga supervõti ei pruugi olla kandidaatvõti. Kandidaatvõtme kohta öeldakse mõnikord ka minimaalne supervõti.Andmebaasis tuleb jõustada (primaar- ja alternatiivvõtmetena) kandidaatvõtmed.Primaarvõti e esmasvõti on kandidaatvõti, mis on teiste kandidaatvõtmete hulgast esile tõstetud (võrdseim võrdsete seas).Nii nagu riigil on korraga maksimaalselt üks kuningas või president on ka tabelis korraga maksimaalselt üks primaarvõti.Alternatiivvõtmed on kõik need kandidaatvõtmed, mis ei saanud primaarvõtmeks.


**Märksõnad:** kandidaatvõti, võtmekandidaat, supervõti, primaarvõti, esmasvõti, alternatiivvõti, võti

## Küsimus: Milliseid täiendusi tuleb arenduse tulemites (mudelid, andmebaas+rakendus) teha, kui tekivad uued nõuded, mida rakendus peab realiseerima?

**Vastus:**

Süsteemiarenduse tulemid (artefaktid) on omavahel läbipõimunud. Muutes ühte, on vaja muuta ka paljusid teisi. Toon näite. Vastuvõtuaegade süsteemis lisandus nõue, et vastuvõtt võib toimuda Interneti vahendusel, st mitte enam kindlas ruumis füüsiliselt kohtudes. Lahenduseks on, et info virtuaalse kohtumise kohta pannakse kirja vastuvõtu kommentaari ning kui vastuvõtul puudub ruum, siis peab sellel olema kommentaar.Tegin süsteemiarenduse tulemites järgmised muudatused.Muutused mudelites.

Lisandus ärireegel: "Kui vastuvõtt toimub Internetis, siis tuleb see kirjutada vastuvõtu kommentaari. Igal vastuvõtul peab olema registreeritud vähemalt üks kahest – ruum võikommentaar."
Olemi suhte diagrammil muutus võimsustik:

[Vastuvõtt]-0..*-------------------1-[Ruum] => [Vastuvõtt]-0..*-------------------0..1-[Ruum]
Muutus ja dokumendis tuli asendada nii kontseptuaalse andmemudeli eskiismudeli diagramm kui ka vastuvõtuaegade registri detailanalüüsi täpsusega olemi-suhte diagramm.


Kontseptuaalse andmemudeli atribuutide definitsioonis lisandus Vastuvõtt atribuudile kommentaar kitsendus: {Vähemalt üks kahest – ruum võikommentaar peab olema registreeritud.}
Muutusid detailanalüüsi täpsusega kasutusjuhtude kirjeldused - vastuvõttude nimekirjas tuleb nii õppejõule kui üliõpilasele lisaks vastuvõtu hoonele/ruumile näidata ka vastuvõtu kommentaari.
Andmebaasi disaini mudelis muutus tabeli Vastuvott veerg ruum_id mittekohustuslikuks.
Andmebaasi disaini mudelis tuli kirjeldada CHECK kitsendus, mille kohaselt igas tabeli Vastuvott reas peab olema määratud vähemalt üks kahest - kommentaar või ruum_id.
Vastuvõtuaegade registri muutunud disaini diagramm tuli dokumendis asendada.

Muutused realisatsioonis.

Tabeli Vastuvott veerult ruum_id tuli kustutada NOT NULL kitsendus.
Tabelile Vastuvott tuli luua valideerimisreegel, mille kohaselt igas tabeli Vastuvott reas peab olema määratud vähemalt üks kahest - kommentaar või ruum_id.
Vastuvõttude nimekirjavormidele tuli lisada ka vastuvõtja kommentaari väli, et nimekirja vaataja näeks kohe, et vastuvõtt toimub Internetis.
Vastuvõtu lisamise/muutmise vormile tuli lisada abitekst selle kohta, et kui vastuvõtt toimub Internetis, siis peab selle kirjutama kommentaari.

Muutused testides.

Kui need oleksid loodud peaks muutma ka neid.


## Küsimus: Mis asi on register?

**Vastus:**

Andmebaas on nagu päikesesüsteem.

Päikese rollis on organisatsiooni eesmärgid. Kõik mis organisatsioonis IT vallas (sh andmebaasidega) tehakse, peab olema nende eesmärkide teenistuses, mitte vastupidi. Seega planeedid (andmebaasi osad) tiirlevad ümber päikese (organisatsiooni eesmärkide), mitte vastupidi.
Päikese ümber tiirlevad planeedid vastavad põhiobjektidele e põhiolemitüüpidele.
Planeetide ümber tiirlevad omakorda kaaslased e kuud, mis vastavad mitte-põhiobjektidele.
Iga planeet-planeedi kaaslased süsteem vastab andmebaasi äriarhitektuuris ühele registrile. Nii nagu iga kuu tiirutab ümber kindla planeedi on ka iga mitte-põhiobjekt kindla registri tiiva all. Igal planeedil on null või rohkem kuud; igal põhiobjektil on null-või rohkem samasse registrisse kuuluvat mitte-põhiobjekti.
Lisaks planeetidele tiirutavad ümber päikese ka asteroidid. Neist võib andmebaaside analoogias mõelda, kui andmestruktuuridest, mis on vajalikud ühe või teise rakenduse töö hõlbustamiseks, kuid mis ei kuulu ühtegi registrisse (nt disainitaseme abitabelid).
Ümber planeetide (hetkel teadaolevalt ainul Maa, aga hiljem miks mitte ka mõni teine planeet) tiirutavad kunstlikud tehiskaaslased, mis on sinna planeedi asukate poolt saadetud, kuid mingil hetkel planeedile tagasi langevad ja selle käigus ära põlevad. Need on nagu registris olevad ajutiste andmetega andmestruktuurid, mida läheb vaja mingi konkreetse ülesande (nt konkreetse päringu) täitmiseks, kuid mis millalgi oma otstarbe kaotavad ja seega võib eemaldada.
Nii nagu andmebaas või meie arusaam selle ülesehitusest ajas muutub, muutub ka päikesesüsteem (nt planeet püüab gravitatsiooni mõjul kinni mõne pisitaevakeha, mis muutub selle planeedi kuuks) või meie arusaam sellest (nt muutub arusaam sellest, millised taevakehad kuuluvad planeetide hulka).
Nii nagu kunagi kustub päike, nii saab kunagi otsa ka organisatsiooni ja selle IT-süsteemide (sh andmebaasisüsteemi toega andmebaasi) elukaar.


## Küsimus: Mis on intelligentne võti ja millal seda kasutada?

**Vastus:**

Üheks SQL tabelite võtmete liigiks on intelligentsed võtmed. Selliste võtmete väärtused omavad inimkasutajale sisulist tähendust ning võtme väärtusesse on kodeeritud informatsiooni. Sellise võtme näiteks on isikukood.
Näiteks nii Eestis kui Soomes sisaldab see infot sünniaja ja soo kohta. Intelligentse võtme kasutamise väljakutseks on, et kui kodeering muutub, tuleb kõik sellest kodeeringust sõltuvad programmid ümber teha.
Sellise võtme probleeme illustreerib hästi juhtum Rootsist, kus isikukoodid said suure pagulaste tulva tõttu otsa. Kuna ka Eesti isikukoodi osaks on järjekorranumber samal päeval sündinute eristamiseks, siis samasugune probleem võib tabada ka Eestit. Seda näiteks siis, kui e-residentsuse programm osutub ootamatult edukaks, sest ka e-residendid saavad isikukoodi.
Viimaste uudiste kohaselt on Soomes arutusele tulnud kodeeringu muutmine. Põhjus on nii koodide otsalõppemine (vana skeem ei võimalda kõigile isikukoodi vajajatele unikaalset koodi genereerida) kui ka soov sooneutraalsuse järele.
Moraal - koode, mis on "kõrgemalt poolt" (riik, standardiseerimisega tegelev organisatsioon, ettevõtte peakontor jne) ette kirjutatud tuleb kasutada, kuid ise ei peaks selliseid koode leiutama hakata.

## Küsimus: Mis on (lihtsalt selgitades) normaliseerimine ja normaalkujud?

**Vastus:**

Normaliseerimine on nagu mäetipp, mille otsas on auhind. Auhinnaks on see, et andmete liiasust (mis aeglustab ja muudab keerukamaks andmete muutmist) on andmebaasis vähem kui mäe jalamil (aga seda ikkagi on - see pole midagi, millest ühe tipu vallutamisega pääseb). Tipule vastab (SQL-andmebaaside näitel) viies normaalkuju ning mäe nõlval on peatuskohad, mis vastavad erinevatele madalamatele normaalkujudele (sealhulgas ka Boyce/Coddi normaalkuju). Praktikule, keda tulemus huvitab rohkem kui protsess, on lõpuks oluline jõuda tippu. Sinna saab erinevatel viisidel - kas mööda mäekülge üles ronides ja peatuskohtades peatudes (viies tabeleid järk-järgult üha kõrgematele normaalkujudele) või ka lennukist/kopterist langevarjuga hüpates, tipule või selle lähedale maandudes ja GPSiga kontrollides, kas sai tipule pihta või mitte (kas kõik tabelid on viiendal normaalkujul). Hüppamine on nagu mustrite põhjal loodud kvaliteetsest kontseptuaalsest andmemudelist andmebaasi disaini kirjelduse genereerimine.  Lihtsalt öeldes tähendab viies normaalkuju, et tabelit ei saa enam tükeldada väiksemateks ja algse tabeli täpset taastamist võimaldavateks osadeks nii, et tükkides on andmete liiasust vähem. Andmete liiasuse vähendamise mõttes on viies normaalkuju maksimum ja kõige olulisem. On ka kõrgemaid normaalkujusid (nagu kuues), kuid nendeni jõudmisel on juba teised auhinnad (näiteks lihtsam toimetulek puuduvate andmete ja skeemi evolutsiooniga). Enamik tabeleid, mis on kolmandal või Boyce/Coddi normaalkujul (populaarsed peatuskohad mäetipule ronides), on ka viiendal. Selle kohta on sõnastatud ja matemaatilised reeglid.

## Küsimus: Mis on olemitüüp, atribuut ja olem?

**Vastus:**

Kogu selle temaatika juures on suureks probleemiks terminoloogiline segadus. Näiteks erinevate autorite tekstides tähistavad järgnevad sõnad (terminid) sisuliselt sama mõistet.

Klass
Objektitüüp
Olemitüüp
Olem
Põhiobjekt

Näiteks erinevate autorite tekstides tähistavad järgnevad sõnad (terminid) sisuliselt sama mõistet.

Objekt
Objekti eksemplar
Olem
Eksemplar
Olemi eksemplar

Eriti halb on, kui neid sõnu kasutatakse läbisegi.
Näiteks üks räägib olemitest ja olemi eksemplaridest, teine olemitüüpidest ja olemitest, kolmas objektidest ja objekti eksemplaridest, neljas klassidest ja objektidest, kuigi tegelikult mõtlevad nad sama asja.
Samasugune probleem on seostega. Üks räägib seosetüüpidest ja seostest, teine seostest ja seoste eksemplaridest ning kolmas seosetüüpidest ja seoste eksemplaridest, kuigi tegelikult mõtlevad nad sama asja.
Selline terminoloogiline segadus on paraku reaalsus.
Näide, kus üritan seda terminoloogiat järjekindlalt kasutada.
Reaalses maailmas on isik (omaduste e atribuutidega) (meiliaadress, mis ühtlasi eristab seda isikut kõigist teistest isikutest e on tema unikaalne identifikaator=)mari.maasikas2@hot.ee (eesnimi=)Mari (perenimi=)Maasikas.
Reaalses maailmas on isik (omaduste e atribuutidega) (meiliaadress, mis ühtlasi eristab seda isikut kõigist teistest isikutest e on tema unikaalne identifikaator=)juhan.juurikas@hot.ee (eesnimi=)Juhan (perenimi=)Juurikas.
Reaalses maailmas on Mari Maasikas Juhan Juurika ülemuseks.
Nende tähelepanekute alusel sõnastab andmebaasi kavandaja kontseptuaalses andmemudelis vajaduse hoida andmebaasis isikute andmeid (meiliaadress, eesnimi, perenimi ning kes on kelle ülemus). Selleks kirjeldab ta seal olemitüübi Isik, millel on atribuudid e_meil, eesnimi ja perenimi. See vajadus joonistatakse UML keele klassidiagrammi abil loodud olemi-suhte diagrammile üles luues seal klassi Isik ja määrates sellele atribuudid e_meil, eesnimi ja perenimi. Kontseptuaalses andmemudelis ei modelleerita olemeid (Juhan Juurikas või Mari Maasikas), vaid nende üldistust (Isik). Samuti modelleeritakse olemi-suhte diagrammil seosetüüp on ülemus, mille mõlemad otsad on seotud klassiga Isik. Kontseptuaalses andmemudelis ei modelleerita seoseid (Mari Maasikas on Juhan Juurika ülemus), vaid nende üldistust (on ülemus).
Kontseptuaalses andmemudelis sõnastatud nõude rahuldamiseks luuakse SQL-andmebaasis tabel Isik, kus on veerud e_meil, eesnimi ja perenimi + välisvõtme veerg ylemuse_id. Iga rida, mis sellesse tabelisse lisatakse, peab vastama selle tabeli päisele (mis määrab isiku kohta andmebaasis kogutavad andmed). Iga rida on kujutus/peegeldus reaalse maailma olemist (nt reaalsest lihast ja luust Juhan Juurikast). Reaalse maailma olem (nt kindel füüsiline isik) ja tema kujutis süsteemis (nt rida tabelis, JSON dokument või XML dokument) on tegelikult ju kaks ise asja, aga kõnekeeles ollakse sageli lühiduse huvides ebatäpsed ja räägitakse lihtsalt olemitest ja nende andmetest.

## Küsimus: Märkasin et te kirjutate SQL muutujaid eesti keeles, näiteks "nimi VARCHAR(10)". Arvestades et kõik ettevõtted ning arendajad kirjutavad tänapäeval muutujaid ja koodi inglisekeelselt, kas ma võin ka praktikaülesannetes ning iseseisvas töös kasutada inglise keelt?

**Vastus:**

Kui Te mõtlete iseseisvat tööd, siis loomulikult võite koodis kasutada ingliskeelseid nimesid. Töö tegemisel tuleb juurde lisasamm, kus kontseptuaalsest andmemudelist genereeritud tabelite kirjelduses tuleb nimed tõlkida.
Mis puudutab praktikaülesannetes andmete otsimise või muutmise lausete kirjutamist, siis seal on kirjutaja piiratud nimedega, mis on andmebaasis kasutusel. Mis puudutab praktikaülesandeid muuta olemasoleva andmebaasi struktuuri (lisada tabeleid, veerge, kitsendusi), siis kasutada ühes andmebaasis läbisegi erinevaid keeli ei ole ilus ega ka kooskõlas puhta koodi põhimõtetega.
Tahan rõhutada et kõik puhta koodi (sh nimetamise) üldpõhimõtted kehtivad sõltumata kasutatavast inimkeelest. Eesti keel on keel nagu iga teinegi ja sobib asjade nimetamiseks täpselt sama hästi. Seega minu arvates ei ole õigustatud arvamus, et andes asjadele nimesid eesti keeles õpime või teeme midagi valesti.
Olulisemad on põhimõtted (ainsus vs. mitmus, snake_case vs. PascalCase vs. camelCase, regulaarne vs. piiritletud identifikaator), kui see, mis inimkeeles on see nimi kirjutatud.
Aga veelkord - oma iseseisva töö projektis kasutage nimetamise stiili, mida ise paremaks peate. Peaasi, olge järjekindel.Kontseptuaalne andmemudel kirjeldab nõudeid. Nõuded tulevad süsteemi tellijatelt ja kasutajatelt. On täiesti loomulik, et nõuded esitatakse keeles, mis on tellijatele ja kasutajatele hästi arusaadav. Kui kasutate tabelite/veergude/kitsenduste nimetamisel inglise keelt, kuid kontseptuaalses andmemudelis eesti keelt, siis võiks kontseptuaalse andmemudeli olemitüüpide ja atribuutides definnitsioonide juures olemitüüpide ja atribuutide nimed olla nii eesti keeles kui ka sulgudes inglise keeles.

**Märksõnad:** identifikaator, nimi, nimetamine

## Küsimus: Otsin omale põnevat lugemist andmebaaside (pigem relatsiooniliste, aga miks mitte ka teiste) antimustrite kohta. Mäletan Teiega andmebaaside kursust läbides, et erinevate materjalide nimed käisid läbi, aga mõtlesin küsida soovitust otse allikast. Mida võiks lugeda? Soovitatavalt võiks materjal olla inglise keeles (saaks jagada ka mitte-eestlastega), aga endale huvi pärast lugemiseks oleks eestikeelne materjal ka väga kasulik. Soovitused on teretulnud nii veebilinkide, dokumentide kui raamatusoovituste kujul.

**Vastus:**

Antimuster klassikalises mõttes on struktuurse kirjutamise viis, kus lisaks probleemile ja selle halvale lahendusele tuuakse välja ka see, kuidas seda probleemi paremal viisil lahendada ning ka see, millisel juhul võib halb lahendus osutuda väljakannatatavaks. SQL-andmebaaside disaini sagedased probleemid on antimustritena raamatusse kirja pannud Bill Karwin. Tema raamatut saab laenutada ülikooli raamatukogust (https://www.ester.ee/record=b2888667*est), seda saab lugeda O'Reilly digitaalselt platvormilt (https://learning.oreilly.com/library/view/sql-antipatterns/9781680500073/?ar; sellele on Tehnikaülikooli üliõpilastel juurdepääs).
 
Siis on olemas tasuta raamat kus kirjeldatakse 150-t võimalikku disainiprobleemi MS SQL Server andmebaasides: http://assets.red-gate.com/community/books/sql-code-smells.pdf Mõned nendest probleemidest on spetsiifilised MS SQL Serveri jaoks, kuid enamik võib esineda mistahes SQL-andmebaasides. Probleemide kirjeldamisel ei kasutata mustri formaati.Siia on kirja pandud viis viga, mida SQL-andmebaasi disainimisel tuleks üritada vältida: https://www.red-gate.com/simple-talk/databases/sql-server/database-administration-sql-server/five-simple-database-design-errors-you-should-avoid/
 
Mis puudutab NoSQL süsteeme, siis neid iseloomustab standardite puudus (kuid see on näiteks graafiandmebaaside puhul muutumas: https://www.gqlstandards.org/) ja lugemise skeemi eelistamine kirjutamise skeemile (andmete struktuuri ei kirjeldata andmebaasi tasemel ja andmebaasisüsteem ei kontrolli andmete struktuurile vastavust andmete salvestamisel) (kuid ka see on muutumas). Tulemuseks on, et turule jõudnud kümnetes, et mitte öelda sadadest NoSQL süsteemidest tehakse igaühes asju omamoodi ja paljusid süsteeme läbivaid disaini probleeme ei saa / on raske välja tuua. Probleemid ja nende kirjeldused on süsteemi-spetsiifilised. Raamatus "Seven NoSQL Databases in a Week" (Seitse NoSQL süsteemi nädalaga), mida saab O'Reilly keskkonna kaudu lugeda, kirjeldatakse seitset NoSQL andmebaasisüsteemi (https://learning.oreilly.com/library/view/seven-nosql-databases/9781787288867/?ar). Osade süsteemide peatükkides on antimustrite alapeatükk, kus kirjeldatakse lühidalt võimalikke probleeme. Need kirjeldused ei ole mustri formaadis.
 
Sellest raamatust hakkas valusalt silma tekstilõik: "Neo4j involves appropriately modeling the required queries. Relational modeling requires you to focus on how your data is stored, and not as much on how it is queried or returned." See esitab valeväiteid. Relatsiooniline mudel ei kirjuta ette, kuidas andmebaasisüsteemi tarkvara peab sisemiselt andmeid salvestama. See on andmebaasisüsteemide (mudeli realisatsiooni) küsimus. Mudel ja realisatsioon on kaks ise asja nii nagu projekt või tarkvara või plaan ning plaani täitmine on kaks ise asja. Ühes või teises relatsioonilist mudelit realiseerivas süsteemis võib andmete salvestamine olla tehtud nii, et andmete struktuur ja selle muutmine mõjutab ka andmete käitlemise operatsioonide jõudlust. Kuid see on konkreetse süsteemi realisatsiooni, mitte relatsioonilise mudeli probleem. Konkreetseid süsteeme tutvustavate, mitte üldistest põhimõtetest kirjutavate, allikate häda on selles, et need vananevad väga kiiresti ja saadud teadmine kehtib ühes konkreetses kohas - üks süsteem (sageli ainult mõnes selle kindlas versioonis).
 
Leidub päris mitmeid teadusartikleid, kus on uuritud SQL-andmebaaside disainiprobleeme. Need artiklid nimetavad probleeme ja uurivad nende esinemist erinevates andmebaasides, kuid probleeme ei esitata mustri formaadis. Nimetan järgnevalt mõningaid artikleid. Google Scholar (https://scholar.google.com/) kaudu otsides leiab nende artiklite avalikud täistekstid.
 
Blaha, M.: A retrospective on industrial database reverse engineering projects - part 2. In:  Eighth Working Conference on Reverse Engineering, pp. 147–153. IEEE, (2001). https://doi.org/10.1109/WCRE.2001.957818


Vana artikkel 35 SQL-andmebaasi pöördprojekteerimise tulemuste kohta. Nendes oli masendavalt palju puuduvaid kitsendusi. Minu kogemus näitab, et 20 aastat hiljem  pole taolised probleemid andmebaasidest kuhugi kadunud.


 
Blaha, M.R., Premerlani, W.J.: Observed idiosyncracies of relational database designs. In: 2nd Working Conference on Reverse Engineering, pp. 116–125. IEEE, (1995). https://doi.org/10.1109/WCRE.1995.514700


Jällegi vana artikkel, kuid siin nimetatud artiklitest üks kõige suurem hulk erinevaid SQL-andmebaasi disainiprobleeme. Paraku, kuna vigadest õppimine pole kombeks, siis see, et artikkel on vana ei tähenda, et neid vigu uutes andmebaasides ei tehta.


Weber, J.H., Cleve, A., Meurice, L., Ruiz, F.J.B.: Managing technical debt in database schemas of critical software. In: Sixth International Workshop on Managing Technical Debt, pp. 43–46. IEEE (2014). https://doi.org/10.1109/MTD.2014.17


Puuduvatest välisvõtme kitsendustest ja sellest tulenevast tehnilisest võlast.


 
Al-Barak, M., Bahsoon, R.: Database design debts through examining schema evolution. In: 8th International Workshop on Managing Technical Debt, pp. 17–23. IEEE, (2016). https://doi.org/10.1109/MTD.2016.9


Esitatakse üks võimalik SQL-andmebaaside disainiprobleemide liigitus ja nimetatakse neid probleeme.


Delplanque, J., Etien, A., Auverlot, O., Mens, T., Anquetil, N., Ducasse, S.: CodeCritics applied to database schema: Challenges and first results. In: 24th International Conference on Software Analysis, Evolution and Reengineering, pp. 432–436. IEEE, (2017). https://doi.org/10.1109/SANER.2017.7884648


Muuhulgas tutvustatakse SQL-andmebaaside disainiprobleemide otsimiseks mõeldud tarkvara ning nimetatakse 11 probleemi, mida see tarkvara suudab tuvastada.


 
Sharma, T., Fragkoulis, M., Rizou, S., Bruntink, M. and Spinellis, D.: Smelly relations: measuring and understanding database schema quality. In: 40th International Conference on Software Engineering: Software Engineering in Practice, pp. 55–64. ACM, (2018). https://doi.org/10.1145/3183519.3183529


Tutvustatakse SQL-andmebaaside disainiprobleemide otsimiseks mõeldud tarkvara. Nimetatakse 13 probleemi, mida see tarkvara suudab tuvastada. Uuritakse nende probleemide esinemist suures hulgas avatud lähtekoodiga süsteemide andmebaasides ja ka nende probleemide koosesinemist (kui esineb üks probleem, siis millised teised sellega sagedasti koos esinevad).


 
Dintyala, P., Narechania, A., Arulraj, J.: SQLCheck: automated detection and diagnosis of SQL anti-patterns. In: 2020 ACM SIGMOD International Conference on Management of Data, pp. 2331–2345. (2020). https://doi.org/10.1145/3318464.3389754


Muuhulgas tutvustatakse SQL-andmebaaside disainiprobleemide otsimiseks mõeldud tarkvara ning nimetatakse 26 probleemi, mida see tarkvara suudab tuvastada.


Foidl, H., Felderer, M., Biffl, S.: Technical Debt in Data-Intensive Software Systems. In: 45th Euromicro Conference on Software Engineering and Advanced Applications, pp. 338 –341. IEEE, (2019). https://doi.org/10.1109/SEAA.2019.00058


Üks oluline mõte on, et viga ühes süsteemi osas võib tekitada probleeme teistes süsteemi osades. Näiteks puuduvad andmebaasi kitsendused vähendavad andmete kvaliteeti ja muudavad keerukamaks ning veaohtlikumaks andmebaasirakenduste realiseerimise.

Eessaar, E.: Automating detection of occurrences of PostgreSQL database design problems. In: Robal, T., Haav, H.M., Penjam, J., Matulevičius, R. (eds) Databases and Information Systems. DB&IS 2020. Communications in Computer and Information Science, vol 1243. Springer, Cham. (2020) https://doi.org/10.1007/978-3-030-57672-1_14


Tutvustatakse PostgreSQL andmebaasi disaini kontrollimiseks mõeldud päringute kataloogi (https://github.com/erki77/database-design-queries). Suur osa nendest päringutest (problem detection queries) otsivad andmebaasi disaini probleemide esinemisi ja enamik nendest probleemidest ei ole PostgreSQL-spetsiifilised. Seega on ühtlasi tegemist ka disaini vigade kataloogiga ja selles esitatud päringud on nagu käivitatavad vigade spetsifikatsioonid. Võrreldes eelnevate artiklitega on selles kataloogis palju rohkem disaini probleeme.



Balogh, G., Gergely, T., Beszédes, Á., Szarka, A., Fábián, Z.: Capturing expert knowledge to guide data flow and structure analysis of large corporate databases. Acta Polytechnica Hungarica 16(4), 7–26 (2019).

Suurte süsteemide, sh andmebaaside analüüsimine tehniliste puuduste osas on keeruline ettevõtmine. Selleks on vaja toetavat tarkvara. Artikkel kirjutab esimestest sammudest, mis on tehtud reeglipõhise analüüsisüsteemi loomise suunas.

Brass, S., Goldberg, C.: Semantic errors in SQL queries: A quite complete list. Journal of Systems and Software, 79(5), 630-644. (2006). https://doi.org/10.1016/j.jss.2005.06.028

SQL päringute vigade kataloog.


**Märksõnad:** antimuster, anti pattern, muster, pattern

## Küsimus: Teeme projekti töövihiku järgi. Meil on andmebaasis järgmise kontseptuaalse andmemudeli järgi loodud tabelid:

[Treening]-1----------0..*-[Treeningu_kategooria_omamine]-0..*---------1-[Treeningu_kategooria]
[Treening]-1----------0..*-[Treeningu_põhimõttelise_toimumise_asukoht ]-0..*---------1-[Ruum]

Milliste välisvõtmete puhul tuleks kasutada ON DELETE CASCADE ja milliste puhul mitte?

**Vastus:**

Teie andmebaasis on kaks sarnast (mitu-mitmele seost realiseerivat) tabelit.
Treeningu_kategooria_omamine Treeningu_põhimõttelise_toimumise_asukoht
Nendes on kokku neli välisvõtit. ON DELETE CASCADE kasutamise üle otsustamisel tuleks mõelda, milline oleks primaartabelist ühe rea kustutamise mõju sõltuvale tabelile.
Analüüsin ükshaaval kõiki välisvõtmeid mõttega, et nende puhul oleks määratud "ON DELETE CASCADE".
1. Primaartabel: Treening Sõltuv tabel: Treeningu_kategooria_omamine
Kui kustutan rea tabelist Treening, siis kustuvad ainult selle konkreetse treeningu kategooria omamised. Muudatus mõjutab ainult neid, kes kasutavad selle ühe treeningu andmeid. Kustutamine ei sega ega takista teistele treeningutele kategooriate määramist. Võib öelda, et muudatuse mõju on lokaalne. ON DELETE CASCADE toetaks kasutusjuhu Unusta treening läbiviimist.
2. Primaartabel: Treening Sõltuv tabel: Treeningu_põhimõttelise_toimumise_asukoht
Sama, mis esimene.
3. Primaartabel: Ruum Sõltuv tabel: Treeningu_põhimõttelise_toimumise_asukoht
Kui kustutan rea tabelist Ruum, siis mõjutab see kõiki treeninguid, millele see ruum on asukohaks märgitud (võib olla kümneid või isegi sadu). Võibolla mõni treening jääks üldse ilma ruumita. Kui treeningute haldur on treeningule märkinud ruumi ja siis selgub, et seda ruumi polegi tegelikult olemas või see kaob kasutusest, siis korrektne asjaajamine dikteerib, et treeningute haldurit tuleb sellest informeerida ning temaga koos leida lahendus, millist ruumi ikkagi treeningute jaoks kasutada. Äkki tuleb välja, et mõne treeningu läbiviimiseks ei olegi ühtegi sobivat ruumi ja seda treeningut ei saagi läbi viia (treening tuleb lõpetada või unustada). Võib öelda, et muudatuse mõju on globaalne. ON DELETE CASCADE ei peaks kasutama. Selle asemel sobib ON DELETE NO ACTION. Kui süsteemis on kasutusjuht Unusta ruum, siis ON DELETE NO ACTION aitab jõustada reegli, et kasutuses ruume ei saa unustada (andmeid kustutada), vaid need tuleb lõpetada ja vajadusel lõpetatavale ruumile sobiv asendus leida.
4. Primaartabel: Treeningu_kategooria Sõltuv tabel: Treeningu_kategooria_omamine
Kui kustutan rea tabelist Treeningu_kategooria, siis mõjutab see kõiki treeninguid, mis on sellesse kategooriasse määratud (võib olla kümneid või isegi sadu). Võibolla peale seda ei kuulugi enam mõni aktiivne treening ühtegi kategooriasse. See läheb aga vastuollu analüüsi dokumendis seisundidiagrammis väljendatud reegliga, et iga aktiivne treening peab olema seotud vähemalt ühe kategooriaga. Kategooriaid kasutatakse treeningute otsimiseks. Kui treening pole üheski kategoorias, siis ei saa kliendid selle andmeid vaadata (vt kasutusjuhtu Vaata aktiivseid treeninguid). Võib öelda, et muudatuse mõju on globaalne.ON DELETE CASCADE ei peaks kasutama. Selle asemel sobib ON DELETE NO ACTION. Kui süsteemis on kasutusjuht Unusta klassifikaator, siis ON DELETE NO ACTION aitab jõustada reegli, et kasutuses klassifikaatori väärtuseid ei saa unustada (kustutada), vaid need tuleb lõpetada ja vajadusel lõpetatavale väärtusele sobiv asendus leida.

## Küsimus: Teeme töövihiku järgi ning põhiolemiks on hoiuruum. Küsimus: Kas olekudiagrammile oleks loogiline lisada ka "renditud" olek? Mõtlesime selle üle ning tundus, et see viib vastuoluni, et hoiuruum peab olema korraga nii aktiivne kui ka renditud/vaba. (See oleks justkui nagu aktiivse oleku alam-olek). Samas informatsioon selle oleku kohta, kas hoiuruum on välja renditud või vaba on väga vajalik. Kas seda olekut peaks kajastama hoiuruumi seisundi diagrammil või kuskil mujal?

**Vastus:**

Ei ole vaja kajastada. Jah, kontseptuaalselt on "Renditud" oleku "Aktiivne" alamolek. Andmebaasi mõttes saab kindlaks teha, kas hoiuruum on parajasti renditud või mitte selle kaudu, kui teha päring rentimiste registrisse ja veenduda, kas leidub selle hoiuruumi kehtiv rentimine, mille puhul hetke aeg jääb selle rentimise alguse aja ja lõpu aja vahele. Hoiuruum võib olla täna vaba, järgmine kuu renditud, ülejärgmine kuu jälle vaba. Küsimus - mis seisundis ta siis on - vaba või hõivatud.
Praktikas muidugi võiks tahta hoiuruumi lõpetamisel kontrollida, kas sellel on mõni lõpetamata rentimine või mitte. Aga sellisel juhul tuleks projektis ka projekteerida ja realiseerida rentimiste register. Selle tegemine poole keelatud, kuid ei ole ka nõutud.Kokkuvõte:  Seda ei pea seisundidiagrammis kajastama, selle pärast ei pea kasutsjuhtude mudelit muutma ja see jääb käesoleva töö skoobist välja.


**Märksõnad:** seisundidiagramm, olekumasin

## Küsimus: Töövihiku järgi on juba olemas klassifikaator Riik, mis on siis seotud kliendiga seoses isikukoodiga. Kui me soovime lisada klassifikaatori Riik ka Pakettreisile, kas sobib kasutada sama klassifikaatorit või peaksime tegema lisaks Pakettreisi_Riik. Pakettreisi_Riigis ilmselt on vähem võimalikke väärtusi.

**Vastus:**

Mitte ainult ei sobi, vaid see on ainuõige lahendus.
 
Näiteks avaliku teabe seadus ütleb (põhjusega)"§ 43-3.  Andmekogu asutamine(2) Keelatud on asutada ühtede ja samade andmete kogumiseks eraldi andmekogusid."
 
Andmete dubleerimine võib küll mõnikord parandada töökiirust, kuid samas tekitab see andmete muutmise anomaaliaid. Klassifikaatorite dubleerimine samas andmebaasis ei paranda töökiirust, aga andmete muutmise anomaaliad tekivad ikka.

**Märksõnad:** dubleerimine, klassifikaator

## Küsimus: Töövihiku projekti muutes tekkis küsimus, kui suurt rõhku tuleks panna ainsuse/mitmuse kasutamisele X-i asendamisel? Nt. allsüsteemide juures on isikute, töötajate jne allsüsteemid, loogiliselt võttes tuleks seal asendada X mitmuse vormiga, aga kas see oleks korrektne? Läbivalt on kasutusel muidugi (meie projekti puhul) kaup kui ainsuse vorm, kuid mõned kohad tekitavad segadust, kas panna mitmusesse või ainsusesse. Kuidas sellises olukorras tegutseda?

**Vastus:**

Öeldakse, et arvutiteaduses on kaks keerulist asja ja nendest üks on nimede andmine. X ainsuse ja mitmuse vormi valikul on oluline järjekindlus – sama tüüpi elemente (nt allsüsteemid, kasutusjuhud, olemitüübid, tabelid) tuleb nimetada ühes stiilis.
Minu soovitus on kasutada funktsionaalsete allsüsteemide ja registrite nimetamisel mitmuse vormi (nt kaupade funktsionaalne allsüsteem ja kaupade register) ning olemitüüpide ja tabelite nimetamisel ainsuse vormi (nt Kaup). Kasutusjuhtude korral, kui protsess tegeleb korraga ühe eksemplariga (nt ühe kauba lõpetamine), siis kasutage ainsuse vormi (nt kasutusjuht Lõpeta kaup). Kui protsess tegeleb korraga mitme eksemplariga, siis kasutage mitmuse vormi (nt kasutusjuht Vaata kõiki kaupu).


---

# Teema: Korraldus - iseseisev töö

## Küsimus: Kas iseseisva töö ülevaatamisel peavad olema kohal kõik projekti tegijad?

**Vastus:**

Ei pea, kuid teadmiste saamise eesmärgil oleks mõistlik. See ei ole kaitsmine. Õppejõud vaatab koos vähemalt ühe autoriga töö üle ning teeb talle suuliselt teatavaks puudused mis tuleb arvestuse saamiseks kõrvaldada. Need tuleb üles kirjutada. Kui õppejõuga suhtleb ning märkmeid teeb mitu inimest, siis on väiksem võimalus, et midagi jääb kahe silma vahele. Kui kõik on kohal, siis jõuab kõigi osalisteni info vigade kohta kiiremini ja see võimaldab ka kiiremini ja paremini vigu parandada.

## Küsimus: Kas ma peaksin enne iseseisva töö prototüübi tegema hakkamist näitama õppejõule dokumentatsiooni ette?

**Vastus:**

See ei ole kohustuslik, kuid on mõistlik juhul kui olete otsustanud teha töö nullist ja omal teemal, mitte kasutada etteantud malli. Seda saab teha vastuvõtuajal. Kirja teel projekte üle ei vaadata.

## Küsimus: Kas ma võin minna üle ühest iseseisva töö tegijate rühmast teise üle?

**Vastus:**

Liitumine olemasoleva rühmaga (kaks üliõpilast), et nende projekti edasi teha on lubatud kuni kaheksanda õppenädala lõpuni. Peale seda on lubatud projektist eraldumine ja projekti üksinda tegemine, projekti liikme projektist väljaarvamine teiste liikmete poolt ning samuti kahe või kolme üksinda projekti tegija üheks tegijate rühmaks liitumine.
Projekti liikmete muutmisel tuleb arvestada piiranguga, et projektis võib olla kuni kolm liiget. Projekti liikmete hulga muutusest õppejõu teavitamiseks on ainus viis muuta teema registreerimise ülesande vastust Mauruses. Kui seda pole tehtud, siis järelikult pole rühm muutunud.

## Küsimus: Kas ma võin muuta iseseisva töö registreeritud teemat?

**Vastus:**

Jah võib. Sellest mulle teada andmiseks muutke palun Mauruse keskkonnas iseseisva töö teema registreerimise ülesande vastust. Õppejõud näeb kui vastust on muudetud ja saab selle kaudu muudatusest teada.

## Küsimus: Kas ma võin vaadata teiste üliõpilaste projektide kaitsmisi?

**Vastus:**

Jah võite ja see on isegi väga soovitav. Ülevaatused toimuvad MS Teamsis ja need kohtumised on kõigile huvilistele avalikud.
Kui projekt pole veel valmis ja arvestust saanud, siis osalege vähemasti oma tunniplaani järgses praktikumis (loomulikult võite tulla ka mõnda teise tundi!) ja vaadake palun teiste üliõpilaste tehtud tööd. Enamik võimalikest probleemidest on ühised paljudele projektidele. Nii nagu haiguste ennetamine on kasulikum haiguste ravimisest on ka projekteerimise korral palju odavam ja mugavam vigu ennetada, mitte neid tagantjärgi parandada. Hindan, et vähemalt 80% vigadest kordub paljudes projektides.

## Küsimus: Kas me saame töövihiku projekti korral ära kustuta diagrammidelt mentor ja juhendatav seose?

**Vastus:**

Töövihiku valmistehtud osi projektist eemaldada ei tohi. Diagrammilt (nt X registri olemi-suhte diagramm) võite selle kustutada, kuid seda ei tohi kustutada mudelist. Räägin praegu seosetüüpi tähistava joone pildilt eemaldamisest. See seosetüüp peab olema kindlasti nähtav töötajate registri olemi-suhte diagrammil. Andmebaasis tuleb see seosetüüp realiseerida. 

## Küsimus: Kas töövihiku tüüpi projekti korral võib mitu rühma teha projekti samal teemal?

**Vastus:**

Jah võib.

## Küsimus: Kas ühes "Andmebaasid I" aine projekti meeskonnas võivad olla inimesed erinevatest gruppidest?

**Vastus:**

Projekti rühmas võivad olla üliõpilased erinevatest gruppidest, kes käivad erinevatel aegadel praktikumis ja kes võivad ka õppida erinevate õppekavade järgi. Kõikidele üliõpilastele on nõuded projekti osas ühesugused. Kui praktikumis toimub projektiga tegelemine, siis on oluline, et kõik kohalkäinud annaksid oma tunni töö järgmisele tundi tulijale üle.

**Märksõnad:** meeskond, rühm, tiim

## Küsimus: Kuidas esitada iseseisev töö?

**Vastus:**

Iseseisva töö esitamiseks (sõltumata sellest, kas tegemist on lõplikult valmis versiooniga või vaheversiooniga, millele soovite konsultatsiooni käigus tagasisidet) valige õppekeskkonna vasakpoolsest menüüst "Kiirvalik=>Vastamine" ning avanenud leheküljelt ülesanne "Iseseiseva töö esitamine".
Ülesande vastusena saab saata ka faile. Ülesandele esmakordselt vastamine.Vajutage ülesande juures lingile "saada faile". Avanenud aknas on iga küsimuse juures link "Saada fail". Sellele vajutades tekib lehe ülaosas võimalus faili valimiseks. Faili serverile saatmiseks tuleb vajutada nupule "Saada ära".Ülesande vastuse parandamine.Vajutage ülesande juures lingile "paranda/muuda". Avanenud lehel saab kustutada küsimustega seotud faile ja lisada uusi faile.NB! Proovige kontrolli eesmärgil enda üleslaetud faile alla laadida! Kui faili suurus on 0 KB (üleslaadimine ilmselt ebaõnnestus), siis on faili suurus punasega tähistatud.NB! Nupule "Salvesta muutused vastuse tekstis" tuleb vajutada vaid siis, kui lisaks failidele kirjutasite midagi ka küsimuste vastuste lahtritesse.
NB! Iseseisva töö lõpliku versiooni esitamisel peab vastuse saatma üks projekti liige.

## Küsimus: Kuidas registreerida iseseisva töö projekti teema?

**Vastus:**

Tähtajaga 5. veebruar 2021 (kaasa arvatud) tuleb vastata iseseisva töö valikuga seotud küsimustele (st saada selgeks ülesande püstitus, valida teema ja panna kokku tegijate rühm). Seda tuleb nii varakult teha, et saaks alates kolmandast nädalast praktikumides sisukalt ja efektiivselt kaasa töötada.
Iseseisva töö registreerimiseks valige õppekeskkonna vasakpoolsest menüüst "Kiirvalik=>Vastamine" ning avanenud leheküljelt ülesanne "Iseseiseva töö teema registreerimine".
Kui teete iseseisvat tööd rühmatööna, siis peab teema registreerima üks rühma liige (iseseisvat tööd võib teha 1-3 liikmelistes rühmades).
Enne vastamist on kindlasti vaja tutvuda ülesande püstitusega.
Kui teete projekti üksinda, kuid otsite kaaslast, siis on võimalik seda soovi iseseisva töö teema registreerimisel väljendada.

## Küsimus: Kuidas toimub iseseisva töö projektide ülevaatamine?

**Vastus:**

Sõltumata sellest, kas COVID seab ülikooli kohaletulemisele piiranguid või mitte, toimuvad kõik projektide ülevaatamised MS Teams vahendusel.Kõik ettenäitamised on avalikud. See tähendab, et õppejõud vaatab töid oma arvutis ning jagab ekraanipilti MS Teamsis kohtumisel osalejatele. Soovitan tulle vaatama ja kuulama (link kohtumisel osalemiseks tekib MS Teamsis grupi ITI0206-K-2021 kanalisse). Vestluste käigus tulevad kiiresti välja tüüpilised vead ja saate neid oma projekti juures kasvõi kohe parandada, et tulla oma projekti ettenäitamisele parema projektiga.Iseseisva töö ülevaatamise protsessi visuaalset kirjeldust saate vaadata SIIT.

**Märksõnad:** iseseisev töö, projekt, ülevaatus, ülevaatamine, ettenäitamine, kaitsmine

## Küsimus: Kui palju andmebaasioperatsioonide lepinguid peab olema iseseisvas töös laialt kirjeldatud? 
Näidisprojekti kasutujuhtude kirjelduses (punkt 2.1.1) on neid üsna palju, 
kuid operatsioonide lepingute kirjelduses (punkt 2.2.2) neid leidub neid vähem. 
Millised on nõuded selle projekti osa kohta?

**Vastus:**

Operatsioonide lepingud tuleb kirjutada kõigi nende operatsioonide kohta, mis täidavad mõlemat järgnevat tingimust. a) neid vajavad projektis käsitletavad kasutusjuhud, b) nende käigus lisatakse/muudetakse/kustutatakse andmebaasis olevaid andmeid.
Operatsioonide lepinguid ei tule kirjutada operatsioonide kohta, mille käigus ainult ainult loetakse andmebaasis olevaid andmeid.

## Küsimus: Kus on kirjas, millised projekti osad tuleb iseseisvas töös täita?

**Vastus:**

Kevadise iseseiseva töö dokument hõlmab näiteprojektist peatükke 1, 2 ja 5 ning lisaks punkti 3.1. Lisaks tuleb teha projekteeritud süsteemi andmebaasi prototüüp (kogu projekti mahus) ja rakenduse funktsionaalne prototüüp ühe töökoha ulatuses.
See info on ka kirjas kursuse tutvustuses kataloogis "Aine korraldus". Samuti näeb seda kui vaatate iseseisva töö dokumendi malli - kõik pealkirjad, mille alla peab aine projektis midagi kirjutama, on tähistatud punasega.

## Küsimus: Ma ei registreerinud õigel ajal iseseisva töö teemat. Mis nüüd saab?

**Vastus:**

Miinuseid selle eest ei saa. Kuid registreerige esimesel võimalusel oma vastused. Mida hiljem Te hakkate iseseisvat tööd tegema, seda raskem on seda õigeks ajaks valmis saada ja seda väiksema on võimalus saada lisapunkte eksamile.

## Küsimus: Miks tasub iseseisva töö projekti teha rühmatööna?

**Vastus:**

Selleks, et harjutada koostööd ja suhtemist. Artikkel Postimehes (15.02.2018) kirjutab, et IT ettevõtted tunnevad puudust spetsialistidest, kes on koostööaltid ja head suhtlejad.

## Küsimus: Mul ei ole ühtegi kaaslast, kellega koos iseseisva töö projekti koos teha. Ometigi sooviksin kaaslase(id) leida. Mida teha?

**Vastus:**

Variandid (võib kasutada kõiki):

Annate loengu või praktikumi alguses või lõpus oma soovist teistele osalejatele teada.
Annate oma soovist teada õppeaine MS Teamsi rühmas.
Saadate mulle enne projekti registreerimise tähtaega meili, et ma reklaamiksin Teie soovi õppeaine kodulehel.
Iseseisva töö projekti registreerimisel on üks küsimus selle kohta, et kui teete projekti üksinda, siis kas soovite leida kaaslaseid. Kui vastate seal küsimusele jaatavalt, siis reklaamin samuti Teie soovi õppeaine kodulehel.

NB! Kui leiate hiljem projekti tegemiseks kaaslase(d), siis tuleb sellest muudatusest mulle teada anda, muutes iseseisva töö teema registreerimise ülesande vastust. NB! Üksik üliõpilane ei saa liituda kahese projekti rühmaga peale kaheksanda õppenädala lõppu. Kõik muud liikumised rühmade sees ja vahel on lubatud kuni semestri lõpuni.

## Küsimus: Mul on küsimus andmebaaside I projekti kohta. Kas me põhiobjektid, mis alguses töövihikus olid võime muuta ja mõned kustutada, või me peame ainult enda oma põhiobjektid juurde lisada originaalseid puudutamata?

**Vastus:**

Kustutada ei või: Isik, Töötaja, Klient, Klassifikaator, X. Nende olemasoluga arvestatakse järgnevates dokumendi osades. Ülejäänusid võib kustutada, kuid tuleb pidada silmas, et siis tuleb muuta ka teisi punkte alajaotises 1.1​Soovitan kustutamise asemel keskenduda sellele, mida ise lisate. Töövihikusse on kirja pandud asjad, millega üldiselt tuleb peaaegu igas organisatsioonis/infosüsteemis tegeleda.

**Märksõnad:** töövihik

## Küsimus: Tahan SQLi harjutada/lisapunktide ülesandeid lahendada PostgreSQLis või teha projekti PostgreSQL või Oracle andmebaasisüsteemis ning selleks soovin juurdepääsu apex.ttu.ee serverisse. Kuidas seda saada?

**Vastus:**

Täitke palun esimene punkt "Andmebaasid II" kodulehel (kasutajanimi: SIS2, parool: SIS2) olevast ülesandest 1.
Loodavad kontod on individuaalsed, st kui teete iseseisvat tööd rühmatööna, siis iga rühma liige peab küsima eraldi juurdepääsu. Oma kasutajanime ja parooli kellelegi edasi anda ei ole lubatud.
Vaadake ka "Andmebaasid II" kodulehe pealehel olevaid korduvaid küsimusi, sest mitmed nendest on apex.ttu.ee serveri kasutamise kontekstis olulised.PostgreSQL/Oracle kasutamise juhiseid leiate (kasutajanimi: SIS2, parool: SIS2) SIIT ja SIIT.

**Märksõnad:** Postgres, apex


---

# Teema: Korraldus - SQL kontrolltöö

## Küsimus: Kas ka siis peab SQL kontrolltööle registreeruma, kui lisapunktidega on saavutatud lävend, mis annab kontrolltöö hindeks 5?

**Vastus:**

Siis palun ärge registreeruge! Kui olete juba registreerunud, siis palun kustutage oma registreerimine.

**Märksõnad:** kontrolltöö, lisapunktid

## Küsimus: Kas oleks võimalik saada iseseisvaks harjutamiseks mõeldud SQL ülesandeid?

**Vastus:**

Ülesanded on lisamaterjalide lehe (kasutajanimi: SIS2, parool: SIS2) kataloogis AB 1 SQL praktika. Seal on neid palju ning igale maitsele.
Selle kataloogi alamkataloogis SQLi nuputamine on keerukamad ülesanded.
Selle kataloogi alamkataloogis Lahendused on ülesannete (sageli kommenteeritud) vastused.

**Märksõnad:** lisaülesanne, lisaülesanded, ülesanne, harjutusülesanne, harjutusülesanded

## Küsimus: Kui kirjutan kontrolltööd 16 nädalal ja ei õnnestu see mul, kas tohib peale seda teha järel tööd sessiooniajal?

**Vastus:**

Jah, tohite küll. Sessiooni ajal on veel kaks kontrolltöö kirjutamise võimalust (üks sessiooni alguse- ja teine lõpuosas). Nendel aegadel ei lähe lisapunktid enam arvesse.

## Küsimus: Kui kirjutan SQL kontrolltööd esimest korda mingil muul ajal kui aprillis, siis kas on lubatud kasutada A4 lehte abimaterjalina.

**Vastus:**

Üldiselt ei ole lubatud. Abimaterjale saab SQL kontrolltöö kirjutamisel kasutada üks kord aastas - aprillis - kui üliõpilastel on esimene kontrolltööde kirjutamise voor.

Ainus erand on, et kui annate enne 13nda õppenädala kontrolltööd teada, et ei saa sellel osaleda, siis see annab võimaluse kasutada A4 abimaterjalide lehte 16nda nädala järeltööl. Sellest teadaandmise tähtaja leiate kursuse kodulehelt. Teadaandmiseks tuleb ennast registreerida Mauruses õppeaine kodulehel spetsiaalsele teadmiste kontrollile.

## Küsimus: Tahaksin küsida. Kui sel semestril projekt ei jõua teha aga SQL kontrolltöö on tehtud, 
nagu mina sain aru, et projekt on vaja järgmisel kevadel uuesti teha
aga mis saab siis kontroltöö hinnest? Kas kontrolltöö on vaja ka uuesti teha?

**Vastus:**

Kontrolltöö hinne kehtib kuni deklaratsiooni kehtivuse lõpuni. Uuesti deklareerimisel tuleb kontrolltöö uuesti teha.
Projekti arvestus kehtib ka uuesti deklareerides. Hindamisel kasutatav projekti kordaja määratakse kindlaks vastavalt jooksval semestril kehtivatele reeglitele.
SQL kontrolltöö ja eksami lisapunktid kehtivad ainult saamise semestril.
Deklaratsioon kehtib ühe semestri.

## Küsimus: Tahan kirjutada kontrolltööd 16. nädalal. Kas selle saad kirjutada mitte oma grupi praktikumi ajal?

**Vastus:**

Jah. 16. nädalal toimuvadki kontrolltöö järeltööd ainult osade praktikumide ajal. Ülejäänud praktikumides toimub iseseisva töö ettenäitamine.


---

# Teema: Korraldus - üldine

## Küsimus: Kas eksamit saab teha enne eksamisessiooni algust?

**Vastus:**

Kui väga vaja, siis kokkuleppel õppejõuga saab. Eksamieeldused peavad olema eelnevalt täidetud. Kui mõtlete, et see on vajalik selleks, et eksamisessiooni ajal oma lõputööd kaitsta, siis ärge muretsege - lõputööde kaitsmine toimub eksamisessiooni teises pooles ning tehes eduka eksami eksamisessiooni esimesel nädalal jõuate ilusti kaitsmisele.

**Märksõnad:** eksam, eksamisessioon

## Küsimus: Kas eksamit saab teha enne kui kõik eksamieeldused on täidetud?

**Vastus:**

Ei saa. Eksami tegemiseks peavad olema täidetud kõik eksamieeldused:

SQL kontrolltöö tehtud jooksval semestril vähemalt hindele 1,
projekt on arvestatud.


## Küsimus: Kas erinevatel nädalatel võib käia erinevates praktikumides?

**Vastus:**

Jah, erandkorras ning kokkuleppel õppejõuga saab. Arvestades COVIDiga, mistõttu praktikumid on kas MS Teamsis (kus suurele hulgale üliõpilastele on samaaegselt raskem tagasisidet anda kui klassis kohapeal olles) või klassis kohapealt hajutatult, siis palun Teid väga osaleda võimalusel Teie tunniplaanijärgses tunnis.Te ei saa käia IASM rühma praktikumis, sest see on inglise keeles ja need ei kulge eestikeelsete tundidega samas taktis.
Mis puudutab üliõpilasi, kellel ei ole seda ainet tunniplaanis (nt Avatud Ülikooli õppurid), siis elu näitab, et lõpptulemusena võib olla mõnes praktikumis hästi palju osalejaid ja õppejõul jagub sedavõrra osalistele vähem aega aga mõnes teises praktikumis (eriti reedeti) on aga väga vähe osalejaid ja samavõrra on õppejõul igale osaleja jaoks rohkem aega. Seega tasub alates teises õppenädalast õppejõult uurida, millised on ajad, kus tunnis käijaid on vähe ning käia selles tunnis - et õppimine läheks võimalikult libedalt ja ainest oleks võimalikult palju kasu.

## Küsimus: Kas tehes eksamit eksamisessiooni viimasel eksami tegemise ajal on veel võimalik seda parandada?

**Vastus:**

Kui teete eksamit eksamisessiooni viimasel päeval, siis saate vajadusel ikkagi teha eksamit 2+1 korda (kui teete põhieksamit) või 1+1 korda (kui teete lisaeksamit). Kuid kõik need eksami tegemised toimuvad samal päeval ja samas kohas, üksteise järgi (olen selleks aeg varunud).

## Küsimus: Kuidas arvestatakse lisapunkte?

**Vastus:**

SQL lisapunktid lähevad arvesse SQL kontrolltöös (13. õppenädalal) ja esimeses järeltöös (16. õppenädalal). Näiteks ilma lisapunktideta on SQL töö 65 punkti ja 2, kuid koos 7 lisapunktiga 72 punkti ja 3. Lisaks sellele määran üheteistkümnenda õppenädala lõpus lisapunktide lävendi, mille ületamisel saab üliõpilane SQL kontrolltöö hinde automaatselt 5. Kõik üle lävendi olevad punktid lähevad eksami lisapunktideks. Seega, kui üliõpilasel on näiteks 5 punkti üle lävendi, siis ta saab eksamile 5 punkti juurde.
Kahe vahetesti tulemused lähevad samuti eksamile lisapunktideks. Näiteks ilma lisapunktideta on eksam 68 punkti ja 2 (17 õiget vastust 25-st), kuid koos 10 lisapunktiga on eksam 78 punkti ja 3. Eksami lisapunktid lähevad arvesse kõigil semestri jooksul tehtud eksami sooritustel.

**Märksõnad:** punktid, lisapunkt, SQL kontrolltöö, test, eksam, hinne, lävend

## Küsimus: Kuidas kujuneb hinne? Milline mõju on lisapunktidel ja projektil?

**Vastus:**

Üks koht, kust seda kiiresti vaadata on aine korralduse kirjelduses. Hindamise põhimõtted on rasvase ja suure fondiga esile tõstetud.

## Küsimus: Kuidas see aine reageerib COVID-19st tingitud olukorrale?

**Vastus:**

Tervis on kõige kallim vara. Teadmised ja oskused on ka väga olulised. Seega üritame kasvatada teist ja samal ajal hoida esimest. Kui olete haiguskahtlusega või haige, siis püsige kodus. Õppeaine korraldus arvestab sellega.MS Teamsis õppeaine selle semestri rühmaga liitumiseks vajalikku võtit jagan ÕISi kaudu saadetud teates ning see on ka aine korralduse materjalides.Plaanid semestriks on järgmised.

Loenguid saab vaadata otseülekandena ja need ka lindistatakse. Kui kohapealne õppetöö ülikoolis mingis osas taastub, siis pole keelatud käia loengus kohal, sest auditoorium on suur ning seal saab hajutatult istuda, aga see ei ole kohustuslik.

Olen loengu ajal ka MS Teamsis ning vastan sealtkaudu tulnud küsimustele.


Nädalad 1-12: senikaua kuni ülikool ei ole läinud rohelisele ohutasemele (arvutiklassides saab piiranguteta koguneda ja ei ole inimeste hajutamise nõuet) toimuvad kõik selle perioodi praktikumid kasutades MS Teamsi. Paraku on aines nii palju üliõpilasi, et 50% klasside täituvuse nõuet arvestades ei saa arvutiklassis tunde pidada.

MS Teamsis toimuvate praktikumide korral võin kuid ei pruugi ma olla arvutiklassis - seega ärge füüsiliselt kohale tulge (isegi siis, kui ülikoolis üldiselt on kohapealne õppetöö lubatud kuni 50%-se klassi täituvusega).
Kui läheb hästi, COVID taandub ning ülikool jõuab rohelisele ohutasemele, siis läheme operatiivselt tagasi kontaktõppele. Info selle kohta tuleb kodulehe kaudu jooksvalt.
Kui neljandal või kaheksandal õppenädalal on siin aines endiselt kaugtöö, siis vahetestid toimuvad üle Interneti.
Kui ülikoolis taastub osaliselt kohapealne õppetöö ja soovite mingi tarkvara (nt CASE vahendi kasutamiseks) tulla arvutiklassi, siis seda muidugi saab, kuid eelnevalt peaks õppejõuga selle kokku leppima (võib juhtuda, et mõnda praktikumi ei vii ma läbi arvutiklassist).


Praktikumid on igal juhul MS Teamsis aktiivsed ja nendel nädalatel, kus seal ise pikemalt räägin, üritan ühte lindistada.
Kui olud seda vähegi võimaldavad (ülikoolis kogunemine on lubatud), siis SQL kontrolltöö (13ndal õppenädalal), SQL kontrolltöö järeltööd (16ndal õppenädalal ja eksamisessiooni ajal) ning eksam toimuvad ülikooli arvutiklassides kohapeal. Loomulikult arvestatakse sellel ajal kehtivate inimeste hajutamise reeglitega (nt kollase ohutaseme puhul võib ruumi täituvus olla maksimaalselt 50%).

Tulles arvutiklassi kontrolltööd või eksamit tegema on lubatud kasutada oma arvutit.
Kui olete haiguskahtlusega või haige, siis saab kontrolltöö tegemist edasi lükata või eksamisessiooni lõpus teha üle interneti (vajalik kokkulepe õppejõuga).
Kui olete haiguskahtlusega või haige ja eksamisessiooni lõpp on käes, siis saab teha eksamit ilma arvutiklassi kohale tulemata (vajalik kokkulepe õppejõuga).


Projektide ülevaatamine (praktikumides 13-16 nädal) ja vastuvõtud toimuvad kasutades MS Teamsi.

Sellise üle Interneti õppe puhul põhineb palju usaldusel. Palun ärge kuritarvitage seda! Kõik SQL ülesanded ja vahetestid on mõeldud individuaalseks lahendamiseks. Vahetestidel ei tohi kasutada abimaterjale.Kui kogu semestri peaks olema kaugõpe, siis aine korralduses, tähtaegades, nõuetes jms ei muutu mitte midagi.Kes soovib, saab SIIT alla laadida Teams töölauarakenduse.
Teams'i töölauarakendus on olemas ka Linuxile nagu kirjutatakse SIIN.
Sisselogimiseks tuleb kasutada ülikooli Uni-ID'd. Kasutajanimi on Teie @ttu.ee domeeniga ülikooli meiliaadress.
Jäägem (testi mõttes) negatiivseks ja samas olgem (meeleolu mõttes) positiivsed!

## Küsimus: Kuidas toimub SQL lisapunkti ülesannete lahendamine perioodil kui praktikumid toimuvad MS Teamsi vahendusel?

**Vastus:**

Tunnis osalejad peavad liituma tunniga MS Teamsis (siin on viit õppeaine selle semestri rühmale MS Teamsis). Palun sisselülitada veebikaamera.Tunni alguses jagan ekraani ja lahendan läbi mõned SQL ülesanded. Siis teen õppeaine kodulehel nähtavaks tunni ülesande.Igaüks peab lahendama ülesandeid iseseisvalt. Kui saate midagi valmis või tahate küsida, siis tuleb SQL kood saata õppejõule MS Teamsi privaatses vestluses (chat), mitte tunni vestluses. Õppejõud võib vastata vestluses või ka läbi mikrofoni nii, et kõik kuulevad. Teise nädala ülesannete 3-7 vastuste ettenäitamiseks tuleb üliõpilasel jagada ekraani.

## Küsimus: Kuidas toimub vahetestide tegemine kui praktikumid toimuvad MS Teamsi vahendusel?

**Vastus:**

Testil osaleda soovijad peavad eelnevalt Mauruses osalemise registreerima ("Kiirvalik=>Teadmiste kontrollile registreerumine"; registreerimine avatakse enne testi ja sellest teatakse õppekeskkonna vahendusel). Kes pole registreeritud, see testi teha ei saa.Enne testi algus peab testi tegija liituma tunniga MS Teamsis (siin on viit õppeaine selle semestri rühmale MS Teamsis). Veebikaamera tuleb sisse lülitada. Kõigepealt kontrollib õppejõud kohalolu ja avab siis testi. Kes MS Teamsis kohal ei ole, see testi teha ei saa.

## Küsimus: Kuidas valmistuda õppeaines toimuvateks testideks (vahetestid ja lõpptest)?

**Vastus:**

Kordamisküsimused leiab SELLEST DOKUMENDIST (kataloog Teooria).
Testide tegemine toimub veebipõhise keskkonna kaudu, kuhu Teie konto luuakse õppejõu poolt peale seda, kui olete Mauruses õppeaine kodulehel registreerinud.
NB! Süsteemis on olemas testideks harjutamise funktsionaalsus.
Harjutamiseks minge lehele https://maurus.ttu.ee/testimine/valik_harjuta.php. Õppeaines toimud kaks vabatahtliku vahetesti auditoorse õppetöö perioodil ning kohustuslik lõpptest (eksam) eksamisessiooni ajal. Kõikide nende jaoks saab selles keskkonnas harjutada.
Lisaks saab harjutada SQLi. SQLi valikvastustega testi hindamiseks ei toimu, kuid SQLi kohta toimub ülesannete lahendamisega kontrolltöö ning kõik selles testis esitatavad küsimused võivad tulla ka lõpptesti - seega võib olla huvi seda testi SQLi õppimiseks teha.
Millal on mingi test harjutamiseks avatud on kirjas õppeaine kodulehe ajakavas ning perioodi algusest teavitatakse ka eraldi meili teel.
Järgnevalt loetlen harjutuskeskkonna mõned olulised põhimõtted.

Sisselogimiseks on Mauruse kasutajanimi ja parool.
Harjutamiseks võib olla avatud rohkem kui üks test - pöörake palun tähelepanu, mida valite.
Testi omadused (vastamiseks ettenähtud aeg; küsimuste arv; küsimuste hulk, millest testiküsimused valitakse; küsimuste valiku põhimõtted) on samasugused nagu vastaval hinnataval testil.
Iga testi tegemisel genereerib süsteem uue küsimustiku.
Tehtavate testide arv ei ole piiratud.
Süsteemi kuritarvitamisel, et selle abil küsimusi välja pumbata (skripti kasutamine vastamiseks; küsimustiku korduv genereerimine ilma vastamiseta), blokeeritakse vastaja juurdepääs sellele testile ilma eelhoiatuseta ning jäädavalt.
Iga valitava testi juures on näha ajahetk, milleni on test harjutamiseks valitud.
Tulemused salvestatakse ja õppejõud näeb tulemusi.
Salvestamise järel näeb vastaja õigete vastuste arvu, hinnangut vastustele ja iga küsimuse korral ka seda, kas küsimusele vastati õigesti või valesti.

Iga testi puhul on määratud, kui mitmel korral päevas näeb vastaja, juhul kui ta vastas küsimusele valesti (kuid ei jätnud vastamata), ka õiget vastust. Teste võib muidugi päevas teha rohkem kui on kordi, millal näeb õigeid vastuseid.


Õigeid/valesid vastuseid näeb ainult salvestamise järel, kuid mitte hiljem. Harjutamise testide tulemusi näeb hiljem ka siit.
Tulemusi ei võeta õppeaine hindamisel MITTE MINGIL VIISIL arvesse (st võite julgelt harjutada ja ka eksida).


## Küsimus: Kui praktikumis ei jõudnud kõiki või ühtegi lisapunktide ülesannet ära lahendada, kas on võimalik samal nädalal ka mõnes teises praktikumis veel lisapunktide ülesandeid lahendada?

**Vastus:**

Põhiülesannete eest võib nädala jooksul punkte saada maksimaalselt üks kord. Nuputamisülesannete (praktikumi ülesannete failides joone all) eest võib punkte saada nädalas rohkem kui ühel korral. Seega:

kui käisite tunnis ja ühegi põhiülesande eest punkti ei saanud, siis võite tulla mõnda teise sama nädala praktikumi, et veelkord proovida põhiülesandeid lahendada (eeldusel, et seal ruumi jagub),
kui käisite tunnis ja saite vähemalt ühe põhiülesande eest punkti, siis samal nädalal uuesti tundi tulles saate lahendada nuputamisülesandeid.


## Küsimus: Milline on vääritu käitumine antud aine kontekstis?

**Vastus:**

Infotehnoloogia teaduskonnas kehtib õppuri akadeemiliste tavade rikkumise ja vääritu käitumise menetlemise kord (dokument 09). Selles dokumendis määratakse ära, milliseid õppuri poolseid tegevusi loetakse akadeemiliselt väärituks käitumiseks ning millised on tegevused ja võimalikud ametlikud tagajärjed õppuri jaoks (noomitus, eksmatrikuleerimine) kui ta millegi sellisega hakkama saab.
Palun Teilt järgnevat.

Palun ärge jagage enda tehtud projekte teiste üliõpilastega.
Palun ärge tehke kellegi teise eest tema tööd ära.
Palun ärge taluge projekti rühmas liikmeid, kes teistega võrdselt töösse ei panusta.

Sellega teete tegelikult neile palju halba, sest nad ei õpi midagi!!! Veel enam, Te teete kahju endale, sest teadmisteta/oskusteta lõpetajad kahjustavad tööandjate silmis kõigi diplomisaajate mainet.
Kui mõni projekti kaaslane ei panusta piisavalt, siis arvake ta palun oma projektist välja ja teavitage sellest (nt õppekeskkonna kaudu) õppejõudu.

## Küsimus: Millises järjekorras ja millisel viisil soovitate aine õppimist alustada? Millele kõigepealt tähelepanu pöörata?

**Vastus:**

Soovitan alustada sellest, et jälgite pealehele ilmuvaid kuupäevi ja üritate täita nendega seotud ülesanded. Pealehel näidatakse lähenevaid tähtaegu. Kõiki kuupäevi saab vaadata aine tutvustuse alt.
Kuluva aja ja üliõpilaste tagasisiside järgi vaadates on õppeaine kõige raskem osa iseseisava töö projekt. On väga oluline, et teeksite selle tegemiseks head valikud (üksi või kaaslastega; kui kaaslastega, siis kellega; mis viisil teha (töövihik vs. omalooming), mis teemal teha, mis vahendeid kasutada) ja kui tuleb välja, et need ei olnud ikkagi head valikud, siis korrigeeriksite neid kiiresti. See on nagu süsteemiarendusega - mida hiljem viga avastada, seda kulukam on seda parandada. Leidke palun aega, et ülesande püstitus korralikult läbi lugeda ja valida meeldiv ja jõukohane teema. Selle arvelt kokku hoitud viis minutit võib hiljem valusalt kätte maksta. Töö tegemist nõuab iseseisev töö igal juhul, aga mõni teema/tegemise viisi korral kindlasti rohkem kui mõne teise korral.
Soovitan iseseisva töö kiireks ja edukaks sooritamiseks sellega iga nädal kasvõi natukenegi tegeleda. Praktikumide ajakavas on kirjas, mis võiks olla iseseisva töö osas tehtud viienda õppenädala lõpuks. Kui teete projekti rühmas, siis kasutage palun maksimaalselt paralleeltöö võimalust, et sama ajaga rohkem tehtud saada. Selles mõttes pole üldse paha mõte (pole muidugi kohustuslik), et 3-5 õppenädalal osaleksid sama projekti tegijad erinevates praktikumides 3*3*1.5 tundi projekti tegemist on kindlasti parem kui 3*1.5 tundi projekti tegemist. Siis tuleb muidugi oma tunnitöö järgmisena tundi tulijale edasi anda.


---

# Teema: Küsimused seoses jätkuainega ("Andmebaasid II")

## Küsimus: Arvestades sellega, et "Andmebaasid II" aines tuleb seda projekti edasi teha, siis millised oleksid soovitused "Andmebaasid I" projekti jaoks andmebaasisüsteemi valimisel?

**Vastus:**

Jätkuaines "Andmebaasid II" peate Te valima ühe serveri andmebaasisüsteemi, mille põhjal oma projekti edasi teha. Süsteemid, mille hulgast valik teha, on rangelt ette antud - PostgreSQL ja Oracle (ei näe põhjust seda valikut lähitulevikus muuta, sest tegu on väga heade süsteemidega). Projektis tuleb valitud serveri andmebaasisüsteemi abil realiseerida andmebaas ning samuti realiseerida seda andmebaasi kasutav rakendus valitud allsüsteemi ühe töökoha piires. Rakenduse tegemise vahendi valik on vaba, kuid tulemust peab olema muidugi võimalik mulle demonstreerida.
Eelnevast tulenevalt soovitan kevadise projekti tegemiseks kasutada kas:

MS Access
PostgreSQL
Oracle

Kui kasutate MS Accessi, siis on Teil võimalik sügisel töötada MS Accessis tehtud rakendus ümber nii, et see hakkab ODBC andmeühenduse tehnoloogia vahendusel kasutama PostgreSQL andmebaasi. Kui kasutate MS Accessi ja plaanite ka sügisel projekti rakenduse osa MS Accessis teha, siis valige kevadises projektis realiseerimiseks töökoht, mis võiks ka reaalses elus kasutada kahekihilist klient-server süsteemi, kus rakendus on kliendi arvutis. Seega ei sobi MS Accessis realiseerimiseks kõikvõimalikud "kliendi" töökohad, mis kindlasti peavad olema tehtud veebirakendusena.
Kui teete oma kevadise projekti PostgreSQLis või Oracles, siis saate sügisel tehtud serveri andmebaasi edasi arendada. Kindlasti on sügisel disaini parandamisega omajagu tööd, kuid kevadel saadud kogemus võib tööd lihtsamaks muuta.
Huvilistele saan juba kevadel anda juurdepääsu serverile apex.ttu.ee, kus on PostgreSQL (13) ja Oracle (12c Enterprise Edition, Release 1). Kuna seal serveris on andmebaaside disaini automaatkontrollimise vahendid, siis palun PostgreSQLis või Oracles tehtud "Andmebaasid I" projekti andmebaas sinna enne ettenäitamist üles panna.

**Märksõnad:** Postgres, MSAccess

## Küsimus: Kas aines "Andmebaasid I" tehtava projekti rühm peab jääma samaks jätkuaine "Andmebaasid II" raames?

**Vastus:**

Ei pea.

## Küsimus: Kas sügisel saab teha "Andmebaasid II" õppeainet, kui "Andmebaasid I" jäi kevadel tegemata?

**Vastus:**

Võite sügisel deklareerida "Andmebaasid II", kui "Andmebaasid I" on tegemata. Muidugi hoiatan, et üks on teisele sisuline eeldus ja kui eeldusaine pole selgeks saanud, siis on jätkuaine kindlasti selle võrra raskem.
"Andmebaasid II" õppeaines arendatakse edasi "Andmebaasid I" projekti. Pakun välja kolm "Andmebaasid I" projekti, mille hulgast saavad üliõpilased, kellel on eeldusaine tegemata, valida projekti, mida sügisel edasi arendada. Nii saavad üliõpilased "Andmebaasid II" projekti tegemisega kohe septembri alguses pihta hakata. Teine võimalus on, et liitute sügiseks mõne rühmaga, kus "Andmebaasid I" projekt on tehtud. Nii nagu kevadel on ka sügiseses projektis lubatud osalejate arv 1-3 üliõpilast.
"Andmebaasid I" projekti sügisel kaitsta ei saa. Seda saab teha järgmisel kevadel. Siis saate ka teenida varase esitamisega seotud soodustuse (suur kordaja väärtus). Selles mõttes pole paha mõte sügisel "Andmebaasid I" projekt ikkagi ära teha, et siis kohe järgmise aasta veebruaris/märtsis see ette näidata. Te ei pea valima uut "Andmebaasid I" projekti teemat. Piirang millega tuleb arvestada "Andmebaasid II" projekti teema valimisel on, et eelnevalt kirjeldatud viisidel projekti tehes ei tohi "Andmebaasid I" ja "Andmebaasid II" projekti teemad kokku langeda.
Sellel semestril kogutud lisapunktid "Andmebaasid I" uuesti deklareerides arvesse ei lähe, kuid saate neid koos ülejäänud üliõpilastega järgmisel kevadel uuesti koguda. SQL kontrolltöö tuleb õppeainet uuesti deklareerides uuesti teha ning lävend ületada.
Kui saite projekti kevadel tehtud, siis saate sellega sügisel jätkata. Õppeaine uuesti deklareerimisel ei ole vaja projekti uuesti teha. Projekti kordaja leitakse uuesti deklareerimise semestril kehtivate reeglite kohaselt.

## Küsimus: Kui nt üks liige peab ajateenistuse tõttu aasta vahele jätma, kas siis seda projekti võivad erinevad rühma liikmed erinevatel aastatel edasi teha "Andmebaasid II" aine raames, st kaks liiget selle aasta sügisel ja kolmas liige eraldi üksi järgmise aasta sügisel? Kas selline olukord on üldse võimalik või tuleks siis "Andmebaasid I" projekt üksi teha?

**Vastus:**

Kõigepealt tuleb muidugi öelda, et me keegi ei tea täpselt ette, mis juhtub mitme aasta pärast ning elu võib igasugustes nõuetes ja plaanides teha korrektiive. Järgnev on minu käesoleva hetke vaade ning praegu pole mul plaani selles vaates muudatusi teha.
Jätkuaines "Andmebaasid II" peate Te valima ühe serveri andmebaasisüsteemi, mille põhjal oma ("Andmebaasid I") projekti edasi teha. Süsteemid, mille hulgast valik teha, on rangelt ette antud - PostgreSQL ja Oracle (ei näe põhjust seda valikut lähitulevikus muuta, sest tegu on väga heade süsteemidega). Eeldusel, et lähteprojektis kasutati teist andmebaasisüsteemi, on sisuliselt tegemist süsteemi migreerimise projektiga ühelt platvormilt teisele koos koodi puhastamisega ja selleks vajaliku refaktoreerimisega. Ainus lisaks realiseerimist vajav funktsionaalsus on kasutaja tuvastamine.
Projektis tuleb valitud serveri andmebaasisüsteemi abil realiseerida andmebaas ning samuti realiseerida seda andmebaasi kasutav rakendus valitud allsüsteemi ühe töökoha piires. Rakenduse tegemise vahendi valik on vaba, kuid tulemust peab olema muidugi võimalik mulle demonstreerida. Ka sügisese aine projekti saab teha 1-3 üliõpilast. Nagu kevadel, ei sõltu ka sügisese aine projekti maht/nõuded/tähtajad tegijate arvust.
Millised oleksid Teie kaaslase valikud järgmise aasta sügisel, eeldusel, et teete "Andmebaasid I" projekti mitmekesi? 1. Kaaslane teeb edasi kevadel alustatud ja arvestuse saanud projekti, kuid kasutab sügisese projekti tegemiseks teist andmebaasisüsteemi kui Teie sügisel kasutasite.
Toon näite. Oletame, et töö teemaks on "e-poe infosüsteemi kaupade arvestus". Sellel sügisel realiseerib üks grupp selle kasutades Oracle andmebaasisüsteemi. Järgmisel sügisel realiseerib teine grupp selle kasutades PostgreSQL andmebaasisüsteemi. Vahendite valikus võiks muidugi omavahel aegsasti kokku leppida.
2. Kaaslane leiab järgmisel sügisel projekti, millesse ta läheb teiseks või kolmandaks liikmeks.
3. Kaaslane valib projekti tegemiseks ühe selleks otstarbeks "Andmebaasid II" kodulehele välja pandud (mõnede teiste üliõpilaste tehtud) "Andmebaasid I" projekti.


---

# Teema: Loengud

## Küsimus: Kas loengute ja praktikumide lindistusi saab vaadata ilma internetiühenduseta (offlain)?

**Vastus:**

Echo keskkonnast saab loengute videofaile alla laadida. Kui lähete kursuse Echo lehele (valige Kiirvalik => Loengute lindistus) ja klõpsate lindistuse juures noolega ikoonil, siis avaneb hüpikmenüü, kust saab valida Download Original.
 
Mis puudutab MS Stream keskkonda, siis seal saab videot alla laadida selle omanik või üleslaadija.
https://docs.microsoft.com/en-us/stream/portal-download-video
 
Videote allalaadimise võimalus on funktsionaalsus, mida kasutajad on soovinud, kuid mida pole veel realiseeritud.
https://techcommunity.microsoft.com/t5/office-365/when-will-non-owners-be-able-to-download-videos-from-microsoft/m-p/139114

## Küsimus: Millele oleks eriti oluline andmebaaside õppimisel tähelepanu pöörata?

**Vastus:**

Kui maailmas on üldse midagi kindlat, siis see, et kõik on pidevas muutumises. Kui loote infosüsteemi ja selle andmebaasi, siis tuleb neid ajaga kaasaskäimiseks pidevalt kohandada. Hoolduskulud võivad lõpuks moodustada kuni 80% süsteemi kogukuludest. Selles kontekstis on väga oluline andmebaasi hallatavus.
Artiklis: Riaz, M., Tempero, E., Sulayman, M., & Mendes, E. (2013). Maintainability Predictors For Relational Database-Driven Software Applications: Extended Results From A Survey. International Journal of Software Engineering and Knowledge Engineering, 23(04), 507-522.
esitatakse 40 tarkvaraarenduse spetsialisti hulgas läbiviidud küsitluse tulemused. Selle küsitlusega sooviti teada saada, millised tegevused aitavad parandada SQL-andmebaasil põhinevate andmebaasirakenduste hallatavust. Vastusele lisatud failis tuuakse välja kõik sellised aspektid, millel on küsitlusele vastanute arvates mõõdukas või suur positiivne mõju hallatavusele. See fail esitab artiklis esitatud diagrammi.

## Küsimus: Mul ei õnnestu vaadata loengute lindistusi, sest saan videote vaatamisel veateate.

ERROR:Unable to process language file located at: language/ru.xml
The file is either missing or corrupt.

**Vastus:**

Ilmselt on probleem selles, et veebilehitseja on vene keelne. Lahendus oleks kasutada inglise keelset veebilehitseja. Ehk siis peaksite ära muutma keele sätted.
GoogleChromes saaks korda kui võtta Настройка и управление Google Chrome Настройки ->Показать дополнительные настройки -> Языки ->Настройка языков и способов ввода ja võtate kasutusse inglise keele (англиский (США)).

## Küsimus: Mul on veidi vaba aega ja tahaks kuulata audio- või videoloenguid. Kas oskate soovitada midagi andmebaaside kohta?

**Vastus:**

Kursus andmebaasisüsteemide kohta Carnegie Mellon ülikoolis. "Andmebaasid I" kursuse temaatika alla lähevad esimesed viis loengut. https://www.youtube.com/playlist?list=PLSE8ODhjZXjYutVzTeAds8xUt1rcmyT7x

01 Course introduction & Relational Data Model (Fall 2017) - täiendus teemale 2
02 Relational Algebra (Fall 2017) - täiendus teemale 3
03 Advanced SQL (Fall 2017) - täiendus teemadele 4, 5
04 Functional Dependencies (Fall 2017) - täiendus teemale 9
05 Normal Forms (Fall 2017) - täiendus teemale 9

Carnegie Mellon ülikoolis on andmebaaside teadusgrupp. Nende Youtube lehel leidub päris palju loenguid tehnilisemate (edasijõudnute) teemade kohta. Osasid nendest teemadest käsitleb ka sügisene "Andmebaasid II" õppeaine. https://www.youtube.com/channel/UCHnBsf2rH-K7pn09rb3qvkA
Relatsioonilised andmebaasid: https://www.youtube.com/watch?v=qx0F7TfA8CI https://www.youtube.com/watch?v=kSZX3fBgg1A&index=5&list=PLWIxuiyTh_yY3w26sJMbdTDXuEYJp-GxT (puuduvate andmetega toimetulek. SQLis on selleks üks väga veider omamoodi elukas NULL - sellest ka loengu nimi)
Esimene on küll väga lühike video, kuid lektoriks mõlemal on C.J.Date, kellel minu arvates on väga hea selgitamisoskus.
NoSQL süsteemid ja suurandmed: https://www.youtube.com/watch?v=qI_g07C_Q5I (hea kõrgtaseme ülevaade; lektorist) https://www.youtube.com/watch?v=S79-buNhdhI (lektorist)


---

# Teema: SQL

## Küsimus: Kas olemasse tabelisse T ridade lisamiseks võib MS Accessis kasutada SELECT ... INTO T FROM ... lauset?

**Vastus:**

Ei! See oleks ränk viga. SELECT ... INTO T … põhjustab MS Accessis tabeli T kustutamise ja uuesti loomise. Uues tabelis T on:

kaotsi läinud kõik seal varem olnud andmed,
tabeliga seotud kitsendused,
tabeliga seotud indeksid.

Loodud tabelis on andmetüübid ja maksimaalsed lubatud andmete suurused valitud vastavalt päringus viidatud tabelite andmetüüpidele ja väljapikkustele.Andmete lisamiseks tabelisse (olgu selles andmeid või mitte) tuleb kasutada INSERT lauset.NB! SQL standardis ja paljudes teistes SQL-andmebaasisüsteemides on sarnaseks koopia loomiseks kasutusel CREATE TABLE ... AS ... lause. Kui üritate sellega luua tabelit T ja tabel T on juba andmebaasis vastavas skeemis olemas, siis lause täitmine ebaõnnestub (mitte ei kirjutata tabelit üle nagu MS Access seda teeb). Sama juhtub ka siis kui kasutada SELECT ... INTO lauset MS SQL Server andmebaasisüsteemis.

**Märksõnad:** MS Access, MSAccess

## Küsimus: Kuidas Mauruse otsing täpsemalt töötab? Millist tuge pakkus selle realiseerimiseks andmebaasisüsteem, mida Maurus kasutab?

**Vastus:**

Mauruse kasutajad soovisid sageli, et seal oleks otsingu funktsionaalsus. Lisasin Maurusesse selle funktsionaalsuse. Otsing on võimalik kodulehe piires. Leiate võimaluse seda teha iga aine kodulehe paremast ülaservast. Otsing toimub üle aine sisu kirjelduse, materjalide metaandmete, tegevuskava, teadete (v.a isiklikud teated), kasutajatoe küsimuste/vastuste, viidete, tähaegade, ülesannete (kuid mitte nende vastused) ja vastuvõtuaegade. Otsingu tulemused on ühel lehel nende kategooriate kaupa grupeerituna. Materjale, teateid ja kasutajatoe küsimusi/vastuseid on otsingu tulemuses igaühte kuni 10. Viiteid on tulemuses kuni 20. Materjalide puhul ei toimu otsing mitte failide sisu, vaid materjale kirjeldavate andmete (metaandmete) põhjal.
Kuna Maurus kasutab PostgreSQL andmebaasisüsteemi, siis tegi PostgreSQLi pakutav täisteksti otsingu funktsionaalsus selle funktsionaalsuse realiseerimise lihtsamaks.
Järgnevalt esitan koodinäite.
Näiteks oletame, et tahan lisada teadete otsimise võimaluse ning et andmebaasis on tabel Avalik_teade, üle mille veergude pealkiri ja sisu peaks otsing toimuma.
Avalik_teade(avalik_teade_id, pealkiri, sisu) Primaarvõti(avalik_teade_id)INSERT INTO Avalik_teade (pealkiri, sisu) VALUES ('Otsinguvõimalus', 'Kodulehel saab nüüd teha otsingut');
Lisan tabelisse veeru tsv, mis hakkab iga teate korral sisaldama spetsiaalset pealkirja ning sisu kokkuvõtet ja on ühtlasi aluseks nende alusel otsingute tegemisele. See veerg on tüüpi tsvector. See on spetsiifiline PostgreSQLi andmetüüp.
ALTER TABLE Avalik_teade ADD COLUMN tsv tsvector;
Loon tabeliga seotud trigeri, mis andmete tabelisse lisamisel või muutmisel värskendab veergudes pealkiri ja sisu olevate andmete põhjal veerus tsv olevaid andmeid. Määran, et ridade uuendamise (UPDATE) korral peaks triger käivituma ainult siis, kui andmeid uuendatakse (UPDATE) mingis kindlas veerus. Kahjuks ei ole täistektiotsingutel eesti keele tuge, tänu millele oskaks andmebaasisüsteem otsingu tegemisel arvestada keele eripäradega. Seega kasutan inglise keele (pg_catalog.english) reegleid.
CREATE TRIGGER teade_tsv_iu BEFORE INSERT OR UPDATE OF pealkiri, sisuON Avalik_teade FOR EACH ROW EXECUTE PROCEDURE tsvector_update_trigger(tsv, 'pg_catalog.english', pealkiri, sisu);
Teen andmemuudatuse, mis tänu eelnevale trigerile tingib andmete lisamise veergu tsv.
UPDATE Avalik_teade SET pealkiri=pealkiri;
Veerus tsv on nüüd andmed nagu: 'kodulehel':2 'nüüd':4 'otsingut':6 'otsinguvõimalus':1 'saab':3 'teha':5
Loon veerule tsv otsingu kiirendamiseks indeksi.
CREATE INDEX teade_tsv_idx ON Avalik_teade USING gin(tsv);
Muudan veeru tsv kohustuslikuks.
ALTER TABLE Avalik_teade ALTER COLUMN tsv SET NOT NULL;
Järgnev päring leiab tabelist Avalik_teade sellised teated, mis sisaldavad sõna "SQL". Päring väljastab teate identifikaatori, pealkirja, sisu ning pealkirja ja sisu põhjal moodustatud kokkuvõtte, kus on otsisõna esile tõstetud. Päringu tulemus on sorteeritud tulemuse relevantsuse hinnangu alusel kahanevalt.. Päringu tulemuses on maksimaalselt 10 rida..
coalesce funktsioon tagastab vasakult lugedes esimese argumendi, mis ei ole NULL. coalesce(pealkiri,'') avaldis tähendab, et kui pealkiri on olemas (pole NULL) tagastab funktsioon pealkirja, vastasel juhul teiseks argumendiks oleva tühja stringi. Tühi string ja NULL on kaks ise asja - tühi string on väärtus, kuid NULL on marker, mis tähistab väärtuse puudumist. coalesce läheb vaja, sest PostgreSQLi stringide ühendamise (konkatenatsiooni) operaator käitub juhul kui üks argument on NULL järgnevalt: 'tekst' || NULL => NULL. Juhuks kui teates pealkiri või sisu puudub tuleb enne nende ühendamist kontrollida kas üks nendest on NULL ja vajadusel asendada see tühja stringiga: 'tekst' || '' => ''tekst'
SELECT avalik_teade_id, pealkiri, sisu, ts_headline(coalesce(pealkiri,'') || ' ' || coalesce(sisu,''), q) AS fragment  FROM (SELECT avalik_teade_id, pealkiri, sisu, q, ts_rank_cd(tsv,q) AS rank FROM Avalik_teade, to_tsquery('sql') AS q WHERE tsv @@ q  ORDER BY rank DESC LIMIT 10) AS foo;

## Küsimus: Lispunktide/kontrolltöö ülesandeks on teha koopia tabelist X (SELECT ... INTO lausega) ning seejärel koopias ridu muuta või ridu kustutada. Kas võin selle asemel kirjutada lause, mis loob koopia ridadega kus kajastub muudatuste järgne seis?

**Vastus:**

Sellise ülesande eesmärgiks on teha kindlaks, kas lisaks andmetest koopia tegemisele oskate koostada UPDATE või DELETE lauseid. Seega, SQL lisapunktide või kontrolltöö lahendamisel oleks see vale lahendus. Peaksite kirjutama vähemalt kaks eraldi lauset - üks koopia tegemiseks ja teine nõutud muudatuste tegemiseks. Lisapunktide ülesannete lahendamisel ühe lausega lahenduse eest punkte ei saa. Kontrolltöös saab selle eest osa punkte - seega kui kahe lausega ei oska, siis tehke ühe lausega.

## Küsimus: Mida tähendab, et kirjutage INSERT lause nii, et see poleks tundlik veergude järjekorra muutmise suhtes?

**Vastus:**

Halb:

INSERT INTO Isik VALUES ('39107070123', 'Mets');




Kui tabelis Isik muutub veergude järjekord, siis tuleb seda lauset muuta.
Vastasel juhul võib lisamine ebaõnnestuda, või mis veel hullem, lisamine õnnestub, kuid väärtused lähevad valedesse väljadesse.
Lause ei kirjelda esitatud väärtuste tähendust.



Palju parem:

INSERT INTO Isik (isikukood, perenimi) VALUES ('39107070123', 'Mets');




Kui tabelis Isik muutub veergude järjekord, siis ei tule seda lauset muuta.



Halb:

INSERT INTO Magamine_koopia SELECT * FROM Magamine;




Lisaks eelnimetatud probleemidele ei näe koodi lugeja, millised veerud ja millises järjekorras alampäringu poolt tagastatakse.



Palju parem:

INSERT INTO Magamine_koopia (ase_id, algus, magaja_id, kestus, kommentaar)SELECT ase_id, algus, magaja_id, kestus, kommentaar FROM Magamine;


## Küsimus: Mida tähendab ülesandes lause "tabelite ühendamisel realiseerige joini tingimused WHERE klausli abil"?

**Vastus:**

Teatavasti saab tabelite ühendamiseks kasutada nii vanemat süntaksi:
SELECT Oppimine.*, Aine.nimetus AS aine_nimetus FROM Oppimine, Aine WHERE Oppimine.aine=Aine.aine_kood;
kui "uuemat" süntaksi:
SELECT Oppimine.*, Aine.nimetus AS aine_nimetus FROM Oppimine INNER JOIN Aine ON Oppimine.aine=Aine.aine_kood;
"Uuem" on jutumärkides, sest SQL standard näeb seda ette juba 1992. aasta redaktsioonist/versioonist.
Mõlemaid kirjaviise peaks oskama. Näiteks võivad SQL lausete generaatorid genereerida just vanema süntaksiga lauseid. Siis peaks sellest aru saama.
Kui ülesandes on öeldud, et "tabelite ühendamisel realiseerige joini tingimused WHERE klausli abil", siis see tähendab, et juhul kui kasutate ühendamisoperatsiooni, siis tuleb kasutada vanemat süntaksi. Kui lahendate ülesande ilma ühendamisoperatsioonideta (nt kasutades alampäringuid), siis ignoreerige seda juhist.

## Küsimus: Miks õppida SQLi?

**Vastus:**

SQLis kui keeles võiks kahtlemata olla palju asju teistmoodi ja paremini (vt "Andmebaasid I" teema 6 materjale). Arendajad kiristavad SQLi peale hambaid ja kiruvad, kuid ikkagi kasutavad seda.
Miks nad seda teevad? 2021. aasta jaanuari seisuga on kümne kõige populaarsema andmebaasisüsteemi hulgas kuues kasutusel SQL. Sellest tulenevalt on lisaks arendajatele SQL hädavajalik keel andmeteadlastele. Nad peavad kuidagi enda uurimismaterjalile e andmetele ligi pääsema ja sageli on selleks vaja kasutada SQLi.
Näiteks üleeuroopalisel suurandmete töötlemise maratonil 2017. aastal kolmanda koha saanud meeskonna liige kommenteeris, et sisendandmed olid SQL-andmebaasis, hierarhiatena, Adjacency List (külgnevusnimistu) mudeli alusel. Ta ütles SQLi kasutamise kohta: "asi kisub vist hoopis sql hackathoniks. /.../ eeltöötlus ja andmebaasides ringirändamine ja avastamine on 80-90% ajast."
Osalejatele anti vahendite valik vabaks. Eesti meeskond otsustas esmajoones kasutada PostgreSQLi (populaarne ja väga võimalusterohke avatud lähtekoodiga serveri andmebaasisüsteem, kus saab kasutada SQLi). See tähendab, et andmed laaditi PostgreSQLi tabelitesse ja otsiti vastuseid küsimustele kasutades SQL päringuid.
Ainult siis, kui PostgreSQL jäi töökiiruse mõttes hätta ("5+ JOINiga päringutel kulus tulemusteni üle 15 minuti (võtmeveergude indekseerimised jm. "hügieenilised" tegevused olid eelnevalt tehtud)"), laaditi andmed päringu tegemiseks Hadoop klastrisse. Ka seal läks vaja SQLi oskust, sest läbi Hive pakutava liidese saab klastris olevate andmete poole pöörduda kasutades SQL-laadset keelt HiveQL. PostgreSQL päringuid polnud vaja palju muuta, kuid töökiiru paranes kuni 10 korda. Samas kommenteeris üks meeskonna liikmetest, et "Kui Hackathlonil poleks ajapiirangut olnud, siis selle andmestiku puhul oleks saanud ka ilma Hiveta."
Samuti kasutati hajusarvutuste platvormi Spark, kuid ka selle kasutamiseks on kasulik SQLi tunda.
Arvatavasti olete kuulnud NoSQL (kes interpreteerib seda kui "No to SQL", kes aga "Not only SQL") süsteemidest. Need süsteemid sõitsid 2010ndatel suure hurraaga turule, kui järjekordsed printsid valgel hobusel, mis pidid andmebaaside maailma kõigist hädadest päästma. Eriti alguses vastandusid need (nagu nimigi viitab) kõvasti SQLile. Nüüdseks aga on üha rohkemates sellistes süsteemides kasutusele võetud kõrgtaseme (deklaratiivne) päringukeel, mis kangesti meenutab SQLi. Irvhambad on hakanud NoSQLi kutsuma tänu sellele kui "Not yet SQL". Nii et kui "päris" SQLi oskate, siis pole keeruline ka neid uusi keeli suhu saada. Näited:

CQL (Cassandra Query Language, andmebaasikeel veergude perekondade põhises andmebaasisüsteemis Cassandra).
N1QL (päringukeel dokumendipõhises andmebaasisüsteemis Couchbase).
SPARQL (standardiseeritud päringukeel andmebaasisüsteemidele, mis põhinevad RDF (Resource Description Framework, ressursside kirjeldamise karkass) andmemudelil).
PGQL (katse pakkuda graafipõhistele süsteemidele välja ühtlustatud SQLi-laadset päringukeelt).
Rahvusvaheline standardimisorganisatsioon ISO (International Organization for Standardization) alustas graafipõhise andmebaasikeele standardi väljatöötamisega. Uus keel hakkab põhinema SQLil ja selle edul ning andmete otsimise lause peaks meenutama SQL SELECT lauset.
Cypher (päringukeel graafipõhises andmebaasisüsteemis Neo4J).


## Küsimus: Milline võiks olla üldine SQL SELECT lausete koostamise strateegia?

**Vastus:**

Olen kunagi midagi kirjutanud SQL SELECT lausete koostamise üldise strateegia/metoodika kohta. See põhineb paljuski matemaatik Georg Pólya üldist probleemilahenduse strateegiat kirjeldaval raamatul Kuidas seda lahendada.
Huvilised leiavad kirjutise lisamaterjalide lehelt (kasutajanimi: SIS2 parool: SIS2) SIIT.

## Küsimus: Mis vahe on MS Accessi SQL mägimurrakus DISTINCT ja DISTINCTROW määrangutel?

**Vastus:**

SQL standard kirjeldab DISTINCT, kuid mitte DISTINCTROW (st viimane on andmebaasisüsteemi-spetsiifiline leiutis).
Leidke külaliste perenimed nii, et kordused on eemaldatud. Esitage perenimed suurtähtedega. Sorteerige päringu tulemuses perenimed tähestikulisele järjekorrale vastupidises järjekorras.
Õige:
SELECT DISTINCT Ucase(perenimi) AS perenimi
FROM Külaline
ORDER BY Ucase(perenimi) DESC;
SELECT Ucase(perenimi) AS perenimi
FROM Külaline
GROUP BY perenimi
ORDER BY Ucase(perenimi) DESC;

Õpetlik on, et ORDER BY klauslisse tuleb kirjutada ORDER BY Ucase(perenimi) DESC, mitte ORDER BY perenimi DESC;
Kuigi MS Access lubaks ORDER BY lauses kirjutada ka ORDER BY perenimi DESC, siis PostgreSQL ja Oracle tahavad ka seal funktsiooni poole pöördumist (NB! PostgreSQL ja Oracle andmebaasisüsteemides on see funktsioon nimega Upper, mitte Ucase). Pealegi on see ülesande mõttes loogilisem – sorteerida tuleks nende andmete alusel, mis kasutajale esitatakse.
Kui ma ei taha ORDER BY klauslisse funktsiooni poole pöördumist kirjutada, siis võin vormistada lahenduse mitmeosaliselt, kus kõigepealt leitakse suurtähtedega erinevad perenimed ja siis sorteeritakse tulemust.
SELECT perenimi
FROM (SELECT DISTINCT Ucase(perenimi) AS perenimi
FROM Külaline) AS erinevad_perenimed
ORDER BY perenimi DESC;
Vale:
SELECT DISTINCTROW Ucase(perenimi) AS perenimi
FROM Külaline
ORDER BY perenimi DESC;
DISTINCTROW ignoreeritakse, kui andmeid küsitakse vaid ühest tabelist või on vaja väljastada andmed kõikidest FROM klauslis nimetatud tabelite veergudest. Viide.
Veel üks näide.
Leidke vähemalt ühe reserveerimise teinud külaliste erinevad perenimed. Päringu tulemuses on iga perenimi üks kord.
SELECT DISTINCT perenimi
FROM Külaline INNER JOIN Reserveerimine ON Külaline.külalise_nr = Reserveerimine.külalise_nr;
Leidke vähemalt ühe reserveerimise teinud külalised. Väljastage igaühe kohta tema perenimi. Kui leidub rohkem kui üks sama perenimega külaline, kes on teinud vähemalt ühe reserveerimise, siis on see perenimi päringu tulemuses mitmekordselt.
SELECT DISTINCTROW perenimi
FROM Külaline INNER JOIN Reserveerimine ON Külaline.külalise_nr = Reserveerimine.külalise_nr;
DISTINCTROW vaatleb korduste eemaldamiseks tervet tabeli rida, mitte ainult päringu tulemuses väljastatavaid andmeid. DISTINCTROW pole SQL standardis ja on MS Accessi-spetsiifiline kontsruktsioon (seda ei toeta isegi MS Accessi vanem vend – MS SQL Server). Alternatiiv selle kasutamisele:
SELECT perenimi
FROM Külaline 
WHERE EXISTS (SELECT * FROM Reserveerimine WHERE Külaline.külalise_nr = Reserveerimine.külalise_nr);

## Küsimus: Ühes õppematerjalis on öeldud "Objekt-relatsiooniliste andmebaasisüsteemide loomine tuleneb lõppkokkuvõttes sellest, et tänapäeva   SQL-andmebaasisüsteemid   ei   realiseeri   täies   ulatuses relatsioonilist mudelit ja see tekitab probleeme."
Millist osa relatsioonilisest mudelist SQL andmebaasisüsteemid ei realiseeri? Miks nõnda?

**Vastus:**

Põhinemine hulkade asemel multihulkadel (korduvad read ja veerud on lubatud),tühjade võtmete ja ilma veergudeta tabelite mitte lubamine (kuigi ka tühi hulk on hulk),NULLide kasutamine puuduvate andmete esitamiseks, liigsete piirangutega ja samas liiga keeruline uute tüüpide loomise võimalus, SQL-andmebaasisüsteemides praktikas esinevad piirangud deklaratiivsete kitsenduste loomisele (nt ei saa luua üldiseid kitsendusi e ASSERTIONeid),üleüldine järjekindlusetus asjade tegemises või lubamises,need on vaid mõned asjad, mis muudavad SQLi kasutamise keerukamaks kui peaks.Nii mõnedki erinevused SQLi ja relatsioonilise mudeli lähenemiste vahel on toodud välja teema nr 2 (relatsiooniline andmemudel) slaididel (märkused punastes kastides). Põhjalikumalt on teemat eesti keeles lahatud SELLES ettekandes ja SELLE materjali peatükis 6.Kes ei taha pelgalt piirduda vahendatud infoga, see võib uurida Kolmanda Manifesti kohta ilmunud värskeimat raamatut, kus relatsioonilise mudeli ideid väga põhjalikult ja paljude näidetega selgitatakse.SIIN on aga andmebaasisüsteem (Rel), mis realiseerib relatsioonilist mudelit nii nagu sellest aine teemas nr 2 juttu oli.


---

# Teema: Vahendid - CASE

## Küsimus: Kas iseseisva töö projektis võib kasutada mõnda muud CASE vahendit kui Enterprise Architect (EA) või Rational Rose (RR)?

**Vastus:**

Keelatud see ei ole. Kuid palun arvestage järgnevaga.

Kui Te ei kasuta EA või RR, siis Te ei saa kasutada töövihiku projekti puhul eelnevalt valmistehtud diagramme ja peate need nullist käsitsi joonistama.
Kui Te ei kasuta mõnda andmete modelleerimisele spetsialiseerunud CASE vahendit (näiteks kasutate ArgoUMLi või Cacood), siis Te ei saa kasutada kontseptuaalsest andmemudelist andmebaasi disaini mudeli genereerimise võimalust ja peate andmebaasi disaini mudeli looma nullist käsitsi.
Kui Te ei kasuta mõnda andmete modelleerimisele spetsialiseerunud CASE vahendit (näiteks kasutate ArgoUMLi või Cacood), siis Te ei saa kasutada andmebaasi disaini mudelist SQL koodi genereerimise võimalust ja peate SQL koodi tabelite loomiseks kirjutama nullist käsitsi.


## Küsimus: Kuidas käivitada Enterprise Architecti mudeliteisenduste täiendust arvutiklassides?

**Vastus:**

Kuna laienduse autor ei teadnud installeerimise programmi loomisel kõiki tsentraalse installeerimise eripärasid, siis on selle laienduse korrektseks töölehakkamiseks vaja arvutiklassi arvutis üks kord käivitada reg.reg fail. Seda saavad üliõpilased oma konto alt ise teha. Pärast seda, peale EA taaskäivitamist, hakkab laiendus tööle. Kui arvutis on see fail korra käivitatud, siis rohkem pole seda vaja enam teha. Isiklikule arvutile installeerides seda pole vaja teha - peaks koheselt töötama, kui olete juhendis olevat installeerimise protseduuri järginud.
Mingil põhjusel funktsioneerib see mudeliteisendus vaid osades arvutiklassi arvutites. Seega, kui see ühes ei tööta proovige teist.

## Küsimus: Kuidas on võimalik Rational Rose'ist eksportida mõni diagramm bmp/jpg/gif/png kujul?

**Vastus:**

Diagrammi dokumenti kopeerimiseks pole seda vaja teha. Piisab, kui teete diagrammi aktiivseks, valite klaviatuurilt Ctrl+A (vali kõik diagrammi elemendid), Ctrl+C (kopeeri) ning dokumendis valite Ctrl+V (kleebi).
Kui see mingil põhjusel ei sobi, siis näiteks Windowsi puhul võib kasutada spetsiaalset operatsioonisüsteemiga kaasa tulevat abiprogrammi (Windows Snipping Tool).

## Küsimus: Kuidas parandada Enterprise Architect CASE vahendis loodud andmebaasi disaini mudelis riknenud tabelite vahelist seost?

**Vastus:**

Vaadake palun lisatud faili.

## Küsimus: Kuidas toimida, kui kasutan Enterprise Architect 12 vahendit, soovin MS Accessi andmebaasi disaini mudelis määrata veeru tüübiks Decimal, kuid seda tüüpi ei ole pakutavate tüüpide valikus?

**Vastus:**

Project => Settings => Database Datatypes 


 

Sealt alt saaks lisada uusi andmetüüpe, mida andmebaasi disaini mudelis kasutada. Valige avanenud aknas Product Name: MS AccessPeate määrama baastüübi (Common Type) (saate valida decimal), täpsuse+skaala ja peate andma tüübile nime. Seejärel tuleb vajutada Save nupule.Decimal tüüpi veerg on mõeldud kümnendmurdude e püsikomaarvude registreerimiseks. Kasutage seda kui on vaja registreerida komakohtadega arve ning on teada maksimaalne kohtade arv peale koma. Kui  Te just ei tegele teadusmõõtmiste andmete registreerimisega, siis peakski komakohtadega arvude registreerimisel kasutama Decimal tüüpi. Sõltuvalt ujukomatüüpi andmete sisemise salvestamise viisist võivad nende puhul tekkida koondandmete leidmisel ümardamise vead.Muide, sellisel juhul peaks kontseptuaalses andmemudelis vastava atribuudi definitsioonis olema kirjas, kui palju komakohti on vaja.Decimal tüübi kasutamise puhul tuleb ära määrata täpsus (precision) ja skaala (scale). precision määrab ära maksimaalse numbrikohtade arvu ja skaala kohtade arvu peale koma. Näiteks veerus, mis on tüüpi Decimal (3,1), saab olla maksimaalne väärtus 99.9 ja minimaalne väärtus -99.9 (kolm numbrikohta, üks peale koma).





**Märksõnad:** kümnendmurd, püsikomaarv, ujukomaarv, MSAccess

## Küsimus: Kui mina muudan näiteks kaupade registri diagrammis klassi seost, siis mina pean uuesti genereerima SQL tabelite disaini kirjelduse?

**Vastus:**

Teil tuleb tagada kontseptuaalse andmemudeli, andmebaasi füüsilise disaini kirjelduse ja valmistehtud tabelite kooskõla. Selle saavutamiseks on erinevaid strateegiaid, uuesti genereerimine on nendest üks. Arvan, et kui muudatus kontseptuaalses andmemudelis ei ole väga suur, siis tulenevalt kasutatavate CASE vahendite tehnilistest piirangutest, võib muuta kontseptuaalset andmemudelit, siis muuta käsitsi andmebaasi füüsilise disaini kirjeldust ning siis genereerida uuesti SQL kood.

## Küsimus: Kui mul on Enterprise Architect (ver 12) CASE vahendis loodu mudelis Isiku klass koos atribuutidega Isikute registris, aga sooviksin teistes registrites nt Klientide registris seda klassi ilma atribuutideta kuvada, siis kuidas seda teha?

**Vastus:**

Aktiveerite klassi => parem hiireklõps Features and Properties => Feature and Compartment Visibility. Avanenud aknas eemaldate ülevalt vasakult nurgast linnukesed valikute "Attribute Visibility => All" ja "Operation Visibility => All" eest.

**Märksõnad:** olemi-suhte diagramm, refaktoreerimine

## Küsimus: Kumba CASE vahendit eelistada projekti tegemiseks - kas Enterprise Architect (EA) või Rational Rose (RR)?

**Vastus:**

Mõlemad vahendid on projekti tegemiseks sobivad. Järgnevalt tuuakse esile kummagi tugevad küljed võrreldes teisega.
EA eelised RR ees

Palju uuem, ettevõtetes rohkem kasutusel
Installeerimine ja litsentsi hankimine lihtsam
Võimalused luua palju rohkem erinevat tüüpi mudeleid (kuid selles aines ei lähe neid vaja)
Võimalik programmeerida juurde laiendusi (ühte sellist hakkame kasutama - vaadake palun Tarkvara/EA mudeliteisenduse täiendus ja proovige installeerida)
Andmebaasi disaini mudeli saab luua spetsiifiliselt PostgreSQL või MS Accessi jaoks
Semestri alguses loengus projekti tehes kasutan EA-d (samas on RR kasutamise kohta olemas kodulehel videod)

RR eelised EA ees

Litsentsi ei pea 10 nädala tagant värskendama
Vähem funktsionaalsust (selleks aineks kõik vajalik olemas), kuid tänu sellele ka lihtsam ja kiiremini kasutatav kasutajaliides
Kaasa tulev genereerimismoodul, mis tekitab kontseptuaalsest andmemudelist füüsilise SQL-andmebaasi disaini mudeli, on parem (disaineril on hiljem vaja teha vähem käsitsi muudatusi)
Väga palju lihtsam ja kiirem on muuta SQL-andmebaasi disaini kirjeldustes välisvõtmeid - tegevus, mida on vaja päris palju teha
Genereeritav SQL kood on lihtsamini käivitataval ja loetaval kujul - koodi tuleb vähem käsitsi muuta

Mõlema vahendi nõrkused

Fail võib rikneda, mis tähendab, et eelnev töö läheb kaotsi
SQL lausete generaator teeb vigu

Mõlema vahendi kasutamise kohta on kodulehel videod.

Enterprise Architect
Rational Rose

Slaidiesitlus (kasutajanimi: SIS2, parool: SIS2), mille teises pooles antakse ülevaade EA ja RR probleemidest seoses andmete modelleerimisega.
Rational Rose eestikeelne juhend (kasutajanimi: SIS2, parool: SIS2).
NB! Ülikooli vahendusel litsentsi saamise võimalus on vaid tarkvarale, mis on alla laaditud SIIT.

## Küsimus: Lõin ühenduse virtuaalse töölauaga ning seadistasin failide jagamise, kuid virtuaalsel töölaual ei ilmu minu kohaliku arvuti kataloogid nähtavale. Mida teha?

**Vastus:**

Kui olite virtuaalsele töölauale sisseloginud, siis muudatuste rakendamiseks logige virtuaalselt töölaualt välja ja uuesti sisse, mitte ärge valide ristile vajutades "Disconnect".

**Märksõnad:** Horizon, virtuaalne töölaud, vmware

## Küsimus: Ma ei suuda Enterprise Architect (EA) vahendi menüüde rägastikus orienteeruda. Millised on kõige olulisemad menüüpunktid antud aine jaoks?

**Vastus:**

Järgnevalt on nimetatud EA12 näitel mõnede oluliste funktsioonide asukoht menüüsüsteemis.

Tööriistakast, kust saab valida mudelisse lisamiseks uusi elemente. Kui olete selle kinni pannud, siis saate uuesti avada: Diagram=>Toolbox (kiirkorraldus ALT+5)
Projekti elementide hierarhia. Kui olete selle kinni pannud, siis saate uuesti avada: View=>Project Browser (kiirkorraldus ALT+0)
Andmebaasi disaini mudeli loomiseks mõeldud täiustatud teisenduse kasutusele võtmine: Project=>Data Management=>Import Reference Data
Enne andmebaasi disaini mudeli teisenduse abil loomist tuleb määrata, millise andmebaasisüsteemi jaoks disaini mudel luuakse: Project=>Settings=>Database Datatypes Avanenud aknas tuleb soovitud andmebaasisüsteemi juures märkida Set as Default
Mudeliteisendus kontseptuaalsest andmemudelist andmebaasi disaini mudeliks: Package=>Model Transformation (MDA)=>Transform Current Package
SQL koodi genereerimine: Package=>Database engineering=>Generate package DDL


## Küsimus: Meil tekkis andmebaasi füüsilise disaini mudeli genereerimisega probleem: veerg nimega kood esineb mitmes kohas. Milles võib olla probleem?

**Vastus:**

See probleem tekib Enterprise Architecti (EA) täiendatud mudeliteisenduse kasutamise korral. Tekib, sest ka EA täiendatud mudeliteisendus pole paraku ideaalne.
Konkreetne põhjus on selles, et kontseptuaalses andmemudelis on olemitüüp Klassifikaator, millel on atribuut kood. Klassifikaatoril on palju alamtüüpe (Riik, Amet, Töötaja_seisundi_liik jne) millest igaühe põhjal luuakse eraldi tabel. Kõikidesse nendesse tekib teisenduse tulemusena primaarvõtme veerg kood. See veeru nimi tuleb ära muuta nii klassifikaatorite tabelites kui ka tabelites, kuhu koodid lähevad välisvõtmeks. Näiteks kui tabelis Amet on veerg kood, siis selle uus nimi võiks olla amet_kood. Kui tabelis Töötaja on välisvõtme veerg kood, milles olevad andmed viitavad ridadele tabelis Amet, siis ka sellele veerule tuleb anda nimi amet_kood.
Järgnevalt esitan soovitusliku parandamise algoritmi. Kõigepealt terminoloogiast:
[Amet]-1--------0..*-[Töötaja]
Välisvõti on tabelis Töötaja Amet - primaarne tabel, antud juhul klassifikaatori tabel Töötaja - sõltuv tabel
1. Juhul kui sõltuvas tabelis on täpselt üks välisvõtme veerg nimega kood (näiteks töövihiku kasutamise korral Klient).

Muuda primaarvõtme veeru nime klassifikaatori tabelis (näiteks tabelis Kliendi_seisundi_liik: kood=> kliendi_seisundi_liik_kood).
Muuda vastavat välisvõtme veeru nime sõltuvas tabelis (antud juhul tabelis Klient: kood=> kliendi_seisundi_liik_kood).

2. Juhul kui sõltuvas tabelis on rohkem kui üks välisvõtme veerg nimega kood (näiteks töövihiku kasutamise korral Töötaja).

Kustuta sõltuvast tabelist kõik välisvõtme kitsendused, mis viitavad klassifikaatorite tabelitele (näiteks kaks kitsendust tabelist Töötaja).
Muuda primaarvõtme veeru nime kõikides asjassepuutuvates klassifikaatori tabelites (näiteks tabelis Amet: kood=> amet_kood; tabelis Töötaja_seisundi_liik: kood=> töötaja_seisundi_liik_kood).
Muuda vastavate välisvõtme veergude nimesid sõltuvas tabelis (antud juhul tabelis Töötaja: kood=> amet_kood; kood=> töötaja_seisundi_liik_kood ).
Loo välisvõtme kitsendused mudelis käsitsi uuesti.


## Küsimus: Mida teha, kui arvutiklassi arvutis küsib Enterprise Architect (EA) avamisel võtit ja ei ole nõus ilma selleta käivituma?

**Vastus:**

Sulgege EA.
Valige: Control Panel => System and Security => Configuration Manager => Configurations => evaluate CB WRK Enterprise Achitect Key
Seejärel avage EA uuesti.

**Märksõnad:** litsents, värskendamine, laenutamine, arvutiklass

## Küsimus: Mida teha, kui Horizoni virtuaalsel töölaual küsib Enterprise Architect (EA) avamisel võtit ja ei ole nõus ilma selleta käivituma?

**Vastus:**

EA kasutamiseks peab peale sisselogimist hetke ootama, et skriptifail looks vajalikud registri võtmed selle jaoks. Config Manageri (mille kaudu käib võtmete laenutamine arvutiklassi arvutis) nendes masinates pole ja Horizoni loomuse tõttu ei hakka ka olema.

**Märksõnad:** Horizon, virtuaalne töölaud, VDI-Andmebaasid, vmware

## Küsimus: Mul registrite analüüsi mudel loodud. Pärast andmebaasi disaini mudeli nagu videos õppeaine kodulehel.
Kokku kõik on korras, aga tekib tõsine probleem. CASE vahend ehitab seosed Kliendi, Ameti, Treeningu ja Töötaja seisundi liigi vahel. Aga ei peaks ja ma ei taha. Mida teha?

**Vastus:**

Arvan, et põhjuseks on analüüsi mudelisse kogemata tehtud ja korralikult kustutamata jäänud valed seosed.
Konkreetsel juhul võtke palun lahti analüüsi mudelis klientide registri olemi-suhte diagramm ja lohistage sellele mudelist olemitüübid (klassid) Amet, Töötaja_seisundi_liik ja Treening. Kui selle tulemusel tekivad diagrammile ka seosed Kliendiga, siis kustutage need seosed.
Seose mudelist kustutamiseks tehke:

Enterprise Architect (EA) CASE vahendis seos aktiivseks; valige parema hiire klahvi alt hüpikmenüüst "Delete connector" või vajutage Delete klahvile; valige "Delete the connector from the model".
Rational Rose (RR) CASE vahendis seos aktiivseks; valige parema hiire klahvi alt hüpikmenüüst "Edit" => "Delete from Model".

Seejärel genereerige andmebaasi disaini mudel uuesti. Samuti eemaldage klientide registri olemi-suhte diagrammilt Amet, Töötaja_seisundi_liik ja Treening.
Kuna kasutate analüüsi mudelit uue tehise (disaini mudeli) genereerimiseks, siis on väga oluline, et analüüsi mudelisse ei jääks "prügi".

## Küsimus: Rationa Rose-il pole menüüs punkti Data Modeler => New => Database, millega genereerida andmebaasi füüsilise disaini mudelit. Mis on valesti?

**Vastus:**

Selleks, et saaksite kasutada Rational Rose'i (2007) Data Modeleri, peab arvutis eelnevalt olema installeeritud .NET Framework redistributable (ver. 1.1) või kõrgem Installige enne .NET ja siis Rational.


---

# Teema: Vahendid - MS Access

## Küsimus: Kas ja millised on MS Accessi eelised SQLi õppimisel?

**Vastus:**


SQL andmekäitluskeele lausete (SELECT, INSERT, UPDATE, DELETE) koostamiseks saab kasutada graafilist kasutajaliidest - Query Designer. See graafiline kasutajaliides realiseerib visuaalse andmebaasikeele Query by Example. Võimalik on tõlkida lauseid ühest keelest (SQL ja Query by Example) teise. Siit saab vaadata videoid Query by Example abil päringute kooostamisest.
Tabelites on läbi graafilise kasutajaliidese lihtne teha andmemuudatusi. Nii saab kergelt teha andmemuudatusi, kontrollimaks, et koostatud SQL laused annavad igas olukorras oodatud tulemuse.
MS Accessi SQLi mägimurrak ei ole nii suurte võimalustega kui võimekamatel SQL-andmebaasisüsteemidel, kuid kõik põhiline on olemas. Näiteks lendama õppimisel ei alustata praktiseerimist ka mitte kohe reisi- või sõjalennukist, vaid kõigepealt saavutatakse põhjendatud enesekindlus väikesel lennukil ja sellega sillutatakse teed aina suuremate lennukitega lendamiseks.

PostgreSQL ja Oracle lisavõimalusi võib vaadata lisamaterjalide lehelt (kasutajanimi: SIS2 ja parool: SIS2) SIIT (Ja mõelge, kas tahaksite ka kõige selle peale kontrolltööd teha).

## Küsimus: Kas MS Accessis tuleks hoiduda Decimal tüübi kasutamisest?

**Vastus:**

Ei!Kui loete soovitusi (nagu see siin), siis pöörake tähelepanu millise süsteemi versiooni kohta need on. See konkreetselt on vana versiooni kohta ning vähemalt MS Access 2019 ja uuemates ei kehti. Tehke katse. Käivitage oma andmebaasis ükshaaval järgmised laused:CREATE TABLE Decimal_test (v DECIMAL (3,2));INSERT INTO Decimal_test (v) VALUES (1.0);INSERT INTO Decimal_test (v) VALUES (-1.0);INSERT INTO Decimal_test (v) VALUES (-3.22);INSERT INTO Decimal_test (v) VALUES (-1.01);INSERT INTO Decimal_test (v) VALUES (0);Seejärel proovige päringut:SELECT * FROM Decimal_testORDER BY v;Päringu tulemuses on sorteerimisega on kõik korras.

**Märksõnad:** MSAccess

## Küsimus: Kuidas jõustada MS Accessis tabeliga seotud kitsendus, et elukoht ei tohi olla ainult numbritest koosnev string?

**Vastus:**

MS Access ei paku täielikku toetust regulaaravaldiste kasutamisele, kuid selle LIKE predikaadi mustrite koostamise võimalusi on laiendatud regulaaravaldistest tuntud võimalustega.
Nimetatud kitsenduse jõustamiseks on abi, kui see kitsendus ümbersõnastada.
Kui elukoha stringis on vähemalt üks numbrimärk, siis peab selles olema ka mõni selline märk, mis ei ole numbrimärk.
Teatavasti võib binaarset loogilist operatsiooni implikatsioon kasutava avaldise P=>Q kirjutada teisendusreeglite alusel ümber samaväärseks avaldiseks: NOT (P) OR Q. Sellise avaldise saab aga juba tabelitaseme valideerimisreeglina kirja panna.
Antud juhul

P="Kui elukoha stringis on vähemalt üks numbrimärk"
Q="peab selles olema ka mõni selline märk, mis ei ole numbrimärk"

Seega seon MS Accessis veeruga elukoht valideerimisreegli:
Not ([elukoht] ALike '%[0-9]%') Or ([elukoht] ALike '%[!0-9]%')
[!0-9] ütleb mustris, et leiduma peab vähemalt üks märk, mis ei kuulu numbrimärkide hulka.
Veel üks võimalus on defineerida MS Accessis veeruga elukoht seotud valideerimisreegel:
IsNumeric([elukoht])=False
Võrdluseks, PostgreSQL ja Oracle võimaldavad regulaaravaldiste kasutamist:

PostgreSQLis tuleks tabeliga Isik siduda CHECK kitsendus: CHECK (elukoht!~'^[[:digit:]]+$')
Oracles tuleks tabeliga Isik siduda CHECK kitsendus: CHECK(NOT REGEXP_LIKE(elukoht,'^[[:digit:]]+$'))

Need kitsendused kontrollivad, et elukoht ei vastaks mustrile, mille kohaselt sisaldab see ainult numbrimärke.

**Märksõnad:** MSAccess

## Küsimus: Kuidas kirjeldada Decimal tüüpi veergu läbi tabeli graafilise disaineri?

**Vastus:**

Määrake veeru omaduste juures järgnevat:Data Type (Andmetüüp): Number (Arv)Field Size (Välja suurus): Decimal (Kümnendarv)Precision (Täpsus): Soovitud maksimaalne numbrikohtade arvScale (Mastaapimine): Soovitud kohtade arv peale komaValik Decimal Places (Kümnendkohad) määrab kuvatavate komakohtade arvu ja sinna võib jätta Auto (Automaatne).Näiteks veerus, mis on tüüpi Decimal (3,1), saab olla maksimaalne väärtus 99.9 ja minimaalne väärtus -99.9 (kolm numbrikohta, üks peale koma). Antud juhul on täpsus 3 ja skaala 1.

## Küsimus: Kuidas teha nii, et MS Accessis oleksid avatud aknad (näiteks tabelid või SQL lausete kirjutamise aknad) organiseeritud sakkidena (kaartidena) üksteise kõrval (vt lisatud pilt)?

**Vastus:**

Valige File=> Options=> Current Database => Tabbed DocumentsSee valik on üsna pakutavate valikute nimekirja alguses.Samuti veenduge, et sealsamas on märgistatud "Display Document Tabs".Kui soovite, et aknad oleksid üksteisest sõltumatult väiksemaks ja suuremaks tehtavad ning võivad ka üksteist katta,siis sealsamas on valik "Overlapping Windows".Vt ka: https://www.599cd.com/glossary/access/overlappingwindowstabbeddocuments/?key=

## Küsimus: Kust saab infot MS Accessis kasutusel oleva SQL mägimurraku e dialekti kohta?

**Vastus:**

Kuigi SQL on rahvusvaheline standard, ei realiseeri paraku ükski andmebaasisüsteem seda täielikult. Ilmselt on põhjus selles, et standard on väga mahukas. See tähendab, et mistahes SQL-andmebaasisüsteemis on ilmselt võimalusi, mida standard näeb ette, kuid süsteem ei paku nagu ka võimalusi, mis on spetsiifilised sellele süsteemile. See on paraku elu tõsiasi. Need on mõned allikad, kus aine materjalidele lisaks MS Accessi SQL mägimurraku kohta lugeda.

Jet SQL (see on MS Accessi aluseks oleva andmebaasimootori nimi),
Microsoft Access SQL reference.


**Märksõnad:** mägimurrak, MSAccess, MS Access

## Küsimus: Millised on MS Accessi eelised teiste SQL-andmebaasisüsteemide ees?

**Vastus:**

Iga töö jaoks on oma tööriistad. Töövahend pole universaalselt halb ega hea, vaid sellel on sobivad ja mittesobivad kasutusvaldkonnad. Ma pole nõus nendega, kes MS Accessi põlastavad ja selle peale nina kirtsutavad. Prototüüpide, üksikkasutajate andmebaaside ja väikeettevõtete andmebaaside loomiseks on see väga hea vahend. Saan aru, kui kõhklusi tekitab hind, suletud lähtekood või tootjafirma maine, kuid funktsionaalsuselt on see väga hea vahend. Lihtsalt "ilusate silmade" eest selles pingereas kõrgele kohale ei jõua (MS Access on seal esikümnes või selle lähedal).Siin on näide artiklist, kus tuuakse välja MS Accessi puuduseid. Samas selles samas artiklis välja toodud alternatiivide juures tuuakse välja nende nõrgad küljed, mis näitavad nende alternatiivide nõrkuseid. Selle sama artikli kommentaaride osas on elav arutelu, kus ei olda autoriga nõus. Muuhulgas viidatakse seal 2019. aasta intervjuule MS Accessi programmijuhiga, kes kinnitab Microsofti jätkuvat pühendumust MS Accessi edasi arendada.Nimetan järgnevalt mõningaid MS Accessi eeliseid konkurentide ees. MS Access on töölaua andmebaasisüsteem. Võrreldes "vanemate vendade/õdedega" - serveri andmebaasisüsteemidega (nt PostgreSQL, Oracle erinevad väljaanded, MySQL) - on sellel palju puudujääke. Kuid kas on ka eeliseid? Jah on. Üksiti võttes võivad tunduda väikesed asjad, kuid palju väikeseid asju annab kokku ühe suure.

Tabeli veergude järjekorra muutmiseks tabelis tuleb tabeli disainivaates veergu sobivale kohale lohistada.

SQL tabelites on veerud vasakult paremale järjestatud. Igal veerul on järjekorranumber. Mõnes olukorras tuleb seda järjekorranumbrit teada. Paraku ei paku SQL  lauset tabeli veergude järjekorra muutmiseks või veeru lisamiseks konkreetsele positsioonile. Seega on teistes süsteemides enamasti lahenduseks tabeli kustutamine ja uuesti loomine.


CHECK kitsendustes saab kasutada alampäringuid.

Võimaldab realiseerida deklaratiivsel viisil keerukate reeglite kontrolli. See tähendab, et süsteemile öeldakse, mida peab kontrollima, mitte kuidas seda teha. Näiteks PostgeSQL ja Oracle ei luba CHECK kitsendustes alampäringuid ning keerukamate reeglite andmebaasi tasemel jõustamiseks ei jää üle muud kui luua trigereid. Trigerites kirjeldatakse andmete kontrolli protseduur. Koodi on palju rohkem kui deklaratiivsete kitsenduste puhul ning lihtne on teha vigu. Muide, ka MS Accessis on võimalus sisuliselt luua trigereid - selleks tuleb luua andmemakrod.


Attachment tüübi kasutamine veeru tüübina, mida saab määrata ainult läbi graafilise kasutajaliidese, võimaldab lihtsalt ja mugavalt realiseerida failide andmebaasis hoidmise.

Andmebaasirakenduse kaudu hallatavate failide (näiteks veebipoe kaupade pildid) hoidmine väljapool andmebaasi (andmebaasisüsteemi kontrolli alt väljas) on üks SQL disaini antimustritest - Assume You Must Use Files (Phantom Files) (Chapt 12).


Tabeli disainivaates saab valideerimisreeglitega koos määrata valideerimisteksti. Seda näidatakse kasutajale kui tema andmemuudatus eksis selle reegli vastu. Niimoodi on võimalik kerge vaevaga määrata (loodetavasti head ja arusaadavad) veateated, mida kasutajale näidatakse.

Paraku ei pöörata veateadete heale kasutatavusele paljude programmide puhul piisavat tähelepanu.


Päringute kujundaja (query designer) pakub ka võimalust andmete muutmise lausete (INSERT/UPDATE/DELETE) koostamiseks.

SELECT lausete graafilise kasutajaliidese abil koostamise võimalust pakutakse paljudes programmides, kuid andmete muutmise lausete sellise koostamise võimalusega polegi ma muudes programmides kokku puutunud.


TOP predikaat, mida saab kasutada ka teistes Microsofti andmebaasisüsteemides, kuid mida ei kirjelda SQL standard, võimaldab mitmeid ülesandeid lihtsamalt lahendada. Näiteks - leia hotellid, milles on toimunud kõige rohkem reserveerimisi (selliseid hotelle võib olla rohkem kui üks).

SELECT TOP 1 hotelli_nrFROM ReserveerimineGROUP BY hotelli_nrORDER BY Count(*) DESC;

Andmebaasisüsteemiga ühte programmi integreeritud andmebaasirakenduste loomise võimalus on hea näide väikese kodeerimise vajadusega arenduskeskkonnast (low code development environment).

See on IT süsteemide arenduse üks oluline tulevikusuund. IT on igal pool ja inimestel on vajadus/soov luua kiiresti endale kõige sobivamat tarkvara. Süsteemiarendus demokratiseerub, st võimalikult paljud peaksid seal saama kaasa lüüa. 
Näiteks Oracle veebirakenduste kiirprogrammeerimise keskkonnas Apex andmebaasirakenduse loomise kasutajakogemus meenutab väga palju MS Accessi kasutamise kogemust. Vahe on selles, et Apexis on kogu arendusliides veebipõhine ja arenduse tulemusena valmib Oracle andmebaasi kasutav veebirakendus.


Võimalus kasutada SQL lausetes parameetreid, mille väärtust küsitakse lõppkasutajalt või loetakse mõnelt ekraanivormilt.
Andmebaasirakenduse mugavam muutmine.

Muutes tabeli/veeru nime muudetakse paljudel juhtudel automaatselt (siiski küll mitte alati) ka salvestatud SQL lauseid (queries) nii, et need arvestaksid uute nimedega. Paraku alampäringuid ei osata muuta.
Muutes tabeli/veeru nime muudetakse paljudel juhtudel automaatselt (siiski küll mitte alati) ka ekraanivorme nii, et need arvestaksid uute nimedega.  Muudetakse just selliseid vorme, mis on seotud tabelitega (bound forms), st mitte selliseid, kus andmete leidmine ja esitamine käib kasutaja kirjutatud VBA koodi kaudu.




**Märksõnad:** MSAccess

## Küsimus: Mul tekkis probleem MS Accessi allalaadimisega (vt lisatud pilt):

Azure portalis pakutakse mulle ainult venekeelset versiooni.
Kui genereerin allalaadimis URL-i, siis tuleb mingi viga. Teiste tarkvaradega sellist probleemi ei ole.

Kuidas tuleb tegutseda?

**Vastus:**

Probleem on selles, et Te olete sisseloginud gmail kontoga. Gmail ei ole seotud TalTech litsentsidega.
 
Tarkvara saab sealt vaid siis, kui tehakse endale Windows konto, mis seotakse TalTech UniID-ga.
 
Täpsemalt, Te ei ole täitnud siin kirjeldatud variant 2 puhul nõutud samme 2-4.

**Märksõnad:** Access, Azure Dev Tools for Teaching, MSAccess

## Küsimus: Teen MS Accessis currency veeru põhjal näiteks summeerimise või keskmise leidmise päringu. Tulemuses ei ole valuuta tähiseks Eur. Mida teha?

**Vastus:**

Põhjus on Windowsi regionaalsetes sätetes. Tähis võetakse sealt ning järelikult peitub ka tulemuse põhjus seal.

**Märksõnad:** euro

## Küsimus: Võtsime lahti Accessi faili, mida sai kunagi arvutiklassis täiendatud, ning nüüd viskab Error 2950-it (Action name: Set property). Milles on probleem ja kuidas seda lahendada?

**Vastus:**

Avasite 32-bitises MS Accessis tehtud faili 64-bitises MS Accessis. Kui seda teha, siis võib olla vaja VBA koodi parandada.


---

# Teema: Vahendid - muu

## Küsimus: Kas "Andmebaasid I" iseseisvas töös võib rakenduse prototüübi tegemisel kasutada mõnda ORM (Object-Relational Mappers, objekt-relatsioonvastenduse) vahendit.

**Vastus:**

See pole keelatud. Kuid palun tutvuge ka probleemidega.
ORM vahendi(te) probleemidele osutab see uuring 67 avatud lähtekoodiga tarkvara põhjal.
Siin on veel üks suure hulga põhjendustega selgitus, miks üks arendaja loobus ORMi kasutamisest ning eelistab ise SQL lauseid kirjutada.
Siin on arutelu, kus kõrvutatakse ORMi ja andmebaasiserveris talletatud rutiinidest, vaadetest ja hetktõmmistest koosneva virtuaalse andmete kihi kasutamist.
NB! "Andmebaasid II" aines pole see ka keelatud, kuid siis tuleb tingimata tagada, et loodud rakendus kasutab andmebaasi läbi avaliku andmebaasi liidese e virtuaalse andmete kihi. Teiste sõnadega peaks rakendus lugema andmeid vaadetest (näiteks Djangos on see võimalik) ning muutma andmeid kasutades andmebaasiserveris talletatud rutiine (näiteks Djangos on see võimalik). Andmete kitsendustele vastavuse kontroll peab toimuma andmebaasi tasemel (kasutades deklaratiivseid kitsendusi ja reegleid), mitte rakenduse tasemel nagu ORM vahendid üldiselt propageerivad.
"Andmebaasid I" õppeaines, kus iseseisva töö üheks tulemuseks on rakenduse prototüüp, ei ole avaliku andmebaasi liidese loomine nõutud. Küll aga tuleb ka selles aines kitsendusi maksimaalselt andmebaasi tasemel jõustada.

**Märksõnad:** rutiin, funktsioon, protseduur, hetktõmmis, materialiseeritud vaade, virtuaalne andmete kiht, andmebaasi avalik liides

## Küsimus: Kas on võimalik kasutada aines vajalikku tarkvara ilma seda enda arvutisse installeerimata?

**Vastus:**

Jah, alates 2021. aasta septembrist on see võimalik kasutades virtuaalset töölauda.Juhendi leiab SIIT.
Tuleb valida virtuaalne töölaud VDI-andmebaasid.
Lahendus töötab ka väljastpoolt ülikooli. Hetkel ei ole sellisel juhul eelnevalt vaja luua eduVPN ühendust, aga see võib jooksvalt muutuda, kui administraatorid tunnevad, et on vaja lisada eraldi turvakiht.
Teenus töötab vajadusel veebilehitsejas.
Lisaks Windowsile on olemas kliendid nii Linuxile kui Macile ning tegelikult isegi Android ja iOS jaoks.
Samuti saate seda lahendust kasutada, kui olete oma Linux/Mac arvutiga arvutiklassis.NB! Kindlasti on vaja teha vastavalt juhendile ketta jagamine, sest välja logides kustutatakse loodud failid kohe (sh kataloogist PrivatData). Kui sulgete Horizon akna ristist, siis loodud töölaud ja failid säilivad 15 minutit. Kui kasutate veebipõhist lahendust, siis saab virtuaalsele töölauale faile üleslaadida (vt küsimusele lisatud pilti). Kuid failide kättesaamiseks tuleks logida VDI masinast näiteks OneDrive'i. Seega on soovitatav kasutada klientprogrammi ning veebilehitseja jätta pigem hädajuhtudeks.EA kasutamiseks peab peale sisselogimist hetke ootama, et skriptifail looks vajalikud registri võtmed selle jaoks. Config Manageri (mille kaudu käib võtmete laenutamine arvutiklassi arvutis) nendes masinates pole ja Horizoni loomuse tõttu ei hakka ka olema.Siit lehelt  leiate rohkem infot Vmware Horizoni kohta.

**Märksõnad:** mac, linux, kaugkasutus, ülikool, arvuti, virtuaalne töölaud, Horizon, vmware

## Küsimus: Kas projekti dokumenti võib teha Githubi Wikis, Google Docs'is või muus sarnases rühmatööd toetavas keskkonnas?

**Vastus:**

Miks mitte, kuid soovitan ikkagi kaaluda MS Wordi kasutamist, sest seal on mudeli koostajale väga kasulik funktsionaalsus - Split screen. See funktsionaalsus lihtsustab projekti erinevate osade kooskõla kontrollimist.
Ükskõik mis vahendit Te dokumendi loomiseks kasutate, siis õppejõud soovib hindamiseks projekti dokumenti sellises formaadis, et seda saab MS Word programmis avada ja "Split screen" abil vaadata. Projekti pealkirjade struktuur PEAB täpselt vastama mallis ette antud struktuurile. See on vajalik, et oleks võimalik lühikese ajaga suur hulk projekte kiiresti läbi vaadata ja sisukat tagasisidet anda.

## Küsimus: Kus relatsioonilist mudelit peale andmebaaside veel kasutatakse?

**Vastus:**

Relatsiooniline mudel kirjeldab ühte võimalikku viisi, kuidas andmeid andmebaasides organiseerida ning kuidas neid seal kasutada saab ja seega on relatsioonilise mudeli rakendusvaldkonnaks ikkagi andmebaasid.Samas on see mudel, selle väljatöötamine ja selle põhjal loodud andmebaasikeeled andnud kindlasti inspiratsiooni erinevateks teadus- ja arendustöödeks.

Andmemudelite ajalugu algas enne relatsioonilist mudelit, kuid koos relatsioonilise mudeliga saadi aru vajadusest selliste mudelite kirjeldus ka ilmutatult kirja panna. Siin on hea näide, kuidas seda lühidalt ja selgelt teha. Kui mudel on ilmutatult kirja pandud, siis on seda võimalik palju paremini analüüsida ning järjekindlamalt ja täpsemalt realiseerida.
Andmestruktuuride normaliseerimise teooria (see on väga läbitöötatud relatsioonilise andmemudeli korral kuid rakendub ka teistele andmemudelitele) on andnud inspiratsiooni normaliseerimise teooria väljatöötamiseks programmikoodi kohta ja laiemalt üldse mistahes liiki süsteemide kohta (normaliseeritud süsteemide teooria - lugege pikemalt siit, peatükist 6).
Relatsiooniline mudel ja andmetüübid on ortogonaalsed, st relatsiooniline mudel seab väga vähe nõudeid/piiranguid tüüpidele, mida saab kasutada relatsioonilises andmebaasis näiteks atribuutide või parameetrit tüüpidena. Tüüpide loomise keerukus SQLis on pannud mõtlema, milline võiks olla sobiv andmetüüpide süsteem ja kuidas oleks õige tüüpe pärimise kaudu luua. Eesmärgiks oleks süsteem, kus rakenduse ja andmebaasisüsteemi vahel ei oleks nii põhimõttelisi erinevusi, et nende koostööle sundimiseks oleks vaja mingit ORM-i laadset vahekihti.
Relatsioonilise mudeli põhjal loodud reaalne andmebaasikeel - SQL - on vaatamata oma puudustele inspiratsiooniks paljudele uue põlvkonna (NoSQL) andmebaasisüsteemidele deklaratiivse andmebaasikeele väljatöötamise seisukohast. Näiteid:

CQL
N1QL
SPARQL
PGQL




## Küsimus: Millega tuleks arvestada koostöökeskkondade kasutamisel?

**Vastus:**

Sellega, et tegemist on tarkvaraga mille on teinud inimesed. Inimesed on ekslikud ja tarkvaras on vigu. Murphy seaduste kohaselt löövad need välja kõige ootamatumates kohtades ja kõige ebasobivamal ajal. Siiski arvan, et nende keskkondade üldine kasu kaalub üles võimalikud probleemid. Järgnevalt kaks negatiivset kogemust üliõpilaste enda sõnadega.***************"OneDrive ühiselt projekti tegemine võib ahvatlev olla, aga tegelikult võib jamasid tekkida. Meil rollbackis onedrive mingi tundmatu vea tõttu projekti dokumendifaili 40 minuti võrra ning täielikult korruptis EA faili nii, et EA faili avades saime network errori, ning tegime põhimõtteliselt diagrammid nullid uuesti. Minu soov on, et mõnel tudengil tulevikus seda muret ei tekiks"***************Teatele lisatud failis on fragment kolme üliõpilase poolt ühistööna kirjutatud magistritööst. Töö käigus puutusid nad kokku Wordi dokumendi ühise täiendamise probleemidega ja kirjutasid lõpuks oma töösse sellest eraldi alajaotuse.

## Küsimus: Millist töövahendit saaks kasutada PostgreSQL andmebaasi tabelitest graafilise kujutise (kas HTML, pildifail või midagi taolist) loomiseks? Tööriist võiks olla vabavaraline, joosta Linuxi masinal ning ideaalis olla kasutatav käsurealt (et saaks kasutada ka skriptide sees).

**Vastus:**

Kui Teil on andmete modelleerimise CASE vahend, siis see võib toetada pöördprojekteerimist (reverse engineering) olemasolevast andmebaasist.Leidub ka eraldi andmebaaside haldusvahendeid, mis sellist funktsionaalsust pakuvad. Tõstan esile:

DBVisualizer
DBeaver

Mõlema puhul on probleemiks, et visualiseerimise tulemuses ei näidata UNIQUE kitsendusi, CHECK kitsendusi, indekseid, kitsenduste ja indeksite nimesid.DBVisualizeris ei näe lisaks ka NOT NULL kitsendusi. Samuti ei saa seal teha eraldi diagramme andmebaaside erinevate alamosade kohta. DBeaveris on eraldi diagrammide loomine võimalik (Project => ER Diagrams; loodud diagrammile saab lohistada valiku tabelitest)

## Küsimus: Mul on arvutiks Mac / minu arvutil on Linux operatsioonisüsteem. Millist tarkvara soovitate kasutada?

**Vastus:**

Jutt on tarkvarast, mis on seotud kahe põhilise selle aine tegevuste plokiga.

SQLi harjutamine ja lõpuks (kui vaja) kontrolltöö tegemine. Vaikimisi kasutame MS Accessi.
Iseseisva töö projekti tegemine. Vaikimisi kasutame Enterprise Architect (12) või Rational Rose tarkvara.

Need vaikimisi programmid töötavad Windowsil. EA14 näitel näen, et seda saab installeerida ka Maci, kuid see nõuab üsna palju lisatööd. Litsentsi taotlemine (bat failiga) on mõeldud just EA12 jaoks, st seda ei saa kasutada näiteks EA kodulehelt allalaaditud kõige viimasele EA versioonile litsentsi taotlemiseks.Variant 1 - kasutada virtuaalset töölauda
Juhendi leiab SIIT.
Tuleb valida virtuaalne töölaud VDI-andmebaasid.
Lahendus töötab ka väljastpoolt ülikooli. Hetkel ei ole sellisel juhul eelnevalt vaja luua eduVPN ühendust, aga see võib jooksvalt muutuda, kui administraatorid tunnevad, et on vaja lisada eraldi turvakiht.
Teenus töötab vajadusel veebilehitsejas.
Lisaks Windowsile on olemas kliendid nii Linuxile kui Macile ning tegelikult isegi Android ja iOS jaoks.
Samuti saate seda lahendust kasutada, kui olete oma Linux/Mac arvutiga arvutiklassis.NB! Kindlasti on vaja teha vastavalt juhendile ketta jagamine, sest välja logides kustutatakse loodud failid kohe (sh kataloogist PrivatData). Kui sulgete Horizon akna ristist, siis säilivad loodud töölaud ja failid 15 minutit.
EA kasutamiseks peab peale sisselogimist hetke ootama, et skriptifail looks vajalikud registri võtmed selle jaoks. Config Manageri (mille kaudu käib võtmete uuesti laenutamine arvutiklassi arvutis) nendes masinates pole ja Horizoni loomuse tõttu ei hakka ka olema.Variant 2 - kasutada alternatiivset tarkvaraSQLSQLi iseseisvaks harjutamiseks ja osade lisapunkti ülesannete lahendamiseks saaks kasutada  LibreOfficeBase või PostgreSQL andmebaasisüsteeme. Kontrolltöö tegemisel saaks MS Accessi asemel kasutada LibreOffice Base süsteemi.LibreOffice Base kuulub avatud lähtekoodiga LibreOffice kontoripaketi koosseisu, mille allalaadimise koht on SIIN.PostgreSQL (14) on serveris apex.ttu.ee, millele juurdepääsu küsimise kohta on info SIIN.Lisamaterjalide lehel (kasutajanimi: SIS2 ja parool: SIS2) on:

SIIN mõned harjutamise andmebaasid LibreOffice Base jaoks ning ka pisike MS Access ja LibreOffice Base võrdlus,
SIIN SQL laused mõnede harjutamise andmebaaside loomiseks PostgreSQL jaoks.

Iseseisev tööKui tahate teha iseseisvat tööd töövihiku järgi, siis alternatiivse CASE tarkvara kasutamisel tuleb arvestada sellega, et Te ei saa kasutada etteantud diagrammi põhju, vaid need tuleb käsitsi nullist ise teha.Andmete modelleerimiseks soovitan kindlasti kasutada CASE vahendit, mis toetab andmete modelleerimist, mitte joonistusvahendit või andmete modelleerimise toeta CASE vahendit (nt ArgoUML).Andmete modelleerimist toetava CASE vahendi eelis on, et see suudab genereerida andmemudelist SQL koodi ja nii oluliselt suurendada Teie töö kvaliteeti ja tulemuslikkust.  SIIN on nimekiri mõnedest kasutaja arvutisse installeeritavatest tasuta CASE vahenditest ja SIIN on nimekiri mõnedest veebipõhistest tasuta CASE vahenditest.Iseseisva töö prototüüpi ei pea tegema MS Accessis nii et sellega muret ei ole. Saate näiteks kasutada PostgreSQLi, LibreOffice Base jne. Variant 3 - üritada tööle saada WindowsInternetist leiab juhiseid. Panin siia stiilinäiteks ühe juhise Maci ja ühe Linuxi kohta. Windowsi saate Azure Dev Tools for Teaching keskkonnast (sealtsamast, kus saaksite MS Accessi). Kuidas sellele keskkonnale juurdepääs saada on kirjas kataloogis Tarkvara dokumendis Kuidas saada enda arvutisse MS Access (2019)?Variant 4 - veel võimalusiInstalleerida EA12 oma Windowsi lauaarvutisse (tööl või kodus) ning taotleda litsentsi üle eduVPNi. Tehes projekti rühmatööna saate tööd jaotada nii, et visuaalsete mudelite (diagrammide) loomisega tegelevad need projekti osalised, kellel on oma arvutis vajalik tarkvara.Kuna projekti tegemisel on võimalik kasutada töövihiku lahendust, kus suur osa diagrammidest on ette valmis tehtud, siis nende täiendamine ei võta liiga palju aega. Kui taastub osaline kohapealne õppetöö ülikoolis, siis saab õppejõuga kokku leppida, et mõne selle aine praktikumi ajal arvutiklassi kasutada. Kui kohapealne õppetöö on taas lubatud ja klass ei täitu üle 50% ulatuses, siis see on täiesti võimalik. Samuti võib saada kasutada arvutiklasse vabakasutuse korras (nt ICT-405 on vabakasutuses) - selles osas tuleb rääkida ICT-maja neljandal korrusel asuvate arvutiklassi administraatoritega.

**Märksõnad:** kaugkasutus, MSAccess, virtuaalne töölaud, vmware

## Küsimus: PostgreSQL EXCLUDE kitsendus: millal seda kasutada ning miks ilmub see kõikides näidetes fraasi "EXCLUDE USING gist" kujul?

**Vastus:**

EXCLUDE on PostgreSQLi laiendus - SQL standard seda ette ei näe ja teised andmebaasisüsteemid seda ei paku. Kuid see on väga kasulik laiendus. See on UNIQUE kitsenduse üldistus selles mõttes, et unikaalsuse kontrollimisele saab kasutada väärtuste võrdlemiseks ka muid operaatoreid kui =. Näiteks saab selle abil andmebaasi tasemel deklaratiivsel viisil tagada, et tabelis esitatud ajaliste väärtuste perioodid ei oleks osaliselt ega täielikult kattuvad. Näiteks, kui isikule X on määratud roll Y ajaperioodiks 1. jaanuar 2021 kuni 31. detsember 2021, siis ei saa talle seda sama rolli määrata ajaperioodiks 1. märts 2021 kuni 1. juuni 2021 või 1. märts 2021 kuni 31. detsember 2022.  See on "kangem" unikaalsuse kontroll kui UNIQUE (isik_id, rolli_kood, alguse_aeg). EXCLUDE abil saaks kontrollida ka tavalist unikaalsust, kuid kontrolli töökiiruse (aeglasem kui tavalise UNIQUE kontroll) ja porditavuse (teistesse süsteemide ülekandmise) mõttes pole see hea lahendus. EXCLUDE kitsenduse abil saab realiseerida ka kontrolle, mida muidu tuleks teha (osaliselt) unikaalse indeksiga.

Tõstutundetu unikaalsus. Näiteks kui tabeli Isik veerus e_meil on juba mingis väljas aadress 'kask@hot.ee', siis ei saa sinna tabelisse lisada aadressi 'Kask@hot.ee'.
Osaline unikaalsus. Näiteks, aktiivses seisundis kaupade nimetused peavad olema unikaalsed. Kui kaup ei ole aktiivses seisundis, siis selle nimetus ei pea olema unikaalne.

Unikaalsuse kitsenduse kontrollimise toetuseks loob PostgreSQL automaatselt B-puu tüüpi indeksi. Kujutage ette, mis juhtuks ilma indeksita - tabelis on miljon rida, tabelisse lisati uus rida, reas oleva väärtuse unikaalsuse kontrollimiseks tuleks süsteemil kõik need read läbi vaadata. Ka EXCLUDE kitsenduse toetuseks vajab andmebaasisüsteem indeksit. Arvestades võrdluseid, mida süsteem peab EXCLUDE kitsenduse täidetuse kontrollimiseks läbi viima, ei sobi B-puu tüüpi indeks, vaid sobib indeks tüüpi GIST. SIIN on EXCLUDE kitsenduse kasutamise koodinäiteid.


---

# Teema: Õppekeskkond

## Küsimus: Kas iseseisva töö juhendis ja näiteprojektis on võimalik mugavalt erinevate alamosade vahel liikuda?

**Vastus:**

Jah on.Nendes pdf failides on järjehoidjad (bookmarks), mis võimaldavad dokumendis erinevate alamosade vahel hõlpsasti navigeerida. Kahjuks, sõltuvalt kasutatavast veebilehitsejast, ei ole see alati automaatselt esile tõstetud. Kui vaatate neid faile Firefoxi veebilehitsejas, siis on need järjehoidjad lehe vasakus servas kohe näha.Kui vaatate neid faile Chrome veebilehitsejas, siis tuleb lehe vasakust servast valida jaotis Dokumendi liigendus.Kui vaatate neid faile Edge veebilehitsejas, siis tuleb lehe vasakust ülaservast valida Sisukord.Kui vaatate neid faile Opera veebilehitsejas, siis tuleb lehe vasakust servast valida jaotis Document outline.Chrome, Edge ja Opera puhul tuleb kõige kõrgema taseme pealkirjale klõpsata, et näha selle all olevaid alampealkirju.Vastusele on lisatud illustreerivad pildid.

**Märksõnad:** navigeerimine, järjehoidja

## Küsimus: Kuidas ennast kodulehele registreerida?

**Vastus:**

Lehele ligipääsemiseks tuleb ennast registreerida.

Kui kasutate https://maurus.ttu.ee keskkonda esmakordselt, siis valige õppeaine lehelt menüüst Üldist=> Lehele registreerumine. Täitke vorm ja vajutage nupule "Registreeri".
Kui juba olete õpikeskkonnas mingile lehele registreerunud (vahet pole, kas üks või kümme aastat tagasi), siis valige Mauruse esilehel menüüst Üldist=>Minu konto ja lisage enda aktiivsete lehtede hulka: "Andmebaasid I (ITI0206) (kevad 2021)" Ärge unustage vajutada "registreeri".

Kui olete unustanud parooli, siis SIIN saab seda nullida.
Kui Te ei mäleta kasutajanime/meiliaadressi, siis pöörduge õppejõu poole!



Registreerumise järel peate ootama kuni õppejõud Teie juurdepääsu õiguse kinnitab. Kinnitamise kohta saadab süsteem automaatselt meili.
Palun vaadake üle oma konto andmed ning registreerige seal selline meiliaadress, mida Te igapäevaselt loete. Sellele aadressile hakkab saabuma aine korralduslik ja muu info. Seda võib vaja minna õppejõul, et Teiega ühendust võtta.

## Küsimus: Kus on kodulehel jooksvad tulemused?

**Vastus:**

Klõpsake Kiirvalik=>Tulemused (link on nähtav ainult siis, kui on avaldatavaid tulemusi).

**Märksõnad:** punktid, lisapunktid, vahetest, vahetestid

## Küsimus: Kus on kodulehel loengute lindistused?

**Vastus:**

OTSEVIIDE Echo lindistuste lehele. Seal pole paraku loengute annotatsioone (Echo keskkond laseb küll videoid kirjeldada, kuid ei näita seda infot vaataja õigustes kasutajale). Selle lingi avamiseks saate ka menüüst valida Kiirvalik=>Loengute lindistusSIIN on lisaks loengute annotatsioonid.

**Märksõnad:** loengud, loeng, echo, lindistus, lindistused, salvestus, salvestused, video, videod

## Küsimus: Materjale on liiga palju! Kuidas tulla toime suure materjalide hulgaga?

**Vastus:**

Kõiki materjale ei pea sugugi lugema. Te saate valida kolme materjalide kasutamise taseme (õpiraja) vahel. Valige tase vastavalt oma huvidele ja eesmärkidele.Tase 1

Neile, kellele piisab "läbi saamisest".
Loe ainult materjale: Kiirvalik => Tutvu igal juhul!

Materjalid korralduse ja projekti kohta.
SQL andmebaasikeele ning teooria kohta leiab materjali väga paljudest allikatest.
Teooria testideks saab valmistuda harjutuskeskkonnas harjutades.



Tase 2

Neile, kes soovivad õpiväljundid heatasemeliselt saavutada.
Loe igal nädalal materjale: Kiirvalik=>Nädala materjalid

Igal nädalala jaoks kõige olulisemad materjalid.
Pööra tähelepanu ka materjalide juures olevatele seotud dokumentidele.
Lisaks on iga nädala kohta välja toodud soovitavad tegevused seoses ainega (nädalate peale kokku moodustab õppimise tegevuskava).



Tase 3

Neile, kes soovivad süveneda ja saada põhjalikke teadmisi.
Lisaks nädala materjalidele lugege ka muid materjale (alajaotis Materjalid) ning kasutajatoe küsimusi ja vastuseid (Abi => Kasutajatugi).

Nädala materjalide juures on viited seotud dokumentidele ja lähedastele materjalidele.


Kasutage otsingut!


**Märksõnad:** Maurus, materjalid, kuidas õppida, õpirada, fail, failid

## Küsimus: Miks me ei kasuta õppekeskkonnana Moodlet?

**Vastus:**

Jah, see on kindlasti üks võimalus. Siiski on minu hinnangul Mauruse keskkonnal Moodle ees eeliseid. Järgmised võimalused on Mauruses, kuid puuduvad Moodles.

Loodetavasti kiirem reageerimine funktsionaalsuse või kasutajaliidese muutmise soovidele.
Üliõpilastele säilib juurdepääs õppeaine kodulehele ning seal olevatele materjalidele ka peale aine uue õpetamiskorra algust. Isegi kui koduleht on Mauruse pealehelt eemaldatud, pääseb sellele endiselt ligi kas otseviitega või läbi pealehelt avaneva Minu konto alajaotuse. Hakates uuel semestril õppeainet uuesti õpetama loon Mauruses uue kodulehe (vana säilib) ning saan sinna enda valikul vanalt kodulehelt informatsiooni kopeerida. Moodles seevastu on õppeaine uuel semestril õpetama hakkamisel esimeseks sammuks kõikide lehele registreerunud üliõpilaste kustutamine. Ka Mauruses saab õppijatelt võtta juurdepääsu õppeaine kodulehele, kuid see on õppejõu otsus, mitte keskkonnast tulenev paratamatus.
Materjale saab kasutaja jaoks grupeerida mitmel erineval viisil. Selleks on kataloogide hierarhias paiknevatele. materjalidele pealisehitusena lisatud vaadete mehhanism (vt menüüd Vaated materjalidele), mis võimaldab materjale kasutaja jaoks erineval viisil grupeerida. Vaade Kiirvalik=>Nädalate kaupa võimaldab välja tuua konkreetsel õppenädalal kõige olulisemad materjalid. Sisuliselt on nädala vaade selle nädala tegevuskava. Üks ja sama materjal võib olla seotud mitme nädalaga. Arendajatel on lihtne vajadusel uusi vaateid lisada.

Analoogia: Kui materjalide all olev kataloogide hierarhia on nagu hierarhiline dokument dokumendipõhises andmebaasis (nt MongoDB abil loodud), siis vaated materjalidele on nagu selle dokumendi põhjal loodud (mitte-materialiseeritud) vaated. MongoDB toetab selliste vaadete loomist alates versioonist 3.4.


Õppejõud saab esile tõsta, millised materjalid on kohustuslikud (peaks igal juhul lugema) ja milliseid võib aja või huvipuudusel lugemata jätta. Kohustuslikud materjalid on erinevates vaadetes ühtemoodi esile tõstetud ja on lisaks koondatud vaatesse Kiirvalik=>Tutvu igal juhul!
Vaadete kasutamise eelis seisneb ka selles, et materjale ei ole vaja dubleerida. Sama materjal võib olla erinevates vaadetes. Miks see on õppija jaoks tähtis? Kui materjale on vaja täiendada/täiustada, siis õppejõud peab seda tegema ühes kohas. Sellega:

tagatakse muudatuste võimalikult kiire tegemine (lugejani jõuab kõige viimane ja kõige täpsem info võimalikult kiitesti),
välditakse olukorda, kus samast materjalidest on õppekeskkonna erinevates osades mittekooskõlalised koopiad. Näiteks moodulis 1 on materjal, mis ütleb, et kontrolltööks tuleb lugeda A ja B kuid moodulis 2 on materjal, mis ütleb, et kontrolltööks tuleb lugeda A, B, C ja D.

NB! Samad eelised on vaadetel ja andmete dubleerimise vältimisel ka andmebaaside maailmas.

Kasutaja saab vaadata (alajaotus Isiklik) enda kõige viimati vaadatud faile või enda kõige rohkem vaadatud faile ja niimoodi leida kiiresti üles materjali, mida ta kunagi on juba vaadanud.
Kasutajatel on võimalus teha otsing üle aine sisu kirjelduse, materjalide metaandmete, tegevuskava, teadete (v.a isiklikud teated), kasutajatoe küsimuste/vastuste, mõistete, viidete, tähaegade, ülesannete (kuid mitte nende vastused) ja vastuvõtuaegade. Näen, et otsingut kasutatakse palju.
Süsteemis kogutud info tehtud otsingute kohta annab õppejõule võimaluse materjalide annotatsioone täiendada, et samasuguse otsingu tulemused oleksid edaspidi täpsemad.
Materjalidele ja kasutajatoe küsimustele/vastustele saab lisada põhjaliku annotatsiooni, mida kasutaja vaikimisi ei näe, kuid mida kasutatakse eelmises punktis nimetatud otsingus.
Võimalus panna välja suurel hulgal individuaalseid projektide ettenäitamise aegu (st üliõpilased ei pea tulema kaitsmise sessiooni alguseks kohale ja seal elavas järjekorras ootama).
Võimalus tagada, et projekti mitmekesi tegijad, ei saaks broneerida mitu ettenäitamise aega ja välistada sellest tulenev ebaõiglus nende suhtes, kes teevad projekti üksinda.
Kasutajatugi ning võimalus seal olevaid korduvaid küsimusi avalehele kinnitada ning küsimusi/vastuseid kõigile üliõpilastele meilile saata (sh korduvalt). Võimalus muuta avalehel näidatavate korduvate küsimuste järjekorda ning hulka. Võimalus neid küsimusi esile tõsta.
Võimalus valida, millised teated saadetakse üliõpilasele meilile ja milliseid mitte (vähem ebaolulisi meile).
Võimalus valida, milliste kalendri sündmuste meeldetuletused ainele registreerunute meilile saata ja millised mitte.
Nii üliõpilasel kui õppejõul on võimalik saada kiiresti ülevaade, millisele teadmiste kontrollile on veel vabu kohti ja millisele mitte. See on väga oluline olukorras, kus on väljas näiteks 10 SQL kontrolltöö või vahetesti aega või 50-100 projekti näitamise aega.
Üliõpilane ei saa sama tüüpi teadmiste kontrollile olla samaaegselt mitmekordselt registreeritud. See aitab tagada, et vabu kohti ei hõivataks ilmaasjata ning et neid jätkuks suuremale hulgale soovijatele.
Õppejõul on võimalus saata meeldetuletus kõigile üliõpilastele, kes mingit tüüpi teadmiste kontrollile ei ole veel registreerunud (on selle unustanud või mäletavad ekslikult, et registreerisid, kuid tegelikult ei teinud seda).
Kui projekt on arvestatud ja üliõpilane paneb ennast uuesti projekti näitamisele kirja või unustab varem tehtud registreerimise tühistada, siis saan päringuga selle üles leida ja operatiivselt sellise registreerimise tühistada. Vabad ettenäitamise ajad on oluline ning projektide näitamiste tippajal paljudele huvi pakkuv ressurss.
Õppejõud saab kasutajate jaoks materjale ja katalooge esile tõsta nii, et tulemus tõepooles ülejäänud materjalidest ja kataloogidest visuaalselt eristub.
Saab teha nii, et lingi alusel materjali (faili) allalaadides ei pea kasutaja ennast tuvastama - teiste sõnadega materjali saavad kasutada kõik, kes teavad linki.
Võimalik loengu otseülekande toimumise ajal seda kodulehe avalehel esile tõsta.
Eesti- ja ingliskeelse terminoloogiaga mõistete sõnastik, mis on integreeritud materjalidega ja pakub täiendavaid märksõnu mille alusel otsing leiab üles olulisi/vajalikke materjale.
Üliõpilased ja õppejõud näevad, millised materjalid on lugemata ja kuidas edeneb üliõpilastel materjalidega tutvumine võrreldes teiste üliõpilastega.

Annan ka teada, et Mauruses ei salvestata paroole avatekstina.

**Märksõnad:** Moodle, e-õpe, e-tugi,e-kursus

## Küsimus: Miks on nii, et Mauruse testikeskkond näitab, et vastamise lõpetamiseni on veel aega, kuid tegelikult on aeg täis?

**Vastus:**

Arvuti kell jääb maha. Siin kirjeldatakse selle mõningaid põhjuseid Windowsi korral. Sarnane probleem esineb ka Mac arvutites.

## Küsimus: Millisel viisil saab esitada soove selle kohta, kuidas muuta andmebaaside õppeaine koduleht Mauruses paremini kasutatavaks ja materjalid kergemini ülesleitavaks?

**Vastus:**

Soovid saab kirja panna SIIA (anonüümselt). Ma olen sealt saanud häid ideid, mille alusel olen kodulehte ja materjale parandanud. Tänan juba ette konstruktiivsete ettepanekute eest!

**Märksõnad:** tagasiside, Maurus, anonüümne, kasutatavus, funktsionaalsus