Razvoj DATA VAULT-a i prelazak na BUSINESS DATA VAULT

U prethodnom članku sam govorio o osnovama DATA VAULT-a, opisao osnovne elemente DATA VAULT-a i njihovu svrhu. Međutim, ova tema se ne može smatrati iscrpljenom; potrebno je razgovarati o narednim fazama evolucije DATA VAULT-a.

U ovom članku ću se fokusirati na razvoj DATA VAULT-a i prelazak na BUSINESS DATA VAULT ili jednostavno BUSINESS VAULT.

Razlozi za pojavu BUSINESS DATA VAULT-a

Treba napomenuti da, iako DATA VAULT ima određene prednosti, nije bez nedostataka. Jedan od takvih nedostataka je složenost pisanja analitičkih upita. Upiti sadrže značajan broj JOIN-ova, a kod postaje dug i nezgrapan. Takođe, podaci koji ulaze u DATA VAULT ne podležu nikakvim transformacijama, pa DATA VAULT u svom čistom obliku nema neospornu vrednost iz poslovne perspektive.

Upravo kako bi se uklonili ovi nedostaci, metodologija DATA VAULT-a je proširena s elementima kao što su:

• PIT (point in time) tabele;
• BRIDGE tabele;
• PREDEFINED DERIVATIONS.

Hajde da detaljnije razmotrimo svrhu ovih elemenata.

PIT tabele

Obično jedan poslovni objekat (HUB) može sadržavati podatke s različitim frekvencijama osvežavanja. Na primer, kada govorimo o podacima koji opisuju osobu, možemo reći da informacije o broju telefona, adresi ili e-pošti imaju veću frekvenciju osvežavanja nego, recimo, ime i prezime, podaci o pasošu, bračno stanje ili pol.

Stoga, prilikom određivanja satelita, treba voditi računa o frekvenciji njihovog osvežavanja. Zašto je to važno?

Ako se u jednoj tabeli čuvaju atributi s različitim frekvencijama osvežavanja, moraćete dodavati red u tabelu pri svakoj promeni najčešće menjane atribute. Kao posledicu imamo – rast prostora na disku i produženo vreme izvođenja upita.

Sada, kada smo podelili satelite prema frekvenciji osvežavanja, možemo ih učitavati nezavisno, trebamo obezbediti mogućnost dobijanja ažuriranih podataka. Bolje je, bez upotrebe suvišnih JOIN-ova.

Na primer, potrebno je dobiti ažurirane (po datumu poslednjeg ažuriranja) informacije iz satelita koji imaju različitu učestalost ažuriranja. Za to nije dovoljno samo napraviti JOIN, već je potrebno kreirati nekoliko ugniježdenih upita (za svaki satelit koji sadrži informacije) sa izborom maksimalnog datuma ažuriranja MAX(Datum ažuriranja). Sa svakim novim JOIN-om, ovaj kod se širi i vrlo brzo postaje složen za razumevanje.

PIT tabela ima zadatak da pojednostavi takve upite, a PIT tabele se popunjavaju istovremeno sa unosom novih podataka u DATA VAULT. PIT tabela:

Dakle, imamo informacije o aktuelnosti podataka za sve satelite u svakom trenutku. Koristeći JOIN-ove sa PIT tabelom, možemo potpuno isključiti ugniježdene upite, naravno pod uslovom da se PIT popunjava svaki dan i bez preskočenih unosa. Čak i ako su u PIT-u prisutni preskočeni unosi, aktuelne podatke možemo dobiti koristeći samo jedan ugniježdeni upit prema samom PIT-u. Jedan ugniježdeni upit će raditi brže od ugniježdenih upita za svaki satelit.

BRIDGE

Tabele tipa BRIDGE takođe se koriste za pojednostavljanje analitičkih upita. Međutim, razlika od PIT-a je da služi za pojednostavljenje i ubrzanje upita između različitih hubova, veza i njihovih satelita.

Tabela sadrži sve potrebne ključeve za sve satelite koji se često koriste u upitima. Pored toga, ako je potrebno, heširani poslovni ključevi mogu se dopuniti ključevima u tekstualnom formatu, ukoliko su imena ključeva potrebna za analizu.

Pitanje je da, bez korišćenja BRIDGE-a, prilikom dobijanja podataka iz satelita koji pripadaju različitim hubovima, trebalo bi izvršiti JOIN ne samo između samih satelita, već i veza koje povezuju hubove.

Prisutnost ili odsustvo BRIDGE-a određuje konfiguracija skladišta, kao i potreba za optimizacijom brzine izvršenja upita. Teško je izmisliti univerzalni primer BRIDGE-a.

PREDEFINED DERIVATIONS

Još jedan tip objekata koji nas približava BUSINESS DATA VAULT-u su tabele koje sadrže unapred izračunate pokazatelje. Ove tabele su zaista važne za biznis, sadrže informacije agregirane prema zadatim pravilima i omogućavaju relativno jednostavan pristup ovim podacima.

Arhitekturne PREDEFINED DERIVATIONS predstavljajo še en satelit določenega vozlišča. Tako kot običajni satelit vsebuje poslovni ključ in datum oblikovanja zapisa v satelitu. S tem pa se podobnosti končajo. Nadaljnji sestav atributov takšnega "specializiranega" satelita določajo poslovni uporabniki na podlagi najbolj iskane, vnaprej izračunane kazalnike.

Na primer, vozlišče, ki vsebuje informacije o zaposlenem, lahko vključuje satelit s takimi kazalniki, kot so:

• Minimalna plača;
• Maksimalna plača;
• Povprečna plača;
• Kumulativni skupni znesek izplačane plače itd.

Logično je vključiti PREDEFINED DERIVATIONS v sestavo PIT tabele tega istega vozlišča, saj lahko brez težav pridobimo preseke podatkov o zaposlenem na izbrani datum.

POVZETEK

Kot kaže praksa, je uporaba DATA VAULT za poslovne uporabnike nekoliko zapletena iz več razlogov:

• Koda poizvedb je zapletena in obsežna;
• Obilo JOIN'ov vpliva na hitro izvajanje poizvedb;
• Za pisanje analitičnih poizvedb je potrebno izjemno poznavanje strukture skladišča.

Da bi poenostavili dostop do podatkov, se DATA VAULT razširja z dodatnimi objekti:

• PIT (point in time) tabele;
• BRIDGE tabele;
• PREDEFINED DERIVATIONS.

V nasledujúcej članku Namreč, nameravam predstaviti, po mojem mnenju, najbolj zanimivo, za tiste, ki delajo z BI. Predstavljal bom načine ustvarjanja tabel - dejstev in tabel - meritev na osnovi DATA VAULT.

Gradiva v članku temeljijo na:

• Na publication Kenta Grazianno, ki poleg podrobnega opisa vsebuje tudi sheme modela;
• Knjigi: "Building a Scalable Data Warehouse with DATA VAULT 2.0";
• na Lifehackerju. Osnove Data Vault.

Izvor: habr.com