Data Warehouse Technologien

fügen eines neuen Tupels. Auch lassen sich vorberechnete Aggregate sehr ein-

fach behandeln, da nur auf die entsprechende Dimensions-ID verwiesen werden

muss. Nachteilig ist jedoch die Ausführung von Selbstverbunden beim Zugriff

auf höhere Stufen.

Beide Varianten können auch kombiniert werden, indem zum Einen alle

Klassifikationsstufen als Spalten repräsentiert werden – dabei jedoch mit ei-

nem generischen Bezeichner – und zum Anderen auch die höheren Stufen als

eigenes Tupel gespeichert werden. Damit eindeutig erkennbar ist, welche Stufe

der Klassifikationshierarchie von einem Tupel repräsentiert wird, ist wiederum

ein Stufe-Attribut analog dem Vorgehen bei der Verwaltung von Summentabel-

len in Abschnitt 3.3.5 einzufügen.

3.3.7 Vermeidung von Semantikverlusten

Die oben beschriebenen Abbildungen auf das relationale Datenmodell sind lei-

der mit einem Verlust an Semantik verbunden, da das Relationenmodell nur

Relationen kennt. Konkret ist es ohne Wissen über das multidimensionale

Schema und die Bedeutung der Attribute nur schwer oder nicht eindeutig mög-

lich:

• zwischen Kennzahlen und Dimensionen als Attribute der Faktentabelle zu

unterscheiden,

• die Rolle der Attribute von Dimensionstabellen (beschreibend oder zum

Aufbau der Hierarchie) zu identifizieren,

• den Aufbau der Dimensionen (Drill-Pfade) zu erkennen.

Der einzige Ausweg besteht daher in der expliziten Bereitstellung entspre-

chender Informationen bzw. in der Erweiterung des Systemkatalogs um Me-

tadaten für multidimensionale Anwendungen. Ein Beispiel hierfür ist die

CREATE DIMENSION-Anweisung von Oracle, die im Folgenden kurz vorgestellt

wird.

SQL bietet bekanntlich die Möglichkeit, funktionale Abhängigkeiten vom

Primärschlüssel sowie Fremdschlüsselbeziehungen durch Integrationsbedin-

gungen auszudrücken. Was jedoch nicht möglich ist, ist die Spezifikation von

funktionalen Beziehungen zwischen Attributen innerhalb einer Dimension. Ge-

nau hier setzt die Oracle-Erweiterung CREATE DIMENSION an: Mit dieser Anwei-

sung können die Struktur einer Dimension und insbesondere die Abhängigkei-

ten zwischen den Attributen definiert werden. Allerdings handelt es sich nicht

um eine echte Integritätsbedingung sondern nur um eine informative Zusiche-

rung. Dies bedeutet, dass die Korrektheit der Daten bezüglich dieser Zusiche-

rung vom DBMS nicht überprüft wird. Oracle nutzt die Informationen nur zum

Umschreiben von Anfragen über materialisierten Sichten (siehe Kapitel 8).

3.3 Relationale Umsetzung 65

Der Aufbau einer Dimensionsspezifikation mit CREATE DIMENSION ist wie

folgt:

CREATE DIMENSION DimName

LEVEL Stufe IS (Tabelle.Spalte) ...

HIERARCHY HierarchyName (AttribName CHILD OF AttribName CHILD OF ...)

ATTRIBUTE AttribName DETERMINES (SpaltenListe)

Die Schlüsselworte haben im Einzelnen folgende Bedeutung:

• LEVEL: definiert eine Klassifikationsstufe durch den Namen der Stufe und

den Verweis auf das Attribut der Dimensionstabelle

• HIERARCHY: ermöglicht die Festlegung einer Hierarchie mit den Abhängig-

keiten der Klassifikationsstufen über CHILD OF-Paare

• ATTRIBUTE ... DETERMINES: definiert Abhängigkeit zwischen Klassifikati-

onsattribut und dimensionalen Attributen.

Betrachten wir dazu zwei konkrete Beispiele – die Definition der Produkt-

Dimension unseres Beispielszenarios. Zunächst soll diese Dimension für das

Star-Schema aus Abbildung 3.13 spezifiziert werden:

CREATE DIMENSION ProduktDimension

LEVEL Artikel IS (Produkt.P

_

ID)

LEVEL Produktgruppe IS (Produkt.P

_

PGruppe

_

ID)

LEVEL Produktkategorie IS (Produkt.P

_

Produktkategorie)

HIERARCHY ProduktHierarchie (

Artikel CHILD OF

Produktgruppe CHILD OF

Produktkategorie)

ATTRIBUTE Artikel DETERMINES (P

_

Bezeichnung, P

_

Verkaufspreis,

P

_

Einkaufspreis, P

_

Rabatt, P

_

Steuern)

ATTRIBUTE Produktgruppe DETERMINES (P

_

Produktgruppe)

Während die Dimensionsdefinition für ein Star-Schema sehr einfach ist, da sich

alle Attribute auf eine Tabelle beziehen, muss für ein Snowflake-Schema der

notwendige Verbund für den Übergang zur nächsten Hierarchiestufe explizit

angegeben werden. Hierzu gibt es eine JOIN KEY-Klausel, deren Anwendung

im folgenden Beispiel zu unserem Schema aus Abbildung 6-8 illustriert ist:

CREATE DIMENSION ProduktDimension

LEVEL Artikel IS (Produkt.P

_

ID)

LEVEL Produktgruppe IS (Produktgruppe.PG

_

ID)

LEVEL Produktkategorie IS (Produktkategorie.PK

_

ID)

66 3 Modellierung von Data Warehouses