Klassischerweise gibt es bei den Reporting Services Beschränkungen für die MDX-Abfragen auf Cubes:

1. Es gibt nur zwei Achsen: Spalte (Axis 0) und Zeile (Axis 1)
2. Auf der ersten Achse muss die Measure Dimension abgebildet werden

    SELECT
{ [Measures].[Some Measure]
        } ON COLUMNS,
{ [Dimension].[Dimension Hierarchy].MEMBERS
} ON ROWS
    FROM [Cube]

Damit ist auch vorgeschrieben, dass in Reporting Services Berichten Measures in Tabellen nur in den Spalten dargestellt werden können. Was aber tun, wenn die Measures in den Zeilen erscheinen sollen?
Zum Beispiel in einem Dashboard eine Auflistung der wichtigsten KPIs mit Vorperiodenvergleichen:

KPI_Tabelle_kurz

Tatsächlich lassen sich Measures trotzdem auf den Zeilen anzeigen. Dafür gibt es gleich mehrere Lösungsansätze.

Lösung A (statisches Layout):

Handelt es sich im Bericht um eine feste Liste der anzuzeigenden Measures (also: Anzahl und Namen der Measures sind definiert und ändern sich nicht), dann kann die MDX-Abfrage wie gewohnt geschrieben werden: mit den Measures auf der ersten Achse (Spalte), und zum Beispiel der Zeit auf der zweiten Achse (Zeile).

   SELECT
{ [Measures].[Gross Profit Margin]
[Measures].[Expense to Revenue],
[Measures].[Sales],
[Measures].[Sales Order]
        } ON COLUMNS,
{ [Date].[Calendar].MEMBERS
} ON ROWS
    FROM [Adventure Works]

 

Im Layout des Berichts muss dann aber für jedes Measure eine eigene Zeile in der Tabelle angelegt, der Name statisch in das Tabellenfeld eingetragen werden und das entsprechende Feld aus der Abfrage fest zugeordnet werden.
Das sieht dann zum Beispiel so aus:

KPI_Tabelle_SSRS

Vorteil: Die Abfrage kann wie gewohnt geschrieben werden.
Nachteil: Das Layout ist sehr statisch. Die anzuzeigende Liste der Measures ist nicht änderbar, ohne das der Bericht geändert werden muss.

 

Es gibt andere Lösungsansätze, die ein flexibleres Layout ermöglichen.
Zum Beispiel in der Art, dass die Measures vom Datenset auf den Zeilen geliefert werden. Mit diesem Ansatz sieht das Berichtslayout dann etwa so aus:

KPI_Tabelle_SSRS_kurz

Statt für jedes Measure eine eigene Zeile im Design vorzusehen, wird hier genutzt, dass die Measures aus dem Datenset auf den Zeilen geliefert werden.
Das widerspricht jedoch der eingangs beschriebenen Reporting Services Restriktion, dass die Measure Dimension auf der ersten Achse sein muss. Wie können die Measures dann auf den Zeilen geliefert werden?

Wie das mit Reporting Services möglich ist, das wird in den nächsten beiden Lösungen beschrieben.

Lösung B (Query als Text):

Grundsätzlich sind MDX Abfragen mit beliebig vielen Achsen möglich. Auch ist nicht vorgeschrieben, auf welcher Achse die Measure Dimension sein muss.
In dieser Lösung wird das ein bisschen ausgenutzt und die Abfrage quasi aus der Reporting Services “Verantwortung” genommen. Das passiert, indem sie als Ausdruck (Expr) eingefügt wird:

Query_Type_Expr

In diesem Ausdruck kann nun eine valide MDX-Abfrage hinterlegt werden, die die Measures auf den Zeilen abfragt.
Damit das so funktioniert, muss die Datenverbindung vom Typ OLE DB sein.

Vorteil: Die Abfrage kann (fast) wie gewohnt geschrieben werden. Es gilt nicht die Reporting Services Beschränkung der Measures auf den Spalten.
Nachteil: Ein Debuggen der Abfrage im Report Designer ist nicht bzw. nur sehr umständlich möglich.

Lösung C (Measures in benutzerdefinierter Dimension):

Ein dritter Weg ist das Anlegen einer eigenen Measure Dimension im Cube. Diese kann dann zum Beispiel [Reporting Measure] heißen und nur die Measures enthalten, die im Bericht benutzt werden.

Dim-ReportingMeasure2

Wichtig dabei ist, dass ein Attribut in dieser Dimension vorgesehen ist, dass den technischen Namen des Measures enthält. Zum Beispiel das Attribut [Reporting Measure].[Technical Key]
Dieses Attribut hat dann als Namen: [Measures].[My Measure Name]
Darüber kann dann wiederum die Verbindung zum “echten” Measure im Cube hergestellt werden.

Vorteil: Dynamisches Layout, Anzeigenamen von Measures können geändert werden
Nachteil: Aufwändig in der Implementierung (Pflegen und Beladen der Measure Dimension)

Fazit:
Drei Wege, drei Lösungen. Welches nun der beste Weg ist, ist nicht pauschal zu sagen, sondern muss je nach Fragestellung entschieden werden.