Modelování a návrh datových skladů

Transkript

1 Modelování a návrh datových skladů Doc. Ing. B. Miniberger, CSc. BIVŠ

2 Obsah 1. Přednáška I. Základy modelování datových skladů (DW) 2. Přednáška II. ETL procesy III. Data Mining IV. Kvalita dat a BI

3 Literatura Humphries M. a kol. : Datawarehousing (navrh a implementace). Computer Press, ISBN RUD Parr Olivia: Data Mininig. (Praktický průvodce dolováním dat pro efektivní prodej, cílený marketing a podporu zákazníků (CRM). Computer Press, ISBN INMON W.H.: Building the Data warehouse. Vydání třetí. New York: Willey s Publishing, ISBN KIMBALL R.: The Data warehouse Toolkit. New York: Willey s Publishing, ISBN LACKO L.: Datové sklady analýza OLAP a dolování dat. Brno: Computer Press, a.s., ISBN MINIBERGER B.,: Kvalita dat datových skladů nezbytný předpoklad předcházení rizik manažerského rozhodování. Sborník z 11. ročníku mezinárodní konference Současnost a budoucnost krizového řízení. Praha 2009, ISBN

4 Odkazy na webu ADASTRA. Dostupný z : Ballard Chuck, Herreman Dirk,, Schau Don, Bell Rhonda,Kim Eunsaeng, Valencic Ann: Data Modeling Techniques for Data Warehousing. ISBN In: ORACLE. An Introduction to OLAP In: Chuck Ballard, Daniel M. Farrell, Amit Gupta, Carlos Mazuela, Stanislav Vohnik: Dimensional Modeling:In a Business Intelligence Environment. In:

5 Strategie a procesy v podnikání (podle Meta Group) Periody cyklů se zkracují Perioda cyklů v 70 tých a 80 tých létech byla: 5-7 LET Periody cyklů pro období po r měsíců Technology Competition Economics Policy Leadership Doc. B. Cíl: Miniberger, Adaptivní CSc. Modelování IT architektura a návrh DS pro podnikání

6 Konflikt změn Rychlost změn podnikatelských procesů je často větší než kapacitní možnosti IT

7 Požadavky na IT pro 21. století Každé 4 roky vzrůstá potřeba dat 12 x. Neřízený nárůst dat způsobuje snižování produktivity a zvyšuje náklady. Proces řízení nárůstu dat lze považovat považuje jako problém No 1. Aktuálnost dat se stává největší potřebou distribuovaných systémů v prostředí UNIX a NT. Mission critical data jsou všude - uvnitř i vně datových center. Petabytes 1, * Source: IDC,

8 Požadavky na Správu dat Archivace databáze a souborů denně. Přesun dat a souborů (např. mezi MVS a UNIX MS Windows, Linux) denně. Prvotní tvorba testovacích dat opakovaně. Obnova testovacích dat změněných testovacími procedurami denně. Extrakce, formátování a slučování dat pro použití v data warehouse a v data marts denně. /týdně/měsíčně Migrace dat z jednoho na druhé zařízení - ročně, nebo jakmile je zpracování uzavřeno. Migrace celých datových center zřídka. Katastrofy- zřídka.

9 Informační pyramida (podle IBM) a její podpora pomocí: Datový sklad s OLAP OLTP

10 Architektura CRM + DWH Interakce se zákazníkem Fax, telefon, TV, informační kiosky, , direct (přímá), WWW Operační část Analytická část Podnikové aplikace (ERP) Obsluha zákazníka Marketing Prodej Servis Trh Průzkum trhu Data warehouse Znalostní DB Řízení kampaně Zákazník 10

11 Co je datový sklad a jak pracuje? 1. (Datový sklad (Datawarehouse, DWH, DS) je sdružený zdroj informací shromážděných z dat firemních systémů. 2. Z pohledu koncového uživatele umožňuje Datový sklad snadný a rychlý přístup k firemním informacím. 3. Díky tomu umožňuje uživateli získávat odpovědi na často velmi složité dotazy a jejich vyhodnocování, aniž by byl vybaven hlubokými znalostmi programování.

12 Schéma datového skladu (DWH)

13 Spolupráce OLTP a OLAP OLTP & jiné zdroje dat OLAP Databáze ETL Přínos pro podporu rozhodování 20% 80%

14 Rozdíly ve schématech OLTP v. OLAP

15 Co je datová kostka OLAP?

16 Rozdílné pohledy na data Multidimenzionální pohled na data: Čas Produkt Obchod Pomocí OLAP databáze, může uživatel lehce zjistit data, která ho v daných souvislostech zajímají. vyžadují nové druhy operací na DM OLAP (viz dále) Pohled produktov ého manažera Produktový manažer sleduje jeden produkt napříč časovými intervaly a obchodními jednotkami. Pohled regionální ho manažera Regionální manažer sleduje všechna údobí prodeje za všechny produkty v daném regionu. Pohled finančního manažera Finanční manažer se zaměří na prodeje za předchozí a minulé období za všechny obcodní jednotky a produkty Přležitost ný pohled vrcholého řízení Strategické řízení se může zaměřit na podmnožinu podnikových dat jak v současném, tak v minulém období, za účelem zvýšení prodeje nějakého výrobku v daném regionu..

17 Příklad DM typu hvězda Hvězdicové schéma pro obchodní organizaci : Čas Produkt Fakta jsou normalizovaná. Klient Prodej (tabulka faktů) Organizace Dimenze nemusí být normalizovaná, ale mohou být.

18 Dimenzionální modelování Systémy OLTP používají normalizované datové struktury, ale nejsou optimalizovány pro podporu rozhodování Nejsou pro obchodního uživatele příliš pochopitelné Vyžadují znalost jazyka SQL Dimenzionální modelování OLAP systémů je vhodné pro podporu rozhodování Dva typy tabulek: Tabulky faktů, které jsou používány pro ukládání záznamu např. aktuálních obchodních faktů, či měřítek. Fakta jsou čísla, která uživatelé analyzují a sumarizují s cílem získat lepší pochopení svého podnikání Tabulky dimenzí, které stanovují obsah faktů a obsahují atributy popisující fakta, pro jednotlivá průmyslová odvětví. Tabulka faktů + tabulky dimenzí = schéma OLAP

19 Granularita tabulky faktů Granularita určuje úroveň podrobností v tabulce faktů. V případě tabulky faktů granularita pochopitelně vychází z úrovně podrobností odpovídajících dimenzí. Čím nižší je úroveň granularity, tím detailnější jsou data určená k provádění matematických operací. Příklad: jestliže každý záznam v časové dimenzi odpovídá jednomu dni, jestliže každý záznam v tabulce dimenzí Produkt odpovídá jednomu produktu, jestliže záznam v dimenzi Organizace odpovídá jedné pobočce, Pak pole tabulky faktů s těmito dimenzemi bude: Prodej produktů za jednotlivé dny a jednotlivé pobočky.

20 Spojení klíče v tabulce faktů Jelikož Granularita tabulky faktů určuje úroveň podrobností odpovídajících dimenzí, potom Hodnota klíče v tabulce faktů je spojením klíčů každé z odpovídajících dimenzí.

21 Datový model hvězda Dimenze Fakta PK

22 Datový model vločka PK Rozdělením tabulky na podtabulky

23 Hierarchie dimenzí Čas Rok Čtvrtletí Měsíc Den Obchod Všechny obchody Region Stát Město Produkt Všechny produkty Produktová oblast Kategorie produktů Produkt Prodej všech produktů podle regionů v jednotlivých letech. Rok Region Asie Evropa Amerika Asie Prodej

24 Rozpad (zjemňování) dimenze čas Čas Rok Čtvrtletí Měsíc Den Obchod Všechny obchody Region Stát Město Produkt Všechny produkty Produktová oblast Kategorie produktů Produkt A odpovídající sestava: Prodej všech produktů podle regionů v jednotlivých ČVRTLETÍCH. Rok Čtvrtletí Region Prodej Asie Asie Asie Asie Evropa

25 Operace OLAP podporované v DM Agregace je předpřipravená sumace, na základní úrovni, pro vyšší úrovně v hierarchických dimenzích. Pivoting (rotating) - změna vizualizace dat kostky. Roll-up: sumarizace zaměřená na vyšší úroveň, navigována hierarchií dimenze (od prodeje podle města k prodeji podle obvodu). Drill-down: rozpad - zjemňování k větším detailům (od prodeje podle obvodu k prodeji podle města). Slice_and _dice (redukce dimenzionality dat).

26 Agregace a sumace Čas Rok Čtvrtletí Měsíc Den Obchod Všechny obchody Region Stát Město Produkt Všechny produkty Produktová oblast Kategorie produktů Produkt Možnost používat agregace zvyšuje celkový výkon a použitelnost DS. Agregace jsou vlastně sumace na základní úrovni uložená v samotném schématu, pro vyšší úrovně v hierarchiích dimenzí

27 Příklad multidimenzionalního modelu Metriky

28 Vizualizace modelu Metriky

29 Metrika (Measure) A measure (metrika) je numerický atribut tabulky faktů, reprezentující výkonnost nebo chování podnikání ve vztahu k dimenzím. Metrika je určena kombinací členů dimenzí a je založena na faktech.

30 Drill Down and Roll Up Roll-up: od prodeje podle města k prodeji podle obvodu Drill-down: od prodeje podle obvodu k prodeji podle města

31 Metriky Slice and Dice Rotace X Redukc e diemzio nality

32 Obvyklý postup návrhu DS (Od modelování procesů k implementaci a ne jinak)

33 Nejprve analýza věcných požadavků Věcný cíl - strategický cíl podnikání, definovaný vedením banky. Kritická oblast výkonnosti (KOV) - oblast, ve které musí být dosažena určitá efektivní úroveň výkonnosti aby banka mohla dosáhnout svých cílů. Kriterium výkonnosti - ukazatel, umožňující stanovit výkonnost sledované oblasti nějakou metrikou (poměrem nebo v jednotkách). Požadavek - požadavek na zdokonalení výkonnosti v KOV. Problém - okolnost, významně bránící dosažení požadované úrovně KOV ve stávajících podmínkách.

34 Výsledky analýzy kritických požadavků Stanovení věcných cílů. Stanovení kritických oblastí výkonnosti. Specifikace výkonnostních kriterií a požadavků. Specifikace a ohodnocení problémů. (Vyhodnocení návrhů alternativ systému).

35 Stanovení věcných cílů Rozvoj komerčního bankovnictví, jako základu stabilního vývoje a výnosnosti

36 Stanovení funkčních KOV Projekt Podpora řízení prodeje. 1. Individuální obsluha klienta 2. Organizační zabezpečení 3. Zavedení systému řízení prodeje 4. Lidské zdroje 5. Informační technologie 2.1 Metodické 2. 2 Přímé Retail a Corporate 4.1 Odměňování 4.2 Kvalifikační růst 1.1 Obchodní manažeři 1.2 Nabídka produktů 3.1 Segmentac e 3.2 Propagace 5.1 SW 5.2 HW

37 Definování a vyhodnocení problémů P1 Klienti (počet, segmentace, objem vkladů...). P2 Produkty (počet, objemy, období..). P3 Obchodní manažeři ( objem obchodů, kvalifikace, zkušenosti..). P4 Metodika ( přehlednost, podpora PC, školení...). P5 Forma propagace ( TV, sponzorství, INTERNET, DirectMarketing). P6 Osobní zainteresovanost, Školení, Vyhodnocování. P7 Podpora IT (Implementace, Správa dat, Intranet...).

38 Návrh pohledů systému Model Přehled úrokových sazeb Model Konjunkturní indikátory Model Analýzy trhu Pohled 1 Pohled 2 Klienti Vklady Pohled 3 Pohled 4 Kč Úvěry Prodej produktů Pohled 5 Vztahy klientů s bankou

39 Reportování 3 hlavní typy analytických systémů: nástroje pro dotazy a tvorbu výstupních sestav - nabízejí jednoduchý přístup k relačním databázím a uživatelsky jednoduchým způsobem tvorbu dotazů a reportů nad relačními databázemi (pro menší aplikace i různé spredsheety, např. MS Excel apod.) OLAP (Online Analytical Processing) systémy - strukturují data do multidimenzionálních hierarchií agregovaných informací a tím nabízejí pohled na data z vhodných perspektiv a ve formě vhodných pro jejich analýzu. Systémy pro dolování dat, které predikují informace z velkého množství dat, na základě matematických modelů Moderní OLAP produkty nabízejí propojení všech tří způsobů, včetně komunikace mezi nimi prostřednictví technologií Internetu.

40 Zjednodušený DM úlohy Marketing: Možný dotaz: Na základě čísla účtu klienta, zjistěte stav jeho účtu a klasifikaci podle standardu ČNB, k danému datu. STŘEDISKO stredisko_id Tabulka dimenzí Tabulka faktů: KLIENT klient_id cislo_klienta název_ klienta segment_id. klasif_čnb_kod Fa:ÚCET_Datum klient_id ucet_id datum_id Zust_ult_mena. uroky_mena. datum_id ÚČET ucet_id stredisko_id mena_kod_id druh_uctu_id. syu_id DATUM datum_id MĚNA mena_kod DRUH ÚČTU druh_uctu_kod

41 ROI pro zavedení DS Zkvalitněním vlastních služeb Pomocí Customer Value Intelligence ROI = Jak zlepšit ROI??? Dosažené úspory + Zvýšení výnosů Celkové náklady na tvorbu a provoz Pomocí výběrových řízení na dodávky SW a HW, služeb, zavedením metodiky RAD,...

42 Bod zlomu návratnosti $ $ Dollars $ $ $ $ Bod zlomu pro návratnost Cumulative Savings Investment $ $ Time (Years)

43 Doporučení postupu tvorby DS Tvorba DS - společným vývojem: uživatelů, analytiků a programátorů provozovatelů Zabezpečení konsistence: nástroji pro datové modelování správou DS Řízení projektu: vedoucí projektu a jeho tým mapování a vyhodnocování postupu Realizace Provoz DS: uživatelské příručky konzultace při zavádění a provozu monitorování využití DS návrhy na racionalizaci ROI

44 Anatomy of a Data Warehouse Failure (anatomie neúspěchů tvorby DS) 1. chyba : Nezačínejte projekt bez jasného porozumění věcných cílů (Business Objectives) nebo uživatelských požadavků (Requirements). 2. chyba : Redundantní nebo zmatené definice dat. 3. chyba : Poskytování nepotvrzených (neautorizovaných) dat a reportů. 4: chyba: Zahájení plánu, který je podporován výkonným týmem (*B.M.: bez schválení řídící komise.) Podle Lawrence F. Goldman: Published in DM Review Online in February 2001

45 12 pravidel pro tvorbu OLAP (podle: Codd E.F., Codd S.B., and Salley C.T. "Providing OLAP (On-line Analytical Processing) to User-Analysts: An IT Mandate". Codd & Date, Inc < refer/codd.html 1. Multidemenzionální koncepce (provádění operací OLAP). 2. Transparentnost (propojení na front end systémy. 3. Dostupnost ( z kteréhokoliv datového zdroje). 4. Konsistentní provádění reportů (neměla by být degradována velikostí databáze). 5. C/S architektura (server zajišťuje integraci mezi klientskými a datovými zdroji (*nově podle B.M. i SOA). 6. Generická dimenzionalita (všechny dimenze se chovají stejně).

46 Pokračování 12 pravidel tvorby OLAP 1. Dynamické ovládání řídkých matic (automatické uspořádání profilů databáze). 2. Multiuživatelská podpora (souběžné vyhledávání a aktualizace se zabezpečenou integritou a bezpečností). 3. Neomezené provádění operací napříč dimenzemi (konsolidace kalkulů je prováděna automaticky, formule jsou k dispozici pro jiné kalkuly). 4. Intuitivní manipulace s daty (vybavování napříč dimenzemi měl by zahrnovat jednoduché operace). 5. Flexibilní reportování (reporty založené na animaci libovolně orientovaného datového modelu). 6. Neomezený počet dimenzí a agregačních úrovní.

47 Závěr Děkuji za pozornost