Manchmal wollen Benutzer aus dem Cube heraus Daten in die Datenbank zurück schreiben. Diese könnten beispielsweise die Summe des Verkaufs, das Budget oder die Planzahlen der nächsten Monate sein. Dazu gibt es verschiedene Möglichkeiten:

• Die Benutzer schreiben Ihre Daten beispielsweise in eine Excel Datei (oder eine beliebige andere Textdatei). Danach werden diese Daten per SSIS ins DWH importiert.
• Eigene Lösung, die direkt in das DWH schreibt (Zum Beispiel ein Web Frontend).
• Die Benutzer haben Zugriff zu einem Cube durch Excel. Sie können in eine speziell definierte Measure-Gruppe schreiben. Danach werden die Daten automatisch im Cube gespeichert und in eine „Writeback“ Tabelle geschrieben.

Wir wollen die letzte Option umsetzen und werden hierbei folgende Schritte durchlaufen:

• Konfigurieren der Writeback Measure-Gruppe
• Setzen der Rechte des Benutzers  und Definition einer Rolle
• Deploy und Process des Cubes und der Rolle
• Wechseln des Schemas der neuen Tabelle

Anschließend zeigen wir:

• Wie man diese Measure-Gruppe mit Excel benutzen kann
• Wie die „Writeback“ Tabelle verwendet werden kann (durch den Einsatz von 2 Cubes: Einer liest, Einer schreibt)

 

Erstellen der Partition der Writeback Measure Gruppe im Cube Designer

Der Beispielcube sieht wie folgt aus: Bei der Writeback Measure Gruppe müssen folgende Punkte beachtet werden:

• Die Writeback-Daten müssen in einer/mehreren Measure-Gruppe/n sein.
• Alle Measures in der Writeback Measure-Gruppe müssen:
  • speicherbar sein
  • eine Sum-Aggregation haben

  

Dann gehen wir in den Partitions-Reiter -> Rechtsklick auf die Partition, die unsere Measure Gruppe enthält (In unserem Beispiel existiert  lediglich eine) -> Klick auf Writeback Setting…. In der Dialog Box müssen die Eigenschaften für eine neue SQL Server Tabelle gewählt werden. Die dann unsere Writeback-Tabelle wird. Folgende Eigenschaften müssen gesetzt werden:

• Table Name
• Data Source
• Storage mode

Die neue Writeback-Tabelle beinhaltet die Änderungen der Daten. Wir benennen die Tabelle und klicken OK. Eine neue Partition ist erstellt. Diese Operation können wir für alle gewollten Measure-Gruppen machen.

Benutzer Rechte

Der Benutzer muss genug Rechte haben, um die Daten zu speichern.

• db_DataWriter Rolle für die SQL Server Datenbank, um die Daten zu speichern
• Eine neue Rolle mit Vollzugriff (Administrator) muss im Cubeprojekt erstellt werden: Dabei nicht vergessen den Benutzer im Membership Reiter hinzuzufügen.

 

Deploy und Process des Cubes und der Rolle

Der Cube und die neue Rolle müssen verarbeitet sein. Dann ist die Writeback-Tabelle erstellt. Die Spaltennamen sind automatisch benannt und mit einem Nummernsuffix versehen. Folgende Spalten werden erzeugt:

• Alle Measures von unserer Writeback Measure-Gruppe
• Die IDs der Dimensionen
• Eine Datumsspalte
• Eine Benutzerspalte

Die Tabelle ist jedoch noch leer. In unserem Beispiel sieht das Create Table Statement der Writeback-Tabelle so aus: CREATE TABLE [dbo].[WriteTable_Fact Planning](                 [SalesPlanning_0] [float] NULL,                 [SalesTerritoryKey_1] [int] NULL,                 [DateKey_2] [int] NULL,                 [MS_AUDIT_TIME_3] [datetime] NULL,                 [MS_AUDIT_USER_4] [nvarchar](255) NULL ) ON [PRIMARY]

Speichern der Daten mit Excel

Der Benutzer kann jetzt den Cube mit Excel 2010 öffnen. Es funktioniert nicht mit Vorgängerversionen ohne Plug-In. Wir klicken im Options-Menu What-If-Analysis (Was-wäre-wenn-Analyse) und dann Enable What-If-Analysis (Was-wäre-wenn-Analyse aktivieren). Dann können wir direkt Automatically Calculate Changes (Änderungen automatisch berechnen) klicken: Jetzt kann der Benutzer Daten in Excel schreiben.

Vorsicht: Beim Speichern der Eingaben ist die Baumstruktur der Dimensionsausprägungen zu beachten. Wenn eine Eingabe auf einer Ebene gespeichert wird, so wird der Wert auf alle Blätter aufgeteilt:

Man sollte also nicht zu viele Dimensionen benutzen oder möglichst immer in Blätter schreiben weil:

• Einzig die Blätter in die „Writeback“ Tabelle geschrieben werden.
• Die Dauer des Speichervorgangs sehr lang werden kann.

Wenn der Benutzer die Änderungen speichern will muss er in What-If-Analysis gehen und Publish Changes (Änderungen veröffentlichen) klicken. Damit ist der Differenz zwischen dem eingegebenem und dem vorherigen Wert in die Tabelle geschrieben.

Schema der neuen Tabelle

Das Schema der neuen Tabelle (Writeback-Tabelle) ist automatisch das Default Schema. Es ist aber möglich das Schema in Analysis Services zu ändern. Dazu müssen wir die XML Ansicht des Cubes öffnen. Im <Partition> Tag der Writeback Partition müssen wir den Tag  <DbSchemaName>…</DbSchemaName> erstellen. Damit können wir dem Schema einen Namen geben: <Source xsi:type=„TableBinding„> <DataSourceID>TEST_Writeback</DataSourceID> <DbSchemaName>Schema_Name</DbSchemaName> <DbTableName>WriteTable_Fact Planning</DbTableName> </Source>

Lösung mit 2 Cubes: Einer schreibt, Einer liest

Wie kann man die Daten der neuen Tabelle benutzen? Wenn der Cube verarbeitet wird sind die zurückgeschriebenen Daten gelöscht. Dies liegt daran, dass der Cube die Daten beim Verarbeiten aus dem DWH zieht und dabei die Writeback-Tabelle nicht berücksichtigt. Eine Lösung ist 2 Cubes zu erstellen. Einen Cube um die Daten zu schreiben und einen anderen Cube um die Daten zu lesen. Dies realisieren wir über SSIS Pakete:

• Speichern der Daten:
  • Kopieren der Writeback-Tabelle in eine Planungs-Tabelle, die die Daten archiviert
  • Truncate der Writeback-Tabelle
  • Laden der Daten in das DWH für den Lese-Cube
    • Vom Staging
    • Vom Archiv
    • Verarbeiten der beiden Cubes

Hier sind die Vorzüge dieser Lösung:

• Alle Daten sind gespeichert
• Die Writeback-Tabelle wird nicht zu groß
• Man kann die letzte Planung visualisieren