V této části práce jsou popsány různé teoretické a technické přístupy ke stavbě datového skladu, na základě kterých je v další části práce vybráno nejlepší řešení pro firmu Epico vzhledem k jejich business požadavkům, organizační struktuře a celkové velikosti firmy.
Existují dvě hlavní teorie architektury datového skladu – Inmonova metoda a Kimballova metoda. Pro obě dvě metody je stěžejní jednotkou podnikové datové architektury datový sklad (DWH), ale liší se v přístupu, jak jsou jednotlivé komponenty DWH modelovány a jaké mezi sebou mají vztahy.
Podle Inmona je DWH centralizované uložiště dat pro celou organizaci tzn. „single point of truth“, z kterého čerpají všechny další komponenty analytického systému. Hlavními vlastnostmi Inmonova DWH je subjektová orientace, integrovanost a neměnnost v čase.
Subjektová orientace znamená zaměření na určitou oblast, kterou může být např. produkt, zákazník, dodavatel apod. Integrovanost znamená, že data z různých systémů jsou transformována a nahrána do jednoho skladu. Neměnnost v čase znamená, že na rozdíl od transakčních systémů se data v DWH už po nahrání nemění (Inmon, 2002).
Tím, že do DWH jsou nahrávána data ze všech relevantních transakčních systémů, je důležité, aby byla minimalizována redundance dat, a tím se zároveň optimalizovala celková velikost DWH. Proto DWH podle Inmona využívá k modelování datových struktur snowflake schéma.
Výhody Inmonova přístupu (Naeem, 2020):
▪ Datový sklad je „single point of truth“, protože obsahuje všechna data z celého podniku
18
▪ Nízká redundance dat a díky tomu je menší pravděpodobnost vzniku nesrovnalostí během nahrávání dat. A to dělá ETL proces jednodušší a méně náchylný k selhání
▪ Je snazší aktualizovat datový sklad v případě, že dojde ke změně business potřeby nebo zdrojových dat.
▪ Možnost vytvoření reportingu přes celou společnost a jednodušší propojování dat z jednotlivých oddělení
Nevýhody Inmonova přístupu (Naeem, 2020)
▪ S narůstajícím počtem tabulek v datovém modelu narůstá celková komplexita datového skladu
▪ Vyšší nároky na dovednosti datového týmu
▪ Počáteční rollout je časově náročnější a nákladnější
▪ Jsou potřeba další ETL na plnění jednotlivých datových tržišť z datového skladu
Obr. 8 Bill Inmon’s Data Warehouse Architecture (Rangarajan, 2018)
Kimball, na rozdíl od Inmona, používá bottom-up přístup, kdy místo jednoho centralizovaného uložiště pro celý podnik, navrhuje použít různá datová tržiště pro různé business procesy/potřeby. A právě z tohoto vychází největší rozdíl oproti Inmonově modelu a to, že
19
Kimballův model je dimenzionální – není normalizovaný a základní koncept modelování je Star schéma. Dalším klíčovou součástí je Data warehouse bus, který zajišťuje, že jednotlivá datová tržiště používají standardizované dimenze (Breslin, 2014). Z Kimballova modelu vychází architektura nezávislých datových tržišť (viz Architektura datových tržišť).
Výhody Kimballova přístupu (Naeem, 2020):
▪ Model je denormalizovaný a díky tomu je první část implementace datového skladu rychlá a relativně nenákladná
▪ Star schéma je srozumitelné pro business uživatele, a protože má denormalizovanou formu, tak i vytváření dotazů a samotná analýza je jednodušší
▪ Model datového skladu je jednodušší, protože se zaměřuje na jednotlivá oddělení a procesy, místo na celý podnik. A tím pádem je i jednodušší jeho údržba
▪ Na správu datového skladu stačí menší tým developerů Nevýhody Kimballova přístupu (Naeem, 2020):
▪ Neexistuje „single point of truth“ a proto může dojít k tomu, že data v jednotlivých datových tržištích jsou různá
▪ Integrace starých systému (legacy systems) může být komplikovaná
▪ Náročná změna DWH při změně business potřeby nebo zdrojových dat. Přidání nových sloupců do faktových tabulek může způsobit problém s výkonem. To je dané tím, že faktové tabulky jsou velmi rozsáhlé a při přidání nového sloupce dojde k výraznému růstu její velikosti v databází a snížení výkonu.
▪ Není možné vytvořit ucelenou reportingovou vrstvu přes celý podnik
20
Obr. 9 Ralph Kimball Data Warehouse Architecture (Zentut.com, nedatováno)
3.1.1 ETL (Extract, Transform, Load) alias Datové pumpy
ETL je komponenta datové architektury, která má za úkol extrahovat, pozměnit a nahrát data ze zdrojových systémů buď do jednotlivých datových tržišť (viz Kimball) nebo do EDW (viz Inmon). V současné době se ETL nástroje vyvinuly do takové podoby, že už nejsou používány jenom pro svůj původní účel, ale dají se využít i na zajištění datové kvality a bezpečnosti (Slánský, 2018).
▪ Extract je první komponenta ETL, která má za úkol přesunout data ze zdrojových systému do DSA.
▪ Transform je v pořadí druhý krok ETL. Během tohoto procesu dojde k pozměnění dat nahraných do DSA. Mezi základní transformace patří: změna názvů sloupců, změna datových typů, rozsekání (parsing) textových souborů, sjednocení měrných jednotek, přidání time-stamp atd. Krok transformace má za úkol také zabezpečit datovou integritu v datovém skladu.
▪ Load je poslední krok ETL, kdy se transformovaná data fyzicky nahrají do datového skladu/tržiště.
21
3.1.2 Data staging area (DSA)
DSA je uložiště, které slouží k dočasnému uložení dat nahraných ze zdrojových systémů. Pro data v DSA je charakteristické (Slánský, 2018):
▪ Jedná se o tzv. jedna ku jedné kopii dat ze zdrojových systému – data nejsou nijak transformována, obohacena či jinak pozměněna
▪ není zaručena jejich kvalita
▪ jsou dočasná – po zpracování jsou přehrána novými daty
3.1.3
Datová tržiště (Data Marts, DM)
Datová tržiště jsou komponenty datového skladu, které obsahují data vztahující se k určitému problému či oddělení. Existují dva hlavní přístupy k architektuře datových tržišť – architektura nezávislých datových tržišť a architektura závislých datových tržišť, kde každý vychází z jiného pohledu na architekturu datového skladu.
V případě nezávislých datových tržišť jsou jednotlivá datová tržiště plněna daty přímo z dočasného uložiště integrační vrstvy. Jednotlivá datová tržiště, která dohromady tvoří datový sklad, jsou na sobě nezávislá a mohou existovat samostatně (Slánský, 2018). Výhodou toho přístupu je především rychlost, nenáročnost implementace a relativně snadná rozšiřitelnost. Na druhou stranu velkou nevýhodou této architektury je fakt, že jednotlivá datová tržiště jsou na sobě nezávislá, takže zde hrozí riziko vzniku nejednotné reportingové vrstvy, a s tím spojené riziko rozdílného reportování skutečnosti.
Obr. 10 Architektura nezávislých datových tržišť (Oracle, nedatováno)
22
U architektury závislých datových tržišť jsou jednotlivá datová tržiště plněna daty z podnikového datového skladu (Enterprice Data Warehouse – EDW) a jednotlivá datová tržiště mohou být na sobě vzájemně závislá. Mezi hlavní výhody této architektury patří centralizace všech dat v jedné „core“ databázi a vystavení jednotlivých datových tržišť na stejných vstupních datech, čímž se snižuje riziko rozdílné interpretace skutečnosti a je jednodušší docílit jednotné reportingové vrstvy. Tato architektura se v posledních letech stala standardem pro architekturu datového skladu (Slánský, 2018).
Obr. 11 Architektura závislých datových tržišť (Oracle, nedatováno)
Jako poslední architektura, kterou zde zmíním, je hybridní architektura datového tržiště, která spojuje oba přístupy. Je založena na závislých datových tržištích, ale specifická datová tržiště mohou být plněna daty z jiných zdrojů než z EDW. Hlavní výhodou této architektury je relativní rychlost a snadnost rozšíření o další datové zdroje, protože mohou být nahrána přímo do jednotlivých tržišť. Toho se hlavně využívá v případě, když je zapotřebí ad hoc integrace nových dat, která nejsou dostupná v EDW. Nevýhody toho přístupu jsou stejné jako v případě nezávislých datových tržišť (Oracle, nedatováno).
23
Obr. 12 Architektura hybridních datových tržišť (Oracle, nedatováno)
3.1.4 Reportingová vrstva
Poslední vrstvou datové architektury je reportingová vrstva, která je z pohledu business uživatelů určitě ta nejdůležitější, protože právě zde nalezne management odpovědi na business otázky a business potřeby. Ačkoliv existuje více komponent reportingové vrstvy, zmíním pouze dvě nejvíce používané, a to OLAP a vizualizaci dat.
OLAP (online analytical processing) je na rozdíl od klasické relační databáze multidimenzionální a obsahuje již předpočítaná a agregovaná data. Díky tomu je práce s OLAP kostkou rychlejší a umožnuje větší flexibilitu při různých pohledech na data, např. je možné porovnávat prodeje po produktech přes různé lokace nebo zákazníky v různých časových intervalech (Slánský, 2018).
24 Obr. 13 OLAP kostka (olap.com, 2020)
Vizualizace dat je grafická prezentace dat pro potřeby koncových uživatelů, aby se na jejich základě mohli rozhodovat. Základní dělení vizualizačních nástrojů je na reporty a dashboardy.
Reporty se zaměřují na specifickou oblast podniku např. prodeje a jdou do většího detailu než dashboardy. Dashboardy obsahují hlavní KPIs, které jsou většinou agregované do jednoho místa, aby bylo možné odhalit trendy rychle a na první pohled. Dashboardy také bývají většinou dynamické (Slánský, 2018).
Na trhu existuje mnoho vizualizačních nástrojů, proto zde zmíním jen ty nejrozšířenější, a to jsou Power BI, Tableau a Qlik Sense. (Gartner, 2020)
3.1.5 Master data management
Master data management má na starost, aby klíčová data podniku byla vždy aktuální a správná.
(Slánský, 2018) Master data dávají kontext transakčním datům. Na správu master dat existuje celá řada nástrojů. Mezi hlavní dodavatele patří Informatica, TIBCO Software, SAP, IBM atd.
(Gartner, 2020)
25
3.1.6 Data quality management
Řízení datové kvality je jedna ze stěžejních oblastí celého datového ekosystému a bezesporu nesmí být opomenuta. Tradičně byla kontrola datové kvality spojena s integrační vrstvou, ale v posledních letech její důležitost stoupá, a to z toho důvodu, že nízká datová kvalita je jeden z velkých problémů, který řeší téměř všechny společnosti.
Datová kvalita je důležitá nejen z čistě analytického pohledu, abychom byli schopní dodat relevantní doporučení, ale také z pohledu úspěšnosti implementace datové infrastruktury a změny uvažování koncových uživatelů. Pokud nejsme schopni zajistit dostatečnou kvalitu dat, koncoví uživatele nebudou analytickým výstupům věřit a budu se i nadále spoléhat na svoji zkušenost a intuici a celý projekt je odsouzen k zániku.
Pokud se bavíme o tom, co jsou kvalitní data, neexistuje přesně daná definice. Pragmatický přístup by byl, že data jsou dostačující kvality, pokud jsou koncoví uživatelé spokojení.
Pomineme-li tento pragmatický pohled, tak datová kvalita se dá definovat následovně (Slánský, 2018):
▪ Včasnost – data jsou dostupná v požadovaný čas
▪ Dostupnost – data jsou dostupná pro koncové uživatele
▪ Užitečnost – data mají business využití
▪ Integrita – data nebyla pozměněna
▪ Konzistence – data si vzájemně neodporují
▪ Přesnost – data přesně popisují aktuální stav
▪ Aktuálnost – data odráží aktuální stav
▪ Kompletnost – nechybí žádná užitečná data
Tak jako v případě master data managementu, tak i pro data quality management existuje celá řada nástrojů zaměřující se na tuto oblast. Mezi hlavní dodavatele patří IBM, Informatika, SAP, SAS, Attaccama, atd. (Gartner, 2020)
26