Lõputööde teemad

Sissejuhatus ja nõuded

Alljärgnev nimekiri sisaldab teemasid, mis on sobilikud Informaatika ja Äriinfotehnoloogia õppekavade üliõpilastele.

1. Ankurmodelleerimise (Anchor Modeling, AM) rakendused ja tööriistad

Uurimisvaldkond keskendub 6NF-põhise ankurmodelleerimise metoodika rakendatavusele operatiivsüsteemides ja selle toe automatiseerimisele.

  1. Ankurmodelleerimise sobivus ja jõudlus tehingutöötluse (OLTP) süsteemides Baka Magister
    Töö eesmärgiks on empiiriliselt analüüsida AM metoodika sobivust OLTP süsteemidele, kus on kriitiline andmete terviklikkus ja kirjutamiskiirus.
    • Disainida ja realiseerida võrdlevad prototüübid: üks traditsioonilises 3NK/5NK mudelis ja teine AM (6NK) põhimõttel (alus: "Andmebaasid I" projekt). Andmebaas tuleb teha PostgreSQLis.
    • Uurida skeemi evolutsiooni (nt atribuutide lisamine, ajaloolisuse muutmine) mõju rakenduse koodile mõlemas mudelis.
    • Analüüsida ja realiseerida deklaratiivsete kitsenduste ja trigerite süsteem PostgreSQLis AM mudeli jaoks, tuginedes AM kitsenduste juhendile. Mõõta kitsenduste jõustamise keerukust ja jõudluskulu võrreldes tavalise disainiga.
  2. Automatiseeritud migratsioonimetoodika ja -tarkvara (SQL -> AM) Magister
    Luua metoodika ja tarkvara olemasoleva pärandsüsteemi (legacy) SQL-andmebaasi teisendamiseks AM-andmebaasiks.
    • Kirjeldada formaalne metoodika 3NK/5NK skeemi teisendamiseks 6NK tabelitega ankurmudeliks.
    • Arendada tarkvara (või laiendada olemasolevat), mis automatiseerib andmebaasi struktuuri ja andmete migratsiooni PostgreSQLi korral.
    • Valideerida lahendust reaalse, keeruka struktuuriga andmebaasi peal. Töö peab analüüsima genereeritud skeemi kvaliteeti ja päringute keerukuse muutust.

3. Arendusvahendid ja platvormid

Uute tööriistade loomine või olemasolevate (avatud lähtekoodiga) vahendite edasiarendamine, mis lihtsustavad süsteemiarenduse erinevaid aspekte.

  1. Madalkoodi (Low-Code) platvormi pgApex arhitektuur ja kasutatavus Baka Magister
    Jätkata PostgreSQL-põhise arenduskeskkonna pgApex (MIT litsents, GitHub) arendamist.
    • Teostada võrdlev analüüs Oracle APEXi ja CYPEX-iga.
    • Koostada koostöös juhendajaga väljalaske plaan puuduva funktsionaalsuse (nt rakenduse varundamine/taastamine, mugavam kasutajaliidese loomine) lisamiseks ja viia see plaan ellu.
  2. Andmete dünaamilise maskimise jõudlus ja turvalisus PostgreSQLis Magister
    Arendada edasi PostgreSQLi andmete maskimise laiendust.
    • Lahendada magistritöös tuvastatud piirangud (nt ühilduvus teiste laiendustega, keerukad päringud).
    • Optimeerida C-keelse laienduse jõudlust ja mõõta "overhead'i" suure koormuse all.
    • Analüüsida võimalikke infolekkeid (nt side-channel attacks) maskitud andmete pealt ja luua vastumeetmed.
  3. Tarkvara sõltuvuste analüüs: Staatiline analüüs vs. suur keelemudel Magister
    Projekteerida ja realiseerida süsteem (sarnane projektile Hecataeus), mis kaardistab tarkvaraelementide (andmebaasiobjektide ja rakenduse koodi elementide) vahelisi sõltuvusi.
    • Võrrelda kahte lähenemist sõltuvuste tuvastamisel: klassikaline staatiline koodianalüüs (parserid) vs. suurte keelemudelite (LLM) kasutamine.
    • Realiseerida mõjuanalüüsi (Impact Analysis) päringud kasutades rekursiivset SQL-i või graafibaasi (Neo4j).
    • Hinnata lahenduse täpsust (Recall/Precision) erinevate avatud lähtekoodiga projektide peal.
  4. Denormaliseerimise otsustustoe süsteem ja täideviija Magister
    Luua tööriist, mis aitab andmebaasi administraatoril otsustada, millal ja mida denormaliseerida.
    • Implementeerida algoritm "Denormalization Survival Guide" (vt "Andmebaasid I").
    • Luua veebipõhine liides, mis analüüsib andmebaasi statistikat ja pakub soovitusi (nõustamissüsteem).
    • Automatiseerida denormaliseeritud struktuuride (tabelid, trigerid sünkroniseerimiseks) loomine PostgreSQLis.
    • Eelnev töö on olemas, kuid vajab edasiarendust terviklikuks lahenduseks.
  5. PostgreSQL füüsilise disaini nõustaja (Tuning Advisor) Magister
    Arendada tarkvara, mis analüüsib töökoormust (workload) ja soovitab indekseid või seadistusi.
    • Võrrelda olemasolevaid vahendeid (pgtune) kommertstoodetega (Oracle SQL Access Advisor, MS SQL Tuning Advisor).
    • Implementeerida heuristiline algoritm puuduvate indeksite tuvastamiseks PostgreSQLi päringute logide põhjal.
  6. Täiustatud koodigeneratsioon mudelist: Trigerid, olekumasinad ja domeenid Baka Magister
    Enterprise Architecti (EA) modelleerimisvahendi standardne andmekirjelduskeele koodi genereerimine on piiratud. Töö eesmärk on luua UML profiil ja koodigeneraator (EA Add-in või skriptid), mis võimaldab:
    • Modelleerida trigerite loogikat käitumisdiagrammidega (nt tegevusdiagramm või jadadiagramm) ja genereerida sellest PostgreSQL PL/pgSQL koodi.
    • Genereerida olekumasina (State Machine) diagrammist PostgreSQLi trigerid, mis jõustavad olekute vahetumise reeglid (vt "Andmebaasid I" mustrit).
    • Modelleerida ja genereerida SQL domeene ja liittüüpe.
    • Töö tulemust tuleb valideerida testrakenduse loomisega.

4. Andmebaasirakenduste arhitektuur ja keerukad süsteemid

Keskendutakse keerukate äriliste probleemide lahendamisele läbi nutika andmebaasidisaini ja arhitektuuri.

  1. Klassifikaatorite ja metaandmete haldussüsteem (Master Data Management) Baka
    Luua avatud lähtekoodiga süsteem hierarhiliste klassifikaatorite (Reference Data) haldamiseks.
    • Analüüsida olemasolevaid RDM lahendusi ja disainida metaandmetega juhitav skeem (vt viidet).
    • Realiseerida süsteem (PostgreSQL + PHP), mis suudab hallata Eesti Statistikaameti keerukusega klassifikaatoreid.
    • Tagada mitmekeelsuse tugi ja rakendusliidesed teistele süsteemidele.
  2. Üldine sündmuste register ja protsessikaeve (Process Mining) tugi Magister
    Arendada universaalne moodul süsteemi olekumuudatuste auditeerimiseks ja visualiseerimiseks.
    • Disainida PostgreSQLis optimeeritud sündmuste logi (Event Log) arhitektuur.
    • Luua rakendus, mis võimaldab andmeid "elama panna" (animatsioon) sarnaselt Disco tarkvarale.
    • Uurida protsessikaeve standardeid ja tagada andmete eksporditavus (XES formaat) analüüsivahenditesse.
  3. Polüglott-salvestus (Polyglot Persistence): Jõudlus ja kooskõla Magister
    Uurida polüglott-salvestuse (SQL + NoSQL ühes süsteemis) arhitektuurseid mustreid.
    • Realiseerida reaalne rakendus, kus on põhjendatud nii SQL-andmebaasi (PostgreSQL) kui ka mõne NoSQL (nt graaf, dokument) baasi kasutamine.
    • Mõõta andmete sünkroniseerimise latentsust ja süsteemi üldist keerukust võrreldes monoliitse lahendusega.
  4. Avaandmete integratsioon ja analüütiline andmeladu Baka
    Luua automatiseeritud ETL toru ja andmeladu Eesti avaandmete põhjal.
    • Integreerida vähemalt kolm erinevat andmestikku (nt kinnisvara + transport + koolid), lahendades andmekvaliteedi ja semantilised probleemid.
    • Kasutada PostGIS laiendust ruumiliste päringute tegemiseks.
    • Luua analüütiline töölaud (Dashboard), mis demonstreerib andmete ristkasutusest tekkivat lisaväärtust.

5. Rakenduste disainimustrid ja turvalisus

Erinevate arhitektuursete lähenemiste võrdlev analüüs ja parimate praktikate (mustrite) väljatöötamine.

  1. Töökindla andmebaasidisaini mustrid (Robust Database Design) Baka
    Koostada kataloog ja realiseerida näiterakendus, mis demonstreerib "kaitsva programmeerimise" võtteid andmebaasis.
  2. Andmepöörduskihi arhitektuurid: API vs. TAPI vs. ORM Magister
    Võrdlev uuring äriloogika paigutamise strateegiatest.
    • Realiseerida sama funktsionaalsus kolmel viisil: a) Transactional API (TAPI) andmebaasis, b) Table API, c) Puhas ORM rakenduskihis.
    • Analüüsida iga lähenemise mõju lukustamisele (optimistlik vs pessimistlik), jõudlusele ja koodi hooldatavusele.
  3. Hübriidsed andmemudelid: JSON PostgreSQLis vs. Relatsiooniline mudel Baka
    Analüüsida PostgreSQLi JSONB võimekust.
    • Luua rakendus, mis kasutab "NoSQL stiilis" disaini PostgreSQLis (andmed JSONB tüüpi veergudes) ja võrrelda seda klassikalise normaliseeritud disainiga.
    • Hinnata arenduskiirust, päringute keerukust ja jõudlust (indekseerimine). Sõnastada reeglid, millal eelistada JSONB-d.
  4. Turvalisus: Andmebaasipõhine (RLS) vs Rakendusepõhine mudel Magister
    Uurida PostgreSQLi Row Level Security (RLS) mehhanismi.
    • Realiseerida andmebaasipõhine turvamudel (üks andmebaasi kasutaja per rakenduse kasutaja ja RLS poliitikad) ja võrrelda seda klassikalise rakendusepõhise kontrolliga.
    • Analüüsida mõju ühenduste haldusele (connection pooling) ja turvalisusele (nt SQL süstimise mõju piiramine).
  5. Loogiline andmeait ja andmete virtualiseerimine (FDW) Magister
    Projekteerida föderatiivne andmebaas kasutades PostgreSQL Foreign Data Wrappers tehnoloogiat.
    • Luua loogiline andmeait, mis pärib reaalajas andmeid mitmest heterogeensest allikast.
    • Analüüsida päringute optimeerimist (push-down) ja võrrelda lahendust klassikalise ETL-põhise andmeaidaga.

6. Andmebaaside disaini analüüs ja erilahendused

Süvitsi minev uurimistöö andmestruktuuride, graafide ja ajaandmete haldamise teemadel.

  1. Graafiandmete haldamise võimekuse võrdlev analüüs: Relatsioonilised vs. Graafipõhised vs. Hübriidsüsteemid Magister
    Kuigi graafipõhised andmebaasid kuuluvad traditsiooniliselt NoSQL vihmavarju alla, on SQL-standardisse (SQL:2023) lisandunud graafipäringute tugi (SQL/PGQ). Töö eesmärgiks on uurida, kas ja millal on otstarbekas asendada spetsialiseeritud graafibaasid relatsiooniliste süsteemide graafivõimekusega. Töö peab võrdlema valitud süsteeme kolmest aspektist: 1) kirjutamise skeemi (schema-on-write) ja andmete terviklikkuse jõustamise võimalused; 2) päringukeelte ekspressiivsus ja koodi keerukus; 3) teede leidmise ja analüütiliste päringute jõudlus.

    Üliõpilane peab valima ühe konkreetse võrdluskomplekti (tehnoloogiapinu) ja viima läbi eksperimendi:
    • Suund A (PostgreSQL ökosüsteem): Võrrelda omavahel:
      • Puhas SQL disain (kasutades rekursiivseid päringuid ja graafimustreid SQL-is).
      • PostgreSQL laiendusega Apache AGE (mis põhineb AgensGraph tehnoloogial).
      • Graafipõhine andmebaasisüsteem (nt Neo4j) kontrollgrupina.
    • Suund B (Microsofti ökosüsteem): Võrrelda omavahel:
    • Suund C (Tugevad tüübid vs Skeemivabadus): Võrrelda mudeli paindlikkust ja andmekvaliteeti:
      • TypeDB (endine Vaticle) – tugevalt tüübitud, reeglitepõhine süsteem.
      • Neo4j – populaarseim, paindliku skeemiga ("schema-optional") süsteem.
      • Relatsiooniline andmebaas (PostgreSQL/MySQL) range skeemiga.
    Valiku tegemisel võib lähtuda ka DB-Engines edetabelist, valides võrdluseks hetke populaarseimad lahendused.
  2. Bi-temporaalsete andmete haldamine PostgreSQLis Magister
    Uurida SQL:2011 standardi ajaliste laienduste (PERIOD, SYSTEM_TIME) implementatsiooni.
    • Arendada edasi varasemat laiendust või luua uus lahendus, mis toetab nii kehtivusaega kui transaktsiooniaega.
    • Võrrelda lahendust kommertsbaasidega (Oracle Flashback, MS SQL Temporal Tables).
  3. Avatud lähtekoodiga tarkvara SQL-andmebaaside disaini empiiriline analüüs Magister
    Korraldada laiaulatuslik uuring andmebaaside disainikvaliteedi kohta.
    • Valida uuritavad disainiprobleemid (nt vähene normaliseeritus, võtmete puudumine, nimetamisreeglite mittejärgimine).
    • Automatiseerida nende puuduste esinemise kohta info kogumine paljudest GitHubi projektidest.
    • Võrrelda tulemusi olemasolevate uuringutega (nt Michael Blaha 2001. aasta uuring).
  4. Vaadete kasutamise mõju päringute optimeerimisele ja jõudlusele kaasaegsetes andmebaasisüsteemides Baka
    Andmebaaside teoorias peetakse vaateid (views) oluliseks abstraktsioonikihiks, kuid ajalooliselt on need tekitanud probleeme päringu optimeerijatele (nt indeksite mittekasutamine tingimuste "alla surumisel" ehk predicate push-down ebaõnnestumine). Töö eesmärgiks on korrata ja laiendada varasemas magistritöös tehtud uuringut, kasutades uusimaid andmebaasisüsteemide versioone (nt PostgreSQL 16+, Oracle 23c).

    Töö käigus tuleb:
    • Uurida eksperimentaalselt, kui edukalt suudavad kaasaegsed optimeerijad rakendada query rewriting ja view merging tehnikaid.
    • Võrrelda täitmisplaane (execution plans) ja täitmisaegu kolmes olukorras: 1) päring otse baastabelitest, 2) päring läbi lihtsa vaate, 3) päring läbi sügavalt nestitud (üksteist kutsuvate) vaadete.
    • Analüüsida erijuhte, mis optimeerijaid sageli segadusse ajavad: agregeerimist sisaldavad vaated, `UNION ALL` vaated ja väliste funktsioonide kasutamine vaadetes.
    • Tulemused peavad andma praktilisi soovitusi arendajatele: millal on vaadete kasutamine jõudluse seisukohast ohutu ja millal tuleks eelistada muid lahendusi (nt materialiseeritud vaated, ühised tabeli avaldised).
  5. Vaadete ja materialiseeritud vaadete disainimetoodika Baka
    Süstematiseerida vaadete kasutamine.
    • Koostada metoodika (millal kasutada virtuaalset tabelit e vaadet, millal materialiseeritud vaadet e hetktõmmist).
    • Rakendada metoodikat reaalse süsteemi optimeerimisel ja mõõta mõju jõudlusele.

7. Evolutsioon ja elutsükli haldus (DLM)

Kuidas hallata andmebaasi muudatusi, versioonimist ja skeemi arengut pikaajalistes projektides.

  1. Skeemi ja koodi koosevolutsiooni empiiriline uuring Magister
    Analüüsida, kuidas erinevad arhitektuurid (ORM vs. salvestatud protseduurid ja vaated vs. JSON) mõjutavad süsteemi muudetavust.
    • Viia läbi eksperiment, kus muudetakse süsteemi nõudeid ja mõõdetakse koodimuudatuste mahtu (koodiridade arv, failide arv) erinevate lähenemiste korral.
    • Tugineda teaduskirjandusele (nt Qiu et al., 2013).

    2. 8. Jõudlus ja optimeerimine

    SQL lausete ja andmebaasi mootori töökiiruse analüüs ja parandamine.

    1. Tekstiotsingu lahenduste võrdlus: PostgreSQL trigramm indeksid vs. PostgreSQL FTS vs. välised mootorid Baka
      • Võrrelda täpsust, kiirust ja seadistamise keerukust: PostgreSQL + pg_trgm (trigramm) indeksid, PostgreSQL FTS, ElasticSearch (või Sphinx), Wildspeed.
      • Analüüsida lahendusi eesti keele morfoloogia toe seisukohast.

    Tagasi kodulehele