Sternschema

Grundidee und Aufbau

Ein Sternschema ist ein logisches Datenbankschema für Data-Warehouse- und OLAP-Anwendungen. Es ist auf effiziente Leseoperationen und analytische Abfragen ausgerichtet, nicht auf Normalisierung. Die Tabellen sind sternförmig angeordnet: Eine Faktentabelle steht im Zentrum, mehrere Dimensionstabellen liegen darum herum und beziehen sich jeweils auf genau diese eine Faktentabelle.

Die Faktentabelle enthält informationstragende Werte wie Umsätze, Zeiträume oder Kosten. Ihr Primärschlüssel ist normalerweise zusammengesetzt: Er besteht aus den Primärschlüsseln der beteiligten Dimensionstabellen, die in der Faktentabelle als Fremdschlüssel gespeichert sind. Jede Dimensionstabelle steht über ihren Schlüssel und den entsprechenden Fremdschlüssel der Faktentabelle in einer 1:n-Beziehung zur Faktentabelle. Dadurch werden m:n-Beziehungen implizit in einer Faktentabelle abgebildet.

Das Schema ermöglicht, Messwerte auszuwählen, zusammenzufassen und entlang verschiedener Dimensionen zu untersuchen. Es nimmt bewusst Redundanz, möglichen zusätzlichen Speicherbedarf und eine geringere Datenintegrität in Kauf, um Abfragen schneller zu verarbeiten.

Fakten und Dimensionen

Fakten sind die zu verwaltenden Kenn- oder Ergebniszahlen; weitere Bezeichnungen sind Metriken, Messwerte und Kennzahlen. Sie werden typischerweise fortlaufend in der Faktentabelle gespeichert und können wirtschaftliche Leistung ausdrücken, etwa Profitabilität, Kosten, Leistung/Erlös, Ausgaben, Einnahmen, Aufwände oder Erträge. Aussagekräftig werden sie erst im Zusammenhang mit Dimensionen, beispielsweise wenn Umsätze für bestimmte Produkte, Bereiche und Zeiträume verglichen werden.

Faktentabellen können sehr groß werden, in einem Sternschema oft mit mehr als 10 Millionen Datensätzen. Deshalb werden Daten in einem Data Warehouse nach und nach verdichtet (aggregiert) und nach einer Halteperiode gelöscht oder ausgelagert (archiviert). Die Gesamtheit der Fremdschlüssel auf Dimensionstabellen bildet meist zugleich den Primärschlüssel der Faktentabelle. Daher kann es zu einer Kombination von Dimensionswerten nur einen Eintrag geben.

Dimensionstabellen enthalten beschreibende Daten, die die Bedeutung der Fakten festlegen. Sie sind meist vergleichsweise statisch und erheblich kleiner als Faktentabellen. Jede stellt eine Dimension eines mehrdimensionalen OLAP-Würfels dar. Die Trennung erlaubt, Fakten generisch und unabhängig nach jeder Dimension zu analysieren; die fachliche Interpretation einer Dimension bleibt dem Benutzer überlassen.

Denormalisierung und Änderungen

Dimensionstabellen sind im Sternschema üblicherweise denormalisiert. Zwischen Nicht-Schlüsselattributen bestehen funktionale Abhängigkeiten; damit wird die dritte Normalform (3NF) bewusst verletzt. Für die 3NF müsste eine Dimensionstabelle in einzelne hierarchische Tabellen zerlegt werden. Das Sternschema verzichtet aus Performancegründen darauf und akzeptiert die entstehende Redundanz.

Bei besonders großen Dimensionstabellen kann eine Normalisierung in Richtung Schneeflockenschema sinnvoll sein, um große Datenbestände und damit Zugriffszeiten zu verringern.

Eine besondere Schwierigkeit sind Änderungen von Dimensionsdaten über längere Zeiträume. Alte Fakten dürfen durch neue Dimensionswerte normalerweise nicht ihre historische Bedeutung verlieren. Wechselt zum Beispiel der Verkäufer einer Produktgruppe, darf der bestehende Dimensionseintrag nicht einfach überschrieben werden: Sonst wären die Verkaufszahlen des vorherigen Verkäufers nicht mehr feststellbar. Slowly Changing Dimensions fassen Methoden des Data Warehousing zusammen, die solche Änderungen in Dimensionstabellen erfassen und gegebenenfalls historisch dokumentieren.

Vorteile, Nachteile und Schneeflockenschema

Vorteile sind die schnelle Verarbeitung analytischer Anfragen auf höheren Aggregationsniveaus, weil durch den Verzicht auf die Normalisierung der Dimensionen Joins eingespart werden. Auch ein Star Join kann gut optimiert werden. Das Modell ist einfach und intuitiv: Es hat weniger Relationen als ein konvergierendes Schneeflockenschema, und die JOIN-Tiefe ist nicht größer 1. Es unterstützt zudem verständliche und nachvollziehbare Auswertungen, etwa Datensammlungen zur Trenderkennung und für Data-Mining.

Der zusätzliche Speicherbedarf durch die Denormalisierung kleiner Dimensionstabellen muss meist nicht beachtet werden. Änderungsanomalien lassen sich leicht kontrollieren, da Klassifikationen nur selten geändert werden.

Nachteile sind ein schlechteres Antwortzeitverhalten bei häufigen Abfragen sehr großer Dimensionstabellen, etwa bei Browsing-Funktionen, die Redundanz durch mehrfach gespeicherte identische Werte oder Fakten innerhalb einer Dimensionstabelle sowie die schwierige Aggregationsbildung.

Im Gegensatz dazu verfolgt das Schneeflockenschema die Redundanzminimierung durch Normalisierung und eine effiziente Transaktionsverarbeitung. Es kann bei großen Datenmodellen viele Entitäten und Beziehungen enthalten und ist komplexer sowie spezifischer. Das Sternschema zielt hingegen auf benutzerfreundliche Aggregatabfragen und führt zu einem einfachen, lokalen und standardisierten Modell mit einer Faktentabelle und wenigen Dimensionstabellen.

Anforderungen und typische Abfrage

Der Aufbau beginnt mit betrieblichen Anforderungen: Welche Fakten interessieren nach welchen Kriterien? Dazu werden verfügbare Daten, geforderte Auswertungen und Tabelleninhalte bestimmt. Ein Anforderungsdiagramm fasst diese Spezifikationen zusammen.

Indikatoren sind Attribute, die das Ergebnis einer Unternehmenseinheit bewerten; sie beantworten die Frage „Wie gut?“. Dimensionen sind Attribute, entlang derer Indikatoren gemessen werden; typische Fragen sind „Was?“, „Wann?“ und „Wo?“. Kategorien sind Wertebereiche einer Dimension und beantworten „Wie genau?“.

Star Join und Abfragebeispiel

Typische Abfragen im Sternschema sind Star Joins. Sie wählen Dimensionsattribute und aggregierte Fakten aus der Faktentabelle, verknüpfen diese mit einer oder mehreren Dimensionstabellen, filtern mit einer WHERE-Bedingung, gruppieren nach einem Dimensionsattribut und sortieren nach Faktenaggregation oder Dimensionsattribut.

Im Beispiel werden die Verkäufe eines Produkts für einen definierten Zeitraum summiert: ProductAlternateKey wird mit „XYZ%“ gefiltert, CalendarYear auf die Jahre 2008 bis 2009 begrenzt und SalesAmount nach ProductAlternateKey und CalendarYear gruppiert und summiert. Die Faktentabelle FactInternetSales wird dabei über ProductKey mit DimProduct und über OrderDateKey mit DimTime verknüpft. Es werden 2 Joins verwendet. Im Sternschema ist die Anzahl der Joins unabhängig von der Länge der Aggregationspfade; das unterscheidet es vom Schneeflockenschema.