Data Warehouse Modellierung mit Claude: Star Schema und Dimensional Modeling

1. Warum Data Warehouse Modellierung ein eigenes Vorgehen braucht

Data Warehouse Modellierung unterscheidet sich fundamental von klassischem OLTP-Schema-Design. Während ein transaktionales System auf Normalisierung, kurze Schreibpfade und Konsistenzsicherung optimiert ist, zielt ein analytisches Modell auf schnelle Lesezugriffe über große Datenmengen, verständliche Struktur für Analysten und stabile historische Auswertbarkeit. Wer diese beiden Welten vermischt, produziert Data-Warehouse-Schemata, die zwar normalisiert, aber für Reporting-Abfragen unbrauchbar langsam sind.

Claude für Data Warehouse Modellierung kennt die etablierten Muster aus Ralph Kimballs dimensionalem Modellierungsansatz: Faktentabellen mit Kennzahlen, Dimensionstabellen mit beschreibenden Attributen, und ein Star Schema als zentrale Struktur. Der Mehrwert liegt darin, dass Claude aus einer Beschreibung des Quellsystems und der geplanten Analysen ein passendes dimensionales Modell ableiten kann, statt jede Entscheidung von Grund auf neu zu treffen.

Wichtig ist die Abgrenzung zu generischem Schema-Design: Es geht hier nicht um die Frage, ob eine einzelne Tabelle normalisiert ist, sondern um die gesamte analytische Architektur mit Fakten, Dimensionen, Granularität und historischer Nachverfolgung von Änderungen. Die folgenden Abschnitte behandeln genau diese spezifischen Fragen der Data Warehouse Modellierung.

2. Fakten- und Dimensionstabellen mit Claude entwerfen

Der Ausgangspunkt jeder Data Warehouse Modellierung ist die Unterscheidung zwischen Fakten und Dimensionen. Eine Faktentabelle enthält die messbaren Kennzahlen eines Geschäftsvorgangs, etwa Umsatz, Menge oder Bearbeitungsdauer, zusammen mit Fremdschlüsseln auf die zugehörigen Dimensionen. Dimensionstabellen liefern den beschreibenden Kontext, etwa Produkt, Kunde, Zeit oder Standort. Claude hilft, aus einer Beschreibung des Geschäftsprozesses die richtige Aufteilung vorzuschlagen, inklusive der Frage, welche Attribute in die Faktentabelle gehören und welche besser als Dimension modelliert werden.

-- Star schema: fact_orders surrounded by conformed dimensions
CREATE TABLE dim_date (
  date_key        INT PRIMARY KEY,
  full_date       DATE NOT NULL,
  day_of_week     SMALLINT NOT NULL,
  month_name      VARCHAR(20) NOT NULL,
  quarter         SMALLINT NOT NULL,
  fiscal_year     SMALLINT NOT NULL,
  is_weekend      BOOLEAN NOT NULL
);

CREATE TABLE dim_product (
  product_key     SERIAL PRIMARY KEY,
  product_id      INT NOT NULL,     -- natural key from source system
  product_name    VARCHAR(255) NOT NULL,
  category        VARCHAR(100) NOT NULL,
  brand           VARCHAR(100),
  valid_from      DATE NOT NULL,
  valid_to        DATE,
  is_current      BOOLEAN NOT NULL DEFAULT TRUE
);

CREATE TABLE fact_orders (
  order_line_key  BIGSERIAL PRIMARY KEY,
  date_key        INT NOT NULL REFERENCES dim_date(date_key),
  product_key     INT NOT NULL REFERENCES dim_product(product_key),
  customer_key    INT NOT NULL REFERENCES dim_customer(customer_key),
  quantity        INT NOT NULL,
  unit_price      NUMERIC(12,2) NOT NULL,
  net_revenue     NUMERIC(12,2) NOT NULL,
  discount_amount NUMERIC(12,2) NOT NULL DEFAULT 0
);

Ein häufiger Anfängerfehler ist, Attribute wie den Produktnamen direkt in die Faktentabelle zu schreiben, statt über den Fremdschlüssel auf die Dimension zu verweisen. Das führt zu Redundanz und macht historische Änderungen am Produktnamen unmöglich nachzuvollziehen. Claude weist auf solche Modellierungsfehler zuverlässig hin, wenn man den Tabellenentwurf zur Prüfung vorlegt.

3. Slowly Changing Dimensions mit Claude implementieren

Dimensionsattribute ändern sich über die Zeit, etwa wenn ein Kunde die Adresse wechselt oder ein Produkt in eine andere Kategorie verschoben wird. Slowly Changing Dimensions vom Typ 2 lösen dieses Problem, indem bei einer Änderung eine neue Zeile mit neuem Surrogate Key angelegt wird, statt die bestehende Zeile zu überschreiben. So bleibt die historische Zuordnung in vergangenen Fakten korrekt erhalten. Claude für Data Warehouse Modellierung generiert das entsprechende Upsert-Muster inklusive Gültigkeitszeiträumen.

-- SCD Type 2 upsert: close old version, insert new version
WITH changed_rows AS (
  SELECT s.product_id, s.product_name, s.category, s.brand
  FROM staging_products s
  JOIN dim_product d ON d.product_id = s.product_id AND d.is_current = TRUE
  WHERE d.category IS DISTINCT FROM s.category
     OR d.brand IS DISTINCT FROM s.brand
)
UPDATE dim_product d
SET valid_to = CURRENT_DATE - INTERVAL '1 day',
    is_current = FALSE
FROM changed_rows c
WHERE d.product_id = c.product_id AND d.is_current = TRUE;

INSERT INTO dim_product (product_id, product_name, category, brand, valid_from, valid_to, is_current)
SELECT product_id, product_name, category, brand, CURRENT_DATE, NULL, TRUE
FROM changed_rows;

Bei der Implementierung ist entscheidend, dass Faktentabellen niemals direkt auf den natürlichen Schlüssel, sondern immer auf den Surrogate Key der zum Zeitpunkt des Geschäftsvorgangs gültigen Dimensionsversion verweisen. Claude kann diese Referenzierungslogik im ETL-Prozess durchgängig prüfen und typische Fehler wie das versehentliche Verknüpfen mit der aktuellen statt der historisch korrekten Dimensionsversion aufdecken.

4. Granularität und Surrogate Keys richtig wählen

Die Granularität einer Faktentabelle, also die Frage, was genau eine Zeile repräsentiert, ist die wichtigste und am schwersten nachträglich änderbare Designentscheidung eines Data Warehouse. Eine Faktentabelle auf Bestellzeilen-Ebene erlaubt granulare Analysen, eine auf Bestellungs-Ebene aggregierte Tabelle ist kompakter, verliert aber Detailinformationen. Claude hilft, die Granularität anhand konkreter geplanter Fragestellungen zu bestimmen, etwa ob Analysten jemals einzelne Produktzeilen innerhalb einer Bestellung auswerten müssen.

Surrogate Keys statt natürlicher Schlüssel als Primärschlüssel in Dimensionen zu verwenden ist ein weiteres zentrales Muster. Natürliche Schlüssel aus Quellsystemen können sich ändern, mehrdeutig sein oder zwischen mehreren Quellsystemen kollidieren. Ein künstlicher, fortlaufender Surrogate Key entkoppelt das Warehouse von diesen Unsicherheiten und ist zusätzlich performanter für JOIN-Operationen als zusammengesetzte natürliche Schlüssel.

5. dbt-Modelle mit Claude generieren lassen

dbt hat sich als Standardwerkzeug etabliert, um Transformationslogik für Data Warehouses versioniert, testbar und dokumentiert zu halten. Claude für Data Warehouse Modellierung generiert vollständige dbt-Modelle inklusive Schema-Definitionen mit Tests für Eindeutigkeit und referenzielle Integrität, was manuell zu schreiben zeitaufwendig ist.

# schema.yml — dbt model definitions with built-in data tests
version: 2

models:
  - name: fact_orders
    description: "Order line grain fact table, one row per product line item"
    columns:
      - name: order_line_key
        tests: [unique, not_null]
      - name: date_key
        tests:
          - not_null
          - relationships: { to: ref('dim_date'), field: date_key }
      - name: product_key
        tests:
          - not_null
          - relationships: { to: ref('dim_product'), field: product_key }
      - name: net_revenue
        tests:
          - not_null
          - dbt_utils.accepted_range: { min_value: 0 }

  - name: dim_product
    description: "SCD Type 2 product dimension"
    columns:
      - name: product_key
        tests: [unique, not_null]
      - name: product_id
        tests: [not_null]
      - name: is_current
        tests:
          - accepted_values: { values: [true, false] }

Der Vorteil dieses Vorgehens liegt darin, dass Modelldefinition und Datenqualitätsprüfung in einem einzigen, versionierten Artefakt zusammenfallen. Claude kann zusätzlich aus einer bestehenden SQL-Transformation ein passendes dbt-Modell inklusive Materialisierungsstrategie ableiten, etwa ob ein Modell als View, Table oder inkrementelles Modell gebaut werden sollte.

6. Vom OLTP-Quellsystem zum dimensionalen Mapping

Der Übergang vom relationalen Quellsystem zum dimensionalen Modell erfordert ein explizites Mapping: Welche Quelltabellen liefern welche Dimension, welche Transaktionstabelle wird zur Faktentabelle, und wie werden mehrere Quelltabellen zu einer konsolidierten Dimension zusammengeführt. Claude unterstützt dabei, dieses Mapping systematisch zu dokumentieren und in ausführbaren Transformationscode zu übersetzen.

import pandas as pd

# Map OLTP source tables to the conformed customer dimension
customers_raw = pd.read_sql("SELECT * FROM oltp.customers", oltp_conn)
addresses_raw = pd.read_sql("SELECT * FROM oltp.customer_addresses WHERE is_primary = true", oltp_conn)

dim_customer = (
    customers_raw
    .merge(addresses_raw, on="customer_id", how="left")
    .assign(
        customer_key=lambda df: df.index + 1,
        valid_from=pd.Timestamp.today().normalize(),
        valid_to=pd.NaT,
        is_current=True,
    )
    .rename(columns={"city": "billing_city", "country": "billing_country"})
    [["customer_key", "customer_id", "full_name", "billing_city",
      "billing_country", "valid_from", "valid_to", "is_current"]]
)

dim_customer.to_sql("dim_customer", warehouse_conn, if_exists="append", index=False)

Ein häufiger Fehler bei diesem Mapping ist, mehrere Adressen pro Kunde ohne klare Priorisierung zu verarbeiten, wodurch Duplikate in der Dimension entstehen. Claude weist bei der Codeprüfung typischerweise darauf hin, eine eindeutige Filterbedingung wie die primäre Adresse zu definieren, bevor die Zusammenführung stattfindet.

7. Partitionierung und Indexierung im Data Warehouse

Faktentabellen wachsen schnell auf mehrstellige Millionen Zeilen, weshalb Partitionierung nach Zeit, meist nach Monat oder Quartal, zum Standardmuster gehört. Claude hilft, eine passende Partitionierungsstrategie basierend auf dem erwarteten Abfragemuster vorzuschlagen, etwa ob die meisten Analysten nach den letzten zwölf Monaten filtern oder ganze Historien scannen.

-- Range partitioning by month for fact_orders
CREATE TABLE fact_orders (
  order_line_key  BIGSERIAL,
  date_key        INT NOT NULL,
  product_key     INT NOT NULL,
  customer_key    INT NOT NULL,
  net_revenue     NUMERIC(12,2) NOT NULL,
  order_date      DATE NOT NULL
) PARTITION BY RANGE (order_date);

CREATE TABLE fact_orders_2026_07 PARTITION OF fact_orders
  FOR VALUES FROM ('2026-07-01') TO ('2026-08-01');

CREATE INDEX idx_fact_orders_2026_07_product ON fact_orders_2026_07 (product_key);
CREATE INDEX idx_fact_orders_2026_07_customer ON fact_orders_2026_07 (customer_key);

Ohne Partitionierung müssen Abfragen, die nur den letzten Monat betreffen, trotzdem die gesamte Tabelle scannen, was bei wachsenden Datenmengen zunehmend spürbar wird. Claude weist zusätzlich darauf hin, wann eine spaltenorientierte Speicherung, etwa in Snowflake oder BigQuery, das Partitionierungsproblem für analytische Workloads von vornherein anders löst als eine zeilenorientierte Datenbank.

8. Validierung und Tests des Warehouse-Modells

Ein dimensionales Modell ohne systematische Validierung führt zu stillen Fehlern, etwa doppelten Fakten durch fehlerhafte JOINs oder falschen Summen durch fehlende Filterbedingungen bei historischen Dimensionsversionen. Claude für Data Warehouse Modellierung hilft, Validierungsabfragen zu entwerfen, die genau diese Fehlerklassen systematisch aufdecken, bevor ein neues Modell produktiv geschaltet wird.

Ein bewährtes Muster ist der Abgleich der aggregierten Summe aus der Faktentabelle gegen eine unabhängig berechnete Kontrollsumme aus dem Quellsystem für denselben Zeitraum. Weichen beide Werte ab, deutet das auf doppelte Zeilen, verlorene Datensätze beim Laden oder falsche Join-Bedingungen hin. Claude kann solche Abgleichsabfragen als festen Bestandteil der Deployment-Pipeline vorschlagen, sodass Modellfehler automatisch auffallen, statt erst bei einem falschen Management-Report entdeckt zu werden.

9. OLTP-Schema und dimensionales Modell im Vergleich

Die folgende Tabelle stellt die wichtigsten Unterschiede zwischen einem normalisierten OLTP-Schema und einem dimensionalen Data-Warehouse-Modell gegenüber.

Beide Modellwelten haben ihre Berechtigung, gelöst wird jeweils ein anderes Problem. Claude hilft, an der Schnittstelle zwischen beiden ein konsistentes, gut dokumentiertes dimensionales Modell aufzubauen, ohne die typischen Modellierungsfehler wiederholen zu müssen.

10. Zusammenfassung

Data Warehouse Modellierung mit Claude beginnt mit der klaren Trennung von Fakten- und Dimensionstabellen im Star Schema und der richtigen Wahl der Granularität, bevor überhaupt ETL-Code entsteht. Slowly Changing Dimensions vom Typ 2 sichern historische Korrektheit, Surrogate Keys entkoppeln das Warehouse von Unsicherheiten in Quellsystemen. dbt-Modelle mit eingebauten Tests machen Transformationslogik versioniert und überprüfbar.

Partitionierung nach Zeitraum und systematische Validierungsabfragen gegen unabhängige Kontrollsummen runden das Vorgehen ab. Claude ersetzt nicht die fachliche Entscheidung über Granularität und geschäftliche Kennzahlen, liefert aber einen fundierten, technisch korrekten Entwurf, der die typischen Modellierungsfehler vermeidet, die in gewachsenen Data Warehouses regelmäßig zu falschen Reports führen.

11. FAQ: Data Warehouse Modellierung mit Claude