Datové sklady. Multidimenzionální modelování Modely datového skladu Návrh datového skladu v rámci návrhu IS/ICT. Vladimíra Zádová, KIN, EF, TUL

Transkript

1 Datové sklady Multidimenzionální modelování Modely datového skladu Návrh datového skladu v rámci návrhu IS/ICT Multidimenzionální modelování

2 (Multi)dimenzionální modelování speciální technika určená pro logický návrh DW tak, aby vedl k výsledku - multidimenzionálnímu schématu s jehož pomocí se výhodně formulují uživatelské dotazy na datový sklad Multidimenzionální modelování Požadavky uživatelů (Business Requirements) Dimenzionální model Business procesy Granularita Dimenze Fakty Zdroje dat (Data Realities) Proces návrhu dimenzionálního modelu Zdroj: Kimball, R., Ross, M.: The Data Warehouse Toolkit: The Complete Guide to Dimensional Modelling, 2nd Edition, John Wiley & Sons,2002, str. 32, obr.2.1

3 Stanovení granularity Kritický krok určuje úroveň detailu prioritně nejjemnější granularita je spojena s ukazateli v tabulce faktů určuje základní dimenzionalitu (primární dimenze) stanovuje kandidáty faktů Identifikace faktů V kroku 2 určeny možné fakty musí být pravdivé k zrnitosti aditivní fakty fakty, které mohou být sumarizovány přes všechny dimenze semiaditivní fakty fakty, které nejsou aditivní alespoň k jedné dimenzi neaditivní fakty nejsou aditivní k žádné dimenzi

4 fakty Neaditivní jsou ty fakty, k jejichž výpočtu je třeba podílu ( při roll up nelze sumarizovat; rozdíl suma podílu x podíl sum) třeba uložit čitatele a jmenovatele zvlášť neaditivní je i jednotková cena, denní stav účtu... tedy fakty, které vyjadřují statickou úroveň Výběr dimenzí Primární dimenze předurčeny v předchozím kroku přidané dimenze, degenerované dimenze

5 Dimenze přidané dimenze pokud přidané dimenze poruší granularitu, třeba se vrátit k předchozímu kroku degenerované dimenze nemají tabulku dimenzí většinou primární klíče z transakčních systémů seskupené dimenze (Junk dimension) je vhodné uskupení nesouvisících atributů, které jsou vyjmuty z tabulky faktů a vloženy do jedné dimenze (snížení počtu atributů v tabuulce faktů) Dimenze normalizace dimenzí nemá příliš velký vliv na nároky na paměť zpomaluje dotazy - zejména prohledávání u normalizovaných dimenzí (- další join ) počet dimenzí - nejčastěji méně než 15 větší počet dimenzí znamená, že některé dimenze nejsou na sobě zcela nezávislé možnost sloučení větší počet dimenzí znamená výrazně větší nároky na paměť

6 Dimenze čas výskyt téměř vždy v DW, DM, lépe explicitně den, den v týdnu, měsíci, týden, q, rok (prodejní sezóna, konec týdne,..) (lze více hierarchií - kalendářní a fiskální vyjádření) někdy pro analýzu i část dne - pak je lépe přidat dimenzi čas Klíče v dimenzionálním schématu přirozený klíč ten existuje v transakčních systémech může být použit v degenerovaných dimenzích

7 Klíče v dimenzionálním schématu Náhradní klíč (surrogate key; umělý klíč, generovaný klíč, syntetický klíč) celočíselný klíč, který je přiřazen sekvenčně při vkládání do tabulek dimenzí slouží pouze ke spojení tabulky dimenzí a tabulky faktů výhoda při integraci dat z více zdrojů (pokud nekonzistence) menší nároky na paměť ( hlavně v tabulce faktů) chrání před změnami v původních transakčních systémech nutný při řešení typ 2 aktualizace měnících se dimenzí (viz dále) Dimenze a změny změny hodnot atributů dimenzí mohou probíhat rychle i pomalu, odlišení: pomalu se měnící dimenze (většina) rychle se měnící dimenze pro každý atribut třeba stanovit strategii pro vyjádření změn třeba již při i analýze zjistit od managementu jaké změny hodnot atributů jsou možné jaký výstup ( informace) budou s ohledem na tyto změny požadovat

8 Vlastní návrh datového skladu může prioritně vycházet z : analýzy zdrojů z požadavků na datový sklad současně z požadavků uživatelů i možností zdrojů dat Přístup k budování datového skladu jako celku

9 Přístup k budování datového skladu jako celku Centralizovaný datový sklad a závislá datová tržiště B. Inmon Datový sklad jako množina sjednocených datových tržišť R. Kimball Centralizovaný datový sklad - Bill Inmon Podnikový data warehouse obsahuje detailní, atomicky integrovaná historická data

10 Sjednocené data marty - Ralph Kimball Data warehouse není nic víc než sjednocení všech konzistentních data martů Integrace Každý podnikový proces vytváří jednoznačné metriky ve specifických časových intervalech s unikátní granularitou a dimenzionalitou může vytvářet 1 nebo více tabulek faktů dimenzionální model může být navržen z 1 procesu z více procesů

11 Integrace integrování jednotlivých dimenzionálních modelů do jednoho DW dovolí kombinovat fakty z odlišných procesů nejen drill down, drill up ale i drill across Pozn.: drill across - řešení dotazů přes vnější spojení společných tabulek dimenzí Bus architektura pro DW sběrnicová architektura je nezávislá na technologii a databázové platformě umožňuje použít přírůstkový přístup k stavbě DW různé týmy, asynchronnířešení

12 DW bus architektura Definování standardního rozhraní pro DW a respektování rozhraní umožňuje postupné zapojení a využívání jednotlivých DM jako celku Stanovení rámce DW bus architektura návrh standardizovaných dimenzí návrh faktů (conformed dimension, conformed facts) standardizované dimenze a fakty zajišťují jednotnou interpretaci v organizaci umožňuje efektivní komunikaci uvnitř týmů a mezi týmy vytváření DM každá iterace přísně dodržuje architekturu

13 DW bus architektura Obecné dimenze Business procesy Obchodní prodeje X X X X Obchodní zásoby X X X Obchodní dodávky X X X Skladové zásoby X X X X Skladové dodávky X X X X Objednávky X X X X X D atum P rodukt P rodejna Reklam a S klad Dodava tel D opravce Stanovení matice Z dimenzí a procesů se stanoví sběrnicová matice řádky značí jednotlivé datové trhy sloupce jednotlivé dimenze (conformed dimension) každý řádek dává přehled o dimenzích použitých pro DM

14 dimenze jsou buď identické nebo striktně matematické podmnožiny z nejvyšší granularity detailní dimenze mají shodný dimenzionální klíč shodná jména a definice atributů stejné domény ( shodnost datového obsahu znamená stejnou interpretaci a prezentaci) dimenze mohou být stejné tabulky ( i fyzicky) častěji synchronní duplikace tabulek nejvíce přizpůsobené dimenze jsou definovány na nejjemnější možné granularitě ( den, zákazník, produkt.) mnohdy se shodují ve vyšší granularitě v některých DM jsou sledovány fakty reprezentující agregované hodnoty ( a ty spojeny s agregovanými dimenzemi)

15 Data v IS/ICT OLTP - operativní data zdroje: zejména aplikace Data v OLTP a DW přístup: více současně pracujících uživatelů aktualizace:častá, relativně malých objemů dat Operace INSERT, UPDATE, DELETE dotazy nad daty selektivní ( zejména předpřipravené dotazy) přesnost výstupu - na Kč, haléře,.. četnost stejných dotazů - i vícekrát denně ukládání dat strukturovaně - normalizovaná relační databáze nověji objektově relační, objektová databáze požadavky - nekonfliktní zpracování operací, zajištění integrity dat procesní orientace ( stavy procesů, detailní data)

16 Data v OLTP a DW Data Warehouse zdroje: podnikové OLTP, operativní data + externí data přístup: malé množství specializovaných uživatelů - management aktualizace:řídká - jen přidávání dat ze zdrojů, delšíčasové intervaly dotazy intenzivní na data, složité dotazy, postupná iterace, sumarizace výstupy zaokrouhlené (i na tisíce) ukládání dat strukturovaně speciálně navržená relační databáze multidimenzionální kostka Organizace dat v DW Multidimenzionální kostka Založené na RMD

17 Multidimenzionální data 4-atributové relace X 3-dimenzionální kostky Reprezentace multidimenzionálních dat kostka reprezentuje data jako buňky relace reprezentuje multidimenzionální data ve 2 dimenzích

18 Příklad multidimenzionální kostky multidimenzionální modely datového skladu vycházející z RMD tabulky dimenzí vztahy mezi atributy, funkční závislosti tabulky faktů

19 multidimenzionální model dat logický návrh pomocí RMD konstrukty - fakty, dimenze, atributy dimenze, dimenzionální tabulky jednoatributový klíč (tvoří cizí klíč v tabulce faktů) atributy - slouží jako zdroj pro různá omezení daná v dotazech na DW atributy spíše textové jedna dimenze může být ve více hvězdicových schématech většina dimenzí se mění pouze pomalu obdobné vlastnosti jako číselníky (katalog výrobků, údaje o okresech..) multidimenzionální model dat logický návrh pomocí RMD tabulka faktů obsahuje ukazatele (metriky) výskyt konkrétní hodnoty závisí na n-tici konkrétních hodnot odpovídajících dimenzí mezi dimenzí a fakty je vztah 1: N mezi dimenzemi nejsou žádné přímé vztahy nejsou mezi nimi žádné funkční závislosti fakty jsou neklíčové atributy v tabulce faktů obvykle jsou numerické, aditivní, představují jisté míry představa faktů jako funkcí- závislost na klíčových atributech, výsledkem jsou hodnoty neklíčové

20 multidimenzionální model dat logický návrh pomocí RMD D 1 D 2 F 1 D 3 D 4 Hvězdicové schéma Hvězdicové schéma Hvězdicov zdicové schéma S je dáno trojicí <D, F, CC>, kde D je množina schémat dimenzionálních tabulek Di s množinou atributů Ai, F je schéma tabulky faktů a CC je množina kardinalit. Jeden atribut z tabulky Di představuje klíč tabulky a je označen KDi, klíč tabulky faktů je pak dán sjednocením KDi, je tedy tvořen ze všech cizích klíčů. Kardinalita CCi je definována pro schémata F a Di tak, že pro každý řádek u z F existuje pouze jeden řádek v z Di pro který platí u. KDi = v. KDi Multidimenzionáln lní databází nad hvězdicovým schématem je pak množina tabulek dimenzí D a tabulka faktů F, které vyhovují kardinalitám z CC Pozn. definice neuvažuje klíč degenerované dimenze, který hraje roli v určení klíče tabulky faktů neobsahuje normalizované dimenze, hierarchie atributů jsou skryté, jedna tabulka faktů obsahuje všechny agregace.

21 multidimenzionální model dat vycházející z RMD D 1 D 2 F 1 D 3 D 4 F 2 D 5 D 6 Schéma souhvězdí multidimenzionální model dat vycházející z RMD Schéma souhvězdí je dáno trojicí <D, F, CC>, kde D je množina schémat dimenzionálních tabulek, F je množina schémat tabulek faktů a CC je množina kardinalit. Pro každé schéma F z množiny F existuje podmnožina D D a CC CC tak, že <D, F, CC > je hvězdicové schéma

22 multidimenzionální model dat vycházející z RMD Další možnosti návrhu schémat vycházejí z těchto dvou základních a jsou dány: 1. rozdělením tabulky faktů v souladu s hierarchií dimenzí 2. vybudováním hierarchií jako řetězců tabulek 3. normalizací tabulek dimenzí daného schématu (jedné nebo více) multidimenzionální model dat logický návrh pomocí RMD Ad1 rozdělení tabulky faktů v souladu s hierarchií dimenzí vede ke vzniku souhvězdí tabulek faktů, které je speciálním případem schématu souhvězdí Jedna tabulka faktů je rozdělena do více tabulek faktů podél jedné hierarchie dimenze Všechny takto vzniklé hierarchické tabulky faktů se odkazují do stejných dimenzí, jsou však s nimi spojovány přes jiné atributy logicky odpovídající primárním klíčům jednotlivých hierarchických tabulek V dělení je možné pokračovat i podle hierarchií dalších dimenzí

23 multidimenzionální model dat logický návrh pomocí RMD D 1 D 2 F 1 D 3 D 4 F 1-hierarch1 D 5 F 1-hierarch2 Schéma souhvězdí pro hierarchii faktů multidimenzionální model dat logický návrh pomocí RMD Ad 2 vybudování hierarchií jako řetězců tabulek rozdělení tabulek faktů i rozdělení tabulek dimenzí podle hierarchií (obdobným způsobem) rozdělení tabulek faktů je shodné jako v předchozím případě jednotlivé hierarchické stupně těchto tabulek jsou spojeny s odpovídajícími si hierarchickými stupni tabulek dimenzí obdobně i zde může dojít k rozkladu více tabulek dimenzí i faktů podle obsažených hierarchií

24 multidimenzionální model dat logický návrh pomocí RMD D 1 D 2 F 1 D 3 D 4 F 1-hierarch1 D 4-hierch1 D 5 F 1-hierarch2 D 4-hierch2 Schéma souhvězdí pro hierarchii faktů a dimenzí multidimenzionální model dat logický návrh pomocí RMD Ad3 Normalizace tabulek dimenzí lze provádět jak ve hvězdicových schématech, tak i ve schématech souhvězdí tabulky dimenzí jsou ve třetí normální formě hvězdicové schéma s explicitními hierarchiemi v dimenzích je vřadě publikací označeno jako schéma sněhové vločky

25 Návrh datového skladu v rámci návrhu IS/ICT Návrh datového skladu v rámci návrhu IS/ICT Přístupy pro analýzu a návrh strukturovaný, objektový, Business Rules přístup Popis modelů pro návrh datového skladu multidimenzionální modely (ideální schéma) modely transakčních systémů (zdroje dat pro datový sklad)

26 Přístupy pro analýzu a návrh PRAVIDLA DATA PROCESY Strukturovaný, objektový, Business Rules přístup Základní přístup abstrakce, modelování Společné: Princip tří architektur (P3A) - konceptuální úroveň Odlišné: - technologická úroveň - fyzická úroveň Srovnání přístupů Strukturovaný přístup: data a procesy odděleně Objektově orientovaný přístup: data a procesy jako celek Business Rules přístup: pravidla odděleně, analýza pravidel, sledování pravidel

27 Modely přístupů Strukturovaný přístup konceptuální úroveň : ERA diagram, Diagram datových toků, Diagram stavů a přechodů technologická úroveň: Model logických datových struktur, Diagram modulární struktury Slovník dat Objektový přístup Diagram užití, diagram tříd, objektový diagram Dynamika: diagram stavů a přechodů, diagram činností diagram spolupráce, diagram sekvencí Přístupy k návrhu IS/ICT vypracovány pro OLTP popisuje konceptuální schémata, která jsou optimalizována pro OLTP systémy nerespektují specifika datových skladů neposkytuje postačující informace, které má DW poskytovat pro analytické zpracování nepřehlednost, není vidět přímo dimenze a fakty není zřejmé jak jednoduše agregovat data

28 IS/ICT - vztahy mezi daty a procesy OLTP ETL OLAP, DM, Operativní data Datové sklady OLAM, EIS Datové modely Datového skladu založené na relačním modelu dat - hvězdicové schéma, souhvězdí multidimenzionální kostka - hyperkostka, multikostka Operativních dat ERA model, diagram tříd, objektový diagram relační model dat, objektově relační modely, objektové modely, XML modely dat

29 (Multi)dimenzionální modely pro návrh datového skladu Multidimenzionální modely D 1 D 2 F 1 D 1 D 2 F 1 D 3 D 4 F 2 D 3 D 4 D 5 D 6 Hvězdicové schéma Schéma souhvězdí

30 Modely pro návrh datového skladu Obr. 1-P4 Grafické znázornění schéma faktů Zdroj: M. Golfarelli, D. Maio, S. Rizzi. The Dimensional Fact Model: a Conceptual Model for Data Warehouses. International Journal of Cooperative Information Systems,, pp , Modely pro návrh datového skladu Obr. 2-P4 Grafické znázornění konceptuálního multidimenzionálního schématu Zdroj: [9] Hüsemann, B., Lechtenbörger, J., Vossen, G.: Conceptual Data Warehouse Design,In Proceedings of the International Workshop on Design and Management of Data Warehouses, DMDW, Stockholm, 2000

31 Obr. 3-P4 Multidimenzionální doménová struktura E. Thomsen prodeje BANERJEE, S., DAVIS, K.: Modeling Data Warehouse Schema Evolution over Extended Hierarchy Semantics. Journal on Data Semantics, 2009, Vol. XIII, pp ISSN

32 Modelování datového skladu Specifikace požadavků a návrh řešení vychází z hlavních momentů návrhu návrhřešení Multidimenzionální modelování v rámci návrhu IS/ICT Specifikace požadavků a návrh řešení vztah mezi fakty a dimenzemi vztahy mezi atributy dimenzí mezi agregačními úrovněmi dimenze mezi agregační úrovní a vlastnostmi atributů k ní náležejících označení změn atributů dimenzí v čase agregovatelnost faktu k dimenzím, včetně možných agregačních funkcí

33 Specifikace požadavků a návrh řešení popis atributů dimenzí popis ukazatelů včetně stanovení výpočtu vztahy mezi jednotlivými ukazateli vztahy mezi ukazateli a fakty vztahy mezi zdrojovými atributy a atributy datového skladu specifikace procesů pro podporu rozhodování Zaměstnanec Zákazník Zam Id Jméno zam Nástup zam Ved Id Čas Den Id Typ dne Teplota dne Týden Měsíc Čtvrtletí Rok F - Prodej Zak Id Zam Id Prod Id Den Id C fakt Qty-prodané Prodej v KČ Zak Id Jméno zak Profese Odvětví Typ zak Země Produkt Prod Id Název prod Skupina Kategorie

34 Navrženéřešení Profese Zákazník Zak Id Typ zak Země Jméno zak Odvětví Faktura (deg) C-fakt F - Prodej Max, Min Qty-prodané Zaměstnanec Prodej v KČ T 3 Ved Id Zam Id Jméno zam Nástup zam Prod Id-_ Název prod Skupina Produkt Kategorie Týden Čas Rok Čtvrtletí Měsíc Den Id Teplota dne Typ dne Charakteristika a zajištění dimenzí T y p Název atributu: doména j e d n o t k a Bližší popis Počty instancí zdroj Transformace zdroj-cíl poznámka H Zam-Id:Int Person H Ved-Id:Int Person V Jméno zam:char Person V Nástup zam: Date Person Př. dimenze zaměstnanec

35 Charakteristika a zajištění ukazatelů Název ukazatele Doména J e d n o t k a Bližší popis Výpočet Uložení ve faktech Zdroj Transformace zdroj-cíl Poznámka QTY prodané N K s QTY prodané Prodej Kč N K č Prodej Kč Rozšířená multidimenzionální doménová struktura Jméno faktu (seznam agregačních úrovní dimenzí; podmínky výběru) Ωi Obr. 3-P4 Multidimenzionální doménová struktura (E. Thomsen)

36 Budování datového skladu Užitečnost DW Problematika návrhu konkurenční výhoda Užitečnost DW potenciální velká návratnost investic množství zdrojů pro Dw, náklady mohou kolísat zvýšení produktivity při rozhodování - vytvářením integrované subjektově orientované historické konzistentní databáze z více nekompatibilních systémů DW představuje jediný konzistentní pohled na podnik Omyly a DW DW =úložiště pro všechna data firmy; DW pouze data pro čtení; DW požadují relační DB; DW vždy veliké

37 Vlivy na efektivnost DW, BI Zkreslené představy nevhodná očekávání Zabezpečení projektu Personální, finanční Stanovení a analýza požadavků na DW, BI Volba metod Problémy DW, BI Zdroje skryté problémy zdrojů chybovost, nepřesnost (změna zdrojů během let) požadovaná data nejsou podchycena modifikovat OLTP či tvorba nového složitost integrace podhodnoceníčasu požadovaného pro ETL ( předpokladá se až 80% času na celý vývoj) vlastnictví dat Růst požadavků koncových uživatelů díky učení se vzniká potřeba změn: jemnější granularita, lepší prostředky; růst požadavků na pracovníky IT dlouhá doba trvání projektu

38 Možnosti dalšího rozvoje Datové sklady Datové sklady s daty v pevné datové struktuře Konceptuální úroveň návrhu datového skladu je ukončena Vývoj technologické úrovně - XML Datové sklady se semistrukturovanými daty Přístupy k analýze a návrhu IS/ICT Konceptuální úroveň pouze modely a techniky pro analýzu pravidel Další úrovně možné změny Pokud jiné typy aplikací (z hlediska charakteru dat a procesů) pak nové modely