|
SQL Abfragen auf OLAP Cubes, Teil 1
von Frank Schneede, ORACLE Deutschland GmbH
Die Erstellung von OLAP Cubes mit dem Analytic Workspace Manager (AWM) ist in einem früheren Tipp
ausführlich behandelt worden. Wie dort
ausgeführt, enthalten die Zellen eines OLAP Cubes nahezu beliebig komplexe geschäftliche Kennzahlen, die
nach unterschiedlichen Kriterien (Hierarchien) verdichtet vorliegen. Mit den unterschiedlichsten Methoden und Werzeugen von MS Excel bis hin zu Oracle BI
Enterprise Edition können die Inhalte von OLAP Cubes ausgewertet und visualisiert werden. Die Abfragesprache, mit der auf den OLAP Cube zugegriffen wird, ist
hierbei SQL. Das SQL wird jedoch innerhalb der verwendeten Software generiert und bleibt daher dem Benutzer meistens verborgen.
Durch die Verwendung der seit Oracle 11g bekannten Cube-organized Materialized Views können eine Vielzahl von relationalen
Materialized Views ersetzt werden, die Abfragen im Datawarehouse mittels Query Rewrite beschleunigen. Cube-organized Materialized Views werden hierbei
über den OLAP Cube gelegt, ohne ein neues Objekt mit redundanten Daten zu erzeugen. Dieses Verhalten ist bereits aus der relationalen Welt mit der Verwendung
der Materialized Views on prebuilt table bekannt.
Dieser Tipp, sowie der in 14 Tagen erscheinende 2. Teil, vervollständigen das Thema OLAP in der Datenbank. Beide sind erneut ausdrücklich zum Mitmachen gedacht. Es wird gezeigt, wie das Abfragen von
OLAP Cubes über den Zugiff auf die zum OLAP Cube gehörenden relationalen Views mit Hilfe von einfachem SQL erfolgt.
Darüberhinaus wird die Steigerung der Abfrage Performance durch Query Rewrite auf eine Cube-organized Materialized View dargestellt.
Im ersten Schritt müssen die Voraussetzungen geschaffen werden, um die in diesem Tipp verwendeten SQL Statements ausführen zu können. Das geschieht,
in dem der Tipp Erstellung von OLAP Cubes leicht gemacht mit dem Analytic Workspace Manager 11g (AWM)
oder alternativ die Schritte
- Installation der Oracle Datenbank 11g mit OLAP Option
- Installation des Analytic Workspace Manager 11g
- Installation des Beispiel-Schemas
ausgeführt werden.
Abfragen der zum OLAP Cube gehörenden Views
Zusammen mit dem OLAP Cube werden im AWM eine Reihe von relationalen Views angelegt. Diese Views bilden den multidimensionalen OLAP Cube als Star Schema ab.
Hierbei entsprechen
- die Cube View der Fakten-Tabelle und
- die Dimensions- oder Hierarchie-Views den Dimensions-Tabellen
Es gibt im Gegensatz zum klassischen Star Schema jedoch zwei entscheidende Unterschiede
- Fakten-Tabellen im Star Schema beinhalten lediglich Detaildaten, während die Cube-View verdichtete Daten verschiedener Ebenen enthält
- Berechnungen in einem OLAP Cube werden jeweils als Spalten dargestellt und in der OLAP Engine der Datenbank ausgeführt
Diese Unterschiede sind wesentlich dafür, wie Abfragen auf dem OLAP Cube formuliert werden müssen. Im klassischen Star Schema werden Aggregationen mittels
einer Kombination von Aggregatfunktionen (z. B. SUM) und GROUP BY Klausel erzeugt. In einer Cube-View braucht hingegen nur die Spalte selektiert zu werden,
die das entsprechende Aggregat enthält. Es wird keine Aggregatfunktion im SELECT-Statement benötigt, da die Daten ja bereits im OLAP Cube aggregiert
vorliegen!
In der großen Mehrheit sind bei Abfragen auf OLAP Cubes folgende Schritte zu beachten
- Auswahl der Kennzahlen und Attribute der Dimensionen
- Verknüpfung der Cube-View mit den Dimensions-Views
- Einschränkung der Kennzahlen und Attribute der Dimensionen
- Verwendung der "ALL"-Filter zur korrekten Berechnung von Aggregationen für ausgeschlossene Spalten der Dimension
Zur Erläuterung dieser Funktionsweise sollen nun einige SELECT-Statements vorgestellt werden, die im Schema OLAPTRAIN ausgeführt werden. Die ausgeführten
Statements in Skriptform finden Sie hier.
Beispiel 1: Ausführung einer einfachen OLAP Cube Abfrage
In dieser Abfrage werden die nach Departments aggregierten Verkäufe einfach als Spalte abgefragt. Der Filter in der Produkthierachie wird genutzt, um die
gewünschten Produktebenen zu bekommen. Obwohl nur die Produkthierarchie im SELECT ausgewählt worden ist, müssen in der WHERE-Klausel alle anderen
Dimensionen auf höchster Hierarchieebene ("ALL%") angegeben werden, um die im OLAP Cube vorausberechneten Werte zu erhalten.
Die Aggregate werden durch die Verwendung der "ALL"-Filter in der OLAP Engine der Datenbank berechnet, das Ergebnis erscheint nahezu ohne Zeitverzug.
Die Spaltennamen werden übrigens durch OLAP auf 24 Zeichen begrenzt (das muss bei Abfragen entsprechend berücksichtigt werden).
Beispiel 2: Verwendung von Level- und Member-Conditions in einer Abfrage
Im ersten Beispiel ist lediglich die Produkthierarchie als Bedingung für die ausgewählte Ebene (Level-Condition) verwendet worden. Das zweite Beispiel soll zeigen,
dass an dieser Stelle Ebenen mehrerer Hierarchien ausgewählt werden können.
Jede Hierarchie- bzw. Dimensions-View enthält eine Spalte LEVEL_NAME. Der Wert dieser Spalte ist der Name der OLAP Hierarchieebene, die bei der Modellierung
der Dimension im AWM angelegt wurde. Über die Einschränkung dieser Spalte in der WHERE-Bedingung läßt sich die Abfrage so einschränken, dass nur die Verdichtungen
auf der gewünschten Hierarchieebene berücksichtigt werden.
Im folgenden Beispiel werden die Verdichtungen auf den Hierarchieebenen Vertriebskanal (CLASS), Abteilung (DEPARTMENT) und Quartal (CALENDAR_QUARTER)
festgelegt. Es sollen die Aggregationen für das Kalenderjahr 2007 errechnet werden.
An dieser Stelle noch einige Bemerkungen zu dem obigen Statement
- Es wurden drei der vier zur Verfügung stehenden Dimensionen ausgewählt: CHANNEL, PRODUCT, TIME
- Für jede der ausgewählten Dimensionen wurde die Hierachie-View der Dimension und die darin enthaltene Bezeichnung LONG_DESCRIPTION verwendet.
- Die Dimension GEOGRAPHY ist nicht in der Select-Liste des Statement enthalten, sondern wird nur im JOIN verwendet. Analog
zu Beispiel 1 dient die Einschränkung auf die Hierarchieebene ALL_REGIONS dann dazu, die Aggregate über die GEOGRAPHY korrekt zu berechnen.
- Die Einschränkung auf die gewünschten Ebenen (Level-Conditions) der anderen Dimensionen erfolgt über die Auswahl von
- c.level_name = 'CLASS'
- p.level_name = 'DEPARTMENT'
- t.level_name = 'CALENDAR_QUARTER'
- Auf der Dimension TIME wird der Filter t.calendar_year_long_descr = 'CY2007' (Member-Condition) gesetzt, um den gewünschten Zeitraum festzulegen. Hier werden
also bestimmte Sätze ausgewählt und nicht alle Sätze einer festgelegten Ebene.
- Durch die Kombination von Level- und Member-Condition auf der Dimension TIME wird erreicht, dass nur die Quartale des Kalenderjahres 2007 als Ergebnis
zurückgeliefert werden.
Beispiel 3: Hinzufügen von berechneten Kennzahlen
In der Cube-View werden Berechnungen in Form von Spalten zur Verfügung gestellt, wodurch die Durchführung analytischer SQL-Abfragen erheblich erleichtert wird.
Spalten für berechnete Kennzahlen erscheinen im Ergebnis vollständig ausgerechnet, die Berechnung erfolgt jedoch durch die OLAP Engine und wird über die Cube-View
angezeigt.
In dem Analytischen Workspace SALESTRACK sind nur die Kennzahlen SALES und QUANTITY direkte Kennzahlen. Alle anderen Werte sind berechnete Kennzahlen. Die OLAP Berechnungen
arbeiten problemlos über alle Aggregationsebenen, selbst wenn die zugrundeliegenden Berechnungen komplex sind. In der folgenden Abfrage werden drei berechnete
Kennzahlen (aufgelaufene Verkäufe, prozentuale Veränderung zum Vorjahr, Tendenz der Verkäufe) zu der in Beispiel 2 verwendeten Abfrage hinzugefügt
- round(s.sales_ytd) AS ytd
- round(s.sales_ytd_py_pct_chg, 2) AS ytd_py_pct_chg
- how_is_sales_ytd
Diese Kennzahlen werden in der OLAP Engine berechnet und über die Cube-View bereitgestellt.
Beispiel 4: Verwendung unterschiedlicher Gesamtsummen in einer OLAP Cube Abfrage
Im OLAP Cube werden Gesamtsummen auf allen Aggregationsebenen der Dimensionen vorgehalten. Auf diese Weise können
in einer Abfrage unterschiedliche Ebenen dargestellt werden. Dadurch ist es in der OLAP Darstellung möglich
- unabhängig von der Aggregationsebene jede beliebige Dimension auszuwählen
- komplexe Berechnungsregeln (z. B. Bildung eines Saldo) in der OLAP Engine automatisch aufzulösen
Im folgenden Synstaxbeispiel wird die bereits bekannte Abfrage so erweitert, dass die Werte dreier Ebenen
(Monat, Quartal, Kalenderjahr) ausgegeben werden.
Man sieht hier, dass eine Member-Condition über mehrere Ebenen in der TIME Dimension angewendet wird,
also t.long_description in ('CY2007', 'Q3-CY2007', 'Nov-2007').
Beispiel 5: Ausführung einer drill-down Abfrage
Durch die Dimensionshierarchien innerhalb des Datenmodells ist es möglich, ein drill-down durchzuführen,
also die Child-Datensätze abzufragen, die zu einem bestimmten Parent-Datensatz gehören. Ein drill-down kann
in jedem Typ von Hierarchie ausgeführt werden, unabhängig davon, ob diese Hierarchie z. B. aus aufeinander
aufbauenden Ebenen besteht oder die Ebenen unabhängig voneinander sind.
In diesem Beispiel wird die obige Abfrage mit einem drill-down auf den Dimensionen PRODUCT und GEOGRAPHY
erweitert
- drill-down auf ALL_PRODUCT liefert alle Child-Daten, also die Sätze auf der Ebene DEPARTMENT
- drill-down auf ALL_REGIONS liefert alle Child-Daten, also die Sätze auf der Ebene REGION
- in der Hierarchie CHANNEL wird weiterhin die oberste Aggregationsebene verwendet und nicht
auf die Sätze der Ebene CLASS zugegriffen
Einige Anmerkungen zu der Abfrage in diesem Beispiel
- Die Hierarchie GEOGRAPHY wird in der SELECT-Liste verwendet, die Hierarchie CHANNEL hingegen nicht. Aus diesem
Grund muss die CHANNEL Dimension mit der "ALL_CHANNELS" Bedingung versehen werden.
- Der drill-down auf der Dimension GEOGRAPHY wird ausgeführt, indem der Wert der Spalte PARENT in der
Hierarchie-View abgefragt wird: g.parent = 'ALL_REGIONS'
- Der drill-down auf der Dimension PRODUCT wird ausgeführt, indem der Wert der Spalte PARENT in der
Hierarchie-View abgefragt wird: p.parent = 'ALL_PRODUCTS'
Beispiel 6: Verwendung von Parametern zum drill-down
Eine Parametrisierung des drill-down kann über einen Substitutions-Parameter sehr einfach umgesetzt werden. In der folgenden
Abfrage wird der Substitutions-Parameter genutzt, um einen gültigen Wert für die Dimension TIME eingeben zu können.
Einige Anmerkungen zu der Abfrage in diesem Beispiel
- Die Hierarchie GEOGRAPHY wurde entfernt, dafür wurde die Dimension CHANNEL eingefügt. Daher muss eine
"ALL_REGIONS" Bedingung für die Dimension eingesetzt werden.
- Der drill-down auf den Dimensionen CHANNEL und PRODUCT erfolgt wie bereist oben beschrieben.
- Zusätzlich wird ein parametrisierter drill-down auf der TIME Dimension durchgeführt. Um Fehler abzufangen,
wird die Funktion nvl benutzt, die sicherstellt, dass mindestens der Wert "ALL_YEARS" als Parent verwended wird.
Die Abfrage zeigt die Aggregation für alle Kalenderjahre im OLAP Cube, da der Parameter den Wert NULL hat und somit
"ALL_YEARS" als Einschränkung der TIME Dimension angenommen wird. Für das Jahr 2005, das das erste Jahr im OLAP Cube ist,
gibt es keine Vorjahreswerte. Aus diesem Grunde sind die auf YTD basierenden Berechnungen leer.
Im letzten Beispiel wird als Wert für den Substitutionsparameter CY2007 angenommen, so dass das Ergebnis dann alle
Child-Datensätze enthält, hier also die einzelnen Quartale des Kalenderjahres 2007.
Im zweiten Teil dieses Community-Tipps, der schon in 14 Tagen erscheinen wird, erfahren Sie, wie Cube-oriented Materialized Views eingerichtet werden. Weiterhin wird anhand von Beispielen
gezeigt, wie durch deren Einsatz die Abfrageperformance gesteigert werden kann.
Zurück zur Community-Seite
|