VYSOKÉ UČENÍ TECHNICKÉ V BRNĚBRNO UNIVERSITY OF TECHNOLOGY
FAKULTA PODNIKATELSKÁFACULTY OF BUSINESS AND MANAGEMENT
ÚSTAV INFORMATIKYINSTITUTE OF INFORMATICS
TVORBA DATOVÉHO SKLADU A REPORTOVACÍCHSLUŽEBCREATION OF DATA WAREHOUSE AND REPORTING SERVICES
DIPLOMOVÁ PRÁCEMASTER'S THESIS
AUTOR PRÁCEAUTHOR
Bc. Andreas Zduba
VEDOUCÍ PRÁCESUPERVISOR
Ing. Jiří Kříž, Ph.D.
BRNO 2016
Vysoké učení technické v Brně Akademický rok: 2015/2016Fakulta podnikatelská Ústav informatiky
ZADÁNÍ DIPLOMOVÉ PRÁCE
Zduba Andreas, Bc.
Informační management (6209T015)
Ředitel ústavu Vám v souladu se zákonem č.111/1998 o vysokých školách, Studijním azkušebním řádem VUT v Brně a Směrnicí děkana pro realizaci bakalářských a magisterskýchstudijních programů zadává diplomovou práci s názvem:
Tvorba datového skladu a reportovacích služeb
v anglickém jazyce:
Creation of Data Warehouse and Reporting Services
Pokyny pro vypracování:
ÚvodCíle práce, metody a postupy zpracováníTeoretická východiska práceAnalýza současného stavuVlastní návrhy řešeníZávěr Seznam použité literaturyPřílohy
Podle § 60 zákona č. 121/2000 Sb. (autorský zákon) v platném znění, je tato práce "Školním dílem". Využití této
práce se řídí právním režimem autorského zákona. Citace povoluje Fakulta podnikatelská Vysokého učení
technického v Brně.
Seznam odborné literatury:
GENDRON, M. S. Business Intelligence and the Cloud. Hoboken: John Wiley & Sons, 2014.Inc.HOFFMAN, J. Business Intelligence: Empower Your Users with Business Intelligence.technet.microsoft.com[online]. 2010 [cit. 2015-10-12]. Dostupné z:ttps://technet.microsoft.com/en-us/magazine/gg405051.aspxKEN, W. Microsoft Business Intelligence FOR DUMMIES. Hoboken: Wiley Publishing, 2010.Inc.KIMBALL, R. a M. ROSS. The Data Warehouse Toolkit. Indianapolis: John Wile & Sons, 2013.Inc.LIEBOWITZ, J. Strategic intelligence: business intelligence, competitive intelligence, andknowledge management. New York: Auerbach Publications, 2006. 223 s. ISBN 0-8493-9868-1.
Vedoucí diplomové práce: Ing. Jiří Kříž, Ph.D.
Termín odevzdání diplomové práce je stanoven časovým plánem akademického roku 2015/2016.
L.S.
_______________________________ _______________________________doc. RNDr. Bedřich Půža, CSc. doc. Ing. et Ing. Stanislav Škapa, Ph.D.
Ředitel ústavu Děkan fakulty
V Brně, dne 29.2.2016
Abstrakt
Cílem této diplomové práce je návrh a vývoj řešení pro podporu rozhodování
(Business Intelligence) pro společnost Toprecepty.cz. Díky tomuto řešení získá management
společnosti podklady založené na analytických informacích pro vykonávání lepších
rozhodnutí.
Abstract
The aim of this master thesis was to design and develop decision making solution
(Business Intelligence) for company Toprecepty.cz. Thanks to this solution, company
management will have the ability to produce better decisions based on gained analytical
information.
Klíčová slova
Business Intelligence, Cloudová technologie, ETL, Reporting, Modelování dat, Softwarová
architektura, Projektová administrace
Keywords
Business Intelligence, Cloud technologie, ETL, Reporting, Data modeling, Software
architecture, Project administration
Citace
ZDUBA, A. Tvorba datového skladu a reportovacích služeb. Brno: Vysoké učení technické v
Brně, Fakulta podnikatelská, 2016. 83 s. Vedoucí diplomové práce Ing. Jiří Kříž, Ph.D..
Tvorba datového skladu a reportovacích služeb
Prohlášení
Prohlašuji, že jsem tuto diplomovou práci vypracoval samostatně pod vedením pana
Ing. Jiřího Kříže, Ph.D. Další informace mi poskytli firmy Toprecepty.cz a LSV, s.r.o. Uvedl
jsem všechny literární prameny a publikace, ze kterých jsem čerpal a neporušil jsem
autorská práva (ve smyslu Zákona č. 121/2000 Sb., o právu autorském a o právech
souvisejících s právem autorským).
……………………
Bc. Andreas Zduba
20. května 2016
Poděkování
Chtěl bych poděkovat vedoucímu práce, panu Ing. Jiřímu Křížovi, Ph.D. za čas, ochotný
přístup a důvěru, kterou do mě vložil při vypracovávání této diplomové práce. Dále bych chtěl
poděkovat kolegům ze společnosti LSV, s.r.o. a panu Ing. Janu Křížovi, kteří mě v průběhu
práce podporovali a poskytovali odborné konzultace. V poslední řadě bych chtěl poděkovat
rodině, kamarádům a manželce. Po celou dobu mi byly morální podporou a měli pro mě
pochopení.
© Bc. Andreas Zduba, 2016.
Tato práce vznikla jako školní dílo na Vysokém učení technickém v Brně, Fakultě
Podnikatelské. Práce je chráněna autorským zákonem a její užití bez udělení oprávnění
autorem je nezákonné, s výjimkou zákonem definovaných případů..
Obsah
Úvod .......................................................................................................................................... 8
Cíl a struktura práce .................................................................................................................. 9
1 Teoretická východiska .................................................................................................... 10
1.1 Sběr dat a jejich analýza ........................................................................................... 10
1.2 Vrstva pro extrakci, transformaci, čištění a nahrávání dat ....................................... 11
1.3 Vrstva pro ukládání dat ............................................................................................ 12
1.4 Vrstva pro analýzu dat.............................................................................................. 13
1.5 Cíle a výhody DW a Business Intelligence .............................................................. 14
1.5.1 Výhody BI řešení .............................................................................................. 16
1.6 Databáze ................................................................................................................... 18
1.6.1 Interní datové zdroje ......................................................................................... 19
1.6.2 Externí datové zdroje ........................................................................................ 19
1.7 Business Intelligence ................................................................................................ 20
1.7.1 BI projekt .......................................................................................................... 21
1.7.2 Přístup k vývoji (Vývojový cyklus) .................................................................. 24
1.7.3 Prediktivní analýza............................................................................................ 25
1.7.4 Rozdíl mezi Business Intelligence a prediktivní analýzou ............................... 26
1.7.5 Statistika ............................................................................................................ 26
1.7.6 Dolování dat (Data mining) .............................................................................. 27
1.7.7 Přidaná obchodní hodnota ................................................................................. 27
1.7.8 Mráček na vzestupu (Cloud computing) ........................................................... 28
1.8 Facebook Graph API ................................................................................................ 28
2 Analýza současného stavu .............................................................................................. 30
2.1 Představení společnosti ............................................................................................ 30
2.1.1 Organizační struktura ........................................................................................ 30
2.2 Analýza současného stavu ........................................................................................ 31
2.3 Požadavky společnosti ............................................................................................. 32
3 Vlastní návrhy a řešení.................................................................................................... 34
3.1 Projekt tvorby datového skladu a reportovacích služeb ........................................... 35
3.1.1 WBS – work breakdown structure .................................................................... 35
3.1.2 Komunikační prostředky se zákazníkem .......................................................... 36
3.2 Analýza datových zdrojů .......................................................................................... 39
3.2.1 Facebook ........................................................................................................... 39
3.3 ETL proces ............................................................................................................... 44
3.3.1 Extrakce ............................................................................................................ 44
3.3.2 Transformace a uložení ..................................................................................... 55
3.4 Datový sklad pro analytické účely ........................................................................... 57
3.4.1 Logický model .................................................................................................. 59
3.4.2 Generátor hodnot časové dimenze .................................................................... 60
3.5 Tvorba reportů a dashboardů.................................................................................... 61
3.5.1 Možnosti napojení datového modelu ................................................................ 62
3.5.2 Úprava datového modelu, datových typů ......................................................... 63
3.5.3 Tvorba reportů a dashboardů ............................................................................ 64
3.6 Zhodnocení návrhu ................................................................................................... 69
3.7 Přínos pro společnost ............................................................................................... 71
3.7.1 Splnění KPI ukazatelů....................................................................................... 71
3.7.2 Náklady na vlastnictví....................................................................................... 71
Závěr ....................................................................................................................................... 73
Literatura ................................................................................................................................. 74
Seznam obrázků ...................................................................................................................... 78
Seznam tabulek ....................................................................................................................... 81
Seznam příloh ......................................................................................................................... 82
Seznam použitých zkratek ...................................................................................................... 83
8
Úvod
V dnešní době vyžadují manažeři přesnější, detailnější a aktuálnější informace. Navíc jsou
často poptávány v reálném čase, na všech dostupných platformách (počítač, tablet, mobil) ze
všech možných míst (mobilita), aby mohli konat efektivní rozhodnutí. Jedná se o klíčové
vlastnosti pro rychlé a správné rozhodování, které ovlivňuje celou společnost. Řešení pro
podporu rozhodování Business Intelligence, podporují manažery čísly, které jsou výsledkem
analýz a správnou grafickou interpretací.
Manažeři jsou zvyklí zakládat rozhodnutí na vlastním úsudku, který je založen na pocitech či
intuici. Společnost si nicméně nemůže dovolit činit špatná rozhodnutí, nezávisle na tom, ať už
se jedná o politický či ekonomický (konkurenční) faktor.
Pro pochopení této práce je důležité uvědomit si, že výsledné řešení není postaveno na
komunikaci v reálném čase, ale jedná o dávkové zpracování analytických informací za určité
období s následnou grafickou interpretací v podobě reportů. Na výstupy a kvalitu práce nemá
tento fakt žádný vliv. Období, za které jsou data získávána a analyzována, poskytují dostatečně
kvalitní vzorek dat.
Řešení Business Intelligence (BI) je postaveno z převážné části na cloudové výpočetní
technologii (Power BI) vyvinuté společností Microsoft. Mezi hlavní výhody této technologie,
které pomohli s vývojem a nasazením mého řešení, patří možnost nahrání na vzdálené servery,
odkud je možné se k analýzám připojit ze všech dostupných platforem. Další výhodou je
pokročilý editor datového modelu, pomocí kterého je vytváření nových entit velmi efektivní.
Nutným předpokladem pro úspěšné vytvoření řešení BI je tvorba datového skladu a jeho
naplnění. Všechny tyto činnosti, které se odehrávají v pozadí, se skládají z extrakce dat
z externího zdroje dat (Facebook Ads), transformace do integrované podoby a následného
nahrání do vytvořené databáze (ETL proces).
V rámci této práce budu analyzovat reklamní data společnosti za uplynulý půlrok. Výstupem
BI řešení jsou grafické reporty analyzující, vložené investice do reklamních kampaní. Toto
řešení bude společnosti Toprecepty.cz sloužit jako základní nástroj pro podporu rozhodování
při dalším investování do reklam.
9
Cíl a struktura práce
Tato kapitola má za úkol přiblížit čtenáře s cíli této práce. Zároveň bychom chtěli čtenáře
seznámit se strukturou této práce od začátku až do konce.
Cílem této práce je vývoj a nasazení řešení pro podporu rozhodování Business Intelligence pro
management společnosti Toprecepty.cz.
Dílčí cíle jsou:
Popis teoretických základů Business Intelligence,
Definice výkonnostních ukazatelů (KPI) na základě požadavků společnosti,
Vývoj řešení pro extrakci, transformaci a uložení dat (ETL proces) do datového skladu,
Prezentace výstupů ve formě skupin grafů,
Závěry a doporučení pro další rozvoj systému pro podporu rozhodování.
Pro vypracování této práce jsem využil metodologií a technologií, které jsem získal během
studia fakulty podnikatelské a informačních technologií. Uplatnil jsem také získané zkušenosti
ze společnosti LSV, s.r.o. a InkWater Capital Management, s.r.o.
Tato diplomová práce je rozdělena do čtyř hlavních částí. První z nich pojednává o cílech
a struktuře. Druhá část pojednává o teoretických východiscích Business Intelligence a další
části, které jsou pro zpracování potřebné. Třetí a čtvrtá část (závěrečná) je zaměřena na
praktickou část. Třetí část popisuje současnou situaci společnosti a požadavky na zlepšení.
Závěrečná část navazuje implementací řešení systému pro podporu rozhodování, založeném
na platformě společnosti Microsoft.
10
1 Teoretická východiska
1.1 Sběr dat a jejich analýza
Jedním z nejdůležitějších zdrojů každé společnosti jsou informace, které jsou využívány pro
dva účely:
Uchování v databázi
Analytické rozhodování Business Intelligence (dále jen BI)
Sběr dat a jejich uchování v databázi si můžeme představit pomocí běžných operačních
databázových (OLTP) systémů, jako jsou SQL, NoSQL servery. Mimo to, se může jednat
o jednodušší systémy, které ale jsou z hlediska této práce nepodstatné. Tyto systémy jsou
využívány ve většině podnikových procesů, kterými mohou být vytváření nových zákazníků,
monitorování jejich aktivity, vytváření objednávek apod. Hlavními uživateli těchto systémů
jsou buď zákazníci sami, nebo zaměstnanci společnosti vyskytující se na taktické, operační
vrstvě společnosti. Silná a nezbytná stránka těchto systémů spočívá v rychlém a spolehlivém
zpracování operací (transakcí). Tyto systémy se umí vypořádat s velkým množstvím operací
v krátkém časovém intervalu a mimo jiné, musí být schopny data uchovat v konzistentním
a dlouhodobém stavu (založeny na principu ACID). Nicméně tyto operace jsou neměnné a jsou
prováděny stále dokola. Sběr a uchování dat je nutnou podmínkou, v případě zájmu společnosti
o rozvíjení analytického rozhodování. Pokud totiž neuchováváme žádné informace, nemáme
co dál zpracovávat.
BI systémy slouží hlavně pro sledování výkonnostních ukazatelů KPI, které si společnost sama
nastavuje a vyvíjí dle aktuálních potřeb a vývoje trhu. Oproti operačním systémům je zde
kladen důraz hlavně na uchovávání historických dat. Ve srovnání s operačními systémy,
v případě, že dojde ke ztrátě transakce (záznamu v databázi), nemělo by dojít k ovlivnění
výsledků analytického rozhodování (pár záznamů v tom velkém množství dat ovlivní výsledek
pouze zanedbatelně). Samozřejmě tím nechci říct, že nad tím můžeme mávnout rukou a jen tak
ztrácet data, ale přece jen jsou tyto systémy nejčastěji využívány manažery společnosti, kteří
se vyskytují na taktické, strategické vrstvě společnosti. Pokud bychom provedli srovnání
s předchozím systémem a uvedenými příklady, jsou BI systémy využívány k získání informací
typu „počet“ nových objednávek, porovnat je s objednávkami za předchozí týden, získat
11
odpovědi na otázky proč došlo k registraci nových zákazníků a co je na stránkách nejvíce
zajímalo (jedná se o Online Analytical Proccessing, dále jen OLAP). Jedná se o operace
prováděné nad velkým množství dat (nutná optimalizace dotazů kvůli výkonnostním
problémům, které jsou způsobeny velkým množstvím dat) a jak je z výkladu patrné, analytické
systémy se opírají o data, získaná z operačních databází, tyto data dále zpracovávají (očišťují,
transformují) a ukládají. Pro tento proces se používají tři nejznámější postupy a to:
EAI, ETL, EII
Detailnějšímu popisu charakteristik a využití těchto metod se věnujeme níže v samostatné
podkapitole, zejména metodě ETL, kterou jsem použil v mém řešení. Součástí BI systémů musí
být uložiště, kde jsou data uložena a prováděny složité dotazy. Často se jedná o stejný typ
databáze jako v případě operativních systémů. Rozdílná je tvorba vazeb jednotlivých entit.
Takto vytvořené databáze se nazývají datové sklady (Data Warehouse, dále jen DW). Tvorbě
DW se věnujeme podrobněji v kapitole Datový sklad pro analytické účely.
1.2 Vrstva pro extrakci, transformaci, čištění a
nahrávání dat
Jedná se o první vrstvu modelu BI. Slouží k výběru, transformaci a přenosu dat z produkčních
databází do cílových databází BI. Jedná se o časově náročný proces, který při tvorbě BI řešení
zabere okolo 70 % celkového času. Nejčastěji se používají 2 přístupy, pomocí kterých se tento
proces uskutečňuje.
ETL (Extraction, Transformation and Loading) je jednou z nejvýznamnějších
komponent celého komplexu BI. Běžným označením pro prostředky ETL je rovněž
datová pumpa. Jejím úkolem je data ze zdrojových systémů získat, vybrat (Extraction),
upravit do požadované formy (Transformation) a nahrát je do specifických datových
struktur, respektive datových schémat, datového skladu (Loading). Tyto nástroje lze
tedy používat pro přenos dat mezi dvěma, či více libovolnými systémy. Stejně jako
později zmiňované nástroje pro zajištění datové kvality DQS a správy metadat. ETL se
stal nedílnou součástí procesu až s rozvojem analytických systémů, tedy s explicitní
potřebou pro zajištění přenosu dat mezi různými aplikačními systémy v rámci
různorodého databázového prostředí. ETL pracuje v dávkovém (batch) režimu, data
12
jsou tedy přenášena v určitých časových intervalech. Pro dnešní BI řešení se většinou
jedná o denní, týdenní a měsíční intervaly [1].
EAI (Enterprise Application Integration) jsou nástroje, které můžeme najít ve vrstvě
zdrojových systémů. Jejich cílem je integrovat primární podnikové systémy a razantně
redukovat počet jejich vzájemných rozhraní. Tyto nástroje pracují principiálně na dvou
úrovních. První úroveň je datová integrace. Pod datovou integrací si můžeme představit
proces výběru záznamů z jedné aplikace a následného přenosu do druhé, jednotné.
Druhá úroveň slouží k aplikační integraci, kde dochází ke sdílení určitých funkcí
informačních systémů [1].
1.3 Vrstva pro ukládání dat
Jedná se v pořadí o druhou vrstvu modelu BI. Základní komponentou této vrstvy je datový
sklad. Kromě datového skladu existují ještě dva další způsoby, které lze pro ukládání dat
využít. Každé z těchto řešení má své kladné a záporné stránky, záleží na způsobu
implementace a výběru komponenty.
Datový sklad (Data Warehouse) je nezbytným technologickým základem mnoha
řešení zajišťujících či podporujících obchodní aktivity společnosti. Kvalitní datový
sklad je prostředkem, který dává možnost neustálého posilování konkurenceschopnosti
a úspěšnosti organizace. Základní úlohou datového skladu je přeměnit data společnosti
na „rodinné stříbro“, tedy hodnotné informace vedoucí k lepšímu rozhodování
a v konečném důsledku k lepším výsledkům společnosti [2].
Datové tržiště (Data marts) je komponenta datových skladů. Jejich princip je obdobný
jako v případě datových skladů. Rozdíl spočívá v tom, že jsou určeny pro pokrytí
konkrétní problematiky daného okruhu uživatelů a jejich architektura je již většinou
založená na tabulkách faktů a tabulkách dimenzí, což podstatně usnadňuje datovou
analýzu. Datová tržiště obsahují rovněž spoustu odvozených a agregovaných atributů
často používaných v daném oddělení. Výsledkem jsou pak datová tržiště pro různá
oddělení v podniku [3].
Dočasné úložiště dat (DSA) vzniklo za účelem dočasného uložení extrahovaných dat
z produkčních systémů. Hlavním úkolem je podpora rychlé a efektivní extrakce
13
(výběru) dat. Je to první úložiště, kam se data ukládají v netransformované formě ze
zdrojových systémů. Tato komponenta je v řešení BI nepovinná [1].
1.4 Vrstva pro analýzu dat
Komponenty, které v této vrstvě najdeme, mají za úkol zpřístupnit data a připravit pro
následnou analýzu. Může se jednat jak o jednoduché (tzv. user-friendly) tak i sofistikovanější
nástroje, které slouží k výběru klíčových dat z datových skladů nebo datových tržišť a jejich
následné analýze.
OLAP analýza slouží ke zpracování údajů uložených v datovém skladu do podoby pro
koncové uživatele, tedy manažery a analytiky. OLAP technologie by měla poskytovat
uživatelům multidimenzionální model odpovídající jeho podnikatelským potřebám tak,
aby bylo možné tento model využít pro účely analýzy. Systémy typu OLAP, mohou
mít více dimenzí, přičemž každá z nich může mít vícenásobné hierarchie. Z tohoto
důvodu by se neměly zavádět žádné umělé omezení počtu dimenzí nebo úrovní
agregace [4].
Reporting je činnost spojená s dotazováním se do databází pomocí standardních
rozhraní (např. pomocí SQL příkazů v rámci relačních databází, nebo MDX pro
MOLAP). V rámci reportingu lze definovat standardní reporting a ad hoc reporting [1].
o Standardní reporting: předpřipravené reporty (dotazy) jsou spuštěny
automaticky buď v určitých časových periodách, nebo na vyžádání koncového
uživatele.
o Ad hoc reporting: specifické dotazy jsou formulovány jednorázově, explicitně
vytvořené uživatelem.
Dolování dat z databází (Data mining) je proces získávání zajímavých, ale
dosud neznámých informací z databází. Mnohdy je škoda, pokud ve společnosti leží
ladem zajímavá data, nebo jejich zpracování spočívá pouze ve vytvoření tabulek a grafů
v Excelu. Pomocí data miningu můžeme vyhodnocovat návratnost kampaní, analyzovat
zákaznickou databázi, nebo hledat souvislosti a možné korelace v datech. Tyto analýzy
jsou založeny na specializovaných algoritmech, jako jsou například rozhodovací
stromy, neuronové sítě, generické algoritmy nebo clustering [5].
14
1.5 Cíle a výhody DW a Business Intelligence
Než se ponoříme do principů multidimenzionálního modelování, je dobré si říci, jaké otázky
z pohledu zákazníka je DW/BI schopno zodpovědět. Podle [6] se opírá o více jak 20-leté
zkušenosti získané z manažerských schůzek zastupující jednotlivé společnosti. Nejčastější
situace, které společnosti řeší a na které hledají odpovědi, jsou:
„Shromažďujeme spoustu dat, ale nemáme k nim přístup“
„Potřebujeme se na data dívat jen z určitého úhlu a do hloubky“
„Manažeři vyžadují jednoduchý přístup k datům“
„Chceme vidět jen co je důležité“
„Celé schůzky trávíme diskutováním, kdo má správná čísla, než abychom se věnovali
rozhodování“
„Chtěli bychom, aby zaměstnanci lépe využívali informace pro podporu rozhodování
na základě faktů“
Ze zkušeností, jsou tyto situace tak univerzální, že automaticky tvoří jádro DW/BI systémů [6].
Nyní se pokusíme tyto tvrzení rozebrat a vytvořit z nich business požadavky na systém:
Informace musí být v rámci DW/BI systému jednoduše dostupné.
Obsah DW/BI systému musí být srozumitelný. Data by měla být pro obchodní manažery
intuitivní a zřejmá, ne pouze pro vývojáře. Datové struktury a popisky by měly být zaměřené
a přizpůsobené pro obchodní odvětví. BI nástroje a aplikace, které zpřístupňují koncovým
uživatelům data, by měly být jednoduché pro používání. Zároveň se od nich očekává, aby se
dotazy zpracovaly a výsledky vrátily co nejrychleji. Celé to můžeme shrnout do jedné věty
a to: jednoduché a rychlé
DW/BI systémy musí informaci reprezentovat stále stejným způsobem (konzistence
informace).
Data musí být důvěryhodná. Data musí projít shromážděním z jednotlivých zdrojů, očištěním,
zajištěním kvality a integrity. K uvolnění dochází až v případě, že jsou data způsobilá pro
15
zpracování uživateli. Jelikož jsou data shromážděna z různých datových zdrojů, je důležité
pečlivě zvolit datové struktury a popisky. Pokud dva výkonnostní ukazatele mají stejný název,
musí mít stejný význam. Z výše uvedeného vyplývá, nutnost platnosti implikace a s tím
souvisí, že v případě odlišných významů dvou ukazatelů musí mít odlišné názvy popisků
struktur.
Systémy se musí umět přizpůsobit potřebám.
Potřeby uživatelů, obchodní podmínky, data a technologie jsou předmětem stálých změn. Tyto
informace je nutné nepodceňovat a věnovat tak patřičnou pozornost návrhu DW/BI systému.
Od výsledného řešení se očekává schopnost bezproblémového zpracování neočekáváných,
výše uvedených situací, které by neměly žádným způsobem jakkoliv ovlivnit existující data
a aplikace. U stávajících dat a aplikací by nemělo docházet ke změně nebo narušení,
v důsledku nových požadavků od obchodních manažerů, nebo dodání nových dat do DW. Na
závěr, pokud dojde ke změně popisných dat DW/BI, je nutné patřičné zvážení všech změn a ty
promítnout do všech částí, takovým způsobem, aby byla dodržena konzistence.
Vysoká dostupnost aktuálních dat.
Tempo vývoje technologií a množství sbíraných a analyzovaných dat, roste exponenciální
rychlostí. Protože se předpokládá denní využívání nástrojů BI, je nutné provádět aktualizace
podkladových dat co nejčastěji, v nejoptimálnějším případě online. Zároveň je od obchodních
uživatelů nutné, realistického očekávání v rámci doručení nových dat do DW/BI.
Bezpečnost informačních zdrojů.
Všechny klíčové, drahocenné informace společnosti jsou ukládány do datového skladu.
Přinejmenším obsahují citlivé obchodní informace o tom, komu prodáváme a za kolik. Jedná
se jednoduše o zneužitelné informace, které by v případě odcizení mohly pro společnost
znamenat velké nepříjemnosti. Z tohoto důvodu se očekává maximální ochrana a zabezpečení
informací uložený v datových skladech a zobrazených v BI aplikaci. Samozřejmostí je
kontrola práv účtu.
Důvěryhodný a autoritativní nástroj pro podporu rozhodování.
Datový sklad musí obsahovat správná data pro podporu rozhodování. Nejdůležitější výstupy
z DW/BI systému jsou rozhodnutí, které jsou uskutečněny na základě analytického výstupu.
16
Tyto rozhodnutí mají přímý dopad v obchodním rozhodování a KPI atributů. Nejlepší popis
DW/BI systému který vystihuje, co by mělo být výstupem, je: „Systém pro podporu
rozhodování“
Systémy musí být tvořeny takovým způsobem, aby byly považovány obchodní
komunitou za přijatelné.
Nezáleží na tom, že se snažíte o elegantní řešení, postavené na nejlepších technologiích,
produktech a platformách pro dané odvětví. Pokud není DW/BI systém kladně přijat obchodní
komunitou a „aktivně“ využíván, došlo k selhání v akceptačním testování, které sebou nese
určité problémy jako například náklady na přepracování, popřípadě může v krajních situacích
dojít ke ztrátě zákazníka. Je to způsobeno i faktem, že na rozdíl od operačních systémů, které
svým způsobem uživatelům nedávají jinak na výběr než je používat, DW/BI systém tímto
faktem nedisponuje a musí se tedy opírat o nejdůležitější kritérium z pohledu obchodních
manažerů a to: „jednoduchý a rychlý“ k získání informací o chodu společnosti.
1.5.1 Výhody BI řešení
Ne všem můžou být výhody BI řešení zřejmé, a proto zde uvádím hezké shrnutí hlavních
výhod [7].
Obrázek 1-1:Výhody Bussiness Intelligence [8]
Jelikož účelem této práce není procházet si všechny uvedené výhody, vybral jsem z mého
pohledu 5 nejdůležitějších výhod Business Intelligence:
17
Získání představy o chování zákazníků:
Hned na úvod můžeme říct, že se jedná o největší přínos BI softwaru, který společnostem
umožňuje získat pohled na věci, které zákazníka zajímají, kupuje (nebo nekupuje). Díky těmto
informacím má zákazník možnost promítnout do navýšení zisků a udržitelnosti klíčových
zákazníků. Společnosti využívají data ze sociálních sítí, jako jsou například Facebook,
Instragram, LinkedIn k obohacení databází a zjištění, jaké jsou potřeby zákazníků.
Dostupnost přehledů o klíčových metrikách:
Mít dobrý přehled o obchodních procesech je jednou z klíčových metrik, pomocí kterých
můžeme měřit obchodní výkonnost společnosti. Proto začíná být čím dál tím důležitější, aby
tyto přehledy, nástěnky (dashboards), byly přístupné na mobilních zařízeních. Největší
uplatnění najdeme u obchodních zaměstnanců, kteří jsou většinu času na cestách a dokáží
takovou vlastnost maximálně zhodnotit.
Zlepšení efektivity:
Další bezesporu důležitou výhodou je zlepšení efektivity společnosti. Spousta společností
zbytečně plýtvá drahocenným časem, snahou získávat data z datových uložišť jednotlivých
oddělení společnosti, které musí následně prozkoumat, pochopit struktury, než jsou schopni
pracovat se souvislostmi, užitečnými pro jejich obchodování. Na rozdíl BI software poskytuje
centralizovanou správu dat, díky které jsme schopni zobrazit struktury v dashboardech,
popřípadě v přehledech, které jsou tvořeny přímo dle potřeb dané společnosti. Tento přístup
díky eliminaci neefektivního přístupu a práce s daty šetří spoustu času..
Historický přehled čeho jsme dosáhli a kam směřujeme:
Výbornou vlastností BI je její vyjadřovací schopnost časově závislých událostí. Může se
například jednat o počet prodaných kusů produktu, skrze který obchod došlo k prodeji, ve
kterém zákaznickém segmentu jsme prodeje uskutečnili. Tato schopnost se dále promítá do
analyzování a zpracování nestrukturovaného obsahu, pro lepší pochopení proč k určitým
událostem došlo.
Identifikace „cross-selling” a „up-selling” příležitostí:
18
Business Intelligence software umožňuje společnosti využít data zákazníků k vytváření
prediktivních modelů, které mohou být použity jako podklady k motivování zákazníka ke
koupi nového (cross-selling), nebo vylepšeného (up-selling) produktu, díky získaných
znalostí preferencí zákazníka [9].
1.6 Databáze
Než se ponoříme do popisu DW/BI řekneme si něco o databázích, na kterých je všechno
založeno. Obvyklým způsobem, který se používá stále dokola, bychom databáze dělily na
osobní a podnikové. Jelikož mi přijde tento pohled v rámci této práce méně významný,
pokusím se zde nastínit jiný pohled, lépe vystihující možné formy informací, ze kterých jsme
schopni DW/BI systémy tvořit a to „Datové zdroje“. Tyto datové zdroje představují všechny
takové entity, které uchovávají data, informace v digitální podobě. Na rozdíl od ortodoxního
pohledu, který dělí databáze podle typu přístupu a to, zda k datům přistupuje pouze jeden
uživatel (obvykle má data na „osobním“ počítači), nebo se jedná o přístup podnikový (k datům
přistupuje spousta uživatelů v rámci společnosti). Vytváří toto dělení dojem, že DW/BI
systémy je možné stavět hlavně na podnikových databázích. Ze zkušeností vím, že realita je
úplně jiná. Jedna nejmenovaná „nadnárodní“ společnost, se kterou jsem měl možnost
spolupracovat, uchovávala data, ke kterým denně přes interní sdílené uložiště (NAS)
přistupovalo desítky zaměstnanců ve formě Excelovských tabulek. Smyslem této práce není
polemizovat a vhodnosti využívaného systému pro úchovu dat a proto to nebudeme dále
rozebírat. Kdybychom se drželi původního pohledu, nepřipadala by taková možnost v úvahu
a neuvažovali bychom za pravděpodobné nad takovými daty systém pro rozhodování vytvářet.
Nicméně velké společnosti zabývající se těmito systémy si jsou vědomi nutnosti podpory
spousty typů uložišť informací, neboli „Datových zdrojů“. Opět se dostáváme k novému
pohledu, který je nejlépe vystižen v [10]. Než se vrhneme na popis datových zdrojů, popíšeme
si dělení databází. Databáze můžeme nejlépe rozdělit do tří kategorií a to:
Osobní databáze jsou navrženy zejména pro používání jednou osobou, na jednom
počítači. Tento typ databáze má jednoduchou strukturu a jsou relativně malé.
Databáze pro používání v odděleních, skupinách jsou využívány členy skupin, nebo
odděleními společnosti. Mohlo by se jednat o databáze určené pouze pro finanční,
legislativní oddělení, kde jsou uchována důvěryhodná data. Databáze jsou zpravidla
větší než osobní databáze. To znamená, že použitý hardware pro tuto databázovou
19
infrastrukturu musí být zvolen tak, aby nevznikaly problémy při současném přístupu
většího počtu uživatelů [11].
Podnikové databáze mohou být obrovské, co se do datové velikosti týče. Mohou
zachycovat kritické informační procesy napříč celou organizací. V poslední době
začaly společnosti využívat tzv. In-memory databáze (oproti klasickému načítání dat
z pevných disků, jsou databáze uloženy v RAM paměti serveru) a cloudově
orientované datové sklady pro ukládání firemních dat. Důvod je prostý. Snižovat každý
rok náklady na uchování dat, ale zároveň zvyšovat jejich uložené množství. Proto
společnosti vyhledávají taková řešení, která tyto požadavky splňují. „Řešení je
v oblacích“ [11].
Na rozdíl od databází, datové zdroje obecně dělíme na interní a externí a věnujeme jim
následující podkapitoly.
1.6.1 Interní datové zdroje
Ačkoli je většina informací uložena v relačních databázích RDBMS, včetně IT správy,
nesmíme opomenout i data vyskytující se v osobních počítačích, noteboocích, které mají často
podobu Access databází, obyčejných textových souborů, souborů se speciálním oddělovačem
hodnot (původně csv) a jiných typů souborů. Byť může být množství těchto dat oproti relačním
databázím malé, mohou mít velký vliv v rámci výsledků pro podporu rozhodování, a proto na
ně nesmíme zapomínat a měli by být zahrnuty do procesu integrace DW/BI systému.
1.6.2 Externí datové zdroje
Data mohou také pocházet z jiných zdrojů, externích, jako jsou například webové služby,
OData čtečky, nebo již zmiňované RDBMS systémy, které mohou být provozované na
vzdálených serverech mimo společnost. Pokud se jedná o webové služby, OData čtečky, jsou
data zpřístupněny skrze URL. Tyto data jsou spoustou vývojářů opomíjena, jelikož neví, že
existují, o jejich možnostech zpřístupnění. Obdobný postup může platit pro RDBMS systémy.
Výsledkem je důležitost zapojení zákazníka do analýzy, protože oni jediný mohou (často sami
neví) vědět, kde jsou která data a jakým způsobem je možné k nim přistoupit. Spojením těchto
dvou zdrojů dat získáme všechny dostupná digitální data, která mohou být dále zpracována
a zaintegrována do DW, viz následující obrázek.
20
Obrázek 1-2: Datové zdroje sloužící jako podklad pro datový sklad [10]
Na základě těchto informací bychom si mohli položit jednoduchou otázku. Proč bychom měli
vyvíjet DW? Nemohli bychom k jednotlivým zdrojům přistupovat, upravovat a vytvářet
reporty samostatně? Dokázali bychom si odpovědět, že určitě ano, ale nicméně jsou tu jisté
situace, které nedovolují, aby se tato myšlenka víc prosadila. Například, některé datové zdroje
budou obsahovat podobnou, ne-li stejnou informaci, akorát v jiném formátu. I když si do určité
míry v životě rád připouštím anarchii, jsem pevným zastáncem nutnosti vést DW, který mluví
jednoznačně a tudíž se o něj můžeme jako dodavatelé systému pro rozhodování opřít
a spolehnout se, že obchodním manažerům dodáme plnohodnotné a validní řešení, které jim
pomůže při rozhodování.
1.7 Business Intelligence
Systémy pro podporu rozhodování postupně rostly, vyvíjely se a postupem času se z nich staly
Business Analytics a Business Intelligence systémy, které se staly nedílnou součástí
obchodních strategií. BI není žádná technologie, ale spíš se jedná výsledek činnosti, který má
pro společnost přidanou hodnotu. Důsledkem dosažení těchto hodnot bývá využití
analytických nástrojů.
Úspěšné BI vyžaduje, úspěšnou synergii s firemní kulturou. Cesta k úspěšnému vytvoření BI
začíná věděním otázek, na které chceme vědět odpovědi. Následuje analýza dat za účelem
pochopení, jakým způsobem mohou být otázky daty zodpovězeny. Typ otázek a výstupů,
kterých chceme dosáhnout je pro každou společnost jiný. Neziskové společnosti chtějí podnítit
21
zájem zákazníků a zvýšit tak svůj podíl na trhu, na rozdíl od vládní organizace, která chce
dosáhnout lepšího hospodaření s financemi a docílit tak lepšího vnímání občany. Ve výsledku
to můžeme shrnout, že v samotném epicentru se nachází mise, vize a cíle společnosti [10]. Pro
tyto účely je nutné mít dobrou BI strategii a plán. Na základě těchto informací sestavíme BI
projekt.
1.7.1 BI projekt
Projekt musí brát v úvahu hodnototvorné činnosti společnosti (interní), viz Obrázek 1-3
a zároveň působení externích vlivů na společnost, viz Obrázek 1-4. Pokud dojde k propojení
s hodnototvorným řetězcem společnosti, zvýší se tím šance přijmutí BI projektu v rámci celé
společnosti. Pochopením externích vlivů dostáváme možnost klást si správné otázky a sdílet
Obrázek 1-3:Hodnototvorný řetězec přizpůsobený od M. E. Porter, The Competitive Advantage of
Nations (New York: Free Press, 1990)
výsledné informace se správnými členy společnosti, díky čemuž můžeme BI projekt postavit
na korektních strategických cílech. BI projekty se odlišují od ostatních projektů tím, že
neobsahují konečný počet staticky definovaných požadavků od jedné osoby. Projekty jsou
charakteristické tím, poskytnout informace napříč celou společností (všemi divizemi,
odděleními), všem zaměstnancům. Z toho nám vyplývá, že takové požadavky se budou
neustále vyvíjet na základě nově vznikajících připomínek, požadavků od jednotlivých
zaměstnanců, změn zodpovědností a pravomocí [12]. Nesmíme zapomenout, že připomínky
nemusejí vznikat jenom na základě nových nápadů, ale na základě vývoje společnosti, která se
musí přizpůsobovat trhu.
22
Obrázek 1-4:Externí okolí: Prvních pět působících sil bylo definováno Porterem, The Competitive
Advantage of Nations. Šestá síla byla definována D. R. Gnyawali a B. J. Park, „Co-Opetition and
Technology Innovations in Small and Medium-Sized Enterprises: A Multilevel Conceptual
Model,“ Journal of Small Business Management 47, no. 3 (2009): 308-30
1.7.1.1 Projektový management BI aplikace
Ve většině společností je projektový management veden jako administrativní přehledová
funkce. Detailní projektové plánování, denní kontrola projektu jsou minimalizovány, pokud ne
úplně ignorovány, obzvlášť pokud se společnost snaží BI aplikace uvést do chodu rychle.
K popsání aktivit projektového managementu v té nejjednodušší podobě, poslouží odpověď na
4 základní otázky [12]:
Co bude dodáno? – obsah,
Kdy to bude dodáno? – čas,
Kolik to bude stát? – rozpočet,
Kdo provede realizaci? – lidské zdroje.
Tyto základní otázky musí být zodpovězeny, než projektový manažer začne s tvorbou
projektového plánu. Musí věnovat dostatečný čas definování projektu, aby jasně pochopil
požadavky, rizika, omezení a očekávání [12]
23
1.7.1.2 Definice BI projektu
Projektové řízení zahrnuje tvorbu projektového náčrtku (project charter), který projekt definuje
v rovinách:
Cílů a milníků:
o Jaký je důvod pro budování BI aplikace?
o Jaká jsou hlavní strategická rozhodnutí přispívající k obchodní hodnotě?
Rozsah:
o Z typického pravidla 80/20 platí: 80 % úsilí na data a 20 % úsilí na
funkcionalitu.
Rizika:
o Nedostatek důvěry, zapojení managementu,
o Ztráta investora,
o Nerealistické očekávání,
o Nerealistický rozpočet (zejména nízký)
Omezení a předpoklady:
o Doporučené pořadí projektových omezení: Kvalita, rozpočet, zdroje, čas,
rozsah.
Procedury zvládání výjimečných událostí:
o Každá událost musí mít přiřazenou osobu, která má na starost její vyřešení.
Každá aktivita, popisující danou událost musí být opatřená datem a patřičně
popsána (jedině tak je možné k rychlé nápravě systému)
Project charter je dohoda uskutečněná mezí obchodním sponzorem (zákazníkem) a IT
oddělením popřípadě firmou, která je za vývoj BI aplikace zodpovědná. Pokud dojde
v project charteru ke změně, musí dojít k přehodnocení a odsouhlasení celého projektu a s tím
i spojených omezení [12].
24
1.7.1.3 Plánování BI projektu
Uveďme si sekvenci aktivit pro přípravu projektového plánu:
Vytvořit pomocí dekompozice práce, seznam aktivit, úloh a pod úloh,
Časový harmonogram pro činnosti z předchozího bodu,
Přiřadit aktivitám zdroje,
Odvodit závislosti mezi jednotlivými aktivitami,
Určit kritickou cestu v závislosti na předchozím bodě,
Na závěr vytvořit detailní projektový plán [12].
1.7.2 Přístup k vývoji (Vývojový cyklus)
Skoro každý druh inženýrského projektu, zahrnující BI projekty, prochází šesti fázemi od
plánování až po implementaci a nasazení. Těchto šest fází můžeme vidět na následujícím
obrázku.
Obrázek 1-5: Fáze inženýrského projektu [12]
Tento vývojový model je iterativní. To znamená, že jakmile dotáhneme projekt do fáze
nasazení, přechází projekt do neustálého vylepšování, které se děje na základě získané zpětně
vazby. Nové vlastnosti, funkce projektu mohou a nemusí být předmětem neustálého
25
vylepšování (snahou je a vždy bude, prodat nové vlastnosti). Každá taková iterace uvolní nový
produkt, verzi [12].
Plán Business Intelligence popisující těchto šest fází:
Fáze 1: Uspokojení: Snahou je odhadnout obchodní potřeby zákazníka, které dávají šanci
inženýrskému projektu.
Fáze 2: Plánování: Vytvořit strategické a taktické plány, které rozkreslují, jakým způsobem
dosáhneme inženýrského projektu a jeho následné nasazení.
Fáze 3: Obchodní analýza: Provést detailní analýzu obchodních problémů, nebo příležitostí
pro zisk slušného pochopení požadavků, které jsou kladeny na výsledné řešení (produkt).
Fáze 4: Návrh: Návrh produktu, který řeší body z Fáze 3, nebo otevírá nový prostor k obchodní
příležitosti.
Fáze 5: Implementace: Vytvořit produkt, který by měl splňovat stanovenou návratnost
investice (ROI) v definovaném čase.
Fáze 6: Nasazení: Nasadit hotové řešení u zákazníka a následně monitorovat a porovnávat zda
dodané řešení ne-splňuje, nebo dokonce převyšuje očekávanou návratnost investice [12].
1.7.3 Prediktivní analýza
Prediktivní analýza je využívána k odhadu možného výskytu určitých událostí, nebo k určení
pravděpodobnosti výskytu konkrétní situace. Na těchto principech staví oblast zabývající se
dolováním dat (data mining, DM). Tato disciplína se zaměřuje na predikci budoucích událostí
a trendů. Prediktivní analýza je aplikována v automatizované analýze velkého množství
(řádech GB a výš) dat různých proměnných, jako jsou klustery, rozhodovací stromy, analýza
obchodního košíku (market basket analysis), regresní modelování, neuronové sítě, genetické
algoritmy, dolování textu a další [13].
Základním stavebním elementem prediktivní analýzy je predictor. Jedná se o měřitelnou
proměnnou, jejíž chování, hodnotu chceme predikovat. Může se například jednat o věk, příjem,
kreditní historii, které může společnost vydávající kreditní karty chtít predikovat [13].
26
1.7.4 Rozdíl mezi Business Intelligence a prediktivní analýzou
Nejjednodušší způsob, jak pochopit rozdíl mezi BI a prediktivní analýzou je za pomocí
následujících příkladů.
BI umožňuje při správné implementaci odpovědět na demografické otázky, charakteristiky
zákazníků, produktů apod.. Dalším důležitým rysem je odpověď na otázky ohledně výkonnosti
obchodování napříč různých dimenzí.
Nejprodávanější produkt za minulý týden?
Počet návštěv firemního e-shopu zákazníky?
Počet nových zákazníků za minulý týden?
Na druhou stranu, prediktivní analýza poskytuje společnostem možnost jít za hranice
odpovědí, které jim poskytují BI aplikace, poskytováním prediktivních odpovědí a doporučení
na obdobné otázky.
Jaký je předpokládaný zisk našich 10 % nejvíce ziskových zákazníků pro příští týden?
Jaké propagace bychom měli příští týden uskutečnit?
Jaká je nejlepší cena, abychom přiměli cílovou skupinu potenciálních zákazníků ke
koupi našeho produktu?
Prediktivní analýza povyšuje odpovědi, na které je schopna BI odpovědět retrospektivně
(zobrazuje fakta) na vyšší úroveň, tím, že vytváří predikce, odhady událostí, doporučení na
základě analýzy historických dat [14].
1.7.5 Statistika
Statistika jsou čísla, která vznikají na základě měření empirických údajů v závislosti na čase.
Jako disciplína se statistika zajímá o shromažďování a analyzování dat – často, aby nám řekli
svůj příběh v číslech [15].
Statistika může naznačit vazby mezi údaji, a tak má významnou roli v reprezentaci dat
a pochopení jich. Nejdůležitějším bodem je vzorek datové sady, se kterým pracujeme. Při
27
využívání vzorků nashromážděných údajů, nám může statistika poskytnout základ pro
inferenční hypotézy o datech jako celku [15].
Inferenční statistika se týká stanovení závěrů nebo předpovědi o charakteristikách celé
populace ze vzorku datové sady. Ukázková data pro analýzy jsou vybrány náhodně, a to
způsobem, který představuje (ale nemusí zahrnovat) celou populaci. V případě, že vzorek
datové sady je vybrán dobře, umožňuje zkoumající osobě promítnout výsledky analýzy celé
populace s určitou pravdivostí (pravdivost je dána velikostí a kvalitou vzorku datové sady)
[15].
1.7.6 Dolování dat (Data mining)
Data organizací se stále zvětšují, zrychlují a obohacují. Data jsou jedním z nejcennějších
zdrojů. Obsahují spoustu skrytých informací a úkolem datových analytiků je tyto informace
najít.
Dolování dat je objevování skrytých vzorců za pomocí strojového učení a sofistikovaných
algoritmů. Prediktivní analýza je proces očištění datových zdrojů, extrakce skrytých hodnot za
pomoci znalosti obchodních procesů [15].
𝑫𝒐𝒍𝒐𝒗á𝒏í 𝒅𝒂𝒕 + 𝒛𝒏𝒂𝒍𝒐𝒔𝒕 𝒐𝒃𝒄𝒉𝒐𝒅𝒏í𝒄𝒉 𝒑𝒓𝒐𝒄𝒆𝒔ů
= 𝒑𝒓𝒆𝒅𝒊𝒌𝒕𝒊𝒗𝒏í 𝒂𝒏𝒂𝒍ý𝒛𝒂 ⇒ 𝒐𝒃𝒄𝒉𝒐𝒅𝒏í 𝒉𝒐𝒅𝒏𝒐𝒕𝒂
Dnešní přední organizace nahlíží na svá data, zkoumají je a zpracovávají je za účelem hledání
nových, lepších cest vedoucí k lepšímu pochopení zákaznické základny, vylepšit procesy,
získat konkurenční výhodu a lepší postavení na trhu. Snaží se o maximální využití informací
pro získání většího podílu na trhu [15].
1.7.7 Přidaná obchodní hodnota
Ve stále se rozvíjejícím konkurenčním prostředí, je snahou společností být co nejvíc
konkurenceschopní. Prediktivní analýza si jako nástroj našla ve společnostech své místo.
Využíváním technologií v podobě algoritmů pro strojové učení, statistik, a technik pro
dolování dat, mohou společnosti odhalit skryté vzorce, trendy, které mohou pomoci ve
strategickém rozhodování a uspokojit klíčové obchodní potřeby [15].
Implementací prediktivní analýzy v operačním rozhodování zlepšuje návratnost investic (ROI)
a to proto, že společnosti tráví méně času zpracováváním rozhodnutí s nízkým dopadem,
28
rizikem pro společnost. Například vyplácení běžných pojistných událostí může probíhat
automatizovaně. Na druhou stranu, pokud prediktivní systém shledá pojistnou událost
neobvyklou, podezřelou z podvodu, systém může takovou událost označit a odeslat patřičné
osobě, která má tyto události na starosti [14].
1.7.8 Mráček na vzestupu (Cloud computing)
Cloud computing je obchodní model pro nový způsob poskytování IS a IT. Novým způsobem
je myšlen model „pay as you go“ (SaaS, PaaS, IaaS), který říká, že platíte pouze za dobu, po
kterou byly prostředky využívány. Nejedná se pouze o technický směr. Přesun aplikací do
cloudu, místo nasazení na vlastních, popřípadě pronajatých serverech vyžaduje promyšlený
přístup, který je od základů odlišný a může vyžadovat změnu strategické orientace společnosti.
K těmto změnám dochází, zejména pokud se společnost rozhodne k přesunu všech
serverových IS k externímu dodavateli cloudových systémů. I přes komplikace spojené
s migrací a reorganizací, se stává tento obchodní model stále populárnější a to zejména díky
nízkým nákladům, díky kterým si tyto technologie mohou dovolit malé podniky s nabytým
potenciálem zvýšit tak svoji konkurenceschopnost vůči větším, zaběhnutějším společnostem.
1.8 Facebook Graph API
Jedná se o jeden z externích zdrojů dat, se kterými jsem se snažil čtenáře seznámit v části
Externí datové zdroje. Jelikož má Facebook na poli sociálních sítí dominantní postavení, jedná
se o významný zdroj dat, o kterém bych se rád zmínil, a přiblížil možnosti komunikace.
Primární cesta, jak pracovat s daty z Facebooku je prostřednictvím Graph API. Jedná se o
nízko-úrovňové API, založené na HTTP, které lze využít pro dotazování dat, odesílání nových
příspěvků, správy reklam, odesílání fotek a mnoho dalších úloh, které může aplikace provádět
(aplikací je myšlena entita, ať už se jedná o webovou, mobilní či jinou vyvinutou aplikaci,
která má vygenerované speciální přístupové klíče, pomocí kterých se autentizuje a získává tak
autorizační práva k provádění operací. Proces autentizace a autorizace je prováděn skrze
přihlášení uživatelského účtu Facebooku).
Graph API je pojmenováno po základním stavebním prvku, na kterém staví všechny sociální
sítě a to „sociální graf“. Reprezentace informací na Facebooku se skládá z:
Uzlů (nodes) – základní prvky jako uživatelé, fotky, stránka, komentář,
29
Hrany (edges) – propojení mezi uzly, například fotek stránky, komentářů fotek,
Položky (fields) – doplňující informace o uzlech jako jsou například narozeniny osoby,
jméno stránky atd.
Pro představu jak takový sociální graf může vypadat, poslouží Obrázek 1-6
Obrázek 1-6: Sociální graf [16]
30
2 Analýza současného stavu
Cílem této kapitoly je seznámit čtenáře se společností Toprecepty.cz s.r.o. a následné získání
požadavků na výsledné řešení Business Intelligence aplikace, které bude sloužit společnosti
jako podpora pro rozhodování.
2.1 Představení společnosti
Společnost Toprecepty.cz s.r.o. byla založena 29.6.2009, s ambicemi stát se jednou
z největších online kuchařek v ČR. Tyto ambice se daří plnit a aktuálně jejich databáze
uchovává celkem přes 43 000 receptů. Pozici leadera upevňuje i hodnota měsíční návštěvnosti.
Ta činí měsíčně okolo 2,5 milionu návštěv. Hlavním zdrojem příjmů je reklama. Tu společnost
rozděluje na přímou, kdy je prodána přímo klientům, kteří mají zájem se na stránkách
zviditelnit, anebo za pomocí Google Adsense, vyhrazením částí webové stránky.
2.1.1 Organizační struktura
Obrázek 2-1: Organizační struktura společnosti (Zdroj: vlastní tvorba)
31
2.2 Analýza současného stavu
V začátcích společnosti nebyl problém monitorovat aktivitu, návštěvnost uživatelů a jejich
chování na webových stránkách. Postupem času návštěvnost narůstala, až do dnešních hodnot
kdy začíná být poněkud časově náročné, veškerou aktivitu sledovat a dochází tak ke častějšímu
výskytu situací, kdy jsou přidané obchodní hodnoty v množství dat ukryty, jelikož není možné
všechny data zpracovávat.
Jako distribuční kanál společnost využívá Facebook, kde se snaží informovat o veškerých
událostech kolem receptů (nové recepty, receptury, události apod.). Současně pro dosažení
maximálního zviditelnění, společnost využívá reklamní kampaně Facebook Ads, kde jsou
vytvořeny jednotlivé sady reklam, do kterých jsou přiřazeny skupiny receptů. Pomocí nich
chceme přilákat uživatele. Zároveň tyto sady mají přiřazený určitý finanční rozpočet k útratě.
Server, na kterém běží webové stránky, je pronajatý, formou virtuálního serveru. Jedná se
o linuxový stroj, díky čemuž jsou náklady na provoz nízké. Správu tohoto serveru zajišťuje
externí společnost, která server zároveň provozuje.
S postupem času si společnost vybudovala dominantní postavení na českém trhu. Bylo to
hlavně díky dobře definovanému produktu (mít důvěryhodné recepty, které čtenáře
nezklamou) a aktivní distribuční kanál, kterým stále je Facebook a s ním spojené reklamy. Pro
společnost je důležité, aby zákazníci cítili, že se svému produktu a zákazníkům věnují a proto
věnují aktivitě na stránkách Facebooku spoustu času. Důkazem mohou být čísla jako
124 000 „lajků“, měsíční návštěvnost těchto stránek v průměru činí přes 1 milion, a v 90 %
případů, společnost reaguje na komentář do 1 dne, což při takových číslech není vůbec snadný
úkol, vezmeme-li v úvahu, že se jedná o malou společnost (10 lidí včetně jednatele,
programátorů a manažerů).
Jak jsem zmiňoval již výše, společnost využívá reklamní kampaně Facebook. Byl to právě
tento distribuční kanál, který motivoval společnost ke změně současného stavu. Hlavním
problémem totiž je nepřehlednost a těžkopádnost nástroje pro monitorování a správu
reklamních kampaní Facebook Ads Manager. Jelikož je pro manažery obtížné s nástrojem
efektivně pracovat, omezili využívání schopností nástroje na úroveň, kdy zjišťují pouze
investice do reklam na denní bázi a celkový počet získaných návštěvníků. Byl to právě tento
stav, který podnítil společnost k řešení této situace, a na základě toho vznikla tato práce, která
si klade za cíl společnosti pomoct lépe, jednoznačně a jednoduše zobrazovat výkonností
32
ukazatele reklam a dalších firemních procesů KPI, které jsou detailně rozebrány
v kapitole návrhu a řešení.
Jako vedlejší distribuční kanály, které bych rád pro informaci zmínil (dál se jimi v práci
nezaobírám, jelikož jim společnost neklade větší pozornost) jsou Instagram a Pinterest. Pro
shrnutí, ilustraci poslouží Obrázek 2-2, který by měl bez nutnosti dalšího vysvětlování čtenáři
rychle umožnit pochopit rozdělení činností společnosti.
FB stránka Toprecepty.cz
Kampaně na receptyNáhodné reklamy na stránkách
Reklamní prostor klientů
Hlavní produkt
Webové stránky
PaaS
Obrázek 2-2:Struktura obchodního modelu (Zdroj: vlastní tvorba)
Tím se pomalu dostáváme k bodu, který je předmětem požadavků ze strany toprecepty.cz pro
optimalizaci procesů společnosti.
2.3 Požadavky společnosti
Společnost měla na začátku spolupráce pouze pár požadavků, navíc tyto požadavky měly velmi
obecný rys, který příliš nepomohl detailnějšímu definování.
Účinnost reklamních kampaní Facebook
33
Tento požadavek byl tak obecný a vyjadřovací schopnost byla tak nízká, že bylo nutné věnovat
větší úsilí a hlavně čas, definování podrobnějších informací jednotlivých požadavků.
Na základě těchto informací jsem usoudil, že bude nutné věnovat větší množství času
detailnějšímu seznámení se s firemními procesy společnosti a provést analýzu distribučních
a reklamních kanálů, které jsou hlavními body pro získání návštěvnosti, zisku. Této podrobné
analýze se věnuji v následující kapitole Vlastní návrhy a řešení.
Výsledkem této analýzy je podrobnější seznam reportů, které zobrazují aktivity společnosti:
CPL (cost per lead) – cena za návštěvníka
CPA (cost per action) – cena za akci. Akce může být kliknutí na odkaz, oblíbenost
příspěvků, zhlédnutí fotografie apod.
Celková investice do reklamy (spend cost)
Aktivita návštěvníků, uživatelů
o Unikátní počet akcí (zejména proklik, označení, komentování příspěvků)
o Celkový počet zobrazení příspěvku (total impressions)
o Poměrový ukazatel mezi dosahem (reach) a zhlédnutím (impression)
o Suma prokliků vedoucí k webové stránkce
o Cena prokliku na webovou stránku (CPWC – cost per website click)
o Dosah příspěvků uživatelů, kteří mají stránku v oblíbených
Společnost by chtěla docílit jednoduché a jednoznačné reprezentace jednotlivých KPI, které
jsme si definovaly výše. Jelikož se kritéria, které si společnost stanovila, týká více externích
zdrojů, byla by společnost ráda, pokud by se podařilo výstupy zaintegrovat pod jednotné
řešení, díky čemuž by se manažeři nemuseli nadále tak často připojovat k různým službám
(AdSense, Facebook Ads) a informace hledat pokaždé v odlišném prostředí. Výstupem by byl
přístup k jednotné aplikaci, která by na jednotlivých nástěnkách zobrazovala výsledky analýz
ze všech externích datových zdrojů. Takovéto řešení by usnadnilo a zpřehlednilo výsledky
taktických operací manažerům společnosti.
34
3 Vlastní návrhy a řešení
Tato kapitola si klade za důraz, čtenáře seznámit s návrhem komunikačních prostředků se
zákazníkem. Dále se zde zabývám definováním jednoduchého projektu, který si myslím, že by
neměl chybět. Díky němu budeme schopni dodefinovat některé události, na které bychom za
normálních okolností zapomněli, pomůže nám vytvořit si jednoduchý harmonogram a získáme
všeobecnou představu o krocích, které jsou nutné podniknout, abychom získali lepší představu
o časové náročnosti projektu a v neposlední řadě, nám poslouží jako vodítko pro případ,
kdybychom si některé části nemohli vybavit. Dále se v této kapitole zabývám samotným
návrhem řešení pro zlepšení současného stavu společnosti toprecepty.cz a jeho následnou
realizací.
Řešení se rozpadá do třech základních rovin, které jdou chronologicky po sobě.
1. Analýza datového zdroje, extraktor dat. Tato část má za úkol nejprve se seznámit
s dostupnými daty a následně se zabývat možnostmi jejich extrakce z externího zdroje
dat. Jedná se o velmi důležitý základní krok, bez kterého bychom nebyly schopni dále
v práci pokračovat. Následně musíme sestrojit na základě získaných znalostí z analýzy
nástroj pro extrakci dat, který tyto data stáhne do dočasného uložiště a připraví tak k
dalšímu zpracování (jedná se o nástroj použitý v procesu ETL).
2. ETL proces, datový sklad. Po analýze a vytvoření extraktoru dochází k samostatnému
ETL procesu a následnému vytvoření datového skladu. Tento ETL proces se skládá ze
tří částí:
a. Extrakce, stažení požadovaných dat z externího zdroje dat.
b. Očištění, transformace informací takovým způsobem, abychom byly schopni
data zaintegrovat do datového skladu.
c. Nahrání těchto očištěných dat do datového skladu.
Abychom mohli provést poslední krok (uložení dat do datového skladu), musíme mít
připravený odpovídající datový sklad. Pořadí, zda se nejdřív zabývat tvorbou datového skladu,
nebo ETL procesem není úplně jednoznačné. Najde se spousta odpůrců prvního přístupu
a naopak. Já si myslím, že každý projekt nese sebou jistá specifika a proto je nejlepší snažit se
35
obě části vyvíjet, pokud to jen trochu jde souběžně. Tento přístup může pomoci dříve vyřešit
nejasnosti, které mohou během návrhu vzniknout.
3. Reporty. Na základě stanovených KPI a dostupných dat v databázi vytváříme
odpovídající reporty, které by měly graficky interpretovat výkonnostní ukazatele. Tyto
reporty můžeme pro lepší přehled, omezení přístupu, zatřídit do samostatných
dashboardů.
Pro lepší pochopení architektury řešení a korelací mezi činnostmi slouží Obrázek 3-1. Všem
výše uvedeným částem se v této práci podrobně věnuji v samostatných podkapitolách.
Obrázek 3-1:Architektura řešení (Zdroj: vlastní tvorba)
3.1 Projekt tvorby datového skladu a
reportovacích služeb
Každý projekt by měl mít nějaké projektové řízení. Pro tento projekt jsem se rozhodl pro agilní
přístup projektového řízení formou WBS (Work Breakdown Structure), jelikož společnost pro
kterou projekt vznikal, funguje sama na agilních principech a nechtěl jsem, aby docházelo
k přebytečné režii.
3.1.1 WBS – work breakdown structure
Princip metody WBS spočívá v počátečním brainstormingu, za pomocí kterého jsme schopni
definovat hlavní činnosti, které jsou pro úspěšné uskutečnění projektu nutné (ne všechny
36
činnosti se nám podaří pomocí brainstormingu zachytit, ale spousta jich vyplyne při
komunikaci se zákazníkem, postupem času). Tyto činnosti dále rozpracováváme, až do
okamžiku, kdy jsme schopni činnosti v rámci projektu úspěšně dokončit. Jedná se o formu
dekompozice, kdy se postupně od obecné definice propracováváme až na nejdetailnější úroveň.
Výstupem této metody bývá dokument obsahující tabulku s činnostmi, jejich očíslováním
a následný slovní popis. Další forma, se kterou se můžeme často v praxi setkat je myšlenková
mapa (mind map). Tato myšlenková mapa je založená právě na brainstormingu a základ tvoří
grafické zobrazení činností v bublinách a jejich kontextuální propojení pomocí čár. Tím je
dosaženo stejného efektu jako v předchozí formě a navíc je tato forma pro čtenáře, nezávisle
na zkušenostech, intuitivnější a čitelnější. Její hlavní nevýhodou oproti formálnější, tabulkové
metodě je absence slovního popisu, který se občas, alespoň v malé míře může hodit. Nicméně
spousta dnešního softwaru disponuje možnostmi tyto mapy o slovní popis doplnit.
Pro účely této práce jsem si zvolil cestu myšlenkových map. V dnešní době se jedná o velmi
používanou agilní metodu, která si našla v projektovém řízení své místo. Pro ilustraci zde
uvádím, jak vypadá aplikace této mapy v rámci této práce. Mapa není úplná, jelikož je poměrně
rozsáhlá a zabírala by příliš prostoru. Pro případný zájem, přikládám kompletní WBS v příloze.
Obrázek 3-2:Část vypracovaného projektu pomocí WBS (Zdroj: vlastní tvorba)
3.1.2 Komunikační prostředky se zákazníkem
Předpoklad pro úspěšné dosažení cílů projektu, bylo nutné správné nastavení komunikace se
zákazníkem. Vytvořil jsem jednoduchý návrh, který obsahoval několik možností, jak by
komunikace mohla probíhat, tento návrh jsme si se zákazníkem na schůzce prošli
a odsouhlasili nejlepší variantu.
37
Schůzky – Hlavní výhodou je osobní kontakt se zákazníkem, vyjadřovací schopnost,
která se dá jen obtížně nahradit IM komunikací, popřípadě online konferencemi. Na
druhou stranu se jedná o časové náročný model, nutná přítomnost všech důležitých
osob, kterých se projekt týká (stakeholdeři).
Online konference – Oproti schůzkám, je tento model jakýmsi kompromisem, co se
organizačních požadavků týče. Bohužel dochází ke snížení vyjadřovací schopnosti,
kontakt se zákazníkem je omezený.
IM komunikace – Tato komunikace má velkou výhodu v tom, že přímo nevyžaduje
přítomnost příjemce informací, který může reagovat, až když bude mít čas. Velkým
omezením je paradoxně samotná výhoda. Může docházet k časové režii způsobené
nutným hlídáním odpovědí na dotazy apod. Dále vyjadřovací schopnost je velmi
omezená, jelikož psaní je pomalé, zdlouhavé a dochází tak k vyjádření minima
informací, což by mohlo mít vliv na projekt (hrozba).
3.1.2.1 Slack
V rámci trvání projektu jsme se dohodli na způsobu komunikace formou pravidelných schůzek
v rozumné intenzitě jedenkrát za tři týdny. Pro ostatní nutnou komunikaci jsme zvolili
IM službu Slack. Touto kombinací jsme dosáhli kompromisu mezi časovou a organizační
náročností.
Možnosti této služby jsou mnohem rozsáhlejší než by se od běžných IM komunikátorů
očekávalo. Služba je bezplatná, má jednoduché ovládání a pro zahájení stačí pouze zadat název
týmu a přizvat účastníky. Rozšíření, které přispěly k volbě tohoto komunikátoru:
Pokročilá skupinová vlákna (channels, ve výchozím nastavení jsou k dispozici
#random a #general), která trvají po celou dobu existence týmu. Vytvořili jsme
jednoduchou strukturu pro uchovávání informací ohledně požadavků na projekt,
vytvořením dvou skupinových vláken
o #business-pozadavky slouží pro zjištění aktuálních potřeb zákazníka
a vytvoření KPI
38
o #technicke-specifikace obsahují veškeré informace od uživatelských údajů
a oprávnění k reklamám, až po technické vlastnosti serveru, jako jsou OS,
možnosti nasazení apod.
Obrázek 3-3: Skupinová vlákna (Zdroj: vlastní zpracování)
Nahrávání souborů povyšuje tuto službu až na úroveň jednoduchého DMS (systém
pro správu dokumentů). Nejedná se samozřejmě o plnohodnotný DMS systém, ale díky
možnosti permanentního ukládání souborů do skupin, celého týmu a také pokročilému
vyhledávání se o jednoduchém systému hovořit dá.
Obrázek 3-4: Sdílení, nahrávání souborů (Zdroj: vlastní zpracování)
Vyhledávání patří mezi výborné vlastností této služby, jelikož vyhledávání probíhá
napříč všem skupinám a dokumentům a my tak můžeme získat maximum shod.
39
Obrázek 3-5: Silné vyhledávácí schopnosti (Zdroj: vlastní zpracování)
3.2 Analýza datových zdrojů
V následujících podkapitolách se věnuji podrobné analýze datového zdroje, který jsem použil
pro tvorbu interpretace KPI. Jedná se o externí datový zdroj Facebook Ads API.
3.2.1 Facebook
Facebook nabízí 2 možnosti jak přistupovat k datům reklam:
Ads Manager
Marketing API
Každá z těchto možností má svá pro a proti, které si přiblížíme.
3.2.1.1 Ads Manager
Jedná se o webový nástroj, jehož hlavní výhodou a cílem je tvorba a správa reklamních
kampaní a sestav. Tento webový nástroj slouží jako hlavní nástroj pro správu placených
reklam. Každá reklama se skládá z:
1. Reklamní kampaň je počáteční bod, který musíme vytvořit. Kampaň je skupina množin,
které se týkají stejného obchodního záměru. Každá kampaň má svá kritéria (rozpočet,
primární účel apod.), která musí být dodržena všemi skupina uvnitř kampaně. Můžeme mít
více kampaní, každá může cílit na jiný segment. Analýzou jsme zjistili, že společnost má
40
vytvořené 2 kampaně, přičemž jedna z nich je již neaktivní a používá pouze kampaň
s názvem „recyklovane“. Mimo jiné má kampaň přiřazené jedinečné číslo, které je vhodné
využít hlavně pro vývojářské účely (nezávisle na změně názvu kampaně, číslo zůstane
stejné) [17].
Obrázek 3-6: Kampaně a jejich správa (Zdroj: vlastní zpracování)
2. Reklamní skupiny jak již bylo naznačeno výše, spadají pod kampaně, a musí tak dodržet
nadřazená kritéria. V podstatě se jedná o skupinu reklam, které sdílí denní, nebo
celoživotní rozpočet, časové plánování, typ aukce a cílovou metriku [18]. Zjistili jsme, že
v tomto projektu se nachází 25 aktivních reklamních skupin.
Obrázek 3-7: Reklamní skupina (Zdroj: vlastní zpracování)
3. Reklamní objekt obsahuje nezbytné údaje pro vizuální zobrazení reklamy a asociováním
s patřičnou reklamní skupinou. Každá reklama je přidružená k reklamní skupině a všechny
reklamy ve skupině mají stejný denní, nebo celoživotní finanční rozpočet, časový plán,
cílovou metriku (každá skupina čítá okolo 30 reklam). Vytvářením víc reklam uvnitř
skupiny nám umožní optimalizovat jejich zobrazení, založené na variací obrázků, odkazů,
videí, textu a umístění [19].
41
Obrázek 3-8: Reklama v rámci skupiny (Zdroj: vlastní zpracování)
Organizační struktura reklam je logická a intuitivní. Nicméně jsme z předchozí části mohli
vypozorovat, že se jedná o speciální druh hierarchické struktury (obsahuje 3 úrovně: kampaně,
skupiny, reklamy), který zhoršuje čitelnost datové analýzy, viz Obrázek 3-9.
Ad Set 1
Ad Campaign
Ad Set 2 Ad Set 3
Ad 11 Ad 12 Ad 13 Ad 21 Ad 31Ad 22 Ad 23 Ad 32 Ad 33
Obrázek 3-9: Hierarchická (stromová) struktura Facebook reklam (Zdroj: vlastní tvorba)
Tím nejsou výsledky na první pohled zřejmé a v případě, že manažer nemá čas se analýze
podrobněji věnovat, může se stát, že tyto hodnoty již zůstanou ukryty. Z toho důvodu vznikly
požadavku na KPI, které by měli měřit výkonnost těchto reklam a hlavně jednoduše a intuitivně
interpretovat. K tomu účelu nám poslouží již v úvodu zmiňované Marketing API, které si nyní
probereme detailněji.
3.2.1.2 Marketing API
Ads Manager sice umožňoval stáhnout, exportovat (xls, csv formát) analytické informace, ale
export provázely různá nastavení, která zákazníka nakonec od exportu odradila. Na základě
42
těchto nevýhod jsme se snažili hledat alternativní řešení. Jeho součástí se nakonec stalo využití
tohoto API.
Pomocí tohoto přístupu jsme schopni provádět stahování analytických informací bez nutnosti
zásahu zákazníka, všechno se odehrává automatizovaně. Jedná se o technologii založenou na
HTTP REST API. Dotazy jsou tvořeny pomocí přesně definované struktury URL dotazu. Tato
struktura je odvozena od Graph API, jehož teoretické základy jsem nastínil v kapitole věnující
se teoretickým východiskám. Jelikož se jedná o HTTP REST API a princip dotazování je
založený na Graph API, je nutné vytvořit pravidla pro dotazování přes URL.
Všechny uzly a hrany můžeme jednoduše získat voláním HTTP GET požadavku. Struktura
těchto dotazů vypadá:
Obrázek 3-10:Obecná struktura dotazu [20]
Obrázek 3-11:Dosazení uzlu za request-path [20]
Obrázek 3-12: Dosazení uzlu a hrany do request-path [20]
Jelikož Facebook neustále pracuje na rozšiřování, vylepšování poskytovaných služeb
vývojářům, neustále dochází k úpravám rozhraní API a dokumentace, staré funkce přestávají
fungovat a přibývají nové. Proto je velmi důležité, aby každý tento požadavek byl doplněn
o verzi API, se kterým je voláno. Tímto zajistíme navrácení očekávaných výstupů. V době
vzniku tohoto projektu, této práce byla aktuální verze 2.6.
Abychom si mohli udělat lepší představu o fungování tohoto API předtím, než se pustíme do
zpracování tohoto zdroje, věnujeme pozornost prozkoumání základních principů tohoto
rozhraní. Marketing API nabízí několik odvětví, na které se můžeme zaměřit (správa reklam,
analytické údaje apod.). Nás budou zajímat analytické údaje, které v tomto rozhraní najdeme
pod Insights API.
K těmto účelům nám poslouží webový nástroj Facebooku, který se jmenuje
Graph API Explorer. Než začneme tento nástroj využívat, musíme provést pár kroků a to:
43
získat od zákazníka účet, který bude mít s reklamou přidružená oprávnění,
přístupový řetězec a
oprávnění číst reklamní informace.
Přístupový řetězec (access token) získáme vygenerováním v nástroji. Tento token má platnost
pouze hodinu až dvě (při implementaci skriptu uvažujeme využít long term access token, který
má už snesitelnější dobu platnosti 60 dní). Posledním krokem zbývá nastavit správná oprávnění
a v případě čtení analytických informací reklam se konkrétně jedná o „read_insights“
a „ads_read“.
Obrázek 3-13:Vygenerování přístupového řetězce, oprávnění (Zdroj: vlastní zpracování)
Nyní můžeme přistoupit k volání metod onoho API. Způsob byl obdobný jak v případě Ads
Manageru, s drobnými odlišnostmi. Nejdůležitější okamžik nastal ve chvíli, kdy jsme se
dostali na hledanou úroveň dat. Museli jsme zvolit metriky a dimenze, které budeme v rámci
definovaných KPI potřebovat. Jednalo se o poměrně časově náročný úkol, jelikož znalosti
tohoto nástroje byly omezené a musel jsem metriky zkoumat. Tyto metriky jsme musely pro
účely splnění KPI vhodně zvolit. Výsledkem jsou následující metriky, viz Obrázek 3-14.
44
Obrázek 3-14: Graph API, analytické informace a metriky (Zdroj: vlastní zpracování)
Jediné parametry date_stop a date_start se netýkají KPI, ale jedná se o časovou dimenzi nutnou
pro vytvoření datového skladu DW. Tento webový nástroj vrací výsledné analytické údaje
v JSON formátu a primárně jsou výsledky agregované (čehož si můžeme všimnout pomocí
položky paging ve vrácených datech dole). Z hlediska přidané obchodní hodnoty nemůžeme
být spokojeni, jelikož jsou data velmi obecná. Naštěstí je možnost vyžádat si detailní informace
k jednotlivým metrikám, které jsme uváděli výše.
Insights API, které využíváme, umožňuje zažádat si o podrobné informace některých metrik.
Tyto metriky jsou vráceny ve formátu JSON. Z hlediska našich ukazatelů se jedná například
o unique_actions, website_ctr a spousty dalších, o kterých si více povíme v následující
kapitole.
3.3 ETL proces
Takto kapitola se zabývá procesem stažení, transformací a uložením dat do integrovaného
zdroje dat, nazývaným ETL. Výstupem jsou skripty, které tyto činnosti provádí autonomně a
jsou spouštěny dávkově bez nutnosti zásahu další osoby.
3.3.1 Extrakce
Z předchozích částí návrhu již jsme se seznámili s možnosti extrakce analytických informací
týkající se Facebook reklam. Jelikož nejsou dostupná řešení vyhovující, ať už se jedná o první
45
případ, kdy je těžké se vůbec k datům dostat, nebo druhý případ, kdy jsou vyžadovány
pokročilé programátorské znalosti, rozhodli jsme se pro tvorbu dávkově spustitelného skriptu,
pomocí kterého budou data stahována a ukládána do dočasných souborů, které poslouží pro
následnou transformaci a uložení do databáze.
Než přejdeme k popisu konstrukce samotného extraktoru analytických dat, je nutné si vysvětlit
nutné předpoklady, které musí být splněny, aby bylo vůbec možné, extraktor použít.
Komunikace s Facebook Insights API je možná pouze pro autorizované Facebook aplikace.
Tuto aplikaci je nutné vytvořit ve webovém prostředí, které je dostupné pro vývojáře,
viz Obrázek 3-15.
Obrázek 3-15: Vytvoření nové Facebook aplikace (Zdroj: vlastní zpracování)
Jakmile začneme s vytvářením nové aplikace, musíme vybrat platformu, na kterou bude naše
aplikace zaměřena. Naše aplikace je skript, který běží v pozadí na počítači. Tím pádem
nevyhojuje žádná z níže uvedených variant našim potřebám, a proto zvolíme základní
nastavení „basic setup“, viz Obrázek 3-16. Dále následují nastavení pro zařazení aplikace do
kategorie, určení jedinečného názvu aplikace, přiřazení do prostoru názvů (namespace) a také
velmi důležité krok, týkající se určení verze API, kterou bude aplikace využívat. Verzi je nutné
zvolit, protože Facebook neustále vydává nové obohacené verze, které už nemusí podporovat
některé funkce, nebo vracejí výsledky v jiném formátu, než jsme momentálně schopni
zpracovat. Z důvodů zpětné kompatibility, je vyžadováno, aby aplikace měla napevno
stanovenou verzi rozhraní, kterou bude využívat. Po vyplnění všech těchto kroků se dostáváme
k možnosti nechat si vygenerovat identifikační číslo aplikace.
46
Obrázek 3-16: Výběr platformy pro vývoj aplikace (Zdroj: vlastní zpracování)
Jakmile je naše aplikace vytvořená, má kromě vygenerovaného App ID navíc i řetězec
„App Secret“. Tento řetězec je velmi důležitý, přikládá se při autentizaci aplikace vůči API
rozhraní, viz Obrázek 3-17 (Za pozornost stojí již dříve zmiňovaná verze rozhraní).
Obrázek 3-17: Facebook aplikace s app id, secret a verzí používaného API (Zdroj: vlastní zpracování)
Jelikož se jedná o citlivé informace zákazníka, měli bychom věnovat zabezpečení maximální
pozornost. Z tohoto důvodu provedeme ještě jeden krok, než se pustíme do popisu samotné
extrakce promocí námi vytvořeného extraktoru. V této chvíli se aplikace vůči API rozhraní
prokazuje za pomocí App ID a přístupového řetězce (access token). Zabezpečení můžeme
vylepšit dvěma způsoby:
Nastavením příznaku pro zabudování App Secret řetězce do aplikace a využít speciální
„client token“, který je uzpůsoben pro použití v aplikacích.
Obrázek 3-18:Pokročilé zabezpečení komunikace mezi klientskou aplikací a API rozhraním
(Zdroj: vlastní zpracování)
47
Omezením aplikace na konkrétní identifikátor reklamy.
Obrázek 3-19: Omezení přístupu aplikace na uvedené reklamní účty (Zdroj: vlastní zpracování)
Tímto bychom měli mít aplikaci z hlediska bezpečnosti proti případnému úniku informací
dostatečně zabezpečenou. Posledním krokem je otestování, zda vše, co jsme nastavovali,
funguje dle očekávání. K tomu využijeme nástroj Graph API Explorer. Za jeho pomoci
můžeme otestovat správnou funkčnost vytvořené aplikace pro přístup k analytickým datům,
viz Obrázek 3-20.
Obrázek 3-20: Test funkčnosti vytvořené aplikace pro přístup k datům (Zdroj: vlastní zpracování)
Z výstupů jsme si potvrdili správnost nastavení aplikace a můžeme použít vygenerované
řetězce v našem extraktoru (Je nutné si uvědomit, že aplikace se vztahují k Facebookovému
účtu. Z toho plyne, že aplikace buď musí být vytvořená pod stejným účtem, kde jsou reklamy
vedeny, nebo musí být účtu přidělena patřičná oprávnění pro přístup k reklamám).
Pro vytvoření skriptů jsme zvolili skriptovací jazyk Python. Tento jazyk je díky své konstrukci
velmi vhodný pro tvorbu takových nástrojů. Může za to fakt, že se jedná o interpretovaný jazyk
(řádky kódu jsou překládány počítačem až za běhu) a také jeho pokročilá podpora datových
48
typů (anonymní proměnné, vestavěná podpora pro JSON a další). K tomu se jedná
o multiplatformní jazyk, který je dostupný na všech známých operačních systémech. Instalace
interpretu a potřebných knihoven byla intuitivní a rychlá.
V rámci této práce jsem využil Python verze 2.7. Pro instalaci jsem zvolil oficiální interpret
jazyka pro platformu Windows, na které jsem řešení vyvíjel (instalace proběhla bez problémů
bez nutnosti větší interakce).
Po instalaci nastala menší komplikace. Při snaze o ověření úspěšnosti instalace, jsem nebyl
schopen interpret přes příkazovou řádku spustit. Na vině byl chybějící záznam cesty
k interpretu v systémové proměnné PATH. Po doplnění tohoto záznamu jsme úspěšně ověřili
funkčnost nainstalovaného jazyka.
Obrázek 3-21:Nastavení cesty pro běhové prostředí jazyka Python (Zdroj: vlastní zpracování)
Z výše uvedeného obrázku vidíme nastavení systémové proměnné PATH. Dalším krokem je
doinstalování nutných knihoven, které využíváme v našem projektu. Jedná se o:
FacebookAds – Jedná se o knihovnu zprostředkovávající komunikaci mezi naším
skriptem a Insights API rozhraním.
Unicodecsv – Pomocí této knihovny máme možnost získané analytické údaje
jednoduše uložit do formátu csv.
uuid – Knihovna slouží pro generování náhodných, jedinečných identifikátorů.
Z počátku jsem se potýkal s nejasností, jakým způsobem tyto knihovny nainstalovat, jelikož
jsem všechny knihovny našel v podobě zdrojových souborů a netušil, co s nimi dělat. Díky
tomu jsem objevil nástroj, který slouží pro instalaci a správu balíčků, který se jmenuje PIP
(jedná se o balíčkovací systém pro Python). Tento nástroj jsem doinstaloval stejným způsobem
jako v případě instalace interpretu.
49
PIP se stará o správnou instalaci knihoven, jejich aktualizaci a případně i úplné odstraňování.
Po hlubším zkoumání jsem zjistil, že se jedná o pouhé kopírování zdrojových souborů
knihoven do složky knihoven uvnitř instalace skriptovacího jazyka (C:\Python27\Lib\).
Obrázek 3-22: Demonstrace instalace knihoven pomocí PIP nástroje (Zdroj: vlastní zpracování)
Díky tomu jsme byli schopni rychle zahájit vývoj a získat tak co nejdřív možnost, osvojit si
práci s externím zdrojem dat. Softwarová architektura skriptu je založena na rozdělení skriptu
do bloků, které autonomně zajišťují jednotlivé činnosti, viz Obrázek 3-23 (skript je vytvořen
takovým způsobem, aby bylo do budoucna možné jeho rozšíření a oddělení jednotlivých
komponent do samostatných skriptů, modulů).
Obrázek chronologicky znázorňuje jednotlivé fáze skriptu k získání a uložení analytických
informací z Facebook Ads pro společnost Toprecepty.cz.
Smyslem této kapitoly není, čtenáře zatěžovat čtením programátorských kódů. Úryvky slouží
pouze k ilustrativním účelům. Po dočtení této kapitoly by měl být čtenář obeznámen
s procesním tokem a principem jednotlivých fází extraktoru dat.
50
Obrázek 3-23: Softwarová architektura skriptu pro extrakci dat pomocí sekvenčního diagramu jazyka
UML (Zdroj: vlastní tvorba)
51
Fáze 1: Přístupový řetězec (long term access token). Na úplném začátku procesu extrakce
dochází k načítání konfiguračního souboru (ve formátu JSON), ze kterého se čtou údaje,
jakými jsou App ID, App Secret, Client Token, Access Token a další. V tuto chvíli nám jde
hlavně o Access Token. Ten má určitou dobu platnosti (v době vývoje byla stanovená doba na
60 dní, ale není zaručená její neměnnost). Pokud ho skript v konfiguračním skriptu není
schopen najít, pokusí se tento token získat pomocí autentizace přes Facebook Login pomocí
uživatelského účtu, který je s reklamou provázaný. Pokud se nám podaří aplikaci úspěšně
přihlásit, získáme onen long term access token, díky kterému můžeme dále pokračovat (pouze
jsme se přihlásili do služby).
Obrázek 3-24: Načtení, získání přístupového řetězce (Zdroj: vlastní zpracování)
Ihned po jeho získání, uložíme řetězec do konfiguračního objektu a následně zapíšeme
aktualizované údaje pomocí souborového systému.
Fáze 2: Vytvoření spojení (session) mezi skriptem a API. Po získání přístupového řetězce,
můžeme začít komunikovat s rozhraním Insights. K tomu využíváme knihovny FacebookAds,
která je dostupná ke stažení přímo na vývojářských stránkách Facebooku. Instalaci,
zprovoznění jsme se věnovali výše v této podkapitole. Pro navázání komunikace s rozhraním,
použijeme:
App ID, Secret slouží pro ověření skriptu. Insights API může tímto způsobem ověřit,
že se jedná o vestavěnou aplikaci (popis vestavěné aplikace, vytvoření popisuji výše
v této podkapitole).
Access Token slouží pro omezení doby platnosti vestavěné aplikace a po vypršení této
doby (v případě dlouho trvajícího řetězce je doba platnosti 60 dní) je nutné získat nový
řetězec, který prodlouží platnost aplikace.
52
Obrázek 3-25: Navázání spojení s Insights API (Zdroj: vlastní zpracování)
Po úspěšném navázání sezení můžeme začít s dotazováním vůči rozhraní. Prvním takovým
dotazem je dotaz na uzel vlastního účtu (Z teoretické části víme, že dotazy, které na rozhraní
zasíláme, jsou překládány do podoby, které jsou interpretovatelné jako sociální graf,
viz Facebook Graph API). Tím máme vše připravené pro následující fázi.
Fáze 3: Reklamní účty. Dalším krokem v komunikaci mezi extraktorem a rozhraním, je získání
přiřazených reklamních účtů s uživatelským účtem. S účtem je spojeno víc reklamních účtů
a my musíme vybrat ten správný, který obsahuje analytická data reklam receptů. Při analýze
jsme zjistili, správný účet (k ostatním jsme neměli přístup). Číslo tohoto účtu máme uložené
v konfiguračním souboru a při procházení účty hledáme shodu.
Obrázek 3-26: Získání reklamního účtu (Zdroj: vlastní zpracování)
Fáze 4, 5: Získání reklamní kampaně, zápis kampaně. Nacházíme se ve fázi, kdy máme přístup
k reklamním kampaním. Z analytického hlediska nejsou nijak významná, ale my je využijeme
pro vytvoření lepší čitelnosti a zařazení analytických informací, které získáme v následující,
poslední fázi extrakce.
53
Obrázek 3-27: Zápis kampaní do výstupní složky (Zdroj: vlastní zpracování)
Fáze 6: Stažení analytických informací o jednotlivých metrikách. V této poslední fázi se
zabýváme stažením obecným i podrobných informací námi zvolených dostupných metrik.
Insights umožňuje nad určitou množinou metrik provést jejich další rozpad (breakdown). Popis
těchto metrik si více přiblížíme při shrnutí architektury a fungování extraktoru.
Obrázek 3-28: Úryvek kódu zápisu analytických informací získaných z reklamní kampaně
(Zdroj: vlastní zpracování)
Nyní bychom měli mít povědomí o tom, jak extraktor funguje, jaké jsou důležité fáze, bez
kterých není možné data z externího zdroje získat. Navíc jsou k dispozici ilustrativní úryvky
kódu, které mohou čtenáře navést, jak takový extraktor implementovat.
Ještě než tuto kapitolu opustíme, musíme si ukázat strukturu a popis výstupu tohoto extraktoru,
na kterou navážeme v následující části, věnované transformaci a uložení dat.
Našemu extraktoru můžeme zadat vstupní parametry, pomocí kterých můžeme přizpůsobit
jeho chování. Jedním z nich je parametr s cestou, kam se mají uložit výstupní soubory
54
s analytickými informacemi (výchozí chování ukládá výstupní soubory do stejné složky, kde
se nachází extraktor).
Obrázek 3-29: Souvislosti jednotlivých souborů (Zdroj: vlastní tvorba)
Na Obrázek 3-29 můžeme vidět, s jakými částmi extraktor pracuje (config, log), jaké jsou
výstupy a jejich vazby. Nyní si jen ve zkratce něco o těchto souborech povíme:
config – Jedná se o konfigurační soubor extraktoru, pomocí něhož získáváme uložené
informace, jako jsou přístupové údaje. Podrobněji jsme o konfiguračním souboru
mluvili výše v této podkapitole.
log – Tento soubor slouží pro zaznamenávání výsledku fází skriptu. Výhodou tohoto
souboru je možnost, rychle dohledat chybu v procesu a provést její nápravu.
campaigns – Záznamy o reklamních kampaních, které jsme si popsali v kapitole Ads
Manager. Je to první výstup, který extraktor generuje. Tyto kampaně nemají sice větší
analytický význam, pouze nám poslouží k jednoznačnější interpretaci výsledků.
insights – Tyto informace (postřehy) obsahují agregované hodnoty metrik, které jsme
vybrali na základě KPI, viz Obrázek 3-14. Pro naše účely se jedná pouze o rozcestí
a všechny hodnoty pro výpočet vzorců KPI budeme hledat v rozpadech těchto metrik.
insight_actions – Podrobný rozpad (breakdown) hlavních insights. Tento rozpad se
zaměřuje na akce, které návštěvník provedl. Tyto akce mohou být:
55
o page_engagement – Počet návštěv stránek (díky reklamě).
o post_engagement – Počet zhlédnutí příspěvku.
o link_click – Počet kliknutí na odkaz.
insight_website_ctr – Poměrový ukazatel počtu kliknutí na odkaz vůči celkovému
počtu zhlédnutí.
insight_unique_actions – Obdobné informace jako insight_actions s tím rozdílem, že
jsou zachyceny pouze jedinečné akce (může se vyskytnout situace, kdy návštěvník
provede akci vícekrát).
insight_cost_per_action_type – Poměrový ukazatel, vyjadřující cenu akce
návštěvníka (na reklamu je vyhrazena určitá finanční částka. Tato částka je podělena
celkovým počtem akcím a získáme tak cenu za akci návštěvníka).
insight_cost_per_unique_action_type – Stejný princip jak v předchozím případě
s tím rozdílem, že finanční částku dělíme jedinečnými akcemi.
Názvy výstupních souborů se mohou jevit jako poněkud nešikovné, ale je to záměr, který si
více přiblížíme a využijeme v následující části.
3.3.2 Transformace a uložení
Z předchozí části už víme, jakým způsobem se data stahují, kde mohou být uloženy a jaké
informace jsou v datech ukryty. Nyní si musíme říct, co všechno je potřeba k tomu, abychom
tyto data přenesly do databáze pro následné zobrazení.
Pro tyto účely jsem opět použil skriptovací jazyk Python. Oproti skriptu pro extrakci dat, se
zde vyskytují pouze jednoduché činnosti, kterým není třeba věnovat takovou pozornost, jako
tomu bylo v předchozím případě.
Použití knihoven třetích stran:
unicodecsv – Pomáhá k lepší práci s datovými soubory csv formátu (načítání vstupních
souborů z předchozí části).
56
psycopg2 – Knihovna (ovladač) pro přístup k PostgreSQL databázi. Tuto databázi jsme
si zvolili, jelikož je zadarmo a obsahuje zajímavé funkce, které jsme měli možnost při
vývoji použít. Více o této databázi si povíme v části věnované tvorbě jednoduchého
datového skladu a tvorbě reportů.
Obrázek 3-30: uložení analytických dat do DB (Zdroj: vlastní zpracování)
Z výše uvedeného obrázku můžeme vidět procesní tok. Nejprve dochází k vytvoření spojení
s databází (datovým skladem). Jak vidíme, jsme schopni bez problému zjistit přihlašovací
údaje k DB. Na tomto bychom měli zapracovat a v dalším rozvoji se pokusit tyto řetězce
ukládat pod šifrou, kterou bude znát pouze skript a nebude možné ji jen tak získat.
Dalším krokem je prohledávání zdrojové složky na datové soubory, které by měly sloužit pro
získání dat k uložení do DW. Struktura názvu těchto souborů je upravena tak, abychom
zamezili špatné interpretaci, která často vzniká zanesením znaku mezery. Proto jsme v názvech
souborů použili podtržítka, která tento jev eliminují.
Následuje čtení prvního řádku souboru (hlavičky s názvy sloupců). Zde bych rád zmínil, co
jsem rozebíral již na začátku kapitoly Vlastní návrhy a řešení. Jedná se o nutnou spolupráci
(synergii) mezi datovým skladem a ETL procesem. Toto řešení je založeno na následujících
axiomech (axiom je tvrzení, které se pokládá za pravdivé a dále se nezpochybňuje):
57
Extraktor generuje výstupní soubory v určitém formátu, které jsou fixně dány. Formát
spočívá ve spojení slova insight s konkrétním rozpadem (spojení a mezery jsou
nahrazeny podtržítky).
Skript pro uložení do DB, tyto soubory vnímá pouze jako obecné csv soubory
(nepřikládá jim žádný kontextový, analytický význam).
Skript pro uložení, tyto soubory ukládá po řádcích do tabulek, které mají stejný název
jako soubory.
Z výše uvedeného, vidíme nutnost dodržet shodu mezi názvy výstupních souborů extraktoru
a názvů tabulek DW.
Na závěr skriptu vidíme, jak dochází k plnění kurzoru daty ze souboru, následným odesláním
a potvrzením. Jediné, co je zde programově upravováno, vytvářeno je počáteční datum. Datum
je vytvářeno, pouze pokud se jedná o hlavní, agregovanou tabulku informací insights. Tento
údaj je nutný, pro napojení tabulek faktů s tabulkou dimenzí (časovou).
Činnost skriptu poukazuje pouze na část uložení, procesu ETL. Očividně skript neřeší
transformaci, která by měla proběhnout, abychom měli data v DW integrovaná. Jelikož
pracujeme pouze s jedním datovým zdrojem, zvolili jsme data do DW uložit ve formátu
v jakém jsou, a transformaci dat na konkrétní datové typy ponechat až při zobrazování
v reportovacím nástroji.
3.4 Datový sklad pro analytické účely
Zatím jsme se seznámili s externím datovým zdrojem, vytvořili jsme v rámci ETL procesu
skripty, které data extrahují a ukládají do DW. Právě nastal ten správný okamžik přiblížit si
proces tvorby datového skladu, který jsme neustále zmiňovali v předchozích částech.
Datový sklad jsme postavili na databázi PostgreSQL. Mezi výhody, které přispěly ke zvolení,
patří:
Neomezená velikost databáze (omezení je, ale v našem případě je nereálné ho
dosáhnout).
58
Zcela zadarmo pro komerční účely. Pomohlo to ke snížení nákladů na pořízení, více v
Zhodnocení návrhu.
Ve spoustě případů se můžeme setkat s odlehčenými verzemi podnikových databází
velkých společností, kterými jsou Microsoft, Oracle, které mají spoustu velikostních
i výkonnostních omezení. U Postgre žádná taková omezení nejsou. Databázi je možné
přiřadit veškeré dostupné HW prostředky.
Datový sklad je zvláštní typ relační databáze upravený pro uchování, zpracování velkého
množství analytických dat. Rozdíly spočívají hlavně v normalizaci databáze. Zatímco
u nasazení relační databáze v hlavních procesech (OLTP) společnosti usilujeme o optimalizaci
datové struktury, kterou vyjadřujeme pomocí stupně normální formy (často postačuje splnění
třetí normální formy, označované jako 3NF). V případě využití databáze pro analytické účely
(OLAP) nás nezajímá stupeň normální formy, ale spíš jde o rozumné propojení entit, abychom
měli možnost data různě tvarovat a zobrazovat informace z různých úhlů pohledu. Toho
dosahujeme pomocí vytvořením tabulek faktů a dimenzí.
Hlavními technikami pro modelování datového skladu je uspořádání tabulek faktů a dimenzi
podle dvou různých schémat:
Schéma hvězdy – je velmi jednoduchá technika jak vytvořit základní strukturu
datového skladu. Představme si, že uprostřed našeho schéma je tabulka faktů, která má
okolo sebe připojeno 1 až N tabulek dimenzí, pomocí cizích klíčů. (Proto se této
modelovací technice říká schéma hvězdy). Toto schéma použijeme i na náš projekt
s tím rozdílem, že propojení mezi tabulkami dimenzí a faktů nebudeme vytvářet
staticky pomocí cizích klíčů, ale až při sestavování dotazů.
Schéma sněhové vločky – vychází ze schématu hvězdy. Odlišujeme se možností
zanořování tabulek dimenzí, tím dochází k vytvoření obrazce, který se podobá
strukturou sněhové vločky (příkladem by mohla být dimenze místo, která by mohla mít
na sebe napojenou další dimenzi popisující město). Pro náš projekt jsme vyhodnotili
sněhovou vločku jako zbytečně komplikovanou, jelikož náš datový sklad bude
jednoduchý a bude se hlavně opírat o časovou dimenzi.
Existují i další techniky jako je například „konstelace faktů“, ale tyto techniky v našem
projektu nemají opodstatnění, a proto jsme se rozhodovali pouze mezi výše uvedenými.
59
Výběrem vhodné techniky máme předpoklady splněny a můžeme přejít k návrhu logického
modelu a jeho následné realizaci.
3.4.1 Logický model
Logický model jsme vytvářeli na základě závazné struktury výstupních souborů extraktoru dat.
O tom, proč tomu tak je jsem mluvil na konci části Transformace a uložení. Model není
fyzickou implementací, pouze zachycuje entity (tabulky), vlastnosti (sloupce) a vazby
(v našem projektu jsou řešeny dynamicky pomocí dotazovacího jazyka SQL).
Obrázek 3-31: Logický model datového skladu (Zdroj: vlastní tvorba)
60
Z výše uvedeného vidíme, že model je založený na schéma hvězdy a tabulka dimenzí (čas),
je bez fixní vazby na tabulku faktů (insights). Názvy vlastností tabulek faktů jsou dodrženy dle
závazné formy skriptu pro extrakci.
Logický model jsme implementovali pomocí SQL skriptů, které následně vytvořili tabulky
DW. Sloupce těchto tabulek mají datový typ „text“. Pro naše účely to ničemu nevadí, jelikož
si datové typy určíme dynamicky při vytváření reportů.
Obrázek 3-32: Ukázka skriptu pro generování tabulek DW (Zdroj: vlastní zpracování)
3.4.2 Generátor hodnot časové dimenze
V části Logický model jsme si vysvětlili a zobrazili návrh modelu datového skladu. Principy
a implementaci řešení pro plnění tabulek faktů jsme pokryli v části Transformace a uložení.
Co jsme doposud nezmínili je řešení v podobě skriptu, který plní časovou tabulku (dimenzi)
hodnotami. V případě tabulek faktů nám plnění zajištuje skript pro uložení do DW. Časové
hodnoty musíme nechat generovat a být schopni vytvořit hodnoty pro všechny definované
sloupce dimenze. Po přemýšlení jsme vytvořili jednoduchý koncept plnění této dimenze a to
tak, že uživatel neřekne jinak, dojde k vygenerování a uložení hodnot v rozpětí dvou let,
počínaje dnešním datem. Jelikož pro účely tohoto projektu je to více jak dostačující, nevidíme
zde žádné omezení. Nicméně mi přišlo šikovné, aby bylo možné tyto parametry upravovat,
a proto jsem skript rozšířil o možnost zadat vstupní parametry, které umožní zadání
počátečního data a počtu generovaných dní.
61
Obrázek 3-33: Úryvek procesu tvorby hodnot všech sloupců dimenze (Zdroj: vlastní zpracování)
Z obrázku vidíme, jakým způsobem probíhá vytváření všech potřebných hodnot pro časovou
tabulku dimenzí. Takto naplněné proměnné odešleme v jednom příkazu do DW, dokud
nedojde k ukončení podmínky cyklu a k ukončení celého skriptu.
V této chvíli máme za sebou extrakci dat, vytvoření datového skladu a uložení těchto dat do
datového skladu. V rámci této práce nám z praktického hlediska zbývá tvorba reportů
v nástroji pro podporu rozhodování. O tvorbě a vybraném nástroji si povíme více v následující
části.
3.5 Tvorba reportů a dashboardů
Tato část se věnuje tvorbě reportů a nástěnek (dashboardů) v analytickém nástroji od
společnosti Microsoft s názvem Power BI. Součástí této podkapitoly je hlubší seznámení
s jednotlivými činnostmi, které jsme v tomto nástroji museli provést, abychom získali
požadované výstupy.
Tento nástroj je novinkou na trhu, který byl oficiálně na trh uveden 24.6.2015 [21]. Proč jsme
tento nástroj zvolili. Power BI poskytuje vedení účtu zdarma, uchování až 1GB dat, k dispozici
je webové a mobilní rozhraní, umožňuje přímé napojení na DB (samozřejmostí je podpora
postgres) a to nejdůležitější, podporuje velkou škálu grafických a výpočetních objektů, pomocí
kterých můžeme správně vypočítat a zobrazit výsledky KPI a to vše zadarmo, což má příznivý
dopad pro zákazníka.
62
Při grafické interpretaci KPI jsme se potřebovali lépe seznámit s možnostmi prostředí
Power BI, postupovali jsme následovně:
Možnosti napojení datového modelu s nástrojem,
úprava datových typů a modelu dle nutnosti (tento krok je fází ETL procesu a to
transformace),
tvorba reportů a nástěnek (dashboard) s filtry pro vytvořený datový model
Protože se jedná o důležitou část, v podstatě je to jediná věc, se kterou se zákazník dostane do
kontaktu (ostatní části ETL probíhají na pozadí a zákazník o nich neví), je nutné, aby výstupy
byly relevantní. To znamená, žádná na sebe navazující část se výstupem nesmí odchýlit od
stanovených požadavků, tím by se výstup následující části stal zkreslený a nemohli bychom
zobrazit relevantní informace. Proto si v následujících částech tyto činnosti postupně
probereme a vysvětlíme jejich úlohu v procesu tvorby reportů.
3.5.1 Možnosti napojení datového modelu
Napojení na různé datové zdroje jako jsou (Excel, SQL databáze, Facebook, Sharepoint, SAP
a další) nám zjednodušuje práci s napojením datového modelu. Nástroj je schopen si poradit
s konkrétní implementací datového zdroje a zobrazit jednotný relační model, viz Obrázek 3-34.
Obrázek 3-34: Napojení datových zdrojů (Zdroj: vlastní zpracování)
Po zvolení našeho datového zdroje (PostgreSQL), následoval výběr entit (tabulek), které jsme
chtěli do prostředí načíst. My jsme nechali načíst všechny dostupné tabulky. Hlavní bylo
63
nezapomenout načíst tabulku s časovou dimenzí. Po dokončení napojení, prostředí chvíli
trvalo, než zpracovalo všechny tabulky a vytvořilo odpovídající datový model ve svém
prostředí. Tím tato fáze končí, data jsou načtená v nástroji a můžeme přejít k dalšímu kroku.
3.5.2 Úprava datového modelu, datových typů
V současné chvíli máme v prostředí nově načtený datový model, který je momentálně otiskem
datového skladu. Z toho víme, že jsme datový sklad navrhovali takovým způsobem, aby nebyl
problém do něj uložit nová data, která by mohla mít odlišný datový typ. Proto jsme se pro
velkou většinu atributů, rozhodli použít datový typ Text. Díky tomu jsme docílili jednoduché
integrace změn, ale na druhou stranu jsme si znepříjemnili práci s hodnotami, jelikož se nám
nevyskytují ve správném tvaru (kontextu).
Pro tyto účely jsme sáhli po pokročilém editoru datového modelu (Query Editor). Tento editor
umožňuje velmi jednoduchým a intuitivním způsobem provádět všemožné úpravy tabulek.
Například výše zmiňovaná změna datové typu, seskupování řádků, rozdělení na více sloupců
podle definovaného oddělovače a mnohé další úpravy. Všechny provedené změny jsou nad
tabulkou uchovány v historii, kde je možné měnit pořadí a samozřejmostí je rušení
jednotlivých změn.
Obrázek 3-35: Editor datového modelu (Zdroj: vlastní zpracování)
V rámci stanovených KPI jsme museli změnit spoustu datových typů. Smyslem této práce není
procházet všechny změny, pouze demonstrovat o jaké změny se jedná a jak je lze dosáhnout.
Jednalo se například o atributy spend, total_actions, total_unique_actions, impressions, reach,
website clicks a další, které jsme museli přetypovat na číselné datové typy. Při změně na
desetinné číslo je třeba dbát zvýšené pozornosti oddělovače desetinného místa (pokud
například v textu budete používat tečku a lokalizaci nástroje budete mít v češtině, narazíte na
problém při převodu desetinného místa).
64
Obrázek 3-36: Transformace datových typů v pokročilém editoru (Zdroj: vlastní zpracování)
Těmito úpravami jsme provedli transformaci, kterou jsme vynechali ve skriptu, který prováděl
ETL proces. Nyní nám zbývá tvorba reportů a dashboardů.
3.5.3 Tvorba reportů a dashboardů
Aby měli reporty dobrou vypovídající hodnotu, zvolili jsme týdenní a měsíční období. K tomu
jsme využili předpřipravené hodnoty v tabulce dimenzí pro čas. Zde můžeme najít sloupce
určující číslo týdne a měsíce, které použijeme při každém reportu. Napojení na tabulky faktů
provedeme pomocí atributu date_key, který je reprezentuje číselnou hodnotu složenou ze dne,
měsíce a roku. Tím jsme schopni tuto hodnotu vytvořit ve všech tabulkách faktů a napojit je
tak na tabulku dimenzí.
Pro tvorbu reportů musíme postupně procházet jednotlivé KPI, které jsme si se společností
Toprecepty.cz definovali. Uvedeme si alespoň tvorbu jednoho ukazatele, abychom čtenáře
patřičně seznámili s procesem tvorby reportů v nástroji Power BI.
CPL = spend cost / total unique action. Tento ukazatel zobrazuje jakou částku je nutno
vynaložit pro získání unikátního návštěvníka. V editoru jsme pro výpočet této hodnoty museli
provést spoustu kroků. Propojení tabulek dimenzí a faktů. Přes editor je možné navolit
plnohodnotný Merge Join, který určí, v jaké relaci jsou hodnoty obou tabulek, viz Obrázek
3-37.
65
Obrázek 3-37: Merge Join tabulky dimenzí a faktů (Zdroj: vlastní zpracování)
Následoval výběr vhodných informací, které nás zajímaly v rámci zvoleného ukazatele (jelikož
se týdenní reporty od měsíčních liší převážně v seskupení podle atributů časové dimenze, bylo
vhodné volit operace tak, abychom získali u každého ukazatele šablonu, kterou jsme byly
schopni okopírovat).
Obrázek 3-38: Výběr informací, nachystání šablony pro reporty na týdenní a měsíční bázi
(Zdroj: vlastní zpracování)
Tímto jsme si vytvořili šablonu, která nám usnadnila tvorbu reportů na týdenní a měsíční bázi.
Nyní musíme provést samotný výpočet dle definovaného KPI (CPL v našem případě). Vzorec
je jednoduchý, jedná se o podíl hodnot dvou sloupců, viz Obrázek 3-39.
66
Obrázek 3-39: Výpočet hodnoty nového, vlastního sloupce (Zdroj: vlastní zpracování)
Jak můžeme z obrázku vidět, přidání nového sloupce a výpočet hodnoty je díky pokročilému
editoru uživatelsky velmi příjemný a napomáhá k rychlému vývoji řešení. Na Obrázek 3-40
vidíme, jakým způsobem jsou výsledná data pro report připravena.
Obrázek 3-40: Tvorba výsledné hodnoty týdenním seskupením (Zdroj: vlastní zpracování)
Dokončením těchto úprav máme výkonnostní ukazatel připravený a můžeme přejít ke
grafickému zobrazení ukazatele (reportu).
Report je graf, nebo tabulka, obsahující metriky, které byly sestrojeny k zobrazení
smysluplných analytických informací. Tyto informace potom slouží klíčovým osobám
k vyhodnocování. Report obsahuje jednu či více agregačních funkcí aplikovanou na číselné
proměnné. Pokud analyzujeme metriky s jinými atributy, nazýváme tyto data jako
„slicing and dicing data“ (řezání a krájení).
67
V prostředí Power BI je vytváření reportů velmi jednoduché. Na začátku máme k dispozici
volnou plochu, která tvoří základ pro dashboard (prostor, ve kterém jsou reporty uloženy.
Obvykle má podobu záložek, mezi kterými můžeme přepínat. Jednotlivé záložky obsahují
logickou sadu reportů). Vpravo se vyskytují dva hlavní panely, viz Obrázek 3-41. První z nich
slouží pro výběr zdroje (tabulky) analytických dat. Druhý panel slouží pro výběr vhodné
reprezentace dat. Na výběr je spousta grafů, jako jsou základní sloupcové, spojnicové až po
geografické mapy a v poslední době přibyla dokonce podpora pro skripty jazyka R.
Obrázek 3-41: Prostředí pro tvorbu reportů (Zdroj: vlastní zpracování)
Náš zvolený ukazatel (CPL) jsme se rozhodli interpretovat pomocí sloupcových grafů, které
jsou pro správné zobrazení vyhovující.
Nejprve v panelu s daty vybereme náš ukazatel, který chceme vykreslit. Po rozbalení ukazatele
vidíme datové položky, které jsou k dispozici.
Obrázek 3-42: Výběr datových polí pro graf (Zdroj: vlastní zobrazení)
68
Z výše uvedeného obrázku vidíme, že nad položkou CPL_week je zobrazen matematický znak
značící sumarizaci. Tento znak nám značí, že se jedná o položku, nad kterou můžeme provádět
součtové, sumarizační operace. Položka first_date_of_week je napojený atribut z časové
tabulky dimenzí. Jelikož nad datem není možné provádět součtové operace, tento znak tam
chybí.
Po výběru položek zaškrtnutím dojde k automatickému vytvoření grafu. Typ tohoto grafu je
vytvořen na základě vnitřní logiky tohoto nástroje. Nám byl vytvořen sloupcový graf,
viz Obrázek 3-43, který nám vyhovuje, a proto volbu měnit nebudeme (v případě, že bychom
chtěli zvolit jinou interpretaci, stačilo by pouze vybrat jiný druh a nástroj by už vše ostatní
zařídil, překreslil).
Obrázek 3-43: Zobrazení výkonnostního ukazatele CPL (Zdroj: vlastní zpracování)
Ve výše uvedeném obrázku vidíme zobrazené popisky dat, nadpis reportu. Tyto informace jsou
ve výchozím režimu vypnuté. My jsme tyto informace doplnili pomocí panelu pro výběr
grafické interpretace, o kterém jsme se zmiňovali již dříve.
Obrázek 3-44: Doplňující informace reportu (Zdroj: vlastní zpracování)
69
Tímto je tvorba reportu ukazatele CPL dokončena. Opakováním kroků úprava datového
modelu, konstrukce výkonnostního ukazatele a tvorba reportu, vytvoříme zbývající KPI, které
začleníme do patřičných dashboardů. Na závěr této části bych pro ilustraci uvedl, jak takto
vytvořený dashboard s reporty vypadá.
Obrázek 3-45: Dashboard s vytvořenými reporty, KPI (Zdroj: vlastní zpracování)
3.6 Zhodnocení návrhu
V dnešní době máme k dispozici spoustu podnikových nástrojů pro podporu rozhodování. Buď
se jedná o řešení, která rozšiřují stávající ERP systémy, jakým může například být
BI 4 Dynamics (staví na ERP systému Microsoft Dynamics NAV, AX), nebo samostatná
řešení od společnosti ADASTRA, která nabízí svá řešení postavená na různých technologiích.
Nicméně oba výše případy mají pár společných rysů. Jsou to výborná řešení pro velmi
pokročilé analýzy a s tím souvisí i pořizovací cena. Pokud bychom brali v úvahu první
zmiňované řešení, tak zjistíme, že nebude fungovat nad jinou databází než Microsoft SQL
Server. Licence a pořizovací náklady na tyto technologie se pohybují v řádu 100 tisíců. Taková
řešení volí pouze takové společnosti, pro které je klíčovým faktorem úspěchu zpracovávání
velkého množství detailních analýz.
Naše řešení jsme postavili na open-source technologii Python a cloudové službě od společnosti
Microsoft, Power BI (vedení jednoho účtu je zdarma). Oproti výše zmiňovaným řešením jsou
70
naše náklady minimální. Hlavním položku tvoří provozní náklad v podobě zajištění hostingu
serveru, kde poběží databáze se skripty ETL procesu. Nyní se pokusím objektivně ohodnotit
návrh řešení.
Mezi kladné stránky řešení patří:
Extrakce dat, generátor dimenze – Silnou stránkou je automatizovaná extrakce
analytických informací ze vzdáleného serveru Facebook Ads a nastavitelný skript pro
generování hodnot časové tabulky dimenzí.
Dostupnost výsledného řešení – Díky zvolené cloudové technologii máme přístup
k výsledným reportům ze všech dostupných platforem.
Přímé napojení na databázi – Jelikož jsou reporty přímo napojené na námi vytvořený
datový sklad, dojde při nahrání nových dat do datového skladu k automatickému
promítnutí změn do reportů, bez nutnosti zásahu jiných osob.
Architektura řešení – Zvolená kombinace technologií nabízí velký prostor pro rozvoj.
Vděčíme za to nízkým pořizovacím nákladům a rychlému vývoji reportů dle požadavků
společnosti.
Bohužel jako každé řešení, má i to naše, své slabší části, mezi které řadíme:
Škálovatelnost – V případě, že budeme chtít z externího zdroje dat stahovat nové
informace, bude nutné provést zásah, úpravu skriptu. Do nevýhody škálovatelnosti
neřadíme modifikaci datového skladu, v tomto případě by se jednalo už o pokročilý
flexibilní systém, který by bylo nákladné vyvinout.
Spolehlivost – Řešení nemá pokročilejší metodu pro hlášení výskytu neočekávaných
událostí. Hlavním způsobem hlášení je výpis událostí do logovacího souboru. Tím
bohužel nemáme k dispozici okamžité hlášení o výskytu události, ale za pomocí
vytvoření opatření v podobě průběžných kontrol, nám pomůže logovací soubor dříve
odhalit podstatu problému.
71
3.7 Přínos pro společnost
Pokusíme-li se vyjádřit přínos našeho řešení pro společnost Toprecepty.cz, rozdělil bych ho do
následujících částí:
Splnění stanovených KPI ukazatelů, viz Požadavky společnosti
Náklady na vlastnictví (TCO)
3.7.1 Splnění KPI ukazatelů
Abychom zajistili, že výstup odpovídá stanoveným potřebám společnosti, vytvořili jsme
jednoduchou dokumentaci (akceptační protokol), která popisovala jednotlivé ukazatele a jejich
výstupy. Dle této dokumentace jsme na závěr prošli všechny body a odsouhlasili si, že jsme
splnili všechny kladené body na řešení.
Zákazník hodnotil řešení velmi pozitivně. Dostupnost na mobilních platformách byla očividně
přidanou hodnotou, která byla kladně přijata. Koordinace s reportovacím nástrojem Power BI
nečinila žádnému z manažerů větší problém, kladně bylo hodnoceno intuitivní, responzivní
ovládání na tabletech a mobilních zařízeních.
3.7.2 Náklady na vlastnictví
Náklady na vlastnictví řešení se nám rozpadají do dvou základních rovin:
Návrh a vývoj řešení
Provoz a údržba
Při zahájení spolupráce s Toprecepty.cz jsem musel navrhnout obchodní model, který by
vyhovoval obou stranám. Bral jsem v úvahu začátečnické znalosti v oboru BI, které jsem chtěl
promítnout do ceny nabídky. Při průzkumu trhu jsem byl schopen zjistit obvyklé hodinové
sazby za implementaci BI řešení. Rozpětí bylo obrovské, jednalo se o částky od 700 až
3 500 Kč. V mém případě jsem zvolil částku 500 Kč za hodinu. Dále jsem stanovil
odhadovanou pracnost. Díky nabytým programátorským zkušenostem, nebyl s odhadem
pracností problém, celý vývoj jsem stanovil na 60 hodin práce.
72
Dalším bodem, který jsem musel v rámci nabídky řešit, byl provoz a údržba řešení. K provozu
řešení jsme se domluvili použít stávající server, který je spravován externím dodavatelem.
V rámci údržby jsme si stanovili měsíční paušál v hodnotě 500 Kč (1 hodina).
Celkové náklady na vlastnictví jsem stanovil následovně:
Tabulka 1: Výpočet TCO (Zdroj: vlastní tvorba)
Pořizovací náklady
Vývoj aplikace 30 000 Kč
Náklady na provoz
Měsíční poplatek za údržbu 500 Kč
Roční náklady na provoz 6 000 Kč
Z průzkumu, který jsem dělal za účelem získání představy o cenových relacích BI řešení jiných
dodavatelů, byly mnou stanovené podmínky bezkonkurenčně nejvýhodnější. Tento fakt se
nakonec promítnul pro společnost jako další přínos, jelikož nejen, že vykročila správným
směrem při získávání a zpracovávání analytických dat pomocí reportovacích služeb, ale navíc
se jí podařilo na řešení ušetřit nemalou částku.
73
Závěr
Cílem této diplomové práce bylo vytvořit Business Intelligence řešení pro společnost
Toprecepty.cz. Výsledné řešení bude tvořit základní platformu pro podporu rozhodování
managementu společnosti Toprecepty.cz. Všechny dashboardy obsahují grafy, zobrazující
analytické informace dat z internetových reklamních kampaní. Jedná se například o ukazatele
ceny za návštěvníka, akce, celkových investic, počtu uživatelů, kteří reklamu shlédli.
Na základě teoretických znalostí a analýzy potřeb společnosti jsem vytvořil
Business Intelligence řešení, které bylo v souladu se všemi podnikovými i technologickými
požadavky.
Tato práce splňuje uvedené cíle a výsledkem je řešení, které tvoří základ pro strategické a další
rozhodování, které může být více objektivní-datově řízené.
Celé řešení Business Intelligence je automatizované a do budoucna škálovatelně udržitelné.
To znamená, že všechny vytvořené reporty budou pro management společnosti dostupné,
dokud nedojde ke změně externího datového zdroje.
Řešení má velký potenciál k rozvoji. V současné chvíli zpracovává a zobrazuje data na základě
faktů. Návštěvnost webových stránek společnosti Toprecepty.cz se dnes nachází na tak vysoké
úrovni, že pro management společnosti se stává obtížné všechny informace sledovat
a vyhodnocovat. Takto dochází k situaci, že některé informace skryté v datech zůstávají zcela
nevyužité. Dalším vyhodnocením těchto informací se nám otevírá prostor k dalšímu
rozšiřování stávajícího řešení o prvky prediktivní analýzy, které by nám ukázaly obtížně
vysledovatelné trendy vývoje, a umožňovaly nám v předstihu provádět změny strategií
reklamních kampaní. V konečné fázi by řešení mohlo být natolik vyspělé, že by bylo schopno
na základě výsledků získaných prediktivní analýzou samostatně a bez zásahu člověka vytvářet
optimalizované reklamní kampaně, které budou pro společnost maximálně profitabilní.
74
Literatura
1. Novotný, O., Pour, J., David, S. (2005) Business Intelligence: Jak využít bohatství ve
vašich datech 1st edn. Grada Publishing, a.s., Praha, Česká republika.
2. Adastra Group Adastra Czech - Data Warehousing. In: Adastra Czech. Available at:
http://www.adastra.cz/847_data-warehousing-dodavka.aspx
3. Adastra Group Adastra Czech - Technologie Data Warehousingu a Data Miningu. In:
Adastra Czech. Available at: http://www.adastra.cz/192_technologie-data-
warehousingu-a-data-miningu.aspx
4. Lacko, L. (2003) Datové sklady analýza OLAP a dolování dat 1st edn. Computer Press,
Brno, Česká republika.
5. MSPS Data mining - MSPS.cz. In: Matematické a Statistické Projekty a Software.
Available at: http://www.msps.cz/data-mining/
6. Kimball, R., Ross, M. (2013) The Data Warehouse Toolkit. John Wile & Sons, Inc.,
Indianapolis.
7. Technology, Kenfo Kanfo BI Tool.
8. Titanium Consulting (Accessed 2014) BI Benefits. Available at:
http://www.businessintelligencesoftware.co/wp-content/uploads/2013/02/Benefits-of-BI-
Business-Intelligence.png
9. Schiff, J. (Accessed 2010) Business Intelligence Benefits. Available at:
http://www.enterpriseappstoday.com/business-intelligence/ten-benefits-of-business-
intelligence-software-1.html
10
.
LeBlanc, P., Moss, J. M., Sarka, D., Ryan, D. (2015) Applied Microsoft Business
Intelligence. John Wiley & Sons, Inc., Indianapolis.
11
.
Taylor, A. G. (2008) SQL for dummies 8th edn. John Wiley & Sons, Inc., , Hoboken,
River Street 111.
12
.
Larisa T. Moss, S. A. (2003) Business Intelligence Roadmap: The complete Project
Lifecycle for Decision-Support Applications. Addison Wesley.
13
.
Zahan, M. (2005) Predictive Analytics; the Future of Business Intelligence..
75
14
.
Scharzo, B. (Accessed 2014) Business Analytics: Moving From Descriptive To
Predictive Analytics. Available at: https://infocus.emc.com/william_schmarzo/business-
analytics-moving-from-descriptive-to-predictive-analytics/
15
.
Anasse Bari, M. CTJ. (2014) Predictive Analytics for dummies. John Wiley & Sons,
Inc.,.
16
.
Wikipedia Wikipedia - social graph. In: Wikipedia. Available at:
https://en.wikipedia.org/wiki/Social_graph
17
.
Facebook (Accessed V2.6) Facebook Campaign. In: facebook for developers. Available
at: https://developers.facebook.com/docs/marketing-api/reference/ad-campaign-group
18
.
Facebook (Accessed V2.6) Facebook Ad set. In: facebook for developers. Available at:
https://developers.facebook.com/docs/marketing-api/reference/ad-campaign
19
.
Facebook (Accessed V2.6) Facebook Ad. In: facebook for developers. Available at:
https://developers.facebook.com/docs/marketing-api/reference/adgroup
20
.
Facebook (Accessed V2.6) Graph API Overview. In: facebook for developers. Available
at: https://developers.facebook.com/docs/graph-api/overview
21
.
Microsoft (Accessed Červen 24, 2015) Microsoft Power BI Blog. In: Microsoft Power
BI. Available at: https://powerbi.microsoft.com/en-us/blog/announcing-power-bi-
general-availability-coming-july-24th/
22
.
Yukl, G. A. (2012) Leadership in Organizations 8th edn. Prentice Hall.
23
.
Inmon, W. H. (2002) Building the Data Warehouse 3rd edn. Wiley Computer
Publishing.
24
.
Power, D. J. (Accessed 2007) Brief History of Decision Support Systems. Available at:
http://dssresources.com/history/dsshistory.html
25
.
Boylan, C. (Accessed 1996-2015) Decision Support Systems. Available at:
http://www.informationbuilders.com/decision-support-systems-dss
26
.
Passionned group (Accessed 2015) List of Business Intelligence Tools. Available at:
http://www.passionned.com/business-intelligence/business-intelligence-tools/list-of-
business-intelligence-bi-tools/
27
.
Decision Innovation™ (Accessed 2009-2015) Emotional decision making can improve
decisions when managed as part of the process. Available at: http://www.decision-
76
making-solutions.com/images/DecisionMaking-Styles-Emotional-
PersonHoldingSmileyFaces-iStock_000009785996XSmall.jpg
28
.
Kardel, D. I., Chormanski, D. J., Miroslaw-Swiatek, D. D., Okruszko, P. T., Grygoruk,
M. M., Wassen, P. M. (Accessed September 9, 2011) Decision Support System for
Biebrza National Park. Available at:
http://www.intechopen.com/books/howtoreference/efficient-decision-support-systems-
practice-and-challenges-from-current-to-future/decision-support-system-for-biebrza-
national-park
29
.
Fayyad, U. M. (1996) From data mining to knowledge discovery: an overview..
30
.
Boris Kovalerchuk, E. V. (2002) Data Mining in Finance: Advances in Relational and
Hybrid Methods. Kluwer Academic Publisher.
31
.
Hurwicz, L. (Accessed 2006) Decision Trees. Available at:
http://vserver1.cscs.lsa.umich.edu/~spage/ONLINECOURSE/R4Decision.pdf
32
.
Jiawei Han, M. KJP. (2012) Data Mining: Concepts and Techniques: Concepts and
Techniques..
33
.
Srivastava, T. (Accessed 2013) Getting your clustering right. Available at:
http://www.analyticsvidhya.com/blog/2013/11/getting-clustering-right/
34
.
Gopalan & Sivaselvan, S. B,gNP. (2009) Data Mining: Techniques And Trends. Asoke
K. Ghosh, PHI Learning Private Limited, New Delhi.
35
.
Michael J. A. Berry, G. SL. (2004) Data Mining Techniques: For Marketing, Sales, and
Customer Relationship Management 2nd edn. Wiley Publishing, Inc., Indianapolis.
36
.
Bell, J. (2015) Machine Learning: Hands-on for developers and technical professionals.
John Wiley & ons, Inc., Indianapolis.
37
.
GoodData (Accessed 2013) CloudConnect core concepts. Available at:
https://developer.gooddata.com/article/intro
38
.
GoodData (Accessed August 30, 2013) CloudConnect. Available at:
https://developer.gooddata.com/images/uploads/cloudconnect.png
39
.
GoodData Corporation (Accessed 2007-2015) Data Loading / ETL. Available at:
https://developer.gooddata.com/docs/data-loading
77
40
.
GoodData Corporation (Accessed 2007-2015) Automating a Data Loading Process.
Available at: https://developer.gooddata.com/getting-started/tutorial/automate-data-
loading-process
41
.
GoodData Corporation (Accessed 2007-2015) Automate Data Loading Process.
Available at: https://developer.gooddata.com/getting-started/tutorial/automate-data-
loading-process
42
.
GoodData Corporation (Accessed 2013) CloudConnect LDM Modeler Guide. Available
at:
http://help.gooddata.com/doc/public/pdf/CloudConnect%20LDM%20Modeler%20Guid
e.pdf?
43
.
zentut.com (Accessed 2013) Data Mining Techniques. Available at:
http://www.zentut.com/data-mining/data-mining-techniques/
78
Seznam obrázků
Obrázek 1-1:Výhody Bussiness Intelligence [8] .................................................................... 16
Obrázek 1-2: Datové zdroje sloužící jako podklad pro datový sklad [10] ............................. 20
Obrázek 1-3:Hodnototvorný řetězec přizpůsobený od M. E. Porter, The Competitive
Advantage of Nations (New York: Free Press, 1990) ............................................................ 21
Obrázek 1-4:Externí okolí: Prvních pět působících sil bylo definováno Porterem, The
Competitive Advantage of Nations. Šestá síla byla definována D. R. Gnyawali a B. J. Park,
„Co-Opetition and Technology Innovations in Small and Medium-Sized Enterprises: A
Multilevel Conceptual Model,“ Journal of Small Business Management 47, no. 3 (2009):
308-30 ..................................................................................................................................... 22
Obrázek 1-5: Fáze inženýrského projektu [12] ...................................................................... 24
Obrázek 1-6: Sociální graf [16] .............................................................................................. 29
Obrázek 2-1: Organizační struktura společnosti (Zdroj: vlastní tvorba) ................................ 30
Obrázek 2-2:Struktura obchodního modelu (Zdroj: vlastní tvorba) ....................................... 32
Obrázek 3-1:Architektura řešení (Zdroj: vlastní tvorba) ........................................................ 35
Obrázek 3-2:Část vypracovaného projektu pomocí WBS (Zdroj: vlastní tvorba) ................. 36
Obrázek 3-3: Skupinová vlákna (Zdroj: vlastní zpracování) .................................................. 38
Obrázek 3-4: Sdílení, nahrávání souborů (Zdroj: vlastní zpracování) .................................... 38
Obrázek 3-5: Silné vyhledávácí schopnosti (Zdroj: vlastní zpracování) ................................ 39
Obrázek 3-6: Kampaně a jejich správa (Zdroj: vlastní zpracování) ....................................... 40
Obrázek 3-7: Reklamní skupina (Zdroj: vlastní zpracování) .................................................. 40
Obrázek 3-8: Reklama v rámci skupiny (Zdroj: vlastní zpracování) ...................................... 41
Obrázek 3-9: Hierarchická (stromová) struktura Facebook reklam (Zdroj: vlastní tvorba) ... 41
Obrázek 3-10:Obecná struktura dotazu [20] .......................................................................... 42
Obrázek 3-11:Dosazení uzlu za request-path [20] ................................................................. 42
Obrázek 3-12: Dosazení uzlu a hrany do request-path [20] ................................................... 42
Obrázek 3-13:Vygenerování přístupového řetězce, oprávnění (Zdroj: vlastní zpracování) ... 43
Obrázek 3-14: Graph API, analytické informace a metriky (Zdroj: vlastní zpracování) ....... 44
Obrázek 3-15: Vytvoření nové Facebook aplikace (Zdroj: vlastní zpracování) ..................... 45
Obrázek 3-16: Výběr platformy pro vývoj aplikace (Zdroj: vlastní zpracování) ................... 46
Obrázek 3-17: Facebook aplikace s app id, secret a verzí používaného API (Zdroj: vlastní
zpracování) .............................................................................................................................. 46
79
Obrázek 3-18:Pokročilé zabezpečení komunikace mezi klientskou aplikací a API rozhraním
(Zdroj: vlastní zpracování) ...................................................................................................... 46
Obrázek 3-19: Omezení přístupu aplikace na uvedené reklamní účty (Zdroj: vlastní
zpracování) .............................................................................................................................. 47
Obrázek 3-20: Test funkčnosti vytvořené aplikace pro přístup k datům (Zdroj: vlastní
zpracování) .............................................................................................................................. 47
Obrázek 3-21:Nastavení cesty pro běhové prostředí jazyka Python (Zdroj: vlastní zpracování)
................................................................................................................................................. 48
Obrázek 3-22: Demonstrace instalace knihoven pomocí PIP nástroje (Zdroj: vlastní
zpracování) .............................................................................................................................. 49
Obrázek 3-23: Softwarová architektura skriptu pro extrakci dat pomocí sekvenčního
diagramu jazyka UML (Zdroj: vlastní tvorba) ........................................................................ 50
Obrázek 3-24: Načtení, získání přístupového řetězce (Zdroj: vlastní zpracování) ................. 51
Obrázek 3-25: Navázání spojení s Insights API (Zdroj: vlastní zpracování) ......................... 52
Obrázek 3-26: Získání reklamního účtu (Zdroj: vlastní zpracování) ...................................... 52
Obrázek 3-27: Zápis kampaní do výstupní složky (Zdroj: vlastní zpracování) ...................... 53
Obrázek 3-28: Úryvek kódu zápisu analytických informací získaných z reklamní kampaně
(Zdroj: vlastní zpracování) ...................................................................................................... 53
Obrázek 3-29: Souvislosti jednotlivých souborů (Zdroj: vlastní tvorba) ............................... 54
Obrázek 3-30: uložení analytických dat do DB (Zdroj: vlastní zpracování) .......................... 56
Obrázek 3-31: Logický model datového skladu (Zdroj: vlastní tvorba) ................................. 59
Obrázek 3-32: Ukázka skriptu pro generování tabulek DW (Zdroj: vlastní zpracování) ....... 60
Obrázek 3-33: Úryvek procesu tvorby hodnot všech sloupců dimenze (Zdroj: vlastní
zpracování) .............................................................................................................................. 61
Obrázek 3-34: Napojení datových zdrojů (Zdroj: vlastní zpracování) ................................... 62
Obrázek 3-35: Editor datového modelu (Zdroj: vlastní zpracování) ...................................... 63
Obrázek 3-36: Transformace datových typů v pokročilém editoru (Zdroj: vlastní zpracování)
................................................................................................................................................. 64
Obrázek 3-37: Merge Join tabulky dimenzí a faktů (Zdroj: vlastní zpracování) .................... 65
Obrázek 3-38: Výběr informací, nachystání šablony pro reporty na týdenní a měsíční bázi
(Zdroj: vlastní zpracování) ...................................................................................................... 65
Obrázek 3-39: Výpočet hodnoty nového, vlastního sloupce (Zdroj: vlastní zpracování) ...... 66
Obrázek 3-40: Tvorba výsledné hodnoty týdenním seskupením (Zdroj: vlastní zpracování) 66
Obrázek 3-41: Prostředí pro tvorbu reportů (Zdroj: vlastní zpracování) ................................ 67
80
Obrázek 3-42: Výběr datových polí pro graf (Zdroj: vlastní zobrazení) ................................ 67
Obrázek 3-43: Zobrazení výkonnostního ukazatele CPL (Zdroj: vlastní zpracování) ........... 68
Obrázek 3-44: Doplňující informace reportu (Zdroj: vlastní zpracování) .............................. 68
Obrázek 3-45: Dashboard s vytvořenými reporty, KPI (Zdroj: vlastní zpracování) .............. 69
81
Seznam tabulek
Tabulka 1: Výpočet TCO (Zdroj: vlastní tvorba) ................................................................... 72
82
Seznam příloh
Příloha 1:Extraktor dat z Facebook Ads (Zdroj: vlastní zpracování) ........................................ I
Příloha 2: ETL proces (Zdroj: vlastní zpracování) ................................................................. IV
Příloha 3: Generátor hodnot časové tabulky dimenzí (Zdroj: vlastní zpracování) .................. V
Příloha 4: Datový sklad (Zdroj: vlastní zpracování) .............................................................. VII
Příloha 5: WBS (Zdroj: vlastní zpracování) ........................................................................ VIII
Příloha 6:Ukazatele CPL, CPA a celkové investice (Zdroj: vlastní zpracování) ................... IX
Příloha 7:Porovnání CPL, CPA vůči investici (Zdroj: vlastní zpracování) ............................. X
Příloha 8: Total vs unique impressions, konkrétní výběr (Zdroj: vlastní zpracování) ............ XI
83
Seznam použitých zkratek
ACID Atomicity, Consistency, Isolation, Durability
BI Business Intelligence
CSV Comma Separated Values
DM Data Marts
DQS Data Quality System
DSA Dynamic Storage Area
DW Data warehouse
EAI Enterprise Application Integration
ETL Extract, Transorm, Load
JSON Javascript Object Notation
KPI Key Performance Index
MDX Multidimensional Expression
MOLAP Multidimensional OLAP
NAS Network Storage Area
NoSQL No SQL
OData Open Data protocol
OLAP Online Analytical Processing
OLTP Online Transactional Processing
RAM Random Accress Memory
RDBMS Relation Database Management System
SQL Structured Query Language
WBS Work Breakdown Structure
XML Extensible Markup Language
I
Přílohy
Příloha 1:Extraktor dat z Facebook Ads (Zdroj: vlastní zpracování)
II
III
IV
Příloha 2: ETL proces (Zdroj: vlastní zpracování)
V
Příloha 3: Generátor hodnot časové tabulky dimenzí (Zdroj: vlastní zpracování)
VI
VII
Příloha 4: Datový sklad (Zdroj: vlastní zpracování)
VIII
Příloha 5: WBS (Zdroj: vlastní zpracování)
IX
Příloha 6:Ukazatele CPL, CPA a celkové investice (Zdroj: vlastní zpracování)
X
Příloha 7:Porovnání CPL, CPA vůči investici (Zdroj: vlastní zpracování)
XI
Příloha 8: Total vs unique impressions, konkrétní výběr (Zdroj: vlastní zpracování)
