Das CASE WHEN Statement  wird in zwei Typen unterteilt:

A) “Simple” CASE:

CASE [MyValue]
  WHEN 100 THEN „Small“
  WHEN 1000 THEN “Middle”
  WHEN 10000 THEN “Large”
ELSE “Micro” END

B) “Searched” CASE:

CASE
  WHEN [MyValue] = 100 THEN „Small“
  WHEN [MyValue] = 1000 THEN “Middle”
  WHEN [MyValue] = 10000 THEN “Large”
ELSE “Micro”
END

Wie Chris Webb in seinem BI-Blog mitteilt, ist die Verwendung von Simple CASE performanter als Searched CASE, allerdings kann in der SQL Server Version 2005 die Verwendung von Simple CASE unter gewissen Umständen fehlerhafte Ergebnisse im ELSE Zweig erzeugen.

Voraussetzung dafür ist, dass in irgendeinem der Zweige ein anderes, berechnetes Measure benutzt wird, welches wiederum aus einem Tupel mit mindestens einer Dimensionsreferenz bestehen muss. Bsp:

CREATE MEMBER CURRENTCUBE.[Measures].TestCalc AS

([Date].[Calendar Year].&[2003],[Measures].[Sales Amount]),

Visible=1,FORMAT_STRING=“#,###0.00″;

Folgend die Definition eines berechneten Elements mit einer SIMPLE CASE Entscheidung auf Basis der AdventureWorks DW 2005 OLAP Datenbank:
(Ich bitte den Sinn der angeführten Berechnungen in den Hintergrund zu stellen …

CREATE MEMBER CURRENTCUBE.[Measures].SimpleCase AS

CASE [Date].[Calendar Year].CURRENTMEMBER

    WHEN [Date].[Calendar Year].&[2002] THEN

      ([Product].[Product Line].&[S],[Measures].TestCalc)

    + ([Product].[Product Line].&[],[Measures].TestCalc)

    WHEN [Date].[Calendar Year].&[2003] THEN

      ([Product].[Product Line].&[],[Measures].[Sales Amount])

    + ([Product].[Product Line].&[S],[Measures].[Sales Amount])

    ELSE   – “Any other year – Product line MOUNTAIN

      ([Product].[Product Line].&[M],[Measures].[Sales Amount])

END,

Visible=1,FORMAT_STRING=“#,###0.00″;

Das Measure summiert die Produktlinien „Accessorys“ und „Components“ in den Pfaden 2002 und 2003, benutzt im Pfad für das Jahr 2002 das Measure „TestCalc“ und zeigt im ELSE Zweig den Sales Amount der Produktinie „Mountain“ an. 

Ein berechnetes Element mit Verwendung der Searched CASE Variante würde dann wie folgt definiert werden müssen:

CREATE MEMBER CURRENTCUBE.[Measures].SearchedCase AS

CASE

    WHEN [Date].[Calendar Year].CURRENTMEMBER

     IS [Date].[Calendar Year].&[2002] THEN

     ([Product].[Product Line].&[S],[Measures].TestCalc)

   + ([Product].[Product Line].&[],[Measures].TestCalc)

    WHEN [Date].[Calendar Year].CURRENTMEMBER

      IS [Date].[Calendar Year].&[2003] THEN

      ([Product].[Product Line].&[S],[Measures].[Sales Amount])

    + ([Product].[Product Line].&[],[Measures].[Sales Amount])

    ELSE   – “Any other year – Product line MOUNTAIN

     ([Product].[Product Line].&[M],[Measures].[Sales Amount])

    END,

Visible=1,FORMAT_STRING=“#,###0.00″;

Das Ergebnis ist verblüffend, zieht man beide berechneten Member in die Abfrage eines Cubebrowsers:

Zeilen   : Dimension Promotion, Attribut Promotion
Filter    : Date.Calendar Year = 2004; Product.Product Line = Mountain

Wie man sieht, wird die Gesamtsumme in beiden Membern korrekt angezeigt, im Simple CASE Measure werden jedoch die Ergebnisse für die unteren beiden Zeilen NICHT angezeigt. Das Phänomen / Bug tritt NUR im SQL Server 2005 auf und NUR bei Verwendung eines berechneten Measures mit o.g. Bedingungen in irgendeinem der CASE Zweige.

Gefährlich bleibt es trotzdem, kontrolliert man nämlich nur die Gesamtsummen (was der eine oder andere Developer aus Zeitgründen sicher schon mal getan hat), fällt der Fehler eben NICHT auf.

Deswegen:

Checkt Eure CASE WHEN Member! Vor allem darauf ob Ihr Euch die Verwendung nicht ganz sparen wollt/könnt

Aber wer kommt denn auf die Idee, dass dieses Zitat wortwörtlich zu nehmen ist?

Ich sah mich mit einer Kundendimension von 172.000 Kunden konfrontiert, die etwa 200 Vertretern zugeordnet waren. Ergebnis der Abfrage sollten die Kunden sein, die in einem gewissen Monat keine Umsätze, dafür aber im Rest des Jahres Umsätze erzielt hatten.

 Übersetzt in den AdventureWorks Cube, wobei der Vertreter hier durch die Dimension “Produkt” ersetzt wird, sah die Abfrage zuerst so aus:

WITH

MEMBER
UmsatzDezember03
AS

(

    [Measures].[Internet Sales Amount]

    ,STRTOMEMBER(‘[Date].[Calendar].[Month].&[2003]&[12]‘, CONSTRAINED)

)

SET Kunden AS

EXCEPT(EXISTS

(NONEMPTY([Customer].[Customer].[Customer].MEMBERS

        ,[Measures].[Internet Sales Amount])

        ,[Product].[Product Categories].[Category].&[1])

,NONEMPTY([Customer].[Customer].[Customer].MEMBERS

    ,UmsatzDezember03))

SELECT

{

    [Measures].[Internet Sales Amount]

} ON 0,

{

    Kunden

} ON 1 FROM [Adventure Works]

WHERE [Date].[Calendar].[Calendar Year].&[2003]


Um der besseren Lesbarkeit willen erstellte ich das berechnete MEMBER UmsatzDezember03 um das – zugegeben etwas komplizierte – Kundenset zu filtern.

Die ursprüngliche Abfrage (nicht das Beispiel hier) benötigte 45 Sekunden, was bei einer so kleinen Dimension von 172.000 Membern nicht akzeptabel war. Query-Tuning war also unumgänglich.

Nehmen wir uns des Beispiels oben an: Diese Abfrage – mit “MDX Studio” auf dem AdventureWorks Cube ausgeführt – berechnete 44.240 Zellen und benötigte 2,6 Sekunden für die Ausführung.

Mosha’s Befehl zur Sparsamkeit gehorchend, verzichtete ich auf das Hilfsmember und brachte den Ausdruck für UmsatzDezember03 direkt in das Kundenset.

WITH

SET Customers AS

EXCEPT(

    EXISTS(NONEMPTY([Customer].[Customer].[Customer].MEMBERS

                ,[Measures].[Internet Sales Amount])

        ,[Product].[Product Categories].[Category].&[1])

,NONEMPTY([Customer].[Customer].[Customer].MEMBERS

    ,(

    [Measures].[Internet Sales Amount]

    ,STRTOMEMBER(‘[Date].[Calendar].[Month].&[2003]&[12]‘, CONSTRAINED)

)))

SELECT

{

    [Measures].[Internet Sales Amount]

} ON 0,

{

    Customers

} ON 1 FROM [Adventure Works]

WHERE [Date].[Calendar].[Calendar Year].&[2003]

Dies führte zu einer Berechnung von nur 7.272 Zellen, benötigte aber immer noch 2,6 Sekunden für die Ausführung. Nachdem ich mir auch das CONSTRAINED Flag in der STRTOMEMBER Funktion erspart hatte, lag die Ausführungszeit bei 0,6 Sekunden.

Was war passiert? Offensichtlich führte das Einfügen des berechneten Members UmsatzDezember03 dazu, das die Berechnung für den Term NONEMPTY([Customer].[Customer].[Customer].MEMBERS,UmsatzDezember03) für jedes einzelne Member der Kundendimension ausgeführt wurde – d.h. je mehr Member in der Dimension enthalten sind, desto langsamer wird die Abfrage.

Darüber hinaus ist festzustellen, dass das CONSTRAINED Flag die Query ebenfalls verlangsamt – was uns zu dem Schluss führt, das Mosha’s Zitat tatsächlich wortwörtlich zu nehmen ist. Allein das Einsparen der Worte “MEMBER, AS, STRTOMEMBER und CONSTRAINED” führt in obigem Beispiel zu einer Beschleunigung der Abfrage von 500% und zu einer 86%-igen Reduktion der berechneten Zellen.


In den Analysis Services 2008 tritt dieses Problem nicht mehr auf. “Hilfsmember” können hier ohne Scham verwendet werden. Beide auf einem SQL Server 2008 ausgeführten Abfragen berechneten nur die nötigen 7.272 Zellen.