Mängureeglid.

·         Minu mõtteid ja soovitusi lõputööde teemavaliku ja teemakäsitluse kohta. Lugege kindlasti, enne, kui hakkate (siit) teemat valima!

·         Teemade nimekiri ei ole lõplik. Paljud lõputööd tehakse töökohalt saadud teemadel. Kui Teil on töökohalt pärit teema, mis seostub infosüsteemide projekteerimise, süsteemianalüüsi või andmebaaside/ andmebaasirakenduste/ arnedusvahendite arendamisega, siis võtke palun ühendust.

·         Ma arvan, et sellel lehel olevad teemad võivad olla lõputööks sobivad. Sobivuse üle otsustavad eksperdid, kes peale ülesande püstituse esitamise tähtaega annavad tööle tagasisidet (seda tuleb kindlasti lugeda ja arvestada) ja kaitsmiskomisjon.

·         Kõik teemad on pakkumises. Kasutan NB!, et tähistada teemasid, mis mulle endale hetkel kõige huvitavamad tunduvad ja mida ma tahaksin hetkel eriti hea meelega juhendada.

·         Siin lehel on teemade ideed. Seda, kas mingi teema on üliõpilase õppetaseme (bakalaureuse/magister) ja õppesuuna (informaatika/äriinfotehnoloogia) jaoks sobiv tuleb konkreetse huvi korral täpsemalt hinnata. Võimalik on, et piisava keerukuse saavutamiseks tulbe mitu teemat ühendada.

·         Teadmised peavad olema avalikud. Ma ei soovi juhendada kinnisel kaitsmisel kaitstavaid lõputöid. See kehtib nii sellel lehel olevate teemade korral kui ka üliõpilaste enda pakutud teemade korral. Keskendumine ühele ettevõttele on enamasti tunnistus töö nõrkusest. Hea lõputöö kirjeldab üldistatud probleeme ja nende lahendusi. Sellise töö tulemusi saaks rakendada erinevates ettevõtetes. Juhtumianalüüsis ei pea konkreetset ettevõtet üldse nimetama (võib rääkida ettevõttest X).

·         Enne mistahes teema valimist peab valija tegema otsingumootori abil taustauuringu, kas tema poolt lahendada soovitav probleem on juba lahendatud. Jalgrattaid pole vaja leiutada, küll aga võib olemasolevaid jalgrattaid paremaks teha. Sellise taustauuringu tulemused on mistahes lõputöö oluline osa ning aitavad püstitada töö uurimisküsimusi.

·         Kui valite sellelt lehelt teema, kuid jätate seejärel õpingud pooleli või vahetate juhendajat, siis palun andke sellest mulle kohe teada. Nii saab Teie valitud teemal tööd teha keegi teine. Samuti on see väga oluline õppejõule koormuse planeerimisel. Kui õppejõud ei tea Teie loobumisest, siis hindab ta oma koormust suuremaks kui see tegelikult on ja väga võimalik, et lükkab seetõttu mõne juhendamise taotluse tagasi.

·         Juhendajana ei ole ma huvitatud teema mitmeks semestriks ettebroneerimisest.

·         Kui hiljemalt kaks semestrit peale teema valimist ei ole töö kaitstud siis on õige anda teema vabaks ja juhendamise suhe lõpetada. Pikendamine on võimalik kokkuleppel õppejõuga.

·         Töö toimetamine on autori, mitte juhendaja ülesanne.

·         Palun üritage ka kõik ettenäidatavad vaheversioonid võimalikult hästi toimetada ja keeleliselt võimalikult heasse korda saada, et oleks võimalik keskenduda sisule.

·         Silmast-silma kohtumised ja tulemuste koos ülevaatamine on efektivsem ning eelistatum kui kirjateel projekti ülevaatamine ning küsimustele vastamine.

·         Juhendaja jälgib töö kirjutamise protsessi ja annab selle kohta hinnangu juhendaja arvamuses.

·         Juhendan töid, mis on kirjutatud eesti keeles või inglise keeles (võimalik juhul kui eesti keel ei ole autori emakeel).

·         Lõputöö juhendamine on kahepoolne protsess. Juhendatavale peab teema südamest huvi pakkuma ja ta peab soovima tööd teha maksimaalselt heale tulemusele. Juhendaja peab seda huvi nägema ning olema ka näinud varasema õppetöö ajal. Kui sellist "keemiat" ei ole, siis ei saa kahjuks ka juhendamisest asja. Kuna juhendatavate arv on piiratud, siis lähtun juhendatavate valikul nendest kriteeriumitest.

·         Vajalikke viiteid lõputöö koostajale leiate sellelt leheküljelt.

Teemade kategooriate pealkirjad viitavad, milliste õppekavade (Informaatika, Äriinfotehnoloogia) ja õppetasemete (bakalureus, magister) jaoks on need teemad sobilikud. Magistritööde kohta kehtib paljudel juhtudel klausel, et teema on sobilik vaid siis, kui õnnestub sõnastada piisavalt keeruline ja väljakutset pakkuv ülesanne. See võib näiteks tähendada mitme siin lehel toodud teema + magistrandi töökohal lahendatavate ülesannete integreerimist kokku üheks ülesandeks. Järgnevalt on otsviited teemade kategooriate juurde.

·         Ankurmodelleerimise vahendite täiustamine ja ankurmodelleerimise kasutusvõimaluste laiendamise uurimine (Informaatika baka/magister, Äriinfotehnoloogia baka/magister)

·         Enterprise Architect CASE vahendi funktsionaalsuse suurendamine (Informaatika baka/magister, Äriinfotehnoloogia baka/magister)

·         Infosüsteemide, andmebaasirakenduste või andmebaaside arendamist abistavate rakenduste loomine (Informaatika baka/magister, Äriinfotehnoloogia baka/magister)

·         Andmebaasirakenduste loomine (Informaatika baka/magister, Äriinfotehnoloogia baka/magister)

·         Andmebaasirakenduste disainilahenduste uurimine (Informaatika baka/magister, Äriinfotehnoloogia baka/magister)

·         Andmebaaside disainilahenduste uurimine (Äriinfotehnoloogia baka/magister, Informaatika baka/magister)

·         Andmebaasi disainilahenduste mustrite formaadis kirjeldamine (Äriinfotehnoloogia baka/magister, Informaatika baka/magister)

·         Andmebaaside evolutsioonilise arendamise meetodite ja vahendite tundmaõppimine ja kasutamine (Äriinfotehnoloogia baka/magister, Informaatika magister)

·         Keerukate süsteemide modelleerimine (Äriinfotehnoloogia baka/magister)

·         Artefaktide mustripõhise võrdlemise teooria ja praktika edasiarendamine (Äriinfotehnoloogia baka/magister)

·         Andmekäitluskeele lausete parema jõudluse saavutamise võimaluste otsimine (Äriinfotehnoloogia baka/magister)

 

Ankurmodelleerimise vahendite täiustamine ja ankurmodelleerimise kasutusvõimaluste laiendamise uurimine (Informaatika baka/magister, Äriinfotehnoloogia baka/magister)

Ankurmodelleerimine on andmebaasi projekteerimise metoodika, mis on välja töötatud ning edukalt kasutusele võetud andmeaitade ja andmevakkade loomiseks, kuid mida saab kasutada ka operatiivandmete andmebaaside loomiseks. Ankurmodelleerimise põhimõttel loodud SQL-andmebaas aitab edukalt toime tulla andmebaasi skeemi evolutsioneerimise, andmete osalise puudumise ja ajalooliste andmete säilitamise probleemidega. Selle metoodika toetuseks on loodud onlain modelleerimiskeskkond ning erinevate SQL-andmebaasisüsteemide jaoks andmekirjelduskeele koodi genereerimiseks mõeldud generaator. 2015. aastal valmis minu juhendatud magistritöö tulemusena koodi generaator PostgreSQL jaoks.

1.    Töö eesmärgiks on uurida kui lihtne/keeruline on AM andmebaasi kasutada tehingutöötluse süsteemi loomiseks. Kõigepealt tuleb kavandada ja realiseerida AM andmebaas ja seda kasutav rakendus. Andmebaasi aluseks võib olla "Andmebaasid I" kontseptuaalne andmemudel ja rakendus tuleb realiseerida ühe töökoha ulatuses. Realiseerimiseks tuleb valida võimalikult mahuka funktsionaalsusega töökoht (töövihiku korral X haldur). Seejärel tuleb AM andmebaasi skeemi evolutsioneerida (lisada nt juurde uusi atribuute, muuta mõne staatilise atribuudi/sideme ajalooliseks) ning muuta vastavalt rakendust. Lugege andmebaasi skeemi evolutsiooni kohta artiklit: Hartung, M., Terwilliger, J., Rahm, E. (2011). Recent Advances in Schema and Ontology Evolution. Data-Centric Systems and Applications, 2011, 149-190. Töö põhitulemuseks on analüüs kuivõrd lihtne/keeruline oli seda kõike teha, millised on sellise lähenemise head ja halvad küljed, millega tuleb arvestada. Töö tegemine eeldab huvi/oskust andmebaasi ja rakendust programmeerida. Võrdluse huvides tuleb sama eksperimendi viia läbi ka "tavalise" disainiga andmebaasi põhjal.

Lisaks on vaja uurida, milliseid kitsendusi ja millisel viisil saab PostgreSQLis loodud ankurmodelleerimise (AM) andmebaasis (kus enamik tabeleid on kuuendal normaalkujul) jõustada ning kui palju see erineb kitsenduste jõustamisest "tavalises" andmebaasis (kus enamik tabeleid on viiendal normaalkujul). Lähteinfot saab siit. Kõigepealt tuleb sama kontseptuaalse andmemudeli alusel disainida ja realiseerida nii AM andmebaas kui "tavaline" andmebaas. Loodud andmebaasis peab olema võimalik jõustada võimalikult palju erinevat tüüpi kitsendusi. Andmebaas tuleb seda silmas pidades kavandada, mis tähendab, et enne andmebaasi kavandamise alustamist tuleb võimalikud kitsenduste tüübid kaardistada. Seejärel tuleb üritada mõlemas andmebaasis neid kitsendusi deklaratiivsel või protseduursel viisil (trigerite abil) jõustada. Töö peab jõudma järeldusteni "AM" andmebaasis kitsenduste jõustamise võimaluste ja probleemide kohta võrrelduna "tavalise" andmebaasiga. Töö tegemine eeldab väga heal tasemel andmebaasi programmeerimise oskust.

2.    Kirjeldada metoodika, mille alusel "tavalise" struktuuriga SQL-andmebaas, milles olevad tabelid on maksimaalselt viiendal normaalkujul ja mida kasutab üks või mitu erinevat rakendust, asendada ankurmodelleerimise alusel loodud andmebaasiga, milles olevad baastabelid on valdavalt kuuendal normaalkujul. Metoodika kirjeldamiseks kasutage Eclipse Process Framework Project (EPF) vahendit. Kavandada ja realiseerida selle metoodika rakendamist abistav tarkvara (võib olla eraldisesisev tarkvara, aga ka ühe või mitme olemasoleva tarkvara laiendused). Rakendada seda metoodikat konkreetse andmebaasi ja rakenduste ümbertöötamiseks.

 

Enterprise Architect CASE vahendi funktsionaalsuse suurendamine (Informaatika baka/magister, Äriinfotehnoloogia baka/magister)

Kõik selles jaotises olevad teemad tähendavad muuhulgas vajadust töö tulemusena hinnata, kui lihtne või keeruline on Enterprise Architect CASE vahendi funktsionaalsust laiendada. Kõigi nendel teemadel töö tegijatele on oluline see bakalaureusetöö, kus projekteeritakse ja realiseeritakse Enterprise Architecti jaoks mudeliteisendus. Siit, aga näite nimekirja kõigist kolmandate osapoolte poolt loodud Enterprise Architecti laiendustest. Siin on Enterprise Architecti enda dokumentatsioon laienduste loomise kohta.

6.    Enterprise Architecti (EA) funktsionaalsuse parandamine seoses andmebaaside füüsilise projekteerimisega ning andmebaasi disaini mudelist koodi genereerimisega.

·         EA kasutab andmebaasi disaini mudelist SQL koodi genereerimiseks malle. Parandada MS Accessi jaoks mõeldud malli, et lahendada probleemid, mida kirjeldati "Andmebaasid I" aines seoses SQL koodi genereerimisega. Parandada PostgreSQL jaoks mõeldud malli, et lahendada probleemid, mida kirjeldati "Andmebaasid II" iseseisva töö ülesandes 4.

·         Laiendada Enterprise Architecti nii, et seal oleks võimalik PostgreSQL andmebaasi disaini mudelis modelleerida domeene, loendtüüpe ja liittüüpe ning leida viis kasutada neid tabelite veergude kirjeldamisel (kui muud üle ei jää, siis struktureeritud kommentaaridena). Enterprise Architect peab olema võimeline sellest kirjeldusest genereerima CREATE DOMAIN, CREATE TYPE lauseid ja CREATE TABLE lauseid, kus domeenidele ja tüüpidele viidatakse.

7.    Luua Enterprise Architect CASE vahendi jaoks skriptid või muu lahendus, mis genereerib tegevusdiagrammide, olekumasina mudelite (seisundidiagrammide) ja kasutusjuhtude diagrammide põhjal neid diagramme kirjeldavad eestikeelsed lausendid (eeldame, et diagrammid on ka eesti keeles). Selline funktsionaalsus on oluline:

·         õppimise seisukohalt, sest diagrammi joonistaja saab sõnalise tagasiside selle kohta, mida ta üles joonistas,

·         mudelite kontrolli seisukohalt, sest diagrammi joonistaja saab sõnalise tagasiside selle kohta, mida ta üles joonistas,

·         mudelite võimalikult laialdase kasutamise seisukohalt, sest mõned inimesed eelistavad vaadata jooniseid, teised aga lugeda teksti.

Eelnevalt on ühes lõputöös realiseeritud tarkvara, mis genereerib lauseid klassidiagrammidest.

8.    Martin Fowler on öelnud, et arvutiteaduses on kaks rasket teemat ja nendest üks on asjade nimetamine. Luua Enterprise Achitect (EA) CASE vahendis skriptid või muu lahendus, mis ühtlustab ja parandab andmebaasi füüsilise disaini mudelis andmebaasiobjektide (tabelid, veerud, kitsendused, indeksid) nimesid. Kasutajal peab olema võimalus nimede formaate ise määrata/muuta. Veidi sarnasel teemal kaitsti 2018. aastal bakalaureusetöö, mille tulemusena töötati välja PostgreSQL laiendus baastabelitega seotud kitsenduste ümbernimetamiseks. EA laiendus peaks lisaks kitsendustele olema võimeline ümbernimetama ka teisi andmebaasiobjekte.

9.    Enterprise Achitect (EA) CASE vahendis saab muuhulgas luua kontseptuaalse andmemudeli ning kontseptuaalsest andmemudelist genereerida andmebaasi disaini kirjeldava mudeli esimese versiooni. See on mudeliteisenduste näide. EA võimaldab luua uusi mudeliteisendusi. Lõputöö ülesandeks on projekteerida ja realiseerida mudeliteisendus, mis loob olekumasina mudeli (seisundidiagrammide) alusel kasutusjuhtude mudeli esimese versiooni. Selle aluseks on "Andmebaasid I" tutvustatud lähenemine, kus kasutusjuhte leiti põhiolemitüübi elutsüklit kirjeldava olekumasina põhjal. Töö ühe osana tuleb uurida/realiseerida kuidas esitada mudelites ka ülejäänud algoritmi poolt nõutud sisendid, selleks, et loodud generaator saaks ka nendega arvestada (generaator vajab ka infovajaduste nimekirja ning infot selle kohta, milline tegutseja algatas millise seisundi ülemineku).

10. Enterprise Achitect (EA) CASE vahendis saab muuhulgas genereerida andmebaasi füüsilise disaini mudelist SQL koodi. See on mudelist koodi genereerimise näide. EA võimaldab luua uusi koodigeneraatoreid. Lõputöö ülesandeks on projekteerida ja realiseerida koodigeneraator, mis genereerib kontseptuaalse andmemudeli ja olekumasina mudelite (seisundidiagrammide) alusel andmebaasioperatsioonide lepingute kirjelduse (nagu need on "Andmebaasid I" projektis). Töö käigus on vaja projekteerida ja realiseerida UML mudeliprofiil, mis võimaldab ära kirjeldada, milliseid põhiolemite andmeid saab millise seisundi korral muuta (nt kinnitamata tellimuses saab muuta nii tähtaega, aadressi kui kommentaari, kuid kinnitatud tellimuses ainult kommentaari). Seda infot on võimalik andmebaasioperatsioonide lepingute genereerimisel ära kasutada. Mudeliprofiilide kohta EAs saab infot siit ja siit.

11. Enterprise Achitect (EA) CASE vahendis saab muuhulgas genereerida andmebaasi füüsilise disaini mudelist SQL koodi. See on mudelist koodi genereerimise näide. EA võimaldab luua uusi koodigeneraatoreid. Lõputöö ülesandeks on projekteerida ja realiseerida koodigeneraator, mis loeb sisendinda andmebaasi füüsilise disaini mudelit ja põhiobjekti olekumasina mudelit ning produtseerib PostgreSQL jaoks trigerite koodi, mis kontrollib seisundimuudatuse vastavust olekumasina mudelile (vt andmebaaside mustripõhise juhendi ("Andmebaasid I" kodulehel) Oracle koodinäidet, kus on selliste trigerite näide).

12. Töötada välja meetod, kuidas modelleerida UMLis SQL-andmebaasi trigereid paremini kui klassi operatsioon, mille kirjeldusse on kirjutatud trigeri protseduuri kood. Teha kindlaks, milline dünaamika diagramm (tegevus-, jada-, koostöö diagramm) sobib trigeri protseduuri visuaalseks modelleerimiseks kõige paremini ning kas oleks vaja kasutusele võtta uusi UML stereotüüpe, märgendi definitsioone või kitsendusi, et trigereid paremini modelleerida. Samuti tuleb uurida, kuidas modelleerida ja mudelite põhjal analüüsida trigerite omavahelist vastasmõju. Vajadusel töötada välja UML mudeliprofiil trigerite projekteerimiseks ning realiseerida see Enterprise Architect jaoks. Realiseerida samas CASE vahendis ka trigerite koodi genereerimise funktsionaalsus. Töötada välja meetod SQL-andmebaasi trigerite testimiseks. Modelleerida, realiseerida, testida keerukaid trigereid kasutav süsteem kasutades eelnevalt väljatöötatud meetodeid. Mudeliprofiilide kohta EAs saab infot siit ja siit. Inspiratsiooni saamiseks tuleks uurida süsteeme, mis võimaldavad modelleerida äriprotsesse sündmus-tingimus-tegevus reeglitena ning kombineerida neid reegleid graafipõhiste mudelitega.

13. Dokumentatsiooni koostamine on infosüsteemi projekteerimise oluline protsess. Mudelitest dokumentatsiooni genereerimise võimalus on üks (paljudest) põhjustest, miks infosüsteemi modelleerida ja viia läbi mudelipõhist arendust. Töö eesmärgiks on luua Enterprise Architect süsteemi jaoks pakettide struktuur ja dokumendi mall, mis võimaldavad genereerida projekti aruande, mis on võimalikult sarnane "Andmebaasid I" iseseisva töö projekti dokumendiga. Selleks, et taolist ettevõtmist saaks korrata teiste õppeainete või arendusprojektide juures tuleb kõik tehtavad tegevused UML mudelite keeles ära kirjeldada. Enterprise Architecti RTF dokumentide generaatori juhend on siin.

14. Luua Enterprise Architect CASE vahendi jaoks valideerimisreeglid, mis kontrollivad kontseptuaalseid andmemudeleid ja andmebaasi füüsilise disaini mudeleid. Luua skriptid leitud vigade parandamiseks. Näiteks võib luua skripti, mis Oracle andmebaasi kirjeldava andmebaasi diagrammi korral teisendab kõik identifikaatorid Oracle jaoks sobivale kujule. Töö alguses tuleb tutvuda selle lõputööga ja täiendavalt uurida olemasolevaid andmete modelleerimise CASE vahendeid tegemaks kindlaks, kas ja milliseid andmemudelite kontrolle need võimaldavad läbi viia. Uuringu läbiviimiseks tuleb koostada erinevates süsteemides vigadega mudelid ning analüüsida CASE süsteemi võimet neid vigu üles leida. Leitud + enda väljamõeldud kontrollidest tuleb moodustada nimekiri võimalikult ammendav ja hästi kategoriseeritud nimekiri, millest võimalikult suure osa alusel mudelite kontrollimine ja parandamine tuleb Enterprise Architecti vahendis realiseerida.

15. Luua Enterprise Architecti jaoks UML mudeliprofiil, mis võimaldaks projekteerida Apache Cassandra andmebaase ning koodigeneraator, mis genereerib loodud mudelitest CQL lauseid. Mudeliprofiilide kohta EAs saab infot siit ja siit. Taustaga tutvumist alustage sellest lõputööst.

16. "Puhast koodi" (clean code) on lust lugeda ja lihtne edasi arendada. Kood on spetsifikatsioon arvutitele, mudel on spetsifikatsioon inimestele. Nii nagu puhas kood on soovitavad ka puhtad mudelid. Clean Code raamatus esitatud koodi puhastamise juhiste alusel on ühes bakalaureusetöös kirja pandud samasugused juhised süsteemianalüüsi mudelitele. Neid juhiseid on detailiseeritud ja edasiarendatud süsteemianalüüsi mudelite halbade lõhnade kataloogis. Töö ülesandeks on hinnata kõigi nende juhiste alusel mudelite automatiseerimise võimalust ning realiseerida EA laiendus, mis võimalikult suure hulga juhiste alusel mudelite kontrollimist automatiseerib.

Infosüsteemide, andmebaasirakenduste või andmebaaside arendamist abistavate vahendite loomine (Informaatika baka/magister, Äriinfotehnoloogia baka/magister)

17. NB! Arendada edasi Notepad++ pistikprogrammi (loodud selles magistritöös, edasiarendatud selles bakalaureusetöös), mis on mõeldud MS Accessi ja PostgreSQL andmebaasis SQL lausete käivitamiseks ja nende lausete vigade suhtes kontrollimine. Tuleb analüüsida võrreldavaid programme ja eelmistes töödes esitatud arendussoovitusi, et leida edasised täiendused.

18. NB! Arendada edasi veebipõhist visuaalset PostgreSQL andmekäitluse lausete koostamise tarkvara, mille viimasesse versiooni lisati INSERT, UPDATE ja DELETE lausete koostamise võimalus. Tuleb analüüsida võrreldavaid programme, et saadud info alusel töötada ümber SELECT lausete koostamise kasutajaliides. Samuti tuleb lisada uusi võimalusi SQL konstruktsioonide esitamiseks ja vastavalt visuaalselt esitatud konstruktsioonidest koodi genereerimiseks.

19. NB! Projekteerida ja realiseerida veebipõhine SQL lausete harjutamise keskkond, kuhu õppejõud saab välja panna SQL harjutamise ülesandeid (eest või inglise keeles) ja kus õppur saab neid ülesandeid lahendada, kusjuures programm üritab lahendust automaatselt kontrollida. Töö ühe osana tuleb uurida, kuidas SQL lauseid saaks automaatselt kontrollida. Töö peab keskenduma SELECT lausetele, kuid lahenduse arhitektuur peab tulevikus võimaldama võimalikult lihtsalt lisada ka andmete muutmise lausete ülesandeid. Keskkond oleks mõeldud õppuritele enesekontrolliks, mitte õppurite hindamiseks. Veebirakendus peab olema tehtud PHPs ning andmebaasisüsteemiks on PostgreSQL.

20. NB! Jätkata PostgreSQL andmebaasisüsteemi põhise metaandmetega juhitavate veebirakenduste kiirprogrammeerimise keskkonna pgApex arendamist. Selle süsteemi arendamise kohta on tehtud üks magistritöö ja kaks bakalaureusetööd (viide ja viide), kuid teha on veel palju. Kõikides nendes töödes on üheks alajaotuseks arendusvaade ja nendest leiab palju täiendusvajadusi. pgApexit tuleb ise katsetada, võrrelda Oracle APEXiga ja teha kindlaks, kas leidub veel täiendusvõimalusi. Järgmiseks ülesandeks on väljalaske planeerimine (release planning) – milline funktsionaalsus lõputöö tulemusena realiseerida. Tuleb valida meetod selle otsustamiseks ja seda rakendada. Kõik täiendused tuleb mudelite abil projekteerida ja ka tarkvaras realiseerida ning testida. Töö peab ka kirjeldama täienduste tegemise protsessi. Siin on pgApexi serverisse üles laetud arenduskeskkond ning siin on selle vahendi MIT litsentsiga kaitstud lähtekood. Töö tulemus peab olema samuti avatud lähtekoodiga, mida kaitseb MIT litsents. Projekt peab olema GitHubis. Töö kõrvaltegevusena tuleb teha statistikat vahendi andmebaasi skeemimuudatuste ja nendest tingitud rakenduse lähtekoodi muudatuste kohta.

21. NB! Arendada edasi andmebaasioperatsioonide lepingutest PostgreSQL funktsioonide genereerimise tarkvara. Tarkvara võtab sisendiks tabelite struktuuri kirjelduse ja andmebaasioperatsiooni lepingu ning genereerib sellest käivitatava koodi. Tabelite struktuuri kirjeldamiseks ning lepingute esitamiseks on väljatöötatud valdkonnapõhised keeled. Nende keelte abil ei saa mõningaid  võimalikke lepinguid esitada ning tarkvara ei genereeri koodi mõnikord õigesti – seega vajavad nii keeled kui generaator täiendamist ja parandamist. Neid probleeme puudutatakse magistritöö jaotistest 6.2 ja 7.2.

22. Arendada edasi PostgreSQL andmete maskimise laiendust. Lahendamist vajavad kõik magistritöö jaotises 5.10 väljatoodud probleemid ning piirangud. Samuti peab autor otsima täiendavaid laienduse täiustamise võimalusi. Lisaks peab autor üritama laienduse koodi optimeerida ja puhastada. Töö üheks osaks on mingi olemasoleva andmebaasi maskimine kasutades edasiarendatud laiendust.

23. Projekteerida ja realiseerida avatud lähtekoodiga veebipõhine tarkvara, mis realiseerib "Andmebaasid I" teemas 14 viidatud algoritmi "Denormalization Survival Guide". Tarkvara tuleb realiseerida PostgreSQL või Oracle jaoks (veel parem, kui tarkvara on häälestatav mõnema andmebaasisüsteemi jaoks). Tegemist peab olema täieliku lahendusega, kus veebiliidese kaudu valitakse andmebaas, tabeleid, vastatakse küsimustele (osadele küsimustele saab süsteem leida vastuse automaatselt tehes päringuid andmebaasist) ning seejärel tekitab programm uued andmestruktuurid ning kannab andmed nendesse uutesse struktuuridesse üle. Samuti peab programm oskama välja pakkuda ja luua indekseid uutele tabelitele. Tarkvara rakenduse osa tuleb realiseerida PHP abil. Projekt peab olema GitHubis. Sellel teemal on tehtud bakalaureusetöö, mille tulemusena valmis Pythonis kirjutatud töölauarakendus, mis täidab püstitatud eesmärke osaliselt. See teema tasub valida vaid siis, kui autoril on oskus ja valmidus see täielikult realiseerida.

24. Jätkata veebi- ja andmebaasipõhise metamodelleerimise vahendi WebMeta arendust, realiseerides selle lõppkasutajate (modelleerija ning mudelite vaataja) töökohad. Selle süsteemi esimeses arendusetapis on loodud administraatori töökoht ning selle taga olev metaandmete andmebaas ja trigeripõhine lahendus mudelite hoidmiseks mõeldud tabelite haldamiseks. Sellel teemal kaitsti 2016. aasta talvel magistritöö. Teie ülesandeks on luua veebipõhine programm, mis loeb infot metaandmete andmebaasist ja ehitab dünaamiliselt valmis (hea kasutatavusega) vormid nendes tabelites olevate andmete lugemiseks ja haldamiseks. Andmebaasisüsteem on PostgreSQL. Kuna administraatori liides on loodud PHPs, kasutades Yii raamistikku, siis tuleb samu vahendeid edasi kasutada. Töö kõrvaltegevusena tuleb teha statistikat vahendi andmebaasi skeemimuudatuste ja nendest tingitud rakenduse lähtekoodi muudatuste kohta.

25. Jätkata veebi- ja andmebaasipõhise metamodelleerimise vahendi WebMeta arendust, realiseerides selle päringute halduse funktsionaalsuse. Selle süsteemi esimeses arendusetapis on loodud administraatori töökoht ning selle taga olev metaandmete andmebaas ja trigeripõhine lahendus mudelite hoidmiseks mõeldud tabelite haldamiseks. Sellel teemal kaitsti 2016. aasta talvel magistritöö. Teie ülesandeks on luua veebipõhine programm, mis võimaldab võimalikult mugavalt ja visuaalselt koostada nende tabelite põhjal päringuid. Töö eeldab erinevate päringute koostamise viisidega tutvumist, võimalike valmis tarkvarakomponentidega tutvumist ning otsustamist, kas kohandada olemasolevat või alustada tegemist nullist. Andmebaasisüsteem on PostgreSQL. Kuna administraatori liides on loodud PHPs, kasutades Yii raamistikku, siis tuleb samu vahendeid edasi kasutada. Töö kõrvaltegevusena tuleb teha statistikat vahendi andmebaasi skeemimuudatuste ja nendest tingitud rakenduse lähtekoodi muudatuste kohta.

·         Tuleviku CASE vahendid (CASE 2.0) peaksid olema pilvepõhised ja võimaldama süsteemi hästi läbimõeldud keeles ära kirjeldada. Kõikvõimalikud mudelid ja kood oleksid selle kirjelduse põhjal esitatud vaadete väärtused. Siin kirjeldatakse seda lähenemist täpsemalt. Käesolev veebi- ja andmebaasipõhine metamodelleerimise vahend on tegelikult üks võimalik keskkond, kus selliseid CASE vahendeid luua. Loodud päringute haldamise funktsionaalsuse demonstreerimiseks tuleb realiseerida WebMeta vahendis CASE vahend, mis lubab kirjeldada kontseptuaalseid andmemudeleid. Sellele CASE vahendile tuleb päringute haldamise vahendi abil luua vaated, mis esitavad kasutajale selliselt kirjeldatud andmebaasi PostgreSQLis realiseerimiseks vajaliku koodi.

26. Projekteerida ja realiseerida avatud lähtekoodiga veebipõhine tarkvara, mis üldistab ja võimaldab hindajatel realiseerida "Andmebaasid II" õppeainest tuntud hindamismudelit (mis oli realiseeritud Excelis). Seda peaks saama kasutada igasugustes õppeainetes, mitte ainult andmebaaside õpetamisel ja ka hinnatavate punktide klassid (Exceli hindamismudelis, dokument, andmebaas ja rakendus) ning nende olulisus peavad olema häälestatavad. Hinded ja hinnangud lähevad edasise analüüsimise huvides andmebaasi ja seega poleks tegemist tsentraliseeritud ülemaailmse teenusega (mis koguks hinnete ja kasutajate infot üle maailma), vaid iga õppeasutus või hindaja saaks selle oma serverisse üles seada. Kasutajaliides peab võimaldama tarkvara tõlkimist. Hinnatavate kontaktandmeid peaks olema võimalik mingil viisil hulga kaupa sisse lugeda, st neid ei pea ühekaupa sisestama. Peale hindamise lõppu peab süsteem genereerima aruande (pdf) ja saatma selle hinnatavate meilile + õppejõu meilile. Süsteem peab võimaldama analüüsida, millistes hindamismudeli punktides teevad üliõpilased kõige rohkem vigu. Süsteem tuleb realiseerida PostgreSQL + PHP põhjal. Projekt peab olema GitHubis. Süsteemil on teatav sugulus selle suuliste eksamite kiireks hindamiseks mõeldud tarkvaraga selles mõttes, et mõlemas saab valida tagasisidet etteantud nimekirjast (siin on ettekandes kirjeldatud äpi veebileht).

27. Projekteerida ja realiseerida avatud lähtekoodiga veebipõhine tarkvara, mis võimaldab leida infosüsteemi strateegilise analüüsi käigus põhiolemitüüpe, mis on omakorda aluseks funktsionaalsete allsüsteemide ning registrite leidmisele. See tähendab "Andmebaasid I" õppeaines pakutud erinevate kategooriate meetodite viimist algoritmi täpsuseni ning selle algoritmi realiseerimist. Süsteem peab kasutama sisseehitatud teadmusbaasi ning küsima kasutajatelt küsimusi. Süsteem peab küsimuste vastustest õppima (need meelde jätma ning oma tulevastes küsimustes ja pakkumistes arvestama). Süsteem tuleb realiseerida PostgreSQL + PHP põhjal. Projekt peab olema GitHubis.

28. Arendada edasi avatud lähtekoodiga tarkvara, mis võtab sisendiks andmebaasioperatsioonide lepingu kirjelduse ning genereerib sellest PostgreSQL funktsioonide loomise koodi. Hetkel loodud lahendus ei võimalda genereerida koodi mitmete keerukamate operatsioonide korral. Töö nõuab nii tarkvara täiendamist kui ka tarkvaras kasutatava valdkonnapõhise keele täiendamist.

29. Arendada edasi Kolmanda Manifesti andmebaaside projekteerimiseks kasutatavat UML profiili ja koodigeneraatorit. Sellel teemal on juba tehtud kaks edukat bakalaureusetööd. Ka Kolmanda Manifesti üks autoritest, Hugh Darwen, on siiani tehtud töösse hästi ja huviga suhtunud. Võimalikud arenduse suunad on nimetatud profiili kodulehe alajaotuses "Limitations".

30. Arendada edasi SQL andmebaaside projekteerimiseks kasutatavat UML profiili ja koodigeneraatorit. Sellel teemal on juba tehtud üks edukas bakalaureusetöö. Võimalikud arenduse suunad on nimetatud profiili kodulehe alajaotuses "Limitations".

31. Valdkonnapõhise keele ja koodigeneraatori projekteerimine ja realiseerimine kasutades mõnda metamodelleerimise vahendit (näiteks MetaEdit+, Actifsource, GME: Generic Modeling Environment). Metamodelleerimise vahendid on mõeldud uute CASE vahendite loomiseks, millest igaüks võimaldab kasutada mõnda valdkonnapõhist keelt. Loodud keel ja koodigeneraator peavad olema mõeldud üliõpilase töökohal või üliõpilase enda hobiarenduses mingi keeruka arendusülesande lihtsustamiseks. Kõige paremaks metamodelleerimise vahendiks on MetaEdit+, mis on aga kommertssüsteem. Seega saab näiteks ühe töö sisuks olla selle ülesande lahendamine kasutades ainult tasuta levitatavaid vahendeid. Kui loodav keel on lihtne ja töö keerukus selle all kannatab, siis tuleb see keel realiseerida mitmes vahendis. Töösse tuleb lisada nende vahendite võrdlus sh parima vahendi valiku otsustusmudel, mis on loodud kasutades Saaty hierarhilise analüüsi meetodit (soovitav on õppeaine "Täppismeetodid otsustuste vastuvõtmisel" eelnev või samaaegne õppimine).

32. PostgreSQL andmebaaside füüsilise disaini nõustamismooduli arendus. Töös tuleb kõigepealt otsida PostgreSQL andmebaaside disaini nõustamisvahendeid, kas leiate midagi peale pgtune vahendi. Seejärel tuleb uurida leitud PostgreSQL vahendeid ja kõrvutada neid teiste andmebaasisüsteemide samasisuliste vahenditega nagu IBM (DB2 Design Advisor), Microsoft (SQL Server Database Tuning Advisor) ja Oracle (SQL Access Advisor). Selleks peab vaadeldavate andmebaasisüsteemide abil looma samade testandmetega andmebaasi ning võrdlema erinevate nõustamissüsteemide pakutavaid soovitusi selle andmebaasi füüsilise disaini parandamiseks. Ülesanne eeldab, et Teil on ülikooli väliselt juurdepääs vastavale tarkvarale. Sellel teemal võib ka lugeda raamatust Physical Database Design: the database professional's guide to exploiting indexes, views, storage, and more (The Morgan Kaufmann Series in Data Management Systems) by Sam S. Lightstone, Toby J. Teorey, and Tom Nadeau (Paperback - April 4, 2007)(kättesaadav Tallinna Tehnikaülikooli raamatukogu vahendusel EBC : Ebook Centralplatvormilt).Saadud info on sisendiks, et arendada PostgreSQLi nõustamismoodulit. Tuleb otsustada, kas töötada edasi pgtune'iga, luua PostgreSQLi laiendus või näiteks eraldiseisv veebipõhine tarkvara. Tulemuseks olev tarkvara peab olema avatud lähtekoodiga. Projekt peab olema GitHubis.

Andmebaasirakenduste loomine (Informaatika baka/magister, Äriinfotehnoloogia baka/magister)

33. Klassifikaatorite register ja klassifikaatorite funktsionaalne allsüsteem (reference data management) on infosüsteemide oluline alamosa. Alustage teemaga tutvumist sellest esitlusest. Turul on mitmeid omanduslikke klassifikaatorite haldamise süsteeme, mis pakuvad suurt paindlikust ja funktsionaalsust, kuid on ka kallid (juurutamiseks võib kuluda kuni 1 miljon USD).

Töö eesmärk ei ole realiseerida konkureeriv üldlahendus, vaid alustada väikselt ja luua esimene versioon spetsialiseeritud süsteemist. Töö eesmärgiks on realiseerida esimene versioon avatud lähtekoodiga metaandmetega juhitavast PostgreSQL andmebaasis oleva andmebaasi klassifikaatorite haldamise tarkvarast, mis arvestab sellega, et klassifikaatorite põhiandmed on eraldi tabelites. Lisaks on loodud kunstlikuks ühendajaks olev tabel, mis võimaldab hallata klassifikaatorite metaandmeid nagu klassifikaatori hetkeseisund ja seisundimuudatuste ajalugu. Tarkvara peab arvestama hierarhiliste klassifikaatorite võimalusega. Taolist andmebaasi disaini kirjeldatakse selles bakalaureusetöös. Metaandmetega juhitav tähendab seda, et tarkvara andmebaasis registreeritakse klassifikaatorite süsteemi poolt hallatavate klassifikaatorite tabelite skeemid ja nimed. Selle alusel leiab tarkvara juba süsteemikataloogist nende tabelite veerud. Selleks, et hakata haldama uut klassifikaatorit, poleks vaja teha muud, kui registreerida selle tabeli skeem ja nimi tarkvara andmebaasis. Süsteem tuleb realiseerida PostgreSQL + PHP põhjal. Projekt peab olema GitHubis. Kasutajaliidese keelte valikus peab olema inglise keel ja eesti keel ning süsteem tuleb kohe alguses luua nii, et keeli oleks lihtne lisada.

Enne kui see teema valida tuleb uurida olemasolevaid klassifikaatorite haldamise vahendeid ja veenduda, et juba ei ole sellise funktsionaalsusega avatud lähtekoodiga tarkvara. Selle uuringu tulemused oleksid ühtlasi töö üheks esimeseks osaks, mis pakub töö vajalikkuse põhjenduse ning nõudeid uuele tarkvarale. Töö esimeses osas tuleks kaardistada selliselt süsteemilt oodatav funktsionaalsus. Järgmiseks ülesandeks on väljalaske planeerimine (release planning) – milline funktsionaalsus lõputöö tulemusena realiseerida. Tuleb valida meetod selle otsustamiseks ja seda rakendada. Seejärel tuleb valitud funktsionaalsuste ulatuses süsteem projekteerida ja realiseerida. Tulemuse hindamiseks tuleb veenduda, et süsteem võimaldaks haldada kõiki Eesti Statistika kodulehel olevaid klassifikaatoreid.

34. Äriarhitektuuri oluliseks osaks on sündmuste registrid, kus hoitakse seisundimuudatuste ajalugu. Sellisel registril on standardiseeritud struktuur. Töö ülesandeks on kõigepealt realiseerida konkreetse infosüsteemi näitel trigerid, mis registreerivad seisundimuudatuste ajalugu. Seejärel tuleb projekteerida ja realiseerida metaandmetega juhitav avatud lähtekoodiga sündmuste registrite vaatamise tarkvara. See eeldab sellise registri andmete kasutamise juhtude leidmist ja kirjeldamist. Metaandmetega juhitav tähendab, et tarkvara andmebaasis registreeritakse süsteemi poolt hallatavate sündmuste registrite tabelite skeemid ja nimed. Selle alusel leiab tarkvara juba süsteemikataloogist nende tabelite veerud. Selleks, et hakata tarkvara vahendusel kasutama uut sündmuste registrit poleks vaja teha muud, kui registreerida selle tabeli skeem ja nimi tarkvara andmebaasis. Tuleb otsida võimalusi muuta võimalikult palju selle süsteemi käitumisest ning väljanägemisest andmetega juhitavaks. Süsteem tuleb realiseerida PostgreSQL + PHP abil. Projekt peab olema GitHubis.

·         Üks selle tarkvara funktsionaalsus on sünduste registrist loetud andmete "elama" panek e animeerimine (vt näiteks omanduslikku programmi Disco). Andmebaas on realiseeritud PostgreSQLis ning tarkvara realiseerimiseks võib näiteks kasutada jQuery't. Andmete laadimiseks saab sellisel juhul kasutada jQuery.ajax päringut. Tuleb mõelda sellele, et tarkvara oleks võimalik palju häälestatav, st selle käitumist saab juhtparameetrite väärtuse abil muuta. Tarkvara peab olema üldlahendus, st tarkvarale saab ette öelda info kust seisundimuudatuste ajaloo infot võtta ning tarkvara oskab seda animeerida. Enne kui see teema valida tuleb uurida olemasolevaid protsesside kaevandamise ja animeerimise vahendeid ja veenduda, et juba ei ole sellise funktsionaalsusega avatud lähtekoodiga tarkvara. Selle uuringu tulemused oleksid ühtlasi töö üheks esimeseks osaks, mis pakub töö vajalikkuse põhjenduse ning nõudeid uuele tarkvarale. Projekt peab olema GitHubis.

35. Infosüsteemi projekti erinevad tulemid (mudelid, testid, kood) on omavahel seotud. Need tulemid kirjutab ette projekti käigus kasutatav metoodika. Iga tulemi alusel võidakse luua null või rohkem tulemit. Iga tulemi muutmisel tuleb nii sõltuvusahelas eespool kui ka tagapool olevad tulemid üle vaadata, et peale muudatust oleksid tulemid endiselt üksteisega kooskõlas. Igas projektis on oma tulemite hulk, mida soovitakse/kohustutakse looma (mõelge näiteks sellele, et igas infosüsteemide õppeaines oli projekti dokumendi struktuur ja projektilt oodatavad tulemused erinevad). Lõputöö ülesandel on kolm osa. Projekt peab olema GitHubis.

1.    Projekteerida ja realiseerida veebipõhine avatud lähtekoodiga tarkvara, mis võimaldab PostgreSQL andmebaasis registreerida erinevate projektide jaoks oodatavaid tulemite tüüpe ning nende vahelisi sõltuvusi. Realiseerida päringukeskkond, mis muuhulgas võimaldab valida tulemi tüübi X ning seejärel kõik sellega otseselt või kaudselt seotud tulemite tüübid, mida tuleb X tüüpi tulemi muutmisel üle vaadata ja võimalik et parandada. Sellise ülesande lahendamiseks PostgreSQLis tuleb kasutada rekursiivseid päringuid. Tulemi tüübiks ei ole antud juhul mitte konkreetne pakett, teek või tabel, vaid nende üldistus. Näiteks iga põhiobjekti kohta tekib äriarhitektuuris register, millele hiljem andmebaasis võib vastata eraldi skeem. Teine näide on, et iga tegutseja kohta tekib infosüsteemi äriarhitektuuris eraldi pädevusala allsüsteem, millele hiljem andmebaasis võib vastata eraldi roll. 

2.    See tarkvara tuleb võrdluse huvides realiseerida nii PostgreSQL andmebaasisüsteemi kui ka graafipõhise andmebaasisüsteemi Neo4j baasil. Töös tuleb kirjutada saadud kogemuste põhjal nende vahendite sobivusest antud ülesande lahendamiseks.

3.    Leida ja loodud tarkvara abil registreerida "Andmebaasid I"/"Andmebaasid II" projekti tulemite tüübid ja nende omavahelised seosed.

36. Projekteerida ja realiseerida põhimõet illustreeriv (proof of concept) prototüüp veebipõhisest diagrammi joonistamise vahendist, milles loodud diagrammid salvestatakse PostgreSQLi andmebaasi (nt JSONB tüüpi veergu). Diagrammide loomise keel ei pea olema keeruline - pakub huvi kas/kuidas sellist süsteemi saab luua. Kasutajaliidese loomiseks võib kaaluda JointJS kasutamist.

37. DeKlarit, mis sellest et praeguseks teise firmaga ühinenud, on näide kuidas kõrgtaseme kirjeldusest jõutakse teisenduste kaudu töötava tarkvarani. DeKlarit 4.3 tarkvara on endiselt võimalik alla laadida. Ülesandeks on selle vahendi baasil realiseerida andmebaas ja andmebaasirakendus ning kirjutada saadud kogemustest. Teoreetilise taustaga tutvumist alustage siit.

38. Realiseerida andmebaasirakendus kasutades Alphora Dataphor vahendit ning kirjutada kogemustest. Tegemist on süsteemiga, mis üritab võtta kasutusele relatsioonilise andmemudeli kogu tema võimsuses ja võimekuses. Kuna kunagi prooviti seda vahendit lõputöös kasutada kuid installeerimine ebaõnnestus, siis enne teema valikut tuleb see vahend oma arvutis tööle saada ning realiseerida mingi väga lihtne andmebaasirakendus.

39. Andmebaasirakenduse realiseerimine polyglot persistence põhimõttel, kasutades erinevaid SQL ja NoSQL süsteeme. Tööle annaks juurde see kui tegemist oleks "reaalse" süsteemiga, mida autor peab arendama oma töökohal või soovib arendada oma huvidest lähtuvalt. Andmebaasirakendus peab olema selline, et NoSQL süsteemi(de) kasutamisest võiks olla reaalselt kasu, mitte ei hakata näiteks kunstlikult kangutades hästi struktureeritud andmeid dokumendipõhisesse andmebaasi panema.

40. ORM (Object-Relational Mappers; objekt-relatsioonilise vastendamise) vahendid on populaarsed, kuid nende kasutamisest tulevad omad probleemid. Andl andmebaasikeel üritab ORM vahendite probleemi lahendada sellega, et nende vajadus ära kaotada, luues andmebaasikeele, milles on võimalik realiseerida äriloogikat ning millel on loomulikult juurdepääs ka relatsioonilistele andmetele. Sellisel juhul poleks vaja tõlkida objekte relatsioonilisteks andmeteks ja tagasi. See keel on arendusjärgus ja hetkel on arendus aktiivne. Ülesandeks on sellest keelest aru saada, see oma arvutis tööle saada, realiseerida selle põhjal andmebaas ja andmebaasi rakendus, sellest kõigest lõputöös kirjutada ning kui võimalik, siis anda ka tagasisidet keele arendajale. Töö on sobilik programmeerimishuvilistele üliõpilastele, kes tahavad oma maailmapilti avardada.

41. Töö, mille sisuks oleks tegeleda selliste teemadega nagu avaandmed, andmete integratsioon, andmete laadimine SQL-andmebaasi, võibolla ka innovatsioon kui nende andmete peale õnnestub midagi huvitavat ehitada. Töö praktilises osas tuleb valida Eesti avaandmete kataloogist vähemalt kaks andmehulka, mida oleks võimalik integreerida; kavandada ja realiseerida PostgreSQLi andmebaas selliste integreeritud andmete hoidmiseks; kavandada ja realiseerida andmete sellesse andmebaasi kandmine; kirjutada mingit uut ja huvitavat infot andvad päringud nendest andmetest info otsimiseks. Töö teoreetilises osas tuleb muuhulgas kirjeldada tööprotsessi ja põhjendada tehtud tehnilisi valikuid. Kui Eesti avaandmete kataloogist tõesti midagi sobivat ei leia, siis võib proovida USA avaandmete kataloogiga.

Andmebaasirakenduste disainilahenduste uurimine (Informaatika baka/magister, Äriinfotehnoloogia baka/magister)

42. Luua PostgreSQL andmebaas ja andmebaasirakendus, kasutades kaitsva programmeerimise stiili. Sõnastada reeglite kogumik, kuidas PostgreSQLis kaitsva programmeerimise stiili järgida. Eeskuju tuleks võtta sellest raamatust, mis kirjeldab andmebaaside kaitsvat programmeerimist MS SQL Serveri näitel.

43. Luua andmebaas ja andmebaasirakendus, järgides nende kavandamisel teadlikult normaliseeritud süsteemide teooria pakutavat nelja disainiteoreemi.Sõnastada kasutatud vahendite jaoks reeglid, kuidas nende abil (võimalikult kõrgelt) normaliseeritud süsteeme luua. Töö sobib magistritööks ning eeldab kasutatavate arendusvahendite väga head tundmist ning kogemust arendajana. Töö praktilises osas tuleb andmebaas ja andmebaasirakendus ka reaalselt valmis saada.

·         Sõnastada need reeglid PostgreSQL jaoks eeldusega, et PostgreSQLi kasutatakse paksu-andmebaasi (funktsioonid, vaated, trigerid, kitsendused) arhitektuuriga andmebaasirakenduse loomiseks. Realiseerida nendest põhimõtetest lähtuvalt PostgreSQL andmebaas ja seda kasutav andmebaasirakendus.

44. Mõne olemasoleva keeruka äriloogikaga programmi ümbertöötamine nii, et see jälgiks põhimõtet - minimeeri koodi, maksimeeri andmeid. Töö autor peab olema selle programmi autor või vähemasti osaline selle loomises. Programm võib pärineda autori töökohalt või olla autori poolt hobi korras loodud. Võib ka luua nullist seda põhimõtet järgiva programmi. Töö üheks osaks on kaardistada võimalused seda põhimõtet rakendada. Üheks selle põhimõtte ilminguks on otsustustabelid, mida programmid saavad lugeda. Lugege nende kohta ka siit. Vaadake ka seda ettekannet uudsest ärireeglite otsustustabelite kirjeldamise meetodist.

45. Aastal 1983 avaldati artikkel Error Messages: The Neglected Ared of the Man/Machine Interface. 2015. aasta kevadel tehti bakalaureusetöö, milles uuriti andmebaasisüsteemide väljastatavaid veateateid ning täheldati samasuguseid probleeme. Töö ülesandeks on realiseerida konkreetne PostgreSQL andmebaasil põhinev ja piisavalt keeruline andmebaasirakendus, milles on läbimõeldud ja heatasemeline veateadete esitamine. Tuleb läbi mõelda, kuidas seda tarkvara arhitektuuri seisukohalt teha, sh kuidas muuta lihtsaks veateadete tõlkimine. Tuleb läbi mõelda, millised oleksid head veateated. Tuleb läbi mõelda, kuidas vigu registreerida. Kõigest sellest tuleb töös kirjutada ning vastavas näitetarkvaras realiseerida.

46. Reaalse (autori töö juurest pärineva või hobi korras arendatava) rahvusvahelikustamist vajava tarkvara loomine või olemasoleva ümbertöötamine nii, et see toetaks rahvusvahelikustamist.Vallaste e-teatmiku kohaselt on "rahvusvahelikustamine tarkvaratoodete projekteerimine algusest peale selliselt, et neid oleks hõlbus kohandada eri keeltele ja piirkondadele ning et selleks poleks vajadust teha hiljem põhimõttelisi muudatusi".  Töö teoreetilises osas tuleb kirjutada tarkvarasüsteemide rahvusvahelikustamisest ja lokaliseerimisest, selle mõjust arendusprotsessile ning erinevatest sellega seotud disainilahendustest (sh andmebaasi tasemel). Osa disainilahendustest on üldised, osad seotud konkreetse keele või vahendiga. Kui ettevõttes on kasutusel arendusprotsess, siis tuleb uurida kas ja kuidas see käsitleb rahvusvahelikustamise ja lokaliseerimise küsimusi. Kui ei käsitle, siis tuleks pakkuda arendusprotsessi täiendusi. Töö praktilises osas tuleb süsteem kavandada ja realiseerida.

47. Uurida erinevaid lähenemisi andmebaasiserveris talletatud rutiinide loomisele.

·         Transactional API (optimistlik lähenemine ridade lukustamisele)

·         Transactional API (pessimistlik lähenemine ridade lukustamisele)

·         Table API (optimistlik lähenemine ridade lukustamisele)

·         Table API (pessimistlik lähenemine ridade lukustamisele)

·         API ja TAPI kombinatsioon (optimistlik lähenemine ridade lukustamisele)

·         API ja TAPI kombinatsioon (pessimistlik lähenemine ridade lukustamisele)

Lähtematerjali teema uurimiseks leiab siit. Kui neid uurite, siis näete, et eksperdid on eriarvamusel, milline oleks parim viis. Luua andmebaas. Luua andmebaasis kuus sama ülesande lahendamiseks mõeldud rutiinide komplekti. Luua kolm veebirakenduse versiooni, millest igaüks kasutab ühte komplekti optimistliku lähenemisega rutiinidest. Luua kolm kahekihilise klient-server süsteemi versiooni, millest igaüks kasutab ühte komplekti pessimistliku lähenemisega rutiinidest.Saadud kogemustest lähtuvalt panna kirja erinevad andmebaasi disainilahendused mustrite formaadis. Andmebaasisüsteemina tuleks kasutada PostgreSQLi. TAPI rutiine võib genereerida andmebaasi skeemi põhjal. Töö üheks osaks on leida tarkvara, mis sellega kõige paremini hakkama saab.

48. Uurida erinevaid lähenemisi, kuidas objektorienteeritud rakendus peaks kasutama SQL-andmebaasi.

·         Tabel-orienteeritud programmeerimine

·         Objekt-relatsioonvastendus

·         Andmebaasi kasutamine läbi virtuaalse andmete kihi (koos objekt-relatsioonvastendusega)

·         Andmebaasi kasutamine läbi virtuaalse andmete kihi (ilma objekt-relatsioonvastenduseta)

Töö praktilises osas tuleb realiseerida ühe ja sama andmebaasi põhjal sama ülesannete hulga lahendamiseks mõeldud andmebaasirakendused kasutades eelnevalt nimetatud viise. Saadud kogemused tuleb kirja panna mustrite formaadis.

49. PostgreSQL andmebaasisüsteemis on süsteemi-defineeritud JSON tüübid. See võimaldab arendajatel realiseerida andmebaase, mis meenutavad ülesehituselt pigem NoSQL andmebaase. Töö sisuks oleks andmebaasirakenduse projekteerimine ning realiseerimine kasutades nii "traditsioonilist" disaini kui ka "NoSQL stiilis" disaini. Töö oluliseks tulemuseks oleks nende disainilahenduste eeliste ja puuduste analüüsimine ning omavaheline võrdlemine. Saadud kogemustest lähtuvalt panna kirja erinevad andmebaasi disainilahendused mustrite formaadis.

50. Oracle kui objekt-relatsioonilise andmebaasisüsteemi uurimine. Kavandada ja realiseerida andmebaas järgnevatel viisidel.

·         Kasutada kasutaja-defineeritud struktureeritud tüüpe ja tüübikonstruktorite abil genereeritud tüüpe baastabelite veergude tüüpidena.

·         Luua kasutaja-defineeritud struktureeritud tüüpide alusel objektitabelid.

·         Luua "tavalised" baastabelid ning nende peale objektivaated.

Luua kõigi andmebaaside jaoks sama funktsionaalsusega rakendus. Võrrelda neid disaine omavahel erinevatest aspektidest lähtuvalt (keerukus, päringute jõudlus, muudatuste lihtsus, rakendusega sidumise lihtsus jne). Saadud kogemustest lähtuvalt panna kirja erinevad andmebaasi disainilahendused mustrite formaadis.

51. Uurida, kuidas andmebaasisüsteemis kasutatav transaktsioonide isolatsioonitase ning lukustamise mehhanism mõjutab andmebaasirakenduste kirjutamist. Töö praktilise osana tuleb realiseerida üks ja sama andmebaasirakendus järgnevate andmebaaside põhjal.

·         PostgreSQL andmebaas, kus transaktsioonidel on READ COMMITTED (vaikimisi) isolatsioonitase.

·         PostgreSQL andmebaas, kus transaktsioonidel on SERIALIZABLE isolatsioonitase.

·         MS SQL Serveri andmebaas, mille korral pole sisse lülitatud multiversioon konkurentsjuhtimine (MVCC) (PostgreSQL realiseerib MVCC-d)

Saadud kogemused ja erinevatest andmebaasi realisatsioonidest tulenevad erinevused programmikoodis tuleb kirja panna. See on tegelikult väga keeruline, kuid rakenduste korrektseks toimimiseks ülioluline teema. Kui lukustamisele tähelepanu ei pööra, siis juhtub näiteks nii. Enda teemaga kurssi viimist alustage sellest ja sellest artiklist. Seejärel vaadake ka seda.

52. Realiseerida kaks veebipõhist andmebaasirakendust. Võib kasutada "Andmebaasid II" projekti, kuid realiseerida tuleb kõik töökohad. Üks peab kasutama andmebaasipõhist turvalisuse tagamise mudelit, mille kohaselt vastab igale rakenduse kasutajale üks andmebaasi kasutaja (sarnast lahendust kasutatakse ka "Andmebaasid I"/"Andmebaasid II" õpingukavade näiteprojektis). Teine rakendus kasutab lahendust, mille kohaselt vastab rakendusele üks andmebaasi kasutaja. Töö üheks põhitulemuseks oleks nende lahenduste omavaheline võrdlemine erinevates aspektides ning eeliste ja puuduste väljatoomine. Nendest lähenemistest on juttu ka selles Oracle teemalises arutelus. Andmebaasisüsteemiks peab olema PostgreSQL. Andmebaasipõhise turvalisuse tagamise meetodi korral tuleb jõuda üldlahenduseni, mida saab kasutada ka teistes programmides ning vastav kood avatud lähtekoodina avaldada. Projekt peab olema GitHubis.

53. Järgnev töö sobib Ruby programmeerimisoskuse ning huviga üliõpilasele. Projekt Alf pakub uudse viisi rakenduse ja andmebaasi sidumiseks. Selle kohaselt võidaks rakendus sellest, kui andmete poole pöördumiseks ei kasutataks SQLi, vaid relatsioonialgebrast kannustatud ning seda täpselt jälgivat keelt. Finitio on andmete keel. Mõte on selles, et rakenduse tasemel on võimalik eraldi keelt kasutades ära kirjeldada rakendusse sisendina antavad andmed ja nende kitsendused. Rakendus saaks kasutada seda kirjeldust andmete kontrollimiseks. Ülesandeks oleks realiseerida sama andmebaasirakendus Ruby kahel viisil. Üks "nagu tavaliselt" PostgreSQL andmebaasi põhjal ning teine kasutades nimetatud uudseid vahendeid. Seejärel on vaja saadud oskused ning kogemused kirja panna ning erinevaid rakenduse loomise lähenemisi omavahel võrrelda.

54. PostgreSQL võimaldab väliste andmete pakendajate ning väliste tabelite mehhanismi abil realiseerida föderatiivse süsteemi, milles osalevad komponent-andmebaasisüsteemid on autonoomsed ja võimalik, et heterogeensed. See võimaldab integreerida tarkvarasüsteeme, mis kasutavad erinevate vahendite abil loodud andmebaase. Luua samas andmebaasirakendusest kaks versiooni. Üks nendest suhtleb otse erinevate andmebaasisüsteemidega. Teine kasutab ainult PostgreSQL andmebaasi, mis omakorda integreerib andmeid erinevatest allikatest. Võrrelge kahe rakenduse poolt tehtavate päringute jõudlust. Võrrelge erinevaid disainilahendusi. Oleks hea kui tegemist oleks reaalse süsteemiga (autori töö juurest pärit või hobi korras arendatav), mitte väljamõeldud näitesüsteemiga.

55. Projekteerida ja realiseerida loogiline andmeait ning seda kasutav päringurakendus, kasutades PostgreSQLi väliste andmete pakendajate ja väliste tabelite mehhanismi. Andmeait peab siduma vähemalt kaks andmebaasi, milles olevad andmed võivad ka osaliselt kattuda. Kattuvas osas võib skeemi ülesehituses (tabelite struktuur, andmetüübid, tabelite ja veergude nimed) olla erinevusi. Allikateks olevates andmebaasides luuakse komplekt vaateid. Need vaated lingitakse väliste tabelitena loogilist andmeaita realiseerivasse PostgreSQLi andmebaasi. Selles andmebaasis on ka metaandmed, mis kirjeldavad globaalse skeemi ning selle vastavuse lokaalse te skeemide vaadete ja veergudega. Loogilise andmeaida andmebaasi peale tuleb luua päringurakendus, mis võimaldab globaalse skeemi kirjeldust kasutades päringuid koostada. Need päringud tõlgitakse SELECT lauseteks, mis täidetakse väliste tabelite põhjal. Nende tulemustest pannaks e kokku kasutajale mõeldud vastus. Tuleb uurida päringute töökiirust erinevate andmehulkade korral. Töö üheks tulemuseks oleks loogilise andmeaida projekteerimise võimaliku protsessi (metoodika) kirjeldus. Metoodika kirjeldamiseks kasutage Eclipse Process Framework Project (EPF) vahendit.

56. Oracle andmebaasisüsteem pakub väga laias valikus võimalusi andmete turvalisuse tagamiseks. Ülesandeks on kõik need võimalused selgeks teha ja kategoriseerida ning seejärel kasutada võimalikult suurt hulka nendest konkreetse andmebaasi/rakenduse paari turvalisuse tõstmiseks. Üritada kõike seda sama realiseerida PostgreSQLi andmebaasi põhjal. Võrrelda saadud kogemuste alusel PostgreSQL ja Oracle andmebaasisüsteeme.

57. Ühe ja sama andmebaasi+rakenduse realiseerimine kasutades ühte SQL-andmebaasisüsteemi ja ühte mitte-SQL süsteemi (objektorienteeritud andmebaasisüsteem, XML andmebaasisüsteem, NoSQL süsteem). Peale selle, kui olete valinud mitte-SQL süsteemi kategooria, võib konkreetse süsteemi valimiseks võtta aluseks andmebaasisüsteemide populaarsuse indeksi. Töö tegemisel võib võtta aluseks oma "Andmebaasid II" projekti. Lisaks süsteemi projektile ning realisatsiooni kirjeldusele oleks lõputöö sisuks ka kasutatud SQL ja mitte-SQL süsteemi omavaheline võrdlemine saadud praktiliste kogemuste alusel.

 

Andmebaaside disainilahenduste uurimine (Äriinfotehnoloogia baka/magister, Informaatika baka/magister)

58. "Puhast koodi" (clean code) on lust lugeda ja lihtne edasi arendada. Nagu näitas bakalaureusetöö ning selle tulemusel valminud kataloog, on peaaegu kõik puhta koodi raamatus kirjeldatud halvad lõhnad leitavad ka süsteemianalüüsi mudelites, sest nii koodis kui analüüsimudelites võivad esineda ühised juurprobleemid. Andmebaasi arendamine on programmeerimine. Halva lõhna ja puhta koodi mõiste on ühtemoodi oluline nii rakenduse kui andmebaasi arendamisel. Ülesandeks on viia läbi eelmainitud bakalaureusetööga sarnane uurimus teemal, millised puhta koodi raamatus esinevad halvad lõhnad saavad esineda ka SQL­-andmebaasi disainis.

59. Bakalaureusetöös "Andmebaasis kirjutamise skeemi ja JSON dokumentide kasutamise mõju PostgreSQL ja MongoDB andmebaasirakenduste loomisele" uuriti kokku viite andmebaasi disaini PostgreSQL (kolm disaini) ja MongoDB (kaks disaini) andmebaasisüsteemide jaoks. Nendest neljas salvestati andmed JSON dokumentidena. Ülesandeks on selles töös loodud andmebaaside põhjal viia läbi põhjalik andmekäitluse operatsioonide töökiiruse uuring. Selleks tuleb genereerida erinevates kogustes testandmeid ja testida nii andmeuuenduste kui andmete otsingute operatsioonide töökiirust. Võimalik, et JSON formaadis andmete genereerimiseks peab looma eraldi utiliidi.

60. Paljusid andmeid saab esitada graafidena. Graafipõhised andmebaasisüsteemid on üks andmebaasisüsteemide klass, mis kuulub NoSQL vihmavarju alla. Samal ajal on ka SQL-andmebaasisüsteemidesse lisandumas graafiandmete haldamise võimekusi. Töö eesmärgiks on võrrelda mõningaid süsteeme andmebaasi kirjutamise skeemi (skeem defineeritakse andmebaasisüsteemis ja andmebaasisüsteemi ülesanne on kontrollida registreeritavate andmete skeemile vastavust) jõustamise võimaluste, andmekäitluse operatsioonide algatamiseks vajalike lausete keerukuse ja nende operatsioonide töökiiruse seisukohast. Võrreldavaid süsteeme on erinevaid ja iga pakutava hulga kohta saaks teha eraldi lõputöö.

·         Valik 1 – erinevad PostgreSQL-põhised lahendused.

·         AgensGraph - PostgreSQL hargmik, mis on mitmemudeliline andmebaasisüsteem, kus saab kasutada nii andmete esitust graafina kui ka "traditsiooniliste" SQL tabelitena.

·         PostgreSQL koos Apache AGE laiendusega.

·         Puhas PostgreSQL, kus graafiandmete esitamiseks ja töötlemiseks kasutatakse senise SQLi võimalusi (enne, kui SQL lisandub graafiandmete töötlemise võimekus). Tuleb valida üks või mitu disaini sellest allikast.

·         Valik 2 – erinevad Microsofti lahendused.

·         Microsoft Azure Cosmos DB – pilvepõhine NoSQL andmebaasisüsteem.

·         MS SQL Serveri andmebaas, kus kasutatakse suhteliselt hiljuti lisandunud graafiandmete töötlemise võimekust.

·         MS SQL Serveri andmebaas, kus graafiandmete esitamiseks ja töötlemiseks kasutatakse "traditsioonilise" SQLi võimalusi. Tuleb valida üks või mitu disaini sellest allikast.

·         Valik 3 –TypeDB vs. Neo4j, MySQL ja PostgreSQL.

·         TypeDB - teadmiste esitamise ja tuletamise süsteem, milles andmeid esitatakse graafidena, kuid maailma kirjeldatakse tüüpide kaudu ja jõustatakse andmebaasis tüüpidega seotud reegleid.

·         Neo4j - populaarseim graafipõhine andmebaasisüsteem.

·         Puhas MySQL ja PostgreSQL, kus graafiandmete esitamiseks ja töötlemiseks kasutatakse senise SQLi võimalusi (enne, kui SQL lisandub graafiandmete töötlemise võimekus). Tuleb valida üks või mitu disaini sellest allikast.

·         Variant 4 – neli hetkel kõige populaarsemat mitte-pilvepõhist graafiandmete andmebaasisüsteemi.

61. Ajaandmete üks võimalik käsitlus PostgreSQL objekt-relatsioonilise andmebaasisüsteemi näitel. Raamatus: Date C.J., Darwen, H., Lorentzos, N., 2002. Temporal Data & the Relational Model. Morgan Kaufmann. pakutakse välja terviklik käsitlus, kuidas saab hoida relatsioonilises andmebaasis ajaga seotud andmeid (andmete ajalugu). Töö ülesandeks oleks uurida, kas ja kui suures ulatuses õnnestuks sarnaseid põhimõtteid rakendada PostgreSQL abil loodud objekt-relatsioonilises SQL-andmebaasis (lühiülevaade ajaandmete haldamise toest PostgreSQLis). PostgreSQL pakub häid laiendusvõimalusi, seega võib seal olla võimalik vajalikud operaatorid ja funktsioonid realiseerida. 2015. aasta kevadel kaitsti heatasemeline magistritöö, milles alustati vastava PostgreSQL laienduse projekteerimist/realiseerimist ning tulemused tehti avalikuks. Töö sisuks on arenduse jätkamine poolelijäänud kohast, olemasoleva koodi optimeerimine jõudluse seisukohast, võrreldes eelmise tööga mahukamad jõudluse uuringud ning laienduse kasutamine konkreetse ülesande lahendamiseks. Samuti peab uus töö võrdlema loodud lahendust detailselt olemasolevate disainilahendusega – näiteks ajaloo tabelid, tugi ajaandmete registreerimisele SQL:2011 standardis, IBM DB2 andmebaasisüsteemis (viimase kohta on infot ka siin) Teradata andmebaasisüsteemis ja MS SQL Serveri andmebaasisüsteemis. Samuti võimaldab ridade vanu versioone säilitada Oracle. Siin on ülevaade ajaandmete hoidmisest andmebaasides minevikus ja tänapäeval ning erinevate andmemudelite korral.

62. C.J. Date väidab raamatus What Not How: The Business Rules Approach to Application Development 1st Edition, et kõiki ärireegleid saab realiseerida andmebaasi kitsendustena. Töö ülesandeks on seda väidet kas kinnitada või ümber lükata, kasutades ärireeglite sellisel viisil realiseerimiseks tõeliselt relatsioonilist andmebaasisüsteemi Rel. Selles artiklis on esitatud ärireeglite võimalik ning uuringu kohaselt ammendav liigitus, koos viidetega allikatele, milles on erinevat tüüpi reeglitest juttu. Ülesandeks on koostada võimalikult ammendav nimekiri erinevat tüüpi ärireeglitest ning iga selles nimekirjas oleva reegli tüübi korral üritada see realiseerida konkreetse näite põhjal Relis. Seal on vaja andmebaasis luua relatsioonilisi muutujaid ning nende väärtuseid piiravaid kitsendusi. Võrdluse huvides tuleb samasugused kitsendused realiseerida PostgreSQL andmebaasis.

63. 2001. aastal avaldas Michael Blaha kaks artiklit (ühe leiab siit), milles analüüsis 35 SQL-andmebaasi pöördprojekteerimise tulemusi selles osas, kui palju ja milliseid disaini vigu on nendes tehtud. Peale seda pole analoogilisi põhjalikke uuringuid tehtud või pole vähemalt nende tulemusi laialt publitseeritud. Samas on disainiprobleeme aina paremini süstematiseeritud ja dokumenteeritud. Töö ülesandeks oleks laias plaanis Blaha uuringut korrata, kuid teha seda uuemate/praegu aktuaalsete andmebaasidega. Kuna töö tulemused ei tohi jääda saladuseks, siis ei sobi see, et hakkate oma töökoha andmebaaside disainiprobleeme lahkama. Tuleb valida andmebaasid, mille disainile on huvilistel vaba ligipääs. Sellisteks sobivad näiteks avatud-lähtekoodiga ERP süsteemid (nt Odoo). Sellel teemal tehti 2015. aasta kevadel heatasemeline bakalaureusetöö kahe andmebaasi põhjal, mis näitas uuritud andmebaaside tõsiste probleemide olemasolu ning vajadust teha oluliselt põhjalikum töö. Probleemidele olemasolevates andmebaasides (nimetamisega seoses) osutas ka selle lõputöö kolmas peatükk. Kui andmebaasid on realiseeritud PostgreSQLis või Oracles, siis saab nende disainide hindamise automatiseerimiseks kasutada "Andmebaasid II" tutvustatud kontrollpäringuid. Uus töö (parem oleks kui magistritöö) peab eelmist edasi arendama järgmistes aspektides.

1.    Andmebaaside disaini uurimise protsessi kirjeldamine.

2.    Võimalikult suur hulk disainiprobleeme.

3.    Oluliselt rohkem andmebaase.

4.    Suurem tähelepanu tabelite normaliseerituse astmele ning andmete liiasusele, mis ei tulene madalast normaliseerituse astmest.

5.    Põhjalikum töö teaduskirjandusega.

6.    Ühe (või mingi osa ühest) uuritava andmebaasi ümberdisainimine. Kuna koos andmebaasi muutmisega oleks vaja muuta ka rakendust, siis peaks üritama ka hinnata rakenduste muutmiseks vajaliku töö hulka. Kuna töö põhineks avatud lähtekoodiga tarkvaral, siis oleks see võimalik.

64. Kasutada konkreetse andmebaasi disainimiseks (tänapäeval väga harva kasutatavat) lähenemist, mille kohasel leitakse kõigepealt kõikvõimalikud atribuudid, millele vastavaid väärtuseid soovitakse andmebaasis talletada ning hakatakse neid atribuute relvaride vahel jagama. Viia normaliseerimine läbi kasutades kolme meetodit:
a) "Tavaline" meetod, mida kirjeldab "Andmebaasid I" teema 9 ning mis algab universaalse relatsiooni loomisega ning jätkub selle atribuutide sõltuvuste lahkamisega ning nende alusel relatsioonide dekomponeerimisega.
b) Lihtsustatud "tavaline" meetod, mis põhineb funktsionaalsete sõltuvuste diagrammide loomisel.
c) Kokaraamatu meetod. Kogu protsess ja selle käigus tehtud valikud tuleb kirjeldada ning valikuid põhjendada. Paralleelselt tuleb üritada seda sama andmebaasi kavandada mudelipõhist (kontseptuaalne andmemudel => füüsilise disaini andmemudel => kood) lähenemist kasutades ning neid nelja lähenemist ja nende tulemusi omavahel võrrelda. Enne kui teema valite lugege palun läbi artikkel.Why normalization failed to become the ultimate guide for database designers?.

65. Töö vaadete ja hetktõmmiste projekteerimise ja realiseerimise kohta. Töö esimeses pooles tuleb arendada teooriat, kuidas vaadete/hetktõmmiste vajadus süsteemianalüüsi tulemuste põhjal tuvastada ning kuidas neid disaini käigus kirjeldada. Millal luua vaade ja millal hetktõmmis? Kuidas seda otsustada? Metoodika kirjeldamiseks kasutage Eclipse Process Framework Project (EPF) vahendit. Töö teises pooles tuleb kirjeldatud metoodikat kasutades mingi konkreetse süsteemi jaoks vaated/hetktõmmised projekteerida ning realiseerida. Oleks hea, kui üliõpilasel oleks töökohal tarkvara (andmebaas + rakendus), mille puhul ta võiks seda teha. Alternatiiv on kasutada avatud lähtekoodiga tarkvara ja mingi osa sellest ümber teha. Rõhutan, et lisaks vaadete loomisele peab muutma ka rakendust, et need hakkaksid vaadetele viitama. Vaadete teemaga enda kurssi viimiseks tuleb kindlasti lugeda seda raamatut.

66. Uurida võimalusi, kuidas SQL-andmebaasis jõustatavaid kitsendusi (peavad olema kogu aeg täidetud) ja uute andmete kontrolle(uued andmed peavad kontrollile vastama, juba registreeritud andmed ei pea) saaks muuta andmetega juhitavaks. See tähendab, et kitsenduse muutmiseks on vaja muuta andmeid tabelites ja seda saab teha dünaamiliselt, ilma lähtekoodi ümber kirjutamata. Töö praktilises osas tuleb realiseerida PostgreSQL andmebaas, kus neid võimalusi kasutatakse. Selles artiklis on esitatud ärireeglite võimalik ning uuringu kohaselt ammendav liigitus, koos viidetega allikatele, milles on erinevat tüüpi reeglitest juttu. Töös tuleb uurida kõigi nende võimalikku andmetega juhitavaks muutmist.

67. Uurida ja võrrelda erinevaid strateegiaid, kuidas Oracles indekseerida sektsioonideks jagatud tabeleid ( lokaalsed sektsioonideks jaotatud indeksid, globaalsed sektsioonideks jagatud indeksid, globaalsed sektsioonideks mittejagatud indeksid). Töö praktilises osas tuleb luua sama tabelite struktuuri põhjal erinevaid disainilahendusi, mis erinevad indeksite kasutamise osas. Kõigi disainide jaoks tuleb genereerida piisavalt suur hulk ühesuguseid testandmeid. Seejärel tuleb neid disaine võrrelda andmemahu, andmemuudatuste kiiruse, erinevate päringuoperatsioonide kiiruse ja indeksite haldamise operatsioonide kiiruse seisukohast.

 

Andmebaasi disainilahenduste mustrite formaadis kirjeldamine (Äriinfotehnoloogia baka/magister, Informaatika baka/magister)

68. Panna mustrite formaadis kirja võimalused, kuidas tulla SQL‑andmebaasides toime olemitüüpide muutuva ning varieeruva atribuutide hulgaga. Kõik lahendused tuleb realiseerida PostgreSQL andmebaasis. Lisaks disainiteadmiste läbitöötamisele ja struktuursele esitamisele, tuleb lahenduste võrdlemiseks koostada ka hulk päringuid ning hinnata nende keerukust. Mustrite abil kirjeldatavate lahenduste näited:

·         lisada olemasolevasse tabelisse üha uusi veerge,

·         "universaalse disaini" tabelid (variatsioonidega, et tabelid on kogu andmebaasi kohta või iga olemitüübi kohta eraldi),

·         alamtabelite loomine,

·         andmete hoidmine JSON või XML dokumentidena (variatsioonidega, et kõik andmed on dokumentides või ainult teatud osa andmetest on dokumentides),

·         kuuendal normaalkujul tabelid.

69. Panna mustrite formaadis kirja, kuida saab SQL-andmebaasis hoida põhiobjektide seisundimuudatuste ajalugu. Kavandada ja realiseerida funktsionaalne allsüsteem, mis haldab ühele põhiobjektile vastavaid andmeid kogu selle elutsükli vältel ning registreerib seisundimuudatuste ajaloo eraldi sündmuste registris. Andmebaas peab olema tehtud PostgreSQLis. Seejärel tuleb katsetada/uurida, kuidas sellist seisundimuudatuste ajalugu saab protsesside kaevandamiseks mõeldud vahendiga analüüsida. Kasutada tuleb mitut vahendit nagu näiteks omanduslik Disco ja avatud lähtekoodiga ProM Tools. Lisaks selliste andmete kogumise kasulikkuse hindamisele annab see võimaluse neid erinevaid programme omavahel võrrelda.

Andmebaaside evolutsioonilise arendamise meetodite ja vahendite tundmaõppimine ja kasutamine (Äriinfotehnoloogia baka/magister, Informaatika magister)

70. Järgneva töö eelduseks on autori juurdepääs mingi pikaajaliselt arendatud suletud lähtekoodiga tarkvara andmebaasi osa erinevatele versioonidele. Eesmärgiks on uurida, kas selle andmebaasi korral kehtivad samad seaduspärasused, mida tutvustatakse näiteks selles artiklis. Need seaduspärasused on leitud avatud lähtekoodiga tarkvara andmebaaside põhjal. Eeldusel, et räägitakse tarkvarast X ja ettevõttest Y, peavad tulemused olema avaldatavad ning kaitstavad avalikul kaitsmisel. Töö osaks on ka töötada välja ja publitseerida tarkvara, mis aitaks analüüsi automatiseerida.

71. Uurida, kuidas mõjutavad erinevad SQL-andmebaasi ülesehitamise viisid andmebaasi ja rakenduse üheskoos evolutsioneerimist. Töö eksperimentaalses osas on vaja realiseerida PostgreSQL‑andmebaas ja seda kasutav rakendus vähemalt kolmel viisil:

·         SQL-andmebaas koos virtuaalse andmete kihiga. Rakendus kasutab andmebaasi läbi virtuaalse andmete kihi.

·         SQL-andmebaas ilma virtuaalse andmete kihita. Rakendus pöördub otse baastabelite poole.

·         SQL‑andmebaas, kus andmed on JSON formaadis. Rakendus pöördub otse baastabelite poole.

Seejärel on vaja viia läbi hulk andmebaasi skeemimuudatusi ning nendest tulenevaid muudatusi rakenduse koodis. Osa muudatusi olgu seotud rakenduse funktsionaalsuse muutmisega, osa aga andmebaasi erinevat tüüpi refaktoreerimisega. Muudatuste hulga valikult tuleb arvestada selliste muudatuste tüüpilise sagedusega. Tausta uurimist tuleb alustada sellest artiklist, kus kirjutatakse rakenduse ja koodi üheskoos arendamisest: Qiu, D., Li, B., Su, Z. (2013). An empirical analysis of the co-evolution of schema and code in database applications. In Proceedings of the 2013 9th Joint Meeting on Foundations of Software Engineering, ACM,  pp. 125‑135.

72. Kasutada Hecataeus tarkvara konkreetse andmebaasi evolutsioneerimiseks. Eriti hea oleks, kui andmebaas, mille põhjal vahendit kasutada, oleks "reaalne" ja pärit üliõpilase töökohalt. Kui üliõpilasel pole "reaalset", töökohalt pärit andmebaasi, siis saab töö üles ehitada ka nii, et kõigepealt projekteeritakse ja realiseeritakse andmebaas ning rakendus (kasutades näiteks PostgreSQLi ja PHPd) ning seejärel seda evolutsioneeritakse. Lugege andmebaasi skeemi evolutsiooni kohta artiklit: Hartung, M., Terwilliger, J., Rahm, E. (2011). Recent Advances in Schema and Ontology Evolution. Data-Centric Systems and Applications, 2011, 149-190.

73. Kasutada Oracle andmebaasisüsteemi sisse ehitatud vahendeid konkreetse andmebaasi evolutsioneerimiseks. Eriti hea oleks, kui andmebaas, mille põhjal tööd teha, oleks "reaalne" ja pärit üliõpilase töökohalt. Kui üliõpilasel pole "reaalset", töökohalt pärit andmebaasi, siis saab töö üles ehitada ka nii, et kõigepealt projekteeritakse ja realiseeritakse andmebaas ning rakendus (kasutades Oraclet ja Oracle Application Expressi) ning seejärel seda evolutsioneeritakse. Lugege Oracle poolt pakutavate võimaluste kohta: Hartung, M., Terwilliger, J., Rahm, E. (2011). Recent Advances in Schema and Ontology Evolution. Data-Centric Systems and Applications, 2011, 149-190.

74. Artiklis Hartung, M., Terwilliger, J., Rahm, E. (2011). Recent Advances in Schema and Ontology Evolution. Data-Centric Systems and Applications, 2011, 149-190. antakse ülevaade Oracle, MS SQL Server ja IBM DB2 andmebaasisüsteemide pakutavatest andmebaasi evolutsiooni toetamise võimalustest. Töö esimeseks osaks oleks uurida, milliseid võimalusi pakub selles osas PostgreSQL. Töö teiseks osaks oleks mõne PostgreSQLi andmebaasi kasutava süsteemi evolutsioneerimine. Eriti hea oleks, kui andmebaas, mille põhjal tööd teha, oleks "reaalne" ja pärit üliõpilase töökohalt. Kui üliõpilasel pole "reaalset", töökohalt pärit andmebaasi, siis saab töö üles ehitada ka nii, et kõigepealt projekteeritakse ja realiseeritakse andmebaas ning rakendus (kasutades PostgreSQLi ja PHPd) ning seejärel seda evolutsioneeritakse.

75. Konkreetse ettevõtte andmebaasi refaktoreerimine võttes aluseks refaktoreerimiste kataloogi (teine variant kataloogist on siin). Töö esimeses pooles tuleb kirjeldada kasutatavat refaktoreerimise protsessi Eclipse Process Framework Project (EPF) vahendi abil. Tuleb leida võimalikult hea protsess ning kõiki protsessi samme ja nende järjekorda põhjendada. Töös tuleb kasutada mõnda andmebaaside refaktoreerimist toetavat vahendit (nagu näiteks LiquiBase) ning kui leiate selle kasutamise käigus vahendis probleeme (näiteks puuduv, kuid väga oluline funktsonaalsus), siis nendele tähelepanu juhtida. Töö lõpuosades tuleb hinnata kasutatud protsessi headust konkreetse ülesande lahendamise näitel ja vajadusel teha protsessis muudatusi.

76. Konkreetse ettevõtte andmebaasi ja seda kasutavate rakenduste migreerimine ühelt andmebaasisüsteemilt teisele. Töö esimeses pooles tuleb kirjeldada kasutatavat migreerimise protsessi Eclipse Process Framework Project (EPF) vahendi abil. Tuleb leida võimalikult hea protsess ning kõiki protsessi samme ja nende järjekorda põhjendada. Töö lõpuosades tuleb hinnata kasutatud protsessi headust konkreetse ülesande lahendamise näitel ja vajadusel teha protsessis muudatusi.

77. Andmesiirde läbiviimine konkreetse ettevõtte andmebaaside näitel. Töö esimeses pooles tuleb kirjeldada kasutatavat andmesiirde protsessi Eclipse Process Framework Project (EPF) vahendi abil. Tuleb leida võimalikult hea protsess ning kõiki protsessi samme ja nende järjekorda põhjendada. Töö lõpuosades tuleb hinnata kasutatud protsessi headust konkreetse ülesande lahendamise näitel ja vajadusel teha protsessis muudatusi.

78. Andmebaasi evitamise läbiviimine konkreetse ettevõtte andmebaasi näitel. Töö esimeses pooles tuleb kirjeldada kasutatavat evitamise protsessi Eclipse Process Framework Project (EPF) vahendi abil. Tuleb leida võimalikult hea protsess ning kõiki protsessi samme ja nende järjekorda põhjendada. Töö lõpuosades tuleb hinnata kasutatud protsessi headust konkreetse ülesande lahendamise näitel ja vajadusel teha protsessis muudatusi. Tuleb kasutada mõnda versioonikontrolli tarkvara. Tuleb kasutada Enterprise Architect 12 lisandunud võimalus andmebaasi skeemi ja mudeli sünkroniseerimise skripti genereerimiseks.

 

Keerukate süsteemide modelleerimine (Äriinfotehnoloogia baka/magister)

79. Keeruka infosüsteemi mitme allsüsteemi kavandamine, kasutades põhiolemitüüpide ja nende elutsüklite leidmisel põhinevat lähenemist, mille alusel saab leida infosüsteemis toimuvad protsessid ning olemitüüpide omavahelised mõjud. Andmevaate modelleerimiseks tuleb kasutada arhetüüpe. Sisuliselt on see andmebaaside ainetes pakutud registripõhiste infosüsteemide projekteerimise metoodika rakendamine reaalse infosüsteemi arendamiseks. Töö teemaks olev infosüsteem peab olema "reaalne süsteem", mille kavandamine kuulub autori töökohal tema tööülesannete hulka või olema äärmisel juhul seotud tema hobidega. Elutsüklite kirjelduste kasutamist on infosüsteemide kavandamisel soovitatud juba 1980ndatest aastatest ning see on viimasel ajal uuesti fookusesse tõusnud tänu artefaktipõhisele protsesside modelleerimisele. Töö teiseks eesmärgiks on projekteerimise protsessi kirjeldamine Eclipse Process Framework Project (EPF) vahendi abil.

80. Valida hulk arendusmetoodikaid. Lugeda nende kohta, praktiseerida neid. Koostada nende valdkonnamudelid e metamudelid (nii nagu on tehtud "Andmebaasid II" teemas 1 Scrumi ja ekstreemprogrammeerimise kohta). Võrrelda neid metoodikaid loodud metamudelite põhjal uurides näiteks, et kui metoodika X mudelis on klassi abil kirjeldatud mingi mõiste m, siis kas kas metoodikates Y ja Z on loogiliselt samaväärsed mõisted, või on mitu samaväärset mõistet, või pole ühtegi samaväärset mõistet.

81. Siin (lk. 3) ja siin (lk. 27-50) on esitatud SQL aluseks oleva andmemudeli ilmutatud ja visuaalne kirjeldus (klassidiagrammidena ja diagrammi elementide selgitustena). Tänapäeval on tekkinud suur hulk uusi andmebaasisüsteeme, mida tuntakse üldnimetaja NoSQL süsteemid all, kuid mis põhinevad tegelikult paljudel erinevatel andmemudelitel. Neist süsteemidest võib mõelda kui andmehoidlate loomise süsteemidest, kus andmed on esitatud näiteks kas dokumentidena (nt MongoDB), veerupõhiselt (nt Cassandra), graafidena (nt Neo4j) või võtme-väärtuse paaridena (nt Riak). Samas pole need andmemudelid nii täpselt kirjeldatud kui SQL aluseks olev andmemudel ja relatsiooniline andmemudel. Töö ülesandeks oleks koostada erinevate NoSQL süsteemide aluseks olevate andmemudelite kirjeldused (diagrammid + tekstikirjeldused) ning nende kirjelduste alusel võrrelda neid andmemudeleid SQL aluseks oleva andmemudeliga. Seda saab näiteks teha pannes erinevate andmemudeli kirjeldustes esitatud klassid. Tänapäeva NoSQL süsteemid kipuvad olema igaüks isemoodi ja seetõttu oleks mõistlik valida iga üldise andmemudeli (graafipõhine, võtme-väärtuse paarid, dokumendid veergude perekonnad) kohta üks andmebaasisüsteem, mille materjalide alusel vastavate andmemudelite kirjeldust luua.

82. Kolmanda Manifesti autorid on välja pakkunud andmetüüpide pärimise kaudu loomise mudeli. Selle kommenteeritud kirjeldust saab lugeda Kolmanda Manifesti raamatust. Ülesandeks on:

1.    luua selle mudeli kohta võimalikult täpne valdkonnamudel (klassidiagramm, mis kirjeldab mõisteid ja seoseid + klasside ja atribuutide sõnalised kirjeldused),

2.    võrrelda seda Javas või mõnes muus populaarses programmeerimiskeeles kasutatava pärimise mudeliga.

83. Põhiolemitüüpide läbipõimunud elutsüklite modelleerimise ja simuleerimise uurimine. Luua võimalikult realistlikud (st keerukad) olekumasinamudelid e-poe infosüsteemi põhiolemitüüpidele Klient, Toode, Tellimus, Tarnija, Arve. Võib ka valida mõne muu modelleeritava valdkonna, kuid keerukus peab olema sarnane. Uurida, kuidas oleks kõige parem mudelites väljendada seda, et nende elutsüklid on omavahel läbipõimunud, st mõjutavad üksteist (nt kui toode eemaldatakse müügilt tuleb tühistada kõik aktiivsed kliendi tellimused, mis ainult seda toodet tellisid; kui see toode oli vaid üheks osaks tellimusest, siis tuleb kliendile teha osaline tagasimakse kuid tellimuse täitmist jätkatakse). Realiseerida Enterprise Architect vahendis nende mudelite simulatsioon kombinatsioonina kasutajaliidese mudeliga. Juhend, kuidas seda teha on siin (osa 1) ja siin (osa 2). Vaadake ka seda.

 

Artefaktide mustripõhise võrdlemise teooria ja praktika edasiarendamine (Äriinfotehnoloogia baka/magister)

84. Süsteemiarenduse artefaktide mustripõhise võrdlemise metoodika on olemas, kuid vajaks detailsemat kirjapanemist. Metoodika põhineb Saaty hierarhilise analüüsi meetodit. Samuti on olemas magistritöö tulemusena loodud veebipõhine tarkvara metoodikal põhinevate võrdluste läbiviimiseks (see on loodud ühe magistritöö tulemusena). Metoodika on üldine. Artefaktideks võivad olla näiteks süsteemide või nende osade kirjeldused (mudelid) või valmis tarkvara. Ülesandeks on võrrelda mustripõhiselt artefakte, sellest protsessist õppida ning suunata õpitu tagasi metoodikasse.

 

Andmekäitluskeele lausete parema jõudluse saavutamise võimaluste otsimine (Äriinfotehnoloogia baka/magister)

85. Uurida lähemalt, mis on SQL andmekäitluskeele lauset andmebaasisüsteemi poolne semantiline teisendamine ning millised andmebaasisüsteemid ja kui palju seda kasutavad. Semantiline teisendamine tähendab andmebaasisüsteemi poolt lause lihtsustamist vastavalt andmebaasis deklareeritud kitsendustele. Andmebaasisüsteem saab eeldada andmete kooskõla kitsendustega. Sellise teisendamise üheks näiteks on mitmetes andmebaasisüsteemides (nt PostgreSQL 10, Oracle 12c, MS SQL Server, MariaDB) on võetud SQL andmekäitluskeele lausete töökiiruse parandamiseks kasutusele tabeli elimineerimise teisendus. Samas pole see kaugeltki ainuke võimalus semantilisteks teisendusteks (lugege palun "Andmebaasid II" teemat 7). Sellise teisendamise vajalikkusele osutab see lõputöö. Tööl on kaks poolt - teoreetiline ja praktiline. Teoreetilises osas tuleb kirjanduse põhjal uurida, mida on semantilise teisendamise osas teadusmaailmas/reaalsetes andmebaasisüsteemides ära tehtud. Tuleb kirja panna kõikvõimalikud semantilised teisendused (üldistatud kujul), mida suudate kirjandusest leida või ise välja pakkuda. Töö praktilises osas tuleb uurida konkreetsete andmebaasisüsteemide näitel (PostgreSQL, Oracle, ...), milliseid semantilisi teisendusi need reaalselt teha oskavad. Selleks tuleb kavandada andmebaas ning proovida läbi erinevad päringud, mille korral võiks andmebaasisüsteem semantilist teisendamist läbi viia.

86. Oletame, et tabelis T on veerg v. Veerule v on loodud B-puu indeks i. Päringu "SELECT * FROM T WHERE v LIKE '%string%'" korral ei kasuta andmebaasisüsteem indeksit i. Otsingus kasutatav string ei pruugi olla terve sõna, vaid võib olla sõna alamosa või ka kombinatsioon mitmest sõnast. Lõputöö ülesandeks oleks otsida erinevaid võimalusi, kuidas sellise päringu jõudlust parandada ning neid võimalusi omavahel võrrelda ja testida. Selle probleemi jaoks ei ole häid valmis lahendusi, kuid samas on tegemist praktikas küllaltki sageli lahendamist vajava küsimusega. Veeru täiendav indekseerimine võib liigselt kasvatada andmemahtu ning aeglustada andmemuudatusi. Võimalikud lahendused sõltuvad konkreetse andmebaasisüsteemi pakutavatest võimalustest. Töö üheks osaks võib olla erinevate andmebaasisüsteemide pakutavate võimaluste võrdlus. Töö osaks on piisavalt mahuka testandmebaasi loomine, mille põhjal erinevaid lahendusi testida. Testandmetena võib kasutada uurimisotstarbel kokku pandud andmehulki (ingl data sets). Sellele probleemile pakutavad lahendused võib töös kirja panna mustritena. Üks võimalik testandmetena kasutatav andmehulk on Reuters-21578. Selle (või mõne muu sarnase) andmehulga kasutamisel oleks üheks alamülesandeks andmehulgas olevate andmete andmebaasi laadimine ja vajadusel selleks mõne abiprogrammi loomine. Siin on üks artikkel LIKE kasutamise kohta.

87. Uurida ja võrrelda mingi praktilise näite baasil tekstiotsingu võimalusi PostgreSQL andmebaasis. Töö sisuks oleks piisavalt mahuka andmebaasi põhjal realiseerida erinevad tekstiotsingu võimalused ning "mugavate" ning "ebamugavate" päringutega koormamise järgselt analüüsida lahenduse efektiivsust päringute kiiruse/täitmisplaanide, indeksite mahu ning indeksite loomisele ja haldamisele kuluva ajakulu aspektides. Omavahel tuleb võrrelda PostgreSQLi sisseehitatud tekstiotsingu funktsionaalsust, lisamooduleid nagu Wildspeed, kolmanda osapoole poolt loodud otsimootori kasutamist (näiteks Sphinx Search) ning otsimootori käsitsi realiseerimist kasutaja-defineeritud funktsioonide ja trigerite abil ning võibolla veel mõne toreda süsteemi/mooduli abil, mida siinkohal ei nimetata (töö üks osa oleks selliseid süsteeme otsida). Viienda võimalusena tuleb proovida tekstiotsingut päringutes kasutatavate regulaaravaldiste abil, mis oodatavalt peaks olema kõige halvema töökiirusega lahendus. Töös kasutatav praktiline näide võib pärineda töökohast. Samas võib testandmetena kasutada ka uurimisotstarbel kokku pandud andmehulki (ingl data sets). Üks võimalik andmehulk on Reuters-21578. Selle (või mõne muu sarnase) andmehulga kasutamisel oleks üheks ülesandeks ka andmehulgas olevate andmete PostgreSQL andmebaasi laadimine ja vajadusel selleks mõne abiprogrammi loomine. Töökiirust tuleb uurida erinevate andmehulkade korral.  Siin on lõputöö isikunimede otsimise kohta PostgreSQL andmebaasides.

88. Andmekäitluskeele lausete ja andmebaasi disaini optimeerimine PostgreSQL või Oracle korral, eesmärgiga, et lauseid täidetaks kiiremini. Tarkvarasüsteem/laused, mida optimeerida, peavad olema realistlikud, st pärinema üliõpilase töökohalt või mõnest tema piisavalt keerukast individuaalsest arendusprojektist ja seal peavad olema ka tegelikult jõudluse probleemid. Töö teostamiseks tuleb kasutada konkreetse andmebaasisüsteemi pakutavaid töökiiruse jälgimise ja parandamise vahendeid. Töökiirust tuleb uurida erinevate andmehulkade korral. 

89. Uurida SQLi võtmeteta tabeleid, kus on korduvad read. C.J. Date on esitanud näite, kus on kaks võtmeteta tabelit ja nendes tabelites on korduvad read. Ta esitab ühe ülesande ja 12 erinevat SQL lauset, mis annavad korduvaid ridu arvestades üheksa erinevat tulemust. Ülesandeks on võrrelda neid 12 tabelit kahe disaini korral. Ühel juhul on tabelites võtmed deklareeritud ja tabelites pole korduvaid ridu. Teisel juhul ei ole tabelites võtmeid deklareeritud ja neis on korduvaid ridu. Tuleb genereerida testandmeid (sajad tuhanded või miljonid read) ja testida nende päringute töökiirust erinevate disainide ja andmehulkade korral. Tuleb uurida ja analüüsida päringute täitmisplaane. Tuleb võrrelda andmemahte. Töö teoreetilises osas tuleb lisaks kirjutada korduvate ridade muudest eelistest ja probleemidest. Töö tuleb teha vähemalt kahe andmebaasisüsteemi (PostgreSQL ja Oracle) põhjal.

90. Ühe ja sama andmebaasi realiseerimine kasutades PostgreSQLi ja vähemalt kolme mitte-SQL süsteemi (objektorienteeritud andmebaasisüsteem, XML andmebaasisüsteem, NoSQL süsteem)(peavad kuuluma erinevatesse kategooriatesse), neisse ühesuguste andmete lisamine, nende andmebaaside põhjal ühesuguste (lihtsamate ja keerukamate) päringu kirjutamise ülesannete lahendamine ning tulemusena nende andmebaasisüsteemide päringukeelte ja andmemudelite võrdlemine. Mitte-SQL süsteemide valimiseks võib võtta aluseks andmebaasisüsteemide populaarsuse indeksi.

91. Erinevatel andmemudelitel põhinevate andmebaasisüsteemide uurimine vaadete loomise seisukohast. Töö esimeses osas tuleb teoreetiliste materjalide põhjal kirjutada vaadete eelistest ja puudustest (hea raamat selle kohta; magistritöö, mis osutab probleemidele). Töö teises osas on vaja kirjanduse põhjal uurida, mida ütlevad erinevad andmemudelid vaadete kohta. Töö kolmandas osas tuleb kirjanduse põhjal uurida, mida võimaldavad vaadetega seoses teha konkreetsed andmebaasisüsteemid. Töö neljandas osas tuleb valida uuritud andmebaasisüsteemidest mõned, mis reaalselt installeerida ning milles igaühes realiseerida ühesugune andmebaas koos vaadetega. Töö peab andma "laia vaate" vaadete loomise võimalustele ja probleemidele erinevates andmemudelites ja andmebaasisüsteemides.

92. Andmebaasis jõustatud kitsendused võimaldavad päringute kirjutajatel aga ka andmebaasisüsteemil päringuid lihtsustada. Erinevatel andmemudelitel põhinevate andmebaasisüsteemide uurimine kitsenduste jõustamise seisukohast. Töö esimeses osas tuleb teoreetiliste materjalide põhjal kirjutada kitsenduste andmebaasis jõustamise eelistest ja puudustest. Töö teises osas on vaja kirjanduse põhjal uurida, mida ütlevad erinevad andmemudelid kitsenduste kohta. Töö kolmandas osas tuleb kirjanduse põhjal uurida, milliseid kitsendusi ja millisel viisil võimaldavad jõustada konkreetsed andmebaasisüsteemid. Töö neljandas osas tuleb valida uuritud andmebaasisüsteemidest mõned, mis reaalselt installeerida ning milles igaühes realiseerida ühesugune andmebaas koos andmebaasi tasemel jõustatud kitsendustega. Töö peab andma "laia vaate" kitsenduste loomise võimalustele ja probleemidele erinevates andmemudelites ja andmebaasisüsteemides.

Tagasi kodulehele