Projekt Business Intelligence pro společnost Nutricia, a.s.

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 Ú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. 1

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šší 2

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. 3

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 4

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. 5

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. 6

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 7

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. 8

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. 9

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'. 10

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 11

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čí. 12

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

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. 14

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čí. 15

Obrázek 2.12 - Data Flow Customer 16

Schéma vrstvy L1 Obrázek 2.13 - Schema vrstvy L1 17

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" 18

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. 19

3.1 Koláčový graf Výběr dat pro manažerský report SQL příkaz pro výběr dat 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 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. 20

Koláčový graf Obrázek 3.1 Graf prodeje výrobků za rok 2009 21

3.2 Liniový graf Výběr dat pro manažerský report SQL příkaz pro výběr dat SELECT FROM dimension_time.month_name, SUM([Transaction].Amount) AS SumAmount [Transaction] INNER JOIN dimension_time ON [Transaction].TimeKey = dimension_time.day_key WHERE (dimension_time.year_name = 2009) GROUP BY dimension_time.month_name 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 22

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). 23

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é 24

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. 25

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). 26

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%. 27

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 Amount FC Amount Discount Quantity Popis Částka ve standardní měně Částka v originální měně Procentní sazba slevy Množství, počet 28

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 Cost Price Standart Description Group Name Item Code Item Group Item Type Net Weight Packing Sales Package Price Type Popis Prodejní cena výrobku Popis Jméno skupiny Kód výrobku Číslo skupiny Typ výrobku Váha samotného výrobku Váha zabaleného výrobku Prodejní cena balení Typ výrobku Tabulka 4.2 Dimenze Article Hierarchie Group Name Description 29

4.3.2 Dimenze Customer Dimenze Customer slouží k zobrazení zákazníka, který si koupil daný výrobek. Atribut Address City PSC Rating Classification Cust Name Cust Status Cust Type Customer Number Popis Adresa Město PSČ Hodnocení Klasifikace Jméno zákazníka Status zákazníka Typ zákazníka Čí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. 30

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 TimeKey je sloupec ve faktové tabulce, který bude použit jako cizí klíč k časové dimenzi. Atribut Day_IsWorkday Day_Name Day_NumberInMonth Day_NumberInWeek Day_NumberInYear Month_Name Month_NumberInYear Quarter_Name Quarter_NumberInYear Week_Name Week_NumberInYear Year_Name Popis Den je pracovní Datum Číslo dne v měsíci Číslo dne v týdnu Číslo dne v roce Jméno měsíce Číslo měsíce v roce Jméno čtvrtletí Číslo čtvrtletí v roce Číslo týdne Číslo týdne v roce Číslo roku Tabulka 4.4 Dimenze Time Hierarchie Year_Name Quarter_Name Month_Name Day_Name 31

4.3.4 Dimenze Person Dimenze Person slouží k zobrazení, jaký zaměstnanec prodal daný výrobek. Atribut First Name Last Name Full Name Popis Křestní jméno Příjmení 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 Address City State Warehouse Name ZIPCode Popis Adresa Město Stát Jméno skladu PSČ Tabulka 4.6 Dimenze Warehouse 32

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 33

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. 34

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.biverdict.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/>.