Lange Antwortzeiten bei grossen Datamarts (Teil 2) - Trivadis

Betrifft Lange Antwortzeiten bei grossen Datamarts? Dies muss nicht so sein!
Art der Info Methodische Background Info (Teil2)
Autor Karol Hajdu, Trivadis AG
Quelle Aus unserer Schulungs- und Beratungstätigkeit
Einleitung
Datamarts sind spezialisierte, auf Performance und Ergonomie optimierte Datenstrukturen, welche als
Abfragequelle für eine breite Skala von Auswertungsbedürfnissen der Endbenutzer verwendet werden.
Die Datamarts kann man als „Schaufenster“ eines Data Warehouses bezeichnen.
In dieser Artikelserie erfahren Sie einerseits, wo die Fallstricke beim Design der Datamarts liegen, und
andererseits auch die Methodik, um Designprobleme, welche zu schlechter Abfragenperformance
führen, zu vermeiden.
Die Erläuterungen werden sich an Beispielen aus der Praxis anlehnen.
Das Vorgehen der Methodik unterscheidet folgende drei Hauptphasen:
- dimensionale Modellierung (technologie-unabhängiges Modell)
- relationales Design (Umsetzung des dimensionalen Modells ins relationale Schema)
- physisches Design der DB-Objekte (erzielt die gleichmässige Lastverteilung auf HW-
Ressourcen)
In diesem Artikel finden Sie eine Untermenge der gesamten Designmethodik: nämlich die, welche
unmittelbar mit der Performance der Abfragen zusammenhängt. Ausführliche Erklärungen zur ganzen
Methodik (Ergonomie, Zugriffschutz etc.) werden am ersten Tag unseres Standard-Kurses „Data
Warehousing mit Oracle“ vermittelt.
Nach dem wir uns im vorherigen Artikel der Phase dimensionale Modellierung gewidmet haben, liegt
der Schwerpunkt vom diesen Artikel im relationalen Design.
Problemstellung
Bekanntlich ist ein relationales Schema durch Tabellen und Beziehungen gebildet. Die Umsetzung
eines dimensionalen Modells (Dimensionen und Kennzahlen) läuft somit auf ein sog. Star-Schema
hinaus (Fakttabelle mit Kennzahlen in der Mitte, verknüpft mit Dimensionstabellen).
Das Design dieser Strukturen hat folgende Zielsetzungen:
a) Verbindung zwischen Kennzahlen und Dimensionsmembers so zu gestalten, dass fürs
Herausfinden der oft abgefragten Beziehungen möglichst wenig I/O, Memory & CPU
notwendig ist
1/12

) beim Aktualisieren der Kennzahlen und Dimensionsmembers (neue Fakten zugekommen,
Eigenschaften der Members haben sich geändert) muss nur ein Minimum der gespeicherten
Daten 1 modifiziert werden
c) die zugrunde liegenden atomaren Daten sollen in solcher Form gespeichert werden, welche
ein einfaches, automatisierbares Anlegen von Indexen und gespeicherten Aggregaten 2
erlaubt
... und wo liegt das Problem?
Wie beim täglichen Leben so üblich – bei der Umsetzung :-):
Wie gehe ich konkret vor, damit ich die vorher formulierte Zielsetzung erreiche?
... leider existiert immer noch - besonders auf der Management-Ebene - die falsche Annahme, dass
jeder, der relationale Modellierung für OLTP-Systeme beherrscht, auch im Stande ist, ein gutes Star-
Schema zu entwerfen.... Die Problematik von Datamarts ist viel zu unterschiedlich zur Problematik
eines OLTP-Systems: wer sich Analogien zu bedienen versucht, kann die Dinge noch schlechter
machen.
... und warum ist diese Problemstellung so wichtig?
Es geht um die Effizienz der Informatik in Data Warehouse Projekten.
Praxisbeispiel1:
Die Reporting Plattform eines operativen CRM – liefert pro Kunde Vermögen- und Verhaltensstatistik -
ist im Unternehmen erfolgreich. Vom Management kommt ein zusätzlicher Bedarf, über diesen
Datenbestand eine strategische on-line Analyse zu machen.
Der erste Anlauf endet in einer Sackgasse: on-line Analyse (d.h. Spielen mit den Daten) ist nicht
möglich, da die Analysten nach Antwortzeiten über 10 Minuten bereits vergessen haben, wozu sie die
Frage gestellt haben ;-). Man formuliert einen Auftrag an Informatik, hier etwas zu unternehmen.
Die Informatik reagiert mit einer Aufwandschätzung, die jedes denkbare Budget übersteigt. Bestehende
Strukturen sind dazu nicht geeignet, man muss Neues entwickeln, dann dieses parallel zu dem
Bestehenden betreiben oder aufwändig migrieren. Das Business kommt nicht aus dem Stauen: dabei
wollten sie nur eine neue Art der Abfragen beschleunigen....
Praxisbeispiel2:
Eine OLAP Plattform ist im Unternehmen für ihre interessanten Analysen und schnelle Antwortzeiten
beliebt. Jetzt will man, dass auch die Leute auf der Linie diese Plattform für taktische Entscheide
benutzen.
Man geht von der Annahme aus, dass die Informatik die Detaildaten bereits besitzt (sonst wären die
OLAP Verdichtungen ja nicht möglich), und somit sollte deren Freigabe relativ kostengünstig über die
Bühne gehen.
Die Reaktion der Informatik ist etwa im gleichen Still wie in dem vorherigen Beispiel.
Nach dieser Erfahrung fragt sich das Business berechtigt, ob die Informatik im DWH–Bereich etwas von
den Software Engineering Techniken anwendet...
Und was sind denn die Engineering Techniken bei der Umsetzung des dimensionalen Modells ins
relationale Star-Schema? Schauen wir uns das genauer an.
1 Dies beinhaltet: atomare Daten, Indexe und materialized Views
2 in Oracle mit sog. Materialized Views implementiert
2/12

Relationales Star-Schema als Umsetzung des dimensionalen Modells
Es gibt eine grosse Vielfalt an Quellen, welche die Grundkonzepte der Star-Schema-Modellierung
beschreiben. In diesem Artikel werde ich hauptsachlich diejenigen Konzepte erläutern, die in diesem
Umfeld neu sind und zugleich in die Kategorie wichtig gehören.
Hier die neuen und wichtigsten Guidelines aus unserer Best-Practice:
1) Surrogate Keys everywhere – auf jeder Verdichtungsstufe
2) Joins, welche Selektivität des Einstiegs in Fakttabelle nicht erhöhen, vermeiden (no snowflaking)
3) gefragten Gültigkeitsbezug pro Verdichtungsstufe wahrnehmen
4) hohe und gleichmässige Selektivität aller Fremdschlüssel der Fakttabelle (Aggregatstabelle)
anstreben
Die nächsten Zeilen erläutern detailliert, worum es in den oben genannten Punkten genau geht.
Guideline1: Surrogate Keys everywhere – auf jeder Verdichtungsstufe
Eine Verdichtungsstufe (z.B. „Kundenstatus“) ist eine Gruppe von Dimensionsmembern („aktiv“,
„aufgehoben“, „gesperrt“), welche die Kennzahlen einer oder mehrerer Faktaussagen beschreiben.
Die Members haben neben einer eindeutigen Identifikations-Bezeichnung (member key), neben einem
Verweis auf einem Parentmember (z.B. „alle Kundenstati“) noch bspw. eine Fliesstext-Beschreibung
(member name). Die Members werden als bestimmte Attribute der Einträge einer Dimensionstabelle
implementiert.
Der Surrogate key ist eine nicht-sprechende Nummer (meistens von einer DB-Sequenz generiert),
welche eine DWH-weit eindeutige „Addresse“ eines Members 3 (genauer: seiner Version) darstellt.
Die Aufgabe von Surrogate-Keys ist inzwischen allgemein gut bekannt. Was weniger bekannt ist, dass
es durchaus Sinn macht, einen (eigenständigen) Surrogate-Key für jede Verdichtungsstufe der
Dimension zu implementieren (und nicht nur für die feinste Verdichtungsstufe, wie heutzutage üblich
der Fall ist).
Warum?
Erst konsequentes „surrogate keys everywhere“ erlaubt:
A) Hierarchie-Constraints bei „Slowly Changing Type 2“ Dimensionen zu deklarieren
B) Kennzahlen zweier Fakttabellen unterschiedlicher Granularitätsstufe ohne nennenswerten
Aufwand gegenüberzustellen
Schauen wir uns die Dinge näher an:
A) Hierarchie-Constraints bei „Slowly Changing Type 2“ Dimensionen werden möglich
Hierarchie-Constraints werden in Oracle mittels CREATE DIMENSION Befehl deklariert. Abbildung 1
stellt eine Beispielshierarchie dar. Der entsprechende Quellcode für CREATE DIMENSION Befehl ist im
Quellcodeauszug 1 zu finden.
3 oder einer Memberskombination – siehe weiter
3/12

{ }
{ }
{ }
Organisations
struktur
Organisations
struktur
Bereich
Abteilung
Mitarbeiter
Abbildung1: Beispielshierarchie in der Dimension „Organisationsstruktur“ in der ADAPT Notation
CREATE DIMENSION dim_OrgStruktur
LEVEL mitarbeiter IS DIM_ORGSTRUKTUR.MITARBEITER_NR -- NR vom HR
LEVEL abteilung IS DIM_ORGSTRUKTUR.ABTEILUNG_CODE -- CODE vom HR
LEVEL bereich IS DIM_ORGSTRUKTUR.BEREICH_CODE -- CODE vom HR
HIERARCHY hier_OrgStruktur (
mitarbeiter CHILD OF
abteilung CHILD OF
bereich )
ATTRIBUTE mitarbeiter DETERMINES
(MITARBEITER_NAME, MITARBEITER_VORNAME, MITARBEITER_GEBURTSJAHR)
ATTRIBUTE bereich DETERMINES
......
;
Quellcodeauszug1: CREATE DIMENSION Befehl zur Deklaration der Hierarchie Organisationstrukur
Die Hierarchie-Constraints dienen dazu, der „Query-Rewrite“ Erweiterung vom CBO 4 mitzuteilen, dass
sie für Abfragen auf der Stufe „Bereich“ auch solche MViews benutzen kann, welche die
Mitarbeiterkennzahlen - aggregiert auf Stufe „Abteilung“ - enthalten.
Bei “Slowly Changing Dimensionen Typ 2“ 5 braucht man nach einem Wechsel einer Abteilung (z.B.
der Abteilung “DWH-Entwicklung”) von einem Bereich zu einem Anderen beide Versionen dieser
Abteilung abzuspeichern: Eine für die Fakten vor dem Wechsel und die Andere für die Fakten danach.
(siehe Abbildung 2).
4 cost based optimizer
5 Terminologie wurde vom Ralph Kimball eingeführt, für kürze Erklärung siehe nächstes Guideline
4/12

Abbildung2: Datensätze der Dimension „dim_OrgStruktur“
Ein Hierarchie-Constraint, welcher über den Member-Keys der Stufen „Abteilung“ und „Bereich“
deklariert ist (Quellcodeauszug1), wäre nach dem Wechsel der Abteilung verletzt (Abteilung „DWH-
Entwicklung“ gehört dann zu zwei Bereichen: nämlich „INF“ und „BIC“).
Dieses Problem kann eliminiert werden, in dem man Surrogate-Keys auf jeder Stufe einführt und
anschliessend die Hierarchie-Constraints als im Quellcodeauszug 2 deklariert (die Surrogate-Keys
entsprechen der Namenskonvention „DWH_ID_“)
CREATE DIMENSION dim_OrgStruktur
/* in dieser Form unterstützt auch SCD Typ 2 */
LEVEL version_mitarbeiter IS DIM_ORGSTRUKTUR.DWH_ID_MITARBEITER -- SurrogKey
LEVEL mitarbeiter IS DIM_ORGSTRUKTUR.MITARBEITER_NR -- NR vom HR
LEVEL version_abteilung IS DIM_ORGSTRUKTUR.DWH_ID_ABTEILUNG -- SurrogKey
LEVEL abteilung IS DIM_ORGSTRUKTUR.ABTEILUNG_CODE -- HR-CODE
LEVEL version_bereich IS DIM_ORGSTRUKTUR.DWH_ID_BEREICH -- SurrogKey
LEVEL bereich IS DIM_ORGSTRUKTUR.BEREICH_CODE -- HR-CODE
HIERARCHY hier_MAversion_MA (
version_mitarbeiter CHILD OF
mitarbeiter )
HIERARCHY hier_MAversion_abteilung (
version_mitarbeiter CHILD OF
version_abteilung CHILD OF
abteilung )
HIERARCHY hier_MAversion_bereich (
version_mitarbeiter CHILD OF
version_abteilung CHILD OF
version_bereich CHILD OF
bereich )
ATTRIBUTE mitarbeiter DETERMINES
(MITARBEITER_NAME, MITARBEITER_VORNAME, MITARBEITER_GEBURTSJAHR)
ATTRIBUTE bereich DETERMINES
......
;
Quellcodeauszug 2: „CREATE DIMENSION“ zur Deklaration der Hierarchie Organisationstrukur vom
SCD Typ 2
B) Gegenüberstellung der Kennzahlen zweier Fakttabellen unterschiedlicher Granularitätsstufe
mit wenig Aufwand möglich
5/12

Diesen Vorgang ist am einfachsten anhand eines Beispiels zu erklären.
Abbildung 3 zeigt die Situation auf.
Abbildung 3: Fakttabelle „Erträge“ und Fakttabelle „Kosten“ teilen neben der Zeit auch die Hierarchie
„Produkttyp“
Nehmen wir weiter an, die Erträge sind im OLTP System auf der Stufe „Einzelprodukt“ vorhanden, die
Kosten jedoch nur auf der Stufe „Produkttyp“.
Dieses Beispiel kann mit dem Ansatz „Surrogate Keys auf jeder Verdichtungsstufe“ wie folgt
implementiert werden:
Über der Dimensionstabelle „DIM_PRODUKT“ sind folgende Hierarchie-Constraints deklariert:
CREATE DIMENSION dim_Produkt
/* unterstützt auch SCD Typ 2 */
LEVEL version_einzelprodukt IS DIM_PRODUKT.DWH_ID_EINZELPRODUKT -- SurrogKey
LEVEL einzelprodukt IS DIM_PRODUKT.PROD_SERIAL# -- OLTP-Key
LEVEL version_produkttyp IS DIM_PRODUKT.DWH_ID_PRODUKTTYP -- SurrogKey
LEVEL produkt IS DIM_PRODUKT.PRODUKTTYP_CODE -- OLTP-Key
LEVEL version_produktart IS DIM_PRODUKT.DWH_ID_PRODUKTART -- SurrogKey
LEVEL produktart IS DIM_PRODUKT.PRODUKTART_CODE -- OLTP-Key
HIERARCHY hier_EPversion_EP (
version_einzelprodukt CHILD OF
einzelprodukt )
HIERARCHY hier_EPversion_produkttyp (
.... )
......
;
6/12

Die Fakttabelle „FaktProduktErträge“ verweisst auf das Attribut DWH_ID_EINZELPRODUKT, das den
Primärschlüssel der Dimensionstabelle „DIM_PRODUKT“ bildet.
Die Fakttabelle „FaktProduktKosten“ verweisst auf das Attribut DWH_ID_PRODUKTTYP, das den
Primärschlüssel der Tabelle „DIM_PRODUKTTYP“ bildet. Für diese Tabelle ist kein Ladejob nötig, da
sie die Materialisierung (Materialisierte View) der folgenden Abfrage über der Tabelle
„DIM_PRODUKT“ ist:
SELECT DISTINCT
DWH_ID_PRODUKTTYP,
PRODUKTTYP_CODE,
... alle anderen vom PRODUKTTYP_CODE abhängige Attribute
FROM DIM_PRODUKT
Die Tatsache, dass beide Fakttabellen die Verdichtungsstufe Produkttyp teilen, ist mittel eines
gemeinsamen SurrogateKeys DWH_ID_PRODUKTTYP implementiert. Dies deutet darauf hin, dass
Kosten/Ertragsvergleiche möglich sind. Falls diese öfters abgefragt werden, soll ein gespeichertes
Aggregat (materialisierte View) über der Fakttabelle „FaktProduktErträge“ auf Stufe
DWH_ID_PRODUKTTYP angelegt werden.
Wie wir gesehen haben, fordert die Technik „surrogate keys everywhere“ indirekt, in sog. konformen
Verdichtungsstufen 6 zu denken.
Guideline2: „no snowflaking“: Vermeidung von Joins, welche Selektivität des
Einstiegs in Fakttabelle nicht erhöhen
Snowflaking ist eine Technik, bei der die Attribute von Members der höheren Verdichtungsstufen,
deren Werte in der Dimensionstabelle vielfach wiederholt werden, in eine separate Tabelle ausgelagert
(normalisiert) werden.
Auch wenn Herr Kimball bereits vor vielen Jahren geschrieben hat „Efforts to normalize dimension
tables in order to save disk space are a waste of time“, es gibt immer noch vielerorts Bedenken, ob dies
bei relationalen Systemen wie Oracle gilt.
Deswegen wiederhole ich hier die Begründung, warum ein „snowflaking“ in Datamarts punkto
Abfrageperformance kontraproduktiv ist:
Jeder Join in einer Abfrage bedeutet lediglich ein Mehraufwand ohne einen Mehrwert, solange durch
diesen Join kein selektiver 7 Einstieg in die Fakttabelle geschaffen wird.
Aus einer Dimensionstabelle können in eine Snowflake-Tabelle nur Daten der höheren
Verdichtungsebenen ausgelagert werden, die ja aufgrund ihrer Natur immer nur weniger selektiv sind
(es gibt meistens weniger Produkttypen als Produkte).
Snowflaking bringt somit Mehraufwand für zusätzlichen Join, dem punkto Performance keinerlei
Mehrwert gegenübersteht.
Wie soll man „surrogate keys everywhere“ einerseits und „no snowflaking“ andererseits denn
verstehen?
6 eine Erweiterung des Konzepts “conform dimensions” vom Kimball
7 selektiver Einstieg: eine Einschränkung in der WHERE Klausel, welche veranlasst, dass ein Zugriff via
Index kostengünstiger ist als die ganze Tabelle(Tabellenpartition) zu lesen. Im DWH-Bereich kann man
von der Daumenregel (hängt natürlich von Fakttabellengrösse und z.V. stehenden HW ab) ausgehen,
dass ein Index-Zugriff dann günstiger ist, falls weniger als 1% der Faktdaten gelesen werden sollen.
7/12

„Surrogate Keys auf jeder Verdichtungsstufe“ definiert, wie die Dateninhalte identifiziert (adressiert)
werden. „No snowflaking“ beschreibt, wie die Dateninhalte gespeichert werden. Der Quellcode fürs
Dimensionsladen kann bei sauberer Trennung dieser zwei Dinge leicht komplexer sein (als bei heute
verbreiteten „Beides-Ist-Eigentlich-Das-Gleiche“-Ansatz), ist aber standardisierbar und sogar
automatisierbar… von dem her, kein wirklicher Zuwachs an Entwicklungskosten – nur an
Entwicklungsdisziplin.
Guideline3: Gefragten Gültigkeitsbezug pro Verdichtungsstufe wahrnehmen
In der Phase „dimensionale Modellierung“ wurde bei einzelnen Verdichtungsebenen u.a. auch der sog.
Gültigkeitsbezug (oder auch Typ der Slowly Changing Dimension 8 ) mit dem Endbenutzer festgelegt:
1) Stand gemäss letzter Dimensionsaktualisierung (Kimball’s Typ 1)
2) effektiver Stand damals (Kimball’s Typ 2)
3) Stand zum eingefrorenen historischen Zeitpunkt
Eine kurze Erklärung und Aufzeigen der Eigenschaften der einzelnen Bezugstypen werde ich anhand
der Mitarbeiter-Hierarchie „Organisationsstruktur“ aus der Abbildung 1 machen.
Nehmen wir weiter an, man möchte den „Produktumsatz“ messen, den die einzelnen Mitarbeiter
verkauft haben.
Beobachten wir mal die Beispielssituation, dass ein Mitarbeiter per 01.03.2004 die Abteilung von „X“
auf „Y“ gewechselt hat.
1) Stand gemäss letzter Dimensionsaktualisierung (Kimball’s Type 1)
Der Umsatz des Mitarbeiters sowohl vor dem 01.03.2004 als auch nach dem 01.03.2004 wird der letzt
gültigen Abteilung, d.h. „Y“ angerechnet. Dieser Bezugstyp wird auch konsolidierte Sicht genannt.
Nebenbei: Gespeicherte Aggregate, welche eine solche Verdichtungsebenen aufaggregiert haben,
werden meistens günstiger mit einem Full Refresh aktualisiert. Generell ist hier ein Refresh „teuer“.
2) effektiver Stand damals (Kimball’s Typ 2)
Der Umsatz des Mitarbeiters vor dem 01.03.2004 wird der Abteilung „X“ angerechnet, der Umsatz
danach der Abteilung „Y“.
Nebenbei: Fakttabelle oder Aggregate, welche ausschliesslich solche Verdichtungsebenen
„referenzieren“, können mit einem inkrementellen Refresh geladen werden (günstiger Refresh der
gespeicherten Aggregate).
3) Stand zum eingefrorenen historischen Zeitpunkt (bspw. Jahresbeginn)
Der Umsatz des MAs wird vom 01.01.2004 bis 31.12.2004 der Abteilung „X“ angerechnet. Der
Umsatz ab 01.01.2005 wird der Abteilung „Y“ angerechnet.
Nebenbei: Fakttabelle oder Aggregate, welche ausschliesslich solche Verdichtungsebenen
„referenzieren“, können mit einem inkrementellen Refresh geladen werden.
Diese Art des Bezugs wird vor allem im taktischen DSS gefragt, wo Plan-Ist Vergleiche die gleiche
Ausgangslage verlangen.
Bei Datamarts, welche sowohl taktische Entscheidungsfindung als auch strategische Analyse
unterstützen sollen, kann es vorkommen, dass gewisse Verdichtungsebenen zweimal angeboten
werden.
Bsp: Im Datamart „Kontotransaktionen“ kann das Kundensegment zweimal vorkommen:
- „Kundensegment“ (effektiver Stand damals)
8 Slowly Changing Dimension – kurz SCD
8/12

- „Kundensegment per Jahresbeginn“
Es handelt sich um zwei Dimensionen, deren Inhalt und Struktur identisch ist (d.h. zwei Views auf eine
Dimensionstabelle, zwei Verweise von den Fakteinträgen)
Vermutlich ist mehreren von Ihnen folgendes bekannt: Solange in der Fakttabelle der Bezugstyp 2
(effektiver Stand damals) implementiert ist, kann man die Kennzahlen jederzeit in die anderen
Bezugstypen transformieren (vorausgesetzt die Dimension enthält die Gültigkeitseinschränkungen der
Versionen, sog. Valid_from & Valid_to).
Auch wenn die Mittel dies zu tun meistens zur Verfügung stehen (DB-Views oder BO-Universen),
unsere Erfahrung zeigt, dass es nicht sinnvoll ist, dies zu tun, denn die Performance dieser Abfragen
wird stark leiden:
- die betroffene Dimensionstabelle muss zweimal gejoint werden
- eine Star-Transformation ist hier meistens ausgeschlossen
- die Schwachstelle vom Oracle-CBO „keine Berechnung von Statistiken für
zusammengesetzte Felderkombinationen möglich“ kommt zum Vorschein.
Wer mit der on-the-fly Ableitung (zur Abfragezeit: DB-View oder BO-Prädikat) an Speicherplatz der
Fakttabelle sparen möchte, spart auf der falschen Stelle.
Unsere Praxis zeigt weiter, dass es aus Bewirtschaftungsgründen nicht günstig ist, Verdichtungsstufen
unterschiedlicher Bezugstypen (z.B. Typ1 zusammen mit Typ2) in eine Dimensionstabelle abzulegen.
Daher ist es wichtig, beim Design der Dimensionstabelle die Bezugstypen wahrzunehmen, und in eine
Dimensionstabelle nur Verdichtungsebenen gleicher Bezugsart unterbringen.
Guideline4: hohe und gleichmässige Selektivität aller Fremdschlüssel der
Fakttabelle (Aggregatstabelle) anstreben
Im vorherigen Artikel habe ich den Ansatz zur Auflösung der „slowly changing monster dimensions“
erklärt (Abbildung 3 zeigt das Resultat). Wie man aus der Abbildung sehen kann, endete ich mit einer
grösseren Anzahl kleiner Dimensionen.
{ }
Einzelkunde
Einzelkunde
Kundennummer
{ }
Kunden
segment
Markt
segment
Kundensegment Marktsegment
Kundensegment
{ }
Marktsegment
{ }
{ }
{ }
Kunden
Wohnort
Wohnort
Geographie
Land
Kanton
Ort
{ } OECD
Mitglied
PLZ
Wohnort
Verkaufs
region
Verkaufs
region
Verkaufs { } region
{ }
Kunden
Status
Status Sprache
Status
{ }
Korrespondenz
Sprache
Sprache
Kundenbranche
Kundenbranche
{ } Abteilung
Kundenbranche
{ } Gruppe
Kundenbranche
{ } Klasse
{ }
Kunden
Branche
Kundenbranche
Alter
Nationalität
{ } Altersegment { } Nationalität
{ }
Alter Nationalität Geschlecht
Abbildung3: Auslagern der hoch-kardinalen Verdichtungsstufe Einzelkunde in separate Dimension
Bei vorheriger Guideline (3) habe ich erwähnt, dass es - Benutzerbedarf vorausgesetzt – sinnvoll ist, die
Dimension „Kundensegment“ auf zwei Dimensionen „Kundensegment (jeweils zum Faktdatum gültig)“
und „Kundensegment per Jahresbeginn“ aufzuspliten. Dies trägt zur Erstellung noch weiterer
Dimensionen bei.
Geburtsjahr
{ }
9/12
Geschlecht
Geschlecht

Die Aufgabe der relationalen Modellierung liegt u.a. auch dort, die Faktverbindungen zu all diesen
(vielen) Dimensionen abzuspeichern. Dies jedoch in solcher Form, dass:
- selektive 9 Abfragen wenig I/O benötigen
- der Platzbedarf für die Fakttabelle im vertretbaren Ausmass bleibt
Wie wir bereits wissen gibt es bei Datamarts, welche taktisches Reporting oder DSS unterstützen,
meistens eine Dimension, welche die Kardinalität 10 der Fakttabelle massgeblich bestimmt. Beispiel:
„Einzelkunde“ - es gibt durchschnittlich nur etwa 100-200 Transaktionen pro „Einzelkunde“, obwohl es
einige Millionen von Einzelkunden mit einer Transaktion gibt.
Hätte ich in diesem Datamart beim relationalen Design einfach für jede kleine Dimension eine
Dimensionstabelle gemacht, dann würden die Attribute der Fremdschlüssel (oder sogar Attribut-
Kombinationen) extrem wenig selektiv, dabei aber wesentlich (aufgrund ihrer grösseren Anzahl) zur
Breite des Fakteneintrags – und somit auch dem Bedarf an Diskplatz – beitragen. Die meisten von
Ihnen sehen es ein – es nicht so zu machen.
Die Lösung hier heisst: junk dimension tables 11 (Dimensionen-Zusammenschluss in eine Tabelle):
Ich nehme einige der kleinen Dimensionen (mit wenigen Members, am besten nur mit einer
Verdichtungstufe), mache ein kartesisches Produkt von den Members der Dimensionen (Kombination
jeder mit jedem), erzeuge einen neuen Surrogate-Key-Wert für jede Kombination, und schreibe die
Kombination in eine Dimensionstabelle (junk dimension table).
Zugegeben, der Refresh-Algorithmus für eine solche Junk Dimensionstabelle ist um einiges komplexer
(punkto Entwicklung aufwändiger) als einfach für jede Dimension eine Dimensionstabelle zu haben.
Der Zweck von Datamarts liegt jedoch nicht darin, dass es die Entwickler einfach haben, sondern dass
die Endbenutzer performante Abfragequelle haben.
Wenn wir jetzt die Technik von junk dimension tables verstehen, kommen wir zu der methodischen
Frage: wann soll man „junk dimension tables“ verwenden und welche Dimensionen zusammenfassen?
Hier ein paar Tipps:
1) Zusammenschluss mit Dimension „Zeit“ vermeiden
… ist ja irgendwie logisch. Dimension „Zeit“ hat eine Reihenfolge unterhalb der Members: Diese kann
man neben der Performance (Partition-Elimination über range-partitionierter Tabelle) auch für Admin-
Zwecke (Partition auf read-only setzen, droppen) gut gebrauchen.
2) Zusammenschluss von Dimensionen mit mehreren oder mehrstufigen Hierarchien vermeiden
Die Ladenprozeduren (wenn sie noch die gefragte Bezugsart richtig implementieren) sind hier ohnehin
schon genug komplex, um da noch die zusätzliche Komplexität vom Zusammenschluss einzuführen.
Meistens haben diese Dimensionen ohnehin schon grössere Anzahl vom Members (1000+) auf der
feinsten Verdichtungsstufe. Somit ist es mit der tiefen Selektivität nicht so schlimm und daher ist auch
der Handlungsbedarf hier klein ist.
3) Dimensionen vom Typ 1 (overwriting history) lassen sich nicht zusammenschliessen (junken)
4) Zusammenschluss der fachlich zusammengehörenden Dimensionen bevorzugen
9 nicht-selektive Abfragen sollen mit geeigneten gespeicherten Aggregaten (MViews) unterstützt werden
10 d.h. Anzahl Rows pro Zeit-Member (Zeitpunkt, Zeitperiode)
11 Begriff eingeführt vom Ralph Kimball
10/12

Dimensionen, welche aufgrund ihres Inhalts oder der Abfragemethode (strategisch/taktisch)
zusammengehören, sind geeignete Kandidaten für den Zusammenschluss.
Das Vorgehen ist aus der Abbildung 4 ersichtlich.
Einzelkonto
Kundenkonten
Kontoinhaber
{ } (Einzelkunde)
{ }
6 Mio
Einzelkonto
{ }
Kundennummer
Kontonummer
Kundensegment Marktsegment
Kunden
segment
{ }
{ }
{ }
Zeit
Kalenderjahre
48
{ }
Quartal
Quartal
Jahrmonat
Markt
segment
Teilmarkt der
Produktkategorie
Teilmarkt der
{ } Produktkategorie
{ }
Kunde Wahrnehmungsprofil
{ }
Finanzprodukt
Produktkategorie
{ }
Kontotyp
Kontotyp
Kontoart
Kundenausrichtung
Kunden- { } ausrichtung
Währung
Währung
{ } Produkt
{ }
Kontoart
{ } Status
Produkt
beschreibung
50
40 10
{ }
Kundensegment
Marktsegment
Verkaufs
region
Status
12 7 10 10
Verkaufs
region
Verkaufs
region
(Stand zum Faktzeitpunkt)
(Stand zum Jahresbeginn)
Status
Kunden
Status
Kontoeingenschaften
Kontokennzahlen
Saldo Bodensatz CHF
.....
{ }
Sprache
Sprache
Korrespondenz
Sprache
{ }
{ }
Kundeneigenschaften
Geburtsjahr
{ } Altersegment { } Nationalität
Alter
110
Nationalität
Kontostatus
Status
{ }
Geschlecht
6 150 4
Geschlecht
Alter Nationalität Geschlecht
{ }
{ }
{ }
Kundenbranche
Kundenbranche
{ } Abteilung
Kundenbranche
{ } Gruppe
Kundenbranche
{ } Klasse
Abbildung4: Dimension-Junking der fachlich zusammengehörenden Dimensionen
{ }
6700
Kunden
Branche
Kundenbranche
Ort
Kanton
Land
170
Wohnort
Geographie
Kunden
Wohnort
11/12
PLZ
Wohnort
{ } OECD
Mitglied
Beispiele: Kleindimensionen über Kunden in Junk-Dimension-Table „Kundenprofil“
zusammenschliessen.
Analog bei Kleindimensionen des Kontos. Neben dem „Kundenprofil“ (für strategische Abfragen oder
operative Zwecke) ggf. noch „Kundenprofil (per Jahresbeginn)“ für taktische Abfragen erstellen.
5) Diskplatzersparnis im Kontext der Komplexitätssteigerung abwägen
Fakttabellen können heutzutage 12 bei gutem Clustering Faktor sehr effizient komprimiert werden (data
segment compression).
Das Erhöhen vom Clustering Faktor und die Kompression sind fast gratis (wir bezahlen Oracle die
Lizenzkosten so oder so). Das Dimension-Junking führt zwar zum grösseren Platzersparnis, steigert aber
die Komplexität und somit auch die ETL-Entwicklungskosten.
Am Schluss noch ein Tipp fürs ETL:
Refresh einer „junk dimension table“ soll immer im letzten Schritt die Eindeutigkeit der Member-Key-
Kombinationen prüfen. Falls die Dimensionstabelle nur wenige Einträge enthält, kann dies ein Unique
Constraint (Unique Index) übernehmen. Beispiel: KUNDENSEGMENT_CODE und
MARKTSEGMENT_CODE sind die Member-Keys der (allen) zweit Verdichtungsstufen, welche in
Tabelle DIM_SEGMENT zusammmengefasst wurden. Ein Unique Index (KUNDESEGMENT_CODE,
MARKTSEGMENT_CODE) über dieser Dimensionstabelle sichert, dass ein Look-Up für Surrogate-Key
bei Laden der Fakteinträge höchstens eine Row liefert.
12 Oracle 9.2 oder höher

Zusammenfassung
Anhand einiger Praxisbeispiele hat dieser Artikel die Wichtigkeit der Designarbeit beim Aufbau eines
Datamarts demonstriert.
Unsere Erfahrung zeigt, dass viele Kunden beim Design oder Redesign der Datamarts dieser Phase
vermehrt erhöhte Aufmerksamkeit widmen: nämlich solche, die sie aufgrund der weitreichenden
Entscheide verdient.
Ich würde mich über Anregungen, Kommentare und Erfahrungen zu diesem Artikel erfreuen.
In den nächsten Artikeln werde ich mich dem physischen Design widmen.
Viel Erfolg beim (Um)bau Ihrer Datamarts wünscht
Karol Hajdu
karol.hajdu@trivadis.com
Trivadis AG
Europa-Strasse 5
CH – 8152 Glattbrugg
Tel. +14 1 808 70 20
12/12