Free Press

Dimenzionální modelování (DM) je součástí metodiky Business Dimensional Lifecycle, kterou vyvinul Ralph Kimball a která zahrnuje soubor metod, technik a konceptů pro použití při návrhu datového skladu. Tento přístup se zaměřuje na identifikaci klíčových podnikových procesů v rámci podniku a jejich modelování a implementaci jako první před přidáním dalších podnikových procesů, tedy na přístup zdola nahoru.

Jaké jsou cíle modelování datového skladu?

Cíle, které stanovili Ross a Kimball, jsou jednoduché:

• zajistit snadnou dostupnost informací
• prezentovat informace konzistentně
• přizpůsobovat se a reagovat na změny
• prezentovat informace včas
• chránit informační aktiva
• .
• sloužit jako autoritativní a důvěryhodný podklad pro lepší rozhodování (jediný zdroj pravdy v jazyce datového inženýrství)
• významné osoby musí váš systém akceptovat

Pokud jste pracovali na systému ETL nebo jej používali, jistě jste si všimli, že konzistence informací se dosahuje pomocí konformních opatření, včasnost zajišťují cykly ETL a přizpůsobivost také do značné míry závisí na návrhu ETL.

Proč modelování?“

Jako datový inženýr znáte velmi dobře jazyk SQL a pravděpodobně dokážete psát dotazy SQL celý den. Nemůžete však předpokládat, že typický koncový uživatel bude odborníkem na psaní dotazů SQL. Naším cílem je tedy vytvořit DW tak, aby bylo pro analytiky snadné psát analytické dotazy rychle a efektivně.

Věci, které byste po svých analyticích nechtěli:

• Dotazy založené na ID
• Kaskádové vnější spojení (to byste nechtěli dělat ani vy)
• skupinové nebo spojené vícenásobné poddotazy
• rekurzivní poddotazy (stačí navštívit Hackerrank SQL a pochopíte tu bolest)
• Korelace poddotazů: Získávání dat z více sloupců v různých poddotazích
• Spojení bez PK/FK: i pro mě(1.5 let zkušeností s DE), je to těžké vizualizovat.

Věci, které byste mohli a měli očekávat od svých analytiků:

• jednoduché spojování
• sloupce s názvy a obsáhlým textem
• jednoduchá agregace
• analytické okénkové funkce
• DISTINCT

Všimněte si, že výše uvedené body nejsou z nejjednodušších a že váš systém by měl být dostatečně škálovatelný pro všechny tyto druhy dotazů.

Databáze OLTP se kvůli výše uvedeným cílům mění na fakta a dimenze.

Přechod z transakčních databází na fakta

Většina podniků měří svou úspěšnost a efektivitu měřením určitých typů dat. Tato data zachycují skutečné podnikové činnosti a pokrok. Tato data se nazývají fakta

Databáze orientované na OLTP zaznamenávají transakce najednou, něco jako streamování událostí, ale centralizované kolem transakcí. U DW je tomu jinak. DW nepotřebuje zaznamenávat detaily na úrovni transakcí. DW potřebuje mít fakta napříč různými kritérii vašeho podnikání. DW musí agregovat (nebo umožnit analytikům agregovat) informace potřebné ke zlepšení podnikání. A tak je redundance v DW neodpustitelným hříchem.

Co jsou to míry a proč byste jimi měli naplnit tabulky faktů?

V datovém skladu je míra vlastnost, na které lze provádět výpočty.

Fakta, která získáváme z provozních datových skladů, přicházejí s některými dalšími údaji, které se v naší analýze obvykle sčítají. Jsou to aspekty faktu, které umožňují analytikovi nebo vedoucímu pracovníkovi, který si analýzu prohlíží, vidět ve faktu hodnotu.

Proč potřebujete udržovat konzistentní zrno?“

Abyste mohli zajistit, že váš systém může legitimně korelovat a agregovat napříč fakty.

Ne vždy je však možné mít data na atomických úrovních. Proto k překlenutí této mezery existují dvě metody:

• Tabulky faktů s periodickými snímky
• Tabulky faktů s kumulativními snímky

Tabulky faktů s periodickými snímky

Jak název napovídá, jsou shromažďovány v pravidelných časových intervalech. Spotřeba plynu, audit a kontroly jsou některé případy sběru dat, pro které jsou povoleny periodické snímky.

Akumulativní tabulky faktů se snímky

Pokud je ukazatelem výkonnosti podniku míra dokončení vícekrokového podnikového procesu, můžete chtít zachytit v zrnku celý proces a zaznamenat jeho zahájení, dokončení a kroky mezi nimi. Může se jednat o transakční zrno, které však obsahuje spoustu opatření mezi nimi. Pro zodpovězení komplexních otázek v oblasti business intelligence, kde dochází k plynutí času mezi jednotlivými fakty, tedy používáte kumulativní tabulky faktů se snímky. Dobrým příkladem může být řádek tabulky faktů o vaší objednávce kuřecího sendviče a řádek tabulky faktů o sáčku podávaném přes okno auta v drive-thru McDonald’s.

Lokalizování faktů pomocí dimenzí

Vy a vaši analytici potřebujete vědět, jak se dotazovat a filtrovat fakta, abyste z nich mohli získat business intelligence. K tomuto účelu slouží dimenze.

Vytváření dimenzí z referenčních a surových dat

Dimenze se téměř vždy vytvářejí s náhradním klíčem; na náhradní klíč se přirozeně odkazuje cizí klíč (nebo klíče) v tabulce faktů. V tabulce prohledáváme dimenze, které nás zajímají. Všechna ostatní data popisující naše fakta, jako jsou časová razítka, agenti zákazníků, umístění prodejny, produkt a zákazník, proměníme v dimenze.

Krása dimenzionálního modelování spočívá v tom, že fakta nejsou definována primárními klíči nebo jakýmkoli jedinečným identifikátorem, místo toho jsou definována kombinací dimenzí. Tím vzniká hvězdicové schéma.

Je velmi důležité, abychom v našich dimenzích měli jedinečnost. Až se dostaneme k dotazům napříč fakty, duplicity mezi kombinacemi dimenzí se promění v katastrofu. Pokud to nejde, přidejte nebo agregujte dimenze, aby byly jedinečné.

Hierarchie v dimenzích

Podívejte se na následující dva obrázky.

Analitik bude mít snadný život, pokud mu nastavíte druhou rozměrovou tabulku.

Takže s druhou tabulkou máte následující hierarchii:

Existují všechny druhy hierarchií – vícenásobné hierarchie, jednoduché hierarchie atd. V tomto příspěvku se jimi nezabývám.

Jediné, na co bych chtěl upozornit, je, že časová dimenze je opravdovým oříškem. Musíte se postarat o magické dny, fiskální kalendář, časová pásma, cykly(typy zisk přes čtvrtletí). A nebuďte v tom mizerní nebo příliš sebevědomí, ani databáze časových řad vám v hierarchiích nepomohou, pokud máte zpackané ETL. Možná byste se měli podívat na dimenze Outrigger. Existují také případy, kdy je jedna dimenze přirozeně závislá na jiné. V takovém případě mohou návrháři vložit cizí klíč z jedné do druhé. Právě to představuje tzv. outrigger dimenzi. U kalendářních dimenzí je to velmi časté.

V outriggeru nemůžete použít datum v jiném zrnu než data, která používáte v tabulce faktů. Nelze povolit agregaci nad outrigger dimenzemi. V případě potřeby maskujte číselné hodnoty v outriggeru textovými předponami nebo příponami, abyste tomu zabránili.

Pomalá změna dimenzí

Ačkoli bych o tom rád psal, přece jen si myslím, že pro čtenáře bude lepší, když tento pojem důkladně pochopí odsud.

Nerozebírám dimenze Snowflake, ale jen upozorňuji, že se stále používají u databází OLAP.

Zapojte svá Big Data do svého systému ETL

Svá tabulková Big Data budete považovat za data získaná v jedné ze standardních fází Extract. Budete na ně tedy aplikovat stejné kroky jako při transformaci:

1. Čištění dat
2. Soulad jednotek a formátů
3. De-duplikace
4. Restrukturace
5. Staging

Shrnutí

Chtěl jsem pochopit teoretické aspekty návrhu databáze, což mě přivedlo k přečtení knihy Ross a Kimball. Poté jsem se začal zajímat o rozdíly a analogie v jejich metodách a metodách dnešních předních společností založených na datech, jako jsou Netflix, Airbnb, Uber atd.

Při tomto hledání mohu spravedlivě říci, že strukturovaný formát dimenzionálního modelování je vhodnější než pouhé hardcore ETL. Tímto způsobem totiž odstraníte závislost na vás, váš BI tým vám nezvoní na Slack, abyste vytvořili novou DAG pro každý další insight, místo toho jim díky správnému modelování umožníte svobodně jednat a zkoumat bez vaší potřeby.

Prosím zanechte zpětnou vazbu, jak bych se mohl zlepšit, určitě to nebylo nejlepší čtení. Děkuji vám za váš čas.

Poznámky

https://en.wikipedia.org/wiki/Dimensional_modeling

https://en.wikipedia.org/wiki/Measure_(data_warehouse)

Ross a Kimball, kap. 2 a kap. 18

Kimball/Ross str. 103-109

.