Když zahajujeme projekt datového skladu, první věc, kterou uděláme, je definování rozměrových tabulek. Rozměrové tabulky jsou zajímavými prvky, rámcem, na kterém stavíme naše měření. Přicházejí v mnoha tvarech a velikostech. V tomto článku se podíváme blíže na každý typ rozměrové tabulky.
Rozměrové tabulky poskytují kontext pro obchodní procesy, které chceme měřit. Řeknou nám vše, co o události potřebujeme vědět. Protože dávají podstatu měřením (tj. tabulkám faktů) systému datového skladu (DWH), věnujeme jejich definici a identifikaci více času než kterýmkoli jiným aspektem projektu. Tabulky faktů definují měření; rozměrové tabulky dávají kontext. (Chcete-li si přečíst více o tabulkách faktů, podívejte se na tyto příspěvky o datových skladech, hvězdném schématu, schématu sněhových vloček a faktech o tabulkách faktů).
Hlavní charakteristikou tabulek dimenzí je jejich množství atributů . Atributy jsou sloupce, které shrnujeme, filtrujeme nebo agregujeme. Mají nízkou mohutnost a jsou obvykle textové a časové. Dimenzionální tabulky mají jeden primární klíč založený na základním obchodním klíči nebo náhradním klíči . Tento primární klíč je základem pro připojení tabulky dimenzí k jedné nebo více tabulkám faktů.
Ve srovnání s tabulkami faktů jsou tabulky rozměrů malé, snadno se skladují a mají malý vliv na výkon.
Pojďme se nyní podívat na některé tabulky dimenzí, se kterými se setkáte v prostředí datového skladu.
Tabulka společných rozměrů:Přizpůsobená dimenze
Začneme základním typem:konformní dimenze. Ty obsahují více atributů, které mohou být adresovány v několika zdrojových tabulkách, ale které odkazují na stejnou doménu (zákazník, smlouva, dohoda atd.) Přizpůsobené dimenze se používají s mnoha fakty a měly by být jedinečné pro hodnotu zrna/domény v datovém skladu.
Příklad:
Podívejme se na typickou rozměrovou tabulku DIM_CUSTOMER .
Definujeme:
id– Primární klíč tabulky dimenzí.cust_natural_key– Přirozený klíč pro zákazníka.first_name– Křestní jméno zákazníka.last_name– Příjmení zákazníka.address_residence– adresa bydliště zákazníka.date_of_birth– Datum narození zákazníka.marital_status– Je zákazník ženatý? Definováno jako Y (ano) nebo N (ne).gender– Pohlaví zákazníka, M (muž) nebo F (žena).
Atributy tabulky dimenzí závisí na obchodních potřebách. Tento typ tabulky můžeme rozšířit tak, aby obsahovala informace specifické pro odvětví (datum výchozího nastavení, aktivita atd.)
Pomaly se měnící rozměrové tabulky
Jak plyne čas, dimenze mohou měnit své hodnoty. V následujících odstavcích prozkoumáme dimenze klasifikované podle toho, jak ukládají (nebo neukládají) historická data.
Řekněme, že máte zákaznický rozměr. Některé atributy se pravděpodobně během života zákazníka změní – např. telefonní číslo, adresa, rodinný stav atd. Tento typ tabulky Ralph Kimball nazývá pomalu se měnící dimenzí neboli SCD.
SCD se dodává v mnoha typech; osm z nich je poměrně běžných. Z nich nejčastěji uvidíte typy 0 až 4; typy 5, 6 a 7 jsou hybridy prvních pěti. (Poznámka:Schéma číslování těchto SCD začíná 0 místo 1.)
Hybridní SCD poskytují větší flexibilitu a lepší výkon, ale za cenu jednoduchosti. Tyto typy tabulek používáme, když potřebujeme provést analytickou analýzu aktuálního data s nějakou historií úvahy.
SCD typ 0:Plnění jednou
Toto je nejzákladnější typ tabulky dimenzí:vyplníte ji jednou a nikdy naplňte znovu. Považujte to za referenční údaj. Typickým příkladem je rozměr data. Tento rozměr nemusíme vyplňovat při každém zatížení DWH. Rozměrová tabulka se časem nemění. Nemůžete získat další data ani je změnit.
Tabulka faktů se připojuje k původním atributům dimenze.
Příklad
Podívejme se na časovou dimenzi:
Struktura je docela jednoduchá:
id– Náhradní klíčtime_date– Skutečné datumtime_day– Den v měsícitime_week– Týden v rocetime_month– Měsíc v rocetime_year– Číselné vyjádření roku
SCD typ 1:Přepisování dat
Jak název napovídá, tento typ rozměrové tabulky přepisujeme s každým zatížením DWH. Nemusíme uchovávat jejich historii, ale očekáváme, že dojde k určitým změnám.
Rozdíl mezi SCD typu 0 a typem 1 není ve struktuře tabulky. Souvisí to s obnovou dat. Data v typu 0 nikdy neobnovujete, ale v typu 1 to někdy ano.
Přepisovatelná tabulka je nejjednodušší způsob zpracování změn (mazání/vkládání), ale přináší malou obchodní hodnotu. Jakmile definujete tabulku dimenzí, jako je tato, je obtížné nainstalovat historické trasování.
Tabulka faktů se připojuje k aktuálním atributům dimenze.
Příklad
Podívejme se na dimenzi účtu:
Jeho struktura je následující:
id– Zástupný klíč tabulkyaccount_name– Název účtuaccount_type– Kategorie účtuaccount_activity– Označuje různé typy aktivit
Pokud se podíváme na data před změnou, uvidíme toto:
Pokud se typ účtu změnil, data by se jednoduše přepsala:
SCD typ 2:Sledování historických atributů podle řádku
Toto je nejběžnější forma historického sledování v systému DWH. Tabulky SCD typu 2 přidávají nové řádky pro každou historickou změnu rozměrových atributů mezi DWH zatížení . V tomto typu definujeme primární klíč jako náhradní klíč, protože obchodní klíč bude mít v průběhu času více reprezentací. Když se změní řádky, které obsahují změnu dat, definujeme novou hodnotu pro náhradní klíč, která odpovídá hodnotě v tabulce faktů. Potřebujeme přidat alespoň dva sloupce, valid_from a valid_to , k ukládání historie tímto způsobem.
Tabulka faktů se připojuje k historickým atributům dimenze pomocí náhradního klíče. Agregace se provádí na přirozeném klíči .
Příklad
Podívejme se na předchozí tabulku dimenzí zákazníků, nyní rozšířenou o dva sloupce data:
Podívejme se na data:
Body ke zvážení:
- Jak můžeme označit aktuální řádek,
valid_to? (Obvykle s 31.12.9999 nebo NULL .) - Jak můžeme označit první řádek,
valid_from? (Obvykle s 01.01.1900 nebo datem prvního vložení). - Definujete inkluzivní nebo exkluzivní řádek? (Výše používáme včetně
valid_froma exkluzivnívalid_to).
SCD typ 3:Sledování historických atributů podle sloupce
Stejně jako u Type 2 SCD, tento typ přidává něco, co reprezentuje historické hodnoty. V tomto případě však přidáváme nové sloupce. Ty představují hodnotu atributu dimenzionálního řádku před tím, než se změní. Obvykle ponecháváme pouze předchozí verzi atributu.
Poznámka:Toto SCD se používá zřídka.
Tabulka faktů se připojuje k aktuálním a předchozím atributům dimenze.
Příklad
Podívejme se na dimenzi zákazníka, tentokrát s předchozí adresou bydliště:
V tomto příkladu jsme přidali nový sloupec previous_address_residence reprezentovat starou adresu zákazníka. Pokud se podíváme na náš počáteční příklad, data v této tabulce by vypadala takto:
Všechny historické informace, kromě předchozí adresy zákazníka, budou ztraceny.
SCD typ 4:Přidání mini-dimenze
Tento typ rozměru není založen na strukturálních (Typ 3) nebo hodnotových (Typ 2) změnách. Spíše je založen na konstrukčních změnách modelu. Pokud naše rozměrová tabulka obsahuje vysoce volatilní data – tj. data, která se často mění – velikost rozměrové tabulky by výrazně narostla.
Abychom to zmírnili, extrahujeme nestálé atributy do minidimenze . Tyto mini-dimenze by pak mohly být agregovány na úroveň relevantní pro obchod. Tato agregace by však neměla zaměňovat s agregací fakta . Příklad to objasní.
Tabulka faktů se připojuje k historickým atributům dimenze.
Příklad
Podívejme se na příklad z jednoduchého trhu finančních dat. Předpokládejme, že potřebujete sledovat, jak se někteří zákazníci zpožďují se svými platbami. Nazvěme tento atribut dny po splatnosti nebo DPD. Pokud bychom měli sledovat DPD každý den v dimenzi typu 2, velikost tabulky by brzy explodovala za zvládnutelné limity. Extrahujeme tedy atribut a najdeme obchodně relevantní období DPD – řekněme po 30denních přírůstcích (0–30 DPD, 30–60 DPD, 60–90 DPD atd.)
Můžeme vzít další atributy s vysokou volatilitou, jako je věk, a vytvořit pro ně období relevantní pro obchod (např. 20–30 let, 30–40 let atd.)
Pokud se podíváme na data v zákaznické minidimenzi, měli bychom něco takového:
Atributy jsou:
id– Náhradní primární klíčDPD_period– Dny po splatnostiDEM_period– Demografické období
Jednoduché hvězdicové schéma by vypadalo takto:
Všimněte si, že abychom mohli provádět jakoukoli analýzu atributů z obou tabulek, museli bychom je propojit s tabulkou faktů.
SCD typ 5:Vytvoření mini-dimenze s přepisovatelným rozšířením
Toto je první z našich konstrukcí hybridních rozměrových tabulek. V SCD typu 5 přidáme aktuální verzi minirozměrných dat do rozměrové tabulky. Musíme mít na paměti, že přidáme pouze aktuální reprezentace mini-dimenze do hlavní dimenze.
Toto minirozměrové rozšíření doplňujeme každým nákladem ("přepisovatelné" SCD typu 1).
Ačkoli by historizace tohoto rozšíření mohla velmi dobře vést k problémům s velikostí, již jsme je zmírnili pomocí tabulky minidimenzí.
Tuto techniku používáme, když chceme provádět analýzy přímo v tabulkách rozměrů.
Příklad
Rozšířením předchozího příkladu o současnou mini-dimenzi dostaneme:
dim_mini_customer_current tabulka obsahuje nejnovější hodnoty atributů, které odpovídají dim_customer stůl. Nyní můžeme provádět analýzy specifické pro zákazníky, aniž bychom museli procházet tabulkou faktů (což je velmi pomalé).
Tabulka faktů se připojuje k historickým atributům dimenze.
Typ 6:Dimenze typu 2 (historický řádek) s přepisovatelným atributem
Toto je velmi častý rozměrový konstrukt. Přidáme atribut, který ukládá jednu věc, obvykle poslední známou hodnotu, kterou přepisujeme při každém načtení. To nám umožňuje seskupit všechna fakta podle jejich aktuální hodnoty, zatímco atribut historie zobrazuje data tak, jak byla, když se události staly.
Tabulka faktů se připojuje k dimenzionálním hodnotám v okamžiku události s extra aktuálními dimenzionálními hodnotami.
Příklad
Rozšiřme předchozí tabulku zákazníků o current_address_residence sloupec.
Nyní máme atribut, který aktualizujeme na aktuální hodnotu pomocí přirozeného klíče (cust_natural_key ).
Typ 7:Rozměry typu 2 (historická řada) s aktuálním zrcadlem
Tento typ můžeme použít pouze v případě, že je v rozměru tabulky přirozený klíč. Klíč se nesmí měnit během existence entity.
Myšlenka je jednoduchá:do schématu sněhové vločky přidáme aktuální reprezentaci rozměrové tabulky. Poté vložíme přirozený klíč nové dimenze do tabulky faktů. (Náhradní klíč historické dimenze je stále přítomen.)
Tabulka faktů se připojuje k dimenzionálním hodnotám v okamžiku události a aktuálním dimenzionálním hodnotám.
Příklad
Podívejme se na hvězdicové schéma našeho zákaznického účtu. Přidáváme nový rozměr dim_current_customer , do tabulky faktů. Tato tabulka je propojena s tabulkou faktů pomocí přirozeného klíče cust_natural_key .
Tato konstrukce nám umožňuje provádět analytické dotazy na hvězdicové schéma s aktuálními i historickými hodnotami atributů zákazníků.
Dimenze domény
Dimenze domény je jednoduchá forma tabulky rozměrů. Obsahuje informace o doméně základního měření rozměrového atributu. Tyto tabulky ukládají různé kódy a vysvětlující hodnoty.
Příklad
Jednoduchým příkladem může být tabulka měn.
V této tabulce ukládáme popisné informace o různých peněžních jednotkách.
Podle mého osobního názoru je nejlepší využití dimenze domény v dokumentaci hodnot dat, které najdeme v systému DWH.
Nevyžádané rozměry
Transakční zdrojové systémy generují mnoho indikátorů a příznaků. Tyto atributy lze považovat za kategorická data, ale nejsou relevantní pro obchod ani nejsou samozřejmé. Všechny tyto indikátory a příznaky můžeme uložit do jedné dimenzionální tabulky nazvané nevyžádaná dimenze . Nevyžádaná dimenze je alternativou k použití degenerovaných dimenzí. Pokud nechceme zatěžovat tabulku faktů mnoha degenerovanými dimenzemi, vytvoříme jednu nevyžádanou dimenzi.
Měli bychom si uvědomit, že nevyplňujeme všechny možné kombinace indikátorů a příznaků. Vyplňujeme pouze ty, které existují ve zdrojovém systému.
Příklad
Tabulky dimenzí jsou kostrou světa datových skladů:vše je postaveno kolem nich. Nejsou tak velké jako tabulky faktů, ale jejich struktura může být složitější.
Můžete sestavit mnoho typů tabulek rozměrů, dokonce i nad rámec těch, o kterých jsme právě hovořili. A co vaše podnikání a odvětví? Pokud jste zkombinovali typy rozměrových tabulek do něčeho nového, řekněte nám o tom!