Die SQL Days 2020 sind gestern und heute in Erding bei München über die Bühne gegangen. Coronabedingt waren nur wenige Teilnehmer vor Ort, aber hoffentlic waren viele online mit dabei. Ich freue mich ganz besonders, daß ich auch dieses Jahr wieder als Sprecher für Power BI mit dabei sein durfte. Im folgenden ein kleiner Erfahrungsbericht und die Eckpunkte meiner Session. Reisebedingt konnte ich selbst nicht die vollen 2 Tage vor Ort sein sondern nur heute vormittag teilnehmen, sodaß ich nur 2 andere - dafür aber sehr gute - Sessions konsumieren konnte.

Organisation

Ich war dieses Jahr mit meiner Session im großen Saal - einfach weil es aufgrund der geringen Teilnehmerzahl vor Ort egal war, welche Session in welchem Raum stattfindet. :) Platz hatten wir jedenfalls genug, die Abstandsregeln konnten gleich mehrfach eingehalten werden.

Die Veranstaltung ist als hybrides Event - also vor Ort und Online - sehr professionell organisiert. Die Sessions wurden in Echtzeit via MS Teams an die Online Teilnehmer übertragen (und natürlich auch gleich aufgezeichnet). Technisch wurde das so gelöst, daß das HDMI Signal von meinem Vortragsrechner (links) sowohl an den Beamer als auch an den Organisator Rechner übertragen wurde und von dort via MS Teams geteilt wurde (und um die Rahmeninfos zur Session angereichert wurde, siehe unten).

Die Webcam des Organisator Rechners wurde in den Raum gerichtet, sodaß alle Online Teilnehmer auch die Teilnehmer im Saal sehen können (umgekehrt ging das aber nicht). Eine weitere (Profi-)Kamera hat mich als Sprecher ins Visier genommen und auf Schritt und Tritt verfolgt:

Hier die Sicht der Online Teilnehmer via Microsoft Teams (am Beispiel einer Session von Andreas Rauch):

Quelle: Twitter @ppedvEvents

Multi-Fakten vs. Star Schema in Power BI

Die folgenden Inhalte geben einen Überblick über die Stationen der Session, jedoch ohne die jeweiligen Besonderheiten und das Conclusio zu verraten. :)

1. Einstieg

Das Thema ist deshalb so wichtig, weil in vielen Fällen die Fakten "in Einzelteilen" angeliefert werden und ohne Modellierungs-Know-How dann intuitiv ein Multi-Fakten Schema in Power BI aufgebaut wird. Häufig ist aber eine Transformation in ein Star Schema zielführender und effizienter. Diese Situationen und die wichtigsten Stolpersteine zu erkennen, darum geht es in dieser Session.

Das Star Schema und das Multi-Fakten Schema sind in meiner Praxis die mit Abstand wichtigsten Datenmodelle, aber es gibt auch noch mehr Modellierungsoptionen:

2. Typisches Star Schema: Sales Reporting

Ein Sales Reporting ist ein gutes Beispiel für die Abbildung als Star Schema, alle Visuals und alle Filter funktionieren absolut intuitiv und für die User funktioniert "alles ganz normal":

3. Typisches Multi-Fakten Schema: Orders & Invoices (Typ 1)

Das Orders & Invoices Modell ist ein typisches Beispiel für ein idR sinnvolles Multi-Fakten Schema, ich nenne diese Art des Datenmodells Typ 1 Multi-Fakten Schema. Das Kennzeichen ist ein natürliches Verbindungsfeld wie hier das Feld Order Number, das in beiden Tabellen enthalten ist und dessen Einträge in einer m:n Beziehung stehen. D.h. ein Order kann über mehrere Invoices abgerechnet werden und eine Invoice kann mehrere Order abrechnen.

Hinweis: die m:n Beziehung zwischen den beiden Faktentabellen wird in der Praxis idR durch eine Verbindungstabelle und zwei 1:n Beziehungen ersetzt um das Risiko der Unvollständigkeit der Visualisierungen auszuschließen.

4. Multi-Fakten Schemata mit gemeinsamen Dimensionen (Typ 2)

Das Kennzeichen eines Typ 2 Multi-Fakten Schemas ist, daß es kein natürliches Verbindungsfeld gibt sondern lediglich gemeinsame Dimensionen, über die die Faktentabellen synchron gefiltert werden. Ich habe dazu 4 Cases entwickelt, die das Thema nach meiner persönlichen Erfahrung repräsentativ abbilden.

Case 1 ist der Reseller & Internet Sales Case: zwei Faktentabellen, die zwar nicht gleich aufgebaut sind aber viel gemeinsam haben und ähnliche Inhalte haben. Die Abbildung als Multi-Fakten Schema ist anspruchsvoller, als es auf den ersten Blick aussieht. Es hat auch einige gravierende Nachteile insbesondere beim Einsatz von (häufig notwendigen) bidirektionalen Beziehungen, da damit das Risiko der Scheinfilterung und der Model Ambiguity rasch schlagend wird.

Im Gegensatz dazu funktioniert das transformierte Star Schema gewohnt unkompliziert, kann aber vielleicht auch weniger (das muß dann jeweils situationsspezifisch beurteilt werden):

Case 2 ist der Actual & Budget Case: die beiden Tabellen beinhalten grundsätzlich die gleichen Daten, allerdings wird das Budget auf aggregierter Ebene (Monat, Produktgruppe, Kundenländer) erstellt während die IST-Daten detailliert (Tag, Artikel, Kunde, usw.) sind. Hier kann mit 1:n und m:n Beziehungen sehr rasch und elegant ein schönes Datenmodell gebaut werden, das sich bei näherer Betrachtung aber als sehr problematisch aufgrund unerwarteter Filterung im Dashboard herausstellt:

Das transformierte Star Schema verwendet die aggregierten Elemente (aus der Budget-Faktentabelle) als zusätzliche Keys in den Dimensionstabellen wodurch die Datensituation radikal vereinfacht wird:

Case 3 ist eine HR Anwendung, die in diesem Blog bereits ausführlich behandelt wurde (siehe hier, hier und hier). Die 3 Faktentabellen und 4 (teilweise) gemeinsamen Dimensionen sorgen für ein unübersichtliches und fehler-/irrtumsanfälliges Beziehungsgeflecht, das in der Praxis aus meiner Sicht auch das größte Problem des Multi-Fakten Schemas darstellt:

Das transformierte Star Schema ist vergleichsweise simpel und filtert intuitiv, erfordert aber etwas Modellierungs- und DAX-Know-How, um die entstehenden ungültigen Summierungen im Common Fact Table zu unterbinden:

Case 4 ist eine Marketing Anwendung, bei der die Faktentabellen so verschieden sind, daß eine Verbindung nur über die Zeitdimension sinnvoll möglich ist. Dieser Anwendungsfall sollte nach meiner Erfahrung immer als Multi-Fakten Schema abgebildet werden - bei Bedarf auch mit m:n Beziehung zur Handhabung der auch hier unterschiedlichen (zeitlichen) Granularitäten.

Die Zeitfilterung funktioniert aufgrund die m:n Beziehung erwünscht intelligent - trotz Auswahl eines datumsbasierten Zeitfensters zeigt bspw. das Visual rechts mit den jährlichen Google Trends richtigerweise immer die gleichen Einträge für das betreffende Jahr an:

Die Transformation in ein Star Schema würde eine Faktentabelle ergeben, bei der nur die Datumsspalte in allen Teildatenbeständen des Common Fact Table durchgehend befüllt wäre. Die Transformation bringt aus meiner Sicht daher idR zu wenig Vorteile.

5. Fazit

Das Fazit ist sehr einfach: wird ein Multi-Fakten Schema in Power BI aufgebaut, muß kritisch hinterfragt werden, ob dies tatsächlich die beste Wahl ist und ob nicht eine Transformation in ein einfaches Star Schema sinnvoller für den konkreten Anwendungsfall ist:

Weiterführende Informationen

https://sqldays.net/2020/