Konceptuální modely datového skladu

Konceptuální modely datového skladu Vladimíra Zádová Katedra informatiky, TU Liberec, e-mail: [email protected]

Abstrakt: Příspěvek je zaměřen na modely datového skladu pro konceptuální úroveň návrhu. Existující modely pro tuto úroveň návrhu datového skladu nejsou standardizovány. Postupně jsou zveřejňovány návrhy dalších modelů datového skladu založené na hvězdicovém schématu, ERA modelu, jsou uváděny objektové modely, objevuje se XML řešení návrhu datového skladu. Tyto modely se liší v počtu i způsobu zobrazení jednotlivých konstruktů. V první části článku jsou specifikovány požadavky na modely datového skladu pro konceptuální návrh. V další části jsou pak posouzeny z hlediska formulovaných požadavků modely vycházející z hvězdicového schématu. Klíčová slova: konceptuální model, multidimenzionální model, hvězdicové schéma, model datového skladu Abstract: This paper deals with data warehouse models for conceptual level of design. Existing models for this level of data warehouse design are not standardized. Continually other designs of models of data warehouse are being published, which are based on star schema, ERA model, object models are being introduced, XML solution of data warehouse has appeared. These models differ in the count of their constructs and in the way their individual constructs are depicted. In the first part of the paper the requirements for the models of data warehouse for conceptual level of design are specified. In the next part of the paper the models based on star schema are assessed in terms of the specified requirements. Key Words: Conceptual model, multidimensional model, star schema, data warehouse model

1. Úvod Datové sklady, datová tržiště, OLAP analýza a dolování dat patří do Business Intelligence (BI) označované jako BI 1.0. Přesto, že v průběhu let došlo k dalšímu vývoji Business Intelligence, mají nezastupitelnou úlohu i dnes. Role datových skladů jako úložiště dat pro procesy rozhodování je zásadní. Pro analýzu a návrh datového skladu je používána řada modelů, postupně jsou navrhovány modely další. Existující modely vycházejí z relačního modelu dat (hvězdicové schéma, souhvězdí, schéma sněhové vločky), z ERA diagramu, jsou uváděny objektové modely, XML modely. Modely předkládané pro konceptuální úroveň návrhu se liší v počtu konstruktů i způsobu jejich zobrazení, mají různou úroveň podrobnosti. Na konceptuální úrovni dosud neproběhla standardizace modelů pro návrh datového skladu. Přitom pro návrh je zásadní zejména jeho konceptuální úroveň, v níž se při řešení setkávají uživatelé spolu s řešiteli.

118

SYSTÉMOVÁ INTEGRACE 3/2012

Konceptuální modely datového skladu

Hlavním cílem článku je formulace požadavků na detailní model datového skladu pro konceptuální úroveň návrhu. Kromě úvodu a závěru má článek další dvě kapitoly. V první z nich jsou formulovány požadavky na modely datového skladu, následující kapitola je věnována modelům vycházejícím z hvězdicového schématu. V kapitole uvedené modely jsou posuzovány z hlediska formulovaných požadavků. Pro přesné pochopení textu jsou v článku uváděny celkem běžné pojmy do poznámek pod čarou. Předkládaný článek navazuje na příspěvek (Zádová, 2009) věnovaný multidimenzionálnímu modelování v rámci analýzy a návrhu informačních systémů, který byl zveřejněný v tomto časopisu.

2. Požadavky na modely pro návrh datového skladu Návrh datového skladu má specifika, která jsou dána jeho postavením v rámci informačního systému. Při konkrétním návrhu je třeba zohlednit nejen požadavky manažerů ale i existenci a kvalitu zdrojů dat. Tedy je třeba se zabývat jak požadavky z hlediska zdrojů dat a jejich transformace, tak z hlediska procesů na podporu rozhodování. V tomto článku jsou formulovány požadavky na modely datového skladu 1 z hlediska procesů na podporu rozhodování, tedy OLAP procesů, dolování dat a reportingu. Pro všechny procesy na podporu rozhodování je důležité stanovit zaměření, podrobnost a rozsah sledování, tedy určit jednotlivé atributy, které vyhovují požadavkům a dát je do vzájemných souvislostí. Z hlediska požadavků na modely jsou 2 určující OLAP procesy, které představují analýzu ukazatelů z různých dimenzí 3 (pohledů) , v rámci jednotlivých dimenzí pak na různé úrovni podrobnosti (operace drilup, resp. roll-up a drill down). Dimenze obsahují atributy, kterými jsou určeny jednotlivé agregační úrovně hierarchií (označované jako úrovně dimenze nebo dimenzionální atributy) a atributy, které blíže charakterizují tyto úrovně (ale nevymezují je) tzv. vlastnosti atributů. Atributy 4 agregační úrovně vytvářejí agregační cestu (hierarchii) . Vlastnosti atributů mohou omezit výstupy při dotazování, v žádném případě neslouží k určení hodnoty ukazatelů vzhledem k dané agregační úrovni, jsou volitelné. V dimenzích může být jedna i několik hierarchií. Je-li hierarchií více, vytváří alternativní agregační cesty. Jednoduchá agregační cesta v dimenzi má všechny agregační úrovně povinné, jedná se tedy o povinnou hierarchii. Hierarchie dimenzí mohou být volitelné, nebo mohou mít proměnlivou délku agregační cesty. Volitelná agregační cesta závisí na hodnotě instance povinné agregační úrovně. U volitelné agregační cesty existují dvě povinné agregační úrovně - úroveň štěpení a úroveň 1

OLAP – On Line Analytical Processing; zásadní pro OLAP analýzu jsou základní operace: drill down/drill (roll) up, dice, slice a pivoting. 2 Obvykle se jedná o kvantitativní ekonomický ukazatel 3 Dimenzi lze charakterizovat jako subjekt důležitý pro činnost organizace. Často používané dimenze jsou: produkt, zákazník, teritorium, čas. 4 Agregační cesta je vytvořena postupným řazením atributů agregační úrovně od nižší úrovně po nejblíže vyšší úroveň podrobnosti; agregační cesta začíná atributem na nejnižší úrovni podrobnosti. SYSTÉMOVÁ INTEGRACE 3/2012

119

Vladimíra Zádová

spojení, mezi kterými se nacházejí další agregační úrovně, které jsou volitelné. Z úrovně štěpení dochází k rozdílnému sledování, které končí v úrovni spojení. Typický příklad pro požadavek vytvoření konstruktu pro hierarchii s proměnlivou délkou lze nalézt v oblasti řízení lidských zdrojů – pro analýzu výkonu v organizační hierarchii. Tato hierarchie lze vyjádřit pomocí rekurzivního vztahu. I u hierarchií s pevnou délkou hierarchie může dojít k tomu, že v konkrétních případech nemusí existovat přímý vztah parent-child, tedy nemusí existovat instance v obou úrovních, ale až instance následující úrovně. Hovoří se o nepokrývající hierarchii. Příkladem může být hierarchie s agregačními úrovněmi země – stát – město, kdy pro některé země (např. USA), existují instance na všech agregačních úrovních, pro jiné země neexistuje instance agregační úrovně stát. Mezi atributy agregačních úrovní tvořících jednu agregační cestu existují vztahy s kardinalitou N:1, což znamená, že instance nižší agregační úrovně lze jednoznačně přiřadit k bezprostředně následující agregační úrovni. Při návrhu může nastat případ, že tato kardinalita nemusí být respektována a u konkrétní instance bude kardinalita N:M. Pokud tato skutečnost nastane, jedná se o nestriktní hierarchii. Příklad může být v hierarchii s agregačními úrovněmi čtvrť a ulice, kdy jedna ulice může patřit do více čtvrtí a naopak jedna čtvrť může mít více ulic. Na konceptuální úrovni návrhu je třeba tuto okolnost uvést. Z důvodů časové variance je třeba se při analýze zabývat změnami dimenzí v čase. To znamená, že je třeba zjistit zda u atributů dimenzí v čase dochází ke změnám hodnot, o jaké atributy se jedná, jak často ke změnám dochází. Pro každý měněný atribut je třeba stanovit strategii vyjádření změn v závislosti na požadavcích uživatele (jsou známy základní a hybridní typy řešení změn; blíže v článcích Zádové (2006), Kimballa (1998) a Novotného et al. (2005)). U každého ukazatele, který je analyzován, je nutné určit agregovatelnost faktu k dimenzím, tedy stanovit k jakým dimenzím je sledován, pro každou dimenzi určit nejvyšší granularitu, další agregační úrovně sledování a také jaké agregační funkce budou pro určení hodnot ukazatelů na těchto úrovních použity, resp. bude mít smysl je použít. Mohou nastat případy, kdy má smysl provést pouze součet, mají smysl jen ostatní agregační funkce (či jen některé z nich), mají smysl všechny agregační funkce včetně součtu, nemá smysl žádná agregace. Pokud jsou ukazatele stanoveny výpočtem, je třeba navíc stanovit způsob jejich výpočtu. Některé ukazatele jsou na sobě nezávislé, jiné lze definovat pomocí dalších ukazatelů. Obojí, způsob výpočtu ukazatele i vzájemná závislost jednotlivých ukazatelů, má vliv na jejich uložení. Jeden ukazatel může být uložen v jednom nebo více atributech, pro které se vžil název fakty. Mezi dimenzemi a fakty je nejčastěji kardinalita 1:N, obecně může existovat kardinalita M:N. Jak vyplývá z výše uvedeného textu této kapitoly, detailní model pro návrh datového skladu pro konceptuální úroveň návrhu musí obsahovat konstrukty pro vyjádření - vztahu mezi fakty a dimenzemi (včetně uvedení kardinality M:N ) - vztahu mezi atributy dimenzí o mezi agregační úrovní a vlastnostmi atributů k ní náležejících o mezi agregačními úrovněmi dimenze  hierarchie s proměnlivou délkou  hierarchie s pevnou délkou povinná hierarchie 120



volitelná hierarchie nepokrývající hierarchie nestriktní hierarchie o označení změn atributů dimenzí v čase - agregovatelnost faktu k dimenzím, včetně možných agregačních funkcí - popis atributů dimenzí - popis ukazatelů včetně stanovení výpočtu - vztahy mezi jednotlivými ukazateli - vztahy mezi ukazateli a fakty. Grafický model datového skladu pro tuto úroveň podrobnosti může obsahovat konstrukty pro vyjádření všech výše uvedených požadavků vyjma posledních čtyř.

3. Konceptuální modely založené na hvězdicovém schématu Hvězdicové schéma, souhvězdí a různé formy sněhové vločky jsou známé multidimenzionální modely pro návrh datového skladu. Uvedené modely vychází 5 z relačního modelu dat , tedy technologické úrovně návrhu, odlišují tabulky dimenzí a tabulky faktů. Oba typy tabulek jsou databázové relace s určitými specifiky zohledňujícími cíl, pro který jsou určeny. U všech modelů jsou tabulky dimenzí spojeny jen s tabulkou faktů, ne mezi sebou. V tabulkách jsou uváděny atributy, označovány primární a cizí klíče. Hvězdicové schéma je tvořeno z jedné tabulky faktů a tabulek dimenzí, v centru schématu je tabulka faktů. Schéma souhvězdí se skládá z několika hvězdicových schémat, kdy dimenze mohou být sdíleny více hvězdicovými schématy. Ve hvězdicovém schématu je tabulka faktů normalizována, tabulky dimenzí normalizovány nejsou. Schéma sněhové vločky vzniká normalizací tabulek dimenzí ve hvězdicovém schématu. Z hlediska relační databáze je tabulka faktů tabulkou podřízenou, tabulky dimenzí jsou nadřazené tabulky. Kardinalita vztahu mezi tabulkou dimenzí a tabulkou faktů je 1:N, tabulka faktů a tabulka dimenzí má jednostranně nepovinný vztah: pro dané hodnoty dimenze nemusí být definován fakt, naopak tabulka faktů má k tabulce dimenzí vždy povinnou účast ve vztahu. Pro konceptuální úroveň návrhu je vhodné zvolit hvězdicové schéma jako východisko návrhu modelu datového skladu na nejjemnější úrovni podrobnosti. Schéma sněhové vločky je příliš spjato s technologickou úrovní. Normalizace dimenzí je pro konceptuální úroveň nežádoucí, vedla by jen ke znepřehlednění vlastního návrhu. Schéma souhvězdí je sice vhodné pro konceptuální úroveň návrhu datového skladu, ale ne pro tuto úroveň detailu (více Zádová, 2009). Vhodnost hvězdicového schématu pro návrh modelu spočívá v jasném vymezení rolí základních konstruktů, kterými jsou tabulka faktu a tabulky dimenzí a snadnost

5

Pojmy spojené s relačním model dat lze nalézt v řadě publikací, např. Pokorný, 2004


121

Vladimíra Zádová

rozšiřitelnosti konkrétního návrhu o další dimenze aniž by tím model utrpěl na přehlednosti. Z hlediska požadavků na model datového skladu pro tuto úroveň podrobnosti uvedených v předchozí kapitole, hvězdicové schéma nemá konstrukty pro odlišení atributů (agregační úroveň a vlastnosti atributů), vyjádření hierarchií, agregovatelnosti faktů k dimenzím, vyjádření kardinality M:N. Konceptuální modely navržené pro vyšší úroveň podrobnosti, které vycházejí z hvězdicového schématu, neuvádějí primární klíče tabulek dimenzí a faktů, ani cizí klíč tabulky faktů. Klíče souvisí s technologickou úrovní návrhu, pro konceptuální úroveň návrhu nejsou podstatné, návrh by byl méně přehledný. Modely přebírají základní rozložení, fakty jsou umístěny do centra hvězdice, na ně jsou napojeny dimenze včetně hierarchií. Liší se v zobrazení dalších požadavků. V článku (Zádová, 2009) jsou uvedeny dva modely vycházející ze schématu, které byly publikovány v (Hüsemann, 2000 a Golfarelli et al., 1998). V prvním z nich je zobrazena povinná a volitelná agregační hierarchie, k jednotlivým agregačním atributům jsou připojeny vlastnosti atributů. V modelu není sledována agregovatelnost faktů k jednotlivým dimenzím, je uveden pouze výčet faktů. Agregovatelnost faktů je uváděna zvlášť. Druhý model zobrazuje fakty, povinnou agregační hierarchii, vztahy mezi atributy dimenzí a vlastnosti atributů. V tomto modelu je uvedena agregovatelnost faktů, včetně neaditivity faktů k jednotlivým dimenzím. Na následujícím obrázku je uveden grafický model převzatý z Banerjee & Davis, 2009. V modelu jsou uvedeny hierarchie dimenzí, název dimenze je uveden jako první úroveň hierarchie. Nejsou zobrazeny vlastnosti atributů. Sledované fakty jsou umístěny do tabulky faktů. Dimenze mají více hierarchií; jsou zobrazeny povinné agregační hierarchie, u dimenze Location je zobrazena nepokrývající hierarchie (např. u Province - District) a nestriktní hierarchie (např. District – Street). Volitelná hierarchie zobrazena není, není zobrazena ani agregovatelnost k faktům.

Obr. 1: Schéma prodeje Zdroj: Banerjee & Davis, 2009 122



Na obrázku 2 je uveden grafický model, který byl poprvé publikován v (Zádová, 2006). Fakty a dimenze jsou zobrazeny v tabulkách. Model dále zobrazuje volitelnou agregační hierarchii (dimenze Zákazník; volitelná agregační úroveň Profese a Odvětví), povinné hierarchie a hierarchii s proměnlivou délkou (dimenze Zaměstnanec, Ved Id - Zam Id). Neobsahuje nepokrývající a nestriktní hierarchii. Jsou zobrazeny vlastnosti atributů k agregačním úrovním. Dále jsou zobrazeny změny dimenze v čase (dimenze Zaměstnanec, atribut Ved Id, je řešen pomocí typu 3). V tabulce faktů jsou uvedeny jednotlivé fakty, uvedena agregovatelnost faktů k dimenzím včetně aditivity a použití agregačních funkcí.

Obr. 2 Schéma prodeje. Zdroj: Zádová, 2006 Každý ze zde zmiňovaných modelů přebírá kardinalitu N:1 mezi tabulkou faktů a jednotlivými tabulkami dimenzí, neuvádí kardinalitu M:N. Žádný z uvedených modelů nesplnil všechny požadavky formulované ve druhé kapitole. Modely, které zachycují nejjemnější úroveň podrobnosti, jsou de facto modely pro zobrazení části datového skladu, tedy datových tržišť. Pro zachycení podoby celého datového skladu je třeba z důvodu přehlednosti návrhu zvolit modely na méně podrobných rozlišovacích úrovních. Modely, které je možné použít pro další úrovně podrobnosti uvádí Zádová (2009 ).

4. Závěr V článku byly formulovány požadavky pro konceptuální úroveň návrhu datového skladu, které by měly respektovat modely navržené pro nejvyšší úroveň podrobnosti. To bylo hlavním cílem článku. Tento cíl byl splněn. V článku nejsou uvedeny a SYSTÉMOVÁ INTEGRACE 3/2012

123

Vladimíra Zádová

analyzovány všechny publikované modely, které jsou založeny na hvězdicovém schématu, taktéž nebyla posuzována vhodnost grafického zobrazení konstruktů v jednotlivých modelech. To nebylo ani záměrem. Aby byl posuzovaný konceptuální model datového skladu na této úrovni podrobnosti úplný, musely by navržené konstrukty pokrývat všechny specifikované požadavky. Na základě specifikovaných požadavků lze posuzovat další modely a to bez ohledu na to, na jakém modelu jsou založeny. Specifikované požadavky mohou být také použity pro návrh nového modelu, či pro rozšíření existujících modelů o další konstrukty. Zásadní by přitom mělo být právě pokrytí všech specifikovaných požadavků konstrukty.

5. Literatura Banerjee, S., Davis, K., 2009: Modeling Data Warehouse Schema Evolution over Extended Hierarchy Semantics. Journal on Data Semantics, Vol. XIII, pp. 72-96. ISSN 1861-2032 Golfarelli, M. Maio, D. Rizzi, S., 1998: The Dimensional Fact Model: a Conceptual Model for Data Warehouses. International Journal of Cooperative Information Systems, Vol. 7, pp. 215-247, ISSN 0218-8430 Hüsemann, B., Lechtenbörger, J., Vossen, G., 2000: Conceptual Data Warehouse Design,In Proceedings of the International Workshop on Design and Management of Data Warehouses, DMDW, Stockholm, čl.6 Kimball, R. et al. 1998: The Data Warehouse Lifecycle Toolkit: Expert Methods for Designing, Developing, and Deploying Data Warehouses, John Wiley & Sons, ISBN 0-471-25547-5, 800 p Novotný, O., Pour, J., Slánský, D., 2005: Business Intelligence. Jak využít bohatství v datech, Praha, Grada, 256 s ISBN 80-247-1094-3. Pokorný, J., 2004: Konstrukce databázových systémů, 2. vydání, ČVUT, Praha ISBN 80-01-02898-4 Zádová, V., 2002: Strukturovaný versus objektový přístup v oblasti analýzy a návrhu. Systémová integrace č. 3, str. 117 - 137, ISSN 1210-9479 Zádová, V., 2006: Specifika postavení a návrhu datových skladů v rámci IS/ICT, [disertační práce] Liberec: Technická univerzita v Liberci, 145 s. Zádová, V., 2009: Multidimenzionální modelování v rámci analýzy a návrhu IS/ICT. Systémová integrace., roč. 16, č. 4. s. 66-76, ISSN 1210-9479 JEL Classification C80, L86

124


Konceptuální modely datového skladu

Recommend Documents