Základem většiny systémů MIS, EIS bývá obvykle datový sklad. Společnosti, které si takové řešení pořizují, stojí často před otázkami "Jak?". Jak dojít k úspěšné implementaci? Jak odlišit kvalitní řešení od méně kvalitního? Jak přistoupit k volbě nástrojů? Jak vyhodnotit nejlepší nabídku? Následující článek poskytuje některá kritéria pro hlavní komponenty, a to bez ohledu na použité technologie.

V typické struktuře datového skladu jsou data z primárních systémů (ERP, CRM, proprietární systémy pro marketing, plánování, další textové soubory apod.) přenášena nástroji ETL do vlastního jádra datového skladu, obvykle tvořeného relační databází. Zde, vyčištěna od veškerých "nečistot" a uložena dle obvyklých pravidel E-R modelování, jsou připravena jako zboží ve skladu určené k expedici na trh. Vlastním trhem, či spíše tržišti, jsou pak byznysově orientované data-marty, obvykle modelované jako multidimenzionální databáze, velmi často též podporované jinými typy nástrojů (OLAP nástroje či databáze). Sem, do datových tržišť, si je pak chodí "kupovat" uživatelé - mají na to speciální klientské nástroje, ať již programy k tomu přímo určené či na míru psané aplikace, obvykle ve formě tenkého klienta (tj. běžící v okně internetovského prohlížeče).

Jak zjistit, že datový sklad je "v pořádku"? Pro koncového uživatele ono "v pořádku" většinou znamená - podobně jako v celé oblasti IT - že o datovém skladu prostě neví. Má k dispozici "svoji" aplikaci, když ji potřebuje, je schopen z ní zjistit údaje, které potřebuje, a výsledky jednotlivých dotazů se na obrazovce objeví dostatečně "rychle" a přitom v očekávaných hodnotách.

Záměrně jsou zde užita poměrně obecná slova - zkušenost ukazuje, že nějaký univerzální etalon správnosti neexistuje. Vše závisí na mnoha okolnostech. Tak například v datovém skladu menšího maloobchodního řetězce může stačit, aby data byla přístupná v denních hodinách pracovních dní, zatímco v případě nadnárodní bankovní instituce s pobočkami ve všech světadílech může výpadek dostupnosti (7x24 - tedy stále) znamenat fatální obchodní důsledky.

Nezřídka se také stává, že není-li uživatel spokojen s kvalitou dat, může za to nejenom chyba v datové pumpě, nýbrž chyba v primárním systému. Máme zde na mysli například výpočty složitých finančních ukazatelů - nezávislý výpočet prováděný datovým skladem již mnohokrát pomohl odhalit drobnou chybu v primárních systémech.

Pokud jde o dostupnost dat a rychlost dotazů (availability, performace), její zadání i případná měřitelnost je poměrně snadná. Horší je to s kvalitou dat, případně s těmi komponentami datového skladu, které oku běžného uživatele zůstávají skryty. Mnohdy jsou i černou skříňkou, kam se "nesmí" podívat ani lidé z IT, která nemá administrátorskou ani technickou dokumentaci a představuje tedy černou skříňku i pro odborníky, kteří by o datový sklad měli v budoucnu pečovat.

Projděme teď jednotlivými vrstvami datového skladu a hledejme odpověď na otázku položenou v úvodu tohoto článku - "Jak poznat, že je to uděláno dobře?"

Relační databáze
Protože je relační databáze vlastním srdcem datového skladu, její správné navržení i fungování rozhoduje o životaschopnosti celého řešení. Jednou z vlastností, kterou by měla splňovat, je otevřenost. Tedy ne černá skříňka, nýbrž transparentní systém. Lze totiž očekávat, že dříve či později vznikne potřeba obohatit datový sklad - ať již přidáním dalšího zdroje nebo rozšířením o další datamart. V některých případech může být databáze otevřená i skupině počítačově zdatnějších uživatelů, kteří z ní čtou data pro speciální analýzy. To vše vyžaduje, aby k databázi existoval nějaký popis, dokumentace, a to ideálně ve formě datového modelu (např. v nějakém CASE nástroji). Pojmenování objektů (tabulky, views, procedury, relace, indexy atd.) by se mělo dít ne nahodile, ale podle nějaké konvence, stejně tak i pojmenování entit. Nejde tu jen o "estetické hledisko" - v případě rozsáhlých datových modelů je to spíš otázka přežití. Z datového modelu - nebo z metadat nástroje ETL - by mělo být také zřejmé, odkud příslušná data pocházejí, případně kdy a v jaké dávce byla přenesena, jaké změny v nich datový sklad provedl.

Kritérium jmenných konvencí je samozřejmě pouze formální. Jak už to ale bývá, formální náležitosti lze překontrolovat velmi snadno, na rozdíl od těch věcných. Věcná stránka datového modelu, to nakolik odpovídá požadovanému byznys zadání a nakolik umožňuje další rozvoj řešení, je věc složitější. Pohybujeme se tu na hranici exaktnosti a umění - některé požadavky lze formulovat obecně - dodržení referenční integrity, uchovávání historie v dimenzích i ve faktech, identifikace dávky, která provádí přenos - jiné věci však leží více v citu návrháře a především v jeho zkušenostech s obdobnými řešeními ve firmách podobného zaměření. Užitečným zdrojem tu jsou odvětvové datové modely, nicméně ty, které jsou veřejně přístupné (internet či publikace), jsou značně obecné.

ETL
Ať už je pro přenos a čištění dat použit systém za miliony dolarů, nebo se transformace dat provádějí kódem, který byl vytvořen přímo pro konkrétní datový sklad, vždycky je to tato vrstva, která představuje největší pracnost v celém řešení. V některých případech to může být přes 60 % celkového rozpočtu. Její správné vytvoření je tedy podobně důležité, jako je důležitý vhodný návrh relační databáze. Na co by si tedy dodavatel nebo zákazník měl dát především pozor?

Primárním úkolem datových pump (ETL vrstvy) je provést to, co říkají písmena zkratky, tedy přečíst data z primárních systémů (extraction), vyčistit a transformovat je do nových struktur (transformation) a následně uložit do datového skladu. Z hlediska výsledného efektu není podstatné, zda-li je zachováno pořadí (ETL), nebo ne (ELT). V některých případech lze volit i druhou možnost, tedy nejprve data přenést v nezměněné podobě z primárního systému do datového skladu a teprve potom provést transformace. Důvodem k tomu je to, že (např. z finančních důvodů) pro velikost projektu není k dispozici specializovaný nástroj ETL a je snadnější pomocí nějakého jiného prostředku data nejprve přenést a teprve potom zpracovávat standardními možnostmi konkrétního databázového stroje.

Prvním úkolem ETL je tedy čtení - zde je rozhodujícím kritériem to, aby se zdařilo v požadovaném čase přečíst všechna data. To někdy nemusí být triviální - je-li primární systém sám provozován v režimu kritické dostupnosti, takže jej není možné uvolnit a masivní čtení ze systému představuje nepřiměřenou zátěž pro další transakce. Pak bude třeba hledat nějaké další způsoby čtení: využít serveru, který poskytuje on-line zálohu pro případ výpadku (hot stand-by server), implementovat triggery na primární systém, takže se budou číst pouze modifikace dat z triggerových tabulek a ne data sama, navrhnout a sestavit systém pro rychlou extrakci dat do textových souborů a ty potom zpracovávat dál.

Druhým úkolem je transformace a čištění dat. To je nejdůležitější a současně nejtěžší úkol. Jeho obtížnost spočívá v tom, že není pouze technickou záležitostí, ale má co dočinění s vlastní činností firmy, pro kterou se řešení vytváří. Jsou to nakonec sami uživatelé, kteří musí definovat pravidla toho, jak zacházet s datovými nekonzistencemi. Je samozřejmě možné (a musí to také být součástí správného řešení) chyby v datech "reportovat" do nějakých vhodně zvolených tabulek či databází, nicméně v mnoha případech jenom to nestačí a je třeba volit další metody nápravy.

Mluvíme-li o integritě dat, máme na mysli referenční integritu, doménovou integritu a pravidla, která vycházejí z podstaty dat samých. V referenční části je nutné nahradit chybějící odkazy do dimenzí odkazem na umělý záznam ("Neurčený zákazník", "Neurčený produkt"). Nastane-li případ, že ve faktech je odkaz do dimenze, avšak v dimenzi odpovídající prvek chybí, pak je nutné takové prvky do dimenzí přidat ("Neznámý zákazník s id=300204" nebo "Neznámý produkt č. 2004356"). Pokud jde o doménovou integritu, jedná se především o pravidla typu: ve sloupci Jméno zaměstnance mohou být pouze písmena mezera a čárka. Nebo pole Sleva obsahuje celočíselnou hodnotu 60 až 100. A zcela nejtěžší je kontrola pravidel vyplývajících z povahy dat - může jít třeba o správnost rodného čísla (dělitelnost jedenácti - i když to bývá obvykle již kontrolováno primárním systémem) nebo správnost data narození - porovnáním s rodným číslem. Nebo pravidla, která váží dohromady více sloupců - např. každý zaměstnanec má uvedeno číslo buď ve sloupci měsíční plat, nebo ve sloupci hodinová sazba.

Uložení dat do datového skladu (loading) je naštěstí jen technická záležitost podobná čtení z primárních systémů.

Datamarty, OLAP a klientské aplikace
Z hlediska uživatelů jsou prvořadými kritérii důvěryhodnost a dostupnost. Ztráta důvěry v data uložená v datovém skladu je noční můrou všech, kteří nové řešení ve firmě prosazují a jediným způsobem jak jí předejít, je dobře realizovat vrstvu ETL. Avšak i když data ve skladu uložená budou sebelepší, jestliže se k nim uživatel nedostane, budou mu k ničemu. V požadovaný čas (např. ráno na začátku práce) musí mít uživatel sklad k dispozici i v případě, že některá data nebylo možné nahrát. To se samozřejmě stává, důvodem může být zpoždění primárních systémů (výpadek, pozdní dokončení konsolidace dat atp.). V takovém případě by měl být každý uživatel informován. Někdy je to vhodné udělat formou e-mailu, v jiných situacích lze takové věci zveřejňovat na vstupní webové stránce k datovému skladu.

Bylo by chybou nezmínit se na tomto místě o zabezpečení. Chybně nastavená přístupová práva mají pro koncového uživatele stejný důsledek jako probíhající aktualizace dat - ke svým datům se prostě nedostane.

O "přiměřenosti" trvání jednotlivých dotazů zde již byla řeč, její vnímání je silně subjektivní a je nutné požadovanou dobu specifikovat již při zadání. Pro úspěch projektu je také podstatná poskytovaná podpora práce uživatelů, ať již ve formě workshopů a školení, kde se naučí s novým řešením pracovat, nebo pomocí on-line nápovědy. Ta by samozřejmě měla zahrnovat popis ovládání aplikací, ale i (především) srozumitelný popis metadat - jaký je význam jednotlivých ukazatelů, z čeho jsou vypočteny, co je zdrojem dimenzí a jaká jsou pravidla řešení konfliktních situací. S výhodou tu lze využít metadat generovaných ETL nástroji nebo informací uložených v datovém modelu.

Kvalitu prověří čas
Poznání kvalitního systému business intelligence obvykle přináší až čas. Za úspěšné lze považovat ty systémy a ta řešení, které jsou uživateli využívány a které jim přinášejí to, proč byly navrženy - pohodlný přístup k datům a možnosti najít v nich informace a dále je využívat. Několik kritérií zmíněných v tomto článku může pomoci při budování takových řešení a orientace v procesu, jimiž podobné projekty jsou.

Jak získat kvalitní systém?

Rekapitulace klíčových bodů jednotlivých etap implementace systému business intelligence:

Databáze

Správný návrh	Použití technik pro sledování změn v datech (SCD, historie ve faktech), pravidla pro serializaci multidimenzionálních struktur, dodržení referenční a doménové integrity.
Datový model	Popisuje všechny databázové objekty, ideálně i datové zdroje a transformace.
Jmenné konvence	Usnadňují orientaci v databázi i v celkovém řešení.
Zabezpečení	Uživatelům jsou přidělena práva k přístupu.

ETL

Doba běhu pump	Pumpy ETL doběhnou ve stanoveném časovém okně.
Identifikace dávky	U každého přeneseného údaje lze zjistit, v jaké dávce byl zpracován.
Ošetření chyb	Implementováno ošetření chyb (integrita doménová, referenční, aplikace byznys pravidel). Všechny chyby jsou logovány.
Dokumentace	Kompletní dokumentace použité architektury umožňuje v budoucnu přidat do datového skladu další komponentu nebo při změně obchodních pravidel snadno provést úpravu v ETL vrstvě.
Monitorování	Nástroj pro sledování běhu datových pump lze využít pro řešení krizových situací (např. výpadky systémů, selhání hardwaru). Součástí by měla být notifikace správce – e-mailem, SMS zprávou.
Naplánování	Spouštění datových pump se provádí automaticky a všechny prováděné kroky jsou logovány pro pozdější případnou analýzu.

OLAP, datamarty a nástroje pro klientský přístup

Dostupnost	Uživatelé mají k dispozici řešení po celou požadovanou dobu. Plánované výpadky (upgrade hardwaru či přidání další komponenty do datového skladu) se děje mimo tuto dobu.
Zabezpečení	Uživatelům lze přiřazovat práva na individuální (či skupinové) úrovni. Práva lze jednoduše přiřadit na objekty typu dimenze, úroveň nebo prvek dimenze, ukazatel nebo skupina ukazatelů.
Výkon	Uživatelské dotazy trvají „přiměřeně“ dlouho, reakční doba odpovídá zadané funkční specifikaci.
Dokumentace	Uživatelé mají k dispozici on-line dokumentaci, která v sobě obsahuje jak popis vlastních nástrojů (nápověda k uživatelským aplikacím) tak i popis metadat datového skladu včetně jejich obchodní interpretace (co znamená který vypočtený ukazatel a odkud se berou data pro jeho výpočet).
Aktuální informace	Uživatelé mají k dispozici informace o stavu dat v datovém skladu (chybějící zdroje, datum poslední aktualizace atd.)

Auror článku, Dr. Mgr. Marek Polášek, působí jako projektový manažer ve společnosti Adastra, kde vede týmy konzultantů na projektech Business Intelligence v ČR a Německu.