Star-Schema und Snowflake-Schema
kurz und knapp:

Tabellen werden differenziert in Fakten- und Dimensionstabellen. Beim Star-Schema steht eine Faktentabelle in der Mitte und an ihr sind Dimensionstabellen gebunden. Das Snowflake-Schema ist identisch aufgebaut, aber aus den Dimensionstabellen können weitere Unter-Dimensionstabellen abzweigen.

Star-Schema (auch Sternschema) und Snowflake-Schema (auch Schneeflockenschema) sind Modelle, um eine Datenbank zu konstruieren. Diese beiden Schemata eignen sich hervorragend dafür, Data Warehouses oder OLAP-Systeme zu modellieren. Grundlegende Begriffe zum Verständnis sind Faktentabellen und Dimensionstabellen.

Vorwissen

Was ist Datenmodellierung?

Datenmodellierung ist ein Prozess, um Daten in verschiedenen Tabellen zu strukturieren. Damit kann man komplexe Daten in eine geordnete und verständliche Form bringen.

Datenmodelle dienen als Grundlagen für Datenbanken und ermöglichen damit effizientes Datenmanagement. Diese Modelle können auf unterschiedliche Ziele ausgelegt sein – sei es eine sehr schnelle Performance, ein geringer Verbrauch von Speicher oder auch das Vereinfachen der Daten.

Warum ist die Wahl des richtigen Datenmodells wichtig?

Ein angemessenes Datenmodell erleichtert die Abfrage und Analyse von Daten. Damit kann die Arbeitszeit von Analysten verkürzt werden und komplizierte Unternehmenslogik kann stark vereinfacht werden.

Für die eine Firma kann das heißen, dass auch weniger technisch begabte Mitarbeiter mit den Daten arbeiten können. Für die andere heißt es, häufig vorkommende Abfragen 1% schneller zu machen.

Letztendlich ist die Wahl des richtigen Datenmodells wesentlich, um Daten einfacher verfügbar zu machen, die Performance der Abfragen zu steigern und Kosten zu reduzieren.

Was ist dimensionale Datenmodellierung?

Dimensionale Datenmodellierung ist der umfassende Begriff für Star- und Snowflake-Schemas. Es beschreibt eine Struktur, bei der Fakten- und Dimensionstabellen benutzt werden, um bspw. ein Data Warehouse zu modellieren. 

Es wird in der Regel verwendet, um Datenbanken zu erstellen, die für Analysen optimiert sind, anstatt bspw. Transaktionen in einer Website auszuführen.

Was sind Faktentabellen? (mit Beispielen)

Faktentabellen liefern wichtige Geschäftsinformationen. Das sind in der Regel Dinge, die konstant vorkommen (z.B. Bestellungen, Transaktionen, Klicks, Ereignisse, Sitzungen, Abstimmungen). 

Sie sind in der Regel lange Tabellen mit wenig Spalten, wie z.B. dem Datum, die ID einer zugehörigen Einheit und weitere Werte mit denen wir Kennzahlen für die Firma berechnen können.

In ihnen befinden sich Spalten, die eine Verbindung mit weiteren Tabellen ermöglichen. In technischer Sprache bedeutet das, dass Fremdschlüssel in der Faktentabelle gesammelt werden, um in SQL mit JOINs auf andere Tabellen zugreifen zu können. Das führt uns direkt zu den Dimensionstabellen.

Als Beispiel können wir die Faktentabelle Verkäufe erstellen. Sie beinhaltet Spalten wie z.B. Datum des Verkaufs, Produkt-ID, Verkaufsmenge, Verkaufspreis und Umsatz.

Weitere Beispiele:

  1. Faktentabelle „Kundenverhalten“
    • Spalten: Datum, Kunden-ID, Besuchsdauer, Seitenaufrufe, Konversionsrate
  2. Faktentabelle „Bestandsbewegungen
    • Spalten: Datum, Produkt-ID, Lager-ID, Einheitenzugang, Einheitenzugang, Einheitenabgang, Bestandssaldo
  3. Faktentabelle „Finanztransaktionen“
    •  Spalten: Datum, Transaktions-ID, Kontonummer, Betrag

Was sind Dimensionstabellen? (mit Beispielen)

Dimensionstabellen speichern weiterführende Informationen, die die Geschäftsdaten in der Faktentabelle genauer beschreiben. 

Das können Tabellen wie z.B. Produkte, Kunden, Geschäfte, Marketing und Zeiten sein. Bei Datenanalysen wählt man Spalten aus der Faktentabelle und erweitert sie um Spalten aus der Dimensionstabelle.

Bei einer Faktentabelle namens Verkäufe könnten wir zu einer Dimensionstabelle namens Produkte verlinken, die tiefergehende Produktinformationen liefern. Diese könnten Spalten haben wie z.B. Produktname, Produktkategorie, Produktbeschreibung, Hersteller, Maße und Gewicht. Jede Dimensionstabelle hat eine einzigartige ID für jede Einheit, damit wir diese mit der Faktentabelle verknüpfen können. 

Damit könnten wir also eine Analyse erstellen und prüfen, wie viele Produkte in den Verkäufen der letzten Woche schwerer als 20kg waren.

Weitere Beispiele:

  1. Dimensionstabelle „Kunden“
    • Spalten: Kunden-ID, Vorname, Nachname, Geschlecht, Geburtsdatum, E-Mail-Adresse, Telefonnummer
  2. Dimensionstabelle „Zeit“
    • Spalten: Datum, Jahr, Monat, Tag, Quartal, Kalenderwoche
  3. Dimensionstabelle „Mitarbeiter“
    • Spalten: Mitarbeiter-ID, Vorname, Nachname, Position, Abteilung, Gehalt, Einstellungsdatum
  4. Dimensionstabelle „Lieferanten“
    • Spalten: Lieferanten-ID, Lieferantenname, Lieferantenartikelnummer, Lieferantenadresse, Kontaktperson
  5. Dimensionstabelle „Zahlungsmethoden“
    • Spalten: Zahlungsmethode-ID, Zahlungsmethode, Kreditkartenart, Bankverbindung

Star-Schema: Ein einfacher Ansatz

Der Name des Star-Schemas kommt daher, dass die Tabellen sternförmig angeordnet werden. In der Mitte befindet sich die Faktentabelle und um sie herum werden Dimensionstabellen verknüpft. 

Es ist die simpelste Form, um ein Data Warehouse zu modellieren. Das ist gleichzeitig auch ihre größte Stärke – Abfragen sind für die Nutzer sehr simpel zu erstellen, weil nur auf zwei Ebenen (Fakten und Dimensionen) gearbeitet wird. 

Das Verbinden der Tabellen in SQL mit JOIN-Befehlen ist also ohne komplexe Verkettung möglich. Durch Einfachheit des Schemas ist es für unkomplizierte Datenbanken wie z.B. Data Marts (eine „Abteilung“ des Data Warehouses) gut geeignet.

Beispiel eines Star-Schemas​

Faktentabelle: Verkäufe

Verkaufs-IDProdukt-IDKunden-IDDatumMengeUmsatz
110110012023-06-015250
210210022023-06-023150
310310032023-06-032100

Dimensionstabelle: Produkte

Produkt-IDNameKategorieMarke
101Produkt AElektronikMarke X
102Produkt BHaushaltsgeräteMarke Y
103Produkt CMöbelMarke Z

Dimensionstabelle: Kunden

Kunden-IDNameLandStadt
1001Max MustermannDeutschlandBerlin
1002Sarah SchmidtDeutschlandMünchen
1003Thomas MüllerDeutschlandHamburg

Vorteile des Star-Schemas

Einfachheit und Verständlichkeit

Das Star-Schema ist sehr simpel aufzubauen und man muss keine komplexen Architekturen entwickeln. Durch die zentrale Faktentabelle orientiert man sich ausschließlich auf Dimensionen, die an diese geheftet werden. Damit kann man sehr einfach Berechnungen erstellen.

Man braucht keine tiefgehenden Kenntnisse, um Tabellen über komplexere Verbindungen zusammenzufügen. Es ermöglicht dadurch eine vereinfachte Datenabfrage und -analyse, da Benutzer nicht durch mehrere Tabellen navigieren müssen.

Es erleichtert damit auch die Integration von Daten aus neuen Quellen, da die Struktur weniger komplex ist.

Performance

Durch die einfache Verbindung zwischen Fakten- und Dimensionstabellen ist eine schnellere Datenabfrage möglich. 

Da weniger Tabellen beteiligt sind, werden weniger JOIN-Operationen benötigt. Dadurch kann das Star-Schema auch bei großen Datenmengen effektiv arbeiten.

Nachteile des Star-Schemas

Wiederholung und Unstimmigkeiten

Redundanz (Wiederholungen) und Inkonsistenzen (Unstimmigkeiten) in den Daten sind ein wesentlicher Nachteil beim Star-Schema.

Da Dimensionstabellen direkt mit der Faktentabelle verbunden sind, können Informationen in mehreren Zeilen der Faktentabelle wiederholt werden. Das kann zu redundanter Datenspeicherung führen und den Speicherbedarf erhöhen.

Einschränkungen bei komplexen Abfragen

Da alle Dimensionstabellen direkt mit der Faktentabelle verbunden sind, kann es schwieriger sein, komplexe Abfragen zu formulieren, die über mehrere Dimensionen hinweggehen.

Bei Abfragen, die Dimensionstabellen tiefer ineinander verschachteln, kann das Star-Schema zu komplexen JOINs führen, was für eine schlechtere Abfrageleistung führen kann.

Insgesamt ist das Star-Schema bei einfachen Abfragen effizient, aber bei komplexen Abfragen kann das Snowflake-Schema eine bessere Leistung und Flexibilität bieten.

Snowflake-Schema: Eine detailliertere Betrachtung

Das Snowflake-Schema ist ähnlich wie das Star-Schema aufgebaut. In der Mitte befindet sich die Faktentabelle und um sie herum sind Dimensionstabellen verknüpft. 

Der große Unterschied zum Star-Schema ist, dass das Snowflake-Schema Unterdimensionen zulässt. 

Diese Weiterverzweigung gibt dem Modell die Form einer Schneeflocke. Aus einer Dimensionstabelle können daher weitere Dimensionstabellen entspringen. 

Diese Eigenschaft ermöglicht die Normalisierung von Daten. Normalisierung ist ein Konzept, das große Tabellen in kleinere aufteilt, um doppelte Daten zu vermeiden. Bei sehr großen Data Warehouses spart das einen riesigen Anteil am Datenspeicher. Je mehr Unterdimensionen existieren, desto komplizierter werden aber die JOIN-Befehle in SQL.

Beispiel eines Snowflake-Schemas

Faktentabelle: Verkäufe
Verkaufs-ID Produkt-ID Kunden-ID Datum Anzahl Umsatz
1 101 1001 2023-07-01 5 250
2 102 1002 2023-07-02 3 150
3 103 1003 2023-07-03 2 100
Dimensionstabelle: Produkte
Produkt-ID Name Kategorie Marke
101 iPhone Elektronik Apple
102 Produkt B Autozubehör Marke Y
103 Produkt C Möbel Marke Z
Dimensionstabelle: Produktvariation
Produkt-ID Farbe Limitierte Edition
101 Rot Nein
101 Gelb Nein
101 24-Karat Gold Ja

Vorteile des Snowflake-Schemas

Effizienz bei der Speicherplatznutzung

Durch die Normalisierung der Dimensionstabellen werden Redundanzen reduziert, da gemeinsame Attribute in separaten Tabellen gespeichert werden. Das führt zu weniger Verbrauch vom Speicherplatz.

Durch die Verringerung der Speicherplatzanforderungen kann das Snowflake-Schema bei großen Datenmengen günstiger sein.

Weniger Wiederholung in den Daten

Die geringere Redundanz in den Daten im Snowflake-Schema verbessert die Datenintegrität, da Aktualisierungen nur an einer Stelle vorgenommen werden müssen. 

Beim Star-Schema hingegen kann es vorkommen, dass wiederholte Informationen in der Faktentabelle zu einer erhöhten Redundanz führen können.

Nachteile des Snowflake-Schemas

Komplexität und Schwierigkeit im Verständnis

Durch die Normalisierung werden Dimensionstabellen in separate Tabellen aufgeteilt, was zu einer komplexeren Struktur führen kann. Die JOIN-Pfade können dadurch schwieriger nachzuvollziehen sein. 

Das kann dazu führen, dass für unser Data Warehouse Benutzer mit mehr Zeit und Expertise gebraucht werden, um effektive Abfragen zu schreiben.

Performance-Einbußen

Da man mehr Dimensionstabellen im Snowflake-Schema hat, werden auch mehr JOINs verlangt, um Daten zu verknüpfen. Das kann zu längeren Abfragezeiten und höherem Ressourcenverbrauch führen.

Die erhöhte Komplexität kann auch zu ineffizienten Abfragen führen, wenn weniger erfahrene Analysten Abfragen schreiben.

Galaxy-Schema: Ein Sonderfall

Das Star- oder Snowflake-Schema kann um mehrere Faktentabellen erweitert werden. Damit entsteht ein sogenanntes Galaxy-Schema

Darin können sich verschiedene Faktentabellen dieselbe Dimensionstabelle teilen. Haben wir als Faktentabellen die Verkäufe aus unserer IT-Beratung und die Verkäufe aus unserem Online-Shop, können wir eine Kundentabelle erstellen, auf die beide Faktentabellen zugreifen. Damit kann man kompliziertere Systeme kompakter aufbauen.

Star-Schema vs. Snowflake-Schema: Ein direkter Vergleich​

Aspekt Star-Schema Snowflake-Schema
Datenstruktur Flache Hierarchie Normalisierte Struktur
Datenintegration Einfach, weniger Komplexität Komplexer, mehrere Tabellen
Performance Schnelle Abfragen, weniger Joins Potenzielle Performance-Einbußen durch Joins
Speicherplatznutzung Potenzielle Redundanz in der Faktentabelle Effizientere Speicherplatznutzung durch Normalisierung
Datenkonsistenz Einfachere Aktualisierung, weniger Unstimmigkeiten Bessere Konsistenz durch Normalisierung
Datenpflege Weniger Aktualisierungen bei Änderungen Komplexere Aktualisierungen in den Dimensionstabellen
Datenverständnis Einfach und intuitiv Komplex und verschachtelt
Abfragekomplexität Gut geeignet für einfache Abfragen Geeignet bei komplexen Abfragen
Anwendungsbereich Gut geeignet für OLAP-Anwendungen Geeignet für größere und heterogene Datenquellen
Entscheidungskriterien Einfache Datenmodelle, Benutzerfreundlichkeit Hohe Datenintegrität, Flexibilität

Fazit: Welches Schema solltest Du wählen?

Das Star-Schema ist sinnvoll, wenn Du ein System aufbauen möchtest, das sehr simpel zu verstehen ist und bei dem Redundanz in den Daten kein Problem ist.

Das Snowflake-Schema ist sinnvoll, wenn Datenintegrität in deinem Data Warehouse wesentlich ist und wenn Daten untereinander stark miteinander verknüpft sind, was zu mehr Komplexität im Star-Schema führen würde.

Kritik: Warum das alles nicht mehr zeitgemäß ist

Unpopular Opinion: In der heutigen Zeit sind die Vor- und Nachteile absolut zu vernachlässigen. Die Konzepte wurden vor 30 Jahren entwickelt, als Festplatten- und Arbeitsspeicher noch teuer war und das skalieren von Data Warehouses mit mehr Hardware verbunden war.

Wir haben heute Clouds wie Amazon Web Services, Google Cloud Platform oder Microsoft Azure, mit denen wir Speicher zu einem extrem günstigen Preis bekommen können. Berechnungen können durch Distributed Computing stark beschleunigt werden.

Mit Cloud Data Warehouses wie BigQuery, Snowflake oder Databricks müssen wir uns um all das nicht mehr kümmern. Der wesentlichste Vorteil ist also nur noch die Übersichtlichkeit. 

Bei vielen Datenquellen kann das Star- oder Snowflake-Schema es als Zwischenebene nützlich sein, um die Daten zu ordnen. Einen tiefergehenderen Effekt sehe ich allerdings im durchschnittlichen Fall nicht.

In den meisten Fällen sind Modelle wie das Data Vault oder One Wide Table sinnvoller, um andere technische Aspekte abzudecken.

ARTIKEL TEILEN

Hast du Fragen? Hinterlasse einen Kommentar!