Zwei Welten, zwei Anforderungen: OLTP vs. OLAP

OLTP-Systeme (Online Transaction Processing) sind die Arbeitspferde des operativen Geschäfts. ERP, CRM und Shopsysteme schreiben hunderte oder tausende Zeilen pro Sekunde. Eine Zeile entspricht einer Transaktion. Die Datenbankstruktur ist darauf ausgelegt, INSERTs, UPDATEs und DELETEs möglichst effizient zu verarbeiten. Klassische Vertreter sind PostgreSQL, MySQL und Microsoft SQL Server.

OLAP-Systeme (Online Analytical Processing) sind das Gegenstück. Sie lesen, aggregieren und vergleichen. Niemand schreibt in ein Data Warehouse in Echtzeit. Es geht um historische Daten, um Trends und um Aggregationen über Millionen von Zeilen. Rpräsentanten einer modernen Datenarchitektur wie Snowflake, Microsoft Fabric oder Google BigQuery sind genau dafür gebaut.

Diese Unterscheidung ist fundamental für eine effiziente Datenstrategie. Zwar kann ein OLTP-System technisch auch für Analytics verwendet werden. Mit zunehmender Datenmenge zahlt man jedoch den Preis in Form von langsamen Queries, hoher Last auf dem Produktivsystem und irgendwann auch mit falschen Zahlen.

Die Reise durch drei Modellierungsparadigmen

Normalisierung (3NF) – Effizienz für die Maschine

Die normalisierte Datenbank ist das Fundament der relationalen Datenbanktheorie. Jede Information existiert genau einmal. Redundanz wird durch Fremdschlüssel ersetzt. Das Ergebnis: maximale Speichereffizienz und Konsistenz bei Schreiboperationen.

Das Problem: Für Analysen muss man joinen, oft über viele Tabellen hinweg. So etwa bei einem normalisierten Datenmodell mit drei Tabellen: customers, orders und order_items. Um eine einfache Frage zu beantworten – „Wie viel Umsatz haben wir mit Kunde Müller GmbH gemacht?“ – müssen alle drei verknüpft werden:

SELECT c.name AS customer,
       SUM(oi.quantity * oi.unit_price) AS revenue
FROM customers c
JOIN orders o ON o.customer_id = c.customer_id
JOIN order_items oi ON oi.order_id = o.order_id
WHERE c.name = 'Müller GmbH'
GROUP BY c.name

Das ist korrekt, aber langsam und schwer zu warten, besonders wenn viele solcher Queries gleichzeitig laufen.

Star Schema – Der klassische BI-Kompromiss

Das Star Schema, popularisiert von Ralph Kimball in den 1990ern, war die Antwort der Business Intelligence auf dieses Problem. Statt alles zu normalisieren, gibt es eine zentrale Faktentabelle (die Transaktionen) und mehrere Dimensionstabellen (Kunde, Produkt, Zeit). Bewusst denormalisiert, bewusst redundant, aber eben optimiert für Lesezugriffe. Dieselbe Frage wie zuvor lässt sich hier bereits mit nur zwei Tabellen beantworten: fact_sales und dim_customers:

SELECT dc.name AS customer,
       SUM(fs.revenue) AS revenue
FROM fact_sales fs
JOIN dim_customers dc ON dc.customer_id = fs.customer_id
WHERE dc.name = 'Müller GmbH'
GROUP BY dc.name

Das Star Schema war für viele Jahre der Standard. Tableau, Power BI, jedes klassische BI-Tool liebt ein Star Schema. Es ist intuitiv für Analysten und performant für Reporting und auch heute noch das Modell, das wir bei The Information Lab in vielen Projekten einsetzen, wo strukturiertes BI-Reporting im Vordergrund steht.

One Big Table (OBT) – Der Cloud-native Ansatz

Das Ergebnis: der One Big Table-Ansatz. Alles in einer einzigen, flachen Tabelle. Keine Joins. Maximale Einfachheit. Dieselbe Beispielfrage lässt sich nun mit einer einzigen Tabelle beantworten – analytics_wide:

SELECT customer,
       SUM(revenue) AS revenue
FROM analytics_wide
WHERE customer = 'Müller GmbH'
GROUP BY customer

Das ist die Query, die jeder sofort versteht. Kein Datenbank-Wissen erforderlich, keine Join-Logik, keine Fragen, welche Tabelle welche Information enthält. Das macht OBT nicht nur attraktiv für AI-gestützte Abfragen, sondern auch für Self-Service Analytics und klassisches BI-Reporting – überall dort, wo Einfachheit und Geschwindigkeit zählen.

Warum das für AI entscheidend ist

Wenn ein Large Language Model (oder ein AI-Agent) Daten abfragen soll, passiert folgendes: Das Modell bekommt ein Schema beschrieben und versucht daraus eine SQL-Abfrage zu generieren. Die Qualität dieser Abfrage hängt massiv davon ab, wie klar und selbsterklärend das Schema ist und genau hier zahlt sich Einfachheit aus.

Ein normalisiertes Schema mit zwölf Tabellen und kryptischen Spaltennamen wie cust_id, ord_ref und li_qty ist für ein LLM genauso schwer zu navigieren wie für einen neuen Mitarbeiter. Es entstehen falsche Joins, fehlende Conditions, halluzinierte Tabellennamen.

Eine breite, gut benannte OBT-Tabelle mit Spalten wie customer_name, product_category, revenue, order_date ist hingegen fast selbst-dokumentierend. Ein Sprachmodell kann daraus zuverlässig SQL ohne tiefes Kontextwissen über die Datenbankarchitektur ableiten.

Gut modellierte Daten sind die Grundlage für verlässliche AI-Antworten. Das ist kein Zufall, sondern direkte Konsequenz aus der Architektur: Je weniger Interpretationsspielraum ein Schema lässt, desto besser funktioniert die AI-gestützte Abfrage darüber.

Fazit

Der Weg von 3NF über Star Schema zu OBT ist keine Revolution, sondern eine pragmatische Anpassung an veränderte Rahmenbedingungen: günstigerer Speicher, leistungsfähigere Cloud Warehouses, und neue Konsumenten wie AI-Systeme, die einfache, klare Datenstrukturen brauchen.

Wer heute ein Data Warehouse entwirft, sollte sich fragen: Für wen modelliere ich eigentlich? Die Antwort ist vermutlich nicht mehr nur „für den Analysten mit SQL-Kenntnissen“. Sie lautet zunehmend: auch für Sprachmodelle, die aus natürlicher Sprache Abfragen generieren. Und für die ist Einfachheit keine Designentscheidung – sie ist eine Voraussetzung.