Im Vergleich zum CUBE-Operator generiert der ROLLUP-Operator weniger Kom-
binationen: während es für n Attribute bei CUBE 2
n
Kombinationen sind,
liefert ROLLUP nur n + 1 Gruppierungskombinationen. Ein weiterer Un-
terschied ist, dass bei ROLLUP die Reihenfolge der angegebenen Attribute
wichtig ist: ROLLUP(O
_
Bundesland, O
_
Stadt) liefert ein anderes Ergebnis als
ROLLUP(O
_
Stadt, O
_
Bundesland)!
Neben der Möglichkeit, mittels CUBE und ROLLUP Gruppierungskombinatio-
nen generieren zu lassen, können mithilfe von GROUPING SETS auch Kombina-
tionen von Gruppen explizit angegeben werden. Auf diese Weise ist auch eine
feingranulare Auswahl der Gruppen möglich. Beispielsweise ist eine Gruppie-
rung der Form
GROUP BY ROLLUP(O
_
Bundesland, O
_
Stadt)
äquivalent zu
GROUP BY GROUPING SETS((O
_
Bundesland, O
_
Stadt), (O
_
Bundesland), ())
Somit lassen sich in Verbindung mit ROLLUP und CUBE beliebig komplexe Grup-
pierungen vornehmen.
5.3.3 OLAP-Funktionen in SQL:2003
Neben den erweiterten Gruppierungsmöglichkeiten und den oben eingeführten
Aggregatfunktionen sind in SQL:2003 auch eine Reihe von neuen Funktionen
speziell für die sequenzbasierte Datenanalyse verfügbar. Insbesondere in Ver-
bindung mit der fensterbasierten Partitionierung lassen sich mit diesen Funk-
tionen komplexe OLAP-Anfragen formulieren.
Die wichtigste Erweiterung ist die Möglichkeit, analytische Funktionen
(auch als OLAP-Funktionen bezeichnet) über sogenannten Fenstern auszufüh-
ren. Ein Fenster (engl. window) spezifiziert eine Folge von Tupeln mit einer
definierten Ordnung, beispielsweise die Einträge der letzten 30 Tage, wobei die
Ordnung hier durch das Datum gegeben ist. Die wesentlichen Unterschiede zur
klassischen Anwendung von Aggregatfunktionen sind, dass
Ordnung und ggf. Partitionierung der Eingabemenge attributlokal ausge-
führt werden und
die Aggregation tupelbasiert erfolgt, d.h., der Aggregatwert wird pro Tu-
pel entsprechend der Ordnung berechnet und nicht wie bei der klassischen
Aggregation für die Gesamtmenge bzw. -gruppe.
138 5 Anfragen an Data-Warehouse-Datenbanken
Auf diese Weise können in Verbindung mit Aggregatfunktionen sehr einfach
Ranking-Anfragen, Anfragen mit gleitendem Durchschnitt, kumulierten Sum-
men oder Ratio-to-Total-Anfragen formuliert werden.
JBeispiel 5-12I In diesem und den folgenden Beispielen gehen wir von einer
einfachen Relation TagesUmsatz aus, die zu jeder Produktgruppe den Tagesum-
satz enthält. Diese Relation kann zum Beispiel über folgende Sichtdefinition
erstellt werden:
CREATE VIEW TagesUmsatz AS
SELECT P
_
Produktgruppe, Z
_
Datum,
SUM(V
_
Anzahl
*
P
_
Verkaufspreis) AS Umsatz
FROM Verkauf, Zeit, Produkt
WHERE V
_
Zeit
_
Id = Z
_
Id AND V
_
Produkt
_
Id = P
_
Id
GROUP BY P
_
Produktgruppe, Z
_
Datum
2
Die Definition eines Fensters kann als Teil der Projektion oder durch ein
explizites WINDOW-Konstrukt erfolgen. In beiden Fällen gibt es folgende (optio-
nale) Teile:
eine Partitionierungsklausel PARTITION BY, die eine Aufteilung des Einga-
bestroms der OLAP-Funktion in Partitionen mit jeweils gleichen Werten
beschreibt (ähnlich GROUP BY),
eine Ordnungsklausel ORDER BY zur Spezifikation einer attributlokalen
Ordnung (ähnlich der ORDER BY-Klausel im SFW-Block von SQL),
eine Definition des Aggregatfensters, d.h. den Bereich des Eingabestroms,
auf den die Aggregation angewendet werden soll.
Bei der Notation als Teil der Projektion werden diese Komponenten im Rahmen
einer OVER-Klausel hinter einer Aggregatfunktion angegeben (Abbildung 5.6).
Funktion(arg)
Partitionierungs-
klausel
Ordnungs-
klausel
Fenster
OVER( )
Ordnung innerhalb
einer Dimension
Festlegung des
Aggregationsfensters
Partitionierung für jedes Attribut
des Ergebnisses ohne Verdichtung:
jeder Eingangswert Ergebniswert
Abbildung 5.6: Syntax der OLAP-Funktionen
5.3 SQL-Operationen für das Data Warehouse 139
Betrachten wir hierzu ein Beispiel.
JBeispiel 5-13I Auf der in Beispiel 5-12 eingeführten Sicht TagesUmsatz soll
eine Ratio-to-Total-Analyse durchgeführt werden, bei der für jeden Tag der An-
teil des Tagesumsatzes (Ratio) am Gesamtumsatz des Monats (Total) darge-
stellt ist:
SELECT Z
_
Datum, Umsatz,
100.0
*
Umsatz/SUM(Umsatz) OVER() AS Anteil,
SUM(Umsatz) OVER() AS MonatGesamt
FROM TagesUmsatz
WHERE P
_
Produktgruppe = ’Wein’ AND YEAR
_
MONTH(Z
_
Datum) = 201108
Diese Anfrage liefert folgende Ergebnisrelation:
Datum Umsatz Anteil MonatGesamt
01-AUG-2011 58 4,669 1242
02-AUG-2011 52 4,186 1242
03-AUG-2011 64 5,152 1242
04-AUG-2011 0 0,000 1242
. . .
31-AUG-2011 47 3,784 1242
. . .
2
Durch die Angabe der OVER-Klausel werden hier die Gesamtsumme
(MonatGesamt) und der Monatsanteil (Anteil) für jedes Tupel berechnet und
ausgegeben. Ohne Verwendung der OLAP-Funktionen kann dies nur mit ei-
ner geschachtelten Anfrage erreicht werden, die zunächst die Gesamtmenge
bestimmt, um dann in einer äußeren Anfrage die Anteile des jeweiligen Tages
zu berechnen:
JBeispiel 5-14I Die entsprechende klassische SQL-Anfrage zur Berechnung
der Tabelle aus Beispiel 5-12 ist:
SELECT Z
_
Datum, Umsatz,
100.0
*
Umsatz/GesamtUmsatz AS Anteil,
GesamtUmsatz AS MonatGesamt
FROM TagesUmsatz,
(SELECT SUM(Umsatz) AS GesamtUmsatz
FROM TagesUmsatz
WHERE P
_
Produktgruppe = ’Wein’ AND
YEAR
_
MONTH(Z
_
Datum) = 201108) Gesamt
WHERE P
_
Produktgruppe = ’Wein’ AND YEAR
_
MONTH(Z
_
Datum) = 201108
2
In der Anfrage aus Beispiel 5-13 wird die PARTITION BY-Klausel noch nicht
benötigt, da die Anteile bezüglich des Gesamtaggregatwertes berechnet wer-
140 5 Anfragen an Data-Warehouse-Datenbanken

Get Data Warehouse Technologien now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.