2 TEORETICKÁ ČÁST
2.2 B USINESS I NTELLIGENCE
2.2.4 Datový sklad
• datová tržiště (Data Marts) – v podstatě redukovaná obdoba datového skladu, která je určena omezenému okruhu uživatelů, jako je např. oddělení, divize, jenž obsahu data stejného typu jako DWH a výrazně přispívá ke snížení doby počáteční implementace, nákladů a zlepšuje orientaci uživatelů v datech,
• OLAP – viz. podkapitola 2.2.2 - Principy BI,
• reporting – je cílené dotazování v databázi pomocí jejího standardního rozhraní, může být buď plánovaný nebo na vyžádání (ad–hoc),
• manažerské aplikace (EIS) – analytické a plánovací aplikace,
• dolování dat (Data Mining) – jde o získávání předem neznámých informací z rozsáhlých zdrojů dat, vyvozovaných z obsahu dat,
• nástroje pro zajištění kvality dat – jejich účelem je zpracovávat data tak, aby bylo dosaženo jejich úplnosti, souladu, konsistence, přesnosti, unikátnosti a integrity,
• nástroje pro správu metadat – shromažďují a evidují informace o jednotlivých komponentách informačních systémů,
• ostatní - nástroje pro podporu rozhodování či expertní systémy.
2.2.4 Datový sklad
Je pěkné mít spoustu nashromážděných dat, jednoznačně lepší ale je, mít daná data vhodně uspořádaná a přístupná. Shromaždování dat nebývá většinou příliš velký problém o něž se starají tzv. primární systémy. Velmi problematické však bývá vhodné uspořádání a dostupnost dat. Vhodným řešením této problematiky je zavedení datového skladu (dále jen DWH).
2.2.4.1 Definice
Za všeobecně uznávanou a zažitou definici datového skladu je považována definice W.
H. Inmona [INM 2002], jenž zní:
„Datový sklad je kolekcí sjednocených, předmětově orientovaných databází navržených za účelem poskytovat informace požadované pro rozhodování.“
Podrobnější vysvětlení pojmů, které tvoří definici:
• Sjednocení – Datový sklad obsahuje data získaná z mnoha podnikových provozních systémů a může být plněn také externími daty. Např. typický datový sklad výrobního podniku vyžaduje integraci dat získaných z výrobních, obchodních a účetních systémů.
Každý z těchto provozních systémů zaznamenává rozdílné typy transakcí. Nejsou-li data integrována, může dojít k situaci, kdy je zákazník veden jak v obchodním, tak v účetním systému a je na něj nahlíženo jako na dvě firmy. Tato skutečnost ovšem není nijak podchycena a zautomatizována a vztahy se zákazníkem jsou spravovány neformálně prostřednictvím vztahů s obchodníky.
DWH spojuje data z mnoha různorodých provozních systémů a poskytuje integrovaný pohled na zákazníka a na plnou šíři z pohledu podniku. Data jsou ukládána do DWH pouze jednou a jsou zpracovávána v rámci celého podniku a ne pouze v rámci oddělení.
• Předmětově orientovaný – běžné provozní systémy jsou zaměřeny na potřeby oddělení či divizí a vytvářejí velmi kritizované „cylindrické“ systémy. S nástupem zpětného inženýrství obchodních procesů začaly podniky využívat procesně zaměřené týmy a pracovníky pro konkrétní případy. Moderní provozní systémy přenesly zaměření na provozní požadavky celého obchodního procesu a zaměřily se na podporu celého obchodního procesu od začátku do konce [HUM2002].
DWH umožňuje informační pohledy na celopodnikové subjekty, jako jsou např. zákazníci, dodavatelé, prodeje či zisky. Tyto subjekty ohraničují jak hranice organizační, tak procesní a pro poskytnutí komplexního obrazu vyžadují informace z více zdrojů.
• Databáze – přestože pojem technologie DWH je používán více méně ve vztahu k technologickým komponentám nutným pro plánování, vývoj, řízení, implementaci a využívání datového skladu, je tento pojem odpovídající i pro velké úložiště dat.
Podstatou všech DWH je rozsáhlá databáze, která obsahuje integrovaná podniková data získaná jak z interních, tak externích zdrojů dat. Pojem interní data zahrnuje všechna data, která jsou získána z provozních systémů provozovaných v podniku. Externí data jsou data poskytnutá třetími stranami, včetně obchodních partnerů, zákazníků, úřadů a organizací, jež se zabývají prodejem svých dat.
• Potřeby pro rozhodování – na rozdíl od databází pro provozní systémy, které jsou často normalizovány pro zajištění a správu datové integrity, je datový sklad navržen a strukturován v nenormalizované podobě z důvodu větší použitelnosti datového skladu. Pokud jsou používány takovéto struktury, mohou uživatelé lépe prohlížet, odvozovat, sumarizovat a analyzovat data na různých úrovních podrobnosti a přes různá časová období [HUM2002].
Databáze jsou navrhovány denormalizovaně z důvodů napodobení úrovně náhledů obchodních uživatelů na obchod. Např. zatímco finanční manažer se zajímá o ziskovost různorodých produktů společnosti, produktový manažer se více zajímá o prodej produktu v různých regionech. Což znamená, že uživatelé DWH potřebují mít možnost „krájet a řezat“ databáze přes různé oblasti a na různých
úrovních integrace a podrobností, aby mohli získat požadované informace.
V tomto smyslu řídící pracovník může spustit obchodní pohled na nejvyšší úrovni, následně zjemňovat a získávat další podrobnosti o oblastech vyžadujících pozornost či naopak.
2.2.4.2 Předpoklady a požadavky datového skladu
Paulraj Ponniah [PON2001] definuje datový sklad z funkčního hlediska jako informační prostředí které:
• poskytuje integrovaný a úplný pohled na firemní data,
• usnadňuje využití historických dat pro rozhodování,
• umožňuje provádění podpory rozhodování bez zatěžování provozních systémů,
• poskytuje konzistentní informace,
• představuje flexibilní a interaktivní zdroj strategických informací.
R. Kimball [KIM2002] shrnuje požadavky na datový sklad v těchto bodech:
• Datový sklad musí umožnit snadnější dostupnost firemních dat. Toho může být dosaženo, pokud data budou pro uživatele jasně a intuitivně uspořádána a bude mít k dispozici uživatelsky příjemnou analytickou aplikaci s odpovídající dobou odezvy.
• Datový sklad musí prezentovat firemní data konzistentně. Předpokladem jsou jasně definované popisy dat dostupné uživatelům a vysoká kvalita integrace dat z provozních systémů.
• Datový sklad musí být přizpůsobivý a připravený na změny.
• Datový sklad musí být zabezpečen, aby chránil firemní data. Datové sklady obsahují důvěrná data o zákaznících, transakcích atd., a proto musí být přístup k těmto datům pečlivě sledován.
• Datový sklad musí sloužit jako základ pro zlepšení rozhodovacích procesů.
• Jestli má být datový sklad považován za úspěšný, musí ho přijmout uživatelé a aktivně ho využívat a podílet se na jeho dalším rozvoji.
2.2.4.3 Účel datového skladu
Abych mohl lépe definovat smysl implementace datového skladu, zhodnotím nejprve běžný stav před jeho zavedením dle [VIT2006]:
• Data jsou rozmístěna v několika primárních systémech.
• Propojení primárních systémů je na velmi nízké úrovni.
• Požadavky na datové výstupy (reporty, exporty, datové pohledy,…) jsou řešeny
„tvůrci reportů“ (správci systémů, informatici, administrátoři)
• Vytváření konsolidovaných datových výstupů je velmi obtížné.
• Obtížná porovnatelnost datových výstupů z různých oblastí (primárních systémů).
• Velké nároky na „tvůrce reportů“.
• Dlouhá doba na uspokojování požadavků (dny, týdny).
• Nemožnost zadávání neúplně specifikovaných požadavků.
• Nemožnost analýzy dat.
Za hlavní přínosy zavedení datového skladu lze tedy považovat:
• Data v DWH jsou konzistentní a kvalitní dříve, než jsou zpřístupněna uživatelům.
• Možnost analýzy dat, umožněná strukturou ukládání dat v DWH, podporující analytické funkce a zajištující rychlou dobu odezvy, přičemž analytik nemusí studovat datové struktury či vztahy mezi daty.
• DWH zajišťují přístup k jednotným podnikovým datům dříve uzavřených v nepřehledných a obtížně ovladatelných prostředích. Uživatelé se nyní mohou s minimálním úsilím bezpečně připojit do datových skladů prostřednictvím klasické pracovní stanice a přes přehledné uživatelské rozhraní využívat analytické funkce třeba i s grafickými výstupy. Mohou zadávat mlhavé dotazy, které postupně upřesňují.
• Bezpečnost je zajištěna buď nástroji pro koncové uživatele nebo servery, případně oběma stranami.
• V DWH je pouze jedna verze pravdy, na rozdíl od primárních systémů z nichž výstupy mohou být těžko porovnatelné, definuje datový sklad společné principy, pravidla a algoritmy, kterými jsou zpracována veškerá data.
• DWH umožňují snadnou dostupnost dat všem oprávněným pracovníkům, kteří si mohou pomocí klientských analytických nástrojů a obecného dotazovacího nástroje během několika málo okamžiků vytvořit vlastní datové výstupy (reporty, datové pohledy,…).
• DWH přebírá funkci reportingu a exportingu, který byl původně řešen primárními systémy a je vhodným zdrojem pro další specializované aplikace vyžadující konsolidovaná data.
• V DWH jsou data z různých oblastí dostupná na jednom místě, jednotným způsobem a pomocí jednoho uživatelského prostředí.
• DWH se stávají běžným zdrojem informací pro rozhodování v rámci celé firmy, dynamické sestavy umožňují uživatelům pohlížet na DWH z různých úhlů, na různých úrovních podrobností.
2.2.4.4 Technologické řešení DW
V typické struktuře datového skladu jsou data z primárních systémů (ERP, CRM, atd….) přenášena nástroji ETL do vlastního jádra datového skladu, obvykle tvořeného relační databází. Zde jsou 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 analyticky orientované data-marty, obvykle vytvořené jako multidimenzionální databáze, velmi často též podporované jinými typy nástrojů (OLAP nástroje či databáze). Z datových tržišť si je pak vyžadují uživatelé pomocí speciálního klientského nástroje, ať již aplikace k tomu přímo určené či na míru psané, obvykle ve formě tenkého klienta (tj. běžící v okně WWW prohlížeče), nebo např. v Excelu.
Relační databáze
Relační databáze jsou specifické ukládáním dat místo do jednoho velkého úložiště spíše do oddělených tabulek, což zajišťuje vyšší rychlost a flexibilitu. Tabulky vždy popisují nějakou část reálného světa a stejně jako ve skutečném životě, i subjekty zachycované tabulkami mohou být spolu v nějakém vztahu. Jak na tabulky, tak na vztahy mezi nimi (mimochodem implementované opět jako tabulky) se dá pohlížet jako na matematický pojem relace [HUM2002].
Protože je relační databáze vlastním jádrem datového skladu, její správné navržení i fungování rozhoduje o funkčnosti celého řešení. Jednou z vlastností, kterou by měla splňovat, je otevřenost a transparentnost. 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 logický 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.) se provádí pokud možno podle určitého standardu, stejně tak i pojmenování entit. 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.
ETL
Jednou z nejdůležitějších částí projektu budování datového skladu jsou procesy ETL (Extraction, Transformation, Loading), což je důvod proč jim věnuji samostatnou podkapitolu. ETL procesy zabezpečují výběr dat z primárních systémů, jejich transformaci a přenos do datového skladu. Tyto procesy jsou většinou časově nejnáročnější etapou projektu návrhu a implantace BI, zabírají cca 45 % jeho času, popř. až 60% rozpočtu. Proto zde stručně rozeberu většinu nejčastějších problémů, které procesy ETL musí řešit dle [HUM2002]:
• formáty dat – často se setkáváme s různými formáty pro datum, rodné číslo či telefonní číslo. Je nezbytné, aby proces ETL zabezpečil sjednocení formátu těchto hodnot. Dále je vhodné převést měrné jednotky či peněžní měny na jednotný formát, jako např. na 2 desetinná místa, či definovat oddělovaní tisíců tečkou,
• různá terminologie – data jsou získávána z různých zdrojů a je běžné, že se v nich nacházejí různé veličiny se stejnými názvy popř. naopak. Sjednocení terminologie se provádí v počáteční analýze projektu,
• chybějící data – častým problémem jsou neúplná data ve zdrojových systémem, popř. data s chybějícím povinným atributem. Je opět nezbytné toto doplnit, jelikož daná data můžou být nezbytná pro následné analytické aplikace,
• nejednoznačné číselníky - jsou velmi častým problémem u firem, které mají větší počet poboček. Pokud firma nemá centrálně definované číselníky např. zboží, je pravděpodobné, že se číselníky jednotlivých poboček nebudou shodovat. Což při následné centralizaci dat vyvolá závažné chyby v analytických činnostech
závislých na těchto datech.Tyto a podobné skutečnosti je nutné odhalit při analýze datových zdrojů,
• nedodržená referenční integrita – ve zdrojových systémech nemusí být vždy dodrženy referenční integrity, a v důsledku toho jsou mnohdy porušeny relační vazby mezi jednotlivými tabulkami. Tyto vazby jsou však v datovém skladu velmi důležité a musíme proto zabezpečit, aby proces ETL načetl data i ze zdrojů s nevyhovující referenční integritou,
• vícenásobné hierarchie – typickým příkladem vícenásobné hierarchie je časová dimenze s hierarchií rok-měsíc-den. Tato časová dimenze může mít i hierarchii rok-týden-den. Vytvoření dimenze rok-měsíc-týden-den by vedlo k chybným analýzám z datového skladu,
• duplicita dat - při plnění datového skladu se musíme vyhnout vložení duplicitních dat, což je velmi aktuální hlavně pokud máme více zdrojových systémů. Je vysoce pravděpodobné, že se některé údaje nacházejí zároveň v několika z nich. Je nezbytné stanovit, které hodnoty se použijí, případně jak se ověří jejich správnost.
Nepochybně je nutné zajistit vyloučení duplicitních dat z téhož zdroje,
• problém měnících se dimenzí - při plnění datového skladu se vytvářejí tabulky faktů (ukazatelů) a tabulky dimenzí. Dimenze se vytvářejí z dat v číselnících a atributů subjektů jako např. dodavatel, zákazník, data v číselnících a údaje o subjektech se však mohou časem měnit, je proto nutné vyřešit způsob, jak bude zachována kontinuita příslušného subjektu nebo druhu položky i v případě změn atributů.
Proces plnění datového skladu musí být zajištěn vůči uvedeným chybám. Většina chyb je opravena správně vytvořenými procesy ETL, ovšem některé kritické chyby vyžadují manuální opravy. Ty je vhodné evidovat a případně o nich informovat správce DWH či jiné odpovědné osoby či uživatele.