Dieser Blogbeitrag knüpft an den Blogbeitrag „Analysewerte austauschen im Präsentationsmodus – Teil 1“ an und zeigt, wie mit dem Back-end die Umsetzung noch weiter optimiert werden kann.

Zielsetzung

Das Ziel ist, das Ergebnis aus dem vorangegangenen Blogbeitrag „Analysewerte austauschen im Präsentationsmodus – Teil 1“ mit dem Back-end so zu optimieren, dass nur ein relationaler Eingabebericht in DeltaMaster gepflegt werden muss.

Nebenbei verbessert sich die Darstellung der Hilfsdimension und auch der MDX-Code für den Analysewert wird kürzer.

Umsetzung

Zuerst legen wir uns eine Stammdatentabelle in der relationalen Datenbank an:

CREATE TABLE [dbo].[T_S_Werte](
					[WertBEZ] [nvarchar](50) NOT NULL,
					[SortierID] [smallint] NOT NULL,
					[Faktor] [smallint] NOT NULL
) ON [PRIMARY]

Wir erhalten damit die Tabelle [dbo].[T_S_Werte], die eine Spalte für die Bezeichnung des Analysewertes (WertBEZ) enthält, eine ID für die Sortierung (SortierID) und eine Faktorspalte (Faktor), die angibt, wie der Analysewert mit einem Faktor multipliziert wird, z.B. für Kosten (-1) und für positive Analysewerte 1.

Nun können wir diese Tabelle bearbeiten, beispielsweise auch mit einer relationalen Eingabeanwendung in DeltaMaster. Folgen wir dem Beispiel aus dem ersten Teil, so sieht die Tabelle wie folgt aus:

Abb. 1: Beispiel der Stammtabelle

Sicherlich fällt auf, dass hier ein Analysewert „Wert“ hinzugefügt wurde, obwohl dieser im Beispielemodell Chair gar nicht vorhanden ist. Das liegt daran, dass wir dieses Element im DeltaMaster-Filter ausblenden können, sodass in den anderen Berichten die Auswahl nicht in der Sicht angezeigt wird.

Nun wenden wir uns DeltaMaster ETL zu und legen eine neue Dimension an, die auf dieser Stammtabelle basiert, in diesem Beispiel „Werte“ genannt. Diese Dimension benötigt keinen ALL-Member, sie besitzt die ID aus der Spalte „SortierID“, den Namen aus der Spalte „WertBEZ“ und das Attribut Faktor aus der Spalte „Faktor“. Ebenso stellen wir eine Verknüpfung zwischen der Dimension und der Measure-Gruppe her, wobei wir als Quellspalte für die Measuregruppen-Dimension den Wert 1 nehmen.

Außerdem legen wir noch den Analysewert „Wert“ an, der mit NULL befüllt werden kann.

Nun erstellen wir das Modell neu und hinterlegen danach noch folgenden MDX-Code im Cube-Skript:

Scope([Measures].[Wert]);
[Measures].[Wert] = 
    (
     StrToMember('[Measures].[' + [Werte].[Werte].currentMember.Properties('Name') + ']')
     ,[Werte].[Werte].[Werte].&[1]
     ) 
     * StrToValue([Werte].[Werte].currentMember.Properties('Faktor'))
;
end scope;

Im Klartext: Wir überschreiben den neuen Analysewert „Wert“ mit dem Wert des Analysewerts, der den Namen des aktuellen Elements der Dimension Werte besitzt, mappen diesen auf das erste Element der Dimension, da wir die ID in der Measure-Gruppe für die Dimension „Werte“ auf 1 gemappt haben, und multiplizieren diesen mit dem dazugehörigen hinterlegten Faktor.

Im Front-end kann nun wieder der Name des Analysewerts mit dem MDX-Ausdruck {<viewX>} umbenannt werden, wenn dies erwünscht ist. Ebenso kann das Element „Wert“ der Dimension Werte aus der Sicht ausgeschlossen werden, sodass die Auswahl nicht in anderen Berichten in der Sicht auftaucht.

Bewertung des Endergebnisses

Als Endergebnis erhalten wir analog zum ersten Teil folgenden Bericht:

Abb. 2: Endergebnis

Diese ähnelt der Variante aus dem ersten Teil, nur dass wir den Dimensions-, Hierarchie- und Ebenennamen selbst wählen können, die Reihenfolge der Elemente jederzeit ändern können und eine Veränderung nur eine Anpassung in einer Tabelle bedeutet.