Kursusel oli kokku 9 moodulit, kus iga juurde anti ka ports kohustuslikku kirjandust lugeda. Loomulikult sel ajal ma seda ei jõudnud lugeda, kuid võtan nüüd eesmärgiks kuu aega järjest lugeda. Vaatame, kuhu jõuame. Lugemine suvalises järjekorras.
holistics.io: Kimball's Dimensional Data Modeling moodul 2: andmemudelid ja baasid. Kas on veel midagi uut võimalik teada saada?
Tähtskeemi on äri muutudes kerge muuta. Kimballi 4 sammu juures granulaarsuse valimisel, vali kõige detailsem, väiksem, kõrgeim aste. See võimaldab leida vastuseid väga erinevatele küsimustele andmeid koondades. 90ndatel, kui valisid vale granulaarsuse, siis ümbertegemine oli töömahukas, sest päringute tegemine oligi süsteemides aeglane.
Dimensioonide valimisel peaksid need andma vastuse igale faktitabeli reale. Seda on lihtne teha, kui granulaarsuse tase on õigesti valitud. Sama kehtib ka faktitabeli kohta. Kui detailsus viimases erineb, siis see läheb teise faktitabelisse. Kimballi lähenemise kohaselt tuleb raske töö ära teha nende 4 sammu juures. NB! Ja kui otsid näidet, mida kõike võib aja-dimensiooni-tabel sisaldada, siis sellest artiklis leidub näide.
Snapshot
Tüüpiline andmeprojekt tähendab erinevatest andmeallikatest andmete sissevõttu (staging area). Siis jällegi ETLi kasutades viiakse vajalikud andmed vajalikul kujul esitluskihti. Edasi kasutavad neid visualiseerimis- või analüüsitööriistad. Kuna nii võib olla liialt palju infot, mis 90ndatel võis jõudluse tõttu õuduseks kujuneda, siis tutvustas Kimball snapshoti ehk andmete seis kindlal perioodil/hetkel.
Tänased pilveandmelao tarkvarad hoiavad andmed pigem veeru-põhistena ja miljonite ridade läbitöötamine pole mingi probleem. Samuti kasutatakse MPP (massive parallel processing), kus vajadusel suurendatakse või vähendatakse serverite arvu. Ja teenusepakkujad maksutavad oma teenuseid andmemahu pealt. Snapshot sõnana on kasutusel, aga põhimõttena pole kohustuslik, sest andmetiimi värbamine ja palga maksmine on kulukam kui pilveteenusele maksta.
SCD - teine põhjus selle artikli lugemiseks
Väga hästi seletab ära SCD (slowly changing dimention ) põhimõtte. Oletame, et meil on dimensioonitabel Klient (dim_klient), kus on järgnev kirje:
| Kliendi ID | Nimi | Aadress |
|---|---|---|
| 101 | Mari Maasikas | Tartu mnt 10, Tallinn |
Kui Mari aadress muutub, siis SCD tüüp 1 on, et me kirjutame aadressi lihtsalt üle.
| Kliendi ID | Nimi | Aadress |
|---|---|---|
| 101 | Mari Maasikas | Pärnu mnt 25, Viljandi |
Vana aadress kaob, ajalugu ei säili. Tavaliselt kasutusel OLTP, kus minevikuandmed ei oma tähtsust. Kui soovime vaadata tehtud ülevaateid, kus meie kliendid elavad, siis on andmed muutunud. Tallinn on ühe kaotanud ja Viljandi juurde saanud.
SCD tüüp 2 korral lisatakse sama inimene teist korda tabelisse, aga on read kehtiv alates, kehtiv kuni. Nüüd kuvab nii vanades kui uutes raportides õigesti, kus klient elab/elas konkreetse ostu sooritamise ajal. See on tavaliselt kasutatav variant. Kuna andmebaasid tühja väärtust/NULL võivad erinevalt tõlgendada, siis lisatakse kehtiv kuni kuupäevaks tavaliselt 9999-12-31. Vaata ka artikli näidet, seal on tegu tootega. Sama toode lisatakse uue ID-ga.
| Klient_key | Kliendi ID | Nimi | Aadress | Kehtib alates | Kehtib kuni |
|---|---|---|---|---|---|
| 1 | 101 | Mari Maasikas | Tartu mnt 10, Tallinn | 01.01.2024 | 14.05.2025 |
| 2 | 101 | Mari Maasikas | Pärnu mnt 25, Viljandi | 15.05.2025 | 31.12.2026 |
| 3 | 101 | Mari Maasikas | Küla tn 8, Rõngu | 01.01.2026 | 31.12.9999 |
Klient_key on surrogaatvõti, millest peaks eraldi rääkima, sest artikkel seda tegelikult ei puuduta. Faktitabel viitab dimensioonile surrogaatvõtme kaudu (klient_key), mitte Kliendi ID-ga. Muidu ei saaks eristada, kas müük toimus Tallinna, Viljandi või Rõngu aadressi ajal. Lühidalt Klient_Key ja Klient ID erinevusest:
| Võti | Näide | Roll |
|---|---|---|
| Ärivõti / naturaalvõti | Kliendi ID = 101 | Sama klient kõigis versioonides — kordub |
| Surrogaatvõti | klient_key = 1, 2, 3 | Iga aadressi versioon on eraldi rida unikaalse võtmega |
SCD tüüp 3 on piiratud ajalooga, lisatakse üks veerg, kus säilitatakse eelmine aadress. Kaugem minevik kaob. Meie klient on vahepeal Rõngu kolinud, nii on selle tüübi puhul näha järgmine kirje:
| Kliendi ID | Nimi | Praegune aadress | Eelmine aadress |
|---|---|---|---|
| 101 | Mari Maasikas | Küla tn 8, Rõngu | Pärnu mnt 25, Viljandi |
Kuskilt teisest artiklist jäi silma, et SCD tüüpe on kokku 8.
Mis on partitsioon?
Naastes taas snapshotide juurde, võimaldavad andmelaod täna partitsioneerimist. Iga päev/kuu,... tehakse selle ajaperioodi snapshote dimensioonitabelite andmetest, et tulla toime andmete muutumisega. Partitsioneerimine tähendabki suure tabeli sees andmete jagamist väiksemateks füüsilisteks osadeks ehk partitsioonideks.
Kui nüüd ülemist osa meenutada, siis arvutusvõimsus ja hoidmine ei maksa midagi. Haldamise, arendamise (andmeinseneeria) ajakulu küll (ka juba täna muutumas?). Dimensioonitabelite andmed on väikesed ja lihtsad võrreldes faktitabelitega, seega nendest snapshotide tegemine, nt kümne aasta taha, on väike andmemaht. Ning analüütikutele annab snapshot ette raamistiku, mis aitab kergemini andmeid mõista. Kokkuvõtteks, andmete hoidmine ei maksa midagi, ja selline "hetke seisudeks" jaotamine aitab pääseda SCD-st, samal ajal säilib kogu ajalugu.
Kas Kimballi lähenemine on täna veel relevantne?
Artikli autorid arvavad, et Kimballi lähenemine jätkuvalt toob kasu tänagi. Küsida tuleb hoopis, kuidas vähendada sellega kaasneva töö mahtu? Nemad arvavad, et modelleerida andmeid tasub ainult siis, kui selleks on tõesti vajadus. Muul juhul kasutada ära arvutusvõimsust, mis lubab paindlikumaid lähenemisviise kastada. Soovitused:
- kui andmed pärinevad su enda süsteemidest, loo raport otse toorandmetest. Eriti siis, kui ei nõua keerulisi päringuid.
- kui nõuab keerukamaid päringuid, modelleeri ainult kõige olulisemad mõõdikud/äriküsimused, ilma mõtlemata tulevikusoovidele.
- kui keerukus veelgi tõuseb, siis mõtle dimensionaalse mudeldamise peale.
Sama andmelao piires andmete teisendamine, uute tabelite loomine on lihtne. Ja mudelit saab alati luua, teisendada vastavalt vajadusele. Kasutada vastavaid tööriistu (dbt, Looker), siis lihtsustub töö veegli. Dbt näiteks jälgib ajas mudelites tehtud muutusi. Samuti genereerivad SQL koodi mudelite loomiseks. Alati tasub küsida, kas seda saab teha tööriist + mingisuguste olemasolevate oskustega inimene või tuleb palgata andmeinsener? Igatahes väga huvitav lugemine.
Allikas: https://www.holistics.io/books/setup-analytics/kimball-s-dimensional-data-modeling/