Der hybride Ansatz kombiniert unterschiedliche Wege für das Lesen und das Schreiben der Daten. Sie werden aus OLAP gelesen und relational geschrieben. Der Ansatz verwendet dafür nicht die bekannte Rückschreibefunktionalität von SQL Server Analysis Services. Es werden stattdessen spezielle relationale SQL-Objekte verwendet, um die Dateneingabe zu speichern.
Im Folgenden wird erläutert, wie eine Planungsanwendung mit dem hybriden Ansatz erstellt wird.

Datenmodell

Das Datenmodell muss folgende Voraussetzung erfüllen: Die Kennzahlen müssen vom Datentyp „float“ sein, um Rundungsdifferenzen bei der Nutzung der Splashingfunktionalität zu vermeiden (Spalte „Type of measure“).

Abbildung 1: Definition der Kennzahlen im DeltaMaster Modeler

SQL-Objekte

Erstellung

Die SQL-Objekte werden durch die Ausführung eines SQL-Skripts erstellt. Das SQL-Skript befindet sich aktuell hier: „S:\Consulting\interne Projekte\Planung 2.0\Prototype Generierung Hybridlogik_Vxx.sql“ (zum Zeitpunkt der Dokumentation aktuelle Versionsnummer ist V19).
Vor der Ausführung des Skripts müssen drei Parameter angepasst werden: @FactID, @DoRecreateWBTable und @TransactionLevel. Die Parameter finden sich am Anfang des Skripts (Version 19), und zwar in den Zeilen 30, 33 und 37.

• @FactID entspricht der ID der Planungs-MeasureGroup; für das aktuelle Beispiel 1

• @DoRecreateWBTable kann die Werte 0 oder 1 enthalten. Wenn der Wert gleich 1 ist, wird die Eingabetabelle bei Skriptausführung neu erstellt. Der Wert kann auf 0 gesetzt werden, um zu verhindern, dass bereits eingegebene Plandaten gelöscht werden.

• @TransactionLevel ist ein binärer Parameter und legt die Transaktionsoptionen fest. Die Optionen 2 und 4 führen zur Erstellung globaler Transaktionsobjekte, wie Logging-Objekte und Transaktionsprozeduren. Die Option 1 erstellt Transaktionsobjekte für die aktuelle Planungs-MeasureGroup, wie eine Rollback-Tabelle. Die Option 8 ist optional und erstellt eine Archive-Tabelle, in der alle Einträge gesichert werden. Die gewünschten Optionswerte müssen einfach summiert übergeben werden. Der Wert 15 ist der Standardwert und ist die Summe aller verfügbaren Optionen.

Bedeutung der erzeugten SQL-Objekte

Nach der Ausführung des Skripts werden verschiedene Objekte (Tabellen, Views und Prozeduren) erstellt. Im Folgenden werden sie kurz erklärt.

• Die eingegebenen Daten werden in der Tabelle T_WriteBackSQL_FACT_<MeasureGroupID>_<MeasureGroupName> gespeichert.

• Es wird für jede Dimension der MeasureGroup eine View sowie eine materialisierte Tabelle erstellt. Die Tabellen enthalten die Dimensionselemente Dimensionsebenen (aller Hierarchien) und werden in der Rückschreiblogik im Wesentlichen für das Splashen verwendet.

• Die View V_WriteBackSQL_FACT_01_Sales ist für die Anbindung der OLAP Partition notwendig. Hierin werden die Spalten an die Struktur der normalen T_FACT-Tabellen angepasst und beispielsweise die zusätzlichen Transaktionsspalten ausgeblendet. Andernfalls wäre die Tabelle nicht in den Data Tools sichtbar, wenn manuell versucht wird eine Partition an einer MeasureGroup anzubinden.

• Die Prozedur P_WriteBack_FACT_01_Sales enthält die Rückschreiblogik. Hier wird der Datensatz bzw. werden die Datensätze (bei Splashing) bestimmt und in der Tabelle T_WriteBackSQL_FACT_01_Sales gespeichert.

• Die Transaktionslogik verwendet folgende Objekte. Sie werden gemäß des Parameterwertes für @TransaktionsLevel erstellt (siehe Punkt 2.1)

OLAP-Rückschreibe-Partition erstellen

Damit die relationalen Daten auch in der OLAP-Datenbank sichtbar sind, ist eine neue Partition an der MeasureGroup notwendig. Diese kann über die XMLA-Schnittstelle des Modelers automatisch hinzugefügt werden (siehe DeltaMaster Modeler Version 212 – ReleaseNotes, Punkt 2.19). Zur besseren Verständlichkeit wird hier der manuelle Prozess im BIDS veranschaulicht:

• Die Partitionsquelle muss in der Datenquelle „DeltaMaster_DS“ gesucht werden und dort die View V_WriteBackSQL_FACT_01_Sales ausgewählt werden. Alternativ kann die View auch zunächst der Datenquellensicht hinzugefügt werden und anschließend von dort („DeltaMaster_DSV“) selektiert werden.

Abbildung 2: Auswahl der Partitionsquelle

• Als nächstes muss der Speichermodus definiert werden. Damit die direkt in der SQL-Tabelle erzeugten Datensätze auch sichtbar sind, muss dies zwingend ROLAP sein.
• Dann stellt sich die Frage wie die Aktualisierungen der Daten ohne Cube-Process im Würfel ankommen. Hier gibt es aktuell zwei bekannte Möglichkeiten: RealTimeOLAP und Proactive Caching.

Die RealTimeOLAP-Option wird beim Aufbauen der OLAP-Verbindung in einem erweiterten Parameter gesetzt. Damit können die ROLAP Partitionen in Echtzeit gelesen werden. Der Nachteil ist, dass es sich um eine globale Einstellung handelt und diese für alle ROLAP-Partitionen der Datenbank wirkt. Das kann zu Performanceeinbußen führen. Vorteilhaft ist, dass nicht bei jedem Rückschreibevorgang das MDX-Script neu gelesen wird (wie dies bei anderen Optionen der Fall ist). Die Eigenschaft kann in der DeltaMaster-Anwendung im Verbindungsdialog gesetzt werden (siehe auch Punkt 4).

Abbildung 3: Einstellung der Speichermodus für RealTime-OLAP

Das „Proactive Caching“ ist eine Eigenschaft einer MeasureGroup-Partition und kann pro Partition getrennt gesetzt werden. Dabei handelt es sich um eine zusätzliche Option zum Speichermodus, dieser wird je nach Konfiguration des Proactive Cachings auch mit angepasst. In unserem Fall benötigen wir die möglichst direkte Aktualisierung der Daten. Daher wählen wir der Speichermodus Echtzeit-ROLAP (im Englischen „Realtime-ROLAP“ – nicht zu verwechseln mit dem oben genannten RealTime-OLAP – ohne R).
Der Speichermodus Echtzeit-ROLAP kann wie folgt erklärt werden:

„OLAP is in real time. Detail data and aggregations are stored in relational format. The server listens for notifications when data changes and all queries reflect the current state of the data (zero latency)…“

Um den Speichermodus zu definieren, müssen die Partition-Speichereinstellungen geöffnet und dort Echtzeit-ROLAP ausgewählt werden.

Abbildung 4: Einstellung der Speichermodus für Proactive Caching

Durch Klicken auf „Optionen“ können auf der Registerkarte „Allgemein“ die Cacheeinstellungen definiert werden, zum Beispiel die Aktualisierungshäufigkeit des Caches. In unseren Fall wählen wir die Aktualisierung mit Latenzzeit gleich 0.

Abbildung 5: Cacheeinstellungen

Anschließend können die Benachrichtigungen konfiguriert werden. Als Benachrichtigungsmethode ist „SQL Server“ festzulegen und die Tabelle T_WriteBackSQL_FACT_01_Sales als Nachverfolgungstabelle auszuwählen. Dies führt dazu, dass der proaktive Cache jedes Mal aktualisiert wird, wenn sich in dieser Tabelle etwas ändert.

Abbildung 6: Einstellung der Benachrichtigungen

• Zuletzt muss der Cube bzw. die betreffende Partition nochmal verarbeitet werden.

DeltaMaster Planungsanwendung

Die Analysesitzung sollte folgende Einstellungen erhalten:

• Nur für RealTime-OLAP, muss die Eigenschaft „RealTimeOLAP=TRUE“ in der Anmeldung zur OLAP-Datenbank unter „Weitere Optionen“ hinzugefügt werden. Für Proaktives Caching bleibt „Erweiterte Eigenschaften“ leer.

Abbildung 7: Erweiterte Eigenschaften für RealTime-OLAP

• Da wir relational rückschreiben, muss das relationales Modell angebunden werden
• Weiterhin müssen die Planungsfunktionen aktiviert sein
• Dort ist das Rückschreibverfahren umzustellen auf: „per modellspezifischer, gespeicherter Prozedur in relationaler Datenbank“. Als Verbindungszeichenfolge verwendet DeltaMaster automatisch die identische Verbindung zum relationalen Modell. Dies ist ggfs. noch anzupassen.

Abbildung 8: Dateneingabe-Einstellungen in Planungsanwendung

Ergebnis

In folgenden Bericht wird ein Umsatz von 700 EUR für die Produktgruppe „Arcade“ in Januar 2016 für Deutschland geplant.

Abbildung 9: Umsatzplanung

Die Eingabe ruft die Prozedur P_WriteBack_FACT_01_Sales, sowie die Transaktionsprozeduren P_WriteBack_Begin und P_WriteBack_Commit auf.

Abbildung 10: Aufruf der Prozeduren

Als Ergebnis werden acht Datensätze in der Tabelle T_WriteBackSQL_FACT_01_Sales erzeugt.

Abbildung 11: Erzeugte Datensätze in T_WriteBackSQL_FACT_01_Sales