Správa dat v podniku. UAI /14 RNDr. Ondřej Zýka, ondrej.zyka@profinit.eu

Transkript

1 Správa dat v podniku UAI /14 RNDr. Ondřej Zýka, ondrej.zyka@profinit.eu

2 Obsah o Důležité oblasti pro správu, uchovávání a využívání dat v podniku Něco z historie ízení dat na úrovni podniku Data management a kategorizace dat

3 Historie o Relační model o SQL Edgar Frank Codd Derivability, Redundancy, and Consistency of Relations Stored in Large Data Banks Relační model matematický model pro ukládání a správu dat Tří hodnotová logika True, False, Unknown Donald Chamberlin, Raymond F. Boyce SEQUEL (Structured English Query Language) IBM - První návrh 1979 první komerční implementace Oracle V2 (Relation software)

4 Historie 1969 Codd - Relační model 1970 Chamberlin, Boyce SQL 1979 Oracle 2, basic SQL, no transaction Založení Teradata 1980 HW - První gigabajtový disk, váha 250 kg, cena $40, HW - 640Kb RAM je dost pro každého (??Gates) 2GB efektivně Windows 32 bit 1983 Oracle 3 - transaction 1984 Oracle 4 read-consistency 1984 Sybase founded by Mark Hoffman and Bob Epstein in Berkeley 1985 Oracle 5 networking, client-server 1986 HW - Standartizace SCSI 1988 Oracle 6 PL/SQL, row level locking, hot backup 1987 Sybase - formally released the SYBASE, Client-server, Transact SQL,

5 Historie 1988 Sybase/Microsoft - sdílení kódu s firmou Microsoft (od roku Ř6) Teradata ve spolupráci NCR uvádí databázový počítač 1991 HW 2.5" 100MB disk 1992 Oracle 7 referencial integrity, triggers 1993 Microsoft Win NT Sybase/Microsoft ukončení smlouvy 1995 Microsoft SQL Server Sybase row-lewel locking 1998 Microsoft SQL Server Oracle 8i java Teradata- největší zákaznická produkční databáze 130 TB 1999 HW IBM 170MB a 340MB disky 2000 Microsoft SQL Server Oracle 9i XML, RAC

6 2001 Sybase 12.5 XML, EJB 2003 Oracle 10 grid computing, flash back 2003 Windows Server bit system - překročení 2GB RAM 2005 Sybase 15 new query-optimalizator, Cluster edition 2005 Microsoft SQL Server HW 500GB disk (Hitachi GST) 2007 Oracle 11 Exadata 2007 HW 1TB disk (Hitachi GST) 2008 SQL Server HW SSD nyní 64 GB 300MB/sec (3000MB/sec.) 2010 Microsoft SQL Server 2008R2 Oracle kupuje SUN SAP kupuje Sybase EMC kupuje Greenplum IBM kupuje Netezza

7 Diskové kapacity (Wikipedia)

8 Historie o Další vlivy na vývoj Operační systémy a jejich unifikace Procesory zejména IBM, SUN, HP Diskové pole RAID Sítě, přenosové kapacity a Internet GUI a Microsoft Windows jako klientský systém

9 Data v organizaci o Desítky (stovky) systémů Každý systém pracuje s daty Většina systémů má data v databázi (relační) Většina systémů vyměňuje data s jinými systémy o Data jsou cenným majetkem organizace Jako budovy, stroje, lidé, Vyžadují správu Data managament

10 Velikost dat 10

11 Různorodost dat 11

12 Rychlost změny 12

13 )ákaz í i a uživatelé ODS Operač í data MDM Datová kvalita Integra ce DWH Jed ot ý odel Ko plet í historie I tegrova á data Byz ys, te h ologi ká a provoz í etadata Governance pravidla, orga izač í struktura, pro esy

14 Prostředí datově orientovaného systému Etapy život ího yklu Komponenty Skupi y uživatelů Plá ová í Vývoj Testová í Provozová í Udržová í Uko če í používá í Aplikač í progra y Interface DBMS Data Hardware Vlast í i aplika e Ar hitekti IT, Aplikač í, Datový ar hitekt Vývojáři Ad i istrátoři data ází Systé oví ad i istrátoři Ko oví uživatelé

15 Data management Data Management International

16 Data management o Pravidla Zodpovědnosti Pravidla pro vývoj Jmenné konvence Definice dat Bezpečnostní pravidla Požadavky na kvalitu dat Provozní pravidla o Procesy Plánovací ídící Vývoj Provoz o Technologie Systémy pro správu dat (Databáze) Zálohovací systémy Metadata management systems Systémy pro správu událostí

17 Kategorizace dat o Organizační struktury Vlastníci dat (Data owner) Data Stewardship Data Stewardship Committee BI oddělení Oddělení bezpečnosti Oddělení (datové) kvality Databázoví administrátoři o Kultura organizace o Plán vývoje a údržby IT architektura Datová architektura

18 Information Capability Framework Gartner,

19 Malcolm Chisholm: The 6 Layers of Data

20 Podle struktury o Strukturovaná Data s přesně definovanou strukturou Uložená v databázích (relačních) o Semistrukturovaná Obsahují datové elementy Nemají pevnou strukturu XML, SWIFT, HL7 EDI, SITA message o Nestrukturovaná data Dokumenty Smlouvy Objednávky Předpisy Obsah webů Prezentace

21 DAMA DMBOK Guide

22 Hierarchie moudrosti o Russell Ackoff (1989) Data Informace Pokud jsme schopni odpovědět na otázky kdo?, co?, kde? a kdy? Pochopení vztahů Znalosti Porozumění jak? Pochopení vzorců Moudrost Porozumět proč? Pochopení principů

23 Co si zapamatovat o Co to je data management o Z jakých oblastí se skládá řízení dat o Co to "Information Capability Framework" a které základní schopnosti jsou nutné pro správu a využití dat o Jaké dělení dat v organizaci se používají o Jaký je rozdíl mezi daty, informacemi a znalostmi

24 Diskuse

25 Datová kvalita UAI /14 RNDr. Ondřej Zýka,

26 Datová kvalita o Vlastnost dat, která není daná jejich strukturou nebo uložením o Podstatná vlastnost pro hodnotu dat Malá vypovídací hodnota Chybné výsledky o Může se měnit časem bez zásahu do dat Deset let starý telefonní seznam má malou datovou kvalitu

27 Datová kvalita o Co má vyšší kvalitu, VW Brouk nebo Cadillac? VW má méně závad Cadillac je luxusnější, lépe se řídí VW potřebuje menší prostor na zaparkování Cadillac je pohodlnější, vejde se do něho více zavazadel Brouk má menší spotřebu Různí uživatelé mají různé požadavky. Kvalita je ovlivněna osobním pohledem. Poměrně málo lidí se obtěžuje analýzou publikovaných statistik.

28 Datová kvalita o Kdy jsou data kvalitní? o Kdy jsou data nekvalitní? o Jak prokázat, že jsou data kvalitní? o Dodavatelé dat obecně nemají moc důvodů produkovat bezchybná data. o Nekvalitní data vytváří nesmírnou frustraci uživatelů dat. o Kvalita dat se nedá dosáhnout pouze prostředky IT systémů. adresa@naznama.cz Rodné číslo

29 Jak vyčistit jezero? o 1. přístup Ignorujte znečištění Potrestejte každého, kdo onemocní po užití vody z jezera Přeneste problém na uživatele.

30 Jak vyčistit jezero? o 2. přístup Přefiltrujte vodu Odstraňte nečistoty Vraťte vodu do jezera o 3. přístup Filtrujte malé množství vody každý den Filtrujte přitékající vodu Filtrujte vodu kterou budete používat Jednorázové vyčištění Použití pouze aktuálních dat Nasazení nástrojů

31 Jak vyčistit jezero? o 4. přístup Najděte znečišťovatele Odstraňte je nebo je upravte tak aby neprodukovali znečištění Předcházení budoucích chyb

32 Proč se zabývat datovou kvalitou o Nespokojenost uživatelů o Legislativní požadavky, požadavky regulátorů Solvency II Basel II, Basel III

33 Dimenze datové kvality Dimenze Dostupnost Odpovídající velikost a granularita dat Věrohodnost Úplnost Výstižná reprezentace Konzistentní reprezentace Snadnost zpracování Bezchybnost Interpretovatelnost Objektivita Relevantnost Reputace Bezpečnost Včasnost Srozumitelnost Přidaná hodnota Popis Zda jsou i for a e k dispozi i e o s ad o získatel é Zda velikost dat a jejich granularita odpovídá vyko áva ý úlohá Zda jsou i for a e pokládá y za pravdivé a důvěryhod é Zda žád á data e hy í a zda jsou dostateč é rozsáhlá a detail í pro vyko áva é úlohy Zda repreze ta e dat á vhod ou strukturu Zda jsou data repreze tová a vždy ve stej é for átu Zda jsou i for a e s ad o zpra ovatel é a použitel é pro rozdíl é úlohy Zda jsou i for a e a data přes é a hod ověr é Zda je jas á defi i e i for a í, zda jsou v odpovídají í jazyku, jed otká h a zda jsou oz ače y správ ý i sy oly Zda jsou i for a e estra é a epředpojaté Zda jsou i for a e použitel é a užiteč é pro vyko áva é úlohy Zda jsou i for a e považová y za spolehlivé v souvislosti s jeji h zdroje e o obsahem Zda o eze í přístupu k datů a i for a í odpovídá ezpeč ost í pravidlů Zda jsou pro vyko áva é úlohy i for a e k dispozi i včas Zda jsou i for a e s ad o po hopitel é a srozu itel é Zda a která data a i for a e jsou pří os é a jaké jsou výhody jeji h použití

34 DQ issues Management a Finance Marketing Vlast í i systé ů IT Nutnost udržovat velké finanční ne o technické rezervy Nepřesná seg entace zákazníků Duplicity v datech Vysoká náročnost nalezení požadovaných infor ací Nekonzistentní reporty napříč organizací Drahé a neúčinné ka paně Nekonzistence mezi systé y Ne ožnost dohledání původu dat a zodpovědných pracovníků Reporty s nedůvěryhodný i daty Nízká kvalita služe pro zákazníky Chy ějící ne o nedohledatelné údaje Nespokojenost uživatelů s dodávaný i infor ace i Rozhodnutí učiněná na základě špatných infor ací Nepořádek v zákaznických datech Zastaralé i for a e Neschopnost řešit konzistentně vady v datech

35 Co to je za číslo o Jak vzniklo? o Kdo to kontroloval? o Byla použita všechna data? o Byla použita aktuální data? o?????

36 Požadavky na datovou kvalitu Data Governance Data quality policy Data quality organization Roles Job descriptions Accountability and responsibility assignment Data Quality Processes Data definition Data and data flow description Data Quality Management Data quality indicator definition Data quality measurement and reporting Data quality issue solving Data quality tool operation

37 Popis dat - statický Definice na obchodní úrovni Definice na technické úrovni Místo a formát uložení Vlastník - Zodpovědná osoba Parametry důležitosti, bezpečnosti, aktuálnosti, Prosinec 2012 Solvency II - Zkušenosti z implementace Slide 13

38 Obsah dat - Data Profiling o Technický o Uživatelský o Speciální

39 Data Profiling

40 Popis dat dynamický Zdroje dat Datové úložiště Transformační procesy Zodpovědnosti (vlastnictví dat) Místa předání zodpovědností Ruční zásahy

41 Požadavky na datovou kvalitu Technické Data mají přípustné hodnoty, očekávaný formát, pohybují se v přípustném rozsahu, jsou jednoznačné pokud je to požadováno, existují odpovídající záznamy v jiných systémech Významové Hodnoty, počty a sumy jsou konzistentní v čase. Porovnání s historickými daty a benchmarky nevykazuje neodůvodněné odchylky. Existuje požadovaná konzistence mezi různými záznamy a hodnotami. Požadavek Kontrakt musí mít definován Politiku zajištění Metrika Procento kontraktů s vyplněným parametrem Politika zajištění Tresholds OK > 99% Failed < 95 % Baseline 96,2 %

42 DQ měření a reportování Prosinec 2012 Solvency II - Zkušenosti z implementace Slide 18

43 Solvency II - requirements

44 Datová kvalita o Nečistoty v datech vznikají Při zadání dat Při předávání dat mezi systémy Časem o Závěr Neexistuje jednoduché řešení Nutná spolupráce IT i uživatelů dat Vždy je nutné porovnat cenu řešení a přínos výsledku Je nutné mít popsaná data (existence metadat) Je nutné mít slovník datové kvality Je nutné měřit kvalitu dat

45 Co si zapamatovat o Co to je datová kvalita o Jak se pozná, že jsou data kvalitní o Kdo a jak pozná, že jsou data nekvalitní o Jaké metody se používají pro čištění dat o Kde a jak vzniká nekvalita dat o Co to jsou dimenze datové kvality o Co to je profiling dat o Jak se dá prokázat, že jsou informace získaná z dat kvalitní

46 Diskuse

47 Metadata UAI /14 RNDr. Ondřej Zýka,

48 Co to jsou metadata

49 Chybějící metadata

50 Doplněná metadata

51 Co o metadatech říkají autority Řízení etadata je nepochy ně nejdůležitější z dvanácti schopností, které usí ít BI aplikace

52 Metadata o Metadata jsou data popisující data. Mohou být reprezentovány jednoduchým popisem, ale také složitou strukturou. o Metadata jsou strukturované informace, které nám umožňují najít informace o datech, spravovat je, kontrolovat je a porozumět jim. o Příklady Informace o datových entitách v databázi Informace o jednotlivých záznamech Dokumenty autor, abstrakt, obsah, klíčová slova, dostupnost, platnost, Fotografie místo pořízení, velikost, formát uložení, Informace o datových fragmentech Tagy v XML

53 Business metadata o Jednotný slovník organizace o Komunikace Mezi odděleními Mezi Byznysem a IT ešení výjimek o Požadavky Schvalovací proces Diskuse Více druhů slovníků

54 Technická metadata o Popisy datových modelů Logická úroveň jednotný model organizace Fyzická úroveň modely jednotlivých databází o Popisy reportů Jaká data se používají SQL dotazy Kdo a kdy je používá Popis na byznys úrovni o Popisy transformací Zdroje a cíle Transformační pravidla

55 Zdroje technických metadat o Modelovací nástroje Logické modely Fyzické modely Mapování a transformace o Databáze Fyzické modely Skripty s transformacemi o ETL nástroje Transformace o Reportingové nástroje Zdroje dat Univerzum Transformace a výpočty

56 Sběr a údržba Metadat FAKT: Cíl: Údržba je náročná Sběr a integrace metadat provádět maximálně automaticky o U ruční údržby podpora workflow o Používat nástroje, které nabízejí Dostatečnou svobodu Dostatečnou funkcionalitu Dostatečnou uživatelskou přítulnost

57 Integrace metadat FAKT: V podniku jsou pouze jedna metadata. Cíl: Provázat metadata od definice na business úrovni až k technickým detailům, od zdrojů dat k reportům. o Často existují lokální ostrůvky kompetence Lokální slovníky Lokální popisy vazeb, struktur, závislostí Často špatně technologicky podporováno Integrace na základě ů, excelů a množství jednání

58 Prezentace metadat FAKT: Matadata musí být maximálně veřejná Cíl: Všichni uživatelé musí mít jednoduchý přístup k metadatům. o Rychlá integrace nových pracovníků. o Dokumentační řízení Automatické generování seznamu použitých termínů a zkratek. Speciální pluginy do wordu, excelu. Rozšíření webových prohlížečů.

59 Analýza metadat FAKT: Cíl: Každá nepřesnost výrazně snižuje kvalitu dopadových analýz. Dopadová analýza jako na obrázku:

60 Metadata - analýza o Historie Kdo a kdy naposledy upravil proceduru procedure_name tak, že nepoužívá tabulku table_name? o Data Lineage Upstream Které aplikace používají centrálních číselník měn? Downstream Která všechna data se podílejí na ohodnocení spolehlivosti dodavatele? o Inpact analysis Které všechny tabulky a aplikace se budou muset upravit, když přejdeme z kódování ISOŘŘ5ř2 na kódování UTFŘ? Pokud místo Y/N začneme používat A/N, co všechno musíme zkontrolovat?

61 Metadata - analýza o Lineage analýza o Katalóg Where used analýza

62 Cíle správy metadata? 1. Jak je poje defi ová? 2. Odkud se vzala data? Controllers Auditors 3. Jak jsou data aktuál í? Managers? 1. Co vše usí upravit při z ě ě zdrojového systé u? Analysts Developers Architects 2. Které vše h y reporty usí opravit, když z ě í defi i i sloup e? 3. Co se sta e, když havaruje toto ETL?

63 ízení metadat Byz ys slov ík Datové odely Pro es í odely Orga izač í struktura SAP Oracle Data áze Teradata Definice Aplikace Cognos SaS Busines Objects Oracle BI Reporting Transfor mace ETL Skripty SOA File transfer

64 Nástroje o Byznys slovník Semanta Collibra Informatica Metadata Manager o Informatica Metadata Manager o Oracle Metadata Directory o IBM InfoSphere Metadata Workbench o Adaptive Metadata Manager o InfoLibrarian o Meta Integration o ASG Rochade o SP PowerDesigner

65 Co si zapamatovat o Co to jsou metadata o Co to jsou byznys metadata o Jak se liší byznys metadata od technických metadat o Co jsou zdroje technických metadat o Co to jsou operační metadata o Které čtyři činnosti jsou nutné pro správu metadat o Jaké typy analýz metadat se používají

66 Diskuse

67 Integrace dat UAI /14 RNDr. Ondřej Zýka,

68 Požadavky o Očekává se, že integrace nebude jenom spojením systémů, ale že přinese i přidanou hodnotu. o Změny se provádějí pouze na jednom místě. o Minimalizace ruční práce a přepisování (Cut/past). o Nejenom integrace dat, ale podpora pracovních postupů. o Transformace mezi různými formáty.

69 Požadavky na integrační technologie o Stabilita o Udržovatelnost o Modifikovatelnost o Správa a dohled o Škálovatelnost o Způsob vývoje o Úplnost o Otevřenost o Podpora

70 Stabilita o Změna systému (upgrade, náhrada) nemá vliv na integrační prostředí změna zasáhne pouze malou část prostředí o Zatížení jedné části neovlivní dostupnost a rychlost ostatních propojení Udržovatelnost, modifikovatelnost o Systém je modulární o Úprava komponent neovlivní provoz ostatních částí systému o Je podporováno verzování o Je podporován provoz ve více prostředích (vývojové, testovací, akceptační, provozní) o Je podporována dokumentovatelnost implementace

71 Správa a dohled o Existují nástroje na dohled systému monitor stavu systému řízení systému a jeho komponent sledování procesů v systému sledování dat v systému možnost ručního zásahu do procesů a dat o Uživatelské rozhraní Vlastní GUI Přizpůsobitelné podle uživatelů a rolí Interface na standardní rozhraní (SNMP Simple Network Management Protocol, logger, EventLog, dohledové systém, )

72 Škálovatelnost o Dostatečná propustnost o Více možností jak zvyšovat výkonnost klastrové řešení podpora více úrovní hardware možnost dělení systému (geografické, funkční, doménové, ) o Granularita nastavení bezpečnosti Způsob vývoje o Vývojové nástroje Snadnost nasazení Podpora týmové práce Verzování o Podpora pro analýzu UML - Unified Modeling Language Designery třetích stran o Programovací jazyk Java, C#, VB, C/C++ klikací XML

73 Úplnost o Typy integrace Data integration Replikace ETL Event integration Messagind systems Service integration Webové služby o Transformace Mezi jednotlivými typy integrace Mezi formátem a strukturou předávaných dat o Počet a typy konektorů

74 Konektory JAVA CAPS BizTalk Server SAP ALE SAP BAPI Oracle Applications Siebel EAI PeopleSoft Oracle SQL Server DB2 Universal Database JDBC/ODBC Adapter DB2 Connect Sybase VSAM Informix Lotus Notes/Domino Sun Java System Application Server WebSphere MQ WebLogic Adapter for CICS Adapter for IMS File Adapter Toolkit eways Development Kit egate API Kit WebSphere MQ MSMQ/MSMQT WSE 2.0, HTTP, SMTP, Base EDI, EDIFACT File, FTP, SOAP, POP3 SQL Server 2000 and 2005 SAP SAP R/3 4.X and R/ (Enterprise) PeopleSoft Enterprise , 8.43, and 8.45 J.D. Edwards OneWorld B J.D. Edwards EnterpriseOne 8.1 Oracle Database Oracle Siebel ebusiness Applications Siebel TIBCO Rendezvous TIBCO Enterprise Message Service Enterprise Message Service Host Applications IBM mainframe zseries DB2 Database File systems on IBM mainframe Windows SharePoint Services

75 Otevřenost o Standardy SOA XML SOAP WSDL UDDI BPEL BPMN o Konfigurovatelnost API Administrace Ovládání jádra

76 Integrační přístupy Asynchronní o V jednom okamžiku mají různé systémy různá data o Technologicky jednodušší o Nižší požadavky na průchodnost systému o Messaging Synchronní o Zaručuje konzistentní stav ve všech systémech pro všechny uživatele o Výpadek jednoho systému ovlivňuje všechny ostatní o Dvojfázový commit

77 Integrační přístupy Long-live operation Short-live operation o V rámci transakcí se vyžaduje interakce uživatelů, například schvalování o V řádu hodin a dnů o Businnes workflow aplication o Transakce probíhají tak rychle jak prostředí dovolí o Synchronní i asynchronní transakce o Většinou v řádu sekund o Messaging, ETL

78 Integrační přístupy Federation Mediation o Systém umožňuje (vynucuje) aby požadavky vznikaly jeho prostřednictvím a rozprostírá je do jednotlivých systémů. o MDM aplikace o Reaguje se na změny v jednotlivých systémech a ty se předávají ostatním systémům o Messaging o Replikace

79 Integrační přístupy Point-to-point Hub and spoke model Systém A Systém A Systém B Systém E Systém B Hub systém Systém D Systém C

80 Integrační přístupy Sender Receiver (Queue) Publisher Subscriber (Topic) Subsriber A Sender Receiver Publisher Subscriber B

81 Integrační přístupy Nekoordinovaně budované propojení Použití centrálního registru Systém A Systém B Systém C Systém D Systém A Systém B Systém C Systém D Register - Metadata Úroveň metadat Úroveň technologií

82 Identifikace změny o Indikace změn Timestamp Fronta událostí Technologicky (triggery) Aplikačně o Indikace rozsahu změn Objekt/záznam Položka/atribut, sloupec o Data Identifikace změny Nová data Nová i původní data

83 Insert Nový záznam Neúplný záznam Nekonzistentní záznam Duplicitní záznam Odmítnutí Dočasný zápis Validační proces

84 Update Změna záznamu Porušení konzistence Rozpoznání nezměněné položky Vytvoření duplicity, neúplného záznamu

85 Delete Zrušení záznamu Více typů zrušení záznamu neaktivní dokončený zrušený fyzický delete Logické zrušení (více typů) Fyzické zrušení Rozsah zrušení Vznik nekonzistencí

86 Integrační přístupy o Který systém má pravdu o Proč má pravdu o Jaké jiné hodnoty jsou/byly v některém systému zadány o Kdy a jak se měnily hodnoty, kdo je měnil (který systém)

87 Integrační paterny o Integrace na základě času o Použití datové kvality o Null hodnoty a jejich význam o Opravy a jejich dopad

88 Příklad použití datové kvality Complete user profile Scheduled Scheduled time time DQ DQ Real time Real time DQ DQ Scheduled Scheduled aircraft aircraft type type DQ DQ Real aircraft Real aircraft type type DQ DQ Sep 21 Sep :05PM 9:05PM 8 8 Sep 21 Sep :59PM 8:58PM 6 9 M84 M M83 M Account information history SRC Scheduled time DQ Real time DQ Scheduled aircraft type DQ Real aircraft type DQ SC Sep :05PM M FO Sep :05PM M MD Sep :05PM M AG Sep :05PM 8 Sep :00PM M83 20 RL 99 Sep :00PM SI 99 Sep :58PM 9 99 M83 5 MR 99 Sep :59PM 6 99 M83 6 Zrušení informace v primárním systému

89 Použití Null hodnot Definice Zdroj Kvalita dat Null hodnota Datawarehouse 70 Ne Systém 90 Ne Druhý systém 80 Ano Pří hozí data Zdroj Jméno Výsledek Datawarehouse Systém Druhý systém Pavel Jirka Tomáš?

90 Použití Null hodnot Definice Zdroj Kvalita dat Null hodnota Datawarehouse 70 Ne Systém 90 Ne Druhý systém 80 Ano Pří hozí data Zdroj Jméno Výsledek Datawarehouse Pavel Systém Jirka Jirka Druhý systém Tomáš

91 Použití Null hodnot Definice Zdroj Kvalita dat Null hodnota Datawarehouse 70 Ne Systém 90 Ne Druhý systém 80 Ano Pří hozí data Zdroj Jméno Výsledek Datawarehouse Pavel Systém Tomáš Druhý systém Tomáš

92 Použití Null hodnot Definice Zdroj Kvalita dat Null hodnota Datawarehouse 70 Ne Systém 90 Ne Druhý systém 80 Ano Pří hozí data Zdroj Jméno Výsledek Datawarehouse Pavel Systém Druhý systém

93 Master Data Management o Správa klientů PARTY Role a vazby (Hausholding, ekonomicky spjaté subjekty, externí informace, scoring, ) o Správa produktů Dodavatelé, Obchodní proces, Design, Marketing, Nacenění, Partneři, Interní systémy, Náklady, Reporting, Konsolidace produktů o Správa centrálních číselníků Historizace, plánování, různé verze pravdy, propagace do systémů o Master Reference Data o Master Systém of Records o Master Registry o Synchronizace

94 Master Reference Data Zdroj A Datová integrace Auto ati ké dávkové e o realti e zpra ová í. Čiště í, i tegra e, Sta dardiza e, Zdroj B Data Warehouse Exceptions Zdroj C Správa výjimek

95 Master System of Record Zdroj A Datová integrace Auto ati ké dávkové e o realti e zpra ová í. Čiště í, i tegra e, Sta dardiza e, Zdroj B Master Databáze Zdroj C Správa výjimek Nové aplikace

96 Master Registry Datová integrace Auto ati ké dávkové e o realti e zpra ová í. Čiště í, i tegra e, Sta dardiza e, Zdroj A Zdroj B Zdroj C Registr vazeb Správa výjimek Nové aplikace

97 Synchronization Zdroj A Datová integrace Auto ati ké dávkové e o realti e zpra ová í. Čiště í, i tegra e, Sta dardiza e, Zdroj B Zdroj C Správa výjimek

98 Integrace o Integrací vzniká nová kvalita. o Nutno uvažovat s požadavky na dozor s nutností komunikace se správci jednotlivých systémů údržbu systému vytvoření adekvátní organizační struktury o Zásah do libovolného systému je zásah se může projevit jako závažný problém v ostatních systémech.

99 Integrace Testování o Testování je složité až nemožné o Míchání různých testovacích prostředí o Zapojení testerů všech systémů do testování Etapa nasazení o Nemožnost paralelního běhu o Připravenost na výskyt neočekávaných stavů nepředpokládané interakce smyčky v přenosu vzájemné ovlivňování systémů změna chování uživatelů

100 Rizika integračních projektů o Bezpečnost ztráta informací neautorizované modifikace právní odpovědnost pravdivost informací původ informací krádež služeb ztráta důvěry zákazníků příležitost pro fraud

101 Co si zapamatovat o Jaké jsou nejdůležitější požadavky na integrační technologie o Jaký je rozdíl mezi synchronním a asynchronním předáváním dat o Jaký je rozdílel mezi Federativním a Mediativním přístupem k integraci dat o Jaký je rozdíl mezi Point-to-point a Hub-and-spoke integračním modelem o Jaký je rozdíl mezi Send-Reciever a Publisher-Subsciber integračním modelem o Jaké techniky se používají při indikaci dat, které je nutno přenášet v rámci integrace o Jaké jsou hlavní problémy při vzniku nového záznamu v integračním systému o Jaké jsou hlavní problémy při změně záznamu v integračním systému o Jaké jsou hlavní problémy při zrušení záznamu v integračním systému o Jak se používá datová kvalita při integraci dat z více systémů o Co to je Master Data Management (MDM) o Jaké architektury MDM se používají o Jaká jsou hlavní rizika integračních projektů

102 Diskuse

103 Úvod do BI UAI /14 RNDr. Ondřej Zýka,

104 Co to je BI o Schopnost shromažďovat, třídit a organizovat svoje znalosti. o Využití vlastních dat a informace pro efektivní podporu byznys aktivit. o Soubor prostředků sloužící k jednotnému pohledu na informace v rámci celého podniku, jejich analýze a vyhodnocení.

105 Co obsahuje BI (Gartner) o Integration BI infrastructure Metadata management Development tools Collaboration Data quality o Information delivery Reporting Dashboards Ad hoc query Microsoft Office integration Mobile BI o Analysis Online analytical processing (OLAP) Interactive visualization Predictive modeling and data mining Scorecards

106 Integrace o BI infrastructure Security Metadata Administration Portal integration Object model Data storage and Query engines o Metadata management Collect Shared Search Analyze Business, technical and operation metadata Dimensions, hierarchies, measures, performance metrics Full data-lineage o o Development tools Programmatic development tools Visual development environment Scheduling Delivering Administering and managing Change management support Workflow tool o Collaboration Share and discuss information BI content and results Manage hierarchies and metrics Analytical master data management (MDM). o Data quality Definition of user requirements Data assessment tools Business rule engines Data quality measuring and reporting Information delivery

107 Information Delivery o Reporting Parameterized reports Distribution and scheduling capabilities Wide array of reporting styles o Dashboards Web-based or mobile reports with intuitive displays of information Performance metric compared with a goal or target value. Real time data usage o Ad hoc query Ask their own questions of the data Query governance Auditing capabilities Performance help o Microsoft Office integration Excel as client Includes cell locking and writeback o Mobile BI Mobile devices Publishing or bidirectional mode

108 Analysis o Online analytical processing (OLAP) Analyze data with extremely fast query and calculation performance, "slicing and dicing" style of analysis Multidimensional navigation and drill down capability. o Interactive visualization Efficiently displayed numerous aspects of the data, Interactive pictures and charts, instead of rows and columns. o Predictive modeling and data mining Classify categorical variables Estimate continuous variables using advanced mathematical techniques Structured and unstructured data search Leveraging the BI semantic layer o Scorecards Strategy map that aligns (KPIs) with a strategic objective Scorecard metrics linked to related reports Six Sigma or a balanced scorecard framework

109 Požadavky na BI o Velké objemy dat o Rychlost zpracování o Data dodávaná v dávkách o Uživatelské zásahy o Stabilní kompletní historie o Opravy a rekonciliace dat o Složité algoritmy zpracování o Více pohledů na stejná data

110 Technologická omezení o Průchodnost sítí ETL, dávkové zpracování o Rychlost přístupu na diskové prostory in memory databáze, read only databáze, specializovaná úložiště o Zpracování dat vyžaduje průchod pamětí a procesorem in-memory databáze, secializovaná úložiště (column store datace), předpočítané data (OLAP)

111 Architektura

112 Zákazníci a uživatelé ODS Operační data MDM Datová kvalita Integra ce DWH Jednotný odel Ko pletní historie Integrovaná data Byznys, technologická a provozní etadata Governance pravidla, organizační struktura, procesy

113 Architektura DWH Stage O raz vstupních dat Záloha dat pro zpracování Datová kvalita Jádro Jednotný odel Ko pletní historie Data Marty Podle analyzovaných procesů Dimenze a metriky Agregovaná data Scheduler a dohled

114

115 Co si zapamatovat o Různé definice BI o Co všechno obsahuje BI řešení o Jaké jsou osvědčené architektonické principy v BI o Jaké jsou kritické omezující podmínky BO řešení v současnosti

116 Diskuse

117 BI prostředí UAI /14 RNDr. Ondřej Zýka,

118 Terminologie o DWH Další systém v podniku Jenom databáze s důležitými daty o BI IT obor Kompetence podniku využívat data a informace Podnikové oddělení DWH je součástí infrastruktury BI prosředí

119 Dimenze BI prostředí o Business value informace dodávané koncovým uživatelům o Technology Použité technologie, algoritmy a metody o BI maturity Kompetence, organizační struktura a schopnosti nutné pro rozvoj a provoz BI prostředí a DWH

120

121 Business value o Od jednodušších reportů po složitější o I jednoduché reporty jsou uživatelé schopni ocenit o Definice pokročilých reportů až na základě seznámení uživatelů s daty o Nejdříve reporty vyžadující data z malé množiny zdrojových systémů o Výstupy na základě potřeby a schopností uživatelů nikoliv na základě možnosti nástrojů nebo dostupnosti dat

122

123 Technology o Pro dodávku výsledků je potřebný celý technologický řetězec o Výběr hlavních technologií je nutné udělat na začátku Migrace mezi technologiemi není zpravidla možná Náhrada technologie vede zpravidla k celému novému řešení o Nutná strategie pro rozvoj prostředí tak, aby náklady na technologie mohly být rozprostřeny v čase Schopnost rozšíření systému Platba podle výkonu Finanční produkty dodavatelů technologií o Postupné vytváření vývojového, testovacího a produkčního prostředí

124

125

126 BICC Business Intelligence Competency Center o Zodpovědnosti Detailní popis entit Jednotné agregace přes celý podnik Jednotné použití termínů Konzistentní reprezentace čísel (význam revenue, slev, apod.) Odstranění rozdílů daných jazykem, lokací, měnou, aplikací, apod. Jednotný způsob řešení bezpečnosti (auditing compliance, autorizace, spod.) Koordinace se standardy (ACORD, SWIFT) Konformní dimenze přes celý podnik

127 Data steward o Komunikuje s business uživateli, zná jejich požadavky. o Rozumí business požadavkům a tomu jak data tyto požadavky podporují. o Zná důkladně strukturu datového skladu a dokáže analyzovat data ve skaldu přímo. o Interpretuje nové business požadavky a jejich dopad na DWH, navrhuje rozšíření datového skladu. o Zajišťuje plnění požadavků regulátorů. Ověřuje kvalitu, přesnost a důvěryhodnost dat. Určuje pravidla ověřující každý load. Je zodpovědný, že při výskytu závažných chyb se data nedostanou k uživatelům a komunikuje tuto událost vedení. o Vytváří a provádí verifikační proces, že data odpovídají požadavkům regulátorů. o Spravuje a vytváří metadata jak o datech, tak o transformacích.

128 BICC procesní oblasti o ízení strategie o Porozumění BI komunitě o ízení požadavků o ízení architektury o ízení vývoje o ízení provozu o ízení rozpočtu a získávání zdrojů o Definování metrik o Nástroje

129 BICC Nástroje o Byznys slovník o Datový slovník o Katalog BI služeb o Katalog BI požadavků o Incident management tool o Katalog reportů o Katalog uživatelů

130 Příklad struktura BI portálu o Novinky o Základní informace o portálu o Status BI o BICC O nás vize a mise Kontakty, napište nám Interní BI specialisti o Projekty Probíhající projekty Dokončené projekty Plánované projekty o Služby Podpora uživatelů Katalog služeb Požadavky Helpdesk o Knowledge base Best practices Byznys slovník Metodiky elerning Datové zdroje Katalog reportů Datový slovník o Kalendář akcí Školení Prezentace Workshopy

131 Příklad definice procesů Incident Management Problem Management Help Desk Change Management Requirement Management IM100 Založení a pre-analýza incidentu PM100 Založení a pre-analýza problému HD100 Založení a pre-analýza požadavku CH100 Založení a pre-analýza RFC RM100 Založení a pre-analýza požadavku IM200 Klasifikace a kategorizace incidentu IM300 Analýza, diagnostika incidentu IM500 ešení a obnova PM200 Klasifikace a kategorizace problému PM300 Analýza, diagnostika problému PM500 ešení problému HD200 Klasifikace a kategorizace požadavku HD500 ešení požadavku Support, Maintanace CH200 Klasifikace RFC CH300 Autorizace a nastavení termínu změny CH500 ešení RFC (Support, Maintanace) Project, Small Enhancement RM200 Klasifikace, analýza, ohodnocení pracnosti, rizik CH550 Kompletace a finální testování CH600 Nasazení RFC IM700 Ověření řešení PM700 Ověření řešení HD700 Ověření řešení majitelem procesu IM800 Schválení zadavatelem HD800 Schválení zadavatelem CH800 Schválení zadavatelem RM800 Schválení k Implementaci IM900 Uzavření incidentu PM900 Uzavření problému HD900 Vyhodnocení ticketu CH900 Vyhodnocení a uzavření RFC RM900 Uzavření požadavku

132 Příklad - SLA parametry BI služby Služba Garantovaný přístup Omezený přístup Údržba Standardní reporty Po - Pá 09:00-17:00 Po,Út,St,Pá 00:00-09:00 Čt 00:00-08:00 Po - Pá 17:00-22:00 So 12:00-24:00 Ne 00:00-24:00 Po - Pá 22:00-24:00 Čt 08:00-09:00 So 00:00-12:00 Standardní dostupnost Rozložení výpadků 95% Průběžná nedostupnost <= 5%, tzn. 8 hodin/měsíc při předpokladu režimu garantovaného přístupu 8x5 v pracovních dnech (pro kalkulaci se počítá, že měsíc má 20 dní) poskytování služby v měsíci Jednorázová nedostupnost <= 3 dny - Jednorázovou nedostupností se míní celková délka trvání jednoho výpadku. Jednorázová nedostupnost převyšující parametr Průběžná nedostupnost může nastat maximálně v jednom případě v rámci kalendářního roku bez porušení SLA Plánovaná nedostupnost Plánovaná údržba bude prováděna v době vymezené obdobím Omezený přístup nebo Údržba. Každou plánovanou údržbu mimo vymezené období Omezeného přístupu nebo Údržby je poskytovatel povinen uživateli oznámit alespoň 3 kalendářní dny předem. Služba - varianta Počet přístupů Odezva přístupu Statické předgenerované reporty přístupů za den 50% přístupů do 10s 90% přístupů do 20s Parametrizovatelné spouštěné reporty Analytické reporty (analytické prostředí) přístupů za den N/A přístupů za den 50% přístupů do 20s 90% přístupů do 40s Drill-down OLAP kostkou o jednu úroveň - 95% do 45s

133 Příklad Incident management tool

134 Gartner BI summit

135

136

137

138

139 Co si zapamatovat o Vztah mezi BI a DWH o Jaké jsou dimenze BI prostředí o Co to je BICC a jaké má funkce o K čemu slouží role Data Steward o Jaké jsou základní procesy spojené s BI prostředím o Jak se dá ohodnotit vyspělost BI prostředí

140 Diskuse

141 Architektura DWH UAI /14 RNDr. Ondřej Zýka,

142 o Bill Inmon: Datový sklad je subjektově orientovaný, integrovaný, stabilní a časově udržovaný soubor dat pro podporu managerských rozhodnutí (W.H.Inmon: Building the Data Warehouse. Second Edition, John Wiley & Sons, Inc., 1996)

143 Pravidla datového skladu # Popis 1 DWH je odděle od pri ár í h systé ů 2 Data v datové skaldu jsou i tegrova á 3 DWH o sahuje histori ká data za dlouhý časový úsek. 4 DWH obsahuje snapshoty k přes ě defi ova ý oka žiků. 5 Data v DWH jsou su jektově ikoliv age dově orie tova á. 6 DWH data jsou urče a pri ár ě ke čte í. ) ě y dat jsou je o dávkové a pri ár ě se jed á o i sert dat. 7 Život í yklus DWH je říze daty (nikoliv procesy). 8 DWH o sahuje ví e úrov í granularity dat. 9 DWH očekává álo select opera í ad velký i o je y dat. 10 DWH obsahuje systé pro vyhledává í zdrojů, tra sfor a í a ísta ulože í dat. 11 Metadata DWH o sahují popis vše h datový h prvků, zdroje, tra sfor a e, i tegra e, ulože í, vaz y a historii vše h datový h ele e tů. 12 DWH u ožňuje přidělovat a zpoplatňovat využití svý h zdrojů jed otlivý i uživateli.

144 Zákazní i a uživatelé ODS Operační data MDM Datová kvalita Integra ce DWH Jednotný odel Ko pletní historie Integrovaná data Byznys, te hnologi ká a provozní etadata Governance pravidla, organizační struktura, pro esy

145 DWH subjektově orientovaný pohled na data OLTP systémy Datový sklad Povinné ručení Zákazník/ Smlouva Životní pojištění Likvidace Zdravotní pojištění Platby a finance Neživotní pojištění Zajištění Aplikace Subjekty

146 Proč budujeme datový sklad Strategické cíle - Top Mgmt. Výnosy ROE Náklady Rizika o Byznys strategie podniku Taktické & operativní cíle - Middle Mgmt. Akvizice klientů Retence klientů Výnosnost na klienta... Automatizace procesů ízení nákladů Efektivita práce OPEX Inteligentní marketing Produktový vývoj Detekce odlivu zákazníků Křížový prodej Detekce podvodů ízení rizik Výkonově řízený komp. systém Finanční řízení Zdroje růstu Scoring & Rating Segmentace Channel Management METRIKY X-Sell probability Customer Lifetime Value Customer Leave Probability Profitability produktu Wallet Share Profitabilita zákazníka Housholding Profitability kanálu Segmentace Delikvence zákazníka Informace/Metriky BI STATISTIKY Statistiky prodejů Statistiky zákazníků Efektivita kampaně Efektivita obchodního procesu... DATA DATA - interní / externí

147 Vazba strategie a architektury v podniku Byznys strategie IT strategie Enterprise architektura Byznys architektura Aplikač í ar hitektura Datová ar hitektura Te h ologi ká architektura IT architektura

148 Proč budujeme datový sklad? ROE Return Of Equity Mise: ROE / Profit ++ Hodnota společnosti + Podíl na trhu + Nová teritoria Strategické cíle - Top Mgmt. Výnosy ROE Rizika Náklady Situace: rychle se ě í í trh lo argin business zákaz ík: dlouhodo ý vztah zákaz íků: konkurence, mzdy,... Strategické cíle - Top Mgmt. Výnosy Taktické & operativní cíle - Middle Mgmt. Akvizice Retence Výnosnost... klientů klientů na klienta Detekce Inteligentní Produktový Křížový odlivu marketing vývoj prodej zákazníků Scoring & Rating Segmentace Zdroje růstu METRIKY X-Sell probability Customer Lifetime Value Customer Leave Probability Profitability produktu Wallet Share Profitabilita zákazníka Housholding Profitability kanálu Segmentace Delikvence zákazníka Informace/Metriky BI ROE Náklady Rizika Automatizace ízení Efektivita OPEX práce procesů nákladů Výkonově Detekce Finanční ízení rizik řízený komp. podvodů řízení systém Channel Management STATISTIKY Statistiky prodejů Statistiky zákazníků Efektivita kampaně Efektivita obchodního procesu... DATA DATA - interní / externí

149 Proč budujeme datový sklad? Mise: Přilákat nové zákazníky Udržet stávající zákazníky Zvýšit výnosy ze stávajících zákazníků Strategické cíle - Top Mgmt. Výnosy Situace: trh je rozděle a saturová e istuje odliv zákaz íků áklady a ového zákaz íka Taktické & operativní cíle - Middle Mgmt. Akvizice klientů Retence klientů Výnosnost na klienta... Strategické cíle - Top Mgmt. Výnosy Taktické & operativní cíle - Middle Mgmt. Akvizice klientů Retence klientů Výnosnost na klienta... ROE Rizika Automatizace procesů Náklady ízení Efektivita nákladů práce OPEX Inteligentní marketing Produktový vývoj Detekce odlivu zákazníků Křížový prodej Detekce podvodů ízení rizik Výkonově řízený komp. systém Finanční řízení Scoring & Rating Segmentace Channel Management Zdroje růstu METRIKY X-Sell probability Customer Lifetime Value Customer Leave Probability Profitability produktu Wallet Share Profitabilita zákazníka Housholding Profitability kanálu Segmentace Delikvence zákazníka STATISTIKY Statistiky prodejů Statistiky zákazníků Efektivita kampaně Efektivita obchodního procesu... Informace/Metriky BI DATA DATA - interní / externí

150 Proč budujeme datový sklad? Úlohy: Aplikovat křížový prodej Zkrátit TTM Zefektivnit marketing Snížit odliv zákazníků... Taktické & operativní cíle - Middle Mgmt. Akvizice klientů Retence klientů Výnosnost na klienta Situace: neznámá zák. struktura neexistují Inteligentní marketing Zdroje růstu Produktový vývoj Scoring & Rating Detekce odlivu zákazníků Segmentace Křížový prodej Strategické cíle - Top Mgmt. Výnosy Taktické & operativní cíle - Middle Mgmt. Akvizice klientů Retence klientů Výnosnost na klienta ROE Channel Rizika Management... Automatizace procesů ízení nákladů Náklady Efektivita práce OPEX Inteligentní marketing Produktový vývoj Detekce odlivu zákazníků Křížový prodej Detekce podvodů ízení rizik Výkonově řízený komp. systém Finanční řízení Scoring & Rating Segmentace Channel Management Zdroje růstu METRIKY X-Sell probability Customer Lifetime Value Customer Leave Probability Profitability produktu Wallet Share Profitabilita zákazníka Housholding Profitability kanálu Segmentace Delikvence zákazníka STATISTIKY Statistiky prodejů Statistiky zákazníků Efektivita kampaně Efektivita obchodního procesu... Informace/Metriky BI DATA DATA - interní / externí

151 Proč budujeme datový sklad o Nejsou důležitá samotná data, ale informace v datech obsažená o Požadavky na uložení dat v datovém skladu: Data musí mít dostatečnou kvalitu a obsah, aby byla použitelná pro reporting i analýzy Data musí mít dostupná dostatečně rychle Data se nesmí dostat do nepovolaných rukou Náklady na uložení dat v datovém skladu se musí pohybovat v rozumných mezích Uložení dat musí být flexibilní, aby umožnilo realizaci budoucích požadavků.

152 Zákazní i a uživatelé ODS Operační data MDM Datová kvalita Integra ce DWH Jednotný odel Ko pletní historie Integrovaná data Byznys, te hnologi ká a provozní etadata Governance pravidla, organizační struktura, pro esy

153 OLTP x DWH OLTP systé y Aplikač ě orie tova á Detail í data Přes é hod oty, výz a v do ě zpra ová í Slouží provoz í pra ov íků M oho z ě update Opakují í se zpra ová í Přede z á y a defi ová y požadavky a data a procesy Sta dard í vývojový yklus aplika e Přístup k jed otlivý záz a u Orientace na transakce Datový sklad Před ět ě orie tova á Agragova á e o vypočítáva í data Historie, data za o do í, snapshoty Slouží a ažerů )az a e ává se historie, update je ový záz a Časté ad-ho a alýzy Větši a požadavků e í přede z á a Požadova ý agil í vývojový yklus Přístup k velké oži ě záz a ů ajed ou Orie ta e a a alýzu

154 OLTP x DWH OLTP systé y Výko ost je e tré ě důležitá pro provoz organizace Práva vlast íků dat a z ě u jsou důležitá Požadová a vysoká dostup ost Spravuje se jako celek Redu da e dat je ežádou í or alizova é odely Stati ká struktura, varia il í o sah Malé o je y dat Orientace a každode í ruti u Datový sklad Vol ější ároky a výko ost de í zpra ová í ) ě a je provádě a te h ologi ký i uživateli Nižší požadavky a dostup ost Spravuje se po logi ký h částe h Redu da e je ěž á de or alizova é modely) Fle i il í struktura Velké o je y dat Orie ta e a a alýzy a plá ová í

155 ODS x DWH ODS I tegrova á data Pře íra á data Orientace po oblastech Bez historie Z ě y v date h Bez agregace Tra sakč í load dat I for ač í zdroj o záz a e h O ous ěr á ko u ika e DWH I tegrova á data Vyčiště á data Orientace po oblastech Ko plet í historie Bez z ě Agregova á data Dávkový load dat A alyti ké aplika e Jed os ěr á komunikace

156 Uživatelé systémů OLTP ODS DWH Provoz í pra ov í i Střed í a age e t Provoz í pra ov í i Klienti Part eři Střed í a age e t Vr hol ý management

157 Vývoj složitosti DWH Big Data A alyti ké aplikace A alyti ké aplikace Data mining Data mining Data mining Multidimenzi o ál í a alýza Multidimenzi o ál í a alýza Multidimenzi o ál í a alýza Multidimenzi o ál í a alýza MIS MIS MIS MIS MIS Dotazy, Reporty, Dotazy, Reporty, Dotazy, Reporty, Dotazy, Reporty, Dotazy, Reporty, Dotazy, Reporty,

158 Architektura DWH Stage Obraz vstupní h dat Záloha dat pro zpra ování Datová kvalita Jádro Jednotný odel Ko pletní historie Data Marty Podle analyzovaný h pro esů Dimenze a metriky Agregovaná data Scheduler a dohled

159 Architektura o Modely o ETL o Reporting o Technologie o Partitioning o Bitmap indexy o Materializované view o Komprimované tabulky o Paralelismus o OLAP

160 Jádro DWH o Logický datový model organizace o Specializovaný na doménu organizace o Nezávislý na implementaci jednotlivých transakčních systémů o Podporuje byznys cíle organizace o Logické doménové modely Teradata FSLDM Logický datový model IBM FSDM Orientace na procesy a služby Oracle SAS další

161 Logický datový model organizace o Konceptuální pohled na strukturu dat o Nejen pro datový sklad ale i pro integraci dat mezi systémy o Definice entit a vztahů, jejich použití Vazba na procesy a služby o Základní atributy jednotlivých entit o Doporučené struktury entit o Doporučené struktury atributů o Logické modely pro jednotlivé subjekty o Návrhy data martů pro řešení specifických úloh

162 Příklad konceptuální model FSLDM

163 Příklad struktura FSDM

164 Příklad logický model oblasti

165 Příklad doporučená struktura

166 FSDM připravené oblasti Asset & Liability Management Capital Allocation Analysis Capital Procurment Equity Position Exposure Financial Management Accounting Funds Maturity Analysis Net Interest Margin Variance Structured Finance Analysis Financial Market Transaction Analysis Positions Analysis VWAP Analysis

167 FSDM připravené oblasti Regulatory Compliance Balance Sheet Classifi ed Approach Balance Sheet Order of Liquidity Approach Balance Sheet Net Assets Approach Balance Sheet Portfolio Basis Approach Cash Flow Direct Analysis Cash Flow Direct FI Analysis Cash Flow Indirect Analysis Cash Flow Indirect FI Analysis Income Statement by Function Analysis Income Statement by Nature Analysis Income Statement FI Approach Statement of Charges in Equity Analysis Sarbanes Oxley Act Analysis Sarbanes Oxley Act Balance Sheet Analysis Sarbanes Oxley Act Cash Flow Analysis Sarebanes Oxley Act Statement of Change in Shareholders Equity Analysis Sarbanes Oxley Act Statement of Income Analysis ECB Reporting Financial Capital Adequacy Analysis Structure of Regulatory Capital Best Execution Analysis

168 FSDM připravené oblasti Risk Credit Risk Assessment Credit Risk Mitigation Assessment Operational Risk Assessment Operational Risk Loss Analysis Value at Risk Analysis

169 Stage o Obraz dat z primárních systémů o Historizace dat z primárních systémů pro opakované zpracování o Integrace dat, tabulky klíčů o Převod dat do modelu jádra o Čištění dat, sledování datové kvality o Přidělování a nahrazování klíčů

170 Stage o Staging area je ve vlastnictví ETL týmu Žádný reporting, dotazy běžných uživatelů, žádná SLA Struktura staging area se může měnit bez vědomí koncových uživatelů Data zapisují a čtou pouze ETL procesy. o Fyzická realizace Databázové tabulky Soubory (flat files)

171 Stage o Horizontální zpracování Data se zpracovávají po systémech Integrace se provádí denně vícekrát Více systémů může najednou měnit stejnou oblast nutnost synchronizace Data se zpracovávají ihned po uvolnění primárním systémem o Vertikální zpracování Data se zpracovávají po oblastech Nutno čekat na všechny systémy krátké časové okno pro zpracování Jednodušší správa integrity v rámci celého podniku Není možné použít při nestejných priodáchpřenosu dat o Nahrávání opožděných dat o Odstranění denního loadu

172 Vybíráme data pro DWH o Možné přístupy: Syntéza zdola Projít data stávajících provozních systémů, a určit data, která jsou užitečná pro organizaci jako celek. Určit překryv dat z provozních systémů Analýza shora Mám vydefinovány reporty Potřebuji určit, kde a jak získat data do těchto reportů o Určení System of Record Vyjasnění si, jaká data do DWH chci Určení, zda a z jakých zdrojových systémů jsem schopen tato data získat Určení, kde se potřebná data ve zdrojovém systému nachází o Datový model datového skladu o Určení granularity dat

173 Nahrávání dat z primárních systémů o Zdroj dat Extrakty Pohledy do tabulek Připravená View Logy změn v primárních systémech Replikace dat Webové služby o Velikost extraktů Full extrakty Přírůstková data

174 Nahrávání dat z primárních systémů o Četnost nahrávání Denní load Ad-hoc load Hodinové intervaly Near-to-online dávky o Dostupnost zdrojových systémů Určení časového okna pro provedení loadu časování loadu DWH Událostmi řízené ukončení denního zpracování Existence extraktů na určeném místě

175 Nahrávání dat ze zdrojových systémů

176 Nahrávání dat ze zdrojových systémů

177 Stage o Persistentní ukládání mezivýsledků jednotlivých fází o Výhody: Zotavení z chyb: Ukládání ihned po extrakci ze zdrojového systému Ukládání mezivýsledků ihned po zásadní či složitější transformaci Záloha Audit Uložená data získaná ze zdrojových systémů mohou být použita k opravnému loadu. Lze snáze dohledat, ve které fázi loadu došlo ke vzniku chyby Lze zjistit, zdali problémová data nepřišla již ze zdrojového systému

178 ETL o EXTRACT Načtení relevantních dat ze zdrojového systému o TRANSFORM Transformace dat do podoby používané v DWH Vytvoření umělých klíčů Historizace Čištění dat o LOAD Načtení dat do DWH

179 ETL nebo ELT? o Extract Transform Load o Extract Load Transform Extrahovat data do DWH Provádět transformace v DWH

180 ETL nástroje o Snadný návrh o Dokumentace transformací o Znuvupoužitelnost objektů o Template pro standardní úlohy o Schopnost napojení na mnoho typů zdrojů o Technologická nezávislost o Schopnost zvládnout veliké objemy dat (stovky GB) o Dohled a řízení běhu transformací o Shromažďování operačních metadat o Konkurence Psaní skriptů (PL/SQL, BTEQ, Perl, shell, )

181 ETL nástroje o ETL transformační run-time Větší flexibilita Rozložení zátěže o Generátory kódu Zatížení databáze Možnost optimalizace na úrovni databáze Využití specifik konkrétního systému

182 Použití ETL o Přenos dat z primárních systémů o Transformace v Stage o Úprava dat v jádře datového skladu o Vytváření data martů

183 Příklad návrh ETL- BizzTalk

184 Příklad grafické rozhraní Informatica

185 Příklad návrh řízení zpracování

186 Příklad dohled zpracování

187 Příklad fáze loadu Data Staging Area Operational Sources IMS Step 1 Step 2 Step 3 Step 4 Step 5 Step 6 Step 7 Step 8 Step 9 Capture * Logs * Extracts * Backups Pre F.1 * Fixed Lt * Variable * SEQ Filter * Select Intel. Merge * Merge N to N Maps Delta * Detect delta records Clean & Transf * Ensure data can be loaded * Convert * Change Build * Build DW rows Apply * Load * SQL Backup * Load files * Recovery Data Warehouse DB2 DBMS Sybase SEQ Oracle

188 Příklad fáze loadu o 1. Načtení dat, zapsání do historických tabulek D-1, D-2, Technologické rozdíly kódování (Mainframe EBCDIC) soubory, zdroje, umístění COBOL files, as400 XML files SAP konektor o 2. Preformat Standardizace datových typů Rozdělení různých záznamů do rozdílných souborů Ověření data quality odmítnutí vstupů

189 Příklad fáze loadu o 3. Filtrace Odstranění záznam, které nepatří do datového skladu o 4. Merge Spojení souborů tak aby se s nimi lépe pracovalo Denormalizace N:N mapování Integrace atributů z rozdílných zdrojů pro jednotlivé záznamy o 5. Delta detection Identifikace nových, změněných nebo zrušených záznamů podle zdrojových dat

190 Příklad fáze loadu o 6. Transformace do datových typů datového skladu ízení null Převod kódů na texty Rušení nepotřebých atributů o 7. Převod dat do modelu datového skladu Převod klíčů a generování nových o 8. Load do jádra datového skladu Historizace Vytvoření dimenzí o ř. Záloha denního zpracování

191 Přidělování klíčů o Klíč v primárním systému o Klíč v datovém skladu Unifikace ešení cizích klíčů o Globální klíč v organizaci (MDM) GID o GID není většinou klíč v datovém skladu o Pravidla pro přidělování klíče o Jmenné pravidla pro modely o Tabulky klíčů pro integraci

192 Co si zapamatovat o Proč budujeme datový sklad o Jaké jsou hlavní pravidla pro budování datového skladu o Jaká je vazba DWH na strategii strukturu organizace o Čim se liší DWH od OLTP systémů o K čemu slouží stage, jádro a marty v DWH o Co to jsou ETL nástroje o Jaké jsou hlavní činnosti při akvizici dat do datového skladu

193 Diskuse

194 Databázové patterny UAI /14 RNDr. Ondřej Zýka,

195 Obsah o Co je databázový pattern o Pattern: Přiřazení rolí o Pattern: Klasifikace

196 Databázové patterny o Odzkoušené a doporučené způsoby, jak řešit často se vyskytující požadavky o N-ární relace o Dědičnost o Přiřazení rolí o Klasifikace

197 Úrovně patternů o Stejný typ požadavků může být řešen v databázi mnoha způsoby o Jednoduše I při drobné změně požadavku je nutný zásah do databáze, Lehce srozumitelné uživatelům, analytikům, vývojářům. o Složitě Hodně změn se dá vyřešit pouze změnou dat. Komplikované datové struktury, uživatelsky nesrozumitelné. Vždy je nutné mít jednoduché uživatelské rozhraní. Koncový uživatel nesmí být zatěžován implementační složitostí.

198 Pattern: Přiřazení rolí o Definice Partneři kooperující s podnikem Podnik - zákazník, dodavatel, partner, zaměstnanec, Škola student, zaměstnanec, spolupracovník, přednášející,

199 Pattern: Přiřazení rolí I CUSTOMER ID ORGANIZATION/FIRST/LAST NAME CREDIT LIMIT 100 Moje data s.r.o CZK 101 Tvoje Data s.r.o. null SUPPLIER ID ORGANIZATION NAME TAXATION IDENTIFIER 369 Moje data s.r.o Vaše Data s.r.o PARTNER ID ORGANIZATION/FIRST/LAST NAME PARTNER TYPE 1001 Moje data s.r.o. 10 (Global partner) 1002 Tvoje Data s.r.o. 20 (Software testing)

200 Pattern: Přiřazení rolí I o Nejjednodušší řešení - každá role jiná entitu o Vlastnosti Jasně definované role Atributy jsou společné (Jméno) a specifické (EMPLOYEE NUMBER) Jedna organizace nebo člověk může mít více rolí Některé role mohou zastávat pouze organizace (SUPPLIER), některé pouze lidé (EMPLOYEE), některé jak lidé, tak organizace

201 Pattern: Přiřazení rolí I o Slabé stránky Není vhodný pro prostředí, kde často vznikají a zanikají role nebo kde se mění atributy rolí; Stejná informace je uložena na více místech (Jak řešit změnu adresy firmy Vaše Data); Těžko se skládá celkový obrázek o vazbách s ostatními subjekty; Není jasné, jak jednoznačně identifikovat subjekt.

202 Pattern: Přiřazení rolí II

203 Pattern: Přiřazení rolí II o Složitější řešení (umožňuje) odstranění redundance informací o osobách a organizacích. o Vlastnosti Role může být vázána na PARTY, nebo jenom na podtyp ORGANIZATION; Jednotlivé role jsou samostatné entity.

204 Pattern: Přiřazení rolí II o Vlastnosti Umožňuje jednoduše vázat další entity (faktura, objednávka) přímo na PARTY, není potřeba rozlišovat, zda se jedná o osobu nebo organizaci. Umožňuje jednoduše přidávat další role existujícím PARTY. Umožňuje, aby jedna PARTY vystupovala ve více rolích.

205 Pattern: Přiřazení rolí II o Slabé stránky V některých prostředí nejsou schopni rozlišit PARTY od rolí. Pattern naznačuje, že PARTY vystupuje v roli pouze jednou. Přidávání rolí vyžaduje přidání entity. Není vhodné pokud nové role vznikají často. Neumožňuje řídit informace ohledně typů rolí.

206 Pattern: Přiřazení rolí III

207 Pattern: Přiřazení rolí ROLE TYPE ID NAME PARENT ROLE TYPE ID 100 Party role Null Null PARENT NAME 101 Customer 100 Party role 102 Partner 100 Party role 103 Organization role 100 Party role 104 Supplier 103 Organization role 105 Person role 100 Party Role 106 Employee 105 Person role 107 Manager 106 Employee 108 Debtor 100 Party role

208 Pattern: Přiřazení rolí Party Role Partner Customer Organization Role Person Role Supplier Employee

209 Pattern: Přiřazení rolí III o Ještě složitější přístup PARTY ROLE je rodičovská entita pro všechny role. o Vlastnosti PARTY může přijímat mnoho rolí. Role pro jednotlivé party mají časovou dimenzi. Existuje stromová hierarchie mezi rolemi. Pokud nové role nevyžadují nové atributy, nevyžaduje přidávání rolí zásah do datového modelu.

210 Pattern: Přiřazení rolí III o Slabé stránky Je to složité Při uvedeném číselníku typů rolí je těžko pochopitelná vazba mezi Person role a Organization role a strukturou PARTY. Pokud nová role vyžaduje nové atributy, je stále nutné zasáhnout do datového modelu.

211 PARTY model - příklad

212 PARTY_ROLE jiný příklad

213 Pattern: Klasifikace o Definice Podpora členění instancí entity podle typů, do kategorií a taxonomií. Typy skupiny se společnými charakteristikami Kategorie kategorizace podporuje více druhů členění (Typy typů) Taxonomie původně věda zabývající se klasifikací organismů; členění dle definované struktury (například Klasifikace ekonomických činností (CZ- NACE))

214 Klasifikace Product Type Hardware Software Accessory Processors Storage devices Business software Gaming Software Cases Mouse pads Product Family Disk drives Carrying Cases Computer Memory Desktop Computers Laptop Computers Product Line Home Use Commercial Use Home Business Government

215 Pattern: Klasifikace I

216 Pattern: Klasifikace I ID NAME TYPE FAMILY LINE 1 LINE 2 CAPACIT Y 100 Save Disk 2000 HW Disk Drivers Home use Commercial Use 101 Carry All Case Accesory Carrying Case Commercial use 102 HS Software package 103 Memmory card M10 Software Hardware Computer memory Home Business Home use Home Business 20GB 1GB COLOU R Black Green

217 Pattern: Klasifikace I o Velice jednoduchý model, snadno pochopitelný pro všechny uživatele o Vhodný jako základ (prototyp), odrazový můstek pro pochopení a podrobnější analýzu o Implementace může používat omezení na hodnoty ve sloupcích nebo pouze uživatelská pravidla.

218 Pattern: Klasifikace I o Slabé stránky Složitá správa redundantních dat (HW hardware Hardware) Velice nepružný model Přidání kategorie přidání atributu Mnoho typů mnoho atributů Více typů klasifikací více sloupců (Product line 1, Product line 2); Nedají se udržovat data o klasifikacích popis, doba platnosti a podobně; Model nepodporuje složitější vazby o klasifikacích pouze povinné a nepovinné klasifikace.

219 Pattern: Klasifikace II

220 Pattern: Klasifikace II o Klasifikace Navzájem se vylučující typy Hardware, Accessory, Software; Více hodnot z klasifikace Product Line. o Klasifikace je možné měnit. o Pro porozumění modelu je důležité znát obsah tabulek (číselníků). o Umožňuje nezávislé řízení klasifikací MDM o Rozdílné klasifikace mohou mít své atributy. o Porozumění modelu není extrémně složité.

221 Pattern: Klasifikace II o Slabé stránky Málo pružný model, pokud je potřeba přidávat nové klasifikace. Klasifikace jsou udržovány v oddělených entitách. Není zde standardní způsob, jak řídit typy. Každý typ má své atributy. (To může být i výhoda.) Mnoho typů klasifikací mnoho atributů, mnoho entit s klasifikacemi.

222 Pattern: Klasifikace III

223 Pattern: Klasifikace III o Popis Sjednocení všech kategorií do jedné entity; Zavedení klasifikace kategorií; Hierarchická struktura na kategoriích i typech kategorií (například pro reporting). o Vlastnosti Jednoduché řízení klasifikací přidávání nové kategorizace, změna hierarchie kategorií; Vhodné pokud je potřeba mnoho klasifikací; Jednoduchý po databázové stránce jenom čtyři tabulky; Umožňuje jednoduše složitější analýzy podle různých klasifikací.

224 Pattern: Klasifikace III o Slabé stránky Těžký na porozumění, zejména při úpravách dat číselníků. Nevynucuje žádná business pravidla. Není vazba mezi hierarchií Kategorií a Typů kategorií. Model neumožňuje mít rozdílné atributy pro specifické typy.

225 Shrnutí o ešení musí odpovídat Složitosti business domény, Složitosti business pravidel, Schopnosti analytiků a vývojářů porozumět modelu, Schopnosti uživatelů udržovat model. o Vždy je vhodné při návrhu modelu vytvářet i data entit.

226 Další směry o ešení časové platnosti záznamu. o ešení více hierarchií. o ešení definice různých atributů pro různé typy.

227 Co si zapamatovat o Co to jsou databázové pattery o Jaké databázové patterny se používají o Jaké řešení pro pattern Rolí se používají, jaké mají slabé a silné stránky o Jaké řešení pro pattern klasifikace se používají, jaké mají slabé a silné stránky

228 Diskuse

229 Dimenzionální modelování UAI /14 RNDr. Ondřej Zýka,

230 Dimenzionální modelování o Ralph Kimball (1997) o Primárně modely pro datové sklady a analýzy Silně denormalizovaný model o Modely Pochopitelné pro netechnicky orientované uživatele Snadno rozšiřitelné Orientované na analytické dotazy Podporované datovými servery a analytickými nástroji (OLAP) o Schopnost reportovat z extrémního objemu dat o Minimum update pouze přidávání dat Požadavek neměnící se historie Technologie neumí současný update a select

231 Příklad

232 Standardní dotaz select SUM(qty) from F_SALES,D_TIME,D_TITLES,D_STORES,D_AUTHORS where F_SALES.TITLES_KEY = D_TITLES.TITLES_KEY and F_SALES.STORES_KEY = D_STORES.STORES_KEY and F_SALES.AUTHOR_KEY = D_AUTHOR.AUTHOR_KEY and F_SALES.DATE_KEY = D_DATE. DATE_KEY and podminky na D_TITLES and podminky na D_STORES and podminky na D_AUTHORS and podminky na D_DATE group by pozadovana granularita vysledku

233 Star schéma Dimenze Time Transaction Date Grocery Transaction Store Number Transaction Date Customer Product Quantity Amount Store Store Number Store Name City State Country Telephone Customer Customer From Date To Date First Name Last Name Address 1 Address 2 Address 3 City State Country Postal Code Fakta Product Product Description Category

234 Snowflake schéma Sales Period Period Identifier Sales Period From Date To Date Region Region Description Time Transaction Date Grocery Transaction Store Number Transaction Date Customer Product Quantity Amount Store Store Number Store Name City State Country Telephone Region Customer Category Category Customer Category Customer Customer First Name Last Name Address 1 Address 2 Address 3 City State Country Postal Code Customer Category Product Product Description Category Product Category Product Category Description

235 Snowflake model o Výhody Minimální redundance dat v rámci dimenzí Úspora místa v databázi Větší flexibilita pro modelování Užitečný pro dimenze se složitou strukturou o Nevýhody Složitější konstrukce dotazů, mnoho joinů Nižší výkonnost Komplikovaný snowflake model může odradit uživatele od přímého přístupu k datům uživatelské nástroje zpravidla zavádějí sémantickou vrstvu, která uživatele odstíní od datového modelu Možný konflikt s bitmapovými indexy Úspora místa je většinou převážena nižší výkonností a složitější administrací

236 Constellation schéma Store Store Number Store Name City State Country Telephone Region Product Inventory Product Warehouse Location Quantity On Hand Quantity Back Ordered Warehouse Warehouse Address 1 Address 2 Address 3 City State Country Postal Code Vendor Vendor Vendor Name Address 1 Address 2 Address 3 City State Country Postal Code Time Transaction Date Grocery Transaction Store Number Transaction Date Customer Product Purchase Quantity Amount Product Purchases Product Purchase Date Supplying Vendor Purchase Order Unit Quantity Purchase Cost Customer Customer First Name Last Name Address 1 Address 2 Address 3 City State Country Postal Code Customer Category Product Product Description Category Product Line

237 Snowstorm schéma Sales Period Period Identifier Sales Period From Date To Date Promotion Period Promotion Id Promotion From Date To Date Store Store Number Store Name City State Country Telephone Region Region Region Description Product Inventory Product Warehouse Location Quantity On Hand Quantity Back Ordered Warehouse Warehouse Address 1 Address 2 Address 3 City State Country Postal Code Vendor Vendor Vendor Name Address 1 Address 2 Address 3 City State Country Postal Code Time Transaction Date Grocery Transaction Store Number Transaction Date Customer Product Purchase Quantity Amount Product Purchases Product Purchase Date Supplying Vendor Purchase Order Unit Quantity Purchase Cost Customer Category Category Customer Category Customer Customer First Name Last Name Address 1 Address 2 Address 3 City State Country Postal Code Customer Category Product Product Description Category Product Line Product Line Product Line ID Description Product Category Product Category Description

238 Postup návrhu modelu 1. Výběr sledovaných procesů 2. Určení granularity 3. Určení dimenzí 4. Určení metrik 5. Definice získávání dat (ETL)

239 Výběr sledovaných procesů o Seznam procesů, které chceme analyzovat Od jednodušších ke složitějším o Bus matrix Matice: Business procesy x Dimenze o Často odpovídá jeden business proces jeden datamart

240 Buss matrix

241 Date Customer Service Bus matrix Rate Category Local Svc Provider Calling Party Custommer Billing Service Orders Trouble Reports Yellow Page Ads Customer Inquiries Promotion Billing Call Detail Network Call Detail Customer Inventory Network Inventory Real eastate Labor & Payroll Computer Charges Purchase Orders Supplier Deliverables Called Party Long Dist Provider Internal Organization Employee Location Equipment Type Supplier Item Shipped Weather Account status

242 Bus architektura a schéma - příklad

243 Určení granularity o Všechny řádky musí mít stejnou granularitu o Granularita malá Jeden řádek jedno měření Velký objem dat o Granularita velká Malé databáze Omezená možnost analýz o Hodnoty odpovídají průniku všech dimenzí o Někdy potřeba realokace dat na několik řádek o ádky s hodnotou nula se nazapisují

244 Fact tables o Transaction - co řádek to transakce (například obchody) Proces může obsahovat více typů transakcí, rozhodnutí zda jedna nebo více tabulek není jednoduché o Snapshots - každý den se udělá celý snímek State model celé denní snímky Event model každý den pouze změněné záznamy Možnost dopočítání dalších hodnot ke každému snímku o Akumulujíce se shapshoty (sklad) Id výrobku jako primární klíč a doplňují/updatují se hodnoty pro události popisující životní cyklus Do daného řádku se doplní datum expedice, fakturace, dodání, vyúčtování, Pozor - update v tabulce faktů o (Fact tables bez faktů slouží jako n:n vazba mezi dimenzemi)

245 Fact tables o Fakta aditivní - počet, cena v transakčních fact tabulkách Význam pro všaechny dimenze Nejlépe se s nimi pracuje Cílem je převést na aditivní fakta maximum Discount -> ceníková cena, prodejní cena semiaditivní - počet cena v snapshot tabulkách součet za produkty má význam, za čas nemá význam Obecně význam pouze pro některé dimenze nonadditive - procentuální profit Často text Někdy možné přenést do dimenzí (degenerované dimenze) o Factless fact table pouze cizí klíče, žádná fakta Příznak existence (účast v kampani)

246 Určení dimenzí o Konformní dimenze Jedna nejpodrobnější dimenze, ostatní jsou jejich agregací Jednotné dimenze pro všechny business procesy o Jeden sloupec primárního klíče o Hodně sloupců popisů, často přes 30, čím více tím lépe o Atributy spíše textové (srozumitelnost) o Hierarchie pro analýzy o Časová dimenze o Degenerovaná dimenze nemá popis (číslo faktury) o Dimenze jsou denormalizované (jedna široká tabulka) Normalizace vločkové schéma o Umělé klíče pro odstínění změn o ádek s hodnotu Not applicable, Uknown

247 Časová dimenze o V každém datovém skladu o Často mnoho hierarchií Provozní rok Fiskální rok Kalendářní rok o Mnoho sloupců Textová informace Číselná informace Konce a začátky období

248 Časová dimenze

249 Časová dimenze - hierarchie Lower-level of granularity is Day 6 parallel hierarchies

250 Dimensions o Schéma a instance dimenze lokace o Použití srozumitelných dat, texty o Často odvozeno z jiných zdrojů (i externích) o Redundance dat je pouze v dimenzích (nikoliv ve faktových tabulkách) o Umožňuje vybírat a agregovat data po úrovních o Hierarchie by měli mít konstatní hloubku (nedoplňovat regiony jenom někde) o Hierarchie jsou obsaženy v metadatech o dimenzích

251 Typy dimenzí o Konformní Pro celý podnik Ostatní dimenze jako podimenze konformních dimenzí o Minidimenze a sběrné dimenze Číselníky Stavové a textové atributy Možné sloučit do sběrných dimenzí o Degenerované dimenze Přímo v tabulce faktů (číslo objednávky)

252 Typy dimenzí z pohledu změn o Statické Žádné ošetření změn V případě změny se přepíše starý záznam Žádná historie o Rostoucí dimenze Přidávají se nové záznamy V případě změny se přepíše starý záznam Žádná historie o Rychle rostoucí diimenze Nutné speciální řešení Oddělení rychle se měnících atributů do vlastní dimenze (Jako Slowly changed dimension Type 2) o Slowly changing dimenze

253 Slowly changing dimension o Typ 1 přepis hodnot Žádná historie o Typ 2 přidávání řádků, vždy jeden platný Přidané pole Begin date, End date, Eff date key, Change reason text, Current flag Kompletní historie o Typ 3 alternativní realita vice možností v jeden čas Přidání nových záznamů uchování současné a předchozí hodnoty v případě změny o Redundance nebývá problém Dimenze zabírají cca 5% místa v DWH

254 Dimensionální model ve zkratce o Fact tables fakta (metriky) a cizí klíče z dimenzí o Dimension tables jeden sloupec primárního klíče a mnoho popisných sloupců o Star schéma o Další speciální tabulky

255 Příklad o Fakta Počet prodaných knih Cena za prodané knihy o Dimenze Knihy Obchody Čas o Hierarchie Knihy Kniha typy knih vše Čas Den kalendářní měsíc kalendářní kvartál kalendářní rok celá historie Obchody Obchod hierarchická struktura podle ústředí vše

256 Další témata o Údržba modelu o Přidělování klíčů o Vazba mezi identifikací ve vstupních datech a primárními klíči o Datová kvalita o Agregace o Vstupní data snapshots nebo events

257 OLAP technologie o Uložení a zpracování dat podporující určité druhy analýz parameterized static reporting slicing and dicing with drill down what if? analysis goal seeking models o Způsob uložení předpočítaných hodnot (denormalizace) Uložení agregovaných hodnot vyžadovaných analýzami podle zadaných Metrik Dimenzí Hierarchií na dimenzích

258 Příklad uložení

259 Multidimenzionální databáze o Nutné rozlišit Princip Práce s dimenzemi Práce s hierarchiemi Skutečný způsob uložení dat Relační model Speciální úložiště se speciálními indexy o Kategorizace dle místa uložení dat a agregací MOLAP veškerá data uložená v multidimenzionální databázi ROLAP veškerá data uložená v relační HOLAP hybrid o Další typy RTOLAP real time, data pouze v RAM DOLAP desktop OLAP, data uložená na klientském počítači

260 FASMI - Fast Analysis of Shared Multidimensional Information o Alternativní název pro OLAP reportingová prostředí o Fast Rychlá odezva, obvykle do jednotek sekund, maximálně několik desítek sekund Delší odezvy odrazují od analýzy, snižují zapojení uživatelů o Analytical Uživatelsky přívětivá schopnost analýz Nevyžaduje programování Podpora dostatečného množství funkcí a neprocedurálních modelů o Shared Podpora bezpečnosti až na úrovni buňky Read-write model o Mutlidimensional Podporuje multidimensionálního pohledu na data Star-, respektive snow-flake schéma Podpora více hierarchií o Information Schopnost zpracovat velké množství informací RAM a disk požadavky. Integrce s DWH

261 FASMI test BI platformy o Multidimensional Conceptual View o Intuitive Data Manipulation o Accessibility o Batch Extraction vs Interpretive o OLAP Analysis Models o Client Server Architecture o Transparency o Multi-User Support o Treatment of Non-Normalized Data o Storing OLAP Results o Extraction of Missing Values o Treatment of Missing Values o Flexible Reporting o Uniform Reporting Performance o Automatic Adjustment of Physical Level o Generic Dimensionality o Unlimited Dimensions & Aggregation Levels o Unrestricted Cross-dimensional Operations

262 Příklady dodavatelů OLAP serverů o MS Analysis Services o IBM Cognos o Oracle OLAP option o Hyperion Essbase o Business Objects o MicroStrategy o SAS

263 Co si zapamatovat o K čemu slouží dimenzionální datové modely o Jaké jsou hlavní rozdíly relačního a dimenzionálního modelování o Jaké jsou rozdíly mezi modely typu hvězda, souhvězdí, vločka nebo sněhová bouře o Jaký je doporučený postup při návrhu dimenzionálního modelu o Co to je Buss Matrix, k čemu slouží o Jaké typy faktových tabulek se používají o Co to je aditivní, semiaditivní a neaditivní metrika o Jaké typy dimenzí se používají o Co to je "Slowly changing dimension of type 2" o Co to je OLAP databáze

264 Diskuse

265 SQL pro DWH UAI /14 RNDr. Ondřej Zýka,

266 Pokročilé použití SQL o Pomocné tabulky With o Rekurze with o Rozhodování case o Analytické funkce COUNT, SUM, AVE, MAX, MIN azení: RANK, DENSE_RANK, ROW_NUMBER Práce s předchozím a následným řádkem: LAG,LEAD o Testování

267

268 Základní části příkazu select Seřaďte knihkupectví podle počtu poboček. COUNT HEADQUARTER

269 ešení SELECT COUNT(STORE_ID) AS "COUNT", HEADQUARTER FROM STORE GROUP BY HEADQUARTER ORDER BY "COUNT"

270 Join A B A B select * from A left join B on A.PK = B.PK select * from A right join B on A.PK = B.PK A B A B A B select * from A left join B on A.PK = B.PK where B.PK is null select * from A inner join B on A.PK = B.PK select * from A right join B on A.PK = B.PK where A.PK is null A B A B select * from A full outer join B on A.PK = B.PK select * from A full outer join B on A.PK = B.PK where A.PK is null or B.PK is null

271 Join Zjistěte kolik knih kterých autorů se prodalo v kterém knihkupectví. - Různé syntaxe - Vyjadřovací síla syntaxi JMENO OBCHOD TITUL ET Bennet,Abraham Academia The Busy Executive's Database Guide 2 Bennet,Abraham Dům Knihy The Busy Executive's Database Guide 5 Bennet,Abraham Dům knihy Kanzelsberger The Busy Executive's Database Guide 2 Bennet,Abraham Dům učebnic a knih Černá labuť The Busy Executive's Database Guide 2 Bennet,Abraham Kanzelsberger The Busy Executive's Database Guide 2 Bennet,Abraham Kanzelsberger, a. s. The Busy Executive's Database Guide 6 Bennet,Abraham Knihkupectví Chodov The Busy Executive's Database Guide 8 Bennet,Abraham Knihkupectví Dejvická The Busy Executive's Database Guide 3 Bennet,Abraham Knihkupectví Hlavní nádraží The Busy Executive's Database Guide 4 Bennet,Abraham Knihkupectví Nový Smíchov The Busy Executive's Database Guide 5 Bennet,Abraham Knihy Kanzelsberger The Busy Executive's Database Guide 33 Bennet,Abraham Luxor The Busy Executive's Database Guide 5 Bennet,Abraham OC Centrum The Busy Executive's Database Guide 3 Bennet,Abraham OC Olympia The Busy Executive's Database Guide 6 Bennet,Abraham OC Varyáda The Busy Executive's Database Guide 7 Bennet,Abraham Palác knih Luxor The Busy Executive's Database Guide 3 Bennet,Abraham Palác knih Palladium The Busy Executive's Database Guide 4 Blotchet-Halls,Reginald Academia Fifty Years in Buckingham Palace Kitchens 68 Blotchet-Halls,Reginald Dům Knihy Fifty Years in Buckingham Palace Kitchens 71 Blotchet-Halls,Reginald Dům knihy Kanzelsberger Fifty Years in Buckingham Palace Kitchens 55

272 ešení select l_name ',' f_name as jmeno, name as obchod, title as titul, sum(qty) as pocet from author join title_author on (title_author.au_id = author.au_id) join title on (title_author.title_id = title.title_id) join sales_detail on (sales_detail.title_id = title.title_id) join store on (store.store_id = sales_detail.store_id) group by l_name ',' f_name, title, name order by 1,2,3;

273 ešení pomocné tabulky with at_table (jmeno, titul, title_id) as select l_name ',' f_name, title titul, title_id from author join title_author on (title_author.au_id = author.au_id) join title on (title_author.title_id = title.title_id), sales_table (obchod, pocet, title_id) as select name, sum(qty), title_id from sales_detail join store on (store.store_id = sales_detail.store_id) group by title_id, name select from jmeno, obchod, titul, pocet at_table join sales_table on (at_table.title_id=sales_table,title_id);

274 Rekurze Vytvořte tabulku s hodnotami 1 až 100 ID

275 ešení with numbers (val) as (select 1 as val from dual union all select val+1 from numbers where val < 100) select val as ID from numbers;

276 Rekurze - číselník o Vytiskněte strukturu obchodů OBCHODY Academia:Václavské nám 34 Luxor:Na Poříčí 25/1067 Knihkupectví Chodov:Nákupní centrum Chodov Knihkupectví Hlavní nádraží:hlavní nádraží, Wilsonova 8 Knihkupectví Dejvická:Vestibul metra A - Dejvická Palác knih Luxor:Václavské náměstí 41 Knihkupectví Nový Smíchov:Plzeňská 8 Palác knih Palladium:Náměstí Republiky 1 Dům učebnic a knih Černá labuť:na poříčí 25, Kanzelsberger, a. s.:4d Office Center, Kodaňská 46 Knihy Kanzelsberger:Prokopa Holého 15 OC Centrum:Vídeňská 100 Dům knihy Kanzelsberger:Kanovnická 3 Knihy Kanzelsberger:Hradební 1 Kanzelsberger:Josefská 2 OC Varyáda:Kpt. Jaroše 375/31 Dům Knihy:Václavské nám 4 Knihy Kanzelsberger:Panská 132/I Knihy Kanzelsberger:T. G. Masaryka 253 Knihy Kanzelsberger:Sedláčkova 109 Knihy Kanzelsberger:Čelakovského 480/10 Knihy Kanzelsberger:Čs. armády 216 Knihy Kanzelsberger:Dukelská tř. 3 Knihy Kanzelsberger:Vodní 61 Knihy Kanzelsberger:Palackého 96 OC Olympia:Jičínská 1350/3

277 ešení with stores(store_id, name,address, store_level, path) as (select store_id, name, address, 1,cast(store_id as varchar2(100)) from store where store_id = headquarter union all select store.store_id, store.name, store.address, stores.store_level+1, stores.path '.' store.store_id from store join stores on (stores.store_id = store.headquarter and store.store_id!= store.headquarter) ) select rpad(' ',store_level*3) name ':' address as obchody from stores order by path;

278 Count Co počítají příkazy select count(*) from title; 18 select count(price) from title; 16 select count(all price) from title; 16 select count(distinc price) from title; 11

279 Count - analytická funkce Spočtěte počet knih, které jsou maximálně o dvě dražší nebo o 3 levnější než daná kniha. TITLE_ID PRICE POCET MC BU PS PS PS BU TC TC BU MC PS

280 ešení select title_id, price, count(price) over (order by price RANGE BETWEEN 3 PRECEDING AND 2 FOLLOWING ) as pocet from title order by price;

281 Count analytická funkce V kolika různých typech knih se vyskytuje kniha se stejnou cenou: TITLE_ID TYPE PRICE TYPE_COUNT BU2075 business BU1032 business BU7832 business BU1111 business MC3021 mod_cook MC2222 mod_cook PC1035 popular_comp PC9999 popular_comp 2 PC8888 popular_comp 20 1 PS2091 psychology MC3026 psychology 2

282 ešení select from title title_id, type, price, count(distinct type) over (partition by price) as type_count order by type;

283 azení číslování řádků Seřaďte knihy podle prodejů. ORDER TOTAL_SALES TYPE TITLE_ID psychology PS psychology PS trad_cook TC mod_cook MC psychology PS psychology PS business BU psychology PS trad_cook TC popular_comp PC business BU business BU popular_comp PC trad_cook TC4203

284 ešení select row_number() over (ORDER BY TOTAL_SALES) as "ORDER", total_sales, type, title_id from title

285 azení ve skupinách Seřaďte knihy podle prodejů a typů knih. ORDER TOTAL_SALES TYPE TITLE_ID business BU business BU business BU business BU mod_cook MC mod_cook MC popular_comp PC popular_comp PC (null) popular_comp PC psychology PS psychology PS psychology PS psychology PS psychology PS3333

286 ešení select row_number() over (partition by type order by total_sales) as "ORDER", total_sales, type, from title title_id

287 azení II Seřaďte knihy podle prodejů - stejný počet, stejné pořadí (jako v golfu) ORDER TOTAL_SALES TYPE TITLE_ID psychology PS psychology PS trad_cook TC mod_cook MC psychology PS psychology PS business BU psychology PS trad_cook TC popular_comp PC business BU business BU popular_comp PC trad_cook TC4203

288 ešení select rank() over (order by total_sales) as "ORDER", total_sales, type, title_id from title

289 azení III Seřaďte knihy podle prodejů, stejný počet, na stejném místě. ORDER TOTAL_SALES TYPE TITLE_ID psychology PS psychology PS trad_cook TC mod_cook MC psychology PS psychology PS business BU psychology PS trad_cook TC popular_comp PC business BU business BU popular_comp PC trad_cook TC business BU2075

290 ešení select dense_rank() over (order by total_sales) as "ORDER", total_sales, type, title_id from title

291 Rozhodování - case Skryjte opakující se hodnoty. ORDER TOTAL_SALES TYPE TITLE_ID psychology PS psychology PS trad_cook TC mod_cook MC psychology PS psychology PS business BU psychology PS trad_cook TC business BU business BU popular_comp PC popular_comp PC trad_cook TC4203

292 ešení select from case LAG("ORDER") over (order by "ORDER") when "ORDER" then null else "ORDER" end as order, total_sales, type, title_id (select dense_rank() over (order by total_sales) as "ORDER", total_sales, type, title_id from title)

293 Case jiné použití Spočtěte počty prodaných knih podle vydavatelství a měsíce, výstup v tabulkovém formátu. MONTH New Age Books Binnet & Hardley Aldata Infosystems

294 ešení select TO_CHAR(SALE.ORD_DATE,'yyyy-mm') as MONTH, SUM(case when TITLE.pub_id = '0736' then QTY else 0 end) as "New Age Books", SUM(case when TITLE.pub_id = '0877' then QTY else 0 end) as "Binnet & Hardley", SUM(case when TITLE.pub_id = '1389' then QTY else 0 end) as "Aldata Infosystems" from PUBLISHER, SALE, SALES_DETAIL, TITLE where SALES_DETAIL.TITLE_ID = TITLE.TITLE_ID and PUBLISHER.PUB_ID = TITLE.PUB_ID and SALE.ORD_NUM = SALES_DETAIL.ORD_NUM group by TO_CHAR(SALE.ORD_DATE,'yyyy-mm') order by 1

295 Spojení hodnot Dejte všechny title_id pro vydavatele do jedné řádky PUB_ID TITLE_IDS BU2075,PS2091,PS2106,PS3333,PS MC2222,MC3021,MC3026,PS1372,TC3218,TC4203,TC BU1032,BU1111,BU7832,PC1035,PC8888,PC9999

296 ešení with aux1(pub_id, title_id, row_id) as (select pub_id, title_id, row_number() over (partition by pub_id order by title_id ) from title), -- příklad ř aux2 (pub_id, title_id, path,row_id) as (select pub_id, title_id,cast(title_id as varchar2(100)),row_id from aux1 where row_id = 1 union all select aux2.pub_id, aux1.title_id, aux2.path ',' aux1.title_id,aux1.row_id from aux2 join aux1 on (aux1.pub_id=aux2.pub_id and aux1.row_id = aux2.row_id+1)) příklad 5 select pub_id,max(path) from aux2 group by pub_id order by pub_id;

297 Testování Máte dvě tabulky nebo view, například: create view TITLE1 as select * from title where title like '%a% create view TITLE2 as select * from title where price > 10 Zjistěte: 1. Zda tabulky mají stejný počet záznamů 2. Zda tabulky mají shodné řádky 3. Které řádky (hodnoty), jsou v jedné tabulce a nejsou v druhé

298 Co si zapamatovat o SQL má podporu pro rekurzivní operace o Mnoho požadavků BI se dá řešit pomocí analytických funkcí o Základní metody testování shodnosti tabulek

299 Diskuse

300 Technologie DWH UAI /14 RNDr. Ondřej Zýka,

301 Technologie o Denormalizace Partitioning Indexy Materializované view o Indexy a bitmapové indexy o Komprimované tabulky o Paralelismus o OLAP

302 Denormalizace o Partitioning Horizontální Vertikální o Uložení vypočtených hodnot o Spojení tabulek

303 Horizontální rozdělení tabulek o Přístupy pouze na část tabulky o Příklady: Aktivní a neaktivní položky Historické záznamy o Možnosti Rozdělení tabulky Přidání tabulky (duplicitní záznamy) Partitioning

304 Rozdělení tabulky Rozdělení tabulky Part 1 Part 1 Table Part 2 View Table Part 3 Výhody práce s menším množstvím dat méně problémů se zamykáním lepší řízení indexů možnost detailní optimalizace Nevýhody nutnost synchronizace triggery, aplikační logika Náročnější údržba

305 Partitioning o Transparentní z pohledu aplikace o Rozdělení dle daného rozsahu nebo hodnot o Dynamicky podle hodnot Dynamicky vytvářeno pro každý měsíc Nejčastější použití o Podle hash klíče (určuje se pouze počet partitions) Part 1 Part 2 Part 3 Part 4 o Více úrovňový partitioning Podle času, podle pobočky o Možnost individuálního řízení partition o Omezený počet partition podle implementace

306 Vertikální rozdělení tabulek o Přístupy pouze na některé sloupce tabulky o Příklady: Bloby, obrázky, popisy o Možnosti Rozdělení tabulek Přidání tabulky (duplicitní záznamy) Vytvoření indexu

307 Rozdělení tabulky Rozdělení tabulky Table P a r t P a r t P a r t View Table P a r t Výhody práce s menším množstvím dat méně problémů se zamykáním možnost optimalizace Nevýhody nutnost synchronizace triggery, aplikační logika náročnější údržba

308 Přidání indexů o Transparentní z pohledu aplikace o Jeden clustrovaný index o Libovolný počet dalších indexů o Automatická údržba o Pokrývající dotazy I n d e x 1 I n d e x 2 o Nároky na diskový prostor o Snížení výkonu pro OLTP aplikace

309 Uložení vypočtených dat o Přidání sloupce o Přidání tabulky o Synchronizace Trigerry Uložené procedury Aplikační logika o Nutno zavést procedury pro údržbu a resynchronizaci

310 Materializovaná view o Transparentní z pohledu aplikace o Automatické řízení výpočtu view o Nákladné výpočty, nutnost možnosti řízení výpočtů asynchronně o Duplicitní uložení dat nároky na diskový prostor

311 B-tree index příklad kořen vnitřní blok indexu listová úroveň indexu data klíč řádek blok Blok 1001 Bennet Chet 1421, Karsen Kit 1876, Smith Ade 1242, Blok 1007 Bennet Chet 1421, Fox John 1317, Hunter Leon 1213, Blok 1306 Karsen Kit 1876, Larn Pard 1451, Peters Mary 1856, Blok 1132 Bennet Chet 1421,1 Burns Saly 1409,4 Claim Dave 1129,3 Dull Rob 1409,1 Blok 1133 Fox John 1317,3 Greane David 1876,4 Green Mitch 1213,2 Greene Joe 1409,2 Blok 1212 Larry John 254 A3 Jetkins Paul 244 C3 White Susan 156 A1 Blok 1213 Hunter Leon 124 A3 Green Mitch 125 B1 Smith Ade 156 A3 Blok 1421 Blok 1127 Bennet Chet 101 B2 Hunter Leon 1213,1 Jetkins Paul 1212,2 Ringer John 144 C1 INSERT INTO user VALUES ( Burns, Saly,128, A1 ) Blok 1409 Dull Rob 128 B1 Greene Joe 142 A2 Port Joe 156 C3 Burns Saly 128 A1

312 Clustered index příklad kořen vnitřní blok indexu listová úroveň indexu klíč blok Blok 1001 Bennet Chet 1007 Karsen Kit 1306 Smith Ade 1062 Blok 1007 Bennet Chet 1132 Fox John 1133 Hunter Leon 1127 Blok 1306 Karsen Kit 1198 Larn Pard 1199 Peters Mary 1200 Blok 1132 Bennet Chet 101 B2 Burns Saly 128 A1 Claim Dave 123 A1 Blok 1133 Fox John 100 A0 Greane David 111 E3 Green Mitch 125 B1 Greene Joe 156 C3 Blok 1127 Hunter Leon 122 A3 Jetkins Paul 124 A5 INSERT INTO user VALUES ( Burns, Saly,128, A1 )

313 Přístupové metody za použití indexu o Nalezení jednotlivých řádků přístupem od kořene indexu o Nalezení skupiny řádků přístupem od kořene indexu a scanem nejnižší úrovně indexu o Scan nejnižší úrovně indexu o Scan dat vědomé nepoužití indexu

314 Data uložená po sloupcích o Vertica o SAP Sybase IQ o Oracle bitmapové indexy

315 Tabulka relační uložení dat ID NAME DESCRIPTION QTY COLOUR PRICE PROVIDER WIDTH HEIGHT DEPTH NUMBER VARCHAR2(50 BYTE) VARCHAR2(500 BYTE) NUMBER VARCHAR2(20 BYTE) NUMBER VARCHAR2(40 BYTE) NUMBER NUMBER NUMBER Struktura tabulky Datové bloky ID NAME DESCRIPTION QTY COLOUR PRICE PROVIDER WIDTH HEIGHT DEPTH ID NAME DESCRIPTION QTY COLOUR PRICE PROVIDER WIDTH HEIGHT DEPTH ID NAME DESCRIPTION QTY COLOUR PRICE PROVIDER WIDTH HEIGHT DEPTH ID NAME ID NAME DESCRIPTION DESCRIPTION QTY COLOUR QTY COLOUR PRICE PRICE PROVIDER PROVIDER WIDTH WIDTH HEIGHT HEIGHT DEPTH DEPTH ID NAME ID NAME DESCRIPTION DESCRIPTION QTY COLOUR QTY COLOUR PRICE PRICE PROVIDER PROVIDER WIDTH WIDTH HEIGHT HEIGHT DEPTH DEPTH ID NAME ID NAME DESCRIPTION DESCRIPTION QTY COLOUR QTY COLOUR PRICE PRICE PROVIDER PROVIDER WIDTH WIDTH HEIGHT HEIGHT DEPTH DEPTH ID NAME ID NAME DESCRIPTION DESCRIPTION QTY COLOUR QTY COLOUR PRICE PRICE PROVIDER PROVIDER WIDTH WIDTH HEIGHT HEIGHT DEPTH DEPTH ID NAME ID NAME ID NAME DESCRIPTION DESCRIPTION DESCRIPTION QTY COLOUR QTY COLOUR QTY COLOUR PRICE PRICE PROVIDER PROVIDER PRICE PROVIDER WIDTH WIDTH WIDTH HEIGHT HEIGHT HEIGHT DEPTH DEPTH DEPTH ID NAME ID NAME DESCRIPTION DESCRIPTION QTY COLOUR QTY COLOUR PRICE PROVIDER PRICE PROVIDER WIDTH WIDTH HEIGHT HEIGHT DEPTH DEPTH ID NAME ID NAME DESCRIPTION DESCRIPTION QTY COLOUR QTY COLOUR PRICE PROVIDER PRICE PROVIDER WIDTH WIDTH HEIGHT HEIGHT DEPTH DEPTH ID NAME ID NAME DESCRIPTION DESCRIPTION QTY COLOUR QTY COLOUR PRICE PROVIDER PRICE PROVIDER WIDTH WIDTH HEIGHT HEIGHT DEPTH DEPTH ID NAME DESCRIPTION QTY COLOUR PRICE PROVIDER WIDTH HEIGHT DEPTH ID NAME DESCRIPTION QTY COLOUR PRICE PROVIDER WIDTH HEIGHT DEPTH ID NAME DESCRIPTION QTY COLOUR PRICE PROVIDER WIDTH HEIGHT DEPTH ID NAME DESCRIPTION QTY COLOUR PRICE PROVIDER WIDTH HEIGHT DEPTH ID NAME DESCRIPTION QTY COLOUR PRICE PROVIDER WIDTH HEIGHT DEPTH ID NAME DESCRIPTION QTY COLOUR PRICE PROVIDER WIDTH HEIGHT DEPTH ID NAME DESCRIPTION QTY COLOUR PRICE PROVIDER WIDTH HEIGHT DEPTH ID NAME DESCRIPTION QTY COLOUR PRICE PROVIDER WIDTH HEIGHT DEPTH ID NAME DESCRIPTION QTY COLOUR PRICE PROVIDER WIDTH HEIGHT DEPTH ID NAME DESCRIPTION QTY COLOUR PRICE PROVIDER WIDTH HEIGHT DEPTH ID NAME DESCRIPTION QTY COLOUR PRICE PROVIDER WIDTH HEIGHT DEPTH ID NAME DESCRIPTION QTY COLOUR PRICE PROVIDER WIDTH HEIGHT DEPTH

316 Tabulka data uložená po sloupcích ID NAME DESCRIPTION QTY COLOUR PRICE PROVIDER WIDTH HEIGHT DEPTH NUMBER VARCHAR2(50 BYTE) VARCHAR2(500 BYTE) NUMBER VARCHAR2(20 BYTE) NUMBER VARCHAR2(40 BYTE) NUMBER NUMBER NUMBER Struktura tabulky Datové bloky ID ID ID ID ID ID ID ID ID ID ID ID ID ID ID ID ID ID ID ID ID ID ID ID ID ID ID ID ID ID ID NAME ID NAME ID NAME ID NAME ID NAME ID NAME ID NAME ID NAME ID NAME ID NAME ID NAME ID NAME ID NAME ID NAME ID NAME ID NAME ID NAME ID NAME ID NAME ID NAME ID NAME ID NAME ID NAME ID NAME ID NAME ID NAME ID NAME ID NAME ID NAME ID NAME ID NAME ID NAME ID NAME ID NAME ID NAME ID NAME ID NAME ID NAME ID NAME ID NAME ID NAME COLOUR ID NAME COLOUR ID NAME COLOUR ID NAME COLOUR ID NAME COLOUR ID NAME COLOUR ID NAME COLOUR ID NAME COLOUR ID NAME COLOUR ID NAME COLOUR NAME COLOUR NAME COLOUR NAME COLOUR NAME COLOUR NAME COLOUR NAME COLOUR NAME COLOUR NAME COLOUR NAME COLOUR NAME COLOUR NAME COLOUR NAME COLOUR NAME COLOUR NAME COLOUR NAME COLOUR NAME COLOUR NAME COLOUR NAME COLOUR NAME COLOUR NAME COLOUR NAME COLOUR NAME COLOUR NAME COLOUR NAME COLOUR NAME COLOUR NAME COLOUR NAME COLOUR NAME COLOUR NAME COLOUR NAME COLOUR QTY QTY QTY QTY QTY QTY QTY QTY QTY QTY COLOUR COLOUR COLOUR COLOUR COLOUR COLOUR COLOUR COLOUR COLOUR COLOUR QTY QTY QTY QTY QTY QTY QTY QTY QTY QTY COLOUR COLOUR COLOUR COLOUR COLOUR COLOUR COLOUR COLOUR COLOUR COLOUR QTY QTY QTY QTY QTY QTY QTY QTY QTY QTY COLOUR COLOUR COLOUR COLOUR COLOUR COLOUR COLOUR COLOUR COLOUR COLOUR QTY QTY QTY QTY QTY QTY QTY QTY QTY QTY COLOUR COLOUR COLOUR COLOUR COLOUR COLOUR COLOUR COLOUR COLOUR COLOUR QTY QTY QTY QTY QTY QTY QTY QTY QTY QTY QTY QTY QTY QTY QTY QTY QTY QTY QTY QTY QTY QTY QTY QTY QTY QTY QTY QTY QTY QTY QTY QTY QTY QTY QTY QTY QTY QTY QTY QTY

317 Data uložená po sloupcích SELECT Count(*) FROM sale where color = Green SELECT Count(*) FROM sale where color in ( Green, Red )

318 Data uložená po sloupcích SELECT SUM(qty) FROM sale (2 * 64) + (3 * 32) + (2 * 16) + (1 * 8) + (3 * 4) + (2 * 2) + (3 * 1) = 283

319 Bitmapové indexy o Rychlé pro sloupce s malou kardinalitou o Rychlé pro operace na málo sloupcích o Složitý update Zamykání a rebuild velkých bloků o Pomalé pro dotaz na jeden konkrétní řádek

320 Metody ukládání bitmapových indexů o Samé nuly nebo jedničky Bloky se neukládají pouze indikátor jejich existence o Do 20% nul nebo jedniček Data se kódují jako souvislé množiny hodnot o Mezi 20% a 80% jedniček Ukládá se skutečná mapa hodnot

321 Typy sloupcových indexů o Mnoho různých typů Více indexů na jednom sloupci o Bitový index pro sloupce s malou kardinalitou o Bitový index pro sloupce s velkou kardinalitou a malou selektivností o Indexy pro sloupce s velkou kardinalitou G-Array (příbuzný B-tree) o Prosté komprimované uložení dat (pro textové řetězce) o Speciální indexy pro čas a datum o Indexy pro joiny, porovnání a další operace

322 Sybase IQ uložení dat a indexů Velikost databáze (GB) Indexy Sumace Čistá data Čistá data CBRD Tradiční RDBMS o Indexy jsou už data o Nízké náklady na uložení dat o Rychlé zpracování malého množství dat

323 OLAP technologie o Uložení a zpracování dat podporující určité druhy analýz parameterized static reporting slicing and dicing with drill down what if? analysis goal seeking models o Způsob uložení předpočítaných hodnot (denormalizace) Uložení agregovaných hodnot vyžadovaných analýzami podle zadaných Metrik Dimenzí Hierarchií na dimenzích

324 FASMI - Fast Analysis of Shared Multidimensional Information o Alternativní název pro OLAP reportingová prostředí o Fast Rychlá odezva, obvykle do jednotek sekund, maximálně několik desítek sekund Delší odezvy odrazují od analýzy, snižují zapojení uživatelů o Analytical Uživatelsky přívětivá schopnost analýz Nevyžaduje programování Podpora dostatečného množství funkcí a neprocedurálních modelů o Shared Podpora bezpečnosti až na úrovni buňky Read-write model o Mutlidimensional Podporuje multidimensionálního pohledu na data Star-, respektive snow-flake schéma Podpora více hierarchií o Information Schopnost zpracovat velké množství informací RAM a disk požadavky. Integrce s DWH

325 FASMI test BI platformy o Multidimensional Conceptual View o Intuitive Data Manipulation o Accessibility o Batch Extraction vs Interpretive o OLAP Analysis Models o Client Server Architecture o Transparency o Multi-User Support o Treatment of Non-Normalized Data o Storing OLAP Results o Extraction of Missing Values o Treatment of Missing Values o Flexible Reporting o Uniform Reporting Performance o Automatic Adjustment of Physical Level o Generic Dimensionality o Unlimited Dimensions & Aggregation Levels o Unrestricted Cross-dimensional Operations

326 Příklad o Metriky Počet prodaných knih Cena za prodané knihy o Dimenze Knihy Obchody Čas o Hierarchie Knihy Kniha typy knih vše Čas Den kalendářní měsíc kalendářní kvartál kalendářní rok celá historie Obchody Obchod hierarchická struktura podle ústředí vše

327 Příklad uložení

328 Multidimenzionální databáze o Nutné rozlišit Princip Práce s dimenzemi Práce s hierarchiemi Skutečný způsob uložení dat Relační model Speciální úložiště se speciálními indexy o Kategorizace dle místa uložení dat a agregací MOLAP veškerá data uložená v multidimenzionální databázi ROLAP veškerá data uložená v relační HOLAP hybrid o Další typy RTOLAP real time, data pouze v RAM DOLAP desktop OLAP, data uložená na klientském počítači

329 Příklady dodavatelů OLAP serverů o MS Analysis Services o IBM Cognos o Oracle OLAP option o Hyperion Essbase o Business Objects o MicroStrategy o SAS

330 Co si zapamatovat o Performance systému je často řešena denormalizací uložených dat o Základní typy denormalizace o Rozdíl mezi clustrovaným a neclustorvaným indexem, jejich výhody a nevýhody z pohledu DWH o Sloupcové uložení dat, výhody a nevýhody o Co to je OLAP výhody a nevýhody

331 Diskuse

332 Teradata basic UAI /14 RNDr. Ondřej Zýka,

333 Něco z historie o Založena v roce 1ř7ř v garáži v Kalifornii (Brentwood). o Teradata symbolizuje schopnost spravovat extrémní množství dat. o Primárně určena pro datové sklady a BI aplikace. o Založena na shared nothing architektuře umožňující lineární rozšiřitelnost. o V současnosti využívána v největších datových skladech V Česku KB, Česká pojišťovna, TO2,

334 Architektura Shared nothing Parsing engine (PE) BYNET AMP 1 AMP 2 AMP 3 AMP 4 RAM RAM RAM RAM

335 Komponenty o Parsing engine PE Parsuje a optimalizuje dotazy, předává požadavky jednotlivým AMPům o BYNET Komunikační kanál (duplikovaný) pro předávání požadavků a výsledků o AMP Access modul processor Zodpovědný za získání požadovaných dat z diskových úložišť o Diskový prostor Součet diskových prostorů všech AMPů

336 Fyzická architektura BYNET Node 1 with AMPs Node 2 with AMPs Node 3 with AMPs Node 4 with AMPs

337 Diskové prostory o Permanent space Limit na uživatele z limitu předchldce Data, indexy, fallback, Rovnoměrně distribuován na jednotlivé AMPy o Spool space Globální limit na uživatele Diskový prostor pro mezivýsledky Všechen nepřidělený prostor o Temp space Global temporary table

338 Přidělování diskového prostoru DBC 100 GB Celkem 1TB SYSDBA 300 GB INVENTORY 100 GB CUSTOMER 150 GB SALES 200 GB ORDERS 50 GB CAMPAIGN 100 GB

339 Distribuce dat o Distribuce dat založena na primárním indexu o Každý AMP má definovánu množinu hash hodnot primárního indexu o Další nástroje pro zrychlení přístupu k datům Secondary index Join index Statistics

340 Distribuce řádků tabulky Ano Ano Ano Ano Ne Ne Ne Ne

341 Indexy Primary index Secondary index Required Yes No Can be unique or nonunique Yes Yes Used for row distribution Yes No Create and drop dynamically No Yes Improve access Yes Yes Required separate physical strucure Required extra processing overhead No No Yes Yes

342 Podpora dostupnost o Transient Journal ídí transakce a rollback o Fallback Zabezpečení proti výpadku jednoho AMPu o Down AMP Journal Podpora zotavení AMPu při pádu

343 Fallback AMP 1 AMP 2 AMP 3 AMP 4 Fallback

344 Nástroje a služby o Nástroje správy odpovídají stáří databáze. o Systém primárně zaměřen na výkon. o Nemá vlastní nástroje na prezentaci a analýzu dat spolupracuje se všemi velkými hráči na trhu Microstrategy, Cognos, Oracle BI, SAP BusinessObject, Microsoft Reporting services.

345 Industriální logické modely o Teradata Communications Logical Data Model o Teradata Financial Services Logical Data Model o Teradata Healthcare Logical Data Model o Teradata Insurance Logical Data Model o Teradata Manufacturing Logical Data Model o Teradata Media Logical Data Model o Teradata Retail Logical Data Model o Teradata Transportation and Logistics Logical Data Model o Teradata Travel and Hospitality Industry Logical Data Model o Teradata Utilities Logical Data Model

346 Aplikace podle obchodních požadavků o Kumulovaná zkušenost ze stovek projektů datových skladů a projektů BI. o Obsah jednotlivých modelů: Více úrovní pohledu Konceptuální pohled, Funkční oblasti (Kontrakt, Účet, Kanál, Událost, Kampaň, Party, Produkt, ), Detailní logický model. Podrobný popis jednotlivých entit včetně atributů a relací, jejich význam a použití. Textový popis i modely.

347 Aplikace podle obchodních požadavků o Business Intelligence o Data Mart Consolidation o Master Data Management o Tax and Revenue Management o Customer Relationship Management o Data Mining and Analytics o Enterprise Risk Management o SAP Integration o Data Governance o Data Warehouse Migration o Financial Management

348 Co si zapamatovat o Jakou architekturu používá systém Teradata o Popište hlavní komponenty systému Teradata o Jaký je rozdíl mezi primárním klíčem a primárním indexem

349 Diskuse

350 Reporting UAI /14 RNDr. Ondřej Zýka,

351 Co to je report o Základní interface uživatelů k datům a informacím Tabulka Kontingenční tabulka Graf Pokročilá analýza

352 Vytvoření/úprava reportovacího prostředí o Zjistit uživatelé a jejich požadavky Typy Způsob použití Způsob doručení o Revize datové základna GAP analýza Metadata o Současně používané reporty o Popisy metriky a dimenzí Návrh datamartů Matadatové vrstvy, kostek o Definice grafických prvků o Návrh technologií o Proces vývoje a implementace o Proces správy reportovacího prostředí

353 Uživatelé o Uživatelské skupiny

354 Požadavky uživatelů o Uživatelé Množství uživatelů Uživatelské skupiny Operativní reporting Dashboardy Scorecards Analýzy Události o Srozumitelnost o Rychlost dodání Nového reportu Dat o Bezpečnost Přístup k datům Přístup k vytvořeným reportům Přístup k systému o Uložení reportů Repository Správa o Formáty o Způsoby doručení o Metadata Použití reportů Dostupnost reportů Popis informací Popis zdrojů reportu o Vývoj Vlastní reporty Konfiguace z předpřipravených komponent Metodiky Proces vývoje Technologie Testování o Různé zdroje dat

355 Revize datové základny o Dostupnost dat Datové zdroje Vlastníci a správci dat Popis dat o Nutnost přípravy agregovaných dat Datamarty OLAP kostky Agregované tabulky o Relační databáze Oracle, Teradata, MS SQL, Sybase, MySQL, Netezza, ODBC, o Dimenzionální zdroje Cognos OLAP, SAP BW, Microsoft analytic servises, EssBase, Oracle, o ERP systémy SAP, PeopleSoft, Siebel, o Moderní datové zdroje XML, Java Beans, JDBC, LDAP, WSDL, o Ostatní zdroje Excelu/Access bush, CSV soubory, textové soubory,

356 Současné reporty o Vlastníci Zodpovědnost za správnost Vlastník není uživatel o Definice Popis reportu na byznys a technické úrovni Může být součástí technologie (Cognos) Excel sheet není dostatečnou definicí Jednodušší je vývoj z nuly o Verze Existuje více verzí používaných lokálně Historické verze reprotu o Příklady Grafika Velikost dat Čitelnost a srozumitelnost

357 Hierarchie reportů o Od souhrnných reportů k detailním analýzám o Udržení jednotných faktů a dimenzí o Granularita odpovídající potřebám uživatelů o Podpora grafickými prvky a formátem

358 Hierarchie reportů

359 Metriky a dimenze o Definice na základě existujících metrik a dimenzí DWH Datamarty Metadata o Nově definované podle potřeb reportů Pro stabilní reporty nutno propojit na podnikové definice Může vést ke rozšíření DWH prostředí o nové zdroje Pra Ad-hoc analýzy nebývá potřeba (externí zdroje dat) o Metriky Granularita Předpočítané metriky o Dimenze Hierarchie Konformní a odvozené dimenze

360 Technologie o Nejrozšířenější Microsoft Excel (Microsoft BI řešení) o Zavedení dodavatelé SAP Business Object Microstrategy IBM Cognos SAS institute Oracle Business Intelligence Discoverer o Inovátoři QlikTech (QlikView) GoodData o Opensource Tableau JasperSoft

361 Gartner Magic Quadrant for Business Intelligence Platforms

362 Technologie o Ověřená škálovatelnost do named uživatelů o Plugin do portálů o Tisíce reportů o Plně publikované webové rozhraní SDK o Jednotná metadatová vrstva pro všechny typy reportů o Dodávka a export reportů o Podpora vývoje a verzování

363 Architektura o Místo uložení dat o Místo uložení definic a metamodelu (Univerza) o Místo výpočtu reportů a mezivýsledků o Datový server o Reporting server Dedikovaný server Uložení v databázi u dat o Klient Tlustý klient Webový klient Excell o Přenosové pásmo Data Reporting server Reporting server Klient Data Klient o Uložení výsledků Na serveru Na klientovi

364 Grafické prvky o Jednotný vzhled o Grafický manuál o Stejné a stejně umístěné ovládací prvky Nadpisy Stránkování Drill-down, Drill-up Stejný layout obdobných reportů Stejné grafické prvky a barevné škály

365 Grafické prvky o Záhlaví o Tabulka Schvalování (ve dnech) Období Min. 95 Perc. Median SLA 2011/ / / / / / / / / / / / /

366 Grafické prvky Executive Dashboard Utilizovaná kapacita - Trend účinnost ů NAO Celková kapacita Utilizovaná kapacita Nevyužitá kapacita v % 25.0% 20.0% 15.0% 10.0% 5.0% 0.0% 100.0% Kvadrant Sigma x Účinnost procesů NAO (MTD) o Trend o Porovnání Účinnost procesu (v %) 90.0% 80.0% 70.0% 60.0% Administration Documentation Approving Administration (Follow Sign.) Draw-Down 50.0% 40.0% Úroveň Sigma (σ) Objem nákladů

367 Scorecarding o Dodává informace pochopitelné na první pohled. Místo podrobných reportů několik málo charakteristik odpovídající kritickým oblastem výkonnosti organizace. o Vypovídá o plnění strategie a dosahování cílů vždy plán versus cíle. Shrnuje důležité informace, klíčové drivery, výkonnostní očekávání a dosažené výsledky. o Zvyšují zodpovědnost poskytují uživatelům informace potřebné pro řízení vlastní výkonnosti, úspěšnosti použitých strategií a měření úspěchu. Alerty při výkyvech. o Metriky ukazují závislost výkonu oddělení na ostatních částech podniku, podporuje spolupráci. o Umožňuje metodologii Balanced Scorecard

368 Dashboard o Jednotný pohled spojující všechny informace. o Nepřetržitě refrešované pohledy na reálná data vypovídající o aktuálních procesech. o Propojení na reporty s podrobnou informací. o Spojení dat z různých oblastí obchod, marketing, finance, HR, logistika, distribuce do jednotného obrazu spojujícího všechny oddělení. o Vypovídající grafika 2D, 3D grafy, mapy, animace o Předpřipravené, nevyžadují uživatelská modifikace nebo zadávání parametrů.

369 Dashboard Navigation: Executive Dashboard Core Process Dashboard NAO Process Sec. Loans Applications Process Dashboard Admin. of Sec. Loans Applications Period: February 2012 February 2012 More... More... Comments More... More... Generating time: 2012/02/20 10:12 Page 1 of 1 Data confidence: Limited use Data provided by: Operations

370 Proces vývoje reportu 1. Určení vlastníka Kdo odpovídá za definici Kdo bude testovat dodávku Kdo bude platit vývoj 2. Důvod vzniku Jaký proces podpoří Pro jaké rozhodnutí je nutný Kdo bude report používat 3. Definice obsahu Data Fakta Dimenze Granularita 4. Ověření existence reportu Nepoužívá někdo už takový report? Nepoužívá někdo obdobný report, který by šel upravit? Odpovídají definice termínům používaným v jiných reportech? Neshromažďuje již někdo požadované informace? Nepočítá už někdo požadovaná čísla? Co z již hotového je možné použít?

371 Proces vývoje reportu 5. Definice reportu Grafika Report automatization Filtry Hierarchie Uživatelsky definované parametry Způsob dodání reportu Plánování výpočtů 6. Příprava dat Nalezení dat v systémech Konsolidace dat Konsolidace v jednom úložišti (DWH) Definice dat Integrace dat ETL procesy Agregace dat a plán výpočtů 7. Vytvoření reportu Vytvoření potřebných artefaktů v reportovacích nástrojích

372 Proces vývoje reportu 8. Technologický test Schopnost dodat data v požadovaných frekvencích a časech Schopnost zpracovat data (všechna data) Schopnost vygenerovat report Schopnost dodat report uživatelům 9. Test dat a informací Dává report správné výsledky? Jsou výsledky srozumitelné uživatelům? Má report odpovídající vypovídací schopnost? 10. Dokumentace Doplnění metadat Zanesení reportu do Report katalogu Vývojová dokumentace Uživatelská dokumentace Administrátorská dokumentace 11. Nasazení do produkce Dodávka na produkční prostředí Akceptační testy Data, procesy, všechny artefakty Informace uživatelů Školení uživatelů

373 Procesy správy reportovacího prostředí o Nastavování přístupových práv o Sledování výkonnosti o Sledování používání reportů o Odstraňování starých výsledků o Incident management o Zálohování prostředí

374 Co si zapamatovat o Struktura reportovacího systému a jeho vazba na organizační strukturu o Základní typy reportů o Požadavky uživatelů o Komponenty reportovacího prostředí o Grafický manuál a jeho složky o Proces vývoje reportu

375 Diskuse

376 Data Mining UAI /14 RNDr. Ondřej Zýka,

377 Data Mining o Mnoho názvů pro to samé Data mining Knowledge discovery in databases Data exploration Advance analyses o Data mining je především Predikční a analytický nástroj, který se na základě historických dat snaží o hledání hlubších souvislostí (a jejich promítnutí do budoucnosti). Funguje na úrovni jednotlivých objektů. Typické otázky, na které Data mining umí odpovědět: Kteří klienti pravděpodobně uzavřou pojištění v příštích 6 měsících? Jaká je charakteristika klientů, kteří pojištění pravděpodobně uzavřou?

378 Data mining o Data mining je proces počítačového zpracování (velkého) objemu dat a vyhledání netriviálních, neznámých závislostí v datech. o Proces data miningu se skládá z několika kroků a středem procesu je tvorba modelu dat a jeho použití. Model je zde černá krabička, která na vstupu přijímá vstupní data a z nich model vypočítá odpověď (výstup). Před použitím musíme nastavit vnitřní parametry modelu. Tomuto procesu se říká učení. K učení potřebujeme trénovací data dvojice vstupní data a odpovídající výstup a snažíme se změnit vnitřní parametry modelu, tak aby model dával správné výstupy. Model se pokusí naučit vše co mu předložíme v průběhu trénování -> je potřeba pečlivě vybírat trénovací množinu!

379 Data mining proces Porozu ění problematice Definování hypotéz Porozu ění dat Dostupnost a obsah Příprava dat For át, integrace Dodávka řešení Data Vý ěr odelů Modelování Vyhodnocování výsledků

380 Model o Základní pojem Data Miningu o Na základě vstupních hodnot Historická data Vzorek dat Předzpracovaní data o Odvozuje Parametry Algoritmy o Výstupní hodnoty Charakterizace Atributy Model Vstupy Výstupy

381 Typy modelů o Analytický srozumitelný model o Vysvětlitelný postup a způsob získání výsledků Vstupy Výstupy o Učící se konstrukce umělé inteligence o Těžko vysvětlitelný postup získání výstupů Vstupy Black box Výstupy

382 Metody Data Miningu o Mnoho různých metod Potřeba znalosti jejich možností a vhodnosti Nestačí znalost analytického nástroje Nutnost vazby na kontext o Typy analýz Klasifikace Regrese Predikce Shlukování Hledání anomalit Text Mining o Další metody Rozhodovací stromy Klasifikační pravidla Asociační pravidla

383 Klasifikace o Zařazení objektu do některé z předem známých kategorií. o Pro každou kategorii je potřeba dostatek příkladů (objektů). Zůstane zákazník u naší společnosti i za 6 měsíců? Nebo uvažuje o změně? Jaká je diagnóza pacienta? Jedná se v této pojistné události o podvod? Zareaguje klient na reklamní nabídku? Bude klient splácet půjčku nebo ne?

384 Regrese o Přiřazení spojité hodnoty objektu. o Na rozdíl od klasifikace se snažím odhadnout přesnou hodnotu spojité veličiny. (Lineární regrese) Predikce ceny zboží na burze. Predikce přenesených dat v síti, zítra dopoledne. Odhad stáří stáří jedince v okamžiku smrti z kosterních pozůstatků. Jakou mám dát slevu, pokud poprvé prodávám zboží malé firmě do Německa a mám dva konkurenty.

385 Shlukování o Seskupování objektů do skupin podle vzájemné podobnosti. o Nepotřebuji znát dopředu, které objekty patří dohromady (to metody zjistí samy), ale potřebuji být schopen určit jejich podobnost. Nalezení skupin podobných zákazníků. Tyto skupiny pak pravděpodobně budou chovat podobně. Potvrzení, že v datech jsou odlišitelné skupiny (a další data miningové metody, například klasifikace, mohou uspět).

386 Další metody data miningu o Výběr důležitých vlastností nalezení parametrů, které mají velký vliv na finální rozhodnutí (u klasifikace a regrese). Mají opravdu všechny sledované parametry stejný vliv na výsledek? Musíme se všemi zabývat? Podobnost s korelací. Má fakt, že prší, vliv na objem dat přenesený po síti? o Asociační pravidla a časté množiny objekty, které se často vyskytují dohromady. hledání zboží, které zákazníci často nakupují společně. Stránky, které návštěvníci webu prohlížejí v jednom sezení. o Pokud zákazník koupí dětské plenky, je 70% pravděpodobnost, že koupí i pivo.

387 Další metody data miningu (2) o Hledání anomalit hledání objektů, které se svými parametry vymykají průměru. Zákazník se chová výrazně jinak, než ostatní zákazníci. Po přihlášení do systému zákazník provedl jiné akce, než dělá obvykle (spustil jiné akce, přihlásil se z neobvyklé IP adresy,...) o Textmining získávání znalostí z volného textu. Primárně skupina metod, jak převést volný text do formy vhodné pro data mining (například pro shlukování / klasifikaci). Například automatické třídění elektronické pošty podle textu zprávy. Vyhledávání zmínek o společnosti v internetových diskusích a klasifikace, jestli je zmínka pozitivní nebo negativní.

388 Vizualizace o Vizualizace zobrazování dat v různých pohledech, obarvení. Vizualizační techniky jsou důležitou součástí analýzy dat a inspekce výsledků data miningu.

389 Rizika o Informace potřebné k správnému závěru (predikci) nejsou v datech přítomné. Lékař, který rozhoduje o léčbě citem a zkušenostmi, než podle přesných výsledků testů. Data z internetového bankovnictví nestačí k identifikaci neobvyklých transakcí. o Málo příkladů a protipříkladů pro jednotlivé třídy. Naprostá většina zaměstnanců pracuje poctivě a (odhalených) podvodníků je minimum. (Málo příkladů podvodníků pro tvorbu modelu podvodníka ). o Snaha o predikci mimo oblast dat použitých k vytvoření modelu. Snaha předpovědět cenu produktu pro region, kam jsem ještě nikdy nic neprodal. o Špatné pochopení business problému (špatné zadání).

390 Shrnutí o Mnoho metod znalost problematiky velmi pomáhá Výsledky se dají získat i z anonymizovaných dat, interpretace je složitější o Často jsou dostatečné jednoduché řešení o Většina algoritmů je už naprogramována složité je rozhodnout jak je využít jak interpretovat výsledky o Historická data jsou nutná

391 Příklady

392 Zneužití přístupových údajů do internetového bankovnictví o Klienti banky mají možnost využívat internetového bankovnictví. Klienti pro autorizaci používají přístupové údaje (jméno, heslo). o Otázka: nezneužil někdo přístupové údaje? o Předpoklad pro úspěšnou detekci klient má jeden/několik vzorů chování, které opakuje. například sekce, které v internetovém bankovnictví navštěvuje, místa, ze kterých se přihlašuje. o Předpoklad na data: dostatečně dlouhá historie přístupů klienta, tak aby bylo možné najít často prováděné akce. o Přístup hledání anomálií. o Výsledkem je množina podezřelých přístupů. Podezřelý neznamená automaticky podvodný, ale zvláštní a potřeba prověřit, co se děje. Klient odjel na dovolenou a potřebuje zaplatit inkaso.

393 Doporučování obsahu o Obchodník chce zjistit, které položky zákazníci nakupují společně. o Podle aktuálního obsahu nákupního košíku, nalézt zboží (službu), kterou by mohl zákazník také chtít. Internetový obchod nabízející zboží. U každé zobrazené položky zobrazuje další zboží, které zákazníci v minulosti nakoupili se zobrazenou položkou. o Předpoklad: zákazníci nakupují stále stejné kombinace zboží (služeb). o Předpoklad na data: historie zakoupených položek. o Přístup časté množiny a asociační pravidla. o Výsledkem je pak množiny zboží, které zákazníci nakupují dohromady. Mohu zákazníkovi přímo nabízet zboží, o které by mohl také mohl koupit. Informace o se také dá využít v marketingu (například zlevnit jeden druh zboží a výšit tak prodej spojeného druhu zboží). o Amazon.com o Tesco

394 Vyhledávání klientů, kteří chtějí odejít o Telefonní operátor chce identifikovat klienty, kteří chtějí odejít. o Klasifikace na klienty, kteří v horizontu 3 měsíců: chtějí odejít a chtějí zůstat. o Předpoklad: klienti, kteří chtějí přejít k jinému operátorovi změní před odchodem své návyky a vzor se před odchodem opakuje (například začínají méně volat, posílat méně SMS). o Předpoklad na data: máme historické záznamy o klientech, kteří již odešli a také o těch, kteří zůstali (pro tvorbu modelu). Dále potřebujeme historii současný klientů pro hledání klientů, kteří chtějí odejít. o Přístup klasifikace. o Výsledkem je seznam klientů, kteří by mohli v budoucnu odejít. Těmto může operátor například nabídnout slevu nebo speciální tarif, aby si je udržel.

395 Porovnání modelů pro churn

396 Churn rozložení segmentace Vysoké útraty Nízké útraty Přeplatek Přes tarif Aktivní V rá ci tarifu Konzervativní