Vastus (30.11.2024 17:42): 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
FortiClient VPN ü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. PostgreSQL puhul on eeldus, et andmebaas on
apex2.taltech.ee serveris (PostgreSQL)
(see on muide projekti reeglitega nõutud).
Vaadake selle kohta
videot.
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.
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.
PostgreSQL
Kui teete oma projekti PostgreSQLis, siis minge aadressile. Logige sisse kasutades apex2 kasutajanime ja parooli. Valige kontrollitav andmebaas. Ilmselt on see samasuguse nimega nagu ühe projekti tegija kasutajanimi ja sisaldab tema matriklinumbrit.
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.
Test on päringute kogum. Keskkonnas on mitmeid teste. Samuti saab käivitatavaid päringuid valida kategooria (teema) ja päringu tüübi järgi. Võite käivitada mistahes päringuid, mida keskkond pakub.
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.
Testi "Quick test2" alla on koondatud probleemide otsimise päringud, mille puhul on palju vale-positiivseid vastuseid või mille osutatud probleemide eest aineprojekti hindamisel miinuspunkte ei saa.
Testi "Databases II (fall ...) (shorter version)" alla on koondatud üldised ja tarkvara mõõdikute päringud, millest igaüks toob välja infot mingi andmebaasi aspekti kohta. Inimene peab tulemustele peale vaatama ja neid interpreteerima.
Testi "Databases I (spring ...) quick test" all on alamhulk "Quick test" päringutest, mille leitud probleemid on olulised "Andmebaasid I" õppeaines.
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.
Usaldusväärsus on hinnang sellele, kuidas päring oma eesmärke täidab.
PostgreSQL jaoks koostatud päringud on avatud lähtekoodiga ja on avaldatud otsimist võimaldavas kataloogis, mille viide on projekti kodulehel SIIN.
Oracle
Kui teete oma projekti Oracles, siis laadige alla need failid ja käivitage seal olevad skriptifailid Oracle SQL Developeri kaudu. Lugege kõigepealt faili LOEMIND.txt Oraclele on loodud 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.