14 RNDr. Ondřej Zýka,

Správa dat v podniku

UAI635 – 2013/14 RNDr. Ondřej Zýka, [email protected]

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

Historie o Relační model – Edgar Frank Codd – 1969 - 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

o SQL – 1970 - Donald Chamberlin, Raymond F. Boyce SEQUEL (Structured English Query Language) IBM - První návrh – 1979 – první komerční implementace Oracle V2 (Relation software)

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,000 1981 – 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,

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 4.21 1993 – Sybase/Microsoft – ukončení smlouvy 1995 – Microsoft SQL Server 6.0 1998 – Sybase 11.9.2 – row-lewel locking 1998 – Microsoft SQL Server 7.0 1999 – 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 2000 2001 – Oracle 9i – XML, RAC

2001 – Sybase 12.5 – XML, EJB 2003 – Oracle 10 – grid computing, flash back 2003 – Windows Server 2003 - 64-bit system - překročení 2GB RAM 2005 – Sybase 15 – new query-optimalizator, Cluster edition 2005 – Microsoft SQL Server 2005 2005 – HW 500GB disk (Hitachi GST) 2007 – Oracle 11 – Exadata 2007 – HW – 1TB disk (Hitachi GST) 2008 – SQL Server 2008 2009 – 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

Diskové kapacity (Wikipedia)

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

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

Velikost dat

10

Různorodost dat

11

Rychlost změny

12

Zákazníci a uživatelé

ODS Operační data

Datová kvalita

MDM

Integra ce

DWH Jednotný model Kompletní historie Integrovaná data

Byznys, technologická a provozní metadata Governance – pravidla, organizační struktura, procesy

Prostředí datově orientovaného systému Etapy životního cyklu

Komponenty

Skupiny uživatelů

Vlastníci aplikace

Plánování

Aplikační programy

Vývoj

Interface

Testování

DBMS

Provozování

Data

Udržování

Hardware

Ukončení používání

Architekti (IT, Aplikační, …) Datový architekt Vývojáři Administrátoři databází Systémoví administrátoři Koncoví uživatelé

Data management Data Management International www.dama.org

Data management o Pravidla – – – – – – –

Zodpovědnosti Pravidla pro vývoj Jmenné konvence Definice dat Bezpečnostní pravidla Požadavky na kvalitu dat Provozní pravidla

o Procesy – – – –

Plánovací Řídící Vývoj Provoz

o Technologie – – – –

Systémy pro správu dat (Databáze) Zálohovací systémy Metadata management systems Systémy pro správu událostí

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

Information Capability Framework Gartner, www.gartner.com

Malcolm Chisholm: The 6 Layers of Data

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 – Email – Obsah webů – Prezentace

DAMA – DMBOK Guide

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ů

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

Datová kvalita

UAI635 2013/14 RNDr. Ondřej Zýka, [email protected]

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

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.

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ů. – [email protected] – Rodné číslo

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.

Jak vyčistit jezero? o 2. přístup

o 3. přístup

– Přefiltrujte vodu – Odstraňte nečistoty – Vraťte vodu do jezera

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

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

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

Dimenze datové kvality Dimenze

Popis

Dostupnost

Zda jsou informace k dispozici nebo snadno získatelné

Odpovídající velikost a granularita dat

Zda velikost dat a jejich granularita odpovídá vykonávaným úlohám

Věrohodnost

Zda jsou informace pokládány za pravdivé a důvěryhodné

Úplnost

Zda žádná data nechybí a zda jsou dostatečné rozsáhlá a detailní pro vykonávané úlohy

Výstižná reprezentace

Zda reprezentace dat má vhodnou strukturu

Konzistentní reprezentace

Zda jsou data reprezentována vždy ve stejném formátu

Snadnost zpracování

Zda jsou informace snadno zpracovatelné a použitelné pro rozdílné úlohy

Bezchybnost

Zda jsou informace a data přesné a hodnověrné

Interpretovatelnost

Zda je jasná definice informací, zda jsou v odpovídajícím jazyku, jednotkách a zda jsou označeny správnými symboly

Objektivita

Zda jsou informace nestranné a nepředpojaté

Relevantnost

Zda jsou informace použitelné a užitečné pro vykonávané úlohy

Reputace

Zda jsou informace považovány za spolehlivé v souvislosti s jejich zdrojem nebo obsahem

Bezpečnost

Zda omezení přístupu k datům a informacím odpovídá bezpečnostním pravidlům

Včasnost

Zda jsou pro vykonávané úlohy informace k dispozici včas

Srozumitelnost

Zda jsou informace snadno pochopitelné a srozumitelné

Přidaná hodnota

Zda a která data a informace jsou přínosné a jaké jsou výhody jejich použití

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

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

Požadavky na datovou kvalitu Data quality policy Data quality organization Data Governance

•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

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

Obsah dat - Data Profiling

o Technický o Uživatelský o Speciální

Data Profiling

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

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 %

DQ měření a reportování

Prosinec 2012

Solvency II - Zkušenosti z implementace

Slide 18

Solvency II - requirements

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

Co si zapamatovat o o o o o o o o

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

Metadata


Chybějící metadata

Doplněná metadata

Co o metadatech říkají autority

Řízení metadata je nepochybně nejdůležitější z dvanácti schopností, které musí mít BI aplikace

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

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ů

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

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

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

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ě emailů, excelů a množství jednání

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

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:

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?

Metadata - analýza o Lineage analýza

o Katalóg

Where – used analýza

Cíle správy metadata ? 1. Jak je pojem definován?

2. Odkud se vzala data? 3. Jak jsou data aktuální?

Controllers

Auditors

Managers

?

Analysts

1. Co vše musím upravit při změně zdrojového systému? Architects

Developers

2. Které všechny reporty musím opravit, když změním definici sloupce? 3. Co se stane, když havaruje toto ETL?

Řízení metadat •Byznys slovník •Datové modely •Procesní modely •Organizační struktura

•SAP •Oracle •Databáze •Teradata

Definice

Aplikace

Transfor Reporting mace •Cognos •SaS •Busines Objects •Oracle BI

•ETL •Skripty •SOA •File transfer

Nástroje o Byznys slovník – Semanta – Collibra – Informatica Metadata Manager

o o o o o o o o

Informatica Metadata Manager Oracle Metadata Directory IBM InfoSphere Metadata Workbench Adaptive Metadata Manager™ InfoLibrarian™ Meta Integration ASG Rochade SP PowerDesigner

Co si zapamatovat o o o o o o o

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

Integrace dat


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.

Požadavky na integrační technologie o o o o o o o o o

Stabilita Udržovatelnost Modifikovatelnost Správa a dohled Škálovatelnost Způsob vývoje Úplnost Otevřenost Podpora

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 Systém je modulární Úprava komponent neovlivní provoz ostatních částí systému Je podporováno verzování Je podporován provoz ve více prostředích (vývojové, testovací, akceptační, provozní) o Je podporována dokumentovatelnost implementace o o o o

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

Škálovatelnost o Dostatečná propustnost o Více možností jak zvyšovat výkonnost – klastrové řešení – podpora více úrovní hardware – možnost dělení systému (geografické, funkční, doménové, …)

o Granularita nastavení bezpečnosti

Způsob vývoje o Vývojové nástroje – Snadnost nasazení – Podpora týmové práce – Verzování

o Podpora pro analýzu – UML - Unified Modeling Language – Designery třetích stran

o Programovací jazyk – Java, C#, VB, C/C++ – „klikací“ – XML

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

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/3 6.20 (Enterprise) PeopleSoft Enterprise® 8.17.02, 8.43, and 8.45 J.D. Edwards OneWorld® B7.3.3.3 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

Otevřenost o Standardy – – – – – – –

SOA XML SOAP WSDL UDDI BPEL BPMN

o Konfigurovatelnost – API – Administrace – Ovládání jádra

Integrační přístupy Asynchronní

Synchronní

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

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

Integrační přístupy Long-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

Short-live operation

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

Integrační přístupy Federation

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

Mediation

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

Integrační přístupy

Point-to-point

Hub and spoke model

Systém A

Systém A

Systém B

Systém B

Systém E

Hub systém

Systém D

Systém C

Integrační přístupy Sender – Receiver (Queue)

Publisher – Subscriber (Topic)

Subsriber A

Sender

Receiver

Publisher Subscriber B


Použití centrálního registru

Nekoordinovaně budované propojení

Systém A Systém A

Systém B

Systém C

Systém B

Systém C

Systém D

Register - Metadata

Úroveň metadat Úroveň technologií

Systém D

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

Insert

Nový záznam

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

Update

Změna záznamu

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

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í


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)

Integrační paterny o o o o

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

Příklad použití datové kvality Complete user profile Scheduled time time Scheduled Sep 21 2004 9:05PM Sep 21 2004 9:05PM

DQ 8

DQReal time Real time 2004 8:59PM 8Sep 21 Sep 21 2004 8:58PM

DQ 6

Scheduled DQ DQ Scheduled aircraft type type aircraft 9M84 M84

7

DQReal aircraft Real aircraft type type 7M83 M83

DQ

DQ

5

5

Account information history SRC

Scheduled time

DQ

SC

Sep 21 2004 9:05PM

FO

Real time

DQ

Scheduled aircraft type

DQ

30

99

M83

30

99

Sep 21 2004 9:05PM

20

99

M83

15

99

MD

Sep 21 2004 9:05PM

10

99

M84

7

99

AG

Sep 21 2004 9:05PM

8

Sep 21 2004 9:00PM

20

99

RL

99

Sep 21 2004 9:00PM

12

99

SI

99

Sep 21 2004 8:58PM

9

99

M83

5

MR

99

Sep 21 2004 8:59PM

6

99

M83

6

Zrušení informace v primárním systému

Real aircraft type

M83

DQ

20 99

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

Datawarehouse

Pavel

Systém

Jirka

Druhý systém

Tomáš

Výsledek

?


Kvalita dat

Null hodnota

Datawarehouse

70

Ne

Systém

90

Ne

Druhý systém

80

Ano


Jméno

Datawarehouse

Pavel

Systém

Jirka

Druhý systém

Tomáš

Výsledek

Jirka


Kvalita dat

Null hodnota

Datawarehouse

70

Ne

Systém

90

Ne

Druhý systém

80

Ano


Jméno

Datawarehouse

Pavel Tomáš

Systém

Druhý systém

Výsledek

Tomáš


Kvalita dat

Null hodnota

Datawarehouse

70

Ne

Systém

90

Ne

Druhý systém

80

Ano


Jméno

Datawarehouse

Pavel

Systém Druhý systém

Výsledek

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 o o o

Master Reference Data Master Systém of Records Master Registry Synchronizace

Master Reference Data Datová integrace Automatické dávkové nebo realtime zpracování. Čištění, integrace, Standardizace,…

Zdroj A

Zdroj B

Zdroj C

Data Exceptions Warehouse

Správa výjimek

Master System of Record Datová integrace Automatické dávkové nebo realtime zpracování. Čištění, integrace, Standardizace,…

Zdroj A

Zdroj B

Zdroj C

Master Databáze

Správa výjimek

Nové aplikace

Master Registry Datová integrace Automatické dávkové nebo realtime zpracování. Čištění, integrace, Standardizace,…

Zdroj A

Zdroj B

Registr

vazeb

Zdroj C Správa výjimek

Nové aplikace

Synchronization

Zdroj A

Datová integrace Automatické dávkové nebo realtime zpracování. Čištění, integrace, Standardizace,…

Zdroj B

Správa výjimek

Zdroj C

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.

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ů

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

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ů

Úvod do BI


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

Co obsahuje BI (Gartner) o Integration – – – – –

BI infrastructure Metadata management Development tools Collaboration Data quality

o Information delivery – – – – –

Reporting Dashboards Ad hoc query Microsoft Office integration Mobile BI

o Analysis – – – –

Online analytical processing (OLAP) Interactive visualization Predictive modeling and data mining Scorecards

Integrace o BI infrastructure – – – – – –

Security Metadata Administration Portal integration Object model Data storage and Query engines

o Metadata management – – – – –

Collect Shared Search Analyze Business, technical and operation metadata – Dimensions, hierarchies, measures, performance metrics – Full data-lineage

o

o Development tools – – – – – – –

Programmatic development tools Visual development environment Scheduling Delivering Administering and managing Change management support Workflow tool

o Collaboration – – – –

Share and discuss information BI content and results Manage hierarchies and metrics Analytical master data management (MDM).

o Data quality – – – – –

Definition of user requirements Data assessment tools Business rule engines Data quality measuring and reporting Information delivery

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

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

Požadavky na BI o o o o o o o o

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

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)

Architektura


ODS Operační data

Datová kvalita

MDM

Integra ce



Architektura DWH

Stage Obraz vstupních dat Záloha dat pro zpracování Datová kvalita

Jádro

Jednotný model Kompletní historie

Scheduler a dohled

Data Marty Podle analyzovaných procesů Dimenze a metriky Agregovaná data

Co si zapamatovat o o o o

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

BI prostředí


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í

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

Business value o o o o o

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

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í

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

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.

BICC – procesní oblasti o o o o o o o

Řízení strategie Porozumění BI komunitě Řízení požadavků Řízení architektury Řízení vývoje Řízení provozu Řízení rozpočtu a získávání zdrojů

o Definování metrik o Nástroje

BICC – Nástroje o o o o o o o

Byznys slovník Datový slovník Katalog BI služeb Katalog BI požadavků Incident management tool Katalog reportů Katalog uživatelů

Příklad – struktura BI portálu o o o o

Novinky Základní informace o portálu Status BI 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

Příklad – definice procesů Help Desk

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

IM200 Klasifikace a kategorizace incidentu

PM200 Klasifikace a kategorizace problému

HD200 Klasifikace a kategorizace požadavku

IM300 Analýza, diagnostika incidentu

PM300 Analýza, diagnostika problému

IM500 Řešení a obnova

PM500 Řešení problému

HD500 Řešení požadavku

Change Management

CH100 Založení a pre-analýza RFC

CH200 Klasifikace RFC

CH300 Autorizace a nastavení termínu změny

CH500 Řešení RFC (Support, Maintanace)

Requirement Management

RM100 Založení a pre-analýza požadavku

Project, Small Enhancement

Problem Management

Support, Maintanace

Incident Management

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í

IM800 Schválení zadavatelem

IM900 Uzavření incidentu

PM900 Uzavření problému

HD700 Ověření řešení majitelem procesu

HD800 Schválení zadavatelem

CH800 Schválení zadavatelem

RM800 Schválení k Implementaci

HD900 Vyhodnocení ticketu

CH900 Vyhodnocení a uzavření RFC

RM900 Uzavření požadavku

Příklad - SLA parametry BI služby Služba Standardní reporty

Garantovaný přístup Po - Pá

09:00 - 17:00

Omezený přístup Po,Út,St,Pá Čt Po - Pá So Ne

00:00 - 09:00 00:00 - 08:00 17:00 - 22:00 12:00 - 24:00 00:00 - 24:00

Standardní dostupnost

Údržba Po - Pá Čt So

22:00 - 24:00 08:00 - 09:00 00:00 - 12:00

Rozložení výpadků 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

95%

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 Statické předgenerované reporty

Počet přístupů 1000 - 10000 přístupů za den

Parametrizovatelné spouštěné reporty

100 - 1000 přístupů za den

Analytické reporty (analytické prostředí)

1000 - 10000 přístupů za den

Odezva přístupu 50% přístupů do 10s 90% přístupů do 20s N/A 50% přístupů do 20s 90% přístupů do 40s Drill-down OLAP kostkou o jednu úroveň - 95% do 45s

Příklad – Incident management tool

Gartner BI summit - 2011

Co si zapamatovat o o o o o o

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

Architektura DWH


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)

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.


ODS Operační data

Datová kvalita

MDM

Integra ce



DWH subjektově orientovaný pohled na data OLTP systémy Povinné ručení

Životní pojištění

Datový sklad Zákazník/ Smlouva

Likvidace

Platby a finance Zdravotní pojištění

Neživotní pojištění

Aplikace

Zajištění

Subjekty

Proč budujeme datový sklad

Strategické cíle - Top Mgmt. ROE

Výnosy

Náklady Rizika

o Byznys strategie podniku

Taktické & operativní cíle - Middle Mgmt. Výnosnost na klienta

Retence klientů

Akvizice klientů

Inteligentní marketing

Produktový vývoj

Detekce odlivu zákazníků

Scoring & Rating

Křížový prodej

Detekce podvodů

Efektivita práce

OPEX

Výkonově řízený komp. systém

Finanční řízení

Řízení nákladů

Automatizace procesů

...

Řízení rizik

Channel Management

Segmentace

Zdroje růstu METRIKY

STATISTIKY

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 prodejů Statistiky zákazníků

Efektivita kampaně

Efektivita obchodního procesu

...

Informace/Metriky BI

DATA DATA - interní / externí

Vazba strategie a architektury v podniku

IT strategie

Byznys architektura

Aplikační architektura Datová architektura Technologická architektura

IT architektura

Enterprise architektura

Byznys strategie

Proč budujeme datový sklad? ROE – Return Of Equity Mise: • • • •

ROE / Profit ++ Hodnota společnosti + Podíl na trhu + Nová teritoria

Situace: • • • • •

rychle se měnící trh „low margin“ business zákazník: dlouhodobý vztah zákazníků: 100.000+ konkurence, mzdy,....


Výnosy

Náklady Rizika


Výnosy

Náklady Rizika


Retence klientů

Akvizice klientů


Produktový vývoj


Scoring & Rating

Křížový prodej

Detekce podvodů

Efektivita práce

OPEX



Řízení nákladů


...

Řízení rizik

Channel Management

Segmentace

Zdroje růstu METRIKY X-Sell probability

STATISTIKY




Wallet Share


Housholding


Segmentace



Efektivita kampaně


...



Proč budujeme datový sklad?

Mise: • • •

Strategické cíle - Top Mgmt.

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ů

Výnosy

Taktické & operativní cíle - Middle Mgmt.

Situace: • • •

trh je rozdělen a saturován existuje odliv zákazníků náklady na nového zákazníka

Akvizice klientů

Retence klientů

Výnosnost na klienta

...


Výnosy

Náklady Rizika


Retence klientů

Akvizice klientů


Produktový vývoj


Scoring & Rating

Křížový prodej

Detekce podvodů

Efektivita práce

OPEX



Řízení nákladů


...

Řízení rizik

Channel Management

Segmentace


STATISTIKY




Wallet Share


Housholding


Segmentace



Efektivita kampaně


...



Proč budujeme datový sklad?

Úlohy: • • • • •

Aplikovat křížový prodej Zkrátit TTM Zefektivnit marketing Snížit odliv zákazníků ...

Situace: • • •

neznámá zák. struktura neexistují metriky @@

Taktické & operativní cíle - Middle Mgmt. Akvizice klientů

Retence klientů



Produktový vývoj


Křížový prodej Strategické cíle - Top Mgmt. ROE

Scoring & Rating

Segmentace

Channel Management

Výnosy

Náklady

Rizika

Taktické & operativní cíle - Middle Mgmt.

Zdroje růstu


Retence klientů

Akvizice klientů


Produktový vývoj


Scoring & Rating

Křížový prodej

Detekce podvodů

Efektivita práce

OPEX



Řízení nákladů


...

Řízení rizik

Channel Management

Segmentace


STATISTIKY




Wallet Share


Housholding


Segmentace



Efektivita kampaně


...



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


ODS Operační data

Datová kvalita

MDM

Integra ce



OLTP x DWH OLTP systémy

Datový sklad

Aplikačně orientovaná

Předmětně orientovaná

Detailní data

Agragovaná nebo vypočítávaní data

Přesné hodnoty, význam v době zpracování

Historie, data za období, snapshoty

Slouží provozním pracovníkům

Slouží manažerům

Mnoho změn – update

Zaznamenává se historie, update je nový záznam

Opakující se zpracování

Časté ad-hoc analýzy

Předem známy a definovány požadavky na data a procesy

Většina požadavků není předem známa

Standardní vývojový cyklus aplikace

Požadovaný agilní vývojový cyklus

Přístup k jednotlivým záznamu

Přístup k velké množině záznamů najednou

Orientace na transakce

Orientace na analýzu

OLTP x DWH OLTP systémy

Datový sklad

Výkonnost je extrémně důležitá pro provoz organizace

Volnější nároky na výkonnost (denní zpracování)

Práva vlastníků dat na změnu jsou důležitá

Změna je prováděna technologickými uživateli

Požadována vysoká dostupnost

Nižší požadavky na dostupnost

Spravuje se jako celek

Spravuje se po logických částech

Redundance dat je nežádoucí (normalizované modely)

Redundance je běžná (denormalizované modely)

Statická struktura, variabilní obsah

Flexibilní struktura

Malé objemy dat

Velké objemy dat

Orientace na každodenní rutinu

Orientace na analýzy a plánování

ODS x DWH ODS

DWH

Integrovaná data

Integrovaná data

Přebíraná data

Vyčištěná data

Orientace po oblastech

Orientace po oblastech

Bez historie

Kompletní historie

Změny v datech

Bez změn

Bez agregace

Agregovaná data

Transakční load dat

Dávkový load dat

Informační zdroj o záznamech

Analytické aplikace

Obousměrná komunikace

Jednosměrná komunikace

Uživatelé systémů OLTP

ODS

DWH

Provozní pracovníci Střední management

Provozní pracovníci Klienti Partneři

Střední management Vrcholný management

Vývoj složitosti DWH

Big Data

Dotazy, Reporty,

1980



Data mining

Data mining

Data mining

Multidimenzi onální analýza




MIS

MIS

MIS

MIS

MIS

Dotazy, Reporty,

Dotazy, Reporty,

Dotazy, Reporty,

Dotazy, Reporty,

Dotazy, Reporty,

1990

2000

2010

Architektura DWH

Stage Obraz vstupních dat Záloha dat pro zpracování Datová kvalita

Jádro

Jednotný model Kompletní historie

Scheduler a dohled

Data Marty Podle analyzovaných procesů Dimenze a metriky Agregovaná data

Architektura o Modely o ETL o Reporting

o o o o o o o

Technologie Partitioning Bitmap indexy Materializované view Komprimované tabulky Paralelismus OLAP

Jádro DWH o o o o

Logický datový model organizace Specializovaný na doménu organizace Nezávislý na implementaci jednotlivých transakčních systémů 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ší

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 o o o o

Základní atributy jednotlivých entit Doporučené struktury entit Doporučené struktury atributů Logické modely pro jednotlivé subjekty Návrhy data martů pro řešení specifických úloh

Příklad – konceptuální model FSLDM

http://mike2.openmethodology.org/wiki/Guidelines_for_Using_the_FSLDM

Příklad – struktura FSDM

Příklad – logický model oblasti

Příklad – doporučená struktura

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

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

FSDM – připravené oblasti

Risk

• • • • •

Credit Risk Assessment Credit Risk Mitigation Assessment Operational Risk Assessment Operational Risk Loss Analysis Value at Risk Analysis

Stage o o o o o o

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

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)

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

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

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

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ě

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

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

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 • Uložená data získaná ze zdrojových systémů mohou být použita k opravnému loadu. – Audit • 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

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

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

ETL nástroje o o o o o o o o o

Snadný návrh Dokumentace transformací Znuvupoužitelnost objektů Template pro standardní úlohy Schopnost napojení na mnoho typů zdrojů Technologická nezávislost Schopnost zvládnout veliké objemy dat (stovky GB) Dohled a řízení běhu transformací Shromažďování operačních metadat

o Konkurence – Psaní skriptů (PL/SQL, BTEQ, Perl, shell, …)

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

Použití ETL o o o o

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

Příklad – návrh ETL- BizzTalk

Příklad – grafické rozhraní Informatica

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

Příklad – dohled zpracování

Příklad – fáze loadu Data Staging Area

Step 2

Step 3

Step 4

Step 5

Capture Pre F.1

Filter

Intel. Merge

Delta

Step 1

* Fixed Lt * Select Operational * Logs * Extracts * Variable Sources * SEQ

* Backups

IMS

Step 6

Step 7

Clean Build & * Detect Transf * Build

* Merge delta * Ensure DW rows records N to N data can Maps be loaded * Convert * Change

Step 8

Step 9

Apply

Backup

* Load * SQL

* Load files * Recovery

Data Warehouse

DB2

DBMS

Sybase

SEQ

Oracle

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ů

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

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í

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

Co si zapamatovat o o o o o o o

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

Databázové patterny


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

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

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

Pattern: Přiřazení rolí I

CUSTOMER ID

ORGANIZATION/FIRST/LAST NAME

CREDIT LIMIT

100

Moje data s.r.o.

1000000 CZK

101

Tvoje Data s.r.o.

null

SUPPLIER ID

ORGANIZATION NAME

TAXATION IDENTIFIER

369

Moje data s.r.o.

123456789

456

Vaše Data s.r.o.

987654321

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)

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

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.

Pattern: Přiřazení rolí II

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.

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.

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

Pattern: Přiřazení rolí III

Pattern: Přiřazení rolí ROLE TYPE NAME ID

PARENT ROLE TYPE ID

PARENT NAME

100

Party role

Null

Null

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

Pattern: Přiřazení rolí

Party Role

Partner

Customer

Organization Role

Person Role

Supplier

Employee

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.

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.

PARTY model - příklad

PARTY_ROLE – jiný příklad

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í (CZNACE))

Klasifikace Product Type

Hardware

Software

Storage devices

Processors

Business software

Accessory

Gaming Software

Mouse pads

Cases

Product Family

Disk drives

Carrying Cases

Computer Memory

Desktop Computers

Laptop Computers

Product Line

Home Use

Commercial Use

Home Business

Government

Pattern: Klasifikace I

Pattern: Klasifikace I

ID

NAME

TYPE

FAMILY

LINE 1

LINE 2

CAPACIT COLOU Y R

100

Save Disk 2000

HW

Disk Drivers

Home use

Commercial Use

20GB

101

Carry All Case

Accesory

Carrying Case

Commercial use

102

HS Software package

Software

103

Memmory card M10

Hardware

Green

Home Business

Computer memory

Home use

Black

Home Business

1GB

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.

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.

Pattern: Klasifikace II

Pattern: Klasifikace II o Klasifikace – Navzájem se vylučující typy – Hardware, Accessory, Software; – Více hodnot z klasifikace – Product Line.

o o o o o

Klasifikace je možné měnit. Pro porozumění modelu je důležité znát obsah tabulek (číselníků). Umožňuje nezávislé řízení klasifikací – MDM Rozdílné klasifikace mohou mít své atributy. Porozumění modelu není extrémně složité.

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.

Pattern: Klasifikace III

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

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.

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.

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.


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

Dimenzionální modelování UAI635 – 2013/14 RNDr. Ondřej Zýka, [email protected]

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

Příklad

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

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

Fakta

Store Store Number Store Name City State Country Telephone

Product Product Description Category

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

Customer Category Category Customer Category

Customer Customer First Name Last Name Address 1 Address 2 Address 3 City State Country Postal Code Customer Category

Store Store Number Store Name City State Country Telephone Region

Product Product Description Category Product Category Product Category Description

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í

Constellation schéma


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 Product Purchases Product Purchase Date Supplying Vendor Purchase Order Unit Quantity Purchase Cost

Grocery Transaction Store Number Transaction Date Customer Product Purchase Quantity Amount 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

Snowstorm schéma Region Region Description

Sales Period Period Identifier Sales Period From Date To Date

Promotion Period Promotion Id Promotion From Date To Date


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 Product Purchases Product Purchase Date Supplying Vendor Purchase Order Unit Quantity Purchase Cost

Grocery Transaction Store Number Transaction Date Customer Product Purchase Quantity Amount

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

Postup návrhu modelu

1. 2. 3. 4. 5.

Výběr sledovaných procesů Určení granularity Určení dimenzí Určení metrik Definice získávání dat (ETL)

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

Buss 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

× × × × × × × × × × × × × × ×

× × × × × × × × ×

×

× × × × × × × × ×

×

×

× × × × × ×

× × × × × × × ×

×

× × × × × ×

× × ×

× ×

× × × × ×

×

× × × × × × × × × × × × × ×

× × × × ×

× × × × × ×

× × × × × × × × × × × × × × ×

× ×

×

×

× × ×

× × × × × ×

× × × × ×

× × × × ×

× × ×

× × ×

× × ×

× ×

Account status

Weather

Item Shipped

Supplier

Equipment Type

Location

Employee

Internal Organization

Long Dist Provider

Called Party

Calling Party

Local Svc Provider

Rate Category

Service

Customer

Date

Bus matrix

× × × × × × × × ×

Bus architektura a schéma - příklad

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í

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)

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)

Určení dimenzí o Konformní dimenze – Jedna nejpodrobnější dimenze, ostatní jsou jejich agregací – Jednotné dimenze pro všechny business procesy

o o o o o o o

Jeden sloupec primárního klíče Hodně sloupců popisů, často přes 30, čím více tím lépe Atributy spíše textové (srozumitelnost) Hierarchie pro analýzy Časová dimenze Degenerovaná dimenze – nemá popis (číslo faktury) 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“

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

Časová dimenze

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

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

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)

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

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

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

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

Další témata o o o o o o

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

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

Příklad uložení

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

FASMI - Fast Analysis of Shared Multidimensional Information o Alternativní název pro OLAP reportingová prostředí o Fast – –

Rychlá odezva, obvykle do jednotek sekund , maximálně několik desítek sekund Delší odezvy odrazují od analýzy, snižují zapojení uživatelů

o Analytical – – –

Uživatelsky přívětivá schopnost analýz Nevyžaduje programování Podpora dostatečného množství funkcí a neprocedurálních modelů

o Shared – –

Podpora bezpečnosti až na úrovni buňky Read-write model

o Mutlidimensional – – –

Podporuje multidimensionálního pohledu na data Star-, respektive snow-flake schéma Podpora více hierarchií

o Information – –

Schopnost zpracovat velké množství informací RAM a disk požadavky. Integrce s DWH

FASMI test BI platformy o o o o o o o o o o o o o o o o o o

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

Příklady dodavatelů OLAP serverů o o o o o o o

MS Analysis Services IBM Cognos Oracle OLAP option Hyperion Essbase Business Objects MicroStrategy SAS

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

SQL pro DWH


Pokročilé použití SQL o o o o

Pomocné tabulky – With Rekurze – with Rozhodování – case 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í

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

COUNT -------1 3 3 5 6 8

HEADQUARTER -------------6566 6899 8545 7312 7721 7063

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

Join A

B

A

select * from A left join B on A.PK = B.PK

A

select * from A right join B on A.PK = B.PK

A

B

select * from A left join B on A.PK = B.PK where B.PK is null

A

B

B

A

select * from A inner join B on A.PK = B.PK

B

select * from A full outer join B on A.PK = B.PK

B

select * from A right join B on A.PK = B.PK where A.PK is null

A

B

select * from A full outer join B on A.PK = B.PK where A.PK is null or B.PK is null

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

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

Ř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 jmeno, obchod, titul, pocet from at_table join sales_table on (at_table.title_id=sales_table,title_id);

Rekurze Vytvořte tabulku s hodnotami 1 až 100

ID ----1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 ...

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

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

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

Count

Co počítají příkazy select count(*) from title; select count(price) from title; select count(all price) from title; select count(distinc price) from title;

18 16 16 11

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 -------- ---------- ---------MC3021 2.99 2 BU2075 2.99 2 PS2106 7 2 PS7777 7.99 2 PS2091 10.95 4 BU1111 11.95 3 TC4203 11.95 3 TC7777 14.99 1 BU7832 19.99 7 MC2222 19.99 7 PS3333 19.99 7

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

Count – analytická funkce V kolika různých typech knih se vyskytuje kniha se stejnou cenou: TITLE_ID -------BU2075 BU1032 BU7832 BU1111 MC3021 MC2222 PC1035 PC9999 PC8888 PS2091 MC3026

TYPE PRICE TYPE_COUNT ------------ ---------- ---------business 2.99 2 business 19.99 3 business 19.99 3 business 11.95 2 mod_cook 2.99 2 mod_cook 19.99 3 popular_comp 22.95 1 popular_comp 2 popular_comp 20 1 psychology 10.95 1 psychology 2

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

Řazení – číslování řádků Seřaďte knihy podle prodejů. ORDER -------1 2 3 4 5 6 7 8 9 10 11 12 13 14

TOTAL_SALES -------------111 375 375 2032 2045 3336 3876 4072 4095 4095 4095 4095 8780 15096

TYPE -----------psychology psychology trad_cook mod_cook psychology psychology business psychology trad_cook popular_comp business business popular_comp trad_cook

TITLE_ID ----------PS2106 PS1372 TC3218 MC2222 PS2091 PS7777 BU1111 PS3333 TC7777 PC8888 BU1032 BU7832 PC1035 TC4203

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

title_id from title

Řazení ve skupinách Seřaďte knihy podle prodejů a typů knih. ORDER -------1 2 3 4 1 2 1 2 3 1 2 3 4 5

TOTAL_SALES -------------3876 4095 4095 18722 2032 22246 4095 8780 (null) 111 375 2045 3336 4072

TYPE -----------business business business business mod_cook mod_cook popular_comp popular_comp popular_comp psychology psychology psychology psychology psychology

TITLE_ID ----------BU1111 BU1032 BU7832 BU2075 MC2222 MC3021 PC8888 PC1035 PC9999 PS2106 PS1372 PS2091 PS7777 PS3333

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

Řazení II Seřaďte knihy podle prodejů - stejný počet, stejné pořadí (jako v golfu) ORDER -------1 2 2 4 5 6 7 8 9 9 9 9 13 14

TOTAL_SALES -------------111 375 375 2032 2045 3336 3876 4072 4095 4095 4095 4095 8780 15096

TYPE -----------psychology psychology trad_cook mod_cook psychology psychology business psychology trad_cook popular_comp business business popular_comp trad_cook

TITLE_ID ----------PS2106 PS1372 TC3218 MC2222 PS2091 PS7777 BU1111 PS3333 TC7777 PC8888 BU1032 BU7832 PC1035 TC4203

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

Řazení III Seřaďte knihy podle prodejů, stejný počet, na stejném místě. ORDER -------1 2 2 3 4 5 6 7 8 8 8 8 9 10 11

TOTAL_SALES -------------111 375 375 2032 2045 3336 3876 4072 4095 4095 4095 4095 8780 15096 18722

TYPE -----------psychology psychology trad_cook mod_cook psychology psychology business psychology trad_cook popular_comp business business popular_comp trad_cook business

TITLE_ID ----------PS2106 PS1372 TC3218 MC2222 PS2091 PS7777 BU1111 PS3333 TC7777 PC8888 BU1032 BU7832 PC1035 TC4203 BU2075

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

Rozhodování - case Skryjte opakující se hodnoty. ORDER -------1 2 3 4 5 6 7 8

9 10

TOTAL_SALES -------------111 375 375 2032 2045 3336 3876 4072 4095 4095 4095 4095 8780 15096

TYPE -----------psychology psychology trad_cook mod_cook psychology psychology business psychology trad_cook business business popular_comp popular_comp trad_cook

TITLE_ID ----------PS2106 PS1372 TC3218 MC2222 PS2091 PS7777 BU1111 PS3333 TC7777 BU7832 BU1032 PC8888 PC1035 TC4203

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

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 -------2010-01 2010-02 2010-03 2010-04 2010-05 2010-06 2010-07 2010-08 2010-09 2010-10 2010-11 2010-12

New Age Books ---------------2477 2159 2195 3327 3797 5490 3407 1470 1221 1063 964 484

Binnet & Hardley ------------------4703 4412 4114 6182 6689 9892 6484 2827 2294 1884 1686 847

Aldata Infosystems --------------------2991 3398 2968 4741 4994 8145 5143 2163 1745 1377 1293 602

Ř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

Spojení hodnot Dejte všechny title_id pro vydavatele do jedné řádky

PUB_ID --------0736 0877 1389

TITLE_IDS -----------------------------------------------BU2075,PS2091,PS2106,PS3333,PS7777 MC2222,MC3021,MC3026,PS1372,TC3218,TC4203,TC7777 BU1032,BU1111,BU7832,PC1035,PC8888,PC9999

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

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é

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

Technologie DWH


Technologie o Denormalizace – Partitioning – Indexy – Materializované view

o o o o

Indexy a bitmapové indexy Komprimované tabulky Paralelismus OLAP

Denormalizace o Partitioning – Horizontální – Vertikální

o Uložení vypočtených hodnot o Spojení tabulek

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

Rozdělení tabulky Rozdělení tabulky

Part 1

Part 1 Table

Part 2

View

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

Table

Partitioning o Transparentní z pohledu aplikace Part 1

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

Part 2 Part 3 Part 4

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

Rozdělení tabulky Rozdělení tabulky

Table

P a r t

P a r t

P a r t

1

2

3

View

Table

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

P a r t 1

Přidání indexů o Transparentní z pohledu aplikace

o o o o

Jeden clustrovaný index Libovolný počet dalších indexů Automatická údržba Pokrývající dotazy

o Nároky na diskový prostor o Snížení výkonu pro OLTP aplikace

I n d e x

I n d e x

1

2

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

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

B-tree index – příklad kořen

vnitřní blok indexu

listová úroveň indexu

data

Blok 1212 Blok 1132 Blok 1007

klíč

řádek blok Blok 1001

Bennet

Chet

1421,1 1007

Karsen

Kit

1876,4 1306

Smith

Ade

1242,3 1062

Bennet

Chet

1421,1 1132

Fox

John

1317,3 1133

Hunter

Leon 1213,1 1127

Bennet

Chet

1421,1

Burns

Saly

1409,4

Claim

Dave

1129,3

Dull

Rob

1409,1

Larry

John

254

A3

Jetkins

Paul

244

C3

White

Susan

156

A1

Blok 1213 Blok 1133

Blok 1306 Karsen

Kit

1876,4 1198

Larn

Pard

1451,2 1199

Peters

Mary 1856,4 1200

Hunter

Leon

124

A3

Fox

John

1317,3

Green

Mitch

125

B1

Greane

David

1876,4

Smith

Ade

156

A3

Green

Mitch

1213,2

Greene

Joe

1409,2 Blok 1421

Blok 1127

Hunter

Leon 1213,1

Jetkins

Paul

1212,2

Bennet

Chet

101

B2

Ringer

John

144

C1

Blok 1409

INSERT INTO user VALUES (′Burns′, ′Saly′,128,′A1′)

Dull

Rob

128

B1

Greene

Joe

142

A2

Port

Joe

156

C3

Burns

Saly

128

A1

Clustered index – příklad kořen

vnitřní blok indexu

listová úroveň indexu

Blok 1132

klíč

blok Blok 1007

Blok 1001 Bennet

Chet

1007

Karsen

Kit

1306

Smith

Ade

1062

Bennet

Chet

1132

Fox

John

1133

Hunter

Leon 1127

Bennet

Chet

101

B2

Burns

Saly

128

A1

Claim

Dave

123

A1

Blok 1133 Blok 1306 Karsen

Kit

1198

Larn

Pard

1199

Peters

Mary 1200

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

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

Data uložená po sloupcích

o Vertica

o SAP Sybase IQ

o Oracle – bitmapové indexy

Tabulka – relační uložení dat ID NAME DESCRIPTION QTY COLOUR PRICE PROVIDER WIDTH HEIGHT DEPTH ID ID ID ID ID ID ID ID

NAME NAME NAME ID NAME ID NAME ID NAME ID NAME ID NAME ID ID ID

NUMBER VARCHAR2(50 BYTE) VARCHAR2(500 BYTE) NUMBER VARCHAR2(20 BYTE) NUMBER VARCHAR2(40 BYTE) NUMBER NUMBER NUMBER

Struktura tabulky

Datové bloky

DESCRIPTION QTY COLOUR PRICE PROVIDER WIDTH HEIGHT DEPTH DESCRIPTION QTY COLOUR PRICE PROVIDER WIDTH HEIGHT DEPTH DESCRIPTION QTY COLOUR PRICE PROVIDER WIDTH HEIGHT DEPTH NAME DESCRIPTION QTY COLOUR PROVIDER DESCRIPTION QTY COLOUR PRICE PRICE PROVIDER WIDTH WIDTH HEIGHTHEIGHT DEPTH DEPTH NAME DESCRIPTION QTY COLOUR PROVIDER DESCRIPTION QTY COLOUR PRICE PRICE PROVIDER WIDTH WIDTH HEIGHTHEIGHT DEPTH DEPTH NAME DESCRIPTION QTY COLOUR PROVIDER DESCRIPTION QTY COLOUR PRICE PRICE PROVIDER WIDTH WIDTH HEIGHTHEIGHT DEPTH DEPTH NAME DESCRIPTION QTY COLOUR PROVIDER DESCRIPTION QTY COLOUR PRICE PRICE PROVIDER WIDTH WIDTH HEIGHTHEIGHT DEPTH DEPTH ID NAME DESCRIPTION QTY COLOUR PRICE PROVIDER WIDTH HEIGHT DEPTH NAME DESCRIPTION QTY COLOUR PRICE PROVIDER WIDTH HEIGHT DESCRIPTION QTY COLOUR PRICE PROVIDER WIDTH HEIGHT DEPTH DEPTH ID NAME DESCRIPTION QTY COLOUR PRICE PROVIDER WIDTH NAME DESCRIPTION QTY COLOUR PRICE PROVIDER WIDTH HEIGHT HEIGHT DEPTH DEPTH ID NAME DESCRIPTION QTY COLOUR PRICE PROVIDER NAME DESCRIPTION QTY COLOUR PRICE PROVIDER WIDTH WIDTH HEIGHT HEIGHT DEPTH DEPTH ID NAME DESCRIPTION QTY COLOUR PRICE PROVIDER WIDTH HEIGHT DEPTH NAME DESCRIPTION PRICE PROVIDER WIDTH ID NAMEQTY COLOUR DESCRIPTION QTY COLOUR PRICE HEIGHT PROVIDERDEPTH WIDTH HEIGHT ID NAME DESCRIPTION QTY COLOUR PRICE PROVIDER WIDTH HEIGHT DEPTH ID NAME DESCRIPTION QTY COLOUR PRICE PROVIDER WIDTH HEIGHT ID NAME DESCRIPTION QTY COLOUR PRICE PROVIDER WIDTH HEIGHT DEPTH ID NAME DESCRIPTION QTY COLOUR PRICE PROVIDER WIDTH HEIGHT ID NAME DESCRIPTION QTY COLOUR PRICE PROVIDER WIDTH HEIGHT DEPTH ID NAME DESCRIPTION QTY COLOUR PRICE PROVIDER WIDTH HEIGHT ID NAME DESCRIPTION QTY COLOUR PRICE PROVIDER WIDTH HEIGHT DEPTH ID NAME DESCRIPTION QTY COLOUR PRICE PROVIDER WIDTH HEIGHT ID NAME DESCRIPTION QTY COLOUR PRICE PROVIDER WIDTH HEIGHT ID NAME DESCRIPTION QTY COLOUR PRICE PROVIDER WIDTH HEIGHT ID NAME DESCRIPTION QTY COLOUR PRICE PROVIDER WIDTH HEIGHT

DEPTH DEPTH DEPTH DEPTH DEPTH DEPTH DEPTH DEPTH

Tabulka – data uložená po sloupcích ID NAME DESCRIPTION QTY COLOUR PRICE PROVIDER WIDTH HEIGHT DEPTH ID ID ID ID ID ID ID ID

NUMBER VARCHAR2(50 BYTE) VARCHAR2(500 BYTE) NUMBER VARCHAR2(20 BYTE) NUMBER VARCHAR2(40 BYTE) NUMBER NUMBER NUMBER ID ID ID NAME ID NAME ID NAME ID NAME ID NAME ID NAME NAME NAME

ID ID ID NAME ID NAME ID NAME ID NAME ID COLOUR NAME ID COLOUR NAME COLOUR NAME COLOUR NAME COLOUR COLOUR COLOUR COLOUR

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 NAME NAME NAME NAME NAME NAME NAME ID ID ID ID ID ID ID NAME NAME ID NAME ID NAME ID NAME ID NAME ID NAME ID NAME ID NAME NAME ID NAME ID NAME ID NAME ID NAME ID NAME ID NAME ID NAME NAME ID NAME ID NAME ID NAME ID NAME ID NAME ID NAME ID NAME COLOUR COLOUR COLOUR COLOUR COLOUR COLOUR COLOUR COLOUR COLOUR NAME NAME NAME NAME NAME NAME NAME ID ID ID ID ID ID ID NAME COLOUR COLOUR COLOUR COLOUR COLOUR COLOUR COLOUR NAME NAME NAME NAME NAME NAME NAME COLOUR NAME COLOUR COLOUR NAME COLOUR NAME COLOUR NAME COLOUR NAME COLOUR NAME COLOUR NAME COLOUR NAME COLOUR NAME COLOUR COLOUR COLOUR COLOUR COLOUR COLOUR COLOUR COLOUR COLOUR COLOUR NAME QTY NAME QTY NAME QTY NAME QTY NAME QTY NAME QTY NAME QTY NAME QTY QTY COLOUR COLOUR COLOUR COLOUR COLOUR COLOUR COLOUR COLOUR COLOUR QTY QTY QTY QTY QTY QTY QTY QTY QTY COLOUR COLOUR COLOUR COLOUR COLOUR COLOUR COLOUR COLOUR COLOUR QTY QTY QTY QTY QTY QTY QTY QTY QTY COLOUR COLOUR COLOUR COLOUR COLOUR COLOUR COLOUR COLOUR COLOUR QTY QTY QTY QTY QTY QTY QTY QTY QTY 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 QTY QTY QTY QTY


SELECT Count(*) FROM sale where color = ′Green′ SELECT Count(*) FROM sale where color in (′Green′, ′Red′)


SELECT SUM(qty) FROM sale

(2 * 64) + (3 * 32) + (2 * 16) + (1 * 8) + (3 * 4) + (2 * 2) + (3 * 1) = 283

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

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

Typy sloupcových indexů o Mnoho různých typů – Více indexů na jednom sloupci

o o o o o o

Bitový index pro sloupce s malou kardinalitou Bitový index pro sloupce s velkou kardinalitou a malou selektivností Indexy pro sloupce s velkou kardinalitou G-Array (příbuzný B-tree) Prosté komprimované uložení dat (pro textové řetězce) Speciální indexy pro čas a datum Indexy pro joiny, porovnání a další operace

Sybase IQ – uložení dat a indexů

500

Velikost databáze (GB)

450

Indexy Sumace Čistá data

400 350 300 250 200 150 100 50 0 Čistá data

CBRD

o Indexy jsou už data o Nízké náklady na uložení dat o Rychlé zpracování malého množství dat

Tradiční RDBMS

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

FASMI - Fast Analysis of Shared Multidimensional Information o Alternativní název pro OLAP reportingová prostředí o Fast – –

Rychlá odezva, obvykle do jednotek sekund , maximálně několik desítek sekund Delší odezvy odrazují od analýzy, snižují zapojení uživatelů

o Analytical – – –

Uživatelsky přívětivá schopnost analýz Nevyžaduje programování Podpora dostatečného množství funkcí a neprocedurálních modelů

o Shared – –

Podpora bezpečnosti až na úrovni buňky Read-write model

o Mutlidimensional – – –

Podporuje multidimensionálního pohledu na data Star-, respektive snow-flake schéma Podpora více hierarchií

o Information – –

Schopnost zpracovat velké množství informací RAM a disk požadavky. Integrce s DWH

FASMI test BI platformy o o o o o o o o o o o o o o o o o o

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

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

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

Příklady dodavatelů OLAP serverů o o o o o o o

MS Analysis Services IBM Cognos Oracle OLAP option Hyperion Essbase Business Objects MicroStrategy SAS

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

Teradata basic


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

Architektura „Shared nothing“

Parsing engine (PE) BYNET

AMP 1

AMP 2

AMP 3

AMP 4

RAM

RAM

RAM

RAM

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ů

Fyzická architektura BYNET Node 1 with AMPs

Node 2 with AMPs

Node 3 with AMPs

Node 4 with AMPs

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

Přidělování diskového prostoru DBC

Celkem 1TB

100 GB

SYSDBA 300 GB

INVENTORY

CUSTOMER

SALES

100 GB

150 GB

200 GB

ORDERS

CAMPAIGN

50 GB

100 GB

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

Distribuce řádků tabulky

333 445 545 687

100 564 999 578

Ano Ano Ano Ano

201 560 408 227

313 875 770

Ne Ne Ne Ne

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

No

Yes

Required extra processing overhead

No

Yes

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

Fallback

AMP 1

AMP 2

AMP 3

Fallback

AMP 4

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.

Industriální logické modely o o o o o o o o

Teradata Communications Logical Data Model Teradata Financial Services Logical Data Model Teradata Healthcare Logical Data Model Teradata Insurance Logical Data Model Teradata Manufacturing Logical Data Model Teradata Media Logical Data Model Teradata Retail Logical Data Model Teradata Transportation and Logistics Logical Data Model o Teradata Travel and Hospitality Industry Logical Data Model o Teradata Utilities Logical Data Model

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.

Aplikace podle obchodních požadavků o o o o

Business Intelligence Data Mart Consolidation Master Data Management Tax and Revenue Management

o o o o

Customer Relationship Management Data Mining and Analytics Enterprise Risk Management SAP Integration

o Data Governance o Data Warehouse Migration o Financial Management

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

Reporting


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

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 o o o

Definice grafických prvků Návrh technologií Proces vývoje a implementace Proces správy reportovacího prostředí

Uživatelé o Uživatelské skupiny

Požadavky uživatelů o Uživatelé – Množství uživatelů – Uživatelské skupiny  Operativní reporting  Dashboardy  Scorecards  Analýzy  Události

o Srozumitelnost o Rychlost dodání – Nového reportu – Dat

o Bezpečnost – Přístup k datům – Přístup k vytvořeným reportům – Přístup k systému

o Uložení reportů – Repository – Správa

o Formáty o Způsoby doručení o Metadata – – – –

Použití reportů Dostupnost reportů Popis informací Popis zdrojů reportu

o Vývoj – Vlastní reporty – Konfiguace z předpřipravených komponent – Metodiky – Proces vývoje – Technologie – Testování

o Různé zdroje dat

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

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

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

Hierarchie reportů

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

Technologie o Nejrozšířenější – Microsoft Excel (Microsoft BI řešení)

o Zavedení dodavatelé – – – – –

SAP Business Object Microstrategy IBM Cognos SAS institute Oracle Business Intelligence Discoverer

o Inovátoři – QlikTech (QlikView) – GoodData

o „Opensource“ – Tableau – JasperSoft

Gartner Magic Quadrant for Business Intelligence Platforms

Technologie o o o o o o

Ověřená škálovatelnost do 200000+ named uživatelů Plugin do portálů Tisíce reportů Plně publikované webové rozhraní SDK Jednotná metadatová vrstva pro všechny typy reportů Dodávka a export reportů

o Podpora vývoje a verzování

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 Přenosové pásmo – Data – Reporting server – Reporting server – Klient – Data – Klient

o Uložení výsledků

o Datový server o Reporting server – Dedikovaný server – Uložení v databázi u dat

o Klient – Tlustý klient – Webový klient – Excell

– Na serveru – Na klientovi

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

Grafické prvky o Záhlaví o Tabulka

Období 2011/02 2011/03 2011/04 2011/05 2011/06 2011/07 2011/08 2011/09 2011/10 2011/11 2011/12 2012/01 2012/02

Min. 0.50 0.60 0.40 0.70 0.80 0.80 0.70 0.60 0.90 1.00 1.10 1.20 1.00

Schvalování (ve dnech) 95 Perc. Median 2.10 1.70 2.20 1.67 2.10 1.76 2.30 1.90 2.50 1.65 2.10 1.45 1.90 1.30 2.20 1.40 2.30 1.60 2.25 1.63 2.10 1.60 2.10 1.65 2.10 1.55

SLA 2.00 2.00 2.00 2.00 2.00 2.00 2.00 2.00 2.00 2.00 2.00 2.00 2.00

Grafické prvky 180

25.0%

Utilizovaná kapacita - Trend

160

20.0%

140 120

15.0%

100 80

10.0%

60 40

5.0%

20

0.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 2012

Kvadrant Sigma x Účinnost procesů NAO (MTD) 100.0%

Administration (Follow Sign.) Účinnost procesu (v %)

o Trend o Porovnání

Documentation 90.0%

80.0%

Draw-Down 70.0%

Administration Approving 60.0%

50.0%

40.0% 2.0

2.1

2.2

2.3

2.4

2.5

2.6

2.7

2.8

2.9

3.0

3.1

3.2

3.3

3.4

Úroveň Sigma (σ) Objem nákladů

3.5

3.6

3.7

3.8

3.9

4.0

4.1

4.2

4.3

4.4

4.5

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

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

Dashboard Navigation: Executive Dashboard → Core Process Dashboard NAO – Process Sec. Loans Applications

Process Dashboard – Admin. of Sec. Loans Applications Period: February February 2012 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

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?

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

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ů

Procesy správy reportovacího prostředí o o o o o o

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

Co si zapamatovat o o o o o o

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

Data Mining


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?

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!

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ů

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

Vstupy

Model Výstupy

Typy modelů o Analytický srozumitelný model o Vysvětlitelný postup a způsob získání výsledků

Vstupy

𝑎𝑖 𝑒 −𝑖𝜔𝑡

Výstupy

o Učící se konstrukce umělé inteligence o Těžko vysvětlitelný postup získání výstupů

Vstupy

Black box

Výstupy

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

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?

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.

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

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.

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

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.

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

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á

Příklady

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.

Doporučování obsahu o Obchodník chce zjistit, které položky zákazníci nakupují společně. o Podle aktuálního obsahu nákupního košíku, nalézt zboží (službu), kterou by mohl zákazník také chtít. – Internetový obchod nabízející zboží. U každé zobrazené položky zobrazuje další zboží, které zákazníci v minulosti nakoupili se zobrazenou položkou.

o Předpoklad: zákazníci nakupují stále stejné kombinace zboží (služeb). o Předpoklad na data: historie zakoupených položek. o Přístup – časté množiny a asociační pravidla. o Výsledkem je pak množiny zboží, které zákazníci nakupují dohromady. – Mohu zákazníkovi přímo nabízet zboží, o které by mohl také mohl koupit. – Informace o se také dá využít v marketingu (například zlevnit jeden druh zboží a výšit tak prodej spojeného druhu zboží).

o Amazon.com o Tesco

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.

Porovnání modelů pro churn

Churn – rozložení segmentace

Vysoké útraty

Nízké útraty Přeplatek

Přes tarif

V rámci tarifu

Aktivní

Konzervativní


Čím se liší DataMining od Reprotingu Proces vytěžování dat Metody data miningu Kritické body úspěchu vytěžování dat

14 RNDr. Ondřej Zýka,

Recommend Documents