ETL-Design Optimierung

Größe: px
Ab Seite anzeigen:

Download "ETL-Design Optimierung"

Transkript

1 ETL-Design Optimierung Tobias Fellner geboren am Dortmund,

2 Kurzfassung Thema dieser Projektarbeit ist die ETL-Design Optimierung. ETL-Design ist die Modellierung von Datenflüssen und Datentransformationen. Grundlage für eine Optimierung sind Ziele und Vergleichbarkeit zwischen Designvarianten. Zu diesem Zweck werden in dieser Arbeit, nach einer Einführung in die zum Verständnis notwendigen Grundlagen, Designziele und darauf wirkende Maße vorgestellt. Anhand von praktischen Beispielen werden die Zusammenhänge zwischen Maßen und Zielen nach einem einheitlichen Vorgehen untersucht. Als Modellierungswerkzeug kommt dabei Informatica PowerCenter 8 Designer zum Einsatz. Nach den praktischen Analysen werden aus den gewonnenen Erkenntnissen generelle Designempfehlungen im Ergebnisteil der Arbeit vorgestellt. Die Arbeit schließt mit einer Zusammenfassung sowie einem Ausblick auf Möglichkeiten weiterer Forschung ab. Abstract Subject of this project thesis is ETL-Design optimization. ETL-Design describes the modeling of data flows and data transformations. Precondition of optimization are knowledge about objectives and comparability between different approaches. Therefore, after an introduction to the theoretical fundamentals, objectives and measures are introduced. Then different approaches of optimization are analyzed in practical examinations. Focus of these analyses are the interdependencies between measures und objectives. After the practical part, the introduced measures are evaluated. Additionally based on observations and the gained knowledge general design recommendations are presented in the conclusion part of this thesis. Finally, this thesis ends with a summary and an outlook on possible future research. ETL-Design Optimierung Seite 2 von 108

3 Markenrechtlicher Hinweis Die in dieser Arbeit wiedergegebenen Gebrauchsnamen, Handelsnamen, Warenzeichen usw. können auch ohne besondere Kennzeichnung geschützte Marken sein und als solche den gesetzlichen Bestimmungen unterliegen. Sämtliche in dieser Arbeit abgedruckten Bildschirmabzüge unterliegen dem Urheberrecht des jeweiligen Herstellers. Informatica und Informatica PowerCenter sind Marken oder eingetragene Marken der Informatica Corporation, Redwood /CA United States. Oracle und Oracle XE sind eingetragene Marken der Oracle Corporation, Redwood Shores/CA United States. ETL-Design Optimierung Seite 3 von 108

4 Inhaltsverzeichnis Kurzfassung... 2 Abstract Einleitung Grundlagen Terminologie Einordnung und Bedeutung von ETL Prozessen Extraktion Transformation Laden Modellierung von ETL Prozessen mit Informatica Powercenter Transformationen in Informatica PowerCenter Mappings in Informatica PowerCenter Mapplets Sessions Workflows Designziele und Maße für ETL Prozesse Designziele Korrektheit Wartbarkeit Wiederverwendbarkeit Performance Zuverlässigkeit Bewertung der Zielerfüllung Maße Übersicht Quantitative Maße Qualitative Maße ETL-Design Optimierung Vorgehensweise Beispielszenario ETL-Design Optimierung Seite 4 von 108

5 4.2.1 Datenquellen Zieltabellen Positionierung von Transformationen Filtertransformation - Fallbeispiel Joinertransformation - Fallbeispiel Zusammenfassung Positionierung von Transformationen Austauschbarkeit von Transformationen Lookup vs. Join Lookup vs. Join - Fallbeispiel Lookup vs. Join - Fallbeispiel Zusammenfassung Lookup vs. Join Weitere Optimierungsansätze - Fallbeispiel Datenquellen Zieltabellen Ausgangsbeispiel Variante 1 - Merge and Split Variante 2 - Modularisierung Variante 3 - Parameter und Sortierungen Ergebnis Bewertung der Maße Quantitative Maße Qualitative Maße Zusammenfassung Klassifizierung von Mappings Designempfehlungen Wartbarkeit Wiederverwendbarkeit Performance Zuverlässigkeit Zusammenfassung und Ausblick a. Tabellenverzeichnis b. Abbildungsverzeichnis c. Literaturverzeichnis d. Eidesstattliche Erklärung...Fehler! Textmarke nicht definiert. ETL-Design Optimierung Seite 5 von 108

6 ETL-Design Optimierung Seite 6 von 108

7 1 Einleitung ETL steht für Extract, Transform, Load und bezeichnet einen Prozess, mit dem Daten aus verschiedenen Quellen extrahiert, verarbeitet und anschließend in Zielsysteme transportiert werden. ETL Prozesse spielen insbesondere in Business Intelligence und in Data Mining Szenarien eine wichtige Rolle, da sie hier dazu genutzt werden, die zu analysierenden Daten aufzubereiten und zur Verfügung zu stellen. Hierfür werden Daten aus häufig verteilten, heterogenen, meist operativen Quellsystemen extrahiert und in Zielsysteme, häufig Data Warehouses, überführt. Neben ihrer Bedeutung in den genannten Szenarien dienen ETL Prozesse auch der Datenintegration im Allgemeinen, zum Beispiel bei der Konsolidierung operativer Systeme. In Data Warehouse Projekten kann die Implementierung von ETL Prozessen bis zu 50% des Gesamtaufwandes bedeuten (Kurz, 1999, S. 266), andere Schätzungen sprechen sogar von bis zu 80% (Bange, 2006, S. 64). Hieraus resultiert, dass Projekterfolge maßgeblich von der Qualität der ETL Prozesse abhängen. Die Basis bei der Entwicklung von ETL Prozessen stellt dabei das ETL-Design, also die Modellierung von Datenflüssen und Transformationsregeln dar. Diese Abhängigkeit verdeutlicht die hohe Bedeutung von gutem ETL-Design. Wodurch gutes Design charakterisiert ist, beziehungsweise wie gutes ETL Design erreicht wird, ist dabei nicht trivial zu erkennen. Entsprechend stellt es eine Herausforderung dar, ETL Design zu analysieren, zu vergleichen und zu bewerten. Während es auf Geschäftsprozessebene umfangreiche Untersuchungen zu ETL Prozessen gibt und aus diesen verschiedene Vorgehensmodelle hervorgegangen sind 1, wurde die Modellierungs- oder Designebene von ETL Prozessen bisher nicht ausführlich untersucht. Designentscheidungen werden bei der Modellierung von ETL Prozessen häufig auf Grundlage der Erfahrungen von Entwicklern und dadurch oft intuitiv gefällt. Hierdurch ist die Qualität starken Schwankungen unterworfen. Personenunabhängige, kontinuierliche Verbesserung ist schwierig und Fehler werden häufig erst spät oder gar nicht entdeckt. Ziel dieser Arbeit ist es, ETL-Design anhand verschiedener Szenarien unter Berücksichtigung von Zielen und Maßen zu problematisieren, Designvarianten aufzuzeigen und zu bewerten. Auf Basis der gewonnenen Erkenntnisse sollen Richtlinien für verschiedene, in der Praxis auftretende Problemstellungen entwickelt werden. Für das weitere Verständnis werden in Kapitel 2 zunächst theoretische Grundlagen von ETL- Prozessen vermittelt. Außerdem wird das Werkzeug Informatica PowerCenter 8, mit dem die Untersuchungen durchgeführt werden, in seiner Funktionsweise vorgestellt. Anschließend werden in Kapitel 3 Ziele, die beim Design von ETL Prozessen relevant sind, eingeführt. Neben den Zielen werden quantitative und qualitative Maße vorgestellt, die die Ziele 1 Vergleiche (Kimball, Reeves, Ross, & Thornthwaite, 1998), (Kimball & Caserta, The Data Warehouse ETL Toolkit, 2004), (Bauer & Günzel, 2004), (Goeken, 2006) ETL-Design Optimierung Seite 7 von 108

8 beeinflussen. Sowohl Maße als auch Ziele werden dabei aus verschiedenen Fachbereichen der Informatik hergeleitet. Nach der Einführung von Zielen und Maßen wird in Kapitel 4 ein Beispielszenario eingeführt. Anhand dieses Szenarios werden verschiedene Optimierungsansätze in einzelnen Fallbeispielen untersucht. Um ihre Vergleichbarkeit sicherzustellen, werden die Analysen nach einem einheitlichen Vorgehen, das ebenfalls in Kapitel 4 eingeführt wird, durchgeführt. Die Untersuchungen finden dabei auf Modellierungs- beziehungsweise Designebene statt. Auf den praktischen Teil der Arbeit und die darin vorgenommenen Untersuchungen anhand von Beispielen folgen in Kapitel 5 eine Bewertung der eingeführten Maße sowie ein auf den Erkenntnissen basierender Vorschlag zur Klassifizierung von Mappings. Außerdem werden die in den Untersuchungen gewonnenen Erfahrungen genutzt, um daraus Empfehlungen für ETL-Design unter Berücksichtigung der verschiedenen Ziele abzuleiten. Zum Abschluss der Arbeit werden in Kapitel 6 eine Zusammenfassung der Ergebnisse sowie ein Ausblick gegeben. ETL-Design Optimierung Seite 8 von 108

9 2 Grundlagen 2.1 Terminologie Im Verlaufe dieser Arbeit werden einige ETL spezifische Begriffe verwendet. Darüber hinaus benutzt das verwendete Werkzeug Informatica Powercenter 8 zum Teil eine eigene Terminologie. Zum besseren Verständnis der folgenden Abschnitte werden die wichtigsten Begriffe hier definiert. ETL: Extract, Transform, Load ETL bezeichnet einen Prozess, bei dem Daten aus einer oder mehreren Quellen extrahiert, verarbeitet bzw. transformiert und anschließend in ein Ziel oder mehrere Ziele geschrieben werden. Quelle: Die zu verarbeitenden Daten können aus einer oder mehreren Quellen verschiedenen Typs extrahiert werden. In Informatica PowerCenter 8, dem verwendeten Werkzeug, werden Daten aus einer Quelle in den sogenannten Source Qualifier gelesen und somit in das Mapping geladen. Ziel: Nach der Verarbeitung werden die Daten in ein oder mehrere Ziele, die von verschiedenem Typ sein können, geschrieben. Transformation: Eine Transformation bezeichnet im ETL-Kontext eine Aktivität, die Manipulationen an Daten bzw. an deren Schema vornimmt. In dieser Arbeit wird, soweit nicht anders angegeben, davon ausgegangen, dass die Daten in Form eines relationalen Schemas, also in Tabellenform mit Zeilen und Spalten vorliegen. Die Zeilen beschreiben dabei die Datentupel, die Spalten deren Attribute. Zu unterscheiden sind aktive und passive sowie verbundene und nicht verbundene Transformationen. Eine aktive Transformation verändert die Anzahl der Zeilen einer Tabelle, dagegen bleibt die Zeilenanzahl bei passiven Transformationen gleich. Zu beachten ist, dass sich das Kriterium nur auf die Zeilen bezieht. Eine Transformation, die die Anzahl der Spalten durch Projektion ändert, die Zeilenanzahl aber unverändert lässt, ist passiv. Neben aktiven und passiven gibt es verbundene und nicht verbundene Transformationen als wesentliche Typen. Eine Transformation wird als verbundene Transformation bezeichnet, wenn sie über verbundene Ein- und Ausgabeports in den Datenfluss integriert ist. Neben verbundenen gibt es auch nicht verbundene Transformationen. Diese haben keine direkte Verbindung zum Datenfluss des Mappings, sondern werden aus anderen Transformationen aufgerufen. Mapping: Eine Menge von Transformationen mit mindestens einer Quelle und einem Ziel wird als Mapping bezeichnet. In Informatica Powercenter werden innerhalb eines Mappings Daten aus einer oder mehreren Quellen gelesen, dann optional in weiteren Transformationen manipuliert und anschließend in ein oder mehrere Ziele geschrieben. Das Mapping kann hierbei als gerichteter, zyklenfreier Graph gesehen werden. Die einzelnen ETL-Design Optimierung Seite 9 von 108

10 Transformationen sind seine Knoten, die Verbindungen zwischen Ports die Kanten (Simitsis, Vassiliadis, & Sellis, 2005). Die Betrachtung als Graph dient im Verlaufe dieser Arbeit als Grundlage für die Diskussion verschiedener Qualitätsmerkmale. Mapplet: Mapplets sind eine Besonderheit von Informatica Powercenter. Sie bieten die Möglichkeit, mehrere Transformationen zu einem Modul zusammenzufassen und als eine Einheit über definierte Ein- und Ausgabetransformationen anzusprechen. Bei sehr umfangreichen Mappings ist es häufig sinnvoll, zusammengehörige Transformationen in Mapplets zu kapseln. Hierdurch wird die Übersichtlichkeit erhöht und Wiederverwendung ermöglicht. Session: In Informatica PowerCenter werden einzelne Mappings in Sessions eingebunden, um diese auszuführen. Für die Session werden die notwendigen Parameter, wie Verbindungen zu Quell und Zielsystemen, definiert. Außerdem bieten Sessions die Möglichkeit Variablen und Parameter, die im ETL Prozess genutzt werden, zu definieren. Sessions werden zur Ausführung in ein Worklet oder einen Workflow integriert. Worklet: Ein Worklet fasst mehrere Sessions zu einem Modul zusammen. Als Module lassen sich Worklets in verschiedenen Workflows wiederverwenden. Workflow: Der Workflow ist die höchste logische Ebene in Informatica Powercenter und bildet einen gesamten ETL Prozess ab. Ein Workflow kann dabei aus 1-n Sessions oder Worklets und somit aus 1-n Mappings bestehen. 2.2 Einordnung und Bedeutung von ETL Prozessen Das Datenaufkommen in heutigen Unternehmen wächst kontinuierlich, gleichzeitig steigt der Bedarf, diese Daten in einer unternehmensweiten, einheitlichen Sicht zu analysieren, überproportional zu diesem Wachstum. Analysen sollen sowohl Erkenntnisse über das operative Geschäft liefern, als auch entscheidungsunterstützend bei der strategischen Planung und Steuerung helfen. Grundlage für derartige Analysesysteme bilden häufig Data Warehouse Systeme. In einem Data Warehouse werden Daten aus allen relevanten Datenquellen eines Unternehmens zusammengeführt und, von den operativen Daten physikalisch getrennt, in einem einheitlichen Schema vorgehalten. (Inmon, 2002, S. 31) Die Versorgung eines Data Warehouses findet üblicherweise durch ETL Prozesse statt. Während eines ETL Prozesses werden zuerst Daten aus Quellsystemen extrahiert. Während der folgenden Transformationsphase werden Daten bereinigt, verarbeitet und in das Zielschema transformiert. Anschließend werden während der Ladephase die zuvor extrahierten und transformierten Daten in das Zielsystem, zum Beispiel ein Data Warehouse geschrieben. Außer in Data Warehouse Szenarien spielen ETL Prozesse auch bei der Datenintegration im Allgemeinen eine wichtige Rolle. Sie kommen überall dort zum Einsatz, wo Daten aus verschiedenen Quellensystemen in andere Datenhaltungssysteme überführt und dabei an neue Anforderungen angepasst werden müssen. Grundsätzlich können ETL Prozesse entweder individuell programmiert werden, oder mit Hilfe von Werkzeugen entwickelt und durchgeführt werden. Im Rahmen dieser Arbeit wird von der Nutzung eines Werkzeugs, konkret dem Informatica PowerCenter Server 8, ausgegangen. Durch die hohe Komplexität von ETL Prozessen, ist der Einsatz eines Werkzeugs in den meisten ETL-Design Optimierung Seite 10 von 108

11 Fällen sehr empfehlenswert. (Kimball & Caserta, The Data Warehouse ETL Toolkit, 2004, S. 10) (Kurz, 1999, S. 268) Nachfolgend wird jede der drei ETL-Phasen näher beschrieben Extraktion In der Extraktionsphase werden Daten aus verschiedenen operativen Datenquellen eines Unternehmens gelesen und in den ETL Arbeitsbereich geladen. Für ETL Prozesse kommen verschiedene Arten von Datenquellen in Frage. Beispiele sind Textdateien, relationale Datenbanken und proprietäre Systeme. Vor der eigentlichen Extraktion müssen die relevanten Quellen und Daten identifiziert und selektiert werden. Dies sind fachliche Entscheidungen, die von den entsprechenden Abteilungen, in Zusammenarbeit mit dem ETL-Team, getroffen werden müssen. Für die Selektion spielen verschiedene Faktoren eine Rolle. So muss zum einen die Verfügbarkeit von Daten berücksichtigt werden. Bei externen Datenquellen kann diese schwanken und somit nicht immer auf Dauer gewährleistet werden. Neben der Verfügbarkeit spielt vor allem die Qualität der Daten bei deren Auswahl eine wichtige Rolle Data Profiling Sind die relevanten Daten identifiziert, müssen diese während des sogenannten Data Profilings analysiert und auf ihre fachliche und technische Qualität überprüft werden. Nach Bauer und Günzel gibt es 7 Kriterien, anhand derer die Qualität von Daten überprüft werden kann. 1. Konsistenz: Daten werden als konsistent bezeichnet, wenn sie untereinander, gegenüber den jeweiligen Metadaten widerspruchsfrei sind. 2. Korrektheit: Bilden Daten die jeweiligen Sachverhalte in der Realität richtig ab, so werden sie als korrekt bezeichnet. 3. Vollständigkeit: Sind alle benötigten Daten vorhanden, um die jeweiligen Sachverhalte in der Realität abzubilden, sind diese vollständig. 4. Genauigkeit und Granularität: Dieses Kriterium ist erfüllt, falls die Daten anhand ihrer Ausprägung unterscheidbar sind und einem geforderten Detaillierungsgrad genügen. 5. Zuverlässigkeit und Glaubwürdigkeit: Um dieses Kriterium zu erfüllen, muss die Herkunft der Daten nachvollziehbar und vertrauenswürdig sein. 6. Verständlichkeit: Daten werden als verständlich bezeichnet, falls die Bedeutung der Daten für die Anwender ersichtlich ist. 7. Verwendbarkeit und Relevanz: Nur Daten, die eine entsprechend den anderen 6 Kriterien hohe Qualität aufweisen und gleichzeitig für die durchzuführenden Analysen relevant sind, werden in das Data Warehouse überführt. ETL-Design Optimierung Seite 11 von 108

12 Mit Hilfe dieser Kriterien können Mindestanforderungen an Datenqualität definiert werden, die zur Auswahl der Daten erfüllt werden müssen. Zwar können in Phase 2 des ETL Prozesses, der Transformationsphase, Maßnahmen zur Verbesserung der Datenqualität vorgenommen werden, eine Verbesserung ist aber nur in bestimmten Fällen und bis zu einem gewissen Maß möglich. Das Verbesserungspotential der Datenqualität muss dementsprechend bei der Selektion von Daten berücksichtigt werden. (Bauer & Günzel, 2004, S. 40 ff.) Staging Nach der Selektion der zu extrahierenden Daten werden diese in der Regel in eine sogenannte Staging Area geladen. Hierbei handelt es sich um einen Arbeitsbereich, in dem alle weiteren Maßnahmen bis zum Laden vorgenommen werden. Der Vorteil des Zwischenspeicherns der Daten liegt zum einen in geringeren Sperrzeiten der operativen Systeme begründet. Zum anderen wird durch Staging die Zuverlässigkeit des Prozesses verbessert. So können ETL Prozesse, bei denen die Daten in einer Staging Area vorgehalten werden, im Fehlerfall neu gestartet werden, ohne dass erneut auf die Quellen zugegriffen werden muss. (Kimball & Caserta, The Data Warehouse ETL Toolkit, 2004, S ) Transformation Während der Transformationsphase findet die eigentliche Verarbeitung der Daten statt. Dies geschieht in drei Unterphasen: Der Datenbereinigung, der Schemaintegration und Datentransformation Datenbereinigung Während der Datenbereinigung werden fehlerhafte Quelldaten behandelt. Dies ist notwendig, da diese die Ergebnisse der auf den Daten durchgeführten Analysen verfälschen könnten. Außerdem werden von inkonsistenten Daten Probleme beim späteren Laden verursacht. Die typischerweise auftretenden Fehler in Quelldaten lassen sich nach (Bauer & Günzel, 2004) in fünf Klassen unterteilen: Referenzielle Integrität: Stehen Daten miteinander in einer Fremdschlüsselbeziehung und ist ein Datensatz, auf den verwiesen wird, nicht vorhanden, liegt eine Verletzung der referenziellen Integrität vor. In einem solchen Fall kann der fehlende Datensatz entweder ergänzt oder, falls dies nicht möglich ist, der verweisende Datensatz gelöscht werden. Fehlerhafte Werte und unzulässige Werte Daten können fehlerhaft in Quellen vorliegen. Dies geschieht zum Beispiel bei der Erfassung durch Tippfehler oder durch Fehler in den operativen Systemen. Durch Plausibilitätsprüfungen, zum Beispiel durch den Vergleich mit Referenzdatenquellen und Überprüfung des zulässigen Wertebereichs, können solche Fehler erkannt und eventuell korrigiert werden. Ist keine automatische Korrektur möglich, müssen Fehler entweder manuell überprüft und behoben, die betroffenen Daten verworfen oder die Fehler toleriert werden. Fehlende Werte und Nullwerte Enthält ein Feld keine Daten, kann dies zwei Ursachen haben. Entweder gibt es zu diesem Feld keinen Wert in der Realität oder es gibt einen, der aber nicht erfasst wurde. Falls ein Wert nicht erfasst wurde, kann dieser unter Umständen ergänzt werden. Dies erfordert aber in den meisten Fällen eine manuelle Prüfung und genaue fachliche Kenntnis der Daten. ETL-Design Optimierung Seite 12 von 108

13 Redundanz Redundanzen beziehungsweise Duplikate treten häufig bei Inkonsistenzen auf. In diesem Fall müssen die Daten untereinander, zum Beispiel mit Hilfe von Zeitstempeln, abgeglichen werden. Erkennung von Duplikaten und deren Beseitigung ist häufig ein Funktionsmerkmal von ETL-Werkzeugen. Trotzdem ist die Behandlung von Duplikaten eine große Herausforderung im ETL Kontext. Unverständliche oder nicht eindeutige Kodierungen In Softwaresystemen werden Daten häufig kodiert gespeichert. Da es keine einheitlichen Standards zur Kodierung gibt, können Kodierungen in verschiedenen Quellen voneinander abweichen. Ein Beispiel hierfür sind Angaben zum Geschlecht, die mit m/w, m/f oder 0/1 kodiert werden können. Solche Konflikte müssen aufgelöst und in eine standardisierte Form überführt werden Schemaintegration Da die Quelldaten aus verschiedenen operativen Systemen stammen, sind sie oft schemaheterogen. Für die Integration in das Zielsystem müssen diese jedoch in ein einheitliches Schema überführt werden. Typische Aufgaben hierbei sind Typkonvertierungen, zum Beispiel verschiedener DATE Typen, oder die Umwandlung von als Zeichenketten gespeicherten Daten in numerische Werte. Zur Schemaanpassung werden häufig Metadaten verwendet. Soweit sich die Quellschemata nicht verändern, sind die Transformationsregeln zur Schemaintegration nach erstmaliger Definition wiederverwendbar. (Lehner, 2003) Datentransformation Nachdem die Quelldaten bereinigt und Transformationsregeln zur Schemaintegration definiert sind, können fachlich Transformationen definiert werden, die die Daten den Anforderungen des Zielsystems entsprechend anpassen und gegebenenfalls erweitern (Lehner, 2003). Eine typische Anforderung ist die Datenfilterung anhand von Wertebereichen. Außerdem werden Daten häufig voraggregiert, falls für die Verarbeitung in den Zielsystemen nur eine höhere Aggregationsstufe benötigt wird. Hierdurch wird der Speicherbedarf in den Zielsystemen zum Teil drastisch reduziert. Neben diesen Maßnahmen können anhand der bereinigten Daten auch zusätzliche Attribute aus bestehenden Attributen abgeleitet werden. Anschließend werden die zuvor definierten Transformationen an den Daten durchgeführt. Die Transformation findet üblicherweise im Staging Area statt. Nach Durchführung aller Transformationen folgt die Ladephase Laden In der Load- oder Ladephase von ETL Prozessen werden transformierte Daten in Zielsysteme geschrieben. Dies kann ein Data Warehouse sein, ETL ist jedoch nicht zwangsläufig nur im Data Warehouse Umfeld anzusiedeln, weswegen auch andere Zielsysteme in Frage kommen. Um das Laden möglichst performant durchzuführen, werden häufig spezielle Funktionen der Zielsysteme genutzt. Zum Beispiel bietet sich bei relationalen Datenbanken der sogenannte Bulk Modus an. Hierbei werden beim Schreiben Protokollfunktionen und Transaktionskontrollen umgangen, wodurch die Leistung erheblich gesteigert werden kann Ladestrategien Zur Versorgung eines Data Warehouses sind grundsätzlich drei Ladestrategien denkbar. Diese sind Initial Load, Full Refresh und Incremental Load. ETL-Design Optimierung Seite 13 von 108

14 Mit Initial Load wird das erstmalige Schreiben in die Zielsysteme bezeichnet. Im Data Warehouse Umfeld werden hierfür alle Tabellen mit den in der Transformationsphase erzeugten Daten bevölkert. Ein Initial Load findet üblicherweise nur einmal bei der Einführung eines neuen Systems statt. Full Refresh löscht den Inhalt einer oder mehrerer Zieltabellen und füllt diese mit neuen Daten. Dieses Verfahren entspricht weitestgehend einem Initial Load, mit dem Unterschied, dass nicht alle Tabellen des Zielsystems betroffen sein müssen. Da Full Refresh entsprechend der zu ladenden Datenmenge äußerst aufwendig werden kann, ist aufgrund der zeitlichen Restriktionen, denen der Ladeprozess unterliegt, das Verfahren eines Incremental Load häufig sinnvoll. Hierbei werden nur geänderte Daten erneut geschrieben. Dies reduziert die zu verarbeitende Datenmenge erheblich. Für Incremental Load können Daten in zwei Klassen unterteilt werden, in neue Daten, die dem Data Warehouse hinzugefügt werden müssen, und geänderte Daten, für die entsprechend eines Historisierungskonzepts verfahren werden muss. Im Betrieb eines Data Warehouses wird üblicherweise mit Incremental Load gearbeitet (Bauer & Günzel, 2004). 2.3 Modellierung von ETL Prozessen mit Informatica Powercenter 8 Zwischen der Modellierung, der Entwicklung und der Durchführung von ETL Prozessen sollen Brüche vermieden werden. Es soll aus dem Modell direkt in die Entwicklung und zur Wartung und Weiterentwicklung aus der Entwicklung zurück in das Modell überführt werden können. Momentan existieren nur sehr wenige Ansätze zur Standardisierung der Modellierung von ETL Prozessen. Die wenigen, vielversprechenden Ansätze 2 werden nicht von ETL Werkzeugen unterstützt, da die Hersteller hier ihre proprietären Ansätze verfolgen. In der Praxis bietet es sich daher an, die Modellierung mit dem Werkzeug, in dem die Umsetzung und der Betrieb der ETL Prozesse realisiert werden sollen, durchzuführen. Die Entscheidung für ein Werkzeug ist also gleichzeitig eine Entscheidung für die Modellierungssprache, umgekehrt kann die verwendete Modellierungssprache die Entscheidung für ein Werkzeug beeinflussen. Für diese Arbeit wurde Informatica Power Center 8 als ETL Werkzeug gewählt. Neben einer graphischen Entwicklungsumgebung zum Design von ETL Prozessen bietet es einen Integrationsserver, um diese auszuführen. Darüber hinaus verfügt Informatica Power Center 8 über ein sogenanntes Repository. Das Repository ist eine relationale Datenbank, in der alle relevanten Informationen inklusive Metadaten zu den ETL Prozessen vorgehalten werden. Für Informatica sprechen insbesondere der große Reifegrad, die hohe Marktdurchdringung und Akzeptanz sowie die umfassende Konnektivität zu verschiedensten Quell- und Zielsystemen. In Informatica Power Center 8 existieren verschiedene Betrachtungsebenen für einen ETL Prozess. Auf höchster Ebene steht der Workflow, welcher einen gesamten ETL Prozess abbildet. Ein Workflow besteht aus Sessions, die jeweils einzelne Mappings zusammenfassen. Außerdem können mehrere Sessions zu einem Worklet zusammengefasst werden. Die nächste Ebene unterhalb der Sessionebene ist die des Mappings. In einem Mapping werden Daten von Quellen durch verschiedene Transformationen in Ziele transferiert. Ein Mapping ist also eine Menge von Transformationen mit mindestens einer Quelle und mindestens einem Ziel. Die einzelnen Transformationen leisten hierbei 2 (Vassiliadis, Simitsis, & Skiadopoulus, 2002), (Luján-Mora, Vassiliadis, & Trujillo, 2004) ETL-Design Optimierung Seite 14 von 108

15 die notwendige Verarbeitung der Daten, die Transformationsebene stellt gleichzeitig die tiefste Betrachtungsebene dar. Nachfolgend werden die Grundlagen zu Transformationen, Mappings, Sessions und Workflows anhand von Beispielen dargestellt. Hierbei wird nach dem bottom-up Prinzip vorgegangen, es werden zuerst Transformationen als unterste Betrachtungsebene vorgestellt. Anschließend werden die nächst höheren Ebenen, Mapping und Mapplet, betrachtet. Abschließend werden Sessions und die darauf aufbauenden Workflows kurz vorgestellt. Der Betrachtungsschwerpunkt der durchgeführten Untersuchungen liegt auf den unteren Ebenen, also Transformations-, Mapplet- und Mappingebene Transformationen in Informatica PowerCenter 8 Eine Transformation verfügt über Ports, die die Attribute von Daten repräsentieren. Es werden hierbei Ein- und Ausgabeports getrennt betrachtet. Über die Ein- und Ausgabeports werden Daten beziehungsweise Attribute zwischen Transformationen weitergeleitet. Neben den Ein- und Ausgabeports existieren Variablenports, die zur Verarbeitung von Daten innerhalb einer Transformation genutzt werden Beispiel einer Transformation Nachfolgend wird eine Transformation inklusive der Ein- und Ausgabeports dargestellt. Als Beispiel wurde eine EXPRESSION Transformation gewählt. Abbildung 1 Expression Transformation mit Ein- und Ausgabeports In Abbildung 1 sind am Beispiel einer EXPRESSION Transformation die verschiedenen Ports zu erkennen. Von links gelangen Daten über die Inputports SUM_HOURS_PER_PROJECT und TASK_LOG_COSTCODE in die Transformation. Rechts werden die in der Transformation berechneten Daten über die Outputports COST_PER_PROJECT, COST_IN_DOLLAR und COST_IN_FRANKEN zur weiteren Verarbeitung ausgegeben. Variablenports, in diesem Beispiel FACTOR_COSTCODE, werden auf Mappingebene nicht dargestellt, sondern werden erst beim Editieren von Transformationen ersichtlich. Folgende Abbildung 2 zeigt dies. ETL-Design Optimierung Seite 15 von 108

16 Abbildung 2 Expression Transformation Detailansicht Für jeden Port werden sein Name, der im relationalen Modell dem Spaltenname entspricht, sein Datentyp mit Länge und Präzision sowie seine Rolle definiert. Die Rollen können hierbei Eingabe- Ausgabe- und Variablenports sein. Sie werden in der Detailansicht durch I, O und V definiert und durch die Checkboxen gewählt. Diese Attribute sind bis auf wenige Ausnahmen für alle Transformationen gleich. In weiteren Merkmalen unterscheiden sich Transformationen jedoch. In einer EXPRESSION Transformation, wie sie beispielhaft in der Abbildung dargestellt ist, können für jeden Port entsprechende Berechnungsanweisungen definiert werden Transformationstypen Informatica Powercenter 8 bietet Transformationen für viele ETL Anforderungen an. Tabelle 1 bietet einen Überblick und eine kurze Beschreibung der in Informatica vorhandenen Transformationen. Wo es zum Verständnis der Beispiele notwendig ist, wird die Funktionsweise einzelner Transformationen an der Stelle der Verwendung genauer erklärt. Transformation Typ Kurzbeschreibung Aggregator aktiv / verbunden Führt Aggregationskalkulationen durch. Application Source Qualifier aktiv / verbunden Liest Zeilen aus einer Applikation, z.b. einem ERP System ein. Custom aktiv oder passiv / verbunden Ruft eine Prozedur aus einer Shared Library oder DLL auf. Expression Passiv / verbunden Berechnet Werte. External Procedure Passiv /verbunden oder nicht verbunden Ruft eine Prozedur aus einer Shared Library oder dem Windows COM Layer auf. Filter aktiv / verbunden Filtert Daten nach dem Prinzip einer Where-Klausel. Input Passiv / verbunden Definiert die Eingabeports eines Mapplets. ETL-Design Optimierung Seite 16 von 108

17 Java Aktiv oder passive / verbunden Führt benutzerdefinierte Anwendungslogik, die in Java entwickelt wurde, aus. Der Bytecode wird im Informatica PowerCenter Repository gespeichert. Joiner Aktiv / verbunden Führt Daten aus verschiedenen Datenbanktabellen oder Flatfiles spaltenweise zusammen. Die Daten können aus verschiedenen Quellsystemen stammen. Lookup Passiv / verbunden oder nicht verbunden Schlägt Werte in Quellen nach. Normalizer Aktiv / verbunden Source Qualifier für COBOL Quellen. Kann darüberhinaus zum Normalisieren von Daten aus relationalen oder flachen Quellen verwendet werden. Output Passiv / verbunden Definiert die Ausgabeports eines Mapplets. Rank Aktiv / verbunden Beschränkt die Daten auf eine Gruppe von maximal oder minimal Werten. Router Aktiv /verbunden Teilt den Datenfluss anhand von Bedingungen auf und leitet die Teilströme an verschiedene Transformationen weiter. Sequence Generator Passiv / verbunden Generiert Sequenzen, z.b. Primärschlüssel. Sorter Aktiv / verbunden Sortiert Daten anhand eines Sortierkriteriums. Source Qualifier Aktiv / verbunden Liest Daten aus relationalen oder flachen Quellen ein. Stored Procedure Transaction Control Passiv / verbunden oder nicht verbunden Aktiv / verbunden Ruft eine, in der Datenbank hinterlegte, Stored Procedure auf. Definiert commit und rollback Transaktionen. Union Aktiv / verbunden Führt Daten aus verschiedenen Datenbanktabellen oder Flatfiles zeilenweise zusammen. Die Daten können aus verschiedenen Quellsystemen stammen. Update Strategy Aktiv / verbunden Dient im Kontext von Historisierung zur Festlegung, ob Zeilen mit insert, delete, update oder reject verarbeitet werden. XML Generator Aktiv / verbunden Liest Daten über einen oder mehrere Eingabeports ein und gibt XML über einen Ausgabeport aus. XML Parser Aktiv / verbunden Liest XML über einen Eingabeport ein und gibt die Daten über einen oder mehrere Ausgabeports aus. XML Source Qualifier Aktiv / verbunden Liest Daten aus XML Quellen ein. Tabelle 1: Übersicht über die Transformationen in Informatica PowerCenter 8 (Informatica, PowerCenter Transformation Guide, 2006) ETL-Design Optimierung Seite 17 von 108

18 Wiederverwendbarkeit von Transformationen Informatica PowerCenter 8 bietet ein Konzept der Wiederverwendbarkeit von Transformationen. Hierfür wird bei der Erstellung von Transformationen das reusable Merkmal aktiviert. Dies führt dazu, dass Transformationen in mehreren Mappings verwendet werden können. Die wiederverwendbare Transformation wird im Repository von Informatica unabhängig von einzelnen Mappings hinterlegt. Sobald eine solche Transformation in einem Mapping verwendet wird, wird eine Instanz der Transformation erstellt. Wiederverwendbare Transformationen zeichnen sich vor allem dadurch aus, dass Änderungen an der Transformation von all ihren Instanzen automatisch übernommen werden. Standardmäßig ist das Wiederverwendbarkeitsmerkmal für alle Transformationen aktiviert. Es kann aber für alle Transformationen außer der External Procedure deaktiviert werden. Grundsätzlich ist die Nutzung von wiederverwendbaren Transformationen empfehlenswert. Die Auswirkungen von Änderungen auf alle Instanzen einer Transformation können bei Wartungsarbeiten allerdings auch zu nicht vorhergesehenem Verhalten in anderen Mappings führen. Bei vorausschauender Anwendung erhöhen sie jedoch sowohl die Wiederverwendbarkeit als auch die Wartbarkeit. (Informatica, Informatica PowerCenter Designer Guide 8.1, 2006, S. 209) Mappings in Informatica PowerCenter Innerhalb eines ETL Prozesses durchlaufen Daten einzelne Transformationen. Werden verschiedene Transformationen zu einem Datenfluss verbunden, stellen diese ein Mapping dar. Hierbei muss ein Mapping mindestens eine Quelle sowie mindestens ein Ziel aufweisen. Als Quellen und Ziele kommen in Informatica PowerCenter 8 relationale Tabellen in Datenbanken und flache Dateien in Frage. Darüber hinaus ist auch Zugriff auf andere Speicherformate, wie zum Beispiel XML oder Cobol, möglich. Zwischen Quellen und Zielen können beliebig viele Transformationen eingesetzt werden, in denen die Daten verarbeitet werden. Innerhalb eines Mappings werden also Daten von Quellen auf Ziele abgebildet und dabei in Transformationen verarbeitet. Die Daten fließen hierbei immer in eine Richtung von der Quelle zum Ziel. Der ETL Prozess wird also durch einen gerichteten, azyklischen Graphen beschrieben (Vassiliadis, Simitsis, & Skiadopoulus, 2002). Das heißt, es sind zwar Aufspaltungen des Datenflusses möglich, aber keine Umkehrung der Flussrichtung und somit auch keine Schleifen. Abbildung 3 auf der folgenden Seite zeigt ein einfaches Mapping Abbildung 3: Einfaches Mapping mit Filter Das Beispielmapping verfügt über eine Quelle und ein Ziel, in einer FILTER Transformation werden dabei nur Daten in das Ziel übergeben, für die Start und Ende der Aufgabe im Jahr 2006 lagen. ETL-Design Optimierung Seite 18 von 108

19 Die SOURCE QUALIFIER Transformation, die in dem abgebildeten Mapping zu sehen ist, ist eine Informatica PowerCenter spezifische Transformation. Sie dient dazu, die Daten per SELECT aus Quellen zu extrahieren und dem Integrationsdienst zur Weiterverarbeitung zu übergeben. Für jede Quelle wird ein Source Qualifier benötigt. Er kann bereits beim Einlesen einer Quelle in den Integrationsdienst Operationen, wie zum Beispiel Filterung oder Join durchführen. Die Bedingungen dafür werden durch eine WHERE Klausel im Source Qualifier definiert. Unter anderem werden die hieraus entstehenden Potentiale in dieser Arbeit untersucht Parameter und Variablen Mit Parametern und Variablen wird die Wiederverwendbarkeit von Mappings und den nachfolgend erläuterten Mapplets verbessert. Bei Parametern handelt es sich um konstante Werte, auf die während einer Session in Transformationen zurückgegriffen werden kann. Hierdurch können zum Beispiel Mappings, die sich strukturell gleichen, aber unterschiedliche Filterbedingungen anwenden, mehrfach mit verschiedenen Parametern verwendet werden. Ein Parameter wird hierbei für ein Mapping oder Mapplet deklariert und vor dem Starten einer Session mit einem Wert belegt. Dies kann entweder direkt im Informatica Mapping- beziehungsweise Mappletdesigner geschehen oder mittels einer Parameterdatei, in der die Werte hinterlegt werden. Variablen werden wie Parameter während einer Session in Transformationen einbezogen, um dort eine höhere Flexibilität und damit Wiederverwendbarkeit zu gewähren. Dies kann zum Beispiel durch Nutzung einer Variablen für Selektionsbedingungen geschehen. Im Unterschied zu Parametern können Variablen während einer Session geändert werden. Sie sind also nicht konstant, sondern können in verschiedenen Durchläufen mit unterschiedlichen Werten belegt werden (Informatica, Informatica PowerCenter Designer Guide 8.1, 2006) Mapplets Im Informatica PowerCenter 8 Designer bieten Mapplets die Möglichkeit Mappings zu modularisieren. Hierdurch können Transformationen, also zusammengehörige Verarbeitungsschritte, zusammengefasst werden. In komplexen Mappings wird hierdurch die sichtbare Anzahl an Transformationen verringert. Andererseits wird die Komplexität nicht reduziert, sondern nur durch Internalisierung verborgen. Wenn sie fachkonzeptionell sinnvoll, also zur Zusammenfassung enger logischer Gruppen genutzt werden, erhöhen Mapplets jedoch die Übersichtlichkeit. Außerdem sind sie als modulare Einheiten wiederverwendbar. Anhand eines Beispiels wird nachfolgend der Einsatz eines Mapplets erläutert. An dieser Stelle soll dabei nur ein Überblick verschafft werden. Eine Diskussion über den Nutzen und die Risiken findet später in Kapitel 4 statt. Auch eine Beschreibung des Anwendungsfalls wird später vorgenommen, da dieses Beispiel wieder verwendet wird. Im zur Veranschaulichung gewählten Beispiel müssen drei Quellen eingelesen und danach über zwei JOINER Transformationen zusammengeführt werden. Danach stehen die Daten in der benötigten Struktur für eine Berechnung der Projektkosten zur Verfügung. ETL-Design Optimierung Seite 19 von 108

20 Abbildung 4 zeigt zunächst ein Mapping ohne den Einsatz von Mapplets. Da einzelne Ports für das Verständnis des Beispiels nicht relevant sind und um die Übersichtlichkeit zu erhöhen, wurde eine minimierte Darstellung der Transformationen gewählt. Abbildung 4 Mapping ohne Mapplets Am Beispiel fällt auf, dass die Transformationen zum Einlesen und Zusammenführen der Quelltabellen mehr als die Hälfte des gesamten Mappings in Bezug auf die Anzahl der Transformationen ausmachen. In einem Mapplet können diese Transformationen zu einem Modul zusammengefasst werden. Die Zusammenfassung von Transformationen findet mit Hilfe des Mappletsdesigners statt. Im gewählten Beispiel sind die Quellen, Source Qualifier und Joiner Transformationen, in einem Mapplet mit der Bezeichnung MLTP_EXTRACT_AND_JOIN_SOURCES zusammengefasst. Zusätzlich verfügt das Mapplet über eine OUTPUT Transformation. Mapplets können über eine INPUT und müssen über eine OUTPUT Transformation verfügen. Diese besonderen Transformationen stellen die Schnittstelle des Mapplets zu dem Mapping, in dem sie genutzt werden, dar. Da in diesem Beispiel die Quellen in das Mapplet integriert sind, wird keine INPUT Transformation benötigt. Ziele hingegen lassen sich nicht in Mapplets einbinden, daher ist eine OUTPUT Transformation immer notwendig. Nachfolgend ist das Mapplet mit den darin enthaltenen Transformationen dargestellt. ETL-Design Optimierung Seite 20 von 108

21 Abbildung 5: Mapplet MLTP_EXTRACT_AND_JOIN_SOURCES Wird das neu erstellte Mapplet in das Mapping eingebunden, stellt sich das Mapping wie in folgender Abbildung gezeigt dar. Abbildung 6 Mapping mit Mapplet Die Zusammenfassung von der genannten Transformationen reduziert die Gesamtzahl der sichtbaren Transformationen um die Hälfte. Wie das Beispiel zeigt, kann der Einsatz von Mapplets die Übersichtlichkeit von ETL Prozessen auf der Ebene der Mappings erhöhen. Außerdem können Mapplets durch ihre Modularität relativ einfach wiederverwendet werden. ETL-Design Optimierung Seite 21 von 108

22 2.3.4 Sessions Sessions werden mit Task Developer des Workflow Managers von Informatica PowerCenter erstellt. Eine Session führt immer genau ein Mapping aus und dient als Arbeitseinheit eines Workflows. Neben dem zugrunde liegenden Mapping werden für eine Session Verbindungen zu den Quell- und Zielsystemen eingerichtet. Außerdem können innerhalb einer Session Parameter und Variablen eingesetzt werden. Für jede Session kann die Art der Fehlerbehandlung gewählt werden. Diese reicht von Ignorieren bis zum Abbrechen des übergeordneten Workflows Workflows Der Workflow ist die höchste Ebene des ETL Prozesses in Informatica PowerCenter 8. In ihm werden eine oder mehrere Sessions ausgeführt. Der Workflow nutzt zur Durchführung des ETL Prozesses den Integration Service. Außerdem können Workflows über einen Scheduler automatisiert, zeitgesteuert gestartet werden. Auch für Workflows können unterschiedlich restriktive Arten der Fehlerbehandlung definiert werden. ETL-Design Optimierung Seite 22 von 108

23 3 Designziele und Maße für ETL Prozesse Im Folgenden wird zunächst eine Liste von denkbaren Designzielen aufgestellt. Danach werden Maße, die die Ziele beeinflussen, eingeführt. Da die Gewichtung der einzelnen Ziele stark vom jeweiligen Anwendungskontext abhängt, wird diese in dieser Arbeit vorerst nicht vorgenommen. Stattdessen werden die Entwicklung der Maße und die daraus resultierende Zielbeeinflussung anhand verschiedener Beispielen untersucht. Hierdurch können Zusammenhänge erkannt und daraus Wirkprinzipien abgeleitet werden. Auf Basis der gewonnenen Erkenntnisse wird im Schlussteil der Arbeit eine Klassifizierung von Mappings vorgenommen. Diese soll bei der Gewichtung der Ziele in einzelnen Szenarien helfen. Darüber hinaus werden, ebenfalls im Schlussteil, generelle Empfehlungen für ETL-Design unter Betrachtung der einzelnen Ziele gegeben. ETL Designziele Die wesentlichen Ziele, die durch Designentscheidungen beeinflusst werden können, sind: Korrektheit Wartbarkeit Wiederverwendbarkeit Performance Zuverlässigkeit Maße Der Erreichungsgrad dieser Ziele wird von verschiedenen quantitativen und qualitativen Maßen beeinflusst. Quantitative Maße Datenmenge Anzahl der Knoten Länge Komplexität Qualitative Maße Modularität Kapselung Kohäsion Kopplung ETL-Design Optimierung Seite 23 von 108

24 3.1 Designziele Korrektheit Der Begriff der Korrektheit eines ETL Prozesses wird in dieser Arbeit analog zum Korrektheitsbegriff in der Softwaretechnik genutzt. Unter Korrektheit versteht man die Eigenschaft einer Software, die an sie gestellten Spezifikationen zu erfüllen. Nicht betrachtet wird, ob die Spezifikationen zur Lösung eines fachkonzeptionellen Problems richtig sind (Liggesmeyer, 2002, S. 7). Im ETL-Kontext bedeutet Korrektheit, dass die bewirtschaftenden Daten nach Durchführung des ETL Prozesses vollständig, fehlerfrei, typrichtig, gemäß des spezifizierten Zusammenhangs und Schemas in den Zielsystemen vorliegen. Korrektheit ist in ETL Prozessen analog zur Softwaretechnik immer stärkstes Ziel, da fachliche oder technische Fehler nicht kalkulierbare Probleme nach sich ziehen können. Dies wird im ETL Kontext insbesondere dadurch verschärft, dass ETL als Datenbewirtschaftungsprozess häufig die Grundlage für entscheidungsunterstützende Systeme in unternehmenskritischen Bereichen bildet Wartbarkeit Auch Wartbarkeit ist ein aus der Softwaretechnik übernommener Begriff. Eine hohe Wartbarkeit reduziert den Aufwand für Pflege und Erweiterung einer Software. Hierdurch werden Kosten gesenkt und eine Weiterentwicklung vereinfacht. Dies steigert in der Regel die Qualität der Lösungen. Gleichzeitig ist eine gute Wartbarkeit ein wichtiges Kriterium für erfolgreiche Teamarbeit, da weniger Abstimmungs- und Schulungsaufwand notwendig ist. Dies gilt analog auch für ETL Prozesse, daher ist auch hier eine hohe Wartbarkeit grundsätzlich erstrebenswert Wiederverwendbarkeit Unter Wiederverwendbarkeit versteht man die Möglichkeit ein Softwareprodukt ganz oder teilweise in weiteren Anwendungsfällen nutzen zu können. Ein hohes Maß an Wiederverwendbarkeit eines Produkts oder einer Komponente steigert die Kosteneffizienz bei der Entwicklung zukünftiger Lösungen und kann gleichzeitig bei der Wiederverwendung ausgereifter Produkte, andere Qualitätsmerkmale, wie die Zuverlässigkeit, positiv beeinflussen. Dies reduziert zum Beispiel den Aufwand für Validierung und Verifikation stark. Diese Definition lässt sich in dieser Form auf das Design von ETL Prozessen übertragen. Das Anstreben einer hohen Wiederverwendbarkeit wird in manchen Fällen den Aufwand für die initiale Erstellung eines ETL Prozesses erhöhen, dieser Nachteil wird aber vermutlich in den meisten Fällen von den oben genannten Vorteilen aufgewogen Performance Unter Performance wird der Durchsatz bzw. die Durchführungsgeschwindigkeit und damit Dauer eines ETL Prozesses verstanden. Im Rahmen von ETL Prozessen ist die Performance häufig ein wichtiges Kriterium. ETL-Design Optimierung Seite 24 von 108

25 Während der Extraktion von Daten aus operativen Quellen müssen diese in vielen Fällen gesperrt werden, wodurch die Arbeit mit diesen Systemen stillsteht. Selbst wenn keine Sperrung der operativen Systeme erforderlich ist, werden diese durch den Extraktionsprozess stark belastet. Diese Punkte begründen, warum die Extraktion meistens in einem kleinen Zeitfenster außerhalb der üblichen Geschäftszeiten stattfinden soll (Bauer & Günzel, 2004). Neben den Anforderungen der Umgebung ist zu beachten, dass aufgrund der häufig sehr großen Datenmengen, die in ETL Prozessen verarbeitet werden, diese sehr ressourcenintensiv werden können. Eine Verbesserung der Leistung kann daher sehr erstrebenswert sein. Die Leistung von ETL Prozessen wird von vielen Faktoren beeinflusst. In dieser Arbeit sollen nur die Faktoren betrachtet werden, die durch Designentscheidungen beeinflusst werden können. Die physikalisch technischen Aspekte, die neben den logisch konzeptionellen eine wichtige Rolle für die Leistung spielen, sollen hier nicht näher betrachtet werden. Aus diesem Grund wird zur Bewertung der Performance kein Benchmarking anhand von Durchlaufzeiten eingeführt, sondern lediglich die Entwicklungstendenz, also ob eine Verbesserung oder Verschlechterung stattgefunden hat, dargestellt Zuverlässigkeit Zuverlässigkeit beschreibt die Eigenschaft, unter gleichen Bedingungen reproduzierbar korrekte Ergebnisse zu erzielen. Außerdem bezeichnet sie die Fähigkeit eines Systems, bei Erreichen eines unerwarteten Zustands, etwa durch Fehlbedienung oder Teilausfälle, wieder in einen stabilen Zustand zurückzukehren. Wichtig für die Bewertung der Zuverlässigkeit ist, ob Fehler bereits bei der Implementierung erkannt werden können oder erst zur Laufzeit auftreten (Liggesmeyer, 2002, S. 9). Im Zusammenhang von ETL Prozessen wird Zuverlässigkeit unter anderem durch die Fähigkeit zur Wiederaufnahme gescheiterter bzw. zur Fortsetzung unterbrochener Prozesse gewährleistet Bewertung der Zielerfüllung Um in den folgenden Abschnitten die Auswirkungen von Veränderungen am Design bewerten zu können, wird die Veränderung der Zielerfüllung anhand einer fünfstelligen Skala dargestellt. Hierbei findet immer ein Vergleich zwischen dem jeweiligen Ausgangsbeispiel und der jeweilig aktuellen Variante statt. Die Bewertungsskala ist nachfolgend in einer Tabelle dargestellt Symbol Veränderung gegenüber Referenz stark verschlechtert verschlechtert unverändert verbessert stark verbessert Tabelle 2: Symbolik zur Bewertung der Zielerfüllung 3.2 Maße Übersicht Verschiedene Maße beeinflussen die definierten Designziele. In den folgenden Untersuchungen dienen Sie dazu, Auswirkungen von Veränderungen an Beispielen in einer systematischen Form zu erfassen und dadurch Vergleichbarkeit zu schaffen. ETL-Design Optimierung Seite 25 von 108

26 Zum Teil beeinflussen sich die Maße gegenseitig, so dass es zu Wechselwirkungen kommt. Die Maße können in zwei Gruppen, quantitative und qualitative, unterteilt werden. Beide Gruppen unterscheiden sich durch die Art ihrer Erhebung. Quantitative und qualitative Maße Während sich quantitativen Maße berechnen und in Form eines Messwertes darstellen lassen, müssen die qualitativen diskutiert und begründet werden. Hierdurch unterliegen qualitativen Maße, im Gegensatz zu den quantitativen, einer subjektiven Beurteilung. Dementsprechend muss ihre Ausprägung begründet werden und kann im Einzelfall zur Diskussion stehen. Quantitative Maße werden in den folgenden Beispielen anhand ihres Messwerts erhoben. Für qualitative wird eine fünfstellige Bewertungsskala eingeführt, anhand derer die Ausprägung dargestellt wird. Die Ausprägungen reichen dabei von sehr schwach bis sehr stark, wie in der nachfolgenden Tabelle verdeutlicht wird. Neutral beschreibt dabei eine durchschnittliche Ausprägung. Symbol n/a n.v Ausprägung nicht erhoben nicht vorhanden sehr schwach schwach neutral stark sehr stark Tabelle 3: Ausprägung der qualitativen Einflussfaktoren Diese Skala bewertet Veränderungen an Maßen nicht, sondern erfasst sie ausschließlich. Welche Ausprägung sich positiv auf Designziele auswirkt, ist unterschiedlich. So wird beispielsweise im Allgemeinen eine möglichst starke Kohäsion angestrebt, die Kopplung hingegen sollte möglichst gering sein. Welchen Einfluss die jeweiligen Ausprägungen haben, wird in den Beispielen für jedes Designziel diskutiert Quantitative Maße Datenmenge Die Datenmenge kann auf mehreren Ebenen betrachtet werden. Zum einen als Anzahl der Tupel, wobei hier die Breite der Tupel nicht berücksichtigt wird. Diese Betrachtung ist, bei der Diskussion von Transformationen die die Zeilenanzahl manipulieren, ausreichend. Eine weitere, genauere Möglichkeit besteht darin, Zeilen und Spalten der Tupel miteinander zu multiplizieren. Diese Betrachtung liefert eine Kenngröße der tatsächlichen Datenmenge. Bei der Diskussion von Transformationen, die die Anzahl der Spalten manipulieren, muss diese Art der Betrachtung gewählt werden. Zur Bewertung von Optimierungsmaßnahmen muss die Datenmenge auf Transformationsebene betrachtet werden, das heißt, es wird betrachtet, wie eine Transformation die Datenmenge verändert. Grundsätzlich ist eine Verringerung der Datenmenge anzustreben. Dies kann beispielsweise durch Selektionen und Aggregationen, was die Zahl der Tupel verringert, oder durch Projektion, wodurch nicht benötigte Attribute entfallen, erzielt werden. Die Datenmenge lässt sich quantitativ erheben: ETL-Design Optimierung Seite 26 von 108

27 Da sich in Transformationen häufig nur die Zeilenanzahl ändert, ist zum Aufzeigen der Entwicklung eine vereinfachte Betrachtung der Datenmenge: häufig ausreichend. Solange nicht anders angegeben, wird unter Datenmenge die Anzahl der Tupel verstanden. Beide Varianten der Messgröße stellen nur eine logische Erhebung der Datenmenge dar, der physikalische Speicherbedarf wird damit nicht berücksichtigt Anzahl der Knoten Sieht man einen ETL Prozess beziehungsweise ein Mapping als Graphen, kann man die Anzahl der Knoten innerhalb dieses Graphen betrachten. Innerhalb eines Mappings ist jede Transformation, also jeder dedizierte Verarbeitungsschritt, ein Knoten. Auf höherer Ebene können auch Mapplets oder Sessions als Knoten des ETL Prozess-Graphen angesehen werden. Dieses Maß entspricht der von (Vassiliads, Simitsis, Terrovitis, & Skiadopoulos, 2005) eingeführten Size. Die Bezeichnung Anzahl der Knoten wurde für ein intuitiveres Verständnis gewählt Komplexität Unter Komplexität wird im ETL Kontext die Anzahl der verbundenen Kanten zwischen den Knoten verstanden (Vassiliads, Simitsis, Terrovitis, & Skiadopoulos, 2005). Die Komplexität kann ab der Mappingebene und für alle höheren Betrachtungsebenen untersucht werden. In Informatica wird die Komplexität durch die Anzahl der verbundenen Ports der einzelnen Transformationen bestimmt Länge Die Länge beschreibt nach (Vassiliads, Simitsis, Terrovitis, & Skiadopoulos, 2005) die maximale Anzahl an Weiterleitungen, die ein Attribut durchläuft. Die Länge eines Mappings berechnet sich durch die maximale transitive Abhängigkeit eines Attributs von vorherigen Transformationen Qualitative Maße Neben den quantitativen gibt es qualitative Maße zur Formalisierung bestimmter Einflussfaktoren. Diese werden nachfolgend eingeführt Modularität Unter Modularität versteht man die Aufteilung von Funktionalität auf Module. Ein Modul stellt dabei eine in sich geschlossene Einheit dar, die Funktionen über Schnittstellen zur Nutzung bereitstellt. ETL-Design Optimierung Seite 27 von 108

28 Wesentlich für ein Modul ist die aus technischer Sicht weitestgehend kontextunabhängige Nutzbarkeit. Dieses qualitative Maß ist aus der Softwaretechnik abgeleitet, wo Modularität eine wichtige Rolle spielt (Balzert H., 1998, S. 572) Kapselung Mit dem Begriff der Modularität geht eng der Begriff der Kapselung einher. Kapselung beschreibt, wie stark die Funktionalität eines Elements oder eines Moduls nach außen verborgen ist. Zusätzlich spielt hierbei eine Rolle, wie viele Funktionen innerhalb eines Elements zusammengefasst werden. Zur Verdeutlichung kann hier das Geheimnisprinzip aus der Softwaretechnik herangezogen werden. Dieses besagt, dass Funktionen eines Elements innerhalb des selbigen verborgen sein sollen. Die Details der Implementierung sind also den Nutzern der Funktionen des Elements nicht bekannt (Balzert H., 1998, S. 572) Universalität Wie universell ein Element beziehungsweise eine Komponente einsetzbar ist, hängt davon ab, wie generell sie entwickelt wurde. Das Gegenteil von Universalität ist Spezifität. Ein Element mit hoher Universalität kann in verschiedenen Szenarien mit geringem Anpassungsaufwand eingesetzt werden, wohingegen ein spezialisiertes Element üblicherweise nur in einem konkreten Anwendungsfall genutzt werden kann Kohäsion Nach (Balzert H., 1998, S. 474) ist die Kohäsion oder auch Bindung in der Softwaretechnik ein qualitatives Maß für die Kompaktheit einer Systemkomponente. Aus dieser Beschreibung geht hervor, dass die Kohäsion im Zusammenhang von Modularisierung und Strukturierung eine wichtige Rolle spielt. Beleuchtungsgegenstand der Kohäsion ist, wie eng die einzelnen Elemente einer Komponente verbunden sind und wie viele Aufgaben durch sie erledigt werden. Das Maß der Kohäsion soll in dieser Arbeit aus der Softwaretechnik auf ETL Prozesse und Mappings übertragen werden und zur Bewertung des Zielerfüllungsgrades dienen. Die Kohäsion spielt insbesondere bei der Untersuchung von Mapplets eine Rolle, kann aber auch auf Transformationsebene aufschlussreich sein. Eine gute, also starke Kohäsion liegt nach (Balzert H., 1998, S. 474) dann vor, wenn nur solche Elemente zu einer Einheit zusammengefasst werden, die auch zusammengehören. In der Literatur wird zwischen verschiedenen Arten von Kohäsion unterschieden. Diese reicht in sieben Stufen von der zufälligen Kohäsion als schwächste bis zur funktionalen Kohäsion als stärkste Form. Letztere liegt dann vor, wenn alle Elemente an der Verwirklichung einer einzigen, abgeschlossenen Funktion beteiligt sind. (Balzert H., 1998, S. 475) Die Art und Stärke der Kohäsion lässt sich laut (Balzert H., 1998) nicht automatisch ermitteln. Balzert nennt jedoch Kennzeichen zur Identifikation der funktionalen Kohäsion. Diese sind: Alle Elemente tragen zur Erreichung eines einzelnen, spezifischen Ziels bei. Es gibt keine überflüssigen Elemente. Die Aufgabe der Komponente lässt sich durch genau ein Verb beschreiben. Eine Komponente ist durch eine andere, die den gleichen Zweck erfüllt, aber unterschiedlich implementiert ist, austauschbar. Es liegt eine hohe Kontextunabhängigkeit vor, das heißt, es bestehen einfache Beziehungen zu anderen Komponenten. ETL-Design Optimierung Seite 28 von 108

29 Aus den beschriebenen Merkmalen resultieren nach Balzert folgende Vorteile: Hohe Kontextunabhängigkeit Geringere Fehleranfälligkeit bei Änderungen Geringere Spezialisierung und dadurch hoher Grad an Wiederverwendbarkeit Verbesserte Erweiterbarkeit und Wartbarkeit, da sich Änderungen auf isolierte Teile beschränken. (Balzert H., 1998, S. 476) Es liegt die Vermutung nahe, dass diese Kennzeichen und Auswirkungen sich aus der Softwaretechnik direkt auf die hier durchgeführten Untersuchungen übertragen lassen. In der Auseinandersetzung mit Beispielen soll diese Vermutung überprüft werden Kopplung Der Begriff der Kopplung ist eng mit dem der Kohäsion verbunden. Während die Kohäsion die Aufgabenspezifität der Elemente beschreibt, ist die Kopplung ein qualitatives Maß für die Schnittstellen zwischen Komponenten. Nach (Balzert H., 1998, S. 474) ist in der Softwaretechnik eine ausgeprägte Struktur eines Systems erstrebenswert, da sie zu einem hohen Maß an Einfachheit, guter Verständlichkeit und leichter Einarbeitung führt. Die Strukturausprägung ist umso größer, je stärker die Bindungen der Systemkomponenten im Vergleich zu den Kopplungen zwischen ihnen sind. Diese Forderung und ihre Bedingungen sind vermutlich aus der Softwaretechnik auf die hier untersuchten ETL Prozesse übertragbar. In den zu behandelnden Beispielen wird dies näher untersucht. Zur Bestimmung der Kopplung wird untersucht, wie stark einzelne Elemente Verbindungen miteinander eingehen. Zu unterscheiden ist dabei zwischen Mappings, die Mapplets verwenden, und solchen, die nur aus Transformationen bestehen. Auf Transformationsebene wird die Kopplung durch die ein- beziehungsweise ausgehenden Kanten, also die verbundenen Ports, bestimmt. Auf dieser Ebene korreliert sie dementsprechend sehr stark mit der Komplexität. Für Mapplets wird die Anbindung der Ein- und Ausgabetransformationen an das außenliegende Mapping betrachtet. Innerhalb von Mapplets liegt wiederum Transformationskopplung vor. Die Transformationskopplung wird auch als intramodulare Kopplung bezeichnet, die zwischen Mapplets als intermodulare. In der Softwaretechnik wird angenommen, dass eine schwache Kohäsion zu einer stärkeren Kopplung führt, sich also bei einer geringeren Spezifikation einzelner Elemente die Anzahl der Verbindungen in der Regel erhöht. Das würde eine direkte Abhängigkeit dieser Maße bedeuten. Dieser Zusammenhang soll anhand von Beispielen auf seine Gültigkeit im ETL Kontext überprüft werden. (Vassiliads, Simitsis, Terrovitis, & Skiadopoulos, 2005) gehen davon aus, dass eine schwächere Kopplung, vor allem in Verbindung mit stärkerer Kohäsion, zu einer Verbesserung in Bezug auf Wartbarkeit und Wiederverwendbarkeit führt. ETL-Design Optimierung Seite 29 von 108

30 4 ETL-Design Optimierung Oft ist es möglich, die gleichen fachkonzeptionellen Anforderungen auf verschiedene Weise zu erfüllen. Um ein optimales Ergebnis zu erreichen, müssen dem Entwickler Alternativen bekannt sein, und er muss diese für sein Szenario gegeneinander abwägen. Um Alternativen vergleichbar zu machen, wurden in dieser Arbeit bereits Designziele und darauf wirkende Maße identifiziert. Nach (Simitsis, Vassiliadis, & Sellis, 2005) sind bei allen Optimierungsmaßnahmen im Wesentlichen zwei Punkte zu prüfen: 1. Bleibt die Korrektheit erhalten? Dies ist gegeben, wenn die geänderte Variante aus fachlicher Sicht äquivalent zur ursprünglichen ist, 2. Werden die angestrebten Ziele durch die Änderungen in höherem Maße erfüllt? Dies ist die Voraussetzung dafür, dass eine Optimierung stattgefunden hat. Im Folgenden sollen anhand verschiedener Beispiele typische Szenarien, in denen mehrere Alternativen möglich sind, vorgestellt, diskutiert und bewertet werden. Folgende Fälle werden untersucht: Positionierung von Transformationen (Swap) Oft kann eine Transformation an verschiedenen Stellen innerhalb eines Mappings, und damit innerhalb des Datenflusses, eingebunden werden. Hierbei bieten sich verschiedene Vorgehen zur Erreichung bestimmter Ziele an. Dieser Ansatz wird von (Vassiliads, Simitsis, Terrovitis, & Skiadopoulos, 2005) als Swap bezeichnet. Ein besonderer Fall der Umpositionierung ist die Auslagerung von Funktionalität in die Datenbank. Auch dies wird anhand von Beispielen diskutiert. Austausch von Transformationen Sollten gleiche Anforderungen unter Nutzung verschiedener Transformationen umsetzbar sein, muss überprüft werden, welche Transformation am besten geeignet ist sowohl die Aufgabe zu lösen als auch die vereinbarten Ziele in möglichst großem Maß zu erfüllen. Zusammenfassen oder Aufteilen (Merge and Split) Von (Vassiliads, Simitsis, Terrovitis, & Skiadopoulos, 2005) wird der Merge and Split Ansatz eingeführt. Bei dem Optimierungsansatz Zusammenführen (merge) werden Operationen, die ursprünglich auf mehrere Transformationen verteilt waren, in einer Transformation zusammengefasst. Im Gegensatz dazu werden bei Aufteilen (split) die in einer Transformation durchzuführenden Operationen auf mehrere Transformationen verteilt. Modularisierung Mapplets bieten die Möglichkeit Transformationen zu Modulen zusammenzufassen, die ETL-Design Optimierung Seite 30 von 108

31 anschließend über Ein- und Ausgabeschnittstellen genutzt werden. Als Module verbergen Mapplets Implementierungsdetails. Außerdem sind sie wiederverwendbar. Parametrisierung Parameter können in Transformationen dazu eingesetzt werden, Bedingungen dynamisch festzulegen. Dies wirkt sich meist auf die Universalität und damit auf die Wiederverwendbarkeit aus. Sortierung von Daten Ob und wenn ja welchen Einfluss eine Vorsortierung von Daten hat, wird in einem Beispiel untersucht. 4.1 Vorgehensweise Nachfolgend wird zuerst ein Beispielszenario vorgestellt. Anhand dieses Szenarios werden anschließend verschiedene Beispiele und Varianten davon analysiert. Das Vorgehen dabei folgt jedes Mal dem gleichen Schema. 1) Optimierungsansatz Zuerst wird der zu untersuchende Optimierungsansatz vorgestellt. Dabei werden, wenn diese schon absehbar sind, Potentiale dieser Ansätze aufgezeigt. 2) Vorstellung verwendeter Transformationen Wo es zum Verständnis notwendig ist, werden die eingesetzten Transformationen in ihrer Funktionsweise vorgestellt. 3) Ausgangsbeispiel Dann wird eine Ausgangsituation in Form eines konkreten Mappings geschaffen. Anhand dieser Ausgangssituation wird ein bestimmter Optimierungsaspekt untersucht. Hierbei werden die fachliche Intension und die daraus resultierenden Rahmenbedingungen des jeweiligen Beispiels dargestellt. a) Erfassung der Maße Für jedes Ausgangsmapping werden zuerst die quantitativen Maße erhoben. Anschließend wird die Ausprägung der qualitativen Maße festgestellt. Aufgrund ihres subjektiven Charakters wird jede Ausprägung begründet. Nach der Erhebung der Maße im Ausgangsbeispiel, werden diese zusammengefasst in einer Übersichtstabelle dargestellt. b) Designziele des Ausgangsbeispiels Für das Ausgangsbeispiel werden Die Designziele nicht ausführlich diskutiert. Es wird nur auf besondere Auffälligkeiten hingewiesen. Das Ausgangsbeispiel dient mit den dafür erfassten Maßen als Vergleichsreferenz für weitere Varianten desselben Beispiels. 4) Voraussetzungen der Änderungen Bevor Varianten des Ausgangsbeispiels vorgestellt werden, werden eventuelle, fachliche und technische, Voraussetzungen für die vorgesehenen Änderungen aufgezeigt. 5) Variante des Ausgangsbeispiels Die Ausgangsvariante wird zur Untersuchung des Optimierungsansatzes in einem Punkt geändert. a) Erfassung der Maße Für die geänderte Variante werden die Maße erfasst. Dies erfolgt nach dem gleichen Vorgehen wie im Ausgangsbeispiel. b) Analyse der Designziele ETL-Design Optimierung Seite 31 von 108

32 Auf Grundlage der Maße werden die Auswirkungen der vorgenommen Änderungen für jedes Ziel diskutiert und bewertet. Als Vergleich dient hierbei die Ausgangsvariante. Jede Analyse wird mit einer Übersichtstabelle und einer Zusammenfassung abgeschlossen. 6) Untersuchung weiterer Varianten Gegebenenfalls werden in weiteren Varianten die Auswirkungen anderer Änderungen untersucht. Das Vorgehen entspricht dabei dem der ersten Variante. Jede weitere Variante geht wieder vom Ausgangsbeispiel aus und zieht dieses zur Bewertung der Ziele heran. 7) Zusammenfassung des Optimierungsansatzes Nach der Vorstellung und Analyse verschiedener Varianten, werden die in den Untersuchungen gewonnenen Erkenntnisse über den Optimierungsansatz zusammengefasst. Dieses einheitliche Untersuchungsschema dient für die folgenden Analysen als Schablone. Durch das systematische Vorgehen wird die Vergleichbarkeit einzelner Analysen gewährleistet. Darüber hinaus ermöglicht es jederzeit das Vorgehen nachzuvollziehen. 4.2 Beispielszenario Die Untersuchungen der Ziele und der auf sie wirkenden Maße finden anhand von verschiedenen Beispielen statt. Alle Beispiele basieren auf der Datenbank des Open Source Programms für Projektmanagement dotproject. Da die Datenbank sehr komplex ist, wird im Rahmen dieser Arbeit nur ein kleiner Ausschnitt der fachlich besonders interessanten Tabellen und ihrer jeweiligen Attribute verwendet. Durch diese Vereinfachung wird gewährleistet, dass die Beispiele nachvollziehbar bleiben. Vor Beginn der Untersuchungen dieser Arbeit wurde die vollständige Datenbank der Anwendung von MySQL nach Oracle XE 10g migriert. Dies ist unter anderem dadurch begründet, dass für Verbindungen zu Oracle in Informatica PowerCenter 8 native Treiber zur Verfügung stehen, während auf MySQL Datenbanken mittels ODBC zugegriffen werden muss. Hierin besteht das Risiko, dass der ODBC Treiber sich auf Untersuchungen auswirkt und Ergebnisse verfälscht. Alle nachfolgenden Untersuchungen finden daher auf einer Oracle XE 10g Datenbank statt. Um die Untersuchungen dieser Arbeit zu unterstützen, wurden sowohl die Schemata einiger Tabellen als auch die darin enthaltenen Daten manipuliert Datenquellen In dotproject werden Projekte, Aufgaben und Aufgabenlogs in separaten Tabellen vorgehalten. Hierbei beinhalten sie unterschiedlichen Informationsgehalt und stehen zueinander durch Fremdschlüssel in Beziehung. Bei der Migration auf Oracle wurden die Fremdschlüsselbeziehungen entfernt. Dies war notwendig, da Oracle für Schlüsselattribute automatisch einen Index erzeugt. Zur Untersuchung der Auswirkungen eines Indexes musste aber die Möglichkeit geschaffen werden, diesen zu aktivieren, bzw. zu deaktivieren. Im Rahmen dieser Arbeit kann aber davon ausgegangen werden, dass sich die Quellen in einem konsistenten Zustand befinden Aufgabenlogbuch Die Zeiterfassung in dotproject geschieht auf Basis des Aufgabenlogbuchs, dem die Tabelle TASK_LOG zugrunde liegt. In dieser Tabelle werden geleistete Stunden sowie ein zugehöriger Kostenfaktor pro Eintrag erfasst. Ein Tupel aus dem Aufgabenlogbuch besitzt jedoch keinen Namen, ETL-Design Optimierung Seite 32 von 108

33 sondern wird über eine Fremdschlüsselbeziehung mit dem Attribut TASK_LOG_TASK einer Aufgabe zugeordnet. CREATE TABLE task_log_new_1 ( task_log_id INTEGER(11) NOT NULL, task_log_task INTEGER(11) NOT NULL, task_log_hours FLOAT NOT NULL, task_log_costcode VARCHAR(8) NOT NULL, ); Aufgaben Aufgaben werden von der Anwendung in der Tabelle TASKS gespeichert. Eine Aufgabe besitzt eine ID (TASK_ID), einen Namen (TASK_NAME) und gehört immer zu einem Projekt (TASK_PROJECT). CREATE TABLE tasks ( task_id INTEGER(10) NOT NULL, task_name VARCHAR(255) NOT NULL, task_project INTEGER(11) NOT NULL, ); Projekte Einzelne Aufgaben werden in Projekten zusammengefasst. Die Daten eines Projekts werden in der Tabelle PROJECTS gespeichert. Für jedes Projekt wird die ID (PROJECT_ID) und der Name (PROJECT_NAME) gespeichert. CREATE TABLE projects ( project_id INTEGER(11) NOT NULL, project_name VARCHAR(255) NOT NULL, ); Die 1:n Beziehung zwischen den Entitäten gestaltet sich wie folgt: Abbildung 7: Schematische Darstellung der Fremdschlüsselbeziehungen Zu beachten ist, dass die Fremdschlüsselbeziehungen hier nur die Ausgangssituation der Datenbank darstellen. Diese wurden aufgrund der geschilderten Indexproblematik entfernt. ETL-Design Optimierung Seite 33 von 108

34 Datenmenge der Quelltabellen Für die Untersuchung einiger Maße kann die Datenmenge relevant sein. In der Ausgangssituation waren nur sehr wenige Tupel in der dotproject Datenbank enthalten. Eine geringe Datenmenge lässt Untersuchungen der Performance ungenau werden, da die Initialisierungsdauer des Integrationsservers in diesem Fall größer ist als die eigentliche Verarbeitung der Daten. Daher wurden die Daten mittels eines PL/SQL Scripts künstlich erhöht. Um die Beziehung zwischen den Entitäten zu erhalten, wurden nur der Tabelle TASK_LOG Tupel hinzugefügt. Die Tabellen enthalten folgende Anzahl an Tupeln: Tabelle Anzahl Tupel Tupel * Attribute TASK_LOG TASKS PROJECTS Tabelle 4: Datenmengen im Beispielszenario Zieltabellen In den Beispielen werden die vorgestellten Quelldaten verwendet, um verschiedene Transformationen durchzuführen. Zum Teil werden zusätzliche Attribute zum Beispiel durch Berechnungen generiert, in anderen Fällen können Attribute entfallen. Die Zielschemata unterscheiden sich entsprechend zwischen den verschiedenen Beispielen. Aus diesem Grund werden diese jeweils in den Beispielen vorgestellt. Grundsätzlich sind alle Ziele Tabellen in einer Oracle XE 10g Datenbank. 4.3 Positionierung von Transformationen Durch eine unterschiedliche Positionierung von Transformationen innerhalb eines Mappings kann der Erfüllungsgrad der angestrebten Ziele positiv beeinflusst werden. Anhand von zwei Beispielen in verschiedenen Varianten wird diese Option diskutiert Filtertransformation - Fallbeispiel 1 Sollen aus einem ETL Workflow Daten gefiltert werden, steht hierfür in Informatica PowerCenter 8 die Filtertransformation zur Verfügung. Sie funktioniert wie eine where Klausel in einem SQL Statement, es passieren also diejenigen Daten den Filter, auf die die Filterbedingung zutrifft. (Informatica, PowerCenter Transformation Guide, 2006, S. 216) Filtertransformationen können unter bestimmten Voraussetzungen an verschiedenen Stellen in den Datenfluss eingebunden werden. Neben der expliziten Filtertransformation ist auch eine Filterung im Source Qualifier, also auf der Datenbank beim Einlesen der Datenquellen, möglich. Soll die Filterung anhand von Charakteristika der Daten, die sich erst durch andere Transformationen ergeben, durchgeführt werden, bleibt nur die Möglichkeit einer expliziten Filterung. Dies können beispielsweise vorangegangene Expression-, Aggregations-, Lookup- oder Joinertransformationen oder andere sein. Nachfolgend werden anhand mehrerer Varianten eines Beispiels die Auswirkungen verschiedener Filterpositionen auf die Maße und die Ziele verdeutlicht. Neben einer Untersuchung der ETL-Design Optimierung Seite 34 von 108

35 Auswirkungen verschiedener Positionen einer expliziten Filtertransformation soll auch die Filterung im Source Qualifier untersucht werden Fallbeispiel 1 - Positionierung eines Filters Es sollen Daten aus den Tabellen TASK_LOG und TASKS anhand der Bedingung TASK_LOG.TASK_LOG_TASK = TASKS.TASK_ID per Joinertransformation zusammengeführt werden und in ein Ziel geschrieben werden. Für das Beispiel sei angenommen, dass aus fachlichen Gründen eine Filterung der Daten vorgenommen werden soll. Die Filterbedingung des Ausgangsbeispiels wird durch TASK_LOG.TASK_LOG_HOURS > 5 definiert. Diese Bedingung bewirkt, dass nur Tupel, in denen mehr als fünf Stunden verbucht sind, den Filter passieren. Abbildung 8: Fallbeispiel 1 Ausgangsbeispiel - Filtertransformation Die Filterbedingung bestimmt die Abhängigkeit von vorausgehenden Transformationen und somit ob, die Filtertransformation an anderer Position in den Datenfluss einfügt werden kann. In den folgenden Varianten wird untersucht, wann unterschiedliche Positionen möglich sind und wie diese sich auf die Maße auswirken. Aus dieser Analyse werden anschließend Schlussfolgerungen auf den jeweiligen Zielerfüllungsgrad gezogen. Erhebung der Maße im Ausgangsbeispiel Um eine Vergleichbarkeit der Varianten zu ermöglichen, müssen zuerst die quantitativen und qualitativen Maße des Fallbeispiels untersucht werden. Quantitative Maße Datenmenge Aus der Tabelle TASK_LOG werden Tupel eingelesen, aus der Tabelle TASKS 133. In der JOINER Transformation werden diese, unter der Joinbedingung TASK_LOG_TASK = TASK_ID, zusammengeführt, so dass danach alle in die Filtertransformation eingehen. Die Filtertransformation passieren 350 Tupel, die danach in das Ziel geschrieben werden Tupel werden verworfen, da sie der Filterbedingung widersprechen. Anzahl der Knoten Das Referenzbeispiel weist inklusive der Quellen und des Ziels 7 Transformationen auf. Länge Im Beispiel durchlaufen alle Tupel das gesamte Mapping. Die maximale Anzahl an Weiterleitungen beträgt 4. ETL-Design Optimierung Seite 35 von 108

36 Komplexität Die Transformationen sind über 28 Kanten miteinander verbunden, was der Komplexität entspricht. Qualitative Maße Modularität Im Referenzbeispiel ist keine Modularität zu erkennen. Jede Transformation führt exakt eine Aufgabe aus und es gibt keine Zusammenfassung von Transformationen. Eine Modulbildung findet nicht statt. Kapselung Das vorliegende Beispiel weist keine über das Minimalmaß hinausgehende Kapselung auf. Jede Transformation führt genau eine Operation aus, die anhand ihres Typs und Namens in der Mapping- Übersicht erkennbar ist. Universalität Das Mapping ist sehr spezifisch auf den entsprechenden Anwendungsfall zugeschnitten. Die Universalität ist also schwach ausgeprägt. Kohäsion Durch die fehlende Modularität ist das Mapping bezüglich der Kohäsion wenig aussagekräftig. Die Kohäsion der einzelnen Transformationen ist aufgrund der eindeutigen Aufgabenspezifität sehr hoch. Diese soll jedoch nicht explizit betrachtet werden, da Transformationen als das atomare Element betrachtet werden und Kohäsion erst auf Modulebene sinnvoll analysiert werden kann. In Ausnahmefällen ist eine Betrachtung bei Transformationen, die mehrere Funktionen in sich vereinen, möglich und sinnvoll. In diesem Beispiel ist das jedoch nicht der Fall, weswegen die Kohäsion nicht erhoben wird. Kopplung Das Fallbeispiel weist eine starke Kopplung zwischen den Transformationen auf. Intermodulare Kopplung ist aufgrund der fehlenden Module nicht zu erkennen. Übersicht über die Maße Die zwei folgenden Tabellen liefern eine Übersicht über die soeben erhobenen Maße. Hierbei werden zuerst die quantitativen, danach die qualitativen Maße dargestellt. Quantitative Maße Maß: Datenmenge Anzahl Knoten Länge Komplexität Messwert: Eingehende Tupel 350 Tupel nach Filter Tabelle 5: Fallbeispiel 1 - Ausgangsbeispiel - Quantitative Maße Qualitative Maße Maß Modularität Kapselung Universalität Kohäsion Kopplung ETL-Design Optimierung Seite 36 von 108

37 Ausprägung n.v. n.v. - n/a + Tabelle 6: Fallbeispiel 1 - Ausgangsbeispiel - Qualitative Maße Untersuchung der Ziele Das vorliegende Ausgangsbeispiel soll für die nächsten Varianten als Referenz dienen. Die Zielerfüllung wird relativ durch den Vergleich der verschiedenen Varianten bewertet. Es werden also Verbesserungen beziehungsweise Verschlechterungen aufgezeigt. Entsprechend seiner Funktion als Referenz wird dieses Beispiel neutral bewertet. Da Verletzung der Korrektheit alle weiteren Betrachtungen obsolet macht, wird diese immer als erstes verifiziert. Innerhalb der Übersichtstabellen wird sie nicht explizit dargestellt, da sie im Regelfall unverletzt sein sollte. Im gegenteiligen Fall wird keine Übersicht über die Ziele dargestellt, sondern auf die Verletzung der Korrektheit verwiesen. Variante / Ziel Wartbarkeit Wiederverwendbarkeit Performance Zuverlässigkeit Ausprägung Tabelle 7: Fallbeispiel 1 - Ausgangsbeispiel - Übersicht über die Ziele Voraussetzungen für eine Umpositionierung der Filtertransformation Die Positionsänderung soll zu einem äquivalenten Ergebnis in den Zieltabellen führen, was Bedingung für das definierte Ziel Korrektheit ist. Dies ist nur unter bestimmten Voraussetzungen gewährleistet. Drei Fälle beeinflussen hier die Auswahlmöglichkeiten. 1. Die Filterbedingung ist von einer vorausgehenden Transformation abhängig: Wenn das in der Filterbedingung zu prüfende Attribut erst in einer Transformation generiert wird, kann die Filtertransformation nicht vor dieser Transformation positioniert werden. 2. Die Filterbedingung ist von der vorherigen Transformation unabhängig: Die Filtertransformation kann mit ihrem Vorgänger die Position tauschen und somit früher ausgeführt werden. 3. Die Filterbedingung ist von keiner Transformation des Mappings abhängig: Eine Filterung im Source Qualifier ist möglich. Hierbei werden die Zeilen beim Lesen aus der Quelle verworfen und gelangen somit gar nicht in das Mapping. Diese Möglichkeit existiert jedoch nur für relationale Quellen. ETL-Design Optimierung Seite 37 von 108

38 Variante 1 Als Beispiel für die erste Variation werden wieder beide Tabellen mittels Joinertransformation zusammengeführt. Die Filtertransformation selektiert alle Tupel, bei denen das Attribut TASK_LOG.TASK_LOG_HOURS mehr als fünf Stunden geleistete Arbeit aufweist, und lässt diese den Filter passieren. Die Bedingung ist also die gleiche wie im Ausgangsbeispiel und die Filtertransformation von der vorhergehenden Joinertransformation unabhängig. Daraus folgt, dass ein Positionswechsel möglich ist. In der folgenden Abbildung wird das geänderte Mapping, in dem die Filtertransformation vor der Joinertransformation stattfindet, dargestellt. Abbildung 9: Fallbeispiel 1 - Variante 1 - Nach vorne verschobener Filter Auswirkungen auf die Maße Nachfolgend wird untersucht, inwiefern sich die Maße durch die Manipulationen in der neuen Variante verändert haben. Quantitative Maße Datenmenge Wie im Ausgangsbeispiel gehen Tupel aus TASK_LOG und 133 Tupel aus TASKS in das Mapping ein. Erneut passieren 350 Tupel den Filter, während verworfen werden. Dies geschieht in der Variante 1 früher, wodurch in der Joinertransformation nur noch 350 Tupel aus TASK_LOG und 133 aus TASKS also insgesamt 483 Tupel verarbeitet werden. Anzahl der Knoten Diese Messgröße wird durch die Veränderungen nicht beeinflusst und beträgt somit weiterhin 7. Länge Die Länge bleibt gleich wie im Ausgangsbeispiel, sie beträgt 4. Komplexität Die Komplexität wird durch die frühe Filterung leicht reduziert und beträgt jetzt 25. Dies entspricht einer Reduktion um 3 Kanten. ETL-Design Optimierung Seite 38 von 108

39 Qualitative Maße Von den qualitativen Maßen ändert sich nur die Kopplung. Da die Filterung nur noch unter Einbeziehung der Attribute aus TASK_LOG stattfindet, verringert sich die Kopplung der Filtertransformation. Da weiterhin alle Attribute jeweils über ein- und ausgehende Ports verbunden sind, wird die Kopplung mit durchschnittlich (0) bewertet. Übersicht über die Maße Quantitative Maße Maß: Datenmenge Anzahl Knoten Länge Komplexität Messwert: Eingehende Tupel 350 Tupel nach Filter Tabelle 8: Fallbeispiel 1 - Variante 1 - Quantitative Maße Qualitative Maße Maß Modularität Kapselung Universalität Kohäsion Kopplung Ausprägung n.v. n.v. - n/a 0 Tabelle 9: Fallbeispiel 1 - Variante 1 - Qualitative Maße Auswirkungen der Alternative auf den Erfüllungsgrad der Ziele Durch die Veränderungen an dem Ausgangsmapping haben sich einige Maße geändert. Dies wirkt sich auf die Ziele aus, was nachfolgend erläutert und diskutiert werden soll. Korrektheit Variante eins und das Ausgangsbeispiel sind bezüglich der Daten die in das Ziel geschrieben werden äquivalent. Das heißt, das Mapping bleibt durch die neue Position der Filtertransformation fachlich korrekt. Dies macht eine Betrachtung der weiteren Ziele erforderlich. Wartbarkeit Die Wartbarkeit des Mappings wird durch die neue Position des Filters gegenüber dem Ausgangsmapping nicht wesentlich beeinflusst. Die Verringerung von Komplexität und Kopplung ist so gering, dass dies die Wartbarkeit nicht verbessert. Wiederverwendbarkeit Die Wiederverwendbarkeit wird nicht beeinflusst. Performance Durch die frühere Reduktion der Datenmenge wird die Effizienz gesteigert beziehungsweise die Durchlaufzeit verringert. Da die Joinertransformation sehr aufwendig ist, kann diese Variante deutlich von der reduzierten Zahl an Tupeln, die in sie eingehen, profitieren. ETL-Design Optimierung Seite 39 von 108

40 Zuverlässigkeit Die Zuverlässigkeit ist im Wesentlichen unbeeinflusst, durch die frühere Filterung werden eventuell korrupte Daten früher bearbeitet und führen damit zu einem früheren Erkennen von Fehlern. Außerdem gehen durch die vorgelagerte Filterung weniger Daten in die Joinertransformation ein, wodurch auch hier die Fehleranfälligkeit reduziert wird. Insgesamt ist die Verbesserung der Zuverlässigkeit gering. Übersicht über die Ziele: Variante / Ziel Wartbarkeit Wiederverwendbarkeit Performance Zuverlässigkeit Ausgangsbeispiel Variante Tabelle 10: Fallbeispiel 1 - Variante 1 - Zielerfüllung Variante 2 In der zweiten Variante des Beispiels wird wiederum von derselben Anforderung wie in den beiden vorangegangen Beispielen ausgegangen. Es werden also alle Zeilen, für die weniger als fünf Stunden Arbeitszeit verbucht sind, ausgefiltert. Die Filterbedingung ist nur von einer der beiden Quellen abhängig. Da keine weitere Transformation vor der Filterung stattfindet, kann diese im Source Qualifier durchgeführt werden. Abbildung 10: Fallbeispiel 1 - Variante 2 - Filterung im Source Qualifier Statt in einer expliziten Filtertransformation wird in Variante 2 in der Source Qualifier Transformation, also beim Einlesen der Quelltabelle TASK_LOG gefiltert. Dies geschieht über die Definition der Filterbedingung in den Optionen des Source Qualifiers. Hierfür nutzt der Source Qualifier beim Einlesen der Daten aus der Quelltabelle eine where Klausel. Im vorliegenden Beispiel lautet das dem Source Qualifier zugrunde liegende SQL Statement dementsprechend: ETL-Design Optimierung Seite 40 von 108

41 SELECT TASK_LOG.TASK_LOG_ID, TASK_LOG.TASK_LOG_TASK, TASK_LOG.TASK_LOG_HOURS, TASK_LOG.TASK_LOG_COSTCODE FROM TASK_LOG WHERE TASK_LOG.TASK_LOG_HOURS > 5 Durch die Verlagerung der Filterung weist das Mapping in dieser Variante bei gleicher Funktionalität eine Transformation weniger auf. Dass eine Filterung stattfindet, ist nicht mehr direkt erkennbar. Die Auswirkung auf Maße und Ziele werden nachfolgend dargestellt und diskutiert. Erhebung der Maße in Variante 2 Quantitative Maße Datenmenge In der Quelltabelle TASK_LOG liegen wie in den bereits dargestellten Beispielen Zeilen beziehungsweise Tupel vor. In TASKS sind es wieder 133. Die Datenmenge wird in der Variante insofern beeinflusst, dass durch die Filterung im Source Qualifier nur die Tupel eingelesen werden, die den Filter passieren. Dies betrifft wie in den vorherigen Varianten 350 Tupel. Die anderen werden bereits beim Lesen der Quelle durch die WHERE Klausel verworfen. Es gelangen also nur sehr wenige Tupel überhaupt in das Mapping. Anzahl der Knoten Da der Source Qualifier sowohl die Aufgabe des Einlesens als auch die Filterung der Quellen bearbeitet kann, die Filtertransformation wegfallen. Hierdurch weist Variante 2 eine Transformation weniger als das Ausgangsbeispiel auf, besteht also aus 6 Knoten. Länge Durch den Wegfall eines Knotens wurde die Länge auf 3 reduziert. Komplexität Die Komplexität sinkt um 7 Kanten und beträgt nun 21. Auch dies ist auf die eingesparte Transformation zurückzuführen. Qualitative Maße Modularität Es ist keine ausgeprägte Modularität in der Variante zu erkennen. Der um Filterfunktionen erweiterte Source Qualifier kann nicht als Modul betrachtet werden, da dieser nicht außerhalb seines Kontextes verwendet werden kann, sondern immer in Bezug auf die zugehörige Quelle steht. Kapselung In Variante 2 ist die Kapselung höher als im Ausgangsbeispiel und als in Variante 1. Ursache ist die Verlagerung der Filterfunktion in einen der Source Qualifier, der diese Funktionalität nun zusätzlich zu seiner ursprünglichen Aufgabe, dem Einlesen der Daten, übernimmt. Da diese zusätzliche Funktionalität von außen nicht erkennbar ist, kann hier von Kapselung gesprochen werden. Universalität War die Universalität in den vorherigen Beispielen schon gering, wurde sie durch die Verlegung des Filters in den Source Qualifier noch weiter reduziert ETL-Design Optimierung Seite 41 von 108

42 Dies ist darauf zurückzuführen, dass eine Filterung von Daten im Source Qualifier nur bei relationalen Quellen möglich ist. Wird die Filterung dagegen erst später in einer expliziten Filtertransformation durchgeführt, können auch andere Quellen wie zum Beispiel Textdateien verarbeitet werden. Kohäsion Die im Source Qualifier durchgeführten Operationen Einlesen der Quellen und Filtern der Daten sind nur durch eine mäßige Kohäsion verbunden. Wie bereits erwähnt, ist die Kohäsion innerhalb von Transformationen im Gegensatz zur Modulebene nur schlecht zu erfassen. Die Kohäsion dieser Variante wird in Bezug auf die Mehrfachfunktionalität des Source Qualifiers als schwach gewertet. Kopplung Die Kopplung zwischen den Transformationen ist unverändert. Alle Ports sind jeweils einmal verbunden. Eine Verringerung der Kopplung durch Umpositionierung ist nicht möglich, daher wird für die Kopplung 0 festgelegt. Intermodulare Kopplung kommt nach wie vor nicht vor. Übersicht über die Maße Quantitative Maße Maß: Datenmenge Anzahl Knoten Länge Komplexität Messwert: Tupel in Quelle vorhanden 350 Tupel werden eingelesen Tabelle 11: Fallbeispiel 1 Variante 2 - Quantitative Maße Qualitative Maße Maß Modularität Kapselung Universalität Kohäsion Kopplung Ausprägung n.v Auswirkungen auf die Ziele in Variante 2 Tabelle 12: Fallbeispiel 1 Variante 2 - Qualitative Maße Korrektheit: Bei der Verlegung der Filterfunktionalität in den Source Qualifier bleibt die Korrektheit erhalten. Wartbarkeit: Die Wartbarkeit wird durch die Kapselung des Filters verschlechtert, da dieser nicht mehr auf den ersten Blick zu erkennen ist. Wiederverwendbarkeit: Da die Filterung im Source Qualifier nur für relationale Quellen möglich ist, ist die Universalität in dieser Variante schwächer ausgeprägt. Dies verursacht eine geringere Wiederverwendbarkeit. ETL-Design Optimierung Seite 42 von 108

43 Performance: Die Änderungen wirken sich positiv auf die Performance aus, was darauf zurückzuführen ist, dass wesentlich weniger Tupel in die Verarbeitung innerhalb des Mappings eingehen. Jedoch sind diese Verbesserungen relativ gering. Im Vergleich ist die Filterung im Source Qualifier trotzdem die Variante mit der besten Performance. Dieser Vorsprung kann sich noch einmal drastisch erhöhen, wenn auf der zugrunde liegenden Datenbank ein Index definiert ist, der von einem im Source Qualifier platzierten Filter genutzt werden kann. Da dies jedoch außerhalb der Modellierungsmöglichkeiten liegt, soll diese Option hier nicht weiter betrachtet werden. Zuverlässigkeit Es kann davon ausgegangen werden, dass sich die geringere Anzahl von zu verarbeitenden Tupel positiv auf die Zuverlässigkeit auswirkt. Gleichzeitig führt aber die Abhängigkeit von relationalen Quellen zu einer geringeren Zuverlässigkeit, da die Filterung nicht mehr funktioniert, wenn andere Quellen eingesetzt werden sollen. Da die Abhängigkeit von relationalen Quellen erst bei Wiederverwendung negative Auswirkungen hat, wird die Zuverlässigkeit hier gegenüber dem Ausgangsbeispiel als unverändert bewertet. Übersicht über die Ziele: Variante / Ziel Wartbarkeit Wiederverwendbarkeit Performance Zuverlässigkeit Ausgangsbeispiel Variante Variante Tabelle 13: Übersicht über die Zielerfüllung der Varianten Zusammenfassung Filterpositionierung. Zusammenfassend gilt, dass eine Variation der Position eines Filters sich vor allem auf Performance als auch auf Wartbarkeit und Wiederverwendbarkeit auswirkt. Die Filterposition kann nicht frei gewählt werden, da bei einer falschen Anwendung die Korrektheit verletzt wird. Anhand der Beispiele wird deutlich, dass der Erfüllungsgrad nicht für alle Ziele gleichzeitig maximiert werden kann. So können durch die frühere Positionierung des Filters in der ersten Variation des Ausgangsbeispiels die Zuverlässigkeit, vor allem aber die Performance verbessert werden. Die anderen Ziele bleiben dabei unbeeinflusst. Die Integration der Filterung in den Source Qualifier in der zweiten Variation maximiert zwar die Performance, führt aber gleichzeitig dazu, dass sich die Wartbarkeit sowie die Wiederverwendbarkeit verschlechtern. Da die Verbesserung bei der Performance bei der Filterung im Source Qualifier recht gering ausfällt, wird die Verschlechterung bei den anderen Zielen in den meisten Fällen schwerer ins Gewicht fallen. Es ist anzumerken, dass bei einer Filterung im Source Qualifier die Quelldatenbank das performancebestimmende Element ist, also die Leistungsfähigkeit des eingesetzten Datenbank Management Systems und der Hardware, auf der dieses läuft, sich maßgeblich auswirken. ETL-Design Optimierung Seite 43 von 108

44 Ein guter Kompromiss zwischen den verschiedenen Zielen ist, eine Filtertransformation so früh wie möglich in den Datenstrom einzubinden, diese aber nicht in den Source Qualifier auszulagern, sondern als explizite Transformation beizubehalten. ETL-Design Optimierung Seite 44 von 108

45 4.3.2 Joinertransformation - Fallbeispiel 2 Nachdem die Positionierung von Filtertransformationen untersucht wurde, wird nun anhand einer Joinertransformation überprüft, wie sich dort eine Umpositionierung auswirkt. Zuerst wird jedoch zum Verständnis die Funktionsweise der Joinertransformation in Informatica PowerCenter 8 dargestellt Joinertransformationen in Informatica PowerCenter 8 Die Joinertransformation ist eine aktive, verbundene Transformation. Mit ihr können zwei Quellen zusammengeführt werden, wenn diese in mindestens einem Attribut jeweils übereinstimmende Werte aufweisen. Master- und Detailpipeline Informatica unterscheidet bei Joinertransformationen zwischen der Master- und der Detailpipeline. Die Masterpipeline endet nach der Joinertransformation, während die Detailpipeline bis zum Ziel weiterläuft. Abbildung 11 stellt dies schematisch dar. Abbildung 11: Master- und Detailpipeline bei einer Joinertransformation (Informatica, PowerCenter Transformation Guide, 2006, S. 266) Aus Performancegründen sollte immer die Quelle mit weniger Zeilen als Master definiert werden. Dies ist darin begründet, dass jede Zeile der Masterquelle gegen die Zielquelle verglichen wird. Hierfür wird die Masterquelle vollständig im Speicher vorgehalten. Bei sehr großen Quellen kann der Speicher unzureichend sein, so dass auf Festplatten ausgelagert werden muss. Dies hat sehr große, negative Auswirkungen auf die Performance. Bei der Modellierung im Informatica PowerCenter Designer wird immer die Quelle als Master gewählt, die als zweite in die Joinertransformation gezogen wird. Die Wahl von Master- und Detailpipeline sonst keine Wechselwirkung mit anderen Zielen hat, wird sie in allen folgenden Beispielen beachtet. ETL-Design Optimierung Seite 45 von 108

46 Jointypen Ein Join kann auf verschiedene Weise durchgeführt werden. Die Unterschiede beziehen sich dabei darauf, wie mit Attributen umgegangen wird, bei denen die für die Joinoperation definierte Bedingung nicht zutrifft. Die Bezeichnungen für die Jointypen weichen in Informatica PowerCenter 8 zum Teil von den im SQL Standard typischen Bezeichnungen ab. Es gibt vier Typen von Joins. 1. Normal Join: Der Normal Join in Informatica entspricht dem im SQL Standard. Es werden nur diejenigen Tupel in die neue Tabelle aufgenommen, für die die Joinbedingung zutrifft. Andere Tupel werden verworfen. 2. Detail outer Join: Entspricht einem Left- beziehungsweise Right outer Join in SQL. Es werden alle Tupel der Master Quelle behalten, auch wenn die Joinbedingung für ein Tupel nicht zutrifft. Die davon betroffenen Tupel aus der Detail Quelle werden verworfen 3. Master outer Join: Verhält sich wie ein Detail Outer Join, mit dem Unterschied, dass alle Tupel der Detail Quelle auch bei nicht Zutreffen der Joinbedingung behalten werden. Entsprechend werden Tupel der Master Quelle verworfen, wenn für das Tupel die Joinbedingung nicht erfüllt ist. 4. Full outer Join: Entspricht wiederum dem SQL Standard. Es werden alle Tupel aus beiden Quellen übernommen, unabhängig von der Erfüllung der Joinbedingung. Für Joinertransformationen gilt unabhängig von ihrem Typ, dass immer alle Zeilen der Quellen verarbeitet werden und entsprechend die Joinbedingung für jedes Tupel geprüft wird. Sollte die Joinbedingung auf mehr als ein Tupel zutreffen, wird jedes dieser Tupel übernommen Fallbeispiel 2 Positionierung von Joinertransformationen Zwei Fälle wurden indirekt schon durch die vorherigen Betrachtungen zu Filtertransformationen beleuchtet; eine Joinertransformation vor und nach einem Filter. Aus den Betrachtungen zur Filtertransformation lässt sich direkt herleiten, dass, falls im Datenfluss eines Mappings die Datenmenge reduziert wird, die Joinertransformation erst danach durchgeführt werden sollte. Hierfür muss im Einzelfall anhand der Join Bedingung geprüft werden, ob dies fachlich möglich ist. Wie schon für Filtertransformationen gibt es auch für Joiner die Möglichkeit, diese in den Source Qualifier zu integrieren. Diese Möglichkeit soll nun auf ihre Auswirkungen untersucht werden. ETL-Design Optimierung Seite 46 von 108

47 Beispielszenario Als Ausgangsbeispiel soll dasselbe Mapping wie das in den Betrachtungen zu Filtertransformationen dargestellte verwendet werden. Da dieses bereits ausführlich beschrieben wurde, sei an dieser Stelle darauf verwiesen ( ) und hier nur noch einmal der Überblick eingefügt. Abbildung 12: Fallbeispiel 2 Ausgangsbeispiel Expliziter Join Voraussetzungen für das Joinen im Source Qualifier Sollen Quellen statt in einer Joinertransformation bereits im Source Qualifier zusammengeführt werden, müssen drei Voraussetzungen erfüllt sein: 1. Die Quellen müssen relational sein, es kommen also nur Datenbanktabellen in Frage. 2. Die zu verbindenden Tabellen müssen vom selben Datenbankserver stammen, also über die selbe Verbindung angesprochen werden. 3. Die in die Joinbedingung eingehenden Attribute müssen bereits in den Datenquellen vorhanden sein. Werden Attribute erst in Transformationen generiert, können diese vorher nicht in eine Bedingung einfließen. Für die folgende Variante sind alle Bedingungen erfüllt. Standardmäßig werden die Tabellen anhand einer Beziehung zwischen gleichbenannten Attributen, die in einer Primary Key <-> Foreign Key Beziehung stehen, verknüpft. Besteht eine solche Beziehung in den Quelltabellen nicht, muss eine selbstdefinierte Verknüpfungsbedingung eingetragen werden. Dies erfolgt über Eigenschaften der Source Qualifier Transformation. Hier werden äquivalent zu einer WHERE Klausel die auf Gleichheit zu prüfenden Spalten definiert. ETL-Design Optimierung Seite 47 von 108

48 Variante 1 Ausgehend von dem bekannten Mapping werden die beiden Source Qualifier sowie die Joinertransformation entfernt und durch einen Source Qualifier, der eine benutzerdefinierte Join Bedingung (TASK_LOG_TASK = TASK_ID) enthält, ersetzt. Das Mapping sieht nach den Veränderungen folgendermaßen aus: Abbildung 13: Fallbeispiel 2 Variante 1 Joinen im Source Qualifier Quantitative Maße Datenmenge In der Quelltabelle TASK_LOG liegen und in TASKS 133 Tupel vor. Alle Tupel werden eingelesen und im Source Qualifier durch Join zusammengeführt. Anzahl der Knoten Da keine explizite Joinertransformation und nur noch ein Source Qualifier benötigt werden, sinkt die Anzahl der Knoten von 7 auf 5. Länge Die Länge reduziert sich von 4 auf 3 Weiterleitungen. Komplexität In der Variante reduziert sich die Komplexität von 28 auf 21 Kanten. Qualitative Maße Modularität Da die Integration des Joins in den Source Qualifier nicht als Modulbildung angesehen wird, kann im vorliegenden Beispiel keine solche beobachtet werden. Kapselung Durch die Integration von Funktionalität im Source Qualifier ist die Kapselung in der Variante leicht erhöht. ETL-Design Optimierung Seite 48 von 108

49 Universalität Grundsätzlich müssen Quellen, die in eine Joinoperation im Source Qualifier einbezogen werden, relational sein und vom selben Datenbankserver stammen. Ein Join über heterogene Quellen ist im Source Qualifier nicht möglich, sondern muss mittels einer expliziten Joinertransformation durchgeführt werden. Dementsprechend wirkt sich, ähnlich wie schon bei der Filterung, auch das Joinen im Source Qualifier negativ auf die Universalität aus. Kohäsion Die Source Qualifier Transformation integriert zwei Funktionen, das Auslesen der Quellen und das Verbinden der enthaltenen Daten mittels Join. Die Kohäsion zwischen diesen Funktionen ist nur schwach ausgeprägt. Kopplung Jeder Port ist jeweils über eine Kante mit einem anderen Port verbunden. Eine Reduzierung zum Beispiel durch Umpositionierung ist nicht möglich, daher wird die Kopplung mit 0 erhoben. Übersicht über die Maße Quantitative Maße Maß: Datenmenge Anzahl Knoten Länge Komplexität Messwert: Tupel werden eingelesen und verarbeitet. 350 Tupel verbleiben nach dem Filter Tabelle 14: Fallbeispiel 2 - Variante 1 - Quantiative Maße Qualitative Maße Maß Modularität Kapselung Universalität Kohäsion Kopplung Ausprägung n.v Tabelle 15: Fallbeispiel 2 - Variante 1 - Qualitative Maße Auswirkungen auf die Ziele in Variante 1 Korrektheit Die Korrektheit bleibt erhalten, die Veränderungen sind also zulässig. Wartbarkeit Wie in den vorangegangenen Beispielen verschlechtert sich die Wartbarkeit durch Kapselung bei gleichzeitig geringer Kohäsion, da hierdurch das Mapping intransparenter wird. Dieser negative ETL-Design Optimierung Seite 49 von 108

50 Einfluss wirkt sich geringer auf die Wartbarkeit aus, als der positive Einfluss der reduzierten quantitativen Maße. Insgesamt wird die Variante daher bezüglich ihrer Wartbarkeit schlechter bewertet. Wiederverwendbarkeit Da sich die Universalität verringert, verschlechtert sich auch die Wiederverwendbarkeit. Das Mapping in der veränderten Form setzt relationale Quellen voraus. Der Zugriff auf beide Quellen muss über eine Verbindung zu einem Datenbankserver stattfinden. Das Mapping in Variante 1 kann dementsprechend nicht für verteilte Quellen eingesetzt werden. Performance Die Veränderungen wirken sich sehr positiv auf die Performance aus. Dies ist darauf zurückzuführen, dass eine im Source Qualifier implementierte Joinoperation auf der Quelldatenbank durchgeführt wird, die häufig bessere Performance bietet. Die größte Verbesserung ist zu erzielen, wenn auf der Quelldatenbank ein Index für die in die Joinbedingung eingehenden Attribute definiert ist. Wenn dies nicht der Fall ist, fällt die Verbesserung geringer aus. Hieraus geht hervor, dass die Performance für die jeweilige Infrastruktur zu bewerten ist. Zuverlässigkeit Grundsätzlich ist das Ziel Zuverlässigkeit unbeeinträchtigt. Die Fehlerbehandlung kann als unverändert betrachtet werden, da Fehler, die auf der Datenbank auftreten, ebenso wie Fehler in expliziten Transformationen in den Logdateien des Workflow Monitors ausgegeben werden. Fehler werden allerdings frühzeitiger erkannt. Die Auslagerung auf die Datenbank verschiebt Zuverlässigkeitsanforderungen auf die zugrunde liegenden Systeme. Hierdurch kann sie je nach eingesetzter Datenbank schwanken. Es wird jedoch davon ausgegangen, das alle Datenbank Management Systeme bezüglich ihrer Funktionsimplementierung hinreichend zuverlässig sind. Das Designziel Zuverlässigkeit wird daher als unverändert bewertet. Übersicht über die Ziele bei der Positionierung von Joinertransformationen: Variante / Ziel Wartbarkeit Wiederverwendbarkeit Performance Zuverlässigkeit Ausgangsbeispiel Variante Tabelle 16: Fallbeispiel 2 Vergleich der Zielerfüllung Zusammenfassung Positionierung Joinertransformationen Join- Operationen können auf verschiedene Weise in den Datenfluss integriert werden. Bereits in den Betrachtungen zur Filterpositionierung wurde deutlich, dass eine Joinertransformation recht aufwendig sein kann, so dass diese, falls die Datenmenge im Verlauf eines Mappings reduziert wird, nach dieser Reduktion eingebunden werden sollte. Hierbei muss jedoch die Korrektheit gewahrt werden, was sich durch Prüfung der Join-Bedingung sicherstellen lässt. Wie auch Filterung, kann ein Verbund im Source Qualifier und damit auf der Datenbank durchgeführt werden. Dies unterliegt jedoch Einschränkungen, da die einbezogenen Quellen relational sein und vom gleichen Datenbankserver geliefert werden müssen. Falls eine Integration in den Source Qualifier möglich ist, kann sich dies positiv auf die Performance auswirken. Es muss jedoch die Infrastruktur, und hierbei insbesondere die ETL-Design Optimierung Seite 50 von 108

51 regelmäßige Auslastung der Datenbank und Integrationsserver beachtet werden. Die Verbesserungspotentiale in der Performance werden von Verschlechterungen bei Wartbarkeit und Wiederverwendbarkeit begleitet. Dementsprechend müssen im Einzelfall die Machbarkeit der Ansätze geprüft und die Gewichtung der Ziele festgelegt werden Zusammenfassung Positionierung von Transformationen Die gezeigten Beispiele bieten nur einen Einblick in die Verbesserungspotentiale, die durch verschiedene Positionen von Transformationen erschlossen werden können. Grundsätzlich lässt sich daraus jedoch ableiten, dass sich die deutlichsten Verbesserungen bezüglich des Ziels Performance erreichen lassen. Einflussstärkstes Maß ist dabei die Datenmenge. Je größer die Reduktion der Datenmenge, je früher diese innerhalb eines Mappings stattfindet und je aufwendiger die nachfolgenden Transformationen sind, desto höher sind die erreichbaren Vorteile. Dieser Ansatz entspricht der klassischen Anfrageoptimierung in Datenbanken. In der Literatur werden SQL Anfragen zum Teil als Baum betrachtet. Hierbei wird die Anfrage von der Wurzel aus gelesen. Ein Optimierungsansatz ist es, Selektionen und Projektionen möglichst weit in Richtung der Wurzel nach unten zu verschieben. Dieses Vorgehen ist eine algebraische oder implementierungsunabhängige Optimierung (Vossen, 2000, S. 315). Diese Sichtweise lässt sich auf ETL-Design übertragen und die Ansätze behalten, wie in den Beispielen gezeigt wurde ihre Gültigkeit. Der Gesichtspunkt der Implementierungsunabhängigkeit stellt den Ansatz als eine besonders geeignete Form der konzeptionellen Optimierung heraus. Neben den in den Beispielen gezeigten Transformationen wirken sich Positionsänderungen auch bei anderen Transformationen aus. Aktive Transformationen sind bezüglich der Positionierung interessant, insbesondere dann wenn sie die Zeilenanzahl verringern. Beispiele hierfür sind die gezeigten Filtertransformationen, aber auch Aggregationen, die Tupel anhand bestimmter Kriterien zusammenfassen beziehungsweise gruppieren. Werden diese früh in den Datenfluss eingebunden, verringern auch sie die Datenmenge, was die Verarbeitungszeit und den Ressourcenbedarf der nachfolgenden Transformationen verringert. Die aufgezeigte Möglichkeit, Funktionalität in den Source Qualifier zu integrieren und damit auf der Datenbank ausführen zu lassen, kann Verbesserungen der Performance weiter steigern. In den Beispielen wurde dies anhand von Filter- und Joinertransformationen gezeigt. Gleichzeitig führt die damit einhergehende Kapselung jedoch in der Regel zu einer Verschlechterung von Wartbarkeit und Wiederverwendbarkeit, so dass hier eine Entscheidung bezüglich der Zielgewichtung getroffen werden muss. Solange die zu verschiebenden Transformationen explizit vorhanden bleiben, sind die Wechselwirkungen gering, das heißt, die Verbesserungen beim Ziel Performance führen nicht gleichzeitig zur Verschlechterung anderer Ziele. ETL-Design Optimierung Seite 51 von 108

52 4.4 Austauschbarkeit von Transformationen In einigen Fällen können gleiche fachliche Anforderungen an ein Mapping mit Hilfe verschiedener Transformationen umgesetzt werden. Es besteht die Vermutung, dass die Wahl der richtigen Transformation hierbei große Auswirkungen auf den Erfüllungsgrad der Ziele hat. Nachfolgend sollen hierzu 3 Beispiele aufgestellt werden, anhand derer die Auswirkungen eines Austauschs von Transformationen untersucht werden. Als Beispiel wird der Austausch zwischen Lookup- und Joinertransformation gewählt Lookup vs. Join Lookup- und Joinertransformation sind häufig gegeneinander austauschbar. Sowohl mit einer Lookupals auch mit einer Joinertransformation können Tupel aus verschiedenen Quellen über eine Bedingung miteinander verknüpft werden. Die Art der Verknüpfung unterscheidet sie jedoch wesentlich, so dass im Einzelfall geprüft werden muss, ob ein Austausch aus fachlicher Sicht möglich, und in Bezug auf die vereinbarten Ziele sinnvoll ist Joinertransformation Die Joinertransformation wurde bereits bei den Untersuchungen zur Positionierung vorgestellt, daher sei an dieser Stelle darauf verwiesen. (Abschnitt ) Lookuptransformation Beim Lookup handelt es sich um eine passive Transformation, er verändert die Zeilenzahl im Gegensatz zur Joinertransformation also nicht. Lookuptransformationen können sowohl verbunden als auch unverbunden eingesetzt werden. Sie dienen wie Joinertransformationen dazu, anhand einer Prüfbedingung eine Quelle durch Daten aus einer anderen zu erweitern. Wesentlicher Unterschied zur Joinertransformation ist hierbei, dass bei Mehrfachtreffern nur ein Tupel übernommen wird. Welches dies ist, kann in den Optionen der Transformation bestimmt werden. In Frage kommen hierbei drei Optionen: Der ersten Wert, der letzten Wert oder der ersten Wert auf den die Bedingung zutrifft. Alternativ kann im Fall von Mehrfachtreffern ein Fehler gemeldet werden. Caching Informatica empfiehlt aus Performancegründen für Lookuptransformationen Caching zu nutzen. Hierbei wird die Lookup-Quelle in den Hauptspeicher des Integrationsservers gelesen und weitere Abfragen darauf ausgeführt (Informatica, PowerCenter Transformation Guide, 2006, S. 320). Obwohl dies meistens sinnvoll ist, lohnt sich Caching nicht immer. Ausnahme sind Lookups, die nur sehr wenige Anfragen durchführen. In diesen Fällen ist der Aufbau des Lookup-Caches aufwändiger als ein ungecachter Lookup. Als Standard wird ein statischer Cache genutzt. Dieser behält seinen Inhalt während einer Session. Er wird bei Ausführung der Lookuptransformation mit dem Einlesen der ersten Zeile aus der Lookup- Quelle aufgebaut. Neben dem statischen Cache gibt es den persistenten Cache, der nach einer Session erhalten bleibt und auf den bei einer erneuten Durchführung zurückgegriffen wird. Dieser kann nur eingesetzt werden, wenn die Lookup-Quelltabelle statisch ist, also die darin enthaltenen Daten keinen Veränderungen unterworfen sind. ETL-Design Optimierung Seite 52 von 108

53 4.4.2 Lookup vs. Join - Fallbeispiel 3 Die Auswirkungen einer Ersetzung sollen anhand von Beispielen untersucht werden. Hierbei wird das bereits bei den vorherigen Betrachtungen eingeführte Ausgangsbeispiel herangezogen. In diesem werden die Quelltabellen TASKS und TASK_LOG mittels einer Joinertransformation verknüpft. Diese Verknüpfung soll nun mit einer Lookuptransformation durchgeführt werden Ausgangsbeispiel Zur Erinnerung das Ausgangsbeispiel und die dafür erhobenen Maße: Abbildung 14: Fallbeispiel 3 Ausgangsbeispiel Quantitative Maße Maß: Datenmenge Anzahl Knoten Länge Komplexität Messwert: Eingehende Tupel 350 Tupel nach Filter Tabelle 17: Fallbeispiel 3 - Ausgangsbeispiel - Quantitative Maße Qualitative Maße Maß Modularität Kapselung Universalität Kohäsion Kopplung Ausprägung n.v. n.v. - n/a + Tabelle 18: Fallbeispiel 3 - Ausgangsbeispiel - Qualitative Maße Voraussetzungen für eine Ersetzung zwischen Lookup und Join Entsprechend dem verschiedenen Verhaltens der beiden Transformationen müssen bestimmte Bedingungen erfüllt sein, damit sie austauschbar sind, ohne dass dabei die Korrektheit verletzt wird. Diese Voraussetzungen hängen von der Art der Relation zwischen den beiden betroffenen Tabellen ab. ETL-Design Optimierung Seite 53 von 108

54 Bei 1:1 Beziehungen ist ein Austausch immer möglich, bei 1:n muss das Attribut der n-seite als Grundlage dienen, das der 1-Seite per Lookup bezogen werden. Stehen die Quellen in einer n:m Beziehung kann, aufgrund der Behandlung von Mehrfachtreffern, kein Lookup eingesetzt werden Variante 1 Nun wird das Ausgangsbeispiel dahingehend verändert, dass die Verknüpfung statt durch eine Joinermit einer Lookuptransformation durchgeführt wird. Durch die Änderungen wird nur noch eine Quelltabelle benötigt, die Daten aus der zweiten Quelle werden durch die Lookuptransformation bezogen. Da die Tabellen TASKS und TASK_LOG in einer 1:n Beziehung stehen, müssen die Tupel aus der Tabelle TASK_LOG in die Lookuptransformation eingehen, diejenigen aus TASKS werden dann mittels Lookup bezogen. Das Mapping sieht danach folgendermaßen aus: Abbildung 15: Fallbeispiel 3 Variante 1 Lookup statt Join Erhebung der Maße Um eine Vergleichbarkeit der Varianten zu ermöglichen, müssen zuerst die quantitativen und qualitativen Maße des Fallbeispiels untersucht werden. Quantitative Maße Datenmenge Die absolute Datenmenge ist gegenüber dem Ausgangsbeispiel unbeeinflusst. Wieder werden Tupel aus TASK_LOG bezogen. Die 133 Tupel der Tabelle TASKS werden in dieser Variante aber erst später, nämlich in der Lookuptransformation bezogen. Anzahl der Knoten Die Anzahl der Knoten wird durch die Einsparung einer Quelle und ihres Source Qualifiers von 7 auf 5 reduziert. Länge Die maximale Länge beträgt 3, sie wurde also um 1 reduziert. Komplexität Durch die Ersetzung der Joinertransformation und insbesondere die daraus resultierende Einsparung einer Quelle samt Source Qualifier verringert sich die Komplexität von 28 auf 19. ETL-Design Optimierung Seite 54 von 108

55 Qualitative Maße Modularität Die Modularität ist von den Änderungen nicht beeinflusst. Wie im Ausgangsbeispiel gibt es keine Module. Kapselung Die im Lookup hinterlegte Quelltabelle kann als gekapselt angesehen werden, jedoch ist keine Funktionalität gekapselt. Die Kapselung wird daher als nicht vorhanden (n.v.) bewertet. Universalität Während eine Joinertransformation immer zur Verknüpfung von Tabellen in Frage kommt, ist dies bei der Lookuptransformation in bestimmten Fällen (n:m Relation) aus bereits erläuterten Gründen nicht möglich. Bei 1:n Relationen besteht das Risiko eine falsche Reihenfolge beim Lookup zu wählen. Aus diesen Gründen muss die Universalität dieser Variante als schwach bewertet werden. Kohäsion Da in keiner Transformation mehrere Funktionen durchgeführt werden und keine Modulbildung stattfindet, ist die Betrachtung der Kohäsion obsolet. Kopplung Die Kopplung des Mappings wurde, analog zur Komplexität reduziert. Bei Betrachtung der Lookuptransformation ist zu erkennen, dass seine eingehende Kopplung mit einer Kante sehr gering ist, die ausgehende mit drei Kanten etwas höher. Die Kopplung des Source Qualifiers ist gestiegen, der Port TASK_LOG_TASK muss über zwei Kanten mit dem Lookup und dem Filter verbunden werden. Insgesamt wird die Kopplung als neutral (0) bewertet. Übersicht über die Maße Quantitative Maße Maß: Datenmenge Anzahl Knoten Länge Komplexität Messwert: Eingehende Tupel 350 Tupel nach Filter Tabelle 19: Fallbeispiel 3 Variante 1 - Quantitative Maße Qualitative Maße Maß Modularität Kapselung Universalität Kohäsion Kopplung Ausprägung n.v. n.v. - n/a 0 Tabelle 20: Fallbeispiel 3 Variante 1 - Qualitative Maße ETL-Design Optimierung Seite 55 von 108

56 Auswirkungen auf die Ziele Korrektheit Wenn die geschilderten Einschränkungen bezüglich der Reihenfolge beachtet werden, wird die Korrektheit nicht verletzt. Die Änderungen sind daher zulässig. Wartbarkeit Durch die Verwendung einer Lookuptransformation steigt die Übersichtlichkeit. Dies ist darauf zurückzuführen, dass bei Verwendung einer Lookuptransformation die Anzahl der Knoten und die Komplexität verringert werden, da hierbei die Quelle des Lookups und ihr Source Qualifier nicht mehr in das Mapping eingebunden werden müssen. Daneben wird durch die Verwendung einer Lookuptransformation eine höhere Transparenz erreicht, da die Art der Beziehung explizit ersichtlich ist. Ein Lookup bildet explizit eine x:1 Beziehung ab. Eine Joinertransformation enthält im Gegensatz dazu implizit eine 1:1, 1:n oder n:m Beziehung. Um die Korrektheit nicht zu Verletzen, muss die Richtung der Beziehung bei Wartungsarbeiten entsprechend berücksichtig werden. Die Wartbarkeit wird für diese Variante als leicht verbessert bewertet. Wiederverwendbarkeit Die Bewertung der Wiederverwendbarkeit erfordert eine fallweise Unterscheidung. Im vorliegenden Beispiel, dient der Lookup dazu, verschiedene Quellen in großer Breite, das heißt bezüglich vieler Attribute miteinander zu verknüpfen, wobei gleichzeitig die Relationshierarchie berücksichtigt werden muss. Hierbei gestaltet sich die Lookuptransformation wenig wiederverwendbar. Sollen jedoch sehr punktuell zu Tupeln weitere Daten nachgeschlagen werden, zum Beispiel Faktoren für eine Berechnung in einer Expressiontransformation, kann man hierfür Lookuptransformationen mit großer Universalität entwickeln. Diese bringen dann eine sehr gute Wiederverwendbarkeit mit sich. Ein späteres Beispiel wird diese Möglichkeit zeigen (Abschnitt 0). Für dieses Beispiel wird die Wiederverwendbarkeit als leicht verschlechtert bewertet. Performance Der Austausch der Joiner- durch eine Lookuptransformation führt im vorliegenden Beispiel zu einer schlechteren Performance. Generell ist die Performance von vielen Faktoren abhängig, was auch in diesem Beispiel deutlich gezeigt werden kann. Unter bestimmten Bedingungen kann die Performance zugunsten der Lookuptransformation ausfallen. Aufgrund der komplexen Zusammenhänge muss dies hier auch über das Beispiel hinaus diskutiert werden. Kommentar [t1]: Wf_filter_afte r_joiner_many_data: 1:36 Wf:lookup_statt_join_many_data: 1:57 Wenn nur wenige Attribute der involvierten Tabellen in die Verknüpfung eingehen, ist Lookup in der Regel performanter als Join. Dies ist auf die Implementierung der beiden Transformationen in Informatica zurückzuführen (Informatica, PowerCenter Transformation Guide, 2006, S. 304). Bei Verwendung eines persistenten Caches, ist das Mapping mit einer Lookuptransformation ab der zweiten Ausführung performanter als das mit einer Joinertransformation. Dies ist damit zu begründen, dass ein persistenter Cache nur einmal aufgebaut werden muss und danach über ETL-Design Optimierung Seite 56 von 108

57 mehrere Sessions hinweg zur Verfügung steht. Es muss geprüft werden, ob ein persistenter Cache die Korrektheit verletzen kann. Sobald Tabellen, wie im vorliegenden Fall, Änderungen unterzogen werden, kann kein persistenter Cache verwendet werden, ohne die Korrektheit zu verletzen. Wird für den Lookup kein Cache verwendet, aber im Datenbank Management System ist auf der Quelltabelle des Lookups ein Index definiert, kann dieser von der Transformation genutzt werden. In diesem Fall ist die Laufzeit bei Verwendung einer Lookuptransformation geringer als mit einer expliziten Joinertransformation (Informatica, PowerCenter Transformation Guide, 2006, S. 297). Im Vergleich mit einem Join im Source Qualifier kann die Lookuptransformation im beschrieben Fall keine Performanceverbesserung schaffen, da der Join im Source Qualifier in selbem Maße von einem Index auf der Datenbank profitiert. Performance hängt immer sehr stark von der Systemumgebung ab. Insbesondere der verfügbare Hauptspeicher wirkt sich deutlich aus. Daneben muss die Auslastung der Systeme in Bezug auf Speicher und CPU beachtet werden, falls Datenbank und Integrationsservice auf verschiedenen Servern laufen. So kann es bei hoher Auslastung des Datenbankservers vorkommen, dass Operationen, die üblicherweise auf der Datenbank performanter ausgeführt werden, auf dem Informatica PowerCenter Integrationsserver eine geringere Durchlaufzeit beanspruchen. Zuverlässigkeit: Bei Verwendung einer Lookuptransformation zum Verknüpfen der Tabellen bleibt die Zuverlässigkeit unbeeinflusst. Es ist zu beachten, dass es bei dieser Variante eine zu beachtende Reihenfolge entlang der relationalen Beziehungen gibt. Übersicht über die Ziele bei Verwendung eines Lookups in Variante 1 Variante / Ziel Wartbarkeit Wiederverwendbarkeit Performance Zuverlässigkeit Ausgangsbeispiel Variante Tabelle 21: Fallbeispiel 3 Variante 1 - Zielerfüllung bei Lookup statt Join Lookup vs. Join - Fallbeispiel 4 Im vorangegangenen Beispiel wurde deutlich, dass die Entscheidung zwischen Lookup und Joinertransformation sehr schwierig sein kann. Es gibt allerdings auch Fälle, in denen die Entscheidung aus fachlicher Sicht einfacher gefällt werden kann. Hierfür wird ein anderes Fallbeispiel herangezogen. Es sei angenommen, dass auf der Basis der geleisteten Stunden in der Tabelle TASK_LOG gleichzeitig die Kosten erhoben werden sollen. Jedes Tupel in TASK_LOG weist ein Attribut COSTCODE auf, das den zugrundeliegenden Stundensatz repräsentiert. Der Kostenfaktor liegt jedoch nicht in EURO pro Stunde vor, sondern in den Ausprägungen 1 und 2. Diesen Werten müssen Eurowerte zugewiesen werden. Über eine separate Tabelle, in der die Eurowerte hinterlegt sind, kann dieser Bezug hergestellt werden. Dies kann entweder über eine Joiner- oder über eine Lookuptransformation geschehen. Nach der Erhebung des Stundensatzes in EURO können durch ETL-Design Optimierung Seite 57 von 108

58 Multiplikation dieses Kostenfaktors mit den geleisteten Stunden die angefallenen Kosten berechnet werden. Quelltabellen Neben der bereits bekannten Tabelle TASK_LOG wurde für das Beispiel eine Tabelle COSTCODE_EUROVALUE erstellt. In dieser wird den Kostenfaktoren 1 beziehungsweise 2 ein Stundensatz von 75 beziehungsweise 120 Euro zugewiesen. COSTCODE_EUROVALUE ist folgendermaßen definiert: CREATE TABLE COSTCODE_EUROVALUE ( COSTCODE varchar2(8), EUROVALUE number(15,2) ); Zieltabelle Die Zieltabelle des Mappings TASK_LOG_WITH_COSTS entspricht der Quelltabelle TASK_LOG erweitert um die Attribute EUROVALUE und TASK_LOG_COST. CREATE TABLE Task_log_with_costs ( TASK_LOG_ID number(10), TASK_LOG_TASK number(10), TASK_LOG_HOURS number(15,2), TASK_LOG_COSTCODE varchar2(8), EUROVALUE number(10,2), Task_Log_Cost number(15,2) ); Die geschilderte Anforderung kann mittels Joiner- oder Lookuptransformation umgesetzt werden. Beide Varianten werden nachfolgend dargestellt und anschließend verglichen. ETL-Design Optimierung Seite 58 von 108

59 Umsetzung mit einer Joinertransformation Die Tabellen TASK_LOG und COSTCODE_EUROVALUE werden in der Joinertransformation unter der Bedingung TASK_LOG_COSTCODE = COSTCODE zusammengeführt. Danach findet in der Expressiontransformation die Berechnung der Kosten satt. Anschließend werden die gesamten Daten in die Zieltabelle TASK_LOG_WITH_COSTS geschrieben. Abbildung 16: Fallbeispiel 4 Ausgangsbeispiel - Berechnung der Aufgabenkosten Erhebung der Maße Quantitative Maße Datenmenge Die Datenmenge in TASK_LOG beträgt unverändert Tupel, in COSTCODE_EUROVALUE liegen 2 Tupel vor. Über die Attribute TASK_LOG.TASK_LOG_COSTCODE und COSTCODE_EUROVALUE.COSTCODE werden die beiden Tabellen in Beziehung gesetzt. Dabei wird jedes Tupel aus TASK_LOG mit genau einem aus COSTCODE_EUROVALUE verbunden. Die Tabellen stehen in einer 1:n Relation zueinander. Da ein Master Outer Join angewandt wird, wird durch diese Beziehung in der Joinertransformation nur die Anzahl der Spalten erhöht, Tupel bleiben unverändert vorhanden. Diese Zahl bleibt bis in das Ziel unverändert bestehen. Anzahl der Knoten Das Mapping besteht aus 7 Knoten. Länge Atrribute werden maximal vier Mal weitergeleitet, das Mapping weist also eine Länge von 4 auf. Komplexität Die Transformationen des Mappings sind über 23 Kanten verbunden. Dies entspricht der Komplexität. Qualitative Maße Modularität Alle Operationen werden in atomaren Transformationen durchgeführt, Modularität ist nicht vorhanden. ETL-Design Optimierung Seite 59 von 108

60 Kapselung Es gibt keine verborgene Funktionalität und somit keine Kapselung. Universalität Das Mapping weist eine hohe Spezifität für den Anwendungsfall auf. Kohäsion Aufgrund der nicht vorhandenen Modularität ist die Kohäsion nicht sinnvoll zu erheben. Kopplung Bis auf eine Ausnahme, COSTCODE in der Joinertransformation, sind alle Ports jeweils mit den nachfolgenden Transformationen verbunden. Die Kopplung wird als neutral erhoben. Übersicht über die Maße Quantitative Maße Maß: Datenmenge Anzahl Knoten Länge Komplexität Messwert: Eingehende Tupel Tabelle 22: Fallbeispiel 4 Ausgangsbeispiel - Quantitative Maße Qualitative Maße Maß Modularität Kapselung Universalität Kohäsion Kopplung Ausprägung n.v. n.v. - n/a 0 Tabelle 23: Fallbeispiel 4 Ausgangsbeispiel - Qualitative Maße Auswirkungen auf die Ziele Das vorgestellte Ausgangsbeispiel soll als Referenz für den Vergleich mit einer Lookup-Variante dienen. Daher werden, um die Vergleichbarkeit zu gewährleisten, die Ziele in der Übersicht alle mit 0 bewertet. In der Diskussion der einzelnen Ziele soll dennoch auf die Besonderheiten des Ausgangsmappings eingegangen werden. Korrektheit Das Mapping führt die geforderten Operationen korrekt durch. Wartbarkeit Positiv ist die hohe Transparenz zu werten. Jede Transformation führt genau eine Operation durch, alle Operationen sind in der Mappingansicht zu erkennen. Für die wenig komplizierten Operationen weist das Mapping relativ viele Knoten und eine hohe Komplexität auf. ETL-Design Optimierung Seite 60 von 108

61 Wiederverwendbarkeit Das Mapping ist sehr spezifisch auf den Anwendungsfall zugeschnitten und daher schlecht wiederverwendbar. Performance Performance wird erst in der folgenden Variante im Vergleich beurteilt. Zuverlässigkeit Das Ausgangsbeispiel lässt keine Zuverlässigkeitsmängel erkennen. Übersicht über die Ziele Variante / Ziel Wartbarkeit Wiederverwendbarkeit Performance Zuverlässigkeit Ausgangsbeispiel Tabelle 24: Fallbeispiel 4 Ausgangsbeispiel Zielerfüllung Umsetzung mit einer Lookuptransformation Statt beide Quellen einzulesen und anschließend mittels einer Joinertransformation zusammenzuführen, sollen nun die benötigten Stundensätze über eine Lookuptransformation aus der Tabelle COSTCODE_EUROVALUE bezogen werden. Anschließend werden wie in der vorherigen Variante die Kosten in der Expressiontransformation CALCULATE_COSTS berechnet. Die Auswirkungen, die diese Veränderung mit sich bringt, werden anschließend ausgewertet und diskutiert. Abbildung 17: Fallbeispiel 4 Variante 1 Umsetzung mit Lookuptransformation Erhebung der Maße Quantitative Maße Datenmenge Die Datenmenge in TASK_LOG beträgt unverändert Tupel, in COSTCODE_EUROVALUE liegen 2 Tupel vor. Für jedes Tupel aus TASK_LOG wird in der Lookuptransformation das ETL-Design Optimierung Seite 61 von 108

62 zusätzliche Attribut EUROVALUE nachgeschlagen. Die Anzahl der Tupel bleibt dabei unverändert, jedes Tupel wird aber um zwei Attribute, EUROVALUE und TASK_LOG_COST, erweitert. Anzahl der Knoten Da die Quelle der Lookuptransformation nicht explizit eingelesen werden muss, reduziert sich die Anzahl der Knoten von 7 auf 5. Länge Auch die Länge kann durch die Veränderungen reduziert werden, und zwar von 4 auf 3. Komplexität Die Komplexität kann deutlich reduziert werden. Während die Transformationen im vorangegangenen Beispiel noch über 23 Kanten verbunden waren, sind es jetzt nur noch 16. Qualitative Maße Modularität Eine Lookuptransformation wird nicht als Modul angesehen, daher ist unverändert keine Modularität vorhanden. Kapselung Die Attribute der Lookup-Quelltabelle sind direkt ersichtlich, daher ist keine Kapselung zu verzeichnen. Das Mapping ist transparent bezüglich der durchgeführten Operationen. Universalität Das Mapping weist eine hohe Spezifität für den Anwendungsfall auf. Allerdings ist es bezüglich der Quelle der Stundensätze etwas genereller. So ist es relativ einfach möglich, diese Quelle von einer relationalen Tabelle auf eine flache Textdatei umzustellen. Kohäsion Aufgrund der nicht vorhandenen Modularität ist die Kohäsion nicht sinnvoll zu erheben. Kopplung Die Lookuptransformation hat aber ein relativ günstiges Verhältnis zwischen eingehender und ausgehender Kopplung. Der Port TASK_LOG_COSTCODE ist über mehrere ausgehende Kanten verbunden. Insgesamt wird die Kopplung als neutral erhoben. Übersicht über die Maße Quantitative Maße Maß: Datenmenge Anzahl Knoten Länge Komplexität Messwert: Eingehende Tupel Tabelle 25: Fallbeispiel 4 Variante 1 - Quantitative Maße Qualitative Maße Maß Modularität Kapselung Universalität Kohäsion Kopplung ETL-Design Optimierung Seite 62 von 108

63 Ausprägung n.v. n.v. 0 n/a 0 Tabelle 26: Fallbeispiel 4 Variante 1 - Qualitative Maße Auswirkungen auf die Ziele Sowohl die quantitativen als auch die qualitativen Maße weisen Veränderungen auf. Die Auswirkungen auf die vereinbarten Ziele werden nachfolgend dargestellt. Korrektheit Fachlich sind beide Varianten des Mappings äquivalent. Die Korrektheit bleibt durch die Verwendung einer Lookuptransformation statt der Joinertransformation unverletzt. Wartbarkeit Alle quantitativen Maße außer der Datenmenge konnten reduziert werden. Hierdurch erhöht sich die Übersichtlichkeit, was die Wartbarkeit positiv beeinflusst. Darüber hinaus erhöht sich die Universalität etwas, da die Lookuptransformation einfacher auf verschiedene Quelltypen angepasst werden kann. Dies verbessert im vorliegenden Beispiel die Wartbarkeit, da die Stundensätze in Euro nicht in der Originaldatenbank vorlagen, sondern nachträglich eingeführt wurden. Statt einer relationalen Tabelle hätte entsprechend auch eine Textdatei eingebunden werden können. Neben den genannten Auswirkungen bleibt die gute Transparenz erhalten. Negative Effekte durch die richtungsabhängige Relation sind in diesem Fall minimal, da die Beziehung zwischen den Tabellen auch ohne detaillierte Kenntnis des Datenbankschemas offensichtlich ist. Wiederverwendbarkeit Unverändert ist das Mapping recht spezifisch auf den vorliegenden Anwendungsfall zugeschnitten. Dennoch gibt es eine Verbesserung der Wiederverwendbarkeit. Einen geringen positiven Einfluss auf hat dabei die bereits dargestellte größere Flexibilität in Bezug auf die Quelle der Stundensätze. Darüber hinaus kann die Lookuptransformation insofern besser wiederverwendet werden, dass sie die Lookupquelle integriert. Es müssen als nicht, wie bei einer Joinertransformation, zwei Quellen verbunden werden, sondern nur eine. Performance Auf die Performance wirken sich die Veränderungen positiv aus. Die Laufzeit kann im Vergleich mit dem Ausgangsbeispiel um ca. 40% reduziert werden. Zur Erhebung der Durchlaufzeit wurde der Mittelwert von 10 Ausführungen herangezogen, trotzdem sei an dieser Stelle noch einmal auf die recht geringe Aussagekraft dieses Werts hingewiesen. Die Verbesserung ist darauf zurückzuführen, dass die Lookupquelle nur sehr wenige Tupel (2) aufweist und daher der Lookup gegenüber der Joinertransformation effizienter ist. Zuverlässigkeit Die Zuverlässigkeit wird durch den Austausch einer Joinertransformation mit einer Lookuptransformation nicht beeinflusst. ETL-Design Optimierung Seite 63 von 108

64 Übersicht über die Ziele Variante / Ziel Wartbarkeit Wiederverwendbarkeit Performance Zuverlässigkeit Ausgangsbeispiel Variante Tabelle 27: Fallbeispiel 4 Zielerfüllung Vergleich der Varianten Zusammenfassung Lookup vs. Join Wie bereits bei der Erhebung der Maße und Untersuchung der Ziele deutlich wurde, ist die Entscheidung zwischen Lookup und Joinertransformation nicht trivial. Die Auswirkungen von Veränderungen sind zum Teil gravierend, stehen aber bezüglich der definierten Ziele in Konflikt. Es gilt zu beachten, dass ein Austausch nur unter bestimmten Voraussetzungen möglich ist. Lookup und Join unterscheiden sich fachlich dadurch, dass die Lookuptransformation zur Prüfbedingung nur ein Tupel zurückliefern kann. Die Joinertransformation dagegen überprüft je nach Join-Typ die Bedingung für alle Tupel und liefert dabei auch Mehrfachtreffer zurück. Dementsprechend können nur Werte aus Entitäten, die in einer 1:1 oder 1:n Relation stehen, mittels einer Lookuptransformation bezogen werden. Bei n:m Relationen muss mit der Joinertransformation gearbeitet werden. Bei 1:n Relation ist es für die Wartbarkeit wichtig, ob Art und gegebenenfalls Richtung der Relation offensichtlich sind. Dies hängt von den Daten beziehungsweise deren Aussagekraft ab. Da die zugrundeliegenden Quellen nicht in expliziten Transformationen eingelesen werden müssen und folglich auch keine Source Qualifier für diese Quellen benötigt werden, reduzieren Lookuptransformationen quantitative Maße eines Mappings. Insbesondere die Anzahl der Knoten und die Komplexität sinken in der Regel. Häufig verkürzt sich auch die Länge. Die positiven Auswirkungen dieser Reduktionen verstärken sich natürlich, wenn an mehr als einer Stelle des Mappings Daten aus anderen Quellen nachgeschlagen werden müssen, da sich die Einsparungen in diesem Fall multiplizieren. Die Lookuptransformation bietet im Gegensatz zur Joinertransformation die Möglichkeit, Daten aus mehr als zwei Tabellen in einem Verarbeitungsschritt zu verknüpfen. Dies geschieht mittels einer SQL Override Anweisung in der Lookuptransformation. Weil hierdurch aber massiv Transparenz eingebüßt wird, ist diese Möglichkeit unter dem Gesichtspunkt der Wartbarkeit als sehr ungünstig zu bewerten. In Bezug auf das Ziel Performance ist es bei der Frage Lookup vs. Join nicht möglich, eine generelle Aussage zu treffen. Mehr als von Designentscheidungen hängt die Performance von technischen Rahmenbedingungen ab. Insbesondere Caching, Art und Struktur der Quellsysteme beziehungsweise Daten, sowie Ausstattung und Auslastung der Systeme, auf denen die Dienste ausgeführt werden, beeinflussen die Performance. Beide profitieren stark von vorsortierten Daten, es kann sich jedoch hierdurch keine Transformation von der anderen abgrenzen. Indizes auf der Datenbank wirken sich bei Joinoperationen im Source Qualifier und ungecachten Lookups positiv auf die Performance aus. Laut Informatica ist der Joiner aus Performancegesichtspunkten in der Regel dem Lookup vorzuziehen ETL-Design Optimierung Seite 64 von 108

65 (Informatica, PowerCenter Transformation Guide, 2006, S. 318). Die Beispiele haben aber gezeigt, dass unter bestimmten Bedingungen die Lookuptransformation recht deutliche Performancevorsprünge vor der Joinertransformation erzielen kann. Welcher Transformation unter dem Kriterium der Performance der Vorzug zu geben ist, hängt neben den genannten Kriterien von der Struktur der Daten ab. Sollen zwei Tabellen, die viele Tupel mit jeweils vielen Attributen enthalten, zusammengeführt werden, ist hierfür die Joinertransformation vorzuziehen. Stammen die zu beziehenden Daten aus einer in Bezug auf die Zahl der Tupel und deren jeweiligen Attribute sehr kleinen Tabelle, wird in den meisten Fällen die Lookuptransformation die bessere Performance bieten. Es ist festzustellen, dass die Entscheidung Lookup vs. Join bezüglich der Performance sehr unscharf ist. Es ist daher im Einzelfall empfehlenswert, die Auswirkungen auf andere Ziele zu betrachten und dann entsprechend die Auswirkungen auf die Performance zu überprüfen. Die festgestellten Maße wirken hierbei entscheidungsunterstützend. 4.5 Weitere Optimierungsansätze - Fallbeispiel 5 Bisher wurden sehr einfache Beispiele vorgestellt, um die Wirkungsweisen verschiedener Veränderungen an Mappings zu verdeutlichen. Dabei fiel auf, dass für diese einfachen Beispiele qualitative Maße, insbesondere Modularität, Kohäsion und Kopplung regelmäßig nicht aussagekräftig untersucht werden konnten. In diesem Abschnitt wird nun ein etwas umfangreicheres Beispiel eingeführt, an dem sich Auswirkungen auf diese Maße deutlicher zeigen lassen. Für die Beispiele dienen die bereits vorgestellten Ausschnitte der dotproject Datenbank als Grundlage. Für das Szenario sollen die anfallenden Kosten eines Projekts berechnet werden. Außerdem soll eine Umrechnung in verschiedene Währungen anhand von externen Wechselkurstabellen stattfinden Datenquellen Für die kommenden Beispiele werden die Tabellen TASK_LOG, TASKS und PROJECTS als Quellen verwendet. Diese wurden bereits bei der Einführung des Szenarios in Abschnitt vorgestellt. Zur Erinnerung sei hier nochmals auf die Beziehung zwischen den Tabellen hingewiesen. In der Tabelle TASK_LOG werden einzelne Aufgaben mit den dafür angefallenen Stunden und einem Kostenfaktor gespeichert. Jedes Tupel aus TASK_LOG kann eindeutig einem aus der Tabelle TASKS zugeordnet werden. In PROJECTS wiederum werden Projekte erfasst. Jedes TUPEL aus TASKS lässt sich eindeutig einem aus PROJECTS zuordnen. TASKS dient im Beispiel demnach in erster Linie als Bindeglied zwischen den Teilaufgaben in TASK_LOG und Projekten in PROJECTS. Im Fallbeispiel müssen Daten aus den drei genannten Tabellen zusammengeführt und aggregiert werden. Darüber hinaus müssen die Kosten berechnet werden. Diese sollen auf Projektbasis erhoben werden. Es bieten sich also verschiedene Möglichkeiten an, wo innerhalb eines Mappings diese Berechnung durchgeführt werden soll. Neben den Kosten in Euro sollen verschiedene Fremdwährungen berechnet werden. Für das Beispiel werden die Wechselkurse in einer Textdatei hinterlegt. Diese muss in die Umrechnung einbezogen werden. Die Ergebnisse, in verschiedenen Währungen, werden in drei verschiedene Zieltabellen geladen Zieltabellen Die berechneten Projektkosten sollen jeweils in einer Tabelle pro Währung gespeichert werden. Die Zieltabellen sehen dabei wie folgt aus: ETL-Design Optimierung Seite 65 von 108

66 CREATE TABLE PROJECT_COST_IN_DOLLAR ( PROJECT_ID number(10), PROJECT_NAME varchar2(255), SUM_HOURS_PER_PROJECT number(15,2), COST_PER_PROJECT number(15,2) ); Analog dazu gestalten sich die Tabellen für die Währungen Euro und Schweizer Franken: CREATE TABLE PROJECT_COST_IN_EURO ( PROJECT_ID number(10), PROJECT_NAME varchar2(255), SUM_HOURS_PER_PROJECT number(15,2), COST_PER_PROJECT number(15,2) ); CREATE TABLE PROJECT_COST_IN_FRANKEN ( PROJECT_ID number(10), PROJECT_NAME varchar2(255), SUM_HOURS_PER_PROJECT number(15,2), COST_PER_PROJECT number(15,2) ); Untersuchung weiterer Optimierungsansätze Bezüglich der oben geschilderten Anforderungen werden verschiedene Designvarianten vergleichen. Alle Varianten sind fachlich äquivalent und können daher unter Optimierungsgesichtspunkten miteinander verglichen werden. Zu Beginn wird, entsprechend des definierten Vorgehens, ein Ausgangsbeispiel eingeführt. Anschließend werden in Varianten davon Optimierungsansätze untersucht. Dabei wird die Auswirkung auf die Maße und die Erfüllung der Ziele, im Vergleich mit dem Ausgangsbeispiel, untersucht beziehungsweise bewertet. ETL-Design Optimierung Seite 66 von 108

67 4.5.3 Ausgangsbeispiel Extraktion und Zusammenführung der benötigten Daten Im Ausgangsbeispiel werden zuerst die drei benötigten Quelltabellen über zwei Joinertransformationen zusammengeführt. Hierfür werden die beiden Tabellen TASKS und TASK_LOG anhand der Bedingung TASK_LOG_TASK = TASK_ID gejoined. Da in der Tabelle TASKS weniger Zeilen vorhanden sind, bilden ihre Daten die Detailpipeline. Die Tabelle TASK_LOG geht dementsprechend als Masterpipeline in die Joinertransformation ein. Im nächsten Schritt werden die zusammengeführten Daten aus der gerade beschriebenen Joinertransformation in einer weiteren Joinertransformation mit den Daten der Tabelle PROJECTS verknüpft. Da hierbei wiederum die Tabelle PROJECTS die wenigsten Zeilen liefert, gehen ihre Daten als Detailpipeline in die Transformation ein und die Ergebnisse der vorherigen Joinertransformation als Masterpipeline. Die Verknüpfung findet anhand der Bedingung TASK_PROJECT = PROJECT_ID statt. Abbildung 18: Fallbeispiel 5 Ausgangsbeispiel - Zusammenführen der Quellen Aggregation der geleisteten Stunden Nachdem die benötigten Quelldaten zusammengeführt sind, werden mittels der Aggregationstransformation SUM_HOURS_PER_PROJECT die geleisteten Stunden pro Projekt aufsummiert. Dies geschieht mittels der Aggregationsfunktion SUM(TASK_LOG_HOURS) und einem GROUP BY PROJECT_ID sowie einem GROUP BY COSTCODE. Die Gruppierung nach COSTCODE wird benötigt, da die darin hinterlegten Faktoren in die folgende Berechnung der Kosten eingehen sollen. ETL-Design Optimierung Seite 67 von 108

68 Abbildung 19 zeigt die Aggregationstransformation Abbildung 19: Fallbeispiel 5 Ausgangsbeispiel - Aggregation SUM_HOURS_PER_PROJECT Berechnung der Kosten Nach der Aggregation wird die Berechnung der Kosten pro Projekt, aufgeteilt nach den Kostenfaktoren COSTCODE, durchgeführt. Hierfür gehen die Attribute PROJECT_ID, PROJECT_NAME, SUM_HOURS_PER_PROJECT sowie TASK_LOG_COSTCODE in die EXPRESSION Transformation CALCULATE_COST ein. Innerhalb der Transformation wird zuerst der Kostenfaktor ermittelt. Im Beispiel gibt es zwei Kostenfaktoren, nämlich den Stundensatz für Mitarbeiter in Höhe von EURO 75 und den Stundensatz für Geschäftsführer von EURO 120. In den Quelldaten wird dies über den Integer 1 für einen Mitarbeiterstundensatz und 2 für einen Geschäftsführerstundensatz dargestellt. Weitere Kostenfaktoren gibt es nicht. Die Ableitung des Stundensatzes aus dem in COSTCODE gespeicherten Wert geschieht unter Nutzung eines Variablenports FACTOR_COSTCODE. Ein Variablenport ist hierbei ein rein in der Transformation existierender Port, das heißt, er ist nach außen weder über Eingänge noch über Ausgänge verbunden. Er dient der Berechnung von Werten, die für die Weiterverarbeitung benötigt werden. Im Beispiel wird auf dem Variablenport FACTOR_COSTCODE folgende Operation durchgeführt: IIF(TASK_LOG_COSTCODE = '1', 75, 120). Es wird also abhängig von dem in COSTCODE hinterlegten Wert entweder 75 oder 120 im Variablenport der jeweiligen Zeile gespeichert. Danach wird auf den Ausgabeports COST_PER_PROJECT, COST_IN_DOLLAR und COST_IN_FRANKEN jeweils die Berechnung der Kosten in den entsprechenden Währungen durchgeführt. Bei COST_PER_PROJECT sieht die Berechnung dabei folgendermaßen aus: SUM_HOURS_PER_PROJECT * FACTOR_COSTCODE. Es werden also die aufsummierten Stunden mit dem Stundensatz, der über den Variablenport geliefert wird, multipliziert. Für die Berechnungen der Kosten in fremden Währungen wird die Berechnung um einen Faktor, der dem Umrechnungskurs entspricht, erweitert. Die aktuellen Wechselkurse werden dabei mittels eines nicht verbundenen Lookups aus einer Textdatei bezogen. Der Aufruf der nicht verbundenen LOOKUP Transformation geschieht auf dem jeweiligen Port folgendermaßen: :LKP.LOOKUP_WECHSELKURS('Währung') Dieser Aufruf wird in die Formel zur Berechnung der Kosten eingebunden. Für beide Währungen gibt ETL-Design Optimierung Seite 68 von 108

69 es jeweils einen Ausgabeport, die vollständige Berechnung für die Kosten in Dollar sieht dabei folgendermaßen aus: SUM_HOURS_PER_PROJECT * FACTOR_COSTCODE * :LKP.LOOKUP_WECHSELKURS('Dollar') Nachdem alle Berechnungen durchgeführt wurden, werden die Attribute PROJECT_ID, PROJECT_NAME sowie die neu ermittelten Werte COST_PER_PROJECT, COST_IN_DOLLAR und COST_IN_FRANKEN zur Weiterverarbeitung in der folgenden Transformation SUM_COST_PER_PROJECT ausgegeben. Zur Übersicht ist in der folgenden Abbildung die Transformation CALCULATE_COST dargestellt. Abbildung 20: Fallbeispiel 5 Ausgangsbeispiel - Expression Transformation CALCULATE_COST Aggregation der Kosten Nach der Berechnung liegen die Kosten pro Projekt vor. Allerdings sind diese noch nach den beiden Kostenfaktoren COSTCODE (1,2) separiert. Dies wird nun mit einer weiteren Aggregation behoben. In dieser Transformation SUM_COST_PER_PROJECT werden die Kosten in den verschiedenen Währungen sowie die geleisteten Stunden auf Portebene über die Aggregationsfunktion SUM(Port) aufsummiert und nach der PROJECT_ID gruppiert. Nach erfolgter Aggregation werden die Daten in die entsprechenden Ziele geschrieben, wie folgende Abbildung zeigt. Abbildung 21: Fallbeispiel 5 Ausgangsbeispiel - Aggregation SUM_COST_PER_PROJECT ETL-Design Optimierung Seite 69 von 108

70 Gesamtübersicht Bevor Varianten des Ausgangsbeispiels vorgestellt werden, soll nun zuerst eine kurze Untersuchung des vorliegenden Mappings stattfinden. Zur besseren Orientierung ist das vollständige Mapping in folgender Abbildung dargestellt. Abbildung 22: Fallbeispiel 5 Ausgangsbeispiel - Gesamtübersicht Erhebung der Maße des Ausgangsbeispiels Quantitative Maße Zunächst werden die quantitativen Maße des Ausgangsbeispiels untersucht. Das Mapping ist etwas komplexer als die vorherigen Beispiele. Informatica PowerCenter 8 bietet eine einfache Möglichkeit des XML-Exports. Aus einer solchen XML Datei können alle Maße außer Datenmenge und Länge einfach ermittelt und somit auch für sehr komplexe Mappings erhoben werden. Datenmenge Aus der Tabelle TASK_LOG gehen Tupel in das Mapping ein. Aus TASK und PROJECTS jeweils 133 beziehungsweise 57. In der ersten Joinertransformation werden die beiden letzteren zu 133 Tupel zusammengeführt. Anschließend werden in der zweiten Joinertransformation das Ergebnis der ersten und die Tupel aus TASK_LOG zu Zeilen verknüpft. In der ersten Aggregation werden diese dann auf 72, in der zweiten Aggregation dann nochmal auf 49 Tupel reduziert. Diese verbleibenden 49 Tupel werden anschließend auf 3 Ziele verteilt. Anzahl der Knoten Das Mapping besteht aus 15 Transformationen, was der Anzahl der Knoten entspricht. Länge Die maximale Anzahl an Weiterleitungen erfährt das Attribut PROJECT_ID aus der Tabelle PROJECTS. Diese beträgt 8 und stellt die Länge des Mappings dar. Komplexität Die Komplexität, also die Anzahl der Kanten, mit denen die einzelnen Transformationen untereinander verbunden sind, beträgt 55. ETL-Design Optimierung Seite 70 von 108

71 Qualitative Maße Modularität Im Ausgangsbeispiel ist noch keine Modularität erkennbar. Kapselung In der Expressiontransformation CALCULATE_COST werden zwei fachliche Operationen durchgeführt, die Berechnung der Kosten und die Umrechnung in Fremdwährungen. Dabei kapselt CALCULATE_COST auch den Aufruf der nicht verbundenen Lookuptransformation. Universalität Das Mapping weist eine geringe Universalität auf. Da in CALCULATE_COST zwei Operationen gekapselt sind, lassen sich diese schlecht auf anderen Szenarien anwenden. Kohäsion Die Kohäsion in CALCULATE_COST ist relativ schwach, da zwischen den Aktionen Berechnung der Kosten und Umrechnung in Fremdwährungen keine ausgeprägte fachliche Bindung erkennbar ist. Kopplung Die Kopplung zwischen den einzelnen Transformationen ist hoch. Die Lookuptransformation LOOKUP_WECHSELKURS ist eine nicht verbundene Transformation. Das heißt, im Gegensatz zu den anderen Transformationen ist sie nicht über Ein- und Ausgabeports gekoppelt, sondern über einen impliziten Aufruf in der Transformation CALCULATE_COST Übersicht über die Maße Quantitative Maße Maß: Datenmenge Anzahl Knoten Länge Komplexität Messwert: Tabelle 28: Fallbeispiel 5 Ausgangsbeispiel - Quantitative Maße Qualitative Maße Maß Modularität Kapselung Universalität Kohäsion Kopplung Ausprägung n.v Tabelle 29: Fallbeispiel 5 Ausgangsbeispiel - Qualitative Maße Auswirkungen auf die Ziele Da es sich bei dem Beispiel um die Referenz für die folgenden Vergleiche handelt, werden alle Ziele mit 0 bewertet. Auffälligkeiten in Bezug auf die Ziele werden im Text dargestellt. Korrektheit Alle Daten werden fachlich korrekt und konsistent in die Zieltabellen geschrieben. ETL-Design Optimierung Seite 71 von 108

72 Wartbarkeit Die Wartbarkeit des Mappings ist nicht optimal. Anzahl der Knoten, Länge und Komplexität sind bezogen auf die gebotene Funktionalität recht hoch. Außerdem werden in CALCULATE_COST Funktionen gekapselt, zwischen denen eine recht schwache Kohäsion herrscht. Wiederverwendbarkeit Das Mapping ist sehr spezifisch auf den Anwendungsfall zugeschnitten und daher schlecht wiederverwendbar. Performance Die Performance wird erst im Vergleich mit den folgenden Varianten bewertet. Zuverlässigkeit Das Mapping ist von der Verfügbarkeit der Quellen und der Zielsysteme abhängig. Innerhalb des Mappings gibt es keine Auffälligkeiten, die sich auf die Zuverlässigkeit auswirken könnten Zusammenfassung und Übersicht über die Ziele Variante / Ziel Wartbarkeit Wiederverwendbarkeit Performance Zuverlässigkeit Ausgangsbeispiel Tabelle 30: Fallbeispiel 5 Ausgangsbeispiel - Zielerfüllung Auffällig ist in dem vorliegenden Mapping, dass neun von fünfzehn Transformationen dazu benötigt werden, die für die zu berechnenden Werte erforderlichen Daten zu extrahieren und zusammenzuführen. Außerdem fällt auf, dass im Abstand von einer Transformation zwei Mal aggregiert wird. Hier kann vermutet werden, dass diese Redundanz durch eine Zusammenfassung der beiden Aggregationen behoben werden kann. Dies entspräche einem Merge and Split Optimierungsansatz nach (Vassiliads, Simitsis, Terrovitis, & Skiadopoulos, 2005). In den folgenden Varianten wird untersucht, ob dies möglich ist und wie sich dies auf das Mapping auswirkt. In dem entwickelten Mapping muss die Lookup Operation auf jedem der betroffenen Ports für jede Zeile der eingehenden Daten durchgeführt werden Variante 1 - Merge and Split In der ersten Variante des eingeführten Beispiels sollen die Aggregation und die Kalkulation überarbeitet werden. Dies geschieht auf Grundlage des Ausgangsbeispiels. Dort wurden zuerst in der Aggregation SUM_HOURS_PER_PROJECT die geleisteten Stunden gruppiert nach PROJECT_ID und nach dem Kostenfaktor COSTCODE summiert. Danach wurden die aufsummierten Stunden zusammen mit dem Kostenfaktor in die Berechnung der Kosten einbezogen. Anschließend wurde durch eine weitere Aggregation SUM_COST_PER_PROJECT die Summe der Kosten diesmal ausschließlich nach PROJECT_ID gruppiert gebildet. Aufgrund der großen örtlichen und fachlichen Nähe der beiden Aggregationstransformationen ist die Überlegung einer Zusammenfassung beider naheliegend. Dieses Vorgehen entspricht dem Merge and Split Ansatz der Optimierungsansätze aus (Vassiliads, Simitsis, Terrovitis, & Skiadopoulos, 2005), wobei hier ein Merge, also eine Zusammenfassung durchgeführt wird. Die Zusammenfassung erfordert zusätzlich einen Positionstausch beziehungsweise Swap, da die Kalkulation, die in der Expressiontransformation CALCULATE_COST vorgenommen wird, dann vor der Aggregation stattfinden muss. Der ETL-Design Optimierung Seite 72 von 108

73 Positionstausch oder Swap gehört ebenfalls zu den in (Vassiliads, Simitsis, Terrovitis, & Skiadopoulos, 2005) beschriebenen Optimierungsmaßnahmen. In der ersten Variante soll nun überprüft werden, welche Auswirkungen diese Veränderungen auf die angestrebten Ziele haben. Ausgangssituation Ausgegangen wird von dem Aggregations- und Kalkulationsabschnitt aus dem Ausgangsbeispiel: Abbildung 23: Fallbeispiel 5 Variante 1 - Ausgangssituation mit zwei Aggregationen Die Anordnung der Transformationen wurde bei der Vorstellung des Ausgangsbeispiels begründet. Zielsituation der Variante 1 In Variante 1 soll die Zahl der Aggregationen durch Zusammenfassung reduziert werden. Wenn die Summierung der Stunden und der Kosten in einer Aggregationstransformation berechnet werden sollen, müssen folglich die Kosten vorher für jeden Eintrag in TASK_LOG.TASK_LOG_HOURS unter Berücksichtigung des jeweiligen Faktors COSTCODE kalkuliert werden. Abbildung 24: Fallbeispiel 5 Variante 1 - Zielsituation mit einer Aggregation ETL-Design Optimierung Seite 73 von 108

74 Expressiontransformation Dies erfordert eine Anpassung der Expressiontransformation CALCULATE_COST. Nachfolgend ist die geänderte Transformation abgebildet. Abbildung 25: Fallbeispiel 5 Variante 1 - Kostenkalkulation auf Basis der TASK_LOG Einträge Wieder enthält die Transformation drei Ausgabeports, COST_PER_TASK_LOG für die Kosten pro Eintrag in TASK_LOG in Euro sowie COST_IN_DOLLAR und COST_IN_FRANKEN für die beiden Fremdwährungen. Die Formel zur Berechnung der Kosten ist in dieser Variante der aus dem Ausgangsbeispiel sehr ähnlich. Sie unterscheiden sich jedoch darin, dass nicht wie zuvor die bereits aggregierten Stunden zur Berechnung der Kosten herangezogen werden, sondern diese für jede Zeile auf Basis des Attributs TASK_LOG_HOURS vorgenommen wird. Hieraus ergibt sich für die Eurowerte die Formel TASK_LOG_HOURS * FACTOR_COSTCODE Für die Fremdwährungen wird zusätzlich der Wechselkurs über Aufruf des nicht verbundenen Lookups als Faktor in die Berechnung einbezogen, woraus sich folgende Formel ergibt: TASK_LOG_HOURS * FACTOR_COSTCODE * :LKP.LOOKUP_WECHSELKURS('Währung') Die Expression unterscheidet sich also nur durch das Attribut, das in die Berechnung eingeht. Als Ergebnis ist jede Zeile der Daten um die Attribute für die Kosten erweitert. ETL-Design Optimierung Seite 74 von 108

75 Aggregationstransformation Nachdem die Kosten für jedes Tupel erhoben sind, können in einer einzelnen Aggregationstransformation sowohl die Stunden als auch die Kosten je Projekt aufsummiert werden. Abbildung 26: Fallbeispiel 5 Variante 1 - Aggregation der Projektkosten und geleisteten Stunden Dies geschieht analog zu den Aggregationen im Ausgangsbeispiel, wobei in diesem Fall die Summierung von Stunden und Kosten in einem Schritt geschieht. Gesamtübersicht Zur Orientierung das gesamte Mapping in der Übersichtsdarstellung. Der Bereich, in dem das Mapping gegenüber der Ausgangssituation verändert wurde, ist durch den roten Rahmen kenntlich gemacht. Abbildung 27: Fallbeispiel 5 Variante 1 - Gesamtübersicht ETL-Design Optimierung Seite 75 von 108

76 Erhebung der Maße für Variante 1 Quantitative Maße Datenmenge Die 57 Tupel aus Projects werden mit den 133 aus TASKS und den aus TASK_LOG in 2 Joinertransformationen zusammengeführt. Danach werden Tupel weiterverarbeitet. Alle Zeilen gehen in die Berechnung der Kosten CALCULATE_COST ein. Danach wird die Anzahl der Zeilen in der Aggregation SUM_HOURS_AND_COST_PER_PROJECT auf 49 reduziert. Die verbliebenen Tupel werden anschließend in drei Ziele geschrieben. Anzahl der Knoten Die Anzahl der Knoten ist von 15 auf 14 um 1 Knoten reduziert. Länge Das Attribut mit der bisher größten Anzahl an Weiterleitungen, PROJECT_ID, wurde auch durch die weggefallene Transformation geleitet. Daher reduziert sich die Länge um 1 auf nun 7. Komplexität Durch die Reduktion um eine Transformation wird auch die Komplexität reduziert. Diese beträgt jetzt 44. Qualitative Maße Modularität Bei der Variation werden keine Module erstellt. Daher ist unverändert keine Modularität vorhanden. Kapselung Die Expressiontransformation CALCULATE_COST kapselt nach wie vor Funktionalität. Da sich nur das Attribut, auf dem die Operationen durchgeführt werden, verändert hat, bleibt die Kapselung gleich. Universalität Die Änderungen führten zu keiner Verstärkung der Universalität. Genau wie das Ausgangsbeispiel ist auch diese Variante sehr spezifisch auf den Anwendungsfall abgestimmt. Kohäsion CALCULATE_COST zeigt eine schwache Kohäsion bezüglich der enthaltenen Operationen Kostenberechnung und Währungsumrechnung. Kopplung Die einzelnen Transformationen sind stark gekoppelt, intermodulare Kopplung ist nicht erkennbar. ETL-Design Optimierung Seite 76 von 108

77 Übersicht über die Maße Quantitative Maße Maß: Datenmenge Anzahl Knoten Länge Komplexität Messwert: eingehende Tupel 49 nach Aggregation Tabelle 31: Fallbeispiel 5 Variante 1 - Quantitative Maße Qualitative Maße Maß Modularität Kapselung Universalität Kohäsion Kopplung Ausprägung n.v Auswirkungen auf die Ziele Tabelle 32: Fallbeispiel 5 Variante 1 - Qualitative Maße Korrektheit Diese Variante führt die Operationen korrekt durch. Wartbarkeit Da sich die Maße nur unwesentlich geändert haben, ist die Wartbarkeit von den Anpassungen unbeeinflusst. Der minimal positive Einfluss durch die Reduktion quantitativer Maße ist hier vernachlässigbar. Wiederverwendbarkeit Die Variante ist unverändert schlecht bezüglich ihrer Wiederverwendbarkeit. Performance Die Reduktion an Knoten und Komplexität lässt vermuten, dass sich die vorgenommenen Änderungen positiv im Vergleich zum Ausgangsbeispiel auswirken. Für eine genaue Beurteilung müssen allerdings die durchgeführten Operationen und die jeweilig zu bearbeitenden Daten betrachtet werden. Beide Beispiele unterscheiden sich dadurch, dass im Ausgangsbeispiel zuerst eine Aggregation auf Projekte und Kostenfaktor vorgenommen wird und danach auf Basis dieser voraggregierten Daten die die Kosten berechnet werden. Die Aggregation ist eine aktive Transformation, sie verringert die Anzahl der Zeilen und damit die Menge der zu verarbeitenden Daten. Im vorliegenden Beispiel werden Tupel aus den Quellen extrahiert. In der angepassten Variante werden für jedes dieser Tupel die drei notwendigen Berechnungen durchgeführt. Insgesamt wird die Formel zur Berechnung der Kosten mal durchgeführt. Zusätzlich muss für jede dieser Berechnungen per Lookuptransformation LOOKUP_WECHSELKURS der jeweilige Wechselkurs nachgeschlagen werden. ETL-Design Optimierung Seite 77 von 108

78 Im Gegensatz dazu werden durch die Voraggregation im Ausgangsbeispiel diese Berechnungen und die dafür benötigten Lookups nur für die nach der Summierung und Gruppierung verbleibenden 72 Zeilen, insgesamt also 216-mal durchgeführt. Hieraus folgt, dass Variante 1 gegenüber der Ausgangssituation trotz geringerer Anzahl von Knoten und geringerer Komplexität bezüglich der Performance wesentlich ineffizienter ist. Die Ausführungsdauer stieg im Schnitt um ca. 400 % von 90 Sekunden im Ausgangsbeispiel auf 360 Sekunden in dieser Variante 3. Insbesondere ist zu beachten, dass sich dieser Nachteil mit zunehmender Zeilenanzahl vergrößert, diese Variante also sehr schlecht skaliert. Zuverlässigkeit Beide Ziele werden nicht direkt beeinflusst. Allerdings führen die Ineffizienz und der dadurch verursachte hohe Ressourcenbedarf dieser Variante dazu, dass Fehler, die von der Systemumgebung ausgelöst werden, wahrscheinlicher werden. Ein Beispiel hierfür sind fehlgeschlagene Verbindungen zu anderen Systeme aufgrund einer Überschreitung der Antwortzeit Zusammenfassung und Übersicht über die Ziele Variante / Ziel Wartbarkeit Wiederverwendbarkeit Performance Zuverlässigkeit Ausgangsbeispiel Variante Tabelle 33: Fallbeispiel 5 Variante 1 - Zielerfüllung Im direkten Vergleich der beiden Varianten wird vor allem deutlich, dass die fachliche Analyse der Transformationen, insbesondere in Bezug auf die Datenmenge, bei der Optimierung von Mappings Vorrang genießen sollte. Die an sich naheliegende Reduktion der Transformationen durch den Merge- Ansatz führt im Beispiel zu einer signifikant schlechteren Performance und Skalierbarkeit. Es kann davon ausgegangen werden, dass sich die Verschlechterungen bei der Performance indirekt auf die Zuverlässigkeit auswirken können. Gleichzeitig ist der Einfluss auf die anderen angestrebten Ziele vernachlässigbar gering, so dass die Nachteile nicht aufgewogen werden können. Andersherum gesehen zeigt dieses Beispiel deutlich, dass Split Maßnahmen, also das Aufteilen von Funktionen einer Transformation auf mehrere, sich sehr positiv auswirken können. 3 Die Werte in Sekunden dienen nur zum Aufzeigen der Tendenz. Bei Ausführung auf verschiedenen Systemen waren teilweise massive Unterschiede der Verarbeitungsdauer zu verzeichnen. Der Trend blieb jedoch auf unterschiedlichen Systemen gleich. ETL-Design Optimierung Seite 78 von 108

79 4.5.5 Variante 2 - Modularisierung Im Ausgangsbeispiel und der ersten Variante fiel auf, dass die gravierendsten Veränderungen bei der Performance auftraten. Die Einflüsse auf andere Designziele waren überwiegend gering. Im Folgenden wird untersucht, welche Auswirkungen der Einsatz von Mapplets in dem bekannten Beispiel mit sich bringt. Mapplets bieten die Möglichkeit der Modularisierung, wodurch vermutet werden kann, dass sich ihr Einsatz auf die Wartbarkeit und Wiederverwendbarkeit auswirkt. Auf Grundlage des Ausgangsbeispiels werden Transformationen zu Mapplets zusammengefasst und die resultierenden Auswirkungen untersucht. In der folgenden Abbildung sind die Transformationen gekennzeichnet, bei denen eine Zusammenfassung aufgrund der fachlichen Zusammengehörigkeit auf den ersten Blick sinnvoll erscheint. Abbildung 28: Fallbeispiel 5 Variante 2 potentielle Mapplets Für die Zusammenfassung von Transformationen zu Mapplets ist zuerst die Frage zu stellen, welche Transformationen sich zu einer logischen Einheit gruppieren lassen. Grundsätzlich lassen sich alle Transformationen außer Ziele in Mapplets integrieren. Mapplet zum Extrahieren und Zusammenführen der Quellen Zuerst werden die Transformationen, die das Extrahieren und Zusammenführen der Quellen durchführen, im Mapplet MPLT_EXTRACT_AND_JOIN_SOURCES zusammenfassend gekapselt. Das hierfür verwendete Mapplet ist bereits aus der Einführung von Mapplets in Abschnitt bekannt. ETL-Design Optimierung Seite 79 von 108

80 Aggregation und Kalkulation der Projektkosten Anschließend werden innerhalb des Mapplets MPLT_CALCULATE_COST_PER_PROJECT_AND_COSTCODE zuerst die Aggregation basierend auf Project_id und Costcode und danach die Berechnung der Kosten in Euro für die Aggregate durchgeführt. Abbildung 29: Fallbeispiel 5 Variante 2 Mapplet MLTP_CALCULATE_COST_PER_PROJECT_AND_COSTCODE zur Vorbereitung der Projektkosten Die Berechnung der Kosten in Fremdwährungen findet hier nicht mehr innerhalb der Transformation CALCULATE_COST statt. Stattdessen wird diese in ein eigenes Mapplet verlagert. Es wird also zusätzlich zur Modularisierung auch eine Split-Optimierung vorgenommen. Währungsumrechnung Nachdem die Kosten in Euro vorliegen, findet die Umrechnung in die beiden Fremdwährungen innerhalb des Mapplets MPLT_CURRENCY_CONVERSION statt. Hier geht über die Input Transformation des Mapplets das zuvor berechnete Attribut COST_PER_PROJECT ein. Innerhalb des Mapplets werden in einer Expression Transformation die Fremdwährungen durch Bezug des Wechselkurses mittels eines nicht verbundenen Lookups berechnet. Abbildung 30: Fallbeispiel 5 Variante 2 Mapplet MLTP_CURRENCY_CONVERSION zur Berechnung der Projektkosten in Fremdwährungen Die danach folgende Aggregationstransformation SUM_COST_PER_PROJECT lässt sich nicht sinnvoll einem der Mapplets zuweisen und liegt deshalb nach wie vor als Einzeltransformation vor. In Ihr werden die Zeilen, die aus fachlichen Gründen momentan noch auf Basis der PROJECT_ID und ETL-Design Optimierung Seite 80 von 108

Vergleich von Open-Source und kommerziellen Programmen zur Durchführung eines ETL-Prozesses

Vergleich von Open-Source und kommerziellen Programmen zur Durchführung eines ETL-Prozesses Vergleich von Open-Source und kommerziellen Programmen zur Durchführung eines ETL-Prozesses Exposé zur Diplomarbeit Humboldt-Universität zu Berlin Mathematisch-Naturwissenschaftliche Fakultät II Institut

Mehr

WhitePaper. Mai 2012. BIA Business Intelligence Accelerator. Markus Krenn Geschäftsführer Mail: m.krenn@biaccelerator.com

WhitePaper. Mai 2012. BIA Business Intelligence Accelerator. Markus Krenn Geschäftsführer Mail: m.krenn@biaccelerator.com WhitePaper BIA Business Intelligence Accelerator Mai 2012 Markus Krenn Geschäftsführer Mail: m.krenn@biaccelerator.com BIA Business Intelligence Accelerator GmbH Softwarepark 26 A-4232 Hagenberg Mail:

Mehr

1 Einleitung. Betriebswirtschaftlich administrative Systeme

1 Einleitung. Betriebswirtschaftlich administrative Systeme 1 1 Einleitung Data Warehousing hat sich in den letzten Jahren zu einem der zentralen Themen der Informationstechnologie entwickelt. Es wird als strategisches Werkzeug zur Bereitstellung von Informationen

Mehr

Business Intelligence Data Warehouse. Jan Weinschenker

Business Intelligence Data Warehouse. Jan Weinschenker Business Intelligence Data Warehouse Jan Weinschenker 28.06.2005 Inhaltsverzeichnis Einleitung eines Data Warehouse Data Warehouse im Zusammenfassung Fragen 3 Einleitung Definition: Data Warehouse A data

Mehr

IG07: Informatica PowerCenter - Grundlagen

IG07: Informatica PowerCenter - Grundlagen IG07: Informatica PowerCenter - Grundlagen Ein Seminar der DWH academy Seminar IG07 - Informatica PowerCenter - Grundlagen Das ETL-Tool PowerCenter von Informatica ist eines der marktführenden Werkzeuge

Mehr

Perzentile mit Hadoop ermitteln

Perzentile mit Hadoop ermitteln Perzentile mit Hadoop ermitteln Ausgangspunkt Ziel dieses Projektes war, einen Hadoop Job zu entwickeln, der mit Hilfe gegebener Parameter Simulationen durchführt und aus den Ergebnissen die Perzentile

Mehr

Das ultimative Daten Management

Das ultimative Daten Management Das ultimative Daten Management Beschreibung des Programms Rafisa AG Seestrasse 78 CH 8703 Erlenbach-Zürich Ziel und Zweck Das Program: ist ein multi-funktionales Programm, welches dazu dient, für den

Mehr

Integration Services - Dienstarchitektur

Integration Services - Dienstarchitektur Integration Services - Dienstarchitektur Integration Services - Dienstarchitektur Dieser Artikel solle dabei unterstützen, Integration Services in Microsoft SQL Server be sser zu verstehen und damit die

Mehr

Eignung unterschiedlicher Faktenmodellierungen in Data Warehouse-Systemen

Eignung unterschiedlicher Faktenmodellierungen in Data Warehouse-Systemen Christoph Arnold (B. Sc.) Prof. Dr. Harald Ritz Eignung unterschiedlicher Faktenmodellierungen in Data Warehouse-Systemen AKWI-Tagung, 17.09.2012, Hochschule Pforzheim Christoph Arnold, Prof. Dr. Harald

Mehr

Data Lineage goes Traceability - oder was Requirements Engineering von Business Intelligence lernen kann

Data Lineage goes Traceability - oder was Requirements Engineering von Business Intelligence lernen kann Data Lineage goes Traceability - oder was Requirements Engineering von Business Intelligence lernen kann Andreas Ditze MID GmbH Kressengartenstraße 10 90402 Nürnberg a.ditze@mid.de Abstract: Data Lineage

Mehr

Integration Services Übersicht

Integration Services Übersicht Integration Services Übersicht Integration Services Übersicht Integration Services stellt umfangreiche integrierte Tasks, Container, Transformationen und Datenadapter für die En t- wicklung von Geschäftsanwendungen

Mehr

Kapitel 2 Terminologie und Definition

Kapitel 2 Terminologie und Definition Kapitel 2 Terminologie und Definition In zahlreichen Publikationen und Fachzeitschriften tauchen die Begriffe Data Warehouse, Data Warehousing, Data-Warehouse-System, Metadaten, Dimension, multidimensionale

Mehr

Marketing Intelligence Architektur und Konzepte. Josef Kolbitsch Manuela Reinisch

Marketing Intelligence Architektur und Konzepte. Josef Kolbitsch Manuela Reinisch Marketing Intelligence Architektur und Konzepte Josef Kolbitsch Manuela Reinisch Übersicht Mehrstufiges BI-System Architektur eines Data Warehouses Architektur eines Reporting-Systems Benutzerrollen in

Mehr

Data Flow One Engine V 3.1

Data Flow One Engine V 3.1 Data Flow One Engine V 3.1 Data Flow One Engine V3.1 Für eine gute Performance Data Flow One ist eine Standardsoftware im EAI-Bereich, welche es dem Benutzer ermöglicht, auf einfache, graphisch unterstützte

Mehr

Datawarehouse Architekturen. Einheitliche Unternehmenssicht

Datawarehouse Architekturen. Einheitliche Unternehmenssicht Datawarehouse Architekturen Einheitliche Unternehmenssicht Was ist Datawarehousing? Welches sind die Key Words? Was bedeuten sie? DATA PROFILING STAGING AREA OWB ETL OMB*PLUS SAS DI DATA WAREHOUSE DATA

Mehr

Oracle 10g und SQL Server 2005 ein Vergleich. Thomas Wächtler 39221

Oracle 10g und SQL Server 2005 ein Vergleich. Thomas Wächtler 39221 Oracle 10g und SQL Server 2005 ein Vergleich Thomas Wächtler 39221 Inhalt 1. Einführung 2. Architektur SQL Server 2005 1. SQLOS 2. Relational Engine 3. Protocol Layer 3. Services 1. Replication 2. Reporting

Mehr

Analysen sind nur so gut wie die Datenbasis

Analysen sind nur so gut wie die Datenbasis Analysen sind nur so gut wie die Datenbasis Datenaufbereitung und Sicherung der Datenqualität durch den kontextbasierten MIOsoft Ansatz. Daten gelten längst als wichtiger Produktionsfaktor in allen Industriebereichen.

Mehr

Adlerblick So gewinnen Sie einen Überblick über ein DWH Dr. Andrea Kennel InfoPunkt Kennel GmbH CH-8600 Dübendorf Schlüsselworte Einleitung

Adlerblick So gewinnen Sie einen Überblick über ein DWH Dr. Andrea Kennel InfoPunkt Kennel GmbH CH-8600 Dübendorf Schlüsselworte Einleitung Adlerblick So gewinnen Sie einen Überblick über ein DWH Dr. Andrea Kennel InfoPunkt Kennel GmbH CH-8600 Dübendorf Schlüsselworte DWH Projekt, Methodik, Stärken und Schwächen, Übersicht, Weg der Daten,

Mehr

Sven Bosinger solution architect BI. Data Warehouse Architekturen Der Schlüssel zum Erfolg! DOAG 16.11.2007 1

Sven Bosinger solution architect BI. Data Warehouse Architekturen Der Schlüssel zum Erfolg! DOAG 16.11.2007 1 Sven Bosinger solution architect BI Data Warehouse Architekturen Der Schlüssel zum Erfolg! DOAG 16.11.2007 1 Agenda Kurze Vorstellung its-people Architektur als Erfolgsfaktor Verschiedene Architekturansätze

Mehr

Halbautomatische Migration bestehender ETL-Prozesse von Informatica nach Talend

Halbautomatische Migration bestehender ETL-Prozesse von Informatica nach Talend Halbautomatische Migration bestehender ETL-Prozesse von Informatica nach Talend Proof of Concept, Möglichkeiten und Grenzen Markus Pepping Dipl. Wirtschaftsinformatiker, IT-Architekt Senior Consultant

Mehr

Data Warehouse. für den Microsoft SQL SERVER 2000/2005

Data Warehouse. für den Microsoft SQL SERVER 2000/2005 Warehouse für den Microsoft SQL SERVER 2000/2005 Begriffe 1 DWH ( Warehouse) ist eine fachübergreifende Zusammenfassung von Datentabellen. Mart ist die Gesamtheit aller Datentabellen für einen fachlich

Mehr

7.4 Analyse anhand der SQL-Trace. 7.3.5 Vorabanalyse mit dem Code Inspector

7.4 Analyse anhand der SQL-Trace. 7.3.5 Vorabanalyse mit dem Code Inspector 7.4 Analyse anhand der SQL-Trace 337 7.3.5 Vorabanalyse mit dem Code Inspector Der Code Inspector (SCI) wurde in den vorangegangenen Kapiteln immer wieder erwähnt. Er stellt ein paar nützliche Prüfungen

Mehr

Data Warehouse Grundlagen

Data Warehouse Grundlagen Seminarunterlage Version: 2.10 Version 2.10 vom 24. Juli 2015 Dieses Dokument wird durch die veröffentlicht.. Alle Rechte vorbehalten. Alle Produkt- und Dienstleistungs-Bezeichnungen sind Warenzeichen

Mehr

Ein subjektiver Vergleich zwischen SSIS und Kettle mit Ausblick auf die Generierung von BI-Lösungen

Ein subjektiver Vergleich zwischen SSIS und Kettle mit Ausblick auf die Generierung von BI-Lösungen Ein subjektiver Vergleich zwischen SSIS und Kettle mit Ausblick auf die Generierung von BI-Lösungen vorgestellt am 29.09.2008 in der PASS Regionalgruppe Karlsruhe Michael Riedmüller inovex GmbH Project

Mehr

Datenintegration mit Informatica PowerCenter

Datenintegration mit Informatica PowerCenter Datenintegration mit Informatica PowerCenter Mein Weg vom Studenten zum Consultant Christoph Arnold 03.07.2013 1 Agenda Von der THM zu Infomotion Datenschieberei oder doch mehr? Die weite Welt von Informatica

Mehr

Einsatz der Mehrkörpersimulation in Verbindung mit Computertomographie in der Produktentwicklung

Einsatz der Mehrkörpersimulation in Verbindung mit Computertomographie in der Produktentwicklung Einsatz der Mehrkörpersimulation in Verbindung mit Computertomographie in der Produktentwicklung Hintergrund Bei komplexen Baugruppen ergeben sich sehr hohe Anforderungen an die Tolerierung der einzelnen

Mehr

A-Plan 12.0. Zeiterfassung 2.0. Ausgabe 1.1. Copyright. Warenzeichenhinweise

A-Plan 12.0. Zeiterfassung 2.0. Ausgabe 1.1. Copyright. Warenzeichenhinweise A-Plan 12.0 Zeiterfassung 2.0 Ausgabe 1.1 Copyright Copyright 1996-2014 braintool software gmbh Kein Teil dieses Handbuches darf ohne ausdrückliche Genehmigung von braintool software gmbh auf mechanischem

Mehr

Projekt AGB-10 Fremdprojektanalyse

Projekt AGB-10 Fremdprojektanalyse Projekt AGB-10 Fremdprojektanalyse 17. Mai 2010 1 Inhaltsverzeichnis 1 Allgemeines 3 2 Produktübersicht 3 3 Grundsätzliche Struktur und Entwurfsprinzipien für das Gesamtsystem 3 3.1 Die Prefuse Library...............................

Mehr

Data Warehouse Definition (1) http://de.wikipedia.org/wiki/data-warehouse

Data Warehouse Definition (1) http://de.wikipedia.org/wiki/data-warehouse Data Warehouse Definition (1) http://de.wikipedia.org/wiki/data-warehouse Ein Data-Warehouse bzw. Datenlager ist eine zentrale Datensammlung (meist eine Datenbank), deren Inhalt sich aus Daten unterschiedlicher

Mehr

Referenzprozessmodell zur erfolgreichen Durchführung von CRM - Projekten

Referenzprozessmodell zur erfolgreichen Durchführung von CRM - Projekten Referenzprozessmodell zur erfolgreichen Durchführung von CRM - Projekten Eine große Anzahl von CRM- Projekten scheitert oder erreicht die gesetzten Ziele nicht. Die Ursachen hierfür liegen oftmals in der

Mehr

Solution for Business Intelligence. MID Insight 2013

Solution for Business Intelligence. MID Insight 2013 Solution for Business Intelligence MID Insight 2013 A G E N D A 1. Solution für Business Intelligence (BI) 2. Die Gründe und Hintergründe 3. Die Methode 4. Vorteile MID GmbH 2013 2 Solution für Business

Mehr

Performanceoptimierung mit Exadata Verarbeitung extremer Datenmengen mit PL/SQL basierter Datenbewirtschaftung (Erfahrungsbericht)

Performanceoptimierung mit Exadata Verarbeitung extremer Datenmengen mit PL/SQL basierter Datenbewirtschaftung (Erfahrungsbericht) Performanceoptimierung mit Exadata Verarbeitung extremer Datenmengen mit PL/SQL basierter Datenbewirtschaftung (Erfahrungsbericht) Christian Haag, DATA MART Consulting Consulting Manager Oracle DWH Team

Mehr

Towards Automated Analysis of Business Processes for Financial Audits

Towards Automated Analysis of Business Processes for Financial Audits Towards Automated Analysis of Business Processes for Financial Audits Michael Werner Universität Hamburg michael.werner@wiso.uni hamburg.de Max Brauer Allee 60 22765 Hamburg StB Prof. Dr. Nick Gehrke Nordakademie

Mehr

Änderungen erkennen Schneller handeln Stefan Panek. Senior Consultant Christoph Jansen. Consultant 23.10.2008

Änderungen erkennen Schneller handeln Stefan Panek. Senior Consultant Christoph Jansen. Consultant 23.10.2008 Änderungen erkennen Schneller handeln Stefan Panek. Senior Consultant Christoph Jansen. Consultant 23.10.2008 Seit der Datenbankversion 9i bietet Oracle das Feature Change Data Capture an. Aber was genau

Mehr

Star-Schema-Modellierung mit ERwin - eine kritische Reflexion der Leistungspotentiale und Anwendungsmöglichkeiten

Star-Schema-Modellierung mit ERwin - eine kritische Reflexion der Leistungspotentiale und Anwendungsmöglichkeiten Star-Schema-Modellierung mit ERwin - eine kritische Reflexion der Leistungspotentiale und Anwendungsmöglichkeiten Michael Hahne T&I GmbH Workshop MSS-2000 Bochum, 24. März 2000 Folie 1 Worum es geht...

Mehr

Fördercontrolling im öffentlichen Bereich Aspekte beim Aufbau eines DWH. Software mit Format.

Fördercontrolling im öffentlichen Bereich Aspekte beim Aufbau eines DWH. Software mit Format. Fördercontrolling im öffentlichen Bereich Aspekte beim Aufbau eines DWH Gerd Schandert, Neuss den 18.03.2014 Agenda 1. Vorstellung Auftraggeber 2. Förderung allgemein 3. Schichten im Data Warehouse 4.

Mehr

Automatisierte Durchführung von Transporten in der Automic (UC4) Automation Engine - ONE Automation

Automatisierte Durchführung von Transporten in der Automic (UC4) Automation Engine - ONE Automation WF2Trans Automatisierte Durchführung von Transporten in der Automic (UC4) Automation Engine - ONE Automation Aus unserer langjährigen Erfahrung in Kundenprojekten wissen wir, dass ein klares und eindeutiges

Mehr

Data Mining-Projekte

Data Mining-Projekte Data Mining-Projekte Data Mining-Projekte Data Mining stellt normalerweise kein ei nmaliges Projekt dar, welches Erkenntnisse liefert, die dann nur einmal verwendet werden, sondern es soll gewöhnlich ein

Mehr

Kapitel II. Datenbereitstellung 2004 AIFB / FZI 1. Vorlesung Knowledge Discovery

Kapitel II. Datenbereitstellung 2004 AIFB / FZI 1. Vorlesung Knowledge Discovery Kapitel II Datenbereitstellung 2004 AIFB / FZI 1 II. Datenbereitstellung 2004 AIFB / FZI 2 II. Datenbereitstellung Collect Initial Data identify relevant attributes identify inconsistencies between sources

Mehr

Übungen zur Softwaretechnik

Übungen zur Softwaretechnik Technische Universität München Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering Markus Pister, Dr. Bernhard Rumpe WS 2002/2003 Lösungsblatt 1 17. Oktober 2002 www4.in.tum.de/~rumpe/se

Mehr

[accantum] Document Manager

[accantum] Document Manager [accantum] Document Manager Professionelle automatische Verarbeitung digitaler Belege. Multifunktionale Schnittstelle für vollständiges Output (COLD) und Input (Scan)- Management unter einheitlicher grafischer

Mehr

Business Intelligence. Data Warehouse / Analyse Sven Elvers 2005-07-06

Business Intelligence. Data Warehouse / Analyse Sven Elvers 2005-07-06 Business Intelligence Data Warehouse / Analyse Sven Elvers 2005-07-06 Einleitung Dieses Dokument beschreibt einen für das Verständnis relevanten Teil der Präsentation. Business Intelligence Motivation

Mehr

Motivation. Themenblock: Data Preprocessing. Einsatzgebiete für Data Mining I. Modell von Gianotti und Pedreschi

Motivation. Themenblock: Data Preprocessing. Einsatzgebiete für Data Mining I. Modell von Gianotti und Pedreschi Motivation Themenblock: Data Preprocessing We are drowning in information, but starving for knowledge! (John Naisbett) Was genau ist Datenanalyse? Praktikum: Data Warehousing und Data Mining Was ist Data

Mehr

Softwaretechnik. Fomuso Ekellem WS 2011/12

Softwaretechnik. Fomuso Ekellem WS 2011/12 WS 2011/12 Inhalt Projektvorstellung Übung 1 Wiederholung zusammengefasst Planungsphase Lernziele Ziele und Inhalt der Planungsphase Anlass und Aufgabestellung(Was ist dabei erförderlich) Requirement Engineering

Mehr

erfolgreich steuern Datenqualität rä dpunkt.verlag Ldwi Praxislösungen für Business-Intelligence-Projekte Rüdiger Eberlein Edition TDWI

erfolgreich steuern Datenqualität rä dpunkt.verlag Ldwi Praxislösungen für Business-Intelligence-Projekte Rüdiger Eberlein Edition TDWI Detlef Apel Wolfgang Behme Rüdiger Eberlein Christian Merighi Datenqualität erfolgreich steuern Praxislösungen für Business-Intelligence-Projekte 3., überarbeitete und erweiterte Auflage Edition TDWI rä

Mehr

The integration of business intelligence and knowledge management

The integration of business intelligence and knowledge management The integration of business intelligence and knowledge management Seminar: Business Intelligence Ketevan Karbelashvili Master IE, 3. Semester Universität Konstanz Inhalt Knowledge Management Business intelligence

Mehr

Handbuch ECDL 2003 Basic Modul 5: Datenbank Grundlagen von relationalen Datenbanken

Handbuch ECDL 2003 Basic Modul 5: Datenbank Grundlagen von relationalen Datenbanken Handbuch ECDL 2003 Basic Modul 5: Datenbank Grundlagen von relationalen Datenbanken Dateiname: ecdl5_01_00_documentation_standard.doc Speicherdatum: 14.02.2005 ECDL 2003 Basic Modul 5 Datenbank - Grundlagen

Mehr

1 Einleitung. 1.1 Caching von Webanwendungen. 1.1.1 Clientseites Caching

1 Einleitung. 1.1 Caching von Webanwendungen. 1.1.1 Clientseites Caching 1.1 Caching von Webanwendungen In den vergangenen Jahren hat sich das Webumfeld sehr verändert. Nicht nur eine zunehmend größere Zahl an Benutzern sondern auch die Anforderungen in Bezug auf dynamischere

Mehr

Cubeware Connectivity for SAP Solutions

Cubeware Connectivity for SAP Solutions Cubeware Connectivity for SAP Solutions Beispiele und Anwendungsfälle 1. Modellierung, Extraction, Transformation und Loading mit Datenquelle SAP R/3 und mysap ERP Mit Hilfe des Cubeware Importers und

Mehr

Business Intelligence und Geovisualisierung in der Gesundheitswirtschaft

Business Intelligence und Geovisualisierung in der Gesundheitswirtschaft Business Intelligence und Geovisualisierung in der Gesundheitswirtschaft Prof. Dr. Anett Mehler-Bicher Fachhochschule Mainz, Fachbereich Wirtschaft Prof. Dr. Klaus Böhm health&media GmbH 2011 health&media

Mehr

Survival Guide für Ihr Business Intelligence-Projekt

Survival Guide für Ihr Business Intelligence-Projekt Survival Guide für Ihr Business Intelligence-Projekt Sven Bosinger Solution Architect BI Survival Guide für Ihr BI-Projekt 1 Agenda Was ist Business Intelligence? Leistungsumfang Prozesse Erfolgsfaktoren

Mehr

Einbindung eines Buchungs- und Ticketingsystems in eine bestehende Anwendungslandschaft

Einbindung eines Buchungs- und Ticketingsystems in eine bestehende Anwendungslandschaft Einbindung eines Buchungs- und Ticketingsystems in eine bestehende Anwendungslandschaft Harald Lange sd&m Lübecker Str. 1 22087 Hamburg harald.lange@sdm.de Abstract: Mit der Einführung eines Buchungs-

Mehr

Integrating Architecture Apps for the Enterprise

Integrating Architecture Apps for the Enterprise Integrating Architecture Apps for the Enterprise Ein einheitliches Modulsystem für verteilte Unternehmensanwendungen Motivation und Grundkonzept Inhalt Problem Ursache Herausforderung Grundgedanke Architektur

Mehr

tcvision Freigabemitteilung Version 6

tcvision Freigabemitteilung Version 6 tcvision Freigabemitteilung Version 6 Stand: 5. Mai 2015 TCP/IP TCP/IP Verbindungen werden dynamisch auf- und abgebaut, um Stabilitätsproblemen in der Infrastruktur zu begegnen. Mit Hilfe des tcscript

Mehr

In die Zeilen würden die Daten einer Adresse geschrieben werden. Das Ganze könnte in etwa folgendermaßen aussehen:

In die Zeilen würden die Daten einer Adresse geschrieben werden. Das Ganze könnte in etwa folgendermaßen aussehen: 1 Einführung in Datenbanksysteme Fast jeder kennt Excel und hat damit in seinem Leben schon einmal gearbeitet. In Excel gibt es Arbeitsblätter, die aus vielen Zellen bestehen, in die man verschiedene Werte

Mehr

Datenqualität erfolgreich steuern

Datenqualität erfolgreich steuern Edition TDWI Datenqualität erfolgreich steuern Praxislösungen für Business-Intelligence-Projekte von Detlef Apel, Wolfgang Behme, Rüdiger Eberlein, Christian Merighi 3., überarbeitete und erweiterte Auflage

Mehr

Was ist DITA und was bringt es? www.ditaworks.com

Was ist DITA und was bringt es? www.ditaworks.com www.ditaworks.com Wir leben im Informationszeitalter und sind einem exponentiellen Anstieg neuer Daten und Informationen ausgesetzt. Nach neusten Studien können wir davon ausgehen, dass 90% aller verfügbaren

Mehr

Managed VPSv3 Was ist neu?

Managed VPSv3 Was ist neu? Managed VPSv3 Was ist neu? Copyright 2006 VERIO Europe Seite 1 1 EINFÜHRUNG 3 1.1 Inhalt 3 2 WAS IST NEU? 4 2.1 Speicherplatz 4 2.2 Betriebssystem 4 2.3 Dateisystem 4 2.4 Wichtige Services 5 2.5 Programme

Mehr

Welche Daten gehören ins Data Warehouse?

Welche Daten gehören ins Data Warehouse? Welche Daten gehören ins Warehouse? Dani Schnider Principal Consultant 9. Januar 2012 In vielen DWH-Projekten stellt sich die Frage, welche Daten im Warehouse gespeichert werden sollen und wie dieser Datenumfang

Mehr

A Generic Database Web Service for the Venice Lightweight Service Grid

A Generic Database Web Service for the Venice Lightweight Service Grid A Generic Database Web Service for the Venice Lightweight Service Grid Michael Koch Bachelorarbeit Michael Koch University of Kaiserslautern, Germany Integrated Communication Systems Lab Email: m_koch2@cs.uni-kl.de

Mehr

Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme. Tillmann Schall, anaptecs GmbH

Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme. Tillmann Schall, anaptecs GmbH Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme Tillmann Schall, anaptecs GmbH : Agenda Grundlagen modellgetriebener Entwicklungsprozesse Schritte zur Einführung Erfahrungen

Mehr

Oracle Warehousebuilder. Version 9.2.0.2.8 In Version 9.2er Umgebung

Oracle Warehousebuilder. Version 9.2.0.2.8 In Version 9.2er Umgebung Oracle Warehousebuilder Version 9.2.0.2.8 In Version 9.2er Umgebung Themenüberblick Architektur Vorbereitung Ablauf und Details Anmerkungen / Probleme Architektur GEBIS (Source) Datenfluss

Mehr

Enterprise Resource Suite. Produkt Beschreibung

Enterprise Resource Suite. Produkt Beschreibung Enterprise Resource Suite Produkt Beschreibung Inhaltsverzeichnis 1 Summary... 2 2 Enterprise Resource Suite (ERS)... 3 3 ERS-Analyzing... 4 3.1 Belegung der Plattensysteme... 4 3.2 Verzeichnisbelegung...

Mehr

Oracle BI Publisher in der Oracle Business Intelligence Enterprise Edition Plus. Eine Mehrwertdiskussion

Oracle BI Publisher in der Oracle Business Intelligence Enterprise Edition Plus. Eine Mehrwertdiskussion Oracle BI Publisher in der Oracle Business Intelligence Enterprise Edition Plus Eine Mehrwertdiskussion Der Oracle BI Publisher als Teil der Oracle BI Suite versus Oracle BI Publisher Standalone Der Oracle

Mehr

Nach Data Warehousing kommt Business Intelligence

Nach Data Warehousing kommt Business Intelligence Nach Data Warehousing kommt Business Intelligence Andrea Kennel Trivadis AG Glattbrugg, Schweiz Schlüsselworte: Business Intelligence, Data Warehouse Zusammenfassung Data Warehouse bedeutet, dass operative

Mehr

Powerful PL/SQL: Collections indizieren mit VARCHAR2- Indizes ein Praxisbeispiel

Powerful PL/SQL: Collections indizieren mit VARCHAR2- Indizes ein Praxisbeispiel Powerful PL/SQL: Collections indizieren mit VARCHAR2- Indizes ein Praxisbeispiel Schlagworte Autor: Klaus Friemelt, MT AG dynamisches BULK SQL, VARCHAR2-indizierte PL/SQL-Tabellen Einleitung Mit den letzten

Mehr

Tipps & Tricks. Neues, Nützliches und Praktisches. Christian Dahmen con terra GmbH

Tipps & Tricks. Neues, Nützliches und Praktisches. Christian Dahmen con terra GmbH Tipps & Tricks Neues, Nützliches und Praktisches Christian Dahmen con terra GmbH 1 Qualitätssicherung von Geodaten Qualitätssicherung von Geodaten Mit FME lassen sich einfache und komplexe Prüfroutinen

Mehr

IBM Informix SQL. Seminarunterlage. Version 11.04 vom

IBM Informix SQL. Seminarunterlage. Version 11.04 vom Seminarunterlage Version: 11.04 Version 11.04 vom 27. April 2015 Dieses Dokument wird durch die veröffentlicht.. Alle Rechte vorbehalten. Alle Produkt- und Dienstleistungs-Bezeichnungen sind Warenzeichen

Mehr

Kapitel II. Datenbereitstellung. II. Datenbereitstellung. II.1 Grundlagen. II. Datenbereitstellung. Collect Initial Data. II.

Kapitel II. Datenbereitstellung. II. Datenbereitstellung. II.1 Grundlagen. II. Datenbereitstellung. Collect Initial Data. II. II. bereitstellung Kapitel II bereitstellung 1 2 II. bereitstellung II.1 Grundlagen Collect Initial Data identify relevant attributes identify inconsistencies between sources Describe Data characterize

Mehr

//einfach und mittelstandsgerecht. aruba //Enterprise Query. Datenextraktion und Datenbereitstellung Ad-hoc Analyse Taskplaner.

//einfach und mittelstandsgerecht. aruba //Enterprise Query. Datenextraktion und Datenbereitstellung Ad-hoc Analyse Taskplaner. Enterprise Query //einfach und mittelstandsgerecht aruba //Enterprise Query Datenextraktion und Datenbereitstellung Ad-hoc Analyse Taskplaner aruba //Enterprise Query einfach Daten abfragen und veröffentlichen

Mehr

6 InfoCubes erstellen und konfigurieren

6 InfoCubes erstellen und konfigurieren InfoCubes bilden die Reportingschicht in der LSA; sie sind für die Performance des Reportings entscheidend. In diesem Kapitel stellen wir Ihnen vor, welche InfoCubes es gibt und wie Sie damit arbeiten.

Mehr

ITS Business Integrator

ITS Business Integrator IBI Weboberfläche zur Datenintegration Location Viewer Asset-Management Smallworld GIS Monitoring Planung Bau Wartung Entstörung Integration Der ITS Business Integrator (IBI) ist eine offene Plattform

Mehr

ETL in den Zeiten von Big Data

ETL in den Zeiten von Big Data ETL in den Zeiten von Big Data Dr Oliver Adamczak, IBM Analytics 1 1 Review ETL im Datawarehouse 2 Aktuelle Herausforderungen 3 Future of ETL 4 Zusammenfassung 2 2015 IBM Corporation ETL im Datawarehouse

Mehr

eadmin Manual Universitätsstraße 3 56070 Koblenz Deutschland

eadmin Manual Universitätsstraße 3 56070 Koblenz Deutschland DOKUMENT: TYP: ERSTELLT VON: Manual nova ratio AG Universitätsstraße 3 56070 Koblenz Deutschland VERSION: STAND: 9.x 23. September 2015 Inhaltsverzeichnis 1 2 2.1 2.2 2.3 3 3.1 3.2 3.3 4 4.1 4.2 4.3 4.4

Mehr

ERP-Connector für MHS

ERP-Connector für MHS Whitepaper ERP-Connector für MHS VERSION 2.0 ERSTELLT AM 10.01.2013 Zusammenfassung Der ERP-Connector für MHS ist ein innovatives Werkzeug, dass es IT-Abteilungen und BI- Administratoren auf einfache und

Mehr

Suche schlecht beschriftete Bilder mit Eigenen Abfragen

Suche schlecht beschriftete Bilder mit Eigenen Abfragen Suche schlecht beschriftete Bilder mit Eigenen Abfragen Ist die Bilderdatenbank über einen längeren Zeitraum in Benutzung, so steigt die Wahrscheinlichkeit für schlecht beschriftete Bilder 1. Insbesondere

Mehr

Die Bedeutung abstrakter Datentypen in der objektorientierten Programmierung. Klaus Kusche, September 2014

Die Bedeutung abstrakter Datentypen in der objektorientierten Programmierung. Klaus Kusche, September 2014 Die Bedeutung abstrakter Datentypen in der objektorientierten Programmierung Klaus Kusche, September 2014 Inhalt Ziel & Voraussetzungen Was sind abstrakte Datentypen? Was kann man damit grundsätzlich?

Mehr

Process Streamlining:

Process Streamlining: Process Streamlining: Geschäftsprozesse in globalen Business Software-Lösungen Dr. Frank Schönthaler Michael Mohl PROMATIS software GmbH Ettlingen/Baden Schlüsselworte Business Process Streamlining, Multinationaler

Mehr

Data-Vault-Automation aus dem Datenmodellierungstool. 1. Tagung der DDVUG am 24.Juni2014

Data-Vault-Automation aus dem Datenmodellierungstool. 1. Tagung der DDVUG am 24.Juni2014 Data-Vault-Automation aus dem Datenmodellierungstool 1. Tagung der DDVUG am 24.Juni2014 A G E N D A 1. MID & Innovator 2. Modell & Methode 3. Architektur & Automatisierung 4. Nutzen & Veränderung MID GmbH

Mehr

Wie Fusion CRM die Datenqualität im Marketingprozess erhöhen kann (Fusion CRM@ec4u)

Wie Fusion CRM die Datenqualität im Marketingprozess erhöhen kann (Fusion CRM@ec4u) Wie Fusion CRM die Datenqualität im Marketingprozess erhöhen kann (Fusion CRM@ec4u) Jeder kennt folgende Sätze aus seinem eigenen Unternehmen: Wieso sind so viele doppelte Einträge im System? Kann man

Mehr

Probeklausur. Lenz Belzner. January 26, 2015. Lenz Belzner Probeklausur January 26, 2015 1 / 16

Probeklausur. Lenz Belzner. January 26, 2015. Lenz Belzner Probeklausur January 26, 2015 1 / 16 Probeklausur Lenz Belzner January 26, 2015 Lenz Belzner Probeklausur January 26, 2015 1 / 16 Definieren Sie Software Engineering in Abgrenzung zu Individual Programming. Ingenieursdisziplin professionelle

Mehr

Quality Point München Datenqualität

Quality Point München Datenqualität Quality Point München Datenqualität Paul, wie ist denn Eure Datenqualität? Nachdem ich bei der letzten Gehaltszahlung mit Frau... angeredet wurde, bin ich mir nicht mehr so sicher. Autor: W. Ulbrich IT&More

Mehr

Marketing Intelligence Schwierigkeiten bei der Umsetzung. Josef Kolbitsch Manuela Reinisch

Marketing Intelligence Schwierigkeiten bei der Umsetzung. Josef Kolbitsch Manuela Reinisch Marketing Intelligence Schwierigkeiten bei der Umsetzung Josef Kolbitsch Manuela Reinisch Übersicht Schwierigkeiten bei der Umsetzung eines BI-Systems Schwierigkeiten der Umsetzung 1/13 Strategische Ziele

Mehr

1. Einleitung. 1.1. Ausgangssituation

1. Einleitung. 1.1. Ausgangssituation 1. Einleitung In der vorliegenden Arbeit wird untersucht, welche Faktoren den erfolgreichen Ausgang eines Supply-Chain-Projektes zwischen zwei Projektpartnern beeinflussen. Dazu werden zum einen mögliche

Mehr

Innovatives Reporting mit PM10: Analysen und Berichte mit Single Point of Truth 11.00 11.45 Uhr

Innovatives Reporting mit PM10: Analysen und Berichte mit Single Point of Truth 11.00 11.45 Uhr Copyright 2007 Infor. Alle Rechte vorbehalten. Innovatives Reporting mit PM10: Analysen und Berichte mit Single Point of Truth 11.00 11.45 Uhr Hubertus Thoma Presales Consultant PM Schalten Sie bitte während

Mehr

Die Datenhoheit kehrt ins Controlling zurück

Die Datenhoheit kehrt ins Controlling zurück Die Datenhoheit kehrt ins Controlling zurück Dennis Giese, Forensis Finance & Controlling AG Das webbasierte Oracle Hyperion Financial Data Quality Management Enterprise Edition (FDM EE) orientiert sich

Mehr

Master Data Management

Master Data Management Master Data Management Warum Stammdatenmanagement Komplexität reduzieren Stammdatenmanagement bringt Ordnung in ihre Stammdaten. Doubletten werden erkannt und gesperrt. Stammdaten verschiedener Quellsysteme

Mehr

Geschäftsprozessmanagement

Geschäftsprozessmanagement Geschäftsprozessmanagement Der INTARGIA-Ansatz Whitepaper Dr. Thomas Jurisch, Steffen Weber INTARGIA Managementberatung GmbH Max-Planck-Straße 20 63303 Dreieich Telefon: +49 (0)6103 / 5086-0 Telefax: +49

Mehr

SOA und Business Intelligence. Whitepaper von Thomas Volz

SOA und Business Intelligence. Whitepaper von Thomas Volz SOA und Business Intelligence Whitepaper von Thomas Volz I N H A LT 1 Zielsetzung dieses Whitepapers 2 Was ist SOA? 3 Warum ist das gerade jetzt ein Thema? 3 Was ist der Nutzen für den BI-Anwender? 4 Wird

Mehr

ETL Monitoring & Tuning durch Auswertung der OWB Laufzeit-Metadaten. Referent: Lutz Bauer, Leiter CC Data Integration, MT AG

ETL Monitoring & Tuning durch Auswertung der OWB Laufzeit-Metadaten. Referent: Lutz Bauer, Leiter CC Data Integration, MT AG ETL Monitoring & Tuning durch Auswertung der OWB Laufzeit-Metadaten Referent: Lutz Bauer, Leiter CC Data Integration, MT AG MT AG managing technology Key-facts: 1994: Gründung als MT Software GmbH 2000:

Mehr

Logische Modellierung von Data Warehouses

Logische Modellierung von Data Warehouses Logische Modellierung von Data Warehouses Vertiefungsarbeit von Karin Schäuble Gliederung. Einführung. Abgrenzung und Grundlagen. Anforderungen. Logische Modellierung. Methoden.. Star Schema.. Galaxy-Schema..

Mehr

Einführung in SQL Datenbanken bearbeiten

Einführung in SQL Datenbanken bearbeiten Einführung in SQL Datenbanken bearbeiten Jürgen Thomas Entstanden als Wiki-Buch Bibliografische Information Diese Publikation ist bei der Deutschen Nationalbibliothek registriert. Detaillierte Angaben

Mehr

WENDIA ITSM EXPERT TALK

WENDIA ITSM EXPERT TALK WENDIA ITSM EXPERT TALK WENDIA ITSM WHITEPAPER IT SERVICE MANAGEMENT BASISWISSEN: IN EINFACHEN SCHRITTEN ZUR CMDB Wer, Wie, Was: Die CMDB als Herzstück eines funktionierenden IT Service Management Die

Mehr

SAP BW + Microsoft Excel Viel genutzt, oft unterschätzt

SAP BW + Microsoft Excel Viel genutzt, oft unterschätzt Corporate Performance Management SAP BW + Microsoft Excel Viel genutzt, oft unterschätzt Martin Krejci, Manager CPM Matthias Schmidt, BI Consultant Kristian Rümmelin, Senior BI Consultant Braincourt GmbH

Mehr

Grundlagen der Verwendung von make

Grundlagen der Verwendung von make Kurzskript zum Thema: Grundlagen der Verwendung von make Stefan Junghans Gregor Gilka 16. November 2012 1 Einleitung In diesem Teilskript sollen die Grundlagen der Verwendung des Programmes make und der

Mehr

7 Die Reorganisation von DB2

7 Die Reorganisation von DB2 Ab und an sollte eine Tabelle reorganisiert werden. Besonders, nachdem größere Datenmengen eingefügt oder gelöscht wurden, muß über eine Reorganisation nachgedacht werden. Eine optimale Performance ist

Mehr

Entwicklung eines Scheduling-Verfahrens zur Optimierung der Reihenfolge von Prototypentests. Masterarbeit

Entwicklung eines Scheduling-Verfahrens zur Optimierung der Reihenfolge von Prototypentests. Masterarbeit Entwicklung eines Scheduling-Verfahrens zur Optimierung der Reihenfolge von Prototypentests Masterarbeit zur Erlangung des akademischen Grades Master of Science (M.Sc.) im Masterstudiengang Wirtschaftswissenschaft

Mehr

Data Warehousing. Kapitel 1: Data-Warehousing-Architektur. Folien teilweise übernommen von Matthias Gimbel

Data Warehousing. Kapitel 1: Data-Warehousing-Architektur. Folien teilweise übernommen von Matthias Gimbel Data Warehousing Kapitel 1: Data-Warehousing-Architektur Folien teilweise übernommen von Matthias Gimbel 2 Analyse von Geschäftsprozessen Mögliche Fragestellungen Wie entwickelt sich unser Umsatz im Vergleich

Mehr

Whitepaper Externe Speicherung von Binary Large Objects (BLOBs) mit SharePoint 2007 sowie SQL Server 2005 / 2008

Whitepaper Externe Speicherung von Binary Large Objects (BLOBs) mit SharePoint 2007 sowie SQL Server 2005 / 2008 Externe Speicherung von Binary Large Objects (BLOBs) mit SharePoint 2007 sowie SQL Andreas Glaser, 23. September 2008 Teufenerstrasse 19 CH 9001 St.Gallen t [+41] 71 228 67 77 f [+41] 71 228 67 88 info@namics.com

Mehr

System Landscape Optimization. Karl Nagel, Patrick Müller

System Landscape Optimization. Karl Nagel, Patrick Müller System Landscape Optimization Karl Nagel, by CaRD / CaRD PLM 2008 Schritte > Voraussetzung: Prozessharmonisierung und Systemintegration > 1. Erstellung eines neuen Meta-Datenmodells/Vereinbarung der gültigen

Mehr