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:
- Faktentabelle „Kundenverhalten“
- Spalten: Datum, Kunden-ID, Besuchsdauer, Seitenaufrufe, Konversionsrate
- Faktentabelle „Bestandsbewegungen„
- Spalten: Datum, Produkt-ID, Lager-ID, Einheitenzugang, Einheitenzugang, Einheitenabgang, Bestandssaldo
- 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:
- Dimensionstabelle „Kunden“
- Spalten: Kunden-ID, Vorname, Nachname, Geschlecht, Geburtsdatum, E-Mail-Adresse, Telefonnummer
- Dimensionstabelle „Zeit“
- Spalten: Datum, Jahr, Monat, Tag, Quartal, Kalenderwoche
- Dimensionstabelle „Mitarbeiter“
- Spalten: Mitarbeiter-ID, Vorname, Nachname, Position, Abteilung, Gehalt, Einstellungsdatum
- Dimensionstabelle „Lieferanten“
- Spalten: Lieferanten-ID, Lieferantenname, Lieferantenartikelnummer, Lieferantenadresse, Kontaktperson
- 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-ID | Produkt-ID | Kunden-ID | Datum | Menge | Umsatz |
|---|---|---|---|---|---|
| 1 | 101 | 1001 | 2023-06-01 | 5 | 250 |
| 2 | 102 | 1002 | 2023-06-02 | 3 | 150 |
| 3 | 103 | 1003 | 2023-06-03 | 2 | 100 |
Dimensionstabelle: Produkte
| Produkt-ID | Name | Kategorie | Marke |
|---|---|---|---|
| 101 | Produkt A | Elektronik | Marke X |
| 102 | Produkt B | Haushaltsgeräte | Marke Y |
| 103 | Produkt C | Möbel | Marke Z |
Dimensionstabelle: Kunden
| Kunden-ID | Name | Land | Stadt |
|---|---|---|---|
| 1001 | Max Mustermann | Deutschland | Berlin |
| 1002 | Sarah Schmidt | Deutschland | München |
| 1003 | Thomas Müller | Deutschland | Hamburg |
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
| 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 |
| Produkt-ID | Name | Kategorie | Marke |
|---|---|---|---|
| 101 | iPhone | Elektronik | Apple |
| 102 | Produkt B | Autozubehör | Marke Y |
| 103 | Produkt C | Möbel | Marke Z |
| 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.
