DATENINTEGRATION // INTEGRATIONSANSÄTZE // BEISPIELSZENARIEN // PROBLEMLÖSUNGEN // TALEND OPEN STUDIO. EXTRA: Mit kostenlosem E-Book

ines ROSSAK (Hrsg.) DATENINTEGRATION // INTEGRATIONSANSÄTZE // BEISPIELSZENARIEN // PROBLEMLÖSUNGEN // TALEND OPEN STUDIO EXTRA: Mit kostenlosem E-Book

Rossak (Hrsg.) Datenintegration E-Book inside. Mit folgendem persönlichen Code erhalten Sie die E-Book- Ausgabe dieses Buches zum kostenlosen Download. Registrieren Sie sich unter www.hanser-fachbuch.de/ebook inside und nutzen Sie das E-Book auf Ihrem Rechner*, Tablet-PC und E-Book-Reader. * Systemvoraussetzungen: Internet-Verbindung und Adobe Reader

Ines Rossak (Hrsg.) Datenintegration Integrationsansätze, Beispielszenarien, Problemlösungen, Talend Open Studio Mit 156 Bildern, 15 Tabellen sowie Kontrollfragen und Aufgaben

Die Herausgeberin: Professor Dr. Ines Rossak lehrt und forscht auf dem Gebiet der Datenbanken und Informationssysteme an der FH Erfurt. Die Autoren: Thomas FILBRY studiert im Masterstudiengang Angewandte Informatik an der FH Erfurt. Frank GEYER hat seinen Masterabschluss an der FH Erfurt im Studiengang Angewandte Informatik erworben und gründet derzeit unterstützt von EXIST eine eigene Firma. Matthias LAUFER hat seinen Masterabschluss an der FH Erfurt im Studiengang Angewandte Informatik erworben und arbeitet als IT-ETL-Spezialist sowie Softwareentwickler in Australien. Sebastian RENKER hat nach seinem Studium im Masterstudiengang Angewandte Informatik an der FH seinen Abschluss an der Swinburne University in Melbourne erworben und arbeitet als IT-Security Consultant. Stefan SKOUTI hat seinen Masterabschluss an der FH Erfurt im Studiengang Angewandte Informatik erworben und arbeitet als IT-Specialist in der Internationalen IT eines großen Einzelhandelsunternehmens. Alle in diesem Buch enthaltenen Informationen, Verfahren und Darstellungen wurden nach bestem Wissen zusammengestellt und mit Sorgfalt getestet. Dennoch sind Fehler nicht ganz auszuschließen. Aus diesem Grund sind die im vorliegenden Buch enthaltenen Informationen mit keiner Verpflichtung oder Garantie irgendeiner Art verbunden. Autoren und Verlag übernehmen infolgedessen keine juristische Verantwortung und werden keine daraus folgende oder sonstige Haftung übernehmen, die auf irgendeine Art aus der Benutzung dieser Informationen oder Teilen davon entsteht. Ebenso übernehmen Autoren und Verlag keine Gewähr dafür, dass beschriebene Verfahren usw. frei von Schutzrechten Dritter sind. Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Buch berechtigt deshalb auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften. Bibliografische Information Der Deutschen Nationalbibliothek Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar. Dieses Werk ist urheberrechtlich geschützt. Alle Rechte, auch die der Übersetzung, des Nachdruckes und der Vervielfältigung des Buches, oder Teilen daraus, vorbehalten. Kein Teil des Werkes darf ohne schriftliche Genehmigung des Verlages in irgendeiner Form (Fotokopie, Mikrofilm oder ein anderes Verfahren), auch nicht für Zwecke der Unterrichtsgestaltung mit Ausnahme der in den 53, 54 URG genannten Sonderfälle, reproduziert oder unter Verwendung elektronischer Systeme verarbeitet, vervielfältigt oder verbreitet werden. 2013 Carl Hanser Verlag München Herstellung: Dipl.-Ing. Franziska Kaufmann Coverconcept: Marc Müller-Bremer, www.rebranding.de, München Coverrealisierung: Stephan Rönigk Datenbelichtung, Druck und Bindung: Kösel, Krugzell Printed in Germany ISBN: 978-3-446-43221-5 E-Book-ISBN: 978-3-446-43491-2 www.hanser-fachbuch.de

Vorwort Liebe Leserinnen und Leser, die Idee zu diesem Buch wurde ursprünglich in den Vorlesungen und Seminaren zu analyseorientierten Datenbanken geboren, an deren Konzeption der Aufbau des Buches angelehnt ist. Im Rahmen eines Hauptseminars im Masterstudiengang Angewandte Informatik haben wir fünf uns unter der Leitung von Frau Prof. Dr. Rossak zusammengefunden, um ein Lehrbuch über Datenintegration mit Hilfe der Software Talend Open Studio zu verfassen. Naiv, wie man es vor seinem ersten Buch ist, haben wir, ohne groß zu überlegen, Ja gesagt. Schon in den ersten Wochen zeigte sich aber, dass ein Buch schreiben doch mehr ist als ein typisches Projekt innerhalb des Studiums. Allein die Auswahl des Beispielszenarios verursachte sehr intensive Diskussionen. Wie genau wir unsere Professorin von einer solchen Männerdomäne überzeugen konnten, lässt sich nicht mehr rekonstruieren. Nachdem zumindest der grobe Rahmen des Buches abgesteckt war, begannen wir, in die Welt der Fahrzeugvermietungen einzutauchen, aus der wir unser Beispielszenario ableiten. Preismodelle, Fahrzeugtypen, alles musste so realitätsnah und gleichzeitig so unterschiedlich (und rechtssicher) wie möglich modelliert werden, um den Berg an zu vermittelnden Informationen in ein Szenario pressen zu können, das gleichzeitig komplex und überschaubar genug sein musste. Bald darauf folgte die Überzeugung, dass wir jetzt nur noch integrieren und etwas dazu schreiben müssten. Wer konnte denn ahnen, dass zwischen Szenarioentwurf, Aufbau der Arbeitsumgebung und Erstellen der Beispieldatensätze noch beinahe neun Monate vergehen würden, bis dieses Integrieren und Schreiben abgeschlossen wäre? Schnell wurde deutlich, dass man doch nicht alles bedenkt, wenn ein Beispiel entworfen wird und sich auch bekannte Schwierigkeiten als äußerst komplex erweisen können, wenn Realität auf Theorie trifft. Folglich führten viele Wege doch nur zurück an den Anfang und mussten mehrfach beschritten werden. Dann galt es ja nur noch das Wichtigste aufzuschreiben eine weitere grundlegende Fehleinschätzung der offenen Aufgaben. Eine Welt, die dem eigenen Kopf entspringt, für Dritte verständlich zu beschreiben, stellte sich als diffiziler heraus, als wir es vermutet hatten, vor allem, weil neben der grundlegenden Vorgehensweise eine Software zur Umsetzung dieser mit erklärt werden musste...

6 Vorwort Unzählige stundenlange Meetings, diverse Diskussionen, Stapel an Pizzakartons und literweise Kaffee später ist es nun vollbracht. Wir können hiermit das fertige Buch präsentieren, das wichtige Fragen rund um Datenintegration erklären und typische Fragen beantworten soll. Es hat uns viel Arbeit, Schweiß und Nerven gekostet, aber auch viel Freude bereitet, dieses Buch zu schreiben. Wir sind sehr stolz, ein Buch über Datenintegration als unser Werk betrachten und an Sie weiterzugeben zu können. An dieser Stelle möchten wir auch unser Dankeschön an alle Unterstützer aussprechen. Neben unseren eigenen praktischen Erfahrungen aus Integrationsprojekten sind in dieses Buch zahlreiche Anregungen von Studierenden eingeflossen, die sich im Rahmen von Abschlussarbeiten, Projekten und Praktika mit dem Problem der Datenintegration konfrontiert sahen. Ihnen gilt unser Dank für das ständige Hinterfragen, die Hinweise auf Unstimmigkeiten und Unklarheiten und so manchen Denkanstoß. Bedanken möchten wir uns auch bei allen, die die wichtige und undankbare Arbeit des Korrekturlesens auf sich nahmen, insbesondere Frau Jakob, die uns auf viele Fehler hingewiesen hat. Besonderer Dank gilt Frau Kaufmann, die mit Rat und Tat zur Seite stand, wenn es um Satz und Druck ging. Sie hat einen wesentlichen Anteil am Erscheinungsbild dieses Buches. Besonderer Dank gilt unseren Lektoren, Herrn Dr. Feuchte und Frau Werner, die mit vielen Hinweisen, Geduld und Ruhe das Entstehen dieses Buches begleiteten. Abschließend sei auch den wichtigsten Menschen in unserem Leben gedankt, ohne deren Ermutigung und Unterstützung dieses Buch nicht entstanden wäre unseren Familien. Sie teilten uns fast ein Jahr lang mit Komponenten, Jobs und Schemas und ertrugen unsere Frustration, wenn wieder etwas nicht funktionierte. Noch ein Hinweis zum Schluss: In diesem Buch werden an einigen Stellen geschlechtsspezifische Formulierungen verwendet. An dieser Stelle sei ausdrücklich darauf hingewiesen, dass in einem solchen Fall alle Personen gleichermaßen adressiert werden. Und nun viel Spaß beim Lesen und Integrieren! Thomas Filbry, Frank Geyer Matthias Laufer, Sebastian Renker Stefan Skouti Dezember 2012 Es ist immer ein Wagnis, große, lang laufende und termingebundene Projekte mit Studierenden in Angriff zu nehmen. Das Risiko ist relativ hoch, dass der ein oder andere die Projektgruppe verlässt, weil es nicht einfach ist, sich mit unterschiedlichen Temperamenten, Arbeitstempos und Kommunikationsstilen auseinanderzusetzen und weil Credits auch einfacher zu bekommen sind. Mit entsprechend vorsichtiger Erwartungshaltung ging ich an dieses Projekt heran. Im Laufe der vergangenen Monate bin ich jedoch immer wieder überrascht worden von Studierenden, die sich selbst effektiv organisierten, sich beinahe klaglos durch Hunderte Seiten Literatur kämpften, sich gegenseitig motivierten und härter kritisierten, als ich es je getan hätte. Ich bin beeindruckt, wie sie diese anspruchsvolle Aufgabe bewältigt haben. Ines Rossak Dezember 2012

Vorwort 7 Für Gerhard Max Kuno Möller (*10.05.1931-13.07.2011) Wärd so, wie ich sein müsst, hast du zu mir gesagt. Wenn ich so werde, wie du warst, bin ich zufrieden. - Frank Geyer Für Dr. Jamal Skouti Nur wer gelernt hat, auf eigenen Beinen zu stehen, der kann auch seine eigenen Wege gehen. Mit Unterstützung, auch wenn von weit her, ist selbst der steinigste Weg, nur noch halb so schwer. - Stefan Skouti Für meine Eltern, Großeltern, Freunde und meinen Bruder Danke für die Unterstützung, Rückhalt, Antrieb und Motivation auf meinen langjährigen Bildungsweg. - Matthias Laufer Für meine Eltern Danke für eure Unterstützung. Ihr seid die Besten! Für Stefanie Danke, dass Du immer für mich da warst, mich immer wieder motivierst und es nie langweilig mit Dir wird! - Sebastian Renker Für meine Eltern Die mich die Jahre meines Studiums stets an allen Stellen wo es nötig war unterstützt und gefördert haben. Weiterhin möchte ich allen Kommilitonen danken, mit welchen ich an Projekten gearbeitet oder für Prüfungen gelernt habe. - Thomas Filbry Für Tina Bleib ein Sonnenkind im Leben, wer Sonne hat, kann Sonne geben. Für Willi Ohne dich ist alles doof! - Ines Rossak

Inhaltsverzeichnis 1 Einführung... 13 2 Grundlagen der Datenintegration... 16 2.1 Einleitung... 16 2.2 Typische Anwendungsfelder... 18 2.2.1 Konsolidierung im operativen Bereich... 19 2.2.2 Konsolidierung im analytischen Bereich... 21 2.3 Herausforderungen... 24 2.3.1 Verteilung... 25 2.3.2 Autonomie... 27 2.3.2.1 Entwurfsautonomie... 27 2.3.2.2 Schnittstellenautonomie... 27 2.3.2.3 Kommunikationsautonomie... 27 2.3.3 Heterogenität... 28 2.3.3.1 Technische Heterogenität... 28 2.3.3.2 Syntaktische Heterogenität... 29 2.3.3.3 Strukturelle Heterogenität... 29 2.3.3.4 Semantische Heterogenität... 30 2.4 Integrationsebenen... 31 2.4.1 Integration auf Präsentationsebene... 32 2.4.2 Integration auf Applikationsebene... 34 2.4.3 Integration auf Datenebene... 35 2.5 Integrationsarchitekturen... 37 2.5.1 Extraktion-Transformation-Laden (ETL und ELT)... 37 2.5.1.1 Extraktion... 39 2.5.1.2 Transformation... 39 2.5.1.3 Laden... 40

10 Inhaltsverzeichnis 2.5.1.4 ETL vs. ELT... 41 2.5.2 Enterprise Application Integration (EAI)... 42 2.5.3 Enterprise Information Integration (EII)... 45 2.5.4 Zusammenfassung... 47 2.6 Integrationsaufgaben... 47 2.6.1 Vorintegration... 48 2.6.2 Schema-Integration... 50 2.6.2.1 Korrespondenzen... 50 2.6.2.2 Konflikte... 52 2.6.2.3 Schema-Angleichung... 54 2.6.2.4 Matching... 59 2.6.3 Daten-Integration... 59 3 Marktsituation im Bereich Datenintegration... 61 3.1 Überblick... 61 3.2 Open Source im Bereich Datenintegration... 63 3.2.1 Einleitung... 63 3.2.2 Vor- und Nachteile von Open Source... 64 3.2.3 Anbieter und Produkte... 66 4 Integrationslösungen von Talend... 69 4.1 Talend v5 Plattform... 69 4.2 Datenintegrationslösungen von Talend... 71 4.3 Möglichkeiten von TOSDI... 72 5 Beispielszenario... 75 5.1 Ausgangssituation... 75 5.1.1 AutoMysel... 76 5.1.2 GresNutzfahrzeuge... 76 5.1.3 ExpressCarMobil... 77 5.2 Analyse der Quelldatenbanken... 78 5.3 Ableitung der Transformationsvorschriften... 81 5.3.1 Fahrzeugdaten... 82 5.3.2... 84 5.4 Ableitung der Integrationsreihenfolge... 85 6 Installation und Konfiguration der Beispieldatenbanken... 88 6.1 AutoMysel... 88 6.1.1 Installation und Konfiguration von MySQL... 89

Inhaltsverzeichnis 11 6.1.2 Erstellung und Befüllung der Datenbank... 91 6.2 GresNutzfahrzeuge... 92 6.2.1 Installation und Konfiguration von PostgreSQL... 92 6.2.2 Erstellung und Befüllung der Datenbank... 93 6.3 ExpressCarMobil... 94 6.3.1 Installation und Konfiguration von MS SQL Express... 94 6.3.2 Erstellung und Befüllung der Datenbank... 97 7 Einstieg in Talend Open Studio for Data Integration... 98 7.1 Installation und Konfiguration des Talend Open Studio for Data Integration... 98 7.2 Das erste Projekt... 100 7.2.1 Grundbegriffe TOSDI... 100 7.2.2 Notationen... 101 7.2.3 Ein neues Projekt anlegen... 103 7.2.4 Datenbank-Verbindung einrichten... 107 7.2.5 Tabellen und Daten einbinden... 109 7.3 Der erste Job... 111 7.3.1 Verwendete Komponenten... 111 7.3.2 Der Firmen Lookup-Job... 113 8 Datenintegration mit dem Talend Open Studio for Data Integration. 120 8.1 Integration der... 120 8.1.1 Kundenintegration Einleitung... 120 8.1.2 Der Lookup-Job Kunden... 122 8.1.3 Der Integration-Job Kunden... 126 8.1.4 Der Integration-Job Firmen... 134 8.2 Integration der Fahrzeugdaten... 138 8.2.1 Einleitung... 138 8.2.2 Der Lookup-Job Fahrzeuge... 139 8.2.3 Der Integration-Job Fahrzeugtyp... 142 8.2.4 Der Integration-Job Fahrzeuge_Mysel... 149 8.2.5 Der Integration-Job Preisgruppe_Fahrzeuge_Mysel... 155 8.2.6 Die Fahrzeugdaten von GresNutzfahrzeuge... 160 8.2.7 Exkurs Daten aus dem Internet... 163 8.3 Integration der Anmietung... 166 8.3.1 Einleitung... 166 8.3.2 Der Integration-Job Anmietung_Mysel... 169 8.3.3 Der Integration-Job Anmietung_Gres... 175 8.4 Der übergeordnete Integrationsjob... 177

12 Inhaltsverzeichnis 9 Ausblick... 187 9.1 Exkurs: Import und Export... 187 9.1.1 Import und Export von Projekten... 187 9.1.2 Import und Export von Items... 188 9.2 Social Media Integration mit TOSDI... 190 10 Zusammenfassung... 200 A Anhang... 203 A.1 Schema AutoMysel... 204 A.2 Schema GresNutzfahrzeuge... 205 A.3 Schema ExpressCarMobil... 206 Listingverzeichnis... 207 Abkürzungsverzeichnis... 209 Literaturverzeichnis... 211 Sachwortverzeichnis... 221

1 Einführung Datenkonsolidierung, Datenintegration sowie Verbesserung der Datenqualität sehen mehrere Studien (z. B. von Forrester, Lünendonk, BARC, TDWI u. a.) weiterhin als Top-Thema. In fast allen Unternehmen, Institutionen und Organisationen sind heutzutage enorme Datenmengen in den verschiedensten Anwendungssystemen hinterlegt. Umstrukturierungen, Übernahmen, Unternehmensfusionen oder -teilungen haben vielfach zu einer über die Jahre hinweg historisch gewachsenen, fragmentierten und heterogenen Systemlandschaft geführt, die eine Vielzahl von isolierten und oft auch widersprüchlichen Dateninseln umfasst. Kennzahlen oder Prozesse über Bereichs-, Standortgrenzen oder größere Zeiträume hinweg verlässlich zu analysieren, ist unter solchen Bedingungen extrem aufwendig, da die für den jeweiligen Zweck relevanten Daten nicht nur in unterschiedlichen Systemen, Strukturen und Formaten abgelegt sind, sondern sich darüber hinaus auch hinsichtlich ihrer Aktualität, Detailliertheit, Genauigkeit, Zuverlässigkeit usw. unterscheiden. Die benötigten Daten müssen daher nicht nur identifiziert, sondern im Normalfall auch konsolidiert werden, ehe sie für die unternehmensweite Verwendung zur Verfügung stehen können. Dabei stehen die Unternehmen unter dem wachsenden Druck, immer schneller immer größere Datenmengen, die über immer mehr Kanäle generiert werden, in geschäftskritische Überlegungen einzubeziehen, um z. B. Störungen, Risiken oder auch Chancen zeitnah oder sogar in Echtzeit zu erkennen. In der Praxis stehen daher Integrationsaufgaben in vielen IT-Projekten im Mittelpunkt. Eine Vielzahl von Software-Anbietern stellen dafür Tools bereit, wobei die Spannbreite von kleinen spezialisierten Lösungen für Teilaufgaben bis hin zu Suiten für das Gesamtspektrum von Business Intelligence (Business Intelligence (BI)) reicht. Im kommerziellen Bereich wird der Markt beherrscht durch Produkte von Informatica, IBM, SAS, SAP und Oracle. Deren Systeme bieten einen enormen Funktionsumfang, sind aber auch entsprechend kostspielig. Seit 2008/2009 erobern jedoch auch immer mehr Open Source Lösungen von Anbietern wie Talend, Pentaho, Jaspersoft, Jedox u. a. Marktanteile. Diese Produkte sind nicht nur, aber insbesondere für kleine und mittlere Unternehmen attraktiv, da deutlich geringere Anschaffungs- und Folgekosten anfallen, der Funktionsumfang meist ausreichend ist und sich Anpassungsarbeiten oft durch eigenes Personal bewältigen lassen. Für den akademischen Bereich, insbesondere für informatikbezogene Studiengänge sind Open Source Lösungen aus mehreren Gründen interessant. Zum einen bieten sie eine kostengünstige Möglichkeit, Studierende mit der Architektur und Funktionsweise von Werk-

14 1 Einführung zeugen für die Lösung von Anwendungsproblemen vertraut zu machen, zum anderen können diese Werkzeuge von den Studierenden selbst weiter entwickelt werden. Als problematisch erweist sich allerdings häufig das Fehlen einführender Literatur. Die Hersteller bieten auf ihren Webseiten umfangreiche Dokumentationen zu einzelnen Modulen oder Teilsystemen an, ebenso gibt es Webinare und Tutorials zu speziellen Fragestellungen sowie white paper zu grundlegenden Problemen. All diese Informationen sind jedoch breit gestreut und fast nie wird ein durchgängiges Beispiel von den ersten theoretischen Überlegungen bis hin zur tatsächlichen Datenfusion behandelt. Das vorliegende Buch unternimmt den Versuch, diese Lücke zu schließen und einerseits einen Überblick über die häufigsten Integrationsszenarien und wichtigsten existierenden Integrationskonzepte zu geben, andererseits Anregungen und Impulse für anstehende Integrationsprojekte zu liefern. Dabei sollen und können keine Patentrezepte geliefert werden, wie Integration zu erfolgen hat. Vielmehr geht es darum, ein vertieftes Verständnis für grundlegende Probleme zu entwickeln, die in Integrationsprojekten fast zwangsläufig auftreten und bewährte Vorgehensweisen für deren Lösung kennenzulernen. Neben den theoretischen Betrachtungen stellt die Einführung in die praktische Arbeit mit einem Datenintegrationswerkzeug einen weiteren Schwerpunkt des Buches dar. An einem durchgängigen Beispiel wird ein in der Praxis häufig vorkommendes Szenario die Fusion von bisher unabhängig agierenden Unternehmen mit ähnlichen Geschäftsfeldern, aber unterschiedlichen Datenbasen konsequent von der Analyse bis zur physischen Übernahme der Daten in das Zielsystem durchgespielt. Zum Einsatz kommt dabei ein Open Source-Werkzeug das Talend Open Studio for Data Integration, mit dem die Integration von autonomen, heterogenen Datenquellen Schritt für Schritt bis zur einheitlichen Datenbasis realisiert wird. Bei der Auswahl eines geeigneten Werkzeugs spielten mehrere Überlegungen eine Rolle. Die verwendete Software sollte lizenzkostenfrei zur Verfügung stehen, einfach zu erhalten (download) und ohne größeren Verwaltungsaufwand zu installieren sein ohne größeres Training zu erlernen sowie benutzerfreundlich und intuitiv zu bedienen sein umfangreiche Funktionalitäten und eine gewisse Marktreife besitzen aussagekräftige und umfangreiche Dokumentationen (User Guides, Reference Guides) bereitstellen Diese Merkmale erfüllte das Talend Open Studio for Data Integration aus der Sicht der Autoren am besten. Das Buch richtet sich in erster Linie an Studierende informatikbezogener Studiengänge, die sich im Rahmen von Lehrveranstaltungen zum Daten- und Informationsmanagement mit dem Problem der Integration verteilter Datenbestände befassen. Ebenso geeignet ist das Buch aber auch für technische Consultants oder Projektmitarbeiter, die nach geeigneten Werkzeugen zur Unterstützung bei Integrationsprojekten suchen oder ihre Kenntnisse und Fähigkeiten erweitern, vertiefen oder systematisieren wollen. Aufbau und Methodik des Buches orientierten sich an der Lehrveranstaltung Spezielle Kapitel Datenbanken, die im Masterstudiengang der Angewandten Informatik an der FH Erfurt angesiedelt ist. Kapitel 2 bildet den Kern des theoretischen Teils. Dort werden nach der Einführung in das Thema die Besonderheiten der Integration auf Präsentations-, Applikations- oder Daten-

1 Einführung 15 ebene behandelt und typische Szenarien sowie entsprechende Architekturvarianten beschrieben. Anschließend wird der Versuch unternommen, die Vielfalt der Integrationsansätze und -szenarien auf zwei Kernkonzepte zu reduzieren Fusion bzw. Mapping und eine möglichst allgemeingültige Schrittfolge für eine Integration auf Datenebene abzuleiten. Am Ende des Kapitels werden typische Probleme des Integrationsprozesses aufgegriffen und bewährte Vorgehensweisen für deren Lösung gezeigt. Kapitel 3 gibt einen kurzen Überblick über die Marktsituation im Bereich der Datenintegration im Allgemeinen sowie verfügbare Open Source-Werkzeuge im Besonderen. Kapitel 4 stellt das Portfolio von Talend, insbesondere die verwendete Datenintegrationslösung Talend Open Studio for Data Integration (TOSDI) vor. Als Open Source Lösung bietet diese einige Vorteile, die im Kapitel 4 dargestellt werden. Am Anfang des Kapitels 5 wird zunächst das für das Buch konzipierte Beispielszenario vorgestellt und die fiktiven Unternehmen werden kurz beschrieben. Anschließend werden die vorliegenden Schemas der Quellsysteme analysiert und die Regeln für das Mapping auf das Zielsystem abgeleitet. Die Ableitung der Schrittfolge für die Übernahme der Quelldaten in das Zielsystem bildet den Abschluss des Kapitels 5. Kapitel 6 beschreibt die Installation und Konfiguration der Datenbanksysteme für das Beispielszenario und hilft damit, die verwendete Umgebung auf dem eigenen Rechner nachzustellen. Kapitel 7 führt in die praktische Arbeit mit dem Talend Open Studio for Data Integration ein, zeigt die erforderlichen Installations- und Konfigurationsschritte und die ersten Schritte zur Erstellung eines Projektes. An einem Fallbeispiel aus dem Beispielszenario werden die wichtigsten Begriffe erklärt und gezeigt, wie ein konkreter Integrationsjob erstellt wird. Kapitel 8 ist der Kern des praktischen Teils. In diesem Kapitel wird Schritt für Schritt durch den Prozess der Übernahme der Daten der beiden fiktiven Quellsysteme in das Zielsystem geführt. Entsprechend der in Kapitel 5 abgeleiteten Schrittfolge wird die Datenübernahme in drei großen Teilabschnitten durchgeführt. Dabei werden die verschiedenen Möglichkeiten dargestellt, mit denen das Integrationswerkzeug von Talend diesen Prozess unterstützt. Insbesondere werden die wichtigsten Komponenten und deren Funktionsweise an konkreten Beispielen erklärt. Typische Integrationsjobs können damit einfach nachgestellt werden. Aus der Menge der ca. 600 verfügbaren Komponenten werden diejenigen vorgestellt, die immer wieder und in fast allen Integrationsprojekten benötigt werden. Anhand des Beispielszenarios werden diese Schritt für Schritt eingeführt und die Arbeit mit ihnen demonstriert. Kapitel 9 zeigt, wie bereits fertige Projekte und Jobs für die weitere Verwendung aus TOSDI exportiert werden können und wie man zu integrierende Daten mit Informationen aus externen Quellen wie z. B. sozialen Netzwerken anreichern kann.

2 Grundlagen der Datenintegration In diesem Kapitel wird nach einer kurzen Einführung in das Thema am Beispiel typischer Anwendungsfelder verdeutlicht, dass Datenintegration in einer Vielzahl von Anwendungsfeldern zum Einsatz kommt. Es werden die Herausforderungen beschrieben, die sich ergeben, wenn Datenbestände isoliert voneinander verwaltet, aber gemeinsam ausgewertet werden sollen. Ausgehend vom klassischen Schichtenmodell wird dargestellt, auf welchen Ebenen Integration in Angriff genommen werden kann, welche Architekturen sich dafür bewährt haben und welche Aufgaben zu lösen sind. 2.1 Einleitung Die meisten Unternehmen sind heute durch die Risiken und den Wettbewerbsdruck globalisierter Märkte sowie den Zwängen durch gesetzliche Bestimmungen usw. unter enormen Druck, zeitnah über Ablauf und Ergebnisse aller geschäftlichen Prozesse Bescheid zu wissen. Sie müssen insbesondere Risiken wie z. B. drohenden Zahlungsausfall oder Störungen und Verzögerungen in der Lieferkette durch unzuverlässige oder nicht mehr verfügbarer Zulieferer schnell erkennen können. Ebenso zügig müssen Unternehmen auf geänderte Situationen reagieren können wie z. B. eine plötzliche Nachfrage nach einem bestimmten Produkt, Abwanderung von Kunden, Preisschwankungen auf den Rohstoffmärkten usw. Dies setzt voraus, dass vorhandene, oft über verschiedene Fachabteilungen und Standorte verteilte Datenbestände übergreifend ausgewertet werden können, um eine Gesamtsicht auf die gesamte Wertschöpfungskette zu erhalten. Jedes Unternehmen, jede Institution, jede Organisation verfügt über enorme Datenmengen. In den meisten Unternehmen haben Umstrukturierungen, Übernahmen, Unternehmensfusionen oder -teilungen zu einer über die Jahre hinweg historisch gewachsenen fragmentierten, heterogenen Systemlandschaft geführt, die auch eine Vielzahl von isolierten Dateninseln umfasst. In einem durchschnittlichen Unternehmen ist heute eine kaum noch überschaubare Menge unterschiedlichster Anwendungssysteme im Einsatz, die für bestimmte Geschäftsprozesse oder Aufgabenbereiche optimiert sind. Am häufigsten finden sich naturgemäß Systeme, die Kunden-, Produkt-, oder Lieferanteninformationen enthalten. Diese werden ergänzt durch Lagerhaltungs-, Logistik-, Finanzsysteme und viele andere mehr. Laut einer

2.1 Einleitung 17 IBM-Studie von 2007 [Cor07] sind in einem mittleren Unternehmen etwa 50 unterschiedliche Systeme im Einsatz, eine andere Studie von Accenture verzeichnet bis zu 200 unterschiedliche ERP-Systeme in großen, global agierenden Unternehmen. Informatica spricht sogar von einer regelrechten Anwendungsschwemme [Inf11]. Hinter diesen Systemen liegen in der Regel für den jeweiligen Zweck entworfene und optimierte Datenbanken. Die darin enthaltenen Daten sind häufig redundant, oft sogar aus anderen Systemen repliziert, denn die meisten Geschäftsprozesse benötigen ähnliche oder sogar gleiche Daten. So benötigt das Marketing für Mailingaktionen die Kundenadressen, ebenso die Kundenbetreuung, die Stammkunden mit einer Sonderaktion belohnen möchte. Auch die Logistik, die Waren an Kunden zustellt, muss die Kundenadresse kennen oder die Buchhaltung, die eine Mahnung schicken muss. Eine von Omikron 2010 beauftragte Studie [OMI12], in der 339 Unternehmen zum Umgang mit befragt wurden, kommt zum Ergebnis, dass bei 60 % der befragten Unternehmen zwischen drei und zehn separate banken bestehen. Die Hoheit über diese Daten liegt bei 52 % der Befragten im jeweiligen Geschäftsbereich. Diese Art der isolierten Datenhaltung führt nicht nur zu redundanten, sondern naturgemäß auch widersprüchlichen Daten, da ein Datenabgleich oder -austausch nicht kontinuierlich oder gar nicht stattfindet. Selbst ursprünglich identische Datenbestände beginnen im Laufe der Zeit auseinanderzudriften, wenn sie ohne unternehmensweit geltende Standards autonom verwaltet werden. So entstehen Informationsinseln mit eigenen Strukturen, Kodierungen, Formaten, Standardwerten, semantischen Bedeutungen usw. (siehe auch Abschnitt 2.3). Dazu kommt die ständig weiter wachsende Datenflut durch die zunehmende Zahl von Kanälen, über die Daten generiert werden sowie immer mehr proprietäre Formate. Schätzungen gehen davon aus, dass die Datenbestände um mindestens 50 % pro Jahr wachsen [IDC11]. Andere Schätzungen sprechen sogar von 64 % pro Jahr [Inf11]. Dies macht es oft unerlässlich, einen Teil der Altdaten auszulagern. So werden historische Daten häufig getrennt von operativen Daten für das Tagesgeschäft gespeichert und müssen für Analysen, die größere Zeiträume umfassen sollen, oft mühsam wiederhergestellt werden. Diese Ausgangslage erschwert es, Prozesse über Bereichs- oder Standortgrenzen oder größere Zeiträume hinweg verlässlich zu analysieren, da Daten einbezogen werden, die sich in ihrer Aktualität, Detailliertheit, Genauigkeit, Zuverlässigkeit usw. unterscheiden können. Daraus abgeleitete geschäftliche Entscheidungen sind oft wenig transparent und mitunter nicht nachvollziehbar. Das Risiko falscher Entscheidungen wächst, finanzielle, juristische und Imageprobleme können die Folge sein. So wird z. B. in einer Postwurfsendung ein bestimmter Artikel beworben, der nur kurze Zeit im Angebot ist. Es gab im Vorfeld keine Analyse des Einzugsgebietes und der Kundenstruktur jeder Filiale, daher bekommen alle Filialen die gleiche Anzahl des Artikels. Zum Verkaufsstart tritt die bekannte Situation auf, dass in einigen Filialen der Artikel nach wenigen Minuten ausverkauft ist, in anderen gibt es noch nicht einmal eine Nachfrage. Da es keine zentrale Warenwirtschaft gibt, bleiben in der einen Filiale verärgerte Kunden zurück und in der anderen eine Menge unverkaufter Artikel. Eine Empfehlung für die Kunden, die andere Filiale aufzusuchen oder den Artikel von dort zu beschaffen, gibt es aus Unkenntnis der Situation nicht. Zum entgangenen aktuellen Umsatz kommen möglicherweise zukünftige Umsatzverluste, weil die verärgerten Kunden künftig woanders kaufen. Ähnlich ärgerlich bzw. nachteilig sind fehlgeleitete oder doppelte Sendungen oder nicht zustellba-

18 2 Grundlagen der Datenintegration re Rechnungen, weil es widersprüchliche Adressdaten gibt, Lieferung falscher Artikel, weil Produktdaten unterschiedlich abgelegt sind, mehrfache Beschaffung von Teilen, weil sie im Lager nicht mehr auffindbar sind usw. Ein wichtiger Schlüssel für die Lösung dieser Probleme ist die Konsolidierung und Standardisierung der gesamten IT-Infrastruktur, insbesondere der Datenhaltung. Für große Unternehmen hat das höchste Priorität [Mad09]. Das Kernstück aller Konsolidierungsvorhaben ist die Datenintegration, denn keine Anwendung kommt ohne Daten aus. Die Anwendungsfelder für Datenintegration sind außerordentlich vielfältig und umfassen deutlich mehr Bereiche als nur Data Warehousing. In den folgenden Abschnitten werden daher einzelne Aspekte der Datenintegration näher betrachtet. Der Abschnitt 2.2 betrachtet zwei typische Anwendungsbereiche von Integration Konsolidierung für operative und Konsolidierung für analytische Zwecke. Im Abschnitt 2.3 werden die Herausforderungen beschrieben, die sich aus der Verteilung und Autonomie der Datenbestände ergeben. Im Abschnitt 2.4 wird Integration ausgehend vom klassischen Schichtenmodell betrachtet, d. h. die Betrachtung von Integration auf Daten-, Anwendungs-, bzw. Präsentationsebene. Im Abschnitt 2.5 werden die daraus resultierenden verschiedenen Integrationsarchitekturen beschrieben und gegeneinander abgegrenzt. Im Abschnitt 2.6 werden typische Aufgaben, die bei einer Integration zu lösen sind und eine bewährte Schrittfolge zur Abarbeitung beschrieben. 2.2 Typische Anwendungsfelder Datenintegration wird häufig gleichgesetzt mit Data Warehouse, spielt aber auch in anderen Bereichen des Datenmanagements wie z. B. der Migration von Daten aus Altsystemen, der Replikation und Synchronisation von Daten in redundanten Systemen, dem Datenqualitätsmanagement oder dem Master Data Management eine wichtige Rolle [BAR09]. Zentrale Aufgabe in all diesen Bereichen ist die Konsolidierung der Daten mit dem Ziel, möglichst vollständige, einheitliche und korrekte Datenbestände zur Verfügung zu stellen. Stellvertretend für die vielfältigen Einsatzmöglichkeiten sollen hier einige Anwendungsfelder aus zwei großen Kernbereichen des Datenmanagements herausgegriffen werden die Konsoliderung im operativen Bereich und die Konsoliderung im analytischen Bereich. Im operativen Bereich wird Datenintegration überall dort benötigt, wo operative Daten, die aus verschiedenen Gründen verteilt vorliegen, aus praktischen Gründen in einer Datenbank vereinigt werden sollen. Im analytischen Bereich steht die Auswertung von Daten im Vordergrund mit dem Ziel, einen hohen Grad an Wissen aus den verfügbaren Informationen zu generieren und dieses so aufzubereiten und darzustellen, dass es schnellstmöglich erfasst und für operative und strategische Entscheidungen genutzt werden kann.

2.2 Typische Anwendungsfelder 19 2.2.1 Konsolidierung im operativen Bereich Es gibt verschiedene Ursachen, die eine Konsolidierung von Daten im operativen Bereich notwendig machen. An dieser Stelle sollen drei typische Szenarien kurz dargestellt werden. Fusionierungen und Umstrukturierungen Die Fusion zweier Unternehmen oder Umstrukturierungen innerhalb des Unternehmens sind relativ häufig anzutreffende Szenarien, wenn beispielsweise mehrere Standorte oder Abteilungen existieren, die bisher unabhängig voneinander agierten und aus wirtschaftlichen Gründen zusammengeführt werden sollen oder andere Unternehmen mit den gleichen Kerngeschäften übernommen bzw. strategische Partnerschaften eingegangen werden. Die zu fusionierenden Unternehmen oder Unternehmensteile haben in der Regel historisch gewachsene Datenbanken auf eigenen IT-Systemen, manchmal mit völlig verschiedenen, oft aber mit vergleichbaren Strukturen und Inhalten. Daten Daten Daten BILD 2.1 Fusionierung Eigentlich zusammengehörende Daten liegen oft verteilt und in uneinheitlichen Formaten vor (siehe Abschnitt 2.3). Auch Flatfiles wie Comma-Separated Values (CSV)-Dateien oder Excel-Tabellen, in denen zusätzliche Informationen hinterlegt werden, sind keine Seltenheit. Ziel sollte eine Komplettierung des Datenbestandes sein, so dass alle zusammengehörigen Daten vollständig und einheitlich vorliegen [Sch05], [KR05]. Um die sich aus der Fusionierung ergebenden Synergien effektiv zu nutzen, die IT- Landschaft zu verschlanken und/oder zu homogenisieren, wird fast immer entschieden, die ursprünglichen Systeme nicht parallel weiter zu betreiben. Vielmehr wird entweder eines der Systeme zum führenden System erklärt und die Daten aus dem anderen System werden in dieses überführt oder es wird ein ganz neues Zielsystem definiert, in das die Daten der Altsysteme integriert werden. Ein praxisnahes Anwendungsbeispiel für den ersten Fall wurde für dieses Buch konzipiert und soll später ausführlich behandelt werden. Anwendungsmodernisierung Ein weiteres typisches Szenario ist die parallele Existenz und Nutzung von Neu- und Legacy-Anwendungen (dt. Altlast, Erbe). Im Laufe der Jahre wächst die IT-Landschaft in vielen Unternehmen enorm. Es werden neue Systeme eingeführt, jedoch erscheint es nicht

20 2 Grundlagen der Datenintegration BILD 2.2 Verteilte Daten immer sofort als erforderlich, die Daten bisheriger Programme in die neuen Anwendungssysteme zu integrieren. Da aber in bestimmten Fällen neben aktuellen auch Altdaten benötigt werden, werden Legacy-Anwendungen nicht abgeschaltet, sondern parallel weiter betrieben. Mitarbeiter, die lange im Unternehmen beschäftigt sind, tendieren erfahrungsgemäß ohnehin dazu, bestehende Arbeitsabläufe (und damit oft auch gewohnte Anwendungen) beizubehalten. Dadurch kommt es zu einer Parallelbenutzung von verschiedenen Systemen mit der Gefahr, dass benötigte Daten an verschiedenen Stellen bearbeitet, aber nicht über alle Systeme hinweg konsistent gehalten werden. Fehlende oder widersprüchliche Informationen können die Folge sein. Zudem erhöht sich durch den Parallelbetrieb auch der Wartungs- und Supportaufwand (und damit die Kosten) für die IT-Abteilung. Bei der Einführung von neuen Anwendungssystemen muss deshalb frühzeitig geklärt werden, welche Alt-Systeme abgelöst werden sollen und wie mit den damit verbundenen Datenbeständen vefahren werden soll. Diese Probleme können entweder auf Anwendungsebene gelöst werden, wie z. B. durch die Möglichkeiten wie sie Enterprise Application Integration (EAI) bietet (vgl. dazu auch Abschnitt 2.5.2) oder auf Datenebene selbst, indem die verwendeten Datenbanken fusioniert werden. Die Überführung der Altdaten muss strategisch geplant und zeitnah umgesetzt werden. Sobald sichergestellt ist, dass alle Daten vollständig und korrekt in das neue System integriert wurden, sollten Legacy-Anwendungen aus dem täglichen Betrieb entfernt werden [Han09, S.2], [Tie06, S.10]. Master Data Management MDM Bei global agierenden Unternehmen, aber auch bei Unternehmen mit heterogenen Unternehmens- und IT-Strukturen werden Daten zu gleichen oder ähnlichen Sachverhalten in den Fachabteilungen an verschiedenen Standorten in einer Vielzahl von Anwendungssystemen bereitgestellt. So muss z. B. in vielen Unternehmensbereichen (Sales, Marketing, Finance, Logistic usw.) mit gearbeitet werden. Diese Daten werden jedoch im Allgemeinen mit speziellen Anwendungen verwaltet (CRM-Systeme, ERP-Systeme usw.), die den Kunden ganz unterschiedlich abbilden. Üblicherweise unterscheiden sich diese Daten auch in ihrer Beschaffenheit, Qualität, Aktualität und Genauigkeit, da sie in der Regel für bestimmte Zwecke erfasst und strukturiert wurden. Für standort- und/oder abteilungs-

2.2 Typische Anwendungsfelder 21 BILD 2.3 Legacy Anwendungen übergreifende Geschäftsprozesse müssen diese Daten aus den IT-Systemen der jeweiligen Geschäftsbereiche aufwendig extrahiert und homogenisiert werden. Daten, die standort-, abteilungs-, oder auch prozessübergreifend zur Verfügung stehen müssen, werden im Allgemeinen als Stamm- oder Masterdaten bezeichnet. Das Management solcher Masterdaten rückt in den letzten Jahren immer mehr in den Fokus der Unternehmen. Bei Umfragen haben über 90% der Unternehmen erklärt, bereits Master Data Management (MDM)-Lösungen einzusetzen oder für die nächste Zeit zu planen. Ziel des MDM ist die zentrale Verwaltung von Stammdaten bzw. Referenzdaten, um system- und anwendungsübergreifende Konsistenz sicherzustellen, ohne immer neue Integrationsprojekte zu starten. Für ein vernünftiges MDM müssen zunächst die relevanten Systeme identifiziert werden, die Stammdaten liefern oder empfangen. Aus den gelieferten Datenmengen sollte eine Schnittmenge gebildet werden, um die für das MDM-System sinnvollen Daten zu finden. Diese Masterdaten müssen aus den relevanten Systemen extrahiert und nach vorab zentral definierten Regeln und Standards in einer Master-Datenbank integriert und konsolidiert werden. Herausforderungen, die in MDM-Projekten zu meistern sind, sind jedoch nicht in erster Linie technischer Art (die Integrationsmethoden sind vergleichbar mit denen von Data Warehouse Projekten), sondern eher organisatorischer Art. Diese und weitere Herausforderungen werden u. a. bei [Los08] und [HOW11] vertiefend behandelt und durch zahlreiche Fallstudien und Anwendungsszenarien ergänzt. 2.2.2 Konsolidierung im analytischen Bereich Das wichtigste Ziel im analytischen Bereich ist die Transformation von Informationen in Wissen. Je umfangreicher und je zuverlässiger Informationen verknüpft werden können, desto fundierteres Wissen lässt sich daraus generieren, um operative und strategische Entscheidungen ziel- und bedarfsgerecht durchzuführen. Um dieses Ziel zu erreichen, müssen verfügbare Daten aus verschiedenen Quellen integriert, angereichert, aufbereitet und dargestellt werden. Das große Gebiet, unter dem sich diese Aufgaben zusammenfassen lassen,

22 2 Grundlagen der Datenintegration BILD 2.4 Gemeinsame Datenbasis wird im Allgemeinen als Business Intelligence (BI) bezeichnet. Wie für viele Anwendungen im operativen Bereich bildet Datenintegration auch für BI-Anwendungen das Rückgrat. Aussagekräftige und verlässliche Analysen, Vorhersagen, Berichte usw. sind nur auf der Basis konsolidierter Datenbestände möglich. KONZEPT METHODE BEISPIEL Reporting Dashboards Score Cards Übersicht potentielle Kündiger OLAP Data Cubes Kündiger pro Quartal pro Region Mining Klassifikation Regression Clusterbildung Assoziation Charakteristik Kündiger-Nichtkündiger Vorhersage Kündigungswahrscheinlichkeit BILD 2.5 Business Intelligence