Bankovní institut vysoká škola Praha Katedra matematiky, statistiky a informačních technologií
Návrh a implementace business intelligence řešení Diplomová práce
Autor:
Bc. Tomáš Kocábek Informační technologie a management
Vedoucí práce:
Praha
Ing. Michal Valenta, Ph.D.
Duben, 2012
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 16.04.2012
Bc. Tomáš Kocábek
Poděkování Rád bych poděkoval vedoucímu této práce Ing. Michalu Valentovi, Ph.D. za cenné připomínky a konzultace. Dále můj vděk patří zaměstnavateli, České národní bance, za umožnění studia. V neposlední řadě bych rád poděkoval své rodině za neutuchající podporu a trpělivost. Tomáš Kocábek
Anotace Tato diplomová práce si klade za cíl uvést problematiku Business Intelligence (BI) a ukázat, jak může být využito BI řešení v tak specifické činnosti jakou je sestavování platební bilance a investiční pozice České republiky v České národní bance. Význam této práce spočívá v poskytnutí všeobecného přehledu v oblasti BI a v řešeném příkladě. Tento příklad, doplněný o vlastní zkušenosti, rady a postřehy, ukazuje na možný způsob tvorby BI úlohy postavené na platformě Oracle business intelligence (OBIEE). První teoretická část této diplomová práce je věnována problematice BI a představení současných BI nástrojů s důrazem na platformu OBIEE. Druhá praktická část je věnována příkladu návrhu, implementace a nasazení BI řešení na platformě OBIEE v prostředí České národní banky. Klíčová slova: Business Intelligence, Česká národní banka, platební bilance, investiční pozice, Oracle business intelligence.
Annotation This thesis aims to introduce the issue of Business Intelligence (BI) and to show how it can be used in the specific activities such as compiling balance of payments and international investment position of the Czech Republic to the Czech National Bank. The importance of this work is to provide a general overview of BI and solved example. This example, together with my own experience, advice and observations, shows a possible way to create task of BI based on Oracle Business Intelligence (OBIEE). The first theoretical part of this thesis is dedicated to the performance of BI and current BI tools with an emphasis on OBIEE platform. The second part is devoted to a practical example of design, implementation and deployment of BI solutions on OBIEE platform in the Czech National Bank. Klíčová slova: Business Intelligence, Czech National Bank, balance of payments, international investment position, Oracle Business Intelligence.
Obsah Úvod ........................................................................................................................................... 7 1
2
3
Business intelligence ......................................................................................................... 8 1.1
Metody zpracování ..................................................................................................... 8
1.2
Vymezení pojmu ........................................................................................................ 8
1.3
Historie a vývoj BI ................................................................................................... 10
1.4
Architektura BI ......................................................................................................... 12
1.5
Budoucnost BI .......................................................................................................... 13
Platformy a nástroje pro BI........................................................................................... 15 2.1
SAP ........................................................................................................................... 17
2.2
SAS ........................................................................................................................... 19
2.3
IBM........................................................................................................................... 20
2.4
Microsoft .................................................................................................................. 22
2.5
MicroStrategy ........................................................................................................... 24
2.6
Oracle ....................................................................................................................... 26
2.6.1
BI SERVER ....................................................................................................... 27
2.6.2
BI ANSWERS .................................................................................................... 30
2.6.3
BI DELIVERS ................................................................................................... 31
2.6.4
BI INTERACTIVE DASHBOARDS .................................................................. 33
2.6.5
BI PUBLISHER ................................................................................................ 33
Návrh a implementace BI řešení ................................................................................... 35 3.1
Úvod do problematiky řešeného příkladu ................................................................ 35
3.1.1
Informační prostředí ČNB ................................................................................ 35
3.1.2
Platební bilance ................................................................................................ 40
3.1.3
Investiční pozice ............................................................................................... 42
3.2
Předběžná studie řešeného příkladu ......................................................................... 42
3.2.1
Uživatelské zadání IS UNIZBIP ...................................................................... 43
3.2.2
Studie proveditelnosti ....................................................................................... 45
3.3
Shrnutí základních funkčních požadavků ................................................................. 48
3.4
Postup řešení ............................................................................................................. 50
3.4.1
UML .................................................................................................................. 51
3.4.2
Návrh řešení modulu FD .................................................................................. 53
3.4.3
Návrh datové struktury ..................................................................................... 57 5
4
5
3.4.4
Příprava metadat BI Serveru............................................................................ 62
3.4.5
Tvorba sestav .................................................................................................... 72
3.4.6
Tvorba interaktivních panelů ........................................................................... 78
Nasazení BI řešení .......................................................................................................... 80 4.1
Prostředí OBIEE ....................................................................................................... 81
4.2
Řízení přístupových práv .......................................................................................... 83
Výsledky .......................................................................................................................... 85
Závěr ........................................................................................................................................ 86 Seznam použité literatury ...................................................................................................... 87 Seznam zkratek ....................................................................................................................... 90 Příloha č. 1 ............................................................................................................................... 94 Příloha č. 2 ............................................................................................................................... 96 Příloha č. 3 ............................................................................................................................... 97 Příloha č. 4 ............................................................................................................................... 99
6
Úvod V dnešním hektickém, daty a informační technologií zahlceném světě je pro každý (nejen velký) podnik prakticky nezbytné zajistit spolehlivý, bezpečný sběr všech relevantních dat a jejich následné uložení. Tato data je pak třeba podrobit komplexní analýze, vytvořit predikce a náležitě prezentovat. Společnost, která toto opomene či se tomu dostatečně nevěnuje, nemá v dnešním globálním světě šanci dlouhodobě uspět. Tato komplexní práce s daty vyžaduje moderní platformy, nástroje a specializované přístupy souhrnně označované jako Business Intelligence (BI). Ačkoliv se může zdát, že jde o velice komplikovanou a složitou věc, při bližším pohledu tomu tak není a tato diplomová práce si, mimo jiné, klade za cíl dostatečně osvětlit pojem BI tak, aby byl srozumitelný široké veřejnosti. Na jedné straně se sice pod pojmem BI skrývají výkonné analytické a prezentační nástroje, které slouží pro vyhodnocení historických nebo aktuálních dat a predikci budoucího vývoje dané firmy či trhu. Na straně druhé však BI nepředstavuje pouze sofistikované systémy pro podporu rozhodování, ale zahrnuje i nástroje se kterými se setkal prakticky každý uživatel osobního počítače jako například aplikaci MS Excel z kancelářského balíku MS Office. Kromě toho se většina koncových BI nástrojů vyznačuje značnou uživatelskou přívětivostí a intuitivností bez nutnosti hlubších znalostí dotazovacích, značkovacích či dokonce programovacích jazyků. Na různá BI řešení ostatně narážíme prakticky každý den. Dokonce je všichni používáme. Každá návštěva internetového obchodu znamená použití uživatelského rozhraní, různých statistik, přehledů a hodnocení výrobků a služeb, které jsou samozřejmě součástí rozsáhlého BI řešení. Jen si to na první pohled neuvědomujeme. V rámci této diplomové práce uvedu stručný přehled vývoje BI. Představím současné nejrozšířenější produkty. Speciálně se zaměřím na firmu Oracle a její platformu a nástroje, neboť s ní mám největší osobní zkušenosti a zároveň se domnívám, že v současné době BI nástroje této firmy patří mezi nejlepší produkty v této oblasti. Největší prostor pak věnuji vlastnímu BI řešení (od návrhu, přes implementaci až po nasazení) postavenému na platformě OBIEE. Tato praktická úloha ukáže, jakým způsobem lze využít BI řešení i pro tak specifickou činnost jakou je sestavování platební bilance a investiční pozice České republiky.
7
1 Business intelligence 1.1 Metody zpracování Tato diplomová práce je rozdělena do dvou základních částí. Části teoretické (kapitoly 1 – 2) a části praktické (kapitoly 3 - 4). Na volbu níže uvedených metod a nástrojů, použitých při zpracování praktické části, měla velký vliv má osobní zkušenost s jejich využitím. Nemenší roli pak hrál ten fakt, že příklad je řešen pro potřeby ČNB a tudíž je vhodné a žádoucí použít její standardní postupy a nástroje pro rozvoj IS/IT. Teoretická část Při zpracování této části diplomové práce jsem využil potřebné dostupné zdroje, ať už tištěné či elektronické. Zároveň jsem čerpal ze svých dlouholetých teoretických i praktických znalostí zpracovávané problematiky. Praktická část V praktické části této diplomové práce je zpracováván příklad tvorby BI úlohy. Při jeho zpracování jsem použil následující metody, postupy a nástroje: -
metodické pokyny ČNB č. 62 ze dne 3.2.2010 „O rozvoji informačních systémů a informačních technologií v České národní bance“,
-
jazyk UML pro konstrukci potřebných modelů (detailněji popsán v kapitole 3.4.1),
-
CASE nástroj „Enterprise Architect“ pro tvorbu modelů a komplexní řízení vývoje,
-
a pro tvorba metadat modelu BI Serveru, sestav a panelu jsem použil příslušné BI nástroje OBIEE.
1.2 Vymezení pojmu Než přistoupíme k vlastnímu rozboru vývoje Business Intelligence (BI), osvětlíme si samotný pojem. Co termín business intelligence vlastně znamená, jaká je jeho definice a zda má tento termín český ekvivalent. V prvé řadě je třeba říci, že čeština pro tento termín nenašla (dosud) odpovídající výstižný překlad a tak se toto slovní spojení používá ve své anglické (původní) podobě a toho se přidrží i tato diplomová práce.
8
Co se týče samotné definice pojmu business intelligence, zde situace není jednoznačná. I přes skutečnost, že významem se nejuznávanější výklady tohoto pojmu výrazněji neliší, jednotná všeobecně uznávaná definice neexistuje. Mezi nejfrekventovanější definice patří: -
definice z „The Data Warehousing Institute“, jenž lze přeložit: Business intelligence sjednocuje data, technologie, analytiku a lidské znalosti za účelem optimalizace obchodní rozhodnutí pro konečné dosažení podnikového úspěchu. BI programy obvykle kombinují podnikové datové sklady a BI platformu či sadu nástrojů za účelem transformovat data do využitelných obchodních informací [17],
-
další významná definice pochází od společnosti Gartner, Inc., opět volně přeloženo: Business intelligence je zastřešující pojem, který zahrnuje aplikace, infrastrukturu, nástroje a nejlepší postupy, jenž umožňují přístup k informacím a jejich analýzu za účelem zlepšit a optimalizovat rozhodování a výkonnost [15],
-
poslední charakteristika BI, o které se zde zmíním, popisuje Business Intelligence jako sadu procesů, aplikací a technologií, jenž jsou postaveny na multidimenzionálním pohledu na podniková data a podporují rozhodovací, analytické a plánovací činnosti v podniku [04].
Z výše uvedených definic je patrné, že každá z nich klade důraz na trochu jiné aspekty BI, což je jedním z hlavních důvodů proč neexistuje jednotná definice pro tento pojem. Nicméně si myslím, že všichni chápou BI jako soubor technik, metod a nástrojů, které v kombinaci s velkým objemem kvalitních dat, poskytují podporu pro řídící činnosti podniku. Ke každému smysluplnému rozhodnutí bylo, je a bude třeba, co nejvíce kvalitních dat, které musíme určitými způsoby získat. Tato data pak bezpečně uchovávat. Dále je analyzovat, prezentovat a na základě uskutečněných analýz a rozborů se řádným způsobem rozhodnout. Pokud ovšem nebudeme BI nástroje a postupy spojovat pouze s rozvojem výpočetní techniky, ale naopak s jejich účelem, mám za to, že jejich potřeba a používání je stará jako lidstvo samo. V každém historické období existovaly nejlepší možné dostupné techniky, postupy a metody, které zajistily sběr, uchování, zpracování a prezentaci relevantních dat a informací potřebných pro rozhodování. Až teprve s rozvojem výpočetní techniky v druhé polovině 20. století došlo ke sjednocení všech těchto technik, postupů a nástrojů, sloužících k podpoře rozhodování, pod souhrnný termín BI.
9
1.3 Historie a vývoj BI Termín BI zpopularizoval pracovník konzultační společnosti Gartner, Inc. Howard J.Dresner. V roce 1989 jej představil jako sadu metod a konceptů pro podporu a zlepšení obchodních procesů rozhodování firem s využitím dostupných datových zdrojů a aplikací. Nicméně stopy termínu BI, v kontextu podpory obchodního rozhodování, lze vysledovat do začátku druhé poloviny minulého století. Historie a vývoj BI jsou pevně spjaty s vývojem v oblastech IT a především pak s rozvojem databázových systémů. Se vznikem prvních informačních systémů a manažerských aplikací v 70. letech 20. století, které poskytovaly jen malý prostor pro implementaci dle individuálních potřeb, se vynořila řada problematických oblastí týkajících se dat: -
rozmístění a verzování dat,
-
jejich špatná dostupnost a absence popisu neboli metadat,
-
velká chybovost a nedostatečná datová transformace.
K řešení těchto problémů se začaly objevovat nástroje, pro které se později začal používat souhrnný název BI. Na vznik a rozvoj relačních databází a unixových systémů navazuje vývoj centrálních datových úložišť – datových skladů (Data Warehouse). Počátek budování datových skladů spadá do 80. let 20. století a za zakladatele je považován William H. Inmonen, který prvně a jasně z formuloval tento termín a popsal jeho architekturu. Datový sklad představuje centrální integrované, stálé a časově rozlišitelné úložiště rozličných firemních dat. Přičemž slovem stálé se rozumí existence dat v datovém skladu, v nezměněné podobě, po celou dobu jeho existence. Termínem časově rozlišitelná data rozumíme taková data, která jsou ukládána v časovém kontextu neboli obsahují časové dimenze. Datový sklad je určen pro analytickou podporu rozhodování a zahrnuje kromě dat i nástroje pro jejich vytažení, analýzu, reporting a data mining neboli dolování dat. [02] Prezentace dat je cílena na management dané firmy a to co uživatelsky nejpřívětivější formou. Rozvoj datových skladů a vznik multidimenzionálního datového modelování má za následek vznik nástrojů na ad-hoc analýzy dat nad databázemi v reálném čase – „On-Line Analytical Processing“ (OLAP). Vlastnosti OLAP nástrojů definoval Edgar T. Codd (též vynálezce relačního modelování) na základě dvanácti pravidel. Avšak pro svoji složitost, kontraverzi a jednostranné zaměření se příliš neujala. Místo toho se používá alternativní popis neboli test
10
„Fast Analysis of Shared Multidimensional Information“ (FASMI), se kterým přišel Nigel Pendse z tehdejšího OLAP reportu (nyní BI Verdict). Na základě tohoto testu označujeme termínem OLAP ty nástroje, které splňují následující vlastnosti [13]: -
FAST – rychlá odezva v řádu několika vteřin.
-
ANALYSIS – podpora relevantních analytických operací dle potřeb uživatele.
-
SHARED – komplexní správa přístupových práv.
-
MULTIDIMENSIONAL – klíčový požadavek. Multidimenzionální pohled na data s plnou podporou vícenásobných hierarchií.
-
INFORMATION – získat z dat potřebné informace. Tento požadavek je nicméně daleko relevantnější pro aplikace než pro nástroje.
S OLAP technologiemi se můžeme v případě řešení databází setkat v několika rozličných podobách. Mezi nejfrekventovanější termíny patří [04]: -
MOLAP (Multidimensional OLAP) – jedná se o uložení dat v multidimenzionálních OLAP kostkách,
-
ROLAP (Relational OLAP) – zajišťuje multidimenzionalitu dat v relačních databázích,
-
HOLAP (Hybrid OLAP) – kombinuje multidimenzionální a relační databáze tím způsobem, že data jsou uložena v relační a agregace v multidimenzionální databázi,
-
DOLAP (Desktop OLAP) – využití nachází především pro mobilní aplikace, kdy uživatelům umožňuje stáhnout si žádanou podmnožinu multidimenzionální kostky na lokální zařízení a následné analytické operace provádět již nad touto lokální kostkou.
Postupem doby, jak rostl objem sbíraných dat a složitost jejich analýz, vznikla potřeba „vytěžení“ ukrytých (přitom však užitečných) informací z obrovského množství sesbíraných dat. Tato potřeba dala vzniknout nástrojům, které tuto problematiku řeší a jsou souhrnně označovány jako Data Mining. Dnes tímto termínem označujeme prakticky všechny nástroje a postupy na zpracování statistických dat, tak aby bylo možné modelovat, předvídat a plánovat vývoj na základě stanovených ukazatelů. [07] Vždy je však třeba mít na paměti, že nezbytným předpokladem úspěšného dolování jsou správná data. V okamžiku kdy se na trhu zabydleli Customer Relationship Management (CRM) systémy a staly se součástí informačního prostředí v podstatě všech větších firem, začali se do nich začleňovat i BI nástroje. Společně tak dokáží lépe poznat, popsat, pochopit a předvídat
11
potřeby či touhy zákazníků a napomáhají tak úspěšnému prosazení a udržení společností na daném trhu. V současné době jsou BI nástroje přítomny v menší či větší míře prakticky ve všech firemních informačních prostředích, bez ohledu na obor podnikání dané společnosti.
1.4 Architektura BI Jak jsem tedy již uvedl, BI je souhrnný pojem, kterým označujeme infrastrukturu, datové sklady, OLAP technologie, analytické nástroje, reportingová a prezentační řešení. Zkrátka vše, co nám umožní rychlý přístup k datům, jejich komplexní analýzu, reporting a prezentaci. Z pohledu architektury viz. obrázek č. 1, pak tedy můžeme rozdělit BI řešení do následujících komponent[14]: -
Zdrojové provozní systémy – tato část zahrnuje veškeré kanály, kterými proudí do daných společností data. Od systémů ERP, CRM, přes vlastní sofistikované sběrné systémy až po prosté excelovské tabulky.
-
Transformační prostředí – zde se jedná o procesy datové transformace. Tyto procesy jsou pro úspěšné vybudování datového skladu klíčové. V rámci Extraction, Transformation and Loading (ETL) procesů, též někdy označovaných termínem datová pumpa, dochází k převádění dat ze zdrojových systémů do cílových struktur. Při transformaci se využívají nejrůznější matematické operace, konverze, normalizace či denormalizace a další. V neposlední řadě se provádí kontrola kvality dat a případně jejich čištění. Jedná se o velmi komplikovaný proces, kterému je třeba věnovat náležitou pozornost. Jeho zanedbání či podcenění může mít fatální vliv na vypovídací schopnost transformovaných dat. V rámci transformačního prostředí můžeme identifikovat rovněž Enterprise Application Integration (EAI) nástroje. Narozdíl od ETL procesů, které pracují v dávkovém režimu, EAI nástroje jsou využívány pro přenos dat v reálném čase. Jejich největší přínos tak spočívá v umožnění bezprostředního využití aktuálních dat prostřednictvím operativních úložišť. [4]
-
Datové prostředí – tady se nacházejí datové sklady a datová tržiště. Zatímco v případě datového skladu se jedná o centrální celopodnikové datové úložiště, pod pojmem datové tržiště, rozumíme tématicky orientované úložiště přizpůsobené informačním potřebám daného útvaru.
12
-
Analytické prostředí – obsahuje komponenty jako jsou OLAP technologie, Data Mining a reportovací nástroje.
-
Klientské aplikace – jedná se především o analytické, prediktivní a vizualizační nástroje. Obrázek č. 1: Architektura BI
Zdroj: http://www.daquas.cz/articles/379-seznamte-se-s-bi [14] Závěrem můžeme říci, že architektura BI je značně rozsáhlá, byť ne komplikovaná. Největší pozornost musíme, z logiky věci, věnovat návrhu ETL procesů a kompatibilitě BI prostředí s existujícími zdrojovými a produkčními systémy. Kvalitní návrh architektury BI nám v budoucnu uspoří čas, finančních prostředky a v neposlední řadě umožní snadnou implementaci nových komponent.
1.5 Budoucnost BI Rozvoj BI nástrojů jde ruku v ruce s vývojem informačních technologií. I přes současnou absenci skutečně vizionářského řešení, trh s BI nástroji rozhodně není strnulý. Velkým rozvojem procházejí nejrůznější mobilní aplikace, Cloud BI, pokročilá vizualizace a především koncept BI 2.0. Cloud BI Toto označení se užívá pro BI, kde poskytovatelé nabízejí infrastrukturu a software pro Cloud BI prostředí a kde zákazníci platí pouze za využití této služby předem dohodnuté poplatky. 13
Firmy, jenž využívají této služby, tak nejsou nuceni implementovat BI do svého informačního prostředí. Zároveň odpadá potřeba vysoce specializované a málo frekventované činnosti, jakou je konfigurace a nasazení BI pro velké množství uživatelů. Na straně druhé však přetrvá ze stran zákazníka obava o ztrátě kontroly nad daty, jejich zabezpečením a pochybnost o výhodnosti tohoto řešení oproti „klasické“ implementaci BI. S rozptýlením těchto obav čeká poskytovatele BI ještě mnoho práce. Stejně tak jako s uvedením Cloud BI v široké povědomí a to dokonce i u BI profesionálů. [11] BI 2.0 Můžeme si pod tím představit sofistikovaný přístup k datové správě a datové architektuře, která povede k vytvoření robustní platformy, jenž nám umožní soustředit se na budoucnost. Hlavním cílem je analýza a řízení budoucnosti. Závěry učiněné na základě hypotéz z historických dat, aplikujeme na současnost a vytvoříme prediktivní analýzy. Ty nám posléze poslouží v řízení budoucnosti. Předpokladem je sběr dat v reálném čase a schopnost systémů pojímat velké objemy dat do hlavní paměti, což zajistí jak rychlou bezprostřední analýzu, tak odpovídající reakci. Mezi základní charakteristiky konceptu BI 2.0 patří provádění prediktivních analýz v reálném čase, současné zaměření na atomická i agregovaná data, orientace na budoucnost, procesy a škálovatelnost. [23]
14
2 Platformy a nástroje pro BI O stavu na poli BI si uděláme nejlepší představu ze šetření společnosti Gartner, Inc., která každý rok vydává studii jenž mapuje tento trh a uvádí jednotlivé poskytovatele BI. Přehledně rozebírá sílu jejich produktů a případná úskalí, jimž musí čelit. Gartner, Inc. je společnost zabývající se analýzou, výzkumem a poradenstvím
v oblasti
informačních technologií. Pro vizualizaci závěrů svých šetření, nejen v oblasti BI, využívá magický kvadrant (Magic Quadrant). Jedná se o její vlastní nástroj, který ukazuje postavení jednotlivých firem na daném trhu v závislosti na použitých hodnotících kritérií a který se pro tuto oblast zpracovává a uveřejňuje každý rok. Na obrázku č. 2 je zachycen nejaktuálnější magický kvadrant pro BI. Obrázek č. 2: Gartner‘s 2012 Magic Quadrant for BI
Zdroj: Magic Quadrant for Business Intelligence Platforms [10] Jednotliví poskytovatelé BI jsou rozděleni do čtyř čtverců, které ukazují na jejich postavení na trhu. Toto rozdělení je provedeno na základě dvou kritérií a sice připravenosti k růstu (ability to exekute) a úplnosti vize (completeness of vision). Pro každé kritérium se používají rozdílné
15
kvalifikátory s rozdílnou váhou v závislosti na daném odvětví, pro který je magický kvadrant zpracováván. Pro úplnost si zde uvedeme stručnou charakteristiku jednotlivých čtverců [10]: -
lídři (leaders) – jedná se o firmy, jenž jsou silné v obou hodnotících kritérií. Společnosti zde uvedené do jisté míry určují, jakým směrem se bude trh ubírat a na jaké oblasti se bude soustředit,
-
vyzyvatelé (challangers) – zde jsou soustředěny firmy, které mají velký potenciál růstu. Nicméně jsou do jisté míry omezovány způsoby užití či technickým prostředím. Nedostatek vize může být zapříčiněn chybějící strategií koordinace produktů v jejich BI portfoliu,
-
niche players – pro tento čtverec nelze použít jednoslovný český ekvivalent. Nejlépe se hodí popis, že společnosti zde uvedené se snaží zaplnit mezeru na daném trhu. Specializují se na jeden, dva konkrétní segmenty, které se snaží dokonale pokrýt a mají samozřejmě omezené možnosti komplexně pokrýt BI potřeby svých zákazníků,
-
vizionáři (visionaries) – jedná se o společnosti, jenž mají velkou vizi, jakým způsobem rozvíjet a dodávat svoji BI platformu. Jejich architektury jsou dostatečně flexibilní a nabízejí širokou paletu funkcionalit v oblasti, kterou se snaží rozvíjet. Jejich nevýhodou může být počáteční malé povědomí o jejich produktech u potencionálních zákazníků a míra důvěry v jejich funkčnost.
Pokud se podíváme zpět na jednotlivá roční šetření společnosti Gartner, Inc. pro oblast BI zjistíme, že tento vcelku ještě mladý trh procházel a stále prochází poměrně bouřlivým vývojem a konsolidací. Mezi lídry na trhu se postupně dostali prakticky všechny velké softwarové firmy. Někteří vývojem vlastních BI produktů, jiní akvizicemi tehdejších úspěšných firem. Následující přehled existujících BI nástrojů proto není v žádném případě úplný. Cílem tohoto výčtu je především v krátkosti představit nástroje největších hráčů na trhu BI. Podrobněji si však rozebereme jednotlivé BI nástroje firmy Oracle. Důvodem je jednak značná osobní zkušenost s těmito nástroji a taktéž fakt, že s jejich pomocí je řešen příklad ve druhé části této diplomové práce.
16
2.1 SAP Společnost SAP – zkratka vzniklá ze Systeme, Anwendungen, Produkte in der Datenverarbeitung, patří mezi největší softwarové společnosti a v oblasti ERP1 zaujímá na trhu dominantní postavení. SAP nabízí řešení jak pro velké společnosti, tak pro společnosti malé a střední. Všechny SAP aplikace využívají jednotnou technologickou základnu SAP NetWeaver. Tato platforma vznikla v roce 2003 a je postavena na otevřených standardech s cíle spolupracovat se stávající IT infrastrukturou daného podniku. Obsahuje technologické prostředky pro datovou, procesní a uživatelskou integraci. Samozřejmostí je spolupráce s ostatními všeobecně používanými platformami jako Java 2 Enterprise Edition (J2EE), Microsoft .NET a IBM WebSphere. [03] Obrázek č. 3: SAP BusinessObjects BI
Zdroj: http://en.sap.info/sapphire_business_intelligence/32326 [32] Po převzetí společnosti Business Object, na začátku roku 2008, došlo k rozšíření a přepracování portfolia BI nástrojů. Stávající nástroje byly především doplněny o oblast podpory řízení a operativního rozhodování. V současné době jsou BI nástroje seskupeny
1
Enterprise resource planning můžeme charakterizovat jako informační systém, jenž má za cíl integrovat a automatizovat podnikové produkční procesy od výroby a logistiky přes prodej až po účetnictví.
17
do souhrnného balíku SAP BusinessObjects, který je možné nakonfigurovat dle potřeb a možností dané firmy. Pro velké firmy je standardně k dispozici SAP BusinessObjects business intelligence solutions, která nabízí kompletní sadu BI nástrojů pokrývající následující oblasti [33]: -
oblast analytická a publikační – zde se nacházejí nástroje umožňující analytickou práci nad daty uloženými v rozličných zdrojích, vytváření koncových sestav a jejich publikování, o SAP BusinessObjects Analysis, edition for Microsoft – pro komplexní analýzy dat v prostředím MS Office, o SAP BusinessObjects Web Intelligence – pro ad hoc analýzy z online i offline zdrojů, o SAP Crystal reports – slouží k tvorbě, analýze a prezentaci sestav, přičemž sestavy lze sdílet interně i externě, o SAP
BusinessObjects
Analysis,
edition
for
OLAP
–
pro
analýzy
multidimenzionálních dat s využitím OLAP nástrojů, o SAP BusinessObjects Predictive Workbench – analýzy vytvářené pomocí tohoto nástroje slouží k sestavování predikcí, -
oblast panelů (dashboards) – slouží k vytváření přehledových panelů neboli dashboards. Obecně je jednou z nejvděčnějších a nejpoužívanějších funkcionalit BI nástrojů. Dobře vytvořený panel dokáže svým uživatelům rychle a přehledně poskytnout žádané informace, o SAP BusinessObjects Dashboards - nástroj pro tvorbu panelů,
-
průzkum dat – tato oblast pokrývá nástroje, s jejichž pomocí lze rychle a účinně vyhledat a analyzovat požadovaná data, o SAP BusinessObjects Explorer – si můžeme představit jako určitého průzkumníka fungujícího na bází internetového prohlížeče. Umožní rychle data nalézt pro okamžitý náhled,
-
mobilní zařízení – zde se nachází nástroje pro přístup a práci s daty z mobilních zařízení, o SAP BusinessObjects Mobile – zajistí přístup k datům, metrikám a sestavám přes mobilní zařízení, o SAP Event Insight – zajistí předání upozornění na mobilní zařízení při změně sledovaných dat. 18
Pro malé a střední podniky společnost SAP připravila ze svých BI nástrojů následující řešení [34]: -
SAP Crystal – je určen pro malé společnosti do 1000 zaměstnanců a obsahuje nástroje pro ad hoc analýzu dat, vytváření sestav a panelů,
-
SAP BusinessObjects BI Ondemand – jedná se o rychlé řešení pro společnosti do cca 5000 zaměstnanců a poskytuje vyvážené portfolio BI nástrojů zajišťující nepřetržitý dohled,
-
SAP BusinessObjects Edge – toto řešení v sobě zahrnuje většinu BI nástrojů a poskytuje tak komplexní BI řešení pro podniky do 2500 zaměstnanců.
2.2 SAS Společnost SAS Institute Inc., založena v roce 1976, je největší soukromě vlastněnou společností na světě. Zaměřuje se především na velké zákazníky, pro které dodává komplexní řešení pro podporu řízení organizace včetně ucelených metodik nasazení pro rozličné obory podnikání. [29] Prakticky od začátku patřila k největším a nejlepším firmám v oblasti BI a v současné době zůstává spolu s firmou MicroStrategy jediným „čistokrevným“ dodavatelem BI řešení mezi leadery na tomto trhu. Síla řešení od firmy SAS spočívá v jeho ucelenosti a komplexnosti. Tato řešení jsou navíc optimalizovaná napříč odvětvími od telekomunikací přes bankovnictví až po zdravotnictví. Základem řešení je integrovaná inteligentní platforma Enterprise Intelligence Platform. Business Intelligence pak tvoří jednu ze základních komponent této moderní a na standardech založené otevřené platformy. Pro úspěšně implementované BI řešení je nezbytným předpokladem sběr, čištění a zajištění kvality všech potřebných zdrojových dat. Proto nás nepřekvapí skutečnost, že mezi hlavní části platformy rovněž patří komponenty pro datovou integraci a řízení kvality dat. Samotné BI nástroje pro velké společnosti od firmy SAS můžeme členit na dvě části[31]: -
SAS Enterprise BI Server – jedná se o uživatelsky přívětivé softwarové řešení, které integruje správu dat s analytickými nástroji a tím poskytuje možnost získat všechna potřebná data a informace k učinění správného rozhodnutí. Mezi základní prvky především patří [16]: o tvorba sestav, panelů (dashboards) a jejich distribuce, o vizualizace skrze mobilní zařízení, o provázání s aplikacemi MS Office, 19
o podpora OLAP technologie, o řízení metadat, o tvorba aplikací pomocí nástroje SAS AppDev Studio. -
Business Visualization – pokročilá datová vizualizace. Umožňuje uživatelům, prostřednictvím rozsáhlé interaktivní práce s dotazy, zjistit skryté informace a tím pádem učinit nové závěry a rozhodnutí. K vizualizaci slouží, mimo jiné, nepřeberné množství grafů. Například „Bubble/XY plots“ poskytující kvantitativní měřítka na dvou osách s možností pro třetí.
Pro střední firmy pak SAS nabízí, s ohledem na náklady, optimalizované BI řešení „SAS Business Intelligence for Midsize Business“, které nabízí všechny potřebné základní funkce BI nástrojů (panely, analýzy, sestavy, správu metadat a propojení s MS Office).
2.3 IBM Firmu IBM můžeme bez nadsázky označit za jednu z nejstarších a nejvýznamnějších firem působících v oblasti IT. Z platformy jejího počítače IBM PC, uvedeného na trh v roce 1981, se brzy stal celosvětový standard. V současné době, vzhledem k velké konkurenci levných producentů, IBM již počítače nevyrábí. Místo toho se zaměřuje na realizaci serverových řešení či ukládání dat a s tím spojených outsourcingových služeb. Na trhu s BI produkty nehrála IBM zpočátku výraznější roli a její nabídka spočívala zejména v oblasti databázových systémů DB2. Teprve až v roce 2007 se dostala mezi největší hráče na tomto trhu. Nebylo to však způsobeno tím, že by IBM přišla s nějakým vlastním inovátorským BI řešením, ale pomocí daleko jednoduššího postupu a to koupením kanadské firmy Cognos. Firma Cognos totiž nebyla nějakou firmou na okraji působnosti, ale středně velkou patřící k těm nejlepším. Tato akvizice je názorným příkladem toho, jak je dnes těžké pro středně velké, byť úspěšné, společnosti samostatně přežít. Nicméně, především díky své pověsti, se BI produkty u firmy IBM stále rozvíjejí a nabízejí pod svojí původní značkou Cognos. V současné době se nabídka nástrojů pro datové sklady a BI od firmy IBM nachází ve dvou typových řadách. -
Cognos – jedná se o platformu, která nabízí celou řadu modulů, pomocí kterých můžeme pracovat (integrovat, analyzovat, reportovat) se všemi dostupnými a relevantními daty dané společnosti. Předností je zejména velká a snadná škálovatelnost, která umožňuje zpočátku implementovat základní sadu BI nástrojů a
20
postupně ji, dle potřeby, rozšiřovat až do komplexního řešení. Jedná se především o tyto nástroje[18]: o Cognos 8 Business Intelligence – základní nástroj vystavěný na architektuře SOA. Pokrývá veškerou hlavní funkcionalitu BI, jako je tvorba sestav a panelu (dashboards), vyhodnocování či analýzy. Implementací dalších modulů můžeme funkcionalitu dále rozšiřovat. Mezi nejdůležitější lze zařadit následující moduly:
Cognos 8 Go! Mobile – slouží k propojení s mobilními zařízeními, kterým dodává vytvořené sestavy a panely. Mezi podporované platformy patří BlackBerry, Simbian S60 a Windows Mobile,
Cognos 8 Go! Office – jeho implementací získáme možnost pracovat s výstupy v softwarových nástrojích kancelářského balíku MS Office (Excel, Word či PowerPoint),
Cognos 8 Go! Search – začlenění výstupů do podnikových vyhledávačů například IBM OmniFind a tím usnadnit vyhledávání potřebných informací dle zadaných klíčových slov,
Cognos 8
Workforce Performance – aplikace pro útvary lidských
zdrojů, o Cognos Now! – jedná se o nástroj pro on-line sledování provozních metrik a indikátorů výkonu závislých na čase, o Cognos TM1 – nástroj pro podnikové plánování, -
Infosphere – nástroje pro datové sklady, integraci informací a datové analýzy. V této řadě se jedná především o [19]: o Infosphere Warehouse – datový sklad pro strukturovaná, nestrukturovaná, statická či transakční data, o InfoSphere Master Data Management Server – slouží ke správě účetních, zákaznických a produktových dat, o InfoSphere Information Server – datová integrační platforma pro získání porozumění a distribuci informací, jež jsou pro potřeby příslušné společnosti klíčové.
21
2.4 Microsoft Microsoft je jednou z nejvýznamnějších IT společností, jenž dlouhou dobu určovala a do jisté míry stále určuje trend u operačních systémů pracovních stanic a balíků kancelářských nástrojů. Má široké pole působnosti od hardwaru přes software až po herní konzole. V současné době je BI řešení od Microsoftu postavené na platformě Microsoft SQL Server, s využitím všeobecně známého a používaného kancelářského softwaru Microsoft Office a produktem Microsoft SharePoint Server pro sdílení a spolupráci mezi uživateli. Všechny části BI
řešení
procházejí
neustálým
vývojem
a
v současné
době
hovoříme
o verzích: Microsoft SQL Server 2008 R2 (nicméně již je k dispozici verze Microsoft SQL Server 2012), Microsoft SharePoint Server 2010 a Microsoft Office 2010. Obrázek č. 4: Microsoft BI
Zdroj: http://www.element61.be/e/resourc-detail.asp?ResourceId=59 [24] -
Microsoft SQL Server – jedná se o výkonný databázový systém, který tvoří datovou platformu pro Microsoft BI. Jeho prostřednictvím můžeme pracovat jak s daty vlastních aplikací vytvořených v Microsoft.NET či Visual Studiu, tak s daty ze SOA. S použitím serveru Microsoft Biz Talk Server můžeme rovněž využít data obchodních procesů. Součástí SQL Serveru jsou takzvaná studia „SQL Server Management Studio“ a „Business Intelligence Development Studio“. Tyto studia obsahují nástroje pro řízení integračních procesů, správu reportingových serverů, datovou analýzu a
22
vytváření sestav. SQL Server rovněž obsahuje doplňky pro dolování dat, jenž napomáhají analyzovat rozsáhlé datové objemy, predikovat vývoj a tyto trendy graficky znázornit. V neposlední řadě je v SQL Serveru implementována knihovna komponent sestav, která umožňuje vývojářům a pokročilým uživatelům nadefinovat nejrůznější pohledy nad daty a vytvářet grafy. Takto připravené komponenty jsou uloženy v knihovně a poskytnuty všem uživatelům pro rychlou vlastní tvorbu výsledných sestav. [26] -
Microsoft SharePoint Server představuje ucelenou sadu serverových nástrojů, nebo-li platformu. Tato integrovaná sada funkcí a nástrojů pomáhá dosáhnout lepší spolupráce v rámci celé organizace prostřednictvím sdílených dat a informací. Lze říci, že namísto používání samostatných podnikových systémů umožňuje integrovat podnikové webové, intranetové a extranetové aplikace do jedné platformy. Kromě toho správcům poskytuje nástroje pro správu jak obsahu, tak i samotného serveru a vývojářům umožňuje tvorbu podnikových aplikací. [25] Dále Microsoft SharePoint Server umožňuje: o prostřednictvím
komponenty
„Dokument
Management
System“
řídit
souborový systém na společném disku, o vytvářet diskusní skupiny a znalostní databáze, o spolupracovat s podnikovými ERP a CRM systémy, o a v neposlední řadě poskytuje širokou paletu nástrojů pro datovou analýzu. -
Microsoft Office – jednotlivé nástroje všeobecně známého a používaného kancelářského balíku jsou ve větší či menší míře provázány s Microsoft SharePoint Serverem a umožňují tak uživatelům využít možnosti, které SharePoint Server nabízí, aniž by se museli vzdát známých softwarů. Technologie Backstage, která je implementována do jednotlivých nástrojů MS Office, dovoluje uživatelům, prostřednictvím jednotlivých aplikací, pohodlně spravovat sdílené dokumenty uložené na SharePoint Serveru. Za hlavní aplikaci pro BI je zde považován MS Excel, který nabízí množství nástrojů pro analýzu a vizualizaci dat. Například vedle známých kontingenčních tabulek jsou k dispozici takzvané průřezy pro analýzy velkých datových objemů a predikce jejich budoucího vývoje. [25] Mezi implementované funkcionality dalších aplikací MS Office mimo jiné patří: o synchronizace kalendářů a podpora RSS zpráv v MS Outlook,
23
o zadávání metadat a možnost úpravy stejného dokumentu více uživateli v jeden okamžik v MS Word, o sdílená knihovna snímků a prezentací na lokalitě SharePoint v MS PowerPoint, o využití aplikací vytvořených MS Access v SharePointu pomocí služby Access Services. Závěrem je třeba podotknout, že Microsoft má svoji největší základnu mezi malými až menšími uživateli. Své BI řešení tudíž koncipoval s ohledem na finanční možnosti svých hlavních zákazníků. Posledním vývojem, především v oblasti SQL Serveru, se však Microsoft snaží výrazněji proniknout i na trh s BI produkty pro střední a velké firmy.
2.5 MicroStrategy Společnost MicroStrategy byla založena v roce 1989 v USA. Původně se věnovala multidimenzionálnímu modelování a simulacím, později se zaměřila na software pro data mining. V současné době patří mezi nejpřednější poskytovatele komplexních BI řešení. Dle již zmiňovaného výzkumu společnosti Gartner, Inc. zaujímá MicroStrategy druhé místo mezi všemi prodejci BI. Tohoto výsledku společnost dosáhla zejména díky vysokému stupni integrace individuálních komponent a opětovné využitelnosti dobře navržené objektově orientované sémantické vrstvy. [10] Současné BI řešení MicroStrategy 9 je postaveno na relační architektuře OLAP (ROLAP). Tato technologie je vystavěna na virtuální kostce představující celou relační databázi a zajišťující velkou škálovatelnost a interaktivitu. Metadata ROLAP modelují kompletní relační databázi
v jeden
logický
multidimenzionální
model
firmy.
Webová
architektura
MicroStrategy 9 podporuje 64bitové moduly JVM a Extreme AJAX kódování, což umožňuje současnou práci mnoha uživatelů při zachování krátké doby odezvy. BI nástroje firmy MicroStrategy lze rozdělených do tří základních skupin.[27] Nástroje pro vývoj -
Desktop – pro přístup k datům na osobním počítači skrze integrované vývojové BI prostředí,
-
Architekt – tvorba metadat modelů,
-
Software development kit (SDK) – zajišťuje integraci BI platformy s podnikovými systémy,
24
-
MultiSource option – umožňuje analyzovat a reportovat data z více zdrojů v rámci jednotného podnikového modelu,
-
Transaction services – podpora komunikace s aplikacemi pro mobilní zařízení. Mimo jiné dovoluje zápis do dokumentů a dashboards skrze tato zařízení.
Nástroje pro řízení a nasazení -
Intelligence server – škálovatelný, bezpečný a robustní server. Tvoří jádro pro všechny analytické, monitorovací a distribuční aplikace,
-
OLAP services – umožňuje provádění intuitivních OLAP analýz,
-
Integrity manager – automatické porovnání reportů a dokumentů pro zajištění integrity dat. Nabízí též možnost regresní analýzy,
-
Object manager – změnový management a verzování BI aplikací mezi vývojovým, testovacím a produkčním prostředí.
Nástroje pro reporting -
Web reporter – interaktivní a intuitivní rozhraní pro soustavný monitoring, tvorbu reportů a analýz,
-
Office – dovoluje pracovat s reporty v aplikacích Microsoft Office (Excel, Word, PowerPoint),
-
Mobile – uživatelské interaktivní rozhraní pro mobilní zařízení,
-
Distribution services – poskytuje funkcionalitu pro velkokapacitní řízenou distribuci sestav a reportů dle předepsaného harmonogramu. Využívá design „What-You-See-IsWhat-You-Get“ (WYSIWYG).
V současné době společnost věnuje velkou pozornost MicroStrategy Cloudu. S oznámením o plné dostupnosti tohoto produktu přišla společnost na konferenci MicroStrategy World 2011. Produkt je poskytován kompletně jako „Platform-as-a-Service“ (platforma jako služba – PaaS). V rámci tohoto řešení je poskytována plná BI funkcionalita od datové integrace až po datovou vizualizaci. Společnost se rozhodla jít cestou vlastních datových center a nabízí rovněž „Cloud personal“ (osobní cloud), jehož prostřednictvím si může každý nahrát a z analyzovat potřebná data (předzpracovaná například v tabulkovém procesoru). Takto z analyzovaná data může navíc sdílet s ostatními uživateli. [12]
25
2.6 Oracle Společnost Oracle corporation je americká nadnárodní společnost specializující se na oblast počítačových systémů, podnikových softwarů a zejména pak na oblast vývoje databázových systémů. Společnost byla založena v roce 1977. Podnětem pro její založení byla studie „A relational Model of Data for Large Shared Data Banks“ od otce relačních databází Edgara F. Codda, jenž inspirovala jednoho ze zakladatelů firmy Oracle Larry Ellisona. Nástroje od firmy Oracle zaujímají na poli BI jedno z nejpřednějších míst, ne-li vůbec to nejvyšší. Firmě Oracle se to podařilo nejen vlastním úsilím ve vývoji BI nástrojů, ale hlavně díky několika akvizicím, ne však vždy zcela přátelským. Zásadním pro dosažení a upevnění vedoucího postavení byla koupě konkurenční firmy Siebel System v roce 2005, jenž patřila, v oblasti systémů pro správu vztahů se zákazníky (CRM), k těm nejlepším a měla tudíž i kvalitní BI nástroje (Siebel BI Platform). V současné době je komplexní sada BI komponent a nástrojů soustředěna do jednoho velkého balíku nazývaného Oracle Business Intelligence Suite Enterprise Edition (OBIEE). Platforma OBIEE je postavena na servisně orientované architektuře (SOA) a díky velké škálovatelnosti může být OBIEE provozováno ve všech myslitelných společnostech, od malých lokálních až po nadnárodní koncerny. Obrázek č. 5: Oracle Business Intelligence Suite Enterprise Edition Plus
Zdroj: https://santoshbidw.wordpress.com/category/obi-applications/ [08] 26
OBIEE umožňuje využít prakticky jakýkoliv zdroj dat a přistupovat k němu lze prostřednictvím řady kanálů. Například pomocí otevřeného interface lze přistupovat k serveru Oracle Business Intelligence jako ke standardní databázi nebo lze vytvořit interface vlastní pomocí Simple Object Access Protocol (SOAP). Vedle tohoto komplexního balíku BI nástrojů, je k dispozici jeho nadstavba v podobě analytických aplikací, jenž byly dříve známy pod označením Siebel Business Analytics. Tyto aplikace dále BI rozvíjejí a umožňují podnikům využít nejlepší postupy tzv. „best practices“ jak u obchodních procesů, tak u funkčních oblastí v nejrůznějších průmyslových odvětvích. [5] Nyní si podrobněji představíme a rozebereme jednotlivé stěžejní komponenty OBIEE.
2.6.1 BI SERVER Oracle BI Server představuje základní komponentu infrastruktury OBIEE. Byl vytvořen pro dosažení co největší škálovatelnosti, vyváženosti a optimalizaci výkonnosti. Konečným cílem je snaha o to, aby co nejširší okruh uživatelů mohl využít úplnou hodnotu BI aplikací. Pomocí BI Serveru získáváme centralizovaný přístup k datům z různých zdrojů, nebo-li prostřednictvím objemné datové pumpy BI Serveru má kdokoliv přístup k jakýmkoliv datům uloženým kdekoliv v dané organizaci2. S těmito daty pak následně pracujeme tak, že vytváříme možná propojení, kalkulace či dimenze. Pro zjednodušení můžeme shrnout funkci BI Serveru do následující věty: Oracle BI Server se stará o dotazování na data ze zdrojových databází, jejich zpracování a předání výsledků prezentační vrstvě. V rámci BI Serveru vytváříme metadata BI Serveru. Tyto metadata můžeme chápat jako mezivrstvu, jenž nám pomůže odstínit uživatele od nutnosti mapování, návrhů dimenzí či hierarchií. Koncový uživatel pak jejich prostřednictvím může analyzovat data nebo vytvářet nejrůznější výstupy bez podrobné znalosti jazyka SQL. Metadata BI Serveru, neboli taktéž „Common Enterprise Information Model“ (CEIM) – obrázek č. 6, jsou uložena v takzvaném „BI Server Repository“. Jedná se o BI Serverem používané úložiště, jenž obsahuje přichycení (mapování) jednotlivých datových zdrojů a jeho transformaci do sémantické vrstvy (business modelu). [30]
2
Samozřejmě že slovy jakýmkoliv a kdekoliv, myslíme data smysluplně strukturována, popsána a náležitým způsobem uložena v široké paletě dostupných datových úložišť.
27
Obrázek č. 6: Common Enterprise Information Model (CEIM)
Zdroj: http://download.oracle.com/docs/cd/E14571_01/bi.1111/e10540/intro.htm [21] Jednotný metadata-model se vytváří v klientském nástroji, postaveném na platformě Windows, zvaném „Oracle BI Administration Tool“. Tento jednotný model je organizován ve třech níže popsaných vrstvách. Fyzická vrstva (Physical Layer) Jedná se o nejnižší úroveň metadat, ve které mapujeme všechny potřebné datové zdroje z různých úložišť a následně tyto namapované fyzické zdroje dle potřeby provážeme. Tato vrstva se pak automaticky postará o vygenerování optimálního kódu (SQL) pro dané datové úložiště. Součástí automatického generování je taktéž „function shipping“ neboli provedení všech kalkulací, které byly definovány v rámci business model vrstvy příslušné databázové platformy. Samozřejmě za předpokladu že dotyčná databázová platforma takovouto kalkulaci umožňuje. Oracle BI Server podporuje nepřeberné množství datových úložišť a z obrázku č. 6 si můžeme udělat názornou představu z jakých druhů datových úložišť je možné zdroje mapovat. Mohou to být především: -
Relační databáze – relační databázový model vzniká spojením lineárních modelů pomocí tzv. relačních klíčů, na rozdíl od ostatních modelů není spojení tímto relačním klíčem trvalé - vzniká tehdy kdy potřebujeme mít společně k dispozici data ze všech požadovaných tabulek a zaniká v okamžiku, kdy spojení nepotřebujeme. Základem jsou relace (vztahy), k tomu slouží primární klíč a cizí klíč. Cizí klíč slouží pro 28
vyjádření vztahu mezi tabulkami, umožní identifikovat, které záznamy spolu navzájem souvisí. Primární klíč je pak jednoznačný identifikátor záznamu – řádku tabulky. Z čistě relačních databázových modelů se časem staly objektově relační. Tyto modely čerpají z objektově orientovaného přístupu a mezi jejich základní charakteristiky řadíme: objektovou identitu a referenci, složité datové struktury jako pole či hnízděné tabulky, dále pak dědičnost, DML s objektovými rysy a v neposlední řadě práci s velkými datovými objekty typu blob, clob a bfile. Mezi podporované relační databáze resp. objektově relační databáze patří samozřejmě Oracle, ale i další jako MS SQL, MySQL, IBM DB2, Informix, Teradata, Sybase, RedBrick a další, -
Multidimenzionální databáze – zde hovoříme o takzvané kostce jako o základní stavební jednotce této databáze. Tato datová resp. multidimenzionální kostka (cube) je složena ze sad měr a dimenzí (rozměrů). Dimenze můžeme chápat jako kategorie, podle nichž chceme data agregovat či analyzovat a které se mohou rozpadat do mnoha úrovní a podúrovní, s cílem zpřesnit analyzovaná data. Klasickým příkladem dimenze je čas, výrobek (subjekt) a pozice. Mírami pak rozumíme prakticky jakékoliv kvantitativní údaje. Nejčastěji se jedná o nákup, prodej, aktiva, pasiva, zisky, ztráty, úrokové míry a další. Mezi podporované multidimenzionální databáze řadíme nejen (samozřejmě) Oracle OLAP Option, ale i SAP BW, Hyperion Essbase, MS Analysis Services a další,
-
Ostatní zdroje – zde se jedná především o data formátu XML a o data připravená v kancelářském balíku MS Office, respektive v databázovém softwaru MS Access nebo tabulkovém procesoru MS Excel.
Vrstva business modelu (Business Model and Mapping Layer) Jedná se o druhou, prostřední, a taktéž nejdůležitější vrstvu metadat BI Serveru. U této vrstvy se můžeme rovněž setkat s označením „vrstva sémantického modelu“. Cílem této vrstvy metadat je transformace namapovaných datových zdrojů, neboli fyzického datového modelu, do business modelu. Transformací musí projít všechny fyzické datové modely bez ohledu na to, jestli se jedná o dimenzionální model, relační model či data XML. Výsledkem transformace je business model, kterému také říkáme logický dimenzionální datový model. Jedná se o tzv. schéma hvězdy s logickými dimenzemi a fakty. Přičemž pod pojmem faktová tabulka si můžeme představit tabulku (datovou strukturu) obsahující především rozličné ukazatele – metriky, nad kterými lze provádět nejrůznější aritmetické operace. Dimenzemi pak rozumíme ty atributy, jenž nám ukazatele ve faktové tabulce nějakým způsobem popisují. 29
V rámci tvorby výsledného business modelu vytváříme a definujeme jednotlivé dimenzní hierarchie, vypočtené a odvozené ukazatele, taktéž se zde definují vlastní agregace a kalkulace. Prezentační vrstva (Presentation Layer) Poslední (nejvyšší) vrstva metadat BI Serveru nám umožňuje rozdělit business model do menších částí neboli subjektových oblastí. Důvodem je skutečnost, že tato vrstva, jako jediná, je viditelná pro koncového uživatele, který pak pomocí nástroje BI Answers vytváří nejrůznější koncové sestavy a analýzy nad připravenými daty. Jelikož
se jedná o vrstvu přístupnou všem uživatelům, tedy i těm kteří nemusí být
obeznámeni se zákonitostmi a fungováním jazyka SQL, je třeba tuto vrstvu připravit co nejsrozumitelněji. Tudíž využíváme v hojné míře zástupných názvů (aliasů) jednotlivých logických sloupců, diakritiku a v neposlední řadě vytváříme vhodné hierarchické členění prezentační vrstvy. Je třeba zdůraznit, že přípravě prezentační vrstvy metadat musíme věnovat mimořádnou pozornost. Pokud se nám totiž nepodaří tuto vrstvu připravit, tak aby byla pro uživatele co nesrozumitelnější a v mnoha ohledech intuitivní, sebelepší vytvořený business model přijde nazmar. Závěrem si zde dovolím ještě pár slov o řízení přístupových práv k vytvořenému modelu metadat BI Serveru. Přístupová práva, z logiky věci, řešíme v úplném závěru, kdy již máme model vytvořen. Nástroj pro tvorbu metadat nám umožňuje definovat uživatele a skupiny, kterým přidělujeme přístupová práva. Práva lze přidělit jak na úrovni fyzické (nejnižší) vrstvy, tak na úrovni vrstvy prezentační tedy nejvyšší. Přístupová práva můžeme přidělit rovnou celé vrstvě nebo lze v rámci dané vrstvy přidělit přístup jen k určitým objektům. Později, na praktickém příkladu této diplomové práce, si podrobně ukážeme, jak se v jednotlivých vrstvách pracuje a tedy jakým způsobem lze metadata model připravit.
2.6.2 BI ANSWERS Tento nástroj slouží koncovým uživatelům k práci nad připraveným modelem BI Serveru. S jeho pomocí uživatel může vytvářet dotazy, provádět online analýzy či připravovat sestavy pro reporting, aniž by musel znát jazyk SQL, uměl programovat nebo byl seznámen s procesem tvorby datových modelů. [30] V rámci tohoto nativního prostředí jsou veškeré dotazy definovány vůči vytvořeným prezentačním sloupcům nejvyšší vrstvy metadat BI
30
Serveru. Vedle intuitivního sestavování jednoduchých tabulkových dotazů z připravených prezentačních sloupců může uživatel vytvářet kontingenční tabulky, grafy popřípadě míry. Míru si můžeme představit například jako ukazatel paliva v autě. Ručička ukazatele je provázána s výslednou hodnotou či hodnotami a pohybuje se dle nastavených rozsahů barevných škál. Dále samozřejmě můžeme výsledné sestavy opatřit nejrůznějšími popiskami, legendami či značkami. Tento nástroj poskytuje veškerou základní uživatelskou funkcionalitu, která se od takového nástroje očekává. Dostupná je nejrůznější filtrace dat dle jakéhokoliv zvoleného prezentačního sloupce. Dále lze pracovat s formátem zvoleného sloupce, s formátem dat nebo podmíněným formátováním. Všechny tyto funkce jsou jednoduše a přehledně přístupné s cílem umožnit všem uživatelům, bez ohledu na jejich znalosti, rychle a jednoduše vytvářet profesionálně vypadající výstupy. Samozřejmě, vedle této základní funkcionality, nástroj nabízí plno pokročilých funkcí jak pro zkušené uživatele, tak pro profesionální tvůrce sestav. Mezi nejužitečnější a nejpoužívanější patří: -
možnost využití vlastních kaskádových stylů či tříd - Cascading Style Sheets (CSS) při úpravě zobrazení sloupců,
-
kombinovat dotaz s dotazem (sjednocení, rozdíl, průnik),
-
tvorba výzev – uživatel nejdříve vybere hodnotu či hodnoty na jejichž základě budou následně dynamicky filtrována data v zobrazené sestavě,
-
možnost ručně upravit automaticky sestavený XML požadavek nebo dotaz SQL.
Stejně jako v případě tvorby metadat BI Serveru si v rámci praktického přikladu předvedeme jak jednoduše lze sestavy, včetně podporovaných grafických prvků, vytvářet.
2.6.3 BI DELIVERS Tato komponenta představuje inteligentní řešení, které se stará o monitorování aktivit, popřípadě detekuje a upozorňuje na vzniklé anomálie. [30] V rámci této komponenty vytváříme a řídíme takzvané iBots. Ty můžeme charakterizovat jako inteligentní agenty, kteří na základě nadefinovaných pravidel a v nastaveném čase zasílají zvolený obsah. Tyto agenty lze využít v mnoha situacích a představují cenného pomocníka jak pro uživatele, tak pro administrátory či správce. Mezi typické příklady jejich využití patří: -
zasílání sestav příslušným uživatelům na vybrané cíle. Tímto cílem může být mobil, e-mail, pager či jiné nadefinované příruční zařízení, 31
-
hlídání přístupů a sledování logů,
-
informace o chybách ve zpracování apod.
Postup vytvoření agenta je velmi jednoduchý a je rozdělen do 7 sekcí. Na obrázku č. 7 vidíme úvodní obrazovku při tvorbě agenta v komponentě BI Delivers. Projdeme si jednotlivé sekce podrobněji: -
obecné – zde nastavujeme prioritu agenta a definujeme podle jakého nastavení (vlastníka agenta či příjemců) se budou zobrazovat výsledky,
-
podmíněný požadavek – tady vybereme uložený dotaz, který našeho agenta vyvolá,
-
plán – nastavíme plán spouštění agenta. Máme na výběr od okamžitého spuštění, po opakování každou minutu, každý den v týdnu,
-
adresáti – definujeme příjemce agenta. Může jím být jeden uživatel, množina uživatelů či aplikační skupina,
-
obsah doručení – definujeme jaký text, jaká sestava se má zaslat/zobrazit v případě, že dotaz nastavený v podmíněném požadavku vrátí alespoň jeden řádek/záznam. Lze taktéž nadefinovat text v případě že dotaz nevrátí žádný záznam,
-
cíle – nastavíme místo/zařízení, kam se má výsledek doručit,
-
pokročilé – zde můžeme přidat akci, neboli pokud bude splněna podmínka jednoho agenta, můžeme tím vyvolat dalšího agenta, který pro každý vrácený řádek bude jednou puštěn s nastavenými filtry. Obrázek č. 7: BI Delivers – tvorba nového agenta iBot
Zdroj: Instalace OBIEE v prostředí ČNB - vlastní úprava 32
Posledním krokem při tvorbě agenta je jeho aktivace. Ta proběhne automaticky v okamžiku, kdy vytvořeného agenta uložíme. Samotné provádění uložených agentů dle nastaveného plánu má na starosti další komponenta infrastruktury OBIEE, a to Oracle BI Schedule Server.
2.6.4 BI INTERACTIVE DASHBOARDS Dashboards představují interaktivní panely, které si uživatel může vytvořit a přizpůsobit vlastním potřebám. Jsou plně personalizované, tudíž každý uživatel má k dispozici svůj vlastní panel. Na něj lze přidat libovolný počet stránek mezi nimiž je pak možné se pohybovat pomocí záložek. Stránky můžeme rozdělit na sloupce a oddíly a ty pak následně vybavit potřebným obsahem. Z prezentačního „web“ katalogu věšíme na stránku uložené sestavy, analýzy či grafy. Dále pak můžeme stránku opatřit odkazy řízené navigace, přidat vlastní názvy a komentáře. Samozřejmostí je nejrůznější úprava vlastností sloupců a navěšeného obsahu, ať už pomocí předefinovaných voleb, či prostřednictvím vlastních CSS stylů a tříd. Například pro každou takto připravenou sestavu či graf lze nastavit možnost jejich změny, tisku, kopírování nebo stáhnutí do různých aplikací (MS Excel, PowerPoint a další). Nedílnou součástí tvorby každého panelu je práce s přístupovými právy. Každý uživatel má možnost, pokud k tomu má oprávnění, přidělit přístupová práva ke svému panelu ostatním uživatelům či skupinám. V rámci řízení přístupových práv je možné zpřístupnit jen vybrané stránky daného panelu či omezit přístup pouze na jednu vyvěšenou sestavu. Závěrem bychom mohli funkcionalitu této komponenty jednoduše shrnout slovy, že poskytuje všem uživatelům možnost vytvoření uživatelsky velmi přívětivého interaktivního „rozhraní“ s přístupem ke všem potřebným sestavám, analýzám a grafům vytvořených s pomocí metadat BI Serveru a uložených ve web katalogu. V praktické části této diplomové práce si ukážeme postup tvorby jednoduchého panelu.
2.6.5 BI PUBLISHER Tato komponenta, založená na standardu W3c XSL-FO formátu, představuje ucelené řešení pro tvorbu, generování a distribuci nejrůznějších sestav dle předpřipravených šablon. Hlavní myšlenkou je oddělit vlastní návrh šablon od datové logiky. Návrh šablon je záležitostí vcelku značně jednoduchou. K jejich tvorbě můžeme využít široce rozšířených a používaných aplikací typu MS Word a Adobe Akrobat. Není tedy zapotřebí žádných profesionálních vývojových prostředí či znalostí nad rámec běžného koncového uživatele. Samozřejmě Publisher nabízí také možnost použít šablony vytvořené ve speciálních vývojových 33
prostředích jako například jakékoliv XML IDE prostředí. Všechny takto vytvořené šablony jsou v Publisher převedeny do formátu XSL-FO. Další nespornou výhodou této komponenty je možnost využití dat prakticky z jakéhokoliv zdroje, ať už je to databáze, webová služba či souborový systém. K zajištění nezávislosti komponenty na zdroji dat pak slouží jednotný vstupní formát (XML). Jelikož zde pracujeme s daty sebranými ze všech možných podnikových systémů a vytváříme originální firemní výstupy, musíme zajistit maximální možnou míru bezpečnosti, abychom předešli úniku dat a informací. Můžeme BI Publisher napojit například na podnikový LDAP server nebo na existující Business Intelligence či konkrétní databázi. Dle výše uvedeného, jednoduchá charakteristika této komponenty může znít následovně. Prostřednictvím této komponenty vytvoříme jeden výstupní dokument/sestavu z dat získaných z mnoha rozličných zdrojů. Takto vytvořenou výstupní sestavu můžeme uložit do mnoha standardních formátů a distribuovat pomocí nejrůznějších zařízení. Z obrázku č. 8 si můžeme udělat názornou představu o principu fungování této komponenty. Obrázek č. 8: Schéma BI Publisher
Zdroj:http://www.howtoexam.com/index.php?option=com_content&view=article&id=261:bipublisher-and-its-integration-with-oracle-report&catid=790:computers-and-software [09]
34
3 Návrh a implementace BI řešení V následující kapitole si ukážeme, jakým způsobem lze využít BI řešení pro tak specifickou společnost jakou je Česká národní banka (ČNB). Za příklad jsem zvolil úlohu pro sestavování platební bilance a investiční pozice České republiky, na níž předvedu, že řešení BI je vhodné i pro oblasti, které nejsou, na první pohled, pro BI řešení typické či ideální.
3.1 Úvod do problematiky řešeného příkladu ČNB je centrální bankou České republiky a je zřízena Ústavou České republiky. Činnost ČNB je pak upravena zákonem č.6/1993 Sb., o ČNB. Dle tohoto zákona je hlavním cílem ČNB péče o cenovou stabilitu. ČNB rovněž mimo jiné určuje měnovou politiku, vydává bankovky a mince, řídí peněžní oběh, vykonává dohled nad bankovním sektorem či kapitálovým trhem a v neposlední řadě sestavuje a zveřejňuje statistiky, mezi které patří zejména měnová a finanční statistika a platební bilance. [28]
3.1.1 Informační prostředí ČNB Kvalitní sběrné, zpracovatelské a distribuční systémy jsou pro ČNB klíčové. Bez nich by nemohla plnit všechny své definované cíle. Předem je třeba říci, že účelem není představit kompletní systémy IS/IT v ČNB. Níže uvedený popis způsobu sběru, zpracování a „reportingu“ statistických dat v České národní bance, je právě tak podrobný, aby poskytl obecnou představu o práci se statistickými daty v České národní bance, tak abychom posléze lépe porozuměli řešenému příkladu. Nejedná se tedy o kompletní popis způsobu nakládání se statistickými daty v ČNB. Detailnější a komplexnější informace o způsobu sběru a zpracování statistických dat v ČNB včetně „reportingu“ a zabezpečení vykazovaných i zasílaných dat, je možno nalézt například v bakalářské práci3.
3
KOCÁBEK, Tomáš. Sběr a zpracování dat v ČNB. Praha [36]
35
Sběr dat Automatizovaný sběr statistických dat prošel od vzniku výkaznictví velkým rozvojem. Za jeho začátek lze považovat rok 1991, kdy byla v České republice vytvořena již určitá standardní bankovní soustava. Základním systémem pro sběr statistických a dohledových dat od bank, ostatních finančních a především nefinančních subjektů, je v současné době systém SDNS, který je dostupný z oficiálního webu ČNB na adrese: https://wsn.cnb.cz/ewi/. Tento systém byl původně budován jako doplněk k stávajícímu systému sběru dat od bankovních subjektů a to především pro nefinanční subjekty. Důvodem byla ta skutečnost, že implementace původního systému sběru pro komerční banky působící v ČR, založeného na konceptu EDI a komunikačním kanálu X.400, je pro ostatní subjekty příliš nákladná a složitá. Systém SDNS se tak postupně stal plnohodnotným kanálem pro sběr dat. Nově vzniklé banky tudíž nemusí zavádět systém EDI, ale mohou využít SDNS. Taktéž banky stávající mohou přejít k systému SDNS bez omezení. [35] Veškerá sbíraná data, výše uvedenými systémy, jsou ukládána do relační databáze provozované na linuxových serverech. Ze schémat zachycených na obrázcích 9 a 10 si můžeme udělat názornou představu o fungování systému SDNS. Obrázek č. 9: Webové rozhraní systému SDNS Uživatelská vrstva
Aplikační vrstva Presenční vrstva Vrstva aplikační logiky
Datová vrstva
Zdroj: KOCÁBEK, Tomáš. Sběr a zpracování dat v ČNB. [36]
36
Obrázek č. 10: Hardwarové schéma webového rozhraní systému SDNS Uživatel
Vnitřní síť ČNB DMZ
Internet
Firewall
Aplikační server
Web server
Zdroj: KOCÁBEK, Tomáš. Sběr a zpracování dat v ČNB. [36] Za samozřejmost lze považovat fakt, že všechna komunikace tímto systémem je šifrována a zasílané zprávy jsou podepisovány digitálním podpisem. Systém SDNS je rovněž využíván jako hlavní nástroj pro prezentaci vykazovacích metodik, jenž vytvářejí příslušné odborné útvary v ČNB a které jsou pro všechny vykazující subjekty závazné. Systém SDNS se skládá z veřejné a neveřejné části. Každý subjekt který je ze zákona povinen data do ČNB zasílat (banky a ostatní finanční subjekty) nebo se k výkaznictví dobrovolně zaváže (podniky vybrané pro statistická šetření) musí nejprve v ČNB nechat zaregistrovat odpovědné osoby, jenž následně mohou data zasílat. Zpracování statistických dat V Česká národní bance neexistuje jednotný systém pro zpracování statistických dat. Je to dáno velkou specifičností jednotlivých oblastí, pro která jsou statistická data zpracovávána. V současné době existuje v ČNB několik zastřešujících modulů zpracování, které postihují hlavní tématické oblasti [36]: -
oblast měnová a finanční – jedná se o měnovou a finanční statistiku dle předpisů EU a mezinárodních standardů,
-
oblast platební bilance – sestavování platební bilance dle mezinárodních standardů a předpisů EU,
-
oblast finanční trhů – informace o vývoji na peněžním, kapitálovém či devizovém trhu ČR,
-
oblast finančních účtů – statistky finančních účtů dle mezinárodních standardů a předpisů EU.
37
V rámci každého vrchního modulu existují jednotlivé dílčí moduly, kde jsou příslušná data zpracovávána dle specifických požadavků uživatelů. Tyto dílčí moduly byly a jsou ve většině případů, v rámci daného vrchního modulu, vytvářeny a rozvíjeny samostatně, bez větší vzájemné koordinace v rámci dané oblasti. Jediným společným bodem je výstupní rozhraní pro prezentační systém statistických dat ARAD. Všechny moduly byly a jsou vyvíjeny interními silami ČNB. Hlavním důvodem pro toto řešení je jedinečnost potřebných úloh a důvěrnost dat. Vzhledem ke skutečnosti, že potřebná data jsou ukládána do relační databáze, jsou příslušné programové rutiny psány v PL/SQL. Ke správě jednoho každého dílčího modulu jsou vytvářena uživatelská rozhraní. K jejich tvorbě se používají nástroje Microsoft Access, Oracle Forms a Oracle Application Expres. K vlastní analytické práci nad příslušnými daty se využívají nástroje Microsoft Excel, Oracle Discoverer a OBIEE. Do budoucna je plánováno s postupnou konsolidací jednotlivých dílčích modulů tak, aby bylo možné v plné míře využít veškerou dostupnou funkcionalitu implementovaných nástrojů OBIEE v ČNB. Na obrázku č. 11 jsou zachyceny vybrané vrchní moduly zpracování včetně systému ARAD. Obrázek č. 11: Modulární zpracování statistických dat v ČNB
Primární databáze systému sběru dat
Externí zdroje dat
Měnová a finanční
Platební bilance
Finanční trhy
Finanční účty
CSDB- databáze cenných papírů při ECB
ARAD Primární databáze statistických dat
Zdroj: KOCÁBEK, Tomáš. Sběr a zpracování dat v ČNB. [36]
38
Statistická data zpracovávaná v ČNB plní dvojí úlohu. Na jedné straně slouží odborným útvarům k plnění jejich hlavních pracovních úkolů a tím napomáhají plnit hlavní cíle ČNB. Na straně druhé se zpracovávaná statistická data uveřejňují (v agregované podobě) a reportují do příslušných orgánů EU. Presentace statistických dat Zpracovaná statistická data jsou prezentována v podobě agregovaných časových řad. Hlavním prezentačním systémem ČNB, pro tato data, je systém ARAD. Systém je přístupný, skrze internetový portál ČNB, nejen odborné, ale i široké laické veřejnosti na adrese: http://www.cnb.cz/docs/ARADY/HTML/index.htm. Reporting statistických dat ČNB, jako centrální banka České republiky, je povinna na základě smluvních vztahů, jenž vyplývají z našeho členství v Evropské unii, poskytovat statistická data evropským institucím, zejména Evropské centrální bance (ECB) a Evropskému statistickému úřadu (Eurostat). Taktéž, ať už na bázi dobrovolnosti či smluvních vztahů, je ČNB povinna zasílat vybraná data do mezinárodních institucí, jako jsou Mezinárodní měnový fond (IMF), Banka pro mezinárodní platby (BIS) a Organizace pro hospodářskou spolupráci a rozvoj (OECD). Tato povinnost vznikala postupně a neustále se rozšiřuje. Ruku v ruce se tím zvyšují nároky na požadované množství a detail poskytovaných statistických dat. Za začátek „reportingu“ lze považovat zahájení přístupových rozhovorů mezi Českou republikou a Evropskou unií. Nezbytnou součástí tohoto vyjednávání bylo zasílání požadovaných dat do určených evropských institucí. V začátcích byla data zasílána mailem a podepisovaná a šifrovaná standardem OpenPGP. Po přistoupení České republiky k Evropské unii byl (tento jednoduchý způsob) nahrazen sofistikovanou sítí ESCB-Net. Rozvoj komunikace mezi ECB a jednotlivými centrálními bankami členských zemí EU probíhá kontinuálně v závislosti na stále se zvyšujících požadavcích na množství a periodicitu zasílaných dat a technickém pokroku. V současné době je vzájemná komunikace zajišťována prostřednictvím dvou hlavních infrastrukturních systémů:
39
-
CoreNet – fyzická síť s hvězdicovou topologií, která zajišťuje samotný přenos dat mezi ECB a jednotlivými centrálními bankami členských států EU,
-
ESCB-Net – systémové prostředí určené k provozu ESCB4 aplikací. Toto prostředí obsahuje řadu logických komponent v čele s EXDI gateways. o Jedná se servery a operační systém pro aplikačního rozhraní EXDI, který představuje upravený komerční produkt „webMethods“ a jako takový je plně pod správou ECB.
Na straně ECB tak spočívá zajištění bezpečnosti dat
proudící přes toto rozhraní. Z obrázku č. 12 si můžeme udělat názornou představu o stávající organizaci komunikace mezi ECB a jednotlivým centrálními bankami členských zemí EU. Obrázek č. 12: Blokové schéma komponent a vazeb ESCB infrastruktury a aplikací Jednotlivé koncové aplikace např. CSDB – centrální databáze cenných papírů
Jednotlivé systémy například: CebaMail – elektronická pošta
Telekonferenční systém
DARWIN – informační dokumentový systém aj.
EXDI ESCB-Net CoreNet Zdroj: KOCÁBEK, Tomáš. Sběr a zpracování dat v ČNB. [36]
3.1.2 Platební bilance Platební bilance obsahuje souhrn ekonomických transakcí se zahraničím za dané časové období. Můžeme si ji představit jako účetní výkaz, do kterého se zadávají všechny hospodářské toky, které do země vstupují a vystupují. Pomocí platební bilance se tak měří úhrn toků statků, služeb a kapitálu, včetně darů a přesunů finančních prostředků mezi danou zemí a zahraničím. Jednotlivé toky se v platební bilanci zaznamenávají na kreditní nebo
4
European System of Central Banks (ESCB) – Zastřešuje všechny centrální banky členských zemí EU.
40
debetní stranu, dle toho zda se jedná o vývoz (kredit) či dovoz (debet). Následně se dopočte pro každou zaznamenanou položku příslušný tok (kredit-debet). [06] ČNB zpracovává platební bilanci na základě interních předpisů ke statistice platební bilance, dle mezinárodních standardů a předpisů EU.5 Všechny předpisy a standardy jsou volně k dispozici na stránkách ČNB: http://www.cnb.cz/cs/statistika/platebni_bilance_stat/. Platební bilance je zpracovávána na měsíční a čtvrtletní bázi. Přičemž čtvrtletní platební bilance je sestavována, publikována a reportována s vyšší mírou podrobnosti než bilance měsíční. Struktura platební bilance se skládá ze čtyř základních částí: Běžný účet Obecně shrnuje rozdíl mezi celkovým vývozem statků a služeb dané země a celkovým dovozem statků a služeb[06]. Do této části patří: -
obchodní bilance – zahrnuje dovoz a vývoz zboží,
-
bilance služeb – jedná se o příjmy a výdaje ve sféře služeb,
-
bilance výnosů – patří sem náhrady zaměstnancům a investiční výnosy,
-
běžné převody.
Kapitálový účet Do této částí spadají nejrůznější kapitálové transfery včetně například odpuštění dluhů, příspěvků do EU či emisních povolenek. Finanční účet Svým rozsahem jde o největší část platební bilance, ve které se uvádějí investice a patří sem: -
přímé investice – zde se uvádějí investice, jenž tvoří alespoň 10% základního jmění společnosti,
-
portfoliové investice – do této kategorie spadají menší investice, jakou jsou například majetkové nebo dluhové cenné papíry,
-
finanční deriváty – jedná se o instrumenty, jenž se oceňují na základě tržních cen jednoho či více podkladových aktiv. Mezi finanční deriváty patří například forvardy, opce či certifikáty,
5
Nejdůležitější předpis pro zpracování platební bilance a investiční pozice ČR je Guideline of the European Central Bank of 31 May 2007 amending Guideline ECB/2004/15 on the statistical reporting requirements of the European Central Bank in the field of balance of payments and international investment position statistics, and the international reserves template.
41
-
ostatní investice – zahrnují investice vlády a ČNB,
-
změna devizových rezerv – jedná se o devizové rezervy v držení ČNB. Případný nárůst devizových rezerv se uvádí s minusovým znaménkem.
Saldo chyb a opomenutí Tato část zahrnuje statistické diskrepance vzniklé na základě kursových rozdílů, metodických změn či statistických nedokonalostí.
3.1.3 Investiční pozice Investiční pozice vůči zahraničí vyčísluje aktuální stav příslušných finančních aktiv a pasiv ke stanovenému dni. Jinak řečeno uvádí saldo finančních aktiv a pasiv rezidentů6 ČR ve vztahu k nerezidentům7. Jedná se tedy, na rozdíl od platební bilance, o veličiny stavové. Investiční pozice zahrnuje všechny sektory tuzemské ekonomiky a svoji strukturou odpovídá jednotlivým položkám finančního účtu platební bilance. Součástí přehledu investiční pozice je i údaj o zahraniční zadluženosti ČR.[22] Při sestavování investiční pozice se vychází ze stejných předpisů a standardů jenž se používají pro platební bilanci. Investiční pozice je sestavována ve čtvrtletní a roční periodicitě s různou mírou detailu.
3.2 Předběžná studie řešeného příkladu Jednou ze základních nezbytných částí každého budovaného IS je zpracování předběžná studie, jenž vychází ze schváleného podnětu příslušným rozhodovacím orgánem společnosti, ve které je IS tvořen. Předepsané náležitosti každé předběžné studie jsou dány zvolenou metodikou firmy. ČNB si pro rozvoj a údržbu IS/IT v celé organizaci vytvořila metodiku vlastní. Ta je založena na mezinárodním standardu8 a je přizpůsobena vlastním potřebám. Dle této metodiky musí každá předběžná studie obsahovat dvě základní povinné části [37]:
6
Rezidentem se v tomto případě rozumí institucionální jednotka s trvalým ekonomickým zájmem v ČR. Například právnická osoba se sídlem v ČR. 7 Nerezidentem se v tomto případě rozumí institucionální osoba, jenž nemá trvalý ekonomický zájem v ČR. 8 ANSI/IEEE standard 830-1998: Doporučená praxe při specifikaci SW požadavků - Recommended Practice for Software Requirements Specification.
42
-
Uživatelské zadání – tato část je nezbytná pro prezentaci řešeného problému co nejpřesněji a v kompletní šíři. Taktéž musí být tato část zpracována tak, aby mohla sloužit jako podklad pro definici akceptačních testů. Uživatelské zadání musí bezpodmínečně obsahovat: o popis současného stavu a jeho nevýhod, o obecné požadavky uživatele na funkcionalitu vyvíjeného IS, o všechny zjištěné uživatelské požadavky, o definovaná známá omezení identifikovaná uživatelem. Naproti tomu uživatelské zadání nemá za cíl analyzovat požadavky na systém a definovat jakékoliv části návrhu řešení.
-
Studii proveditelnosti – se zabývá technickou problematikou řešené úlohy. Vypracování studie je závislé na vytvořeném a úplném uživatelském zadání. Cílem studie proveditelnosti je: o variantní návrh technického řešení požadavků specifikovaných v uživatelském zadání, o návrh způsobu realizace včetně časového harmonogramu, kontrolních bodů, a odhad zdrojů potřebných k realizaci a provozu vytvořeného IS. o návrh organizačního zajištění vedení projektu.
Cílem této diplomové práce není rozbor tvorby dokumentace ke tvorbě IS. Proto představím uživatelské požadavky našeho řešeného příkladu ve zhuštěné a zestručněné formě a taktéž studie proveditelnosti nebude zabíhat do zbytečných detailů. Pro naše účely (příklad návrhu, tvorby a implementace BI řešení, dále jen IS UNIZBIP) bude takto uvedená předběžná studie plně postačující.
3.2.1 Uživatelské zadání IS UNIZBIP Rozsah řešené problematiky Účelem tohoto IS je vrcholové sestavení platební bilance a investiční pozice ČR na základě primárního zpracování všech dílčích oblastí potřebných pro jejich sestavení. Cílem je vytvoření jednotlivých modulů zpracování, s vlastním uživatelským rozhraním a výstupy, pokrývajícími příslušnou dílčí oblast a vytvoření hlavního řídícího modulu pro vrcholové sestavení PB a IP. Současný stav zpracování V současné době probíhá organizace zpracování PB a IP následujícím způsobem: 43
-
platební bilance se zpracovává v měsíční a čtvrtletní periodě. Investiční pozice má periodu čtvrtletní a roční,
-
obě statistiky se sestavují v souborech Microsoft Office Excel z různorodých zdrojových dat, jenž nemají jednotný či standardizovaný formát. Jedná se zejména o e-maily, tiskové výstupy a soubory ve formátu Microsoft Office Excel,
-
návaznost mezi stavy a toky příslušných položek je řešena vzorci v Microsoft Office Excel souborech a optickou kontrolou při sestavování,
-
takto sestavená platební bilance a investiční pozice je nahrána prostřednictvím standardizovaného Microsoft Office Excel souboru do systému ARAD a z něho jsou následně data odesílána do ECB a BIS,
-
současně jsou ručně vytvářeny výstupy na webové stránky ČNB,
-
propočet PB v geografickém členění probíhá pouze čtvrtletně a s omezeným detailem položek (podle požadavků Eurostatu). IP se v současné době geograficky nečlení,
-
výsledné statistiky jsou nahrány do db Oracle a interním uživatelům zpřístupněny prostřednictvím Oracle Discovereru,
-
pomocí návazných úloh jsou následně z takto uložených dat vytvářeny GESMES zprávy, které se odesílají do Eurostatu a výstupy pro ČSÚ.
Nedostatky stávajícího způsobu zpracování Současný systém sestavení PB a IP vede k vyššímu objemu mechanické práce nebo zdvojování některých činností a tím vede k vyšší pravděpodobnosti potenciálních chyb (zejména při sestavování geografického členění). Dále neumožňuje sestavovat statistiky ve větším detailu (geograficky, časově nebo i z hlediska položek a měn). Při současném způsobu zpracování není možné vyhovět všem požadavkům, které ECB klade na členy Měnové unie (MU). K metodickému sladění musí dojít v předstihu už jen z důvodu závazku dodat při přijetí eura harmonizovaná data za období od vstupu do EU. ECB v současnosti od členů MU požaduje: -
měsíční a čtvrtletní PB a čtvrtletní IP v rozdělení na MU a ostatní,
-
čtvrtletní PB v jiné položkové struktuře v rozdělení po vybraných zemích,
-
roční IP v detailnější položkové struktuře v rozdělení na MU a ostatní,
-
roční IP v jiné položkové struktuře v rozdělení po jednotlivých zemích,
-
detail dílčí oblasti PB (portfoliových investicích) v členění podle vybraných měn.
44
Uživatelské požadavky na budoucí stav zpracování Požadovaný IS musí komplexně pokrýt zpracování PB a IP (od jednotlivých primárních oblastí po vrcholového sestavení), včetně následné rozsáhlé analytické práce. Dále musí být budovaný IS dostatečně pružný, tak aby pokryl vysokou frekvenci metodických změn. Pro každý jeden dílčí modul musí být vybudováno samostatné uživatelské rozhraní, které umožní příslušnému věcnému správci dané oblasti následující: -
import dat do datového skladu platební bilance ze zdrojů mimo sběrné systémy,
-
správu těchto importovaných dat (verzování, rušení, bilancování),
-
správu geografického číselníku dané oblasti,
-
správu primárních položek dané oblasti „BopItems“,
-
vkládání ručních, bilančních položek pro jednotlivé „BopItems“,
-
opakované sestavování dané dílčí oblasti pro PB a IP ze všech zdrojových dat a případných bilančních položek v nejnižší, měsíční periodě a v nejširším členění,
-
řízení revizí konečných výstupů za dané oblasti.
Uživatelské rozhraní hlavního řídící modulu zajistí: -
načtení zpracovaných dat ze všech dílčích oblastí primárního zpracování,
-
dopočet sald a vyšších stupňů agregací a tím sestavení pracovní verze PB a IP, která bude sloužit k bilancování, na jehož základě buď ještě dojde k úpravám na úrovni některé oblasti primárního zpracování (zvláště v odhadovaných částech) nebo ke schválení dat PB a IP v rámci dané revize,
-
sestavení výstupů pro mezinárodní a spolupracující národní instituce včetně potřebných formátů,
-
vytvoření výstupů pro další analytické a prezentační systémy ČNB,
-
organizaci, archivaci a uživatelskou dostupnost dat jednotlivých revizí PB a IP,
-
jednoduchou uživatelskou obslužnost při zadávání dat, metadat, zakládání revizí a archivaci.
3.2.2 Studie proveditelnosti Vzhledem k jedinečnosti řešené problematiky neexistuje na trhu IT odpovídající řešení, a proto v rámci studie proveditelnosti bude zpracována pouze jedna varianta řešení. Toto řešení předpokládá vytvoření systému IS UNIZBIP vlastními silami, bez vynaložení externích nákladů.
45
Koncepce řešení Pro každou primární oblast zpracování bude vytvořen samostatný modul, který umožní správci a uživatelům dané oblasti pracovat s příslušnými primárními daty dle specifikovaných uživatelských požadavků. Přehled jednotlivých dílčích modulů ve struktuře PB a IP je uveden v příloze č. 1. Hlavním výstupem z jednotlivých modulů primárního zpracování budou logicky a věcně správná, vybilancovaná, rozvážená a spočítaná data v jednotné předepsané struktuře, která budou tvořit datový základ pro hlavní zpracovatelský modul IS UNIZBIP. Hlavní zpracovatelský modul následně umožní příslušným věcným správcům pracovat s daty dle specifikovaných uživatelských požadavků a v souladu s požadovanými rolemi. Dle uživatelských požadavků budou vytvořené výstupy z dílčích modulů: -
poskytnuty oprávněným osobám prostřednictvím nástrojů OBIEE pro detailní analýzy a další využití,
-
předány hlavnímu zpracovatelskému modulu ke konečnému sestavení PB a IP.
Z hlavního zpracovatelského modulu IS UNIZBIP budou výstupy: -
předány systému ARAD pro další zpracování,
-
poskytnuty oprávněným osobám prostřednictvím nástrojů OBIEE pro detailní analýzy,
-
publikovány na webu ČNB,
-
předány modulu GESMES/TS pro příslušný reporting,
Aplikační architektura Na obrázku č. 13 je zachyceno konceptuální schéma IS UNIZBIP. Jedná se o obecné schéma určené k modelování reality, jenž není ovlivněno budoucími prostředky řešení. V našem případě představuje konceptuální model formální popis modelované reality, jehož cílem je získání celkového pohledu na modelovaný systém. Systémová architektura IS UNIZBIP bude využívat standardních softwarových prostředků ČNB. Data, metadata a řídící procedury jednotlivých primárních oblastí a hlavního zpracovatelského modulu budou uložena v příslušné objektově relační databázi Oracle 10g. Řídící procedury jednotlivých primárních oblastí a hlavního zpracovatelského modulu budou napsány v PL/SQL a sdruženy do packages. Uživatelská rozhraní primárních oblastí zpracování a hlavního zpracovatelského modulu budou vytvořena v prostředí Oracle Application Express 4. Analýza dat, tvorba sestav a prezentace výstupů bude řešena prostřednictvím jednotlivých nástrojů OBIEE.
46
Obrázek č. 13: Konceptuální schéma IS UNIZBIP Moduly primárních PZI
FD
PI
Rezervy
Ostatní investice
Ostatní investice
MFI, MA
vláda
Ostatní investice
Důchody a KÚ
ostatní sektory
oblastí zpracování
Služby
Zboží
Ostatní položky prvotních důchodů
Hlavní zpracovatelský modul pro sestavení PB
WEB
(zpracování měsíčních a čtvrtletních dat)
Datový sklad platební bilance
ARAD
Modul pro reporting GESMES/TS
OBIEE
ECB
ČSÚ
WB
Zdroj: vlastní úprava
47
IMF
OECD
BIS
Eurostat
3.3 Shrnutí základních funkčních požadavků Z výše uvedené předběžné studie jsme získali obecný přehled, jaký problém je třeba řešit a jakým směrem se naše řešení bude ubírat. Než přistoupíme k samotnému řešení, shrneme si základní požadavky na budovaný systém a na jeho funkcionalitu. Ke každému požadavku si také řekneme pár základních informací. Jednotná datová základna zdrojových dat Cílem je všechna data potřebná k sestavení PB a IP ČR soustředit ve společné databázi. Předejde se tak redundantním datům a případným nekonzistentním verzím. Také bude možno provést dodatečné formátové kontroly do databáze nahrávaných dat a tím zvýšit jejich kvalitu. Uživatelská rozhraní pro každý dílčí a hlavní modul Cílem je vytvoření co největšího zpracovatelského komfortu pro věcné správce každé oblasti i hlavního modulu. Uživatelská rozhraní budou zejména sloužit k sestavování statistik ze zdrojových dat, řízení revizí a správy metadat. Správa metodik tvorby BP a IP Tento požadavek souvisí s tvorbou uživatelských rozhraní pro jednotlivé moduly. Cílem je umožnit jednotlivým věcným správcům, prostřednictvím UI, pružně reagovat na metodické změny týkající se sestavování požadovaných statistik, bez nutnosti úprav zdrojového kódu IS UNIZBIP. Sestavování všech statistik po jednotlivých měsících Tento požadavek taktéž reaguje na stále se zvyšující požadavky na reporting. Cílem je sjednotit tvorbu všech statistik, s nejrůznější mírou detailu, na měsíčním základě. V praxi to znamená, že veškeré statistiky budou sestavovány s měsíční periodicitou. Sestavování PB a IP v základním geografickém a ekonomickém členění Jednotlivé statistiky je třeba vytvářet v co největším detailu tak, aby bylo možné reagovat na stále se rozšiřující požadavky na reportovaná data. Součástí předpisů, kterými se řídí sestavování a reporting PB a IP, je rozdělení zemí do geografických a ekonomických zón. Tyto zóny se navzájem překrývají a jejich hlavním rozdílem je ta skutečnost, že součástí ekonomických zón jsou i mezinárodní organizace. V tabulce č.1 je uveden příklad geografických a ekonomických zón a jejich součtových pravidel.
48
Tabulka č. 1: Rozdělení zemí do geografických a ekonomických zón Geografického členění Podskupina 1
Podskupina 2
Kód
Název
FR
Francie
GB
Velká Británie
CZ
Česká republika
SK a další
Slovensko
……
……
CA
Kanada
GL
Grónsko
US
Spojené státy americké
E9 – centrální Amerika a další
……
……
……
……
……
E1 - EVROPA
Skupina
V1 - EU27
A5 - EFTA a další E7 - AMERIKA
A1 - SVĚT
Celek
E8 – západní Amerika
E4 - AFRIKA a další
……
Ekonomické členění Celek
Skupina
Podskupina 1
Podskupina 2
E8 – západní Amerika
E7 - AMERIKA W4 a další
1B – organizace spojených národů
a další
7Z – mezinárodní organizace
J6 - EXTRA EURO AREA
A1 - SVĚT
I6 - EURO AREA
a další ……
Zdroj: vlastní úprava
49
Kód
Název
FR
Francie
SK a další
Slovensko
GB
Velká Británie
CZ a další
Česká republika
CA
Kanada
GL
Grónsko
US
Spojené státy americké
……
……
1C
Mezinárodní měnový fond
1D a další
Světová obchodní organizace
……
……
……
……
……
……
……
Jednotný systém revizí Každá sestavovaná základní statistika prochází určitým procesem zpřesňování. Tomuto procesu se říká revize a provádí se prakticky neustále. Je tedy třeba evidovat a uchovávat historii revizí jednotlivých základní statistik a evidovat revize statistik seskupovaných. Jedná se o čtvrtletní a roční statistiky, jenž jsou vytvářeny ze statistik se základní tj. měsíční periodicitou. Jednotné rozhraní pro načtení dat z dílčích modulů do modulu hlavního Jde o nezbytný předpoklad modulárního systému. Jednotlivé dílčí moduly musí být schopny předat data za svoji oblast hlavnímu zpracovatelskému modulu v předepsané struktuře. Příprava dat pro reporting Tato funkcionalita se týká pouze hlavního zpracovatelského modulu. Na základě předepsaných pravidel je třeba celkové statistiky předat, ve stanoveném tvaru, modulu pro reporting „GESMES/TS“. Analýza Zajistit věcným správcům rozsáhlou analytickou práci nad příslušnými primárními oblastmi a celkovými výstupy. Prezentace všech dílčích i celkových sestav Cílem je jednotná prezentace všech výstupů PB a IP v rámci všech dotčených útvarů ČNB.
3.4 Postup řešení Nyní bychom měli mít všechny potřebné informace pro dobrou základní orientaci v námi řešeném příkladě a můžeme přistoupit k samotnému řešení. Protože výše popsaný IS je velice rozsáhlý a požadavky na jednotlivé dílčí moduly se do značné míry vzájemně překrývají a liší se pouze v několika málo specifických záležitostech, bude pro účely této diplomové práce dostačující ukázat si řešení pouze pro jeden vybraný dílčí modul. Postup řešení lze pak s drobnými úpravami použít pro všechny ostatní dílčí moduly, včetně modulu hlavního. Nejprve tedy pár slov o tom, jakým způsobem budeme k řešení přistupovat. Na vývoj IS nahlížíme, prakticky stejně, jako na jakýkoliv jiný projekt. To znamená, že se musíme řídit obecně platnými zásadami a zvolenou metodikou řízení projektu. Pro návrh samotného IS si zvolíme metodiku, kterou se budeme řídit (COBIT, ITIL, MDIS a další), nástroje, jako prostředek pro vývoj, a techniky, jako způsob provedení návrhu. 50
Pro vývoj IS se nejlépe hodí CASE nástroje, sloužící jako podpora týmové práce v průběhu celého cyklu vývoje systému. Zajišťují sdílení rozpracovaných fragmentů a komplexní správu vývoje. Pro náš řešený příklad je použit CASE nástroj „Enterprise Architect verze 8.0“. Ten podporuje projektové řízení jako takové, objektové i strukturované metodiky, objektově orientované modelování (UML), tvorbu dokumentace, testování, provoz a údržbu. Obecně platí, že k získání kvalitního IS a v neposlední řadě k dobré orientaci v návrhu IS, musíme vytvářet modely na různých úrovních vývoje. Tyto modely slouží k získání jasné představy o vyvíjeném systému, všech jeho vazbách a funkcionalitách. Modely lze vytvářet několika způsoby. V našem řešeném příkladě jsou použity diagramy UML.
3.4.1 UML Jazyk UML byl navržen pro objektově orientované modelování a dnes představuje v této oblasti standard. Velkou výhodou je jeho nezávislost neboť není svázán s žádnou konkrétní metodikou. Slouží ke specifikaci, vizuálnímu popisu a dokumentaci částí SW systémů. Diagramy UML nám umožní zachytit budovaný systém z různých pohledů a na různé úrovni abstrakce. Během vývoje prošlo UML řadou změn a v současné době využívá pro modelování 13 základních diagramů, které jsou rozděleny do skupiny dynamické (diagramy chování) a skupiny statické (diagramy struktury). Rozbor všech diagramů jazyka UML není předmětem této diplomové práce a ani není třeba pro náš příklad všechny základní diagramy UML vytvářet. Rozebereme si proto pouze ty nejdůležitější diagramy, se kterými se můžeme případně v této diplomové práci potkat. Ze skupiny diagramů chování, které zachycují časové návaznosti akcí a interakci mezi elementy, se jedná o následující diagramy: -
Diagram aktivit – jedná se o objektově orientované vývojové diagramy, které umožňují také graficky modelovat jednotlivé případy užití, jako posloupnost akcí, jenž mohou probíhat sekvenčně či paralelně. Tyto diagramy, připojené k libovolnému modelovanému prvku, umožní modelovat jeho chování. Diagramy aktivit většinou připojujeme k případům užití, třídám, rozhraním, komponentám. Sémantika diagramu aktivit odpovídá v UML 2.0 Petriho síti (což je matematická reprezentace diskrétních distribuovaných systémů). [01]
-
Stavový diagram – neboli diagramy stavových automatů zachycují jednotlivé stavy objektů a přechod mezi nimi. Používají se především pro popis chování určitého objektu napříč více případů užití. Jejich pomocí modelujeme dynamické chování 51
objektů (třídy, případy užití či celé systémy). Stavový diagram má tři základní prvky [05]: o stavy – situace v životě objektu, během níž objekt splňuje nějakou podmínku, provádí nějakou operaci nebo čeká na událost, o přechody – představují podmínky pro přechod objektu z jednoho stavu do druhého, o události – specifikují výskyt něčeho v čase a prostoru. Pokud nejsou v diagramu uvedeny, znamená to, že přechod do dalšího stavu probíhá automaticky. -
Diagram případu užití – používá se k popisu chování systému z hlediska uživatele a zachycuje, které typy uživatelů se systémem pracují a jaké činnosti v rámci systému vykonávají. Umožňuje znázornit funkční požadavky na systém tím, že popisuje interakci mezi ním a uživateli. Hranice systému (v UML 2.0 označovány jako subjekt) jsou v modelu znázorněny rámečkem kolem případů užití a názvem modelovaného systému. [01]
Mezi nejvyužívanější diagramy struktury, jenž popisující strukturu navrhovaného systému a nezahrnují časový rozměr, patří [01]: -
Diagram tříd – představuje statický pohled na modelovaný systém a jeho úkolem je znázornit typy objektů v systému a jejich vztahy. Návrh tříd, jejich odpovědností a následné vytvoření tohoto diagramu je jedním z prvních a základních kroků analýzy navrhovaného programového systému. Díky tomu že diagram tříd zachycuje pravidla modelovaného systému, je nejdůležitějším podkladem jak pro forward engineering, tak pro reverse engineering. Při tvorbě diagramu tříd je nutné vzít v úvahu jeho účel a rozlišit, zda potřebujeme vyjádřit požadavky na modelovaný software nebo například získat podrobný popis designu.
-
Diagram komponent – slouží k zachycení komponent a závislostí mezi nimi. Můžeme také říci, že diagram komponent zachycuje strukturu budoucího systému. Komponentu můžeme charakterizovat jako zcela zapouzdřenou funkčnost, která je zpřístupněna prostřednictvím rozhraní, pracuje s daty uloženými v databázi či souboru a je zpravidla nezávislá na programovacím jazyce. Jsou-li komponenty dobře navrženy, mohou být opakovaně používány v různých projektech.
-
Diagram nasazení – zachycuje nasazení tvořeného software na hardware na kterém pak bude následně provozován. Zároveň diagram zachycuje propojení použitého
52
technického vybavení. Tvorbě diagramu předchází architektonická implementace. Jedná se o identifikaci architektonicky podstatných komponent a o jejich mapování na fyzických hardware. V závěru této kapitoly je třeba poznamenat, že UML nedefinuje pořadí, ve kterém je třeba diagramy vytvářet. To stanovuje použitá metodika vývoje SW. Nicméně začíná se většinou případem užití.
3.4.2 Návrh řešení modulu FD Jak již bylo řečeno výše, ukážeme si řešení pro jeden vybraný modul. Naším zvoleným modulem jsou Finanční deriváty (FD). Tato oblast je ideální zejména proto, že na jedné straně poskytuje data jak pro PB (toky), tak pro IP (stavy) a můžeme si na ni demonstrovat požadovanou funkcionalitu. Na druhé straně se jedná o poměrně malý a přehledný primární modul, který nám umožní snadnou orientaci v řešeném příkladě. Interakce s uživatelem Na základě řádné a úplné analýzy uživatelských požadavků získáme jasnou představu jaká má být interakce uživatele se systémem. Pro zachycení této interakce použijeme scénáře případu užití. Poté co máme podchycenu veškerou požadovanou komunikaci uživatele se systémem, přistoupíme k tvorbě uživatelského rozhraní. Pomocí tohoto rozhraní bude uživatel posléze se systémem pracovat. V našem případě musíme vybudovat rozhraní pro práci s aplikací databázovou. K tvorbě takovéhoto rozhraní můžeme použít řadu nástrojů v závislosti na používaném operačním systému. Vhodný nástrojů je celá řada a při jeho výběru si musíme zodpovědět zejména následující otázky: -
jak rozsáhlou a komplikovanou úlohu bude uživatelské rozhraní ovládat,
-
jakou datovou základnu úloha využívá,
-
kolik potencionálních uživatelů bude s úlohou pracovat,
-
v jakém softwarovém prostředí bude uživatelské rozhraní fungovat.
V možnostech této diplomové práce není, všechny možné nástroje si, byť jen v krátkosti, představit. Nicméně rád bych uvedl alespoň pár použitelných nástrojů, se kterými mám osobní zkušenost. Při jejich výběru jsem také přihlédl k jejich použitelnosti v informačním prostředí ČNB, které pracuje s operačními systémy Windows a databázemi Oracle. Ve všech případech hovoříme o GUI tedy o grafickém uživatelském rozhraní. MS Access a MS Excel – tyto aplikace umožňují vytvořit jednoduché grafické uživatelské rozhraní pomocí jazyka Visual Basic. Potřebné databázové objekty (tabulky, pohledy) lze 53
s nimi přímo propojit pomocí ODBC nebo rovnou importovat. Rovněž prostřednictvím ODBC lze z vystavěné aplikace pouštět uložené procedury. Výhoda tohoto řešení spočívá ve velké rozšířenosti produktů, velmi přijatelné ceně a v jednoduchosti tvorby. Nevýhodou je pak horší řízení přístupových práv k jednotlivým funkcím uživatelského rozhraní, jednoduchost nástroje a komunikace s databázovým prostředím pomocí rozhraní. Oracle Forms – prostřednictvím Forms Builder lze vytvářet uživatelská rozhraní, která nám umožní data uložená v databázi přímo zobrazit a dle potřeby s nimi nakládat. Prostřednictvím vytvořených formulářů a integrovaných objektů (rozbalovací seznamy, tlačítka, zaškrtávací políčka a podobně), můžeme data vkládat, opravovat či mazat. Používá se zde jazyk PL/SQL. Forms Builder je součástí vývojového prostředí Oracle Developer Suite. Toto prostředí obsahuje další nástroje, neboli komponenty, které pomáhají jak celý projekt řídit, tak vyvářet komplexní sestavy a grafy nad požadovanými daty. Hotovou a zkompilovanou aplikaci pouštíme v prostředí Forms Runtime popřípadě od verze 9i je možné se přímo připojit k aplikačnímu serveru s kontejnerem J2EE. Mezi výhody tohoto nástroje bezesporu patří jednoduchý a rychlý vývoj, přímé propojení s databází, možnost předávání řízení a intuitivní ovládání. Hlavní současnou nevýhodou je fakt, že firma Oracle upřednostňuje pro komplexní vývoj aplikací nástroj „Oracle Application Development Framework“ a tudíž již nechce zajišťovat podporu a nástroj dále rozvíjet. Ve skutečnosti, kvůli velkému odporu vývojářů i uživatelů, je budoucnost Oracle Forms stále otevřená. Oracle Application Express (APEX) – jedná se o webový nástroj, který je plně integrován v databázích Oracle od verze 10g. Lze ho charakterizovat jako jednoduchý a uživatelsky velmi přívětivý nástroj pro vcelku rychlou tvorbu webových aplikací pracujících nad databázemi Oracle. APEX vychází z deklarativní kostry, kde definujeme sadu stránek, na které umisťujeme dostupné šablony a do nich následně vkládáme objekty pro interakci s uživatelem. K tvorbě jednoduchého uživatelského rozhraní si v tomto nástroji vystačíme se základními znalostmi jazyka PL/SQL a HTML. Pokud bychom však chtěli vytvářet komplexnější uživatelská rozhraní, naše znalosti PL/SQL i HTML musí být daleko rozsáhlejší. Mezi jeho největší přednosti patří relativní jednoduchost tvorby, řízení přístupových práv, uložení všech objektů jak nástrojů, tak i vytvořeného uživatelského rozhraní přímo v databázi 54
a přenositelnost mezi operačními systémy. Nevýhodou pak může být nemožnost předání řízení úlohy mimo databázové prostředí, komplikovanost tvorby vlastního designu uživatelského rozhraní a omezení tvorby sofistikovanějších uživatelských rozhraní. Oracle Application Development Framework (ADF) – v současné době se jedná, firmou Oracle, o nejpreferovanější nástroj pro komplexní vývoj webových aplikací postavených na standardu J2EE. Jak ze samotného názvu nástroje vyplývá, ADF je „framework“, neboli v českém překladu trochu nepřesně, rámec. V praxi to znamená, že velké množství funkcionality nástroje je obsaženo v množině knihoven. Přidávat či měnit tuto funkcionalitu je pak možné vytvářením specifických „business“ komponent. Nástroj ADF je založen na „Model-view-controller“ (MVC) architektuře, která od sebe odděluje datový model, řídící logiku a uživatelské rozhraní do tří samostatných komponent. Výhoda tohoto řešení spočívá zejména v tom, že změna provedená v jedné komponentě má minimální vliv na komponenty ostatní. Na obrázku č. 14 můžeme vidět MVC architekturu nástroje ADF. Podíváme se podrobněji na jednotlivé vrstvy [20]: -
Business service layer – tato vrstva řídí přístup k datům a zapouzdřuje business logiku. Můžeme si pod tím představit příklad definování databázových objektů jako jsou tabulky do XML dokumentů,
-
Model layer – reprezentuje hodnoty vztažené k aktuální stránce,
-
Controller layer – zde se zpracovávají uživatelské vstupy a určuje navigace stránek,
-
View layer – zahrnuje samotné uživatelské rozhraní pro práci s daty a řízení aplikace. Toto rozhraní je vytvořeno v JavaServer Faces (JSF). ADF k tomu navíc poskytuje širokou paletu komponent, jako jsou grafy, vodící lišty, mapy či ukazatele.
Nespornou výhodou tohoto nástroje je fakt, že se jedná o moderní a komplexní nástroj s rozsáhlou podporou. S jeho pomocí lze vytvářet rozsáhlé webové aplikace. Ovšem z jeho výhod logicky vyplývá i jeho největší slabina a to přílišná komplikovanost nástroje. Pro úspěšné zvládnutí je třeba poměrně obsáhlé studium a značná znalost různých typů jazyků či skriptů (Java, CSS, HTML, Java Skript).
55
Obrázek č. 14: Model-view-controller architektura
Zdroj: http://docs.oracle.com/cd/E12839_01/web.1111/b31974/intro.htm [20] Závěrem je třeba říci, že nástroj ADF, především pro svou složitost, není zatím příliš oblíben a vývojáři, pracující s databázemi Oracle, tam kde to jen trochu jde, upřednostňují nástroje Oracle Developer Suite (Forms) a APEX. Uživatelské rozhraní Uživatelské rozhraní pro všechny moduly bude vytvořeno v nástroji APEX verze 4. Tento výše představený nástroj jsem zvolil především pro možnost poměrně jednoduché tvorby i sofistikovanějších aplikací za předpokladu dobré znalosti jazyka PL/SQL a HTML. V neposlední řadě jsem tento nástroj vybral s ohledem na velkou intuitivnost při ovládání, takto vytvořeného rozhraní uživatelem. Na obrázku č. 15 je zachycen scénář případů užití. Tento scénář znázorňuje identifikovanou interakci uživatele se systémem, která bude probíhat právě pomocí vytvořeného uživatelského rozhraní. Hotové uživatelské rozhraní, respektive ukázka jeho grafického vzhledu, se nachází v příloze č. 2 této diplomové práce.
56
Obrázek č. 15: Scénář případu užití modulu FD
Zdroj: Enterprise Architect - vlastní tvorba
3.4.3 Návrh datové struktury Musíme vytvořit takovou datovou základnu, která umožní jednoduchým a efektivním způsobem splnit základní uživatelské požadavky jak na funkcionalitu, tak na tvorbu výstupních sestav. Patří sem zejména rozpad, neboli drilování, geografických a ekonomických zón na jednotlivé země, dále rozpad součtových položek na jednotlivé základní položky (Bop Items) a taktéž účinný systém revizí, který umožní načítat a zobrazovat měsíční sestavy v příslušných čtvrtletích a letech. Rovněž musíme vzít v úvahu fakt, že uživatel nebude komunikovat s databází přímo, tedy prostřednictvím dotazovacího jazyka, ale bude své dotazy jednoduchým způsobem skládat v prostředí Oracle Answers, jež je součástí OBIEE.
57
Z těchto důvodů vytvoříme nad určitými tabulkami pohledy (views), které nám posléze usnadní práci při návrhu metadat BI Serveru a umožní tvorbu dimenzí. Na obrázku č. 16 máme zachycen diagram tříd pro několik základní objektů našeho příkladu. Jsou na něm uvedeny, vedle primární datové tabulky a potřebných metadat, také 2 pohledy. Ty jsou vytvořeny z metadat a jejich struktur. Nemají žádnou přímou vazbu na datovou tabulku, ale, jak si ukážeme později, pro přípravu metadat BI Serveru nám poslouží lépe a efektivněji než původní tabulky. Obrázek č. 16: Digram tříd modulu FD - IS UNIZBIP
Zdroj: Enterprise Architect - vlastní tvorba
58
Příprava view pro strukturu FD Na struktuře položek FD si ukážeme přípravu view pro tvorbu dimenzí v metadat modelu BI Serveru. Každá položka, ať už primární či součtová, struktury FD (viz. příloha č. 3) má svůj jednoznačný identifikátor, neboli Bop Item. Datová tabulka FD_FD obsahuje, z logických důvodů, pouze spočítaná data primárních položek za aktiva a pasiva. Musíme tedy zajistit jejich načítání do součtových položek a propočet salda (aktiva-pasiva). Za tímto účelem vytvoříme view FD_STRUKTURA nad tabulkou UNIZBIP_ITEMS, jenž obsahuje Bop Items všech dílčích modulů IS UNIZBIP a tabulkou FD_ITEMS, kde máme připravenou strukturu pro FD. Vytvořením view dostaneme potřebnou strukturu včetně názvů jednotlivých Bop Items. Na obrázku č. 17 je ukázána část atributů (sloupců) vytvořeného view. Jelikož se pasiva ukládají jako kladné hodnoty, je třeba pro výpočet salda (aktivapasiva) zajistit jejich přenásobení hodnotou -1. K tomuto účelu slouží sloupec „ROZDIL“. Obrázek č. 17: Záznamy v tabulce FD_STRUKTURA TOTAL 910 910 910 910 910 910
NAZEV_T FINANČNÍ DERIVÁTY - SALDO FINANČNÍ DERIVÁTY - SALDO FINANČNÍ DERIVÁTY - SALDO FINANČNÍ DERIVÁTY - SALDO FINANČNÍ DERIVÁTY - SALDO FINANČNÍ DERIVÁTY - SALDO
LEVEL1 LEVEL2
ITEM
NAZEV_I
ROZDIL
900
902
902_S.1311 Ústřední vládní instituce
1
900
902
902_S.1312 Národní vládní instituce
1
900
902
902_S.1313 Místní vládní instituce
1
905
908
908_S.1221 Banky
-1
905
909
909_S.11
Nefinanční podniky
-1
905
909
909_S.14
Domácnosti
-1
Zdroj: Vlastní úprava Návrh systému revizí Dle výše specifikovaných uživatelských požadavků je třeba zajistit, aby bylo možné spočítané statistiky zafixovat. V případě potřeby pak musí být uživatel schopen provést revizi dané statistiky za zvolené období a následně tuto revizi opět zafixovat. Tato funkcionalita musí být schopna provádět fixaci pro veškeré statistiky s měsíční, čtvrtletní a roční periodicitou. Jedná se o společnou funkcionalitu pro všechny dílčí moduly včetně modulu hlavního. Systém revizí se bude skládat ze čtyř databázových tabulek, jednoho view a package, která bude obsahovat procedury pro řízení tohoto systému. Na obrázku č. 18 je zachycen diagram
59
tříd pro systém revizí, z něhož si můžeme udělat obecnou představu jak jsou databázové objekty, v našem případě tabulky a view, provázány. Obrázek č. 18: Digram tříd systému revizí
Zdroj: Enterprise Architect - vlastní tvorba Popíšeme si princip fungování: -
systém revizí je aktivován v okamžiku, kdy věcný správce příslušné oblasti provede, prostřednictvím UI, sestavení měsíční statistiky ze zdrojových dat,
-
provede se kontrola na existenci záznamu rozpracované statistiky za inkriminované období v příslušné databázové tabulce. V případě že takový záznam existuje, řídící procedura uzavře systém revizí. V opačném případě dojde k založení záznamu o rozpracované měsíční revizi do patřičné databázové tabulky. Z obrázku č. 19 si lze udělat představu, jakou má takový záznam strukturu,
60
Obrázek č. 19: Záznam v db tabulce měsíčních revizí ID
MODUL 1
ZBOZI
MESIC
REVIZE
2011/6
Jednoznačný identifikátor - dodávaný sekvencí
NAHRANO 0
SYSDATE
POZNAMKA Vzor
Default „null“ – editace prostřednictvím UI
Default „0“ – rozpracovaná revize
Zdroj: vlastní tvorba -
dále bude provedena kontrola, zda existuje k tomuto záznamu odpovídající záznam čtvrtletní a roční rozpracované revize. V případě že ne, dojde k jeho založení do příslušných databázových tabulek. Struktura záznamu je obdobná tomu, jaká je ukázána na obrázku č. 19,
-
v okamžiku, kdy známe identifikátory všech rozpracovaných period (měsíční, čtvrtletní a roční), provede se záznam do řídící databázové tabulky systému revizí. Na obrázku č. 20 je uvedena ukázka takového záznamu,
-
při zafixování rozpracovaného období se provede i aktualizace v systému revizí. U patřičného záznamu rozpracovaného období se aktualizuje číslo revize z pracovního stavu 0. ID (jednoznačné identifikátory) čtvrtletí i roku zůstávají stejné dokud není příslušné období zařazeno do nějaké zafixované čtvrtletní nebo posléze roční revize, Obrázek č. 20: Záznam v řídící db tabulce systému revizí MODUL ZBOZI
OBDOBI
ID_M
1.6.2011
ID_C 1
Období formát (date), ke kterému je statistika sestavována
ID_R 42
155
Cizí klíče záznamů v příslušných db tabulkách daných period
Zdroj: vlastní tvorba -
rušení záznamů v systému revizí se provádí v UI dle pokynu věcného správce. Rušení probíhá kvůli zajištění konzistence od nejdelší periody, tedy roku, 61
-
při mazání čtvrtletních revizí se provádí kontrola, zda existuje zařazení čtvrtletní revize v jiné než rozpracované revizi roku. Pokud ano - výmaz nebude proveden dokud není zrušena příslušná roční revize,
-
rušení měsíční (primární) revize předchází kontrola zda je tato revize zařazena v jiné než rozpracované revizi čtvrtletí. Pokud ano - výmaz nebude proveden dokud není zrušena příslušná čtvrtletní revize. Jelikož se jedná o rušení revize fyzicky uložených spočítaných dat, dojde taktéž k jejich smazání z příslušné datové databázové tabulky.
3.4.4 Příprava metadat BI Serveru V této kapitole si rozebereme způsob a postup přípravy metadat BI Serveru pomocí nástroje Oracle BI Administration Tool verze 10. Oracle BI Server jsme si podrobněji popsali v kapitole 2.5.1 a tudíž si zde nebudeme popisovat detailní možnosti tvorby metadat. Zaměříme se pouze na řešený příklad a v logickém sledu si projdeme všechny nezbytné úkony potřebné k přípravě metadat a jejich uložení v repository BI Serveru. K přípravě metadat přistoupíme v okamžiku, kdy máme vytvořenou strukturu všech potřebných databázových objektů a současně máme k dispozici dostatek testovacích dat. Testovací data jsou nezbytná pro řádné otestování a odladění připravených metadat. Obecně přitom platí, že čím kvalitněji máme navrženou potřebnou datovou strukturu, tím snadněji a rychleji se nám vytváří příslušný metadata model. Fyzická vrstva V této vrstvě provedeme dva základní úkony. Import neboli namapování všech potřebných objektů a v případě potřeby jejich následné propojení. V našem případě provedeme import vybraných databázových objektů popsaných v diagramů tříd modulu FD a systému revizí Jedná se o tyto objekty: -
FD_FD – datová tabulka spočítaných dat (prostřednictvím UI) za oblast FD,
-
FD_STRUKTURA – view obsahující součtová pravidla a strukturu FD,
-
UNIZBIP_REVIZE_OBIEE – view vazeb mezi měsíčními, čtvrtletními a ročními revizemi,
-
UNIZBIP_VADEM_ZONES – view obsahující členění zemí do geografických a ekonomických zón dle požadavků ECB a Eurostatu.
Po provedení importu vytvoříme takzvané „aliasy“ (kopie) importovaných objektů. Vytváření aliasů není v mnoha případech nezbytné, nicméně se jedná o „best practise“ neboli
62
doporučenou praxi. Důvodem je větší přehlednost, transparentnost a v neposlední řadě možnost záměny „zdrojové tabulky“ aliasu bez vlivu na jiné vrstvy metadat. Bez aliasů se však neobejdeme v případě, kdy je třeba zabránit tzv. cirkulárnímu spojení mezi tabulkami. Tato spojení vznikají v okamžiku, kdy tabulka či tabulky mají vícenásobnou vazbu na jinou tabulku. Názorným příkladem mohou být dvě tabulky. Jedna faktová a druhá obsahující časové dimenze. Mezi nimi existují dvě vazby cizího klíče (FK). Jednou se jedná o datum otevření a podruhé o datum uzavření. V takovém případě je pak nezbytné vytvořit nad tabulkou, jenž představuje dimenze času, dva aliasy a spojení s faktovou tabulkou provést těmito aliasy. V našem řešeném příkladě budeme postupovat v souladu s doporučenou praxí a nad každým importovaným objektem vytvoříme příslušný alias. Při pojmenování aliasů je vhodné dodržet určitá pravidla, abychom zajistili co největší přehlednost. Alias objektu obsahující fakta označíme předponou „Fact“ a pro objekty obsahující dimenze použijeme předponu „Dim“. Samotné provázání objektů provedeme ve fyzickém diagramu našeho nástroje. Tento diagram nám zobrazí importované objekty v grafické podobě (jako obdélníky se jmény objektů), mezi kterými můžeme vytvořit požadovaná spojení. Ta nám posléze umožní vytvářet sestavy napříč propojenými objekty bez nutnosti tato spojení definovat pokaždé, když potřebujeme data z více objektů. Při propojování objektů pomocí jednoho cizího klíče použijeme jednoduché spojení a tam kde máme provázání složitější (například složený klíč), použijeme spojení komplexní. Na výběr máme prakticky všechny myslitelné druhy spojení, jako jsou spojení rovností, nerovností či spojení s přesahem a další. Na obrázku č. 21 je zachycena fyzická vrstva obsahující importované objekty a jejich vytvořené aliasy, diagram s vytvořenými komplexními spojeními a ukázkou detailu takového spojení.
63
Obrázek č. 21: Diagram fyzické vrstvy
Zdroj: Oracle BI Administration Tool – vlastní tvorba Business vrstva V momentě, kdy máme namapované všechny potřebné objekty a vytvořené požadované vazby, můžeme přistoupit k transformaci fyzického datového modelu do business modelu. Výsledkem je „star schéma“ neboli schéma hvězdy s logickými dimenzemi a fakty. V této prostřední části vytváříme a definujeme jednotlivé dimenzní hierarchie, vypočtené či odvozené ukazatele a taktéž můžeme definovat vlastní agregace nebo kalkulace. Začneme tím, že v business vrstvě vytvoříme čtyři nové objekty jako logické tabulky. Při jejich pojmenování se přidržíme konvence pro pojmenovávání aliasů ve fyzické vrstvě. To znamená, že logické tabulky obsahující dimenze budou mít předponu „Dim“ a faktové „Fakt“. Tímto způsobem si přehledně upořádáme a označíme budoucí role logických tabulek. Na obrázku č. 22 je znázorněn postup tvorby logických tabulek v business vrstvě.
64
Obrázek č. 22: Business vrstva 1
Zdroj: Oracle BI Administration Tool – vlastní tvorba Následně přiřadíme vytvořeným logickým tabulkám příslušné zdroje. V našem případě půjde o jednoduché přetažení příslušného aliasu z fyzické vrstvy do odpovídající logické tabulky v business vrstvě. Dalším krokem je definice logických klíčů u dimenzních logických tabulek. Definice těchto klíčů je nezbytná pro pozdější vytvoření schématu „star“. Zároveň nastavíme počáteční (default) pravidlo agregace pro logické sloupce faktové tabulky, jenž obsahují metriky. V našem případě se jedná pouze o jeden logický sloupec, kde nastavíme součet (sum) „Fact_FD_FD.HODNOTA“. V této vrstvě se rovně nastavují případné filtry (klauzule WHERE) pro jednotlivé logické tabulky. Podmínky výběru, které zde uvedeme, se stanou součástí vytvořeného a uloženého modelu metadat v repositury BI Serveru a všechny sestavy vytvořené nad těmito metadaty jsou jimi limitovány. Z tohoto důvodu je třeba k jejich definici přistupovat obezřetně a pokud je to jen trochu vhodné, ponecháme co nejširší možnost filtrace až tvůrci sestav či konečnému
65
uživateli. V našem případě tedy nastavíme pouze jeden filtr a to v logické tabulce „Dim UNIZBIP_REVIZE_OBIEE“, kde omezíme možnost výběru pouze na primární modul FD. Obrázek č. 23 zachycuje business vrstvu s vytvořenými logickým tabulkami, přiřazenými zdroji, definovanými logickými klíči, nastaveným počátečním pravidlem agregace u použité metriky a definovaným filtrem. Obrázek č. 23: Business vrstva 2
Zdroj: Oracle BI Administration Tool – vlastní tvorba V tomto okamžiku můžeme přistoupit k definici logického schématu „star“, který je nezbytný pro rozdělení rolí logických tabulek na dimenzní a faktové. V business vrstvě si otevřeme business model diagram, kde pomocí komplexních spojení, prostým tahem vedených směrem od dimenzní tabulky k tabulce faktové, vytvoříme požadovanou vazbu. Zároveň s vytvořeným spojením se nám změní barva ikony logických tabulek představujících dimenze. Z původní žluté se změní na bílou, zatímco u faktových tabulek nadále zůstává barva ikony žlutá. Komplexní spojení mezi logickými tabulkami je na úrovni business modelu jediným povoleným typem vazby. Neudává se zde podmínka spojení jako ve fyzické vrstvě a kardinalita vazby určuje roli tabulky. Tabulka odkud vedeme spojení má kardinalitu 1 a značí tak dimenzi, opačná tabulka má kardinalitu N a značí tabulku faktovou. Na obrázku č. 24 je
66
zachyceno vytvořené schéma „star“ našeho řešeného příkladu s detailem jedné z vazeb mezi dimenzní a faktovou tabulkou. Obrázek č. 24: Business model diagram
Zdroj: Oracle BI Administration Tool – vlastní tvorba Po definici logického schématu v business model diagramu máme připravenou základní strukturu metadat. Nicméně za současného stavu bychom nemohli vytvořit sestavy umožňující rozpady vrcholových položek logických dimenzních tabulek na stanovenou úroveň detailu. K využití této funkcionality je třeba v business modelu definovat objekty dimenze (s hierarchiemi), které umožňují tuto možnost rozpadů, neboli „drilování“ v rámci sestav. Taktéž musíme mít připravenou vhodnou strukturu tabulek, které slouží jako zdroje pro logické dimenzní tabulky. V našem řešeném příkladě vytvoříme takovéto dimenze nad všemi logickými dimenzními tabulkami. Cílem je umožnit koncovým uživatelům vytvářet sestavy dovolující následující rozpady: -
FD_STRUKTURA (TOTAL LEVEL1 LEVEL2 ITEM)
67
-
UNIZBIP_REVIZE_OBIEE (ROK CTVRTLETI MESIC)
-
UNIZBIP_VADEM_ZONES (TOTAL LEVEL1 LEVEL2 LEVEL3 LEVEL4 KOD)
Postup tvorby je ve všech případech stejný a liší se hlavně pouze počtem vytvořených úrovní jednotlivých hierarchií. Z tohoto důvodu si detailní postup ukážeme (krok za krokem) pouze na definici úrovní hierarchie pro dimenzi struktury modulu FD. Jednotlivé úrovně definujeme z pravidla sestupně od nejvyšší po nejnižší: -
začneme vytvořením nového objektu dimenze v business modelu,
-
následně vytvoříme nejvyšší logickou úroveň dané dimenze (ta je povinná pro každou dimenzi), pojmenujeme ji například „ALL“ a označíme jako „Grant Total Level“, jenž má přednastaven počet prvků úrovně na 1,
-
vytvoříme první podřízenou úroveň „child level“ s názvem „TOTAL“, o přiřadíme logický sloupec či sloupce (opět prostým přetažením pomocí myši). V našem případě se jedná o sloupce TOTAL a NAZEV_T, o definujeme klíč či klíče úrovně (z přiřazených logických sloupců), které jednoznačně identifikují danou úroveň a budou použity pro rozpad na tuto úroveň v sestavách, o stanovíme počet prvků úrovně. Hodnota nemusí být naprosto přesná, postačí nám pouhý „DISTINCT“ prvků dané úrovně. Jen musíme dodržet pravidlo, že každá další úroveň musí mít hodnotu vyšší než předcházející,
-
vytvoříme druhou podřízenou úroveň „child level“ s názvem „L1“, o zde přiřadíme logický sloupec LEVEL1 a provedeme stejné úkony jako v první podřízené úrovni,
-
vytvoříme třetí podřízenou úroveň „child level“ s názvem „L2“, o postup opět stejný za použití logického sloupce LEVEL2,
-
vytvoříme čtvrtou podřízenou úroveň „child level“ s názvem „ITEM“, o v této úrovni použijeme dva sloupce ITEM a NAZEV_I a oba označíme jako klíče úrovně.
Stejným způsobem pak vytvoříme zbylé dimenze. Na obrázku č. 25 je zobrazena celá struktura business vrstvy s detailem popsané dimenze.
68
Obrázek č. 25: business vrstva – dimenze
Zdroj: Oracle BI Administration Tool – vlastní tvorba Vytvoření dimenzí byl poslední nezbytný krok k přípravě takové business vrstvy, která kompletně pokryje potřeby našeho řešeného příkladu. Nyní tedy můžeme přistoupit k závěrečné fázi přípravy metadat. Prezentační vrstva Tato nejvyšší vrstva metadat BI Serveru je přístupná všem uživatelům bez rozdílu znalostí jazyka SQL. Je tedy velmi důležité připravit ji velmi srozumitelně tak, aby práce všech uživatelů při tvorbě sestav byla co nejintuitivnější. Strukturu prezentačního katalogu tedy vytvoříme za pomoci zástupných názvů (s případným využitím diakritiky) pro jednotlivé logické sloupce a vhodného jednoduchého hierarchického členění. Začneme vytvořením nového prezentačního katalogu v jehož rámci vytvoříme jednotlivé prezentační tabule. Jedná se vlastně o složky, do kterých přiřadíme připravené logické sloupce a vytvoříme tak tabulky, jenž odpovídají logice definované business vrstvy. Pod vytvořeným prezentačním katalogem „UNIZBIP“
založíme následující prezentační
tabule: -
„Finanční deriváty“ – vrcholová složka pro primární modul FD o Období – Struktura – Země – Parametry – Metriky
69
Nyní přiřadíme do jednotlivých složek odpovídající logické sloupce z business vrstvy a tam, kde je to vhodné, vytvoříme alias k původnímu jménu příslušného sloupce. Posledním krokem v přípravě prezentačního katalogu je vystavění jednoduché hierarchické struktury z vytvořených prezentačních složek. Nástroj Oracle BI Administration Tool primárně nepodporuje adresářovou strukturu prezentačního katalogu. Nicméně pomocí jednoduchého řešení lze jednostupňovou strukturu vytvořit. Do popisu složek, jenž hodláme vnořit do složky vrcholové (kořene), musíme vložit výraz „->“. Tato úprava se projeví pouze v nástroji pro tvorbu sestav (BI Answers). Zde, v prezentačním katalogu, není tato adresářová strukturu viditelná. Na obrázku č. 26 je zobrazena kompletní prezentační vrstva pro náš řešený příklad s detailem jedné z vnořených složek a s příkladem vytvořeného aliasu nad jedním z logických sloupců zařazených do prezentačního katalogu. Obrázek č. 26: Prezentační vrstva
Zdroj: Oracle BI Administration Tool – vlastní tvorba Nastavení přístupových práv Jedná se o poslední důležitý úkon v přípravě metadata modelu před jeho nasazením. Přístupová práva nastavujeme pro prezentační katalog a práva lze přiřadit jak na celý katalog, tak na jednotlivé prezentační složky a sloupce.
70
Přístupová práva lze přiřazovat jednotlivým databázovým účtům nebo založeným aplikačním skupinám, kterým jsou přiřazeny konkrétní databázové účty. V praxi se využívají převážně aplikační skupiny. Důvodem je vyšší bezpečnost, přehlednost a snadnější správa. Pro IS UNZIBIP byly vytvořeny aplikační skupiny k jednotlivým primárním modulům. Pro náš řešený modul (FD) použijeme dvě uživatelské skupiny pro různé skupiny uživatelů. Dále pak jednu skupinu pro administrátory tohoto modulu a rovněž nesmíme zapomenout na skupinu pro vývojáře úlohy. Nastavení přístupových práv je zachyceno na obrázku č. 27. Vzhledem k významu, jaký problematika řízení přístupových práv pro úlohy OBIEE zaujímá, je jí věnována samostatná kapitola 4.2 této diplomové práce. Obrázek č. 27: Nastavení přístupových práv pro prezentační katalog
Zdroj: Oracle BI Administration Tool – vlastní tvorba Závěr V této části diplomové práci jsme si ukázali přípravu jednoduchého metadat modelu. V zásadě můžeme při tvorbě modelu postupovat dvěma základními způsoby: -
jednoduchý model – zde není nutné vytvářet nejrůznější metriky, neboť prakticky veškerá výpočetní činnost je obsažena v řídících procedurách dané úlohy. Zaměřujeme se především na vytvoření modelu umožňující co nejvariabilnější pohledy na spočítaná data,
-
komplexní model – tady naopak definujeme mnoho výpočetních položek, neboť největší tíha zpracování leží na bedrech BI Serveru. Základním předpokladem je dobře navržená struktura potřebných databázových objektů. 71
Při definici metadat ostatních primárních oblastí IS UNIZBIP postupujeme obdobným způsobem a dbáme na zajištění přehledné organizace kompletního metadat modelu IS UNIZBIP. Během tvorby je rovněž vhodné a žádoucí si správnost postupu průběžně ověřovat kontrolou konzistence vytvářeného modelu „check global consistency“.
3.4.5 Tvorba sestav Poté co jsme si připravili metadata, můžeme přistoupit k tvorbě sestav určených pro prezentaci a případnou následnou analytickou činnost. Stejně jako v případě tvorby metadata modelu není účelem této kapitoly představit všechny možnosti a způsoby tvorby sestav v nástroji BI Answers. Zaměříme se především na tvorbu sestavy pro prezentaci platební bilance pro náš řešený primární modul FD (Finanční deriváty). Na této sestavě si podrobně ukážeme možné postupy. Sestava – Celkový přehled vrcholové položky FD pro platební bilanci ČR Cílem sestavy je zobrazení vrcholové položky v nejvyšším členění (za svět celkem) na straně aktiv, pasiv a bilance (aktiva-pasiva). Položku je třeba členit po měsících, načítat do čtvrtletí a roku. V grafu pak ukázat měsíční vývoj platební bilance na straně aktiv a pasiv během jednoho kalendářního roku. K vytvoření takovéto složené sestavy použijeme kontingenční tabulku a graf, který bude z této tabulky vycházet. Začneme tím, že si v BI Answers otevřeme naši cílovou oblast „UNIZBIP“. Nejedná se o nic jiného než o prezentační katalog definovaný v rámci tvorby metadata modelu. Následně z tohoto katalogu vybereme potřebné sloupce pro požadovanou kontingenční tabulku a nastavíme potřebné filtry výběru, vlastnosti jednotlivých sloupců a případné další funkce. Na obrázku č. 28 jsou zobrazeny vybrané sloupce s ukázkou možnosti použití funkce a filtru. Taktéž si zde můžeme povšimnout námi vytvořené jednoduché hierarchické struktury prezentačního katalogu.
72
Obrázek č. 28: Tvorba sestavy – výběr sloupců pro zobrazení a nastavená kritéria
Zdroj: Oracle BI Answers – vlastní tvorba V okamžiku, kdy jsme nastavili všechna požadovaná kritéria, přistoupíme k přípravě samotné sestavy. Přepneme se na záložku výsledky, kde si vybereme z rozvíracího seznamu kontingenční tabulku. Zde opět můžeme pracovat s nastavením jednotlivých vybraných sloupců, vytvořit nově dopočítané položky, popřípadě nastavit sloupce pro výběr. Definice naší kontingenční tabulky je zachycena na obrázku č. 29. Vedle běžných nastavení kontingenční tabulky jako jsou řádky, sloupce a míry, zde můžeme definovat další možnosti zobrazení jako je například oddíl stránky, který slouží k vytvoření rozvíracích seznamů pro filtraci zobrazení. Můžeme zde umístit libovolné množství sloupců a vytvořit z nich jednoduché či složené rozvírací seznamy. My jsme zde umístili sloupce „Rok“ a „Revize R“ pro složený rozvírací seznam (kombinace všech hodnot použitých sloupců). Při zapnuté funkci „Zobrazit výsledky“ si můžeme ihned zkontrolovat výsledné zobrazení dle nastavených pravidel. Při každé změně definice tabulky dojde automaticky k překreslení tohoto zobrazení.
73
Obrázek č. 29: Tvorba sestavy – definice kontingenční tabulky
Zdroj: Oracle BI Answers – vlastní tvorba Nyní můžeme přistoupit k vytvoření odpovídajícího grafu. Ze stejného seznamu, z jakého jsme vybírali kontingenční tabulku, vybereme diagram. V návrhu diagramu máme automaticky přednastaveny sloupce definované v kontingenční tabulce. Na nás je, abychom zvolili odpovídající diagram, nastavili osu x, y a další parametry dle zvoleného typu diagramu. V našem případě použijeme pruhový svislý graf, pro který nastavíme všechny potřebné vlastnosti včetně měřítka os. Definice diagramu pro naši kontingenční tabulku je zachycena na obrázku č. 30. Posledním krokem, který nás čeká, je kompletace všech připravených částí sestavy do jednoho celku. Pro toto sestavení vybereme volbu složeného rozložení (ze stejného seznamu jako v předchozích případech) a postupně přidáme všechny předpřipravené pohledy, diagramy, míry, filtry, popisky. V neposlední řadě můžeme také umožnit výběry dodatečných sloupců do připravených pohledů či zobrazit vytvořený logický dotaz SQL a další. V našem případě, obrázek č. 31, použijeme do konečné sestavy kontingenční tabulku a diagram a taktéž přidáme nadpis. Nastavíme ovládací prvky pro případný export do formátu PDF a pro tisk sestavy.
74
Obrázek č. 30: Tvorba sestavy – definice diagramu
Zdroj: Oracle BI Answers – vlastní tvorba Obrázek č. 31: Tvorba sestavy – složené rozložení
Zdroj: Oracle BI Answers – vlastní tvorba Takto vytvořená sestava je plně interaktivní. Uživateli je umožněno, díky nadefinovaným dimenzím v metadata modelu, rozložit si sestavu „kliknutím“ na souhrnné sloupce „Svět“, 75
„Aktiva“ a „Pasiva“ do jednotlivých úrovní až na konečné detailní položky. Zároveň s tím, jak se uživatel vnořuje do detailu sestavy, mění se i diagram. Na obrázku č. 32 je ukázána výsledná sestava rozložená do detailu položek tvořících aktiva. Obrázek č. 32: Příklad rozpadu výsledné sestavy
Zdroj: Oracle BI Answers – vlastní tvorba
76
Závěr Ukázali jsme si jeden z možných způsobů tvorby sestavy, kterou můžeme vytvořit z námi připraveného modelu metadat. Možnosti tvorby sestav v nástroji BI Answers jsou nicméně daleko rozsáhlejší a v rukou zkušeného uživatele představují mocný analytický nástroj. Všechny vytvořené sestavy můžeme přímo, s různými právy manipulace se sestavou, zpřístupnit daným uživatelům nebo vytvořit interaktivní panel (Dashboard) a sestavy na něj vyvěsit. Pro sestavy našeho vzorového příkladu použijeme jeden takový panel, jehož tvorbu si rozebereme v následující kapitole. Nakonec si zmíníme pár praktických rad pro pokročilé tvůrce sestav. Předně musíme mít na paměti, že základem pro úspěšnou a komplexní tvorbu sestav je dobře připravený model metadat s jasnou a intuitivní prezentační vrstvou. Dále bychom měli při tvorbě sestav: -
využít možnosti, jenž nabízejí kaskádové styly (CSS), které se nastavují ve vlastnostech sloupců. Například „white-space:nowrap“ zabrání automatickému zalamování hodnot či znaků do okna prohlížeče. Vše bude na jednom řádku,
-
maximálně využít funkce pro jednotlivé sloupce. Zde můžeme vkládat proměnné, dopočítávat hodnoty či použít příkazy PL/SQL. Příkladem může být situace, kdy máme znakový sloupec, jenž obsahuje číselné hodnoty a má tzv. vodící nuly. Typickým příkladem je IČO subjektu (00195251). V okamžiku, kdy si uživatel stáhne sestavu s tímto sloupcem do excelu, ztratí všechny vodící nuly. K zamezení tohoto jevu
je
třeba
použít
funkci
„‘
style="mso-number-format:\@">'||
[jmeno_sloupce]|| '
pro velké sestavy vytvořit výzvy. Tyto výzvy slouží k dynamickému filtrování na základě hodnot vybraných uživatelem. V rámci definice výzev je vhodnější použít pro zobrazení hodnot vlastní SQL dotaz. S jeho pomocí můžeme výběrové hodnoty lépe ošetřit (filtrace, řazení apod.),
v každé nadefinované sestavě nezapomenout využít možnosti pokročilého nastavení. Zde můžeme upravit automaticky vygenerovaný kód SQL pro danou sestavu. Tato funkcionalita je velmi vhodná například při tvorbě složitějších výběrových podmínek, které nelze definovat v návrhu sestavy. Dále zde můžeme zasáhnout do vygenerovaného XML požadavku a v neposlední řadě je dobré zaškrtnout volbu vynechání mezipaměti webu „Oracle BI Presentation Services Cache“. Sestavy budou sice o trochu pomalejší, zato bude mít uživatel vždy aktuální data.
3.4.6 Tvorba interaktivních panelů Jedná se o poslední fázi tvorby úlohy OBIEE. Interaktivní panely vytváříme v nástroji BI Interactive Dashboards. Vytvořením příslušného interaktivního panelu, do kterého přidáme požadované a vytvořené sestavy, získáme komplexní analytickou úlohu. Začneme tím, že ve správě interaktivních panelů vytvoříme nový panel s názvem „Finanční deriváty“, který bude při nasazení do testovacího a posléze produkčního prostředí zařazen do skupiny UNIZBIP mezi panely ostatních primárních oblastí. Přepneme se do editoru vytvořeného panelu a případně přidáme do panelu další stránky. Každou stránku pak můžeme upravit dle potřeby. Můžeme přidat sloupce a oddíly, u kterých se nastavují nejrůznější parametry, od barvy pozadí až po možnost použití kaskádových stylů. Do oddílů se následně vkládají vytvořené sestavy, texty, odkazy řízené navigace, také lze vložit obsah z webové stránky či obrázek. Ke každému takto vloženému objektu pak můžeme nastavit příslušná přístupová práva (podrobněji v kapitole 4.2). Náš panel bude obsahovat 3 stránky: -
Celkový pohled – tato stránka obsahuje sestavy v nejvyšším členění, jak pro platební bilanci tak pro investiční pozici. Na této stránce bude umístěna i naše příkladová sestava,
Detailní pohled – zde se nalézají sestavy v nejnižším členění, jenž jsou určeny pro detailní analýzy příslušných věcných správců,
ECB - GEO – na této stránce jsou sestavy určené pro reporting do příslušných orgánů EU.
Na obrázku č. 33 je znázorněn editor panelu s návrhem stránky pro Celkový pohled. Tato stránka je rozdělena do dvou sloupců. Jeden pro platební bilanci a druhý pro investiční pozici. V každém sloupci je jeden oddíl a v něm příslušná sestava. V rámci každého oddílu můžeme nastavit řadu vlastností a parametrů, od řízené navigace až po možnost sbalitelnosti oddílu uživatelem při práci v rámci panelu.
Obrázek č. 33: Tvorba interaktivního panelu
Zdroj: Oracle BI Interactive Dashboards – vlastní tvorba Pro jednotlivé sestavy jsou nastaveny možnosti práce se sestavou v interaktivním panelu. Tyto možnosti se nastavují ve vlastnostech sestavy v části „Odkazy sestavy“. Zaškrtnutím jednotlivých možností se všem uživatelům zobrazí odpovídající interaktivní odkazy pod danou sestavou. Tato funkcionalita je velmi používaná, neboť dovoluje uživatelům jednotlivé sestavy v panelech upravovat, tisknout a kopírovat. Taktéž umožňuje stahovat požadované sestavy do MS Excel (pro dodatečnou analytickou práci), do MS PowerPoint (pro tvorbu případných prezentací) a v neposlední řadě umožňuje požadovanou sestavu stáhnout jako webovou stránku MHTML. Takto můžeme například zkombinovat externí odkazy s kódem HTML do jednoho souboru. V příloze č. 4 je uvedena ukázka interaktivního panelu našeho řešeného příkladu ve vývojovém prostředí. Do jedné stránky panelu můžeme samozřejmě umístit prakticky libovolné množství sloupců, oddílů a sestav. Nicméně vždy je třeba dbát na potřebu maximální přehlednosti a vypovídající schopnosti vytvořeného panelu, který dnes neodmyslitelně patří ke každé úloze, vybudované pomocí BI nástrojů. Teprve kompletace všech potřebných a vytvořených sestav do interaktivního panelu poskytne všem potencionálním uživatelům tu nejlepší orientaci ve zpracovávané oblasti a vysoký komfort práce se sestavami.
4 Nasazení BI řešení V této poslední kapitole si ukážeme „High-Level“ architekturu softwarových a hardwarových komponent
č. 34) instance prostředí OBIEE a jejich implementaci v ČNB, včetně postupu nasazení vyvíjených úloh. Rovněž si zde probereme problematiku řízení přístupových práv. Obrázek č. 34: Diagram nasazení v ČNB - OBIEE a APEX
4.1 Prostředí OBIEE Obecně je rozsah nasazení OBIEE do informačního prostředí podniku závislé na jeho povaze a velikosti. Dále pak na firemní politice v oblasti IS/IT, na jeho stavu a na stupni případných outsourcingových služeb. Rovněž podstatnou roli hrají finanční možnosti dané společnosti. ČNB má nasazené všechny stěžejní BI nástroje sdružené v produktu OBIEE. Z hlediska prostředí BI jsou v ČNB zprovozněny následující instance prostředí: Vývojové prostředí – jedná se o lokální instance, umístěné dle potřeb jednoho každého vývojáře, ve kterých vývojáři tvoří, testují a ladí lokální OBIEE repository (metadata model) vyvíjených úloh. Vývojáři jsou povinni dodržet předepsané konvence pro tvorbu těchto dílčích repository. Důvodem je umožnit jejich budoucí sloučení do jednoho master repository. Vývojové prostředí zahrnuje BI Server, BI Interactive Dashboards a BI Answers. Každý vývojář si ve svém lokálním prostředí vytvoří příslušný metadata model, jehož funkčnost odladí při tvorbě sestav v BI Answers. Tato instance rovněž umožňuje vývojáři upravit konfiguraci lokálního BI Serveru – xml soubor „instanceconfig“. Jedná se o takové parametry jako například navýšení počtu buněk v kontingenční tabulce <MaxCells> či maximální počet viditelných
administrátorům, dle doporučení vývojářů, nastavit optimální testovací a produkční prostředí. Ve vývojovém prostředí je tvořen metadata model IS UNIZBIP a postupně je rozšiřován o metadata dílčích modulů. Pro přehlednost jsme si však v našem řešeném příkladě ukázali metadata model, který řeší pouze jednu dílčí primární oblast. Testovací prostředí – slouží k otestování připravených a odladěných metadat modelů jednotlivých úloh. Provádí se zde ověřování dílčích sestav či interaktivních panelů. V tomto prostředí také probíhají uživatelské a akceptační testy. Dle požadavku vývojáře, provedou administrátoři nasazení příslušného metadat modelu. Nasazení probíhá tím způsobem, že dojde ke sloučení požadovaného repository se stávajícím TEST repository. Administrátoři provádějí toto slučování ihned po zadání požadavku, tedy bez zbytečných odkladů. Předpokládá se zde časté nasazování jednotlivých dílčích repository. Obnova testovacího prostředí se provádí dle potřeby a je odvislá od stavu prostředí produkčního. Do testovacího prostředí je repository IS UNIZBIP nasazováno vždy bezprostředně po dokončení dalšího primárního modulu či po provedení změn v modulech již hotových. Díky 81
skutečnosti, že testovací prostředí je napojeno na produkční databázi, běží zde rovněž pilotní provoz. Uživatelé zde pracují nad reálnými (ostrými) daty a jediné omezení spočívá v delší době obnovy při pádu instance či krátkých výpadcích při nasazování dílčích repository. Migrační prostředí – používá se k migraci a ověření integrovaných finálních verzí jednotlivých úloh před nasazením do produkčního prostředí. Produkční prostředí – jedná se o konečné (finální) prostředí, sloužící k prezentaci akceptovaných analytických úloh. Před nasazení repository požadované úlohy do produkčního prostředí, provedou administrátoři ověření slučitelnosti s master repository, kontrolu správnosti použití jmenných konvencí a správnost nastavení přístupových práv (aplikačních skupin) u daného repository. Nasazení úlohy na produkční prostředí probíhá na žádost technického správce dané úlohy a to v okamžiku, kdy je tato úloha plně otestována a akceptována uživatelem. Před samotným sloučením, neboli „Merge“, provedou administrátoři OBIEE zálohu aktuálně platného produkčního master repository. V případě IS UNIZIBIP, kdy se jedná o modulární systém, se nasazování na produkční prostředí odehrává průběžně vždy v okamžiku, kdy je uživatelem akceptován příslušný dílčí modul. Aby vývojář nemusel sestavy a panely vytvářet pro každou instanci zvlášť, je součástí nasazení také přenos a archivace Web katalogu na příslušnou instanci. Tento katalog představuje úložiště pro sestavy a interaktivní panely vytvořené vývojářem a odpovídá adresářové struktuře ve filesystému. Obsahuje jednotlivé složky a soubory objektů včetně příslušných oprávnění. Správa Web katalogu, jež je rovněž v gesci administrátorů OBIEE, se provádí v nástroji „Catalog Manager“ a zahrnuje vytváření a správu aplikačních skupin, tvorbu nových složek a přiřazení oprávnění k těmto složkám pro existující aplikační skupiny. Schéma prostředí OBIEE v ČNB je zachyceno na obrázku č. 35
Obrázek č. 35: Prostředí OBIEE v ČNB Lokální vývojová prostředí
4.2 Řízení přístupových práv Nedílnou součástí nasazení úlohy OBIEE je přidělení a řízení přístupových práv. Jak již bylo řečeno dříve, k řízení přístupových práv se nejčastěji používají aplikační skupiny vytvářené pro každou úlohu zvlášť. K jedné úloze může být vytvořeno neomezené množství těchto skupin. Nicméně pro přehlednou a účinnou správu se používá jedna aplikační skupina pro administraci úlohy a několik pro různé skupiny uživatelů. Vývojáři úloh mají vlastní aplikační skupiny se širokými oprávněními tak, aby mohli vyvíjené úlohy plně spravovat a řídit přístupová oprávnění k vytvářeným objektům dané úlohy. Řízení přístupových práv k úloze OBIEE se provádí na různém stupni detailu a na několika úrovních, aby bylo možné poskytnout co nejširší množství dat a informací za dodržení co největší míry zabezpečení.
V našem řešeném příkladě řídíme přístupová práva pomocí následujících aplikačních skupin: -
Přidělení přístupových práv při vytváření metadat BI Serveru (kapitola 3.4.3), představuje první úroveň v nastavení oprávnění. Další úroveň představuje řízení oprávnění pro jednotlivé sestavy a interaktivní panely: -
přístupová práva v BI Answers se nastavují ve správě katalogu prezentace a ve správě interaktivních panelů. V prvním případě nastavujeme oprávnění k vytvořeným sestavám a v případě druhém nastavujeme oprávnění k jednotlivým panelům,
přístupová práva v BI Interactive Dashboards – zde se přidělují oprávnění pro jednotlivé stránky a objekty daného interaktivního panelu. Tato variabilita umožní zpřístupnit panel co největší skupině uživatelů s tím, že některé objekty na stránkách panelů či celé stránky budou přístupné pouze určité skupině.
Celý postup přidělení přístupových práv pro náš řešený příklad je tedy následující: -
nastavení aplikačních skupin v metadat modelu pro příslušné složky prezentačního katalogu,
nastavení práv pro jednotlivé objekty uvnitř vytvořeného interaktivního panelu.
Nastavení přístupových oprávnění k jednotlivým sestavám a panelům můžeme nadefinovat buď ihned po vytvoření na vývojovém prostředí a nebo až v prostředí testovacím či dokonce produkčním. V okamžiku, kdy dojde k nasazení našeho metadat modelu na testovací prostředí a zároveň jsou nastavena příslušná přístupová oprávnění, mají všichni uživatelé, jenž jsou uvedeni v některé z aplikačních skupin, možnost pracovat s vytvořenými interaktivními panely a tím pádem i s příslušnými sestavami. Taktéž mohou vytvářet sestavy vlastní z příslušné cílové oblasti BI Answers, jenž obsahuje objekty, které jsou definovány v prezentačním katalogu našeho vytvořeného metadat modelu.
5 Výsledky Při studiu jednotlivých produktů v oblasti BI pro potřeby této diplomové práce a při zpracování příkladu použití nástrojů BI pro potřeby ČNB jsem dospěl k následujícím poznatkům. Trh s BI nástroji zaznamenává v posledních letech velký rozvoj a konsolidaci. Hlavním důvodem je neustále postupující globalizace a velký boj o zákazníka, který nutí čím dál tím větší množství společností investovat značné množství prostředků do kvalitních ERP a CRM systémů. Navíc si tuto potřebu začíná uvědomovat i značná část menších a středních firem, která dříve tuto oblast pomíjela jako příliš nákladnou a „v jejich očích“ neefektivní. Nemalý podíl na rozvoji BI má také neustávající rychlý vývoj v oblasti informačních a komunikačních technologií (ICT). Dnešní moderní technologie umožňují sběr a uchování obrovského množství dat a tato data jsou následně zpracovávána stále rychleji a efektivněji. Tyto skutečnosti poskytují dostatečný prostor pro tvorbu a rozvoj široké palety BI nástrojů, jenž dovolují nahlížet na data ze všech možných úhlů či perspektiv a umožňují nad nimi bohatou analytickou práci včetně jejich následné prezentace. Rozvoj ICT také umožňuje vyvíjené nástroje nabízet levněji a oslovit tak větší množství firem. Další podstatnou obecnou výhodu BI nástrojů je jejich grafické a mobilní rozhraní, přehlednost a intuitivnost. Pro tyto vlastnosti jsou čím dál tím oblíbenější, používanější a žádanější rovněž mezi nejvyšším managementem společností. Všechny tyto skutečnosti poskytují široké možnosti a příslib velkých zisků pro softwarové společnosti zabývající se touto oblastí. Prakticky všechny velké softwarové firmy jsou si toho velmi dobře vědomi a snaží se, pokud se této oblasti před tím dostatečně nevěnovaly či na začátku „zaspaly“, vše dohnat a pevně se na trhu usadit. Což v důsledku vedlo z jejich strany k místy až nepřátelskému převzetí již dříve zavedených firem. Dnes tak mezi významnými hráči na trhu s BI produkty zůstávají již pouze dva „čistokrevný prodejci“. V druhé části této diplomové práce jsem posléze ukázal vhodnost použití BI nástrojů, v tomto konkrétním případě OBIEE, pro specifické potřeby ČNB. Představil jsem informační prostředí ČNB a na řešeném příkladu IS UNIZBIP jsem se zároveň pokusil nastínit problematiku sestavování platební bilance a investiční pozice České republiky v ČNB. Moji snahou bylo rovněž ukázat možný postup a metodiku tvorby úlohy bez ohledu na použitou platformu. 85
Myslím si, že cílů, jež jsem si vytyčil v rámci této diplomové práce, bylo dosaženo a že jsem navíc poskytl stručný názorný návod, jakým způsobem lze vytvořit jednoduchou OBIEE úlohu a demonstroval uživatelskou přívětivost a do značné míry intuitivnost použitých BI nástrojů.
Závěr Bez ohledu na skutečnost, že závěry zjištění současného stavu na trhu s BI nástroji ukazují na jasnou dominanci velkých softwarových firem, magický čtverec prezentovaný společností Gartner, Inc. zachycuje velké množství firem, které se pokoušejí zaplnit stále se zmenšující mezery na tomto trhu. I přes hrozbu blízkého zániku či nedobrovolného převzetí se tyto společnosti snaží neustále inovovat své produkty a pružně se přizpůsobovat potřebám svých zákazníků. Z tohoto důvodu zde nacházím značný prostor pro provedení studie, jenž ukáže na možný budoucí směr rozvoje nástrojů BI pro tyto menší a flexibilní společnosti. Příkladem možného směru může být rozvoj prediktivních analýz a pokročilé vizualizace. Nicméně je zde také potřeba zmínit, že hledání možného budoucího směru nebude vůbec jednoduché. Boj o zákazníka je na tomto trhu veliký a vedoucí společnosti investují značné množství prostředků do rozvoje prakticky všemi myslitelnými směry. Tuto skutečnost podtrhuje fakt, že magický čtverec ukazuje na absenci vizionářů a pouhé dva vyzyvatele. V otázce vhodnosti použití BI nástrojů pro potřeby ČNB jsem přesvědčen, že jsou nejen vhodné, ale ba přímo nutné. Usuzuji tak na základě svých dvacetiletých zkušeností se zpracováním statistických dat v ČNB v široké paletě soudobých nástrojů. V současné době ČNB sbírá, uchovává a zpracovává data v daleko větším objemu a detailu než kdykoliv dříve v minulosti. Důvodem je jednak potřeba zajistit plnění, jež je dáno posláním ČNB a rovněž tlak EU na zasílání ať už co největšího objemu dat v co nejširším členění či dat z různých úhlů pohledu. Za této situace je použití BI nástrojů prakticky nezbytné. Jen z jejich pomocí lze totiž rychle, efektivně a jednoduše vytvářet sestavy a výstupy na všech úrovních od celku až po největší detail. Rovněž umožňují nahlížet na data ze všech stran, při zachování potřebného stupně členění, což podstatným způsobem usnadňuje práci příslušných odborných útvarů.
ARLOW, Jim; NEUSTADT, Ila. UML 2 a unifikovaný proces vývoje aplikací : Průvodce analýzou a návrhem objektově orientovaného softwaru. 1. vyd. Brno : Computer Press, a.s., 2007. 568 s. ISBN 978-80-251-1503-9
INMON, W. H. Building the Data Warehouse. 4th Edition. Oxford : John Wiley & Sons, 2005. 576 s. ISBN 978-0-7645-9944-6
MAASSEN, André, et al. SAP R/3 Kompletní průvodce. 1. vyd. Brno : Computer Press, a.s., 2007. 733 s. ISBN 978-80-251-1750-7
NOVOTNÝ, Ota; POUR, Pavel; SLÁNSKÝ, David. Business Intelligence : Jak využít bohatství ve vašich datech. 1. vyd. Praha : Grada Publishing, a.s., 2005. 256 s. ISBN 80-247-1094-3
RUMBAUGH, James; JACOBSON, Ivar; BOOCH, Grady. The Unified Modeling Language Reference Manual. Boston : Addison-Wesley Professional, 1998. 576 s. ISBN 020130998X
SAMUELSON, Paul A.; NORDHAUS, William D. Ekonomie. 1. vyd. Praha : Nakladatelství Svoboda, 1991. 1011 s. ISBN 80-205-0192-4
Business intelligence : příručka manažera. Praha : TATE International, s.r.o., 2007. 166 s. ISBN 978-80-86813-12-7
GIDADMANI, Santosh Kumar. Performance Tuning – Collapsible Reports. In: OBI Applications: ORACLE BUSINESS INTELLIGENCE WORLD [online]. March 23, 2012 [cit. 2012-03-25]. Dostupný z WWW: https://santoshbidw.wordpress.com/category/obiapplications/
GUPTA, Pooja. BI Publisher and its integration with Oracle Report. In: University, placement, school and entrance exam question paper [online]. 14 November 2011 [cit. 2012-02-02]. Dostupný z WWW: http://www.howtoexam.com/index.php?option=com_content&view=article&id=261:bipublisher-and-its-integration-with-oracle-report&catid=790:computers-and-software
HAGERTY, John, Rita L. SALLAM a James RICHARDSON. GARTNER, Inc. Magic Quadrant for Business Intelligence Platforms [online]. 6 February 2012 [cit. 2012-0326]. ISBN G00225500. Dostupný z WWW: http://www.microstrategy.com/software/businessintelligence/
HOWSON, Cindi. MicroStrategy Offers Cloud BI. In: BI Scorecard Blog [online]. August 26, 2011 [cit. 2012-03-26]. Dostupný z WWW: http://biscorecard.typepad.com/biscorecard/2011/08/microstrategy-offers-cloud-bi.html
MENNINGER, David. MicroStrategy Introduces Cloud Personal. In: BusinessIntelligence.com: Business Intelligence [online]. November 15, 2011 [cit. 201202-05]. Dostupný z WWW: http://businessintelligence.com/microstrategy-introducescloud-personal/
PENDSE, NIgel. What is OLAP?. In: The BI Verdict: Business Intelligence software evaluations and tool selection advice [online]. March 3, 2008 [cit. 2012-03-26]. Dostupný z WWW: http://www.bi-verdict.com/fileadmin/FreeAnalyses/fasmi.htm
PETERKA, Miloslav. Seznamte se s BI. In: DAQUAS [online]. 9.6.2010 [cit. 2012-03-26]. Dostupný z WWW: http://www.daquas.cz/articles/379-seznamte-se-sbi
Business Intelligence (BI): Gartner IT Glossary. GARTNER, Inc. Gartner Inc: Technology Research [online]. [cit. 2012-03-27]. Dostupný z WWW: http://www.gartner.com/it-glossary/business-intelligence-bi/
Business Intelligence: SAS. SAS. SAS: Business Analytics and Business Intelligence Software [online]. [cit. 2012-03-27]. Dostupný z WWW: http://www.sas.com/technologies/bi/index.html
Business Intelligence: TDWI -The Data Warehousing Institute. TDWI. TDWI: The Data Warehousing Institute [online]. [cit. 2012-01-28]. Dostupný z WWW: http://tdwi.org/portals/business-intelligence.aspx
IBM - Business Intelligence (BI) a řízení finanční výkonnosti (Financial Performance Management): Česká republika. IBM. IBM: Česká republika [online]. [cit. 2012-03-26]. Dostupný z WWW: http://www01.ibm.com/software/cz/data/cognos/products/index.html
IBM - Software InfoSphere - Řešení pro integraci dat, datové sklady, správu hlavních dat, MDM a analýzu entit: Česká republika. IBM. IBM: Česká republika [online]. [cit. 2012-03-26]. Dostupný z WWW: http://www-01.ibm.com/software/cz/data/infosphere/
Introduction to Building Fusion Web Applications with Oracle ADF. ORACLE. Oracle Fusion Middleware Documentation Library [online]. [cit. 2011-12-08]. Dostupný z WWW: http://docs.oracle.com/cd/E12839_01/web.1111/b31974/intro.htm
Introduction to Building Your Metadata Repository. ORACLE. Oracle Fusion Middleware Documentation Library [online]. 2010 [cit. 2012-01-31]. Dostupný z WWW: http://docs.oracle.com/cd/E14571_01/bi.1111/e10540/intro.htm
Investiční pozice ČR vůči zahraničí a zahraniční zadluženost. In: Česká národní banka [online]. [cit. 2011-11-28]. Dostupný z WWW: https://www.cnb.cz/cs/kalendar/investicni-pozice-cr-vuci-zahranici-a-zahranicnizadluzenost/2011-06-29_02.html
Jste připraveni na business intelligence 2.0?. Ekonomické a informační systémy v praxi [online]. 9/2011: IT SYSTEMS [cit. 2012-03-26]. Dostupný z WWW: http://www.systemonline.cz/business-intelligence/jste-pripraveni-na-businessintelligence-2.0.htm
Microsoft Office Excel 2007 as front-end to SQL Server 2005. ELEMENT61. Element61: Business Intelligence - Performance Management consulting [online]. [cit. 2012-01-31]. Dostupný z WWW: http://www.element61.be/e/resourcdetail.asp?ResourceId=59.
Microsoft SharePoint 2010. MICROSOFT. Microsoft Česká republika: Software, IT, Digitální svět [online]. 2012 [cit. 2012-03-26]. Dostupný z WWW: http://www.microsoft.com/cze/sharepoint/2010/
Microsoft SQL Server 2008: SQL Server 2008 R2. MICROSOFT. Microsoft Česká republika: Software, IT, Digitální svět [online]. 2012 [cit. 2012-03-26]. Dostupný z WWW: http://www.microsoft.com/cze/sqlserver2008/produkt/podrobnosti/r2.aspx
MICROSTRATEGY. Microstrategy9_brochure_cs [online]. Köln, 2009 [cit. 2012-03-26]. ISBN COLL-0863 0209. Dostupný z WWW: http://www.oksystem.cz/produkty/produkty-partneru/microstrategy
O ČNB: Česká národní banka. ČNB. Česká národní banka [online]. [cit. 2011-11-08]. Dostupný z WWW: http://www.cnb.cz/cs/o_cnb/
O nás: SAS. SAS INSTITUTE INC. SAS: Business Analytics and Business Intelligence Software [online]. [cit. 2012-03-26]. Dostupný z WWW: http://www.sas.com/offices/europe/czech/o_firme/corp.html
Oracle Business Intelligence Enterprise Edition Platform Components. ORACLE. Oracle: Hardware and Software, Engineered to Work Together [online]. [cit. 2012-0108]. Dostupný z WWW: http://www.oracle.com/technetwork/middleware/bifoundation/enterprise-edition-platform-compone-093074.html
Produkty a řešení: SAS. SAS. SAS: Business Analytics and Business Intelligence Software [online]. [cit. 2012-03-27]. Dostupný z WWW: http://www.sas.com/offices/europe/czech/technologies/enterprise_intelligence_platform/
Roadmap SAP BusinessObjects BI: SAP.info. SAP.info [online]. [cit. 2012-01-31]. Dostupný z WWW: http://en.sap.info/sapphire_business_intelligence/32326
SAP: Business Intelligence Solutions l Access, Analyze, and Explore Data. SAP Business Management Software Solutions, Applications and Services [online]. [cit. 2012-03-26]. Dostupný z WWW: http://www.sap.com/solutions/sapbusinessobjects/large/business-intelligence/index.epx
SAP Česká republika: Software Business Intelligence. SAP. SAP Česká republika SAP: Business Management Software Solutions Applications and Services [online]. [cit. 2012-03-26]. Dostupný z WWW: http://www.sap.com/cz/sme/solutions/businessintelligence/index.epx
Výkaznictví a sběr dat: Česká národní banka. ČNB. Česká národní banka [online]. [cit. 2011-11-08]. Dostupný z WWW: http://www.cnb.cz/cs/statistika/vykaznictvi_sber_dat/
KOCÁBEK, Tomáš. Sběr a zpracování dat v ČNB. Praha, BIVŠ, 2010. 57 s. Bakalářská práce
Česká republika. Pokyny České národní banky č. 62: O rozvoji informačních systémů a informačních technologií v České národní bance. In: Zpravodaj ČNB částka 5/2010. Praha: ČNB, 2010, 5/2010.
Obecné označení technologií sloužících k vývoji interaktivních webových aplikací
Nástroj pro tvorbu webových aplikací pracujících nad databázemi Oracle Hlavní prezentační systém agregovaných statistických dat v ČNB
Zahrnuje nástroje a postupy jenž usnadňují přístup k datům a jejich analýzu z cílem zlepšit a optimalizovat rozhodování a výkonnost[15]
Banka pro mezinárodní zúčtování je mezinárodní organizace, jenž podporuje mezinárodní měnovou a finanční spolupráci a slouží jako banka pro centrální banky
Nástroje pro správu vývoje IS s podporou týmové práce a sdílením rozpracovaných částí budovaného systému
Elektronická výměna standardních strukturovaných zpráv mezi aplikacemi či systémy
Jedná se procesy, používané zejména v datových skladech, jenž zajišťující převádění dat ze zdrojových systémů do cílových struktur
Finanční deriváty - jedná se o instrumenty, jenž se oceňují na základě tržních cen jednoho či více podkladových aktiv
Značkovací jazyk pro hypertext. Je jedním z jazyků pro vytváření stránek v systému World Wide Web
Investiční pozice vůči zahraničí. Vyčísluje aktuální stav příslušných finančních aktiv a pasiv ke stanovenému dni
Informační systém pro sestavení a analýzu platební bilance a investiční pozice v ČNB
Virtuální stroj složený ze sady programů, jenž umožňuje zpracovat mezikód Java bytecode
Softwarová architektura oddělující datový model, řídící logiku a uživatelské rozhraní.
Způsob uložení velkých objemů dat v databázi, jenž dovoluje rychlé a pružné provádění dotazů a analýz. Standard pro šifrování a podepisování dat
Procedurální nadstavba jazyk SQL Platební bilance - obsahuje souhrn ekonomických transakcí se zahraničím za dané časové období
Rodina XML formátů Webová aplikace ČNB určená pro sběr dat od bankovních, ostatních finančních a nefinančních subjektů
Architektura orientovaná na služby. Pokročilá fáze budování podnikových informačních systémů
Světová banka Soubor doporučení definující standardy pro Message Handling System (MHS)
Obecný značkovací jazyk určený především pro výměnu dat mezi aplikacemi a pro publikování dokumentů
Příloha č. 1 Členění primárních modulů ve struktuře platební bilance
Běžný účet A. B. C.
Obchodní bilance Bilance služeb Bilance výnosů 1. Náhrady zaměstnancům 2. Investiční výnosy 2.1 Přímé investice 2.2 Portfoliové investice 2.3
Kapitálový účet Finanční účet 1. 1.1 1.2 2. 2.1 2.2 3. 4. 4.1 4.2 4.3 4.4 5.
Modul IS UNIZBIP Součtová položka Zboží Služby Součtová položka Důchody a KÚ Součtová položka PZI PI Všechny moduly ostatních investic a ostatní položky Důchody a KÚ Důchody a KÚ Součtová položka
Přímé investice v zahraničí PZI zahraničí v tuzemsku Portfoliové investice majetkové cenné papíry a účasti PI dluhové cenné papíry Finanční deriváty FD Ostatní investice součet ČNB Ostatní investice - MFI, MA vláda Ostatní investice - vláda měnové finanční instituce Ostatní investice - MFI, MA ostatní sektory Ostatní investice - ostatní sektory Změna devizových rezerv (-nárůst) Rezervy
Modul IS UNIZBIP Součtová položka PZI PI FD Všechny moduly ostatních investic Rezervy Součtová položka PZI
Aktiva Přímé investice v zahraničí Portfoliové investice Finanční deriváty Ostatní investice Rezervy ČNB
Příloha č. 2 Ukázka uživatelského rozhraní vytvořeného pro primární modul FD
Příloha č. 3 Struktura položek Finančních derivátů pro platební bilanci a investiční pozici BOP ITEM 910 911 912 912_S.1311 912_S.1312 912_S.1313 912_S.1314 913 913_S.1221 913_S.1222 913_S.1223 913_S.1224 914 914_S.11 914_S.123 914_S.124 914_S.1251 914_S.1252 914_S.14 914_S.15 900 901 902 902_S.1311 902_S.1312 902_S.1313 902_S.1314 903 903_S.1221 903_S.1222 903_S.1223 903_S.1224 904 904_S.11
NÁZEV SALDO FINANČNÍ DERIVÁTY - SALDO Finanční deriváty měnových institucí - saldo Finanční deriváty vládních institucí - saldo Ústřední vládní instituce Národní vládní instituce Místní vládní instituce Fondy sociálního zabezpečení Finanční deriváty ostatních měnových finančních institucí Banky Spořitelní a úvěrní družstva Fondy peněžního trhu Jiné měnové finanční instituce Finanční deriváty ostatních sektorů - saldo Nefinanční podniky Ostatní finanč. zprostř. (bez pojišť. spol. a penzij. fondů) Pomocné finanční instituce Pojišťovací společnosti Penzijní fondy Domácnosti Neziskové instituce sloužící domácnostem AKTIVA FINANČNÍ DERIVÁTY - aktiva Finanční deriváty měnových institucí - aktiva Finanční deriváty vládních institucí - aktiva Ústřední vládní instituce Národní vládní instituce Místní vládní instituce Fondy sociálního zabezpečení Finanční deriváty ostatních měnových finančních institucí Banky Spořitelní a úvěrní družstva Fondy peněžního trhu Jiné měnové finanční instituce Finanční deriváty ostatních sektorů - aktiva Nefinanční podniky
TYP součtová součtová součtová součtová součtová součtová součtová součtová součtová součtová součtová součtová součtová součtová součtová součtová součtová součtová součtová součtová součtová primární součtová primární primární primární primární součtová primární primární primární primární součtová primární
904_S.123 904_S.124 904_S.1251 904_S.1252 904_S.14 904_S.15 905 906 907 907_S.1311 907_S.1312 907_S.1313 907_S.1314 908 908_S.1221 908_S.1222 908_S.1223 908_S.1224 909 909_S.11 909_S.123 909_S.124 909_S.1251 909_S.1252 909_S.14 909_S.15
Ostatní finanč. zprostř. (bez pojišť. spol. a penzij. fondů) Pomocné finanční instituce Pojišťovací společnosti Penzijní fondy Domácnosti Neziskové instituce sloužící domácnostem PASIVA FINANČNÍ DERIVÁTY - pasiva Finanční deriváty měnových institucí - pasiva Finanční deriváty vládních institucí - pasiva Ústřední vládní instituce Národní vládní instituce Místní vládní instituce Fondy sociálního zabezpečení Finanční deriváty ostatních měnových finančních institucí Banky Spořitelní a úvěrní družstva Fondy peněžního trhu Jiné měnové finanční instituce Finanční deriváty ostatních sektorů - pasiva Nefinanční podniky Ostatní finanč. zprostř. (bez pojišť. spol. a penzij. fondů) Pomocné finanční instituce Pojišťovací společnosti Penzijní fondy Domácnosti Neziskové instituce sloužící domácnostem Zdroj: Vlastní úprava
primární primární primární primární primární primární součtová primární součtová primární primární primární primární součtová primární primární primární primární součtová primární primární primární primární primární primární primární
Příloha č. 4 Ukázka interaktivního panelu pro modul FD – IS UNIZBIP
