Vastus: NB! Järgnevalt nimetatud kontrollpäringute käivitamise veebilehtedele saab ligi nii Tehnikaülikooli kui ka Eesti IP ruumist. Kui keegi peaks vajama ka välisriikidest ligipääsu, siis eelnevalt tuleb luua eduVPN ühendus.

Jah on. Teie töö hindamiseks kasutatakse automatiseeritud disaini kontrollimise vahendit (erinev tarkvara PostgreSQL ja Oracle jaoks, kuid need lähtuvad samast põhimõttest). Teil on võimalus jooksvalt ise oma andmebaasi selle abil analüüsida. Eeldus on, et andmebaas on apex.ttu.ee serveris (see on muide projekti reeglitega nõutud).

Vahend käivitab andmebaasi süsteemikataloogi põhjal päringuid. Osa päringuid suudavad leida vigu. Osa aga otsivad andmebaasi disainist halva lõhnaga kohti (vt halvasti lõhnav disain ja halvasti lõhnav kood). Halvasti lõhnavad kohad ei takista andmebaasi ja seda kasutavate süsteemide toimimist, kuid muudavad andmebaasi kasutamise, haldamise või arendamise mingis aspektis raskemaks kui see võiks olla. Halvasti lõhnavad kohad on sügavamate probleemide sümptomid. Nende probleemide lahendamine aitab koodi/mudelit/disaini/arhitektuuri puhastada. Halb lõhn on tehnilise võla tunnus. Tehniline võlg tähendab, et "asi" töötab, kuid saaks olla sisemiselt tehtud paremini. Kuna praegu on seal midagi "üle jala" lastud, siis see on probleem tulevikus, kui "asja" on vaja edasi arendada. Kliendile kiiresti töötava asja üleandmiseks on võetud võlga tuleviku arenduste arvelt. Tehnilist võlga aitab vähendada refaktoreerimine.

Vahend on mõeldud andmebaasi osaliseks staatiliseks versifitseerimiseks – kontrollimiseks, kas andmebaas vastab tehnilistele nõuetele. Vahendi kasutamine aitab vastata küsimusele: Kas andmebaasi tehakse õigesti? Staatiline tähendab, et kontrollimiseks vaadeldakse andmebaasi struktuuri ja käitumise kirjeldust, mitte ei viida andmebaasi põhjal läbi tegevusi (see oleks dünaamiline verifitseerimine).

Verifitseerimine ei ole sama mis valideerimine. Andmebaasi valideerimine peab vastama küsimusele: Kas andmebaas võimaldab hoida kõiki neid andmeid, mida kasutajal on vaja hoida (st kas vastab kasutajate nõudmistele, kas teeme õiget andmebaasi)? Kontroll, kas andmebaasi disaini mudel realiseerib andmebaasi vastavalt kontseptuaalses andmemudelis esitatud nõuetele, läheb valideerimise alla. Probleem on, et need nõuded võivad olla vananenud või valesti kirja pandud. Andmebaasi valideerimine annab vastuse, kas andmebaas ka tegelikult nõudeid täidab.

Kui teete oma projekti PostgreSQLis, siis minge aadressile. Logige sisse kasutades apexi kasutajanime ja parooli. Valige kontrollitav andmebaas. Ilmselt on see samasuguse nimega nagu ühe projekti tegija kasutajanimi ja sisaldab tema matriklinumbrit. Valige test "Databases II (fall 2021)". Vaadake päringu tulemusi, milles on üks või rohkem rida. Selleks, et tulemuses oleksid vaid päringud, mis tagastavad vähemalt ühe rea, vajutage nupule "Execute and show only queries that return rows". Iga päringu korral lugege kirjeldust, vaadake tulemusi. Kui päringute käivitamisel on valitud "Generate SQL statements to fix problems", siis väljastab programm mõningate probleemide puhul nende lahendamiseks mõeldud SQL lauseid.

Päringuid on erinevat tüüpi.

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

Usaldusväärsus on hinnang sellele, kuidas päring oma eesmärke täidab.

Soovi korral võite kasutada ka kasutajaliidese uut versiooni. Päringud on samad, kasutajaliides erinev. See keskkond ei paku võimalust väljastada leitud probleemide lahendamiseks mõeldud SQL lauseid.

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

PostgreSQL jaoks koostatud päringud on avatud lähtekoodiga ja on avaldatud otsimist võimaldavas kataloogis, mille viide on projekti kodulehel SIIN.

Kui teete oma projekti Oracles, siis minge aadressile. 990999 tuleb asendada matrikli numbriga, mida kasutate projekti tulemusena loodud andmebaasiobjektide nimedes. Oraclele on loodud palju vähem kontrolle kui PostgreSQLile (üks põhjus, miks eelistada iseseisva töö andmebaasisüsteemina PostgreSQLi) ning Oracle kontrollpäringute täitmine võtab PALJU rohkem aega kui PostgreSQL päringute täitmine.

Võite neid päringuid regulaarselt ise käivitada ja interpreteerida üritada. Küsimuste korral pöörduge õppejõu poole. Oleks väga hea, kui mõnes semestri lõpu praktikumis, kui projekt juba valmis saama hakkab, jõuaksite koos õppejõuga need päringu tulemused üle vaadata. Praktikas ongi semestri teise poole praktikumid suures osas pühendatud üliõpilastega koos nende andmebaasi põhjal käivitatud päringute ülevaatamisele.

Need süsteemid võimaldavad andmebaasides põhimõtteliselt samasugust analüüsi kui rakendustes programmid SonarQube ja PVS-Studio. Siit saate näitena lugeda kolme avatud lähtekoodiga andmebaasisüsteemi (PostgreSQL, MySQL, Firebird) koodi kvaliteedi võrdlust, milleks samuti kasutati lähtekoodi staatilist analüüsimist. PostgreSQL ja Oracle näitel ei analüüsita mitte otse lähtekoodi, vaid selle käivitamise tulemust (loodud andmebaasiobjekte). Tegemist ei ole programmi dünaamilise analüüsiga, sest dünaamilise analüüsi korral käivitatakse programm erinevate sisenditega ja jälgitakse selle käitumist/väljundit. Andmebaaside korral tähendaks see erinevate päringute ja andmemuudatuste tegemist ning näiteks täitmisaja ning täitmiseks kasutatud plaanide jälgimist/uurimist.