Konsolidace několika databází klientů do jednoho úložiště

Transkript

1 České vysoké učení technické v Praze Fakulta elektrotechnická ČVUT FEL katedra počítačů Diplomová práce Konsolidace několika databází klientů do jednoho úložiště Martin Novák Vedoucí práce: Mgr. Martin Pavlík Studijní program: Elektrotechnika a informatika magisterský Obor: Informatika a výpočetní technika Květen

2 2

3 Poděkování Rád bych poděkoval mému vedoucímu práce Mgr. Martinu Pavlíkovi za vedení při tvorbě této práce, dále také za jeho cenné rady a postřehy a také za výběr velmi zajímavého tématu. 3

4 Prohlášení Prohlašuji, že jsem svou diplomovou 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 dne

5 Anotace Cílem této práce bylo vytvořit proces, který bude konsolidovat klientská data ze zdrojového úložiště do cílového úložiště. Integrace dat spočívá v transformaci struktur ze dvou úložišť do jednoho a čištění dat samotných. Dále byly vytvořeny dvě ukázkové aplikace, které používají stávající klientská úložiště dat, zároveň byly také integrovány s novým úložištěm a také využívají real-time procesů pro čištění, úpravu a integraci dat. Annotation The main purpose of this work was to create a process that integrates client data from new data sources to new consolidated data source. The data integration means to transform data structures from two data sources to one and to clean the data. Two sample applications that use the old client data source were created and later they were modified to use a real-time version of the transformation proces for cleansing, modifying and integration of data. 5

6 6

7 Obsah Úvod, motivace a cíle 11 Integrace dat 12 Jednotné místo uložení konsolidovaných dat 12 Jednotný bod správy a přístupu ke konsolidovaným datům 13 Konzistentní reprezentace dat 13 Konzistentní a validní data 14 Analýza problému 15 Zdrojová data 15 Formát zdrojových dat a jejich kontext 15 Data z databáze 15 XML 16 Zpracování Xml souborů 17 Textové soubory 18 Aplikace dodávající data 18 Úložistě mezivýsledků 19 Výsledná data 19 Stávající aplikace 19 Popis jednotlivých kroků 20 Naplánování projektu a definování cílů, kterých chceme dosáhnout 20 Analýza dat a jejich struktury 20 Modelování ETL procesu 20 Příprava stávajících aplikací a systémů na přechod k novému úložišti 20 Provedení konsolidace dat a přechod stávajících systémů k novému úložišti 21 Příprava projektu 22 Co integrovat 22 Rozhodnutí o správě a zodpovědnosti za data a systémy 22 Kroky po skončení transformace dat 22 Analýza dat a jejich struktury 23 Vznik chyb 23 Datová kvalita a čištění dat 23 Typické příklady narušení kvality dat 24 Nesprávná data 24 Nejednoznačná data 25 Nekonzistentní data 25 7

8 Neúplná individuální data 26 Neúplné celky 26 Složitější omezení 26 Analýza pro kvalitní data 26 Struktura hodnot dat 26 Znakové sady 27 Modelování procesu konsolidace 28 Návrh procesu 28 Načtení dat ze zdroje 29 Standardizace a odstranění duplicit 29 Transformace 29 Načtení dat do cílové databáze 29 Komponenty 30 Metadata 30 Příprava stávajích systémů 31 Middleware 31 Message Oriented Middleware 32 SOAP 32 JMS 32 Komunikace aplikací s real-time transformačním systémem 33 Komunikace s transformačním systémem 33 Komunikace přímo s novým úložištěm 33 Komunikace s novým úložištěm přes transformační systém 34 Komunikace přes middleware 34 Vytvoření mezivrstvy mezi existujícími aplikacemi a novým úložištěm 35 Spolupráce starého úložiště s novým 36 Když nemáme kód stávající aplikace 36 Online detekce 36 Offline detekce 37 Provedení konsolidace dat a přechod na nové aplikace 39 IBM Information Server 40 Architektura Information Serveru 40 Metadata 41 Návrh ETL procesu v Information Serveru 41 Komponenty 41 Kategorie Database 43 8

9 Kategorie File 43 Data Set 43 Sequential File 44 Kategorie Data Quality 44 Investigate 44 Standardize 44 Frequency analyzer 45 Unduplicate Match 45 Survive 45 Definice a testování specifikace pro porovnávání duplicit 46 Kategorie Processing 47 Transformer 47 Lookup 49 Sort 49 Funnel 50 Remove Duplicates 50 Copy 50 Kategorie Real-time 50 Real-time zpracování 50 Implementace konsolidace databází v IBM IS 52 Zdrojová data 52 Struktura zdrojové databáze hypoték 52 Cílová struktura úložiště 53 Problémy s daty 54 ETL proces 54 Nahrání dat z databáze do úložiště IIS 55 Standardizace 58 Frekvenční analýza dat 60 Odstranění duplicit 60 Nahrání dat do cílové databáze 61 Aktualizace odkazů ve zdrojových úložištích 62 Aplikace 64 Aplikace pro správu hypoték 64 Systémové požadavky, instalace a spuštění aplikace 66 Aplikace pro správu klientských účtů banky 66 Systémové požadavky, instalace a spuštění aplikace 68 Aplikace prohlížení a základní manipulaci s novým úložištěm 68 9

10 Úprava aplikací pro použití s Information Serverem 70 Implementace real-time transformace 71 Závěr 74 Slovníček pojmů 75 Seznam literatury a odkazů 76 Obsah přiloženého CD 77 10

11 Úvod, motivace a cíle Data jsou nedílnou součástí dnešní moderní informační společnosti. V dnešním světě si to ani nedokážeme představit jinak. Data nás obklopují, spoluvytvářejí naše rozhodování, umožňují nám pochopit okolí a spoustu věcí z něj. Dat, která nás obklopují je mnoho a velmi snadno nás mohou zahltit. A přiznejme si, že tomu tak velmi často je. Bez kvalitních a strukturovaných dat se prostě neobejdeme. Proto je potřeba dát datům jednotnou formu tak, aby byla uspořádaná, aby se nad nimi daly snadno vykonávat různé operace a také, aby byla bezpečně uložená. K tomuto úkolu nám pomáhají databáze, které jsou základním prostředkem dnešní doby na uchovávání dat. Databáze jsou, z pohledu informatiky, na světě celou věčnost. Taktéž systémy postavené na databázích a data v nich obsažená jsou bývají k dispozici hodně dlouhou dobu. Data do nich bývají v mnoha případech bez ladu a skladu vkládána jak se konkrétním vývojářům líbilo. Ve většině podniků neexistuje a nikdy neexistovala jasná pravidla jak manipulovat s databázemi, neexistoval žádný jednotný systém ať už k vývoji, tak i k vkládání samotných dat do databáze. Celé systémy i s daty procházely v průběhu času evolucí a to takovou, že dnes již často nevíme, jestli jsou data, která máme k dispozici správná. Často o datech ani nemáme žádný velký přehled. Bývá problémem zjistit v které databázi jsou jaké informace, víme toho velmi málo o struktuře databází samotných. Zaměstnanci, kteří tyto systémy navrhovali bývají již nenávratně pryč. Postupné změny sloupečků tabulek podle aktuálních potřeb, přidávání sloupečků ruší celistvost dat a způsobuje další problémy. Nezkušenost návrhářů, kteří databáze navrhovali a časem modifikovali, přináší chaos nejen do dat, ale i do vývoje samotných aplikací nad nimi stavěnými. Postupem času se ztrácí a zamlžuje význam jednotlivých tabulek, specifikace a dokumentace k nim jsou velmi vágní. Jelikož jsou ale databáze základní a nedílnou součástí podnikových informačních systémů, tak zde nastává docela podstatný problém. Nevíme-li, jestli jsou naše data správná a nebo nevyznáme-li se v našich datech, tak jak můžeme takovým datům věřit? Tyto problémy mohou docela snadno ochromit chod podniku. Pokud jste pracovali v nějaké větší firmě, tak jste se určitě setkali s tím, že jste nemohli najít určité informace. Ne proto, že by tyto informace v databázích nebyly, ale proto, že tyto informace byly někde, neznámo kde, uloženy a vy jste se k nim prostě nemohli nikterak dostat. Vezměme si jako příklad firmu s dlouho budovaným informačním systémem. Vezměme si jako příklad, že chceme poslat fakturu firmě IBM. Pokud nebudeme mít jasně daná pravidla jak firmy do databáze vkládat, tak se nám může lehce stát, že firmu IBM přehlédneme. IBM se totiž může psát jako International Business Machines nebo také jako I.B.M nebo prostě IBM. V takovém případě jste ztraceni. Záznam může být v jiném formátu, než jsme zrovna vložili do vyhledávání. Nebo se může stát, že záznam o IBM může být v databázi pod dvěma různými názvy. Pokud jako uživatelé záznam nenajdeme, tak budeme mít vždy tendenci jej do databáz přidat, čímž v lepším případě vznikne jen duplicita, tedy situace, kdy jedem objekt reálného světa existuje ve dvou záznamech v databázi. Vezměme si další příklad z našeho podniku a to dvě databáze dvou informačních systémů - jedna v logistice a druhá v účtárně. Obě databáze o sobě vůbec neví a jsou na sobě úplně 11

12 nezávislé. Obě databáze také obsahují záznamy o IBM, ale každá v jiném formátu. Pokud nebudou záznamy o IBM sedět, tak podnik může mít problémy s fakturami. Je tedy žádoucí, aby se informační systémy spolu uměly domluvit nebo ještě lépe by bylo, kdyby oba informační systémy používaly některá data ze společné databáze. Je vidět, že problém se jen komplikuje. Špatně poslané faktury by se ještě daly spravit, ale další, ještě výraznější problémy mohou nastat, jestliže z takovýchto špatných dat vzejdou špatná rozhodnutí, která ovlivní chod firmy. Toto pak komplikuje chod podniku a jeho situaci na trhu. Je vidět, že kvalita dat a jejich správná provázanost je klíčová pro každý podnik. Nebudeme-li mít svoje správné informace, tak v dnešním světě máme velkou nevýhodu. Proto je dobré mít jasnou strategii pro správu dat a pokud ji, je potřeba na ní v co nejbližší době začít pracovat a začít data integrovat. Cílem této diplomové práce je proto postavit jednoduchý základ, na kterém by mohla stát implementace procesů integrování dat, popsat co by tento proces měl dělat, čeho by měl dosáhnout a jakým způsobem, dále si rozmyslet, jak by měly vypadat nástroje, které chceme používat. Jako další cíl je postavit ukázku toho jakou cestou by se měla samotná implementace vydat, tj. vytvořit dvě ukázkové aplikace se separátními datovými úložišti a implementovat proces konsolidace v technologiích IBM. Integrace dat Integrací dat se rozumí proces, ve kterém se budeme snažit sjednotit data z různých zdrojů. Tento proces bude poměrně náročný, protože data nikdy nebudou v pořádku a můžeme se při jejich zpracování dočkat různých překvapení, která ani sami nebudeme čekat a to nejen ve špatných datech, ale také v nepochopení jejich významu a špatné interpretaci. Před zanořením se do detailů celého procesu by bylo vhodné si stanovit cíle a požadavky na nově vytvořené úložiště. jednotné místo uložení konsolidovaných dat jednotný bod správy a přístupu ke konsolidovaným datům konzistentní reprezentace dat konzistentní a validní data Celý systém procesu integrace, který navrhneme, by měl splňovat několik dalších požadavků. Následuje jejich výčet. opakovatelný proces, který je do maximální míry automatizován systém pro opravu chyb, které nelze strojově napravit minimální narušení chodu stávajících systémů Jednotné místo uložení konsolidovaných dat Mezi největší přednosti nového systému patří unifikace fyzických dat do jednoho zdroje. Umožní nám to jednak snížit náklady na správu všech systémů tím, že budeme mít data pod 12

13 jednotnou centrální správou. Dále se zvýší přehlednost, protože budeme vědět, kde jsou data fyzicky uložena. Podstatné je také to, že se tím sníží počet nasazených softwarových architektur - databází. Díky tomu je možno se soustředit vývoj pouze na určité klíčové prostředí a díky tomu snížit složitost aplikací, integračních celků a také zvýšit odbornost pracovníků vývojových a IT oddělení organizací soustředěním pouze na určité technologie. Další výhodou může být i menší nutný počet licencí na například databázové servery, což také uspoří nemalé peníze. Centrální správa ale neznamená jen konsolidaci softwaru pro správu dat, ale také konsolidaci hardwaru. Méně systémů uspoří náklady vydané za hardware a také je pro organizace snazší vybrat server na platformě, kterou používají a je pro ně nejvýhodnější z hlediska cena-výkon. Jednotný bod správy a přístupu ke konsolidovaným datům Unifikace uložení dat se dále rozšiřuje na unifikaci přístupu k těmto datům. Všechny systémy musí umět přistupovat k novému úložišti. To samozřejmě vyžaduje buď jisté úpravy stávajících aplikací nebo vytvoření mezivrstev pro komunikaci. Z umístění klíčových dat na jednom místě plynou zřejmé výhody. Díky tomu, že data budou na jednom místě, tak se tyto data budou moci používat ve více aplikacích a ve více informačních systémech. Vezměme si jako příklad jednotnou databázi zákazníků v podniku, v našem případě třeba klienty v bance. Tato jednotná databáze pomůže rozhodovat se efektivněji. Banka bude moci například vidět, že záznamy jednoho klienta jsou ve více systémech současně. Díky této informaci se bude moci prohlédnout jeho platební neschopnost a dále se bude možno lépe rozhodnout při poskytování dalších úvěrů. Pokud by neexistovalo jednotné klientské úložiště používané všemi databázemi a všemi informačními systémy, pak by mohl být problém dotyčného klienta dohledat v jiném systému a banka by mu nemohla nabídnout další příslušné produkty ze kterých by profitovala. Konzistentní reprezentace dat Pokud uchováváme data, potřebujeme je mít v konzistentní reprezentaci v celém systému a je nutné tyto reprezentace definovat předem a konzistentně pro celý systém. Pro standardní typy dat je nutné co nejvíce využívat nativních formátů databází. Jako první příklad můžeme uvést datum, které by mělo být uchováno ve formátu určeném pro datum v databázi, tedy jako typ DATE a ne námi formátovaný text. Pro některá data ale nativní formát neexistuje. Jako příklad lze uvést telefonní čísla. Je potřeba využít typ VARCHAR nebo jemu podobný a data udržovat zformátovaná interně. Formát těchto telefonních čísel může být například nastaven na +XXX YYYYYYYYY, kde část s X je předvolba země a Y je telefonní číslo. Takto by se měla ukládat všechna telefonní čísla konzistentně v celém cílovém systému. Další příklad jsou výčtové hodnoty dat, kdy budeme mít například databázi automobilů a budeme sledovat typ motoru - benzínový, dieselový, elektro. Pro tyto typy si musíme jasně definovat jaké hodnoty budou co reprezentovat. Tato rozhodnutí by se měla dělat na úrovni projektu tak, aby se v celé cílové databázi používaly stejné výčtové typy. 13

14 Konzistentní reprezentace dat usnadňuje psaní aplikací, validaci dat a dotazování. Některé datové typy jsou v databázích předem definovány, ale pokud budeme mít jako cílové úložiště XML, tak musíme všechna data formátovat ručně a proto bychom měli se špatně naformátovanými daty problém. V takovém případě musíme být zvláště opatrní. Více o problémech XML v další kapitole. Důležitost jasné reprezentace dat tkví ve správném porozumnění toho, co informace obsahují. Zabraňuje to nejasnostem v interpretaci dat, což vede k úspoře času nejen pro pracovníky, kteří navrhují architekturu systému a její návaznost na reálný svět, ale také pro vývojáře při vývoji aplikací a pro další technické pracovníky zodpovědné za pozdější řešení problémů s daty samotnými. Konzistentní a validní data Konzistence a validita dat je po sjednocení úložiště druhý hlavní cíl procesu integrace dat. Konzistence dat znamená, že data jsou úplná a neobsahují chyby a proto je můžeme s klidným svědomím dále používat při dalším rozhodování a můžeme se na jejich obsah spolehnout. 14

15 Analýza problému Jako příklad systémů, které chceme konsolidovat data klientů byly vybrány jako příklad systémy banky a hypotečního ústavu. Problémy s daty v několika informačních systémech, popsané v předchozí kapitole, jsou ovšem patrné v mnoha dalších podnicích a odvětvích podnicích. Naštěstí se většinou redundance týká entit jako jsou například klient, dodavatel, adresa, a podobně. Pro vyřešení problému vyčištění a zkonsolidování dat do nového úložiště bude potřeba mít sadu nástrojů. Tento transformační systém je možno buď vytvořit v rámci podniku nebo zakoupit již hotové řešení. Zdrojová data Zdrojová data mohou být různého charakteru. Od jednoduché ploché struktury, přes hierarchická data, až po složitější případy dat, která mají strukturu grafu. Od zdrojové struktury dat se odvíjí to, jak budeme dále zpracovávat. Formát zdrojových dat a jejich kontext Data mohou být načítána z mnoha různých zdrojů. V potaz se nemusí brát pouze databáze, ale i jiné zdrojové soubory, například XML soubory, prosté textové soubory formátované například s oddělovači políček (csv formát) a další. Je důležité si uvědomit, že je potřeba se na data dívat ne jako na plochou strukturu, ale jako na strukturu rozvětvenou, kterou je potřeba vyčistit a zpracovat jako celek. Má smysl zpracovávat a transformovat jen data včetně všech souvislostí. Pokud tedy budeme například čistit a transformovat data klienta banky, pak také musíme zohlednit to, že klient banky někde bydlí. Dále je také zřejmé, že s takovými rozvětvenými strukturami můžeme pracovat dvojím způsobem. Za prvé můžeme nejdříve zpracovat informace o bydlišti a uložit jej do cílového úložiště nebo můžeme pracovat s adresou a s klientem v celku, což znamená obě informace v průběhu transformace a čištění spojit a na konci procesu od sebe oddělit. Jako zdroj dat nám také může posloužit některá již existující aplikace. Jedná se zejména o případy, kdy nemáme přímý přístup k datům nebo data jsou dostupná kvůli technickým omezením pouze na základě přímého požadavku. Data z databáze Databáze jsou díky svému rozšíření asi nejčastějším zdrojem dat pro konsolidaci. Je dobré si uvědomit, že ač dnešní moderní databáze obsahují jisté nástroje pro omezení domény dat, kontroly dat a kontroly jejich konzistence, tyto nástroje nejsou v žádném případě dostačující. Zaručí nám nejvýše konzistenci formátu dat, ale ne správnost a korektnost významu dat. Pro zpracování dat z databáze nám postačí standardizovaný ovladač k API pomocí kterého se připojíme - např. JDBC, ODBC nebo specializované ovladače, které nám mohou umožnit některé další pokročilejší funkce, které nám urychlí zpracování dat jako jsou paralelní zápis nebo načítání, které se hodí při práci s opravdu velkými objemy dat. 15

16 XML Xml je textový formát primárně sloužící pro výměnu dat. V mnoha systémech je ale tento formát také používán k uchovávání dat. Používá se pro data která nemají plochou strukturu, ale jsou hierarchicky uspořádaná. Z našeho pohledu je největším problémem XML, že ač jsou data strukturovaná, formát samotný neobsahuje žádnou definici ani struktury ani formátu dat. Tyto informace se definují externě a musí být explicitně vyžadovány programátorem při parsování xml. Tato kontrola není vyžadována a pokud programátor nezapne validátor ručně, tak žádná kontrola dat prostě neproběhne. Dalším problémem je, že při běžném používání jsou xml soubory kontrolovány pouze při čtení a nikoliv při zápisu. Takže se může stát, že program bude zapisovat data, která nemají ani konzistentní strukturu, natož obsah. V takovém případě na to nepřijdeme dokud se nepokusíme o čtení. Tento problém se neprojeví ani tak při malých programech, ale spíše při integraci více aplikací dohromady, kdy je větší potřeba striktně dodržovat formát. Definice struktury a formátu jsou, jak již bylo psáno externí, a jsou od nejjednodušších jako Doctype, který definuje pouze základní strukturu, až po XML Schema nebo NG Schema, které kontrolují i hodnoty dat. Document Type Definition (DTD) DTD je standard definující formát struktury XML. Tento formát je nejjednodušší ze všech používaných, ale také nejméně mocný. DTD definuje následující prvky v XML: Obsah elementu - párový element může obsahovat jiné elementy nebo pouze data. DTD definuje, jestli obsah elementů mohou být pouze data, pouze jiné elementy nebo mixované elementy společně s obsahem. DTD také definuje, které elementy může rodič obsahovat. Nulové hodnoty - DTD definuje, které elementy a které atributy elementů nemusí být obsaženy v XML souboru. Kardinalitu - elementy mohou být obsaženy v rodičovském elementu vícekrát nebo jenom jednou. Povolené atributy - DTD definuje, které atributy jsou v XML elementech povolené. Výčet hodnot - v DTD je zapsáno, jaké hodnoty mohou elementy a atributy mít. XML Schema Definition (XSD) XML Schema je následník DTD, který jej dále rozšiřuje o detailní kontrolu typů a jiných vlastností. V Xml schema je možno v definovat strukturu do stejné úrovně jako jej definujeme v databázových tabulkách. Je tedy možno definovat typ atributů, hodnoty atributů. Tuto vlastnost DTD nemá. Xml Schema také podporuje některé věci, které byly do Xml přidány čase v době, tedy v době, kdy už bylo DTD vymyšleno. Nejvýraznější rozdíly mezi DTD a Xml Schema jsou uvedeny v následujícím výčtu. XSD má typový systém. To tedy znamená, že může definovat, že hodnota elementu/atributu musí obsahovat korektní datum nebo musí být číslo nebo URI nebo například text o délce přesně 5 znaků. 16

17 DTD může být vloženo do XMLml souboru, což XSD neumožňuje a musí být vždy definováno v externím souboru. XSD může specifikovat obsah pouze části XML. XSD podporuje XML namespace. XSD umí tvořit vlastní datové typy s použitím objektových principů. XSD ale obsahuje mnoho implicitních datových typů jako jsou textové hodnoty, čísla, data, časové hodnoty a jiné. Zpracování Xml souborů Při zpracování XML bývá potřeba použít nějakého nástroje, který data z Xml dostane. Budeme při tom měnit strukturu z různě hierarchické do polo-ploché struktury, která bude splňovat požadavek na to, že tranformační proces zpracovává jednotlivé ploché záznamy. Vezměme si za příklad následující fragment XML souboru, který poskytuje jeden záznam pro zpracování. <data> <area> <city>olomouc</city> <clients> <client> <name>martin</name> <lastname>novák</lastname> </client <client> <name>josef</name> <lastname>novák</lastname> </client> </clients> </area> </data> Výše uvedená struktura dat pro proudové zpracování dat opravdu moc praktická není, ale dobře ilustruje problém. Data jsou rozdělena podle oblastí, zde je konkrétně uvedeno město Olomouc. V něm jsou uvedeni jako klienti Martin Novák a Josef Novák. Uživatelé budou chtít zpracovávat klienty a z tohoto souboru mohou získat tyto informace - jméno, příjmení, město, a tedy dostat data jako v následující tabulce. Jméno Příjmení Město Martin Novák Olomouc Josef Novák Olomouc Aby se tyto data z XML dostala, tak se musí použít vhodné nástroje pro vyhledání dat. Jako nejvhodnější se jeví kombinace XML Stylesheet (XSLT) pro definici transformací struktury a dat a XPath pro definici cesty k jednotlivým elementům. Tento proces bude transformovat XML dokument ke zpracování na XML dokument, který zná náš transformační systém. Jako příklad takového XML Stylesheetu je níže. <?xml version="1.0" encoding="utf-8"?> <xsl:stylesheet xmlns:xsl=" version="2.0"> <xsl:output method="xml" version="1.0" encoding="utf-8" indent="yes"/> <xsl:template match="/"> 17

18 <data> <xsl:for-each select="/data/area"> <xsl:variable name="city"> <xsl:value-of select="city/text()"/> </xsl:variable> <xsl:for-each select="./client"> <row> <column> <xsl:value-of select="$city"/> </column> <column> <xsl:value-of select="./firstname/text()"/> </column> <column> <xsl:value-of select="./lastname/text()"/> </column> </row> </xsl:for-each> </xsl:for-each> </data> </xsl:template> </xsl:stylesheet> Jako další je ukázán výsledný dokument, kterému bude transformační systém spíše rozumět. <?xml version="1.0" encoding="utf-8"?> <data> <row> <column>olomouc</column> <column>martin</column> <column>novák</column> </row> <row> <column>olomouc</column> <column>josef</column> <column>novák</column> </row> </data> Textové soubory Textové soubory také mohou sloužit k naplnění transformačního systému daty. Nejobvyklejší formát je CSV formát, kdy jsou jednotlivá políčka od sebe oddělena čárkami či jiným oddělovačem a jednotlivé záznamy jsou od sebe odděleny oddělovačem řádku. Možné jsou i samozřejmě i další formáty, ale je potřeba, aby na ně byl náš systém připraven. Textové soubory, přestože jsou nejprimitivnější formou vstupu, nemusíme považovat za špatné. Jejich velká výhoda je vysoká rychlost načítání či zápisu velkého množství dat a také dobrá čitelnost dat uživateli. Aplikace dodávající data Někdy se může stát, že nebudeme mít z různých důvodů přímý přístup ke zdrojovým datům. V takovém případě musíme využít externí aplikace, která nám tyto data do našeho transformačního systému nahraje. Obvykle tomu bývá přes standardní vstup a výstup, který dále transformační systém přečte, rozparsuje a uloží data do vlastních struktur. 18

19 Úložistě mezivýsledků Při transformaci databáze se používá speciálního úložiště dat, které slouží pro uskladnění dočasných dat. Jako úložiště může sloužit klasická relační databáze nebo soubory. V praxi ale není z výkonostních důvodů příliš vhodné využívat klasické databáze z výkonostních důvodů. Je tomu kvůli vysoké náročnosti udržování integrity, indexů a dále kvůli přoblémům výkonem s paralelními zápisy a čtením. Proto je vždy, když je to možné lepší používat nějaký formát souboru, který se bude optimální pro rychlý zápis a rychlé čtení. Výsledná data Výsledná data budou celkovým produktem našeho snažení o správnost a korektnost dat. Ve většině případů budou data zapsány do výše uvedených struktur, tedy do databází nebo xml souborů. Stávající aplikace Konsolidovaná úložiště dat jsou jistě používány aplikacemi, které je potřeba uzpůsobit nové situaci, kdy zde bude ještě jeden zdroj dat. Tyto aplikace mohou sahat od historických běžících na mainframech přes terminály až po nově napsané využívající moderní technologie. Tyto aplikace bude potřeba nějakým způsobem upravit tak, aby využívaly on-line konsolidaci dat a dělaly tak stejné operace nad daty jako náš konsolidační nástroj, ale v on-line režimu. 19

20 Popis jednotlivých kroků V této kapitole budou stručně popsány jednotlivé kroky, podle kterých lze postupovat. Ze všeho nejdříve budou všechny kroky popsány pohledem shora, tedy bude načrtnuto základní schéma, budou stručně shrnuty jednotlivé kroky a poté budou v dalších kapitolách postupně podrobněji rozebrány s detaily a doporučeními podle kterých postupovat. Pro celý postup budeme používat soubor nástrojů nebo lépe celý integrovaný systém pro konsolidaci dat. K implementaci byl použit IBM Information Server, ale obdobné nástroje mají i konkurenti IBM jako jsou Oracle, Informatica, SAP a další. Celý postup se bude skládat z jednotlivých kroků, které lze modifikovat podle potřeby. Vše bude vždy záviset na nástrojích a možnostech, které jsou k dispozici. Naplánování projektu a definování cílů, kterých chceme dosáhnout Analýza dat a jejich struktury Modelování ETL procesu Příprava stávajících aplikací a systémů na přechod k novému úložišti Provedení konsolidace dat a přechod stávajících systémů k novému úložišti Naplánování projektu a definování cílů, kterých chceme dosáhnout Projekt je potřeba správně naplánovat tak, aby jeden úkon plynule navazoval na druhý. Analýza dat a jejich struktury Po naplánování projektu je potřeba pořádně zanalyzovat data a strukturu dat. Je potřeba zjistit, kde by se mohly vyskytovat datové chyby a další problémy. Dále je potřeba zjistit rozložení dat, které hodnoty vybočují z obvyklých mezí a také, aby se dalo poznat, které záznamy jsou pravděpodobně duplicitní. Dále se v tomto kroku navrhne struktura cílového úložiště. Modelování ETL procesu V této fázi se navrhne postup jakým budou zdrojová data transformována do cílového úložiště. Příprava stávajících aplikací a systémů na přechod k novému úložišti V tomto kroku připravíme stávající aplikace pro spuštění v novém prostředí. Navážeme je na nové úložiště a na on-line verzi ETL procesu transformace dat. 20

21 Provedení konsolidace dat a přechod stávajících systémů k novému úložišti V poslední fázi se provede samotný deployment nového úložiště a aplikací. Nejprve se provede dávková úloha transformace starého úložiště na nové a dále se upgradují stávající aplikace na nové verze, které budou spolupracovat s transformačním systémem. 21

22 Příprava projektu Plánování projektů je velmi důležité pro celkový úspěch. Proto je potřeba mu věnovat náležitou pozornost a nepodcenit jej. Je třeba si vytvořit časový harmonogram prací, tak aby na sebe jednotlivé úkony navazovaly a udržela se vysoká produktivita práce. Příprava a plánování však není pouze o časovém harmonogramu prací, ale také o tom co se všechno bude dělat a jaká data bude potřeba integrovat, jaké aplikace a systémy upravit, kdo bude mít zodpovědnost za data atd. Je tedy třeba kromě samotného naplánování projektu také rozhodnout a zjistit tyto věci: zjištění co integrovat správa a zodpovědnost za data a systémy kroky po dokončení transformace dat Co integrovat Je potřeba zjistit nejen jaká data z kterých databází mohou být integrovány dohromady, ale také jaké aplikace je používají, aby mohly být upraveny pro práci s novým úložištěm dat. Také je potřeba zjistit jak budou integrovaná data záviset na dalších systémech, aby se nerozbily závislosti mezi nimi. Rozhodnutí o správě a zodpovědnosti za data a systémy V každé firmě by měl být někdo, kdo za data ručí a nese za ně zodpovědnost. Tímto se myslí, že někdo bude zodpovědný za obsah, bude mít konečné slovo při rozhodování při nesrovanalostech v datech, bude vědět co jednotlivá data znamenají. Dále bude monitorovat data, upravovat je, zlepšovat jejich kvalitu a přidělovat práva pro přístup k těmto datům. Pro tuto činnost se používá termínu data governance. Proto by správa a zodpovědnost za data rozhodně neměla být na IT oddělení společností. IT oddělení totiž za prvé obsahu dat většinou nerozumí a proto mohou přesouvat odpovědnost na jiné oddělení. IT oddělení dále mají většinou na starost chod systémů a ne interpretaci jejich obsahu. Kroky po skončení transformace dat Plánování takového projektu jako je transformace a čištění dat není pouze krátkodobá záležitost doby, po kterou se bude realizovat technická stránka projektu, ale je to záležitost dlouhodobá pokrývající i další úkony po dobu existence nového úložiště. Je třeba si uvědomit, že projektem končí jenom první část - realizace nového úložiště. V další, dlouhodobé fázi je potřeba mít vyškolené pracovníky, kteří se budou dál zabývat kvalitou dat uložených v databázích. Také je také potřeba vytvořit pravidla pro nové IT projekty tak, aby pracovali s novým úložištěm. 22

23 Analýza dat a jejich struktury Dalším krokem, který je na našem seznamu je analýza dat a jejich struktury. Proč je tento krok důležitý? Je tomu hlavně z důvodu, že data uložená v databázích oraganizací typicky obsahují spousty chyb. Typicky uváděná čísla jsou okolo 5% chyb, což je měřeno jako počet chybných polí děleno počtem všech polí [RED98, ORR98]. Tyto chyby dále zvyšují nejen provozní náklady, kdy společnost například ztrácí prodeje vlivem špatných dat, ale také evidentně porostou náklady na jejich pozdější dodatečnou opravu, což je jistě náročnější než oprava dat při vstupu dat do databáze. Proto je třeba data čistit co nejdříve, abychom neplýtvali lidskými silami a časem. Také je zřejmé, že nelze mluvit o kontrole dat a následném čištění dat lidskými silami, ale automatizovanými nástroji. Databáze bývají často příliš velké na to, aby je mohly čistit lidé ručně. Další důvod je to, že lidská práce je mnohem dražší, než případný vývoj nebo nákup nástrojů a hardwarových prostředků pro čištění, ač ani ony nejsou zanedbatelnou položkou v účtech za vyčištěnou databázi. Je zřejmé, že je třeba připravit celý proces čištění tak, aby byl komplexní a pokrýval nejen co největší množství položek, také se zabýval chybami, které v datech mohou vzniknout a pokud možno jich co nejvíce opravoval. Buďme tedy konkrétnější a řekněme, co vše budeme potřebovat. Za prvé to bude nástroj pro čištění dat samotných, dále budeme potřebovat nějaké nástroje na analýzu dat, dále nástroje na sestavení, ladění a ověření procesu čištění a v neposlední řadě nástroje pro opravu chyb pro najmutý personál, který vyčistí chyby, které nelze opravit automatizovaně. Tento personál je třeba také vyškolit tak, aby věděl co a jak opravovat. V této kapitole bude rozebrán pojem datové kvality a čištění dat, dále to, jakou strukturu dat by mělo výsledné úložiště mít. Vznik chyb Mnoho chyb v datech vzniká proto, že jsou umístěny v polích, která jsou svým obsahem textová bez omezení. Do těchto polí se data vkládají bez ladu a skladu aniž se bere ohled na jejich další integritu. Jako příklad můžeme uvést PSČ, které je v České Republice uloženo jako textové políčko o délce pěti znaků. Jeho jediným omezením je délka pěti znaků. Obvykle žádná další kontrola obsahu, jako shoda s městem, nikdy neproběhne. Datová kvalita a čištění dat Definujme si nejdříve co to jsou kvalitní data. Vybrána byla definice podle [DWETL] - jsou to data, která splňují následující požadavky: Správnost - hodnota uložená v datech je uložena bez překlepů a její interpretace pravdivě a správně vyjadřuje jejich význam. Vezměme za příklad klienta banky žijícího v Praze. Obsah dat s bydlištěm klienta potom musí obsahovat Prahu a ne jinou hodnotu. Jednoznačnost - hodnota uložená v datech má pouze jednoznačnou interpretaci, tedy znamená jednu věc a nelze si ji splést s jinou. Proto v datech o našem klientovi musí být 23

24 napsána ještě Česká republika, protože na světě existuje více Prah (např. městečko v Oklahomě v USA). Konzistence - hodnoty uložené v datech jsou reprezentovány v jednotném formátu. Tedy například kraje mohou být vyjádřeny jako Jihomoravský kraj nebo JM. V takovém případě je nutno se shodnout na jednotné definici a důsledně ji všude používat. Úplnost - zde je třeba brát v potaz dvě úplnosti Úplnost individuálních hodnot - jednotlivá data musí být plně definovaná, nejsou dovoleny hodnoty jako není definováno. Tedy v adrese našeho klienta musí být správně definovány všechny položky adresy - ulice, číslo domu, psč a město. Úplnost celku - data jako celek musí obsahovat včechny záznamy. V našem případě to budou všichni klienti naší banky. Jediný klient nesmí chybět. Tato definice je definicí úplné kvality dat. Tohoto stupně se v našem procesu konsolidace dat snažíme dosáhnout všemi možnými prostředky. V následujících odstavcích jsou více rozebrány jednotlivé případy nekvality dat, se kterými se lze běžně setkat. Je třeba si je uvědomit a při konsolidaci dat s nimi počítat a jednotlivá porušení operativně spravovat. Typické příklady narušení kvality dat V této podkapitole budou rozebrány některé typické příklady co všechno lze mít v datech špatně a jak to opravit. Jako příklady byly vybrány typické entity, které jsou používány ve velkých organizacích. Samozřejmě lze najít spoustu dalších příkladů, kde lze data zadat špatně, ale to závisí na struktuře dat a na doméně problému a je potřeba vše zvážit individuálně. Nesprávná data Nesprávná data jsou data, která nepatří do domény naších dat - buď hodnotami nebo interpretací. Správnost dat můžeme v některých případech kontrolovat podle slovníku hodnot - jestli v datech nejsou překlepy. Hodnoty, které takto můžeme kontrolovat jsou většinou jmenného charakteru, tedy například jména a příjmení osob, názvy ulic, názvy měst. Nesprávnou interpretaci samozřejmě nemůžeme automaticky odstranit, proto dále rozebírána nebude. Adresy Adresy jsou typickým příkladem dat, která mohou být kontrolována podle slovníku. Česká Pošta, s. p. poskytuje za úplatu číselníky se všechi adresami evidovanými v České Republice, na které může být doručena listovní zásilka. Tyto číselníky jsou nejlepším dostupným registrem všech adres v České republice a jsou pravidelně aktualizovány. Číselníky adres nám pomohou zajistit jednoznačnost našich adres tím, že se musí shodovat všechny údaje o adresách v naší databázi s číselníky. Cena číselníků adres prodávaných Českou poštou byla v roce kč za jednorázové dodání na CD a 1200, resp kč za půlroční resp. roční předplatné. Další informace lze nalézt na webových stránkách České Pošty

25 Omezení Data také mohou být omezena nějakými pravidly, která se v některých zdrojích nemusí dodržovat a v jiných ano. Nejednoznačná data Adresy Adresy jsou jedním z nejvíce rozšířených typů dat, která mohou být nejednoznačná. Adresy se obvykle skládají z ulice, čísla domu, města a PSČ. Tato data jsou spolu svázána a je proto třeba kontrolovat, jestli souhlasí jako celek. Jména Jména jsou dalším příkladem, kdy jsou jako samostatně použitá nejednoznačná. Vezměme si jako příklad jméno Josef Novák. Toto jméno se ve velkých databázích bude vyskytovat určitě několikrát a proto je třeba jeho jednoznačnost doplnit ještě například rodným číslem. Synonyma Dalším z nejednoznačností v datech mohou být synonyma. Ta se mohou také vyskytovat v adresách, kde jsou například ulice označeny zkratkami UL, ulice nebo ul.. Proto je potřeba data standardizovat. Standardizace Standardizace je úkon, při němž se data, která mají nejednoznačné formátování, jednoznačně zformátují. Standardizují se data proti nějakému slovníku standardních pojmů. Jako příklad si můžeme dát výše uvedenou ulici nebo například jména, kde takto můžeme bojovat s akademickými tituly. Další výhodou srovnávání dat se slovníkovými údaji je možnost rozdělit data podle významu. Toto se například může používat pro rozdělení políčku jména, které obsahuje křestní jméno, příjmení a akademický titul. Nekonzistentní data Rodná čísla Rodná čísla jsou jedním z příkladů možných nekonzistentních dat. Rodná čísla lze strojově kontrolovat proti nekonzistenci dat, protože zde platí pravidlo dělitelnosti jedenácti. Je třeba se ale mít na pozoru, že zde existuje několik vyjímek rodných čísel, které nejsou dělitelné jedenácti. Platební karty Dalším příkladem, kdy lze uplatnit nějaké pravidlo na konzistenci hodnot dat jsou platební karty, pro které platí, podobně jako pro rodná čísla, různá pravidla dělitelnosti. Záleží samozřejmě na vydavateli a typu karty. 25

26 Neúplná individuální data Neúplné hodnoty jednotlivých polí individuálních dat samozřejmě ne vždy znamenají, že data jsou neúplná. Vezměme si za příklad rodná čísla, která jsou přidělována pouze občanům České republiky, a proto bude hodnota dat u cizinců nulová. Nulové hodnoty Nulové hodnoty jsou častým případem neúplných dat, kdy data prostě nebyla do systému zadána. Neúplné celky Mezi nejčastější chyby jsou neúplné celky dat, kdy jsou například špatně definované cizí klíče, nebo stromové relace s rodiči a potomky. Složitější omezení Některá data musí podléhat složitějším omezením. Tyto data je také možné označit a ručně zkontrolovat. Analýza pro kvalitní data Analýzou dat pro datovou kvalitu se snažíme najít slabá místa, kde by se mohla kvalita dat zlepšit. Analýza by nám měla odpovědět na tyto otázky: Jaké chyby se mohou v datech vyskytovat? Ve kterých datech se chyby vyskytují (ve kterém zdroji)? Jak moc jsou chyby v datech rozšířené? Existují nějaké zajímavé vzory chyb v datech? Struktura hodnot dat Poznání struktury hodnot dat nám řekne hodně o tom, jaké hodnoty se v datech vyskytují a odhalí nám potenciální špatné hodnoty. Vezměme si jako příklad kraje v České republice. Před rokem 2000 existovalo krajů 7 jako pozůstatek Československa, ale dnes je jich 14 a některé, ač s podobným územím, se jmenují jinak. Analýzou struktury hodnot můžeme například zjistit, že se u některých osob stále ještě používá Severomoravský kraj místo Moravskoslezského. Toto je příklad hodnot o kterých nemusíme mít tušení a odhalí je nám až analýza struktury hodnot dat. Nulové hodnoty dat Dalším problémem je nesoulad mezi definicemi nulových hodnot dat. V jedné databázi mohou být v sloupci jednoho významu vloženy hodnoty s povolenou nulovou hodnotou a v další databázi ve stejném sloupci nemusí být nulová hodnota dat povolená. Důležitá je interpretace těchto 26

27 nulových hodnot, protože se mohou databázi od databáze lišit. Také je důležité sjednotit metodiku v tom, co s těmito daty dále dělat. Nulové hodnoty jsou také jedním z největších problémů kvůli interpretování svého obsahu. Není nikde řečeno, jestli nulový text je jen nezadaný text nebo je to text s nulovou délkou. Interpretace je tedy volná a záleží na návrháři databáze, popřípadě na uživatelích databáze. Proto je nejlepší se nulovým hodnotám vyhnout a jednotlivé uvádět jako NOT NULL s předvyplněnou hodnotou buď prázdného řetězce nebo jiné hodnoty tak, aby uživatelé databáze poznali, že hodnota není vyplněna. V případě konsolidace je doporučeno kovertovat nulové hodnoty na prázdný řetězec hned v úvodu konsolidace dat a dále používat pouze nenulové hodnoty. Znakové sady Ještě je potřeba zmínit problém znakových sad, které dělají problémy při komunikaci a ukládání dat mezi různými systémy. Znakové sady jsou samozřejmě také problémem při ETL procesu a je třeba se problémům s nimi vyhnout jak je to jen možné a používat Unicode kódování. Při návrhu cílového úložiště je dobré se zamyslet, jestli by nebylo lepší se v cílovém úložišti nevyhnout budoucím možným problémům s kódováním. Tedy zda-li nepoužít kódování podle standardu Unicode místo například podle standardu ISO. Pravděpodobně nejlepším řešením by bylo zvolit si kódování UTF-8, které kombinuje úsporu velikost s pokrytím prakticky všech znaků všech světových abeced. Toto kódování dosahuje úspory, protože kóduje standardní znaky Angličtiny v prvním bytu a znaky ostatních abeced neobsazené v Angličtině kóduje vícebytově. Toto je zjevná výhoda proti dalšímu rozšířeným kódováním Unicode UTF-16, resp. UTF-32, které pro kódování jednoho znaku používají fixní délku 2, resp. 4 bytů. Tato kódování jsou lépe použitelná pro použití v klasických aplikacích, kvůli rychlejšímu indexování, ale v operacích s daty by nastal problém se zabráním příliš mnoha místa. Toto rozhodnutí nám usnadní budoucí život, ale je potřeba zjistit, jestli je to vůbec možné a jestli s tímto rozhodnutím bude kompatibilní nejen databáze, ale i samotné aplikace využívající nové úložiště. Dalším problémem, který může nastat je nekompatibilita stávajících aplikací se standardem Unicode. Nekompatibilita může začínat nad jiným chápáním délky databázového pole se znaky v Unicode a se znaky v jednobytovém kódování. Například délka řetězce může být chápána jako délka znaků nebo délka v bytech. V Unicode nám tento příklad dá dvě různé hodnoty. Aplikace samotné také nemusí podporovat standard Unicode. Jako příklad si můžeme vzít Borland Delphi nebo v této práci použitý C++Builder, který využívá standardních kódovýh stránek vestavěných ve Windows a tudíž, pokud konvertujeme data z UTF-8 a přijde-liczb znak, který aktuálí kódová stránka neumí, aplikace bude mít s tímto znakem problém a může dojít napřiklad k odmítnutí přijmout tento text nebo k automatické konverzi takového textu do aktuálí kódové stránky, což bude znamenat ztrátu dat. 27

28 Modelování procesu konsolidace V této kapitole bude rozebráno jak by měl vypadat model procesu, který se použije k překlopení dat z databází do konsolidovaného úložiště. Bude rozebráno nejen jak data přenést, ale také jak data transformovat a vyčistit. Jako téměř každý problém, který chceme řešit, lze i modelování konsolidace databází rozdělit na základní kroky, které spojením vytvoří výsledný postup řešení. Celou integraci lze rozdělit na několik procesů, ve kterých se budou provádět jednotlivé dílčí úkony a které budou na sebe navazovat. Jednotlivé kroky budou blíže popsány a jednotlivé operace v nich budou rozděleny do komponent. Při konsolidaci databází budeme spouštět jeden či více nástrojů. Některé společnosti nabízí ucelené systémy, které se postarají o všechny kroky, jiné nabízejí systémy, které provedou pouze svoji část a o zbytek procesu se musí postarat další nástroje buď od toho samého výrobce nebo od jiných. Návrh procesu Celý proces je nejlepší navrhnout jako soubor akcí, podobně, jako u messagingových systémů. Musíme se ale při návrhu připravit, obzvláště, pokud nemáme zkušenosti s podobnými systémy, že styl je poněkud odlišný než jsme zvyklí ze standardních programovacích prostředí. Základním rozdílem je, že zde nejde o programování jednotlivých kroků, ale o vytvoření pravidel, která se v jednotlivých krocích provedou. Nejlépe je, když se postup rozdělí na několik procesů, v každém se provede nějaký dílčí mezikrok a spojením všech těchto procesu do jednoho celku vznikne jakýsi program, který překlopí stávající data do nového úložiště. Jednotlivé procesy budou na sobě funkčně závislé, tedy následující krok lze spustit až po dokončení kroku předchozího. Samozřejmě, že existují vyjímky, kdy lze jednotlivé kroky spouštět paralelně, ale to jen za předpokladu, že nedojde ke konfliktu závislostí dat. V následujícím seznamu jsou vypsány jednotlivé kroky, které se budou spouštět po sobě. Nahrání dat do systému pro konsolidaci Standardizace a odstranění duplicit Transformace Nahrání dat do cílového úložiště dat Tyto procesy na sebe budou navazovat, ale například v kroku nahrání dat do systému pro konsolidaci se mohou nahrávat data z jednotlivých databází paralelně. Jednotlivé procesy se také mohou skládat z více podprocesů podle toho, jakou implementaci systému pro konsolidaci dat použijeme. 28

29 Načtení dat ze zdroje 1 Standardizace Transformace Cílová databáze Načtení dat ze zdroje 2 Sled procesů Celý temto transformační proces se nazývá ETL proces a původně vznikl při vytváření datových skladů. Jednotlivé procesy si mezi sebou budou předávat data. Je dúležité znát formát těchto dat a proto mnoho systémů zavádí nástroje na správu metadat, které operace s metadaty zjednodušují. Načtení dat ze zdroje V tomto procesu se načtou data ze zdrojů do systému. Nejdříve je potřeba definovat si vstupní sloupečky dat a dále si definovat jaká data budeme posílat do dalšího procesu, tedy do standardizace. Standardizace a odstranění duplicit V procesu standardizace a odstranění duplicit se vyčistí data. Jako vstup budou data ze všech vstupních databází, která budeme mít uložena v systému z předchozího kroku. Výstup ze standardizace budou data, která jsou rozdělena na atomické informace. Jako příklad lze uvést jméno osoby, které může být rozděleno na titul, křestní jméno a příjmení. Odstranění duplicit bude probíhat tak, že se nejdříve vyberou záznamy, které jsou duplicitní a dále se z těchto záznamů vyberou políčka, která mají nejlepší data. Kromě těchto duplicitních záznamů budou k dispozici záznamy, které nemají ve zdrojových datech duplicity a dále záznamy, u kterých si systém není jistý, že jsou duplicitní a je potřeba rozhodnout ručně. Transformace Tento proces provede další transformace dat podle potřeby. Transformace se samozřejmě mohou objevit v jakémkoliv předchozím kroku. Načtení dat do cílové databáze V tomto procesu se data zpracovaná v předchozích krocích načtou do nového úložiště. 29

30 Komponenty Jednotlivé procesy je možné buď naprogramovat nebo v moderních ETL systémech graficky namodelovat jako sled akcí, které dohromady dávají funkční celek, který provede příslušné transformace s daty. Dobrou reprezentací takovýchto akcí jsou komponenty, které jsou znovupoužitelné, reprezentují obecnější operace nad daty, jsou parametrizovatelné a jejich chování je upravitelné podle potřeby. Díky tomu, že se procesy budou modelovat a ne programovat, je dobré si uvědomit základní rozdíly v myšlení mezi modelováním a programováním takového systému. Celý proces deklarativní, to znamená, že vykonávání jednotlivých akcí komponent není řízeno námi, nýbrž systémem. Zde nemáme možnost ovlivňovat kdy se co vykoná (samozřejmě, že je systém omezen závislostí dat, ale nemáme úplně přesnou kontrolu nad tím jak a kdy se co spouští). Systému tak vlastně pouze řekneme jaká akce se spustí po které, ale to je vše, co můžeme ovlivnit. Metadata Metadata jsou informace o datech. V našem systému se tím myslí informace o formátu dat, dále to mohou být například definice připojení k databázi nebo cesty k souborům. V průběhu modelování musíme dodržovat strukturu dat. V jakém formátu jeden proces data uloží, v takovém je musí následující proces i načíst. Na prvním místě se to týká počtu a významu sloupečků v jednotlivých záznamech. Musí být stejné. Dále se to také týká formátů jednotlivých dat. Zde podmínka není tak přísná, protože existuje možnost konverze dat mezi navzájem kompatibilními typy. U jednotlivých polí je třeba zachovávat vlastnosti sloupců podle toho. Následuje výčet toho, co vše by se mohlo považovat jako omezení sloupečků. Datový typ - používat lze pouze kompatibilní datové typy. Rozsahy čísel - některé sloupečky mohou mít omezení rozsahu hodnot. Je třeba definovat jaké rozsahy jsou povoleny. Výčty - v některých sloupcích lze povolit pouze určitý výčet hodnot. Nepovolené hodnoty - pokud by byl výčet moc dlouhý, tak je možno definovat nepovolené hodnoty. Délku polí - je třeba brát ohled na omezení délky textů Nulové hodnoty - je třeba se dohodonout, jestli políčko může obsahovat nulové hodnoty a popřípadě co znamenají tyto nulové hodnoty. Při nedodržení některého z výše uvedených omezení lze provést následující operace: Zapsat chybu do určeného výstupu pro další zpracování chybných dat Ignorovat chybu a předat data další komponentě Zastavit zpracování 30

31 Příprava stávajích systémů V této kapitole budou popsány možnosti jak upravit stávající aplikace tak, aby používaly nového úložiště v kombinaci se stávajícím úložištěm. Může se předpokládat, že každý systém, který se bude konsolidovat, bude zdrojem dat pro více aplikací nebo informačních systémů a aplikací. Stávající aplikace mohou buď plně přejít na nové úložiště nebo jej využívat částečně, například pouze pro zápis dat. Druhá možnost bude kvůli náročnosti předělávání stávajících aplikací asi častější volbou nehledě na to, že je pravděpodobné, že existující databáze jsou používány více aplikacemi, a tak by bylo potřeba přepisovat více kódu. Dalším problémem je možná ztráta zdrojových kódů současných aplikací, nedostatek dokumentace a také to, že lidé, kteří staré systémy navrhovali, již nejsou k dispozici. Toto vše komplikuje práci na předělání stávajících systémů a mnohdy je proto třeba sahat k náročnějším řešením, které budou obcházet stávající situace. Více v podkapitole Když nemáme kód stávající aplikace. Než bude navrhnuto jak implementovat komunikaci stavajících systémů s novým úložištěm, je třeba říct, nějaké požadavky a omezení toho, co by měla nová implementace umět. stávající aplikace by při zápisu dat do nového úložiště měly využívat náš transformační systém tak, aby se maximálně eliminovaly chyby v datech a to v on-line režimu. data ve starém systému musí zůstat stále konzistentní data, která se budou přidávat do nového úložiště, se také budou přidávát do stávajících úložišť a budou na sebe vzájemně odkazovat. Možností jak upravit aplikace samotné je více, ale jako základní se jeví dvě. Buď se aplikace může upravit tak, aby s novým úložištěm komunikovala sama nebo se může použít middleware, který bude zpracovávat celou logiku aplikace a aplikace samotná bude komunikovat pouze s ním. Tento druhý přístup bude vhodnější, protože tak budeme mít přístup k datům z jednoho místa a můžeme jej využívat z více aplikací. Middleware Middleware je obecně označován systém, který stojí mezi dvěmi dalšími systémy a dělá jim prostředníka v komunikaci. Middleware komunikaci nejen zjednodušuje, ale také ji dělá přehlednější a flexibilnější. Výhoda middlewaru jako systému mezi dalšími aplikacemi je především ta, že pokud bude potřeba, aby spolu dvě aplikace komunikovaly, tak není potřeba upravovat aplikace a psát speciální adaptér pro komunikaci, ale může se využít většinou standardizovaných protokolů, které podporuje daný middleware. Middleware také umožňuje jednoduše využít různých již vymyšlených a standardizovaných řešení pro komunikaci mezi aplikacemi. Tyto standardizované postupy mohou pomoci navrhnout lepší architekturu pro klienty, kteří mohou počítat s omezeními v komunikaci jako například rychlosti protokolů nebo s jejich spolehlivostí. 31

32 Hlavní nevýhodou middleware je, že představuje jediné místo poruchy, tedy pokud middleware selže a není automaticky duplikován, tak ani ostatní systémy spolu nemohou komunikovat. Proto u middleware bývá kladen velký důraz na spolehlivost a na redundanci. Message Oriented Middleware Message Oriented Middleware (MOM) se nazývá klient-server infrastruktura, kde se přenáší jednotlivé zprávy. Tato architektura není nikterak standardizovaná a standardizace proběhla pouze u jejich některých implementací jako jsou JMS nebo Message Queue. MOM je výhodná a používaná kvůli svému základnímu paradigmatu - klient pošle zprávu serveru, ten ji zpracuje. Některé systémy také umožní vrátit původnímu odesílateli odpověď, což ale záleží na implementaci. Zprávy jsou po přijetí ukládány v databázi, která slouží k jejich zálohování. Zpráva je dále poslána příjemci. Databáze na pozadí také umožní asynchronní zpracování zpráv, kdy jsou zprávy do MOM systému postupně posílány, zde ukládány do databáze a postupem času posílány příjemci. Tato vlastnost je také výhodná, pokud klient komunikuje se serverem na nespolehlivé lince nebo chce mít jistotu, že server vždy přijme každou poslanou zprávu a žádná zpráva se neztratí. Jako další příklad pro asynchronní zpracování jsou zprávy, které jsou ukládány na MOM server a poté například periodicky vyzvedávány jiným systémem. MOM také umožňuje routovat zprávy, například poslat zprávu více klientům jako broadcast nebo multicast. V našem systému dále budeme uvažovat pouze tuto middleware architekturu. Komunikace s MOM může probíhat nad několika protokoly. Mezi nejtypičtější příklady patří SOAP nebo JMS. SOAP Simple Object Access Protocol (SOAP) [SOAP1] je komunikační protokol založený na XML, který slouží pro výměnu strukturovaných informací. SOAP nejčastěji komunikuje pomocí HTTP protokolu, kdy klient pošle serveru HTTP POST zprávu, která bude mít jako svůj parametr SOAP zprávu. Server zprávu zpracuje a pošle klientovi SOAP zprávu s návratovou hodnotou. SOAP tedy funguje na paradigmatu požadavek-odpověď. SOAP má také výhodu toho, že je textovým formátem. Díky tomu se dají jednotlivé zprávy relativně snadno prohlížet bez pomocí dalších nástrojů. Také je dobré, že lze jednotlivé zprávy snadno ukládat na disk například pro další audit. JMS Java Messaging Service (JMS) je standardizované rozhraní pro posílání zpráv v messagingových systémech v Javě a je definováno pod Java Enterprise Edition (JEE). 32

33 Komunikace aplikací s real-time transformačním systémem Komunikace s transformačním systémem Jak již bylo řečeno, tak aplikace by měla využívat námi použitý transformační systém pro zajištění kvality dat. Tento systém může běžet buď na serveru nebo přímo v klientské aplikaci, podle toho jak byl původní systém napsán a navržen. Tentokrát se již nebude jednat o úlohu, která se jednou spustí, ale bude se spouštět periodicky a klientská aplikace od této úlohy bude chtít vracet i výsledek, tzn. jestli nejsou data například duplikovaná. On-line zpracování může dál komunikovat s novým úložištěm a ukládat do něj data nebo to může dělat aplikace. Transformační systém však musí vždy informovat volající aplikaci o upravených datech. Data by se měla vrátit stejným způsobem jaký byl použit na volání transformace a měla by se vrátit buď volající aplikaci nebo jinému systému, který slouží jako prostředník pro update stávajících databází. Komunikace přímo s novým úložištěm Přímá komunikace s novým úložištěm je již na první pohled to nejjednodušší řešení. Stačí pouze do aplikace přidat transformaci dat v transformačním systému a zápis dat do nového úložiště. Právě toto řešení bylo implementováno v ukázkových aplikacích. Problémem tohoto řešení je, že pokud jedna aplikace provede změnu v novém úložišti, tak tyto změny nejsou již dále propagovány do všech stávajících úložišť. Kvůli tomuto problému a s narůstající velikostí a složitostí celku je lepší vyčlenit alespoň nějakou logiku pryč z klientské aplikace na stranu serveru do middleware nebo například do transformačního systému. Další důvody jsou například lepší přehlednost systémů, lepší oddělení kódu spravující data v novém úložišti od starého, snazší konfigurace aplikací, snazší upgrade software, a jiné. 1. insert 2. Transformační systém A P P Staré úložiště 3. update/insert 3. update/insert Nové úložiště Schéma jednoduché komunikace přímo s novým úložištěm 33

34 Komunikace s novým úložištěm přes transformační systém Další možností implementace je přesunout komunikaci s novým úložištěm do transformačního systému. Transformační systém se tak postará o zápis dat a vrátí aplikaci standardizovaná a vyfiltrovaná data, popřípadě zprávu, že záznam se stejným významem (např. se stejným klientem) již v novém úložišti existuje. 3. update/insert 1. insert 2. Transformační systém Nové úložiště A P P 3. update/insert Staré úložiště Schéma komunikace přes transformační systém Komunikace přes middleware Sofistikovanější komunikací s novým úložištěm nebo s transformačním systémem je komunikace přes middleware. Middleware celou funkcionalitu zabalí vlastním rozhraním a aplikace tedy nekomunikují přímo, ale přes něj. Možností co implementovat v middleware je několik. Komunikace pouze s transformačním systémem 1. insert 2. M I D D L E WA R E Transformační systém A P P Staré úložiště 3. update/insert 3. update/insert Nové úložiště Komunikace s transformačním systémem a s novým úložištěm 34

35 2. 1. insert 3. M I D D L E WA R E Transformační systém A P P Staré úložiště 4. update/insert 3. update/ insert Nové úložiště Middleware komunikující s transformačním systémem i novým úložištěm Komunikace s transformačním systémem, novým i starým úložištěm. 1. insert A P P 4. M I D D L E WA R E 3. update /insert 2. Transformační systém 3. update/ insert Nové úložiště Staré úložiště Middleware obsluhující jak transformaci dat, tak zápis do nového i do starého úložiště Vytvoření mezivrstvy mezi existujícími aplikacemi a novým úložištěm Ještě je potřeba věnovat trochu pozornost způsobu jak bude komunikovat transformační proces s naší starou databází. Je dobré si uvědomit několik požadavků a omezení, která budou kladena na zápis do starého úložiště. data musí být v souladu s novým úložištěm data se musí nejdříve upravit transformačním systémem a poté se uložit do starého úložiště data jsou ve většině případů používána více aplikacemi data z nového úložiště jsou používány ve více systémech Protože jsou data používána ve více systémech, je zřejmé, že je potřeba postavit nejaký replikační mechanismus, který by spolehlivě data z nového úložiště rozkopíroval do starého. Pro tento účel se nejlépe bude hodit nějaký MOM middleware, který bude pracovat v topic režimu, tedy bude mít jednu frontu, kam bude řadit zprávy a více odebiratelů, kteří budou zprávy vyzvedávat a tak ukládat data do starých úložišť. Nejlépe bude, když tento mechanismus bude spouštěn rovnou z transformačního systému těsně před uložením dat do nového úložiště. 35

36 1. insert A P P MOM SUBSCRIBER 1 MOM SUBSCRIBER 2 7. M I D D L E WA R E 2. MOM 3. zpráva pro MOM 7. Transformační systém 4. update/ insert Nové úložiště Staré úložiště 1 Staré úložiště 2 Spolupráce starého úložiště s novým Nově vytvořené úložiště musí být také schopno spolupráce s již existujícími zdroji dat, to znamená odkazovat na již existující data. Do každého řádku nového úložiště musíme tedy přidat jeden zpětný odkaz na řádku úložiště starého. Je to tedy umělé vytvoření cizího klíče, avšak bez možnosti automatické kontroly integrity. Když nemáme kód stávající aplikace Pokud nejsou k dispozici zdrojové kódy stávající aplikace nebo by přepsání stávající aplikace bylo příliš náročné, přechod na nové úložiště ještě není ztracen. Online detekce Mezi aplikaci a starou databázi se může postavit server, který interpretuje SQL dotazy a v případě vložení nebo update stávajícího záznamu v databázi je možno spustit náš transformační proces, data upravit, uložit je do nového úložiště a spustit SQL dotaz ve starém úložišti. 36

37 A P P SQL Proxy Staré úložiště Transformační systém Nové úložiště Schéma architektury s sql proxy Další variantou je do zdrojové databáze nainstalovat triger, který se bude spouštět při přidání nebo úpravě záznamu z dané tabulky. Tento trigger spustí transformační proces, uloží data do nové databáze a změní záznamy dat ve starém úložišti. 1. insert 2. trigger 4. update/insert A P P Staré úložiště Transformační systém Nové úložiště 3. update hodnot Schéma architektury s triggerem Obě výše uvedené možnosti jsou vlastně jakýmisi obdobami jednoduché replikace databází. Offline detekce Pokud nebudeme mít z různých důvodů možnost dělat online detekci popsanou v předchozí podkapitole, můžeme detekovat změny ve starých databázích a následovně externím procesem tyto změny replikovat do nového úložiště. Způsobů detekce změn je několik a je potřeba mít přístup přímo k databázi. Auditovací sloupec Do tabulky ze které bude načítat data do našeho transformačního systému vložíme nový sloupec, který bude obsahovat časové razítko poslední změny v hodnotách záznamů a jestli byl záznam přidán nebo upraven. Transformační proces je poté periodicky spouštěn po určitých časových úsecích a data jsou v něm nahrávána, čištěna a propagována do nového úložiště a dalších úložišť. 37

38 Sledování logu databáze Do databázových logů se vkládají změny záznamů postupně tak, jak v databázích mění jednotlivé záznamy. Tyto logy primárně slouží k obnovení databáze v případě problémů, ale je možno je využít i k jiným účelům jako je například propagace změn. Tuto techniku umí využívat existující ETL systémy. Postup je následující: v naplánovaný čas se udělá kopie logu, která se dále zpracovává. Tato kopie je postupně prozkoumávána systémem a jsou analyzovány všechny změny v záznamech. Tato technika má ovšem také nepříjemné stránky. Není neobvyklá situace, kdy databázové logy přetečou. V této situaci, kdy není dostatek volného místa administrátoři systémů logy většinou vyčistí. To pro nás znamená ztrátu informací o tom, jaké záznamy byly upraveny a tak ztratíme i možnost tyto změny dále propagovat do nového úložiště a do dalších systémů. 38

39 Provedení konsolidace dat a přechod na nové aplikace Provedení kosolidace data a přechod na nové aplikace se skládá ze dvou kroků. V prvním kroku se spustí proces transformace dat, tedy převedou se data na nové úložiště a jako druhý krok se upgradují stávající systémy a aplikace pro použití s novým úložištěm. Před začátkem nahrávání je potřeba vypnout stávající klienty tak, aby se neztratila data, která by se v průběhu přechodu na nový systém nahrávala do starého úložiště, ale zároveň by nebyla nebo byla špatně propagována do nového úložiště. Je také dobré myslet na plán B, tedy na případ, že se něco nepovede a bude potřeba se vrátit zpět k původnímu systému dokud se chyba neopraví tak, aby nebyla ohrožena funkčnost systémů. Nahrátí dat do nového úložiště je záležitost zpracování jedné dávky v transformačním systému. Po dokončení této dávky je vhodné zkontrolovat nové úložiště, jestli skutečně vše proběhlo v pořádku a jestli jsou v novém úložišti data, která tam mají být. Dalším krokem je upgrade stávajících aplikací a systémů. Tento krok spočívá v horším případě v instalaci nové verze aplikací na všechny počítače, které do stávajících úložišť ukládají data. Pokud je v organizaci nasazen software pro vzdálenou administraci klientů, jako je například Microsoft MOM nebo Microsoft SMS tak instalace nové verze software není problém. Problém s instalacemi také nebude, pokud budou aplikace využívat middleware nebo se budou používat webové aplikace, kde stačí vyměnit jednu komponentu v celém systému. 39

40 IBM Information Server IBM Information Server (IIS) [IBMIS] je produkt firmy IBM, který se snaží pomoci s problémy kvality a transformace dat. Tento produkt byl použit i pro vypracování projektu v této diplomové práci a následující text se snaží přiblížit jeho strukturu a používání. Kromě tvorby ETL procesů jsou další oblasti použití pro IIS jsou například replikace databází, a další aplikace z oblasti zpracování dat. Architektura Information Serveru IIS je z hlediska nástrojů rozdělen na uživatelské nástroje a na server běžící na pozadí, který tyto procesy spouští. Uživatelské nástroje umožňují vývoj a analýzu procesů a administraci IIS. Server běží jako několik Java aplikací pod J2EE aplikačním serverem IBM WebSphere. Název Popis Designer Administrator Director Console Aplikace pro návrh procesů. Aplikace pro administraci jednotlivých projektů. Aplikace pro monitorování, kontrolu, spouštění a plánování jednotlivých procesů. Nástroj pro správu a nasazení real-time komponent IIS. Seznam uživatelských nástrojů IIS Nástroje pro vývoj a analýzu jsou k dispozici jako klientské aplikace pro Windows. Uživatelské aplikace se připojují na rozhraní serveru a komunikují s ním, celý vývoj jednotlivých procesů tedy probíhá na serveru. IIS obsahuje několik serverových modulů, které spolu komunikují a vzájemně se doplňují. DataStage a QualityStage Federation Server Director Analyzer Bussines glossary Metadata Server Modul zajišťující návrh transformace dat, návrh zpracování dat pro zajištění kvality dat a samotné spuštění procesu transformace dat. Modul pro přístup a integraci dat z různých zdrojů. Modul pro zpřístupnění procesů IIS pro vnější aplikace. Modul pro analýzu obsahu a struktury dat. Modul starající se o integraci IT termínů s termíny pro běžné uživatele. Modul pro správu struktury dat. 40

41 Při tvorbě této práce byly použity DataStage a QualityStage moduly a dále Director, Analyzer a Console. IIS je kompletním nástrojem u kterého až na některé specializované aplikace není třeba používat externí nástroje pro některou ze základních částí transformace dat. Metadata Důležitou součástí IIS jsou metadata. Metadata jsou data o struktuře dat a procesů na serveru. Všechna metadata jsou umístěna v jednom úložišti na serveru. Přistupovat k nim lze pomocí unifikovaného rozhraní. Metadata se dělí na dva základní druhy - dynamická metadata a operační metadata. Dynamická metadata obsahují informace o úlohách, dalo by se tedy říci, že data, která může vývojář měnit. Operační metadata obsahují statistiky o výkonosti, audity, logy a vzorky dat pro profilování, tedy data o běhu IIS. Návrh ETL procesu v Information Serveru Návrh procesu transformace dat v IIS se děje ve vizuálním editoru. Při návrhu transformace dat rozdělíme proces na jednotlivé úlohy, které budou provádět větší celky a tyto jednotlivé úlohy na jednotlivé předpřipravené komponenty. Úlohy jsou v terminologii IIS nazývány jobs a komponenty stages. O komponentách více v další podkapitole. Díky tomuto rozdělení práce se návrhář nemusí zabývat nízkoúrovňovou prací přímo s daty, ale má k dispozici ucelený nástroj. Návrhář se bude zabývat pouze tím jak spojit jednotlivé komponenty do sebe tak, aby ve výsledku transformovaly data podle potřeb. Proces se někdy musí rozdělit na jednotlivé úlohy, které jsou na sobě závislé, protože některé stage potřebují vstup v návaznosti na předzpracovaná data a podle těchto předzpracovaných dat se musí také upravit jejich vlastnosti. Typickým příkladem může být stage pro odstranění duplicitních dat. Více v další podkapitole. Komponenty Komponenty (stage) jsou základním stavebním kamenem pro všechny úlohy v návrháři procesu. Jsou jednoduše použitelné a zodpovídají vždy za jednu funkci. Komponenty se propojují mezi sebou linkami a umožňují tak tok dat mezi sebou. IIS obsahuje celou řadu komponent. Můžeme rozdělit do několika kategorií podle typu funkce, kterou vykonávají. Jednotlivé komponenty se mezi sebou propojují spojeními, která reprezentují datový tok v rámci zpracování. Spojení tvoří výstup z jedné komponenty a vstup do jiné komponenty. Má definován seznam sloupců dat, které jsou výstupem první komponenty a vstupem do druhé. Pokud je první komponenta průchozí, tedy má-li vstup a výstup, pak lze většinou sloupce mapovat tak, abychom nemuseli zachovávat jména sloupců nebo mohli některé sloupce vynechat. 41

42 Definice sloupců na výstupu z komponeny Mapování sloupců mezi komponentami V rámci jednoho procesu lze ve vývojáři používat také kontejnery. Kontejnery jsou logickými jednotkami, které mohou obsahovat další komponenty. Mají vstupy a výstupy a přes ně komunikují se zbylými komponentami. Zvenčí se ale chovají jako jedna komponenta. V následující tabulce jsou vypsány kategorie komponent podle standardního nastavení IIS, jednořádkový popis a seznam komponent. Název Data Quality Popis Komponenty pro zajištění datové kvality Standardize, Unduplicate, Survive, Frequency Database Komponenty pro snadný přístup k datům v databázích Classic Federation, DB2 Enterprise, Oracle Enterprise, Informix, SQLServer Enterprise, Sybase, ODBC, MS OLEDB, Stored Procedure Development/Debug Komponenty pro pomoc při vývoji procesu a při problémy s daty. Column Generator, Head, Peek, Row Generator, Sample, Tail, Write Range Map 42

43 Název Popis File Komponenty pro přístup k datům uloženým na pevném disku. Complex Flat File, Data Set, External Source, External Target, File Set, Lookup File Set, Sequential File Processing Komponenty pro zpracování obsahu. Transformer, BASIC Transformer, Aggregator, Join, Merge, Lookup, Sort, Funnel, Remove Duplicates, Compress, Expand, Copy, Modify, Filter, External Filter, Change Capture, Change Apply, Difference, Compare, Encode, Decode, Switch, SAS, Generic, Surrogate Key Real time Komponenty pro umožnění procesům chovat se jako webové služby. Java Client, Java Transformer, Web Services Client, Web Services Transformer, WebSphere MQ, WISD Input, WISD Output, XML Input, XML Output, XML Transformer Restructure Komponenty pro manipulaci s komplexními typy ve sloupcích. Column Export, Column Import, Combine Records, Make Subrecord, Make Vector, Promote Subrecord, Split Subrecord, Split Vector Následuje seznam komponent použitých při tvorbě procesu transformace podle výše uvedeného seznamu kategorií s popisem jejich použití a vlastností. Kategorie Database V této kategorii nalezneme komponenty pro přístup k datům v databázi. Z této kategorie byla použita pouze komponenta ODBC Connector, která zajišťuje spojení s databází přes ODBC rozhraní. Kategorie File Data Set Komponenta Data Set umožní uložení dat v interní databázi IIS a dále tato data používat v jiných procesech. Data Set je možné si představit jako databázi, která je optimalizovaná pro rychlý zápis a čtení dat. Pro správa Data Setů lze použít nástroj Data Set Management, který lze vyvolat z menu Designeru. Zde si lze prohlížet definici dat a také samotná data. Data ale nelze měnit jinak než komponentou Data Set po spuštění procesu transformace. 43

44 Sequential File Sekvenční soubor, který umožňuje sekvenční čtení nebo zápis jednoho nebo více souborů. Pro soubory musí být použito stejného formátování jako pro CSV soubory s tím, že jednotlivé oddělovače záznamů a sloupců si můžeme zvolit dle potřeby. Kromě klasického CSV souboru můžeme definovat soubory s pevnou délkou záznamu. Příklad čtení a zápisu z/do sekvenčního souboru s chybovým výstupem Kategorie Data Quality V kategorii Data Quality jsou obsaženy komponenty pro zajištění kvality dat. Tato kategorie obsahuje následující komponenty: Investigate, Standardize, Match Frequency, Reference Match, Unduplicate Match a Survive. Celý proces zpracování kvality v IIS se skládá z následujícího workflow. Standardizace dat Frekvenční analýza dat Odstranění duplicit Vybrání přeživších dat (survive) Investigate Komponenta investigate slouží k analýze kvality zdrojových dat. Tato analýza pak poskytne detailní informace o tom, jaká je struktura dat a také může určit jaké parametry se budou dále používat v dalších komponentách datové kvality. Standardize Tato komponenta má za úkol standardizaci dat. Standardizace z každého záznamu vybere určitá data a ta podle svých dat ve slovnících zkategorizuje. Například, pokud se nechá komponentou standardize zanalyzovat celé jméno, pak komponenta na výstupu nabídne rozčlenění jména na jednotlivé elementy, které jsou klasifikované. Tedy nabídne titul, křestní 44

45 jméno, příjmení a jiné. Zde je ale nutné podotknout, že výsledky závisí na tom, jestli komponenta existuje pro daný jazyk nebo region. Údaje jsou totiž srovnávány se slovníkovými údaji a pokud například některé exotické jméno chybí, pak je třeba jej do slovníku doplnit. Frequency analyzer Tato komponenta má za úkol zjistit rozložení dat podle výskytu slov. Vezměme si jako příklad analýzu frekvence jmen a příjmení. Tento analyzátor bude sledovat jak často se vyskytují jednotlivé kombinace jmen a příjmení. Výsledky z této komponety se budou používat pro vstup komponenty unduplicate match, tedy pro odstranění duplicit, a dále pro vytváření pravidel pro tuto komponetu. Unduplicate Match Tato komponenta najde záznamy s identickým obsahem na základě analýzy obsahu a na základě pravidel, které vytvoříme. Tedy například najde ve více vstupních zdrojích dat záznamy z jedné domácnosti nebo například záznamy o jednom zákazníkovi, přitom se předpokládá, že ve vstupním souboru dat budou tyto záznamy vícekrát. Unduplicate Match tedy třídí vstupní záznamy do skupin záznamů, které si odpovídají. Třízení probíhá podle výpočtu podobnosti jednotlivých záznamů, který se ovlivní nastavením váhy jednotlivým sloupcům záznamu, které jsou později porovnávány mezi sebou. Tyto váhy se vytvářejí ve specifikace pro porovnávání duplicit viz. dále. Důležité je tedy, že párování záznamů není pouze jednoduchá shoda na všech sloupcích řádků, ale heuristická analýza dat. Když komponenta najde dva identické záznamy, vybere z nich master záznam, tedy záznam, který v rámci skupiny duplicitních záznamů má nejvyšší váhu. Tento záznam je asociován se skupinou svých odpovídajících duplicitních záznamů a poslán na jeden z výstupů komponenty. Dalšími výstupy jsou záznamy na plnou shodu, residuální (neduplicitní) záznamy a záznamy pro ruční vytřízení, tedy záznamy u kterých si systém není jistý, jestli jsou duplicitní nebo ne. Návrh a testování porovnávací specifikace je proces skládající se ze dvou kroků. Prvním krokem je vybrání testovacího souboru dat podle kterého navrhneme kritéria. Tento testovací soubor by měl být pokud možno vybrán ze zdrojových souborů dat tak, aby obsahoval duplicity a především byl reprezentativním vzorkem dat. Druhý krok bude návrh, ladění a testování kritérií a jejich parametrů podle tohoto testovacího vzorku. Survive Tato komponenta z vstupních duplicitních záznamů vybere takové záznamy, které ze skupiny duplicitních obsahují ta nejlepší data. Survive je poslední komponenta, která se používá v IIS workflow pro kvalitu dat a obvykle se spouští po komponentě Unduplicate Match a jako vstup přichází duplicitní záznamy, které jsou setříděny po duplicitních skupinách. V další tabulce je pro ilustraci uveden příklad osoby, která byla na vstupu dvakrát a je potřeba z těchto dvou záznamů vybrat ta nejlepší data. 45

46 Jméno Příjmení RČ Telefon Martin Novák Martin Novák Po komponentě survive zůstane jeden řádek s nejlepšími údaji. Jméno Příjmení RČ Telefon Martin Novák martin@ .cz Takto lze ze skupiny neúplných záznamů pomocí různých pravidel dostat více informací. Definice a testování specifikace pro porovnávání duplicit V komponentách Unduplicate Match, Reference Match a Match Frequency se používají specifikace pro srovnávání záznamů podle rlzných kritérií. Proto pro tvorbu a testování kritérií v IIS existuje v Designeru specializovaný návrhář. Tento návrhář umožňuje navrhnout a otestovat na vzorku dat kritéria pro vyhledávání duplicit a dále umožní ladit jejich parametry. Kvůli možnosti využívat specifikace v různých komponentách v návrháři existuje několik módů, které se liší tím, čeho chceme dosáhnout a co chceme testovat. Ukázka rozložení váhy jednotlivých záznamů v testovacím souboru Pokud budeme chtít testovat, pak je nejdříve potřeba si zvolit výchozí soubor se vzorkem dat. Jako další se nastaví typ srovnávání podle dalšího použití specifikace v komponentách. 46

47 Ve výsledku nám jde o to nastavit váhy záznamů tak, aby byl systém schopen nejlépe určit master záznam, který v dalším workflow půjde do cílového úložiště a odlišit jej tak od duplicitních záznamů. Také je potřeba odlišit, kdy vzniká duplicitní záznam, u které si můžeme být jistí, že se skutečně jedná o duplicitní záznam a kdy se jedná o možný duplicitní záznam a zařadit jej pro další zpracování. Pro takové případy je nutno nastavit minimální a maximální hranici váhy pro oba případy. Kategorie Processing V této kategorii lze nalézt komponenty pro manipulaci se strukturou a obsahem dat. Na rozdíl od komponent datové kvality se zde nepoužívají důmyslné principy, ale spíše postupy, které jsou myslitelné i v běžném SQL. Seznam komponent je poměrně široký - je jich 25 a zde jsou uvedeny jen ty nejdůležitější použité v této práci. Transformer Tato komponenta umožňuje aplikovat jednoduché transformace na jednotlivé sloupečky záznamů, které zpracováváme. Tyto transformace používají jednoduchý jazyk, který nám toho moc neumožňuje, nicméně pro základní operace si s ním bez problémů vystačíme. 47

48 Transformer nám umožní používat více výstupů, každý s jinými transformacemi a posílat do nich data podle jednoduchých pravidel. Komponenta transformer obsahuje vlastní editor. V tomto editoru lze přiřadit vstupní data do výstupu nebo provést operaci se vstupními daty a přiřadit výsledek této operace na výstup. Jazyk pro výrazy je spíše velmi jednoduchý. Následuje několik ukázek toho, jak mohou jednoduché výrazy vypadat. If ToUpdateBirthDate.birthDate = StringToDate(" ") Then If Len(ToUpdateBirthDate.birthNumber) = 10 Then If StringToDecimal(Left(ToUpdateBirthDate.birthNumber,1)) >= 1 Then If Right(Left(ToUpdateBirthDate.birthNumber,3),1) = "5" Then StringToDate("19" : Left(ToUpdateBirthDate.birthNumber, 2) : "-0" : Right(Left(ToUpdateBirthDate.birthNumber,4),1) : "-" : Right(Left(ToUpdateBirthDate.birthNumber,6),2)) Else If Right(Left(ToUpdateBirthDate.birthNumber,3),1) = "6" Then StringToDate("19" : Left(ToUpdateBirthDate.birthNumber, 2) : "-1" : Right(Left(ToUpdateBirthDate.birthNumber,4),1) : "-" : Right(Left(ToUpdateBirthDate.birthNumber,6),2)) Else StringToDate("19" : Left(ToUpdateBirthDate.birthNumber, 2) : "-" : Right(Left(ToUpdateBirthDate.birthNumber,4),2) : "-" : Right(Left(ToUpdateBirthDate.birthNumber,6),2)) Else If Right(Left(ToUpdateBirthDate.birthNumber,3),1) = "5" Then StringToDate("20" : Left(ToUpdateBirthDate.birthNumber, 2) : "-0" : Right(Left(ToUpdateBirthDate.birthNumber,4),1) : "-" : Right(Left(ToUpdateBirthDate.birthNumber,6),2)) Else If Right(Left(ToUpdateBirthDate.birthNumber,3),1) = "6" Then StringToDate("20" : Left(ToUpdateBirthDate.birthNumber, 2) : "-1" : Right(Left(ToUpdateBirthDate.birthNumber,4),1) : "-" : Right(Left(ToUpdateBirthDate.birthNumber,6),2)) Else StringToDate("20" : Left(ToUpdateBirthDate.birthNumber, 2) : "-" : Right(Left(ToUpdateBirthDate.birthNumber,4),2) : "-" : Right(Left(ToUpdateBirthDate.birthNumber,6),2)) Else ToUpdateBirthDate.birthDate Else ToUpdateBirthDate.birthDate Výraz pro extrakci data narození z rodného čísla 48

49 Editor výrazů v komponentě Transformer Lookup Tato komponent slouží k dohledávání sloupečků v dalších vstupech podle klíče. Pro každý vyhledávací vstup je možné vytvořit podmínku, jestli se bude v tom vstupu vyhledávat. Záznam bude vypuštěn do linky pro chybové záznamy, pokud se nenajde v některém z vyhledávacích vstupů záznam odpovídající množině vyhledávaných informací. Jako příklad si můžeme vzít vyhledávání krajů podle poštovního směrovacího čísla a v dalším kroku se směrovací číslo doplní podle toho, jestli bylo nalezeno nebo ne. Příklad komponenty lookup Sort Komponenta sort slouží k setřízení dat v příchozím kanálu. Na vstupním kanálu každé komponenty lze sice také seřadit data, sort ale proti tomuto základnímu řazení poskytuje 49

50 rozsáhlejší možnosti. Někdy je také vhodné také Sort explicitně používat, pokud chceme zdůraznit fakt, že od některé části procesu jsou data již seřazená. U Sortu lze pro řazení zíznamů používat více klíčů. To znamená, že definujeme první (primární) klíč pro řazení, dále druhý (sekundární), atd. Pokud budou dva záznamy v primárním klíči stejné, tak se použije klíč sekundární a podobně se postupuje dále. Funnel Komponenta Funnel slouží ke zkopírování vstupních dat z více vstupů do jednoho výstupu, tedy ke zkombinování všech příchozích dat. Struktura dat na všech vstupech musí být stejná. Remove Duplicates Tato komponenta odstraní duplicitní záznamy ze vstupu a zapíše výsledek, tedy záznamy bez duplicit, na výstup. Jako vstup slouží seřazená posloupnost záznamů podle klíče, který identifikuje duplicitní záznamy. Není to samé jako workflow quality stage, které používá heuristicky k označení duplicit, ale porovnává záznamy podle klíče. Copy Komponenta Copy zkopíruje data ze vstupu na vícero výstupů. Kategorie Real-time V této kategorii jsou obsaženy komponenty, které umožňují procesům v IIS se chovat jako webové služby. Z této kategorie byly použity komponenty WSID Input a WSID Output, tedy komponenty pro komunikaci přes SOAP a EJB. IIS ještě podporuje připojení a spouštění úloh JMS. Real-time zpracování Před tím, než se budou moci jednotlivé procesy spouštět vzdáleně, je potřeba v nich nastavit podporu pro spouštění více instancí a podporu pro nasazení jako web services. Dále je potřeba v aplikaci Information Server Console vytvořit novou aplikaci, která zprostředkuje interakci mezi IIS a okolním světem. Tato aplikace bude JEE aplikace, která bude přijímat SOAP (EJB, JMS) požadavky a přes interní protokol bude dále komunikovat s Information Serverem. Aplikace poběží na stejném WebSphere aplikačním serveru jako IIS. Celá tato aplikace bude spravovaná IIS Console - od vygenerování aplikace podle parametrů zadaných uživatelem po deployment. Procesy v IIS mohou být z pohledu stylu práce rozděleny do tří typů. Dávkové procesy Tyto procesy jsou klasické dávkové procesy, které se spouští, když chceme transformovat data z jednoho zdroje do druhého. Předpokládá se, že data zpracovávaná těmito procesy se budou 50

51 zpracovávat pouze jednou a dále, že poběží maximálně jedna instance těchto procesů. Dávkové procesy jsou spouštěny administrátorem nebo jiným oprávněným uživatelem a nikde nereportují výsledek spuštění. Dávkové procesy s výstupem do klientské aplikace Tyto procesy jsou stejné jako dávkové procesy, ale mohou se spouštět vzdáleně z aplikací. Tyto procesy jsou určené k dávkovému zpracování velkého množství dat. Nemohou sice ze vzdálených systémů, které je spouští, přijímat žádné požadavky, ale mohou jim vracet hodnoty. Procesy se vstupem a výstupem do klientské aplikace (real-time) Tento typ procesů je vhodný pro zpracování real-time požadavků. Počítá se s mnoha malými požadavky, tedy s opakem k dávkovým procesům, které spouští jeden požadavek na hodně datech. Jako příklad můžeme uvést situaci, kdy si klient nechá standardizovat data a po standardizaci chce, aby mu byl vrácen výsledek, což mu může být vráceno jako odpověď přijaté SOAP zprávy. Problémem tohoto typu procesů je, že běží stále, což znamená řadu omezení. Například při každém požadavku může zpracovat pouze data z tohoto požadavku a nemůže zpracovávat data z externích zdrojů - databází. Ještě je potřeba uvést jeden drobný detail a to, že procesy neimplementují a neuvádí rozhraní pro vstup dat, tedy neříkají, že budou implementovat SOAP (nebo EJB, JMS) protokol. Připojení na SOAP protokol musíme definovat externím konektorem, který se na IIS připojí a právě on bude zajišťovat spojení IIS na okolní svět. Tyto procesy běží obvykle ve více instancích. IIS bohužel implementuje real-time procesy jako synchronní, takže klient musí čekat na přímou odpověď, kterou dostane až poté, co proces skončí. 51

52 Implementace konsolidace databází v IBM IS Tato kapitola bude pojednávat o implementaci konsolidace v IBM Information Serveru (IIS) jako ETL procesu. Jak již bylo řečeno v kapitole o IIS, tak celý proces je namodelován v aplikaci Information Server Designer Client a skládá se z několika částí, které se spouští jedna za druhou v závislosti na sobě. Ve stručnosti je celý ETL proces implementován takto. Testovací data jsou uložena v textových souborech, proto prvním krokem je nahrátí testovacích dat do databází klientů banky a hypoték, dalším krokem je extrakce dat z těchto databází do interního úložiště ETL systému. Na těchto datech je poté provedena standardizace, jsou zbaveny duplicit a v posledním kroku jsou nahrány do cílového úložiště a zdrojové databáze jsou aktualizovány. Popišme si nejdříve zdrojová data, dále cílovou databázi a poté podrobněji jednotlivé kroky. Zdrojová data Zdrojová data jsou získávána ze zdrojových databází. Tyto zdrojové databáze jsou základem pro systém banky a systém hypoték. Ze zdrojových databází jsou ETL procesem používány pouze tabulky, které obsahují informace o klientech. Ostatní tabulky jsou systémem přehlíženy. Databáze banky je v tomto případě postavena nad databázovým serverem MySQL. Je pravdou, že MySQL není databáze, která by se typicky používala pro takto důležitá data, ale cílem bylo, aby obě zdrojové databáze běžely na jiných systémech a díky relativně snadné dostupnosti byla vybrána MySQL. Konkrétní verze MySQL na testovacím systému je 5.1. Databáze hypoték je běží nad databázových strojem IBM DB2 Enterprise, verze 9.5. Na testovacím systému je tento databázový stroj sdílen s interními databázemi Information Serveru. Ještě je potřeba doplnit poznámku, že testovací data jsou ale prvotně vytvořena v textových souborech, která se až poté nahrávají do zdrojových databází. Struktura zdrojové databáze hypoték Zde je ukázána struktura tabulek používaných ETL procesem ze zdrojové databáze hypoték. Přestože má databáze hypoték v aplikaci více tabulek, tak zde jsou uvedeny jenom dvě, které jsou pro nás zajímavé a které jsou importované a používané v procesu konsolidace dat - tabulky CLIENT a CITY. 52

53 Zjednodušené schéma tabulek z databáze hypoték použité ETL procesem Struktura zdrojové databáze banky Ze zdrojové databáze bankovního systému jsou v ETL procesu použity tabulky CLIENT a ADDRESS. Zjednodušené schéma tabulek databáze použité ETL procesem Cílová struktura úložiště Cílová struktura úložiště bude obsahovat korektní data s omezeními jak integrity tak hodnot samotných tak, aby byly jednotlivé hodnoty dále nedělitelné. Tabulky, které bude cílové úložiště obsahovat jsou CLIENT, ADDRESS. 53

54 Schéma cílového úložiště Problémy s daty Pokud se podíváme na zdrojové tabulky ze kterých čerpáme data, tak je jisté, že už samotný návrh tabulek není ideální. Je tomu tak schválně, aby byl vidět proces transformace dat nad různými strukturami tabulek a nad různými strukturami dat, které mohou obsahovat chyby. Mezi nejzákladnější problémy patří: 1. nesouhlas povolených nulových hodnot. 2. nesouhlas data narození a rodného čísla 3. nesouhlas PSČ a adresy 4. chybějící položky v datech 5. špatné formátování položek Zdrojová data v reálných systémech mohou a určitě budou obsahovat i další chyby, záleží na obsahu dat. Jejich detekce odstranění závisí především na možnostech jejich detekce z reálných dat a na přístupu k nim nebo k jejich vzorku, které by bylo možné prozkoumat. ETL proces ETL proces implementovaný v Information Serveru se skládá z několika podprocesů, které vždy vykonávají jednu určitou věc a které se mohou spouštět samostatně jeden po druhém a v celku transformují data ze zdrojových databází do cílových databází. Aby se všechny procesy nemusely spouštět ručně jeden po druhém, tak byly poskládány dohromady v jednu sekvenci procesů. 54

55 Sekvence prosesů Sekvence procesů se postupně skládá z těchto činností. 1. Nahrátí zdrojových dat do interních databází Information Serveru 2. Standardizace dat 3. Odstranění duplicitních dat 4. Nahrátí dat do cílové databáze 5. Update odkazů na záznamy z cílového úložiště ve zdrojových databázích Jednotlivé kroky budou postupně popsány v následujícím textu. Nahrání dat z databáze do úložiště IIS V testovacím systému se testovací data zadávají do textových csv souborů, proto celkový proces se nahrátí dat do ETL systému skládá z jednoho kroku navíc - nahrátí testovacích dat z textových souborů do ETL systému, který v reálném systému samozřejmě není potřeba. Nahrátí dat ze zdrojových systémů se tedy skládá z těchto kroků. 1. Nahrátí testovacích dat do databáze banky a databáze hypoték 2. Nahrátí dat z databáze banky a databáze hypoték do interní databáze Information Serveru. Testovací data klientů hypoték jsou umístěny ve dvou textových souborech v CSV formátu. Jeden obsahuje seznam měst a druhý obsahuje seznam klientů banky. Jako první se nahrají data měst do tabulky CITY. 55

56 Nahrátí měst z testovacích dat do databáze hypoték Dalším spuštěným procesem je nahrátí klientů. Tento proces je komplikovanější, protože musí dohledat názvy měst v databázi hypoték. Nahrátí klientů z testovacích dat do databáze hypoték Nahrátí dat z testovacích souborů do databáze banky se ukázalo jako komplikovanější. Problémem, který nastal byla nekompatibilita ODBC ovladačů pro MySQL s Information Serverem. Jako náhradní řešení proto byl napsán jednoduchá Java program, který nahraje data z testovacích souborů do MySQL databáze přes JDBC. Tento program se spouští přímo v sekvenci procesů celé transformace. Jako další krok se spouští načtení dat ze zdrojových databází do interního datového úložiště Information Serveru. Tento krok již není testovací, ale je první, který by byl použit na případném produkčním systému. Data z databáze hypoték jsou načítány přes ODBC ovladač. Data z databáze banky jsou opět načítány externím programem. Tento externí pomocí program byl napsán v Javě a přes JDBC ovladač se připojuje k databázi banky a přes přes standardní výstup předává data další komponentě Information Serveru. 56

57 Diagram nahrátí dat z externích zdrojů do Information Serveru Spojení dat do jednoho souboru nám umožní provádět další operace jako standardizaci a odstranění duplicit nad jedním schématem a najednou a tudíž ušetří práci jak při návrhu, tak při zpracování. Záznamy z obou databází jsou ale od sebe odlišeny ve sloupcích mortid a bankid, které obsahují zpětné identifikátory sloupců v databázi hypoték a databázi banky. Následuje tabulka se sloupečky výstupních dat. Sloupec name birthnumber address address2 zip cityname birthdate phone mortid bankid Typ NVARCHAR(100) NVARCHAR(10) NVARCHAR(255) NVARCHAR(255) NVARCHAR(5) NVARCHAR(64) NVARCHAR(50) DATE NVARCHAR(20) INTEGER INTEGER 57

58 Standardizace V tomto procesu jsou provedeny transformace dat - standardizace a dohledání chybějících nebo nesprávných údajů o adrese klienta a další drobné opravy dat. Standardizace dat Jako první krok je provedena standardizace dat. Data jsou zde vyčištěna od drobných chyb. Dále jsou z klientova jména získány křestní jméno, příjmení a titul, z adresy ulice, a číslo popisné domu, z města informace o městu, popř. městské části. Ke standardizaci byly použity standardní pravidla standardizace pro Češtinu dodávané s Information Serverem. Standardizační pravidla jsou sice k Information Serveru k dispozici, nicméně je třeba mít na mysli, že se určitě vyskytnou údaje, kdy tato pravidla nebudou dostatečná a bude je třeba ručně do standardizačních pravidel doplnit. Po standardizaci se také odstraní nulové hodnoty ve všech sloupcích a místo nich se na jejich místo doplní prázdné řetězce. V dalším kroku proces zjistí, jestli je v klientově záznamu vyplněno město a potom jej zkusí vyhledat z předem připraveného seznamu měst. Pokud je město vyplněno, proces pošle záznam do dalšího kroku. V stage Zip_lookup systém vyhledá PSČ města podle ulice a města a v následujícím transformačním kroku tyto údaje vyplní jako PSČ podle toho, jestli našel PSČ v našem předpřipraveném seznamu nebo ne. Je třeba si uvědomit, že pokud nebudeme mít v doplňkové databázi ulic dostatečný počet ulic pokrývající celou lokalitu, ze které budeme mít klienty, tak tento krok nebude mít žádnou účinnost. 58

59 V posledním kroku totho procesu se, pokud máme údaj rodného čísla, vyplní správné datum narození podle rodného čísla. Ve výstupních datech přibudou záznamy, které začínají std_. V nich jsou umístěna standardizovaná data. Dále byl zaveden nový záznam blocking, který využijeme v dalším kroku, tedy ve vyhledávání duplicitních záznamů definuje velikost prostoru, který je třeba prohledat. Toto je sice v tuto chvíli, kdy máme malinkou databázi, neužitečná informace, ale využije se při velkých objemech dat, kdy zaručuje zrychlené zpracování procesech tím, že prohledávané údaje rozdělí do množin. V následující tabulce je seznam sloupců záznamů vycházejících z procesu standardizace. Žádný z odchozích sloupců nebude obsahovat nulové hodnoty dat. Sloupec name birthnumber address address2 zip cityname birthdate phone mortid bankid std_title std_first_name std_last_name std_addr_type std_street std_house_no std_house_no_ext std_zip std_city std_city_ext blocking Datový typ NVARCHAR(100) NVARCHAR(10) NVARCHAR(255) NVARCHAR(255) NVARCHAR(5) NVARCHAR(64) NVARCHAR(50) DATE NVARCHAR(20) INTEGER INTEGER NVARCHAR(20) NVARCHAR(25) NVARCHAR(50) NVARCHAR(20) NVARCHAR(50) NVARCHAR(10) NVARCHAR(10) NVARCHAR(6) NVARCHAR(50) NVARCHAR(30) INTEGER 59

60 Frekvenční analýza dat Frekvenční analýza dat je potřeba pro proces odstranění duplicit a pro vytvoření specifikace pro odstraňování duplicit. Podoba tohoto procesu je velmi jednoduchá. Načtou se data vzniklá standardizací obou původních databází, ta se předají komponentě Frequency Analyzer, která zapíše na výstup frekvenční analýzu dat. Frekvenční analýza dat Odstranění duplicit V tomto kroku se odstraní duplicitní záznamy, které se vyskytují v datech. Neděje se tomu ovšem tak, že by se porovnávaly jednotlivé řádky, protože takto může spousta duplicitních záznamů uniknout, ale používá se komponenta Unduplicate Match. Tato komponenta rozpozná duplicitní údaje podle pravidel, které byly před tím vytvořeny a rozešle vstupní data po skupinách do několika výstupů podle toho, jestli v datech pozná duplicitní údaje nebo ne. Master záznamy - záznamy, které mají duplicitní údaje, ale byly vyhodnoceny jako nejdůležitější z dané skupiny duplicitních záznamů. Duplicitní záznamy - tyto záznamy jsou duplicitní k danému master záznamu Jednotlivé záznamy - záznamy, které nemají duplicitu v prohledávaných datech Záznamy pro ruční zpracování - záznamy u kterých si systém není jistý, jestli jsou duplicitní nebo ne. Proto je potřeba ručně tento stav posoudit. Poslední fází tohoto procesu je ponechání pouze nejlepších dat ze skupiny duplicitních záznamů. Tato fáze je samozřejmě spuštěna pouze pokud na záznamech, které jsou vyhodnoceny jako duplicitní. Vše je implementováno v komponentě survive. Sloupečky jsou vybírány vždy z několika záznamů ze skupiny master záznam a duplicity. Sloupečky, které zůstanou zachovány, jsou z nejlepšího záznamu vybraného komponentou unduplicate. Dále jsou uplatňena speciální pravidla pro a telefon, které jsou vybrány jako záznamy, které se nejvíce krát opakují v dané skupině. Jako poslední skupina sloupečků, na které existují specielní pravidla, jsou mortid a bankid, tedy zpětné odkazy na záznamy ve zdrojových databázích, protože potřebujeme získat všechny odkazy na zdrojová data, ne jen odkazy na master záznam. Tyto sloupečky jsou vybírány jako hodnoty větší nebo rovny nule. 60

61 Proces odstranění duplicit Nahrání dat do cílové databáze Předposledním krokem je nahrání dat do cílové databáze. Tato fáze je rozdělena do dvou procesů. V prvním kroku jsou uloženy adresy klientů a v dalším kroku jsou uloženi klienti samotní. První část nahrávání do databáze uloží do databáze pouze adresy. Jako první se spojí data z obou použitelných výsledků odstranění duplicitních záznamů z předchozí části transformace, tedy ze záznamů, které nemají duplicity a ze záznamů, které byly vybrány z více duplicit. Po spojení těchto dvou množin záznamů vznikne jedna množina, kterou dále zpracováváme jako celek. Jako další krok je provedeno setřízení a odstranění duplicitních adres. Zde byla použita jednodušší komponenta pro odstranění duplicit, protože adresy jsou zde totiž definovány zcela jednoznačně. Detailní postup je tedy vytvoření jednoznačného klíče ze všech záznamů adresy, setřízení všech údajů podle tohoto klíče a dále odstranění stejných řádků. Jako poslední krok je nahrátí adres do tabulky ADDRESS v novém úložišti. K tomuto je použita stage ODBC connection, která data nahraje přes ODBC ovladač. 61

62 Uložení adresy do DB2 Další proces je nahrátí samotných klientů. Na začátku nahrávání jsou již v novém úložišti uloženy všechny použité adresy. Jako první se opět spojí obě množiny dat z kroku pro odstranění duplicit, tedy přežiší duplicitní záznamy. V dalším kroku se doplní do dat cizí klíče, které identifikují záznamy v databázi adres. Použije se tedy opět Lookup stage, která se bude dotazovat v tabulce adres přes ODBC na id adres a bude je doplňovat do průběžně zpracovávaných záznamů. Uložení klienta do cílového úložiště Aktualizace odkazů ve zdrojových úložištích Jako poslední krok jsou aktualizovány odkazy v cílových úložištích. Pro databázi hypoték byl v Information Serveru vytvořen proces, který aktualizuje příslušné sloupečky. 62

63 Aktualizace odkazů do nového úložiště Pro databázi banky byla opět vytvořena jednoduchá Java aplikace, která aktualizuje zpětné odkazy. Tato aplikace je spouštěna na konci sekvenčního ETL procesu. 63

64 Aplikace Jako demonstraci, jak by mohla transformace dat a následné napojení existujících aplikací vypadat, byly vytvořeny dvě ukázkové aplikace, dále real-time transformační proces v IBM Information Serveru. Jako poslední byla vytvořena webová aplikace pro kontrolu záznamů a obsahu databází. Obě aplikace byly nejdříve napsány tak, aby spolupracovaly pouze se stávajícími databázemi a poté byly minimálně modifikovány tak, aby spolupracovaly s IBM Information Serverem, předávaly mu modifikovaná data pro vyčištění a další zpracování. IIS po vyčištění a restrukturalizaci data vrátí zpět do aplikace, která se postará o jejich uložení do cílové databáze, kterou mohou využívat nové systémy a kde bude garance toho, že data jsou správná a neobsahují chybné údaje. Obě aplikace jsou svým zaměřením z bankovní sféry, která je častým klientem čištění a transformací dat. První z aplikací je systém pro správu hypoték a druhá aplikace je systém pro správu klientských účtů v bance. Obě aplikace včetně databází jsou zjednodušeny a implementují pouze ty části a funkce, které obsluhují uživatelské účty. Aplikace tedy nelze v žádném případě považovat za vhodné k reálnému nasazení, ale slouží jenom jako demostrace toho, jak napojit stávající systémy na real-time procesy Information Serveru. Databáze nad kterými aplikace běží také nejsou vhodnou ukázkou toho, jak by měly vypadat. Nevhodnost není dána pouze nevhodnou strukturou, ale také chybnými daty. Špatná struktura databází pro daný účel je ale záměrná, protože jen takto lze demostrovat některé vlastnosti čištění a transformací dat a také proto, že se v praxi dá velmi často setkat s takovými nevhodnými návrhy databází. Aplikace pro správu hypoték První ukázková aplikace je systém pro správu hypoték. Kvůli jednoduchosti byly v systému implementovány pouze funkce, které zajišťují manipulaci s klienty a jednoduché operace nad hypotékami. Databáze, která stojí na pozadí, taktéž implementuje pouze část spravující data klientů a jednoduchá data. Aplikace je napsána v Javě jako plug-in do Eclipse Rich Client Platform (RCP). Aplikace využívá několika frameworků a knihoven pro ulehčení práce. Pro komunikaci s databázemi aplikace používá ORM mapování objektů na databázové tabulky podle standardu JPA knihovny Eclipselink. Dále používá pro navázání uživatelského rozhraní na datové objekty z databáze knihovnu Eclipse Databindings, která automaticky nahrává změny uživatelského rozhraní do databázových Java Beans objektů. Pro další komunikaci s Information Serverem přes SOAP protokol byla použita knihovna Apache Axis. Databázový model je jednoduchý a obsahuje data o klientovi, dále informace o hypotéce v tabulce mortgage. Každá hypotéka obsahuje několik plateb postupně, jak klient hypotéku splácel. Tento fakt je zanesen v tabulce payment. Tabulka product slouží jako číselník produktů hypotečního ústavu. 64

65 Schéma databáze hypoték Díky využití JPA se práce s databází se mnohem zjednodušila, protože se data z databáze automaticky načítají do Java Beans objektů jazyka Java a stejně to platí zpět do databáze. Knihovny implementující tento standard generují většinu potřebných dotazů automaticky a jen občas je potřeba ručního vytvoření dotazu ve specializovaném jazyce JPQL podobném SQL, který se dotazuje na objekty místo na tabulky a který je následně knihovnou Eclipselink do SQL převeden. Class diagram datového modelu je uveden na následujícím obrázku a význam jednotlivých entit je stejný jako u databáze. 65

66 City cityid : int name : String Payment amount : float date : Timestamp paymentid : int 1 0..* Client 0..* clientid : int name : String birthnumber : String address : String address2 : String zip : String String newid : int 1 0..* 1 Mortgage mortgageid : int amountlended : float lastupdate : Timestamp 0..* 1 Product name : String productid : int Class diagram modelu uloženého v databázi Uživatelské rozhraní, jak bylo uvedeno na začátku užívá platformy Eclipse RCP. Tvoří jej dvě okna - seznam klientů a okno pro úpravu klienta, kde lze zadávat osobní údaje klienta, dále mu přidělovat hypotéky a zadávat jeho platby. Jako poslední bylo vytvořeno okno pro konfiguraci spojení s datovými zdroji včetně otestování funkčnosti těchto zdrojů. Změny provedené v aplikace pro komunikaci s novým úložištěm jsou popsány v příští kapitole. Systémové požadavky, instalace a spuštění aplikace Java 1.5. Operační systém podporovaný Eclipse Platform Windows, Linux, Mac OS X a další. Databázový server IBM DB2. Poznámka - předpřipavená aplikace je k dispozici pouze pro MS Windows. Pro ostatní operační systémy je potřeba sestavit novou distribuci z Eclipse Rich Text Platform. Pro instalaci aplikace je potřeba nahrát DDL příkazy do databáze, které jsou umístěny v SQL souboru v kořenovém adresáři aplikace. Dále je třeba v aplikaci nakonfigurovat JDBC parametry pro spojení s databází. Aplikace samotná je dále spustitelná bez nutnosti instalace. Aplikace pro správu klientských účtů banky Aplikace pro správu klientských účtů je jednoduchou ukázkou vytvořenou pro demonstraci. Tato aplikace je vytvořena v prostředí Codegear Turbo C++. Aplikace využívá MySQL jako databázového serveru. S MySQL komunikuje pomocí knihovny libmysql. Nad knihovnou libmysql je postavená jednoduchá vrstva, která zapozdřuje komunikaci s databázemi do objektů v C++. Komunikace s MySQL je implementována ve třídách mysql_connection a mysql_query. V úpravě aplikace pro komunikaci s cílovou databází (DB2) přibily ještě třídy pro komunikaci s ODBC implementované ve třídách odbc_query a odbc_connection. 66

67 class connection boolean auto_commit; virtual query create_query(string sql) virtual query execute_query(string sql) virtual void execute_update(string sql) virtual long last_insert_id() virtual void begin() virtual void commit() virtual void rollback() virtual string escape_string() virtual void close() class query virtual void execute() virtual boolean next() virtual void close() virtual int get_int(int column) virtual long get_long(int column) virtual date get_date(int column) virtual ptime get_ptime(int column) virtual string get_string(int column) class mysql_query : public query class mysql_connection : public connection class odbcl_connection : public connection class odbc_query : public query Class diagram připojení do databáze Na dalším diagramu je uvedeno schéma databáze bankovního systému. Jsou zde uvedeny informace o klientovi v tabulce client, klientova adresa v tabulce address. Jako další je zde tabulka account, která reprezentuje informace o účtu klienta. Jako poslední tabulka je uvedena tabulka transaction, která zahrnuje všechny operace uskutečněné v systému. Schéma databáze banky Na dalším diagramu je vrstva pro manipulaci s modelem aplikace, která je implementována ve třídě model. Tato vrstva pokládá dotazy sql serveru a vytváří objekty podle obdržených odpovědí. 67

68 Podobně jako v aplikaci pro správu hypoték jsou i zde data z databáze v aplikaci uchovávána v jednoduchých objektech s tím rozdílem, že serializace a deserializace z a do databáze je zde provedena ručně. transaction address id : long address : string zip : string city : string 1 1 client id : long name : string phone : string birth_number : string birth_date : date final_id : long account id : long type : string number : string remaining : long * id : long description : string amount : float type : transaction_type source_account : string source_bank : int dest_account : string dest_bank : int variable_symbol : int const_symbol : int s_symbol : int Class diagram datového modelu banky Systémové požadavky, instalace a spuštění aplikace Operační systém Windows, databázový server MySQL. Pro instalaci databáze je potřeba importovat strukturu databáze do MySQL serveru pomocí sql souboru, který je přiložen v kořenovém adresáři aplikace. Aplikace samotná je dále spustitelná bez nutnosti instalace. Je ovšem opět třeba nastavit konfigurační parametry pro spojení do databáze, což lze buď přímo v aplikaci nebo v konfiguračním ini souboru, který je umístěn v adresáři databáze a má stejný název jako aplikace, ale s příponou ini. Aplikace prohlížení a základní manipulaci s novým úložištěm Jako poslední byla vytvořena webová aplikace, která slouží k prohlížení a jednoduché manipulaci s daty z nového úložiště. Tato aplikace také bere v potaz existující úložiště a data vytvořená pro nové úložiště zobrazuje ve spojení s daty ve starých úložištích. Aplikace byla napsána jako webová aplikace v Javě. Aplikace používá MVC vzoru, který rozděluje funkcionalitu aplikace do relativně nezávislých částí. Jako knihovna pro kontroler je použit Stripes Framework, pro zobrazování dat uživateli Apache Velocity a pro ukládání modelu do databáze opět Eclipselink. Datové modely jsou stejné jako ve výše uvedených aplikacích, proto zde nejsou uvedeny a je na ně odkázáno. Aplikace je jednoduchá a obsahuje pět stránek. Prohlížení klientů v cílovém úložišti, v databázi banky, v databázi hypoték, prohlížení adres v cílové databázi. Editaci/vytváření nových klientů v novém úložišti a stávajících úložištích. Poslední implementovanou funkcionalitou je mazání záznamů jak z nového, tak ze starého úložiště. Aplikace je vytvořena jako standardní Java webová aplikace pro Java webové servery. Aplikace byla vyvíjena pro server Tomcat, nicméně je možné ji zprovoznit na jakémkoliv Servlet

69 kompatibilním webovém serveru. Aplikace je distribuována v podobě standardního war souboru a pro její spuštění je třeba ve webovém serveru vytvořit spojení se všemi databázemi, které aplikace získá ze serveru pomocí JNDI technologie. Následuje ukázka jak definovat napojení na všechny tři databáze v serveru Tomcat. Úpravu je nutné udělat v konfiguračním souboru server.xml, který se nachází v adresáři tomcat/conf. Důležité je, že je potřeba v XML elementech <Resource> měnit pouze atributy username, password a url.... <Context...> <Resource name="jdbc/bankdb" auth="container" type="javax.sql.datasource" username="jmeno" password="heslo" driverclassname="com.mysql.jdbc.driver" url="jdbc:mysql://localhost/bank" /> <Resource name="jdbc/mortdb" auth="container" type="javax.sql.datasource" username="jmeno" password="heslo" driverclassname="com.ibm.db2.jcc.db2driver" url="jdbc:db2://localhost:50000/mortgage" /> <Resource name="jdbc/finaldb" auth="container" type="javax.sql.datasource" username="jmeno" password="heslo" driverclassname="com.ibm.db2.jcc.db2driver" url="jdbc:db2://localhost:50000/final" /> </Context>... Kód definice spojení s databázemi v Tomcatu Instalace aplikace do Tomcatu zpravidla spočívá v nakopírování war souboru do adresáře tomcat/webapps. 69

70 Úprava aplikací pro použití s Information Serverem Aplikace musely být samozřejmě, jak již bylo dříve uvedeno, upraveny pro použití s Information Serverem a využití nového úložiště klientů. V této kapitole bude popsáno, jakým způsobem byly ukázkové aplikace napojeny na IIS a na nové úložiště klientů. Dále jsou zde popsány real-time procesy v Information Serveru. Přestože by bylo ideální použít ESB middleware pro komunikaci s IIS, tak kvůli časové náročnosti byla tato fáze nahrazena jednodušší přímou komunikací s Information Serverem přes SOAP protokol a přímou komunikací s cílovou databází. Aplikace tedy přímo volá standardizaci a vyhledávání duplicit dat pomocí IIS. Následně aplikace uloží data vrácená IIS přímo do cílové databáze. Schéma je nakresleno na následujícím sequence diagramu. /class TClientForm /class iis_service /class final_model - cílové úloziste /class model - úloziste aplikace /Information Server standardize() standardizovaný klient unduplicate() prepare_for_unduplicate() vlozi klienta do docasne tabulky pro IIS proces soap_unduplicate() vrátí unikátního klienta clean_after_unduplicate() smaze klienta z docasné tabulky unikátní klient update_client() ulozi klienta do noveho uloziste update_client() ulozi klienta do stavajiciho uloziste update_client() aktualizuje odkaz na klienta ze stavajiciho uloziste Sequence diagram ukládání klienta s využitím Information Serveru Podrobněji k předchozímu diagramu. Tento diagram je, až na názvy metod, které jsou zde použity z bankovní aplikace), stejný jak pro bankovní aplikaci, tak pro hypoteční aplikaci. Diagram znázorňuje uložení klienta do databáze. Klientská aplikace tedy nejdříve data standardizuje. Dále je provedena funkce unduplicate, ale to jen v případě, že se do systému ukládá nový klient. Vyhledání duplicit nejdříve uloží data do dočasné tabulky pro proces unduplicate Information 70

71 Serveru, dále zavolá SOAP funkci unduplicate a jako poslední krok odstraní dříve přidaný řádek z dočasné tabulky. Aplikace dále uloží data o klientovi do nového úložiště a poté do stávajícího úložiště. Pokud se jedná o nového klienta, potom aplikace aktualizuje záznam o klientovi v novém úložišti. Pro implementaci SOAP komunikace v aplikaci pro správu hypoték byla použita knihovna Apache Axis. Komunikace s cílovou databází probíhá pomocí knihovny Eclipselink. V aplikaci pro správu bankovních účtů se k SOAP komunikaci využívá knihovna gsoap a pro komunikaci s cílovou databází ODBC ovladač DB2. Implementace real-time transformace Standardizace a odstranění duplicit je v ukázkových aplikacích implementováno jako proces webové služby IIS. Tento proces je spouštěn přes SOAP protokol. Standardizace je používána při jakékoliv změně klientských údajů, zatímco odstranění duplicit pouze při vkládání nových klientů. Oba real-time procesy jsou, až na vstupní a výstupní rozhraní stejné jako procesy pro dávkové zpracování dat, tedy proces standardizace a odstranění duplicit. Proces standardizace Při standardizaci se provádí opět tři kroky. Jako první proběhne standardizace dat, tedy rozdělení jména, adresy a města na atomické elementy jako titul, křestní jméno, příjmení, název ulice, číslo domu, číslo popisné, název města, název čtvrti. Dále jsou dohledány případně chybějící údaje o názvu města a PSČ. A v posledním kroku jsou doplněny špatné data narození podle rodných čísel. Proces standardizace pro real-time procesy 71

72 Proces odstranění duplicit Proces odstranění duplicit je až co se týče zpracování duplicitních dat také podobný dávkovému procesu. Hlavní rozdíl je v komunikaci s externími zdroji dat. První rozdíl je, že je tento proces typu, kdy nemůže přijímat vstup ze SOAP protokolu, ale může volajícímu vracet výsledek. To také znamená, že se proces chová jako normální, na dálku spouštěný dávkový proces se všemi svými výhodami a nevýhodami, tedy že neběží pořád a před během se musí nastartovat. Toto je problematické místo, protože start a běh tohoto procesu trvá přibližně 2 až 3 minuty, po které musí uživatel čekat. Důvod, proč proces musí být spouštěn takto je, že kdyby proces běžel pořád tak jako je tomu u real-time standardizace, nemohl by opakovaně číst data z databáze, takže by komponenta unduplicate neměla možnost přijatý klientský záznam porovnávat s databází. Další rozdíl je, že pro porovnávání záznamů čerpá data přímo z cílového úložiště klientů a data pro porovnání dostane z tabulky UNDUPPROC z cílové databáze, která slouží výhradně pro předávání dat procesu. Aplikace tedy před použitím procesu unduplicate musí uložit záznam, který chtějí ověřit do databáze. Proces dostane odkaz na řádek z parametru SOAP příkazu. Unduplicate proces tedy v první fázi načte data z externích zdrojů, tedy id záznamu z parametru procesu, který je předán v SOAP protokolu, podle kterého načte požadovaného klienta z cílové databáze z tabulky UNDUPPROC. Jako další načte všechny záznamy z cílové databáze klientů. Před detekcí duplicit se provedou některé drobné transformace dat jako identifikace, jestli je záznam z existujících klientských dat. Dále tento proces identifikuje duplicitní údaje. Pokud proces identifikuje duplicitní údaje, tak komponenta Survive ze skupiny duplicitních údajů vybere ty nejlepší data. V posledním kroku (Residual_transformer a Survive_transformer) proces odfiltruje záznam, který byl přijat přes SOAP protokol a odešle jej na výstup. Real-time proces odstranění duplicitních záznamů 72