Vývoj DATA VAULT a prechod na BUSINESS DATA VAULT

V predchádzajúcom článku som hovoril o základoch DATA VAULT, opísal hlavné prvky DATA VAULT a ich účel. Toto nemožno považovať tému DATA VAULT za vyčerpanú, je potrebné sa porozprávať o ďalších krokoch vo vývoji DATA VAULT.

A v tomto článku sa budem venovať vývoju DATA VAULT a prechodu na BUSINESS DATA VAULT alebo jednoducho BUSINESS VAULT.

Dôvody, prečo sa objavil SCHRÁN OBCHODNÝCH ÚDAJOV

Je potrebné poznamenať, že DATA VAULT, hoci má určité silné stránky, nie je bez nevýhod. Jednou z týchto nevýhod je obtiažnosť pri písaní analytických otázok. Dopyty majú značný počet JOINov, kód je dlhý a ťažkopádny. Taktiež údaje vstupujúce do DATA VAULT neprechádzajú žiadnymi transformáciami, preto z obchodného hľadiska nemá DATA VAULT vo svojej čistej forme absolútnu hodnotu.

Práve na odstránenie týchto nedostatkov bola metodika DATA VAULT rozšírená o prvky ako:

  • tabuľky PIT (bod v čase);
  • BRIDGE stoly;
  • PREDDEFINOVANÉ DERIVÁCIE.

Pozrime sa bližšie na účel týchto prvkov.

PIT tabuľky

Typicky môže jeden podnikateľský subjekt (HUB) obsahovať údaje s rôznou rýchlosťou 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-maile majú vyššiu mieru aktualizácie ako napr. celé meno, údaje z pasu, rodinný stav alebo pohlavie.

Pri určovaní satelitov by ste preto mali mať na pamäti ich frekvenciu aktualizácie. Prečo je to dôležité?

Ak v tej istej tabuľke uložíte atribúty s rôznymi rýchlosťami aktualizácie, budete musieť do tabuľky pridať riadok vždy, keď sa aktualizuje najčastejšie zmenený atribút. Výsledkom je zväčšenie miesta na disku a zvýšenie času vykonávania dotazu.

Teraz, keď sme rozdelili satelity podľa frekvencie aktualizácie a môžeme do nich nezávisle načítať dáta, mali by sme zabezpečiť, aby sme mohli prijímať aktuálne dáta. Lepšie, bez použitia zbytočných JOINov.

Dovoľte mi vysvetliť, že napríklad potrebujete získať aktuálne (podľa dátumu poslednej aktualizácie) informácie zo satelitov, ktoré majú rôznu rýchlosť aktualizácie. Aby ste to mohli urobiť, budete musieť nielen vytvoriť JOIN, ale aj vytvoriť niekoľko vnorených dopytov (pre každý satelit obsahujúci informácie) s výberom maximálneho dátumu aktualizácie MAX (Dátum aktualizácie). S každým novým JOINom takýto kód rastie a veľmi rýchlo sa stáva ťažko zrozumiteľným.

Tabuľka PIT je navrhnutá tak, aby takéto dopyty zjednodušila, tabuľky PIT sa plnia súčasne so zápisom nových údajov do DATA VAULT. PIT tabuľka:

Vývoj DATA VAULT a prechod na BUSINESS DATA VAULT

Máme teda informácie o relevantnosti údajov pre všetky satelity v každom časovom bode. Pomocou JOINov do tabuľky PIT dokážeme úplne eliminovať vnorené dopyty, samozrejme s podmienkou, že sa PIT vypĺňa každý deň a bez medzier. Aj keď sú v PIT medzery, najnovšie údaje môžete získať iba pomocou jedného vnoreného dotazu na samotný PIT. Jeden vnorený dopyt spracuje rýchlejšie ako vnorené dopyty na každý satelit.

MOST

Tabuľky BRIDGE sa tiež používajú na zjednodušenie analytických dopytov. Čo sa však od PIT líši, je prostriedok na zjednodušenie a zrýchlenie požiadaviek medzi rôznymi hubmi, prepojeniami 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é, môžu byť hashované obchodné kľúče doplnené kľúčmi v textovej forme, ak sú názvy kľúčov potrebné na analýzu.

Faktom je, že bez použitia BRIDGE bude v procese prijímania údajov nachádzajúcich sa v satelitoch patriacich do rôznych uzlov potrebné urobiť JOIN nielen samotných satelitov, ale aj prepojení spájajúcich uzly.

Prítomnosť alebo neprítomnosť BRIDGE je určená konfiguráciou úložiska a potrebou optimalizovať rýchlosť vykonávania dotazu. Je ťažké prísť s univerzálnym príkladom BRIGE.

PREDDEFINOVANÉ DERIVÁCIE

Ďalším typom objektu, ktorý nás približuje k BUSINESS DATA VAULT, sú tabuľky obsahujúce vopred vypočítané ukazovatele. Takéto tabuľky sú pre podnikanie skutočne dôležité, obsahujú informácie agregované podľa daných pravidiel a uľahčujú ich prístup.

Z architektonického hľadiska nie sú PREDDEFINOVANÉ DERIVÁCIE ničím iným ako ďalším satelitom určitého uzla. Rovnako ako bežný satelit obsahuje obchodný kľúč a dátum vytvorenia záznamu v satelite. Tu sa však podobnosti končia. Ďalšie zloženie atribútov takéhoto „špecializovaného“ satelitu určujú podnikoví používatelia na základe najobľúbenejších, vopred vypočítaných ukazovateľov.

Napríklad hub obsahujúci informácie o zamestnancovi môže obsahovať satelit s indikátormi, ako sú:

  • Minimálna mzda;
  • Maximálny plat;
  • Priemerná mzda;
  • Kumulatívny úhrn časovo rozlíšených miezd atď.

Je logické zahrnúť PREDDEFINOVANÉ DERIVÁCIE do tabuľky PIT toho istého hubu, potom môžete jednoducho získať dátové segmenty pre zamestnanca v konkrétne vybraný dátum.

záver

Ako ukazuje prax, používanie DATA VAULT podnikovými používateľmi je trochu ťažké z niekoľkých dôvodov:

  • Kód dotazu je zložitý a ťažkopádny;
  • Množstvo JOINov ovplyvňuje výkon dopytov;
  • Písanie analytických dopytov si vyžaduje vynikajúce znalosti dizajnu úložiska.

Na zjednodušenie prístupu k údajom je DATA VAULT rozšírený o ďalšie objekty:

  • tabuľky PIT (bod v čase);
  • BRIDGE stoly;
  • PREDDEFINOVANÉ DERIVÁCIE.

Ďalšie článok Plánujem povedať, podľa môjho názoru, to najzaujímavejšie pre tých, ktorí pracujú s BI. Predstavím spôsoby vytvárania tabuliek faktov a tabuliek dimenzií na základe DATA VAULT.

Materiály článku sú založené na:

  • Na Uverejnenie Kenta Graziano, ktorá okrem podrobného popisu obsahuje modelové diagramy;
  • Kniha: „Vybudovanie škálovateľného dátového skladu s DATA VAULT 2.0“;
  • článok Základy dátového trezoru.

Zdroj: hab.com

Pridať komentár