Im letzten Blogpost haben wir über Datenschemas aka Fundament von Power BI gesprochen – ohne das richtige Datenschema ist keine zuverlässige Datenanalyse oder Visualisierung möglich.
Mindestens genauso wichtig sind allerdings die Beziehungen, die erforderlich sind, sobald wir mehr als eine Datenquelle bzw. eine Tabelle in Power BI haben – also sobald wir weg von dem flachen Datenschema mit einer einfachen Tabelle gehen.
Um bei unserer Gebäude-Analogie zu bleiben – wenn Datenschemas das Fundament sind, dann bilden die Beziehungen das Tragwerk. Beide sind ausschlaggebend für die Stabilität und Nutzbarkeit.
Kardinalität
In Power BI werden Beziehungen zwischen Tabellen über gemeinsame Schlüssel definiert – das bedeutet, dass jede Tabelle eine übereinstimmende Spalte haben muss – z.B. die Element ID.
Kardinalität ist im Kontext von Power BI die formale Beschreibung, wie viele Zeilen aus Tabelle A mit wie vielen Zeilen aus Tabelle B in Beziehung stehen dürfen.
Oder in der BIM-Sprache ausgedrückt: Kardinalität definiert, ob ein Bauteil genau einen Typ haben darf, mehrere, oder ob Power BI damit rechnen muss, dass derselbe Typ auch bei unterschiedlichen Bauteilen vorkommen kann.
Die Beziehungen sind in der Modellansicht in Power BI als Verbindungen zwischen den Tabellen sichtbar. Beim Auswählen einer Verbindung werden in dem Eigenschaftenfenster die Details sichtbar:
Die Beziehungen können per Drag & Drop von Eigenschaften in der Modellansicht oder über das Dialogfeld Manage Relationship erstellt werden.
Dabei schläft Power BI meistens bereits von sich aus die richtige Art von Beziehung – dennoch ist es wichtig, diese Einstellungen zu verstehen und zu überprüfen.
Die wichtigste Eigenschaft einer Beziehung in Power BI ist die Kardinalität. Power BI hat vier mögliche Kardinalitäten:
1 : n (One-to-Many) bzw. n : 1 (Many-to-One)
Das ist der Idealzustand: Eine Zeile in Tabelle A kann mit vielen Zeilen in Tabelle B verbunden sein, aber jede Zeile in B gehört nur zu genau einer Zeile in A (oder umgekehrt).
Power BI liebt diese Beziehung – Filter sind eindeutig, performant und nachvollziehbar. Ein schönes Beispiel dazu findet sich in dem Assets Dasbhoard, zu dem ich vor einer Weile ein Video Tutorial veröffenticht habe:
Hier haben wir eine Data Exchange und die Assetsinformation, die jeweils über die Element ID verknüpft werden – dabei wird dir vielleicht die Frage kommen, warum wir denn keine 1:1 Beziehung haben, da ein Bauteil i.d.R. einem Asset entspricht – und das ist eine hervorragende Frage!
Wie im letzten Beitrag erwähnt, lädt der Data Exchange Connector alle Daten in einer Tabelle, d.h. die eigentlichen Elementinformationen wie auch die Viewer Daten, die für die Anzeige des Modell gebraucht werden. Das merkst du daran, dass in der Tabellenansicht viele scheinbar leere Zeilen sind – diese enthalten wichtige Informationen für den Viewer und sollten nicht gelöscht werden.
Aus diesem Grund ist allerdings i.d.R. keine 1:1 Beziehung zu einer Data Exchange möglich, da diese Art der Beziehung erfordert, dass jede Zeile einen eindeutigen Wert hat – und auch ein leeres Feld zählt als ein Wert.
Das Assets Dashboard könnt befindet sich übrigens in dem Data Exchange Sandboxv ACC Projekt – der Zugriff kann bei Bedarf einfach hier angefordert.
1 : 1 (One-to-One)
Diese Beziehung treffen wir eigentlich eher selten beim Arbeiten BIM-Daten: Jede Zeile in Tabelle A gehört genau zu einer Zeile in Tabelle B. Das kann vor allem vorkommen, wenn zusätzliche Informationen über die Bauteile in einer separaten Tabelle zu finden sind und von Element zu Element variieren.
Beim Arbeiten mit Data Exchange kommt diese Beziehung allerdings bei Federated Views vor – nämlich wenn zwei geladene Data Exchanges im selben Viewer als ein aggregiertes Modell angezeigt werden sollen. Um dies zu ermöglichen, müssen zunächst die beiden Spalten Federated Viewer Mapping verbunden werden – Power BI erkennt dabei automatisch die 1:1 Beziehung:
Hier geht es übrigens zu der offiziellen Dokumentation für dieses Szenario.
n : n (Many-to-Many)
Mehrere Zeilen in A können mehreren Zeilen in B entsprechen – ohne eindeutige Zuordnung. Dieses Szenario gilt es i.d.R. zu vermeiden, da es oft zu unklaren Ergebnissen und widersprüchlichen Auswertungen führen kann. Kommt ein solches Szenario vor, sollte das Datenschema überprüft und optimiert werden.
Cross-filter Direction
Für alle Beziehungen kann auch die Filterrichtung definiert werden.
Ein besonders beliebtes Feature in Power BI sind bi-direktionale Relationships, also Beziehungen, bei denen Filter in beide Richtungen wirken. Gerade im BIM-Kontext ist das verlockend: Man klickt auf einen Raum und sieht sofort alle zugehörigen Bauteile, klickt auf einen Typ und sieht alle Räume, in denen er vorkommt. Es fühlt sich intuitiv und „richtig“ an.
Und das ist auch der große Vorteil: Für erste Analysen und kleinere Modelle kann bi-direktional sehr hilfreich sein.
Das Problem zeigt sich erst mit wachsender Komplexität. Mehrere bi-direktionale Beziehungen können unvorhersehbare Filterpfade erzeugen. Ergebnisse sind plötzlich nicht mehr erklärbar, Performance leidet, und niemand weiß mehr genau, warum eine Visualisierung etwas anzeigt oder eben nicht. In größeren BIM-Datenmodellen entstehen so logische Schleifen.
Bi-direktional ist deshalb kein Fehler, sondern ein Werkzeug – allerdings eines, das bewusst und sparsam eingesetzt werden sollte.
Grundsätzlich lautet die Empfehlung daher: erstmal mit der einfachen Beziehung anfangen und nur bei Bedarf auf bi-direktional wechseln, dabei allerdings die Resultate im Auge behalten.
Fazit: Beziehungen sind die Tragstruktur
Ein gutes Power-BI-Datenmodell unterscheidet sich gar nicht so sehr von einem guten BIM-Modell. Es ist vielleicht nicht spektakulär, aber es ist logisch aufgebaut, nachvollziehbar und erweiterbar. Beziehungen sind dabei keine Nebensache, sondern die Tragstruktur des gesamten Systems.
Dashboards sind die Fassade. Beziehungen sind das Tragwerk.
Wenn du mehr über das Arbeiten mit Revit-Daten in Power BI lernen möchtest, melde dich unbedingt zu unserem Webinar nächste Woche an (solltest du diesen Blogpost erst später lesen, keine Sorge – ich werde die Aufzeichnung sobald verfügbar hier verlinken!)
👉🏼 Hier geht es zur Webinar-Anmeldung – ich freue mich auf neue und bekannte Gesichter und wie immer spannende Diskussionen! 🙂
P.S. Die Aufnahme vom letzten Webinar, bei dem wir über die Neuerungen in dem Data Connector for Power BI 2.4.0 berichtet haben, findest du hier.