# Teema: Andmebaasi kavandamine

## 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 heauskselt uurib 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 oleks parem neid mudeleid üldse mitte säilitada ja presenteerida. Või siis tuleb need 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.

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

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](https://mariadb.com/kb/en/table-elimination/),
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](http://tallinn.ester.ee/record=b2888667~S1*est) esinemisi). Vigu saab
otsida [päringutega andmebaasi süsteemikataloogi põhjal](http://staff.ttu.ee/~eessaar/files/Design_flaws_queries.pdf).

* Kui rakenduse lähtekood on suletud ja sellesse ei ole võimalik muudatusi teha, 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](http://technology.amis.nl/blog/1375/on-the-false-sense-of-security-with-plsql-based-implementation-of-business-rules-and-what-to-do-about-it) 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](http://www.rulegen.com/). 

Väide: _Andmete valideerimine andmebaasi tasemel on halb, sest muudatuste sisseviimiseks peab andmebaasi töö peatama_. 
**Vastus: Võimalused nagu näiteks _[Online Table Redefinition](http://docs.oracle.com/database/121/ADMIN/tables.htm#ADMIN01514) ja _[Edition-Based Redefinition](http://docs.oracle.com/database/121/ADFNS/adfns_editions.htm#ADFNS020)_ aitavad seda probleemi leevendada. 
Tänapäeva andmebaasisüsteemid võimaldavad kitsendusi kiiresti [sisse ja välja lülitada](http://docs.oracle.com/database/121/CNCPT/datainte.htm#CNCPT33337) ning sama saab teha [trigeritega](http://docs.oracle.com/database/121/LNPLS/triggers.htm#LNPLS2011). 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](http://maurus.ttu.ee/346) 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."

Lõpetuseks - tänapäeval on populaarsust kasvatamas [ärireeglite mootorid](http://en.wikipedia.org/wiki/Business_rules_engine). 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.

## 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 andeid 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://userpage.chemie.fu-berlin.de/diverse/doc/ISO_3166.html](http://userpage.chemie.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](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](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](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 ([http://www.ttu.ee/asutused/raamatukogu/10640/andmebaasid-databases/elb/](http://www.ttu.ee/asutused/raamatukogu/10640/andmebaasid-databases/elb/))

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

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: [http://users.geocaching-sk.info/thailon/tools/converter/?latitude=48.759920&longitude=20.999600&convert_now=Convert+coordinates](http://users.geocaching-sk.info/thailon/tools/converter/?latitude=48.759920&longitude=20.999600&convert_now=Convert+coordinates)

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: [http://stackoverflow.com/questions/1023229/spatial-data-in-postgresql](http://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: [http://stackoverflow.com/questions/6665894/what-is-the-best-way-to-store-geographic-coordinate-data-in-a-database](http://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/](http://postgis.net/)) Oracle: Oracle Spatial and Graph ([http://docs.oracle.com/database/121/SPATL/toc.htm)](http://docs.oracle.com/database/121/SPATL/toc.htm)

## 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](http://www.regular-expressions.info/posixbrackets.html).

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

Sellele raamatule lisa pakkuv veebileht on [siin](http://maxthe3rd.com/test-driven-database-development/code.aspx). Seal on koodinäited ja viited teemakohasele artiklile ning ettekandele.


---

# Teema: Andmebaasisüsteemid

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

**Vastus:**

Jah saab, [kasutades SQL*Loader vahendit](http://www.orafaq.com/wiki/SQL*Loader_FAQ).

## 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](https://asktom.oracle.com/) lehekülg. Selle taga on Oracle ekspert Thomas Kyte, kes on kirjutanud ühed kõige paremad raamatud Oracle kohta nagu näiteks [see](http://it-ebooks.info/book/525/). Sellel 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: 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.

## Küsimus: Milliseid raamatuid soovitate erinevate andmemudelite kohta?

**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](http://www.ester.ee/record=b2287548*est)

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.)](http://www.ester.ee/record=b3046556*est)

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

**Vastus:**

[Foneetilisi algoritme](http://en.wikipedia.org/wiki/Phonetic_algorithm) saab kasutada näiteks suguvõsauuringutes, et otsida sarnase kõlaga perekonnanimega inimesi. Need inimesed võivad 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." ([allikas](http://www.okupatsioon.ee/et/kes-me-oleme/332-2011-01-14-12-22-36)).

* "Kalmisturaamatusse kanti andmeid sageli mitte dokumendi alusel vaid kuulmise järgi, seega võis viga olla juba kalmisturaamatus" ([allikas](http://www.kalmistud.ee/KKK)).

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](http://www.cio.com.au/article/140194/punk_rocker_terrorist_don_t_ask_soundex_decide/).

Foneetilisi algoritme saab ka kasutada selleks, 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 - [viide](http://archiver.rootsweb.ancestry.com/th/read/APG/2003-04/1051053365)). 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 allgoritmi 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.


---

# Teema: Õppetöö

## 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 (Oracle APEXi korral eksportimise tulemus). Muidu pole tõestatud, et rakendus oli õigeks ajaks valmis. MS Accessi puhul ei saa lähtekoodi saata - saadate rakenduse faili. Accessi puhul tuleb mulle saata *.mdb või *.accdb laiendiga fail, mitte *.mde või *.accde laiendiga fail.

## 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 (англиский (США)).