Data Warehouse: Definition, Architektur und Abgrenzung

Ein Data Warehouse (deutsch: Datenlager, abgekürzt DWH) ist eine zentrale Analyse-Datenbank, die Geschäftsdaten aus den täglichen Arbeitssystemen eines Unternehmens (etwa Warenwirtschaft, Kassensystem, CRM) einsammelt, aufräumt und in einer festen Struktur für Auswertungen ablegt. Die Daten liegen dort historisiert (also mit Zeitstempel und in ihrer zeitlichen Abfolge), damit Berichte, Dashboards und Business Intelligence (datengestützte Analyse für Entscheidungen) verlässliche Zahlen liefern. Das Warehouse ist bewusst vom laufenden Betrieb getrennt: Es beantwortet Fragen zu großen Datenmengen und Zeitverläufen, ohne die operativen Systeme zu belasten.

Was ist ein Data Warehouse?

Ein Data Warehouse führt Geschäftsdaten aus mehreren Vorsystemen (etwa dem ERP für Warenwirtschaft, dem CRM für Kunden und dem Webshop für Bestellungen) an einem Ort zusammen. Dort werden die Daten bereinigt, um eine gemeinsame Sprache gebracht (gleiche Kundennummern, gleiche Einheiten, gleiche Codes) und mit Zeitstempel abgelegt, damit auch historische Zustände abfragbar bleiben. Aufgebaut ist ein Warehouse typischerweise in drei Schichten: einer Eingangsschicht (Staging) für die Rohkopien aus den Quellsystemen, einer Kern-Schicht mit dem integrierten, historisierten Unternehmensmodell und einer Auswertungs-Schicht, in der die Daten so aufbereitet sind, dass Berichts-Werkzeuge wie Power BI oder Tableau sie direkt lesen können. Den Weg von den Quellsystemen bis in die Auswertungs-Schicht übernehmen ETL- oder ELT-Prozesse (Werkzeuge, die Daten extrahieren, umformen und laden).

Der Begriff geht auf Bill Inmon zurück, der ihn in „Building the Data Warehouse" (1990/1992) systematisierte. Inmons Definition nennt vier Eigenschaften: subject-oriented (Daten sind nach Geschäftsobjekten wie Kunde oder Produkt organisiert, nicht nach Quellsystem), integrated (heterogene Quellcodes, Schlüssel und Einheiten werden vereinheitlicht), non-volatile (Daten werden geschrieben und gelesen, aber nicht laufend überschrieben) und time-variant (jede Beladung ist versioniert, historische Zustände bleiben abfragbar). Diese vier Merkmale grenzen ein Warehouse strukturell von operativen Datenbanken und von reinen Speicher-Systemen ab.

Der Schema-on-Write-Ansatz ist die zentrale Mechanik. Das Datenmodell wird vor der Beladung definiert; alle Daten müssen sich vor dem Persistieren in dieses Modell einpassen. Damit erzwingt das Warehouse Konsistenz, Datentypen und Integritätsregeln zum Ladezeitpunkt. Der Preis ist Modellierungs-Aufwand vor jeder neuen Quelle; der Gewinn ist eine belastbare, dokumentierte Datenbasis mit stabilen Kennzahl-Definitionen.

Architektonisch hat sich das Warehouse-Muster über drei Generationen weiterentwickelt: On-Premises-Appliances wie Teradata, Netezza oder Oracle Exadata mit gekoppeltem Compute und Storage; Cloud-native Warehouses wie Snowflake, Google BigQuery, Amazon Redshift und Azure Synapse mit entkoppelten Ressourcen und elastischer Skalierung; und Warehouse-Layer auf Data-Lakehouse-Plattformen wie Databricks SQL oder Microsoft Fabric, die die Warehouse-Eigenschaften auf offene Tabellenformate über Objekt-Speicher setzen. Die Rolle des Warehouse in der Datenarchitektur ist über die Generationen stabil geblieben; die Speicher- und Betriebs-Ökonomie hat sich verschoben.

Abgrenzung zu Data Lake, Data Lakehouse, Data Mart und OLTP

Der Begriff Data Warehouse wird in Praxis-Diskussionen häufig mit verwandten Speicher-Konzepten vermischt, die entweder auf einer anderen Ebene der Architektur liegen oder eine andere Speicher-Philosophie tragen.

Begriff	Achse	Kernunterschied
Data Lake	Speicher-Philosophie	Der Data Lake speichert Rohdaten formatoffen auf Objekt-Speicher mit Schema-on-Read. Das Warehouse persistiert modellierte Daten in einem festen Schema (Schema-on-Write).
Data Lakehouse	Ebene	Das Lakehouse bringt Warehouse-Eigenschaften (ACID, Schema-Enforcement, Katalog) auf die Lake-Speicherung. Ein klassisches Warehouse ist ein geschlossenes Speicher- und Compute-System, das Lakehouse ist offener Speicher plus Warehouse-Schicht darüber.
Data Mart	Reichweite	Ein Data Mart ist ein themen- oder fachbereichsspezifischer Ausschnitt eines Warehouse (Vertrieb, Finance, Marketing). Das Warehouse ist der integrierte Gesamtbestand, aus dem Marts abgeleitet werden.
Operative Datenbank (OLTP)	Workload	Eine OLTP-Datenbank ist auf schnelle Einzelsatz-Transaktionen optimiert (Zeilenspeicher, hohe Schreiblast). Das Warehouse ist auf große Lese-Aggregationen optimiert (Spaltenspeicher, OLAP).
Cloud Data Warehouse	Betriebsmodell	Cloud-native Ausprägung des Warehouse-Musters (Snowflake, BigQuery, Redshift) mit entkoppeltem Compute und Storage. Dieselbe logische Rolle, andere Speicher- und Kosten-Ökonomie als On-Premises-Appliances.

Die wichtigste Abgrenzung verläuft zwischen Data Warehouse und Data Lake. Beide sind Speicher-Architekturen für Analyse-Daten und unterscheiden sich grundlegend in der Modellierungs-Philosophie. Das Warehouse zwingt die Modellierung an den Anfang der Pipeline (Ingest gegen ein definiertes Schema), der Lake verschiebt sie ans Ende (Modellierung beim Lesen oder in Downstream-Layern). Warehouse-Governance ist stärker, Lake-Flexibilität ist höher. Moderne Lakehouse-Plattformen führen beide Welten in einer Speicher-Schicht zusammen.

Die zweite häufige Verwechslung betrifft Data Warehouse und Data Mart. Der Mart ist eine logische Teilmenge des Warehouse für eine Fachdomäne. Kimballs Bus-Architektur versteht das Enterprise Data Warehouse sogar als Verbund konformer Marts mit gemeinsamen Dimensionen; Inmons Corporate Information Factory baut zuerst das integrierte Warehouse in dritter Normalform und leitet anschließend abhängige Marts daraus ab. Beide Schulen führen zu demselben Ergebnis auf unterschiedlichen Wegen: einem integrierten Analyse-Bestand mit thematischen Ausschnitten für Fachbereiche.

Inmon vs. Kimball: die zwei Schulen der Warehouse-Modellierung

Die Warehouse-Praxis hat sich entlang zweier Modellierungs-Schulen entwickelt, die bis heute in Cloud-Warehouses und Lakehouse-Plattformen nachwirken.

Bill Inmons Ansatz (Corporate Information Factory) legt zuerst ein normalisiertes Enterprise Data Warehouse in dritter Normalform (3NF) an. Die Modellierung folgt dem Datenbestand des Unternehmens, orientiert sich also am gesamten integrierten Datenmodell statt am konkreten Analyse-Bedarf einer Fachdomäne. Aus diesem integrierten Kern werden abhängige Data Marts für Fachbereiche materialisiert. Vorteil: eine einzige, konsistente Wahrheit über alle Marts. Kosten: höherer Modellierungs-Aufwand vor der ersten Auswertung.

Ralph Kimballs Ansatz (Dimensional Modeling) beginnt mit dem Analyse-Bedarf der Fachbereiche und baut das Warehouse als Verbund konformer Data Marts mit gemeinsamen Dimensionen (Conformed Dimensions). Fakten-Tabellen enthalten Geschäftsereignisse (Verkauf, Bestellung, Klick), Dimensions-Tabellen die Kontext-Attribute (Kunde, Produkt, Zeit, Region). Vorteil: schnellerer Time-to-First-Report und einfachere Modelle für BI-Anwender. Kosten: die Integrität zwischen den Marts hängt an der Disziplin bei den Conformed Dimensions.

In modernen Cloud-Warehouses und Lakehouse-Plattformen materialisiert sich die Warehouse-Rolle typischerweise als Gold-Layer einer Medaillon-Architektur: Bronze speichert Rohdaten, Silber übernimmt Cleansing und Historisierung, Gold enthält die dimensional modellierten Fakten- und Dimensions-Tabellen. Die Frage Inmon oder Kimball ist damit meistens eine Frage der Schichtung: das integrierte Modell in Silber, die dimensionalen Marts in Gold.

Beispiel: Cloud Data Warehouse in einer Handels-Datenplattform

Ein Handelsunternehmen konsolidiert Verkaufsdaten aus SAP ERP, Kundendaten aus einem CRM und Klickstrom-Ereignisse aus dem Webshop in einem zentralen Cloud Data Warehouse (Snowflake). Change-Data-Capture-Streams aus den Quellsystemen landen zunächst in einer Staging-Schicht als tages-partitionierte Tabellen. Ein ELT-Werkzeug (dbt) transformiert die Staging-Daten in eine integrierte Kern-Schicht mit historisierten Slowly-Changing-Dimensions und lädt anschließend eine Auswertungs-Schicht mit einer Fakten-Tabelle „Verkaufstransaktion" und den Conformed Dimensions „Kunde", „Produkt", „Zeit" und „Region".

BI-Werkzeuge wie Power BI und Tableau greifen ausschließlich auf die Auswertungs-Schicht zu; Berechtigungen werden pro Schema und pro Fachbereich vergeben. Fachbereichs-Marts für Vertrieb, Finance und Marketing werden als Views oder materialisierte Tabellen aus derselben Auswertungs-Schicht abgeleitet und teilen dieselben Kunden- und Produkt-Dimensionen. Der operative Kassenbetrieb läuft davon getrennt in einer transaktionalen Datenbank; das Warehouse enthält ausschließlich historisierte Kopien der Transaktionen mit Ladezeit-Stempel.

Diese Architektur ist die typische heutige Warehouse-Umsetzung. Sie kombiniert einen Cloud-nativen Warehouse-Dienst mit entkoppeltem Compute und Storage, ein Schichtungs-Muster (Staging, Kern, Auswertung) und eine dimensionale Modellierung nach Kimball. Wird die Speicher-Schicht auf offene Tabellenformate wie Delta Lake oder Apache Iceberg umgestellt und ein Lakehouse-Dienst wie Databricks SQL statt eines klassischen Warehouse eingesetzt, wandert dieselbe logische Warehouse-Rolle in eine Lakehouse-Plattform; das Datenmodell und die BI-Nutzung bleiben unverändert.