# Teema: Andmebaasi kavandamine

## Küsimus: Kas andmete andmebaasi tasemel valideerimine (eelnevalt defineeritud reeglitele vastavuse kontrollimine) on hea mõte või mitte?

**Vastus:**

Väide: Kui rakenduse tasemel andmeid valideeritakse, siis andmebaasi tasemel pole seda enam vaja teha, sest see on liiga keeruline. Vastus: Kõik sõltub sellest, kui oluliseks andmete korrektsust peetakse. Muidugi ei taga kontrollid, et andmed on alati sisuliselt õiged, kuid need aitavad vähendada andmebaasi sattuvate ebaõigete andmete hulka. Kui kontroll realiseerida n rakenduses (mida on pidevalt vaja edasiarendada), mis on tehtud m firma poolt (igaühel oma CASE vahendid, dokumenteerimise standardid ja tavad - probleem: kuidas neile kitsenduste olemasolu kõige paremini kommunikeerida) kasutades y erinevat keelt ja kus on z vormi mille kaudu saab andmeid muuta ning kõigele lisaks on veel g skripti, mis laadivad andmebaasi regulaarselt uusi andmeid, siis kontrolli veelkordne teostamine andmebaasi tasemel ei tundugi enam nii suur täiendav pingutus - pealegi kui sellest tõuseb olulist täiendavat kasu.
Teemast hetkeks kõrvale kaldudes - deklaratiivsete reeglite jõustamine pole suurem pingutus kui Java koodi kirjutamine. See võib olla pingutus indiviididele, kes kahe tabeli ühendamise päringu kirjutamiseks peavad pool tundi googeldama. Siinkohal on abiks oma tööjõu parem valimine ja koolitamine. Elav klassik hr Leo Võhandu on öelnud, et umbes 1/3-le inimestest on võimatu deklaratiivset, hulkade töötlemisel põhinevat keelt korralikult selgeks õpetada - nad ei saa sellest aru ja ei hakkagi kunagi korralikult aru saama. Õpetamise praktikuna võin seda väidet kinnitada.
Andmebaasi taseme kontrollidest pole võimalik meelega mööda hiilida või kogemata "mööda tuigerdada".
Ma ei ole kindlasti andmete rakenduse tasemel valideerimise vastu, sest see võimaldab anda kasutajale kiiremat ja selgemat tagasisidet ning vähendada võrguliiklust, sest leitud ebakorrektseid andmeid ei hakata üle võrgu saatma. Kuid kaitse (kui kaitstavat objekti tahetakse tõesti kogu hingest kaitsta) peaks olema mitmekihiline - kui üks kiht veab alt, siis on veel vähemalt üks kiht, mis löögi vastu võtab ja tagasi põrgatab. Autol panete uksed lukku, panete eraldi rooliluku panete kõigele lisaks veel signalisatsiooni peale. Mõni jätab isegi kurja koera autosse. Keegi ei tule selle pealegi, et seda oleks "liiga palju". Kui rakenduses x jäi vormile y kontroll peale panemata, siis testimisel tekib veateade ja kohe on selge, et vormi juures on jäänud midagi tegemata.
Möönan, et kitsenduste kontrolli realiseerimine lisaks andmebaasile ka rakendustes tähendab lisatööd ja dubleerimist. Kontrolliloogika dubleerimisega tekivad samad probleemid kui andmete liiasusega - muudatusi tuleb teha mitmes kohas (st tööd on rohkem) ning kui muudatusi ei tehta kõigis vajalikes kohtades, siis tulemuseks on süsteemi erinevate osade vastuoluline käitumine.
Lisaks andmete valideerimisele on veel põhjuseid, miks andmebaasi tasemel deklareeritud kitsendused osutuvad kasulikuks. Möönan, et järgnevate võimaluste kasutuselevõtu osas on tänapäeva tarkvarasüsteemidel veel palju ära teha.

Andmekäitluskeele lausete (päringud ja andmemuudatused) optimeerimine ja automaatne lihtsustamine. Eesmärgiks on saavutada lausete kiirem täitmine. Kitsendused annavad andmebaasisüsteemile infot andmebaasis olevate andmete tähenduse kohta ja selle info alusel saaks andmebaasisüsteem asendada nii mõnegi käivitatava lause oluliselt lihtsama kuid semantiliselt samaväärse lausega. Sellise semantilise teisendamise esimeseks pääsukeseks on tabelite elimineerimise teisendus, mida muuhulgas toetavad PostgreSQL ja Oracle.
Arendussüsteemides, mille puhul genereeritakse rakendus andmebaasi põhjal (nagu näiteks Oracle APEX), saaks põhimõtteliselt teha nii, et andmebaasi tasemel jõustatud ja süsteemikataloogis talletatud kitsenduste põhjal luuakse automaatselt rakenduse kood, mis samuti kitsenduse täidetust kontrollib. Näiteks APEX puhul võiks automaatselt tekkida tabeli alusel loodud lehega seotud Valideerimised (validations). Omaette keerukus tõuseb muidugi sellest, kuidas taolises olukorras kitsenduste muudatusi sünkroniseerida.
Kitsendused aitavad andmebaasisüsteemil mõista andmete tähendust ja aitavad seda teha ka arendajatel. Sisuliselt dokumenteerivad need andmetele esitatavaid nõudeid - see on eriti kasulik olukorras kus dokumentatsiooni peaaegu ei ole või on sellel lastud vananeda.
Samuti annavad kitsendused olulist infot, mille alusel otsida andmebaasi skeemist automaatselt mitmesuguseid disainivigu (näiteks erinevate SQL-andmebaasi disaini antimustrite esinemisi). Vigu saab otsida päringutega andmebaasi süsteemikataloogi põhjal.
Kui rakenduse lähtekood on suletud ja sellesse ei ole võimalik muudatusi teha või kui tegemist on pärandkoodiga, mida keegi ei oska/taha muuta, siis on andmebaasi tasemel jõustatud kitsendused viis, kuidas täiendavaid andmete kontrolle ikkagi süsteemi sisse viia.

Väide: Andmebaasis kontrollide realiseerimine on liiga keeruline. Vastus: Tõsi - kui kasutada trigereid keerukamate reeglite kontrollimiseks, siis on nendesse lihtne teha vigu nii, et teatud olukorras laseb kontroll läbi ebakorrektseid andmeid. Samu vigu saab muide teha ka rakenduses. Deklaratiivsete kitsenduste puhul selliseid probleeme ei teki, sest ütlete süsteemile mida on vaja kaitsta ning süsteem ise valib parima algoritmi kuidas kontrolli läbi viia. See, et tänapäeva SQL-andmebaasisüsteemid ei võimalda luua üldiseid deklaratiivseid kitsendusi (CREATE ASSERTION) on minu hinnangul üks tänapäeva SQL-andmebaasisüsteemide suuremaid puuduseid. Abi on generaatorsüsteemidest nagu RuleGen.
Väide: Andmete valideerimine andmebaasi tasemel on halb, sest muudatuste sisseviimiseks peab andmebaasi töö peatama. Vastus: Võimalused nagu näiteks Online Table Redefinition ja Edition-Based Redefinition aitavad seda probleemi leevendada. Tänapäeva andmebaasisüsteemid võimaldavad kitsendusi kiiresti sisse ja välja lülitada ning sama saab teha trigeritega. Olen nõus, et paljugi on veel vaja ära teha. Samas mõelge ka sellele, et kitsendus, mille jõustate andmebaasis, jõustub kohe loomise järel ja rakendub kõigile andmemuudatustele sõltumata sellest, millisest allikast (rakendusest, skriptist, administreerimise programmist) need pärinevad. Kas see kui jõustatava reegli muutumise tõttu tuleb korraga asendada kõik rakendused uue versiooniga on kuidagi olemuslikult lihtsam ja parem? Kas see kui erinevates sama baasi kasutavates rakendustes on realiseeritud erinevad versioonid andmete kontrolli reeglitest (üks rakendus leiab, et isikukood peab olema Eesti isikukood; teist rakendust on juba uuendatud ja see lubab Eesti ning Läti isikukoode) on olemuslikult hea? Toodi näide selle kohta, et on vaja hakata registreerima ka Läti ja Leedu isikukoodiga isikuid. Kena! Andmebaasist kitsenduse kustutamine või kitsenduse väljalülitamine võtab vaid hetke. Kas tõesti leiate, et sama asja tegemine m rakenduse z vormis ja lisaks veel g skriptis võtab sama vähe aega?!
Ma võin andmebaasis muuta tabelite struktuuri ja see, et mõne kitsenduse rakenduse tasemel kontroll seetõttu enam ei toimi tuleb välja alles testimisel. Samas andmebaasis on andmebaasiobjektide vahelised seosed andmebaasisüsteemi jälgimise all, info nende kohta on süsteemikataloogis ja a) süsteem ei lase mul teha struktuurimuudatusi, mis viivad mõne teise objekti ebakorrektsesse seisu või b) ma saan nende seoste kohta vähemalt süsteemikataloogist päringutega infot otsida.
Väide: Andmete valideerimine andmebaasi tasemel mõjub halvasti jõudlusele. Vastus: Suure hulga andmete tabelisse laadimisel on sõltuvalt süsteemist võimalik kitsendusi ajutiselt välja lülitada ning laadimise lõppedes uuesti sisse lülitada. Kui Teil on ühe tabeli mitut rida või mitme tabeli ridu hõlmavad kontrollid (näiteks välisvõtme kitsenduse kontroll), siis selle rakenduse tasemel realiseerimine tähendab ikkagi päringuid baasi vastu, vajadusel andmeelementide lukustamist. Mille alusel arvatakse, et selline lahendus on kuidagi jõudluse poolest parem?!
Andmebaaside lisamaterjalide kodulehel on lõputöö Ärireeglite realiseerimine PHP ja PostgreSQLi abil. Tsiteerin selle töö lõppjäreldusi: "Nende uuringute tulemuste põhjal jõuti järeldusele, et enamuse ärireegli tüüpide realiseerimise puhul on PostgreSQLi kasutamine realisatsiooniks mõistlikum, mis tähendab, et kood on seal lihtsam, kompaktsem ja muudatuste sisseviimisel mugavam. Ka süsteemi töökiirus ärireegli kontrolli läbiviimisel ja realiseerimisel oli suurem. Vigade parandus oli PostgreSQLi puhul tihtipeale kergem, kuid mõningatel juhtudel ei olnud mõlemad süsteemid võimelised arusaadavalt vea põhjust kuvama. Muudatuste sisseviimine on andmebaasi tasandil kergem selles osas, et siis ei pea muutmist vajavat kohta kaua otsima ning pole vaja ka rakendust toimingusse kaasata: kõik muudatused saab andmebaasis ära teha. Lisaks pakub andmebaas palju võimalusi ärireeglite realiseerimiseks, mida PHPs teha ei saa: vaated, domeenid, klassist klassi pärimine (disjoint), trigerid ja muud. Ainult realisatsiooni arendamise käigus kasutatud abiinfo maht oli mõlema realiseerimisviisi puhul piisav ning ka kood oli üldiselt arusaadav."
Paljud andmebaasirakendused on veebirakendused. Nende vastu suunatud levinud rünnakumeetodiks on skriptisüstimine. Ründaja üritab anda veebirakendusele sisendi, et veebilehitseja hakkaks rakenduse kasutamisel käitama tema soovitud koodi. Halva tagamõttega sisend võib tulla nii lõppkasutaja poolt vormidesse sisestatult, kui ka andmebaasist, kus keegi on teinud pahatahtlikke andmemuudatusi. Vastumeetmed andmebaasi tasemel on:

sisendi valideerimine (SQL-andmebaasis veergudel sobivad tüübid, CHECK kitsendused),
vaba teksti väljade hulga vähendamine (SQL-andmebaasis klassifikaatori tabelid, välisvõtme kitsendused).

Need on üks osa suuremast meetmete hulgast. Lugege (PHP) veebirakenduste sisendi valideerimise kohta täpsemalt siit.
Kitsenduste andmebaasi tasemel deklaratiivsele jõustamisele tuleks mõelda kohe andmebaasi loomisel, mitte tagantjärgi. Deklaratiivset kitsendust ei saa andmebaasis luua (sõltuvalt andmebaasisüsteemist), kui andmebaasis juba olemasolevad andmed ei ole sellega kooskõlas. Kui luua alguses deklaratiivsete kitsendusteta andmebaas ja üritada hiljem deklaratiivseid kitsendusi lisada, siis võite põrkuda probleemiga, et andmebaasi on juba sattunud valideerimata andmeid ja mingit kitsendust ei saa luua. Selliste andmete andmebaasi sattumise põhjuseks võivad olla näiteks:

vead rakenduste töös,
rakenduste programmeerijate teadmatus ärireeglitest, mida peab andmete tasemel jõustama,
lõppkasutaja hooletus.

Siis on valikud:

Hakata olemasolevaid andmeid parandama (võtab aega; sageli pole enam kelleltki küsida, millised peaksid olema paremad andmed). Parandamise järel saab jõustada deklaratiivsed kitsendused.
Kui andmebaasisüsteem lubab, siis kasutada võimalust viia deklaratiivsed kitsendus seisundisse, mille kohaselt kontrollitakse uusi andmeid, kuid mitte andmebaasis juba olemasolevaid. Oracles tuleb selleks kitsendus viia seisundisse ENABLE NOVALIDATE ning PostgreSQLis seisundisse NOT VALID.
Loobuda ühe või teise kitsenduse deklaratiivsest jõustamisest ning realiseerida kontroll kas andmebaasi tasemel rutiinides või trigerites või üldse ainult rakenduses.

Lahendused 2 ja 3 võimaldavad jätta andmebaasis olemasolevad andmed selliseks nagu need on, kuid vähemasti kontrollida uusi andmeid. Kuna andmed on aluseks otsustele ja peaksid olema seega võimalikult täpsed, siis soovitan lahendusi 2 ja 3 nagu esmaabi, peale mida tuleks ikkagi jätkata punktis 1 toodud soovituse elluviimisega.
Lõpetuseks - tänapäeval on populaarsust kasvatamas ärireeglite mootorid. Nende kasutamisel on sama eesmärk, mis kitsenduste andmebaasis defineerimisel - võtta süsteemi tööd juhtivad reeglid tarkvarast välja ning muuta need reeglid tsentraalselt hallatavaks. Reeglite muutmine mõjutab kõiki nende reeglite alusel töötavaid rakendusi.
Kokkuvõttes ma jään enda juurde - kitsenduste andmebaasi tasemel jõustamine on kasulik. Alati on erandeid, aga need kinnitavad reeglit erandiga mitte kaetud juhtudel. Lugege palun lisaks seda artiklit!
Mõttearendus andmebaasisüsteemi võimaluste kasutamise kohta PostgreSQL näitel.
2017. aastal avaldati teadusartikkel andmebaasirakenduste vastu suunatud ründemeetodist ACIDRain. See on ründemeetod, mis kasutab ära rakenduste nõrkust, mille korral saab rakendust manipuleerida nii, et selle antud korralduste alusel hakkab andmebaasisüsteem koostama mitteserialiseeritud tööplaane. Nende tööplaanide läbimise tulemusena satuvad andmebaasi olulised andmed, mis ei ole kooskõlas kitsendustega (invariantidega).
Warszawski, T., Bailis, P., 2017. ACIDRain: Concurrency-related attacks on database-backed web applications. In Proceedings of the 2017 ACM International Conference on Management of Data. ACM. pp. 5–20. [WWW] http://www.bailis.org/papers/acidrain-sigmod2017.pdf
Autorid uurisid 12 e-kaubanduse programmi, mida on kokku installeeritud üle kahe miljoni korra. Üle 60% miljonist kõige populaarsemast e-kaubanduse keskkonnast kasutavad ühte nendest programmidest. Uuring tuvastas nendes programmides kokku 22 kriitilist haavatavust, mida saab ACIDRain rünnakuga ära kasutada. Näiteks saab ründaja kasutada kinkekaarte üle etteseatud limiidi ja osta e-poest tasuta kaupu. ACIDRain rünnakute vältimises peavad arendajad tundma transaktsioone, lukustamist, transaktsioonide isolatsioonitasemeid ning oskama neid õiges kohas ja õigel viisil kasutada.
Väidan, et paljud (kui mitte kõik) nendest haavatavustest ei oleks probleemiks, kui andmebaasi tasemel oleksid jõustatud deklaratiivsed kitsendused. Siis ei saa tekkida probleemi, et rakendustes on tulenevalt nende kitsenduste kontrolli ebapiisavast/halvast realiseerimisest võimalik nendest kitsendustest mööda minna. Enamike selliste kitsenduste deklaratiivseks andmebaasi tasemel jõustamiseks oleks vaja SQL-andmebaasides kasutada CREATE ASSERTION lauset, sest nende kitsenduste kontroll hõlmab sama tabeli erinevaid ridu või mitut tabelit. Kuigi CREATE ASSERTION lause on SQL standardis ette nähtud, ei toeta seda hetkel mitte ükski laiatarbe SQL-andmebaasisüsteem.
Siin kirjutatakse kitsendustest PostgreSQL andmebaasisüsteemi näitel. Siin kirjeldatakse konkreetsete näidete varal, kuidas kitsenduste andmebaasis jõustamine aitab rakendusi lihtsustada.

**Märksõnad:** triger, kitsendus, constraint, trigger, primaarvõti, välisvõti, unique, primary key, foreig key, check, not null

## Küsimus: Kas oleks mõistlik hoida andmebaasis asukoha andmeid aadressi ja riigi kombinatsiooni asemel koordinatidena? Kui jah, siis mis oleks sobivaim andmetüüp selleks(nii Oracles kui Postgresis)?

**Vastus:**

Kõik sõltub sellest, millisel otstarbel on plaanis neid andmeid kasutada.
Kui tegemist on taustainfoga, mille alusel ei tehta täpseid otsinguid ja mida võibolla trükitakse kirjadele/arvetele, siis piisab veerust aadress. Tõstaksin riigi "sulgude ette" nii, et tabelis on aadressiandmete jaoks kaks veergu: aadress ja riigi_kood. riigi_kood on välisvõtme veerg, mis viitab klassifikaatori tabelile Riik. Tabelis Riik olevad andmed oleksid määratud rahvusvahelise klassifikaatoriga. http://kirste.userpage.fu-berlin.de/diverse/doc/ISO_3166.html
Kui soov on teha aadressi alusel täpseid otsinguid, siis tuleb aadress "lahti lõhkuda" ning tükid erinevatesse tabelitesse/veergudesse salvestada. See pole triviaalne ülesanne. Näiteks Eestis on kasutusel kaheksa-tasemeline aadressiandmete süsteem (https://geoportaal.maaamet.ee/est/Andmed-ja-kaardid/Aadressiandmed-p112.html), mille tehnilist spetsifikatsiooni saab lugeda siit: https://geoportaal.maaamet.ee/docs/aadress/ADS_spetsifikatsioon_22_10_2012.pdf
Aadressikomponentide tasandid on seal jaotises "2.2.3.1 Aadressikomponentide tasandid".
Kuna erinevates riikides on haldusjaotuse põhimõtted erinevad, siis on seal ka aadresside komponendid erinevad. Eesti aadressiandmete süsteemi andmemudelit näete selle dokumendi https://geoportaal.maaamet.ee/docs/aadress/ADS_spetsifikatsioon_22_10_2012.pdf jaotises 2.4O'Reilly digitaalse platvormi kaudu saab lugeda raamatut Blaha, M., 2010. Patterns of Data Modeling.Kuidas kasutada O'Reilly digitaalset platvormi?
Peatükis 10 käsitletakse andmete modelleerimise arhetüüpe ning üks nendest on "Location" (jaotis 10.12). Eesti keele seletava sõnaraamatu kohaselt on arhetüüp "inimkonna kollektiivsest alateadvusest lähtuv püsistruktuur, mis teadvuses avaldub universaalse motiivi v. kujundina".
Muinasjuttudele mõeldes on arhetüübiks näiteks noorim vend, kes lõpuks tapab lohe ning saab tasuks printsessi tähelepanu ja pool kunigriiki.
Koordinaatide hoidmisel on mõtet, kui tahate näiteks asukohti kaardil kujutada. Andmebaasis koordinaatide ja koha-aadresside hoidmine ei välista teineteist. Nii Eesti aadressiandmete süsteem kui "Location" arhetüüp näevad ette ka ruumiandmete hoidmist koordinaatidena.
Mis puudutab sobivaid veerge ja tüüpe, siis see sõltub kasutatavast koordinaatide süsteemist.
Näide: https://twcc.fr/
PostgreSQL ja Oracle on mõlemad objekt-relatsioonilised süsteemid ning lubavad defineerida uusi tüüpe - miks mitte ka geograafiliste koordinaatide jaoks. PostgreSQLis on mõned geomeetrilised tüübid/operaatorid süsteemi-defineeritud ja ilmselt õnnestub ka neid koordinaatide esitamiseks kasutada: https://stackoverflow.com/questions/1023229/spatial-data-in-postgresql Saate esitada ruumilise asukoha Point tüüpi väärtusena.
Kui see ei sobi ning peaksin hoidma pikkus ja laiuskraade kümnendmurruna, siis kasutaksin DECIMAL(10,6) - PostgreSQL NUMBER(10,6) - Oracle. Lisaks on vaja CHECK kitsendusi. Pikkuskraad peab olema vahemikus -180 ja 180 (otspunktid kaasa arvatud) ja laiuskraad vahemikus -90 ja 90 (otspunktid kaasa arvatud).
Kui peaksin hoidma kraade, minuteid ja sekundeid, siis võtaks iga selle komponendi jaoks kasutusele täisarvu tüüpi veeru. Jällegi oleks vaja ka CHECK kitsendusi, sest näiteks 300 kraadi idapikkust ei ole õige asi.
Lugege ka: https://stackoverflow.com/questions/6665894/what-is-the-best-way-to-store-geographic-coordinate-data-in-a-database
Nii PostgreSQLi kui Oracle jaoks on olemas laiendused geograafiliste andmetega töötamiseks, kuid nendega ma kahjuks tuttav ei ole. PostgreSQL: PostGis (http://postgis.net/) Oracle: Oracle Spatial and Graph (https://docs.oracle.com/database/121/SPATL/toc.htm)

## Küsimus: Kas uuendatavate vaadete (vaated, mille kaudu andmebaasisüsteem põhimõtteliselt lubaks INSERT/UPDATE lauseid käivitada) puhul on ikka vaja WITH CHECK OPTION kitsendust kasutada?

**Vastus:**

Jah on. 
Näiteks, kui juhataja rollis kasutaja näeb sellise vaate kaudu kinnitamata tellimusi, siis saaks ta ilma selle kitsenduseta käivitada lause:

UPDATE kinnitamata_tellimuste_vaade SET tellimuse_seisundi_kood=3 WHERE tellimuse_kood='XX';

Selle tulemusena kaob tellimus XX kinnitamata tellimuste nimekirjast ära.

Miks ma leian, et selline vaade vajab WITH CHECK OPTION kitsendust, mis keelab sellise muudatuse tegemise?

See on põhimõtte küsimus. Süsteemi õpitavuse, kasutamise efektiivsuse, meeldejäävuse ja arusaadavuse seisukohalt on oluline, et süsteemi osade käitumine on ootuspärane, järjekindel ja võimalikult väheste eranditega - kokkuvõtlikult järgiks ortogonaalse disaini printsiipi. Olen ortogonaalse disaini printsiibist kirjutanud "Andmebaasid I" materjalides. Tarkvarakeel, mis on kavandatud ortogonaalse disaini printsiipi arvestades:

pakub suhteliselt väikese hulga keelekonstruktsioone
koos terviklike ja järjekindlate reeglitega nende konstruktsioonide kombineerimise kohta
ning iga konstruktsioonide kombinatsioon on legaalne ja sisulist tähendust omav.

SQL on näide keelest, mis paraku paljudes kohtades RIKUB ortogonaalse disaini printsiibi põhimõtteid ning nagu on näha käesolevast näitest, siis võimaldab ka luua süsteeme, mis omakorda seda printsiipi rikuvad.

Baastabel, virtuaalne tabel e vaade, kitsendus, UPDATE ja INSERT operatsioon kuuluvad SQLi põhiliste konstruktsioonide hulka. 
Ortogonaalse disaini printsiibi mõtte kohaselt:

INSERT ja UPDATE operatsioonid toimivad ühtemoodi nii baastabelitel kui virtuaalsetel tabelitel (seega, näiteks, kuna UPDATE lause baastabelist ridu ei kustuta, siis ei tee see seda ka virtuaalsete tabelite korral).
Kitsendusi jõustatakse ühtemoodi nii baastabelitel kui virtuaalsetel tabelitel, st ei lubata nendes teha muudatusi, mis lähevad vastuollu neile defineeritud kitsendustega. Virtuaalse tabeli alampäringus olev piirang (predikaat) on selle tabeli kitsendus, mis ütleb, millistele tingimustele vastavad read selles tabelis sisalduvad.


Tulles tagasi jutu alguses olnud näite juurde, siis siin tuleks lisaks vaatele teha funktsioon, mille sisuks on etteantud koodiga tellimuse kinnitamine. Kasutajale antakse õigus käivitada funktsiooni, kuid ei anta UPDATE õigust vaate suhtes. Seega vaade on praktikas kasutusel andmete lugemiseks ning funktsioon selleks, et seisundit muuta. Funktsioon muudab andmeid otse baastabelis Tellimus. Sellise lahenduse põhjenduseks on SQLi suured piirangud uuendatavatele vaadetele (mis on kõigele lisaks erinevates andmebaasisüsteemides erinevad). Seetõttu on otstarbekas vaadete uuendamise võimalust (andmete muutmine vaate kaudu) praktikas mitte kasutada. Põhimõtte pärast peaks sellisel vaatel aga siiski olema WITH CHECK OPTION kitsendus.

## Küsimus: Kas võin eeldada, et Eesti isikukood on unikaalne identifikaator?

**Vastus:**

Eesti e-riigi loogika eeldab, et see on unikaalne. Samas tuleb välja, et unikaalsus ei ole mineviku möödalaskmiste tõttu tagatud. Huvitav ülevaade Eesti isikukoodi loomise taustast ja kaalutlustest (originaal pole enam saadaval, kuid ajamasinas on see säilinud). Muuhulgas väärib tähelepanu tsitaat:
Although it has served Estonia well, the system was not perfect. To the extent that, in fact, in the early days several people received the same identification code and it was too deep in the registries before the mistake was discovered. Thus, technically, the id-code in Estonia can not be assumed to be unique.
Hea näide, miks on parem asju kohe hästi teha, mitte loota sellele, et hiljem midagi parandada õnnestub.

## Küsimus: Kuidas kontrollida regulaaravaldisega, et string tohib sisaldada ainult numbreid ning suurtähti (A-Z)?

**Vastus:**

Katsetus 1
Regulaaravaldis: '[A-Z0-9]+'

Kuidas kontrollida seda regulaaravaldist PostgreSQLis?

SELECT 'EST?12'~'[A-Z0-9]+' AS tulemus;

ja

SELECT 'est12'~'[A-Z0-9]+' AS tulemus;

annavad mõlemad tulemuseks TRUE, sest kontrollitakse, et stringis sisalduks vähemalt üks märk (seda näitab +), mis kuulub märkide klassi [A-Z0-9].

Seega see regulaaravaldis seda ülesannet ei lahenda.

Katsetus 2
Regulaaravaldis: '^[A-Z0-9]+$'

^ tähendab stringi algust
$ tähendab stringi lõppu
Stringi alguse ja lõpu vahel tohivad olla vaid märkide klassi kuuluvad märgid.

Kuidas kontrollida seda regulaaravaldist PostgreSQLis?

SELECT 'EST?12'~'^[A-Z0-9]+$' AS tulemus;

ja

SELECT 'est12'~'^[A-Z0-9]+$' AS tulemus;

annavad mõlemad tulemuseks FALSE.

SELECT 'EST12'~'^[A-Z0-9]+$' AS tulemus;

ja

SELECT 'est12'~*'^[A-Z0-9]+$' AS tulemus;

annavad mõlemad tulemuseks TRUE.

SELECT 'est12'~*'^[A-Z0-9]+$' AS tulemus;

tulemuseks on TRUE, sest ~* operaator teostab tõstutundetut vastavuse kontrolli.

## Küsimus: Kuidas sobitub Tallinna Tehnikaülikooli andmebaaside kursustes õpitud andmebaaside projekteerimise lähenemine erinevate arendusmetoodikatega?

**Vastus:**

Leian, et seda on võimalik erinevate metoodikatega (sh paindmetoodikatega) kenasti koos kasutada. Artefaktidel põhinev äriprotsesside modelleerimine kasutab süsteemide kirjeldamiseks (sh protsesside modelleerimiseks) andmekeskset lähenemist. Sarnasel andmekesksel lähenemisel põhineb ka Tallinna Tehnikaülikooli andmebaaside alastes kursustes (Andmebaasid I ja Andmebaasid II) kirjeldatud andmebaaside projekteerimise metoodika.
Andmekeskne lähenemine äriprotsesside/süsteemide modelleerimisele ei ole uus idee nagu võiks Wikipedia artiklit lugedes mulje jääda (kõik viidatud artiklid on 2000-ndatest). Lugege selle kohta:
Sanz, J.L., 2011. Entity-centric operations modeling for business process management- a multidisciplinary review of the state-ofthe-art. In IEEE 6th International Symposium on Service Oriented System Engineering (SOSE). IEEE. pp. 152–163. [WWW] http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.1006.8091&rep=rep1&type=pdf
Tegelikult tegeleti sellega palju 1980-ndatel ja 1990-ndatel. Seoses objektorienteeritud analüüsi ja disaini populaarsuse kasvuga huvi vahepeal vähenes, kuid artefaktikeskne äriprotsesside modelleerimine on selle huvi taastekitanud.

## Küsimus: Kui soovin kontrollida, et nimi tohib sisaldada vaid tähti ja tühikuid, siis kas sobib selline regulaaravaldise muster: '^([a-zA-Z]|[[:space:]])+$' ?

**Vastus:**

Ei, kahjuks ei sobi, sest Te välistate nimedes näiteks täpitähed. Märkide hulga [a-zA-Z] asemel tuleks kasutada märkide klassi [:alpha:].


PostgreSQL

SELECT 'Õnne Pärl'~'^([a-zA-Z]|[[:space:]])+$' AS tulemus;
Tulemus: FALSE

SELECT 'Õnne Pärl'~'^([[:alpha:]]|[[:space:]])+$' AS tulemus;
Tulemus: TRUE

Oracle


DECLARE
result BOOLEAN;
BEGIN
result:=REGEXP_LIKE('Õnne Pärl', '^([a-zA-Z]|[[:space:]])+$');
IF (result=true) THEN
dbms_output.put_line('TRUE');
ELSE
dbms_output.put_line('FALSE');
END IF;
END;
/

Tulemus: FALSE


DECLARE
result BOOLEAN;
BEGIN
result:=REGEXP_LIKE('Õnne Pärl', '^([[:alpha:]]|[[:space:]])+$');
IF (result=true) THEN
dbms_output.put_line('TRUE');
ELSE
dbms_output.put_line('FALSE');
END IF;
END;
/

Tulemus: TRUE

Märkide klassid.

Eraldi küsimus on, kas isikunimede puhul on sellist kontrolli vaja? Leian, et ei ole, sest tulenevalt kultuurilistest eripäradest võivad nimed olla väga eripalgelised.

## Küsimus: Kust saada infot andmebaasi testimiskeskse arendamise kohta?

**Vastus:**

Raamatust
Guernsey III, M., 2013. Test-Driven Database Development. Unlocking Agility. Addison-Wesley. 315 p.Seda saab lugeda O'Reilly digitaalse platvormi kaudu elektrooniliselt. Kuidas kasutada O'Reilly digitaalset platvormi?

## Küsimus: Miks peaks eelistama trigerite puhul tingimuse kirjutamist päises olevasse WHEN klauslisse, selle asemel, et kirjutada see kehandis olevasse IF lausesse?

**Vastus:**

Stackoverflow arutelus pakub kasutaja Elad ühe ülesande lahendusena välja variandid A ja B. Variandi A korral on tingimus trigeri kehandis IF klauslis. Variandi B korral on tingimus trigeri päises WHEN klauslis. Trigereid on seetõttu kaks, mitte üks.
Tõsi on, et muudatuste tegemiseks on variandi A korral mõnikord vaja käivitada vähem lauseid kui variandi B korral. Kui ma tahan muuta trigeri loogikat, siis tuleb käivitada kaks lauset: DROP TRIGGER ja CREATE TRIGGER. Kui terve loogika on trigeri funktsioonis siis CREATE OR REPLACE FUNCTION lause on muudatuseks piisav.
Kuid sama saab ka öelda B kohta - kui tahan näiteks lõpetada reageerimise UPDATE sündmusele, siis DROP TRIGGER ja CREATE OR REPLACE FUNCTION lausete asemel piisab DROP lausest.
Variant B eeliseks on, et IF lausete sees olevat koodi ei dubleerita ja seetõttu on ka funktsioon lihtsam.
Minu arvates on R.C. Martini puhta koodi raamatu halbade lõhnade kataloogi (peatükk 17) kohaselt lahendusel A järgmised halvad lõhnad:

G5: Duplication
G30: Functions Should Do One Thing

(Kuidas kasutada O'Reilly digitaalset platvormi?)Lisaks võtab variant A andmebaasisüsteemilt võimaluse teostada optimeerimist, mille kohaselt käivitatakse ja läbitakse trigeri funktsioon ainult siis, kui selleks on tõesti vajadus (st tingimused on täidetud).
Lõpetuseks on variant B ka veidi paremini kooskõlas üldise relatsiooniliste/SQL-andmebaaside ideoloogiaga, mille kohaselt tegevused toimuvad indiviidide hulkadega, mitte üksikute indiviididega.
Variandile A vastab algoritm: 
FOR EACH huvipakkuv objekt o  
  IF o.rahuldab_tingimust
    o.tee_tegevus
  END IF;
END;

ja variandile B vastab algoritm: 
FOR EACH huvipakkuv objekt o WHERE  o.rahuldab_tingimust
    o.tee_tegevus
END;


**Märksõnad:** triger, trigerid, puhas kood, deklaratiivne, imperatiivne

## Küsimus: Miks peaks tabeliga seotud kitsenduse või indeksi nimi sisaldama tabeli nime?

**Vastus:**

Hea praktika on sellistes nimedes tabeli nime kasutada. Üldine põhimõte on, et tabeli nimi aitab tagada kitsenduse/indeksi nime unikaalsust skeemi piires. Miks on nime unikaalsus skeemi piires vajalik?

Miks kasutada indeksi nimes tabeli nime?

See vähendab nimekonfliktide tekkimise võimalust. Indeksi nimi peab olema nii PostgreSQLis kui Oracles skeemi piires unikaalne. Erinevates samas skeemis olevastes tabelites võib olla sama nimega veerge. Kui annate selliste veergude korral indeksitele või kitsendustele, millega koos luuakse automaatselt indeks (PRIMARY KEY, UNIQUE, PostgreSQLis ka EXCLUDE) nime, mis sisaldab ainult tabeli veeru nime, siis kutsute sellise nimekonflikti ise esile. Nimekonflikti esilekutsunud lause (CREATE INDEX, CREATE TABLE, ALTER TABLE) jääb täitmata.
Kui indeksi nimes ei ole tabeli nime, siis halvendab see SQL andmekäitluskeele lausete täitmisplaanide loetavust.


Miks kasutada kitsenduse nimes tabeli nime?

Oracles peavad kitsenduste nimed olema skeemi piires unikaalsed. Arvestades võimalusega, et erinevates sama skeemi tabelites võib olla sama nimega veerge, eeldab nimetamisskeem, mis tagab sisukad unikaalsed ja ühetaolised nimed, tabeli nime kasutamist kitsenduse nime osana.
PostgreSQL on kitsenduste nimetamisel liberaalsem.

PRIMARY KEY, UNIQUE ja EXCLUDE kitsenduste nimed peavad olema unikaalsed skeemi piires. Nende kitsenduste toetuseks luuakse indeks ja indeksi nimi peab olema skeemi piires unikaalne.
Erinevates tabelites võib olla sama nimega CHECK ja FOREIGN KEY kitsendusi.
Ühes ja samas tabelis ei tohi olla sama nimega CHECK ja FOREIGN KEY kitsendust.

PostgreSQLis peaks PRIMARY KEY, UNIQUE ja EXCLUDE kitsenduste nimedes kasutama tabeli nime tulenevalt indeksitega seoses mainitud punktist 1.
PostgreSQLis peaks FOREIGN KEY (ning tulevikku silmas pidades ka CHECK kitsenduste) nimed olema unikaalsed, et oleks mugavam kasutada seda lauset: https://www.postgresql.org/docs/current/sql-set-constraints.html " Because PostgreSQL does not require constraint names to be unique within a schema (but only per-table), it is possible that there is more than one match for a specified constraint name. In this case SET CONSTRAINTS will act on all matches."
Unikaalsed kitsenduste nimed aitavad paremini aru saada veateadetest.
Unikaalsete kitsenduste nimede alusel on parem skriptifailist või päringuga andmebaasi süsteemikataloogist huvipakkuva kitsenduse kirjeldus üles leida.


**Märksõnad:** indeks, kitsendus, nimetamine

## Küsimus: Miks peavad ka rakenduste programmeerijad andmebaase hästi tundma?

**Vastus:**

Väga eluline näide (seostub teemaga 6 - transaktsioonid ja lukustamine).
2017. aastal avaldati rahvusvahelisel tippkonverentsil teadusartikkel, kus sellist tüüpi rünnakute tagamaid täpsemalt avati ning uuriti nende esinemise võimalust 12 e-kaubanduse programmi põhjal.
Warszawski, T., Bailis, P., 2017. ACIDRain: Concurrency-related attacks on database-backed web applications. In Proceedings of the 2017 ACM International Conference on Management of Data. ACM. pp. 5–20. [WWW] http://www.bailis.org/papers/acidrain-sigmod2017.pdf
Autorid nimetavad sellist tüüpi rünnakut ACIDRain. See on ründemeetod, mis kasutab ära rakenduste nõrkust, mille korral saab rakendust manipuleerida nii, et selle antud korralduste alusel hakkab andmebaasisüsteem koostama mitteserialiseeritud tööplaane.
Uuritud 12 e-kaubanduse programmi on installeeritud üle kahe miljoni korra. Üle 60% miljonist kõige populaarsemast e-kaubanduse keskkonnast kasutavad ühte nendest programmidest. Uuring tuvastas nendes programmides kokku 22 kriitilist haavatavust, mida saab ACIDRain rünnakuga ära kasutada. Näiteks saab ründaja kasutada kinkekaarte üle etteseatud limiidi ja osta e-poest tasuta kaupu. ACIDRain rünnakute vältimises peavad arendajad tundma transaktsioone, lukustamist, transaktsioonide isolatsioonitasemeid ning oskama neid õiges kohas ja õigel viisil kasutada.
2015. aastal avaldati rahvusvahelisel tippkonverentsil teadusartikkel, kus kirjeldati Ruby on Rails raamistikus loodud 67 avatud lähtekoodiga rakenduse uurimise tulemusi.
Bailis, P., Fekete, A., Franklin, M. J., Ghodsi, A., Hellerstein, J. M., Stoica, I., 2015. Feral concurrency control: An empirical investigation of modern application integrity. In Proceedings of the 2015 ACM SIGMOD International Conference on Management of Data. ACM. pp. 1327-1342 [WWW] http://www.bailis.org/papers/feral-sigmod2015.pdf
Uuring keskendus rakenduse tasemel jõustatud andmete kontrollidele. Uuringu tulemusena selgus, et 13% uuritud kontrollidest olid ebapiisavad (st lubasid andmebaasi kitsendusega vastuolus olevaid andmeid), sest ei arvestanud andmete samaaegse kasutamise võimalusega. Seega rakenduste looja peaks oskama selle võimalusega arvestada ning teadma ka seda, kuidas kitsenduste andmebaasi tasemel jõustamine tema tööd lihtsamaks teeb nagu kirjeldatakse näiteks siin ja siin. Siis ei ole andmebaasis kitsenduste jõustamine tema jaoks enam "veider trikk".
Järgneva kohta võivad küünilised programmeerijad öelda, et palju koodi ja pärmina paisuvad arenduste hinnad annavad neile tööd ja leiba. Kuid kindlasti on see suur probleem ARVETE MAKSJATELE (lõpuks tuleb kogu raha ikkagi kas maksumaksja või organisatsiooni pakutava toote/teenuse ostja taskust).
Tänapäeva tarkvaraprojekte iseloomustavad üle kokkulepitud tähtaegade minek ning arenduseks kulunud summade kasv. Pole mingi ime, kui süsteem, mis algselt pidi maksma üks miljon Eurot, läheb maksma 10 miljonit Eurot või rohkem. Näideteks on Sotsiaalkindlustusameti infosüsteemi SKAIS2 arendus Eestis ja Obamacare veebilehe arendus USAs. Selle põhjuseks on raiskamine ning sellest kirjutab pikemalt oma raamatus Dave McComb. See näide pole seotud andmebaasidega, kuid on siiski tähelepanuväärne näide üle võlli kulutustest (raiskamisest) lihtsale tarkvarale. Suured kulud tulevad tarkvara asjatust keerukusest.
McComb pakub välja tarkvara keerukuse leidmise valemi:
keerukus = rakenduste arv * andmebaasi skeem (skeemi elementide arv - nt tabelite ja veergude arv) * rakenduste lähtekood (koodiridade arv) skeemi kohta
Keerukuse vähendamiseks tuleks nende näitajate väärtuseid vähendada. McComb kirjutab, et kui kahte nendest vähendada poole võrra, siis väheneb keerukus 75% ja kui kõiki kolme vähendada poole võrra, siis väheneb keerukus 83%.
"Andmebaasid I" õppeaines räägitud allsüsteemideks jagamine aitab hoida rakenduste arvu kontrolli all, väldib funktsionaalsuse dubleerimist erinevates rakendustest (igale funktsionaalsele allsüsteemile hakkab vastama rakendus, mis tänapäeva mobiilses maailmas võib isegi olla äpp) ja andmete dubleerimist erinevates andmebaasi alamosades e registrites.
Hästi disainitud e kavandatud andmebaas (kus on läbimõeldud ja hästi koostatud andmestruktuurid) muudab rakenduse tegemise lihtsamaks ja vähendab vajamineva koodi hulka. Halvasti disainitud andmebaas, vastupidi, suurendab vajamineva koodi hulka. Hästi disainitud tähendab muuhulgas, et andmebaasis, kus on vaja üksikuid fakte lisada, muuta ja kustutada (operatiivandmete andmebaas), on võimalikult vähe andmete liiasust (vt andmebaasi normaliseerimine ja ortogonaalse disaini printsiip). Kui näiteks kliendi andmeid korratakse üle erinevate andmestruktuuride, siis kasvab skeemi suurus ja skeemi jaoks vajaliku rakenduse koodi hulk ning see omakorda kasvatab keerukust. Kui andmestruktuur ei ole kõrge astmeni normaliseeritud ja seal on palju andmete liiasust, siis suureneb andmete muutmiseks vajaliku koodi hulk ja see kasvatab keerukust. Rääkimata sellest, et suurem andmete hulk vähendab andmete muutmise operatsioonide täitmiskiirust.
Ärireeglite kontroll andmebaasi tasemel vabastab vajadusest neid kontrolle korduvalt ja erinevates rakendustes realiseerida ja seega vähendab vajamineva koodi hulka. Kui on täiesti kindel, et andmebaasis olevad andmed vastavad teatud reeglitele (st nende reeglite kontroll toimub andmebaasi tasemel), siis saab andmete küsimiseks kirjutada lihtsamaid päringuid ja andmebaasisüsteem suudab teatud päringuid kiiremini täita.
Deklaratiivne andmebaasikeel (nagu SQL andmekäitluskeel) on väga võimas ning suhteliselt väikese koodi hulgaga saab lahendatud vägagi keerulised andmete otsimise või muutmise ülesanded. Võrdluseks, sama ülesande lahendamine rakenduse tasemel imperatiivselt (süsteemile samm‑sammult tegevusi ette kirjutades), nõuaks suuremat hulka koodi ja seega kasvataks keerukust. Samuti, mida rohkem koodi, seda rohkem on koodis võimalikke vigu. Vajadus lahendada sama ülesannet erinevates rakendustes kasvatab koodi hulka ning süsteemi keerukust veelgi.

## Küsimus: Millist räsifunktsiooni tuleks kasutada andmebaasis hoitavate paroolide räsimiseks (avateksti peitmiseks)?

**Vastus:**

Cybernetica AS, 2013. Krüptograafiliste algoritmide kasutusvaldkondade
ja elutsükli uuring. Aruanne. Versioon 3.1. 31. detsember 2013. a. [WWW]
https://www.ria.ee/public/PKI/kruptograafiliste_algoritmide_elutsukli_uuring_II.pdf

Teatavasti ei luba ülesande püstitus (ja ka kaine mõistus) hoida andmebaasis paroole avatekstina, vaid tuleb hoida paroolide soolatud räsi. Selle dokumendi jaotises 2.3 kirjutatakse erinevate räsifunktsioonide turvalisusest. 2013. aasta detsembri lõpu seisuga kirjutab dokument muuhulgas räsifunktsioonide kohta:

5 aasta jooksul turvalised primitiivid: Blowfish, AES (kõik standardsed võtmepikkused),
RSA-2048 (ja diskreetse logaritmi põhised süsteemid mooduli pikkusega 2048
bitti), SHA-2, SHA-3, RIPEMD-160 

Nende hulgast tulekski leida oma projektis kasutatav räsifunktsioon.

2018. aastal ilmus krüptograafiliste algoritmide elutsükli uuringu uus versioon, mis sisuliselt kordas sama soovitust.
Cybernetica AS, 2018. Krüptograafiliste algoritmide elutsükkel. Uuring. Versioon 2.0. 9. veebruar 2018. a. [WWW]
https://www.ria.ee/sites/default/files/content-editors/publikatsioonid/kruptograafiliste_algoritmide_elutsukli_uuring_2017.pdf

Selles kirjutatakse: 2017. aasta veebruaris leidis Google’i poolt toetatud teadlaste meeskond lõpuks ammuoodatud kollisiooni räsifunktsioonile SHA-1. Kuigi kollisiooni olemasolu ei tähenda automaatselt kõigi kasutusstsenaariumite ebaturvaliseks muutumist, kordame siinkohal jubakõigis eelmistes  krüptograafiliste algoritmide elutsükli uuringutes  antud soovitust SHA-1 käibelt kõrvaldada. Asenduseks sobivad kõik SHA-2 ja SHA-3 perekonna räsifunktsioonid. ... Nagu ülal juba mainitud, pole viimase aasta jooksul peale SHA-1 kollisiooni leidmise märkimisväärseid
krüptograafilisi läbimurdeid toimunud. Seega kehtivad üldjoontes eelmistes aruande versioonides antud soovitused.

## Küsimus: Ülesande 10 juhendis on öeldud, et f_is_user funktsiooni asendus tuleb teha kahes kohas. Esimene koht on .CommandText = "public.f_is_user" mille muutsin .CommandText = "public.f_on_juhataja"'ks, kuid ei leidnud teist kohta kus seda muuta.

**Vastus:**

Private Sub OK_Click() ... Do While Not rst.EOF result = rst!f_is_user ...
See on sündmusprotseduuris, mis käivitub OK nupule vajutamisel.
Kõige lihtsam on vajutada Ctrl+F ja otsida f_is_user.

**Märksõnad:** vba, MS Access, sündmusprotseduur, funktsioon, kasutaja tuvastamine, f_is_user

## Küsimus: Ülesandes 10 kirjeldatud kasutaja tuvastamise funktsioon ei toimi. Kutsume selle välja, andes ette kasutajanime ja parooli, kuid tulemus on FALSE (kuid peaks olema TRUE). Mis võib olla viga?

**Vastus:**

Võimalikke põhjuseid, miks selline funktsioon ei tööta.

1. Kasutajanimi on vale.
2. Parool on vale.
3. Parooli räsimise UPDATE lauset käivitati rohkem kui üks kord. Selle tulemusena leiti ja salvestati olemasoleva parooli räsi põhjal uus räsiväärtus.
4. Katsetatav isik pole töötaja, pole juhataha või pole isiku või töötajana sobivas seisundis.

Midagi nendest põhjustab vea. Variandi 3 lahendamiseks aitab see, kui kirjutate isikutele avatekstilised paroolid ja käivitate seejärel uuesti räsiväärtuse leidmise UPDATE lause - üks kord!

Võite katsetamise huvides määrata kõikidele isikutele ühesuguse vabatekstilise parooli. Näiteks:

UPDATE Isik SET parool='seepoleTurvaline';

**Märksõnad:** Ülesanne 10, kasutaja tuvastamine, turvalisus


---

# Teema: Andmebaasisüsteemid (Üldine)

## Küsimus: Kas ja miks peab rutiinis või trigeris kasutama SELECT ... FOR UPDATE?

**Vastus:**

Kas ... FOR UPDATE on vajalik sõltub kõigepealt kasutatavast andmebaasisüsteemist. PostgreSQLis ja Oracles on SELECT ... FOR UPDATE vaja kasutada siis, kui teete trigeri protseduuris või lihtsalt rutiinis mingi tingimuse kontrolliks päringu (SELECT lause) teise tabelisse või ka sama tabeli teiste ridade põhjal. Sellega tagate, et kui andmed, mille põhjal kontrolli teete, on parajasti muutmisel, siis jätkub Teie trigeri või rutiini töö alles siis, kui see muutmine on lõppenud ja on selge, millised on uued andmed. Lihtsalt SELECT seda ei taga, sest nii Oracle kui PostgreSQL kasutavad multiversioon-konkurentsjuhtimist (MVCC, multi-version concurrency control) ning andmete muutmine/kustutamine ei blokeeri nende samaaegset lugemist. SELECT ... FOR UPDATE üritab panna loetud ridadele eksklusiivse luku ja see ebaõnnestub, kui need read on juba eksklusiivselt lukustatud, st keegi parajasti muudab neid.

**Märksõnad:** triger, rutiin, lukustamine

## Küsimus: Kas ja millal eelistada NoSQL andmebaasi SQL-andmebaasi loomisele?

**Vastus:**

Arvan, et käesolevaks ajaks on NoSQL jõudnud haibitsüklis ülisuurte ootuste tipust üle, pettumuste lohust läbi, võibolla isegi juba taasavastamise tõusule.
Üha rohkem ilmub seisukohti ja tähelepanekuid, mis osundavad lähenemise või süsteemide üldistele puudujääkidele (näide1, näide2, näide 3) ja konkreetsete süsteemide probleemidele (näide4, näide5, näide6). Muidugi saab öelda, et ühes või teises NoSQL süsteemis selliseid probleeme ei ole ja olemasolevad süsteemid arenevad kiiresti ja lahendavad käigupealt esilekerkinud probleeme, kuid küsimus on, kuidas see toode kümnete teiste seast üles leida ja kas on kindel, et selle teinud idufirma pole viie aasta pärast hingusele läinud. NoSQL süsteemid peavad oma arengus jõudma produktiivsuse platoole ja tõsised tegijad välja settima.
Näen tõsist probleemi selles, et NoSQL süsteeme üritatakse kasutada ka seal, kus see pole kindlasti mõistlik. Teha raamatupidamise tarkvara NoSQL süsteemi põhjal on sama lahe kui kratsida kukalt pannes käe jalge vahelt läbi. Alguses paistab huvitav ja ekstravagantne, sellest tehtud piltidega saab sotsiaalmeedias praalida - pärast on kael ja keha kanged ning selg paigast ära. Mulle meeldis ühes arutelus võrdlus andmete ja koduse tööriistakuuri vahel. Oletame, et Teil on kuuris palju tööriistu. Üks võimalus on võtta erinevat tüüpi tööriistade jaoks kasutusele erinevad kastid. Kahtlemata võtab kastide valimine, neile siltide kleepimine ning tööriista ära panemisel õige kasti otsimine aega. Andmebaaside maailmas vastab sellele skeemi defineerimine SQL/relatsioonilises andmebaasis. Selle tulemusena on vajaliku tööriista leidmine kiire. Kas tõesti oleks lahendus, kus kuuris on hulk kaste ja tööriist pannakse esimesse vabasse kasti, kokkuvõttes kiirem ja parem? Andmebaaside maailmas vastaks sellele skeemitu (täpsemalt ainult lugemise skeemiga) NoSQL andmebaasi kasutamine.
Näen NoSQL süsteemide peamist kasutusvaldkonda suurandmete (big data) hoiustamisel - andmeid on hästi palju, neid tuleb nagu kosest juurde ja andmete struktuur ei ole ühe vitsaga löödud, vaid küllaltki muutlik. Kena oleks need kuskile kiiresti ja odavalt ära panna, lootuses, et ehk on hiljem aega, tahtmist ja raha, et neid lähemalt uurida. Tööriistade näitel oleks see umbes midagi sellist. Asjade hunnikusse paigutajal oli oma süsteem ja ta leiab vajaliku kiiresti üles. Teistel see nii kiiresti ei lähe. Teisalt, nagu tõestavad seriaalid nagu American Pickers, võib sellisest hunnikust igasugu väärt kraami leida. Samamoodi ei tasu ka andmeid lihtsalt ära visata. Graafipõhistel andmebaasisüsteemidel on kindlasti oma kindel koht igat sorti võrgustike (kes on kelle sõber, kust kuhu tee viib või kaabel jookseb jne) andmete käepäraseks muutmisel. Arvan, et mõistlikuks arengusuunaks on SQL ja NoSQL kokkusulamine, mille näiteks on PostgreSQLis JSON tüüpi andmetega töötamise võimalus. See võimaldab lahendusi, kus ühes geograafilises punktis oleva andmebaasi piires on teatud osa andmetest esitatud rohkem struktureeritult (eraldi veergudes) ja muutlikum osa andmeid on surutud kokku JSON andmeväärtustesse (vt kolmandat disaini selles näites). Kõiki neid andmeid kantseldab ACID omadusi toetav transaktsioonide juhtimise moodul.
NoSQL and Technical Debt on 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. SQL ja NoSQL on nagu lennukid ja helikopterid. Mõlemad lendavad, kuid üks ei asenda teist. Kummalgi on omad kasutusvaldkonnad, kus nad on alternatiividest paremad ja edukamad.

## Küsimus: Kas päringute tegemine vaadete põhjal võib mõjutada päringute täitmise kiirust võrreldes päringute tegemisega otse baastabelite põhjal?

**Vastus:**

Jah. Vaadete kasutamine mõjutab täitmisplaanide valikut ja võib mõnikord viia ebaotstarbekate plaanide valimiseni.

Kašnikova, D., 2015. Vaadete mõju päringute täitmisplaanide koostamisele kahe andmebaasisüsteemi näitel. Magistritöö. TTÜ Informaatikainstituut. [WWW] https://digi.lib.ttu.ee/i/?3676 (30.08.2016)

Tsiteerin: Uuringu tulemused näitasid, et kuigi Oracle andmebaasisüsteemis põhjustab vaate põhjal päringu tegemine sageli teistsuguse täitmisplaani valimise kui otse baastabelite põhjal päringuid tehes, siis sellest tulenevad töökiiruse erinevused ei ole kuigi märgatavad. PostgreSQLis koostab andmebaasisüsteem (ilma turvabarjäärita) vaate põhjal tehtud päringule ning otse baastabelil tehtud päringule suurema tõenäosusega ühesuguse täitmisplaani. Kuid probleem on selles, et võrreldes Oraclega on see täitmisplaan mõnikord lihtsalt halb, olgu päring tehtud vaate põhjal või mitte. PostgreSQLis tuleks andmete turvalisuse tõstmiseks kasutada vaadetes turvabarjääre, kuid see võib tingida vaate põhjal tehtud päringule mitteoptimaalse (ja seega aeglaselt täidetava) täitmisplaani valimise.

Siiski, mõeldes kõigile vaadete võimalikele eelistele ja puudustele leian, et vaated on hea ja kasulik vahend andmebaasi kapseldamiseks ning neid tuleks kasutada.

## Küsimus: Kuidas kasutatakse andmebaasisüsteeme suurtes, hajutatud süsteemides nagu näiteks Facebook?

**Vastus:**

Elu näitab, et loengutes ja praktikumides teevad paljud üliõpilased lisaks apex.ttu.ee serverile praktilisi katseid ja vaatluseid ka Facebookis :-) Kelle huvi pakub, siis sellele teatele lisatud faili jaotises 2.1 antakse ülevaade Facebooki andmebaasi arhitektuurist. Artikkel ise seostub teemadega 6 ja 12.

## Küsimus: Kuidas valida üldiselt andmebaasirakenduse jaoks andmebaasisüsteemi?

**Vastus:**

Arutelu teemal, kuidas ettevõtted valivad enda infosüsteemide jaoks andmebaasisüsteeme ning milliseid meetodeid andmebaasisüsteemide arendajad kasutavad, et leida uusi kliente ja hoida kinni olemasolevaid.

## Küsimus: Millised on PostgreSQLi ja Oracle eelised võrreldes üksteisega?

**Vastus:**

Vastus peegeldab õppejõu isiklikku seisukohta, puudutab eeskätt andmebaaside programmeerimist ning välja toodud nimekirjad pole ammendavad.
PostgreSQL eeliseid võrreldes Oraclega.

Avatud lähtekood.
Litsentsitasuta.
Lisaks lähtekoodi avalikkusele on ka andmebaasisüsteemi endasse sisse ehitatud mitmed vahendid süsteemi funktsionaalsuse suurendamiseks - näiteks võimaldab PostgreSQL võtta kasutusele uusi protseduurseid keeli (PL) Näide: Skype – PL/Proxy, Slaidid 6, 11–29
Tõeliselt serialiseeritavad transaktsioonid, mis muudab oluliselt lihtsamaks andmete reeglitele vastavuse kontrollimise.
Minu arvates parem vastavus SQL standardile. Näiteks Oracles ei saa kasutada nt INFORMATION_SCHEMA skeemi; domeene; BOOLEAN, BIGINT, INTEGER, SMALLINT, DECIMAL andmetüüpe tabelite veergude tüübina; ON UPDATE CASCADE välisvõtme kompenseerivat tegevust. Slaidiettekanne sellest, kuidas PostgreSQLis on konkurentidest parem tugi SQL standardile.
EXCLUSION kitsendused koos vahemiku tüüpidega (mida saab ise juurde defineerida) võimaldavad väga lihtsalt jõustada reegleid, et vahemiku tüüpi väärtused ei tohi kattuda (nt kaks broneeringut samasse tuppa ei tohi ajaliselt ei osaliselt ega täielikult kattuda).
Serveris saab olla andmebaaside klaster suure hulga andmebaasidega, selle asemel, et nagu Oracles jännata alates Oracle versioonist 12.1 võimaliku andmebaasile alamandmebaaside defineerimisega.
Väliste andmete pakendajate, väliste serverite ja väliste tabelite funktsionaalsus võimaldab PostgreSQLi andmebaasi abil üles ehitada andmete integreerimise keskkonna. Saan teha nii, et PostgreSQL andmebaasis on tabelid, mille kaudu näen andmeid teistest andmebaasidest ja mille kaudu saan nendes nii andmeid lugeda kui ka muuta.
Võimalus koondada andmekirjelduskeele lauseid ühte transaktsiooni, mis lubab teha andmebaasi skeemimuudatusi ühe loogilise tervikuna (kõik laused kas täidetakse, või jäetakse kõik täitmata). Oracles on selleks suurte piirangutega CREATE SCHEMA lause.

Oracle eeliseid võrreldes PostgreSQLiga.

Application Express andmetega juhitav veebirakenduste kiirprogrammeerimise vahend. AGA, sellist süsteemi on võimalik realiseerida ka PostgreSQLi põhjal ning seda tõestab selle magistritöö ning selle bakalaureusetöö ja selle bakalaureusetöö tulemus.
Rohkem sisseehitatud andmete turvalisuse tagamise vahendeid. AGA, PostgreSQL 9.5 lisandus reapõhiste juurdepääsupiirangute võimalus, st PostgreSQL tõmbab Oraclele selles küsimuses järgi.
Hetktõmmiste puhul on võimalik nende osaline värskendamine ning võimalik kohe andmebaasisüsteemis ära kirjeldada nende värskendamise sagedus (ei pea hakkama Cron plaanurit kasutama).
Väiksemad piirangud vaadetele, mille kaudu saab vaikimisi andmeid muuta.
Suuremad võimalused mõjutada tabelis olevate andmete salvestamist andmebaasi sisemisel tasemel (sh võimalus koondada tabeleid klastrisse) ja andmete muutmällu lugemist. Selles bakalaureusetöös on mitmete nende Oracle võimaluste kasutamise mõju katsetatud. AGA, PostgreSQL viimastes versioonides pööratakse suurt tähelepanu tabelite sektsioonideks jagamisele (st suure tabeli väiksemateks osadeks jagamisele andmebaasi sisemisel tasemel).
Baastabeli veeru tüüpi saab muuta ka siis, kui andmebaasis on loodud vaade, mis viitab sellele veerule. See omakorda lihtsustab andmebaasi evolutsiooni. PostgreSQLis sellisel juhul baastabeli veeru tüüpi muuta ei saa - eelnevalt tuleb vaated kustutada, siis muuta tüüpi ja siis luua vaated uuesti.

Veel üks võrdlus.
Ja veel üks.
Konkreetne näide, kuidas suur infosüsteem vahetas Oracle PostgreSQLi vastu. Siin on lühike tekstiline ülevaade.
2019. aasta sügisel teatas Amazon, et lõpetas suuremas osas Oracle andmebaasisüsteemi kasutamise. Läbiviidud andmebaaside migreerimise tulemusena kanti ligi 7500-st Oracle andmebaasist kokku 75 petabaiti andmeid erinevatesse Amazoni enda pilvepõhiste andmebaasisüsteemide abil loodud andmebaasidesse. Mõned kolmandate osapoolte rakendused vajavad tööks ilmtingimata Oracle andmebaase ja need jäid ülekandmata. Sellest migreerimisest kirjutatakse pikemalt siin.Seda, et PostgreSQL on hästi kasutatav suurtes ja kriitilise tähtsusega süsteemides (st ei saa öelda, et Oracle sobib sellistesse süsteemidesse, kuid PostgreSQL ei sobi), näitab näiteks selle andmebaasisüsteemi laialdane kasutamine riigi infosüsteemides. 2018. aastal avaldatud siseministeeriumi haldusala IKT teenuste finantseerimise uuring toob välja, et enamasti on andmebaasisüsteemiks PostgreSQL ja rakendusserveriks Tomcat. Samuti nähti 2019. aasta jaanuari keskel välja kuulutatud sotsiaalkaitse infosüsteemi hanke avalikes dokumentides ette, et uues süsteemis tuleb eelistatult kasutada PostgreSQL andmebaasisüsteemi.
Lõpetuseks tõstaksin esile Markus Winandi (mees veebilehe taga modern-SQL, mis tutvustab kaasaegset SQLi kogu oma vägevuses) kiidusõnu PostgreSQLi aadressil: Küsimusele kuidas Teile meeldib PostgreSQL vastas ta nii: "PostgreSQL on väga tugevas positsioonis. Arendajate vaatepunktist on selle pakutavad võimalused lähemal kommertssüsteemidele kui avatud lähtekoodiga võistlejatele nagu MySQL/MariaDB. Mulle meeldib eriti PostgreSQLi pakutav rikkalik SQL standardi toetus, mis tähendab selliseid asju nagu täielik VALUES klausli toetus, rekursiivsed päringud, over, lateral ja massiivide kasutamise võimalus."
Ühes teises kohas vastas ta küsimusele, millist andmebaasisüsteemi ta eelistab, et kõik sõltub nõuetest, arendusmeeskonnast ja eelarvest, kuid kui need pole veel selged, siis on PostgreSQL parim vaikimisi valik.

## Küsimus: Milliseid raamatuid soovitate erinevate andmemudelite kohta (andmemudel kui andmebaasikeele aluseks olev üldiste andmebaasi ehitusplokkide, kitsenduse tüüpide, andmetüüpide ja operatsioonide kirjeldus)?

**Vastus:**

Relatsiooniline andmemudel (mitte ajada segi SQLiga)Date, C.J., 2015. SQL and Relational Theory, 3rd Edition. O'ReillyFüüsiline raamat ülikooli raamatukogus: Date, C.J., Darwen, H., 2007. Databases, types, and the relational model. 3rd ed. China Machine Press
NoSQL süsteemid Sadalage, P.J., Fowler, M., 2013. NoSQL distilled : a brief guide to the emerging world of polyglot persistence. Upper Saddle River (N.J.)Sama raamat on saadava füüsilisel kujul ülikooli raamatukogust.
Dokumendipõhistel ja graafipõhistel andmemudelitel põhinevad andmebaasisüsteemid kuuluvad NoSQL süsteemide kategooriasse. Nendest mudelitest annab teises peatükis ülevaate: Kleppmann, M., 2017. Designing Data-intensive Applications : the Big Ideas Behind Reliable, Scalable, and Maintainable Systems, O'Reilly. 590 p.Sama raamat on saadava füüsilisel kujul ülikooli raamatukogust.
Graafipõhiste andmemudelite kohta saab lugeda eesti keeles jaotisest 2.2: Mikk, S.M., 2017. Graafide esitamine SQL-andmebaasides. Magistritöö. TTÜ Tarkvarateaduse instituut.Kuidas kasutada O'Reilly digitaalset platvormi?

## Küsimus: NoSQL süsteemid, sh MongoDB on "uus lahe tehnoloogia". Mida ma võiksin nende kohta teada?

**Vastus:**

Kasutage, kui vaja, kuid olge tähelepanelikud ja säilitage kriitiline meel.
Siin on Teile veidi mõtteainet edasiseks eluks. 2020. aasta augustis on MongoDB andmebaasisüsteemide populaarsuse indeksis viiendal kohal! Kui mitte muul põhjusel, siis laske pilk hetkeks sellest artiklist üle, nägemaks, kuidas andmete hajutatud paiknemine komplitseerib süsteemide käitumist. See artikkel on osa projektist Jepsen, mis testib erinevaid hajussüsteemide loomiseks mõeldud vahendeid.
Tsitaat: "In this post, we’ll see that Mongo’s consistency model is broken by design: not only can “strictly consistent” reads see stale versions of documents, but they can also return garbage data from writes that never should have occurred. The former is (as far as I know) a new result which runs contrary to all of Mongo’s consistency documentation. The latter has been a documented issue in Mongo for some time. We’ll also touch on a result from the previous Jepsen post: almost all write concern levels allow data loss."
Mis on sellise või teiste samalaadsete süsteemide kasutamise tulemus? NoSQL Meets Bitcoin and Brings Down Two Exchanges: The Story of Flexcoin and Poloniex.
Tsitaat ühest teisest artiklist, mist käsitleb MongoDB pakutavaid päringute tegemise võimalusi: "Instead of providing developers with a core, well-engineered set of properly shaped building blocks that can combine together to solve all problems, MongoDB provides a set of weirdly shaped, poorly connecting blocks that solve whatever ad hoc user problems prompted their development."
Lõpetuseks veel mõtteavaldusi MongoDB kohta. Pange tähele, et paljudel arvajatel leidub häid sõnu PostgreSQLi kohta.
Maailma esimene süsteem, mis brändis ennast nime all NoSQL pole päris see, mida ootate/arvate.
NoSQL süsteemide õppimise ja kasutamise häda on, et (hetkel veel) on vähe standardeid, mida kõik süsteemid peaksid järgima. Standardite puudus on NoSQL süsteemide autorite teadlik valik - standardid olevat liiga piiravad. Nende meelest - parim süsteem võitku. Kui ellujäänud on selginud ja tehnoloogia areng stabiliseerub, siis võivat ka hakata mõtlema standarditele.
Dokumendipõhiste süsteemide (nagu MongoDB) puhul on standardiks JSON formaati kirjeldav standard. JSON formaati kasutavad dokumendipõhised andmebaasisüsteemid pakuvad võimalust kontrollida/tagada, et andmebaasis andmeid esitav JSON dokument on trimmis, st reeglitega kooskõlas.
Graafi andmebaasisüsteemide korral on jõutud selleni, et populaarseima graafipõhise andmebaasisüsteemi Neo4j arendajad esitasid üleskutse töötada välja graafipõhise andmebaasikeele standard (võttes muidugi aluseks Neo4j andmebaasikeele Cypher). 2019. aasta suvel algatas ISO (International Organization for Standardization) kõigi rahvuslike standardimise organisatsioonide seas küsitluse, kas alustada GQL (Graph Query Language) standardi loomist. 2019. aasta septembris kiideti standardi loomisega alustamine heaks. Standardi koduleht - https://www.gqlstandards.org. GQL pärib mõned omadused (andmetüübid, avaldised jne) SQList, viidates selleks SQL standardile.
Praktikas tähendab standardite puudus, et igas süsteemis on oma andmebaasikeel. Kui isegi süsteemides X ja Y on justkui ühesugune andmemudel (nt graafi andmemudel), siis lähemal vaatlusel selgub, et nende süsteemide arendajate nägemus sellest andmemudelist võib olla märkimisväärselt erinev. Andmebaasisüsteemide võimaluste hulgas ja käitumises esineb väga suuri erinevusi. Standardite puudus tähendab, et kui hakata tarbijana kasutama süsteemi X ning aasta-paari pärast seda arendav (idu)firma pillid kotti paneb, siis uuele platvormile ülekolimine võib osutuda keeruliseks ja töömahukaks. Samuti tähendab standardite puudus, et süsteemi kasutada oskavaid spetsialiste on raske leida ja kallis pidada. Sisuliselt on igal süsteemil oma "standard" ja seda olukorda kirjeldatakse naerdes läbi pisarate SIIN.
Tõele au andes - olemas on SQL standard, kuid ka ühe SQL-andmebaasisüsteemi vahetamine teise vastu (andmebaasi migratsioon) on paraku endiselt keeruline ja töömahukas ülesanne. Seega standard pole imerohi - need kellele standard on mõeldud peavad seda ka reaalselt järgima hakkama.
Kui tahate kiiret kõrgtaseme ülevaadet NoSQL süsteemides, siis on see päris hea materjal. Sama mees on üks selle raamatu autoritest ja viidatud artikkel on põhimõtteliselt selle raamatu lühikokkuvõte. Nimetatud raamatut saab ka lugeda elekrooniliselt O'Reilly digitaalse platvormi kaudud SIIN (Kuidas kasutada O'Reilly digitaalset platvormi?).

## Küsimus: PostgreSQL ja Oracle pakuvad funktsioone, mis realiseerivad foneetilisi algoritme. Milleks neid vaja on? Mis nendest kasu on?

**Vastus:**

Foneetilisi algoritme saab kasutada näiteks suguvõsauuringutes, et otsida sarnase kõlaga perekonnanimega inimesi. Need inimesed võivad, aga ei pruugi, olla omavahel sugulased. Võibolla panid dokumentide väljaandjad vanal ajal nime kirja kuulmise järgi ning seetõttu on erinevate inimeste nimed sarnase kõlaga, kuid erineva kirjapildiga.
Sarnase probleemiga puutuvad kokku paljud ajaloouurijad. Toon näiteks tsitaate:

"Omaette tõsiseks probleemiks on isikunimede moonutamine vene keelde transkribeerimisel, kuna nimed said tihti üleskirjutatud vaid kuulmise järgi." (Rajaotsinguid - Sõjavangilaagrite dokumendid ajalooallikaina).
"Kalmisturaamatusse kanti andmeid sageli mitte dokumendi alusel vaid kuulmise järgi, seega võis viga olla juba kalmisturaamatus" (allikas).

Soundex algoritmi kasutatakse mõnedes (ingliskeelsetes) riikides piiriturvalisuse tagamisel. Inimesel võib olla võltsitud dokument, millel kasutatakse tema pärisnimele (mis võib olla huvipakkuvate isikute nimekirjas) kõlalt lähedast nime. See võib viia väga kummaliste tagajärgedeni nagu kirjutatakse siin. Siin on veel kriitikat Soundex'i ebatäpsuse suhtes. Näiteks ei ole see võimeline arvestama olukorraga, et erinevates keeltes võib sama nimi teiseneda nii palju, et neil on erinevad Soundex'i koodid. Soundex on koostatud inglise keelt silmas pidades ja ei suuda arvestada teiste (nt erinevate Aasia keelte) kultuuriliste omapäradega.
Foneetilisi algoritme saab ka kasutada, et otsida ühes ja samas süsteemis või üle erinevate süsteemide inimesi, kes esinevad ja teevad seal tegusi veidi erinevate nimede all (nt broneerivad mitme erineva, kuid üsna sarnase nime all lennupileteid). Veel üheks näiteks on, et süsteemis, kus klient ei pea tellimuse tegemiseks ennast identifitseerima, vaid sisestab iga kord isikuandmed uuesti, võib ta erinevate tellimuste puhul kogemata või meelega teha nime sisestamisel vea. Mõnda foneetilist algoritmi realiseerivat funktsiooni kasutava päringu abil saab need erinevad tellimused omavahel "kokku viia".


---

# Teema: CASE vahendid

## Küsimus: Kas võin kasutada Rational Rose CASE vahendis # märke?

**Vastus:**

Ühel üliõpilaste grupil oli probleem Rational Rose andmebaasi disaini mudeli riknemisega. Probleem (vähemalt ajutiselt) kadus, kui mudelis eemaldati skeemi (schema) nimest ##.

Seega palun ärge igaks juhuks kasutage skeemi nimedes # märke. Näiteks skeemi nime C##TUD5 asemel kasutage nime TUD5.

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

**Vastus:**

Vaadake palun lisatud faili.

## 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)
SQL koodi genereerimine: Package=>Database engineering=>Generate package DDL


## 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.

## Küsimus: Milliseid võimalusi pakub Enterprise Architect andmebaaside projekteerijale?

**Vastus:**

Video Enterprise Architect 12 täiendustest seoses andmebaaside arendamisega.

## Küsimus: Mul on arvutiks Mac / minu arvutil on Linux operatsioonisüsteem. Kuidas saan kasutada Enterprise Architect (EA) CASE vahendit?

**Vastus:**

Ülikooli pakutav Enterprise Architect (EA) 12 on mõeldud Windowsile. 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.
Maci/Linuxi kasutajad saaksid enda arvutis EA tööle nii, et panevad seal paralleelselt tööle Windowsi (Internetist leiab juhiseid; panin siia stiilinäiteks ühe juhise Maci ja ühe Linuxi kohta). Windowsi saate Azure Dev Tools for Teaching keskkonnast. Kuidas sellele keskkonnale juurdepääs saada on kirjas "Andmebaasid I" õppeaine kodulehe kataloogis Tarkvara saamine ja kasutamine dokumendis Kuidas saada enda arvutisse MS Access (2016)?
Alternatiivid on:

Installeerida EA12 oma Windowsi lauaarvutisse (tööl või kodus) ning taotleda litsentsi üle TORU VPNi. Koolis saab EAd kasutada arvutiklassides.

Kui teete projekti mitmekesi, siis saate ehk tööd jaotada viisil, et Teie ei pea väljaspool praktikume EA faili kasutama.



## Küsimus: Rational Rose (RR) või Enterprise Architecti (EA) mudelifail riknes. Selle väljenduseks on, et mudeli (kas kõiki või osasid) elemente ei saa enam muuta ning ei saa genereerida tabelite kirjeldusest SQL lauseid. Mida teha?

**Vastus:**

Tõepoolest, paraku nii RR kui EA failidega võib selline paha asi juhtuda. Tehke palun iga kord enne mudeliga tööle hakkamist failist koopia ja tehke tööd koopias. Originaal nimetage ümber ja säilitage. Kui töö käigus selgub, et fail on riknenud, siis originaal on alles ja kaotsi ei lähe kogu töö, vaid ainult viimasel korral tehtu.

## Küsimus: Sain Enterprise Architectis (ver 12) veateate "Unrecognized database format". Viga tekkis peale seda, kui olin kõigile tabel X veergudele vajalikud check kitsendused kirjeldanud ja tahtsin edasi liikuda järgmise registri juurde. Proovisin jätkata teises arvutis, kuid jõudsin sama tulemuseni - peale tabeli X kõigile veergudele check kitsenduste kirjeldamist kordus sama viga. Mida teha?

**Vastus:**

Enterprise Architecti dokumentatsioon  kirjutab: "Unfortunately on rare occasions usually caused by network or PC outages a .EAP may become corrupted and may not be opened."

Küsimuses tõstatatud EA probleem lahenes järgnevalt. Avasin Enterprise Architecti. Kui tarkvara küsis, milline projekt avada, siis vajutasin "Cancel". Seejärel valisin: Project => Data Management=> Manage .EAP File => Repair .EAP File Avanenud aknas valisin probleemidega EA faili. Seejärel ootasin mõned minutid kuni tarkvara faili töötles. Peale seda õnnestus fail avada.

## Küsimus: Teen Enterprise Architectis topeltklõpsu tabelite vahelisel seosel ning saan veateate, et osalevad tabelid on erinevates andmebaasisüsteemides. Milles on probleem ja kuidas seda parandada?

**Vastus:**

Vaadake lisatud faili.

**Märksõnad:** Enterprise Architect


---

# Teema: Infosüsteemid ja nende arendus (Üldine)

## Küsimus: Kas leidub eestikeelset materjali tehnilise võla kohta?

**Vastus:**


Käosaar, E., 2017. Lähtekoodi halbade lõhnade üldistamine süsteemianalüüsi mudelitele. Bakalaureusetöö. TTÜ Tarkvarateaduse instituut. [WWW] https://digi.lib.ttu.ee/i/?8930
Paide, R., 2017. Juhtumiuuring tehnilisest võlast Eesti IKT sektori ettevõtetes. Magistritöö. TTÜ Tarkvarateaduse instituut. [WWW] https://digi.lib.ttu.ee/i/?8865
Siseministeerium, 2018. Siseministeeriumi haldusala IKT teenuste arendamine ja haldamise finantseerimise jätkusuutlikkus ning mõju siseturvalisuse tagamisele. Lõpparuanne. 17.08.2018 [WWW] https://www.smit.ee/files/ikt-finantseerimine-pwc-lopparuanne-veeb.pdf?a8072e9c5b



Käosaar (2017) kirjutab tehnilise võla vähendamisest süsteemianalüüsi mudelites. Ta esitab kataloogi mudelites esinevatest halbadest lõhnadest. Iga sellise lõhna esinemine võib olla mudelites leiduva tehnilise võla tunnus.

Paide (2017) uurib tehnilise võla fenomeni Eesti IT ettevõtetes. Selleks viidi läbi poolstruktureeritud intervjuud kaheksa ettevõtte esindajatega (33-st kutsutust). Intervjueeritud töötasid erinevatel IT arendusega seotud töökohtadel. Nad kõik väitsid, et on tehnilise võla mõistega kursis. Intervjuude tulemusi uuriti erinevate statistiliste meetoditega.

Tehnilise võla küsimustele pöörab tähelepanu ka siseministeeriumi haldusala IKT teenuste finantseerimise uuring (Siseministeerium, 2018). Selle uuringu teise peatüki pealkiri on "Tehnoloogiline võlg teenustes". Uuringu lõpparuanne on huvitav ka seetõttu, et seal kirjeldatakse ühte võimalikku tehnilise võla leidmise ja suuruse arvutamise metoodikat. Seda metoodikat kasutati siseministeeriumi haldusalas olevate IT teenuste tehnilise võla suuruse väljaarvutamiseks. Uuringus osales siseministeeriumi haldusalast 14 meeskonda, mis haldavad 45 IT teenust. Uuringu tulemusena leiti uuritud tarkvarades ja nende toimimiseks vajalikes platvormides lähtekoodiga seotud tehniline võlg, mille likvideerimine või tasandamine nõuab pingutust vähemalt u 71100 tarkvaraarendaja töötunni ulatuses. Sellest tarkvaraplatvormidega seotud parandused oleksid 50600 töötundi ja tarkvara lähtekoodi parandused 20478 tundi.

## Küsimus: Kas oskate tuua näiteid Eestist andmete turvalisuse rikkumise kohta?

**Vastus:**

Soovitan kõigil, kes seda pole veel teinud, lugeda 15.01.2017 Postimehest Nils Niitra poolt kirjutatud artiklit andmelekkest metsaregistris. See on surepärane juhtumianalüüs teema 5 (andmete turvalisus) kohta.
Niitra (2017) kirjutab metsaregistrist toimunud andmelekkest. Väidetavalt luges üks artikli kirjutamise ajaks töölt lahkunud töötaja süstemaatiliselt infot isikute (nimed, sünniajad, telefoninumbrid) ja nende metsakinnistute kohta. Peale töölt lahkumist asus ta tööle erafirma metsakorraldajana. Lekkinud info alusel hakkasid metsaomanikud saama massiliselt telefonikõnesid, millega üritati neid kallutada müüma raieõigust turuhinnast madalamalt. Vahendusfirmasid huvitab põhiliselt raieõigus. Seda müüakse suure vaheltkasuga edasi metsa ülestöötamisega tegelevatele ettevõtetele. "Samad firmad tegelevad ka kinnistute vahendamisega rahvusvahelistele kontsernidele, Eesti kohalikele suurmaaomanikele ja välismaistele pensionifondidele. Mets saadakse inimestelt kätte muuhulgas neid juriidiliselt korrektsel moel pettes, kasutades selleks väga erinevaid võtteid." (Niitra, 2017)
Olgu öeldud, et avaliku teabe seadus keelab riigi infosüsteemis asutada ühtede ja samade andmete kogumiseks eraldi andmekogusid. Isikuandmete kogumise koht on rahvastikuregister. Metsaregistrisse jõuavad isikuandmed siis, kui inimesed esitavad e-kava keskkonna kaudu metsaregistrile enda metsa kohta infot.
Milliseid seoseid saab tõmmata selle juhtumi ja andmebaaside aines õpitu vahele?

Andmete loata lugemine rikkus konfidentsiaalsuse nõuet.
Kuna metsaregister ei loginud piisavalt infot selle kohta, kes ja milliseid andmeid täpselt luges ning milliseid tegevusi andmetega tegi (kas laadis alla või mitte), siis polnud täidetud ka revideeritavuse nõue.
"Asutusesisese uurimise käigus suudeti küll tõestada, et mees oli käinud andmeid vaatamas, küll aga oli võimatu tagantjärele kindlaks teha, kas ta neid ka maha laadis." – puudus võimalus viia läbi turvarikke tõendtuvastus, mida on vaja turvarikete rangeks ja täpseks tõestamiseks (näiteks, et oleks võimalik kasutada süüdistusmaterjalina kohtus).
Töötaja vaatas andmeid, mis ei kuulunud tema tööpiirkonda – õiguste jagamisel ei oldud lähtutud minimaalsuse printsiibist.
Registri kasutamise paroolid on antud ka metsakonsulentidele. Neil võib tekkida huvide konflikt, kuid kuna andmete lugemisi piisavalt ei logita, siis on võimatu seda tuvastada. Võimalik, et süsteemile juurdepääsu andmisel pole lähtutud minimaalsuse põhimõttest ja juurdepääs on antud liiga suures ulatuses liiga laiale kasutajate ringile.
Riiklike registrite andmete avalikustamine suurendab üheltpoolt läbipaistvust, kuid teisalt võib leiduda selle info kuritarvitajaid. "Isegi metsaregistri avalik osa on vahendajatele piisavalt huviväärne. Hiljuti muutis riik kaardil nähtavaks ka kõik need metsaeraldised, millel tohib teha uuendusraiet ehk lageraiet. Just sellised tükid tõotavad iseäranis suurt tulu vahendajatele ja metsa ülestöötajatele." (Niitra, 2017)
Süsteemi kõige nõrgemaks lüliks on sellega seotud inimesed.
Kasuahnus on väga levinud rünnaku motiiv.
Ebaseaduslikult saadud andmed võivad anda ettevõttele konkurentide ees ebaseadusliku ja ebaeetilise eelise.
Kõneluse töötaja elukaaslane töötab ühes riigi suurimas metsavahendusfirmas metsahindajana. Eelnev taustakontroll oleks võinud tuvastada töötaja puhul huvide konflikti ja talle poleks pidanud selliseid õiguseid andma või oleks vähemalt tulnud võtta selle töötaja tegevus teravdatud tähelepanu alla. Taustakontrolli vajaduse kehtestamine oleks organisatsiooniline tugevdusmeede. Selle tulemuste alusel juurdepääsu piiramine oleks tehniline tõkestusmeede.
Selliste juhtumite uurimisega tegeleb Andmekaitse Inspektsioon.
Ilmselt pole metsaregistri puhul ISKEt kasutatud.


## Küsimus: Kust saaks rohkem teada paindmetoodikatest?

**Vastus:**

Soovitan vaadata seda Bertrand Meyeri ettekannet (osa 1 ja osa 2), mis põhineb tema uuel raamatul. Raamat ise on olemas Tallinna Tehnikaülikooli raamatukogus.
Tallinna Tehnikaülikooli raamatukogu kaudu on tehtud üliõpilastele elektrooniliselt kättesaadavaks raamat Disciplined Agile Delivery: A Practitioner’s Guide to Agile Software Delivery in the Enterprise. See kirjeldab suurte projektide jaoks kohandatud paindmetoodikat.Kuidas kasutada O'Reilly digitaalset platvormi?
Selles magistritöös valitakse suurettevõttele sobivat skaleeritavat paindmetoodikat. Töös antakse põhjalik ülevaade järgmistest metoodikatest: Scaled Agile Framework (SAFe), Nexus, Disciplined Agile Delivery (DAD), Large-Scale Scrum (LeSS) ja Large-Scale Scrum Huge (LeSS Huge).

## Küsimus: Mida saavad inimesed ise ära teha oma andmete ja privaatsuse kaitsmiseks?

**Vastus:**

Olla tähelepanelikud! Näiteks isikuandmete kaitse seaduse kohaselt kuuluvad andmed tervisliku seisundi kohta eriliiki isikuandmete hulka, mille töötlemisele on ranged nõuded. Tänapäeva nutiseadmete ja enese-eksponeerimise ajastul lekitavad paljud inimesed teadmatusest või hoolimatusest enda sellekohaseid andmeid osapooltele, kelle puhul pole võimalik kontrollida, kes ja mida nende andmetega teeb. Nendeks andmeteks on kantavate seadmete poolt kogutud tervisenäitajad, mis edastatakse teenusepakkujale, kes omakorda võimaldab vaadata nende andmete kohta aruandeid või pakub soovitusi.
Tsitaat artiklist "Andmekaitse Inspektsioon töötas välja uue juhise «Kantavad seadmed ja privaatsus», milles selgitatakse kantavate seadmete (wearable computing) olemust ja nende kasutamise mõju inimese eraelule. Samuti jagatakse juhises soovitusi kasutajate privaatsuse paremaks tagamiseks."

## Küsimus: Millised Eesti riiklikud infosüsteemid töötlevad delikaatseid isikuandmeid?

**Vastus:**

Uus isikuandmete kaitse seaduse redaktsioon, mis võtab üle Euroopa Liidu isikuandmete kaitse üldmääruse, ei kasuta terminit "delikaatsed isikuandmed". Kuid seal on juttu "eriliigilistest isikuandmetest". Eriliiki isikuandmete alla kuuluvad enamus selliseid andmeid, mis varasema sõnastuse järgi olid Eestis käsitletavad kui delikaatsed isikuandmed. Riigi infosüsteemi haldussüsteemi RIHA eelmisest versioonist on võimalik vaadata, millised riigi registrid sisaldavad milliseid delikaatseid isikuandmeid Valige "Riigi infosüsteem => Andmeobjektid => Andmeobjekti otsing".

## Küsimus: Milliseid andmebaaside kursustes käsitletud teemasid puudutavaid järeldusi saab teha 2017. aasta suvel nurjunuks kuulutatud pensionide ja sotsiaaltoetuste maksmise infosüsteemi uue versiooni SKAIS2 arendusprojekti alusel?

**Vastus:**


Väga sageli ei tea süsteemi tulevased kasutajad ja selle arenduse eest maksjad (ei pruugi olla üks ja sama isikute ring), milline täpselt peaks uus süsteem olema. Tulemuseks võivad olla lepingud, mida on ebareaalne täita. Sõltub tellija poolsete läbirääkijate tarkusest, kas nad suudavad lepingusse suruda piisavad hilinemisest tulenevad sanktsioonid ja sellega motiveerida ka arendajaid andma realistlikke lubadusi. Nagu ütleb Marek Helm, siis tellija peab olema tark. Tarka tellijat ei saa ebareaalsete lubadustega petta.
Lehmani tarkvara evolutsiooni seadused (vt "Andmebaasid I", teema 1) ütlevad, et tarkvara funktsionaalsus ja keerukus ajas suureneb ning mingil hetkel jõutakse punkti, kus lihtsam on olemasoleva süsteemi edasise muutmise asemel see nullist uuesti kirjutada e puhtalt lehelt alustada. Samasse seisu jõuti sotsiaalkaitseameti infosüsteemiga SKAIS, mille puhul selgus 2013. aastaks, et olemasolev tarkvara uut töövõimereformi toetada ei suuda ning tuleb alusada selle tarkvara uue versiooni SKAIS2 loomisega.
Suuri süsteeme tuleks arendada väiksemate alamprojektide või äriliselt loogiliste osade (nt ühe teenuse) kaupa. Seda näeb ette strateegilise analüüsi metoodika (vt "Andmebaasid 1", teema 7). Seda soovitab tarkvaraettevõtte Helmes arendusjuht Raul Ennus (siin) ja tarkvaraettevõtte Thorgate tehnoloogiajuht Virgo Riispapp (siin). Sellest saadi lõpuks aru ka SKAIS2 arendamise juures – kui algselt sõlmiti leping terviksüsteemi arendamiseks, siis 2017. aastal, enne arendajaga lepingu katkestamist, mindi üle osade kaupa arendusele. Samuti kirjutab Aivar Pau, et SKAIS2 arendamise uue hanke puhul jagatakse see tükkideks, kusjuures iga arendusetapp puudutab ühte teenust. Selleks tükeldatakse ka kogu süsteemi arhitektuur osadeks nagu üldkasutatavad komponendid, integratsioonikiht, ärifunktsionaalsused, arveldusmoodul ja kasutajaliidesed. Aivar Pau kohaselt sellist tükeldust varem ei tehtud. Süsteemi tükeldamist alamosadeks ja alamosade arendamise jaoks eraldi projektide algatamist näeb samuti ette strateegiline analüüs (vt Andmebaasid I, teema 7). Sellise väiksemate osade kaupa arendamise korral võivad süsteemi erinevate osadega töötada erinevad arendusfirmad. Süsteem ei valmi mitte korraga (suure pauguga), vaid osade kaupa. Väiksematest osadest nagu Lego klotsidest kokkupandud süsteemi korral on lihtsam ja odavam üksikuid osi parandada ja välja vahetada. 
Tarkvara arhitektuur on oluline ja aitab tagada, et see klotsidest moodustis oma raskuse all kokku ei kuku.
Suurte projektide korral on hea mõte lasta arendajatel teha proovitöö ning arvestada hanke võitja valimisel ka muude kriteeriumitega kui kõige madalam hind. Projekti prioriteetide kolmnurk (vt "Andmebaasid I", teema 7) ütleb, et kui eesmärgiks on madal hind ja kiire valmimine (nagu SKAIS2 puhul alguses see oli), siis ei saa tulemus olla kõrge kvaliteediga. Muide, sellist valikut, kus saab saavutada vaid maksimaalselt kaks eesmärki kolmest tuntakse trilemmana.
Riiklikus sotsiaalvaldkonnas, kus kõikvõimalikud reeglid ja maksete suurused sõltuvad poliitikute suvast, on nõudmised äärmiselt muutlikud. See sai SKAIS2 arendamisele lõpuks saatuslikuks. Selliste süsteemide arendamisel tuleks kindlasti kasutada iteratiivset arendust (vt "Andmebaasid II", teema 1). Sama soovitab ka Helmese arendusjuht Raul Ennus (siin).
Arvestades nõudmiste muutlikust tuleks luua tarkvara, mida kasutajad saavad uute reeglite kehtima hakkamisel ise kohandada e konfigureerida, mitte ei pea kogu aeg tellima arendajatelt uusi arendustöid. Sellised süsteemid võivad olla andmetega juhitavad (vt "Andmebaasid II", teema 1). Samas tuleb ette vaadata, et paindlikuse tagaajamisega üle ei pingutata ning ei lisata sellega süsteemi asjatut keerukust. Tarkvara peaks olema hästi evolutsioneeritav. Samas  seda soodustav lähenemine, mille kohaselt on süsteemi igal alamosal (teenusel/mikroteenusel) oma andmebaas (rakenduse andmebaas), mille vahel võib ka olla andmete dubleerimine, ei ole hästi kooskõlas riiklike infosüsteemide nõuete ja vajadustega.
Arendusse tuleks võimalikult varakult kaasata süsteemi lõppkasutajaid ja hakata neile tagasiside saamiseks iteratiivselt süsteemi uusi versioone esitlema. Kasutajad saavad anda tagasisidet nii süsteemi kasutatavuse kui ka funktsionaalsuse kohta. Suurte riiklike süsteemide puhul võib kasutada fookusgruppe. SKAIS2 puhul tuleks kaasata nii igapäevaseid makseid tegevaid ametnikke kui ka maksete saajaid. Oluline on võimalikult varakult ja regulaarselt saada lõppkasutajate tagasisidet, tagamaks, et uues süsteemis oleks neile kõik lihtne ja mugav. Seda ütlevad nii TransferWise'i arendusjuht Alvar Lumberg (siin) kui Helmese arendusjuht Raul Ennus (siin).
Selle asemel, et iga allüksus (riigi puhul näiteks ministeerium) põlve otsas oma süsteemi arendaks, võiks luua ühissüsteeme üle erinevate allüksuste haldusalade. Sellisel viisil on ka tellijate ja juhtide summaarne ajupotensiaal suurem ja ehk tuleb paremini välja. Riik viib sarnase põhjendusega läbi haldusreformi – väikesed haldusüksused jäävad igasuguste suurte projektidega üksi hätta, vaja on jõud ühendada.


## Küsimus: Mis on andmesaatkonnad?

**Vastus:**

Juhin Teie tähelepanu uudisele andmesaatkondade kohta, mis seostub nii teemaga 5 (andmete turvalisus) kui ka 12 (hajusad andmebaasid).

Tegemist on näitega, kuidas liiasust kasutatakse andmete kaitse ühe vahendina.

Pange tähele, kuidas artiklis rõhutatakse korduvalt andmete tervikluse vajadust "Selle kontseptsiooni juures ei saa me aga üle ega ümber vajadusest andmete tervikluse järele –kuidas me tagame, et mingi Eestis kasutusel olevas andmekogus ja selle peegelduses kas siis saatkondades ja mujal välismaa pilveteenustes olevad andmed oleksid igal ajahetkel samad." 

Teemas 12 on juttu CAP teoreemist, mille kohaselt andmete hajutatud paiknemise korral on disaineritel valida, kas tagada süsteemi kättesaadavus igal ajahetkel (leppides sellega, et andmed koopiates pole igal hetkel ühesugused) või koopiate kooskõla igal ajahetkel e terviklus (leppides sellega, et süsteemi või selle osi ei saa mõnikord kasutada). Paljud (kergekaalulisemad) hajutatult paiknevad süsteemid eelistavad tagada kättesaadavust.  Kriitilise tähtsusega andmetega süsteemid (nagu riiklikud süsteemid, aga ka pangad), aga ei saa kuidagi koopiate kooskõlast (terviklusest) mööda vaadata.

2019. aasta uudise kohaselt on Eesti esimesed andmekogud Luksemburgis asuvasse andmesaatkonda talletanud. Esimestena kanti sinna üle e-toimiku, kinnistusraamatu, äriregistri ning Riigi Teataja andmebaasid. 2019. aasta jooksul oli riigil kavas varundada veel kümme kõige kriitilisemat andmekogu.

## Küsimus: Tooge palun näiteid suurandmetest (big data).

**Vastus:**

Uudis andmete olulisuse kohta, mis kirjeldab ühte võimalikku tulevikku.
Autode sensorite abil kogutavad andmed kuuluvad suurandmete kategooriasse.
Kokkuvõtteks võib öelda, et suurandmeid iseloomustamiseks kasutatakse järgnevaid kriteeriume.

Volume – koguhulk on suur.
Velocity – uute saabuvate andmete hulk on suur – andmeid tulvab nagu kosest juurde ja nende põhjal on vaja kohe midagi järeldada. Näiteks ennustuste kohaselt on 2020. aastal arvutisüsteemides loodavate andmete hulk 44 korda suurem kui 2009. aastal.
Variety – andmestruktuuride varieeruvus on suur – erinevad formaadid, muutuv struktuur.


**Märksõnad:** suurandmed


---

# Teema: Iseseisva töö projekt

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

**Vastus:**

See pole keelatud, eeldusel, 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.

Rakenduse tasemele andmete kontrolli probleemiks on: 

üleliigsed päringud andmebaasi põhjal, mis kokkuvõttes aeglustavad ORM abil loodud programmi tööd,
kontrollide ebapiisavus selles mõttes, et juhul kui samu andmeid kasutab samaaegselt mitu kasutajat, siis võivad need kontrollid lasta läbi reeglitele mittevastavaid andmeid.


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.

Kuigi eelnev näitab, et ORMi ja andmebaasi avalikku liidest saab koos kasutada, siis praktikas on need alternatiivid.

Alternatiiv 1: Rakendus kasutab andmebaasi läbi ORMi. ORM vahend genereerib ise SQL koodi, millega loetakse ja muudetakse andmebaasis andmeid otse baastabelites. Selleks, et piirata kasutajate juurdepääsu teatud tingimustega tabeli ridadele, pakuvad andmebaasisüsteemid vahendeid nagu turvapoliitikad (PostgreSQL) või peeneteralised juurdepääsupiirangud.
Alternatiiv 2: Rakendus kasutab andmebaasi läbi avaliku andmebaasi liidese, mille realiseerimiseks kasutatakse andmebaasis loodud vaateid, rutiine ja materialiseeritud vaateid e hetktõmmiseid. Rakendus ei pöördu otse baastabelite poole, vaid kasutab nendes olevaid andmeid läbi avaliku liidese.


## Küsimus: Kas "Andmebaasid II" projekti tegemisel tuleb tagada kooskõla "Andmebaasid I" projekti mudelitega?

**Vastus:**

Jah tuleb. Mudel on reaalsuse lihtsustatud esitus. Olen seisukohal, et mudelite koostamisel tuleb südamest ja järjekindlalt teha seda esitust võimalikult täpselt. Kui süsteemi arendamise käigus tekib juurde uusi nõudmisi, siis tuleb üritada mudelit ja realisatsiooni kooskõlas hoida.

Muidu tekib olukord, et keegi uurib heauskselt seda mudelit, kulutab selle juures aega, aga siis saab teada, et TEGELIKULT käivad asjad hoopis teisiti. See mudel, see oli lihtsalt üks vanaks läinud joonistus/tekstimass, mida poleks tasunud üldse vaadatagi. AEG on midagi, mida mingi rahaga tagasi/juurde osta ei õnnestu. Kui eesmärgiks oli saada aru praeguse süsteemi versiooni toimimisest, siis kahjuks sellise mudeli vaatamiseks kulunud aeg oli kaotatud aeg.

Leian, et kui ei suudeta tagada mudeli ja realisatsiooni kooskõla, siis ei tohiks mudelit presenteerida olemasoleva süsteemi kirjeldusena. Sellised mudelid tuleks säilitada selge märkega - ajalooline mudel.

"Andmebaasid II" projekt ei näe ette ajalooliste mudelite esitamist. Töö suhteliselt väikest mahtu arvestades oodatakse projektide autoritelt tarkvara ja mudelite kooskõla tagamist.

Kui "Andmebaasid I" projekt on tehtud töövihiku põhjal (siia alla kuuluvad ka projektita üliõpilastele välja pandud kolm projekti), siis tuleb andmebaasis realiseerida kõik need kitsendused, mida kontseptuaalne andmemudel ette näeb - kitsenduste kontseptuaalsest andmemudelist eemaldamine ei ole lubatud. Kitsendusi kontseptuaalsesse andmemudelisse ja sealtkaudu ka andmebaasi juurde lisada on lubatud! 

## Küsimus: Kas iseseisva töö jõuab valmis ainult praktikumides tööd tehes?

**Vastus:**

Arvan, et ei jõua. Hindan, et kui praktikumides tõhusalt töötada, siis võiks valmis jõuda 50-75% protsenti projektist (väga palju sõltub ka tegijatest). Kindlasti aitab praktikumides tegemise kiirust ja kvaliteeti parandada see, kui olete juba enne praktikumi algust lugenud samm-sammulise juhendi ülesannet ning kodulehele pandud seda toetavaid materjale.

Kui teete praktikumis tööd ja siis kaotate tehtud töö ära (pole versioonihaldust), siis ei pruugi muidugi ka nii palju valmis saada. Seega olge palun hoolsad!

## Küsimus: Kas iseseisva töö tegemisel on võimalik seda automaatselt kontrollida ja saada seega töö kohta jooksvalt tagasisidet?

**Vastus:**

Jah on. Teie töö hindamiseks kasutatakse automatiseeritud disaini kontrollimise vahendit (erinev tarkvara PostgreSQL ja Oracle jaoks, kuid need lähtuvad samast põhimõttest). Teil on võimalus jooksvalt ise oma andmebaasi selle abil analüüsida. Eeldus on, et andmebaas on apex.ttu.ee serveris (see on muide projekti reeglitega nõutud).
Vahend käivitab andmebaasi süsteemikataloogi põhjal päringuid. Osa päringuid suudavad leida vigu. Osa aga otsivad andmebaasi disainist halva lõhnaga kohti (vt halvasti lõhnav disain ja halvasti lõhnav kood). Halvasti lõhnavad kohad ei takista andmebaasi ja seda kasutavate süsteemide toimimist, kuid muudavad andmebaasi kasutamise, haldamise või arendamise mingis aspektis raskemaks kui see võiks olla. Halvasti lõhnavad kohad on sügavamate probleemide sümptomid. Nende probleemide lahendamine aitab koodi/mudelit/disaini/arhitektuuri puhastada. Halb lõhn on tehnilise võla tunnus. Tehniline võlg tähendab, et "asi" töötab, kuid saaks olla sisemiselt tehtud paremini. Kuna praegu on seal midagi "üle jala" lastud, siis see on probleem tulevikus, kui "asja" on vaja edasi arendada. Kliendile kiiresti töötava asja üleandmiseks on võetud võlga tuleviku arenduste arvelt. Tehnilist võlga aitab vähendada refaktoreerimine.
Vahend on mõeldud andmebaasi osaliseks staatiliseks verifitseerimiseks – kontrollimiseks, kas andmebaas vastab tehnilistele nõuetele. Vahendi kasutamine aitab vastata küsimusele: Kas andmebaasi tehakse õigesti? Staatiline tähendab, et kontrollimiseks vaadeldakse andmebaasi struktuuri ja käitumise kirjeldust, mitte ei viida andmebaasi põhjal läbi tegevusi (see oleks dünaamiline verifitseerimine).
Verifitseerimine ei ole sama mis valideerimine. Andmebaasi valideerimine peab vastama küsimusele: Kas andmebaas võimaldab hoida kõiki neid andmeid, mida kasutajal on vaja hoida (st kas vastab kasutajate nõudmistele, kas teeme õiget andmebaasi)? Kontroll, kas andmebaasi disaini mudel realiseerib andmebaasi vastavalt kontseptuaalses andmemudelis esitatud nõuetele, läheb valideerimise alla. Probleem on, et need nõuded võivad olla vananenud või valesti kirja pandud. Andmebaasi valideerimine annab vastuse, kas andmebaas ka tegelikult nõudeid täidab.
Kui teete oma projekti PostgreSQLis, siis minge aadressile. Logige sisse kasutades apexi kasutajanime ja parooli. Valige kontrollitav andmebaas. Ilmselt on see samasuguse nimega nagu ühe projekti tegija kasutajanimi ja sisaldab tema matriklinumbrit. Valige test "Databases II (fall 2019)". Vaadake päringu tulemusi, milles on üks või rohkem rida. Selleks, et tulemuses oleksid vaid päringud, mis tagastavad vähemalt ühe rea, vajutage nupule "Execute and show only queries that return rows". Iga päringu korral lugege kirjeldust, vaadake tulemusi. Kui päringute käivitamisel on valitud "Generate SQL statements to fix problems", siis väljastab programm mõningate probleemide puhul nende lahendamiseks mõeldud SQL lauseid.
Päringuid on erinevat tüüpi.

General (üldine): päringud, mis otsivad andmebaasist spetsiifilist infot, kuid otsuse selle kohta, kas midagi on õigesti või valesti peab tegema inimkasutaja, kes tulemust vaatab.
Flaw detection (probleemide otsimine): päringud, mille tulemuses olev iga rida osundab mingile võimalikule disaini probleemile/veale. Siiski on võimalikud vale-positiivsed ja vale-negatiivsed tulemused.
Software measure (tarkvara mõõdik): päringud, mis arvutavad andmebaasi skeemi põhjal mingi arvulise väärtuse.

Usaldusväärsus on hinnang sellele, kuidas päring oma eesmärke täidab.
Soovi korral võite kasutada ka kasutajaliidese uut versiooni. Päringud on samad, kasutajaliides erinev. See keskkond ei paku võimalust väljastada leitud probleemide lahendamiseks mõeldud SQL lauseid.
Keskkonnas on mitmeid teste. Testi "Quick test" alla on koondatud probleemide otsimise päringud, mille puhul tulemuses olev iga rida viitab suure tõenäosusega sellele, et andmebaasi disainis on probleem/viga.PostgreSQL jaoks koostatud päringud on avatud lähtekoodiga ja on avaldatud otsimist võimaldavas kataloogis SIIN.
Kui teete oma projekti Oracles, siis minge aadressile. 990999 tuleb asendada matrikli numbriga, mida kasutate projekti tulemusena loodud andmebaasiobjektide nimedes. Oraclele on loodud palju vähem kontrolle kui PostgreSQLile (üks põhjus, miks eelistada iseseisva töö andmebaasisüsteemina PostgreSQLi) ning Oracle kontrollpäringute täitmine võtab PALJU rohkem aega kui PostgreSQL päringute täitmine.
Võite neid päringuid regulaarselt ise käivitada ja interpreteerida üritada. Küsimuste korral pöörduge õppejõu poole. Oleks väga hea, kui mõnes semestri lõpu praktikumis, kui projekt juba valmis saama hakkab, jõuaksite koos õppejõuga need päringu tulemused üle vaadata.
Need süsteemid võimaldavad andmebaasides põhimõtteliselt samasugust analüüsi kui rakendustes programmid SonarQube ja PVS-Studio. Siit saate näitena lugeda kolme avatud lähtekoodiga andmebaasisüsteemi (PostgreSQL, MySQL, Firebird) koodi kvaliteedi võrdlust, milleks samuti kasutati lähtekoodi staatilist analüüsimist. PostgreSQL ja Oracle näitel ei analüüsita mitte otse lähtekoodi vaid selle käivitamise tulemust (loodud andmebaasiobjekte). Tegemist ei ole programmi dünaamilise analüüsiga, sest dünaamilise analüüsi korral käivitatakse programm erinevate sisenditega ja jälgitakse selle käitumist/väljundit. Andmebaaside korral tähendaks see erinevate päringute ja andmemuudatuste tegemist ning näiteks täitmisaja ning täitmiseks kasutatud plaanide jälgimist/uurimist.

## Küsimus: Kas lävendi ületanud projekti saab parandada?

**Vastus:**

Lävendi ületanud projekti parandada ei saa. Kogu protsess oli organiseeritud nii, et parandamine toimus enne esitamist. Suuremas osas praktikumidest toimub iseseisva töö projekti tegemine. Selle käigus peaks olema piisavalt võimalusi tehtud tööle jooksvalt tagasiside saamiseks. Kui soovite uusi punkte, siis tuleb teha uus projekt uuel teemal.

## Küsimus: Kas ma võin "Andmebaasid II" projektis realiseerida teise töökoha kui "Andmebaasid I" projektis?

**Vastus:**

Jah võite, kuid see ei ole mingil juhul kohustuslik. Ka "Andmebaasid II" kehtib reegel, et realiseeritaval töökohal peab toimuma nii andmete lugemist kui ka andmete muutmist.

Kui tegite "Andmebaasid I" projekti töövihiku järgi ning realiseerisite juhataja töökoha, siis loomulikult võite soovi korral realiseerida (funktsionaalsuselt mahukama) X halduri töökoha, kuid mahuliselt on piisav ka juhataja 
töökoht.

Aine projekt on sisuliselt migreerimise projekt koos koodi puhastamisega. Töö käigus on vaja süsteem viia üle ühelt platvormilt teisele. On loogiline, et rakenduses realiseeritav töökoht jääb samaks.

Realiseeritav töökoht võib seada piiranguid rakenduse tegemiseks kasutatavale vahendile. Üldpõhimõte on, et "Andmebaasid II" aines realiseeritav arhitektuuriline lahendus (kahekihilne klient/server süsteem, kus rakendus on kasutaja arvutis vs. n kihiline (n>2) veebipõhine süsteem) peab sobima ka pärisellu. Süsteemi sisemiste pädevusalade puhul sobib nii kasutaja arvutis olev rakendus kui veebirakendus. Välised pädevusalad (kõikvõimalikud kliendid ja partnerid) vajavad veebirakendust.

**Märksõnad:** iseseisev töö, projekt, migreerimine

## 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".
Valige palun Iseseisva töö esitamine=> Sisesta esimest korda. Lugege seal ülesande teksti. Ülesande vastusena saab saata ka faile. Selleks tuleb ülesandesse esmakordsel sisenemisel vajutada lehe lõpus nupule "Saada ära". Seejärel tuleb ülesande juures vajutada lingile "paranda/muuda". Nüüd on ülesande küsimustega seotud lingid "Saada fail". Sellele vajutades tekib lehe ülaosas võimalus faili valimiseks. Faili serverile saatmiseks tuleb vajutada nupule "Saada ära".
NB!Iseseisva töö lõpliku versiooni esitamisel peab vastuse saatma üks projekti liige.

## Küsimus: Kuidas kirjeldada kujundlikult (metafoore kasutades) õppeaine aineprojekti sisu?

**Vastus:**

Tehnilist terminoloogiat kasutades tähendab aineprojekt süsteemi (andmebaasi ja rakenduse) migreerimist uuele platvormile ning selle käigus andmebaasi/rakenduse/mudelite refaktoreerimist. Andmebaas tuleb realiseerida uues andmebaasisüsteemis ning rakendus (mille tegemise vahendi valik on vaba) tuleb panna seda andmebaasi kasutama. Andmebaasi ja rakenduse skoop võrreldes lähteprojektiga ei muutu (välja arvatud see, et tuleb realiseerida ka kasutusjuht "Tuvasta kasutaja", mis lähtesüsteemis on ilmselt tegemata).

Kujutage andmebaasisüsteemi ette restoranina. Iga restoran pakub külastajale oma menüüd (näiteks andmetüüpe ja andmebaasi programmeerimise võimalusi), kuid selles on ka omad kiiksud ja piirangud (näiteks klient ei saa ilma tellimata pikalt istuma jääda või et lemmikloomaga sisse ei lubata). Samuti on restorani külalistel oma kindlad eelistused (näiteks taimetoit), mis on antud juhul kirja pandud kontseptuaalsesse andmemudelisse. Sisuliselt on Teie ülesanne minna uude (paremasse, kallimasse) restorani ning arvestades enda soovide ja piirangutega ning restoranis pakutavaga teha restoranis tellimus ja lasta see ära täita (lauda tuua).

**Märksõnad:** metafoor, näide, iseseisev töö, projekt, andmebaasisüsteem, restoran

## Küsimus: Kuidas PostgreSQLis tehtud iseseisva töö andmebaasi kiiresti iseseisvalt kontrollida?

**Vastus:**

Kui teete projekti PostgreSQLis, siis saate oma andmebaasi testimiseks tarvitada kiirtesti, kuhu on koondatud kontrollid, mille tulemused osutavad suure tõenäosusega probleemile/veale. Tähelepanu! Kui kiirtest midagi ei leia, siis see ei garanteeri probleemide/vigade puudumist. Samuti võib kiirtesti tulemuses olla nii väärpositiivseid kui väärnegatiivseid tulemusi.
Kiirtesti käivitamiseks minge andmebaaside disaini kontrollimise rakendusse (vanem kasutajaliides; uuem kasutajaliides). Valige huvipakkuv andmebaas. Testiks valige Quick test. Andke korraldus test käivitada. Vanemas kasutajaliideses vajutage selleks nupule "Execute and show only queries that return rows".
Stiilinäiteks on päring, mis loendab kokku andmebaasis kasutaja poolt loodud trigereid ja reegleid. Tulemuses on rida vaid siis, kui nende arv on alla kolme. 
WITH activedb AS (SELECT trigger_schema, trigger_name, 'TRIGGER' AS type
FROM INFORMATION_SCHEMA.triggers
WHERE trigger_schema NOT IN (SELECT schema_name
FROM INFORMATION_SCHEMA.schemata
WHERE schema_name<>'public' AND
schema_owner='postgres' AND schema_name IS NOT NULL)
UNION SELECT r.schemaname,  r.rulename, 'RULE' AS type
FROM pg_catalog.pg_rules r, pg_catalog.pg_namespace n, pg_catalog.pg_user u
WHERE  r.schemaname = n.nspname AND n.nspowner = u.usesysid AND 
(n.nspname = 'public' OR u.usename <> 'postgres'))
SELECT 'Too few triggers and/or rules, must be at least 3' As comment, (SELECT Count(*) AS cnt FROM activedb) AS cnt
WHERE (SELECT Count(*) AS cnt FROM activedb)<3;


Mõned kommentaarid.

Skeemis pg_catalog on PostgreSQL süsteemikataloogi baastabelid.
Skeemis INFORMATION_SCHEMA on süsteemikataloogi baastabelite põhjal defineeritud standardse struktuuriga vaated.
Trigerite ja reeglite otsimisel on vaja jätta välja süstemikataloogis loodud trigerid ja reeglid.
WITH klausel võimaldab defineerida käesoleva lause piires kasutatavaid virtuaalsed tabelid, millele lauses saab peale defineerimist nime kasutades viidata. See võimaldab SQL koodi paremini struktureerida. WITH klauslis võib olla järjest mitu alampäringut. Igas sellises alampäringus saab viidata kõikidele selles lauses eespool defineeritud alampäringutele.
PostgreSQLis võib kirjutada SELECT lause, kus puudub FROM klausel, aga on WHERE klausel. WHERE klausli eesmärgiks on antud juhul tagada, et päringu tulemuses on rida vaid siis, kui trigerite ja reeglite koguarv on alla kolme.
SELECT klauslisse saab kirjutada konstante ja ka mittekorreleeruvaid skalaarseid alampäringuid. Nende väärtuseid korratakse kõikides päringu tulemuseks olevates ridades.
Väikeste andmehulkade korral ei ole PostgreSQLis NOT IN konstruktsiooni kasutamine probleem, kuid suurte andmehulkade korral tuleks sellest töökiiruse huvides hoiduda.


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

**Vastus:**

Tähtajaga 13. september 2019 tuleb registreerida iseseisva töö teema, rakenduses realiseeritav töökoht, esialgne kasutatavate vahendite valik ja üliõpilased, kes seda tööd üheskoos teevad. Kui otsustate hiljem teha midagi teisiti, kui vastuses kirjas, siis õppejõu teavitamiseks piisab ainult selle vastuse muutmisest.
Iseseisva töö registreerimiseks valige õppekeskkonna vasakpoolsest menüüst Kiirvalik=> Vastamine ning avanenud leheküljelt ülesanne "Iseseiseva töö registreerimine".
Ühte tööd võib teha koos kuni kolm inimest. Kui teete tööd mitmekesi, siis peab ülesandele vastama ainult üks tegijatest.
Kui teete projekti üksinda, kuid otsite kaaslast, siis on võimalik seda soovi iseseisva töö teema registreerimisel väljendada.
Nimetan järgnevalt ka mõningaid tüüpilisi probleeme vastustes ja loodan, et Te väldite neid.

Teisi andmebaasisüsteeme peale PostgreSQL ja Oracle iseseisva töö tegemiseks kasutada ei saa.
Oraclet ja MS Accessi on raske koos kasutada ja seega ei sobi MS Access Oracle andmebaasi rakenduse tegemiseks. Kui soovite teha andmebaasirakenduse MS Accessis, siis kirjutab see andmebaasisüsteemina ette PostgreSQLi.
"Andmebaasid I" realiseeritud "Juhataja töökoht" on sobilik ning piisav realiseerimiseks ka "Andmebaasid II".
Oracle Application Express vahendi abil ei saa (õigem oleks öelda, et "on väga tülikas") teha PostgreSQL andmebaasi kasutamiseks mõeldud veebirakendust.
pgApex vahendi abil ei saa (õigem oleks öelda, et "on väga tülikas") teha Oracle andmebaasi kasutamiseks mõeldud veebirakendust.
Enterprise Architect ja Rational Rose ei ole rakenduse tegemise vahendid, vaid on modelleerimisvahendid (CASE).


## Küsimus: Kuidas saada juurdepääs iseseisva töö tegemiseks mõeldud serverile?

**Vastus:**

Saamaks juurdepääsu serverile apex.ttu.ee, tuleb täita esimene punkt ülesandest nr 1, mis on kataloogis Iseseisva töö projekti tegemine/Töö praktikumis(samm-sammuline juhend). 

Seda juurdepääsu läheb vaja juba teises praktikumis.

## Küsimus: Kui projekti esimest korda hinnati ja see ei ületanud lävendit, siis kas peale parandamist projekti uuesti esitamisel saan hilinenud esitamise eest täiendavaid miinuspunkte?

**Vastus:**

Kõigepealt tahan rõhutada, et kursus on kavandatud selliselt, et projekti tegijal oleks võimalik saada korduvat ja põhjalikku tagasisidet juba ENNE esimest korda projekti esitamist. Enamik praktikume on pühendatud projekti tegemisele, andmebaasi disaini kontrolliks on automaattestimise võimalus ning sellest, mida üldse hinnatakse, annab ülevaate detailne hindamismudel. Loodetavasti tagab see, et projekt ületab lävendi esimesel korral ja suure varuga. Kui aga nii ei juhtu, siis on üliõpilasele pakkuda päästerõngas, millel on küll paraku hind.

Kui iseseisev töö esitada peale parandamist teistkordselt, siis väheneb töö punktisumma kümne punkti võrra. Täiendavaid hilinemise miinuspunkte ei anta. Seega, kui projekti esmakordsel esitamisel sai see hilinemise eest viis miinuspunkti, siis neid punkte ei arvestata (st hilinemise/parandamise tõttu kaotab projekt kas viis või kümme punkti, mitte 5+10=15 punkti).
Juhin tähelepanu, et hindamismudeli alusel saate seda kaotust kuhjaga kompenseerida, täites lisapunkte andvaid ülesandeid.

Lisaks kaotate projekti uuesti esitamise vajaduse tõttu kõik praktikumides kogutud aktiivsuspunktid. Viimase põhjendus on, et kõik need punktid saadi praktikumides aktiivselt projektiga tegelemise eest. Tunnis kohapeal punkte kirja pannes on õppejõul raske hinnata, kas tegelemine oli aktiivne või näiline/vähetulemuslik. Kui tegelemine oli aktiivne, siis jõudis projekt kindlasti nii kaugele, et ületas esimese korraga lävendi. Kui tegelemine oli näiline/vähetulemuslik, siis võis tekkida projekti valmissaamisega probleeme ja lävend võis jääda esimesel katsel ületamata. Siis pole ka põhjust aktiivsuses eest punkte saada.

## Küsimus: Miks on hindamismudelis nii palju võimalikke miinuspunkte?

**Vastus:**

Hindamismudeli leiate kataloogist Aine korraldus. 

Kõik need võimalikud miinuspunktid vastavad võimalikele vigadele, mida projektis võib teha. Nende sellisel viisil väljatoomise üks oluline eesmärk on anda võimalikult kiiresti ja võimalikult täpselt tagasisidet. Mida rohkem on väljatoodud vigu, seda kiiremini ja täpsemalt saab tagasisidet anda. Kiirust parandab, et konkreetse vea kohta pole vaja kommentaari nii pikalt välja kirjutada, sest see on antud juba vea kirjeldusega.

Juba peale seda kui olin selle hindamismudeli kasutusele võtnud esines Tarkvarateaduse instituudi seminaril külalisettekandega Dr Antonette Mendoza, kes on vanemlektor Melbourne'i Ülikoolis Austraalias. Tuleb välja, et seal on välja töötatud küllaltki sarnane süsteem suulistele eksamitele kiire tagasiside andmiseks.  See süsteem on realiseeritud mobiiliäpina. Hindaja kuulab suulist vastust ning saab umbes 200 eeldefineeritud vea kirjelduse hulgast valida neid, mis iseloomustavad tema poolt kuulatavat vastust. Eelnevalt saab hindaja määrata vigadele kaalud. Hindamise käigus valitud vigade ja nende kaalude põhjal arvutab äpp hinde ja muudab selle koos vigadega hinnatavale nähtavaks.

Täpsemal saab selle süsteemi kohta lugeda: 

Mendoza, A., Shallcross, D.,  2016. Assessment and rapid feedback for oral presentations. Proceedings of Sixth International Symposium of Engineering Education. pp. 5-12 [WWW] link artiklit sisaldavale raamatule

Hindamismudelis on mitmeid miinuseid välja toodud vaid sellepärast, et projekti saab teha ka vabal teemal. Tehes edasi eeldusaines alustatud töövihiku projekti või tehes projekti siin aines etteantud analüüsiprojekti järgi, ei ole võimalik neid vigu teha.

Tegelikult saaks ka meie aines oleva hindamismudeli arendada edasi veebipõhiseks universaalseks süsteemiks, kus saaks hinnata erinevate õppeainete erinevaid teadmiste kontrolle. See võiks olla isegi üks lõputöö teema.

Hindamismudeli eesmärgid on kokkuvõtlikult järgmised.

Aidata anda tagasisidet võimalikult kiiresti.
Võimaldada projekti tegijatel juba tegemise käigus teada saada, mida hinnatakse.
Ühtlustada erinevate projektide hindamist selles mõttes, et nende hindamisel pööratakse tähelepanu samadele aspektidele.
Aidata vähendada hindamise subjektiivsust, st muuta hinne rohkem põhjendatuks.



**Märksõnad:** Hindamismudel, hinne, Excel, projekt, iseseisev töö

## Küsimus: Milline on MINIMAALNE materjalide hulk, mille lugemisest piisab projekti edukaks tegemiseks?

**Vastus:**

Piisab hindamismudelist (siin kataloogis) ning näiteprojektist kui NÄITEST (siin kataloogis) selle kohta, mis tuleb valmis saada.

Võite läheneda arendusele testimispõhise arenduse põhimõttest lähtuvalt. Kõik hindamismudeli punktid on ühiktestid. Kõigepealt on nõue (mis peab olema projektis tehtud). Selle nõue kohta kirjutatakse test (sissekanne hindamismudelis), mis on ühtlasi nõude spetsifikatsioon. Testi esmakordselt jooksutades kukub see läbi, sest nõue pole täidetud. Seejärel tuleb teha projekti tulemites muudatus, et nõue saaks täidetud ja test läbitud. Pidevalt tuleb  tehtud tööd refaktoreerida. Erinevalt tarkvarast, kus ideaalis peaksid kõik ühiktestid vigadeta läbi jooksma, on siin latt madalamal, sest osa teste võib ebaõnnestuda - peaasi, et vähemalt 31 punkti kokku tuleb.

Siiski soovitan materjale rohkem lugeda, sest seal on kirjas, mitte ainult MIDA teha, vaid ka MIKS tuleb seda teha. Kas usaldaksite arsti, kes on õppinud selgeks plaastri peale panemise, süsti tegemise või retsepti väljakirjutamise protsessi, kuid ei tea midagi haigustest? Või kas usaldaksite prokuröri/kohtunikku/advokaati, kes teab küll kohtu protseduure, kuid seaduseid ei tunne ("Riigi Teataja on ju avalik allikas ja seda saab alati vajadusel guugeldada" - iroonia, kui keegi aru ei saanud). IT-spetsialistil on sama vastutusrikas töö.

**Märksõnad:** hindamismudel, näiteprojekt, projekt, iseseisev töö

## Küsimus: Milliste andmete kogumist peaksin infosüsteemi projektis ette nägema?

**Vastus:**

Koguma peaks ainult selliseid andmeid, mida tööülesannete täitmiseks vaja läheb. Spordiklubid koguvad mõistliku põhjuseta isikuandmeid.

Isikuandmete töötlemist reguleerib isikuandmete kaitse seadus. Seaduste mitte tundmine ei vabasta nende täitmisest. Infosüsteemid (sh andmebaasid) peavad olema kooskõlas seadustega - seadused moodustavad ühe osa keskkonnast, milles infosüsteemid ja andmebaasid eksisteerivad.

## 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):

Tõusete loengu või praktikumi alguses või lõpus püsti ja annate oma soovist kõigile ruumis viibijatele kõva häälega teada.
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 Teie soovi õppeaine kodulehel. Kui leiate peale seda 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.
 


---

# Teema: Oracle

## Küsimus: Kas Oracle andmebaasi saab laadida andmeid ka muul viisil kui väliste tabelite kaudu?

**Vastus:**

Jah saab, kasutades SQL*Loader vahendit.

## Küsimus: Kust saada head ja põhjalikku infot Oracle andmebaasisüsteemi kohta?

**Vastus:**

Üks hea koht Oracle kohta käivatele küsimustele vastuse saamiseks on Ask Tom lehekülg. Selle taga on Oracle ekspert Thomas Kyte koos abilistega. T. Kyte on kirjutanud ühed kõige paremad raamatud Oracle kohta nagu näiteks see (Kuidas kasutada O'Reilly digitaalset platvormi?). Ask Tom lehel esitavad inimesed üle maailma küsimusi Oracle kohta, neile vastatakse ning vastuste põhjal tekib sageli pikk diskussioon koos täiendavate (koodi)näidetega.

## Küsimus: Miks on Oracle's realiseeritud rutiinides vaja kasutada bind variables?

**Vastus:**

Hea selgitus.

## Küsimus: Milleks on hea Oracle kitsenduse seisund DISABLE VALIDATE?

**Vastus:**

Kui kitsendus luuakse sellises seisundis, siis andmemuudatuste korral kitsenduse kontrolli ei toimu, kuid tabelis olemasolevad andmed peavad olema kitsendusega kooskõlas - vastasel juhul kitsendust ei looda.

Tsitaat Oracle dokumentatsioonist: "This feature is most useful in data warehousing situations, because it lets you load large amounts of data while also saving space by not having an index. This setting lets you load data from a nonpartitioned table into a partitioned table using the exchange_partition_subpart clause of the ALTER TABLE statement or using SQL*Loader. All other modifications to the table (inserts, updates, and deletes) by other SQL statements are disallowed."

Ühesõnaga, tabelis olevad andmed peavad kitsendusele vastama, kuid uute andmete lisamisel kontrolli ei teostata. Andmeid saab sellisesse tabelisse lisada just SQL*Loader abil.

**Märksõnad:** kitsendus

## Küsimus: Millist regulaaravaldist tuleks kasutada Oracles, et kontrollida andmebaasi tasemel kolmetähelisi riigi koode?

**Vastus:**

Märkus: Paraku ei toeta Oracle andmebaasimootor BOOLEAN tüüpi ja seetõttu tuleb järgnevas PL/SQL anonüümses plokis tulemuse väljastamiseks asendada tõeväärtus tekstilise väärtusega. 
DECLARE result BOOLEAN; BEGIN result:=REGEXP_LIKE('EST', '^[A-Z]{3}$'); IF (result=true) THEN dbms_output.put_line('TRUE'); ELSE dbms_output.put_line('FALSE'); END IF; END; /
Oracle APEXis, SQLclis ja SQL*Plusis annab see test tulemuseks TRUE, Oracle SQL Developeris (versioon 20.2) annab see tulemuseks FALSE.
Kui tabelis on selline CHECK kitsendus (nt veerul riigi_kood), siis Oracle APEXis ja SQL Plusis õnnestub sellise CHECK kitsendusega tabelisse kenasti andmeid lisada. Samas SQL Developeris öeldakse andmete lisamisel (nt riik koodiga EST), et CHECK kitsenduse viga - nii INSERT lauseid käivitades, kui otse tabelisse andmeid lisades.
Üha rohkem hakkab tunduma, et see on mingi SQL Developeri mulle tundmatu eripära.
Soovi korral võite kasutada regulaaravaldise mustrit '^[[:upper:]]{3}$', mis toimib tõrgeteta kõigis minu kasutatud Oracle andmebaasisüsteemiga suhtlemiseks mõeldud keskkondades.
Pange tähele, et mustrid '^[[:upper:]]{3}$' ja '^[A-Z]{3}$' pole samaväärsed, sest esimene lubab ka täpitähti (ÕÄÖÜ), kuid teine mitte. Kuna riikide koodides pole selliseid täpitähti, siis oleks mustrina eelistatud '^[A-Z]{3}$'.
PostgreSQLis toimib regulaaravaldis '^[A-Z]{3}$' nii nagu peab.

## Küsimus: Teatavasti saavad Oracles (12c Release 1.0.1) enamik identifikaatoreid (nt tabelite ja kitsenduste nimed) olla maksimaalselt 30 baidi suurused. Kas on mõni abivahend, mis lihtsustakse andmebaasikeele lausete kirjutamisel selle pikkuse kontrollimist?

**Vastus:**

See veebipõhine vahend pakub võimaluse pikkust kontrollida. Meie kasutatavates CASE vahendites (Enterprise Architect, Rational Rose) pole paraku sellist kontrolli sisse ehitatud. Soovijad saaksid sellise vahendi luua, kasutades nende CASE vahendite laiendamise võimalusi, kuid see pole käesoleva kursuse teema.

## Küsimus: Teeme projekti Oracles ning mitmekesi. Millisesse andmebaasi tuleb panna rakenduse andmebaasiobjektid? Kuidas me üksteise tehtud andmebaasiobjektidele ligi pääseme?

**Vastus:**

Oracle andmebaas on serveris juba loodud. Logite Oracle serverisse olemasoleva andmebaasi kasutajana ja hakkate kasutama oma kasutajanimele vastavat skeemi. Kui loote mõne skeemiobjekti (nt tabeli), siis pannakse see Teie kasutajanimele vastavasse skeemi. Skeemile vastav kasutaja on kõigi oma skeemis olevate objektide omanik, st näeb neid ja saab hallata.

Kõigil samal aastal serverile juurdepääsu saanutel on üks ja sama Oracle kasutajanimi ning parool, st kasutate ühte ja sama skeemi. Kui teete projekti mitmekesi, siis valige ühe enda rühma liikme matriklinumber, mida kasutate kõikides identifikaatorites (v.a tabellite veerud ning pakettides olevad rutiinid). Nii on SQL Developeris lihtne välja filtreerida just Teie rühma poolt loodud andmebaasiobjektid. Matriklinumbrite kasutamine identifikaatorites on vajalik, et vältida nimekonflikte (skeem on nimeruum).

## Küsimus: Üritan muuta Oracles tabeli struktuuri või tabelit kustutada, kuid saan veateate ORA-00054: resource busy and acquire with NOWAIT specified or timeout expired. 

Milles on viga ja kuidas seda lahendada?

**Vastus:**

Viga tuleb sellest, et üritate kustutada tabelit, milles olevaid andmeid mõni teine transaktsioon samal ajal muudab. Lisan vastusele seda illustreeriva pildi.
Sessioonis 1 loodi tabel ja lisati sellesse rida. INSERT lausega algas uus transaktsioon. Kuna Oracle ei tööta transaktsioonide automaatse kinnitamise režiimis, siis see transaktsioon kestab seni kuni see lõpetatakse või kestab sessioon, milles transaktsioon algatati. Kui tabelis andmeid muudetakse, siis paneb see tabelile luku, mis ei lase samal ajal tabeli struktuuri muuta või tabelit kustutada. Sellest tuleb sessioonis 2 veateade.
Selline olukord saab tekkida, kui töötate tabelitega mitmekesi - üks muudab andmeid, teine tahab samal ajal neid kustutada.
Lahenduseks on sessioonis 1 transaktsiooni lõpetamine. Transaktsiooni kinnitamiseks on COMMIT lause ja transaktsiooni tühistamiseks ROLLBACK lause. Peale seda võib sessioonis 2 uuesti kustutamist proovida.


---

# Teema: PostgreSQL

## Küsimus: Kas ja kuidas pääseb väljastpoolt ülikooli ligi õppeserveris olevale PostgreSQL andmebaasisüsteemile?

**Vastus:**

Serveritega seotud turvalisuse küsimustega tegeleb IT osakond. Nad on võtnud suuna sellele, et kaugligipääsudeks ülikooli serveritele peab hakkama kasutama autenditud VPNi või võtmetega SSHd. Kaugligipääs (st ligipääs väljastpoolt Tallinna Tehnikaülikooli arvutivõrku) apex.ttu.ee PostgreSQL pordile (5432) on blokeeritud järgmiste eranditega. Kaugligipääs on võimalik:

Tallinna Tehnikaülikooli wifist, 
eduroamist,
kodust läbi TORU.ttu.ee https://wiki.ttu.ee/et:juhendid:it:doc:lib_toru.


PostgreSQL andmebaasile rakenduse tegijad peaksid arvestama järgnevaga.

Kui teete kahekihilise süsteemi, kus rakendus on kliendi arvutis (nt kasutades MS Accessi või Javat), siis kodus rakendusega tegeledes on kõigepealt vajalik luua TORU.ttu.ee kaudu VPN ühendus. Muide, samal viisil saate kasutada Tallinna Tehnikaülikooli raamatukogu andmebaase olles ise väljaspool ülikooli. 
Veebirakenduste tegijad - apex.ttu.ee serveris on PHP ja pgApex. Kui soovite rakenduse jaoks kasutada mõnda muud serverit/vahendit, siis tuleks kas valida Tallinna Tehnikaülikooli võrgus olev server (mõnest teisest ainest) või luua rakenduses apex.ttu.ee serveriga SSH ühendus (näide).


Kui soovite kodust PostgreSQLiga töötamiseks kasutada pgAdmini, siis tuleb teha ühte järgnevast.

Luua kõigepealt TORU.ttu.ee kaudu VPN ühendus.
Luua ühendus kasutades SSH tunnelit (vt lisatud faili).


Andmebaas on kohustuslik paigutada apex.ttu.ee serverisse, sest seal on automaattestimise vahendid ja õppejõul on sellele hindamiseks vajalik täielik juurdepääs.

**Märksõnad:** ODBC,draiver, data source, andmeühenduse spetsifikatsioon

## Küsimus: Kas ja milliseid lisavõimalusi SELECT lausete kirjutajale pakub PostgreSQL võrreldes MS Accessiga?

**Vastus:**

PostgreSQL (ja ka Oracle) pakuvad palju lisavõimalusi. Peaaegu kõik, mida õppisite MS Accessi baasil toimib ka PostgreSQLis või Oracles (võibolla väikeste süntaktiliste erinevustega). Kuid nendes süsteemides saab teha ka palju sellist, mida MS Access ei võimalda. 

Veendumaks, et selliseid lisavõimalusi on olemas, vaadake siia, kerige veidi allapoole, et leida PostgreSQLile pühendatud osa ning proovige seal olevaid SELECT lauseid nt pgAdmin abil käivitada.

Need laused on panus projekti, mis üritab illustreerida erinevaid programmeerimiskeeli ühe ülesande lahenduse abil. Ülesandeks on genereerida ühe õllelaulu sõnad.

Veel üheks allikaks mida uurida on SQLi viimasele sõnale pühendatud ajaveeb. Paljud seal kirjeldatud SQLi võimalused on olemas PostgreSQLis (ja Oracles), kuid mitte MS Accessis.

## Küsimus: Kas kuskil leidub iseseisvaid harjutusülesandeid PostgreSQL admebaasisüsteemi paremaks tundmaõppimiseks?

**Vastus:**

Huvitav keskkond neile, kes tahaksid veebipõhises interaktiivses keskkonnas rohkem PostgreSQLi harjutada.

## Küsimus: Kas oleks otstarbekas siduda domeeniga mingi veeru omadus ja lisada sellele täiendav tabelipõhine piirang? Näiteks andmetüüp, NOT NULL ja tühikutest koosnemise piirang tulev domeeni poolt ja tabelis lisan täiendava piirangu pikkusele.

**Vastus:**

Tehniliselt oleks see võimalik. Ma mõtlen, et hallatavuse mõttes pole see kõige parem, sest pakutud juhul tuleb veerule rakenduvaid CHECK kitsendusi otsida (ja vajadusel muuta kahes kohas) - domeenis ja otse tabeli veeru küljes.

## Küsimus: Kas PostgreSQLis saab genereerida fraktaleid nagu demonstreerib see projekt MS SQL Serveri põhjal?

**Vastus:**

Jah, PostgreSQLis kirjutatud rekursiivsete SELECT lausetega saab genereerida fraktaleid. Näiteid leiab SIIT. Võite nende päringute käivitamiseks kasutada mistahes kursuse serveri andmebaasi. Kasutage käivitamiseks programme psql või pgAdmin.

## Küsimus: Kuidas kutsuda PostgreSQLis välja funktsiooni või protseduuri, mille mõni parameeter on SMALLINT tüüpi?

**Vastus:**

Oletame, et andmebaasis on loodud funktsioon f_lopeta_teenus, mille parameeter p_teenuse_kood on SMALLINT tüüpi.

Üritades seda funktsiooni välja kutsuda lausega: SELECT f_lopeta_teenus(p_teenuse_kood:=436);

on tulemuseks veateade: ERROR:  function f_lopeta_teenus(p_teenuse_kood => integer) does not exist
LINE 1: select f_lopeta_teenus(p_teenuse_kood:=436);

Käivitatav funktsioon valitakse argumentide tüüpide alusel. Vaikimisi eeldus on, et literaali 436 poolt esitatav väärtus kuulub tüüpi INTEGER. Kuid funktsiooni parameeter on hoopis tüüpi SMALLINT. Seega korrektseks väljakutseks on vajalik lause:

SELECT f_lopeta_teenus(p_teenuse_kood:=436::SMALLINT);

::SMALLINT teeb tüübiteisenduse tüüpi SMALLINT.

## Küsimus: Käivitan läbi psqli PostgreSQL andmebaasis CREATE TABLE lauseid. Saan ühe lause peale veateate:

ERROR:  syntax error at or near "CONSTRAINT"
LINE 29: SET CONSTRAINT FK_Isik_Riik FOREIGN KEY (isikukoodi_riik) RE...

Samas selles lauses ei ole SET CONSTRAINT fraasi. Milles on viga ja kuidas seda parandada?

**Vastus:**

Vea põhjus on CREATE TABLE lauses olevas tabeldusmärgis.
Näiteks saan sellise veateate, kui käivitan lause 
1.CREATE TABLE C(c_id INTEGER PRIMARY KEY, 2.    a_id INTEGER NOT NULL, 3.    b_id INTEGER NOT NULL, 4.    CONSTRAINT ak_c UNIQUE (a_id, b_id), 5.    CONSTRAINT fk_c_a FOREIGN KEY (a_id) REFERENCES A(a_id) ON DELETE No Action ON UPDATE Cascade, 6.    CONSTRAINT fk_c_b FOREIGN KEY (b_id) REFERENCES B(b_id) ON DELETE No Action ON UPDATE Cascade 7.);

Veateade: ERROR: syntax error at or near "CONSTRAINT" LINE 6: SET CONSTRAINT fk_c_b FOREIGN KEY (b_id) REFERENCES B(b_id) ...
Viga tekib sellest, et psql ei saa mõnikord tabeldusmärkidega hakkama. Reas nr 5 on võtmesõna UPDATE. Sellele järgneb rea nr 6 alguses tabeldusmärk. See paneb psqli arvama, et UPDATE on eraldi lause.
Kuidas seda probleemi lahendada?

Kustutage skriptist enne käivitamist tabeldusmärgid (tekstiredaktoris Search and Replace funktsioon).
Käivitage skripti pgAdminis (seal seda probleemi ei ole).
Panete (näiteks WinSCP programmi abil) skriptifaili apex.ttu.ee serveris enda kodukataloogi (/home/kasutajanimi - satute sinna sisselogimisel). Seejärel käivitate shelli promptist selle skripti üldise käsuga:
psql -f skriptifaili nimi andmebaasi nimi, kus soovite skripti käivitada
Näiteks järgmine käsk käivitab failis DDL_PostgreSQL.sql olevad laused andmebaasis proov.
psql -f DDL_PostgreSQL.sql proov



## Küsimus: Käivitan PostgreSQLis funktsiooni, kuid seda ei täideta, sest ei leita funktsioonis viidatud tabelit. Mis on viga ja kuidas seda lahendada?

Näide: Lõin andmebaasis funktsiooni f_on_juhataja

SELECT f_on_juhataja(p_kasutajanimi:='joy.hawkins@geekosis.name', p_parool:='Boss');

ERROR:  relation "isik" does not exist

LINE 2: FROM isik INNER JOIN tootaja ON isik.isik_id = tootaja.isik_...

**Vastus:**

Kirjutasite funktsiooni loomise lauses:

SET search_path = 'public, pg_temp'

Tekst, mis on apostroofide e ülakomade vahel, on PostgreSQLi jaoks kokku üks skeemi nimi. PostgreSQL hakkas otsima sellise nimega skeemist tabelit Isik. Kuna sellist skeemi andmebaasis ei ole, siis ei leitud ka tabelit.

Õige on kirjutada otsingutee ilma ülakomadeta:

SET search_path = public, pg_temp

Otsingutee on vajalik, et SECURITY DEFINER funktsioon oleks turvaline.

## Küsimus: Käivitasin PostgreSQLis skripti/päringu/andmemuudatuse, mis "jooksis kinni". Nüüd töötab andmebaasisüsteem aeglaselt ning protsess on lukustanud tabeli/vaate/andmebaasi, mille tulemusena ei saa ma seda muuta ega kustutada. Kuidas "rippuma jäänud" PostgreSQL kasutamise sessioonidest ja nendes algatatud ressursse blokeerivates serveriprotsessidest lahti saada?

**Vastus:**

Lahendust kirjeldatakse siin.

Kokkuvõtlikult:
Tuleb leida konkreetse andmebaasiga seotud sessioonid e seansid. Järgneva päringu võite käivitada tegelikult mistahes PostgreSQLi andmebaasis.


SELECT *                     
FROM pg_stat_activity
WHERE datname='andmebaasi nimi väiketähtedega';


Katkesta serveriprotsess ja lõpeta selle algatanud sessioon.

SELECT pg_terminate_backend(pid);

## Küsimus: Lõin PostgreSQL andmebaasis protseduuri (CREATE PROCEDURE lause). Seda MS Accessi rakendusest välja kutsudes saan veateateid nagu:

Error while preparing parameters.
ERROR: ... is a procedure; Error while preparing parameters.


Milles on viga ja mida selle parandamiseks ette võtta?

**Vastus:**

Protseduurid on PostgreSQLis väga uus asi (lisandusid PostgreSQL 11) ja vanemad draiveri versioonid neid ei toeta. Lahenduseks on asendada serveris protseduurid funktsioonidega.

**Märksõnad:** protseduur, rutiin, funktsioon, ODBC, MS Access, protseduuri väljakutse, VBA

## Küsimus: Millised on PostgreSQLi eelised võrreldes MySQLiga (miks me ei kasuta MySQLi)?

**Vastus:**

Internetis on väljas 2012. aasta juunis Rob Conery poolt Norwegian Developers Conference konverentsil peetud ettekande salvestus. Ettekande esimesed 15 minutit demonstreerivad väga ilmekalt MySQLi puuduseid. SIIN ja SIIN on videos välja toodud puuduste jätkuarutelu.
Soovitan vaadata kogu ettekannet, sest seal tutvustatakse mõningaid huvitavaid PostgreSQLi pakutavaid võimalusi.

Alates 14:30 Multiversioon konkurentsjuhtimine.
Alates 20:30 Tabelite loomine pärimise kaudu ja selle kasutamine suure tabeli sektsioonideks jagamiseks.
Alates 26:30 Foreign Data Wrapper (võimalus teha päringuid paljudest välistest andmeallikatest).
Alates 29:30 Andmetüübid (näitena käsitleti timestamp with timezone tüüpi, massiivitüüpe, liittüüpide loomise võimalust).
Alates 44:30 on kokkuvõtte PostgreSQLi eelistest - hind (PostgreSQL on tasuta; vaadake võrdluseks Oracle hinnapakkumist), jõudlus, salvestusruumi kokkuhoid, väljalasete sagedus, sobivus ettevõtte infosüsteemides kasutamiseks.

Kas MySQLis on need võimalused olemas?

MySQLis on kasutusel multiversioon konkurentsjuhtimine, kuid see on realiseeritud PostgreSQList erinevalt.
MySQLis ei saa luua tabeleid pärimise kaudu. Nii PostgreSQL uuemad versioonid kui ka MySQL toetavad deklaratiivset tabeli sektsioonideks jagamist (st selleks pole tabelite pärimist vajagi.
MySQLis ei saa kasutada väliste andmete pakendajaid. MySQLis saab kasutada FEDERATED salvestusmootorit, mis võimaldab kasutada MySQL andmebaasis andmeid, mis on mõnes teises MySQL andmebaasis. Kasutamaks MySQLis mõne teise andmebaasisüsteemi andmebaasis olevaid andmeid tuleb kasutada tasulisi ja standardiseerimata erilahendusi.
MySQLis ei saa kasutada massiivitüüpe. MySQLis ei saa kasutajad ise uusi andmetüüpe luua.

Kokkuvõttes tuleb tõdeda, et PostgreSQLi näol on tegemist andmebaasisüsteemiga, mis pakub Oracle ja Microsofti andmebaasisüsteemidele väärikat konkurentsi ning mida saab väga edukalt kasutada ka suurtes ettevõtte infosüsteemides ning riigi infosüsteemides.
2017. aastal võrreldi staatilist koodi analüüsi kasutades PostgreSQL, MySQL ja Firebird andmebaasisüsteemide koodi kvaliteeti (st kui palju on koodis vigu). Kõigil nendel on avatud lähtekood, mis muudab sellise analüüsi võimalikuks. Võrdlust saab lugeda siit. Võrdluse tulemusena leiti, et PostgreSQL ja Firebird olid koodi kvaliteedilt üsna ühesugused, kuid MySQL oli neist mõlemast selles osas halvem. Võrdluse autor naljatas, et talle meeldis MySQL kõige rohke, sest seal olid kõige huvitavamad vead.
PostgreSQLi kasutab näiteks Skype. Veel üheks PostgreSQLi heaks omaduseks on laiendatavus - SIIT leiate ülevaate laiendustest, mida Skype kasutab/arendab.
Siin on veel üks artikkel, mis kõrvutab PostgreSQLi MySQLiga ja tõstab esile PostgreSQLi kasvavat populaarsust idufirmade tehtavates arendustes.
Ja siin on kokkuvõte ühe PostgreSQL administraatori kogemustest MySQLiga. MySQLi puhul toob ta negatiivsena esile õiguste jagamist ja reliiside poliitikat ning tõstab positiivsest küljest esile MySQLi tiražeerimise võimalusi.
Veel üks arutelu, millised on PostgreSQL ja MySQL eelised ning puudused võrreldes üksteisega.
PostgreSQL populaarsuse näiteks on Lõpparuanne Siseministeeriumi haldusala IKT teenuste arendamine ja haldamise finantseerimise jätkusuutlikkus ning mõju siseturvalisuse tagamisele. Selle kohaselt kasutab enamik siseministeeriumi haldusala IKT teenustest sisemiselt PostgreSQL andmebaasisüsteemi.
Siit leiate PostgreSQL ja MySQL põhiliste omaduste võrdluse.

## Küsimus: PostgreSQL andmebaasisüsteemiga ei saa ühendust, sest aktiivsete klientide limiit on täis (too many clients). Milles võib olla põhjus ja kuidas probleemi lahendada?

**Vastus:**

Samaaegselt lubatud Postgresql kasutajate arvu on juba suurendatud 300-ni (vaikimisi arv on 100). Paraku juhtub aeg-ajalt, et ühe või teise serveri kasutaja tegevuse tulemusena genereeritakse nii palju ühendusi, et kogu ühenduste arv saab täis.

PostgreSQL (10.1) korral oli sellisel juhul probleemide allikaks ühes andmebaasis olev riknenud väline tabel ja/või selle loomiseks vajalik laiendus. Selle tabeli põhjal päringut tehes loodi ühe ühenduse asemel nii palju ühendusi, et aktiivsete ühenduste limiit sai täis. Käivitades nimetatud andmebaasis lause:

DROP EXTENSION IF EXISTS postgres_fdw CASCADE;

ning seejärel uuesti ülesandes 5 oleva väliste tabelite loomise koodi, sai väliseid tabeleid probleemideta kasutada. Kui puutute sama probleemiga kokku oma andmebaasis, siis peaksite toimima sarnaselt - kustutage laiendus ja sellest sõltuvad objektid enda andmebaasist ning käivitage ülesande 5 kood uuesti.

Kui põhjus pole Teis, vaid kelleski teises, siis aitab mulle kirja saatmine.

Infoks:

Päringuga (suvalises) andmebaasis:

SELECT  * FROM
(SELECT count(*) AS used_connections FROM pg_stat_activity) q1,
(SELECT setting::int AS res_for_super FROM pg_settings WHERE name=$$superuser_reserved_connections$$) q2,
(SELECT setting::int AS max_connections FROM pg_settings WHERE name=$$max_connections$$) q3;

leiate hetkel aktiivsete ühenduste arvu ja ühenduste maksimaalse arvu.

Käsuga

ps ax | grep post

shelli promptis näete hetkel PostgreSQLiga seotud protsesse. Kui seal mingi matriklinumber palju kordub, siis põhjuseks on just see paljude ühenduste genereerimine.

Samuti palun kõikidel üliõpilastel töö lõppedes psqlist või pgAdminist välja logida, sest nagu eespool kirjas, ei ole samaaegsete ühenduste arv piiramatu ressurss!



## Küsimus: PostgreSQL andmebaasi varukoopia tegemisel pgAdmini programmiga esineb mul viga:
pg_dump: server version: 12.0; pg_dump version: 11.5
pg_dump: aborting because of server version mismatch

Mida teha?

**Vastus:**

See viga võib esineda ka tulevastes versioonides. Üldine põhjus on selles, et kasutatav pgAdmini versioon ei vasta kõige uuemale PostgreSQLi versioonile. Tüüpiliselt tuleb PostgreSQList välja uus põhiversioon igal sügisel (tavaliselt septembri lõpus või oktoobris).
Üheks lahenduseks on installeerida pAdmini kõige viimane versioon, mis peab olema tulnud välja peale PostgreSQL uut versiooni ning suudab juba arvestada uue PostgreSQL versiooniga.
Alternatiivselt saab loogilise varukoopia teha phpPgAdmin kaudu, valides andmebaasi ja klõpsates menüüs Export. Kui valida andmete esituse formaadiks "SQL", siis on tulemuseks INSERT laused. Paraku on need halvasti kirjutatud selles mõttes, et INSERT klauslis ei ole veergude nimesid. Teiste sõnadega sellised laused on tundlikud veergude järjekorra muutmise suhtes. Selliseid lauseid tuleks käsitsi täiendada.
Veel üheks lahenduseks on kasutada varukoopia tegemiseks serveris olevat pg_dump utiliiti, käivitades selle shelli promptist. Järgnevalt kirjutan, kuidas seda teha.
Loogilise varukoopia tegemine

Logige PuTTY või mõne muu sarnase programmiga apex.ttu.ee serverisse.
Käivitage shelli promptist käsk, mille üldkuju on: pg_dump -C -f varukoopia_faili_nimi.sql andmebaasi_nimi_millest_tahan_varukoopiat Näiteks varukoopia andmebaasist scott: pg_dump -C -f scott_2020_11_07.sql scott

C tähendab, et varukoopia failis on CREATE DATABASE lause. See tähendab, et varukoopiast andmebaasi taastamiseks ei tohi serveris sellise nimega andmebaasi olla - see luuakse taastamise alguses automaatselt.
Soovitan kasutada varukoopia faili nimes kuupäeva, et oleks selge, mis aja seisuga on varukoopia loodud ning et uus varukoopia vana üle ei kirjutaks.
Fail sisaldab andmebaasi scott põhjal genereeritud SQL lauseid. Failis sisalduvad SQL laused andmebaasiobjektide loomiseks, õiguste jagamiseks ja andmete laadimiseks andmebaasi.
See käsk tuleb käivitada shelli promptis (satute sinna kohe peale sisselogimist; see sama koht kus käivitate psql programmi), mitte psqlis. pg_dump nagu ka psql on PostgreSQLiga kaasa tulevad (abi)programmid.


Logige WinSCP või muu sarnase failide haldamiseks mõeldud programmiga apex.ttu.ee serverisse. Kasutajanimi ja parool on sama, mis PuTTY abil sisselogimisel.
Sisselogimise järel satute oma kodukataloogi: /home/minu_kasutajanimi Loodud varukoopia fail on selles kataloogis.
Tõmmake see fail enda arvutisse, sest kui näiteks serverarvutis ketas rikneb, siis ei ole riknenud kettale jäänud ja kättesaamatuks muutunud failidest hiljem taastamise juures abi.
Tehke varukoopiate hoidmiseks enda arvutis eraldi kataloog.
Varukoopia failis on andmete tabelisse lisamiseks vaikimisi COPY laused. See on andmete taastamiseks kõige kiirem lahendus. Kui soovite (näiteks dokumendi jaoks) saada andmete tabelisse lisamiseks INSERT lauseid, siis tuleb varukoopia tegemise käsku täiendada. Järgnev on konkreetse andmebaasi (scott) varundamise käsu näide: pg_dump -C --column-inserts -f scott_2020_11_07.sql scott

Andmebaasi taastamine loogilisest varukoopiast

Eeldused:

Serveris pole sellise nimega andmebaasi, mille CREATE DATABASE lause on varukoopia faili alguses.
Loogilise varukoopia fail on serverarvutis Teie kodukataloogis: /home/minu_kasutajanimi


Logige PuTTY või mõne muu sarnase programmiga apex.ttu.ee serverisse.
Käivitage shelli promptist käsk, mille üldkuju on: psql -U minu_kasutajanimi -f varukoopia_faili_nimi.sql template1 Näiteks kasutaja erki taastab andmebaasi scott käsuga: psql -U erki -f scott_2020_11_07.sql template1


**Märksõnad:** loogiline varukoopia

## Küsimus: PostgreSQLis NULL || tekstiline väärtus = NULL. Kuidas luua PostgreSQLis sarnane operaator MS Accessi stringide konkatenatsiooni operaatorile &, mille korral NULL & tekstiline väärtus = tekstiline väärtus?

**Vastus:**

Järgneva koodi võite käivitada oma andmebaasis ja see loob operaatori & mis käitub nii: 
NULL & tekstiline väärus = tekstiline väärtus
NULL & NULL = tühi string


CREATE FUNCTION textcat_coalesce(text, text) RETURNS text AS $$
SELECT coalesce($1,'') || coalesce($2,'');
$$ LANGUAGE sql IMMUTABLE LEAKPROOF;

COMMENT ON FUNCTION textcat_coalesce(text, text) IS 'Stringide konkatenatsiooni operaatorit & realiseeriv funktsioon. Tagab, et operatsiooni tulemus pole NULL.';

CREATE OPERATOR & (
LEFTARG = text,
RIGHTARG = text,
PROCEDURE = textcat_coalesce
);

SELECT NULL || 'katsetus' AS tulemus;
Tulemus:NULL 
SELECT NULL & 'katsetus' AS tulemus;
Tulemus: katsetus

NB! Alternatiiv sellise operaatori kasutamisele oleks tarvitada koos PostgreSQLi konkateneerimise operaatoriga (||) coalesce funktsiooni. coalesce funktsiooni pool pöördumisel võib ette anda mitu samatüübilist argumenti. Funktsioon tagastab vasakult lugedes esimese argumendi, mis ei ole NULL (või kui kõik argumendid on NULLid, siis tagastab NULLi). Seda funktsiooni saab kasutada NULLi asendamiseks konkreetse väärtusega.

SELECT coalesce(NULL,'') || 'katsetus' AS tulemus;
Tulemus: katsetus (sest kokku ühendatakse kaks väärtust - 'katsetus' ja '')

Samuti võib kasutada concat_ws funktsiooni.

SELECT concat_ws(' ', 'katsetus', NULL) AS tulemus;
Tulemus: katsetus (sest funktsioon ignoreerib NULL argumente)


## Küsimus: PostgreSQLis saab luua null veeruga tabeleid. Miks ma peaksin tahtma sellist tabelit luua?

**Vastus:**

PostgreSQLis saan luua baastabeli, kus on null veergu (aste on null) ja lisada sinna null või rohkem rida (tabeli võimsus on null või rohkem).
CREATE TABLE on_avatud();
INSERT INTO on_avatud DEFAULT VALUES;

Saan selliseid tabeleid kasutada tõeväärtustüüpi juhtparameetrite realiseerimiseks. Need on disainitaseme abitabelid, mis kontseptuaalses andmemudelis ei kajastu.


SELECT Count(*) AS cnt FROM on_avatud;

Kui süsteem on avatud, siis cnt>=1
Kui süsteem on suletud, siis cnt=0


Alates PostgreSQL 9.4 saab kirjutada SELECT lauseid (ilma DISTINCT operatsioonita), kus SELECT klauslis olev veergude hulk on tühihulk.
SELECT FROM on_avatud;

Kui süsteem on avatud, siis leitud ridade arv >=1
Kui süsteem on suletud, siis leitud ridade arv =0


Tühja SELECT klausliga päringuid saab kasutada jah/ei küsimuste formuleerimiseks.

Kas osakonnas 10 on mõni töötaja?
SELECT FROM Emp WHERE empno=10;

Kui jah, siis leitud ridade arv >=1
Kui ei, siis leitud ridade arv =0


Erinevused relatsioonilisest mudelist.

Ei saa luua nimega tuletatud tabeleid (vaateid, hetktõmmiseid), mille aste on null.
Sellise tabeli võimsus võib olla ühest suurem.


SQLis üldiselt peab tabelis olema vähemalt üks veerg.

## Küsimus: Teeme projekti PostgreSQLis ning mitmekesi. Millisesse andmebaasi tuleb panna rakenduse andmebaasiobjektid? Kuidas me üksteise tehtud PostgreSQL andmebaasidele ligi pääseme?

**Vastus:**

PostgreSQLis on apex.ttu.ee serveris kõigil üliõpilastel ülikasutajate (superuser) õigused. Kõik üliõpilased pääsevad piiranguteta kõikidele serveris olevatele PostgreSQL andmebaasidele ligi ja saavad seal kõike teha. Andmebaasis ja skeemis võib olla erinevatele kasutajatele kuuluvaid andmebaasiobjekte. Projekti tegemiseks peate valima ühe rühmaliikme andmebaasi või võite ka teha täiesti eraldi andmebaasi. Kõik saate töötada sama andmebaasiga.


---

# Teema: Rakenduse tegemine

## Küsimus: Kas tehes veebirakenduse Oracle APEX vahendit kasutades on vaja luua Oracle andmebaasis kasutajaid/rolle ja jagada nendele õiguseid?

**Vastus:**

Kasutaja, kellena Oracle APEX suhtleb andmebaasisüsteemiga, on andmebaasis automaatselt loodud. Seda ei ole vaja muuta ning talle õiguseid jagada. 

Seega üliõpilased, kes teevad rakenduse Oracle APEXis, ei pea oma projekti jaoks looma looma rakendusele vastavat kasutajat ning jagama sellele õiguseid.

Enda projektis kirjutate jaotistesse:
5.13 Rollid ja kasutajad
5.14 Õiguste jagamine

, et töö spetsiifikast tulenevalt ei ole vaja rolle/kasutajaid luua ning õiguseid jagada.

## Küsimus: Kuhu tuleb paigutada PHPs tehtud veebirakendus?

**Vastus:**

apex.ttu.ee serveris on PHP (5.5.3) olemas.
apex.ttu.ee serveris tuleb veebirakenduse failid paigutada kataloogi /usr/local/apache2/htdocs alamkataloogi.
Kui loote seal näiteks oma rakenduse jaoks kataloogi rakendus, siis rakenduse veebiaadress on: http://apex.ttu.ee/rakendus/

Rakenduse paigutamine apex.ttu.ee serverisse ei ole kohustuslik. Kui Teil on omal server, siis võite panna sinna - peaasi, et õppejõud rakendusele lõppkasutajana ligi pääseb. Selliste serverite häda kipub küll olema, et need on sageli maas/kättesaamatud, mis raskendab töö tulemuse ülevaatust.ANDMEAAS PEAB OLEMA apex.ttu.ee SERVERIS!

## Küsimus: Kuidas täita pgApexis järgmiseid mittefunktsionaalseid kasutajaliidesega seotud nõudeid?


Kuupäevad tuleb esitada formaadis DD.MM.YYYY
Kellaajad tuleb esitada formaadis HH24:MI:SS
Ajatemplid tuleb esitada formaadis DD.MM.YYYY HH24:MI:SS


**Vastus:**

pgApex ei võimalda hetkel muuta andmete formaati rakenduse tasemel (nagu seda võimaldab Oracle APEX). Seega tuleb teha kõik vajalikud muudatused vaadetes, mille peale luuakse andmete vaatamise leheküljed. Andmebaasi vaated ongi mõeldud selleks, et esitada kasutajatele just neid andmeid, mida nad vajavad ning just sellises formaadis nagu nad soovivad. PostgreSQLis esitatakse ajatempli (timestamp) andmed vaikimisi YYYY-MM-DD HH24:MI:SS formaadis. Mõne teise formaadi kasutamiseks vaate väärtuses tuleb vaate alampäringus kasutada to_char funktsiooni. Näide seda funktsiooni kasutavast päringust.
SELECT isik_id, to_char(reg_aeg, 'DD.MM.YYYY HH24:MI:SS') AS reg_aeg, perenimi FROM Isik;
Funktsiooni väljakutses on esimene argument veeru nimi, milles olevaid andmeid soovitakse formaatida ja teine argument soovitud formaat.
Kuna selle funktsiooni väljund ei ole mitte tüüpi TIMESTAMP, vaid TEXT, siis ei piisa vaate muutmiseks CREATE OR REPLACE lausest (saaksite veateate: ERROR: cannot change data type of view column "reg_aeg" from timestamp to text). Selle asemel tuleb vaade kustutada ja uuesti luua.

## Küsimus: Millele pöörata tähelepanu MS Accessis tehtud rakenduses, milles soovitakse VBAs välja kutsuda tekstitüüpi parameetriga PostgreSQLi andmebaasis loodud funktsiooni?

**Vastus:**

Kui andmebaasis on funktsiooni parameeter tekstitüüpi ning sellel on maksimaalne väljapikkus määratud (nt kauba kood – 7 märki), siis tuleb VBA koodis parameetri deklareerimisel määrata ka see väljapikkus. Näide:

Juhul kui serveris oleva funktsiooni parameeter on tüüpi CHAR(7)
.Parameters.Append .CreateParameter("kauba_kood", adChar, adParamInput, 7) 


Serveris oleva funktsiooni parameeter on tüüpi VARCHAR(7)
.Parameters.Append .CreateParameter("kauba_kood", adVarChar, adParamInput, 7)

## Küsimus: Millistest üldistest põhimõtetest lähtuda andmebaasirakenduste loomisel?

**Vastus:**

Thomas Kyte on Oracle andmebaasisüsteemide spetsialist ja tema sellel teemal kirjutatud raamatud on väga head. Üks nendest raamatutest - Expert Oracle Database Architecture, Third Edition - on Tallinna Tehnikaülikooli üliõpilastele kättesaadav elektrooniliselt O'Reilly digitaalse platvormi kaudu.
Palun lugege sellest raamatust esimese peatüki osi My Approach ja The Black Box Approach.
Jah, seal kiidetakse muuhulgas Oraclet. Võtke seda kergelt, sest ka mitmed teised andmebaasisüsteemid (sh PostgreSQL) on sama võimekad. Kuid seal kirjeldatav üldine andmebaasirakenduste loomise mõtteviis on selline, mida pean mõistlikuks ja millest lähtun ka käesolevas kursuses.
Põhimõte on, et hea andmebaasirakenduse loomiseks tuleks tunda ja kasutada andmebaasisüsteemide pakutavaid võimalusi. Lisan siia lõppu tsitaadi raamatust, mida ma tõlkima ei hakka. Viidatud osades tuuakse mõned ilmekad näited selle kohta, kuidas rakenduse arendajate poolne andmebaasi/andmebaasisüsteemi musta kastina vaatamine viis halbade tulemusteni.
My point about the power of database features is not a criticism of tools or technologies like Hibernate, EJBs, and container-managed persistence. It is a criticism of purposely remaining ignorant of the database and how it works and how to use it. The technologies used in this case worked well—after the developers got some insight into the database itself.
The bottom line is that the database is typically the cornerstone of your application. If it does not work well, nothing else really matters. If you have a black box and it does not work, what are you going to do about it? About the only thing you can do is look at it and wonder why it is not working very well. You can’t fix it, you can’t tune it. Quite simply, you do not understand how it works—and you made the decision to be in this position. The alternative is the approach that I advocate: understand your database, know how it works, know what it can do for you, and use it to its fullest potential.

## Küsimus: Tegin pgApexis vaadete ekraanivorme ning avastasin, et vaatest oli väli puudu. pgApex näitas vaatele vastaval ekraanivormil päringu tulemusel saadud andmeid. Lisasin puuduva välja kustutades vastava vaate ning luues selle uuesti. Kuid nüüd ei näita pgApex enam vastavas vaates andmeid. Testimiseks tegin uue rakenduse, aga ka seal ei tekkinud otsitavad andmed.
Kas ja kuidas mul oleks võimalik vaadete andmed uuesti rakendusse saada? Mida ma saaksin edaspidi teist moodi teha, et rohkem sellist probleemi ei esineks?

**Vastus:**

Probleem on selles, et rakendusele vastaval kasutajal pole õigust vaatest andmeid küsida (SELECT  õigus). See õigus läks kaotsi, kui vaate kustutasite ja uuesti lõite (DROP lause  + CREATE lause). Lahenduseks on anda rakendusele vastavale kasutajale uuesti vaadetest andmete lugemise õigus. Seega tuleb peale vaate kustutamist ja uuesti loomist käivitada ka GRANT laused vaate suhtes õiguste jagamiseks. 

Kui asendate vaate CREATE OR REPLACE lausega, siis on tulemuseks sama vaade ja õigused säilivad. Kuid on tõsi, et: 

vaatesse veeru lisamiseks, 
vaatest veeru eemaldamiseks,
vaate veeru andmetüübi muutumisel,


 tuleb vaade kustutada ja uuesti luua.

CREATE OR REPLACE lausest piisab, kui muudate vaadet nii, et selle veerud jäävad samaks (nt lisate või eemaldate alampäringust tingimusi).

**Märksõnad:** report, aruanne, vaade, õigused, õigus, andmed


---

# Teema: Õppetöö

## 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 erinevatel nädalatel võib käia erinevates praktikumides?

**Vastus:**

Jah võib, eeldusel, et klassi mahute.

## Küsimus: Kas magistriõppe üliõpilane, kes on bakalaureuseõppes sooritanud (saanud positiivse hinde) õppeaine "Andmebaasid II" (IDU0230), võib magistriõppes deklareerida eriõppe/põhiõppe moodulisse valikaine "Andmebaasid II" (ITI0207)?

**Vastus:**

Tegemist on sisuliselt sama ainega, kuid muidugi on koos tehnoloogiate arenguga ka selle sisu vahepealse aja jooksul mingil määral värskenenud.

IAPM (Informaatika) õppekava juht on seisukohal, et IAPM üliõpilased, kes on seda õppeainet juba varem teise koodiga sooritanud, peavad üldiselt valima mõne teise õppeaine. Erandiks on, kui üliõpilane sooritas IDU0230 hindele 1. Siis võib ta ITI0207 teadmiste värskendamiseks ning hinde parandamiseks deklareerida. Kogu õppeaine tuleb täies mahus uuesti teha, st, et muuhulgas tuleb teha uuesti projekt (nagu mäletate, siis põhiosa ainest). 

IABM (Äriinfotehnoloogia) õppekava juht on seisukohal, et aine uuesti deklareerimine pole keelatud, aga VÕTAga seda teha ei saa. Sellise deklareerimise põhjus on soov teadmisi ning oskuseid kinnistada ja selleks tuleb kogu aine uuesti teha. Seda tuleb teha täies mahus, st, et muuhulgas tuleb teha uuesti projekt (nagu mäletate, siis põhiosa ainest). 

Projekti tegemiseks valmistan (eeskätt magistriõppe üliõpilastele) ette mõned "Andmebaasid I" projektid, mille hulgast peavad nad valima projekti, millega õppeaines "Andmebaasid II" jätkata. Lisan omalt poolt, et kordamine on õppimise jaoks väga tähtis ning kindlasti leiab uuel kuulamisel midagi uut ja huvitavat, seda enam, et tehnoloogiad on pidevas muutumises.

Lähtun deklaratsioonide aktsepteerimisel nendest seisukohtadest.

## Küsimus: Kas õppeaine võib deklareerida ka siis, kui eeldusaine (Andmebaasid I) on sooritamata?

**Vastus:**

Jah võib.
Eeldusaines saadud teadmised ja oskused on sellest ainest arusaamiseks ja ainega edukalt hakkamasaamiseks vajalikud, kuid need võivad olla saadud väljastpoolt Tallinna Tehnikaülikooli või siis tuleb neid jooksvalt koguda.
Paljud magistriõppe üliõpilased pole bakalaureusetasemel Tallinna Tehnikaülikoolis õppinud või kui on, siis pole "Andmebaasid I" olnud nende bakalaureuseõppe õppekavas või see on olnud valikaine, mida nad ei valinud. Seega nad ei olegi saanud eeldusainet õppida.
Õppeaine "Andmebaasid II" üheks õpiväljundiks on "Oskab disainida tehingutöötluseks mõeldud paksu jagatud SQL-andmebaasi ja programmeerida andmebaasi kasutades serveri andmebaasisüsteemi (andmebaasisüsteemide valik esitatakse semestri alguses). Lisaks oskab luua andmebaasi kasutava rakenduse ühes enda valitud vahendis." Selle õpiväljundi hindamiseks tuleb teha projekt.
Bakalaureuseõppe üliõpilased võtavad projekti tegemisel aluseks enda poolt õppeaines "Andmebaasid I" tehtud projekti. Üliõpilastele, kellel sellist projekti ei ole (bakalaureuseõppe üliõpilased, kellel eeldusaine on jäänud sooritamata + magistriõppe üliõpilased), valmistasin ette mõned "Andmebaasid I" projektid, mille hulgast peavad nad valima projekti, millega õppeaines "Andmebaasid II" jätkata. Leiate need kodulehe kataloogist Projekt/Projektid neile, kellel eeldusaine on sooritamata. Nende projektide hulgast võivad jätkamiseks sobiva valida ka need üliõpilased, kellel on "Andmebaasid I" projekt tehtud, kuid kes ei soovi sellega mingil põhjusel jätkata.
Magistriõppe üliõpilased võivad teha ka enda töökohalt pärinevat projekti. Sellise ülesandepüstituse korral on hädavajalik eelnev kokkulepe õppejõuga, sest kõik mahulised ja muud nõuded peavad ka sellise projekti puhul olema täidetud (andmeaida projekt näiteks ei sobi, sest see ei vasta õppeaine õpiväljundile).

## Küsimus: Kas äriinfotehnoloogia magistrant saab seda õppeainet õppida töökohapõhist õpet kasutades?

**Vastus:**

Põhimõtteliselt küll, kuid kõik sõltub detailidest. Vaadates õpiväljundeid oleks kõige loomulikum ja võimalikum teha just projekt oma töökoha põhjal (projekt annab umbes poole aine punktidest). Tehtav projekt peab vastama õpiväljundile "Oskab disainida tehingutöötluseks mõeldud paksu jagatud SQL-andmebaasi ja programmeerida andmebaasi kasutades serveri andmebaasisüsteemi (andmebaasisüsteemide valik esitatakse semestri alguses). Lisaks oskab luua andmebaasi kasutava rakenduse ühes enda valitud vahendis." ning toetama ka teisi õpiväljundeid (turvalisuse, transaktsioonide halduse ja töökiiruse parandamise põhimõtetega tutvumine). 

Seega igasugune töökohapõhine töö kindlasti selle aine projektiks ei sobi. Kui näiteks juhite töö juures projekti, teete süsteemianalüüsi või arendate andmeaita, siis kõikide nende teemade jaoks on õppekavas eraldi õppeaine, milles saate töökohapõhist õpet kasutada. Töökohapõhine õpe ei tähenda, et see peaks toimuma igas õpitavas õppeaines täpselt 50% ulatuses. Võibolla mõnes aines on see 0% ja mõnes teises aines 100%.

Kui osalete töökohase õppe programmis, siis peate õppejõule ise välja pakkuma, mida tahaksite töökohapõhise õppe raames teha. Edasine on juba läbirääkimiste küsimus.

## Küsimus: Kas üliõpilased on kohustatud käima nendele tunniplaaniga määratud aegadel praktikumis või on võimalik käia ka teiste rühmade praktikumides?

**Vastus:**

Ei ole kohustatud. Põhimõtteliselt on võimalik käia teisel ajal, sest sisu poolest praktikumid ei erine. Praktiline võimalus sõltub sellest, kas soovitud ajal on klassis vabu kohti. Seda on enne semestri algust raske prognoosida, sest pole teada, kui aktiivseks ühe või teise aja külastus kujuneb. Kui vabu kohti on, siis minu poolt takistust ei ole.

Elu näitab, et lõpptulemusena võib olla mõnel ajal käijaid hästi palju ja õppejõul jagub sedavõrra osalistele vähem aega mõnel teisel ajal (eriti reedeti) on aga klass väga hõre ja samavõrra on õppejõul igale osaleja jaoks rohkem aega. Seega tasub alates teises õppenädalast õppejõult uurida, kas soovitud ajal on võrreldes teiste aegadega klassis liiga palju üliõpilasi ning millised on ajad, kus tunnis käijaid on vähe.

## 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 siis valige Mauruse esilehel menüüst Üldist=>Minu konto ja lisage enda aktiivsete lehtede hulka: "Andmebaasid II (ITI0207, IDU0230) (sügis 2019)" Ä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.
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: Kuidas esitada õppejõule ülevaatamiseks projekti rakenduse osa?

**Vastus:**

Kui Teie rakendus on veebirakendus ja üles pandud serverisse või kui Teie rakendus on tehtud MS Accessis, siis mul selle vaatamisega probleeme ei ole ja rakendust ei ole vaja tulla eraldi ette näitama.

Kui Teie rakendus on vaja installeerida kasutaja arvutisse, siis see on probleem, sest minu tööarvutisse uue tarkvara lisamine on õiguste piirangute tõttu aeganõudev ja takistatud. Seega, kui rakendus vajab kasutaja arvutis mingeid lisaprogramme pole kahjuks muud teha, kui peate tulema rakendust eksamisessiooni ajal vastuvõtuajal ette näitama. Oma projekti tulemuse saate teada alles pärast seda. Pange palun sellisel juhul rakenduse üleslaadimisel Maurusesse vastava küsimuse vastusesse kirja, millisel vastuvõtuajal plaanite rakendust näitama tulla.

Ükskõik millises vahendis on rakendus tehtud - tähtajaks tuleb Maurusesse üles laadida selle rakenduse lähtekood. Muidu pole tõestatud, et rakendus oli õigeks ajaks valmis. Järgnevalt kommenteerin mõningaid antud aines populaarseid rakenduse tegemise vahendeid.

Oracle APEXi korral on vaja esitada eksportimise tulemus. 
pgApexi korral on vaja esitada apex.ttu.ee serverist andmebaasi pgapex2 eksportimisel saadud fail (plain formaadis, SQL laused; loomiseks saate kasutada pgAdmin programmi Backup funktsiooni). 
MS Accessi puhul ei saa lähtekoodi saata - saadate rakenduse faili. MS Accessi puhul tuleb mulle saata *.mdb või *.accdb laiendiga fail, mitte *.mde või *.accde laiendiga fail.


## Küsimus: Kuidas moodustub hinne? Mis roll on lisapunktidel?

**Vastus:**

Punktid liidetakse kokku ja taandatakse Tallinna Tehnikaülikooli hindamisskaalale (0-50 punkti hinne 0; 51-60 punkti hinne 1, ..., rohkem kui 91 punkti hinne 5). Lisaks tuleb positiivse lõpphinde saamiseks ületada kaks lävendit.


Projekti punktid (saate teada õppejõu poolt saadetud hindamismudeli failist). Lävendi ületamiseks on vaja vähemalt 31 punkti.
Eksami punktid. Lävendi ületamiseks on vaja vähemalt 20 punkti. Eksami punktide saamiseks liidetakse:

vahetestide punktid (võimalik saada kuni 18 punkti),
lõpptesti punktid (võimalik saada kuni 30 punkti).

Kuna vahetestide tõttu võib liitmise tulemus olla komakohtadega (nt 34.5), siis tulemus ümardatakse (nt 34.5=>35).
Praktikumides kogutud aktiivsuspunktid.


Vahetestide punktid aitavad ületada eksami lävendit ja suurendavad ka lõplikku punktisummat. Aktiivsuspunktid ühtegi lävendit ületada ei aita, kuid suurendavad lõplikku punktisummat.

Kaotate aktiivsuspunktid (st neid ei liideta ülejäänud punktidele juurde), kui on täidetud vähemalt üks nendest tingimustest.

Esimesele ülevaatusel ei ületa projekt lävendit ning saate võimaluse seda parandada.
Projekti esmakordne esitamine hilineb rohkem kui kaks nädalat.


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

**Vastus:**

Kordamisküsimused ja testideks õppimise materjalid leiab kataloogist Teooria. Kordamisküsimuste dokumendi alguses on ka kirjas küsimuste valiku põhimõtted iga testi jaoks.
Testide tegemine toimub veebipõhise keskkonna kaudu, kuhu Teie konto luuakse automaatselt 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 kolm vabatahtliku vahetesti auditoorse õppetöö perioodil ning kohustuslik lõpptest (eksam) eksamisessiooni ajal. Kõikide nende jaoks saab selles keskkonnas harjutada. 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 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. Kui küsimusele vastati valesti (kuid ei jäetud vastamata), siis näitab süsteem ka õiget vastust.
Õ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 esitan projekti ja see on nii kehva, et pean seda parandama, siis kuidas tuleb parandus esitada?

**Vastus:**

Palun laadida parandatud töö Maurusesse, mitte saata seda mulle meilile.

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

**Vastus:**

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

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

**Vastus:**

Kataloogi Teooria testideks (vahetestid, eksam) valmistumine alguses. 

OTSEVIIDE Echo lindistuste lehele. Seal pole loengute annotatsioone.

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

## Küsimus: Kust leiab infot lõputööde kirjutamise kohta, sh võimalikke teemasid?

**Vastus:**

Üks selline lehekülg on ka osa sellest samast õppekeskkonnast.

## 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. 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.

Ärge jagage enda tehtud projekte teiste üliõpilastega.
Ärge tehke kellegi teise eest tema tööd ära.
Ä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: Milliseid linke läheb õppetöös igapäevaselt vaja, sh iseseisva töö projekti tegemisel?

**Vastus:**


PostgreSQL phpPgAdmin: http://apex.ttu.ee/phppgadmin
Oracle Application Express (Oracle APEX): http://apex.ttu.ee:8000/apex/apex_login 

Oracle Application Express abil tehtud rakenduste näiteid:

Töötajate andmebaas (rakenduse tegemiseks kulus umbes 30 minutit) (kasutajanimi: testkasutaja parool: 1234)
Koristajate andmebaas (kasutajanimi: testkasutaja parool: 1234)
Seisundimuudatuste realiseerimise näide
APEXiga kaasa tulev näiterakendus (kasutajanimi: testkasutaja parool: 1234)

2016. aasta kevadel arendas hr Rait Raidma välja Oracle APEXile sarnase süsteemi nimega pgApex, mis põhineb PostgreSQLil. Magistritööd saab lugeda siit. 2019. aasta kevadel täiendas hr Nikolai Kopa seda tarkvara. Tema selleteemalist bakalaureusetööd saab lugeda siit. 2020. aastal andis Dmitri Bizjulin pgApexile täieliku võimekuse andmete haldamise rakenduste (CRUD rakenduste) loomiseks. Tema selleteemalist bakalaureusetööd saab lugeda siit.

apex.ttu.ee serveris üles seatud arenduskeskkond (sisselogimiseks apex kasutajanimi/parool)
MIT litsentsiga kaitstud avalik lähtekood:

Versioon 1
Versioon 2
Versioon 3


Tubade halduse näiterakendus (kasutajanimi: lucile.burgess@frolix.net parool: laborum)

PHP rakenduse näide:

Teadetetahvel - sisselogimiseks on vaja kasutada apex.ttu.ee PostgreSQL kasutajanime ja parooli.

NB! apex.ttu.ee serveris tuleb PHP rakendus paigutada kataloogi /usr/local/apache2/htdocs alamkataloogi. Kui loote seal näiteks oma rakenduse jaoks kataloogi rakendus, siis rakenduse veebiaadress on: http://apex.ttu.ee/rakendus/
Abivahendid:

StarUML CASE vahendil põhinev lahendus, mis võimaldab StarUML abil koostada SQL-andmebaasi disaini mudeleid ja genereerida nendest PostgreSQLi jaoks mõeldud SQL koodi (kaasa arvatud mõningate keerukamate kitsenduste jõustamiseks vajalik kood). Idee on, et mudelis saab deklareerida kitsenduse vajaduse ning generaator oskab selle deklaratsiooni alusel koodi genereerida.
apex.ttu.ee serveris olevate PostgreSQL andmebaaside kvaliteedi kontroll - sisselogimiseks on vaja kasutada apex.ttu.ee PostgreSQL kasutajanime ja parooli. Siin on sama vahendi uuem kasutajaliides. Siin on kontrollimiseks kasutatavad päringud.
Erinevad tarkvaravahendid PostgreSQL andmebaaside projekteerimiseks, programmeerimiseks ja haldamiseks. Nimekirjas on nii vaba tarkvara kui ka kommertstarkvara.
Visuaalne SELECT lausete koostamise tarkvara PostgreSQL jaoks.

Dokumentatsioon:

Tigu lahkamas, ehk ekskursioon UNIXi maailma
PostgreSQL dokumentatsioon

PostgreSQL SQL Reference


Oracle 12c Release 1 dokumentatsioon

Oracle SQL Reference


Ask Tom on koht kust leiab vastuseid paljudele küsimustele Oracle kohta. Ühtlasi on see keskkond näide Oracle Application Express kasutamise kohta.
Oracle Application Express
Oracle Application Express foorum
Pistikprogrammid e pluginad, mida saab kasutada Oracle APEXI abil tehtud rakenduste funktsionaalsuse suurendamiseks.
Mõned videod, mis demonstreerivad APEX 4.1 kasutamist.

Lisainfo:

Suur hulk soovitusi ja näpunäiteid andmebaaside programmeerijatele
Visioon, kuidas üles ehitada andmete haldamiseks mõeldud süsteeme
Teadmusbaas Database Lifecycle Management, kus on palju andmebaasi testimisest, evitamisest, versioonihaldusest. Tehnilisemad näited on seal MS SQL Serveri baasil, kuid üldiselt on see jutt oluline ja vajalik mistahes andmebaasisüsteemi korral.
Kümme tavalist viga, mida Java arendajad teevad SQLi kirjutamisel
Veel kümme tavalist viga, mida Java arendajad teevad SQLi kirjutamisel
Üle kümne aasta uus väljaanne raamatus, kus andmebaasidega seotud teadus- ja arendustöö suurkujud esitavad viiteid mõnedele andmebaaside valdkonda palju ja püsivalt mõjutanud teadusartiklitele. Mis peamine, iga peatüki ees on toimetajate kommentaar, milles tutvustatakse artikleid ning kommenteeritakse andmebaasisüsteemide minevikku, olevikku ja tulevikku. Kellel on andmebaaside ja maailma selle valdkonna trendide vastu sügavam huvi, soovitan lugeda.


## 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).

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

## Küsimus: Millist tarkvara läheb õppeaines vaja? Milline tarkvara tuleks installeerida enda isiklikku tööarvutisse?

**Vastus:**

Iseseisva tööga alustamisel (praktikumis alates viiendast õppenädalast) läheb vaja CASE vahendit (Enterprise Architect või Rational Rose). Selle saamise juhend on "Andmebaasid I" kodulehel. Kui Enterprise Architect on juba installeeritud, siis on vaja uuesti litsents laenutada.

PostgreSQL andmebaasiga töötamiseks võib kasutada tasuta pakutavat programmi pgAdmin. Sobivad nii põlvkonnad 3 kui ka 4. Juhin tähelepanu, et hetkel pole põlvkonnas 4 realiseeritud graafilist päringute koostamise liidest (sarnane MS Accessi Query Designerile). See on olemas põlvkonnas 3 ja sellest võib olla abi vaadete alampäringute koostamisel, kui soovitakse mitme tabeli ühendamist nõudev vaate alampäring ilma koodi kirjutamata valmis saada. Soovi korral võib installeerida mõlemad. Kui serveris on PostgreSQL 10 või hilisem, siis pgAdmin 3 abil sisenemisel saab veateateid ja hoiatusi, kuid lõpuks võimaldab tarkvara siiski serveris olevate andmebaasidega töötada.

Oracle andmebaasiga töötamiseks soovitan kasutada Oracle poolt pakutavat programmi Oracle SQL Developer (ülikooli serveriga ühenduse loomisel SID= orcl). Tarkvara on tasuta, kuid selle allalaadimiseks tuleb ennast registreerida.

apex.ttu.ee serveriga SSH ühenduse loomiseks võib kasutada programmi PuTTY või Bitvise SSH Client.
Samuti võib mitte-kommerts otstarbel kasutada SSH Secure Shell klienti versiooni 3.2, kuid see on juba üsna vana ja ebaturvaline. Selles lõigus nimetatud programmidest piisab ühest!

apex.ttu.ee serverisse failide ülekandmiseks ja sealt failide allalaadimiseks võib kasutada programmi WinSCP. Tegelikult sisaldavad ka Bitvise ja SSH Secure Shell programmid sellist funktsionaalsust ja siis poleks WinSCPd vajagi.

Lähtekoodiga (sh SQL lausetega) töötamiseks sobib hästi tekstiredaktor SciTe või Notepad++.

Valikuline
PostgreSQL andmebaasisüsteemi kasutava kahekihilise klient-server süsteemi loomiseks läheb vaja PostgreSQL ODBC draivereid.
Valige palun kõige viimane versioon. Kui olete juba installeerinud mõne varasema versiooni, siis see tuleb kõigepealt arvutist maha võtta ja siis installeerida draiveri uuem versioon. Milline draiver täpsemalt valida ja kuidas andmeühendust seadistada lugege palun teatele lisatud failist.

Kui Teile meeldib käsureapõhine kasutajaliides ja peate (õigusega) Oracle SQL*Plus'i liiga vanamoodsaks, siis võite enda arvutisse installeerida Oracle SQLcl. See on Oracle SQL*Plus edasiarendus. Kui kasutate enda arvutisse installeeritud versiooni, siis on kasulik teada, kuidas Windowsi command prompt aknasse teksti kleepida.

PHP rakenduste genereerimiseks võib (EI PEA) kasutada SQL Maestro koodigeneraatorit PostgreSQL jaoks või SQL Maestro koodigeneraatorit Oracle jaoks. Soovitan neid neid siiski mitte kasutada (esitasin viited, et teaksite seda tüüpi vahendite olemasolust), sest loodav rakendus peab vastama projektile. Need generaatorid suudavad "toota" lihtsa CRUD rakenduse tabelites andmete haldamiseks, kuid projektis valitud töökohale vastav funktsionaalsus võib olla midagi hoopis muud. Sellisel puhul pole generaatori töö tulemusest kuigivõrd abi.

Kui PostgreSQLiga suhtlemiseks pakutud vahenditest väheks jääb, siis siit leiab veel alternatiive.


## 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: Teen projekti PostgreSQLis/Oracles. Kas mul on siis vaja praktikumides tutvuda teise andmebaasisüsteemiga (Oracle/PostgreSQL) ja selle kasutamiseks vajalik tarkvara enda sülearvutisse installeerida?

**Vastus:**

Ma kujutan ette, et üliõpilased tahaksid ennast tulevaseks tööeluks võimalikult mitmekülgselt ette valmistada ja seega ülikooli liivakastis erinevaid asju katsetada.

Formaalselt rääkides, siis kõik testid küsivad küsimusi nii PostgreSQL kui Oracle kohta. Eeldan, et üliõpilased on tuttavad kõige sellega, mis kodulehe  materjalides on kirjas. Oracle SQL Developer/pgAdmin tasub endale Oracle/PostgreSQL katsetamise huvides installeerida, isegi kui Te projekti Oracles/PostgreSQLis ei tee.