Využití datového skladu jako zdroje pro Business

Transkript

U NICORN C OLLEGE
Softwarové inženýrství a informatika
Management ICT projektů
Využití datového skladu jako zdroje
pro Business Intelligence
Usage of a data warehouse as a source for Business Intelligence
Bakalářská práce
Autor: Lukáš Král
Vedoucí práce: Mgr. Peter Buchlák
Praha 2010
Unicorn College © 2010
Unicorn College, V Kapslovně 2767/2, Praha 3, 130 00
Název práce v ČJ:
Využití datového skladu jako zdroje
pro Business Intelligence
Název práce v AJ:
Usage of a data warehouse as a
source for Business Intelligence
Autor:
Lukáš Král
Akademický rok:
2010
Kontakt:
E-mail: [email protected]
Tel.: (+420) 774 246 242
Děkuji vedoucímu bakalářské práce Peterovi Buchlákovi za účinnou metodickou, pedagogickou a odbornou pomoc a další cenné rady při zpracování mé bakalářské práce.
Prohlašuji, že svou bakalářskou práci na téma „Využití datového skladu jako zdroje pro Business Intelligence” jsem vypracoval samostatně pod vedením vedoucího bakalářské práce a s použitím odborné literatury a dalších informačních zdrojů, které jsou v práci citovány a jsou též
uvedeny v seznamu literatury a použitých zdrojů. Jako autor uvedené bakalářské práce dále prohlašuji, že v souvislosti s vytvořením této bakalářské práce jsem neporušil autorská práva třetích
osob, zejména jsem nezasáhl nedovoleným způsobem do cizích autorských práv osobnostních
a jsem si plně vědom následků porušení ustanovení § 11 a následujícího autorského zákona
č. 121/2000 Sb.
V Praze dne 6. května 2010
Lukáš Král
4
5
Abstrakt
Tato bakalářská práce se zabývá datovými sklady a jejich praktickým využitím pomocí Business Intelligence (BI). Kromě popisu obou technologií je hlavní důraz kladen na znázornění jejich vzájemného vztahu
a také výhod, které z tohoto spojení pro BI vznikají. V souvislosti s tím je datový sklad nejprve definován
z pohledu dvou nejdůležitějších osobností v oboru, Williama H. Inmona a Ralpha Kimballa, a poté srovnán s operační databází. Následně se již pozornost přesouvá na Business Intelligence. Postupně je zde
rozebrána problematika reportů, OLAP analýzy a data miningu. V práci jsou také nastíněny možné směry,
kterými se budou tyto systémy spolu s datovými sklady ubírat do budoucna. V praktické části je navrhnut a
implementován funkční model datového skladu. Ten je následně použit jako zdroj pro jednotlivé BI nástroje
a jsou tak názorným způsobem demonstrovány různé způsoby jeho využití.
Klíčová slova
Business Intelligence, datový sklad, data mart, normalizovaný model, dimenzionální model, hvězdicové
schéma, reporty, OLAP, multidimenzionální databáze, data mining
Abstract
This bachelor thesis deals with data warehouses and their practical usage with Business Intelligence (BI).
Apart from describing both technologies, the main emphasis is put on illustrating their relationship and also
advantages that result for BI from this connection. Considering this a data warehouse is at first described
from a perspective of the two most important people in this discipline, William H. Inmon and Ralph Kimball
and then compared to an operational database as a possible source for BI tools. Afterwards the attention
is moved towards Business Intelligence itself. This topic is divided into several categories, reporting, OLAP
analysis and data mining. Aim of this thesis is also to outline possible future developments of these systems
along with data warehouses. In practical part a functional model of a data warehouse is designed and
implemented. It is consequently used as a source for individual BI tools and thus diferent ways of its usage
are demonstrated.
Keywords
Business Intelligence, data warehouse, data mart, normalized model, dimensional model, star schema, reports, OLAP, multidimensional database, data mining
6
Obsah
Zadání
5
Abstrakt
6
1 Úvod
8
2 Datové sklady
10
2.1 Charakteristika datového skladu podle Williama H. Inmona . . . . . . . . . . . . .
10
2.2 Charakteristika datového skladu podle Ralpha Kimballa . . . . . . . . . . . . . . .
13
2.3 Normalizovaný a dimenzionální přístup k ukládání dat . . . . . . . . . . . . . . . .
17
3 Business Intelligence
23
3.1 Reporty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
3.2 Analýza (OLAP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
3.3 Data Mining . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
3.4 Současné trendy ve vývoji datových skladů a BI . . . . . . . . . . . . . . . . . . . .
35
4 Návrh a využití datového skladu ve spojení s BI
39
4.1 Návrh a implementace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
4.2 Vytvoření reportů . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
4.3 Analýza (OLAP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
4.4 Data mining . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
54
5 Závěr
59
6 Conclusion
61
Literatura
63
Seznam obrázků
65
Seznam použitých symbolů a zkratek
66
Seznam příloh
67
Příloha 1
I
Příloha 2
VIII
7
1
1
ÚVOD
Úvod
Ještě před několika lety stačily firmám k úspěšnému konkurenčnímu boji znalosti a zkušenosti
několika svých klíčových manažerů. V posledních letech se ale situace začíná zcela zásadně
měnit. Hlavní podíl na tom má turbulentní a globalizované prostředí, které díky neustálým změnám nutí organizace k daleko rychlejšímu rozhodování než v dřívější době. Úsudek již nemůže
vycházet ze zkušeností manažerů, ale musí se opírat o správné informační podklady. Spolu se
změnou ekonomického prostředí je na firmy vyvíjen tlak také díky nárůstu konkurence či stále se
zvyšujícím požadavkům zákazníků.
V souvislosti s vývojem informačních technologií zároveň rapidním způsobem roste objem
podnikových dat, přičemž velké množství z nich obsahuje cenné informace, které by se daly využít pro rozvoj dané firmy. Otázkou však zůstává, jak tyto informace z nashromážděných dat
získat. Není proto divu, že se v posledních letech začínají prosazovat tzv. decision support systems (DSS), neboli systémy pro podporu rozhodování. Do této kategorie lze zařadit i nástroje
Business Intelligence (BI) spolu s datovými sklady, které pro BI představují jakousi datovou základnu. Tyto systémy umožňují firmám spravovat svá data a získávat z nich strategické informace
potřebné pro dosažení výhody na trhu a zvýšení šance na úspěšný boj v konkurenčním prostředí.
S tím, jak stoupá obliba DSS systémů, se však pozornost přesouvá spíše na samotné získávání
a prezentaci dat, než na formu jejich skladování. Pojmy Business Intelligence a datové sklady, byt’
se jedná o dva odlišné termíny, jsou v praxi často zaměňovány nebo se naopak označují pouze
pomocí termínu Business Intelligence.
Cílem této práce je tedy mimo jiné tyto pojmy jasně definovat a popsat. Hlavní důraz bude
ale kladen na vzájemný vztah obou subjektů. Spíše než prokazovat nezbytnost datového skladu
ve vztahu k BI si však tato práce klade za cíl demonstrovat veškeré možnosti a výhody, které
z tohoto spojení pro BI vznikají. Budou zde tedy uvedeny jednotlivé kategorie BI nástrojů, pro které
datový sklad představuje onen zdroj uvedený v názvu práce, přičemž u každé z nich bude dbáno
na to, aby byla jasně znázorněna role datového skladu. V práci také zmíním současné trendy
v oblasti datových skladů a BI nástrojů a nastíním jejich vývoj do budoucna. Kromě teoretického
znázornění využití datových skladů ve spojení s BI se pokusím tento vztah demonstrovat také na
praktické ukázce.
V souvislosti s výše uvedenými cíly je práce rozdělena do dvou částí, teoretické a praktické,
přičemž teoretická část dále obsahuje dvě kapitoly. V té první popisuji technologii datových skladů
z pohledu dvou nejvýznamnějších osobností působících v tomto oboru, Williama H. Inmona a
Ralpha Kimballa. Jsou zde uvedeny rozdíly i výhody a nevýhody obou přístupů. Zároveň zde
porovnávám datový sklad s operační databází, jako dalším možným zdrojem pro BI.
V druhé kapitole nejdříve definuji, co je to Business Intelligence, a poté se již zaměřím na popis
jeho jednotlivých kategorií. Postupně se budu věnovat reportům, OLAP analýze a data miningu.
Dále budou v této kapitole znázorněny jednotlivé výhody či možnosti, které spojení s datovými
8
1
ÚVOD
sklady BI umožňuje. V závěru ještě nastíním možnosti dalšího vývoje těchto systémů.
Druhou část této práce tvoří praktická ukázka. Jejím cílem je nejprve vytvořit fungující model
datového skladu a na něm poté s pomocí BI nástrojů demonstrovat možnosti jeho využití. Stejně
tak jako v teoretické části, i zde se zaměřím na reporty, OLAP analýzu a data mining.
9
2
DATOVÉ SKLADY
Teoretická část
2
Datové sklady
„The users of an operational system turn the wheels of the organization. The users of a data
warehouse, on the other hand, watch the wheels of the organization turn.” 1
Úvodní citace poměrně dobře naznačuje, čím se tato kapitola zabývá. V první části je vysvětlen pojem datový sklad a to z pohledu dvou nejznámějších osobností v tomto oboru, Williama H.
Inmona a Ralpha Kimballa. Oba přístupy jsou zde podrobně popsány a vzápětí také porovnány.
Druhá část se věnuje vztahu mezi dimenzionálním modelem, který tvoří základní strukturu datového skladu, a normalizovaným modelem, který je pro změnu základem provozních databází.
Tyto modely jsou srovnány a s ohledem na využití pro BI jsou uvedeny jejich výhody či nevýhody.
2.1
Charakteristika datového skladu podle Williama H. Inmona
Jako první definoval v roce 1991 termín „Data Warehouse” William H. Inmon a je také právem
nazýván „otcem datových skladů”.2 Ve své publikaci autor uvádí:
„Datový sklad je subjektově orientovaná, integrovaná, neměnná a trvale uložená kolekce dat
sloužící pro podporu rozhodování. Datový sklad obsahuje granulární korporátní data.” 3
Vzhledem k tomu, že se jeho pohled na datové sklady výrazně liší od druhého nejvýznamnějšího činitele v tomto oboru Ralpha Kimballa4 , považuji za důležité se nyní jednotlivým požadavkům uvedených v předchozí definici věnovat podrobněji.
• Subjektová orientace - datový sklad obsahuje data, která se týkají vlastního předmětu
podnikání, nikoliv zápisy jednotlivých transakcí. V klasických provozních systémech jsou
data shromažd’ována okolo aplikací dané firmy. Inmon jako příklad uvádí pojišt’ovací firmu,
jejíž aplikace mohou být auto, nehoda atd. Hlavním předmětem zájmu organizace je však
zákazník, odměna či nárok na pojistné.
• Integrovanost - tato vlastnost souvisí s tím, že do datového skladu mohou vstupovat data
z různých nesourodých částí podnikového systému. Proto musí být nejprve zformátována do
ucelené podoby - např. všechny jednotky délky jsou převedeny na cm atd. Ze všech aspektů
datového skladu je právě tento nejdůležitější. Obrázek 1 ilustruje převod dat z provozních
systému do datového skladu.
1 KIMBALL, Ralph; ROSS Margy. The Data Warehouse Toolkit: The Complete Guide to Dimensional Modeling. 2nd ed.
Wiley Publishing. Canada. 2002. str. 2
2 ANUPINDI, Nagesh V. Inmon vs. Kimball [online]. 25.8.2005, poslední revize 10.3.2010 [cit. 2010-03-15]. Dostupné
z: <http://www.nagesh.com/publications/technology/173-inmon-vs-kimball-an-analysis.html>
3 INMON, William Harvey. Building the Data Warehouse. 3rd ed. Wiley Publishing. Canada. 2002. str. 31
4 Jeho definici a struktuře datového skladu se věnuje následující kapitola.
10
2.1
2
DATOVÉ SKLADY
33
The Data Warehouse Environment
Obrázek 1: Integrovanost
integration
operational
data warehouse
encoding
appl A
appl B
appl C
appl D
m,f
1,0
x,y
male, female
appl A
appl B
appl C
appl D
pipeline—cm
pipeline—inches
pipeline—mcf
pipeline—yds
appl A
appl B
appl C
appl D
description
description
description
description
appl A
appl B
appl C
appl D
key
key
key
key
m,f
attribute measurement
pipeline—cm
multiple sources
?
description
conflicting keys
char(10)
dec fixed(9,2)
pic ‘9999999’
char(12)
Figure 2.2 Zdroj:
The issue
of integration.
Inmon.
Building
key
char(12)
the Data Warehouse. str. 33
of -gender
matters
little whether
dataů,inkde
the ware• Nízká promencoding
ěnlivost
data is
se,concerned,
na rozdílit od
provozních
systém
mohou být libovolně
house is encoded as m/f or 1/0 . What does matter is that regardless of method
měněna, doordatových
skladů warehouse
nahrají aencoding
pak již isnemohou
být nijak
modifikována. Ukládání
source application,
done consistently.
If application
data is encoded as X/Y, it is converted as it is moved to the warehouse. The
probíhá většinou
po většíchofdávkách
a představuje
tak jakýsi
snímek
datové
same consideration
consistency
applies to all application
design
issues,
such základny v uras naming conventions, key structure, measurement of attributes, and physical
čitý okamžik,
veškerá data jsou tak přesná právě k tomuto bodu. Pokud se objeví nějaká
characteristics of data.
změna, je místo
modifikace
již uložených
dat,warehouse
vytvořenis athatuložen
další snímek (dochází
The third
important characteristic
of a data
it is nonvolatile.
Figure 2.3 illustrates nonvolatility of data and shows that operational data is
k historizaciregularly
dat - viz.
následující odstavec). Toto ukládání probíhá dle předem stanovené
accessed and manipulated one record at a time. Data is updated in the
aktualizačníoperational
strategie.environment as a regular matter of course, but data warehouse data
• Trvalost uložení dat (historizace) - jak již bylo uvedeno dříve, data se v datových skladech
nepřepisují ani neodstraňují, jsou statická a určená pouze pro čtení. Díky tomu, že jsou
průběžně načítána z provozních systémů (kde jsou vždy obsažena pouze aktuální data),
je vytvářena historická sekvence událostí a aktivit.5 V praxi to může vypadat tak, že v provozní databázi budou uloženy informace o aktuálním kurzu české koruny vůči euru, zatímco
v datovém skladu budou uloženy všechny jeho hodnoty v posledních pěti letech. Díky tomu
může datový sklad daleko lépe sloužit pro rozsáhlé analytické dotazy.
Kromě těchto pojmů se v definici také vyskytuje termín granulární data. Co je to granularita,
vysvětluje Inmon ve své publikaci. „Granularita odkazuje na úroveň detailu nebo souhrnu dat
v datových skladech. Čím více je detailu, tím méně je granularity. Čím méně je detailu, tím více je
granularity.” Jako příklad uvádí, že jednoduchá transakce má malou granularitu, zatímco souhrn
5 INMON,
William Harvey. Building the Data Warehouse. 3rd ed. Wiley Publishing. Canada. 2002. str. 31-43
11
2.1
2
DATOVÉ SKLADY
všech transakcí za měsíc má naopak granularitu velkou.6 Inmon věří, že obsah datového skladu
by měl být granulární (zrnitý) co nejvíce.7
První vlastností datového skladu, ve které se William H. Inmon od Ralpha Kimballa rozchází, je
jeho skladba a následný vývoj. Inmon je zastáncem tzv. top-down8 přístupu, který spočívá ve vytvoření jednotného datového skladu pokrývajícího celý podnik. Jeho filozofii vystihuje následující
lehce nadnesená citace.
„Do not do anything until you have designed everything.” 9
Jinými slovy Inmon doporučuje nejprve vytvořit centralizovaný datový sklad v rámci celého
podniku a až poté začít budovat satelitní databáze, které budou přizpůsobeny potřebám jednotlivých oddělení ve firmě. Tyto databáze nazýváme data marty nebo také „datovými tržišti”.
Odlišné je i pojetí struktury dat. Inmon navrhuje, aby byl centrální datový sklad vytvořen v normalizovaném datovém modelu a z něj odvozené data marty, obsahující data pro specifický business proces, byly vytvořeny za pomoci dimenzionálního přístupu. 10 Normalizovaný datový model
můžeme chápat jako entitně relační schéma, kde se každý údaj vyskytuje pouze jednou.11 Architekturu datového skladu tak, jak ji popisuje William H. Inmon, zobrazuje obrázek 2.
Obrázek 2: Integrovaný datový sklad podle W.H. Inmona
Zdroj: http://www.stanford.edu/dept/itss/docs/oracle/10g/server.101/b10736/concept.htm, Vlastní úprava
6 INMON,
William Harvey. Building the Data Warehouse. 3rd ed. Wiley Publishing. Canada. 2002. str. 43
Nagesh V. Inmon vs. Kimball [online]. 25.8.2005, poslední revize 10.3.2010 [cit. 2010-03-15]. Dostupné
8 Data warehouse - Wikipedia, the free encyklopedia [online]. poslední revize 15.3.2010 [cit. 2010-03-16]. Dostupné z:
<http://en.wikipedia.org/wiki/Data_warehouse>
9 Kimball vs. Inmon...or, How to build a Data Warehouse [online]. 8.8.2006. [cit. 2010-03-19]. Dostupné z:
<http://it.toolbox.com/blogs/confessions/kimball-vs-inmonor-how-to-build-a-data-warehouse-10987>
10 Data warehouse - Wikipedia, the free encyklopedia [online]. poslední revize 15.3.2010 [cit. 2010-03-16]. Dostupné z:
<http://en.wikipedia.org/wiki/Data_warehouse>
11 Blíže se vysvětlení normalizovanému modelu věnuje kapitola 2.3.
7 ANUPINDI,
12
2.2
Charakteristika datového skladu podle Ralpha Kimballa
2
DATOVÉ SKLADY
Výhody i nevýhody přímo vyplývají jak z definice datového skladu, tak i z jeho schématu zachyceném na obrázku. Zřejmě největší výhodou tohoto modelu je možnost relativně jednoduchého
a rychlého vytvoření jednotlivých data martů. S tím je navíc spojen fakt, že data marty zůstávají
velmi konzistentní, což je samozřejmě zapříčiněno tím, že jsou generovány z jednotného datového skladu. Za druhou velkou výhodu lze označit jednodušší načítací proces dat z provozních
systémů. Hlavním důvodem je opět fakt, že data jsou ukládána do stejného centrálního datového
skladu.
Naopak za největší nevýhody lze považovat složitou a mnohdy i velmi nákladnou realizaci tohoto modelu. Samotná implementace je navíc časově náročná, a tak firmy mohou na požadovaný
výsledek čekat velmi dlouho. Vycházíme z Inmonova tvrzení, které je uvedeno výše, že při budování datového skladu nejdříve vytvoříme centrální úložiště a až z něj se odvozují jednotlivé data
marty.
Je nutné dodat, že na tato negativní fakta upozorňuje William H. Inmon ve své knize v kapitole
nazvané „Day 1-Day n Phenomenon”. Zde vysvětluje, že datový sklad není vytvořen najednou,
ale že se do něj data ukládají postupně a tím pádem jsou spíše evoluční než-li revoluční.12 Tím
se snaží popřít tzv. „big bang” přístup, za který ho někteří autoři kritizovali.13 Na druhou stranu se
však lze domnívat, že i přesto se dříve popsané problémy nepodaří úplným způsobem eliminovat.
2.2
Druhou nejdůležitější osobou v této oblasti je bezesporu Ralph Kimball. Jako první definoval koncept data martů a popsal využití dimenzionálního modelování včetně „star” a „snowflake” datových struktur14 . Jestliže William H. Inmon je nazýván „otcem datových skladů”, Ralph Kimball
může být bezesporu nazván „otcem business intelligence”.15
Vzhledem k tomu, že se názory na budování datového skladu obou jeho zakladatelů poměrně
hodně odlišují, věnuje se tato kapitola také přístupu Ralpha Kimballa.
Ten ve své knize definuje datový sklad takto:
„Data Warehouse is a copy of transaction data specifically structured for querying and reporting.” 16
Je vidět, že definice je daleko jednodušší a srozumitelnější než u jeho předchůdce. Přesto se
však domnívám, že vyžaduje důkladnější vysvětlení. To lze nejlépe poskytnout pomocí rozboru
jednotlivých částí datového skladu, které Kimball uvádí ve své publikaci17 .
12 INMON,
William Harvey. Building the Data Warehouse. 3rd ed. Wiley Publishing. Canada. 2002. str. 41
14 V českém jazyce mluvíme o schématech hvězdy a vločky. Oba termíny jsou vysvětleny v následující kapitole.
16 GREENFIELD, Larry. The Data Warehousing Information Center [online]. 1995. poslední revize 14.1.2010 [cit. 201003-19]. Dostupné z: <http://www.dwinfocenter.org/defined.html>
Wiley Publishing. Canada. 2002. str. 7-16
13 ANUPINDI,
13
2.2
2
DATOVÉ SKLADY
Jak ukazuje obrázek 3, datový sklad by měl obsahovat čtyři samostatné a odlišné komponenty:
1. Operational source systems (provozní systémy)
2. Data staging area
3. Data presentation area
4. Data access tools (nástroje pro přístup k datům)
Obrázek 3: Datový sklad podle Ralpha Kimballa
Zdroj: Kimball, The Data Warehouse Toolkit. str. 7. Vlastní úprava
Provozní systémy
Provozní systémy zaznamenávají jednotlivé podnikové transakce. Je důležité si uvědomit, že
v podstatě nejsou součástí datového skladu, nebot’ nad obsahem a formátem dat v nich obsažených máme velmi malou kontrolu. Za hlavní priority provozních systémů můžeme považovat
výkon a dostupnost.
Tyto systémy jsou častokrát tvořeny samostatnými aplikacemi, které nejsou optimalizovány
na sdílení běžných dat mezi sebou, což vývoj datového skladu značně ztěžuje.
Data staging area
Za tuto oblast můžeme označit v podstatě vše mezi provozními systémy a data presentation
area. Jedná se o místo, kde jsou data podrobena tzv. extract-transform-load (ETL) procesům.Ty
umožňují firmám získat data z různých zdrojů, následně je přeformátovat či očistit a nakonec je
načíst do jiného úložiště.
14
2.2
2
DATOVÉ SKLADY
Prvním krokem v tomto procesu je extrakce. Extrahováním je myšleno čtení a porozumění
zdrojových dat a jejich kopírování do data staging area za účelem další manipulace.
Jak již bylo řečeno, extrakce většinou probíhá z několika různých provozních systémů, a tak
jsou získaná data často nesourodá. Proto musí následovat fáze transformace dat. Její součástí je
například očišt’ování dat (oprava pravopisných chyb, převod do standardního formátu), kombinování dat z různých zdrojů, de-duplikování dat a přidělování databázových klíčů.
Posledním krokem ETL procesu je načítání dat do data presentation area. Tato fáze se liší
podle toho, do jakého systému jsou data načítána. Pokud se jedná o provozní databázi či jiný normalizovaný systém, jsou data většinou přepsána, jedná-li se však o datový sklad, jsou neaktuální
data zachována jako historická.
Klíčovým požadavkem na tuto komponentu je, že musí být skryta před koncovým uživatelem
a nesmí být používána k poskytování dotazovacích či prezentačních služeb.
Data presentation area
V data presentation area dochází k organizaci, uchovávání a zpřístupňování dat pro přímé dotazování uživateli či analytickými aplikacemi. Tato oblast je většinou tvořena několika integrovanými
data marty.
Jedním ze základních prvků této oblasti je, že data musí být prezentována, uložena a zpřístupněna v dimenzionálním schématu. Dimenzionální model sice obsahuje stejné informace jako model normalizovaný, ale v takové podobě, aby byly srozumitelné, vhodné pro dotazování a odolné
vůči změnám.18
Dalším důležitým prvkem je, že data marty musí obsahovat atomická data, tedy data s nejnižší úrovní detailu. Atomická data jsou nezbytná kvůli odolnosti datového skladu vůči náporu
nepředvídatelných uživatelských dotazů. Data marty mohou také obsahovat sumarizovaná nebo
agregovaná data za účelem zrychlení výkonu.
Všechna datová tržiště se musí skládat ze společných dimenzí a faktů19 . Toto pravidlo Kimball
nazývá jako conformed, neboli stav, kdy si všechna datová tržiště odpovídají. To je také základem
„data warehouse bus architecture” 20 . Bez sdílených dimenzí a faktů se data mart stává samostatnou aplikací. Tento fakt je nesmírně důležitý, nebot’ reálný systém v praxi se může skládat
i z více než 20 různých data martů, a proto je jejich integrace za pomocí bus architektury nezbytná. Na tomto principu je v podstatě založen celý přístup a pohled Ralpha Kimballa na vývoj
datových skladů.
Nástroje pro přístup k datům
Poslední z hlavních komponent datového skladu jsou nástroje pro přístup k datům. Termín se
vztahuje ke všem schopnostem, které mohou být poskytnuty koncovým uživatelům na analytic18 Co
je to dimenzionální a normalizované schéma bude vysvětleno v následující kapitolách.
jsou vysvětleny v kapitole zabívající se dimenzionálním a normalizovaným přístupem.
20 Ve zbytku práce je používán termín bus architektura datového skladu.
19 Pojmy
15
2.2
2
DATOVÉ SKLADY
kou podporu rozhodování. Toto je samozřejmě hlavní cíl a myšlenka datového skladu. Nástroj
pro přístup k datům může být třeba jednoduchý dotaz stejně tak jako složitá aplikace pro dolování
dat.
Jako součásti datového skladu lze označit i tzv. metadata nebo také „operational data store”
(ODS)21 , které se ovšem nepočítají mezi jeho hlavní komponenty. Za metadata lze považovat
vše z prostředí datových skladů, co nejsou data samotná. ODS představuje zvláštní databázi,
která často integruje data z více zdrojů, a proto se také využívá za účelem provozního reportování. Často se umíst’uje mezi datový sklad a provozní systém. Podle Kimballova přístupu by tedy
mohl být ODS mezi data staging area a data presentation area. Druhým uplatněním je pro sklad
provozních dat oblast CRM (Customer Relationship Management) systémů.
Jak již bylo řečeno, datový sklad podle Ralpha Kimballa je založen na bus architektuře. Tu
ve své knize definuje jako společnou strukturu, do které se vše zapojuje a ze které vše čerpá
energii. Architektura je zároveň nezávislá na technologii a databázové platformě.22
Kimball se však neliší pouze v architektuře datových skladů, ale také v přístupu k jeho budování. Stejně jako u Inmona i zde se nabízí shrnout autorovu teorii do jedné citace.
„Let everybody build what they want when they want it, we will integrate it all when and if we
need to.” 23
Kimball tedy doporučuje začít s vytvářením data martů pro jednotlivé podnikové oddělení,
které se následně spojí za pomocí již zmíněné bus architektury. Proto se také tento přístup nazývá
„bottom-up”.24 Eventuálně může poté dojít ke sloučení datových tržišt’ dohromady a vytvoření
jednoho datového skladu. V praxi mohou být jednotlivé data marty umístěny na jednom či několika
jiných serverech v rámci celého podniku, zatímco datový sklad může být pouze virtuální entitou,
která slučuje všechny data marty dohromady. Proto lze tvrdit, že, co se týče architektury datových
skladů, tento model nabízí velmi dobrý kompromis mezi centralizovaným a decentralizovaným
přístupem.
Největší výhodou oproti Inmonově přístupu je ale bezesporu možnost rychlého inkrementálního vývoje, díky kterému se požadované výsledky dostaví daleko dříve než u implementace
centralizovaného datového skladu. Kromě toho je také vývoj méně nákladný.
Naopak za nevýhodu lze označit větší počet rozhraní mezi produkčními systémy a data marty
stejně tak jako složitější integraci jednotlivých datových tržišt’. Oba dva faktory mají za následek
zvýšení nároků na správu datového skladu. Vzhledem k tomu, že jsou data marty přímo odvozeny
z jednotlivých podnikových oddělení a nevycházejí ze společného datového úložiště, lze se také
domnívat, že bude docházet k určité redundanci dat.
21 Lze
přeložit jako sklad provozních dat.
Ralph; ROSS Margy. The Data Warehouse Toolkit: The Complete Guide to Dimensional Modeling. 2nd ed.
23 Kimball vs. Inmon...or, How to build a Data Warehouse [online]. 8.8.2006. [cit. 2010-03-19]. Dostupné z:
<http://it.toolbox.com/blogs/confessions/kimball-vs-inmonor-how-to-build-a-data-warehouse-10987>
22 KIMBALL,
16
2.3
Normalizovaný a dimenzionální přístup k ukládání dat
2
DATOVÉ SKLADY
V úvodní části práce byl tedy definován datový sklad z pohledu dvou hlavních představitelů
v tomto oboru, Williama H. Inmona a Ralpha Kimballa. Byly uvedeny rozdílné přístupy k výstavbě
datových skladů i k jejich architektuře a zároveň byly odvozeny jejich výhody a nevýhody. Nyní se
tedy nabízí otázka, zda-li je možné považovat jeden přístup za jednoznačně lepší či výhodnější.
Z historického hlediska má jistě navrch filozofie Williama Inmona, nebot’ právě on byl tím, kdo
jako vůbec první termín datový sklad definoval. Není proto divu, že se v 90. letech používal téměř
výhradně tento přístup. V následujících letech se ale začala prosazovat Kimballova teorie. Zvláště
pro malé či střední firmy představovala daleko jednodušší a méně nákladný způsob, jak do svého
podniku datový sklad začlenit.25
Lze usuzovat, že právě díky snazší implementaci a menším nákladům je i v dnešní době
o něco častěji využíván přístup Ralpha Kimballa. Tyto dva faktory jsou navíc ještě umocněny
současnou ekonomickou situací, kdy si žádná organizace nemůže dovolit vkládat velké částky
peněz do dlouhotrvajících a předem nejistých projektů.
Na závěr je však nutné říci, že cílem není vybrat si jeden přístup, podle kterého se pak budoucí
vývoj datového skladu bude řídit. Daleko důležitější je ujasnit si potřeby a požadavky, které podnik
k vytvoření datového skladu vedou a především soustředit se na jeho obsah a kvalitu dat. To, jestli
se výsledné řešení bude více podobat jednomu či druhému přístupu, lze ponechat víceméně
náhodě.
2.3
V předchozích kapitolách byl několikrát zmiňován normalizovaný a dimenzionální přístup, případně schéma či modelování. V této kapitole jsou všechny tyto pojmy vysvětleny a zároveň jsou
určeny výhody a nevýhody obou přístupů s ohledem na jejich využití jako zdroje pro BI.
Normalizovaný přístup
Normalizovaný systém je takový systém, který prošel procesem normalizace a je tak optimalizovaný pro vkládání, upravování a mazání dat. Tyto operace se dají označit jedním slovem jako
transakce.26
Normalizace je proces, při kterém dochází k odstraňování redundantních dat za pomoci normalizačních pravidel27 . Rozlišuje se pět různých úrovní tzv. normálních forem, přičemž za normalizovaný systém lze označit systém, který splňuje třetí normální formu (3NF). Proces normalizace
vede většinou k tomu, že jediná transakce je uložena v několika rozdílných databázových tabulkách.
25 ANUPINDI,
26 Proto se také můžeme setkat s pojmem OLTP (online transaction processing) systémy. V souvislosti s datovými sklady
je však častější termín operační databáze.
27 Normalizační pravidla definoval v roce 1970 Edgar F. Codd, proto se lze také setkat s názvem Coddova pravidla.
V této práci nejsou dále rozebírána.
17
2.3
2
DATOVÉ SKLADY
Obrázek 4: Normalizovaný přístup
Zdroj: Rainardi. Building a Data Warehouse. str. 9. Vlastní úprava
Vzhledem k optimalizaci těchto systémů pro transakční spracování jsou nejčastěji používány
k integraci dat z několika rozdílných zdrojů.28 Proto je v souvislosti s datovými sklady normalizovaný přístup využit v případě ODS nebo u Inmonova centralizovaného řešení.29 Snížení redundance dat má za následek také snížení celkové velikosti normalizovaných systémů.
Naopak největší nevýhodou tohoto přístupu je jeho pomalá odezva při rozsáhlých analytických dotazech. To je způsobeno nevhodnou strukturou a dodržováním normalizačních pravidel.
Databáze pak musí za účelem dosažení výsledku dotazu spojovat velké množství tabulek, což
je samozřejmě daleko méně efektivní než číst data z jedné i když velmi obsáhlé tabulky. Dalším
velkým nedostatkem normalizovaného přístupu je jeho složitost pro běžné uživatele.30
Podobu normalizované databáze zobrazuje obrázek 4.
28 Díky
snížení redundance se data nemusí upravovat na více místech.
Vincent. Building a Data Warehouse: With Examples in SQL Server. Apress. United States of America.
2008. str. 8-9
30 UTLEY, Craig. Designing the Star Schema Database [online]. 1995, Ver. 1.1 poslední revize 17.7.2008 [cit. 2010-0323]. Dostupné z: <http://ciobriefings.com/Publications/WhitePapers/DesigningtheStarSchemaDatabase/tabid/101/Default.aspx>
29 RAINARDI,
18
2.3
2
DATOVÉ SKLADY
Dimenzionální přístup
Dimenzionální přístup nebo modelování je technika, která je určena pro optimalizaci databází
za účelem podpory rozhodování v rámci rozsáhlých dotazů či jiných analytických technologií.31
Dimenzionální schéma musí být složeno z centrální faktové tabulky (či tabulek) a s nimi přidružených dimenzí. Každá faktová tabulka by přitom podle Ralpha Kimballa měla být v normalizovaném
(typicky v třetí normální formě) zatímco dimenze v denormalizovaném stavu.32 Denormalizovaná
databáze je databáze s určitým obsahem redundantních dat, která ještě neprošla procesem normalizace.33
Faktová tabulka
• Faktová tabulka je jádrem dimenzionálního modelu a jsou v ní uložená analyzovaná data
podniku. Jedna řádka ve faktové tabulce vyjadřuje určitou míru či hodnotu. Tyto míry by měly
být vyjádřeny v číselné podobě tak, aby mohly kvantifikovat rozsah analyzované události
jako např. počet objednávek, množství prodaného zboží nebo také dobu hovoru.
• Velký význam má v dimenzionálních modelech granularita. Kimball ve své publikaci uvádí,
že faktové tabulky by měly být navrhovány na nejnižší úrovni detailu, která je možná, tedy
za pomoci atomických dat. Atomické faktové tabulky poskytují možnost jak data v budoucnu
libovolně sumarizovat. Takto upraveným datům se někdy říká agregace. Kimball dále uvádí,
že všechny faktové tabulky by měly být na stejné úrovni granularity, jinak by se mohly stát
velmi nepřehledné.
• Jak již bylo řečeno, klade se u faktových tabulek velký důraz na to, aby hodnoty v nich uvedené byly vyjádřeny číselně. Na tomto základě se rozlišuje několik typů dat. Většina jich je
tzv. aditivní (např. tržby, zisk), což znamená, že se dají navzájem sčítat napříč všemi dimenzemi. Tato vlastnost je velmi důležitá, nebot’ Business Intelligence aplikace jen zřídkakdy
načítají data z jedné faktové tabulky. Většinou se jedná o stovky až tisíce záznamů napříč
celým systémem. Další hodnoty mohou být tzv. semi-aditivní a neaditivní. Semi-aditivní mohou být přidávány pouze k určitým dimenzím (např. podíl na trhu) zatímco neaditivní hodnoty
nemohou být přičteny nikam (jednotková cena).34
• Co se týče počtu sloupců jsou faktové tabulky velmi malé, avšak obsahují většinou velké
množství řádek. Díky tomu mohou zabírat až 90% celkové velikosti dimenzionálních databází.
31 FIRESTONE,
Joseph M. Dimensional Modeling and E-R Modeling In The Data Warehouse [online]. 22.6.1998, [cit.
2010-03-24]. Dostupné z: <http://www.dkms.com/papers/dmerdw.pdf>
32 MUNDY, John; THORNWAITE, Warren; KIMBALL, Ralph et al. The Microsoft Data Warehouse Toolkit: With SQL
Server 2005 and the Microsoft Business Intelligence Toolset. Wiley Publishing. Canada. 2006. str. 41
33 RAINARDI, Vincent. Building a Data Warehouse: With Examples in SQL Server. Apress. United States of America.
2008. str. 30
Server 2005 and the Microsoft Business Intelligence Toolset. Wiley Publishing. Canada. 2006. str. 41-43
19
2.3
2
DATOVÉ SKLADY
Dimenze
• Dimenzionální tabulky jsou nedílným společníkem faktových tabulek. Na rozdíl od nich obsahují dimenze textové popisy podniku.35 Dimenze si lze představit jako podstatná jména
datového skladu, zatímco faktové tabulky představují slovesa nebo podnikové procesy, kterých se dimenze účastní. Každá dimenze musí být propojena se všemi podnikovými procesy,
se kterými souvisí.
• Atributy dimenzí slouží jako hlavní zdroj dotazů či reportů a mají tak v datovém skladu
nepostradatelnou roli. Jsou klíčovým prvkem pro vytvoření srozumitelného datového skladu.
Robustní dimenzionální atributy zároveň poskytují také možnost rozsáhlého analytického
dotazování.
• V dobře navrhnutém dimenzionálním modelu mají jednotlivé tabulky velký počet atributů,
výjimkou nejsou ani tabulky obsahující 100 sloupců. I přesto jsou ale poměrně malé a nezabírají více než 10% celkové velikosti datového skladu.36
Jak se Ralph Kimball ve své publikaci domnívá, dimenzionální modelování je nejlepší technikou,
pomocí které lze prezentovat informace uživatelům. Dimenzionální přístup umožňuje splňovat
základní cíle datového skladu a tím i BI:
• prezentovat uživatelům potřebné informace tím nejjednodušším způsobem
• reagovat na uživatelské dotazy co nejrychleji
• poskytovat relevantní informace, které vystihují základní podnikové procesy
První bod lze vysvětlit tak, že dimenzionální model obsahuje daleko méně databázových tabulek
než model normalizovaný. Informace jsou navíc spojeny do souvisejících podnikových kategorií,
což má za následek to, že systém je mnohem jednodušší a uživatelé se v něm lépe orientují.37
Jednoduchost dimenzionálního modelu přináší také výkonnostní benefity. Databáze mohou
tato schémata procházet daleko efektivněji díky nižší potřebě spojovat jednotlivé tabulky. Uživatelské dotazy tak v porovnání s normalizovaným přístupem trvají daleko kratší dobu.38
I přesto, že termín Business Intelligence a jeho jednotlivé nástroje ještě nebyly definovány, lze
se domnívat, že více výhod mu bude poskytovat spojení s datovým skladem a to právě díky jeho
dimenzionální struktuře. Jedině ta, jak již bylo zmíněno, umožňuje vytváření rozsáhlých analytických dotazů, na jejichž funkci je princip BI založen.
Server 2005 and the Microsoft Business Intelligence Toolset. Wiley Publishing. Canada. 2006. str. 40-41
20
2.3
2
DATOVÉ SKLADY
Hvězdicové schéma
Dimenzionální datový sklad může být výsledně implementován pomocí dvou různých schémat.39
Tím prvním je schéma hvězdy. Podle Ralpha Kimballa se jedná o model, který se skládá z centrální faktové tabulky (nebo tabulek) a k ní připojených dimenzí.
Všechny faktové tabulky se skládají z několika cizích klíčů, které se připojují k primárním
klíčům dimenzí. Velký důraz se klade na to, aby každý cizí klíč uvedený ve faktové tabulce měl
svůj unikátní primární klíč v příslušné dimenzi. Tento návrh umožňuje, aby se v dimenzionálních
tabulkách vyskytovaly primární klíče, které nejsou uvedeny ve faktové tabulce. V reálné situaci to
může znamenat například to, že dimenze produktu může být spojena s faktovou tabulkou prodeje,
ve které se však ještě nějaké produkty vůbec neprodaly, což je ale naprosto v souladu s principem
zachování integrity a pravidel dimenzionálního modelování.40
Vzhled hvězdicového schématu demonstruje obrázek 5.
Obrázek 5: Hvězdicové schéma
Zdroj: http://en.wikipedia.org/wiki/File:Star-schema-example.png. Vlastní úprava
Vločkové schéma
Schéma vločky vychází z hvězdicového schématu ovšem s tím rozdílem, že u tohoto modelu
mohou mít jednotlivé dimenze další poddimenze. Díky tomu pracují některé analytické aplikace
s tímto modelem lépe než s hvězdicovým schématem. Jako výhody jsou v tomto případě uváděny
menší míra redundance dat a tím pádem i menší celková velikost.41
Ralph Kimball má však na vločkové schéma jiný pohled. Ve své knize tvrdí, že vločkové
39 Možností
je více, v této práci ale pracuji pouze se dvěma nejdůležitějšími.
Ralph. Fact Tables and Dimension Tables - Intelligent enterprise [online]. 1.1.2003, [cit. 2010-03-25]. Dostupné z: <http://intelligent-enterprise.informationweek.com/030101/602warehouse1_1.jhtml>
2008. str. 7
40 KIMBALL,
21
2.3
2
DATOVÉ SKLADY
schéma vede k větší komplexitě celého modelu a tím se také zmenšuje schopnost jeho využití.
Ve své knize doslova uvádí:
„Snowflaking involves re-normalizing the dimensions to the third normal form level, usually
under the misguided belief that this will improve maintability, increase flexibility, or save space.
We discourage snowflaking.”42
Ve své další publikaci navíc argumentuje tím, že vzhledem k tomu, že dimenze z pohledu
celkové velikosti dimenzionální databáze zabírají pouze malý zlomek, je v podstatě zbytečné přecházet na normalizované schéma.43
Na obrázku 6 jsou zobrazeny stejné faktové tabulky a dimenze jako v obrázku předchozím,
nyní ovšem ve vločkovém schématu.
Obrázek 6: Vločkové schéma
Zdroj: http://en.wikipedia.org/wiki/File:Snowflake-schema-example.png. Vlastní úprava
Server 2005 and the Microsoft Business Intelligence Toolset. Wiley Publishing. Canada. 2006. str. 58
22
3
3
BUSINESS INTELLIGENCE
Business Intelligence
V předchozí kapitole byl představen datový sklad jako dimenzionální databáze. Ovšem účel datového skladu nespočívá v ukládání dat, nýbrž v jejich získávání a prezentování, a to takovým
způsobem, aby byla srozumitelná a přinášela uživatelům nějakou přidanou hodnotu. Toho lze dosáhnout v případě spojení datového skladu s Business Intelligence. Proto se tato kapitola zabývá
způsoby prezentace dat, kterých jsou BI nástroje díky datovým skladům schopné. Zároveň zde
bude kladen velký důraz na zobrazení výhod, které z tohoto spojení pro BI plynou. V závěru této
kapitoly budou nastíněny současné trendy ve vývoji obou zmiňovaných systémů.
Ještě než budou vysvětleny jednotlivé typy BI, je nutné definovat samotný pojem. Data Warehousing Institute, poskytovatel vzdělávacích a instruktážních programů v oblasti datových skladů
a BI, definuje Business Intelligence takto:
„The processes, technologies, and tools needed to turn data into information, information into
knowledge, and knowledge into plans that drive profitable business action.”
Zároveň uvádí, že BI zahrnuje datové sklady, analytické nástroje a znalostní management.
Tato definice je velmi výstižná, nebot’ zachycuje hierarchii jednotlivých úrovní podnikové inteligence. Zároveň také poukazuje na dva kriticky důležité faktory:
• BI představuje víc než jen soubor nástrojů. Bez příslušných procesů a uživatelů ztrácí BI
svoji hodnotu.
• Hodnota BI je vždy realizována v kontextu s výnosnou podnikovou činností. Tím je myšleno,
že pokud je znalost, která může být využita k výnosné činnosti, ignorována, ztrácí BI svůj
význam.
V souvislosti s těmito definicemi však dochází k zaměňování pojmů data, informace a znalosti.
Proto jsou zde tyto pojmy vysvětleny:
• Data jsou kolekcí prvotních, nezpracovaných hodnot, které jsou používány pro výpočet měření či různých úvah. Data mohou být shromažd’ována, uchovávána či zpracována, ovšem
nemohou z nich být interpretovány žádné souvislosti.
• Informace jsou výsledkem shromažd’ování a organizování dat tak, aby byly mezi jednotlivými daty navázány vztahy a z nich šlo následně vyvodit určitý smysl či význam.
• Znalost je proces porozumění informací založený na urřitých vzorech takovým způsobem,
aby došlo k pochopení jejich podstaty.44
Tato definice se poměrně striktně zaměřuje na podstatu BI a kromě zmínky o datových skladech
vůbec nevyjadřuje, jakým způsobem spolu tato dvě témata souvisí. Vzhledem k pojetí a cíli této
práce je tak princip BI daleko lépe vysvětlen v publikaci Joye Mundyho.
44 LOSHIN, David. Business Intelligence - The Savvy manager’s guide. Getting Onboard with Emerging IT. Morgan
Kaufmann Publishers. United States of America. 2003. str. 6-7
23
3.1
Reporty
3
V tom nejširším pojetí znamená Business Intelligence využívání informací za účelem vytváření lepších rozhodnutí. Mnoho definic tak jako synonymum k BI uvádí termín decision support
system (DSS) neboli systém na podporu rozhodování. Význam tohoto pojmu původně odkazoval
na strukturovanou vrstvu pro přístup k datům nacházející se mezi uživateli a datovým skladem.
Z toho plyne, že BI bylo popisováno jako samostatné odvětví přímo nesouvisející s datovým skladem.
Přestože je teoreticky možné využívat BI aplikace bez datových skladů, ve skutečnosti se to
stává jen zřídkakdy. Dobře navržený datový sklad totiž díky dimenzionálnímu modelu a ETL procesu přidává datům takovou hodnotu, že je naprosto zbytečné vynakládat tuto snahu za účelem
vytvoření pouze samostatné BI aplikace. Většina z těchto aplikací jsou navíc nedílnou součástí
datového skladu.45
Business Intelligence a datové sklady jsou tedy dva rozdílné pojmy, ovšem jeden bez druhého
v podstatě ztrácí smysl. Stejně tak jako jsou datové sklady od začátku do konce budovány s tím,
že budou sloužit jako zdroj dat pro BI, by i BI nástroje měly být do firmy zaváděny pouze za předpokladu, že dojde k vybudování datového skladu. BI aplikace představují přímé využití pro datové
sklady, nebot’ s provozními databázemi by nikdy podniku nepřinesly takovou přidanou hodnotu.
Přínosy datového skladu pro jednotlivé části BI jsou uvedeny v následujících kapitolách.
Business Intelligence nástroje lze rozdělit do dvou základních kategorií. Těmi jsou reporty a
analytické aplikace, do kterých dále spadá analýza, data mining, text mining, přehledové zobrazení atd. V této práci se však z hlediska jejího zaměření věnuji především reportům, analýze a
data miningu, v části věnující se současnému vývoji bude pak zmíněna technologie text mining.46
3.1
Reporty
V tomto kontextu je report program, který získává data z datového skladu a prezentuje je uživatelům na obrazovce či na papíru. Uživatelé také mohou tyto reporty přijímat automaticky třeba
pomocí e-mailu po určité době (den, týden atd.) nebo v závislosti na nějakou událost. Reporty se
nejčastěji získávají z datových skladů, mohou však pracovat i s normalizovanou relační databází
či dokonce s multidimenzionální databází.47
Reporty jsou těmi nejzákladnějšími nástroji Business Intelligence spektra. Jedná se o většinou
relativně jednoduché výkazy, které se dají parametrizovat, a které mají již předem definovaný formát. Lze se ale setkat i s automatickými, statickými reporty. Všechny reporty mají však společné
to, že poskytují uživatelům základní soubor informací o tom, co se děje v dané oblasti podniku.
I přes svůj jednoduchý princip jsou právě reporty tím nejznámějším a nejvíce využívaným BI nástrojem v dnešním světě a pro velkou skupinu uživatelů představují v praxi každodenní rutinu.48
45 MUNDY, Joy; THORNWAITE, Warren; KIMBALL, Ralph et al. The Microsoft Data Warehouse Toolkit: With SQL Server
2005 and the Microsoft Business Intelligence Toolset. Wiley Publishing. Canada. 2006. str. 355
46 Pro zbylé nástroje BI nepředstavuje datový sklad nutný zdroj dat.
2008. str. 329-330
24
3.1
Reporty
3
Pokud pomineme existenci administrativních reportů a budeme brát v úvahu pouze ty uživatelské, lze reporty rozdělit následovně:
• Standardní reporty - tyto reporty jsou určeny k tlumočení stavu podniku a jsou většinou
velmi jednoduché, příkladem může být výkaz rozpočtu vůči reálným tržbám či výkaz nákladů. Do této skupiny lze však zařadit také reporty, které získávají data pouze z jedné
tabulky, většinou za účelem kontroly určitého obchodu, zákazníka, produktu atd.
• Strukturované reporty - na rozdíl od předchozího typu, tyto reporty běžně prezentují informace napříč podnikem a spojují tak typicky všechny dimenze s faktovou tabulkou. Zároveň
mohou být parametrizovány, aby umožnily uživatelům modifikovat jejich vzhled dle potřeby.
Typickým příkladem může být přehled týdenních tržeb v daném regionu a v určitém období.
• Ad hoc reporty - tyto reporty umožňují uživatelům formulovat vlastní dotazy přímo do databáze. Některé systémy poskytují pomocné nástroje na vytváření těchto dotazů, tak, aby
je byli schopni vytvářet i uživatelé, kteří nemají dostatečné znalosti se syntaxí dotazovacího
jazyka.
• Tzv. exception-based reporty - tyto reporty jsou generovány na základě určité události,
která se stala v podniku, a mají tak za úkol spíše upozornit uživatele než jim poskytovat
různé výkazy.49
Nyní již lze poměrně snadno určit největší výhodu reportů. Tou je bezesporu jejich jednoduchost.
Reporty je jednoduché vytvořit, spravovat i používat. Další výhodou je také to, že reporty lze prezentovat v libovolném tabulkovém formátu, například ve formátu Excel, což, vzhledem k popularitě
Microsoft Office aplikací, poměrně velkým způsobem přispívá jejich uživatelské přívětivosti.
Největší nevýhodou reportů je naopak jejich nízká flexibilita. Obecně lze říci, že reporty jsou
před ostatními nástroji BI upřednostňovány ve chvíli, kdy jsou požadavky na formu prezentace
jednoduché a spíše statického rázu. Ve chvíli, kdy chce uživatel pozměnit data nebo je vidět
na jiné úrovni detailu, je nutné celý report předělat a znovu vygenerovat. U ostatních analytických
nástrojů tato potřeba mizí a je tak dosaženo daleko větší flexibility.50
V úvodu kapitoly bylo řečeno, že reporty dokáží pracovat jak s datovými sklady, tak i s jinými druhy databází. Na závěr je však nutné říci, že v podstatě všechny výhody reportů výše
uvedené (především jejich jednoduchost) jsou přímo závislé na datovém skladu. Jedině dimenzionální struktura je schopna zaručit, že reporty budou za každé situace stále srozumitelné a
snadné na vytváření. V případě standardních reportů je tak zaručeno, že se při výpisu dimenze
zákazníka opravdu zobrazí veškeré požadované atributy bez nutnosti spojování dalších tabulek.
Naopak u strukturovaných reportů je díky hvězdicové struktuře datového skladu zaručeno, že
2005 and the Microsoft Business Intelligence Toolset. Wiley Publishing. Canada. 2006. str. 356
Kaufmann Publishers. United States of America. 2003. str. 54
2008. str. 357, 412
25
3.2
Analýza (OLAP)
3
i přes spojení relativně velkého množství tabulek bude tento proces stále srozumitelný a přehledný. Lze tedy tvrdit, že pouze ve spojení s datovými sklady jsou reporty schopné dodržet svůj
charakter jednoduchých a často využívaných nástrojů.
3.2
Analýza (OLAP)
Vincent Rainardi definuje OLAP analýzu následovně:
„Online analytical processing is the activity of interactively analyzing business transaction data
stored in the dimensional data warehouse to make tactical and strategic business decisions.”
Uživatelé, kteří pracují s analytickými nástroji, mohou být například business analytici či manažeři ale také vedení firmy. Typickým případem, kdy se analýza používá, může být pak analyzování
dopadu zdražení produktu na tržby v jednotlivých zemích či městech v určitém časovém období.
Aby se opravdu jednalo o OLAP analýzu, musí proces získávání dat probíhat vždy z dimenzionálního datového skladu, at’ už je založen na relačním či multidimenzionálním formátu. Právě
na základě tohoto faktoru lze OLAP rozdělit na:
• MOLAP - Multidimensional online analytical processing, jako zdrojový systém se používá
multidimenzionální databáze
• ROLAP - Relational online analytical processing, jako zdrojový systém se používá relační
datový sklad
• HOLAP - Hybrid online analytical processing, jako zdrojový systém se používá jak relační
tak multidimenzionální databáze51
MOLAP
MOLAP lze popsat jako analytický nástroj, který získává data ze speciální struktury zvané multidimenzionální databáze (MDD). V první části této kapitoly je proto vysvětleno, jak tato databáze
vypadá a jakým způsobem funguje. Zbytek kapitoly se již věnuje možnosti MDD a jejím výhodám
či nevýhodám.
Multidimenzionální databáze se skládá z číselných hodnot, které jsou kategorizovány podle dimenzí. Vzhledem k tomu, že se MDD typicky získává z hvězdicového schématu datového skladu,
je poměrně jednoduché si představit, jak tento proces probíhá. Dimenze jsou odvozeny z dimenzionálních tabulek a jednotlivé hodnoty pak z faktové tabulky.52
Nejlépe však lze MDD ilustrovat jako kostku, jejíž hrany tvoří dimenze. Zmiňované hodnoty
jsou pak obsaženy v tzv. buňkách, přičemž jednotlivé dimenze slouží jako osy pro určení jejich
polohy. Tyto hodnoty mohou být jak agregované, tak atomického charakteru. Důležité však je,
2008. str. 380-381
52 Online analytical processing - Wikipedia, the free encyklopedia [online]. poslední revize 14.4.2010 [cit. 2010-04-18].
Dostupné z: <http://en.wikipedia.org/wiki/Olap>
26
3.2
Analýza (OLAP)
9314ch12final.qxd
11/15/07
10:01 AM
3
Page 379
aby byly aditivní53 . Každá buňka představuje jednu podnikovou událost a hodnoty dimenzí pak
vyjadřují kde a kdy se stala.
CHAPTER 12 ■ MULTIDIMENSIONAL DATABASE
Obrázek 7: Multidimenzionální databáze
Zdroj:ofRainardi.
Building a Data
Warehouse.
str. 379
Figure 12-2. Visualization
a multidimensional
database
with three
dimensions
the other
hand,jethe
drawback
of using ačíslo
multidimensional
database
Příklad On
takovéto
kostky
uveden
na obrázku
7. Hrany kostky
tvořícompared
dimenze to
produktu,
using a relational database is the processing time required for loading the database and calcu-
zákazníka
a the
času,
přičemž
jejichWhenever
kombinace
nasource
jednotlivé
buňky,the
které
lating
aggregate
values.
theukazuje
relational
is updated,
MDBobsahují
needs tohodnoty
be
updated
reprocessed; in other words, the aggregate cells need to be recalculated (it doesn’t
tržeb, náklad
ů aorzisku.
have to be done in real time). The second drawback is the scalability: an MDB may not scale
Hlavní
využití
databázeoroproti
databázím
jsou menší spowellvýhody
for a very
large multidimenzionální
database (multiple terabytes)
a largerelačním
number of
dimensions.
třeba místa na disku a lepší výkon. Příčinou toho, proč MDD zabírá v porovnání s relačním dimenzionální modelem méně místa je hlavně to, že je komprimovaná a nepoužívá indexování.
■Note The term multidimensional database is often confused with the term online analytical processing,
Větší výkon
je terms
zasehave
způsoben
tím, že MDD
předkalkulované
agregované
hodnoty a
and OLAP is the activity
used to analyze
but these
different meanings.
An MDBobsahuje
is the database,
An OLAP
cube
has the same meaning
the database.
The uložení
confusionna
is caused
word OLAP cube.
díky svému
způsobu
disku by
sethe
minimalizuje
počet
vstupn
ě výstupních
operací.as an
MDB; it means a multidimensional database. We’ll talk about OLAP in the next section.
Na druhou stranu velkou nevýhodou MDD oproti relační databázi je doba, jakou trvá výpočet
agregovaných hodnot a její uvedení do produkce. Nehledě na to, že pokud dojde k úpravě zdrodatabase
world know
that annedostatkem
RDBMS is theje
system
that manages
a není
jových dat, Most
MDDpeople
musí in
býtthe
také
aktualizována.
Dalším
škálovatelnost.
MDD
relational database. What do we use to manage multidimensional databases? The system that
manages and operates multidimensional databases is called a multidimensional database system
database
systems
are
also known
as OLAPoperace
servers oracube
Poté,
co(MDBMS).
byla vysvMultidimensional
ětlena struktura MDD,
je již
možné
definovat
konkrétní
možnosti,
engines. Examples of an MDBMS are Microsoft SQL Server Analysis Services, Hyperion Esskteré přináší uživatelům. Mezi základní operace patří:
base, and Cognos PowerCube. Business Objects and MicroStrategy don’t have an MDBMS;
they use ROLAP (I’ll talk about ROLAP in the next section).
• Slicing
slicing neboli
„krájení”
představuje
proces
získávání
dat z(http://www.
datové kostky ovšem
The- standard
interface
to connect
to an MDBMS
is XML
for Analysis
xmlforanalysis.com/),
which is z
known
XMLA. For
using SQL Server
Reporting
na
základě konkrétní hodnoty
jednéasdimenze.
Taexample,
je pak zobrazena
v kontextu
se zbylými
Services, we can connect not only to Analysis Services cubes but also to Hyperion Essbase
nefiltrovanými
dimenzemi
a hodnotami.
Tento
případ
ilustrujeSAP,
obrázek
8 na
kostceXMLA.
uvedené
cubes using XMLA.
Microsoft,
Hyperion (now
owned
by Oracle),
and SAS
support
is a .NET data provider that uses XMLA to communicate the analytical data
v ADOMD.NET
předchozí části.
sources.
příliš vhodná pro velké databáze nebo pro databáze s velkým počtem dimenzí.
• Dicing - dicing neboli „sekání” datové struktury je proces získávání dat na základě filtrování více dimenzí. Tak je umožněno vymezit požadovaný prostor, který se bude následně
53 Právě aditivita zaručuje to, že lze jednotlivé hodnoty sčítat. Je však nutné dodat, že ve chvíli, kdy se OLAP kostka
vytváří z datového skladu, který je navržen podle hvězdicového schématu a má tedy faktovou tabulku obsahující číselné
hodnoty, je tato aditivita v podstatě automaticky zaručena.
27
379
3.2
Analýza (OLAP)
3
analyzovat. Příklad je zobrazen v levé části obrázku 8. Je vidět, že došlo k filtrování pouze
určitých zákazníků, produktů a v určitém období.
Obrázek 8: Slicing a dicing MDD
Zdroj: Rainardi. Building a Data Warehouse. str. 413. Vlastní úprava
• Drilling up - pro pochopení tohoto pojmu je nutné uvést, jakým způsobem jsou data v dimenzích MDD uložena. Pro definování této struktury se zavádí pojem hierarchie. „Hierarchy is a systematic way of organizing each of the elements of a dimension-or so called
’Members’- into a logical tree strucutre which defines parent-child aggregation points, where
parent members correspond to the consolidation of children members.” 54 Definice zní poněkud složitě, ovšem na konkrétním příkladě si lze hierarchii velice jednoduše představit.
Obrázek 9 znázorňuje produktovou hierarchii, kdy se strom postupně člení na kategorie,
typy a jednotlivé produkty. Důležité je podotknout, že mezi jednotlivými členy na odlišných
úrovních musí být vždy vztah 1:M.
Nyní, když je vysvětlena definice hierarchií je již velmi snadné definovat pojem drilling up.
Jedná se o prezentování dat na vyšší úrovni dané hierarchie. Nebo také přecházení z nižší
úrovně na vyšší.
• Drilling down - drilling down je přesný opak předchozího případu. Jedná se tedy o prezentaci dat na nižších úrovních hierarchií.55
MOLAP je bezpochyby nejvyužívanějším typem analýz právě pro svoji specializovanou strukturu,
která umožňuje naprosto přirozený pohled na dané podnikové odvětví nebo činnost. Zároveň se
také podílí na stále vzrůstající oblibě analytických nástrojů. V dnešní době se analytické řízení
stává stále běžnější věcí a uvědomují si to i velké firmy, které nástroje poskytují. Jako opravdu
zajímavý lze například označit krok společnosti Microsoft, která již od verze Office 2007 podporuje
54 Hierarchy - OLAP.com, Your Source to Learn about OLAP [online]. poslední revize 9.3.2009 [cit. 2010-04-19]. Dostupné z: <http://www.olap.com/w/index.php/Hierarchy>
2008. str. 377-379, 414
28
3.2
Analýza (OLAP)
3
analytické dotazování ve svém kancelářském programu Excel. Takto se dostává velice mocný
nástroj ovšem v již známém prostředí do rukou velkého počtu lidí.
Obrázek 9: Produktová hierarchie
Přestože MOLAP analýza získává data z multidimenzionální databáze, jsou i zde výhody
spojení s datovým skladem zcela patrné. Díky tomu, že jsou datové sklady navrženy pomocí
hvězdicového schématu, které téměř odpovídá struktuře MDD, stává se vytvoření datové kostky
snadnou záležitostí.
ROLAP
Jak bylo uvedeno dříve, ROLAP je druh analýzy, která získává data z relačního databázového
skladu. ROLAP ponechává data v původních tabulkách a spoléhá se na SQL příkazy, kterými
požadovaná data vyhledává. Nejdůležitějším mechanismem je zde však využívání agregací. Ty
jsou tvořeny z faktové tabulky, přičemž jejich výsledný počet je dán všemi možnými kombinacemi
granularit jednotlivých dimenzí. Problémem ovšem je, že tento počet je opravdu velký a v podstatě
nelze zaručit, aby byly tímto způsobem předpřipraveny veškeré výpočty. Díky tomu se musí zbylé
hodnoty sčítat až pomocí sum a group klauzulí v SQL příkazech, což má za následek zpomalení
celého procesu. Další výhody a nevýhody tohoto přístupu byly uvedeny již v předchozí kapitole.
HOLAP
Je známo, že HOLAP analýza je schopna získávat data jak z multidimenzionálních, tak z relačních
databází, ovšem přesná definice tohoto pojmu zatím nebyla stanovena. Jako příklad fungujícího
HOLAP přístupu si lze představit stav, kdy je velké množství detailních dat uloženo v relační
databázi a z nich je pouze část obsažena v MDD v podobě agregovaných hodnot. Díky tomu
HOLAP analýza spojuje výhody obou předchozích přístupů, ovšem nástrojů, které tuto funkčnost
umožňují, je zatím poměrně málo.56
56 Online analytical processing - Wikipedia, the free encyklopedia [online]. poslední revize 14.4.2010 [cit. 2010-04-19].
Dostupné z: <http://en.wikipedia.org/wiki/Olap>
29
3.3
Data Mining
3
Na závěr této kapitoly je nutné uvést srovnání OLAP analýzy vůči reportům i proto, že je
hranice mezi těmito nástroji často nejasná. Největší výhodou analytických aplikací je zajisté jejich
flexibilita a interaktivita. Pokud uživatelé dopředu nevědí, co přesně budou analyzovat, je obecně
lepší využít analytických než reportovacích nástrojů. Naopak za největší nevýhodu lze označit
poměrně velkou složitost. Uživatel již na rozdíl od reportů musí rozumět dané struktuře (většinou
datové kostky) a musí ji umět správně použít. OLAP nástroje jsou také náročnější na údržbu
nebot’ se musí pravidelně aktualizovat.57
3.3
Data Mining
Jestliže předchozí dvě kategorie Business Intelligence nástrojů byly alespoň co se týče výstupů
relativně podobné, data mining je kapitolou sám pro sebe. Je také nutné říci, že se jedná o kapitolu
velmi rozsáhlou, v dnešním světě tvořící v podstatě samostatné odvětví. Nárůst popularity data
miningu jde ruku v ruce s tím, jak se konkurenční boj stává stále těžším a těžším. Výsledkem je,
že firmy se nebojí vkládat do této oblasti více finančních prostředků, a tak se toto odvětví poslední
dobou velmi rozrůstá. Na rozvoj data miningu má dále velký vliv stále se zdokonalující a přitom
dostupnější výpočetní technika a samozřejmě také současná ekonomická situace.
V souvislosti s rozsahem tohoto tématu považuji za nutné zmínit, že tato práce si nebere
za úkol popsat kompletní disciplínu do detailů, nýbrž poukázat na spojení s datovými sklady,
vysvětlit hlavní metody data miningu a také uvést příklady jeho využití. Konkrétní aplikace těchto
metod a příkladů bude zpracována v praktické části.
Co je a co není data mining?
Autoři knihy Data Mining Techniques definují data mining následovně:
„Data mining, as we use the term, is the exploration and analysis of large quantities of data in
order to discover meaningful patterns and rules.” 58
Na první pohled však tento termín spíše evokuje myšlenku starodávného zlatokopa, který se
musel probírat obrovským množstvím bahna, aby našel oněch pár vysněných kousků zlata a tím
tak celý proces nabyl smyslu. Pokud by se tato myšlenka přeložila, aby odpovídala informačnímu
světu, jednalo by se o analytika probírající se terabyty dat a hledající nějakou hodnotnou informaci. Ovšem tato myšlenka již v dnešním světě v podstatě neexistuje, dnes je za „data minera”
označován každý, kdo provádí jakékoliv databázové dotazy.
Dle definice je ovšem jasné, že by to tak nemělo být. Proto lze v kontextu s data miningem
zavést ještě jeden pojem, který lépe vyjadřuje podstatu věci. Jedná se o pojem knowledge discovery. Tento termín odkazuje na proces objevování vzorů, které vedou k získání znalostí z velkého
2008. str. 416
58 BERRY, Michael J.A.; LINOFF, Gordon S. Data Mining Techniques: For Marketing, Sales, and Customer Relationship
Management. 2nd ed. Wiley Publishing. Indianopolis (Indiana). 2004. str. 7
30
3.3
Data Mining
3
množství dat pomocí jedné z data miningových metod.59
Data mining se dá rozlišit podle dvou různých přístupů. Tím prvním je případ, kdy je znám
problém, který je třeba řešit a metody data miningu jsou tak využívány za účelem odhalení souvislostí mezi konkrétními podnikovými daty. Tento přístup je nazván directed data mining. Opačný
přístup, undirected data mining, vyjadřuje proces využívání metod k nalezení jakýchkoliv zajímavých souvislostí, které by vedly k dalšímu využití.60
Nyní, když jsou známy oba přístupy, lze se zamyslet nad srovnáním data miningu s ostatními BI nástroji, především pak s OLAP analýzou. Lze říci, že všechny dříve uvedené nástroje
jsou schopny analyzovat obrovské množství dat. Tak kde je v tom případě rozdíl? Ten největší je
právě v tom, že u předchozích analytických nástrojů se vždy zkoumá nějaký již známý fakt, at’
už na základě hypotéz či odhadů business analytiků. U data miningu však lze kromě toho hledat také nové, dosud nepoznané vztahy a myšlenky. Tato možnost odpovídá výše definovanému
undirected přístupu.61
Data mining a datový sklad
Data mining je proces, který vyžaduje přístup k velkému množství dat a tato data se musí nacházet ve spolehlivém stavu. Problémem u velkých firem je, že shromažd’ují terabyty dat, většinou
ale za účelem jednorázového využití v provozním systému. Jakmile tato data naplní svůj účel
(účetnictví atd.), jsou automaticky zálohována na pásku a z podniku tak nadobro mizí dřív, než se
z nich stačí vytěžit nějaké informace.62
A proto se jako zdroj pro data mining využívá v naprosté většině případů datový sklad, který
je díky svým vlastnostem schopen zaručit veškeré požadavky, které pro svoji funkci data mining
potřebuje. Datový sklad nejenom že většinou umožňuje získat požadovaný rozsah dat, ale obsahuje také potřebná historická data. Vzhledem k tomu, že velký počet data miningových metod
vyžaduje jeden soubor dat pro své výpočty, které jsou následně otestovány na jiném souboru, je
přítomnost historických dat a obecně tedy datového skladu téměř nezbytná.63
Využití a metody data miningu
Na úvod této části je nutné uvést, že terminologie v oblasti datových skladů není ještě úplně
standardizována. Ve většině zdrojů se nejprve definují možné způsoby využití data miningu64
a zvlášt’ potom matematické operace, pomocí kterých se daný business proces analyzuje. Tyto
operace mají ovšem v mnoha případech stejný název, a tak dochází k záměně pojmů. Aby se tomu
59 V
této práci jsou oba pojmy používány ve stejném významu.
David. Business Intelligence - The Savvy manager’s guide. Getting Onboard with Emerging IT. Morgan
Kaufmann Publishers. United States of America. 2003. str. 205, 208
61 MOSS, Larissa T.; ATRE, Shaku. Business Intelligence Roadmap:The Complete Project Lifecycle for Decision-Support
Applications. Pearson Education. Canada. 2003. s. 306
Management. 2nd ed. Wiley Publishing. Indianopolis (Indiana). 2004. str. 4-5
64 Možnými způsoby využití jsou myšleny jednotlivé metody data miningu.
60 LOSHIN,
31
3.3
Data Mining
3
předešlo i v této práci, jsou zde data miningové metody a operace uváděny společně, ovšem s tím,
že hlavní důraz je kladen na znázornění jednotlivých metod, spíše než matematických operací.
Data mining lze využít v následujících případech:
• Classification - metoda klasifikace se skládá ze zkoumání vlastností nově přítomného objektu a jejich přiřazování jedné z předem definovaných tříd. Objekty, které se klasifikují, jsou
většinou reprezentovány jednotlivými řádky v databázové tabulce. Proces klasifikace potom
do této tabulky přidá nový sloupec s názvem třídy a jejími hodnotami.65
Příkladem z praxe může být proces, kdy se banky rozhodují, zda danému zákazníkovi poskytnou úvěr či nikoliv. Nejprve je nutné stanovit určitá pravidla, podle kterých bude klasifikace probíhat. V tomto případě se bude nejspíše jednat o zůstatek na zákazníkově kontě či
jeho roční příjem. Banka si poté zkontroluje tyto atributy a na jejich základu rozhodne o výsledku. Tím bude bud’ ano, poskytne zákazníkovi úvěr či ne, neposkytne (v jiných případech
mohou být samozřejmě výsledky daleko složitější). Proces znázorňuje obrázek 1066 .
Metody, které tyto procesy počítají se nazývají Decision trees (Rozhodovací stromy), Neural
network (Neuronové sítě) či Naïve Bayes.67
Chapter 13: Panning for Gold—Introduc tion to Data M ining
475
Obrázek 10: Klasifikace
Zdroj:
Delivering Business Intelligence with Microsoft SQL Server 2008. str. 475
FigureLarson.
13-6 Classification
Let’s look at an example. Maximum Miniatures is having a problem with some
• Estimation
(Regression)
„odhadování”
je proces
přiřazování
nějaké pr
ůbwant
ěžně oceňované
wholesale
customers not -paying
their invoices
in a timely
manner. Therefore,
we
a way
to predict
the credit risk
of prospective
risk is our
predictionKde však klačíselné
hodnoty
k určitému
objektu
a je takcustomers.
obdobouCredit
předchozí
klasifikace.
attribute. We look at the past data, where we already know the value of the credit risk
sifikace
vrací We
diskrétní
hodnotu,
estimation
vrací
číslo.had
Výhoda
tétotometody
spočívá v její
attribute.
know who
paid their
bills on time
and who
to be taken
collections.
We can examine the past data and determine the attributes that most distinguish the
customers that were good credit risks from those that were bad credit risks. These
65 BERRY, Michael
are the J.A.;
distinguishing
attributes.
This
sounds
like an easy
to do,Sales,
but ifand
we Customer
have
LINOFF, Gordon
S. Data
Mining
Techniques:
For thing
Marketing,
Relationship
of records
in ourIndianopolis
past data, it(Indiana).
can be a daunting
task.
Management.millions
2nd ed. Wiley
Publishing.
2004. str. 8-9
66 S tím rozdílem, že na obrázku figurují místo zákazníků celé firmy.
This is where data mining proves its worth. Data mining is excellent at plowing
through millions of records to find correlations. It can process the past data and
2005 and the determine
Microsoft Business
Toolset.
Wiley
Publishing.
Canada.
2006.
str. 424or a CEO’s
whetherIntelligence
it is net assets,
annual
revenue,
invoice
payment
history,
favorite color that is a distinguishing attribute for credit risk.
Perhaps customers with over ten million dollars in assets and three million dollars in
annual revenue are almost always good credit risks, while customers that don’t meet these
32 become our distinguishing attributes: the
criteria are almost always bad credit risks. These
measures we can apply to prospective customers to determine what their credit risk is likely
to be. Using the distinguishing attributes, we can identify bad credit-risk prospects and ask
for cash in advance, before they have thousands of dollars’ worth of overdue invoices.
schopnosti vypočítat hodnotu pro nějakou proměnnou, například pravděpodobnost, že si
3.3
Data Mining
3
zákazník ve věku 15-20 let zakoupí CD přehrávač.68 Tak může firma poměrně snadno definovat své potenciální zákazníky.69
Estimation lze demonstrovat i na předchozím případě poskytnutí úvěru. Spíše než odpovědi
ano, ne by banka potřebovala vědět číselné vyjádření, jak moc výhodné to pro ni je. Algoritmy, které tyto hodnoty počítají jsou založeny na principu regresní analýzy, a proto je tato
metoda také někdy nazývána regression, regrese. Stejně jako v předchozím případě i zde
lze pracovat s Rozhodovacími stromy či Neuronovou sítí.
• Prediction - rozdíl mezi předpovědí a předchozími dvěma případy spočívá v tom, že předpověd’ se pokouší zařadit objekty na základě předpokládaného budoucího chování. Předpověd’ tak sice pracuje se stejnými technikami, ovšem za účelem stanovení proměnné, která
bude ověřena až v budoucnu. Jednodušeji řečeno, předpověd’ analyzuje pomocí matematických výpočtů, co se stalo v minulosti (zkoumá historická data uložená v datovém skladu)
a snaží se určit, co se, pokud vydrží současný trend, nejpravděpodobněji stane v budoucnu.
Příkladem může být firma, která staví nový dům za účelem následného prodeje a ráda by
tak určila jeho budoucí cenu. Aby byla schopna sestavit předpověd’, musí nejprve sestavit
soubor atributů, na základě kterých se bude cena odhadovat. Zde se jedná například o rozlohu domu, počet koupelen, destinace atd. Prediktivní metoda pak porovná atributy v tomto
souboru s jejich historickými hodnotami a na jejich základě vytvoří předpověd’.
Pro předpovídání číselné hodnoty se opět nejčastěji využívají Rozhodovací stromy a Neuronové sítě. Pro určení časové předpovědi se však musí využít specializovaných metod (např.
Microsoft Time Series).70
• Association (Affinity Grouping) - jedná se o proces vyhodnocování vztahů či asociací
mezi jednotlivými objekty, které prokazují určité vzájemné spříznění. Affinity Grouping může
být například použito k určení pravděpodobnosti, že zákazníci, kteří si pořizují jeden určitý produkt by byly ochotni vyzkoušet i jiný. Tento druh analýzy je velmi užitečný například
pro marketingové kampaně nebo také pro vytvoření takového produktu, který by oslovoval
co možná největší počet lidí.71
Nejvíce se však tato metoda používá v tzv. Market basket analysis. Jde o případ, se kterým
se asi setkal každý, kdo někdy nakupoval zboží na internetovém obchodě. Tyto e-shopy využívají asociačních algoritmů pro analýzu toho, co si zákazník vkládá do nákupního košíku
a následně mu zobrazují, co si uživatelé, kteří si zakoupili toto zboží také pořídili. V anglickém jazyce zní tato hláška „Customers, who bought this product, also bought.” a lze se s ní
setkat opravdu téměř všude. Tento proces ilustruje obrázek 11 na příkladu nákupu hraček
68 V souvislosti s tím se také zavádí pojem skóre. Zatímco pravděpodobnost vyjadřuje s jakou určitostí si zákazník
produkt koupí, skóre představuje procento zákazníků, které si daný produkt již zakoupilo.
2005 and the Microsoft Business Intelligence Toolset. Wiley Publishing. Canada. 2006. str. 425-426
Kaufmann Publishers. United States of America. 2003. str. 210
33
3.3
Data Mining
3
z druhé světové války.
Metody, které asociace počítají se jmenují stejnojmenně Association nebo Affinity Grouping.
Chapter 13: Panning for Gold—Introduc tion to Data M ining
489
Obrázek 11: Asociace - Market basket analysis
One-Item Sets
Two-Item Sets
Product
Sales
Product
Sales
American GI
British Tank Commander
German Panzer Driver
RAF Pilot
Russian Infantry
Russian Tank Commander
U.S. Army Pilot
U.S. Navy Gunner’s Mate
14,025
16,044
16,580
16,632
13,557
16,028
16,229
12,499
+ German Panzer Driver
+ RAF Pilot
+ Russian Tank Commander
+ U.S. Army Pilot
+ RAF Pilot
+ U.S. Army Pilot
RAF Pilot
RAF Pilot
+ U.S. Army Pilot
Russian Tank Commander
+ U.S. Army Pilot
15,232
15,132
10,983
15,139
Three-Item Sets
Product
Sales
+ RAF Pilot
+ U.S. Army Pilot
+ RAF Pilot
+ U.S. Army Pilot
10,773
14,845
10,937
15,493
14,238
14,943
13,293
15,134
13,489
Rules
94.9% buying British Tank Commander
also buy German Panzer
Driver
97.5% buying British Tank Commander
and German Panzer Driver
also buy U.S. Army Pilot
Zdroj: Larson. Delivering Business Intelligence with Microsoft SQL Server 2008. str. 489
Figure
13-15 The Microsoft Association Rules algorithm
• Now,
Clustering
(Segmentation)
- natest
clustering
lze dívat jako
automatickou
the algorithm
examines the
data set se
to determine
howna
many
purchases klasifikaci.
included
in each
two-item
set. Again,
minimum
level of
support
is který se co
Algoritmyboth
tétoitems
metody
seskupují
podobné
objektya do
tzv. clusteru
(shluku
dat),
required. In Figure 13-15, you can see we have 5 two-item sets with the minimum
nejvíce liší
od clusterů ostatních. Tyto clustery nejsou předem definované a je tak na příslušsupport
required.
Items
from theaby
two-item
sets aarepokoušel
now combined
form
three-item
sets.jsou
Thispředmětem
ném
analytikovi,
je zkoumal
se najít to
určité
závislosti.
Pokud
process continues until there is either one or zero sets with the minimum support. In
zkoumání zákazníci, mluvíme většinou o tzv. segmentaci.
Figure 13-15, no three-item sets have the minimum support required so, in this case,
Proces
clusteringu
je také
schopen
odhalit
nejčast
ější posloupnosti mezi daty. Proto je často
the
algorithm
does not
continue
with
four-item
sets.
Once
the
sets
are
created,
the
algorithm
creates
rules
based on
the také k urvyužíván například k mapování chování zákazníkůmembership
na webových
stránkách
nebo
result. The algorithm determined that 16,044 purchases included the British Tank
čení sledovanosti televizních pořadů v závislosti na jejich vysílacím čase. Clustering je
Commander.
Of those purchases, 15,232, or 94.9%, also included the German Panzer
také používán
k odhalení
problém
ů associations.
či závislostí aInmthe
ůžefuture,
tak sloužit
Driver.
This becomes
a rulejakýchkoliv
for predicting
future
whenjako vstup
someone
puts
the
British
Tank
Commander
in
their
shopping
cart,
95
times
out of 100,
pro ostatní metody data miningu. Příslušné algoritmy k této metodě jsou nazývány
Clustethey will also include the German Panzer Driver in the same purchase.
ring a Sequence Clustering.72
• Description and Profiling - o této metodě hovoří autoři v knize Data mining techniques
následovně. Někdy spočívá účel data miningu pouze v popisování toho, co se děje v nějaké
složité databázi a to tím způsobem, abychom získali lepší porozumění těm procesů, produktům či zákazníkům, které tato data v první řadě vyprodukovala. Dobrý popis problému
72 MUNDY,
Joy; THORNWAITE, Warren; KIMBALL, Ralph et al. The Microsoft Data Warehouse Toolkit: With SQL Server
2005 and the Microsoft Business Intelligence Toolset. Wiley Publishing. Canada. 2006. str. 426-427
34
3.4
Současné trendy ve vývoji datových skladů a BI
3
nějakého chování většinou dospěje také k jeho vyřešení a nebo alespoň poukáže na to, kde
ho hledat.
Za tímto účelem lze využít algoritmy jako Rozhodovací stromy, Clustering či Affinity Grouping.73
3.4
V této části je znázorněno, jakým směrem se vývoj datových skladů a Business Intelligence
nástrojů v dnešním světě ubírá. Jsou zde uvedeny dvě pravděpodobně nejaktuálnější témata
na tomto poli a to využití nestrukturovaných dat v datovém skladu a tzv. Real-time Business Intelligence.
Nestrukturovaná data
Až doposud byla jak v kapitole datových skladů, tak v části BI rozebírána pouze data, která byla
tvořena číslicemi, znaky atd. Tato data se nazývají strukturovaná. Pravdou však je, že daleko větší
část podnikových dat je tvořena jinými tzv. nestrukturovanými daty. Jedná se například o obrázky,
videa, webové stránky, prezentace, e-maily, dokumenty, hudbu atd. Na rozdíl od dat strukturovaných, která jsou většinou uložena v relačních tabulkách, jsou tato data ukládána na file serverech,
FTP serverech, mail serverech nebo také v content management či document management systémech. Vzhledem k tomu, že množství těchto dat může být v podnicích několikanásobně větší
než množství dat strukturovaných (záleží při tom samozřejmě na zaměření firmy), vzniká v posledních letech poptávka po možnosti ukládání a analyzování dat nestrukturovaných.
Otázkou tedy zůstává, jak tato data ukládat v datovém skladu a následně je pomocí BI nástrojů
analyzovat? V podstatě existují dvě možnosti. První z nich je označována jako tradiční a spočívá
v uložení nestrukturovaného objektu na určitý file server a jeho atributů pak do datového skladu.
Princip lze pochopit na příkladu dokumentů. Všechny z nich, at’ už jsou uloženy v jakémkoliv formátu, mají několik společných atributů, jako například název, téma, abstrakt, typ, verzi, id, datum
vytvoření, velikost, počet slov, jméno autora atd. Všechny tyto vlastnosti lze uložit do datového
skladu, kromě nich se však uloží do tabulky také adresa souboru na file serveru či jeho URL.
Tímto způsobem lze dokonce uložené atributy podrobit následné analýze stejně tak jako to bylo
v případě strukturovaných dat. Tuto metodu lze pochopitelně kromě dokumentů aplikovat i na jiná
nestrukturovaná data.
Tento přístup však z hlediska analýzy a zkoumání dat nepřináší žádné nové výhody. A proto
se objevila jiná metoda, která se nazývá text mining, nebo v poslední době spíše text analytics.
Jedná se o proces transformování nestrukturovaných dat na data strukturovaná na základě analyzování jazykové struktury textu uvnitř dokumentu, rozboru textu, extrahování slovních spojení a
identifikace asociací s využitím různých statistických analýz.
Management. 2nd ed. Wiley Publishing. Indianopolis (Indiana). 2004. str. 12
35
9314ch15final.qxd
3.4
11/15/07
9:43 AM
Page 472
472
3
CHAPTER 15 ■ OTHER DATA WAREHOUSE USAGE
Celý proces začíná převedením dokumentu do textu za pomoci speciálních nástrojů, které
the candidate
worked. Theznaky.
softwareNásledn
can then ě
use
thistakto
understanding
of the
parsed
text. The
jsou schopny
rozlišit jednotlivé
lze
připravený
text
podrobit
analytickému
words are then processed using a data mining clustering algorithm to get the relationships.
zkoumání.My
Jeho
výsledkem
seznam
slov
a frází spolu
s jejich tzv.
asociačním
hodnocením.
Toto
point
here is that ajetext
analytics
application
that is developed
specifically
for the
recruitindustry
understands
the context
of the
industry
and is able
to identify
that certain
hodnoceníment
si lze
představit
jako číslo
od 0 do
1, které
vyjadřuje
vztah
jednotlivých
frází. Čím vyšší
phrases are skills, titles, software, cities, and company names, whereas a pharmaceutical text
analytics
application
would
be ableje,
to recognize
symptoms,
research,jsou
diagnoses,
chemical
číslo je, tím
je vztah
silnější.
Důležité
že tyto the
analytické
aplikace
schopny
zpracovávat
content, cure, and treatment phrases within hundreds of medicine patent files. The applica-
takovéto dokumenty
v závislosti
na daném
kontextu,
životopisy atd.74
tion understands
the relationship
between
phrases, například
such as howfaktury,
skills aresmlouvy,
related to software
and how symptoms
related
treatments.
Because ofpomocí
this, when
selecting a textnástroj
analytics
Vygenerovaný
seznam are
frází
lze to
následn
ě zpracovat
analytických
ů nebo také
application, you need to ensure that it has the right “dictionary” for your industry. A text ana-
lyticsminingového
application, which
works well for algoritmu.
pharmaceuticals,
not be good
for processing
pomocí data
clusterovacího
Ten may
je schopen
lépe
znázornit počet a sílu
claim documents within the insurance industry.
jednotlivých vztah
ů. Takto
schéma
je znázorn
ěno na to
obrázku
12. A pictorial
The scored
lists vytvořené
describe which
words have
strong relations
other words.
representative of the result is probably easier to understand. Figure 15-3 shows the result of
the résumé example.
Obrázek 12: Reprezentace textové analýzy pomocí data miningu
Zdroj:
Rainardi.of
Building
a of
Data
str. 472
Figure 15-3. Pictorial
representation
the result
textWarehouse.
analytics
The line thickness reflects the strength of association between the phrases. For example,
V souvislosti
s nestrukturovanými daty je také nutné zmínit koncept nové generace datových
in Figure 15-3, city A is more related to role B than to software A, and software B is more closely
associated
to skill B than
to city
D. City
C is related only
software
and company
A has
nosplňuje půskladů, který
je označován
jako
Data
Warehousing
2.0to(DW
2.0).A, Tento
přístup
sice
relation with any skill, software, or company. The other output of the analytics is grouping or
vodní Inmonovu
definici
uvedenou
v první kapitole,
zárove
sethevšak
první
classification
according
to the taxonomy
of the phrases,
thatňis,
list ofod
cities,
list generace
of jobs, list datových
of roles, list of software, and so on. It is often industry specific. In other words, text analytics or
skladů lišímining
v několika
bodech:
software that works well for car insurance claims may not have the vocabulary required
to analyze food and beverage patents.
• Životní Once
cyklus
jaklists
data
stárnou,
mění scores,
se i jejich
charakteristika.
Vdata
důsledku
youdat
have- the
and
the association
you can
store them in the
ware- toho jsou
house for further analysis. For example, you can ask questions such as, “What are the top five
data v DW 2.0 rozdělena na několik oblastí právě podle jejich věku.
• Nestrukturovaná data - nestrukturovaná data jsou naprosto validní součástí datového skladu.
Kromě toho se zde vyskytují v několika formách, jako jednotlivé úryvky textu, jako upravená
slova a fráze a také jako tzv. matching text, který vyjadřuje pravděpodobnost shodnosti nestrukturovaných dat.
• Přítomnost metadat - DW 2.0 klade větší důraz na metadata a stejně tak jako v předchozím
bodě i metadata jsou členěna na více úrovní.
74 RAINARDI,
Vincent. Building a Data Warehouse: With Examples in SQL Server. Apress. United States of America.
2008. s. 470-473
36
3.4
3
Tyto body sebou také přinášejí jisté výhody, a tak lze předpokládat, že vývoj datových skladů bude
směřovat právě tímto směrem. Zajímavá je i skutečnost, že rozvoj DW 2.0 podporuje i sám William
H. Inmon, zakladatel první generace datových skladů. Na druhou stranu je nutné říci, že je tento
koncept starý pouze pár let a v praxi se zatím příliš nevyužívá. Na jeho uplatnění v budoucnu si
bude tedy ještě třeba nějakou dobu počkat. Schéma struktury DW 2.0 zobrazuje obrázek 13.75
Obrázek 13: Struktura DW 2.0
Zdroj: http://www.information-management.com/issues/20060401/1051111-1.html
75 INMON, William H. DW 2.0 - Architecture for the Next Generation of Data Warehousing - Information Management
[online]. 04.2006, [cit. 2010-04-22]. Dostupné z: <http://www.information-management.com/issues/20060401/10511111.html>
37
3.4
3
Real-time Business Intelligence
I přestože je toto téma v podstatě v přímém rozporu s myšlenkou této práce, tedy ukázat nezbytnost přítomnosti datového skladu pro BI aplikace, považuji za důležité tento pojem alespoň
zmínit. Jedná se o technologii, která se začala rozvíjet teprve před několika lety a představuje
pravděpodobně jednu z možných cest dalšího vývoje celého odvětví datových skladů a BI.
Problém běžného Business Intelligence spočívá v tom, že pracuje s daty, která nejsou úplně
aktuální. To je samozřejmě spojeno s tím, že datový sklad se většinou aktualizuje jednou za den
či dokonce méně často. V dnešní době však současné ekonomické prostředí a situace kladou
stále větší nároky na nutnost analyzovat co možná nejaktuálnější data, nejlépe v reálném čase.
Příkladem může být odhalení podezřelé bankovní transakce nebo také analýza propadu tržeb
daného dne. Ve všech těchto případech již klasické BI nástroje nestačí.76
V souvislosti s těmito příčinami se tedy v posledních letech objevilo několik nových technologií
a pojmů. To, ke kterému zde směřuji, se nazývá Real-time Business Intelligence (RTBI), někdy
také Business Intelligence 2. Vzhledem k tomu, že je tato problematika poměrně nová, neexistuje
ještě žádná standardizovaná definice. Lze však definovat, co RTBI pro každý podnik znamená.
Spojení real-time může tedy vyjadřovat:
• Požadavek na nulovou latency jakéhokoliv procesu
• Fakt, že má proces přístup k informacím kdykoliv je potřeba
• Možnost čerpat měřené hodnoty, které se vztahují k současné a ne historické situaci77
Nutno říci, že tyto požadavky mohou být naplněny takřka pouze v případě, že se budou data čerpat z provozních databází, které mohou zaručit jejich aktuálnost. Existuje sice také technologie
Real-time Data Warehouse, která se snaží o minimalizaci prostojů mezi jednotlivými aktualizacemi dat, ovšem ani ta ve většině případů nevyhovuje výše uvedeným požadavkům. Jednotlivé
načtení probíhá v intervalech v rozmezí několika až desítek minut, a tak definici „datového skladu
v reálném čase” stejně přímo neodpovídá.
RTBI aplikace se, díky své orientaci na současné problémy, přesouvají především do oblasti
různých přehledových zobrazení, jako například dashboards, internetové portály atd. Výhodou
tohoto přístupu je navíc také to, že pro zacházení s těmito nástroji uživatel většinou nepotřebuje
dobrou znalost jak business domény, tak informačních technologií. Tyto aplikace poskytují většinou spíše high level pohled na současnou situaci a navíc v takové formě, která je pro uživatele
srozumitelná. Jedná se většinou o různé grafy, tabulky a jiné formy prezentace dat.
Real-time Business Intelligence tak ukazuje jakýsi trend, kterým se informační nástroje v tomto
odvětví budou nejspíše ubírat. Otázkou však zůstává, jakou roli budou v této vizi hrát datové
sklady.
76 Real-Time
Business
Intelligence
Gravic
[online].
c2010,
[cit.
2010-04-22].
Dostupné
z:
<http://www.gravic.com/shadowbase/uses/realtimebusinessintelligence.html>
77 AZVINE, B.; CUI, Z., et al. Real Time Business Intelligence for the Adaptive Enterprise [online]. [cit. 2010-04-22].
Dostupné z: <http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.101.194&rep=rep1&type=pdf>
38
4
NÁVRH A VYUŽITÍ DATOVÉHO SKLADU VE SPOJENÍ S BI
Praktická část
4
Návrh a využití datového skladu ve spojení s BI
Tato kapitola je věnována praktické ukázce využití datového skladu ve spojení s Business Intelligence nástroji. První část se však zabývá návrhem později využívaného datového skladu a to
i přesto, že návrh a implementace datového skladu není přímo předmětem této práce. Pro pochopení jeho využití a tedy i další částí kapitoly či jeho výhod oproti klasické normalizované databázi
je však tato část důležitá. Implementační část navíc přímo souvisí s využitím datových skladů
nebot’ se zde definují technologie, které umožňují propojení datového skladu s okolními systémy
a především pak jeho naplnění patřičnými daty.
Další kapitoly jsou již věnovány výhradně možnostem využití datových skladů. První z nich se
zaměřuje na problematiku reportů, v dalších kapitolách se pak věnuji analýze a data miningu.
4.1
Návrh a implementace
Jak již bylo řečeno, první část této kapitoly se věnuje návrhu a implementaci datového skladu,
který bude následně využíván k ukázkám v dalších kapitolách. Aby byly funkce a využití datových
skladů co nejsrozumitelnější, byl pro implementaci datového skladu vybrán typický model prodejní
společnosti. Jedná se o prostředí, kde se datové sklady budují velmi často a jeho struktura je
poměrně jednoduchá a dobře představitelná, proto je vhodný i pro demonstraci využití v této
práci.
Datový sklad bude vyvíjen pro fiktivní zahraniční firmu, která se zabývá prodejem elektroniky.
Vzhledem k tomu, že působí ve více zemích78 , má společnost velký problém s organizací svých
dat, především potom s jejich analýzou. Firemní data musí být získávána z několika různých
systémů napříč jednotlivými státy, což je velmi obtížné. Organizace by tak chtěla své informace
o prodeji analyzovat podle zeměpisné oblasti a také dle různých kategorií svých produktů, to vše
přitom v závislosti na čase. Zároveň by firma chtěla mít lepší přehled o svých zákaznících napříč
svými systémy.79
Návrh požadovaného datového skladu by se dal rozdělit do těchto fází:
1. Definování business požadavků
2. Návrh dimenzionálního modelu
3. Návrh technologické platformy
4. Implementace a načtení dat
78 Firma
působí v USA, Kanadě a Mexiku.
79 Toto jsou pouze informace nutné pro nastolení výchozí situace. Popis firmy a následné získávání požadavků nelze brát
jako systematický postup při vývoji datového skladu, nýbrž spíše jako definování důležitých informací o systému. V další
části práce se tedy mohou objevit atributy, které by nemohly být logicky odvozeny z popisu firmy na začátku kapitoly.
39
4.1
4
Definování business požadavků
Z popisu firmy byly určeny základní subjekty účastnící se firemních procesů. Tím hlavním je samozřejmě samotný prodej, dalšími faktory, které do tohoto procesu zasahují jsou zákazník a také
obchod, ve kterém se prodej uskutečnil (z požadavku na zeměpisné rozlišení). Vzhledem k tomu,
že firma potřebuje analyzovat svá data v závislosti na čase, je dalším faktorem účastnící se tohoto
procesu čas. Základní podobu datového skladu ilustruje konceptuální model na obrázku 14.
Obrázek 14: Konceptuální schéma datového skladu
Kromě struktury je také třeba určit, co by měl datový sklad umět, jinými slovy je třeba určit
funkční požadavky. Datový sklad musí umožňovat:
• analyzovat požadovaná data v závislosti na čase, na produktu, na zákazníkovi, který si daný
produkt zakoupil a na obchodě, ve kterém bylo zboží zakoupeno. Zároveň musí umožnit
sledování tržeb, nákladů a zisků z prodeje a také počty prodaných kusů.
• vyhledávat zákazníky dle zeměpisných údajů (země, města atd.) a také podle jejich demografických údajů (pohlaví, věk, zaměstnání atd.)
• analyzovat data na úrovni let, kvartálů, měsíců, týdnů a dnů
• analyzovat data podle jednotlivých států a měst
• od prvního spuštění analyzovat nejméně dva roky stará data
Dále by měly být určeny nefunkční požadavky či provedena analýza rizik, oba dva procesy jsou
však v tomto případě irelevantní.
40
4.1
4
Návrh dimenzionálního modelu
Poté co byly v předchozí části shromážděny základní požadavky na systém, je nyní možné přistoupit k dimenzionálnímu modelování. Cílem této části je zformovat tyto požadavky do podoby
logického modelu datového skladu. Prvním krokem je odvození patřičných dimenzí ze struktury
systému. Z konceptuálního modelu lze určit, že dimenze budou následující:
• zákazník
• produkt
• obchod
• čas
Z funkčních požadavků lze navíc odvodit požadované míry, které se budou sledovat. Těmi jsou:
náklady, tržby, zisk a počet prodaných kusů. Tyto hodnoty tvoří jádro faktové tabulky. Po spojení
jednotlivých dimenzí s faktovou tabulkou pomocí cizích klíčů navíc vznikne požadovaný dimenzionální model. Je vidět, že všechny nasbírané požadavky se týkají právě jedné business problematiky, a tak toto schéma přesně odpovídá definici data martu uvedené dříve.
V dalším kroku dimenzionálního modelování byly navrženy jednotlivé atributy. Bylo dbáno
na to, aby vyhovovaly požadavkům stanovených dříve a zároveň odpovídali definici dimenzionálního modelu.
• Faktová tabulka prodej - u faktové tabulky se nachází unikátní primární klíč id_prodej a cizí
klíče, které ji spojují s jednotlivými dimenzemi. Dále je zde uveden počet prodaných kusů
jednoho produktu a také náklady a tržby z prodeje daného produktu. Posledním, ovšem
nejdůležitějším atributem je položka zisk. Tato položka je vypočítána přímo databází jako
rozdíl mezi tržbami a náklady na prodej. Dá se předpokládat, že právě tento atribut bude
nejčastějším předmětem dotazů. Jak bylo uvedeno v teoretické části, je u faktových tabulek
důležité stanovit jejich granularitu. V tomto případě jedna řádka v tabulce koresponduje
s jednou prodanou položkou.
• Dimenze datum - dimenze jsou spojeny s faktovou tabulkou pomocí cizích klíčů, obsahují
tedy unikátní primární klíč. V případě této dimenze se jedná o atribut id_datum. Dimenze
data je zároveň dobrým příkladem toho, jaké redundantní informace se mohou v dimenzionálních modelech skrývat. Kromě data samotného je zde ještě zvlášt’ definován měsíc,
týden a den a to navíc v některých případech jak v číselné, tak slovní formě.
Tento fakt také souvisí s vytvářením na sebe navazujících atributů, hierarchií. Díky tomu
bude možné procházet a zkoumat data obsažená v datovém skladu na různých úrovních,
a získat tak daleko více potřebných informací.
41
4.1
4
Obrázek 15: Logický model
42
4.1
4
• Dimenze zákazník - dimenze zákazníka byla navržena především s ohledem na praktickou
ukázku data miningu. Shromažd’uje tak všechny možné informace o zákazníkovi, které by
jinak v reálném případě prodejního oddělení bylo jednak zbytečné a jednak i takřka nemožné
získat. Tabulka zákazník tedy obsahuje primární klíč id_zakaznik a další popisné atributy
jako například vek, prijem, zamestnani atd.
Jestliže předchozí dimenze byla příkladem redundance jako jednoho ze základních projevů
dimenzionálního modelu, na této dimenzi je vidět její denormalizace. V případě klasické
normalizované databáze by se atributy jako emailova_adresa, adresa_1 či jiné geografické
atributy nejspíše nacházely v samostatné tabulce, zde jsou však umístěny v jedné.
• Dimenze produkt - tato dimenze obsahuje, kromě primárního klíče id_produkt, další atributy, z nichž za nejdůležitější se dají označit nazev, typ a kategorie, které jsou zároveň
součástí jedné hierarchie, dle které se dá jasně odlišit, který segment, kategorie či konkrétní
výrobek se v dané chvíli nejvíce prodává. V tabulce jsou dále uvedeny popisné vlastnosti
produktu jako cena, hodnota80 , vaha, sirka nebo také informace, zda-li je daný výrobek
recyklovatelný.
• Dimenze obchod - u této dimenze je nejdůležitější odlišit jednotlivé obchody na základě
geografického umístění. Tabulka tedy obsahuje atributy jako mesto, zeme, či adresy obchodů. Dalším důležitým atributem je typ obchodu, který zachycuje, jedná-li se o kamenný
či elektronický obchod. Primárním klíčem je id_obchod.
Výsledný logický model znázorňuje obrázek 15. Je vidět, že model odpovídá hvězdicovému schématu, nebot’ není důvod jednotlivé dimenze normalizovat, naopak by se tím potlačily výhody spojené s požadavky na analýzu a dotazování.
Návrh technologické platformy
V tomto bodě je určena technologická platforma, na které bude data mart založen. Výstupem
bude tedy fyzický model, který je již plně přizpůsoben dané databázi.
V tomto případě se nemuselo přihlížet na to, zda jsou některé technologie pro vývoj upřednostňovány, proto byl výběr realizován na základě kvality či vhodnosti a také na základě předchozích
zkušeností s daným produktem. Obecně lze říci, že projekt byl realizován převážně s využitím
aplikací od společnosti Microsoft, základním softwarem pro další technologie byl proto operační
systém Windows XP81 .
Použité technologie lze shrnout do několika kategorií:
• pro správu datového skladu byl použit Microsoft SQL Server 2008 Enterprise spolu s programem pro správu databázových tabulek SQL Server Management Studio. Tento software
80 Cenu
lze chápat jako částku, za kterou se produkt prodává, zatímco hodnota je v podstatě výrobní cena výrobku.
Tyto atributy jsou zde uvedeny jen pro znázornění ceny výrobku, nemají však žádnou souvislost s aktuálními náklady či
tržbami prodeje, to by ve skutečnosti zajišt’oval provozní systém, ze kterého by data byla načítána.
81 V mém případě se jednalo o Windows XP Service pack 3, ale lze samozřejmě použít jakýkoliv novější operační systém
od společnosti Microsoft.
43
4.1
4
byl vybrán na základě předchozích zkušeností, velice dobré dokumentace všech vlastností
SQL serveru a také jeho dostupnosti.82 Jeho největší výhodou jsou však s ním dodávané
programy uvedené v následujícím bodě.
• SQL Server je dodáván jako balík aplikací, které jsou uvedeny pod jedním názvem. V Enterprise edici tak lze najít program SQL Server Business Intelligence development studio,
který má v sobě zabudován hned několik dalších komponent potřebných pro tento projekt.
Jedná se o aplikaci Integration Services, pomocí které lze načíst data do datového skladu,
a dále o aplikace Analysis Services a Report Services, které budou využity při tvorbě analytických dotazů či reportů. Pro analýzu dat vytvořených pomocí těchto programů byl pak
využit program Microsoft Excel 2007.
• pro načtení dat byla využita částečně aplikace Integration Services spolu s programem
Microsoft Excel, ve kterém byla data vytvořena. Zbylá data byla načtena pomocí programu
SQL Data Generator, který umožňuje poměrně jednoduché vygenerování testovacích dat
a lze ho volně používat po dobu 14 dnů.
• další kategorií jsou nástroje použité pro vytvoření jednotlivých modelů datového skladu.
Konceptuální model byl vytvořen v programu Microsoft Office Visio 2007, všechny zbylé
modely pak v programu Enterprise Architect.
Nyní lze začít s transformací logického modelu na fyzický. V první části jsou přizpůsobeny jednotlivé datové typy databázi SQL Server.
Až na výjimky se jedná o datové typy int v případě čísel, nvarchar či nchar v případě textu
a smalldatetime v případě datumu. Datový typ nvarchar byl vybrán z toho důvodu, že obsahuje
znaky unicode, což není v našem případě nezbytně nutné, nebot’ jsou atributy psány bez diakritiky,
ovšem má to velký význam pro pozdější import dat do datového skladu. Nevýhoda tohoto typu
je, že díky tomu, že obsahuje dvakrát tolik znaků, zabírá také více místa na disku. V případě
této databáze to však nehraje velkou roli, nebot’ velikost bude i tak relativně malá. Datový typ
smalldatetime se od klasického date liší tím, že může obsahovat pouze data mezi lety 1900 až
2079, což v tomto případě opět není důležité.
V další části je nutné správně zvolit cizí klíče. Faktová tabulka ponese informace o primárních
klíčích každé dimenze, jedná se tedy o id_obchod, id_zakaznik, id_produkt a id_datum. Zároveň
je dobré již v této fázi myslet na případnou optimalizaci systému. Vzhledem k tomu, že cílem
této kapitoly je především ukázat využití datových skladů, není zde věnováno optimalizaci mnoho
prostoru. Přesto však lze nyní navrhnout základní indexy, které mohou teoreticky pomoci k vyššímu výkonu. Protože může u reportování často docházet ke spojování všech dimenzí s faktovou
tabulkou, jsou indexy umístěny na cizí klíče právě v této tabulce.
Výstup této části v podobě fyzického modelu lze vidět na obrázku 16.
82 SQL
Server 2008 Enterprise lze volně používat po dobu 180 dní.
44
4.1
4
Obrázek 16: Fyzický model
45
4.1
4
Implementace a načtení dat
Jednou z výhod programu Enterprise Architect je, že dokáže z fyzického modelu vygenerovat
zakládací skripty pro jednotlivé databázové tabulky. Zde je uveden příklad takto vygenerovaného
kódu v případě tabulky produktu:83
Podobným způsobem byly vygenerovány i ostatní tabulky a byl tak vytvořen kompletní dimenzionální model. Před načtením dat bylo ještě nutné lehce upravit tabulku prodeje. Jak bylo
uvedeno dříve, atribut zisk není importován, nýbrž je počítán přímo databází. K tomu lze využít funkčnost SQL serveru, která se nazývá computed column. Ta umožňuje využít jakýkoliv jiný
atribut z příslušné tabulky pro výpočet daného atributu. Položka zisk bude tedy upravena následujícím způsobem:
Parametr persisted zaručuje, že bude atribut fyzicky uložen na disku. Bez tohoto parametru
by byl přepočítáván při každém použití.
K plnohodnotné ukázce jakýchkoliv BI nástrojů je nutné, aby datový sklad obsahoval velké
množství dat, především historických. Ve funkčních požadavcích je navíc uvedeno, že datový
sklad by měl již od prvního spuštění uchovávat minimálně dva roky stará data, což toto množství
dále umocňuje. Vzhledem k tomu, že není k dispozici žádná operační databáze, ze které by se
daly čerpat reálná data, je nutné tato data nějakým způsobem vygenerovat a simulovat tak chod
skutečného systému.
Jak již bylo řečeno, k tomuto úkolu byl využit program SQL Data Generator. Pomocí něho
bylo možné určit přesnou podobu testovacích dat i počet řádek k vygenerování. Aplikace pak
požadovaná data vygenerovala a sama načetla do databáze.
83 Kód
není kvůli délce kompletní.
46
4.2
Vytvoření reportů
4
V případě tabulky datum však bylo zapotřebí vytvořit data manuálním způsobem a poté je
do datového skladu importovat.84 K tomu byly využity programy Microsoft Excel a Integration
Services. Tato aplikace umí načíst libovolná data ze souboru Excel, přetransformovat je tak, aby
odpovídaly cílové destinaci a následně je do ní načíst.85
Celý proces importu dat pomocí aplikace Integration Services je zachycen na obrázku 17. Tím
je také proces návrhu datového skladu ukončen a nyní lze konečně přistoupit k jeho využívání.
Obrázek 17: Proces integrace dat do databáze
4.2
V této části jsou uvedeny praktické ukázky uživatelských reportů, které lze ve spojení s datovým
skladem vytvořit. Zároveň zde budou znázorněny široké možnosti SQL Report Services nástroje,
ve kterém budou dotazy tvořeny. Výstupem této části jsou ukázky dvou v praxi se nejvíce vyskytujících typů reportů.
Jak je známo, nástroje na vytváření reportů by měly být mezi ostatními nástroji Business
Intelligence těmi jednoduššími, nebot’ s nimi často pracují běžní uživatelé. V tomto ohledu vychází
program Report Services opravdu vstříc. Díky spojení přehledného GUI aplikace s jednoduchou
strukturou datového skladu lze vytvořit různé reporty poměrně snadným způsobem.
S tímto případem je spojen první ukázkový report, uveden na obrázku 18, který obsahuje přehled zákazníků, kteří si zakoupili nějaký produkt. Jedná se o případ, kdy nejsou spojovány žádné
databázové tabulky, pouze jsou vybrány některé atributy, se kterými se dále pracuje. Na ukázce je
vidět, že uživatelé si mohou prohlížet zákazníky na základě země a města, ve kterém bydlí. Dále
mohou být zákazníci řazeni dle jejich věku či jejich jména. Spolu s možností zákazníky v jednotlivých zemích a městech postupně skrývat a zobrazovat se jedná o snahu vytvořit alespoň trochu
flexibilní prostředí, přestože jsou v tomto ohledu daleko převyšovány OLAP nástroji.
Jak již bylo řečeno, report se dá vytvořit pomocí grafického uživatelského prostředí nebo ručně,
zadáním SQL dotazu. Přestože znalost dotazovacího jazyka není pro tvorbu tohoto jednoduchého
reportu nezbytně nutná, kontaktu s ním se uživatel nevyhne. Pro přehled tedy uvádím krátký
příkaz pro vytvoření reportu z obrázku 18.
84 V předchozím případě byl, až na pár výjimek, každý sloupec generován nezávisle na sobě, zde však není možné mít
například jako jeden objekt datum 1.1.2010, den 15, měsíc červen, kvartál q2 atd.
85 Kvůli tomuto kroku byly zvoleny atributy, které podporují unicode kódování.
47
4.2
4
Obrázek 18: Přehled zákazníků
48
4.3
Analýza (OLAP)
4
Druhý případ je již pro uživatele složitější, na druhou stranu je však nutné říci, že je i přesto
nejčastějším typem vytvářených reportů. Jedná se o případ, kdy dochází ke slučování typicky
všech dimenzionálních tabulek s tabulkou faktovou. Zde se plně projevují výhody dimenzionálního
modelu a tedy i datového skladu obecně, nebot’ díky hvězdicovému schématu se dají tabulky
velmi efektivně spojit.
Takto vytvořený report, který je uveden na obrázku 19, zobrazuje přehled týdenních tržeb rozdělených podle typu produktu. Jednotlivé tržby jsou tak sčítány, nebot’ ve faktové tabulce jsou
uvedeny zvlášt’ pro každou prodanou položku. Zároveň je zde možnost zobrazit pouze data z určitého roku či kvartálu nebo z určité země či města. Pro tuto funkčnost se musely vytvořit tzv.
parametry, do kterých byly pomocí dalšího SQL příkazu načteny hodnoty, ze kterých pak může
uživatel při výběru volit. Zde je uveden příkaz, pomocí kterého byl report vytvořen:
Velkou výhodou takto vytvořených reportů je i to, že se dají exportovat do jiných programů,
například Microsoft Word nebo Excel, kde se s nimi dá dále pracovat. Kromě exportu do různých
formátů se reporty dají publikovat na webovém serveru, což zajišt’uje program Report Manager.
4.3
Analýza (OLAP)
V této kapitole je znázorněno praktické využití datových skladů ve spojení s analytickými nástroji. Za tím účelem bude vytvořena multidimenzionální databáze, která bude následně sloužit
jako zdroj pro OLAP analýzu. Proto je také tato kapitola rozdělena na dvě části. V té první je
popsán vývoj MDD, v té druhé jsou pak uvedeny ukázky analytického dotazování, tak aby vhodně
znázornily široké možnosti OLAP nástrojů.
49
4.3
Analýza (OLAP)
4
Obrázek 19: Přehled týdenních tržeb
50
4.3
Analýza (OLAP)
4
Multidimenzionální databáze
Proces vytvoření datové kostky je složen z několika částí:
1. Výběr datového zdroje - jako datový zdroj, ze kterého se bude pro vytvoření kostky vycházet
byl vybrán samozřejmě dříve vytvořený datový sklad
2. Výběr struktury - z požadavku na zkoumání dat dle geografického umístění a podle kategorií prodávaných produktů v závislosti na čase byly jako dimenze vybrány dim_obchod,
dim_produkt a dim_datum. Součástí struktury datové kostky je samozřejmě faktová tabulka
prodeje. Dimenze obsahující data o zákaznících byla pro tuto část vynechána.
3. Návrh MDD - v této části byly vybrány jednak hodnoty z faktové tabulky, které tvoří zkoumané parametry, a dále pak jednotlivé atributy a hierarchie, se kterými se bude pracovat.
Jako hodnoty byly zvoleny všechny přípustné atributy z faktové tabulky, tedy naklady, trzby,
zisk a pocet_kusu. Jako hierarchie v případě tabulky datum byla vybrána posloupnost rok,
kvartal, nazev_mesice, tyden, nazev_dne.86 U tabulky obchodu se jedná o navazující atributy zeme, mesto a nazev. V případě produktu se jedná o atributy kategorie, typ a nazev.
Atributy, které nejsou součástí žádné hierarchie jsou v databázové kostce taktéž obsaženy.
4. Vytvoření kostky - na závěr se musí navrhnutá kostka fyzicky vytvořit a naplnit požadovanými daty. V programu Analysis Services se toho lze docílit spuštěním procesů build, deploy
a process.
5. Vytvoření KPI - byl vytvořen indikátor zisku, který pomáhá sledovat jeho současný stav a vývoj do budoucna napříč všemi úrovněmi a dimenzemi. Cílová hodnota zisku odpovídá jedné
třetině tržeb. Tímto způsobem lze navíc kontrolovat i náklady nebot’ ze vztahu mezi ziskem,
tržbami a náklady je jasné, že nemohou být větší než dvě třetiny tržeb.
Co se týče vývoje do budoucna je cílem, aby hodnoty zisku byly o 20% větší než předcházející týden. V případě, že je dosaženo nižších hodnot, ukazatel trendu se snižuje. Tyto
indikátory byly zadány pomocí skriptovacího jazyka MDX, který je určen pro práci s multidimenzionální databází.
Zde je ukázka nastavení vývoje zisku, nebo-li trendu:
86 Druhou
variantou je hierarchie rok, kvartal, nazev_mesice, den.
51
4.3
Analýza (OLAP)
4
Analytické dotazování
Nyní je již možné vytvořenou datovou strukturu libovolně procházet a analyzovat. Přestože s ní
lze pracovat přímo v Analysis Services, obecně nejlepším programem pro OLAP analýzu je označován Microsoft Office Excel, proto i v této práci je využíván právě tento program.
Výstupem této části je tedy jeden dokument ve formátu excel, který je tvořen několika záložkami. V každé z nich se analýza zaměřuje na něco jiného a jsou uvedeny odlišné možnosti
prezentace dotazovaných dat. Základním cílem však bylo uvést všechny možnosti OLAP analýzy
ve spojení s multidimenzionální databází, tedy možnost prohlížet data na elementární úrovni či
naopak vysoce agregovaná data a zároveň také možnosti tzv, krájení a sekání dat.
• V prvním sešitu je znázorněn případ drill up/down. Uživatel může prohlížet náklady, tržby
a zisk jak na úrovni zemí, tak i na úrovni měst čí jednotlivých obchodů. Zároveň lze díky velké
flexibilitě analytických nástrojů měnit požadované období a také určitou kategorii produktů.
• Ve druhé záložce je vypracována ukázka zmiňovaného krájení kostky. Jako parametr, dle
kterého se kostka filtruje, je zvolen název obchodu. Ten je pak zobrazován uživateli v kontextu s kategoriemi a typy produktů a také s časem. Příklad přesně odpovídá definici krájení
kostky, kdy je zvolen jeden parametr na nejnižší úrovni a následně je zkoumán na základě
zbylých dimenzí v celém spektru datového skladu.
• U sekání je situace podobná, ovšem parametr není elementární informace, jedná se o kategorii či typ produktu. Stejně tak osy tabulky zobrazují již vyfiltrovaná data, konkrétně rok
2009 a obchody pouze v USA.
• Čtvrtý sešit neobsahuje z hlediska obsahu nic nového. Co bylo ovšem změněno, je forma
prezentace dat. Je zde uveden graf, který je schopen dynamicky zobrazovat data, která uživatel vybere na základě parametrů uvedených na téže straně. Zde lze vybírat na základě
území a období, přičemž data jsou členěna dle kategorií. Kromě grafu je zde uveden ještě
jeden vizuální prvek a to sice podmíněné vybarvování sloupců v poměru k ostatním hodnotám. Lze tak na první pohled odlišit, která kategorie má největší náklady, tržby a zisk.
• V poslední části je uveden přehled indikátoru stavu zisku, který byl navržen a popsán v předchozí kapitole. Kromě klasické tabulky, která uvádí zisk na základě zvolených parametrů,
jsou zde uvedeny sloupce cílový zisk, stav a trend. Sloupec zisk je aktuální zisk pro danou položku, zatímco cílový zisk představuje číselnou metu, které chce podnik dosáhnout.
Sloupce stav a trend jsou znázorněny pomocí ikon, které se nastaví na patřičný tvar pomocí
vypočítaných hodnot z vytvořené KPI. Tato ukázka je uvedena na obrázku 20.
52
4.3
Analýza (OLAP)
4
Obrázek 20: Ukázka OLAP analýzy v programu Microsoft Excel
53
4.4
Data mining
4.4
4
Data mining
Cílem této části je vytvořit data miningový model a ten vzápětí pomocí různých metod analyzovat.
Výstupem této kapitoly budou jednak schémata a grafy vytvořené v programu Analysis Services,
a zároveň také různé poznatky a vztahy mezi zkoumanými atributy daného podnikového procesu
či oddělení.87 Proces začlenění data miningu do systému se stejně jako v předchozích částech
dá rozdělit do několika fází.
1. Vymyšlení zkoumaných parametrů
2. Vytvoření datové struktury pro zkoumání
3. Vytvoření modelů pro zkoumání
4. Zkoumání dat
Nejprve je tedy třeba rozhodnout, které vztahy a souvislosti mezi daty se budou zkoumat. Pro prodejní odvětví je bezesporu nejdůležitějším faktorem vztah mezi zákazníkem a produktem, který
kupuje. Proto lze formulovat otázku, na kterou se následná analýza dat bude snažit odpovědět,
následovně: „Jaký je vztah mezi vlastnostmi zákazníka88 a typem produktu, který pořizuje?” Jako
konkrétní příklady mohou posloužit následující úvahy: „Kupují si MP3 přehrávače a jinou elektroniku spíše mladí lidé a naopak domácí spotřebiče spíše lidé starší? Jakou roli hraje v nákupu
počet dětí zákazníka? Je nějaký vztah mezi vzděláním či zaměstnáním zákazníka a typem produktu?” A nebo také: „Kupují si elektroniku spíše bohatí lidé?”
Na základě těchto úvah je nutné vytvořit datovou strukturu, ze které je program Analysis Services schopen získat požadované údaje. Byla tedy vytvořena tabulka obsahující všechny relevantní
údaje o zákazníkovi a zároveň informace o tom, který typ produktu daný zákazník nakupoval.
Pro každý z nich byl vytvořen příslušný sloupec a následně byla pomocí SQL příkazu do tabulky
načtena data z ostatních tabulek datového skladu. Výslednou podobu vytvořené tabulky i se všemi
atributy ilustruje obrázek 21.
Následně bylo nutné tato data integrovat do programu Analysis Services a určit jednotlivé modely, které se budou analyzovat. Kromě načtení samotné tabulky bylo také třeba určit atributy,
které slouží jako vstup a atributy, které se budou předpovídat. Z úvodu je patrné, že jako vstupní
atributy budou sloužit věk, pohlaví, počet dětí, ukončené vzdělání, zaměstnání a příjem. Naopak
zkoumané hodnoty budou vybrané typy produktů. V teoretické části bylo popsáno několik odlišných technik a algoritmů pro zkoumání závislostí mezi daty. Pro tento případ byly jako nejvhodnější zvoleny metody Decision trees, Clustering, Neural network a Association rules a na základě
toho byly také vytvořeny patřičné data miningové modely.
87 Vzhledem
k tomu, že jediným způsobem, jak simulovat dvouletý chod provozního systému, bylo data pomocí víceméně náhodného algoritmu vygenerovat, nelze bohužel očekávat nějaké vysoké závislosti mezi jednotlivými atributy.
Stejně tak je možné, že některá výsledná spojení budou naprosto odporovat reálným poznatkům. Na druhou stranu je
nutné zdůraznit, že výsledky zde uváděné jsou spíše určitou nadstavbou, nebot’ principialně šlo především o demonstraci
vytvoření data miningového modelu z datového skladu a názorné ukázky jeho možností.
88 Vlastnostmi zákazníka jsou myšleny informace, které jsou uchovány v databázi. Tedy jeho věk, vzdělání, zaměstnání,
příjem atd.
54
4.4
Data mining
4
Poté, co se, stejně jako u OLAP kostky, uvedou modely do produkce, lze již začít se samotným
„dolováním” dat. Výsledky jsou rozděleny na základě použitých metod pro jejich získání.
Obrázek 21: Struktura data miningového modelu
Decision tree
Tato metoda ma dva různé výstupy, stejnojmenný Decision tree a Dependency network.
• Decision tree - toto schéma zobrazuje hodnoty atributů, které nejvíce ovlivnily nákup zvoleného typu produktu. Je vidět, že v nejvíce případech je nákup ovlivňován pohlavím zákazníků. U domácího kina však má na nákup produktu vliv také věk. Je vidět, že z mužů
mladších 63 let si produkt zakoupilo 292 a nekoupilo 24 a zároveň všichni muži starších 63
let si produkt zakoupili. Podoba tohoto výstupu je zachycena na obrázku 22.
• Dependency network - tento diagram zachycuje atributy z předešlého schématu ovšem
v grafické podobě tak, aby byly jasně vidět jejich vztahy a zároveň jejich síla. Jak již bylo
řečeno, nákup produktů nejvíce ovlivňuje pohlaví, dále pak příjem a věk, který má však
vliv pouze na nákup domácího kina. Co se týče síly jednotlivých vztahů, je možné vidět že
největší vliv má pohlaví zákazníka na nákup digitálního fotoaparátu.
Neural network
Tato metoda počítá konkrétní hodnoty a pravděpodobnosti toho, jak moc dané atributy ovlivňují
koupi produktu. U každého atributu lze vidět, jestli zákazníci s touto vlastností spíše kupují či
nekupují daný produkt. Zároveň je také u obou možností uvedeno dříve definované skóre, které
určuje procento zákazníků odpovídající jedné z možností.
55
4.4
Data mining
4
Obrázek 22: Decision tree - nákup domácího kina
Toto skóre například ukazuje, že všichni zákazníci, kteří jsou povoláním konzultanti, zásadně
nekupují LCD televize, zatímco téměř 30% zákazníků ve věku mezi 15 - 30 lety tento produkt
nakupuje rádo.
Association rules
Tato metoda hledá veškeré závislosti a vztahy mezi jednotlivými atributy. Jejím výsledkem jsou tři
různé výstupy, Rules, Itemsets a Dependency network.
• Rules - zde jsou uvedeny veškeré asociace, které byl tento algoritmus schopen v testovaném souboru nalézt. Výsledkem je tak spojení dvou a více atributů, které mají bud’ velkou
pravděpodobnost společného výskytu, nebo má tento poznatek vysokou důležitost.89
Je vidět, že algoritmus našel velké množství spojení se 100% pravděpodobností výskytu.
Například všichni manažeři, kteří mají dvě děti si kupují digitální fotoaparát, všichni lékaři
s vysokoškolským vzděláním si kupují domácí kino atd. Naopak za nejvíce využitelný poznatek, ovšem jen se 40% pravděpodobností výskytu, tato metoda považuje fakt, že zákazníci,
kteří pracují jako právníci a mají jedno dítě si nekupují ledničku.
• Itemsets - tento výstup zobrazuje nejčastěji se vyskytující hodnoty atributů v testovacím
souboru. Je vidět, že se jedná především o kombinace nákupů různých typů produktů. Naopak nejméně se vyskytující kombinace byla například IT specialista s ukončeným základním
vzděláním, který si pořizuje domácí kino.
• Dependency network - tato metoda zobrazuje všechny zjištěné asociace a jejich sílu v grafické podobě. Asociací je samozřejmě obrovské množství, a tak je nutné ty méně důležité
vyfiltrovat. Tak lze zjistit, že nejsilnější vztah mají konzultanti, ekonomové či zpěváci nakupující hudební komponenty do auta. Tento diagram ilustruje obrázek 23.
89 Tuto hodnotu zobrazuje sloupec importance. V dokumentaci však Microsoft spíše než jako důležitost popisuje tuto
vlastnost jako využitelnost v praxi.
56
4.4
Data mining
4
Obrázek 23: Dependency network
Clustering
Princip tohoto algoritmu spočívá v rozdělení testovaného souboru na určité skupiny dat, clustery.
Do těchto clusterů jsou vkládány pouze objekty, které si jsou něčím podobné, naopak jednotlivé
clustery musí být, pokud možno, co nejodlišnější. Tato metoda má hned několik výstupů.
• Cluster diagram - zde je vidět diagram vztahů mezi jednotlivými clustery. Opět je možné
filtrovat pouze silnější vztahy a tak je vidět, že největší vazba je mezi 8. a 10. clusterem.
• Cluster profiles - toto je hlavní výstup celé metody. Jsou zde graficky znázorněny všechny
zkoumané atributy v závislosti na jednotlivých clusterech. Díky tomuto znázornění je jasně
vidět poměr obsahu atributů s určitou hodnotou v daném clusteru a je tak možné zjišt’ovat,
zda má tato skutečnost nějaký vliv na zkoumané veličiny.
V konkrétním případě si lze všimnout, že ve čtvrtém clusteru jsou takřka výhradně zákazníci, kteří mají vysokoškolské vzdělání. Přesto je vidět, že tento fakt nijak neovlivňuje výši
prodaných produktů. Stejný efekt lze pozorovat i ve třetím clusteru, který je tvořen z 94%
ženami, přesto nelze pozorovat nějakou závislost mezi prodanými kusy produktů.
• Cluster characteristics a Cluster discrimination - v těchto výstupech lze prohlížet obsah
jednotlivých clusterů a zároveň je navzájem porovnávat. V tomto případě neobsahují žádné
nové poznatky.90
90 Další
grafické výstupy data miningových algoritmů jsou uvedeny v příloze 1.
57
4.4
Data mining
4
Kromě konkrétních hodnot vypočítaných na základě výše uvedených metod, lze také ověřit, jak
přesné tyto výpočty byly na základě tzv. lift chart grafu. Tento graf zobrazuje jednotlivé algoritmy
v porovnání s ideálním modelem výpočtu. Tedy takovým modelem, který z testovacího souboru
obsahujícího 50% dat, je schopen určit všechny vztahy a závislosti. Je vidět, že procentuální
úspěšnost použitých algoritmů se pohybovala při tomto obsahu kolem 35%, což se dá označit
za průměrně přesný výpočet.
Dalším výstupem je tzv. prediction. Jedná se o algoritmus, který je schopen určit s jakou
pravděpodobností se v budoucnu naplní zkoumaný jev. V tomto případě bylo zkoumáno, s jakou
pravděpodobností si daný zákazník v budoucnu zakoupí domácí kino či MP3 přehrávač. Tyto
hodnoty se většinou pohybovaly kolem 95%, ovšem lze vidět i výjimky, například zákazník číslo 1
si koupí přenosný přehrávač „pouze” s pravděpodobností 77%.91
91 Výpočet těchto pravděpodobností se nachází v tabulce data_mining_prediction v datovém skladu, nebot’ to byl jediný
způsob, jak vypočítané výsledky uložit.
58
5
5
ZÁVĚR
Závěr
V souvislosti s tím, jak se mění ekonomická situace a jakým způsobem se zvětšuje objem podnikových dat, jsou firmy nuceny využívat stále více informačních systémů na podporu jejich rozhodování. Zároveň vzniká potřeba z firemních dat extrahovat potenciálně využitelné informace
pro rozvoj podniku. Jedním ze systémů, které toto umožňují, je i Business Intelligence a jeho
nezbytná součást, datový sklad.
Tato práce si kladla za cíl jednak ověřit onu nezbytnost datového skladu ve spojení s BI, především pak ale chtěla znázornit veškeré výhody, které z tohoto spojení plynou. Tato problematika
byla rozložena do několika kapitol, kde byla postupně studována.
V první kapitole byly nejprve popsány a porovnány možné přístupy k vytvoření datových
skladů. Bylo zjištěno, že především díky menším finančním nárokům a možnosti budovat datový
sklad postupným způsobem, je v dnešní době upřednostňován spíše přístup Ralpha Kimballa.
Zároveň byl v této kapitole porovnán datový sklad s operační databází a byly určeny jejich výhody a nevýhody s ohledem na využití pro BI. Vzhledem k tomu, že normalizované databáze
jsou koncipovány především pro transakční operace, zatímco datové sklady díky své dimenzionální struktuře umožňují provádění rozsáhlých analytických dotazů ve srozumitelné podobě, bylo
prokázáno, že datový sklad představuje pro BI takřka ideální zdroj.
Ve druhé kapitole byl definován samotný termín Business Intelligence a následně byly rozebrány jeho jednotlivé kategorie. U každé z nich byly uvedeny výhody, které ve spojení s datovým
skladem pro BI vznikají. U reportů bylo zjištěno, že jedině dimenzionální struktura datového skladu
je schopna zaručit jednoduchost, která je základem pro vytváření veškerých reportů, a proto je
v tomto případě využití datového skladu téměř nezbytné. U OLAP analýzy bylo řečeno, že datový
sklad představuje v podstatě jediný možný zdroj, nebot’ i vytvoření MDD musí probíhat z dimenzionálního modelu. Datový sklad je navíc schopen fungovat přímo jako základ pro analytické dotazování, které je v tom případě nazýváno ROLAP. Pro využití datového skladu jako zdroje pro data
mining je, spíše než jeho struktura, důležitý fakt, že obsahuje velké množství historických dat,
které potřebují jednotlivé data miningové metody pro svůj výpočet. Na závěr této kapitoly byly
nastíněny směry, kterými se v současné době vývoj datových skladů a BI ubírá. Byly definovány
pojmy Real-time Business Intelligence a také Data warehousing 2.0, který představuje možného
nástupce pro současnou a v této práci popisovanou generaci datových skladů.
V praktické části byl navrhnut a implementován model datového skladu pro, za tímto účelem
vytvořenou, fiktivní firmu. Následně byl tento datový sklad použit pro vytvoření různých typů reportů. V případě data miningu byl využit jako základ pro studii, která zkoumala možné dopady
vlastností zákazníka na prodej jednotlivých typů produktů za pomoci odlišných metod a algoritmů. V kapitole týkající se OLAP analýzy byla vytvořena multidimenzionální databáze, která byla
poté podrobena sérii analytických dotazů. V této části byl také kladen důraz na použití moderních
aplikací, které jsou v tomto odvětví k dispozici. U BI byl znázorněn posun z komplexních speciali-
59
5
ZÁVĚR
zovaných aplikací až do běžně rozšířených kancelářských programů jakým je například Microsoft
Excel.
Lze tedy říci, že práce splnila to, co si v úvodu předsevzala. Na základě rozebrání struktury
datového skladu a jednotlivých BI kategorií bylo prokázáno, že datový sklad, na rozdíl od operační
databáze, přináší BI velké množství výhod a možností. Bude však zajímavé sledovat vývoj tohoto
odvětví do budoucna, nebot’, jak bylo v práci uvedeno, již nyní jsou známy technologie, které
mají potenciál současnou generaci BI a datových skladů nahradit. Pokud se tak stane, je možné,
že i jejich vzájemný vztah nabere jinou podobu, než jakou má v dnešní době a než jaká byla
demonstrována v této práci.
60
6
6
CONCLUSION
Conclusion
Along with unstable economical situation and increasing number of corporate data, companies are
forced to use more information systems to support their decisions. Also a new need for extracting
potentially valuable information out of the company’s data rises. One of the systems that allows
this is Business Intelligence and its essential part data warehouse.
Aim of this thesis was partly to verify the need of a data warehouse in conjunction with BI,
but mostly to emphasize all the advantages that result from this connection. This subject has
been divided into several chapters, where it has been consequently studied.
In the first chapter possible perspectives of building a data warehouse have been at first described and then compared. It is possible to say that, primarily due to less financial expenditures
and the possibility to build a data warehouse step by step, perspective of Ralph Kimball is slightly more preferable nowadays. Furthemore data warehouse has been in this chapter compared
with an operational database and then all the advantages or disadvantages of both technologies
regarding their usage for BI have been identified. While normalized databases are designed mainly for transactional operations, data warehouses due to their structure allow performing of large
analytical queries in an understandable form and that is why they are also considered to be an
ideal source for BI.
In the second chapter the term Business Intelligence and consequently its relevant categories
have been described. In every one of them all the advantages that result from the connection
with a data warehouse for BI have been identified. In case of reports it has been proven that only
the dimensional structure of a data warehouse is able to guarantee their simplicity and usability.
As these are the most important features for creating any reports, usage of a data warehouse
is almost a necessity. Concerning OLAP analysis it has been mentioned that a data warehouse
represents the only possible source for even the creation of a MDD must be proceeded from
a dimensional model. In addition data warehouse is able to function as a base for analytical
querying which is in that case called ROLAP. For usage of a data warehouse as a source for data
mining is rather than his structure important the fact that it contains large amount of historical
data, which are needed by the particular data mining methods. At the conclusion of this chapter
possible directions of future development of data warehouses and BI have been outlined. Also
terms as Real-time Business Intelligence and Data warehousing 2.0, which presents a potential
successor for contemporary and in this thesis described generation of data warehouses, have
been defined.
In the practical part of this thesis a model of a data warehouse has been designed and implemented. In consequence it has been used as a source for creation of different types of reports.
In case of data mining the model has been used as a base for a study, which has been examining
possible effects of customer characteristics on sales of various types of products using distinc methods and algorithms. In the event of OLAP analysis multidimensional database has been firstly
created and then submitted to a set of analytical queries. There has been an emphasis in this
61
6
CONCLUSION
chapter to use only the modern applications that are available in this discipline. In context of BI
a drift from complex and specialized applications to wide-spread computer programmes such as
Microsoft Excel has been demonstrated.
It is therefore possible to say that this thesis has fulfilled everything that it has resolved in the
introduction. By analyzing the structure of a data warehouse and particular BI categories it has
been proven that data warehouse unlike operational database provides BI many possibilities and
advantages. On the other hand it will be interesting to observe a progression of this segment in future, for as it has been mentioned in the thesis, that technologies with a high potential of replacing
the contemporary generation of BI and data warehouses, are already available. Considering this,
it is possible that even their relationship will obtain a different form than it has nowadays and that
has been demonstrated in this thesis.
62
Reference
[1] KIMBALL, Ralph; ROSS Margy. The Data Warehouse Toolkit: The Complete Guide to Dimensional Modeling. 2nd ed. Wiley Publishing. Canada. 2002. 440 s. ISBN 0-471-20024-7
[2] INMON, William Harvey. Building the Data Warehouse. 3rd ed. Wiley Publishing. Canada.
2002. 412 s. ISBN 0-471-08130-2
[3] RAINARDI, Vincent. Building a Data Warehouse: With Examples in SQL Server. Apress.
United States of America. 2008. 523 s. ISBN 978-1-59059-0
[4] MUNDY, Joy; THORNWAITE, Warren; KIMBALL, Ralph et al. The Microsoft Data Warehouse
Toolkit: With SQL Server 2005 and the Microsoft Business Intelligence Toolset. Wiley Publishing. Canada. 2006. 746 s. ISBN 978-0-471-26715-7
[5] MOSS, Larissa T.; ATRE, Shaku. Business Intelligence Roadmap:The Complete Project Lifecycle for Decision-Support Applications. Pearson Education. Canada. 2003. 543 s. ISBN
0-201-78420-3
[6] LOSHIN, David. Business Intelligence - The Savvy manager’s guide. Getting Onboard with
Emerging IT. Morgan Kaufmann Publishers. United States of America. 2003. 270 s. ISBN
978-1-55860-916-7
[7] BERRY, Michael J.A.; LINOFF, Gordon S. Data Mining Techniques: For Marketing, Sales,
and Customer Relationship Management. 2nd ed. Wiley Publishing. Indianopolis (Indiana).
2004. 643 s. ISBN 0-471-47064-3
[8] LARSON, Brian. Delivering Business Intelligence with Microsoft SQL Server 2008. McGrawHill. 2009. United States of America. 770 s. ISBN 978-0-07-154945-5
[9] ANUPINDI, Nagesh V. Inmon vs. Kimball [online]. 25.8.2005, poslední revize 10.3.2010
[cit. 2010-03-15]. Dostupné z: <http://www.nagesh.com/publications/technology/173-inmonvs-kimball-an-analysis.html>
[10] Data warehouse - Wikipedia, the free encyklopedia [online]. poslední revize 15.3.2010 [cit.
2010-03-16]. Dostupné z: <http://en.wikipedia.org/wiki/Data_warehouse>
[11] Star schema - Wikipedia, the free encyklopedia [online]. poslední revize 15.3.2010 [cit. 201003-16]. Dostupné z: <http://en.wikipedia.org/wiki/Star_schema>
[12] Snowflake schema - Wikipedia, the free encyklopedia [online]. poslední revize 15.3.2010 [cit.
2010-03-16]. Dostupné z: <http://en.wikipedia.org/wiki/Snowflake_schema>
[13] Kimball vs. Inmon...or, How to build a Data Warehouse [online]. 8.8.2006. [cit. 2010-0319]. Dostupné z: <http://it.toolbox.com/blogs/confessions/kimball-vs-inmonor-how-to-build-adata-warehouse-10987>
63
[14] GREENFIELD, Larry. The Data Warehousing Information Center [online]. 1995. poslední
revize 14.1.2010 [cit. 2010-03-19]. Dostupné z: <http://www.dwinfocenter.org/defined.html>
[15] UTLEY, Craig. Designing the Star Schema Database [online]. 1995. Ver. 1.1. poslední revize
17.7.2008 [cit. 2010-03-23]. Dostupné z: <http://ciobriefings.com/Publications/WhitePapers/DesigningtheStarSchemaDatabase/tabid/101/Default.aspx>
[16] FIRESTONE,
The
Data
Joseph
M.
Warehouse
Dimensional
[online].
Modeling
22.6.1998,
[cit.
and
E-R
Modeling
In
2010-03-24].
Dostupné
z:
<http://www.dkms.com/papers/dmerdw.pdf>
[17] KIMBALL,
prise
Ralph.
[online].
Fact
Tables
1.1.2003,
[cit.
and
Dimension
2010-03-25].
Tables
Dostupné
z:
Intelligent
enter-
<http://intelligent-
enterprise.informationweek.com/030101/602warehouse1_1.jhtml>
[18] Online analytical processing - Wikipedia, the free encyklopedia [online]. poslední revize
14.4.2010 [cit. 2010-04-18]. Dostupné z: <http://en.wikipedia.org/wiki/Olap>
[19] Hierarchy - OLAP.com, Your Source to Learn about OLAP [online]. poslední revize 9.3.2009
[cit. 2010-04-19]. Dostupné z: <http://www.olap.com/w/index.php/Hierarchy>
[20] Real-Time Business Intelligence - Gravic [online]. c2010, [cit. 2010-04-22]. Dostupné z:
<http://www.gravic.com/shadowbase/uses/realtimebusinessintelligence.html>
[21] AZVINE,
the
B.;
Adaptive
CUI,
Z.,
Enterprise
et
al.
Real
[online].
Time
[cit.
Business
Intelligence
for
2010-04-22].
Dostupné
z:
<http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.101.194&rep=rep1&type=pdf>
[22] INMON, William H. DW 2.0 - Architecture for the Next Generation of Data Warehousing - Information Management [online]. 04.2006, [cit. 2010-04-22]. Dostupné z:
<http://www.information-management.com/issues/20060401/1051111-1.html>
[23] Data Warehousing Concepts - Oracle [online]. poslední revize 17.5.2004 [cit. 2010-03-15].
Dostupné z: <http://www.stanford.edu/dept/itss/docs/oracle/10g/server.101/b10736/concept.htm>
64
Seznam obrázků
1
Integrovanost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
2
Integrovaný datový sklad podle W.H. Inmona . . . . . . . . . . . . . . . . . . . . .
12
3
Datový sklad podle Ralpha Kimballa . . . . . . . . . . . . . . . . . . . . . . . . . .
14
4
Normalizovaný přístup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
5
Hvězdicové schéma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
6
Vločkové schéma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
7
Multidimenzionální databáze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
8
Slicing a dicing MDD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
9
Produktová hierarchie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
10
Klasifikace
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
11
Asociace - Market basket analysis . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
12
Reprezentace textové analýzy pomocí data miningu . . . . . . . . . . . . . . . . .
36
13
Struktura DW 2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
14
Konceptuální schéma datového skladu . . . . . . . . . . . . . . . . . . . . . . . . .
40
15
Logický model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
16
Fyzický model
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
17
Proces integrace dat do databáze . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
18
Přehled zákazníků . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
19
Přehled týdenních tržeb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
20
Ukázka OLAP analýzy v programu Microsoft Excel . . . . . . . . . . . . . . . . . .
53
21
Struktura data miningového modelu . . . . . . . . . . . . . . . . . . . . . . . . . .
55
22
Decision tree - nákup domácího kina . . . . . . . . . . . . . . . . . . . . . . . . . .
56
23
Dependency network
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
57
24
OLAP analýza - příklad drill up/down funkčnosti . . . . . . . . . . . . . . . . . . . .
I
25
OLAP analýza - příklad sekání datové kostky . . . . . . . . . . . . . . . . . . . . .
II
26
OLAP analýza - ukázka grafických možností v programu Microsoft Excel . . . . . .
III
27
Data mining - Decision trees - Dependency network . . . . . . . . . . . . . . . . .
IV
28
Data mining - Neural network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
V
29
Data mining - Cluster profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
VI
30
Data mining - Lift chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
VII
65
Seznam použitých symbolů a zkratek
BI
Business Intelligence
DSS
Decision Support System
OLAP
Online Analytical Processing
MOLAP
Multidimensional Online Analytical Processing
ROLAP
Relational Online Analytical Processing
HOLAP
Hybrid Online Analytical Processing
OLTP
Online Transaction Processing
MDD
Multidimensional database
DW
2.0 Data Warehousing 2.0
KPI
Key Performance Indicator
ODS
Operational Data Store
CRM
Customer relationship management
RTBI
Real-time Business Intelligence
66
Seznam příloh
• Příloha 1 - Dodatečné výstupy OLAP analýzy a data miningu
• Příloha 2 - CD s výstupy praktické části
67
PŘÍLOHA 1 - Dodatečné výstupy OLAP analýzy a data miningu
Obrázek 24: OLAP analýza - příklad drill up/down funkčnosti
I
Obrázek 25: OLAP analýza - příklad sekání datové kostky
II
Obrázek 26: OLAP analýza - ukázka grafických možností v programu Microsoft Excel
III
Obrázek 27: Data mining - Decision trees - Dependency network
IV
Obrázek 28: Data mining - Neural network
V
Obrázek 29: Data mining - Cluster profiles
VI
Obrázek 30: Data mining - Lift chart
VII
PŘÍLOHA 2 - CD obsahující výstupy praktické části
Obsah přiloženého cd:
/analyza_olap - soubor obsahující výstupy OLAP analýzy
/data_mining1 - složka obsahující soubory týkající se data miningu
/data_warehouse - zálohovaný databázový sklad
/dw - fyzicky - soubor s fyzickým modelem datového skladu
/dw - logicky - soubor s logickým modelem datového skladu
/Multidimensional database - složka obsahující soubory nutné pro vytvoření multidimenzionální
databáze
/pruvodce - soubor s informacemi o instalaci
/Report1 - report s přehledem zákazníků
/Report2 - report s přehledem týdenních tržeb
VIII

Využití datového skladu jako zdroje pro Business

Transkript

Podobné dokumenty

Business Intelligence systémy - Think Together 2016

petr_jasa_datove_sklady

Pr˚uvodce Linuxem

Sociodemografie - soubor

1. PROČ TO VŠECHNO? ......................................................

Magnetic Levitation Control 1 Princip procesu magnetické

využití inteligentních nástrojů pro analýzu technologických dat

celý časopis

pojem “informační management”

Práce s veřejností v nepodnikatelském sektoru

Sociodemografie - soubor

bytové domy

GridSQL a pg-pool II

text kapitoly