Kodulehed
Valitud koduleht: [374] - Andmebaasid II (ITI0207, IDU0230) (sügis 2019)
pinned Kiirvalik
Üldist
Materjalid
Vaated materjalidele
Tudeng
Abi
Mitmesugust
HELPDESK - teemad:

                         
Erki Eessaar:
Kas iseseisva töö tegemisel on võimalik seda automaatselt kontrollida ja saada seega töö kohta jooksvalt tagasisidet?
Vastus: Jah on. Teie töö hindamiseks kasutatakse automatiseeritud disaini kontrollimise vahendit (erinev tarkvara PostgreSQL ja Oracle jaoks, kuid need lähtuvad samast põhimõttest). Teil on võimalus jooksvalt ise oma andmebaasi selle abil analüüsida. Eeldus on, et andmebaas on apex.ttu.ee serveris (see on muide projekti reeglitega nõutud).

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

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

Verifitseerimine ei ole sama mis valideerimine. Andmebaasi valideerimine peab vastama küsimusele: Kas andmebaas võimaldab hoida kõiki neid andmeid, mida kasutajal on vaja hoida (st kas vastab kasutajate nõudmistele, 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 2019)". 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.
  • 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.

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.

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.

Kommentaarid

Sellele küsimusele/vastusele pole kommentaare



1.Erki Eessaar:
2.Erki Eessaar:
3.Erki Eessaar:
4.Erki Eessaar:
5.Erki Eessaar:
6.Erki Eessaar:
7.Erki Eessaar:
8.Erki Eessaar:
9.Anonüümne:
10.Anonüümne:
11.Anonüümne:
12.Erki Eessaar:
13.Erki Eessaar:
14.Erki Eessaar:
15.Erki Eessaar:
16.Erki Eessaar: