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

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áˇrská 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 CJ:

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

ˇ Dekuji vedoucímu bakaláˇrské práce Peterovi Buchlákovi za úˇcinnou metodickou, pedagogickou a odbornou pomoc a další cenné rady pˇri zpracování mé bakaláˇrské práce.

Prohlašuji, že svou bakaláˇrskou práci na téma „Využití datového skladu jako zdroje pro Business Intelligence” jsem vypracoval samostatneˇ pod vedením vedoucího bakaláˇrské práce a s použitím odborné literatury a dalších informaˇcní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áˇrské práce dále prohlašuji, že v souvislosti s vytvoˇrením této bakaláˇrské práce jsem neporušil autorská práva tˇretích osob, zejména jsem nezasáhl nedovoleným zpusobem ˚ do cizích autorských práv osobnostních ˇ a jsem si plneˇ vedom následku˚ porušení ustanovení § 11 a následujícího autorského zákona cˇ . 121/2000 Sb.

ˇ V Praze dne 6. kvetna 2010

Lukáš Král

4

5

Abstrakt Tato bakaláˇrská práce se zabývá datovými sklady a jejich praktickým využitím pomocí Business Intelliˇ jejich vzájemného vztahu gence (BI). Kromeˇ popisu obou technologií je hlavní duraz ˚ kladen na znázornení 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 nejduležit ˚ ejších osobností v oboru, Williama H. Inmona a Ralpha Kimballa, a poté srovnán s operaˇcní databází. Následneˇ se již pozornost pˇresouvá na Business Intelligence. Postupneˇ je zde ˇ možné smery, ˇ rozebrána problematika reportu, ˚ OLAP analýzy a data miningu. V práci jsou také nastíneny 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 funkˇcní model datového skladu. Ten je následneˇ použit jako zdroj pro jednotlivé BI nástroje a jsou tak názorným zpusobem ˚ demonstrovány ruzné ˚ zpusoby ˚ jeho využití.

ˇ Klícová slova ˇ Business Intelligence, datový sklad, data mart, normalizovaný model, dimenzionální model, hvezdicové 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í pˇrí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 Souˇcasné 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 Vytvoˇrení reportu˚ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

47

4.3 Analýza (OLAP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

49

4.4 Data mining . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

54

ˇ 5 Záver

59

6 Conclusion

61

Literatura

63

Seznam obrázku˚

65

Seznam použitých symbolu˚ a zkratek

66

Seznam pˇríloh

67

Pˇríloha 1

I

Pˇríloha 2

VIII

7

1

1

ÚVOD

Úvod

ˇ ˇ Ješteˇ pˇred nekolika lety staˇcily firmám k úspešnému konkurenˇcnímu boji znalosti a zkušenosti ˇ nekolika svých klíˇcových manažeru. ˚ V posledních letech se ale situace zaˇcíná zcela zásadneˇ ˇ ˇ menit. Hlavní podíl na tom má turbulentní a globalizované prostˇredí, které díky neustálým zmeˇ dobe. ˇ Úsudek již nemuže nám nutí organizace k daleko rychlejšímu rozhodování než v dˇrívejší ˚ vycházet ze zkušeností manažeru, ˚ ale musí se opírat o správné informaˇcní podklady. Spolu se ˇ zmenou ekonomického prostˇredí je na firmy vyvíjen tlak také díky nárustu ˚ konkurence cˇ i stále se zvyšujícím požadavkum ˚ zákazníku. ˚ V souvislosti s vývojem informaˇcních technologií zárovenˇ rapidním zpusobem ˚ roste objem podnikových dat, pˇriˇcemž velké množství z nich obsahuje cenné informace, které by se daly vyˇ užít pro rozvoj dané firmy. Otázkou však zustává, ˚ jak tyto informace z nashromáždených dat získat. Není proto divu, že se v posledních letech zaˇcínají prosazovat tzv. decision support systems (DSS), neboli systémy pro podporu rozhodování. Do této kategorie lze zaˇradit i nástroje Business Intelligence (BI) spolu s datovými sklady, které pro BI pˇredstavují jakousi datovou záˇ firmám spravovat svá data a získávat z nich strategické informace kladnu. Tyto systémy umožnují ˇ potˇrebné pro dosažení výhody na trhu a zvýšení šance na úspešný boj v konkurenˇcním prostˇredí. S tím, jak stoupá obliba DSS systému, ˚ se však pozornost pˇresouvá 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ˇ novány nebo se naopak oznaˇcují pouze pomocí termínu Business Intelligence. Cílem této práce je tedy mimo jiné tyto pojmy jasneˇ definovat a popsat. Hlavní duraz ˚ 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 pˇredstavuje onen zdroj uvedený v názvu práce, pˇriˇcemž u každé z nich bude dbáno ˇ na to, aby byla jasneˇ znázornena role datového skladu. V práci také zmíním souˇcasné trendy v oblasti datových skladu˚ a BI nástroju˚ a nastíním jejich vývoj do budoucna. Kromeˇ teoretického ˇ využití datových skladu˚ ve spojení s BI se pokusím tento vztah demonstrovat také na znázornení praktické ukázce. ˇ V souvislosti s výše uvedenými cíly je práce rozdelena do dvou cˇ ástí, teoretické a praktické, pˇriˇcemž teoretická cˇ ást dále obsahuje dveˇ kapitoly. V té první popisuji technologii datových skladu˚ ˇ z pohledu dvou nejvýznamnejších osobností pusobících ˚ v tomto oboru, Williama H. Inmona a Ralpha Kimballa. Jsou zde uvedeny rozdíly i výhody a nevýhody obou pˇrístupu. ˚ Zárovenˇ zde porovnávám datový sklad s operaˇcní databází, jako dalším možným zdrojem pro BI. ˇ rím na popis V druhé kapitole nejdˇríve definuji, co je to Business Intelligence, a poté se již zameˇ ˇ jeho jednotlivých kategorií. Postupneˇ se budu venovat reportum, ˚ OLAP analýze a data miningu. ˇ Dále budou v této kapitole znázorneny jednotlivé výhody cˇ i možnosti, které spojení s datovými

8

1

ÚVOD

ˇ ˇ ješteˇ nastíním možnosti dalšího vývoje techto ˇ sklady BI umožnuje. V záveru systému. ˚ Druhou cˇ ást této práce tvoˇrí praktická ukázka. Jejím cílem je nejprve vytvoˇrit fungující model ˇ poté s pomocí BI nástroju˚ demonstrovat možnosti jeho využití. Stejneˇ datového skladu a na nem ˇ rím na reporty, OLAP analýzu a data mining. tak jako v teoretické cˇ ásti, i zde se zameˇ

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 ˇ eˇ dobˇre naznaˇcuje, cˇ ím se tato kapitola zabývá. V první cˇ ásti je vysvetˇ Úvodní citace pomern ˇ len pojem datový sklad a to z pohledu dvou nejznámejších osobností v tomto oboru, Williama H. ˇ také porovnány. Inmona a Ralpha Kimballa. Oba pˇrístupy jsou zde podrobneˇ popsány a vzápetí ˇ Druhá cˇ ást se venuje vztahu mezi dimenzionálním modelem, který tvoˇrí základní strukturu daˇ tového skladu, a normalizovaným modelem, který je pro zmenu 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á, nemenná 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ýznamnejšího cˇ initele v tomto oboru Ralpha Kimballa4 , považuji za duležité ˚ se nyní jednotlivým požadavˇ ˇ kum ˚ uvedených v pˇredchozí definici venovat podrobneji. ˇ • Subjektová orientace - datový sklad obsahuje data, která se týkají vlastního pˇredmetu 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 pˇríklad uvádí pojišt’ovací firmu, ˇ jejíž aplikace mohou být auto, nehoda atd. Hlavním pˇredmetem zájmu organizace je však ˇ zákazník, odmena cˇ i nárok na pojistné. • Integrovanost - tato vlastnost souvisí s tím, že do datového skladu mohou vstupovat data z ruzných ˚ nesourodých cˇ ástí podnikového systému. Proto musí být nejprve zformátována do ucelené podoby - napˇr. všechny jednotky délky jsou pˇrevedeny na cm atd. Ze všech aspektu˚ ˇ datového skladu je práveˇ tento nejduležit ˚ ejší. Obrázek 1 ilustruje pˇrevod 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: 3 INMON, William Harvey. Building the Data Warehouse. 3rd ed. Wiley Publishing. Canada. 2002. str. 31 4 Jeho definici a struktuˇre datového skladu se venuje ˇ 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


pipeline—cm pipeline—inches pipeline—mcf pipeline—yds


description description description description


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, the wareˇ • Nízká promencoding enlivost data is se,concerned, na rozdílit od provozních systém ˚ inkde mohou být libovolneˇ house is encoded as m/f or 1/0 . What does matter is that regardless of method

ˇ ena, ˇ men 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

ˇ same consideration ˇ probíhá vetšinou po vetších a pˇ redstavuje tak jakýsi snímek datové ofdávkách 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 pˇresná práveˇ k tomuto bodu. Pokud se objeví nejaká characteristics of data. ˇ zmena, je místo modifikace již uložených dat,warehouse vytvoˇrenis 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 pˇredem stanovené accessed and manipulated one record at a time. Data is updated in the aktualizaˇcníoperational strategie.environment as a regular matter of course, but data warehouse data • Trvalost uložení dat (historizace) - jak již bylo uvedeno dˇríve, data se v datových skladech ˇ nepˇrepisují ani neodstranují, jsou statická a urˇcená pouze pro cˇ tení. Díky tomu, že jsou ˇ eˇ naˇcítána z provozních systému˚ (kde jsou vždy obsažena pouze aktuální data), prub ˚ ežn je vytváˇrena 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ˇ ˚ ci euru, zatímco ˇ letech. Díky tomu v datovém skladu budou uloženy všechny jeho hodnoty v posledních peti muže ˚ datový sklad daleko lépe sloužit pro rozsáhlé analytické dotazy. ˇ Kromeˇ techto pojmu˚ se v definici také vyskytuje termín granulární data. Co je to granularita, ˇ vysvetluje 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 pˇrí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

ˇ ˇ rí, že obsah datového skladu všech transakcí za mesíc má naopak granularitu velkou.6 Inmon veˇ ˇ být granulární (zrnitý) co nejvíce.7 by mel 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 pˇrístupu, který spoˇcívá ve vytvoˇrení 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 doporuˇcuje nejprve vytvoˇrit centralizovaný datový sklad v rámci celého podniku a až poté zaˇcít budovat satelitní databáze, které budou pˇrizpusobeny ˚ potˇrebám jednotliˇ ˇ Tyto databáze nazýváme data marty nebo také „datovými tržišti”. vých oddelení ve firme. Odlišné je i pojetí struktury dat. Inmon navrhuje, aby byl centrální datový sklad vytvoˇren v norˇ odvozené data marty, obsahující data pro specifický busimalizovaném datovém modelu a z nej ness proces, byly vytvoˇreny za pomoci dimenzionálního pˇrístupu. 10 Normalizovaný datový model mužeme ˚ chápat jako entitneˇ relaˇcní 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é z: 8 Data warehouse - Wikipedia, the free encyklopedia [online]. poslední revize 15.3.2010 [cit. 2010-03-16]. Dostupné z: 9 Kimball vs. Inmon...or, How to build a Data Warehouse [online]. 8.8.2006. [cit. 2010-03-19]. Dostupné z: 10 Data warehouse - Wikipedia, the free encyklopedia [online]. poslední revize 15.3.2010 [cit. 2010-03-16]. Dostupné z: 11 Blíže se vysvetlení ˇ ˇ normalizovanému modelu venuje kapitola 2.3. 7 ANUPINDI,

12

2.2

Charakteristika datového skladu podle Ralpha Kimballa

2

DATOVÉ SKLADY

Výhody i nevýhody pˇrímo vyplývají jak z definice datového skladu, tak i z jeho schématu zachyˇ ceném na obrázku. Zˇrejmeˇ nejvetší výhodou tohoto modelu je možnost relativneˇ jednoduchého a rychlého vytvoˇrení jednotlivých data martu. ˚ S tím je navíc spojen fakt, že data marty zustávají ˚ ˇ velmi konzistentní, což je samozˇrejmeˇ zapˇríˇcineno tím, že jsou generovány z jednotného datového skladu. Za druhou velkou výhodu lze oznaˇcit jednodušší naˇcítací proces dat z provozních ˇ fakt, že data jsou ukládána do stejného centrálního datového systému. ˚ Hlavním duvodem ˚ je opet skladu. ˇ nevýhody lze považovat složitou a mnohdy i velmi nákladnou realizaci toNaopak za nejvetší hoto modelu. Samotná implementace je navíc cˇ asoveˇ nároˇcná, 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 pˇri budoˇ se odvozují jednotlivé data vání datového skladu nejdˇríve vytvoˇríme centrální úložišteˇ a až z nej marty. ˇ Je nutné dodat, že na tato negativní fakta upozornuje William H. Inmon ve své knize v kapitole ˇ nazvané „Day 1-Day n Phenomenon”. Zde vysvetluje, že datový sklad není vytvoˇren najednou, ˇ data ukládají postupneˇ a tím pádem jsou spíše evoluˇcní než-li revoluˇcní.12 Tím ale že se do nej ˇ rí autoˇri kritizovali.13 Na druhou stranu se se snaží popˇrít tzv. „big bang” pˇrístup, za který ho nekteˇ však lze domnívat, že i pˇresto se dˇríve popsané problémy nepodaˇrí úplným zpusobem ˚ eliminovat.

2.2


ˇ osobou v této oblasti je bezesporu Ralph Kimball. Jako první definoval konDruhou nejduležit ˚ ejší cept data martu˚ a popsal využití dimenzionálního modelování vˇcetneˇ „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 ˇ eˇ Vzhledem k tomu, že se názory na budování datového skladu obou jeho zakladatelu˚ pomern ˇ hodneˇ odlišují, venuje se tato kapitola také pˇrí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 ˇ že definice je daleko jednodušší a srozumitelnejší ˇ než u jeho pˇredchudce. Je videt, ˚ Pˇresto se ˇ vysvetlení. ˇ však domnívám, že vyžaduje dukladn ˚ ejší 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 Nagesh V. Inmon vs. Kimball [online]. 25.8.2005, poslední revize 10.3.2010 [cit. 2010-03-15]. Dostupné z: 14 V c ˇ eském jazyce mluvíme o schématech hvezdy ˇ ˇ a vloˇcky. Oba termíny jsou vysvetleny v následující kapitole. 15 ANUPINDI, Nagesh V. Inmon vs. Kimball [online]. 25.8.2005, poslední revize 10.3.2010 [cit. 2010-03-15]. Dostupné z: 16 GREENFIELD, Larry. The Data Warehousing Information Center [online]. 1995. poslední revize 14.1.2010 [cit. 201003-19]. Dostupné z: 17 KIMBALL, Ralph; ROSS Margy. The Data Warehouse Toolkit: The Complete Guide to Dimensional Modeling. 2nd ed. Wiley Publishing. Canada. 2002. str. 7-16 13 ANUPINDI,

13

2.2


2

DATOVÉ SKLADY

ˇ obsahovat cˇ tyˇri samostatné a odlišné komponenty: Jak ukazuje obrázek 3, datový sklad by mel 1. Operational source systems (provozní systémy) 2. Data staging area 3. Data presentation area 4. Data access tools (nástroje pro pˇrístup k datum) ˚

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 duležité ˚ si uvedomit, že v podstateˇ nejsou souˇcá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 tvoˇreny samostatnými aplikacemi, které nejsou optimalizovány ˇ ˇ na sdílení bežných dat mezi sebou, což vývoj datového skladu znaˇcneˇ ztežuje. Data staging area Za tuto oblast mužeme ˚ oznaˇcit 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) procesum.Ty ˚ ˇ firmám získat data z ruzných umožnují ˚ zdroju, ˚ následneˇ je pˇreformátovat cˇ i oˇcistit a nakonec je ˇ naˇcí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 porozumení zdrojových dat a jejich kopírování do data staging area za úˇcelem další manipulace. ˇ ˇ Jak již bylo ˇreˇceno, extrakce vetšinou probíhá z nekolika ruzných ˚ provozních systému, ˚ a tak jsou získaná data cˇ asto nesourodá. Proto musí následovat fáze transformace dat. Její souˇcástí je napˇríklad oˇcišt’ování dat (oprava pravopisných chyb, pˇrevod do standardního formátu), kombinoˇ vání dat z ruzných ˚ zdroju, ˚ de-duplikování dat a pˇridelování databázových klíˇcu. ˚ Posledním krokem ETL procesu je naˇcítání dat do data presentation area. Tato fáze se liší podle toho, do jakého systému jsou data naˇcítána. Pokud se jedná o provozní databázi cˇ i jiný norˇ malizovaný systém, jsou data vetšinou pˇrepsána, jedná-li se však o datový sklad, jsou neaktuální data zachována jako historická. Klíˇcovým požadavkem na tuto komponentu je, že musí být skryta pˇred koncovým uživatelem a nesmí být používána k poskytování dotazovacích cˇ i prezentaˇcních služeb. Data presentation area ˇ V data presentation area dochází k organizaci, uchovávání a zpˇrístupnování dat pro pˇrímé dotaˇ ˇ zování uživateli cˇ i analytickými aplikacemi. Tato oblast je vetšinou tvoˇrena nekolika 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 zpˇrístupˇ v dimenzionálním schématu. Dimenzionální model sice obsahuje stejné informace jako monena ˇ aby byly srozumitelné, vhodné pro dotazování a odolné del normalizovaný, ale v takové podobe, 18 ˇ vuˇ ˚ ci zmenám.

Dalším duležitým ˚ prvkem je, že data marty musí obsahovat atomická data, tedy data s nejnižší úrovní detailu. Atomická data jsou nezbytná kvuli ˚ odolnosti datového skladu vuˇ ˚ ci náporu nepˇredvídatelných uživatelských dotazu. ˚ Data marty mohou také obsahovat sumarizovaná nebo agregovaná data za úˇcelem zrychlení výkonu. Všechna datová tržišteˇ se musí skládat ze spoleˇcný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ˇ duležitý, ˚ nebot’ reálný systém v praxi se muže ˚ skládat i z více než 20 ruzných ˚ data martu, ˚ a proto je jejich integrace za pomocí bus architektury nezbytná. Na tomto principu je v podstateˇ založen celý pˇrístup a pohled Ralpha Kimballa na vývoj datových skladu. ˚ Nástroje pro pˇrístup k datum ˚ Poslední z hlavních komponent datového skladu jsou nástroje pro pˇrístup k datum. ˚ Termín se vztahuje ke všem schopnostem, které mohou být poskytnuty koncovým uživatelum ˚ na analytic18 Co

ˇ je to dimenzionální a normalizované schéma bude vysvetleno v následující kapitolách. ˇ jsou vysvetleny v kapitole zabívající se dimenzionálním a normalizovaným pˇrí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 samozˇrejmeˇ hlavní cíl a myšlenka datového skladu. Nástroj pro pˇrístup k datum ˚ muže ˚ být tˇreba jednoduchý dotaz stejneˇ tak jako složitá aplikace pro dolování dat. Jako souˇcásti datového skladu lze oznaˇcit i tzv. metadata nebo také „operational data store” (ODS)21 , které se ovšem nepoˇcítají mezi jeho hlavní komponenty. Za metadata lze považovat vše z prostˇredí datových skladu, ˚ co nejsou data samotná. ODS pˇredstavuje zvláštní databázi, která cˇ asto integruje data z více zdroju, ˚ a proto se také využívá za úˇcelem provozního reportoˇ vání. Casto se umíst’uje mezi datový sklad a provozní systém. Podle Kimballova pˇrístupu by tedy ˇ mohl být ODS mezi data staging area a data presentation area. Druhým uplatnením je pro sklad provozních dat oblast CRM (Customer Relationship Management) systému. ˚ Jak již bylo ˇreˇceno, datový sklad podle Ralpha Kimballa je založen na bus architektuˇre. Tu ve své knize definuje jako spoleˇcnou strukturu, do které se vše zapojuje a ze které vše cˇ erpá ˇ 22 energii. Architektura je zárovenˇ nezávislá na technologii a databázové platforme. Kimball se však neliší pouze v architektuˇre datových skladu, ˚ ale také v pˇrí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 doporuˇcuje zaˇcít s vytváˇrením data martu˚ pro jednotlivé podnikové oddelení, ˇ bus architektury. Proto se také tento pˇrístup nazývá které se následneˇ spojí za pomocí již zmínené „bottom-up”.24 Eventuálneˇ muže ˚ poté dojít ke slouˇcení datových tržišt’ dohromady a vytvoˇrení ˇ na jednom cˇ i nekolika ˇ jednoho datového skladu. V praxi mohou být jednotlivé data marty umísteny jiných serverech v rámci celého podniku, zatímco datový sklad muže ˚ být pouze virtuální entitou, která sluˇcuje všechny data marty dohromady. Proto lze tvrdit, že, co se týˇce architektury datových skladu, ˚ tento model nabízí velmi dobrý kompromis mezi centralizovaným a decentralizovaným pˇrístupem. ˇ Nejvetší výhodou oproti Inmonoveˇ pˇrístupu je ale bezesporu možnost rychlého inkrementálního vývoje, díky kterému se požadované výsledky dostaví daleko dˇríve než u implementace centralizovaného datového skladu. Kromeˇ toho je také vývoj méneˇ nákladný. ˇ poˇcet rozhraní mezi produkˇcními systémy a data marty Naopak za nevýhodu lze oznaˇcit vetší ˇ integraci jednotlivých datových tržišt’. Oba dva faktory mají za následek stejneˇ tak jako složitejší zvýšení nároku˚ na správu datového skladu. Vzhledem k tomu, že jsou data marty pˇrímo odvozeny ˇ ˇ lze se také z jednotlivých podnikových oddelení a nevycházejí ze spoleˇcného datového úložište, domnívat, že bude docházet k urˇcité redundanci dat. 21 Lze

pˇreložit jako sklad provozních dat. Ralph; ROSS Margy. The Data Warehouse Toolkit: The Complete Guide to Dimensional Modeling. 2nd ed. Wiley Publishing. Canada. 2002. str. 78-79 23 Kimball vs. Inmon...or, How to build a Data Warehouse [online]. 8.8.2006. [cit. 2010-03-19]. Dostupné z: 24 ANUPINDI, Nagesh V. Inmon vs. Kimball [online]. 25.8.2005, poslední revize 10.3.2010 [cit. 2010-03-15]. Dostupné z: 22 KIMBALL,

16

2.3

Normalizovaný a dimenzionální pˇrí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 pˇredstavitelu˚ v tomto oboru, Williama H. Inmona a Ralpha Kimballa. Byly uvedeny rozdílné pˇrístupy k výstavbeˇ datových skladu˚ i k jejich architektuˇre 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 pˇrístup za jednoznaˇcneˇ lepší cˇ i výhodnejší. Z historického hlediska má jisteˇ navrch filozofie Williama Inmona, nebot’ práveˇ on byl tím, kdo ˇr jako vubec ˚ první termín datový sklad definoval. Není proto divu, že se v 90. letech používal témeˇ výhradneˇ tento pˇrístup. V následujících letech se ale zaˇcala prosazovat Kimballova teorie. Zvlášteˇ pro malé cˇ i stˇrední firmy pˇredstavovala daleko jednodušší a méneˇ nákladný zpusob, ˚ jak do svého podniku datový sklad zaˇclenit.25 Lze usuzovat, že práveˇ díky snazší implementaci a menším nákladum ˚ je i v dnešní dobeˇ ˇ ˇ využíván pˇrístup Ralpha Kimballa. Tyto dva faktory jsou navíc ješteˇ umocneny ˇ o neco cˇ asteji souˇcasnou ekonomickou situací, kdy si žádná organizace nemuže ˚ dovolit vkládat velké cˇ ástky ˇ do dlouhotrvajících a pˇredem nejistých projektu. penez ˚ ˇ je však nutné ˇríci, že cílem není vybrat si jeden pˇrístup, podle kterého se pak budoucí Na záver ˇ je ujasnit si potˇreby a požadavky, které podnik vývoj datového skladu bude ˇrídit. Daleko duležit ˚ ejší k vytvoˇrení datového skladu vedou a pˇredevším soustˇredit se na jeho obsah a kvalitu dat. To, jestli se výsledné ˇrešení bude více podobat jednomu cˇ i druhému pˇrístupu, lze ponechat víceméneˇ ˇ náhode.

2.3


ˇ ˇ V pˇredchozích kapitolách byl nekolikrát zminován normalizovaný a dimenzionální pˇrístup, pˇríˇ padneˇ schéma cˇ i modelování. V této kapitole jsou všechny tyto pojmy vysvetleny a zárovenˇ jsou urˇceny výhody a nevýhody obou pˇrístupu˚ s ohledem na jejich využití jako zdroje pro BI. Normalizovaný pˇrí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í oznaˇcit jedním slovem jako transakce.26 ˇ Normalizace je proces, pˇri kterém dochází k odstranování redundantních dat za pomoci norˇ ruzných malizaˇcních pravidel27 . Rozlišuje se pet ˚ úrovní tzv. normálních forem, pˇriˇcemž za normaˇ lizovaný systém lze oznaˇcit systém, který splnuje tˇretí normální formu (3NF). Proces normalizace ˇ ˇ vede vetšinou k tomu, že jediná transakce je uložena v nekolika rozdílných databázových tabulkách. 25 ANUPINDI,

Nagesh V. Inmon vs. Kimball [online]. 25.8.2005, poslední revize 10.3.2010 [cit. 2010-03-15]. Dostupné z: 26 Proto se také mužeme ˚ setkat s pojmem OLTP (online transaction processing) systémy. V souvislosti s datovými sklady ˇ termín operaˇcní databáze. je však cˇ astejší 27 Normalizaˇ cní 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ý pˇrístup

Zdroj: Rainardi. Building a Data Warehouse. str. 9. Vlastní úprava

ˇ ˇ používány Vzhledem k optimalizaci techto systému˚ pro transakˇcní spracování jsou nejˇcasteji ˇ k integraci dat z nekolika rozdílných zdroju. ˚ 28 Proto je v souvislosti s datovými sklady normalizovaný pˇrístup využit v pˇrípadeˇ ODS nebo u Inmonova centralizovaného ˇrešení.29 Snížení redundance dat má za následek také snížení celkové velikosti normalizovaných systému. ˚ ˇ Naopak nejvetší nevýhodou tohoto pˇrístupu je jeho pomalá odezva pˇri rozsáhlých analytických dotazech. To je zpusobeno ˚ nevhodnou strukturou a dodržováním normalizaˇcních pravidel. Databáze pak musí za úˇcelem dosažení výsledku dotazu spojovat velké množství tabulek, což je samozˇrejmeˇ daleko méneˇ efektivní než cˇ íst data z jedné i když velmi obsáhlé tabulky. Dalším ˇ velkým nedostatkem normalizovaného pˇrí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: 29 RAINARDI,

18

2.3


2

DATOVÉ SKLADY

Dimenzionální pˇrístup Dimenzionální pˇrístup nebo modelování je technika, která je urˇcena pro optimalizaci databází za úˇcelem 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 (ˇci tabulek) a s nimi pˇridružeˇ být v normalizovaném ných dimenzí. Každá faktová tabulka by pˇritom podle Ralpha Kimballa mela ˇ zatímco dimenze v denormalizovaném stavu.32 Denormalizovaná (typicky v tˇretí normální forme) databáze je databáze s urˇcitý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 vyjadˇruje urˇcitou míru cˇ i hodnotu. Tyto míry by mely být vyjádˇreny v cˇ íselné podobeˇ tak, aby mohly kvantifikovat rozsah analyzované události jako napˇr. poˇcet 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í, ˇ být navrhovány na nejnižší úrovni detailu, která je možná, tedy že faktové tabulky by mely za pomoci atomických dat. Atomické faktové tabulky poskytují možnost jak data v budoucnu ˇ ˇríká agregace. Kimball dále uvádí, libovolneˇ sumarizovat. Takto upraveným datum ˚ se nekdy ˇ být na stejné úrovni granularity, jinak by se mohly stát že všechny faktové tabulky by mely velmi nepˇrehledné. • Jak již bylo ˇreˇceno, klade se u faktových tabulek velký duraz ˚ na to, aby hodnoty v nich uveˇ Na tomto základeˇ se rozlišuje nekolik ˇ ˇ dené byly vyjádˇreny cˇ íselne. typu˚ dat. Vetšina jich je tzv. aditivní (napˇr. tržby, zisk), což znamená, že se dají navzájem sˇcítat napˇríˇc všemi dimenzemi. Tato vlastnost je velmi duležitá, ˚ nebot’ Business Intelligence aplikace jen zˇrídkakdy ˇ naˇcítají data z jedné faktové tabulky. Vetšinou se jedná o stovky až tisíce záznamu˚ napˇríˇc celým systémem. Další hodnoty mohou být tzv. semi-aditivní a neaditivní. Semi-aditivní mohou být pˇridávány pouze k urˇcitým dimenzím (napˇr. podíl na trhu) zatímco neaditivní hodnoty nemohou být pˇriˇcteny nikam (jednotková cena).34 ˇ • Co se týˇce poˇctu sloupcu˚ jsou faktové tabulky velmi malé, avšak obsahují vetš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: 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 34 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-43

19

2.3


2

DATOVÉ SKLADY

Dimenze • Dimenzionální tabulky jsou nedílným spoleˇcníkem faktových tabulek. Na rozdíl od nich obsahují dimenze textové popisy podniku.35 Dimenze si lze pˇredstavit jako podstatná jména datového skladu, zatímco faktové tabulky pˇredstavují slovesa nebo podnikové procesy, kterých se dimenze úˇcastní. 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íˇcovým prvkem pro vytvoˇrení srozumitelného datového skladu. Robustní dimenzionální atributy zárovenˇ poskytují také možnost rozsáhlého analytického dotazování. • V dobˇre navrhnutém dimenzionálním modelu mají jednotlivé tabulky velký poˇcet atributu, ˚ ˇ eˇ malé a nevýjimkou nejsou ani tabulky obsahující 100 sloupcu. ˚ I pˇresto jsou ale pomern zabí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živatelum. ˚ Dimenzionální pˇrístup umožnuje splnovat základní cíle datového skladu a tím i BI: • prezentovat uživatelum ˚ potˇrebné informace tím nejjednodušším zpusobem ˚ • reagovat na uživatelské dotazy co nejrychleji • poskytovat relevantní informace, které vystihují základní podnikové procesy ˇ tak, že dimenzionální model obsahuje daleko méneˇ databázových tabulek První bod lze vysvetlit než model normalizovaný. Informace jsou navíc spojeny do souvisejících podnikových kategorií, ˇ lépe orientují.37 což má za následek to, že systém je mnohem jednodušší a uživatelé se v nem Jednoduchost dimenzionálního modelu pˇrináší také výkonnostní benefity. Databáze mohou ˇ díky nižší potˇrebeˇ spojovat jednotlivé tabulky. Uživatato schémata procházet daleko efektivneji telské dotazy tak v porovnání s normalizovaným pˇrístupem trvají daleko kratší dobu.38 I pˇresto, ž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í struktuˇre. Jedineˇ ta, jak již bylo zmíneno, umožnuje vytváˇrení rozsáhlých analytických dotazu, ˚ na jejichž funkci je princip BI založen. 35 KIMBALL, Ralph; ROSS Margy. The Data Warehouse Toolkit: The Complete Guide to Dimensional Modeling. 2nd ed. Wiley Publishing. Canada. 2002. str. 18-19 36 KIMBALL, Ralph; ROSS Margy. The Data Warehouse Toolkit: The Complete Guide to Dimensional Modeling. 2nd ed. Wiley Publishing. Canada. 2002. str. 19-21 37 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. 40-41 38 KIMBALL, Ralph; ROSS Margy. The Data Warehouse Toolkit: The Complete Guide to Dimensional Modeling. 2nd ed. Wiley Publishing. Canada. 2002. str. 22

20

2.3


2

DATOVÉ SKLADY

ˇ Hvezdicové schéma Dimenzionální datový sklad muže ˚ být výsledneˇ implementován pomocí dvou ruzných ˚ schémat.39 ˇ Tím prvním je schéma hvezdy. Podle Ralpha Kimballa se jedná o model, který se skládá z centrální faktové tabulky (nebo tabulek) a k ní pˇripojených dimenzí. ˇ Všechny faktové tabulky se skládají z nekolika cizích klíˇcu, ˚ které se pˇripojují k primárním ˇ klíˇcum ˚ dimenzí. Velký duraz ˚ se klade na to, aby každý cizí klíˇc uvedený ve faktové tabulce mel ˇ svuj ˚ unikátní primární klíˇc v pˇríslušné dimenzi. Tento návrh umožnuje, aby se v dimenzionálních tabulkách vyskytovaly primární klíˇce, které nejsou uvedeny ve faktové tabulce. V reálné situaci to muže ˚ znamenat napˇríklad to, že dimenze produktu muže ˚ být spojena s faktovou tabulkou prodeje, ˇ ve které se však ješteˇ nejaké produkty vubec ˚ neprodaly, což je ale naprosto v souladu s principem zachování integrity a pravidel dimenzionálního modelování.40 ˇ Vzhled hvezdicového schématu demonstruje obrázek 5. ˇ Obrázek 5: Hvezdicové schéma

Zdroj: http://en.wikipedia.org/wiki/File:Star-schema-example.png. Vlastní úprava

ˇ Vlockové schéma ˇ Schéma vloˇcky vychází z hvezdicové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í nekteré analytické aplikace ˇ ˇ s tímto modelem lépe než s hvezdicovým schématem. Jako výhody jsou v tomto pˇrípadeˇ uvádeny menší míra redundance dat a tím pádem i menší celková velikost.41 Ralph Kimball má však na vloˇckové schéma jiný pohled. Ve své knize tvrdí, že vloˇckové 39 Možností

ˇ ˇ je více, v této práci ale pracuji pouze se dvema nejduležit ˚ ejšími. Ralph. Fact Tables and Dimension Tables - Intelligent enterprise [online]. 1.1.2003, [cit. 2010-03-25]. Dostupné z: 41 RAINARDI, Vincent. Building a Data Warehouse: With Examples in SQL Server. Apress. United States of America. 2008. str. 7 40 KIMBALL,

21

2.3


2

DATOVÉ SKLADY

ˇ schéma vede k vetší 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ˇ zbyteˇcné pˇrecházet na normalizované schéma.43 Na obrázku 6 jsou zobrazeny stejné faktové tabulky a dimenze jako v obrázku pˇredchozím, nyní ovšem ve vloˇckovém schématu. Obrázek 6: Vloˇckové schéma

Zdroj: http://en.wikipedia.org/wiki/File:Snowflake-schema-example.png. Vlastní úprava 42 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. 58 43 KIMBALL, Ralph; ROSS Margy. The Data Warehouse Toolkit: The Complete Guide to Dimensional Modeling. 2nd ed. Wiley Publishing. Canada. 2002. str. 21

22

3

3

BUSINESS INTELLIGENCE

Business Intelligence

V pˇredchozí kapitole byl pˇredstaven datový sklad jako dimenzionální databáze. Ovšem úˇcel datového skladu nespoˇcívá v ukládání dat, nýbrž v jejich získávání a prezentování, a to takovým ˇ zpusobem, ˚ aby byla srozumitelná a pˇrinášela uživatelum ˚ nejakou pˇridanou hodnotu. Toho lze dosáhnout v pˇrípadeˇ spojení datového skladu s Business Intelligence. Proto se tato kapitola zabývá zpusoby ˚ prezentace dat, kterých jsou BI nástroje díky datovým skladum ˚ schopné. Zárovenˇ zde ˇ této bude kladen velký duraz ˚ na zobrazení výhod, které z tohoto spojení pro BI plynou. V záveru ˇ souˇcasné trendy ve vývoji obou zminovaných ˇ kapitoly budou nastíneny systému. ˚ ˇ Ješteˇ než budou vysvetleny jednotlivé typy BI, je nutné definovat samotný pojem. Data Wareˇ housing Institute, poskytovatel vzdelá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 duležité ˚ faktory: • BI pˇredstavuje víc než jen soubor nástroju. ˚ Bez pˇrí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 svuj ˚ význam. ˇ ˇ V souvislosti s temito definicemi však dochází k zameˇ nování pojmu˚ data, informace a znalosti. ˇ Proto jsou zde tyto pojmy vysvetleny: ˇ • Data jsou kolekcí prvotních, nezpracovaných hodnot, které jsou používány pro výpoˇcet meˇrení cˇ i ruzný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 urˇcitý smysl cˇ i význam. ˇ informací založený na urˇritých vzorech takovým zpusobem, • Znalost je proces porozumení ˚ aby došlo k pochopení jejich podstaty.44 ˇ eˇ striktneˇ zameˇ ˇ ruje na podstatu BI a kromeˇ zmínky o datových skladech Tato definice se pomern vubec ˚ nevyjadˇruje, jakým zpusobem ˚ spolu tato dveˇ témata souvisí. Vzhledem k pojetí a cíli této ˇ práce je tak princip BI daleko lépe vysvetlen 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 úˇcelem vytváˇrení 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 puvodn ˚ eˇ odkazoval na strukturovanou vrstvu pro pˇrístup k datum ˚ nacházející se mezi uživateli a datovým skladem. ˇ pˇrímo nesouvisející s datovým sklaZ toho plyne, že BI bylo popisováno jako samostatné odvetví dem. Pˇrestože je teoreticky možné využívat BI aplikace bez datových skladu, ˚ ve skuteˇcnosti se to stává jen zˇrídkakdy. Dobˇre navržený datový sklad totiž díky dimenzionálnímu modelu a ETL procesu pˇridává datum ˚ takovou hodnotu, že je naprosto zbyteˇcné vynakládat tuto snahu za úˇcelem ˇ ˇ vytvoˇrení pouze samostatné BI aplikace. Vetšina z techto aplikací jsou navíc nedílnou souˇcá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 zaˇcátku do konce budovány s tím, ˇ být do firmy zavádeny ˇ pouze za pˇredže budou sloužit jako zdroj dat pro BI, by i BI nástroje mely pokladu, že dojde k vybudování datového skladu. BI aplikace pˇredstavují pˇrímé využití pro datové sklady, nebot’ s provozními databázemi by nikdy podniku nepˇrinesly takovou pˇridanou hodnotu. Pˇrínosy datového skladu pro jednotlivé cˇ ásti BI jsou uvedeny v následujících kapitolách. ˇ do dvou základních kategorií. Temi ˇ Business Intelligence nástroje lze rozdelit jsou reporty a analytické aplikace, do kterých dále spadá analýza, data mining, text mining, pˇrehledové zobraˇ rení venuji ˇ zení atd. V této práci se však z hlediska jejího zameˇ pˇredevším reportum, ˚ analýze a ˇ ˇ technologie text mining.46 data miningu, v cˇ ásti venující se souˇcasnému vývoji bude pak zmínena

3.1

Reporty

V tomto kontextu je report program, který získává data z datového skladu a prezentuje je uživatelum ˚ na obrazovce cˇ i na papíru. Uživatelé také mohou tyto reporty pˇrijímat automaticky tˇreba ˇ pomocí e-mailu po urˇcité dobeˇ (den, týden atd.) nebo v závislosti na nejakou událost. Reporty se ˇ získávají z datových skladu, nejˇcasteji ˚ mohou však pracovat i s normalizovanou relaˇcní databází cˇ i dokonce s multidimenzionální databází.47 ˇ nejzákladnejšími ˇ ˇ Reporty jsou temi nástroji Business Intelligence spektra. Jedná se o vetšinou relativneˇ jednoduché výkazy, které se dají parametrizovat, a které mají již pˇredem definovaný formát. Lze se ale setkat i s automatickými, statickými reporty. Všechny reporty mají však spoleˇcné ˇ v dané oblasti podniku. to, že poskytují uživatelum ˚ základní soubor informací o tom, co se deje ˇ I pˇres svuj ˚ jednoduchý princip jsou práveˇ reporty tím nejznámejším a nejvíce využívaným BI náˇ eˇ a pro velkou skupinu uživatelu˚ pˇredstavují v praxi každodenní rutinu.48 strojem v dnešním svet 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 nepˇredstavuje datový sklad nutný zdroj dat. 47 RAINARDI, Vincent. Building a Data Warehouse: With Examples in SQL Server. Apress. United States of America. 2008. str. 329-330 48 MUNDY, Joy; THORNWAITE, Warren; KIMBALL, Ralph et al. The Microsoft Data Warehouse Toolkit: With SQL Server

24

3.1

Reporty

3


Pokud pomineme existenci administrativních reportu˚ a budeme brát v úvahu pouze ty uživaˇ následovne: ˇ telské, lze reporty rozdelit ˇ • Standardní reporty - tyto reporty jsou urˇceny k tlumoˇcení stavu podniku a jsou vetšinou velmi jednoduché, pˇríkladem muže ˚ být výkaz rozpoˇctu vuˇ ˚ ci reálným tržbám cˇ i výkaz nákladu. ˚ Do této skupiny lze však zaˇradit také reporty, které získávají data pouze z jedné ˇ tabulky, vetšinou za úˇcelem kontroly urˇcitého obchodu, zákazníka, produktu atd. ˇ eˇ prezentují infor• Strukturované reporty - na rozdíl od pˇredchozího typu, tyto reporty bežn mace napˇríˇc podnikem a spojují tak typicky všechny dimenze s faktovou tabulkou. Zárovenˇ mohou být parametrizovány, aby umožnily uživatelum ˚ modifikovat jejich vzhled dle potˇreby. Typickým pˇríkladem muže ˚ být pˇrehled týdenních tržeb v daném regionu a v urˇcitém období. ˇ uživatelum • Ad hoc reporty - tyto reporty umožnují ˚ formulovat vlastní dotazy pˇrímo do daˇ ˇ tabáze. Nekteré systémy poskytují pomocné nástroje na vytváˇrení techto dotazu, ˚ tak, aby je byli schopni vytváˇret i uživatelé, kteˇrí nemají dostateˇcné znalosti se syntaxí dotazovacího jazyka. • Tzv. exception-based reporty - tyto reporty jsou generovány na základeˇ urˇcité události, která se stala v podniku, a mají tak za úkol spíše upozornit uživatele než jim poskytovat ruzné ˚ výkazy.49 ˇ eˇ snadno urˇcit nejvetší ˇ výhodu reportu. Nyní již lze pomern ˚ Tou je bezesporu jejich jednoduchost. Reporty je jednoduché vytvoˇrit, spravovat i používat. Další výhodou je také to, že reporty lze prezentovat v libovolném tabulkovém formátu, napˇríklad ve formátu Excel, což, vzhledem k populariteˇ ˇ eˇ velkým zpusobem ˇ Microsoft Office aplikací, pomern ˚ pˇrispívá jejich uživatelské pˇrívetivosti. ˇ nevýhodou reportu˚ je naopak jejich nízká flexibilita. Obecneˇ lze ˇríci, že reporty jsou Nejvetší ˇ pˇred ostatními nástroji BI upˇrednostnová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 pozmenit data nebo je videt ˇ a znovu vygenerovat. U ostatních analytických na jiné úrovni detailu, je nutné celý report pˇredelat ˇ flexibility.50 nástroju˚ tato potˇreba mizí a je tak dosaženo daleko vetší V úvodu kapitoly bylo ˇreˇceno, že reporty dokáží pracovat jak s datovými sklady, tak i s jiˇ je však nutné ˇríci, že v podstateˇ všechny výhody reportu˚ výše nými druhy databází. Na záver uvedené (pˇredevším jejich jednoduchost) jsou pˇrímo závislé na datovém skladu. Jedineˇ dimenzionální struktura je schopna zaruˇcit, že reporty budou za každé situace stále srozumitelné a snadné na vytváˇrení. V pˇrípadeˇ standardních reportu˚ je tak zaruˇceno, že se pˇri 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 hvezdicové struktuˇre datového skladu zaruˇceno, že 2005 and the Microsoft Business Intelligence Toolset. Wiley Publishing. Canada. 2006. str. 356 49 LOSHIN, David. Business Intelligence - The Savvy manager’s guide. Getting Onboard with Emerging IT. Morgan Kaufmann Publishers. United States of America. 2003. str. 54 50 RAINARDI, Vincent. Building a Data Warehouse: With Examples in SQL Server. Apress. United States of America. 2008. str. 357, 412

25

3.2

Analýza (OLAP)

3


i pˇres spojení relativneˇ velkého množství tabulek bude tento proces stále srozumitelný a pˇrehledný. Lze tedy tvrdit, že pouze ve spojení s datovými sklady jsou reporty schopné dodržet svuj ˚ 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é, kteˇrí pracují s analytickými nástroji, mohou být napˇríklad business analytici cˇ i manažeˇri ale také vedení firmy. Typickým pˇrí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 mestech v urˇcité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 relaˇcním cˇ i multidimenzionálním formátu. Práveˇ ˇ na: na základeˇ tohoto faktoru lze OLAP rozdelit • 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á relaˇcní datový sklad • HOLAP - Hybrid online analytical processing, jako zdrojový systém se používá jak relaˇcní tak multidimenzionální databáze51 MOLAP MOLAP lze popsat jako analytický nástroj, který získává data ze speciální struktury zvané multiˇ dimenzionální databáze (MDD). V první cˇ ásti této kapitoly je proto vysvetleno, jak tato databáze ˇ vypadá a jakým zpusobem ˚ funguje. Zbytek kapitoly se již venuje 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 diˇ menzí. Vzhledem k tomu, že se MDD typicky získává z hvezdicového schématu datového skladu, ˇ eˇ jednoduché si pˇredstavit, jak tento proces probíhá. Dimenze jsou odvozeny z dimenje pomern zionálních tabulek a jednotlivé hodnoty pak z faktové tabulky.52 ˇ Nejlépe však lze MDD ilustrovat jako kostku, jejíž hrany tvoˇrí dimenze. Zminované hodnoty ˇ jsou pak obsaženy v tzv. bunkách, pˇriˇcemž jednotlivé dimenze slouží jako osy pro urˇcení jejich polohy. Tyto hodnoty mohou být jak agregované, tak atomického charakteru. Duležité ˚ však je, 51 RAINARDI, Vincent. Building a Data Warehouse: With Examples in SQL Server. Apress. United States of America. 2008. str. 380-381 52 Online analytical processing - Wikipedia, the free encyklopedia [online]. poslední revize 14.4.2010 [cit. 2010-04-18]. Dostupné z:

26

3.2

Analýza (OLAP)

9314ch12final.qxd

11/15/07

10:01 AM

3

Page 379


ˇ aby byly aditivní53 . Každá bunka pˇredstavuje jednu podnikovou událost a hodnoty dimenzí pak vyjadˇrují 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ˇmultidimensional database Pˇríklad On takovéto kostky uveden na obrázku íslo 7. Hrany kostky tvoˇrícompared dimenze to produktu, using a relational database is the processing time required for loading the database and calcu-

ˇ the zákazníka a the cˇ asu, pˇriˇcemž jejichWhenever kombinace nasource jednotlivé bunky, 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 cním of databázím jsou menší spowellvýhody for a very large multidimenzionální database (multiple terabytes) a largerelaˇ number dimensions. tˇreba místa na disku a lepší výkon. Pˇríˇcinou toho, proˇc MDD zabírá v porovnání s relaˇcní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, ˇ Vetší výkon je terms zasehave zpusoben ˚different meanings. tím, že MDD pˇredkalkulované agregované hodnoty a and OLAP is the activity used to analyze but these An MDBobsahuje is the database, cube has the same meaning the database. confusionna is caused word OLAP cube. díky svému zpusobu ˚ The uložení disku by sethe minimalizuje poˇcAn et OLAP 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 relaˇcní databázi je doba, jakou trvá výpoˇcet 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 etlena struktura MDD, je již možné definovat konkrétní možnosti, engines. Examples of an MDBMS are Microsoft SQL Server Analysis Services, Hyperion Esskteré pˇrináší uživatelum. ˚ Mezi základní operace patˇrí: 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í” pˇredstavuje 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 pˇrí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 pˇredchozí cˇ ásti. sources.

pˇríliš vhodná pro velké databáze nebo pro databáze s velkým poˇctem dimenzí.

• Dicing - dicing neboli „sekání” datové struktury je proces získávání dat na základeˇ filtroˇ vání více dimenzí. Tak je umožneno vymezit požadovaný prostor, který se bude následneˇ 53 Práve ˇ aditivita zaruˇcuje to, že lze jednotlivé hodnoty sˇcí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 hvezdicového schématu a má tedy faktovou tabulku obsahující cˇ íselné hodnoty, je tato aditivita v podstateˇ automaticky zaruˇcena.

27

379

3.2

Analýza (OLAP)

3


ˇ že došlo k filtrování pouze analyzovat. Pˇríklad je zobrazen v levé cˇ ásti obrázku 8. Je videt, urˇcitých zákazníku, ˚ produktu˚ a v urˇcité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 zpusobem ˚ 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í poˇ ˇ ovšem na konkrétním pˇríkladeˇ si lze hierarchii velice jednoduše pˇredstavit. nekud složite, ˇ Obrázek 9 znázornuje produktovou hierarchii, kdy se strom postupneˇ cˇ lení na kategorie, typy a jednotlivé produkty. Dulež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 vysvetlena definice hierarchií je již velmi snadné definovat pojem drilling up. Jedná se o prezentování dat na vyšší úrovni dané hierarchie. Nebo také pˇrecházení z nižší úrovneˇ na vyšší. • Drilling down - drilling down je pˇresný opak pˇredchozího pˇrípadu. Jedná se tedy o prezentaci dat na nižších úrovních hierarchií.55 ˇ MOLAP je bezpochyby nejvyužívanejším typem analýz práveˇ pro svoji specializovanou strukturu, ˇ ˇ nebo cˇ innost. Zárovenˇ se která umožnuje naprosto pˇrirozený pohled na dané podnikové odvetví také podílí na stále vzrustající ˚ oblibeˇ analytických nástroju. ˚ V dnešní dobeˇ se analytické ˇrízení ˇ ejší ˇ vecí ˇ a uvedomují ˇ stává stále bežn si to i velké firmy, které nástroje poskytují. Jako opravdu zajímavý lze napˇríklad oznaˇcit krok spoleˇcnosti 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: 55 RAINARDI, Vincent. Building a Data Warehouse: With Examples in SQL Server. Apress. United States of America. 2008. str. 377-379, 414

28

3.2

Analýza (OLAP)

3


analytické dotazování ve svém kanceláˇrském programu Excel. Takto se dostává velice mocný nástroj ovšem v již známém prostˇredí do rukou velkého poˇctu lidí. Obrázek 9: Produktová hierarchie

Pˇrestož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í ˇ ˇ r odpovídá struktuˇre MDD, stává se vytvoˇrení datové kostky hvezdicového schématu, které témeˇ snadnou záležitostí. ROLAP Jak bylo uvedeno dˇríve, ROLAP je druh analýzy, která získává data z relaˇcního databázového skladu. ROLAP ponechává data v puvodních ˚ tabulkách a spoléhá se na SQL pˇríkazy, kterými ˇ požadovaná data vyhledává. Nejduležit ˚ ejším mechanismem je zde však využívání agregací. Ty jsou tvoˇreny z faktové tabulky, pˇriˇcemž jejich výsledný poˇcet je dán všemi možnými kombinacemi granularit jednotlivých dimenzí. Problémem ovšem je, že tento poˇcet je opravdu velký a v podstateˇ nelze zaruˇcit, aby byly tímto zpusobem ˚ pˇredpˇripraveny veškeré výpoˇcty. Díky tomu se musí zbylé hodnoty sˇcítat až pomocí sum a group klauzulí v SQL pˇríkazech, což má za následek zpomalení celého procesu. Další výhody a nevýhody tohoto pˇrístupu byly uvedeny již v pˇredchozí kapitole. HOLAP Je známo, že HOLAP analýza je schopna získávat data jak z multidimenzionálních, tak z relaˇcních databází, ovšem pˇresná definice tohoto pojmu zatím nebyla stanovena. Jako pˇríklad fungujícího HOLAP pˇrístupu si lze pˇredstavit stav, kdy je velké množství detailních dat uloženo v relaˇcní 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 pˇredchozích pˇrístupu, ˚ ovšem nástroju, ˚ které tuto funkˇcnost ˇ ˇ eˇ málo.56 umožnují, je zatím pomern 56 Online analytical processing - Wikipedia, the free encyklopedia [online]. poslední revize 14.4.2010 [cit. 2010-04-19]. Dostupné z:

29

3.3

Data Mining

3


ˇ této kapitoly je nutné uvést srovnání OLAP analýzy vuˇ Na záver ˚ ci reportum ˚ i proto, že je ˇ ˇ výhodou analytických aplikací je zajisté jejich hranice mezi temito nástroji cˇ asto nejasná. Nejvetší ˇ flexibilita a interaktivita. Pokud uživatelé dopˇredu nevedí, co pˇresneˇ budou analyzovat, je obecneˇ ˇ lepší využít analytických než reportovacích nástroju. ˚ Naopak za nejvetší nevýhodu lze oznaˇcit ˇ eˇ velkou složitost. Uživatel již na rozdíl od reportu˚ musí rozumet ˇ dané struktuˇre (vetšinou ˇ pomern ˇ správneˇ použít. OLAP nástroje jsou také nároˇcnejší ˇ datové kostky) a musí ji umet na údržbu nebot’ se musí pravidelneˇ aktualizovat.57

3.3

Data Mining

Jestliže pˇredchozí dveˇ kategorie Business Intelligence nástroju˚ byly alesponˇ co se týˇce výstupu˚ relativneˇ podobné, data mining je kapitolou sám pro sebe. Je také nutné ˇríci, že se jedná o kapitolu ˇ eˇ tvoˇrící v podstateˇ samostatné odvetví. ˇ velmi rozsáhlou, v dnešním svet Nárust ˚ popularity data ˇ ˇ miningu jde ruku v ruce s tím, jak se konkurenˇcní boj stává stále težším a težším. Výsledkem je, ˇ poslední že firmy se nebojí vkládat do této oblasti více finanˇcních prostˇredku, ˚ a tak se toto odvetví dobou velmi rozrustá. ˚ Na rozvoj data miningu má dále velký vliv stále se zdokonalující a pˇritom ˇ výpoˇcetní technika a samozˇrejmeˇ také souˇcasná ekonomická situace. dostupnejší 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, ˇ hlavní metody data miningu a také uvést pˇríklady jeho využití. Konkrétní aplikace techto ˇ vysvetlit metod a pˇríkladu˚ bude zpracována v praktické cˇ ásti. Co je a co není data mining? ˇ Autoˇri 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 ˇ pár vysnených ˇ musel probírat obrovským množstvím bahna, aby našel onech kousku˚ zlata a tím tak celý proces nabyl smyslu. Pokud by se tato myšlenka pˇreložila, aby odpovídala informaˇcnímu ˇ ˇ svetu, jednalo by se o analytika probírající se terabyty dat a hledající nejakou hodnotnou inforˇ eˇ v podstateˇ neexistuje, dnes je za „data minera” maci. Ovšem tato myšlenka již v dnešním svet oznaˇcován každý, kdo provádí jakékoliv databázové dotazy. ˇ být. Proto lze v kontextu s data miningem Dle definice je ovšem jasné, že by to tak nemelo ˇ Jedná se o pojem knowledge discozavést ješteˇ jeden pojem, který lépe vyjadˇruje podstatu veci. very. Tento termín odkazuje na proces objevování vzoru, ˚ které vedou k získání znalostí z velkého 57 RAINARDI, Vincent. Building a Data Warehouse: With Examples in SQL Server. Apress. United States of America. 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 ruzných ˚ pˇrístupu. ˚ Tím prvním je pˇrípad, kdy je znám problém, který je tˇreba ˇrešit a metody data miningu jsou tak využívány za úˇcelem odhalení souvislostí mezi konkrétními podnikovými daty. Tento pˇrístup je nazván directed data mining. Opaˇcný pˇrístup, undirected data mining, vyjadˇruje 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 pˇrístupy, lze se zamyslet nad srovnáním data miningu s ostatními BI nástroji, pˇredevším pak s OLAP analýzou. Lze ˇríci, že všechny dˇríve uvedené nástroje ˇ je jsou schopny analyzovat obrovské množství dat. Tak kde je v tom pˇrípadeˇ rozdíl? Ten nejvetší ˇ práveˇ v tom, že u pˇredchozích analytických nástroju˚ se vždy zkoumá nejaký 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 pˇrístupu.61 Data mining a datový sklad Data mining je proces, který vyžaduje pˇrí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, vetšinou ale za úˇcelem jednorázového využití v provozním systému. Jakmile tato data naplní svuj ˚ úˇcel (úˇcetnictví atd.), jsou automaticky zálohována na pásku a z podniku tak nadobro mizí dˇrív, než se ˇ nejaké ˇ z nich staˇcí vytežit informace.62 ˇ A proto se jako zdroj pro data mining využívá v naprosté vetšin eˇ pˇrípadu˚ datový sklad, který je díky svým vlastnostem schopen zaruˇcit veškeré požadavky, které pro svoji funkci data mining ˇ ˇ potˇrebuje. Datový sklad nejenom že vetšinou umožnuje získat požadovaný rozsah dat, ale obsahuje také potˇrebná historická data. Vzhledem k tomu, že velký poˇcet data miningových metod vyžaduje jeden soubor dat pro své výpoˇcty, které jsou následneˇ otestovány na jiném souboru, je ˇ r nezbytná.63 pˇrítomnost historických dat a obecneˇ tedy datového skladu témeˇ 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 vetšin eˇ zdroju˚ se nejprve definují možné zpusoby ˚ využití data miningu64 a zvlášt’ potom matematické operace, pomocí kterých se daný business proces analyzuje. Tyto ˇ eˇ pojmu. operace mají ovšem v mnoha pˇrípadech stejný název, a tak dochází k zámen ˚ 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 62 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. 4-5 63 LOSHIN, David. Business Intelligence - The Savvy manager’s guide. Getting Onboard with Emerging IT. Morgan Kaufmann Publishers. United States of America. 2003. str. 206-207 64 Možnými zpusoby ˚ využití jsou myšleny jednotlivé metody data miningu. 60 LOSHIN,

31

3.3

Data Mining

3


ˇ spoleˇcne, ˇ ovšem s tím, pˇredešlo i v této práci, jsou zde data miningové metody a operace uvádeny ˇ jednotlivých metod, spíše než matematických operací. že hlavní duraz ˚ je kladen na znázornení Data mining lze využít v následujících pˇrípadech: • Classification - metoda klasifikace se skládá ze zkoumání vlastností noveˇ pˇrítomného objektu a jejich pˇriˇrazování jedné z pˇredem definovaných tˇríd. Objekty, které se klasifikují, jsou ˇ vetšinou reprezentovány jednotlivými ˇrádky v databázové tabulce. Proces klasifikace potom do této tabulky pˇridá nový sloupec s názvem tˇrídy a jejími hodnotami.65 Pˇríkladem z praxe muže ˚ být proces, kdy se banky rozhodují, zda danému zákazníkovi poˇ cˇ i nikoliv. Nejprve je nutné stanovit urˇcitá pravidla, podle kterých bude klasifiskytnou úver kace probíhat. V tomto pˇrípadeˇ se bude nejspíše jednat o zustatek ˚ na zákazníkoveˇ konteˇ cˇ i jeho roˇcní pˇríjem. Banka si poté zkontroluje tyto atributy a na jejich základu rozhodne o výˇ cˇ i ne, neposkytne (v jiných pˇrípadech sledku. Tím bude bud’ ano, poskytne zákazníkovi úver ˇ ˇ mohou být samozˇrejmeˇ výsledky daleko složitejší). Proces znázornuje obrázek 1066 . Metody, které tyto procesy poˇcítají se nazývají Decision trees (Rozhodovací stromy), Neural ˇ cˇ i Naïve Bayes.67 network (Neuronové síte) 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

ˇ ˇ eˇ ocenované ˇ • Estimation (Regression) „odhadování” je proces pˇriˇrmanner. azováníTherefore, nejaké pr ub ˚ want ežn wholesale customers not -paying their invoices in a timely we

a way to predict the credit risk of prospective risk is our predictionKde však klacˇ íselné hodnoty k urˇ citému objektu a je takcustomers. obdobouCredit pˇredchozí 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 spoˇcí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éData firmy.mining is excellent at plowing This is where data mining proves its worth. 67 MUNDY, Joy; THORNWAITE, Warren; KIMBALL, Ralph et al. The Microsoft Data Warehouse Toolkit: With SQL Server 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 vypoˇcítat hodnotu pro nejakou promennou, napˇríklad pravdepodobnost, že si

3.3

Data Mining

3


ˇ 15-20 let zakoupí CD pˇrehrávaˇc.68 Tak muže ˇ eˇ snadno defizákazník ve veku ˚ firma pomern novat své potenciální zákazníky.69 ˇ ˇ Estimation lze demonstrovat i na pˇredchozím pˇrípadeˇ poskytnutí úveru. Spíše než odpovedi ˇ et ˇ cˇ íselné vyjádˇrení, jak moc výhodné to pro ni je. Algoano, ne by banka potˇrebovala ved ritmy, které tyto hodnoty poˇcítají jsou založeny na principu regresní analýzy, a proto je tato ˇ metoda také nekdy nazývána regression, regrese. Stejneˇ jako v pˇredchozím pˇrípadeˇ i zde lze pracovat s Rozhodovacími stromy cˇ i Neuronovou sítí. ˇ a pˇredchozími dvema ˇ • Prediction - rozdíl mezi pˇredpovedí pˇrípady spoˇcívá v tom, že pˇredˇ se pokouší zaˇradit objekty na základeˇ pˇredpokládaného budoucího chování. Pˇredpopoved’ ˇ tak sice pracuje se stejnými technikami, ovšem za úˇcelem stanovení promenné, ˇ ved’ která ˇ rena až v budoucnu. Jednodušeji ˇreˇceno, pˇredpoved’ ˇ analyzuje pomocí matemabude oveˇ tických výpoˇctu, ˚ co se stalo v minulosti (zkoumá historická data uložená v datovém skladu) ˇ ˇ stane v budoucnu. a snaží se urˇcit, co se, pokud vydrží souˇcasný trend, nejpravdepodobn eji Pˇríkladem muže ˚ být firma, která staví nový dum ˚ za úˇcelem následného prodeje a ráda by ˇ musí nejprve sestavit tak urˇcila jeho budoucí cenu. Aby byla schopna sestavit pˇredpoved’, soubor atributu, ˚ na základeˇ kterých se bude cena odhadovat. Zde se jedná napˇríklad o rozlohu domu, poˇcet koupelen, destinace atd. Prediktivní metoda pak porovná atributy v tomto ˇ souboru s jejich historickými hodnotami a na jejich základeˇ vytvoˇrí pˇredpoved’. ˇ nejˇcasteji ˇ využívají Rozhodovací stromy a NeuroPro pˇredpovídání cˇ íselné hodnoty se opet ˇ Pro urˇcení cˇ asové pˇredpovedi ˇ se však musí využít specializovaných metod (napˇr. nové síte. Microsoft Time Series).70 • Association (Affinity Grouping) - jedná se o proces vyhodnocování vztahu˚ cˇ i asociací ˇ Affinity Grouping muže mezi jednotlivými objekty, které prokazují urˇcité vzájemné spˇríznení. ˚ ˇ být napˇríklad použito k urˇcení pravdepodobnosti, že zákazníci, kteˇrí si poˇrizují jeden urcˇ itý produkt by byly ochotni vyzkoušet i jiný. Tento druh analýzy je velmi užiteˇcný napˇríklad pro marketingové kampaneˇ nebo také pro vytvoˇrení takového produktu, který by oslovoval ˇ poˇcet lidí.71 co možná nejvetší Nejvíce se však tato metoda používá v tzv. Market basket analysis. Jde o pˇrípad, se kterým ˇ ˇ Tyto e-shopy vyse asi setkal každý, kdo nekdy nakupoval zboží na internetovém obchode. užívají asociaˇcní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é, kteˇrí si zakoupili toto zboží také poˇrídili. V anglickém jazyce zní tato hláška „Customers, who bought this product, also bought.” a lze se s ní ˇ r všude. Tento proces ilustruje obrázek 11 na pˇríkladu nákupu hraˇcek setkat opravdu témeˇ 68 V souvislosti s tím se také zavádí pojem skóre. Zatímco pravdepodobnost ˇ vyjadˇruje s jakou urˇcitostí si zákazník produkt koupí, skóre pˇredstavuje procento zákazníku, ˚ které si daný produkt již zakoupilo. 69 LOSHIN, David. Business Intelligence - The Savvy manager’s guide. Getting Onboard with Emerging IT. Morgan Kaufmann Publishers. United States of America. 2003. str. 209-210 70 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. 425-426 71 LOSHIN, David. Business Intelligence - The Savvy manager’s guide. Getting Onboard with Emerging IT. Morgan Kaufmann Publishers. United States of America. 2003. str. 210

33

3.3

Data Mining

3


ˇ z druhé svetové války. Metody, které asociace poˇcí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

British Tank Commander + German Panzer Driver British Tank Commander + RAF Pilot British Tank Commander + Russian Tank Commander British Tank Commander + U.S. Army Pilot German Panzer Driver + RAF Pilot German Panzer Driver + Russian Tank Commander German Panzer Driver + U.S. Army Pilot RAF Pilot + Russian Tank Commander 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

British Tank Commander + German Panzer Driver + RAF Pilot British Tank Commander + German Panzer Driver + U.S. Army Pilot British Tank Commander + 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 pˇredem definované a je tak na pˇríslušsupport required. Items from theaby two-item sets aarepokoušel now combined three-item sets.jsou Thispˇredmetem ˇ ném analytikovi, je zkoumal se najít to urˇcform 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 vetšinou o tzv. segmentaci. Figure 13-15, no three-item sets have the minimum support required so, in this case, ˇ posloupnosti mezi daty. Proto je cˇ asto Proces clusteringu je také schopen odhalit nejˇcast ejší the algorithm does not continue with four-item sets. Once the sets are kcreated, the chování algorithm creates u˚membership rules based on the také k urvyužíván napˇ ríklad mapování zákazník na webových stránkách nebo result. The algorithm determined that 16,044 purchases included the British Tank cˇ ení sledovanosti televizních poˇradu˚ 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že ˚ future, 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. Pˇrí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ˇ hovoˇrí autoˇri v knize Data mining techniques ˇ Nekdy ˇ ˇ v nejaké ˇ následovne. spoˇcívá úˇcel data miningu pouze v popisování toho, co se deje ˇ tem ˇ procesu, složité databázi a to tím zpusobem, ˚ abychom získali lepší porozumení ˚ produktum ˚ cˇ i zákazníkum, ˚ které tato data v první ˇradeˇ 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

Souˇcasné trendy ve vývoji datových skladu˚ a BI

3


ˇ ˇ ˇ také k jeho vyˇrešení a nebo alesponˇ poukáže na to, kde nejakého chování vetšinou dospeje ho hledat. Za tímto úˇcelem lze využít algoritmy jako Rozhodovací stromy, Clustering cˇ i Affinity Grouping.73

3.4

ˇ Soucasné trendy ve vývoji datových skladu˚ a BI

ˇ ˇ V této cˇ ásti je znázorneno, jakým smerem se vývoj datových skladu˚ a Business Intelligence ˇ eˇ ubírá. Jsou zde uvedeny dveˇ pravdepodobn ˇ ˇ nástroju˚ v dnešním svet eˇ nejaktuálnejší 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 ˇ tvoˇrena cˇ íslicemi, znaky atd. Tato data se nazývají strukturovaná. Pravdou však je, že daleko vetší cˇ ást podnikových dat je tvoˇrena jinými tzv. nestrukturovanými daty. Jedná se napˇríklad o obrázky, videa, webové stránky, prezentace, e-maily, dokumenty, hudbu atd. Na rozdíl od dat strukturovaˇ ných, která jsou vetšinou uložena v relaˇcní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 sysˇ ˇ ˇ témech. Vzhledem k tomu, že množství techto dat muže ˚ být v podnicích nekolikanásobn eˇ vetší ˇ rení firmy), vzniká v ponež množství dat strukturovaných (záleží pˇri tom samozˇrejmeˇ na zameˇ sledních letech poptávka po možnosti ukládání a analyzování dat nestrukturovaných. Otázkou tedy zustá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 oznaˇcována jako tradiˇcní a spoˇcívá v uložení nestrukturovaného objektu na urˇcitý file server a jeho atributu˚ pak do datového skladu. Princip lze pochopit na pˇríkladu dokumentu. ˚ Všechny z nich, at’ už jsou uloženy v jakémkoliv forˇ mátu, mají nekolik spoleˇcných atributu, ˚ jako napˇríklad název, téma, abstrakt, typ, verzi, id, datum vytvoˇrení, velikost, poˇcet 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 zpusobem ˚ lze dokonce uložené atributy podrobit následné analýze stejneˇ tak jako to bylo v pˇrípadeˇ strukturovaných dat. Tuto metodu lze pochopitelneˇ kromeˇ dokumentu˚ aplikovat i na jiná nestrukturovaná data. Tento pˇrístup však z hlediska analýzy a zkoumání dat nepˇrináší žá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 uvnitˇr dokumentu, rozboru textu, extrahování slovních spojení a identifikace asociací s využitím ruzných ˚ statistických analýz. 73 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. 12

35

9314ch15final.qxd

3.4

11/15/07

9:43 AM

Page 472


472

3


CHAPTER 15 ■ OTHER DATA WAREHOUSE USAGE

Celý proces zaˇcíná pˇrevedení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 ˇ lze jsou schopny rozlišit jednotlivé pˇripravený 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. asociaˇcfor ním hodnocením. Toto point here is that ajetext analytics application that is developed specifically the recruitindustry understands the context of the industry andris able to identify that certain ˇ hodnoceníment si lze pˇredstavit jako cˇ íslo od 0 do 1, které vyjadˇ uje vztah jednotlivých frází. Cím vyšší phrases are skills, titles, software, cities, and company names, whereas a pharmaceutical text

analytics application to recognize symptoms, research,jsou diagnoses, chemical ˇ would cˇ íslo je, tím je vztah silnejší. Duležité ˚ be ableje, ž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, íklad životopisy atd.74 tion understands the relationship between phrases, napˇ suchras 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 poˇcet a sílu claim documents within the insurance industry.

ˇ jednotlivých vztah u. ˚ Takto rené schéma je znázorn eno na to obrázku 12. A pictorial The scored lists vytvoˇ 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 nosplnuje ˇ skladu, ˚ který je oznaˇ cován jako Data Warehousing 2.0to(DW 2.0).A, Tento pˇrístup sice pu˚ relation with any skill, software, or company. The other output of the analytics is grouping or

ˇ is,sethevšak vodní Inmonovu definici uvedenou v první kapitole, zárove první classification according to the taxonomy of the phrases, thatn 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

ˇ software skladu˚ lišímining v nekolika bodech: that works well for car insurance claims may not have the vocabulary required to analyze food and beverage patents.

ˇ scores, • Životní Once cyklus jaklists data stárnou, mení se i jejich charakteristika. Vdata dusledku ˚ ware- toho jsou youdat have- the and the association you can store them in the house for further analysis. For example, you can ask questions such as, “What are the top five

ˇ ˇ ˇ data v DW 2.0 rozdelena na nekolik oblastí práveˇ podle jejich veku.

• Nestrukturovaná data - nestrukturovaná data jsou naprosto validní souˇcástí datového skladu. ˇ Kromeˇ toho se zde vyskytují v nekolika formách, jako jednotlivé úryvky textu, jako upravená ˇ slova a fráze a také jako tzv. matching text, který vyjadˇruje pravdepodobnost shodnosti nestrukturovaných dat. ˇ duraz • Pˇrítomnost metadat - DW 2.0 klade vetší ˚ na metadata a stejneˇ tak jako v pˇredchozím ˇ bodeˇ i metadata jsou cˇ lenena 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é pˇrinášejí jisté výhody, a tak lze pˇredpokládat, že vývoj datových skladu˚ bude ˇ rovat práveˇ tímto smerem. ˇ smeˇ Zajímavá je i skuteˇcnost, ž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 ˇ v budoucnu si koncept starý pouze pár let a v praxi se zatím pˇríliš nevyužívá. Na jeho uplatnení ˇ bude tedy ješteˇ tˇreba nejakou dobu poˇckat. 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:

37

3.4


3


Real-time Business Intelligence I pˇrestože je toto téma v podstateˇ v pˇrímém rozporu s myšlenkou této práce, tedy ukázat nezbytnost pˇrítomnosti datového skladu pro BI aplikace, považuji za duležité ˚ tento pojem alesponˇ ˇ zmínit. Jedná se o technologii, která se zaˇcala rozvíjet teprve pˇred nekolika lety a pˇredstavuje ˇ ˇ datových skladu˚ a BI. pravdepodobn eˇ jednu z možných cest dalšího vývoje celého odvetví ˇ Problém bežného Business Intelligence spoˇcívá v tom, že pracuje s daty, která nejsou úplneˇ ˇ aktuální. To je samozˇrejmeˇ spojeno s tím, že datový sklad se vetšinou aktualizuje jednou za den cˇ i dokonce méneˇ cˇ asto. V dnešní dobeˇ však souˇcasné ekonomické prostˇredí a situace kladou ˇ nároky na nutnost analyzovat co možná nejaktuálnejší ˇ data, nejlépe v reálném cˇ ase. stále vetší Pˇríkladem muže ˚ být odhalení podezˇrelé bankovní transakce nebo také analýza propadu tržeb ˇ daného dne. Ve všech techto pˇrípadech již klasické BI nástroje nestaˇcí.76 ˇ ˇ V souvislosti s temito pˇríˇcinami se tedy v posledních letech objevilo nekolik nových technologií ˇ ruji, se nazývá Real-time Business Intelligence (RTBI), nekdy ˇ a pojmu. ˚ To, ke kterému zde smeˇ ˇ eˇ nová, neexistuje také Business Intelligence 2. Vzhledem k tomu, že je tato problematika pomern ješteˇ žádná standardizovaná definice. Lze však definovat, co RTBI pro každý podnik znamená. Spojení real-time muže ˚ tedy vyjadˇrovat: • Požadavek na nulovou latency jakéhokoliv procesu • Fakt, že má proces pˇrístup k informacím kdykoliv je potˇreba ˇ rené hodnoty, které se vztahují k souˇcasné a ne historické situaci77 • Možnost cˇ erpat meˇ ˇ takˇrka pouze v pˇrípade, ˇ že se budou data cˇ erNutno ˇríci, že tyto požadavky mohou být naplneny pat z provozních databází, které mohou zaruˇcit jejich aktuálnost. Existuje sice také technologie Real-time Data Warehouse, která se snaží o minimalizaci prostoju˚ mezi jednotlivými aktualizaˇ cemi dat, ovšem ani ta ve vetšin eˇ pˇrípadu˚ nevyhovuje výše uvedeným požadavkum. ˚ Jednotlivé ˇ naˇctení probíhá v intervalech v rozmezí nekolika až desítek minut, a tak definici „datového skladu v reálném cˇ ase” stejneˇ pˇrímo neodpovídá. RTBI aplikace se, díky své orientaci na souˇcasné problémy, pˇresouvají pˇredevším do oblasti ruzných ˚ pˇrehledových zobrazení, jako napˇríklad dashboards, internetové portály atd. Výhodou ˇ ˇ tohoto pˇrístupu je navíc také to, že pro zacházení s temito nástroji uživatel vetšinou nepotˇrebuje ˇ dobrou znalost jak business domény, tak informaˇcních technologií. Tyto aplikace poskytují vetšiˇ která je pro uživatele nou spíše high level pohled na souˇcasnou situaci a navíc v takové forme, ˇ srozumitelná. Jedná se vetšinou o ruzné ˚ grafy, tabulky a jiné formy prezentace dat. Real-time Business Intelligence tak ukazuje jakýsi trend, kterým se informaˇcní nástroje v tomto ˇ odvetví budou nejspíše ubírat. Otázkou však zustá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: 77 AZVINE, B.; CUI, Z., et al. Real Time Business Intelligence for the Adaptive Enterprise [online]. [cit. 2010-04-22]. Dostupné z:

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 venována praktické ukázce využití datového skladu ve spojení s Business Intelˇ využívaného datového skladu a to ligence nástroji. První cˇ ást se však zabývá návrhem pozdeji ˇ i pˇresto, že návrh a implementace datového skladu není pˇrímo pˇredmetem 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 duležitá. ˚ Implementaˇcní cˇ ást navíc pˇrímo souvisí s využitím datových skladu˚ ˇ propojení datového skladu s okolními systémy nebot’ se zde definují technologie, které umožnují ˇ patˇriˇcnými daty. a pˇredevším pak jeho naplnení ˇ Další kapitoly jsou již venovány výhradneˇ možnostem využití datových skladu. ˚ První z nich se ˇ ruje na problematiku reportu, ˇ zameˇ ˚ v dalších kapitolách se pak venuji analýze a data miningu.

4.1

Návrh a implementace

ˇ Jak již bylo ˇreˇceno, první cˇ ást této kapitoly se venuje 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 nejsrozumitelnejší, byl pro implementaci datového skladu vybrán typický model prodejní spoleˇcnosti. Jedná se o prostˇredí, kde se datové sklady budují velmi cˇ asto a jeho struktura je ˇ eˇ jednoduchá a dobˇre pˇredstavitelná, proto je vhodný i pro demonstraci využití v této pomern práci. Datový sklad bude vyvíjen pro fiktivní zahraniˇcní firmu, která se zabývá prodejem elektroniky. Vzhledem k tomu, že pusobí ˚ ve více zemích78 , má spoleˇcnost velký problém s organizací svých ˇ dat, pˇredevším potom s jejich analýzou. Firemní data musí být získávána z nekolika ruzných ˚ ˇ své informace systému˚ napˇríˇc jednotlivými státy, což je velmi obtížné. Organizace by tak chtela ˇ o prodeji analyzovat podle zemepisné oblasti a také dle ruzných ˚ kategorií svých produktu, ˚ to vše ˇ mít lepší pˇrehled o svých zákaznících napˇríˇc pˇritom v závislosti na cˇ ase. Zárovenˇ by firma chtela svými systémy.79 ˇ do techto ˇ Návrh požadovaného datového skladu by se dal rozdelit fází: 1. Definování business požadavku˚ 2. Návrh dimenzionálního modelu 3. Návrh technologické platformy 4. Implementace a naˇctení dat 78 Firma

pusobí ˚ 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 pˇri vývoji datového skladu, nýbrž spíše jako definování dulež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 zaˇcátku kapitoly.

39

4.1


4


Definování business požadavku˚ Z popisu firmy byly urˇceny základní subjekty úˇcastnící se firemních procesu. ˚ Tím hlavním je samozˇrejmeˇ samotný prodej, dalšími faktory, které do tohoto procesu zasahují jsou zákazník a také ˇ obchod, ve kterém se prodej uskuteˇcnil (z požadavku na zemepisné rozlišení). Vzhledem k tomu, že firma potˇrebuje analyzovat svá data v závislosti na cˇ ase, je dalším faktorem úˇcastní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

ˇ datový sklad umet, ˇ jinými slovy je tˇreba urˇcit Kromeˇ struktury je také tˇreba urˇcit, co by mel ˇ funkˇcní požadavky. Datový sklad musí umožnovat: • analyzovat požadovaná data v závislosti na cˇ ase, na produktu, na zákazníkovi, který si daný ˇ ve kterém bylo zboží zakoupeno. Zárovenˇ musí umožnit produkt zakoupil a na obchode, sledování tržeb, nákladu˚ a zisku˚ z prodeje a také poˇcty prodaných kusu. ˚ ˇ ˇ mesta ˇ • vyhledávat zákazníky dle zemepisných údaju˚ (zeme, atd.) a také podle jejich demoˇ zamestnání ˇ grafických údaju˚ (pohlaví, vek, atd.) ˇ u, • analyzovat data na úrovni let, kvartálu, ˚ mesíc ˚ týdnu˚ a dnu˚ ˇ • analyzovat data podle jednotlivých státu˚ a mest ˇ analyzovat nejméneˇ dva roky stará data • od prvního spuštení ˇ být urˇceny nefunkˇcní požadavky cˇ i provedena analýza rizik, oba dva procesy jsou Dále by mely však v tomto pˇrípadeˇ irelevantní. 40

4.1


4


Návrh dimenzionálního modelu ˇ základní požadavky na systém, je nyní možné pˇriPoté co byly v pˇredchozí cˇ ásti shromáždeny stoupit 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í patˇriˇcných dimenzí ze struktury systému. Z konceptuálního modelu lze urˇcit, že dimenze budou následující: • zákazník • produkt • obchod • cˇ as ˇ jsou: Z funkˇcních požadavku˚ lze navíc odvodit požadované míry, které se budou sledovat. Temi náklady, tržby, zisk a poˇcet prodaných kusu. ˚ Tyto hodnoty tvoˇrí jádro faktové tabulky. Po spojení jednotlivých dimenzí s faktovou tabulkou pomocí cizích klíˇcu˚ navíc vznikne požadovaný dimenziˇ že všechny nasbírané požadavky se týkají práveˇ jedné business probleonální model. Je videt, matiky, a tak toto schéma pˇresneˇ odpovídá definici data martu uvedené dˇríve. V dalším kroku dimenzionálního modelování byly navrženy jednotlivé atributy. Bylo dbáno na to, aby vyhovovaly požadavkum ˚ stanovených dˇrí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íˇce, které ji spojují s jednotlivými dimenzemi. Dále je zde uveden poˇcet prodaných kusu˚ jednoho produktu a také náklady a tržby z prodeje daného produktu. Posledním, ovšem ˇ nejduležit ˚ ejším atributem je položka zisk. Tato položka je vypoˇcítána pˇrímo databází jako rozdíl mezi tržbami a náklady na prodej. Dá se pˇredpokládat, že práveˇ tento atribut bude ˇ ˇ nejˇcastejším pˇredmetem dotazu. ˚ Jak bylo uvedeno v teoretické cˇ ásti, je u faktových tabulek duležité ˚ stanovit jejich granularitu. V tomto pˇrípadeˇ jedna ˇrádka v tabulce koresponduje s jednou prodanou položkou. • Dimenze datum - dimenze jsou spojeny s faktovou tabulkou pomocí cizích klíˇcu, ˚ obsahují tedy unikátní primární klíˇc. V pˇrípadeˇ této dimenze se jedná o atribut id_datum. Dimenze data je zárovenˇ dobrým pˇríkladem toho, jaké redundantní informace se mohou v dimenziˇ onálních modelech skrývat. Kromeˇ data samotného je zde ješteˇ zvlášt’ definován mesíc, ˇ ˇ týden a den a to navíc v nekterých pˇrípadech jak v cˇ íselné, tak slovní forme. Tento fakt také souvisí s vytváˇrení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 ruzných ˚ úrovních, a získat tak daleko více potˇrebný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 pˇredevší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 pˇrípadeˇ prodejního oddelení bylo jednak zbyteˇcné a jednak i takˇrka nemožné získat. Tabulka zákazník tedy obsahuje primární klíˇc id_zakaznik a další popisné atributy jako napˇríklad vek, prijem, zamestnani atd. Jestliže pˇredchozí dimenze byla pˇríkladem redundance jako jednoho ze základních projevu˚ ˇ její denormalizace. V pˇrípadeˇ klasické dimenzionálního modelu, na této dimenzi je videt normalizované databáze by se atributy jako emailova_adresa, adresa_1 cˇ i jiné geografické ˇ v jedné. atributy nejspíše nacházely v samostatné tabulce, zde jsou však umísteny • Dimenze produkt - tato dimenze obsahuje, kromeˇ primárního klíˇce id_produkt, další atriˇ buty, z nichž za nejduležit ˚ ejší se dají oznaˇcit nazev, typ a kategorie, které jsou zárovenˇ souˇcá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ý. ˇ odlišit jednotlivé obchody na základeˇ • Dimenze obchod - u této dimenze je nejduležit ˚ ejší ˇ geografického umístení. Tabulka tedy obsahuje atributy jako mesto, zeme, cˇ i adresy obchodu. ˚ Dalším duležitým ˚ atributem je typ obchodu, který zachycuje, jedná-li se o kamenný cˇ i elektronický obchod. Primárním klíˇcem je id_obchod. ˇ ˇ že model odpovídá hvezdicovému ˇ Výsledný logický model znázornuje obrázek 15. Je videt, schématu, nebot’ není duvod ˚ jednotlivé dimenze normalizovat, naopak by se tím potlaˇcily výhody spojené s požadavky na analýzu a dotazování. Návrh technologické platformy V tomto bodeˇ je urˇcena technologická platforma, na které bude data mart založen. Výstupem bude tedy fyzický model, který je již plneˇ pˇrizpusoben ˚ dané databázi. ˇ V tomto pˇrípadeˇ se nemuselo pˇrihlížet na to, zda jsou nekteré technologie pro vývoj upˇrednostˇ ˇ realizován na základeˇ kvality cˇ i vhodnosti a také na základeˇ pˇredchozích novány, proto byl výber zkušeností s daným produktem. Obecneˇ lze ˇríci, že projekt byl realizován pˇrevážneˇ s využitím aplikací od spoleˇcnosti Microsoft, základním softwarem pro další technologie byl proto operaˇcní systém Windows XP81 . ˇ Použité technologie lze shrnout do nekolika 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. ˇ ceny výrobku, nemají však žádnou souvislost s aktuálními náklady cˇ i Tyto atributy jsou zde uvedeny jen pro znázornení tržbami prodeje, to by ve skuteˇcnosti zajišt’oval provozní systém, ze kterého by data byla naˇcítána. 81 V mém pˇrípade ˇ se jednalo o Windows XP Service pack 3, ale lze samozˇrejmeˇ použít jakýkoliv novejší ˇ operaˇcní systém od spoleˇcnosti Microsoft.

43

4.1


4


byl vybrán na základeˇ pˇredchozích zkušeností, velice dobré dokumentace všech vlastností ˇ SQL serveru a také jeho dostupnosti.82 Jeho nejvetší 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 nekolik dalších komponent potˇrebných pro tento projekt. Jedná se o aplikaci Integration Services, pomocí které lze naˇcíst data do datového skladu, a dále o aplikace Analysis Services a Report Services, které budou využity pˇri tvorbeˇ anaˇ lytických dotazu˚ cˇ i reportu. ˚ Pro analýzu dat vytvoˇrených pomocí techto programu˚ byl pak využit program Microsoft Excel 2007. • pro naˇctení dat byla využita cˇ ásteˇcneˇ aplikace Integration Services spolu s programem Microsoft Excel, ve kterém byla data vytvoˇrena. Zbylá data byla naˇctena pomocí programu ˇ ˇ eˇ jednoduché vygenerování testovacích dat SQL Data Generator, který umožnuje pomern a lze ho volneˇ používat po dobu 14 dnu. ˚ • další kategorií jsou nástroje použité pro vytvoˇrení jednotlivých modelu˚ datového skladu. Konceptuální model byl vytvoˇren v programu Microsoft Office Visio 2007, všechny zbylé modely pak v programu Enterprise Architect. Nyní lze zaˇcít s transformací logického modelu na fyzický. V první cˇ ásti jsou pˇrizpusobeny ˚ jednotlivé datové typy databázi SQL Server. Až na výjimky se jedná o datové typy int v pˇrípadeˇ cˇ ísel, nvarchar cˇ i nchar v pˇrípadeˇ textu a smalldatetime v pˇrípadeˇ datumu. Datový typ nvarchar byl vybrán z toho duvodu, ˚ že obsahuje znaky unicode, což není v našem pˇrípadeˇ nezbytneˇ nutné, nebot’ jsou atributy psány bez diakritiky, ˇ import dat do datového skladu. Nevýhoda tohoto typu ovšem má to velký význam pro pozdejší je, že díky tomu, že obsahuje dvakrát tolik znaku, ˚ zabírá také více místa na disku. V pˇrí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ž ˇ není duležité. 2079, což v tomto pˇrípadeˇ opet ˚ V další cˇ ásti je nutné správneˇ zvolit cizí klíˇce. 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 pˇrípadnou optimalizaci systému. Vzhledem k tomu, že cílem ˇ této kapitoly je pˇredevším ukázat využití datových skladu, ˚ není zde venováno optimalizaci mnoho prostoru. Pˇresto 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 ˇ na cizí klíˇce práveˇ v této tabulce. tabulkou, jsou indexy umísteny ˇ na obrázku 16. Výstup této cˇ ásti v podobeˇ fyzického modelu lze videt 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 nactení 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 pˇríklad takto vygenerovaného kódu v pˇrípadeˇ tabulky produktu:83

Podobným zpusobem ˚ byly vygenerovány i ostatní tabulky a byl tak vytvoˇren kompletní dimenzionální model. Pˇred naˇctením dat bylo ješteˇ nutné lehce upravit tabulku prodeje. Jak bylo uvedeno dˇríve, atribut zisk není importován, nýbrž je poˇcítán pˇrímo databází. K tomu lze vyuˇ žít funkˇcnost SQL serveru, která se nazývá computed column. Ta umožnuje využít jakýkoliv jiný atribut z pˇríslušné tabulky pro výpoˇcet daného atributu. Položka zisk bude tedy upravena následujícím zpusobem: ˚

Parametr persisted zaruˇcuje, že bude atribut fyzicky uložen na disku. Bez tohoto parametru by byl pˇrepoˇcítáván pˇri každém použití. K plnohodnotné ukázce jakýchkoliv BI nástroju˚ je nutné, aby datový sklad obsahoval velké množství dat, pˇredevším historických. Ve funkˇcních požadavcích je navíc uvedeno, že datový ˇ již od prvního spuštení ˇ uchovávat minimálneˇ dva roky stará data, což toto množství sklad by mel ˇ dále umocnuje. Vzhledem k tomu, že není k dispozici žádná operaˇcní databáze, ze které by se ˇ daly cˇ erpat reálná data, je nutné tato data nejakým zpusobem ˚ vygenerovat a simulovat tak chod skuteˇcného systému. ˇ Jak již bylo ˇreˇceno, k tomuto úkolu byl využit program SQL Data Generator. Pomocí neho bylo možné urˇcit pˇresnou podobu testovacích dat i poˇcet ˇrádek k vygenerování. Aplikace pak požadovaná data vygenerovala a sama naˇcetla do databáze. 83 Kód

není kvuli ˚ délce kompletní.

46

4.2

Vytvoˇrení reportu˚

4


V pˇrípadeˇ tabulky datum však bylo zapotˇrebí vytvoˇrit data manuálním zpusobem ˚ a poté je do datového skladu importovat.84 K tomu byly využity programy Microsoft Excel a Integration Services. Tato aplikace umí naˇcíst libovolná data ze souboru Excel, pˇretransformovat je tak, aby odpovídaly cílové destinaci a následneˇ je do ní naˇcí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 ukonˇcen a nyní lze koneˇcneˇ pˇristoupit 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 ˇ široké možnosti SQL Report Services nástroje, skladem vytvoˇrit. Zárovenˇ zde budou znázorneny ve kterém budou dotazy tvoˇreny. Výstupem této cˇ ásti jsou ukázky dvou v praxi se nejvíce vyskytujících typu˚ reportu. ˚ ˇ být mezi ostatními nástroji Business Jak je známo, nástroje na vytváˇrení reportu˚ by mely ˇ jednoduššími, nebot’ s nimi cˇ asto pracují bežní ˇ Intelligence temi uživatelé. V tomto ohledu vychází program Report Services opravdu vstˇríc. Díky spojení pˇrehledného GUI aplikace s jednoduchou ˇ eˇ snadným zpusobem. strukturou datového skladu lze vytvoˇrit ruzné ˚ reporty pomern ˚ S tímto pˇrípadem je spojen první ukázkový report, uveden na obrázku 18, který obsahuje pˇreˇ hled zákazníku, ˚ kteˇrí si zakoupili nejaký produkt. Jedná se o pˇrípad, kdy nejsou spojovány žádné ˇ databázové tabulky, pouze jsou vybrány nekteré atributy, se kterými se dále pracuje. Na ukázce je ˇ že uživatelé si mohou prohlížet zákazníky na základeˇ zemeˇ a mesta, ˇ videt, ve kterém bydlí. Dále ˇ cˇ i jejich jména. Spolu s možností zákazníky v jednotlimohou být zákazníci ˇrazeni dle jejich veku ˇ vých zemích a mestech postupneˇ skrývat a zobrazovat se jedná o snahu vytvoˇrit alesponˇ trochu flexibilní prostˇredí, pˇrestože jsou v tomto ohledu daleko pˇrevyšovány OLAP nástroji. ˇ Jak již bylo ˇreˇceno, report se dá vytvoˇrit pomocí grafického uživatelského prostˇredí nebo ruˇcne, zadáním SQL dotazu. Pˇrestože znalost dotazovacího jazyka není pro tvorbu tohoto jednoduchého reportu nezbytneˇ nutná, kontaktu s ním se uživatel nevyhne. Pro pˇrehled tedy uvádím krátký pˇríkaz pro vytvoˇrení reportu z obrázku 18.

84 V pˇredchozím pˇrí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 ˇ napˇríklad jako jeden objekt datum 1.1.2010, den 15, mesíc cˇ erven, kvartál q2 atd. 85 Kvuli ˚ tomuto kroku byly zvoleny atributy, které podporují unicode kódování.

47

4.2


4


Obrázek 18: Pˇrehled zákazníku˚

48

4.3

Analýza (OLAP)

4


ˇ Druhý pˇrípad je již pro uživatele složitejší, na druhou stranu je však nutné ˇríci, že je i pˇresto ˇ nejˇcastejším typem vytváˇrených reportu. ˚ Jedná se o pˇrípad, kdy dochází ke sluˇcování typicky všech dimenzionálních tabulek s tabulkou faktovou. Zde se plneˇ projevují výhody dimenzionálního ˇ nebot’ díky hvezdicovému ˇ modelu a tedy i datového skladu obecne, schématu se dají tabulky velmi efektivneˇ spojit. Takto vytvoˇrený report, který je uveden na obrázku 19, zobrazuje pˇrehled týdenních tržeb rozˇ delených podle typu produktu. Jednotlivé tržby jsou tak sˇcí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 urˇ cˇ itého roku cˇ i kvartálu nebo z urˇcité zemeˇ cˇ i mesta. Pro tuto funkˇcnost se musely vytvoˇrit tzv. parametry, do kterých byly pomocí dalšího SQL pˇríkazu naˇcteny hodnoty, ze kterých pak muže ˚ ˇ volit. Zde je uveden pˇríkaz, pomocí kterého byl report vytvoˇren: uživatel pˇri výberu

Velkou výhodou takto vytvoˇrených reportu˚ je i to, že se dají exportovat do jiných programu, ˚ napˇríklad Microsoft Word nebo Excel, kde se s nimi dá dále pracovat. Kromeˇ exportu do ruzný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ázorneno praktické využití datových skladu˚ ve spojení s analytickými nástroji. Za tím úˇcelem bude vytvoˇrena multidimenzionální databáze, která bude následneˇ sloužit ˇ jako zdroj pro OLAP analýzu. Proto je také tato kapitola rozdelena 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: Pˇrehled týdenních tržeb

50

4.3

Analýza (OLAP)

4


Multidimenzionální databáze ˇ Proces vytvoˇrení datové kostky je složen z nekolika cˇ ástí: ˇ datového zdroje - jako datový zdroj, ze kterého se bude pro vytvoˇrení kostky vycházet 1. Výber byl vybrán samozˇrejmeˇ dˇríve vytvoˇrený datový sklad ˇ struktury - z požadavku na zkoumání dat dle geografického umístení ˇ a podle kate2. Výber gorií prodávaných produktu˚ v závislosti na cˇ ase byly jako dimenze vybrány dim_obchod, dim_produkt a dim_datum. Souˇcástí struktury datové kostky je samozˇrejmeˇ 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é tvoˇrí zkoumané parametry, a dále pak jednotlivé atributy a hierarchie, se kterými se bude pracovat. Jako hodnoty byly zvoleny všechny pˇrípustné atributy z faktové tabulky, tedy naklady, trzby, zisk a pocet_kusu. Jako hierarchie v pˇrí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 pˇrípadeˇ produktu se jedná o atributy kategorie, typ a nazev. Atributy, které nejsou souˇcástí žádné hierarchie jsou v databázové kostce taktéž obsaženy. ˇ se musí navrhnutá kostka fyzicky vytvoˇrit a naplnit požadova4. Vytvoˇrení kostky - na záver ˇ nými daty. V programu Analysis Services se toho lze docílit spuštením procesu˚ build, deploy a process. 5. Vytvoˇrení KPI - byl vytvoˇren indikátor zisku, který pomáhá sledovat jeho souˇcasný stav a výˇ a dimenzemi. Cílová hodnota zisku odpovídá jedné voj do budoucna napˇríˇc všemi úrovnemi tˇretineˇ tržeb. Tímto zpusobem ˚ lze navíc kontrolovat i náklady nebot’ ze vztahu mezi ziskem, ˇ než dveˇ tˇretiny tržeb. tržbami a náklady je jasné, že nemohou být vetší ˇ Co se týˇce vývoje do budoucna je cílem, aby hodnoty zisku byly o 20% vetší než pˇredˇ že je dosaženo nižších hodnot, ukazatel trendu se snižuje. Tyto cházející týden. V pˇrípade, indikátory byly zadány pomocí skriptovacího jazyka MDX, který je urˇcen 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é vytvoˇrenou datovou strukturu libovolneˇ procházet a analyzovat. Pˇrestože s ní lze pracovat pˇrí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 tvoˇren nekolika záˇ ruje na neco ˇ ložkami. V každé z nich se analýza zameˇ 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. ˇ pˇrípad drill up/down. Uživatel muže • V prvním sešitu je znázornen ˚ prohlížet náklady, tržby ˇ cˇ í jednotlivých obchodu. a zisk jak na úrovni zemí, tak i na úrovni mest ˚ Zárovenˇ lze díky velké ˇ požadované období a také urˇcitou kategorii produktu. flexibiliteˇ analytických nástroju˚ menit ˚ ˇ • Ve druhé záložce je vypracována ukázka zminované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. Pˇríklad pˇresneˇ 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. ˇ ˇ eno, ˇ • Ctvrtý sešit neobsahuje z hlediska obsahu nic nového. Co bylo ovšem zmen je forma prezentace dat. Je zde uveden graf, který je schopen dynamicky zobrazovat data, která užiˇ Zde lze vybírat na základeˇ vatel vybere na základeˇ parametru˚ uvedených na téže strane. ˇ území a období, pˇriˇcemž data jsou cˇ lenena dle kategorií. Kromeˇ grafu je zde uveden ješteˇ ˇ vybarvování sloupcu˚ v pomeru ˇ k ostatním hodnojeden vizuální prvek a to sice podmínené ˇ náklady, tržby a zisk. tám. Lze tak na první pohled odlišit, která kategorie má nejvetší • V poslední cˇ ásti je uveden pˇrehled indikátoru stavu zisku, který byl navržen a popsán v pˇredchozí 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 pˇredstavuje cˇ íselnou metu, které chce podnik dosáhnout. ˇ pomocí ikon, které se nastaví na patˇriˇcný tvar pomocí Sloupce stav a trend jsou znázorneny vypoˇcítaných hodnot z vytvoˇrené 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

ˇ pomocí ruzných Cílem této cˇ ásti je vytvoˇrit data miningový model a ten vzápetí ˚ metod analyzovat. Výstupem této kapitoly budou jednak schémata a grafy vytvoˇrené v programu Analysis Services, a zárovenˇ také ruzné ˚ poznatky a vztahy mezi zkoumanými atributy daného podnikového procesu 87 ˇ ˇ data miningu do systému se stejneˇ jako v pˇredchozích cˇ ástech cˇ i oddelení. Proces zaˇclenení

ˇ do nekolika ˇ dá rozdelit fází. 1. Vymyšlení zkoumaných parametru˚ 2. Vytvoˇrení datové struktury pro zkoumání 3. Vytvoˇrení modelu˚ pro zkoumání 4. Zkoumání dat Nejprve je tedy tˇreba rozhodnout, které vztahy a souvislosti mezi daty se budou zkoumat. Pro proˇ ˇ dejní odvetví je bezesporu nejduležit ˚ ejším faktorem vztah mezi zákazníkem a produktem, který ˇ et, ˇ kupuje. Proto lze formulovat otázku, na kterou se následná analýza dat bude snažit odpoved ˇ „Jaký je vztah mezi vlastnostmi zákazníka88 a typem produktu, který poˇrizuje?” Jako následovne: konkrétní pˇríklady mohou posloužit následující úvahy: „Kupují si MP3 pˇrehrávaˇce a jinou elektroniku spíše mladí lidé a naopak domácí spotˇrebiˇce spíše lidé starší? Jakou roli hraje v nákupu ˇ zákazníka? Je nejaký ˇ ˇ ˇ poˇcet detí vztah mezi vzdeláním cˇ i zamestnáním zákazníka a typem produktu?” A nebo také: „Kupují si elektroniku spíše bohatí lidé?” ˇ Na základeˇ techto úvah je nutné vytvoˇrit datovou strukturu, ze které je program Analysis Services schopen získat požadované údaje. Byla tedy vytvoˇrena 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 vytvoˇren pˇríslušný sloupec a následneˇ byla pomocí SQL pˇríkazu do tabulky naˇctena data z ostatních tabulek datového skladu. Výslednou podobu vytvoˇrené tabulky i se všemi atributy ilustruje obrázek 21. Následneˇ bylo nutné tato data integrovat do programu Analysis Services a urˇcit jednotlivé modely, které se budou analyzovat. Kromeˇ naˇctení samotné tabulky bylo také tˇreba urˇcit atributy, které slouží jako vstup a atributy, které se budou pˇredpovídat. Z úvodu je patrné, že jako vstupní ˇ pohlaví, poˇcet detí, ˇ ukonˇcené vzdelání, ˇ ˇ atributy budou sloužit vek, zamestnání a pˇríjem. Naopak ˇ zkoumané hodnoty budou vybrané typy produktu. ˚ V teoretické cˇ ásti bylo popsáno nekolik odlišných technik a algoritmu˚ pro zkoumání závislostí mezi daty. Pro tento pˇrípad byly jako nejvhodˇ zvoleny metody Decision trees, Clustering, Neural network a Association rules a na základeˇ nejší toho byly také vytvoˇreny patˇriˇcné data miningové modely. 87 Vzhledem

k tomu, že jediným zpusobem, ˚ jak simulovat dvouletý chod provozního systému, bylo data pomocí víˇ ceméneˇ náhodného algoritmu vygenerovat, nelze bohužel oˇcekávat nejaké vysoké závislosti mezi jednotlivými atributy. ˇ Stejneˇ tak je možné, že nekterá výsledná spojení budou naprosto odporovat reálným poznatkum. ˚ Na druhou stranu je ˇ jsou spíše urˇcitou nadstavbou, nebot’ principialneˇ šlo pˇredevším o demonstraci nutné zduraznit, ˚ že výsledky zde uvádené vytvoˇrení 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 vek, ˇ vzdelání, ˇ ˇ zamestnání, pˇríjem atd.

54

4.4

Data mining

4


Poté, co se, stejneˇ jako u OLAP kostky, uvedou modely do produkce, lze již zaˇcít se samotným ˇ „dolováním” dat. Výsledky jsou rozdeleny 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 ruzné ˚ výstupy, stejnojmenný Decision tree a Dependency network. • Decision tree - toto schéma zobrazuje hodnoty atributu, ˚ které nejvíce ovlivnily nákup zvoˇ že v nejvíce pˇrípadech je nákup ovlivnován ˇ leného typu produktu. Je videt, pohlavím záˇ Je videt, ˇ že z mužu˚ kazníku. ˚ U domácího kina však má na nákup produktu vliv také vek. 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 pˇredešlého schématu ovšem ˇ jejich vztahy a zárovenˇ jejich síla. Jak již bylo v grafické podobeˇ tak, aby byly jasneˇ videt ˇreˇceno, nákup produktu˚ nejvíce ovlivnuje ˇ ˇ který má však pohlaví, dále pak pˇríjem a vek, ˇ že vliv pouze na nákup domácího kina. Co se týˇce síly jednotlivých vztahu, ˚ je možné videt ˇ vliv má pohlaví zákazníka na nákup digitálního fotoaparátu. nejvetší

Neural network ˇ ˇ Tato metoda poˇcítá konkrétní hodnoty a pravdepodobnosti toho, jak moc dané atributy ovlivnují ˇ jestli zákazníci s touto vlastností spíše kupují cˇ i koupi produktu. U každého atributu lze videt, nekupují daný produkt. Zárovenˇ je také u obou možností uvedeno dˇríve definované skóre, které urˇcuje 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 napˇríklad ukazuje, že všichni zákazníci, kteˇrí jsou povoláním konzultanti, zásadneˇ ˇ r 30% zákazníku˚ ve veku ˇ nekupují LCD televize, zatímco témeˇ 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 tˇri ruzné ˚ 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 89 ˇ pravdepodobnost spoleˇcného výskytu, nebo má tento poznatek vysokou duležitost. ˚

ˇ že algoritmus našel velké množství spojení se 100% pravdepodobností ˇ Je videt, výskytu. ˇ si kupují digitální fotoaparát, všichni lékaˇri Napˇríklad všichni manažeˇri, kteˇrí mají dveˇ deti ˇ s vysokoškolským vzdeláním si kupují domácí kino atd. Naopak za nejvíce využitelný poznaˇ tek, ovšem jen se 40% pravdepodobností výskytu, tato metoda považuje fakt, že zákazníci, kteˇrí pracují jako právníci a mají jedno díteˇ si nekupují ledniˇcku. ˇ se vyskytující hodnoty atributu˚ v testovacím • Itemsets - tento výstup zobrazuje nejˇcasteji ˇ že se jedná pˇredevším o kombinace nákupu˚ ruzných souboru. Je videt, ˚ typu˚ produktu. ˚ Naopak nejméneˇ se vyskytující kombinace byla napˇríklad IT specialista s ukonˇceným základním ˇ vzdeláním, který si poˇrizuje domácí kino. ˇ • Dependency network - tato metoda zobrazuje všechny zjištené asociace a jejich sílu v graˇ Asociací je samozˇrejmeˇ obrovské množství, a tak je nutné ty méneˇ duležité fické podobe. ˚ ˇ vztah mají konzultanti, ekonomové cˇ i zpeváci ˇ vyfiltrovat. Tak lze zjistit, že nejsilnejší 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 duležitost ˚ popisuje tuto vlastnost jako využitelnost v praxi.

56

4.4

Data mining

4


Obrázek 23: Dependency network

Clustering ˇ Princip tohoto algoritmu spoˇcívá v rozdelení testovaného souboru na urˇcité skupiny dat, clustery. ˇ ˇ cím podobné, naopak jednotlivé Do techto clusteru˚ jsou vkládány pouze objekty, které si jsou neˇ ˇ ˇ clustery musí být, pokud možno, co nejodlišnejší. Tato metoda má hned nekolik výstupu. ˚ ˇ diagram vztahu˚ mezi jednotlivými clustery. Opet ˇ je možné • Cluster diagram - zde je videt ˇ vztahy a tak je videt, ˇ že nejvetší ˇ vazba je mezi 8. a 10. clusterem. filtrovat pouze silnejší ˇ všechny • Cluster profiles - toto je hlavní výstup celé metody. Jsou zde graficky znázorneny ˇ je jasneˇ zkoumané atributy v závislosti na jednotlivých clusterech. Díky tomuto znázornení ˇ pomer ˇ obsahu atributu˚ s urˇcitou hodnotou v daném clusteru a je tak možné zjišt’ovat, videt ˇ zda má tato skuteˇcnost nejaký vliv na zkoumané veliˇciny. V konkrétním pˇrípadeˇ si lze všimnout, že ve cˇ tvrtém clusteru jsou takˇrka výhradneˇ zákazˇ ˇ že tento fakt nijak neovlivnuje ˇ níci, kteˇrí mají vysokoškolské vzdelání. Pˇresto je videt, výši prodaných produktu. ˚ Stejný efekt lze pozorovat i ve tˇretím clusteru, který je tvoˇren z 94% ˇ ženami, pˇresto nelze pozorovat nejakou závislost mezi prodanými kusy produktu. ˚ ˇ • Cluster characteristics a Cluster discrimination - v techto výstupech lze prohlížet obsah jednotlivých clusteru˚ a zárovenˇ je navzájem porovnávat. V tomto pˇrípadeˇ neobsahují žádné nové poznatky.90 90 Další

grafické výstupy data miningových algoritmu˚ jsou uvedeny v pˇríloze 1.

57

4.4

Data mining

4


ˇ rit, jak Kromeˇ konkrétních hodnot vypoˇcítaných na základeˇ výše uvedených metod, lze také oveˇ pˇresné tyto výpoˇcty byly na základeˇ tzv. lift chart grafu. Tento graf zobrazuje jednotlivé algoritmy v porovnání s ideálním modelem výpoˇctu. Tedy takovým modelem, který z testovacího souboru ˇ že procentuální obsahujícího 50% dat, je schopen urˇcit všechny vztahy a závislosti. Je videt, ˇ úspešnost použitých algoritmu˚ se pohybovala pˇri tomto obsahu kolem 35%, což se dá oznaˇcit ˇ eˇ pˇresný výpoˇcet. za prum ˚ ern Dalším výstupem je tzv. prediction. Jedná se o algoritmus, který je schopen urˇcit s jakou ˇ pravdepodobností se v budoucnu naplní zkoumaný jev. V tomto pˇrípadeˇ bylo zkoumáno, s jakou ˇ pravdepodobností si daný zákazník v budoucnu zakoupí domácí kino cˇ i MP3 pˇrehrávaˇc. Tyto ˇ ˇ i výjimky, napˇríklad zákazník cˇ íslo 1 hodnoty se vetšinou pohybovaly kolem 95%, ovšem lze videt ˇ si koupí pˇrenosný pˇrehrávaˇc „pouze” s pravdepodobností 77%.91 91 Výpoˇ ˇ ˇ cet techto pravdepodobností se nachází v tabulce data_mining_prediction v datovém skladu, nebot’ to byl jediný zpusob, ˚ jak vypoˇcítané výsledky uložit.

58

5

5

ˇ ZÁVER

ˇ Záver

ˇ ekonomická situace a jakým zpusobem ˇ V souvislosti s tím, jak se mení ˚ se zvetšuje objem podnikových dat, jsou firmy nuceny využívat stále více informaˇcních systému˚ na podporu jejich rozhodování. Zárovenˇ vzniká potˇreba z firemních dat extrahovat potenciálneˇ využitelné informace ˇ pro rozvoj podniku. Jedním ze systému, ˚ které toto umožnují, je i Business Intelligence a jeho nezbytná souˇcást, datový sklad. ˇ rit onu nezbytnost datového skladu ve spojení s BI, pˇreTato práce si kladla za cíl jednak oveˇ ˇ znázornit veškeré výhody, které z tohoto spojení plynou. Tato problematika devším pak ale chtela ˇ byla rozložena do nekolika kapitol, kde byla postupneˇ studována. V první kapitole byly nejprve popsány a porovnány možné pˇrístupy k vytvoˇrení datových ˇ skladu. ˚ Bylo zjišteno, že pˇredevším díky menším finanˇcním nárokum ˚ a možnosti budovat datový ˇ sklad postupným zpusobem, ˚ je v dnešní dobeˇ upˇrednostnován spíše pˇrístup Ralpha Kimballa. Zárovenˇ byl v této kapitole porovnán datový sklad s operaˇcní databází a byly urˇceny jejich výhody a nevýhody s ohledem na využití pro BI. Vzhledem k tomu, že normalizované databáze jsou koncipovány pˇredevším pro transakˇcní operace, zatímco datové sklady díky své dimenzioˇ provádení ˇ rozsáhlých analytických dotazu˚ ve srozumitelné podobe, ˇ bylo nální struktuˇre umožnují prokázáno, že datový sklad pˇredstavuje pro BI takˇrka 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šteno, že jedineˇ dimenzionální struktura datového skladu je schopna zaruˇcit jednoduchost, která je základem pro vytváˇrení veškerých reportu, ˚ a proto je ˇ r nezbytné. U OLAP analýzy bylo ˇreˇceno, že datový v tomto pˇrípadeˇ využití datového skladu témeˇ sklad pˇredstavuje v podstateˇ jediný možný zdroj, nebot’ i vytvoˇrení MDD musí probíhat z dimenzionálního modelu. Datový sklad je navíc schopen fungovat pˇrímo jako základ pro analytické dotazování, které je v tom pˇrípadeˇ nazýváno ROLAP. Pro využití datového skladu jako zdroje pro data mining je, spíše než jeho struktura, duležitý ˚ fakt, že obsahuje velké množství historických dat, ˇ této kapitoly byly které potˇrebují jednotlivé data miningové metody pro svuj ˚ výpoˇcet. Na záver ˇ smery, ˇ kterými se v souˇcasné dobeˇ vývoj datových skladu˚ a BI ubírá. Byly definovány nastíneny pojmy Real-time Business Intelligence a také Data warehousing 2.0, který pˇredstavuje možného nástupce pro souˇcasnou 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 úˇcelem vytvoˇrenou, fiktivní firmu. Následneˇ byl tento datový sklad použit pro vytvoˇrení ruzných ˚ typu˚ reportu. ˚ V pˇrí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 vytvoˇrena multidimenzionální databáze, která byla poté podrobena sérii analytických dotazu. ˚ V této cˇ ásti byl také kladen duraz ˚ na použití moderních ˇ k dispozici. U BI byl znázornen ˇ posun z komplexních specialiaplikací, které jsou v tomto odvetví

59

5

ˇ ZÁVER

ˇ eˇ rozšíˇrených kanceláˇrských programu˚ jakým je napˇríklad Microsoft zovaných aplikací až do bežn Excel. Lze tedy ˇríci, že práce splnila to, co si v úvodu pˇredsevzala. 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 operaˇcní databáze, pˇrináší BI velké množství výhod a možností. Bude však zajímavé sledovat vývoj tohoto ˇ odvetví do budoucna, nebot’, jak bylo v práci uvedeno, již nyní jsou známy technologie, které mají potenciál souˇcasnou 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: [10] Data warehouse - Wikipedia, the free encyklopedia [online]. poslední revize 15.3.2010 [cit. 2010-03-16]. Dostupné z: [11] Star schema - Wikipedia, the free encyklopedia [online]. poslední revize 15.3.2010 [cit. 201003-16]. Dostupné z: [12] Snowflake schema - Wikipedia, the free encyklopedia [online]. poslední revize 15.3.2010 [cit. 2010-03-16]. Dostupné z: [13] Kimball vs. Inmon...or, How to build a Data Warehouse [online]. 8.8.2006. [cit. 2010-0319]. Dostupné z: 63

[14] GREENFIELD, Larry. The Data Warehousing Information Center [online]. 1995. poslední revize 14.1.2010 [cit. 2010-03-19]. Dostupné z: [15] UTLEY, Craig. Designing the Star Schema Database [online]. 1995. Ver. 1.1. poslední revize 17.7.2008 [cit. 2010-03-23]. Dostupné z: [16] FIRESTONE, The

Data

Joseph

M.

Warehouse

Dimensional

[online].

Modeling

22.6.1998,

[cit.

and

E-R

Modeling

In

2010-03-24].

Dostupné

z:

[17] KIMBALL, prise

Ralph.

[online].

Fact

Tables

1.1.2003,

[cit.

and

Dimension

2010-03-25].

Tables

Dostupné

z:

Intelligent

enter-

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: [19] Hierarchy - OLAP.com, Your Source to Learn about OLAP [online]. poslední revize 9.3.2009 [cit. 2010-04-19]. Dostupné z: [20] Real-Time Business Intelligence - Gravic [online]. c2010, [cit. 2010-04-22]. Dostupné z: [21] AZVINE, the

B.;

Adaptive

CUI,

Z.,

Enterprise

et

al.

Real

[online].

Time [cit.

Business

Intelligence

for

2010-04-22].

Dostupné

z:

[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: [23] Data Warehousing Concepts - Oracle [online]. poslední revize 17.5.2004 [cit. 2010-03-15]. Dostupné z:

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ý pˇrístup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

18

5

ˇ Hvezdicové schéma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

21

6

Vloˇckové 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

Pˇrehled zákazníku˚ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

48

19

Pˇrehled 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 - pˇríklad drill up/down funkˇcnosti . . . . . . . . . . . . . . . . . . . .

I

25

OLAP analýza - pˇrí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 pˇríloh • Pˇríloha 1 - Dodateˇcné výstupy OLAP analýzy a data miningu • Pˇríloha 2 - CD s výstupy praktické cˇ ásti

67

ˇ ˇ PRÍLOHA 1 - Dodatecné výstupy OLAP analýzy a data miningu Obrázek 24: OLAP analýza - pˇríklad drill up/down funkˇcnosti

I

Obrázek 25: OLAP analýza - pˇrí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 pˇrilož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 vytvoˇrení multidimenzionální databáze /pruvodce - soubor s informacemi o instalaci /Report1 - report s pˇrehledem zákazníku˚ /Report2 - report s pˇrehledem týdenních tržeb

VIII

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

Recommend Documents