Data Warehousing Grundlagen mit SQL: Star-Schema, Fakten und Dimensionen

1. Was Data Warehousing wirklich loest

Data Warehousing strukturiert Daten fuer Analysen ueber grosse Zeitraeume und grosse Datenmengen, im Unterschied zu einer transaktionalen Datenbank, die auf schnelle Einzelzugriffe optimiert ist. Eine normalisierte, transaktionale Schema-Struktur mit vielen kleinen, ueber Fremdschluessel verbundenen Tabellen ist fuer Analysten und Reporting-Tools unhandlich: Jede Abfrage braucht zahlreiche Joins, um eine einfache Kennzahl wie den Umsatz pro Monat und Region zu berechnen.

Data Warehousing loest dieses Problem durch eine dedizierte, analyseoptimierte Schema-Struktur, das Star-Schema. Zentrale Kennzahlen liegen in einer Faktentabelle, Kontext-Informationen in Dimensionstabellen, und beide sind so verbunden, dass typische Analyse-Queries mit minimaler Join-Komplexitaet auskommen. Die folgenden Abschnitte zeigen, wie Star-Schema, Faktentabellen und Dimensionstabellen konkret aufgebaut sind, wie man mit sich aendernden Dimensionsdaten umgeht und wie Aggregations-Queries darauf performant laufen.

2. Das Star-Schema als zentrale Struktur

Das Star-Schema ordnet eine zentrale Faktentabelle sternfoermig um mehrere Dimensionstabellen an. Die Faktentabelle enthaelt messbare Ereignisse (Bestellungen, Klicks, Transaktionen) als Zeilen, jede mit Fremdschluesseln auf die relevanten Dimensionen (Kunde, Produkt, Zeit, Region) und den eigentlichen Kennzahlen (Umsatz, Menge, Rabatt). Der Name Data Warehousing-Star-Schema kommt vom visuellen Erscheinungsbild: die Faktentabelle im Zentrum, Dimensionstabellen wie Sternzacken ringsherum.

Der grosse Vorteil dieser Struktur: Eine typische Analyse-Query braucht nur einen einzigen Join-Level, von der Faktentabelle direkt zu jeder benoetigten Dimension, statt mehrerer verschachtelter Joins wie in einem normalisierten transaktionalen Schema. Das macht Queries fuer Analysten lesbar und fuer den Datenbank-Optimizer effizient planbar, weil Join-Reihenfolge und Join-Strategie bei einem Star-Schema deutlich vorhersagbarer sind.

-- Star schema: one fact table, three dimension tables
CREATE TABLE dim_customer (
  customer_key SERIAL PRIMARY KEY,
  customer_id INT NOT NULL,
  customer_name VARCHAR(200),
  segment VARCHAR(50)
);

CREATE TABLE dim_product (
  product_key SERIAL PRIMARY KEY,
  product_id INT NOT NULL,
  product_name VARCHAR(200),
  category VARCHAR(100)
);

CREATE TABLE dim_date (
  date_key INT PRIMARY KEY, -- e.g. 20260730
  full_date DATE NOT NULL,
  year INT,
  quarter INT,
  month INT
);

CREATE TABLE fact_sales (
  sale_id BIGSERIAL PRIMARY KEY,
  customer_key INT REFERENCES dim_customer(customer_key),
  product_key INT REFERENCES dim_product(product_key),
  date_key INT REFERENCES dim_date(date_key),
  quantity INT NOT NULL,
  revenue_eur NUMERIC(12,2) NOT NULL
);

3. Faktentabellen: Kennzahlen und Granularitaet

Die Faktentabelle im Zentrum jedes Data Warehousing-Modells enthaelt die eigentlichen messbaren Groessen, meist numerische Kennzahlen wie Umsatz, Menge oder Dauer. Entscheidend ist die Granularitaet einer Faktentabelle, also die Frage, was genau eine einzelne Zeile repraesentiert. Eine Zeile pro einzelnem Verkauf ist feiner granular als eine Zeile pro Tag und Produkt, erlaubt aber flexiblere Aggregationen im Nachhinein.

Die Granularitaet einmal festgelegt, sollte sie nicht mehr geaendert werden, ohne die gesamte Faktentabelle neu aufzubauen. Additive Kennzahlen (Umsatz, Menge) lassen sich ueber jede Dimension problemlos summieren. Semi-additive Kennzahlen (Lagerbestand) lassen sich ueber manche Dimensionen summieren, aber nicht ueber Zeit, weil ein Lagerbestand am Monatsende nicht mit dem Lagerbestand des Vormonats addiert werden darf. Diese Unterscheidung ist zentral fuer korrekte Aggregations-Queries im Data Warehousing.

4. Dimensionstabellen: Kontext fuer Fakten

Dimensionstabellen liefern den beschreibenden Kontext zu den Kennzahlen in der Faktentabelle: wer, was, wann, wo. Im Gegensatz zur Faktentabelle, die schnell waechst (jede Transaktion erzeugt eine neue Zeile), aendern sich Dimensionstabellen selten und sind meist deutlich kleiner. Eine gute Dimensionstabelle im Data Warehousing denormalisiert bewusst: Statt einer Kunden-Dimension mit Fremdschluessel auf eine separate Land-Tabelle enthaelt sie den Laendernamen direkt als Spalte, um Joins zu vermeiden.

Diese bewusste Denormalisierung ist ein zentraler Unterschied zwischen transaktionalen Schemas und Data Warehousing-Schemas. In einer transaktionalen Datenbank waere Redundanz ein Anzeichen fuer schlechtes Design, in einem Data Warehouse ist sie eine bewusste Optimierung fuer Lesegeschwindigkeit, weil Schreiblast in einem Warehouse eine untergeordnete Rolle spielt gegenueber Lesegeschwindigkeit fuer Analysen.

5. Slowly Changing Dimensions verwalten

Ein zentrales Problem im Data Warehousing: Dimensionsdaten aendern sich gelegentlich, etwa wenn ein Kunde in ein anderes Verkaufsgebiet umzieht. Eine Slowly Changing Dimension vom Typ 1 ueberschreibt den alten Wert einfach, verliert dabei aber die Historie, was fuer manche Analysen problematisch ist, wenn historische Umsaetze ruecknachtraeglich dem neuen Verkaufsgebiet zugeordnet werden, obwohl sie im alten Gebiet entstanden sind.

Eine Slowly Changing Dimension vom Typ 2 loest dieses Problem, indem sie bei jeder Aenderung eine neue Zeile mit Gueltigkeitszeitraum anlegt, statt die alte zu ueberschreiben. Die Faktentabelle referenziert dann immer die zum Zeitpunkt des Ereignisses gueltige Version der Dimension. Dieses Muster ist im Data Warehousing Standard, weil es historische Korrektheit garantiert, ohne die Faktentabelle selbst anpassen zu muessen.

-- Slowly Changing Dimension Type 2: keep full history
CREATE TABLE dim_customer_scd2 (
  customer_key SERIAL PRIMARY KEY,
  customer_id INT NOT NULL,
  region VARCHAR(100),
  valid_from DATE NOT NULL,
  valid_to DATE,           -- NULL = currently active
  is_current BOOLEAN NOT NULL DEFAULT TRUE
);

-- When a customer's region changes: close the old row, insert a new one
UPDATE dim_customer_scd2
SET valid_to = '2026-07-29', is_current = FALSE
WHERE customer_id = 4821 AND is_current = TRUE;

INSERT INTO dim_customer_scd2 (customer_id, region, valid_from, valid_to, is_current)
VALUES (4821, 'DACH-Nord', '2026-07-30', NULL, TRUE);

-- Fact rows always reference the customer_key valid at event time
SELECT f.revenue_eur, d.region
FROM fact_sales f
JOIN dim_customer_scd2 d ON f.customer_key = d.customer_key;

6. Star-Schema vs. Snowflake-Schema

Das Snowflake-Schema ist eine Variante des Star-Schemas, bei der Dimensionstabellen selbst weiter normalisiert werden, statt bewusst denormalisiert zu bleiben. Eine Produkt-Dimension wird beispielsweise in Produkt, Kategorie und Unterkategorie aufgeteilt, jede als separate Tabelle mit eigenen Fremdschluesseln. Dieses Muster reduziert Redundanz, erhoeht aber die Anzahl der noetigen Joins fuer eine typische Analyse-Query im Data Warehousing.

In der Praxis bevorzugen die meisten modernen Data-Warehouse-Systeme das Star-Schema gegenueber dem Snowflake-Schema, weil Speicherplatz in Cloud-Warehouses guenstig ist, waehrend Query-Performance und Lesbarkeit fuer Analysten deutlich wichtiger sind. Snowflake-Schemas lohnen sich vor allem bei sehr grossen, sich haeufig aendernden Dimensionen, bei denen die Redundanz des Star-Schemas zu spuerbarem Speicherplatz- oder Wartungsaufwand fuehrt.

-- Snowflake schema: product dimension normalized into separate tables
CREATE TABLE dim_category (
  category_key SERIAL PRIMARY KEY,
  category_name VARCHAR(100)
);

CREATE TABLE dim_product_snowflake (
  product_key SERIAL PRIMARY KEY,
  product_name VARCHAR(200),
  category_key INT REFERENCES dim_category(category_key)
);

-- Same query now needs one extra join compared to the star schema version
SELECT cat.category_name, SUM(f.revenue_eur)
FROM fact_sales f
JOIN dim_product_snowflake p ON f.product_key = p.product_key
JOIN dim_category cat ON p.category_key = cat.category_key
GROUP BY cat.category_name;

7. Aggregations-Queries ueber grosse Faktentabellen

Der eigentliche Zweck eines Data Warehousing-Systems zeigt sich in Aggregations-Queries: Summen, Durchschnitte und Zaehlungen ueber Millionen oder Milliarden Zeilen der Faktentabelle, gruppiert nach einer oder mehreren Dimensionen. Diese Queries profitieren enorm von spaltenorientierter Speicherung (Column-Store), wie sie moderne Data Warehouses (Snowflake, BigQuery, ClickHouse) nutzen, weil nur die tatsaechlich benoetigten Spalten gelesen werden muessen, statt kompletter Zeilen.

Partitionierung der Faktentabelle nach der Zeit-Dimension (etwa nach Monat) beschleunigt Aggregations-Queries zusaetzlich, weil der Optimizer Partitionen ausserhalb des abgefragten Zeitraums komplett ueberspringen kann (Partition Pruning). Diese Kombination aus Star-Schema, Spaltenorientierung und Zeit-Partitionierung ist der Grund, warum Data Warehousing-Systeme Aggregationen ueber riesige Datenmengen in Sekunden statt Minuten liefern.

-- Typical warehouse aggregation: revenue by region and month
SELECT
  d.year,
  d.month,
  c.segment,
  SUM(f.revenue_eur) AS total_revenue,
  COUNT(*) AS number_of_sales
FROM fact_sales f
JOIN dim_date d ON f.date_key = d.date_key
JOIN dim_customer c ON f.customer_key = c.customer_key
WHERE d.year = 2026
GROUP BY d.year, d.month, c.segment
ORDER BY d.month, total_revenue DESC;

8. OLAP-Cubes und Materialized Views

Ein OLAP-Cube ist eine vorab berechnete, mehrdimensionale Aggregation eines Star-Schemas, die typische Analyse-Queries noch schneller macht, weil die Summen nicht erst zur Abfragezeit berechnet werden. Klassische OLAP-Server wie SQL Server Analysis Services verwalten diese Cubes explizit, moderne Cloud-Warehouses erreichen aehnliche Performance meist einfacher ueber Materialized Views, die die Ergebnisse haeufiger Aggregations-Queries zwischenspeichern und periodisch aktualisieren.

Der Trade-off bei beiden Ansaetzen im Data Warehousing ist derselbe: Vorab berechnete Aggregationen beschleunigen Leseabfragen erheblich, muessen aber bei jeder Aenderung der zugrundeliegenden Faktentabelle aktualisiert werden, entweder inkrementell oder durch vollstaendige Neuberechnung. Fuer haeufig abgefragte, aber selten sich aendernde Aggregationen (etwa monatliche Umsatzberichte) ist dieser Trade-off fast immer profitabel.

-- Materialized view: precompute a frequent aggregation
CREATE MATERIALIZED VIEW mv_monthly_revenue AS
SELECT d.year, d.month, c.segment, SUM(f.revenue_eur) AS total_revenue
FROM fact_sales f
JOIN dim_date d ON f.date_key = d.date_key
JOIN dim_customer c ON f.customer_key = c.customer_key
GROUP BY d.year, d.month, c.segment;

-- Refresh periodically, e.g. via a nightly scheduled job
REFRESH MATERIALIZED VIEW CONCURRENTLY mv_monthly_revenue;

-- Reporting queries hit the precomputed view instead of the raw fact table
SELECT * FROM mv_monthly_revenue WHERE year = 2026 ORDER BY month;

9. Data-Warehouse-Modelle im Vergleich

Die folgende Tabelle vergleicht die zentralen Schema-Ansaetze im Data Warehousing.

Fuer die meisten neuen Data Warehousing-Projekte ist ein Star-Schema mit Materialized Views fuer die haeufigsten Aggregationen der pragmatischste Startpunkt. Snowflake-Schemas und dedizierte OLAP-Cubes lohnen sich erst bei sehr spezifischen Anforderungen an Speicherplatz-Effizienz oder feste, hochfrequentierte Report-Strukturen.

10. Zusammenfassung

Data Warehousing strukturiert Daten fuer Analysen statt fuer transaktionale Schreibgeschwindigkeit, meist ueber ein Star-Schema mit einer zentralen Faktentabelle und mehreren Dimensionstabellen. Faktentabellen enthalten messbare Kennzahlen mit fest definierter Granularitaet, Dimensionstabellen liefern bewusst denormalisierten Kontext. Slowly Changing Dimensions vom Typ 2 bewahren historische Korrektheit, wenn sich Dimensionsdaten aendern.

Spaltenorientierte Speicherung, Zeit-Partitionierung und Materialized Views machen Aggregations-Queries ueber riesige Faktentabellen performant, ohne auf dedizierte OLAP-Cubes angewiesen zu sein. Wer Data Warehousing von Anfang an mit klarer Granularitaet und durchdachtem SCD-Handling aufbaut, vermeidet die teuren Nacharbeiten, die ein nachtraeglich umgebautes Schema erfordert.

11. FAQ: Data Warehousing Grundlagen mit SQL