Vytvoření datového skladu

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:

Praha

doc. Ing. Bohumil Miniberger, CSc.

Červen, 2015

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

………………………. Podpis autora

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

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

Obsah ÚVOD ..................................................................................................................................................................... 6 1

BUSINESS INTELLIGENCE ARCHITEKTURA A MODELY DATOVÉHO SKLADU .................... 8 1.1 BUSINESS INTELLIGENCE.......................................................................................................................... 8 1.1.1 Prvky BI architektury....................................................................................................................... 8 1.1.2 Architektury datového skladu ........................................................................................................ 20 1.2 DIMENZIONÁLNÍ MODEL......................................................................................................................... 30 1.2.1 Fakta .............................................................................................................................................. 31 1.2.2 Dimenze ......................................................................................................................................... 32

2

TELEKOMUNIKAČNÍ FIRMA ............................................................................................................... 40 2.1 IS TELEKOMUNIKAČNÍ FIRMY ................................................................................................................. 40 2.1.1 Telekomunikační síť ....................................................................................................................... 41 2.1.2 Mediace ......................................................................................................................................... 42 2.1.3 Provisioning .................................................................................................................................. 42 2.1.4 Rating ............................................................................................................................................ 42 2.1.5 Billing ............................................................................................................................................ 43 2.1.6 Customer Relationship Management ............................................................................................. 44 2.2 FRAMEWORKX........................................................................................................................................ 45 2.2.1 Procesní rámec eTOM ................................................................................................................... 45

3

TVORBA DIMENZIONÁLNÍHO MODELU .......................................................................................... 53 3.1 PODNIKOVÉ PROCESY ............................................................................................................................. 53 3.1.1 Využití služeb sítě (CDR data mart) .............................................................................................. 59 3.1.2 Fakturace....................................................................................................................................... 61 3.1.3 Balance účtu .................................................................................................................................. 63 3.1.4 Správa objednávek......................................................................................................................... 64 3.1.5 Servisní požadavky ........................................................................................................................ 67 3.2 DIMENZE ................................................................................................................................................ 68 3.2.1 Adresa ............................................................................................................................................ 72 3.2.2 Audit .............................................................................................................................................. 73 3.2.3 Datum a čas ................................................................................................................................... 74 3.2.4 Fakturační cyklus .......................................................................................................................... 76 3.2.5 Kontakt .......................................................................................................................................... 77 3.2.6 Lokalita .......................................................................................................................................... 78 3.2.7 Produkt .......................................................................................................................................... 78 3.2.8 Subscriber, fakturační účet a zákazník .......................................................................................... 79 3.2.9 Zaměstnanec .................................................................................................................................. 84 3.2.10 Sběrnice datového skladu .............................................................................................................. 86 3.3 IDENTIFIKACE FAKTŮ ............................................................................................................................. 87

4

NÁVRH PROCESŮ NA PLNĚNÍ DATOVÉHO SKLADU ZE ZDROJOVÝCH SYSTÉMŮ ............ 91 4.1 4.2 4.3

5

DATOVÁ KVALITA .................................................................................................................................. 92 PLNĚNÍ DATOVÉHO SKLADU ................................................................................................................... 95 ŘÍZENÍ ETL PROCESŮ ........................................................................................................................... 100

IMPLEMENTACE DATOVÉHO SKLADU .......................................................................................... 101 5.1 5.2 5.3

ODS ..................................................................................................................................................... 101 ETL SYSTÉM ........................................................................................................................................ 104 DATOVÝ SKLAD.................................................................................................................................... 105

ZÁVĚR ............................................................................................................................................................... 107

5

Ú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

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

1 Business Intelligence architektura a modely datového skladu 1.1 Business Intelligence Gála1 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 Teradata2, 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ý.

1.1.1 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 978-80-247-2615-1. 2

http://www.teradata.com/products-and-services/Teradata-Database/ 8

Zdrojové systémy

Analytické databáze

Transformace dat

Datový sklad

OSS/BSS ETL

Datové tržiště

Datové tržiště

Analytické a prezentační aplikace 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 podle3

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ála4 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


496 s. Expert (Grada). ISBN 978-80-247-2615-1. s. 218 4

Tamtéž, s. 227 9

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 podle5

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


496 s. Expert (Grada). ISBN 978-80-247-2615-1. s. 226 10

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 Inmon6 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 Gate7, Informatica Power Exchange8 nebo Dell

6

INMON, William H. Building the data warehouse. 3rd ed. New York: John Wiley, 2002, 412 p.

ISBN 04-710-8130-2. 7

http://www.oracle.com/us/products/middleware/data-integration/goldengate/overview/index.html

8

http://www.informatica.com/Images/01435_powerexchange_ds_en-US.pdf 11

SharePlex9. 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. 1.1.1.2 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).

Extract Datový zdroj Load Datový zdroj

Transform

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

http://software.dell.com/products/shareplex/, původně se jedná o produkt firmy Quest 12

především identifikace změn ve zdrojovém systému a jejich čtení. Ralph Kimball10 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. Kimball11 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 podle12

10

KIMBALL, Ralph, Margy Ross. The data warehouse toolkit: the definitive guide to dimensional modeling. 3rd

ed. Indianopolis: John Wiley, 2013, 601 p. ISBN 11-185-3080-2. 11

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 07-645-7923-1. 12


ed. Indianopolis: John Wiley, 2013, 601 p. ISBN 11-185-3080-2. s. 460 13

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.

Extract

Transform

Datový zdroj Load

Datový sklad

Datový zdroj

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

primární zdrojový systém. Zástupcem těchto produktů je např. Oracle Golden Gate nebo Quest SharePlex. 1.1.1.3 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ály13 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í. 1.1.1.4 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 čase14 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 DSS15, jako je integrace a subjektová orientace.

13



INMON, William H. The Operational Data Store. In: Information Management [online]. 1998

[cit. 2014 04 06]. Dostupné z: http://www.information-management.com/issues/19980701/469-1.html 15

DSS - Decision Support System 15

Podle četnosti nahrávání změn do ODS rozlišuje Inmon čtyři základní třídy ODS16: 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.

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.

III.

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

IV.

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

1.1.1.5 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]. 2000 [cit. 2014 04 06]. Dostupné z:

http://www.information-management.com/issues/20000101/1749-1.html 17

INMON, William H. Building the data warehouse. 3rd ed. New York: John Wiley, 2002, 412 p. ISBN 04-710-8130-2. s. 31, překlad autor 16

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

Obrázek 6: Problémy integrace dat Zdroj: 18

18

INMON, William H. Building the data warehouse. 3rd ed. New York: John Wiley, 2002, 412 p. ISBN

04-710-8130-2. s. 33 17

1.1.1.6 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ší. 1.1.1.7 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

v multidimenzionálních strukturách.

18

OLAP)

provádí

uložení

dat

•

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ála19) 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. 1.1.1.8 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 Discoverer20 nebo SAP BusinessObjects21 se pro tvorbu analytických aplikací používají také kancelářské aplikace jako je MS Excel nebo MS Access22.

19



http://www.oracle.com/technetwork/developer-tools/discoverer/overview/index.html

21

http://www.sap.com/pc/analytics/business-intelligence/software/overview/index.html

22

http://office.microsoft.com 19

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.

1.1.2.1 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: 23 23



1.1.2.2 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 podle24 (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 Kimball25 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. The data warehouse lifecycle toolkit: expert methods for designing, developing, and

deploying data warehouses. 3rd ed. New York: John Wiley, 1998, 771 p. ISBN 04-712-5547-5. s. 51 21

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ů. Kimball27 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 complete guide to dimensional modeling.

2nd ed. New York: John Wiley, 2002, 436 p. ISBN 04-712-0024-7. s. 81 22

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



dotazů,

tabulkový procesor,

reportingové

a

analytické

nástroje

jako

jsou

SAP

BusinessObjects29, Oracle Discoverer30 nebo data-miningové aplikace, jako je například SPSS Clementine31. Samotný proces návrhu datového skladu rozděluje Ralph Kimball do čtyř základních etap: •

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. 1.1.2.3 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 29

http://www.sap.com/pc/analytics/business-intelligence/software/overview/index.html

30

http://www.oracle.com/technetwork/developer-tools/discoverer/overview/index.html

31

http://www-01.ibm.com/software/analytics/spss/ 24

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 04-713-9961-2. s. 13 25

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

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

Opakovat pro každý subjekt DSS5 výběr subjektové oblasti

DSS7 analýza zdrojových systémů

DSS8 tvorba specifikací

DSS9 programování

DSS10 naplnění databáze

DSS1 analýza datového modelu DSS2 breadbox analýza

DSS3 technický návrh

DSS6 návrh databáze DWH

DSS4 příprava technického prostředí

Obrázek 12: Metodika Meth 2 Zdroj: autor, upraveno podle34

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

Breadbox analýza v kroku DSS2 je analýzou velikosti datového skladu a jeho granularity INMON, William H. Building the data warehouse. 3rd ed. New York: John Wiley, 2002, 412 p.

ISBN 04-710-8130-2. 27

DW1

DW2 federalizovaný datový sklad

integrace DW3

DW4 Obrázek 13: Federalizovaný datový sklad Zdroj: autor

1.1.2.5 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 Breslin35.

Celkový přístup komplexita Porovnání se zavedenými vývojovými metodikami Diskuze o fyzickém designu

Inmon Metodika a architektura shora dolů komplexní odvozena ze spirálové metodiky

Určeno primárně pro

poměrně důkladná Datové modelování subjektová orientace tradiční (ERD, DIS) nízká Filozofie IT odborníky

Umístění v organizaci

Integrální část CIF

Cíl

dodat důkladné technické řešení založené na ověřených databázových metodách a technologiích

Orientace dat Nástroje Přístupnost pro koncové uživatele

Kimball zdola nahoru vcelku jednoduchá postup ve čtyřech krocích; založeno na RDBMS metodách pouze lehká procesně orientovaná dimenzionální modelování vysoká koncové uživatele transformace a udržování operačních dat dodat řešení, které koncovým uživatelům usnadní přímé dotazování při rozumném čase odezvy

Tabulka 2: Porovnání základních vlastností Inmonova a Kimballova modelu. Zdroj: 36

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. 6-20. 9, 1. ISSN 1547-2825. 36

Tamtéž 28

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 Journal37, 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 1547-2825. 29

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 KATEGORIE DIMENZE ČAS

DIMENZE PRODUKT

DIMENZE ČAS

DIMENZE PRODUKT

FAKTA PRODEJ FAKTA PRODEJ DIMENZE ZÁKAZNÍK DIMENZE ZÁKAZNÍK

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

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 dimenzemi38, 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 04-712-0024-7. 31

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.

1.2.2 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

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

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

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ě 103 řádků. V případě, že atributy mohou nabývat pěti různých hodnot, počet řádků vzroste až na 100 000, 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 Kimball40 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



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

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: 42

41

KIMBALL, Ralph, Margy Ross. The data warehouse toolkit: the definitive guide to dimensional modeling.

3rd ed. Indianopolis: John Wiley, 2013, 601 p. ISBN 11-185-3080-2. s. 160 42

Tamtéž, s. 161 37

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



Obrázek 19: využití pomocné tabulky pro vazbu M:N Zdroj: autor, upraveno podle44

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



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ů Frameworkx45, jejímž tvůrcem je organizace TeleManagement

Forum46.

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 Union47, jako ITU-T Recommendation M.3050: Enhanced Telecom Operations Map48.

2.1 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 45

https://www.tmforum.org/tm-forum-frameworx/

46

http://www.tmforum.org

47

http://www.itu.int

48

http://www.itu.int/rec/T-REC-M/en 40

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

2.1.1 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

•

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.

2.1.2 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ů.

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

2.1.4 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

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

2.1.5 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

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

2.1.6 Customer Relationship Management Gála49 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, email, mobilní aplikace a další. Analytické CRM slouží k analýze informací o zákaznících, k predikci jejich chování, 49


496 s. Expert (Grada). ISBN 978-80-247-2615-1. s. 210-212 44

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

2.2.1 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, SIP51, 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.

50

https://www.tmforum.org/tm-forum-frameworx/

51

SIP – Strategy, Infrastructure & Product 45

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:

52

•

trh a prodej (Market / Sales),

•

produkt (Product),

•

zákazník (Customer),

•

služby (Services),

•

zdroje (Resources),

•

dodavatelé a partneři (Suppliers / Partners),

•

podnik (Enterprise).

GB921CP Process Framework Concepts and Principles R14.5.1. TM Forum [online]. Morristown (NJ), 2015

[cit. 2015-06-23]. Dostupné z: https://www.tmforum.org/resources/standard/gb921-process-framework-concepts-and-principles-r14-5-1/ 46

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

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ů. 2.2.1.1 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: 53

53

GB921P Process Framework Primer R14.5.1. TM Forum [online]. Morristown (NJ), 2015 [cit. 2015-06-23].

Dostupné z: https://www.tmforum.org/resources/standard/gb921p-process-framework-primer-r14-5-1/ 48

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 podle54

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 R14.5.1. TM Forum [online]. Morristown (NJ), 2015 [cit. 2015-06-23].

Dostupné z: https://www.tmforum.org/resources/standard/gb921p-process-framework-primer-r14-5-1/ 49

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. 2.2.1.2 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í SLA55 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

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

Obrázek 25: eTOM model provozních procesů, úroveň 2 Zdroj: 56

56



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

•

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

•

Manage Balances je proces zodpovědný za správu zůstatku na účtu zákazníka nebo subscribera57.

•

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, guiding58, 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

•

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 podle59

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),

•

59

využití služeb sítě.



Systémy, ze kterých bude datový sklad plněn, jsou billingový systém Kenan FX izraelské firmy Comverse60 a Siebel61, 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ýmu62, 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

60

http://www.comverse.com/comverse-products/comverse-bss/comverse-postpaid/comverse-kenan-fx/

61

http://www.oracle.com/us/products/applications/siebel/overview/index.html

62

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

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. 2.1. Uživatel vybere produkt ze seznamu. 2.2. Uživatel vybere požadovanou akci 2.2.1. Pokud je akce změna, uživatel upraví parametry 3. Pokud je požadovanou akcí přidání nového produktu. 3.1. Uživatel vybere produkt ze seznamu. 3.2. 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

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

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

Identifikace první BTS (CGI - CellGlobalIdentity), na kterou přišel hovor

VARCHAR2(14)

teleServiceCode

Identifikuje typ hovoru (normální, pohotovostní, fax). Pokud je použitý, tak není k dispozici bearerServiceCode

NUMBER(2)

bearerServiceCode

Identifikuje typ hovoru (normální, pohotovostní, fax). Pokud je použitý, tak není k dispozici teleServiceCode

NUMBER(2)

lastPartialOutput

Označuje poslední CDR, pokud dochází k dělení CDR. (0 = ne, 1 = ano)

NUMBER(1)

59

Název atributu

Popis

Datový typ (Oracle notace)

partialOutputRecNum

Pořadové číslo CDR, pokud dochází k dělení CDR.

NUMBER(2)

networkCallReference

Jednoznačný identifikátor hovoru. Všechny CDR k jednomu hovoru mají tento atribut shodný.

VARCHAR2(10)

internalCauseAndLoc

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.

VARCHAR2(4)

eosInfo

Proč hovor nebyl spojen. (účastník nedostupný, obsazeno, ústředna neměla prostředky)

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

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.

3.1.2 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

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

Obrázek 30: Kenan FX - ER diagram fakturace a zákaznický účet Zdroj: autor

3.1.3 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

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.

3.1.4 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

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

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

1

1.1.2015 15:20

SUBMIT_DATE

COMPLETED_DATE

STATUS

IS_FINAL_STATUS

CREATED

N

CREATE_TO_SUBMIT

CREATE_TO_COMPLETED

CREATE_TO_COMPLETED

Změna statusu objednávky, aktualizace řádku objednávky ORDER_NUM

CREATE_DATE

SUBMIT_DATE

1

1.1.2015 15:20

1.1.2015 19:42

COMPLETED_DATE

STATUS

IS_FINAL_STATUS

CREATE_TO_SUBMIT

SUBMITED

N

15720

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

1

1.1.2015 15:20

1.1.2015 19:42

1.1.2015 19:58

FAILED

Y

15720

16680

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

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

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

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

SERV_REQ_F

Akumulovaný snímek servisního požadavku

Tabulka 5: Tabulky faktů Zdroj: autor

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

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

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

Obrázek 40: Datové tržiště „Servisní požadavky“ Zdroj: autor

3.2.1 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 163, 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

Cíl Jméno tabulky

Jméno sloupce

Zdroj Zdrojový systém

Jméno tabulky

Jméno sloupce

ADDRESS_D

ADDRESS_KEY

ETL

ADDRESS_D

SIEBEL_ROW_ID

Siebel

S_ADDR_PER

ADDRESS_D

CREATED

Siebel

ADDRESS_D

END_DT

Siebel

63

Popis

SCD typ

surrogate key

1

ROW_ID

unikátní identifikátor řádku v tabulce S_ADDR_PER

1

S_ADDR_PER

CREATED

Kdy byl záznam vytvořen

1

S_ADDR_PER

END_DT

Konec platnosti adresy

1

Typy dimenzí jsou popsány v kapitole 1.2.2 72

Cíl Jméno tabulky

Jméno sloupce


Jméno tabulky

Popis

Jméno sloupce

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

Různé informace, např. jméno budovy, PO box apod.

1

ADDRESS_D

RECORD_TS

ETL

kdy byl záznam vložen do dimenze nebo modifikován

1

Tabulka 6: Dimenze adresa Zdroj: autor

3.2.2 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

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

3.2.3 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

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 31536000 řá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

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; Cíl Jméno tabulky

Jméno sloupce


Jméno tabulky

BILLCYCLE_D

BILLCYCLE_KEY

BILLCYCLE_D

BILL_PERIOD

Kenan

BILL_CYCLE

BILLCYCLE_D

BILLING_FREQUENCY Kenan

BILLCYCLE_D

PPDD_DATE

Jméno sloupce

ETL

Kenan

SCD typ

Popis

0

Surrogate key

BILL_PERIOD

0

název billingového cyklu

BILL_CYCLE

BILLING_FREQUENCY

0

kód frekvence billingu

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

BILLCYCLE_D

SHORT_DISPLAY

Kenan

BILL_FREQUENCY_VYLUES SHORT_DISPLAY

0

BILLCYCLE_D

DISPLAY_VALUE

Kenan

BILL_FREQUENCY_VYLUES DISPLAY_VALUE

0

popis frekvence

1

kdy byl záznam vložen do dimenze nebo modifikován

BILLCYCLE_D

RECORD_TS

ETL

Tabulka 10: Dimenze fakturační cyklus Zdroj: autor

76

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 krátký popis frekvence

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. Cíl Jméno tabulky CONTACT_D

Jméno sloupce CONTACT_KEY


Jméno tabulky

Jméno sloupce

ETL

SCD Typ

Popis

Surrogat key

CONTACT_D

ROW_ID

Siebel

S_CONTACT ROW_ID

unikátní identifikátor kontaktu v tabulce S_CONTACT. Přirozený klíč pomocí kterého svážeme všechny řádky patřící k 0 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

CONTACT_D

RECORD_TS

ETL

příznak aktuálního kontaktu kdy byl záznam vložen do dimenze nebo 1 modifikován

Tabulka 11: Dimenze kontakt Zdroj: autor 77

3.2.6 Lokalita Tato dimenze je plněna ze souboru, který obsahuje záznam pro každou lokalitu, kde je umístěna BTS64, mapování dimenze je v tabulce 12. Cíl Jméno tabulky


Jméno sloupce

Jméno tabulky

Jméno sloupce

SCD Typ

Popis

CELL_LOCATION_D

CELL_KEY

ETL

CELL_LOCATION_D

CELL_BAND

CELL DB

soubor

BAND

1 rádiová frekvence

surrogate key

CELL_LOCATION_D

CELL_CGI

CELL DB

soubor

CGI

identifikace buňky (Cell Glogal 2 Identifier)

CELL_LOCATION_D

CELL_DISTRICT

CELL DB

soubor

DISTRICT

2 oblast

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

1 kdy byl záznam vložen do dimenze

Tabulka 12: Dimenze lokalita Zdroj: autor

3.2.7 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). Cíl Jméno tabulky

64

Jméno sloupce


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

kdy byl záznam ve 0 zdrojové tabulce

Base Transceiver Station 78

Cíl Jméno tabulky

Jméno sloupce


Jméno tabulky

Jméno sloupce

SCD Typ

Popis vytvořen kdy byl záznam ve zdrojové tabulce 1 naposled změněn

PRODUCT_D

LAST_UPD

Siebel

S_PROD_INT

LAST_UPD

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

datum ukončení platnosti 1 produktu

PRODUCT_D

EFF_START_DT

Siebel

S_PROD_INT

EFF_START_DT

datum začátku platnosti 1 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

typ platby (např. prepaid, pospaid pro telefonní 1 služby)

PRODUCT_D

PRICE_TYPE_CD

Siebel

S_PROD_INT

PRICE_TYPE_CD

typ ceny (jednorázová, 0 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

PRODUCT_D

RECORD_TS

ETL

1 kód subtypu kdy byl záznam vložen do dimenze nebo 1 modifikován

Tabulka 13: Dimenze produkt Zdroj: autor

3.2.8 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

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

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. Cíl Jméno tabulky

Jméno sloupce

Zdroj Zdroj. systém

Jméno tabulky

Jméno sloupce

SUBSCRIBER_D SUBSCRIBER_KEY

ETL

SUBSCRIBER_D ORDER_LINE_ID

CRM

S_ORDER_ITEM

ROW_ID

SUBSCRIBER_D ASSET_ID

CRM

S_ASSET

ROW_ID

SUBSCRIBER_D MSISDN

CRM

S_ASSET (Aktivováno) S_ORDER_ITEM (Preaktivováno)

S_ASSET.SERIAL_NUM, S_ORDER_LINE.SERVICE_NUM

SUBSCRIBER_D SUBSCR_NO

Kenan

EXTERNAL_ID_EQUIP_MAP SUBSCR_NO

SUBSCRIBER_D SUBSCR_NO_RESETS Kenan

EXTERNAL_ID_EQUIP_MAP SUBSCR_NO_RESETS

81

SCD Typ

Popis

0 surrogate key identifikace řádku 0 objednávky identifikace 0 assetu

0 MSISDN identifikace subscribera z 0 Kenan FX identifikace subscribera z 0 Kenan FX

Cíl Jméno tabulky

Zdroj

Jméno sloupce

Zdroj. systém

Jméno tabulky

CRM


CRM


SUBSCRIBER_D BILL_PROF_ID

CRM


SUBSCRIBER_D EFF_START_TS

ETL

SUBSCRIBER_D EFF_END_TS

ETL

SUBSCRIBER_D CURRENT_FLG

ETL

SUBSCRIBER_D RECORD_TS

ETL

SUBSCRIBER_D STATUS_CD

SUBSCRIBER_D ACCOUNT_ID

SCD Typ

Jméno sloupce

Popis

STATUS_CD

status 1 subscribera

BILL_ACCOUNT_ID

zákazník, ke kterému 2 subscriber patří fakturační účet přiřazený 2 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 1 modifikován

BILL_PROFILE_ID

Tabulka 14: Dimenze subscriber Zdroj: autor

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). Cíl Jméno tabulky

Jméno sloupce


Jméno tabulky

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

identifikace záznamu v 0 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

kdy byl záznam vytvořen 0 ve zdroji

BILL_PROF_D

LAST_UPD

Siebel

S_INV_PROF

LAST_UPD

kdy byl záznam 1 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

BILL_PROF_D

BILL_PREF_CD

Siebel

S_INV_PROF

BILL_PREF_CD

BILL_PROF_D

CONTACT_ID

Siebel

S_INV_PROF

CON_ID

BILL_PROF_D

MEDIA_TYPE_CD

Siebel

S_INV_PROF

MEDIA_TYPE_CD

1 identifikace kontaktu medium pro tisk 2 vyúčtování

BILL_PROF_D

PAYMENT_TYPE_CD

Siebel

S_INV_PROF

PAYMENT_TYPE_CD

typ platby (prepaid, 2 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

Perioda, ve které se 1 vystavuje faktura preferovaný typ 1 vyúčtování

Cíl Jméno tabulky

Jméno sloupce


Jméno tabulky

Jméno sloupce LANG_ID

SCD Typ

Popis

BILL_PROF_D

LANG_ID

Siebel

S_INV_PROF

1 preferovaný jazyk

BILL_PROF_D

ACCOUNT_NO

Kenan

EXTERNAL_ID_ACCT_MAP ACCOUNT_NO

identifikace fakturačního 0 účtu v Kenan FX

BILL_PROF_D

ACCOUNT_NO_RESETS Kenan

EXTERNAL_ID_ACCT_MAP ACCOUNT_NO_RESETS


BILL_PROF_D

EFF_START_TS

ETL


BILL_PROF_D

EFF_END_TS

ETL


BILL_PROF_D

CURRENT_FLG

ETL

BILL_PROF_D

RECORD_TS

ETL

příznak aktuálně 1 platného řádku kdy byl záznam vložen do dimenze nebo 1 modifikován

CUSTOMER_D CUSTOMER_KEY

ETL

CUSTOMER_D CUSTOMER_ID

Siebel

S_ORG_EXT

ROW_ID

surrogate key Identifikace řádku 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_EMAIL_ADDR

Siebel

S_ORG_EXT

MAIN_EMAIL_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


EXTERNAL_ID_ACCT_MAP ACCOUNT_NO_RESETS


CUSTOMER_D ACCOUNT_NO_RESETS Kenan CUSTOMER_D EFF_START_TS

ETL


CUSTOMER_D EFF_END_TS

ETL


CUSTOMER_D CURRENT_FLG

ETL

CUSTOMER_D RECORD_TS

ETL

příznak aktuálně 1 platného řádku 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

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

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

Cíl Jméno tabulky EMPLOYEE_D

Zdroj Jméno sloupce EMPLOYEE_KEY

Zdrojový Jméno tabulky systém

Jméno sloupce

SCD Typ

Popis

ETL

0 surrogate key

EMPLOYEE_D

EMPLOYEE_ID

Siebel

S_EMP_PER

ROW_ID

identifikace zaměstnance v 0 S_EMP_PER

EMPLOYEE_D

EMPLOYEE_NAME

Siebel

S_EMP_PER

NAME

1 jméno

EMPLOYEE_D

LOGIN

Siebel

S_USER

LOGIN

1 login

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

příznak aktuálního 1 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

identifikace 2 zaměstnance

POSITION_EMPLOYEE_BRIDGE EFF_START_TS

ETL


POSITION_EMPLOYEE_BRIDGE EFF_END_TS

ETL


POSITION_EMPLOYEE_BRIDGE CURRENT_FLG

ETL


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


POSITION

EFF_END_TS

ETL


POSITION

CURRENT_FLG

ETL


Tabulka 16: Dimenze zaměstnanec Zdroj: autor

3.2.10 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

Subscriber

Adresa

Kontakt

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

Fakturace

Lokalita

Fakturační účet

Fakturační cyklus

Zákazník

X

Zaměstnanec

Audit

X

X

Produkt

Čas

X

Datum

X

Využití služeb sítě

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

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. Cíl Jméno tabulky

Zdroj Jméno sloupce

Zdrojový systém

Jméno tabulky

Popis

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

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í

Aditivní fakt

N N

N N 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

Y

ORDER_MANAGEMENT_F

NET_PRI

Siebel

S_ORDER_ITEM

NET_PRI

ORDER_MANAGEMENT_F

UNIT_PRI_RC

Siebel

S_ORDER_ITEM

UNIT_PRI_RC

daň cena po zdanění, včetně dopravy, slevy a dobropisu cena po slevě, opakovaná platba

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

N

ORDER_MANAGEMENT_F

DISC_AMT_RC

Siebel

S_ORDER_ITEM

DISC_AMT_RC

sleva v procentech sleva na opakovanou platbu

88

Y Y

Y

Cíl Jméno tabulky


Zdrojový systém

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

ORDER_MANAGEMENT_F

FROM_CREATED_T O_FINAL

Siebel

S_ORDER

ORDER_MANAGEMENT_F

FROM_CREATED_T O_APPROVED

Siebel

S_ORDER

ORDER_MANAGEMENT_F

FROM_CREATED_T O_FINAL_LN

Siebel

S_ORDER_ITEM

STATUS_DT (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

Tabulka 18: Fakta - Správa objednávek Zdroj: autor

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. Cíl Jméno tabulky


Zdrojový systém

Jméno tabulky

Jméno sloupce

Popis

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

(SR_STAT_DT S_SRV_REQ ACT_OPEN_DT)*24*3600

SRV_REQ_F

OPEN_TO_SOLVING

Siebel

(ASGN_DT S_SRV_REQ ACT_OPEN_DT)*24*3600

SRV_REQ_F

OPEN_TO_SOLVED

Siebel

(ACTL_RESOLVED_TS S_SRV_REQ ACT_OPEN_DT)*24*3600

SRV_REQ_F

OPEN_TO_REOPEN

Siebel

(REOPENED_TS S_SRV_REQ ACT_OPEN_DT)*24*3600

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

Siebel

(ACT_CLOSE_DT S_SRV_REQ ACT_OPEN_DT)*24*3600

od otevření do uzavření ve

SRV_REQ_F

OPEN_TO_CLOSE

89

Aditivní fakt

N N n n n

n n

y

y

y

y y

Cíl Jméno tabulky


Zdrojový systém

Jméno tabulky

Jméno sloupce

Popis

Aditivní fakt

vteřinách

SRV_REQ_F

OPEN_TO_EXP_CLOSE Siebel

(EXP_CLOSE_DT S_SRV_REQ ACT_OPEN_DT)*24*3600

Tabulka 19: Fakta - Servisní požadavky Zdroj: autor

90

od otevření do slíbeného uzavření ve vteřinách

y

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 07-645-7923-1. s. 17-20

91

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:66

66

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. 12-20. ISBN 978-80-254-5912-6. s. 18 92

Ralph Kimball ve svém článku An Architecture for Data Quality67 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ů. Loshin68 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]. 2007 [cit. 2015-06-13].

Dostupné z: http://www.kimballgroup.com/wp-content/uploads/2007/10/An-Architecture-for-Data-Quality1.pdf 68

LOSHIN, David. Business Intelligence: The Savvy Manager's Guide. San Francisco: Morgan Kaufmann Publishers, 2003. ISBN 1-55860-916-4. s. 111 93

Pro profilování dat existuje celá řada nástrojů, namátkou lze uvést např. Ataccama DQ Analyzer69, Talend Open Studio for Data Quality70 nebo TS Discovery firmy Trilium71. 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( regexp_replace(cust_phone1,'[[:digit:]]', 9),'[[:alpha:]]', 'X') AS PATTERN, COUNT(*) AS POCET_ZAZNAMU FROM arbor.cmf GROUP BY regexp_replace( regexp_replace(cust_phone1,'[[:digit:]]', 9),'[[:alpha:]]', 'X') ORDER BY 2 DESC;

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,

69

https://www.ataccama.com/products/dq-analyzer https://www.talend.com/resource/data-profiling.html 71 http://www.trilliumsoftware.com/products/data-profiling/ 70

94

•

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


S_PARTY_PER

tabulka


S_LOGIN

tabulka


S_ORDER

tabulka

fakt

insert nových záznamů

timestamp změny

S_ORDER_ITEM

tabulka

fakt


timestamp změny

S_SRV_REQ

tabulka

fakt

insert/update nového/aktualizovaného řádku timestamp změny

S_ORG_EXT

tabulka


S_CONTACT

tabulka


S_ADDR_PER

tabulka


BILL_CYCLE

tabulka


S_INV_PROF

tabulka


CMF

tabulka


EXTERNAL_ID_EQUIP_MAP tabulka


EXTERNAL_ID_ACCT_MAP

tabulka


CMF_BALANCE

tabulka

fakt

insert snímku tabulky

N/A

BILL_INVOICE_DETAIL

tabulka

fakt


timestamp změny

95

Tabulka

Typ zdroje Typ cíle

Operace

identifikace změn na zdroji

CDR soubory

flat file

fakt


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 GoldenGate72, 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 72

http://www.oracle.com/us/products/middleware/data-integration/goldengate/overview/index.html 96

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

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

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

99

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 54. 100

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

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

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 = @GETENV ('GGHEADER', 'COMMITTIMESTAMP')); GGSCI (myhost2) 2> DBlogin UserIdAlias ogg_user

103

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

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

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

106

Závěr Závěrem bych rád shrnul přínos této diplomové práce, míru dosažených cílů, způsob jakým jich bylo dosaženo a případně navrhnout další směry, jakými by bylo možné navržené řešení dále rozšířit. Prvním cílem bylo seznámení se s problematikou datových skladů a dimenzionálního modelování. Tomuto cíli se věnuji v první kapitole práce, první část kapitoly je věnována definici základních pojmů z oblasti BI, prvkům architektury a jejich vztahům. Tato část je zakončena srovnáním používaných architektur datového skladu a hlouběji se věnuje porovnání dvou nejvýznamnějších architektur, datové sběrnici Ralpha Kimballa a „Hub and Spoke“ Williama Inmona. Druhá část kapitoly pojednává o dimenzionálním modelování a vychází především z myšlenek Ralpha Kimballa. Tato část definuje základní stavební prvky dimenzionálního modelu, fakta a dimenze, jejich základní typy. Kromě základních termínů také popisuje typické problémy, které mohou při návrhu vznikat a jak je řešit – například pomalu se měnící dimenze a jejich rozdílná implementace podle typu atributu. Druhá kapitola se věnuje IS infrastruktuře a podnikovým procesům v telekomunikační firmě. V oblasti podnikových procesů se práce věnuje procesům, jak je definuje obecný rámec eTOM. Druhá kapitola tvoří nezbytný základ pro praktickou část této práce. Kapitolou tři začíná samotný proces tvorby datového skladu, postup odpovídá metodice Ralpha Kimballa, pro splnění cíle je vhodnější, protože umožňuje snadněji rozdělit řešení do více inkrementů. Jádro celé práce tvoří tvorba dimenzionálního modelu. Prvním krokem při jeho tvorbě je výběr podnikových procesů tak, aby odpovídaly danému cíli. Vybráno bylo pět procesů: využívání služeb sítě, balance účtu, fakturace, správa objednávek a správa servisních požadavků. Využívání služeb sítě sice neumožňuje přímo sledovat zákaznickou zkušenost, ale je nutné si uvědomit, že telekomunikační síť je hlavním „výrobním“ faktorem telekomunikační firmy a je tedy vhodné tento proces zařadit do prvního inkrementu tvorby datového skladu. Proces balance účtu nám umožňuje sledovat balanci na účtech zákazníků, hradí-li své závazky před splatností. Fakturace vypovídá o útratě zákazníka za služby a tedy o příjmech firmy z těchto služeb, tento proces také umožňuje sledovat využívání služeb a to nejen těch spojených s telekomunikační sítí. Poslední dva procesy mají přímý dopad na 107

zkušenost zákazníka. Správa objednávek nám umožňuje sledovat, co si zákazník objednal za produkty a služby a především jak dlouho trvalo doručení nebo aktivace služby zákazníkovi, případně zdali během zpracování objednávky došlo k chybě. Správa servisních požadavků sleduje vyřizování požadavků zákazníků a řešení problémů jimi hlášených, zda bylo řešení doručeno dle SLA apod. Pro větší názornost jsem při tvorbě dimenzionálního modelu zvolil dva reálné systémy. Siebel, CRM systém firmy Oracle, a billingový systém Kenan FX firmy Comverse. Oba tyto systémy se v telekomunikačních firmách běžně využívají. Navržená tržiště tedy vycházejí z datových modelů těchto systémů. Dalším krokem je návrh ETL procesů. Řešení je navrženo ve formě obecných procesů pro vybrané dimenze a fakta a s přihlédnutím k požadavkům datové kvality. Závěrečná kapitola navrhuje možnou implementaci a nasazení celého řešení především s ohledem na minimalizaci dopadů na zdrojové systémy. Vzhledem k rozsahu práce se jedná pouze o náčrt možného řešení. Rozšíření práce je možné v několika směrech. Jedním je přidání dalších datových tržišť do datového skladu, nabízí se především rozšíření o zpracování aktivit, platby a oceněné CDR záznamy. Také by bylo možné se pokusit model rozšířit o mapování mezi produkty a fakturou nebo mezi produkty a využitím služeb sítě. Toto mapování může být velice komplikované a v některých případech nemusí být vůbec možné.

Dalším rozšířením může

být implementace navržených ETL procesů v ODI nebo další rozpracování nasazení celého řešení. Navržená řešení jsem se snažil koncipovat jako obecná, přesto je hlavně v případu dimenzionálního modelu závislost na konkrétních produktech zřejmá. Postup a některé části návrhu jsou však platné i obecně a dají se tak využít jako možný základ pro jakékoliv řešení datového skladu.

108

Použitá literatura 1. BALLARD, Chuck. Dimensional modeling: in a business intelligence environment. 1st ed. San Jose, California: IBM International Technical Support Organization, 2006, 646 p. ISBN 0738496448. 2. 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. 6-20. 9, 1. ISSN 1547-2825. 3. GÁLA, Libor, Jan POUR a Zuzana ŠEDIVÁ. Podniková informatika. 2., přeprac. a aktualiz. vyd. Praha, 2009, 496 s. Expert (Grada). ISBN 978-80-247-2615-1. 4. HUMPHRIES, Mark, Hawkins, Michael W, Dy,Michelle C. (2002). Data warehousing: Návrh a implementace. 1.vyd. Praha: Computer Press, 2001, 257 s. CD. ISBN 80-7226-560-1. 5. INMON, William H. Building the data warehouse. 3rd ed. New York: John Wiley, 2002, 412 p. ISBN 04-710-8130-2. 6. INMON, William H, Claudia IMHOFF a Ryan SOUSA. Corporate information factory. 2nd ed. New York: John Wiley, 2001, 382 p. ISBN 04-713-9961-2. 7. INMON, William H., Derek STRAUSS. DW 2.0: the architecture for the next generation of

data

warehousing.

3rd

ed.

Boston:

Morgan

Kaufmann,

2008,

371

p.

ISBN 978-012-3743-190. 8. JARKE, Matthias. Fundamentals of data warehouses. 2., rev. and extended ed. New York: Springer, 2003, 219 p. ISBN 35-404-2089-4. 9. 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 07-645-7923-1. 10. 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 04-712-5547-5. 109

11. KIMBALL, Ralph, Margy Ross. The data warehouse toolkit: the complete guide to dimensional

modeling.

2nd

ed.

New

York:

John

Wiley,

2002,

436

p.

ISBN 04-712-0024-7. 12. KIMBALL, Ralph, Margy Ross. The data warehouse toolkit: the definitive guide to dimensional

modeling.

3rd

ed.

Indianopolis:

John

Wiley,

2013,

601

p.

ISBN 11-185-3080-2. 13. LACKO, Luboslav. Databáze: datové sklady, OLAP a dolování dat s příklady v Microsoft SQL Serveru a Oracle. 1. vyd. Brno: Computer Press, 486 s. ISBN 80-722-6969-0. 14. LOSHIN, David. Business Intelligence: The Savvy Manager's Guide. San Francisco: Morgan Kaufmann Publishers, 2003. ISBN 1-55860-916-4. 15. 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. 12-20. ISBN 978-80-254-5912-6. 16. 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 1547-2825. Online zdroje a webová sídla 17. An Architecture for Data Quality. KIMBALL, Ralph. The Kimball Group [online]. 2007 [cit. 2015-06-13]. Dostupné z :http://www.kimballgroup.com/wp-content/uploads/2007/1 0/An-Architecture-for-Data-Quality1.pdf 18. DELL INC. IT & Systems Management [online]. Aliso Viejo (California), (c) 2014 [cit. 2014-04-06]. Dostupné z: http://www.quest.com

110

19. GB921CP Process Framework Concepts and Principles R14.5.1. TM Forum [online]. Morristown (NJ), 2015 [cit. 2015-06-23]. Dostupné z: https://www.tmforum.org/resources/standard/gb921-process-framework-concepts-andprinciples-r14-5-1/ 20. GB921P Process Framework Primer R14.5.1. TM Forum [online]. Morristown (NJ), 2015 [cit. 2015-06-23]. Dostupné z: https://www.tmforum.org/resources/standard/gb921p-process-framework-primer-r14-5-1/ 21. INFORMATICA CORPORATION. Informatica [online]. Redwood City (California), (c) 2014 [cit. 2014-04-06]. Dostupné z: http://www.informatica.com 22. INMON, William H. The Operational Data Store. In: Information Management [online]. 1998 [cit. 2014-04-06]. Dostupné z: http://www.information-management.com/issues/19980701/469-1.html 23. INMON, William H. ODS Types. In: Information Management [online]. 2000 [cit. 2014-04-06]. Dostupné z: http://www.information-management.com/issues/20000101/1749-1.html 24. ORACLE CORPORATION. Oracle [online]. Redwood Shores (California), [2014] [cit. 2014-04-06]. Dostupné z: http://www.oracle.com 25. SAP AG. SAP Software & Solutions [online]. Walldorf, (c) 2014 [cit. 2014-04-20]. Dostupné z: http://http://www.sap.com/ 26. TERADATA CORPORATION. Teradata [online]. Dayton (Ohio), [2014] [cit. 2014-04-06]. Dostupné z: http://www.teradata.com 27. TM FORUM. TM Forum [online]. Morristown, © 1988-2015 [cit. 2015-01-06]. Dostupné z: http://www.tmforum.org

111

Seznam obrázků Obrázek 1: Základní vrstvy řešení BI ......................................................................................... 9 Obrázek 2: BI architektura ....................................................................................................... 10 Obrázek 3: Princip ETL............................................................................................................ 12 Obrázek 4: Auditní dimenze ..................................................................................................... 13 Obrázek 5: Princip ELT............................................................................................................ 14 Obrázek 6: Problémy integrace dat .......................................................................................... 17 Obrázek 7: Princip multidimenzionální (OLAP) databáze ...................................................... 18 Obrázek 8: Architektura nezávislých datových tržišť .............................................................. 20 Obrázek 9: Fakta a dimenze ..................................................................................................... 21 Obrázek 10: DW/BI architektura podle Ralpha Kimballa........................................................ 23 Obrázek 11: Corporate Information Factory ............................................................................ 25 Obrázek 12: Metodika Meth 2 .................................................................................................. 27 Obrázek 13: Federalizovaný datový sklad ............................................................................... 28 Obrázek 14: Dimenzionální schéma ......................................................................................... 30 Obrázek 15: Normalizovaná (snowflaked) dimenze se dvěma hierarchiemi ........................... 34 Obrázek 17: SCD typ 5 ............................................................................................................. 37 Obrázek 18: SCD typ 6 ............................................................................................................. 37 Obrázek 19: SCD typ 7 ............................................................................................................. 38 Obrázek 20: využití pomocné tabulky pro vazbu M:N ............................................................ 39 Obrázek 21: IS telekomunikační firmy .................................................................................... 41 Obrázek 21: Offline a online charging ..................................................................................... 43 Obrázek 22: konceptuální model eTOM .................................................................................. 46 Obrázek 24: Dekompozice procesů .......................................................................................... 48 Obrázek 24: Dekompozice procesů v modelu eTOM, úroveň 1 .............................................. 49 Obrázek 25: eTOM model provozních procesů, úroveň 2 ....................................................... 52 Obrázek 26: eTOM - FAB vertikály a zákaznická dimenze .................................................... 55 Obrázek 27: Diagram případů užití billingového systému ....................................................... 56 Obrázek 28: Diagram případů užití CRM ................................................................................ 58 Obrázek 29: Kenan FX - CDR management ER diagram ........................................................ 60 Obrázek 30: Kenan FX - ER diagram fakturace a zákaznický účet ......................................... 63 Obrázek 31: Siebel CRM - ER diagram správy objednávek .................................................... 64 Obrázek 32: Životní cyklus objednávky................................................................................... 65 Obrázek 33: Akumulovaný snímek faktů ................................................................................. 66 Obrázek 34: Siebel CRM - ER diagram servisních požadavků................................................ 67 Obrázek 35: Životní cyklus servisního požadavku................................................................... 68 Obrázek 36: Datové tržiště „Využití sítě“ ................................................................................ 69 Obrázek 37: Datové tržiště „Fakturace“ ................................................................................... 70 Obrázek 38: Datové tržiště „Balance účtu“ .............................................................................. 70 Obrázek 39: Datové tržiště „Správa objednávek“ .................................................................... 71 Obrázek 40: Datové tržiště „Servisní požadavky“ ................................................................... 72 Obrázek 41: Hierarchie adresy ................................................................................................. 72 Obrázek 42: Hierarchie dimenze datum ................................................................................... 74 Obrázek 43: Vztah subscriber - fakturační účet – zákazník ..................................................... 80 Obrázek 44: Životní cyklus subscribera ................................................................................... 80 Obrázek 45: Vztah mezi entitami zákazník, fakturační účet a subscriber v Siebel CRM a Kenan FX.................................................................................................................................. 81 Obrázek 46: Vztah mezi zaměstnancem a pozicí v Siebel CRM ............................................. 84 112

Obrázek 47: Dimenze „zaměstnanec“ s využitím pomocné tabulky pro implementaci hierarchie .................................................................................................................................. 85 Obrázek 48: Zjednodušené schéma správy datového skladu ................................................... 92 Obrázek 49: ETL proces - BPMN diagram kontrol datové kvality.......................................... 96 Obrázek 50: ETL proces - BPMN diagram plnění dimenze s atributy SCD typu 0 a 1 ........... 97 Obrázek 51: ETL proces - BPMN diagram plnění dimenze s atributy SCD typu 0, 1 a 2 ....... 98 Obrázek 52: ETL proces - BPMN diagram spojení více zdrojů při plnění dimenze................ 99 Obrázek 53: ETL proces - BPMN diagram plnění faktů ........................................................ 100 Obrázek 54: ETL proces - BPMN diagram řízení denního zpracování ................................. 101 Obrázek 55: Oracle GoldenGate diagram nasazení ................................................................ 102 Obrázek 56: ODI diagram nasazení........................................................................................ 104 Obrázek 57: Diagram nasazení datového skladu .................................................................... 106

Seznam tabulek Tabulka 1: Matice sběrnice datového skladu (Data Warehouse Bus Matrix) .......................... 22 Tabulka 2: Porovnání základních vlastností Inmonova a Kimballova modelu. ....................... 28 Tabulka 3: Denormalizovaná hierarchická data ....................................................................... 33 Tabulka 4: CDR atributy .......................................................................................................... 60 Tabulka 5: Tabulky faktů ......................................................................................................... 69 Tabulka 6: Dimenze adresa ...................................................................................................... 73 Tabulka 7: Auditní dimenze ..................................................................................................... 74 Tabulka 8: Dimenze datum ...................................................................................................... 75 Tabulka 9: Dimenze čas ........................................................................................................... 75 Tabulka 10: Dimenze fakturační cyklus ................................................................................... 76 Tabulka 11: Dimenze kontakt................................................................................................... 77 Tabulka 12: Dimenze lokalita................................................................................................... 78 Tabulka 13: Dimenze produkt .................................................................................................. 79 Tabulka 14: Dimenze subscriber .............................................................................................. 82 Tabulka 15: Dimenze fakturační účet a zákazník ..................................................................... 83 Tabulka 16: Dimenze zaměstnanec .......................................................................................... 86 Tabulka 17: Sběrnice datového skladu ..................................................................................... 87 Tabulka 18: Fakta - Správa objednávek ................................................................................... 89 Tabulka 19: Fakta - Servisní požadavky .................................................................................. 90 Tabulka 20: ETL – zdroje dat a způsob jejich zpracování ....................................................... 96

Seznam zkratek BI BSS CDR CIF CRM DIS DOLAP DSA DSS DW

Business Intelligence Business Support System Call Detail Record Corporate Information Factory Customer Relationship Management Data Item Set Desktop On-line Analytic Processing Data Staging Area Decision Support System Data Warehouse 113

EAI EDR ELT ERD ETL eTOM FAB GGSN HOLAP HW IS IT MMSC MOLAP MS MSC ODI ODS OLAP OLTP OSS QoS RDBMS ROLAP SCD SGSN SIP SLA SMSC SW UDR

Enterprise Application Integration Event Detail Record Extraction Loading Transformation Entity Relationship Diagram Extraction Transformation enhanced Telecommunication Map Fulfillment, Assurance & Billing Gateway GPRS Support Node Hybrid On-line Analytic Processing Hardware Informační systém Information Technology Multimedia Messaging Service Centre Multidimensional On-line Analytic Processing Microsoft Mobile Switching Centre Oracle Data Integrator Operational Data Store On-line Analytic Processing On-line Transaction Processing Operational Support System Quality of Service Relational Database Management System Relational On-line Analytic Processing Slowly changing dimension Serving GPRS Support Node Strategy, Infrastructure & Product Service Level Agreement Short Message Service Centre Software Usage Detail Record

114

Příloha č. 1 SQL dotazy – Siebel metadata /**************************************************************/ /* Význam sloupců tabulky podle Siebel Repository */ /**************************************************************/ SELECT T.NAME TABLE_NAME, C.NAME AS "COLUMN NAME", C.TYPE, C.STAT_CD AS "STATUS", C.DESC_TEXT AS "DESCRIPTION" FROM S_TABLE T, S_COLUMN C, S_REPOSITORY R WHERE R.ROW_ID = T.REPOSITORY_ID AND T.ROW_ID = C.TBL_ID AND (R.INACTIVE_FLG IS NULL OR R.INACTIVE_FLG = 'N') AND T.INACTIVE_FLG = 'N' AND C.INACTIVE_FLG = 'N' AND T.NAME = :TABLE_NAME ORDER BY C.NAME;

/**************************************************************/ /* Mapování z pole apletu (Siebel GUI) na sloupec tabulky */ /* jinou možností je aplikace Siebel Tools, ale ta je */ /* obvykle k dispozici pouze administrátorům Siebel CRM */ /**************************************************************/ SELECT DISTINCT APPLET, APPLETTYPE, BUSINESSCOMPONENT, CAPTION, PICKLIST, LOVTYPE, FIELD_NAME, FIELD_CALCVAL, COL_NAME, TABLE_NAME, JOIN_NAME FROM (SELECT RESP.NAME RESPONSIBILITY, VW.NAME VIEWNAME, APP.NAME APPLET, 'FORM' AS APPLETTYPE, BC.NAME BUSINESSCOMPONENT, NVL (CTRLOVR.CAPTION, CTRLSTR.STRING_VALUE) CAPTION, CTRL.FIELD_NAME FIELD, FLD.PICKLIST_NAME PICKLIST, PICK.TYPE_VALUE LOVTYPE, FLD.NAME FIELD_NAME, FLD.CALCVAL FIELD_CALCVAL, FLD.COL_NAME, BC.TABLE_NAME, FLD.JOIN_NAME FROM SIEBEL.S_APP_VIEW_RESP VIEWRESP, SIEBEL.S_APP_VIEW APPVIEW, SIEBEL.S_VIEW VW, SIEBEL.S_RESP RESP,

1

SIEBEL.S_VIEW_WEB_TMPL VWT, SIEBEL.S_VIEW_WTMPL_IT VWTI, SIEBEL.S_APPLET APP, SIEBEL.S_CONTROL CTRL, SIEBEL.S_CONTROL_INTL CTRLOVR, SIEBEL.S_SYM_STR_INTL CTRLSTR, SIEBEL.S_BUSCOMP BC, SIEBEL.S_FIELD FLD, SIEBEL.S_PICKLIST PICK WHERE VIEWRESP.RESP_ID = RESP.ROW_ID AND VIEWRESP.VIEW_ID = APPVIEW.ROW_ID AND APPVIEW.NAME = VW.NAME AND VW.INACTIVE_FLG = 'N' AND VW.ROW_ID = VWT.VIEW_ID AND VWT.INACTIVE_FLG = 'N' AND VWTI.VIEW_WEB_TMPL_ID = VWT.ROW_ID AND VWTI.INACTIVE_FLG = 'N' AND APP.NAME = VWTI.APPLET_NAME AND CTRL.APPLET_ID = APP.ROW_ID AND CTRL.INACTIVE_FLG = 'N' AND CTRL.FIELD_NAME IS NOT NULL AND CTRL.ROW_ID = CTRLOVR.CONTROL_ID(+) AND CTRL.CAPTION_REF = CTRLSTR.SYM_STR_KEY(+) AND APP.BUSCOMP_NAME = BC.NAME AND CTRL.FIELD_NAME = FLD.NAME(+) AND FLD.BUSCOMP_ID = BC.ROW_ID AND FLD.PICKLIST_NAME = PICK.NAME(+) AND VW.REPOSITORY_ID = (SELECT ROW_ID FROM SIEBEL.S_REPOSITORY WHERE NAME = 'SIEBEL REPOSITORY') AND APP.REPOSITORY_ID = (SELECT ROW_ID FROM SIEBEL.S_REPOSITORY WHERE NAME = 'SIEBEL REPOSITORY') AND (CTRLSTR.REPOSITORY_ID IS NULL OR CTRLSTR.REPOSITORY_ID = (SELECT ROW_ID FROM SIEBEL.S_REPOSITORY WHERE NAME = 'SIEBEL REPOSITORY')) AND BC.REPOSITORY_ID = (SELECT ROW_ID FROM SIEBEL.S_REPOSITORY WHERE NAME = 'SIEBEL REPOSITORY') AND (FLD.REPOSITORY_ID IS NULL OR FLD.REPOSITORY_ID = (SELECT ROW_ID FROM SIEBEL.S_REPOSITORY WHERE NAME = 'SIEBEL REPOSITORY')) AND (PICK.REPOSITORY_ID IS NULL OR PICK.REPOSITORY_ID = (SELECT ROW_ID FROM SIEBEL.S_REPOSITORY WHERE NAME = 'SIEBEL REPOSITORY')) AND APP.NAME LIKE :APPLET_NAME UNION SELECT RESP.NAME RESPONSIBILITY, VW.NAME VIEWNAME, APP.NAME APPLET, 'LIST' AS APPLETTYPE, BC.NAME BUSINESSCOMPONENT, NVL (LSTCOLOVR.DISPLAY_NAME, LSTCOLSTR.STRING_VALUE) CAPTION, LSTCOL.FIELD_NAME FIELD, FLD.PICKLIST_NAME PICKLIST, 2

PICK.TYPE_VALUE LOVTYPE, FLD.NAME FIELD_NAME, FLD.CALCVAL FIELD_CALCVAL, FLD.COL_NAME, BC.TABLE_NAME, FLD.JOIN_NAME FROM SIEBEL.S_APP_VIEW_RESP VIEWRESP, SIEBEL.S_APP_VIEW APPVIEW, SIEBEL.S_VIEW VW, SIEBEL.S_RESP RESP, SIEBEL.S_VIEW_WEB_TMPL VWT, SIEBEL.S_VIEW_WTMPL_IT VWTI, SIEBEL.S_APPLET APP, SIEBEL.S_LIST LST, SIEBEL.S_LIST_COLUMN LSTCOL, SIEBEL.S_LIST_COL_INTL LSTCOLOVR, SIEBEL.S_SYM_STR_INTL LSTCOLSTR, SIEBEL.S_BUSCOMP BC, SIEBEL.S_FIELD FLD, SIEBEL.S_PICKLIST PICK WHERE VIEWRESP.RESP_ID = RESP.ROW_ID AND VIEWRESP.VIEW_ID = APPVIEW.ROW_ID AND APPVIEW.NAME = VW.NAME AND VW.INACTIVE_FLG = 'N' AND VW.ROW_ID = VWT.VIEW_ID AND VWT.INACTIVE_FLG = 'N' AND VWTI.VIEW_WEB_TMPL_ID = VWT.ROW_ID AND VWTI.INACTIVE_FLG = 'N' AND APP.NAME = VWTI.APPLET_NAME AND LST.APPLET_ID = APP.ROW_ID AND LST.INACTIVE_FLG = 'N' AND LSTCOL.LIST_ID = LST.ROW_ID AND LSTCOL.INACTIVE_FLG = 'N' AND LSTCOL.FIELD_NAME IS NOT NULL AND LSTCOL.ROW_ID = LSTCOLOVR.LIST_COLUMN_ID(+) AND LSTCOL.DISPLAY_NAME_REF = LSTCOLSTR.SYM_STR_KEY(+) AND APP.BUSCOMP_NAME = BC.NAME AND LSTCOL.FIELD_NAME = FLD.NAME(+) AND FLD.BUSCOMP_ID = BC.ROW_ID AND FLD.PICKLIST_NAME = PICK.NAME(+) AND VW.REPOSITORY_ID = (SELECT ROW_ID FROM SIEBEL.S_REPOSITORY WHERE NAME = 'SIEBEL REPOSITORY') AND APP.REPOSITORY_ID = (SELECT ROW_ID FROM SIEBEL.S_REPOSITORY WHERE NAME = 'SIEBEL REPOSITORY') AND LST.REPOSITORY_ID = (SELECT ROW_ID FROM SIEBEL.S_REPOSITORY WHERE NAME = 'SIEBEL REPOSITORY') AND (LSTCOLSTR.REPOSITORY_ID IS NULL OR LSTCOLSTR.REPOSITORY_ID = (SELECT ROW_ID FROM SIEBEL.S_REPOSITORY WHERE NAME = 'SIEBEL REPOSITORY')) AND (LSTCOLOVR.REPOSITORY_ID IS NULL OR LSTCOLOVR.REPOSITORY_ID = (SELECT ROW_ID FROM SIEBEL.S_REPOSITORY WHERE NAME = 'SIEBEL REPOSITORY')) AND BC.REPOSITORY_ID = (SELECT ROW_ID FROM SIEBEL.S_REPOSITORY 3

WHERE NAME = 'SIEBEL REPOSITORY') AND (FLD.REPOSITORY_ID IS NULL OR FLD.REPOSITORY_ID = (SELECT ROW_ID FROM SIEBEL.S_REPOSITORY WHERE NAME = 'SIEBEL REPOSITORY')) AND (PICK.REPOSITORY_ID IS NULL OR PICK.REPOSITORY_ID = (SELECT ROW_ID FROM SIEBEL.S_REPOSITORY WHERE NAME = 'SIEBEL REPOSITORY')) AND APP.NAME LIKE :APPLET_NAME) WHERE LOWER (CAPTION) LIKE :CAPTION; /*****************************************************************/ /* Vyhledání spojení mezi dvěma tabulkami v databázi Siebel CRM */ /* alternativou je aplikace Siebel Tools */ /* vazby mezi tabulkami v datovém modelu Siebel CRM jsou */ /* udržovány dynamicky v Siebel Repository */ /*****************************************************************/ SELECT DISTINCT BC.TABLE_NAME BASE_TABLE, NVL (F.JOIN_NAME, BC.TABLE_NAME) SOURCE_TABLE, F.COL_NAME, J.DEST_TBL_NAME, JS.DEST_COL_NAME, J.NAME JOIN_NAME, JS.SRC_FLD_NAME FROM SIEBEL.S_REPOSITORY R, SIEBEL.S_BUSCOMP BC, SIEBEL.S_JOIN J, SIEBEL.S_JOIN_SPEC JS, SIEBEL.S_FIELD F, SIEBEL.S_TABLE T, SIEBEL.S_COLUMN C WHERE R.INACTIVE_FLG IS NULL AND BC.INACTIVE_FLG != 'Y' AND J.INACTIVE_FLG != 'Y' AND JS.INACTIVE_FLG != 'Y' AND F.INACTIVE_FLG != 'Y' AND R.ROW_ID = BC.REPOSITORY_ID AND BC.ROW_ID = J.BUSCOMP_ID AND J.ROW_ID = JS.JOIN_ID AND F.BUSCOMP_ID = BC.ROW_ID AND ( JS.SRC_FLD_NAME = F.NAME OR (JS.SRC_FLD_NAME IS NULL AND F.COL_NAME = 'ROW_ID') OR (JS.SRC_FLD_NAME = 'ID' AND F.COL_NAME = 'ROW_ID')) AND ( (BC.TABLE_NAME LIKE :SOURCE_TABLE AND F.JOIN_NAME IS NULL) OR (BC.TABLE_NAME != F.JOIN_NAME AND F.JOIN_NAME LIKE :SOURCE_TABLE)) AND J.DEST_TBL_NAME LIKE :DESTINATION_TABLE AND F.COL_NAME IS NOT NULL AND NVL (F.JOIN_NAME, BC.TABLE_NAME) = T.NAME AND T.ROW_ID = C.TBL_ID AND C.NAME = F.COL_NAME ORDER BY SOURCE_TABLE, DEST_TBL_NAME, COL_NAME, DEST_COL_NAME;

4

Vytvoření datového skladu

Recommend Documents