Universität Karlsruhe (TH)Fakultät für Informatik

Institut für Programmstrukturen undDatenorganisation (IPD)

Hauptseminar

Imperfektion und erweiterte Konzepte im DataWarehousing

Fortgeschrittene OLAP Analysemodelle

Seminararbeit

von

Jens Kübler

Sommersemester 2005

Inhaltsverzeichnis

Abbildungsverzeichnis iii

7 Fortgeschrittene OLAP-Analysemodelle 1

7.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17.2 Datenmodelle und Modellierung von Systemen . . . . . . . . . . 2

7.2.1 Systemmodelle . . . . . . . . . . . . . . . . . . . . . . . . 27.2.2 Datenmodelle . . . . . . . . . . . . . . . . . . . . . . . . . 3

7.3 Klassi�kation nach Codd . . . . . . . . . . . . . . . . . . . . . . 37.3.1 Kategorisches Modell . . . . . . . . . . . . . . . . . . . . 47.3.2 Exegatives Modell . . . . . . . . . . . . . . . . . . . . . . 47.3.3 Kontemplatives Modell . . . . . . . . . . . . . . . . . . . 57.3.4 Formalisiertes Modell . . . . . . . . . . . . . . . . . . . . 7

7.4 Datenmodelle in der Implementierung . . . . . . . . . . . . . . . 97.4.1 Vorbemerkungen . . . . . . . . . . . . . . . . . . . . . . . 97.4.2 Kategorisches Modell und OLTP-Datenmodelle . . . . . . 97.4.3 Exegatives Modell und Data Warehouses . . . . . . . . . 107.4.4 Kontemplatives Modell für fortgeschrittene Analysefunk-

tionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107.4.5 Formalisiertes Modell für abstrakte Analysen . . . . . . . 11

7.5 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Literaturverzeichnis 15

i

Abbildungsverzeichnis

7.1 Kategorisches Modell . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47.2 Exegatives Modell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57.3 Kontemplatives Modell . . . . . . . . . . . . . . . . . . . . . . . . . . . 67.4 Formalisiertes Modell . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

iii

Jens Kübler

7Fortgeschrittene

OLAP-Analysemodelle

In dieser Seminararbeit werden die von Codd spezi�zierten OLAP Datenmo-dellklassen für unterschiedliche Analysebedürfnisse vorgestellt und mit formalenGrundlagen in Verbindung gebracht. Hierzu werden Systeme und deren Modellie-rung herangezogen, um abzugrenzen, welches Informationsbedürfnis der Analystbefriedigen will. Basierend auf diesen De�nitionen wird eine marktübliche Daten-bank analysiert und die vorhandenen Operationen den einzelnen Klassen zugeord-net. Abschlieÿend wird eine Bewertung der Operationen vorgenommen, inwieferndiese die vorangegangenen De�nitionen erfüllen.

7.1 Einleitung

Nachdem in den vergangenen Dekaden die performante Speicherung und Abfragevon Daten in der Forschung groÿe Beachtung fand, entstand darauf aufbauendder Bedarf, die kumulierten Daten nicht nur für den aktuellen Betrieb zu ver-wenden, sondern die Datenbestände temporär zu analysieren. Die Begri�e �OnlineTransactional Processing� (OLTP) und �Online Analytical Processing� (OLAP)identi�zieren diese Themenbereiche, deren Datentypen, Algebren und respektiveAnfragesprachen durch so genannte Datenmodelle repräsentiert werden.So hat sich für OLTP überwiegend ein relationales also tabellenbasiertes Mo-

dell etabliert, während sich für OLAP auf logischer Datenspeicherebene ein sogenannter Data Cube durchgesetzt hat, der Daten in beliebig vielen endlichen �Di-mensionen� speichert.Aufgrund des inhärenten Datenumfangs der Data Cubes, ist der Bedarf entstan-

den, nicht nur Einblick in diese Cubes zu gewinnen, sondern automatisch Informa-

1

7 Fortgeschrittene OLAP-Analysemodelle

tionen aus dem Datenbestand zu extrahieren und für den Benutzer aufzubereiten.Dieser Vorgang wird als �Data Mining� bezeichnet, der Ähnlichkeiten mit dem For-schungsgebiet des maschinellen Lernens aufweist, jedoch eine andere Zielsetzunghat. Aufgrund der automatischen Synthetisierung von Daten zu Informationenlässt sich �Data Mining� klar zu OLAP abgrenzen, da bei OLAP bereits Basisin-formationen vorhanden sind, die der Analytiker konkretisieren will, während bei�Data Mining� keine Informationen, sondern lediglich Daten als Basis vorliegen.Nachfolgend wird darauf eingegangen, welche Basisinformationen dem Analytikerbereits vorliegen und welche Informationen er zu extrahieren wünscht.Die folgende Ausarbeitung beschäftigt sich in Kapitel 7.2 mit der formalen Mo-

dellierung von Systemen, die hilft, die in Kapitel 7.3 vorgestellten Analysemodelle,zu di�erenzieren. Weiterhin werden in diesem Kapitel Datenmodelle kurz einge-führt und deren Komponenten erläutert. Kapitel 7.3 stellt die Codd'schen Da-tenmodellklassen vor und erläutert die unterschiedlichen Anforderungen bezüglichmöglicher Analysen. In Kapitel 7.4 wird ein aktuelles Datenbanksystem hinsicht-lich der vorgestellten Datenmodellklassen analysiert. Abschlieÿend wird in Kapitel7.5 eine Bewertung der vorgestellten Implementierung bezüglich der De�nitioneneingegangen.

7.2 Datenmodelle und Modellierung von Systemen

Die nach [CCS] spezi�zierten Datenmodellklassen haben keine formale Grundlage,weshalb im folgenden erst auf Systeme und dann auf Datenmodelle eingegangenwird. Die folgende De�nitionen bezüglich Systemen sind aus [Han05] entnommen.

7.2.1 Systemmodelle

Ein System besteht aus einer Eingabe, einem Modell und einer Ausgabe. Die Ein-gabe uk ist im Allgemeinen mehrdimensional, wobei k der Zeitpunkt der Eingabeist und im Kontext von Datenbanken diskret ist. Das Modell besteht aus der Sys-temgleichung,

xk = ak(xk−1, uk, ωk) (7.1)

die den aktuellen Zustand des Systems aus den vorangegangenen Zustand xk−1,den aktuellen Eingaben uk und den Systemstörungen ωk berechnet. Ist der Zu-stand eines Systems von auÿen nicht zugänglich, wird eine Messung einer Gröÿedurchgeführt, die im Allgemeinen nichtlinear von dem Systemzustand abhängt. DieMessung ist durch

yk = hk(xk, vk) (7.2)

gegeben, wobei yk das Ergebnis der Messung, xk den aktuellen Systemzustand undvk die Messstörung beschreibt . Ein Schätzer erhält als Eingaben uk und yk undrekonstruiert aus diesen den geschätzten Systemzustand xk, wobei die Schätzungsich allgemein nicht auf zukünftige Zustände xk+t, t > 0 beschränkt, sondern auchvergangene Zustände xk−t, t > 0 als Schätzergebnis haben kann.

2

7.3 Klassi�kation nach Codd

Von dieser allgemeinen De�nition lassen sich einige Spezialfälle ableiten. Diefunktionale Abhängigkeit kann generell in lineare und nicht-lineare Abhängigkei-ten unterteilt werden, von denen ein groÿer Teil in Tabelle 7.1 zu �nden ist. Desweiteren kann die Systemgleichung unabhängig von dem letzten Systemzustandsein wie auch Beispiel 7.3.3 illustriert.

ak(xk−1, uk, ωk) = ak(uk, ωk). (7.3)

Dies ist als statisches System de�niert im Gegensatz zu dynamischen Systemen, beidenen der aktuelle Systemzustand xk von vergangenen Zuständen xk−t, t > 0 ab-hängt. Weitere mögliche Spezialfälle sind beispielsweise das Fehlen von Störungen,die ebenfalls in Beispiel 7.3.3 dargestellt wird.

7.2.2 Datenmodelle

Datenmodelle bestehen aus Datentypen und Operationen. Die Operationen wer-den über die Datentypen ausgeführt. Datentypen re�ektieren die mathematischeStruktur eines Datums. Datenoperationen lassen sich zum einen nach ihrem Ver-wendungszweck in Datende�nitionssprache (DDL: CREATE), Datenanfragespra-che (DQL: SELECT), Datenmodi�kationssprache (DML: INSERT, UPDATE, DE-LETE) und Datenkontrollsprache (DCL: COMMIT, ROLLBACK, SAVEPOINT)und zum anderen mathematisch in arithmetische, ordnende, mengenbezogene, lo-gische und vergleichende Operationen einteilen. Durch die De�nition der einzelnenDatensprachen ergibt sich die logische Struktur der Speicherung und des Zugri�sauf das Datenmodell. Bekannte logische Datenmodelle sind beispielsweise das rela-tionale Datenmodell oder das objektorientierte Datenmodell. Die darunter liegendephysikalische Speicherung der logischen Datenstruktur ist im Rahmen dieser Arbeitnicht von Bedeutung.

7.3 Klassi�kation nach Codd

Nach [CCS] wird nach der Synthese von Daten zur Information, die Informationwiederum analysiert. Es existiert eine statische und eine dynamische Analyse, wo-bei statische Analysen auf historischen Daten beruhen, die keiner Veränderungbedürfen, während dynamische Analysen Veränderungen und Modellierungen er-möglichen. Grundlage für Analysen in Datenbanken sind nach [CCS] Datenmodelle,die sich in vier unterschiedliche Kategorien einteilen lassen. Diese Modelle werdennachfolgend eingehend erläutert und der Bezug zu Systemen wird hergestellt. Wei-terhin wird zur Verdeutlichung der Modellklassen eine Zinsrechnung als Beispielangeführt. Bei den folgenden Diagrammen wird darauf hingewiesen, dass dieseim Kontext von Datenbanken zu sehen sind, das heiÿt, dass die Eingaben sowiedie Ausgaben, soweit in der jeweiligen Klasse vorhanden, üblicherweise aus einerDatenbank entstammen oder dort gespeichert werden.

3

7 Fortgeschrittene OLAP-Analysemodelle

7.3.1 Kategorisches Modell

Das kategorische Modell dient der Extraktion eines Datums aus der Datenbank zueinem bestimmten Zeitpunkt k. Bezogen auf Systemmodelle besteht also das In-formationsbedürfnis in Ausgaben yk oder Eingaben uk mit unterschiedlichem aberfestem Zeitschritt k und festen Ein- und Ausgaben. Die Ergebnisse der Anfragelassen sich aufgrund ihrer einfachen Dimensionalität als Tabellen darstellen wie dieAbbildung 7.1 verdeutlicht.

Abbildung 7.1: Kategorisches ModellAnfragen, bei denen einzelnen Eingaben einzelne Ausgaben zugeordnet sind. Für

jedes Tupel der Eingabe, erhält der Analyst ein Tupel der Ausgabe, ohneMöglichkeit das Systemverhalten aus der Datenbank zu extrahieren.

Beispiel 7.3.1 Gegeben seien als Eingaben uk ein Zinssatz uk1 und ein Startkapi-tal uk2 sowie der resultierende Endbetrag dieser Zinsrechnung als Ausgabe yk. DerAnalytiker ist in diesem Datenmodell nur an den beiden Systemkomponenten Ein-gaben und Ausgaben interessiert. Eine De�nition des zugrunde liegenden System-modells ist im Beispiel 7.3.3 zu �nden. Die Abfragen gestalten sich in der Form,das der Analyst einzelne uk und yk aus der Datenbasis extrahiert, was sich im re-lationalen Modell üblicherweise durch Selektion einzelner Attributwerte realisierenlässt.

7.3.2 Exegatives Modell

Das exegative Modell erweitert das kategorische Modell um Detaillierungsgrade,wie in Abbildung 7.2 dargestellt. Diese umfassen einerseits die zeitliche Au�ösung,sowie andererseits die Datengranularität. Der Analytiker erhält durch das Daten-modell die Möglichkeit, die Dimensionalität der Eingaben uk sowie der Ausgabenyk zu erhöhen oder zu reduzieren und dadurch Einsicht in Vorgänge zu erlangen.Auÿerdem können die zeitlichen Einteilungsschritte k aufgespalten oder zusammen-gefasst werden, so dass zeitliche Abläufe und Abhängigkeiten in einem höherenMaÿe nachvollzogen werden können. Dies ist in der Literatur[HK01] unter demBegri� der Hierarchieebenen bekannt. Operationen, die multidimensionale Sich-ten aufgrund von einem inhärenten Datenbankschemata dynamisch erzeugen und

4

7.3 Klassi�kation nach Codd

Hierarchieebenenwechsel durchführen, sind Bestandteil dieses Datenmodells underlauben dem Analytiker neue Datenassoziationen zu knüpfen und zu untersuchen.Diese Operationen grenzen das exegative Modell von dem kategorischen Modell ab.Die Anfragen zielen dementsprechend auf multidimensionale Mengen von Ein- undAusgaben, anstatt auf einzelne Werte im Datenbestand, wie dies im kategorischenModell der Fall ist. Die dem System zugrunde liegende Gleichung ak ist in diesemDatenmodell wie auch im kategorischen Modell nicht Ziel der Anfrage.

Abbildung 7.2: Exegatives ModellMultidimensionale Abfrage von Ein- und Ausgaben, die auch hier nichtdargestellte Zerlegungsoperationen und Aggregationen beinhaltet.

Beispiel 7.3.2 Das Beispiel 7.3.1 lässt sich durch marginale Änderungen an dieexegativen Anforderungen anpassen. Die Einführung einer Hierarchieebene für dieZeit in Form von Tag, Monat und Jahr ermöglicht es dem Analysten zusammenmit den entsprechenden Hierarchie-Operatoren die Zeitschritte für die Eingaben uk

und die Ausgaben yk di�erenziert oder aggregiert darzustellen und so beispielsweiseEinsicht in Zinsveränderungen und resultierende Ergebnisänderungen zu erlangen.Existieren im Datenbestand mehrere Banken mit unterschiedlichen Zinssätzen, solässt sich eine neue Dimension Banken einführen und deren unterschiedliche Zins-entwicklung nachvollziehen. Diese Daten sind im kategorischen Modell nicht gleich-zeitig visualisierbar, können im exegativen Modell jedoch dynamisch erzeugt und beiBedarf auch materialisiert werden.

7.3.3 Kontemplatives Modell

Das kontemplative Modell besteht aus zwei Kernkomponenten. Dem Analytikerwird die Möglichkeit gegeben ein System durch Systemgleichungen zu beschreibenund Modi�kationen am Eingabevektor vorzunehmen.

Eingabevektor

Dem Eingabevektor können im kontemplativen Modell Varianzen hinzugefügt wer-den. Für numerische Werte lassen sich beispielsweise Standardabweichungen undSchwerpunkte de�nieren, für kategorische Werte kann dies durch Unscharfe Men-gen realisiert werden.

5

7 Fortgeschrittene OLAP-Analysemodelle

Systemgleichung

Die Systemfunktion ak(xk−1, uk, ωk) unterliegt allgemein zeitlichen Änderungen(k) und erzeugt daher zeitlich unterschiedliche Systemverhalten. Weiterhin kannder Analyst Störungen ωk in der Systemfunktion spezi�zieren, die beschriebendurch k ebenfalls zeitlichen Änderungen unterliegen. Die Möglichkeit zur Angabemultipler Systemfunktionen ak zur Evaluation unterschiedlicher Modelle ist demAnalysten in diesem Datenmodell zusätzlich gegeben (s. Abbildung 7.3). Der Zu-stand xk, den die Systemfunktion ak berechnet, ist im Allgemeinen mehrdimensio-nal und beschreibt durch einen Vektor von Zuständen den Systemzustand [Han05].

Ausgaben

Die Ausgaben können Varianzen aufweisen, die durch die Systemgleichungen, denEingabevektor oder einer Kombination aus beiden Gröÿen rühren. Im Zentrum derAnalyse stehen somit die Ausgaben, die das gegebene Modell bei gegebenen Ein-gaben erzeugt. Dieses Datenmodell eignet sich daher insbesondere zur De�nitionund Anfrage an Schätzer, die zukünftige Zeitschritte k prädizieren.

Abbildung 7.3: Kontemplatives ModellMehrere Modelle werden mit unterschiedlichen Eingaben evaluiert. Die

resultierenden Ergebnisse stehen dem Analysten zur Verfügung.

Beispiel 7.3.3 Das den Beispielen 7.3.1 und 7.3.2 zugrunde liegende Systemmo-dell ist für feste k durch folgende Systemfunktion (siehe Gleichung 7.1) gegeben.

ak(xk−1, uk, ωk) = u1k ∗ u2k + u1k (7.4)

6

7.3 Klassi�kation nach Codd

Das Startkapital wird mit dem Zinssatz multipliziert, das Startkapital nochmals ad-diert und der Endbetrag als neuer Systemzustand xk gesetzt. Da in diesem Beispielunterstellt wird, dass das Zinsergebnis nicht von vorangegangen Zinsrechnungen, re-präsentiert durch xk−1, abhängt, kommt dieser Term nicht auf der rechten Seite derGleichung vor, da dieser 0 ist. Da weiterhin das System als ungestört angenommenwerden kann, sind die Systemstörungen ωk = 0, wie auch die Messungsstörungenvk = 0 sind, was in der folgenden Messfunktion (siehe Gleichung 7.1) resultiert.

hk(xk, vk) = xk (7.5)

Dadurch entspricht die Ausgabe yk dem Systemzustand xk.

7.3.4 Formalisiertes Modell

Das formalisierte Modell dient der Suche nach möglichen Systemverhalten oderEingaben. Die Spezi�kation nach [CCS] liefert keine exakte Beschreibung dieserModellklasse. Die Namensgebung legt nahe, dass das Systemmodell ak formal be-schrieben wird und eine mögliche Implementierung gesucht wird. Die De�nitionnach [CCS] beschreibt eine Ausgabe y und einen Startpunkt, wodurch der Ana-lytiker Einsicht in Eingaben u und Verhaltensweisen a des Modells gewinnen soll,jedoch ist der Startpunkt nicht näher de�niert. Da sowohl die Eingaben als auch dasModellverhalten gesucht werden, ist nicht exakt zu schlieÿen, ob der Startpunkt eininitialer Eingabevektor oder ein initiales Systemverhalten darstellt. UnvollständigeEingabevektoren oder Systemgleichungen könnten übergeben werden und würdeneine Suche nach möglichen Ergänzungen zur Folge haben, um die spezi�zierte Aus-gabe zu erreichen.Ohne dass diese explizit in [CCS] genannt werden, erfüllen Regressionsanalysen

[reg] diese Forderungen. Das Ziel von Regressionsanalysen ist es, eine Approximati-onsfunktion ak einer Funktion ak zu �nden, die optimal bezüglich eines Gütemaÿesist, wobei häu�g die Methode der kleinsten Quadrate als Gütemaÿ verwendet wird[reg].

ak = ak + R (7.6)

Die Parameter, die die funktionalen Abhängigkeiten zwischen den Ausgaben yk

und den Eingaben uk konditionieren und als Ergebnis der Regressionsanalyse zurVerfügung stehen, können als die fehlende Eingaben interpretiert werden, nachdenen der Analytiker unter anderem sucht. Da die funktionalen Abhängigkeitender Eingaben und Ausgaben beispielsweise linear, exponentiell, polynominiell oderlogarithmisch sein können, gilt es auch unter der Klasse der möglichen Abhängigkei-ten eine optimale Approximation zu �nden, was wiederum durch die Minimierungdes Fehlers zu erreichen ist (s. Abbildung 7.4).

Beispiel 7.3.4 Bei der Zinsrechnung aus den Beispielen 7.3.1 und 7.3.2 reduzie-ren wir den Eingabevektor um den Zinssatz, so dass lediglich unser Startkapitaluk1 und unser Endbetrag yk zur Verfügung stehen. Gegeben seien nun zwei Mengen

7

7 Fortgeschrittene OLAP-Analysemodelle

Abbildung 7.4: Formalisiertes ModellVorhandene Ein- und Ausgaben werden verwendet, mehrere Modelle zu

evaluieren aus denen ein optimales Modell bezüglich eines Gütemaÿes hervorgeht.Ein- und Ausgaben sind beliebig dimensioniert.

von uk1 und yk, die gleich mächtig sind und zwischen denen bei unserem Zinsmo-dell o�ensichtlich nur eine Abhängigkeit zwischen gleichen Zeitschritten k besteht.Wenden wir auf dieses Modell die Regressionsanalyse an, sollte sich im Fall vongleichbleibenden Zinssätzen eine lineare Approximation der Form

yk = a · uk1 + b (7.7)

als optimal erweisen, wobei a der fehlende Zinssatz ist und b = 0. . Die Approxima-tion würde sich in diesem Fall auch als tatsächliche Systemfunktion herausstellen,was einem Fehler in Gleichung 7.6 von R = 0 entspricht.

Das vorangegangene Beispiel o�enbart, das aufbauend auf dem gewonnenen Sys-temverhalten ein Schätzer beschrieben durch die Parameter a und b konstruiertwerden kann, der wiederum im Kontext des kontemplativen Modells zur Anwen-dung kommt und Ausgaben yk berechnet.

8

7.4 Datenmodelle in der Implementierung

7.4 Datenmodelle in der Implementierung

7.4.1 Vorbemerkungen

Von Codd'schen Modellklassen zur Implementierung

Die Codd'schen Modellklassen sind in der Implementierung nicht exakt voneinan-der zu trennen, da aus Benutzersicht eine Konvergenz oder sogar eine Inklusionder Modellklassen zwecks Bedienungskomfort wünschenswert ist. Das Erlernen un-terschiedlicher Datentypen mit zugehörigen Anfragesprachen ist für den Benutzerzu aufwändig, wie auch die Kosten für die Entwicklung klassenkonformer Daten-modelle in keinem Verhältnis stehen.

Implementierungsbeispiel Oracle

Neben Microsoft SQL Server, IBM DB2 oder Informix und Sybase ist Oracle ei-nes der groÿen Enterprise Datenbank Management Systeme (DMBS), das wie dieanderen DBMS mit einem reichhaltigen Angebot an Funktionen aufwartet. AlleDatenbanksysteme hier bezüglich der implementierten Operationen vorzustellenübersteigt den Rahmen dieser Ausarbeitung, weshalb lediglich Oracle als Beispie-limplementierung nicht zuletzt wegen der umfangreichen einfach zugänglichen Do-kumentation näher betrachtet wird. Aufgrund der groÿen Verbreitung des relatio-nalen Modells und produktabhängigen Erweiterungen werden andere Datenmodel-le, wie zum Beispiel das objektorientierte, hier nicht nähergehend bezüglich derenAnalyseoperationen betrachtet.Neben der Datenbank bietet Oracle ein zusätzliches OLAP-Modul, welches auf

der bestehenden Datenbankengine aufsetzt, jedoch zusätzlich ein eigenes Daten-modell implementiert, welches den speziellen Anforderungen für Analysen gerechtwird. Für die nachfolgenden Abgrenzungen werden soweit nötig nur die Funktionender Kern-Datenbankengine nähergehend erläutert, da diese in den Hauptfunktio-nen quantitativ denen des OLAP-Moduls entsprechen und sich die Komplexitätder Parameter und Optionen nicht so hoch darstellt, wie das im OLAP-Modulder Fall ist. Lediglich im formalisierten Modell werden Funktionalitäten aus demOLAP-Modul vorgestellt, die in der Kerndatenbank nicht zur Verfügung stehen.Für eine detaillierte Beschreibung des OLAP-Moduls konsultiere man die verschie-denen Oracle OLAP Referenzbücher [Orad].

7.4.2 Kategorisches Modell und OLTP-Datenmodelle

Aufgrund der niedrigen Anforderungen an die Analyse ist dieses Datenmodell inhä-rent durch bestehende OLTP-Systeme gegeben. ORACLE bietet gängige SQL99 -Datentypen wie zum Beispiel INT, DOUBLE und CHAR an und erweitert diese umeinige Spezialdatentypen, wie XMLType, die für Spezialeinsatzgebiete des Transak-tionsmodells interessant sind. Die Datenstrukturen sind auf logischer Ebene durchTabellen repräsentiert auf denen die DML-Operationen ausgeführt werden. Die zen-

9

7 Fortgeschrittene OLAP-Analysemodelle

tralen Modi�kationsoperatoren sind INSERT, UPDATE, SELECT und DELETE, die zu-sammen mit Funktionen und Ausdrücken neben Transaktionsfunktionalitäten auchkategorischen Analyseansprüchen genügen. Im Kontext dieser Modellklasse bietetORACLE Funktionen für Ränge und Perzentile, gleitende Berechnungsfenster so-wie Führungs- und Rückstandsanalysen, die ergänzend zu den in SQL üblichenanalytischen Funktionen, wie zum Beispiel Aggregationen (SUM,COUNT,STDDEV), zurVerfügung stehen. Da die detaillierte Erläuterung dieser Funktionen den Rahmendieser Ausarbeitung übersteigt, wird hier nur auf die entsprechende Oracle Doku-mentation [Oraa] verwiesen.

7.4.3 Exegatives Modell und Data Warehouses

Die Implementierung des exegativen Modells ist durch Data Warehouses als zugrun-de liegendes Datenmodell realisiert. ORACLE setzt hier aufgrund des bestehendenDatenbanksystem auf ROLAP [HK01], welches die multidimensionale Speicherungmit Hilfe von Tabellen durchführt. Star- und Snow�ake-Schemata ermöglichen demAnalytiker mit den gleichen DML-Operatoren wie im kategorischen Modell, multi-dimensionale Datenbestände zu erforschen. Die Funktionen ROLLUP und CUBE erlau-ben dem Analytiker entsprechend über Hierarchieebenen oder über DimensionenAggregationen durchzuführen. Die Sicht auf den multidimensionalen Datenbestandkann dynamisch erzeugt oder materialisiert werden, wofür die Operation CREATE

MATERIALIZED VIEW zur Verfügung steht [Orab].

7.4.4 Kontemplatives Modell für fortgeschrittene Analysefunktionen

Eingaben und Ausgaben

Da im relationalen Modell die Eingaben sowie die Ausgaben in Relationen abgelegtsind, lassen sich diese wie bei den anderen Modellklassen über gewöhnliche SQL-SELECT -Ausdrücke anfragen. Ist der Wertebereich eines Attributs kontinuierlich,so lassen sich mit der WHERE-Klausel und entsprechenden Konjunktionen vonGröÿenvergleichen für Ausgaben Bereichsanfragen stellen. Eine weitere Möglich-keit besteht beispielsweise mit Subqueries Standardabweichungen in der Domänedes Attributs zu berechnen und das Ergebnis als Bedingung der WHERE-Klauselzu übergeben. Die Eingaben können im kontinuierlichen Fall durch berechneteAttributwerte in der Selektion mit Varianzen versehen werden. Diese Funktiona-litäten sind in jeder gröÿeren SQL-Datenbank vorhanden, jedoch mangelt es derORACLE -Datenbankengine an Anfragemöglichkeiten für unscharfe kategorischeAttribute. Diese Funktionalität wurde für ältere ORACLE -Versionen durch [Gal]bereitgestellt, was jedoch keine o�zielle Erweiterung der Datenbank darstellt. NachAngaben des Autors besteht auch die Möglichkeit, die Unschärfe in den einzelnenTabellen zu hinterlegen.

10

7.4 Datenmodelle in der Implementierung

Systemmodelle

ORACLE realisiert Systemmodelle neben einer umfassenderen Erweiterung imOLAP-Modul über den SQL-Befehl MODEL, der auf multidimensionalen Daten ope-riert und einer SELECT-FROM-WHERE-Klausel folgt. Auf den ausgewählten Datenkönnen beliebig viele so genannte Regeln angewendet werden, die durch Gleichun-gen angegeben werden. Dabei können neben den umfangreichen Rechenoperationenauf den selektierten Daten auch Aggregationen ausgeführt werden. Die Erzeugungneuer Werte erfolgt wie bei vielen Programmiersprachen durch Zuweisung an eineentsprechend benannte Variable auf der linken Seite der Gleichung. Weiterhin be-steht die Möglichkeit mittels den Zusätzen UPSERT und UPDATE die Erzeugung vonWerten entsprechend zu erzwingen oder nur zu aktualisieren, wenn diese tatsäch-lich vorhanden sind.

Beispiel 7.4.1 SELECT SUBSTR(country, 1, 20) country,

SUBSTR(product, 1, 15) product, year, sales

FROM sales_view

WHERE country IN ('Italy', 'Japan')

MODEL

PARTITION BY (country) DIMENSION BY (product, year)

MEASURES (sales sales)

RULES

(sales['Bounce', 2002] = sales['Bounce', 2001]

+ sales['Bounce', 2000],

sales['Y Box', 2002] = sales['Y Box', 2001],

sales['All_Products', 2002] = sales['Bounce', 2002]

+ sales['Y Box', 2002])

ORDER BY country, product, year;

Das aus [Orac] entnommene Beispiel illustriert die Verwendung der SQL-MODEL-Klausel und berechnet aus den Jahren 2000 und 2001 unterschiedlicheneue Werte für das Jahr 2002 durch einfache Zuweisung.

7.4.5 Formalisiertes Modell für abstrakte Analysen

Das formalisierte Modell ist in der Kerndatenbank von ORACLE nur in Formeiner linearen Regression implementiert. Erweiterte Funktionalitäten wie das auto-matisierte Suchen von vorliegenden Systemverhalten ak sind jedoch im zusätzlichverfügbarem OLAP-Modul, welches eine Ergänzung der bestehenden Datenbankdarstellt, in Form von Vorhersagen vorhanden. Die Basis von Vorhersagen sindZeitreihenanalysen, denen multidimensionale Regressionsanalysen zugrunde liegen.ORACLE OLAP unterstützt folgende Regressionsmethoden im Zusammenhangmit Vorhersagen [Orae]:

Es besteht weiterhin die Möglichkeit, die Anwendung automatisch das besteRegressionsmodell �nden zu lassen.

11

7 Fortgeschrittene OLAP-Analysemodelle

Regressionsmethode mathematische Beschreibunglinear y = a · x + b

polynominiell y = c · xa

exponentiell y = c · eax

logarithmisch y = a · log(x) + b

asymptotisch y = xa+bx

exponentiell asymptotisch y = cKeax

(1+ceax)

einfache exponentielle Glättungdoppelte exponentielle Glättung

Holt / Winters Methode

Tabelle 7.1: Verfügbare Regressionsmethoden in Oracle

Dem Vorhersagemodell von ORACLE können Periodengröÿen übergeben wer-den, die im Fall der Periodengröÿe p = 1 der einfachen Regressionsanalyse ent-spricht und in den Fällen von p > 1 eine multidimensionalen Regressionsanalyseüber der Zeit ist. Durch die Angabe der Anzahl zurückliegender Perioden werdendie Eingaben und Ausgaben der Zeitschritte k de�niert, aufgrund derer das System-modell approximiert wird. Der Schätzer ist direkter Bestandteil von Vorhersagenund liefert basierend auf der ermittelten funktionalen Abhängigkeiten konkreteSchätzergebnisse. Ein zusätzliches Kommando erlaubt die ermittelten Systempara-meter (im Beispiel 7.3.4 a und b) zu extrahieren.

7.5 Fazit

In Kapitel 7.2 wurde grundlegend auf die einzelnen Bestandteile von Systemen undDatenmodellen eingegangen. Die in [CCS] nicht formal umschriebenen Datenmo-delle wurden in Kapitel 7.3 mit Systemen in Zusammenhang gebracht und anhandvon Beispielen wurden die unterschiedlichen Analysebedürfnisse illustriert. Die ver-fügbaren Funktionen des Datenbankprodukts ORACLE wurden hinsichtlich dieserModellklassen eingeordnet. Die Zusammenhänge zwischen kategorischen, exegati-ven, kontemplativen und formalisierten Datenmodellen und den entsprechendenImplementierungen des relationalen Modells, des Data Cubes, der Systemmodellie-rung und der Regressionsanalyse wurden in Kapitel 7.4 hergestellt.Zum Zeitpunkt der Verö�entlichung von [CCS] existierten laut Autor zwar viele

Datenbankprodukte, die den kategorischen Anforderungen genügten, jedoch warennur wenige oder gar keine Produkte am Markt verfügbar, die den gehobenen Mo-dellklassen genügten. Diese Darstellung entspricht nicht mehr den heutigen Gege-benheiten. Es wurde anhand eines marktüblichen Datenbanksystems gezeigt, dassexegative, kontemplative und formale Anforderungen umfassend erfüllt werden. DieMODEL-Klausel für kontemplative Analysen ist im Zusammenhang mit der umfang-reichen DML eine mächtige SQL-Erweiterung, mit der eine Vielfalt von Analysenmöglich ist. Lediglich die Modellierung und Speicherung von Unschärfe ist nicht in

12

7.5 Fazit

vollem Umfang gegeben. Die Vorhersagefunktion des OLAP-Moduls stellt wichtigeRegressionsverfahren zur Verfügung, die es erlauben Systemparameter zu extrahie-ren sowie Schätzungen durchzuführen.

13

Literaturverzeichnis

[CCS] E. F. Codd, S. B. Codd, and C. T. Salley. Providing OLAP toUser-Analysts: An IT Mandate. http://dev.hyperion.com/resource_

library/white_papers/providing_olap_to_user_analysts.pdf Letz-ter Zugri�: 5. Juni 2005.

[Gal] J. Galindo. Fuzzy SQL - A Fuzzy Query Language. http://www.lcc.

uma.es/~ppgg/FSQL.html Letzter Zugri�: 5. Juni 2005.

[Han05] Uwe D. Hanebeck. Skriptum zur Vorlesung Stochastische Informations-verarbeitung. 2005.

[HK01] Jiawei Han and Micheline Kamber. Data Mining: Concepts and Techni-ques. Morgan Kaufmann, 2001.

[Oraa] Oracle Corporation. Oracle R© Database Data Warehousing Guide, 10grelease 1 (10.1) edition. Chapter 21: SQL for Analysis.

[Orab] Oracle Corporation. Oracle R© Database Data Warehousing Guide, 10grelease 1 (10.1) edition. Chapter 8: Basic Materialized Views.

[Orac] Oracle Corporation. Oracle R© Database Data Warehousing Guide, 10grelease 1 (10.1) edition. Chapter 22: SQL for Modelling.

[Orad] Oracle Corporation. Oracle R© Documentation Library - Books, 10g Relea-se 1 (10.1) edition.

[Orae] Oracle Corporation. Oracle R© OLAP DML Reference, 10g Release 1 (10.1)edition. Chapter 1.4.5: Forecasting Programs.

[reg] Wikipedia: Regressionsanalyse. http://de.wikipedia.org/wiki/

Regressionsanalyse Letzter Zugri�: 5. Juni 2005.

15