3NF im Silver-Layer: Warum Dashboards unterschiedliche Zahlen zeigen
Warum mehrere Dashboards auf denselben Daten oft unterschiedliche Zahlen zeigen und wie 3NF im Silver-Layer für eine gemeinsame, konsistente Grundlage sorgt.
Die Kernaussagen auf einen Blick.
- 3NF im Silver-Layer hilft, Kunden, Produkte und Verträge nur einmal sauber zu modellieren. Dadurch greifen Dashboards auf dieselbe Grundlage zu.
- Sichtbar wird das Thema meist erst beim zweiten Konsumenten: das zweite Dashboard, der erste Feature Store oder eine Reverse-ETL-Strecke. Bis dahin wirkt ein Silver, der nur für den ersten Report gebaut wurde, ausreichend. Beim zweiten Konsumenten kippt das.
- Vor der Silver-Modellierung sollten drei Fragen beantwortet werden: Wie viele Dashboards nutzen dieselben Daten? Wo entstehen heute unterschiedliche Zahlen? Und wer ist verantwortlich, wenn sich ein Attribut ändert?
- Mein Vorschlag: Silver grundsätzlich 3NF-nah modellieren, aber kleine und stabile Referenzdaten bewusst vereinfachen. So bleiben Kennzahlen konsistent, ohne den Silver-Layer unnötig schwer zu betreiben.
Inhaltsverzeichnis
Warum unterschiedliche Dashboards oft am Silver-Layer liegen
Ein einzelnes Vertriebs-Dashboard ist schnell gebaut. Schwieriger wird es, wenn später ein Retouren-Report, ein Forecast-Modell oder ein Management-Dashboard auf dieselben Kundendaten zugreift, aber andere Zahlen zeigt. Dann beginnt die typische Diskussion: Warum hat Report A 100 Kunden und Report B 105?
Das passiert häufig, sobald mehrere Gold-Modelle auf dieselbe Silver-Basis zugreifen. Der Modellierungsüberblick klärt, wann Star Schema, Wide Table oder Data Vault im Gold-Layer sinnvoll sind. Hier geht es um die Ebene darunter: den Silver-Layer als gemeinsame Grundlage für mehrere Reports, Datenprodukte und Modelle. Wie sich Bronze, Silver und Gold im Lakehouse zueinander verhalten, klären wir im Überblick zur Medaillon-Architektur.
Vor der Modellierung sollte klar sein: Wie viele Dashboards nutzen dieselben Silver-Daten? Wo entstehen heute unterschiedliche Zahlen? Wer ist verantwortlich, wenn sich ein Attribut ändert? Und wann bringt zusätzliche Struktur mehr Nutzen als Aufwand?
3NF im Silver ist keine akademische Modellierungsübung. Es geht darum, ob mehrere Reports dieselben Begriffe, Schlüssel und Attribute verwenden. Wenn der Silver zu wenig Struktur hat, baut jedes Gold-Modell seine eigene Logik. Die Folge sind genau die Diskussionen, die niemand im Reporting-Meeting führen will: Warum ist dieselbe Kennzahl in zwei Reports unterschiedlich?
Was ist die dritte Normalform?
Die dritte Normalform kommt aus der relationalen Datenmodellierung und wurde Anfang der 1970er Jahre von Edgar F. Codd geprägt. Einfach gesagt: Ein Attribut steht dort, wo es fachlich hingehört, und nicht mehrfach in verschiedenen Tabellen.
Für die praktische Modellierung reicht diese Regel: Stammdaten stehen einmal zentral. Bewegungsdaten verweisen darauf über Schlüssel. Die Kundenanschrift steht in der Kundentabelle. Die Produktkategorie steht in der Produkttabelle. Aufträge und Rechnungen verweisen darauf über Schlüssel, ohne die Informationen erneut zu speichern.
| Tabelle | Typ | Schlüsselfelder |
|---|---|---|
| kunde | Stammdaten | kunde_id (PK), name, region, telefon, email |
| produkt | Stammdaten | produkt_id (PK), name, kategorie |
| auftrag | Bewegungsdaten | auftrag_id (PK), kunde_id (FK), datum, status, gesamtbetrag |
| auftragsposition | Bewegungsdaten | position_id (PK), auftrag_id (FK), produkt_id (FK), menge, einzelpreis |
Das Modell ist keine Erfindung des Lakehouses. 3NF wird seit Jahrzehnten in ERP-, CRM- und PIM-Systemen genutzt. Auch viele klassische Enterprise Data Warehouses wurden nach diesem Prinzip aufgebaut. Im Delta Lakehouse hat 3NF aber eine andere Rolle. Das alte Speicherargument ist heute weniger wichtig. Speicher ist im Lakehouse nicht mehr der entscheidende Kostentreiber. Heute geht es weniger um Speicherplatz und mehr um Konsistenz: 3NF schafft eine konsistente Grundlage im Silver-Layer.
Data & AI Beratung mit ruhrdot
Als offizieller Databricks-Partner begleiten wir dich von der Datenstrategie bis zur produktiven KI-Lösung.
Warum 3NF im Silver-Layer für konsistente Zahlen sorgt
Ein 3NF-naher Silver speichert zentrale Informationen nur einmal. Die Kundenanschrift steht in der Kundentabelle, die Produktkategorie in der Produkttabelle und der Auftragsstatus in der Auftragstabelle. Ändert sich ein Attribut, wird es an einer Stelle aktualisiert. Alle nachgelagerten Reports greifen danach auf dieselbe Version zu.
Das Gegenbeispiel: Die Kundenanschrift wird in jede Bestellzeile kopiert. Der Vertriebsreport zeigt noch die alte Anschrift, weil er nachts geladen wurde. Der Retourenreport zeigt bereits die neue Anschrift, weil er stündlich aktualisiert wird. Spätestens im Meeting fällt der Unterschied auf. Databricks beschreibt die Silver-Rolle in seinem Beitrag zur Medaillon-Architektur klar: „The Silver layer brings the data from different sources into an Enterprise view.“
Der praktische Nutzen liegt heute nicht vor allem im geringeren Speicherverbrauch. Vier Effekte sind wichtiger:
Konsistente Zahlen
Eine Attribut-Änderung wird an einer Stelle geschrieben. Alle Reports, die die Kunden-Tabelle konsumieren, zeigen danach dieselbe Version.
Frühere Fehlererkennung
Fehlende Fremdschlüssel-Referenzen, verwaiste Positionen oder Duplikate im Business-Key fallen im Silver auf, statt erst als unstimmige Zahl im Dashboard.
Klare Verantwortung
Wird die Kundenanschrift nur einmal gespeichert, ist auch klar, wer sie liefert und pflegt.
Basis für weitere Gold-Modelle
Der Silver muss auch die Gold-Modelle tragen, die erst später dazukommen, nicht nur das erste Dashboard.
Wo stößt 3NF im Silver-Layer an Grenzen?
3NF im Silver ist kein Dogma. Es gibt zwei Grenzen, bei denen bewusste Ausnahmen sinnvoll sind.
Die erste Grenze liegt im Betrieb. Ein sehr strikt normalisierter Silver kann schnell viele kleine Referenztabellen erzeugen. Bei jedem Load werden dann viele kleine Tabellen oder Dateien aktualisiert. Delta arbeitet effizienter, wenn Tabellen nicht aus vielen sehr kleinen Dateien bestehen. Sehr kleine Referenztabellen erreichen diese Größe oft nie. Mit der Zeit entstehen viele kleine Dateien. Das erhöht den Wartungsaufwand, ohne dass die fachliche Konsistenz spürbar besser wird. Die Databricks-Dokumentation zur Optimierung des Daten-Layouts empfiehlt für den Silver-Layer explizit tuneFileSizesForRewrites.
Kleine und stabile Referenzdaten wie Ländercodes, Währungen oder Kalendermerkmale müssen deshalb nicht immer eigene Tabellen sein. Sie können bewusst in der übergeordneten Tabelle bleiben. Für Land, Region und PLZ lohnt sich eine eigene Tabellenstruktur nicht immer. In solchen Fällen erzeugt die zusätzliche Normalisierung mehr Aufwand als Nutzen.
Die zweite Grenze liegt in der späteren Nutzung im Gold-Layer. Ein Star Schema mit einer Faktentabelle und sechs Dimensionen verbindet typischerweise mehrere Tabellen. Wenn der Silver zu stark normalisiert ist, entstehen im Gold schnell sehr viele Joins. Viele Joins sind nicht kostenlos. Je nach Datenmenge, Dateigröße und Layout können sie die Abfragen deutlich verlangsamen. Die für Reports optimierte Struktur gehört ins Gold. Der Silver bleibt die gemeinsame, saubere Basis.
Wie Liquid Clustering die Physik von Silver-Tabellen konkret verändert, klären wir im Überblick zu Liquid Clustering.
3NF oder Data Vault: welches Modell passt wann?
3NF ist nicht immer die richtige Antwort für den Silver-Layer. Data Vault 2.0 ist vor allem dann eine Alternative, wenn viele Quellsysteme, häufige Änderungen oder starke Audit-Anforderungen dazukommen.
Für die Entscheidung helfen zwei Fragen: Wie oft ändern sich die Quellsysteme, und gibt es eine Audit-Anforderung mit Insert-Only-Historie?
3NF wählen, wenn
- Die Quellsysteme sind stabil und ändern sich selten
- Keine Audit-Anforderung mit Insert-Only-Historie besteht
- Ein Standard-DWH-Team ohne dediziertes Data-Vault-Setup arbeitet
- Weniger Tabellen und geringerer Betriebsaufwand wichtiger sind als maximale Flexibilität
Data Vault 2.0 wählen, wenn
- Regelmäßig neue Quellsysteme dazukommen oder sich Attribute häufig ändern
- Eine lückenlose, nachvollziehbare Insert-Only-Historie gefordert ist (z. B. BaFin, MDR, AI Act)
- Ein dediziertes Data-Vault-Team mit Automatisierung vorhanden ist
- Neue Attribute als zusätzliche Satelliten ergänzt werden sollen, ohne bestehende Pipelines anzufassen
In vielen BI-Domänen ist ein 3NF-naher Silver einfacher zu betreiben und leichter zu verstehen: weniger Tabellen, weniger Betriebsaufwand und eine einfachere Modellierung.
Als Orientierung hilft diese Einordnung:
| Kriterium | 3NF-nah | Data Vault 2.0 | Bewusst denormalisiert |
|---|---|---|---|
| Anzahl Dashboards und Analyse-Modelle | mehrere | mehrere plus regulierte Domäne | genau eines, dauerhaft |
| Änderungen an den Quell-Systemen | überschaubar | häufig | selten |
| Auditability-Anforderung | keine mit Insert-Only-Zwang | belegt (BaFin, MDR, AI Act) | keine |
| Team-Reife | Standard-DWH-Reife | dediziertes DV-Team plus Automatisierung | Basisreife reicht |
Wie Data Vault 2.0 auf Delta konkret aufgebaut wird und ab wann sich der zusätzliche Modellierungs- und Betriebsaufwand rechnet, zeigen wir im Überblick zu Data Vault 2.0 im Delta-Lakehouse.
Typische Fehler bei der Silver-Modellierung
Silver-Modellierung scheitert meistens nicht an der Theorie, sondern an vier praktischen Fehlern.
Silver wird zum Reporting-Modell
Ein Report-Team fragt nach einer zusätzlichen Spalte, sie wird kurzfristig eingebaut. Nach ein paar Monaten verliert der Silver seine Rolle als gemeinsame Basis.
Nur für das erste Dashboard modelliert
Wird das erste Gold-Modell denormalisiert, entsteht der Silver oft gleich in diese Richtung, und passt beim zweiten Gold-Modell nicht mehr.
Bronze wird ungeprüft zu Silver
Nur Datentypen werden vergeben, fachlich wird nichts entschieden. Jedes Gold-Modell baut dadurch seine eigene Logik. Später entstehen unterschiedliche Zahlen.
Kennzahlenlogik vermischt sich mit Basisdaten
Berechnete Kennzahlen wie customer_lifetime_value wandern in den Silver, weil sie wie normale Attribute wirken. Definieren zwei Gold-Modelle sie unterschiedlich, wird der Silver zur Diskussionsfläche.
Wann ist 3NF im Silver-Layer nicht sinnvoll?
Nicht jeder Silver muss 3NF-nah modelliert werden. In drei Fällen lohnt sich der Aufwand oft nicht.
Nur ein dauerhafter Konsument
Greift dauerhaft nur ein Report oder ein Datenprodukt auf den Silver zu, kann ein einfacheres, stärker denormalisiertes Modell reichen, wenn ein späterer Umbau von Anfang an eingeplant ist.
Audit-Anforderung mit Insert-Only-Historie
Ist eine lückenlose Historie und nachvollziehbare Herkunft auf Attributebene gefordert, passt Data Vault oft besser. 3NF liefert diese Historie nicht automatisch.
Sehr kleine Silver-Domänen
Bei einem Quellsystem, wenigen Datensätzen und nur einem Report ist 3NF oft übertrieben. Eine einfache, typisierte Silver-Tabelle reicht dann aus.
Der häufigste Fehler ist aber grundsätzlicher: Der Silver wird nicht bewusst modelliert. Er entsteht nebenbei aus der ersten Gold-Pipeline und wird später einfach Silver genannt. In diesem Modus hilft kein Modellierungsansatz wirklich. Auch 3NF oder Data Vault ändern daran wenig. Der Silver sollte bewusst modelliert werden, bevor das erste Gold-Modell darauf aufsetzt.
Fazit
3NF im Silver-Layer lohnt sich vor allem dann, wenn mehrere Dashboards, Datenprodukte oder Modelle dieselbe Basis nutzen.
Spätestens beim zweiten Gold-Modell, beim Feature Store oder bei Reverse ETL zeigt sich, ob der Silver wirklich als gemeinsame Grundlage funktioniert.
Besonders wichtig wird die Entscheidung in BI-Organisationen, in denen immer mehr Reports auf dieselben Kunden-, Produkt- oder Vertragsdaten zugreifen. Für regulierte Domänen mit Insert-Only-Historie ist Data Vault meist die klarere Wahl. Für sehr kleine Domänen mit nur einem Konsumenten reicht oft ein einfacher, typisierter Silver.
Mein Vorschlag: Silver bewusst 3NF-nah modellieren, aber nicht dogmatisch. Kleine und stabile Referenzdaten können in der übergeordneten Tabelle bleiben, wenn eine eigene Tabelle keinen echten Nutzen bringt. Jede weitere Denormalisierung sollte im Modell-Katalog begründet werden. Der Betriebsaufwand sollte vor dem ersten Load klar sein: Wie viele Tabellen entstehen? Wie groß werden die Dateien? Welche Optimierung ist nötig? Der Silver bleibt die gemeinsame Basis für alle Gold-Modelle, auch wenn zuerst nur ein Dashboard gebaut wird.
Am Ende zählt, ob Reports dieselben Begriffe, Schlüssel und Zahlen verwenden. Genau dafür braucht es einen bewusst modellierten Silver-Layer.
Prüft vor dem nächsten Gold-Modell, wie viele Dashboards und Datenprodukte dieselbe Silver-Basis nutzen und wie groß der Betriebsaufwand bei zusätzlicher Normalisierung wäre.
FAQ
3NF, also die dritte Normalform, sorgt dafür, dass zentrale Informationen nur an einer fachlich richtigen Stelle gespeichert werden. Im Silver-Layer bedeutet das zum Beispiel getrennte Tabellen für Kunden, Adressen, Produkte und Aufträge, die über Schlüssel verbunden sind. Die Kundenanschrift steht einmal in der Adresstabelle. Alle Gold-Modelle greifen auf diese Quelle zu.
