V predchádzajúcom článku som predstavil základy DATA VAULT, opísal hlavné prvky DATA VAULT a ich účel. Témy DATA VAULT sa však nedá považovať za vyčerpanú, je potrebné hovoriť o ďalších krokoch evolúcie DATA VAULT.
A v tomto článku sa zameriam na rozvoj DATA VAULT a prechod k BUSINESS DATA VAULT alebo jednoducho BUSINESS VAULT.
Dôvody vzniku BUSINESS DATA VAULT
Je potrebné poznamenať, že DATA VAULT, hoci má určité silné stránky, nie je bez nedostatkov. Jedným z takých nedostatkov je zložitosti pri písaní analytických dopytov. Dopyty majú značné množstvo JOIN’ov, kód je dlhý a neprehľadný. Taktiež dáta umiestnené do DATA VAULT nie sú podrobené žiadnym transformáciám, preto z pohľadu podnikania má DATA VAULT v ako také bezpodmienečnú hodnotu.
Práve na odstránenie týchto nedostatkov bola metodológia DATA VAULT rozšírená o takéto prvky ako:
- PIT (point in time) tabuľky;
- BRIDGE tabuľky;
- PREDEFINED DERIVATIONS.
Poďme si podrobnejšie rozobrať účel týchto prvkov.
PIT tabuľky
Zvyčajne jeden biznis objekt (HUB) môže obsahovať dáta s rôznou frekvenciou aktualizácie, napríklad, ak hovoríme o údajoch charakterizujúcich osobu, môžeme povedať, že informácie o telefónnom čísle, adrese alebo e-maili majú vyššiu frekvenciu aktualizácie ako povedzme, meno, údaje o pase, rodinný stav alebo pohlavie.
Preto, pri určovaní satelitov, je potrebné mať na pamäti frekvenciu ich aktualizácie. Prečo je to dôležité?
Ak v jednej tabuľke uchovávame atribúty s rôznou frekvenciou aktualizácie, bude potrebné pridať riadok do tabuľky pri každej aktualizácii najčastejšie meneného atribútu. Ako dôsledok – rast objemu diskového priestoru, zvýšenie doby vykonávania dopytov.
Teraz, keď sme rozdelili satelity podľa frekvencie aktualizácie a môžeme do nich nahrávať dáta nezávisle, je potrebné zabezpečiť prístup k aktuálnym dátam. Najlepšie, bez zbytočných JOIN’ov.
Vysvetlím, napríklad, je potrebné získať aktuálne (podľa dátumu poslednej aktualizácie) informácie zo satelitov, ktoré majú rôznu frekvenciu aktualizácie. Na to je potrebné nielen spraviť JOIN, ale aj vytvoriť niekoľko vnorených dopytov (k každému satelitu obsahujúcemu informácie) s výberom maximálneho dátumu aktualizácie MAX(Dátum aktualizácie). S každým novým JOIN-om sa takýto kód rozrastá a veľmi rýchlo sa stáva zložitým na pochopenie.
PIT tabuľka má za cieľ zjednodušiť takéto dopyty, PIT tabuľky sa vypĺňajú zároveň s zapisovaním nových údajov do DATA VAULT. PIT tabuľka:
Takto máme informácie o aktuálnosti údajov zo všetkých satelitov v každom okamihu. Použitím JOIN-ov k PIT tabuľke môžeme úplne vylúčiť vnorené dopyty, samozrejme s podmienkou, že PIT sa vyplňuje každý deň a bez prestávok. Aj keď sa v PIT vyskytnú prestávky, aktuálne údaje môžeme získať len použitím jedného vnoreného dopytu k samotnému PIT-u. Jeden vnorený dopyt bude fungovať rýchlejšie ako vnorené dopyty k každému satelitu.
BRIDGE
Tabuľky typu BRIDGE sa tiež používajú na zjednodušenie analytických dopytov. Rozdielom od PIT je, že slúžia na zjednodušenie a urýchlenie dopytov medzi rôznymi hubmi, linkami a ich satelitmi.
Tabuľka obsahuje všetky potrebné kľúče pre všetky satelity, ktoré sa často používajú v dopytoch. Okrem toho, ak je to potrebné, hashované biznis kľúče môžu byť doplnené kľúčmi v textovej podobe, ak sú názvy kľúčov potrebné pre analýzu.
Ide o to, že bez použitia BRIDGE, pri získavaní údajov nachádzajúcich sa v satelitoch, ktoré patria rôznym hubom, bude potrebné vykonať JOIN nielen samotných satelitov, ale aj linkov, ktoré spájajú huby.
Prítomnosť alebo neprítomnosť BRIDGE je určená konfiguráciou úložiska a potrebou optimalizácie rýchlosti vykonávania dopytov. Univerzálny príklad BRIDGE sa ťažko navrhuje.
PREDEFINED DERIVATIONS
Ďalším typom objektov, ktorý nás približuje k BUSINESS DATA VAULT, sú tabuľky obsahujúce vopred vypočítané ukazovatele. Takéto tabuľky sú skutočne dôležité pre biznis, obsahujú informácie, agregované podľa stanovených pravidiel a umožňujú k nim prístup relatívne jednoducho.
Architektonické PREDEFINED DERIVATIONS predstavujú len ďalší satelit určitého hubu. Obsahuje, rovnako ako bežný satelit, obchodný kľúč a dátum vytvorenia záznamu v satelite. Tým to však podobnostiam končí. Ďalší sklad atribútov takéhoto „špecializovaného“ satelitu určujú obchodní používatelia na základe najžiadanejších, predbežne vypočítaných ukazovateľov.
Napríklad, hub obsahujúci informácie o zamestnancovi môže obsahovať satelit s takýmito ukazovateľmi, ako sú:
- Minimálny plat;
- Maximálny plat;
- Priemerný plat;
- Kumulovaný súčet vyplatených platov atď.
Je logické, že by sa PREDEFINED DERIVATIONS malo zahrnúť do PIT tabuľky tohto istého hubu, čím by sa bez problémov získali výseky údajov o zamestnancovi na konkrétne zvolený dátum.
ZÁVER
Ako ukazuje prax, používanie DATA VAULT obchodnými používateľmi je trochu problematické z niekoľkých dôvodov:
- Kód dotazov je zložitý a rozmerný;
- Hojnosť JOIN-ov ovplyvňuje rýchlosť dotazov;
- Na písanie analytických dotazov je potrebné výnimočné poznanie štruktúry úložiska.
Aby sa zjednodušil prístup k údajom, DATA VAULT sa rozširuje dodatočnými objektmi:
- PIT (point in time) tabuľky;
- BRIDGE tabuľky;
- PREDEFINED DERIVATIONS.
V nasledujúcom Plánujem rozprávať o tom, čo považujem za najzaujímavejšie, pre tých, ktorí pracujú s BI. Predstavím spôsoby vytvárania tabuliek – faktov a tabuliek – dimenzií na báze DATA VAULT.
Materiály článku sú založené na:
- Na Kenta Graciano, kde okrem podrobného popisu sú obsiahnuté aj schémy modelu;
- Knihe: „Building a Scalable Data Warehouse with DATA VAULT 2.0“;
- Článok .
Zdroj: habr.com
