Architektur Analytische Informationssysteme [Diplomarbeit Risikomanagement und Business Intelligence]
Kopfzeilenbild  
Diplomarbeit Risikomanagement  
  :: Inmaco HOME :: 
 
 
Inhaltsverzeichnis
Kapitel 1
Kapitel 2 & 2.1
Kapitel 2.2
Kapitel 2.3
Kapitel 3 & 3.1
Kapitel 3.1.2
Kapitel 3.1.3
Kapitel 3.2 & 3.3
Kapitel 3.4
Kapitel 4 & 4.1
Kapitel 4.2
Kapitel 4.2.3
Kapitel 4.3
Kapitel 4.4
Kapitel 4.4.3
Kapitel 5
Kapitel 6
 
 
Kapitel 4 Architektur von Analytischen Informationssystemen  

 

(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 Trans­action 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 Anforde­rungen und Eigenschaften für diese zwei Konzepte. Mit dem OLAP-Konzept wird ein anwen­dungsorientierter Gestaltungsrahmen für den Aufbau von AIS vorgegeben, damit Benutzer schnell und individuell, sowie mit geringem Aufwand Ad-hoc-Auswertungen, wie auch kom­plexe betriebswirtschaftliche Analysen durchführen können. Da zur Analyse (Planung, Prog­nose 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.

  1. 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.

  2. 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 Speiche­rung, Datenmodellierung und Verwaltung auseinanderzusetzen.

  3. Zugriffsmöglichkeiten
    Auf alle relevanten Daten, die der Anwender für seine Analysen benötigt, muß er jederzeit zugreifen können.

  4. 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.

  5. 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.

  6. 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.

  7. 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.

  8. Mehrbenutzer-Funktionalität
    Auf die Datenbasis müssen zumeist mehrere Anwender zur gleichen Zeit zugreifen. Dies sollte ein OLAP-System bewerkstelligen können.

  9. Unbeschränkte dimensionsübergreifende Operationen
    Das System sollte Berechnungen unterstützen, die nicht nur zwei Dimensionen, sondern viele Dimensionen mit einbeziehen.

  10. Intuitive Datenanalyse
    Es sollte in einem OLAP-System Navigationstechniken geben, mit denen intuitiv in der Datenbasis vorgegangen werden kann.

  11. 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.

  12. Unbegrenzte Dimensionen und Aggregationsebenen
    Beim Aufbau der Dimensionen und deren Aggregations- und Konsolidierungstufen sollen keinerlei Beschränkungen existieren, so daß die Datenmodellierung den betriebswirt­schaftlichen 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

  1. 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 Analy­sen.

  2. Analysis
    Bei Analyseabfragen werden Verfahren und Techniken gefordert, die es dem Benutzer er­möglicht, alle notwendigen mathematischen Berechnungen und Strukturuntersuchungen ad-hoc zu bilden. Dabei sollte es dem Benutzer möglich sein, diese Abfragen ohne Pro­grammierkenntnisse zu bilden, wobei er verschiedene Präsentationsformen nutzen kann.

  3. Shared
    Die Sicherheitsanforderungen an relationale DBMS sollten erfüllt sein. Bei OLAP-Anwen­dungen, die auch Schreibzugriffe zulassen, sollten auch Mechanismen, wie „concurrency control“, „Query processing“ und „Recovery“ realisiert sein.

  4. Multidimensional
    Grundanforderung an jedes OLAP-Produkt ist die Bereitstellung der Daten in multidimen­sionaler 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.

  5. 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 Analysewerkzeu­gen. Der Einsatz des Konzeptes des Data Warehouse ist sehr wichtig, da die Daten in aggre­gierter Form vorliegen müssen. Dadurch können schnelle Analysen erstellt werden. Ein weite­rer Grund dafür liegt im Zeitreihen-Konzept, da in den operativen Systemen keine Vergan­genheitsdaten 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ür­fel 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 Um­fang 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 Erfor­dernis 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 wer­den 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 Realisie­rung liegen in der Handhabung, Funktionalität und der Modellierung, da die multidimensio­nalen 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 multi­medialen 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 Spei­chermenge stärker ansteigt als bei ROLAP-Servern. Dadurch steigt auch der Wartungsauf­wand, 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 Tabellenkalkulations­programm 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 Anwenderpro­blem ab.

Im Finanzbereich wird normalerweise ein Tabellenkalkulationsprogramm verwendet. Dabei sollte man darauf achten, daß der OLAP-Server die Navigationseigenschaften für Tabellen­kalkulationen 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 be­zeichnet man den Vorgang, bei dem man von aggregierten Daten in die Detaildaten bzw. ato­maren Daten vordringt. Dabei navigiert der Anwen­der 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 so­mit 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-Sys­teme 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 seman­tischen 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



 
    ©2000-2007 InMaCo, Powered by Ralph Leipert All rights reserved.