Zusammenfassung
Im vorhergehenden Kapitel wurde eine Vielzahl von Einzelaspekten diskutiert, die bei der Transformation von Daten aus operativen Systemen für die Datenbank analyseorientierter Informationssysteme zu beachten sind. Der Schwerpunkt betraf dabei die Frage, wie die relevanten Daten für das Data Warehouse aus den operativen Datenbeständen extrahiert werden können und welche Transformationsschritte zur Reinigung sowie zur strukturellen und inhaltlichen Anpassung der Daten erforderlich sind, bevor diese in den Data Warehouse-Datenbestand integriert werden.
This is a preview of subscription content, log in via an institution.
Buying options
Tax calculation will be finalised at checkout
Purchases are for personal use only
Learn about institutional subscriptionsPreview
Unable to display preview. Download preview PDF.
Literatur
Vgl. zu diesen Merkmalen z.B. Mayer (1997), S. 3ff.
Unter einem Lebenszyklus wird ein Konzept verstanden, das davon ausgeht, daß die Entwicklung eines Objektes im Zeitablauf in charakteristische Phasen unterteilt werden kann. Zeitreihen der Ausprägungen wichtiger Merkmale dieses Objektes ergeben idealisiert vielfach glok-kenförmige Kurven. So wird z.B. von Produktlebenszyklen gesprochen, die sich über Zeitreihen der Größen „Absatzmenge” und „Stiickgewinn” beschreiben lassen. Vgl. zu diesem Konzept z.B. Gabler Wirtschaftslexikon (1997), S. 2422f. In Analogie zum biologischen Lebenszyklus ist immer auch eine degenerative Phase Bestandteil solcher Konzepte. Diese wird im Zusammenhang mit dem „Data Warehouse-Lebenszyklus” im folgenden nicht betrachtet, da (optimistisch) davon ausgegangen wird, daß sich das Data Warehouse als Konzept zu einem festen, sich mit zunehmender Reife immer weiter etablierenden Instrument betrieblicher Informationsversorgung entwickelt. Auf den Begriff des Software-Lebenszyklus (vgl. Abschnitt 2.1.3, phasenorientierte Modelle) wird hier dagegen nicht zurückgegriffen, weil dieser für ein streng sequentielles Vorgehen belegt ist (vgl. Hansen (1996), S. 137).
„DSS processing begins with data and ends with requirements.” Inmon (1996), S. 291.
Vgl. zu Problemen beim Management von Softwareentwicklungsprojekten z.B. Brack/Koppe (1990), S. 304f.
Vgl. Fitting (1998), S. 338.
Vgl. z.B. Mattison (1996), S. 46ff.; Anahory/Murray (1997), S. 28ff.; W.-R. Hansen (1998), S. 326ff.; Weber/Strüngmann (1997), S. 34; Ladley (1997), S. 102ff.; Levin (1997), S. 74ff.
Vgl. zu den genannten Vorgehensmodellen Abschnitt 2.1.3.
Vgl. Anahory/Murray (1997), S. 331f.
Vgl. dazu Erler/Schelp (1998), S. 8ff.
Vgl. Holthuis (1998a), S. 217.
Beispiele, die eine Charakterisierung als eigenständiger Wettbewerbsfaktor erlauben, finden sich z.B. in Erler/Schelp (1998), S. 29ff.
Vgl w _R Hansen (1998), S. 327.
Vgl. Holthuis (1998a), S. 220f.
Vgl. zur Akzeptanz- und Partizipationsproblematik im Umfeld einer Systementwicklung auch Gluchowski/Gabriel/Chamoni (1997), S. 135ff. sowie Knittel (1995), S. 50ff.
Vgl. zu der hier nur schlaglichtartig beschriebenen Problematik Abschnitt 4.3.2.5.
Überlegungen zur Akzeptanzproblematik im vorliegenden Kontext stellt Kaiser (1998), S. 454ff., an.
Zum Requirements Engineering vgl. Mittermeir (1990), S. 239ff.
Füting (1998), S. 340, zeigt ein ähnliches Vorgehen, erweitert dieses aber um die Möglichkeit der teilweise parallelen Entwicklung der einzelnen Module.
Vgl. Abschnitt 4.3.1.
Vgl. Abschnitt 4.2.1.
Dies führt möglicherweise dazu, daß die Gesamtstrategie der Informationsversorgung neu überdacht wird und auch eine Neupositionierung des analyseorientierten Informationssystems erfolgt.
Zur Parallelisierung des Transformationsprozesses vgl. Kimball et al. (1998), S. 644f. Die Verwendung paralleler Systeme für die Data Warehouse-Datenbank wird in LaRue (1997), S. 241 ff., und in Yevich (1997), S. 236, beschrieben.
Vgl. Fußnote 590.
In bezug auf den Anschaffungspreis von Softwareprodukten kann argumentiert werden, daß diese hinsichtlich der Gesamtkosten für den Aufbau und den Betrieb der Systeme, in die sie einfließen, nur eine untergeordnete Rolle spielen. Hier wird jedoch eine kleinschrittige Vorgehensweise betrachtet, die entsprechend auch von schmalen Budgets in den einzelnen Phasen ausgeht, in denen durch den Kauf kommerzieller ETL-Werkzeuge (Extraction, Transformation, Loading) ein relevanter Budgetposten entsteht.
Vgl. Abschnitt 2.4.2. Ein Beispiel für ein metadatengestütztes Entwicklungssystem mit umfangreichen Generatorfunktionen ist Oracle Designer/2000, vgl. hierzu Anderson/Wendelken (1996).
Vgl. Gleason (1997b), S. 149.
Auf diese Weise lassen sich etwa strukturorientierte Metadaten für das Data Warehouse und die Transformationskomponenten gewinnen, wie sie in Abschnitt 3.4.1.1 beschrieben worden sind.
Dies setzt voraus, daß Möglichkeiten zur Zwischenspeicherung der extrahierten Daten vorhanden sind.
Das Vorliegen dieser Voraussetzung kann keineswegs als von vornherein selbstverständlich angesehen werden, wenn etwa Großrechnersysteme angeschlossen werden sollen, die in erster Linie für eine Kommunikation mit den angeschlossenen Benutzerterminals ausgelegt sind. Vgl. zu Infrastrukturaspekten Kimball et al. (1998), S. 51 lf.
Vgl. Abschnitt 4.3.2.3.
Vgl. Goranson (1998), S. 719f.
Vgl. Soeffky (1999), S. 14.
Rights and permissions
Copyright information
© 2000 Springer Fachmedien Wiesbaden
About this chapter
Cite this chapter
Müller, J. (2000). Anforderungen an die Transformationskomponente im Rahmen der Entwicklung und Nutzung eines analyseorientierten Informationssystems. In: Transformation operativer Daten zur Nutzung im Data Warehouse. Deutscher Universitätsverlag, Wiesbaden. https://doi.org/10.1007/978-3-663-09052-6_5
Download citation
DOI: https://doi.org/10.1007/978-3-663-09052-6_5
Publisher Name: Deutscher Universitätsverlag, Wiesbaden
Print ISBN: 978-3-8244-7073-0
Online ISBN: 978-3-663-09052-6
eBook Packages: Springer Book Archive