DT blogi

Disaini mustrid (design patterns) on vist tuttav termin pea igale tarkvara arendajale, kes vähegi objekt-orienteeritud programmeerimisega on tegelenud. Omad mustrid on olemas ka andmebaaside jaoks, mida ei tohi segi ajada andmemudelitega.

Oma TechEd Developers 2007 esimesel päeval toimunud ettekandes Database Design Patterns jagas Stephen Forte andmebaasi mustrid kahte kategooriasse:

1. andmemudelite mustrid,
2. infrastruktuuri mustrid.

Käesolevas kandes peatun andmemudelite mustritel, infrastruktuuri omad jäävad mõneks teiseks korraks. Selle kande kirjutasin valmis Stepheni väga ladusa ja tasemel ettekande põhjal.

Andmemudeli mustrid rakenduvad andmemudelitele. Tegemist on mustritega andmebaasi tasemel tehnilistele lahendustele, mitte mustritega, mis rakenduvad konkreetse andmemudeli disainile. Siin vaatleme järgmiseid mustreid.

1. Multi-User Highly Transactional design pattern (OLTP).
2. Slowly Changing Dimension design pattern (SCD).
3. Data Warehouse design pattern (OLAP).

Transaktsiooniline muster

Esimest ehk siis transaktsioonilist mustrit järgivad kõik andmemudelid, mis on mõeldud andmete kogumiseks. Siia alla lähevad ka andmebaasid, kus transaktsioone näiliselt ei kasutata. Transaktsioonilised andmebaasid kasutavad tavalist normaliseerimist (esimene, teine ja kolmas normaalvorm).

Näiteid transaktsioonilistest andmebaasidest

Tegemist on meie igapäevaste andmebaasidega, mis jooksevad pea kõikide rakenduste taga, mis andmeid kuskil hoiavad. Näiteks veebi lehekülgede ja intranetide taga töötavad andmebaasid järgivad enamasti transaktsioonilist mustrit.

Millal kasutada ja millal mitte

Transaktsioonilise mustriga andmebaasid ei sobi hästi andmete analüüsiks ja raportite koostamiseks. Tänu sellele, et tegemist on normaliseeritud andmetega, tuleb raporteerimisel ja analüüsimisel kasutada vastavate lähteandmete saamiseks mahukamaid ja keerukamaid päringuid.

Teine löök jõudlusele on erinev indeksite vajadus. Kui vaatame kõrvalolevat pilti, siis näeme, et terve hulk kasutajaid tekitab andmeid ja teine hulk kasutajaid pärib neid. Siin tekib üks probleem.

Andmete sisestamise ja muutmise juures on vaja ühtesid indekseid, efektiivsete päringute jaoks aga enamasti tervet posu teisi indekseid veel lisaks. Andmete muutmine aga tähendab alati ka indeksite muutmist.

Seega, mida rohkem on indekseid, seda aeglasemad on andmete muutmise protseduurid. Ja mida aeglasemad on andmete muutmise protseduurid, seda pikema aja peavad ootama ka päringud, mis meile andmeid esitavad töödeldud kujul.

Transaktsiooniline andmebaas, nagu näeme, ei sobi raporteerimiseks ja analüüsiks, kui see täidab andmete adekvaatseks töötlemiseks ühte olulist eeldust - andmed on normaliseeritud. Raporteerimise probleemi lahendab siit järgnev muster.

Slowly Changing Dimension

Tegemist on andmebaasidega, mille saab tuletada transaktsioonilistest andmebaasidest peamiselt raportite koostamiseks. Selle mustri idee seisneb selles, et meil õnnestub andmebaasi koormust vähendada oluliselt, kui me igal päringul ei koosta erinevate tabelite põhjal korduvalt samu tulemuste hulki andmetest, mis pole vahepeaö muutunud.

Andmemudeli osas on tegemist enamasti “lamedama” struktuuriga, kus esineb mõningal määral denormaliseerimist. Enamasti on selle mustriga andmebaaside tabelitel palju indekseid, sest andmeid kasutatakse reaalsetes päringutes.

“Avaldatud andmed”

Stephen illustreeris Slowly Changing Dimension mustrit järgivaid andmebaase väga hästi. Kujutame ette, et meil on transaktsiooniline andmebaas, kuhu koguneb andmeid. Nende andmete põhjal soovime teha raporteid, mida esitame veebis või kuskil mujal. Oletame, et soovime saada kokku nimistu, kus on sellised veerud nagu klient, asukoha riik, aadress ja seniste tellimuste summa.

Kliendi nime saame ühest tabelist koos aadressiga, asukoha riigi teisest ning tellimuste summa läbi tellimuste tabeli tellimuse ridade tabelist ridade liitmise teel. On selge, et siin on päris hea hulk andmeid, mis koguaeg ei muutu.

Klient oma nime vahetab harva, kui üldse (selleks tuleb siiski valmis olla). Aadress püsib ka enamasti tükk aega muutumatuna, asukoha riik muutub aga veel harvemini. Need on andmed, mille uuesti koostamisel on mõtet ainult juhul, kui need andmed muutusid. Tellimuste summa muutub neist andmetest arvatavasti kõige enam. Eriti juhul, kui on püsikliente palju.

Seega võiks aruandluse jaoks luua just selleks mõeldud ja optimeeritud andmebaasi, kuhu pumpame mingi intervalli järel andmete uue seisu peale, tehes seejuures ära kõik vajalikud andmete teisendused. Selles seisnebki Slowly Changing Dimension muster - me koostame aeglasemalt muutuvate andmete jaoks eraldi andmebaasi, kus on andmed optimeeritud just väljundile.

Pluss on veel seegi, et selle andmebaasi saame indekseerida just selliselt, et raportite koostamine oleks kiire ja seejuures ei mõjuta me andmete lähtabaasiks oleva andmebaasi jõudlust.

Millal kasutada ja millal mitte

Seda mustrit tasub kasutada ainult selleks, milleks see on mõeldud - raporteerimiseks ja aruandluseks. See ongi “avaldatud andmete” mõte. Me ei koosta kogu andmehulka igal korral alates nullist, vaid kasutame ettevalmistatud andmed.

Tavaliseks andmete ladustamiseks ei ole seda mustrit otstarbekas kasutada, sest kui OLTP andmebaas on kiire ja toimib kenasti, mõjutaks muudatuste reaalajas kajastamine siia serveri jõudlust oluliselt.

Data Warehouse muster

Tegemist on enamasti star schema järgi ehitatud andmebaasiga, milles hoitakse andmeid analüüsimiseks sobival kujul. On faktitabelid, mille küljes on dimensioonide tabelid, mis sisaldavad analüüsiks vaja minevaid täiendavaid andmeid. Faktitabelid on enamasti kolmandas normaalvormis, dimensioonide tabelid aga teises normaalvormis. Nende tabelite normaliseerimine on enamasti räige viga, sest see tõstab andmete analüüsis kasutatavate päringute keerukust päris kõvasti.

Jooniselt näeme, et faktitabeliks on töötajate andmeid sisaldav factEmployee. Dimensioonide tabeliteks on dimSalaryGroup, dimGender ja dimAgeGroup, mis sisaldavad vastavalt andmeid palgagruppide, sugude ja vanusegruppide kohta.

Millal kasutada ja millal mitte

Data Warehouse mustrit kasutatakse andmesalvede disainimisel. Andmed sellistesse andmebaasidesse ei teki otse - need tekivad enamasti andmeteisenduse operatsioonide kaudu. Andmed võivad siia kokku voolata erinevatest andmebaasidest, näiteks müük, personal, kasutajatugi ja tootmine.

Andmed selles andmebaasis on mõeldud ainult andmeanalüüsiks ning eelmise kahe mustri kontekstis on sellise andmebaasi kasutamine mõeldamatu.

Kokkuvõtteks

Tutvustasin käesolevas kandes kolme andmemudeli mustrit. Kindlasti on neid mustreid veelgi. Andmebaasi mustrid on küllaltki uus teema ning erinevalt tarkvaralistest disaini mustritest pole andmebaaside omi veel täie sulatuses üles kaardistatud ja kirja pandud. Aga küll tuleb seegi päev pea, mil andmebaasid oma mustrite kataloogi saavad.

Kirjutas Gunnar, 13.11.2007 kell 01:45, teemal Andmebaasid. Jälgi selle postituse kommentaare läbi RSS-uudistevoo (feed). Lisa kommentaar või tagasisideviide (trackback) oma veebilehelt või blogist.