ixto-Blog » Analysis Services 2008

Spaltenreihenfolge in Drillthrough Actions

Marcel Ebner — Fri, 10 Sep 2010 14:05:44 +0000

Wer schon einmal Excel Drillthrough-Actions in einem Cube erstellt hat, wird sich mit Sicherheit mindestens zweimal durch das Fenster “Drillthroughspalten” geklickt haben, schließlich kann es kaum vorkommen, dass man schon beim ersten Mal exakt die Informationen trifft, die der Kunde nach der Präsentation des Drillthrough-Features für beachtenswert hält. Entweder hat man die falschen Dimensionen und Attribute gewählt oder die Reihenfolge ist unglücklich.

Wer dann, mit Hoffnung im Herzen und einem Mausklick rechts, versucht, im Kontextmenü den Eintrag “Reihenfolge ändern” oder “Dimension auswählen” zu finden, wird bitter enttäuscht. Zu sehen gibt’s nur “Löschen”.

So bleibt der Versuch, zwischen zwei vorhandenen Dimensionen noch eine dritte hinzuzufügen oder allein einen Eintrag zu ändern, von Misserfolg gekrönt und man darf sich die Aktionsspalten nochmal ganz von vorn zusammenklicken. Will man darüber hinaus gar die Reihenfolge der Attribute einer Dimension ändern, ist man (fast) hilflos der von Visual Studio angebotenen Reihenfolge ausgeliefert, deren Sortierungsgrundlage wohl immer ein Geheimnis bleiben wird.

Zum Glück gibt es noch die Möglichkeit im XMLA Script des Cubes selbst einzugreifen.

Hierzu sollte man im Reiter “Aktionen” im Fenster “Aktionsplaner” die eben erstellte Drillthrough-Aktion auswählen, in der Eigenschaft [ID] den entsprechenden Wert auslesen und im Projektmappenexplorer mit Rechtsklick auf den entsprechenden Cube “Code anzeigen” wählen. VisualStudio öffnet eine neue Reiterkarte mit der Cubedefinition im XMLA Format, mit Strg+F kann man den Abschnitt mit der Drillthrough-Aktion schnell finden. (Die XML-Elemente , und die Sequenz müssen vorhanden sein, das Actions-Element ist unterhalb der KPIs zu finden)

Nun kann man die Elemente innerhalb des -Element per Cut&Paste verschieben. Leider gibt es (bisher) keine Möglichkeit den Anzeigenamen der Spalten in Excel festzulegen, aber, immerhin, die Reihenfolge der Attribute (Column) ist nun frei wählbar. Speichert man dann die Änderungen ab, verändert sich auch die Anzeige der Dimensionsreihenfolge im Fenster “Drillthroughspalten”, zwar erkennt der Designer nur, dass eine Dimension vor den Measures steht und zeigt dementsprechend alle Attribute der Dimension vor dem Measure an, die Reihenfolge der Spalten aber, wie sie im XMLA Script festgelegt ist, bleibt beim Exceldrillthrough erhalten.

(nur Promotion Name vor SalesSummary, nicht auch End Date und Start Date)

Analysis Services und das nachträgliche Erlauben von NULL-Werten in den Quelldaten – oder: Wie werd ich bloß die 0en los?

Markus Schechner — Wed, 30 Jun 2010 18:22:55 +0000

Ich hatte vor kurzem eine interessante Begegnung mit einem SSAS Cube (2008), über die ich an dieser Stelle gerne berichten möchte.

Dabei ging es um einen Cube, bei dem für ein bestimmtes Measure die Leerzeilenunterdrückung nicht so richtig funktionierte. Wenn man dieses Measure, das eigentlich eher selten gefüllt war, abfragte, dann sah das in etwa so aus:

Wie in diesem aus der Adventure Works stammenden Beispiel (wir sehen hier den Reseller Sales Discount Amount nach Reseller Telefonnummer) wurden die leeren Zellen mit einer 0 angezeigt, was ja bekanntlich nicht leer ist und somit auch nicht unterdrückt werden kann. Bei kurzem Blick in die Quelle fand ich in etwa folgendes Bild:

War also alles korrekt, was die Analysis Services so angezeigt haben. Der verwunderliche Teil der Geschichte beginnt aber auch erst jetzt.

Da es für Measures, bei denen mich die 0en gar nicht interessieren, nur bedingt Sinn macht, diese in der Datenbank abzulegen, habe ich also die Definition der Tabelle so geändert, dass die betroffene Spalte ab sofort NULL-Werte erlaubt. Danach wurden dann noch mit einem kleinen Statement wie unten die 0en eliminiert.

UPDATE dbo.FactResellerSales

SET DiscountAmount = NULL

WHERE DiscountAmount = 0

Wie fast zu erwarten ist, reicht das aber noch nicht aus, denn bis die Zahlen dann wirklich im Cube landen, haben wir ja noch ein paar Abstraktionsebenen vor uns. In diesem Fall war die nächste zu überwindende Hürde die View, die der Cube für den Datenzugriff benutzt:

Dort war die Spalte nämlich weiterhin als NOT NULL definiert (im Bild ganz unten). Also erst mal rasch die Metadaten der View aktualisiert:

SP_REFRESHVIEW N’dbo.v_FactResellerSales’;

Prompt stimmt die View mit der Realität überein. Aber selbstverständlich reicht auch das noch nicht, damit die 0en aus meinem Cube verschwinden. Es gibt da ja auch noch die Data Source View in den Analysis Services, die Metadaten speichert und die ich deswegen vorsorglich aktualisierte. Das Visual Studio meldete mir aber leider nach dem Klick auf den Refresh-Knopf, dass keine Änderungen gefunden wurden. Und wenn man sich dann die Eigenschaften der Spalte in der DSV anschaut:

Dann gibt es eine Eigenschaft AllowNull, die leider immer noch auf False stand. Und
natürlich sind die 0en nach erneuter Aufbereitung auch immer noch im Cube.

Da ich bei meiner View als Datenquelle bleiben wollte habe ich also kurzfristig „Tabelle ersetzen durch neue benannte Abfrage“ gewählt und danach dann wieder die ursprüngliche View über „Tabelle ersetzen durch andere Tabelle“ übernommen. Und endlich: AllowNull steht auf true. Das Ganze also schnell auf dem Server bereitgestellt, aufbereitet und … NICHTS! Immer noch grinsen mich die 0en förmlich an.

Hm, ist vielleicht beim Measure selbst noch was falsch eingestellt?

Eigentlich sieht alles gut aus. NullProcessing steht auf Automatic, was der Default ist. Ich persönlich musste das zwar bisher auch noch nie ändern, aber irgendwann ist ja immer das erste Mal:

Nach dem Ändern des NullProcessing auf Preserve verwunderte dann beim Bereitstellen, dass die automatische Aufbereitung keinen Anlass sah, die betroffene Measure Group neu mit Daten zu befüllen. Wen wundert’s dann noch, dass die 0en auch immer noch da waren.

Die nun folgende manuelle Aufbereitung war wohl die leichteste Übung, und endlich:

Ich bin die 0en los!

Excel 2010 – Comeback des OLAP-Writebacks

Markus Schechner — Thu, 01 Oct 2009 12:29:28 +0000

Hallo zusammen,

ich habe in einer Feature-Liste für das neue Excel 2010 etwas gelesen, was ich unbedingt mal ausprobieren musste: Das allseits gefürchtete/geliebte Writeback für OLAP-Cubes kommt zurück.

Meine Ergebnisse möchte ich Euch natürlich nicht vorenthalten. Ich habe mir in einem 2008er Cube (Adventure Works 2008) eine kleine, einfache Partition mit Planzahlen gebaut und habe dort das Writeback im Modus ROLAP aktiviert (die AS können das mit dem Zurückschreiben übrigens durchweg seit mind. Version 2000 und mit dem Excel Add-in for SQL Server Analysis Services konnte man das sogar schon mal benutzen).

Dann habe ich mich mit Excel 2010 auf diesen Cube verbunden und die “What-If-Analyis” aktiviert.

Folgende Settings habe ich genommen.

Dann hab ich mein Measure mit zwei Dimensionen in die Pivot-Tabelle gepackt…

… und den Wert für Europa erhöht.

Nach dem Neuberechnen der Pivot-Tabelle haben sich alle zugehörigen Werte erhöht.

Allerdings ist das ganze bis dahin nur eine Art Simulation. Erst wenn man es explizit sagt, werden die Änderungen in den Cube übernommen.

Dort landen sie dann in der vorher definierten Tabelle.

Nett, oder? Und die aus alten Zeiten bekannten Performanceprobleme beim Writeback auf größere Datenmengen sollen seit SQL Server 2008 auch der Vergangenheit angehören, da nicht mehr nur ROLAP, sondern auch MOLAP unterstützt wird. Das kann man aber auf einer Adventure Works schlecht überprüfen.