vorheriger Artikel
Für spezifische Anwendungsfälle, wie das Deckungsbeitragsschema, ist die Darstellung von Kennzahlen in einer Dimensionstabelle anstelle der klassischen Faktentabelle sinnvoll. In diesem Beitrag zeigen wir Dir Charakteristika und einen Implementierungsansatz in Power BI.
Spezifische Nachteile der klassischen Faktentabelle
Das klassische Datenmodell für Analyse-Software wie Power BI ist das Sternschema, das sich durch eine Faktentabelle und diverse Dimensionstabellen auszeichnet. Erstere enthält hierbei – mit je einer Spalte pro Kennzahl – die Bewegungsdaten. Um Kennzahlen zu aggregieren, werden Measures angelegt, die jeweils mindestens eine Faktenspalte referenzieren. Diese Methode zeigt bei spezifischen Anwendungsfällen, wie dem Deckungsbeitrag oder dem ROI, allerdings Nachteile, die an einem stark vereinfachten Beispiel einer zweistufigen Deckungsbeitragsrechnung deutlich werden:
Das Datenmodell mit klassischer Faktentabelle (im vereinfachten Beispiel mit lediglich dem Datum als Fremdschlüssel) könnte folgendermaßen aussehen:
- Die Unübersichtlichkeit und Ineffizienz der Faktentabelle nimmt bei einer steigenden Anzahl an Kennzahlen zu.
- Die Abbildung verschiedener Hierarchieebenen der Kennzahlen ist nicht möglich.
- Jede abzubildende Kennzahl erfordert ein separates, manuell zu pflegendes Measure. Auch die Aggregation von Kennzahlen ist nur über zusätzliche Measures möglich.
- Die feste Sortierung der Kennzahlen im Sinne der Deckungsbeitragsrechnung ist nicht möglich.
- Bei der Erstellung einer Visualisierung müssen dieser alle Einzelmeasures manuell hinzugefügt werden.
- Für neue Kennzahlen müssen neue Measures angelegt und bestehende manuell erweitert werden, wobei die neuen Measures den bestehenden Visualisierungen ebenfalls manuell hinzugefügt werden müssen.
Technische Implementierung einer Kennzahlendimension
Diese negativen Aspekte kannst Du durch die Implementierung einer Kennzahlendimension umgehen. Dafür werden die Kennzahl-Spalten der Faktentabelle mit Hilfe der unpivot-Funktion in Power Query in eine Attribut- und eine Wert-Spalte transformiert. Anschließend wird eine ID-Spalte erzeugt, die für die gleichen Werte in der Attribut-Spalte ebenso gleiche ID-Werte erhält. Nun kannst Du auf Basis der ID- und der Attribut-Spalte eine Dimensionstabelle erstellen und dieser zusätzliche Hierarchieebenen sowie Sortierreihenfolgen als Spalten hinzufügen.
Die Spaltenanzahl der Faktentabelle wird deutlich reduziert, indem dort lediglich die Fremdschlüssel, u.a. die neue Kennzahl ID, und die Spalte Kennzahl Wert verbleiben. Durch neue Kennzahlen ändert sich die Spaltenanzahl im Vergleich zur herkömmlichen Faktentabelle nicht. Da nun lediglich eine Spalte mit Bewegungsdaten existiert (für die korrekte Aggregation im Bericht müssen negative Posten mit -1 multipliziert werden), muss nur ein einfaches Measure geschrieben werden, um die Daten bereits darstellen zu können:
Das Datenmodell könnte also folgendermaßen aussehen (für die Kennzahlendimension wurde bereits eine Hierarchie angelegt):
Visuelle Darstellung
Im Gegensatz zum Datenmodell ohne Kennzahlendimension …
- … kann durch die zusätzlichen Spalten zur Sortierung die feste Kalkulationsreihenfolge des Deckungsbeitragsschemas auch in einer Visualisierung dargestellt werden, ohne Measures manuell anzuordnen. Dies wäre bei einer Vielzahl an Measures mit einem enormen Aufwand für Erstellung und Pflege verbunden.
- …kann die hierarchische Struktur der Deckungsbeitragsrechnung z. B. mit einer Matrix-Visualisierung abgebildet werden:
- …ist das Hinzufügen und Entfernen von Kennzahlen in Visualisierungen für den Endanwender einfach durch Filtern via hierarchisch strukturierter Slicer möglich:
Abwägung einer Kennzahlendimension
Neben den bereits dargestellten Vorteilen einer Kennzahlendimension weist sie allerdings auch gewisse negative Aspekte auf. Die Erstellung eines Measures für eine einzelne Kennzahl ist etwas komplexer, da sich alle Kennzahlen in derselben Spalte befinden und diese im DAX-Code gefiltert werden muss. Auch die Verrechnung von Kennzahlen, die nicht in den Quelldaten erfasst sind, ist deutlich komplizierter, da nicht einfach auf Datensatzebene kalkuliert werden kann.
Ein weiterer positiver Aspekt der Verwendung einer Kennzahlendimension ist hingegen der notwendige Speicherbedarf der Tabellen. Die zusätzliche Dimensionstabelle benötigt zwar auch zusätzlichen Speicherplatz, jedoch wird das durch die geringere Größe der kleineren Faktentabelle ausgeglichen. In unserem Beispiel ist dies nicht der Fall, was an der geringen Anzahl an Kennzahlen und Datensätzen liegt.
Eine Steigerung der Anzahl an Kennzahlen und Einträgen pro Kennzahl würde das Größenverhältnis allerdings umdrehen und auch den zusätzlichen Speicherplatz der Kennzahlendimension relativieren. Das zeigt in der Analyse des Speicherbedarfs die Testtabelle „FaktDeckungsbeitrag Standard erweitert“, die 20 zusätzliche Spalten und ca. 200 neue Zeilen enthält:
Empfehlung
Aufgrund der aufgezeigten Aspekte ist die Verwendung einer Kennzahlendimension für spezifische Anwendungsfälle wie der Deckungsbeitragsrechnung absolut zu empfehlen. Insbesondere, da die technische Implementierung in der Regel keine tiefgreifenden Power BI- und DAX-Kenntnisse voraussetzt.
Du hast einen vergleichbaren Anwendungsfall? Dann nutze die Kennzahlendimension und wende dich bei
Problemen einfach an uns!
Melde Dich!
