Vytvoření datového skladu

Transkript

1 Bankovní institut vysoká škola Praha Katedra informatiky a kvantitativních metod Vytvoření datového skladu Diplomová práce Autor: Petr Havlas Informační technologie a management Vedoucí práce: doc. Ing. Bohumil Miniberger, CSc. Praha Červen, 2015

2 Prohlášení: Prohlašuji, že jsem diplomovou práci zpracoval samostatně a v seznamu uvedl veškerou použitou literaturu. Svým podpisem stvrzuji, že odevzdaná elektronická podoba práce je identická s její tištěnou verzí, a jsem seznámen se skutečností, že se práce bude archivovat v knihovně BIVŠ a dále bude zpřístupněna třetím osobám prostřednictvím interní databáze elektronických vysokoškolských prací. V Praze, dne Podpis autora

3 Poděkování: Děkuji doc. Ing. Bohumilu Minibergrovi, CSc. za podporu a odborné vedení během mé práce.

4 Anotace Tématem diplomová práce je proces tvorby datového skladu v prostředí telekomunikační firmy. V první části práce popisuje oblast Business Intelligence, datových skladů a dimenzionálního modelování, dále se věnuje popisu telekomunikační firmy, jejího IS a podnikových procesů. Praktická část je věnována krokům tvorby dimenzionálního modelu, jak je definuje Ralph Kimball, návrhu ETL procesů s přihlédnutím ke kvalitě dat a návrhu implementace datového skladu. Klíčová slova Business Intelligence, datové tržiště, datový sklad, dimenze, ETL, etom, fakta, Frameworkx Annotation The diploma thesis is focused on the process of building the data warehouse in a telecommunication company. The first theoretical part describes the area of Business Intelligence, data warehousing, and dimensional modeling. It also describes the business processes and the information system of a telecommunication company. The second practical part is devoted to the steps of dimensional modeling, as defined by Ralph Kimball, to the design of ETL processes, taking data quality into account, and to the implementation of the data warehouse. Key words Business Intelligence, Data Mart, Data Warehouse, Dimension, ETL, etom, Fact, Frameworkx

5 Obsah ÚVOD BUSINESS INTELLIGENCE ARCHITEKTURA A MODELY DATOVÉHO SKLADU BUSINESS INTELLIGENCE Prvky BI architektury Architektury datového skladu DIMENZIONÁLNÍ MODEL Fakta Dimenze TELEKOMUNIKAČNÍ FIRMA IS TELEKOMUNIKAČNÍ FIRMY Telekomunikační síť Mediace Provisioning Rating Billing Customer Relationship Management FRAMEWORKX Procesní rámec etom TVORBA DIMENZIONÁLNÍHO MODELU PODNIKOVÉ PROCESY Využití služeb sítě (CDR data mart) Fakturace Balance účtu Správa objednávek Servisní požadavky DIMENZE Adresa Audit Datum a čas Fakturační cyklus Kontakt Lokalita Produkt Subscriber, fakturační účet a zákazník Zaměstnanec Sběrnice datového skladu IDENTIFIKACE FAKTŮ NÁVRH PROCESŮ NA PLNĚNÍ DATOVÉHO SKLADU ZE ZDROJOVÝCH SYSTÉMŮ DATOVÁ KVALITA PLNĚNÍ DATOVÉHO SKLADU ŘÍZENÍ ETL PROCESŮ IMPLEMENTACE DATOVÉHO SKLADU ODS ETL SYSTÉM DATOVÝ SKLAD ZÁVĚR

6 Úvod Cílem této diplomové práce je seznámit se s problematikou datových skladů a dimenzionálního modelování, provést analýzu informačního systému (IS) telekomunikační firmy a navrhnout vhodný počáteční inkrement datového skladu, který bude možné implementovat v relativně krátkém čase a přitom pokryje základní potřeby pro reporting s důrazem na zákaznickou zkušenost. Se vzrůstajícím objemem dat roste potřeba analýzy dat a z toho se odvíjí také zvyšující se nároky na oblast Business Intelligence (BI) a datových skladů. Datový sklad není nový pojem, začal se objevovat již v sedmdesátých letech dvacátého století, za otce tohoto pojmu je považován William Inmon. S problematikou datových skladů a celého BI je provázáno také dimenzionální modelování: pojmy dimenze a fakta se objevily již v šedesátých letech dvacátého století, dnes je pojem dimenzionální modelování spojen především se jménem Ralpha Kimballa. Dnes jsou Inmon a Kimball považováni za tvůrce dvou základních paradigmat, na nichž se budují moderní datové sklady. V teoretické části diplomové práce se seznámíme se základními pojmy a architekturou BI, porovnáme základní přístupy ke tvorbě datového skladu, především Hub and Spoke architekturu Williama Inmona a sběrnicovou architekturou Ralpha Kimballa, také se seznámíme se základy dimenzionálního modelování. Praktickou část tvoří tři kapitoly: v první se zaměříme na návrh modelu datového skladu podle metodiky Ralpha Kimballa. Tato metodika umožňuje snadné rozdělení tvorby datového skladu na menší přírůstky a tedy i rozložení nákladů do delšího období, zároveň umožňuje získat první výstupy poměrně brzy. Představíme si typický model IS telekomunikační firmy a rámec Frameworkx organizace TeleManagement Forum, na základě procesního rámce etom a podnikových metrik (oboje je součástí Frameworkx) vybereme základní procesy (budoucí datová tržiště), které budeme modelovat. Při výběru modelovaných procesů se zaměříme na procesy typické pro telekomunikační firmu. Dalšími kroky návrhu datového skladu je volba granularity modelovaných procesů, výběr popisných dimenzí (v metodice Ralpha Kimballa se jedná o důležitý krok, protože dimenze tvoří základ integrace datového skladu). Posledním krokem tvorby dimenzionálního modelu je výběr faktů, které budeme sledovat. Výstupem první kapitoly praktické části bude dimenzionální model datového skladu. 6

7 Druhá kapitola praktické části se zaměřuje na plnění datového skladu, tedy na výběr zdrojových dat, jejich transformaci a plnění do datového modelu vytvořeného v předchozí kapitole. V poslední kapitole se zaměříme na návrh nasazení datového skladu s využitím HW a SW produktů firmy Oracle. 7

8 1 Business Intelligence architektura a modely 1.1 Business Intelligence datového skladu Gála 1 popisuje Business Intelligence (BI) jako specifický typ úloh informatiky, které se zaměřují především na podporu analytických, plánovacích a řídících činností organizace. Těmto činnostem je potom podřízen výběr principů a technologií, na kterých je BI architektura budována. Pokud se snažíme pochopit podstatu BI, je dobré se zaměřit právě na činnosti, které má BI podporovat a v čem se potřeby těchto činností liší od potřeb běžných provozních úloh v organizaci. Pro provozní prostředí je typické transakční zpracování, hovoříme o tzv. OLTP (On-Line Transactional Processing) aplikacích a databázích, v praxi to znamená důraz na detailní data a informace, podporu paralelního zpracování, rychlou odezvu, krátké transakce apod. Naopak analytické zpracování (tento typ aplikací a databází se nazývá OLAP, On-Line Analytical Processing) se zaměřuje především na ukazatele a jejich vývoj z různých hledisek, včetně časového. Tomuto účelu je nutné přizpůsobit jak výběr dat ze zdrojových systémů, tak jejich organizaci v analytických databázích. Odlišné zaměření produktů pro BI je dobře vidět například na databázovém systému Teradata 2, který je navržen speciálně pro tvorbu datových skladů. Tento databázový systém se zaměřuje především na manipulaci s velkým objemem dat, na druhou stranu tento produkt není optimalizován pro požadavky OLTP systémů a pro tento typ nasazení je nevhodný Prvky BI architektury Obecně lze BI architekturu rozdělit do několika základních vrstev: vrstvu zdrojových aplikací a databází, transformační vrstvu, vrstvu analytických databází a nakonec vrstvu analytických aplikací a prezentace informací (obrázek 1). 1 GÁLA, Libor, Jan POUR a Zuzana ŠEDIVÁ. Podniková informatika. 2., přeprac. a aktualiz. vyd. Praha, 2009, 496 s. Expert (Grada). ISBN

9 Zdrojové systémy Transformace dat Analytické databáze Analytické a prezentační aplikace OSS/BSS ETL Datové tržiště Datový sklad Datové tržiště Dolování dat Reporting Portály Dashboard Scoreboard Excel ERP OLAP databáze Obrázek 1: Základní vrstvy řešení BI Zdroj: autor, upraveno podle 3 Vrstva zdrojových systémů je vrstvou produkčních aplikací a OLTP databází, které obsahují data potřebná pro analytickou část. Na vrstvu zdrojových systémů navazuje vrstva transformační, tuto vrstvu tvoří datové pumpy (ETL procesy), které mají za úkol extrakci dat ze zdrojových systémů, transformaci těchto dat a nakonec nahrání do analytických databází. Součástí této vrstvy jsou také datová úložiště nazývaná Data Staging Area (DSA) a já bych sem řadil také procesy datové integrace (Gála 4 tyto procesy označuje jako Enterprise Application Integration - EAI) a Operation Data Store (ODS). Zařazení ODS není zcela jednoznačné, toto úložiště může být řazeno také mezi zdrojové systémy nebo mezi analytické databáze (ODS je často využíván jako zdroj provozních reportů, především pokud je nutné je spouštět nad aktuálními daty), záleží na konkrétní úloze tohoto datového úložiště v implementaci BI architektury. Transformační vrstva je jednou z klíčových součástí BI architektury, jejím úkolem je plnění analytických databází požadovanými daty, musí zajistit potřebnou datovou kvalitu, odstranění multiplicit a další. Vrstvou analytických databází máme na mysli především samotný datový sklad a další databáze používané v BI architektuře, tedy případná datová tržiště (může se jednat o samostatné databáze nebo jsou přímo součástí datového skladu) a multidimenzionální OLAP databáze, které mohou být součástí různých analytických aplikací. Poslední vrstvu tvoří analytické aplikace, aplikace pro dolování dat (data mining) a aplikace pro prezentaci výsledků a informací pro uživatele. Může se jednat o Microsoft Excel, webové portály a různé 3 GÁLA, Libor, Jan POUR a Zuzana ŠEDIVÁ. Podniková informatika. 2., přeprac. a aktualiz. vyd. Praha, 2009, 496 s. Expert (Grada). ISBN s Tamtéž, s

10 dashboardy či scoreboardy. Na obrázku 2 jsou znázorněny vazby mezi základními komponentami BI architektury. Obrázek 2: BI architektura Zdroj: autor, upraveno podle 5 Kromě uváděných komponent jsou součástí BI řešení také nástroje pro zajištění datové kvality a pro správu metadat Primární zdrojové systémy Jedná se o různorodou množinu aplikací a databází (mohou být i externí), které slouží jako zdroj dat pro datový sklad, data mohou být ve formě databáze, textových souborů (flat files) apod. Při vzniku těchto zdrojových aplikací a databází pravděpodobně nikdo nepočítal s budoucí integrací dat a každá aplikace sleduje především svou sadu unikátních potřeb, takže při pokusu o integraci dat z různých zdrojů narazíme na různé problémy: stejná informace může být různě reprezentována v rozdílných aplikacích (např. muž/žena, m/ž), stejná data mohou být různě pojmenována, různá data mohou být stejně pojmenovaná a v českém prostředí téměř s jistotou narazíme na problémy s českou znakovou sadou. Dalším problémem, který musíme řešit, je efektivita přístupu k datům v primárních systémech, prioritou samozřejmě musí být co nejmenší dopad na běh primárního systému. 5 GÁLA, Libor, Jan POUR a Zuzana ŠEDIVÁ. Podniková informatika. 2., přeprac. a aktualiz. vyd. Praha, 2009, 496 s. Expert (Grada). ISBN s

11 Pro potřebu plnění datového skladu obvykle rozlišujeme tři typy dat: archivní data, aktuální data aplikace a nakonec změny, ke kterým došlo od posledního plnění datového skladu. Z těchto tří typů dat jsou nejmenší výzvou archivní data, v případě jejich nahrání se jedná pouze o jednorázovou akci a data jsou obvykle uložena mimo primární systém, takže nedochází ani k odčerpání systémových zdrojů produkčních aplikací, navíc se často od nahrání archivních dat do datového skladu upouští. Nahrání aktuálních aplikačních dat je opět jednorázovou akcí, ale je nutné si dát pozor na vytížení systémových zdrojů, zvláště v případě většího objemu dat je třeba tuto akci pečlivě naplánovat. Poslední typ dat představuje pro datové modeláře největší výzvu, William Inmon 6 uvádí pět obecných technik, jak tato data v aplikaci zajistit. První technikou je přiřadit datům časovou značku jejich změny, při plnění datového skladu se potom můžeme orientovat podle této značky a nahrát pouze data změněná od posledního plnění. Aktualizaci časové značky obvykle zajišťuje aplikace, v případě manipulace s daty přímo v databázi (např. hromadné úpravy, které není efektivní provést přes aplikační rozhraní) je nutné aktualizaci časové značky zajistit manuálně, jinak se změny nepřenesou do datového skladu. Druhou technikou je vytváření tzv. delta souborů, tedy souborů, které obsahují změněná data. Výhodou je, že se čtou pouze změněná data, takže se omezuje zatížení systému, nevýhodou je malá podpora ze strany aplikací. Existují také technologie, které umožňují tuto funkci implementovat i bez úpravy aplikace, jedná se např. o logy materializovaných pohledů v RDBMS Oracle. Zjednodušeně jde o typ databázového triggeru, který ukládá informace o změnách provedených v tabulce (tzv. změnový vektor) do speciální tabulky a pomocí těchto záznamů se vytváří replika změn. Třetí možností jsou různé logovací nebo auditovací záznamy, které vytváří aplikace nebo databáze. Mezi tyto technologie patří například využití databázových transakčních logů v produktech, jako je Oracle Golden Gate 7, Informatica Power Exchange 8 nebo Dell 6 INMON, William H. Building the data warehouse. 3rd ed. New York: John Wiley, 2002, 412 p. ISBN

12 SharePlex 9. Výhodou těchto řešení je replikace téměř v reálném čase, navíc s minimální zátěží zdrojového systému. Čtvrtou technikou je modifikace aplikačního kódu, jedná se však o poměrně neoblíbenou metodu, protože zásah do existujících aplikací může být náročný a riskantní, často i nemožný (např. licenční podmínky). Jako reálnou možnost bych tuto techniku viděl především při tvorbě nové aplikace. Poslední technikou je vytvoření snímku aplikace v čase, kdy dochází k extrakci dat. V okamžiku další extrakce je vytvořen další snímek a tyto dva snímky jsou porovnány a tím získáme soubor změn. Tento způsob se většinou bere jako poslední možnost, kdy žádný jiný způsob není možný, jedná se totiž o značně komplikovaný mechanismus, náročný na systémové zdroje Extract, Transform, Load a procesy datové integrace ETL je určitě jednou z nejdůležitějších částí BI architektury, účelem této komponenty je dostat data ze zdrojových systémů do datového skladu a to v požadované kvalitě. Zpracování dat v této komponentě probíhá ve třech hlavních etapách (jak ostatně napovídá i samotný název této komponenty). První je fáze extrakce dat (Extract), následuje transformace a čištění dat (Transform) a nakonec nahrání dat do cílového systému (Load). Datový zdroj Extract Datový zdroj Transform Load Datový sklad Datový zdroj Obrázek 3: Princip ETL Zdroj: autor Účelem fáze Extract je dostat data ze zdrojového systému, důležitým rozhodnutím v této etapě je, jaká data číst a jaké filtry při čtení těchto dat aplikovat. Hlavní náplní fáze je 9 původně se jedná o produkt firmy Quest 12

13 především identifikace změn ve zdrojovém systému a jejich čtení. Ralph Kimball 10 zmiňuje ještě jeden subsystém této části ETL, a to je profilování dat, já bych však profilování dat nepovažoval za součást ETL procesu, ale spíše za součást jeho implementace či přípravy. Když jsou data extrahována ze zdrojového systému, nastává fáze transformace dat, tato fáze je klíčovou pro datovou kvalitu celého řešení a je tedy nutné jí věnovat náležitou péči. Kimball 11 uvádí pět hlavních služeb, které jsou ETL systémem v této fázi poskytovány: čištění dat (Data cleansing), sledování chybových stavů (Error event tracking), vytváření auditní dimenze (Audit dimension creation), deduplikace (Deduplication), a sladění dat (Conforming). Pod pojmem čištění dat si můžeme představit odstranění chybných dat, tato funkce je důležitá pro datovou kvalitu datového skladu. Úlohou sledování chyb je provést záznam o všech chybách, které vznikly v průběhu ETL zpracování, včetně chyb v datové kvalitě. Auditní dimenze je speciální typ dimenze, obsahuje informace o nahrání dat do datového skladu, ke každému záznamu v tabulce faktů tak existuje i záznam obsahující informace o jeho nahrání. Obrázek 4: Auditní dimenze Zdroj: autor, upraveno podle KIMBALL, Ralph, Margy Ross. The data warehouse toolkit: the definitive guide to dimensional modeling. 3rd ed. Indianopolis: John Wiley, 2013, 601 p. ISBN KIMBALL, Ralph, Joe Caserta. The data warehouse ETL toolkit practical techniques for extracting, cleaning, conforming, and delivering data. Indianopolis: John Wiley, 2004, 491 p. ISBN KIMBALL, Ralph, Margy Ross. The data warehouse toolkit: the definitive guide to dimensional modeling. 3rd ed. Indianopolis: John Wiley, 2013, 601 p. ISBN s

14 Protože data často pocházejí z různých zdrojů, je v této fázi také nutné řešit spojení dat z těchto zdrojů do jednoho záznamu. Kritéria pro toto spojení často nejsou zcela exaktní a některé údaje se mohou vyskytovat víckrát, je tedy nutné zvolit, která data ponechat a která zahodit (deduplikace), vše tak, aby se dosáhlo co nejvyšší datové kvality. Poslední službou, kterou ETL v transformační fázi poskytuje, je sladění dat z více zdrojů. Je nutné určit jak data správně kombinovat, jaké klíče použít, odstranit chybná data, vyřešit případné nekonzistence mezi systémy apod. Poslední částí ETL zpracování je již samotné nahrání očištěných, upravených a konsolidovaných dat do cílového systému. S nárůstem výkonu ať už hardwaru či databázových strojů se začaly objevovat nástroje, které používají modifikaci klasického ETL postupu a to tzv. Extract, Load, Transform (ELT) nástroje. Jak název napovídá, došlo ke změně pořadí jednotlivých fází a transformace dat se přesunula až do cílového databázového stroje, který obvykle má optimalizované nástroje pro potřebné operace s daty a v dnešní době i dostatečný výkon. Datový zdroj Extract Transform Datový zdroj Load Datový sklad Datový zdroj Obrázek 5: Princip ELT Zdroj: autor Typickým zástupcem této skupiny produktů je např. Oracle Data Integrator. Cílem datové integrace je integrovat primární systémy na jedno místo, obecně tyto nástroje spadají do vrstvy zdrojových aplikací, pro účely BI však většinou slouží k přípravě dat pro plnění datového skladu a jsou tedy spolu s operačním datovým úložištěm (Operational Data Store ODS) součástí transformační vrstvy. Na rozdíl od klasického ETL pracují nástroje datové integrace v reálném čase, typický je pro ně důraz na minimální zatížení zdrojových systémů, jejich použití je tedy vhodné, pokud chceme snížit dopad extrakce dat na 14

15 primární zdrojový systém. Zástupcem těchto produktů je např. Oracle Golden Gate nebo Quest SharePlex Data Staging Area Data Staging Area (DSA) je dočasné datové úložiště, kam se odkládají data ve fázi extrakce. Účelem tohoto úložiště je urychlit extrakci surových dat ze zdrojových systémů. Podle Gály 13 mají data na tomto úložišti následující charakteristiky: jsou detailní, nejsou konzistentní, neobsahují historii, mění se, jsou ve stejné struktuře, jako ve zdrojových systémech. DSA úložiště jsou obvykle implementována jako relační databáze nebo ve formě souborů a jedná se o nepovinnou, ale poměrně častou součást BI implementací Operational Data Store Operational Data Store (ODS) je nepovinnou součástí datové vrstvy BI architektury. Jedná se o databázi, která obsahuje integrovaná data z primárních (operačních) databází a může sloužit jak pro potřeby primárních systémů, tak reporting nebo jako zdroj datového skladu. Inmon popisuje ODS jako integrovaný, subjektově orientovaný a proměnlivý systém obsahující hodnoty platné v daném čase 14 a odkazuje na dvojí roli ODS, kde na jedné straně je plnohodnotnou součástí operačních aplikací, poskytuje rychlou odezvu a vysokou dostupnost a na druhou stranu má jasné charakteristiky DSS 15, jako je integrace a subjektová orientace. 13 GÁLA, Libor, Jan POUR a Zuzana ŠEDIVÁ. Podniková informatika. 2., přeprac. a aktualiz. vyd. Praha, 2009, 496 s. Expert (Grada). ISBN INMON, William H. The Operational Data Store. In: Information Management [online] [cit ]. Dostupné z: 15 DSS - Decision Support System 15

16 Podle četnosti nahrávání změn do ODS rozlišuje Inmon čtyři základní třídy ODS 16 : I. V případě první třídy ODS, jsou transakce nahrávány do ODS okamžitě, jakmile nastanou. Koncový uživatel by tedy neměl podle dat rozlišit, zda přistupuje k primárnímu systému nebo k ODS. II. III. IV. V této třídě ODS jsou změny nahrávány v dávkách několikrát za den (např. po čtyřech hodinách). Je zde tedy znatelné zpoždění proti primárnímu prostředí. Na druhou stranu je implementace ODS třídy II jednodušší než třídy I. Pro třetí třídu ODS je charakteristický update v průběhu noci, dochází zde tedy k jednodennímu zpoždění, ale implementace této třídy je nejjednodušší. Na rozdíl od prvních třech tříd, které jsou plněny z primárních systémů, je čtvrtá třída ODS plněna analytickými daty z datového skladu. Tato data potom mohou sloužit pro potřeby primárních systémů Datový sklad Datový sklad je spolu s ETL klíčovou součástí BI architektury. Definicí datového skladu existuje celá řada, zřejmě nejčastěji se však používá definice, kterou vytvořil William Inmon: Datový sklad je subjektově orientovaná, integrovaná, stálá a časově rozlišená kolekce dat určená pro podporu rozhodování managementu. 17 Subjektově orientovaný znamená, že data jsou organizována podle jejich typu, nikoliv podle primární aplikace. V důsledku to znamená, že data např. o dodavateli jsou v datovém skladu uložena pouze jednou, nikoliv rozptýlena podle zdrojových aplikací. Druhou a nejvýznamnější vlastností datového skladu je integrovanost. Data v datovém skladu pocházejí z mnoha rozdílných zdrojů, při jejich plnění dochází ke konverzi, formátování či jiné transformaci. Výsledkem těchto operací je jediný fyzický obraz dat umístěný v datovém skladu. Mezi primárními aplikacemi obvykle neexistuje konzistence 16 INMON, William H. ODS Types. In: Information Management [online] [cit ]. Dostupné z: 17 INMON, William H. Building the data warehouse. 3rd ed. New York: John Wiley, 2002, 412 p. ISBN s. 31, překlad autor 16

17 v pojmenování, kódování hodnot, jsou používány různé popisy atributů, různé jednotky a toto vše je nutné během integrace dat vyřešit. Obrázek 6 představuje základní problémy, se kterými se můžeme setkat během integrace dat z různých zdrojů. Stálostí datového skladu máme na mysli, že data v datovém skladu zůstávají po celou dobu své životnosti jako read only obraz dat primárních aplikací a již nedochází k jejich modifikaci. Aby bylo možné provádět analýzy za časové období, obsahuje sklad historii dat, každý záznam tedy obsahuje informaci o čase - může to být časové razítko vzniku záznamu, čas transakce, ale v každém případě je zde nějaké časové rozlišení. Hlouběji se budeme datovému skladu a jeho koncepcím věnovat v kapitole Obrázek 6: Problémy integrace dat Zdroj: INMON, William H. Building the data warehouse. 3rd ed. New York: John Wiley, 2002, 412 p. ISBN s

18 Datové tržiště V principu jsou datová tržiště velice podobná datovému skladu, rozdíl je především v tom, komu jsou určena. Zatímco datový sklad je určen pro celou organizaci, datová tržiště jsou určena pouze omezenému okruhu uživatelů, jsou zaměřena pouze na určitý problém nebo určitou oblast. Při vytváření celopodnikového skladu jsou tržiště integrována do tohoto skladu, ale často nezanikají a existují i po jeho vzniku, potom slouží především pro specializované a ad hoc analýzy, protože jsou flexibilnější a implementace změn je pro jejich nižší složitost levnější a rychlejší OLAP databáze V souvislosti s datovými sklady se často objevuje pojem multidimenzionální databáze nebo také OLAP (Online Analytical Processing) databáze. Základem této technologie je multidimenzionální tabulka nebo také kostka, která umožňuje rychle měnit jednotlivé dimenze a tím umožňovat různé pohledy na data. Obrázek 7: Princip multidimenzionální (OLAP) databáze Zdroj: autor Tato architektura je optimalizována pro snadnou a rychlou změnu pohledu na data (otáčení kostky - pivot), umožňuje vytváření řezů a výřezů kostky (operace slice a dice), změnu detailu (drill down, drill up) a také sumarizace přes vybranou dimenzi (roll up). V praxi se implementace této technologie provádí v několika různých variantách: MOLAP (Multidimensional OLAP) provádí uložení dat v multidimenzionálních strukturách. 18

19 ROLAP (Relational OLAP) umožňuje uložení dat v relačních databázích. HOLAP (Hybrid OLAP) kombinuje obě předchozí varianty data, se kterými potřebujeme rychle pracovat, jsou uložena v MOLAP databázi (například nejčerstvější data) a zbytek dat je uložen v relační databázi s využitím ROLAP technologie. Někteří autoři (např. Gála 19 ) uvádějí jako další možnou variantu DOLAP (Desktop OLAP), ale dle mého názoru se jedná o některou z již uvedených variant, pouze provozovanou na lokálním počítači Analytické a reportingové aplikace V BI architektuře rozlišujeme dvě základní skupiny klientských aplikací: reportingové aplikace a analytické aplikace. Reportingové aplikace slouží k dotazování do databází datového skladu (nebo OLAP databází) s využitím standardního rozhraní těchto databází. Do reportingu řadíme jak standardní reporty, které se spouští v pravidelném intervalu, tak jednorázové ad hoc dotazy vytvořené uživateli. V případě ad hoc dotazů je nutné věnovat pozornost zkušenosti a vyškolení uživatelů, protože špatně definovaný dotaz může způsobit přetížení systému. Analytické aplikace jsou dalším typem klientských aplikací, typicky jsou určené na poskytování manažerských informací, umožňují agregované i detailní pohledy na data, dokáží sledovat trendy, provádět on-line analýzu dat, snadno se ovládají, typicky poskytují grafické uživatelské rozhraní. Kromě specializovaných produktů jako je např. Oracle Business Intelligence Discoverer 20 nebo SAP BusinessObjects 21 se pro tvorbu analytických aplikací používají také kancelářské aplikace jako je MS Excel nebo MS Access GÁLA, Libor, Jan POUR a Zuzana ŠEDIVÁ. Podniková informatika. 2., přeprac. a aktualiz. vyd. Praha, 2009, 496 s. Expert (Grada). ISBN

20 1.1.2 Architektury datového skladu V předchozí kapitole jsme prošli základní prvky BI architektury, nyní se zaměříme na základní architektury datových skladů. Obvykle rozlišujeme čtyři základní architektury datového skladu: nezávislá datová tržiště, architektura datové sběrnice Ralpha Kimballa, architektura Billa Inmona (Hub and Spoke), federalizovaný datový sklad Nezávislá datová tržiště V této architektuře vznikají datová skladiště podle potřeb jednotlivých oddělení, bez zájmu o sdílení nebo integraci informací napříč celým podnikem. Ačkoliv se toto řešení může z krátkodobého hlediska zdát výhodným, a to jak z pohledu rychlosti dosažení prvních výsledků, tak z pohledu počáteční ceny, z dlouhodobé perspektivy je tato architektura neefektivní a neposkytuje žádnou integraci napříč celým podnikem. Obrázek 8: Architektura nezávislých datových tržišť Zdroj: KIMBALL, Ralph, Margy Ross. The data warehouse toolkit: the definitive guide to dimensional modeling. 3rd ed. Indianopolis: John Wiley, 2013, 601 p. ISBN s

21 Kimballova architektura Základem architektury Ralpha Kimballa jsou dva prvky, které ji odlišují od ostatních architektur datových skladů: prvním z těchto prvků je dimenzionální modelování, druhým je datová sběrnice (data bus, někdy také data warehouse bus nebo enterprise data warehouse bus). Dimenzionální modelování je založeno na dvou typech tabulek: faktů a dimenzí (obrázek 9). Tabulky faktů obsahují metriky, tabulky dimenzí atributy naměřených metrik, data v dimenzích jsou denormalizovaná, objevují se v nich redundance, na druhou stranu se s nimi uživatelům snadněji a efektivněji pracuje. Hlouběji se dimenzionálním modelováním budeme zabývat v kapitole 1.2. Obrázek 9: Fakta a dimenze Zdroj: autor, upraveno podle 24 (12, str. 98) Datový sklad je v této architektuře tvořen množinou datových tržišť, každé tržiště je založeno na některém z podnikových procesů, žádné z těchto datových tržišť by nemělo být vlastněno nebo řízeno pouze jedním oddělením, protože daný proces může zajímat také jiná oddělení. Aby se datový sklad choval jako celek, nikoli jako množina nezávislých tržišť, obsahuje tato architektura integrační prvek datové sběrnice. V praxi to znamená, že každé tržiště musí obsahovat sadu standardních konformních dimenzí. Ralp Kimball 25 uvádí, že dvě dimenze jsou konformní, pokud jejich atributy jsou shodně pojmenované a mají stejný doménový obsah. Konformní dimenze mají stejné klíče, 24 KIMBALL, Ralph, Margy Ross. The data warehouse toolkit: the definitive guide to dimensional modeling. 3rd ed. Indianopolis: John Wiley, 2013, 601 p. ISBN s KIMBALL, Ralph. The data warehouse lifecycle toolkit: expert methods for designing, developing, and deploying data warehouses. 3rd ed. New York: John Wiley, 1998, 771 p. ISBN s

22 stejná jména sloupců, stejnou definici i hodnotu atributů. S pomocí konformní dimenze lze kombinovat informace z různých faktových tabulek do jednoho reportu. Tabulka 1: Matice sběrnice datového skladu (Data Warehouse Bus Matrix) Zdroj: 26 Základním nástrojem pro návrh sběrnicové architektury je matice sběrnice datového skladu (Data Warehouse Bus Matrix). Jedná se o tabulku (viz tabulka 1), kde každému řádku v matici odpovídá jedno datové tržiště (podnikový proces), ve sloupcích jsou uvedeny dimenze. Na základě této matice se určí konformní dimenze a zajistí se integrovanost datového skladu. Kimball doporučuje začít vývoj datového skladu datovými tržišti, která jsou odvozená vždy od jednoho primárního zdroje (někdy se nazývají first-level data marts ). Tato tržiště minimalizují riziko, že úvodní implementace bude příliš komplexní a náročná, také to umožní rychle dodat první část datového skladu uživatelům a umožnit vývojovému týmu v klidu pracovat na náročnějších úkolech, např. na konsolidovaných datových tržištích, ve kterých dochází ke sloučení dat z více zdrojů. Kimball 27 uvádí, že matice sběrnice datového skladu je jedním z nejdůležitějších výstupů počáteční fáze implementace datového skladu. Jedná se o hybridní prostředek, částečně nástroj technického návrhu, částečně projektového managementu a částečně komunikační nástroj. Samotná architektura datového skladu je podle Kimballa tvořena čtyřmi základními prvky: zdrojovými systémy, ETL procesy, prezentační oblastí a BI aplikacemi (obrázek 10). 26 KIMBALL, Ralph, Margy Ross. The data warehouse toolkit: the definitive guide to dimensional modeling. 3rd ed. Indianopolis: John Wiley, 2013, 601 p. ISBN s KIMBALL, Ralph, Margy Ross. The data warehouse toolkit: the complete guide to dimensional modeling. 2nd ed. New York: John Wiley, 2002, 436 p. ISBN s

23 Obrázek 10: DW/BI architektura podle Ralpha Kimballa Zdroj: 28 Zdrojové systémy (Kimball je v originále nazývá Operational Source Systems ) jsou OLTP aplikace, které jsou zaměřeny na svůj primární účel a nejsou přímo svázány s BI nebo s datovým skladem. BI tým má velmi nízkou nebo žádnou kontrolu nad obsahem těchto systémů nebo formátem dat v nich uložených. V Kimballově pojetí je ETL subsystém vše mezi zdrojovými systémy a prezentační oblastí datového skladu. Jak je zřejmé z obrázku 9, úkolem tohoto subsystému je převod dat ze zdrojových systémů do dimenzionálního modelu datového skladu. ETL systém je hlouběji představen v kapitole Prezentační oblast, tedy samotný datový sklad, kde jsou data uložena, je připravena pro přímé dotazy uživatelů a BI aplikací. Zjednodušeně lze říct, že je to vše, co vidí uživatel. Data jsou uložena v dimenzionálním modelu, nejsou normalizovaná. Ralph Kimball dále doporučuje, aby data byla atomická, sumarizovaná data by měla být až ve specializovaných datových tržištích. Hlavními cíli při návrhu by měla být výkonnost při dotazech a snadnost využití pro koncové uživatele. BI aplikace jsou poslední komponentou Kimballovy architektury. Tyto aplikace čtou data z prezentační oblasti, může jít o jednoduché dotazovací nástroje pro tvorbu ad-hoc 28 KIMBALL, Ralph, Margy Ross. The data warehouse toolkit: the definitive guide to dimensional modeling. 3rd ed. Indianopolis: John Wiley, 2013, 601 p. ISBN s

24 dotazů, tabulkový procesor, reportingové a analytické nástroje jako jsou SAP BusinessObjects 29, Oracle Discoverer 30 nebo data-miningové aplikace, jako je například SPSS Clementine 31. etap: Samotný proces návrhu datového skladu rozděluje Ralph Kimball do čtyř základních výběr business procesů pro modelování, volba granularity dat, výběr dimenzí, identifikace faktů. Business procesy jsou definovány poměrně široce, obvykle se jedná o procesy, které jdou napříč více odděleními, mělo by se jednat o důležité činnosti, které v organizaci probíhají (v telekomunikační firmě to může být např. billing, správa objednávek, logistika, události na telekomunikační síti apod.). Kimball doporučuje začít s procesy, které mají na firmu největší dopad. Granularita určuje, jaká úroveň detailu bude v datovém skladu obsažena, atomická úroveň detailu je úroveň detailu, která nejde již více dělit. Obecně lze doporučit granularitu co nejvyšší, tedy atomickou, protože data mohou být později snadno agregována (často se tak děje např. na úrovni datových tržišť napojených na datový sklad). Ve třetí fázi dochází k výběru dimenzí; dimenze nám poskytují informaci kdo, co, kdy, kde, proč a jak. Poskytují popisné atributy používané pro filtrování, spojování či seskupování faktů. Je nutné také nezapomenout na konformní dimenze, aby datový sklad splňoval požadavek na integrovanost. Jako poslední přichází identifikace faktů, tedy metrik, které budeme v datovém skladě ukládat a sledovat Hub and spoke architektura Označení této architektury vychází z vizuální podobnosti s nábojem a paprsky kola (hub znamená náboj kola a spoke je paprsek kola), v centru této architektury je konsolidovaný datový sklad, tvoří náboj kola, závislá datová tržiště potom tvoří paprsky. Tvůrcem tohoto konceptu a jeho významným propagátorem je William Inmon. Někdy se lze s touto

25 architekturou setkat také pod názvem Corporate Infomation Factory (CIF). Architektura CIF zahrnuje celý informační ekosystém organizace (na rozdíl od dříve představených architektur), jedná se tedy o celopodnikové řešení, které se snaží BI integrovat do všech firemních procesů. Základními prvky se, kterými tato architektura pracuje, jsou: externí svět aplikace, integrační a transformační vrstva, ODS, datový sklad, datová tržiště, DSS a BI aplikace. Obrázek 11: Corporate Information Factory Zdroj: 32 V externím světě vznikají transakce, tento svět je tvořen lidmi a procesy. Aplikace jsou systémy, kde vznikají transakční data, Inmon v rámci CIF rozlišuje integrované a neintegrované aplikace. Integrované aplikace byly vyvinuty v souladu se standardy CIF. Neintegrované aplikace jsou funkčně orientované aplikace, které podporují především svou primární funkci a typické jsou pro ně různé nekonsistence, které je nutné odstranit v integrační vrstvě (může jít například o různou strukturu dat, různé klíče, nekonzistentní definici dat, různou strukturu dat apod.). 32 INMON, William H, Claudia IMHOFF a Ryan SOUSA. Corporate information factory. 2nd ed. New York: John Wiley, 2001, 382 p. ISBN s

26 Integrační a transformační vrstvu (ETL procesy) tvoří dvě komponenty: datová akvizice (data acquisition) a doručení dat (data delivery). Datová akvizice je určena pro získání transakčních dat ze zdrojových aplikací, jejich transformaci a nahrání do datového skladu, doručení dat slouží načtení dat z datového skladu a jejich nahrání do datových tržišť a aplikací pro podporu rozhodování (Decision Support System - DSS). Jádro celého řešení tvoří integrovaný atomický datový sklad, který obsahuje normalizovaná data (na rozdíl od architektury Ralpha Kimballa, který primárně pracuje s dimenzionálním modelem). Dimenzionální datový model popř. OLAP se uplatňuje až v datových tržištích, která se plní z datového skladu. Inmon dělí databázové prostředí organizace na čtyři úrovně: provozní (operational), atomický datový sklad (atomic data warehouse), sekční nebo odborový (departmental), individuální (individual). Provozní úroveň odpovídá transakčním systémům, data v této vrstvě ukazují okamžitý stav. Z těchto aplikací jsou data nahrána do atomizovaného datového skladu, data v této vrstvě jsou historizována, ale stále obsahují atomickou úroveň detailu. Další vrstvu tvoří typicky datová tržiště jednotlivých oddělení, data v nich jsou sumarizovaná. Poslední individuální vrstvu vytváří přímo koncoví uživatelé, jedná se o datové sety vznikající při různých analýzách, většinou jde o dočasná data, která jsou uložena přímo na koncových zařízeních uživatelů (může se jednat o tabulky, OLAP kostku apod.). Pro návrh datového skladu doporučuje Inmon použít tři úrovně datového modelu: ER diagramy (Entity Relationship Diagrams - ERD), sety datových položek (Data Item Set - DIS) a fyzický model. ER diagram je první úrovní modelu, vytváří se vždy jeden set ER diagramů pro každé oddělení, které bude používat datový sklad. Korporátní ERD je potom sumou všech ER diagramů. Pro každou entitu z ER diagramu je vytvořen model nižší úrovně (DIS), každému seskupení dat v DIS odpovídá tabulka v databázovém modelu. Vytvoření datového modelu je předpokladem pro využití Inmonovy vývojové metodiky, kterou nazývá Meth 2 (Meth 1 je určená pro vývoj primárních systémů, Meth 3 pro ladění datového skladu). Jedná 26

27 se o adaptaci spirálového vývoje, který sestává z deseti kroků první krok (DSS1) je analýza datového modelu, jednotlivé kroky a jejich návaznost znázorňuje obrázek Opakovat pro každý subjekt DSS1 analýza datového modelu DSS5 výběr subjektové oblasti DSS7 analýza zdrojových systémů DSS8 tvorba specifikací DSS9 programování DSS10 naplnění databáze DSS2 breadbox analýza DSS6 návrh databáze DWH DSS3 technický návrh DSS4 příprava technického prostředí Obrázek 12: Metodika Meth 2 Zdroj: autor, upraveno podle 34 Inmon vidí datový sklad jako součást celé informační infrastruktury organizace (CIF), datový sklad i operační databáze jsou podle něj součástí většího celku. Tento pohled pomáhá pochopit, proč datový sklad musí v jeho pojetí splňovat většinu stejných standardů jako provozní systémy. Cílovou skupinou Inmonovy metodiky jsou hlavně IT profesionálové, koncoví uživatelé mají ve vývoji datového skladu především pasivní roli Federalizovaný datový sklad Federalizovaný datový sklad (obr. 13) je logicky nebo fyzicky integrovaná skupina datových skladů a datových tržišť. Architektura federalizovaného datového skladu se typicky využívá ve velkých globálních organizacích, které mají v regionech existující datové sklady, ale zároveň existují požadavky na BI na globální úrovni, pro potřeby globálního vedení. 33 Breadbox analýza v kroku DSS2 je analýzou velikosti datového skladu a jeho granularity 34 INMON, William H. Building the data warehouse. 3rd ed. New York: John Wiley, 2002, 412 p. ISBN

28 DW1 DW2 DW3 integrace federalizovaný datový sklad DW4 Obrázek 13: Federalizovaný datový sklad Zdroj: autor Srovnání přístupu Ralpha Kimballa a W.H.Inmona Oba modely, Ralpha Kimballa i Williama Inmona, mají společné pouze dva základní prvky. Jedná se o prvky, které se musí shodovat, protože bez nich nebude žádný BI systém životaschopný: časově rozlišená data a ETL. Prakticky ve všem ostatním, ať už mluvíme o architektuře, vývojové metodice nebo datovém modelu, se liší. Velmi přehledně srovnává tyto metodiky Mary Breslin 35. Inmon Kimball Metodika a architektura Celkový přístup shora dolů zdola nahoru komplexita komplexní vcelku jednoduchá Porovnání se zavedenými postup ve čtyřech krocích; založeno odvozena ze spirálové metodiky vývojovými metodikami na RDBMS metodách Diskuze o fyzickém designu poměrně důkladná pouze lehká Datové modelování Orientace dat subjektová orientace procesně orientovaná Nástroje tradiční (ERD, DIS) dimenzionální modelování Přístupnost pro koncové uživatele nízká vysoká Filozofie Určeno primárně pro IT odborníky koncové uživatele Umístění v organizaci Integrální část CIF transformace a udržování Cíl dodat důkladné technické řešení založené na ověřených databázových metodách a technologiích Tabulka 2: Porovnání základních vlastností Inmonova a Kimballova modelu. Zdroj: 36 operačních dat dodat řešení, které koncovým uživatelům usnadní přímé dotazování při rozumném čase odezvy Obecně lze asi říci, že Kimballův model je vhodnější, pokud požadavky na datový sklad jsou spíše taktického rázu, je třeba dodat první část datového skladu co nejrychleji nebo 35 BRESLIN, Mary. Data Warehousing Battle of the Giants: Comparing the Basics of the Kimball and Inmon Models. In: Business intelligence journal. Seattle: Data Warehousing Institute, 2004, p , 1. ISSN Tamtéž 28

29 je vhodné rozdělit náklady na projekt do delšího časového období. Inmonův model je naopak vhodný pro naplnění strategických požadavků, přináší rozsáhlou integraci napříč celou organizací (CIF není pouze o BI, ale popisuje kompletní informační infrastrukturu celé organizace), počáteční náklady jsou vyšší, ale dodatečné náklady jsou již nižší. Podle průzkumu, který byl zveřejněn v Business Intelligence Journal 37, jsou z pěti základních architektur (proti zde uvedenému přehledu je v článku navíc uveden centralizovaný datový sklad bez datových tržišť) nejvhodnější právě Inmonův a Kimballův přístup s tím, že Hub and Spoke architektura se častěji využívá pro velká řešení. 37 Watson, Hugh J., Thilini Ariyachandra. Which Data Warehouse Architecture Is Most Successful? In: Business intelligence journal. Seattle: Data Warehousing Institute, 2006, p. 4-6,11, 1. ISSN

30 1.2 Dimenzionální model Alternativou ER modelu, používanou pro potřeby BI, je dimenzionální model. Pro dimenzionální modelování je typické zaměření na snadnou srozumitelnost prezentovaných dat koncovým (business) uživatelům a rychlost analytických dotazů. V tomto se liší od normalizovaného ER modelování, které se zaměřuje především na efektivitu uložení dat, na odstranění redundance dat. Základ dimenzionálního modelu tvoří dimenzionální schéma, tedy soustava dvou druhů tabulek: tabulek faktů a tabulek dimenzí. Tabulky faktů typicky obsahují výsledky měření (measures), něco, co nelze znát dopředu, dimenze obsahují popisná data, atributy, podle kterých lze naměřené hodnoty filtrovat a agregovat. Existují dvě základní uspořádání dimenzionálního schématu (obr. 14): hvězda a sněhová vločka. DIMENZE ČAS FAKTA PRODEJ DIMENZE PRODUKT DIMENZE ZÁKAZNÍK DIMENZE ČAS FAKTA PRODEJ DIMENZE PRODUKT DIMENZE ZÁKAZNÍK DIMENZE KATEGORIE Schéma hvězda Schéma sněhová vločka Obrázek 14: Dimenzionální schéma Zdroj: autor Společným znakem je umístění tabulky faktů do centra schématu, na fakta jsou napojeny dimenze, které tato fakta popisují. Rozdíl je v uspořádání hierarchií jednotlivých dimenzí: v případě hvězdy jsou všechna data v jedné tabulce, u sněhové vločky dochází k umístění dat na různé úrovni hierarchie do samostatných tabulek a tedy k vazbám přímo mezi tabulkami dimenzí. Obecně se doporučuje používat schéma hvězdy, protože je srozumitelnější a snáze se udržuje, sněhová vločka může být někdy vynucena z důvodu napojení na faktové tabulky s různou granularitou a také může přinést úsporu místa (nižší redundance dat oproti hvězdě). Tato úspora však obvykle není příliš významná, protože většina objemu datového skladu je tvořena fakty. Pokud je použita sněhová vločka, je vhodné toto uspořádání před uživatelem skrýt pomocí vrstvy databázových pohledů. 30

31 1.2.1 Fakta Faktová tabulka obsahuje velké množství cizích klíčů pro napojení jednotlivých dimenzí a ukazatele, které pro daný proces chceme sledovat. Primární klíč faktových tabulek je vždy složený, tvořený klíči jednotlivých dimenzí. Toto tvrzení lze také obrátit a platí, že každá tabulka, která má složený primární klíč, je tabulka faktů. Jinak vyjádřeno, faktová tabulka vyjadřuje vztah M:N mezi dimenzemi 38, nebo také každý vztah M:N v dimenzionálním modelu je faktová tabulka. Každému řádku ve faktové tabulce odpovídá jedno měření a hodnoty ve všech řádcích musí mít stejnou úroveň detailu, tedy granularitu. Pro tabulky faktů je typický relativně malý počet sloupců a velký počet řádků, tyto tabulky běžně tvoří okolo devadesáti procent objemu datového skladu. Rozlišujeme tři druhy faktů: aditivní, semiaditivní a neaditivní. Nejužitečnější fakta pro použití v datovém skladě jsou fakta aditivní, jsou to fakta (ukazatele), která lze agregovat (sčítáním) přes všechny dimenze. Semiaditivní fakta lze agregovat pouze přes některé dimenze, je třeba je agregovat pomocí jiných funkcí (např. průměr). Neaditivní fakta nelze sčítat přes žádnou dimenzi, může jít o strukturovaná či textová data, ale také sem patří procenta a poměry. V případě neaditivních fakt se doporučuje ukládat aditivní části neaditivní metriky a neaditivní fakta dopočítat až při zpracování uživatelských dotazů nebo v předpočítaných strukturách (např. OLAP kostky). Kromě zde uvedených druhů faktů existuje ještě speciální případ faktové tabulky, která žádná fakta neobsahuje. Tento druh faktové tabulky se nazývá factless a použije se například pro sledování, zda nastala nějaká událost, pro kterou nás nezajímá žádná sledovaná hodnota, ale pouze informace, zdali událost nastala či nikoli. Podle způsobu sběru a uložení fakt rozlišujeme tři druhy faktových tabulek: transakční, snímkové a akumulované. Transakční tabulky obsahují nejvyšší granularitu dat. Zachycena je v nich každá transakce tak, jak nastala ve zdrojových systémech, zachycují chování v čase. Transakční faktové tabulky zachycují pouze transakce, které proběhly (pokud se neuskutečnil hovor nebo si zákazník nic nekoupil, není tato informace ani ve faktové tabulce). Transakční faktové tabulky vždy obsahují cizí klíče pro všechny asociované 38 KIMBALL, Ralph, Margy Ross. The data warehouse toolkit: the complete guide to dimensional modeling. 2nd ed. New York: John Wiley, 2002, 436 p. ISBN

32 dimenze, kromě toho také mohou obsahovat přesné časové razítko či klíče degenerovaných dimenzí 39. Snímkové tabulky faktů obsahují periodické snímky faktů k určitému časovému okamžiku (např. každou půlnoc, každou nedělní půlnoc apod.). Tento typ faktové tabulky je vhodný např. pro stav skladu, stav účtu apod. Snímkové tabulky faktů mají uniformní hustotu, snímek se vytvoří, i když nedošlo k žádné aktivitě (např. pokud v daný okamžik nebude na skladě žádný výrobek daného typu, vloží se nula), tato vlastnost může vést k velkému počtu řádků v tabulce, je tedy vhodné dobře zvážit granularitu těchto faktů. Pro transakční i snímkovou tabulku platí, že záznamy se po vložení již nemění (samozřejmě s výjimkou oprav, i když i ty se dají řešit bez aktualizace existujícího záznamu). Akumulované faktové tabulky se používají v případě procesů, které jsou jasně definované v čase, mají jasný začátek, jasný konec a identifikovatelné milníky mezi nimi. S akumulovanou tabulkou faktů je obvykle asociováno několik časových dimenzí, každá z těchto dimenzí popisuje, kdy došlo k jinému ze sledovaných milníků (začátek procesu, konec procesu, poslední aktualizace apod.). Při vzniku procesu je vytvořen řádek ve faktové tabulce a tento řádek je následně aktualizován podle toho, jak se proces v průběhu času posouvá. Časové dimenze by v případě akumulovaných tabulek měly obsahovat umělé klíče pro hodnoty, které neznáme, které zatím nenastaly (např. při startu procesu známe čas, kdy začal, ale nevíme, kdy skončí). Během tvorby datového modelu je třeba dodržovat disciplínu při pojmenování faktů. Všechna fakta, která mají přesně stejný význam, by měla být pojmenována stejně a naopak pokud fakta nemají zcela stejný význam, je nutné je v názvu odlišit, aby nedocházelo k nedorozumění a matení uživatelů. Fakta, která mají zcela stejný význam, nazýváme konformní fakta Dimenze Dimenze obsahují popisná data ke sledovaným procesům, respektive ke sledovaným faktům. Odpovídají na otázky kdo, co, kde, kdy, jak a proč, spojené s konkrétní událostí zachycenou ve faktech. Tabulky dimenzí mají často velký počet atributů, výjimkou není ani 50 až 100 atributů, počet řádků je menší než ve faktech, ve výjimečných případech však 39 Degenerovaná dimenze je dimenze, která obsahuje pouze primární klíč. Je součástí tabulky faktů. 32

33 mohou také nabývat velkého objemu, typicky pro dimenze zákazníků apod. Každá tabulka dimenzí má jeden primární klíč, jako primární klíč je vhodné ve všech případech používat umělé klíče (surrogate keys), odstraníme tím závislost na OLTP systémech. Primární klíč slouží ke spojení s tabulkami faktů, v nich je použit jako cizí klíč a zajišťuje referenční integritu mezi fakty a dimenzemi. Jako typický počet dimenzí se v literatuře uvádí 5-15 dimenzí pro každou faktovou tabulku, pokud je jich méně, je vhodné model prověřit, jestli jsme na některou dimenzi nezapomněli. Pokud je dimenzí více než dvacet, je možné, že některé dimenze jsou na sobě závislé, v tom případě bychom je měli spojit. Zakaznik_ID Zakaznik_Jmeno Zakaznik_Kategorie Zakaznik_Subkategorie Zakaznik_Zeme Zakaznik_Kraj Zakaznik_Obec 1 Novák 1 1-a ČR Středočeský Kolín 2 Nováček 1 1-b ČR Ústecký Děčín 3 Pěnkava 3 3-a ČR Středočeský Mladá Boleslav 4 Slavík 3 3-a ČR Středočeský Beroun 5 Mašlová 2 2-c ČR Ústecký Chomutov Tabulka 3: Denormalizovaná hierarchická data Zdroj: autor Jak ukazuje tabulka 3, dimenze často reprezentují hierarchické vztahy (vztah 1:M) mezi atributy dimenze, v jedné dimenzi se běžně vyskytuje několik různých hierarchií. Obvykle se v dimenzi vyskytuje kombinace hierarchických a nehierarchických atributů. Hierarchie má vždy stromovou strukturu. Existují dva způsoby jak řešit hierarchii v rámci datového modelu, buď můžeme dimenzi ponechat jak je, všechny atributy v jedné tabulce, nebo lze tabulku dekomponovat a vytvořit normalizovaný model (obr. 15). V případě použití normalizovaného modelu hovoříme o schématu sněhové vločky, tento model je hůře srozumitelný pro koncové uživatele a komplikuje tvorbu databázových dotazů, upřednostňováno je tedy schéma hvězdy a to i přes nárůst velikosti v důsledku redundantních dat (vzhledem k tomu, že většinu objemu datového skladu tvoří fakta, není tento nárůst příliš závažný). 33

34 Obrázek 15: Normalizovaná (snowflaked) dimenze se dvěma hierarchiemi Zdroj: autor Konformní dimenze Dvě dimenze jsou konformní, pokud atributy v těchto dimenzích jsou stejně pojmenované a mají stejný význam. S pomocí konformních dimenzí lze spojit informace z různých faktových tabulek. Konformní dimenze jsou základ integrace datového skladu, bez nich bychom dostali pouze množinu izolovaných datových tržišť. Zakrnělé (shrunken) dimenze jsou konformní dimenze, které jsou podmnožinou řádků nebo sloupců (nebo kombinací obojího) základní dimenze. Tyto dimenze použijeme v případě, že potřebujeme spojit faktové tabulky s různou granularitou nebo pokud vytváříme agregované tabulky faktů. Outrigger dimenze V některých případech může vzniknout potřeba vytvořit vazbu 1:M přímo mezi dimenzemi, jedná se vlastně o atributy z nějakého důvodu vyčleněné z původní dimenze. V tomto případě není dimenze plně normalizována, tabulky stále mohou obsahovat redundantní data. Outrigger dimenze se často používají, pokud potřebujeme vytvořit vazbu z jedné standardní dimenze na druhou, např. datum nástupu v dimenzi Zaměstnanec. Outrigger dimenze jsou povolené, ale měly by se používat opatrně, spíše v menší míře. Ve většině případů lze vazby mezi dimenzemi řešit spojením přes faktovou tabulku. Degenerované dimenze Degenerovaná dimenze je dimenze, která nemá žádný obsah, kromě svého primárního klíče. V tomto případě je tato dimenze přímo součástí faktové tabulky, bez vazby na tabulku dimenze. Často se tyto dimenze objevují v transakčních tabulkách faktů, může se jednat např. 34

35 o číslo objednávky, číslo transakce nebo číslo faktury, kde tento atribut slouží k určení řádků, které patří k jedné operaci (objednávce, transakci, faktuře apod.). Junk dimenze Při vytváření modelu můžeme často narazit na identifikátory, které nabývají relativně malého množství různých hodnot. Pro jejich realizaci v modelu existuje několik možností: můžeme je ponechat ve faktové tabulce, to však může vést k vyšším kapacitním nárokům vzhledem k vysokému počtu řádků, můžeme vytvořit pro každý atribut jednu dimenzi, nebo tyto atributy můžeme umístit do jedné nebo více junk dimenzí. Junk dimenze je tedy uskupení indikátorů s nízkou kardinalitou, které byly vyjmuty z faktové tabule a umístěny do samostatné dimenze. Při tvorbě junk dimenze je nutné věnovat pozornost počtu řádků v této dimenzi, pokud existuje deset nezávislých atributů, z nichž každý může nabývat tří různých hodnot, vytvořená dimenze bude mít maximálně 10 3 řádků. V případě, že atributy mohou nabývat pěti různých hodnot, počet řádků vzroste až na , když je možných kombinací příliš mnoho, je tedy vhodné atributy rozdělit do několika nezávislých junk dimenzí. Pomalu se měnící dimenze Pomalu se měnící dimenze (Slowly Changing Dimension - SCD) jsou dimenze, ve kterých dochází k řídkým změnám, obvykle nepravidelným. OLTP systémy tyto změny často neřeší a hodnoty prostě přepíší (žijí v přítomnosti), v datovém skladu je však situace jiná a vzniká potřeba tyto změny sledovat pro potřeby historického reportování. Typicky se může jednat o změny jako přejmenování produktu se zachováním jeho ID, přeřazení pracovníka do jiné organizační jednotky, přejmenování pracovníka apod. Je několik různých přístupů, jak se SCD naložit, Ralph Kimball 40 rozlišuje osm základních typů SCD: typ 0 pasivní metoda. Atributy se nemění, stále zůstává zachována původní hodnota. typ 1 přepsání původní hodnoty. Stará hodnota atributu je přepsána novou, atributy typu 1 vždy zobrazují aktuální stav, takže dochází ke ztrátě historie. Tento typ SCD se 40 KIMBALL, Ralph, Margy Ross. The data warehouse toolkit: the definitive guide to dimensional modeling. 3rd ed. Indianopolis: John Wiley, 2013, 601 p. ISBN s

36 snadno implementuje, ale v případě změny je nutné přepočítat agregované tabulky faktů. typ 2 nový řádek. Pokud dojde ke změně atributu, SCD typu 2 vždy přidá nový řádek s novou hodnotou atributu. Tato implementace vyžaduje změnu přirozeného primárního klíče na umělý klíč, protože k existujícímu záznamu budou vznikat další řádky s různými hodnotami atributu. Od okamžiku vytvoření nového řádku se ve všech faktových tabulkách používá klíč nově vytvořeného řádku a to až do doby, než dojde k další změně hodnoty atributu. S typem 2 je nutné přidat do dimenze alespoň tři nové sloupce: odkdy je řádek platný, dokdy byl řádek platný a příznak aktuálního řádku. typ 3 přidání nového atributu. V SCD typu 3 dojde k přidání dalšího atributu, takže dimenze obsahuje v jednom řádku jak původní hodnotu atributu, tak novou. typ 4 přidání mini dimenze. Tato technika se používá v případě, že dochází k častým změnám atributů v rozsáhlé dimenzi. Jako vhodné atributy pro vytvoření mini dimenze se jeví nejen často měněné atributy, ale také často používané atributy. S mini dimenzí je pracováno jako se SCD typ 2. Snahou je udržet počet řádků v mini dimenzi co nejnižší, s tím mohou být spojené také některé kompromisy v modelu např. používání intervalů místo přesných hodnot apod. Mini dimenze má svůj primární klíč a ten je spolu s primárním klíčem dimenze použit v asociované faktové tabulce, vazba mezi základní a mini dimenzí je tedy přes faktovou tabulku. typ 5 mini dimenze a outrigger dimenze typ 1. Tento typ SCD je kombinací typu 4 a outrigger mini dimenze. V základní dimenzi je vytvořen nový atribut typu 1 (takže se vždy přepisuje aktuální hodnotou) a tento atribut odkazuje na aktuální řádek v mini dimenzi, zároveň existuje také vazba mezi mini dimenzí a faktovou tabulkou. Pro uživatele by měla být kombinace základní dimenze a mini dimenze prezentována jako jedna tabulka. 36

37 Obrázek 16: SCD typ 5 Zdroj: upraveno podle 41 typ 6 atribut typu 1 v dimenzi typu 2. Tato implementace SCD je kombinací typu 1,2 a 3. Dimenze obsahuje atribut pro aktuální a atribut pro minulou hodnotu (jako typ 3), při vložení řádku mají oba atributy stejnou, aktuální hodnotu. Pokud dojde ke změně hodnoty atributu, vytvoří se nový řádek stejně jako v typu 2 a zároveň se aktualizuje atribut pro aktuální hodnotu v původně platném řádku (s atributem se tedy pracuje jako s typem 1). Obrázek 17: SCD typ 6 Zdroj: KIMBALL, Ralph, Margy Ross. The data warehouse toolkit: the definitive guide to dimensional modeling. 3rd ed. Indianopolis: John Wiley, 2013, 601 p. ISBN s Tamtéž, s

38 typ 7 dvojitá dimenze typu 1 a 2. Tento typ je implementován jako dimenze typu 2, která obsahuje umělý primární klíč a zároveň klíč, který identifikuje všechny varianty řádků pro daný záznam. Faktová tabulka obsahuje cizí klíče, jak pro primární klíč dimenze, tak pro tento přirozený klíč dimenze. Typ 7 přináší obdobnou funkcionalitu jako typ 6, ale je méně náročný na ETL implementaci. Obrázek 18: SCD typ 7 Zdroj: 43 M:N vztahy a pomocné (bridge) tabulky Dimenzionální modelování je založeno na vztazích 1:N, jediná správná dimenze je taková, která řádku ve faktové tabulce přiřadí pouze jedinou hodnotu. V reálném světě však mohou nastat situace, kdy je nutné řešit M:N vazby mezi dimenzí a faktovou tabulkou, např. k účtu může mít přístup více zákazníků, pacient může mít několik různých diagnóz apod. Tuto situaci můžeme řešit vypuštěním takové dimenze, změnou granularity nebo vytvořením pomocné (bridge) tabulky (obrázek 19). Pokud náš model obsahuje faktovou tabulku s granularitou účet a chceme sledovat vztah účet a zákazník, narazíme na problém v případě účtů, ke kterým má přístup více zákazníků. Zákazníka v tomto případě nemůžeme uvést jako atribut v dimenzi účtů a pokud bychom pro tuto vazbu použili faktovou tabulku, porušíme její granularitu. 43 KIMBALL, Ralph, Margy Ross. The data warehouse toolkit: the definitive guide to dimensional modeling. 3rd ed. Indianopolis: John Wiley, 2013, 601 p. ISBN s

39 Obrázek 19: využití pomocné tabulky pro vazbu M:N Zdroj: autor, upraveno podle 44 Do pomocné tabulky je vhodné doplnit alespoň následující sloupce: začátek platnosti, konec platnosti a váhový faktor (weighting factor). Váhový faktor je číslo od nuly do jedné a součet vah pro jednu položku (v našem případě pro jedno číslo účtu) musí být vždy roven jedné. Váhový faktor umožňuje agregovat aditivní fakta i přes existující M:N vazbu, např. pokud v našem případě sečteme balance účtu pro všechny uživatele s přístupem k účtu a využijeme k tomu váhový faktor, bude výsledek správný. Pro reporty, které využívají váhový faktor pro agregaci faktů, se vžilo označení weighting report. Pokud váhový faktor vynecháme, nemůžeme agregovat aditivní fakta, report bez váhového faktoru se označuje jako impact report. 44 KIMBALL, Ralph, Margy Ross. The data warehouse toolkit: the definitive guide to dimensional modeling. 3rd ed. Indianopolis: John Wiley, 2013, 601 p. ISBN s

40 2 Telekomunikační firma Telekomunikační firma je, jak z hlediska technologií, tak z hlediska procesů, specifickou organizací odlišnou od klasických výrobních nebo prodejních firem. Tato odlišnost vedla ke vzniku specifických podnikových procesů a s tím spojených částí IS. V průběhu času došlo k vytvoření sady rámců Frameworkx 45, jejímž tvůrcem je organizace TeleManagement Forum 46. Na těchto rámcích spolupracuje většina velkých telekomunikačních firem a také významných tvůrců SW a integrátorů. Některé rámce se staly de facto standardy pro danou oblast, především rámec podnikových procesů etom (enhanced Telecommunication Map). Od roku 2004 je rámec etom také doporučením organizace International Telecommunication Union 47, jako ITU-T Recommendation M.3050: Enhanced Telecom Operations Map IS telekomunikační firmy IS telekomunikační firmy tvoří dva základní bloky: Operational Support Systems (OSS) a Business Support Systems (BSS). OSS zajišťuje back-office aktivity, zaměřuje se na provoz telekomunikační sítě. Jedná se o aktivity spojené s provozem sítě, poskytováním a udržováním telekomunikačních služeb pro zákazníky. Tradičními uživateli OSS jsou projektanti sítě, architekti, provoz apod. BSS typicky podporují zákaznicky orientované aktivity jako je fakturace (billing), řízení objednávek, řízení vztahu se zákazníky (CRM), automatizace call centra apod. BSS také může zajišťovat rozhraní mezi zákazníkem a OSS, např. zpracování servisních požadavků nebo potvrzení o zajištění služby zpět zákazníkovi jedná se o back-office aktivity, ale vznikají přímo z kontaktu se zákazníkem. V minulosti byly tyto dvě platformy poměrně jasně odděleny, ale jak jsou sítě a služby stále složitější, přestává být zřetelná také jasná dělicí čára mezi těmito systémy. Na obrázku 20 můžeme vidět základní schéma IS telekomunikačního operátora. Do bloku OSS patří síťové prvky, mediace a provisioning. Billing a CRM (zajišťuje správu zákaznické databáze, produktového katalogu apod.) patří do bloku BSS. Pro jednoduchost se

41 zaměřujeme na části IS spojené s poskytováním telekomunikačních služeb, vynecháváme finanční systémy, lidské zdroje, logistiku apod. Obrázek 20: IS telekomunikační firmy Zdroj: autor Telekomunikační síť Z pohledu IS jsou důležité především prvky, které komunikují s IS firmy, mezi tyto prvky patří ústředny (v případě mobilního operátora se jedná o MSC - Mobile Switching Centre). Další typické prvky mobilní telekomunikační sítě jsou SMSC (Short Message Service Centre), MMSC (Multimedia Messaging Service Centre), GGSN (Gateway GPRS Support Node) a SGSN (Serving GPRS Support Node). Výčet samozřejmě není úplný, ale poskytuje dobrou představu o rozmanitosti zařízení, která komunikují s IS mobilního operátora. MSC; úkolem ústředny je především sestavování, udržování a monitorování hlasových spojení, SMS centrum je zodpovědné za doručování krátkých textových zpráv, MMS centrum je zodpovědné za doručování multimediálních zpráv, 41

42 GGSN (bránový uzel podpory GPRS) je brána mezi účastníky telekomunikační sítě a paketovými sítěmi mimo síť mobilního operátora (Internet), SGSN (obslužný uzel podpory GPRS) je zodpovědný za přenos datových paketů v rámci telekomunikační sítě. Pro všechny tyto prvky platí, že informace o využívání služeb sítě jejími účastníky zaznamenávají a předávají dál ve formě tzv. CDR (Call Detail Records) souborů. CDR je tedy záznam o využití služby telekomunikační sítě jejím účastníkem a slouží jako základ pro tvorbu účtu jednotlivých uživatelů. Někdy se používá také označení EDR (Event Detail Record) nebo UDR (Usage Detail Rocord), pro jednoduchost budeme dále používat označení CDR Mediace Primárním úkolem mediace je konverze CDR dat z různých zdrojů do formátu, kterému rozumí billingový systém. Vstupem jsou data ze síťových prvků a výstupem je obvykle textový soubor. Kromě konverze formátů jsou dalšími důležitými funkcemi mediace kontrola syntaxe a validace CDR, monitoring dat v reálném čase a agregace CDR záznamů Provisioning Provisioningem se v telekomunikacích rozumí proces přípravy telekomunikační sítě k poskytování služby uživateli. V praxi to znamená nastavení síťových prvků tak, aby síť mohla uživateli poskytovat požadovanou službu Rating Rating v telekomunikační praxi znamená ocenění hovoru nebo jiné služby poskytované telekomunikační sítí. Vstupem ratingu jsou CDR, které obsahují informace o události na síti (např. datum a čas volání, délka hovoru, volající, volaný apod.) a tyto informace slouží k ocenění dané události. Mezi základní funkce ratingu patří příjem a akceptace CDR z mediace, validace CDR a odstranění duplicitních záznamů, určení zákaznického účtu, kterému má být událost účtována (guiding), výpočet ceny a aplikace slev. Oceněné události se předávají k dalšímu zpracování billingovému systému. 42

43 Podle času, kdy probíhá ocenění události, rozlišujeme dvě základní formy: online a offline charging. Pokud probíhá ocenění v reálném čase, ještě v průběhu čerpání služby, hovoříme o online chargingu. Rating v tomto případě probíhá na úrovni prvků telekomunikační sítě a tento způsob ratingu je nutný při poskytování předplacených služeb (např. předplacené karty). Offline charging se provádí na službě, jejíž čerpání již skončilo (např. došlo k ukončení telefonního hovoru), nemusí probíhat v reálném čase a provádí se na CDR souborech, které již prošly mediací. Rating je v tomto případě často součástí billingového systému. Základní rozdíl mezi architekturou s online a offline chargingem je vidět na obrázku 21. Obrázek 21: Offline a online charging Zdroj: autor Billing Telekomunikační billing lze popsat jako informační systém zodpovědný za vytváření včasných a přesných účtů (faktur), poskytování informací zákazníkům, procesování a distribuce zákaznických plateb a často také vymáhání pohledávek. Tento také také obvykle podporuje zpracování záloh na poskytování služeb. 43

44 Hlavním cílem billingu je vytvoření zákaznické faktury, k tomu tento systém využívá následující informace (výčet je orientační, konkrétní vstupy závisí na konkrétní implementaci billingového systému): oceněné CDR soubory vygenerované zákazníkovým používáním služeb za dané zúčtovací období (obvykle jeden měsíc), poplatky spojené se zákazníkovými produkty a službami, přeplatek nebo nedoplatek za minulá období, všechny platby provedené zákazníkem za dané zúčtovací období, kompenzace a dobropisy ve prospěch i neprospěch zákazníka, celková sleva daná zákazníkovi, celková daň, datum splatnosti, datum zákazníkova billingu a další parametry nutné pro běh billingu. V první fázi billingu dochází ke spočítání všech položek faktury, poté následuje formátování a generování výstupu k tisku faktury. Pokud je zákaznická báze příliš rozsáhlá, je možné billing rozdělit na několik cyklů (bill cycles) a každému zákazníkovi je přidělen jeden z těchto cyklů Customer Relationship Management Gála 49 rozlišuje tři hlavní komponenty systému pro řízení vztahů se zákazníky (CRM - Customer Relationship Management): operační CRM, kooperativní CRM a analytické CRM. Operační CRM zajišťuje funkce spojené s udržováním databáze zákazníků, podporou a řízením prodeje, podporou a řízením obchodníků, správou objednávek, podporou marketingu apod. Kooperativní CRM podporuje přímo kanály pro komunikaci se zákazníkem, mezi komunikační kanály může patřit call centrum, web, , mobilní aplikace a další. Analytické CRM slouží k analýze informací o zákaznících, k predikci jejich chování, 49 GÁLA, Libor, Jan POUR a Zuzana ŠEDIVÁ. Podniková informatika. 2., přeprac. a aktualiz. vyd. Praha, 2009, 496 s. Expert (Grada). ISBN s

45 segmentaci zákazníků, jejich hodnocení a skóringu (hodnocení zákazníka podle různých hledisek, může se jednat o pravděpodobnost podvodu, odchodu zákazníka, šance na up-sell nebo cross-sell apod.), k automatizaci prodejních a servisních aktivit. 2.2 Frameworkx Frameworkx 50 je sada rámců vyvinutá organizací TeleManagement Forum pro potřeby telekomunikačního průmyslu a pro poskytovatele digitálního obsahu. Frameworkx je rozdělen do pěti rámců: The Business Process Framework (etom) pro modelování a popis podnikových procesů, The Information Framawork (SID) se zaměřením na informace, The Application Framework (TAM) se zaměřuje na aplikace v podniku, The Intergation Framework pro integraci, podnikové metriky, které jsou zaměřeny na problematiku měření výkonnosti podniku. V dalším textu se budeme zabývat podnikovými procesy, tedy rámcem etom Procesní rámec etom Procesní rámec etom je referenční rámec podnikových procesů, zaměřený na telekomunikace a poskytování digitálního obsahu. Na obrázku 22 je znázorněno přehledové schéma rámce etom: na nejvyšší úrovni jej tvoří tři hlavní skupiny procesů (Operations, SIP 51, Enterprise Management), horizontální domény znázorněné jako horizontální boxy, sedm vertikálních seskupení procesů a nakonec interní a externí entity, které interagují s podnikem (znázorněné jako ovály). Zatímco domény (nebo dříve horizontální procesy) představují funkční členění, sedm vertikálních skupin procesů představuje spíše end-to-end procesy, které prostupují všechny domény SIP Strategy, Infrastructure & Product 45

46 Obrázek 22: konceptuální model etom Zdroj: 52 Pojem doména zavádí etom ve své nejnovější verzi 14.5, domény částečně nahrazují původní horizontální procesy úrovně 0 (jak si ukážeme později na provozních procesech, horizontální procesy stále hrají svou roli v dekompozici etom modelu a ve formálním značení procesů). Důvodem pro zavedení domén bylo především sladění s dalšími rámci. Bylo definováno sedm domén: trh a prodej (Market / Sales), produkt (Product), zákazník (Customer), služby (Services), zdroje (Resources), dodavatelé a partneři (Suppliers / Partners), podnik (Enterprise). 52 GB921CP Process Framework Concepts and Principles R TM Forum [online]. Morristown (NJ), 2015 [cit ]. Dostupné z: 46

47 Hlavním cílem domény trh a prodej je přilákat zákazníka k nabídce produktů a služeb, vytvářet a oceňovat řešení, která splňují specifické potřeby zákazníka. Dále také vytvářet a udržovat databázi kontaktů, sběr a analýza dat pro podporu marketingu a tím umožnit vytvářet lépe cílené kampaně a nabídky produktů. Produktová doména je zaměřena na životní cyklus produktu a informace spojené s tímto životním cyklem. Zahrnuje například strategické plány pro produktové portfolio, výkonnost produktů, statistiky o využívání produktů, informace o instanci produktu doručené zákazníkovi. Doména zákazník zahrnuje data a operace spojené se zákazníkem (zákazníkem je jedinec nebo organizace, která od daného podniku získala nějaký produkt či službu). Patří sem všechny typy kontaktu se zákazníkem, řízení vztahů se zákazníkem a správa zákaznických dat. Doména také obsahuje data a činnosti související se zákazníkovým účtem a fakturou, platbami za využívané produkty, pohledávkami po splatnosti či požadavky na informace o zákaznickém účtu a faktuře. Doména služby sestává z informací používaných pro údržbu definice, vývoje a provozních aspektů služeb poskytovaných podnikem. Tato doména podporuje různé podnikové procesy, které se podílejí na definici, vývoji a správě služeb použitých k vytvoření produktů nabízených podnikem. Toto zahrnuje např. SLA (Service Level Agreement), nasazení a konfigurace služeb, management problémů s instalací, nasazením, používáním nebo výkonností služeb. Doména služeb také podporuje plánování budoucích služeb, vylepšování, rušení a kapacitu služeb. Doména zdroje je spojena s infrastrukturou podniku, zahrnuje informace a procesy spojené s definicí, vývojem a správou sítí a aplikačních zdrojů, komponenty infrastruktury a také produkty a služby, které využívají infrastrukturu. Doména má tři hlavní cíle: prvním je spojit zdroje s příslušnými produkty a službami a poskytnout dostatečně detailní sadu entit zdrojů k usnadnění tohoto spojení. Druhým cílem je správa zdrojů, tedy snaha zajistit, že zdroje mohou podporovat a dodávat služby nabízené podnikem. Správa zdrojů znamená plánování, konfiguraci a sledování informací o výkonnosti, využití a bezpečnosti. Také zahrnuje schopnost rekonfigurace zdrojů při ladění výkonnosti, reakci na chyby a korekci provozních nedostatků infrastruktury. Zdroje poskytují informace o svém využívání, ty jsou 47

48 dále agregovány pro potřeby zákaznického vyúčtování. Posledním cílem této domény je umožnit definici plánovacích procesů. Doména dodavatelé a partneři zahrnuje plánování strategií pro dodavatele a partnery, zpracování všech typů kontaktů s dodavateli a partnery, řízení vztahů a správu dodavatelských a partnerských dat. Tato doména také obsahuje data a operace spojené s dodavatelskými a partnerskými účty, spory a požadavky na informace. Poslední doménou je doména podnik. Ta reprezentuje celý podnik, korporaci nebo firmu, která využívá procesní rámec pro modelování podnikových procesů Dekompozice procesů Dekompozice procesů je strukturovaný přístup k analýze podniku prostřednictvím podnikových procesů a jejich interní struktury. Základ tohoto konceptu je znázorněn na obrázku 23. Proces 1 doručuje specifickou funkcionalitu v rámci podniku, může jít například o proces vystavení faktury za služby. Po analýze tohoto procesu můžeme dojít k rozhodnutí, že proces lze rozdělit na tři podprocesy, toto rozdělení vychází. Obrázek 23: Dekompozice procesů Zdroj: GB921P Process Framework Primer R TM Forum [online]. Morristown (NJ), 2015 [cit ]. Dostupné z: 48

49 Procesní rámec etom nejprve dekomponuje podnikové procesy na tři hlavní procesní oblasti: provoz (Operations), strategie, infrastruktura a produkt (Strategy, Infrastructure & Product) a řízení podniku (Enterprise Management). Každá z těchto procesních oblastí se dále dekomponuje na horizontální skupiny procesů (L1 procesy). Další úroveň dekompozice (L2 procesy) kombinuje horizontální skupiny procesů a vertikální end-to-end procesy. Schéma podnikových procesů a jejich dekompozice úrovně 1 je znázorněno na obrázku 24. Obrázek 24: Dekompozice procesů v modelu etom, úroveň 1 Zdroj: autor, upraveno podle 54 Oblast provozních procesů (Operations) sdružuje procesy, které podporují provoz a management činností spojených se zákazníkem a také činnosti nebo operace přímo prováděné zákazníkem. Toto zahrnuje běžné denní činnosti a také procesy podpory provozu a připravenosti. Na oblast provozních procesů, jakožto klíčovou část procesního rámce etom, se zaměříme v samostatné kapitole. Procesní oblast SIP zahrnuje procesy, které vytvářejí strategii podniku, tvoří infrastrukturu, vyvíjí a spravují produkty, služby a dodavatelský řetězec. V pojetí rámce etom není infrastrukturou myšlena pouze IT infrastruktura a zdroje, které slouží k podpoře 54 GB921P Process Framework Primer R TM Forum [online]. Morristown (NJ), 2015 [cit ]. Dostupné z: 49

50 produktů a služeb, ale obsahuje také infrastrukturu, která podporuje funkční procesy, jako jsou např. CRM, lidské zdroje, marketing. SIP procesy nejsou běžné každodenní procesy, které interagují se zákazníkem, ale jedná se o procesy, které plánují, budují, rozvíjejí a určují směr. Oblast Enterprise Management obsahuje základní procesy nutné pro běh podniku. Jedná se o procesy zaměřené na podnik jako celek, jeho cíle a úkoly: procesy spojené s finančním řízením, právní procesy, řízení nákladů a kvality, procesy zodpovědné za nastavení firemní politiky, cílů a strategie, celopodnikové procesy jako je projektové řízení, hodnocení výkonu, hodnocení nákladů apod Oblast provozních procesů Provozní procesy (obrázek 25) jsou základem procesního rámce, jedná se o procesy, které zajišťují každodenní provoz ve vztahu k zákazníkovi, procesy zodpovědné za podporu a připravenost provozních procesů a také se sem řadí management prodeje a řízení vztahů s dodavateli a partnery. Oblast provozních procesů obsahuje tři vertikály end-to-end procesů Fulfillment, Assurance a Billing ( FAB procesy jsou někdy označovány jako zákaznické provozní procesy Customer Operations processes), k těmto se přidává ještě čtvrtá vertikála Operations Support & Readiness. Úkolem vertikály Operations Support & Readiness je umožnit fungování a zajistit provozní připravenost procesů ve vertikálách FAB. Obecně se jedná o procesy a činnosti, které nejsou přímo ve styku se zákazníkem, může jít například o plánování směn v Call centru apod. Vertikála Fulfillment zajišťuje poskytování produktů zákazníkům, a to v požadovaném čase a kvalitě. Tato vertikála je také zodpovědná za převod zákaznických požadavků na konkrétní řešení složené z produktů podniku, informování zákazníka o stavu objednávky a dodání řešení na čas. Vertikála Assurance je zodpovědná za proaktivní i reaktivní údržbu. Procesy této vertikály mají za úkol monitorovat výkonnost i stav zdrojů, aby bylo možné odhalit případné problémy a proaktivně zabránit porušení SLA 55 vůči zákazníkovi. Procesy této vertikály jsou 55 Service Level Agreement smlouva mezi zákazníkem a poskytovatelem služby o úrovni poskytovaných služeb. 50

51 také zodpovědné za příjem zpráv o problémech zákazníka, informování zákazníka o problémech a zajišťují obnovu či opravu služby. Zodpovědností vertikály Billing & Revenue Management je především zajistit vyúčtování zákaznických služeb. Úkolem těchto procesů je zpracování záznamů o využívání služeb, zpracování plateb zákazníků, vystavení zákaznické faktury a vymáhání pohledávek za zákazníky. Kromě uvedených činností zajišťují také zpracování zákaznických dotazů na vyúčtování a jsou zodpovědné za řešení problému souvisejících s vyúčtováním, platbami či vymáháním, to vše včas a v požadované kvalitě. 51

52 Obrázek 25: etom model provozních procesů, úroveň 2 Zdroj: GB921CP Process Framework Concepts and Principles R TM Forum [online]. Morristown (NJ), 2015 [cit ]. Dostupné z: 52

53 3 Tvorba dimenzionálního modelu Tvorba dimenzionálního modelu má podle metodiky Ralpha Kimballa čtyři kroky: výběr podnikových procesů, volba granularity, výběr dimenzí, identifikace faktů. Vstupem pro výběr podnikových procesů jsou sebrané business požadavky, při výběru je důležité začít od procesů, které pokryjí nejdůležitější části činnosti podniku. Pro telekomunikačního operátora jsou klíčové dvě provozní oblasti, první z nich je telekomunikační síť a její využívání, druhou jsou zákazníci. Při výběru podnikových procesů pro datový sklad je tedy vhodné se zaměřit na využití telekomunikační sítě a na procesy, které se podle rámce etom nacházejí v průniku vertikál FAB a zákaznické dimenze. 3.1 Podnikové procesy Standard etom definuje v dané oblasti celkem dvanáct procesů (na obrázku 26 jsou přehledně zobrazeny včetně jejich umístění vůči vertikálám): Customer Interaction Management, úkolem tohoto procesu je zajistit interakci mezi zákazníkem a podnikem, interakce může být vyvolána jak ze strany zákazníka, tak ze strany podniku. Customer Management řídí vztah mezi zákazníkem a podnikem. Tento proces se spouští v rané fázi životního cyklu zákazníka (například ve fázi lead, pro potenciální zákazníky) a trvá až do ukončení vztahu mezi zákazníkem a podnikem. Tento proces zajišťuje jedinečnou identitu každého zákazníka, je zodpovědný za vyhodnocení hodnoty zákazníka, jeho rizika a ověření zákaznické spojenosti. Customer Information Management je zodpovědný za správu zákaznických dat, zajišťuje ukládání, aktualizaci a archivaci informací o zákazníkovi. 53

54 Order Handling, tento proces je zodpovědný za přijímání, odesílání a správu objednávek. Provádí vyhodnocení proveditelnosti ( feasibility check), sleduje stav objednávky, umožňuje změnu objednávky a její zrušení. Problem Handling je zodpovědný za přijímání hlášení zákazníků o chybách a problémech, řešení těchto problémů ke spokojenosti zákazníka a poskytování informací o stavu řešení problému zákazníkovi. Customer QoS/SLA Management monitoruje, řídí a vykazuje úroveň služby dodávané zákazníkovi a porovnává ji s úrovní služby jak je definována v popisu služby, smlouvě či produktovém katalogu. Charging má za úkol přiřadit hodnotu (peněžní) nějaké akci, produktu nebo kombinaci produktů či akcí. Může se jednat o kreditní i debetní operace a ocenění lze provést online i offline. Online charging probíhá v reálném čase a umožnuje telekomunikační firmě nabízet předplacené služby (to ovšem neznamená, že online charging se využívá pouze pro předplacené služby). Další informace o chargingu či ratingu lze nalézt v kapitole Manage Balances je proces zodpovědný za správu zůstatku na účtu zákazníka nebo subscribera 57. Manage Billing Events, tento proces zahrnuje činnosti spojené se zpracováním záznamů o využívání služeb a produktů, jako je mediace, guiding 58, sumarizace a analýza. Bill Invoice Management je proces vytvoření a distribuce vyúčtování zákazníkovi, také zajišťuje aplikaci daní, slev a úprav vyúčtování (dobropis). Bill Payments & Receivables Management, cílem tohoto procesu je zajistit, že příjmy podniku jsou sbírány prostřednictvím předem vytvořených kanálů, vymáhání pohledávek po splatnosti, zpracování plateb a sledování stavu účtu. 57 Z pohledu telekomunikačního operátora můžeme za subscribera považovat např. telefonní linku nebo SIM kartu. Nejedná se přímo o zákazníka, ale subscriber je se zákazníkem svázán. 58 Guiding je proces přiřazení události (typicky reprezentované jako CDR) ke správnému zákaznickému učtu. 54

55 Bill Inquiry Handling zajišťuje včasné a efektivní uspokojení zákaznických dotazů a stížností k vyúčtování. Obrázek 26: etom - FAB vertikály a zákaznická dimenze Zdroj: autor, upraveno podle 59 Vybrané procesy, které budeme dále modelovat, jsou Bill Invoice Management, Manage Balances, Order Handling a Problem Handling. Na základě těchto procesů vytvoříme čtyři datová tržiště podle etom procesů a přidáme tržiště pro sledování využití služeb sítě, jsou to: fakturace, balance účtu, správa objednávek, servisní požadavky (pokrývá nejen problémy, ale požadavky zákazníků, které nemůže vyplnit pracovník ve styku se zákazníkem), využití služeb sítě. 59 GB921CP Process Framework Concepts and Principles R TM Forum [online]. Morristown (NJ), 2015 [cit ]. Dostupné z: 55

56 Systémy, ze kterých bude datový sklad plněn, jsou billingový systém Kenan FX izraelské firmy Comverse 60 a Siebel 61, CRM systém firmy Oracle. Třetím zdrojem je mediace, respektive CDR soubory jí generované. Obrázek 27: Diagram případů užití billingového systému Zdroj: autor Obrázek 27 ukazuje přehledový diagram případů užití billingového systému. Diagram obsahuje celkem šest aktérů, jsou to uživatel, administrátor, CRM, banka, mediace a čas. Uživatel je obvykle členem backoffice týmu 62, uživatelé, ve styku se zákazníkem, by měli pracovat především s CRM, které jako jeden z aktérů zprostředkovává některé činnosti v billingovém systému. Banka předává do billingového systému informace o platbách na účet společnosti, mediace předává CDR soubory. Důležitým aktérem je také čas zodpovědný za spuštění samotného procesu vytvoření faktury (billing). Ukázka popisu případů užití: Název případu užití: Správa produktů zákaznického účtu Tým, který není ve styku se zákazníky. Jedná se obvykle o specializovaný tým, ať už technický nebo businessový, např. reklamace, finance apod. 56

57 Stručný popis: Přidání, změna parametrů nebo ukončení produktů vázaných na zákaznický účet. Hlavní aktéři: CRM, uživatel Vstupní podmínky: Uživatel je přihlášen v systému (přímo v GUI billingového systému nebo v CRM) a má potřebná oprávnění. Hlavní scénář: 1. Přihlášený uživatel vybere zákazníka 2. Pokud je požadovaná akce ukončení nebo změna produktu na zákaznickém účtu Uživatel vybere produkt ze seznamu Uživatel vybere požadovanou akci Pokud je akce změna, uživatel upraví parametry 3. Pokud je požadovanou akcí přidání nového produktu Uživatel vybere produkt ze seznamu Uživatel vloží parametry produktu 4. Uživatel potvrdí provedení akce. Název případu užití: Billing Stručný popis: Ve stanovený čas dojde ke spuštění procesu vytvoření zákaznických faktur. Hlavní aktéři: Čas Vstupní podmínky: Nastal stanovený čas startu procesu Hlavní scénář: 1. Systém načte oceněné CDR záznamy. 2. Systém aplikuje požadované slevy. 3. Systém vypočítá výši daně. 4. Systém aplikuje dobropisy. 5. Systém aktualizuje balanci zákaznického účtu. 6. Systém provede formátování faktury. 7. Systém zveřejní vytvořenou fakturu. 57

58 Diagram případů užití CRM systému ukazuje obrázek 28. Prvním z aktérů jsou online kanály, jedná se o web, hlasovou samoobsluhu, mobilní aplikace apod., tedy o prostředky, které umožňují zákazníkovi objednávat a měnit služby bez přímé účasti pracovníka callcentra. Pracovník callcentra je přímo ve styku se zákazníkem, přijímá jeho požadavky a stížnosti, upravuje a vytváří zákaznické účty a objednává produkty a služby podle požadavků zákazníka. Pracovník backoffice týmu obvykle zpracovává specializované požadavky nebo stížnosti, které nedokáže řešit přímo pracovník ve styku se zákazníkem. Správce systému má na starost správu aplikace, řízení přístupů a také správu katalogu produktů. Billing je pasivním aktérem, přebírá požadavky na zobrazení faktur, změny zákaznického účtu apod. Posledním aktérem je provisioning služeb a produktů, jemu jsou předávány požadavky na aktivaci služby nebo produktu k danému účtu a zpátky vrací potvrzení o stavu zpracování. Obrázek 28: Diagram případů užití CRM Zdroj: autor 58

59 3.1.1 Využití služeb sítě (CDR data mart) Informace o využívání služeb telekomunikační sítě lze získat především z CDR souborů generovaných mediací, další možností může být billingový systém, který obsahuje oceněné CDR záznamy (může se opět jednat o soubory, nebo o záznam v databázi) pro potřebu tvorby vyúčtování. Tabulka 4 obsahuje příklad atributů, které může obsahovat CDR soubor v mobilní telekomunikační síti (jedná se o hlasové CDR, při čerpání jiných služeb budou atributy rozdílné). Název atributu Popis Datový typ (Oracle notace) cdrtype CDR Typ: MOCIN, MOC msoriginating MTC msterminating TRIN, TR transit CFIN, CF callforwarding RCF roamingcallforwarding ISDN isdnoriginating TSP - CAMEL VARCHAR2(5) fileid Název souboru VARCHAR2(6) callidentificationnumber Unikátní číslo hovoru identifikující hovor v rámci ústředny. Obsahuje identifikaci ústředny, kde vznikl. VARCHAR2(6) recordsequencenumber Pořadové číslo záznamu (1.. FFFFFF) VARCHAR2(6) typeofcallingsubscriber Typ subscribera (prepaid/postpaid) VARCHAR2(2) callingpartynumber MSISDN volajícího VARCHAR2(40) calledpartynumber MSISDN volaného VARCHAR2(40) callingsubscriberimei International Mobile Station Equipment Identity (IMEI) volajícího VARCHAR2(48) callingsubscriberimsi International Mobile Subscriber Identity (IMSI) volajícího. Prázdné, pokud jde o hovor bez SIM karty (emergency). VARCHAR2(48) originalcallednumber Původně volané MSISDN, pokud se jedná o CallForward nebo transit VARCHAR2(40) disconnectingparty Kdo ukončil hovor (volající, volaný, síť) NUMBER(1) dateforstartofcharge Datum, kdy došlo ke spojení DATE timeforstartofcharge Čas, kdy došlo ke spojení VARCHAR2(6) dateforstopofcharge Datum, kdy došlo k ukončení spojení DATE timeforstopofcharge Čas, kdy došlo k ukončení spojení VARCHAR2(6) chargeableduration Doba hovoru ve vteřinách NUMBER mscidentification Identifikace ústředny VARCHAR2(40) outgoingroute Svazek, kam bylo předáváno VARCHAR2(7) incomingroute Ze kterého svazku hovor přišel VARCHAR2(7) firstcallinglocationinformation Identifikace první BTS (CGI - CellGlobalIdentity), ze které hovor přišel VARCHAR2(14) firstcalledlocationinformation teleservicecode bearerservicecode lastpartialoutput Identifikace první BTS (CGI - CellGlobalIdentity), na kterou přišel hovor Identifikuje typ hovoru (normální, pohotovostní, fax). Pokud je použitý, tak není k dispozici bearerservicecode Identifikuje typ hovoru (normální, pohotovostní, fax). Pokud je použitý, tak není k dispozici teleservicecode VARCHAR2(14) NUMBER(2) NUMBER(2) Označuje poslední CDR, pokud dochází k dělení CDR. (0 = ne, 1 = ano) NUMBER(1) 59

60 Název atributu Popis Datový typ (Oracle notace) partialoutputrecnum Pořadové číslo CDR, pokud dochází k dělení CDR. NUMBER(2) networkcallreference internalcauseandloc eosinfo Jednoznačný identifikátor hovoru. Všechny CDR k jednomu hovoru mají tento atribut shodný. Důvod ukončení hovoru vztahující se k protokolům v síti. Např. z důvodu nedostupného důležitého prvku v síti. Proč hovor nebyl spojen. (účastník nedostupný, obsazeno, ústředna neměla prostředky) VARCHAR2(10) VARCHAR2(4) VARCHAR2(2) bssmapcausecode Identifikace události, která vedla k rozpojení hovoru. VARCHAR2(2) faultcode Proč došlo k rozpojení hovoru, interní error code. VARCHAR2(4) Tabulka 4: CDR atributy Zdroj: autor CDR po vygenerování některým prvkem telekomunikační sítě projde mediací, která vytvoří formátovaný CDR a ten předá ratingu. Rating přidělí tomuto CDR cenu a předá ho k dalšímu zpracování billingovému systému. Tyto záznamy jsou obvykle uloženy v relační databázi, na obrázku 29 je znázorněn ER diagram pro příslušnou část billingového systému Kenan FX. Obrázek 29: Kenan FX - CDR management ER diagram Zdroj: autor CDR záznamy určené pro billingový systém často obsahují pouze atributy potřebné pro vystavení vyúčtování, často se jedná o atributy derivované z originálních atributů, lokalizační údaje či informace o důvodu přerušení hovoru chybí. Pokud je v obou zdrojích 60

61 shodná granularita dat, lze to řešit spojením do jedné faktové tabulky, ale někdy můžeme narazit na situaci, kdy je původní CDR rozdělen do několika záznamů, ale billingový systém obsahuje pouze jeden spojený záznam. Další překážkou pro spojení těchto dvou zdrojů mohou být rozdílné primární klíče. V datovém skladu je vhodné oddělit CDR popisující různé typy událostí (někdy se označuje jako usage type), tyto záznamy jsou generovány jinými prvky sítě, obsahují různé atributy a používají jiné jednotky (např. CDR pro hlasové služby bude obsahovat informaci o délce hovoru, jednotkou budou vteřiny, ale CDR pro datové služby bude obsahovat objem přenesených dat v kb). Dalším argumentem pro rozdělení je velikost faktových tabulek, objem generovaných CDR může být opravdu velký, v případě České republiky se u průměrného mobilního operátora může jednat o desítky milionů CDR denně. Pro CDR je typické, že pouze vznikají nové, nikdy nedochází k jejich zpětné modifikaci. Granularitu je vhodné zvolit co nejvyšší, v tomto případě to bude na úrovni jednotlivých generovaných CDR, tabulka faktů bude transakční. Každému záznamu ve faktové tabulce bude odpovídat jeden CDR Fakturace Jádrem informací o faktuře jsou v Kenan FX tři tabulky, první z nich je BILL_INVOICE, která obsahuje informace platné pro celou fakturu, jako je číslo faktury, fakturační účet, datum vystavení, datum splatnosti, billingový cyklus, platební metoda apod. Tabulka BILL_INVOICE_DETAIL obsahuje jednotlivé řádky faktury, důležité údaje jsou číslo faktury, číslo řádku faktury, číslo subscribera, částka, částka daně, sazba daně, částka slevy a deskripce řádku. Poslední ze tří základních tabulek je BILL_INVOICE_DISCOUNT, tato tabulka obsahuje informace o slevě na daný řádek tabulky BILL_INVOICE_DETAIL, pokud je sleva na řádku faktury kumulovaná z více slev, obsahuje řádek pro každou jednotlivou slevu. Tabulka BILL_INVOICE_DETAIL v tom případě obsahuje agregovanou částku a chybí v ní odkaz na konkrétní slevu. Přehledový ER diagram příslušné části datového modelu systému Kenan FX je znázorněn na obrázku 30. Při rozhodování o granularitě dat v tomto datovém tržišti je nutné si uvědomit, že popsané tabulky mají rozdílnou granularitu: tabulka BILL_INVOICE obsahuje data na úrovni celé faktury, BILL_INVOICE_DETAIL na úrovni jednotlivých řádků faktury a BILL_INVOICE_DISCOUNT na úrovni jednotlivých slev, mezi tabulkami BILL_INVOICE a 61

62 BILL_INVOICE_DETAIL je tedy vztah 1:N a stejně tak mezi tabulkami BILL_INVOICE_DETAIL a BILL_INVOICE_DISCOUNT. Pokud zvolíme jako granularitu fakturu, nebudeme schopni analyzovat fakturované částky podle jednotlivých částí faktury, nedokážeme rozlišit, jaký objem z celkové částky tvoří platba za hlasové služby, jaká za data apod. Vhodné tedy bude spojit data z obou tabulek a některé údaje z BILL_INVOICE duplikovat. Pro toto řešení hovoří také skutečnost, že BILL_INVOICE obsahuje pouze popisná data, nikoli možná fakta. Jiná situace je u tabulky BILL_INVOICE_DISCOUNT, ta obsahuje rozpad slevy na daném řádku faktury a pokud bychom chtěli udržet granularitu na této úrovni a spojit data ze všech tří tabulek, znamenalo by to duplicitu v aditivních faktech z tabulky BILL_INVOICE_DETAIL. Pokud není rozpad na jednotlivé slevy důležitý, respektive neexistují požadavky na analýzu podle konkrétního typu slevy a stačí pouze celková výše slevy, lze tuto tabulku zcela vynechat. Pokud jsou informace o typu slevy vyžadovány, lze vytvořit dvě tabulky faktů s různou granularitou. První tabulka bude obsahovat informace s granularitou řádku faktury a druhá s granularitou slevy. Poslední možností je vytvořit jednu tabulku faktů s granularitou slevy, ale v tomto případě musíme do tabulky přidat přepočtový faktor, který nám umožní pracovat s aditivními fakty na úrovni řádku faktury. Jako vhodnější se mi jeví řešení se dvěma tabulkami faktů, kde první bude obsahovat data s granularitou řádek faktury a druhá s granularitou sleva na řádku faktury. 62

63 Obrázek 30: Kenan FX - ER diagram fakturace a zákaznický účet Zdroj: autor Balance účtu Balance účtu je v Kenan FX udržována v tabulce CMF_BALANCE (obrázek 30). Tabulka CMF_BALANCE obsahuje řádek pro každý fakturační účet a fakturu vystavenou pro tento účet, včetně řádku pro dočasné uložení balance, kterou nelze přiřadit žádné vystavené faktuře (suspense invoice). Tabulka obsahuje číslo fakturačního účtu, číslo faktury, datum splatnosti faktury, datum uzavření faktury (kdy balance této faktury dosáhla nuly), účtovanou částku k faktuře (obsahuje také dobropisy vystavené před billingem, po vytvoření faktury se tato hodnota již nemění), částka dobropisovaná po billingu, celkový dluh k okamžiku vytvoření řádku (dále se již nemění), celkem zaplaceno z částky na dané faktuře (částka se mění, jak jsou proti faktuře započítávané platby nebo dobropisy) a celkový zůstatek na účtu. 63

64 Pro volbu granularity mámě dvě varianty, buď granularitu na úrovni faktury, nebo granularitu na úrovni účtu. Jako vhodnější mi přijde denní snímek s granularitou účtu, pokud by nás zajímalo, jak jsou postupně umořovány faktury a pohyb peněz, je vhodnější sledovat platby a jejich distribuci Správa objednávek Správa objednávek je v Siebel CRM tvořena především dvěma tabulkami, S_ORDER a S_ORDER_ITEM. S_ORDER obsahuje hlavičky objednávek, tedy informace typu: číslo objednávky, kategorie a typ objednávky, status objednávky, kdo a kdy objednávku založil, kdo a kdy objednávku naposled modifikoval, požadovaný termín odeslání, datum a čas poslední změny statusu objednávky, zákaznický účet, fakturační účet apod. Tabulka S_ORDER_ITEM obsahuje data pro jednotlivé řádky objednávky: hodnotu položky, datum a čas vytvoření, datum a čas poslední modifikace, status, produkt, typ akce a další. ER diagram popisující správu objednávek a její okolí v Siebel CRM je znázorněn na obrázku 31. Obrázek 31: Siebel CRM - ER diagram správy objednávek Zdroj: autor Při práci s objednávkami je důležité si uvědomit, stejně jako v případě fakturace, rozdílnou granularitu obou tabulek a rozhodnout se jak s tabulkami pracovat. Pokud se 64

65 rozhodneme pro detail na úrovni objednávky, je možné agregovat fakta z jednotlivých řádků, ale tímto krokem se připravíme o možnost analýzy na úroveň produktů a to je poměrně velký problém. Zvolíme tedy stejný postup jako v případě fakturace (kapitola 3.1.2) a spojíme data do jedné tabulky faktů, pokud existují na úrovni objednávky aditivní nebo semiaditivní fakta je nutné práci s nimi ošetřit pomocí podílového koeficientu, kterým je možné v případě součtu vynásobit hodnoty těchto faktů. Práci s tímto koeficientem je vhodné skrýt před koncovými uživateli pomocí databázového pohledu. Obrázek 32: Životní cyklus objednávky Zdroj: autor Důležité je také si uvědomit, jakým způsobem chceme objednávky sledovat, pokud nám stačí informace, že byla vytvořena objednávka, jak trvala objednávka dlouho a jak skončila, bude nejlepší vytvořit transakční tabulku faktů, do které budeme vkládat pouze objednávky v některém z finálních stavů (životní cyklus objednávky je znázorněn na obrázku 32). Pokud je třeba sledovat, jak dlouho trvaly jednotlivé kroky objednávky, musíme zvolit jiný přístup. Vhodným řešením je akumulovaný snímek objednávky. V případě akumulovaného snímku se existující záznam ve faktové tabulce aktualizuje o nové stavy, tento postup je znázorněn na obrázku 33 (zobrazený příklad je pouze ilustrativní, v případě 65

66 reálného nasazení bude řádek obsahovat také klíče dimenzí). V prvním kroku je vložen nový záznam do tabulky faktů, tento záznam obsahuje informace známé při jeho vložení, po čase dojde ke změně statusu objednávky z hodnoty CREATED na SUBMITED, to vyvolá aktualizaci existujícího záznamu, je změněn status objednávky, je vloženo datum změny statusu do sloupce submit_date a je vložen rozdíl obou časů do sloupce create_to_submit. Při přechodu objednávky do některého z finálních stavů dojde opět k aktualizaci statusu, je změněn příznak ve sloupci is_final_status, je vložen datum do sloupce completed_date a vypočten obsah sloupce create_to_completed. Tato implementace nám umožní sledovat životní cyklus objednávky a také dopočítat chybějící časy přechodu mezi statusy, sledované statusy je však nutné v případě složitějšího životního cyklu pečlivě vybírat. Vložen řádek s novou objednávkou ORDER_NUM CREATE_DATE SUBMIT_DATE COMPLETED_DATE STATUS IS_FINAL_STATUS CREATE_TO_SUBMIT CREATE_TO_COMPLETED :20 CREATED N Změna statusu objednávky, aktualizace řádku objednávky ORDER_NUM CREATE_DATE SUBMIT_DATE COMPLETED_DATE STATUS IS_FINAL_STATUS CREATE_TO_SUBMIT CREATE_TO_COMPLETED : :42 SUBMITED N Změna statusu objednávky, aktualizace řádku objednávky ORDER_NUM CREATE_DATE SUBMIT_DATE COMPLETED_DATE STATUS IS_FINAL_STATUS CREATE_TO_SUBMIT CREATE_TO_COMPLETED : : :58 FAILED Y Obrázek 33: Akumulovaný snímek faktů Zdroj: autor Protože chceme zachovat možnost analyzovat objednávky také na úrovni služby, zvolíme granularitu na úrovni řádku objednávky. Dalším důležitým rozhodnutím je, jaký zvolit typ faktové tabulky, zda transakční a plnit ji pouze objednávkami ve finálním statusu nebo akumulovaný snímek a sledovat i přechody mezi stavy. Řešení s akumulovaným snímkem navíc komplikuje fakt, že objednávku ve stavu Pending lze dále modifikovat, její obsah není finální, tento problém lze řešit vkládáním pouze objednávek, které přejdou do některého z návazných stavů. I přes toto řešení je vhodnější volbou vkládat pouze objednávky ve finálním stavu, životní cyklus objednávky je poměrně složitý, obsahuje větvení, takže implementace i následná analýza dat by byla velmi náročná. 66

67 3.1.5 Servisní požadavky Servisní požadavek je obecně požadavek zákazníka na informaci, na asistenci se službou nebo při řešení problému. V Siebel CRM servisní požadavek slouží ke sledování požadavku zákazníka, který vyžaduje nějaké následné akce. Na základě požadavku zákazníka je vytvořen záznam o požadavku, ten je následně předán k řešení konkrétní osobě nebo týmu. Pokud dokáže zákaznický požadavek vyřešit přímo pracovník ve styku se zákazníkem, používají se pro sledování těchto požadavků aktivity. Obrázek 34: Siebel CRM - ER diagram servisních požadavků Zdroj: autor Na obrázku 34 je znázorněn ER diagram, který popisuje část datového modelu Siebel CRM obsahující informace o servisních požadavcích. Centrum tvoří tabulka S_SRV_REQ, která obsahuje informace o vytvořeném servisním požadavku: číslo požadavku, kategorii požadavku, typ požadavku, status, produkt, konkrétní instanci produktu (asset), identifikaci zákazníka, kdo záznam vytvořil, kdo řeší apod. Servisní požadavky budeme sledovat na úrovni jednotlivých požadavků a v tomto případě je pro nás důležité sledovat časy přechodů a změny stavu požadavku (životní cyklus 67

68 servisního požadavku je znázorněn na obrázku 35), vhodným typem faktové tabulky je akumulovaný snímek. Jak bude na zdroji docházet ke změně stavu servisního požadavku, bude také docházet k modifikaci příslušného řádku faktové tabulky. Sledovanými stavy servisního požadavku budou statusy New, Solved, Closed, Reopen a Cancelled. Obrázek 35: Životní cyklus servisního požadavku Zdroj: autor 3.2 Dimenze Výběr dimenzí je v Kimballově metodice velice důležitý, protože dimenze jsou prvkem zodpovědným za integraci datového skladu, pokud zvolíme špatné dimenze, vytvořený datový sklad bude pouze množinou izolovaných datových tržišť. V předešlém kroku jsme definovali pět podnikových procesů, každý z těchto procesů odpovídá jedné faktové tabulce, přehledně, včetně zvolené granularity, jsou uvedeny v tabulce 5. 68

69 Podnikový proces Jméno tabulky Granularita Využití sítě CDR_VOICE_F Vygenerovaný CDR Fakturace BILL_INVOICE_F Řádek faktury Balance účtu ACCOUNT_BALANCE_F Denní snímek balance účtu Správa objednávek ORDER_MNGT_F Řádek dokončené objednávky Servisní požadavky Tabulka 5: Tabulky faktů Zdroj: autor SERV_REQ_F Akumulovaný snímek servisního požadavku Všechna datová tržiště budou také obsahovat degenerované dimenze. Jako degenerované dimenze implementujeme dimenze, které jednak obsahují pouze jediný popisný atribut (např. status, kategorie, typ, volané a volající číslo apod.) a zároveň nemají význam pro integraci, tedy vyskytují se pouze v daném datovém tržišti. Dále se budeme zabývat pouze dimenzemi, které jsou implementovány samostatně. Při plnění dimenzí je vhodné myslet také na možnost, že se nepodaří spojit záznam v tabulce faktů s žádnou hodnotou v dimenzi, či hodnota příslušného atributu chybí a do každé dimenze připravit řádek pro takový případ. Prvním datovým tržištěm je Využití sítě, v tomto tržišti využijeme dimenze datum, čas, subscriber, fakturační účet, zákazník a lokalita buňky. Datumová a časová dimenze se vyskytují ve dvou významech, jednou je to pro datum a čas začátku spojení a podruhé pro ukončení spojení. Graficky je datové tržiště znázorněno na obrázku 36. Obrázek 36: Datové tržiště Využití sítě Zdroj: autor 69

70 Datové tržiště Fakturace (obrázek 37) obsahuje informace o řádcích vystavených faktur, mezi dimenzemi jsou opět: datum, subscriber, fakturační účet a zákazník, nově se objevila dimenze fakturační cyklus. Datum je opět ve dvou významech, jednou je to datum vystavení faktury, podruhé datum splatnosti. Bohužel neexistuje jednoznačné přiřazení produktu řádku faktury, budeme si muset vystačit s popisem řádku, který ponecháme jako degenerovanou dimenzi. Obrázek 37: Datové tržiště Fakturace Zdroj: autor Informace o balanci účtu sledujeme v tržišti Balance účtu, jedná se o denní snímek balance účtu, takže jednou dimenzí bude datum, další dimenze budou zákazník a fakturační účet, grafické znázornění na obrázku 38. Obrázek 38: Datové tržiště Balance účtu Zdroj: autor Správa objednávek (obrázek 39) obsahuje informace o řádcích uzavřených objednávek, opakují se dimenze datum a čas, zákazník, fakturační účet, subscriber. Nově se 70

71 objevují dimenze zaměstnanec, adresa a kontakt. Dimenze datum, čas, adresa a kontakt se vyskytují v několika významech. Obrázek 39: Datové tržiště Správa objednávek Zdroj: autor Posledním z modelovaných datových tržišť je tržiště Servisní požadavky (obrázek 40), sada dimenzí je shodná, jako v případě předchozího tržiště, datum a čas, zákazník, fakturační účet, subscriber, zaměstnanec, produkt, kontakt a adresa. Datum, čas a zaměstnanec se vyskytují ve více významech. 71

72 Obrázek 40: Datové tržiště Servisní požadavky Zdroj: autor Adresa Dimenze adresa je z hlediska implementace velice jednoduchá, pochází z jediného systému a z jediné tabulky, všechny atributy jsou typu 1 63, přehledně je mapování dimenze znázorněno v tabulce 6. Hierarchii tvoří v dimenzi územněsprávní prvky, konkrétně to jsou atributy Země, Stát, Kraj, Okres, Obec a Část obce. Graficky je vztah mezi atributy znázorněn na obrázku 41, dimenze, včetně mapování zdroj-cíl je zobrazena v tabulce 6. Obrázek 41: Hierarchie adresy Zdroj: autor Jméno tabulky Cíl Jméno sloupce Zdrojový systém Zdroj Jméno tabulky Jméno sloupce Popis SCD typ ADDRESS_D ADDRESS_KEY ETL surrogate key 1 ADDRESS_D SIEBEL_ROW_ID Siebel S_ADDR_PER ROW_ID unikátní identifikátor řádku v tabulce S_ADDR_PER ADDRESS_D CREATED Siebel S_ADDR_PER CREATED Kdy byl záznam vytvořen 1 ADDRESS_D END_DT Siebel S_ADDR_PER END_DT Konec platnosti adresy Typy dimenzí jsou popsány v kapitole

73 Jméno tabulky Cíl Jméno sloupce Zdrojový systém Zdroj Jméno tabulky Jméno sloupce Popis SCD typ ADDRESS_D START_DT Siebel S_ADDR_PER START_DT Začátek platnosti adresy 1 ADDRESS_D ADDR_NAME Siebel S_ADDR_PER ADDR_NAME Název adresy 1 ADDRESS_D ACTIVE_FLG Siebel S_ADDR_PER ACTIVE_FLG Příznak aktivní adresy 1 ADDRESS_D ALTITUDE Siebel S_ADDR_PER ALTITUDE Nadmořská výška 1 ADDRESS_D LATITUDE Siebel S_ADDR_PER LATITUDE Latitude. 1 ADDRESS_D LONGITUDE Siebel S_ADDR_PER LONGITUDE Longitude. 1 ADDRESS_D TIME_ZONE_CD Siebel S_ADDR_PER TIME_ZONE_CD Časová zóna 1 ADDRESS_D ZIPCODE Siebel S_ADDR_PER ZIPCODE PSČ 1 ADDRESS_D COUNTRY Siebel S_ADDR_PER COUNTRY Země 1 ADDRESS_D STATE Siebel S_ADDR_PER STATE Stát 1 ADDRESS_D PROVINCE Siebel S_ADDR_PER PROVINCE Kraj 1 ADDRESS_D COUNTY Siebel S_ADDR_PER COUNTY Okres 1 ADDRESS_D CITY Siebel S_ADDR_PER CITY Obec 1 ADDRESS_D DISTRICT Siebel S_ADDR_PER DISTRICT Část obce 1 ADDRESS_D STREET Siebel S_ADDR_PER ADDR Ulice 1 ADDRESS_D ADDR_LINE_2 Siebel S_ADDR_PER ADDR_LINE_2 Ulice řádek 2 1 ADDRESS_D ADDR_LINE_3 Siebel S_ADDR_PER ADDR_LINE_3 Ulice řádek 3 1 ADDRESS_D DESCRIPTION_NUMBER Siebel S_ADDR_PER ADDR_LINE_4 Číslo popisné 1 ADDRESS_D HOUSE_NUMBER Siebel S_ADDR_PER ADDR_LINE_5 Číslo orientační 1 ADDRESS_D MISC_ADDR_LINE Siebel S_ADDR_PER MISC_ADDR_LINE ADDRESS_D RECORD_TS Tabulka 6: Dimenze adresa Zdroj: autor ETL Různé informace, např. jméno budovy, PO box apod. kdy byl záznam vložen do dimenze nebo modifikován Audit Auditní dimenze je jedním z nejúčinnějších nástrojů pro řízení kvality dat. Tato dimenze by měla být připojena ke každé faktové tabulce, takže uživatelé datového skladu si mohou ověřit původ dat a jejich kvalitu a tím i zvýšit jejich důvěru v datový sklad. Zjednodušeně lze říci, že prostřednictvím auditní dimenze jsou metadata povýšena na běžná data a uživatelům je dána možnost s nimi pracovat v reportech. Atributy auditní dimenze lze rozdělit na dvě základní skupiny, první jsou informace o prostředí, druhá jsou ukazatelé datové kvality. Navržená struktura auditní dimenze je v tabulce 7. 73

74 Název sloupce Typ atributu Popis AUDIT_KEY Prostředí Surrogate key ETL_VERSION Prostředí Verze ETL systému SOURCE_SYSTEM Prostředí Jméno zdrojového systému EXTRACT_TIMESTAMP Prostředí Časové razítko, kdy byl záznam extrahován LOAD_TIMESTAMP Prostředí Časové razítko, kdy byl záznam nahrán COMPLETE Datová kvalita Podařilo se nahrát všechny fakta v daném řádku? OUT_OF_BOUND Datová kvalita Je hodnota některého faktu v řádku mimo běžné hranice? MODIFIED Datová kvalita Bylo nutné některé hodnoty v řádku modifikovat? SCREENS_FAILED Datová kvalita Počet testů, které zhavarovaly Tabulka 7: Auditní dimenze Zdroj: autor Datum a čas Dimenze datum bude připojena prakticky ke všem faktovým tabulkám, jedná se o dimenzi, obsahující datum a mnoho různých atributů, které daný den popisují. Na obrázku 42 jsou schematicky vyobrazeny hierarchie v dimenzi datum. Obrázek 42: Hierarchie dimenze datum Zdroj: autor Na rozdíl od většiny ostatních dimenzí lze dimenzi datum (to samé platí i o dimenzi čas) vygenerovat dopředu, není žádný problém si naplnit dimenzi záznamy na 10 let a pokrýt, jak již existující historii, tak budoucí data. 74

75 Jméno sloupce Datový typ Popis DATE_KEY NUMBER(6) surrogate key DATE_VAL DATE den uložený jako datový typ DATE DAY_OF_WEEK_NUM NUMBER(1) číslo dne v týdnu, je třeba si ujasnit, jakým dnem týden začíná DAY_OF_WEEK VARCHAR2(10) jméno dne WEEKDAY_TYPE VARCHAR2(10) informace, jestli jde o víkend nebo ne DAY_OF_MONTH_NUM NUMBER(2) číslo dne v měsíci DAY_OF_YEAR_NUM NUMBER(3) číslo dne v roce WEEK NUMBER(2) týden v roce MONTH_NUM NUMBER(2) číslo měsíce MONTH VARCHAR2(10) jméno měsíce QUARTER NUMBER(1) čtvrtletí HALFYEAR NUMBER(1) pololetí YEAR NUMBER(4) rok FY_DAY_OF_YEAR_NUM NUMBER(3) číslo dne ve fiskálním roce FY_WEEK NUMBER(2) týden fiskálního roku FY_MONTH_NUM NUMBER(2) měsíc fiskálního roku FY_QUARTER NUMBER(1) čtvrtletí fiskálního roku FY_HALFYEAR NUMBER(1) pololetí fiskálního roku FY_YEAR NUMBER(4) fiskální rok HOLIDAY_FLAG CHAR(1) příznak svátku HOLIDAY_NAME VARCHAR2(256) jméno svátku EVENT VARCHAR2(256) důležitá událost Tabulka 8: Dimenze datum Zdroj: autor Někdy může svádět rozšíření dimenze datum také o čas, to však není dobrý nápad, jen za jeden rok by to znamenalo řádků dimenze při volbě granularity na jednu vteřinu. Dimenze čas by měla obsahovat alespoň počet vteřin od půlnoci a hierarchii vteřina, minuta a hodina. Dimenzi lze samozřejmě rozšířit, vše se odvíjí od požadavků na filtrování, možné další atributy jsou dopoledne/odpoledne, pracovní doba apod. Jméno sloupce Datový typ Popis TIME_KEY NUMBER(5) surrogate key SECONDS_FROM_MIDNIGHT NUMBER(5) počet vteřin od půlnoci HOUR NUMBER(2) hodina MINUTE NUMBER(2) minuta SECOND NUMBER(2) vteřina Tabulka 9: Dimenze čas Zdroj: autor 75

76 3.2.4 Fakturační cyklus Dimenze fakturační cyklus (tabulka 10) neobsahuje žádnou hierarchii, jedná se o jednoduchou dimenzi, která kombinuje obsah dvou tabulek. Tabulka BILL_CYCLE obsahuje informace o každém fakturačním cyklu, jako je jméno periody, datum vystavení faktury, datum splatnosti, kód frekvence apod. Tabulka BILL_FREQUENCY_VALUES obsahuje popis jednotlivých frekvencí, tato tabulka obsahuje řádek pro každou kombinaci frekvence a jazyka, při spojení tabulek je s tím tedy nutné počítat a omezit výběr pouze na jeden jazyk. Ukázka SQL dotazu pro získání dat k naplnění dimenze: select c.bill_period, c.billing_frequency, c.ppdd_date, c.next_ppdd_date, c.statement_date, c.cutoff_date, c.prep_delay, c.prep_date, f.short_display, f.display_value from arbor.bill_cycle c, arbor.billing_frequency_values f where f.billing_frequency = c.billing_frequency and language_code = 1; Jméno tabulky Cíl Jméno sloupce Zdrojový systém Zdroj Jméno tabulky Jméno sloupce SCD typ BILLCYCLE_D BILLCYCLE_KEY ETL 0 Surrogate key BILLCYCLE_D BILL_PERIOD Kenan BILL_CYCLE BILL_PERIOD 0 Popis název billingového cyklu BILLCYCLE_D BILLING_FREQUENCY Kenan BILL_CYCLE BILLING_FREQUENCY 0 kód frekvence billingu BILLCYCLE_D PPDD_DATE Kenan BILL_CYCLE PPDD_DATE 0 datum splatnosti BILLCYCLE_D NEXT_PPDD_DATE Kenan BILL_CYCLE NEXT_PPDD_DATE 0 datum splatnosti následujícího cyklu BILLCYCLE_D STATEMENT_DATE Kenan BILL_CYCLE STATEMENT_DATE 0 datum vystavení BILLCYCLE_D CUTOFF_DATE Kenan BILL_CYCLE CUTOFF_DATE 0 BILLCYCLE_D PREP_DELAY Kenan BILL_CYCLE PREP_DELAY 0 BILLCYCLE_D PREP_DATE Kenan BILL_CYCLE PREP_DATE 0 maximální datum a čas, který ještě bude na faktuře s jakým zpožděním v hodinách začne zpracování faktur po CUTOFF_DATE CATOFF_DATE + PREP_DELAY BILLCYCLE_D SHORT_DISPLAY Kenan BILL_FREQUENCY_VYLUES SHORT_DISPLAY 0 krátký popis frekvence BILLCYCLE_D DISPLAY_VALUE Kenan BILL_FREQUENCY_VYLUES DISPLAY_VALUE 0 popis frekvence BILLCYCLE_D RECORD_TS ETL 1 Tabulka 10: Dimenze fakturační cyklus Zdroj: autor kdy byl záznam vložen do dimenze nebo modifikován 76

77 3.2.5 Kontakt Dimenze kontakt obsahuje data o kontaktech v systému Siebel CRM, dimenze neobsahuje žádné hierarchie. Atributy této dimenze (celkem se jedná o 55 atributů) se dají rozdělit do tří hlavních skupin. První skupinou jsou systémové informace, např. generovaný primární klíč dimenze, unikátní identifikátor řádku zdrojové tabulky, kdy byl kontakt vytvořen ve zdrojovém systému, kdy byl kontakt naposledy změněn. Druhou skupinu tvoří kontaktní údaje, jako je jméno, příjmení, oslovení, titul, adresa elektronické pošty, telefonní číslo apod. Třetí skupina obsahuje různé demografické údaje, např. národnost, datum narození, datum úmrtí, rodinný stav a další. Tato dimenze obsahuje jak atributy SCD typu 1, tak atributy SCD typu 2, u kterých chceme znát i jejich historické hodnoty. V případě SCD typu 2 řešíme změnu hodnoty atributu přidáním nového řádku, který obsahuje nové hodnoty, aby bylo možné spojit všechny řádky patřící k jednomu kontaktu. Je nutné, aby dimenze obsahovala klíč, který identifikuje konkrétní kontakt, ideální je využít přirozený klíč, který existuje ve zdrojových datech. Dimenzi je také vhodné rozšířit o tři nové atributy: časová známka odkdy řádek platí, časová známka dokdy řádek platil a příznak aktuálně platného řádku. Ukázku dimenze kontakt zobrazuje tabulka 11. Jméno tabulky Cíl Jméno sloupce Zdrojový systém Jméno tabulky Zdroj Jméno sloupce SCD Typ Popis CONTACT_D CONTACT_KEY ETL Surrogat key CONTACT_D ROW_ID Siebel S_CONTACT ROW_ID 0 77 unikátní identifikátor kontaktu v tabulce S_CONTACT. Přirozený klíč pomocí kterého svážeme všechny řádky patřící k jednomu kontaktu CONTACT_D CREATED Siebel S_CONTACT CREATED 0 kdy byl kontakt vytvořen CONTACT_D LAST_UPD Siebel S_CONTACT LAST_UPD 1 kdy byl kontakt naposledy modifikován CONTACT_D FST_NAME Siebel S_CONTACT FST_NAME 1 křestní jméno CONTACT_D MID_NAME Siebel S_CONTACT MID_NAME 1 prostřední jméno CONTACT_D LAST_NAME Siebel S_CONTACT LAST_NAME 1 příjmení CONTACT_D OCCUPATION Siebel S_CONTACT OCCUPATION 2 rodinný stav CONTACT_D NATIONALITY Siebel S_CONTACT NATIONALITY 2 národnost CONTACT_D RESIDENT_STAT_CD Siebel S_CONTACT RESIDENT_STAT_CD 2 typ pobytu CONTACT_D EFF_START_TS ETL odkdy platí daný řádek CONTACT_D EFF_END_TS ETL dokdy řádek platil CONTACT_D CURRENT_FLG ETL příznak aktuálního kontaktu kdy byl záznam vložen do dimenze nebo CONTACT_D RECORD_TS ETL 1 modifikován Tabulka 11: Dimenze kontakt Zdroj: autor

78 3.2.6 Lokalita Tato dimenze je plněna ze souboru, který obsahuje záznam pro každou lokalitu, kde je umístěna BTS 64, mapování dimenze je v tabulce 12. Jméno tabulky Cíl Jméno sloupce Zdrojový systém Zdroj Jméno tabulky Jméno sloupce SCD Typ Popis CELL_LOCATION_D CELL_KEY ETL surrogate key CELL_LOCATION_D CELL_BAND CELL DB soubor BAND 1 rádiová frekvence CELL_LOCATION_D CELL_CGI CELL DB soubor CGI 2 CELL_LOCATION_D CELL_DISTRICT CELL DB soubor DISTRICT 2 oblast identifikace buňky (Cell Glogal Identifier) CELL_LOCATION_D CELL_ID CELL DB soubor CELL_ID 0 identifikátor buňky CELL_LOCATION_D CELL_LATITUDE CELL DB soubor LATITUDE 2 zeměpisná šířka CELL_LOCATION_D CELL_LOC_AREA_CODE CELL DB soubor LOC_AREA_CODE 2 Location Area Code (LAC) CELL_LOCATION_D CELL_LONGITUDE CELL DB soubor LONGITUDE 2 zeměpisná délka CELL_LOCATION_D CELL_SITE_NAME CELL DB soubor SITE_NAME 1 jméno stanoviště CELL_LOCATION_D CELL_START_DATE CELL DB soubor START_DATE 1 odkdy je BTS v provozu CELL_LOCATION_D CELL_STOP_DATE CELL DB soubor STOP_DATE 1 dokdy byla BTS v provozu CELL_LOCATION_D EFF_START_TS ETL 0 odkdy je řádek platný CELL_LOCATION_D EFF_END_TS ETL 1 dokdy je řádek platný CELL_LOCATION_D CURRENT_FLG ETL 1 příznak aktuálně platného řádku CELL_LOCATION_D RECORD_CREATED_TS ETL Tabulka 12: Dimenze lokalita Zdroj: autor 1 kdy byl záznam vložen do dimenze Produkt Produktová dimenze je v tomto případě velice jednoduchá, zdrojem je pouze jediná tabulka a všechny atributy mají SCD typ 0 nebo 1 (tabulka 13). Jméno tabulky Cíl Jméno sloupce Zdrojový systém Zdroj Jméno tabulky Jméno sloupce SCD Typ Popis PRODUCT_D PRODUCT_KEY ETL PRODUCT_D ROW_ID Siebel S_PROD_INT ROW_ID 0 unikátní identifikátor PRODUCT_D CREATED Siebel S_PROD_INT CREATED 0 64 Base Transceiver Station kdy byl záznam ve zdrojové tabulce 78

79 Jméno tabulky Cíl Jméno sloupce Zdrojový systém Zdroj Jméno tabulky Jméno sloupce SCD Typ vytvořen Popis PRODUCT_D LAST_UPD Siebel S_PROD_INT LAST_UPD 1 kdy byl záznam ve zdrojové tabulce naposled změněn PRODUCT_D NAME Siebel S_PROD_INT NAME 0 jméno produktu PRODUCT_D CAPACITY Siebel S_PROD_INT CAPACITY 0 kapacity PRODUCT_D CASE_PACK Siebel S_PROD_INT CASE_PACK 0 počet kusů v balení PRODUCT_D EFF_END_DT Siebel S_PROD_INT EFF_END_DT 1 PRODUCT_D EFF_START_DT Siebel S_PROD_INT EFF_START_DT 1 datum ukončení platnosti produktu datum začátku platnosti produktu PRODUCT_D MODEL_YR Siebel S_PROD_INT MODEL_YR 0 modelový rok PRODUCT_D TAXABLE_FLG Siebel S_PROD_INT TAXABLE_FLG 1 je zdanitelný? PRODUCT_D ALIAS_NAME Siebel S_PROD_INT ALIAS_NAME 1 alias PRODUCT_D CATEGORY_CD Siebel S_PROD_INT CATEGORY_CD 0 typ kategorie PRODUCT_D DETAIL_TYPE_CD Siebel S_PROD_INT DETAIL_TYPE_CD 0 typ portfolia PRODUCT_D MODEL Siebel S_PROD_INT MODEL 0 model PRODUCT_D MODEL_CD Siebel S_PROD_INT MODEL_CD 0 kód modelu PRODUCT_D PART_NUM Siebel S_PROD_INT PART_NUM 0 číslo produktu PRODUCT_D PAYMNT_TYPE_CD Siebel S_PROD_INT PAYMNT_TYPE_CD 1 PRODUCT_D PRICE_TYPE_CD Siebel S_PROD_INT PRICE_TYPE_CD 0 typ platby (např. prepaid, pospaid pro telefonní služby) typ ceny (jednorázová, opakovaná ) PRODUCT_D PROD_CD Siebel S_PROD_INT PROD_CD 0 typ produktu PRODUCT_D STATUS_CD Siebel S_PROD_INT STATUS_CD 1 status PRODUCT_D SUB_TYPE Siebel S_PROD_INT SUB_TYPE 1 subtyp produktu PRODUCT_D SUB_TYPE_CD Siebel S_PROD_INT SUB_TYPE_CD 1 kód subtypu PRODUCT_D RECORD_TS ETL kdy byl záznam vložen do dimenze nebo 1 modifikován Tabulka 13: Dimenze produkt Zdroj: autor Subscriber, fakturační účet a zákazník Entity subscriber, fakturační účet a zákazník tvoří přirozenou hierarchii (obrázek 43), takže se nabízí možnost umístit je do jedné dimenze. Proti tomuto řešení hovoří fakt, že ne všechna fakta pracují se stejnou úrovní detailu, například balance účtu je na úrovni fakturačního účtu, využití služeb sítě zase pouze na úrovni subscribera. Možnosti, jak udržet vazby mezi těmito třemi entitami i přes rozdělení dimenze, jsou dvě: první je držet vazbu na úrovni faktových tabulek, druhá přidat pomocnou tabulku, která bude tuto vazbu udržovat. Vazba mezi dimenzemi pouze přes faktovou tabulku je z hlediska dimenzionálního 79

80 modelování čistší přístup a v tomto případě neexistuje objektivní důvod pro druhé řešení, vazba mezi těmito třemi dimenzemi je tedy držena ve faktových tabulkách. Dimenze subscriber a fakturační účet bude vhodné rozšířit o atribut, který bude obsahovat přirozený cizí klíč pro spojení s nadřazenou entitou a chovat se k tomuto atributu jako SCD typu 2. Obrázek 43: Vztah subscriber - fakturační účet zákazník Zdroj: autor Subsriber neexistuje v Siebel CRM jako samostatná datová entita, ale jedná se o asset (instance produktu nebo služby) typu subscriber. Na obrázku 44 je znázorněn životní cyklus subscribera, dokud je subscriber ve stavu Preaktivováno je reprezentován pouze řádkem objednávky v tabulce S_ORDER_ITEM, následně při přechodu do stavu Aktivováno je vytvořen záznam také v tabulce S_ASSET. Kromě informací, které jsou k dispozici v Siebel CRM, je nutné dimenzi rozšířit také o vazební data mezi Siebel CRM a Kenan FX, aby bylo možné dimenzi mapovat na fakta z obou systémů. Pro plnění dimenze tedy potřebujeme tři tabulky ze dvou různých zdrojů. Obrázek 44: Životní cyklus subscribera Zdroj: autor Pro plnění dimenze je nutné tabulky S_ORDER_ITEM a S_ASSET filtrovat podle typu produktu Subscriber, extrakce dat by měla probíhat v pořadí S_ORDER_ITEM, S_ASSET a 80

81 nakonec tabulka EXTERNAL_ID_EQUIP_MAP z Kenan FX. Poslední tabulka obsahuje mapovací údaje mezi systémy Siebel a Kenan FX. Vztah mezi Siebel CRM a Kenan FX, včetně podmínek pro spojení je naznačen na obrázku 45. Obrázek 45: Vztah mezi entitami zákazník, fakturační účet a subscriber v Siebel CRM a Kenan FX Zdroj: autor Tabulka 14 ukazuje strukturu dimenze subscriber včetně mapování atributů na zdrojové tabulky. Jméno tabulky Cíl Jméno sloupce Zdroj. systém Jméno tabulky Zdroj Jméno sloupce SCD Typ Popis SUBSCRIBER_D SUBSCRIBER_KEY ETL 0 surrogate key SUBSCRIBER_D ORDER_LINE_ID CRM S_ORDER_ITEM ROW_ID identifikace řádku 0 objednávky SUBSCRIBER_D ASSET_ID CRM S_ASSET ROW_ID identifikace 0 assetu S_ASSET (Aktivováno) S_ORDER_ITEM (Preaktivováno) S_ASSET.SERIAL_NUM, S_ORDER_LINE.SERVICE_NUM SUBSCRIBER_D MSISDN CRM 0 MSISDN identifikace subscribera z SUBSCRIBER_D SUBSCR_NO Kenan EXTERNAL_ID_EQUIP_MAP SUBSCR_NO 0 Kenan FX identifikace subscribera z SUBSCRIBER_D SUBSCR_NO_RESETS Kenan EXTERNAL_ID_EQUIP_MAP SUBSCR_NO_RESETS 0 Kenan FX 81

82 Jméno tabulky Cíl Jméno sloupce Zdroj. systém Jméno tabulky Zdroj Jméno sloupce SCD Typ Popis SUBSCRIBER_D STATUS_CD SUBSCRIBER_D ACCOUNT_ID SUBSCRIBER_D BILL_PROF_ID SUBSCRIBER_D EFF_START_TS SUBSCRIBER_D EFF_END_TS SUBSCRIBER_D CURRENT_FLG CRM CRM CRM ETL ETL ETL S_ASSET (Aktivováno) S_ORDER_ITEM (Preaktivováno) STATUS_CD 1 S_ASSET (Aktivováno) S_ORDER_ITEM (Preaktivováno) BILL_ACCOUNT_ID 2 S_ASSET (Aktivováno) S_ORDER_ITEM (Preaktivováno) BILL_PROFILE_ID 2 SUBSCRIBER_D RECORD_TS ETL 1 Tabulka 14: Dimenze subscriber Zdroj: autor status subscribera zákazník, ke kterému subscriber patří fakturační účet přiřazený subscriberovi odkdy je řádek platný dokdy je řádek platný příznak aktuálně platného řádku kdy byl záznam vložen do dimenze nebo modifikován V případě dimenzí fakturační účet a zákazník je situace podobná, data se načítají z tabulek S_INV_PROF (fakturační účet), S_ORG_EXT (zákazník), S_ORG_EXT_X (rozšíření tabulky S_ORG_EXT, mapování 1:1) a EXTERNAL_ID_ACCT_MAP (mapovací údaje v Kenan FX). Jméno tabulky Cíl Jméno sloupce Zdroj. systém Jméno tabulky Zdroj Jméno sloupce SCD Typ Popis BILL_PROF_D BILL_PROF_KEY ETL Surrogate key BILL_PROF_D INV_PROF_ID Siebel S_INV_PROF ROW_ID 0 identifikace záznamu v S_INV_PROF BILL_PROF_D NAME Siebel S_INV_PROF NAME 1 jméno fakturačního účtu BILL_PROF_D CREATED Siebel S_INV_PROF CREATED 0 BILL_PROF_D LAST_UPD Siebel S_INV_PROF LAST_UPD 1 kdy byl záznam vytvořen ve zdroji kdy byl záznam modifikován ve zdroji BILL_PROF_D CUSTOMER_ID Siebel S_INV_PROF ACCNT_ID 2 identifikace zákazníka BILL_PROF_D ADDR_ID Siebel S_INV_PROF ADDR_ID 1 identifikace adresy BILL_PROF_D BILL_CYCLE Siebel S_INV_PROF BILL_CYCLE Perioda, ve které se 1 vystavuje faktura BILL_PROF_D BILL_PREF_CD Siebel S_INV_PROF BILL_PREF_CD preferovaný typ 1 vyúčtování BILL_PROF_D CONTACT_ID Siebel S_INV_PROF CON_ID 1 identifikace kontaktu medium pro tisk BILL_PROF_D MEDIA_TYPE_CD Siebel S_INV_PROF MEDIA_TYPE_CD 2 vyúčtování BILL_PROF_D PAYMENT_TYPE_CD Siebel S_INV_PROF PAYMENT_TYPE_CD 2 typ platby (prepaid, postpaid) BILL_PROF_D PAYMENT_METH_CD Siebel S_INV_PROF PAYMENT_METH_CD 2 platební metoda BILL_PROF_D STATUS_CD Siebel S_INV_PROF STATUS_CD 1 status fakturačního účtu BILL_PROF_D X_BA_NUM Siebel S_INV_PROF X_BA_NUM 0 číslo fakturačního účtu 82

83 Jméno tabulky Cíl Jméno sloupce Zdroj. systém Jméno tabulky Zdroj Jméno sloupce SCD Typ Popis BILL_PROF_D LANG_ID Siebel S_INV_PROF LANG_ID 1 preferovaný jazyk BILL_PROF_D ACCOUNT_NO Kenan EXTERNAL_ID_ACCT_MAP ACCOUNT_NO 0 BILL_PROF_D ACCOUNT_NO_RESETS Kenan EXTERNAL_ID_ACCT_MAP ACCOUNT_NO_RESETS 0 identifikace fakturačního účtu v Kenan FX identifikace fakturačního účtu v Kenan FX BILL_PROF_D EFF_START_TS ETL 0 odkdy je řádek platný BILL_PROF_D EFF_END_TS ETL 1 dokdy je řádek platný BILL_PROF_D CURRENT_FLG ETL příznak aktuálně 1 platného řádku BILL_PROF_D RECORD_TS ETL kdy byl záznam vložen do dimenze nebo 1 modifikován CUSTOMER_D CUSTOMER_KEY ETL surrogate key Identifikace řádku CUSTOMER_D CUSTOMER_ID Siebel S_ORG_EXT ROW_ID 0 zákazníka CUSTOMER_D CUST_SINCE_DT Siebel S_ORG_EXT CUST_SINCE_DT 0 odkdy je zákazníkem CUSTOMER_D CUST_END_DT Siebel S_ORG_EXT CUST_END_DT 1 dokdy byl zákazníkem CUSTOMER_D ACCNT_TYPE_CD Siebel S_ORG_EXT ACCNT_TYPE_CD 1 typ účtu CUSTOMER_D CUST_STAT_CD Siebel S_ORG_EXT CUST_STAT_CD 1 status zákazníka CUSTOMER_D MAIN_ _ADDR Siebel S_ORG_EXT MAIN_ _ADDR 1 elektronická pošta CUSTOMER_D MAIN_PH_NUM Siebel S_ORG_EXT MAIN_PH_NUM 1 telefonní číslo CUSTOMER_D MAIN_FAX_PH_NUM Siebel S_ORG_EXT MAIN_FAX_PH_NUM 1 Fax CUSTOMER_D OU_NUM Siebel S_ORG_EXT OU_NUM 0 číslo zákazníka CUSTOMER_D OU_TYPE_CD Siebel S_ORG_EXT OU_TYPE_CD 2 typ zákazníka CUSTOMER_D PAY_TYPE_CD Siebel S_ORG_EXT PAY_TYPE_CD 1 typ platby CUSTOMER_D PRIVACY_CD Siebel S_ORG_EXT PRIVACY_CD 1 nastavení soukromí CUSTOMER_D PR_ADDR_ID Siebel S_ORG_EXT PR_ADDR_ID 2 identifikace adresy CUSTOMER_D PR_CON_ID Siebel S_ORG_EXT PR_CON_ID 2 identifikace kontaktu CUSTOMER_D BIRTH_CODE Siebel S_ORG_EXT_X X_BIRTH_CODE 0 rodné číslo CUSTOMER_D IN Siebel S_ORG_EXT_X X_IN 0 IČO CUSTOMER_D ACCOUNT_NO Kenan EXTERNAL_ID_ACCT_MAP ACCOUNT_NO 0 CUSTOMER_D ACCOUNT_NO_RESETS Kenan EXTERNAL_ID_ACCT_MAP ACCOUNT_NO_RESETS 0 identifikace fakturačního účtu v Kenan FX identifikace fakturačního účtu v Kenan FX CUSTOMER_D EFF_START_TS ETL 0 odkdy je řádek platný CUSTOMER_D EFF_END_TS ETL 1 dokdy je řádek platný CUSTOMER_D CURRENT_FLG ETL příznak aktuálně 1 platného řádku CUSTOMER_D RECORD_TS ETL kdy byl záznam vložen do dimenze nebo 1 modifikován Tabulka 15: Dimenze fakturační účet a zákazník Zdroj: autor 83

84 3.2.9 Zaměstnanec Dimenze zaměstnanec (tabulka 16) je poslední dimenzí tohoto modelu. Základ pro plnění této dimenze tvoří tabulky S_EMP_PER a S_USER, pomocí těchto tabulek dokážeme dimenzi naplnit popisem zákazníka. Pokud chceme dimenzi rozšířit o hierarchii organizační struktury, můžeme využít tabulky S_PARTY_PER a S_PARTY, hierarchie je implementovaná rekurzí v tabulce S_PARTY. Obrázek 46: Vztah mezi zaměstnancem a pozicí v Siebel CRM Zdroj: autor Při implementaci hierarchie do dimenze je vhodné toto provést s využitím pomocné tabulky a přirozených klíčů, pokud je implementována přímo v tabulce dimenze, každá změna na vyšší úrovni organizační struktury způsobí růst počtu řádků dimenze (např. změna na úrovni CEO způsobí růst řádků o 100%). Při použití pomocné tabulky je nutno spojit tuto tabulku s dimenzí pomocí přirozeného klíče, nikoli s využitím klíče dimenze. V případě dimenze SCD typu 2 by bylo velmi těžké udržet korektně vazby mezi tabulkami. Pomocná tabulka bude obsahovat vazbu mezi zaměstnancem a jeho pozicí v organizační struktuře, tabulka pozic bude obsahovat hierarchické vazby z pozice na nadřazenou pozici (vztah dítě - rodič). Pokud dojde ke změně zaměstnance na kterékoli pozici, vytvoří se pouze nová vazba v pomocné tabulce. Řešení je zobrazeno na obrázku 47, je důležité si uvědomit, že hierarchický dotaz je v tomto případě možný pouze s využitím klauzule CONNECT BY, pokud zvolený databázový stroj tuto možnost nepodporuje, je nutné zvolit jiné řešení. 84

85 Obrázek 47: Dimenze zaměstnanec s využitím pomocné tabulky pro implementaci hierarchie Zdroj: autor Níže je ukázka hierarchického SQL dotazu, který sečte fakta pro vybranou pozici a všechny její podřízené. Dotaz také pracuje s historií zákaznické dimenze i pomocných tabulek, takže hierarchie je vždy platná k okamžiku vzniku záznamu ve faktové tabulce. SELECT reported_position_name, fact_ts, SUM(fact_value) FROM (SELECT e.employee_id, e.employee_name, reported_position_name, f.fact_ts, p.position_name, f.fact_value FROM fact_table f INNER JOIN employee_d e ON (f.employee_key = e.employee_key AND f.fact_ts BETWEEN e.eff_start_ts AND NVL (e.eff_end_ts, SYSDATE)) INNER JOIN position_employee_bridge b ON (b.employee_id = e.employee_id AND f.fact_ts BETWEEN b.eff_start_ts AND NVL (b.eff_end_ts, SYSDATE)) INNER JOIN ( SELECT CONNECT_BY_ROOT position_name AS reported_position_name, position_name, position_id, eff_start_ts, eff_end_ts FROM position START WITH position_name = 'Senior Manager 1' CONNECT BY PRIOR position_id = parent_position_id ) p ON (b.position_id = p.position_id AND f.fact_ts BETWEEN p.eff_start_ts AND NVL (b.eff_end_ts, SYSDATE))) GROUP BY reported_position_name, fact_ts ORDER BY fact_ts; 85

86 Jméno tabulky Cíl Jméno sloupce Zdrojový systém Zdroj Jméno tabulky Jméno sloupce SCD Typ Popis EMPLOYEE_D EMPLOYEE_KEY ETL 0 surrogate key EMPLOYEE_D EMPLOYEE_ID Siebel S_EMP_PER ROW_ID 0 EMPLOYEE_D EMPLOYEE_NAME Siebel S_EMP_PER NAME 1 jméno EMPLOYEE_D LOGIN Siebel S_USER LOGIN 1 login identifikace zaměstnance v S_EMP_PER EMPLOYEE_D HIRE_DT Siebel S_EMP_PER HIRE_DT 0 datum nástupu EMPLOYEE_D TERMINATION_DT Siebel S_EMP_PER TERMINATION_DT 1 datum odchodu EMPLOYEE_D MAIN_PH_NUM Siebel S_EMP_PER MAIN_PH_NUM 1 telefonní číslo EMPLOYEE_D MAIN_MAIL_ADDR Siebel S_EMP_PER MAIN_MAIL_ADDR 1 elektronická pošta EMPLOYEE_D EFF_START_TS ETL 0 platnost záznamu od EMPLOYEE_D EFF_END_TS ETL 1 platnost záznamu do EMPLOYEE_D CURRENT_FLG ETL 1 příznak aktuálního záznamu EMPLOYEE_D RECORD_TS ETL 0 vznik záznamu POSITION_EMPLOYEE_BRIDGE POSITION_ID Siebel S_PART_PER PARTY_ID 2 identifikace pozice POSITION_EMPLOYEE_BRIDGE EMPLOYEE_ID Siebel S_PARTY_PER PERSON_ID 2 identifikace zaměstnance POSITION_EMPLOYEE_BRIDGE EFF_START_TS ETL 0 platnost záznamu od POSITION_EMPLOYEE_BRIDGE EFF_END_TS ETL 1 platnost záznamu do POSITION_EMPLOYEE_BRIDGE CURRENT_FLG ETL 1 příznak aktuálního záznamu POSITION POSITION_ID Siebel S_PARTY ROW_ID 0 identifikace pozice POSITION NAME Siebel S_PARTY NAME 2 jméno pozice POSITION PAR_PARTY_ID Siebel S_PARTY PAR_PARTY_ID 2 nadřazená pozice POSITION EFF_START_TS ETL 0 platnost záznamu od POSITION EFF_END_TS ETL 1 platnost záznamu do POSITION CURRENT_FLG ETL 1 Tabulka 16: Dimenze zaměstnanec Zdroj: autor příznak aktuálního záznamu Sběrnice datového skladu Výsledky předchozích kapitol lze shrnout do matice sběrnice datového skladu. Tato matice zobrazuje průnik podnikových procesů a dimenzí a přehledně nám tak předkládá celkový obraz integrovaného datového skladu (tabulka 17). 86

87 Datum Čas Audit Produkt Zákazník Fakturační účet Subscriber Zaměstnanec Fakturační cyklus Lokalita Adresa Kontakt Využití služeb sítě X X X X X X X Fakturace X X X X X X Balance účtu X X X X Správa objednávek X X X X X X X X X X Servisní požadavky X X X X X X X X X X Tabulka 17: Sběrnice datového skladu Zdroj: autor 3.3 Identifikace faktů V případě procesu Využití služeb sítě existuje jediný fakt, který lze z CDR souboru získat, a to délka hovoru. Ostatní atributy, které obsahuje CDR soubor (viz kapitola 3.1.1), pouze popisují danou událost, většinu z nich se nevyplatí vyvést do samostatné dimenze, jedná se o různé statusy, kategorie apod. Délka hovoru je aditivní fakt, který ukazuje míru čerpání služby. Dalším důležitým údajem, který lze z tohoto datového tržiště získat, je informace, že došlo k čerpání služby, ke spojení účastníků, tato informace je dána již pouhou existencí záznamu ve faktové tabulce. Ne všechny dimenze v tomto tržišti mají stejnou granularitu jako tabulka faktů (např. dimenze zákazník), ale protože zde nejsou jiná fakta než aditivní, nepůsobí to při tvorbě reportů žádné potíže. Proces Fakturace obsahuje větší množství faktů, ve všech případech se jedná o finanční údaje. Jsou to fakturovaná částka, částka daně, výše slevy a procentuální výše daně. První tři fakta jsou aditivní, poslední je semiaditivní. Při vytváření reportu je nutné si uvědomit, že dimenze zákazník má jinou granularitu než tabulka faktů a počítat s tím při práci s jinými fakty, než aditivními (procentuální výše daně). Balance účtu obsahuje pět faktů: zůstatek na účtu, celkem účtovaná částka (za všechny faktury, neustále se navyšuje), celkem zaplacená částka (také se jedná o agregovanou částku, za celou existenci účtu), celková výše dobropisů (stejný případ jako předešlá fakta) a 87

88 balance účtu platná ke vzniku snímku. Pouze balance účtu je aditivní fakt, ostatní fakta nelze sčítat. Neaditivní fakta v tomto případě lze na aditivní transformovat odečtením hodnot dvou po sobě jdoucích snímků a tím získat přírůstek. Použít lze analytickou funkci LAG, viz následující příklad: SELECT D.DATE_VAL AS SNAPSHOT_DATE, P.NAME AS BILL_ACCOUNT_NAME, NVL(LAG (TOTAL_CHARGES,1) OVER (PARTITION BY P.NAME ORDER BY D.DATE_VAL),0 ) AS TOTAL_PREV_CHARGES, TOTAL_CHARGES, TOTAL_CHARGES NVL(LAG (TOTAL_CHARGES,1) OVER (PARTITION BY P.NAME ORDER BY D.DATE_VAL),0 ) AS CHARGES_DELTA FROM ACCOUNT_BALANCE_F F INNER JOIN DATE_D D ON (D.DATE_KEY = F.SNAPSHOT_DATE_KEY) INNER JOIN BILL_PROF_D P ON (P.BILL_PROF_KEY = F.BILL_PROF_KEY) ORDER BY 1,2; V procesu Správa objednávek je možné identifikovat dvě skupiny faktů, jednak to jsou fakta, která mají vztah k ceně, a jednak fakta obsahující informaci o době zpracování objednávky. Přehledně jsou fakta, včetně mapování zdroj-cíl, uvedena v tabulce 18. Jméno tabulky Cíl Jméno sloupce Zdrojový systém Zdroj Jméno tabulky Jméno sloupce ORDER_MANAGEMENT_F ORDER_DT Siebel S_ORDER ORDER_DT ORDER_MANAGEMENT_F APPROVED_DT Siebel S_ORDER APPROVED_DT ORDER_MANAGEMENT_F STATUS_DT Siebel S_ORDER STATUS_DT ORDER_MANAGEMENT_F LAST_UPD Siebel S_ORDER LAST_UPD Popis datum vzniku objednávky datum schválení objednávky datum a čas dokončení objednávky datum změny objednávky ORDER_MANAGEMENT_F QTY_REQ Siebel S_ORDER_ITEM QTY_REQ množství Y ORDER_MANAGEMENT_F UNIT_PRI Siebel S_ORDER_ITEM UNIT_PRI cena po slevě Y ORDER_MANAGEMENT_F BASE_UNIT_PRI Siebel S_ORDER_ITEM BASE_UNIT_PRI ceníková cena Y ORDER_MANAGEMENT_F UNIT_TAX_AMT Siebel S_ORDER_ITEM UNIT_TAX_AMT daň Y ORDER_MANAGEMENT_F NET_PRI Siebel S_ORDER_ITEM NET_PRI cena po zdanění, včetně dopravy, slevy a dobropisu Y ORDER_MANAGEMENT_F UNIT_PRI_RC Siebel S_ORDER_ITEM UNIT_PRI_RC cena po slevě, opakovaná platba Y ORDER_MANAGEMENT_F ADJ_UNIT_PRI Siebel S_ORDER_ITEM ADJ_UNIT_PRI cena po dobropisu Y ORDER_MANAGEMENT_F FRGHT_AMT Siebel S_ORDER_ITEM FRGHT_AMT cena dopravy Y ORDER_MANAGEMENT_F PRI_ADJ_AMT Siebel S_ORDER_ITEM PRI_ADJ_AMT dobropis Y ORDER_MANAGEMENT_F DISCNT_AMT Siebel S_ORDER_ITEM DISCNT_AMT sleva Y ORDER_MANAGEMENT_F DISCNT_PERCENT Siebel S_ORDER_ITEM DISCNT_PERCENT sleva v procentech N sleva na ORDER_MANAGEMENT_F DISC_AMT_RC Siebel S_ORDER_ITEM DISC_AMT_RC opakovanou platbu Y Aditivní fakt N N N N 88

89 Jméno tabulky Cíl Jméno sloupce Zdrojový systém Zdroj Jméno tabulky Jméno sloupce ORDER_MANAGEMENT_F DISC_PERCT_RC Siebel S_ORDER_ITEM DISC_PERCT_RC ORDER_MANAGEMENT_F CREATED Siebel S_ORDER_ITEM CREATED ORDER_MANAGEMENT_F STATUS_DT Siebel S_ORDER_ITEM STATUS_DT ORDER_MANAGEMENT_F ORDER_MANAGEMENT_F ORDER_MANAGEMENT_F Tabulka 18: Fakta - Správa objednávek Zdroj: autor FROM_CREATED_T O_FINAL Siebel S_ORDER FROM_CREATED_T O_APPROVED Siebel S_ORDER FROM_CREATED_T O_FINAL_LN Siebel S_ORDER_ITEM (S_ORDER.STATUS_ DT - S_ORDER.ORDER_D T)*3600*24 (S_ORDER.APPROVE D_DT - S_ORDER.ORDER_D T)*3600*24 (S_ORDER_ITEM.ST ATUS_DT - S_ORDER_ITEM.CRE ATED)*3600*24 Popis sleva na opakovanou platbu v procentech datum a čas vytvoření řádku objednávky datum a čas dokončení řádky objednávky čas od založení do konce objednávky ve vteřinách čas od založení do schválení objednávky ve vteřinách čas od založení do konce řádky objednávky ve vteřinách Aditivní fakt N N N Y Y Y Posledním z modelovaných procesů je proces Servisní požadavky. V tomto procesu lze identifikovat pouze fakta typu časový interval mezi dvěma stavy servisního požadavku. Mapování vybraných atributů a faktů na zdrojový systém je zobrazeno v tabulce 19. Jméno tabulky Cíl Jméno sloupce Zdrojový systém Jméno tabulky Zdroj Jméno sloupce SRV_REQ_F ACT_OPEN_DT Siebel S_SRV_REQ ACT_OPEN_DT SRV_REQ_F SR_STAT_DT Siebel S_SRV_REQ SR_STAT_DT SRV_REQ_F ASGN_DT Siebel S_SRV_REQ ASGN_DT SRV_REQ_F ACTL_RESOLVED_TS Siebel S_SRV_REQ ACTL_RESOLVED_TS SRV_REQ_F REOPENED_TS Siebel S_SRV_REQ REOPENED_TS SRV_REQ_F ACT_CLOSE_DT Siebel S_SRV_REQ ACT_CLOSE_DT SRV_REQ_F EXP_CLOSE_DT Siebel S_SRV_REQ EXP_CLOSE_DT SRV_REQ_F OPEN_TO_SENT Siebel S_SRV_REQ SRV_REQ_F OPEN_TO_SOLVING Siebel S_SRV_REQ SRV_REQ_F OPEN_TO_SOLVED Siebel S_SRV_REQ SRV_REQ_F OPEN_TO_REOPEN Siebel S_SRV_REQ SRV_REQ_F OPEN_TO_CLOSE Siebel S_SRV_REQ (SR_STAT_DT - ACT_OPEN_DT)*24*3600 (ASGN_DT - ACT_OPEN_DT)*24*3600 (ACTL_RESOLVED_TS - ACT_OPEN_DT)*24*3600 (REOPENED_TS - ACT_OPEN_DT)*24*3600 (ACT_CLOSE_DT - ACT_OPEN_DT)*24*3600 Popis datum a čas vytvoření SP datum a čas odeslání SP datum a čas kdy se SP začal řešit datum a čas kdy byl SP vyřešen datum a čas znovuotevření SP datum a čas ukončení SP (úspěšné i neúspěšné) dohodnutý termín splnění od založení do odeslání ve vteřinách od založení do začátku řešení ve vteřinách od založení do vyřešení ve vteřinách od otevření do znovuotevření ve vteřinách od otevření do uzavření ve Aditivní fakt N N n n n n n y y y y y 89

90 Jméno tabulky Cíl Jméno sloupce Zdrojový systém Jméno tabulky Zdroj Jméno sloupce vteřinách Popis Aditivní fakt SRV_REQ_F OPEN_TO_EXP_CLOSE Siebel S_SRV_REQ (EXP_CLOSE_DT - ACT_OPEN_DT)*24*3600 od otevření do slíbeného uzavření ve vteřinách y Tabulka 19: Fakta - Servisní požadavky Zdroj: autor 90

91 4 Návrh procesů na plnění datového skladu ze zdrojových systémů Plnění datového skladu zajišťuje ETL systém respektive ETL procesy. Ralph Kimball uvádí čtyři základní fáze, kterými data procházejí ve většině datových skladů 65 : extrakce, čištění, přizpůsobení a doručení dat. Každá z těchto fází obvykle znamená dočasnou nebo permanentní kopii dat. Extrakce dat je prvním krokem ETL systému, cílem je dostat požadovaná data ze zdrojového systému do dočasného úložiště (DSA), kde s nimi lze dále pracovat. Během této fáze se provádí pouze minimum transformací dat (typickou transformací prováděnou během této fáze je např. konverze znakové sady), cílem je udržet tento krok co nejjednodušší a s co nejmenším dopadem na zdrojový systém. Zdrojem dat může být např. relační databáze, textový soubor (flat file) nebo XML. Čistění a přizpůsobení spolu tvoří transformační část ETL systému a tyto dva kroky jsou důležitou součástí pro zajištění datové kvality datového skladu. Čistění dat může zahrnovat mnoho různých kroků jako je odstranění duplicit, kontroly platnosti hodnoty (např. kontrola rodného čísla s využitím modulo 11), zajištění konzistence hodnot v celém záznamu (např. odpovídá rodné číslo datu narození?), kontrola business pravidel (např. zákazník daného typu musí mít určité vlastnosti apod.), kontrola prázdných (null) hodnot. Zjištěné chyby by měly být reportovány, aby bylo případně možné provést úpravy zdrojových systémů, pokud se jedná o chybu v procesu. Informace z tohoto kroku jsou také důležité pro uživatele BI řešení, kteří je mohou vzít v úvahu při práci s reporty z datového skladu (auditní dimenze). Přizpůsobení dat je nutné, pokud dochází ke spojení dat z různých zdrojů. Data mohou být v různých zdrojích různě pojmenována, mohou mít trochu jiný význam, je tedy třeba věnovat zvýšené úsilí tomu, aby dohromady dávala smysl. Tento krok obvykle vyžaduje vytvoření celopodnikových standardizovaných domén a sjednocení sledovaných metrik. Posledním krokem je samotné naplnění dimenzionální struktury připravenými daty a zpřístupnění těchto dat v prezentační vrstvě datového skladu. 65 KIMBALL, Ralph, Joe Caserta. The data warehouse ETL toolkit practical techniques for extracting, cleaning, conforming, and delivering data. Indianopolis: John Wiley, 2004, 491 p. ISBN s

92 4.1 Datová kvalita Kvalita dat v datovém skladu se v praxi neodvíjí pouze od zdrojových systémů a procesu plnění datového skladu, ale také od procesu správy datového skladu a řízení změn v datovém skladu. Zjednodušené schéma správy datového skladu ukazuje obrázek 48. Obrázek 48: Zjednodušené schéma správy datového skladu Zdroj: MINIBERGER, Bohumil. Kvalita dat datových skladů nezbytný předpoklad předcházení rizik manažerského rozhodování. In: Sborník z 11. ročníku mezinárodní konference Současnost a budoucnost krizového řízení. Praha: T-SOFT, a.s. Praha, 2009, s ISBN s

93 Ralph Kimball ve svém článku An Architecture for Data Quality 67 upozorňuje na fakt, že pokusy o technické řešení datové kvality nevedou k úspěchu, pokud nejsou součástí celkové kultury kvality v organizaci a pokud tato kultura není podporována vrcholovým vedením organizace. Kimball ve svém článku také uvádí devět základních kroků, kterými by se měla řídit organizace věnující se datové kvalitě: 1. Vyhlásit obecný závazek ke kultuře datové kvality. 2. Podporovat a prosazovat reengineering procesů na úrovni vrcholového vedení. 3. Investovat do zlepšování prostředí pro vstup dat. 4. Investovat do zlepšování integrace aplikací. 5. Investovat do změn ve fungování procesů. 6. Podporovat povědomí týmů o end-to-end fungování procesů. 7. Podporovat spolupráci mezi odděleními. 8. Veřejně chválit dokonalost v datové kvalitě. 9. Nepřetržitě měřit a vylepšovat datovou kvalitu (jedná se o kontinuální proces). Aby bylo možné jasně určit, která data jsou správná, je nutné pro data v datovém skladu stanovit definice a pravidla, která umožní definovat datovou kvalitu. Klíčovou roli v tomto procesu hraje datový stevard, jeho zodpovědností je, v rámci organizace, utvářet dohodu o definicích, business pravidlech a přípustných hodnotách pro data v datovém skladu a následně tato pravidla publikovat a prosazovat. Pokud jsou v organizaci splněny předpoklady pro řízení datové kvality, nastupuje technická část řešení. Prvním krokem je profilování dat, jedná se o analýzu dat zdrojových systémů. Loshin 68 uvádí, že se jedná o hierarchický proces, který se pokouší vytvořit metadata popisující sadu dat. Nejnižší úroveň popisuje hodnoty spojené s jednotlivými atributy, vyšší úroveň sleduje vztahy mezi sloupci tabulky a nejvyšší popisuje vztahy mezi tabulkami. 67 An Architecture for Data Quality. KIMBALL, Ralph. The Kimball Group [online] [cit ]. Dostupné z: 68 LOSHIN, David. Business Intelligence: The Savvy Manager's Guide. San Francisco: Morgan Kaufmann Publishers, ISBN s

94 Pro profilování dat existuje celá řada nástrojů, namátkou lze uvést např. Ataccama DQ Analyzer 69, Talend Open Studio for Data Quality 70 nebo TS Discovery firmy Trilium 71. Jako nástroj pro základní profilování dat lze také použít přímo SQL dotazy, viz následující příklady (všechny příklady jsou určeny pro RDBMS Oracle): /************************************************************************/ /* minimální, maximální a průměrná délka jména produktu a celkový počet */ /* produktů */ /************************************************************************/ select min(length(name)), max(length(name)), avg(length(name)), count(*) from siebel.s_prod_int; /************************************************************************/ /* počet produktů, které obsahují primární kontakt a kde chybí */ /************************************************************************/ select decode(pr_con_id,null,0,1), count(*) from siebel.s_prod_inv group by decode(pr_con_id,null,0,1); /************************************************************************/ /* nalezení patternů pro zápis čísla ve znakovém sloupci */ /* a jejich četnost */ /* podobný postup lze použít pro datum apod. */ /************************************************************************/ SELECT regexp_replace( FROM arbor.cmf regexp_replace(cust_phone1,'[[:digit:]]', 9),'[[:alpha:]]', 'X') AS PATTERN, COUNT(*) AS POCET_ZAZNAMU GROUP BY regexp_replace( ORDER BY 2 DESC; regexp_replace(cust_phone1,'[[:digit:]]', 9),'[[:alpha:]]', 'X') Dalším krokem při implementaci čištění dat je definice kontrol, které se provádějí jako součást ETL procesu. Na úrovni hodnoty atributu či sloupce lze definovat některé základní kontroly, např.: NULL hodnota pro vyžadovaný sloupec, číselná hodnota mimo požadovaný rozsah, hodnota mimo požadovaný seznam hodnot,

95 nedodržený vyžadovaný formát hodnoty, obsah sloupce je příliš dlouhý nebo krátký, apod. Na základě výsledku kontrol se ETL proces musí rozhodnout, jak s chybou naložit. Může záznam zpracovat bez chyby, může záznam označit a pustit dál ve zpracování, může záznam odmítnout nebo může zcela zastavit ETL proces. Preferované řešení je označit záznam s chybou a dále ho zpracovat, naopak k zastavení ETL procesu by mělo dojít pouze výjimečně. 4.2 Plnění datového skladu Prvním krokem při plnění datového skladu je extrakce dat ze zdroje. V tomto konkrétním případě existují dva typy zdrojů, tabulky v relační databázi a textové soubory. Přehled zdrojů včetně identifikace změn a operace při vkládání do datového skladu je v tabulce 20. Tabulka Typ zdroje Typ cíle Operace identifikace změn na zdroji S_PROD_INT tabulka dimenze insert/update nového/aktualizovaného řádku timestamp změny S_EMP_PER tabulka dimenze insert/update nového/aktualizovaného řádku timestamp změny S_PARTY_PER tabulka dimenze insert/update nového/aktualizovaného řádku timestamp změny S_LOGIN tabulka dimenze insert/update nového/aktualizovaného řádku timestamp změny S_ORDER tabulka fakt insert nových záznamů timestamp změny S_ORDER_ITEM tabulka fakt insert nových záznamů timestamp změny S_SRV_REQ tabulka fakt insert/update nového/aktualizovaného řádku timestamp změny S_ORG_EXT tabulka dimenze insert/update nového/aktualizovaného řádku timestamp změny S_CONTACT tabulka dimenze insert/update nového/aktualizovaného řádku timestamp změny S_ADDR_PER tabulka dimenze insert/update nového/aktualizovaného řádku timestamp změny BILL_CYCLE tabulka dimenze insert/update nového/aktualizovaného řádku timestamp změny S_INV_PROF tabulka dimenze insert/update nového/aktualizovaného řádku timestamp změny CMF tabulka dimenze insert/update nového/aktualizovaného řádku timestamp změny EXTERNAL_ID_EQUIP_MAP tabulka EXTERNAL_ID_ACCT_MAP tabulka dimenze insert/update nového/aktualizovaného řádku timestamp změny dimenze insert/update nového/aktualizovaného řádku timestamp změny CMF_BALANCE tabulka fakt insert snímku tabulky N/A BILL_INVOICE_DETAIL tabulka fakt insert nových záznamů timestamp změny 95

96 Tabulka Typ zdroje Typ cíle Operace identifikace změn na zdroji CDR soubory flat file fakt insert nových záznamů zpracuje se celý soubor Cell lokace flat file dimenze insert/update nového/aktualizovaného řádku zpracuje se celý soubor Tabulka 20: ETL zdroje dat a způsob jejich zpracování Zdroj: autor Extrakce probíhá v případě všech tabulek z ODS, kam jsou data replikována s využitím Oracle GoldenGate 72, toto zároveň umožňuje rozšířit záznam o časové razítko potvrzení transakce, která daný řádek změnila, a tak snadno identifikovat řádky, které je nutné přenést do datového skladu (více k Oracle GoldenGate v kapitole 5.1). Dalším krokem po extrakci je čištění dat (schéma procesu je uvedeno na obrázku 49) a přizpůsobení dat z více zdrojů. Kromě čištění a kontrol dat na úrovni hodnot sloupců je nutné také ověřit integritu dat především v případě vazby mezi fakty a dimenzemi, ale také v případě, že dochází ke spojení dat z více zdrojů. Obrázek 49: ETL proces - BPMN diagram kontrol datové kvality Zdroj: autor Návrh procesu pro plnění dimenzí s atributy SCD typu 1 je na obrázku 50. Jedná se o jednoduchou dimenzi, která je plněna pouze z jednoho zdroje a obsahuje pouze atributy SCD typu 0 a 1. V případě SCD typu 0 se ke změně hodnoty přistupuje pasivně, změna hodnoty není přenesena do datového skladu, v návrhu ETL procesu na obrázku 50 pouze dochází k zapsání pokusu o změnu atributu do error logu, protože změna hodnoty tohoto atributu

97 může znamenat chybu v business procesu. Aktualizace hodnot atributů SCD typu 1 pro již existující záznamy se do datového skladu přenášejí jako prostý update existujícího řádku. ETL nástroje často umožnují plnění dimenzí SCD typu 1 pomocí implementace operace upsert, v databázi Oracle lze použít příkaz merge. Obrázek 50: ETL proces - BPMN diagram plnění dimenze s atributy SCD typu 0 a 1 Zdroj: autor Pokud dimenze obsahuje také atributy SCD typu 2, je situace o něco složitější. Existující hodnotu atributu nelze přepsat, ale je nutné ukončit platnost existujícího řádku a vytvořit řádek nový, jehož platnost začíná jeho vytvořením (dochází k historizaci záznamů v dimenzi). Na obrázku 51 je znázorněn BPMN diagram procesu pro plnění dimenze Subscriber, která obsahuje atributy SCD typu 2. Prvním krokem je spojení všech zdrojových tabulek, následuje spuštění kontrol datové kvality, prověření integrity s dimenzemi Fakturační účet a Zákazník, pokud tyto dimenze neobsahují příslušný záznam je zapsáno varování a zpracování pokračuje dál. Posledním krokem je zápis do dimenze, zpracování se liší podle SCD typu parametru. 97

98 Obrázek 51: ETL proces - BPMN diagram plnění dimenze s atributy SCD typu 0, 1 a 2 Zdroj: autor Při plnění dimenze Subscriber dochází ke spojení dat z více zdrojů, tato část procesu je zachycena na obrázku 52. První krokem je načtení řádků objednávek, kde typ produktu odpovídá subscriberu, následuje spojení s tabulkou assetů (musí se jednat o outer join, subscriber ve stavu Preaktivováno je reprezentován pouze objednávkou, zároveň v případě hromadné migrace aktivních subscriberů z jiného systému nemusí k subscriberu existovat objednávka). Posledním krokem je spojení s tabulkou EXTERNAL_ID_EQUIP_MAP, která obsahuje informace pro mapování mezi subscriberem v CRM systému a billingovém systému. 98

99 Obrázek 52: ETL proces - BPMN diagram spojení více zdrojů při plnění dimenze Zdroj: autor Při plnění faktů je nutné věnovat pozornost také mapování faktů na řádky dimenzí. Pro případ, že není možné pro řádek ve faktové tabulce dohledat záznam v dimenzi (ať už z důvodu chybějící hodnoty na straně faktů nebo nekonzistence mezi fakty a dimenzí), měl by v každé dimenzi existovat řádek, který se použije v tomto případě. Tento případ je nutné zaznamenat do auditní dimenze a následně také provést analýzu, protože to ukazuje na možný problém ve zdrojových systémech. Schéma procesu pro plnění faktů je na obrázku

100 Obrázek 53: ETL proces - BPMN diagram plnění faktů Zdroj: autor 4.3 Řízení ETL procesů Při řízení ETL procesů je nutné si uvědomit závislosti mezi daty a jednotlivými ETL procesy a správně naplánovat spouštění jednotlivých procesů. Obecně platí, že před startem plnění faktů je nutné naplnit všechny potřebné dimenze, pokud však existují také závislosti mezi některými dimenzemi, je nutné zohlednit i to. Při startu denního zpracování dochází k paralelnímu startu plnění dimenzí Cell lokalita, Produkt, Adresa, Kontakt, Zaměstnanec a Zákazník. Po dokončení procesu pro plnění dimenze Zaměstnanec, lze spustit plnění dimenze Fakturační účet a po jeho dokončení startuje plnění dimenze Subscriber. Souběžně se startem plnění dimenzí se provede kontrola, zdali dimenze Datum obsahuje požadované záznamy, pokud ne, provede se jejich generování. Po dokončení všech procesů na plnění dimenzí je možné paralelně spustit plnění faktů. BPMN diagram denního zpracování je znázorněn na obrázku

101 Obrázek 54: ETL proces - BPMN diagram řízení denního zpracování Zdroj: autor 5 Implementace datového skladu Návrh implementace nebo nasazení datového skladu lze rozdělit do tří oblastí. Pro každou oblast projdeme návrh hardwaru a softwaru, který využijeme pro nasazení tohoto řešení (diagram nasazení obr. 55). Oblasti jsou: ODS, ETL, datový sklad. 5.1 ODS ODS je v řešení zařazen, aby bylo možné přenést zátěž při extrakci dat mimo zdrojové systémy. Replikace dat ze zdrojového systému (Oracle databáze) je řešena s využitím 101

102 produktu Oracle GoldenGate, který umožňuje replikaci změn v reálném čase a s minimálním dopadem na zdrojový systém. Oracle GoldenGate sestává ze tří hlavních komponent: extract, data pump a replicat. Extract má za úkol extrahovat změny prováděné ve zdrojové databázi, tyto změny může přímo posílat procesu replicat, nebo je může ve formě trail souborů ukládat na disk. Uložené trail soubory odebírá proces data pump a předává je k aplikaci procesu replicat. Pro toto řešení je vhodnější zvolit implementaci s procesem data pump, protože v případu výpadku síťové komunikace nedojde k přerušení replikace, trail soubory se budou hromadit na straně procesu extract a budou zpracovány, až dojde k obnovení síťové komunikace. Obrázek 55: Oracle GoldenGate diagram nasazení Zdroj: autor GoldenGate pro extrakci dat z databáze Oracle využívá transakční logy, aby bylo možné potřebné informace získat, je nutné aktivovat minimal supplemental logging na úrovni celé databáze a vynutit zápis všech operací do transakčních logů. SQL> ALTER DATABASE ADD SUPPLEMENTAL LOG DATA; SQL> ALTER DATABASE FORCE LOGGING; /* ověření, že je vše nastaveno */ SQL> SELECT supplemental_log_data_min, force_logging FROM v$database; Dalším nutným krokem je zapnout rozšířené logování také na úrovni replikovaných tabulek, toto se provede příkazem ADD TRANDATA ADD TRANDATA v nástroji GGSCI 73. GGSCI (myhost1)> ADD TRANDATA siebel.s_org_ext 73 GGSCI je součást instalace Oracle GoldenGate. Jedná se o řádkovou utilitu k ovládání Oracle GoldenGate. 102

103 Pokud jsou splněny všechny náležitosti, lze pokračovat v konfiguraci procesů extract a data pump. GGSCI (myhost1) 2> edit param extsbl Extract extsbl SETENV (ORACLE_SID='SIEBELDB') UserIdAlias ogg_user TranlogOptions IntegratedParams (max_sga_size 256) Exttrail./dirdat/in LOGALLSUPCOLS UPDATERECORDFORMAT COMPACT Table SIEBEL.S_ORG_EXT; GGSCI (myhost1) 3> dblogin useridalias ogg_user GGSCI (myhost1) 4> register extract extsbl database GGSCI (myhost1) 5> add extract extsbl, integrated tranlog, begin now GGSCI (myhost1) 6> add exttrail./dirdat/in, extract extsbl, megabytes 10 GGSCI (myhost1) 7> Edit Param pumpsbl Extract pumpsbl SETENV (ORACLE_SID='SIEBELDB') UserIdAlias ogg_user rmthost localhost, mgrport 7909 rmttrail./dirdat/pn Table SIEBEL.S_ORG_EXT; GGSCI (myhost1) 8> add extract pumpsbl, exttrailsource./dirdat/in GGSCI (myhost1) 9> add rmttrail./dirdat/pn, extract pumpsbl, megabytes 10 Na straně ODS databáze se provede konfigurace procesu replicat, pro potřebu identifikace změn je tabulka rozšířena o sloupec src_trn_timestamp, kterému je přiřazeno časové razítko potvrzení transakce. GGSCI (myhost2) 1>Edit Param repods Replicat repods SETENV(ORACLE_SID='ODSDB') DBOPTIONS INTEGRATEDPARAMS(parallelism 2) AssumeTargetDefs DiscardFile./dirrpt/rpdw.dsc, Purge UserIdAlias ogg_user Map SIEBEL.S_ORG_EXT, target ODSUSER.S_ORG_EXT, Colmap (USEDEFAULTS, src_trn_timestamp ('GGHEADER', 'COMMITTIMESTAMP')); GGSCI (myhost2) 2> DBlogin UserIdAlias ogg_user 103

104 GGSCI (myhost2) 3> Add Replicat repods Integrated exttrail./dirdat/pn GGSCI (myhost2) 4> Start Replicat repods Je nutné si uvědomit, že konfigurace Oracle GoldenGate je v předchozím textu pouze pro ilustraci naznačena, nejedná se o kompletní postup. 5.2 ETL systém Pro implementaci ETL systému jsme zvolili Oracle Data Integrator (ODI), jedná se o ELT systém dodávaný firmou Oracle. Implementaci tvoří čtyři základní komponenty, jsou to: ODI Studio, ODI Console, ODI Run-Time Agent a ODI Repository. Ukázka nasazení je schematicky znázorněna na obrázku 56. Obrázek 56: ODI diagram nasazení Zdroj: autor ODI Repository je centrem architektury ODI, uchovává konfigurační informace o IT infrastruktuře, metadata aplikací, projektů, scénářů a logy exekucí. ODI Repository je tvořeno jedním Master repozitářem a několika pracovními repozitáři. ODI Studio je nástroj pro administrátory a vývojáře. Lze ho používat pro správu infrastruktury, reverzní inženýring metadat, vývoj projektů, rozvrh činností a provoz a sledování exekuce. Obsahuje čtyři navigátory : Designer Navigator, Operator Navigator, Topology Navigator a Security Navigator. Designer Navigator slouží k návrhu integritních kontrol, vytváření transformací apod. Umožňuje vizualizaci datových toků, automatické generování dokumentace, úpravy generovaného kódu, grafický návrh transformací a další. Operator Navigator slouží pro správu a sledování provozu v produkčním prostředí. Topology 104

105 Navigator umožňuje správu dat, která popisují fyzickou a logickou architekturu. Security Navigator je nástroj pro bezpečnostní správu ODI. Lze v něm vytvářet, modifikovat a rušit uživatele, role a profily a přiřazovat uživatelská oprávnění na objekty. ODI Run-Time Agent je zodpovědný za běh vytvořených scénářů. Agent získá kód scénáře z ODI Repository, připojí se k datovým serverům a koordinuje exekuci na těchto serverech. ODI Console zprostředkovává web interface k prohlížení repozitářů, konfiguraci topologie a k provozní správě. Tato aplikace může být nasazena na WebLogic serveru. 5.3 Datový sklad Na obrázku 57 je návrh nasazení celého řešení, včetně základní HW konfigurace. Pro nasazení samotného datového skladu je zvolen server Oracle Exadata Database Machine X5-2 v osminové konfiguraci. Tato konfigurace bude dostatečná pro počáteční fázi datového skladu a zároveň je dostatečně škálovatelná pro pozdější rozšíření. Serverový rack v osminové konfiguraci obsahuje dva databázové servery, každý se 36 procesorovými jádry a maximálně 768 GB RAM. Dále obsahuje tři storage servery, celkem s 24 procesorovými jádry, 6 karet s flash pamětí o celkové kapacitě 9,6 GB a 18 disků o kapacitě 4 TB každý. Maximální SQL propustnost flash cache je 15 GB/s, propustnost pevných disků je 2 GB/s. Exadata X5-2 lze rozšířit na maximální konfiguraci osmi databázových serverů (288 CPU jader) s 6 TB RAM a 14 storage serverů (224 CPU jader) s 89,6 TB flash paměti a 168 pevných disků o kapacitě 4 TB. V maximální konfiguraci je propustnost flash paměti 140 GB/s a pevných disků 20 GB/s. 105

106 Obrázek 57: Diagram nasazení datového skladu Zdroj: autor 106