Pojem "datový sklad" je v dnešním "datovém" a "informačně systémovém" světě fenoménem a téměř univerzálním zaklínadlem. Stejným, jakým byl ještě před několika málo lety pojem "informační systém", v dnešní terminologii "primární" nebo "provozní" informační systém. Zdaleka ne každý si však dostatečně dobře uvědomuje, jaký je rozdíl mezi těmito dvěma typy systémů, jaké jsou jejich hlavní charakteristiky, výhody, nevýhody a účel. Dovolte mi proto na úvod krátkou rekapitulaci a objasnění těchto a některých dalších pojmů.

Provozní informační systém
Provozní informační systém, v anglické literatuře také často nazýván OLTP (On-Line Transaction Processing) systém je z historického hlediska vývojově starší. Hlavním účelem provozních informačních systémů je podpora každodenních elementárních operací a činností v daném podniku a zajištění informační provázanosti a integrace jednotlivých částí nebo oblastí činnosti. První systémy tohoto typu začaly vznikat na počátku 80. let a hlavního rozmachu vývoje dosáhly koncem 80. a začátkem 90. let.

V současné době jsou ve větších podnicích provozní informační systémy téměř samozřejmostí, bez které by tyto podniky nemohly existovat.

Provozní informační systém musí uchovávat a spravovat množství různorodých elementárních dat z různých částí podniku (např. skladové záznamy zboží, faktury, záznamy o docházce do zaměstnání, firemní kontakty, obchodní případy a jejich součásti, evidenci aut a jejich používání, atd.). Kromě toho provozní systém musí být schopen nad těmito elementárními daty rychle a efektivně provádět relativně jednoduché transakce jako vyhledání záznamu(ů) podle zadaných kritérií, vložení nových záznamů, oprava již existujících nebo jejich vymazání (odtud pojem "transakční zpracování"). Transakce tohoto typu zpracovává provozní informační systém obvykle pro velké množství uživatelů = zaměstnanců, kteří jej používají pro svou každodenní práci.

Dobře navržený provozní informační systém uchovává svoje data obvykle v relační databázi, jejíž datové schéma splňuje všechny nebo některé normální formy relačního uložení dat. Provozní informační systém ve většině případů uchovává pouze aktuální data za poslední období, se kterými přímo pracuje a nikoliv data historická. Důvodem je především to, že historická data většinou nepotřebuje, takže by pouze zabírala místo a plýtvala výkonem.

Výše zmíněné uložení dat je velice vhodné právě pro provádění jednoduchých elementárních operací, ale je značně nevhodné pro kladení složitých dotazů pro vytváření různých přehledových a statistických sestav. Potřeba vyhodnocování složitých přehledových a statistických dotazů nad daty vedla ke vzniku nového typu informačních systémů, datových skladů.

Datový sklad
Pojem Datový sklad je překladem anglického termínu Data Warehouse. Obecnější označení pro systémy umožňující analytické zpracování dat je OLAP (On-Line Analytical Processing). Vývoj datových skladů začal v době hromadného nasazování provozních informačních systémů, které produkovaly velké množství dat, z nichž bylo potřeba získávat analytické a statistické údaje a to pokud možno snadno a rychle. Anglicky se tato třída činností nazývá Data Mining.

Dobře navržený a úplně implementovaný datový sklad pravidelně přebírá data z jednoho nebo více provozních informačních systémů, příp. jiných zdrojů a ukládá je do své vlastní primární databáze. Do datového skladu se většinou nepřebírají všechna data provozního informačního systému, ale pouze určité podoblasti, které mají být předmětem dalšího zkoumání. V primární databázi datového skladu jsou data stále ještě uložena relačním způsobem a jde vlastně o jakýsi obraz vybrané části provozního systému s tím rozdílem, že se zde uchovávají data včetně historie. Proces, který zajišťuje převod dat z provozního informačního systému do primární databáze datového skladu, se často nazývá datová pumpa.

Datová pumpa
Úkolem datové pumpy není jen vybrat specifikovanou část dat z provozního systému a tuto část překopírovat do primární databáze datového skladu. Proces převodu většinou představuje částečnou nebo i značnou změnu struktury ukládaných dat a hlavně jejich "čištění". V provozních systémech (zvláště těch hůře navržených) mohou být data většinou globálně a někdy i lokálně nekonzistentní.

Totéž platí, když se provádí import z různých zdrojů dat. Proces čištění má za úkol zjistit a odstranit nekonzistence ve vstupních datech a může sloužit i jako opravná zpětná vazba pro provozní informační systém.

V praxi je datová pumpa tvořena několika programy, které musí být přímo přizpůsobeny cílové aplikační doméně na jedné straně a struktuře primární databáze na straně druhé. Primární databáze datového skladu je ovšem v podstatě obrazem aplikační domény. Datová pumpa je tudíž přímo závislá na cílové aplikační doméně nasazovaného datového skladu. Na rozdíl od většiny dalších součástí datového skladu je datová pumpa obvykle pro každou instalaci datového skladu unikátní a tzv. "šitá na míru".

Datová pumpa je prvním potenciálně slabým místem datového skladu a tudíž i prvním adeptem na případnou optimalizaci. Řada databázových odborníků ji neprávem poněkud opovržlivě opomíjí. Jejich názor a bohužel i názor některých tvůrců datových skladů by se dal parafrázovat asi následujícím způsobem: "Tam dole bude nějaká ta pumpa, která nám nějak napumpuje data do našeho skladu, kde teprve začíná ta pravá věda." Je to značné podcenění, které by se dalo přirovnat k případu, že by výrobce leteckých motorů zkonstruoval vysoce výkonný moderní motor, ale vybavil by jej nevyhovující vrtulí s tím, že na vrtuli přece nesejde nebo k případu konstruktéra počítačů, který by svůj nový počítač vybavil superrychlým 64-bitovým procesorem, ale ten připojil na univerzální 8-bitovou sběrnici.

Z teoretického hlediska datová pumpa opravdu nepřináší mnoho zajímavých nebo nových problémů, ale její konkrétní realizace bývá často z hlediska výkonu velice kritickým místem celého skladu. Zvláště v případě, kdy se při importu provádějí složitější transformace a kontroly, nebo když je krátký interval mezi jednotlivými importy. Nesprávný je také názor, že datovou pumpu lze vytvořit univerzálně a její konkrétní podobu potom jen "naklikat" během pár chvil. Teoreticky samozřejmě ano, ale jak známo, každá obecnost se platí složitostí a nižší efektivitou, přičemž efektivita je v případě datové pumpy jeden z nejdůležitějších parametrů. Obecná datová pumpa může fungovat na školních příkladech s malým množstvím jednoduchých dat, ale v praxi, kdy je potřeba v rozumném čase "přepumpovat", přetransformovat a očistit mnoho gigabytů dat, je taková technologie naprosto nepoužitelná. I v případě dobře vytvořené datové pumpy je v reálném případě při reálné zátěži potřeba počítat s tím, že se provedení importu bude pohybovat v řádu desítek hodin až dnů.

Přestože jsem uvedl, že vytvoření datové pumpy při nasazování datového skladu vyžaduje mimořádnou pozornost a že podcenění může mít fatální důsledky, zpravidla se nejedná o teoretický problém. Optimalizace a vyladění datové pumpy obvykle spočívá v práci šikovných návrhářů a programátorů a provádí se v podstatě jednorázově při jejím vytváření a ladění. Dobrá datová pumpa může být přímo mistrovským návrhářským a programátorským kouskem. Z výše zmíněných důvodů prakticky nelze provádět optimalizaci datové pumpy automaticky.

Prvotní agregace
Analytické a statistické dotazy nad daty se vyznačují tím, že v naprosté většině případů směřují k získávání nikoliv detailních dat, nýbrž dat různým způsobem agregovaných. Počítání agregovaných dat je činnost velice časově náročná, proto je v datových skladech žádoucí tuto činnost zbytečně neopakovat. Proto je snaha vypočítat co možno nejvíce agregací dopředu a v hlavní části datového skladu uchovávat data už v agregované podobě. Nad takto uloženými daty je pak mnohem snazší realizovat dotazy, které jsou pro tento typ zpracování dat charakteristické.

Teoreticky čistý datový sklad dokonce poskytuje pouze agregované údaje a to ve formě předem definovaných číselných ukazatelů (faktů), které se v největší dostupné podrobnosti vytvářejí během prvotní agregace. Příkladem faktu by mohl být třeba počet výskytů, celková finanční částka, součet věků osob v dané skupině apod.

Vytváření dimenzí a atomických tabulek
V předchozí kapitole byl zmiňován proces datové pumpy, který zajišťuje převod dat z provozních systémů do primární databáze datového skladu. Další proces na cestě plnění datového skladu je vytváření prvotních (atomických) agregací a plnění obsahu dimenzí. Obsah dimenzí i hodnoty faktů v primárních agregacích se získávají z primární databáze datového skladu. Proces vytváření obsahu dimenzí je ve své podstatě statický, až na výjimky probíhá pouze při zakládání datového skladu a proto většinou nebývá kritický na vyladění výkonu. Ani operace, které se při plnění dimenzí provádějí nebývají většinou příliš složité a časově náročné, takže tato část většinou nepotřebuje žádnou zvláštní optimalizaci.

Druhou částí tohoto procesu je vlastní vytváření primárních agregací pro všechna datová tržiště, která datový sklad obsahuje. V tomto případě se jedná o proces značně výkonově kritický. Kritický je z několika důvodů. Prvním důvodem je, že vytváření atomických agregací probíhá opakovaně po naplnění primární databáze novými daty a je proto žádoucí minimalizovat počet operací v jednom opakování. Dalším důvodem je, že agregace se vytvářejí na základě zpracování velikého množství primárních dat a jejich vytvoření je tudíž velice časově náročné. Časová náročnost vytváření atomických agregací je většinou srovnatelná nebo vyšší než časová náročnost vstupní datové pumpy mimo jiné i proto, že se atomická agregace musí počítat pro každé datové tržiště zvlášť, čímž úměrně stoupá celková časová náročnost pro větší počet datových tržišť v datovém skladu.

Vytváření atomických agregací je vzhledem k výše zmíněným vlastnostem dalším potenciálním kritickým místem výkonu celého datového skladu a tudíž dalším adeptem na optimalizaci. Podstata algoritmů, které vytvářejí atomické agregace spočívá ve složitých SQL příkazech typu INSERT - SELECT hostitelskému databázovému stroji, protože se jedná o vypočítání obsahu nové tabulky z obsahů tabulek již existujících. Z tohoto důvodu spočívá optimalizace výkonu této části ve vyladění výkonu hostitelského databázového stroje (což je úkol pro jeho administrátora) a ve vyladění vlastních SQL příkazů, aby na daném databázovém stroji běžely co možná nejefektivněji. Jedná se opět o pečlivou mravenčí práci zkušených tvůrců, která se nedá moc automatizovat, ale obdobně jako v případě datové pumpy se provádí pouze staticky.

Část vytváření atomických agregací a plnění dimenzí je opět značně aplikačně závislá a musí být z velké části vytvořena pro každou aplikaci datového skladu znovu. Na rozdíl od datové pumpy, která byla zcela závislá na aplikační oblasti, je agregační část závislá na aplikační oblasti pouze částečně.

Zmíněné transformační SQL příkazy jsou sice přímo závislé na aplikační oblasti, ale jejich výsledky jsou ukládány do univerzálních struktur, které na konkrétní aplikaci závislé nejsou a také bývají často generovány na základě různých metadat, která jsou rovněž univerzální a na konkrétní aplikaci nezávislá.