Entwicklung eines ETL Vorgehensmodells für Data Warehouse Projekte

Größe: px
Ab Seite anzeigen:

Download "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

Einführungsveranstaltung: Data Warehouse

Einführungsveranstaltung: Data Warehouse Einführungsveranstaltung: 1 Anwendungsbeispiele Berichtswesen Analyse Planung Forecasting/Prognose Darstellung/Analyse von Zeitreihen Performancevergleiche (z.b. zwischen Organisationseinheiten) Monitoring

Mehr

OLAP und Data Warehouses

OLAP und Data Warehouses OLP und Data Warehouses Überblick Monitoring & dministration Externe Quellen Operative Datenbanken Extraktion Transformation Laden Metadaten- Repository Data Warehouse OLP-Server nalyse Query/Reporting

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

MIS by Franziska Täschler, Winformation GmbH ftaeschler@winformation-gmbh.ch Ausgabe 01/2001

MIS by Franziska Täschler, Winformation GmbH ftaeschler@winformation-gmbh.ch Ausgabe 01/2001 MIS Glossar by Franziska Täschler, Winformation GmbH ftaeschler@winformation-gmbh.ch Ausgabe 01/2001 Aggregat Data Cube Data Marts Data Mining Data Warehouse (DWH) Daten Decision Support Systeme (DSS)

Mehr

Data Warehouse Technologien

Data Warehouse Technologien mitp Professional Data Warehouse Technologien von Veit Köppen, Gunter Saake, Kai-Uwe Sattler 2. Auflage 2014 Data Warehouse Technologien Köppen / Saake / Sattler schnell und portofrei erhältlich bei beck-shop.de

Mehr

Einführung in OLAP und Business Analysis. Gunther Popp dc soft GmbH

Einführung in OLAP und Business Analysis. Gunther Popp dc soft GmbH Einführung in OLAP und Business Analysis Gunther Popp dc soft GmbH Überblick Wozu Business Analysis mit OLAP? OLAP Grundlagen Endlich... Technischer Background Microsoft SQL 7 & OLAP Services Folie 2 -

Mehr

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

SOFTWARETECHNIK. Kapitel 7 Vorgehensmodelle. Vorlesung im Wintersemester 2012/13 FG System- und Software-Engineering Prof. Dr.-Ing.

SOFTWARETECHNIK. Kapitel 7 Vorgehensmodelle. Vorlesung im Wintersemester 2012/13 FG System- und Software-Engineering Prof. Dr.-Ing. SOFTWARETECHNIK Kapitel 7 Vorgehensmodelle Vorlesung im Wintersemester 2012/13 FG System- und Software-Engineering Prof. Dr.-Ing. Armin Zimmermann Inhalt Vorgehensmodelle Sequenzielle Modelle Iterative

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

Projektmanagement: Prozessmodelle

Projektmanagement: Prozessmodelle Projektmanagement: Prozessmodelle Martin Wirsing Institut für Informatik Ludwig-Maximilians-Universität München WS 2006/07 Ziele Wichtige Prozessparadigmen und Vorgehensmodelle wiederholen und in Zusammenhang

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

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

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

Komponenten und Architekturen von Analytischen Informationssystemen (AIS)

Komponenten und Architekturen von Analytischen Informationssystemen (AIS) Komponenten und Architekturen von Analytischen Informationssystemen (AIS) Melanie Pfoh Konsultation 27. Juni 2013 Hinweis Diese Folien ersetzen keinesfalls den Übungsstoff des zugehörigen e-learning-kurses.

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

Projektmanagement. Dokument V 1.1. Oliver Lietz - Projektmanagement. Wie kommt es zu einem Projektauftrag? Ausführung

Projektmanagement. Dokument V 1.1. Oliver Lietz - Projektmanagement. Wie kommt es zu einem Projektauftrag? Ausführung Projektmanagement Management- und Phasen-Modelle Vom Wasserfall bis Extreme Programming / Scrum Dokument V 1.1 Wie kommt es zu einem Projektauftrag? Auftraggeber Projekt-Idee / Ziele [Anforderungen/Spezifikation/

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

3. Vorgehensmodelle Software Engineering. Prof. Dr. Bernhard Humm Hochschule Darmstadt, 23. Oktober 2006

3. Vorgehensmodelle Software Engineering. Prof. Dr. Bernhard Humm Hochschule Darmstadt, 23. Oktober 2006 3. Vorgehensmodelle Software Engineering Prof. Dr. Bernhard Humm Hochschule Darmstadt, 23. Oktober 2006 Agenda Agenda Übersicht V-Modell Rational Unified Process Extreme Programming Fazit, Literatur, Kontrollfragen

Mehr

1Ralph Schock RM NEO REPORTING

1Ralph Schock RM NEO REPORTING 1Ralph Schock RM NEO REPORTING Bereit für den Erfolg Business Intelligence Lösungen Bessere Entscheidungen Wir wollen alle Mitarbeiter in die Lage versetzen, bessere Entscheidungen schneller zu treffen

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

Business Intelligence im Krankenhaus

Business Intelligence im Krankenhaus Business Intelligence im Krankenhaus Dr. Thomas Lux Holger Raphael IT-Trends in der Medizin 03.September 2008 Essen Gliederung Herausforderungen für das Management im Krankenhaus Business Intelligence

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

Themenblock: Erstellung eines Cube

Themenblock: Erstellung eines Cube Themenblock: Erstellung eines Cube Praktikum: Data Warehousing und Data Mining Einführung relationale Datenbanken Problem Verwaltung großer Mengen von Daten Idee Speicherung der Daten in Form von Tabellen

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

The Rational Unified Process. Eine Einführung von T. Langer und A. Nitert

The Rational Unified Process. Eine Einführung von T. Langer und A. Nitert The Rational Unified Process Eine Einführung von T. Langer und A. Nitert Übersicht Einleitung Probleme der SW-Entwicklung, Best Practices, Aufgaben Was ist der Rational Unified Process? Struktur des Prozesses

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

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

good. better. outperform.

good. better. outperform. good. better. outperform. Analytic mit Oracle BI relational oder besser multidimensional? 8. Oracle BI & DWH Konferenz, 20.03.2013 Dirk Fleischmann Director Business Intelligence & DWH Business Intelligence

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

Software-Lebenszyklus

Software-Lebenszyklus Software-Lebenszyklus Inhalt Vorgehensmodell/Phasenplan Wasserfallmodell WAS-Beschreibung WIE-Beschreibung Weitere Phasenmodelle: Spiral-Modell, V-Modell, RUP Extreme Programming SW-Qualitätssicherung

Mehr

Systemen - Testen im Softwarelebenszyklus

Systemen - Testen im Softwarelebenszyklus P r a k t I s c h e Entwicklung und Test Testen von Software-Systemen Systemen - Testen im Softwarelebenszyklus Entwickler erstellen ihr System bzw. ihre Software und testen es/sie zur Entwicklungszeit

Mehr

Ganzheitliches IT-Projektmanagement

Ganzheitliches IT-Projektmanagement Ganzheitliches IT-Projektmanagement Kapitel 2 nach dem Buch: Ruf, Walter; Fittkau, Thomas: "Ganzheitliches IT-Projektmanagement" Wissen - Praxis - Anwendungen R. Oldenbourg Verlag München - Wien 2008;

Mehr

Komponenten und Architekturen von Analytischen Informationssystemen (AIS)

Komponenten und Architekturen von Analytischen Informationssystemen (AIS) Komponenten und Architekturen von Analytischen Informationssystemen (AIS) Melanie Pfoh Konsultation Zusammenfassung OPAL 6. Übung Juni 2015 Agenda Hinweise zur Klausur Zusammenfassung OPAL Übungen / Kontrollfragen

Mehr

Agile Analytics Neue Anforderungen an die Systemarchitektur

Agile Analytics Neue Anforderungen an die Systemarchitektur www.immobilienscout24.de Agile Analytics Neue Anforderungen an die Systemarchitektur Kassel 20.03.2013 Thorsten Becker & Bianca Stolz ImmobilienScout24 Teil einer starken Gruppe Scout24 ist der führende

Mehr

V-Methode, RUP, Waterfall oder was?

V-Methode, RUP, Waterfall oder was? 5. Bayerischer IT-Rechtstag am 26. Oktober 2006 auf der SYSTEMS 2006 in München Übersicht über die verschiedenen Vorgehensmodelle Dr. Sarre & Schmidt EDV-Sachverständige, München Öffentlich bestellter

Mehr

Umsetzung der Anforderungen - analytisch

Umsetzung der Anforderungen - analytisch Umsetzung der Anforderungen - analytisch Titel des Lernmoduls: Umsetzung der Anforderungen - analytisch Themengebiet: New Economy Gliederungspunkt im Curriculum: 4.2.5.5 Zum Inhalt: In diesem Modul wird

Mehr

Wie integriert sich BI in den unternehmensweiten Softwareentwicklungsprozess? Nürnberg, 10.11.2009

Wie integriert sich BI in den unternehmensweiten Softwareentwicklungsprozess? Nürnberg, 10.11.2009 Wie integriert sich BI in den unternehmensweiten Softwareentwicklungsprozess? Nürnberg, 10.11.2009 I N H A L T 1. Warum Modelle für Business Intelligence (BI)? 2. Anforderungen von BI an Software- Entwicklungsprozesse

Mehr

Hinweise zur Klausur Zusammenfassung OPAL-Übungen / Kontrollfragen Fragen Vertiefung Modellierung

Hinweise zur Klausur Zusammenfassung OPAL-Übungen / Kontrollfragen Fragen Vertiefung Modellierung Komponenten und Architekturen von Analytischen Informationssystemen (AIS) Melanie Pfoh Konsultation Zusammenfassung OPAL 24. Juni 2014 Agenda Hinweise zur Klausur Zusammenfassung OPAL-Übungen / Kontrollfragen

Mehr

Effizientes Änderungsmanagement in Outsourcing- Projekten

Effizientes Änderungsmanagement in Outsourcing- Projekten Effizientes Änderungsmanagement in Outsourcing- Projekten Dr. Henning Sternkicker Rational Software IBM Deutschland GmbH Sittarder Straße 31 52078 Aachen henning.sternkicker@de.ibm.com Abstract: Es werden

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

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

Die praktische Bedeutung der verschiedenen Vorgehensmodelle in der Software-Entwicklung

Die praktische Bedeutung der verschiedenen Vorgehensmodelle in der Software-Entwicklung Vorgehensmodelle Seite 1/6 Die praktische Bedeutung der verschiedenen Vorgehensmodelle in der Software-Entwicklung Große Softwareprojekte erwecken oft den Eindruck, dass diese chaotische verlaufen. Und

Mehr

Business Intelligence

Business Intelligence Business Intelligence Anwendungssysteme (BIAS) Lösung Aufgabe 1 Übung WS 2012/13 Business Intelligence Erläutern Sie den Begriff Business Intelligence. Gehen Sie bei der Definition von Business Intelligence

Mehr

Datenbanktechnologie für Data-Warehouse-Systeme

Datenbanktechnologie für Data-Warehouse-Systeme Wolfgang Lehner Datenbanktechnologie für Data-Warehouse-Systeme Konzepte und Methoden dpunkt.verlag 1 1.1 1.2 1.3 1.4 1. 5 2 2.1 2.2 2.3 Einleitung 1 Betriebswirtschaftlicher Ursprung des Data Warehousing...

Mehr

Marketing Intelligence Vorstellung der Softwarekomponenten. Josef Kolbitsch Manuela Reinisch

Marketing Intelligence Vorstellung der Softwarekomponenten. Josef Kolbitsch Manuela Reinisch Marketing Intelligence Vorstellung der Softwarekomponenten Josef Kolbitsch Manuela Reinisch Übersicht Übersicht über die Systemlandschaft Übersicht über die Werkzeuge Workshop Systemlandschaft 1/8 Klassische

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

BI Konsolidierung: Anspruch & Wirklichkeit. Jacqueline Bloemen. in Kooperation mit

BI Konsolidierung: Anspruch & Wirklichkeit. Jacqueline Bloemen. in Kooperation mit BI Konsolidierung: Anspruch & Wirklichkeit Jacqueline Bloemen in Kooperation mit Agenda: Anspruch BI Konsolidierung Treiber Was sind die aktuellen Treiber für ein Konsolidierungsvorhaben? Kimball vs. Inmon

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

Softwareentwicklungsprozesse. 18. Oktober 2012

Softwareentwicklungsprozesse. 18. Oktober 2012 Softwareentwicklungsprozesse 18. Oktober 2012 Überblick Was soll ein Softwareentwicklungsprozess leisten? Überblick über Softwareentwicklungsprozesse Welche gibt es? Warum gibt es mehrere? Diskussion:

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

Referent: Alessandro Arrigo AAM1. Professor: Prof. Dr. Heindl. Furtwangen, 2.7.2009

Referent: Alessandro Arrigo AAM1. Professor: Prof. Dr. Heindl. Furtwangen, 2.7.2009 - Entwicklungsprozess - Referent: Alessandro Arrigo AAM1 Professor: Prof. Dr. Heindl Furtwangen, 2.7.2009 Agenda 1. Vorstellung des Autors 2. Das Buch 3. Inhalt des Kapitels 4. Verwendung in anderer Literatur

Mehr

Multidimensionales Datenmodell, Cognos

Multidimensionales Datenmodell, Cognos Data Warehousing (II): Multidimensionales Datenmodell, Cognos Praktikum: Data Warehousing und Mining Praktikum Data Warehousing und Mining, Sommersemester 2010 Vereinfachte Sicht auf die Referenzarchitektur

Mehr

(Titel des Berichts)

(Titel des Berichts) (Titel des Berichts) Praxissemesterbericht von (Vorname Name) aus (Geburtsort) Matrikelnummer Anschrift Telefon HTW Aalen Hochschule für Technik und Wirtschaft Betreuender Professor Abgabetermin Angaben

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

Data Warehousing Grundbegriffe und Problemstellung

Data Warehousing Grundbegriffe und Problemstellung Data Warehousing Grundbegriffe und Problemstellung Dr. Andrea Kennel, Trivadis AG, Glattbrugg, Schweiz Andrea.Kennel@trivadis.com Schlüsselworte Data Warehouse, Cube, Data Mart, Bitmap Index, Star Queries,

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

Vorwort zur zweiten Auflage...V. Vorwort zur ersten Auflage... VIII

Vorwort zur zweiten Auflage...V. Vorwort zur ersten Auflage... VIII Vorwort zur zweiten Auflage...V Vorwort zur ersten Auflage... VIII 1 Management Support Systeme und Business Intelligence Anwendungssysteme zur Unterstützung von Managementaufgaben...1 1.1 Computergestützte

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

Der Projektmanager (nach GPM / IPMA) Fragen zur Selbsteinschätzung und für die Prüfungsvorbereitung. Kapitel B Vorgehensmodelle

Der Projektmanager (nach GPM / IPMA) Fragen zur Selbsteinschätzung und für die Prüfungsvorbereitung. Kapitel B Vorgehensmodelle Der Projektmanager (nach GPM / IPMA) Fragen zur Selbsteinschätzung und für die Prüfungsvorbereitung Kapitel B Vorgehensmodelle Inhaltsverzeichnis 1 B Vorgehensmodell... 3 1.1 Welche Vorgehensmodelle sind

Mehr

OLAP mit dem SQL-Server

OLAP mit dem SQL-Server Hartmut Messerschmidt Kai Schweinsberg OLAP mit dem SQL-Server Eine Einführung in Theorie und Praxis IIIBibliothek V dpunkt.verlag Teil OLAP undder Microsoft SQL-Server 1 1 Theoretische Grundlagen 3 1.1

Mehr

CRM Architektur. New Economy CRM Architektur Page 1

CRM Architektur. New Economy CRM Architektur Page 1 CRM Architektur Titel des Lernmoduls: CRM Architektur Themengebiet: New Economy Gliederungspunkt im Curriculum: 4.2.4.2 Zum Inhalt: Dieses Modul beschreibt mögliche Architekturen von CRM-Systemen. Insbesondere

Mehr

Einführung in die SWE

Einführung in die SWE Einführung in die SWE Inhalte der Vorlesung Allgemeine Ziele der Lehrveranstaltung Entwickeln einer kleinen Applikation nach professionellem Vorgehensmodell Erlernen des objektorientierten Herangehens

Mehr

Zusammenspiel von Business Intelligence mit betrieblicher Anwendungssoftware Falk Neubert, Universität Osnabrück

Zusammenspiel von Business Intelligence mit betrieblicher Anwendungssoftware Falk Neubert, Universität Osnabrück Zusammenspiel von Business Intelligence mit betrieblicher Anwendungssoftware 14. März 2013, IHK Osnabrück-Emsland-Grafschaft Bentheim Geschichte Kassenbuch des Liederkranz, 1886 Hutmachergesangvereins

Mehr

SAP BI Business Information

SAP BI Business Information Aus der Praxis für die Praxis. SAP BI Business Information Thomas Wieland Berlin, 24. November 2006 SAP BW Architektur Seite 2 Business Intelligence Aufgaben Bereitstellung harmonisierter Daten, Informationen

Mehr

BARC-Studie Data Warehousing und Datenintegration

BARC-Studie Data Warehousing und Datenintegration Ergebnisse der BARC-Studie Data Warehouse Plattformen Dr. Carsten Bange BARC-Studie Data Warehousing und Datenintegration Data-Warehouse -Plattformen und Datenintegrationswerkzeuge im direkten Vergleich

Mehr

Hetero-Homogene Data Warehouses

Hetero-Homogene Data Warehouses Hetero-Homogene Data Warehouses TDWI München 2011 Christoph Schütz http://hh-dw.dke.uni-linz.ac.at/ Institut für Wirtschaftsinformatik Data & Knowledge Engineering Juni 2011 1 Data-Warehouse-Modellierung

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

Intelligente Kanzlei

Intelligente Kanzlei Seite 1 von 5 Intelligente Kanzlei Datawarehouse und OLAP in der Steuerkanzlei Notwendigkeit eines Kanzleiinformationssystems Seit einigen Jahren sind enorme Veränderungen am Beratungsmarkt durch einen

Mehr

Professionelles Projektmanagement in der Praxis. Veranstaltung 7 Teil 1 (30.06.2003):

Professionelles Projektmanagement in der Praxis. Veranstaltung 7 Teil 1 (30.06.2003): Professionelles Projekt-Management in der Praxis Veranstaltung 7 Teil 1 (30.06.2003): Prof. Dr. Phuoc Tran-Gia, FB Informatik, Prof. Dr. Margit Meyer, FB Wirtschaftswissenschaften, Dr. Harald Wehnes, AOK

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

Marketing Intelligence Übersicht über Business Intelligence. Josef Kolbitsch Manuela Reinisch

Marketing Intelligence Übersicht über Business Intelligence. Josef Kolbitsch Manuela Reinisch Marketing Intelligence Übersicht über Business Intelligence Josef Kolbitsch Manuela Reinisch Übersicht Beispiel: Pantara Holding Der Begriff Business Intelligence Übersicht über ein klassisches BI-System

Mehr

INVEST projects. Besseres Investitionscontrolling mit INVESTprojects

INVEST projects. Besseres Investitionscontrolling mit INVESTprojects Besseres Investitionscontrolling mit Der Investitionsprozess Singuläres Projekt Idee, Planung Bewertung Genehmigung Realisierung Kontrolle 0 Zeit Monate, Jahre Perioden Der Investitionsprozess Singuläres

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

1 Einführung. Unbekannte Begriffe: Business Intelligence, Knowledge Management, Unternehmensportale, Information Warehouse.

1 Einführung. Unbekannte Begriffe: Business Intelligence, Knowledge Management, Unternehmensportale, Information Warehouse. 1 Einführung mysap Business Intelligence stellt mit Hilfe von Knowledge Management die Verbindung zwischen denen, die etwas wissen und denen, die etwas wissen müssen her. mysap Business Intelligence integriert

Mehr

Business Intelligence für Controller

Business Intelligence für Controller Controllers Best Practice Fachbuch Business Intelligence für Controller Hermann Hebben und Dr. Markus Kottbauer Verlag für ControllingWissen ÄG, Freiburg und Wörthsee Ein Unternehmen der Haufe Mediengruppe

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

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

Herkömmliche Softwareentwicklungsmodelle vs. Agile Methoden

Herkömmliche Softwareentwicklungsmodelle vs. Agile Methoden vs. Agile Methoden Christoph.Kluck@Student.Reutlingen University.de Medien und Kommunikationsinformatik Agenda Einführung Vorgehensmodelle Herkömmlich agil Resümee Klassische Probleme Nachgereichte Anforderungen

Mehr

Data Warehousing. Sommersemester 2005. Ulf Leser Wissensmanagement in der Bioinformatik

Data Warehousing. Sommersemester 2005. Ulf Leser Wissensmanagement in der Bioinformatik Data Warehousing Sommersemester 2005 Ulf Leser Wissensmanagement in der Bioinformatik ... Der typische Walmart Kaufagent verwendet täglich mächtige Data Mining Werkzeuge, um die Daten der 300 Terabyte

Mehr

Block R (Rahmen): SE Aktivitäten 21.10.04 2. Vorlesung Methoden des Software Engineering. Block R Rahmen Aktivitäten der Software-Entwicklung

Block R (Rahmen): SE Aktivitäten 21.10.04 2. Vorlesung Methoden des Software Engineering. Block R Rahmen Aktivitäten der Software-Entwicklung Block R (Rahmen): SE Aktivitäten 21.10.04 1 Vorlesung Methoden des Software Engineering Block R Rahmen Aktivitäten der Software-Entwicklung Martin Wirsing Einheit R.2, 21.10.2004 Block R (Rahmen): SE Aktivitäten

Mehr

DWH Szenarien. www.syntegris.de

DWH Szenarien. www.syntegris.de DWH Szenarien www.syntegris.de Übersicht Syntegris Unser Synhaus. Alles unter einem Dach! Übersicht Data-Warehouse und BI Projekte und Kompetenzen für skalierbare BI-Systeme. Vom Reporting auf operativen

Mehr

eevolution Business Intelligence Oliver Rzeniecki COMPRA GmbH Programmierer & Datenbankadministrator

eevolution Business Intelligence Oliver Rzeniecki COMPRA GmbH Programmierer & Datenbankadministrator eevolution Business Intelligence Oliver Rzeniecki COMPRA GmbH Programmierer & Datenbankadministrator Agenda Was ist Business Intelligence? Was ist OLAP? Unterschied zwischen OLAP und OLTP? Bestandteile

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

INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung. Robust und Agil gegeneinander oder miteinander?

INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung. Robust und Agil gegeneinander oder miteinander? INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung Rütistrasse 9, Postfach 5401 Baden, Switzerland Phone: +41 56 222 65 32 Internet: www.infogem.ch Robust und Agil gegeneinander oder miteinander?

Mehr

Data Warehouse Version: June 26, 2007. Andreas Geyer-Schulz und Anke Thede

Data Warehouse Version: June 26, 2007. Andreas Geyer-Schulz und Anke Thede Data Warehouse Version: June 26, 2007 Andreas Geyer-Schulz und Anke Thede Schroff-Stiftungslehrstuhl Informationsdienste und Elektronische Märkte Fakultät für Wirtschaftswissenschaften Gebäude 20.20 Rechenzentrum,

Mehr

Master-Thesis (m/w) für unseren Standort Stuttgart

Master-Thesis (m/w) für unseren Standort Stuttgart Master-Thesis (m/w) für unseren Standort Abschlussarbeit im Bereich Business Process Management (BPM) Effizienzsteigerung von Enterprise Architecture Management durch Einsatz von Kennzahlen Braincourt

Mehr

Strategien zur Erweiterung eines Data Warehouse

Strategien zur Erweiterung eines Data Warehouse Studiengang: Informatik Prüfer: Betreuer: Prof. Dr.-Ing. habil. Bernhard Mitschang Thomas Sauter (DaimlerChrysler AG) Holger Schwarz (Universität Stuttgart) begonnen am: 01. September 2001 beendet am:

Mehr

Datenmanagement. Simone Unfried, Passau Vitaly Aleev, Passau Claus Schönleber, Passau. Strategisches Informationsmanagement 1 (01/2006)

Datenmanagement. Simone Unfried, Passau Vitaly Aleev, Passau Claus Schönleber, Passau. Strategisches Informationsmanagement 1 (01/2006) Simone Unfried, Passau Vitaly Aleev, Passau Claus Schönleber, Passau (01/2006) Strategisches Informationsmanagement 1 Definition Notwendige Vermaischung der Daten in der Vorstufe zur Destillation von hochprozentiger

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

Mit Transbase Hypercube Data Warehouse Anwendungen effizient betreiben. Die Hypercube-Technologie

Mit Transbase Hypercube Data Warehouse Anwendungen effizient betreiben. Die Hypercube-Technologie Mit Transbase Hypercube Data Warehouse Anwendungen effizient betreiben Transbase Hypercube ist eine Transbase -Option, die die innovative Hypercube-Technologie für komplexe analytische Anwendungen (OLAP)

Mehr

eevolution Business Intelligence

eevolution Business Intelligence eevolution Business Intelligence Haben Sie sich schon häufig gefragt, warum Ihr Berichtswesen so kompliziert sein muss? Warum Sie nicht einfach mit wenigen Handgriffen Ihr Berichtswesen einrichten und

Mehr

Agile BI mit Agile BI Modeler & Agile Scorecard

Agile BI mit Agile BI Modeler & Agile Scorecard Agile BI mit Agile BI Modeler & Agile Scorecard Business Intelligence - so einfach wie möglich - so komplex wie nö7g Jon Nedelmann Darmstadt, 26.10.2012 Agile BI Tools Agile BI Modeler Ist eine Web- Anwendung

Mehr

INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung. Robust und Agil gegeneinander oder miteinander?

INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung. Robust und Agil gegeneinander oder miteinander? INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung Rütistrasse 9, Postfach 5401 Baden, Switzerland Phone: +41 56 222 65 32 Internet: www.infogem.ch Robust und Agil gegeneinander oder miteinander?

Mehr

Leseprobe. Claus Jordan, Dani Schnider, Joachim Wehner, Peter Welker. Data Warehousing mit Oracle. Business Intelligence in der Praxis

Leseprobe. Claus Jordan, Dani Schnider, Joachim Wehner, Peter Welker. Data Warehousing mit Oracle. Business Intelligence in der Praxis Leseprobe Claus Jordan, Dani Schnider, Joachim Wehner, Peter Welker Data Warehousing mit Oracle Business Intelligence in der Praxis ISBN: 978-3-446-42562-0 Weitere Informationen oder Bestellungen unter

Mehr

Die Microsoft-Komplettlösung für Datawarehousing, Big Data und Business Intelligence im Überblick. Volker.Hinz@microsoft.com

Die Microsoft-Komplettlösung für Datawarehousing, Big Data und Business Intelligence im Überblick. Volker.Hinz@microsoft.com Die Microsoft-Komplettlösung für Datawarehousing, Big Data und Business Intelligence im Überblick Volker.Hinz@microsoft.com Was sagt der Markt? Fakten Meinung der Analysten zu Microsofts Angeboten Nutzen

Mehr

Bachelor/Master-Thesis (für den Standort Stuttgart) Treiberbasierte Planung

Bachelor/Master-Thesis (für den Standort Stuttgart) Treiberbasierte Planung Bachelor/Master-Thesis (für den Standort Stuttgart) Treiberbasierte Planung Hochschulstudium (Wirtschaftsinformatik oder ein vergleichbarer Studiengang) Fachliche und technische Kenntnisse im Bereich Business

Mehr

Business Intelligence

Business Intelligence Business Intelligence Anwendung 1 MInf1 HAW Hamburg Betreuender Professor: Prof. Dr. Zukunft by Jason Hung Vuong [12] Gliederung 1. Hamburg Energie Kooperation 2. Motivation 3. Business Intelligence 4.

Mehr

Kapitel 4: Data Warehouse Architektur

Kapitel 4: Data Warehouse Architektur Data Warehousing, Motivation Zugriff auf und Kombination von Daten aus mehreren unterschiedlichen Quellen, Kapitel 4: Data Warehousing und Mining 1 komplexe Datenanalyse über mehrere Quellen, multidimensionale

Mehr