Bankovní institut vysoká škola Praha Katedra matematiky, statistiky a informačních technologií
Kvalita dat v Data Warehouse – nezbytný předpoklad reportingu Diplomová práce
Autor:
Bc. Petr Tesař Informační technologie, správce IS
Vedoucí práce:
Praha
doc. Ing. Bohumil Miniberger, CSc.
Duben, 2011
Prohlášení: Prohlašuji, že jsem diplomovou práci zpracoval samostatně a s použitím uvedené literatury. Svým podpisem stvrzuji, že odevzdaná elektronická podoba práce je identická s její tištěnou verzí, a jsem seznámen/a se skutečností, že se práce bude archivovat v knihovně BIVŠ a dále bude
zpřístupněna
třetím
osobám
prostřednictvím
interní
databáze
elektronických
vysokoškolských prací.
V Praze dne 28. 4. 2011
Bc. Petr Tesař
Poděkování: Tímto děkuji panu doc. Ing. Bohumilu Minibergerovi, CSc., vedoucímu mé diplomové práce, za cenné rady, odborné informace, věcné připomínky a dohled nad mojí prací. Bc. Petr Tesař
Anotace Název mé diplomové práce je Kvalita dat v datovém skladu – nezbytný předpoklad reportingu. V práci si vysvětlíme, co je datový sklad, k čemu je používán a popíšeme si několik způsobů jeho tvorby. Dále se budeme věnovat procesu ETL, problematice, která úzce souvisí s kvalitou dat a jaké problémy mohou nastat při zavádění dat do datového skladu. V další části práce budou popsány datové modely, různé druhy analýz OLAP a také se popíšeme datové kostky. Vysvětlíme si pojem data mining a s ním spojené metodologie reportování. Popíšeme si často používané metody dolování dat. V poslední kapitole se budeme věnovat řídícím procesů zabezpečení kvality dat, kde si pomocí case nástroje ADONIS, vytvoříme model pro zlepšení procesů změny aplikace v datovém skladu a jiné modely.
Annotation The title of my thesis is the quality of data in a datawarehouse - a prerequisite for reporting. The paper will explain what a data warehouse, what is used, and describe a few ways of making. In addition,we will deal with the ETL process, an issue that is closely related to the quality of data and what problems may arise when implementing data into the data warehouse. The next section will describe data models, different kinds of analysis, OLAP, and also describe the data cubes. Explain the concept of datamining and related reporting methodology. We describe a method frequently used datamining. In the last chapter will be devoted to managing the process of securing data quality, where you use CASE tools ADONIS, create a model for process improvement changes to the application in a datawarehouse and other models.
Obsah Úvod .................................................................................................................. 7 1. Úvod do Data Warehouse ........................................................................... 8 1.2 Subjektová orientace ............................................................................................... 10 1.3 Integrovanost ........................................................................................................... 10 1.4 Časová variabilita .................................................................................................... 10 1.5 Neměnnost ................................................................................................................ 10 1.6 Návrh a koncepce projektu datového skladu ........................................................ 11 1.6.1 Hardware ............................................................................................................ 12 1.6.2 Software .............................................................................................................. 12 1.6.3 Datové trhy ......................................................................................................... 12 1.7 Metody budování datového skladu ........................................................................ 13 1.7.1 Metoda velkého třesku ....................................................................................... 13 1.7.2 Přírůstková metoda ............................................................................................. 13 1.8 Činnost datového skladu ......................................................................................... 17 1.8.1 ETL ..................................................................................................................... 18 1.9 Kvalita dat v datovém skladu ................................................................................. 24 1.9.1 Konsolidace dat a adres ...................................................................................... 26 1.9.2 Role pro tvorbu datového skladu:....................................................................... 31 1.9.3 Audit datového skladu ........................................................................................ 33
2. Datové modely Data Warehouse .............................................................. 36 2.1 Analýza OLAP ......................................................................................................... 36 2.2 Datové kostky ........................................................................................................... 38 2.3 Schéma tabulek datového skladu ........................................................................... 40 2.3.1 Hvězdicové schéma ............................................................................................ 40 2.3.2 Schéma Sněhová vločka ..................................................................................... 41 2.3.3 Schéma Souhvězdí.............................................................................................. 41 5
2.4 Varianty OLAP ........................................................................................................ 42 2.4.1 ROLAP (Relational Online Analytical Processing) ........................................... 43 2.4.2 MOLAP (Multidimensional Online Analytical Processing) .............................. 44 2.4.3 HOLAP (Hybrid Online Analytical Processing) ................................................ 46 2.5 Základní operace v OLAP systémech .................................................................... 47 2.6 OLTP ........................................................................................................................ 48 2.7 Rozdíly mezi OLTP a OLAP .................................................................................. 48
3. Reportování dat (Data mining) ................................................................ 51 3.1 Metodologie CRISP-DM ......................................................................................... 52 3.2 Nejpoužívanější techniky Data miningu ................................................................ 58 3.2.1 Rozhodovací stromy (Decision trees)................................................................. 58 3.2.2 Neuronové sítě (Artifical neural networks) ........................................................ 59 3.2.3 Detekce shluků (Clustering detection) ............................................................... 59 3.2.4 Analýza nákupního košíku (Market basket analysis) ......................................... 60 3.2.5 Rozhodovací pravidla (Decision rules) .............................................................. 60 3.2.6 Asociační pravidla .............................................................................................. 60 3.2.7 Analýza závislostí ............................................................................................... 60
4. Řízení procesů zabezpečení kvality dat v Data Warehouse .................. 61 4.1 Nástroje pro popis procesů ..................................................................................... 61 4.1.1 UML ................................................................................................................... 61 4.1.2 VISIO ................................................................................................................. 62 4.1.3 ADONIS ............................................................................................................. 62 4.2 Návrh na zlepšení procesu změny údaje v Data Warehouse ............................... 63 4.3 Role při tvorbě datového skladu ............................................................................ 65
Závěr ............................................................................................................... 69 Seznam použité literatury ............................................................................. 70 Seznamobrázků ............................................................................................. 72 Seznam tabulek .............................................................................................. 73 6
Úvod V dnešní době kdy konkurence na trhu roste velmi rychle a zvyšují se i potřeby zákazníků. Musí každá organizace nebo společnost tyto potřeby řešit a snažit se být čím dál více konkurenceschopnější. Proto musí volit správná a rychlá rozhodnutí v čemž jím pomáhají nástroje Business Intelligence. Nasazením těchto nástrojů do všech odvětví organizace nebo společnosti vzniká obrovské množství shromažďovaných dat a údajů, které bez vhodných prostředků a technologií nejsou schopni zpracovat. Jedním z těchto nástrojů je datový sklad (Data Warehouse), který je schopný velké objemy dat zpracovat a následně pomocí reportů může uživatel vytěžit jemu potřebná data. S tímto termínem je úzce spjata kvalita dat, protože jak víme, bez kvalitních dat nelze odvést kvalitní práci a v horších případech může dojít i ke špatnému rozhodnutí v organizaci, což může mít za následek velké finanční ztráty nebo pokud by se jednalo a strategické rozhodování, dokonce její zánik. Cílem práce je popsat funkčnost a problematiku Data Warehousingu, definovat a popsat procesy řízení kvality dat v Data Warehouse. V první kapitole se budeme zabývat vysvětlením co je to datový sklad a k čemu slouží. Dále si popíšeme návrh projektu datového skladu, metody jakými se datový sklad tvoří. Vysvětlíme se pojem ETL a problémy s ním spojené. Stručněji si popíšeme kvalitu dat a problémy, které mohou vzniknout ve spojení s tímto tématem a jak se dají zmírnit nebo eliminovat. Druhá kapitola se zabývá datovými modely, analýzou OLAP a jejími druhy jako je MOLAP, ROLAP a HOLAP. Popíšeme si různé schémata tabulek datového skladu. Probereme základní operace v analýze OLAP, stručně popíšeme technologii OLTP a rozdíly mezi nimi. A v neposlední řadě osvětlíme pojem Datová kostka. Reportováním dat neboli Data Miningem se zabývá kapitola třetí. Zde jsou popsány metodologie reportu, podrobněji je popsána metodologie CRISP – DM. Dále jsou popsány nejpoužívanější techniky dolování dat. V poslední čtvrté kapitole popíšeme nástroje pro popis procesů. Kde pomocí jednoho zvoleného, budou na základě teoretických poznatků z předchozích kapitol, namodelovány návrhy na zlepšení procesů.
7
1. Úvod do Data Warehouse Datové sklady (Data Warehouse) jsou technologií, která v současné době je nezbytností skoro každého podniku, kde si podnikový management nedovede představit svou práci bez Business Intelligence nástrojů. Nasazování informačních technologií skoro do všech odvětví, s sebou nese velké shromažďování různých údajů, jak údaje o technologických zařízeních, administrativě a podobně. Ve všech případech dochází k nashromáždění velkého objemu dat. Dnešním trendem jsou moderní databázové servery, které umožňují bezpečnou a rychlou práci s tímto množstvím dat a umožňují z nich čerpat cenné informace. Mnoho lidí si plete pojmy data a informace. Pro vysvětlení data se stávají informacemi pokud: máme data, víme, kde máme data uložená, máme k datům přístup a zdroji dat můžeme důvěřovat. „Zjednodušeně lze data charakterizovat jako libovolnou posloupnost znaků, přičemž se nemusí jednat pouze o bity či bajty. Pod posloupností se totiž mohou skrývat libovolné znaky, třeba i ty, které vůbec neznáme či u kterých si nedokážeme představit, že jde o nějaké písmo či znak. Samo o sobě jsou tedy znaky této posloupnosti jen jakási "suchá, bezbarvá" data, která nám mohou, ale nemusí něco říkat. Pojem informace je totiž spojen až s nějakým konkrétním významem. Lze říci, že z dat se stávají informace teprve tehdy, pokud jsme z nich (tedy v roli příjemce) schopni získat nějaké poznatky, vědomosti. Pokud tedy příjemce rozumí významu v datech ukrytém, znamenají pro něj data také nějakou informaci. Je nutné si ale uvědomit, že ne všechna data musí nést nějakou informaci“1. Procesem zpracování těchto informací je náplní informačního systému. Podle Wikipedie „Informační systém (IS) je soubor lidí, technologických prostředků a metod, které zabezpečují sběr, přenos, zpracování a uchování dat za účelem tvorby prezentace informací pro potřeby uživatelů. Dále na stejném odkaze najdeme jeho stručný rozbor způsobů jeho implementace: Implementaci informačního systému předchází většinou důkladná analýza požadavků firmy i samotných procesů, které se ve společnosti používají. Většina systémů se implementuje jako tzv. datové sklady, což je architektura (obvykle založená na SŘBD), jež transformuje operativní data do jiné podoby, u které se bere ohled například na čas a rychlost následných dotazů. Tato data se nemění, mohou se transformovat z více zdrojů (např. od dodavatelů) a jsou aktualizována v časových intervalech. Nad nimi se dělají statistiky či analýza. To je poslední fáze - OLAP (Online Analytical Processing)“ A dále se 1
Poláková Jiřina, Kalousková Eva, Univerzita Pardubice, Data, informace, znalosti - rozdíly, podrobnosti [on line][ cit. 2011-02-07]. Dostupné z: http://knowledgemanagement.ic.cz/informaceznalosti.doc
8
ve stejném zdroji uvádí: „Systémy OLAP jsou implementovány buď nad relačními databázemi, nebo nad speciálními (zejména objektovými) OLAP databázemi“2Je zde popisována OLAP databáze, kterou si podrobněji popíšeme ve 2. Kapitole. Jiná definice datového skladu pochází od guru datawarehousingu od Billa Inmona. „Datový sklad je podnikově strukturovaný depozitář subjektově orientovaných, integrovaných, časově proměnlivých historických dat použitých na získávání informací a podporu rozhodování. V datovém skladu jsou uložena atomická a sumární data“3. Jednodušeji řečeno datový sklad dle Inmona je jedna část z celého business intelligence podniku a zdrojem informací pro datové tržiště je právě datový sklad. Na obrázku 1.1 vidíme grafické znázornění Datového skladu podle Inmona. Na druhou stranu je nutné také zmínit definici datového skladu podle Kimballa. Kimball tvrdí, že datový sklad je konglomerát všech datových tržišť v rámci podniku. Údaje se ukládají do operačních databází, které se mohou nacházet v různých odděleních firem nebo v různých geografických lokalitách. Tyto údaje se v pravidelných intervalech sesbírají, předzpracují a uloží do datového skladu. Datový sklad sám o sobě tvoří také databázi, což je soubor technologií pro efektivní využití údajů za účelem podpory rozhodovaní.
Obrázek 1Grafické znázornění Datového skladu podle Inmona (vlastní úprava). Nyní si vysvětlíme pojmy, které pan Inmon ve své definici Datového skladu zmiňoval.
2
Informační systém [on line][2011-02-07] Dostupné z: http://cs.wikipedia.org/wiki/Informa%C4%8Dn%C3%AD_syst%C3%A9m 3 Lacko, Luboslav. Databáze: Datové sklady, Olap a dolování dat s příklady v SQL Serveru a Oracle. 1.vyd. ComputerPress. 2003. ISBN 80-7226-969-0
9
1.2 Subjektová orientace Údaje se do datového skladu zapisují podle předmětu zájmu a ne podle předmětu aplikace. Při orientaci na subjekt jsou data řazena podle subjektu, což může být: dodavatel, zákazník, výrobek a podobně. Na druhou stranu při orientaci na aplikaci, znamená, že data jsou v datovém skladu uloženy podle aplikace, kde si představíme aplikace pro odbyt, pro fakturaci a jiné.
1.3 Integrovanost Data v datovém skladu musí být integritní. To znamená, že data, která se týkají jednoho předmětu, musí být uložena jen jednou. Proto je nezbytné zavést jednotnou terminologii, jednotné a neměnící se jednotky veličin. Toto je složitá věc, protože data, která se ukládají do datového skladu, jsou nekonzistentní a jsou z neintegrovaného operačního prostředí. Proto musí být upraveny, vyčištěny a sjednoceny, pokud se tak nestane, tak datový sklad ztrácí svůj význam.
1.4 Časová variabilita Data se ukládají jako určitá série snímků, kde každý z nich je reprezentantem určitého časového úseku. Oproti operačnímu databázovému prostředí, kde jsou údaje platné v okamžiku přístupu a data jsou ukládány za kratší časové období, většinou několik dní, maximálně měsíců, tak v datovém skladě jsou platné pro určitý časový snímek a jsou ukládány za delší časové období, většinou několik roků. Mezi klíčové atributy v datovém skladě patří čas, který se nemusí u operačního databázového prostředí uvádět.
1.5 Neměnnost U operačních transakčních databází jsou data vkládána, modifikována a mazána. V datovém skladu tomu tak není. Data se pouze doplňují v pravidelných intervalech. Proto manipulace s daty je mnohem jednodušší než u operačních transakčních databází. V datovém skladu jsou pouze dva typy operací, které můžeme provádět s daty, zavedení dat do datového skladu a přístup k těmto datům. Rozdíly mezi produkčními databázemi a datovým skladem jsou zobrazeny v tabulce 1.
10
Vlastnosti
Produkční databáze
Datový sklad
Čas odezvy
Zlomky sekund až sekunda
Sekundy až hodiny
Operace
DML
Primární jen na čtení
Původ dat
30-60 dní
Série snímku za určitý interval
Organizace dat
Podle aplikace
Podle předmětu, času, atd.
Velikost
Malá až velká
Velká až velmi velká
Zdroje dat
Operační, interní
Operační, interní, externí
Činnosti
Procesy
Analýza
Tabulka 1 Rozdíly mezi Produkčními databázemi a datovým skladem. Jednou z možností datového skladu je, že zde můžeme vykonávat analýzy pro potřeby k rozhodování manažerů, obchodníku, atd. K těmto údajům a výsledkům analýz, mají většinou přístup přes webové rozhraní, manažeři firmy po celém světě a jejich obchodní partneři, pomocí přidělených práv. Velkou výhodou poskytnutí informací z datového skladu svým obchodním partnerům je, že se nám vrátí určitá část nákladů na datový sklad. Protože k vytvoření datového skladu je nezbytně velká počáteční investice. Při poskytnutí informací, například dodavatel obchodního domu ocení informace o tom, jaké zboží jde na odbyt, jaké zboží bude vyžadováno zákazníky domu v následujících týdnech.
1.6 Návrh a koncepce projektu datového skladu Projekt je soubor aktivit zaměřený na dosažení předem stanovených cílů. Kde je potřeba určit rozpočet projektu a časový rozvrh. „Proces řízení projektu se týká koordinace lidských, materiálních a finančních zdrojů a je zaměřený na dosažení dopředu stanovených cílů v daném rozsahu, nákladech, čase, kvalitě a spokojenosti účastníků projektu. Asi největší procento z hodnoty datového skladu se skrývá v jeho návrhu a koncepci. Know how a to nejen v oblasti datových skladů, ale hlavně v oblasti podnikání firmy, je zkrátka to nejcennější co firma má, když samozřejmě nebereme v úvahu firemní značku zavedené firmy. V tomto případě si kvalitu, na rozdíl od hardwaru a softwaru, nelze koupit, kvalitu je potřeba vytvořit, případně ji pro firmu vytvoří dobře placený tým konzultantů a vývojářů“4. V dnešní době jde rozvoj IT tak rychle vpřed, že není v silách interních
4
Lacko, Luboslav. Business Intelligence v SQL Serveru 2008. 1.vyd. ComputerPress. 2009. ISBN 978-80251-2887-9
11
zaměstnanců řešit problematiku k vytvoření datového skladu. Projekt vytvářený interními zaměstnanci by trval příliš dlouho a pravděpodobně by nebyl natolik konkurence schopný, aby se vyplatil. Proto management mnohých firem najímá externí vývojáře, kteří zvládnout projekt vytvořit v kratším čase a v dostatečné kvalitě. Úkolem externích konzultantů v oblasti vytvoření datového skladu je vhodný výběr hardwaru a softwaru, návrh architektury a optimální sestavy softwarových technologií a využití nejnovějších informačních technologií v různých oblastech podnikání.
1.6.1 Hardware Co se týče nákladů, tak hardware je nezanedbatelná položka, z hlediska datového skladu se jedná pouze o technické prostředky, které se dají nahradit. Jedná se pouze o prostředky, ne data v nich uložená. A tak je zapotřebí uvážit, zda chceme v přímé úměře výkon a spolehlivost nebo jen cenu. Pro rychlý přístup k obrovskému množství dat je zapotřebí výkonných serverů nebo velkých datových center.
1.6.2 Software Nástroje pro tvorbu datových skladů a k analýze dat jsou také drahou položkou. V dnešní době je trendem integrace analytických služeb přímo do instalací databázových serverů, kde se za některé analytické služby platí licenční poplatky zvlášť nebo jsou v ceně serveru.
1.6.3 Datové trhy Datové trhy (Data marts) jsou menší datové sklady, v podstatě je to podmnožina datových skladů, kterou jsou vytvořeny pro organizační složky firmy na nižší úrovni hierarchii, případně slouží k ukládání dat z některých vybraných oblastí podnikání. Datové trhy obsahují informace, které pocházejí z jednoho zdroje (např. personální útvar), na rozdíl od datových skladů, které uchovávají informace z více zdrojů (finanční útvar, výroba, od dodavatele). Vytvořit datový sklad je velmi finančně náročné, proto se někdy vytváří po částech, to znamená, že pro důležité organizační složky se vytvoří podmnožiny datového skladu – datové trhy. Datové trhy mohou vzniknout i opačným postupem, z datového skladu se vytvoří určité množství datových trhů.
12
1.7 Metody budování datového skladu Při budování datového skladu je nejdůležitější vybrat vhodnou metodu budování. Je potřeba brát v úvahu organizační a informační strukturu firmy, ale také předvídat potíže, které se nevyhnutelně objeví. Mezi nejznámější metody patří: Metoda velkého třesku Přírůstková metoda
1.7.1 Metoda velkého třesku Velký počet firem a vývojářů se domnívá, že je možné provést implementaci datové skladu pomocí jednoho projektu. Vývoj datového skladu je složitá záležitost a je málo pravděpodobné, že se jí podaří vyřešit hned na poprvé a v rozumném čase. Toto je veliké riziko projektu, protože kdyby se zrealizoval datový sklad pomocí metody velkého třesku, mohou se mezitím změnit technologie, ale i požadavky uživatelů. Metoda se skládá ze tří fází: Analýza požadavků podniku Vytvoření podnikového datového skladu Vytvoření přístupu buď přímo, nebo přes datové trhy Jediná výhoda této metody je fakt, že celý projekt lze kompletně vypracovat ještě před začátkem jeho realizace. Protože vytváření datového skladu je vyvíjející se proces, při kterém se změní nejen technologie, ale i požadavky uživatelů, nemůžeme tento fakt považovat za skutečnou výhodu. Spíše převažují nevýhody, jedna z nich je, že trvá velmi dlouho dobu, než se dostaví první výsledky obrovských investic do datového skladu, což znamená, než se dostaví obchodní zisk.
1.7.2 Přírůstková metoda Přírůstková metoda, také známa jako evoluční, předpokládá vytváření datové skladu po jednotlivých etapách, to znamená, že místo vybudování celého datového skladu jak tomu bylo u předchozí metody, zde budou postupně přibývat přírůstková řešení, které zapadají do komplexní architektury datového skladu. Většinou se začne s vybudováním několika málo předmětných oblastí, zpravidla jednou nebo dvěma. Tyto řešení implementujeme jako datový trh a poskytneme ho používání koncovým uživatelům. Tím to krokem je management částečně spokojen, protože určitá část investic je navrácena. Jeli částečné 13
řešení skutečně otestované koncovými uživateli a osvědčí se jako funkční, můžeme do systému vložit další předmětnou oblast, tím se získá nová funkcionalita. Tak to se dá pokračovat, až do úplného vytvoření datového skladu. Vytváření datového skladu přírůstkovou metodou je opakující se proces, který neustále udržuje spojitost mezi požadavky uživatelů a datovým skladem. U přírůstkové metody převyšují výhody než nevýhody, právě naopak než tomu bylo u metody velkého třesku. Mezi výhody přírůstkové metody patří: Přírůstkové vytváření datového skladu zachovává spojitost budovaného projektu s požadavky a potřebami uživatelů Umožňuje implementovat rozšířitelnou architekturu Zabezpečuje rychlejší zisk i rychlejší návratnost investic Na obrázku 2. je znázorněné schéma přírůstkové metody, jsou zde zobrazeny pouze dva cykly.
Obrázek 2 Schéma přírůstkové metody (vlastní úprava). Přírůstková metoda se skládá z šesti fází: Strategie Definice Analýza Návrh Sestavení 14
Produkce
Strategie V této fázi přírůstkové metody se definují cíle, jednal cíl podnikání, účel řešení a základ architektury podnikového datového skladu. Z toho to důvodu by měla být fáze strategie plně v rukou vrcholového managementu. Kde cíle podnikové strategie mohou být krátkodobé nebo dlouhodobé. U dlouhodobého cíle projektu datového skladu je zahrnuto jeho vytvoření, definice strategie správy datového skladu a počítá se zde i s dokumentací datového skladu, ale i se zaškolením jeho uživatelů.
Definice Zde se definuje rozsah a cíl přírůstkového vývoje. Nejprve se vytvoří počáteční přírůstek, konceptuální modely, zdokumentují se zdroje dat a vymezí se jejich rozsah kvality. Dále se navrhuje architektura datového skladu i technických prostředků. U této fáze je nejlepší čas na pochopení struktury operačních a externích zdrojů dat.
Analýza Analýza se zaměřuje na informace týkající se uživatelů, slouží k získávání dat a požadavkům k přístupu k datům pro obchodní analýzu a přijímání rozhodnutí. Dále jsou tvořeny relační a multidimenzionální modely pro datový sklad, metadata, kde se řeší problémy kvality dat a určují se požadavky na metadata a je-li to potřeba, jsou tvořena i pro datový trh. V této fázi se dokončí výběr nástrojů pro všechny komponenty datového skladu.
Návrh Zde se transformují požadavky, které se získaly během analýzy do detailních podmínek návrhu a dokončují se instalace technické architektury.
Sestavení U této fáze se vytvoří a otestují navržené datové struktury, moduly správy datového skladu, moduly získávání dat, moduly metadat, moduly přístupu k datům, sestavy a dotazy.
15
Produkce Poslední fáze má za úkol přejít na produkční stav, to znamená, že se nainstaluje datový sklad, který se používá jen ve zkušebním provozu a časem se přejde na normální provoz. Společně s provozem je nutné řídit růst a údržbu datového skladu. Přírůstková metoda se dále dělí: Přírůstková metoda směrem shora dolů Přírůstková metoda směrem zdola nahoru
Přírůstková metoda směrem shora dolů U této metody se jako první na základě uživatelských požadavků vytvoří konceptuální model datového skladu, kde důležitou roli hraje stanovení hierarchie předmětných oblastí. Dále jsou postupně vytvořeny datové trhy pro jednotlivé předmětové oblasti v rámci struktury datového skladu. Tato metoda zaručuje rychlé začlenění jednotlivých datových trhů, a tím rychlou návratnost investic. Jedna z výhod této metody je, že není tolik zatížena rizikem, jako bylo u metody velkého třesku a není tolik náročná na analýzu. Velká nevýhoda však je, že tato metoda vyžaduje větší vstupní investice, ještě před tím než je možné předvídat jejich návratnost. Schéma je vyobrazeno na obrázku 3.
Obrázek 3 Schéma Přírůstkové metody shora dolů (vlastní úprava).
Přírůstková metoda směrem zdola nahoru Metoda je velmi podobná předcházející metodě, s tím rozdílem že u této metody jsou hlavní prioritou data než obchodní zisk. Nejprve se vybudují datový trhy předmětných 16
oblastí, ale v rámci celé struktury datového skladu. Nevýhoda této metody je že se konceptuální model vyvíjí od zdrojových systémů, proto je někdy celková implementace problematická. Většinou se IT oddělení dozvídá o připravovaných změnách a strategických záměrech jako poslední, proto mohou navrhnout a zrealizovat něco co už v tu dobu nebude pro podnik aktuální.
Obrázek 4 Přírůstková metoda zdola nahoru (vlastní úprava).
1.8 Činnost datového skladu Datový sklad je dlouhodobým úložištěm dat, kam data, která jsou shromážděná informačními systémy, periodicky přibývají po určitých dávkách neboli loadech. Odezva na dotazy nemusí být okamžitá, jak je tomu vyžadováno u informačních systémů. U datového skladu je dovolena redundantnost neboli možnost uložení stejných dat vícekrát. Data, která se jsou uložená v datovém skladu, nejsou nikdy mazána, ale je zde možnost souhrnného shrnutí některých dat a zálohovat je na externí media. Jedním z problémů datového skladu je to, že data, která do něj mají být uložená, většinou pochází z nekonzistentních prostředí. Tím je myšleno, že jsou uloženy v odlišných strukturách, formátech, některé mohou být i nestrukturované (běžný text, e-maily), mají odlišnou filozofii záznamu, jsou uloženy na různých médiích. K tomuto problému může dojít jak v rozsáhlých projektech státní správy, ale i v jediném podniku, který má řadu poboček. V souvislosti s touto problematikou se vyskytuje termín ETL.
17
1.8.1 ETL Název ETL vznikl ze spojení prvních třech písmen ze slov a to Extraction, Transformation a Loading. Někdy se také používá zkratka ETT což je spojení obdobné s tím rozdílem, že poslední písmeno znamená Transport. My budeme používat české výrazy a to Extrakce, Transport a Zavedení. Celý proces je komplexní a časově náročný, proto u některých implementací může trvat více, než polovinu celkového času, s tím jsou spojené i větší náklady na vytvoření datového skladu. Jakou roli hraje v tvorbě datového skladu ETL znázorňuje obrázek 5.
Obrázek 5 ETL v procesu zavedení dat do datového skladu(vlastní úprava).
Extrakce Data, která je potřeba přenést do datového skladu jsou většinou uložena v nekonzistentním operačním prostředí, různé databázové standardy, nedatabázové strukturované formáty, textové soubory, standardy elektronické pošty, apod. V současné době je obvyklé že datové sklady mají předem definovanou spojitost s databázovými standarty, ale i na standarty s prostředí ERP5 (například SAP, Oracle). Dalším důležitým zdrojem informací jsou webovské logovací soubory a protokoly, které zapisují každé kliknutí na internetovských stránkách po celém světě, z toho se dají vyčíst informace o chování jak našich tak i potenciálních zákazníků. Na internetu je možné nalézt například historie měnových kursů, vývoj ekonomických indexů, cen akcií, proto je zapotřebí neustále monitorovat externí data za účelem určení doby dostupnosti. Kromě interních dat, chceme také pracovat s externími daty, tyto data se dají získat od svých obchodních partnerů, analýzou konkurenčního trhu, zakoupením dat o zákaznících a jinými způsoby. Pro 5
ERP- Enterprise resource planning – informační systém, který automatizuje a integruje velké množství procesů, které souvisí s produkčními činnostmi podniku.
18
extrakci jsou dostupné nejrůznější postupy, technologie a nástroje. Můžeme si vytvořit vlastní aplikaci v programovacích jazycích například v Delphi, C++, C# a podobně. Pro menší objem dat je vhodné vytvořit přístupovou bránu, ale tato metoda při větším objemu dat zatěžuje síť, proto je někdy možné použít výstupy s vlastních podnikových systémů, které nám umožní změnu a vyčištění dat. U etapy ETL by měli být k dispozici metadata pro všechny její fáze, kde metadata obsahují informace o místě, typu, přístupových oprávněních a struktuře zdroje dat. V souhrnu můžeme extrakci chápat jako pracovní etapu, v nichž usilujeme o přesné, rychlé, bezpečné a dobře ovladatelné načtení dat z co možná nejvíce externích datových zdrojů. Tato fáze se opakuje s určitou periodicitou a po jejím skončení jsou potřebná data načtena přímo do připravených zdrojových struktur pro extrahovaná data.
Transformace Transformace je posloupnost řady operací, která extrahovaná data připraví pro načtení do datového skladu. Základ transformace je vytvoření určité programové logiky, která vykoná převod mezi zdrojovými strukturami, která obsahují počáteční data, a cílovými strukturami, které jsou zdrojem pro pozdější vyvolání dat. Definice zdrojových a cílových struktur celého procesu transformace a určitých pravidel, která zkontrolují, doplní nebo změní data, pokud nejsou správná, je náročným a specifickým úkolem pro každý projekt. Je možné, že se nekvalitní data vyskytují ve zdrojových systémech a jejich používání směřuje k chybným nebo nesprávným sestavám, dále pak k chybným obchodním rozhodnutím. „Když jsou data, která slouží jako podklad pro získávání informací pro podporu rozhodovaní, nebo data v datovém skladu nekvalitní, snižuje to důvěru v takové řešení a datový sklad se oprávněně nepoužívá“6. Můžeme mít nekvalitní data, dokonce, i když jsou úplně přesná, ale nevyhovuje nám jejich forma uložení. Pro představu chceme oslovit určitou skupinu našich klientů prostřednictvím poštovních zásilek, máme údaje o jejich adresách, které nám poskytli obchodní zástupci firmy v následující podobě:
6
Lacko, Luboslav. Business Intelligence v SQL Serveru 2008. 1.vyd. ComputerPress. 2009. ISBN 978-80251-2887-9
19
Jméno
Adresa
Santiago Canizares
BayleRoad 1125 Tlaxiaco 15098 Mexico
WayneLindros
Down Avenue 9982 Ottawa 27319 Canada
Berry Jane
Wallstreet 7625 Chicago 66187 USA
SpencerDoyl
Downhill 3542 Ottawa 27319 Canada
Tabulka 2 Údaje o klientech. Takové údaje nám nepomohou k automatickému vyplnění adres na poštovních obálkách, i když to zkusíme, hodně se nám jich vrátí zpět. Proto je lepší databáze klientů, která je normalizována a lze ji použít v jakémkoliv kancelářském softwaru. Normalizovaná tabulka může vypadat například takto: Jméno
Adresa
Město
PSČ
Země
Santiago
BayleRoad 1125
Tlaxiaco
15098
Mexico
Down Avenue
Ottawa
27319
Canada
Canizares WayneLindros
9982 Berry Jane
Wallstreet 7625
Chicago
66187
USA
SpencerDoyl
Downhill 3542
Ottawa
27319
Canada
Tabulka 3 Údaje o klientech v normalizované databázi. Transformace těchto dat lze použit například při akvizicích jiných společní, kde se provazují data z ERP, ale i seznamy klientů. V potaz musíme vzít i kromě těchto technických záležitostí, lidský faktor, například pravopisné chyby, různé překlepy a změnu pořadí zadávání. V průběhu čištění dat sjednocujeme formátování dat, pořadí datových typů, jednotek a peněžních měn. Transformaci je možné provádět sériově nebo paralelně se zadáváním dat. U sériové se transformace provede před zavedením dat do datového skladu, u paralelní se transformace provede současně se zadáváním dat do datového skladu. Při transformaci můžeme narazit na několik problémů: Nejednoznačnost dat Chybějící hodnoty Duplicitní záznamy Nejednotnost pojmů a objektů Nejednotnost peněžních měn Nejednotnost formátů čísel a textových řetězců Problémy s referenční integritou 20
Chybějící datum Nejednoznačnost dat: Tento problém se vyskytuje v uložení dat stejného typu v různé formě. Příklad je uveden v tabulce. Name
Gender
Jane Briget
Woman
Lucy Parker
Female
John Cash
Man
DerrenClark
Male
Tabulka 4 Údaje o pohlaví klientů. Po transformaci by tabulka měla vypadat takto, kde sloupec pohlaví je v jednotném tvaru: Name
Gender
Jane Briget
F
Lucy Parker
F
John Cash
M
DerrenClark
M
Tabulka 5 Údaje o pohlaví klientů v normalizované tabulce. Chybějící hodnoty a duplicitní záznamy: Chybějící hodnoty nebo duplicitní záznamy oba tyto faktory snižují kvalitu datové skladu. Duplicita údajů je menším problémem, než chybějící údaje, kde některé sloupce relačních databází obsahují hodnotu NULL. U duplicity není problém přebývající údaje odstranit, na druhou stranu nalezení a odstranění duplicitních údajů je velmi časově náročné. Nejednotnost pojmů a objektů: Při slučování údajů z různých zdrojů, když popisují stejný jev, ale jejich entity jsou jinak pojmenovány, musíme sloučit terminologii a vytvořit společnou a jednotnou dohodu názvů. Nejednotnost peněžních měn: Vezme si příklad, peněžní hodnota 100$ je jiná peněžní hodnota než 100Kč. Toto je neustále aktuální problematika, protože stále více zemí přechází na euro, proto se v přechodném období uváděli obě měny jak euro tak měna příslušné země.
21
Nejednotnost formátů čísel a textových řetězců: Data se ukládají v relačních databázích a souborech v různých druzích formátů. Velkým problémem je ukládání číselných údajů s pohyblivou řádovou čárkou. Pro typy těchto dat se používají numerické formáty, ve zdrojových databázích a dokumentech se používají řetězcové datové typy. V numerických formátech je číslo uloženo jako numerická hodnota, v řetězcových datových typech se ukládá jako posloupnost číslic a jiných znaků. Problém je v tom, že například rodné číslo může být uloženo ve formátu 8110208888, kde je možno ho uložit jako číslo i jako textový řetězec. Ale většinou se rodné číslo ukládá s lomítkem 811020/8888, v tomto případě může být uloženo jen jako textový řetězec, protože některé tabulkové procesory, při špatném návrhu šablon, by toto číslo brali jako matematickou operaci dělení. Problémy s referenční integritou: Krom hodnot jsou v údajích skryté i jiné údaje, například organizační struktury firmy, hierarchická struktura zaměstnanců a jiné. Tyto údaje jsou dynamické, organizační struktura se mění, většinou bez jakékoliv dokumentace a změn v OLTP databázích. Pokud se zruší nějaké oddělení firmy, zůstanou po něm nějaké záznamy, které mohou zkreslit data, a tím ovlivnit kvalitu dat. Chybějící datum: Čas je jedním z významných atributů v datovém skladě. V transakčních systémech se data nemusí označovat časovým údajem, ale u některých je to vyžadováno, například při objednávce zboží nebo určité transakce. Před zavedením dat do datového skladu, by měly tyto data obsahovat časový údaj, popřípadě ho určit a přidat čas při zavádění dat. V souhrnu je tedy transformace chápána jako úkol k získání co nejkvalitnějších dat, protože informace, jsou tak kvalitní, jak kvalitní jsou data. Z toho dále vyplívá, že datový sklad je kvalitní, tak jak je kvalitní každý jednotlivý záznam v něm. Pokud bychom měli nekvalitní a chybná data, budou nekvalitní i odpovědi na naše dotazy a tím datový sklad ztrácí význam.
Přenos Přenos je poslední část celého procesu ETL. Jedná se o fyzický přenos dat ze zdroje dat do cílové databáze nebo datového skladu. Přenos je realizován v přesunu dat a jejich uložení do databázových tabulek. Ten to přenos by měl být automatizovaný, plánovaný a optimalizovaný. Při úplně prvním naplnění datového skladu se jedná o velké množství dat. V dalších fázích se nové údaje zavádějí v pravidelných časových intervalech, o objemu 22
dat, který vznikne za určité období v OLTP databázi nebo se zavádějí po volbě uživatele – správce datového skladu. Po zavedení dat začíná jejich indexování, to umožňuje optimalizovaný přístup k těmto datům. Pro identifikaci údajů se využívají uměle vytvořené klíče. Díky těmto klíčům je u každého řádku v tabulce zajištěna jeho jednoznačnost. V datovém skladu jsou data v mnoha případech kombinací určitého množství transformovaných záznamů, které nemají vlastní přirozené klíče, které by se dali využít k jejich jednoznačné identifikaci. Vlastnosti nástroje pro tvorbu kvalitního datového skladu, a tím i zajištění kvalitního průběhu všech tří etap procesu ETL, jsou popsány níže. U procesu Extrakce by měl nástroj být schopen připojit co možná nejširší spektrum formátů datových zdrojů a možnost připojení ERP systémů, webových logů a formátů elektronické pošty. Měl by maximálně využít současných a modulárních doplnění nových standardů. Dále by měl obsahovat kvalitní a velké úložiště dat. U dalšího kroku procesu, což je Transformace by měl být nástroj uživatelsky zvládnutelný na výstavbu cílových a zdrojových struktur a pro jejich vzájemné mapovaní. Automaticky by se měli tvořit datové struktury ze známých standardů a měla by zde být použita technologie drug and drop. V poslední části procesu Přenos, patří mezi požadavky na nástroj k tvorbě datového skladu, jednak kvalitní a přehledné uživatelské prostředí pro dotazování a předdefinované pohledy, dotazy na datový sklad a reporty.
Testování procesu ETL Proces ETL se nejprve testuje na simulovaných datech a později na „ostrých“ datech. K tomuto účelu se pro vytvoření testovacího prostředí využívají v dnešní době virtuální počítače a servery. Hned při prvních testech se projeví, zdali byl proces ETL dostatečně a dobře zdokumentován. Avšak po otestování a následně plném nasazení do provozu, nemáme jakoukoliv jistotu, že všechno bude stále fungovat, tak jak si představujeme a to z důvodu, že roste poměrně rychle objem datového skladu, a tím se mění dynamika systému. Proto je nutné pravidelně sledovat metriku zavádění a podrobnou identifikace jednotlivých dat a jejich ověření. Když nejsou data ověřená, často dochází k problémům při extrakci a transformaci. V důsledku závažnosti problému, lze začít znova, nebo je postačující začít z místa selhání. Nepřesná a neúplná data často vedou k nesprávným výsledkům analýz, což v jejich důsledku vede k nesprávným obchodním rozhodnutím a v nejhorším případě ke strategickým rozhodnutím. 23
Ne vždy se stane, že proces ETL proběhne úspěšně. A to z několika důvodů, například může nastat problém s úložištěm dat, ty mohou být mechanického rázu a tím pádem dochází k jejich opotřebení. Může docházet k výpadkům spojení během přenosu dat, zdroje dat mohou být při upgradu OLTP systému přejmenovány.
1.9 Kvalita dat v datovém skladu Nedílnou součástí každého informačního systému je neodmyslitelně kvalita dat. A to od transakčních systémů TPS, systémů, které slouží pro manažerské řízení MIS, systémy pro rozhodování EIS, které využívají OLAP architekturu. Propojení těchto systémů je znázorněno na obrázku 6.
Top mangement
Střední management OI
S
I
ED
Analytici a specialisté
MI S Wa Dat a reh ou se TP S
Ředitelé odborů
EIS
Představenstvo, dozorčí rada
Odborní pracovníci
Obrázek 6 Hierarchická struktura informačních systémů podniku7 „Již při zběžném pohledu na strukturu a hierarchii IS je zřejmé, že v Datovém skladu – DS (Data Warehouse), který přebírá data z transakčních systémů, bude kvalita uložených dat funkčně závislá nejen na vlastní fyzické tvorbě DS, ale také na řízení a jeho správě. DS totiž tvoří integrální platformu pro zavádění a využívání MIS organizace, která potřebuje řídit své „Business“ procesy „v pseudo-reálném čase“. Tím to pojmem budeme rozumět řízení vnitropodnikových procesů, u nichž požadavek na aktuálnost podkladů nutných jak pro operativní, tak strategické plánování a rozhodování, je v souladu s obchodními procesy daného sektoru podnikání. Z tohoto „Business“ předpokladu pak vyplývá i požadavek na „služby IT“ s návazností na manažerské podnikové systémy, jejichž neodmyslitelnou součástí je i DS. Navíc různými změnovými řízeními, která průběžně vznikají jak v TPS, tak v jejich agregovaných podobách při ETL procesech plnění DS, jsou tyto změny trvalými zdroji nekonzistence, které se bohužel pak objeví i při tvorbě různých problémově orientovaných aplikací – datamartech - DM (Data Mart). Potom se “nepořádek” v datech může velice vymstít, protože obrazně řečeno, do výpočtu potřebných faktů se mohou 24
dostat data naprosto nekonzistentní, která pak vrcholové vedení organizace bere jako totální selhání pracovníků útvaru IT. Zpravidla není selhání způsobeno samotnými SW řešeními, ale procesními pochybeními při zabezpečování kvality dat napříč útvary, poskytujícími data pro MIS. Tvorba MIS obvykle totiž zapadá do pracovní náplně IT útvarů, často jako exklusivní činnost, vyžadující však spolupráci s dalšími podnikovými útvary. Nebývá to ale rigorózním pravidlem. Někdy vrcholový management (CEO) útvar MIS „vyčlení“ z podřízenosti vedoucího IT útvaru (CIO), protože není spokojen s kvalitou poskytovaných dat, aby po jisté době tento útvar buď vrátil zpět do IT úseku, nebo přesunul do jiného, protože chybovost dat přetrvává, aniž by se provedl interní audit, který by pomohl zjistit příčiny jejich chybovosti“7 Definic ke kvalitě dat je nespočet, proto si pouze vypíšeme jednoduchý přehled atributů, které by měla kvalitní data splňovat: Přesnost Úplnost Včasnost Jedinečnost Konzistentnost Dále je zde popis atributů nekvalitních dat: Překlepy při vkládání dat Chybná metadata Nesplňují danou specifikaci Jsou nevhodná pro řešení podnikových problémů V dnešní době, kdy se zvyšuje konkurenční prostředí a nasycenost trhu v jednotlivých odvětvích, roste i požadavek na zvyšování kvality dat v informačních systémech podniků. V přístupu k zákazníkovi, k dodavateli nebo obchodnímu partnerovi bychom měli získat co nejvíce informací a ty následně velmi dobře zohlednit. Proto je zapotřebí co nejefektivněji využít nové příležitosti a vyřešit nově vzniklé problémy, což nabízejí nové trendy jako je nový vývoj technologií, automatizace a podpora v reálném čase. Avšak s nekvalitními daty firemní procesy nefungují tak jak bychom očekávali a mnohdy vystavují podnik k velkým finančním dopadům, které tuto problematiku řeší nebo jen zmírňují její dopad. Jen v
7
Miniberger, Bohumil, Referát: Kvalita datových skladů-nezbytný předpoklad předcházení rizik manažerského rozhodování. Sborník z 11. ročníku mezinárodní konference „Současnost a budoucnost krizového řízení“. Praha 2009, ISBN 978-80-254-5912-6.
25
Americe nízká kvalita dat stojí společnosti několik stovek miliard dolarů ročně. Proto zvýšená kvalita dat vede ke snížení nákladů na odstranění nebo zmírnění vzniklých problémů, které jsou vynucené neefektivním fungování firemních procesů, nebo můžeme zvýšit zisk implementací nových procesů. „Pro systémové řešení datové kvality lze obecně zvolit jednu ze dvou základních strategií. První, relativně méně náročná strategie je postupovat od konce – tj. postup od koncových uživatelů, jejich aplikací, respektive datového skladu, opravování dat při přípravě pro ně a následná propagace těchto oprav do primárních systémů. Druhá strategie začíná u vzniku dat a jejich kvalitu monitoruje a řídí v průběhu celého jejich životního cyklu. Z principu jde o nákladnější variantu. V praxi se zcela jistě bude možné setkávat s kombinací obou výše zmíněných strategií, neboť se bude vycházet z některých již existujících řešení (tedy od konce) a budou se budovat prvky pro řízení kvality v počátečních fázích zpracování dat při jejich vzniku“8.
1.9.1 Konsolidace dat a adres Tento termín si nejlépe vysvětlíme na příkladu. Představme si dvě bankovní instituce, které mají být časem sloučeny. Při sjednocení je nezbytně nutné sjednotit jejich organizační strukturu a zajistit integraci datových zdrojů, tím získáme jednotný přístup k datům obou bank. Avšak spojením datových zdrojů obou bankovních institucí nezískáme jednotný pohled na zákazníka. Z důvodů různých datových struktur, které byly u každé banky odlišné, rozdílné metodiky při zadávání údajů o zákazníkovy do databáze a hlavním důvodem je, že není možné jednoduše ve všech případech a stoprocentně určit zda dané údaje odpovídají totožnému zákazníkovi. Mezi oběma institucemi v jejich databázích dohledat údaje, které patří k totožnému zákazníkovi a dodržet pravidlo, že je potřeba seskupit všechny údaje, které k sobě patří a dát si pozor na seskupení údajů k sobě nepatřících. Je v milionech údajů, kde mohou být překlepy, údaje zapsány ve zkrácené formě, mohou zde chybět nějaké atributy a údaje k sobě už nemusí patřit, zcela nemožné. Nejprve je tedy nutné opravit překlepy a zkratky, zkontrolovat správnost údajů v referenčních standardech (tabulkách), údaje roztřídit do oddělených sloupců, toto vše se nazývá čištění dat. U kroku čištění dat není smyslem opravit všechny údaje a označit statisíce dat určené k ruční kontrole. Množství dat určených ke kontrole musí být rozumně velké, jinak celé automatizované zpracování není efektní. V průběhu úpravy dat při chybně 8
Martin Bergner, Čistá a kvalitní data z nebe nespadnou [on line][cit. 2011-02-21] Dostupné:http://businessworld.cz/ostatni/cista-a-kvalitni-data-z-nebe-nespadnou-3066
26
zvoleném metodickém postupu, může systém opravit údaje, o kterých si myslí, že jsou špatně. Například pan Leka, jehož příjmení bylo při zadávání prohozeno se jménem, systém pomocí nevhodně aplikovaných replecementů – ženských křestních jmen opraví na Lenka. V dalším případě nejsme schopni údaj opravit bez znalosti kontextu. Kde u jména Vlastislva mohlo dojít k prohození písmen „a“ a „v“ nebo nebylo zavedeno ještě jedno písmeno „a“ k vytvoření jména Vlastislava. V tomto případě je nutné obrátit se na jeden z hlavních atributů o zákazníkovi a tím je atribut pohlaví. Proto je nutné opravy údajů implementovat za velkého rozmyslu, protože dobře míněná oprava může pomoci u několika stovek údajů, avšak na druhou stranu při automatizovaném zpracování řádově několik milionů dat může dojít k zavedení chyb u několika tisíců údajů. O to více musí být věnována větší pozornost při kontrole řídících atributů, jako jsou pohlaví, kód státu, atd. Aby se co nejméně eliminovaly výše zmíněné chyby. Po vyčištění dat se dále můžeme pustit do vyhledávání dat totožného zákazníka. Z toho vyplívá, že konsolidace dat se sestává ze dvou kroků, které na sebe navazují. Čištění dat – odstranění překlepů, zkratek, standardizovat data a další. Unifikace – seskupení údajů, které patří k sobě, pod jeden identifikační kód. V následující tabulce je seznam nejpoužívanějších pojmu, které úzce souvisí s unifikací a čištěním dat. Název pojmu
Popis
Data Quality Management
Řízení kvality dat
Zákazník (klient)
Fyzická, právnická osoba, právnický subjekt, atd.
Deduplikace
Metoda eliminace redundantních dat, jsou nahrazena jedním reprezentativním záznamem
Identifikace
Ověření zda je záznam uložen v referenčním etalonu
Párovací klíč
Skupina atributů, které jednoznačně určují zákazníka nebo adresu
Parsing
Rozložení textu na jednotlivé komponenty
Unifikace
Seskupení záznamů, které se shodují v párovacím klíči pod jeden identifikační kód
Replacement
Automatická oprava dat využívající uživatelsky překladový slovník (původní hodnota -> správná hodnota)
Tabulka 6 Pojmy související s unifikací a čištěním dat. Z pohledu obsahu dat se dále jedná o další dvě úlohy, které jsou navzájem separátní.
27
Konsolidace zákazníka – týká se atributů, jako je rodné číslo, jméno, příjmení, datum narození, titul, pohlaví a další. Konsolidace adres – týká se atributů, jako je PSČ, obec, ulice, číslo popisné a další Čištění dat je samo o sobě dosti náročný proces, proto je nutné použít vhodnou a pokročilou technologii. Jako příklad si uvedeme systém Ataccama DQC (Data QualityCenter), kde na území České republiky je spíše známý pod názvem AdastraPurity. „AdastraPurity je nástroj pro řízení kvality dat (Data Quality Management - DQM), který vám umožní zvyšovat informační hodnotu stávajících údajů v informačních systémech a zároveň zajistit řízení kvality dat na vstupu do systémů. Primárně je připraven k jednoznačné identifikaci zákazníků, adres a vozidel. Na rozdíl od konkurenčních produktů je nástroj Purity od začátku šitý na míru českému a slovenskému národnímu prostředí, zná jeho specifika a plně integruje všechny dostupné externí datové zdroje. Zajišťuje pravidelné aktualizace programového jádra, údržbu potřebných číselníků a úpravy datového rozhraní produktu v případě změn externích zdrojů.“9 V rámci procesu konsolidace dat je potřeba provést několik činností, mezi které patří: audit datové kvality, business analýza a implementace řešení. Audit datové kvality První náhled na zpracovaná data poskytnou statistiky (například určení maxima, minima, atd.) jednotlivých atributů, které jsou úzce spjaté s analýzou nezbytných atributů popisujících zákazníka, jako je jméno, příjmení, datum narození, rodné číslo, adresa a další. Tyto činnosti mají jasný úkol, rychle zmapovat a popsat datové zdroje jako je: zjistit kvalitu, dostupnost a úplnost jednotlivých atributů, provést analýzu hodnot atributů, které se používají při unifikaci zákaznických dat. To znamená zjistit u nich, jestli obsahují slova, číslice, písmena nebo jiné znaky. Po těchto operacích se ukáže, v kterých primárních systémech jsou data a jak jsou data kvalitní, čímž se zjistí i různé chyby, které vznikly při přípravě dat, například z údajů z jednoho primárního systému chybí rodné číslo zákazníků. Tím je poukázáno na to, že je vhodné provádět analýzu i z hlediska jednotlivých primárních systému a nejen z celkového pohledu. Z čehož plyne, chyba, která je ve srovnání s celkovým počtem zpracovaných údajů zanedbatelná, tak v rámci jednoho primárního systému, může způsobit velký problém.
9
Nástroje pro Data Quality Management [online][cit. 2011-02-03] Dostupné: http://www.adastra.cz/123_nastroje-pro-data-quality-management-%28purity%29.aspx
28
Business analýzy Úkolem této fáze procesu je zjistit business požadavky budoucích zákazníků, zpravidla z oblasti marketingu. Dále tyto požadavky sladit s možnostmi, které poskytují dostupné datové zdroje. Budeme vycházet z vlastních „bestpractices“, ze specifických potřeb a požadavků budoucích zákazníků a v neposlední řadě ze závěrů, které jsme získali během auditu datové kvality. Dalším krokem jsou navržena a odsouhlasena pravidla pro unifikaci zákazníka, na základě kterých je zevrubně upravena stávající konfigurace systému pro Data Quality Management a provedeno zpracování všech dat. Obdržené výsledky jsou vyhodnoceny, provedou se potřebné úpravy v nastavení aplikace, provede se úplná konfigurace systému a celý tento postup se několikrát opakuje. Implementace řešení U této fáze je nutné, aby data pro proces unifikace a čištění byla připravena a správně charakterizována ze zdrojových systém, ještě dříve než započne proces samotné implementace. Nastavení systému pomocí „bestpractices“ se postupem času přizpůsobí konečným požadavkům na řešení a celý tento proces je implementován do workflow dávkového zpracování. Na vzorcích a denních přírůstcích dat se kontroluje kvalita vyčištěných dat a dále se kontroluje správnost unifikace zákaznických dat. Proto není vhodné během této fáze procesu, měnit obsahově nebo strukturálně zpracovávaná data. „Implementací systému pro data quality management dostávají uživatelé do ruky jednotný informační zdroj pro práci s klientem založený na unifikovaném klientovi. Standardizací a ověřováním osobních a adresních údajů lze následně postavit proces identifikace domácnosti (householding), čímž lze dosáhnout ještě větší adresnosti marketingových kampaní a spolehlivěji než dosud stanovit míru bankovních rizik při vyřizování konkrétních žádostí o úvěry. U většiny implementací se následně celý proces identifikace a unifikace klientských a adresních dat převádí z dávkového do on-line režimu. Tím se nepochybně dále zvyšuje kvalita pořizovaných dat již v samotném zárodku, neboť dojde k zamezení vzniku nekvalitních dat přímo při jejich zadávání v klientských centrech. Nasazením on-line systému pro data quality management je totiž možno na základě několika vyplněných klíčových dat (např. jména, příjmení, rodného čísla nebo čísla občanského průkazu) ve zlomku sekundy klienta identifikovat (pokud je již zákazníkem banky) a doplnit ostatní nezadané údaje (adresu, tituly, pohlaví, datum narození atd.). Pokud daný zákazník klientem banky ještě není, jsou zadávané údaje vyčištěny, ověřeny vůči referenčním etalonům, ze kterých jsou chybějící údaje, pokud to je možné, doplněny, 29
a do systému je založen záznam nový. Nemůže se tak již prakticky stát, že by klient byl v rámci banky veden duplicitně. Lepší data prostě znamenají méně komplikací.“10 V dnešní době se také setkáváme s pojmem a řešením MDM (Master Data Management), což je centrální registr, který obsahuje konsolidovaná master data (referenční data) z různých systémů, tyto data jsou poskytována uživatelům v reálném čase. Jedná se o státní systémy, které mohou využívat různé platformy a mohou být i geograficky členěné. Nejčastěji jsou tak řešené centrální zákaznické databáze. Ve státní správě je pomocí MDM řešen ucelený systém základních registrů, jehož součástí je i registr obyvatel, registr osob a registr územních jednotek a nemovitostí. Pomocí toho to systému může, kterákoliv instituce státní správy využít evidenci všech subjektů a nemusí řešit, která instituce daný subjekt povolila nebo vytvořila. Avšak je zde nepříjemná překážka, která do určité míry znesnadňuje implementaci nápravných mechanismů pro zajištění datové kvality. Data, která jsou uložena v MDM vznikají v různých systémech, kde jsou považována za master data (originál data). Pokud se narazí na chybu, například nesprávná adresa zákazníka, musí se opravit právě v kořenovém systému, to je tam, kde byla vytvořena a poté může být implementována do MDM. Lze provést i opačný průběh, kde se chyba opraví v MDM a poté se implementuje do všech odebírajících systémů včetně systému kořenového. Toto záleží na architektuře řešení, zda je povoleno měnit master data v MDM nebo to povoleno není. Řešení pomocí MDM přináší výhodu a tu, že při jeho tvorbě musí být nadefinovány určité standardy. Tím je myšleno, že každá entita (například: adresa zákazníka) je popsána jednotným způsobem, který akceptují všechny zapojené systémy do MDM. Jedná se o velmi náročné a komplexní řešení při implementaci MDM, které s sebou nese mnohé opravy dat v primárních systémech. V architektuře MDM jsou již implementovány primární systémy, což jsou systémy, které vytváří data (o zákaznících, o produktech, atd.), a centrální registr. Centrální registr nedisponuje možností data vytvářet ani měnit, je vhodným místem pro kontrolu kvality dat. Umožňuje zde porovnat kvalitu dat všech kořenových systémů, kontrolu dodržování standardů a zhodnotit časové trendy zlepšení nebo zhoršení kvality dat. Určitá zjištění problémů pak mohou být obsahem reportu přímo kořenovým systémům, kde je očekávána oprava. Kvalita dat se odráží na manažerském řízení. Proto kvalita dat v datovém skladu úzce souvisí s MIS (manažerský informační systém), ale také se systémy pro rozhodování EIS. 10
Pavel Kmínek, Konsolidace dat ve finančních institucích [online][cit. 2011-02 - 03] Dostupné:http://www.systemonline.cz/business-intelligence/konsolidace-klientskych-dat-ve-financnichinstitucich.htm
30
V návaznosti na kvalitu dat v datovém skladu si stručně popíšeme, co by měl manažerský informační systém – MIS zajišťovat, aby byl chod firmy bezpečný. Nejprve si zobrazíme organizační strukturu firmy pomocí následujícího obrázku, abychom věděli, kde se ve schématu nachází systém MIS.
Obrázek 7 Organizační struktura firmy (vlastní úprava) U každého prvku organizační struktury firmy jsou i určité role, které mají vliv na kvalitu dat v datovém skladu, a to jak na jeho vývoj, využívání tak i na jeho správu.
1.9.2Role pro tvorbu datového skladu: Vedoucí útvaru MIS – jeho úkolem je jednak plánování vývoje, zavádění a chod datového skladu, tak i řídit a dohlížet na pracovníky útvaru. Analýza a vývoj DWH – tato role je zodpovědná za analýzu, programovou tvorbu datového skladu a úzce spolupracuje s jinými odděleními. Správa informačních zdrojů pro DWH – zkoumá využití datového skladu, což je základ pro návrh nové analýzy a efektivnější využití datového skladu, a provádí školení uživatelům. Administrace a podpora zavádění požadavků – toto oddělení se zabývá statistikou provozu datového skladu, má dohled nad efektivním poskytováním služeb, kde je obsažena i chybovost. Informační analytik – úkolem tohoto specialisty je návrh logického datového modelu datového skladu a je účastníkem jeho implementace do systému, stará se o udržení integrity datového skladu. 31
Správce datového skladu – je zodpovědný za údržbu datového skladu, jeho administraci, archivaci, bezpečnostní funkce a dohlíží na ETL proces. Specialista technické podpory – seskupuje a řídí určité části datového skladu, udržuje jejich návaznost, řeší různé problémy a události v datovém skladu a je k dispozici ohledně helpdesku. Specialista řízení kvality – má kontrolu nad procesy a standardy v provozu datového skladu, vyhodnocuje určité statistiky, na základě kterých analyzuje chyby a nedostatky v datovém skladu a navrhuje způsob jejich odstranění. Výstupní informace z datového skladu slouží jako podklady pro strategické rozhodování, efektivní chod firmy a její další působení na trhu. Proto jsou výše zmíněné role nutností při tvorbě, chodu a správy datového skladu, kde při dnešním rychle rostoucím množství zpracovávaných a ukládaných dat, by tyto atributy práce běžný uživatel nezvládl. Provoz datového skladu, získání a modifikace požadovaných dat je ovlivňován různými faktory, například konkurencí, legislativou, změnou fungování firmy, většími nároky ze strany uživatelů, atd. Pokud uživatel neobdrží požadovaná data, z důsledku jejich ztráty, nebo mu jsou poskytnuty nepravdivé informace, obrátí se k jiným zdrojům informací nebo k tvorbě datových trhů – Data martů. Což vede ke zvýšení rizika zkreslujících informací v obsahu datového skladu, který je jednotným zdrojem informací firmy. Tuto problematika řeší oddělení správy pro datový sklad, které se také stará o kvalitu dat v něm obsažených. Hlavní roli při řešení problémů hraje metasystém, což je přesný výpis určité problematiky, kde jsou popsány definice pojmů a jejich vztahy mezi sebou. Metasystém je tedy nástroj, který archivuje a předává „know –how“ určité problematiky, k jejímu vyřešení a podporuje procesy výše popsaných rolí. Aby se v datovém skladu dosáhlo co možná největší kvality dat, je nutné přesně definovat odpovědnosti a pravomoce všech rolí, které se podílejí jak na vývoji datového skladu, tak i na popisu příslušných dokumentů a v neposlední řadě popis možných přístupů do všech částí datového skladu. Role, která nese největší zodpovědnost za správnost všech souborů v datovém skladu je správce datového skladu, který se také stará o zabezpečení metasystému. Pokud je navržen požadavek na změnu v datovém skladu, například zavedení nové aplikace nebo její úprava, úpravy stávajících atributů datového modelu a jiné, tak správce datového skladu požadavek přijímá a následně vyhotoví jeho analýzu a rozepíše další postup integrace požadavku do všech fyzických zdrojových informačních systémů, kde následně provede podrobnou evidenci o změnách a o tom jak se změny projevili v datovém skladu nebo v datamartech. Proces správy datového skladu je zjednodušeně zobrazen níže na obrázku 8. 32
Obrázek 8 Proces správy datového skladu (vlastní úprava).
1.9.3 Audit datového skladu V dnešní době, kdy je tržní svět hyperkonkurenčí se stali datové sklady nezbytnou součástí pro řízení firmy napříč všemi tržními segmenty. Kde datové sklady a s nimi kooperující aplikace zajišťují řešení při analýze dat v reálném čase, pomáhají při získání detailních informacích o zákaznících a jeho chování, při úpravě klíčových dat firmy a podobně. Po určité době používání je potřeba se zamyslet nad efektivností datového skladu, aby přinášel firmě co největší užitek, pokud je řešení na základě datového skladu provozováno řádově několik let, vedení je nespokojené s funkcionalitou řešení a to například: nejsou splněna finanční očekávání jak výdaje, tak i příjmy, nejsou přesně určeny role a procesy, které řídí provoz a rozvoj řešení, pak je zapotřebí provést audit datového skladu. 33
Pokud jsme se opravdu rozhodli provést audit datového skladu, je zapotřebí přesně určit co, jak a kdy má být auditováno a co od auditu očekáváme. Většinou od auditu očekáváme: Porovnání obsahu, funkcionalitu datového skladu, řídící procesy, jsou-li vhodně použity technologie a další atributy již zavedeného datového skladu s podobným řešením v obdobné firmě v určitém regionu nebo na mezinárodní úrovni. Ověřit očekávaný rozvoj řešení, zda je v souladu s obecně uznávanými „bestpractices“ a to na úrovni obsahu, funkcionality datového skladu, použitých technologií a jiných atributů. Určit příčiny neefektivnosti nebo selhání řešení.
Obrázek 9Ukázky z aplikace ARIS IT architect – jednoho z nástrojů vhodných pro modelování architektury IT11 „Jak vyplývá z výše uvedeného, auditorem datového skladu by neměla být oddělení zainteresované organizace, ale jednoznačně jím musí být nezávislá konzultační společnost. V případě, že řešení je dodané externí firmou, musí být auditor nezávislý i na této firmě. Ideální je i technologická nezávislost, protože velmi často jsou porovnávány různé technologie a je hodnocena efektivita konkrétně využitých nástrojů. Auditorská společnost musí mít dostatečné know-how v oblasti datových skladů a business intelligence (BI), a to nejen v rámci regionu, ale i celosvětově. Konkrétní auditoři by měli být zkušení implementátoři řešení DW, současně však musí mít velmi vyspělé schopnosti komunikace a percepce prostředí, ve kterém bude audit probíhat. Za stranu organizace vlastnící auditované řešení se projektu musí účastnit osoby zodpovědné za jeho obsah, technický provoz a další rozvoj, tedy například manažer řešení datového skladu, resp. BI, business 11
David Slánský, Audit řešení datového skladu, [on line][cit. 2011-02-25] Dostupné: http://www.systemonline.cz/business-intelligence/audit-reseni-datoveho-skladu-1.htm
34
sponzor a další. Pokud business sponzor není již přímo v nejvyšším vedení organizace (což je vhledem k důležitosti řešení preferovaná varianta), měl by na projekt dohlížet některý z top manažerů“12
12
David Slánský, Audit řešení datového skladu, [on line][cit. 2011-02-25] Dostupné: http://www.systemonline.cz/business-intelligence/audit-reseni-datoveho-skladu-1.htm
35
2. Datové modely Data Warehouse Datový model v IT je jako abstraktní model. To znamená, že dokumentuje a organizuje podniková data pro komunikaci mezi zaměstnanci, a také slouží jako plán pro rozvoj nových aplikací. Konkrétně jak data ukládat a zpřístupnit je. Datový model jednoznačně určuje strukturu dat.
2.1 Analýza OLAP OLAP (Online Analytical Processing) je taková technologie, která zpracovává databázi na aplikačním serveru, kde je možné uspořádat obrovské množství dat, tak aby byla data srozumitelná a přístupná těm uživatelům, kteří se zabývají analýzou trendů a výsledků. U těchto databází jsou kategorie dat uspořádávány do skupin polí, které se nazývají dimenze a v některých případech mohou být i vícedimenzionální. Tato technologie tedy používá multidimenzionální pohled na shromažďování dat, které poskytují rychlý přístup ke strategickým informacím a ty dále k další analýze. Databáze, které podporují technologii OLAP jsou používány podniky, pro nalezení nových trendů z datových tržišť nebo datových skladů. OLAP je založena na koncepci multidimenzionálních databází a pracuje na principu několikadimenzionálních tabulek, které umožňují rychle a pružně měnit jednotlivé dimenze a tím měnit pohledy uživatelů na modelovanou realitu. Většinou bývají data ve firmách rozdělována do několika zdrojů a jsou navzájem nekompatibilní. Dosažení OLAP reportu například: „Jaký produkt byl nejlépe prodáván v letech 2005 až 2011?“by bylo časově náročné, proto je OLAP navržen, aby poskytoval přehledné analýzy toho, co se stalo. Jak je výše zmíněno, data jsou ukládána do polí a ne do ploché mřížky. Toto pole vypadá jako krychle, kde každá jeho strana je dimenzí a zastupuje nějaký atribut například: čas, produkt, region nebo množství. OLAP umožňuje uživatelům analyzovat data, které si zvolí a nemusí se spoléhat na data, které generoval někdo před nimi, tím je myšleno, že mohou vytvářet Ad hoc sestavy, které jsou vytvořené pro koncové uživatele. Zhruba do poloviny devadesátých let se OLAP analýzy prováděly jen ve velkých podnicích, kvůli jejich velké nákladnosti. Postupem času začali prodejci databází zahrnovat OLAP do svých vytvořených databází, například: Microsoft SQL Server – Analysis Services, IBM – DB2, ORACLE – Expres (DB) a Darwin. A tím se práce pomocí OLAP rozšířila velmi rychle, nejen z levnějšího pořízení, ale i z důvodu zvětšujícího se objemu dat a z přínosu pro podnik z hlediska rozhodování v business intelligence. 36
OLAP můžeme také chápat pomocí 12 pravidel, které v roce 1993 zavedl E. F. Codd, aby eliminoval mezery mezi využitím uživatelských PC a řízení podnikových dat. 12 pravidel: Informační pravidlo – všechny hodnoty v databázi musí být vyjádřeny jedním způsobem, a to dle hodnot v tabulkách. Pravidlo zaručeného přístupu – všechna data musí být přístupná, v podstatě jde o přeformulování základních požadavků na primární klíče. Znamená to, že každá skalární hodnota v databázi musí být adresovatelná pomocí specifického jména, které je obsaženo v tabulce, jméno obsahuje název sloupce a hodnotu primárního klíče obsaženého v řádku tabulky. Systematické zpracování nulových hodnot – SŘBD musí každému poli umožnit hodnotu (indikátor) NULL. Tento indikátor je vyhovující jak v oblasti číselných hodnot, liší se od čísla nula, tak i v oblasti prázdných řetězců, kde chybí hodnota, nebo hodnotu neznáme. On-line katalog dat založený na relačním modelu – systém musí podporovat online relační databázi, který je přístupný autorizovaným uživatelům pomocí jejich běžně užívaného dotazovacího jazyku. To znamená, že autorizovaný uživatel může aplikovat stejný dotazovací jazyk ke svému dotazu jako uživatel při práci s daty. Komplexní datový podjazyk – systém může podporovat několik jazyků, avšak musí být jeden jazyk, který umožní lineární syntaxi, podporuje definici datových operací, včetně zobrazení definic, definice manipulace s daty (aktualizace, vyhledávání), bezpečnost a integritní omezení. Pravidlo pohledu – všechny pohledy, které je možné aktualizovat, musí být aktualizovatelné systémem. Úroveň vkládání, aktualizace a mazání – jde o zachování relačních pravidel u základních i odvozených relací, jak při pohledu tak i při různých operacích. Fyzická datová nezávislost – změny na fyzické úrovni (jak jsou data uložena, jestli v poli nebo provázané seznamy, apod.) nesmí vyžadovat změnu aplikace založené na fyzické datové struktuře. Logická datová nezávislost - změny na logické úrovni (tabulky, sloupce, řádky, apod.) nesmí vyžadovat změnu aplikace založené na logické datové 37
struktuře. Logické datové nezávislosti je obtížnější dosáhnout než fyzické datové nezávislosti. Integritní nezávislost – integritní omezení musí být specificky odděleno od aplikačních programů a uloženo v katalogu dat, musí být možnost definovat integritní omezení pomocí prostředků relační databáze a musí být uloženo v katalogu data ne v aplikačním programu. Distribuční nezávislost – relační SŘBD musí být implementovatelný i na jiných počítačových architekturách. Pravidlo přístupu do databáze – je-li použit u relačního systému jazyk nižší úrovně, nemůže pomocí něho vytvářet integritní omezení, proto je nutná interpretace ve vyšším jazyce.
2.2 Datové kostky Datová kostka (Data cube) je vícerozměrné rozšíření dvojrozměrné tabulky, to znamená, že si kostku můžeme představit jako stejně strukturované dvojrozměrné tabulky, které jsou kupené jedna na druhou, což představuje troj rozměrný objekt. „Nicméně datové kostky se nemusejí nutně omezovat jen na trojici rozměrů. Mohou být 2 - dimenzionální, 3dimenzionální a více – dimenzionální. Avšak většina analytických OLAP (On-line Analytical Processing) systémů umí vytvářet kostky s daleko více rozměry. Microsoft SQL Server 2000 Analytical Services například nabízí až 64 rozměrů. Čtyřrozměrnou datovou kostku si můžeme představit jako řadu trojrozměrných datových kostek, nicméně vizualizace podobných vícerozměrných entit může z prostorového nebo geometrického hlediska představovat problém. V praxi proto sestavujeme datové kostky o mnoha rozměrech, ale máme tendenci dívat se v jednom okamžiku pouze na 3 rozměry. Velmi cenná je možnost indexování kostek na základě jednoho či více rozměrů“13. Datová kostka je znázorněna na obrázku níže s atributy čas, lokalita a výrobek.
13
Russel Kay, Zaostřeno na datové kostky [on line][cit. 2011-02-21] Dostupné:http://scienceworld.cz/technologie/zaostreno-na-datove-kostky-2223
38
Obrázek 10 Datová kostka 14 Datová kostka umožňuje uživatelům zkoumat a analyzovat data z různých pohledů, což také umožňují OLAP nástroje, které jsou založené na multidimenzionálním datovém modelu, o kterém jsme se již zmínili. Z toho vyplívá, že datový sklad neobsahuje tabulky, ale kostky, které umožňují rychlé vyhledávání dat. Dále si vysvětlíme pojmy dimenze a míry datové kostky. Jak bylo dříve zmíněno, dimenze datové kostky zastupuje nějaký atribut, zpravidla to bývá čas, geografické určení místa, produkt nebo množství. Dimenze bývají většinou uspořádány v hierarchickém stylu a mapují sloupce v relačních databázích. Tím je myšleno, že každá úroveň dimenzí je seskupena tak, aby tvořila hodnoty pro úroveň výše neboli úroveň nad ní. Například v dimenzi času, seskupením hodnot úrovní den dosáhneme hodnot k vytvoření vyšší úrovně měsíc. Míry v databázi zastupují kvantitativní hodnoty, které jsou připravené k analýze. Mezi typické míry patří prodej, náklady a rozpočty. Míry jsou analyzovány vůči různým kategoriím dimenzí datové kostky. Tím je myšleno, že analýza prodeje (míry) jednoznačně určeného výrobku (dimenze) v různých geografických polohách (dimenze) během určitého časového úseku (dimenze). Pro lepší pochopení si uvedeme konkrétní případ. Na obrázku 11. je vytvořena datová kostka s třemi dimenzemi: místo, čas a produkt.
14
OLAP Multidimensionalita[online] [cit. 2011-02-21] Dostupné: http://www1.osu.cz/studium/dozna/olap.htm
39
Obrázek 11 Příklad datové kostky (vlastní úprava). V našem případě je zobrazenou úrovní dimenze času, úroveň měsíc, u geografické polohy jsou to města a u úrovně dimenzí produkt jsou typy aut Škoda. Z kostky je možné vyčíst, že v Praze se za měsíc květen prodalo 8 aut Škoda Superb.
2.3 Schéma tabulek datového skladu Každý datový sklad má odlišné struktury, pravidla a přístup k datům, tak aby vyhovovali různým potřebám uživatelů. Nejprve si popíšeme schéma s názvem Hvězdicové dále jeho složitější nadstavbu, což je schéma sněhové vločky a nakonec schéma souhvězdí.
2.3.1 Hvězdicové schéma Hvězdicové schéma nebo také pod názvem „Star schema“ patří mezi nejvíce používané k převedení relačního modelu dat k multidimenzionálnímu modelu. Hvězdicové schéma je složeno s centrální tabulky, která se také může nazývat tabulka faktů, kde je obsažen cizí klíč, a k ní přiřazené doprovodné tabulky dimenzí, kde jsou obsažený primární klíče, které jsou přidružené k cizím klíčům. V tomto schématu je každá dimenze zastoupena právě jednou tabulkou. Kde každá tabulka může obsahovat několik atributů, tím je myšleno, například dimenze „Region“ může obsahovat úrovně: stát, země. U tohoto schéma nejsou normalizované dimenze a propojení mezi tabulkami dimenzí taktéž ne. Z toho důvodu se schéma tvoří pomaleji, ale výhodou je vysoká rychlost dotazování.
40
Obrázek 12 Hvězdicové schéma (vlastní úprava).
2.3.2 Schéma Sněhová vločka Toto schéma se také nazývá „Snowflake schema“. Zde jsou tabulky dimenzí normalizovány, čímž jsou data dále rozdělena do tabulek. Spojením těchto tabulek vypadá schéma jako sněhová vločka, odtud je odvozen i název. Jak bylo zmíněno hlavním rozdílem mezi dvěma schématy, je normalizace tabulek, tím je dosaženo určitého snížení redundance dat v uložených tabulkách, tabulka se pak snadno udržuje a není tolik zabírán diskový prostor. Tato úspora je zcela zanedbatelná vůči typické velikosti tabulky faktů. S větším počtem tabulek, narůstá odezva dotazování, což snižuje efektivnost analýz dat, z tohoto důvodu se schéma sněhové vločky moc nepoužívá, a více je používáno schéma hvězdicové.
Obrázek 13 Schéma Sněhová vločka (vlastní úprava).
2.3.3 Schéma Souhvězdí „Z každého hvězdicového schéma nebo schéma sněhové vločky je možné sestavit schéma souhvězdí. Toto schéma je mnohem složitější než tyto dvě schéma, protože obsahuje více tabulek faktů. Tabulky faktů umožňují sdílet více tabulek dimenzí. Toto řešení je flexibilní, avšak může být těžké jak z hlediska řízení, tak i z hlediska podpory. Hlavní nevýhodou 41
tohoto schéma je jeho komplikovaná architektura, protože hodně variant agregace musí být dobře zváženo. Ve schématu souhvězdí jsou různé tabulky faktů jednoznačně přiřazené k tabulkám dimenzí, které jsou pro ně relevantní. To může být užitečné v případě, že některé tabulky faktů jsou spojeny s určitou úrovní tabulky dimenzí a další tabulka faktů je spojena s nižší úrovní tabulky dimenzí. Použití tohoto modelu může být například: mámeli tabulku faktů – prodej, s přesnými detaily na přesný den a id hlavičky faktury. Tabulku faktů – předpovídaný prodej, který byl vypočten na měsíc, kde máme k dispozici Id klienta a Id produktu. V tomto případě používáme dvě různé tabulky faktů na jiné úrovni, které jsou seskupeny do schématu souhvězdí. Příklad schéma souhvězdí je znázorněn níže“15.
Obrázek 14 Schéma Souhvězdí13
2.4 Varianty OLAP Varianty OLAP se odlišují podle způsobu uložení dat, na relační (ROLAP), multidimenzionální (MOLAP) a hybridní (HOLAP). Každá z těchto variant poskytuje různé možnosti, kde jejich charakteristika vychází z velikosti databáze a na způsobu 15
Factconstellationschemaarchitecture[online][cit. 2011-02-28] Dostupné:http://etl-tools.info/en/bi/datawarehouse_constellation-schema.htm
42
využití dat. Nejčastěji je používán multidimenzionální OLAP. Hybridní OLAP se většinou používá pro samostatné databáze a relační OLAP je vhodný, jsou-li požadavky na dotazy nízké.
2.4.1 ROLAP (Relational Online AnalyticalProcessing) U této metody jsou data k analýze získávána z relačního datového skladu, kde jsou uložena v dvojdimenzionálních tabulkách. Každý řádek obsahuje informaci o skutečné věci v reálném prostředí, sloupce obsahují údaje, které se týkají atributů. Z pravidla bývá ROLAP používán pro rozsáhlé databáze nebo pro „stará“ data, tím je myšleno pro data, která nejsou tak často analyzována, protože jedna z vlastností ROLAP je jeho pomalá odezva na požadovaná data. Zadá-li uživatel požadavek k zobrazení dat, server OLAP vygeneruje SQL dotaz, ten je přes rozhraní ODBC16 zaslán do databáze primárního systému. Data zůstanou uložena v relačních databázích, čímž je odstraněn problém s redundancí. Mezi výhody ROLAP patří: K datům lze přistupovat v reálném čase. Pracuje s velkými objemy dat – velikost je omezena pouze velikostí relační databází, tzn. že ROLAP neklade žádné omezení na objem dat. Může využívat funkce spojené s relačními databázemi, protože tyto databáze často už v sobě obsahují určité funkce, které usnadňují práci s daty (například: povolení ovládacích prvků, jako je řádek-úrovně zabezpečení, kde výsledky dotazu jsou filtrovány v závislosti na použití nastavených kritérií, například pro daného uživatele nebo skupinu uživatelů). Není zde vyžadováno speciální školení uživatelů. Možnost přístupu k detailním informacím. Flexibilita. Nevýhody ROLAP: Dlouhé odezvy při dotazování – každá zpráva ROLAP je ve své podstatě SQL dotaz nebo skupina dotazů v relační databázi, čas dotazu může být dlouhý, pokud jsou podkladová data velmi objemná. ROLAP je hodně závislí na generování SQL dotazů v relačních databázích. Kde všechny SQL výrazy nejsou vhodné pro 16
Open Database Connectivity-jedná se standardizované softwarové rozhraní pro programování aplikací pro přístup k databázovým systémům. ODBC je nezávislí na programovacím jazyku, operačním systému a databázovém systému.
43
všechny požadavky (například: při složitějších výpočtech). Z toho vyplívá, že ROLAP je závislý na SQL. Toto se částečně řeší, tím že je zde možnost uživatelů, definovat jejich vlastní funkce. Musí nutně existovat databáze, protože u ROLAP se k databázi primárního systému připojujeme pomocí ODBC, kdežto u MOLAP postačí textový soubor.
Obrázek 15 Schéma ROLAP17 Použití ROLAP je většinou ve spolupráci s datovým skladem. Může být použito neomezeného počtu dimenzí, kde se počet prvků v dimenzi pohybuje v jednotkách tisíc, do 10 000. Technologie ROLAP je vhodná pro aplikace s častými změnami, protože se prvky v dimenzi, vytváří v době dotazu.
2.4.2 MOLAP (Multidimensional Online AnalyticalProcessing) Již z názvu vyplívá, že jde o multidimenzionální způsob ukládání dat. Data jsou získávána buď z datových skladů, nebo z operačních zdrojů, které jsou pak ukládána do multidimenzionálních kostek, čímž je zajištěn vysoký výkon vzhledem k dotazům
17
ROLAP – Relational OLAP Architecture[online][cit. 2011-02-28] Dostupné: http://www.executionmih.com/business-intelligence/rolap-olap.php
44
uživatele. Oproti ROLAPu musíme pomocí vhodného ETL nástroje data transformovat z relační databáze a potom je uložit do datového skladu, což je velmi časově náročné. MOLAP ukládá analytická data ve vlastních strukturách a sumářích. Vysoký výkon je zajištěn jak uložením dat v multidimenzionálních kostkách tak i tím, že při ukládání dat se v úložišti spočítá takové množství možných výsledků, které je z časového a technického hlediska možné. Hodnoty dat jsou uchovávány v polích multidimenzionálních databází, ta je strukturovaná tak aby co nejefektivněji umožnila rychlé získání dat z více dimenzí. U analýzy MOLAP je možnost pracovat off-line, tedy bez připojení k primárnímu zdroji. Mohlo by se to tedy zdát jako veliká výhoda, například na poradě prezentovat výsledky analýzy bez připojení k primárnímu zdroji, ale je potřeba si uvědomit, že výsledky nejsou v tu danou chvíli prezentace aktuální.
Obrázek 16 Schéma MOLAP18
18
MOLAP – Multi-dimensional OLAP Architecture[online][cit. 2011-02-28] Dostupné:http://www.executionmih.com/business-intelligence/molap-olap.php
45
Výhody MOLAP: Rychlá odezva na dotazy uživatelů, díky uložení dat v multidimenzionální kostce. Data jsou získávána z různých datových zdrojů (TXT, ODBC, atd.). Může provádět složité výpočty. Nevýhody MOLAP: Redundance dat. Data jsou uložena jak v multidimenzionální databázi, tak i v relační databázi. Nutnost dávkového zpracování. Velké nároky diskový prostor. Technologie MOLAP se většinou používá tam, kde není zcela nutné vytvářet databázi datového skladu, tedy tam kde jsou malé až střední objemy dat. Je zde omezen i počet prvků v dimenzi pro určitý ukazatel v multidimenzionální databázi, který by neměl přesahovat 5000 prvků. Dále není vhodný pro řešení, u kterých dochází k častým změnám v dimenzích, například: nové zboží.
2.4.3 HOLAP (Hybrid Online Analytical Processing) Hybridní OLAP kombinuje úložiště jak ROLAP tak i MOLAP, kde je snaha potlačovat jejich nevýhody a využívat výhody. Údaje zůstávají uložené v relačních databázích a spočítané agregace jsou uloženy do multidimenzionálních struktur. U hybridního řešení jsou detailní data ukládána do relačních databází a sumární data jsou ukládána do multidimenzionálních databází. „Tzv. „Příčky“ rozdělují kostku do segmentů, které mohou být optimalizovány individuálně, ale následně může být kostka analyzována jako celek. Každá kostka se skládá alespoň z jednoho segmentu, nicméně může být rozdělena i do několika. Každá část potom může být uložena rozdílným způsobem. Např. kostka má tři části, jedna používá ROLAP, další HOLAP a třetí MOLAP.“19 Výhody HOLAP: Lze přistupovat k rozsáhlým datům současně při rychlé agregaci. Nevýhody HOLAP: Data musí být udržována na dvou místech.
19
Vítek, Uložení dat v OLAP systémech,[online][cit. 2011-02-28] Dostupné: http://datamining.xf.cz/view.php?cisloclanku=2002102810
46
Obrázek 17 Schéma HOLAP20
Technologie HOLAP se používá u rozsáhlých projektů a datových skladů. Kdy je potřeba uložit data s mírou agregace do multidimenzionálních databází a v relačních databázích ponechat detailní data. Další technologie patřící do OLAP systémů je DOLAP(Desktop – Online Analytical Processing). U této technologie je multidimenzionální kostka vytvářena jako virtuální v RAM paměti. Z toho plyne výhoda neomezená flexibilita, nevýhodou jsou naopak velké nároky na RAM paměť a tvořit kostku pokaždé znovu.
2.5 Základní operace v OLAP systémech Drill – Down (roll – down):umožňuje uživateli v jedné nebo více zvolených instancích jisté agregační úrovně nastavit nižší (jemnější) agregační úroveň. V hierarchii dimenzí se jedná o navigaci směrem k většímu detailu. Drill – Up (roll – up): jedná se o opak předešlé operace. V jedné nebo více zvolených instancích agregační úrovně lze nastavit vyšší (hrubší) agregační úroveň. V hierarchii dimenzí se jedná o navigaci směrem k menšímu detailu.
20
HOLAP – Hybrid OLAP Architecture[online][cit. 2011-02-28] Dostupné:http://www.executionmih.com/business-intelligence/holap-olap.php
47
Pivoting: jedná se o jednoduchou a efektivní funkci, která umožňuje uživatelům zobrazovat hodnoty krychlí, pochopitelnějším způsobem. Máme, tím namysli možnost „otáčet“ datovou krychlí a tím měnit pohledy na data na úrovni presentace obsahu data. Slicing: provádí řezy datovou krychlí a umožňuje nalézt pohledy, v nichž je jedna dimenze fixována v jistých instancích určité agregační úrovně. Tato dimenze aplikuje filtr na instance příslušné agregační úrovně dané dimenze. Dicing: ve své podstatě je stejný jako Slicing, s tím rozdílem, že umožňuje nastavit filtr pro více dimenzí.
2.6 OLTP OLTP (Online Transaction Proccessing) jak vyplívá z názvu OLTP pracuje v reálném čase, data jsou uložena v databázi, kde je umožněna jejich snadná a bezpečná modifikace v mnohauživatelském prostředí. V dnešní době se jedná o zcela běžný přístup ve většině databázových aplikací. Především se používá k podpoře operačních potřeb společnosti. Zpracovávají data, u kterých je potřeba, aby byla ihned zpracována, jako jsou například: objednávky, bankovní operace a jiné.
2.7 Rozdíly mezi OLTP a OLAP Zjednodušeně můžeme tyto dva IT systémy rozdělit tak, že OLTP poskytuje zdrojová data do Data warehouse, naproti tomu OLAP nám poskytne analýzu těchto dat. OLTP je charakterizováno velkým počtem krátkých on-line transakcí jako je například: INSERT, DELETE, UPDATE a jiné. Hlavní důraz je kladen na velmi rychlé zpracování dotazů, zachování integrity v mnohauživatelském prostředí a v efektivním využití vyřízených transakcí za vteřinu. V OLTP databázi jsou obsažena aktuální a detailní data. OLAP je charakterizován velmi malým počtem transakcí. Dotazy jsou ve většině případů složité a zahrnují agregace. Pro OLAP systémy je význačná jejich vysoká rychlost pro dotazování uživatelů. OLAP aplikace jsou úzce spjaty s technikami dolování dat z datových skladů (Data Mining). V databázích jsou strukturovaná, historická data uložena v multidimenzionálním schéma, většinou se jedná o hvězdicové. Na obrázku je znázorněna závislost mezi OLTP a OLAP.
48
Obrázek 18 Závislost mezi OLTP a OLAP21
V následující tabulce jsou shromážděny hlavní rozdíly mezi OLAP a OLTP systéme. OLTP Systém
OLAP Systém
Zdroj dat
Operativní data; OLTP jsou původní zdroje dat
Konsolidovaná data; OLAP data pochází z různých databází OLTP
Účel dat
K řízení a provozování běžných obchodních úkolů
K pomoci plánování, řešení problémů a je nezbytnou součástí při podpoře rozhodování
Účel použití
Zobrazuje momentální snímek probíhajících obchodních procesů
Multidimenzionální pohledy na různé způsoby obchodní činnosti
Vkládání a update
Krátké a rychlé vkládání a aktualizace na podnět koncových uživatelů
Periodické, dlouho trvající dávkové úlohy aktualizace dat
Dotazování
Relativně standardizované a jednoduché dotazy
Často složité dotazy zahrnující agregace
Typicky velmi vysoká
Závisí na množství zahrnutých údajů; aktualizace pomocí dávek a složité dotazy mohou trvat několik hodin; dotazovací rychlost může být zvýšena vytvořením indexů
Rychlost zpracování
21
OLTP vs. OLAP [online][cit. 2011-02-28] Dostupné: http://datawarehouse4u.info/OLTP-vs-OLAP.html
49
Nároky na diskový prostor
Schéma databáze
Záloha a obnovení
Může být relativně malý, pokud jsou historická data archivována
Větší z důvodu existence agregačních struktur, historických dat a větší množství indexů než u OLTP
Vysoce normalizované s mnoha tabulkami
Denormalizované s méně tabulkami, většinou se používá schéma Hvězda nebo Sněhová vločka
Záloha musí být prováděna pečlivě a svědomitě, protože ztráta provozních údajů je pro běh obchodních procesů kritická a často vede k velkým finančním ztrátám a právní zodpovědnosti
Místo pravidelného zálohování, můžou být některá prostředí jednoduše zavedena a načtena z OLTP jako způsob obnovy
Tabulka 7 Rozdíly mezi OLTP a OLAP systémy.
50
3. Reportování dat (Data mining) Pojem data mining v překladu znamená dolování dat. V praxi se můžeme setkat i s pojmem dobývání znalostí z databáze – Knowledge Discovery in Database (KDD). Jedná se o analytickou metodu, k získávání užitečných a žádoucích informací z dat. Tato metoda je velmi úzce spjata s datovým skladem, jako s kvalitním zdrojem dat. Data mining je primárně používán dnešními společnostmi, se silným zaměřením na spotřebitele, maloobchodníky, finanční, komunikační, marketingové a mnohé další organizace. Data mining umožňuje těmto společnostem určovat vztahy jak mezi vnitřními faktory, jako jsou například: cena, umístění produktu nebo dovednosti zaměstnanců, tak externími faktory, jako jsou například: konkurence schopnost, ekonomické ukazatele nebo demografické údaje zákazníka. Tyto faktory společnostem umožní určit jaký je prodejní dopad, spokojenost zákazníka, firemní zisky nebo mnoho dalších údajů, jež jim slouží například k oslovení určitého segmentu trhu. Na obrázku je znázorněno postavení Data miningu v získávání údajů (znalostí) z databáze.
Obrázek 19 Pozice Data miningu v získávání údajů22 Obecně zde platí pravidlo Garbage In Garbage Out, čili smetí dovnitř smetí ven, znamená to, že z nekvalitních zdrojů nedostaneme kvalitní data. Ve většině případů se data mining využívá k marketingu pro segmentaci zákazníků, pro zvýšení efektivnosti reklamních kampaní nebo analýzy obchodního košíku. Tato analýza může být použita jak u 22
Business Intelligence, KDD and Data mining:definitions[online][cit. 2011-04-07] Dostupné:http://www.kmining.com/info_definitions.html
51
kamenných obchodů, tak i u elektronických obchodů. Elektronické obchody mají oproti kamenným obchodům výhodu možnosti sledování, jaké produkty si zákazník prohlížel. Kde výsledky poukazují na pravděpodobnost nákupu jednoho typu produktu s jiným produktem. U kamenných obchodů jsou tyto analýzy využívány k rozmístění zboží, u elektronických obchodů jsou doporučení, co si k danému výrobku ještě koupili ostatní zákazníci. „Nárůst aplikací v oblasti data miningu se projevil i na softwarovém a konzultačním trhu. Existuje již poměrně široká nabídka specializovaných softwarů pro tento účel. Vedoucími trhu data miningových softwarů jsou komerční aplikace SAS EnterpriseMiner, SPSSClementine a STATISTICA Data Miner, mezi známé nekomerční softwary patří Weka a Orange. Protože data mining zahrnuje velkou šíři metod a způsobů práce, je obtížné podat jednoznačný návod k postupu. Přesto během 90. let vykrystalizovaly dvě obecné metodologie, které alespoň v hrubých rysech popisují jednotlivé kroky: metodologie SEMMA, za níž stojí firma SAS, a CRISP-DM, vyvinutá konsorciem firem, mezi něž patřil druhý hlavní hráč na trhu, SPSS“23 Metodologie SEMMA se skládá z pěti částí. SAMPLE – zabývá se vybíráním vhodných objektů EXPLORE – zabývá se redukcí dat a vizuální explorací MODIFY - seskupování objektů a hodnot atributů, datové transformace MODEL – zde dochází k analýze dat ASSESS – porovnání interpretace a modelů Další metodologie se nazývá CRISP-DM, tu si popíšeme trochu podrobněji, než předchozí metodologii.
3.1 Metodologie CRISP-DM CRossIndustry Standard Proces for data mining jak již názvů vyplívá je standardizovaná metodologie pro všechny obory, bez ohledu na to odkud data pochází. Tato metodologie popisuje data mining v šesti krocích, které si následně popíšeme. Business Understanding (porozumění problému) – v této fázi je potřeba dobře a srozumitelně porozumět požadavkům zákazníka a jasně stanovit cíl, protože
23
Data mining [online][cit. 2011-04-04] Dostupné:http://cs.wikipedia.org/wiki/Data_mining
52
jakýkoliv projekt se bez stanovení cíle neobejde. Dále zde dochází k návrhu a tvorbě plánu řešení daného problému. Data Understanding (porozumění datům) – je potřebné pro další vývoj procesu, pokud datům neporozumíme, tak tím ovlivníme celkovou kvalitu řešení. V této části procesu dochází k vytváření prvních hypotéz, které se během celého procesu snažíme potvrdit, vyvrátit nebo nalézt nové řešení. Data Preparation (příprava dat)- v této fázi probíhá integrace více datových zdrojů, čištění a úpravě dat, do podoby, která je nezbytně vyžadována analytickými nástroji a metodami, které se v dalším průběhu procesu na data aplikují. Je zde potřeba dobré znalosti dat, která je popsána výše, protože špatná integrace dat vede ke znehodnocení zdrojů a snížení kvality řešení. Modeling (modelování) – jsou zde vybrány a použity různé techniky modelování, nastavení parametrů na optimální hodnoty. Je zde obsaženo několik technik pro časté problémy data miningu. Avšak některé techniky mají specifické požadavky na formu dat, proto se vracíme k fázi Data Preparation, kde si data připravíme, jak potřebujeme. Dále vybereme několik vhodných řešení, která jsou vhodná a postupují do další fáze procesu. Evaluation (hodnocení) – V této fázi máme již vytvořený model nebo několik modelů, které mají vysokou datovou kvalitu. Modely musí být zhodnoceny a rozděleny dle různých kritérií, ověřuje se správnost řešení pomocí těchto vytvořených modelů. Před tím, než bude model implementován, musíme detailně přezkoumat fáze při jeho tvorbě, cílem tohoto hodnocení je poukázat, zda nebyla opomenuta nějaká obchodní záležitost, na kterou nebyl brán dostatečný zřetel, což by mohlo způsobit nekvalitní výsledná řešení. Deployment (nasazení) – je posledním krokem v procesu. Mohlo by se zdát, že tím celá práce skončila, avšak nekončí, protože se proces začíná cyklicky opakovat jak je zřejmé z níže uvedeného obrázku 19. Pokud jsou výsledky data miningu implementovány do business procesů, je zapotřebí udržovat modely aktuální. Závislost mezi daty se časem mění, a pokud by nebyl systém aktualizován, nebyl by dostatečně kvalitní a tím by ztratil i svou funkčnost. Tomu se zabrání častým a pravidelným ověřováním funkčnosti modelu, novými daty.
53
Obrázek 20 CRISP-DM24 Lidé z praxe uvádějí, že nejdůležitější je fáze porozumění problému v procentuálním vyjádření přikládají 80% významu a 20% času. Kdežto časově nejnáročnější fáze je fáze přípravy dat (80 % času, 20 % významu). Velmi málo práce zaberou vlastní analýzy 5% času a 2% významu. Aby model sloužil co možná nejdéle je zapotřebí dodržet několik kroků. Kontrola konzistence skóringu Kalibrace modelu Obnova modelu Vývoj nového modelu Kontrolo konzistence skóringu Hlavní součástí v údržbě modelu je jeho kontrola, zda je skóring konzistentní (nemění se jeho vlastnosti) Ke kontrole nám postačí pouhý aritmetický průměr skóre a následné srovnání s minulými hodnotami, od kterých by se neměl výrazně lišit. V důsledku úplnosti je možné informaci doplnit o počet chybějících pozorování, tedy hodnoty NULL nebo 24
Process Model [online][cit. 2011-05-04] Dostupné: http://www.crisp-dm.org/Process/index.htm
54
doplnit směrodatnou odchylku. Pokud dojdeme k zjištění, že byla porušena konzistentnost, může to být způsobeno následujícími příčinami: Technická závada skóringu Změna portfolia zákazníků Změna chování zákazníků U první příčiny může dojít, pokud dojde k zásahu do struktury datového skladu, například přidaly se nové tabulky, změnil se jejich název, změnila se jejich velikost nebo byly zrušeny číselníky, apod. Následně může nastat jeden ze dvou stavů. Buď skóring zákazníků úplně selže, to znamená, že na výstupu jsou nesmyslné hodnoty, většinou se stává, že všichni zákazníci mají stejné skóre, nebo naopak obsahuje prázdné hodnoty NULL. Druhá příčina nastává, pokud se změní portfolio skórovaných zákazníků. To ovlivňuje rozhodnutí managementu, například některým zákazníkům se nadále nebudou poskytovat některé služby, nebo se zaměřit na určitou skupinu zákazníků. O této záležitosti jsou provozovatelé většinou včas vyrozuměni. Na druhou stranu se tím také změní struktura zákazníků v databázi. Například mohou být vyřazeni ze skupiny, která používá úvěrové karty, zákazníci se špatným skórem. Tím se zvýší průměrné skóre celé skupiny, avšak není důvod, v této situaci nějak měnit model, pouze se nechá tak jak byl doposud. Avšak závažnější změna nastává, pokud je změna skóringu zákazníka způsobena jeho náhlou změnou chování. Pro představu banka vyvinula model na predikci využívání úvěrových karet, který je závislý na užívání spotřebitelského úvěru. Následně začala banka nabízet svým zákazníkům výhodný kontokorent, proto větší počet zákazníků přestal předešlou službu využívat, tím se změnilo jejich chování a model se stal nepoužitelným. Proto je nutné vytvořit úplně nový model. Mohlo by se zdát, že nalézt příčinu změny skóringu zákazníka je složité. Postačí provést kontrolu konzistence všech proměnných hodnot, které vstupují do modelu. Na základě této kontroly nalezneme proměnné, které mohou za změnu vlastností celého modelu. Kontrola se provádí pomocí aritmetického průměru nebo pomocí směrodatné odchylky a jejich porovnání s předchozími hodnotami. „Zpravidla se dá říct, že kontrola konzistence by se měla provádět bezprostředně po každém skóringu. Jedná se totiž o velmi jednoduchou kontrolu, která může firmu ochránit před obrovskými ztrátami. Navíc vzhledem ke své jednoduchosti nevyžaduje tato kontrola žádné znalosti z oblasti data miningu a je možné ji bez problému delegovat i na oddělení 55
IT, které může operativně zasáhnout“25. Kalibrace modelu Často se odhadované hodnoty skóringu liší od skutečných hodnot a to vlivem sezónních faktorů. Například: model, který byl vyvinut na získaných datech z období března, až června, na odhadu zákazníků, kteří mají zájem o hotovostní úvěr. Poptávka po těchto úvěrech může před Vánocemi prudce vzrůst, proto je u všech klientů v portfoliu větší pravděpodobnost poptávky, než je u jiného modelu z jiného období. Z dekalibrovaného modelu je možnost určit, který zákazník má lepší nebo horší skóre. Dekalibrovaný model může přecenit nebo podcenit reálnou situaci, tím je myšleno, že uživatel v rámci obsluhy modelu, má namysli, že profitabilita schvalování zákazníků je vyšší nebo nižší než v reálu. Jeli model dekalibrovaný zjistíme porovnáním průměrného skóre s průměrnou hodnotou odhadovanou proměnnou, v našem příkladu je to pravděpodobnost poptávky po úvěru, spolu s procenty zákazníků, kteří si úvěr skutečně objednali. Pokud jsou tyto veličiny hodně odlišné, je nutná kalibrace modelu. Kalibrovat lze teoreticky i modely založené na neuronových sítích či rozhodovacích stromech, není to však tak jednoduché jako u lineární či logistické regrese. Mnohem jednodušší je celý model přepočítat. Obnova modelu Postupem času dochází k dekalibraci modelu, ale také ztrácí svou schopnost predikce (model není schopen dobře rozeznat špatné a dobré zákazníky). Například je model používán v cíleném marketingu, projeví se jeho schopnost predikce v menších ohlasech zákazníků na marketingové nabídky. Jedním z důvodu snížené schopnosti predikce je změna na trhu, kde jsou produkty zákazníkovi nabízeny jak vlastní společností tak konkurencí, změnou ekonomické situace, kde se mění příjmy zákazníků a ceny zboží rostou. Tyto změny mají také vliv na zákazníky, kteří na ně reagují změnou svého chování, proto se některé atributy zákazníka považují za důležité a některé méně, při vstupu do modelu. U obnovy modelu je potřeba nově nastavit všechny váhy, které pak podrobněji vyjadřují důležitost proměnných v modelu. Oproti kalibraci modelu, vyžaduje obnova modelu použití statického softwaru a přepočítání modelu na nových datech. Kde seznam atributů se nemění, mění se pouze jeho váha. 25
Lubomír Hanusek, Data miningové modely a jejich údržba, [online][cit. 2011-05-04] Dostupné:http://computerworld.cz/software/Data-miningove-modely-a-jejich-udrzba-3714
56
Vývoj nového modelu Při obnově modelu se obvykle nepodaří dosáhnout takové kvality, jakou měl na začátku, většinou dojde pouze k malému přiblížení a ke kalibraci modelu. Z dlouhodobého hlediska je tento postup neudržitelný, protože po několika letech ztratí nějaké atributy svou sílu predikce. V tomto důsledku je zapotřebí vyvinout zcela nový model. Ten je zapotřebí vyvinout i u změny chování zákazníků, jak jsem se zmínil výše u kapitoly „Konzistence“. Vývoj nového modelu značně zasahuje no IT infrastruktury, kde je potřeba změnit samotné parametry modelu, ale nezbytně připravit výpočet nových atributů a model je nutné určitou dobu testovat. „Četnost údržby závisí zejména na tom, jak moc je pro nás kritický nefunkční model (můžeme si nejspíš dovolit jednu nepodařenou marketingovou kampaň, ale asi by bylo tragické mít dlouhodobě nefunkční model na schvalování úvěrů) a jak rychle dochází v daném oboru ke změnám (v telekomunikacích se dá očekávat mnohem turbulentnější prostředí než třeba v energetice). Potřebuje-li uživatel kalibrovaný model, je ideální zvolit měsíční periodicitu (čím rychleji se bude na sezónní výkyvy reagovat, tím lépe, na druhou stranu dekalibrace modelu neznamená až tak vysoké riziko, aby ji bylo třeba provádět každý den). Každých šest až dvanáct měsíců stojí za úvahu model obnovit, tj. přepočítat jeho parametry. Vývoj úplně nového modelu se zpravidla doporučuje po dvou až čtyřech letech“.26 Data mining lze v zásadě rozdělit do dvou skupin Predikce a Deskripce. Predikce znamená prognózu nebo předpověď. Zabývá se předpovídáním dalšího vývoje na základě předchozích a získaných znalostí. Tato metoda předpovědi má své využití například na určení vývoje ceny na burze a mnoho dalších. Deskripce chceme-li někomu předat nějaké informace, musím být schopni tuto skutečnost logicky popsat. Avšak někdy s popisem daných skuteční bývají problémy, například nemůže dát zákazníkovi tabulku s různými algoritmy a přesvědčit ho o tom, že tak na tomto základě to funguje. Pro představu máme jakousi skříňku, která má na vstupu 72 hodnot a na výstupu hodnotu pouze jen jednu. Tato skříňka zpracovává informace z výrobní linky a rozhoduje o kvalitě 26
Lubomír Hanusek, Data miningové modely a jejich údržba, [online][cit. 2011-05-04] Dostupné:http://computerworld.cz/software/Data-miningove-modely-a-jejich-udrzba-3714
57
výrobku. Pomocí data miningu se nám podaří redukovat vstupní data ze 72 na 8, které nám při zachování kvality stačí na výpočet výstupní hodnoty. Nasadíme-li získané informace do systému zákazníka, dochází k minimalizaci počtu měření, tím se změní i rychlost výrobního procesu k lepšímu. V tomto případě byl data mining úspěšný a zákazníkovi se investice vyplatila.
3.2 Nejpoužívanější techniky Data miningu Mezi nejpoužívanější techniky, které se u Data miningu používají, patří: Rozhodovací stromy Neuronové sítě Detekce shluků Analýza nákupního košíku Rozhodovací pravidla Asociační pravidla Analýza rozhodování
3.2.1 Rozhodovací stromy (Decision trees) Jsou analytické nástroje, které slouží k objevení pravidel a vztahů v datovém souboru pomocí systematického větvení na nižší úrovně. Význam toho dělení spočívá v určení takových proměnných, které záznamy rozdělí a sníží tak nejistotu uživatele. Problém nastává v okamžiku, kdy se uživatel rozhoduje na kolik větví daný případ rozdělit nebo na kolik větví rozdělit proměnnou. Může nastat situace, že při velkém rozdělení jedné proměnné na mnoho větví, dostaneme v každé větvi několik málo záznamů, z kterých nejsme schopni vyvodit rozhodovací pravidla. Rozhodovací stromy jsou vhodné v případě provedení klasifikace nebo predikce. Na obrázku 21. je znázorněn rozhodovací strom banky, která na základě určitých proměnných a rozhodnutí poskytne klientovi úvěr.
58
Obrázek 21 Rozhodovací strom27
3.2.2 Neuronové sítě (Artifical neural networks) „Neuronové sítě jsou v podstatě zjednodušeným modelem neuronových propojení v lidském mozku modelovatelným výpočetní technikou. Jejich principem je nastavení parametrů jednotlivých „neuronů“ v procesu učení se z tréninkových vzorků dat, aby výsledná konfigurace co nejlépe vyhovovala následné klasifikaci a predikci. Neuronové sítě jsou příkladem aplikace jedné z vývojových linií dolování dat – umělé inteligence“28
3.2.3 Detekce shluků (Clustering detection) Jsou vytvářeny modely, které jasně identifikují data a jsou si velmi podobné. Zjišťování shluků nevychází z předem definovaných charakteristik shluků, ale děje se tak při jejich tvorbě i jejich počet je vyhledáván na základě podobnosti zkoumaných dat. Pro představu se jedná například o organizaci, která obchoduje s určitým zbožím. Detekce shluků jí pomůže nalézt nejvíce ziskové zákazníky a zaměřit se tak na podobné zákazníky a snažit se je získat.
27
Metody dobývání znalostí [online][cit. 2011-08-04] Dostupné: http://euromise.vse.cz/kdd/index.php?page=metody 28 Ota Novotný; Jan Pour; David Slánský. Business Intelligence, Jak využít bohatství ve vašich datech. 1.vyd. 2005. ISBN 80-247-1094-3.
59
3.2.4 Analýza nákupního košíku (Market basket analysis) Tato analýza je rozšířenou formou detekce shluků. Používá se k vyhledávání skupin a prvků, které se většinou zobrazují pospolu v jedné transakci. Někteří si možná ani neuvědomují, že se s tou to analýzou již setkali. Příkladem nám je internetový obchod, kde si zakoupíme určitou věc a k ní nám je nabízená další „ostatní zákazníci si také ještě koupili“. U e-shopů můžeme určit, které produkty budou na stránku umístěny společně. U kamenných obchodů zase můžeme produkty vyskládat do jednoho regálu nebo vyškolit prodavače, které zboží mají zákazníkovi ještě nabídnout.
3.2.5 Rozhodovací pravidla (Decision rules) Jedná se o algoritmy pokrývající množinu, která pracuje na základě metody seperate and conquer (odděl a panuj). Jedná se o nalezení pravidel, které pokrývají příklady stejných tříd a oddělit je od příkladů jiných tříd. If příjem = vysoký
Than úvěr = ano
If účet = vysoký
Than úvěr = ano
If příjem = malý and if účet = střední and if
Than úvěr = ano
nezaměstnaný = ne
Tabulka 8 Rozhodovací pravidla.
3.2.6 Asociační pravidla Tyto asociační pravidla hledají všechny asociace mezi hodnotami různých atributů. Pro lepší názornost si uvedeme tabulku. If příjem = velmi vysoký
Than nezaměstnaný = ne
If nezaměstnaný = ano
Than příjem = nízký
Tabulka 9 Asociační pravidla
3.2.7 Analýza závislostí Tato analýza nezkoumá prvky na základě jejích vlastností, ale zkoumá jejich chování a vztahy mezi nimi.
60
4. Řízení procesů zabezpečení kvality dat v Data Warehouse Jak už bylo popsáno v první kapitole, kvalita je nezbytným atributem všech řídících procesů jak transakční systémy TPS, systémy pro manažérské řízení MIS a rozhodovací systémy EIS. Bez kvalitních dat nemůžeme dosáhnout požadovaných výsledků, nesprávně fungují i podnikové procesy, což má za následek velké ekonomické ztráty a management nemůže udělat správná rozhodnutí na základě analýz nekvalitních dat. Každá organizace nebo podnik jsou tak úspěšní a konkurence schopní jak kvalitní mají data. Váha negativního dopadu zpracování nekvalitních dat se v dnešní době stává významnější, díky zvětšování rozsahu a složitosti informačních systému a zvyšování potřebnosti IT v podnikových procesech. Nejprve si popíšeme nástroje, které podnikové procesy popisují a které jsou nejčastěji používané.
4.1 Nástroje pro popis procesů V této kapitole budou popsány tři nástroje pro popis procesů: UML, VISIO a ADONIS, kde ke znázornění procesů bude použit právě poslední jmenovaný (ADONIS).
4.1.1 UML UML nebol Unified Modeling Language je unifikovaný modelovací jazyk, který obsahuje vlastní grafickou syntaxi, pravidlo pro sestavování jednotlivých elementů jazyka do větších objektů, dále obsahuje sémantiku, kde se jedná o jednoznačné pravidlo, které určuje jednotlivým syntaktickým výrazům jejich význam. UML se většinou používá při návrhu softwarových systémů, protože úspěšná a rychlá implementace složitějších aplikací je právě při objektově orientovaném návrhu. Při objektově orientovaném návrhu lze použít dalších podpůrných prostředků, jako jsou odlišné typy diagramů. Při sdílení informací mezi vývojáři a analytiky má UML tu výhodu, že je zde přesně specifikováno co má každý diagram obsahovat. Vytvářené grafy v UML musí mít vnitřní konzistenci a přesně danou sémantiku, což u jiných grafů není obecně zaručeno. UML obsahuje několik lišících se typů diagramů a to podle toho, jaké se plánují nebo zpracovávají úlohy. Tyto diagramy se od sebe liší seznamem použitých značek, jejich 61
vzájemným propojením a související sémantikou. Velikou výhodou UML a pomocí tohoto jazyka vytvořeným diagramů je otevřenost a rozšiřitelnost standardu, podpora celého vývojového cyklu aplikace či systému a podpora pro různé aplikační oblasti. Avšak nevýhoda programovacího jazyka UML je jeho složitost. UML je spíše vhodný pro audit IS a je zastaralý.
4.1.2 VISIO Visio je nástroj z dílny Microsoft konkrétně z kancelářského balíku vyšších verzí Microsoft office. Původně pocházel od společnosti Visio Corporation, kterou v roce 2000 koupil právě Microsoft. Visio je nástroj který umožňuje uživateli kreslit procesní schémata. Jeho nevýhoda je složitost při tvorbě schémat.
4.1.3 ADONIS Case nástroj ADONIS, s jehož pomocí lze soustavně zlepšovat procesní výkonnost v rámci podniku. ADONIS je vhodný pro tvorbu dokumentace procesních map, optimalizace procesů, restrukturalizaci a snížení nákladů. „Základem nástroje ADONIS je tzv. rámec pro procesní řízení a zavádění kontinuálního cyklu zlepšování procesů - BPMS (Business Process Management Systems). Koncepty ADONIS jsou založeny na jednotlivých fázích, definovaných v rámci BPMS a na systému permanentního cyklu, jak je tento popisován v různých odlišnostech v literatuře na téma procesního řízení. Přitom jsou v popředí chápány a analyzovány čtyři základní prvky podniku, kterými jsou produkty, procesy, organizační struktura a informační technologie v jejich vzájemných souvislostech Zobrazených na obrázku 22. Cílem řízení podnikových procesů je optimalizace procesů a podnikových struktur, jakož i využití zdrojů a technologií. Toho je dosaženo prostřednictvím využívání holistického přístupu ve sběru, vyhodnocování, optimalizaci a řízení podnikových procesů a investovaných prostředků. Rozhodujícím faktorem této činnosti je především možnost provádět v rámci ADONIS konzistentní modelování, analýzy, simulace a hodnocení podnikových procesů. V rámci nástrojů BOC Management Office se tak dále nabízí možnost, v ADONIS identifikované odborné služby a aplikace IT“29.
29
Metodika [online][cit. 2011-20-04] Dostupné: http://www.boc-group.com/cz/products/adonis/method/
62
Obrázek 22 Rámec procesního řízení BOC30 Mezi výhody Case nástroje ADONIS patří: Rozsáhle webové a publikační možnosti Jednoduché a intuitivní prostředí Podnikohospodářské vyhodnocovací funkce (např. plánování kapacit, procesní účetnictví, atd.) ADONIS je vhodný a názorný jak pro IT tak i pro Business management.
4.2 Návrh na zlepšení procesu změny údaje v Data Warehouse Každý uživatel občas potřebuje přidat, odebrat nějaké záznamy z datového skladu nebo má požadavek na to co se mu má zobrazit. K této změně jsou obecně potřeba tři lidé: zadavatel požadavku, analytik a programátor. My si postup ukážeme na schématu vymodelovaném v CASE nástroji ADONIS.
30
Metodika [online][cit. 2011-20-04] Dostupné: http://www.boc-group.com/cz/products/adonis/method/
63
Obrázek 23 Návrh na změnu požadavku v DWH (vlastní úprava) 64
Zadavatel požadavku, většinou se jedná o uživatele, zadá požadavek na změnu aplikace v datovém skladu, nebo co přesně chce, aby se v datovém skladu objevilo. Tento požadavek příjme analytik, který úzce pracuje s metasystémem. Metasystém je systém, který slouží k popisu jiného systému nebo k jeho modulu. V tomto případě se jedná o informační metasystém. Kde je tento systém považován za metadatabázi, která obsahuje metadata, pomocí různých operací je umožněno uchovávat a zpracovat tyto metadata. Analytik prostuduje požadovanou změnu z hlediska proveditelnosti, kvality vstupních dat a aktuální stav datového skladu. Pokud shledá požadavek za nemožný, vytvoří report, který pošle zpět zadavateli s objasněním, proč nemohl vyhovět jeho požadavku. Pokud lze požadavek realizovat, vytvoří analytik přesný postup práce s dostatečnou dokumentací a předá ji programátorovi. Programátor pomocí dostupných softwarových aplikací (podle platformy) změnu realizuje a vypracuje report o provedení změny.
4.3 Návrh rolí při tvorbě datového skladu Z pohledu finančního ředitele se zde naskytují dvě možnosti pohledu na řešení této problematiky, buď k této práci použít své zaměstnance, nebo najmout externí pracovníky. Externí pracovníci jsou mnohem nákladnější než zaměstnanci firmy. Ovšem je zde otázka, kteří pracovníci budou lepší při tvorbě datového skladu z hlediska jejich zkušeností a kvality práce. Při najmutí externích pracovníků jsou jejich výhody v tom, že mají větší zkušenosti s implementací datových skladů. Faktem zůstává, že i dnes nalézt pracovníky, kteří mají rozsáhlé zkušenosti s datovými sklady je velmi složité a časově náročné, proto pokud je potřeba sestavit tým velmi rychle je jednodušší najmout na tuto práci své zaměstnance, ale pokud je vše narychlo, tak jakýkoliv projekt, ztrácí na své kvalitě. Návrh rolí, které jsou potřeba při projektu na datovém skladu, jsou zároveň také nezbytné pro jeho kvalitu a funkčnost. Project manager – dohlíží na vývoj datového skladu a je zodpovědná za jeho úspěšné dokončení. DBA (Database administrator) – je zodpovědný za hladký chod databáze. Další úkoly, které může mít na starost, jsou plánování a provádění záloh, stejně tak i obnovy a může ladit výkon systému. Technical Architect – stará se o rozvoj a implementaci celkové technické architektury datového skladu. Na základě zpětné vazby od klienta zajišťuje konfiguraci na jeho počítači a stará se o hardware a software. 65
ETL developer – zodpovídá za plánování, rozvoj a za procesy extrakce, transformace a přenos dat do datového skladu. Front End Developer – je zodpovědný za přední vývoj uživatelského programu, ať už je to klient – server nebo přes webové rozhraní. OLAP Developer – osoba zodpovědná za vývoj OLAP kostek. Trainer – po implementaci datového skladu, pracuje s koncovými uživateli, aby jim vysvětlil jak je nastavený uživatelský program a jak s ním správně pracovat, aby koncoví uživatelé dosahovali co nejlepších výsledků při „dolování“ dat z datového skladu. Data Modeler – je zodpovědný za přijetí datové struktury, která je implementována v podniku a na jejím základu vytváří schémata, která jsou vhodná pro analýzy OLAP. QA Group – je nejdůležitější součásti projektu, zajišťuje správnost dat v datovém skladu. Protože nesprávná data často mívají za následek restrukturalizaci skladu, což je jak finančně tak i časově velmi náročné a v horším případě zrušení celého projektu. Na obrázku jsou výše pospané role zobrazené.
Obrázek 24 Role při tvorbě datového skladu (vlastní tvorba)
66
Obrázek 25 Organizační struktura oddělení IT (vlastní úprava)
67
Veliký podíl na kvalitě dat má bez pochyb i MIS (Manager Information System), který je součástí organizační struktury oddělení IT. MIS zajišťuje celkovou správu datového skladu a to jeho tvorbou, údržbu a zavádění nových dat. V celé organizační struktuře lze přiřadit role a jejich činnosti, popřípadě různé dokumenty, pracovníky, kteří zodpovídají za aktualizaci datových prvků, které jsou pak zařazovány do metasystému a správu daného funkčního útvaru. Toto rozdělení činností slouží k rozdělení odpovědnosti za kvalitu a správnost datových prvků jednotlivých funkčních orgánů.
68
Závěr V diplomové práci je popisována tvorba a účelnost datového skladu. Jsou zde popsány i různé metody tvorby datového skladu. Popisován je i proces ETL pomocí něhož procházejí data třemi etapami, než se jimi naplní datový sklad. Kvalita dat je popsána o něco stručněji, jsou zde popsány chyby, které mohou nastat, tak i jejich odstranění pomocí různých technologií. Jedním ze systému, který je popsán je systém Ataccama DQC (Data QualityCenter), kde na území České republiky je spíše známý pod názvem Adastra Purity. Což je nástroj pro řízení kvality dat. Dále jsme se zabývaly popisem analýzy OLAP, kde je zmíněno i 12 pravidel E. F. Codda. Jsou zde popsány různé varianty analýz, ale i Datová kostka. Popisováno je i několik metodologii data miningu včetně metodologie CRISP-DM a nejpoužívanější techniky při reportování dat. Cílem praktické části bylo aplikovat různé poznatky z celé práce. Kde byly popsány některé CASE nástroje k modelování různých procesů. Kde jsem jako modelovací nástroj zvolil CASE nástroj ADONIS od společnosti BOC Group, s kterým mám v rámci cvičení s panem Slavíkem určitou zkušenost. Pomocí ADONIS jsem namodeloval proces ke zlepšení požadavku na změnu údaje v Data Warehouse, kde jsou popisovány tři subjekty k provedení tohoto požadavku a k jeho realizaci s potřebnou dokumentací. Dále jsem navrhoval role na tvorbu datového skladu, kde je potřeba celkovou práci na projektu rozdělit na několik osob, protože není v silách jednoho pracovníka zvládnout tak komplexní a časově náročné zadaní. Z pohledu kvality dat, má toto rozdělení jisté uplatnění. Vzhledem k tomu, že každý pracovník bude zastávat jednu část z projektu, bude mít dostatek času na to, aby práci odvedl v dostatečné kvalitě, než kdyby měl na starosti více částí na projektu. K dobrému fungování datového skladu je také potřeba, aby kvalitně fungovala organizační struktura IT, která má bezpochyby také vliv na celkovou správu datového skladu, v organizační struktuře jsou také popsáni pracovníci a jejich činnosti, kteří zodpovídají za kvalitu datových prvků a jejich aktualizaci v jednotlivých částech struktury IT.
69
Seznam použité literatury Tištěné monografie 1. Lacko, Luboslav. Business Intelligence v SQL Serveru 2008. 1.vyd. ComputerPress. 2009. ISBN 978-80-251-2887-9 2. Lacko, Luboslav. Databáze: Datové sklady, Olap a dolování dat s příklady v SQL Serveru a Oracle. 1.vyd. ComputerPress. 2003. ISBN 80-7226-969-0 3. Loshin, David. Business Intelligence. 2003. Morgan Kaufman Publisher. ISBN – 10:1-55860-916-4 4. Miniberger, Bohumil, Referát: Kvalita datových skladů-nezbytný předpoklad předcházení rizik manažerského rozhodování. Sborník z 11. ročníku mezinárodní konference „Současnost a budoucnost krizového řízení“. Praha 2009, ISBN 97880-254-5912-6 5. Novotný, Ota; Pour, Jan; Slánský, David. Business Intelligence, Jak využít bohatství ve vašich datech. 1.vyd. Grada Publisher. 2005. ISBN 80-247-1094-3. Elektronické monografie 6. Bergner Martin, Čistá a kvalitní data z nebe nespadnou [on line]. 2007 [cit. 201102-21]Dostupné z WWW:
7. Business Intelligence, KDD and Data mining:definitions[online]. 2004 [cit. 201104-07] Dostupné z WWW: 8. Data mining [online]. 2011 [cit. 2011-04-04] Dostupné z WWW: 9. Fact constellation schema architecture[online]. 2011 [cit. 2011-02-28] Dostupné z WWW: 10. Hanusek Lubomír, Data miningové modely a jejich údržba, [online]. 2009 [cit. 2011-05-04] Dostupné z WWW: 11. HOLAP – Hybrid OLAP Architecture[online][cit. 2011-02-28] Dostupné z WWW: 12. Informační systém [on line]. 2011[2011-02-07] Dostupné z WWW: 70
13. Kay Russel, Zaostřeno na datové kostky [on line]. 2004[cit. 2011-02-21] Dostupné z WWW: 14. Kmínek Pavel, Konsolidace dat ve finančních institucích [online]. 2008[cit. 201102 - 03]Dostupné z WWW: 15. Metodika [online]. 2011[cit. 2011-20-04] Dostupné z WWW: 16. Metody dobývání znalostí [online]. 2002[cit. 2011-08-04] Dostupné z WWW: 17. MOLAP – Multi-dimensional OLAP Architecture[online][cit. 2011-02-28] Dostupné z WWW: 18. Nástroje pro Data Quality Management [online][cit. 2011-02-03]Dostupné z WWW: 19. OLAP Multidimensionalita[online][cit. 2011-02-21] Dostupné z WWW: 20. OLTP vs. OLAP [online]. 2009 [cit. 2011-02-28] Dostupné z WWW: 21. Poláková Jiřina, Kalousková Eva, Univerzita Pardubice, Data, informace, znalosti rozdíly, podrobnosti [on line]. 2007[cit. 2011-02-07]. Dostupné z WWW: 22. Process Model [online][cit. 2011-05-04] Dostupné z WWW: 23. ROLAP – Relational OLAP Architecture[online][cit. 2011-02-28] Dostupné z WWW: 24. Slánský David, Audit řešení datového skladu, [on line]. 2011 [cit. 2011-02-25] Dostupné z WWW: 25. Vítek, Uložení dat v OLAP systémech, [online]. 2002 [cit. 2011-02-28] Dostupné z WWW:
71
Seznam obrázků Obrázek 1 Grafické znázornění Datového skladu podle Inmona (vlastní úprava). ............... 9 Obrázek 2 Schéma přírůstkové metody (vlastní úprava). ................................................... 14 Obrázek 3 Schéma Přírůstkové metody shora dolů (vlastní úprava). ................................. 16 Obrázek 4 Přírůstková metoda zdola nahoru (vlastní úprava). ........................................... 17 Obrázek 5 ETL v procesu zavedení dat do datového skladu (vlastní úprava). ................... 18 Obrázek 6 Hierarchická struktura informačních systémů podniku .................................... 24 Obrázek 7 Organizační struktura firmy (vlastní úprava) ..................................................... 31 Obrázek 8 Proces správy datového skladu (vlastní úprava). ............................................... 33 Obrázek 9 Ukázky z aplikace ARIS IT architect – jednoho z nástrojů vhodných pro modelování architektury IT ................................................................................................. 34 Obrázek 10 Datová kostka .................................................................................................. 39 Obrázek 11 Příklad datové kostky (vlastní úprava)............................................................. 40 Obrázek 12 Hvězdicové schéma (vlastní úprava). .............................................................. 41 Obrázek 13 Schéma Sněhová vločka (vlastní úprava). ....................................................... 41 Obrázek 14 Schéma Souhvězdí ........................................................................................... 42 Obrázek 15 Schéma ROLAP ............................................................................................... 44 Obrázek 16 Schéma MOLAP .............................................................................................. 45 Obrázek 17 Schéma HOLAP............................................................................................... 47 Obrázek 18 Závislost mezi OLTP a OLAP ......................................................................... 49 Obrázek 19 Pozice Data miningu v získávání údajů ........................................................... 51 Obrázek 20 CRISP-DM ....................................................................................................... 54 Obrázek 21 Rozhodovací strom .......................................................................................... 59 Obrázek 22 Rámec procesního řízení BOC ......................................................................... 63 Obrázek 23 Návrh na změnu požadavku v DWH (vlastní úprava) ..................................... 64 Obrázek 24 Role při tvorbě datového skladu (vlastní tvorba) ............................................. 66 Obrázek 25 Organizační struktura oddělení IT (vlastní úprava) ......................................... 67
72
Seznam tabulek Tabulka 1 Rozdíly mezi Produkčními databázemi a datovým skladem. ............................. 11 Tabulka 2 Údaje o klientech. ............................................................................................... 20 Tabulka 3 Údaje o klientech v normalizované databázi. ..................................................... 20 Tabulka 4 Údaje o pohlaví klientů. ..................................................................................... 21 Tabulka 5 Údaje o pohlaví klientů v normalizované tabulce. ............................................. 21 Tabulka 6 Pojmy související s unifikací a čištěním dat....................................................... 27 Tabulka 7 Rozdíly mezi OLTP a OLAP systémy. .............................................................. 50 Tabulka 8 Rozhodovací pravidla. ........................................................................................ 60 Tabulka 9 Asociační pravidla .............................................................................................. 60
73
