Dieser Blogbeitrag erklärt wie man Zeitanalyseelemente im OLAP-Cubeskript anlegt, die mit mehreren Zeithierarchien funktionieren. Mit diesem Lösungsansatz kann vermieden werden, dass man für jede verwendete Zeithierarchie eigene Zeitanalyseelemente anlegen muss.

Mit DeltaMaster ist es sehr einfach Zeitvergleiche darzustellen. Oft soll zum Beispiel der aktuelle Monat mit dem Vorjahr oder der Vorperiode verglichen werden. Solche Auswertungen lassen sich mithilfe der Magischen Knöpfe in DeltaMaster 6 innerhalb von Sekunden erstellen. Technisch werden hierzu die sogenannten Zeitanalyseelemente auf der OLAP-Hilfsdimension „Periodenansicht“ angelegt und mit in der Pivottabelle verschachtelt.

Dies kann DeltaMaster 6 vollautomatisch. Ebenfalls kann DeltaMaster erkennen, welche Hierarchie in der Periodendimension verwendet wird und passt gegebenenfalls das Zeitanalyseelement an, ohne dass der Anwender etwas tun muss. Das bedeutet, es kann dasselbe Element für unterschiedliche Zeithierarchien (z. B. Periode, Periode_KW) verwendet werden.

Abbildung 1: Editor für Zeitanalyseelemente

 Je nach Bedarf können auch benutzerdefinierte Zeitanalyseelemente in DeltaMaster angelegt werden (Modus: Modellieren). Möchte man dem Anwender diese für jede neue Anwendung von vornherein zur Verfügung stellen, empfiehlt sich das Anlegen dieser Zeitanalyseelemente über das Cubeskript direkt in der OLAP-Datenbank. Das Cubeskript ist DeltaMaster vorgelagert. Die Definition der dort erstellten berechneten Elemente oder Zeitanalyseelemente kann von DeltaMaster nicht mehr beeinflusst werden. Das Zeitanalyseelement kann also nicht in Abhängigkeit der verwendeten Zeithierarchie von DeltaMaster angepasst werden. Die Anpassung muss direkt im Cubeskript erfolgen.

Das Zeitanalyseelement muss so angelegt werden, dass über den CurrentMember-Operator geprüft wird, welche Hierarchie für den Bericht aktuell verwendet wird. Je nach verwendeter Hierarchie wird die Definition des Zeitanalyseelements entsprechend angepasst. Die Prüfung erfolgt hier im Beispiel für eine bessere Übersichtlichkeit mit der CASE-Funktion statt mit der IIF-Funktion (Beide Funktionen sind möglich).

Wichtig ist, dass als CurrentMember der ALL-Member der jeweiligen Hierarchie ausgeschlossen wird. Hintergrund ist folgender: Wenn z. B. die Hierarchie 2 „Periode_KW“ in DeltaMaster gewählt ist, ist der CurrentMember der Hierarchie “Periode” automatisch das ALL-Element. Eine Prüfung nach dem CurrentMember liefert also auch bei der nicht ausgewählten Hierarchie „Periode“ ein Ergebnis, nämlich das ALL-Element. Das bedeutet: Obwohl zwar die Hierarchie „Periode_KW“ gewählt ist, ist die erste WHEN Bedingung der CASE-Funktion für die Hierarchie „Periode“ erfüllt. Das hat zu Folge, dass die falsche Definition für das Zeitanalyseelement verwendet wird (Definition für Hierarchie “Periode” statt “Periode_KW”). Um dies zu vermeiden, schließt man das ALL-Element der jeweiligen Hierarchien mit der NOT-Funktion für die WHEN-Prüfung einfach aus.

Das fertige MDX lautet folgendermaßen (Zeitanalyseelement hier Vorperiode):

CREATE MEMBER CURRENTCUBE.[Periodenansicht].[Periodenansicht].[VP cube]
AS
CASE
WHEN
NOT([Periode].[Periode].CurrentMember is [Periode].[Periode].[Alle Jahre]) AND
[Periode].[Periode].CurrentMember is [Periode].[Periode]
THEN ([Periode].[Periode].CurrentMember.PrevMember,[Periodenansicht].[Periodenansicht].[Periodenansicht].&[1])
WHEN
NOT([Periode].[Periode].CurrentMember is [Periode].[Periode_KW].[Alle Jahre]) AND
[Periode].[Periode_KW].CurrentMember is [Periode].[Periode_KW]
THEN
([Periode].[Periode_KW].CurrentMember.PrevMember,[Periodenansicht].[Periodenansicht].[Periodenansicht].&[1])
ELSE NULL
END,
VISIBLE = 1;

Hiermit ist es möglich, Zeitanalyseelemente im Cubeskript anzulegen, die auch bei unterschiedlichen Zeithierarchien funktionieren.

Das Prinzip lässt sich natürlich auch auf berechnete Elemente in anderen Dimensionen mit mehreren Hierarchien übertragen.