Entwicklung eines ETL Vorgehensmodells für Data Warehouse Projekte

Transkript

1 Entwicklung eines ETL Vorgehensmodells für Data Warehouse Projekte Tobias Fellner geboren am Dortmund, Kurzfassung Thema dieser Arbeit ist die Entwicklung eines ETL Vorgehensmodells für Data Warehouse Projekte. Ein Vorgehensmodell ist notwendig, um die Komplexität derartiger Projekte beherrschbar zu machen. Die Grundstruktur des Vorgehensmodells ist ein iterativ-inkrementelles Phasenmodell. Die Phasen des Vorgehensmodells sind Bedarfsanalyse, Anforderungsanalyse, Architektur, Konstruktion und Produktionsübernahme. Damit wird der gesamte Projektlebenszyklus abgedeckt. Über den Projektumfang hinaus wird eine Betriebsphase beschrieben und dadurch zwischen Projekt- und Produktlebenszyklus abgegrenzt. Für jede Phase sind Aufgaben, Rollen und Ergebnisse definiert. Die einzelnen Elemente werden in den Phasen beschrieben. Nach seiner Einführung wird das entwickelte Vorgehensmodell in den Kontext der Softwaretechnik eingeordnet und anhand definierter Kriterien überprüft und bewertet. Die Arbeit schließt mit einer Zusammenfassung und einem Ausblick. Abstract Subject of this thesis is the development an ETL process model for Data Warehouse Projects. A process model is necessary to make the complexity of such projects controllable. The process models basic structure is an iterative and incremental stage model. The stages are demand analysis, requirements analysis, architecture, construction, roll-out. This covers the complete Project life cycle. Beyond the project scope an operating stage is described. Each stage contains roles, tasks and results. These elements are described within the stages. After the process model is described it is classified and evaluated by defined criteria. This thesis ends with a summary and an outlook on future work

2 Inhaltsverzeichnis 1 Einleitung Grundlagen Data Warehouse ETL Prozesse Business Intelligence Szenarien Data Warehouse Referenzarchitektur Vorgehensmodelle in der Informatik Übersicht über aktuelle Vorgehensmodelle Einführung in das ETL Vorgehensmodell Darstellungsstruktur des Vorgehensmodells Überblick über die Hauptphasen Bedarfsanalyse Beschreibung Vorbedingungen Rollen Aufgaben Ergebnis Diskussion Management Beschreibung Vorbedingungen Rollen Aufgaben Ergebnis Diskussion Anforderungsanalyse Beschreibung Vorbedingungen Rollen Aufgaben Ergebnis Diskussion Architektur...72 I

3 7.1 Beschreibung Vorbedingungen Rollen Aufgaben Ergebnis Diskussion Konstruktion Beschreibung Vorbedingungen Rollen Aufgaben Ergebnis Diskussion Produktionsübernahme Beschreibung Vorbedingungen Rollen Aufgaben Ergebnis Diskussion Betrieb Beschreibung Vorbedingungen Rollen Aufgaben Ergebnis Diskussion Ergebnis und Diskussion Einordnung des Vorgehensmodells Bewertung des Vorgehensmodells Zusammenfassung und Ausblick A. Abbildungsverzeichnis B. Tabellenverzeichnis C. Literaturverzeichnis D. Anhang...1 II

4 1 Einleitung Der wirtschaftliche Erfolg von Unternehmen hängt in zunehmendem Maße von der Verfügbarkeit geschäftlicher Informationen ab. Informationen bilden die Grundlage für strategische und taktische Entscheidungen, die Fachanwender und Management regelmäßig zu treffen haben. Entscheidungen sind umso fundierter, je valider, aktueller und umfassender die zugrunde liegenden Informationen sind. Dadurch ist die Verfügbarkeit derartiger Informationen ein wesentlicher Faktor der Wettbewerbsfähigkeit eines Unternehmens. Informationen liegen in Unternehmen theoretisch in großer Menge vor. Bei nahezu jeder geschäftlichen Aktivität werden Informationen generiert, die in Form von Daten gespeichert werden. Die Problematik ist, dass Daten in heterogenen, verteilten Systemen und in undefinierter Qualität vorliegen. Daher ist es schwierig, aus diesen Informationen Wissen zu gewinnen. Zusätzlich erschwert die meist unklare Qualität der Daten das Vertrauen in die enthaltenen Informationen. Diese Problematik kann durch ein Data Warehouse gelöst werden. In einem Data Warehouse werden Daten aus allen relevanten, operativen Quellen integriert und zu Analysezwecken bereitgestellt. Ein Data Warehouse stellt somit das zentrale Datenlager der Informationsinfrastruktur eines Unternehmens dar. Durch ETL Prozesse wird ein Data Warehouse mit Daten versorgt. ETL steht für Extract, Transform, Load und beschreibt Prozesse, die Daten aus Datenquellen extrahieren, diese Daten entsprechend den Anforderungen aufbereiten und anschließend die aufbereiteten Daten in Datenziele, zum Beispiel ein Data Warehouse, laden. Während der Transformationsphase eines ETL Prozesses werden die Daten homogenisiert, integriert und in ein geeignetes Schema übertragen. Darüber hinaus wird die Datenqualität überprüft und gegebenenfalls erhöht. Dadurch wird das Vertrauen in das Data Warehouse und die darin enthaltenen Informationen verbessert. In seiner Funktion als Datenlager bildet das Data Warehouse die Grundlage für Business Intelligence Anwendungen. Diese Anwendungen greifen auf den Datenbestand des Data Warehouse zu und ermöglichen durch verschiedene, in erster Linie analytische, Verfahren aus Informationen Wissen zu generieren. Anhand der genannten Punkte, insbesondere der Verbesserung der Wettbewerbsfähigkeit wird die Bedeutung von Data Warehousing und damit der ETL Entwicklung deutlich. Diese Bedeutung steigt kontinuierlich weiter (Gartner Inc., 2008). Dadurch nehmen die Themenfelder Data Warehousing und ETL neben der klassischen Softwareentwicklung einen wichtigen Platz in der Informatik ein. Die Entwicklung von ETL Prozessen ist komplex. Sie erfordert fachbereichsübergreifendes Denken und umfangreiches technisches Wissen. In Data Warehouse Projekten kann die Implementierung von ETL Prozessen einen sehr großen Anteil am Gesamtaufwand in Anspruch nehmen. Literaturquellen sprechen von Aufwänden zwischen 50% (Kurz, 1999 S. 266) und 80% (Bange, 2006 S. 64) des Gesamtvolumens eines Data Warehouse Projekts. Aus der fachlichen und technischen Komplexität ergeben sich hohe Risiken bei der Projektdurchführung. Verstärkt werden die Risiken insbesondere durch die Begrenzung von Budget, Zeit und Ressourcen bei gleichzeitig hohen Anforderungen an die Qualität der Ergebnisse. Seite 1 von 141

5 Um den Entwicklungsprozess und die damit verbundenen Risiken beherrschbar zu machen, ist ein strukturiertes, planmäßiges Vorgehen erforderlich. Ziel ist die erfolgreiche Projektdurchführung unter Einhaltung aller Restriktionen und mit qualitativ hochwertigen Ergebnissen. Darüber hinaus sollen Projekte vergleichbar und wiederholbar werden. Dadurch können Erkenntnisse zwischen verschiedenen Projekten übertragen werden und so das Vorgehen kontinuierlich verbessert werden. In der Softwaretechnik gibt es zur Erfüllung dieser Forderungen Vorgehensmodelle zur Softwareentwicklung. In einem Vorgehensmodell wird das notwendige Vorgehen soweit von konkreten Projekten abstrahiert, dass sie sich generisch auf verschiedene Softwareentwicklungsszenarien übertragen lassen. Dem entgegen gibt es für die ETL Entwicklung bisher trotz ähnlicher Anforderungen keine standardisierten Vorgehensmodelle. Ziel dieser Arbeit ist es, ein ETL Vorgehensmodell für Data Warehouse Projekte zu entwickeln. Das Vorgehensmodell soll dabei den gesamten Projektlebenszyklus beleuchten. Alle notwendigen Aktivitäten sollen identifiziert und beschrieben werden. Eine Herausforderung dabei ist, die identifizierten Aufgaben zu strukturieren und in Beziehung zueinander zu setzen. Zusätzlich zu den Aktivitäten werden Rollen identifiziert und einzelnen Phasen zugeordnet. Eine Zuordnung von Rollen zu einzelnen Aufgaben befindet sich im Anhang dieser Arbeit. Betrachtungsgegenstand dieser Arbeit ist die ETL Entwicklung. Die Entwicklung von Data Warehouse Systemen ist dagegen nicht Schwerpunkt der Arbeit. Aufgrund des engen thematischen Zusammenhangs müssen Überschneidungen beider Themengebiete jedoch betrachtet werden. Für das weitere Verständnis werden in Kapitel zwei zunächst die Grundlagen vermittelt. Dabei werden die Konzepte des Data Warehousing und von ETL Prozessen vorgestellt. Zusätzlich erfolgt eine kurze Einführung in Business Intelligence Anwendungen sowie die Beschreibung einer Data Warehouse Referenzarchitektur. Nach Behandlung der technischen Grundlagen folgt eine Einführung in die Grundlagen von Vorgehensmodellen. Dabei werden Kriterien zur Einordnung und zur Bewertung von Vorgehensmodellen erläutert. Zusätzlich werden wichtige, aktuelle Vorgehensmodelle vorgestellt und bewertet. In Kapitel drei wird das im Rahmen dieser Arbeit entwickelte ETL Vorgehensmodell eingeführt. Hierfür wird zunächst die Struktur des Vorgehensmodells dargestellt. Die Struktur des Vorgehensmodells wird aus der Literatur, Ansätzen der Softwaretechnik und den in den Grundlagen beschriebenen Vorgehensmodellen hergeleitet. Zusätzlich wird eine Übersicht über alle Phasen des Vorgehensmodells und die Zuordnung aller Aufgaben zu den Phasen dargestellt. Die einzelnen Aufgaben werden aus der Literatur und der Praxis hergeleitet. Anschließend wird die Vorgehensweise zur Darstellung des Vorgehensmodells in dieser Arbeit beschrieben. Den Abschluss von Kapitel drei bildet eine Übersicht über die Hauptphasen des Vorgehensmodells. Die Kapitel vier bis zehn beschreiben die einzelnen Phasen des Vorgehensmodells. In Kapitel vier wird die Bedarfsanalyse, die der Feststellung der Projektziele und der Projektvorbereitung dient, beschrieben. Seite 2 von 141

6 Kapitel fünf beschreibt die Managementphase, die die Stützprozesse Projektmanagement, Konfigurationsmanagement und Qualitätsmanagement umfasst. Darauf folgt in Kapitel sechs die Anforderungsanalyse. Während der Anforderungsanalyse werden die definierten Ziele der Bedarfsanalyse auf konkrete Anforderungen abgebildet. Der Schwerpunkt dieser Phase liegt auf der Analyse der Quelldaten und deren Qualität. Anschließend wird in Kapitel sieben die Architektur behandelt. Dabei wird basierend auf einer Analyse des Ist Zustands und den definierten Anforderungen die technische Infrastruktur entworfen und bereitgestellt. Kapitel acht beschreibt die Konstruktionsphase. Die Konstruktion umfasst Design, Implementierung und Test der Datenziele und ETL Prozesse. Ein Betrachtungsschwerpunkt dieser Phase liegt auf der Entwicklung geeigneter Transformationen und der Behandlung der Datenqualität. Kapitel neun beschreibt das Vorgehen der Produktionsübernahmephase. Aktivitäten der Phase sind die Bereitstellung des entwickelten Systems sowie die Durchführung der Endabnahme. Außerdem wird der Betrieb des Systems geplant. Als letzter Teil des Vorgehensmodells wird in Kapitel zehn der Betrieb beschrieben. Der Betrieb ist kein Bestandteil der Projektdurchführung, die Darstellung dient der Abgrenzung von Projekt und Betrieb. Zu den Aufgaben des Betriebs gehören Überwachung, Steuerung und Wartung des Systems. In Kapitel elf beginnt der Schlussteil dieser Arbeit. Darin wird das entwickelte Vorgehensmodell zunächst eingeordnet und anschließend anhand der in den Grundlagen vorgestellten Kriterien bewertet. In Kapitel zwölf schließt diese Arbeit mit einer Zusammenfassung und einem kurzen Ausblick auf zukünftige Forschungsansätze. Seite 3 von 141

7 2 Grundlagen Dieses Kapitel dient der Einführung in die Thematik und der Vermittlung von Grundlagen, die für das weitere Verständnis erforderlich sind. Dabei werden zuerst die Begriffe Data Warehouse und ETL geklärt und eingeordnet, anschließend werden Grundlagen zu Vorgehensmodellen vermittelt und eine Auswahl wichtiger Vorgehensmodelle vorgestellt. 2.1 Data Warehouse Der Begriff Data Warehouse wurde erstmals durch William H. Inmon (Inmon, 1992) eingeführt. Inmon definiert das Data Warehouse wie folgt: A Data Warehouse is a subject-oriented, integrated, time-variant and nonvolatile collection of Data in support of management s Decision support process. Inmons Definition stellt vier Kernforderungen an ein Data Warehouse. Diese sind übersetzt: Themenorientierung (subject-oriented) Der Datenbestand eines Data Warehouse wird nach fachlichen, häufig betriebswirtschaftlichen Kriterien ausgewählt und organisiert. Integration (integrated) Ein Data Warehouse wird aus verschiedenen, heterogenen Quellen mit Daten gefüllt. Die Daten müssen vor ihrer Übertragung in das Data Warehouse in Struktur und Format vereinheitlicht werden. Historisierung (time-variant) Das Data Warehouse ermöglicht Zeitreihenanalysen, also den Vergleich von Daten über die Zeit. Dadurch werden Veränderungen und Entwicklungen deutlich. Hierfür werden die gespeicherten Daten in einen Zeitbezug gesetzt. Persistenz (nonvolatile) Der Datenbestand eines Data Warehouse ist beständig. Einmal gespeicherte Daten werden weder geändert noch gelöscht. Ein Data Warehouse stellt demnach einen vereinheitlichten, quellenübergreifenden Datenbestand zentral zur Verfügung. Dadurch bildet es die Grundlage für organisationsübergreifende Analysen. Aus dieser Definition wird deutlich, dass sich das Konzept des Data Warehouse fundamental von dem operativer Systeme der Datenhaltung unterscheidet. Mit operativen Systemen werden in der Regel Geschäftsprozesse abgebildet. Ein Beispiel hierfür sind ERP Systeme. Diese halten Daten aktueller Geschäftsvorfälle. Die Datenmodelle sind üblicherweise stark normalisiert und auf eine hohe Transaktionszahl hin optimiert. Derartige Systeme werden auch als online transactional processing, kurz OLTP bezeichnet. An ein Data Warehouse werden andere Anforderungen gestellt. Datenbestände des Data Warehouse müssen historisiert werden, um Zeitreihenanalysen durchzuführen. So können Veränderungen und Entwicklungen geschäftlicher Zusammenhänge erkannt werden. Die Abfragen der Daten sind in der Regel komplexer als in operativen Systemen. Häufig müssen Seite 4 von 141

8 Daten aggregiert werden, um Zusammenhänge auf einer globaleren Ebene zu bewerten können. Gleichzeitig ist die Transaktionszahl wesentlich geringer als in operativen Systemen. Technisch wird das dafür benötigte Datenhaltungskonzept als online analytical processing OLAP bezeichnet. Dem gegenüber steht das Data Warehouse als analytisches System. Diese Rahmenbedingungen machen andere technische Maßnahmen erforderlich, als diese bei operativen Systemen in Frage kommen. Hierzu gehören Datenbankschemata sowie Speichermodelle, die auf den analytischen Zweck des Data Warehouse hin optimiert sind. Die multidimensionalen Schemata werden im Anschluss vorgestellt, die Speichermodelle im darauf folgenden Abschnitt. Multidimensionale Schemata für das Data Warehouse In einem Data Warehouse werden Daten häufig in einem multidimensionalen Schema gespeichert (Chamoni, et al., 2006 S. 177). Da häufig relationale Datenbanken als technische Grundlage des Data Warehouse genutzt werden, muss der multidimensionale Charakter der Daten auf zweidimensionale, relationale Tabellen abbildet werden (Bauer, et al., 2004 S. 57). Typisch sind hierfür das Star-, Snowflake- und Galaxy-Schema. Alle multidimensionalen Schemata organisieren Daten in Fakten und Dimensionen. Fakten repräsentieren dabei die zu analysierenden Kennzahlen. Es handelt sich dabei üblicherweise um numerische Werte. Dimensionen repräsentieren die Auswertungsbereiche von Fakten. Dabei können Dimensionen hierarchisch strukturiert sein. Die Hierarchie stellt dabei einen Aggregationspfad einer Dimension dar. Entsprechend sind Fakten die quantifizierenden, Dimensionen die qualifizierenden Elemente eines multidimensionalen Schemas (Kimball, 1996 S. 10 ff.). Als Beispiel seien Umsatzdaten eines Unternehmens mit mehreren Produkten und Filialen herangezogen. Die Fakten sind Umsätze, die Dimensionen, nach denen diese Umsätze ausgewertet werden, sind Produkt, Filiale und Zeit. Hieraus ergibt sich ein einfaches multidimensionales Schema, das sogenannte Star-Schema: Abbildung 1: Star-Schema Seite 5 von 141

9 Hauptcharakteristikum von multidimensionalen Schemata ist, dass die Werte der Faktentabelle über Fremdschlüsselbeziehungen Dimensionstabellen zugeordnet sind. Beim Star-Schema wird die gesamte Dimensionshierarchie in einer Dimensionstabelle abgebildet. Dadurch ist ein Star- Schema denormalisiert. Das Snowflake-Schema unterscheidet sich vom Star-Schema durch die Struktur der Dimensionshierarchien. Jede Hierarchieebene wird in einer eigenen Dimensionstabelle abgebildet, die Hierarchie zwischen den Dimensionstabellen verschiedener Ebenen wird über Fremdschlüsselattribute realisiert. Folgende Abbildung zeigt ein einfaches Snowflake-Schema. Abbildung 2: Snowflake-Schema Ein Snowflake-Schema ist ein normalisiertes Star-Schema. Durch Denormalisierung der Dimensionstabellen kann ein Snowflake-Schema in ein Star-Schema überführt werden. Die Normalisierung beim Snowflake-Schema reduziert den Speicherbedarf. Außerdem wird die Wartung vereinfacht. Allerdings erfordern Abfragen mehr Joinoperationen, wodurch die Performance negativ beeinflusst werden kann. (Vassiliadis, 1998) Das Galaxy-Schema weist im Gegensatz zu Star- und Snowflake-Schema mehrere Faktentabellen auf, die über gemeinsame Dimensionstabellen qualifiziert werden. Wie beim Star-Schema sind die Dimensionstabellen dabei denormalisiert. Dim_Filiale Dim_Verkäufer Verkäufer_ID Verkäufer_Name Fact_Umsatz Produkt_ID Filiale_ID Tag Verkäufer_ID Umsatz Filiale_ID Filiale_Name Filiale_Ort Dim_Produkt Produkt_ID ProduktName Fact_Inventar Produkt_ID Filiale_ID Tag Menge Dim_Tag Tag Monat Jahr Abbildung 3: Galaxy-Schema Seite 6 von 141

10 Das Galaxy-Schema eignet sich dazu, auch sehr komplexe Unternehmenszusammenhänge darzustellen. Daraus ergibt sich jedoch eine hohe Komplexität des Schemas, was die Implementierung und Wartung erschwert. Speichermodelle für multidimensionale Daten Im Data Warehouse Kontext kommen verschiedene Speichermodelle zur Speicherung multidimensionaler Daten in Frage. Eine verbreitete Speicherform ist relationales online analytical processing, kurz ROLAP. Bei ROLAP dient eine relationale Datenbank als Grundlage. Die Daten werden auf der Datenbank in den bereits vorgestellten multidimensionalen Schemata Star- Snowflake- oder Galaxy-Schema gespeichert. Dadurch findet eine Abbildung multidimensionaler Daten auf zweidimensionale, relationale Tabellen statt. Zugriff auf ROLAP gespeicherte Daten erfolgt mittels der bekannten Abfragesprache SQL. Standard SQL ist zur multidimensionalen Analyse nur bedingt geeignet, aus diesem Grund sind SQL-Erweiterungen entwickelt worden, wie zum Beispiel der ROLLUP-Operator (Kurz, 1999 S. 365). Über ROLAP hinaus gibt es weitere Speichermodelle, von denen insbesondere zwei relevant sind: MOLAP - multidimensionales online analytical processing HOLAP - hybrides online analytical processing. Dies stellt eine Mischform aus den Speichermodellen ROLAP und MOLAP dar. MOLAP Wird MOLAP eingesetzt, werden die Daten des Data Warehouse in einer multidimensionalen Datenbank gehalten. Physikalisch werden dabei Daten häufig in Arrays gespeichert (Chamoni, et al., 2006 S. 155). Die Daten werden logisch in Datenwürfeln, sogenannten Cubes, organisiert. Da die Speicherstrukturen eines Cubes für multidimensionale Anfragen optimiert sind, ergeben sich bei kleineren Datenmengen wesentliche Performancevorteile gegenüber anderen Speichermodellen. Dies gilt insbesondere dann, wenn Cubes vollständig im Hauptspeicher gehalten werden. Zur Performancesteigerung trägt zusätzlich die Voraggregation bei. MOLAP bringt als Speichermodell jedoch auch Nachteile gegenüber anderen Modellen, insbesondere ROLAP, mit sich. Multidimensionale Datenbanken sind in der Regel herstellerspezifisch. Es hat sich bis heute kein Standard durchsetzen können. Ein Ansatz sind Multidimensional Expressions MDX. Diese Abfragesprache weist jedoch noch keine so große Verbreitung auf wie SQL im relationalen Bereich (Rainardi, 2007 S. 395). Ein weiterer Nachteil ist, dass sich große Datenvolumina und insbesondere Cubes mit vielen dünn besetzten Dimensionen negativ auf die Performance auswirken (Kurz, 1999 S. 330). HOLAP HOLAP ist ein Speichermodell, mit dem Hersteller versuchen die Vorteile von ROLAP und MOLAP zu vereinen. Grundlage bildet eine relationale Datenbank, in der Detaildaten mit niedriger Aggregationsstufe sowie historische Daten gespeichert werden. Übergeordnet werden häufig angefragte Daten in einem multidimensionalen Speichermodell gehalten. Dabei werden die multidimensional gespeicherten Datenwürfel in der Regel voraggregiert. Liegt für eine Anfrage kein Datenwürfel vor, werden die Informationen aus dem relationalen Datenbestand generiert. Die multidimensionale Speicherkomponente eines HOLAP Systems führt demnach eine Art Caching auf den Daten durch (Kurz, 1999 S. 331). Kann eine Anfrage auf Seite 7 von 141

11 multidimensional gespeicherte Daten zurückgreifen, gelten die gleichen Vorteile wie beim MOLAP Modell. Durch die ROLAP Basis gelten gleichzeitig nicht die Einschränkungen bezüglich der bearbeitbaren Datenvolumina. Nachteilig sind die Herstellerspezifität und die komplexere Wartung gegenüber ROLAP Systemen. Andere OLAP Formen Andere OLAP Arten wie DOLAP (Desktop OLAP) oder FOLAP (Flatfile OLAP) spielen in Szenarien einer gewissen Größenordnung keine Rolle (Kurz, 1999 S. 322) und werden daher im Rahmen dieser Arbeit nicht betrachtet. 2.2 ETL Prozesse Aufgrund der Heterogenität von transaktional orientierten, operativen Systemen und dem analytisch ausgerichteten Data Warehouse werden beide Systeme physikalisch getrennt voneinander bereitgestellt. Die Übertragung von Daten aus operativen Quellen in das Data Warehouse findet üblicherweise periodisch statt. Dabei werden große Datenmengen aus den Quellsystemen extrahiert, den Anforderungen des Data Warehouse entsprechend verarbeitet und anschließend in das Data Warehouse geschrieben. Dieser Prozess wird als Extract, Transform, Load - ETL bezeichnet. ETL Prozesse spielen nicht nur in Data Warehouse Szenarien eine Rolle, sondern überall dort, wo Daten zwischen verschiedenen Datenhaltungssystemen übertragen und dabei an neue Anforderungen angepasst werden müssen. Es lassen sich folglich nahezu beliebige Datenintegrationsszenarien durch ETL Prozesse abbilden. Diese Arbeit betrachtet ETL Prozesse jedoch im Data Warehouse Kontext. Während der Extraktion werden Daten aus Quellsystemen gelesen und in einen Arbeitsbereich übertragen. Bereits während der Extraktion werden nur die relevanten Daten selektiert. Anschließend werden die extrahierten Daten in der Transformationsphase verarbeitet. Dabei werden Daten vereinheitlicht, bereinigt und harmonisiert. Die Transformationsphase erfordert regelmäßig den größten Aufwand bei Erstellung und Durchführung von ETL Prozessen (Kurz, 1999 S. 267 ff.). Besondere Herausforderungen ergeben sich dabei bei der Behandlung der Datenqualität. Nach der Transformation werden die Daten während der Ladephase in das Zielsystem, zum Beispiel ein Data Warehouse, geschrieben. Grundsätzlich können ETL Prozesse entweder individuell programmiert oder mit Hilfe von Werkzeugen entwickelt und durchgeführt werden. Durch die hohe Komplexität von ETL Prozessen ist der Einsatz eines Werkzeugs in den meisten Fällen sehr empfehlenswert (Kimball, et al., 2004 S. 10), (Kurz, 1999 S. 268). Im Rahmen dieser Arbeit wird von der Entwicklung eines ETL Werkzeugs ausgegangen. Trotz der Unterschiede zwischen verschiedenen ETL Werkzeugen, bleiben die Grundprinzipien gleich. Die in dieser Arbeit beschriebenen Vorgehensweisen basieren auf diesen Grundprinzipen, wodurch dem Entwickler die freie Wahl für ein ETL Werkzeug obliegt. ETL Prozesse können auf zwei unterschiedlichen Ebenen betrachtet werden. Seite 8 von 141

12 Auf der unteren Ebene bestehen ETL Prozesse aus Mappings. Der Begriff Mapping wird von vielen ETL Werkzeugen 1 und vom IEEE verwendet (Dessloch, et al., 2008). Ein Mapping bildet Datenquelle auf Datenziele ab. Dabei werden alle ETL Phasen durchgeführt. Datenquellen werden extrahiert, die extrahierten Daten gemäß den definierten Anforderungen transformiert und anschließend in Datenziele geladen. Ein Mapping besteht aus mindestens einer Datenquelle, beliebig vielen Transformationen und mindestens einem Datenziel. Der Mappingebene übergeordnet ist die Workflowebene. Ein Workflow kapselt dabei ein oder mehrere Mappings zu einer ausführbaren Einheit. Durch Workflows wird die Ablaufreihenfolge und -koordination zwischen Mappings definiert. Da die einzelnen Aspekte von ETL Prozessen und deren Entwicklung im Rahmen des Vorgehensmodells intensiv behandelt werden, soll an dieser Stelle eine kurze Einführung genügen. 2.3 Business Intelligence Szenarien Data Warehouses sind die Grundlage vieler Business Intelligence Anwendungen. Obwohl der Fokus dieser Arbeit auf der ETL Entwicklung im Data Warehouse Kontext liegt und daher keine Frontendanwendungen betrachtet werden, sind zum weiteren Verständnis Kenntnisse der wesentlichen Szenarien notwendig. Geschäftsberichte Eine häufige Anforderung sind Geschäftsberichte. In einem Geschäftsbericht werden Daten thematisch zusammengefasst und ausgewertet. Ein Geschäftsbericht wird in einem einheitlichen Template dargestellt. Häufig werden Geschäftsberichte in Form von HTML Dokumenten erstellt. Geschäftsberichte setzten in der Regel eine integrierte Datenbasis voraus, da Daten aus unterschiedlichen Systemen und Fachbereichen miteinander in Verbindung gebracht werden (Gluchowski, et al., 2008 S. 205 ff.). Performance Management Gerade im Management und für Top-Entscheider bieten Dashboards oder sogenannte Scorecards eine geeignete Möglichkeit, einen schnellen Überblick über wichtige Unternehmenskennzahlen zu gewinnen. Neben der Überwachung der Unternehmensleistung unterstützen Performance Management Werkzeuge das Treffen von strategischen und taktischen Entscheidungen (Kurz, 1999 S. 638 ff.). OLAP Online Analytical Processing dient der interaktiven Analyse von Unternehmensdaten. Hierbei können Daten anhand verschiedener Abfragedimensionen und in unterschiedlichen Aggregationsebenen untersucht werden. Grundlage von OLAP Analysen ist der sogenannte OLAP Cube, also ein Datenwürfel. Ein Cube hält Daten kategorisiert nach Fakten und Dimensionen. Fakten sind dabei numerische Werte, die bestimmte Sachverhalte in einem Unternehmen darstellen. Dimensionen sind Textwerte, nach denen die Fakten kategorisiert werden (Getz, 2007). Abbildung 4 auf der folgenden Seite zeigt einen OLAP Cube 1 Zum Beispiel Informatica Powercenter, Oracle Warehouse Builder, Microsoft SSIS Seite 9 von 141

13 Abbildung 4: OLAP Cube (Gluchowski, et al., 2008 S. 156) In OLAP Anwendungen sind spezielle Operationen auf dem OLAP Cube möglich, durch die die Analysemöglichkeiten vergrößert werden. Da dies jedoch nicht Inhalt dieser Arbeit ist sei auf weiterführende Literatur verwiesen. 2 Data Mining Data Mining dient dazu, Muster und Beziehungen in großen Datenmengen aufzudecken. Hierzu kommen statistische Methoden und Suchalgorithmen zum Einsatz. Durch Data Mining sind komplexe Analysen möglich, die Zusammenhänge aufzeigen, die mittels einfacher Analysen nicht festzustellen sind. Insbesondere in der strategischen Planung hat Data Mining eine hohe Relevanz. Alle genannten Verfahren sind dem Bereich Business Intelligence zuzuordnen. Ihre Datenbasis bildet in der Regel ein unternehmensweites Data Warehouse, das eventuell in einzelne Data Marts aufgeteilt wird. In der Praxis werden häufig mehrere oder sogar alle Verfahren parallel eingesetzt. Die Auflistung typischer Szenarien dient an dieser Stelle nicht als vollständige Übersicht. Weitere Szenarien sind durchaus denkbar, überschreiten aber den Rahmen dieser Arbeit. 2 Vertiefende Informationen zu Operationen auf OLAP Cubes finden sich unter anderem in: (Kurz, 1999 S. 334 ff.) und (Bauer, et al., 2004 S. 181 ff.) Seite 10 von 141

14 2.4 Data Warehouse Referenzarchitektur Data Warehouse Systeme können anhand einer Referenzarchitektur entwickelt werden. Da zum weiteren Verständnis der Arbeit Kenntnis der Referenzarchitektur und ihrer Komponenten vorausgesetzt wird, wird diese nachfolgend vorgestellt. Zusätzlich dient die Vorstellung der Referenzarchitektur der Einführung einer einheitlichen Terminologie. Die Referenzarchitektur besteht aus 5 Schichten. Diese unterteilen sich in: 1. Quellenschicht 2. Staging Area 3. Basisdatenbank 4. Data Warehouse und Data Marts 5. Frontend. Folgende Abbildung stellt die Referenzarchitektur eines Data Warehouse Systems schematisch dar: Datenquellen Staging Area Basisdatenbank Data Warehouse und Data Marts Frontend Legende Datenfluss Datenquelle (relational) Data Mart OLAP Datenzugriff Datenquelle (Flatfiles) ETL ETL ETL Staging Area Basisdatenbank Data Warehouse Reporting Datenquelle (ERP) Data Mart Datenquelle ( ) Data Mining Operative Anwendung ETL Server Repository / Metadaten Abbildung 5: Data Warehouse Referenzarchitektur Datenquellen Datenquellen sind beispielsweise operative Systeme. In ihnen werden Daten der anfallenden geschäftlichen Vorgänge gehalten. Datenquellen können unterschiedlichen Typs sein. Häufig sind Dateien, proprietäre Systeme und relationale Datenbanken. Datenbanken operativer Systeme sind transaktionsorientiert organisiert. Eine Herausforderung bei der Einführung von Data Warehouse Systemen ist die Heterogenität der Datenquellen. Bei der Entwicklung eines Data Warehouse Systems muss die Verfügbarkeit der Quellen berücksichtigt werden. Insbesondere bei Daten, die aus unternehmensexternen Quellen bezogen werden, wie zum Beispiel Wechsel- oder Börsenkurse. Nichtelektronische Datenquellen, die eventuell ebenfalls relevant sind, können nicht automatisch in einer Data Warehouse Architektur verarbeitet werden. Diese müssen zuerst digitalisiert werden. Seite 11 von 141

15 Aus den Quellen werden Daten durch ETL Prozesse extrahiert und in die Staging Area geladen. Staging Area Die Staging Area ist ein Arbeitsbereich, in dem Daten zwischengespeichert werden. Bei der Extraktion von Daten in die Staging Area finden noch keine Transformationen statt. Anschließend werden die in die Staging Area extrahierten Daten vor der Überführung in nachgelagerte Systeme verarbeitet und aufbereitet. Durch die Extraktionskomponente des ETL Servers werden die Daten in die Staging Area transportiert. Die Extraktion von Daten in die Staging Area findet üblicherweise periodisch statt. In welchen Intervallen die Extraktion durchgeführt wird, hängt von den Anforderungen an die Aktualität der Daten im Data Warehouse und den Zeitfenstern, in denen auf die Quellsysteme zugegriffen werden kann ab. Die Transformation der Daten durch den ETL Server findet auf Daten in der Staging Area statt. Eine wesentliche Aufgabe ist dabei die Datenbereinigung. Die Daten werden in der Staging Area temporär gespeichert. Nachdem die Daten in ein nachgelagertes System geladen wurden, können sie aus der Staging Area entfernt werden. Nur Administratoren und ETL Prozesse haben Zugriff auf die Staging Area. Dadurch wird die Konsistenz der Daten gewährleistet. Zweck dieses separaten Arbeitsbereichs ist es, die Datenquellen und die nachgelagerten Speicher wie die Basisdatenbank zu entlasten. Dies ist insbesondere dann notwendig, wenn große Datenmengen verarbeitet oder komplexe Transformationen durchgeführt werden müssen (Inmon, 2005 S. 168). Basisdatenbank Die Basisdatenbank ist ein Datenspeicher, der zwischen der Staging Area und dem Data Warehouse angesiedelt ist. Sie dient dem Zweck, unternehmensweite, integrierte Daten nachgelagerten Systemen zur Verfügung zu stellen. Die Abgrenzung zur Staging Area liegt im Zustand der Daten. Diese werden in der Basisdatenbank integriert und bereinigt gespeichert. Zum Data Warehouse wird die Basisdatenbank in erster Linie über das Schema abgegrenzt. In der Basisdatenbank werden Daten normalisiert und abfrageneutral gehalten, im Data Warehouse werden Daten dagegen in multidimensionalen Schemata gespeichert. Außerdem werden die Daten in der kleinsten erforderlichen Granularität gespeichert. Je nach Anforderungen werden Daten historisiert. Die Basisdatenbank wird zu dem in der Literatur mit dem Begriff Operational Data Store (ODS) (Inmon, 1999) beschriebenen Konzept über die vollständige Integration der Daten und die optionalen Historisierung abgegrenzt. Beides ist im Konzept des ODS nicht vorgesehen. Später hat Inmon das Konzept des ODS erweitert. Das eingeführte ODS der Klasse zwei erweitert das ursprüngliche ODS der Klasse eins um eine Historisierung (Inmon, 2005 S. 133). Somit entspricht ein ODS der Klasse zwei dem Konzept der Basisdatenbank. Zur Vermeidung nicht eindeutiger Begriffe wird in dieser Arbeit der von Bauer & Günzel eingeführte Begriff der Basisdatenbank verwendet (Bauer, et al., 2004). In einem der Referenzarchitektur entsprechenden Data Warehouse Szenario übernimmt die Basisdatenbank verschiedene Funktionen. Dazu zählen: Sammlung unternehmensweiter, integrierter und bereinigter Daten Versorgung des Data Warehouse mit Daten Bereitstellung bereinigter und integrierter Daten für operative Anwendungen. Seite 12 von 141

16 Data Warehouse Das Data Warehouse bildet die Grundlage für nachgelagerte Analysewerkzeuge. Im Data Warehouse werden Daten vollständig integriert und bereinigt gespeichert. Die Daten werden analyseorientiert vorgehalten. Technisch liegen Data Warehouses in der Regel relationale Datenbanken zugrunde. Seltener kommen multidimensionale Speichermodelle zum Einsatz. Strukturiert werden die Daten in einem multidimensionalen Schema. Die für Analysen benötigten Daten werden durch ETL Prozesse aus der Basisdatenbank extrahiert und in das Data Warehouse geladen. Da bereits die Basisdatenbank integrierte und bereinigte Daten vorhält, müssen die Daten vor dem Laden nur noch in das Zielschema transformiert werden und eventuell aggregiert werden. Wird in einer konkreten Architektur keine Basisdatenbank betrieben, müssen Integration und Bereinigung entsprechend bei der Überführung in das Data Warehouse durchgeführt werden. Data Marts Data Marts sind Teilausschnitte des Data Warehouse. Diese Abschnitte können nach einzelnen Analyseanforderungen oder Organisationseinheiten eingeteilt sein. Oft werden für bestimmte Analysen nicht alle Daten des Data Warehouse benötigt. In diesem Fall kann die Aufteilung in einzelne Data Marts, und damit die Reduktion der einzelnen Datenvolumina und der eingehenden Anfragen, die Performance der Analysewerkzeuge verbessern. Außerdem können Sicherheitoder Datenschutzaspekte eine Verteilung der Daten auf mehrere Data Marts notwendig machen (Bauer, et al., 2004 S. 59). Data Marts können entweder durch Teilkopien des Data Warehouse erstellt und gepflegt werden oder durch den Einsatz materialisierter Sichten auf das Data Warehouse. Werden die Daten kopiert, wird dies im Rahmen von ETL Prozessen durch den ETL Server durchgeführt. Während der ETL Prozesse können die Daten noch entsprechend der Anforderungen des jeweiligen Data Marts transformiert werden. Durch materialisierte Sichten werden Data Marts sozusagen virtuell erzeugt. Die Daten verbleiben im Data Warehouse. Stattdessen werden Abfragen auf das Data Warehouse vorberechnet und gespeichert. Auf die dadurch erzeugte Sicht kann wie auf einen Data Mart mit eigenem Datenbestand zugegriffen werden. Bei Erstellung und Auffrischung der Sichten muss das Data Warehouse die notwendige Rechenleistung zur Verfügung stellen. Frontend Das Frontend einer Data Warehouse Architektur bilden die Analysewerkzeuge, wie sie in den Business Intelligence Szenarien vorgestellt wurden. Je nach Anwendungsfall können Frontendapplikationen mehr oder weniger aufwendig ausfallen. Werden beispielsweise OLAP Analysen durchgeführt, muss die Frontendkomponente aus den Daten des Data Warehouses sogenannte Datenwürfel (Cubes) erstellen. Dies erfordert sehr leistungsfähige Systeme. Auch Data Mining, bei dem komplexe Algorithmen und aufwendige statistische Verfahren eingesetzt werden, erfordern hohe Leistung. Standardreporting ist generell weniger aufwendig und erfordert daher in der Regel keine besondere Beachtung bei der Auswahl der Frontendsysteme. ETL Server Der ETL Server ist keiner einzelnen Schicht zuzuordnen, sondern kommt immer bei den Transitionen zwischen Schichten zum Einsatz. Beim Transport der Daten zwischen den einzelnen Schichten der Data Warehouse Architektur führt der ETL Server die notwendigen Schritte Extraktion, Transformation und Laden durch. Grundsätzlich kann dies auch mit individuell entwickelten Lösungen durchgeführt werden. Allerdings ergeben sich insbesondere durch die Seite 13 von 141

17 Heterogenität der Quellsysteme dabei große Risiken. Neben der ETL Engine zur Ausführung der ETL Prozesse und den zur Verfügung stehenden Extraktions- und Ladekomponenten für viele verschiedene Quell- und Zieltypen bieten ETL Server häufig auch eine integrierte Entwicklungsumgebung, die bei Design und Implementierung von ETL Prozessen sehr hilfreich ist. Eine weitere Aufgabe des ETL Servers ist die Verwaltung von Metadaten. Metadaten speichern zum einem Schemainformationen der verschiedenen Datenzeile, zum anderen Beschreibungen von Daten und Datenquellen zu Dokumentationszwecken. Darüber hinaus werden Transformationsregeln in Form von Metadaten gespeichert. Speicherort der Metadaten ist das sogenannte Repository. Im Rahmen dieser Arbeit wird von der Verwendung eines ETL Werkzeugs mit Server und Entwicklungskomponente ausgegangen. 2.5 Vorgehensmodelle in der Informatik Vorgehensmodelle in der Informatik sind Beschreibungen systematischer Vorgehensweisen zur Entwicklung von Softwaresystemen. Aufgrund der Komplexität von Softwareentwicklungsprojekten ist vor Beginn der eigentlichen Entwicklung eine genaue Planung erforderlich. Bei der Planung müssen verschiedene Aspekte berücksichtigt werden. Hierzu zählen insbesondere Anforderungen an das zu entwickelnde Produkt sowie finanzielle, zeitliche und personelle Restriktionen. Da jedes Projekt im Detail einmalig ist, erfordert jedes Projekt eine erneute Planung. Hierdurch ergeben sich in jedem Projekt große Planungsrisiken. Um die Risiken trotz der Einmaligkeit von Projekten erfolgreich bewältigen zu können, werden standardisierte Vorgehensweisen angestrebt. Dies führt zu einer Effizienzverbesserung der Planung und Entwicklung, Risiken werden früher und detaillierter erkannt und damit leichter vermieden. Vorgehensmodelle sind möglichst generische Schablonen zur Planung und Durchführung von Projekten. Dies trägt zur geforderten Standardisierung bei. Ein Vorgehensmodell muss mehrere Anforderungen erfüllen. Die Anforderungen stellen gleichzeitig Qualitätsmerkmale zur Bewertung eines Vorgehensmodells dar. Anforderungen an Vorgehensmodelle An Vorgehensmodelle werden verschiedene Anforderungen gestellt. Nach (Bunse, et al., 2002) sind insbesondere sechs Kriterien relevant. Vollständigkeit Das Vorgehensmodell beschreibt, für den jeweiligen Anwendungskontext alle Phasen des Entwicklungsprozesses und bindet die Stützprozesse Projektmanagement, Konfigurationsmanagement und Qualitätsmanagement mit ein. Systematik Es wird ein einheitliches Vokabular konsistent verwendet. Durch die klar definierte Begriffswelt wird die Kommunikation zwischen Projektbeteiligten vereinfacht. Modularität Das Vorgehensmodell ist durch eine Unterteilung in überschaubare Einheiten von Phasen und Aufgaben als Schablone für die Planung verwendbar. Durch wohldefinierte Vorgaben und Ergebnisse wird die Erfolgskontrolle im Projekt erleichtert beziehungsweise ermöglicht. Seite 14 von 141

18 Allgemeingültigkeit Das Vorgehensmodell ist unabhängig von konkreten Anwendungsszenarien und Produkten. Es ist geeignet, Projekte unterschiedlicher Größe und Komplexität abzubilden. Anpassbarkeit Das Vorgehensmodell lässt sich an technische oder organisationsspezifische Besonderheiten und Anforderungen anpassen. Werkzeugunterstützung Für die einzelnen Aktivitäten des Vorgehensmodells gibt es geeignete Werkzeuge. Dabei sind sowohl die Stützprozesse als auch die Aktivitäten des Entwicklungsprozesses zu berücksichtigen. Typische Werkzeuge zur Unterstützung des Entwicklungsprozesses sind Entwicklungsumgebungen, in denen Programmteile erstellt werden. Häufig integrieren Entwicklungsumgebungen Werkzeuge zur Durchführung der Stützprozesse. Insbesondere Qualitätssicherungswerkzeuge, zum Beispiel Testsuiten und Versionierungswerkzeuge als Bestandteile des Konfigurationsmanagements, haben sich hierbei durchgesetzt. Angemessene Komplexität Zusätzlich zu den von (Bunse, et al., 2002) definierten Kriterien lässt sich ein weiteres ableiten. Eine dem Anwendungszweck und der Zielgruppe angemessene Komplexität. Das Vorgehensmodell macht durch Erfüllung der anderen sechs Kriterien den Entwicklungsprozess und die damit verbundenen Risiken beherrschbar. Gleichzeitig trägt das Vorgehensmodell selbst so wenig wie möglich zur Komplexität der Projektdurchführung bei. Im Vergleich gibt es in der klassischen Softwareentwicklung wesentlich mehr Literatur die sich mit Methodik und Vorgehensweise befasst als im ETL Kontext. Daraus kann für das ETL Umfeld auf eine tendenziell geringere Erfahrung mit Vorgehensmodellen geschlossen werden. Dies macht ein einfach zugängliches Vorgehensmodell als Grundlage einer erfolgreichen Projektdurchführung erforderlich. Anspruch an das entwickelte Vorgehensmodell ist es, diesen sieben Kriterien zu genügen. Im Abschluss der Arbeit wird dieser Anspruch überprüft und das Vorgehensmodell anhand der Kriterien bewertet. Familien von Vorgehensmodellen Durch gemeinsame Eigenschaften lassen sich Vorgehensmodelle nach (Bunse, et al., 2002) in drei Familien einordnen. 1. Phasenmodelle: Wasserfall- und Schleifenmodell 2. Prototypische Vorgehensmodelle 3. Verbesserungsmodelle: Inkrementelle, iterative, evolutionäre und rekursive Vorgehensmodelle Je nach Projektaufgabe sind Vertreter verschiedener Familien besser oder weniger gut geeignet. Bevor das in dieser Arbeit entwickelte Modell eingeordnet wird, werden kurz die Charakteristika der unterschiedlichen Familien dargestellt. Seite 15 von 141

19 Phasenmodelle: Stagewise-, Wasserfall- und Schleifenmodell Die ersten Vorgehensmodelle der Softwaretechnik waren Phasenmodelle. Der erste Vertreter dieser Familie ist das Stagewise Model, das (Benington, 1956) veröffentlichte. Das Modell legt eine stufenweise, sukzessive Softwareentwicklung fest. Das in (Royce, 1970) vorgestellte Wasserfall-Modell erweitert das Stagewise Modell um Rückschritte, die zwischen aufeinander folgenden Phasen ermöglicht werden. Als Wasserfall-Modell benannt wurde es erstmals in (Boehm, 1981). Das wesentliche Charakteristikum von Phasenmodellen ist, dass die durchzuführenden Aktivitäten auf einzelne Phasen verteilt werden. Die Phasen werden sequentiell, das heißt nacheinander in der definierten Reihenfolge, durchgeführt. Verschiedene Phasenmodelle unterscheiden sich hauptsächlich dadurch, ob und wenn ja wie Rückschritte zwischen Phasen möglich sind. Rückschritte zwischen Phasen werden als Iterationen bezeichnet. Zu unterscheiden sind dabei drei Fälle: 1) Keine Iterationen zwischen Phasen erlaubt. 2) Iterationen zwischen direkt aufeinander folgenden Phasen möglich. 3) Beliebige Iterationen auch zu weiter zurückliegenden Phasen möglich. Phasenmodelle setzten grundsätzlich voraus, dass vor Beginn einer Phase die Vorgängerphase abgeschlossen ist. Wenn Rückschritte vorgesehen sind, dann nur, um Fehler zu korrigieren oder neue Anforderungen zu berücksichtigen. Der sequentielle Charakter von Phasenmodellen macht diese relativ unflexibel. Gleichzeitig wird hierdurch jedoch ein hohes Maß an Struktur vorgegeben, dass die Planbarkeit verbessert. Phasenmodelle eignen sich insbesondere dann, wenn die zu erstellenden Artefakte in hohem Maße voneinander abhängen beziehungsweise aufeinander aufbauen. Prototypische Vorgehensmodelle Prototypische Vorgehensmodelle sehen vor, dass einzelne Phasen nicht sequentiell, sondern wiederholt durchlaufen werden. Zur Evaluierung von Anforderungen und Entwurf werden Prototypen erstellt. Anhand der Prototypen werden Erfahrungen gesammelt, die in die Wiederholung einer Phase einfließen. Die Entwicklung von Prototypen verringert das Risiko von Fehlentwicklungen, da das Ergebnis vor Fertigstellung evaluiert und diskutiert werden kann. Die Erstellung von Prototypen ist jedoch mit hohem Aufwand verbunden. In manchen Projekten kann es darüber hinaus unmöglich sein, einen aussagekräftigen Prototyp mit vertretbarem Aufwand zu erstellen. Ein weiteres großes Risiko ist, dass Prototypen beziehungsweise Teile davon in den Produktivbetrieb übernommen werden (Balzert, 1998 S. 119). Verbesserungsmodelle Bei Vorgehensmodellen dieser Familie werden Anforderungen in Teilmengen partitioniert. Die Teilmengen durchlaufen dann unabhängig voneinander den gesamten Entwicklungsprozess. Eine fertiggestellte Teilmenge der Anforderungen wird als Inkrement bezeichnet. Anschließend wird durch Erstellung weiterer Inkremente das Produkt verbessert beziehungsweise erweitert. Verbesserungsmodelle eignen sich durch das inkrementelle Vorgehen gut dazu, Projekte, deren Anforderungen zu Projektbeginn teilweise unklar sind, durchzuführen. Bei der Anwendung werden zunächst Inkremente der Anforderungsteile, die sich eindeutig definieren lassen, erstellt. Im weiteren Projektverlauf werden dann die unklaren Bestandteile definiert. Die Integration der verschiedenen Inkremente kann sich in der Praxis als schwierig herausstellen. Der wesentliche Seite 16 von 141

20 Faktor ist, wie gut sich Anforderungen unterteilen lassen und welche Abhängigkeiten zwischen den einzelnen Teilanforderungen bestehen (Balzert, 1998 S. 121). 2.6 Übersicht über aktuelle Vorgehensmodelle Die folgende Übersicht über wichtige, aktuelle Vorgehensmodelle dient dazu, die verschiedenen Ansätze darzustellen. Jedes Modell wird nach einer kurzen Erklärung der wesentlichen Prinzipen bewertet. Hierbei werden Vor- und Nachteile der einzelnen Modelle aufgeführt. Bewertungsgrundlage sind dabei zum einen die genannten Anforderungen an Vorgehensmodelle, zum anderen die Eignung zur Übertragung in den ETL Kontext. Das im Rahmen dieser Arbeit entwickelte Vorgehensmodell greift verschiedene Prinzipien vorhandener Vorgehensmodelle auf und strukturiert diese für die spezifischen Anforderungen der ETL Entwicklung in Data Warehouse Projekten neu. Die nachfolgend vermittelten Grundlagen ermöglichen dabei die Einordung des entwickelten Vorgehensmodells in den aktuellen Stand der Softwaretechnik Wasserfallmodell Das Wasserfallmodell sieht eine sequentielle Softwareentwicklung vor. Jede Phase muss vor Eintritt in die nächste Phase vollständig abgeschlossen sein. Iterationen sind nur zwischen direkt aufeinander folgenden Phasen möglich. Das Wasserfallmodell orientiert sich am top-down Vorgehen. Ergebnis jeder Phase ist ein Dokument, daher wird das Wasserfallmodell auch dokumenten-getriebenes Modell genannt (Balzert, 1998 S. 100). Folgende Abbildung stellt das Wasserfallmodell dar. Abbildung 6: Wasserfallmodell Bewertung des Wasserfallmodells Nach (Balzert, 1998) lassen sich einige Vor- und Nachteile des Wasserfallmodells erkennen. Vorteilhaft ist, dass das Modell einfach und verständlich ist. Es erzeugt nur einen geringen Managementaufwand. Durch die Vorab-Planung jeder Phase gibt es einen strikten Rahmen zur Projektdurchführung. So entsteht ein sichtbarer und nachvollziehbarer Prozessablauf. Die Vorteile haben zu einer hohen Anerkennung und Verbreitung des Wasserfallmodells geführt. Dieser hohe Bekanntheitsgrad kann ebenfalls als Vorteil angesehen werden. Das Wasserfallmodell hat jedoch auch Nachteile. An erster Stelle steht hier die mangelnde Flexibilität. In Softwareentwicklungsprojekten ist es nicht immer sinnvoll, Phasen vollständig und sequentiell durchzuführen. Teilaspekt der geringen Flexibilität ist die nur schwache Seite 17 von 141