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.