Fakten neu modellieren: gemeinsame Dimensionen oder getrennte Fakten für sauberere Modelle?

Hilfreiche Gold-Views, die "einfach Dimension A und Dimension B joinen", verstecken eine Many-to-Many-Granularität, bis eine Berichtsseite sich selbst widerspricht. Filter zählen doppelt. Role-Playing-Dimensionen brechen. Zwei Seiten, die übereinstimmen sollten, tun es nie.

Liefere Bridge-Schlüssel als vollwertiges Artefakt aus und modelliere die Faktentabelle neu, bevor du Visuals polierst. Die Matching-Logik muss von jeder Faktentabelle, die sie nutzt, gemeinsam verwendet werden, sonst weichen die Zahlen schon konstruktionsbedingt voneinander ab. Role-Playing-Dimensionen im semantischen Modell brauchen passende Fremdschlüsseltypen. Zuerst umbauen. Dann polieren.

Abbildung 1. Bridge-Schlüssel vor Dashboards. Benenne das Many-to-Many, speichere es als Bridge oder ehrliche Faktentabelle und poliere dann. Komfort-Views sind keine Strategie für die Granularität.

Kontext und Rahmenbedingung

Ein häufiger Fehler: Eine Seite auf Basis von Dimension A und eine Seite auf Basis von Dimension B sehen beide plausibel aus und weigern sich in derselben Woche, übereinzustimmen. Die Gold-Schicht hat eine Komfort-View, die ein Many-to-Many zu etwas plattdrückt, das an einem guten Tag nach One-to-Many aussieht. Die Dashboards sind nicht der Fehler. Die Granularität ist es.

Bridge-Schlüssel gehören mit Validierung nach Gold, nicht in DAX, das "es im Bericht repariert". Gemeinsames Matching über Faktentabellen hinweg hält die Kennzahlen in den Überschriften ehrlich. Role-Playing-Dimensionen vervielfachen die Kosten eines einzigen falschen Schlüsseltyps. Berichtspolitur auf einer kaputten Granularität bringt Nutzern bei, jeder Zahl zu misstrauen.

Abbildung 2 zeigt die Oberfläche in Learn für die Kardinalität von Beziehungen. Eine Many-to-Many-Granularität sickert in leere oder doppelt gezählte Visuals, wenn du so tust, als reiche eine flache View.

Abbildung 2. Eine Many-to-Many-Granularität sickert in leere oder doppelt gezählte Visuals. Modelliere die Faktentabelle neu, bevor du Seiten polierst. Quelle: Microsoft Learn: Beziehungen verstehen.

Abbildung 3 zeigt die Filterrichtung auf derselben Learn-Seite. Bridge-Schlüssel und Filterrichtung gehören zum Umbau. Dashboards erben jede Granularität, die du in Gold hinterlässt.

Abbildung 3. Bridge-Schlüssel und Filterrichtung gehören zum Umbau. Quelle: Microsoft Learn: Beziehungen verstehen.

Design

1. Die Granularität laut aussprechen

Schreib auf, ob eine Zeile ein Ereignis, eine Zuordnung, eine Position oder eine Bridge zwischen Dimension A und Dimension B ist. Wenn zwei Wahrheiten in eine Tabelle passen, trenne sie. Über eine mehrdeutige Granularität kommt das Doppelzählen durch die Seitentür herein, während das Sternschema-Diagramm noch sauber aussieht.

2. Bridge-Schlüssel zu vollwertigen Spalten machen

Surrogat- oder fachliche Bridge-Schlüssel sollten dokumentiert, auf Eindeutigkeit in der beabsichtigten Granularität getestet und im semantischen Modell einheitlich verwendet werden. Lass Bridges nicht als "den Join, den wir in dieser einen View machen" stehen. Vollwertige Schlüssel überleben Übergaben.

3. Matching-Logik über Faktentabellen hinweg teilen

Wenn Quellschlüssel für Faktentabelle A über ein gemeinsames Modul auf eine Dimension aufgelöst werden, nutzt Faktentabelle B dasselbe Modul. Abweichendes Matching garantiert abweichende Kennzahlen. Gemeinsame Logik ist billiger als Abstimmungsmeetings. Abbildung 4 zeigt diese Aufteilung der Verantwortung.

Abbildung 4. Ein Matching-Modul für beide Faktentabellen. Veröffentliche seine Version zusammen mit dem Umbau, damit die Kennzahlen eine Woche später nicht auseinanderdriften. FKs der Role-Plays teilen die Typen mit Gold.

4. FK-Typen für Role-Playing-Dimensionen angleichen

Jede Rolle einer Role-Playing-Dimension braucht an jedem Beziehungsendpunkt passende Typen. Ein int64-Schlüssel neben einem string-Role-Play ist ein leeres Visual, das auf eine Demo wartet. Korrigiere Gold und TMDL gemeinsam.

5. Bridges vor den Seiten validieren

Abnahmetests: Eindeutigkeit der Bridge, Waisenquoten, Abgleich zwischen Ausschnitten nur nach Dimension A und nur nach Dimension B auf Fixture-Schlüsseln. Akzeptiere "die Seite sieht richtig aus" nicht als Beweis für die Granularität. Visuals können richtig aussehen und trotzdem die falsche Entität doppelt zählen.

6. Die Arbeit in der Reihenfolge Umbau, dann Visuals planen

Wenn Stakeholder eine hübschere Seite wollen, prüfe, ob die Faktentabelle noch lügt. Umbau-Tickets machen den Weg für Berichts-Tickets frei. Wer beides mischt, bekommt schöne Falschheit.

Warum "hilfreiche" Gold-Views unter Filtern versagen

Eine Komfort-View, die Attribute von Dimension B auf jede Zeile von Dimension A kopiert, sieht ohne Filter gut aus. Setz auf beiden Seiten gleichzeitig einen Datenschnitt, und die Kardinalität explodiert oder fällt in sich zusammen, je nach Richtung der Beziehung. Das semantische Modell kann keine Bridge erfinden, die du nicht speichern wolltest. Wenn Product Owner sowohl "Zeilen von Dimension B pro Schlüssel von Dimension A" als auch "Zeilen von Dimension A pro Schlüssel von Dimension B" als vollwertige Fragen wollen, haben sie bereits nach einer Bridge gefragt. Deine Aufgabe ist, nicht länger so zu tun, als beantworte eine flache View beides ohne Aussage zur Granularität. Abbildung 5 zeigt den Gegensatz.

Abbildung 5. Flache Komfort-Views verstecken Many-to-Many, bis zwei Datenschnitte sich widersprechen. Eine ausdrückliche Bridge speichert die Granularität, damit beide Richtungen übereinstimmen können.

Eine minimale Checkliste für den Umbau

Liste die aktuellen Konsumenten der Komfort-View auf. Definiere die Granularität der Bridge in einem Satz. Ergänze Schlüssel und Tests. Richte das semantische Modell auf die neue Faktentabelle oder Bridge aus. Baue die betroffenen Seiten neu. Erst dann löschst oder friert du die Komfort-View ein. Einfrieren ohne Löschdatum garantiert einen Zombie-Pfad. Veröffentliche die Version des Matching-Moduls neben dem Umbau, damit die anderen Faktentabellen eine Woche später nicht abweichen.

Semantische Tests, die Regressionen nach dem Umbau fangen

Halte ein winziges Fixture-Paket bereit: ein Schlüssel von Dimension A mit zwei Schlüsseln von Dimension B, ein Schlüssel von Dimension B mit zwei Schlüsseln von Dimension A, falls das fachlich erlaubt ist, ein Schlüssel von Dimension A ohne Treffer, ein Schlüssel von Dimension B ohne Treffer. Prüfe nach jeder Änderung in Gold die Zahlen aus beiden Richtungen. Ergänze einen Check für Role-Playing-Datumsdimensionen, damit Datumsrolle A und Datumsrolle B nicht still einen falschen Typ teilen. Diese Tests sind langweilig. Sie sind auch der Weg, nicht nach jeder "kleinen" Anpassung der Anreicherung denselben Fehler neu zu entdecken.

Häufige Fehler

Komfort-Views in Gold. Many-to-Many plattgedrückt, bis es versagt.

Bridges in DAX. Geschäftsregeln versteckt in Measures, die niemand verantwortet.

Unterschiedliches Matching pro Faktentabelle. Die Kennzahlen streiten für immer.

Gemischte FK-Typen bei Role-Plays. Leere Visuals werden darauf geschoben, dass "Power BI komisch ist".

Lieferung mit der Seite zuerst. Politur zementiert die falsche Granularität.

Keine Waisenkennzahlen. Schlüssel ohne Treffer fallen auf beiden Seiten still weg.

So übernehmen oder anpassen

So übernehmen

• Many-to-Many zwischen zwei Dimensionen wird mit einer ausdrücklichen Bridge oder einer klaren Aussage zur Granularität der Faktentabelle modelliert.
• Bridge-Schlüssel werden in den Gold-Pipelines validiert (Eindeutigkeit, Waisen).
• Matching- und Anreicherungslogik wird über alle Faktentabellen gemeinsam genutzt.
• Endpunkte von Role-Playing-Beziehungen teilen die Typen mit den FKs in Gold.
• Berichtsarbeit an betroffenen Seiten wartet auf die Abnahmetests des Umbaus.
• Komfort-Views, die die Granularität verstecken, werden mit einem Entfernungsdatum ausgemustert.

Vor dem Einsatz anpassen

Ausdrückliche Bridges bringen zusätzliche Tabellen und Schulungsaufwand. Verstecktes Many-to-Many kostet Vertrauen. Gemeinsame Matching-Module verlangen Paketdisziplin über Notebooks hinweg. Der Umbau verzögert sichtbaren Fortschritt in der UI und verhindert, dass diese UI neu gebaut werden muss. Strenge Berichte über Waisen können unangenehme Lücken in den Quellen sichtbar machen. Mach sie sichtbar. Versteck sie nicht in Inner Joins.

Wichtigste Quellen: Beziehungen in Power BI und die Hinweise zum Sternschema auf Microsoft Learn sowie die Modellierungspraxis für die Gold-Schicht in Fabric. Stell die Diagramme neben den Satz zur Granularität im Repo.

Zuerst Bridge-Schlüssel. Dann gemeinsames Matching. Typen angleichen. Dann die Seite polieren. Der Abgleich ist kein wöchentliches Rätsel mehr, wenn die Granularität ehrlich ist.