Zugriffsmöglichkeiten auf das Data Warehouse durch das Analysekonzept OLAP

Inhaltsverzeichnis

Abbildungsverzeichnis

Abkürzungsverzeichnis

1 Einleitung

2 Das Data Warehouse-Konzept
2.1 Der Begriff des Data Warehouse-Konzeptes
2.2 Die Architektur des Data Warehouse-Konzeptes
2.3 Analyse- und Auswertungskonzepte im Data Warehouse-Konzept

3 Das Analysekonzept des On-line Analytical Processing (OLAP)
3.1 Einordnung in den Data Warehouse-Kontext
3.2 Begriffliches zum Analysekonzept OLAP
3.3 Anforderungen an das Analysekonzept OLAP
3.4 Navigation im OLAP-Würfel
3.4.1 Droll Down und Roll Up
3.4.2 Slice und Dice
3.4.3 Rotation
3.4.4 Drill Across und Drill Through
3.5 OLAP-Architekturen
3.5.1 Relationales OLAP
3.5.2 Multidimensionales OLAP
3.5.3 Hybrid OLAP
3.6 Bewertung des Analyse-Konzeptes OLAP

4 Zusammenfassung und Ausblick

Literaturverzeichnis

Abbildungsverzeichnis

Abb. 1: Die Data Warehouse-Architektur

Abb. 2: Multidimensionale Sichtweise auf Produktumsätze

Abb. 3: Klassifikationsschema mit einfachen Hierarchien

Abb. 4: Klassifikationsschema mit parallelen Hierarchien

Abb. 5: Drill Down

Abb. 6: Slice

Abb. 7: Dice

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1 Einleitung

Die Bedeutung des Produktionsfaktors Information hat neben Arbeit, Kapital und Boden in den letzten Jahren starken Zuwachs gewonnen. Nur ein gezielter Infor- mations- und Wissenstransfer innerhalb eines Unternehmens kann Innovationen, Wettbewerbsfähigkeit und Profitabilität gewährleisten. Um diese Ziele in einem Unternehmen durchsetzen zu können, muß ein ausgereiftes Informationssystem im Unternehmen vorhanden sein, das die Informationen dem Management in ge- eigneter Qualität übermittelt, und zudem diese vorher themenspezifisch selektiert . Wissenschaft und Praxis beschäftigen sich schon seit mehreren Jahrzehnten mit der Entwicklung von Informtionssystemen für das Management zu Controlling- und Planungszwecken. Dabei hat sich das Data Warehouse-Konzept als ein effi- zienter Ansatz herausgestellt. In diesem wird an die Informationsverarbeitung der operativen Systeme eines Unternehmens, wie z. B. der Verarbeitung von Perso- nal-, Verkaufs- oder Umsatzzahlen, angeknüpft und die Informationen zu Analy- sezwecken in einer separaten Datenbank zusammengestellt. Diese können dann mittels verschiedener Berichts- oder Analysekonzepte aufbereitet werden. Die vorliegende Seminararbeit beschäftigt sich mit dem Analysekonzept des „On-line Analytical Processing“ (OLAP). Als Einstieg dient die Darstellung des Data Wa- rehouse-Konzeptes. Hierbei soll inbesondere auf Begriffliches und auf seine Ar- chitektur eingegangen werden. Die Analyse- und Berichtskonzepte, auf deren Grundlage die Daten ausgewertet werden können, sollen vorerst nur ansatzweise erwähnt werden, da im eigentlichen Hauptteil gezielt das Konzept des OLAP dar- gestellt wird. Dieser beschäftigt sich mit der detaillierten Darstellung von OLAP und soll die Möglichkeiten des Konzeptes in den Vordergrund rücken. Hierbei soll der Unterschied zum „On-line Transactional Processing“ (OLTP) verdeutlicht werden. Zunächst erfolgt dies durch eine Einordnung in den Data Warehouse- Kontext, der als Einstieg in den Themenzusammenhang zur Verdeutlichung des engen Verbundes von Data Warehouse mit OLAP dienen soll. Durch Definitori- sches und Begriffliches zu Beginn diesen Abschnittes soll die Haupteigenschaft - die mehrdimensionale Betrachtungsweise - und deren Vorteile bei der Analyse veranschaulicht werden, so daß die in späteren Abschnitten folgenden Navigati- onsformen des Konzeptes zu verstehen sind. Die anschließenden Architekturvari- anten des OLAP-Konzeptes ergänzen die technische Seite der Darstellung des Analysekonzepts. Eingefügte Abbildungen sorgen für ein besseres Vorstellungs- vermögen im dreidimensionalen Raum und verdeutlichen das Konzept bildlich.

Zuletzt führt eine Zusammenfassung die wesentlichen Punkte stichwortartig zu- sammen und gibt einen Ausblick auf mögliche Entwicklungen und gegenwärtige Projekte oder Produkte in der Praxis.

2 Das Data Warehouse-Konzept

Ein Unternehmen verfügt heutzutage über riesige Datenbestände mit Informatio- nen, die sich aus seinen tagtäglichen Transaktionen ergeben. Sie befinden sich im operativen System eines Unternehmens. Die Führungskräfte benötigen jedoch nicht alle abrufbaren Daten aus den einzelnen operativen Systemen, wie z. B. La- gerverwaltung, Einkauf oder Verkauf, zur Ausführung ihrer Aufgaben, so daß für sie speziell aus den einzelnen Datenbasen abgeleitete Informationen zu Analyse- zwecken bereitgestellt werden müssen. Bereits Ende der 60er Jahre versuchten Unternehmen, durch geeignete computergestützte Informationssysteme, den In- formationsfluß zur Bewältigung der Managementaufgaben zu verbessern.¹ Die Begriffe Management-Informationssysteme (MIS), Decision Support Systeme (DSS) oder auch Executive Information Systeme (EIS), auf die im folgenden nicht näher eingegangen werden soll, stellen solche Versuche dar. Diese alle Systeme haben es gemeinsam, daß sie auf die Daten der Data Warehouse-Datenbank zugreifen.² In den folgenden Abschnitten wird erläutert, was sich hinter dem Beg- riff des Data Warehouse verbirgt.

2.1 Der Begriff des Data Warehouse-Konzeptes

Das Data Warehouse-Konzept sieht „... die separate Speicherung der analyserele- vanten Datenbestände...“³ aus den Datenbanken des operativen Systems eines Unternehmens, wie z. B. Finanzbuchhaltung oder Vertriebssystem, in der Data Warehouse-Datenbank vor. Konkret heißt dies, daß entscheidungsrelevante De- taildaten aus mehreren verschiedenen, dezentralen oder auch externen Datenquel- len „... in einen zentralen, homogenen und konsistenten Datenpool [zusammenge- führt werden], mit dem Zweck, die strukturierten, bereinigten und verdichteten Daten als Informationen allen am Entscheidungsprozeß beteiligten Personen im Sinne einer einheitlichen Entscheidungsgrundlage automatisiert zur Verfügung zu stellen.“⁴ Mit Hilfe flexibler Analyse- und Auswertungskonzepte, wie z. B. das Data Access, Data Mining oder auch OLAP, auf die im Abschnitt 2.3 eingegangen wird, kann auf diese Daten sinnvoll zugegriffen werden.

2.2 Die Architektur des Data Warehouse-Konzeptes

Um ein Data Warehouse-Konzept aus betriebswirtschaftlicher Sicht optimal nut- zen zu können, muß es unter technischen Gesichtspunkten in die Informationssys- temlandschaft eines Unternehmens eingebettet werden. Dabei sind zwei Punkte zu beachten: Zum einen muß es so konstruiert sein, daß die Daten in das zentrale Data Warehouse hineingelangen, und zum anderen muß das Management über geeignete Analyse- und Auswertungsfunktionen, zur Navigation im Datenbestand und zur Präsentation seiner Ergebnisse verfügen.⁵ Aufgrundessen kann das Data Warehouse-Konzept unter architektonischen Gesichtspunkten in drei Schichten eingeteilt werden: Die unterste Schicht stellen die sogenannten operativen Vorsys- teme, auch On-line Transactional Processing (OLTP)-Systeme dar. Sie sind die Informationssysteme für die eigentlichen Geschäftsprozesse, wie z. B. Finanz- buchhaltung, Lagerverwaltung und andere.⁶ Das zentrale Data Warehouse stellt die Datenbasis in Form relationaler Datenbanken dar und steht im Mittelpunkt des Data Warehouse-Konzeptes.⁷ Seine Gestaltung trägt zum Erfolg der Abfragen und Analysen des Managements entscheidend bei. Die eingespeisten Daten müssen daher auf bestimmte Art und Weise aufbereitet und gespeichert werden. Von Im- mon wurde hierzu eine Anforderungsdefinition aufgestellt: „ A data warehouse is a subject oriented, integrated, nonvolatile, and time variant collection of data in support of management ’ s decisions. ” ⁸

Hiernach sollen die Daten aus den operativen Systemen und externen Quellen im zentralen Data Warehouse:

1. nach übergeordneten Themengebieten abgelegt werden (subject oriented),
2. in Bezug auf Bezeichnung, Identifikationsschlüssel, Typ, Format, Syntax und Semantik vereinheitlicht werden (integrated),
3. nach der Übertragung nicht mehr verändert werden, wobei die Zugriffe ausschließlich aus Leseoptionen bestehen (nonvolatile),
4. mit einem Datum versehen werden und mehrere Jahre gespeichert werden (time variant).

Aufgrund der hohen Datenbestände und damit verbundenen längeren Wartezeiten bei Abfragen können aus den Daten des Data Warehouse dezentrale Data Marts gebildet werden. Sie sind funktionsbereichs- oder personengruppenspezifische Ausschnitte aus der zentralen Datenbasis und können als abteilungs- und themen- spezifisches Data Warehouse verstanden werden. Sie werden gebildet, um schnel- ler von verschiedenen Orten auf eine gemeinsame Datenbank zugreifen zu können und sie werden in die Gesamtarchitektur des Data Warehouse eingebettet.⁹ Inso- fern beinhaltet ein Data Mart einen bewußt redundant gehaltenen Ausschnitt des Data Warehouse.¹⁰ In anderen wissenschaftlichen Sichtweisen werden Data Marts auch als Vorstufe des unternehmensweiten Data Warehouses genannt, indem fachbereichsbezogene kleine Data Marts aufgebaut werden, aus denen im Endef- fekt ein Data Warehouse entsteht.¹¹ Hierbei existiert keine zentrale Datenbasis. Das Data Warehouse besteht vielmehr aus vielen, einzelnen, themenbezogenen Data Marts, oftmals wird diese Architektur auch als virtuelles Data Warehouse bezeichnet. In den folgenden Ausführungen wird jedoch von einem Data Ware- house-Konzept mit einer zentralen Datenbasis und redundanten Abbildungen in Form von Data Marts ausgegangen, welches auch weiterhin nur als Data Ware- house bezeichnet werden soll. Die oberste Schicht der Data Warehouse- Architektur bilden die Berichts- und Analysesysteme, die durch geeignete Front- End-Werkzeuge dem Management eine beliebige (Ad-hoc) Präsentation und Sicht der Daten ermöglichen.¹² Die Aufteilung in verschiedene, miteinander kooperie- rende Schichten macht den Begriff des Konzeptes deutlich, da es zu einer Zu- sammenführung dreier unternehmensindividueller Komponenten kommt, die zwar einzeln, aber nicht in dieser Konstellation zusammen als Data Warehouse-System erhältlich wären. Abb. 1 soll die Architektur bildlich verdeutlichen. Im folgenden Abschnitt wird auf die üblichen Analyse- und Auswertungskonzepte, auf deren Grundlage geeignete Front-End-Werkzeugen erstellt werden, eingegangen.

Quelle: Müller (1999), S. 96.

Abb. 1: Die Data Warehouse-Architektur

2.3 Analyse- und Auswertungskonzepte im Data Warehouse-Konzept

Das Front-End ist die Benutzeroberfläche von Softwareprogrammen und bezeich- net das letzte Glied in der Kette der Informationsgewinnung und -bereitstellung innerhalb des Data Warehouse-Konzeptes. Front-End-Werkzeuge sind Program- me für den Einsatz am Arbeitsplatz und dienen der Bearbeitung und Darstellung von Informationen in Form von Analysen und Berichten. Sie sind mit bestimmten Analyse- und Auswertungsfunktionen ausgestattet, die nach verschiedenen Kon- zepten funktionieren. Einige Programme sind nach dem Konzept des sogenannten Data Minings aufgebaut. Hierbei handelt es sich um eine Analyse durch „... das automatische Entdecken von Zusammenhängen in Datenbeständen durch Anwen- dung von Algorithmen.“¹³ Es entstand daraus, daß nicht alle wertvollen Informa- tionen in wissenschaftlichen und kommerziellen Datenbanken durch eine einfache Auswertung gefunden werden konnten, da letztlich hierbei der Benutzer Selbst die Steuerung des Programms übernehmen mußte.¹⁴ Geeigneter waren geübte Statis- tiker oder jemand, der sich mit dem Anwendungsgebiet auskannte.¹⁵ Ziel des Data Minings ist somit, bisher unbekannte Zusammenhänge in großen Datenbeständen zu erkennen. Im Gegensatz zu den klassischen Abfragewerkzeugen des operativen Systems muß der Benutzer im Vorfeld nicht wissen, wonach er sucht.

Eine weitere Möglichkeit der Softwaremodellierung bildet das Konzept des Data Access. Hierbei handelt es sich um ein Berichtskonzept, welche Daten liest, diese eventuell verändert, anreichert und sie in vorgefertigten Berichten präsen- tiert.¹⁶ Das Berichtswerkzeug bedient sich einer Ampelfunktion, die als „... regel- gebundene Formatierung definierter Bereiche ...“¹⁷ definiert wird. Z. B. können Grenzwerte in Tabellen oder auch Grafiken gesetzt werden und diese werden in drei Klassen unterteilt, die sich bildlich in verschiedenen Farben präsentieren, was dem Benutzer die Auswertung einzelner Daten erleichtert. Im Gegensatz zum Da- ta Mining wird nicht nach unbekannten Strukturen gesucht, sondern bereits ge- fundene Strukturen mit aktuellen Informationen gefüllt.

Letztlich existiert noch das Analysekonzept des On-line Analytical Processing (OLAP). Hierbei wird nicht wie beim Data Mining oder Data Access auf relatio- nale Daten zugegriffen, vielmehr stellt OLAP ein „... Konzept zur analytischen multidimensionalen Datenauswertung ...“¹⁸ dar, d. h. daß die Daten zur besseren Analyse in die mehrdimensionale Sichtweise gebracht werden müssen, wo sie vom Benutzer durch beliebiges Drehen und Wenden oder Ausschneiden von Da- tenbereichen betrachtet und ausgewertet werden können. Hierbei kann der Benut- zer beliebige, sogenannte Ad-hoc-Anfragen, oder auch vorgefertigte Anfragen durchführen. In den folgenden Abschnitten wird näher auf das Analysekonzept OLAP eingegangen.

3 Das Analysekonzept des On-line Analytical Processing (OLAP)

Zur Erfüllung seiner Aufgaben, wie Planung und Kontrolle, braucht das Management aus dem Data Warehouse Unternehmensdaten in aufbereiteter, aussagefkräftiger Form, um aus ihnen entscheidungsrelevante Informationen zu gewinnen. Wie schon im Abschnitt 2.3 dargestellt, kann dies unter anderen mittels „Data Access“, „Data Mining“ und OLAP geschehen. Es existieren noch andere Analyse- und Auswertungskonzepte, diese sollen jedoch nicht thematisiert werden, ferner wird nur auf die üblichen Konzepte eingegangen.

In den folgenden Abschnitten wird das Analysekonzept OLAP näher erläutert, dessen Grundlage die multidimensionale oder mehrdimensionale Sichtweise auf historische, konsolidierte Datenbestände zu Analysezwecken bildet.¹⁹

3.1 Einordnung in den Data Warehouse-Kontext

OLAP stellt ein Analysekonzept dar, welches es dem Benutzer erleichtert, auf Daten des Data Warehouse zuzugreifen, und diese schnell und ohne großen Auf- wand - basierend auf der Betrachtung aus verschiedenen Blickwinkeln - auswer- ten zu können.²⁰ Hierbei bietet OLAP einen „... Gestaltungsrahmen für den Auf- bau von analytischen Informationssystemen...“²¹, ohne daß die Beherrschung von Eingabebefehlen der Datenmanipulationssprachen der vierten Generation (wie z. B. SQL²² ) notwendig wäre. Es sollen beliebige Abfragen (Ad-hoc-Abfragen) ntu- itiv getätigt werden können , ohne auf die dauerhafte Hilfe eines Datenbankpro- grammierers angewiesen zu sein. OLAP läßt sich von den anderen Arten der In- formationsgewinnung, dem Data Access und Data Mining, klar abgrenzen. Es handelt sich hierbei nicht um zweckorientierte Berichte, die innerhalb eines ein- gegrenzten Datenraumes abgefragt werden (Data Access), oder um die Suche nach speziellen Beziehungen, z. B. Mustern, innerhalb des Datenbestandes (Data Mining), wie z. B. Regelmäßigkeiten oder Auffälligkeiten,²³ sondern um die Da- tenanalyse im multidimensionalen Raum, die darauf abzielt, neue oder unerwarte- te Beziehungen zwischen den einzelnen Dimensionen zu entdecken.²⁴

3.2 Begriffliches zum Analysekonzept OLAP

Geprägt wurde der Begriff OLAP 1993 von Edgar F. Codd und seinen Mitarbei- tern, die in Form eines Anforderungskataloges 12 Grundregeln aufstellten, denen ein OLAP-System entsprechen muß.^{25 26} Sie grenzten den Begriff bewußt von dem des OLTP ab, der die Informationsverarbeitung innerhalb des operativen Systems eines Unternehmens beschreibt und aktuelle Detailinformationen satzweise ab- fragt. Ferner werden die Daten innerhalb der operativen Systeme nicht zeitpunkt- bezogen abgespeichert, sondern modifiziert oder gar gelöscht. OLTP-Systeme sind somit für die Analyseanforderungen des Managements ungeeignet, auch weil diese nicht genügend Kenntnisse in einer Sprache der vierten Generation besitzen, um geeignete Anfragen zu programmieren. Darüber hinaus würden ungeschickte Anfragen das ganze Rechnersystem blockieren. Das OLAP-Konzept soll hierbei Abhilfe schaffen und die im Data Warehouse befindlichen aggregierten und histo- rischen Daten aus dem operativen System und externen Quellen zu Analysezwe- cken nutzen.²⁷ Der Teilbegriff „On-line“ steht für schnelle Antwortzeiten, ähnlich die der operativen Systeme. „Analytical“ steht für die Analyse der Daten, im Ge- gensatz zu der Informationsverarbeitung der operativen Systeme. „Processing“ stellt die Funktionsweise von OLAP als Prozeß dar.²⁸ Den zentralen Bestandteil des OLAP-Konzeptes stellt somit die Analyse in multi- oder auch mehrdimensio- naler Sichtweise dar. Zuvor war es nur möglich, Analysen im zweidimensionalen Raum in Form von Tabellen darzustellen. Mit Hilfe von OLAP sollen auch Frage- stellungen, wie z. B. „Wie hoch war der Umsatz im ersten Quartal 2000 in der Region S ü d vom Produkt Leonardo ?“, anhand der drei Dimensionen Quartal 2000, Region Süd und Produkt Leonardo analysiert werden können. Eine gute Veranschaulichung dieser drei Dimensionen bietet der Würfel, wie in Abb. 2 dar- gestellt, auf dessen Kanten sich jeweils eine Dimension abbilden läßt. Um die Mehrdimensionalität des OLAP-Konzeptes gewährleisten zu können, müßte es sich um einen Hyperwürfel mit beliebig vielen Dimensionen handeln, da streng geometrisch gesehen, der Würfel nur über genau drei Dimensionen verfügt, es sich jedoch gemäß OLAP aber um ein n-dimensionales Konzept handeln soll. Desweiteren beinhalten alle Dimensionen mehrere Elemente, oder auch Ausprä- gungen genannt, deren Anzahl in jeder Dimension unterschiedlich sein kann. Wie in Abb. 2 ersichtlich, enthält die Dimension „ Produkt “ genau drei Ausprägungen, die Dimension „ Region “ jedoch vier.

Abbildung in dieser Leseprobe nicht enthalten

Abb.2: Multidimensionale Sichtweise auf Produktumsätze

[...]

¹ Vgl. Gluchowski et al. (1997), S. 149.

² Vgl. Behme / Mucksch (1998), S. 15 ff.

³ Müller (1999), S. 96.

⁴ Harbauer (2000), S. 56.

⁵ Vgl. Holten et al. (2001), S. 6.

⁶ Vgl. Holten et al (2001), S. 7

⁷ Vgl. hierzu und zum folgenden: Totok (2000), S. 43.

⁸ Immon (1996), S. 30.

⁹ Vgl. Voß / Gutenschwager (2001), S. 264.

¹⁰ Vgl. Mucksch (1999), S. 174.

¹¹ Vgl. Totok (2000), S. 46.

¹² Vgl. Holten et al. (2001), S. 10.

¹³ Schinzer / Bange (1999), S. 65.

¹⁴ Vgl. Ebenda, S. 64.

¹⁵ Vgl. Bissantz et al. (1998), S. 447.

¹⁶ Vgl. Bauer / Günzel (2001), S. 65.

¹⁷ Ebenda.

¹⁸ Totok (2000), S. 55.

¹⁹ Vgl. Gluchowski et al. (1997), S. 282.

²⁰ Vgl. Totok (2000), S. 55.

²¹ Chamoni / Gluchowski (1999b), S. 263.

²² Structured qery lnguage.

²³ Vgl. Düsing (1999), S.349.

²⁴ Vgl. Bauer / Günzel (2001), S. 96.

²⁵ Vgl. Jahnke et al. (1996), S. 321.

²⁶ Vgl. hierzu und zum folgenden: Stickel (1997), S. 507.

²⁷ Jahnke et al. (1996), S. 321.

²⁸ Vgl. hierzu und zum folgenden: Totok (2000), S. 56.