Preden začnete kakršen koli BI projekt v kateremkoli drugem BI orodju, je pomembno razumeti koncept podatkovnega modeliranja. V laičnem jeziku lahko rečete, da modeliranje podatkov ni nič drugega kot način povezave različnih tabel, da dobite potrebno analizo. Na voljo so različne tehnike modeliranja podatkov, od katerih je vsaka primerna za določeno vrsto zahteve.

Modeliranje podatkov je zelo pomembno za vsak BI projekt, saj pri tem raziskujete logični odnos med različnimi atributi poslovanja. Pomaga vam predstaviti različne vidike poslovanja in najti povezavo med njimi. Tako modeliranje postane pomemben del BI projektov, kjer želite videti pravo povezavo med različnimi atributi in njihov vpliv drug na drugega.

Zakaj?

Če vložite malo truda v podatkovni model, pripomorete k boljšemu razumevanju, lažjemu vzdrževanju in kasnejšemu razvoju oz. razširitvi podatkov. Z dobro pripravljenim podatkovnim modelom prihranite veliko časa pri razvoju in pripravi samih vizualizacij (»front-end«), izboljšate samo delovanje aplikacij in seveda lahko posamezne komponente ponovno uporabite.

Med številnimi razpoložljivimi tehnikami za modeliranje podatkov je za analitične projekte najprimernejše dimenzijsko modeliranje. Dimenzijsko modeliranje je tehnika, pri kateri podatke preoblikujemo in shranimo v denormalizirani obliki. Razlog za denormalizacijo podatkov je v tem, da omogoča boljše poizvedbe pri uporabi ogromne količine podatkov. Zato večina BI orodij uporablja dimenzijsko modeliranje za boljše delovanje svojih aplikacij.

Preden pa začnemo z denormalizacijo, si na hitro oglejmo normalizacijo: postopek organiziranja polj in tabel v relacijski podatkovni bazi za zmanjšanje redundance in odvisnosti.

• Prva normalna oblika: polja so atomska nedeljiva, brez seznamov ali množic. Več si lahko preberete tukaj.
• Druga normalna oblika: vsa polja so odvisna od celotnega  kandidatnega (»UNIQUE«- unikatnega) ključa. Več si lahko preberete tukaj.
• Tretja normalna oblika: vsak atribut, ki ni ključ, mora vsebovati dejstvo o ključu, celotnem ključu in nič drugega kot ključ. Več si lahko preberete tukaj.

Spodaj na sliki je primer realcijskega modela.

Dimenzijsko modeliranje  je enostavno, saj vključuje manjše število povezav med tabelo v primerjavi z ER (entity relationship oz. entitetno-relacijski) podatkovnim modeliranjem. Zaradi tega je takšen model hitreje narejen in enostavnejši za spreminjanje. Model je mogoče enostavno razširiti po potrebi.

Pojmi, ki jih pri dimenzijskem modeliranju uporabljamo, so:

• Tabele dejstev (»Fact tables«) niso nič drugega kot tabele, ki se uporabljajo za shranjevanje poslovnih transakcij. Hranijo podatke meritev, ki nastanejo kot rezultat poslovanja: koliko smo prodali, koliko obiskov se je zgodilo, … Tabele o dejstvih imajo nekatere značilnosti, kot so:
  • Shranjevanje večinoma merjencev, ki so po naravi numerični.
  • Shranjevanje tujih ključev(foreign key), ki se povezujejo na tabele dimenzij.

• Dimenzijske tabele (»Dimension tables«) so tiste, ki hranijo podrobne informacije o tabelah z dejstvi. Večinoma so podatki, ki so shranjeni v dimenzijskih tabelah, opisne narave in opisujejo lastnosti tabele dejstev: kategorije, barve, poštne številke, artikli, datum in čas, … Tabele dimenzij so po naravi denormalizirane in zaradi tega vsebujejo večje število stolpcev kot tabele z dejstvi. Značilnosti dimenzijskih tabel so:
  • Shranjujejo tekstovne podatke (To ne pomeni, da ne morejo shranjevati številskih podatkov opisnega značaja, kot so na primer poštne številke).
  • Shranjujejo atribute tabel dejstev.
  • V primerjavi s tabelami  dejstev so majhne (glede na število vrstic).

PRAKSA
V praksi se uporabljata se predvsem dve strukturi dimenzijskega modeliranja:

Zvezdna shema 

Zvezdna shema (Star schema) je široko uporabljena metoda dimenzijskega modeliranja v podatkovnih skladiščih. V tej tehniki modeliranja je ena ali več tabel dejstev, ki so obdane in povezane s tabelami dimenzij. Naslednja slika prikazuje vzorec zvezde sheme:

Zvezdna shema je dobila zaradi videza po povezavi tabel z dejstvi s tabelami dimenzij. Kot lahko vidite na sliki, res izgleda kot zvezda.

Snežinka 

Shemo snežinke (snowflake schema) se uporablja, kadar želimo shemo normalizirati. To je potrebno, kadar raziskujemo podatke (data mining oz data discovery). To niso nič drugega kot modeli zvezdne sheme z dimenzijskimi tabelami, ki so dodatno normalizirani. Naslednja slika prikazuje vzorec sheme snežinke:

Na koncu pridemo do ene same TABELE

Seveda pa se denormalizacija tukaj ne konča in na koncu pridemo dejansko do ene same tabele, ki vsebuje vse potrebne podatke – single table:

Denormalizacija, koliko do kam v Qlik Sense?

Če je denormalizacija tabel v zvezdno shemo dobra, mora biti sploščenje celotnega modela v eno tabelo in odstranitev vseh povezav še boljša, kajne? Na splošno je za modeliranje podatkov v Qlik Sense najbolj primerna Zvezdna shema, ker Qlik Sense zaradi svojega posebnega načina dela najbolje deluje z denormaliziranimi tabelami.

Točno te trditve oz. provokativnega vprašanja g. Barrya Harmsena pa se spomnim tudi iz srečanja Qlik Masters Summit v Stockholmu, ko smo se pogovarjali o denormalizaciji podatkovnih modelov. Odgovor je bil: »It depends!« Odvisno je od tega kakšne podatke imate, koliko jih je, kakšna je strojna infrastruktura in ali točno veste kaj želite iz podatkov dobiti in kakšni so ti podatki.

Denormalizacija celotnega podatkovnega modela v eno tabelo ponavadi prinese hitrejše delovanje, vendar gre to na račun večje porabe pomnilnika (tako RAM-a kot diska), pa tudi skripte in kalkulacije je navadno težje ustvariti in vzdrževati. Spodnja tabela prikazuje primerjavo shem z vidika Qlik Sense projektov:

Torej »it depends!«. Imejmo to v mislih ko načrtujemo podatkovni model in izbiramo stopnjo denormalizacije v Qlik Sense projektih.

Naslednjič pa nekaj o tem kako se denormalizacije lotiti v Qlik Sense, na konkretnem primeru.

Ne spreglejte sorodnih člankov