Die Best Practice Warnungen im Business Intelligence Development Studio (BIDS) gibt es seit SQL Server 2008. Sie sind vor allem für Anfänger eine schöne Sache, um oft gemachte Fehler zu vermeiden. So erinnern einen die blauen Wellenlinien im Dimensionsdesigner der Analysis Services z.B. an fehlende Attributbeziehungen oder schlagen numerische Schlüssel zumindest für große Dimensionen vor.
Eine Warnung haben ich und alle Kollegen mit denen ich bisher gesprochen habe bisher jedoch weitestgehend ignoriert:
Abbildung 1 Best Practice Warnung im BIDS
Diese Warnung, hier in der Datumsdimension der Adventure Works, ist im BIDS mit der Wichtigkeit Low definiert und lautet auf Deutsch: “Vermeiden Sie sichtbare Attributhierarchien für Attribute, die in benutzerdefinierten Hierarchien als Ebenen verwendet werden”. Ursache ist in diesem Fall z.B. die Attributhierarchie Date, die sichtbar ist und außerdem in den benutzerdefinierten Hierarchien “Calendar” und “Fiscal” benutzt wird. Der Grund der Warnung ist also relativ schnell klar, warum das jedoch schlecht sein soll, dem Anwender auch die flache Liste der Tage anzubieten, leuchtet erst mal nicht ein, weswegen ich das also bisher auch immer ignoriert habe.
Kürzlich sind wir jedoch beim Bau eines Kundenberichtes auf ein Phänomen gestoßen, das hoffentlich ein Bug in den SSAS ist oder mich und meine Kollegen Lügen straft.
Überführt in die Adventure Works könnte der betroffene Bericht folgendermaßen aussehen:
Abbildung 2 Ausgangsabfrage
Es werden die Umsätze nach Produktkategorie angezeigt und als Parameter wird die Kalender-Hierarchie angeboten. Wählt man nun z.B. den 1. Und 2. Januar 2008 aus, erhält man das obige Ergebnis. Soweit noch alles schön. Erweitert man die Anforderung nun dahingehend, dass zusätzlich die Tage an denen die Verkäufe stattgefunden haben angezeigt werden sollen, passiert folgendes:
Abbildung 3 Falsches Ergebnis nach Hinzufügen des Datums
Der Filter, der über die benutzerdefinierte Hierarchie gesetzt wurde, verliert scheinbar seine Wirksamkeit. Wir haben plötzlich nicht mehr Fahrräder für 63 Tsd $ verkauft, sondern für 28 Mio. Klappen wir diese dann auf, ergibt sich folgendes Bild:
Abbildung 4 Die Verwirrung ist komplett
Ich habe also nicht geschummelt. Der Filter steht immer noch auf 1. + 2.1.2008.
Ein solches Verhalten kenne ich bisher nur bei der Verwendung von bestimmten SCOPE-Statements im MDX Script, die nicht Multiselect-fähig sind. Dies kann hier aber ausgeschlossen werden, da das gleiche Verhalten auch bei komplett leerem MDX Script auftaucht.
Was können wir nun aber auf die Schnelle tun? Wir können uns an die Best Practice Warnungen des BIDS halten.
Die bestehende Datumsdimension wird also ein bisschen umgebaut.
Abbildung 5 Originale Datumsdimension
Zuerst nennen wir das Schlüsselattribut “Date” in “DateKey” um und setzen Attribute Hierarchie Visible auf “False”. Dann erzeugen wir ein neues Attribut “Date”, dass als KeyColumns die Spalte “DateKey” und als NameColumns das “SimpleDate” verwendet.
Abbildung 6 Datumsdimension nach Umbau
Wenn wir das Ganze dann bereitstellen, verschwindet nicht nur die vermeintlich unnütze Warnung, sondern wir erhalten auf unsere Abfrage von oben, dass folgende Ergebnis:
Abbildung 7 Richtiges Ergebnis nach Umbau
Nun sieht es so aus, wie wir es von Anfang an erwartet hätten. Als schön kann man dieses Verhalten aber nicht gerade bezeichnen, da solche Umbauten natürlich Zeit kosten und bei exzessivem Einsatz von Scopes auch Folgefehler verursachen können. Hoffen wir also, dass das wirklich ein Bug ist und in einem zukünftigen Update wieder verschwindet. Wenn ich in den nächsten Tagen die Muße finde, werde ich jedenfalls versuchen, das bei Microsoft Connect einzustellen.