Datové sklady a BI aplikace MFF – část 3 Duben 2004 Ing. David Pirkl

7. Přednáška

Obsah Dokončení metodologie BDLC OLAP DM a CRM

Agenda BDLC Plán projektu a projektový management Business požadavky Dimenzionální modelování Architektura Fyzický design ETL Uživatelské aplikace Nasazení Správa a růst DW

Architektura Je třeba mít plán Návrh architektury slouží Nezačnete stavět dům bez plánu O co je DW dražším projektem? Návrh architektury slouží Pro komunikaci v rámci týmu Určení plánu Podklad pro učení nových členů týmu Zaručuje flexibilitu a snadnost údržby Pro znovu použití (na dalších projektech)

Architektura Využít Top-Down přístup Od obecného k detailními Architektura musí vycházet z uživatelských požadavků

Architektura Úroveň Data (co) Technologie (jak) Infrastruktura (kde) (bezpečnost, síť, metadata, …) ETL Prezentace Uživatelské požadavky a audit Jaké informace potřebujeme k rozhodování? Jak zapadají do matice BUS architektury (DM a dimenze)? Jak můžeme získat data, jak je transformovat, jak je dostat k uživatelům? Jak se to děje dnes? Jak chceme analyzovat data? Jaké jsou hlavní business otázky? Jak měříme výkonnost firmy? Jaké HW a SW komponenty potřebujeme k úspěchu? Jaké používáme dnes? Model a Dokumentace architektury Dimensionální model: Jaké jsou hlavní fakta a dimenze které chceme sledovat? Jaké jsou vztahy mezi nimi? Jak tyto entity mají být strukturovány? Jaké specifické komponenty potřebujeme k dostání dat v užitečné formě na potřebné místo v potřebném čase? Jaké budou hlavní úložiště dat a kde budou situovány? Co budou uživatelé potřebovat k získání informací v užitečné podobě? Jaké druhy analýz a reportingu budeme potřebovat? Jaké jsou priority? Odkud a kam proudí data? Máme kapacity na přesun dat a na jejich uložení?Co za specifické komponenty potřebujeme? Kdo za ně bude odpovídat? Detailní model a specifikace Logický a fyzický model: Jednotlivé atributy, datové typy, domény, pravidla pro odvození atributů. Jak se zdroje dat mapují na cíle dat? Jaké produkty podporují potřebné vlastnosti? Jak je lze integrovat? Standardy pro psaní kódu, jmenné konvence, … Jaké jsou požadavky na reporty (šablony) – pro řádky, sloupce, hlavičky, filtry, ...? Kdo potřebuje jaké? Jak často? Jak je třeba je distribuovat Jak je možné integrovat nástroje? Jak volat jejich utility, API, …? Implementace Vytvořit databáze, indexy, backup, … Dokumentace. Napsat ETL kód. Automatizace procesu. reportingového a analytického řešení, vytvořit první sadu standardních reportů, školení uživatelů. Instalace a testování komponent infrastruktury. Propoj zdroje dat a DW s uživateli. Dokumentace.

Architektura Základní framework architektury (logický model)

Architektura Architektura by měla být řízena metadaty (metadata catalog) Poskytuje parametry a informace pro všechny procesy (ETL, reporty, …) Informace o DW, zdrojových systémech, ETL, … Např. procedury pro zakládaní tabulek, indexů, uživatelů, spuštění skriptů, … (informace o tabulce a atributech v metadata katalogu, …) Umožňuje např. rychlou změnu při upgrade provozních systémů, …

Architektura Data staging area (DSA) je vhodným místem pro archivování dat z provozních systémů Datový model DSA by měl být navržen tak, aby podporoval výkonnost ETL procesu a snadnost vývoje ERD modely (kopie OLTP systémů) Dimenzionální model Pomocné tabulky DSA – převod ERD modelů do dimenzionálních určených k načtení do 1. vrstvy DW (prezentační část)

Architektura Nástroje ETL je možné Vyvinout sami Zakoupit Komerční ETL nástroje jsou často poměrně drahé ale zaručují vysokou produktivitu (při správném využití) Má smysl první etapu udělat ručně Pak po schválení výsledků přejí na ETL nástroj

Architektura ETL proces – zabírá až 60 procent celkového vývojového času na projektu Potřeba vybrat a integrovat dat Problémy Různé názvy sloupců Chybné hodnoty Neexistující referenční integrita …

Architektura Možnosti získat data Export z provozního systémů (flat file) Vhodné dohodnout rozhraní a přenechat odpovědnost na provozovateli OLTP systému Přímé napojení Replikace Někdy je vhodné data komprimovat pro přenos a zase dekomprinovat

Architektura Typy extrakce Inkrementální load Full load Načtení dát nových (změněných) od posledního loadu Nová (změněná) data identifikována většinou flag v provozním systému nebo dle datumu (času) transakce, trigery, log file, … Datum (čas) transakce posledního loadu nutné uložit do metadata katalogu Většinou tak načítáme velké fakt tabulky Full load Malé dimenze Při sledování SCD je nutné porovnat s původní dimenzí I v případě velkým faktových tabulek – jestliže není možné identifikovat v provozním systému co se změnilo od posledního loadu

Architektura Po načtení dat následuje transformace Transformace zahrnuje: Integraci SCD Kontrola referenční integrity Denormalizace Čištění dat, spojování (merge), rozpojování Konverze datových typů (např. ASCII, EBCDIC) Odvození nových atributů, alokace hodnot na nižší granualitu (např. náklady) – využití business pravidel Agregace Audit obsahu dat (kontrolní součty, počty řádků, …) Plnění auditních tabulek a metadat Transformace dat pro specifické potřeby (např. pro Data miningové nástroje) Null hodnoty – identifikace (např. speciálních kódu pro null hodnoty), nahrazení

Architektura Během načítání dat je třeba kontrolovat a monitorovat: Naplánování úloh Monitorovat proces načtení – ukládat potřebné informace např. pro možnost recovery (znovunačtení) Řízení výjimky a špatná data identifikovaná při procesu ETL (např. duplicity) Exportovat, předat k vyřešení, načíst Identifikovat odpovědnou osobu za data (kvalitu) Navrhnout postupy řešení chyb při načítání (např. výpadek proudu, DB, …) Zaslání upozornění na chyby při loadu (nečekat až do rána, že neproběhlo)

Architektura Potřeba nastavit způsoby zálohování a recovery Archivace Potřeba zajistit rychlost a jednoduchost zálohování a recovery Archivace Fyzická – databáze Logická – modely, skripty, … Seznam všech tabulek v DW (0. i 1. vrstva) Zhodnotit jak náročné je bude obnovit Které by nešly (obsahují historická dat) Vybrat a rozhodnout co zálohovat Nastavit procesy Vyzkoušet recovery

Architektura Otázky bezpečnosti nejsou v 0. vrstvě (ETL) tak kritické – není-li určena pro dotazy Pozor při přenášení dat po sítí při loadu

Architektura V metadata katalogu je vhodné udržovat metadata pro uživatele při získávání dat z DW Kde co naleznou, popis, v jakých reportech se vyskytuje, … V prezentační vrstvě je třeba zajistit bezpečnost dat Authentication Systém hesel, fyzické kontroly (otisky prstů, rohovky), omezení přístupu na základě IP adres, … Bezpečnost přístupu k databázi, reportům, exportovaným souborům Authorization Co kdo může vidět – někdy vyžaduje hodně práce zabezpečit

Architektura Monitorovat využití DW Využití pro: Zvýšení výkonnosti (agregace, indexy, view, …) Podporu uživatelů, školení Marketing DW Plánování (rozvoje, upgrade architektury, …) Dobré reportovací nástroje by měly podporovat Uživatelskou formulaci dotazů (business vrstva mezi daty a uživatelem) Podporu využití agregací Rozklad složitých SQL na více dotazů a jejich propojení ve výsledků Tvorbu odvozených atributů Ochranu před složitými dotazy, které mohou „položit“ DW

Architektura Reportingové nástroje Desktop Aplikační server Součást RDBMS Reportingové řešení by mělo podporovat Uživatelskou tvorbu reportů Reportovací server Parametrizované reporty Plánovač plnění reportů (scheduler) Interaktivní reporty Propojení reportů Report delivery (pull, push, email, web, file system) Metadata Pokročilá prezentace (např. barevně označení položek nad určitý limit) Podpora práce s semiaditivními ukazateli Přímý zápis SQL plus SQL builder API

Architektura Dále: Calculace položet (if then, …) Pivoting (cross tab) Sorting Kompletní formátování (mix tabulek, obrázků, grafů, report s více sekcemi, …) Podpora grafů Export výstupů (excel, word, …) Uživatelsky přívětivý Drop and down – tvorba reportů Multitasking (nemuset čekat až report doběhne) Cancel query Podpora přístupy k různým zdrojům Bezpečnost Administrace (desktop, web) …

Architektura Existuje několik skupin uživatelů z hlediska jejich technických znalostí Oblast Typ uživatele Papírový uživatel Tlačítkový uživatel Jednoduchý ad-hoc Pokročilý uživatel Používání počítače Žádná E-mail, Word Word, Excel, PowerPoint Makra, tvorba WWW DW Spoléhá na pomoc ostatních Standardní reporty, default parametry, EIS Vytvoří jednoduché dotazy (QBE), modifikace existujících dotazů, změna parametrů, navigace v hierarchiích Tvorba dotazů, přímý přístup k databázi

Architektura Informační požadavky se rovněž liší Informační potřeby – kategorie Role uživatele Přístup k datům - kategorie Nástroje Počet osob Monitoring na vysoké úrovni - klíčové metriky, flags Senior management Přístup na "tlačítko" EIS - styl nástrojů Malý Sledování businessu - trh, produkty, zákaznicí, drill-down k detailu Střední management, marketing, prodejci, podpora zákazníků Standardní reporty – parametrizované OLAP style, reportingové nástroje, časování tvorby Velký Průzkum . Výjimky, nové problémy a příležitosti, vývoj obchodních případů (business case) Jako předchozí plus business analytici Ad hoc analýza OLAP style, reporting, analytické nástroje pro ad-hoc dotazování Střední Kompletní analýza – kombinace dotazů, statistická analýza, vývoj modelů Business analytici a experti na analýzu Data mining - pokročilé analýzy Statistické nástroje, data mining nástroje, pokročilé analytické nástroje

Architektura Potřeba poznat potřeby uživatelů -> navrhnout správné nástroje pro přístup k datům Vycházet z priorit nejdůležitějších uživatelů DW Vhodné využít web Např. pro přístup k metadatům, reportům, …

Architektura Otázky infrastruktury je vhodné řešit s expertem z dané firmy (kde se buduje DW) Navržení HW DW většinou prudce roste v prvních dvou letech (objem dat, dotazy)

Architektura Existuje mnoho variant řešení: Malé/Počáteční řešení Vývoj/Testování Warehouse 0. vrstva Aplikační server Desktop nástroje Datové tržiště Vývoj Reporting 1. vrstva tržiště Tržiště Malé/Počáteční řešení Střední/2. kolo řešení Velké/Enterprise řešení

Architektura Třeba vzít v úvahu business požadavky Faktory Velikost dat Přírůstky, změny v datech, frekvence loadů, čas pro load Počet uživatelů, jejich aktivita, typy analýz, kolik pracuje konkurenčně, rozložení časové zátěže Složitost business – řešení Požadavky na dostupnost (regionální, časovou) Znalosti IS pracovníků (umí UNIX, Windows, DBA, …) Finanční zdroje

Architektura Využití paralelního zpracování Symmetric multiprocessing (SMP) Jeden počítač, sdílejí disk, paměť Massively parrallel processing (MPP) Více počítačů, každý paralelně, např. tabulky přes několik počítačů, full table scan paralelně Non-uniform memory architecture (NUMA) Kombinace SMP a NUMA Musí to HW a SW (OS, RDBMS) podporovat Při výběru OS zvážit i jaké jsou pro něj dostupné aplikace

Architektura CPU SMP CPU MPP CPU NUMA

Architektura HW: Nezapomenout na zdroje pro back-up Volba Disky (velikost, rychlost, RAID 1-5) Paměť (čím více tím lépe) Nezapomenout na zdroje pro back-up Volba OS: UNIX Windows RDBMS OLAP databáze ETL tool

Architektura RDBMS – hlavní faktory pro uvažování: Podpora DW Bitmapové indexy Optimalizátor dotazů Vhodné je se poučit z jiných DW projektů nebo dopředu otestovat výkonnost RDBMS Existují speciální relační databáze určené pro DW a ne pro transakční Sybase IQ

Architektura Pro front-room nástroje zjistit nároky: Paměť Disk Platforma U desktop aplikací vyřešit problém upgrade na nové verze, OS desktop stanic, paměť Záleží na potřebách uživatele co bude za aplikace používat Stanovit minimální požadavky dle skupin uživatelů (pasivní, analytici, …)

Architektura Potřeba zvážit nároky na síť Databázová konektivita Kapacita, zatížení, množství přenesených dat Bezpečnost – přenos přes síť (ssh) Databázová konektivita Nativní ovladače OBDC OLE DB JDBC Využití DNS serveru (ne přímý zápis IP adres), Active directory - metadata

Architektura Metadata – data o datech Metadata „Je to užitečná definice, moc toho neříká“ Metadata Pro ETL Pro prezentaci Ohledně metadat je třeba: Sepsat všechna metadata Určit jejich důležitost Určit odpovědnou osobu Rozhodnout zda není vhodné koupit speciální nástroj na podporu metadat Určit jejich uložení a back-up a recovery Vystavit je uživatelům (procesům), kteří je potřebují Zaručit jejich kvalitu a aktuálnost Kontrola

Architektura Metadata: Zdrojové systémy ETL RDBMS Umístění, modely, formát, vlastník, popis, frekvence změn, limity použití, dostupnost, způsob přístupu, práva přístupu, heslo, privilegia, extrakty z provozních systémů (formát, čas, zodpovědnost) ETL Plánování (schedule) ETL pump, výsledky pump, jakých dat se týkalo (time stamp – pro inkrementální load), čas loadu, definice tabulek (dimenze, fakta, pracovní), skripty – popis, SCD pro každý atribut, umělé klíče pro produkční klíče (mapování), specifikace postupů čištění dat, transformace - popis, datový model, skripty – popis, agregace popis, auditní dimenze, nastavení bezpečnosti, specifikace back-up, recovery RDBMS Model (logický, fyzický), partition, indexy, disk využití, bezpečnost, uživatelé, práva, view definice, uložené procedury, administrační skripty, back-up, recovery

Architektura Metadata Metadata – prostě všechno Prezentace Business jména sloupců, tabulek, hierarchií, reporty, business skupiny požadavků (marketing, obchod, …), uživatelská dokumentace, bezpečnost – privilegia, počty login, délka, počet dotazů, nejvíce využívané reporty (obecně, uživatelem) Metadata – prostě všechno

Architektura Je potřeba zajistit publikaci dat vs. ochanu data a bezpečnost Bezpečnost: Fyzické komponenty Servery, stanice, kabely, switch, … Nebezpečí Krádež Zničení/vandalismus Oheň Vlhkost Voda Prach Slunce, chemie Elektrické výpadky, zkraty Magnetismus

Architektura Informace: data, finanční dopady, reputace Data, metadata, emaily, dokumenty, kopie, zálohy Nebezpečí Vyzrazení strategie, plánů, rozpočtu, … Vyzrazení citlivých dat (čísla účtů, stavy účtů, …) Modifikace dat Hrozby Odposlech Hacker útoky Fyzická krádež (notebook, dokumenty) Sociotechnika Trojské koně

Architektura SW Ataky na business Nebezpečí Krádež kódu Krádež SW Trojské koně Viry Ataky na business Nemožnost poskytovat služby (např. zahlcení serveru) Nemožnost rekonstruovat data (např. objednávku) Terorismus

Architektura Zajistit bezpečnost přenosu informací přes internet Krytování Symetrické Asymetrické HW prvky k využití: Routry (pro filtraci paketů) Firewall Důležitý systém hesel Neodhadnutelný Odolný proti útoku hrubou silou (slovník slov) Heslo – písmena a číslice Člověk – nebezpečí pro bezpečnost Hesla na papírku přilepená na monitor Otisky palce, sítnice

Architektura Bezpečnost je proces Je potřeba Potřeba zakomponovat do firemní kultury Je potřeba Definovat bezpečnostní politiku Získat podporu vedení Školit a stále připomínat Být ostražití, stále aktualizovat bezp. pravidla Nedůvěřivý (Proč chtějí uživatelé vidět tyto data, pozorovat log, …)

Architektura Kroky Taktické Využij antivirové programy (server, desktop), aktualizuj je Zvaž odstranění floppy disků a CD z stanic uživatelů Instaluj firewall, zakaž připojení přes modem ze stanic uživatelů, nastav bezpečnou komunikaci na internet (přes proxy server) Kontroluj SW instalovaný na počítačích Nastav a vyžaduj politiku hesel Škol uživatele v otázkách bezpečnosti Nastav kontrolní mechanizmy – kontrola logů, špatné přihlášení Zabezpeč back-up media Kontroluj nastavení práv uživatelů (vidí jen co mají?) Fyzicky zabezpeč servery Zajisti skartaci starých záloh, …

Architektura Strategické Nezávislý bezpečnostní audit Využití asymetrického kódování Nahrazení hesel pokročilými technikami (otisky prstů, sítnice, magnetické karty) Z pohledu DW – využít bezpečnostní politiku, kterou firma implementovala dosud

Architektura Návrh a implementace architektury Vycházet z principu 80-20 20 procent úsilí přinese 80 procent přínosu Nastavit priority a na ty se zaměřit Interaktivní proces – zpřesňování požadavků a návrhu architektury

Architektura Výstupy návrhu architektury Plán technické architektury Shrne požadavky uživatelů Návrh budoucí architektury DW Plán infrastruktury Někdy součástí Plánu technické architektury Popisuje servery, desktopy, síť

Architektura Data Technologie Infrastruktura Uživatelské požadavky (Zahrnující business, data, otázky infrastruktury) Matice BUS architektura Plán technické architektury Specifikace Infrastruktury (a model) Model business datových procesů Matice vyhodnocení produktů Plán infrastruktury Logický a fyzický model dat Výběr produktů Implementace

Plán technické architektury Během interview získej i požadavky na architektury Její první návrh lze udělat už v průběhu interview nebo před a následně upřesňovat Spolupracuj s vybranými pracovníky (IS) na oponentuře a tvorbě architektury Vypracovat draft plánu Nechat oponovat Vytvoř model architektury (grafický) Vhodný pro komunikaci Navrhni postup implementace architektury Vyber prioritní oblasti Odhadni čas a zdroje potřebné pro implementaci Proveď revizi dokumentu s managementem

Plán technické architektury

Plán technické architektury Plán – nemusí být na úroveň konkrétního produktu, ale měl by vycházet z potřeb uživatelů Vize jak to do budoucnosti bude Vypsat typy uživatelů, jejich potřeby na přístup k informacím, požadavky na reporting, …

Plán technické architektury

Plán infrastruktury Tři základní oblasti Server (HW a OS) CPU, OS, Disk, Přírůstek dat, paměť Síť Od OLTP do DW Od DW k uživatelům Zabezpečení, frekvence přenosu Pracovní stanice HW, OS, konektivitu (ODBC, OLE DB, …) Plán je postupně upřesňován na základě vybraného SW podle plánu technické architektury

Výběr produktů Výběr na základě návrhu architektury, uživatelských požadavků HW DBMS ETL tool Nástroje pro prezentaci a přístup k datům Vhodné je testovat vybrané HW a SW komponenty Vytvořit prototyp DW a testovat produkty Nikdy je ale neotestujeme na reálné zatížení Vhodné je např. domluvit s dodavatelem 90 denní testovací období a potom teprve podepsat smlouvu

Výběr produktů Vytvořit Matici vyhodnocení produktů Nastavit priority (váhu) jednotlivým kritériím Musí mít … bylo by dobré kdyby mělo Spolupracuj s výrobcem (ať objasní potřebné informace) Proveď průzkum trhu WWW stránky Publikace, časopisy DW konference, fórum, portály Kritéria Dle uživatelských potřeb pro daný ty nástroje Výrobce Podpora Dokumentace Školení Konzultace Externí podpora (nezávislé forum na webu o produktu, …) Spolupráce s výrobce (dobrá, nekomunikativní, …) Velikost, budoucnost Reference

Výběr produktů Vybrat pro porovnání maximálně 5 produktů Uspořádat prezentaci výrobců Získat informace na vyplnění Matici vyhodnocení produktů Ukázka práce produktu Domluvit ukázku u stávajícího zákazníka s podobným řešením Není-li možné rozhodnout – vytvoř prototyp (2 – 3 výrobci) a otestuj Vhodné přenést na výrobce nebo s ním spolupracovat

Výběr produktů Otestovat produkty v plné šíři, ne jen omezeně Jednoduché i komplexní funkce Málo i hodně dat Jeden a více uživatelů Tvorba prototypu – 4 až 6 týdnů Po 2 – 3 letech je vhodné výběr opakovat pro možný upgrade na nové technologie

Výběr produktů Na co si dát při tvorbě prototypu pozor Definovat rozsah prototypu Rozsah by neměl být moc velký Vzít rozumnou velikost dat Načíst data v syrovém stavu (neztrácet čas čištěním) Jednorázové ne vytvářet pro inkrementální Naučit se v rámci tvorby prototypu co nejvíce o provozních systémech, problémech v datech, HW, SW potřebném Získej názory uživatelů – ukázat jim výstupy Nenechat se zaslepit očekáváním

Výběr produktů Instalace je závislá na to co je vybráno HW a SW Potřeba dobře nainstalovat –může dosti ovlivnit výkonnost řešení Spolupracovat se specialisty, dodavatelem, výrobcem Nezapomenout na: Příprava místa na HW (servery) Školení administrátorů Testování po instalaci

Výběr produktů Čas potřebný na vytvoření plánu architektury Globální firma Techno – politický Komplexní 12+ týdnů Nerozumně Komplexní n týdnů Organizační komplexnost Jednoduché 1 – 6 týdnů Funkčně komplexní 8 – 12 týdnů Jeden člověk Systémová komplexita Výstupy Datové zdroje Platformy

8. Přednáška

Agenda BDLC Plán projektu a projektový management Business požadavky Dimenzionální modelování Architektura Fyzický design ETL Uživatelské aplikace Nasazení Správa a růst DW

Fyzický design - Agregace Agregace mohou významně zvýšit výkonnost Někdy nahrazeno OLAP databází Uchování agregací vedle detailních dat v databázi DW Agregace – obvyklé souhrny podle daných dimensí Je třeba vložit vrstvu, která dokáže rozpoznat, zda uspokojit uživatelský požadavek přímo z detailních dat nebo existuje agregace Umí některé reportingové nástroje Nebo je třeba vyvinout Je to největší obtíž a výzva směrem k agregacím

Fyzický design - Agregace Přidat je rozumné agregace – zvyšuje nároky na prostor na disku Výběr dat pro agregaci Dle potřeb uživatelů Např. na základě existujících reportů Vybrat atributy z dimenzí používané pro seskupení (region, kategorie produktu) Určit jejich kombinace – které atributy jsou používány společně Dle statistické distribuce dat v DW Např. produktu je 1 000 000 Kategorií – 500 000 – nemá moc smysl agregovat (stále mnoho řádků) Kategorii – 1 500 – agregovat Počítat frekvence výskytu řádků pro kombinace hodnot atributů dimenzí Např. 12 měsíců x 256 produktů = XY možných řádků v faktové V čase se mění – interaktivní cyklus Mažou nepoužívané, přidávají nové

Fyzický design - Agregace Všechny agregace v součtu by měly být optimálně asi stejně objemově velké jako původní tabulka Každá agregace má svoji faktovou tabulku A zmenšené verze dimenzionálních tabulek (dle úrovně agregace) Některá fakta musí být vypuštěna – mohou dávat smysl pouze na detailní úrovni Agregace pak často umožňují přímé porovnání s uloženými daty plánu (plány jsou často na agregované úrovni) Lze uložit do jedné tabulky Agregované tabulky mohou být často rozšířeny o fakta typu min_prodej_kč, max_, count_

Fyzický design - Agregace Product dimension Product_key (PK) SKU Description Brand Category Department Package_type Size … Time dimension Time_key (PK) SQL_date Day_of_week Month Fiscal_period Season Sales fact table Time_key (FK) Product_key (FK) Store_key (FK) Promotion_key (FK) Dollar_sold Units_sold Dollars_cost Store dimension Store_key (PK) Store_ID Store_name Address Region Division Floor_plan_type Promotion dimension Promotion_key Promotion_name Price_type Ad_type Display_type …

Fyzický design - Agregace Category dimension Product_key (PK) Category Department Time dimension Time_key (PK) Month Fiscal_period Season Sales by Category-Region-Month Fact table Sales fact table Time_key (FK) Product_key (FK) Store_key (FK) Dollar_sold Units_sold Dollars_cost Plan_dollars_sold Plan_units_sold Plan_dollars_cost Store dimension Store_key (PK) Region Division

Fyzický design Je ovlivněno: Je třeba: Logický datový model Zvolený RDBMS Objemem dat Způsobem využití dat Nástroji pro přístup k datům Je třeba: Vytvořit plán fyzické implementace Vytvořit a dodržovat standardy

Fyzický design Vytvoř jmenné a databázové standardy Fyzický model Revize Plánu agregací Počáteční Strategie indexace Databázová instance Fyzické uložení Monitoring užívání

Fyzický design Vytvořit standardy Jména databázových objektů Jména a cesty k fyzickým souborům Lze převzít (a případně modifikovat) již existující firemní standardy Příklad konvence – jméno složené ze tří částí Hlavní část – co je to? (např. zákazník, produkt, účet) Třída – typ objektu (např. průměr, počet, datum, flag) Vlastnost – volitelný, popisuje předchozí dvě vlastnosti (např. počátek, konec, primární, sekundární) Konvence: hlavni_vlastnost_třída Ucet_počateční_datum Prodeje_průměr Zvážit rozlišit logická a fyzická jména Doporučeno stejné – co nejvíce popisné

Fyzický design - standardy Dohodnout se na seznamu slov (Hlavních části) s uživateli Vytvořit seznam tříd a vlastností Vytvořit seznam používaných zkratek (např. desc = description) Vytvořit standardy pro pojmenování pracovních tabulek pro ETL Zvážit poměr mezi popisností názvu a jeho délkou my_company_billingDW_customer_ID Pozor zda databáze je case senzitive Brát jako by byla i když není Připraveno pro migraci na novou databázi, která by mohla být

Fyzický design - standardy Využít pro názvy tabulek synonyma Je pak jednoduší při změně struktury tabulky jenom změnit odkaz synonyma než měnit aplikace Alternativně lze využít view Nebo materializované view Zvážit výkonnost view tvořené z více tabulek Vytvořit standardy (adresářovou strukturu a jmenné konvence) pro umístění souboru Zdrojové kódy Skripty Binární soubory Databázové soubory Modely Dokumentace

Fyzický design - standardy DISK A RAID 1 Adresáře RDBMS Obsahuje databázi ETL Obsahuje ETL nástroj LOG Obsahuje log soubory SCRIPT_PROD Obsahuje produkční scripty METADATA Obsahuje skripty pro metadata DIMENZE Obsahuje scripty pro dimenze ZAKAZNIK Obsahuje scripty pro dimenzi zákazník crt_zakaznik.sql DDL - vytáří tabulku zákazník crt_cust_stage.sql DDL - vytáří data staging tabulky pro zákazníka crx_customer.sql DDL - indexy nad tabulkou zakazník drx_customer.sql DDL - drop indexy customer_stage.sql Script pro 0.vrstvu upd_customer.sql Script pro načtení do 1. vrstvy readme Popis obsahu adresáře …. FAKTA Obsahuje scripty pro faktové tabulky SCRIPT_DEV Obsahuje vývojové scripty DRIVE B RAID 5 DATABASE Obsahuje databázové soubory (vlastní data) DRIVE C NO RAID DATASTAGE Obsahuje flat files TEMPDAT Temp místo pro databázi JOBLOGS Logy z proběhlých úloh a scriptů

Fyzický design Fyzický model vychází z logického Některé změny vlivem zvoleného RDBMS Přidány pomocné tabulky (většinou nejsou součástí logického modelu) Detailní nastavení datových typů, partition, specifikace umístění tabulky, umístění na disku databáze (souborů) Vhodné využít modelovacího (case) nástroje Většinou je možné i využít pro tvorbu dokumentace (např. technický popis z jakých zdrojů se plní daný atribut, jaký je typ, transformace, …) Definovat entitní, doménovou a referenční integritu, null hodnoty Někdy je výhodnější neimplementovat (když jsou čistá data) – nezatěžuje RDBMS – ale pozor na konzistenci dat

Fyzický design Model by měl obsahovat i indexy Modifikovat model dle potřeb uživatelských nástrojů Např. vyžadují snow-flake Provedení přibližného odhadu velikosti databáze Možno využít schopností modelovacího nástroje „Ruční výpočet“ Délka (velikost) řádku Počet řádek, počet řádek přírůstku pro jeden load Pro indexy přidej stejně místa jak pro tabulku Temp space – pro budování indexu musí být dvojnásobný jak index Pro třídění alespoň velký jak tabulka Započítat metadata tabulky Připočítej agregační tabulky (obecně velikost v souhrnu jako base tabulka) Obecně platí, že DW zabere v součtu 3 až 4 tolik místa jak atomická data Potřeba zahrnout i místo pro testování, vývoj, ETL

Fyzický design Nejvíce místa zabírají Faktové tabulky Indexy na nich Dimenze jsou v porovnání s faktovou tabulkou obecně zanedbatelné Výjimka např. velké dimenze zákazníků

Fyzický design Vytvořit počáteční plán indexace Bude se měnit v průběhu využívání DW – podle analýzy dotazů, doby odezvy, … Potřeba porozumět jak zvolený RDBMS využívá indexy a jak tvoří plán provedení dotazu B-tree indexy Pro atributy s velku kardinalitou (např. customer_ID) Klastrované vs. Neklastrované Na jednom nebo více sloupcích Bitmapové indexy Pro atributy s nízkou kardinalitou (např. pohlaví) Některé RDBMS disponují speciálními indexy Některé mají zabudovanou podporu star schéma (násobné join)

Fyzický design Faktová tabulka Dimenzionální tabulka Indexy na klíčích Jeden pro jeden klíč – RDBMS podporuje využití více indexů pro jeden dotaz Několik složených indexů – podle cesty dotazu Lze v případě potřeby i indexy na faktech (když hodně dotazů typu prodej > 1000) Dimenzionální tabulka Na primárním klíči Bitmapové indexy na atributech dimenze Na atributech sloužících pro join, filtrování, group by

Fyzický design Nastavit a zvážit indexy i pro efektivní ETL Při loadu dat Zvětší-li se loadem tabulka o 10 až 20 procent je efektivnější smazat a znovu vytvořit index Kontroluj indexy a statistiky po loadu

Fyzický design Instalace a nastavení databáze DW je náročny na paměť Zdokumentovat nastavení databáze plus důvod DW je náročny na paměť Blocksize Záleží na potřebách Uložit scripty pro nastavení databáze Nastavit partition tabulek Většinou podle atributu datum Nastavit umístění souborů na disku Doporučuje se využít RAID disky (RAID 1 až 5) Optimálně databáze a OS jeden disk, zdrojová data (flat soubory) druhý disk, tabulky a indexy další dva disky, transakční log další disk, temp další disk Z hlediska dotazů je vhodné aby fakt na jednom disku a dimenze na jiném

Fyzický design Potřeba vybudovat systém pro monitoring využití DW Load dat Dotazy Běh procesů Využití zdrojů Důvody pro monitoring: Výkonnost Ladění dotazů, indexy, agregace Výběr testovacích dotazů Podpora uživatelů Sledovat vytíženost, logování uživatelů Pro plánování školení Proč se uživatel už dlouho nepřihlásil – neví jak, nemůže se připojit k databázi Marketing Že DW je stále více využíván Kdo z uživatelů využívá nejvíce – konkurence mezi uživateli Plánování Další rozvoj DW dle vzrůstajícího počtu uživatelů, konkurenčních dotazů, času loadu, velikosti databáze,….

9. Přednáška

Agenda BDLC Plán projektu a projektový management Business požadavky Dimenzionální modelování Architektura Fyzický design ETL Uživatelské aplikace Nasazení Správa a růst DW

ETL Hlavní základní kámen dobrého DW V prvním kroku je třeba vytvořit plán ETL Plán: Konceptuální model zdroj-cíl prodění dat (na jednu stránku) Testovat, implementovat nástroj pro ETL nebo využít SQL Graficky zobraz všechny komplexní transformace, generování umělých klíčů, SDC. Vytvořit prvotní plán sekvenčních kroků Dimenze Vytvoř a testuj statický load dimensionální tabulky. Primárním cílem je otestovat infrastrukturu (připojení, přenos souborů, bezpečnost – práva) Vytvoř a testuj SCD proces pro jednu dimenzi Vytvoř load pro zbývající dimenze Fakta a automatizace Vytvoř load historických dat do faktových tabulek (zahrnuje management umělých klíčů, a jejich substituci) Vytvoř a testuj inkrementální proces Vytvoř a testuj load agregací nebo load do OLAP vrstvy Vytvoř a testuj automatizaci celého procesu

Vrstvy datového skladu Datový sklad se většinou staví ve vrstvách: Vrstva Popis ETL náročnost 0. vrstva V nulté vrstvě se uchovávají data z jednotlivých provozních databází. Jedná se většinou o kopie provozních dat 1:1. Data neslouží přímo pro analýzy, ale jako vstup pro další vrstvy. Převod dat v zásadě 1:1, základní transformační kroky. 1. vrstva Data jsou uložena v datovém modelu datového skladu (tabulky fakt a dimenzí). Na data jsou aplikována integritní omezení. Tato vrstva slouží pro analýzy. Data jsou očištěná a konzistentní. Náročné transformace a čištění dat, mapování dat z 0. vrstvy na datový model datového skladu. 2. vrstva Speciálně připravená data pro podporu speciálních aplikací. V podstatě se jedná o jednotlivá datová tržiště. Náročné transformace z 0. a 1. vrstvy (speciální algoritmy).

ETL Obecně je nutné vyřešit dva základní problémy: Transformace z různorodých zdrojů Integrace data do datového skladu zdrojové DB transformace integrace homogenní DB DW

ETL Je třeba zajistit dostupnost zdrojových systémů pro potřeby loadu Přímé napojení Extrakty s danou strukturou Vychází se z vytvořeného dokumentu mapující vazby zdroj – cíl Je potřeba Dodržovat standardy (jmenné, psaní kódu) Psát srozumitelné komentáře Hlavičky skriptů Vytvořit knihovny obecně využívaných funkcí Testovat funkčnost Dokumentace

ETL Krok 1 – konceptuální model ETL Základní, na jednu stránku Mapování zdroj – cíl, poznámky k hlavním bodům Je-li jeden hlavní systém – zdroje logické seskupení zdrojových tabulek Tři základní fáze ETL Extrakce – ze zdrojových dat Transformace Load – do 1. vrstvy DW

(COBOL flat file, 2000 sloupců ETL Zákazníci (RDBMS) Regiony (RDBMS) DMR systém (COBOL flat file, 2000 sloupců Jeden na zákazníka) Měřiče (MS Access) Čas (MS Excel) 15 tis oblasti SCD pro demografické a účetní atributy 750 tis. Zakazníku Za den Kdo spravuje 75 typů měřičů Starší nejsou v tomto systému Kontrola RI …. 25 mil zakazniku, 10 tis nových nebo Změněných za den Popisky potřebují upravit Měsíční spotřeba Kontrola RI Kontrola RI Region Prodeje elektřiny Čas odpočtu Zákazník Měřiče

ETL Krok 2 – nástroj na ETL Možnosti řešení Kód T-SQL, PL/SQL, Delphi, … Nástroj Grafické rozhraní, zrychlení procesů Repositář dat, paralelismus Dražší řešení Informatika, DTS, warehouse Builder Většinou na první fázi dělat „ručně“ Nezvyšovat náklady na DW Záleží na podmínkách

ETL Krok 3 – detailní plán Detailně rozpracovat jednotlivé kroky Rozhodnout se nad sekvencí kroků Nejprve dimenze Pak fakta (plus look-up na umělé klíče) Zde jedna (i více) stránka pro jednu tabulku v DW Někdy smysl vycházet ze zdrojové tabulky Doplnit pseudokódem pro transformaci 0. vrstva = data staging area Místo kde jsou načtená data čištěna, kombinována, archivována, transformována a přenášena do prezentačních vrstev (1. vrstva DW)

ETL Dimenze Statická SCD Umělé – nejsou v datech (Časová dimenze) Krok 4 – naplnit jednoduchou statickou (ne SCD) dimenzionální tabulku Load Ze souboru – výhoda, že soubory lze zálohovat a tak znovu použít při recovery, lze je při přenosu kryptovat, zapakovat Přímé napojení - stream

ETL Krok 4 – pokračování I jednoduchá tabulka potřebuje Čištění dat Přiřazení umělých klíčů Je třeba uchovávat tabulku mapování přirozených klíčů na umělé Využívá se později i pro faktové tabulky Obvykle umělý klíč – integer Možno využít sekvencí Hlavní transformace – konverze datových typů, kódování – čeština Jsou-li zdrojová data pro dimenzi z více zdrojů (např. zákazník) Potřeba namapovat na sebe Někdy těžko lze – fuzzy logika (jméno, adresa, …) Existují na to nástroje Uložit do tabulky umělých klíčů přirozené klíče ze všech spojených záznamů (ze všech zdrojů) Testovat zda vztahy mezi atributy dimenze jsou opravdu 1:1 nebo 1:N

ETL Krok 4 – pokračování Pro load dat využít bulk funkci I pro load do 1. vrstvy je možné Insert into je pomalé a zapisuje se do log souboru – problém při velkých loadech Pro load dat do prezenční vrstvy – doporučení Vypnout loggování Pre-sort data dle primárního klíče (rychleji se načte při indexu na primární klíč) Při full refresh tabulky – smaž původní data pomocí truncate table Nelogguje se Přidává-li se více jak 10 procent dat do tabulky je smysluplné drop a recreate index (záleží na podmínkách, počtu indexů, …) I při ponechání indexů je dobré je časem přebudovat pro zamezení přílišné fragmentace (fillfactror na maximum)

ETL Krok 5 – SCD Hlavně se používá technika Typ 2 Přístup Načíst všechna data a dívat se co se změnilo Využít inkrementálního načítání (načíst jen změny od minulého loadu) – viz dále u faktové tabulky Hlavně u velkých tabulek SCD typ 1 – je vlastně inkrementální načtení dimenzionální tabulky (jako full ale inkrementálně) Problém s položky smazanými v OLTP – byly smazány tak nemohou být načteny – pro DW to ale potřebujeme vědět Triggery Změny v OLTP – nemazat, deaktivovat Výhodně je načítat jen změny A ještě více pokud OLTP udržuje informaci o typu změny

ETL Krok 5 – pokračování Identifikovat změny Porovnat s stávající dimenzí Neexistuje-li záznam – vložit Existuje-li – SCD (dle typu SCD) Jestliže v dimenzi některé položky mají SCD typ 1 a některé SDC typ 2 musím u položek s typem 1 každou změnu promítnout do všech záznamů pro daný objekt v dimenzionální tabulce Velké dimenze se zpracovávají podobně jako faktové tabulky

ETL Most recent key map Customer_id Customer_key Lookup max Load to DBMS dimension table Záznamy s umělým klíčem Customer_key (PK) Customer_id Customer_type Jméno Adresa … Update key map Add surrogaste Key and load record Změněné záznamy Dimeze zákazník Customer_id Customer_type Jméno Adresa … Umělý klíč

ETL Input do Procesu Diff compare Na předchozím Policy decision slide Dnešní záznamy Customer_id Customer_type Jméno Adresa … Změněné záznamy dimenze zákazník Customer_id Customer_type Jméno Adresa … Diff compare Policy decision Input do Procesu Na předchozím slide Včerejší verze dimenze Customer_id Customer_type Jméno Adresa …

ETL Krok 6 – naplnit zbývající dimenze Obdobně jako předchozí načíst i další tabulky Vytvořit skript pro načtení Časové dimenze Někdy se využívá tabulkový procesor

ETL Faktové tabulky Krok 7 – načtení historických údajů Výhodné načítat inkrementálně Jen záznamy změněné od posledního loadu Podobně i velké dimenze Krok 7 – načtení historických údajů Vytvořit pumpy pro načtení historických dat Interaktivní proces – nebude pravděpodobně dobře na první pokus V praxi řada výjimek (co započítat, co ne, …) – potřeba identifikovat tyto business pravidla Potřeba auditovat součty, počty, … a porovnat s výstupy z provozních systémů – zvyšuje důvěryhodnost DW

ETL Krok 7 – pokračování Nahrazení přirozených klíčů umělými Vhodné je zjišťovat aktuální umělé klíče ze speciálních tabulek, ne přímo z dimenzí (může být pomalé) Lze řešit v dimenze flagem – aktuální záznam a bitmapovým indexem nad ním Jestliže se načítají faktová tabulka historicky musí se i historicky přiřadit umělé klíče (platné v čase transakce zachycené v faktové tabulce), ne vzít aktuální umělý klíč!!!

ETL Sales fact table Production ID Time_id Product_id Store_id Most recent key map time_id time_key Most recent key map product_id product_key Most recent key map store_id store_key Sales fact table Production ID Time_id Product_id Store_id Dollar_sold Units_sold Dollars_cost Plan_dollars_sold Plan_units_sold Plan_dollars_cost Sales fact table Surrogate key Time_key (FK) Product_key (FK) Store_key (FK) Dollar_sold Units_sold Dollars_cost Plan_dollars_sold Plan_units_sold Plan_dollars_cost Replace ID umělým klíčem Replace ID umělým klíčem Replace ID umělým klíčem Load fact table Into RDBMS

ETL Krok 7 – pokračování Je-li null hodnota v klíči do dimenzionální tabulky – nahradit klíčem k speciálnímu záznamu v dimenzionální tabulce („Neuvedeno“) Odvozená fakta je možné uložit fyzicky (jsou-li často přistupována, chceme index nad nimi) nebo vypočítáme až ve view

ETL Krok 8 – inkrementální načtení Identifikovat co se stalo nového Nová transakce Přidat záznam do fakt tabulky Update transakce Změnit záznam ve fakt tabulce Přidat změnový záznam Smazání transakce Smazat záznam ve fakt tabulce

ETL Technika pro zajištění maximální dostupnosti DW Vhodná pro menší DW Budou existovat 3 kopie faktové tabulky

ETL 7. DW up From data staging Active_fact_1 6. Rename load_fact_1 na Active_fact_1 1. Load fact table Load_fact_1 4. DW down 3. Index 2. Duplicate load_fact_1 8. Rename dup_fact_1 na load_fact_1 5. Rename Active_fact1 na old_fact_1 Old_fact_1 Dup_fact_1 9. Drop old fact table

ETL Krok 9 – Agregace a OLAP Agregace – někdy třeba rovněž vytvářet inkrementálně (full proces moc náročný časově) Je-li agregován čas (z dnu např. na měsíce) volby: Nezahrnovat dosud neskončený měsíc Zahrnout – hodnota month-to-day (každý den se přepočítává) OLAP – viz dále

ETL Krok 10 – automatizace Načasovat jednotlivé kroky Lze na sebe jednotlivé kroky navázat (např. zápis do tabulky metadat, že už jeden proces skončil a druhý může začít, existence souboru, …) Získat potřebná metadata Proces Start Konec Doba běhu Počet přesunutých řádků Status dokončení (úspěšně/neúspěšně) Diskové operace, CPU, … Viz Auditní dimenze u faktové tabulky

ETL Krok 10 – pokračování Možný postup: Extrakce dimenzí a zápis metadat Extrakce faktů a zápis metadat Procesování dimenzí Umělé klíče/SCD/…. Čištění dat, zápis metadata Procesování fakt Umělé klíče, zápis nevyhovujících záznamů Zápis nevyhovujících záznamů Transformace dat Load dimenze Load fakta Agregace, OLAP Validace loadu proti metadatům Zaměň servery (pro 24 hod DW) Načti datové tržiště Aktualizuj metadata Zapiš metadata o loadu Otestuj správnost a úplnost loadu

ETL Hlavním problémem je kvalita zdrojových dat Obsáhlý problém (Data quality and cleaning) Kvalitní data Přesnost Kompletnost Konzistence Jedinečnost (stejné názvy pro atributy se stejnou informací) Včasnost Kvalitní data – „pravda, jenom pravda a nic než pravda“

ETL Problémy v datech OLTP systémy pro podporu transakcí Nekonsistentní používání kódů (Ano, true, T, …) Jeden atribut uchovává více informací Význam atributu záleží na hodnotě druhého atributu Chybějící hodnoty Duplicity Chybné hodnoty Překlepy OLTP systémy pro podporu transakcí Aby doručili zboží Kvalita dat není na prvním místě Validace dat by mohla neúměrně zdržet zápis transakce Problémy při ručním vkládání DW – přínos – ukazuje na kvalitu dat Pro zvýšení kvality potřeba získat podporu managementu

ETL – příklad transformace Datový sklad appl A - m,f appl B - 1,0 appl C - x,y appl D - male, female Kódování appl A - pipeline - cm appl B - pipeline - in appl C - pipeline - feet appl D - pipeline - yds Měřítko appl A - balance appl B - bal appl C - currbal appl D - balcurr Atributy

ETL Nejběžnějším problémem je integrace zákazníků Standardizace jmen a adres Householding – identifikace ekonomické jednotky Existují specializované nástroje na tento problém Doporučení ke kvalitě dat Je-li možnost (více potencionálních zdrojů dat) vybrat nejkvalitnější zdroj Prozkoumat data – hledat možné problémy Prezentuj nekvalitu dat managementu – nesmí dojít k názoru, že data jsou nekvalitní jen v DW Spolupracuj s OLTP správci na odstranění chyb Spolupracuj s uživateli na definici pravidel pro čištění dat Využij specializované nástroje na čištění dat Přenes odpovědnost za čištění dat na provozovatele OLTP (čisté extrakty pro DW) – je.li to možné

ETL Kontrola správnosti dat Dotazy vůči provozním systémů Porovnání s DW Možnost automatizovat a ukládat do metadat Ruční prohlídka Nejde-li testovat vůči provozním (např. informace v DW z více zdrojů) Hledat odchylky, možné chyby Spolupracovat s uživateli (experty) Těžko kdy ale bude všechno pasovat se vším

ETL 0. vrstva Potřeba kontrolovat dostupné místo na disku Často místo pro zálohy Obsahuje detailní data Je možné z nich rekonstruovat další vrstvy (?inkrementální load fakt a dimenzí?) Není třeba je zálohovat (data jejich, modely ano) Může sloužit pro nové transformace (např. pro data mining) Potřeba kontrolovat dostupné místo na disku Např. i místo přidělené pro růst databáze, zda nedojde k jeho vyčerpání během ETL – problém Někdy vhodné vytvořit speciální opravné pumpy

Praktický příklad 4 Tvorba modelu a naplnění 1. vrstvy Využití DTS SQL skripty Create Naplnění

Agenda BDLC Plán projektu a projektový management Business požadavky Dimenzionální modelování Architektura Fyzický design ETL Uživatelské aplikace Nasazení Správa a růst DW

Uživatelské aplikace Důležitá část z hlediska „prodeje“ předchozího úsilí Vytvořit šablony (parametrizované) standardních reportů Operativní Taktické Strategické Podpořit ad-hoc analýzu Podpořit plánování, stanovení rozpočtu, předpovědi, what-if analýzy Čerpají data z DW a potřebují výsledky někam zapsat (často i verze) Zápis do DW (vlastní faktová tabulka)

Uživatelské aplikace Potřeba využít flexibilních nástrojů, Verifikace Objevování Jaký je průměrný prodej dle jednotlivých okresů? Jaké jsou nejlepší prediktory prodeje? Jaký je průměrný věk zákazníků? Co zapříčiňuje odchod zákazníka? Potřeba využít flexibilních nástrojů, multidimenzionální pohled na data, data mining

Uživatelské aplikace Potřeba zapojit uživatele Vhodné definovat počáteční množinu reportů co nejdříve po interview (sbírání uživatelských požadavků) Kroky: 1. Určení počáteční množiny reportů Vybrat 10 – 20 hlavních reportů Identifikovat kandidáty Např. v excelu soupis reportů z interview, popis, řádku, sloupce, ukazatele, komu slouží Ukázat uživatelům k doplnění Kategorizovat reporty Výkonnost (prodej, podíl, hodnota) Trendy Odchylky, výjimky (Top n, odchylky od normálu) Důvody odchylek What-if Dopady rozhodnutí, promocí, … Nastav priority Identifikuj skupinu A (implementována v první fázi) Skupina B – v druhé, skupina C – možná v třetí

Uživatelské aplikace Pozn: Je-li to možné nekopírovat původní reporty Většinou nebudou přesně sedět čísla Potřeba dopředu vědět proč Uživatelé ztrácí důvěru v DW Ukázat uživatelům něco nového

Uživatelské aplikace Kroky: 2. Určit strategii navigace Počet reportů bude rychle růst Potřeba najít způsob jejich uspořádání – přehledné pro uživatele Podle obsahu, nebo dle oddělení, …

Uživatelské aplikace Welcome Sales volume report Forecastying Pricing analyst Inventory tracking To desktop application Product topline template Produkt trend template Market topline template Market trend template

Uživatelské aplikace Kroky 3. Vytvořit standardy tvorby reportů Dohodnout standardy pro tvorbu reportů Jmenné (jména reportů, atributů), formátovací (co v hlavičce – datum vytvoření, počet stran, zdroj dat, pro koho určeno), standardní zkratky – pro lepší uživatelskou orientaci Naplnit metadata těmito informacemi 4. Vytvořit reporty na detailní úrovni Vytvoř prvních 10 až 20 šablon reportů Dokumentace Metadata (popis reportů) Název šablony Popis Frekvence plnění Nastavitelné parametry Default omezení (např. že je za aktuální rok) Způsob výpočtu odvozených faktů Poznámky Nechat zkontrolovat uživateli

Uživatelské aplikace Nasazení reportů Několik možností Přístup přes Web Asi nejhodnější, možno rozšířit o přístup k metadatům Speciální reportingové nástroje Vlastní vývoj Načasovat plnění reportů Nebo nechat vybrané on-line (např. pro zadání parametrů) Testovat reporty Na různých strojích, různé dotazy Porovnat s OLTP Rozdíly (jiná definice faktu, jinak počítá reportingový nástroj, správně v DW a špatně v OLTP – potřeba vysvětlit uživatelům) Podpora uživatelům – získat od nich zpětnou vazbu, zda jsou reporty bez chyb

Uživatelské aplikace V čase je třeba sledovat reporty Přidávat nové Aktualizovat staré (nové zdroje, změna stávajících) Monitorovat výkonnost reportů (čas tvorby) Sledovat využívání reportů Odstranit nepoužívané reporty

10. Přednáška

OLAP Popis – definice Způsoby uložení dat (MOLAP, ROLAP, HOLAP) Výhody, použití Příklady výstupů Vypočítané ukazatele Bezpečnost na kosce Ukázka Analysis Services

OLAP SW technologie, která umožňuje analytikům a managerům získat informace z dat rychle, konzistentně a interaktivně za pomoci široké škály pohledů vytvořených z relačních dat a odrážejících pravou dimenzionalitu obchodního světa, kterou rozeznávají uživatelé. Vizualizace Bezpečnost Flexibilita OLAP Interaktivita

OLAP OLAP funkcionalita poskytuje dynamický multidimenzionální přístup k datům, analýzu dat a podporuje analytické a navigační aktivity OLAP funkcionalita je poskytována pomocí OLAP Serveru OLAP Server: Výkonný, víceuživatelský server vytvořený pro podporu a správu operací nad multidimenzionálními strukturami uložení dat

OLAP je FASMI Fast Analysis Shared Multidimensional Information Do 30 sekund (dle výzkumu v Holandsku) Neovlivněno množstvím dat Analysis Flexibilita (ad-hoc dotazy, vypočítané ukazatele) Důraz na obchodní logiku Shared Stejné výsledky pro všechny (konzistence dat) Bezpečnost dat – oprávnění uživatelů Multidimensional Základ analýz OLAP – dimenzionální modelování Information Důraz na zpracování velkého objemu informací Není důležité kolik GB bude potřeba

OLAP Multidimenzionální uložení dat – multidimenzionální databáze (krychle) Uloženy data i agregace roll-up region roll-up značka Ostrava Dimenze: Time, Product, Geography Hierarchie: Druh  Značka  … Den  Týden  Kvartál Město  Region  Země Brno Praha Rohlík Zmrzlina Sýr Chleba Produkt (druh) 28 roll-up týden P U S Čt Pá S N Čas (den) 28 kusů chleba prodaného v Praze v pondělí

OLAP Druhy uložení OLAP: MOLAP – Multi-dimensional OLAP Data i agregace uložení v multidimenzionální databází Rychlé, výkonné, pro menší objemy dat ROLAP – Relational OLAP Data a agregace uloženy v relační databázi Pro velké objemy dat, rychle se měnící HOLAP – Hybrid OLAP Kombinace MOLAP a ROLAP Agregace v multidimenzionální databázi, detailní data v relační Rychlé pro sumární informace, pomalejší pro detailní DOLAP – Desktop OLAP Zjednodušená verze MOLAP nebo ROLAP

OLAP Možno definovat složité výpočty na úrovni OLAP databáze Např. MDX jazyk – MS Analysis Services 2000

OLAP Výhody uložení dat v OLAP: Příklad nástrojů Rychlí přístup k datům Uživatelský přívětivé Standardní rozhraní Drag and drop Vizualizace Příklad nástrojů MS Analysis Server 2000 Oracle Discoverer SAS Warehouse Administrator, SAS MDDB serverBusiness Warehouse (SAP) Microstrategy …

Praktický příklad 5 Vytvoření OLAP krychle MS Analysis Services Ukazatel: Prodej Kč, Prodej Ks Dimenze: Zakaznik (Kraj – Mesto – Jmeno) Čas (Rok – Kvartal – Mesic – Den) Produkt (Kategorie – Subkategorie – Nazev) Dovozce (Nazev) Prodejce (Pobocka kraj – Mesto – Jmeno) Prohlídka dat v MS Excel

Agenda BDLC Plán projektu a projektový management Business požadavky Dimenzionální modelování Architektura Fyzický design ETL Uživatelské aplikace Nasazení Správa a růst DW

Nasazení Zkontrolovat připravenost (SW, HW) serveru a uživatelských stanic Databázová konektivita, internet, přístup k databázi SW instalovaný Naplánovat nutné reinstalace, upgrade, … Získat login pro jednotlivé uživatele Test na různých stanicích Vytvořit strategii školení uživatelů Důležité – aby uživatelé opravdu využívali DW Seznámit s daty, jejich význammen, nástroji pro přístup k datům, metadaty Customizované pro jednotlivé skupiny uživatelů dle jejich potřeb Specializované kurzy pro pokročilé analytiky Při prvním školení základy, ne se snažit jim říci vše, budou ještě další příležitosti

Nasazení Možné pro školení připravit speciální databázi s vzorkem dat Rychlejší odpovědi, konzistentní přes více školení

Nasazení Body školení Představení DW a projektu Prohlídka dat DW Web site Jak začít Prohlídka dat Dimenze Fakta Jak je prohlížet Uživatelské aplikace Předpřipravené reporty Jak se k nim dostat Jak je využívat Další možnosti Tisk Export do Wordu, Excelu Manipulace s report – grafy, drill-down, … Aplikace toho co se naučili na reálném příkladě Diskuze

Nasazení Provádět školení, když už DW běží „bez chyb“ Jinak riziko, že uživatelé ztratí důvěru v DW, když ještě bude ve fázi plné chyb Nastavit politiku:“bez školení – DW není přístupný“ Zmenšit riziko rozčarování nad DW Nastavit strategii podpory uživatelů Umožnit uživatelům přístup k dokumentaci (DW, nástrojů pro přístup k datům) a metadatům Vytvořit web portál datového skladu

Nasazení Sales activity Standard report A analysis Customer services DW overview About the reports About data Metadata browser Learn about The warehouse Education and class schedule DW home page Call traccking Status inquiry DW status User list And DW team contact Data load status Warehouse community DW discusion group Conntact DW team Public status summary Fact of the month Cool techniques Or analysis What is new

Nasazení Vlastní nasazení se může připodobnit k nasazení SW (verze) Alfa verze DW Testovat technickou infrastrukturu, ETL, kvalitu dat, výkonnost, reporty, metadata Interaktivní proces odstraňování chyb Zapojen tým DW případně pokročilí business analyst Beta verze DW přístupný malému počtu vybraných uživatelů 10 až 15 Musejí být flexibilní, motivovaní, dostupní Zabere jim dost času – potřeba podpory jejich vedoucích Budou pak pro uživatel zdrojem informací o DW Každá další etapa růstu DW by měla projít beta testováním Finální verze Umožnit uživatelům přístup ve vlnách (po 10 až 15) – zvládnutelné lépe z hlediska podpory uživatelů

Nasazení Finální nasazení Co je třeba zkontrolovat: Uživatel prošel školením a druhý den už může pracovat s DW Co je třeba zkontrolovat: Desktop stanice Potřebný HW a SW Uživatel má přidělen přístup k DW Kvalita dat Porovnány výstupy s OLTP Rozdíly vysvětleny, zdokumentovány a vysvětleny uživatelům Otestovány uživatelské aplikace (a reporty) Uživatel prošel školením Je nastaven způsob podpory uživatelů (zaznamenávání problému a jejich řešení) Dokumentovat plán nasazení

Agenda BDLC Plán projektu a projektový management Business požadavky Dimenzionální modelování Architektura Fyzický design ETL Uživatelské aplikace Nasazení Správa a růst DW

Správa a růst DW DW se stále se vyvíjející „organizmus“ Je třeba reagovat na změny požadavků, změny zdrojových systémů, … Správa DW – potřeba zajistit finanční fondy Obecně bude potřeba na správu asi 50 procent zdrojů co na vývoj Není-li DW využíván je třeba zjistit příčiny Business sponzor odešel z organizace, nebo už nepodporuje DW? Naplňuje DW požadavky uživatelů? Rozumí uživatelé dimensionálnímu modelu? Prošli uživatelé školením? Mají uživatelé podporu, vědí kam zavolat, jsou jejich problémy řešeny? Neobsahují data chyby? Jsou data dostupná včas (ve správné frekvenci)? Je výkonnost DW dostatečná, není nutné příliš dlouho čekat na odezvu? …

Správa a růst DW Jako v business Je levnější si udržet stávajícího zákazníka DW než získat nového Podporovat stávající zákazníky DW – zvyšovat jejich loajalitu k DW (budou o DW říkat ostatním) Důležité jsou první 2 týdny od nasazení Uživatelé musí cítit podporu Např. vyhlásit úřední hodiny pro dotazy na DW (uživatelé mohou přijít pro radu a kafe) Pokračovat ve školení Pokročilá analýza Refresh školení Školení pro nové zaměstnance (pravidelně např. 1 za čtvrtletí) Web stránky DW Newsletter DW Pravidelné semináře při kávě – řešit aktuální problémy, novinky, …

Správa a růst DW DW se stane kritickou aplikací pro firmu Hlavní zdroj informací Data musí být dostupná co nejdříve Vysoké nároky na řízení DW Školení správců (nové trendy, nástroje, …) Monitorovat HW, SW, infrastrukturu Síť, výkonnost, zaplnění disků, … Ladění databáze (indexy, agregace, …) Upgrade nové technologie Oddělit provozní a vývojové prostředí Změny provozních systémů Změny ETL Aktualizace metadat Modifikace provozních systému dle chyb zjištěných při loadu do DW Reakce na nové potřeby uživatelů (nové reporty, …)

Správa a růst DW Monitorovat a marketovat úspěch DW Sledovat naplnění kritérií úspěchu DW Sledovat Využití DW (počet login, doba strávená) Počet dotazů na podporu a čas potřebný na řešení Zaznamenávat např. v DW (vlastní fakt tabulka) Prezentovat managementu Spočítat ROI Zaznamenat rozhodnutí učiněná po používání DW Část zisk přičíst na vrub DW

Správa a růst DW Marketovat DW Oproti provozním systémům uživatelé DW nemusí používat Rozhodovali se bez informací před tím, řada z nich v tom chce pokračovat Potřeba informovat o výhodách a úspěchu DW Např. „určit mluvčího DW“, který prezentuje DW Udržovat komunikaci S business sponzorem Uživateli IS pracovníky DW týmem

Správa a růst DW DW se stále buduje Na první etapu navazují další etapy Jejich realizace opět dle popsané metodologie Využívá již nainstalované technologie a uživatelské nástroje Reviduje potřeby jejich upgrade nebo přidání nových Je vhodné ustanovit Řídící výbor DW Složen ze zástupců IS a uživatelů S vlivem, s důvěrou v informační podporu rozhodování, s drivem k DW, s představou směrování celé firmy Rozhoduje o prioritách dalšího rozvoje DW, podstatných upgrade, financích na rozvoj Setkání přibližně jednou za čtvrtletí Ustanovit dokument strategie rozvoje DW

Správa a růst DW Řídící výbor Je mu předložen k schválení seznam menších změn, jejich priority Případně co bylo od minule uděláno za menší změny Jsou mu předloženy návrhy na další etapy Provedeny pro ně hrubě studie proveditelnosti (čas, potřebné finance, …)

Gratuluji Právě jste dokončili tvorbu datového skladu a úspěšně jste ho nasadili!!!

Tipy a triky budování DW Potřeba získat podporu vedení Nejkritičtější je kvalita dat v provozních systémech Dopad na náročnost ETL procesu Potřeba široké komunikace s uživateli Učit práci s informacemi Začít jednoduchou aplikací – rychlí přínos výsledků Proof-of-concept

11. Přednáška

Agenda CRM Analytické metody – Data Mining

CRM Existuje mnoho definic: Zákaznicky orientovaná obchodní strategie umožněná současnou a vznikající technologií Budování bližšího vztahu a poznání mezi zákazníkem a firmou Zvyšování prodeje, loajality zákazníků, zefektivnění servisu pomocí znalosti zákazníka CRM je koncept nebo manažerská disciplína zaměřená na to jak firma může zvýšit loajalitu svých nejziskovějších zákazníků za současného snížení nákladů a zvýšení zisku (Subbarathnam Swaminathan, CRM.Talk) CRM se soustřeďuje na poskytování optimální hodnoty zákazníkovi – za pomoci komunikace se zákazníkem, způsobu prodeje zákazníkovi, servisem zákazníkovi jako i za pomoci tradičních prostředků jako jsou produkt, cena, promoce, způsob distribuce (Melinda Nycamp, Nycamp consulting group) Více

CRM CRM je a mnoho dalšího: Firemní filozofie SW, který implementuje marketingové, prodejní, servisní obchodní procesy Velká řada aplikací Způsob uspokojení zákaznických potřeb a očekávání Více

CRM 3 základní typy CRM interakce Prodej – efektivní prodej, tvorba nabídek, znalostní systém, prodejní síť, forecasting Marketing – zacílení na potencionální zákazníky, získání nových zákazníků, využití data miningu, campaign management, distribuční kanály Servis – poprodejní podpora, call centum, www aplikace pro zákazníky Více

CRM CRM označuje zákaznicky orientovaný přístup k relevantnímu, nákladově efektivnímu a časově příhodnému prodeji zboží (služby) zákazníkovi a zaručující maximalizaci zisku firmy Zákazník Organizace

CRM Pouze 4% nespokojených zákazníků si stěžuje firmě Přes 90% nespokojených zákazníků se nevrátí Každý nespokojený zákazník to oznámí v průměru 9 známým Udržet zákazníka stojí v průměru pětinu až šestinu nákladů na získání nového zákazníka Spokojený zákazník je ochoten platit více Spokojený zákazník to oznámí v průměru 5 znaným

CRM Pravděpodobnost prodeje novému zákazníkovi je 15% zatímco stávajícímu 50% Firma může zvýšit zisk až o 85% udržením 5% zákazníků navíc Zákaznicky orientované firmy jsou o 60% ziskovější než tradiční firmy

Source: Microstrategy CRM One-to-one Marketingový přístup Mass marketing Jeden pro všechny Individuální Produktový přístup Source: Microstrategy

Zpracování objednávky CRM Od: Izolovaný zákazník Důvěrný vztah Jednotný pohled na zákazn. Komunikace Služby dle hodnoty zakazn. Do: Zákaznická orientace Neosobní vztah Nekonzistentní pohled Slabá komunikace Stejné služby pro všechny Dodávka Prodej Vedení Podpora zákazníků Platba Zpracování objednávky Dodávka Podpora Lidské zdroje Podpora Dodávka Lidské zdroje Prodej a marketing Výroba Ředitelství Finance Prodej a marketing Výroba Ředitelství Finance

CRM Starý pohled: Supply Chain (ERP) Nový pohled: CRM

CRM Základní části řešení CRM Collaborative CRM Operativní CRM Front-end aplikace Zabezpečení kontaktu se zákazníkem Aktuální potřeby – Co se děje Operativní CRM Operativní rozhodnutí Data pro Collaborative CRM Analytické CRM Proč se to děje? Back-end systém Získávání znalostí o zákaznících (Data Mining) Data pro operativní CRM Někdy označováno jako operativní CRM celé

CRM CRM aplikace Zákazníci Modely chování Datový sklad zákazníků Vztah (CRM) Znalosti o zákaznících Modely chování zákazníků Datový sklad Analýza zákazníků

CRM – loajalita zákazníka Příjmy Loajální a spokojený zákazník Podpora prodeje cross-selling, up-selling, … Získání zákazníka Náklady Nový zákazník Podpora stávajícího zákazníka

CRM Představ služby a produkty Cross selling Up selling Hodnota zákazníka (Life time value) Cross selling Up selling Loajalita

CRM Plánování/Analýza Operativní CRM Analytické CRM Akce Zpětná vazba Marketing Prodej Podpora Operativní CRM Marketingové analýzy Prodejní Zákaznické Analytické CRM Akce Zpětná vazba Web Call centrum Přímý prodej Collaborative CRM

CRM Datový sklad Collaborative CRM Marketing Prodej Zákazníci Operativní CRM Reporting OLAP Data Mining Segmentace Detekce podvodů Predikce Analytické CRM Kampaně Credit scoring Plánování promocí Churn (odchod zákazníka) Event Scheduling Cross selling

CRM Prodej Marketing Podpora Čas CRM úkol Řešení Prodej Před prodejem Collaborative CRM Prodej Prodej Udržet zákazníkovu loajalitu Automatizace prodeje Předpovědi prodeje Hledání příležitostí Objednávkový Mgt. Náhrady, Slevový Mgt. Kategory Mgt. Marketing Před prodejem Personifikace Marketingové předpovědi Kampaň Mgt. Event Mgt. Promoce Katalog Mgt. Marketingový mix Balíčky Operativní CRM Podpora Po prodeji Zesílit zákazníkovu spokojenost Předpověď potřeby podpory Průzkumy spokojenosti Zákaznická péče Reklamační řízení Náhrada zboží Call, web centrum Analytické CRM

Komunikace se zákazníkem CRM Collaborative CRM Prodejny Fyzická Face-to-face Direct mail Call centrum Telekomunikace SMS Mobil CRM DB Operativní CRM Komunikace se zákazníkem Web Internet Chat Email Analytické CRM

CRM – kroky k úspěchu Krok1 Celopodnikový konsenzus na vývoji a nasazení CRM řešení Vytvoření CRM projektového týmu Analýza obchodních potřeb Plán CRM aktivit Výběr CRM SW Výběr dodavatele Tvorba CRM aplikací a nasazení Údržba a růst CRM řešení Krok2 Krok3 Krok4 Krok5 Krok6 Krok7 Krok8

CRM – začít v malém Současné obchodní problémy/příležitosti Vysoce ziskové kampaně Fáze 1 Současné obchodní problémy/příležitosti Optimální start: - Cross-selling - Churn - Direct mailing Datová architektura Cílení analýza zákazníků Využití kanálů - Mail - Call centrum - Web - Prodejní místa - … Fáze 2 Kampaně na podporu zákazníků Business processes reengineering Nákup CRM systému CRM orientace organizace Training CRM technologií Fáze 3 Prorůstání CRM v organizaci Dlouhodobé plánování Strategické řízení zákazníků Rozšíření systémů - Architektura - CRM Nové možnosti kanálů - Call centre - E-commerce Fáze 4 Dlouhodobé plánování CRM

CRM Úspěšné CRM stojí na pěti pilířích: Strategie Informace Zákazníci (cílový segment, potřeby, nároky, chování, zvyky, ...) Trh (otevřenost trhu, velikost, růst, konkurence, …) Produkt (cena, balíčky, vlastnosti, …) Kanály distribuční (preference zákazníků, trendy, náklady, …) Zaměstnanci (schopnosti, znalosti, školení, motivace, …) Informace DW, Householding, … Funkcionalita Ohodnocení zákazníka Risk analýza Segmentace Modelování chování Cílený marketing (Campaign management) Integrace Integrace kontaktu se zákazníkem a informací a analýz o zákazníkovi Technologie Podpora funkcionality (reporting, DM, Statistika, …)

CRM – hodnota zákazníka Nábor Aktivace CRM management Potencionální zákazník Nový zákazník Stávající zákazník Dřívější zákazník Vysoká hodnota Neřízený odchod Cílový trh Nový zákazník Začátek vztahu Vysoký potenciál Řízený odchod Nízká hodnota Zpětná vazba

CRM - metriky Kdo je náš zákazník? Jak se k němu můžeme dostat? Profilace Demografie “Firmografie” Jak se k němu můžeme dostat? Segmentace Jak s námi zákazníci přicházejí do kontaktu ? Face-to-face Katalog Direct mail Internet

CRM - metriky Jaká je hodnota zákazníka pro firmu? Ziskovost Lifetime Value Loajalita V jakém životním cyklu se zákazník nachází? Počáteční fáze Růst Dospělost Jaké jsou zákazníkovy postoje? Jak se zákazník v čase mění?

CRM „Nábor“ zákazníků: Jaké jsou charakteristiky dobrých zákazníků? Na které potencionální zákazníky bych se měl zaměřit? Jak mohu zvýšit odpovědi na promoce? Jak mohu předpovědět, zda potencionální zákazník bude dobrý zákazník? Hodnota zákazníka v čase: Jaká bude celoživotní hodnota zákazníka? Cross marketing (Jaké další produkty mohu zákazníkovi prodat)? Retence a odchod zákazníků: Kteří zákazníci pravděpodobně odejdou ke konkurenci? Které zákazníky chci nechat odejít? Které zákazníky si chci udržet?

DM Analytické aplikace -> předávám slovo SPSS CR

Praktický příklad Praktický příklad

Děkujeme za pozornost Ing. David Pirkl pirkld@centrum.cz