Vývoj DATA VAULT a přechod na BUSINESS DATA VAULT

V předchozím článku jsem hovořil o základech DATA VAULT, popsal hlavní prvky DATA VAULT a jejich účel. V tuto chvíli nelze považovat téma DATA VAULT za vyčerpané, je nutné hovořit o dalších krocích ve vývoji DATA VAULTU.

A v tomto článku se zaměřím na vývoj DATA VAULT a přechod na BUSINESS DATA VAULT nebo prostě BUSINESS VAULT.

Důvody pro vznik BUSINESS DATA VAULT

Je třeba poznamenat, že DATA VAULT, který má určité silné stránky, není bez nedostatků. Jednou z těchto nevýhod je obtížnost psaní analytických dotazů. Dotazy mají značný počet JOINů, kód je dlouhý a těžkopádný. Rovněž data, která vstupují do DATA VAULTU, nepodléhají žádným transformacím, proto z obchodního hlediska nemá DATA VAULT ve své čisté podobě žádnou bezpodmínečnou hodnotu.

Právě pro odstranění těchto nedostatků byla metodika DATA VAULT rozšířena o prvky jako:

  • tabulky PIT (point in time);
  • Stoly BRIDGE;
  • PŘEDDEFINOVANÉ DERIVACE.

Podívejme se blíže na účel těchto prvků.

PIT tabulky

Zpravidla může jeden obchodní objekt (HUB) obsahovat data s různou rychlostí aktualizace, například pokud mluvíme o datech charakterizujících osobu, můžeme říci, že informace o telefonním čísle, adrese nebo emailu mají vyšší rychlost aktualizace než řekněme celé jméno, údaje z pasu, rodinný stav nebo pohlaví.

Při určování satelitů je proto třeba mít na paměti frekvenci jejich obnovy. Proč je to důležité?

Pokud do stejné tabulky uložíte atributy s různou rychlostí aktualizace, budete muset do tabulky přidat řádek pokaždé, když se aktualizuje nejčastěji měněný atribut. V důsledku toho dochází ke zvýšení množství místa na disku, prodloužení doby provádění požadavků.

Nyní, když jsme družice oddělili podle rychlosti aktualizace a můžeme do nich nezávisle načítat data, musíme zajistit, abychom mohli získat aktuální data. Lepší bez použití zbytečných JOINů.

Dovolte mi vysvětlit, že například potřebujete získat aktuální (k datu poslední aktualizace) informace ze satelitů s různou rychlostí aktualizace. K tomu budete muset nejen provést JOIN, ale také vytvořit několik vnořených dotazů (pro každý satelit obsahující informace) s výběrem maximálního data aktualizace MAX (Update date). S každým novým JOINem takový kód roste a velmi rychle se stává obtížně srozumitelným.

Tabulka PIT je navržena tak, aby takové dotazy zjednodušila, tabulky PIT se naplňují současně se zápisem nových dat do DATA VAULT. PIT tabulka:

Vývoj DATA VAULT a přechod na BUSINESS DATA VAULT

Máme tak informace o relevanci dat pro všechny satelity v každém okamžiku. Pomocí JOINů na tabulce PIT můžeme zcela eliminovat vnořené dotazy, samozřejmě s podmínkou, že se PIT plní každý den a bez mezer. I když jsou v PIT mezery, aktuální data můžete získat pouze pomocí jednoho vnořeného dotazu do samotného PIT. Jeden vnořený dotaz bude fungovat rychleji než vnořené dotazy pro každý satelit.

MOST

Tabulky BRIDGE se také používají ke zjednodušení analytických dotazů. Rozdíl oproti PIT je však prostředkem pro zjednodušení a zrychlení požadavků mezi různými huby, spoji a jejich satelity.

Tabulka obsahuje všechny potřebné klíče pro všechny satelity, které se často používají v dotazech. V případě potřeby lze navíc hashované obchodní klíče doplnit o klíče v textové podobě, pokud jsou názvy klíčů potřebné pro analýzu.

Faktem je, že bez použití BRIDGE bude v procesu získávání dat umístěných v satelitech patřících do různých hubů nutné PŘIPOJIT nejen satelity samotné, ale také spoje spojující huby.

Přítomnost nebo nepřítomnost BRIDGE je určena konfigurací úložiště, potřebou optimalizovat rychlost provádění dotazu. Je těžké přijít s univerzálním příkladem BRIGE.

PŘEDDEFINOVANÉ DERIVACE

Dalším typem objektů, které nás přibližují k BUSINESS DATA VAULT, jsou tabulky obsahující předem vypočítané ukazatele. Takové tabulky jsou pro podnikání opravdu důležité, obsahují informace agregované podle daných pravidel a umožňují relativně snadný přístup.

Z architektonického hlediska nejsou PŘEDDEFINOVANÉ DERIVACE nic jiného než další satelit určitého uzlu. Stejně jako běžný satelit obsahuje obchodní klíč a datum vytvoření záznamu v satelitu. Tím však podobnosti končí. Další složení atributů takového „specializovaného“ satelitu určují firemní uživatelé na základě nejoblíbenějších, předem vypočítaných ukazatelů.

Například centrum obsahující informace o zaměstnanci může zahrnovat satelit s indikátory, jako jsou:

  • Minimální mzda;
  • Maximální plat;
  • Průměrná mzda;
  • Kumulativní součet naběhlých mezd atd.

Je logické zahrnout PŘEDDEFINOVANÉ DERIVACE do tabulky PIT stejného hubu, pak můžete snadno získat datové řezy zaměstnanců pro konkrétní datum.

Závěr

Jak ukazuje praxe, použití DATA VAULT firemními uživateli je poněkud obtížné z několika důvodů:

  • Kód dotazu je složitý a těžkopádný;
  • Množství JOINů ovlivňuje výkon dotazů;
  • Psaní analytických dotazů vyžaduje vynikající znalost struktury skladu.

Pro zjednodušení přístupu k datům je DATA VAULT rozšířen o další objekty:

  • tabulky PIT (point in time);
  • Stoly BRIDGE;
  • PŘEDDEFINOVANÉ DERIVACE.

další článek Plánuji říct, podle mého názoru, to nejzajímavější pro ty, kteří pracují s BI. Uvedu způsoby tvorby tabulek - fakta a tabulky - dimenze na základě DATA VAULT.

Materiály článku jsou založeny na:

  • Na Uveřejnění Kenta Graziano, která kromě podrobného popisu obsahuje modelová schémata;
  • Kniha: "Building a Scalable Data Warehouse with DATA VAULT 2.0";
  • Článek Základy datového trezoru.

Zdroj: www.habr.com

Přidat komentář