Kodulehed
[369] - Andmebaasid II (IDU0230, ITI0207) (sügis 2018)
Esiletöstetud Kiirvalik
Lisainfo Kõige olulisemate tegevuste kiirvalik. Failide saatmiseks valige Vastamine alt sobiv ülesanne.
Avaleht
Nagu Moodles

Valik materjalidest
   Nädala materjalid
   Minu lemmikud

Vastuste vaatamine
Hinneteleht
Seisuga: 22.12.2018 12:46
Üldist
Materjalid
LisainfoMaterjalide kataloogid.
Värvilised mummud tähistavad hinnangulist kataloogide lugemise vajadust. Roheline - suurim, kollane - keskmine, punane või mummuta - väikseim
Isiklik
Lisainfo Info ainult Sulle - teised kasutajad seda ei näe
Abi
Lisainfo Võimalus küsida õppejõult abi (nagu foorum, kus saab küsida küsimusi ja kommenteerida vastuseid)
Mitmesugust
Abi / Kasutajatugi / Iseseisva töö projekt

Avalikud küsimused ja vastused:

Küsimuste teemade nimekiri

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 "Käivita saadaolevaid teste". Valige test "Databases II (fall 2018)". Vaadake päringu tulemusi, milles on üks või rohkem rida. Lugege kirjeldust, vaadake tulemusi. Usaldusväärsus on hinnang sellele, kuidas päring oma eesmärke täidab.

  • Alajaotuses "General" on päringud, mis otsivad andmebaasist spetsiifilist infot, kuid otsuse selle kohta, kas midagi on õigesti või valesti peab tegema inimkasutaja, kes tulemust vaatab.
  • Alajaotuses "Flaw detection" on päringud, mille tulemuses olev iga rida osundab mingile võimalikule disaini veale. Sõltuvalt päringu usaldusväärsuse hinnangust peaks inimkasutaja selle üle kontrollima.
  • Alajaotuses "Software measure" on päringud, mis arvutavad andmebaasi skeemi põhjal mingi arvulise väärtuse.

Soovi korral võite kasutada ka kasutajaliidese vana versiooni, kus kõik tulemused on ühel lehel. Mina kasutan tundides Teiega koos andmebaase vaadates seda. Päringud on samad, kasutajaliides erinev.

Keskkonnas on mitmeid teste. Testi "Quick test" alla on koondatud päringud, mille puhul tulemuses olev vähemalt üks 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 programm SonarQube.

Hinda vastust:

Keskmine hinne : Pole veel hinnanguid!