Architektura DW podle Ralpha Kimballa

V minulém čísle jsme si podrobněji popsali architekturu datového skladu, kterou navrhl Bill Inmon. Tato architektura je z...


V minulém čísle jsme si podrobněji popsali architekturu datového skladu, kterou
navrhl Bill Inmon. Tato architektura je založena na centrálním data warehousu a
závislých data martech, jejichž zdrojem dat je právě celopodnikový DW.
Druhý, odlišný přístup pochází od zakladatele dimenzionálního modelování,
Ralpha Kimballa. Jeho idea, že data warehouse může být vybudován inkrementálně
pomocí série jednotlivých data martů s odpovídajícími dimenzemi, pochází z roku
1996. Další popisy této architektury se objevily v literatuře o rok později. V
následujícím textu se budeme podrobněji zabývat přístupem, který Kimball
pojmenoval jako "BUS data warehouse architektura".
V každém podniku jsou definovány obchodní aktivity, které jsou prováděny
jednotlivými zaměstnanci. Obchodní aktivitu budeme chápat jako proces, který je
tvořen konečnou množinou elementárních aktivit, které mohou vytvářet logické
celky. Některé z obchodních aktivit přesahují definici individuálního procesu a
mohou procházet napříč celou organizací. Proto je potřeba zajistit určitou
koherenci údajů používaných v rámci jednotlivých procesů. Od tohoto požadavku
se postupně dostáváme k pojmům "odpovídající dimenze" (Conformed Dimensions CD)
a "odpovídající fakta" (Conformed Facts CF). Tyto dimenze a fakta představují
základ BUS architektury.
Definice DW
Pro úplnost si připomeňme definici data warehousu dle Kimballa, neboť
představuje pomyslnou červenou nit, která bude prostupovat celým článkem.
Kimballova definice říká, že data warehouse není nic jiného než sjednocení
jednotlivých data martů s odpovídajícími dimenzemi (nebo též celopodnikovými
dimenzemi).
V praxi se setkáváme s tím, že v podnicích jsou budovány jednotlivé data marty,
avšak poměrně často jsou opomíjeny "BUS" prvky CD a CF. Jestliže tyto prvky
nejsou zaintegrovány do budování DW, pak vybudujeme data marty, které není
možné v budoucnu sjednotit do DW. To má také za následek to, že data mezi
jednotlivými data marty jsou v takových případech nekonzistentní.
Data je potřebné před jejich umístěním do jednotlivých data martů extrahovat z
produkčních systémů, vyčistit, formátovat, odstranit duplicity a kombinovat. K
tomuto účelu slouží "Data Staging Area" (záchytná oblast), která je v ideálním
případě umístěna na jednom serveru. V praxi se ovšem stává, že DSA je umístěna
na několika serverech.
Zmínili jsme se o všech prvcích architektury BUS tj. data martu, DSA,
produkčních systémech a data warehousu. Pokud spojíme jednotlivé stavební prvky
do logického celku, dostaneme schéma znázorněné na obr. 1. Obrázek však
nezachycuje úplnou architekturu DW, neboť na něm není vyznačena poslední
vrstva, kterou jsou uživatelské koncové nástroje např. pro OLAP, ROLAP, MOLAP,
MDDB, ad-hoc apod. Pro dokreslení představy o úplné BUS architektuře doplníme
vrstvu koncových uživatelských nástrojů (obr. 2). Obrázek zachycuje data
warehouse, který odpovídá Kimballově definici.
Z výše uvedeného vyplývá, že jádrem a také kritickým místem ovlivňujícím
úspěšnost implementace DW podle popsané architektury jsou celopodnikové dimenze
a celopodniková fakta. Podívejme se na to, jak problematiku BUS prvků řeší
metodika budování DW a jak jsou tyto prvky spravovány. Naším úkolem není popsat
kompletní metodiku, ale poukázat na to, co je potřeba udělat pro zavedení a
správu celopodnikových dimenzí a faktů.
Celopodnikové dimenze
Prvním a velmi důležitým krokem je definice pojmů (dimenzí a faktů), což má
značný dopad na granularitu a dimenzionalitu datového modelu použitého pro
návrh databáze. Kimball předpokládá, že všechny data marty jsou navrženy pomocí
dimenzionálního modelování.
V praxi se setkáváme s tím, že určité slovo má několik významů. Tato slova jsou
potom používána pro tu samou věc, přičemž jejich definice jsou rozdílné. S
tímto stavem se setkáváme u těch organizací, kde si jednotlivé podnikové útvary
budovaly své vlastní data marty. Ve chvíli, kdy řešíme problém slučování těchto
data martů, projeví se nutnost existence a dodržování celopodnikových dimenzí a
faktů.
V etapě získávání uživatelských požadavků jsou prováděna interview za účelem
definování právě těchto BUS prvků. Doporučuje se, aby tato interview byla
prováděna horizontálně napříč organizací a aby se definice jednotlivých pojmů
nediskutovala na hromadném interview. Také je potřebné, aby analytici měli
velmi dobrou znalost prostředí, pro něž má být datový sklad implementován.
Co tedy jsou celopodnikové dimenze a fakta? Celopodniková dimenze je dimenzí,
která představuje jednu a tu samou věc pro všechna pravděpodobná odpovídající
fakta, s nimiž může být sama spojena. Obecně řečeno, představuje např.
skutečnost, že dimenze jsou identicky stejné v každém jednotlivém data martu, a
to co do struktury i obsahu. Příkladem celopodnikových dimenzí jsou např.
zákazník, produkt, lokalita, kalendář apod.
Bez definování správy dimenzí nemůže výsledný data warehouse fungovat jako
jeden celek. Proto je nutné, aby tvorba "BUS" prvků byla podporována nejvyšším
stupněm řízení organizace.
Definice faktů
Podobně jako v případě dimenzí je potřebné zajistit, aby jednotlivé data marty
poskytovaly stejné hodnoty pro standardní fakta, která procházejí napříč
organizací. Mezi celopodniková fakta můžeme např. zařadit zisk, plán, a další.
Pokud se není možné domluvit na jednotné definici dimenzí, je nutné definovat
synonyma pro příslušná fakta.
Správa dimenzí
V další části článku se zaměříme na popis způsobu správy a distribuce "BUS"
prvků, speciálně celopodnikových dimenzí. Celopodnikové dimenze představují
určité datové tabulky, které mají stejný význam ve všech data martech nejen co
do databázové struktury, ale i co do obsahu dat.
Častou otázkou je správa těchto dimenzí například v heterogenním prostředí,
pokud používáme BUS DW architekturu. Pro tyto účely je nejvhodnější definovat
tzv. CD data mart (CDDM), který se integruje do BUS data warehouse
architektury, viz obr. 3.
CDDM má několik vrstev:
vstupní záchytná oblast (Data Staging Area)
procesy tvorby jednotlivých data martů
CD repository
výstupní záchytná oblast (DSA)
distribuční vrstva
Následující obrázek (obr. 4) zachycuje jednotlivé vrstvy CD data martu. CDDM
představuje samostatný data mart, který získává data z tzv. záchytné oblasti
(DSA), do níž jsou data z produkčních systémů ukládána pomocí extrakce. DSA je
vrstvou, která slouží pro ETT procesy, tj. je určena pro čištění, validaci,
transformaci, odstraňování duplicit apod. Podívejme se ale, k čemu slouží
jednotlivé oblasti.
1. Vstupní záchytná oblast (CDDM-1)
Do této vrstvy vstupují data z DSA a jsou zde uložena. Vstupní vrstva CDDM
dovoluje případný restart nebo návrat k původnímu stavu. Data nejsou v této
vrstvě ukládána do dimenzionálních modelů.
2. Procesní vrstva (CDDM-2)
Vrstva obsahující množinu procesů, které jsou spojeny s tvorbou jednotlivých
data martů či s aktualizací již existujících. Data v nově vytvořeném DM jsou
ukládána do vrstvy CDDM-4 a odtud do CDDM-5. V případě, že nově vznikající DM
obsahuje dimenzi, která není zahrnuta v repository, pak ji sem musíme přidat.
Pokud došlo ke změnám v dimenzích, pak provedeme v repository update
odpovídajících dimenzionálních tabulek.
3. Repository (CD-Rep)
Repository slouží jako úložiště pro správu jednotně definovaných dimenzí.
Používání těchto dimenzí pomáhá redukovat čas a finanční prostředky zahrnuté do
výstavby nového data martu.
4. Výstupní záchytná oblast (CDDM-4)
Data pro nově vytvořené DM jsou uložena do výstupní záchytné oblasti, kde jsou
uchována po dobu distribuce dat z vrstvy CDDM-5. Vrstvu CDDM-4 můžeme použít
pro různé kalkulace. Možnost kalkulací v této vrstvě může mít za následek
snížení kapacitních nároků na PC koncového uživatele a tím i redukci potřebných
finančních nákladů.
5. Distribuční vrstva (CDDM-5)
Po skončení procesů v CDDM-4 jsou data převedena do CDDM-5 a odtud jsou dále
distribuována do jednotlivých DM.
Závěrem
Seznámili jsme se teorií Ralpha Kimballa na budování datových skladů, to jest
budování pomocí inkrementálního přístupu. Poukázali jsme na problematiku správy
celopodnikových dimenzí a jejich zásadní význam pro BUS architekturu. Příště už
opustíme oblast přístupů k budování data warehousu a budeme se věnovat
problematice personálního zabezpečení projektů v oblasti DW.

9 1642 / ramn









Komentáře
K tomuto článku není připojena žádná diskuze, nebo byla zakázána.