Případová studie návrhu implementace a nasazení OLAP

Bankovní institut vysoká škola Praha Katedra informačních technologií a elektronického obchodování

Případová studie návrhu implementace a nasazení OLAP

Diplomová práce

Autor:

Bc. Pavel PECA Informační technologie a management

Vedoucí Práce:

Praha

Ing. Michal VALENTA, Ph.D.

Červen 2011

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 ………………… Místo a datum

…………………………. jméno a příjmení autora

Poděkování: Na tomto místě bych rád poděkoval panu Ing. Michalovi Valentovi, Ph.D., za hodnotné rady, zajímavé podněty, vstřícný a mentorský přístup a pomoc při návrhu a psaní této diplomové práce. Velké díky patří mé rodině, za vytvoření příjemných podmínek a nezměrnou podporu. Dále pak děkuji kolegům z týmu Capitol společnosti Capgemini Czech Repubulic, za lidský a chápavý přístup k mým absencím v období dokončování této diplomové práce. Také bych rád poděkoval kamarádovi Honzovi Jarošovi za motivaci a pozitivní energii.

Anotace V dnešní elektronické době se v transakčních systémech uchovává velké mnoţství různorodých informací, jako jsou například informace o prodejích výrobků, o klientech, o časovém zařazení těchto informací atd.

Pokud tyto data budeme vhodně skladovat

a analyzovat, můţeme z nich pomocí vyspělých nástrojů získat značnou vypovídací hodnotu, například o vývoji trendů, bilancí a jiných zákonitostí v našich ţivotech. Tyto data za účelem analýzy a zkoumání vstupují do datových skladů, kde je na ně nahlíţeno z různých pohledů. Tato diplomová práce popisuje relační databáze, syntaxi jazyka SQL, MDX a další především normalizační a denormalizační techniky pouţívané k zastřešení problematiky datových skladů a OLAP analýzy obecně. Vysvětluje pojmy jako „dimenze“, „datová krychle“ či „míra“. V další praktické části potom vyuţívá zmíněných informací a vytváří případovou studii implementace OLAP serveru pro servery Oracle OLAP a Pentaho Mondrian. Implementaci dokumentuje a jejich funkci demonstruje na příkladech.

Annotation In today's electronic age the transactional systems keep large amounts of diverse information such as information of sales products, of clients, the inclusion of time information etc. If these data will be stored and analyzed properly, we can use the advanced tools and gain the considerable explanatory value for the development of trends, balances and other legality in our lives. These analysis and examination data entering into a data warehouse where they are viewed from different perspectives. This diploma thesis describes a relational database, SQL syntax, MDX and other techniques above all normalizing and de-normalizing techniques used to cover issues of data warehouses and OLAP analysis in generally. Explains terms such as "Dimension", "Data cube" or "Measure". In another – practical part we can use mentioned information and create a study case and implementation of OLAP Server for servers Oracle OLAP and Pentaho Mondrian. This work documents implementation and demonstrating their functions in the examples.

Obsah Obsah .................................................................................................................... 5 Úvod ...................................................................................................................... 7 Problematika datových skladů obecně .............................................................. 8 1

Architektury pro datové sklady ................................................................ 10 1.1

OLTP – relační databáze ....................................................................................... 13

1.1.1 1.2

OLAP – multidimenzionální databáze ................................................................. 19

1.2.1 1.3

3

SQL................................................................................................................... 28

1.3.1.1

Příkazy DDL ................................................................................................ 29

1.3.1.2

Příkazy DML ............................................................................................... 32

1.3.1.3

Příkazy TCC ................................................................................................ 37

1.3.1.4

Příkazy DCL ................................................................................................ 40

1.3.1.5

Moţnosti jazyka SQL pro agregaci a analýzu dat ....................................... 41

1.3.2

2

Schémata uspořádání tabulek faktů a dimenzí ................................................. 25

Dotazovací jazyky ................................................................................................... 27

1.3.1

1.4

Datová normalizace .......................................................................................... 14

MDX ................................................................................................................. 41

ETL Procesy ........................................................................................................... 45

Seznámení s OLAP produkty na trhu ...................................................... 47 2.1

Oracle OLAP .......................................................................................................... 48

2.2

Pentaho Mondrian .................................................................................................. 50

Vlastní návrh a implementace DS ............................................................ 52 3.1

PIM návrh architektury a řešení datového skladu ............................................. 52

3.1.1

Datový model zdrojové relační databáze.......................................................... 52

3.1.2

Převod relačního schématu na schéma hvězdy................................................. 57

3.2

PSM návrh architektury a řešení datového skladu Oracle ................................ 59

3.2.1

Vlastní instalace SŘBD Oracle 11g.................................................................. 59

3.2.2

Vytvoření datových struktur ............................................................................. 61

3.2.3

Naplnění datových struktur daty....................................................................... 62

3.2.4

Vytvoření datové krychle, dimenzí a hierarchií ............................................... 68 5

3.3

4

PSM návrh architektury a řešení datového skladu Pentaho .............................. 75

3.3.1

Vlastní instalace OLAP serveru Pentaho Mondrian ......................................... 75

3.3.2

Konfigurace OLAP serveru a mapování modelu na SŘBD Oracle 11g........... 77

3.3.3

Vlastní pouţití OLAP serveru Pentaho Mondrian............................................ 79

Porovnaní vyhotovených řešení ................................................................ 85 4.1

Porovnání z pohledu dostupnosti a instalace ....................................................... 85

4.2

Porovnání z pohledu implementace ...................................................................... 86

4.3

Porovnání z pohledu rychlosti ............................................................................... 86

4.4

Další varianty porovnání ....................................................................................... 88

Závěry a doporučení ......................................................................................... 89 Seznam použité literatury ................................................................................. 92 Seznam použitých zkratek ................................................................................ 94 Seznam použitých obrázků ............................................................................... 96 Seznam použitých tabulek ................................................................................ 97 Přílohy ................................................................................................................ 98

6

Úvod Cíl této diplomové práce je detailní seznámení se s moderními přístupy k návrhu OLAP aplikací a ukázková implementace datového skladu v prostředích Oracle OLAP a Pentaho Mondrian. Problematika datových skladů nabírá v poslední době na oblibě, díky více a více dostupným hardwarovým řešením, velké škále platforem pro uchovávání dat a rozšiřující se nabídkou analytických nástrojů. V této práci se budu zabývat popisem techniky realizace datového skladu a nástroji k tomu potřebnými. Navrhnu vhodnou případovou studii, její logický i fyzický rámec a provedu ukázkovou implementaci výše zmíněných OLAP serverů. Případová studie bude realizovaná nad reálnými daty tak, aby co nejvěrněji nastínila moţná pouţití takto implementovaných řešení. Také se budu zaměřovat na zvýraznění kladů a záporů popisovaných řešení a slabá a silná místa mého návrhu.

7

Problematika datových skladů obecně Intenzivní nasazení informačních technologií do rozličných odvětví lidské činnosti přináší s sebou jeden zákonitý jev, kterým je shromaţďování velkého mnoţství různorodých údajů. Shromaţďují se údaje z technologických zařízení, firemní administrativy, odbytu a podobně. Mnoţství údajů mají shromáţděno i velké supermarkety ze skladových karet, elektronických pokladen a podobně. Výsledek je lehko předvídatelný. Za kratší či delší dobu se podaří shromáţdit obrovské mnoţství údajů. Moderní databázové servery umoţňují nejen bezpečnou a rychlou práci s takovým mnoţstvím údajů, ale umoţňují nám z těchto údajů získat i informace? Na první, povrchní pohled by se mohlo zdát, ţe mezi pojmy, údaje a informace, můţeme postavit znaménko rovnosti. Ale jen na první pohled. [5] Výstiţnou definici rozdílu mezi údaji (daty) a informacemi můţeme najít ve firemní literatuře Oracle. Podle této definice se stávají data informacemi, pokud: Máme data Víme, ţe máme data Víme, kde tato data máme Máme k těmto datům přístup Zdroji dat můţeme důvěřovat [6] Proces transformace dat na informace a převod těchto informací na poznatky prostřednictvím objevování nazýváme Business intelligence. Jinými slovy, účelem Business intelligence je konvertovat velké objemy údajů na poznatky, které jsou potřebné pro koncové uţivatele. Tyto poznatky můţeme potom efektivně vyuţít například v procesu rozhodování. Pod pojmem informace nerozumíme jen konkrétní záznam nebo mnoţinu záznamů. Často potřebujeme sledovat trend nějaké veličiny, například při obchodování s cennými papíry, nebo potřebujeme najít mezi údaji určité závislosti. Proto moderní databázové servery obsahují rozsáhlou podporu pro budování datových skladů (data warehouse), analýzy OLAP a data mining (dolování, odkrývání dat).

8

Poznatky z obchodování se samozřejmě zpracovávaly i předtím, neboť plány a studie se pro manaţery vypracovávaly odjakţiva, byly to samozřejmě reporty v papírové podobě. Určitý posun nastal v období 1980 aţ 1990, kdy se pro vyhodnocování údajů z obchodování začaly pouţívat různé tabulkové kalkulační programy. Éra produktů pro Business Intelligence začala okolo roku 1990. [5]

9

1 Architektury pro datové sklady Pokud budeme hovořit o architekturách databázových systémů obecně, můţeme je rozdělit z hlediska jejich datové architektury (modelu), která označuje vlastnosti vazeb mezi údaji v databázi a způsob organizace jejich struktury, kterým se prezentuje na logické úrovni, tedy na rozhraní SŘBD . Výběr datové architektury podstatně ovlivňuje vlastnosti dotazovacího jazyka a především způsob konstrukce jednotlivých dotazů. Datový model představuje definici formalizovaných přístupů k uložení a práci s informací v paměti počítače.

„Klasické“ síťové Síťové Hierarchické Souborově orientované „Klasické“ relační Normalizované Relační

Objekty (objektově relační) NFNF

Datové modely Hypertextové Fultextové Objektově orientované Sémantické sítě „Klasické“ (třídně instanční)

Obrázek 1 – Druhy datových modelů (převzato z [10])

Datové modely lze rozdělit na dvě velké skupiny. První z nich jsou historicky starší souborově orientované modely. Jejich název vychází z pohledu na data v databázi, který je relativně blízký souborové technologii, také z ní vychází, a nahlíţí na data jako na seznamy poloţek, coţ lze povaţovat za formalizovanou podobu původního datového souboru. Druhou skupinou jsou modely souhrnně označované jako objektově orientované. Jejich společnou vlastností je to, ţe jsou zaloţeny na takových formálních prostředcích, které nemají přímou vazbu na architekturu současných počítačů, především na jiţ zmíněnou organizaci 10

paměti. V detailech se však jednotlivé modely od sebe velmi liší a jejich vývoji se věnuje značná pozornost. Na pomyslné linii člověk-počítač je tato druhá skupina vlivem pouţitých prostředků blíţe člověku. Síťový datový model je historicky nejstarším datovým modelem. Základy síťového datového modelu byly poloţeny v roce 1971. Podstatou síťového datového modelu jsou vzájemně propojené mnoţiny záznamů. Záznamy jednoho typu jsou obvykle uloţeny v jednom souboru. Celá databáze je sloţena ze dvou hlavních mnoţin. Mnoţin záznamů, obvykle rozloţenou do více souborů a mnoţinou spojek, přičemţ spojka je zvláštní typ záznamu o dvou poloţkách obsahující fyzické adresy záznamů, které spojují. Pro modelování síťového databázového schématu se pouţívají např. tzv. Bachmanovy diagramy datové struktury, obsahující symboly obdélníků, reprezentující záznamy a čáry se šipkou mezi obdélníky, které představují spojky jako orientovanou vazbu mezi záznamy. Hierarchický datový model je zvláštním případem síťového datového modelu, kdy je kaţdý záznam odkazován pouze nejvýše jedním jiným záznamem. Pokud je toto pravidlo dodrţeno, potom celá struktura databáze degeneruje na strom, coţ se projevuje v odlišné fyzické implementaci databáze. V tomto modelu jsou data uspořádána podle tzv. hierarchických stromů (např. ZEMĚ, STÁT, HLAVNÍ MĚSTO,…). Kaţdý uzel tohoto stromu reprezentuje typ záznamu a kaţdá hrana spojku mezi dvěma typy záznamů. V hierarchickém stromu existuje jeden speciální význačný typ záznamu, tzv. kořen. Ostatní typy záznamů se nazývají závislé typy záznamů a jsou ve struktuře hierarchického stromu na niţší úrovni. Síťový a hierarchický datový model ve své době představoval optimální technologii pro organizaci dat v databázích. Mezi výhody těchto modelů patří velká rychlost zpracování a vazba na nativní knihovny funkcí programovacích jazyků, které dodnes podporují práci s daty organizovanými podle síťového nebo hierarchického datového modelu. Mezi nevýhody těchto datových modelů patří sekvenční přístup po jednotlivých záznamech, coţ je nevýhodné pro konstrukci uţivatelských dotazů nad SŘBD, či obtíţná změna struktury databáze. Tyto modely pracují optimálně pouze tehdy, pokud je na počátku vytvořena struktura databáze, do které se potom jen zapisuje. Rušení záznamů v databázi a hlavně změny struktury databáze jsou programátorsky obtíţné. Tyto nevýhody vyústily vývojem relačního datového modelu.

11

Relační datový model má počátky v roce 1969. Autorem prvních prací byl E. F. Codd, matematik z laboratoře IBM. Relační datový model se od svých předchůdců liší tím, ţe je důsledně budován na teoretickém základě, tj. je definována struktura a povolené operace nad nimi. Rozšíření relačního datového modelu po řadu let bránil nízký výkon tehdejších počítačů, neboť tento model je řádově pomalejší při provádění dotazů neţ síťový datový model. Rozšíření RDM nastalo koncem 80. let. Relační datový model lze charakterizovat následujícím způsobem: Hodnoty v tabulkách musejí být atomické. Hodnoty musejí být skalární (nesmějí mít více neţ jeden rozměr). Hodnoty v tabulkách existují jako prvky jednotlivých domén. Všechny prvky dané domény musejí být mezi sebou porovnatelné a musejí náleţet jednomu datovému typu. V kaţdé tabulce jsou hodnoty v jednom nebo více sloupcích (doménách), které slouţí k jednoznačné identifikaci řádek mezi sebou. Tyto hodnoty jsou označovány jako primární klíče tabulky. V některých tabulkách jsou hodnoty v jednom nebo ve více sloupcích, které mají vztah k hodnotám v jiných tabulkách (nebo k hodnotám vlastní tabulky). Tyto hodnoty jsou označovány jako cizí klíče. V tabulkách lze definovat podmnoţiny řádek anebo podmnoţiny sloupců. Operace vybírající podmnoţinu řádek jako výběr řádek z tabulky je označována jako selekce tabulky. Operace vybírající podmnoţinu sloupců jako výběr sloupců z tabulky je označována jako projekce. Více tabulek lze kombinovat mezi sebou jako běţné mnoţiny pomocí operací sjednocení, rozdíl, průnik a kartézský součin mnoţin. Kombinace kartézského součinu a selekce se nazývá spojení tabulek. Základním pojmem teorie relačních datových bází je tedy relace, která je neformálně prezentována jako tabulka. V relační bázi dat jsou datové soubory chápany jako mnoţiny. Z uţivatelského hlediska jsou data v relačním datovém modelu uspořádána v dvourozměrných tabulkách. Kaţdá tabulka je označována termínem relace, která je tvořena záhlavím, kde jsou specifikována jména sloupců (nazývaných téţ atributy) a řádky (označovanými také jako

12

n–tice podle toho, ţe sdruţují hodnoty z n-sloupců, případně také záznamy). Kaţdý sloupec obsahuje hodnoty určitého datového typu, přičemţ obor těchto hodnot, které se v daném sloupci mohou vyskytovat, se nazývá doména sloupce nebo atributu. Průsečíkem řádku a sloupce je označován jako pole. Kaţdé pole nese konkrétní hodnotu. [10]

Sloupec Hodnota

Databáze

Řádek

Tabulka

Obrázek 2 – Struktura dat relační databáze (převzato z [5])

Výhody a nevýhody relačního modelu: + Potenciál odborníků ve firmách, kteří tento model mnoho roků rutinně pouţívají + Potenciál softwaru a vývojových nástrojů pro vývoj a ladění aplikací a pro generování reportů + Pouţitelnost v transakčních databázích i datových skladech –

Absence komplexních analytických nástrojů

–

Potenciální omezení objemu údajů, ke kterým je moţné v rozumném čase přistoupit

[5]

1.1

OLTP – relační databáze

Oblast pouţití transakčních databázových systémů je skoro neomezená. Primárním cílem při jejich návrhu je umoţnit klientům databázového serveru vykonávání velkého mnoţství transakcí online, například bankovních, obchodních a podobně. Cílem transakčních 13

databázových systémů je automatizace kaţdodenních činností, které jsou předmětem našeho podnikání, například skladového hospodářství, mzdy, nákup a prodej, případně řízení a monitorování technologických procesů v reálném čase. Transakční systémy jsou ve firemní praxi velmi často pouţívané a jsou velmi oblíbené, jednak pro svoje výhody, ale i z důvodu existence mnoţství specialistů, ať uţ administrátorů, nebo vývojářů. V případě, ţe transakční databázový systém pokrývá většinu podnikových aktivit, nazýváme ho systémem ERP. Ke zdroji údajů tedy ve stejném čase přistupuje velké mnoţství uţivatelů, kteří údaje z databáze čtou, jiní do něj zapisují, případně někteří vykonávají jednodušší analýzy. Ano, i nad databázemi OLTP je moţné vybudovat analytické aplikace OLAP. Nejen z teorie, ale z praktických zkušeností totiţ vyplývá, ţe údaje v transakčních databázích by měly být uloţeny v normalizovaných tabulkách, které by měly vyhovovat podmínkám druhé nebo třetí normální formy. To znamená mnoho atomických, relačně svázaných tabulek. Analýza velkého mnoţství takto uloţených údajů by byla proto velmi neefektivní a značně pomalá. [5]

1.1.1 Datová normalizace Datová normalizace je postupný reverzibilní proces nahrazování dané mnoţiny relací souhrnem relací, které mají jednodušší a současně i regulérnější strukturu. Tento proces zjednodušování je zaloţen na nestatickém kriteriu. Reverzibilita zaručuje, ţe původní souhrn informací lze kdykoliv obnovit, a proto při pouţití této techniky nedochází ke ztrátě informace. Cíle datové normalizace: Umoţnit reprezentaci kaţdé relace v DB Získat účinné algoritmy vyhledávání, zaloţené na jednodušší mnoţině relačních operací Odstranit v relacích neţádoucí závislosti při operacích vkládání, aktualizace a rušení Redukovat potřebu restrukturalizace při zavedení nového typu dat Zajistit neutrálnost souhrnu relací k četnosti dotazů, které mají tendenci měnit se v čase

14

Normalizace dat představuje takový způsob seskupení datových prvků do struktur záznamů, který zabraňuje problémům s jejich aktualizací. Technika datové normalizace patří mezi základní techniky návrhu relačního databázového schématu. Návrh pomocí tzv. normálních forem byl motivován praktickými problémy souvisejícími především s aktualizací dat v jednotlivých relačních tabulkách. Tato technika slouţí k dekompozičnímu návrhu tabulek s minimální redundancí a maximální konzistencí dat, přičemţ existuje více správných řešení provedené normalizace. Normalizace přináší výhody: Zabránění vzniku duplicitních dat Šetří kapacitu paměťového média Usnadňuje aktualizace a výběry poţadovaných dat Normalizovaná data však nejsou optimalizovaná k výkonnosti DBS z pohledu doby zpracování dotazu. [10]

1NF – Jedna relace nesmí obsahovat násobná data (data ve vztahu 1:N) 2NF – Všechna neklíčová data v jedné relaci musí záviset na celém primárním klíči 3NF – Všechna neklíčová data v jedné relaci musí záviset jen na celém primárním klíči této relace BCNF – (původně 3NF) všechna data v jedné relaci musejí záviset jen na primárním klíči a nikoliv mezi sebou 4NF – sloţený primární klíč nesmí být tvořen z nezávislých dat 5NF – sloţený (3 a více) primární klíč nesmí obsahovat párové cyklické závislosti

Obrázek 3 – Normální formy (převzato z [10])

1. Normální forma je nezbytným předpokladem relačního datového modelu vymezeného původními definicemi E. F. Codda. Pokud má být databáze v souladu s poţadavky relačního datového modelu, tak musí být alespoň v 1NF, která je vymezena pravidlem, ţe v tabulce nesmějí být obsaţeny multizávislosti. Jinými slovy to znamená, ţe pokud v jedné tabulce existují závislosti více hodnot na jedné klíčové hodnotě, tak (vzhledem k tomu, ţe v poloţkách tabulky nesmí být více neţ po jedné hodnotě) je třeba tuto tabulku 15

dekomponovat. Výše uvedená multizávislost se projevuje tzv. neplochostí záznamů, které musí být normalizovány do 2 či více plochých záznamů. [10] Relace je v první normální formě, pokud kaţdý její atribut obsahuje jen atomické hodnoty. Tedy hodnoty z pohledu databáze jiţ dále nedělitelné. [7] 2. Normální forma se týká tabulek se sloţeným klíčem (alespoň ze dvou domén). Pokud tedy má tabulka sloţený klíč, tak je v 2NF jen tehdy, pokud jsou všechny hodnoty v tabulce závislé na celém klíči tabulky. Pokud tomu tak není, tak se tabulky musejí rozkládat. Zjednodušeně tedy lze říci, ţe relace se nachází v druhé normální formě, jestliţe je v první normální formě a kaţdý neklíčový atribut je plně závislý na primárním klíči, a to na celém klíči a nejen na nějaké jeho podmnoţině. Z čehoţ vyplívá, ţe druhou normální formu musíme řešit pouze v případě, ţe máme vícehodnotový primární klíč. Například v tabulce zboţí v obchodě bude atribut název zboţí, výrobce, telefon na výrobce, cena zboţí a mnoţství na skladě. Klíčem této relace je kombinace atributů Název a Výrobce. Telefon výrobce ovšem není závislý na celém klíči, ale pouze na atributu výrobce. To by vedlo k aktualizační anomálii a to k té, ţe pokud by se vymazaly veškeré výrobky od daného výrobce, ztratilo by se jeho telefonní číslo, coţ není zrovna ţádané. Řešením je zmíněný rozklad relace na více relací. [7] 3. Normální forma se týká vzájemných závislostí mezi daty v tabulce. Aby byla tabulka v 3NF, musí dílčí hodnoty v ní obsaţené záviset pouze na klíčových hodnotách a ne mezi sebou. V případě neţádoucí vzájemné závislosti mezi daty se tabulka rozkládá. Obecně řečeno, v této formě se nachází tabulka, splňuje-li předcházející dvě formy a ţádný z jejich atributů není tranzitivně závislý na klíči. Jiné vyjádření téhoţ říká, ţe relace je v 3NF, pokud je ve 2NF a všechny neklíčové atributy jsou navzájem nezávislé. Tranzitivní závislost je taková závislost, mezi minimálně dvěma atributy a klíčem, kde jeden atribut je funkčně závislý na klíči a druhý atribut je funkčně závislý na prvním. Například řekněme, ţe firma chce uchovávat informace o zaměstnancích, takţe vytvoří relaci Zaměstnanec s atributy r. č. (primární klíč), Jméno, Příjmení, Město, PSČ, Funkce a Plat. Z této tabulky je vidět kromě závislosti všech atributů na klíči ještě závislost PSČ a Města a závislost Platu na Funkci. Závislost r.č -> Město -> PSČ je tranzitivní závislost PSČ na klíči, stejně tak závislost r.č. -> Funkce ->Plat. Pochopitelnější je asi druhé vyjádření, podle 16

něj jsou závislosti Město -> PSČ a Funkce -> Plat přesně ty, které porušují sousloví: "všechny neklíčové atributy jsou navzájem nezávislé". Řešením problému je opět zmíněný rozpad na více relací, v tomto případě dokonce na 3. [7] Boyce – Coddova normální forma je někdy nazývána jako 3.5NF a je původní definicí 3NF jak ji v 70. letech publikovali její autoři. BCNF je vymezena stejným pravidlem jako 3NF, ale je přísnější v tom, ţe toto pravidlo musí platit i mezi hodnotami uvnitř sloţeného primárního klíče. Nejsnáze Boyce – Coddovu normální formu pochopíme s pomocí funkčních závislostí. Boyce – Coddova normální forma v podstatě říká, ţe mezi kandidátními klíči nesmí být ţádná funkční závislost. Například relace adresář s atributy Město, Ulice a PSČ. V této relaci platí dvě netriviální funkční závislosti, {Město, Ulice} -> PSČ a PSČ -> Město. Protoţe neplatí Ulice -> PSČ ani Město -> PSČ, tvoří dvojice {Město, Ulice} klíč schématu. Klíčem je ale i {Ulice, PSČ} platí totiţ PSČ -> Město, nikoliv však PSČ -> Ulice. Tudíţ je {PSČ, Ulice} kandidátním klíčem schématu. Schéma má všechny atributy atomické a nemá ţádný neklíčový atribut a tudíţ je v 3NF, ale není v BCNF. Tento fakt vede k tomu, ţe nelze evidovat města s PSČ bez znalosti Ulice a krom toho jsou v relaci redundantní data, pokud by se evidovalo velké mnoţství ulic v jednom městě, začal by to být problém. Klasické řešení, rozpad na dvě tabulky. Vzhledem k tomu, ţe neplatí PSČ -> Ulice, musíme spojit PSČ a Ulice. Výsledkem tudíţ budou relace Města (PSČ, Město) a Ulice (PSČ a Ulice). 4. Normální forma se zabývá vztahy uvnitř sloţeného primárního klíče. Pokud je totiţ v tabulce sloţený primární klíč, tak se můţe stát, ţe některé hodnoty tohoto klíče jsou na sobě nezávislé, ale tím, ţe společně vytváří sloţený klíč, tak vzniká falešná souvislost mezi těmito hodnotami a nemohou existovat nezávisle na sobě, coţ není v souladu s modelovanou realitou. 4NF proto vyţaduje, aby klíč tvořily jen ty hodnoty, které mají skutečnou vzájemnou souvislost, a v případě nezávislých hodnot se vyţaduje rozklad. Jinými slovy, ve čtvrté normální formě je relace tehdy, je-li v BCNF a všechny vícehodnotové závislosti obsaţené v relaci jsou zároveň funkčními závislostmi. Vícehodnotovou závislost atributů lze definovat následovně: V relaci R, která je v BCNF, s atributy A, B, C nastává vícehodnotová závislost atributu B na atributu A právě tehdy, jestliţe mnoţina hodnot B přiřazená dvojici hodnot A, C závisí jen na hodnotě atributu A a je nezávislá na hodnotě atributu C. 17

Například, mějme relaci zachycující vztah zaměstnance, kvalifikace a úkolu: Pracovní zařazení (Zaměstnanec, Úkol, Kvalifikace). Všechny atributy dohromady tvoří klíč schématu a neexistuje mezi nimi ţádná funkční závislost, tudíţ je v BCNF a všechno vypadá ideálně, ale není tomu tak. I kdyţ se dá předpokládat, ţe atributy Kvalifikace a Úkol jsou na sobě nezávislé, tak tabulka neumoţňuje zachytit kvalifikaci zaměstnance, který nemá přiřazen ţádný úkol a nelze ani úkolovat zaměstnance bez kvalifikace. Krom ztráty informací se rozkladem vyvarujeme i redundance dat. Tudíţ je opět nutno tabulku rozdělit a to na dvojici: Kvalifikace (Zaměstnanec, Kvalifikace), Úkol (Zaměstnanec, Úkol). 5. Normální forma je poslední v praxi pouţívanou normální formou a týká se primárních klíčů, které jsou tvořené nejméně třemi hodnotami. V případě, ţe mezi těmito hodnotami v klíči existují párové cyklické závislosti, tak je třeba tyto závislosti extrahovat do samostatných tabulek (ale původní tabulka zůstává zachována). Tyto zdánlivě nadbytečné tabulky nám pak umoţňují udrţovat informaci o zmíněných závislostech i v případě, ţe hlavní tabulka neobsahuje záznam s odpovídajícími hodnotami a jeho sloţeného klíče. [10] K porušení 5NF musí opět být splněno několik podmínek a to dost specifických. Relace musí být ve 4NF a musí mít klíč sloţený ze třech nebo více atributů a mezi nimi musí být párové cyklické závislosti, ale nikoliv funkční, ani multizávislosti, to by nebyla ve 4NF. Typicky se jedná o vztah třech a více tabulek, kde platí vztahy M:N:O:M a tento vztah je vytvořen jednou relací. 5NF řeší redundanci dat a moţnou ztrátu závislostí. Například, mějme firmu, která provozuje síť obchodních zástupců strojírenských firem pro celou Evropu. Ta potřebuje vědět, který zástupce zastupuje kterou firmu a v jakých státech a ve kterých státech firmy působí. Předpokládejme, ţe o Zástupcích, Firmách i Státech máme vytvořeny informační relace a pouţité hodnoty jsou pouze cizí klíče, kterými řešíme vztahy mezi těmito relacemi. Zdánlivě jednoduché: Problém vypadá na první pohled vyřešeně, ale dle naší definice páté normální formy tomu tak není, neboť zde existují závislosti Zástupce-> Firma -> Sát -> Zástupce a to jsou párové cyklické závislosti. Mohlo by se stát, ţe s vymazáním obchodního zástupce, by se mohla ztratit informace o tom, ţe firma prodává v zemi, kde jí zastupoval pouze ten smazaný zástupce a to je pochopitelně neţádoucí. Stejně tak odebrání firmy můţe způsobit ztrátu informace o působení obchodního zástupce v některé zemi a to je taktéţ neţádoucí. Takţe musíme provést rozpad na tři relace, které nám pokryjí všechny vztahy. Zdá se, ţe problém je vyřešen, nicméně není. Jedna z definic říká, ţe relace je v páté normální formě, pokud jiţ nelze bezeztrátově rozdělit na menší relace. Důleţité je slovíčko 18

bezeztrátově. Protoţe pokud si spojíme výsledné tabulky pomocí přirozeného spojení, nedostaneme původní výsledek. Dostaneme úplně jiné informace. [7]

1.2

OLAP – multidimenzionální databáze

Na úvod problematiky budování datových skladů uvedu definici datového skladu podle Billa Inmona. Datový sklad je podnikově strukturovaný depozitář subjektově orientovaných, integrovaných, časově proměnlivých, historických dat použitých na získávání informací a podporu rozhodování. V datovém skladu jsou uložena atomická a sekundární data.

Datový sklad

Provozní transakční databáze

Vkládání, aktualizace, mazání, čtení

Čtení

Obrázek 4 – Pohyb dat

(převzato z [6])

Jednotlivé pojmy, které tvoří definici, jsou: Subjektová orientace. Data se do datového skladu zapisují spíše podle předmětu zájmu neţ podle aplikace, ve které byla vytvořena. Datový sklad neuchovává data, která nejsou vhodná pro podporu rozhodování na manaţerské úrovni. Integrovanost a sjednocení. Data, která se týkají konkrétního předmětu, se do datového skladu ukládají jen jednou.

19

Zahrnuje sjednocení názvů stejných ukazatelů, sjednocení měr, sjednocení kódování (například pohlaví M, muţ, 0, Ţ, ţena, 1 atd.) Časová variabilita. Data se ukládají do datového skladu jako série snímků, ze kterých kaţdá reprezentuje určitý úsek. Neměnnost.

Data v datovém skladu se obvykle nemění ani neodstraňují, jen se

v pravidelných intervalech přidávají nová data. Data se získávají z uloţených dat do produkčních databází, které mohou být v různých odděleních firem anebo dokonce v rozličných lokalitách. Tato data se v pravidelných intervalech sbírají, předzpracují se a zavedou se do datového skladu. Datový sklad je v podstatě také databáze, jen je organizována podle uvedených pravidel. Rozdíly mezi transakčním prostředím relačních databází a OLAP prostředím datových skladů, charakterizuje následující tabulka. Tabulka č. 1, rozdíly v architekturách Vlastnost Čas odezvy Operace Původ dat Organizace dat Velikost Zdroje dat Činnosti

Transakční databáze Zlomky sekund až sekundy DML 30 – 60 dní Podle aplikace Malá až velká Operační, interní Procesy

Datový sklad Sekundy až hodiny Primárně jen čtení Série snímků za časový úsek Podle předmětu, času… Velká až velmi velká Operační, interní, externí Analýza

Nástroje na budování a provoz datových skladů představují poměrně velkou počáteční investici za hardware a software, takţe datové sklady vyuţívají většinou banky, pojišťovny, mobilní operátoři, velké obchodní řetězce a podobně. Datový sklad, i kdyţ můţe obsahovat mnohé informace, je hlavně prostředkem na získávání informací pro podporu rozhodování. Bez analytických nástrojů by se i nejdokonaleji navrţený a organizovaný datový sklad stal jen shromaţdištěm dat. [6] Data v datovém skladu představují jakýsi neutrální datový prostor, který není vytvářen s myšlenkou konkrétních analýz. Proto se doporučuje vytvářet v návaznosti na datový sklad řadu tzv. specializovanějších datových trţišť (data-mart), kam se z datového skladu přesunou

20

data relevantní pro určitý typ analýz (pro určité oddělení firmy). Mluví se pak o třívrstvé architektuře datového skladu. Viz Obrázek 5 – Třívrstvá architektura.

Produkční databáze

1. vrstva

2. vrstva Datový sklad

3. vrstva

Datové tržiště

Obrázek 5 – Třívrstvá architektura (převzato z [2])

OLAP servery můţou být děleny podle způsobu, jakým ukládají data. Můţeme jmenovat následující modely. Multidimenzionální OLAP – MOLAP Získává data z datového skladu anebo transakčních databází. Po jejich získání vypočítá výsledky a uloţí je ve vlastních multidimenzionálních strukturách. Z existujících dat jsou na základě výpočtů a transformací získána nová data. Databáze je organizována tak, aby umoţnila rychlé získání příslušných dat z více dimenzí. Připravená sumární data a předem vypočítané hodnoty umoţní rychlou a jednoduchou analýzu. Tato architektura OLAP databáze se hodí pro středně velké, statické aplikace. Vzhledem k tomu, ţe výpočty souhrnů vyţadují jistý čas, není MOLAP řešení vhodné pro dynamické aplikace, kde jsou povaţovány informace z průběţně aktualizovaných dat. [2]

Relační databázový OLAP – ROLAP Získává data z relačně organizovaného datového skladu. Uţivateli však poskytuje pro tato data zobrazení ve formě multidimenzionálního pohledu. Nevýhodou je potřeba vysokého výpočetního výkonu. V tomto případě se dotazy OLAP převádějí do klasických dotazů SQL.

21

ROLAP je vhodný pro rozsáhlé aplikace hojně vyuţívající transakčních dat. Výhodou je schopnost zpracovávat rozsáhlá data za pouţití existujících databázových technologií. [6] Hybridní databázový OLAP – HOLAP HOLAP je kombinací obou zatím uvedených modelů. Zdrojová data jsou uloţena v relačních databázích a výsledky výpočtů a agregací jsou uloţeny v multidimenzionálně organizované databázi.

MOLAP

Uživatelské rozhraní

ROLAP

OLAP engine

SQL egine

Sumarizovaná data

Granulární data

Obrázek 6 – MOLAP a ROLAP zpracování (převzato z [2])

OLAP architektura představuje přímé analytické zpracování velkého mnoţství dat v reálném čase. Na rozdíl od architektury OLTP, kde je typickou operací čtení a změna specifické či malé skupiny záznamů, OLAP pracuje s mnoţinou dat a prováděné operace nad daty jsou zpravidla pouze čtení. Pod termínem přímého zpracování v reálném čase si můţeme představit dostatečně rychlou práci s obrovským mnoţstvím dat, typicky desítky milionů záznamů fyzicky reprezentujících několik GB paměťového prostoru, jeţ musí být systém schopen nahlíţet z poţadovaných hledisek a měr a interaktivně tyto pohledy poskytovat uţivateli. Tabulka č. 2, osy a buňky Rok Produkt Celkem Knihy Poezie Cizojazyčné Časopisy Blahopřání

Tržba 7073 2753 1341 1412 2753

2000 Kusů 2693 824 424 400 824

Tržba 7636 3331 1202 2129 2426

2001 Kusů 3008 966 380 586 766

Tržba 8% 21% -10% 51% -12%

Růst Kusů 12% 17% -10% 47% -7%

1567

1045

1879

1276

20%

22%

22

Tabulka č. 2 zobrazuje osu řádku, který obsahuje hodnoty „Celkem“, „Knihy“, „Poezie“, „Cizojazyčné“, „Časopisy“ a „Blahopřání“ a osu sloupce, který obsahuje agregované hodnoty k rokům 2000 a 2001, dále pak vypočtené hodnoty procentuálních rozdílů, označené jako „Růst“. Mírou pro tyto osy je pak „Trţba“ a „kusy“. Kaţdá buňka potom reprezentuje hodnoty prodeje daného artiklu v daném roce, vyjádřené v jednotkách kusů a utrţené hodnoty. Toto je komplexnější pohled na data, neţ běţně bývá nabídnut architekturou OLTP. Dimenze „Produkt“, „Rok“ a míry zmíněné v této tabulce jsou jenom 3 z mnoha dimenzí, v kterých mohou být data agregována a filtrována. Soubor dimenzí, hierarchií jejich úrovní

Tr ž

ba

Produkt

a měr je nazýván multidimenzionální kostka. [4]

Čas

Obrázek 7 – Multidimenzionální krychle (vlastní tvorba)

Na rozdíl od geometrické krychle můţe mít multidimenzionální databázový model i více dimenzí neţ tři, řádově i běţně desítky. Údaje se nacházejí v průnicích jednotlivých dimenzí. Můţeme analyzovat údaje jen za určité časové období, například abychom vyhodnotili výsledky reklamní kampaně nebo sledovanost webové stránky za určité období a podobně.

23

Výhody a nevýhody multidimenzionálního modelu: + Rychlý komplexní přístup k velkému objemu dat + Přístup k multidimenzionálním a relačním datovým strukturám + Moţnost komplexních analýz + Silné schopnosti pro modelování a prognózy –

Problémy při změně dimenzí, bez přizpůsobení časové dimenzi

–

Vyšší nároky na kapacitu úloţiště

Záznamy v transakčních systémech obsahují informace například o prodeji různých produktů v různých dnech a v různých městech. Tyto databáze můţeme převést na krychle tak, ţe jednotlivé sledované atributy budou tvořit dimenze krychle, buňky krychle pak odpovídají jednotlivým záznamům v databázi. Tento způsob uloţení umoţňuje různé pohledy na data (natočení krychle, provádění řezů), ale plýtvá se při něm místem. Řada buněk je v krychli prázdných, tento stav se nazývá řídkou maticí, viz Tabulka č. 3, řídká matice. Datová krychle obsahuje jak data z transakčních databází, tak z dílčí souhrny. Právě proto tyto souhrny umoţňují rychlou odezvu a dotazy uţivatele. Práce s krychlí spočívá v různém natáčení (pivot), provádění řezů (slice), výběrů určitých částí (dice) a zobrazování různých agregovaných hodnot. Velmi často lze hodnoty atributů sdruţovat do hierarchií a těchto úrovní bývá obvykle více. Tyto hierarchie se vyuţívají při práci s krychlí při operacích roll-up a drill-down. Při roll-up se přechází na hierarchicky vyšší, obecnější úroveň, kdy mají zobrazované údaje podobu souhrnů, při drill-down se přechází na podrobnější pohled na data. V tomto kontextu se mluví o granuralitě, podrobnosti pohledu na data. [14] Tabulka č. 3, řídká matice Datum 10.1. 10.2.

šrouby 241 92

Praha Matky 61

podložky

Brno Matky

šrouby 17

27

podložky 42

šrouby

Kladno Matky

podložky

35

Každá krychle OLAP byla vytvořena na základě dvou druhů údajů: faktů a dimenzí. Fakta jsou numerické měrné jednotky. Tabulky faktů a dimenzí mohou vytvářet určitá schémata, například hvězdicové (star schema) nebo schéma sněhové vločky (snowflake 24

schema). Hvězdicové schéma obyčejně obsahuje jen jednu tabulku faktů, jiné, hlavně schémata DSS, mohou obsahovat i více tabulek faktů. Prvotní fakta se mohou kombinovat nebo vypočítat pomocí jiných faktů a vytvořit tak měrné jednotky. Měrné jednotky se mohou uloţit v tabulce faktů, případně vyvolat, kdyţ je to nevyhnutelné, na účely vykazování. Dimenze obsahují logicky nebo organizačně hierarchicky uspořádané údaje. Jsou to vlastně textové popisy hodnot v tabulce faktů. Tabulky dimenzí jsou obyčejně menší neţ tabulky faktů a data v nich se nemění tak často. Velmi často se pouţívají časové, produktové nebo geografické dimenze. Většinou obsahují data ve stromové struktuře. Například dimenze vytvořené na základě časových informací, se člení na jednotlivé úrovně podle zařazení na časové ose, například Rok s podúrovní kvartál, kvartál s podúrovní měsíc, měsíc s podúrovní týden atd. V této analogii lze pouţívat i produktové či jiné dimenze.[5] Ne kaţdé dimenzi musí nutně příslušet dimenzní tabulka. Pokud máme dimenzi s nízkou kardinalitou (několik málo záznamů), případně dimenzi, která má podobu číselníku, je zbytečné pro takovou dimenzi vytvářet separátní dimenzní tabulku. V takovém případě je moţné hodnoty z domény této dimenze pouţít jako součást primárního klíče faktové tabulky, ve které se má tato dimenze uplatnit. Dimenze tohoto typu nazýváme degenerované. Existuje jedna výjimka. Pokud má degenerovaná dimenze podobu číselníku, avšak patří do nějaké hierarchie, je výhodné i pro tuto dimenzi vytvořit dimenzní tabulku. Agregace hodnot do nadřazené úrovně je pak mnohem jednodušší. [14] Tabulky faktů a tabulky dimenzí jsou jedním z příkladů, kdy normalizace databázových tabulek nejenţe nepřináší ţádný efekt, ale v případě tabulek dimenzí by mohla v mnoha případech nepříliš velká úspora uloţené kapacity přinést sníţení výkonu, a tím také prodlouţení doby potřebné pro analýzu.[6]

1.2.1 Schémata uspořádání tabulek faktů a dimenzí Krychli vytváříme na základě dimenzionálního modelu, který má určité topologické uspořádání, kterému říkáme schéma. Nejčastěji je pouţívané schéma hvězdicové, které se skládá z centrální tabulky faktů, obsahující cizí klíče, které se vztahují k primárním klíčům v tabulkách dimenzí. Pro kaţdou dimenzi existuje jedna tabulka, která obsahuje údaje na různé úrovni hierarchie. Úroveň

25

v hierarchii se rovněţ zaznamenává jako další indikátor do tabulky dimenzí. Tento identifikátor je nutný při dotazování do tabulky, která obsahuje současně data detailní i agregovaná. Hvězdicové schéma nemá normalizované dimenze ani relační propojení mezi tabulkami dimenzí, proto je velmi lehce pochopitelné a v důsledku nenormalizovaných dimenzí je vytvoření takového modelu relativně pomalé, ale na druhé straně tento model poskytuje vysoký „dotazovací výkon“. Schematicky je hvězda znázorněna, viz Obrázek 8 – Hvězdicové schéma.

Tabulka dimenzí

Tabulka dimenzí

Tabulka faktů

Tabulka dimenzí

Tabulka dimenzí

Obrázek 8 – Hvězdicové schéma (převzato z [5])

Data v tabulce dimenzí v této topologii mohou vypadat stejně, jako ukazuje Tabulka č. 4, denormalizovaná tabulka. Tabulka č. 4, denormalizovaná tabulka Time_ID 367 368 369 370 371 372

Date 1997-01-01 1997-01-02 1997-01-03 1997-01-04 1997-01-05 1997-01-06

Day Wednesday Thursday Friday Saturday Sunday Monday

Month January January January January January January

Year 1997 1997 1997 1997 1997 1997

DayOfMonth 1 2 3 4 5 6

WeekOfYear 2 2 2 2 3 3

MonthOfYear 1 1 1 1 1 1

Quarter Q1 Q1 Q1 Q1 Q1 Q1

Sestavit takovouto tabulku vyţaduje určité úsilí, ale pro kaţdý den okamţitě víme jeho pořadí v týdnu, kvartálu, v roce, jméno dne a měsíce a podobně. Z této struktury pramení vysoký výkon, protoţe všechny údaje získáme najednou a nemusíme je skládat z relačních tabulek.

26

Schéma sněhové vločky obsahuje některé dimenze sloţené z mnoha relačně svázaných tabulek. Tento model umoţňuje rychlejší zavedení údajů do normalizovaných tabulek dimenzí, ale má podstatně niţší dotazovací výkon, neboť obsahuje větší mnoţství spojení tabulek.[5]

Tabulka dimenzí Tabulka dimenzí

Tabulka dimenzí

Tabulka dimenzí Tabulka faktů

Tabulka dimenzí Tabulka dimenzí

Tabulka dimenzí

Tabulka dimenzí

Obrázek 9 – Schéma sněhové vločky (převzato z [5])

1.3

Dotazovací jazyky

Každý dotazovací jazyk určený pro SŘBD musí splňovat následující předpoklady: Musí obsahovat konstrukce, ze kterých lze skládat příkazy pro definici nových dat včetně jednoznačného popisu jejich struktury. Tato část dotazovacího jazyka se nazývá jazyk pro definici dat, DDL. Musí obsahovat konstrukce, ze kterých lze skládat příkazy pro kladení dotazů nad mnoţinou dat v databázi, pro vkládání nových dat, rušení a změny existujících dat. Tato část dotazovacího jazyka je nazývána jako jazyk pro manipulaci dat, DML.

27

Musí obsahovat konstrukce pro řízení přístupových práv jednotlivých uţivatelů systému a také např. pro řízení transakcí (někdy jsou příkazy pro řízení transakcí začleněny do zvláštní skupiny příkazů pro řízení transakcí, TCL). Tato část dotazovacího jazyka je označována jako jazyk pro řízení dat, DCL. Kromě textového přístupu uplatněného v dotazovacích jazycích se v poslední době stále více pouţívají prostředky vizuálního programování, pomocí kterých se příslušné příkazy skládají z grafických symbolů v uţivatelském rozhraní. Přitom je však potřeba si uvědomit, ţe i kdyţ textový a vizuální přístup se z pohledu uţivatele od sebe velmi odlišuje, tak z pohledu SŘBD, který je řízen příkazy dotazovacího jazyka, se oba postupy od sebe neliší. Podle způsobu zadávání dotazů rozlišujeme dotazovací prostředky na jazyky procedurální a neprocedurální. Procedurální jazyky vyţadují zadání algoritmu pro získání poţadované odpovědi, neprocedurální jazyky jsou jednodušší a vyţadují pouze specifikování podmínky, kterou má poţadovaná odpověď splňovat. Nejznámějším neprocedurálním jazykem je SQL. [10]

1.3.1 SQL Databázový jazyk SQL vznikl na základě projektu společnosti IBM pod názvem SEQUEL. Cílem projektu bylo vytvořit jazyk blízký angličtině pro práci s daty v relačních databázích. Postupem času se ujaly vylepšení a upravené standardy tohoto jazyka s označeními SQL 86 a SQL 92, pro které se zaţilo označení SQL 2. V současné době je nejrozšířenějším standardem SQL 3. [6] Jak jiţ bylo zmíněno, jazyk SQL prošel normalizací ANSI, ale v praxi tuto normu dodrţuje pouze IBM a Oracle. Ve skutečnosti tedy existuje celá třída podobných jazyků typu SQL, které se liší od produktu k produktu. Největší odchylky od normy má implementace SQL v produktech firmy Microsoft, především ve specifikaci ODBC rozhraní. V následujících odstavcích tato práce obecně popisuje základní příkazy jazyka SQL, které jsou implementovány napřič produkty ze světa relačních databází a jsou nedílnou součástí administrátorských a vývojářských prácí s nimi spojenými, především pak ty, které budu vyuţívat v praktické části této práce, viz kapitola 3.

28

1.3.1.1 Příkazy DDL Skupina těchto příkazů obsahuje převáţně prostředky pro vytváření struktur v databázi. Jsou zde definovány tři typy příkazů. Příkazy typu CREATE, které slouţí k vytvoření popsaného objektu v databázi, příkazy typu ALTER, které slouţí k modifikaci jiţ existujícího objektu podle předaného popisu a příkazy typu DROP, které slouţí k odstranění objektu z databáze. V této části přiblíţím ty nejdůleţitější příkazy DDL jazyka SQL. Vytvoření/změna tabulky – CREATE/ALTER TABLE Pomocí těchto příkazů se vytváří tabulka v poţadované struktuře. Definují se integritní omezení, výchozí chování tabulky atd. Syntaxe příkazu můţe vypadat takto: CREATE TABLE jméno tabulky ( <definice sloupce>, … )

Případně ALTER TABLE jméno tabulky ( [ADD | ALTER | DROP] <definice sloupce>, [ENABLE | DISABLE CONSTRAINT jmeno omezení] … )

Konstrukce <definice sloupce> pak obecně obsahuje tyto parametry: Jméno sloupce [COLLATE jméno collace] [NULL | NOT NULL] [CONSTRAINT jméno omezení {PRIMARY KEY | UNIQUE }{, CHECK logická podminka}] [DEFAULT výraz pro defaultní hodnotu] [FOREIGN KEY (referencované pole) pole)] [IDENTITY {inkrement}]

29

REFERENCES jméno tabulky (jméno

Syntaxe tohoto příkazu je velmi obsáhlá a celý popis je nad rámec této práce. Konkrétní příklad pouţití příkazu CREATE TABLE, viz kapitola 3 této diplomové práce. Odstranění tabulky z databáze – DROP TABLE Pro odstranění tabulky z databáze se pouţívá příkaz DROP TABLE, za kterým následuje parametr určující tabulku, která má být odstraněna. Příkaz DROP TABLE nesmí porušit integritní omezení vystavěná nad databází. Vytvoření/změna pohledu – CREATE/ALTER VIEW Příkaz CREATE/ALTER

VIEW vytvoří virtuální tabulku, jejíţ obsah a struktura je

definována databázovým dotazem. Syntaxe příkazu můţe vypadat následovně: CREATE VIEW jméno pohledu AS

Odstranění pohledu z databáze – DROP VIEW Pro odstranění pohledu z databáze se pouţívá příkaz DROP VIEW, za kterým následuje parametr určující pohled, který má být odstraněn. Vytvoření/změna uložené procedury –CREATE/ALTER PROCEDURE Hlavním omezením jazyka SQL je fakt, ţe se jedná o neprocedurální jazyk. V praxi to znamená, ţe příkazy jazyka se provádějí sekvenčně bez moţnosti pouţití klasických programátorských konstrukcí, jako jsou například cykly, podmínky, procedury, funkce či prvky objektového programování. Vzhledem k tomu, ţe tyto omezení jsou nevýhodná, nabízí takřka kaţdá moderní databázová platforma procedurální rozšíření jazyka SQL. Např. Oracle má název PL/SQL, Microsoft SQL server pouţívá Transact-SQL. Obecně lze říci, ţe rozšířením jazyka o jeho procedurální část, bylo umoţněno uloţit do databáze krom samotných dat a jejich popisu, také aplikační logiku pro zpracování těchto dat. Toto řešení přispívá nejen k přehlednosti a spolehlivosti, ale také k minimalizaci přenášených dat mezi datovou a aplikační vrstvou. Velkou výhodou uloţených procedur je fakt, ţe jsou uloţené v databázi v předkompilované podobě, takţe databázový server neztrácí čas s analýzou a interpretací procedur, ale provádí jiţ předkompilovaný kód. 30

Obecně lze deklaraci uloţené procedury zapsat takto: CREATE PROCEDURE

název procedury

( Seznam parametrů … ) AS BEGIN Tělo procedury END

Odstranění uložené procedury z databáze – DROP PROCEDURE Pro zrušení uloţené procedury pouţíváme následující příkaz doplněný o parametr názvu uloţené procedury. DROP PROCEDURE název procedury

Vytvoření/změna databázového triggeru –CREATE/ALTER TRIGGER Pod pojmem trigger rozumíme pojmenovanou mnoţinu příkazů, která se automaticky provede v případě předem definované operace s daty, například vloţení nového záznamu, při vymazání či změně apod. Mohou se pouţívat např. na kontrolu zadávaných dat, pro zajištění referenční integrity atd. Trigger je chápan jako speciální případ uloţené procedury. Nikdy se neprovádějí přímo, ale jsou svázány s konkrétní událostí. Cílem triggerů nikdy není vrácení výsledků nějakého dotazu. V dnešních SŘBD je moţno definovat více druhů triggerů, jako například triggery pro DDL příkazy, triggery pro příkazy DML či triggery pro autentifikaci uţivatele do databáze. Obecně můţe vytvoření DML triggeru nad tabulkou mít takovouto syntaxi: CREATE TRIGGER název triggeru ON název tabulky { BEFORE | AFTER} [INSERT | UPDATE | DELETE] AS BEGIN Tělo procedury END

31

Odstranění databázového triggeru z databáze –DROP TRIGGER Odstranění triggeru se provede příkazem: DROP TRIGGER jméno triggeru

Do skupiny DDL příkazů patří ještě další příkazy a konstrukce pro obsluhu indexů, funkcí, databázových omezení či samotných databází a jejich vlastností. Popis těchto příkazů a jejich syntaxe je nad rámec této práce.

1.3.1.2 Příkazy DML S příkazy této podmnoţiny jazyka SQL se vývojáři databázových aplikací střetávají pravděpodobně nejčastěji. Příkazy jazyka DML umoţňují vkládání, aktualizaci, mazání a výběr dat. Výběr dat z databáze – příkaz SELECT Příkaz SELECT umoţňuje cílený výběr dat z databáze. Úplná syntaxe příkazu SELECT je poměrně sloţitá. Pro účely obecného přiblíţení uvedu jeho zjednodušenou syntaxi. SELECT [*] [seznam položek výstupní sestavy] FROM název tabulky WHERE podmínka výběru GROUP BY položky HAVING podmínka agregace ORDER BY seznam položek [ASC] [DESC]

[6] Operace projekce slouţí pro potlačení sloupců, které nejsou předmětem zájmu. Výsledkem je relace o p-sloupcích, která vznikla z původní relace s n-sloupci, přičemţ platí, ţe p
A

B

C

D

F

G

A

1

1

2

2

3

3

4

4

Obrázek 10 – Operace projekce (převzato z [10])

32

B

D

Operaci projekce realizujeme pomocí příkazu SELECT a to díky výčtu poţadovaných sloupců oddělených čárkou, případně pouţití zástupného znaku *, který vybírá všechny dostupné sloupce. Moţnosti projekce výběrem sloupců nekončí. V této části příkazu SELECT je moţné pouţívat aliasů, aritmetických operátorů, zřetězení apod. Alias je v tomto kontextu pojmenování vybíraného sloupce, případně sloupce vzniklého jménem pomocí klíčového slova AS. V klauzuli SELECT je moţno pouţít i aritmetických operátorů pro práci se sloupci s numerickými či datumovými datovými typy se stejnou prioritou operátorů jako v klasické aritmetice. Priorita těchto aritmetických operátorů je ovlivněna pouţitím závorek. Zřetězením textových datových typů je moţné pouţít v případě, kdy potřebujeme sloučit několik textových polí či hodnot do jednoho textu. Klauzule SELECT můţe obsahovat i klíčová slova DISTINCT pro vyloučení duplicitních záznamů, případně klíčové slovo TOP s argumentem počtu prvních zobrazených vět v celkové výsledkové sadě. Při operaci selekce vzniká nová relace, do které jsou vybírány pouze ty řádky, které splňují uţivatelem specifikovanou podmínku. Schematicky lze tuto operaci znázornit viz Obrázek 11 – Operace selekce. [10]

A

B

C

D

F

G

A

1

1

2

3

3 4

Obrázek 11 – Operace selekce (převzato z [10])

33

B

C

D

F

G

Operaci selekce realizujeme v příkazu SELECT pomocí klauzule WHERE. Do této klauzule zapisujeme logické podmínky, které lze kombinovat pomocí logických operátorů AND, OR a NOT. Pro samotné logické podmínky lze vyuţívat především jednoduché porovnávací operátory jako rovnost, větší menší, větší nebo rovný, nerovný atd. či komplexnější operátory jako je BETWEEN … AND pro porovnávání intervalů, IN pro porovnávání mnoţiny hodnot, LIKE pro porovnávání řetězců na základě jejich částí, IS NULL pro porovnávání hodnot, které nebyly zadány a další. Pomocí příkazu SELECT a jeho klausule ORDER BY, můţeme výslednou sadu dat seřadit dle libovolných sloupců vyčtených v klauzuli SELECT, a to buď vzestupně nebo sestupně za pomoci klíčového slova DESC pro sestupné řazení a ASC pro vzestupné řazení. Spojení je jednou z hlavních operací relační algebry. Spojením dvou relací se vytváří třetí relace, přičemţ výsledná tabulka vţdy obsahuje všechny kombinace, které vyhovují zadané podmínce. Operace spojení lze schematicky znázornit viz Obrázek 12 – Operace spojení. [10]

A

B

A

B

D

E

1

Jedna

1

Jedna

A

aaa

2

dvě

1

Jedna

B

bbb

3

Tři

2

dvě

A

aaa

D

E

2

dvě

B

bbb

A

aaa

3

Tři

A

aaa

B

bbb

3

Tři

B

bbb

Obrázek 12 – Operace spojení (převzato z [10])

Principy relační databáze a pravidla pro normalizaci vyţadují, aby byla data umístěna v tabulkách, jeţ mají atomickou strukturu a aby byla uloţena ve více relačně svázaných tabulkách. Princip spojení je v příkazu SELECT řešen pomocí klauzule FROM. V klauzuli je moţné definovat, které tabulky, pohledy či subselecty se budou účastnit výstupu databázového

34

dotazu. Samotné spojení můţe být deklarováno jen za pomoci klauzule FROM a WHERE, nebo, přehledněji, můţeme v klauzuli FROM pouţít konstrukci JOIN. V konstrukci JOIN je moţno definovat druh spojení tabulek, jejich alias ve výsledkové sadě a podmínku spojení. Typickým příkladem pouţití konstrukce JOIN můţe vypadat následovně: SELECT tab1.hodnota, tab2.hodnota, tab3.hodnota FROM tabulka1 AS tab1 INNER JOIN tabulka2 AS tab2 ON tab1.ID = tab2.ID LEFT OUTER JOIN tabulka3 AS tab3 ON tab2.ID_Z = tab3.ID_Z

Někdy je výhodné zpracovávat data, která jsou na základě určitého kritéria seskupená do skupin. V syntaxi příkazu SELECT jsou podpoře této funkce vyhrazeny klauzule GROUP BY a HAVING. Za klíčovým slovem GROUP BY SŘBD očekává výčet sloupců, podle kterých bude data ve výsledkové sadě seskupovat. Nad těmito skupinami potom lze aplikovat agregační funkce, jako jsou maximální a minimální hodnoty, počet záznamů ve skupině, průměrná hodnota či suma numerických hodnot. Klauzule HAVING slouţí k vyloučení skupinových výsledků z dalšího zpracování. V předcházejícím odstavci jsem uvedl, ţe klauzule WHERE slouţí pro omezení záznamů, které se potom seskupují pomocí klauzule GROUP BY. Rozdíl mezi těmito dvěma klauzulemi je mnoţina dat, nad kterou se její podmínka uplatňuje. Klauzule HAVING slouţí k selekci záznamů z výstupní mnoţiny výsledkové sady dotazu. Konkrétní příklad pouţití příkazu SELECT se všemi zde popsanými i nepopsanými moţnostmi viz kapitola 3 této diplomové práce. Vkládání dat do tabulky – příkaz INSERT Pro přidávání dat do databáze se pouţívá příkaz INSERT. Základní syntaxi lze zapsat následujícím příkladem. INSERT INTO název tabulky [ (sloupec1 [, sloupec2..])] VALUES [ (hodnota1 [, hodnota..])]

nebo

35

INSERT INTO název tabulky [ (sloupec1 [, sloupec2..])] SELECT sloupec1 [, sloupec2..])] FROM název tabulky zdroje dat

Zápis jednotlivých hodnot v klauzuli VALUES se provádí podle konotace konkrétního SŘBD. Obecně lze říci, ţe číselné hodnoty zadáváme bez apostrofů, znakové řetězce a hodnoty pro datum a čas zadáváme v apostrofech. Výčet jednotlivých sloupců lze vynechat, ale v takovém případě musíme zadat hodnoty pro všechny sloupce a v takovém pořadí, jak jsou definovány v tabulce. Při provádění příkazu INSERT musíme samozřejmě respektovat integritní omezení, která byla určena při vytváření tabulky. Konkrétní příklad pouţití příkazu INSERT viz kapitola 3 této diplomové práce. Změna dat v tabulce – příkaz UPDATE Jazyk SQL obsahuje pro aktualizaci záznamů příkaz UPDATE. Nejčastěji se s tímto příkazem setkáváme v tomto následujícím tvaru. UPDATE tabulka SET sloupec = hodnota [, sloupec1 = hodnota1..] FROM tabulka WHERE podmínka

Kde v klauzuli UPDATE specifikujeme tabulku obsahující záznamy, které chceme příkazem UPDATE aktualizovat. Pokud v příkazu UPDATE pouţijeme klauzuli FROM, je moţné aktualizovat data i na základě dat z jiných tabulek. I zde je moţné vyuţívání aliasů pro vyčtené tabulky. Klauzule WHERE má stejné pouţití a syntaxi jako u příkazu SELECT a určuje, které záznamy mají být aktualizovány. Provedenou změnu nad specifikovanými záznamy definuje klauzule SET. I pro příkaz UPDATE platí definovaná integritní omezení. Mazání dat z tabulky – příkaz DELETE Pro odstranění záznamů z tabulky se v jazyku SQL pouţívá příkaz DELETE.Syntaxe příkazu DELETE je následující.

36

DELETE FROM tabulka FROM tabulka WHERE podmínka

Dvě klauzule FROM v tomto případě nejsou překlepem. První klauzule FROM je nepovinná a smysl jejího uţití spočívá v případě, kdy je v povinné klauzuli FROM pouţita konstrukce JOIN. Pak první nepovinná klauzule FROM určuje tabulku, z které se budou záznamy odstraňovat. Klauzule WHERE má stejné pouţití a syntaxi jako u příkazu SELECT či UPDATE a určuje, které záznamy mají být odstraněny z tabulky. I pro příkaz DELETE platí definovaná integritní omezení.

1.3.1.3 Příkazy TCC Databázová transakce je skupina příkazů jazyka SQL, které převedou databázi za pomocí příkazů DML z jednoho konzistentního stavu do druhého. Databázová transakce má tyto vlastnosti souhrnně nazývané ACID: A – Atomicity C – Consistency I – Isolation D – Durability Atomicita. Databázová transakce je jako operace dále nedělitelná (atomární) ve vztahu k ostatním transakcím. Provede se buď jako celek, nebo se neprovede vůbec (a daný databázový systém to dá uţivateli na vědomí, např. chybovou hláškou). Tedy transakce A nastala buď před transakcí B, nebo po ní, ale nemohla probíhat současně. Přesněji, ve skutečnosti současně probíhala, ale synchronizace provedená databázovým serverem zajišťuje, ţe databáze bude vypadat, jako kdyby všechny transakce proběhly popořadě. Pokud to nebude moţné, provede zrušení některé transakce a zkusí ji provést znovu na novém stavu databáze. Atomicita transakce zároveň znamená, ţe pokud transakce selţe, selţe jako celek, tedy všechny zápisy, které provedla, budou při zrušení transakce vráceny.

37

Konzistence. Je vlastnost databázové transakce, díky které při a po provedení transakce není porušeno ţádné integritní omezení. Izolovanost. Operace uvnitř transakce jsou skryty před vnějšími operacemi. Vrácením transakce není zasaţena jiná transakce, jinak i tato musí být vrácena. V důsledku tohoto chování můţe dojít k tzv. řetězovému vrácení (cascading rollback). Trvalost. Změny, které se provedou jako výsledek úspěšných transakcí, jsou skutečně uloţeny v databázi a jiţ nemohou být ztraceny. Transakce se mohou lišit podle způsobu zpracování na pesimistické a optimistické. U pesimistického zpracování se v jeho průběhu změny zaznamenávají do dočasných objektů (například a nejčastěji: do řádků tabulek s příznakem dočasných dat, platných jen po dobu transakce) a teprve po přesunu/změně dat se odznačí příznak dočasnosti a data se stanou platnými. (Tento způsob se dá přibliţně připodobnit přepisu souboru, při kterém se nejdříve nová verze souboru nakopíruje pod dočasným jménem a teprve poté se tento soubor přejmenuje za starý a tím ho nahradí.) U optimistického zpracování se (optimisticky) předpokládá, ţe při transakci nenastane chyba a nebude třeba ji vrátit zpět (přestoţe tato moţnost je zachována). Měněné záznamy v tabulkách jsou při optimistickém zpracování transakce zapisovány „natvrdo“, současně s tím se však vytváří tzv. rollback log coby seznam SQL příkazů, které dokáţí prováděné změny vrátit zpět. V případě, ţe při transakci dojde k nějaké nezotavitelné chybě, tento log se provede a transakce (aby dodrţela pravidlo atomicity) skončí ve výchozím stavu s chybou. Naopak, na konci transakce, při které k ţádné takové chybě nedošlo, se rollback log maţe. Ţurnály jsou v tomto kontextu záznamy, které uchovávají informace o průběhu transakcí a slouţí k zotavení po vzniklé chybě. Ţurnály musí být v kaţdém uzlu a obsahují záznamy o historii kaţdé transakce. Transakce může nabývat těchto stavů: Aktivní - od počátku provádění transakce Částečně potvrzený - stav po provedení poslední operace transakce Chybný - nelze pokračovat v normálním průběhu transakce Zrušený - nastane po skončení operace

38

Potvrzený - po úspěšném vykonání [12] K řízení explicitních, uţivatelem definovaných, databázových transakcí je v jazyce SQL určena skupina TCC příkazů. Zde jejich výčet. Začátek transakce Pro začátek transakce je v jazyce SQL určen příkaz BEGIN TRANSACTION, kterým SŘBD sdělíme, ţe v tomto místě jsou data konzistentní a do zrušení či potvrzení transakce se nemají měnit. Za tímto příkazem následuje volitelný parametr jména transakce. Průběh transakce V průběhu transakce se provádí poţadované změny v tabulkách databáze. V některých případech, například při zpracování záznamů v cyklu je výhodné, vrátit se na určité místo po začátku transakce aniţ by bylo třeba celou transakci rušit. K vytvoření takového místa v transakci je určena funkce tzv. savepointů. Savepoint se v průběhu transakce deklaruje pomocí příkazu SAVE TRANSACTION následovaného pojmenováním takto označeného místa, kam je moţné se v průběhu transakce vrátit. Potvrzení probíhající transakce K ukončení transakce a jejímu persistentnímu zapsání na paměťové medium slouţí příkaz COMMIT TRANSACTION, který má volitelný parametr jména potvrzované transakce. Tento příkaz potvrzuje explicitní transakce volané uţivatelem i implicitní transakce spouštěné automaticky databázovým serverem. Zrušení probíhající transakce Pro zrušení explicitních i implicitních transakcí slouţí příkaz ROLLBACK TRANSACTION doplněný o volitelný parametr názvu savepointu či explicitní transakce. Není-li definován savepoint, tak se provede návrat do stavu před započetím vykonávání transakce. Většina databázových serveru umoţňuje řídit a nastavovat izolovanost transakcí. Izolovanost transakcí se úzce dotýká problematiky databázových zámků záznamu a je nad rámec této práce.

39

1.3.1.4 Příkazy DCL Přístup k datům v relačních databázích je řízen na základě identifikace uţivatele. Uţivatel, který tabulku vytvořil, má automaticky veškerá oprávnění pro práci s ní. Tato práva můţe rozšířit i na ostatní uţivatele pomocí příkazu GRANT. Syntaxe příkazu GRANT můţe být obecně zapsána takto: GRANT {ALL | <seznam oprávění>} ON <jméno objektu> TO {PUBLIC | <seznam uživatelů>}

V seznamu oprávnění příkazu GRANT mohou být specifikována následující oprávnění: SELECT, který povoluje čtení dat z tabulky INSERT, který povoluje vkládání dat do tabulky UPDATE, který povoluje modifikaci dat v tabulce DELETE, který povoluje mazání záznamů z tabulky EXECUTE, který povoluje spuštění uloţené procedury nebo skalární funkce Případně klíčové slovo ALL, které opravňuje ke všem úkonům vztahujících se k typu daného objektu. K odnětí přidělených se pouţívá příkaz REVOKE. Příkaz REVOKE má následující syntaxi. REVOKE {ALL | <seznam oprávění>} ON <jméno objektu> FROM {PUBLIC | <seznam uživatelů>}

V seznamu oprávnění mohou být uvedena stejná oprávnění jako pro příkaz GRANT. K vytvoření uţivatelských rolí je moţno pouţít příkazy CREATE ROLE. Uţivatelská role se zakládá pro skupinu uţivatelů se shodnými pravomocemi. Příkaz CRETAE ROLE má následující syntaxi: CREATE ROLE jméno role [AUTHORIZATION jméno předka oprávnění]

Vytvořené role a uţivatelé se odstraní z aktivní evidence příkazem DROP ROLE, respektive DROP USER s parametrem specifikujícím jméno rušeného záznamu. [10] 40

1.3.1.5 Možnosti jazyka SQL pro agregaci a analýzu dat Klauzule CUBE Pomocí rozšiřující klauzule CUBE získáme multidimenzionální přehled všech moţných kombinací podle vybraných dimenzí. Syntaxe pouţití je velmi jednoduchá: SELECT … GROUP BY CUBE (seznam seskupených sloupců)

Výsledkem takto formulovaného dotazu je sestava sumárních dat, kde jsou zahrnuty všechny kombinace dle seskupených sloupců. Všechny, tedy i ty, které nemají ţádnou hodnotu v průsečíku os dimenzí a hodnot. V případě pouţití této klauzule dostaneme výpis všech kombinací a sumárních hodnot. Pokud je poţadováno zobrazit pouze sumární informace bez všech vypsaných kombinací, je moţné je potlačit za pomoci klausule GROUPING a HAVING. Syntaxe pouţití klausule GROUPING je následující:

SELECT Jméno sloupce, Jméno sloupce2, GROUPING (jméno sloupce), GROUPING (jméno sloupce2), … FROM tabulka faktu, tabulka dimenzí WHERE … GROUP BY CUBE (jméno sloupce, jméno sloupce2, …)

Tímto zápisem získáme stejný výpis jako u předcházejícího dotazu s indikací, zda hodnota výpisu je agregována či nikoliv. Poté jiţ můţeme jednoduše pouţít klauzuli HAVING pro potlačení takových vět.

1.3.2 MDX Obdobou jazyka SQL pro relační databáze je MDX, jako dotazovací jazyky pro dotazování na data datových krychlí. MDX byl představen společností Microsoft společně s produktem Microsoft SQL Server OLAP Services, jako komponenta OLE DB pro OLAP API.[13] 41

V následující kapitole přiblíţím základní syntaxi jazyka MDX, následně potom jeho praktické pouţití demonstruji na příkladech v kapitole 3. OLAP krychle jsou skladišti multidimenzionálních dat. Pro pochopení dotazů jazyka MDX je třeba pochopit, jak jsou data v kostce uloţena. Data jsou v kostce uloţena ve formě dimenzí a faktů. Jednotlivé dimenze jsou většinou hierarchické s různou úrovní zanoření a s tímto zanořením souvisejícími agregovanými hodnotami, viz Obrázek 13 – Hierarchie časové dimenze.

Vše

2010

Q1

1

Q2

2

3

2011

Q3

Q4

4

12

Q1

1

Q2

2

3

Q3

4

Q4

12

Obrázek 13 – Hierarchie časové dimenze (vlastní tvorba)

Základní zápis pro dotaz na data je velmi podobný jazyku SQL. Funkce a pouţití jsou však významně odlišné. Syntaxe příkazu SELECT jazyka MDX vypadá následovně: SELECT <seznam definující hlavičky sloupců> ON COLUMNS, <seznam definující hlavičky řádků> ON ROWS FROM jméno datové krychle WHERE <specifikace výběrové podmínky>

42

V případě klausule SELECT seznam prvků znamená definici poţadované úrovně dimenze nebo dimenzí. Pokud pouţiji časovou dimenzi, kterou vyobrazuje Obrázek 13 – Hierarchie časové dimenze, zápis můţe vypadat takto: [ČAS].[ALL].[2011].[Q1].[2]

Čímţ říkám, ţe na poţadované ose chci hodnoty související s druhým měsícem roku 2011. Na jedné ose je moţno specifikovat více dimenzí a jejich úrovní. Zápisem těchto parametrů realizuje jazyk MDX základní operace na datové krychli, jako je výsek z kostky, zavrtávání, vyvrtávání či otáčení kostky. Zápis by pak vypadal například takto: { [ČAS].[2011].[Q3], [Zboží].[Potraviny].[Pečivo], [Místo].[Střední čechy].[Praha] }

Pojmenování dimenzí nebo jejich hierarchií je ţádoucí uzavírat do hranatých závorek, aby kompilátor dotazu rozpoznal, ţe se jedná o pojmenování objektů, nikoliv o klíčová slova jazyka MDX v případě, ţe by taková obsahoval, případně pojmenování můţe obsahovat znaky, jakou jsou mezery, čísla atd., které by mohla působit problémy. V případě syntaxe MDX vstupují do hry dva další pojmy, které mají dopad na pouţití závorek. N-tice – Kulaté závorky Kulaté závorky v MDX jsou pouţity pro označení tzv. n–tice. N–tice je kolekce členů, kaţdého z jiné dimenze, v jejichţ průsečíku se nachází uţivatelem poţadovaná data. N–tice mohou, a běţně tomu tak je, odkazovat na několik členů různých dimenzí zároveň. Příkladem zápisu n-tice můţe být: ( [Product].[Drink].[Beverages],[Customers].[USA],[Time],[1998] )

43

Sets – složené závorky Sloţené závorky jsou v MDX pouţity pro označení setů. Set je v MDX chápán, jako kolekce N-tice se stejnou dimensionalitou. Například: { [Product].[Product Family].[Food].[Baked Goods], [Product].[Product Family].[Food].[Baking Goods], [Product].[Product Family].[Food].[Breakfast Foods], [Product].[Product Family].[Food].[Canned Foods], }

Set můţe obsahovat jeden nebo více n-tic. Klíčovým slovem Members specifikujeme, ţe poţadujeme výstup za všechny členy definované úrovně dimenze. Např. ( [Product].[Drink].[Beverages].Members )

Stejným způsobem můţeme například pouţít i klíčová slova, Parent, Children, FirstChild, LastChild aj. V jazyce MDX jsou implementována i klíčová slova, která zajišťují relativní odkazování na buňky v osách kostky. Kaţdá buňka má v kostce určité souřadnice. V MDX existuje konstrukce, kterou můţeme definovat například následující dotaz: „Pracuj s daty z roku 2010, předešlého a následujícího roku“ aniţ bychom rok 2009 a 2011 museli přímo odkazovat v definici setu. K tomuto účelu slouţí klíčové slovo PrevMemeber a NextMember. Pro odkaz na buňky, které jsou v jiných osách neţ sousedních, můţeme pouţít funkci Lag(n) pro definici osy o n – členů zpět či vpřed. Jazyk MDX nabízí rozsáhlé moţnosti agregačních funkcí jako je Sum(), Count(), Avg(), Max(), Min(), aj. [11] Představme si, ţe v tabulce faktů máme více měr, jako například: prodáno kusů, cena atd. 44

V případě klausule WHERE říkáme jazykem MDX, „ukaţ mi ty data, kde je účastna míra cena“. Prázdné buňky, které jsou následkem řídkých matic, můţeme eliminovat klíčovým slovem NON EMPTY s následující syntaxí: SELECT NON EMPTY {[Produkt].[Třída].Members} ON COLUMNS, { [2011].[Q1], [2011].[Q2] } ON ROWS FROM [Prodeje]

Jazyk MDX nabízí velmi široké moţnosti dotazování a zpracování daty. Popis celé jeho syntaxe je nad rámec této práce a proto jsem se omezil pouze na základní stavební kameny příkazu SELECT, který budu dále potřebovat v kapitole 3.

1.4

ETL Procesy

ETL je zkratkou z třech anglických slov, které popisují proces pouţívaný ve světě databází, speciálně pak v oboru datových skladů. ETL je poměrně časově náročný a u některých implementací můţe zabrat aţ polovinu celkového času a úsilí. Hlavním účelem procesu ETL je centralizace údajů, tzn. jejich shromáţdění z mnoha z pravidla nehomogenních a různorodých zdrojů a databází OLTP a naplnění do skladu určenými údaji v poţadovaném čase. Extrakce Údaje, které chceme přenést do datového skladu jsou jednak umístěny v různých nehomogenních operačních prostředích, platformách či informačních systémech. Tyto data jsou rozdílně organizována nebo uloţena v rozličných formátech. Kromě interních údajů je někdy potřebné pracovat i s údaji externími, které můţou být dostupné na internetu případně z komerčních databází. Práce s externími údaji tak přináší nutnost zamyslet se ještě nad dostupností a monitorováním. Proces extrakce je tak velmi specifický konkrétní implementaci. 45

Obecně lze říci, ţe cílem extrakce dat je konvertovat data do jednotného formátu, který je zpracovatelný následujícím subprocesem, transformací. Transformace Transformace je proces, který aplikuje celou řadu pravidel a funkcí nad daty poskytnutými extrakcí, aby transformoval data do podoby vhodné pro nahrání do datového skladu. Tyto pravidla vedou ke zvýšení kvality údajů a k odstranění anomálií. Některá data nepotřebují ţádnou manipulaci a jsou připravena ihned. V jiných případech, mnohem častějších, musí být data transformována, aby splňovala technické nebo logické poţadavky. Nejčastější druhy transformací: Ošetření null hodnot Ošetření sirotků Překlady interních kódů různých systému (např. pohlaví, stav a jiná označení atd.) Tvorba nových vypočítávaných hodnot Agregace Řazení Tvorba unikátních klíčů Transpozice nebo kontingence Řetězení Věcná validace dat, například zápis titulů u jmen formátu PSČ, datumových polí atd. Doménová validace dat, například délka řetězců, intervaly dat, maximální a minimální hodnoty numerických polí atd. Změnu kódování Přenos Završením procesu ETL je přenesení extrahovaných a transformovaných dat do datového skladu. Tento proces by měl být plánovaný a automatizovaný, protoţe ve většině případů jde o obrovské mnoţství údajů. Po prvotním zavedení se však objem přenášených dat zmenší a přenáší se jen časové snímky. Přenos dat je spojen například s indexování záznamů, či přepočítáváním multidimenzionálních objektů a tak by měl být pečlivě naplánován s ohledem na vytíţení výpočetního výkonu.[5]

46

2 Seznámení s OLAP produkty na trhu V současné době je na trhu dostupných několik produktů, které zastřešují problematiku OLAP serverů. Portfolio těchto produktů se rozkládá od open-source řešení koncipovaných jako nástavba nad jiţ hotovým SŘBD, přes různé architektury a platformy, aţ po velmi nákladná a komplexní řešení předních softwarových developerů, jako jsou firmy Oracle, IBM či Microsoft. V následujících tabulkách uvedu stručnou charakteristiku některých dostupných OLAP serverů. Tabulka č. 5, OLAP řešení na trhu OLAP Server Essbase icCube Microsoft Analysis Services MicroStrategy Inteligence Server Mondrian OLAP server Oracle Database OLAP Option Palo SAS OLAP Server SAP NetWeaver BW TM1

Výrobce Oracle MISConsulting SA Microsoft MicroStrategy

Poslední verze 11.1.2.0 1.0 2008 R2 9

Licence Chráněno Chráněno Chráněno Chráněno

Náklady –

Pentaho Oracle Jedox SAS Institute SAP IBM

3.2 11g R2 3.2 SR3 9.2 7.20 9.5

EPL Chráněno GPL/EULA Chráněno Chráněno Chráněno

Zdarma – – – – –

Zdarma – –

V následující tabulce jsou tyto produkty charakterizovány z hlediska moţného způsobu uloţení dat. Tabulka č. 6, podporované modely uložení dat OLAP Server Essbase icCube Microsoft Analysis Services MicroStrategy Inteligence Server Mondrian OLAP server Oracle Database OLAP Option Palo SAS OLAP Server SAP NetWeaver BW TM1

47

MOLAP Ano Ano Ano Ano –

ROLAP Ano –

HOLAP Ano –

Ano Ano Ano

Ano Ano –

Ano Ano Ano Ano Ano

Ano –

Ano –

Ano –

Ano – –

Ano

Následující tabulka charakterizuje dostupné řešení z pohledu podporovaných platforem. Tabulka č. 7, podporované platformy OLAP Server Essbase icCube Microsoft Analysis Services MicroStrategy Inteligence Server Mondrian OLAP server Oracle Database OLAP Option Palo SAS OLAP Server SAP NetWeaver BW TM1

Windows Ano Ano Ano Ano Ano Ano Ano Ano Ano Ano

Linux Ano Ano –

UNIX Ano Ano –

Ano Ano Ano Ano Ano Ano Ano

Ano Ano Ano Ano Ano Ano Ano

OS – Ano – – Ano Ano – Ano Ano –

Následující tabulka charakterizuje dostupná řešení z pohledu podporovaných dotazovacích jazyků Tabulka č. 8, podporované dotazovací jazyky OLAP Server Essbase icCube Microsoft Analysis Services MicroStrategy Inteligence Server Mondrian OLAP server Oracle Database OLAP Option Palo SAS OLAP Server SAP NetWeaver BW TM1

XML for Analysis Ano Ano Ano Ano Ano – Ano Ano Ano Ano

OLE DB for OLAP Ano Ano Ano – Ano Ano Ano Ano Ano Ano

MDX Ano Ano Ano

SQL – – –

Ano Ano Ano Ano Ano Ano Ano

Ano – Ano – – – –

[1] Tato diplomová práce se bude nadále zabývat pouze popisem a implementací dvou popsaných produktů. A to OLAP serverem Mondrian společnosti Pentaho a produktem společnosti Oracle.

2.1

Oracle OLAP

Oracle OLAP je volitelnou součástí databáze Oracle 11g Enterprise Edition, která nabízí zakomponování OLAP nástrojů, dříve dostupných pouze díky samotným OLAP řešením přímo do relační databáze Oracle. Díky této integraci mohou být veškerá data (i metadata) spravována přímo z databázového prostředí, coţ s sebou přináší výbornou škálovatelnost celého systému a dostupnost

48

a zabezpečení dat. Díky Oracle OLAP je moţné snadno definovat multidimenzionální modely zahrnující sloţité analytické výpočty, vyuţívat jednoduchý a rychlý přístup k bohatým analýzám pomocí SQL dotazů a snadno a efektivně zlepšit výkon agregačních dotazů za pomocí materializovaných pohledů zaloţených na datových kostkách. Oracle, podobně jako Microsoft, je silným hráčem na poli databázových technologií. A stejně tak si za svá kvalitní řešení nechává náleţitě zaplatit. Na druhou stranu se databáze Oracle neomezuje na pouze jeden operační systém, ale je multiplatformní. [14] Oracle OLAP je plně integrován v databázi Oracle, což na technické úrovni znamená: OLAP engine běţí v jádru SŘBD Oracle Dimenzionální objekty jsou uloţeny v databázi Oracle v jejich přirozeném nativním formátu Datové krychle a další multidimenzionální objekty jsou první třídy dataobjektů uloţené v datovém slovníku databáze Bezpečnost dat je spravována standardním způsobem, pomocí příkazu GRANT a REVOKE v oboru databázových uţivatelů a rolí. Aplikace mohou dotazovat multidimenzionální objekty prostřednictvím dotazů SQL Uţivatelsky velmi příjemnou moţností je, dotazovat se na datové kostky uloţené v databázi prostřednictvím aplikace Microsoft Excel. MS Excel dotazuje přímo prostřednictvím MDX, čímţ zpřístupňuje uţivatelům data v kostkách, jako jsou například sumarizovaná data či vypočítávané hodnoty interaktivně. Uţivatelé si mohou definovat jejich vlastní dotazy a plně vyuţívat všech základních operací s datovými kostkami. Excelovské rozhraní s jeho formátováním a širokou vizualizační škálou, můţe být pouţito ve spojení s daty z datových kostek v Oracle OLAP. Toto spojení pak nabízí reprezentaci a zpracování dat v dalších modulech MS Office, jako je PowerPoint nebo Word, ţivě přímo z multidimezionální databáze. [9] Internetové stránky výrobce obsahují velké mnoţství specificky zaměřených dokumentů právě k problematice OLAP serveru. Ke zhlédnutí jsou i videa obsahující prezentace

49

zmiňovaného balíčku, instruktáţní videa, jak datovou kostku v tomto prostředí implementovat a jak se na data dotazovat.

2.2

Pentaho Mondrian

Mondrian od společnosti Pentaho je OLAP serverový nástroj postavený na platformě Java. Jako dotazovací jazyk v Mondrian slouţí jazyk MDX, který čte data z relační databáze a prezentuje výsledek v multidimenzionálním formátu prostřednictvím aplikačního interface pouţité platformy. [4] Jeho hlavním účelem je tedy umoţnit uţivatelům analyzovat data uloţená v SQL databázi (jedná se o ROLAP řešení) aniţ by museli psát sloţité SQL dotazy. Mondrian umoţňuje definovat logické schéma datového skladu nad relační databází pomocí jednoduchého XML souboru. Dotazy nad logickým schématem se pak mohou zadávat pomocí jazyka MDX, nebo pomocí jazyka XMLA, které jsou Mondrianem překládány na klasické SQL dotazy. Výsledky těchto dotazů jsou nakonec opět převedeny do multidimenzionální podoby a vráceny jako odpověď na dotazy původní. Jedná se o komunitní open-source projekt, který můţe být dále doplněn o příbuzné produkty Pentaho Reporting. [14] Architektura serveru Pentaho Mondrian je rozdělena do čtyř vrstev, logicky rozdělených od části poskytující výstupy uţivateli aţ po nejinternější datové centrum. 4 Vrstvy Mondrian jsou: Prezentační vrstva (Presentation layer) Dimenzionální vrstva (Dimenzional layer) Hvězdicová vrstva (Star layer) Datová vrstva (Storage layer) Prezentační vrstva určuje, co uţivatel uvidí na svém monitoru a vytváří pro něj komunikační rozhraní pro práci se systémem a zadávání nových dotazů. Existuje mnoho způsobů jak prezentovat výsledky multidimenzionálních dotazů, jako například pomocí pivot tabulek, různých grafů a komplexnějších vizualizačních nástrojů jako jsou např. clikací mapy či dynamická grafika. Tyto výstupy mohou být naprogramovány v prostředí Swing nebo JSP, grafy mohou být renderovány ve formátu JPEG nebo GIF, případně mohou být přeneseny do 50

ostatních aplikací prostřednictvím XML. Ve víceuţivatelském řešení by tato vrstva měla existovat na kaţdé klientské stanici s výjimkou zobrazení pomocí JSP stránek, generovaných samotným serverem. Dimenzionální vrstva parsuje, validuje a provádí MDX dotazy. Samotný dotaz je vyhodnocován v několika fázích. První jsou zpracovávány osy dotazu, následně pak jednotlivé buňky v těchto osách. Pro větší efektivitu dimenzionální vrstva posílá poţadavky na zpracování hodnot buněk do agregační podvrstvy v dávkách. Transformační proces umoţňuje aplikacím pracovat a modifikovat jiţ provedené dotazy, které preferuje před vykonáváním zcela nových MDX dotazů pro kaţdý nový uţivatelský poţadavek. Metadata popisují dimenzionální model a jeho namapování na model relační. Hvězdicová vrstva je zodpovědná za správu agregační cache. Agregační cache je sada agregovaných hodnot kvalifikovaných dle definovaných dimenzí uloţených v paměti. Dimenzionální vrstva posílá poţadavky této vrstvě o sadu agregovaných hodnot. Pokud nejsou tyto agregované hodnoty v agregační cache nebo nejsou odvoditelné z agregací v cache, agragační manager posílá poţadavek do datové vrstvy. Strategie pouţití cache v systému Mondrian je následující. Faktová data jsou uloţena v SŘBD. Autoři Mondrianu jsou si vědomi absence důvodu vyvíjet novou datovou platformu, kdyţ potřebný SŘBD je dostupný. Datovou vrstvu představuje SŘBD, která je zodpovědná poskytováním vstupních dat pro agregované hodnoty a členy pro dimenzionální tabulky. Tato vrstva můţe být instalována na jiném serveru přístupném prostřednictvím JDBC[4]. Blokové schéma architektury OLAP serveru Mondrian je součástí této diplomové práce, viz příloha č. 1. Více informací a potřebná dokumentace k instalaci, konfiguraci a ladění OLAP serveru, případně sekce FAQ či dokumentace pro vývojáře jsou dostupné na internetových stránkách výrobce.

51

3 Vlastní návrh a implementace DS V následující kapitole popíši, jaké datové struktury, reprezentující databázový transakční systém, jsem se rozhodl pouţít jako vstupní bod pro tvorbu datového skladu. Dále popíši proces převodu struktury vhodné pro relační databáze a transakční zpracování do struktur vhodných pro uloţení dat ve strukturách, vhodných pro datové sklady a tvorbu datové krychle. V posledních kapitolách této části práce popíši instalaci SŘBD Oracle 11g, vytvoření zmiňovaných OLTP a OLAP struktur, vytvoření datové krychle, a instalaci OLAP serverů Oracle OLAP a Pentaho Mondrian, jich konfiguraci a spuštění nad daty obsaţenými v SŘBD.

3.1

PIM návrh architektury a řešení datového skladu

PIM návrh se zabývá tou částí specifikace systému, která se nemění podle konkrétního druhu zvolené platformy. PIM zprostředkovává určitou míru nezávislosti konkrétního řešení dané problémové oblasti tak, aby se hodila na různé platformy podobného typu. [8]

3.1.1 Datový model zdrojové relační databáze Pro případovou studii této diplomové práce jsem si vybral obecnou problematiku obchodování s cennými papíry. Navrhl jsem příslušný, zjednodušený, datový model popisující danou oblast a tento klasický relační model pouţiji jako předlohu pro návrh struktury datového skladu a procesu ETL. Datový model byl vytvořen v CASE nástroji Sybase PowerDesigner 12.0 a obsahuje 12 tabulek a 16 vazeb. Je v 3. normální formě a datová integrita je udrţována pomocí základních databázových deklarativních mechanizmů. Viz Obrázek 14 – Datový model relační databáze.

52

Obrázek 14 – Datový model relační databáze (vlastní tvorba)

Tabulka S01Stat je číselníkem států, jejich označení a měny v tomto státě pouţívané. Jsou v ní uloţená data ve struktuře: S01StatID – Sloupec je v tabulce primárním klíčem S01NazevStat – Sloupec nese označení státu, například „Čínská lidová republika“ S01NazevMena – Sloupec nese hodnotu názvu měny, například „Česká koruna“ S01StatKod – Sloupec nese hodnotu kódu označení státu, například „AU“ S01MenaKod – Sloupec nese hodnotu kódu označení měny, například „EMU“ Všechna pole v této tabulce jsou povinná.

53

Tabulka U01Ucastnik je evidencí osob participujících na obchodech a osob emitentů. Data jsou v ní uloţena v následující struktuře: U01UcastnikID – Sloupec je v tabulce primárním klíčem U02FormaID – Sloupec je v tabulce cizím klíčem z tabulky U02Froma S01StatID – Sloupec je v tabulce cizím klíčem S01Stat U01RC – Sloupec nese hodnotu rodného čísla nebo investičního čísla U01Jmeno – Sloupec nese hodnotu křestního jména osoby U01Prijmeni – Sloupec nese hodnotu příjmení osoby U01TitulPred – Sloupec nese hodnotu titulu před jménem osoby U01TitulZa – Sloupec nese hodnotu titulu za jménem U01Ulice – Sloupec nese hodnotu ulice adresy osoby U01CisloPopisne – Sloupec nese hodnotu čísla popisného adresy osoby U01Mesto – Sloupec nese hodnotu města adresy osoby U01PSC – Sloupec nese hodnotu poštovního směrovacího čísla adresy osoby U01DatumNarozeni – Sloupec nese hodnotu data narození účastníka Tabulka U02Froma je číselníkem druhu osoby a data jsou v ní uloţena v následující struktuře: U02FormaID – Sloupec je v tabulce primárním klíčem U02FormaKod – Sloupec nese hodnotu kódu označení formy osoby, například „U02_MUZ“ U02Forma – Sloupec nese hodnotu popisu formy osoby, například „Právnická osoba“ Tabulka U03Role je číselníkem rolí osoby a data jsou v ní uloţena v následující struktuře: U03RoleID – Sloupec je v tabulce primárním klíčem U03RoleKod

–

Sloupec

nese

hodnotu

kódu

označení

role

osoby,

například

„U03_EMITENT“ U03RoleNazev – Sloupec nese hodnotu popisu role osoby, například „Emitent“ Tabulka

U04UcastnikRole

je

vazební

tabulkou

mezi

tabulkami

U03Role

a U01Ucastnik a řeší zde vazbu typu M:N. Data jsou v ní uloţena v následující struktuře: U04UcastnikRoleID – Sloupec je v tabulce primárním klíčem U01UcastnikID – Sloupec primárního klíče z tabulky U01Ucastnik

54

U03RoleID – Sloupec primárního klíče z tabulky U03Role Tabulka E01Emise je evidencí cenných papírů. Data jsou v ní uloţena v následující struktuře: E01EmiseID – Sloupec je v tabulce primárním klíčem S01StatID – Sloupec je v tabulce cizím klíčem S01Stat E02EmiseDruhID – Sloupec je v tabulce cizím klíčem E02EmiseDruh E01ISIN

–

Sloupec

nese

hodnotu

ISINU

daného

cenného

papíru,

například

„NL0006033376“ E01Nazev – Sloupec nese hodnotu názvu daného cenného papíru E01Nominal – Sloupec nese hodnotu nominální hodnoty E01DatumEmise – Sloupec nese hodnotu data emise daného CP E01Objem – Sloupec nese hodnotu objemu CP dané emise Tabulka E02EmiseDruh je číselníkem druhu emise. Jsou v ní uloţená data ve struktuře: E02EmiseDruhID – Sloupec je v tabulce primárním klíčem E02DruhKod – Sloupec nese hodnotu kódu označení emise, například „E02_DERIVAT“ E02DruhNazev – Sloupec nese hodnotu označení stavu, například „Státní dluhopis“ Všechna pole v této tabulce jsou povinná. Tabulka O01Obchod je evidencí zaloţených obchodů. Data jsou v ní uloţena v následující struktuře: O01ObchodID – Sloupec je v tabulce primárním klíčem E01EmiseID – Sloupec je v tabulce cizím klíčem E01Emise P01ObchodSmerID – Sloupec je v tabulce cizím klíčem P01ObchodSmer U01UcastnikID – Sloupec je v tabulce cizím klíčem U01Ucastnik T01TrhID – Sloupec je v tabulce cizím klíčem T01Trh P02StavID – Sloupec je v tabulce cizím klíčem P02Stav U01ProtistranaID – Sloupec je v tabulce cizím klíčem U01Ucastnik O01PocetCP – Sloupec nese hodnotu počtu kusů CP daného obchodu O01ObchodObjem – Sloupec nese hodnotu obchodního objemu daného obchodu O01CenaKus – Sloupec nese hodnotu cenu za kus CP daného obchodu

55

O01ObchodDatum – Sloupec nese hodnotu obchodního data daného obchodu O01DatumVyporadani – Sloupec nese hodnotu data vypořádání obchodu O01VlozeniDatum – Sloupec nese hodnotu vloţení obchodu do systému O01VlozeniDatumInt – Sloupec nese hodnotu interní hodnotu vloţení (defaultně funkce GetDate()) Tabulka O02Vyporadani je evidencí vypořádání k obchodům z tabulky O01Obchod. Data jsou v ní uloţena v následující struktuře: O02VyporadaniID – Sloupec je v tabulce primárním klíčem P02StavID – Sloupec je v tabulce cizím klíčem P02Stav O01ObchodID – Sloupec je v tabulce cizím klíčem O01Obchod O02VyporadaniDatum – Sloupec nese hodnotu data skutečného vypořádání obchodu Tabulka P01ObchodSmer je číselníkem směru obchodu. Jsou v ní uloţená data ve struktuře: P01ObchodSmerID – Sloupec je v tabulce primárním klíčem P01KodExt – Sloupec nese hodnotu kódu označení směru externím systémem, například „N“ P01SmerKod – Sloupec nese hodnotu kódu označení směru, například „P01_NAKUP“ P01Smer – Sloupec nese hodnotu označení směru, například „Nákup“ Všechna pole v této tabulce jsou povinná. Tabulka P02Stav je číselníkem stavu obchodu. Jsou v ní uloţená data ve struktuře: P02StavID – Sloupec je v tabulce primárním klíčem S01StatID – Sloupec je v tabulce cizím klíčem S01Stat P02StavKod

–

Sloupec

nese

hodnotu

kódu

označení

stavu,

například

„P02_VYPORADANO“ P02StavPopis – Sloupec nese hodnotu označení stavu, například „Suspendováno“ Všechna pole v této tabulce jsou povinná. Tabulka T01Trh je číselníkem trhů. Jsou v ní uloţená data ve struktuře: T01TrhID – Sloupec je v tabulce primárním klíčem T01TrhKod – Sloupec nese hodnotu kódu označení stavu, například „T01_BCPP“ 56

T01TrhNazev – Sloupec nese hodnotu označení trhu, například „Burza cenných papíru Praha“ T01MIC – Sloupec nese hodnotu označení trhu označením MIC

3.1.2 Převod relačního schématu na schéma hvězdy Při obecném návrhu datového skladu je nutné ze stávajícího relačního modelu vybrat s ohledem na budoucí pouţití hodnoty pro tabulku faktů a jejich měr a také jednotlivé dimenze. S ohledem na hodnoty ve výše uvedeném relačním modelu a jejich význam pro analytické účely jsem se rozhodl implementovat tyto následující dimenze: Dimenzi časovou pro obchodní den a den vypořádání obchodu Dimenzi participující osoby protistrany a účastníka Dimenzi emise obchodu, s kterou byl obchod uskutečněn Dimenzi trhu, na kterém byl obchod uskutečněn Dimenzi směru obchodu Dimenzi stavu obchodu Datový sklad bude dále obsahovat jednu tabulku faktů, obsahující hodnoty obchodního objemu, počtu CP a jednotkové ceny.

57

Obrázek 15 – Multidimenzionální kostka a dimenze (vlastní tvorba)

Pro řešení datového skladu jsem se rozhodl pouţít model hvězdy. Schéma datového skladu bude obsahovat 6 tabulek dimenzí, tabulky s prefixem DW_D01 – DW_D06 a jednu tabulku faktů s prefixem DW_F01 . Tabulky dimenzí a tabulka faktů jsou spojeny vazbami.

58

Obrázek 16 – Model hvězda datového skladu (vlastní tvorba)

3.2

PSM návrh architektury a řešení datového skladu Oracle

PSM návrh je závislý na cílové platformě, kombinuje PIM s konkrétními technologickými řešeními.

3.2.1 Vlastní instalace SŘBD Oracle 11g Instalační balíček produktu je umístěn na stránkách výrobce v sekci download. Pro instalaci SŘBD Oracle jsem se rozhodl pouţít notebook Lenovo T410, vybavený procesorem Intel Core™ i5 2.4GHz s operační pamětí 3GB. Instalovaný operační systém je Windows 7 Professional. Budu instalovat Oracle na 32 – bitovou verzi operačního systému firmy Microsoft, pro kterou jsem zvolil verzi 11g Release 2 (11.2.0.1). 59

Po staţení obou částí instalace, která je rozdělena na dva instalační archivy, je třeba soubory dekomprimovat do stejné sloţky umístěné na pevném disku počítače. Po dekomprimaci máme k dispozici kompletní instalační balíček, který jsem spustil souborem setup.exe. Při instalaci produktu Oracle 11g jsem postupoval podle návodu uvedeného v zdroji [6] a podle cíle této diplomové práce. Po spuštění souboru setup.exe se objeví přehledný průvodce instalací, který se dotazuje především na následující body, které jsem nastavil tak, jak je uvádí Tabulka č. 9, instalační parametry. Tabulka č. 9, instalační parametry Parametr Způsob instalace SŘBD Třída SŘBD Cesty pro fyzické umístění souboru DBS a aplikačního jádra Druh instalace Defaultní znaková sada SID databáze Heslo administrátorského účtu

Dostupné volby Nová SŘBD, update stávající,… Desktop, Server – Enterprise Edition, Standard Editin, … WIN 1250, Unicode – –

Zvoleno Nová SŘBD Desktop Ponechání výchozí Enterpise Edition WIN1250 orcl –

Po dokončení prvotní instalace následuje okno „Password management“, kde je moţno zaloţit či aktivovat uţivatelské účty k přístupu do databáze a nastavení patřičných hesel. Instalace dále pokračuje bez dalších nutných zásahů aţ do bodu jejího ukončení, kdy je SŘBD po úspěšném instalačním procesu připraven k pouţití. Webové rozhraní nainstalovaného produktu je v případě popisované instalace dostupné z umístění http://localhost:1158/em, kde jsou k dispozici přehledně uspořádané a logicky rozčleněné ovládací, konfigurační a monitorovací prvky. Pro případovou studii této práce jsem se rozhodl nechat nastavení ve výchozím stavu. Dalším krokem bylo tedy vytvořit patřičné datové struktury datového skladu a naplnit je daty vhodnými pro analýzu a prezentaci funkčnosti návrhu. Pro veškerou další práci s daty a datovými strukturami jsem pouţil volně dostupnou aplikaci Oracle SQL Developer verze 3.0.04, která je k dispozici na webu výrobce. Pro její zprovoznění a pouţívání stačí pouze vytvořit patřičnou konexi na v předešlém bodě 60

zmiňovaný SŘBD. Vytvoření konexe popisuje Obrázek 17 – Vytvoření konexe na SŘBD v SQL Developer.

Obrázek 17 – Vytvoření konexe na SŘBD v SQL Developer (vlastní tvorba)

3.2.2 Vytvoření datových struktur Pro vytvoření datových struktur jsem pouţil DDL skript vygenerovaný aplikací Sybase PowerDesigner 12, v které jsem tyto datové struktury modeloval. Skript je k nahlédnutí viz příloha č. 2. V datovém modelu jsem zcela úmyslně nepouţil sloupce typu identity pro primární klíče kaţdé tabulky, protoţe data, která jsem se rozhodl do datového skladu vloţit, pocházejí z informačního systému, kde tyto primární klíče jsou sloupci typu identity a jejich unikátnost je tak zaručena jiţ na straně zdroje. Narušení unikátnosti primárního klíče vstupem dalších instancí jiných primárních klíčů z třetích systémů je v tomto případě vyloučena. Datová integrita je řešena pomocí deklarativních omezení. Referenční integrita pomocí vazeb primárních a cizích klíčů mezi tabulkou faktů a tabulkami dimenzí. Doménová integrita je jiţ z velké části řešena na straně zdrojového informačního systému, na straně datového skladu jsem se tedy omezil jen na ošetření parciality.

61

3.2.3 Naplnění datových struktur daty Z důvodu naplnění datového skladu smysluplnými záznamy, které mají schopnost reálně popisovat danou situaci, z důvodu poţadavku na data integritní a konzistentní, a na dostatečný počet záznamů, jsem se rozhodl jako zdrojová data pro tuto případovou studii data extrahovat z nejmenovaného

transakčního

informačního

systému

pokrývajícího

problematiku

obchodování s cennými papíry. Protoţe se jedná o data z testovacího prostředí, které svůj původ mají v prostředí produkčním, provedl jsem nad těmito daty anonymizaci v takovém rozsahu, aby jejich schopnost identifikovat účastníky obchodů či titul cenného papíru, byla nulová. Po tomto zásahu mohu stále na jejich základě analyzovat pomocí OLAP serverů závislosti a trendy. Protoţe datová základna zmiňovaného informačního systému je implementována na platformě databázového serveru Microsoft SQL Server 2008 a tento server je v demilitarizované intranetové zóně, rozhodl jsem se přenést data mezi zdrojovou a cílovou databází jednorázově, pomocí do CSV souborů exportovaných dat. V případě skutečného automatizovaného procesu ETL by muselo být mezi servery zprovozněno spojení tak, aby proces mohl data dle nastaveného aktualizačního plánu ze zdrojového serveru číst a tyto data po vhodné transformaci do cílového serveru vkládat. Balíček Microsoft SQL Server 2008 i balíček Oracle 11g těmito nástroji disponují. Samotné naplnění tedy spočívalo v extrakci a transformaci časového snímku dat za období roků 2008 aţ 2010 včetně, ze zdrojové databáze, která je umístěna na databázovém serveru MS SQL 2008 a slouţí jako základna pro prostředí transakčního informačního systému. Příprava dat tedy probíhala v prostředí MS SQL serveru a zmiňované dotazy a skripty pouţité pro extrakci, anonymizaci a transformaci dat jsou syntaxí jazyka T-SQL, coţ je procedurální nadstavba standardu SQL implementované společností Microsoft v jejich SŘBD. Nejprve je nutné naplnit tabulku DW_D01Date, která obsahuje data pro dimenzi hodnot obchodního dne a data vypořádání. Časová dimenze má z pohledu datového skladu jistá specifika, mnoţinu obsahující datum není moţné brát přímo z tabulek např. faktů, protoţe jednoduše nemusí obsahovat všechna data v kalendářním roce. Toto je řešeno jednoduchým skriptem v jazyce Transact SQL, který naplní tabulku dimenze času postupně všemi

62

jednotlivými daty v určeném intervalu. V tomto případě tedy všemi dny od začátku roku 2008 do konce roku 2011. Skript pro naplnění tabulky DW_D01Date: Declare @dt_datum datetime Set @dt_datum = '20080101' While @dt_datum < '20110101' Begin Insert Into DW_D01Date ( D01Date, D01Day, D01Month, D01Year, D01Quarter ) Select @dt_datum, DatePart(dd,@dt_datum), DatePart(mm,@dt_datum), DatePart(yyyy,@dt_datum), DatePart(qq,@dt_datum) Set @dt_datum = dateadd(DAY, 1,@dt_datum ) End

Tímto skriptem se tabulka naplní 1096 záznamy, obsahujícími primární klíč záznamu data, který bude pouţit jako cizí klíč pro datumové poloţky tabulky faktů. Dalším postupem bylo naplnit tabulku dimenzí účastníků a protistran obchodů, tabulku DW_D02Ucastnik. Ve zdrojové databázi je tato evidence řešena jednou tabulkou obsahující všechny účastníky, bez rozdělení na protistranu či účastníka obchodu. Tímto způsobem bude řešena i dimenze účastníka a protistrany v této případové studii. V případě většího zatíţení datového skladu by bylo vhodnější tuto tabulku rozdělit na dvě separátní, aby byla zátěţ rozloţena. Tabulku dimenzí DW_D02Ucastnik, obsahující členy obchodů jsem naplnil výsledkovou sadou tohoto SQL dotazu: Select u01.U01UcastnikID As D02UcastnikID,

63

u02.U02FormaID As U02FromaID, u02.U02Forma As U02Froma, s01.S01StatID As S01StatID, s01.S01NazevStat As S01NazevStat, u01. U01UcastnikID as U01RCIC, 'Jméno_' + ltrim(rtrim(str(U01UcastnikID))) As U01Jmeno, 'Příjmení_' + rtrim(ltrim(str(U01UcastnikID))) As U01Prijmeni, U01DatumNarozeni As U01DatumNarozeni From U01Ucastnik as u01 Inner Join U02Forma As u02 On u01.U02Forma = u02.U02Forma Inner Join S01Stat As s01 On s01.S01StatID = u01.S01StatID Where Exists(Select 1 From O01Obchod As o01 Where o01.U01UcastnikID = u01.U01UcastnikID And O01VlozeniCasInt > '20080101' And O01VlozeniCasInt < '20110101') Or Exists(Select 1 From O01Obchod As o01 Where o01.U01ProtistranaID = u01.U01UcastnikID And O01VlozeniCasInt > '20080101' And O01VlozeniCasInt < '20110101')

Jak je ze skriptu patrno, pole U01Jmeno, U01Prijmeni, U01RCIC byly anonymizovány. Pro naplnění tabulky DW_D03Emise, která bude obsahovat denormalizované hodnoty relevantních cenných papírů, jsem pouţil výsledkovou sadu následujícího dotazu: Select e01.E01EmiseID As D03EmiseID, e01.S01StatID As S01StatID, s01.S01NazevStat As S01NazevStat, s01.StatNazevMena As S01NazevMena, e01.E02EmiseDruhID As E02EmiseDruhID, e02.E02DruhNazev As E02DruhNazev, e01.U01EmitentID As U01EmitentID, 'Jmeno_' + rtrim(ltrim(str(e01.U01EmitentID))) as U01Jmeno, 'Příjmení_' + rtrim(ltrim(str(e01.U01EmitentID))) as U01Prijmeni, ltrim(rtrim(STR( E01EmiseID))) As E01ISIN, 'Emise_' + ltrim(RTRIM(str(E01EmiseID))) E01Nazev From E01Emise e01 Inner Join S01Stat As s01 On s01.S01StatID = e01.S01StatID Inner Join E02EmiseDruh As e02 On e01.E02EmiseDruhID = e02.E02EmiseDruhID Inner Join U01UcasnikID As u01 On e01.U01EmitentID = u01.U01UcastnikID Where Exists(Select 1 From O01Obchod As o01 Where e01.E01EmiseID = o01.E01EmiseID and O01VlozeniCasInt > '20080101' And O01VlozeniCasInt < '20110101')

Anonymizovány byly pole U01Jmeno, U01Prijmeni , E01ISIN, E01Nazev. Tabulku DW_D04Trh, která bude obsahovat potřebné hodnoty pro vytvoření dimenze trhu, na kterém je obchod uzavřen, jsem naplnil výsledkovou sadou tohoto SQL dotazu:

64

Select T01TrhID As D04TrhID, T01TrhID As T01TrhKod, 'Trh_' + ltrim(rtrim(str(T01TrhID))) As T01TrhNazev, left(T01Kod,4) + ltrim(rtrim(str(T01TrhID))) As T01MIC, t01.S01StatID As S01StatID, s01.S01NazevStat As S01NazevStat, s01.StatNazevMena As S01NazevMena, From T01Trh t01 Inner Join S01Stat As s01 On s01.S01StatID = t01.S01StatID Where Exists(Select 1 From O01Obchod o01 Where t01.T01TrhID = o01.T01TrhID and O0VlozeniDatumInt > '20080101' And O0VlozeniDatumInt < '20110101')

V této výsledkové sadě jsou anonymizovány sloupce T01TrhNazev, T01TrhKod a T01MIC. Pro naplnění tabulky DW_D05ObchodSmer, která obsahuje hodnoty pro dimenzi obchodního směru, jsem pouţil následující statické inserty: Insert into "DW_D05ObchodSmer" ("D05ObchodSmerID","P01Smer") Values (0,'Nákup'); Insert into "DW_D05ObchodSmer" ("D05ObchodSmerID","P01Smer") Values (1,'Prodej');

Poslední dimenzní tabulku DW_D06Stav jsem naplnil výsledkovou sadou tohoto SQL dotazu: Select P02StavID As D06StavID, P02StavPopis as P02StavPopis From P02Stav As p02 Exists(Select 1 From O01Obchod o01 Where p02.P02StavID = o01.P02StavID and O0VlozeniDatumInt > '20080101' And O0VlozeniDatumInt < '20110101')

Nyní jsou všechny tabulky dimenzí naplněny a je moţné přistoupit k naplnění tabulky faktů DW_D01Obchody. Tato tabulka byla naplněna daty z výsledkové sady tohoto dotazu, který je snímkem dat za určité časové období: Select o01.O01ObchodID As F01ZaznamID, d01_ObchodDatum.D01TimeID As D01ObchodDatumID,

65

o01.U01ProtistranaID as D02ProstistranaID, o01.U01UcastnikID as D02UcastnikID, o01.E01EmiseID As D03EmiseID, o01.T01TrhID As D04TrhID, Coalesce(d01_o02vypor.D01TimeID,d01_01Vypor.D01TimeID) As O01DatumVyporadani, d01_VlozeniInt.D01TimeID As O01VlozeniDatumInt, p01.P01ObchodSmerID As P01ObchodSmerID , Coalesce(o02.P02StavID,o01.P02StavID) As D06Stav, O01ObchodObjem As O01ObchodObjem, O01PocetCP As O01PocetCP, O01CenaKus As O01CenaKus From O01Obchod As o01 Inner Join DW_D01Date as d01_ObchodDatum On O01ObchodDatum = d01_ObchodDatum.D01Date Inner Join DW_D01Date as d01_VlozeniInt On DateDiff(day,O01VlozeniDatumInt,d01_VlozeniInt.D01Date) = 0 Inner Join DW_D01Date as d01_01Vypor On O01DatumVyporadani = d01_01Vypor.D01Date left Join O02Vyporadani As o02 On o01.O01ObchodID = o02.O01ObchodID left Join DW_D01Date as d01_o02vypor On o02.O02VyporadaniDatum = d01_12vypor.D01Date Where O01VlozeniDatumInt > '20080101' And O01VlozeniDatumInt < '20110101'

Pro vkládání záznamu jsem pouţíval aplikaci Oracle SQL Developer a její funkci „Import Data…“ v kontextovém menu nad objektem konkrétní tabulky. Po zvolení této volby se objeví série dialogů, které přehledně provází importním procesem dat. Nejprve je nutné zadat jméno importovaného souboru. Následuje dialog, kde je nutné nastavit parametry importu. V tomto případě hodnoty oddělené znakem „;“, bez hlavičky, s textovými hodnotami bez kvantifikátoru. V druhém kroku se volí způsob importu, vybral jsem tedy vytvoření insertovacího skriptu, kvůli snazšímu případnému opakovanému importu. Ve třetí obrazovce se definují formáty dat, jako jsou datumové poloţky atd. Na čtvrté obrazovce průvodce pak dojde k validaci zadaných parametrů a samotného procesu parsování importovaného souboru. Po kliknutí na tlačítko „Dokončit“ aplikace vytvoří skript obsahující příkazy Insert jazyka SQL, které je moţno nad databázi spustit. Viz Obrázek 18 – Průvodce importem dat. Po spuštění vytvořených importovacích skriptů je datový sklad naplněn a je moţno přistoupit k dalším bodům, vedoucím k cíly. Počet insertovaných záznamů přehledně shrnuje

66

Tabulka č. 10.

Tabulka č. 10, počet záznamů v tabulkách DW Tabulka DW_D01Date DW_D02Ucastnik DW_D03Emise DW_D04Trh DW_D05ObchodSmer

Počet insertovaných vět 1 096 194 768 1 525 42 2 19 605 492

DW_D06Stav DW_F01Obchody

67

Obrázek 18 – Průvodce importem dat (vlastní tvorba)

V tomto bodě jsou struktury datového skladu naplněny a připraveny k dalšímu kroku, podstoupení OLAP serveru.

3.2.4 Vytvoření datové krychle, dimenzí a hierarchií Na platformě Oracle 11g s doplňkem OLAP option jsem pro vytvoření datové krychle a jejích dimenzí pouţil vývojový nástroj dodávaný společností Oracle, Oracle Analytic Workspace Manager ve verzi 11.2.2.0A. Oracle Analytics Workspace je volně přístupný a ke staţení na oficiálních internetových stránkách firmy Oracle. Po staţení a dekomprimaci instalačního balíčku je aplikace připravena k pouţití. Stačí pouze vytvořit patřičnou konexi za pomocí jednoduchého průvodce.

68

Po zadání autentifikačních údajů se objeví stromová struktura s příslušnými schématy pro přihlášeného uţivatele. V tomto stromě pomocí kontextovému menu a volby „Create Analytic Workspace“ jsem nový workspace vytvořil. Workspace je v tomto případě chápan jako kontejner obsahující všechny multidimenzionální objekty a jejich data.

Obrázek 19 – Nový projekt v AWM Oracle (vlastní tvorba)

Základními stavebními kameny pro vytvoření OLAP v prostředí AWM jsou dimenze a k nim patřící definice úrovní a hierarchií, které začleňují definované úrovně. Tyto volby se nabídnou po vytvoření workspace. K dispozici je i velké mnoţství reportů, obsahujících různé statistické informace, logy atd. Je k dispozici i prostředí pro nastavení bezpečnosti dat z hlediska uţivatelských přístupů. Díky tomu je Analytic Workspace Manager komplexním nástrojem pro vývoj a správu multidimenzionálního prostředí v databázi Oracle 11g. Na stránkách výrobce je dostupných několik obsáhlých dokumentů obsahujících popis a způsob práce s tímto nástrojem. Je dostupné i rozsáhlé diskusní fórum, obsahující příspěvky uţivatelů s praktickými zkušenostmi a řešením reálných implementačních a administračních problémů. Pro vytvoření navrţeného OLAP prostředí je třeba definovat dimenze a datovou krychli. Při deklaraci dimenzí jsem postupoval podle dokumentace. K vytvoření dimenze jsem pouţil volbu kontextového menu „Create Dimension…“ na objektu dimenzí. Kde jsem deklaroval především tyto hodnoty: 69

Jména a popisek potřebných dimenzí. Typ vytvářené dimenze. U časové dimenze jsem pouţil v parametru „Dimension type“ volbu „User Dimension“ namísto dostupné volby „Time dimension“, protoţe mnou navrţená tabulka DW_D01Date obsahující hodnoty pro definici dimenzí neobsahuje slupce TIME_SPAN a END_DATE, pro kaţdou úroveň dimenze, které jsou nativně vyţadované tímto prostředím pro časové dimenze. Na záloţce „Levels“ úrovně dimenze s jejich názvy a popisky pro následné sestavení hierarchie. Povolení vytvoření materializovaných pohledů na záloţce „Materialized Views“ Po vytvoření dimenzí jsem vytvořil ke kaţdé dimenzi jednu hlavní hierarchii prostřednictvím volby „Create Hierarchy…“ v kontextovém menu nad objektem „Hierarchy“, kde jsem specifikoval tyto parametry: Jméno a popis hierarchie Druh pouţité hierarchie jako „Level Based Hierarchy“ (všechny mnou navrţené dimenze jsou tohoto typu) Přiřadil jsem hierarchii pro ní vytvořené úrovně a seřadil je dle navrţeného pořadí pomocí selektoru ve spodní části karty „General“ Viz Obrázek 20 – Deklarace dimenze v prostředí AWM Poslední krok k vytvoření dimenzí bylo vytvoření mapování logického schématu dimenze na

skutečné

objekty

v relační

databázi

obsahující

hodnoty

pro

naplnění

multidimenzionálního kontejneru daty. Toto mapování jsem provedl prostřednictvím obrazovky pod volbou „Mappings“ zapsáním výrazu ‘Vše‘ pro první úroveň hierarchie a dále pomocí přetaţením patřičného pole ze zdroje dat do patřičného logického schématu vytvářené dimenze.

70

Obrázek 20 – Deklarace dimenze v prostředí AWM (vlastní tvorba)

Po vytvoření dimenzí je moţno si prohlédnout hodnoty obsaţené v materializovaných pohledech pro úrovně dimenze a naplnění vlastních dimenzí prostřednictvím obrazovek ve volbě „Views“, případně zkontrolovat strukturu načtením dat do multidimenzionálního kontejneru volbou „Maintain Dimension…“ v kontextovém menu nad patřičnou dimenzí a následným zobrazením hierarchie dané dimenze prostřednictvím volby „View Data…“ v tomtéţ kontextovém menu. Viz Obrázek 21 – Zobrazení hodnot vytvořené dimenze.

Obrázek 21 – Zobrazení hodnot vytvořené dimenze (vlastí tvorba)

V tomto bodě jsou všechny potřebné dimenze vytvořeny a je třeba přistoupit k vytvoření datové krychle Obchody. Datovou krychli jsem vytvořil pomocí kontextového menu na

71

objektu „Cubes“ a volby „Create Cube…“. Při vytvoření datové krychle jsem zadal tyto hodnoty: Jméno a popisek datové krychle Za pomocí selektoru ve spodní části obrazovky jsem přiřadil krychli vytvořené dimenze Na záloţce „Aggregation“ jsem zadal způsob agregace měr pro vyvrtávání z datové krychle jako operaci sumace a označil pro agregaci všechny dostupné dimenze. Nastavení přepočítávání datové krychle jsem nechal nastaveno na výchozí hodnotu 35 %. Na záloţce „Partitioning“ jsem záměrně nechal tuto volbu neaktivní z důvodu dalšího porovnávání s OLAP serverem Mondrian. Na záloţce „Materialized View“ jsem zaškrtl volbu „Enable Materialized View Refresh of the Cube“ pro povolení vyuţití materializovaného pohledu. Následně jsem vytvořené datové krychli vytvořil míry prostřednictvím kontextového menu nad objektem „Measures“ volbou „Create Measure…“, kde jsem zadal všechny 3 navrhované míry s těmito parametry. Posledním krokem při tvorbě datové krychle bylo vytvoření mapování logického schématu datové krychle na tabulku faktů. Toto bylo provedeno prostřednictvím obrazovky „Mappings“ ve stromové struktuře nabídek objektu „Cubes“. Viz Obrázek 22 – Mapování měr a dimenzí datové krychle v prostředí AWM. Takto vytvořenou krychli je nyní třeba nechat přepočítat, tj. naplnit daty z relačních tabulek. Tato akce se provede pomocí volby „Maintain Cube OBCHODY…“ v kontextovém menu nad objektem vytvořené datové krychle. Po zvolení této volby engine

Oracle

Olap

option

provede

build

vytvořených

objektů,

generaci

multidimezionálních dat a těmito daty potom vytvořené objekty naplní. Celý proces je přehledně provázen průvodcem, kde jsem zadal pro zpracování všechny dimenze a datovou krychli a způsob zpracování ihned. Pro produkční řešení je dostupná volba naplánovat tento proces na určitý datum a čas, případně nastavit maximální počet paralelních procesů tak, aby nebylo optimalizováno vyuţití dostupného výpočetního výkonu.

72

Obrázek 22 – Mapování měr a dimenzí datové krychle v prostředí AWM (vlastní tvorba)

Po spuštění se zobrazí okno „Maintrance Log“, kde systém informuje o průběhu buildu a plnění objektů daty. Protoţe výpočet datové krychle je náročná operace z hlediska čtení, agregace a manipulace s daty, trvá tato operace nějakou dobu. V případě výpočtu v této práci popsané krychle trvala tato operace 452 vteřin. Úspěšné dokončení je indikováno vizuálním návěštím. Celý proces je detailně popsán v logu, který proces paralelně zapisuje. Viz Obrázek 23 – Dokončení výpočtu multidimenzionální datové krychle. Tímto je implementace datového skladu v podstatě dokončena. V produkčním prostředí by implementaci předcházela výrazně širší analýza skladovaných dat a jejich významu pro účely podpory rozhodování či predikce. Popis těchto oborově specifických technik by však vydal na několik diplomových prací a je nad rámec práce této. Tento proces je v reálném prostředí velmi časově i finančně nákladný. V průběhu implementace i po ní ve skutečném datovém skladu musejí probíhat procesy přidělování uţivatelských práv pro přístup do multidimenzionálních dat, optimalizace uloţených dat, konfigurace přepočítávaných agregací, participace nejvytíţenějších tabulek, analýzy zatíţení, časový plán výpočtu datových krychlí či procesu ETL atd. Těmito otázkami se tato diplomová práce nezabývá, protoţe v této případové studii nevyvstaly. Posledním bodem provedeným při implementaci OLAP serveru je ověření jeho funkčnosti. Jeho funkci jsem si ověřil jednoduše pomocí vestavěného nástroje v prostředí Analytic 73

Workspace Manager. Kde jsem v kontextovém menu vyvolaném nad objektem datové krychle „Obchody“, volbou „View Data OBCHODY…“ zobrazil okno „Measure Data Viewer.

Obrázek 23 – Dokončení výpočtu multidimenzionální datové krychle (vlastní tvorba)

Výsledkem je okno, kde jsou zobrazeny dvě osy, na které si libovolně mohu přetahovat kteroukoliv z definovaných dimenzí či měr, účastných v datové krychli. Takto přetaţený objekt se automaticky zakomponuje do zobrazovaného výsledku. Pomocí navigačních tlačítek mohu provádět základní operace zavrtávání či vyvrtávání. Výsledky jsou ihned zobrazovány na uţivatelsky nastavitelném grafu. Toto zobrazení má však pouze charakter ad-hoc vizualizace. Některé funkce pro práci s multidimenzionálními daty chybí. Pro ověření realizace potřebných objektů v jádru databáze, funkčnosti převodu dat do miltidimenzionálního formátu a vypočítání datové kostky však postačuje. Viz Obrázek 24 – Interaktivní zobrazení výsledků v prostředí AWM.

74

Obrázek 24 – Interaktivní zobrazení výsledků v prostředí AWM (vlastní tvorba)

3.3

PSM návrh architektury a řešení datového skladu Pentaho

3.3.1 Vlastní instalace OLAP serveru Pentaho Mondrian Při instalaci produktu Mondrian společnosti Pentaho jsem postupoval podle instrukcí uvedených na oficiálních stránkách výrobce toho produktu. Jako první krok je třeba stáhnout JAR soubory se samotným jádrem aplikace. Tyto soubory jsou přehledně odkazovány na internetových stránkách společnosti Pentaho. Staţené soubory představují vlastně jakýsi interface mezi pouţitou relační databází a uţivatelským rozhraním, kde uţivatel definuje své dotazy, které jsou převedeny na SQL dotazy, spuštěny nad relační databází a výsledná výsledková sada je opět převedena do multidimezionálního formátu, který potom aplikační vrstva zobrazuje. Při downloadu těchto souborů je moţno vybrat si z několika variant připravených instalačních balíčků. Například balíček obsahující aplikace jPivot, která představuje webový framework. Všechny distribuce obsahují zdrojové soubory OLAP serveru Mondrian. 75

Instalační postup obecně sestává z těchto kroků: Instalace Java JDK prostředí (1.4.2 nebo vyšší) Download a dekomprimace posledního release produktu Mondrian Instalace Tomcat Nastavení a spuštění webové aplikace Pro případovou studii této diplomové práce jsem vybral distribuci produktu Mondrian bez vloţené databáze, kterou bylo moţno instalovat z jednoho z připravených instalačních balíčků. K tomuto rozhodnutí jsem se přiklonil, protoţe jiţ jedna relační databáze se strukturami datového skladu a naplněným obsahem byla k dispozici pro realizaci kapitoly č. 3.2. Touto prací jsem nechtěl porovnat výkonnosti jednotlivých relačních databází, ale vlastnosti jednotlivých OLAP serverů. Proto jsem se rozhodl pouţít stejnou datovou základnu pro oba OLAP produkty. HW pro instalaci jsem pouţil totoţný jako v kapitole 3.2, tedy notebook Lenovo T410 s OS Windows 7 Profesional. Po staţení a instalaci prostředí Java JDK 32bit, verze 6.26 bylo třeba instalovat aplikační server Tomcat. Pouţil jsem 32-bitovou verzi 7.0.16, která je volně ke staţení na stránkách výrobce. Instalace aplikačního serveru Tomcat v tomto případě spočívala pouze v umístění aplikačních souborů serveru a vytvoření dávkového souboru pro zajištění naplnění systémové proměnné JAVA_HOME a spuštění výrobcem dodaného dávkového souboru startup.bat. v adresáři \bin. Tím je příprava aplikačního serveru ukončena. Ověření funkční instalace serveru lze provést zadáním adresy http://localhost:8080, kdy se načte úvodní stránka tohoto produktu. Po staţení souboru mondrian-3.2.1.13885.zip a jeho dekomprimaci jsou potřebné soubory obsaţeny v adresáři ..\lib\. K zprovoznění Mondrian je třeba nakopírovat war soubor mondrian.war z adresáře instalačního balíčku lib\ do domovského adresáře Tomcatu ..\webapps. Server Tomcat automaticky vytvoří příslušný adresář pro Mondrian a extrahuje do něj aplikační soubory. 76

Tímto je instalace Mondrian připravena k pouţití a funkčnost instalace je moţno ověřit na adrese http://localhost:8080/mondian/, odkud se načte výchozí stránka serveru s odkazy na vzorové příklady v aplikaci jPivot, základní interface pro MDX dotazy atd…

3.3.2 Konfigurace OLAP serveru a mapování modelu na SŘBD Oracle 11g Dalším krokem k cíli bylo nastavení konfiguračních souborů pro připojení k jiţ instalované relační databázi, kde je třeba doplnit parametry pouţitých driverů, adresu SŘBD, účet pro přihlášení a XML schéma OLAP databáze. Nastavení je třeba zapsat v souborech v domovském adresáři Tomcatu. ..\webapps\Mondrian\WEB-INF\mondrian.properties Tímto zápisem: mondrian.test.connectString=Provider=mondrian; Jdbc=jdbc:oracle:thin:“user“/“pass“@localhost:1521:orcl; JdbcDrivers=oracle.jdbc.driver.OracleDriver;Catalog=/WEBINF/queries/Obchody.xml;

a ..\webapps\Mondrian\WEB-INF\web.xml Tímto zápisem: <param-name>connectString <param-value>Provider=mondrian; Jdbc=jdbc:oracle:thin:“user“/“pass“@localhost:1521:orcl; JdbcDrivers=oracle.jdbc.driver.OracleDriver;Catalog=/WEBINF/queries/Obchody.xml

Pro ověření funkčnosti provedené konfigurace je třeba ještě vytvořit mapovací soubor uvedený v konfiguračních souborech, který vysvětluje vazby mezi fyzickým schématem tabulek datového skladu a definicí datové kostky, jejích dimenzí a patřičných hierarchií tak, jak je interpretována OLAP serverem.

77

Tabulka č. 11, nastavení a popis XML

Tag

Význam Deklaruje datovou krychli.



Definuje jméno vytvořené datové krychle


Definuje jméno dimenze Definuje druh dimenze, nutné uvádět jen pro dimenze časové. Identifikátor je použit pro optimalizace SQL dotazu a rozšířené využití analytických funkcí. Definuje cizí klíč v tabulce v tabulce faktů, který odkazuje na danou dimenzi Deklaruje hierarchii dimenze Definuje jméno úrovně Definuje jméno sloupce, který představuje hodnoty dané úrovně. Definuje datový typ úrovně tak jak jej interpretuje a zpracovává OLAP server. Definuje, zda je člen této úrovně v tabulce faktů unikátní. Pokud ano, použije se optimalizovaný způsob dotazování. Definuje úroveň časové dimenze. Deklaruje míru v tabulce faktů. Definuje jméno daného míry. Definuje sloupec představující danou míru v tabulce faktů.



<Measure> <Measure name="Quantiti"/> <Measure column="O01PocetCP"/> <Measure aggregator="sum" /> <Measure datatype="Integer"/>

Definuje způsob práce s daty pro agregaci. Definuje datový typ míry tak jak ji interpretuje a zpracovává OLAP server.

Tento mapovací soubor pouţívá syntaxi XML a všechny konfigurační párové i nepárové tagy jsou detailně popsány na internetových stránkách výrobce, a proto zde uvedu jen zkrácený příklad a popis jednotlivých párových značek. Viz Tabulka č. 11, nastavení a popis XML.

78

Obrázek 25 – Část XML mapovacího souboru (vlastní tvorba)

Kompletní konfigurační soubor této případové studie je k nahlédnutí v části Přílohy, viz příloha č. 3.

3.3.3 Vlastní použití OLAP serveru Pentaho Mondrian V tomto bodě jiţ je připravený aplikační server, OLAP server nakonfigurovaný tak, aby pracoval s poţadovaným SŘBD a OLAP server „ví“, které tabulky obsahují které hodnoty pro vytvoření dimenzí a datové krychle. Stačí tedy spustit aplikační server a přejít na adresu http://localhost:8080/mondian/. Pro

ověření

správné konfigurace všech

popsaných soborů funkční OLAP server lze provést libovolný MDX dotaz. Například: Select {[TradeDirection].[Prodej], [TradeDirection].[Nákup],

79

[TradeDirection].[All]} ON COLUMNS, {[TradeDate].[2008].[1].[2].Children} ON ROWS From [Obchody] Where ([Measures].[Amount])

Který vrátí výsledkovou sadu obsahující tři sloupce pro obchodní směr prodeje CP, pro obchodní směr nákupu CP a sumarizovaný sloupec pro oba obchodní směry dohromady. Na ose řádků jsou potom vypsány všechny záznamy druhého měsíce, prvního kvartálu roku 2008. V průsečíkách os řádků a sloupců jsou potom patřičné sumarizované hodnoty měr Amount (obchodní objem) z tabulky faktů. Viz Obrázek 26 – Výsledek MDX dotazu. Tento MDX dotaz je však velmi jednoduchý a dostatečně nedemonstruje celou sílu OLAP serveru a vypovídacích hodnot multidimenzionálních dat. Také je třeba k jeho konstrukci znát hodnoty dimenzních tabulek a pojmenování měr v tabulce faktů, jména dimenzí atd. Celkově je zadávání MDX dotazů pro uţivatele velmi nekomfortní a prezentace dotázaných dat v tabulce nemusí být vţdy optimální. Z tohoto důvodu jsem se rozhodl zprovoznit aplikaci jPivot, která přináší větší komfort při definici poţadovaného dotazu prostřednictvím grafického rozhraní a nabízí nepoměrně větší moţnosti prezentace dotázaných dat. K zprovoznění aplikace jPivot, která je součástí výše popsaného instalačního balíčku postačí konfigurace JSP souboru modrian.jsp umístěného v cestě: ..\webapps\Mondrian\WEB-INF\queries Tímto zápisem: <jp:mondrianQuery id="query01" jdbcDriver="oracle.jdbc.driver.OracleDriver" jdbcUrl="jdbc:oracle:thin:“user“/“pass“@localhost:1521:orcl" catalogUri="/WEB-INF/queries/Obchody.xml" jdbcUser=“user“ jdbcPassword=“pass“ connectionPooling="false">

80

A doplněním MDX dotazu, který bude pouţit jako výchozí. V případě této případové studie tedy výše citovaného.

Obrázek 26 – Výsledek MDX dotazu (vlastní tvorba)

Aplikace jPivot se opět spouští zadáním adresy http://localhost:8080/mondian/ do internetového prohlíţeče. Na zobrazení MDX dotazu nad databází nakonfigurovanou v souboru mondrian.jsp stačí kliknout na volbu „JPivot pivot table“. Po kliknutí na tuto volbu se zobrazí podobná tabulka, jako ukazuje Obrázek 26 – Výsledek MDX dotazu. Viz Obrázek 27 – Zobrazení MDX dotazu pomocí aplikace jPivot. Je ovšem lépe graficky vyvedená a interaktivní. To znamená, ţe je moţné v ní pomocí ovládacích prvků

81

(červených šipek) měnit úroveň zobrazovaných hierarchií a provádět tak operace zavrtávání (Drill Down) či vyvrtávání (Drill Up).

Obrázek 27 – Zobrazení MDX dotazu pomocí aplikace jPivot (vlastní tvorba)

Aplikace jPivot potom na základě takto zvoleného detailu pohledu automaticky vytvoří MDX dotaz a pošle jej prostřednictvím OLAP serveru Mondrian do relační databáze. Výsledek potom znova zobrazí uţivateli, viz Obrázek 28 – Změněná úroveň detailu a nový MDX dotaz.

Obrázek 28 – Změněná úroveň detailu a nový MDX dotaz (vlastní tvorba)

82

Změna definice výběrových podmínek, dalších dimenzí na jednotlivých osách atd., je díky rozbalovacím seznamům velmi komfortní, rychlá a přehledná. Viz Obrázek 29 – Interaktivní definice MDX dotazu aplikací jPivot.

Obrázek 29 – Interaktivní definice MDX dotazu aplikací jPivot (vlastní tvorba)

Pro potřeby uţivatele je moţné generovat i různé grafy podle úrovně zvoleného detailu. Viz Obrázek 30 – Ukázka grafu na základě multidimenzionálních dat.

83

Obrázek 30 – Ukázka grafu na základě multidimenzionálních dat (vlastní tvorba)

84

4 Porovnaní vyhotovených řešení V předešlých kapitolách jsem popsal návrh a způsob implementace dvou OLAP serverů Oracle OLAP a Pentaho Mondrian. Nyní zbývá vyhotovená řešení vzájemně porovnat mezi sebou. Obecné porovnání parametrů těchto dvou produktů z hledisek platformy, způsobu uloţení dat a dotazovacích jazyků obsahují jiţ tabulky č. 5, č. 6, č. 7 a tabulka č. 8. Nyní se tedy zaměřím na srovnání řešení z hledisek, pro která si mohu v popsaném implementačním prostředí vytvořit metriky a za pomoci dostupného vybavení dle těchto metrik obě řešení porovnat.

4.1

Porovnání z pohledu dostupnosti a instalace

Dostupnost je u obou serverů stejná, oba jsou ke staţení na oficiálních stránkách svých výrobců. Instalační balíček Mondrianu má velikost 87MB. Tento balíček ovšem obsahuje kompletní zdrojové kódy a testovací databázi. Samotný webový archiv serveru i s aplikací jPivot má 50,5 MB. Instalace OLAP serveru společnosti Pentaho je tak na diskovou kapacitu velmi nenáročná a download z webu výrobce je velmi rychlý. Nutno však podotknout, ţe zmiňované soubory obsahují jen OLAP server a podpůrné utility. Instalační balíček produktu Oracle 11g má zhruba 1,7 GB. Tato instalace obsahuje jádro robustní SŘBD, zmíněnou aplikaci Oracle SQL Developer, JDK knihovny a velký počet dalších podpůrných ovládacích a administrátorských utilit. Citována aplikace Analytic Worskspace Manager součástí balíčku není a zabere na disku dalších 64 MB. Instalace OLAP serveru Oracle OLAP je tedy na diskovou kapacitu řádově náročnější neţ u Mondrian. V případě této diplomové práce nebylo třeba řešit otázky licencí. V případě produkčního řešení je však situace diametrálně odlišná. Řešení Pentaho Mondrian se dá označit jako cenově dostupné, řešení Oraclu se dá označit jako velmi nákladné.

85

Z pohledu instalace produktů je zde rozdíl také velký. V instalačním balíčku Oracle je k dispozici přehledný průvodce instalací, samotná instalace je velmi košatá a specifikovatelná. Po instalačním procesu je databáze připravena k pouţití či další administraci. Mondrian instalační balíček nemá. K dispozici je pouze instalační postup zdokumentovaný výrobcem. Samotná instalace obsáhlá není, spočívá víceméně v konfiguraci.

4.2

Porovnání z pohledu implementace

Implementace obou serverů je velmi rozdílná, coţ vyplívá ze způsobu, jakým ukládají data. Oracle OLAP option je multidimenzionální OLAP, který data z datového skladu načítá do svých multidimenzionálních objektů a materializovaných pohledů, partition tabulek atd. Navzdory popsanému faktu je díky dostupnému vývojovému prostředí AWM tento proces velmi intuitivní a jen málo se liší od obecně popisované problematiky budování datových kostek a dimenzí. Implementace tedy probíhá v jednotném grafickém prostředí pomocí přetahování hodnot (drag&drop) a checkboxů v přehledně vyvedených průvodcích. Grafické rozhraní umoţňuje snadné mapování obecného multidimenzionálního logického schématu na fyzické schéma datového skladu. Na rozdíl od řešení Mondrian, na pozadí tohoto grafického rozhraní dochází k transformaci tabulek dimenzí a přepočítávání hodnot datové krychle. Zajímavou hodnotou je, ţe v případě zde popsané případové studie si přetransformovaná data z relační databáze vyţádala dalších 132MB diskového prostoru. Oproti Oracle, implementace Mondrianu probíhá prostřednictvím konfiguračních XML nebo JSP souborů, kde se definují způsoby konexe k SŘBD, způsoby práce s materializovanými pohledy, cacheováním výpočtů a dalších optimalizačních nastavení serveru. Mondrian neprovádí build multidimenzionálních objektů, ale překládá MDX dotazy na dotazy SQL, kterými potom dotazuje data v relačním modelu. Metrikou v tomto případě je rychlost, přehlednost a intuitivita a účinnost nasazeného řešení.

4.3

Porovnání z pohledu rychlosti

Jak jiţ bylo v této práci zmíněno, zdrojová SŘBD i oba OLAP servery jsou instalovány na jednom počítači a zdrojová data čerpají z jedné databáze. Tabulka faktů je naplněna počtem záznamů přesahujícím 600tis. Tyto data představují reálný počet záznamů v produkčním transakčním systému nasbíraná za období třech kalendářních roků.

86

Pro porovnání rychlosti odezvy jsem zvolil několik náhodných dotazů s různou úrovní granularity a počtem pouţitých dimenzí. Naměřené hodnoty odezvy na následující modelové dotazy v sekundách zobrazuje Tabulka č. 12, rychlosti odezvy OLAP serverů. Dotaz č. 1 select {[TradeDirection].[Prodej], [TradeDirection].[Nákup], [TradeDirection].[All]} ON COLUMNS, {[TradeDate].[2008].[1].[3].Children, [TradeDate].[2008].[2].Children} ON ROWS from [Obchody]

Dotaz č. 2 select Hierarchize(Union({[Emission].[All]}, [Emission].[All].Children)) ON COLUMNS, {[Measures].[Quantiti], [Measures].[UnitPrice], [Measures].[Amount]} ON ROWS from [Obchody]

Dotaz č. 3 select {[TradeDirection].[All], [TradeDirection].[Nákup], [TradeDirection].[Prodej]} ON COLUMNS, {[TradeDate].[2008], [TradeDate].[2008].[1], [TradeDate].[2008].[1].[1].[1]} ON ROWS from [Obchody] where {[Measures].[Quantiti], [Measures].[UnitPrice], [Measures].[Amount]}

Dotaz č. 4 select Crossjoin({[TradeDirection].[All], [TradeDirection].[Nákup], [TradeDirection].[Prodej]}, {[Emission].[All]}) ON COLUMNS, {[TradeDate].[2008], [TradeDate].[2008].[1], [TradeDate].[2008].[1].[1].[1]} ON ROWS from [Obchody] where {[Measures].[Quantiti], [Measures].[UnitPrice], [Measures].[Amount]}

87

Dotaz č. 5 select Crossjoin({[TradeDirection].[All], [TradeDirection].[Nákup], [TradeDirection].[Prodej]}, {[Emission].[All], [Emission].[USA [Emission].[USA

].[Akcie

],

]}) ON COLUMNS,

{[TradeDate].[2008], [TradeDate].[2008].[1], [TradeDate].[2008].[1].[1].[1]} ON ROWS from [Obchody] where {[Measures].[Quantiti], [Measures].[UnitPrice], [Measures].[Amount]}

Tabulka č. 12, rychlosti odezvy OLAP serverů MDX dotaz Dotaz č. 1

4.4

Oracle OLAP

Pentaho Mondrian 1

1,9

Dotaz č. 2

0,7

1

Dotaz č. 3

1,1

2,1

Dotaz č. 4

1

0,7

Dotaz č. 5

1,4

2,9

Další varianty porovnání

Další podstatnou vlastností Pentaho Mondrian je fakt, ţe se jedná o open–source řešení, coţ otvírá dveře dalším moţnostem vyuţití, modifikacím jádra serveru a jeho vlastností. Server můţe být upraven k naprosto specifickým podmínkám či poţadavkům zákazníka. Tuto variantu cumstomizace řešení firmy Oracle nenabízí. Celá tato kapitola si ţádá srovnání těchto řešení z hlediska určení cílového zákazníka produktu. Zatím co Oracle míří na velké podnikatelské subjekty, jako jsou banky, pojišťovny, telefonní operátoři či velké obchodní řetězce, řešení společnosti Pentaho je určeno pro menší a střední podniky.

88

Závěry a doporučení …téma problematiky datových skladů, na které je zaměřen cíl této diplomové práce jsem si vybral zcela záměrně. Ve svém profesionálním ţivotě se pohybuji ve světě relačních databází řadu let a obecné povědomí a praktická zkušenost s tímto odvětvím práce s daty měla být další cenou komoditou, o kterou jsem se chtěl studiem obohatit… Závěrem této práce bych rád shrnul způsob a míru dosaţení stanovených cílů, zamyslel se nad prezentovanými výsledky a uváţil další moţnosti a směry. Prvním cílem bylo detailní seznámení s moderními přístupy návrhu OLAP aplikací. Nejprve tedy bylo nutné pochopit k čemu a z čeho obor datawarehousingu vznikl, a jaký je jeho přínos pro vedení firem i běţnou společnost. Bylo nutné definovat základní stavební kameny logického schématu, jako je dimenze či datové krychle. Pochopit význam denormalizovaných dat pro konstrukci dimenzí a jejich hierarchií a roli takto denormalizovaných dat pro agregace v tabulkách faktů. Proto jsem v první části detailně popsal prostředí nynějších relačních databází a jazyk SQL, za pomocí kterého se dnešním relačním databázím, které v sobě ukrývají hlavně data transakčních informačních systémů, vládne. Podle veškeré, mnou studované literatury, udrţení konzistentních, správných a věcných dat a jejich zpracování právě na straně zdrojových transakčních systémů, je prvním předpokladem k naplnění datového skladu daty, která mohou představovat hodnotu v podobě správného rozhodnutí. Zmiňuji zde i široce známý termín ETL, který představuje ono vybírání dat ze zdrojových dat, jejich ošetření a transformaci do podoby vhodné pro vloţení do datového skladu a fyzické vloţení. V dostupné literatuře existuje nepřeberné mnoţství definic a stručných návodů jak tento proces realizovat a jakých prostředků pouţít. Dostupné zdroje zmiňují i celou řadu běţně řešených problémů a jejich řešení, doporučují vhodná či odkazují jiţ aplikované a ověřené postupy. Přední výrobci databázových systémů dodávají ke svým produktům velmi sofistikovaná řešení pokrývající všechny tři fáze tohoto procesu. Přes všechnu prostudovanou literaturu se ETL stále jeví jako velmi individuální a těţko konkrétně popsatelný klíčový proces pro pouţitelnost datového skladu.

89

Kdyţ vznikne povědomí o světě datových skladů, bylo by velkou škodou nabyté informace, někdy jen data, nezpevnit aplikací na konkrétním případě. Toto upevnění nabytých znalostí popisuje druhá a třetí část této práce, ukázková implementace OLAP ve dvou zcela rozdílných prostředích. Na řádcích třetí kapitoly jsem navrhl zdrojovou databázi pro případovou studii implementace. Protoţe zdrojová databáze opravdu odráţí funkci skutečného, a v produkčním prostředí pouţívaného transakčního informačního systému, vytvořil jsem dotazy pro kaţdou z navrhnutých tabulek faktů a dimenzí a tyto dotazy pouţil jako proces Extrakct a Transform procesu ETL. Následně jsem je do připravené databáze Oracle 11g vloţil. Následovala implementace OLAP serveru Oralce Olap option a Pentaho Mondrian. Řešení společnosti Oracle pro mě nebylo ţádným překvapením. Vnímám její produkty jako velmi sofistikované a propracované. Tabulky faktů a dimenzí byly umístěny a naplněny téţ v databázi Oracle, v které je integrován i OLAP server Oracle OLAP option. Proto samotné vytvoření datové kostky a dimenzí, díky absolutní integraci relačního a multidimenzionálního prostředí, nebylo podle poskytované, přehledné dokumentace zásadním problémem. Toto řešení je opravdu velmi propracované, ale díky jeho sloţitosti klade mnohem větší nároky na vývojáře a administrátora. K řešení databáze a OLAP serveru jednoho výrobce jsem přistoupil zcela úmyslně, chtěl jsem mít představu, jak funguje kompletní integrované řešení oproti OLAP serveru další strany, proti OLAP serveru Pentaho Mondrian. První kontakt s touto kategorií produktů pro mě byl odměnou v podobě velkého překvapení a nového pohledu na věc. Velká jednoduchost, absence tlustého klienta, přehledně prezentovaná data a úplná volnost pouţití. To je to, co charakterizuje tento open–source produkt. Teprve v kontextu Mondrianu jsem si uvědomil, ţe OLAP server a následné analýzy dat nemusí být doménou podnikatelských gigantů a velmi nákladných projektů. Především spojení Mondrianu s aplikací jPivot v sobě skrývá pohodlné, rychlé a přehledné řešení pro kaţdý den. Díky implementaci obou těchto OLAP serverů jsem si mohl udělat obrázek, z jakých úhlů a různých stupňů agregací je moţno na data pohlíţet a jak je moţné je přehledně zobrazovat uţivateli. Uţ v průběhu testování a pohrávání si s vyhotovenými řešeními, jsem si začínal uvědomovat, ţe navrhnutý logický model dimenzí a datové kostky nedovede zcela vyuţít silného potenciálu multidimenzionálně zformovaných dat a následných analýz. Však je mou první zkušeností se skutečným návrhem reálného řešení a věcně je správný. Především bych pouţil 90

degenerovanou dimenzi pro tabulku DW_D05StavSmerObchodu. Obsahuje jen dvě věty a není třeba pro ni zakládat další dimenzí tabulku. V případě Mondrian lze dokonce celou věc vyřešit pomocí tzv. inlinetable, coţ je tabulka deklarovaná přímo v konfiguračním souboru XML. Posledním bodem bylo srovnání provedených implementací. Fyzický kontakt s oběma řešeními v poslední kapitole, popisující mino jiné rozdíly v odezvách daných serverů, byl pro mě nejzajímavější. Oracle OLAP option je MOLAP a je plně integrován do domácího prostředí databáze Oracle 11g, dalo by se předpokládat, ţe bude výrazně rychlejší neţli ROLAP řešení Pentaho Mondrian. Pravděpodobně při vyšší zátěţi serverů více uţivateli či datovým skladem naplněným řádově větším mnoţstvím dat, které obyčejně datové sklady obsahují, by výsledek rychlosti odezvy dopadl jinak. Avšak v této případové studii, která popisuje reálnou problematiku a data jsou naplněna skutečnými objemy dat reprezentující 3 roky ţivota transakčního systému, je Oracle OLAP srovnatelný v rychlosti odezvy s produktem Pentaho Mondrian. U produktu Oracle OLAP mě velmi nadchla realizace spojit zástupce běţných OIS – Microsoft Excel 2007 – prostřednictvím driveru Simba MDX Provider For Oracle OLAP přímo s multidimenzionálními objekty umístěnými v Oracle, načíst definice dimenzí, měr, interaktivně dotazovat data a v Excelu vlastní velké škále vizualizací je zobrazovat a zpracovávat.

Pokládám

to

za

elegantní

řešení

velmi

specifického

zobrazení

multidimenzionálních dat zcela běţnou aplikací. Při zpracování teoretických částí jsem prošel citovanou literaturu a vyuţil ji k popisu dané problematiky. V praktické části této diplomové práce popisuji mnou provedenou implementaci navrhovaného řešení v prostředích Oracle OLAP a Pentaho Mondrian, při které jsem všechny nabyté zkušenosti zúročil. Velmi rád na tomto posledním řádku konstatuji, ţe stanovené cíle tak byly splněny.

91

Seznam použité literatury [1] Comparison of OLAP Servers. In Wikipedia : the free encyclopedia [online]. St. Petersburg (Florida) : Wikipedia Foundation, 20. september 2009, last modified on 3. july 2011 [cit. 2011-06-04]. Dostupné z WWW: . [2] BERKA, Petr. Dobývání znalostí z databází. Vyd. 1. Praha : Academia, nakladatelství věd České Republiky, 2003. 365 s. ISBN 80-200-1062-9. [3] HYDE, Julian. Pentaho Mondrian Documentation [online]. Release 3.2. 2009 [cit. 201101-02]. MDX Specification. Dostupné z WWW: . [4] HYDE, Julian . Pentaho Mondrian Documentation [online]. Release 3.2. 2006 [cit. 201101-01]. Pentaho Mondrian Documentation. Dostupné z WWW: . [5] LACKO, Luboslav. Databáze: datové sklady, OLAP a dolování dat s příklady v Microsoft SQL serveru a Oracle. Brno : Computer Press, 2003. 478 s. ISBN 80-7226-969-0. [6] LACKO, Luboslav. Oracle : Správa, programování a použití databázového systému. Vyd. 1. Brno : Computer Press, 2007. 576 s. ISBN 978-80-251-1490-2. [7] Manuály.net [online]. 2007-08-02 [cit. 2011-05-10]. Teorie relačních databází: Normalizace. Dostupné z WWW: . [8] Model driven architecture. In Wikipedia : the free encyclopedia [online]. St. Petersburg (Florida) : Wikipedia Foundation, 22.1.2010, last modified on 26.4.2011 [cit. 2011-0614]. Dostupné z WWW: .

92

[9] Oracle OLAP User's Guide. In Oracle OLAP User's Guide Release 11g [online]. Červen 2008 [cit. 2011-06-13]. Dostupné z WWW: . [10]

VOSTROVSKÝ, Václav. Relační databázové systémy. Vyd. 1. Praha : ČZU PEF

Praha - CREDIT , 2001. 98 s. ISBN 80-213-0753-6. [11]

WHITEHORN, Mark; ZARE, Robert; PASUMANSKY, Mosha. Fast Track to MDX :

Second edition. 1st edition. Worcester : Springer Science, 2006. 309 s. ISBN 978-184628-174-7 [12]

Wikipedia [online]. 2010. 2010 [cit. 2011-05-05]. Databázová transakce. Dostupné

z WWW: . [13]

Wikipedia [online]. 2010. 2010 [cit. 2011-01-02]. MultiDimenzional eXpressions.

Dostupné z WWW: . [14]

ZÁMYSLICKÝ, Jan. Návrh a implementace OLAP prostředí nad archivy

výsledků studentské ankety ČVUT. Praha, 2009. 91 s. Diplomová práce. České vysoké učení technické v Praze – Fakulta elektrotechnická.

93

Seznam použitých zkratek AWM – Analytic Workspace Manager BI – Business intelligence CSV – Comma Separated Value DB – Database DBS – Database Specification DCL – Data Control Language DDL – Data Definition Language DML – Data manipulation Language DSS – Decision support system ERP – Enterprise resources planning ETL – Extract – Transform – Load JAR – Java Archive JDK – Java Development Kit JSP – Java Server Page MDX – Multidiemsional expresions OLAP – Online Analytical Processing OLTP – Online Transactional Processing PIM – Platform independent model PSM – Platform specific model RDM – Relational Database Model SŘBD – Systém řízení báze dat SQL – Structured query Language TCC – Transaction Control Language T-SQL – Transact SQL 94

XMLA – XML For Analysis

95

Seznam použitých obrázků Obrázek 1 – Druhy datových modelů ....................................................................................... 10 Obrázek 2 – Struktura dat relační databáze .............................................................................. 13 Obrázek 3 – Normální formy.................................................................................................... 15 Obrázek 4 – Pohyb dat ............................................................................................................. 19 Obrázek 5 – Třívrstvá architektura ........................................................................................... 21 Obrázek 6 – MOLAP a ROLAP zpracování ............................................................................ 22 Obrázek 7 – Multidimenzionální krychle ................................................................................. 23 Obrázek 8 – Hvězdicové schéma.............................................................................................. 26 Obrázek 9 – Schéma sněhové vločky ....................................................................................... 27 Obrázek 10 – Operace projekce................................................................................................ 32 Obrázek 11 – Operace selekce.................................................................................................. 33 Obrázek 12 – Operace spojení .................................................................................................. 34 Obrázek 13 – Hierarchie časové dimenze ................................................................................ 42 Obrázek 14 – Datový model relační databáze .......................................................................... 53 Obrázek 15 – Multidimenzionální kostka a dimenze ............................................................... 58 Obrázek 16 – Model hvězda datového skladu .......................................................................... 59 Obrázek 17 – Vytvoření konexe na SŘBD v SQL Developer ................................................. 61 Obrázek 18 – Průvodce importem dat ...................................................................................... 68 Obrázek 19 – Nový projekt v AWM Oracle............................................................................. 69 Obrázek 20 – Deklarace dimenze v prostředí AWM ............................................................... 71 Obrázek 21 – Zobrazení hodnot vytvořené dimenze ................................................................ 71 Obrázek 22 – Mapování měr a dimenzí datové krychle v prostředí AWM ............................. 73 Obrázek 23 – Dokončení výpočtu multidimenzionální datové krychle ................................... 74 Obrázek 24 – Interaktivní zobrazení výsledků v prostředí AWM........................................... 75 Obrázek 25 – Část XML mapovacího souboru ........................................................................ 79 Obrázek 26 – Výsledek MDX dotazu....................................................................................... 81 Obrázek 27 – Zobrazení MDX dotazu pomocí aplikace jPivot................................................ 82 Obrázek 28 – Změněná úroveň detailu a nový MDX dotaz ..................................................... 82 Obrázek 29 – Interaktivní definice MDX dotazu aplikací jPivot ............................................. 83 Obrázek 30 – Ukázka grafu na základě multidimenzionálních dat .......................................... 84

96

Seznam použitých tabulek Tabulka č. 1, rozdíly v architekturách ................................................................................. 20 Tabulka č. 2, osy a buňky ..................................................................................................... 22 Tabulka č. 3, řídká matice .................................................................................................... 24 Tabulka č. 4, denormalizovaná tabulka .............................................................................. 26 Tabulka č. 5, OLAP řešení na trhu ...................................................................................... 47 Tabulka č. 6, podporované modely uložení dat ................................................................ 47 Tabulka č. 7, podporované platformy ................................................................................. 48 Tabulka č. 8, podporované dotazovací jazyky .................................................................. 48 Tabulka č. 9, instalační parametry ...................................................................................... 60 Tabulka č. 10, počet záznamů v tabulkách DW ................................................................ 67 Tabulka č. 11, nastavení a popis XML ............................................................................... 78 Tabulka č. 12, rychlosti odezvy OLAP serverů ................................................................. 88

97

Přílohy

98

Příloha č. 1 Architektura OLAP serveru Pentaho Mondrian

Příloha č. 2 DDL skript pro vytvoření datových struktur datového skladu /*==============================================================*/ /* Table: "DW_D01Date"

*/

/*==============================================================*/ create table "DW_D01Date"

(

"D01TimeID"

integer

not null,

"D01Date"

date

"D01Day"

integer

not null,

"D01Month"

integer

not null,

"D01Year"

integer

not null,

"D01Quarter"

integer

not null,

"D01MonthName"

Varchar(3)

null,

not null,

constraint PK_DW_D01DATE primary key ("D01TimeID") ); /*==============================================================*/ /* Table: "DW_D02Ucastnik"

*/

/*==============================================================*/ create table "DW_D02Ucastnik"

(

"D02UcastnikID"

integer

not null,

"U02FormaID"

integer

not null,

"U02Forma"

varchar(25)

not null,

"S01StatID"

integer

not null,

"S01NazevStat"

varchar(40)

not null,

U01RCIC

varchar(12)

not null,

"U01Jmeno"

varchar(30)

not null,

"U01Prijmeni"

varchar(30)

not null,

"U01DatumNarozeni"

date null,

constraint PK_DW_D02UCASTNIK primary key ("D02UcastnikID") );

/*==============================================================*/ /* Table: "DW_D03Emise"

*/

/*==============================================================*/ create table "DW_D03Emise"

(

"D03EmiseID"

integer

not null,

"S01StatID"

integer

not null,

"S01NazevStat"

varchar(40)

not null,

"S01NazevMena"

varchar(40)

not null,

"E02EmiseDruhID"

integer

not null,

"E02DruhNazev"

varchar(40)

not null,

"U01EmitentID"

integer

not null,

"U01Jmeno"

varchar(40)

not null,

"U01Prijmeni"

varchar(40)

not null,

E01ISIN

varchar(12)

not null,

"E01Nazev"

varchar(40)

not null,

constraint PK_DW_D03EMISE primary key ("D03EmiseID") );

/*==============================================================*/ /* Table: "DW_D04Trh"

*/

/*==============================================================*/ create table "DW_D04Trh"

(

"D04TrhID"

integer

not null,

"T01TrhKod"

character(16)

not null,

"T01TrhNazev"

varchar(25)

not null,

T01MIC

varchar(12)

not null,

"S01StatID"

integer

not null,

"S01NazevStat"

varchar(40)

not null,

"S01NazevMena"

varchar(40)

not null,

constraint PK_DW_D04TRH primary key ("D04TrhID") );

/*==============================================================*/ /* Table: "DW_D05ObchodSmer"

*/

/*==============================================================*/ create table "DW_D05ObchodSmer"

(

"D05ObchodSmerID"

integer

not null,

"P01Smer"

Varchar(40)

not null,

constraint PK_DW_D05OBCHODSMER primary key ("D05ObchodSmerID") ); /*==============================================================*/ /* Table: "DW_D06Stav"

*/

/*==============================================================*/ create table "DW_D06Stav"

(

"D06StavID"

integer

not null,

"P02StavPopis"

varchar(40)

not null,

constraint PK_DW_D06STAV primary key ("D06StavID") ); /*==============================================================*/ /* Table: "DW_F01Obchody"

*/

/*==============================================================*/ create table "DW_F01Obchody"

(

"F01ZaznamID"

INTEGER

"D01ObchodDatumID"

integer,

"D02ProtistranaID"

integer,

"D02UcastnikID"

integer,

"D03EmiseID"

integer,

"D04TrhID"

integer,

not null,

"D01VyporadaniDatumID" integer, "D01VlozeniDatumID"

integer,

"D05ObchodSmerID"

integer,

"D06StavID"

integer,

"O01ObchodObjem"

float(24)

default 0,

"O01PocetCP"

integer

default 0,

"O01CenaKus"

float(16)

default 0,

constraint PK_DW_F01OBCHODY primary key ("F01ZaznamID") ); alter table "DW_F01Obchody" add constraint "FK_F01Obchody_D01ObchodDatum" foreign key ("D01ObchodDatumID") references "DW_D01Date" ("D01TimeID"); alter table "DW_F01Obchody" add constraint "FK_F01Obchody_D02Ucastnik" foreign key ("D02UcastnikID") references "DW_D02Ucastnik" ("D02UcastnikID"); alter table "DW_F01Obchody" add constraint "FK_F01Obchody_D04Trh" foreign key ("D04TrhID") references "DW_D04Trh" ("D04TrhID"); alter table "DW_F01Obchody" add constraint "FK_F01Obchody_D03Emise" foreign key ("D03EmiseID") references "DW_D03Emise" ("D03EmiseID");

alter table "DW_F01Obchody" add constraint "FK_F01Obchody_D02Protistrana" foreign key ("D02ProtistranaID") references "DW_D02Ucastnik" ("D02UcastnikID"); alter table "DW_F01Obchody" add constraint "FK_F01Obchody_D01VyporadaniDt" foreign key ("D01VyporadaniDatumID") references "DW_D01Date" ("D01TimeID"); alter table "DW_F01Obchody" add constraint "FK_F01Obchody_D01VlozeniDatum" foreign key ("D01VlozeniDatumID") references "DW_D01Date" ("D01TimeID"); alter table "DW_F01Obchody" add constraint "FK_F01Obchody_D05ObchodSmer" foreign key ("D05ObchodSmerID") references "DW_D05ObchodSmer" ("D05ObchodSmerID"); alter table "DW_F01Obchody" add constraint "FK_F01Obchody_D06Stav" foreign key ("D06StavID") references "DW_D06Stav" ("D06StavID");

Příloha č. 3 Mapovací XML soubor OLAP serveru Pentaho Mondrian <Schema name="Obchody">


allMemberName="All"

primaryKey="D02UcastnikID">


allMemberName="All"

primaryKey="D03EmiseID">
allMemberName="All" primaryKey="D04TrhID">






allMemberName="All"

primaryKey="D05ObchodSmerID">
allMemberName="All"

primaryKey="D02ProtistranaID">



<Measure name="Quantiti" column="O01PocetCP" aggregator="sum" datatype="Integer"/> <Measure name="UnitPrice" column="O01CenaKus" aggregator="sum" datatype="Numeric"/> <Measure name="Amount" column="O01ObchodObjem" aggregator="sum" datatype="Numeric"/>

×

Report "Případová studie návrhu implementace a nasazení OLAP"

Your name

Email

Reason -Select Reason- Pornographic Defamatory Illegal/Unlawful Spam Other Terms Of Service Violation File a copyright complaint

Description

Close Send

×

Sign In

Email

Password

Remember me Forgot password?

Sign In

Our partners will collect data and use cookies for ad personalization and measurement. Learn how we and our ad partner Google, collect and use data. Agree & close