Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

05.08.1994

Werkzeuge fuer den Endanwender Ein Dutzend Regeln klaert die Brauchbarkeit von Abfrage-Tools

Benutzerfreundliche Front-ends wie Report-Generatoren und Tabellenkalkulationen sollten dem Anwender helfen, Informationen aus der Datenflut zu gewinnen. Leider erfuellen heutige Produkte diesen Anspruch der auf mehrere Dimensionen bezogenen Aggregation, Zusammenfassung, Konsolidierung, Berechnung und Darstellung von Daten sowie des Formeleinsatzes und der Datenverbindung keineswegs. Edgar Codd stellt einen Forderungskatalog auf.

Im Bereich der Informationstechnologie besteht ein vielfaeltiger Bedarf an Hilfen zum Analysieren und Bearbeiten von numerischen und verschiedenen anderen Informationen. Dabei werden insbesondere solche Instrumente benoetigt, die die Faehigkeit haben,

- auf viele unterschiedliche Datentypen zuzugreifen,

- mehrdimensionale Perspektiven der Daten zu erzeugen,

- mit verschiedenen Datenformaten und Datenaggregationen zu experimentieren,

- neue Informationsmodelle zu definieren und darzustellen,

- die Modelle zusammenzufassen, zu konsolidieren, zu summieren und Formeln auf sie anzuwenden,

- durch Konsolidierungspfade auf und ab zu navigieren, sie aufzuteilen und zu zerlegen, zu drehen und zu rotieren sowie

- eine Vielfalt von Berichten zu generieren, die die einzelnen Arbeitsschritte widerspiegeln.

Das relationale Modell fuer

das Datenbank-Management

(RDBMS) wurde von E.F. Codd entwickelt. Es liefert das abstrakte Modell, die Grundlagen und die Regeln, die fuer die Entwicklung von Systemen zur Definition, Speicherung, Verwaltung und grundlegenden Manipulation verschiedenster Datentypen erforderlich sind. Die anspruchsvolleren Funktionen zur Datenbearbeitung wie statistische Analysen ueber verschiedene Bereiche der Datenbank hinweg, Anwendung komplexer Formeln und Erstellung von Berichten mit Daten aus mehreren Datenbankbereichen sprengen jedoch den Rahmen der "Basismanipulationen".

Waehrend das relationale Modell eine fuenf- bis zehn Milliarden Dollar schwere Industrie hervorgebracht hat, dazu Hunderte von RDBMS-Produkten, Tausende von Anwendungssystemen und Millionen von Datenbanken mit Milliarden von Bytes, wurden die Forderungen der Datenanalytiker vernachlaessigt.

Online Analytical Processing

(Olap) ist die Bezeichnung fuer die dynamische Datenanalyse im Unternehmen. Diese Form wird benoetigt, um Informationen aus exegetischen, kontemplativen und formelbasierten Analysemodellen zu erzeugen, zu bearbeiten, zu aktivieren und zu synthetisieren. Olap ermoeglicht es dem Anwender, neue oder unerwartete Beziehungen zwischen Variablen zu erkennen, notwendige Parameter zur Verarbeitung grosser Datenmengen zu identifizieren, eine unbegrenzte Anzahl von Dimensionen und Konsolidierungspfaden zu erzeugen, kreuzdimensionale Bedingungen und Formeln herzustellen sowie Daten zu analysieren, die diesen vielfaeltigen Dimensionen entsprechen. Dass die Olap-Verarbeitung dabei fast ausschliesslich auf bereits vorhandene Daten angewandt wird, ist eine unnoetige und kuenstliche Einschraenkung.

Olap ist auf einer Vielzahl von spekulativen Szenarios mit den Fragestellungen Was-waere-wenn oder Warum aufgebaut. Innerhalb dieser Szenarios werden Werte von Schluesselvariablen oder Parameter geaendert. Die Informationen werden dann durch eine Aktivierung des Datenmodells zusammengefuehrt, das oft die Konsolidierung der geplanten Geschaeftsdaten mehr als eines Konsolidierungspfades oder einer Datendimension umfasst.

Datenkonsolidierung ist der Prozess der Verdichtung von Informationselementen in einzelnen Bloecken mit relevantem Aussagegehalt. Die hoechste Ebene eines Datenkonsolidierungspfades wird als Dimension dieser Daten bezeichnet. Eine bestimmte Datendimension repraesentiert die spezifische Perspektive von Daten, die in dem zugewiesenen Konsolidierungspfad eingebunden sind. Die gleichzeitige Analyse von mehreren Datendimensionen wird als mehrdimensionale Datenanalyse bezeichnet. So koennen Datensaetze ohne Ruecksicht auf ihren Inhalt oder ihren Ursprung auf unterschiedlichste Weise analysiert werden. Jeder Datenkonsolidierungspfad spiegelt demnach die Perspektive und Erkenntnisabsicht seines Urhebers wider. Mit der Zeit koennen sich darueber hinaus Ueberlegungen, die zur Spezifikation von Konsolidierungspfaden gefuehrt haben, aendern.

Datenkonsolidierungspfade bestehen aus einer Anzahl von Konsolidierungsschritten oder -ebenen, die in Form von Parametern auf vielen Ebenen definiert sind. Diese Parameter entsprechen dem Wert jeder Variablen, wobei jede folgende Ebene eine hoehere Stufe der Datenkonsolidierung wiedergibt. Wurden so Daten einmal entlang eines oder mehrerer Konsolidierungspfade zusammengesetzt, bleibt die Rueckdifferenzierung (Drill down) auf Ebenen mit hoeherem Aufloesungsgrad moeglich. Drill down meint die Navigation von hoeheren zu niedrigeren Konsolidierungsebenen. Umgekehrt beschreibt Roll up die Bewegung von niedrigeren zu hoeheren Konsolidierungsebenen.

Vier Modelle fuer

die Datenanalyse

Dabei bedient sich die Datenanalyse eines von vier Datenmodellen als Basiswerkzeug:

1. das kategorische Modell,

2. das exegetische Modell,

3. das kontemplative Modell sowie

4. das formelbasierte Modell.

Das kategorische Datenmodell wird in der statischen Datenanalyse angewandt. Es beschreibt durch Vergleich mit gegebenen Werten den bisherigen Zustand. Da es ein statisches Modell ist, wird wenig oder keine Interaktion vom Anwender verlangt. Die Daten werden entsprechend dem durch das Datenbankdesign vorbestimmten Konsolidierungspfad ausgewertet.

Diese Form garantiert einen leichten Zugriff auf die Daten, indem einfache Anfragen an die Datenbank gerichtet, Werte miteinander verglichen und Reports erstellt werden. Zur Unterstuetzung dieser Aktivitaeten sind zahlreiche Werkzeuge vorhanden, zum Beispiel Programme fuer Datenbankabfragen, zur Report-Erstellung und Tabellenkalkulation.

Demgegenueber vollzieht das exegetische Modell die Vergangenheit nach. Dieses Werkzeug ist hauptsaechlich ein statisches Datenanalysemodell, mit dem der Anwender durch nachtraegliche, einfache Anfragen gleichsam eine oder mehrere Schalen von einer Zwiebel abschaelt. Will der Analytiker jedoch Entscheidungskonstellationen ermitteln, die vom urspruenglichen Datenbankdesign nicht erfasst wurden, muessen im Rahmen der Anwendung Mehrfachdimensionen erzeugt werden. Diese Funktion unterstuetzen heute allerdings nur wenige Werkzeuge.

Kontrolle und Bewertung

von einzelnen Parametern

Das kontemplative Modell offenbart, welche Ergebnisse mit speziellen Parametern erzielt wurden und zeigt entsprechende Abweichungen quer zu den Dimensionen des Datenmodells an. Anwender koennen mehrere Konsolidierungspfade erzeugen und untersuchen, indem sie kritische Variablen und Gleichungen festlegen. Ein aktiviertes Datenmodell gibt die Ergebnisse der Manipulationen bekannt. Wenige Tabellenkalkulationen bieten einen kleinen Ausschnitt dieser Faehigkeiten innerhalb einer einzelnen Datendimension an, aber keine ist zur Anwendung ueber mehrere Dimensionen hinweg geeignet.

Das formelbasierte Modell ist das dynamischste und anspruchsvollste in bezug auf den Interaktionsgrad und die damit verknuepfte variable Datenkonsolidierung. Es zeigt, welche Werte oder Verhaltensweisen quer durch multiple Dimensionen in das Modell eingefuehrt werden muessen, um ein bestimmtes Ergebnis zu erzielen.

Dazu definiert der Anwender ein Ergebnis und einen Anfangszustand. Das Modell kann aktiviert werden und vermittelt, welche Variablen in welcher Dimension und in welchem Umfang veraendert werden muessen, um das vorgegebene Resultat zu erzielen. Es ist kein Produkt bekannt, das diese Funktionen bereits erfuellt.

Waehrend der letzten 15 Jahre, in denen relationale DBMS und ergaenzende Werkzeuge fuer den Anwender zur Verfuegung standen, wurde versaeumt, Olap-Anforderungen zu unterstuetzen. Die laengst notwendige Evaluation muesste zwoelf Regeln beachten:

1. Mehrdimensionale konzeptionelle Perspektiven,

2. Transparenz,

3. Zugriffsmoeglichkeit,

4. konsistente Berichterstellung,

5. Client-Server-Architektur,

6. generische Dimensionalitaet,

7. dynamische Handhabung wenig ausgelasteter Matrizen,

8. Mehrbenutzer-Unterstuetzung,

9. uneingeschraenkte kreuzdimensionale Operationen,

10. intuitive Datenbearbeitung,

11. flexible Berichterstellung sowie

12. unbegrenzte Dimensionen und Aggregationsebenen.

Ein Anwenderanalytiker sieht die Welt eines Unternehmens naturgemaess mehrdimensional. Entsprechend sollte er auch die Olap- Modelle verstehen. Ein intuitives analytisches Modell erleichtert das Modelldesign und die Analyse von inter- und intradimensionalen Berechnungen.

Es kommt recht haeufig vor, dass Konsolidierungspfade innerhalb eines Modells aufgeteilt und zerlegt, gedreht und rotiert werden. Mehrdimensionale Modelle vereinfachen diese Manipulationen.

Integration als

analytisches Tool

Olap sollte in eine offene Systemarchitektur als analytisches Werkzeug eingebettet sein, ohne die Funktionalitaet des "gastgebenden" Grundwerkzeuges negativ zu beeinflussen. Entscheidend fuer den Erhalt der Produktivitaet ist Transparenz. Die Funktionalitaet des herkoemmlichen Front-ends muss gewahrt bleiben.

Ausserdem sollte fuer den Anwender transparent sein, ob die dem Olap-Werkzeug zugeleiteten Unternehmensdaten aus einer homogenen oder heterogenen Datenbankumgebung stammen.

Um dem Anwender eine einzige, kohaerente und konsistente Datenrepraesentation bieten zu koennen, muss das Olap-Werkzeug sein eigenes logisches Schema auf heterogene physikalische Datenbestaende abbilden. Ausserdem sollte es auf diese Daten zugreifen und jede notwendige Konvertierung selbst durchfuehren koennen. Die Anwender brauchen sich nicht darum zu kuemmern, woher oder von welchem Systemtyp die physikalischen Daten stammen. Dabei darf das Olap-System nur auf relevante Daten zugreifen.

Eine zunehmende Zahl der Dimensionen muss keine nennenswerte Leistungseinbusse bei der Berichterstellung bedeuten. Im Gegenteil: Eine konsistente Berichterstellung ist erforderlich, um die komfortable und einfache Bedienung zu gewaehrleisten.

Die meisten Daten, fuer die derzeit eine analytische Online- Verarbeitung ratsam ist, sind in Grossrechnersystemen gespeichert und werden mit Hilfe von PCs abgerufen. Daher muessen Olap-Produkte Client-Server-faehig sein. So muss der Server alle Adressierungen und Konsolidierungen zwischen ungleichartigen logischen und physikalischen Datenbankschemata von Unternehmen vornehmen koennen. Die Datendimensionen haben hinsichtlich ihrer Struktur und ihrer funktionalen Faehigkeiten aequivalent zu sein.

Darueber hinaus sollte das physikalische Schema des Olap-Werkzeugs vollstaendig an das spezifische analytische Modell angepasst sein, um fuer eine optimale Handhabung wenig ausgelasteter Matrizen zu sorgen. Dabei muessen die physikalischen Zugriffsmoeglichkeiten dynamisch austauschbar sein und unterschiedliche Mechanismen enthalten: direkte Berechnung, B-Trees und Derivate oder Direktadressierung. Ausserdem muss es moeglich sein, diese Methoden miteinander zu kombinieren. Wenn das Olap-Werkzeug sich der Verteilung der zu analysierenden Datenwerte nicht anpassen kann, ist damit eine schnelle und effiziente Bearbeitung verhindert.

Bei einem Unternehmensdatenbestand von vollkommener Dichte (jede moegliche Eingabenkombination enthaelt einen Wert ungleich Null) ist der Umfang des aus der Konsolidierung quer durch alle entwickelten Datendimensionen resultierenden Datenbestandes vorhersagbar. Das physikalische Schema kann in diesem Fall nur zweieinhalbmal so gross wie die Eingabedaten werden.

Bei kleineren Datenbestaenden ist es jedoch denkbar, dass die physikalische Abbildung des resultierenden Datensatzes hundertmal umfangreicher als die Eingabe ist. Daher sollte die Zugriffsgeschwindigkeit von der Reihenfolge beim Zugriff auf Datenelemente weitgehend unberuehrt bleiben und bei Modellen mit unterschiedlicher Anzahl von Datendimensionen oder wechselnden Datensatzgroessen moeglichst konstant gehalten werden.

Was konventionelle

Tools nicht koennen

Weil konventionelle statistische Analysewerkzeuge immer nur eine Dimension mit einer anderen vergleichen, ohne die eventuell zahlreichen anderen Datendimensionen zu beruecksichtigen, sind sie fuer die mehrdimensionale Datenanalyse ungeeignet. Auch wenn solche Werkzeuge alle Dimensionen gleichzeitig vergleichen koennten (was nicht der Fall ist), wuerde die resultierende Kreuzkorrelation die Groesse des Produktes aller Datendimensionen haben, also die maximale Groesse des physikalischen Schemas selbst.

Indem Olap-Werkzeuge ihre physikalischen Datenschemata dem spezifischen analytischen Modell anpassen, versetzen sie den Anwenderanalytiker in die Lage, unterschiedliche Analysen auf einfache Art zu vollziehen. Anstatt ein physikalisches Schema auf Elementen, Datensaetzen oder zweidimensionalen Tabellen aufzubauen, setzen Olap-Werkzeuge automatisch das physikalische Schema des Modells auf den Dimensionen auf.

Oft muessen Anwender gleichzeitig entweder an demselben analytischen Modell arbeiten oder verschiedene Modelle aus gleichen Unternehmensdaten erzeugen. Um als strategisch gelten zu koennen, muessen Olap-Werkzeuge einen gleichzeitigen Zugriff (Lesen und Schreiben) erlauben sowie Integritaet und Sicherheit bieten.

Die verschiedenen Aggregationsebenen mit ihren hierarchischen Konsolidierungsvorschriften stellen die Mehrheit der Eins-zu-eins- , Eins-zu-M- und sonstigen Abhaengigkeitsbeziehungen in Olap- Modellen und Applikationen dar. Daher sollte das Werkzeug aus einer solchen Struktur die notwendigen Berechnungen (innerhalb einer Dimension) selbst ableiten, ohne dass der Benutzer diese zusaetzlich definieren muss.

Andere Berechnungen, die nicht aus Hierarchiebeziehungen ableitbar sind, erfordern die Definition anhand von Formeln in einer Beschreibungssprache. Diese muss Kalkulationen und Datenbearbeitungen ueber eine beliebige Anzahl von Datendimensionen hinweg erlauben. Sie darf die Beziehungen zwischen Datenelementen nicht einschraenken oder verhindern.

Jede neue Ausrichtung von Konsolidierungspfaden ueber Spalten oder Zeilen sollte durch einen direkten Zugriff auf die Elemente des analytischen Modells gestattet sein. Menueauswahl oder lange Wege innerhalb der Benutzer-Schnittstelle verbieten sich.

Voraussetzungen

einer effektiven Analyse

Die Analyse und Praesentation von Daten ist einfacher, wenn die vergleichbaren Datenelemente,

-zeilen und -spalten so arrangiert werden, dass sie entweder nah beieinander liegen oder logisch so gruppiert sind, dass sich darin die Unternehmensstruktur widerspiegelt.

Die Berichterstellung sollte Informationen zeigen, die sich aus der Aktivierung des Datenmodells in beliebiger Richtung ergeben. Jede einzelne Zeilen-, Spalten- oder Seitenueberschrift muss darum 0 bis N Dimensionen enthalten beziehungsweise wiedergeben koennen, wobei N der Anzahl der Dimensionen des gesamten analytischen Modells entspricht. Eine beliebige Untermenge von Elementen laesst sich dabei in jeder Reihenfolge darstellen.

Untersuchungen zur Anzahl der moeglicherweise fuer analytische Modelle benoetigten Dimensionen haben gezeigt, dass gleichzeitig etwa neunzehn Datendimensionen (Grundlage war ein versicherungsstatistisches Modell) notwendig sein koennen. Daher stammt die dringende Empfehlung, dass jedes serioese Olap-Werkzeug wenigstens 15, besser noch 20 Datendimensionen innerhalb eines allgemeinen analytischen Modells unterbringen sollte. Jede dieser generischen Dimensionen innerhalb eines Konsolidierungspfades muss eine unbegrenzte Anzahl von Aggregationsebenen zulassen, die der Anwender selbst definieren kann.

Konsoldidierungsebenen

Datenkonsolidierungspfade bestehen aus Konsolidierungsschritten oder -ebenen, die in Form von Parametern definiert sind. Diese Parameter entsprechen dem Wert jeder Variablen, wobei jede Folgeebene eine hoehere Stufe der Datenkonsolidierung wiedergibt. "Unternehmen" koennte als Konsolidierungspfad die Ebenen "Geschaeftsbereich" und "Abteilung" umfassen. Daten der Ebene "Haendler" koennten auf der Ebene "Teile" verknuepft und auf jede hoehere Ebene der Geschaeftsorganisation gebracht werden.

Verwendung des englischen Originaltextes mit freundlicher Genehmigung der E.F. Codd & Associates.

Deutsche Uebersetzung: AW Technische Dokumentationen, Darmstadt, und M.I.S. GmbH, Darmstadt.

Copyright 1994 E.F. Codd & Associates und M.I.S. GmbH. Alle Rechte vorbehalten.