Snowflake-Schema

Das Snowflake-Schema ist ein Bauplan, wie Daten in einem Data Warehouse (zentraler Datenspeicher für Auswertungen) angeordnet werden. Im Kern steht eine Fakten-Tabelle mit den Geschäftszahlen (zum Beispiel Verkäufe), umgeben von Dimensionstabellen mit den erklärenden Merkmalen (Kunde, Produkt, Zeit). Anders als beim verwandten Star-Schema werden diese Merkmalstabellen aufgetrennt und über Verweise miteinander verbunden, sodass das Diagramm optisch an eine Schneeflocke erinnert. Der Ansatz geht auf die dimensionale Modellierung nach Ralph Kimball zurück.

Was ist ein Snowflake-Schema?

Ein Snowflake-Schema ist ein Ordnungs-Muster für die Auswertungs-Schicht eines Data Warehouse (zentraler Datenspeicher für Reports und Analysen). Im Zentrum liegt eine Fakten-Tabelle mit den messbaren Geschäftsereignissen (Verkauf, Bestellung, Buchung, Klick). Darum herum liegen Dimensionstabellen, die den Kontext dazu liefern (welcher Kunde, welches Produkt, wann, wo). Der Unterschied zum Star-Schema liegt in der Struktur dieser Dimensionen: Statt einer breiten Merkmals-Tabelle pro Dimension wird jede Dimension in mehrere kleinere Tabellen aufgeteilt, die über Verweise (Fremdschlüssel) miteinander verbunden sind. Merkmale, die in klaren Hierarchien stehen (Produkt gehört zu Kategorie, Kategorie gehört zu Sortiment), wandern in eigene Unter-Tabellen.

Eine Produkt-Dimension in einem Star-Schema führt Produktname, Produktkategorie, Produktgruppe und Sortiment als flache Spalten in dim_produkt. Dasselbe Modell im Snowflake-Schema zerlegt die Hierarchie: dim_produkt referenziert dim_produktkategorie, das wiederum dim_produktgruppe referenziert. Das Ergebnis ist ein Baum aus normalisierten Tabellen, dessen ER-Diagramm optisch an eine Schneeflocke erinnert.

Der Begriff stammt aus der klassischen dimensionalen Modellierung nach Ralph Kimball. Kimball behandelt das Snowflake-Schema als Design-Variante des Star-Schemas, die dann eingesetzt wird, wenn eine Dimension sehr breit ist, viele wiederholte Attribut-Werte enthält oder sich Attribute in klaren Hierarchien gliedern lassen. Die Motivation ist historisch: Storage war teuer, Query-Optimizer waren begrenzt und Redundanz in Dimensionstabellen erschwerte konsistente Updates. In modernen Column-Store-Warehouses und Lakehouse-Plattformen hat sich das Kosten-Nutzen-Verhältnis verschoben, weil Spaltenkompression Redundanz billig macht und die zusätzlichen Joins die Query-Kosten stärker erhöhen als die eingesparte Speicherredundanz.

Das Snowflake-Schema bleibt in bestimmten Konstellationen praxisrelevant. Große Dimensionen mit tiefen Attribut-Hierarchien (mehrstufige Produkt- oder Organisations-Klassifikationen), Dimensionen mit vielen Slowly-Changing-Attributen auf unterschiedlichen Änderungs-Frequenzen und Referenzdaten-Dimensionen, die aus operativen Systemen normalisiert übernommen werden, sind typische Einsatzfelder. Für die Standard-Fakten-Auswertung bleibt das Star-Schema die einfachere Wahl.

Abgrenzung zu Star-Schema, Galaxy-Schema, One Big Table und dem Snowflake-Produkt

Der Begriff wird in Praxis-Diskussionen häufig mit vier verwandten Konzepten vermischt: mit dem Star-Schema als Ausgangs-Muster, mit dem Galaxy-Schema als Mehr-Fakten-Variante, mit One Big Table als Gegenextrem und mit dem gleichnamigen Cloud-Data-Warehouse-Produkt der Snowflake Inc.

Die wichtigste Abgrenzung verläuft zwischen Star-Schema und Snowflake-Schema. Beide Muster stammen aus der Kimball-Familie und teilen dieselbe Grundstruktur (Fakten-Tabelle im Zentrum, Dimensionstabellen darum herum). Sie unterscheiden sich ausschließlich im Normalisierungsgrad der Dimensionen. Der Trade-off ist klar: Das Snowflake-Schema spart Speicher und vereinfacht Attribut-Wartung in großen Dimensionen, kostet aber Query-Performance durch zusätzliche Joins und Lesbarkeit für BI-Anwender. Das Star-Schema kehrt beide Vorzeichen um.

Die zweite häufige Verwechslung betrifft das Modellierungsmuster und das gleichnamige Produkt. Snowflake Inc. ist ein Anbieter eines Cloud-Data-Warehouse-Dienstes. Das Snowflake-Schema als Modellierungsmuster existiert seit den 1990er-Jahren und ist unabhängig vom Produkt. Beide Bedeutungen laufen im gleichen Fachkontext zusammen, was in Gesprächen und Suchergebnissen zu Verwechslungen führt.

Beispiel: Produkt-Dimension in einem Handels-Warehouse

Ein Handelsunternehmen führt ein Data Warehouse mit einer Fakten-Tabelle fact_verkauf (Milliarden Zeilen: Datum, Filiale, Produkt, Menge, Umsatz) und einer Produkt-Klassifikation mit vier Ebenen: Produkt, Kategorie, Gruppe, Sortiment. Modelliert als Star-Schema, hält dim_produkt alle vier Ebenen als flache Spalten:

Modelliert als Snowflake-Schema, wird die Hierarchie zerlegt:

Eine Auswertung „Umsatz je Sortiment" erfordert im Star-Schema einen Join zwischen fact_verkauf und dim_produkt. Im Snowflake-Schema führt dieselbe Abfrage über vier Joins (fact_verkauf → dim_produkt → dim_kategorie → dim_gruppe → dim_sortiment). Der Speicher-Vorteil entsteht auf der anderen Seite: Wird der Sortimentsname geändert („Food" wird zu „Lebensmittel"), reicht ein Update in dim_sortiment. Im Star-Schema müsste jede Zeile in dim_produkt mit demselben Sortimentsnamen einzeln aktualisiert werden.

Für BI-Werkzeuge wie Power BI oder Tableau ist das Snowflake-Modell schwerer greifbar, weil die Attribut-Hierarchie über mehrere Tabellen läuft. Praxisübliche Kompromisse sind Views, die das Snowflake-Modell für die Endanwender wieder zu einem flachen Star-Schema abflachen, oder eine semantische Schicht darüber, die die Joins vor dem Anwender verbirgt.