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 Ř6) Teradata ve spolupráci NCR uvádí databázový počítač 1991 – HW – 2.5" 100MB disk 1992 – Oracle 7 – referencial integrity, triggers 1993 – Microsoft – Win NT 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

)ákaz í i a uživatelé

ODS Operač í data

Datová kvalita

MDM

Integra ce

DWH Jed ot ý odel Ko plet í historie I tegrova á data

Byz ys, te h ologi ká a provoz í

etadata

Governance – pravidla, orga izač í struktura, pro esy

Prostředí datově orientovaného systému Etapy život ího yklu

Komponenty

Skupi y uživatelů

Vlast í i aplika e

Plá ová í

Aplikač í progra y

Vývoj

Interface

Datový ar hitekt

Testová í

DBMS

Vývojáři

Provozová í

Data

Ad i istrátoři data ází

Udržová í

Hardware

Systé oví ad i istrátoři

Uko če í používá í

Ar hitekti IT, Aplikač í, …

Ko oví 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

www.profinit.eu

Diskuse

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 i for a e k dispozi i e o s ad o získatel é

Odpovídající velikost a granularita dat

Zda velikost dat a jejich granularita odpovídá vyko áva ý úlohá

Věrohodnost

Zda jsou i for a e pokládá y za pravdivé a důvěryhod é

Úplnost

Zda žád á data e hy í a zda jsou dostateč é rozsáhlá a detail í pro vyko áva é úlohy

Výstižná reprezentace

Zda repreze ta e dat

Konzistentní reprezentace

Zda jsou data repreze tová a vždy ve stej é

Snadnost zpracování

Zda jsou i for a e s ad o zpra ovatel é a použitel é pro rozdíl é úlohy

Bezchybnost

Zda jsou i for a e a data přes é a hod ověr é

Interpretovatelnost

á vhod ou strukturu for átu

Zda je jas á defi i e i for a í, zda jsou v odpovídají í oz ače y správ ý i sy oly

jazyku, jed otká h a zda jsou

Objektivita

Zda jsou i for a e estra

Relevantnost

Zda jsou i for a e použitel é a užiteč é pro vyko áva é úlohy

Reputace

é a epředpojaté

Zda jsou i for a e považová y za spolehlivé v souvislosti s jeji h zdroje obsahem

Bezpečnost

Zda o eze í přístupu k datů

Včasnost

Zda jsou pro vyko áva é úlohy i for a e k dispozi i včas

Srozumitelnost

Zda jsou i for a e s ad o po hopitel é a srozu itel é

Přidaná hodnota

Zda a která data a i for a e jsou pří os é a jaké jsou výhody jeji h použití

a i for a í

odpovídá ezpeč ost í

e o

pravidlů

DQ issues

Management a Finance

Marketing

Vlast í i systé ů

IT

Nutnost udržovat velké finanční ne o technické rezervy

Nepřesná seg entace zákazníků

Duplicity v datech

Vysoká náročnost nalezení požadovaných infor ací

Nekonzistentní reporty napříč organizací

Drahé a neúčinné ka paně

Nekonzistence mezi systé y

Ne ožnost dohledání původu dat a zodpovědných pracovníků

Reporty s nedůvěryhodný i daty

Nízká kvalita služe pro zákazníky

Chy ějící ne o nedohledatelné údaje

Nespokojenost uživatelů s dodávaný i infor ace i

Rozhodnutí učiněná na základě špatných infor ací

Nepořádek v zákaznických datech

Zastaralé i for a e

Neschopnost řešit konzistentně vady v datech

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í

www.profinit.eu

Diskuse

Metadata


Co to jsou metadata

Chybějící metadata

Doplněná metadata

Co o metadatech říkají autority Řízení etadata je nepochy ně nejdůležitější z dvanácti schopností, které usí í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í ISOŘŘ5ř2 na kódování UTFŘ? – Pokud místo Y/N začneme používat A/N, co všechno musíme zkontrolovat?

Metadata - analýza o Lineage analýza

o Katalóg

Where – used analýza

Cíle správy metadata ? 1. Jak je poje

defi ová ?

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

Controllers Auditors

Managers

?

1. Co vše usí upravit při z ě ě zdrojového systé u?

Analysts Architects

Developers

2. Které vše h y reporty usí opravit, když z ě í defi i i sloup e? 3. Co se sta e, když havaruje toto ETL?

ízení metadat •Byz ys slov ík •Datové odely •Pro es í odely •Orga izač í struktura

•SAP •Oracle •Data á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í

www.profinit.eu

Diskuse

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

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

Integrační přístupy

o Který systém má pravdu o Proč má pravdu

o Jaké jiné hodnoty jsou/byly v některém systému zadány o Kdy a jak se měnily hodnoty, kdo je měnil (který systém)

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ří hozí 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 Auto ati ké dávkové e o realti e zpra ová í. Čiště í, i tegra e, Sta dardiza e,…

Zdroj A

Zdroj B

Zdroj C

Data Exceptions Warehouse

Správa výjimek

Master System of Record Datová integrace Auto ati ké dávkové e o realti e zpra ová í. Čiště í, i tegra e, Sta dardiza e,…

Zdroj A

Zdroj B

Zdroj C

Master Databáze

Správa výjimek

Nové aplikace

Master Registry Datová integrace Auto ati ké dávkové e o realti e zpra ová í. Čiště í, i tegra e, Sta dardiza e,…

Zdroj A

Zdroj B

Registr

vazeb

Zdroj C Správa výjimek

Nové aplikace

Synchronization

Zdroj A

Datová integrace Auto ati ké dávkové e o realti e zpra ová í. Čiště í, i tegra e, Sta dardiza e,…

Zdroj B

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ů

www.profinit.eu

Diskuse

Ú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

Zákazníci a uživatelé

ODS Operační data

Datová kvalita

MDM

Integra ce

DWH Jednotný odel Ko pletní historie Integrovaná data

Byznys, technologická a provozní

etadata

Governance – pravidla, organizační struktura, procesy

Architektura DWH

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

Jádro

Jednotný odel Ko pletní 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

www.profinit.eu

Diskuse

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 ízení strategie o Porozumění BI komunitě o ízení požadavků o ízení architektury o ízení vývoje o ízení provozu o ízení rozpočtu a získávání zdrojů o Definování metrik o Nástroje

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í

www.profinit.eu

Diskuse

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ěle od pri ár í h systé ů

2

Data v datové

3

DWH o sahuje histori ká data za dlouhý časový úsek.

4

DWH obsahuje snapshoty k přes ě defi ova ý

5

Data v DWH jsou su jektově

6

DWH data jsou urče a pri ár ě ke čte í. ) ě y dat jsou je o se jed á o i sert dat.

7

Život í yklus DWH je říze daty (nikoliv procesy).

8

DWH o sahuje ví e úrov í granularity dat.

9

DWH očekává „ álo“ select opera í ad velký i o je y dat.

skaldu jsou i tegrova á

10 DWH obsahuje systé

oka žiků .

ikoliv age dově orie tova á.

pro vyhledává í zdrojů, tra sfor a í a

dávkové a pri ár ě

ísta ulože í dat.

11 Metadata DWH o sahují popis vše h datový h prvků, zdroje, tra sfor a e, i tegra e, ulože í, vaz y a historii vše h datový h ele e tů. 12 DWH u ožňuje přidělovat a zpoplatňovat využití svý h zdrojů jed otlivý i uživateli.

Zákazní i a uživatelé

ODS Operační data

Datová kvalita

MDM

Integra ce


Byznys, te hnologi ká a provozní

etadata

Governance – pravidla, organizační struktura, pro esy

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

ízení nákladů

Efektivita práce

OPEX

ízení rizik

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

Finanční řízení

Automatizace procesů

...

Křížový prodej

Detekce podvodů

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č í ar hitektura Datová ar hitektura Te h ologi ká 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 ě í í trh „lo argin“ business zákaz ík: dlouhodo ý vztah zákaz íků: 100.000+ konkurence, mzdy,....


Výnosy

Náklady Rizika


Výnosy

Náklady Rizika


Retence klientů

Akvizice klientů


Produktový vývoj


Scoring & Rating

ízení nákladů

Efektivita práce

OPEX

ízení rizik




...

Křížový prodej

Detekce podvodů

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ěle a saturová e istuje odliv zákaz íků áklady a ového zákaz íka

Akvizice klientů

Retence klientů

Výnosnost na klienta

...


Výnosy

Náklady Rizika


Retence klientů

Akvizice klientů


Produktový vývoj


Scoring & Rating

ízení nákladů

Efektivita práce

OPEX

ízení rizik




...

Křížový prodej

Detekce podvodů

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

ízení nákladů

Efektivita práce

OPEX

ízení rizik




...

Křížový prodej

Detekce podvodů

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

Zákazní i a uživatelé

ODS Operační data

Datová kvalita

MDM

Integra ce


Byznys, te hnologi ká a provozní

etadata

Governance – pravidla, organizační struktura, pro esy

OLTP x DWH OLTP systé y

Datový sklad

Aplikač ě orie tova á

Před ět ě orie tova á

Detail í data

Agragova á e o vypočítáva í data

Přes é hod oty, výz a Slouží provoz í

v do ě zpra ová í

pra ov íků

Historie, data za o do í, snapshoty Slouží

a ažerů

M oho z ě – update

)az a e ává se historie, update je ový záz a

Opakují í se zpra ová í

Časté ad-ho a alýzy

Přede z á y a defi ová y požadavky a data a procesy

Větši a požadavků e í přede

Sta dard í vývojový yklus aplika e

Požadova ý agil í vývojový yklus

Přístup k jed otlivý

Přístup k velké

záz a u

Orientace na transakce

z á a

oži ě záz a ů ajed ou

Orie ta e a a alýzu

OLTP x DWH OLTP systé y Výko ost je e tré organizace

ě důležitá pro provoz

Datový sklad Vol ější ároky a výko zpra ová í

ost de

í

Práva vlast íků dat a z ě u jsou důležitá

) ě a je provádě a te h ologi ký i uživateli

Požadová a vysoká dostup ost

Nižší požadavky a dostup ost

Spravuje se jako celek

Spravuje se po logi ký h částe h

Redu da e dat je ežádou í or alizova é odely

Redu da e je ěž á de or alizova é modely)

Stati ká struktura, varia il í o sah

Fle i il í struktura

Malé o je y dat

Velké o je y dat

Orientace a každode

í ruti u

Orie ta e a a alýzy a plá ová í

ODS x DWH ODS

DWH

I tegrova á data

I tegrova á data

Pře íra á data

Vyčiště á data

Orientace po oblastech

Orientace po oblastech

Bez historie

Ko plet í historie

Z ě y v date h

Bez z ě

Bez agregace

Agregova á data

Tra sakč í load dat

Dávkový load dat

I for ač í zdroj o záz a e h

A alyti ké aplika e

O ous ěr á ko u ika e

Jed os ěr á komunikace

Uživatelé systémů OLTP

ODS

DWH

Provoz í pra ov í i Střed í a age e t

Provoz í pra ov í i Klienti Part eři

Střed í a age e t Vr hol ý management

Vývoj složitosti DWH

Big Data

Dotazy, Reporty,

1980

A alyti ké aplikace

A alyti ké aplikace

Data mining

Data mining

Data mining

Multidimenzi o ál í a alýza




MIS

MIS

MIS

MIS

MIS

Dotazy, Reporty,

Dotazy, Reporty,

Dotazy, Reporty,

Dotazy, Reporty,

Dotazy, Reporty,

1990

2000

2010

Architektura DWH

Stage Obraz vstupní h dat Záloha dat pro zpra ování Datová kvalita

Jádro

Jednotný odel Ko pletní historie

Scheduler a dohled

Data Marty Podle analyzovaný h pro esů 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

Clean Build & * Detect Transf * Build

Step 1

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

* Backups

IMS

Step 6

Step 7

Delta

* 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 ř. 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

www.profinit.eu

Diskuse

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

ešení časové platnosti záznamu. ešení více hierarchií. 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

www.profinit.eu

Diskuse

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

www.profinit.eu

Diskuse

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

www.profinit.eu

Diskuse

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

Výhody

P a r t

P a r t

P a r t

1

2

3

View

Table

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

Bennet

Chet

101

B2

Ringer

John

144

C1

1212,2

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

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

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

www.profinit.eu

Diskuse

Teradata basic


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

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

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

www.profinit.eu

Diskuse

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

Executive Dashboard →

–

Celková kapacita

Utilizovaná kapacita

účinnost ů NAO Nevyužitá kapacita v %

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

www.profinit.eu

Diskuse

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

Porozu ění problematice Definování hypotéz

Porozu ění dat Dostupnost a obsah

Příprava dat For át, integrace Dodávka řešení

Data Vý ěr odelů Modelování

Vyhodnocování výsledků

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

www.profinit.eu

Diskuse

1. Co to je Data management, jaḱ jsou jeho hlavń slǒky? Je soubor činnost́ pro zajištěń dat. Konzistentń, přesný, autoritativń, aktuálń a kompletń pohled na kĺčová data Pravidla - zodpovědnosti, bezpečnosti, vývoje Procesy - Plánovać, vývojov́, ř́d́ć, provozń Technologie - Databáze, zálohovać syst́my

2. Jaký je rozd́l mezi daty a informacemi Data jsou podmnǒinou informać, informace nám odpov́ na KDO?, CO?, dá se d́ky nim pochopit vztahy mezi daty (přidávaj́: časový rámec, relevance, format, definice)

3. Jaký je rozd́l mezi informacemi a znalostmi Informace jsou podskupinou znalost́. Znalosti přidáváj́ k informaćm: vztahy, vzory a trendy, předpoklady.

4. Jak se pozná, ̌e jsou data kvalitń? Pro kǎdou ćlovou skupinu jsou data jinak kvalitń, podle toho jakou maj́ pro skupinu hodnotu Obecně lze ř́ct, ̌e by data měla splňovat následuj́ć parametry: Přesnost, Úplnost, Včasnost, Jedinečnost, Konzistentnost

5. a. b. c. d.

Uvěte čtyři zp̊soby, jak je mǒń přistoupit k zlepšeń kvality dat. Přeneseń probĺmu na ǔivatele Jednorázov́ řešeń Poǔit́ aktuálńch dat, pomoć nástroj̊ Předejit́ probĺmu

6. Co to jsou metadata? (Odpově̌ „Data o datech“ je nedostatečná) Metadata jsou strukturovań informace, kteŕ nám umǒňuj́ naj́t informace o datech, spravovat je, kontrolovat je a porozumět jim.

7. a. b. c. d.

Uvěte čtyři základń činnosti práce s metadaty. Sběr a údřba Integrace Prezentace Analýza

8. a. b. c. d.

K čemu sloǔ́ metadata? K porozumněń mezi ǔivateli dat a informać K plánováń zálohováń a obnovy dat K ohodnoceń ceny ulǒených dat a celkov́ ceny vlastnictv́ (TCO) k zjednodušeń dopadových analýz

9. Kteŕ jsou nejd̊lěitějš́ pǒadavky na syst́my pro datovou integraci.

1

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

10. Popište, č́m se liš́ MDM koncepty Master Reference data a Master System of Records. 1. jmenovaný komunikuje pouze jedńm směrem a data jsou ukládána do datov́ho skladu, druhý syst́m pracuje s databáź a poskytuje určitý druh zpětń vazby. obr: přednáška 4 str 28,29

11. Jaká jsou hlavń rizika integračńch projekt̊. 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́ka, př́lěitost pro podvod

12. Uvěte kriticḱ faktory, kteŕ je nutń brát při integraci dat z v́ce syst́m̊. exterń dodavateĺ vyšš́ slǒitost syst́mu Nároky na př́pravu

13. Co to je MDM. K čemu v organizaci sloǔ́ a proč je d̊lěit́? Master data management - řízení kmenových dat Správa klient̊ Správa produkt̊ správa centrálńch č́selńk̊ umǒňuje sdrǔit a udřovat úplná, přesná a směrodatná data v ceĺm podniku a distribuovat tyto informace

14. Popište základń komponenty architektury datov́ho skladu. Stage - obraz vstupńch dat, datová kvalita Jádro - jednoduchý model, historie Data Marty - dimenze a metriky, agregovaná data

15. Jaḱ jsou tři hlavń dimenze prostřed́ Business Intelligence (BI) v organizaci Business valve- informace dodávań kmenovým ǔivatel̊m Technology - poǔit́ technologie BI monotory - organizačń struktura

16. Co to je BICC a jaḱ jsou jeho hlavń zodpovědnosti Business Intelligence Competency Center Detailń popis entit jednotná agregace

17. Jaḱ jsou hlavń rozd́ly mezi OLTP aplikacemi a Datovým skladem detailń data

agregovaná data

2

mnoho změn standartń vývoj jednotliv́ záznami transakce

známá historie update = insert agilń metody vývoje mnǒiny záznam̊, analýza

18. Co to je ETL, k čemu sloǔ́ Extract - načteń relevantńch dat ze zdrojov́ho syst́mu Transformation - transofrmace dat do podoby poǔ́vań v DWH, vytvořeń umělých kĺč̊, historizace, čištěń dat Load - načteń dat do DWH

19. K čemu sloǔ́ oblast STAGE v datov́m skladu 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́č̊

20. Definujte hlavń vlastnosti modelu jádra datov́ho skladu. 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

21. Doplňte tabulku (jḿna sloupc̊, primárń kĺč a data) tak, aby nesplňovala prvń normálń formu (1NF - Kǎdý atribut obsahuje pouze atomicḱ hodnoty - adresa neń atomická) AUTHOR_ID (PK)

Jmeno

Prijmeni

Adresa

101

Franta

Lala

Pivni 34, Ceske Budejovice, 37001

102

Albin

Pucmidratek

Rumova 123, Pisek, 39701

103

Ludvik

Blabla

Ulice 456, Mesto, 34501

104

Blazej

Hou

Ulice 40, Mesto, 34501

22. Doplňte tabulku (jḿna sloupc̊, primárń kĺč a data) tak, aby splňovala prvń normálń formu a nesplňovala druhou normálń formu (2NF - kǎdý neprimárń atribut je plně závislý na ceĺm primárńm kĺči, tzn. na AUTHOR_ID i na KNIHA_NAZEV, nesplňuje Bydliste_autora ani Pocet_stran_knihy) AUTHOR_ID (PK)

KNIHA_NAZEV (PK)

Bydliste_autora

Pocet_stran_knihy

101

Kniha_1

Ceske Budejovice

672

102

Kniha_2

Praha

1225

3

103

Kniha_3

Amsterdam

211

104

Kniha_4

Hnojuvky

432

23. Doplňte tabulku (jḿna sloupc̊, primárń kĺč a data) tak, aby splňovala druhou normálń formu a nesplňovala třet́ normálń formu. (3NF - Všechny neprimárń atributy muś být vzájemně nezávisĺ, nesplňuje Pocet_obyvatel - je závislý na Bydliste_autora a tud́̌ tranzitivně závislý na AUTHOR_ID) AUTHOR_ID (PK)

Prijimeni_autora

Bydliste_autora

Pocet_obyvatel_bydliste

101

Lala

Ceske Budejovice

95000

102

Pucmidratek

Praha

1000000

103

Blabla

Amsterdam

800000

104

Hou

Hnojuvky

432

24. Uvěte alespoň tři krit́ria, kteŕ je nutno brát v úvahu při výběru primárńho kĺče: jedinečnost v rámci tabulky,nesḿ být null, nelze z něj odebrat ̌ádný atribut aby se neztratila jedinečnost, časový invariant - v čase neměnný

25. Jaká je vazba mezi referenčń integritou a ciźm kĺčem v databázi referenčń integrita je zajištěna pomoć ciźho kĺče mezi tabulkami Jasně stručně wiki

26. Popište co to je databázový pattern. Odzkoušeń a doporučeń zp̊soby, jak řešit často se vyskytuj́ć pǒadavky

27. Jaḱ databázov́ patterny znáte? Přiřazeń roĺ Klasifikace N-árń relace Dědičnost

28. Jaḱ řešeń pro pattern Roĺ se poǔ́vaj́, jaḱ maj́ slab́ a silń stránky? Nejjednodušš́ řešeń - kǎdá role jiná entita Slǒitějš́ řešeń – (umǒňuje) odstraněń redundance informać o osobách a organizaćch. PARTY ROLE je rodičovská entita pro všechny role.

29. Popište co nejjednodušš́ pattern přiřazeń roĺ. Popište jeho slab́ a silń stránky. Nejjednodušší řešení - každá role jiná entita 4

Vlastnosti - asi i zároveň silné stránky • 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 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.

30. Jaḱ řešeń pro pattern klasifikace se poǔ́vaj́, jaḱ maj́ slab́ a silń stránky podpora členěń instanć entity podle typ̊ do kategorí a taxonomí

31. Popište co nejjednodušš́ pattern klasifikace. Popište jeho slab́ a silń stránky popis: veškeŕ info obsahuje jedna entita silń: Velice jednoduchý model, snadno pochopitelný pro všechny ǔivatele, Vhodný jako základ (prototyp), odrazový m̊stek pro pochopeń a podrobnějš́ analýzu, slabe: -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);

5

32. Jaḱ jsou hlavń rozd́ly relačńho a dimenzionálńho modelováń? Kǎdá entita má vlastń tabulku originálń data

rozděluje data do logických fakt̊ a na mnoho dimenź

33. Popište krit́ria, kteŕ je nutń brát v úvahu pro výběr správńho patternu. Ř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.

34. Dimenzionálń model sloǔ́ primárně: a. Pro Analyticḱ DB b. Pro Aplikace vy̌aduj́ć zpracováń velḱho mnǒstv́ dat 35. Mezi výhody dimenzionálńch model̊ patř́ a. Srozumitelnost pro koncov́ho ǔivatele b. Jsou podporovań analytickými nástroji c. Jsou snadno rozšiřitelń

36. Popište pojem dimenze v dimenzionálńm modelováń. Jsou tabulky, kteŕ obsahuj́ seznamy hodnot sloǔ́ćch ke kategorizaci a tř́děń dat ve faktových tabulkách Konformń, časová, statická, rostouć př. knihy, obchody

37. Popište pojem faktov́ tabulky (metriky) v dimenzionálńm modelováń. Tabulky s analyzovanými daty, obsahuj́ detailń údaje ze všech zdroj̊, spojeny pomoć ciźch kĺč̊ s dimenzemi aditivń, semiaditivń, nonaditivń př. počet prodaných knih

38. Co to je Star sch́ma v dimenzionálńm modelováń. Jednoduch́ datov́ sch́ma Obsahuje jednu nebo v́ce faktových tabulek odkazuj́ć na dimenzionálń tabulky Speciálń př́pad sch́ma sněhov́ vločky (snowflake schema)

6

39. Jaký je doporučený postup při návrhu dimenzionálńho modelu? a. Výběr sledovaných proces̊ b. Určeń granuality c. Určeń dimenź d. Určeń metrik (faktových tabulek) e. Definice źskáváń dat 40. Který z uvedených typ̊ neń typ tabulky fakt̊? b) Pr̊bě̌ná transakce

41. Uvěte př́klad aditivńmi, semiaditivńmi a neaditivń metriky v dimenzionálńm modelu. aditivń - ceńková cena semiaditivń - kusy, součty cen nonaditivń - sazba, maře

42. Uvěte základń tři typy dimenź poǔ́vań v dimenzionálńch modelech. Konformń Minidimenze a sběrń dimenze Degenerovań dimenze

43. Co to je „slowly changing dimension“ (druh́ho typu)? V Type 2 Slowly Changing Dimension, je nový záznam přidán do tabulky představuj́ć nov́ informace. Proto, bude př́tomen i p̊vodń a nový záznam má sv̊j vlastń primárń kĺč. Výhody: máme kompletń historii záznam̊ Nevýhody: toto zp̊sob́, ̌e velikost tabulky bude rychle r̊st. V př́padech, kdy je počet řádk̊ v tabulce velmi vysoký, m̊̌e zač́t probĺm s pamět́ a výkonem Hezká ukázka tabulky zde (Version nebo Start_date a end_date)

44. Popište strukturu jednoduch́ho bitmapov́ho indexu a jeho poǔit́. relativně dobře vysvětleno na wiki nebo zde ● ●

poǔit́ v př́padě, pokud má daný sloupce ńzkou kardinalitu dat (např. pohlav́ M/F) poǔit́ hlavně pro read-only tabulky - přepočet bitmap indexu je náročná operace

45. Jak a k čemu se poǔ́vá klauzule with? WITH dovoluje v dotazu specifikovat “poddotazy” a ty nejak pojmenovat (WITH neco AS (SELECT blabla)).

7

Zdroj: link

46. Co to jsou agregačń funkce v př́kazu select? Uvěte př́klad. - Zpracovávaj́ hodnoty z celých sloupc̊ tabulky - Vytvář́ jednu hodnotu ze skupiny záznam̊ SUM, MIN, MAX, COUNT, AVG SELECT SUM (Plat) AS ‘Platy celkem’ FROM Zamestnanci (secte vsechny hodnoty ze sloupce Plat z tabulky Zaměstnanci a vypise je. AS ‘Platy celkem’ je alias - pojmenuje sloupec ve výpisu hodnotou v uvozovkách (nemuś tam v̊bec bejt, ale vypadá to hezky))

47. Co to jsou analyticḱ funkce v př́kazu select? Uvěte př́klad. http://www.root.cz/clanky/cte-a-analyticke-funkce-v-postgresql/ AVG, MIN, MAX

48. Co to je OLAP databáze? OLAP (Online Analytical Processing) je technologie ulǒeń dat v databázi, která umǒňuje uspořádat velḱ objemy dat tak, aby byla data př́stupná a srozumitelná ǔivatel̊m zabývaj́ćm se analýzou obchodńch trend̊ a výsledk̊ (Business Intelligence). Zp̊sob ulǒeń dat se svým zaměřeńm liš́ od bě̌něji ǔ́vańho OLTP (Online Transaction Processing), kde je d̊raz kladen předevš́m na snadń a bezpečń ukládáń změn v datech v konkurenčńm (v́ceǔivatelsḱm) prostřed́. Dobrej krátkej článek na wiki

49. Co to je Data profiling a k čemu se poǔ́vá? Analýza dat a úprava metadat za účelem zvýšeń výkonu či rozš́řeń funkcionality. Zdroj: http://en.wikipedia.org/wiki/Data_profiling

50. Co to je sloupcov́ ulǒeń dat (sloupcov́ indexy)? Pro co jsou vhodń? Bitový index pro sloupce s malou kardinalitou o Bitový index pro sloupce s velkou kardinalitou a malou selektivnost́ o Indexy pro sloupce s velkou kardinalitou G-Array (př́buzný B-tree) o Prost́ komprimovań ulǒeń dat (pro textov́ řetězce) o Speciálń indexy pro čas a datum o Indexy pro joiny, porovnáń a dalš́ operace

51. K čemu sloǔ́ popisy datových tok̊ v datově orientovaných syst́mech organizace? K vizualizaci, co je vstupem/výstupem jednotlivých komponent, kdo komunikuje s kým, kde je co ulǒeno.

52. Jaḱ typy analýz metadat znáte? K čemu jednotliv́ typy analýz sloǔ́? Dopadová analýza (Pokud ḿsto Y/N začneme poǔ́vat A/N, co všechno muśme zkontrolovat?) 8

Lineage analýza - Upstream (kdo si vsechno bere data odnekud?) / Downstream (jaká data se podileji na hodnoceni?)

53. Uvěte alespoň dva př́stupy a dvě technologie poǔ́vań pro indikaci změn v datech v rámci integrace. Timestamp Fronta událost́ Technologicky (triggery) Aplikačně

54. Jak se pozná, ̌e jsou data nekvalitń? Nesplňuj́ technicḱ a významov́ pǒadavky na kvalitu dat ?? Podstatná vlastnost pro hodnotu dat – Malá vypov́dać hodnota – Chybń výsledky

55. Kdy a jak vzniká nekvalita dat? a. Při zadáń dat b. Při předáváń dat mezi syst́my c. Časem d. 56. Kdo a jak pozná, ̌e jsou data nekvalitń? Uvěte př́klady nekvality dat. Neń v přednášce odpově̌ podle mě: Osoba, která s daty pracuje

9

57. Co to je profiling dat? K čemu se poǔ́vá? Analýta dat a úprava metadat za účelem zvýšeń výkonu či rozš́řeń funkcionality. Zdroj: http://en.wikipedia.org/wiki/Data_profiling

58. Co to jsou byznys metadata? K čemu sloǔ́? a. Jednotný slovńk organizace b. Komunikace i. Mezi odděleńmi ii. Mezi Byznysem a IT iii. Řešeń výjimek c. Pǒadavky i. Schvalovać proces ii. Diskuse iii. V́ce druh̊ slovńk̊

59. Co jsou operačń metadata a k čemu sloǔ́? a. jedná se o popis jednotlivých výsledk̊ během r̊zných operać v datov́m skladu b. př́kladem m̊̌e být ETL proces kdy pomoć operačńch metadat je zaznamenáván čas spuštěń, čas ukončeń, s jakými daty bylo manipulováno, atd.

c. zachycuj́ jak a kdy je datový sklad aktualizován a vyǔ́ván (Zdroj: http://czm.fel.cvut.cz/vyuka/A4M33CPM/Download/Metadata.pdf, slide 5)

60. Jaḱ typy analýzy metadat se poǔ́vaj́? a. Data Lineage b. Upstream Kteŕ aplikace poǔ́vaj́ centrálńch č́selńk měn?

c. Downstream Která všechna data se pod́lej́ na ohodnoceń spolehlivosti dodavatele?

d. Inpact analysis e. Kteŕ všechny tabulky a aplikace se budou muset upravit, kdy̌ přejdeme f.

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?

10

61. Jaký je rozd́l mezi synchronńm a asynchronńm předáváńm dat? Asynchronń ● V jednom okam̌iku maj́ r̊zń syst́my r̊zná data ● Technologicky jednodušš́ ● Nǐš́ pǒadavky na pr̊chodnost syst́mu ● Messaging Synchronń ● Zaručuje konzistentń stav ve všech syst́mech pro všechny ǔivatele ● Výpadek jednoho syst́mu ovlivňuje všechny ostatń ● Dvojfázový commit

62. Jaký je rozd́lel mezi Federativńm a Mediativńm př́stupem k integraci dat? Federation ● Syst́m umǒňuje (vynucuje) aby pǒadavky vznikaly jeho prostřednictv́m a rozprost́rá je do jednotlivých syst́m̊. ● MDM aplikace Mediation ● Reaguje se na změny v jednotlivých syst́mech a ty se předávaj́ ostatńm syst́m̊m ● Messaging ● Replikace

63. Jaký je rozd́l mezi Point-to-point a Hub-and-spoke integračńm modelem? Hub-and-Spoke: Výrazně méně tras je potřeba k obsloužení sítě síť. To je proto, že počet dvojic v P2P síi se zvyšuje při větší rychlosi než nárůst v uzlech. Vzhledem k tomu, že je méně cest, za předpokladu, že počet letadel je stejný, si může letecká společnost naplánovat častější lety podél každé cesty a plně využít schopnosi každého letadla. Centralizace operace na HUB vede k úsporám z rozsahu. Point-to-Point: Minimalizuje připojení a cestovní čas. Také, protože tam je méně transferů zavazadel, se tam bude méně vyskytovat chybějící zavazadlo.

(zdroj přednáška Integrace dat)

11

popis z netu, vysvetľovań na letových linkách:

64. Jaḱ techniky se poǔ́vaj́ při indikaci dat, kteŕ je nutno přenášet v rámci integrace?

12

65. Jaḱ jsou hlavń probĺmy při vzniku nov́ho záznamu v integračńm syst́mu? a. Neúplný záznam b. Nekonzistentń záznam c. Duplicitń záznam 66. Jaḱ jsou hlavń probĺmy při změně záznamu v integračńm syst́mu? a. Porušeń konzistence b. Rozpoznáń nezměněń polǒky c. Vytvořeń duplicity, neúplńho záznamu 67. Jaḱ jsou hlavń probĺmy při zrušeń záznamu v integračńm syst́mu? v́ce typ̊ zrušeń. logicḱ zrušeń/fyzicḱ/rozsah zrušených hodnot/vznik nekonzistenć.

68. Jak se poǔ́vá datová kvalita při integraci dat z v́ce syst́m̊? větš́ datová kvalita = vyšš́ priorita

13

14 RNDr. Ondřej Zýka,

Recommend Documents