Warum sind Reporting-Tabellen meistens denormalisiert, während transaktionale Datenbanken normalisiert sind?

Normalisierung optimiert auf Schreibvorgänge und Integrität, eine transaktionale Datenbank vermeidet also Duplikate und aktualisiert eine Zeile an einer Stelle. Reporting optimiert auf Lesevorgänge über riesige Scans, wo jeder Join Zeit kostet und jede zusätzliche Tabelle den Analysten Klarheit kostet. Ein denormalisiertes Star Schema bedeutet weniger Joins, schnellere Queries auf spaltenorientiertem Storage und Spaltennamen, die ein Analyst ohne Data Dictionary versteht.

Sie lösen unterschiedliche Probleme. Eine transaktionale Datenbank ist auf viele kleine Schreibvorgänge mit strenger Integrität gebaut, normalisiert heißt also, dass die Adresse eines Kunden genau einmal existiert und ein Update ein einziger Schreibvorgang ist. Eine Analytics-Tabelle ist darauf gebaut, Millionen Zeilen am Stück zu scannen, wo jeder Join Kosten sind und ein Join über fünfzehn Tabellen langsam und schwer richtig hinzubekommen ist. Also denormalisieren wir in Fakten und konforme Dimensionen, was Joins spart und Analysten lesbare Spaltennamen gibt statt eines Schemadiagramms und dreier Lookup-Tabellen. Spaltenorientierter Storage macht das billig, denn ein Ländercode, der sich über Millionen Zeilen wiederholt, komprimiert auf fast nichts. Der andere Grund ist betrieblich. Ein schwerer analytischer Scan gegen die Produktionsdatenbank konkurriert mit der Anwendung um Ressourcen, und ich habe schon erlebt, wie eine Ad-hoc-Query einen Checkout-Service umgelegt hat. Selbst wenn man Modellierung komplett ignoriert, gehört der Analytics-Workload dorthin, wo er Kunden nicht schaden kann.