Oficiální zadání práce

Oficiální zadání práce Proveďte rešerši postupů používaných v bankovním sektoru při provozování master data management hubu pro podporu procesu underwritingu klientů. Navrhněte postupy, které zajistí dostatečnou datovou kvalitu při provozování těchto systémů a zvolte nejvhodnější řešení. Vytvořené postupy musí být zasazeny do kontextu reálných okolních systémů a jejich požadavků. Navržené řešení ověřte pomocí vlastní implementace a otestujte vhodnými metodami.

i

ii

České vysoké učení technické v Praze Fakulta elektrotechnická Katedra počítačové grafiky a interakce

Diplomová práce

Zajištění datové kvality v master data management hubu pro podporu underwritingu Bc. David Krkoška

Vedoucí práce: Ing. Pavel Náplava

Studijní program: Otevřená informatika, Magisterský Obor: Softwarové inženýrství a interakce 26. dubna 2012

iv

v

Poděkování Děkuji vedoucímu práce Ing. Pavlovi Náplavovi za odbornou podporu, děkuji i vedení společností Adastra s.r.o. a Ataccama s.r.o. za poskytnutí literatury a licencí svých produktů. Děkuji také kolegům z obou jmenovaných firem za sdílení know-how a pomoc při řešení konkrétních problémů při návrhu a implementaci práce.

vi

vii

Prohlášení Prohlašuji, že jsem práci vypracoval samostatně a použil jsem pouze podklady uvedené v přiloženém seznamu. Nemám závažný důvod proti užití tohoto školního díla ve smyslu §60 Zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon).

V Praze 26. dubna 2012

.............................................................

viii

Abstract This thesis deals with Data Quality issues in a Master Data Management hub. In this extensive scope it focuses on the banking domain and more specifically on the support of underwriting processes. The thesis is divided into two parts. The first one introduces essential terms and possible methods of solution. The latter part is practical and involves analysis and especially design of suitable software architecture for sample implementation. This implementation demostrates the solution of given problem and can be deployed to real environments. As a result of the thesis, completely functional and tested component for Master Data Center programme has been created. Different approach to the support of underwriting is considered to be the main contribution of the thesis. It is based on using Master Data Management hub and emphasizing Data Quality monitoring and assurance.

Abstrakt Práce pojednává o zajišťování datové kvality v Master Data Management hubu. V této rozsáhlé problematice se omezuje na doménu bankovnictví a v ní na podporu underwritingu. Je rozdělena do dvou částí. První popisuje nezbytnou teorii zaměřenou na klíčové pojmy a používané postupy. V rámci druhé, praktické, části je provedena analýza a zejména návrh vhodné softwarové architektury pro ukázkovou implementaci, na které je problém demonstrován a kterou je možné nasadit v praxi. Výstupem práce je funkční otestovaná komponenta vyvinutá v programu Master Data Center. Za hlavní přínos práce je možné považovat jiný pohled na řešení podpory underwritingu, založený na využití Master Data Management hubu a důrazu na sledování a zajišťování datové kvality.

ix

x

Obsah 1 Úvod 1.1 Motivace projektu . . . . . . . . 1.2 Představení řešeného problému . 1.3 Vymezení cílů diplomové práce . 1.4 Popis struktury diplomové práce

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

1 1 1 2 2

2 Specifikace problematiky a domény 2.1 Podstata underwritingu . . . . . . . . . . . . . 2.2 Master Data Management a proces unifikace . . 2.2.1 Master Data Management . . . . . . . . 2.2.2 Unifikace . . . . . . . . . . . . . . . . . 2.3 Doména bankovnictví . . . . . . . . . . . . . . 2.4 Datová kvalita a její význam . . . . . . . . . . 2.4.1 Úvod do datové kvality . . . . . . . . . 2.4.2 Pojem datové kvality v diplomové práci 2.5 Typické situace . . . . . . . . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

5 5 5 6 7 8 9 9 10 11

3 Možnosti řešení 3.1 Problematika metodik a existujících řešení . . . 3.2 Datová kvalita při unifikaci klientů . . . . . . . 3.2.1 Používané postupy . . . . . . . . . . . . 3.2.2 Příklady best practices Ataccama . . . . 3.3 Datová kvalita na atributech a jejich skupinách 3.3.1 Dimenze datové kvality na atributech . 3.3.2 Příklady best practices Ataccama . . . . 3.4 Dostupné nástroje pro datovou kvalitu . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

13 13 14 14 18 19 20 23 23

4 Analýza řešení 4.1 Analýza procesů toků dat a míst aplikování datové kvality . . . . . . 4.1.1 Kdy je nejúčinnější aplikovat datovou kvalitu . . . . . . . . . 4.1.2 Proces nahrávání dat do MDM hubu z hlediska datové kvality 4.1.3 Reálné zdroje vstupních dat . . . . . . . . . . . . . . . . . . . 4.1.4 Typy entit, jejich stavy a způsob uložení . . . . . . . . . . . . 4.2 Případy užití . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3 Negativní vymezení funkčností . . . . . . . . . . . . . . . . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

27 27 28 28 30 31 31 34

xi

xii

OBSAH

4.4 4.5

Analýza číselníků (etalonů) a zdrojů znalostních informací . . . . . . . . . . . 35 Metrika datové kvality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

5 Návrh a architektura řešení 5.1 Zjednodušený MDM hub . . . . . . . . . 5.2 Datový model . . . . . . . . . . . . . . . 5.2.1 Model, třídy a atributy . . . . . 5.2.2 Stabilní referenční klíče . . . . . 5.3 Návrh řešení . . . . . . . . . . . . . . . . 5.3.1 Základní představení . . . . . . . 5.3.2 Podrobnější rozebrání komponent 5.4 Nasazení . . . . . . . . . . . . . . . . . . 5.5 Výběr nástrojů a technologií . . . . . . . 5.5.1 Unifikační repository . . . . . . . 5.6 Podpůrné služby . . . . . . . . . . . . . 5.6.1 Logování . . . . . . . . . . . . . . 5.6.2 Číselníky . . . . . . . . . . . . . 5.7 Simulace externích systémů . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

37 37 38 38 42 42 42 44 54 55 56 56 56 57 58

6 Realizace 6.1 Postup realizace . . . . . . . . . . . . . . . . . . . . . . . 6.1.1 Použitý model . . . . . . . . . . . . . . . . . . . 6.1.2 Časové rozložení . . . . . . . . . . . . . . . . . . 6.2 Další praktické informace k realizaci . . . . . . . . . . . 6.2.1 Jazyky a forma realizace . . . . . . . . . . . . . . 6.2.2 Vývojové prostředí, možnosti a omezení nasazení 6.2.3 Plány MDC . . . . . . . . . . . . . . . . . . . . . 6.2.4 Souborová struktura projektu . . . . . . . . . . . 6.3 Ukázka realizace . . . . . . . . . . . . . . . . . . . . . . 6.3.1 Příklad . . . . . . . . . . . . . . . . . . . . . . . 6.3.2 Přínos pro underwriting . . . . . . . . . . . . . . 6.3.3 Problémy a úskalí při realizaci . . . . . . . . . . . 6.4 Integrace a vývojové testování . . . . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

61 61 61 62 62 62 62 63 65 66 66 68 69 69

. . . . . . . . . . .

71 71 71 72 72 73 73 76 78 80 80 80

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

7 Testování 7.1 Míra chybovosti . . . . . . . . . . . . . . . . . . . 7.2 Ověření chybovosti . . . . . . . . . . . . . . . . . 7.2.1 Testy a dimenze datové kvality . . . . . . 7.2.2 Způsob ověření chybovosti . . . . . . . . . 7.2.3 Vstupní data . . . . . . . . . . . . . . . . 7.3 Testovací plán . . . . . . . . . . . . . . . . . . . . 7.4 Výsledky testů . . . . . . . . . . . . . . . . . . . 7.4.1 Hodnocení testů . . . . . . . . . . . . . . 7.5 Testování výkonnosti . . . . . . . . . . . . . . . . 7.5.1 Problémy . . . . . . . . . . . . . . . . . . 7.5.2 Porovnání variant načtení inkrementálních

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . dávek

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

OBSAH

xiii

7.5.3

Zlepšení výkonnosti

. . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

8 Závěr

83

Literatura

85

A Seznam použitých zkratek

87

B Důležité definice a pojmy

89

C Scénáře k případům užití

91

D Instalace řešení D.1 Potřebné nástroje . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D.2 Konfigurace MDC a databáze . . . . . . . . . . . . . . . . . . . . . . . . . . . D.3 Spuštění v MDC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

95 95 95 97

E Externí číselníky E.1 Registr adres UIR-ADR . . . . . . . E.2 Registr ekonomických subjektů RES E.3 Číselníky pro jména a příjmení . . . E.4 Ostatní číselníky . . . . . . . . . . . F Obsah přiloženého CD

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

99 99 99 100 101 103

xiv

OBSAH

Seznam obrázků 1.1

Příklad reálného problému při poskytování úvěru. . . . . . . . . . . . . . . . .

2

2.1 2.2 2.3 2.4

Stručné schéma typického řešení Master Data Managementu. . . . . Modelové množiny vstupních dat do unifikace. . . . . . . . . . . . . . Ukázka modelově unifikovaných dat. . . . . . . . . . . . . . . . . . . Primární funkční požadavky na řešení, odvozené z underwritingových

3.1 3.2 3.3 3.4

Efekt zřetězení při unifikaci – před a po přidání záznamu 2. . . . . . . . . . Definované prahy score rozdělují ohodnocení záznamů do tří skupin. . . . . Příklady vztahů domén V1 a V2 dvou atributů. . . . . . . . . . . . . . . . . Nejvýznamnější tvůrci nástrojů pro datovou kvalitu dle společnosti Gartner.

4.1 4.2

Procesní diagram nahrávání dat do MDM hubu z hlediska datové kvality. . . . 29 Diagram případů užití. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8

Datový model řešení. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Diagram komponent jádra řešení. . . . . . . . . . . . . . . . . . . . . . . . . . Detailní design komponenty DQTool. . . . . . . . . . . . . . . . . . . . . . . . Detailní design komponent clean_sub2sub, clean_address a clean_document. Detailní design komponenty clean_contact. . . . . . . . . . . . . . . . . . . . Detailní design komponenty clean_subject. . . . . . . . . . . . . . . . . . . . . Detailní design komponenty match_subject. . . . . . . . . . . . . . . . . . . . Diagram nasazení. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6.1 6.2 6.3

Ukázka (výřez) MDC plánu. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Ukázka implementace části návrhu v plánu MDC – hádání typu subjektu. . . 64 Ukázka implementace části návrhu v plánu MDC – zpracování adresy a ukázka výrazu. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

7.1 7.2 7.3

Spuštění plánu v Master Data Center. . . . . . . . . . . . . . . . . . . . . . . 73 Spuštění testů v programu SoapUI a vizualizace výsledků. . . . . . . . . . . . 76 Vizualizace výsledku testů a rychlosti opravy nalezených chyb. . . . . . . . . 79

. . . . . 6 . . . . . 7 . . . . . 8 situací. 12 . . . .

15 17 22 24

39 43 45 47 49 51 53 54

D.1 Nastavení databázových spojení a cest k adresářům v MDC. . . . . . . . . . . 96 D.2 Spuštění standalone serveru v MDC pro vystavení on-line služby. . . . . . . . 98 E.1 CSV soubory pro jména subjektů.

. . . . . . . . . . . . . . . . . . . . . . . . 100

xv

xvi

SEZNAM OBRÁZKŮ

Seznam tabulek 3.1 3.2

Data pro ilustraci efektu zřetězení při unifikaci záznamů. . . . . . . . . . . . . 15 Některá unifikační pravidla používaná společností Ataccama. . . . . . . . . . . 19

4.1 4.2 4.3 4.4 4.5 4.6 4.7

Tabulka s jednotlivými kroky FIP. . . . . . . . . . . . . . . . . . . . . . . . . Popis případu užití „UC M01 – Přidat záznamy se zohledněním datové kvality“. Popis případu užití „UC M02 – Identifikovat záznamy se zohledněním datové kvality“. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Popis případu užití „UC I01 – Vyčistit a standardizovat záznamy“. . . . . . . Popis případu užití „UC I02 – Unifikovat záznamy“. . . . . . . . . . . . . . . . Popis případu užití „UC I03 – Vypočítat definované abnormality“. . . . . . . . Tabulka znalostních zdrojů a zdrojů číselníků. . . . . . . . . . . . . . . . . . .

5.1 5.2 5.3

Typologie atributů datového modelu s příklady. . . . . . . . . . . . . . . . . . 41 Vymezení identifikačních, diskriminačních a typových atributů datového modelu. 42 „Módy“záznamů v jednotlivých režimech. . . . . . . . . . . . . . . . . . . . . . 45

6.1 6.2 6.3

Příklad na konkrétních datech – vybrané vstupní atributy entity subjektu a adresy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 Příklad na konkrétních datech – atributy obou entit po čištění. . . . . . . . . 67 Příklad na konkrétních datech – atributy obou entit po standardizaci. . . . . 67

7.1

Plány, vstupní a výstupní data pro jednotlivé kroky testovacího plánu. . . . . 75

C.1 C.2 C.3 C.4 C.5

Scénář případu užití „UC I03 – Vypočítat definované abnormality“ . . . . . . Scénář případu užití „UC I01 – Vyčistit a standardizovat záznamy“ . . . . . . Scénář případu užití „UC I02 – Unifikovat záznamy“ . . . . . . . . . . . . . . Scénář případu užití „UC M01 – Přidat záznamy se zohledněním datové kvality“ Scénář případu užití „UC M02 – Identifikovat záznamy se zohledněním datové kvality“ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

30 32 33 33 34 34 36

91 92 92 93 94

E.1 Přehled CSV souborů pro jména subjektů, ta mohou být i víceslovná. . . . . 101 F.1 Obsah přiloženého CD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

xvii

xviii

SEZNAM TABULEK

Kapitola 1

Úvod 1.1

Motivace projektu

V poslední době si bankovnictví prošlo řadou větších či menších krizí, které přirozeně vyústily v tlak na větší efektivitu a úspornost fungování bank. Jedním z velmi aktuálních témat je poskytování úvěrů klientům. Jednotlivé žádosti jsou mnohem podrobněji přezkoumávány, aby se zamezilo úvěrovým podvodům. A zde si vedení bankovních ústavů začínají uvědomovat, že mají k dispozici obrovskou datovou základnu plnou hodnotných informací, jejíž možnosti zdaleka nevyužívají. Jedním z možných a v dnešní době oblíbených řešení je Master Data Management, který si představíme v dalších kapitolách. Autor práce se s touto problematikou seznámil díky zaměstnání v českokanadské společnosti Adastra s.r.o.1 , která se zabývá datovými řešeními, jako jsou datová integrace či Data Warehousing. Zde se autor přesvědčil, že každý velký projekt je novou výzvou. Je potřeba přizpůsobovat se nejnovějším trendům a reagovat na specifické požadavky a vlastnosti klientského prostředí u konkrétního zákazníka. Důvodů pro vybudování solidního datového řešení může být mnoho a finální architektura se proto značně odlišuje. Právě aplikování postupů Master Data Managementu pro zamezování úvěrových podvodů je zajímavou a ve společnosti Adastra neprozkoumanou oblastí, a proto se jí autor práce rozhodl věnovat ve své diplomové práci. Velikou znalostní podporu mohl čerpat ze zkušeností firmy Ataccama Software s.r.o.2 , se kterou spolupracoval na jednom z projektů.

1.2

Představení řešeného problému

Problematiku i důležité pojmy blíže popíšeme v kapitole 2, zde v úvodu pouze ukážeme jednoduchý příklad reálného problému při poskytování úvěru klientovi. Budeme ho ilustrovat pomocí obrázku 1.1. Tento obrázek ukazuje dva klienty jménem Novák ve dvou různých systémech – v bance a její dceřiné hypoteční společnosti. V první z nich je požádáno o úvěr. Není ale tento Novák, 1 2

Internetové stránky společnosti na http://www.adastra.cz/. Internetové stránky společnosti na http://www.ataccama.com/, společnost je součástí skupiny Adastra.

1

2

KAPITOLA 1. ÚVOD

Obrázek 1.1: Příklad reálného problému při poskytování úvěru.

klient banky, zároveň klientem hypoteční společnosti? Pokud by šlo o totožnou osobu, pak by vyhodnocení úvěru dopadlo zcela jinak kvůli zatížení hypotékou. Právě o těchto případech se v práci pojednává.

1.3

Vymezení cílů diplomové práce

Prvním cílem je představit problematiku a vymezit doménu bankovnictví, dále provést rešerši a na jejím základě popsat možná používaná řešení v bankovní doméně. Následně pak zanalyzovat a navrhnout konkrétní softwarovou architekturu pro praktickou část práce. Tato architektura musí splňovat všechny požadované atributy definované v předchozích podkapitolách (budiž explicitně uvedeno, že cílem není vytvářet Master Data Management hub či provádět hodnocení úvěrů, cílem je v nějakém existujícím hubu zajistit odpovídající datovou kvalitu). Návrh musí být dostatečně přesný, včetně použitých technologií, aby bylo možné řešení následně implementovat a určit, jak bude otestováno splnění všech daných požadavků.

1.4

Popis struktury diplomové práce

Diplomová práce je strukturována tak, aby kapitoly chronologicky popisovaly postupný vývoj řešení až po jeho modelové nasazení a otestování. Rozdělení textu odpovídá přibližně práci na pomezí návrhové a implementační – viz [15] s pokyny pro psaní diplomových prací. Zároveň jednotlivé kapitoly pokrývají výše uvedené cíle práce. V první, teoretické, části v kapitole 2 rozvedeme problém ze sekce 1.2 a představíme důležité pojmy a specifika bankovní domény. Rozepíšeme i typické situace, které by měly být při praktické realizaci práce pokryty. Následující kapitola 3 popisuje možnosti vyřešení daného problému. Praktická část práce začíná v kapitole 4 s analýzou řešení (slovo „řešení“ je chápáno ve smyslu „praktický výstup práce“), kde jsou na konci vytvořeny případy užití a definována

1.4. POPIS STRUKTURY DIPLOMOVÉ PRÁCE

3

metrika ověření splnění požadavků. Kapitola 5, návrh, vyjmenovává použité technologie a popisuje softwarovou architekturu pro následnou implementaci, která je shrnuta v kapitole 6. Problematika testování se nachází v kapitole 7. V přílohách je uveden nejen seznam použitých zkratek (A), ale i abecedně seřazené definice nejdůležitějších pojmů (B) používaných opakovaně v textu. Definovaný pojem je označen slovem „definice“ v horním indexu, např. underwritingdefinice . Výsledek realizace je k dispozici na přiloženém CD. Podrobnosti o obsahu souborů na médiu se nacházejí v dodatcích F společně s doplňujícími informacemi k analýze (C) a nutnou dokumentací (D a E).

4

KAPITOLA 1. ÚVOD

Kapitola 2

Specifikace problematiky a domény V této kapitole shrneme stručně tři důležité pojmy, underwriting, Master Data Management a unifikace. Blíže budou popsány pomocí postupů v dalších kapitolách. Dále vymezíme i specifické náležitosti zvolené domény, tedy bankovnictví. Budeme se podrobně věnovat datové kvalitě a jejímu významu. Vždy představíme skutečnosti v jejich obecné podobě a poté je aplikujeme na konkrétní potřeby práce, tedy na underwriting. Nakonec sestavíme seznam několika typických situací ve formě požadavků, které budou v kapitole 4 sloužit k určení případů užití projektu diplomové práce.

2.1

Podstata underwritingu

Pro odhalování problémových klientů a jejich potenciálních úvěrových podvodů (např. modelový příklad v podkapitole 1.2), se vžil pojem underwriting. Definici si vypůjčíme ze serveru www.wisegeek.com (viz [14]) a explicitně ji zde uvedeme: „Underwriting is the method that is utilized to evaluate the current eligibility of a customer to receive some type of financial product.“, neboli „Underwriting je metoda používaná k vyhodnocení aktuální způsobilosti zákazníka získat určitý finanční produkt.“ Úkolem underwritingu v modelovém příkladě v úvodu je zjistit, že klient má již u dceřiné společnosti hypotéku a že jsou u ní případně problémy se splácením, čímž banka zcela přehodnotí poskytnutí úvěru. Underwriting však musí reagovat i na mnohem složitější situace, tedy vzájemné krytí fyzických a právnických osob, krytí úvěrů mezi manželi apod. Právě těmito situacemi se bude diplomová práce zabývat1 .

2.2

Master Data Management a proces unifikace

Underwritingem jsme tedy nazvali postup, kdy se bankovní společnost chrání před zneužíváním svých služeb, konkrétně úvěrů. Ze situací uvedených výše v 2.1 vyplývá, že pro banku je klíčové sbírat a vhodně propojovat informace ze svých dceřiných společností a z dostupných 1

Pojem underwriting lze aplikovat i v ostatních finančních sektorech, např. v pojišťovnictví, nicméně práce se omezuje právě na bankovní sektor, tedy úvěrovou politiku.

5

6

KAPITOLA 2. SPECIFIKACE PROBLEMATIKY A DOMÉNY

systémů. Pak totiž může underwriting správně aplikovat. Proces shromažďování dílčích informací z jiných systémů a jejich seskupování nazveme procesem vytváření master dat definice . Shromáždění dat na jednom místě umožňuje využít řadu dalších možností na jejich zpracování. Proto jsou získaná data při načítání ze zdrojů (tzv. proces ETL, Extract – Transform – Load, tedy získání – přizpůsobení – uložení dat) zhruba v tomto pořadí nejprve: • vyčištěna, např. zbavena některých překlepů, • standardizována, např. telefonní číslo automaticky doplněno o předvolbu státu, • obohacena, např. o dopočítané hodnoty, což může být třeba poštovní směrovací číslo pro uvedenou adresu, • ohodnocena podle toho, jak moc jsou data v jednotlivých krocích modifikována. Nad takto upravenými daty se provádí operace seskupování (unifikace) a vyhledávání společných záznamů a potenciálních skupin záznamů, které patří k sobě na základě různých kritérií. Data se pak mohou deduplikovat nebo třeba poskládat z několika entit s použitím nejlepších dostupných hodnot.

2.2.1

Master Data Management

Výše popsané procesy a související problematika spadají pod tzv. Master Data Management definice (MDM). Systém pro jeho realizaci, typicky databáze a software na organizaci dat, pak nazveme Master Data Management hubdefinice . Stručnou představu o typickém MDM řešení podává ilustrace 2.1, která byla inspirována obdobnými obrázky 4-7 a 4-8 v [4].

Obrázek 2.1: Stručné schéma typického řešení Master Data Managementu.

Obrázek popisuje tok dat od zdrojů přes vstupní rozhraní, řešené typicky webovými službami nebo integrací Business To Business definice , dále výše popsané ETL, jehož výsledek je uložen spolu s metadaty definice do databáze. Přes obálku datových uložení a přístupovou

2.2. MASTER DATA MANAGEMENT A PROCES UNIFIKACE

7

vrstvu jsou data opět rozličnými způsoby distribuována do cílových konzumentních systémů a aplikací, jež se mohou shodovat se zdrojovými. Tolik tedy k obecné architektuře MDM hubů. Stručně jsme popsali, co se s daty z různých dceřiných společností a systémů děje při operaci ETL, aby mohla být použita pro účely underwritingu. Této „výrobní linky“ se ještě několikrát v práci dotkneme. Právě systematické zpracování dat a jejich seskupování (unifikování) je základní myšlenkou a největším přínosem MDM. Vnášíme totiž do dat nový rozměr jejich organizací do referenčních skupin. V rámci těchto skupin lze již lépe hodnotit rizikovost klientů, protože máme k dispozici jejich kompletní výskyty v rámci všech systémů, které nás zajímají.

2.2.2

Unifikace

Abychom dokázali skupiny zmíněné na konci předchozí podkapitoly vytvářet (neboli unifikovat definice nebo také záznamy párovat) s co největší přesností, musíme využívat možností výše zmíněné výrobní linky s čištěním, standardizací a dalšími kroky. Musíme také zvolit vhodná pravidla pro unifikační proces – tedy vybrat vhodná kritéria, aby se spárovala pokud možno všechna data, která patří k sobě (např. dva klienti z různých dceřiných společností představující jednu a tutéž osobu), zároveň ale nespárovat údaje, jenž k sobě nepatří (např. dva klienti se stejným jménem, ale jiným rodným číslem). Přiblížíme si unifikaci pomocí následujícího příkladu. Mějme dvě množiny dat (data budeme reprezentovat jako řetězce), které mohou představovat třeba dva různé zdrojové systémy. Množiny jsou znázorněny na obrázku 2.2, inspirovaném podobnou ilustrací v [9]. Za stejné záznamy budeme brát takové, které se dostatečně podobají a nejspíše reprezentují totožnou skutečnost. I v reálných systémech mohou záznamy obsahovat překlepy, prohození kolonek pro jméno a příjmení a řadu dalších změn.

Obrázek 2.2: Modelové množiny vstupních dat do unifikace.

Na dalším obrázku (2.3) je vidět příklad možné unifikace těchto množin. Dva prvky jsou již natolik odlišné, že k jejich spárování nedošlo vůbec. Z ilustrace je patrné, že párování prvků je provedeno jen s určitou pravděpodobností, ne vždy si můžeme být zcela jistí, že jsou data unifikována správně. V kapitole 3 jsou mimo jiné zmíněny i metody, jak sílu shody porovnávat. Princip unifikace a fungování výrobní linky v Master Data Management hubu je nutný k pochopení dalšího textu práce. Oba pojmy velice úzce souvisejí s datovou kvalitou definice (DQ) popsanou v podkapitole 2.4.

8


Obrázek 2.3: Ukázka modelově unifikovaných dat.

Poznamenejme ještě, že MDM řešení vyžaduje za unifikaci zařadit další proces – vytváření nových záznamů, reprezentantů, složených z nejlepších dostupných hodnot všech záznamů ve skupině. Tento krok však není pro potřeby diplomové práce nutný, proto se mu nebudeme věnovat.

2.3

Doména bankovnictví

Bankovnictví patří ke komplikovaným a náročným doménám kvůli několika specifikům. Jednou z nejdůležitějších otázek je zabezpečení. Tato problematika by však byla nad rámec rozsahu diplomové práce, proto pro nás není v tuto chvíli podstatná. Ovlivní jen výběr technologií – mělo by být v budoucnu možné zabezpečení jednoduše zajistit. Dále vyjmenujeme několik důležitých specifik dané domény, souvisejících ale přímo se zaměřením diplomové práce. Vycházíme především z vlastních zkušeností autora, případně zkušeností jeho firemních kolegů. Klasickým obrazem z bankovního světa je vnitřní IT struktura jednotlivých systémů. Banky patří k velkým společnostem a jsou v dnešní době na IT zcela závislé. Proto typicky používají desítky různých systémů s rozličnými úkoly, zahrnují různé dceřiné společnosti, které mají samozřejmě opět svá IT řešení. Vyvstává tudíž problém integrace a mnohotvárnosti získávaných dat proudících z nich do Master Data Management hubu. V bankovnictví lze také vysledovat jisté „kliento-centrické“ zaměření. Jinými slovy ve středu všeho databázového dění bude stát klient. Takto bude koncipován i modelový hub v této práci. Požadavky na datovou kvalitu budou vysoké, aby bylo možné mezi klienty, evidovanými v různých systémech, nalézt správné vazby a přiřadit je k sobě, tedy unifikovat. Zároveň je ale bankovní prostředí velice citlivé na chyby, hlavně v případném párování, kdy by se mohly informace dostat do rukou jiného klienta, s čímž se budeme muset vypořádat při návrhu podpory underwritingu. Celkově se bankovní prostředí vyznačuje velkou opatrností. Proto bude nutné provádět vývoj na testovacích datech, protože nebudeme mít k dispozici data produkční.

2.4. DATOVÁ KVALITA A JEJÍ VÝZNAM

9

Opatrnost bankovnictví vede vývojáře i k důkladnému testování návrhu i implementace řešení (tvrdá akceptační kritéria).

2.4

Datová kvalita a její význam

Datovou kvalitu jsme představili na konci sekce 2.2. Z definice v příloze B také vyplývá, že datová kvalita je relativní, odvíjí se od konkrétních potřeb zákazníka. Je tedy nutné podrobněji rozebrat význam a rozsah DQ v této diplomové práci.

2.4.1

Úvod do datové kvality

První kapitola knihy [13] začíná známou větou shrnující stav dat řady společností. „Promiňte, pane Smithi, ale podle našich záznamů jste už dávno mrtvý.“ Jde o vynikající humorné vyjádření problematiky datové kvality. O několik stránek dále autor uvádí, že špatná datová kvalita je v dnešní době obecným problémem. Datová řešení trpí relativně vysokou chybovostí (1 – 5%, což v případě milionů záznamů znamená nezanedbatelné číslo). Tato chybovost pak přirozeně vede ke komplikacím, jenž se projeví ve zvýšených nákladech společností. V době, kdy informace představují významné obchodní a strategické vlastnictví, je jejich nedostačující kvalita stále větším problémem. Na druhou stranu [7] upozorňuje, že definice datové kvality jako úrovně uspokojení potřeb zákazníka ukazuje i na druhou stranu mince. Nemá smysl vynakládat přílišné úsilí a prostředky na zkvalitňování nerelevantních dat (např. dat, která jsou zastaralá, která se často a rychle mění apod.). Tento fakt ještě více podtrhuje jistou subjektivitu v aplikaci postupů datové kvality v různých projektech. Dokonce může nastat situace, kdy dva zákazníci budou mít přesně opačné potřeby. Správně nastavená kvalita musí odpovídat konkrétním potřebám konkrétního projektu, i když lze samozřejmě vymezit mnohé obecné postupy. Více viz 2.4.2. V [13] jsou dále uvedeny dva základní principy, jejichž použití obvykle vede k produkování použitelných aktuálních dat s minimem nesprávných údajů. • Čištění dat, detekce a opravování chyb - Snaha získávat data, která co nejvěrněji odrážejí realitu. Můžeme je ověřovat např. poměrně neefektivním kontaktováním klientů, ale také využitím automatizovaných metod. • Optimalizace procesů získávání dat - Vylepšujeme samotný proces získávání a ukládání dat tak, abychom shromažďovali co nejkvalitnější data. Můžeme využívat pouze nejlepších a důvěryhodných zdrojů, při manuálním zadávání využít vestavěných našeptávačů apod. První způsob, tedy čištění dat, detekce a opravování chyb, je přímá metoda zlepšování datové kvality jak na vstupu, tak i při aplikaci na již uložená data. V [7] je kladen důraz především na čištění a standardizaci jednotlivých položek záznamů. Bez nich není možné provádět datovou unifikaci. Teprve čištění a standardizace zjistí, že telefonní čísla 00420111222333 a tel +42 01 11 22 23 33 jsou stejná nebo že názvy Nové Město nad Metují a Nové Město n. M. představují stejnou obec.

10


Dalším aspektem jsou validace dat. Nekvalitní položky jsou pak buď vyřazeny úplně, nebo alespoň označeny jako nepoužitelné. Tím dochází k ohodnocení záznamů, které opět ovlivní unifikační proces. Příkladem budiž zadané datum narození 30. 2. 2000. Doporučuje se zavádět co nejpřísnější kontrolu - lze omezovat domény, délky a rozsahy proměnných (nezáporný věk člověka, pravidla pro tvar e-mailových adres, pravidla pro délku a dělitelnost rodných čísel. . . ), lze kontrolovat výčtové hodnoty (ISO kódy zemí, kódy pro pohlaví osoby. . . ) anebo testovat i vzájemné hodnoty kombinací atributů (test, zda existuje zadaná ulice v daném městě) apod. Obdobně je dobré doplňovat chybějící data a záznamy tím obohacovat a kompletovat. Může jít třeba o zjištění data narození a pohlaví klienta na základě validního rodného čísla. Některé údaje lze doplnit z výčtových seznamů. Posledním aspektem je porovnávání dat z různých zdrojů. To je možné díky unifikačnímu procesu, jenž se tím pádem stává také nástrojem datové kvality. Druhý, procesní, přístup vychází z předpokladu, že výše uvedené postupy neberou v úvahu budoucí vzniklé chyby. Jestliže tedy chceme kontinuálně vylepšovat datovou kvalitu, musíme se zaměřit na procesy, které ji ovlivňují. Typickým případem je vytipování a správa méně důvěryhodných a k chybám náchylných zdrojů dat, např. manuálního zadávání položek na bankovní přepážce. Dále se dá určit rizikovost konkrétních sloupců a podle jejich váhy se zaměřovat právě na nejproblematičtější z nich. Problémy odstraňujeme především vydefinováním a sledováním nejobtížnějších částí procesu získávání dat. Jak takové části najít a jak v tomto procesu vymezit místa ovlivňující datovou kvalitu, rozebírá podrobně kniha [13], podle níž budeme postupovat v analýze toků dat v kapitole 4.

2.4.2

Pojem datové kvality v diplomové práci

V minulé podkapitole bylo řečeno, že datová kvalita je úzce spojena s konkrétním účelem konkrétního projektu. Nyní tedy propojíme bankovní doménu a uvedené skutečnosti a určíme, jaké atributy musí datová kvalita pokrývat, pokud má zajistit vhodná data pro underwritingové procesy. Vyjděme nyní ze specifikace bankovní domény v sekci 2.3. S integrací velkého množství rozličných systémů se musíme vyrovnat použitím co největšího množství postupů zajišťujících datovou kvalitu, viz 2.4.1. Důraz bude tedy kladen na správnou unifikaci. Budeme muset brát v úvahu problém, kdy nás doména vede k opatrnosti při párování klientů, ale underwriting na druhou stranu vyžaduje co možná nečastější párování, aby se zamezilo podvodným pokusům při žádostech o úvěr. Úkolem práce může být např. zajistit nastavení nějakého příznaku při vkládání „duplicitních“ záznamů o klientech, přestože se často na první pohled o duplicitu nejedná, např. je klient jednou uveden jako právnická a jednou jako fyzická osoba. Naše řešení musí na tuto skutečnost upozornit jako na nález datové kvality definice . Pro zachování kvality dat musíme takovou situaci odhalit. Zabývat se budeme pouze záznamy o klientech a bezprostředně souvisejícími entitami, např. adresou. Výše bylo zmíněno, že nemá smysl provádět optimalizaci datové kvality pro nepodstatné entity, jakými jsou pro účely této práce všechny ostatní.

2.5. TYPICKÉ SITUACE

11

Poznamenejme ještě, že datovou kvalitu v diplomové práci budeme řešit pro české prostředí.

2.5

Typické situace

Probrali jsme si a přiblížili problematiku domény související s diplomovou prací. Nyní odhlédneme od pojmů a zaměříme se zpět na underwriting. Jak bylo řečeno v úvodu práce, výsledkem má být řešení, které se postará o dostatečnou datovou kvalitu v provozovaném Master Data Management hubu tak, aby bylo možné vyhodnocování úvěrů provádět s co největším množstvím relevantních podkladů. Vymezíme nyní několik zcela typických situací, jež při underwritingu mohou nastat. Kvalita dat, kterou zajistíme v MDM hubu, musí reflektovat tyto situace a umožnit ve vhodné míře jejich underwritingové řešení. Přesnou podobu určíme až v analýze a návrhu – jestli např. budou podezřelé záznamy naším nástrojem datové kvality nějak označovány apod. Z těchto identifikovaných situací dále vytvoříme katalog čtyř primárních funkčních požadavků na řešení. Typické situace, které underwriting rozeznává, jsou následující. Seznam byl sestaven za použití [6], [16] a zkušeností autora práce. • Klient žádá o úvěr a má u nás více záznamů stejného typu – Klient je v hubu zaveden vícekrát pod stejným typem klienta, např. jako fyzická osoba. Díky tomu má vyplněny podobné atributy a lze ho lépe unifikovat. Při underwritingu se musí prověřovat všechny jeho instance. • Klient žádá o úvěr a má u nás zároveň záznam jiného typu – Klient je v hubu zaveden vícekrát, ale pod jiným typem klienta, např. jednou jako fyzická osoba pod svým rodným číslem a jednou jako podnikatel pod svým IČ. Identifikace při párování záznamů je obtížnější, ale při spolehlivém underwritingu se musí opět prověřit všechny instance daného subjektu. • Klient žádá o úvěr a jeho záznam je ve vztahu s jiným záznamem v našem systému – Klient je v hubu v různých rolích, např. může být manželem některé jiné klientky, jednatelem společnosti apod. Underwriting musí mít k dispozici i tyto vazby a prověřovat klienty na obou stranách vazeb, tedy při poskytnutí úvěru kontrolovat např. situaci dalších rodinných příslušníků. • Klient žádá o úvěr a jeho záznam vykazuje několik definovaných abnormalit – Datová kvalita by měla postihovat i situace, kdy klientský záznam vykazuje jisté abnormality. Z hlediska underwritingu jsou to časté změny adresy a kontaktních údajů a také „časté“ změny vazeb klienta (mohou vést na potenciální rozvody, narozené potomky, zahájená podnikání, změny pracovních míst a další situace vyžadující pozornost underwritera). Z těchto situací můžeme vymezit primární funkční požadavky na systém, které se nacházejí na obrázku 2.4. Navržené řešení datové kvality musí zajistit, že takové záznamy budou v systému odhalitelné.

12


Obrázek 2.4: Primární funkční požadavky na řešení, odvozené z underwritingových situací.

V příštích kapitolách 3 a hlavně 4 naznačíme, že čtyři zdánlivě jednoduché požadavky, mají-li být správně splněny, vyžadují mnohem větší komplexitu řešení, než se na první pohled zdá.

Kapitola 3

Možnosti řešení V kapitole 2 jsme stručně rozebrali a představili základní pojmy, se kterými budeme dále pracovat. Naznačili jsme, že v Master Data Management hubu pro podporu underwritingu klientů stačí zajistit takovou datovou kvalitu, abychom dokázali pokrýt jen několik málo požadavků. V této kapitole a poté v analýze 4 však ukážeme, že spojení „takovou datovou kvalitu“ musíme chápat jako komplexní problém, i když se na první pohled nezdá. Provedli jsme rešerši, na základě které projdeme problematiku metodik a existujících řešení a pak se zaměříme podrobněji na unifikaci klientů. Ta však očekává i splnění podmínek datové kvality na jednotlivých atributech (či skupinách atributů), které rozebereme hned v další podkapitole. Postupy, které zde uvedeme, je možné aplikovat na oba přístupy k datové kvalitě, datový i procesní (byly představeny v 2.4.1).

3.1

Problematika metodik a existujících řešení

Používané postupy v oboru datové kvality budeme rozebírat v celém zbytku této kapitoly. Žádný z těchto přístupů ale není formulován jako ucelená metodika. Pojem datové kvality je totiž velice úzce provázán s komerční sférou, ve které si jednotlivé společnosti chrání své knowhow, případně je daná metodologie spojena s konkrétní aplikací v nějakém nástroji komerční firmy, např. pro produkty rodiny WebSphere od firmy IBM (viz [4]). Pro použití mimo tento rámec nelze nalézt konkrétní metodiky 1 , pouze doporučené postupy a obecnější principy, jejichž kombinací se dosahuje požadovaných výsledků. Tento způsob používá i společnost Adastra (resp. Ataccama), jež nemá v současnosti zavedenou žádnou oficiální jednotnou metodiku datové kvality ve svých řešeních. Obdobně neurčité závěry získáme při pokusu zjistit, zda se problém underwritingu již někde pomocí MDM hubu řešil. Nepodařilo se dohledat žádné relevantní či zkonkretizované reference u komerčních společností (zmínka o využití MDM hubu a jeho infrastruktury pro 1 Je nutné neplést pojem zajištění datové kvality a jejího měření a vyhodnocení. V druhém zmíněném odvětví již totiž lze metodiky nalézt, např. [12], nicméně v diplomové práci nám pouhé monitorování nestačí, potřebujeme aktivně kvalitu ovlivňovat.

13

14

KAPITOLA 3. MOŽNOSTI ŘEŠENÍ

underwriting se nachází např. ve white-paper [10] či v informacích o produktu Informatica2 ), natož podrobnější informace o architekturách či úskalích jednotlivých řešení. Zkušenosti s MDM hubem jako takovým budou tedy čerpány z literatury a praxe autora práce – a bude provedena úprava pro potřeby underwritingových procesů.

3.2

Datová kvalita při unifikaci klientů

Již dříve bylo zmíněno, že poskytnutí kvalitních dat pro underwriting spočívá převážně v návrzích možného párování klientů tak, abychom dokázali odhalit maximum možných případů uvedených v předchozí kapitole. Dostupná literatura k dané problematice naráží na jeden fakt. Konkrétní pravidla pro unifikaci jsou jednak závislá na prostředí, ve kterém vznikají, tj. jiná mohou být v České republice a jiná bychom zvolili ve Velké Británii, stejně tak na účelu, za kterým jsou vytvářena, a v neposlední řadě jsou součástí know-how společností v daném oboru. Konkrétní podoba pravidel pro párování klientů zde tedy nebude podrobněji rozebírána. Podle [4] na stranách 254 až 287 a článku [9] ukážeme obecnější rady a postupy, jak unifikaci provádět. Pro lepší představu pak velice stručně uvedeme několik příkladů, jež patří k best practices společnosti Ataccama.

3.2.1

Používané postupy

Literatura [4] rozčleňuje relevantní klientské údaje do tří skupin. • Identifikační atributy – Atributy přímo použitelné pro párování, příkladem může být v českém prostředí třeba rodné číslo nebo u firem jejich IČ, adresa, jméno apod. Nevýhodou těchto identifikačních hodnot je především jejich obecná nestabilita a možnost změn (výjimkou je právě rodné číslo). • Diskriminační atributy – Atributy, které jsou naopak určeny pro zamezení spárování záznamů. Lze jimi odlišit např. otce a syna se stejným jménem i adresou prostým porovnáním data narození. Tyto hodnoty se narozdíl od identifikačních obecně zachovávají - zůstává neměnné datum narození, úmrtí, pohlaví osoby. . . • Typové atributy – Definují atributy, jež se budou používat při párování. Může jimi být kupříkladu typ osoby (právnická x fyzická), čímž určíme, zda se má párovat dle rodného čísla, nebo podle IČ. V jistém smyslu sem lze zařadit i pohlaví osoby a další. Příklad na filtraci dle typu ukazuje [9] na straně 445, kde se dle typu osoby vybírají vhodné identifikační atributy. Na párovaných záznamech pak určujeme jednotlivé typy atributů a vymezujeme, zda je vůbec možné unifikaci provádět. Máme-li např. k dispozici pouze jméno klienta, pak nelze ani určit, zda se jedná o fyzickou osobu, nebo podnikatelský subjekt a chybovost párování by byla veliká. Po vyřazení nekvalitních záznamů a rozčlenění atributů do skupin výše už můžeme přikročit k unifikaci. 2

Viz http://www.informatica.com/us/solutions/industry-solutions/financial-services/.

3.2. DATOVÁ KVALITA PŘI UNIFIKACI KLIENTŮ

15

Režimy unifikace Unifikace může probíhat v zásadě ve dvou režimech (viz [4]). Jejich konkrétní implementace se může, ale nemusí lišit. První režim předpokládá iniciální stav databáze. Máme velké množství neunifikovaných záznamů a potřebujeme je spárovat do skupin a každé z nich přiřadit unikátní klíč. Každý záznam je zařazen do nějaké skupiny, byť někdy pouze velikosti 1. Zpracování v praxi reálně může trvat několik hodin až dní a neprovádí se příliš často. V druhém režimu již máme údaje v databázi spárované a unifikaci provádíme pro nově přidané záznamy, typicky na každodenní bázi. Párování probíhá vzhledem k již existujícím skupinám. Snažíme se zařadit nový záznam do některé z nich, případně prohlásit, že je unikátní, a vytvořit pro něj skupinu novou. Ještě upozorníme na jednu skutečnost, která může při druhém režimu unifikace nastat – řetězení. Řetězením chápeme stav, kdy dojde ke spárování dvou záznamů, které by samotné nikdy unifikovány být nemohly. Propojí se díky třetímu záznamu, jež se připáruje ke každému z nich. Situace je ukázána na obrázku 3.1, jenž je obdobou nákresu 12-9 v [4], data k ní se nacházejí v tabulce 3.1. Č. záznamu 1 2 3

Jméno Petr Novák Petr Novák Petr Novák

... ... ... ...

Adresa Plzeňská 34, Praha 5 Plzeňská 34, Praha 5 Úzká 49, Brno

... ... ... ...

Rodné číslo 811227/0012 811227/0012

Tabulka 3.1: Data pro ilustraci efektu zřetězení při unifikaci záznamů.

Obrázek 3.1: Efekt zřetězení při unifikaci – před a po přidání záznamu 2.

Záznamy 1 a 3 by za normálních okolností nebyly připárovány k sobě a tvořily každý svou skupinu. Jakmile ale vložíme záznam 2 s vyplněnou adresou společnou se záznamem 1 a s rodným číslem společným se záznamem 3, vytvoří se nám jedna velká skupina a obě předchozí zaniknou.

16


Je patrné, že efekt řetězení je závislý na pořadí zpracování a může způsobit změnu většího množství údajů pouhým přidáním jednoho nového. Někdy nejsou tyto změny žádoucí a druhý režim lze proto ještě modifikovat tak, že záznam nezpůsobí přepárování ve stávajích datech, ale pouze ukazuje, do které skupiny by nový záznam nejspíše mohl patřit. Takto modifikovaná unifikace se nazývá identifikace, identify.

Binární matching, scoring Různé přístupy k unifikaci můžeme najít i v otázce posuzování párování. V [4] jsou nastíněny tři možné varianty. Liší se podle toho, jak rozhodují, zda nějaké atributy, resp. celý záznam, odpovídají atributům jiného záznamu, resp. celému jinému záznamu. Je nutné kontrolovat obojí shody, tedy jak jednotlivých atributů, tak i záznamu jako celku (shodují se křestní jméno i příjmení, ale musíme se podívat na celou entitu, jestli se třeba neliší rodné číslo). K posouzení se používají dvě metody: • Binární matching – Při porovnání shody dvou atributů/záznamů rozhodujeme pouze ANO/NE. • Scoring – Při porovnání shody dvou atributů/záznamů vypočítáváme score shody. Například pro dva řetězce může jít o jejich Hammingovu nebo Levenshteinovu vzdálenost, pro záznamy třeba údaj o počtu odlišných atributů. Kombinací těchto dvou možností pak dostaneme tři prakticky využitelné přístupy. • Binární matching pro jednotlivé atributy i pro celé záznamy – Atributy porovnává jednoduše na definovanou shodu a pro shodu celých záznamů definuje sadu pravidel, jejichž logickým vyhodnocením získáme ANO/NE rozhodnutí. Příkladem takového pravidla může být „Jestliže se shodují rodná čísla a příjmení, pak jsou záznamy považovány za totožné, pokud v záznamech neexistují dvě validní odlišná data narození“. • Binární matching pro jednotlivé atributy, scoring pro celé záznamy – Nejprve definujeme váhy pro jednotlivé atributy. Pak u nich získáme binární rozhodnutí o shodě. Pro celé záznamy pak spočítáme score započítáním vah shodujících se atributů. Výsledné score pak porovnáváme s definovaným prahem (viz obrázek 3.2 převzatý z [4], kde je ukázáno použití dvou prahů). • Scoring pro jednotlivé atributy i pro celé záznamy – Score celého záznamu je vypočítáno přes score určené při porovnávání jednotlivých atributů. Definují se prahy obdobně, jako v předchozím případě. Pojem „ jednotlivé atributy“ lze chápat i jako menší závislou skupinu atributů, třeba některé adresní komponenty.

3.2. DATOVÁ KVALITA PŘI UNIFIKACI KLIENTŮ

17

Obrázek 3.2: Definované prahy score rozdělují ohodnocení záznamů do tří skupin.

Párování na celých datech a na základě rozdělení do skupin Na unifikaci lze pohlížet i optikou výkonnosti. V literatuře [4] je provedeno porovnání dvou přístupů k výkonnostní stránce párování. Nejprve se věnujme „naivnímu“ přístupu, tedy klasickému párování bez optimalizací. V tomto případě je nutné porovnávat každý záznam s každým záznamem. Mějme jich N, na každém z nich M atributů použitých k porovnání a čas t potřebný k provedení jedné srovnávací operace nad jedním atributem. Celkový potřebný výpočetní čas T lze tedy získat následujícím vzorcem 3.1. Jeho součástí je i výpočet všech možných párovacích kombinací záznamů. T =t·M ·N ·

N −1 2

(3.1)

Lze snadno dosadit typické hodnoty získané praxí, např. M = 10, N = 107 a t = 10−8 s. Potřebný výpočetní čas je potom roven přibližně 57 dnům. Proto je nutné hledat cesty k optimalizaci unifikace. Používaným řešením je rozdělit data do menších skupin podle několika snadno vyhodnotitelných atributů ([4] volí počet atributů např. 3 a připouští rozpad na velké množství skupin). Podrobné párování pak již probíhá uvnitř skupiny, nepřesahuje za její hranice. Výhodou tohoto postupu je nejenom výrazné snížení počtu srovnávání, ale i možnost provádění párování ve více skupinách paralelně. Článek [9] pojmenovává tyto skupiny jako kandidátské a finální jako klientské. Tohoto pojmenování se budeme držet i v diplomové práci. Získání kandidátských a klientských skupin Zmíníme se o způsobu vytváření kandidátských a klientských skupin, jak je naznačeno v [3]. Nejprve se věnujme obecnějším, kandidátským skupinám. Jaké tedy existují seskupovací strategie? • Simple Key – Máme-li k dispozici dostatečně silný klíč pro seskupování, stačí nám záznamy seskupit podle něj. Lze samozřejmě použít i více klíčů. Tato strategie je rychlá, ale pro komplexní případy až příliš jednoduchá.

18


• Hierarchical – Rozšíření předchozí strategie, pouze se v případě absence klíče na některém záznamu použije zástupný (může jich opět být i více). Používají se tudíž primární a sekundární klíče. Strategie je silnější než Simple Key, a proto si dokáže poradit s větším množstvím situací. • Classic Hierarchical – Téměř totožná s předchozí, jen jinak definuje podmínky nenalezení primárního klíče. • Union – Generuje velké kandidátské skupiny a může být velice pomalá. Skupina se skládá ze záznamů, kde pro každý z nich platí, že se shoduje alespoň s jedním dalším záznamem v alespoň jednom atributu z definované množiny. Je možné atributům přiřazovat různé váhy a tím z nich vytvořit primární a sekundární klíče. Z hlediska diplomové práce poznamenejme, že takto lze např. seskupovat klienta banky s jeho manželkou podle bydliště a k nim přisloučit záznam o jeho manželce ještě za svobodna podle rodného čísla. • Hierarchical Union – Kombinuje druhou a čtvrtou strategii. Definuje primární klíč a místo sekundárního pak množinu klíčů, které se chovají jako Union. Tato strategie je nejkomplexnější a umožňuje řešit i velice komplikované situace. V rámci kandidátských skupin pak vytváříme skupiny klientské. Algoritmus záznamy nejprve „seřadí“ a vybere ten „nejlepší“, tzv. center. Určí se prahy vzdáleností ostatních záznamů od centra. Pro ty vzdálené se určí nový center a takto rekurzivně dokud není celá kandidátská skupina rozdělena. Definice prahů a centerů jsou již specifické pro konkrétní účel a projekt.

3.2.2

Příklady best practices Ataccama

V předchozí podkapitole byly zmíněny různé postupy používané při unifikaci dat. Pro jejich praktické předvedení můžeme čerpat ze zkušeností společnosti Ataccama. Uvedeme několik drobných ukázek, jak vypadají některé zmíněné postupy v praxi. Vycházet budou ze zkušeností autora z projektu, na kterém se společností Ataccama spolupracuje. Z hlediska výše rozebraných postupů: Jsou použity shodné procesy pro všechny režimy unifikace. Používá binárně formulovaných podmínek a samozřejmě je umožněno paralelní zpracování díky hledání párování v kandidátských skupinách a ne v celém datovém souboru. Využívá se strategie Hierarchical Union. Specifika českého prostředí odráží volba pravidel, na základě kterých se ověřuje shoda záznamů při párování v rámci kandidátských skupin (ty se získají pomocí rodných čísel, jmen apod.). Podíváme se na pravidla používaná pro unifikaci fyzických osob. Fyzické osoby jsou unifikovány dle tří sad pravidel podle pohlaví (muž, žena, nevyplněná hodnota). Několik zajímavých z nich se nachází v tabulce 3.2, všechny se aplikují na typ pohlaví „muž“.

3.3. DATOVÁ KVALITA NA ATRIBUTECH A JEJICH SKUPINÁCH

Pravidlo rc+fn+ln rc+fn1+ln_short1 rc10digits+fn-1+ln

rc+full_name1w

rc+full_name1w1char

rc9digits+fn+addr/con/doc

19

Popis První, nejjednodušší pravidlo, shodují se rodné číslo a jména. Obdobné, ale tolerují se překlepy v krátkých příjmeních. Sedí rodné číslo a příjmení, ve jméně je povolen přidaný znak na začátku – pravidlo si poradí s chybně interpretovaným jménem „Ladislav“ a „Vladislav“. Symetrická diference s povolenou odchylkou na 1 slovo (slova samotná se ale musí shodovat přesně). Např. „PETR DANIEL“ vs „DANIEL PETR“, nebo „DAVID SVOBODA“ vs. „DAVID MATEJ SVOBODA“. Symetrická diference s tolerancí na odlišnosti znaků v rámci jednotlivých slov. Např. „Viliam Alexai“ vs. „Alexei Viliam“, nebo „ASSAD MOHAMAD“ vs „MOHAMAD MOHAMAD ASAAD“. Shoduje se staré rodné číslo, jméno a některá z dalších entit, tj. adresa, kontakt nebo identifikační dokument.

Tabulka 3.2: Některá unifikační pravidla používaná společností Ataccama.

3.3

Datová kvalita na atributech a jejich skupinách

Pro dobré párování očekáváme vstupní entity s atributy, jejichž datová kvalita je dostatečná. V této části rešerše se podíváme na kritéria a používané postupy pro zkvalitňování atributů a jejich skupin. V předchozí sekci 3.2, když byl rozebírán binární matching a scoring, bylo mimo jiné řečeno, že při párování se vždy vychází z porovnávání hodnot jednotlivých atributů nebo jejich malých skupin. V knize [4] je na straně 263 rozděleno toto porovnávání atributů do tří skupin uvedených níže. (Resp. do čtyř, poslední vychází z pravděpodobnostních rozdělení hodnot atributů. Např. lze předpokládat, že mezi českými klienty budou česká jména zastoupena častěji než jména cizí. Proto lze párování přes cizí jména považovat za přesnější – záznamy se jmény John Rowanleigh budou spíše patřit k sobě, než záznamy o Janu Novákovi. Zároveň je ale ve stejném zdroji poznamenáno, že v praxi je obtížné podobné heuristiky implementovat, a proto se používají málokdy.) • Přesná shoda – Atributy se shodují bez dalších signifikantních úprav. Provede se pouze odstranění přebytečných znaků, jako jsou mezery, opakované mezery, tabulátory apod. • Shoda po aplikaci obecných úprav – Atributy se shodují po předchozích úpravách a aplikaci různého počtu dalších obecných modifikací, může jít třeba o vyčištění (např. odstranění překlepů. . . ), standardizace a normalizace hodnot (např. úprava předvoleb telefonních čísel. . . ), převody hodnot (např. „ul.“ na „ulice“), dopočítání hodnot (např. data narození z rodného čísla. . . ) apod.

20


• Shoda po aplikaci znalostních úprav – Atributy se shodují po eventuálním použití předchozích typů úprav a následné aplikaci znalostních modifikací a obohacení. Důležité je, že k provedení těchto modifikací je zapotřebí nějaké další znalostní databáze, typicky číselníků. Klasickým případem pro české prostředí je Registr ekonomických subjektů (RES)3 , ze kterého lze doplňovat adresy a názvy subjektů s IČ, nebo Územně identifikační registr adres (UIR-ADR)4 , jenž může sloužit ke kontrole a doplňování chybějících údajů v adresách. Konkrétní postupy se odlišují podle toho, k jakému účelu chceme data použít, a podle prostředí. Jinak se např. budou upravovat telefonní čísla v České republice a jinak ve Spojených státech. Nebudeme zde tedy představovat jednotlivé možnosti, jak např. kontrolovat a zpracovávat e-mailové adresy apod. Důležité je, že před svým použitím data musejí projít nějakými úpravami, vymezenými v jednotlivých krocích v seznamu výše. Jako příklad uvedeme stručný popis práce s adresou opět jako best practices společnosti Ataccama v podkapitole 3.3.2. Úpravy se používají takové, aby bylo možné splnit jisté charakteristiky dat uložených v databázi. Tyto charakteristiky, dimenze, i s příklady uvedeme podle [13] v následující podkapitole.

3.3.1

Dimenze datové kvality na atributech

V datové kvalitě dotýkající se jednotlivých atributů a jejich malých skupin můžeme vymezit několik dimenzí. Jejich konkrétní realizace (a samozřejmě výběr dimenzí, které budou na daném projektu řešeny) je již úzce specifická na datových zdrojích i požadovaných datových výstupech. Obecně ale můžeme vymezit určité znaky kvalitních dat, o což se nyní pokusíme. Uvedeme jednotlivé dimenze. Některé z nich mohou být v konfliktu, protože zajišťují protichůdně zaměřená data pro různé účely. Dimenze z uživatelského pohledu Dimenze se týkají pohledu na data z hlediska jejich uživatele. • Relevance dat, jejich jasný obsah a konzistence – Data musí být shromažďována pro ten účel, jakému mají sloužit. Pro uživatele nemá smysl schraňovat gigabyty dat, která nejsou relevantní pro jejich rozhodování, business či použití, což se ovšem velice těžko plánuje s ohledem na budoucí využití. Také musí být jasné, k čemu jaká data slouží a jak jsou organizována. K tomuto účelu je nutná především kvalitní definice metadat. Pro ilustraci – musí být např. jasné, že pracovník patří do nějakého oddělení, zda-li může patřit do více oddělení najednou apod. • Rozsah – Tato dimenze těsně souvisí s relevancí dat – shromažďujeme pouze taková data, která potřebujeme. Ukládání většího množství dat bez užitku je ztrátové. 3

Seznam všech podnikatelských subjektů registrovaných v ČR, který poskytuje Český statistický úřad, viz http://www.czso.cz/csu/redakce.nsf/i/registr_ekonomickych_subjektu. 4 Seznam všech adresních bodů v ČR, který poskytuje Ministerstvo práce a sociálních věcí, viz http: //forms.mpsv.cz/uir/.

3.3. DATOVÁ KVALITA NA ATRIBUTECH A JEJICH SKUPINÁCH

21

• Granularita – Pro různé druhy uživatelů se používají různé granularity dat. Např. pokud je potřeba sledovat nepatrné změny v decimálních proměnných, pak musí být uloženy v databázi s dostatečnou přesností. Obdobně postačují-li managementu nejhrubější údaje, provozní oddělení bude jistě potřebovat mnohem větší detail informací. • Identifikace a homogenita – Data jsou co nejlépe identifikována a organizována. Každá entita musí být v úložišti jednoznačně určitelná. Zároveň by měla být homogenní s ostatními entitami, tedy atributy musí být aplikovatelné na co nejširší spektrum entit. • Reakce na změnu – Data musí být jasně označena ve svém životním cyklu (smazána, založena, aktualizována. . . ) a musí reagovat na změny domény (výčtové typy atd.), a to na vnitřní změny i změny z vnějšku. Dimenze z hlediska hodnot Dimenze se týkají hodnot, které jsou uloženy v jednotlivých atributech. • Úplnost – Týká se úplnosti informace, kterou atribut poskytuje. Musí být např. jasné, co znamená, že atribut není vyplněn, popř. že je uložen s hodnotou NULL. Třeba v případě atributu „příjmení za svobodna“: říká NULL, že údaj vůbec nebyl od klienta získán, nebo je klient svobodný a stačí proto vzít hodnotu současného příjmení? • Konzistence hodnot – Hodnoty skupiny atributů musí být vzájemně konzistentní. Tato dimenze úzce souvisí s přesností. Např. není vhodné mít u adresního záznamu uložené město a k němu nepříslušející poštovní směrovací číslo. Zároveň je dobré si uvědomit, že i když budeme mít k dispozici obě hodnoty a ony budou vzájemně jedna s druhou korespondovat, nemůžeme si být jistí, jestli nejsou obě chybné. Problémem je zvláště u méně známých dat odhadovat jejich možné závislosti. Jednou z cest je provést analýzy dat a vytvořit tabulky závislostí hodnot (neboli závislostí domén dvou atributů), jejich příklady se nachází na obrázku 3.3 (viz [13], str. 264). Na jejich základě je pak možné definovat omezení hodnot tak, aby byla zachována vzájemná konzistence. • Přesnost – Data musí co nejvíce korespondovat s realitou. U některých atributů je obtížné jejich přesnost ověřovat, nicméně je důležité údaje kontrolovat, jakmile k tomu bude příležitost (návrat zákazníka na pobočku, ověření dostupnosti telefonního čísla a e-mailu a další). Zároveň se provádějí kontroly oproti číselníkům a výčtovým seznamům možných hodnot jednotlivých domén. Speciálním případem jsou hodnoty určené k pravidelným aktualizacím. Přesnost p můžeme nad atributy ověřovat vzorcem 3.2. p=

počet správných hodnot počet všech hodnot

(3.2)

Dimenze reprezentace dat Dimenze se týká reprezentace dat. Odhlédneme-li od fyzického uložení, jde zejména o formát uložení. Formátem chápejme mapovací funkci f : V → S,

22


Obrázek 3.3: Příklady vztahů domén V1 a V2 dvou atributů.

kde V je konceptuální doména pro daný atribut a S je symbolická reprezentace prvků z domény. Právě formáty se zabývá dimenze reprezentace dat. • Vhodnost formátu – Data musí být reprezentována v takovém vhodném formátu, který umožní číst tato data strojově i člověku. Asi nebudeme do databáze ukládat obrázkové ikony třeba pro pohlaví klientů, ale určitě je vhodné pro ně zvolit výčtový jednopísmenný typ. Formáty musí odpovídat charakteru uložených dat (měna ve formátu měny, datum podle toho, zda je potřeba ukládat i časovou složku. . . ), měly by poskytnout dostatečný protor pro flexibilní změny, ale na druhou stranu by měly brát v úvahu prostorovou (dlouhé řetězce, zbytečná přesnost desetinných čísel, která nebude nikdy využita) i výpočetní náročnost (vyhledávání ve složených typech nebo při použití XML typu v databázi). • Interpretovatelnost – Interpretovatelnost je úzce spjata s předchozím bodem. Podtrhuje skutečnost, že data musí být uložena v takovém formátu, který sám o sobě umožňuje data interpretovat. Např. není dobrou praxí ukládat číselné hodnoty do řetězců apod. • Přenositelnost – Formát uložení dat by mělo být možné lehce sdílet s ostatními systémy či úložišti, proto by měl být univerzální, případně lehce převoditelný na standardní tvary.

3.4. DOSTUPNÉ NÁSTROJE PRO DATOVOU KVALITU

23

• Vnitřní konzistence formátu - Způsob uložení dat by neměl připouštět zapsání hodnot mimo definovanou doménu. Třeba záporný plat zaměstnance.

3.3.2

Příklady best practices Ataccama

Podívejme se nyní stručně na popis naznačující kostru práce s adresní entitou při zajišťování datové kvality na atributech v projektech společnosti Ataccama. Adresa je čištěna a zpracována v několika krocích. Dochází k parsování záznamu, odstraňují se překlepy, zaměňují se chybné bílé znaky za správné, nahrazují se případná podtržítka mezerami, mění se velikost písmen. Zároveň se jednotlivé části adresy snažíme odhadnout a rozpadnout na správné adresní položky, např. oddělit domovní číslo od ulice do samostatné kolonky, rozdělit číslo orientační a popisné do dvou údajů apod. Používá se řada regulárních výrazů. Pro příklad při zpracování poštovní přihrádky je jich definováno cca osm, mezi jinými: p\.\s?o\.\s?box(\.|\:|\s) (poštovní|postovni|pošt.|post.)\s?(schránka|schranka|schr.)\s?(\d+)\b Tyto dvě ukázky používají notaci regulárních výrazů z programu Master Data Cendefinice ter , jenž společnost Ataccama sama vyvíjí. S jednotlivými rozparsovanými částmi výrazu se pak dále pracuje. V dalším kroku se adresa standardizuje, tedy vyčištěné názvy ulic a měst se převádějí do standardizovaných tvarů (jednotné zkratky pro slova „ulice“, „město“, pro předložky „nad“ apod.). Nad těmito standardizovanými tvary se pak provádí vyhledávání v adresním registru UIR-ADR, aby se zjistilo, zda je zadaná adresa validní. Z číselníku UIR-ADR se automaticky doplní unikátní identifikátor adresního bodu v rámci České republiky a další případné chybějící údaje. Pokud není záznam nalezen, pokusí se algoritmus hodnoty uhádnout dle možných podobných adres v registru či ostatních poskytnutých adresních údajů (výpočet PSČ ze zadaného města. . . ). Pokud se ani takto nepodařilo atributy správně identifikovat, jsou označeny příznakem a uloženy do databáze. Celý proces také hodnotí kvalitu zdrojových dat scoringem jednotlivých nutných úprav záznamů. Pak lze zpětně do zdrojů propagovat informace o kvalitě dat, která jsou od nich získávána.

3.4

Dostupné nástroje pro datovou kvalitu

Zmínili jsme různé postupy používané pro zachování datové kvality. Nicméně jsme neuvedli, jak se dají tyto postupy efektivně aplikovat v reálných podmínkách. Je na první pohled zřejmé, že provádět podobné operace přímo v databázích pomocí standardně dostupných jazyků jako je SQL by bylo velice náročné. Potřebujeme nástroje, které budou umět ukládat mezivýsledky do paměti, které poskytnou předpřipravené funkce na běžně používané operace a které budou podporovat rychlou práci s řetězcovými daty. Představíme nyní tzv. nástroje datové kvality. Jde o komplexní programy různých výrobců s různou cenovou dostupností a samozřejmě i různou funkcionalitou. Použili jsme materiál [8], který každý rok vydává uznávaná analytická společnost Gartner, Inc. V tomto reportu jsou představeni nejvýznamnější hráči na poli podpory datové kvality.

24


Obrázek 3.4: Nejvýznamnější tvůrci nástrojů pro datovou kvalitu dle společnosti Gartner.

Jejich důležitost je určena umístěním do matice 2x2, kde nejlépe hodnocené produkty jsou v prvním kvadrantu (vpravo nahoře) a ty méně dobře hodnocené ve třetím (vlevo dole). Nejaktuálnější výsledky jsou zobrazeny na obrázku 3.4 vybraného z materiálu [8]. Nebudeme se podrobněji zaobírat výhodami a nevýhodami produktů jednotlivých uvedených firem, protože takové srovnání je nad rámec diplomové práce. Spíše pojednejme obecněji o možnostech těchto programů. Existuje několik přístupů. Společnosti jako IBM či SAP a další se snaží na trh proniknout integrací nástrojů pro datovou kvalitu s komplexními řešeními pro správu dat a Master Data Management. Firma Microsoft naopak volí strategii podpory datové kvality přímo ve svém databázovém produktu – v Microsoft SQL Serveru (dle zprávy se toto řešení teprve chystá). Některá řešení jsou naopak nezávislá a lze je integrovat s jakoukouliv jinou technologií či databází. Nástroje všeobecně umožňují práci s daty na úrovni profilingů, parsování, čištění, standardizace, obohacování, párování či monitorování. Některé jsou přímo určeny pro mezinárodní využití, některé se naopak snaží precizně spravovat data omezená lokálně. Další funkcionalitou může být např. správa metadat, definování workflow procesů a přímá podpora vystavování služeb s použitím SOA architektury. Nejpoužívanější nástroje celosvětově tedy můžeme najít v pravém horním kvadrantu. Při rozhodování, který z produktů použijeme pro realizaci diplomové práce, však vezmeme v úvahu celou matici.

3.4. DOSTUPNÉ NÁSTROJE PRO DATOVOU KVALITU

25

Za zmínku zcela jistě stojí nástroj českého původu, jehož autorem je již dříve zmíněná společnost Ataccama. Velkou výhodou je samozřejmě vestavěná podpora českého prostředí, tj. zpracování českých adres, validace rodných čísel a další.

26


Kapitola 4

Analýza řešení V předchozí kapitole 3 jsme nastínili různé možnosti nahlížení na datovou kvalitu. Než zahájíme analýzu řešení, explicitně uvedeme, proč je zajištění datové kvality tak náročné a proč není dostačující použít jednoduché intuitivní přístupy. Když jsme v kapitole 2 na jejím konci vymezili několik obecných případů, jež musí být zajištěny pro správnou podporu underwritingových procesů, jednoduchá řešení jsme tím vlastně úplně eliminovali. Nemohou nám postačovat primitivní metody porovnávání hodnot, protože reálný svět s sebou přináší řadu omezení – překlepy, nesoulady souvisejících hodnot, duplicity nebo naopak chybějící hodnoty. . . Musíme kontrolovat jednotlivé atributy, např. jestli je poskytnutá e-mailová adresa skutečná či vymyšlená. Navíc je nutné implementovat různá kritéria pro párování záznamů, abychom určili míru jejich shody a rozdělili obrovské množství záznamů do souvisejících skupin. To vše si vyžaduje komplexní řešení, jak naznačila kapitola 3. Již byly zmíněny některé postupy a nyní v analýze určíme, které z nich budou využitelné v diplomové práci. Pojednáme i o problémech integrace s okolním prostředím, určíme kritická místa v datových tocích a uvedeme všechny další potřebné podklady pro fázi návrhu řešení v kapitole 5. Začneme s podpůrnými poznatky analýzy, které nakonec shrneme do konkrétních případů užití.

4.1

Analýza procesů toků dat a míst aplikování datové kvality

Analýzu zahájíme globálním pohledem na podporu underwritingu v Master Data Management hubu. Pokusíme se procesně určit, jak se data do hubu dostávají a kde je možné s nimi pracovat z hlediska datové kvality. Budeme vycházet z kapitol 5 a 6 ve [4] (od strany 92 dále) a při popisu procesů pak z osmé kapitoly [13] – zde je nastíněno modelování toků pomocí tzv. FIP charts neboli funkcí zpracování informací. Protože pro vizualizaci těchto diagramů nejsou k dispozici podpůrné nástroje, použijeme diagram vycházející z BPMN, který okomentujeme v podkapitole 4.1.2, jako by se jednalo o FIP chart, tj. vymezíme pro jednotlivé aktivity jejich datový aspekt. Nejprve ale ve 4.1.1 zdůvodněme, proč je zajímavý právě proces přidávání dat do MDM řešení.

27

28

KAPITOLA 4. ANALÝZA ŘEŠENÍ

4.1.1

Kdy je nejúčinnější aplikovat datovou kvalitu

Abychom dokázali odpovědět na tuto otázku, provedeme analýzu procesu, při kterém se data do MDM hubu při jeho provozování dostávají. Proč ale stačí analyzovat jen tento proces? Další možností by bylo editovat data již v hubu uložená. Tento problém je diskutován v [13] na stránkách 22 až 26. Z diskuze vyplývá, že oprava a vylepšování datové kvality jsou mnohem účinnější při nahrávání dat (je možnost vylučovat nekvalitní záznamy, nevnáší se nové chyby do systému, je možné vyžádat u zdroje dat doplnění apod.). Pokud bychom aplikovali dodatečné opravy, je nutné vynaložit značné úsilí, např. kontaktovat klienty zpětně a zjišťovat pravdivost zadaných údajů, porovnávat naše údaje s dalšími databázemi, pokud vůbec nějaké máme k dispozici. Případně lze ještě aplikovat metodu kontroly a opravy dat v rámci databáze. Výše uvedená literatura ovšem upozorňuje na snadné šíření a propagace chyb při jejím použití. Naproti tomuto přístupu stojí ověření dat právě již na vstupu. Příkladem může být situace, kdy se na bankovní pobočce nachází klient. Pokud se systému nebudou zdát některé údaje správné, existuje jednoduchá možnost se klienta přímo zeptat, zda nedošlo k chybě, přehlédnutí či překlepu. Proto budeme procesně analyzovat a ve zbytku diplomové práce uvažovat pouze situaci, jak zajistit datovou kvalitu při přidávání nových záznamů.

4.1.2

Proces nahrávání dat do MDM hubu z hlediska datové kvality

Procesní diagram se nachází na obrázku 4.1. Jednotlivé swimlanes představují některé z vrstev MDM hubu, tak jak jsou zachyceny na obrázku 2.1 v představení architektury (viz podkapitola 2.2). Znázorněný proces je samozřejmě značně zjednodušen. Jsou vynechány chybové stavy a selhání, která nejsou významná pro datovou kvalitu. Není také nutné blíže specifikovat jednotlivé aktivity, i když by je jistě bylo možné rozpadnout do řady podprocesů. Aktivita „Zpracování dat“ byla rozdělena na tři základní podaktivity, protože je z hlediska datové kvality nejvýznamnější. V tabulce 4.1 pak specifikujeme jednotlivé kroky pro hlavní, default, cestu z hlediska toku dat (informací). Využíváme matic zápisu, které používá notace FIP, a explicitně uvádíme, že je vynechán krok převedení dat z dočasného úložiště do struktur MDM hubu, protože pro datovou kvalitu je nepodstatný, jde jen o přeuložení dat. Kroky nyní podrobněji popíšeme a vymezíme jejich vztah k datové kvalitě. Tím určíme, které části musí pokrývat navržené řešení v diplomové práci: 1. První krok představuje dohodu se zdrojem dat o přenosu do MDM hubu pro jejich uložení či zkontrolování. Z hlediska datové kvality není tento krok a jeho realizace zajímavá (různé typy notifikací apod.). Inicijuje však proces, který může vést ke změně datové kvality. 2. Druhý krok reprezentuje přenos dat ze zdroje do dočasného úložiště MDM hubu. Je důležité vědět, o jaký zdroj se jedná, protože vstupy reprezentují iniciální datovou kvalitu a ta se může velice odlišovat zdroj od zdroje. Podrobněji se tímto tématem zabývá podkapitola 4.1.3.

4.1. ANALÝZA PROCESŮ TOKŮ DAT A MÍST APLIKOVÁNÍ DATOVÉ KVALITY 29

Obrázek 4.1: Procesní diagram nahrávání dat do MDM hubu z hlediska datové kvality.

3. Data jsou ve třetím kroku kontrolována a validována (což může být i cílem, hub je možné použít k pouhé kontrole dat). Právě datová kvalita by měla být jedním z kritérií kontroly. 4. až po krok 6. Jde o aktivity, které jsou z hlediska underwritingu pro datovou kvalitu zcela klíčové, zabývali jsme se jimi podrobněji v celé předchozí kapitole 3. Tyto kroky budou tvořit jádro realizovaného řešení. 7. Sedmý krok, uložení dat, je zápisem do databáze. Z hlediska datové kvality jde pouze o vhodné zaznamenání výsledků procesu zajištění datové kvality, který probíhal v předchozích krocích. 8. Poslední krok je označení dokončení procesu. V reálném prostředí může znamenat notifikace jiných systémů nebo nové spuštění stejného procesu. Z hlediska datové kvality je pro nás další chování MDM hubu irelevantní.

30


Kroky FIP Procesní instrukce

1 Prompt Nahrávají se data ze zdroje

Vstup

2 Transmit Data jsou přenesena do MDM hubu Data ze zdroje

Výstup Zařízení Organizační jednotka

Zdroje dat

Kroky FIP

5 Filter

Procesní instrukce

Data jsou zpracována: obohacena a standardizována Vyčištěná data

Vstup

Výstup

Zařízení Organizační jednotka

Obohacená a standardizovaná data MDM úložiště Zpracování dat

Dočasné úložiště Vstupní rozhraní

3 Regulate Je ověřena validita dat Data ze zdroje Zvalidovaná data ze zdroje Dočasné úložiště Zpracování dat

4 Filter Data jsou zpracována: vyčištěna Zvalidovaná data ze zdroje Vyčištěná data MDM úložiště Zpracování dat

6 Associate (Filter) Data jsou zpracována: zunifikována

7 Store

8 Prompt

Data jsou uložena do databáze

Proces dokončen

Obohacená a standardizovaná data Unifikovaná data

Unifikovaná data

MDM úložiště Zpracování dat

Databáze Uložení dat

Tabulka 4.1: Tabulka s jednotlivými kroky FIP.

4.1.3

Reálné zdroje vstupních dat

Zdroje dat, která vstupují do MDM hubu, jsou vlastně zdroji primární datové kvality. Zjevně platí, že čím vyšší je datová kvalita na vstupu, tím lepší datové kvality jsme schopní dosáhnout i v cílovém řešení. V reálném světě bývá ale zaručení co nejlepšího stavu často velice obtížné, proto se musí vstupy v několika fázích kontrolovat, vždy v podrobnější a podrobnější granularitě. Primárními kontrolami by mohl být např. počet získaných souborů, podrobnějším ověřením pak struktura souborů (validace XML souboru vůči XSD atp.), dále potom zda sedí počet záznamů s případnou hlavičkou a nakonec ověření kvality jednotlivých záznamů. Při

4.2. PŘÍPADY UŽITÍ

31

neúspěšné kontrole lze dávku zamítnout. Tyto příklady byly vybrány ze zkušeností autora práce s reálnými projekty. Z hlediska diplomové práce se zaměříme až na poslední krok, tedy nejpodrobnější validace datové kvality. Důvodem je specifičnost všech ostatních kontrol v rámci konkrétních projektů a rozhraní. Ze zkušeností ještě vyjdeme při rozdělení zdrojů do dvou skupin. Jde o vstupy s velkým množstvím záznamů najednou a naproti tomu malé vstupy, typicky jeden záznam. Za první skupinou lze již očekávat nějakou databázi, kde jsou data organizována, dokonce u nich již mohla být sledována datová kvalita, tudíž data mohou být „lepší“. Případně lze ve velkém množství záznamů tolerovat některé výkyvy kvality. Naopak na pozadí zdrojů malých vstupů můžeme vystopovat typicky uživatelský vstup, třeba nějaký formulář GUI rozhraní. Zde již kvalita dat významně kolísá. Nevýhodou obou typů zdrojů (kterou nebudeme v diplomové práci brát na zřetel) je také různé mapování vstupních entit a jejich atributů na entity a atributy v MDM hubu. Řešení v diplomové práci musí být schopné pracovat s oběma typy zdrojů, vybereme si jako příklad vstup z GUI a nějaký hromadný vstup z externího zdroje. Oba druhy vstupů musí být validovány na datovou kvalitu (ne tedy např. na počet souborů, což nemá v modelovém případě význam). Z hlediska principu DRY by bylo žádoucí obsloužit oba případy jedinou funkcionalitou.

4.1.4

Typy entit, jejich stavy a způsob uložení

V této podkapitole shrneme tři poznatky, které je nutné doplnit k analýze toků dat a míst aplikování datové kvality. Nejprve se podívejme na to, u jakých entit musíme datovou kvalitu zajistit, abychom vytvořili dostatečnou podporu underwritingovým procesům. Vyjdeme-li z primárních požadavků uvedených v 2.5, je jasné, že datová kvalita se bude týkat záznamů o klientech, případně navázaných entit (adresa, kontakt, identifikační doklad). Kvalita ostatních dat, třeba údajů o úvěrech, je pro účely diplomové práce nepostižitelná – je příliš specifická pro konkrétní projekt. Je nutné zmínit i režimy záznamů ve vstupních datech. Informace o záznamech může přijít ve třech formách – vložení (insert), aktualizace (update) a smazání (delete). Řešení musí se všemi těmito režimy počítat a podporovat jejich použití. Nakonec ještě explicitně prohlásíme, že data budeme do MDM hubu ukládat, i když by řešení mohlo být read-only s doporučujícím charakterem. Ukládat je budeme pro účely diplomové práce proto, abychom mohli lépe ověřovat funkčnost řešení.

4.2

Případy užití

Na základě předchozí obecnější analýzy budou nyní vymezeny případy užití shrnující vlastnosti řešení. Případy užití popisujeme podle doporučení ve [2]. Zde uvádíme pouze popis, scénáře se nacházejí v příloze C. Celkový obrázek případů užití se nachází v diagramu 4.2. Ještě poznamenejme, že případy užití se vztahují přímo k aspektu datové kvality. Pro účely ověření funkcionality budou použity simulace externích systémů. Popsány budou blíže

32


Obrázek 4.2: Diagram případů užití.

Specifikace případu užití UC M01 – Přidat záznamy se zohledněním DQ Název případu užití: Přidat záznamy se zohledněním datové kvality. Stručný popis: Uloží do databáze záznamy a jejich navázané entity. Záznamy jsou načítány s příznaky insert, update a delete, které jsou k dispozici i na navázaných entitách. Aktéři: Systém. Spouštěč: Požadavek na uložení dat do databáze. Vstupní podmínky: Jsou k dispozici data pro uložení, která již prošla základními kontrolami (počet souborů apod.). Výstupní podmínky: Záznamy jsou uloženy do databáze v požadované datově kvalitě, nebo jsou záznamy odmítnuty. Jsou zalogovány některé informace o ukládaných datech. Scénář: Viz tabulka C.4 v příloze C. Tabulka 4.2: Popis případu užití „UC M01 – Přidat záznamy se zohledněním datové kvality“.

až ve fázi návrhu. Aktérem všech případů užití bude Systém. Simulujeme tak skutečnost, že řešení datové kvality je integrováno do komplexního systému MDM hubu. Konkrétní realizace případů užití, definování prahů apod. proběhnou v následující návrhové kapitole 5. Takto provedené postupy pracující s datovou kvalitou zajistí, že v databázi bude udržován stav dat, ze kterého je již možné provádět analýzy underwritingu klientů (mimo rámec diplomové práce). Na konci této podkapitoly ještě upřesníme, kterých dimenzí datové kvality se bude řešení dotýkat. Výběr byl dán zaměřením řešení a důležitostí jednotlivých dimenzí pro konkrétní

4.2. PŘÍPADY UŽITÍ

33

Specifikace případu užití UC M02 – Identifikovat záznamy se zohledněním DQ Název případu užití: Identifikovat záznamy se zohledněním datové kvality. Stručný popis: Zadané záznamy s navázanými entitami jsou zkontrolovány z hlediska datové kvality na atributech a případně ještě identifikovány (dohledány unifikační skupiny, kam by byl záznam připárován v případě uložení). Aktéři: Systém. Spouštěč: Požadavek na identifikaci záznamů. Vstupní podmínky: Je zadán požadavek na identifikaci záznamů, které prošly základními kontrolami. V požadavku je uvedeno, zda nemá být záznam pouze zkontrolován z hlediska atributové datové kvality. Výstupní podmínky: Je identifikován záznam (vyhledány cílové unifikační skupiny) a zkontrolovány jeho atributy z hlediska datové kvality. Pokud je požadavek pouze na kontrolu, pak není provedena identifikace. Scénář: Viz tabulka C.5 v příloze C. Tabulka 4.3: Popis případu užití „UC M02 – Identifikovat záznamy se zohledněním datové kvality“.

Specifikace případu užití UC I01 – Vyčistit a standardizovat záznamy Název případu užití: Vyčistit a standardizovat záznamy. Stručný popis: Vyčistí, obohatí a standardizuje předané záznamy a označí jejich datovou kvalitu na základě kvality jednotlivých atributů. Aktéři: Systém. Spouštěč: Nadřazené UC M01 (viz 4.2) a M02 (viz 4.3). Vstupní podmínky: Žádné. Výstupní podmínky: Předané záznamy byly vyčištěny, obohaceny a standardizovány, bylo u nich určeno score. Scénář: Viz tabulka C.2 v příloze C. Tabulka 4.4: Popis případu užití „UC I01 – Vyčistit a standardizovat záznamy“.

požadavky diplomové práce. Vyjdeme ze seznamu v 3.3.1. Z uživatelského pohledu půjde o identifikaci a homogenitu, rozsah, relevanci, z hlediska hodnot potom o úplnost, konzistenci a přesnost, z hlediska reprezentace dat o vhodnost formátů a interpretovatelnost dat. Ostatní aspekty nebudou hrát podstatnou roli, např. neposkytujeme reporty, takže není nutné rozebírat různou granularitu dat, stejně tak očekáváme přenositelnost základních databázových formátů apod.

34


Specifikace případu užití UC I02 – Unifikovat záznamy Název případu užití: Unifikovat záznamy. Stručný popis: Provede unifikaci předaného záznamu ke stávajícím záznamům v databázi. Bude kvůli jednoduchosti použito binární porovnávání na atributech i celých záznamech. Pro navázané entity platí, že neprochází unifikací, pouze do ní vstupují, aby pomohly správnému párování záznamu. Aktéři: Systém. Spouštěč: Nadřazené UC M01 (viz 4.2) a M02 (viz 4.3). Vstupní podmínky: Předávaný(é) záznam(y) prošel(y) úspěšně čištěním a standardizací. Výstupní podmínky: Byla vytvořena nová struktura skupin s předaným(i) záznamem(y). V případě režimu identifikace byly navráceny příslušné identifikátory skupin a ostatní záznamy z těchto skupin. Scénář: Viz tabulka C.3 v příloze C. Tabulka 4.5: Popis případu užití „UC I02 – Unifikovat záznamy“. Specifikace případu užití UC I03 – Vypočítat definované abnormality Název případu užití: Vypočítat definované abnormality. Stručný popis: Nad skupinou, do níž spadá přidávaný záznam, provede výpočet definovaných abnormalit. Aktéři: Systém. Spouštěč: Nadřazené UC M01 (viz 4.2) a M02 (viz 4.3). Vstupní podmínky: Předávaný záznam prošel úspěšně čištěním a standardizací a prošel procesem unifikace. Výstupní podmínky: Byly vypočteny charakteristiky abnormalit v záznamech spárovaných s přidávaným či identifikovaným záznamem. Scénář: Viz tabulka C.1 v příloze C. Tabulka 4.6: Popis případu užití „UC I03 – Vypočítat definované abnormality“.

4.3

Negativní vymezení funkčností

Kromě výše popsaných případů užití je součástí analýzy i negativní vymezení požadavků. Určíme, která další funkcionalita, mimo realizace případů užití a nutného podpůrného software, nebude součástí diplomové práce1 . Nejdůležitějším negativním vymezením je odmítnutí realizace zabezpečení řešení, přestože je v bankovním sektoru velice důležité. V práci postačí používat takové technologie, které případné zabezpečení umožňují – např. při použití webových služeb je možné provozovat je 1

Negativních vymezení je definována celá řada. Které části MDM hubu zachováme, bude popsáno v podkapitole návrhu 5.1. Řešení se snažíme maximálně zjednodušit, abychom se mohli zaměřit pouze na definovaný problém – proto je v zadání napsáno „při provozování MDM hubu“. Vybudování hubu může být totiž záležitostí mnohaměsíční práce velkého týmu lidí.

4.4. ANALÝZA ČÍSELNÍKŮ (ETALONŮ) A ZDROJŮ ZNALOSTNÍCH INFORMACÍ 35

i kryptovaně přes nějaký standardní zabezpečený protokol a vyžadovat autentifikaci i autorizaci uživatelů. Již několikrát bylo zmíněno, že nebude řešen samotný underwriting, pouze k němu budou připravována data. Také není úkolem analýzy a návrhu rozebírat architekturu Master Data Management hubu a implementovat jeho kompletní realizaci (vč. takových věcí jako vysoká dostupnost, zátěžová odolnost, zálohování, optimalizace výkonnosti, poskytování dat, auditní logování. . . ). Pro zjednodušení se spokojíme s modelovým vytvořením podstatných částí, např. zjednodušíme business významné atributy do jednoho, celkově nás bude zajímat pouze malá část datového modelu apod. Také z důvodů jednoduchosti řešení nebudeme brát v úvahu manuální zásahy do čištění, standardizace i unifikace. Vynecháme i poslední fázi výrobní linky, kdy vznikají master záznamy. Nebude implementováno ani B2B, protože každé prostředí je zcela specifické a jinak definované.

4.4

Analýza číselníků (etalonů) a zdrojů znalostních informací

V této podkapitole budou zmíněny informace na pomezí analýzy a rešerše. Týkají se zdrojů číselníků (etalonů) a obecněji zdrojů znalostních informací. V tabulce 4.7 jsou uvedeny zdroje různých typů číselníků i s jejich případnými odkazy na internet. V některých případech budou použity číselníky vytvořené společností Ataccama – nemohou ale pochopitelně být součástí odevzdání práce. Některé výčty budou vytvořeny přímo pro účely práce (rodinné stavy, pohlaví, typy kontaktů atd.).

4.5

Metrika datové kvality

V poslední sekci krátce pojednáme o metrice datové kvality, ze které potom vyjde porovnávání výsledků testů. Vytvoření takové metriky je v daném případě velice jednoduché. Abychom určili datovou kvalitu pro potřeby underwritingu, musíme ověřit, že se dané záznamy správně spárovaly a že jednotlivé atributy zapadají do všech určených dimenzí (viz podkapitola 4.2). Jak budeme o těchto aspektech rozhodovat je již otázkou testovacího procesu, jemuž je věnována celá kapitola 7. Metrika, nějaké číslo p, bude definována vzorcem 4.1: p=

počet chybných záznamů počet všech záznamů

(4.1)

Vzorec se opírá o počet chybných záznamů. Pro naši metriku bude chybný záznam definován opět v kapitole o testování 7, v níž bude také experimentálně zjištěn vhodný práh p, který zaručí dostatečnou datovou kvalitu. Metrika je zvolena převážně pro svou jednoduchost a prosté, lehce interpretovatelné vysvětlení. Je převzata z první kapitoly knihy [13] ze strany 6. Je nutné ještě explicitně upozornit na rozdíl mezi chybným záznamem (tj. naše řešení s ním pracuje nesprávně) a definovaným pojmem nález datové kvality, který v pojetí této

36


Číselník/znalost Územně identifikační registr adres (UIR-ADR) Registr ekonomických subjektů (RES)

Jména a příjmení Číselník zemí

Domény prvního řádu Telefonní předvolby Akademické tituly Adresní atributy

Popis a zdroj Již dříve zmíněný seznam všech adresních bodů v ČR, který poskytuje Ministerstvo práce a sociálních věcí, viz http:// forms.mpsv.cz/uir/. Seznam všech podnikatelských subjektů registrovaných v ČR, který poskytuje Český statistický úřad, viz http://www.czso.cz/csu/redakce.nsf/i/registr_ ekonomickych_subjektu. Lze ho využít i pro získání číselníků právních forem a dalších. Statistiky Ministerstva vnitra, viz http://www.mvcr.cz/ clanek/cetnost-jmen-a-prijmeni-722752.aspx/. Poskytuje Český statistický úřad, viz http://www.czso. cz/csu/klasifik.nsf/i/ciselnik_zemi_%28czem%29, jde o kódy ISO 3166-1 a 3166-2. Seznam generických i národních domén, viz http:// aaadomeny.cz/seznam-domen-prvniho-radu/. Seznamy mezinárodních i českých předvoleb, zelené linky apod., viz http://www.predvolby.info/. Seznam i s pravidly jejich řazení, viz http://www.pravidla. cz/tituly/. Databáze adres, ulic, měst a dalších adresních údajů zdarma na stránkách Ministerstva vnitra ČR, viz http://aplikace. mvcr.cz/adresa/index.html, lze ji využít jako alternativu pro UIR-ADR.

Tabulka 4.7: Tabulka znalostních zdrojů a zdrojů číselníků.

práce značí skutečnost v datech, na níž musí umět řešení upozornit, aby jí underwriter blíže prověřil.

Kapitola 5

Návrh a architektura řešení Na základě předchozích kapitol nyní navrhneme design a architekturu řešení. Architekturu Master Data Management hubu převezmeme obecnou z [4] a nebudeme ji blíže rozebírat. Věnovat se budeme pro zjednodušení pouze částem, které přímo souvisejí s řešením v diplomové práci či které jsou najakým způsobem relevantní. Dalším vodítkem pro vypuštění některých částí může být podkapitola 4.3 o negativním vymezení funkčností. Speciální důraz bude kladen i na testování, pro nějž je vyhrazena samostatná kapitola 7. Nejprve tedy představíme zjednodušený MDM hub a jeho datový model, navrhneme řešení reflektující primární funkční požadavky ze sekce 2.5 a případy užití z analýzy 4.2. Přiložíme i diagram nasazení, vybereme vhodné nástroje a technologie a nakonec ještě zmíníme další podpůrné služby, např. logování. Budeme se věnovat i návrhu simulace externích systémů.

5.1

Zjednodušený MDM hub

Potřebný rozsah MDM hubu pro účely diplomové práce byl již vlastně určen předchozími kapitolami. Sepíšeme nyní shrnující seznam, začneme od nejnižších vrstev: • Databáze – Základní komponentou MDM hubu je samozřejmě datové úložiště – databáze. • Datový model – Podrobněji bude rozebrán v podkapitole 5.2. Datový model bude zjednodušen na nejmenší možnou míru. • Podpůrné databázové objekty – Budeme ukládat i další technické informace mimo datový model. Definujeme ale pouze ty tabulky, které reálně budeme využívat. Dříve již byla např. zmíněna potřeba implementace logování, a proto budeme muset vytvořit tabulky na jeho ukládání. • Aplikační server – Pro standardizační, čístící, unifikační a další procesy nám již nestačí pouze databáze. Budeme potřebovat vhodný aplikační server, který umožní provádět dané operace v paměti a teprve jejich výsledek perzistovat do úložiště. Aplikační server bude také představovat hlavní controller pro všechny operace v MDM hubu.

37

38

KAPITOLA 5. NÁVRH A ARCHITEKTURA ŘEŠENÍ

• Podpůrné služby – Další služby potřebné pro zajištění funkcionality, např. již zmíněné logování. Podrobnější popis služeb se nachází v podkapitole 5.6. • Připojení on-line rozhraní – Aplikační server musí poskytovat možnost on-line připojení pro externí systémy, hlavně pro GUI. Zachováme tak architekturu vrstev klient-server systémů. • Zjednodušené načítání dat „ jakoby přes B2B“ – Aplikační server musí poskytovat možnost načítat dávkové soubory získané přes B2B (mimo rozsah diplomové práce). Není nutné provádět základní datové validace, postačí ověřovat kvalitu vstupních dat. Proto můžeme předpokládat, že v reálném hubu by byly nevalidní dávky dat odmítnuty v přijímacích kontrolách. Na straně MDM hubu proto vybudujeme pouze jednoduchou logiku pro načtení příchozích dat. Pro jednoduchost zvolíme načítání dat ze souborů CSV (vysvětlení viz 5.7). Jako simulace externích systémů nám postačí následující: • Simulace GUI rozhraní – K systému se může připojovat i GUI aplikace, která by umožňovala přidávání záznamů či jejich ověřování na pobočkách banky a připojovala by se na on-line rozhraní MDM hubu. Abychom se vyhnuli vytváření zobrazovací logiky a nutnému testování vizuálního prostředí, budeme ho simulovat pomocí klienta komunikujícího přes SOAP skrze webové služby. V rámci práce nebude k dispozici poskytování dat do tohoto „GUI rozhraní“, viz negativní vymezení 4.3. • Zjednodušené poskytování dat „ jakoby B2B“ – Mechanismus pro nahrání dávek vstupních dat na určené místo z „externího systému“, pro nás tedy z úložiště testovacích dat. Předpokládá se, že tyto extrakty jsou validní. Návrhem těchto simulovaných systémů se zabývá podkapitola 5.7. Poznamenejme ještě, že nebudeme potřebovat žádné konzumenty dat.

5.2 5.2.1

Datový model Model, třídy a atributy

Datový model přikládáme ve formě UML diagramu tříd na úrovni domén (viz obr. 5.1), model je denormalizován, aby již odrážel pravděpodobnou strukturu v úložišti, kde kvůli výkonnosti nebudeme zavádět žádné konstrukty typu ISA hierarchií. Používáme v něm jako standardní jazyk angličtinu a v obrázku pro přehlednost vypouštíme datové typy atributů. V projektu pro Enterprise Architect jsou uvedeny, soubor je k nalezení na přiloženém CD. Datové typy používáme doménové, např. string, v databázi pak dostanou konkrétní podobu, např. varchar2(100). V projektu jsou zároveň okomentovány ty atributy, jejichž význam by mohl být nejasný (nekomentujeme např. atribut id ).

5.2. DATOVÝ MODEL

39

Obrázek 5.1: Datový model řešení.

40


Třídy K modelu postupně podáme bližší vysvětlení. Nejprve se podíváme na jednotlivé třídy. Ústřední entitou je Subject. Je jedinou entitou, na kterou bude aplikována unifikace. Tato třída může být přes vazbu vztahů ze zdrojů, Subject2Subject, provázána s jinou a vytváří tak vztahy mezi klienty (jednatel společnosti, manželé, otec-dítě apod.). Tuto třídu budeme plnit pouze ze zdrojových systémů, ostatní vazby budou pokryty v unifikačních skupinách a nedojde k jejich explicitnímu vyjádření touto entitou. Důvod je prostý – nemůžeme v systému zavádět entity, u kterých si nejsme jisti, zda opravdu existují (opravdu jsou dva subjekty manželi?). Proces unifikace se pro účely underwritingu pokusí skrze tyto třídy subjekty propojovat. Na Subject jsou agregovaně připojeny navázané entity s adresami, kontakty a identifikačními dokumenty. Vazby mezi třídami jsou prováděny přes klíče key. Jejich výhodou je stabilita, pokud se vytváří vždy stejným způsobem, třeba konkatenací klíčů entit ze zdrojových systémů. Budou se proto používat vedle číselných id. Pro označení entit, které jsou čištěny, standardizovány a případně unifikovány, používáme vlastní stereotypy «cleansed», «standardized» a «unified» (v tomto pořadí). Speciálními třídami (barevně odlišenými a označenými stereotypem «etalon») jsou tzv. číselníky neboli etalony. Jde o definice výčtových typů pro některé z atributů. Standardizovaná hodnota atributu je spolu s origin_code přímo klíčem do číselníku. Samotná hodnota etalonu je uložena ve sloupci value, který je právě určující pro obsah atributů se sufixem code v názvu. V diagramu jsou pro přehlednost vynechány vazby na číselníky. Jiné třídy v modelu pro naše řešení nepotřebujeme. Reálný MDM hub má samozřejmě model typicky až s desítkami entit. Pro diplomovou práci jsou však irelevantní. Atributy Nejprve ukážeme tabulku 5.1 s typy atributů, které budeme potřebovat. Tabulka může být v průběhu implementace doplňována o další položky, pokud se ukáží být potřebné. Jednotlivým typům atributů přiřadíme prefixy, abychom je odlišili v datovém modelu. Rozdělení atributů a jejich prefixy vycházejí ze zkušeností autora práce z reálných projektů. Atributy jsou zařazeny pod skupinky stereotypů, které určují jejich prefix z tabulky 5.1. Model nezahrnuje dočasné atributy (TECH, MAT ) a jsou přítomny pouze předem známé atributy s prefixem UNI. Ostatní UNI sloupce budou vymezeny ve fázi implementace, kdy teprve určíme, které z nich potřebujeme uchovávat. Bude to záviset i na použitém nástroji. O výběru nástrojů pojednává sekce 5.5. U detekčních DTC atributů a jejich EXP vysvětlení znamenají čísla v názvech očíslování v příslušném kroku scénáře UC I03, jenž je uveden v tabulce C.1. Poznamenejme ještě, že některé atributy mají již ze své povahy daný datový typ. Jde o DTC a SCO – protože se jedná o prahy, budou to celočíselné hodnoty. Obdobně bude vysvětlující EXP vždy řetězec. Atributy score nabývají hodnot od 0 do 1000 a odrážejí penalizaci atributu z hlediska datové kvality. Do 10 jde o kvalitní atribut, do 100 o hodnotu s výhradami, do 1000 pak o nevěrohodný údaj (případně vůbec neposkytnutý). Odstupňování v těchto intervalech musí

5.2. DATOVÝ MODEL

Typ Provozní

Popis Veškeré atributy nutné k základním úkonům nad daty

Zdrojové

Zdrojové hodnoty významných atributů pro řešení – tedy těch, které se čistí, standardizují či vstupují do unifikace Vyčištěné Pro zdrojové atributy, které procházejí čištěním, se zde uloží vyčištěná hodnota Standardizované Standardizované hodnoty vstupních atributů Párovací Dočasné atributy používané v procesu unifikace Unifikační Technické

Detekční Scoring

Vysvětlení

Business

Atributy s výsledky a průběhem unifikace Dočasné atributy pro technické operace

Atributy s výsledkem detekce abnormalit Scoring atributů po čištění a standardizaci, určuje kvalitu jednotlivých atributů Atributy s vysvětlením udělení score či hodnot detekčních atributů (třeba pro navrácení do GUI) Atributy s business významem. Pro naše řešení jsou nepodstatné a budou představovány jedním generickým atributem

41

Příklad atributu Identifikátory, příznak smazání, datum uložení Jméno, příjmení, ulice

Jméno, ulice

Prefix

SRC

příjmení,

CLN

Jméno, příjmení, ulice Všechna jména klienta seřazená dle abecedy Klíč výsledné skupiny Detektory datové kvality, pomocné sloupce Abnormalita kontaktů Score rodného čísla

STD MAT

UNI TECH

DTC SCO

Důvod score rodného čísla

EXP

V reálu datum poslední návštěvy na pobočce

BUS

Tabulka 5.1: Typologie atributů datového modelu s příklady.

odrážet důležitost atributu. Atributy DTC jsou pak určeny jako absolutní čísla počtů entit – např. počty změn na adresách v dávce apod. EXP hodnoty vyjadřují nejen důvod udělení score, ale také svým prefixem DQLOW_, DQMID_, DQHIG_ zohledňují vztah datové kvality vstupu a výstupu. DQHIG_ říká, že vstupní hodnota byla kvalitní, případně taková, že se z ní dala kvalitní hodnota získat (score 0 – 9). DQMID_ pro score 10 – 99 upozorňuje na výhrady k atributu, např. byl dopočítán nějaký důležitý atribut z kombinace méně signifikantních sloupců. DQLOW_ pro score od 100 do 1000 označuje nedůvěryhodné či chybějící hodnoty atributů. Celkově lze říct, že entita

42


ohodnocená třetí skupinou score je z hlediska kvality nedůvěryhodná. Atributy z hlediska unifikace Pro unifikaci záznamů musíme najít atributy, které budou sloužit jako identifikační, diskriminační a typové. Toto rozdělení jsme představili v podkapitole 3.2.1. Přehled atributů se nachází v tabulce 5.2. Typ Identifikační

Diskriminační Typové

Popis Na subjektu na obou úrovních je to určitě rodné číslo a IČ, doplněné ještě kombinacemi data narození, rodného jména a jména, názvu společnosti a návazných entit. Použijí se STD (případně CLN ) hodnoty atributů. Nejsou specifikovány. Všechny atributy končící na type_code a na subjektu ještě status. Hlavním typovým atributem bude typ subjektu.

Tabulka 5.2: Vymezení identifikačních, diskriminačních a typových atributů datového modelu.

5.2.2

Stabilní referenční klíče

Ne vždy se můžeme spolehnout na zdrojové systémy jako na autoritu referenčních klíčů. Řešení proto musí tento fakt reflektovat jejich vlastním vytvářením. Nejedná se přitom o identifikátor id, ale o hodnotu atributu key. Klíč ze zdroje je na entitě Subject uložen a použit pro vytvoření pevného klíče subjektu konkatenací přes „##“ za identifikátor zdroje (tím zajistíme unikátnost v rámci celého Master Data Management hubu). U navázaných entit budeme zdrojové identifikátory ukládat také. Entity bychom sice mohli přiřazovat k subjektům na základě vlastních klíčů (byly by vytvořeny konkatenací z klíče subjektu a typu entity), ale v případě aktualizace či smazání entity bychom se museli spolehnout na přirozené klíče vždy v kombinaci s typem entity – u adresy na identifikátor adresního bodu z číselníku UIR-ADR, u dokumentu na jeho číslo, u kontaktu na standardizovanou hodnotu a u vazeb subjektů na jejich typ. Tím se sice rovnou zajistí deduplikace navázaných entit, ale bude obtížné správně interpretovat změny – nebudeme vědět, zda jde o aktualizaci stávající, či došlo k přidání úplně nové a stará se má zneplatnit. Proto budeme vynucovat z externích systémů i identifikátor navázaných entit, mohou např. poskytovat id entity v jejich databázi.

5.3 5.3.1

Návrh řešení Základní představení

Architektonicky nejčistší bude vytvořit nástroj pro zajištění datové kvality v MDM hubu pro podporu underwritingu jako samostatnou komponentu. V ideálním případě by komponenta

5.3. NÁVRH ŘEŠENÍ

43

ani nemusela zapisovat do databáze, pouze by jí protekly záznamy, které by se uvnitř nějak modifikovaly. V diplomové práci ovšem nemůžeme využít kompletní infrastrukturu MDM hubu (jeho existenci sice předpokládáme, ale minimálně kvůli testům potřebujeme zajistit alespoň základní funkcionalitu), do nějž by komponenta zapadla, a proto do ní zařadíme i komunikaci s databází. Komponentu nazveme DQTool a popíšeme její základní strukturu a vztahy pomocí UML diagramu komponent na obrázku 5.2.

Obrázek 5.2: Diagram komponent jádra řešení.

Vlastnosti komponenty podrobněji popíšeme v podkapitole 5.3.2, kde bude představen detailnější design realizace. Vlastnostmi bude architektura komponenty odpovídat případům užití z analýzy, aby umožnila splnit všechny primární funkční požadavky. Z výstupů nástroje DQTool v databázi i přímo na výstupním rozhraní bude možné vymezit různé nálezy datové kvality (tento pojem byl z pohledu diplomové práce vysvětlen v sekci 2.4.2), na základě kterých pak bude underwriter vyhledávat vazby na další klienty, jejichž finanční situaci bude dále prověřovat. Mezi tyto nálezy datové kvality budou patřit kandidátské skupiny s velkým počtem klientských podskupin (upozorňují na provázanost klienta s dalšími subjekty) a dále vyšší čísla v DTC sloupcích (značí situace jako množství různých adres evidovaných u subjektu či velké množství změn v dané dávce). Stejně tak by se měly prověřovat entity s vysokým score, protože u nich je z různých důvodů k dispozici málo údajů a pro úspěšný underwriting by měly být doplněny.

44


Z diagramu je patrné, že s okolními systémy komunikuje pouze komponenta DQTool, která vnitřně obsahuje ještě čistící a standardizační komponenty clean_subject, clean_sub2sub, clean_address, clean_contact, clean_document pro entity Subject, Subject2Subject, Address, Contact a Document, pro unifikaci klientů potom komponentu match_subject a pro výpočet datové kvality dávky záznamů clnstd_quality. Poslední zmíněnou komponentu nebudeme detailněji v následující podkapitole rozebírat, je v ní pouze proveden výpočet procenta nekvalitních záznamů (score nad níže definovaným prahem). V případě překročení označí všechny záznamy v dávce k odmítnutí. Stejně tak nebudeme blíže hovořit o databázi. K ukládání budou vytvořeny uložené procedury, tabulky budou vygenerovány z datového modelu.

5.3.2

Podrobnější rozebrání komponent

V této podsekci postupně rozebereme podrobnější vnitřní design komponent pomocí diagramů, které byly nakresleny bez použití standardizovaných modelovacích jazyků. Mohl tak být využit přirozený vizuální aparát. Šipky na diagramech značí tok dat, ikonky pak jednoduše graficky vystihují, co se s daty postupně děje (ikonka filtru pro podmínku, ozubené kolo pro komponentu apod.). Kroky jsou označeny čísly, protože některé z nich jsou podrobněji vysvětleny v textu. Odsazení kroků značí podmíněnou větev zpracování, která vždy začíná filtrem. Zbytek entit pokračuje v toku dále. Slovo „vyhledání“ v popiscích znamená, že se ověřuje nějaká hodnota proti číselníku (o číselnících podrobněji v 5.6). Detail návrhu komponenty DQTool Komponenta DQTool je jádrem celého řešení zajišťování datové kvality. Na diagramu 5.2 je její rozhraní rozděleno na režim ukládání (store) a identifikace (identify). Kvůli zachování principu neopakování se bude komponenta poskytovat fyzicky jedno jediné rozhraní, které bude entity zpracovávat v podstatě identicky, vždy jen s menšími odchylkami, jež budou rozlišeny příznakem regime s hodnotou STORE nebo IDENTIFY. Tím dojde ke sloučení obou případů užití M01 (popis viz tabulka 4.2) a M02 (viz tabulka 4.3). V rámci těchto dvou režimů budou ještě na všech záznamech rozlišeny jejich „módy“ atributem record_type. Hodnoty i s popisem se nacházejí v tabulce 5.3. U identify se předpokládá, že všechny entity budou mít nastavenu stejnou hodnotu. Na detailním diagramu 5.4 jsou navázané entity ukázány jako jedna, reálně se ale budou provádět stejné operace se všemi. Čistící komponenta bude pro každou navázanou entitu jiná, stejně tak pro subjekt (kroky (2) a (7)). V krocích (3) a (8) je všude použit totožný mechanismus pro vyhodnocení datové kvality záznamů a zároveň i celé dávky. K vyhodnocení kvality použijeme následující algoritmus. Vezme se score celé entity (aritmetický průměr score atributů) a porovná se s definovaným prahem score, který je stanoven na 500. Je-li práh překročen na více než 20% řádků v dávce, je dávka entit označena v atributu tech_quality_decision jako false a je vyřazena ze zpracování. Vyhodnocení kvality bude umístěno do samostatné komponenty clnstd_quality (na detailním diagramu není vyznačena).


45

Obrázek 5.3: Detailní design komponenty DQTool. Režim

Typ I

IDENTIFY V I STORE U D

Popis Identifikace záznamů, subjekt s navázanými entitami vstupují do unifikace a jsou nalezeny skupiny, ke kterým by se záznam přisloučil, kdyby měl nastaven režim STORE. Entita je vyčištěna, standardizována a zhodnocena scoringem z hlediska datové kvality, nevstupuje dále do unifikace. Nově přidávaný záznam (insert). Pokud již v databázi je, dojde ke změně příznaku, jak je popsáno v kapitole o logování 5.6. Aktualizaci stávajícího záznamu (update) podle klíče. Pokud se v databázi nenachází, změní se příznak, viz 5.6. Smazání stávajícího záznamu (delete) podle klíče. Pokud se v databázi nenachází, změní se příznak, viz 5.6.

Tabulka 5.3: „Módy“ záznamů v jednotlivých režimech.

46


Je-li nastaven režim identifikace typu V nebo je-li dávka označena za nekvalitní, jsou všechny její entity odeslány na výstup a nevstupují do dalšího procesu. Dávky se odmítají po entitách (např. všechny adresy, zatímco ostatní entity pokračují dále). Tento mechanismus vede k tomu, že můžeme v databázi dostávat záznamy porušující referenční integritu mezi subjekty a jejich entitami. Integritu proto nemůžeme vynucovat žádnými constraints, tedy databázovými omezeními. Na toto porušení bude upozorněno zalogováním a je možné mimo rámec diplomové práce pravidelně spouštět údržbové skripty a mazat dlouho netknuté sirotky mezi navázanými entitami. Výhodou tohoto přístupu je pak to, že do databáze dostáváme i údaje, o které bychom striktní kontrolou mohli přijít. Příkladem budiž vztahová entita Subject2Subject typu „manželé“, kde ale neznáme druhý subjekt. Přesto však může být pro underwriting cenná informace, že klient má manžela/manželku, i když nedokážeme dohledat v systému komplementární záznam. Po kontrolách dochází k doplnění entit z databáze pro subjekty a naopak, načež kompletní balík vstupuje do komponenty unifikace (krok (12)). Nakonec jsou záznamy poskytnuty na výstup a v případě ukládacího režimu i přes uložené procedury zapsány do databáze (krok (16)) a jsou zalogovány příslušné informace (viz podkapitola 5.6 se zmínkou o logování). U zdrojových souborů předpokládáme, že v nich nejsou duplicity. Detail návrhu komponenty clean_sub2sub Čistící a standardizační komponenta pro entitu Subejct2Subject je nejjednodušší. Podobně jako ve všech ostatních čistících komponentách jsou nejprve k entitě přidány dočasné technické sloupečky, pak dochází k předčištění atributů (kde je potřeba, je odstraněna diakritika, mezery, je proveden převod na velká písmena apod.). Dalším krokem je pak vyhledání základních hodnot (typicky typ entity) v číselnících. V případě této komponenty jsou přímo určeny i všechny standardizované hodnoty, jsou-li k dispozici. Nakonec je vypočítáno score jednotlivých atributů a příslušné vysvětlovací (EXP ) sloupce. Score je určeno tak, aby zohlednilo datovou kvalitu atributu vzhledem k nejlepší dostupné hodnotě získané modifikacemi původní zdrojové. Protože čištění Subject2Subject je jednoduché, uveďme příklad, na kterém ukážeme vztahy src, cln a std hodnot jednoho atributu. Atributy entity nejprve v kroku (4) vyčistíme do cln hodnot – ověří se, že hodnota typu obsahuje pouze číslice nebo písmena, u datumů1 platnosti se do cln zapíší pouze takové zdrojové hodnoty, které odpovídají běžně zadávaným maskám yyyy-MM-dd, dd/MM/yyyy, dd.MM.yyyy a dalším. Stejně tak definujeme nejnižší možné datum 1. 1. 1900. Pokud je součástí datumu i čas, pak musí být ve formátu HH:mm:ss (formáty odpovídají jazyku Java), ale při zpracování se zahodí. Krok (3) představuje vyhledání typu vztahu v číselníku vztahů, který je definován pro různé zdroje. Není-li v číselníku nalezen, hodnota std se nevyplní. Není možné provádět test, zda mohou dané subjekty daný typ vztahu mezi sebou mít, protože ještě nemusí být v systému známy. Takto neodhalíme např. pokus o nastavení vztahu manželství pro dvě 1

Tento skloňovaný tvar slova „datum“ podle nesprávného mužského vzoru „hrad“ je použit s odkazem na Ústav pro jazyk český http://prirucka.ujc.cas.cz/?id=263.


47

Obrázek 5.4: Detailní design komponent clean_sub2sub, clean_address a clean_document.

48


firmy. Pro účely underwritingu se nicméně nejedná o problém, nepřicházíme v tomto případě o žádnou důležitou informaci. Ani std pro datum se nevyplní, pokud neodpovídá business pravidlům – v případě entity Subject2Subject nesmí být datum začátku platnosti novější než datum ukončení platnosti vztahu. Jaký je tedy vztah src, cln a std hodnot? První, zdrojové, jsou beze změny přebrány ze zdrojového systému. Jejich věrohodnost je malá. Ve vyčištěných atributech se nacházejí modifikované zdrojové hodnoty, pokud odpovídají základním pravidlům. Např. datum je opravdu ve formátu datumu a je po definovaném nejnižším možném datu. Odpovídá-li hodnota i dalším definovaným pravidlům, případně ji lze ověřit v číselnících, pak je propagována do standardizovaných atributů – u datumu to může být právě třeba test, že není novější než současnost. Chceme-li tedy zpětně použít nejlepší dostupnou hodnotu atributu, použijeme std verzi, pokud není, pak cln verzi. A pokud není k dispozici ani ta, musíme se spokojit s nedůvěryhodnými zdrojovými hodnotami – vždy bychom se měli řídit příslušným score. Diagram se nachází na obrázku 5.4. Detail návrhu komponenty clean_address Diagram se nachází také na obrázku 5.4. Princip je obdobný jako u předchozí entity. K čištění a ověřování je ovšem nutné použít mnohem sofistikovanější metody, jako jsou regulární výrazy, složitější číselníky měst, poštovních směrovacích čísel a také český adresní registr UIR-ADR, který již byl v práci několikrát zmíněn. Důležitým momentem je hlavně zpracování ulice v krocích (5) a (6). Je totiž možné, že ze zdroje v ulici přišel např. název obce bez uliční sítě, případně p. o. box, nebo různě zakódovaná orientační či popisná čísla. Komponenta musí zajistit jejich maximální vytěžení, měla by si poradit i se zápisy obsahujícími zkratky jako č. p., č. ev., č. domu apod. V registru adres se pak vyhledává pomocí různých vzorů, tak abychom mohli adresní body jednoznačně identifikovat. Pro nenalezené adresy, které mají kód státu český, se musí komponenta pokusit dohledat chybějící informace (třeba obec ze směrovacího čísla). Pro neověřené adresy (i správné, ale zahraniční) nebudou vyplněny standardizované hodnoty, pro ověřené hodnoty bude přepsán standardizovaný kód státu na ČR. Neověřené české adresy budou mít vyplněny standardizované sloupce, ovšem s penalizací vysokým score snižujícím záruku pravdivosti. Detail návrhu komponenty clean_document Diagram se opět nachází na obrázku 5.4. Dokumenty jsou kontrolovány pouze zevrubně dle zadaného typu v kroku (5), u občanských průkazů se použije ověření i přes kontrolní číslici (dle specifikace ICAO 9303). Podrobnější kontroly nad doklady bohužel nejsou definovány, už vůbec ne nad zahraničními.


49

Obrázek 5.5: Detailní design komponenty clean_contact.

Detail návrhu komponenty clean_contact Návrhový diagram se nachází na obrázku 5.5. U kontaktů se zpracovává pouze e-mailová adresa a telefonní číslo. U e-mailu se kontrolují domény a celkový tvar adresy (7) a v kroku (8) se pokusíme o doplnění domén nejvyššího řádu pro známé servery, např. gmail. U telefonního čísla se odstraní linka a připojí případně znak + k mezinárodní předvolbě. Proti číselníkům se validují předvolby mezinárodní a dále české. Staré české národní předvolby před přečíslováním jsou již vyhodnocovány jako nevalidní. Stejně tak jsou za nevalidní

50


čísla považovány vyhrazené kontakty jako např. 158 (policie), 14116 (předpověď počasí) atd. Jiné než české číslo nemůže skončit v std hodnotě. Typ kontaktu se pak koriguje podle skutečné získané std hodnoty. Detail návrhu komponenty clean_subject Čištění a standardizaci entity Subject popíšeme dle návrhového diagramu na obrázku 5.6. U subjektu platí, že se čistí atributy v závislosti na typu osoby. Subjekt má totiž dvě sady atributů – pro fyzické osoby a pro právnické osoby, není zavedena dědičnost. Budou tudíž vyplněné cln a std hodnoty pouze u atributů patřících danému typu osoby. Protože na začátku není jasné, který typ osoby subjekt představuje, komponenta se musí pokusit entitu zpracovat oběma způsoby, dokonce se musí pokusit získat rodné číslo zapsané v položce pro IČ a naopak, obdobně pro název firmy a jméno člověka. Nejprve proběhne pokus o zpracování právnických osob (3), tedy vyhledání v Registru ekonomických subjektů, nejprve dle IČ a omezením na shodu názvu, pak dle názvu společnosti a pak podle IČ znovu, ale s benevolentními omezeními na shodu názvu společnosti. Pokud se podaří subjekt jednoznačně identifikovat a není podezření, že by mohlo jít o fyzickou osobu, dále se nezpracovává a je poslán na výstup přímo z kroku (4). Ostatní záznamy projdou validacemi atributů fyzických osob včetně kontroly kombinace rodného čísla, data narození a pohlaví (8), včetně získání a seřazení titulů (7) a včetně pokusů o správné určení pohlaví z rodného čísla či jmen (9). Jména jsou ověřována různými pokusy proti číselníkům. Ověřené záznamy jsou poslány na výstup, u ostatních se provádí uhádnutí typu osoby nejprve dle toho, jak se podařilo vyčistit a standardizovat jednotlivé atributy (11), případně na konci podle heuristiky z klíčových slov názvu společnosti (13), kdy se ve jménech hledají slova jako „družstvo“, „trading“ a další. Ve scoringu je penalizováno vyplnění zdrojových atributů jiného subjektu, než byl nakonec určen. Detail návrhu komponenty match_subject Komponenta s unifikací subjektů je rozebrána na diagramu 5.7. Vstupují do ní nejen subjekty, ale i navázané entity, ze kterých jsou vybrány „objekty“, tedy řetězce s konkatenovanými (přes řetězec „##“) prvky těchto entit. Z nich se pak další konkatenací v kroku (3) přes mezeru vytvoří množiny objektů. Množina je tedy dlouhý řetězec, který v kompaktní formě představuje např. všechny adresy daného subjektu. Poté jsou v (5) připraveny unifikační atributy s prefixem MAT (např. jména velkými písmeny a bez diakritiky spojená do jednoho řetězce a nakonec seřazená dle abecedy) a vytvořeny uni atributy, záznamy jsou pak nakumulovány a vstupují do unifikace. Subjekty jsou nejprve rozděleny do širokých kandidátských skupin pomocí režimu Union (režimy unifikace byly představeny v sekci 3.1), protože pro hierarchickou unifikaci nám chybí jeden primární rozhodovací atribut. Pravidla pro unifikaci zohledňují potřeby underwritingu a tvoří co nejširší skupiny, aby mohlo být odhaleno co nejvíce vztahů mezi subjekty. K párování jsou používány i smazané


Obrázek 5.6: Detailní design komponenty clean_subject.

51

52


entity s vědomím, že mohou vznikat velmi velké skupiny (jak se např. s léty budou rozrůstat rodiny, stěhovat se lidé. . . ), nicméně pro underwiting je tento přístup nutný. Lze akceptovat i situace, kdy dojde k připojení nesouvisejících subjektů (viz níže odstavec o manuálních změnách v párování). Použijí se tato pravidla: • shoda v rodném čísle nebo IČ, • shoda v rodném čísle (berou se v úvahu i cln), • shoda v IČ (berou se v úvahu i cln), • shoda ve jméně a datu narození, • shoda ve jméně (bez dalších jmen) a datu narození, • shoda v názvu společnosti a adrese, • shoda v příjmení a adrese, • shoda v příjmení a identifikačním dokumentu, • shoda ve jméně/názvu společnosti (kvůli podnikatelům) a adrese, • shoda ve jméně bez dalších jmen/názvu společnosti a adrese, • shoda ve jméně/názvu společnosti seřazeném dle abecedy a adrese, • shoda v příjmení (včetně deklinace) a rodném jméně a adrese (více generací na jedné adrese či manželé), • shoda v příjmení (včetně deklinace) a adrese, • párování přes explicitně poskytnutou entitu Subject2Subject. Vymezení klientských skupin v rámci kandidátských již naopak musí odrážet důraz na bezpečnost informací v bankovním prostředí. Proto bude prováděn konzervativně. Použijí se tato pravidla pro právnické osoby a podnikatele: • shoda IČ a adresy pro právnické osoby, • shoda IČ pro podnikatele nebo jejich provázání s právnickou osobou, • shoda názvu společnosti a adresy. Pro fyzické osoby pak tato pravidla: • shoda rodného čísla, jména a příjmení, • shoda rodného čísla a malá Levenshteinova vzdálenost jmen, • shoda rodného čísla, jména a jednoho adresy/kontaktu/dokumentu,


53

Obrázek 5.7: Detailní design komponenty match_subject.

• shoda rodného čísla, příjmení a začátku jména, • shoda rodného čísla, začátku jména a příjmení s rodným příjmením, • shoda rodného čísla a shoda některých jmen (křestních či dalších), • shoda data narození, jména, příjmení a jednoho z adresy/kontaktu/dokumentu, • shoda data narození, začátku jména, příjmení s rodným příjmením a jednoho z adresy/kontaktu/dokumentu. Nakonec ještě pojednejme o dvou záležitostech – jednak se při unifikování ke vstupním záznamům přidávají všechny, které se jejich zařazením změnily kvůli efektu řetězení (tj. na výstupu z unifikace může být více záznamů, než na vstupu), a dále je také nutné poznamenat, že i pouhá změna jedné navázané entity může vést k přeunifikování jinak nezměněného subjektu. Další záležitostí jsou manuální výjimky v párování. Jde o možnost ručně rozhodnout o připárování/odpárování dvojice subjektů k sobě/od sebe. Tato funkcionalita nebude v rámci diplomové práce implementována, nicméně bude diskutována v podkapitole 5.5.

54


Unifikovaným klientům se přiřadí id a klíče obou skupin a dopočítají se abnormality definované případem užití I03 (kroky (9) a (10)).

5.4

Nasazení

Nyní uvedeme podrobně rozebranou komponentu DQTool do kontextu okolních komponent a zařízení. Pokud bychom chtěli architekturu popsat přesně, museli bychom vyjádřit celou obrovskou šíři Master Data Management řešení. To ovšem není v našem případě nutné, protože diplomová práce řeší pouze jeho malou část. Dovolíme si tedy z diagramu nasazení, jenž použijeme pro nastínění širší architektury, vypustit řadu věcí, případně je sjednotit pod jednu komponentu. Diagram se nachází na obrázku 5.8.

Obrázek 5.8: Diagram nasazení.

Z obrázku je patrné, že komponenta DQTool je součástí nějakého rozsáhlejšího systému, který byl pro obecnost nazván MDM runtime a běží na aplikačním serveru. V podkapitole 5.5 bude diskutováno, jaký produkt využijeme pro jeho vybudování. Tento systém má v sobě řadu (typicky desítky) komponent shrnutých pod Other MDM components. Ty zajišťují časování, volání různých procesů, starají se o zabezpečení dat a jejich přenosů, vysokou dostupnost, o funkce datových pump a všechny další potřebné akce v Master Data Management řešení. Pro diplomovou práci je důležité, že nad vstupními daty vytváří vrstvu, která se

5.5. VÝBĚR NÁSTROJŮ A TECHNOLOGIÍ

55

stará o základní potřebné validace a umí data přijmout z externích zdrojů a zase jim je eventuálně poskytnout zpátky. Komponenta DQTool proto nemusí řešit napojování na zdroje, pouze přebere již načtená data, a to v režimech store či identify (viz vystavená rozhraní na diagramu komponent 5.2). Již výše bylo diskutováno, že komponenta bude i sama zapisovat přes databázové balíčky do databáze, což je v diagramu vyjádřeno spojením s MDM database engine. Rozhraní směrem ven je odstíněno ostatní funkčností MDM hubu – v diagramu 5.8 je naznačeno několik možností, rozhodně nejde o úplný výčet. Není záměrně uveden ani způsob komunikace, jenž může nabývat řady podob. Pro účely testů a ověření možností integrace komponenty datové kvality bude vytvořena komunikace se dvěma modelovými typy externích zdrojů. A to přes on-line rozhraní a pro přenášení dávek souborů, podobně jako se děje přes B2B. Další možností je využít výměnu dat přes materializované pohledy databází apod. Transportovat se také dají data různých formátů. Podrobněji o externích systémech pojednává podkapitola 5.7. Tím je popsáno okolí, ve kterém bude komponenta integrována. Podrobněji se jím zabývat je nad rámec této diplomové práce.

5.5

Výběr nástrojů a technologií

Nástroje podporující výstavbu MDM hubu byly představeny (i když z pohledu datové kvality) v kapitole s rešerší v sekci 3.4. Nyní vybereme ten z nich, který se bude nelépe hodit pro realizaci diplomové práce. Určíme i další nástroje, pomocí nichž pokryjeme ostatní části zobrazené na diagramu nasazení 5.8. Nástroje pro datovou kvalitu Výběr nástroje pro datovou kvalitu je nejdůležitější. Když jsme uvedli kvadranty firmy Gartner na obrázku 3.4, získali jsme tak i přehled možností, jaké lze pro komplexní řešení datové kvality použít. Při výběru nástroje pro diplomovou práci byly hodnoceny různé parametry, největší váha byla dána následujícím: podpora českého prostředí, dostupná podpora pro produkt v průběhu realizace, cena produktu pro vývoj práce a složitost nasazení. Volba těchto parametrů je odůvodněna především schopností efektivně realizovat diplomovou práci bez vysokých finančních nákladů a dalších komplikací. Protože autor práce spolupracuje se společností Ataccama, byl zvolen právě její produkt MDC (Master Data Center), jehož licenci má autor zdarma k dispozici, a se kterým již má řadu zkušeností. Mezi další podstatné výhody tohoto nástroje patří snadná integrace s běžnými typy databází, bohatá podpora domácího prostředí (komponenty pro práci s českými adresami, IČ, rodnými čísly. . . ), sada příkladů a tutoriálů dodávaných s produktem, použití aplikace bez nutnosti instalace a složitých konfigurací, přenositelnost díky implementaci v Javě a další. Použijeme aktuální verzi, tj. 7. Využijeme ji nejen pro datovou kvalitu, ale pro kompletní simulaci MDM řešení.

56


Databáze Datovým úložištěm bude databáze, máme k dispozici řadu možností. Pro účely diplomové práce není nutné posuzovat podrobné rozdíly mezi různými databázovými stroji. Autor práce má praktické zkušenosti s Microsoft SQL a Oracle, obě jsou ve svých minimálních edicích k dispozici zdarma. Kvůli lepší přenositelnosti mezi operačními systémy byla nakonec vybrána Express edition databáze Oracle ve své současné verzi 11g. Pro editaci databáze je k ní k dispozici nástroj Oracle SQL Developer, také zdarma. Simulace externích systémů Externí systémy budeme blíže rozebírat v sekci 5.7. Z hlediska nástrojů je relevantní možnost využívat služeb datové kvality on-line (o realizaci režimu dávek bude právě pojednáno v podkapitole 5.7). K zadávání dotazů využijeme open source program SoapUI 2 ve verzi 4.0.1 dostupné v době realizace práce.

5.5.1

Unifikační repository

V rámci nástrojů datové kvality se ještě věnujme řešení unifikace. Zvolený program Master Data Center si výsledky párování uchovává v databázi v samostatných tabulkách, které se dohromady nazývají repository. Jaký je jejich význam? Duplikují bezpečným a rychlým způsobem všechny párované záznamy a údaje o jejich unifikačních atributech. Pokud tedy přichází změna na nějakém záznamu, rychle se z repository dohledá skupina, do které záznam patří, jakou roli v této skupině má apod. Navíc je repository spravována pouze prostředky MDC, není do ní zasahováno odjinud, jako se to může dít na normálních tabulkách. Díky MDC repository také neřešíme v diplomové práci manuální výjimky při párování, kterými explicitně určujeme, které záznamy patří či naopak nepatří k sobě. MDC má tuto funkcionalitu v repository implementovánu, ale pro její editaci je potřeba další nástroj (viz [11]). Proto ji zařazujeme pod komponentu Other MDM components uvedenou v diagramu nasazení 5.8.

5.6

Podpůrné služby

Podpůrné služby musí být přímou součástí řešení, přestože by se s nimi v kontextu celého MDM hubu nakládalo poněkud odlišně a musely by být vypracovány další postupy na jejich správu.

5.6.1

Logování

První podpůrnou službou je logování. V MDM hubu se typicky jedná o komplexně pojatou problematiku, která patří k velice důležitým aktivitám. Pro účely diplomové práce však není 2

http://www.soapui.org/

5.6. PODPŮRNÉ SLUŽBY

57

podstatné řešit logování v této šíři (např. navrhnout strukturu tabulek, aby pokrývaly obecné logování různých situací). V detailním designu komponent byly zmíněny tři situace, které vyžadují uchování informací pro případnou budoucí analýzu chování hubu. • Zalogování chybných referencí, tabulka LOG_DATA_REL_ENTITIES – Do tabulky se zapíše klíč subjektu v MDM hubu, na který se odkazuje navázaná entita a který není uložen ani v databázi ani není přítomen ve vkládané dávce. • Zalogování odmítnutých záznamů, tabulka LOG_DATA_DISCARDED_RECS – Do tabulky se zapíše klíč odmítnutého subjektu při unifikaci a status, s jakým byl z unifikace vyřazen (nejčastěji půjde o duplicitu primárního klíče na vstupu, k čemuž by ale ve standardním MDM hubu docházet nemělo kvůli vyšším kontrolám na vstupech). Podle času zalogování lze zpětně určit, v jaké dávce se záznam nacházel. • Zalogování chybných flagů I, U, D, tabulka LOG_DATA_LOAD – Loguje se pouze při ukládání záznamů, došlo-li ke změně typu ukládání (vkládání, aktualizace, mazání). Uloží se název entity, její klíč, původní typ ukládání a řetězec se změnou tohoto typu. Mohou nastat tyto změny: – I_TO_U – Vložení již existujícího záznamu je převedeno na aktualizaci. – I_TO_AD – Nové vložení již smazaného záznamu je převedeno na zaktivnění a aktualizaci hodnot. – U_TO_UD – Aktualizace smazaného záznamu jen přepíše atributy vč. data aktualizace a nechá záznam neaktivní (smazaný). – U_TO_I – Aktualizace neexistujícího záznamu je jeho vložení. – D_TO_ID – Smazání neexistujícího záznamu je jeho vložení ve stavu smazaný. – D_TO_DD – Smazání již dříve smazaného záznamu je podobné U_TO_UD, pouze aktualizuje datum smazání. Všechny logovací tabulky obsahují samozřejmě i čas zalogování a primární klíč id. Zápis do tabulky bude řešen standardně přes procedury logovací package.

5.6.2

Číselníky

Druhou podpůrnou službou, která je úzce propojena s nástrojem pro datovou kvalitu, je správa číselníků (etalonů). Konkrétní použití a potřeba číselníků bude upřesňována v implementaci. Již nyní lze ovšem provést negativní vymezení – nebudeme používat blacklisty a whitelisty (tedy číselníky hodnot různých atributů, které budou automaticky bez dalších validací a kontrol zamítnuty, resp. přijaty). Získávání zdrojů číselníků u pravidelně a řízeně aktualizovaných (Registr ekonomických subjektů ku příkladu) i těch, které se tvoří vlastní silou (číselník zemí, který se převezme od Statistického úřadu a je možné ho aktualizovat jen sporadicky, kompletní číselníky adresních atributů ze stránek Ministerstva vnitra), nebude v rámci práce řešeno. Zdroje číselníků je

58


totiž někdy nutné vytvářet ručně z údajů na internetových stránkách, někdy je nutné za zdrojové soubory dokonce zaplatit (platí např. pro adresní registr). S řešením v diplomové práci budou k dispozici etalony ve třech podobách. • Číselníky Ataccama – Některé číselníky byly pro vývoj vypůjčeny od společnosti Ataccama. Tyto číselníky jsou vlastnictvím společnosti, a nemohou tudíž být součástí CD s diplomovou prací. Jde o seznamy jmen a příjmení osob. Dodatek E rozebírá, jak tyto etalony vytvořit. • Číselníky se zdrojovými soubory – Dodány budou ve formátu CSV. Ke všem z nich budou vytvořeny MDC plány 3 , jejichž spuštěním se vytvoří korespondující .lkp soubory, se kterými pracuje MDC. Některé se uloží i do databáze (ty, které jsou uvedeny v datovém modelu, viz 5.1). Jde o téměř všechny číselníky použité v práci, kromě uvedených v předchozí a následující položce. • Komerční číselníky – Pro komerční číselníky, tedy Registr ekonomických subjektů a Územně identifikační registr adres, které jsou distribuovány oficiálně komerčním způsobem, nelze v diplomové práci poskytnout ani zdrojové ani binární soubory. Budou k dispozici pouze plány na převedení zdrojových CSV do .lkp. Podrobnější informace viz příloha E. Kromě úplných číselníků (kódy všech zemí světa, všechny telefonní předvolby, adresní body ČR apod.) se vždy v případě zdrojových souborů bude jednat o seznamy vytvořené za pomocí zkušeností autora práce, případně inspirace Ataccama. Potom například u rodinných stavů nemusí být používané etalony kompletní. Pro funkční stránku řešení to však nemá vůbec žádný vliv.

5.7

Simulace externích systémů

Na diagramu nasazení 5.8 je ukázáno, že na Master Data Management hub se připojuje velké množství rozličných externích systémů. Výše jsme dokonce zmínili, že se mohou připojovat přes řadu různých rozhraní. Dala by se vymezit i spousta způsobů, jak přístupy řídit. Základní rozdělení, které jsme již v minulých kapitolách vymezili pro externí systémy, bylo na on-line a dávková rozhraní. Tohoto dělení se budeme držet, protože nám umožní definovat dva základní přístupy – dávková rozhraní typicky do hubu dodávají data ve větším množství a neočekávají rychlé zpracování a okamžitou odezvu. On-line připojené zdroje naopak operují s menším počtem dat a většinou očekávají v reálném čase nějakou odpověď. Modelově tedy připojíme oba typy rozhraní vytvořením vrstvy, jež bude umět načíst dávku/požadavek a předat je do komponenty DQTool. Pro dávková rozhraní budeme předpokládat, že byly dodávky doručeny přes externí B2B, budeme pro snadnou manipulovatelnost vyžadovat soubory ve formátu CSV s oddělovačem středník a kódováním UTF-8. Názvy souborů budou odpovídat názvům entit a soubory se budou nacházet v určeném adresáři. Vždy jich musí být kompletní sada, i kdyby některé 3

Pojem MDC plán bude podrobněji představen v kapitole 6.

5.7. SIMULACE EXTERNÍCH SYSTÉMŮ

59

z nich neobsahovaly žádný záznam – bude v nich alespoň řádek s hlavičkou. První sloupce budou obsahovat typ záznamu (I, U, D – přes B2B nebude prováděn režim identifikace, protože není kam a komu vrátit identifikované záznamy), jeho id ve zdrojovém systému, kód zdrojového systému, na nějž bude zaveden číselník, a pro navázané entity ještě id rodičovského subjektu. V rámci diplomové práce nebudeme samozřejmě realizovat B2B, proto předpokládáme doručení souborů a provedení kontrol. Nebudou realizovány ani žádné další mechanismy, jako závory při zpracování, notifikace, časovače apod. To vše by komponentě DQTool měl zajistit MDM hub, jehož je součástí. Poznamenejme, že se nebude provádět ani validace provozních sloupců, tedy typu záznamu, jeho id ve zdroji a podobně. Předpokládá se, že tyto atributy jsou vyplněny spolehlivě. Pro on-line komunikaci vytvoříme rozhraní, které bude standardně provolatelné přes SOAP pomocí webových služeb (rozhraní bude odpovídat strukturám vstupních CSV souborů pro dávkové vstupy). SOAP volíme kvůli jeho přímé podpoře v nástroji MDC. Jinak lze připojovat on-line rozhraní přes REST, vzdálené volání procedur a další.

60


Kapitola 6

Realizace V předchozích kapitolách byla postupně z různých stran rozebrána problematika datové kvality v Master Data Management hubu s ohledem na underwriting. Nyní popíšeme skutečnou implementaci řešení, které bylo navrženo v kapitole 5. Představíme postup, jímž se realizace ubírala, budeme se věnovat některým praktickým záležitostem, uvedeme praktické ukázky a budeme ilustrovat celý proces práce s daty na názorném příkladu, na jehož základě vysvětlíme skutečný přínos práce do problematiky underwritingu. Na konci věnujeme poznámku integraci komponenty DQTool a vývojovému testování.

6.1

Postup realizace

Než se budeme v dalších podkapitolách věnovat konkrétním záležitostem, jež implementace řešení přináší, začneme obecně popisem postupu realizace. Ukážeme, jak implementace navazuje na teoretickou, analytickou a návrhovou fázi a jak zapadá do časového kontextu celé práce.

6.1.1

Použitý model

Protože práce byla navrhována i realizována jedním člověkem, nebylo nutné se striktně držet některé z metodik softwarového inženýrství. Autor práce navíc mohl vycházet ze zkušeností z dosavadní praxe. Přesto však nebylo možné práci dovést do konce způsobem waterfall, tedy dodržet vývoj přesně tak, jak jsou v textu řazeny jednotlivé kapitoly, aniž by došlo k revizím předchozích výstupů. Již od analýzy bylo nutné postupovat iterativním modelem, v jehož rámci byla vytvořena řada prototypových proof of concept (PoC) řešení. Díky nim bylo možné dále specifikovat některé části, a to zvláště v návrhu. Typickým PoC bylo třeba zapojení unifikačního procesu, kterým se teprve vymezily unifikační atributy a skutečný význam MAT hodnot. Stejný případ, kdy orientační implementace pomohla dojasnit design, bylo pořadí některých kroků čistících komponent. Při realizaci PoC se také ukázala potřeba dodefinovat v návrhu např. všechny potřebné číselníky. Implementace tedy nebyla pouhým vyústěním analýzy a návrhu, ale přinesla do těchto kapitol iterativní zpřesnění a doplnění mnohých informací. I v reálných projektech se přístup

61

62

KAPITOLA 6. REALIZACE

pomocí PoC a prototypů často používá, zvláště dodává-li se nové, poprvé realizované řešení. Vytvořená PoC sloužila jako výchozí podklad pro další implementaci.

6.1.2

Časové rozložení

Z hlediska projektového je zajímavé porovnat, kolik času bylo v diplomové práci stráveno nad jednotlivými fázemi vývojového cyklu software. Po celou dobu byly podrobně zaznamenávány hodiny pro časové vyhodnocení. Nad prací bylo stráveno cca 400 hodin, což odpovídá 60 člověkodnům, tedy asi třem měsícům práce na plný úvazek. Autor práce však nezačínal „od nuly“, vycházel ze zkušeností z reálné praxe, a proto tento počet hodin není možné brát za kompletní informaci o náročnosti práce. Z vedených záznamů lze vyčíst časové poměry strávené v jednotlivých etapách. Zhruba stejný čas (cca 40 hodin) zabraly teoretické části, stejně analýza a přibližně stejně návrh. Dvakrát více než analýze bylo věnováno testování a cca čtyřikrát více implementaci (v níž ale bylo zahrnuto také vývojové testování na úrovni jednotek, celé komponenty DQTool i integrace a také několik zpětných aktualizací textu návrhu).

6.2 6.2.1

Další praktické informace k realizaci Jazyky a forma realizace

V projektu jsme se rozhodli využít program MDC a databázi Oracle. Tím je jazyk a forma realizace přesně určena (verze aplikací jsou popsány již v návrhu v podkapitole 5.5). Pro přístupové databázové balíčky a případně dotazy v databázi byl použit jazyk SQL, resp. PL/SQL. Pro realizaci všech komponent (ale i např. převedení číselníků ze zdrojových souborů do binárních .lkp) se v nástroji MDC používají tzv. plány. Plán je vizuálním vyjádřením procesu, který zpracovává data ze vstupu a různými modifikacemi, seskupováním, filtrováním a dalšími operacemi z nich vytváří data výstupní. Uvnitř jednotlivých kroků v plánech se pak nastavují parametry těchto kroků, případně využívá programový kód založený na funkcích aplikovaných nad sloupci. Ukázky viz sekce 6.2.3.

6.2.2

Vývojové prostředí, možnosti a omezení nasazení

Procesy čištění, standardizace a samozřejmě i unifikace jsou výpočetně velice náročné, protože obsahují řadu řetězcových operací, dochází k porovnávání různých atributů a hledají se jejich podobnosti; stejně tak je nutné vyhledávat ve velkých množstvích dat v číselnících, které jsou pro zrychlení nahrávány do paměti (až řádově v GB). Další problém představuje kontakt s databází, protože unifikace potřebuje přistupovat ke všem uloženým záznamům. Proto se obsah databáze nahrává pro unifikační účely na aplikační server (a tím mizí nutnost častých dotazů na databázový stroj).

6.2. DALŠÍ PRAKTICKÉ INFORMACE K REALIZACI

63

Je tedy jasné, že osobní počítač, který byl použit při vývoji řešení, není rozhodně schopen zpracovávat větší množství dat blízké reálnému vytížení u skutečných Master Data Management řešení. Tento aspekt je důležitý hlavně pro prováděné testování. Prostředí pro běh řešení je tedy determinováno svým výkonem. Nicméně platí i některá další softwarová omezení. Vývoj probíhal na platformě Windows 7, 64-bit, Home edice. Pro fungování programu MDC je zapotřebí navíc Java runtime, využita byla verze 6. MDC je ovšem díky Javě přenositelné i na jiné operační systémy. A protože databáze Oracle podporuje také více OS, není tento aspekt pro řešení omezením. Poslední potenciální omezení je prostorové. Naštěstí však s komponentou DQTool úplně nesouvisí, protože ta kromě databáze neuskladňuje žádné velké objemy dat. V kontextu celého MDM řešení jsou pak kapacitní otázky (historizovat data?, jak často promazávat logovací záznamy? apod.) mnohem důležitějším problémem.

6.2.3

Plány MDC

Rozebrali jsme použité jazyky a formy realizace, představili jsme v podkapitole 6.2.1 MDC plány. Na obrázku 6.1 je ukázka, jak takový plán vypadá. Jde o výsek z realizace diplomové práce.

Obrázek 6.1: Ukázka (výřez) MDC plánu.

Jde o síť tvořenou kroky (stepy). Mezi nimi po hranách putují záznamy dat. Tečou od speciálních vstupních stepů (čtení z databáze, dotaz přes SOAP, načtení souboru, integrační

64


vstup pro data z jiných plánů apod.) směrem ke speciálním výstupním stepům (zápis do databáze, do souboru, integrační výstup pro propojení s jiným plánem apod.). Mezi nimi jsou data různě měněna, obohacena, filtrována, deduplikována, seskupována, řazena a jsou s nimi prováděny všechny potřebné modifikace. Každý step má svůj speciální úkol a jejich kombinací je možné získávat velice složité datové transformace. Pro podrobnější popis a seznam použitelných kroků odkazujeme do dokumentace, která je součástí programu MDC. Jako příklady použití kroků je na obrázcích 6.2 a 6.3 ukázáno, jak se detailní diagramy z návrhu převedly v implementaci do MDC plánů. První je odhadování typu subjektu, když se nepodařilo hledání v číselnících právnických osob ani používaných jmen. Druhý zobrazuje úsek zpracování adresy, nebyla-li nalezena ani podruhé v adresním registru UIR-ADR. Na druhém obrázku se také nachází ukázka vnitřku jednoho stepu (přiřazení hodnoty do sloupce), kde je použit kus programového kódu.

Obrázek 6.2: Ukázka implementace části návrhu v plánu MDC – hádání typu subjektu.

Plány se dají vzájemně kompozitně spojovat a vkládat jeden do druhého jako komponenta. Další velikou výhodou je možnost debugovat chování jednotlivých stepů.

6.2. DALŠÍ PRAKTICKÉ INFORMACE K REALIZACI

65

Obrázek 6.3: Ukázka implementace části návrhu v plánu MDC – zpracování adresy a ukázka výrazu.

6.2.4

Souborová struktura projektu

Projektová struktura diplomové práce bude rozebraná podrobněji v přílohách, zde uvádíme, co vše je součástí implementačního workspace používaného programem MDC.

66


Nalezneme zde adresář components s realizací jednotlivých komponent vymezených ve fázi návrhu. Dále složku etalons, ve které je k dispozici kompletní struktura potřebná k práci s číselníky – tedy adresáře bin s binárními soubory pro přímé použití v plánech, build s plány na vytvoření .lkp souborů a případně databázových tabulek ze zdrojů číselníků (adresář sources). Potom se ve workspace nachází složka plans s plány, které zabalují komponentu DQTool (a přidávají např. komunikaci přes webové služby apod.). SQL skripty potřebné pro obsluhu databáze a vytváření či mazání tabulek, triggerů, balíčků a procedur jsou dostupné ve složce sql. Vše potřebné k testování (viz další kapitola 7) se pak nachází ve složce tests. Soubory se zdroji dat se nachází mimo strukturu workspace.

6.3 6.3.1

Ukázka realizace Příklad

Abychom předvedli funkčnost komponenty, zvolíme reálný příklad z použitých testovacích dat, na kterém ukážeme, jakými jednotlivými kroky entity procházejí. Vysvětlíme význam některých atributů a ukážeme, jak výsledný výstup může napomáhat underwritingovým procesům nad daty klientů. Uvedeme na začátek výchozí tabulku 6.1, kde se nachází výběr nejdůležitějších atributů na vstupu, jde o entity Subject a Address. Atribut s rodným číslem pro jistotu v žádné tabulce neuvádíme celý, aby bylo zřejmé, že nejde o skutečná data. Id 1205 1206 1201

Typ P P

Pohlaví

Id 7004 7005 7007 7009

Subjekt 1205 1206 1201 1205

Rodné č. 5******1 5******5 3******3

Ulice Francouzská Francouzská Francouzská

Jméno ŽÁK Žáková KAREL

Č. pop. 152/78 152 152/78

Dr. jméno

Příjmení

Dana

Č. or.

Rod. příjm. Pekařová

Pekař Obec Praha 10 Praha Praha 10 JEDOVNICE 501

PSČ 10100 10100 679 07

Země CZ (CZ) CZ

Tabulka 6.1: Příklad na konkrétních datech – vybrané vstupní atributy entity subjektu a adresy. Tato data tedy komponenta přijala v dávce a prvně se je pokusí vyčistit a standardizovat. Je vidět rozdíl mezi čištěním v tabulce 6.2 a standardizací 6.3, kde již máme data výrazně lepší než na vstupu. Příkladem může být kód země u adresy (z vyčištěného CZ na standardní kód CZE, a to i u adresy, která ho neměla na vstupu vůbec zadán; obdobně u jmen pouhé vyčištění velikosti písmen vůči rozhodnutí o skutečném pořadí jména a příjmení a dokonce dopočítání pohlaví osoby).

6.3. UKÁZKA REALIZACE

Id 1205 1206 1201

Typ P P

Pohlaví

Id 7004 7005 7007 7009

Subjekt 1205 1206 1201 1205

67

Rodné č. 5******1 5******5 3******3

Ulice Francouzská Francouzská Francouzská

Jméno Žák Žáková Karel

Č. popisné 152 152 152

Dr. jméno

Příjmení

Dana


Pekař Č. orient. 78 78 501

Obec Praha Praha Praha Jedovnice

PSČ 10100 10100 67907

Země CZ CZ CZ

Tabulka 6.2: Příklad na konkrétních datech – atributy obou entit po čištění. Id 1205 1206 1201

Typ P P P

Pohlaví M F M

Id 7004 7005 7007 7009

Subjekt 1205 1206 1201 1205

Rodné č. 5******1 5******5 3******3

Ulice Francouzská Francouzská Francouzská Na kopci

Jméno

Dr. jméno

Dana Karel

Č. popisné 152 152 152 501

Č. orient. 78 78 78

Příjmení Žák Žáková Pekař Obec Praha Praha Praha Jedovnice


PSČ 10100 10100 10100 67907

Země CZE CZE CZE CZE

Tabulka 6.3: Příklad na konkrétních datech – atributy obou entit po standardizaci. Dále jsou ke všem řádkům přidány informace o score atributů a připojeno vysvětlení, proč bylo toto score uděleno. Uvedeme tři příklady: • Ulice u adresy 7009 – Ulice byla dohledána až z adresního registru, a to pouze na základě poskytnutého popisného čísla. Je pravděpodobné, že tento údaj je dohledán správně. Protože však může být lehce ovlivněn případným překlepem v čísle, penalizujeme ho score 50 a označíme vysvětlením DQMID_FOUND_IN_AI. • Pohlaví u všech subjektů – Pohlaví u subjektů nebylo poskytnuto, nicméně bylo možné jej získat z rodného čísla a potvrdit pomocí číselníků mužských a ženských jmen používaných v České republice. Přesto však tento údaj nemusí být stoprocentně důvěryhodný, proto ho penalizujeme na hranici střední úrovně pomocí score 99 a vysvětlovacího kódu DQMID_DERIVED_OR_GUESSED. • Jméno u subjektu 1205 - Jméno bylo sice poskytnuto a dokonce by svou strukturou (pouze písmena) mohlo i jménem být, ale kontrolou proti číselníkům bylo zjištěno, že se o jméno nejspíše nejedná. Proto hodnotu penalizujeme vysokým score 900 s vysvětlením DQLOW_NOT_CONFIRMED. Hodnota je ovšem správně zapsána pod příjmení.

68


Celkové score entit se pohybuje ve střední úrovni pod prahem 100, pouze u prvního subjektu je již označeno jako DQLOW. Přesto však nedojde k překročení prahu na dávku a data jsou zpracovávána dalšími kroky. Pro účely unifikace je z adresy vždy vytvořen řetězec, který nese všechny relevantní informace, např. pro třetí adresu (7007) vypadá takto (obsahuje informaci o identifikátoru v adresním registru, poštovním směrovacím čísle, obci, ulici a číslech popisném a orientačním). 22656201##10100##Praha##Francouzská##152##78 V modelovém příkladě neuvažujeme dotahování dalších entit z databáze, takže záznamy projdou přímo do unifikační komponenty. Zde jsou adresy připojeny k subjektům. Jak tedy dopadla unifikace? Výsledek se dal očekávat z poskytnutých dat, nicméně při počtech milionů klientů již není ani pro člověka možné správně vztahy mezi záznamy rozlišit. Všechny tři subjekty totiž tvoří právě jednu kandidátskou skupinu, a to na základě těchto pravidel (byla uvedena v návrhu v podkapitole 5.3.2 u popisu komponenty match_subject). • Sloučení 1205 a 1206 – Spárováni dle pravidla shoda v příjmení (včetne deklinace) a adrese, business význam tohoto sloučení spočívá ve faktu, že nejspíše půjde o manžele, případně o otce a dceru. • Sloučení 1206 a 1201 – Spárováni dle pravidla shoda v příjmení (včetne deklinace) a rodném jméně a adrese, business význam tohoto sloučení je v propojení manželů, nebo jako v tomto případě propojení mezi více generacemi žijícími na stejné adrese, zde nejspíš vztah otec-dcera. Klientské skupiny, v nichž odlišujeme jednotlivé osoby, však samozřejmě patří každému subjektu zvlášť. Nakonec se ještě kontrolují některé ukazatele a jejich vyhodnocení je zapsáno do DTC sloupců. Na ukázkových datech nejsou zaznamenány žádné zajímavé abnormality.

6.3.2

Přínos pro underwriting

Jaký je tedy přínos pro underwriting? Proč mělo smysl budovat složité řešení? Odpovězme na základě uvedeného příkladu na tuto otázku. Řešení v diplomové práci vnáší do dat zcela nové vztahy, což je právě pro problematiku underwritingu klíčové. Underwriter má najednou před sebou více informací, se kterými může pracovat. Dostaví-li se mu na přepážku pan Žák a pan Pekař, hned ví, že při vyhodnocování žádostí o úvěr musí započítat i fakt, že jde o příslušníky jedné rodiny spojené přes dceru (resp. manželku). Přitom ale v původních datech neexistoval žádný důvod toto spojení vytvořit. K tomu musela být správně vyčištěna a standardizována, např. jméno Žák určeno jako příjmení, odhadnuta pohlaví osob apod. Tato data potom mohla být spárována v unifikačním procesu do kandidátských skupin, se kterými underwriter pracuje. Systém má ale jedno přirozené omezení – kvalitu a skutečný význam vztahů entit již musí underwiter interpretovat sám. Třeba v situaci, kdy v jedné domácnosti bydlí dvě ženy se stejným příjmením. Pak systém provede spárování, ale až underwriter rozlišuje, zda jde o sestry, nebo matku s dcerou.

6.4. INTEGRACE A VÝVOJOVÉ TESTOVÁNÍ

6.3.3

69

Problémy a úskalí při realizaci

V předchozí podkapitole jsme na příkladu ukázali, jak probíhá zpracování dat v komponentě DQTool. Nyní vyjmenujeme několik úskalí, která byla při implementaci objevena. • Pády MDC – Při testování integrace čištění, ještě před tím, než byla implementována unifikační komponenta, docházelo k častým pádům prostředí MDC (neidentifikovatelná chyba v native kódu Javy). Chyba později vymizela s postupem další implementace. • Promazávání databáze při testech – Týká se hlavně vývojového testování unifikace, kdy bylo potřeba vždy před novým spuštěním manuálně aplikovat drop/truncate skripty v databázi, aby byla znovu nastavena do iniciálního stavu. Analogicky při zkoušení inkrementů1 bylo nutné vždy před tím nahrát iniciální data. • Nekvalitní data při vývojovém testování – Data použitá při vývojovém testování byla často vytvářena ručně, a proto výsledky čištění, standardizace i unifikace neodpovídaly požadavkům. Nicméně šlo o zkoncentrované extrémní případy, jež neodpovídaly měřítku reálného světa. • Nedohledatelnost některých algoritmů – Velký problém byl s dohledáním některých algoritmů a pravidel v čištění a validaci hodnot. Často muselo být čerpáno ze znalostí pracovníků společnosti Ataccama. • Problém s některými číselníky – Úskalím pro standardizaci byla často nedostupnost některých číselníků, resp. zdrojů pro ně. • Kompromisy – Při realizaci bylo nutné provádět kompromisní rozhodnutí. V čištění např. zda bude benefit v tom, že ze zdrojového atributu získáme ještě nějakou hodnotu navíc, i když to ale v jiném případě může znamenat chybné vyčištění. Obdobně v pravidlech unifikace nalézt správnou míru (např. správné Levenshteinovy vzdálenosti) podobnosti záznamů.

6.4

Integrace a vývojové testování

Integraci a vývojovému testování věnujeme již jen krátkou poznámku. Integrace byla prováděna postupně, nejprve byla implementována kostra komponenty s průtokovým čištěním a unifikací, již s funkčním ukládáním do databáze. Teprve potom byly postupně realizovány komponenty čištění a standardizace a nakonec unifikace s testem abnormalit. Integrace tedy probíhala shora dolů postupným implementováním konkrétních detailů. Jednotlivé komponenty byly testovány zvlášť, vždy svou sadou dat vhodnou na prověření jejich funkčnosti. Tato data byla vytvářena ručně a pro testování celého systému se nehodí, např. testovací data subjektů nebyla nijak provázána s adresami apod. Poté proběhl základní vývojový test celé komponenty i jejího napojení na okolí. Vývojové testy nebudou součástí odevzdání, budou zahrnuty do komplexních testů, které prověří všechny aspekty řešení. Je jim věnována celá kapitola 7. 1

Inkrementem je myšleno načtení druhé a každé další dávky dat. První dávka je nazvána iniciální.

70


Kapitola 7

Testování Tato kapitola bude celá věnována testům řešení. Bude vymezena míra chybovosti, pak pojednáme o tom, jak ji určovat, vytvoříme testovací plán a představíme výsledky. Nakonec se budeme věnovat i ověřování výkonnosti celého řešení.

7.1

Míra chybovosti

Pro hodnocení datové kvality jsme se rozhodli použít (viz 4.5) jednoduchou metriku – poměr chybných záznamů vůči všem záznamům. Za jeden „záznam“ budeme v testování považovat typicky řádek souboru na výstupu, případně jednu odpověď on-line služby. Za chybový označíme takový záznam, kde bude alespoň jeden atribut vyplněn jinak, než bylo očekáváno. Z hlediska datové kvality pak půjde převážně o kontrolu správného čištění a standardizace, ale i přiřazení vysvětlujících kódů, score a zařazení subjektu do kandidátské či klientské skupiny, stejně jako správnost rozhodnutí o odmítnutí dávky ze zpracování. Pro účely testování nedokážeme zavést rozumný práh p (např. nelze určit, jaké procento chybně unifikovaných záznamů je pro zákazníka akceptovatelné), proto zvolíme raději dva prahy, které nám rozdělí chybovost do tří skupin. Snahou pak bude získat takové výstupy z komponent, aby spadaly do kategorie s nejnižší chybovostí. Budeme tak moci porovnávat kardinality jednotlivých kategorií a určovat celkovou kvalitu výstupních dat. Prahy zvolíme bez složitých úvah 2 a 10 chybných záznamů ze sta. Na jednu stranu to znamená, že pro subjekt s více než stovkou atributů je pro nejnižší kategorii povoleno mít chybně dva atributy z deseti tisíc, ale na druhou stranu při reálném počtu např. deseti milionů klientů jich takto může být až dvacet tisíc chybných!

7.2

Ověření chybovosti

V analýze v podkapitole 4.2 byly vymezeny dimenze datové kvality, které musí řešení postihnout. Než přistoupíme k definování toho, jak ověřovat chybovost, rozebereme jednotlivé dimenze a jejich vztah k testování.

71

72

7.2.1

KAPITOLA 7. TESTOVÁNÍ

Testy a dimenze datové kvality

První z nich je identifikace a homogenita. Naplnění této dimenze plyne přímo z designu, hlavně z datového modelu (konzistence názvů atributů, atributy se stejným významem, např. kód země, se jmenují stejně) a způsobu tvorby referenčních klíčů entit. Obdobně lze uznat i splnění rozsahu (viz omezení business atributů do jednoho ukázkového apod.) a relevance, která je vyjádřena komentáři k datovému modelu, zvolenými prefixy atributů, dokumentací programu MDC atd. Hodnotovými dimenzemi jsou úplnost, konzistence a přesnost – ty již souvisí přímo s obsahem atributů a budou proto ověřeny v testovacím procesu. Splnění těchto dimenzí je dáno správným umisťováním hodnot při čištění a standardizaci entit a správným párováním záznamů. Testování těchto aspektů se věnuje skoro celý zbytek kapitoly. Posledními vymezenými dimenzemi jsou vhodnost formátu a interpretovatelnost dat. Obojí je opět určeno již ve fázi návrhu pomocí vhodných datových typů v modelu.

7.2.2

Způsob ověření chybovosti

Již bylo řečeno, že budeme vyhodnocovat vždy nějakou sadu záznamů na její chybovost, čímž ji zařadíme do jedné ze tří kategorií. Pojďme vymezit, co budeme chápat jako sadu záznamů. Postupně budeme spouštět testy definované plánem, který představíme níže v sekci 7.3. Z každého běhu (např. běh pro kontrolu čištění a standardizace) získáme několik souborů s výstupem. Související skupinu souborů budeme považovat za sadu záznamů. Vyhodnocovat je budeme přes všechny řádky všech výstupních entit. Může pak v různých souvisejících bězích nastat, že se chyby budou opakovat, nicméně nejde o zásadní problém. V případě on-line služeb budeme za sadu považovat skupinu odpovědí na nějaký počet testovacích volání služby. Pro jednotlivé kroky plánu ověříme, jak kvalitní jsme získali na daných vstupních datech výstup. Potřebujeme však určit očekávané výstupy a provádět porovnání se získanými daty z komponent. Než bude tedy možné spustit samotné testování a postupně opravováním chyb konvergovat ke stále kvalitnějším výstupům, musíme vytvořit „etalonové“ výstupy, tedy verze souborů s očekávanými výsledky. Získáme je automatickým vygenerováním pomocí testovacích plánů s následnými ručními kontrolami a úpravami. Využijeme také profiling jednotlivých sloupců (profiling dat je přímo funkcionalitou nástroje Master Data Center). Vytvořené vzory správných souborů budou k dispozici na přiloženém CD. Podobným mechanismem vznikly i porovnávací verze odpovědí on-line služeb, kde se používá dotazů jazykem XPath nad částmi navrácených dat. Tento způsob sice není zcela vhodný, nicméně nemáme kapacitu ani možnosti na automatické nebo naopak ruční generování. Proti těmto referenčním souborům budou kontrolovány výstupy testů pomocí nějaké varianty nástroje diff (bude nutné záznamy vždy seřadit podle jejich klíčů). Tato kontrola bude ruční, v rámci diplomové práce není dostatek prostoru na vytváření automatizovaných regresních testů. Naopak pro kontrolu výstupů on-line služeb využijeme možností programu SoapUI, kde automatizaci použijeme.

7.3. TESTOVACÍ PLÁN

7.2.3

73

Vstupní data

Problematika vstupních dat přímo ovlivňuje kvalitu a úspěšnost testů. Vstupní data musí být zvolena tak, aby v jednotkových testech pokryla co nejvíce hraničních a speciálních případů (např. při testu čištění nemá cenu předkládat komponentě standardní vzorek dat, ale je potřeba prověřit funkčnost na speciálně upravených datech). V integrační úrovni testů už musí být naopak kladen důraz na správnou spolupráci všech částí, a data je proto nutné analogicky upravit. Zcela zvláštní skupinou jsou záznamy pro ověřování unifikace, kde je nutné prověřit všechna pravidla definovaná v návrhu. Struktura vstupních dat vychází převážně ze zkušeností autora práce, odráží skutečnosti popsané v předchozím odstavci. Testování bude probíhat řádově na stovkách záznamů, čímž dosáhneme kompromisu mezi dostatečným souborem dat a únosností poloautomatizovaného vytváření referenčních souborů pro porovnávání výstupů. Vstupní data neobsahují reálné údaje o klientech (kromě právnických osob a fyzických osob – podnikatelů, kde jsou údaje veřejně dostupné v registru).

7.3

Testovací plán

Nyní podrobně popíšeme jednotlivé kroky testovacího plánu. K jejich realizaci byly vytvořeny MDC plány, které zajistí splnění všech operací daného kroku. Nacházejí se ve složce tests/plans. Obrázek 7.1 ukazuje, jak se plány spouští z menu na pravé tlačítko myši v programu MDC.

Obrázek 7.1: Spuštění plánu v Master Data Center.

Prerekvizitou testování je vytvořená adresářová struktura tak, jak je k dispozici na přiloženém CD v adresáři tests. Výstupy se zapisují do podsložky data_out, vstupy jsou k dispozici v data_sources a referenční výstupní data pro porovnávání v podadresáři reference_results. Další prerekvizitou je databáze, která musí obsahovat patřičné balíčky a tabulky (viz všechny SQL skripty s ddl v názvu). Struktuře složek ve workspace projektu se věnuje sekce 6.2.4 kapitoly o implementaci. Podrobné informace o vstupních datech, očekávaných výstupech a spouštěných MDC

74


plánech se nacházejí v tabulce 7.1 pod čísly odpovídajícími následujícímu seznamu. Položky seznamu představují kroky testovacího plánu, jak jdou postupně za sebou. 1. Inicializace databáze – V databázi musí být provedeno vyčištění obsahu (truncate, nebo delete from) všech tabulek, musí být smazány (drop) tabulky repository. Tento krok je realizován spuštěním plánu test_init_db.plan. 2. Testování čištění – Spustí se jednotkové testy komponent pro čištění a standardizaci jednotlivých entit. Výstupy komponent nejsou zapsány do tabulek v databázi. Výstupy jsou uloženy pro porovnání s referenčními soubory. Tento krok je realizován spuštěním plánu test_clnstd.plan. Test je možné spouštět opakovaně bez narušení ostatních kroků. 3. Testování unifikace – Spustí se jednotkový test komponenty pro unifikaci subjektů. Výstupy ovlivní repository v databázi. Výstupy jsou uloženy pro porovnání s referenčními soubory. Tento krok je realizován spuštěním plánu test_unify.plan. 4. Reinicializace repository – Po předchozím kroku je nutné smazat (drop) tabulky repository. Tento krok je realizován spuštěním plánu test_del_rep.plan. Lze ho nahradit krokem 1. 5. Integrační test, iniciální zpracování dat – Spustí se integrační test celé komponenty DQTool pomocí iniciální dávky dat. Výstupy nejsou zaznamenány, je pouze zapsáno do databáze. Následně je nutné vyexportovat obsah všech tabulek databáze (kromě repository), které komponenta používá (vč. logů). Jejich obsah je uložen pro porovnání s referenčními soubory. Tento krok je realizován sekvenčním spuštěním plánů test_dqtool_ini.plan a test_extract_db_after_ini.plan v tomto pořadí. 6. Integrační test, první inkrementální zpracování dat – Spustí se integrační test celé komponenty DQTool pomocí první inkrementální dávky dat. Výstupy nejsou zaznamenány, je pouze zapsáno do databáze. Následně je nutné vyexportovat obsah všech tabulek databáze (kromě repository), které komponenta používá (vč. logů). Jejich obsah je uložen pro porovnání s referenčními soubory. Tento krok je realizován sekvenčním spuštěním plánů test_dqtool_inc1.plan a test_extract_db_after_inc1.plan v tomto pořadí. 7. Integrační test, druhé inkrementální zpracování dat – Spustí se integrační test celé komponenty DQTool pomocí druhé inkrementální dávky dat. Výstupy nejsou zaznamenány, je pouze zapsáno do databáze. Následně je nutné vyexportovat obsah všech tabulek databáze (kromě repository), které komponenta používá (vč. logů). Jejich obsah je uložen pro porovnání s referenčními soubory. Tento krok je realizován sekvenčním spuštěním plánů test_dqtool_inc2.plan a test_extract_db_after_inc2.plan v tomto pořadí. 8. Kontrola výstupních souborů – Výstupní soubory jsou porovnány vůči referenčním souborům se stejnými názvy (a přidaným prefixem ref ). K porovnání je možné použít jakýkoliv program, který umí pracovat s CSV soubory, případně čistým textem. Autor práce použil program PSPad (umí seřadit řádky a provádět diff dvou souborů) a obyčejný tabulkový procesor Calc z balíku OpenOffice. Počet nesprávných řádků vůči všem řádkům pak určuje chybovost daného výstupu.

7.3. TESTOVACÍ PLÁN

Krok

2.

3.

5.

6.

7.

MDC plán Vstupní CSV soubory (data_sources) test_clnstd address_clnstd contact_clnstd document_clnstd sub2sub_clnstd subject_clnstd test_unify subject_unify test_dqtool_ini test_extract_db_after_ini address_INI contact_INI document_INI sub2sub_INI subject_INI

test_dqtool_inc1 test_extract_db_after_inc1 address_INC1 contact_INC1 document_INC1 sub2sub_INC1 subject_INC1

test_dqtool_inc2 test_extract_db_after_inc2 address_INC2 contact_INC2 document_INC2 sub2sub_INC2 subject_INC2

75

Výstupní CSV soubory (data_out)

Referenční CSV soubory (reference_results)

address_clnstd contact_clnstd document_clnstd sub2sub_clnstd subject_clnstd

ref_address_clnstd ref_contact_clnstd ref_document_clnstd ref_sub2sub_clnstd ref_subject_clnstd

subject_unify

ref_subject_unify

address_db_after_ini contact_db_after_ini document_db_after_ini sub2sub_db_after_ini subject_db_after_ini log_data_load_db_after_ini log_data_discarded_recs_db_after_ini log_data_rel_entities_db_after_ini address_db_after_inc1 contact_db_after_inc1 document_db_after_inc1 sub2sub_db_after_inc1 subject_db_after_inc1 log_data_load_db_after_inc1 log_data_discarded_recs_db_after_inc1 log_data_rel_entities_db_after_inc1 address_db_after_inc2 contact_db_after_inc2 document_db_after_inc2 sub2sub_db_after_inc2 subject_db_after_inc2 log_data_load_db_after_inc2 log_data_discarded_recs_db_after_inc2 log_data_rel_entities_db_after_inc2

ref_address_db_after_ini ref_contact_db_after_ini ref_document_db_after_ini ref_sub2sub_db_after_ini ref_subject_db_after_ini ref_log_data_load_db_after_ini ref_log_data_discarded_recs_db_after_ini ref_log_data_rel_entities_db_after_ini ref_address_db_after_inc1 ref_contact_db_after_inc1 ref_document_db_after_inc1 ref_sub2sub_db_after_inc1 ref_subject_db_after_inc1 ref_log_data_load_db_after_inc1 ref_log_data_discarded_recs_db_after_inc1 ref_log_data_rel_entities_db_after_inc1 ref_address_db_after_inc2 ref_contact_db_after_inc2 ref_document_db_after_inc2 ref_sub2sub_db_after_inc2 ref_subject_db_after_inc2 ref_log_data_load_db_after_inc2 ref_log_data_discarded_recs_db_after_inc2 ref_log_data_rel_entities_db_after_inc2

Tabulka 7.1: Plány, vstupní a výstupní data pro jednotlivé kroky testovacího plánu.

76


9. Integrační test, on-line dotaz na identifikaci – Posledním krokem testovacího plánu je otestování komunikace přes webové služby společně s prověřením módu unifikace identify. Záznamy jsou kontrolovány na výstupu služeb. K testování je k dispozici projekt do programu SoapUI ws-reader-soapui-project.xml. V něm je cca deset dotazů, u nichž je kontrolován výstup (zda jde o SOAP fault, zda odpovídá definovanému kontraktu přes XSD schéma, zda jsou na výstupu správná data odpovídající definovanému XPath). Testy jsou zaměřeny na integraci, rozhodování o datové kvalitě záznamu (atribut tech_dq_decision) a identifikaci subjektů. Na obrázku 7.2 je ukázáno, jak se spustí testovací sada v SoapUI a jak je vizuálně zobrazen její výsledek.

Obrázek 7.2: Spuštění testů v programu SoapUI a vizualizace výsledků.

7.4

Výsledky testů

Prvními testy, kterými komponenty musely projít, byla základní jednotková prověření při samotném vývoji, prováděná bez předem určené metodiky či postupu. Výsledky těchto testů nebyly uchovány, nebyla uchována ani testovací data (většina byla zahrnuta do vstupních souborů představených v předchozí podkapitole). Relevantní je pro nás proto pouze výstup z opakovaného spouštění testovacího plánu. V následujících odstavcích popíšeme výsledky testů, jaké typy chyb byly odhaleny a také do jakých kategorií chybovosti jednotlivé části řešení spadaly a spadají. Součástí práce nejsou podrobnější reporty testů, statistiky jsou představeny níže.

7.4. VÝSLEDKY TESTŮ

77

Výsledky rozdělíme po jednotlivých oblastech a slovně popíšeme. Nakonec sestavíme údaje do jednoho obrázku 7.3, abychom si mohli udělat podrobnější představu.

Čištění a standardizace (výstup kroku 2) • Subjekt – Zjištěno 13 chybných záznamů ze 129. Bylo potřeba řady (12) opakování testů, než se podařilo debugovat komponentu tak, aby se chybovost snížila na nejnižší úroveň. Bylo objeveno několik důležitých problémů. Při nalezení osoby v registru RES nebyl proveden překlad typu subjektu dle právní formy, také nedocházelo ke scoringu u subjektů nerozhodnutelného typu. Chybně se interpretovalo jméno ve tvaru „ jméno příjmení -“, kdy místo pomlčky mohl být jakýkoliv znak. Ten se pak nesprávně považoval za příjmení a skutečné příjmení za druhé jméno. Poslední problém nastával v případě chybně zadaného titulu, který se považoval za další jméno. • Vztah dvou subjektů – Nejjednodušší část řešení, testy neodhalily žádné chyby. • Adresa – U adresy při prvním běhu testů selhalo cca 30 záznamů ze 46 na vstupu! Bylo zapotřebí cca 15 dalších testů k nápravě všech chyb. U čištění se na výstup posílaly hodnoty velkými písmeny, odstraňovala se chybně diakritika v názvu obce a v číslech domu – např. u Frýdku-Místku se smazala pomlčka a čísla 123/12 se interpretovala jako 12312. Docházelo i k nekorektnímu propisování vyčištěné hodnoty ulice do standardizované při nenalezení v registru UIR-ADR. Poslední opravou bylo značné navýšení udíleného score (vyšší penalizace) u neověřených standardizovaných hodnot adres. • Kontakt – V prvním běhu testů bylo nalezeno 10 chyb ze 113 záznamů, k jejich nápravě bylo zapotřebí cca 8 dalších běhů. Za nesprávné bylo považováno hlavně přebírání vyčištěných hodnot do standardizovaných u neověřených čísel z ciziny. U e-mailů potom nefungovalo automatické doplňování domén u známých a široce používaných serverů (@seznam na @seznam.cz). • Dokument – Ze vstupních 39 záznamů prvním kolem testů neprošlo 8 záznamů, k jejich opravě bylo zapotřebí cca 7 dalších běhů. Chyba byla v číselníku pro kontrolu vydavatelů českých dokladů, nesprávné bylo také ponechání cizího kódu země ve standardizované hodnotě při nalezení českého vydavatele dokladu.

Unifikace (výstup kroku 3) Párování bylo již při vývoji testováno poměrně důkladně, proto i pro plné testy bylo použito vývojových dat s dalšími úpravami tak, aby byla pokryta všechna unifikační pravidla pro kandidátskou i klientskou úroveň skupin. Odhaleno bylo tudíž minimum chyb, přesto u 5 záznamů z 364 byla objevena nesrovnalost v jednom slučovacím pravidle pro kandidátské skupiny (mělo brát v úvahu i adresu, ale párovalo bez ní). Opravou chyby hned další testovací běh prošel.

78


Integrace (výstupy kroků 5, 6 a 7) • Iniciální načtení – Po načtení iniciální dávky dat byly zjištěny chyby v entitě adresa spadající ještě pod čištění, kde u 100 záznamů ze 467 se ke směrovacímu číslu vyhledal poštovní úřad místo názvu obce a případné číslo úřadu se v registru UIR-ADR interpretovalo jako číslo popisné. Tento případ byl pak i zpětně doplněn do testů čištění, vyžádal si pět retestů do opravy chyby. U subjektu tím pádem došlo ke zkreslení u adresních komponent, nicméně bez tohoto zkreslení byly záznamy v pořádku. Dva z nich byly správně při unifikaci odmítnuty jako duplicitní. • První inkrement – První provedení inkrementu odhalilo hned tři chyby většího rázu (bez přesného vyčíslení ovlivněných záznamů). Jednak se chybně vypočítával řetězec navázané entity pro potřeby unifikace – používal se v něm i vyčištěný typ entity, nově se používá pouze standardizovaná hodnota. Pro získávání subjektů z databáze pro navázané entity se také mylně přiřazoval režim identifikace místo správného ukládání. Třetím problémem byla duplikace subjektů v případě, že v dávce Subject2Subject byl některý z nich vícekrát jako rodičovský či dětský subjekt. Pro kompletní opravy bylo potřeba cca 28 běhů testů. • Druhý inkrement – Byl objeven problém patřící do čištění u 15 záznamů subjektu ze 400. Nedocházelo v jistých případech ke scoringu místa založení společnosti. Tato chyba byla opravena na jediný retest. On-line test identifikace (krok 9) Při aplikování SOAP dotazů byl zjištěn jediný integrační problém, totiž že subjekty dotažené z unifikační repository se uloží do databáze i v případě režimu identifikace. Chyba byla na jediný retest odstraněna.

7.4.1

Hodnocení testů

Nyní shrneme výsledky testů vizuálně do obrázku 7.3, kde barevně vyznačíme počty chyb P 1 pro jednotlivé testovací kroky pro úplně první spuštění (počty chyb pro jednotlivé tři specifikované úrovně pod 2 chyby ze 100 záznamů, 2 až 10 chyb a nad 10 chyb ze 100 záznamů) a rychlost opravy (kolik maximálně retestů bylo potřeba, než se chyby celého kroku úplně eliminovaly; barevné vyznačení je čistě vizuální). Na konci byly všechny záznamy všech kroků zcela opraveny. Je vidět, že nejvíce chyb bylo odhaleno a zároveň největší problém s opravami nastal v testu první inkrementální dávky, naopak nejméně problémový byl krok jednotkového ověřování unifikace subjektů, zřejmě kvůli kvalitnějšímu vývojovému testování. Celkově lze tedy říci, že plné testy ukázaly několik věcí. Obtížnost vytváření testovacích dat a pokrytí co největší škály možných testovacích případů. V tomto ohledu bylo zvoleno za testovací sadu stovky záznamů. Při skutečném použití by nyní bylo nutné provádět kontrolu nad plnou množinou subjektů, kde by mohlo dojít k objevení dalších nepokrytých případů. 1

Chybovost p získáme vydělením P/100.

7.4. VÝSLEDKY TESTŮ

79

Obrázek 7.3: Vizualizace výsledku testů a rychlosti opravy nalezených chyb.

Testy také ukázaly význam ověřování funkcionality již při vývoji. Sice první spuštění plného testovacího plánu odhalilo řadu nesrovnalostí, nicméně v takové komplexitě, jako je obsažena v komponentě DQTool, nešlo o tak zásadní čísla.

Dále se ukázala nutnost testy vůbec provádět a provádět je v dostatečném rozsahu. Již výše bylo uvedeno, že testy zabraly polovinu času věnovaného implementaci samotné. Stejně tak je nutné ověřovat software jednotkově i integrovaně a věnovat dostatečný čas přípravě testovacích dat i referenčních výstupů.

Na základě výsledků se vždy podařilo eliminovat chybné záznamy na nulu. V případě dostatku času při realizaci práce by se dalo uvažovat o automatizovaném procesu, nicméně jeho vytvoření a udržování bývá často velice náročné.

80


7.5 7.5.1

Testování výkonnosti Problémy

Ověřování výkonnosti s sebou přináší několik zásadních problémů. Jednak nemáme s čím výkonnost porovnávat – v reálném prostředí zákazník definuje časová okna pro zpracování, podepisují se SLA smlouvy apod. Potom je možné systém označit za dostatečně/nedostatečně výkonný a případně příslušně optimalizovat. Stejně tak se potýkáme s problémem malého množství testovacích dat, což způsobuje zkreslování jakýchkoliv měření. Určitě například neplatí lineární závislost mezi množstvím dat a potřebným výpočetním časem – provádějí se operace join nad tabulkami, navíc při větším množství dat už není možné provádět výpočty v paměti, ale je nutné odkládat na disk. Poslední překážkou měření výkonnosti je dostupná konfigurace hardware. Notebook, na kterém byl prováděn vývoj, se ani vzdáleně neblíží cílovým konfiguracím běhu takového řešení. Jenomže testy by měly probíhat na strojích co nejpodobnějších finálnímu nasazení. Na jedné konfiguraci totiž může být úzkým hrdlem databáze, jinde výkon aplikačního serveru, jinde zase sběrnice a komunikace, někde rychlost diskových polí při ukládání a čtení dat apod. Z těchto důvodů nemělo smysl provádět „absolutní“ výkonnostní testování, protože konkrétní čísla jsou zcela irelevantní. Stejně tak nebyla hledána úzká hrdla (na jiné konfiguraci, třeba se zapnutou paralelizací v databázi, mohou být identifikována jinde). Bylo provedeno porovnání tří variant. Kvůli inicializaci a naplnění databáze byly rozdíly variant vytvořeny až na úrovní prvního inkrementu dat.

7.5.2

Porovnání variant načtení inkrementálních dávek

Nebude podrobněji rozebrán proces vytvoření testovacích dat, všechny potřebné soubory se nacházejí na přiloženém CD v MDC projektu. Data lze získat zavoláním plánů make_address, make_subject a make_data (v tomto pořadí) v adresáři tests/performance. Výstup modifikuje standardní testovací data (pomocí různých anonymizací, změn identifikátorů apod.) a vytvoří inkrementální soubory. Testovací plány jsou ve stejné složce, jako plány pro vytvoření dat; použitá testovací data označená písmeny A, B a C se nalézají v adresáři s ostatními testovacími daty v podsložce performance. Ověření každé ze tří porovnávaných variant vyžaduje prázdnou databázi a provedení inicializačního plánu. K vyhodnocení byly použity logy programu MDC. • Varianta A – Inkrement nahrává zcela nová data. • Varianta B – Inkrement nahrává již nahrané subjekty, navázané entity dotahuje z databáze. • Varianta C – Inkrement nahrává již nahraná data. Porovnáním variant v poměrech jejich časové náročnosti (vždy průměrováno větší množství běhů stejné varianty) jsme došli k následujícím výsledkům – dle očekávání je časově

7.5. TESTOVÁNÍ VÝKONNOSTI

81

nejméně náročná dávka, kde se dotahují navázané entity z databáze, není totiž nutné je čistit a ukládat. Toto zrychlení se pohybuje v řádu poloviny až třetiny času. Naopak varianty A a C již nejsou natolik odlišné, jejich časový rozdíl se pohybuje mezi 15 a 25 procenty ve prospěch (nikoliv překvapivě) běhu C. Můžeme zkusit odhadnout, že unifikace na relativně malých vzorcích dat je méně náročným procesem než čištění a standardizace. Protože jsme však nemohli řešení otestovat na velkých datových souborech (neměli jsme žádné takové k dispozici), nelze tento závěr považovat za obecný. Dá se totiž očekávat, že složitost párování nebude stoupat lineárně vzhledem k velikosti vstupu, zatímco čištění a standardizace ano2 .

7.5.3

Zlepšení výkonnosti

Existuje několik možností, jak zlepšovat výkonnost řešení. Určitě lze zavést paralelizaci, zde jsme ovšem zcela závislí na schopnostech zvolených nástrojů (tedy MDC a databáze). Dále je možné zvýšit výkon hardware, v reálném prostředí se používají i stroje s pamětí 100GB RAM, desítkami procesorových jader apod. Posledními dvěma možnostmi jsou vylepšení v realizovaném softwaru – optimalizace algoritmů v implementaci v MDC plánech (toto řešení je ovšem diskutabilní, je otázka, jak moc se plány skutečně optimalizovat dají, aby si zachovaly svou plnou funkcionalitu) a využití výkonnostních mechanismů databáze, jako jsou indexy, hints a další.

2

Unifikace porovnává proti sobě záznamy téměř každý s každým, zatímco čištění 100 záznamů bude vždy desetinásobně rychlejší než čištění 1000 řádků

82


Kapitola 8

Závěr Práce se věnuje zajištění datové kvality v Master Data Mangement hubu pro podporu underwritingu klientů v bankovním sektoru. Text je v souladu s cíli práce rozdělen do dvou částí. První z nich, teoretická, se soustřeďuje na představení důležitých pojmů a problematiky, na které navazuje přehled používaných postupů pro práci s datovou kvalitou v Master Data Mangement hubu. Praktická část začíná analýzou specifických požadavků pro underwriting a jejich formulací v případech užití. Na analýzu navazuje návrh architektury s použitím standardizovaných modelovacích jazyků (v případě, že pomocí nich nebylo možné vizuálně vyjádřit některé souvislosti, byly použity i vlastní notace diagramů). Podle tohoto návrhu bylo řešení implementováno a patřičně otestováno, a to jak jednotkově, tak integrovaně jako celek. Výstupem praktické části diplomové práce je komponenta DQTool realizovaná v prostředí databáze Oracle a nástroje Master Data Center společnosti Ataccama. Stará se o zajištění potřebné kvality záznamů uložených v Master Data Management hubu. Komponentu lze libovolně integrovat, jedinou podmínkou je dodržení nadefinovaného rozhraní. Lze ji součaně adaptovat pro rozličné typy vstupů a zdrojů dat. Celý koncept je vytvořen tak, aby byl rozčlenitelný na jednotlivé nahraditelné funkční bloky. Komponenta splňuje všechny určené požadavky – zajišťuje transformaci vstupních dat, jejich vztahů a kvality, aby sloužily jako vhodný podklad pro navazující underwritingové procesy. Zahrnuje v sobě čištění, obohacení a standardizaci dat, dále jejich unifikaci do kandidátských a klientských skupin a také hodnocení datové kvality záznamů. Přínosem práce je jiný pohled na podporu underwritingu s využitím Master Data Management hubu a důrazem na datovou kvalitu. Tématika použití tohoto přístupu k řešení úvěrových podvodů je všeobecně málo rozšířená. Pro společnost Adastra, ve které je autor práce zaměstnán, a z jejíž zkušeností často čerpal, je dokonce úplně neprozkoumanou oblastí. Pro underwritingové procesy je pak přínosem, že underwriter dostává do rukou mnohem cennější informace o vztazích mezi klienty, než bylo možné získat z původních dat. Praktický příklad s ukázkou je podrobně popsán v podkapitole 6.3.1.

83

84

KAPITOLA 8. ZÁVĚR

Návrhy na pokračování práce Zdrojem návrhů pro možná pokračování práce je zcela jistě seznam negativního vymezení funkčností v podkapitole 4.3. Nicméně i testování a jiné fáze vývoje odhalily několik aspektů, jejichž realizace by vedla k obohacení a zlepšení stávajícího fungování komponenty DQTool. Fáze testování např. ukázala, že by bylo výhodné vytvořit sofistikovanější systém hodnocení datové kvality záznamů (současný, méně vhodný, je rozebrán v podkapitole 5.2.1). I přes to aktuální verze nebrání nasazení komponenty. Rozsáhlé oblasti se otevírají i v doplňování funkčnosti směrem k internacionalizaci. Pak by komponenta nebyla specializována jen na české prostředí, ale snáze by si poradila i se záznamy ze zahraničí. Stejně tak by bylo možné rozšiřovat sady unifikačních pravidel o čím dál specifičtější případy. V neposlední řadě je možné rozšiřovat čistící a standardizační schopnosti komponenty o nové algoritmy. Např. rozeznávat více druhů identifikačních dokumentů, více druhů kontaktů či zapojit do procesu ověřování a validace hodnot další číselníky.

Literatura [1] UIR-ADR Popis dat struktury 4.2. OKsystems, 2005. [2] J. Arlow and I. Neustadt. UML 2 a unifikovaný proces vývoje aplikací. Computer Press, 2007. [3] J. Barták. UnifyEngine expert. Vzdělávací prezentace společnosti Ataccama. [4] A. Berson and L. Dubov. Master Data Management and Customer Data Integration for a Global Enterprise. The McGraw-Hill Companies, 2007. [5] C. Bussler. B2B Integration: concepts and architecture. Springer, 2003. [6] Dearborn Financial Institute. Introduction to Life Underwriting. Dearborn Trade Publishing, 2001. [7] L. P. English. Improving Data Warehouse and Business Information Quality. Wiley, 1999. [8] T. Friedman and A. Bitterer. Magic Quadrant for Data Quality Tools. Gartner Inc., 2011. [9] D. Holeš. Konsolidace klientů - teorie a praxe. Proceedings of the 13th International Conference on Systems Integration 2005, Prague, Czech Republic, pages 442–449, 2005. [10] M. Overturf and N. Sharma. Data Quality Considerations in Master Data Management Structures. Pitney Bowes, Inc., 2009. [11] M. Špaňo. Unification - Ataccama Wiki. https://intranet.ataccama.com/wyky/index.php?title=Unification, přístupné pouze přihlášeným uživatelům, jinak v Help přímo v aplikaci MDC, aktualizováno 19. 10. 2010. [12] D. B. Paradice and W. L. Fuerst. An MIS Data Quality Methodology Based on Optimal Error Detection. Journal of Information Systems, 5(1):48–67, 1991. [13] T. C. Redman. Data Quality for the Information Age. Artech House Publishers, 1999. [14] M. Tatum. What is underwriting? http://www.wisegeek.com/what-is-underwriting.htm, stav ze 14. 12. 2011.

85

86

LITERATURA

[15] K336 Info o závěrečných pracích. http://info336.felk.cvut.cz, stav ze 2. 12. 2011. [16] How an underwriter interprets different situations. http://www.sailloftrealty.com/html/articles/ how_an_underwriter_interprets_different_situations.htm, stav z 22. 12. 2011. [17] Struktura věty RES pro externí uživatele. http://www.czso.cz/csu/redakce.nsf/i/struktura_vety_res_pro_externi_uzivatele, aktualizace 16. 2. 2012. [18] R. Wolter. Master Data Management (MDM) Hub Architecture. http://msdn.microsoft.com/en-us/library/bb410798.aspx, duben 2007.

Příloha A

Seznam použitých zkratek B2B Business To Business BPMN Business Process Model and Notation CD Compact Disc CSV Comma Separated Values ČR Česká republika DB Databáze DQ Data Quality DRY Don’t Repeat Yourself ETL Extract – Transform – Load FIP Functions of Information Processing GB Gigabyte GUI Graphical User Interface ICAO International Civil Aviation Organization IČ Identifikační číslo ISA „Is a“ Hierarchy ISO International Organization for Standardization IT Information Technology MDC Master Data Center MDM Master Data Management OS Operating System

87

88

PŘÍLOHA A. SEZNAM POUŽITÝCH ZKRATEK

PDF Portable Document Format PL/SQL Procedural Language/Structured Query Language PoC Proof of Concept PSČ Poštovní směrovací číslo RAM Random Access Memory RES Registr ekonomických subjektů REST Representational State Transfer SLA Service Level Agreement SOA Service Oriented Architecture SOAP Simple Object Access Protocol SQL Structured Query Language UC Use Case UIR-ADR Územně identifikační registr adres UTF Universal Character Set Transformation Format UML Unified Modeling Language URL Uniform Resource Locator WSDL Web Service Definition Language XML EXtensible Markup Language XSD XML Schema Definition

Příloha B

Důležité definice a pojmy Business To Business, B2B Přímá výměna informací mezi společnostmi bez prostředníka. Definice viz [5], strana 3. Data Quality Findings Jedná se o případ, kdy byl v procesu kontroly a zpracování záznamu z hlediska datové kvality nalezen problém větší závažnosti, který vyžaduje manuální zásah či zvážení. Českým ekvivalentem je „nález datové kvality“. Definice byla vytvořena pro účely diplomové práce. Datová kvalita, DQ Použijeme následující definici datové kvality: data X mají vyšší, lepší, datovou kvalitu než data Y, pokud data X lépe odpovídají potřebám zákazníka. Viz [13], strany 19 a 20. Master data Master data definujeme jako data, která byla vyčištěna, standardizována a integrována do systému záznamů pro business aktivity společnosti. Viz [4], strana 8. Master Data Center, MDC Program společnosti Ataccama pro komplexní správu datové kvality. Umožňuje vyhodnocovat, monitorovat a spravovat kvalitu dat v různých informačních systémech a hlavně hlídat nesprávná data před vstupem do systému. Přebráno z nápovědy programu MDC, verze 7. Master Data Management, MDM Master Data Management je framework sestávající z procesů a technologií zaměřených na vytvoření a provozování autoritativního, spolehlivého, stálého, přesného a bezpečného prostředí pro reprezentaci dat, která je považována za „ jedinou pravdu“. Je to tedy systém záznamů používaný uvnitř podniku i vně něj celou škálou systémů, business aplikací a uživatelských komunit. Viz [4], strana 11. Master Data Management hub Jedná se o databázi a software pro správu master dat uložených v této databázi. Pomáhá je synchronizovat s transakčními systémy, které Master Data Management hub používají. Definice viz [18].

89

90

PŘÍLOHA B. DŮLEŽITÉ DEFINICE A POJMY

Metadata Data sloužící k popisu či specifikaci ostatních dat. Jde o všechny charakteristiky, které je nutné znát o datech, aby bylo možné vytvářet databáze a nad nimi funkční aplikace. Definice viz [7], strana 482. Nález datové kvality Viz Data Quality Findings. Underwriting Underwriting je metoda používaná k vyhodnocení aktuální způsobilosti zákazníka získat určitý finanční produkt. Takto byl pojem underwriting definován v podkapitole 2.1. Unifikace Unifikace je proces, ve kterém se identifikují skupiny záznamů, které patří do jedné logické entity, kam jsou přiřazeny na základě určených pravidel. Proces seskupování je rozdělen na dvě části – rozdělení záznamů do širších, kandidátských, skupin a poté zúžení do výsledných matchingových či klientských podskupin. Definice byla přebrána z elektronického manuálu programu MDC (viz Master Data Center) společnosti Ataccama [11].

Příloha C

Scénáře k případům užití V této příloze se nacházejí scénáře k případům užití definovaným v analýze 4.2. UC I03 – Vypočítat definované abnormality, popis viz tabulka 4.6 Vstup Vyčištěný, standardizovaný záznam s ostatními záznamy ze skupiny a s navázanými entitami. Krok Scénář Odkaz 01 Na záznamu či klientské skupině se spočítají charakteristiky pro definované abnormality. Definované charakteristiky: 1. Množství různých adres různých typů ve skupině. 2. Množství změn ve stávajících unifikovaných skupinách v dané dávce. 3. Množství různých kontaktů různých typů ve skupině. 4. Množství různých dokladů různých typů ve skupině. 5. Množství změn adres na záznamu v dané dávce. 6. Množství změn kontaktů na záznamu v dané dávce. 7. Množství změn dokladů na záznamu v dané dávce. 8. Množství změn vztahů na záznamu v dané dávce. 02 03

Charakteristiky jsou připojeny k jednotlivým záznamům do speciálních sloupců, původní charakteristiky jsou přepsány. Konec UC

Tabulka C.1: Scénář případu užití „UC I03 – Vypočítat definované abnormality“

91

92

PŘÍLOHA C. SCÉNÁŘE K PŘÍPADŮM UŽITÍ

UC I01 – Vyčistit a standardizovat záznamy, popis viz tabulka 4.4 Vstup Záznam(y) o subjektu s návaznými entitami k vyčištění a standardizaci Krok Scénář Odkaz 01 Atributy subjektu či návazných entit jsou vyčištěny dle postupů určených v návrhu. Hodnoty jsou uloženy do speciálních sloupců. 02 Atributy subjektu či návazných entit jsou standardizovány a obohaceny dle postupů určených v návrhu. Hodnoty se ukládají do speciálních sloupců. 03 Vypočítá se score jednotlivých atributů (score odráží jak vstupní, tak i výstupní datovou kvalitu). Společně se score je přiřazen i vysvětlující kód scoringu. Váha významu atributů je již promítnuta v tomto score. 04 Vypočítá se celkové score entity jako aritmetický průměr score jejích atributů. 05 Konec UC Tabulka C.2: Scénář případu užití „UC I01 – Vyčistit a standardizovat záznamy“

Vstup Krok 01

02

03

04

UC I02 – Unifikovat záznamy, popis viz tabulka 4.5 Záznam(y) o subjektu s návaznými entitami, režim unifikace (ukládání / identifikace). Scénář Odkaz K záznamu se připojí informace z navázaných entit, které k němu náležejí. Navázané entity pak již dále nepodléhají žádným změnám. Je provedena unifikace záznamů či jejich změn k záznamům, které jsou již v databázi. Unifikace nejprve rozdělí záznamy do kandidátských skupin. K unifikaci se použijí vhodná unifikační pravidla, aby bylo možné splnit primární požadavky z kapitoly 2.5. Je provedena unifikace v rámci kandidátských skupin do klientských skupin. K unifikaci se použijí vhodná unifikační pravidla, aby bylo možné splnit primární požadavky z kapitoly 2.5. Konec UC Tabulka C.3: Scénář případu užití „UC I02 – Unifikovat záznamy“

93

UC M01 – Přidat záznamy se zohledněním DQ, popis viz tabulka 4.2 Vstup Záznam(y) a navázaná(é) entita(y) k uložení do databáze. Každý typ entity v samostatné zdrojové dávce. Krok Scénář Odkaz 01 Systém přijme záznam a navázané entity. 02 Alternativní scénář ke kroku 01: Systém přijme dávku více záznamů s navázanými entitami. 03 Nad záznamy i navázanými entitami je zavolán UC I01 – UC I01, viz Vyčistit a standardizovat záznamy. 4.4 a scénář C.2 04 Provede se analýza datové kvality záznamů a entit na základě jejich score. Pokud více řádků než je definovaný práh nedosáhlo definované datové kvality (hodnoty budou určeny v návrhu), je balík entit tohoto typu označen k vyřazení ze zpracování. 05 Chybový scénář: Byly-li záznam či celá dávka označeny k vyřazení ze zpracování, je UC ukončen. 06 Je vytvořen vstupní balík entit do unifikace (z databáze jsou získány k záznamům připojené entity a k entitám případně dozískány jejich rodičovské záznamy). 07 Jsou zalogovány informace o referencovaných záznamech z navázaných entit, které ale v systému neexistují. 08 Nad vstupním balíkem je zavolán UC I02 – Unifikovat zá- UC I02, viz znamy. 4.5 a scénář C.3 09 Jsou zalogovány informace o chybách v unifikaci, které detekuje zvolený nástroj. Např. duplikace primárních klíčů záznamů. 10 Nad záznamy je zavolán UC I03 – Vypočítat definované ab- UC I03, viz normality. 4.6 a scénář C.1 11 Návazné entity i záznamy jsou uloženy do databáze. Režim jejich ukládání je automaticky opraven podle toho, zda již v databázi existují. Změna režimu ukládání je zalogována. 12 Konec UC Tabulka C.4: Scénář případu užití „UC M01 – Přidat záznamy se zohledněním datové kvality“

94

PŘÍLOHA C. SCÉNÁŘE K PŘÍPADŮM UŽITÍ

UC M02 – Identifikovat záznamy se zohledněním DQ, popis viz tabulka 4.3 Vstup Záznam(y) a navázaná(é) entita(y) k uložení do databáze. Každý typ entity v samostatné zdrojové dávce. Krok Scénář Odkaz 01 Systém přijme záznam a navázané entity. 02 Alternativní scénář ke kroku 01: Systém přijme dávku více záznamů s navázanými entitami. 03 Nad záznamy i navázanými entitami je zavolán UC I01 – UC I01, viz Vyčistit a standardizovat záznamy. 4.4 a scénář C.2 04 Provede se analýza datové kvality záznamů a entit na základě jejich score. Pokud více řádků než je definovaný práh nedosáhlo definované datové kvality (hodnoty budou určeny v návrhu), je balík entit tohoto typu označen k vyřazení ze zpracování. 05 Nebyl-li zadán požadavek na identifikaci, pokračuje se shodným krokem, jako chybový scénář v kroku 06. Jinak UC pokračuje krokem 07. 06 Chybový scénář: Záznam nemá dostatečnou datovou kvalitu pro identifikaci a je vrácen pouze jako vyčištěný a zkontrolovaný. 07 Nad vstupním balíkem je zavolán UC I02 – Unifikovat zá- UC I02, viz znamy. 4.5 a scénář C.3 08 Jsou zalogovány informace o chybách v unifikaci, které detekuje zvolený nástroj. Např. duplikace primárních klíčů identifikovaných záznamů. 09 Nad záznamy je zavolán UC I03 – Vypočítat definované ab- UC I03, viz normality. 4.6 a scénář C.1 10 Jsou navráceny výsledky kontroly a identifikace na záznamech i navázaných entitách. Jsou navráceny i záznamy (bez navázaných entit), které jsou součástí identifikovaných párovacích skupin. 11 Konec UC Tabulka C.5: Scénář případu užití „UC M02 – Identifikovat záznamy se zohledněním datové kvality“

Příloha D

Instalace řešení Popis instalace řešení se bude věnovat nejjednoduššímu způsobu nasazení, a tím je spuštění přímo přes program Master Data Center. Pokud by bylo nasazení prováděno do skutečného Master Data Management hubu, probíhalo by o něco složitěji. Integrace s ostatními komponentami by si vyžádala využití společných konfiguračních souborů a také centrální správu spouštění plánů a publikování on-line rozhraní. I přesto by byla tato příručka dostatečným zdrojem informací.

D.1

Potřebné nástroje

Prvním krokem instalace je zprovoznění všech potřebných nástrojů. Jejich přehled i s použitými verzemi byl představen v návrhu v sekci 5.5. Předpokládáme tedy, že jako prerekvizita instalace jsou tyto nástroje na cílovém stroji k dispozici a funkční1 . Současně se předpokládá nakopírovaný projekt z MDC workspace na přiloženém CD do workspace MDC na cílovém stroji a založená prázdná databáze s právy pro read-write přístup. Do adresářové struktury na patřičná místa také musejí být jako poslední prerekvizita dodány všechny zdrojové soubory číselníků. Postup, jak je získat, je podrobněji popsán v příloze E.

D.2

Konfigurace MDC a databáze

Nastavení proměnných prostředí Pro funkčnost řešení diplomové práce je nutné v programu MDC nastavit dva typy proměnných prostředí. Místo, kde se nastavují, a jaké jsou vlastně potřeba, je ukázáno na obrázku D.1. 1 Pro URL ke stažení potřebných řešení odkazujeme na vyhledávač Google, program Master Data Center je k dispozici k zakoupení na stránkách společnosti Ataccama, viz http://www.ataccama.com/en/products/ mdc.html

95

96

PŘÍLOHA D. INSTALACE ŘEŠENÍ

Obrázek D.1: Nastavení databázových spojení a cest k adresářům v MDC.

Databázová spojení musí směřovat na databáze typu Oracle a spojení se shodným prefixem v názvu musí směřovat do stejného schématu. Je možné provozovat řešení na více schématech či dokonce databázích, typicky např. oddělit tabulky repository (stejnojmenné DB spojení) od ostatního úložiště. Cesty k adresářům se nastavují takto: • DATA_SOURCE - Cesta ke zdrojovým souborům pro nahrávání „ jakoby přes B2B“. Odtud se budou při loadování dávek brát CSV soubory s daty. • TEST_DATA_OUT - Výstup testovacích plánů, pro projekt přiložený na CD se bude jednat o adresář tests/data_out ve workspace projektu. • TEST_DATA_SOURCE - Cesta ke zdrojovým souborům pro testy vč. výkonnostních. Pro projekt přiložený na CD se bude jednat o adresář tests/data_sources ve workspace projektu. • TRASH - Cesta k odkladišti dočasných a debugovacích výstupů. Pro nasazení řešení bez debugování či vývoje není nutné nastavovat. Databáze Protože s komponentou DQTool jsou součástí diplomové práce i databázové objekty (balíčky neboli packages, tabulky, triggery apod.), musí dojít k jejich vytvoření. Samozřejmě při zakomponování komponenty do většího projektu je možné pomocí procedur odstínit SQL dotazy od skutečné struktury tabulek. Je nutné provést skripty v adresáři sql ve workspace projektu v tomto pořadí (skript clean_all_tables.sql je pouze servisní):

D.3. SPUŠTĚNÍ V MDC

97

1. log_tables_ddl.sql založí tabulky pro logování. 2. log_package_ddl.sql založí přístupovou package pro logovací operace. 3. mdm_tables_ddl.sql založí tabulky pro ukládání entit MDM hubu. 4. mdm_etalons_ddl.sql založí tabulky pro uložení etalonů. 5. mdm_package_ddl.sql založí přístupovou package pro management entit. Etalony Posledním krokem nastavení prostředí je vytvoření binárních verzí číselníků z jejich zdrojových souborů. Číselníky, etalony, jsou vygenerovány pomocí spuštění příslušných MDC plánů, které se postarají o založení binárních .lkp souborů ve správném cílovém adresáři a také o případný zápis hodnot do databáze. Postup spuštění plánu přímo z nástroje MDC byl ukázán v kapitole o testování na začátku popisu testovacího plánu na obrázku 7.1. Plány se musí provést v tomto pořadí (hvězdička značí více možných plánů se stejným začátkem názvu, mezi nimi nezáleží na pořadí): 1. common_etalons.plan vytvoří obecné číselníky pro řešení diplomové práce (př. kódy zdrojových systémů). 2. subject_*.plan vytvoří číselníky pro čištění subjektů (př. akademické tituly). 3. address_etalons.plan vytvoří číselníky pro čištění adres (př. poštovní směrovací čísla). 4. contact_etalons.plan vytvoří číselníky pro čištění kontaktů (př. mezinárodní předvolby telefonních čísel). 5. document_etalons.plan vytvoří číselníky pro čištění identifikačních dokumentů (př. seznam rozpoznávaných dokumentů systémem). 6. sub2sub_etalons.plan vytvoří číselníky pro čištění vztahů mezi subjekty (př. seznam možných vztahů). 7. cze_business_register.plan vytvoří binární struktury pro číselník Registr ekonomických subjektů ČR. 8. uiradr_*.plan a poté uiradr2_*.plan vytvoří všechny potřebné struktury pro číselníky na základě Územně identifikačního registru adres.

D.3

Spuštění v MDC

Pokud by řešení bylo spouštěno v širším kontextu skutečného MDM hubu, pak by údaje z této podkapitoly nebyly relevantní a řešily by se v komplexním kontextu. Pro minimální spuštění přímo v programu MDC je nicméně nutné zdůraznit následující aspekty.

98

PŘÍLOHA D. INSTALACE ŘEŠENÍ

Spouštění plánů Pro načtení dávek „ jakoby z B2B“ se spouští plán b2b_reader.plan z adresáře plans ve workspace projektu. Přes MDC je nutné ruční spuštění (viz obrázek 7.1), v reálném projektu by samozřejmě byly k dispozici příslušné časovače. Tento plán načte dávky záznamů ze složky se vstupními daty (určena proměnnou prostředí viz výše). Načítají se soubory address.csv, contact.csv, document.csv, sub2sub.csv a subject.csv. Jejich strukturu a parametry lze nalézt v testovacích datech pro iniciální dávku. Vystavení on-line rozhraní Pro zprovoznění přístupu přes webové služby je nutné v programu MDC spustit server, který bude naslouchat příchozím requestům. Pro tento účel musí být v MDC otevřen soubor ws_reader.online z adresáře plans ve workspace projektu. V editačním okně se pak použije tlačítko nahoře, viz obrázek D.2.

Obrázek D.2: Spuštění standalone serveru v MDC pro vystavení on-line služby.

Nastartovaná služba dostupná na endpointu http://<server>:<port>/dqtool, WSDL pak na http://<server>:<port>/console/applications/ws_reader.online/services/ dqtool/wsdl, kde výchozí hodnoty jsou localhost pro server a 8888 pro port. Nyní považujeme řešení za nainstalované a běžící.

Příloha E

Externí číselníky Příloha pojednává o získání externích číselníků, jejichž zdroje nejsou součástí odevzdání diplomové práce, protože se jedná o komerční produkt, případně spadají pod vlastnictví soukromé společnosti.

E.1

Registr adres UIR-ADR

Registr adres UIR-ADR je v práci použit k ověřování a standardizaci adres na území České republiky. Je poskytován Ministerstvem práce a sociálních věcí ČR. Je dostupný pro vyhledávání on-line na internetu, případně za úplatu jako soubory na CD. Struktura dostupných tabulek je podrobně popsána v oficiálním přehledu [1]. Obsah se nahraje do připravené složky etalons/sources/cze_addr_ai/uir-adr. Očekávají se soubory s příponou .txt, v nichž budou jednotlivé struktury v CSV formátu, kódování je očekáváno windows-1250. Protože program MDC poskytuje přímou podporu pro převedení zdrojových souborů registru do .lkp formátu (komponenta UIR ADR Generator ), stačí zavolat dva předpřipravené plány. Toto volání je však součástí instalačního postupu z předchozí přílohy.

E.2

Registr ekonomických subjektů RES

Registr ekonomických subjektů RES je použit k ověření identifikačních čísel a názvů společností a také k dohledání dalších informací o právnických osobách a fyzických osobách – podnikatelích. Registr je podobně jako u adres volně dostupný na internetu k vyhledávání, nicméně jeho kompletní verze v souboru je poskytována Českým statistickým úřadem za úplatu. Součástí dodávky je jeden hlavní soubor s daty, který je třeba nahrát do předpřipraveného adresáře etalons/sources/cze_business_register pod názvem cze_business_register.txt, což je ve skutečnosti CSV soubor v UNIX formátu s kódováním UTF-8, oddělovačem středník a se sloupečky definovanými v [17]. Binární soubory jsou opět vygenerovány připraveným MDC plánem. Tento proces je součástí instalace popsané v příloze D.

99

100

PŘÍLOHA E. EXTERNÍ ČÍSELNÍKY

E.3

Číselníky pro jména a příjmení

V práci byly při vývoji použity vypůjčené číselníky společnosti Ataccama, jejichž zdrojem jsou nejspíše seznamy dostupné na stránkách Ministerstva vnitra České republiky. Protože však jsou dané soubory vlastnictvím společnosti, nelze je dodávat společně s diplomovou prací na přiloženém CD. Popíšeme tedy postup, jak tyto seznamy umístit do správných zdrojových souborů. Data pro ně viz stránky Ministerstva vnitra či jiné zdroje (viz analýza, podkapitola 4.4). Do složky etalons/sources/subject_name je nutné umístit šest souborů CSV (s příponou .txt). Specifikace formátu obsahu je viditelná z obrázku E.1, který je snímkem informačního dialogu o souboru z programu MDC pro seznam jmen možných pro obě pohlaví. Pro soubory se záznamy jen pro mužská či ženská odpadá vždy jeden sloupec s četností (ten pro nepoužité pohlaví). Sloupec Single_Multi pomocí písmen M a S určuje, zda je jméno myšleno jako víceslovné. Sloupec gender je vyplněn buď dle obrázku, nebo pro jednoznačně určené pohlaví jména písmeny M a F. Názvy a popis zdrojů se nachází v tabulce E.1.

Obrázek E.1: CSV soubory pro jména subjektů.

Následné zpracování plánem je již součástí instalace, viz předchozí příloha.

E.4. OSTATNÍ ČÍSELNÍKY

Jméno souboru first_names_F.txt first_names_M.txt first_names_X.txt last_names_F.txt last_names_M.txt last_names_X.txt

101

Obsah Ženská křestní jména Mužská křestní jména Křestní jména použitelná pro obě pohlaví (např. Jindra) Ženská příjmení Mužská příjmení Příjmení použitelná pro obě pohlaví

Tabulka E.1: Přehled CSV souborů pro jména subjektů, ta mohou být i víceslovná.

E.4

Ostatní číselníky

Ostatní číselníky mají jako standardní součást diplomové práce i svoje zdrojové soubory. Jejich doplnění či editace znamená pouze zásahy do stávajících CSV souborů. K některým lze využít znalostní databáze uvedené v analýze, jiné jsou specifické pro daný projekt a lze je editovat téměř libovolně při dodržení správně struktury.

102

PŘÍLOHA E. EXTERNÍ ČÍSELNÍKY

Příloha F

Obsah přiloženého CD Obsah CD, které je přiloženo k diplomové práci, je popsán v tabulce F.1. Jméno ea_docs project_workspace

thesis_final thesis_tex_source

Popis adresář s analytickou a návrhovou dokumentací k projektu v souboru pro Enterprise Architect adresář, který představuje workspace projektu (zmiňován v textu práce), jde o root složku, již je možné naimportovat do programu MDC jako kompletní projekt adresář s finálním textem diplomové práce v PDF formátu adresář se zdrojovými soubory textu práce (formát LATEX) a samostatnými obrázky

Tabulka F.1: Obsah přiloženého CD Dokumentace k MDC plánům či testům je součástí plánů samotných, případně je popsána v textu v příslušných kapitolách (návrh 5 a testy 7).

103

Oficiální zadání práce

Recommend Documents