Upozornění pro čtenáře a uživatele této knihy
Všechna práva vyhrazena. Žádná část této tištěné či elektronické knihy nesmí být reprodukována ani šířena v papírové, elektronické či jiné podobě bez předchozího písemného souhlasu nakladatele. Neoprávněné užití této knihy bude trestně stíháno.

Doc. Ing. Jan Pour, CSc.
Doc. Ing. Miloš Maryška, PhD.
Ing. Iva Stanovská
Ing. Zuzana Šedivá, Ph.D.

Self Service Business Intelligence

Jak si vytvořit vlastní analytické, plánovací a reportingové aplikace

Vydala Grada Publishing, a.s.
U Průhonu 22, 170 00 Praha 7
tel.: +420 234 264 401, fax:+420 234 264 400
www.grada.cz
jako svou 6828. publikaci

Odborní recenzenti:
Ing. Michal Valenta, Ph.D.
Ing. Vladislav Štefaňák

Odpovědný redaktor Petr Somogyi
Grafická úprava a sazba Milan Vokál
Formát ePub Milan Vokál
Návrh a zpracování obálky Michal Němec
Počet stran 352
První vydání, Praha 2018 

Vytiskla Tiskárna v Ráji, s.r.o., Pardubice

© Grada Publishing, a.s., 2018

ISBN 978-80-271-0823-7 (ePub)
ISBN 978-80-271-0816-9 (pdf)
ISBN 978-80-271-0616-5 (print)

Našemu kamarádovi Honzovi

O autorech

Doc. Ing. Jan Pour, CSc.

Jan Pour vystudoval fakultu národohospodářskou na VŠE v Praze. Je docentem katedry informačních technologií Vysoké školy ekonomické v Praze. Profesně se orientuje na otázky řízení podnikové informatiky, koncepcí informačních systémů podniků a úlohy Business Intelligence. Je autorem nebo spoluautorem čtrnácti knižních publikací a řady vysokoškolských skript, článků v časopisech a příspěvků na konferencích. Podílel se na řešení cca sto dvaceti projektů pro nejrůznější podniky a organizace v energetice, průmyslu, obchodu i ve státní správě. V současné době je členem Rady České společnosti pro systémovou integraci a redaktorem časopisu Systémová integrace.

Doc. Ing. Miloš Maryška, PhD.

Miloš Maryška studoval na Katedře informačních technologií Vysoké školy ekonomické, kde obhájil disertační práci na téma „Referenční model řízení ekonomiky podnikové informatiky“. Od roku 2015 působí na Katedře informačních technologií jako docent. V rámci vědecké a pedagogické práce se zaměřuje na oblast řízení ekonomiky podnikové informatiky, Business Intelligence, Corporate Performance Management, finanční řízení podnikové informatiky a ERP systémy. Je spoluautorem sedmi monografií a více než sta odborných a vědeckých článků v časopisech a ve sbornících z mezinárodních konferencí. Ve společnosti VIG Re působí jako projektový manažer a team leader oddělení Busienss Processes and IT Solutions.

Ing. Iva Stanovská

Iva Stanovská je absolventkou fakulty řízení Vysoké školy ekonomické v Praze. V současné době působí jako ředitelka pro rozvoj a konzultační služby ve společnosti Solitea Business Solutions s.r.o., kde je odpovědná za řízení týmu Business Intelligence, předprodejní aktivity a podporu obchodu, firemní procesy a interní informační systém. Současně na částečný úvazek působí jako odborná asistentka na katedře informačních technologií Fakulty informatiky a statistiky VŠE v Praze, kde se zaměřuje na metodiky a postupy specifikace informačních systémů. Je spoluautorkou několika učebních textů, článků v časopisech a příspěvků na konferencích.

Ing. Zuzana Šedivá, Ph.D.

Zuzana Šedivá vystudovala obor Automatizované systémy řízení na Fakultě informatiky a statistiky na Vysoké škole ekonomické v Praze, kde od absolvování působí na Katedře informačních technologií. V pedagogické práci i ostatních odborných aktivitách se zaměřuje především na oblast aplikací grafických dat, vizualizaci a analytické úlohy v BI. Současně svou odbornost rozvíjí v oblasti podpory informačních technologií ve vzdělávání. Kromě krátkodobých praktických projektů, kterých se zúčastnila, spolupracovala dlouhodobě s organizací OBSE v oblasti správy a řízení elektronických dokumentů.

Řekli o knize

Kniha je praktickým a kompletním průvodcem po světě tzv. Self Service Business Intelligence (SSBI) nástrojů. Praktickým proto, že se zaměřuje na reálné případy použití této technologie v kontextu řízení a plánování v menších a středních podnicích. Kompletním průvodcem je ve více směrech:

1.Kromě popisu vybraných nástrojů SSBI a způsobu jejich použití poskytuje také příslušnou teorii, zejména úvod do datového modelování, architekturu a postup návrhu datových skladů a metodiku využití nástrojů SSBI pro řízení a plánování.

2.Jednotlivé nástroje SSBI popisuje od jejich stažení přes instalaci, konfiguraci až pro reálné použití. Kniha nabízí sedm různých rozšířených a v praxi používaných nástrojů SSBI. Většina z nich je dostupná volně nebo v tzv. community edition. Čtenář si tak může udělat přesný obraz o nástrojích a způsobu práce s nimi a vybrat si ten, který mu nejvíce vyhovuje.

Kniha je napsaná velmi čtivě a srozumitelně, přináší i množství ilustrativních příkladů. Teoreticky laděný první oddíl je terminologicky konzistentní a dostatečně přesný pro pochopení problematiky, aniž by zabíhal do složitých detailů, které nejsou pro uživatele SSBI nástrojů potřebné.

Jsem přesvědčen, že knihu ocení široká skupina čtenářů z řad manažerů středních a menších firem, analytiků, zaměstnanců IT oddělení, kteří poskytují v podniku informační servis, stejně jako studenti ekonomických a technických oborů se specializací na informační systémy a management.

Další přidanou hodnotou knihy je její provázanost s portálem MBI (Management Byznys Informatiky). Jedná s o živý informační zdroj, do něhož přispívá řada specialistů na jednotlivé oblasti řízení a provozu IT a který poskytuje stále aktualizované a doplňované informace o operativním, taktickém a strategickém řízení IT v podniku. Právě tam tematika SSBI patří. Čtenář knihy tedy navíc dostává k dispozici další cenný informační zdroj.

Ing. Michal Valenta, Ph.D.České vysoké učení technické v Praze Fakulta informačních technologiíKatedra softwarového inženýrství

Podle studie společnosti Gartner (2017) je dnes penetrace BI nástrojů ve firmách na úrovni 30 %, tedy v průměrné organizaci pouze 30 % uživatelů aktivně používá některý z nástrojů BI. Pokud se navíc podíváme do historie před pěti lety, zjistíme, že před zavedením metod Self Service Business Intelligence (SSBI) byl tento ukazatel na úrovni 15–17 %. Lze tedy říct, že to jsou právě nástroje SSBI, které významně přispívají k většímu rozšíření nástrojů BI v organizacích.

Publikace přináší komplexní přehled oblasti jak v metodické rovině (oddíl A), tak na příkladu konkrétních nástrojů (oddíl B) a velice dobře funguje jako komplexní úvod do oblasti SSBI jak pro pracovníky a manažery, tak pro studenty oborů IT.

Oddíl A předkládá úvod do problematiky logickým přehledem základů nástrojů Business Intelligence od analytických databází přes budování datových skladů a vizualizační nástroje až po nástroje SSBI v jejich dnešní podobě.

Oddíl B čtenáře provede ukázkami sedmi vybraných nástrojů z kategorie SSBI, včetně reálných ukázek z uživatelského rozhraní, pracovních postupů při budování analytického modelu i vizualizačního rozhraní.

Za velmi přínosné považuji především propojení metodiky budování SSBI řešení v organizaci s metodikou MBI, která umožňuje čtenáři jednoduchou formou proniknout do logiky business procesů v organizaci. Lze konstatovat, že u nástrojů typu SSBI je jejich vhodné a pevné ukotvení do metodického rámce a procesů organizace kritickým faktorem jejich finálního úspěchu či neúspěchu.

V publikaci je několikrát akcentováno, že řešení typu SSBI nejsou z pohledu uživatele zcela nenáročné na technologické znalosti, naopak: vyžadují od uživatele určitý mentální posun z role příjemce reportů do role reálného správce dat a jejich business logiky. Právě zakotvení nástrojů SSBI v pevných pravidlech, jednotné metodice užití dat a také jednotné pravdě v rámci organizace představuje základní kámen SSBI řešení. Toto téma vnímám jako jeden z nejvýraznějších přínosů publikace, která může přispět ke skutečně efektivnímu použití SSBI nástrojů v organizaci. Pro čtenáře jsou užiteční a velmi příjemné i reálné postupy a doporučení v oblasti vizualizací v oddílu A, které jsou následně doplněné o postupy přímo v konkrétních nástrojích (oddíl B).

Z pohledu možného dalšího rozvoje publikace, resp. jejího případného pokračování bych doporučil následující oblasti:

⬛Zahrnutí návrhů na organizační kroky a změny procesů, které povedou k „udržitelnému rozvoji“ SSBI nástrojů ve firmě. Tedy kroky, které následují po vlastním nasazení SSBI nástrojů a mají za cíl zajistit jejich efektivní a dlouhodobé používání. Konkrétně může jít například o rozvoj nástrojů samostatně v jednotlivých útvarech, avšak pod jednotným metodickým vedením, sdílení definic KPI, zajištění odpovědnosti za kvalitu dat (data stewardship) atp.

⬛Rozšíření oblasti plánovacích a prediktivních SSBI nástrojů o přehled dalších nástrojů. Oblast plánovacích SSBI nástrojů je specifický trh, kde se setkávají standardní poskytovatelé SSBI s řešeními specializovanými čistě na oblast plánování či prediktivní logiky. Podle studie společnosti Gartner (2017) je tento segment nejrychleji rostoucí oblastí SSBI a do budoucna může zejména prediktivní SSBI výrazně posunout možnosti nasazení BI nástrojů v organizacích.

Publikaci vřele doporučuji všem čtenářům pro její výraznou přidanou hodnotu a pro skloubení metodiky a praxe SSBI do přehledného a logického celku. Současně bych chtěl kolektivu autorů poděkovat, protože podobná publikace na českém knižním trhu zatím chyběla.

Ing. Vladislav Štefaňák

Chief Executive Officer

MIBCON, a.s.

Úvodem

Business Intelligence (BI) představuje jednu z klíčových aplikací IT, která nejvýrazněji ovlivňuje celkovou kvalitu a výkonnost řízení podniků a jejich obchodních a dalších aktivit. Například průzkumy a analýzy společnosti Gartner ukazují, že investice do BI představují celosvětově a dlouhodobě nejvyšší investiční prioritu podniků do IT. Je to dáno zejména rozsáhlými možnostmi BI při podpoře analytických, plánovacích i rozhodovacích aktivit a jejího vlivu na celkovou úspěšnost a konkurenceschopnost firmy.

Výrazným vývojovým proudem v rámci Business Intelligence je uplatňování postupů, nástrojů a aplikací charakterizovaných termínem Self Service Business Intelligence (SSBI), resp. samoobslužná Business Intelligence. V tomto textu používáme první z uvedených termínů. Zatímco původní standardní komplexní systémy se vyznačují celopodnikovým záběrem, obrovskými objemy dat, vysokou složitostí řešení a vysokými náklady, řešení Self Service Business Intelligence jsou zaměřená zejména na individuální potřeby uživatelů nebo jejich menších skupin. Tato řešení jsou založena – oproti standardním BI systémům – také na odlišné škále produktů a nástrojů (např. Power BI, PowerPivot, Tableau, Qlik Sense atd.). Základní principy řešení, analýza a návrh SSBI aplikací jsou však v mnoha směrech obdobné jako u komplexní BI. V tomto kontextu se také často zdůrazňuje, že aplikace SSBI je třeba vesměs chápat jako efektivní doplněk komplexních BI systémů, nikoli jako jejich náhradu.

Tato publikace se primárně orientuje na řešení a nástroje kategorie SSBI, a to jak na jejich analytickou část, tak na implementační. S ohledem na silné vazby na komplexní BI systémy postihuje také jejich základní principy, komponenty a postupy řešení. Kniha je určena IT analytikům i uživatelům (podnikovým specialistům, manažerům), kteří mají zájem samostatně připravovat vlastní analytické a plánovací aplikace, případně se na jejich přípravě a vývoji aktivně podílet. Je rovněž určena studentům, a to jak těm z IT oborů, tak i z ostatních ekonomicky nebo manažersky zaměřených oborů.

Cílem knihy je poskytnout komplexní pohled na přípravu a realizaci zmíněných typů aplikací, resp. úloh spadajících do oblasti označované jako „business analytics“. Strukturu celého textu dokumentuje obrázek na následující straně.

Struktura textu knihy

Příprava a realizace aplikací BI i SSBI (stejně jako i naprosté většiny ostatních) vyžaduje většinou kombinaci tří druhů znalostí:

⬛věcných: znalosti obsahu podnikání, podnikových procesů a funkcí, systémů ukazatelů a jejich analytických hledisek,

⬛metodických: znalosti postupů řešení a možností metod, které se v dané oblasti používají (dimenzionální modelování, datové modelování a další),

⬛technologických: znalosti funkcionality a způsobů využití softwarových nástrojů pro implementaci aplikací (např. Power BI, Tableau atd.).

Na tyto požadavky se snaží reagovat i tato kniha. Problém ale spočívá v tom, že rozsah k tomuto účelu důležitých informací je značný, přičemž uživatel je potřebuje v různých okamžicích řešení, v různém rozsahu a na různé úrovni detailu. K tomu se ještě váží změny přicházející především v technologické rovině řešení, tedy v dostupných nástrojích. Z těchto důvodů jsme se rozhodli provázat text knihy s informacemi na portálu MBI (Management Byznys Informatiky), který najdete na adrese http://mbi.vse.cz.

Poslední informací vážící se k obsahu a organizaci celé publikace je vymezení použitých formálních standardů, zejména piktogramů, které uvozují standardní části jednotlivých kapitol:

Účel kapitoly nebo části textu.

Vymezení nebo definice nejdůležitějších pojmů.

Příklady.

Diskuse, doporučení, praktiky.

Shrnutí kapitoly nebo vybrané části textu.

Oddíl A: Business Intelligence (BI) a Self Service Business Intelligence (SSBI)

První oddíl je zaměřen na společné charakteristiky analytických a plánovacích úloh v podnikovém řízení a na jejich řešení. V návaznosti na to poskytuje obecně pojaté informace o aplikacích a nástrojích jak pro úlohy Business Intelligence, tak Self Service Business Intelligence. Oddíl má odpovědět na tyto otázky:

1.Jaké jsou specifické charakteristiky analytických a plánovacích úloh v podniku na rozdíl od ostatních, zejména transakčních?

2.Jaké jsou používané metody při řešení aplikací pro analytické a plánovací úlohy?

3.Co je podstatou datového modelování a jak se využívá při řešení analytických a plánovacích aplikací?

4.Co je podstatou dimenzionálního modelování, jaké jsou hlavní charakteristiky tabulek faktů a dimenzionálních tabulek a jejich vzájemných vazeb?

5.Jaké jsou současné možnosti vizualizace a prezentace dat v analytických a plánovacích aplikacích, tedy možnosti využití různých typů grafů, map, dashboardů apod.?

6.Jaké jsou principy aplikací a technologií komplexních Business Intelligence systémů, jaké jsou možné přístupy a postupy řešení v této oblasti?

7.Jaké jsou podstatné charakteristiky aplikací a nástrojů Self Service Business Intelligence, jaké jsou doporučené postupy řešení v této oblasti?

1.Podstata a principy analytických a plánovacích úloh

Analytické a plánovací úlohy, označované též jako Business Analytics, představují disciplínu a společný termín pro podnikové analýzy, plánování, dolování dat, prediktivní analýzy a další úlohy a možnosti podporující a zvyšující kvalitu podnikového řízení a rozhodování. Standardně se tyto funkce realizují na základě ukazatelů (resp. faktů, metrik) a podle zvolených hledisek, resp. dimenzí. Business Intelligence již po několik desítek let, Self Service Business Intelligence nyní dává těmto principům systematičnost, provázanost a odpovídající technologickou základnu. Základem jejich řešení je tzv. dimenzionální modelování orientované na určení požadovaných ukazatelů a jim odpovídajících dimenzí a jejich podstatných charakteristik. Předpokladem pochopení a řešení dimenzionálních modelů je datové modelování, a proto mu jako východisku pro další kapitoly věnujeme úvodní část tohoto textu. Cílem kapitoly je vymezit principy datových a dimenzionálních modelů a určit funkce zejména analytických a plánovacích úloh v podnikovém řízení a s tím i požadavky na řešení aplikací BI i SSBI. Jedním z velmi podstatných požadavků na tyto aplikace je vysoká úroveň prezentace dat, využití nejrůznějších typů grafů a schémat, které by měly přispívat k co nejrychlejší orientaci uživatele v analytických tabulkách, reportech apod. Proto je poměrně rozsáhlá část textu věnovaná možnostem vizualizace a prezentace dat jak v aplikacích BI, tak SSBI.

Doplňující informace jsou dostupné na webu MBI. Kromě toho příloha obsahuje komplexní příklad využitý zejména při prezentaci jednotlivých produktů v kapitolách 5–11. V rámci této kapitoly využíváme také několika zjednodušených dílčích příkladů pro objasnění podstaty analytických a plánovacích operací.

Analytické aplikace (BI i SSBI) nevytvářejí nebo většinou nepořizují nová data, ale využívají data vytvořená transakčními aplikacemi (ERP, CRM atd.). Databáze transakčních aplikací se proto označují jako zdrojové. Podstatnou vlastností těchto databází je taková organizace jejich dat, která podporuje přístupy k detailním datům, ukládání a aktualizace dat. Databáze jsou pro tyto operace optimalizované. Oproti tomu analytické BI a SSBI aplikace jsou optimalizované na efektivní poskytování analytických informací, tedy data zde musí být organizována ve shodě s potřebami analytických úloh a musí obsahovat hodnoty ukazatelů ve vazbě na analytická hlediska, tedy dimenze. Z toho také vyplývá, že mezi zdrojovými databázemi a analytickými databázemi probíhá transformace dat (viz obrázek 1.1). Analytické databáze mají v prostředí Business Intelligence formu datových skaldů, datových tržišť, případně OLAP databází (viz kapitolu 3), v prostředí Self Service BI disponují jednotlivé produkty vlastními technologickými nástroji pro uložení a správu analytických dat (viz kapitoly 5–11).

Obrázek 1.1 Transformace dat ze zdrojových do analytických databází

Kvalitní a efektivní návrh analytických databází je předmětem datového a dimenzionálního modelování. Jejich hlavním úkolem je vytvořit základní logiku uložení a uspořádání dat tak, aby vyhovovala požadavkům na analytické a plánovací aplikace, a vytvořit flexibilní datový model, který bude plně podporovat rozsah podnikových analýz a plánování, a to jak aktuálně požadovaných, tak očekávaných v budoucím období.

Je dobré zdůraznit, že při řešení Business Intelligence i Self Service Business Intelligence je předpokladem znalost datového i dimenzionálního modelování, a to nejen u IT analytiků a vývojářů, kde se běžně předpokládá, ale i u uživatelů. Mají-li se uživatelé na těchto řešeních podílet (a v případě SSBI je pokud možno i samostatně implementovat), pak jsou tyto základní znalosti nezbytné.

1.1Datové modelování

Datové modelování je metoda, která podle názvu slouží k navrhování struktury dat v databázích a k jejich dokumentaci. Účelem datového modelování je přispívat ke kvalitnímu návrhu databází (jak transakčních, zdrojových, tak v daném kontextu zejména analytických), což znamená, že:

Databáze jsou konstruovány efektivně s minimalizací redundancí dat (tedy jejich duplicit, či multiplicit), se zajištěním požadovaného výkonu a doby odezvy při nejčetnějších dotazech a dalších operacích.

▪Databáze se navrhují tak, aby poskytovaly data uživatelům, která odpovídají jejich aktuálním požadavkům, ale i požadavkům, které lze v budoucnu očekávat. To znamená tak, aby bylo databáze možné relativně bezpečně rozšiřovat, udržovat a modifikovat. Úpravy databáze nesmí znamenat nepřiměřená rizika pro kvalitu dat.

▪V relační databázi je řešena integrita na úrovni položek (atributů), tabulek i vazeb mezi tabulkami zajišťující přesnost a konsistenci uložených dat po celou dobu provozu,

▪Aplikace postavené na databázi lze pak řešit efektivně a návrh databáze neznamená významné omezení pro jejich další údržbu a rozvoj.

V dalších částech této podkapitoly nemůžeme postihnout celou šíři otázek a postupů datového modelování (k tomu slouží rozsáhlá specializovaná literatura), ale pokusíme se vystihnout pouze nejdůležitější principy a termíny potřebné pro řešení BI i SSBI projektů i jako nezbytný základ pro pochopení dimenzionálního modelování, které je obsahem další podkapitoly.

Datové modelování tak, jak ho budeme dále prezentovat a využívat, je spojené obvykle s relačními databázemi. S ohledem na další text je proto účelné zde rekapitulovat pouze několik základních termínů.

Relace je dvourozměrná datová struktura představovaná tabulkou, kde jeden řádek tabulky odpovídá jednomu záznamu (například jednomu záznamu zboží) a sloupec odpovídá položce (například ID zboží, Název, Jednotková cena atd.). V databázovém pojetí se sloupec tabulky označuje jako atribut, jehož hodnoty spadají do tzv. domény. Příklad části takové databáze zachycuje obrázek 1.2. Z obrázku je patrné, že databázi tvoří pět relací, resp. tabulek. Relace (tabulka) Zboží, Adresa a Objednávka se označují jako entitní relace, relace Adresa objednatele a Detail objednávky popisují vztah mezi entitními relacemi a jsou proto označovány pojmem relace vztahová (asociativní).

S databází je spojena také integrita, což je pravidlo omezující možné hodnoty atributů, případně možné manipulace se záznamy, které existují ve vazbě k záznamům jiné tabulky. K významným integritním omezením patří existence primárního klíče (tzv. entitní integrita). Tím se zajišťuje jednoznačná identifikace záznamu v tabulce (žádné dva záznamy nemohou mít stejnou hodnotu primárního klíče). V příkladu (viz obrázek 1.2) jsou položky, které hrají roli primárního klíče, označeny symbolem klíče. Primární klíč může vzniknout i jako kombinace hodnot zvolených atributů, která se pak označuje jako složený klíč. Příkladem primárního klíče může být Číslo objednávky v tabulce Objednávka. S termínem primární klíč souvisí i umělý primární klíč (surrogate key), který nemá nějaký specifický podnikový význam (například ID zboží), ale vzniká postupným načítáním stanovené hodnoty (většinou 1) při přidávání dalších záznamů do tabulky databáze.

Další typ integritního omezení je doménová integrita, která zajišťuje, aby údaj uvedený jako hodnota atributu byl vybrán z množiny definovaných přípustných hodnot. Například pro sloupec (doménu) Typ adresy v tabulce Adresa objednatele může být takovým doménovým omezením možnost uvedení buď hodnoty Fakturační, nebo hodnoty Dodací.

Obrázek 1.2 Tabulky a jejich vazby v relační databázi (Zdroj: Gála a kol.: Podniková informatika, Grada Publishing, 2009)

Posledním typem integritního omezení je tzv. referenční integrita, která je reprezentována cizím klíčem (foreign key). Cizí klíč zajišťuje provázanost tabulek, například mezi tabulkou Zboží a Detail objednávky je cizím klíčem ID zboží umístěný v tabulce Detail objednávky. Na obrázku je položka, která je cizím klíčem označena zkratkou FK. Princip referenční integrity zajišťuje:

⬛Aby nemohla být vložena jako hodnota atributu, který je označen jako cizí klíč, hodnota, jež nemá odpovídající hodnotu atributu v tabulce, jejíž klíč jako cizí uvádíme. Tak je například zajištěn vztah mezi tabulkou Objednávka a Detail objednávky, kdy platí, že v tabulce Detail objednávky se jako hodnota atributu Číslo objednávky nesmí objevit jiné číslo než to, které je uvedeno u některého ze záznamů v tabulce Objednávka.

⬛Aby z tabulky nebylo možné odstranit záznam, jehož hodnota je uvedena jako cizí klíč v tabulce jiné. To například znamená, že nelze odstranit záznam z tabulky Zboží, jehož ID zboží je rovno 1, protože se tato hodnota vyskytuje jako hodnota cizího klíče v tabulce Detail objednávky.

⬛Uvedené základní principy relačních databází se promítají do řešení datových modelů. Návrh datových modelů se realizuje na několika úrovních, resp. v několika základních krocích. Tyto kroky postupují obvykle od konceptuálního návrhu přes logický až k fyzickému.

1.Konceptuální návrh databáze: Prvotní návrh databáze, tedy její struktury, vazeb a všech potřebných charakteristik, obvykle začíná na konceptuální úrovni. Ta je zaměřena na věcnou podstatu dat a nezohledňuje fyzické, resp. technologické charakteristiky databáze, ale pouze její požadovanou strukturu a logiku uspořádání dat, které jsou nezávislé na konkrétním softwaru pro řízení databáze. Účelem konceptuálního návrhu databáze je specifikovat typy datových objektů (typy entit), jejich vlastnosti (atributy), přirozenou identifikaci, vazby mezi entitami a jejich vlastnosti. V konceptuálním modelu se v entitách nemodelují cizí klíče, vazby mezi entitami jsou vyjádřeny pouze graficky.

2.Logický návrh databáze: Na základě konceptuálního návrhu databáze se řeší logický návrh databáze, jehož cílem je detailně vymezit strukturu databáze založené již na určitém logickém schématu dat, v našem případě relačním. Tedy především definovat struktury databázových tabulek, jejich atributy, primární klíče a relace mezi tabulkami prostřednictvím cizích klíčů.

3.Vytvoření, případně generování fyzického návrhu databáze: Na základě logického návrhu databáze se definuje fyzický datový model, který specifikuje již potřebné implementační charakteristiky ve vztahu k příslušnému databázovému prostředí, v němž bude databáze realizována. Tím se myslí například formáty jednotlivých datových položek, jejich rozsah, resp. délka, definování cizích klíčů a vztahů mezi tabulkami a další charakteristiky.

Datové modely budou jednou ze součástí řešení dimenzionálních modelů v dalších částech kapitoly a následně budou prezentovány v souvislosti s jednotlivými produkty SSBI (viz kapitoly 5–11). V souvislosti s datovým modelováním je ještě třeba vymezit tyto termíny:

⬛Entita představuje z pohledu konceptuálního datového modelu dále nedělitelnou jednotku reálného světa, o které se budou v databázi vést příslušná data. V databázi obvykle entitě odpovídá jeden řádek v databázové tabulce. Typ entity pak představuje zobecnění pro všechny entity se stejnými vlastnostmi (například typem entity je Zákazník a entitou je jeden každý zákazník). Typu entity odpovídá v databázi jedna databázová tabulka. Typ entity má vlastní název, identifikátor a její obsah je dále definován skupinou atributů, které jsou následně, v rámci logického návrhu databáze, základem pro definování struktury databázové tabulky. (Entita a Typ entity se oba běžně používají pro termín „typ entity“, Výskyt pak pro jednu konkrétní entitu, tedy data o konkrétním sledovaném objektu.)

⬛Vazby se definují mezi dvěma entitami použitím symbolu vazby s doplněním názvu vazby a dalších jejich charakteristik, včetně kardinality.

⬛Kardinalita vazby (násobnost a povinnost) znamená vyjádření možnosti výskytu počtu entit na obou stranách vazby. Existují základní vztahy 1 : 1, 1 : M, M : N. Tedy pro vazbu 1 : M (One to Many) to znamená, že například jeden obchodník odpovídá za více objednávek zboží a jedna objednávka zboží je vyřizována pouze jedním obchodníkem. Pokud bychom danou vazbu definovali vztahem M : N (Many to Many), pak to bude znamenat, že jeden obchodník vyřizuje více objednávek, ale na druhé straně se na jedné objednávce může podílet více obchodníků. Povinnost vazby pak vyjadřuje nutnost existence dané vazby ke každému výskytu entity, například obchodník nemusí být odpovědný za žádnou objednávku, ale objednávka musí mít obchodníka, který je za ní odpovědný.

⬛Normalizace databáze: Normalizace databáze se chápe jako postup, kdy je struktura dat v relační databázi přeorganizována tak, aby byly minimalizovány duplicity nebo multiplicity uložení dat v databázi tak, aby ideálně jedna změna v realitě vyžadovala pouze jednu změnu v datech v databázi (viz dále).

S databázemi a datovým modelováním je spojena celá škála dalších termínů a pravidel, o nichž je řeč v různé specializované literatuře, například HERNANDEZ, M. J. (2006), KIMBALL, R., ROSS, M. (2010), PROVOST, F., FAWCETT, T. (2013), ale jako předpoklad pro další text zůstaneme zatím pouze u výše vybraných.

1.2Dimenzionální modelování

Uplatnění dimenzionálního modelování je předpokladem pro naplnění účelu analytických aplikací (BI i SSBI), tedy:

⬛Prezentovat uživatelům potřebné informace co nejjednodušším způsobem.

⬛Poskytovat odpovědi na dotazy s minimální dobou odezvy.

⬛Zajišťovat relevantní informace přesně odpovídající definovaným podnikovým procesům nebo úlohám.

Dimenzionální modely a na nich postavené aplikace jsou pak pro uživatele mnohem pochopitelnější než normalizované modely pro transakční aplikace.

Dimenzionální modelování vychází z poznání a zhodnocení potřeb řízení dané organizace. Jeho obsahem je:

▪Vymezení všech dimenzí, jejich obsahu, včetně vnitřní hierarchie prvků, a dílčích charakteristik jednotlivých dimenzí.

▪Určení soustavy sledovaných ukazatelů (faktů nebo metrik) a jejich dílčích charakteristik.

▪Specifikace vazeb mezi ukazateli a odpovídajícími dimenzemi.

Uložení dat a operace s nimi jsou zde založeny na multidimenzionalitě, a to vhodným řešením organizace dat, resp. databázových schémat (viz obrázek 1.3).

V centru schématu je tabulka faktů, tedy tabulka sledovaných hodnot ekonomických a dalších ukazatelů (Prodej_Trzby, Prodej_Naklady) identifikovaných klíčem složeným z cizích klíčů dimenzionálních tabulek (Zbo_Id, Reg_Id, Cas_Id), nebo vlastním umělým primárním klíčem. Cizí klíče potom slouží pouze pro vazby do dimenzionálních tabulek. Tabulka faktů se tak váže na dimenzionální tabulky, tabulky faktů se ale neváží na jiné faktové tabulky.

Dimenzionální tabulky slouží jako úložiště vlastností, tedy popisných a doplňujících informací o hodnotách ukazatelů uložených v tabulce faktů. Například k číslu zákazníka v tabulce faktů jsou v dimenzionální tabulce obsaženy všechny potřebné informace o zákazníkovi s odpovídajícím číslem. Většinou si dimenzionální tabulku lze představit jako číselník. Pro reálné dimenzionální tabulky je ale typické velké množství atributů, pro něž se nejlépe hodí atributy textové a diskrétní.

Uvedené schéma na obrázku 1.3 představuje vybranou část souhrnného příkladu, který je podrobněji popsaný v příloze.

Obrázek 1.3 Multidimenzionální uložení dat

1.2.1Dimenzionální modelování – hrubý dimenzionální model

Výsledné dimenzionální modely by měly vytvořit potřebný základ pro realizaci analytických aplikací, a to s těmito vlastnostmi:

⬛Jejich výsledná podoba je relativně jednoduchá, založená na určité symetrii a standardech (fakta – dimenze), což umožňuje poměrně dobrou a rychlou orientaci v logice řešení jak informatikům, tak uživatelům.

⬛Jednoduchost řešení nabízí i lepší možnosti zvyšování provozního výkonu aplikací.

⬛Jednoduchost a přehlednost je rovněž základem i pro snadnější úpravy a rozšiřování obsahu řešení, tedy doplňování nových dimenzí, atributů apod.

Podstatou hrubého dimenzionálního modelu je vymezit obsah řešených BI a SSBI aplikací bez ohledu na jejich technickou realizaci v konkrétní databázi. Součástí řešení je i stanovení granularity, tedy úrovně detailu sledovaných hodnot v analytické databázi. Ta by měla být co nejvyšší, aby bylo možné realizovat co nejpodrobnější analytické operace. Na druhé straně je nutné při dané granularitě odhadnout objem databáze a její očekávaný růst. Znamená to určit formou běžného textu nebo s použitím tabulek, matic, případně specifických schémat následující:

1.Dimenze, s jejichž pomocí se budou ukazatelé analyzovat.

2.Ukazatele (fakta, metriky), která budou v aplikaci sledována a analyzována.

3.Vazby ukazatelů a dimenzí, tedy který ukazatel se bude analyzovat podle kterých dimenzí.

V následujícím textu jsou uvedeny charakteristiky dimenzí i ukazatelů, jež má obsahovat hrubý dimenzionální model. I v tomto případě je nutné zdůraznit možnosti modifikace nebo redukce jeho obsahu. Řada charakteristik totiž vychází z potřeby sladění představ o výsledných řešeních mezi širokou škálou uživatelů, což je typické zejména pro komplexní systémy Business Intelligence. Na druhé straně aplikace zaměřené pouze na individuální potřeby jednotlivců rozsáhlou dokumentaci dimenzionálních modelů někdy nepotřebují. Je proto na úvaze konkrétních uživatelů i IT analytiků, v jakém rozsahu a podrobnosti budou hrubé dimenzionální modely tvořit.

V případě návrhu ukazatelů se určují tyto charakteristiky (podrobněji viz kapitolu 1.3):

⬛Jednoznačná identifikace ukazatele – například Prodej_Trzby – pro účely definování vazeb ukazatele na jednotlivé dimenze a dalšího navrhování tabulek faktů a datových modelů.

⬛Plný název ukazatele, například Tržby z prodeje v Kč.

⬛Obsahové vymezení a účel ukazatele – je dobré vymezit ukazatel co nejpřesněji a nejkonkrétněji tak, aby byl vytvořen podklad pro shodu mezi uživateli na jeho interpretaci.

⬛Zdroje dat pro ukazatel – z jakých databází nebo souborů lze hodnoty ukazatele získávat, případně je pořizovat manuálním způsobem, expertním odhadem apod.

⬛Kalkulace ukazatele – výpočty pro základní i související ukazatele.

⬛Typ, formát dat, například numerické, textové.

⬛Měrná jednotka – například Kč, % apod.

⬛Možnost agregace ukazatele, tedy aditivní (A), neaditivní (N), semiaditivní (S).

⬛KPI, tedy zda ukazatel představuje klíčový indikátor výkonnosti (Key Performance Indicator), nebo klíčový cílový indikátor byznysu (KGI, Key Goal Indicator).

⬛Vazby ukazatele na definované dimenze formou jednoduché matice.

V případě návrhu dimenzí se určují a dokumentují následující charakteristiky (podrobněji viz kapitolu 1.4):

⬛Identifikace dimenze – podle stanovených dohodnutých standardů, například DI_Zbozi.

⬛Plný název dimenze, například Zboží prodávané podnikem.

⬛Obsah, tedy podrobnější textové vyjádření obsahu dimenze tak, aby umožňovalo její sjednocené chápání mezi různými uživateli a analytiky.

⬛Typ dimenze, tedy zda jde o dimenzi časovou, STAR, SNOWFLAKE, degenerovanou (viz kapitoly 1.4.2 a 1.4.3).

⬛Zdroj dat pro dimenzi, resp. její prvky, například databáze DB_Zbozi, tabulka číselníku v Excelu, textový soubor apod.

⬛Struktura prvků dimenze, resp. jejich hierarchie tak, aby bylo zřejmé, v jaké celkové struktuře budou prvky dimenze uspořádány, samozřejmě bez jejich výčtu, ale s příklady:

(1)Kategorie zboží (například Audio a kino, Počítače, Monitory, Spotřební elektronika atd.).

(a)Skupiny zboží (například Auto hifi, Notebooky, Ledničky atd.).

(i)Jednotlivá zboží, zbožové položky, například (Autoradio Logik, Acer Aspire One A150 atd.).

⬛Atributy dimenze, tedy struktura záznamu dimenzionální tabulky, viz například tabulku 1.3.

⬛Doplňující poznámky k vytvoření a využití dimenze, vazby na legislativní nároky apod.

Na tomto místě jsme uvedli základní charakteristiky navrhované dimenze, které se podle potřeby v průběhu dimenzionálního modelování dále doplňují a zpřesňují.

Následující dvě tabulky dokumentují specifikaci jednotlivých dimenzí, ukazatelů a jejich vazby na dimenze.

Tabulka 1.1 Přehled dimenzí a jejich charakteristik

ID

Název

Obsah

Typ

Zdroj

Struktura(y)

Atributy

Poznámky

DI_Cas

Čas

Struktura časových jednotek pro sledování ukazatelů v časovém vývoji

časová

manuální

Rok – Kvartál – Měsíc

Rok – Měsíc – – Týden – Den

Cas_Id

Cas_rok,

…

Datová dimenze sleduje čas vzniku obchodu

DI_Regiony

Regiony

Regiony, kde podnik má své obchodní a další aktivity

SNOWFLAKE

DB: Obchod

Kontinent – Stát – – Region

Reg_Id Reg_Nazev Reg_…

DI_Pod_Utvary

Podnikové útvary

Organizační útvary – divize, oddělení – pro sledování obchodní výkonnosti útvarů

SNOWFLAKE

Organizační řád

Kategorie útvaru (například Obchod, Výroba atd.) – Útvar (například Prodej Audio, Prodej počítače atd.),

Utv_Id Utv_Kod Utv_Nazev Utv_….

Může zahrnovat i další organizační struktury

DI_Zakaznici

Struktura zákazníků

Struktura a podstatné charakteristiky zákazníků podniku

STAR

Controlling

Kategorie zákazníka – Zákazník

Nak_id_druhu Nak_nazev_druhu …

Lze doplnit i další členění zákazníků

DI_Zbozi

Zboží

Struktura položek zboží a služeb nabízených a prodávaných zákazníkům

STAR

DB: Zbozi

Kategorie zboží – Skupiny zboží – – Zbožové položky

Zbo_id Zbo_Kategorie_id …

Vychází z katalogu zboží

…

Tabulka 1.2 Přehled ukazatelů (faktů)

ID

Název

Obsah

Zdroj/Vyp

Typ, formát

Jednotka

Agregace

KPI

Dim.:

Cas

Reg

Utv

Zak

Zbo

…

Prodej_Trzby

Objem tržeb

Objem tržeb za prodané zboží a služby

DB: Ucetnictvi

Numeric (10,2)

tis. Kč

A

Ne

X

X

X

X

Prodej_Naklady

Objem nákladů

Objem veškerých nákladů spojených s prodejními aktivitami podniku

DB: Ucetnictvi

Numeric (10,2)

tis. Kč

A

Ne

X

X

X

X

Prodej_Reklamace

Počet reklamací

Počet reklamací od zákazníků na zboží a služby

CRM

Numeric (6,0)

reklamace

A

Ano

X

X

X

X

X

…

Podstatným aspektem této úrovně řešení je určení náplně dimenzí a jejich prvků, to znamená například jací konkrétní zákazníci budou naplňovat dimenzi DI_Zakaznici, jaká konkrétní zboží dimenzi DI_Zbozi apod., podle struktur definovaných v předchozí tabulce.

Jedním z problémů je však to, že vazby ukazatele s definovanými dimenzemi označenými v matici v buňkách příslušné řádky X musí mít adekvátní obraz ve zdrojových databázích. To znamená, že například hodnoty ukazatele Prodej_Trzby musí být identifikovány pomocí prvků všech uvedených dimenzí. Pokud tomu tak není, pak je hodnota ukazatele neúplně identifikována, musí být řešena například v rámci čištění a transformací dat, nebo specifickou funkcí databázového systému.

Speciální místo v modelu má časová dimenze, tedy jaká bude struktura časových intervalů (roky, kvartály, měsíce), zda těchto časových struktur bude současně více, zda se bude k aktuálnímu datu nějakým způsobem měnit (například na dekády, dny), zda se budou nějaké starší časové úseky přesouvat z provozního řešení do archivu (tzv. aging) apod.

Další aktivitou dimenzionálního modelování je analýza a návrh dimenzionálních modelů na bázi principů datového modelování. V návaznosti na hrubý dimenzionální model se upřesňuje obsah a vazby databázových tabulek dimenzí a faktů s určením běžných charakteristik (formátu, rozsahu) jejich jednotlivých atributů. Podstata a různé možnosti realizace tabulek faktů jsou dále obsahem podkapitoly 1.3, tabulek dimenzí pak podkapitoly 1.4. V souvislosti s produkty SSBI (kapitoly 5–11) je však dobré upozornit na to, že se často struktura tabulek vygeneruje automaticky při vstupu, resp. transformaci dat ze vstupních zdrojů, například z tabulky Excelu, zdrojových databázových tabulek apod. Minimálně konceptuální datový model je však účelné vždy udělat.

V rámci této fáze je třeba ještě znovu verifikovat, zda data pro navrhované dimenzionální modely jsou ve zdrojových databázích k dispozici a jsou kvalitní. Podstatou této aktivity je transformace výsledků hrubého dimenzionálního modelu do relačních databázových struktur. Příklad datového modelu pro analytickou aplikaci řízení prodeje dokumentuje obrázek 1.4.

Obrázek 1.4 Příklad – datový model pro BI a SSBI aplikace

1.2.2Návrh datového modelu pro SSBI

V dalších podkapitolách uvedeme podstatné charakteristiky hlavních součástí dimenzionálních modelů, tedy tabulek faktů, tabulek dimenzí a jejich vazeb.

1.3Tabulky faktů

Tabulka faktů uchovává hodnoty sledovaných ukazatelů a jsou pro ni podstatné vlastnosti, které budeme dokumentovat na následujícím příkladu obchodního podniku (viz tabulku 1.3). V souvislosti s ukazateli se používají i termíny fakta nebo metrika.

Tabulka 1.3 Příklad tabulky faktů

Zbo_Id

Reg_Id

Cas_Id

Prodej_Trzby

Prodej_Naklady

111

0105

030115

749 750.00

562 300.00

114

0107

030116

741 470.00

556 100.00

115

0121

030216

539 820.00

404 840.00

Zjednodušená struktura tabulky faktů může být následující:

⬛Zbo_Id: Identifikátor prodaného zboží.

⬛Reg_Id: Identifikátor regionu, místa, kde se zboží prodalo.

⬛Cas_Id: Identifikátor času, kdy se zboží prodalo.

⬛Prodej_Trzby: Tržby za prodané zboží (daného zboží, na daném místě a v daném čase).

⬛Prodej_Naklady: Náklady na prodané zboží (daného zboží, na daném místě a v daném čase).

Sloupce tabulky faktů jsou vesměs buď klíčové atributy (Zbo_Id, Reg_Id, Cas_Id), nebo hodnoty ukazatelů (Prodej_Trzby, Prodej_Naklady). Klíčové atributy reprezentují jednotlivé dimenze a jejich hodnoty jsou prvky těchto dimenzí, například 111 je prvkem dimenze Zboží.

Řádky v tabulce představují ve své podstatě jednotlivá měření (v obchodě, výrobě apod.) a většinou jsou přiřazována na co nejnižší úrovni detailu, tedy pouze na úrovni listů ve strukturách použitých dimenzí. Na odpovídající tabulky dimenzí tabulka faktů odkazuje prostřednictvím cizích klíčů, například Zbo_Id váže tabulku faktů na dimenzionální tabulku DI_Zbozi apod. Všechny cizí klíče reprezentující vazby do odpovídajících tabulek dimenzí tvoří v tomto případě složený klíč tabulky faktů, například Zbo_Id, Reg_Id, Cas_Id. Jinou možností je, že každý řádek tabulky faktů má vlastní, většinou umělý klíč, což je mnohdy s ohledem na riziko duplicit klíčů bezpečnější. Klíčové položky jsou vesměs celočíselného typu.

Příklad vazby tabulky faktů na tabulky dimenzí dokumentuje obrázek 1.3. Kardinalita vazeb tabulek dimenzí na tabulku faktů je vždy 1 : N. Tabulka faktů tak vlastně současně vyjadřuje vazby M : N mezi tabulkami dimenzí navzájem.

1.3.1Granularita v tabulce faktů

Granularita určuje úroveň podrobnosti údajů uložených v tabulce faktů. Granularita údajů v tabulce faktů je přímo závislá na počtu a úrovni podrobnosti dimenzí připojených k příslušné tabulce faktů. Například máme-li v časové dimenzi definovanou strukturu až na jeden den a v dimenzi DI_Zbozi na jeden dílčí produkt, pak každý záznam v tabulce faktů (grain, zrno) je na úrovni objemu prodeje jednoho dílčího zboží za jeden den. Tím je dána granularita tabulky faktů, obdobné je to i ve vztahu k ostatním dimenzím.

Nízká granularita (tedy nízká úroveň detailu uložených dat) znamená nemožnost pracovat s podrobnými daty, tedy podle dnů, jednotlivých zboží, regionů, prodejců apod. Naopak vysoká granularita (tedy vysoká úroveň detailu dat) možnosti detailních analýz nabízí, ale na druhé straně znamená i podstatně vyšší nároky na diskový prostor analytické databáze a jeho další provozní charakteristiky.

Pro řešení úrovně granularity existují některá obecná doporučení:

▪Pokud to technické kapacity dovolují, měla by být data uložena s nejvyšší možnou granularitou.

▪Data vstupující do analytické databáze z různých zdrojů je účelné transformovat na stejnou nebo srovnatelnou granularitu.

V případě druhého uvedeného doporučení existují v praxi určité problémy a s nimi spojené analytické úlohy. Typickým příkladem mohou být data získávaná z obchodních objednávek, faktur apod. Některé údaje (fakta) se mohou vázat k objednávce jako celku (takzvaně k její hlavičce, například náklady na dopravu), a některé k jednotlivým objednávaným zbožovým položkám (například hodnota dodávky příslušného zboží). Jde evidentně o různou granularitu uvedených dat.

Úlohou analytika je převést tyto údaje na stejnou – vyšší – granularitu, tedy v našem případě rozpočítat náklady na dopravu na jednotlivé zbožové položky. Tato operace se v dimenzionálním modelování označuje jako alokace (nikoli pouze nákladů, jak je známá z ekonomických disciplín). Při řešení této úlohy je však nutné nejprve rozhodnout, zda je taková alokace možná, zda má smysl a současně posoudit, kdo z uživatelské (byznys) sféry se na formulaci pravidel pro alokaci bude podílet. Pokud se alokace ukáže jako neúčelná, pak souhrnné hodnoty (například dopravné) musí vytvořit samostatnou agregovanou faktovou tabulku. Nedoporučuje se kombinovat fakta s různou granularitou do jedné faktové tabulky.

1.3.2Typy tabulek faktů

V analytických databázích existují tři hlavní typy tabulek faktů vzhledem k jejich granularitě dat.

Transakční tabulky faktů jsou založeny na tom, že detailní informace vstupující do analytické databáze jsou vázány na jednotlivé transakce a pohybují se na nejvyšší možné granularitě dat. Z toho vyplývá, že časový úsek nebude stejný, ale bude záviset na době výskytu jednotlivých transakcí. Je potom vhodné rozdělit časovou dimenzi na „den“ a „čas“, tedy čas jednotlivých transakcí v rámci dne. Transakční tabulky faktů patří v praxi k těm často využívaným.

Periodické snímkované tabulky faktů jsou v praxi nejpoužívanější. Data vstupují do datového skladu v pravidelných, předem definovaných časových úsecích (snímcích, například dnech) a vyjadřují souhrnné hodnoty ukazatelů za celý časový snímek (například celkový objem transakcí za daný časový úsek). Tento typ tabulek se nejvíce využívá i pro odhadování, resp. predikci trendů vybraných ukazatelů. Návrh periodických snímkovaných tabulek se obvykle úzce váže na návrh transakčních tabulek faktů a sdílejí většinu společných dimenzí. Volba časového úseku pak samozřejmě ovlivňuje nejen granularitu, ale i nárůst objemu dat v datovém skladu.

Akumulované (též někdy stavové) snímkované tabulky faktů jsou rovněž závislé na výskytu transakcí, ale jejich hodnoty se v čase postupně aktualizují. Například při postupném objednávání zboží na sklad se tak udržuje přehled o aktuálním stavu a vývoji dané objednávky. Tyto tabulky se v praxi využívají méně často.

Souhrnné porovnání jednotlivých typů tabulek faktů dokumentuje tabulka 1.4.

Tabulka 1.4 Porovnání typů tabulek faktů (zdroj: Kimball, Ross, 2010)

Charakteristika

Transakční

Periodická snímkovaná

Akumulovaná snímkovaná

Časová perioda

Časový okamžik (čas transakce)

Pravidelné, předem určené intervaly

Nedefinovaný časový rozsah

Granularita

1 záznam = 1 transakce

1 záznam = 1 časový interval

1 záznam (postupně aktualizovaný)

Plnění (load) tabulky faktů

Přidávání záznamů (Insert)

Přidávání záznamů (Insert)

Přidávání záznamů (Insert) a aktualizace (Update)

Aktualizace záznamů tabulky faktů

Nerealizuje se

Nerealizuje se

Realizuje se vždy při změně

Časová dimenze

Datum transakce

Datum konce časového intervalu

Více kalendářních dat pro standardní provádění změn

Fakta (ukazatele)

Obsah transakční aktivity

Obsah odpovídající definovanému časovému intervalu

Obsah odpovídající celému životnímu cyklu dat

1.3.3Agregace dat

Značná část dotazů do analytické databáze směřuje na agregovaná data, například kolik se prodalo zboží X za první čtvrtletí v daném regionu. Jestliže máme uložena fakta v granularitě odpovídající dnům, pak je pro získání výsledku tohoto dotazu třeba sečíst jednotlivé prodeje podle zadaných kritérií. Z toho plyne významná vlastnost údajů v tabulce faktů, tedy jejich možností agregací. Data v tabulkách faktů se podle toho rozdělují na:

⬛Plně aditivní, u nichž lze prakticky vždy získat smysluplné agregované údaje podle všech využitých dimenzí, například u hodnot Prodej_Trzby, Nakup_Objem apod.

⬛Neaditivní, v tomto případě nemají agregované hodnoty smysl, například Sazba_Marze_ %, a nahrazují se v agregacích počty jejich hodnot nebo průměrnými hodnotami.

⬛Semiaditivní agregované hodnoty mají smysl pouze podle určitých dimenzí, například u položky Zasoba_Ks mají agregace smysl podle dimenze zboží, ale nikoli v čase. Místo agregovaných hodnot se v tomto případě používají průměrné hodnoty za určitá časová období.

Tuto charakteristiku je tedy nutné brát vždy pozorně v úvahu, aby aplikace nebo dotazy do databází poskytovaly smysluplné výsledky. Nejpoužívanějšími ukazateli v tabulkách faktů jsou tak numerické a plně aditivní ukazatele.

1.3.4Měrné jednotky

Tabulky faktů obsahují ukazatele, které potřebují různí uživatelé sledovat v různých měrných jednotkách, například počty vyrobených produktů v kusech, v tisících, krabicích, v paletách apod. Nabízejí se dvě možnosti: buď umístit jednotky a přepočítací koeficienty například do produktové dimenze, nebo je umístit přímo do jednotlivých záznamů tabulky faktů. S ohledem na riziko chyb a možné změny v koeficientech se doporučuje využívat spíše druhou variantu, tedy umisťovat je do záznamů tabulky faktů.

1.3.5Rozsah tabulky faktů

Tabulky faktů zabírají v datovém skladu obvykle kolem 90 % jeho celkové kapacity (oproti cca 10 % tabulek dimenzí). Je pro ně charakteristické, že tento rozsah je dán obrovským počtem jejich řádků, záznamů (například pro každý prodej, každý telefonní hovor apod.). Na druhé straně proto existuje snaha omezit jejich rozměr co do počtu sloupců a rozsahu jednotlivých sloupců. Dalším způsobem řešení je určení granularity dat podle období, například pro posledních aktuálních 60 dnů se využije denní granularita tabulky faktů, pro starší období pak granularita nižší.

1.3.6Zdroje a kalkulace ukazatelů

Tabulka faktů obsahuje základní, elementární hodnoty ukazatelů vstupující ze zdrojových databází i hodnoty kalkulované, tedy v tomto případě kalkulace v rámci jednoho záznamu (například Prodej_Zisk = Prodej_Trzby – Prodej_Naklady). Kalkulace se mohou provádět na úrovni transformací dat, analytické databáze, nebo na úrovni analytických aplikací. Obvykle je užitečné u aditivních faktů ukládat kalkulované hodnoty přímo do analytické databáze, neboť se tak zajistí dostupnost těchto dat všem uživatelům, bez nutnosti kalkulace opakovat v různých aplikacích. Oproti tomu stojí někdy fakt, že výpočty v analytických nástrojích (Excel atd.) mohou být jednodušší.

1.3.7Tabulky faktů bez ukazatelů

Dimenzionální modely obsahují i tzv. tabulky faktů bez ukazatelů, faktů (factless fact table), které nemají žádné ukazatele a využívají se například pro zjišťování počtu určitých událostí. To znamená, že každý výskyt záznamu v tabulce faktů s daným složeným klíčem indikuje vznik události: například daná činnost je součástí procesu, zboží bylo zařazeno do marketingové akce apod. U nich lze pak sledovat souhrnné hodnoty pouhou sumarizací počtu záznamů v členění podle klíče.

Při řešení tabulek faktů jde – kromě uvedených principů – také o obsahové vymezení relevantních ukazatelů (faktů, metrik) pro příslušné úlohy nebo procesy v podnikovém řízení. Jejich přehled by překračoval zaměření této knihy, a proto odkazujeme na web MBI (http://mbi.vse.cz, volba Metriky), kde najdete jejich charakteristiky, včetně vazeb na příslušné úlohy a dimenze.