Eine der Herausforderungen im BI-Umfeld sind KPI, die je nach Dimension anders behandelt werden. Ein perfektes Beispiel dafür sind Inventarmetriken. Nehmen wir an in unserem Lager befinden sich am Montag 5 CDs und 3 Bücher und am Dienstag 4 CDs und 5 Bücher. Für einzelne Tage eine einfache Rechnung; am Montag 8 Gegenstände und am Dienstag 9. Aber wie sieht es jetzt mit der Woche aus? Haben wir wirklich summierte 17 Gegenstände im Lager? Aus Lagersicht ist diese Betrachtung natürlich völliger Humbug, denn selbst wenn es sich um 17 völlig verschiedene Gegenstände handelt, möchte wir trotzdem lediglich wissen, wie der Bestand zu einem gewissen Zeitpunkt war, heißt der Endbestand einer Woche ist der Endbestand des letzten Wochentages und so weiter.
MicroStrategy unterstützt uns bei dieser Darstellung durch Metriklevel. Diese können nicht nur festlegen, auf welchem Level eine Metrik berechnet wird, sondern auch wie dieses Level berechnet wird. Die Metrik selbst ist simpel, denn wir summieren lediglich den Fakt „End Inventory“. Wichtig sind das Level und das Verhalten der Zwischensumme.
- Formel
- Zwischensumme / Aggregation
Da wir lediglich die Berechnung für die Zeitreihe anpassen wollen, ziehen wir das niedrigste Attribut aus der Hierarchie – das Datum – in das Level hinein und ändern die Gruppierung von „Standard“ auf „Ending – fact“. Der Unterschied zwischen „fact“ und „lookup“ besteht darin, was zur Bestimmung des letzten Elements herangezogen wird. In unserem Beispiel wären das für „fact“ alle Werte vom Dienstag und für „lookup“ nichts, da wir keine Werte für Sonntag haben. Das Report-Level bleibt selbstverständlich erhalten, da alle anderen Attribute normal berechnet werden sollen. Abschließend muss noch die Zwischensumme auf „Default“ gestellt werden, da ansonsten falsche Summen gebildet werden.
Im Anschluss folgt noch ein praktisches Beispiel und wie immer gilt, Fragen gerne in der Kommentarsektion.
Beispiel
Week | Day | Category | End Inventory |
2018 W 2 | 08.02.2018 | Book | 144 |
CD | 67 | ||
Movie | 51 | ||
Total | 262 | ||
09.02.2018 | Book | 125 | |
CD | 54 | ||
Movie | 38 | ||
Total | 217 | ||
10.02.2018 | Book | 97 | |
CD | 49 | ||
Movie | 32 | ||
Total | 178 | ||
11.02.2018 | Book | 94 | |
CD | 45 | ||
Movie | 55 | ||
Total | 194 | ||
12.02.2018 | Book | 160 | |
CD | 69 | ||
Movie | 52 | ||
Total | 281 | ||
13.02.2018 | Book | 149 | |
CD | 62 | ||
Movie | 50 | ||
Total | 261 | ||
14.02.2018 | Book | 142 | |
CD | 53 | ||
Movie | 41 | ||
Total | 236 | ||
Total | 236 |
Hier sieht man sehr deutlich, wie die einzelnen Kategorien summiert werden; die Gesamtsumme hingegen entspricht exakt dem letzten Tag. Nimmt man nun aus dem Bericht die einzelnen Tage heraus, sieht es folgendermaßen aus:
Week | Category | End Inventory |
2018 W 2 | Book | 142 |
CD | 53 | |
Movie | 41 | |
Total | 236 | |
2018 W 3 | Book | 94 |
CD | 36 | |
Movie | 25 | |
Total | 155 | |
Total | 155 |
Das Datum wird also nicht benötigt, um ein korrektes Ergebnis zu erhalten. Um genau zu sein, kann das Datum sogar komplett aus den Berichtsobjekten entfernt werden, ohne dass die Berechnung fehlerhaft wird. Und zum Ende noch die Kirsche auf dem Kuchen. Ganz gleich in welcher Reihenfolge die Attribute in der Tabelle vorkommen, es wird immer korrekt summiert bzw. über das Datum der letzte Wert herausgesucht.