Bekanntlich ist der Zeitbezug in unseren Daten eines der wichtigsten Merkmale, das es überhaupt ermöglicht Periodenvergleiche darzustellen und letztlich über den Erfolg zu Vorperioden zu informieren. Der gängige Implementierungsweg für uns Berater ist die Erstellung einer Zeitdimension, also die Periode, mit Hilfe von DeltaMaster Modeler.
Was tun, wenn mehrere Zeitbezüge vorhanden sind
Ein durchaus üblicher Fall. Der Kunde liefert eine Faktentabelle mit Liefer- und Rechnungsdatum:
Abb. 1: Faktentabelle mit mehreren Datumsspalten
Wohlwissend, dass die Zeitanalyseelemente in DeltaMaster nur auf Basis einer einzigen Zeitdimension arbeiten, wird bei der Implementierung solcher Anforderungen das „Satzarten-Prinzip“ bevorzugt.
Das Satzarten-Prinzip
Dabei vervielfachen wir die Datensätze einer Faktentabelle um die unterschiedlichen Periodentypen (Liefer-, Rechnungsdatum) und fügen eine neue Schalter-Dimension „Periodentyp“ an, die das Umschalten zwischen Liefer- und Rechnungsdatum in DeltaMaster erlaubt.
Abb. 2: Faktentabelle mit einer Datumsspalte und Periodentyp
Die Zeitanalyseelemente in DeltaMaster beziehen sich weiterhin auf eine einzige Periodendimension, können aber durch Hinzunahme der neuen Dimension „Periodentyp“ in dem Bericht Auskunft über die unterschiedlichen Datumsperspektiven geben. Alles ist wunderbar, oder?
Neulich draußen beim Kunden
Was könnte uns Berater also dazu bewegen auf die „Anhäufung“ der Datensätze in der Faktentabelle doch zu verzichten oder diesen Implementierungsweg zumindest in Frage zu stellen?
Na? Klar, das Vervielfachen! Als ich diesen Weg einem unserer Kunden erläutert hatte, meinte er nur: Bei einem Datenvolumen von 30 GB und mehr, wie lange würde dann der Datenprozess laufen?
In der Tat bewegen wir uns mit diesem Konzept auf dünnem Eis: Indizes, das Löschen und Aufnehmen von Datensätzen und sogar ein Prozess mit Deltaverfahren, also inkrementelles Hinzufügen von Faktendaten, können uns bei diesem Datenvolumen vor Probleme stellen.
Alles bleibt wie gehabt
Die Lösung ist also, die Faktentabelle so zu belassen, wie sie geliefert wird. In DeltaMaster Modeler legen wir zwei unterschiedliche Periodendimensionen an (Rechnungsdatum, Lieferdatum). Das Ergebnis in DeltaMaster sieht folgendermaßen aus:
Abb. 3: Sichtfenster mit zwei Periodendimensionen
Die Dimension „Lieferdatum“ wird im Kontextmenü als Zeitdimension deklariert. Danach legen wir unsere Zeitanalyseelemente in der Dimension „Periodenansicht“ an und definieren den ersten Bericht:
Abb. 4: Periodenvergleich mit Lieferdatum
Bei aktiviertem „mdx.log“ können wir beobachten, dass von DeltaMaster folgender Code generiert und an die Datenbank geschickt wird:
WITH
MEMBER [Periodenansicht].[Periodenansicht].[temp] AS
'([Lieferdatum].[Lieferdatum].CurrentMember,
[Periodenansicht].[Periodenansicht].[Periodenansicht].&[1])', SOLVE_ORDER=0, VISIBLE=1
MEMBER [Periodenansicht].[Periodenansicht].[temp 2] AS
'([Lieferdatum].[Lieferdatum].CurrentMember.PrevMember,
[Periodenansicht].[Periodenansicht].[Periodenansicht].&[1])', SOLVE_ORDER=0, VISIBLE=1
MEMBER [Periodenansicht].[Periodenansicht].[temp 3] AS
'([Lieferdatum].[Lieferdatum].CurrentMember,
[Periodenansicht].[Periodenansicht].[Periodenansicht].&[1])-([Lieferdatum].[Lieferdatum].CurrentMember.PrevMember,
[Periodenansicht].[Periodenansicht].[Periodenansicht].&[1])', SOLVE_ORDER=125, VISIBLE=1
MEMBER [Periodenansicht].[Periodenansicht].[temp 4] AS
'Iif(([Lieferdatum].[Lieferdatum].CurrentMember.PrevMember,
[Periodenansicht].[Periodenansicht].[Periodenansicht].&[1])=0,Null,
(([Lieferdatum].[Lieferdatum].CurrentMember,
[Periodenansicht].[Periodenansicht].[Periodenansicht].&[1])-
([Lieferdatum].[Lieferdatum].CurrentMember.PrevMember,
[Periodenansicht].[Periodenansicht].[Periodenansicht].&[1]))/
Iif(([Lieferdatum].[Lieferdatum].CurrentMember.PrevMember,
[Periodenansicht].[Periodenansicht].[Periodenansicht].&[1])<0,-([Lieferdatum].[Lieferdatum].CurrentMember.PrevMember,
[Periodenansicht].[Periodenansicht].[Periodenansicht].&[1]),
([Lieferdatum].[Lieferdatum].CurrentMember.PrevMember,
[Periodenansicht].[Periodenansicht].[Periodenansicht].&[1])))', SOLVE_ORDER=150, VISIBLE=1
SELECT {[Periodenansicht].[Periodenansicht].[temp],
[Periodenansicht].[Periodenansicht].[temp 2],
[Periodenansicht].[Periodenansicht].[temp3],
[Periodenansicht].[Periodenansicht].[temp 4]} ON AXIS(0),
{[Measures].[Absatz]} ON AXIS(1)
FROM [Chair]
WHERE ([Lieferdatum].[Lieferdatum].[Liefermonat].&[201208])
Also wird der Periodenvergleich auf Basis der Dimension „Lieferdatum“ durchgeführt.
Jetzt wird der nächste Bericht auf Basis von Rechnungsdatum erstellt und siehe da:
Abb. 5: Falscher Periodenvergleich mit Rechnungsdatum
Sowohl die Spaltenüberschriften als auch die Werte werden falsch berechnet. Ein Blick in das „mdx.log“ zeigt, dass der obige Code ohne jegliche Änderung an die Datenbank geschickt wurde. Jetzt ist klar, dass wir für die Berechnung der Periodenwerte auf Basis des Rechnungsdatums andere Zeitanalyseelemente benötigen, die wir aber nicht mit dem Zeitanalyseassistenten anlegen können. Auch ohne viel MDX-Wissen, können wir uns den vorherigen Code zunutze machen und mit ein paar kleinen Änderungen das Ziel erreichen.
Zeitanalyseelemente für Rechnungsdatum
Für die aktuelle Periode:
Abb. 6: Berechnetes Element für die aktuelle Periode
Für die Vorperiode:
Abb. 7: Berechnetes Element für die Vorperiode
Für die absolute Abweichung:
Abb. 8: Berechnetes Element für die absolute Abweichung
Für die relative Abweichung:
Abb. 9: Berechnetes Element für die relative Abweichung
Wir passen unseren Bericht für das Rechnungsdatum an und benutzen die neuangelegten Zeitanalyseelemente in der Spaltenachse:
Abb. 10: Richtiger Periodenvergleich mit Rechnungsdatum
Schlusswort
Es wird ersichtlich, dass mit wenigen einfachen Kniffen in DeltaMaster auch Vergleiche über mehrere Periodendimensionen möglich sind. In Abhängigkeit des Datenvolumens gilt es also abzuwägen, ob das Satzarten-Konzept oder die Implementierung aller Periodendimensionen sinnvoller ist.
