Wenn in BI-Projekten Stammdaten nicht nur aus existierenden Vorsystemen versorgt werden sollen, sondern auch das Anlegen neuer Elemente oder das Verändern von Eigenschaften durch den Anwender direkt in DeltaMaster gefordert wird, bedeutet dies zusätzlichen Aufwand bei der Implementierung und eingeschränkten Bedienkomfort für den Anwender.

Microsoft Analysis Services bietet dazu unter dem Begriff „Dimension Writeback“ einen vermeintlich vielversprechenden Lösungsansatz an, der im Folgenden vorgestellt wird.

So mancher Bissantz-Consultant, Businesspartner oder Kunde wird sich in BI-Projekten mit der Anforderung konfrontiert gesehen haben, dass Stammdaten nicht nur aus existierenden Vorsystemen versorgt werden sollen, sondern auch das Anlegen neuer Elemente oder das Verändern von Eigenschaften (Attributen) durch den Anwender direkt in DeltaMaster notwendig oder zumindest wünschenswert ist. Beispiele sind:

• Bei der Vertriebsplanung sind potentielle Neukunden und zukünftige Produkte einzubeziehen, die in den ERP-Systemen noch gar nicht vorhanden sind.
• Im Projektcontrolling werden laufend neue Projekte und deren Struktur gepflegt.
• In einer Finanzanwendung werden ausschließlich im BI-System „hypothetische“ Kostenarten, Kostenstellen und Kostenträger definiert.

Grundsätzlich ist dies in unseren Lösungen mit DeltaMaster und Microsoft SQL Server/Analysis Services selbstverständlich auch heute lösbar, jedoch eher aufwändig hinsichtlich Modellierung und Aktualisierungsprozessen und vor allem mit Einbußen in Sachen Bedienkomfort für den Anwender:

• Da DeltaMaster-Anwendungen aktuell stets nur auf einer physischen Datenquelle basieren können, muss zur Stammdatenpflege der Tabellen im Data Warehouse eine separate relationale Anwendung erstellt werden. Der Anwender muss also zwischen dieser und seiner eigentlichen Reporting-, Analyse- oder Planungsanwendung hin- und herwechseln.
• Der alternative Einsatz des Parent-Child-Editors zur Strukturpflege ist für die meisten Anwendungsfälle „overengineered“ und erfordert manuelle Anpassungen im Datenmodell, die nicht von DeltaMaster Modeler unterstützt werden (Proaktives Cachen).

Microsoft Analysis Services bietet dazu unter dem Begriff „Dimension Writeback“ einen vermeintlich vielversprechenden Lösungsansatz an, der bei uns jedoch bislang keine Anwendung findet. Was steckt dahinter, wie funktioniert das Ganze und was spricht für oder gegen den Einsatz?

Zunächst scheint alles ganz einfach: In DataTools ist für die betroffene Dimension lediglich die Eigenschaft „WriteEnabled“ zu aktivieren, damit laut Kontexthilfe „die Dimension von Clientanwendungen aktualisiert werden kann“. Im laufenden Betrieb muss die Clientanwendung (DeltaMaster) dann entweder ein XMLA-Statement (bei regulären Dimensionen) oder ein MDX-Statement (bei Parent-Child-Dimensionen) erzeugen. Analysis Services erzeugt daraus entsprechende SQL-Statements und manipuliert direkt die zugrundeliegende Dimensionstabelle.

Der letzte Aspekt stellt einen grundsätzlichen konzeptionellen Unterschied zum Cell Writeback (dem Rückschreiben von Daten z. B. beim eigentlichen Planungsprozess) dar: Eingaben aus dem Frontend werden nicht separat von den ursprünglichen, per ETL-Prozess eingefügten (Stamm-)Daten gehalten, sondern ergänzen bzw. verändern diese. Dies würde bei der in unseren Projekten üblichen Vorgehensweise (zyklischer vollständiger oder inkrementeller Ladeprozess) individuelle, mitunter aufwendige Prüfungen und Manipulationen mittels SQL-Prozeduren vor der Ausführung des „Transform_All“ erfordern.

Hinsichtlich Berechtigungen müssen für den gewünschten Anwenderkreis Lese-/Schreibrechte sowohl in den betroffenen MSAS-Rollen für die jeweilige Dimension als auch in den SQL-Datenbankrollen für die entsprechende Tabelle gewährt werden.

Leider existieren darüber hinaus zusätzlich diverse Restriktionen:

• Die DataSource muss Microsoft SQL Server sein. Fremdprodukte (Oracle, IBM, SAP etc.) werden nicht unterstützt.
• Das Feature ist in der Standard Edition von Microsoft SQL Server nicht verfügbar.
• Die DataSourceView muss ein Star Schema sein. Die obige Formulierung im Singular („zugrundeliegende Dimensionstabelle“) war also kein Tippfehler. Dies ist ein konzeptioneller Widerspruch zum bewährten Snowflake-Ansatz in DeltaMaster Modeler und verhindert die Automatisierung in unseren Projekten.
• In den zu generierenden XMLA-Statements müssen stets alle Dimensionsattribute spezifiziert werden. Selektive Änderungen sind nicht erlaubt.
• Letztlich wurde das Feature mit SQL Server 2016 für das nächste Release abgekündigt.

Vor diesem Hintergrund wird verständlich, warum DeltaMaster das Konzept des Dimension Writeback nicht unterstützt.

Weblinks:

• Übersicht Writeback in Analysis Services
  https://blogs.msdn.microsoft.com/data_otaku/2012/06/03/building-a-writeback-application-with-analysis-services/
• Einführung in Dimension Writeback
  https://blogs.msdn.microsoft.com/data_otaku/2012/06/20/introducing-dimension-writeback/
• Write-Enabled Dimensions in SQL Server 2016
  https://msdn.microsoft.com/en-us/library/ms174540.aspx
• MDX-Syntax ALTER CUBE (nur Parent-Child-Dimensionen)
  https://msdn.microsoft.com/en-us/library/ms144822.aspx