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

Rozměr: px
Začít zobrazení ze stránky:

Download "Správa dat v podniku. UAI635 2013/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 86) 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 Zákazníci a uživatelé ODS Operační data MDM Datová kvalita Integra ce DWH Jednotný model Kompletní historie Integrovaná data Byznys, technologická a provozní metadata Governance pravidla, organizační struktura, procesy

14 Prostředí datově orientovaného systému Etapy životního cyklu Komponenty Skupiny uživatelů Plánování Vývoj Testování Provozování Udržování Ukončení používání Aplikační programy Interface DBMS Data Hardware Vlastníci aplikace Architekti (IT, Aplikační, ) Datový architekt Vývojáři Administrátoři databází Systémoví administrátoři Koncoví uživatelé

15 Data management Data Management International

16 Data management o o o Pravidla Zodpovědnosti Pravidla pro vývoj Jmenné konvence Definice dat Bezpečnostní pravidla Požadavky na kvalitu dat Provozní pravidla Procesy Plánovací Řídící Vývoj Provoz 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 Datová kvalita UAI /14 RNDr. Ondřej Zýka,

25 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

26 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.

27 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

28 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.

29 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ů

30 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

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

32 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 informace k dispozici nebo snadno získatelné Zda velikost dat a jejich granularita odpovídá vykonávaným úlohám Zda jsou informace pokládány za pravdivé a důvěryhodné Zda žádná data nechybí a zda jsou dostatečné rozsáhlá a detailní pro vykonávané úlohy Zda reprezentace dat má vhodnou strukturu Zda jsou data reprezentována vždy ve stejném formátu Zda jsou informace snadno zpracovatelné a použitelné pro rozdílné úlohy Zda jsou informace a data přesné a hodnověrné Zda je jasná definice informací, zda jsou v odpovídajícím jazyku, jednotkách a zda jsou označeny správnými symboly Zda jsou informace nestranné a nepředpojaté Zda jsou informace použitelné a užitečné pro vykonávané úlohy Zda jsou informace považovány za spolehlivé v souvislosti s jejich zdrojem nebo obsahem Zda omezení přístupu k datům a informacím odpovídá bezpečnostním pravidlům Zda jsou pro vykonávané úlohy informace k dispozici včas Zda jsou informace snadno pochopitelné a srozumitelné Zda a která data a informace jsou přínosné a jaké jsou výhody jejich použití

33 DQ issues Management a Finance Marketing Vlastníci systémů IT Nutnost udržovat velké finanční nebo technické rezervy Nepřesná segmentace zákazníků Duplicity v datech Vysoká náročnost nalezení požadovaných informací Nekonzistentní reporty napříč organizací Drahé a neúčinné kampaně Nekonzistence mezi systémy Nemožnost dohledání původu dat a zodpovědných pracovníků Reporty s nedůvěryhodnými daty Nízká kvalita služeb pro zákazníky Chybějící nebo nedohledatelné údaje Nespokojenost uživatelů s dodávanými informacemi Rozhodnutí učiněná na základě špatných informací Nepořádek v zákaznických datech Zastaralé informace Neschopnost řešit konzistentně vady v datech

34 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?????

35 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

36 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

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

38 Data Profiling

39 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

40 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 %

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

42 Solvency II - requirements

43 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

44 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í

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

46 Chybějící metadata

47 Doplněná metadata

48 Co o metadatech říkají autority Řízení metadata je nepochybně nejdůležitější z dvanácti schopností, které musí mít BI aplikace

49 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

50 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ů

51 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

52 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

53 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

54 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í

55 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čů.

56 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:

57 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í ISO88592 na kódování UTF8? Pokud místo Y/N začneme používat A/N, co všechno musíme zkontrolovat?

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

59 Cíle správy metadata? 1. Jak je pojem definován? 2. Odkud se vzala data? Controllers Auditors 3. Jak jsou data aktuální? Managers? 1. Co vše musím upravit při změně zdrojového systému? Analysts Developers Architects 2. Které všechny reporty musím opravit, když změním definici sloupce? 3. Co se stane, když havaruje toto ETL?

60 Řízení metadat Byznys slovník Datové modely Procesní modely Organizační struktura SAP Oracle Databáze Teradata Definice Aplikace Cognos SaS Busines Objects Oracle BI Reporting Transfor mace ETL Skripty SOA File transfer

61 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

62 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í

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

64 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.

65 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

66 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

67 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, )

68 Š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 Programovací jazyk Java, C#, VB, C/C++ klikací XML o Podpora pro analýzu UML - Unified Modeling Language Designery třetích stran

69 Ú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ů

70 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

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

72 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

73 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

74 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

75 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

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

77 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í

78 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

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

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

81 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í

82 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)

83 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

84 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

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

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

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

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

89 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

90 Master Reference Data Zdroj A Datová integrace Automatické dávkové nebo realtime zpracování. Čištění, integrace, Standardizace, Zdroj B Data Warehouse Exceptions Zdroj C Správa výjimek

91 Master System of Record Zdroj A Datová integrace Automatické dávkové nebo realtime zpracování. Čištění, integrace, Standardizace, Zdroj B Master Databáze Zdroj C Správa výjimek Nové aplikace

92 Master Registry Datová integrace Automatické dávkové nebo realtime zpracování. Čištění, integrace, Standardizace, Zdroj A Zdroj B Zdroj C Registr vazeb Správa výjimek Nové aplikace

93 Synchronization Zdroj A Datová integrace Automatické dávkové nebo realtime zpracování. Čištění, integrace, Standardizace, Zdroj B Zdroj C Správa výjimek

94 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.

95 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ů

96 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

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

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

99 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í.

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

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

102 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

103 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

104 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

105 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)

106 Architektura

107 Zákazníci a uživatelé ODS Operační data MDM Datová kvalita Integra ce DWH Jednotný model Kompletní historie Integrovaná data Byznys, technologická a provozní metadata Governance pravidla, organizační struktura, procesy

108 Architektura DWH Stage Obraz vstupních dat Záloha dat pro zpracování Datová kvalita Jádro Jednotný model Kompletní historie Data Marty Podle analyzovaných procesů Dimenze a metriky Agregovaná data Scheduler a dohled

109

110 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

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

112 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í

113 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

114

115 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

116

117 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í

118

119

120 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

121 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.

122 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

123 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ů

124 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

125 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

126 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

127 Příklad Incident management tool

128 Gartner BI summit

129

130

131

132

133 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í

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

135 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)

136 Pravidla datového skladu # Popis 1 DWH je oddělen od primárních systémů 2 Data v datovém skaldu jsou integrovaná 3 DWH obsahuje historická data za dlouhý časový úsek. 4 DWH obsahuje snapshoty k přesně definovaným okamžikům. 5 Data v DWH jsou subjektově (nikoliv agendově) orientovaná. 6 DWH data jsou určena primárně ke čtení. Změny dat jsou jenom dávkové a primárně se jedná o insert dat. 7 Životní cyklus DWH je řízen daty (nikoliv procesy). 8 DWH obsahuje více úrovní granularity dat. 9 DWH očekává málo select operací nad velkými objemy dat. 10 DWH obsahuje systém pro vyhledávání zdrojů, transformací a místa uložení dat. 11 Metadata DWH obsahují popis všech datových prvků, zdroje, transformace, integrace, uložení, vazby a historii všech datových elementů. 12 DWH umožňuje přidělovat a zpoplatňovat využití svých zdrojů jednotlivými uživateli.

137 Zákazníci a uživatelé ODS Operační data MDM Datová kvalita Integra ce DWH Jednotný model Kompletní historie Integrovaná data Byznys, technologická a provozní metadata Governance pravidla, organizační struktura, procesy

138 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

139 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í

140 Enterprise architektura IT architektura Vazba strategie a architektury v podniku Byznys strategie IT strategie Byznys architektura Aplikační architektura Datová architektura Technologická architektura

141 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 měnící trh low margin business zákazník: dlouhodobý vztah zákazní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í

142 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ělen a saturován existuje odliv zákazníků náklady na nového zákazní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í

143 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í

144 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ů.

145 Zákazníci a uživatelé ODS Operační data MDM Datová kvalita Integra ce DWH Jednotný model Kompletní historie Integrovaná data Byznys, technologická a provozní metadata Governance pravidla, organizační struktura, procesy

146 OLTP x DWH OLTP systémy Aplikačně orientovaná Detailní data Přesné hodnoty, význam v době zpracování Slouží provozním pracovníkům Mnoho změn update Opakující se zpracování Předem známy a definovány požadavky na data a procesy Standardní vývojový cyklus aplikace Přístup k jednotlivým záznamu Orientace na transakce Datový sklad Předmětně orientovaná Agragovaná nebo vypočítávaní data Historie, data za období, snapshoty Slouží manažerům Zaznamenává se historie, update je nový záznam Časté ad-hoc analýzy Většina požadavků není předem známa Požadovaný agilní vývojový cyklus Přístup k velké množině záznamů najednou Orientace na analýzu

147 OLTP x DWH OLTP systémy Výkonnost je extrémně důležitá pro provoz organizace Práva vlastníků dat na změnu jsou důležitá Požadována vysoká dostupnost Spravuje se jako celek Redundance dat je nežádoucí (normalizované modely) Statická struktura, variabilní obsah Malé objemy dat Orientace na každodenní rutinu Datový sklad Volnější nároky na výkonnost (denní zpracování) Změna je prováděna technologickými uživateli Nižší požadavky na dostupnost Spravuje se po logických částech Redundance je běžná (denormalizované modely) Flexibilní struktura Velké objemy dat Orientace na analýzy a plánování

148 ODS x DWH ODS Integrovaná data Přebíraná data Orientace po oblastech Bez historie Změny v datech Bez agregace Transakční load dat Informační zdroj o záznamech Obousměrná komunikace DWH Integrovaná data Vyčištěná data Orientace po oblastech Kompletní historie Bez změn Agregovaná data Dávkový load dat Analytické aplikace Jednosměrná komunikace

149 Uživatelé systémů OLTP ODS DWH Provozní pracovníci Střední management Provozní pracovníci Klienti Partneři Střední management Vrcholný management

150 Vývoj složitosti DWH Big Data Analytické aplikace Analytické aplikace Data mining Data mining Data mining Multidimenzi onální analýza Multidimenzi onální analýza Multidimenzi onální analýza Multidimenzi onální analýza MIS MIS MIS MIS MIS Dotazy, Reporty, Dotazy, Reporty, Dotazy, Reporty, Dotazy, Reporty, Dotazy, Reporty, Dotazy, Reporty,

151 Architektura DWH Stage Obraz vstupních dat Záloha dat pro zpracování Datová kvalita Jádro Jednotný model Kompletní historie Data Marty Podle analyzovaných procesů Dimenze a metriky Agregovaná data Scheduler a dohled

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

153 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ší

154 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

155 Příklad konceptuální model FSLDM

156 Příklad struktura FSDM

157 Příklad logický model oblasti

158 Příklad doporučená struktura

159 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

160 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

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

162 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íčů

163 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)

164 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

165 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

166 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

167 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ě

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

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

170 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

171 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

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

173 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, )

174 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

175 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ů

176 Příklad návrh ETL- BizzTalk

177 Příklad grafické rozhraní Informatica

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

179 Příklad dohled zpracování

180 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

181 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ů

182 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

183 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 9. Záloha denního zpracování

184 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

185 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

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

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

188 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

189 Ú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í.

190 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í,

191 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)

192 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

193 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.

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

195 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.

196 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.

197 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í.

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

199 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

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

201 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.

202 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.

203 PARTY model - příklad

204 PARTY_ROLE jiný příklad

205 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))

206 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

207 Pattern: Klasifikace I

208 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

209 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.

210 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.

211 Pattern: Klasifikace II

212 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é.

213 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.

214 Pattern: Klasifikace III

215 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í.

216 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.

217 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.

218 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.

219 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

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

221 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

222 Příklad

223 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

224 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

225 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

226 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í

227 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

228 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

229 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)

230 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

231 Buss matrix

232 Date Customer Service Rate Category Local Svc Provider Calling Party Called Party Long Dist Provider Internal Organization Employee Location Equipment Type Supplier Item Shipped Weather Account status Bus matrix 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

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

234 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í

235 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)

236 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)

237 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

238 Č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í

239 Časová dimenze

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

241 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

242 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)

243 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

244 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

245 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

246 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

247 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

248 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

249 Příklad uložení

250 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

251 FASMI - Fast Analysis of Shared Multidimensional Information o Alternativní název pro OLAP reportingová prostředí o o o o 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ů 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ů Shared Podpora bezpečnosti až na úrovni buňky Read-write model Mutlidimensional Podporuje multidimensionálního pohledu na data Star-, respektive snow-flake schéma Podpora více hierarchií Information Schopnost zpracovat velké množství informací RAM a disk požadavky. Integrce s DWH

252 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

253 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

254 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

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

256 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í

257

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

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

260 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

261 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

262 Ř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;

263 Ř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);

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

265 Ř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;

266 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

267 Ř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;

268 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

269 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

270 Ř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;

271 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

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

273 Ř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

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

275 Ř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

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

277 Ř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

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

279 Ř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

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

281 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

282 Ř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)

283 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

284 Ř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

285 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

286 Ř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 9 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;

287 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é

288 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

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

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

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

292 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

293 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

294 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

295 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

296 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

297 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

298 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

299 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

300 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

301 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 )

302 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

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

304 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

305 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

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

307 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

308 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

309 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

310 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

311 Velikost databáze (GB) Sybase IQ uložení dat a indexů 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

312 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

313 FASMI - Fast Analysis of Shared Multidimensional Information o Alternativní název pro OLAP reportingová prostředí o o o o 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ů 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ů Shared Podpora bezpečnosti až na úrovni buňky Read-write model Mutlidimensional Podporuje multidimensionálního pohledu na data Star-, respektive snow-flake schéma Podpora více hierarchií Information Schopnost zpracovat velké množství informací RAM a disk požadavky. Integrce s DWH

314 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

315 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

316 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

317 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

318 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

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

320 Něco z historie o Založena v roce 1979 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,

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

322 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ů

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

324 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

325 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

326 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

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

328 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

329 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

330 Fallback AMP 1 AMP 2 AMP 3 AMP 4 Fallback

331 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.

332 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

333 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.

334 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

335 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

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

337 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

338 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í

339 Uživatelé o Uživatelské skupiny

340 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 o o o o o Uložení reportů Repository Správa Formáty Způsoby doručení Metadata Použití reportů Dostupnost reportů Popis informací Popis zdrojů reportu Vývoj Vlastní reporty Konfiguace z předpřipravených komponent Metodiky Proces vývoje Technologie Testování Různé zdroje dat

341 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,

342 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

343 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

344 Hierarchie reportů

345 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

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

347 Gartner Magic Quadrant for Business Intelligence Platforms

348 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í

349 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

350 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

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

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

353 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

354 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ů.

355 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

356 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?

357 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

358 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ů

359 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í

360 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

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

362 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?

363 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!

364 Data mining proces Porozumění problematice Definování hypotéz Porozumění dat Dostupnost a obsah Příprava dat Formát, integrace Dodávka řešení Data Výběr modelů Modelování Vyhodnocování výsledků

365 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

366 Typy modelů o Analytický srozumitelný model o Vysvětlitelný postup a způsob získání výsledků Vstupy a i e iωt 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

367 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

368 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?

369 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.

370 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).

371 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.

372 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í.

373 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.

374 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í).

375 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á

376 Příklady

377 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.

378 Doporučování obsahu o o o o o o o o Obchodník chce zjistit, které položky zákazníci nakupují společně. 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. Předpoklad: zákazníci nakupují stále stejné kombinace zboží (služeb). Předpoklad na data: historie zakoupených položek. Přístup časté množiny a asociační pravidla. 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ží). Amazon.com Tesco

379 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.

380 Porovnání modelů pro churn

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

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

Správa dat v podniku. MI-DSP 2013/14 RNDr. Ondřej Zýka, ondrej.zyka@profinit.eu Správa dat v podniku MI-DSP 2013/14 RNDr. Ondřej Zýka, ondrej.zyka@profinit.eu 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

Více

Metadata. MI-DSP 2013/14 RNDr. Ondřej Zýka, ondrej.zyka@profinit.eu

Metadata. MI-DSP 2013/14 RNDr. Ondřej Zýka, ondrej.zyka@profinit.eu Metadata MI-DSP 2013/14 RNDr. Ondřej Zýka, ondrej.zyka@profinit.eu Co to jsou metadata Chybějící metadata Doplněná metadata Co o metadatech říkají autority Řízení metadata je nepochybně nejdůležitější

Více

Datová kvalita. RNDr. Ondřej Zýka

Datová kvalita. RNDr. Ondřej Zýka Datová kvalita RNDr. Ondřej Zýka 1 Datová kvalita Jedna z kompetencí Data managementu Cíl: Zajistit uživatelům data v kvalitě potřebné k jejich činnosti Kvalita dat: Subjektivní pojem závislý na požadavcích

Více

Správa dat v podniku. RNDr. Ondřej Zýka

Správa dat v podniku. RNDr. Ondřej Zýka Správa dat v podniku RNDr. Ondřej Zýka 1 Obsah 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 Datová kvalita

Více

Integrace dat. MI-DSP 2013/14 RNDr. Ondřej Zýka, ondrej.zyka@profinit.eu

Integrace dat. MI-DSP 2013/14 RNDr. Ondřej Zýka, ondrej.zyka@profinit.eu Integrace dat MI-DSP 2013/14 RNDr. Ondřej Zýka, ondrej.zyka@profinit.eu 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

Více

Integrace dat. RNDr. Ondřej Zýka

Integrace dat. RNDr. Ondřej Zýka Integrace dat RNDr. Ondřej Zýka 1 Obsah Kategorizace integračních přístupů Kroky integrace a řešení problematických stavů Master Data Management 2 2 Datová integrace Synchronní Akceptovaný požadavek na

Více

Datová kvalita. RNDr. Ondřej Zýka

Datová kvalita. RNDr. Ondřej Zýka Datová kvalita RNDr. Ondřej Zýka 1 Datová kvalita Jedna z kompetencí Data managementu Cíl: Zajistit uživatelům data v kvalitě potřebné k jejich činnosti Kvalita dat: Subjektivní pojem závislý na požadavcích

Více

Metadata. RNDr. Ondřej Zýka

Metadata. RNDr. Ondřej Zýka Metadata RNDr. Ondřej Zýka 1 Metadata Jedna z kompetencí Data managementu Cíle kompetence: Zajistit jednotné porozumění a užití termínů Provázat informace na různých úrovních (byznys, aplikační, technické)

Více

Integrace dat. RNDr. Ondřej Zýka

Integrace dat. RNDr. Ondřej Zýka Integrace dat RNDr. Ondřej Zýka 1 Obsah Kategorizace integračních přístupů Kroky integrace a řešení problematických stavů Master Data Management 2 2 Datová integrace Synchronní Akceptovaný požadavek na

Více

Databázové patterny. MI-DSP 2013/14 RNDr. Ondřej Zýka, ondrej.zyka@profinit.eu

Databázové patterny. MI-DSP 2013/14 RNDr. Ondřej Zýka, ondrej.zyka@profinit.eu Databázové patterny MI-DSP 2013/14 RNDr. Ondřej Zýka, ondrej.zyka@profinit.eu Obsah o Co je databázový pattern o Pattern: Přiřazení rolí o Pattern: Klasifikace Databázové patterny o Odzkoušené a doporučené

Více

Databázové patterny. RNDr. Ondřej Zýka

Databázové patterny. RNDr. Ondřej Zýka Databázové patterny RNDr. Ondřej Zýka 1 Co to je databázový pettern 2 Databázové patterny Odzkoušené a doporučené způsoby, jak řešit často se vyskytující požadavky Jednoduché N-ární relace Dědičnost Katalog

Více

Datová kvalita základ úspěšného BI. RNDr. Ondřej Zýka, Profinit

Datová kvalita základ úspěšného BI. RNDr. Ondřej Zýka, Profinit Datová kvalita základ úspěšného BI RNDr. Ondřej Zýka, Profinit 1.6.2012 Datová exploze Snižování nákladů o Zdvojnásobení objemu podnikových dat každé dva roky o Konkurenční tlak o Ekonomická krize o V

Více

Information and Data Management. RNDr. Ondřej Zýka

Information and Data Management. RNDr. Ondřej Zýka Information and Data Management RNDr. Ondřej Zýka 1 Informační a datový management Disciplína zaměřená na správu informací (z mnoha zdrojů) a spřístupnění informací různým typům uživatelů podle jejich

Více

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

Správa dat v podniku. UAI635 2013/14 RNDr. Ondřej Zýka, ondrej.zyka@profinit.eu Správa dat v podniku UAI635 2013/14 RNDr. Ondřej Zýka, ondrej.zyka@profinit.eu 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

Více

Obsah Úvod 11 Jak být úspěšný Základy IT

Obsah Úvod 11 Jak být úspěšný Základy IT Obsah Úvod 11 Jak být úspěšný 13 Krok 0: Než začneme 13 Krok 1: Vybrat si dobře placenou oblast 14 Krok 2: Vytvořit si plán osobního rozvoje 15 Krok 3: Naplnit osobní rozvoj 16 Krok 4: Osvojit si důležité

Více

Business Intelligence

Business Intelligence Business Intelligence Josef Mlnařík ISSS Hradec Králové 7.4.2008 Obsah Co je Oracle Business Intelligence? Definice, Od dat k informacím, Nástroj pro operativní řízení, Integrace informací, Jednotná platforma

Více

Infor Performance management. Jakub Urbášek

Infor Performance management. Jakub Urbášek Infor Performance management Jakub Urbášek Agenda prezentace Stručně o produktu Infor PM 10 Komponenty Infor PM - PM OLAP a PM Office Plus Reporting Analýza Plánování / operativní plánování Infor Performance

Více

CPM/BI a jeho návaznost na podnikové informační systémy. Martin Závodný

CPM/BI a jeho návaznost na podnikové informační systémy. Martin Závodný CPM/BI a jeho návaznost na podnikové informační systémy Martin Závodný Agenda Význam CPM/BI Aplikace CPM/BI Projekty CPM/BI Kritické body CPM/BI projektů Trendy v oblasti CPM/BI Diskuse Manažerské rozhodování

Více

Srovnání SQL serverů. Škálovatelnost a výkon. Express Workgroup Standard Enterprise Poznámky. Počet CPU 1 2 4 bez limitu Obsahuje podporu

Srovnání SQL serverů. Škálovatelnost a výkon. Express Workgroup Standard Enterprise Poznámky. Počet CPU 1 2 4 bez limitu Obsahuje podporu Srovnání SQL serverů Škálovatelnost a výkon Počet CPU 1 2 4 bez limitu Obsahuje podporu RAM 1 GB 3 GB bez limitu bez limitu vícejádrových (multicore) procesorů 64-bit podpora Windows on Windows (WOW) WOW

Více

Databáze v praxi. RNDr. Ondřej Zýka Principal Consultant

Databáze v praxi. RNDr. Ondřej Zýka Principal Consultant Databáze v praxi RNDr. Ondřej Zýka Principal Consultant Agenda Obsah Představení Teradata Teradata Databáze Doménové logické modely MS SQL Server Databáze Podpora BI Aktuální směry ve vývoji databází Profinit

Více

<Insert Picture Here> Hyperion a vazba na reportovací nástroje

<Insert Picture Here> Hyperion a vazba na reportovací nástroje Hyperion a vazba na reportovací nástroje Martin Grof Senior Konzultant, Oracle Czech Agenda Enterprise Performance management Představení funkčních oblastí realizace úspor Priority

Více

Zkušební test. Kdy se začala formovat koncept relačních databází (Vznik relačního modelu, první definice SQL)? a) 1950 b) 1960 c) 1970 d) 1980

Zkušební test. Kdy se začala formovat koncept relačních databází (Vznik relačního modelu, první definice SQL)? a) 1950 b) 1960 c) 1970 d) 1980 Zkušební test Gen Student: Ročník: Datum: Propozice: Pokud otázka nabízí výběr z více možností, více než jedna odpověď může být správná. Označte všechny správné možnosti. Pokud otázka vyžaduje slovní odpověď,

Více

DATABÁZOVÉ SYSTÉMY. Metodický list č. 1

DATABÁZOVÉ SYSTÉMY. Metodický list č. 1 Metodický list č. 1 Cíl: Cílem předmětu je získat přehled o možnostech a principech databázového zpracování, získat v tomto směru znalosti potřebné pro informačního manažera. Databázové systémy, databázové

Více

GTL GENERATOR NÁSTROJ PRO GENEROVÁNÍ OBJEKTŮ OBJEKTY PRO INFORMATICA POWERCENTER. váš partner na cestě od dat k informacím

GTL GENERATOR NÁSTROJ PRO GENEROVÁNÍ OBJEKTŮ OBJEKTY PRO INFORMATICA POWERCENTER. váš partner na cestě od dat k informacím GTL GENERATOR NÁSTROJ PRO GENEROVÁNÍ OBJEKTŮ OBJEKTY PRO INFORMATICA POWERCENTER váš partner na cestě od dat k informacím globtech spol. s r.o. karlovo náměstí 17 c, praha 2 tel.: +420 221 986 390 info@globtech.cz

Více

Obsah. Kapitola 1. Kapitola 2. Kapitola 3. Úvod 9

Obsah. Kapitola 1. Kapitola 2. Kapitola 3. Úvod 9 Obsah Úvod 9 Kapitola 1 Business Intelligence, datové sklady 11 Přechod od transakčních databází k analytickým..................... 13 Kvalita údajů pro analýzy................................................

Více

Aplikace IS, outsourcing, systémová integrace. Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/

Aplikace IS, outsourcing, systémová integrace. Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/ Aplikace IS, outsourcing, systémová integrace Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/ Kontext Dodavatelé Strategická Zákazníci ERP Taktická Operativní Kategorie ERP - zaměřeno na

Více

Aplikace IS, outsourcing, systémová integrace. Jaroslav Žáček

Aplikace IS, outsourcing, systémová integrace. Jaroslav Žáček Aplikace IS, outsourcing, systémová integrace Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/ Kontext Dodavatelé Strategická Zákazníci Taktická Operativní Kategorie ERP - zaměřeno na řízení

Více

IBM Tivoli Storage Manager 6.2 a IBM Tivoli Storage Manager FastBack 6.1.1

IBM Tivoli Storage Manager 6.2 a IBM Tivoli Storage Manager FastBack 6.1.1 IBM Tivoli Storage Manager 6.2 a IBM Tivoli Storage Manager FastBack 6.1.1 Reporting a Monitoring Ondřej Bláha CEE+R CoP Team / Tivoli Storage Team Leader Září 2010 2010 IBM Corporation TSM 6: Reporting

Více

Řešení datové kvality prostřednictvím Master Data Managementu v prostředí České pošty s.p.

Řešení datové kvality prostřednictvím Master Data Managementu v prostředí České pošty s.p. Řešení datové kvality prostřednictvím Master Data Managementu v prostředí České pošty s.p. Ing. Jiří Barták Vedoucí odboru BI SAS Roadshows 2017 Ovládejte a chraňte svá data v době digitální transformace

Více

Reportingová platforma v České spořitelně

Reportingová platforma v České spořitelně Reportingová platforma v České spořitelně Agenda Implementované prostředí Cognos 8 v ČS Marek Varga, Česká spořitelna, a.s. Využití platformy Cognos z pohledu businessu Petr Kozák, Česká spořitelna, a.s.

Více

KIV/SI. Rozílová témata. Jan Valdman, Ph.D. jvaldman@dns.cz

KIV/SI. Rozílová témata. Jan Valdman, Ph.D. jvaldman@dns.cz KIV/SI Rozílová témata Jan Valdman, Ph.D. jvaldman@dns.cz 13.6.2011 Integrace Datová vrsta Přesouvání informací mezi DB Databová pumpa, SQL procedura... Problém: pouze relační integrita, záruka za aplikaci

Více

01. Kdy se začala formovat koncept relačních databází (Vznik relačního modelu, první definice SQL)? a) 1950 b) 1960 c) 1970 d) 1980

01. Kdy se začala formovat koncept relačních databází (Vznik relačního modelu, první definice SQL)? a) 1950 b) 1960 c) 1970 d) 1980 01. Kdy se začala formovat koncept relačních databází (Vznik relačního modelu, první definice SQL)? a) 1950 b) 1960 c) 1970 d) 1980 02. Kdy přibližně vznikly první komerční relační databázové servery?

Více

Architektury Informačních systémů. Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/

Architektury Informačních systémů. Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/ Architektury Informačních systémů Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/ Nutné pojmy Co je to informační systém? Jaké oblasti zahrnuje? Jaká je vazba IS na podnikovou strategii?

Více

1. Integrační koncept

1. Integrační koncept Příloha č. 2: Technický popis integrace 1. Integrační koncept Z hlediska koncepčního budování Smart Administration na Magistrátu města Mostu je možno hovořit o potřebě integrace tří úrovní systémové architektury

Více

Integrace podnikových Open Source aplikací v praxi. RNDr. Petr Novák, Open Source Conference Praha, 19. duben 2011

Integrace podnikových Open Source aplikací v praxi. RNDr. Petr Novák, Open Source Conference Praha, 19. duben 2011 Integrace podnikových Open Source aplikací v praxi RNDr. Petr Novák, Open Source Conference Praha, 19. duben 2011 Partneři řešení Business Systems, a.s. www.bsys.cz MULTIMAGE, s.r.o. www.multimageweb.com

Více

Moderní metody automatizace a hodnocení marketingových kampaní

Moderní metody automatizace a hodnocení marketingových kampaní Moderní metody automatizace a hodnocení marketingových kampaní SAS CI Roadshow 2014 24/09/2014 Vít Stinka Agenda Představení společnosti Unicorn Systems Aliance Unicorn Systems a SAS Celkový koncept Customer

Více

Aplikace IS, outsourcing, systémová integrace. Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/

Aplikace IS, outsourcing, systémová integrace. Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/ Aplikace IS, outsourcing, systémová integrace Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/ Kontext Dodavatelé Strategická Zákazníci ERP Taktická Operativní Kategorie ERP - zaměřeno na

Více

Tabulka Nabídková cena za předmět plnění *uchazeč vyplní cenu za celý kurz nebo cenu za 1 účastníka dle zadávací dokumentace a nabídky uchazeče

Tabulka Nabídková cena za předmět plnění *uchazeč vyplní cenu za celý kurz nebo cenu za 1 účastníka dle zadávací dokumentace a nabídky uchazeče Příloha č. 3 k č.j. : MV-145067-6/VZ-2013 Počet listů: 12 Tabulka Nabídková cena za předmět plnění *uchazeč vyplní cenu za celý nebo cenu za 1 dle zadávací dokumentace a nabídky uchazeče Část 1 pro administrátory

Více

BIG DATA. Nové úlohy pro nástroje v oblasti BI. 27. listopadu 2012

BIG DATA. Nové úlohy pro nástroje v oblasti BI. 27. listopadu 2012 BIG DATA Nové úlohy pro nástroje v oblasti BI 27. listopadu 2012 AGENDA 1. Úvod 2. Jaké jsou potřeby? 3. Možné řešení 2 Jaké jsou potřeby? Dopady Analýza dat potřeba nového přístupu Jak na nestrukturovaná

Více

Aktuální otázky provozu datových skladů PAVEL HNÍK

Aktuální otázky provozu datových skladů PAVEL HNÍK Aktuální otázky provozu datových skladů PAVEL HNÍK K čemu slouží datové sklady IT podporuje business podniků S velikostí podniku se zvyšuje náročnost zpracování dat DWH = unifikovaná datová základna pro

Více

Databázové systémy. Doc.Ing.Miloš Koch,CSc. koch@fbm.vutbr.cz

Databázové systémy. Doc.Ing.Miloš Koch,CSc. koch@fbm.vutbr.cz Databázové systémy Doc.Ing.Miloš Koch,CSc. koch@fbm.vutbr.cz Vývoj databázových systémů Ukládání dat Aktualizace dat Vyhledávání dat Třídění dat Výpočty a agregace 60.-70. léta Program Komunikace Výpočty

Více

Reporting a Monitoring

Reporting a Monitoring Reporting a Monitoring IBM Tivoli Storage Manager 6.3 a IBM Tivoli Storage Manager FastBack 6.1.5 Ondřej Bláha CEE+R CoP Team / Tivoli Storage Team Leader 2010 IBM Corporation Administrátorské rozhraní

Více

Databáze Bc. Veronika Tomsová

Databáze Bc. Veronika Tomsová Databáze Bc. Veronika Tomsová Databázové schéma Mapování konceptuálního modelu do (relačního) databázového schématu. 2/21 Fyzické ik schéma databáze Určuje č jakým způsobem ů jsou data v databázi ukládána

Více

Outsourcing v podmínkách Statutárního města Ostravy

Outsourcing v podmínkách Statutárního města Ostravy Outsourcing v podmínkách Statutárního města Ostravy Říjen 2009 Ing. Stanislav Richtar Ředitel společnosti 1 OBSAH PREZENTACE 1. Outsourcing - obecně 2. Výchozí stav projektu 3. Model poskytovaných služeb

Více

1. Webové služby. K čemu slouží? 2. RPC Web Service. 3. SOA Web Service. 4. RESTful Web services

1. Webové služby. K čemu slouží? 2. RPC Web Service. 3. SOA Web Service. 4. RESTful Web services 13. Webové služby. K čemu slouží? Popis a vyhledávání služeb. Co je a k čemu slouží orchestrace a choreografie služeb. Technologie pro implementaci služeb 1. Webové služby. K čemu slouží? Definice WS -

Více

Technická specifikace předmětu plnění:

Technická specifikace předmětu plnění: Technická specifikace předmětu plnění: Poskytnutí standardní služby Premier Support zahrnující konzultační a implementační podporu, řešení problémů u produktů v nepřetržitém režimu 24x7 v rámci aktuálního

Více

Historie a současnost datových skladů GE Money ČR

Historie a současnost datových skladů GE Money ČR Historie a současnost datových skladů GE Money ČR Ing. Vladimír Klement GE Money ČR IDC Business Intelligence Roadshow 2007 30. 10. 2007 Agenda Může v dnešní době fungovat finanční instituce bez BI? Vývoj

Více

PostgreSQL jako platforma pro datové sklady

PostgreSQL jako platforma pro datové sklady PostgreSQL jako platforma pro datové sklady Vratislav Beneš benes@optisolutions.cz 1. Co to jsou datové sklady? 2. Požadavky na datový sklady 3. Technické řešení datového skladu 4. PostgreSQL a datové

Více

Business Intelligence. Adam Trčka

Business Intelligence. Adam Trčka Business Intelligence Adam Trčka 09:00 11:30: BI v kostce Navrhněme si sklad Ukázka BI Datamining 12:30 14:30: Pokračování kurzu 14:30 15:00: Q&A Agenda Co se dnes dovíme? Data informace znalost Business

Více

TM1 vs Planning & Reporting

TM1 vs Planning & Reporting R TM1 vs Planning & Reporting AUDITOVATELNOST? ZABEZPEČENÍ? SDÍLENÍ? KONSOLIDACE? PROPOJITELNOST???? TM1?? COGNOS PLANNING IBM COGNOS 8 PLANNING Cognos Planning Podpora plánovacího cyklu Jednoduchá tvorba

Více

Požadavky pro výběrová řízení TerraBus ESB/G2x

Požadavky pro výběrová řízení TerraBus ESB/G2x Dokument: Převod dat TerraBus ESB/G2x Požadavky pro výběrová řízení TerraBus ESB/G2x Obsah 1. Účel dokumentu... 2 2. Použité termíny a zkratky... 2 3. Požadavky... 3 Účel dokumentu Účelem tohoto dokumentu

Více

Architektury Informačních systémů. Jaroslav Žáček

Architektury Informačních systémů. Jaroslav Žáček Architektury Informačních systémů Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/ Nutné pojmy Co je to informační systém? Jaké oblasti zahrnuje? Jaká je vazba IS na podnikovou strategii?

Více

Novell Identity Management. Jaromír Látal Datron, a.s.

Novell Identity Management. Jaromír Látal Datron, a.s. Novell Identity Management Jaromír Látal Datron, a.s. 19.4.2012 1 Identity management základní vlastnosti Jednoduché a rychlé poskytování uživatelských účtů Samoobslužné funkce pro uživatele Snadný návrh

Více

<Insert Picture Here> Na co se můžete s Oracle BI těšit

<Insert Picture Here> Na co se můžete s Oracle BI těšit Na co se můžete s Oracle BI těšit Tomáš Pospíšil, Oracle Czech Olomouc, 6.3.2014 Oracle BI Ukázka Oracle BI Možnosti platformy Oracle Business

Více

Nová dimenze rozhodovacího procesu

Nová dimenze rozhodovacího procesu Nová dimenze rozhodovacího procesu Marek Matoušek Pavel Mašek Data, nebo INFORMACE Využití dostupných firemních dat Několik systémů, mnoho různých dat Různé divize, různé potřeby Potřeba integrace dat

Více

Vývoj informačních systémů. Obecně o IS

Vývoj informačních systémů. Obecně o IS Vývoj informačních systémů Obecně o IS Informační systém Informační systém je propojení informačních technologií a lidských aktivit směřující k zajištění podpory procesů v organizaci. V širším slova smyslu

Více

PODNIKOVÁ INFORMATIKA

PODNIKOVÁ INFORMATIKA GÁLA Libor POUR Jan TOMAN Prokop PODNIKOVÁ INFORMATIKA Obsah O autorech... 11 Na úvod jak chápat tuto knihu... 13 Část I: Principy podnikové informatiky... 17 1. Informatika, aplikovaná informatika, podniková

Více

Informační systémy 2008/2009. Radim Farana. Obsah. Obsah předmětu. Požadavky kreditového systému. Relační datový model, Architektury databází

Informační systémy 2008/2009. Radim Farana. Obsah. Obsah předmětu. Požadavky kreditového systému. Relační datový model, Architektury databází 1 Vysoká škola báňská Technická univerzita Ostrava Fakulta strojní, Katedra automatizační techniky a řízení 2008/2009 Radim Farana 1 Obsah Požadavky kreditového systému. Relační datový model, relace, atributy,

Více

PROGRAMÁTOR ANALYTIK. Náplň práce:

PROGRAMÁTOR ANALYTIK. Náplň práce: PROGRAMÁTOR ANALYTIK práce na projektu aplikačního vývoje nad databází Oracle, omezeně i na správě existujících platforem Informatica Power Centre a Sybase ASE analýza, programování a údržba vnitřních

Více

ČÍM TO VŠECHNO ZAČÍNÁ NA DATECH ZÁLEŽÍ, ALE NEJSOU DATA JAKO DATA

ČÍM TO VŠECHNO ZAČÍNÁ NA DATECH ZÁLEŽÍ, ALE NEJSOU DATA JAKO DATA ČÍM TO VŠECHNO ZAČÍNÁ NA DATECH ZÁLEŽÍ, ALE NEJSOU DATA JAKO DATA ŘEŠENÍ SAS JAK TO FUNGUJE Podvody a risika Prevence a detekce podvodů, Vyhodnocování a ošetřování risik Detekce anomálií Podpora vyšetřování,

Více

Databázové a informační systémy

Databázové a informační systémy Databázové a informační systémy doc. Ing. Miroslav Beneš, Ph.D. katedra informatiky FEI VŠB-TUO A-1007 / 597 324 213 http://www.cs.vsb.cz/benes Miroslav.Benes@vsb.cz Obsah Jak ukládat a efektivně zpracovávat

Více

O Apache Derby detailněji. Hynek Mlnařík

O Apache Derby detailněji. Hynek Mlnařík O Apache Derby detailněji Hynek Mlnařík Agenda Historie Vlastnosti Architektura Budoucnost Historie 1997 Cloudscape Inc. - JBMS 1999 Informix Software, Inc. odkoupila Cloudscape, Inc. 2001 IBM odkoupila

Více

Business Intelligence

Business Intelligence Business Intelligence Skorkovský KAMI, ESF MU Principy BI zpracování velkých objemů dat tak, aby výsledek této akce manažerům pomohl k rozhodování při řízení procesů výsledkem zpracování musí být relevantní

Více

Katalog služeb a podmínky poskytování provozu

Katalog služeb a podmínky poskytování provozu Příloha č. 1 Servisní smlouvy Katalog služeb a podmínky poskytování provozu Část P2_1 P2_1_Katalog služeb a podmínky poskytování provozu 1 Obsah 1 OBSAH... 2 2 DEFINICE POJMŮ... 3 3 DEFINICE SLUŽEB, KOMPONENT

Více

CASE nástroje. Jaroslav Žáček

CASE nástroje. Jaroslav Žáček CASE nástroje Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/ Co znamená CASE? A CASE tool is a computer-based product aimed at supporting one or more software engineering activities within

Více

MBI - technologická realizace modelu

MBI - technologická realizace modelu MBI - technologická realizace modelu 22.1.2015 MBI, Management byznys informatiky Snímek 1 Agenda Technická realizace portálu MBI. Cíle a principy technického řešení. 1.Obsah portálu - objekty v hierarchiích,

Více

Performance Management What if?

Performance Management What if? Performance Management What if? Ondřej Bothe, IT Specialist ondrej_bothe@cz.ibm.com Agenda: Koncept PM s What if nástroji Ukázka tvorby What if modelu (Ukázka pokročilejší What if aplikace) Performance

Více

Řešení Quest pro správu Windows Martin Malý, ředitel divize Solutio

Řešení Quest pro správu Windows Martin Malý, ředitel divize Solutio Řešení Quest pro správu Windows Martin Malý, ředitel divize Solutio 1 Kdo jsme Servodata ICT Solutions European Distribution Company Servodata působí na IT trhu v oblasti EMEA již od roku 1991, centrála

Více

Základy business intelligence. Jaroslav Šmarda

Základy business intelligence. Jaroslav Šmarda Základy business intelligence Jaroslav Šmarda Základy business intelligence Business intelligence Datový sklad On-line Analytical Processing (OLAP) Kontingenční tabulky v MS Excelu jako příklad OLAP Dolování

Více

Příloha č. 2 ke smlouvě. Rozsah a podmínky provozní podpory

Příloha č. 2 ke smlouvě. Rozsah a podmínky provozní podpory Příloha č. 2 ke smlouvě Rozsah a podmínky provozní podpory Předmět smlouvy v části Provozní podpora zahrnuje zejména: A) Technickou, uživatelskou a administrativní správu a provozní podporu APV IS ROS

Více

Odbor informatiky a provozu informačních technologií

Odbor informatiky a provozu informačních technologií POLICEJNÍ PREZIDIUM ČR Odbor informatiky a provozu informačních technologií Příloha č. 1 a) název zakázky, Technická podpora software pro systém NS-VIS a VISMAIL b) předmět a rozsah plnění veřejné zakázky

Více

Databázové systémy úvod

Databázové systémy úvod Databázové systémy úvod Michal Valenta Katedra softwarového inženýrství Fakulta informačních technologií České vysoké učení technické v Praze c Michal Valenta, 2016 BI-DBS, LS 2015/16 https://edux.fit.cvut.cz/courses/bi-dbs/

Více

Compatibility List. GORDIC spol. s r. o. Verze 3.60.5 8.4.2009

Compatibility List. GORDIC spol. s r. o. Verze 3.60.5 8.4.2009 Compatibility List Verze 3.60.5 8.4.2009 GORDIC spol. s r. o. Copyright 1993-2009 1 Obsah Obsah 1 2 3 4 5 6 7 8 9 3.1 3.2 Úvodní informace Podporované databázové systémy Klientské prostředí Tlustý klient...

Více

powerful SAP-Solutions

powerful SAP-Solutions We deliver powerful SAP-Solutions to the World! Praktický průvodce novými SAP technologiemi Září 2015 Martin Chmelař itelligence, a.s. Milníky: 2002: založení společnosti 2008: společnost členem itelligence

Více

Možnosti reportingu v produktech řady EPM

Možnosti reportingu v produktech řady EPM Možnosti reportingu v produktech řady EPM Martin Répal Senior konzultant/manager EPM MCITP, MCP, MOS, MCTS, vtsp, Prince II martin.repal@autocont.cz 1 Jak je to s reportingem? Má SW produkt reporty? Tak

Více

Marketingová komunikace. 3. soustředění. Mgr. Pavel Vávra 9103@mail.vsfs.cz. Kombinované studium Skupina N9KMK3PH (vm3bph)

Marketingová komunikace. 3. soustředění. Mgr. Pavel Vávra 9103@mail.vsfs.cz. Kombinované studium Skupina N9KMK3PH (vm3bph) Marketingová komunikace Kombinované studium Skupina N9KMK3PH (vm3bph) 3. soustředění Mgr. Pavel Vávra 9103@mail.vsfs.cz http://vavra.webzdarma.cz/home/index.htm Zdroje Studijní materiály Heleny Palovské

Více

Centralizace aplikací ve VZP 9.11.2011

Centralizace aplikací ve VZP 9.11.2011 Centralizace aplikací ve VZP 9.11.2011 Jiří Holubec, Solution Architect jiri.holubec@gemsystem.cz GEM System a. s. All rights reserved HEWLETT-PACKARD celosvětová technologická společnost IT leader na

Více

Příloha č.2 - Technická specifikace předmětu veřejné zakázky

Příloha č.2 - Technická specifikace předmětu veřejné zakázky Příloha č.2 - Technická specifikace předmětu veřejné zakázky Popis stávajícího řešení u zadavatele Česká centra (dále jen ČC ) provozují 8 fyzických serverů, připojené k local storage. Servery jsou rozděleny

Více

Microsoft SharePoint Portal Server 2003. Zvýšená týmová produktivita a úspora času při správě dokumentů ve společnosti Makro Cash & Carry ČR

Microsoft SharePoint Portal Server 2003. Zvýšená týmová produktivita a úspora času při správě dokumentů ve společnosti Makro Cash & Carry ČR Microsoft SharePoint Portal Server 2003 Zvýšená týmová produktivita a úspora času při správě dokumentů ve společnosti Makro Cash & Carry ČR Přehled Země: Česká republika Odvětví: Velkoobchod Profil zákazníka

Více

ARCHITEKTURA INFORMAČNÍCH SYSTÉMŮ PODLE ÚROVNĚ ŘÍZENÍ

ARCHITEKTURA INFORMAČNÍCH SYSTÉMŮ PODLE ÚROVNĚ ŘÍZENÍ ARCHITEKTURA INFORMAČNÍCH SYSTÉMŮ PODLE ÚROVNĚ ŘÍZENÍ Podle toho, zda informační systém funguje na operativní, taktické nebo strategické řídicí úrovni, můžeme systémy rozdělit do skupin. Tuto pyramidu

Více

v praxi Rizika a přínosy zavádění BI jako nástroje pro řízení podnikání

v praxi Rizika a přínosy zavádění BI jako nástroje pro řízení podnikání Podpora rozhodování v praxi Rizika a přínosy zavádění BI jako nástroje pro řízení podnikání HanušRais Business DevelopmentManager SAS Institute ČR s.r.o. Agenda Úvod - Profil SAS Institute Pojem Business

Více

jaromir.slesinger@ca.com

jaromir.slesinger@ca.com Jarom jaromir.slesinger@ca.com Source: IDC Server Virtualization MCS 2007, 2008, 2009; IDC Datacenter and Cloud Survey 2010 Rostou nároky na rychlost technologických inovací s cílem: 2 Virtualizace hnací

Více

Řešení ochrany databázových dat

Řešení ochrany databázových dat Řešení ochrany databázových dat Projekt Raiffeisenbank CZ Aleš Tumpach CISA April 25, 2016 Pokud dojde k bezpečnostnímu incidentu, informace v databázi jsou nejčastějším cílem útoku WHY? % of Records Breached

Více

Marketingová komunikace. 2. a 3. soustředění. Mgr. Pavel Vávra 9103@mail.vsfs.cz. Kombinované studium Skupina N9KMK3PH (vm3aph)

Marketingová komunikace. 2. a 3. soustředění. Mgr. Pavel Vávra 9103@mail.vsfs.cz. Kombinované studium Skupina N9KMK3PH (vm3aph) Marketingová komunikace Kombinované studium Skupina N9KMK3PH (vm3aph) 2. a 3. soustředění Mgr. Pavel Vávra 9103@mail.vsfs.cz http://vavra.webzdarma.cz/home/index.htm Co nás čeká: 2. soustředění 16.1.2009

Více

Od klasického reportingu k SAP BO Design studio na BW power by HANA Pavel Strnad

Od klasického reportingu k SAP BO Design studio na BW power by HANA Pavel Strnad Od klasického reportingu k SAP BO Design studio na BW power by HANA Pavel Strnad CIO PIA5 NSC Prague Obsah Představení firmy Migrace BW to HANA BI architektura ve Wincor Nixdorf Migrační varianty z BW

Více

SOAP & REST služby. Rozdíly, architektury, použití

SOAP & REST služby. Rozdíly, architektury, použití SOAP & REST služby Rozdíly, architektury, použití Obsah Srovnání SOAP a REST služeb Service Oriented Architecture Microservice Architecture Příklady použití Nástroje pro vývoj SOAP a REST služeb (v Java)

Více

PŘÍLOHA C Požadavky na Dokumentaci

PŘÍLOHA C Požadavky na Dokumentaci PŘÍLOHA C Požadavky na Dokumentaci Příloha C Požadavky na Dokumentaci Stránka 1 z 5 1. Obecné požadavky Dodavatel dokumentaci zpracuje a bude dokumentaci v celém rozsahu průběžně aktualizovat při každé

Více

Novinky v Microsoft SQL Serveru RNDr. David Gešvindr MVP: Data Platform MCSE: Data Platform MCSD: Windows Store MCT

Novinky v Microsoft SQL Serveru RNDr. David Gešvindr MVP: Data Platform MCSE: Data Platform MCSD: Windows Store MCT Novinky v Microsoft SQL Serveru 2016 RNDr. David Gešvindr MVP: Data Platform MCSE: Data Platform MCSD: Windows Store MCT david@wug.cz @gesvindr Přehled hlavních novinek Výkon Query Store Temporal Tables

Více

Korporátní identita - nejcennější aktivum

Korporátní identita - nejcennější aktivum Korporátní identita - nejcennější aktivum Luděk Šafář Services Team Leader lsafar@novell.cz 03/13/2006 Standardní prostředí IT prostředí je diverzifikované a komplexní Administrativní činnosti jsou manuální

Více

Mgr. Jan Folbrecht Senior softwarový inženýr, softwarový architekt, manažer

Mgr. Jan Folbrecht Senior softwarový inženýr, softwarový architekt, manažer Mgr. Jan Folbrecht Senior softwarový inženýr, softwarový architekt, manažer SPECIALIZACE Konzultace a školení v oblastech softwarového inženýrství Zavádění vývojových metodik do projektů a vývojových týmů

Více

Přehled systému Microsoft SQL Server. Komu je kniha určena Struktura knihy Nejvhodnější výchozí bod pro čtení knihy Konvence a struktura knihy

Přehled systému Microsoft SQL Server. Komu je kniha určena Struktura knihy Nejvhodnější výchozí bod pro čtení knihy Konvence a struktura knihy Komu je kniha určena Struktura knihy Nejvhodnější výchozí bod pro čtení knihy Konvence a struktura knihy Konvence Další prvky Požadavky na systém Ukázkové databáze Ukázky kódu Použití ukázek kódu Další

Více

PRODUKTY Tovek Server 6

PRODUKTY Tovek Server 6 Tovek Server je serverová aplikace určená pro efektivní zpracování velkého objemu sdílených strukturovaných i nestrukturovaných dat. Umožňuje automaticky indexovat data z různých informačních zdrojů, intuitivně

Více

TECHNICKÁ SPECIFIKACE VEŘEJNÉ ZAKÁZKY

TECHNICKÁ SPECIFIKACE VEŘEJNÉ ZAKÁZKY Příloha č. 3 k č.j. MV-159754-3/VZ-2013 Počet listů: 7 TECHNICKÁ SPECIFIKACE VEŘEJNÉ ZAKÁZKY Nové funkcionality Czech POINT 2012 Popis rozhraní egon Service Bus Centrální Místo Služeb 2.0 (dále jen CMS

Více

Konsolidace v datacentru. Miroslav Kotrle, Ph.D. CONVENIO CONSULTING

Konsolidace v datacentru. Miroslav Kotrle, Ph.D. CONVENIO CONSULTING Konsolidace v datacentru Miroslav Kotrle, Ph.D. CONVENIO CONSULTING 1 Konsolidace v datacentru Konsolidace v datacentru znamená seskupení služeb či zařízení informačních technologií do nové struktury a

Více

Replikace je proces kopírování a udržování databázových objektů, které tvoří distribuovaný databázový systém. Změny aplikované na jednu část jsou

Replikace je proces kopírování a udržování databázových objektů, které tvoří distribuovaný databázový systém. Změny aplikované na jednu část jsou Administrace Oracle Replikace je proces kopírování a udržování databázových objektů, které tvoří distribuovaný databázový systém. Změny aplikované na jednu část jsou zachyceny a uloženy lokálně před posláním

Více

Business Intelligence nástroje a plánování

Business Intelligence nástroje a plánování Business Intelligence nástroje a plánování pro snadné reportování a vizualizaci Petr Mlejnský Business Intelligence pro reporting, analýzy a vizualizaci Business Intelligence eporting Dashboardy a vizualizace

Více

Kapitola 1: Úvod. Systém pro správu databáze (Database Management Systém DBMS) Účel databázových systémů

Kapitola 1: Úvod. Systém pro správu databáze (Database Management Systém DBMS) Účel databázových systémů - 1.1 - Kapitola 1: Úvod Účel databázových systémů Pohled na data Modely dat Jazyk pro definici dat (Data Definition Language; DDL) Jazyk pro manipulaci s daty (Data Manipulation Language; DML) Správa

Více

Registrační číslo projektu: CZ.1.07/1.5.00/34.0553 Elektronická podpora zkvalitnění výuky CZ.1.07 Vzděláním pro konkurenceschopnost

Registrační číslo projektu: CZ.1.07/1.5.00/34.0553 Elektronická podpora zkvalitnění výuky CZ.1.07 Vzděláním pro konkurenceschopnost Registrační číslo projektu: CZ.1.07/1.5.00/34.0553 CZ.1.07 Vzděláním pro konkurenceschopnost Projekt je realizován v rámci Operačního programu Vzdělávání pro konkurence schopnost, který je spolufinancován

Více

SOA a Cloud Computing

SOA a Cloud Computing 9.11.2011 Marriott hotel Praha SOA a Cloud Computing Jaroslav Novotný IT Architekt 1 Copyright 2011, Oracle and/or its affiliates. All rights SOA a Cloud Computing 2 Copyright 2011, Oracle and/or its affiliates.

Více

Diagnostika webových aplikací v Azure

Diagnostika webových aplikací v Azure Miroslav Holec Software Engineer Microsoft MVP: Microsoft Azure MCSD, MCSA, MSP Lead miroslavholec.cz @miroslavholec Diagnostika webových aplikací v Azure 18. 03. 10. 03. Brno Diagnostic tools in Microsoft

Více