Toto je objekt systému MBI.

MBI (Management Byznys Informatiky) je portál obsahující zobecněná řešení v řízení provozu a rozvoje IT, resp. podnikové informatiky.

Pokud máte zájem získat více informací o tomto objektu (vazby na další objekty, přílohy, apod.), ale i získat mnoho dalších užitečných materiálů, můžete tak učinit ZDE / (registrace je bezplatná).

Metoda : Dimenzionální modelování
Dimenzionální modelování
Kód metody

Standarní kód metody v MBI

:
M504
Popis, obsahové vymezení

Obsahové vymezení metody - rekapitulace základních principů ve vztahu k řízení informatiky

1. Dimenzionální modelování - celková charakteristika
  • Dimenzionální modelování vychází z poznání a zhodnocení potřeb řízení dané organizace. Jeho obsahem je:*
  • vymezení všech dimenzí, jejich obsahu, včetně vnitřní hierarchie prvků, a dílčích charakteristik jednotlivých dimenzí,
    • určení soustavy sledovaných ukazatelů (faktů) a jejich dílčích charakteristik,
    • specifikace vazeb mezi ukazateli a odpovídajícími dimenzemi.
2. Dimenzionální modelování - hrubý dimenzionální model
  • Určení všech analytických dimenzí (DIG0 ),
  • Určení soustavy sledovaných ukazatelů (faktů) a jejich dílčích charakteristik (IG0 ),
  • Specifikace vazeb mezi ukazateli a odpovídajícími dimenzemi.
3. Dimenze a jejich charakteristiky
  • Vymezení všech dimenzí, jejich obsahu a dílčích charakteristik , zejména:
    • identifikace dimenze – např. „D_Zbozi“,
    • plný název dimenze, např. „Zboží nabízené a prodávané podnikem“,
    • obsah dimenze – detailní textový popis obsahu dimenze,
    • typ dimenze: časová dimenze, SNOWFLAKE, STAR, degenerovaná - - ,
    • hierarchie dimenze - hierarchické úrovně dimenze,
    • zdroj dat pro dimenzi, resp. její prvky, tj. databázová tabulka, textový soubor apod. s příslušnou standardní identifikací datového zdroje,
    • popis dimenze, poznámky k vytvoření a využití dimenze.
4. Ukazatelé a jejich charakteristiky
  • Vymezení všech sledovaných ukazatelů, jejich obsahu a dílčích charakteristik, zejména:
    • identifikace ukazatele – např. „Prodej_Id“,
    • symbolická identifikace ukazatele, např. „Prodej_objem“,
    • plný název ukazatele, např. „Objem prodeje v Kč“,
    • obsah – detailní obsahové vymezení ukazatele,
    • zdroj dat pro zdrojové ukazatele, nebo výpočty pro ukazatele kalkulované,
    • formát, např. Numeric (10,2),
    • jednotka vyjádření ukazatele – Kč, kusy, % apod.,
    • možnosti agregace ukazatele ve vztahu k dimenzím: aditivní, neaditivní, semiaditivní,
    • KPI – zda má ukazatel charakter KPI, KGI, nebo žádný z nich,
    • poznámky – např. určení tzv. analytických pravidel.
5. Vazby ukazatelé – dimenze
  • Vazby mezi ukazateli a dimenzemi se řeší obvykle formou běžné matice, případně s komentáři k vybraným vazbám.
6. Návrh tabulek faktů
  • Tabulka faktů uchovává hodnoty sledovaných ukazatelů - ,
  • Sloupce jsou buď klíčové atributy (Zbo_id, Ter_id, Cas_id), nebo hodnoty ukazatelů (Prod_trzby, Prod_nak),
  • Klíčové atributy – dimenze , jejich hodnoty - jsou prvky dimenzí,
  • Řádky - jednotlivá měření (v obchodě, výrobě apod.), většinou přiřazovány na co nejnižší úrovni detailu, tj. pouze na úrovni listů ve strukturách použitých dimenzí,
  • Granularita - - úroveň podrobnosti údajů – faktů - je přímo závislá na počtu a úrovni podrobnosti dimenzí odpovídajících příslušné tabulce faktů,
  • Obecná doporučení:
    • pokud to technické kapacity dovolují, měla by být data uložena s nejvyšší možnou granularitou,
    • data vstupující z různých zdrojů je účelné transformovat na stejnou nebo srovnatelnou granularitu,
    • nedoporučuje se kombinovat fakta s různou granularitou do jedné faktové tabulky,
  • Typy tabulek faktů - - v datových skladech existují tři hlavní typy tabulek faktů vzhledem k jejich granularitě dat:
    • Transakční tabulky faktů jsou založeny na tom, že detailní informace vstupující do datového skladu jsou vázány na jednotlivé transakce a pohybují se na nejvyšší možné granularitě dat. Z toho vyplývá, že časový úsek nebude stejný, ale bude záviset na době výskytu jednotlivých transakcí. Je potom vhodné rozdělit časovou dimenzi na „den“ a „čas“, tedy čas jednotlivých transakcí v rámci dne a kombinovat je s daty ve snímkované granularitě. Transakční tabulky faktů patří v praxi k těm velmi často využívaným,
    • Periodické snímkované tabulky faktů jsou v praxi nejpoužívanější. Data vstupují do datového skladu v pravidelných, předem definovaných časových úsecích (snímcích, např. dnech) a vyjadřují souhrnné hodnoty ukazatelů za celý časový snímek (např. celkový objem transakcí za daný časový úsek). Tento typ tabulek je nejvíce užívaný i pro odhadování, resp. predikci trendů vybraných ukazatelů. Návrh periodických snímkovaných tabulek se obvykle úzce váže na návrh transakčních tabulek faktů a sdílejí většinu společných dimenzí. Volba časového úseku pak samozřejmě ovlivňuje nejen granularitu, ale i nárůst objemu dat v datovém skladu,
    • Akumulované (též někdy stavové) snímkované tabulky faktů jsou rovněž závislé na výskytu transakcí, ale jejich hodnoty se v čase postupně aktualizují. Například při postupném objednávání zboží na sklad se tak udržuje přehled o aktuálním stavu a vývoji dané objednávky. Tyto tabulky se v praxi využívají méně často, než předchozí dva typy.
  • Další principy a doporučení:
    • Měrné jednotky , rozsah, zdroje a kalkulace ukazatelů - - tabulky faktů obsahují ukazatele, které potřebují různí uživatelé sledovat v různých měrných jednotkách, např. počty vyrobených produktů v kusech, v tisících, krabicích, v paletách apod. Nabízejí se dvě možnosti, buď umístit jednotky a přepočítací koeficienty např. do produktové dimenze, nebo je umístit přímo do jednotlivých záznamů tabulky faktů. S ohledem na riziko chyb a možné změny v koeficientech se doporučuje využívat spíše druhou variantu, tedy umisťovat je do záznamů tabulky faktů.
    • Tabulky faktů zabírají v datovém skladu obvykle kolem 90 % jeho celkové kapacity (oproti cca 10 % tabulek dimenzí). Je pro ně charakteristické, že tento rozsah je dán obrovským počtem jejich řádků, záznamů (např. každý prodej, každý telefonní hovor apod.). Na druhé straně je proto snaha omezit jejich rozměr co do počtu sloupců a rozsahu jednotlivých sloupců. Dalším způsobem řešení je určení granularity dat podle období, např. pro posledních aktuálních 60 dnů se využije denní granularita tabulky faktů, pro starší období, pak granularita nižší.
    • Tabulka faktů obsahuje základní, elementární hodnoty ukazatelů vstupující ze zdrojových databází i hodnoty kalkulované , tedy v tomto případě kalkulace v rámci jednoho záznamu (např. Prod_zisk = Prod_trzby – Prod_nak). Kalkulace se mohou provádět na úrovni ETL, datového skladu, resp. tržišť, nebo na úrovni analytických aplikací. Obvykle je užitečné u aditivních faktů ukládat kalkulované hodnoty přímo do datového skladu, resp. tržišť, neboť se tak zajistí dostupnost těchto dat všem uživatelům bez nutnosti kalkulace opakovat v různých aplikacích.
    • Dimenzionální modely obsahují i tzv. tabulky faktů bez ukazatelů, faktů (factless fact table), které nemají žádné ukazatele a využívají se např. pro zjišťování počtu určitých událostí. To znamená, že každý výskyt záznamu ve fakt tabulce s daným složeným klíčem indikuje vznik události, např. daná činnost je součástí procesu, zboží bylo zařazeno do marketingové akce apod. U nich lze pak sledovat souhrnné hodnoty pouhou sumarizací počtu záznamů v členění podle klíče.
7. Návrh dimenzionálních tabulek
  • De facto podnikové číselníky se všemi možnostmi a problémy - ,
  • Klíčovým problémem je většinou sjednocení číselníků , resp. dimenzí v rámci celého podniku,
  • Jedna řádka tabulky je vymezena pouze pro jeden prvek dimenze s primárním klíčem, podle něj by měla být tabulka i indexována,
  • Velký počet atributů (50 – 100 atributů) – pro dokumentační a reportovací účely, úrovně agregací, podmínky v dotazech,
  • Zahrnout všechny relevantní popisné charakteristiky ,
  • Property members “, neboli vlastnosti prvků, což jsou takové atributy, resp. položky, které se nepodílejí na vymezení nebo hierarchii dimenze,
  • Kvalita datového skladu dána kvalitou a hloubkou atributů dimenzí,
  • Atributy vyjádřené v plných výrazech, ne ve zkratkách ,
  • Referenční dimenze – dimenze, která se na tabulku faktů odvolává prostřednictvím jiné dimenze - ,
  • Vztahy dimenzí M : N - kardinalita vztahu - M:N (Many-to-Many), řešení - využití vazební (pracovní) tabulky faktů - ,
  • Další principy a doporučení k návrhu dimenzionálních tabulek :
    • V rámci jedné dimenze se mohou tvořit tzv. alternativní struktury , tj. např. pro různé organizační struktury v rámci jednoho podniku apod. - nejnižší úrovně hierarchie – listy obsahují sloupce pro identifikátory, resp. klíče pro více nadřízených struktur,
    • Degenerované dimenze , tzn. že existuje dimenze pouze na základě příslušného atributu v tabulce faktů a nemusí pro ni existovat dimenzionální tabulka (např. číslo položky nákupu na POS),
    • Časová dimenze – po dnech – se všemi podstatnými charakteristikami dní (pracovní den, svátek, ..) – podnikový kalendář,
    • Časová dimenze - hodiny – jako zvláštní, kombinovat s denní, jednodušší manipulace,
    • Kombinované dimenze - výhody – nižší nároky na prostor, efektivnější prohlížení a zpracování, nevýhody – nižší pochopitelnost a průhlednost řešení pro uživatele,
    • Je-li sledovaná veličina měřitelná a měnící se v čase – pak patří do fakt tabulky, či zda je diskrétní a vystupuje spíše jako konstanta – pak jde o položku z dimenzionální tabulky,
    • Parent-child “ dimenze, což je např. dimenze zaměstnanců, kde na úrovni listu je vždy pouze jeden „zaměstnanec“, na vyšší úrovni je „manager“, který je většinou nadřízený pro několik zaměstnanců, ale ten se odkazuje zpět na jednoho konkrétního zaměstnance – managera,
    • Sběrná dimenze (Junk Dimension) - – smyslem je vytvořit společnou, sběrnou dimenzi (junk dimension), která bude v jednotlivých záznamech obsahovat kombinace příznaků, kde každý záznam s takovou kombinací bude mít svůj umělý klíč.
8. Řešení změn dimenzí – SCD, Slowly Changing Dimension
  • Představuje změny ve struktuře a prvcích dimenzí , tedy číselníků v čase, přičemž při řešení úloh BI a SSBI existuje reálná potřeba zachovat konzistenci dat z časového hlediska . V tomto kontextu existují následující možné změny v dimenzích , tj. jejich prvků, příp. vyšších úrovní v rámci hierarchie dimenze:
    • přidání nových prvků (např. nová zboží, zákazníci apod.),
    • zrušení prvků (např. zrušení zboží),
    • změny hodnot atributů (názvy produktů, jména pracovnic, adresy zákazníků nebo dodavatelů apod.),
    • změny ve struktuře – zatřídění (zboží, pracovníků.
  • Historii v datech lze uchovávat dvojím způsobem, a to v rámci tabulky faktů, nebo tzv. historickými tabulkami dimenzí.
  • Řešení historie prostřednictvím tabulky faktů je založeno na principu, kdy se měnící se atribut přesune z tabulky dimenze (číselníku) do tabulky faktů.
  • Řešení změn přímo v dimenzionálních tabulkách je založeno na různých přístupech k řešení , označovaných v dimenzionálním modelování jako typ (Type) a číslo typu, např. Typ 1.:
    • Typ 0 určuje, že změny jsou ignorovány a do datového skladu se nepromítají,
    • Typ 1 – Přepis hodnoty atributu - nahrazuje původní hodnotu atributu hodnotou novou, změněnou ve stejné řádce dimenzionální tabulky.
    • Typ 2 – Přidání nové řádky do dimenzionální tabulky - nejčastěji používaný způsob řešení změn dimenzí a znamená přidání nového řádku do dimenzionální tabulky, který obsahuje změněnou hodnotu atributu, případně atributů. Tím se zachovají historické údaje, ale narůstá objem dimenze. Záznam dimenze obvykle obsahuje - nový primární klíč pro nový, resp. doplněný záznam, operační klíč (původní z transakčního systému), který se se změnami nemění, datum počátku platnosti záznamu, datum konce platnosti záznamu– u aktuálních záznamů se vyplňuje dostatečně vysokou konstantou (např. 1.1.2200).
    • Typ 3 – Přidání nového sloupce do dimenzionální tabulky - představuje přidání nového atributu do dimenze (nového sloupce) a přesunutí staré hodnoty do tohoto nového atributu. Do původního (aktuálního) atributu je pak možné vložit novou hodnotu.
    • Typ 4 – Vytvoření nové historické dimenze - vytvoření nové historické dimenze, do níž se přesouvají historické údaje. Tento přístup se používá obvykle tehdy, kdy v dimenzích dochází k rychlým, respektive častým změnám. Jestliže dojde ke změně, je daná existující dimenze nejdříve zkopírována do historické dimenze a následně jsou v původní tabulce dimenze provedeny potřebné změny.
  • Při dimenzionálním modelování ve vztahu k SCD je třeba brát v úvahu, že různé atributy, které jsou součástí záznamu dimenzionální tabulky, budou mít různý typ SCD . Nejčastěji užívanými typy SCD jsou 1 a 2 . Při návrhu analytické databáze se v této souvislosti můžeme rozhodovat mezi dvěma variantami:
    • jednu dimenzi lze rozdělit na dvě dimenzionální tabulky , přičemž v jedné budou atributy typu 1 a v druhé typu 2. Toto řešení je relativně jednoduché a často populární, ale nese s sebou dvě rizika – zvyšuje se počet dimenzí, v dotazech je třeba řešit navíc vazby mezi těmito dvěma dimenzemi, což je tvoří složitějšími a časově náročnějšími
    • zachovat jednu společnou dimenzi s atributy typu 1 i 2 , což řeší problémy předchozí varianty, ale naopak vede ke složitějším transformacím dat.
9. Nastavení správy metadat
  • Metadata jsou ve své podstatě strukturovaná data o datech. Metadata představují údaje nejen o samotných datech, ale také o technických prostředcích, softwaru, nebo sítích , kde se data nacházejí.
  • Specifikují jejich kontext, obsah, předpokládanou interpretaci a dostupnost . Hlavním účelem metadat je poskytování informací k analýze, návrhu, vývoji, implementaci a užití jednotlivých aplikací i celé podnikové informatiky.
  • V souvislosti s BI řešeními je obsah metadat např. následující:
    • celkový popis zdrojových systémů,
    • u data staging area to jsou popisy dat ve slovníku datového skladu,
    • u datového skladu popisy transformačních pravidel pro každou tabulku a každý datový element a popisy business názvů a transformačních pravidel pro každou tabulku a každý datový element,
    • pro reporting vysvětlení každého pole na reportu.
  • Podstata metadat je tedy zřejmá, jejich uplatnění jako faktor úspěšnosti v BI řešení je dáno několika důvody:*
  • BI řešení se vztahují převážně na celý podnik, jsou proto velmi komplexní, rozsáhlá a komplikovaná. Uspořádané, jasně strukturované a dostupné informace o tom, co tato řešení obsahují, jaké datové struktury, v jakých vazbách apod. jsou při této složitosti nutnou podmínkou realizace těchto projektů,
    • s rozsahem BI řešení roste i rozsah jejich metadat . Pro efektivní zajištění projektů i provozu BI se využívají celé systémy pro správu metadat, tedy databáze metadat s příslušnou aplikační nadstavbou pro práci s nimi,
    • jako jeden z efektů BI, vedle své analytické a plánovací funkcionality, se běžně zdůrazňuje i jejich úloha ve zvyšování pořádku (např. čistoty dat) v celém informačním systému. K uskutečnění této úlohy je nutné disponovat dokonalým přehledem a evidencí o stávajících datových a dalších zdrojích podnikové informatiky a takovou evidenci nabízejí metadata.
10. Návrh vrstev řešení
  • Jde již konkrétní návrh jednotlivých vrstev řešení, tj. jejich obsahové náplně, vzájemných vazeb a příp. návrhy změn do existujících vrstev.
  • Definuje se tak základní obsah dat na úrovni dočasného úložiště dat – Data Staging Area, operativního datového skladu (ODS), datového skladu (DWH), datových tržišť (DMA) .
11. Návrh datového modelu
  • Dalším krokem je analýza a návrh dimenzionálních modelů na bázi principů a s využitím nástrojů datového modelování .
  • V návaznosti na hrubý dimenzionální model a definovaných dimenzionálních tabulek a tabulek faktů se upřesňuje obsah a vazby databázových tabulek s určením běžných charakteristik (formátu, rozsahu) jejich jednotlivých atributů.
  • V rámci této fáze je třeba ještě verifikovat, zda data pro navrhované dimenzionální modely jsou ve zdrojových databázích k dispozici a jsou kvalitní .
  • Podstatou této aktivity je transformace výsledků hrubého dimenzionálního modelu do relačních databázových struktur . Obdobně, jako je tomu u návrhu jiných databázových systémů, se analýza a návrh realizuje na třech základních úrovních:
    • konceptuální, kde se definují základní entity v datovém skladu a jejich vazby,
    • logické, kde se jednotlivé entity transformují do návrhů logických struktur databázových tabulek, tedy včetně struktur atributů těchto tabulek,
    • fyzické, specifikující již všechny nezbytné technologické charakteristiky databázových tabulek a jejich vazeb.