Vysoká škola ekonomická v Praze

Fakulta informatiky a statistiky

Vyšší odborná škola informačních služeb v Praze

Student : Karel Hrubý

Vedoucí bakalářské práce : PhDr. Kateřina Julišová

TÉMA BAKALÁŘSKÉ PRÁCE

Projekt Business Intelligence pro společnost

Nutricia, a.s.

ROK: 2009

Zadávací list

Prohlášení

Prohlašuji, že jsem bakalářskou práci na téma Projekt Business Intelligence zpracoval

samostatně a použil pouze zdrojů, které cituji a uvádím v seznamu použité literatury.

V Praze dne 18.12.2009 Podpis

Poděkování

Děkuji své vedoucí PhDr. Kateřině Julišové za pomoc při tvorbě této bakalářské práce.

Abstrakt

Firmy se stále více ohlížejí po systémovém řešení, které si poradí s jejich obrovským

množstvím dat. Účelem Business Intelligence je konvertovat tyto data na poznatky, které

jsou potřebné pro koncové uživatele. Cílem práce je analýza a návrh projektu Business

Intelligence, který by byl vhodný pro danou firmu. Prvním krokem je transformace dat

z transakčních databází do datového skladu. Tato kapitola se skládá z popisu datových pump.

Z datového skladu se dají následně vytvářet reporty, které budou obsahem další části této

práce, skládající se z příkladu manažerského reportu. Další důležitou součástí Business

Intelligence je OLAP analýza uvedená v další kapitole, která popisuje postup vytvoření OLAP

kostky.

Abstract

Companies are still looking for system solution, which can manage their huge amount of

data. The purpose of Business Intelligence is to convert this data to knowledge which is

needed for the end users. The goal of this paper is to outline a Business Intelligence project,

which would be useful for the given company. First step is to transform data from

transactional databases do the data warehouse. This chapter features the description of an

ETL process. Consequently it is possible to create reports from data warehouse, which will

highlight the next section. This part consists of an example of a manager report. Further

important part of Business Intelligence is an OLAP analysis introduced in the next chapter

describing the procedure of creating an OLAP cube.

Obsah

1 Úvod ................................................................................................................................... 1

2 Datový sklad ....................................................................................................................... 4

2.1 Datový tok z transakčního prostředí ........................................................................... 4

2.2 Vrstva L0 - Staging area ............................................................................................. 6

2.2.1 Import dat do vrstvy L0 ........................................................................................ 8

2.3 Vrstva L1 - Relational area ......................................................................................... 10

2.3.1 Import číselníků do vrstvy L1 ............................................................................. 12

2.3.2 Import ostatních dat do L1(LoadL1.dtsx) ........................................................... 14

2.4 Error databáze ........................................................................................................... 18

3 Reporty ............................................................................................................................. 19

3.1 Koláčový graf ............................................................................................................. 20

3.2 Liniový graf ................................................................................................................. 22

4 OLAP kostka ...................................................................................................................... 23

4.1 Metody uložení dat .................................................................................................... 24

4.2 Faktová tabulka ......................................................................................................... 28

4.3 Dimenze ..................................................................................................................... 29

4.3.1 Dimenze Article .................................................................................................. 29

4.3.2 Dimenze Customer ............................................................................................. 30

4.3.3 Dimenze Time ..................................................................................................... 30

4.3.4 Dimenze Person .................................................................................................. 32

4.3.5 Dimenze Warehouse .......................................................................................... 32

4.4 Příklad OLAP kostky ................................................................................................... 33

5 Závěr ................................................................................................................................. 34

6 Zdroje ................................................................................................................................. 1

Seznam obrázků

Obrázek 1.1 – Informace, data, znalosti [1] ............................................................................... 1

Obrázek 2.1 - Popis procesu načítání dat ................................................................................... 5

Obrázek 2.2 - DTSX balíčky ......................................................................................................... 6

Obrázek 2.3 - Tabulky vrstvy L0 .................................................................................................. 7

Obrázek 2.4 - Import do vrstvy L0 .............................................................................................. 8

Obrázek 2.5 –DTSX balíček Imp_Ciselniky.dtsx .......................................................................... 9

Obrázek 2.6 - Vymazání tabulek ............................................................................................... 10

Obrázek 2.7 - Číselník v Excelu ................................................................................................. 10

Obrázek 2.8 – Tabulky L1 ......................................................................................................... 11

Obrázek 2.9 - Load číselníků z vrstvy L0 do vrstvy L1 ............................................................... 12

Obrázek 2.10 - Load číselníku PartnerGroup do vrstvy L1 ....................................................... 13

Obrázek 2.11 - Transformace z vrstvy L0 do vrstvy L1 ............................................................. 14

Obrázek 2.12 - Data Flow Customer ........................................................................................ 16

Obrázek 2.13 - Schema vrstvy L1 ............................................................................................. 17

Obrázek 3.1 – Graf prodeje výrobků za rok 2009 .................................................................... 21

Obrázek 3.2 - Částka za jednotlivé měsíce ............................................................................... 22

Obrázek 4.1 - Snowflake schema ............................................................................................. 24

Obrázek 4.2 - UDM je most mezi uživateli a jejich daty [17] ................................................... 26

Obrázek 4.3 - Výběr metody uložení dat .................................................................................. 27

Obrázek 4.4 – Možnosti agregací ............................................................................................. 28

Obrázek 4.5 – Příklad OLAP kostky .......................................................................................... 33

1

1 Úvod

Business Intelligence (BI) je v poslední době nejvíce se rozvíjejícím oborem v podnikové

oblasti. Firmy chtějí získat konkurenční výhodu a právě jedna z možností je Business

Intelligence, tedy jinak řečeno transformace dat na informace, které se převádějí na

poznatky. Podle [1] jsou data jakékoli vyjádření (reprezentace) skutečnosti, schopné

přenosu, uchování, interpretace či zpracování. Jsou rovněž "surovinou", z níž se tvoří

informace. Informace jsou data, která mají smysl (význam), jsou sdělitelná

(komunikovatelná). I ony jsou "surovina", z níž se tvoří znalost. Poznatek resp. znalosti

(soustava poznatků tvoří znalost) jsou informace a data, jež umíme použít, a jsou začleněná

do souvislostí.

Obrázek 1.1 – Informace, data, znalosti [1]

A co nám BI může nabídnout? Firmy se stále více ohlížejí po řešení, které je schopné

efektivně zpracovat obrovské množství dat, které mají k dispozici a z toho vytvořit potřebné

znalosti. Tyto znalosti dokážou například podstatně snížit náklady na marketingovou kampaň

tím, že se jejich prostřednictvím nechá vyhledat optimální cílová skupina.

2

Definic BI je několik. Jedna například říká, že je to sada procesů, aplikací a technologií mající

za cíl účinně ovlivňovat rozhodovací procesy ve firmě. Aplikace BI pokrývají analytické a

plánovací funkce většiny oblastí podnikového řízení.

Jak ukazuje tabulka 1.1, BI se dnes stává prioritou pro mnoho firem. Právě v době

hospodářské krize, kdy převládá nejistota a pro situaci se vyhledává optimální řešení, hraje

Business Intelligence rozhodující roli, jak zvýšit konkurenceschopnost.

1. Business intelligence

2. Enterprise applications (ERP, CRM and

others)

3. Servers and storage technologies

(virtualization)

4. Legacy application modernization

5. Collaboration technologies

6. Networking, voice and data

communications

7. Technical infrastructure

8. Security technologies

9. Service-oriented applications and

architecture

10. Document management

Tabulka 1.1 - Top 10 Business and Technology Priorities in 2009 [19]

Součástí této práce je i rozbor konkrétního BI řešení pro firmu Nutricia. Jde o vybudování

datového skladu, z kterého se následně vytvářejí reporty, či OLAP kostky.

Práce je ztížená tím, že zaměstnanci firmy Nutricia jsou zvyklí pracovat s Excelem, a proto

budou všechny číselníky upravovat pomocí tohoto nástroje. Samozřejmě by bylo jednodušší

3

udělat front-end aplikaci přímo pro práci s databází, kde lze manipulovat s daty pouze

v rámci této databáze a nemusí se při každé změně transformovat data do Excelu a zpět. Je

však známo, že zaměstnanci se obecně neradi učí nové věci.

4

2 Datový sklad

2.1 Datový tok z transakčního prostředí

Vytvoření datového skladu je nejdůležitější krok v celém procesu Business Intelligence. Bez

kvalitních a vyčištěných dat nelze tvořit reporty či OLAP kostky, které mají nějakou

vypovídající hodnotu. Data se čerpají z transakčních databází, které nejsou na analýzy moc

vhodné. Hlavní rozdíl mezi transakční databází a datovým skladem je ten, že transakční

databáze je navržena a optimalizována pro záznam. OLAP databáze má ale jiný úkol. Má

ukázat to, co se stalo. Například v jakém časovém období jsme utržili peníze za daný výrobek.

Datový sklad musí být navržen a optimalizován na odpovědi analytických dotazů, které jsou

důležité pro naši firmu. Data v datovém skladu jsou optimalizována pouze na čtení. Nové

data se nahrávají za určitý časový úsek, například jednou denně, týdně, měsíčně atd.

Databáze firmy Nutricia se skládá z databáze MS SQL Server 2005, kterou využívá účetní

software EXACT. Dále je mnoho dat uloženo v Excel tabulkách.

V účetním systému EXACT probíhají následující procesy:

1. Vytvoří se prodejní objednávka

2. Z prodejní objednávky se vytiskne dodací list + vytvoří se záznam v tabulce faktura +

vygeneruje se výdej ze skladu

3. Vytištění faktury + zápis do hlavní knihy - účty 604

K zajištění aktuálnosti údajů v datovém skladu firmy Nutricia je zapotřebí nastavit pravidelné

procesy čerpající data do datového skladu ze zdrojových systémů. Jedná se o následující

zdroje:

1. Databáze EXACT (Účetní software), ze které budou data načítána automaticky

2. Sada číselníků, udržovaných v tabulce Ciselniky.xls

5

Obrázek 2.1 - Popis procesu načítání dat

Popis obrázku 2.1

1. Přemístění souborů na Server

2. Datová pumpa – z Excelu do vrstvy L0

3. Datová pumpa – z vrstvy L0 do vrstvy L1

4. Vytvoření L2 pomocí Analysis Services

5. DB Link – převedení databáze z Exactu do vrstvy L1

6. Použití dat pro reporty

7. Použití dat pro OLAP kostku

Transformace dat se provádí pomocí MS Visual Studia 2005 – Integration Services.

Balíčky pro import

Na obrázku 2.2 jsou vidět všechny dtsx balíčky, pomocí nichž se provádí import do vrstvy L0 a

L1.

6

Obrázek 2.2 - DTSX balíčky

2.2 Vrstva L0 - Staging area

Ve vrstvě L0 Stage nejsou definované žádné klíče, vztahy atd. Data se jen transformují

z Excelu do databáze. Struktura tabulek odráží strukturu vstupních souborů. Data v L0 nejsou

viditelná pro koncové uživatele a ještě nejsou připravená na analýzu. Je to jen mezistupeň,

než se data dostanou do vrstvy L1.

Staging area obsahuje extrakty z primárních systémů:

1. Účetní systém EXACT – vzhledem k tomu, že tento systém užívá databázi MS SQL,

tabulky se načtou prostřednictvím DTSX balíčků přímo z databáze a není potřeba

žádné transformace.

2. Master data a ostatní zdrojová data jsou uložena v Excel tabulkách. Ty se nahrají

prostřednictvím DB loaderu.

7

Během nahrání budou probíhat následující kontroly:

1. Kompletní počet a délka záznamů

2. Datový typ (date, integer, number,char…)

Tabulky

Zkratka Cis znamení číselník.

Obrázek 2.3 - Tabulky vrstvy L0

8

2.2.1 Import dat do vrstvy L0

Jednorázový import

Jednorázový import se týká DTSX balíčků (viz Obrázek 2.3), které začínají písmeny Imp.

Jediná výjimka je balíček Imp_Ciselniky. Tento import se provádí opakovaně při změně

číselníku. V těchto datových pumpách probíhá transformace z Excelu do databáze. Dále už se

s těmito daty v Excel souborech pracovat nebude.

V příkladu (Obrázek 2.5) je vidět ukázka ETL procesu (Extract, transform, load ) do vrstvy L0.

• Extract – Extrakt dat z Excelu

• Transform – Transformace dat do jiného kódování

• Load – Import do tabulky v databázi

Obrázek 2.4 - Import do vrstvy L0

Nejdříve se data nahrají do datové pumpy z listu Excelu. Poté se konvertují do požadované

podoby a následně uloží do databáze.

9

Import číselníků z Excelu do vrstvy L0 (Imp_Ciselniky.dtsx)

Tento proces probíhá opakovaně. Číselníky se aktualizují pomocí Excelu a potom se

transformují do databáze vrstvy L0.

Při importu číselníku do vrstvy L0 se nemusí provádět kontrola duplicity, protože se stará

data vždy mažou a nahrazují se aktuálními. Data-flow rámeček Delete (Obrázek 2.5)

obsahuje SQL příkazy truncate (Obrázek 2.6), který nejprve vymaže všechna data

v tabulkách. Data se potom v aktualizované podobě nahrají z Excelu zpět do databáze.

Obrázek 2.5 –DTSX balíček Imp_Ciselniky.dtsx

Každý data-flow na obrázku 2.5 obsahuje jednotlivé listy ze souboru Ciselniky.xls. Importují

se tedy listy PartnerGroup, Subgroup1, PartnerName atd.

10

Obrázek 2.6 - Vymazání tabulek

Na obrázku 2.8 je vidět jak vypadá číselník v Excelu, který se následně transformuje do

databáze. Ve sloupci D se dá záznam ukončit.

Obrázek 2.7 - Číselník v Excelu

2.3 Vrstva L1 - Relational area

Struktury jsou zde zobecněné, popisují business procesy a vazby. Záznamy se historizují,

fyzicky se tedy vůbec nemažou, jen se aktualizují. Historizace probíhá pomocí primárního

klíče složeného z hodnot ID a ValidFrom. Když se záznam aktualizuje, změní se ve sloupci

ValidTo datum na aktuální a k nové hodnotě se nastaví taktéž aktuální datum ve sloupci

ValidFrom. Tím začne být nový záznam aktuální. Nové ValidTo se nastaví automaticky

v databázi na datum '9999-12-31'.

11

Vrstva L1 je nejdůležitější vrstva celého řešení je to integrační vrstva, která je:

• Detailní

• Historická

• Vyčištěná

• Konsolidovaná

Tabulky

Obrázek 2.8 – Tabulky L1

12

2.3.1 Import číselníků do vrstvy L1

Obecný postup - Load číselníků (Load_Ciselniky.dtsx)

Obrázek 2.9 - Load číselníků z vrstvy L0 do vrstvy L1

Každý data-flow na obrázku 2.9 obsahuje jednotlivou tabulku z vrstvy L0. Nejdříve se

provede PartnerGroup a až po jeho dokončení se provede Subgroup1, následovaným

Subgroup2. PartnerName může proběhnout nezávisle na ostatních.

Všechny tyto data-flow jsou velmi podobné, proto bude rozebrán jako příklad data-flow

PartnerGroup. V prvním kroku (Obrázek 2.10) se načtou všechny sloupce dané tabulky (v

tomto případě PartnerGroup) z vrstvy L0. Každý záznam poté přechází dle funkce

'Conditional Split' do jedné ze tří větví.

Do levé větve jdou záznamy, které jsou nové. Jejich ID má hodnotu null. Těmto záznamům se

přiřadí díky funkci 'Derived Column' automaticky vygenerované ID.

Do prostřední větve jdou záznamy s ID, které je již v databázi uloženo. Pokud má záznam

identický ID i jméno (například jméno zákazníka) jedná se o záznam, který se již v databázi

nachází, a proto se s ním dále nepracuje. Pokud je ID stejné, ale jméno je jiné, jde o

aktualizovaný záznam. Tento záznam postupuje dále do databáze. Pomocí funkce 'Derived

Column2' a 'OLE DB Command' se ukončí záznam tak, že se hodnotu ValidTo nastaví na

předešlý den. Novému záznamu se nastaví automaticky v databázi hodnota '9999-12-31'.

Poté se nové a aktualizované záznamy uloží do databáze.

Do pravé větve jdou záznamy, které mají ukončenou platnost, tedy v Excelu se jim nastavila

hodnota 'Ukoncit'. Pomocí funkce 'Derived Column1' a 'OLE DB Command 1' se nastaví

ValidTo na aktuální datum a tím se záznam ukončí.

13

Obrázek 2.10 - Load číselníku PartnerGroup do vrstvy L1

14

2.3.2 Import ostatních dat do L1(LoadL1.dtsx)

Ostatní data jsou Master data z Excelu a data Exactu. Každý data-flow na obrázku 2.11

obsahuje jednotlivou tabulku z vrstvy L0. Nejdříve se provedou současně data-flow

Customer a CostUnit, dále Article, PriceList, Prices, současně Account a CostCenter,

CCAccRealtion, Person a na závěr Warehouse.

Obrázek 2.11 - Transformace z vrstvy L0 do vrstvy L1

Všechny tyto data-flow jsou velmi podobné, proto bude rozebrán jako příklad data-flow

Customer. V prvním kroku (Obrázek 2.12) se načtou všechny sloupce dané tabulky (v tomto

případě Customer) z vrstvy L0. Každý záznam poté jde dle funkce 'Conditional Split' do jedné

ze tří větví.

Do levé větve postupují záznamy, které jsou nové. Jejich ID má hodnotu null. Těmto

záznamům se přiřadí díky funkci 'Derived Column' automaticky vygenerované ID.

15

Do prostřední větve jdou záznamy s ID, které je již v databázi uloženo. Pokud má záznam

identický ID i jméno (například jméno zákazníka), jde o záznam, který se již v databázi

nachází, a proto se s ním dále nepracuje. Pokud je ID stejné, ale jméno je jiné, jde o

aktualizovaný záznam. Tento záznam postupuje dále do databáze. Následně se kontrolují cizí

klíče k nadřazeným tabulkám PartnerName, Subgroup2 a Country. Jestliže se žádné příslušné

záznamy nevyhledají, spadnou do Error databáze (viz kapitola 2.4). Potom se připojí další

databáze CICMPY (EXACT) a záznamy se sloučí. Následně se zkontroluje, zda není

CustomerCode roven hodnotě NULL. Pomocí funkce 'Derived Column' a 'OLE DB Command'

se ukončí záznam tak, že se hodnotu ValidTo nastaví na předešlý den. Novému záznamu se

nastaví automaticky v databázi hodnota '9999-12-31'. Potom se nové a aktualizované

záznamy uloží do databáze.

Do pravé větve jdou záznamy, které mají ukončenou platnost, tedy v Excelu se jim nastavila

hodnota 'Ukoncit'. Pomocí funkce 'Derived Column1' a 'OLE DB Command 1' se nastaví

ValidTo na aktuální datum a tím se záznam ukončí.

16

Obrázek 2.12 - Data Flow Customer

17

Schéma vrstvy L1

Obrázek 2.13 - Schema vrstvy L1

18

2.4 Error databáze

Error databáze slouží pro záznamy, které nejsou kompletní, nebo jsou duplicitní. Zde nejsou

definované žádné vztahy. Každá tabulka v této databázi obsahuje sloupec Chyba, takže se

vždy pozná, proč daný záznam skončil právě zde. Předpokládá se, že uživatel podle chybové

hlášky záznam upraví a díky tomu se dostane do datového skladu.

Příklad chybových hlášek:

• "Nedošlo k vyhledání cizího klíče v tabulce 205.CICMPY"

• "Nedošlo k vyhledání cizího klíče v tabulce PartnerSubgroup2"

• "Sloupec reknr (Account) neobsahuje číselnou hodnotu"

19

3 Reporty

Reporty se provádějí pomocí MS Visual Studia – Reporting Services. Reporting Services

dokážou získávat data z rozličných databází (př. SQL Server, Oracle, DB2) a přetransformovat

je do různých formátů (HTML, PDF, Excel). Reportovací služby jsou často využívanou oblastí

Business Intelligence. Slouží k vytváření jak papírových, tak interaktivních webových

prezentací provedených analýz.

Díky Report Modelu a Report Builderu jsou schopní i koncoví uživatelé pomocí Drag and

Drop vytvořit své reporty. Jeho rozhraní je podobné Wordu či Excelu, takže uživatel by neměl

mít problém s ním pracovat.

Reportovací služby podporují úplný životní cyklus reportů. Ten začíná vytvořením reportu,

což je práce pro vývojáře. Report je nutné spravovat. SQL Server Reporting Services

podporují jak vyžádané (pull), tak i nabízené (push) doručování sestav. Uživatelům se musí

report zpřístupnit nebo naopak doručit. Doručovány mohou být emailem a zpřístupnit je lze

například uložením do sdíleného adresáře.

Reporty skrývají cenné informace, proto zde hraje důležitou roli bezpečnost. Každá role má

různé oprávnění. Každý uživatel by měl dostat práva jen na ty informace, které opravdu

potřebuje a vše ostatní by se mělo zakázat.

Report je uložen ve formátu RDL (Report Definition Language), který je založen na formátu

XML (Extensible Markup Language). Díky tomu mohou s reportem pracovat i aplikace třetích

stran.

Následující reporty jsou manažerské. Data jsou v nich zpracována do přehledných tabulek a

grafů. Vedení společnosti z nich může získat informace o prodejích rozčleněných na data

jednotlivých zákazníků, dle časových období nebo místa prodeje.

20

3.1 Koláčový graf

Výběr dat pro manažerský report

SQL příkaz pro výběr dat

Graf číslo 3.1 ukazuje prodej výrobků za rok 2009. Pro data je použita suma částek

(Sum(Fields!SumAmount.Value)). Pro třídění do kategorií je použito jméno výrobku

(Group_Name). Legenda je řazena od nejprodávanějšího výrobku.

SELECT Article.Article_Name, SUM([Transaction].Amount) AS SumAmount FROM [Transaction] INNER JOIN dimension_time ON [Transaction].TimeKey = dimension_time.Day_Key INNER JOIN Article ON [Transaction].Article_ID = Article.Article_ID AND [Transaction].Article_ValidFrom = Article.ValidFrom WHERE (dimension_time.Year_Name = 2009) AND ([Transaction].Amount <> 0) AND (Article.Article_ID <> 0) GROUP BY Article.Article_Name

21

Koláčový graf

Obrázek 3.1 – Graf prodeje výrobků za rok 2009

22

3.2 Liniový graf

Výběr dat pro manažerský report

SQL příkaz pro výběr dat

Graf číslo 3.2 ukazuje prodej za jednotlivé měsíce v roce 2009. Pro data je použita suma

částek (Sum(Fields!SumAmount.Value)). Pro třídění do kategorií jsou použity měsíce z časové

dimenze (Month_Name).

Obrázek 3.2 - Částka za jednotlivé měsíce

SELECT dimension_time.Month_Name, SUM([Transaction].Amount) AS SumAmount FROM [Transaction] INNER JOIN dimension_time ON [Transaction].TimeKey = dimension_time.Day_Key WHERE (dimension_time.Year_Name = 2009) GROUP BY dimension_time.Month_Name

23

4 OLAP kostka

OLAP (On Line Analytical Processing) kostka má rychle poskytnout odpovědi na analytické

dotazy. Je nejmodernější podmnožinou systémů na podporu řízení (EIS). Relační databáze se

hodí na transakční zpracování dat, ale ne už tolik na zpracování analytických dotazů nad

daty. Databáze, které jsou určeny pro používání OLAPu, používají multidimenzionální datový

model, který umožňuje velmi rychlé zpracování různých dotazů. Umožňuje to právě díky

dimenzím.

Pro vytvoření vrstvy L2 bylo využito MS Visual Studia - Analysis Services. Použito bylo schéma

snowflake (Obrázek 4.1). Data ve vrstvě L2 nejsou uložena přímo v databázi, ale pouze

cachována v Analysis Services serveru. Data jsou na tento server nahrána podle zvolené

metody (viz kapitola 4.1).

24

Obrázek 4.1 - Snowflake schema

4.1 Metody uložení dat

Kostka se dělí na tři důležité části – metadata, detail a agregovaná data. Je jedno, jaká

metoda bude využita; metadata jsou vždy uložena na OLAP serveru. Detailní data nebo

agregovaná data jsou uložená podle zvolené metody.

MOLAP (Multidimensional OLAP)

Toto je nejčastější metoda uložení dat. Při zpracování kostky jsou zdrojová data nahrána

z relační databáze, vyžadované agregace jsou vykonány a nakonec jsou data uložena v cachi

na Analysis Services serveru v komprimovaném, optimalizovaném a multidimenzionálním

formátu. Poté už neexistuje žádné spojení s relační databází. Jestliže následně dojde k nějaké

25

změně v relační databázi, v kostce už se to nemůže promítnout, dokud není kostka znovu

zpracována. Díky tomu, že jsou data uložena přímo lokálně na OLAP serveru, je MOLAP

metoda velmi efektivní a na pokládané dotazy.

ROLAP (Relational OLAP)

V porovnání s MOLAP, ROLAP nenahrává data z relační databáze na OLAP server, ale detailní

data a agregovaná data zůstávají v relační databázi. Pro uložené agregace databázový server

vytvoří dodatečné indexované pohledy. Data jsou nahrána z relační databáze, pouze pokud

jsou potřeba.

HOLAP (Hybrid OLAP)

Tato metoda je hybrid mezi MOLAP a ROLAP. Pokouší se přinést lepší kapacitu dat ROLAPu a

rychlost zpracování dotazů MOLAPu. V HOLAP metodě zůstávají detailní data v relační

databázi a agregovaná data jsou uložena na OLAP serveru. Jestliže je dotaz položen pouze na

agregovaná data bude HOLAP metoda podobná metodě ROLAP. Pro detailní data sahá

HOLAP do relační databáze, pokud není dotaz uložen v cachi.

UDM (Unified Dimensional Model)

Díky novince v SQL Server 2005 již není zapotřebí vytvářet další databázovou vrstvu. Tato

novinka se jmenuje Unified Dimensional Model (Obrázek 4.2). Dříve bylo běžné vytvořit

datový sklad, který obsahoval jak relační databázi pro ukládání dat, tak i multidimenzionální

databázi pro analytická data.

26

Obrázek 4.2 - UDM je most mezi uživateli a jejich daty [17]

UDM nabízí podstatně pozměněnou strukturu a architekturu, tak aby jeden model posloužil

jakékoliv aplikaci. Data mají nyní větší informační hodnotu než v relačním modelu a co víc,

jsou lépe pochopitelná pro uživatele. Data mohou být uložena na různých operačních

systémech a dokonce i na různých databázových serverech.

V datovém skladu jsou data nejdříve uložena v relační databázi a poté teprve

transformována do multidimenzionální. K propojení těchto dvou databází se dá využít jedna

ze tří metod (viz kapitola 4.1). Metody uložení můžeme podle potřeby měnit (Obrázek 4.3).

27

Obrázek 4.3 - Výběr metody uložení dat

Po zvolení metody je potřeba zadat počet řádku ve faktové tabulce nebo si je můžeme

nechat spočítat automaticky. Poté je potřeba stanovit optimum mezi prostorem, který naše

kostka zabere na pevném disku, a rychlostí výpočtu a přístupu k datům. Na obrázku 4.4 je

vidět, že bylo spočítáno 21 agregací a optimalizovaná úroveň je 43%.

28

Obrázek 4.4 – Možnosti agregací

4.2 Faktová tabulka

Ve faktové tabulce jsou uložena analyzovaná data, v tomto případě data transakcí.

V datovém skladu zabírá faktová tabulka nejvíce místa.

Jediná faktová tabulka Transaction obsahuje měrné jednotky, viz tabulka 4.1. Faktová

tabulka je propojena s dimenzemi pomocí cizích klíčů.

Název měrné jednotky Popis

Amount Částka ve standardní měně

FC Amount Částka v originální měně

Discount Procentní sazba slevy

Quantity Množství, počet

29

Vat Amount Částka DPH ve standardní měně

Tabulka 4.1 – Faktová tabulka

4.3 Dimenze

Data v dimenzích se nemění tak často jako ve faktových tabulkách. Obsahují seznamy hodnot

sloužících ke kategorizaci a třídění dat ve faktových tabulkách. Díky hierarchiím v dimenzi je

možno nastavit jak nižší agregační úroveň (Drill-down), tak naopak vyšší (Roll-up).

Na dimenze můžeme také aplikovat filtr na instance příslušné agregační úrovně (Slicing)

nebo také pro více dimenzí najednou (Dicing).

4.3.1 Dimenze Article

Dimenze Article slouží k zobrazení, jaký výrobek byl prodán.

Atribut Popis

Cost Price Standart Prodejní cena výrobku

Description Popis

Group Name Jméno skupiny

Item Code Kód výrobku

Item Group Číslo skupiny

Item Type Typ výrobku

Net Weight Váha samotného výrobku

Packing Váha zabaleného výrobku

Sales Package Price Prodejní cena balení

Type Typ výrobku

Tabulka 4.2 – Dimenze Article

Hierarchie

• Group Name

• Description

30

4.3.2 Dimenze Customer

Dimenze Customer slouží k zobrazení zákazníka, který si koupil daný výrobek.

Atribut Popis

Address Adresa

City Město

PSC PSČ

Rating Hodnocení

Classification Klasifikace

Cust Name Jméno zákazníka

Cust Status Status zákazníka

Cust Type Typ zákazníka

Customer Number Číslo zákazníka

Tabulka 4.3 – Dimenze Customer

Hierarchie

• Partner Group

• Partner Subgroup1

• Partner Subgroup2

• Cust Name

4.3.3 Dimenze Time

Časová dimenze slouží k zobrazení, v jakém časovém období byl výrobek prodán. Pomocí

webové stránky [23] se vygeneruje časová dimenze. Poté je nutno updatovat faktovou

tabulku pomocí následujícího SQL příkazu.

31

TimeKey je sloupec ve faktové tabulce, který bude použit jako cizí klíč k časové dimenzi.

Atribut Popis

Day_IsWorkday Den je pracovní

Day_Name Datum

Day_NumberInMonth Číslo dne v měsíci

Day_NumberInWeek Číslo dne v týdnu

Day_NumberInYear Číslo dne v roce

Month_Name Jméno měsíce

Month_NumberInYear Číslo měsíce v roce

Quarter_Name Jméno čtvrtletí

Quarter_NumberInYear Číslo čtvrtletí v roce

Week_Name Číslo týdne

Week_NumberInYear Číslo týdne v roce

Year_Name Číslo roku

Tabulka 4.4 – Dimenze Time

Hierarchie

• Year_Name

• Quarter_Name

• Month_Name

• Day_Name

USE DWH_L1 GO UPDATE [Transaction] SET [Transaction].TimeKey = D.Day_Key FROM dimension_time D INNER JOIN [Transaction] ON DATEPART(YY,[Transaction].Date) = D.Year_Name AND DATEPART(MM,[Transaction].Date) = D.Month_Name AND DATEPART(DD,[Transaction].Date) = D.Day_NumberInMonth

32

4.3.4 Dimenze Person

Dimenze Person slouží k zobrazení, jaký zaměstnanec prodal daný výrobek.

Atribut Popis

First Name Křestní jméno

Last Name Příjmení

Full Name Celé jméno

Tabulka 4.5 – Dimenze Person

4.3.5 Dimenze Warehouse

Dimenze Warehouse slouží k zobrazení, z jakého skladu pochází prodaný výrobek.

Atribut Popis

Address Adresa

City Město

State Stát

Warehouse Name Jméno skladu

ZIPCode PSČ

Tabulka 4.6 – Dimenze Warehouse

33

4.4 Příklad OLAP kostky

V této kostce byla použita, v řádkovém poli, dimenze Time, u které se dá drilovat až na

jednotlivé dny. V sloupcovém poli je dimenze Article, kde se nacházejí jednotlivé výrobky.

Obrázek 4.5 – Příklad OLAP kostky

34

5 Závěr

V této bakalářské práci byl představen projekt Business Intelligence, který byl úspěšně

ukončen. Cíle, které byly stanoveny, se podařilo řádně dokončit, tedy předně vytvořit datový

sklad a pomocí datových pump do něj nahrát data ze zdrojových systémů. Další krok, který

se podařil uskutečnit, bylo vytvoření ukázkového manažerského reportu. V závěru byla

vytvořena multidimenzionální databáze, která využívá snowflake schéma pro účely OLAP

kostky. Vytvoření OLAP kostky je velmi složitý úkol, ale k nastínění problematiky by ukázaná

kostka jako příklad měla stačit. Až čas ukáže chyby v datovém skladu, které bude nutné

opravit.

6 Zdroje

[1] LACKO, Luboslav. Business Intelligence v SQL Serveru 2005. 2006. Computer press, 2006. 388 s. ISBN 80-251-1110-5.

[2] HUMPHRIES, , Mark , HAWKINS, Michael W. , DY, Michelle C. . Data warehousing : Návrh a implementace. Computer press, 2002. 256 s. ISBN 8072265601.

[3] POUR, Jan , GÁLA, Libor , ŠEDIVÁ, Zuzana . Podniková informatika. GRADA, 2009. 496 s. ISBN 978-80-247-2615-1.

[4] LACKO, Luboslav . Databáze: datové sklady, OLAP a dolování dat . Computer Press, 2003. 488 s. ISBN 80-7226-969-0.

[5] SACK , Joseph . Mistrovství v Transact-SQL. Zoner Press, 2007. 864 s. ISBN 97880806815572.

[6] KNIGHT, Brian , VEERMAN, Erik . Expert SQL Server 2005 Integration Services.

Wrox Press, 2007. 432 s. ISBN 978047013411. Expert SQL Server 2005 Integrační služby

[7] HANCOCK, John, TOREN, Roger. Practical Business Intelligence with SQL Server 2005 . Addison-Wesley Professional, 2006. 432 s. ISBN 0-321-35698-5. Business Intelligence prakticky v SQL serveru 2005

[8] VIEIRA, Robert. Beginning SQL Server 2005 Programming. Wrox Press, 2006. 720 s. ISBN 978-0-7645-8433-6. Začínáme programovat v SQL serveru 2005

[9] DEWSON, Robin. Beginning SQL Server 2005 for Developers : From Novice to Professional. Wiley, 2006. 536 s. ISBN 1-59059-588-2. Začínáme s SQL serverem 2005, pro vývojáře: od začátečníka po profesionály

[10] WIGHTMAN , Jim . Pro SQL Server 2005 Integration Services. Apress, 2007. 548 s. ISBN 1-59059-897-0. Pro SQL Server 2005 Integrační služby

[11] TAYLOR, Allen G. . SQL For Dummies : 5th Edition . For Dummies, 2003. 408 s. ISBN 07645-4075-0.

[12] ENGLISH, Larry P. Improving Data Warehouse and Business Information Quality : Methods for Reducing Costs and Increasing Profits . John Wiley & Sons, 1999. 544 s. ISBN 0471253839. Vylepšujeme datový sklady a kvalitu byznys informací

[13] DBForums [online]. 2009. Dostupný z WWW: <http://www.dbforums.com/>. [14] The BI Verdict [online]. 2009. Dostupný z WWW: <http://www.bi- verdict.com/>. [15] Microsoft [online]. 2009. Dostupný z WWW: < http://www.microsoft.com/>. [16] Builder [online]. 2009. Dostupný z WWW: < http://builder.cz/>.

[17] Gartner CIO Survey. 2009. Dostupný z WWW:

<http://www.gartner.com/it/page.jsp?id=855612/>.

[18] POUR, Jan. 19. Co lze očekávat od business inteligence?. www.vse.cz [online]. 2006 [cit. 2009-11-05]. [19] Materiály z přednášek

[20] Regnecentralen [online]. 2009. Dostupný z WWW: < http://www.regnecentralen.dk/time_dimension_generator.html/>.