Vastus: Väga eluline näide (seostub teemaga 6 - transaktsioonid ja lukustamine).

2017. aastal avaldati rahvusvahelisel tippkonverentsil teadusartikkel, kus sellist tüüpi rünnakute tagamaid täpsemalt avati ning uuriti nende esinemise võimalust 12 e-kaubanduse programmi põhjal.

Warszawski, T., Bailis, P., 2017. ACIDRain: Concurrency-related attacks on database-backed web applications. In Proceedings of the 2017 ACM International Conference on Management of Data. ACM. pp. 5–20. [WWW] http://www.bailis.org/papers/acidrain-sigmod2017.pdf

Autorid nimetavad sellist tüüpi rünnakut ACIDRain. See on ründemeetod, mis kasutab ära rakenduste nõrkust, mille korral saab rakendust manipuleerida nii, et selle antud korralduste alusel hakkab andmebaasisüsteem koostama mitteserialiseeritud tööplaane.

Uuritud 12 e-kaubanduse programmi on installeeritud üle kahe miljoni korra. Üle 60% miljonist kõige populaarsemast e-kaubanduse keskkonnast kasutavad ühte nendest programmidest. Uuring tuvastas nendes programmides kokku 22 kriitilist haavatavust, mida saab ACIDRain rünnakuga ära kasutada. Näiteks saab ründaja kasutada kinkekaarte üle etteseatud limiidi ja osta e-poest tasuta kaupu. ACIDRain rünnakute vältimises peavad arendajad tundma transaktsioone, lukustamist, transaktsioonide isolatsioonitasemeid ning oskama neid õiges kohas ja õigel viisil kasutada.

2015. aastal avaldati rahvusvahelisel tippkonverentsil teadusartikkel, kus kirjeldati Ruby on Rails raamistikus loodud 67 avatud lähtekoodiga rakenduse uurimise tulemusi.

Bailis, P., Fekete, A., Franklin, M. J., Ghodsi, A., Hellerstein, J. M., Stoica, I., 2015. Feral concurrency control: An empirical investigation of modern application integrity. In Proceedings of the 2015 ACM SIGMOD International Conference on Management of Data. ACM. pp. 1327-1342 [WWW] http://www.bailis.org/papers/feral-sigmod2015.pdf

Uuring keskendus rakenduse tasemel jõustatud andmete kontrollidele. Uuringu tulemusena selgus, et 13% uuritud kontrollidest olid ebapiisavad (st lubasid andmebaasi kitsendusega vastuolus olevaid andmeid), sest ei arvestanud andmete samaaegse kasutamise võimalusega.

Artikli järeldustes tõdeti: "Andmete samaaegse kasutamise reguleerimise lahenduste sisseehitamine rakendusraamistikesse või üksikutesse rakendustesse on kallis, veaohtlik ja raske ettevõtmine, mis eirab andmebaaside valdkonnas aastakümneid sellel suunal tehtud tööd. Kuigi see lähenemine on piisav, et tagada meie analüüsitud süsteemide puhul umbes 87% kitsenduste korrektne jõustamine, võib ülejäänute puhul andmete kontrollimine paljudes kaasaegsete ORMides viia kitsendustele mittevastavate andmete registreerimiseni."

Seega rakenduste looja peaks oskama selle võimalusega arvestada ning teadma ka seda, kuidas kitsenduste andmebaasi tasemel jõustamine tema tööd lihtsamaks teeb nagu kirjeldatakse näiteks siin ja siin. Siis ei ole andmebaasis kitsenduste jõustamine tema jaoks enam "veider trikk".

Järgneva kohta võivad küünilised programmeerijad öelda, et palju koodi ja pärmina paisuvad arenduste hinnad annavad neile tööd ja leiba. Kuid kindlasti on see suur probleem ARVETE MAKSJATELE (lõpuks tuleb kogu raha ikkagi kas maksumaksja või organisatsiooni pakutava toote/teenuse ostja taskust).

Tänapäeva tarkvaraprojekte iseloomustavad üle kokkulepitud tähtaegade minek ning arenduseks kulunud summade kasv. Pole mingi ime, kui süsteem, mis algselt pidi maksma üks miljon Eurot, läheb maksma 10 miljonit Eurot või rohkem. Näideteks on Sotsiaalkindlustusameti infosüsteemi SKAIS2 arendus Eestis ja Obamacare veebilehe arendus USAs. Selle põhjuseks on raiskamine ning sellest kirjutab pikemalt oma raamatus Dave McComb. See näide pole seotud andmebaasidega, kuid on siiski tähelepanuväärne näide üle võlli kulutustest (raiskamisest) lihtsale tarkvarale. Suured kulud tulevad tarkvara asjatust keerukusest.

McComb pakub välja tarkvara keerukuse leidmise valemi:

keerukus = rakenduste arv * andmebaasi skeem (skeemi elementide arv - nt tabelite ja veergude arv) * rakenduste lähtekood (koodiridade arv) skeemi kohta

Keerukuse vähendamiseks tuleks nende näitajate väärtuseid vähendada. McComb kirjutab, et kui kahte nendest vähendada poole võrra, siis väheneb keerukus 75% ja kui kõiki kolme vähendada poole võrra, siis väheneb keerukus 83%.

"Andmebaasid I" õppeaines räägitud allsüsteemideks jagamine aitab hoida rakenduste arvu kontrolli all, väldib funktsionaalsuse dubleerimist erinevates rakendustest (igale funktsionaalsele allsüsteemile hakkab vastama rakendus, mis tänapäeva mobiilses maailmas võib isegi olla äpp) ja andmete dubleerimist erinevates andmebaasi alamosades e registrites.

Hästi disainitud e kavandatud andmebaas (kus on läbimõeldud ja hästi koostatud andmestruktuurid) muudab rakenduse tegemise lihtsamaks ja vähendab vajamineva koodi hulka. Halvasti disainitud andmebaas, vastupidi, suurendab vajamineva koodi hulka. Hästi disainitud tähendab muuhulgas, et andmebaasis, kus on vaja üksikuid fakte lisada, muuta ja kustutada (operatiivandmete andmebaas), on võimalikult vähe andmete liiasust (vt andmebaasi normaliseerimine ja ortogonaalse disaini printsiip). Kui näiteks kliendi andmeid korratakse üle erinevate andmestruktuuride, siis kasvab skeemi suurus ja skeemi jaoks vajaliku rakenduse koodi hulk ning see omakorda kasvatab keerukust. Kui andmestruktuur ei ole kõrge astmeni normaliseeritud ja seal on palju andmete liiasust, siis suureneb andmete muutmiseks vajaliku koodi hulk ja see kasvatab keerukust. Rääkimata sellest, et suurem andmete hulk vähendab andmete muutmise operatsioonide täitmiskiirust.

Ärireeglite kontroll andmebaasi tasemel vabastab vajadusest neid kontrolle korduvalt ja erinevates rakendustes realiseerida ja seega vähendab vajamineva koodi hulka. Kui on täiesti kindel, et andmebaasis olevad andmed vastavad teatud reeglitele (st nende reeglite kontroll toimub andmebaasi tasemel), siis saab andmete küsimiseks kirjutada lihtsamaid päringuid ja andmebaasisüsteem suudab teatud päringuid kiiremini täita.

Deklaratiivne andmebaasikeel (nagu SQL andmekäitluskeel) on väga võimas ning suhteliselt väikese koodi hulgaga saab lahendatud vägagi keerulised andmete otsimise või muutmise ülesanded. Võrdluseks, sama ülesande lahendamine rakenduse tasemel imperatiivselt (süsteemile samm‑sammult tegevusi ette kirjutades), nõuaks suuremat hulka koodi ja seega kasvataks keerukust. Samuti, mida rohkem koodi, seda rohkem on koodis võimalikke vigu. Vajadus lahendada sama ülesannet erinevates rakendustes kasvatab koodi hulka ning süsteemi keerukust veelgi.