Was ist ein Star Schema, und wann würdest du eine Dimension stattdessen snowflaken?

Ein Star Schema hat eine Faktentabelle, umgeben von denormalisierten Dimensionstabellen, sodass die meisten Queries einen Join pro Dimension brauchen. Snowflaking normalisiert eine Dimension in Untertabellen, was Storage spart und geteilte Attribute zentralisiert, aber Joins hinzufügt. In einem spaltenorientierten Warehouse ist Storage billig und Joins kosten mehr als Duplikate, also ist Star der Standard. Snowflake eine Dimension, wenn sie wirklich groß, hierarchisch oder über viele Marts geteilt ist.

Ein Star ist eine Faktentabelle auf definierter Granularität mit denormalisierten Dimensionen daran, sodass eine Analystin einen Join pro Dimension schreibt und lesbare Spaltennamen bekommt. Das ist mein Standard, denn in einem spaltenorientierten Warehouse komprimiert ein Ländername, der sich über zwei Millionen Zeilen wiederholt, auf fast nichts, und die kleine Dimension wird ohnehin gebroadcastet. Snowflaking ergibt Sinn, wenn die Dimension tatsächlich groß und hierarchisch ist, zum Beispiel eine Produktdimension mit einem Kategoriebaum, den mehrere Marts teilen müssen, denn diese Hierarchie an einer Stelle zu pflegen schlägt fünf Kopien. Was ich vor beidem ansprechen würde, ist die Granularität. Die Entscheidung, dass die Faktentabelle eine Zeile pro Bestellposition statt pro Bestellung hat, bestimmt alles danach, und ein Fehler dort erzeugt den klassischen Bug mit doppelt gezähltem Umsatz. Ich musste schon einen Mart neu bauen, weil die Granularität gemischt war, und das ist deutlich teurer als jede Normalisierungsdebatte.