![]() |
![]() | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Multidimenzionální databáze
V souvislosti s datovými sklady (data warehouses) a požadavky OLAP (On-line Analytical Processing) se dnes často hovoří o multidimenzionálních (česky spíše vícerozměrných) databázich. Nejde o speciální formu dodávání dat, což dělá právě OLAP, ale spíše o typ databázové technologie. Ukážeme, že data lze organizovat v multidimenzionálním datovém modelu, který je zcela odlišný od relačního modelu. Model trochu připomíná techniku spreadsheet, ovšem ve více než dvou rozměrech. Zjednodušuje pohled na data pro analýzy typu OLAP a při přímé implementaci vede obecně k rychlejšímu zpracování než provozování OLAP nad relační databází. Co je to vlastně multidimenzionální databáze (MDD)? Firma Kenan Systems Corporation známá v této oblasti specifikuje MDD jako softwarový systém, který je navržen pro výhodné a pružné uložení a vybírání velkých objemů dat, která jsou navzájem vztažena, nahlížena a analyzována z různých perspektiv. Tyto perspektivy se nazývají dimenze. Pochybovači namítnou, že podobnou definici bychom mohli použít i na relační databáze. Jak dále uvidíme, není to však tak úplně pravda. Uvažujme typický příklad prodeje zboží, např. osobních automobilů, přičemž se sleduje počet prodaných kusů podle modelu, barvy a prodejce. V relačním modelu jde samozřejmě o atributy. Zde však atributy MODEL, BARVA, PRODEJCE mají trochu jinou úlohu než OBJEM (počet prodaných kusů). První tři představují dimenze, podle kterých se řídící pracovník ptá na hodnoty atributu OBJEM. Analyzuje se tedy množina dat typu OBJEM z hlediska tří dimenzí.. Přidáme-li ČAS a OBLAST, získáme další dimenze, které umožňují řešit dotazy jako “Jaké jsou trendy v prodeji modelu Škoda v barvě zelené u prodejců ze Středočeského kraje”. Cílem tedy je získat informace o množině dat z různých perspektiv. O množině dat závisející na n dimenzích budeme říkat, že je n-rozměrná. Relační databázista by viděl problém celkem jednoduše. Vytvořil by tabulku PRODEJ(MODEL, BARVA, PRODEJCE, OBJEM) případně tabulky pro prodejce či modely, možná i pro barvy (v případě jejich dalších atributů) a nad nimi by se pokoušel formulovat dotazy v SQL. Ukažme si tabulku PRODEJ pro 3 modely, 3 barvy a 2 prodejce. Uvažujme dále, že každý model se vyskytuje ve všech barvách a každý prodejce prodává všechny modely ve všech barvách. Tyto předpoklady lze samozřejmě zjemnit, nicméně podstatné je, že všechny dimenze tvoří klíč tabulky. Atribut závislý na klíči je jeden (OBJEM), je možné jich však uvažovat obecně libovolné množství.
Podstatou přístupu k reprezentaci dat v MDD je multidimenzionální model dat (MDMD). Data se v něm místo v tabulce zobrazují pomocí vícerozměrných polí (tak jak je již po řadu desetiletí známe z programovacích jazyků). V terminologii OLAP se také hovoří o datových kostkách nebo multidimenzionálních kostkách. Každá dimenze v poli odpovídá jedné dimenzi n-rozměrné množiny dat, každý prvek v dimenzi (hodnota atributu v RMD) se nazývá pozice. Vícerozměrná data odpovídající nějaké kombinaci pozic jednotlivých dimenzí jsou umístěna v buňkách pole. V našem případě (obr. 1) jde o hodnoty atributu OBJEM.
Obr. 1 Dimenze a buňky Na základě těchto úvah bychom mohli (alespoň zjednodušeně) definovat, co je strukturálně MDD pomocí pojmů používaných v klasických databázích. Schéma multidimenzionální databáze je množina vícerozměrných polí. Multidimenzionální databáze je dána vícerozměrnými množinami dat uloženými v těchto polích. Odpovídající softwarový systém, který slouží pro založení, správu a dotazování nad MDD nazveme systém řízení multidimenzionálních databází (SŘMDD). Složitost reprezentace v MMD a RMD Existuje řada výhod, proč je pole pružnější a efektivnější pro prezentaci dat v MDD.
MDMD reprezentuje vyšší úroveň organizace než RMD. Relační struktura neříká nic o struktuře jednotlivých atributů. Získávat různé agregace z tabulek přímo je též mnohem složitější než v MDMD. Je nutné formulovat komplikované dotazy v SQL, případně ručně kombinovat jejich výsledky.
Obr. 2 Agregace v podprostorech vícerozměrného pole
Uvažujme na chvíli 2-rozměrnou množinu dat s 10 modely a 10 barvami. V RMD potřebujeme tabulku s 100 řádky. Přidáme-li 10 prodejců, obdržíme tabulku s 1000 řádky. Tomu v MDMD odpovídá pole s 1000 buňkami. Hledání v tabulce v obecném relačním prostředí může znamenat prohledávání 1000 záznamů, kdežto v MDD 3 prohledání - každé v 10 hodnotách. Jistě, otázkou je, jak je vlastně vícerozměrné pole nějaké MDD implementované. Podstatné je, že implementace je “šitá na míru” pro data uvažovaného typu a dotazy podporující analýzu dat. Navíc, naše příklady vypadaly tak, že každá buňka pole byla obsazená, což nemusí být obecně pravda. Každý prodejce nemusí prodávat všechny modely ve všech barvách. Problém implementace vícerozměrných polí musí uvažovat i prázdné hodnoty. Kde MMD není vhodný Uvažujme obecnou tabulku v RMD např. s jednoatributovým klíčem. Takovou tabulkou může být PRODEJCE(ROD_Č, JMÉNO, ADRESA, VĚK). Za dimenze vezměme atributy ROD_Č, JMÉNO, ADRESA, do buněk se bude ukládat hodnota věku. Nechť je 100 prodejců, 80 jmen, 100 adres. Počet buněk bude 800 000. Protože je ale k uložení pouze 100 hodnot věku (pro 100 prodejců!), bude 799 900 buněk neobsazeno. MMD je zřejmě v daném případě zcela nevhodná. Kdy tedy využijeme MMD? Půjde zřejmě o případy, které v konceptuálním pohledu odpovídají n-árnímu typu vztahu s kardinalitami M, N, P, ..., tj. případy, kdy mezi klíči entit neexistuje žádná funkční závislost. Klíčem K odpovídající tabulky R by bylo zřetězení klíčů participujících typů entit. Pak jediné funkční závislosti v R jsou závislosti na klíči K a neexistují tedy žádné funkční závislosti mezi dimenzemi ve vícerozměrném poli. Všimněme si, že zrovna toto není u příkladu s tabulkou PRODEJCE pravda. Klíčem je ROD_Č a tedy dimenze JMÉNO a ADRESA na něm budou i pro pole PRODEJCE funkčně závislé. Chyba v návrhu MDD PRODEJCE však už nastala na konceptuální úrovni. PRODEJCE totiž nemodeluje vztahy, ale entity. Ani n-ární typ vztahu nemusí být ještě postačující pro existenci MDD. Žádoucí je, aby co nejvíce buněk bylo obsazeno, tj. aby vícerozměrná data existovala pro každou kombinaci pozic z jednotlivých dimenzí. Z pohledu relační databáze toto nastává v případě, kdy mezi dimenzemi existují (zahnízděné) multizávislosti. Např. v našem příkladě PRODEJ platí zahnízděné multizávislosti MODEL ->> BARVA, MODEL ->> PRODEJCE a řada dalších. MDD vs. relační implementace OLAP Přestože existují samostatné produkty pro MDD, tj. SŘMDB, většina výrobců nejznámějších relačních databází začíná nabízet prostředky pro OLAP implementované na základě relační databáze, případně na základě jejího rozšíření o vícerozměrná pole. V souvislosti s relačním přístupem pomocí jazyka SQL se objevila speciální syntaxe pro vytváření agregací data vyžadovaných v OLAP. Hovoří se o operátoru CUBE, pomocí něhož lze provádět obecnější agregace dat než jak je tomu dosud, tj. kombinací GROUP BY a agregačních funkcí. Tímto způsobem lze integrovaným přístupem přistupovat data v běžné operativní databázi a ve speciální MDD. Významným prvkem MDD je prezentace dat uživateli. V této souvislosti se objevují speciální operace umožňující rotaci vícerozměrných kostek, pohyb po jednotlivých úrovních agregace apod. MDD využívají speciální metody konceptuálního modelování. Např. entitní typy PRODEJCE, BARVA, MODEL spolu s typem vztahu PRODEJ tvoří tzv. schéma hvězdy. Obecně řečeno, jde o novou oblast databází přinášející nové zajímavé problémy k řešení, ať už v dotazování, prezentaci či implementaci dat.
<seznam dílů seriálu> <COMPUTERWORLD> |