Kodulehed
[380] - Andmebaasid I (ITI0206) (kevad 2021)
pinned Kiirvalik Kõige olulisemate tegevuste kiirvalik
Üldist
Materjalid Materjalide kataloogid
Vaated Erinevad väljavõtted kataloogides olevatest materjalidest. Alternatiivsed juurdepääsuteed materjalidele.
Isiklik Info ainult Sulle - teised kasutajad seda ei näe
Abi Võimalus küsida õppejõult abi (nagu foorum, kus saab küsida küsimusi ja kommenteerida vastuseid)
Mitmesugust
Abi / Kasutajatugi / Andmebaasi kavandamise sisulised küsimused

Avalikud küsimused ja vastused:
Teemad:

                         
Anonüümne:
Ma olen informaatika üliõpilane. Ma arvan, et kursuse töö töövihik on suur dokument mida keegi ei kasuta päris elus. Aine projekti tegemine on täielik ajaraisk, sest kogu info mida õppejõud näha tahab tuleb temalt ning kui ise sellest väga õppida ei saa. Milliseid kasulikke teadmisi, lisaks andmebaasidele, see projekt (informaatikutele) annab?
Vastus: 1. Üks võimalik viis, kuidas tarkvara tükeldada. Tükeldamine on vajalik tarkvara keerukusega toimetulekuks ja töö paremaks organiseerimiseks.
2. Ülevaade võimalikest mudelitest, mida saab kasutada tarkvara kirjeldamiskes. Ka agiilne süsteemiarendus ütleb, et modelleerimine on vajalik. Tuleb luua mudeleid, millest on kasu, mitte linnukese pärast. Erinevates olukordades, võib olla kasu erinevatest mudelitest. Selleks, et osata otsustada, kas mingit tüüpi mudel mingis olukorras sobib või mitte, tuleb esmalt neid mudeli tüüpe teada. Samuti tuleb arendajal osata aru saada nõuetest ja seega ka mudelitest, mida võidakse kasutada nende nõuete väljendamiseks.
3. Puhta koodi põhimõtted on universaalsed ja kehtivad ka mudelite ning andmebaasi disaini puhul.
4. Andmebaasis kitsenduste loomine on üks kaitsva programmeerimise meetod. Kaitsev programmeerimine üritab tagada koodi toimist ka ettenägematute asjaolude ilmnemisel ja see aitab parandada süsteemi käideldavust ja turvalisust. Siin on raamat, mis on pühendatud kaitsvale andmebaasi programmeerimisele.

Kirjutan järgnevalt täpsemalt ja toon näiteid.

1. Tänapäeval on üheks lööksõnaks e "kuumaks teemaks" mikroteenuste arhitektuur. See tähendab, et tarkvara peaks koosnema üksteisest võimalikult vähe sõltuvatest "tükkidest" e teenustest, mida saaks arendada ülejäänud "tükkidest" võimalikult sõltumatult, mida saaks kerge vaevaga asendada uue realisatsiooniga ja mida ei peaks (palju) muutma, kui mõnes teises "tükis" midagi muutub. Iga funktsionaalse allsüsteemi saaks realiseerida mikroteenusena. Selle funktsionaalse allsüsteemi teenindatava registri saaks realiseerida rakenduse andmebaasina.

Mikroteenused üritatakse luua üksteisest võimalikult sõltumatuna, eelistades dubleerimist üksteisest ilmutatud viisil sõltumisele. Andmebaaside mõttes tähendaks see, et erinevate teenuste andmebaasides dubleeritaks põhiandmeid (master data) nagu andmed klientide, toodete ja teenuste kohta ja klassifikaatoreid. Kommentaariks ütlen, et see võib tunduda teenuse autonoomsuse mõttes ahvatlev, kuid andmete dubleerimine tähendab suuremat tööd nende sünkroniseerimiseks (nii suuremat tööd arendajatel selle realiseerimiseks/testimiseks kui ka suuremat koormust süsteemile läbiviimisel) ja suuremat võimalust vastuoluliste väidete registreerimiseks. Kas see on sobiv hind või mitte jäägu igaühe enda otsustada ja kindlasti sõltub ka oludest. (Eesti) Riigi infosüsteemide kohta ütleb avaliku teabe seadus selge sõnaga: "§ 43 3.   Andmekogu asutamine (2) Keelatud on asutada ühtede ja samade andmete kogumiseks eraldi andmekogusid."

Põhiobjektidest lähtuv allsüsteemide leidmine on üks võimalik viis mikroteenuste kindlaks määramiseks ja põhiobjekti elutsüklist lähtuv funktsionaalsuse leidmine on üks võimalik viis selle teenuse funktsionaalsuse tuvastamiseks.

Kui soovida luua mikroteenused võimalikult autonoomsena ja vajadusel dubleerida andmeid erinevate teenuste andmebaasides, siis saaks teenused luua põhiobjektidele, mis vastavad transaktsioonilistele andmetele ning põhiandmetele ja klassifikaatoritele vastavaid andmeid erinevates andmebaasides dubleerida. Siin on näide hotelli infosüsteemi põhiobjektidest andmete liigituse järgi.

2. See on väga vähetõenäoline, et mõni ettevõte kasutab süsteemide kirjeldamiseks just sellist dokumendi struktuuri nagu on aineprojektis. Kuid see, et mingil määral kasutatakse modelleerimist ja mudeleid ning mõnda antud projekti mudeli tüüpidest, on väga palju tõenäolisem.

Hea allikas, kust saab lugeda erinevate aineprojekti mudelitüüpide kohta, on:
See raamat on pühendatud objektorienteeritud analüüsile ja disainile (eesmärgiga luua objektorienteeritud programmeerimiskeeles tarkvara), kuid räägitakse ka arendusprotsessist. Mudelite koostamine ei ole mitte kuidagi vastuolus iteratiivse arendamisega. Lihtsalt mudeleid ei looda ühekorraga, vaid neid luuakse ja täiendatakse järk-järgult erinevate iteratsioonide käigus. Raamatus kirjutatakse muuhulgas põhjalikult:
  • klassidiagrammidest, mida kasutades luuakse valdkonnamudeleid (domain model),
    • Kontseptuaalne andmemudel ja valdkonnamudel on sugulased ja kontseptuaalse andmemudeli loomise võtted ning mustrid on kõik kasutatavad ka valdkonna klassidiagrammide koostamiseks. Sama kehtib ka antimustrite kohta, mis esitavad esmapilgul häid lahendusi, mis hiljem viivad probleemideni. Need klassidiagrammid on omakorda sisendiks tarkvaraklasside leidmisele (nii nagu kontseptuaalne andmemudel on sisendiks tabelite leidmisele),
  • seisundidiagrammidest,
  • tegevusdiagrammidest,
  • kasutusjuhtude mudelist,
  • süsteemi operatsioonide lepingutest
    • Need on sarnased andmebaasi operatsioonide lepingutega. Süsteemi operatsioonid kirjeldavad teenuseid, mida funktsionaalsed allsüsteemid (tarkvara) pakuvad pädevusaladele (lõppkasutajatele). Andmebaasi operatsioonid kirjeldavad teenuseid, mida andmebaasi alamosad (registrid) pakub funktsionaalsetele allsüsteemidele (tarkvarale).
    • Nii nagu süsteemi operatsioonide lepingutest tekivad tarkvara klasside meetodid, tekivad andmete muutmise operatsioonide lepingutest andmebaasiserveris talletatud rutiinid (funktsioonid ja protseduurid).
    • Operatsioonide lepingud võiksid huvi pakkuda ka seetõttu, et need lähtuvad lepingprojekteerimise (design by contract) põhimõttest. See põhimõte töötati välja seoses objektorienteeritud programmeerimiskeelega Eiffel ning lähtub tarkvara elementide käitumist viisil, mida ideaalis saaks hiljem kasutada tarkvara kontrollimiseks või koodi genereerimiseks. Sellel teemal mõtlejaid on teisigi (vaadake History alamosa Larmani raamatu süsteemi operatsioonide lepingute peatükist) ja nende idee on kasvanud välja arvutiteaduse (computer science) ringkondadest.
Järgnev raamat argumenteerib, miks kontseptuaalse andmemudeli ja andmebaasi disainimudeli loomine ei ole ka agiilse andmebaasi arenduse mõttes ajaraisk, vaid igati kasulik ettevõtmine.
Burns, L., 2011. Building the Agile Database. How to Build a Successful Application Using Agile Without Sacrificing Data Management, Technics Publications. 276 p.

CRUD maatrikseid on arvutiteaduses üritatud kasutada süsteemide struktuuri leidmiseks ja see on huvitav uurimissuund (vaadake näitena seda artiklit ja ka seda).

3. Lugege näiteks siit, kuidas peaagu igale koodi halvale lõhnale vastab mingi analoogiline probleem seoses infosüsteemi/tarkvara mudelitega. Samamoodi esinevad andmebaasis ja tekitavad sellest arusaamisel, õppimisel, hooldamisel ja edasiarendamisel probleeme näiteks halvad andmebaasiobjektide nimed, kasutama andmebaasiobjektid, ebatäpsed kommentaarid, üleliigne dubleerimine ja järjekindlusetus disainiotsuste tegemisel.



1.
Erki Eessaar:
2.
Erki Eessaar:
3.
Anonüümne:
4.
Anonüümne:
5.
Ajaloo säilitamine PostgreSQL andmebaasisüsteemis:
6.
Pull request'ide sarnase süsteemi loomine Postgres:
7.
Erki Eessaar:
8.
Erki Eessaar:
9.
Erki Eessaar:
10.
Erki Eessaar:
11.
Anonüümne:
12.
Erki Eessaar:
13.
Erki Eessaar:
14.
Erki Eessaar:
15.
Erki Eessaar:
16.
Erki Eessaar:
17.
Erki Eessaar:
18.
Erki Eessaar:
19.
Erki Eessaar:
20.
Erki Eessaar:
21.
Anonüümne:
22.
Erki Eessaar:
23.
Erki Eessaar:
24.
Erki Eessaar:
25.
Anonüümne:
26.
Erki Eessaar:
27.
Anonüümne:
28.
Erki Eessaar:
29.
Anonüümne:
30.
Erki Eessaar:
31.
Anonüümne:
32.
Anonüümne:
33.
Anonüümne:
34.
Erki Eessaar:
35.
Anonüümne:
36.
Eerik Sven Puudist: