![]() |
![]() |
Datové sklady očima databázisty
MULTIDIMENZIONÁLNÍ MODELOVÁNÍ Klasické modelování při budování IS zahrnovalo většinou tři stádia: konceptuální modelování, databázové modelování a fyzické modelování. Pro návrh datového skladu (DW) je vhodné připojit další stádium, které se nazývá dimenzionální modelování. Alternativní název je multidimenzionální modelování. Jde o speciální techniku určenou pro logický návrh DW způsobem, který povede k výsledku - (multi)dimenzionálnímu schématu, s jehož pomocí se výhodně formulují uživatelské dotazy nad DW. Jde vlastně o disciplínu, která používá relační model dat (RMD) s jistými omezeními. V Databázové abecedě v CW jsme již rozebírali multidimenzinální databáze jako speciální struktury, které pracují s fakty a dimenzemi. Základem dimenzionální modelování je hvězdicové schéma, což v E-R modelu znamená vyhradit jeden typ entity pro fakty. Ten je spojen s jednou nebo více dimenzemi. Dimenze jsou vlastně typy entit, které spolu nějak souvisí, např. VÝROBEK, ZÁKAZNÍK, PRODEJNÍ_JEDNOTKA, ČAS. Každý z těchto typů entit má svůj klíč a atributy. Např. PRODEJNÍ_JEDNOTKA obsahuje atributy Jméno, Představitel, Úřad, Okres. Fakty jsou popsány “průnikovým” typem entity PRODEJ, který má klíč složený z cizích klíčů (participujících dimenzí) a své vlastní atributy, např. Množství, Cena apod. V dimenzionálním modelování však modelujeme spíše v řeči tabulek, tj. jednotlivým dimenzím odpovídají dimenzionální tabulky a fakta jsou uložena v tabulce faktů. Primární klíče dimenzionálních tabulek tvoří komponenty primárního klíče tabulky faktů. Připomeňme, že z toho plyne, že se vlastně modelují vztahy M:N: ... :P. Toto omezení se může zdát poněkud zvláštní, ale zřejmě charakterizuje povahu dat v DW, kde, jak dokládá tvůrce Manifestu dimenzionálního modelování Ralph Kimball ve svých sloupcích v časopise DBMS, jde o zcela běžný případ. Jsme-li ve světě tabulek, říká se hvězdicovému schématu často také hvězdicové spojení (star join). Zdůrazněme, že vztahy typu 1:N mezi dimenzemi se v tomto přístupu neuvažují vůbec. Kimball také vysvětluje pojem faktu v dimenzionálním modelování. Jde (poněkud nelogicky) o neklíčové atributy v tabulce faktů. Tyto atributy jsou obvykle numerické a aditivní, představují jakési míry. Např. Cena, Množství apod. modelují jistá fakta. Poněkud smysluplnější pohled na věc by pojímal fakta jako funkce od hodnot klíče tabulky faktů do množin hodnot, které jsou představovány neklíčovými atributy. Např. “Cena výrobku prodaného zákazníkovi v daném období od dodavatele” je taková funkce. Samotné hodnoty atributu Cena mají totiž velmi chudou sémantiku a bez souvisejícího klíče vlastně žádné fakty (tj. tvrzení) nepředstavují. Zastavme se ještě na chvíli u aditivity faktů. Je zdůrazněno, že právě fakty se budou v dotazech agregovat (sčítat, násobit, načítat apod.). Příklad hvězdicového schématu je na obr. 1, kde “hvězdici” tvoří schémata PRODEJ, PRODEJNÍ JEDNOTKA, ZÁKAZNÍK, ČAS, VÝROBEK. První z nich popisuje tabulku faktů, ostatní definují dimenzionální tabulky. Nejde ovšem o “čisté” hvězdicové schéma, protože dimenze jsou modelovány složitějším způsobem pomocí hierarchií. Dimenze obsahují atributy spíše textové. Hodnoty z řádků těchto tabulek mohou tvořit vhodná omezení na dotazy na fakty. Např. dimenze ZÁKAZNÍK popisuje zákazníky včetně kategorie (např. právnická a fyzická osoba). Pak má smysl se ptát na výrobky prodané pouze právnickým osobám. Je patrné, že jedna dimenze se může vyskytovat ve více hvězdicových schématech. Četné aplikace DW podle uvedené strategie ukazují, že dimenze se většinou mění pouze pomalu. Některé z nich mají podobné vlastnosti jako tzv. číselníky (např. katalogy výrobků, sazebníky, údaje o okresech apod.), které se mění buď v dlouhých časových periodách, nebo vůbec ne (tj. nahrazují se čas od času novou verzí). Důležitou charakteristikou každého DW je možnost uchovat historii. Z toho plynou nároky a i na modelování dimenzí. Pouhá náhrada dat dimenze za nová data samozřejmě historii nezahrnuje. Vhodnější řešení je zahrnout historii do dimenze explicitně a to buď horizontálně nebo vertikálně. V prvním případě to znamená zavést další atribut (atributy), např. STARÁ_ADRESA, NOVÁ_ADRESA, ve druhém případě má každý historický záznam svůj vlastné řádek v tabulce a součástí klíče se stane např. ČÍSLO_VERZE. V databázové řeči je na místě se ptát, jak vypadá dimenzionální schéma. Jde o množinu hvězdicových schémat. Diskuse konstruktů Dimenze mohou tvořit jisté hierarchie. Např. PRODEJNÍ JEDNOTKA může být chápána s umístěním do OKRESů, které mají své vlastní atributy. Také čas může být chápan v hierarchii DEN, MĚSÍC, ČTVRTLETÍ, ROK. Tento přístup pak umožňuje chápat dimenzi jako cestu v grafu. Cesta zároveň ukazuje možnosti agregace faktů v souladu s členy hierarchie, např. prodej za prodejní jednotku, za okres atd. Příkladem takto rozšířeného hvězdicového schématu je na obr. 1. Abychom se vyrovnali s výrokem, že dimenzionální schéma se skládá pouze z hvězdicových schémat, mohli bychom poskytnout řešení, kdy hierarchie neexistují a hierarchie dimenzí je “degenerována” na jednu tabulku. Uvažme dimenzi ÚDOBÍ, která zahrnuje všechny atributy obsažené na obr. 1 v tabulkách týkajících se času. Podobně by se ošetřila prodejní jednotka. Tak obdržíme hvězdicové schéma. I budování hierarchií dimenzí má své zastánce. Jiným směrem je vytvářet jisté redundantní tabulky pomocí tzv. “sněhových vloček”, kdy se jedna hierarchizací dimenze současně vytvářejí nové tabulky faktů obsahující fakty v projekcích původních záznamů podle dané hierarchické úrovně. Pohyb nahoru k v hierarchii se tradičně anglicky nazývá roll up, pohyb dolů drill down (poskytni více podrobností). Při použití SQL v dotazech uživatele to znamená přidat více atributů do klauzule GROUP BY. Zastánci dimenzionálního modelování jdou ještě dále. Zavádějí pohyb drill across (spojování více tabulek fakt stejné úrovně podrobnosti) a další. Obr. 1: Hvězdicové schéma v multidimenzionálním modelování
Některé tabulky faktů paradoxně nemusí obsahovat fakta. Mimochodem, tento paradox vyplývá z nevhodného pojetí pojmu fakt (viz výše). V E-R bychom řekli, že jde o vztahy bez atributů. Není na nich nic nepřirozeného. Často je pomocí nich možné reprezentovat např. události. Ve studentské laboratoři může vztah (Novák, PROGRESS, 30.9.1997) reprezentovat událost, že student Novák se přihlásil přes počítač k SŘBD PROGRESS 30.9.1997 a pracoval s ním. Zřejmě jde o řádek tabulky faktů s atributy STUDENT, SOFTWARE, ČAS. Jiným zdrojem tabulek, které nemají neklíčové atributy jsou tzv. pokrývající tabulky, které jsou přiřazeny k jiným tabulkám faktů. Uvažujme např. tabulku PRODEJ_ZLZB, která obsahuje fakty o prodeji zlevněného zboží. Neobsahuje však žádné řádky o zboží, které si dosud nikdo nekoupil. To může být nevýhodné z hlediska požadavků na uživatelské dotazy. K tabulce PRODEJ_ZLZB zkonstruujeme pokrývající tabulku ZLEVNĚNÉ_ZBOŽÍ (má stejný klíč jako PRODEJ_ZLZB), která obsahuje i ty kombinace klíčů dimenzí, které se nevyskytují v PRODEJ_ZLZB). Pozor, námitka, že by bylo možné ukládat vše v jedné tabulce s použitím prázdných hodnot, neobstojí. V mnoha případech obsahuje tabulka PRODEJ_ZLZB pouze zlomek všeho zlevněného zboží a s reprezentací neprodaného pomocí hodnot NULL by enormně narostla. Dimenzionální modelování a E-R Zkušeného projektanta napadne, proč nepoužít rovnou E-R, když vlastně o nic jiného nejde. Jistě, něco pravdy na to je. Existují ale jisté významné rozdíly. E-R modelování je určeno pro modelování databází vhodných pro online transakční zpracování. Tabulky, které jsou výsledkem transformace E-R diagramů do RMD jsou užitečné pro jisté transakce, nikoliv však pro zpracování komplikovanějších uživatelských dotazů. Každý si uvědomí množství spojovacích podmínek, které musí formulovat při realizaci dotazů nad více relacemi. Dimenzionální modelování slouží pro jiný účel. Uživatel se jeho prostřednictvím (resp. s pomocí odpovídajícího navigačního software) může dostat k požadovaným výstupům, jednodušším způsobem, než formulací dotazů nad tabulkami s operativními daty. Jednoduchá struktura hvězdicových schémat podporuje i jednoduchost kladení dotazů. Nezanedbatelným prvkem je také fakt, že některé hvězdice jsou “typové”, tj. vyskytují např. v obchodním světě často, pouze se mění některé jejich atributy. Nic však není jednoznačné. Existují samozřejmě případy, kdy organizace implementující DW nepovažuje hvězdicová schémata za vhodný nástroj, který podporuje její potřeby. To jen dokumentuje fakt, že svět je natolik rozmanitý, že jej není možné jednotně ovládat a zřejmě ani modelovat. <seznam dílů seriálu> <COMPUTERWORLD> |