(Auszug aus der Diplomarbeit von Ralph Leipert: "Analytische Informationssysteme als Basis des Risikomanagement der Unternehmung")
4.1 OLAP
4.1.1 Einführung
Den Begriff „On-Line Analytical Proccessing“ prägte Codd40 1993. Damit bezeichnet er Konzepte, die zur Datenanalyse und Entscheidungsunterstützung des Management und von Fachabteilungen dienen. OLAP wird hier bewußt von dem Begriff OLTP (On-Line Transaction Processing) abgegrenzt. Als OLTP werden DBMS bezeichnet, die in den traditionellen operativen (transaktionsorientierten) Informationssystemen zum Einsatz kommen. Dabei steht der Prozeß der Transaktion im Vordergrund, der in einem zumeist relationalen DBS verwaltet werden muß. Da operative DBS hauptsächlich zur Verwaltung von aktuellen Daten dienen, sind Lese- und Schreibzugriffe zu verwalten, im Gegensatz zum OLAP, wo hauptsächlich Lesezugriffe verwaltet werden müssen. Daraus ergeben sich auch unterschiedliche Anforderungen und Eigenschaften für diese zwei Konzepte. Mit dem OLAP-Konzept wird ein anwendungsorientierter Gestaltungsrahmen für den Aufbau von AIS vorgegeben, damit Benutzer schnell und individuell, sowie mit geringem Aufwand Ad-hoc-Auswertungen, wie auch komplexe betriebswirtschaftliche Analysen durchführen können. Da zur Analyse (Planung, Prognose und Kontrolle) von Daten auch historische Daten erforderlich sind, eignet sich dafür kein operatives DBS, in dem nur aktuelle Daten gespeichert werden. Außerdem sollten die Daten aggregiert, d.h. in verschiedenen Verdichtungsstufen vorliegen, da nur damit ein schneller Zugriff auf die Daten gewährleistet werden kann, welches eine Hauptanforderung an MSS ist. Um dies zu gewährleisten, ist ein Data Warehouse-Konzept als Datengrundlage für das OLAP unumgänglich.
4.1.2 Anforderungen an das OLAP-Konzept
Damit der Vorteil des OLAP-Konzeptes gegenüber herkömmlichen OLTP-Konzepten auch deutlich abgegrenzt werden kann, hat Codd41 12 Anforderungsregeln aufgestellt.
-
Multidimensionale Datensicht auf das konzeptionelle Schema
Das OLAP-System muß eine multidimensionale Sicht auf die Daten unterstützen, damit auch eine intuitive Analyse möglich wird.
-
Transparenz
Wie bei den VDBS der OLTP muß dem Anwender die Umsetzung und Funktionalität der Systeme verborgen bleiben. Somit bleibt ihm erspart, sich mit den Konzepten der Speicherung, Datenmodellierung und Verwaltung auseinanderzusetzen.
-
Zugriffsmöglichkeiten
Auf alle relevanten Daten, die der Anwender für seine Analysen benötigt, muß er jederzeit zugreifen können.
-
kontinuierliche Leistungsfähigkeit
Das System sollte zu jeder Zeit eine kontinuierliche Leistung (Schnelligkeit) erbringen, so daß der Anwender nicht eigene Navigationsstrategien entwickeln muß, um schnellstmöglich zu einer Analyse zu kommen.
-
Client-Server-Architektur
Damit die Daten im System verteilt werden können, ist es erforderlich, eine Client-Server Architektur für das OLAP-System zu verwenden.
-
einheitlich strukturierte Dimensionen
Die benötigten Dimensionen in der Datenstruktur sollten einheitlich aufgebaut sein. Dadurch erreicht man eine Einfachheit und damit einen leichteren Umgang mit diesen Daten und den darauf zugreifenden Werkzeugen als mit individuellen Dimensionsstruktuern.
-
Dynamische Speicherverwaltung dünnbesetzter Matrizen
Da betriebswirtschaftlichen Matrizen häufig dünn besetzt sind, muß das OLAP-System geeignete Mechanismen zur effizienten Handhabung dieser Lücken besitzen.
-
Mehrbenutzer-Funktionalität
Auf die Datenbasis müssen zumeist mehrere Anwender zur gleichen Zeit zugreifen. Dies sollte ein OLAP-System bewerkstelligen können.
-
Unbeschränkte dimensionsübergreifende Operationen
Das System sollte Berechnungen unterstützen, die nicht nur zwei Dimensionen, sondern viele Dimensionen mit einbeziehen.
-
Intuitive Datenanalyse
Es sollte in einem OLAP-System Navigationstechniken geben, mit denen intuitiv in der Datenbasis vorgegangen werden kann.
-
Flexibles Berichtswesen
Das Berichtswesen sollte flexibel hinsichtlich der Anforderungen der verschiedenen Anwender und der Datenbasis aufgebaut sein. Es muß möglich sein, Berichte von beliebigen Ausschnitten der Datenbasis zu bilden.
-
Unbegrenzte Dimensionen und Aggregationsebenen
Beim Aufbau der Dimensionen und deren Aggregations- und Konsolidierungstufen sollen keinerlei Beschränkungen existieren, so daß die Datenmodellierung den betriebswirtschaftlichen Anforderungen genügen kann.
Da diese Regeln jedoch sehr produktspezifisch sind, haben weitere Softwarehäuser und Beratungsunternehmen eigene, zum Teil ergänzende Anforderungen aufgesetzt, so daß derzeit ca. 50 Regeln existieren.42 Deshalb haben Pendse und Creeth eine gängigere Definition für das OLAP-Konzept unter dem Begriff FASMI (Fast Analysis of Shared Multidimensional Information) gefunden.43
-
Fast
Unter dem englischen Begriff „Fast“ verstehen die Autoren bei OLAP-Abfragen ein bis zwei Sekunden Antwortzeit für einfache und maximal 20 Sekunden für komplexe Analysen.
-
Analysis
Bei Analyseabfragen werden Verfahren und Techniken gefordert, die es dem Benutzer ermöglicht, alle notwendigen mathematischen Berechnungen und Strukturuntersuchungen ad-hoc zu bilden. Dabei sollte es dem Benutzer möglich sein, diese Abfragen ohne Programmierkenntnisse zu bilden, wobei er verschiedene Präsentationsformen nutzen kann.
-
Shared
Die Sicherheitsanforderungen an relationale DBMS sollten erfüllt sein. Bei OLAP-Anwendungen, die auch Schreibzugriffe zulassen, sollten auch Mechanismen, wie „concurrency control“, „Query processing“ und „Recovery“ realisiert sein.
-
Multidimensional
Grundanforderung an jedes OLAP-Produkt ist die Bereitstellung der Daten in multidimensionaler Form. Dabei ist großer Wert auf volle Unterstützung der Dimensionshierarchien zu legen, d.h. der Benutzer hat freien Zugriff auf den multidimensionalen Datenwürfel und kann multiple Berichtshierarchien über die Dimensionen legen.
-
Information
Zum Bereitstellen der erforderlichen Informationen für den Benutzer ist es wichtig, daß das Produkt ausreichend große Datenmengen speichern und verwalten kann. Weniger wichtig bei der Beurteilung der Leistungsfähigkeit des Produktes ist somit die Ressourcenbelegung (RAM und externe Speicher).
4.1.3 Komponenten und Architektur
Die OLAP-Architektur wird durch zwei Komponenten, den OLAP-Server (Datengrundlage) und den OLAP-Client (Endbenutzerwerkzeug), gekennzeichnet.
4.1.3.1OLAP-Server
Der OLAP-Server stellt die Daten für die Analysewerkzeuge zur Verfügung und kann durch ein Data Warehouse bzw. ein Data Mart realisiert werden (siehe Kapitel „Data Warehouse“). Somit ist er ein Bindeglied zwischen den operativen Datenquellen und den Analysewerkzeugen. Der Einsatz des Konzeptes des Data Warehouse ist sehr wichtig, da die Daten in aggregierter Form vorliegen müssen. Dadurch können schnelle Analysen erstellt werden. Ein weiterer Grund dafür liegt im Zeitreihen-Konzept, da in den operativen Systemen keine Vergangenheitsdaten existieren. Der OLAP-Server sorgt für die Bereitstellung der Daten in einer adäquaten, multidimensionalen Form.44 Dafür hat z.B. Microsoft das neues Datenformat MDX (Multi-Dimensional Extension) definiert.45 Die Datenbasis wird als multidimensionaler Würfel gespeichert. Dazu können relationale Datenbanken, aber auch spezielle multidimensionale Datenbanken zur Anwendung kommen. Mischformen dieser beiden sind ebenfalls möglich.
Abbildung 4-1 dreidimensionaler OLAP-Würfel
Ein wichtiger Punkt bei der Entwicklung bzw. Entscheidung für einen OLAP-Server stellt das Konzept zur Handhabung von Berechnungen dar. Die Berechnungen sind das Herzstück eines jeden OLAP-Servers und entscheiden über die Schnelligkeit, Benutzerfreundlichkeit und Umfang der Analysen. Die Berechnungen sollten im Meta-Modell des OLAP-Servers gespeichert werden, damit Änderungen an den Berechnungen nicht der Entwickler des Servers, sondern der Anwender selbst vornehmen kann.
Zur Realisierung von OLAP-Servern bedient man sich zur Zeit dreier verschiedener Methoden, dem Multidimensionalen OLAP (MOLAP), dem Relationalen OLAP (ROLAP) und der Mischform dieser beiden, dem Hybrid OLAP (HOLAP). Im folgenden sollen die MOLAP und ROLAP Methoden näher vorgestellt werden. Beim HOLAP werden die Daten je nach Erfordernis in eher relationalen oder eher mehrdimensionalen Strukturen gespeichert. Der Vorteil liegt bei diesem Server in der Flexibilität der Datenhaltung bzw. im variablen Zugriff von MOLAP und ROLAP Clients auf diesen Server.
Die Anforderungen an die Datenhaltung und die dazugehörigen Datenmodellierung wird im Kapitel „Data Warehouse“ bzw. „Datenmodellierung für die AIS“ näher beschrieben.
4.1.3.1.1 Relationales OLAP (ROLAP)
ROLAP-Werkzeuge basieren auf einer mehrdimensional-relationalen Datenhaltung. Dabei wird die multidimensionale Datensicht auf ein relationales Datenmodell abgebildet. Für die Umsetzung der Benutzer-Operationen (von multidimensionaler Sicht auf relationale Sicht) bedient man sich einer ROLAP-Maschine, welche mit Hilfe von dynamisch generierten SQL-Befehlen bewerkstelligt wird. Bei diesem Vorgang wird die bereitgestellte Funktionalität des DBMS genutzt.
Abbildung 4-2 ROLAP-Maschine
Die Realisierung der ROLAP-Maschine kann direkt im Data Warehouse bereitgestellt werden. Andererseits können die Daten aus dem Data Warehouse in ein Data Mart repliziert werden. Dies kann Schnelligkeits- und Sicherheitsvorteile bringen, da ein Data Mart nur einen Ausschnitt aus dem Data Warehouse darstellt und somit die Datenmenge kleiner ist. Außerdem können in das Data Mart zusätzlich externe Daten importiert werden, die z.B. nicht in das allgemeine Data Warehouse Konzept passen. In beiden Fällen muß die Datenbasis in einem mehrdimensional-relationalen Datenmodell dargestellt werden, z.B. in einem Star-Schema oder Snow-Flake-Schema.
Der Vorteil des ROLAP-Konzeptes liegt in der Möglichkeit der Datenhaltung größerer Datenmengen. ROLAP-Werkzeuge eignen sich somit besonders bei der Analyse von großen Datenmengen z.B. für Verkaufsanalysen. ROLAP-Werkzeuge sind auch die zur Zeit am häufigsten eingesetzten OLAP-Werkzeuge am Markt.
4.1.3.1.2 Multidimensionales OLAP (MOLAP)
MOLAP-Werkzeuge basieren auf einer multidimensionalen Speicherverwaltung. Dabei werden die Daten aus dem Data Warehouse in ein Data Mart repliziert. Dieser Data Mart wird mit Hilfe eines multidimensionalen DBMS (MDDBMS) verwaltet. Die Vorteile dieser Realisierung liegen in der Handhabung, Funktionalität und der Modellierung, da die multidimensionalen Daten auch multidimensional modelliert werden. Dadurch sollen die Zugriffe optimiert werden, sowie Speicher- und Struktureffizienz der analytischen Daten erreicht werden. Der Nachteil einer solchen Lösung liegt in der fehlenden Funktionalität der textuellen und multimedialen Datenunterstützung. Ein weiterer Nachteil der MOLAP-Server liegt in der großen Menge an Verknüpfungen von Daten, so daß bei steigender Datenmenge die benötigte Speichermenge stärker ansteigt als bei ROLAP-Servern. Dadurch steigt auch der Wartungsaufwand, falls die Daten im multidimensionalen Würfel geändert werden müssen.46 MOLAP-Werkzeuge werden besonders bei sehr intensiven und komplexen Analysen eingesetzt wie z.B. bei Rentabilitätsanalysen, Analysen von Finanzierungs-Kennzahlen (VaR, RAROC, RORAC) und Zukunftsprognosen (Shareholder Value).
4.1.3.2 OLAP-Client
Der OLAP-Client ist ein Werkzeug, das die Daten für das Management bzw. Fachabteilungen in der gewünschten Form darstellt. Dabei kann es sich um ein einfaches Tabellenkalkulationsprogramm wie MS Excel, Standard-Reporting-Programm, Data-Mining-Programm aber auch um ein individuelle erstelltes MSS, welches komplexe Analysen durchführen kann, handeln. Die Auswahl, welches Tool als OLAP-Client verwendet wird, hängt stark vom Anwenderproblem ab.
Im Finanzbereich wird normalerweise ein Tabellenkalkulationsprogramm verwendet. Dabei sollte man darauf achten, daß der OLAP-Server die Navigationseigenschaften für Tabellenkalkulationen unterstützt. Alle OLAP-Tools sollten die Navigationseigenschaften des Drill-Down bzw. des Roll-up besitzen. Damit wird dem Anwender ermöglicht, in die unterschiedlichen Detailierungsstufen des mehrdimensionalen Würfels vorzudringen. Zu dem wäre es von Vorteil, wenn die Tools die Navigationseigenschaften „drill-across“ und „drill-through“ unterstützen würden.47 „When viewing financial data by organization, account and time, an analyst might want to see product-specific revenue by organization, product and time. This is called drill across.“48 Drill-through bezeichnet man den Vorgang, bei dem man von aggregierten Daten in die Detaildaten bzw. atomaren Daten vordringt. Dabei navigiert der Anwender normalerweise direkt in die operativen Informationssysteme.
Weiterhin sollte darauf geachtet werden, wie Berichte erstellt und ausgedruckt werden können. Dreht man den Würfel und bildet beliebige zweidimensionale Schnitte durch den Würfel, so sind beliebige Perspektiven auf die Datenbasis möglich (Slice-and Dice).
Viele OLAP-Clients werden webbasierend realisiert, da dadurch viele Anwender auf ein und dieselben Daten zugreifen können. Diese Web-Clients haben den Vorteil, daß sie schnell erstellt und leicht zu warten bzw. anzuwenden sind. Die Realisierung bzw. Entwicklung des Web-OLAP-Tools kann entweder mit statischer oder mit dynamischer Seitengenerierung erfolgen. Bei der statischen Seitengenerierung werden die Seiten je nach Bedarf in einem bestimmten Zeitrhythmus generiert und im Netz abgelegt. Der Vorteil dabei ist, daß die Seiten von der Anwenderseite her sehr schnell abrufbar sind. Der Nachteil dieser statischen Methode ist aber die fehlende Aktualität der generierten Seiten. Bei der dynamischen Seitengenerierung werden die Seiten je nach Anwenderabfrage real-time gebildet. Dies führt gerade bei Mehrbenutzerbetrieb zu Schnelligkeitsproblemen, hat jedoch den Vorteil der absoluten Aktualität.
4.1.4 Zusammenfassung und Ausblick
OLAP-Systeme wurden entwickelt, um dem Anwender ein leistungsfähiges Analysewerkzeug bereitzustellen. Hierbei wurden die relationalen und die multidimensionalen OLAP-Systeme vorgestellt. Es wurde auch festgestellt, daß beide Systeme Vor- und Nachteile haben und somit der jeweilige Einsatz auf bestimmte Bereiche begrenzt ist. In diesem Teil der Arbeit wurde jedoch nicht auf die Datenmodellierung von OLAP-Servern eingegangen, da diese im Kapitel „Datenmodellierung für die AIS“ ausführlich behandelt wird.
Die Entwicklung von OLAP-Systemen geht immer mehr in die Richtung von der relationalen in die multidimensionale Speicherverwaltung. Durch die stetige Erweiterung der RDBS (Universal Server) wird heute schon eine Funktionalität (z.B. virtueller Würfel) angeboten, die weit über die des relationalen Modells hinausgeht.49 Dadurch nähern sich die ROLAP-Systeme immer mehr den MOLAP-Servern an. Außerdem existieren auch Ansätze der Entwicklung objektorientierter Systeme. Diese beschränken sich jedoch in der Praxis zur Zeit noch auf die objektorientierten Oberflächen von OLAP-Systemen.50
Da in den letzten Jahren sich mehr mit der Architektur von OLAP-Anwendungen auseinandergesetzt wurde, kam die Auseinandersetzung mit der dazugehörigen Datenmodellierung zu kurz. So wird auch die Entwicklung von neuen Datenmodellen - vor allem bei den semantischen Datenmodellen - ein Schwerpunkt in der nächsten Zukunft sein. Das Problem der Datenmodellierung zeigte sich auch bei einem Projekt der Hamburg-Mannheimer Versicherungs-AG51, bei dem ca. 3,5 Mio. Datensätze in einer Faktentabelle für einen Betrachtungsraum von 25 Monaten verwaltet werden mußten. Hierbei wäre eine klassische OLAP-Lösung in Form eines OLAP-Würfels (ca. 41 Mrd. Zellen) nicht möglich gewesen. Durch Speicherung der Daten in ihrer feinsten Struktur und durch geschickte Datenmodellierung und Indizierung konnte ein annehmbares Antwortverhalten (durchschnittlich 10 sec) bewerkstelligt werden.
40 Vgl.: Codd,E. F. / Codd,S. B. / Sally,C. T. (1993)
41 Vgl.: Codd,E. F. / Codd,S. B. / Sally,C. T. (1993)
42 Vgl.: Jahnke, B. / Groffmann, H.-D. / Kruppa, S. (1996), S. 321, Chamoni, P. (1998b), S.236
43 Vgl.: Pendse, N./ Creeth, R. (1995)
44 Vgl.: Jahnke, B. / Groffmann, H.-D. / Kruppa, S. (1996), S.322
45 Vgl.: Kuppinger, M. (1998), S.23
46 Vgl.: Tresch, M. / Rys M. (1997), S.18-37
47 Vgl.: Bulos, D. (1998a), S.4
48 Bulos, D. (1998a), S.4
49 Vgl.: Chamoni, P. (1998b), S. 247
50 Vgl.: Chamoni, P. (1998b), S. 247
51 Vgl.: Lühmann, P. / Erben, E. (1998), S. 33 |