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:
Otsin omale põnevat lugemist andmebaaside (pigem relatsiooniliste, aga miks mitte ka teiste) antimustrite kohta. Mäletan Teiega andmebaaside kursust läbides, et erinevate materjalide nimed käisid läbi, aga mõtlesin küsida soovitust otse allikast. Mida võiks lugeda? Soovitatavalt võiks materjal olla inglise keeles (saaks jagada ka mitte-eestlastega), aga endale huvi pärast lugemiseks oleks eestikeelne materjal ka väga kasulik. Soovitused on teretulnud nii veebilinkide, dokumentide kui raamatusoovituste kujul.
Vastus:
Antimuster klassikalises mõttes on struktuurse kirjutamise viis, kus lisaks probleemile ja selle halvale lahendusele tuuakse välja ka see, kuidas seda probleemi paremal viisil lahendada ning ka see, millisel juhul võib halb lahendus osutuda väljakannatatavaks. SQL-andmebaaside disaini sagedased probleemid on antimustritena raamatusse kirja pannud Bill Karwin. Tema raamatut saab laenutada ülikooli raamatukogust (https://www.ester.ee/record=b2888667*est), seda saab lugeda O'Reilly digitaalselt platvormilt (https://learning.oreilly.com/library/view/sql-antipatterns/9781680500073/?ar; sellele on Tehnikaülikooli üliõpilastel juurdepääs).
 
Siis on olemas tasuta raamat kus kirjeldatakse 150-t võimalikku disainiprobleemi MS SQL Server andmebaasides: http://assets.red-gate.com/community/books/sql-code-smells.pdf Mõned nendest probleemidest on spetsiifilised MS SQL Serveri jaoks, kuid enamik võib esineda mistahes SQL-andmebaasides. Probleemide kirjeldamisel ei kasutata mustri formaati.

Siia on kirja pandud viis viga, mida SQL-andmebaasi disainimisel tuleks üritada vältida: https://www.red-gate.com/simple-talk/sql/database-administration/five-simple--database-design-errors-you-should-avoid/
 
Mis puudutab NoSQL süsteeme, siis neid iseloomustab standardite puudus (kuid see on näiteks graafiandmebaaside puhul muutumas: https://www.gqlstandards.org/) ja lugemise skeemi eelistamine kirjutamise skeemile (andmete struktuuri ei kirjeldata andmebaasi tasemel ja andmebaasisüsteem ei kontrolli andmete struktuurile vastavust andmete salvestamisel) (kuid ka see on muutumas). Tulemuseks on, et turule jõudnud kümnetes, et mitte öelda sadadest NoSQL süsteemidest tehakse igaühes asju omamoodi ja paljusid süsteeme läbivaid disaini probleeme ei saa / on raske välja tuua. Probleemid ja nende kirjeldused on süsteemi-spetsiifilised. Raamatus "Seven NoSQL Databases in a Week" (Seitse NoSQL süsteemi nädalaga), mida saab O'Reilly keskkonna kaudu lugeda, kirjeldatakse seitset NoSQL andmebaasisüsteemi (https://learning.oreilly.com/library/view/seven-nosql-databases/9781787288867/?ar). Osade süsteemide peatükkides on antimustrite alapeatükk, kus kirjeldatakse lühidalt võimalikke probleeme. Need kirjeldused ei ole mustri formaadis.
 
Sellest raamatust hakkas valusalt silma tekstilõik: "Neo4j involves appropriately modeling the required queries. Relational modeling requires you to focus on how your data is stored, and not as much on how it is queried or returned." See esitab valeväiteid. Relatsiooniline mudel ei kirjuta ette, kuidas andmebaasisüsteemi tarkvara peab sisemiselt andmeid salvestama. See on andmebaasisüsteemide (mudeli realisatsiooni) küsimus. Mudel ja realisatsioon on kaks ise asja nii nagu projekt või tarkvara või plaan ning plaani täitmine on kaks ise asja. Ühes või teises relatsioonilist mudelit realiseerivas süsteemis võib andmete salvestamine olla tehtud nii, et andmete struktuur ja selle muutmine mõjutab ka andmete käitlemise operatsioonide jõudlust. Kuid see on konkreetse süsteemi realisatsiooni, mitte relatsioonilise mudeli probleem. Konkreetseid süsteeme tutvustavate, mitte üldistest põhimõtetest kirjutavate, allikate häda on selles, et need vananevad väga kiiresti ja saadud teadmine kehtib ühes konkreetses kohas - üks süsteem (sageli ainult mõnes selle kindlas versioonis).
 
Leidub päris mitmeid teadusartikleid, kus on uuritud SQL-andmebaaside disainiprobleeme. Need artiklid nimetavad probleeme ja uurivad nende esinemist erinevates andmebaasides, kuid probleeme ei esitata mustri formaadis. Nimetan järgnevalt mõningaid artikleid. Google Scholar (https://scholar.google.com/) kaudu otsides leiab nende artiklite avalikud täistekstid.
 
Blaha, M.: A retrospective on industrial database reverse engineering projects - part 2. In:  Eighth Working Conference on Reverse Engineering, pp. 147–153. IEEE, (2001). https://doi.org/10.1109/WCRE.2001.957818
  • Vana artikkel 35 SQL-andmebaasi pöördprojekteerimise tulemuste kohta. Nendes oli masendavalt palju puuduvaid kitsendusi. Minu kogemus näitab, et 20 aastat hiljem  pole taolised probleemid andmebaasidest kuhugi kadunud.
 
Blaha, M.R., Premerlani, W.J.: Observed idiosyncracies of relational database designs. In: 2nd Working Conference on Reverse Engineering, pp. 116–125. IEEE, (1995). https://doi.org/10.1109/WCRE.1995.514700
  • Jällegi vana artikkel, kuid siin nimetatud artiklitest üks kõige suurem hulk erinevaid SQL-andmebaasi disainiprobleeme. Paraku, kuna vigadest õppimine pole kombeks, siis see, et artikkel on vana ei tähenda, et neid vigu uutes andmebaasides ei tehta.
Weber, J.H., Cleve, A., Meurice, L., Ruiz, F.J.B.: Managing technical debt in database schemas of critical software. In: Sixth International Workshop on Managing Technical Debt, pp. 43–46. IEEE (2014). https://doi.org/10.1109/MTD.2014.17
  • Puuduvatest välisvõtme kitsendustest ja sellest tulenevast tehnilisest võlast.
 
Al-Barak, M., Bahsoon, R.: Database design debts through examining schema evolution. In: 8th International Workshop on Managing Technical Debt, pp. 17–23. IEEE, (2016). https://doi.org/10.1109/MTD.2016.9
  • Esitatakse üks võimalik SQL-andmebaaside disainiprobleemide liigitus ja nimetatakse neid probleeme.

Delplanque, J., Etien, A., Auverlot, O., Mens, T., Anquetil, N., Ducasse, S.: CodeCritics applied to database schema: Challenges and first results. In: 24th International Conference on Software Analysis, Evolution and Reengineering, pp. 432–436. IEEE, (2017). https://doi.org/10.1109/SANER.2017.7884648
  • Muuhulgas tutvustatakse SQL-andmebaaside disainiprobleemide otsimiseks mõeldud tarkvara ning nimetatakse 11 probleemi, mida see tarkvara suudab tuvastada.
 
Sharma, T., Fragkoulis, M., Rizou, S., Bruntink, M. and Spinellis, D.: Smelly relations: measuring and understanding database schema quality. In: 40th International Conference on Software Engineering: Software Engineering in Practice, pp. 55–64. ACM, (2018). https://doi.org/10.1145/3183519.3183529
  • Tutvustatakse SQL-andmebaaside disainiprobleemide otsimiseks mõeldud tarkvara. Nimetatakse 13 probleemi, mida see tarkvara suudab tuvastada. Uuritakse nende probleemide esinemist suures hulgas avatud lähtekoodiga süsteemide andmebaasides ja ka nende probleemide koosesinemist (kui esineb üks probleem, siis millised teised sellega sagedasti koos esinevad).
 
Dintyala, P., Narechania, A., Arulraj, J.: SQLCheck: automated detection and diagnosis of SQL anti-patterns. In: 2020 ACM SIGMOD International Conference on Management of Data, pp. 2331–2345. (2020). https://doi.org/10.1145/3318464.3389754
  • Muuhulgas tutvustatakse SQL-andmebaaside disainiprobleemide otsimiseks mõeldud tarkvara ning nimetatakse 26 probleemi, mida see tarkvara suudab tuvastada.
Foidl, H., Felderer, M., Biffl, S.: Technical Debt in Data-Intensive Software Systems. In: 45th Euromicro Conference on Software Engineering and Advanced Applications, pp. 338 –341. IEEE, (2019). https://doi.org/10.1109/SEAA.2019.00058
  • Üks oluline mõte on, et viga ühes süsteemi osas võib tekitada probleeme teistes süsteemi osades. Näiteks puuduvad andmebaasi kitsendused vähendavad andmete kvaliteeti ja muudavad keerukamaks ning veaohtlikumaks andmebaasirakenduste realiseerimise.
Eessaar, E.: Automating detection of occurrences of PostgreSQL database design problems. In: Robal, T., Haav, H.M., Penjam, J., Matulevičius, R. (eds) Databases and Information Systems. DB&IS 2020. Communications in Computer and Information Science, vol 1243. Springer, Cham. (2020) https://doi.org/10.1007/978-3-030-57672-1_14
  • Tutvustatakse PostgreSQL andmebaasi disaini kontrollimiseks mõeldud päringute kataloogi (https://github.com/erki77/database-design-queries). Suur osa nendest päringutest (problem detection queries) otsivad andmebaasi disaini probleemide esinemisi ja enamik nendest probleemidest ei ole PostgreSQL-spetsiifilised. Seega on ühtlasi tegemist ka disaini vigade kataloogiga ja selles esitatud päringud on nagu käivitatavad vigade spetsifikatsioonid. Võrreldes eelnevate artiklitega on selles kataloogis palju rohkem disaini probleeme.
Balogh, G., Gergely, T., Beszédes, Á., Szarka, A., Fábián, Z.: Capturing expert knowledge to guide data flow and structure analysis of large corporate databases. Acta Polytechnica Hungarica 16(4), 7–26 (2019).
  • Suurte süsteemide, sh andmebaaside analüüsimine tehniliste puuduste osas on keeruline ettevõtmine. Selleks on vaja toetavat tarkvara. Artikkel kirjutab esimestest sammudest, mis on tehtud reeglipõhise analüüsisüsteemi loomise suunas.
Brass, S., Goldberg, C.: Semantic errors in SQL queries: A quite complete list. Journal of Systems and Software, 79(5), 630-644. (2006). https://doi.org/10.1016/j.jss.2005.06.028
  • SQL päringute vigade kataloog.



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: