# 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 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 muudatustele 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, 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.
Loobuda ühe või teise kitsenduse deklaratiivsest jõustamisest ning realiseerida kontroll kas andmebaasi tasemel rutiinides või trigerites või üldse ainult rakenduses. Selline lahendus võimaldab jätta andmebaasis olemasolevad andmed selliseks nagu need on, kuid vähemasti kontrollida uusi andmeid.


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. Uuring tuvastas nendes programmides kokku 22 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.

## 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 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 (http://geoportaal.maaamet.ee/est/Andmed-ja-kaardid/Aadressiandmed-p112.html), mille tehnilist spetsifikatsiooni saab lugeda siit: http://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 http://geoportaal.maaamet.ee/docs/aadress/ADS_spetsifikatsioon_22_10_2012.pdf jaotises 2.4

TTÜ raamatukogu pakub juurdepääsu EBL : Ebook Library kataloogi kuuluvatele raamatutele (https://ebookcentral.proquest.com/lib/tuee/home.action)

IT Akadeemia toel on järgnev EBL e-raamat TTÜ-le päriseks ostetud!

Blaha, M., 2010. Patterns of Data Modeling.

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

Kui peaksin hoidma kraade, minuteid ja sekundeid, siis võtaks iga selle komponendi jaoks kasutusele täisarvu tüüpi veeru.

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 puhul on ikka vaja WITH CHECK OPTION kitsendust kasutada? Näiteks, kui juhataja rollis kasutaja näeb vaate kaudu kinnitamata tellimusi, siis saaks ta 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.

**Vastus:**

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

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. Tarkvarakeelkeel, 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.


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

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

**Vastus:**

Raamatust

Guernsey III, M., 2013. Test-Driven Database Development. 
Unlocking Agility. Addison-Wesley. 315 p.

See raamat on üliõpilastele kättesaadav TTÜ võrgus Safari andmebaasi kaudu. Viide raamatule selles andmebaasis on siin. 

Siit aga leiab info, kuidas kasutada neid raamatuid ka väljaspoolt TTÜ võrku. 

## Küsimus: Miks peavad ka veebi/rakenduste programmeerija ning neile korralduste andjad andmebaase hästi tundma?

**Vastus:**

Väga eluline näide (seostub teemaga 6 - transaktsioonid ja lukustamine).

2017. aastal avaldati 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. Uuring tuvastas nendes programmides kokku 22 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.

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


---

# Teema: Andmebaasisüsteemid (Üldine)

## 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) ja konkreetsete süsteemide probleemidele (näide3, näide4, näide5). Muidugi saab öelda, et ühes või teises NoSQL süsteemis selliseid probleeme ei ole, 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 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.

## 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 harjutustes 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:**

Hiljutine 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. 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.
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 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, mis on tegelikult lingitud mingitest 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öö 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 sektsioonidesse). Selles bakalaureusetöös on mitmete nende Oracle võimaluste kasutamise mõju katsetatud.
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.

Konkreetne näide, kuidas suur infosüsteem vahetas Oracle PostgreSQLi vastu. Siin on lühike tekstiline ülevaade.

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

TTÜ raamatukogus on kaks head raamatut:

Relatsiooniline andmemudel (mitte ajada segi SQLiga)
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.) 

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.

Graafipõhiste andmemudelite kohta saab lugeda eesti keeles punktist 2.2:
Mikk, S.M., 2017. Graafide esitamine SQL-andmebaasides. Magistritöö. TTÜ Tarkvarateaduse instituut.

## 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. 01.09.2018 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 ei ole standardeid (kui JSON formaati kirjeldav standard välja jätta; JSON formaati kasutavad dokumendipõhised andmebaasisüsteemid pakuvad võimalust kontrollida/tagada, et andmebaasis andmeid esitav JSON dokument on trimmis, st reeglitega kooskõlas), mida kõik süsteemid peaksid järgima. See 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.  Praktikas tähendab see, 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. 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.

## 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: Milliseid võimalusi pakub Enterprise Architect andmebaaside projekteerijale?

**Vastus:**

Video Enterprise Architect 12 täiendustest seoses andmebaaside arendamisega.

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


---

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

## 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 tervadatud 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 TTÜ raamatukogus.

TTÜ 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. Siit aga leiab info, kuidas pääseda raamatule ligi ka väljaspoolt TTÜ võrku. 

## 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 delikaatsete 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:**

Isikuandmete kaitse seadus sätestab, millised on 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 hilinemise eest 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 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).

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 (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 mööda vaadata.

## 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 aastal 2020 arvutisüsteemides loodavate andmete hulk 44 korda suurem kui aastal 2009.
Variety – andmestruktuuride varieeruvus on suur – erinevad formaadid, muutuv struktuur.



---

# Teema: Iseseisva töö projekt

## 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, 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öö 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)? Kontroll, kas andmebaasi disaini mudel realiseerib andmebaasi vastavalt kontseptuaalses andmemudelis esitatud nõuetele, läheb verifitseerimise 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 "Käivita saadaolevaid teste". Valige test "Databases II (fall 2017)". Vaadake päringu tulemusi, milles on üks või rohkem rida. Lugege kirjeldust, vaadake tulemusi. Usaldusväärsus on hinnang sellele, kuidas päring oma eesmärke täidab.


Alajaotuses "General" on päringud, mis otsivad andmebaasist spetsiifilist infot, kuid otsuse selle kohta, kas midagi on õigesti või valesti peab tegema inimkasutaja, kes tulemust vaatab. 
Alajaotuses "Flaw detection" on päringud, mille tulemuses olev iga rida osundab mingile võimalikule disaini veale. Sõltuvalt päringu usaldusväärsuse hinnangust peaks inimkasutaja selle üle kontrollima.
Alajaotuses "Software measure" on päringud, mis arvutavad andmebaasi skeemi põhjal mingi arvulise väärtuse.

Soovi korral võite kasutada ka kasutajaliidese vana versiooni, kus kõik tulemused on ühel lehel. Mina kasutan tundides Teiega koos andmebaase vaadates seda. Päringud on samad, kasutajaliides erinev.

Keskkonnas on mitmeid teste. Testi "Quick test" alla on koondatud päringud, mille puhul tulemuses olev vähemalt üks rida viitab suure tõenäosusega sellele, et andmebaasi disainis on probleem/viga.

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 harjutustunnis, kui projekt juba valmis saama hakkab, jõuaksite koos õppejõuga need päringu tulemused üle vaadata.

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

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

**Vastus:**

Tähtajaga 15. september 2017 tuleb registreerida iseseisva töö teema, rakenduses realiseeritav töökoht, esialgne kasutatavate vahendite valik ja  üliõpilased, kes seda tööd üheskoos teevad. Kui otsustate teha midagi teisiti, kui vastuses kirjas, siis õppejõu teavitamiseks piisab ainult selle vastuse muutmisest.

Iseseisva töö registreerimiseks valige õppekeskkonna vasakpoolsest menüüst "Tudeng->Ülesanded" 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. Kutsun üles koonduma ja tegema projekti mitmekesi!

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.
Oracle Application Express vahendi abil ei saa teha PostgreSQL andmebaasi kasutamiseks mõeldud veebirakendust.
Enterprise Architect ja Rational Rose ei ole rakenduse tegemise vahendid, vaid on modelleerimisvahendid.


## 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öö harjutustunnis (samm-sammuline juhend).

## 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. Seadus sätestab muuhulgas, millised on delikaatsed isikuandmed. Nende töötlemisele on rangemad reeglid. 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.


---

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

## 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 ja SQL*Plusis annab see test tulemuseks TRUE, Oracle SQL Developeris  (versioon 4.1.1) 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 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.


---

# Teema: PostgreSQL

## Küsimus: Kas ja kuidas pääseb väljastpoolt ülikooli õ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 TTÜ arvutivõrku) apex.ttu.ee PostgreSQL pordile (5432) on blokeeritud järgmiste eranditega. Kaugligipääs on võimalik:

TTÜ wifist, 
eduroamist,
kodust läbi TORU.ttu.ee https://wiki.ttu.ee/it/et/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 kasutade väljaspool TTÜd ülikooli raamatukogu andmebaase. 
Veebirakenduste tegijad - apex.ttu.ee serveris on PHP ja pgApex. Kui soovite rakenduse jaoks kasutada mõnda muud serverit/vahendit, siis tuleks kas valida TTÜ 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 (ühenduse defineerimisel pgAdmin 3 ver 1.22 sisestada info nii sakkide Properties kui SSH Tunnel alla).


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

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

## 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: 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: 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 (selle kohta on ka üks eksami küsimus).
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.


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.

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.

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

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.

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

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


---

# 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: 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 TTÜ üliõpilastele kättesaadav elektrooniliselt, andmebaasist Safari. TTÜ ja TÜ ühistellimusena on TTÜ võrgus avatud juurdepääs üle 200-le selles andmebaasis olevale infotehnoloogia valdkonna raamatule. 

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.

Siit aga leiab info, kuidas pääseda raamatule ligi ka väljaspoolt TTÜ võrku. 

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.


---

# Teema: Õppetöö

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

**Vastus:**

Jah võib, eeldusel, et klassi mahute.

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

**Vastus:**

Ei ole kohustatud. Põhimõtteliselt on võimalik käia teisel ajal, sest sisu poolest harjutustunnid 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 on 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.

## Küsimus: Kuidas ennast kodulehele registreerida?

**Vastus:**

Lehele ligipääsemiseks tuleb ennast registreerida. 

Kui kasutate http://maurus.ttu.ee keskkonda esmakordselt, siis valige õppeaine lehelt menüüst Üldist=> Registreerumine. Täitke vorm ja vajutage nupule "Registreeri". 
Kui juba olete õpikeskkonnas mingile lehele registreerunud, siis siis valige Mauruse esilehel menüüst Üldist=>Minu konto ja lisage enda aktiivsete lehtede hulka:  "Andmebaasid II (IDU0230)(sügis 2017)" Ärge unustage vajutada "registreeri".


Registreerumise järel peate ootama kuni õppejõud teie juurdepääsu õiguse kinnitab.

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

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.

Ü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 pgapex 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 TTÜ 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 minupoolt 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).

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

## 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: 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 meeskonnas 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:**


 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.

apex.ttu.ee serveris üles seatud arenduskeskkond (sisselogimiseks apex kasutajanimi/parool)
MIT litsentsiga kaitstud avalik lähtekood
Tubade halduse näiterakendus (kasutajanimi: kask@ttu.ee 
parool: test)


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 vana kasutajaliides.
Erinevad tarkvaravahendid PostgreSQL andmebaaside projekteerimiseks, programmeerimiseks ja haldamiseks. Nimekirjas on nii vaba tarkvara kui ka kommertstarkvara.



Dokumentatsioon:

Tigu lahkamas, ehk ekskursioon UNIXi maailma
PostgreSQL (10.0) 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: Millist tarkvara läheb õppeaines vaja? Milline tarkvara tuleks installeerida enda isiklikku tööarvutisse?

**Vastus:**

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, 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 versioon psqlodbc_09_05_0400. Hilisemate versioonide korral tekib tõrge selle kasutamisel koos MS Accessiga (juhendis kirjeldatud andmeühenduse spetsifikatsioon PostgreSQL_yhendus ei toimi nii nagu vaja - kui hakkate tabeleid linkima saate veateate, mitte ei avata akent, kus täita lüngad). Kui olete juba installeerinud mõne hilisema versiooni, siis see tuleb kõigepealt arvutist maha võtta ja siis installeerida draiveri vanem versioon. Milline draiver täpsemalt valida ja kuidas andmeühendust seadistada lugege palun teatele lisatud failist.

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 harjutustundides 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 tasub endale Oracle katsetamise huvides installeerida, isegi kui Te projekti Oracles ei tee.