Cílová databáze


Předchozí dvě kapitoly popisovaly proces, kterým se data z provozního informačního systému transformují do cílové databáze datového skladu. V této kapitole si povšimneme struktury uložení dat v cílové databázi a rozdílů od struktury databáze provozního informačního systému.

Konkrétní struktura databáze provozního informačního systému samozřejmě plně odpovídá aplikační oblasti, pro kterou je navržen, ale, jak již bylo zmíněno, databáze dobře navrženého informačního systému je normalizovaná (splňuje normální formy relačního uložení dat). Zde nebudeme rozebírat důvody pro takovéto uložení dat, protože jsou detailně popsány v literatuře, která se zabývá návrhem databází. Tyto důvody pramení vesměs ze snahy o zajištění konzistence dat. Obecně lze říci, že databáze provozního informačního systému má pevnou strukturu a nová data přibývají ve formě nových záznamů v existujících tabulkách.

Cílová databáze datového skladu má naproti tomu strukturu značně odlišnou a je vhodné jí dále rozdělit na dvě nezávislé části: datovou a metadatovou.

Datová část
První a nejdůležitější částí je část, kde jsou uložena sledovaná data. Charakter datové části cílové databáze datového skladu se výrazně liší od charakteru databáze provozního informačního systému i od ostatních datových úložišť datového skladu. Do datové části cílové databáze jsou postupně ukládány obsahy dimenzí v podobě dimenzionálních tabulek a sledované údaje v podobě tabulek faktů. Hlavním úkolem této části není zajištění integrity dat (ta je zajištěna předcházejícími popsanými stupni datového skladu), ale maximální možné zefektivnění provádění dotazů a výpočtů nad uloženými předagregovanými daty.

Struktura tabulek v datové části cílové databáze nesplňuje (nebo nemusí splňovat) známé normální formy, mívá často redundance sloužící pro zrychlení výpočtů, ale hlavně tato struktura není pevná. V datové části tabulky dynamicky vznikají a zanikají podle potřeby a podle toho, jak přibývají nebo ubývají data. Přírůstek dat do datové části cílové databáze se většinou neprojeví nárůstem počtu řádků ve stávajících tabulkách, ale vznikem nových tabulek. Nové tabulky v této části databáze vznikají také z dalších důvodů, jako například při postupném několikastupňovém počítání vyšších agregátů z atomických agregací nebo jako výsledkové tabulky při vyhodnocování uživatelských dotazů.

Naznačená dynamicky se měnící struktura velkého množství tabulek a různých vazeb mezi nimi je dynamicky a automaticky spravována obslužnými programy, které tvoří jádro datového skladu. Část programů této skupiny již byla zmíněna v předcházející kapitole. Jednalo se o programy zajišťující vytváření nových atomických agregací, případně rušení již nepotřebných. Další část obslužných programů tvoří dotazovací systém, který umožňuje uživateli vytvářet a vyhodnocovat dotazy nad sledovanými uloženými daty.

Programy patřící do jádra datového skladu jsou většinou univerzální a nad složitou, dynamicky se měnící strukturou datové části cílové databáze pracují z větší části automaticky.

Metadatová část
Aby bylo možné zajistit automatickou činnost obslužných algoritmů, musí být struktura části databáze v každém okamžiku přesně a detailně popsána. Přesný popis dynamické datové části databáze je možné udržovat v databázi, která se v principu značně podobá databázi provozních informačních systémů. Podoba spočívá v tom, že její struktura je pevná a navržená s ohledem na normální formy, takže i SQL příkazy a ostatní algoritmy, které slouží pro práci s touto částí databáze, jsou pevné.

Metadata popisující skutečná data a obsahují takové údaje, jako názvy tabulek a jejich sloupců, vazby mezi tabulkami, atd. Samozřejmě by bylo možno ukládat metadata společně s daty, což by se na první pohled mohlo zdát snazší a výhodnější. Oddělené uložení ale poskytuje mnohem větší pružnost a univerzálnost jádra takto vybudovaného datového skladu, včetně možnosti uchovávat obě části cílové databáze ve fyzicky oddělených datových prostorech.

Jádro datového skladu
Jak jsme se již zmínili, jádrem datového skladu zde označujeme množinu programů, které na základě metadat spravují a obsluhují skutečná data uložená v dynamicky se měnící datové části cílové databáze datového skladu. Díky pevnému uložení metadat je možné vytvořit jádro datového skladu univerzálně tak, že při nové aplikaci datového skladu není potřeba toto jádro měnit, ale jeho funkčnost se přizpůsobí nové aplikační doméně pouhým správným naplněním jejího popisu ve formě metadat do metadatové části cílové databáze.

Činnost jádra datového skladu (konkrétně dotazovacího systému) při zpracování uživatelských dotazů nad uloženými daty potom vypadá tak, že nejprve poskytne uživateli obraz sledovaných dat, který je uložen v metadatech a umožní mu na základě tohoto popisu aplikační oblasti specifikovat nový dotaz podle jeho přání. Potom, při vyhodnocování tohoto dotazu, nejprve na základě jeho analýzy a analýzy metadat dynamicky sestaví většinou značně složitý SQL příkaz, který se odkazuje na skutečné tabulky v datové části databáze, a tento příkaz zašle ke zpracování hostitelskému databázovému systému.

Výsledky zpracování vytvořeného příkazu pak prezentuje uživateli jako výsledky jím definovaného dotazu.

Jádro datového skladu, hlavně dotazovací systém, má ještě velké množství dalších podpůrných funkcí, ale jejich popis přesahuje rozsah tohoto článku a princip jejich funkce je obdobný.

Algoritmy jádra datového skladu by se daly charakterizovat tak, že svou činnost přesně řídí podle obsahu metadatabáze a většinu své činnosti věnují právě velkému množství operací nad metadaty. Jelikož se jedná o často používané části datového skladu, bylo by žádoucí jejich činnost vyladit (optimalizovat) tak, aby zabírala co možná nejkratší čas.

Obdobně jako u předchozích zmiňovaných částí datového skladu má optimalizace jádra datového skladu charakter spíše statický. Spočívá především v dobrém návrhu struktury medatadové části databáze a optimalizace algoritmů jádra. Obojí se ale provádí při vývoji (nikoliv nasazování) datového skladu, takže jde o činnost ještě méně častou než například v případě optimalizace datové pumpy, kterou je potřeba optimalizovat při každém novém nasazení. Určitou možnost optimalizace také skrývá nikoli optimalizace vlastní činnosti algoritmů jádra, ale optimalizace SQL příkazů, které jádro dynamicky generuje. I v tomto případě se ale jedná o statickou optimalizaci, kterou prakticky není možno automatizovat a je závislá pouze na šikovnosti tvůrců.

Logická struktura dat v datové části
V předchozích kapitolách jsme se zmínili, že v datové části cílové databáze datového skladu jsou dynamicky ukládány a vytvářeny tabulky uchovávající obsahy dimenzí, obsahy atomických tabulek faktů, případně tabulky obsahující již vypočítané výsledky uživatelských dotazů. Jejich popisy a popisy jejich vzájemných fyzických vazeb jsou ukládány do metadatové části cílové databáze.

Datový sklad fungující tímto způsobem by byl zcela jistě plně funkční. Z podstaty agregačních operací (ve většině případů sčítání) vyplývá, že libovolné vyšší agregace lze vypočítat z agregace atomické, proto by bylo možné vypočítat pro každé datové tržiště, které se v datovém skladu nachází ve fázi prvotní agregace, vždy pouze atomickou tabulku faktů a všechny uživatelské dotazy vyhodnocovat výpočtem z ní. Přestože je tento postup teoreticky možný, je v praxi značně nevýhodný, protože atomické tabulky faktů mají díky velkému počtu obsažených dimenzí a velké mohutnosti připojených dimenzionálních úrovní veliké množství řádků (v praxi běžně i mnoho milionů). Vyhodnocování uživatelských dotazů z takto mohutných tabulek by zabíralo neúměrně dlouhý čas. V praxi se navíc ukazuje, že velká většina uživatelských dotazů neobsahuje víc než tři, maximálně čtyři dimenze, a i to většinou na vyšších než nejnižších úrovních. Takovéto dotazy by bylo možno mnohem rychleji vyhodnotit z tabulky faktů, která by měla vyšší úroveň agregace a byla tudíž co do počtu řádků mnohem menší.

Neatomické tabulky faktů
Z praxe dále vyplývá, že svými kombinacemi použitých dimenzí a jejich úrovní uživatelské dotazy nad daným datovým tržištěm zdaleka nepokrývají rovnoměrně prostor vytvořený jednotlivými dimenzemi datového tržiště, ale že tvoří určité shluky. Nabízí se tedy myšlenka, pro každý shluk často kladených dotazů vytvořit a předvypočítat neatomickou tabulku faktů, která by posloužila k rychlému vyhodnocení dotazů kladených v příslušném shluku. Tím se zavede určitá redundance v uložených datech, která slouží výhradně pro zrychlení vyhodnocování často kladených dotazů. Seznam neatomických tabulek u každého datového tržiště a jejich vzájemné závislosti tvoří logickou strukturu datového tržiště, jejíž popis je rovněž uložen v metadatové části cílové databáze datového skladu.

Definování a vytváření neatomických tabulek faktů může sice výrazně urychlit zpracování některých dotazů, ale na druhé straně představuje značnou redundanci dat a tudíž klade veliké nároky na velikost datových prostorů v hostitelské databázi. Cílem je tedy navrhnout a rozmístit v každém datovém tržišti neatomické tabulky faktů tak, aby se docílilo co možná nejvyššího zefektivnění vyhodnocování dotazů při zachování rozumných nároků na datový prostor.

Právě návrh rozmístění neatomických tabulek faktů v dimenzionálním prostoru datového tržiště představuje asi nejzajímavější problém a nabízí nejširší prostor pro optimalizaci. Návrh rozmístění tabulek je možno vytvořit ručně administrátorským zásahem na základě citu nebo úsudku, ale je možno jej též vytvářet automaticky adaptivně na základě analýzy skutečně kladených uživatelských dotazů, a tak docílit co možná nejlepších výsledků.

Automatický návrh rozmístění neatomických tabulek představuje netriviální optimalizační problém s velmi vysokým stupněm algoritmické složitosti, protože prostor možných řešení je vzhledem k počtu dimenzí neobyčejně mohutný a ohodnocovací funkce, která by ohodnotila jedno konkrétní rozmístění neatomických tabulek vůči zaznamenaným dotazům sice existuje, je poměrně jednoduchá, ale zároveň je velice nespojitá, takže nelze použít žádné deterministické algoritmy založené na gradientních optimalizačních metodách. Různé metody založené na náhodnosti sice netrpí některými problémy gradientních metod, ale zase se vyznačují poměrně vysokou algoritmickou složitostí (která je i tak neúnosná), takže byly zatím vesměs shledány pro tento účel nepoužitelnými.

Závěr
V dnešním světě je stále více oblastí lidské činnosti řízeno nebo podporováno pomocí počítačů prostřednictvím různých provozních informačních systémů. Neustále vznikají nové informační systémy a systémy již existující se rozšiřují a integrují s ostatními. Výsledek je ten, že dohromady produkují stále větší množství dat. Ještě nedávno byl skoro zázrak, když kapacita pevných disků počítačů přesáhla jeden gigabyte. Dnes jsou běžné velikosti o jeden a téměř už o dva řády vyšší a není daleko doba, kdy se velikosti databází budou běžně pohybovat v řádech jednotek a více terrabytů.

Současně s dramatickým nárůstem množství dat, které provozní systémy produkují také prudce roste význam a nutnost jejich dalšího zpracování za účelem získávání dalších užitečných informací z těchto "surových" dat. V tomto procesu budou hrát čím dál větší úlohu systémy, které budou schopny si s takovým obrovským množstvím dat poradit a efektivně z nich získávat další cenné informace. Právě takovými systémy jsou datové sklady. Přestože dnes jsou stále ještě v plenkách, budou v budoucnu stále rychleji nabývat na významu a s jejich rostoucím rozsahem budou také stoupat nároky na jejich efektivnost. Množství jimi zpracovávaných dat zřejmě poroste mnohem rychleji než výkon procesorů počítačů, na kterých budou provozovány. Proto s významem a rozsahem datových skladů porostou také nároky na jejich optimalizaci.

Cílem toho článku nebylo detailně vysvětlit konstrukci datových skladů, ale v souvislostech uvést, které části datového skladu jsou kritické pro výkon a efektivitu, a v čem spočívá možnost případné optimalizace dané části a jaký charakter může tato optimalizace mít. Souhrnně lze říci, že místem, kde lze optimalizací dosáhnout největšího efektu je dynamický adaptivní návrh logické struktury agregovaných dat. Jedná se prakticky také o jediné místo, kde lze optimalizaci provádět automatizovaně.