Die Hybrid-Planungstechnik ist mittlerweile weit verbreitet und hat die Feuertaufe bereits mehr als einmal bestanden. Noch nicht ganz so weit verbreitet sind alle Tricks und Kniffe, die im Umgang mit solchen Systemen notwendig sind. Ein ganz zentraler Baustein von Planungssystemen sind Vorschlagswerte, die dem Planer die Arbeit erleichtern. Dieser Artikel beschäftigt sich primär mit der Frage, wo genau diese Daten eigentlich hingehören und was passiert, wenn sie an der falschen Stelle abgelegt werden.
Grundlagen
Schauen wir uns zunächst die Grundlagen anhand einer leicht modifizierten Chair-International-Datenbank an. Hinter jeder Planungs-MeasureGroup liegen zwei (bei normalem Hybrid) oder drei Partitionen. Die normale T_FACT-Partition, die in der Regel die Ist-Daten und evtl. historische Planungen enthält. Weiterhin die V_WriteBackSQL-Partition. In normalen Hybrid-Lösungen werden hier alle Plandaten mit den echten Zellwerten gespeichert und die Partition ist per ROLAP angebunden. In Delta-Hybrid-Lösungen liegen hier die verdichteten Planwerte per MOLAP-Anbindung und es gibt weiterhin noch die V_WriteBackSQL_Delta-Partition, welche die Veränderungen gegenüber den MOLAP-Planwerten enthält und auf ROLAP basiert.
Hier ein Beispiel aus einer normalen Hybrid-Anwendung:
Abbildung 1: Beispiel aus einer normalen Hybrid-Anwendung
Die Frage ist nun, in welche Tabelle (bzw. View) die Vorschlagswerte hineingehören?
Falsch
Bindet man die Vorschlagswerte über die Basisfunktionalität von DeltaMaster ETL per SourceTable-Bericht an, werden die Daten ganz normal in die T_FACT-Tabelle geladen. Hier eine typische Konstellation aus unserer Demoanwendung:
Abbildung 2: Eine typische Konstellation aus unserer Demoanwendung
Dagegen ist auch erstmal nichts einzuwenden und ist spätestens unter dem Aspekt, dass die T_FACT-Tabelle mit allen Foreign Keys bestückt ist, um die referentielle Integrität aller geladenen Daten sicherzustellen, auch unbedingt sinnvoll.
Schauen wir uns nun an, wie sich die Planungsanwendung verhält, wenn wir mit der Konfiguration ins Rennen gehen. Hierfür haben wir einen kleinen Bericht vorbereitet, der uns die Eingabe in einem kleinen Datenraum ermöglicht. Zunächst wollen wir neue Daten bei Herrn Schmid eintragen:
Abbildung 3: Eingabe neuer Daten in einem kleinen Datenraum
Nach Bestätigung der Eingabe mit der Enter-Taste wird dieser Datensatz erwartungsgemäß zurückgeschrieben und die Abweichung umgehend ausgerechnet:
Abbildung 4: Darstellung der Abweichung
Auch in der Rückschreibtabelle finden wird die Daten erwartungsgemäß auf zwölf Monate gleichverteilt wieder:
Abbildung 5: Rückschreibtabelle
Es scheint auf den ersten Blick alles in Ordnung zu sein. Doch mit der Annahme liegen wir leider wie der nächste Test beweist – die Eingabe auf eine (mit Vorschlagswerten) gefüllte Zelle:
Abbildung 6: Eingabe auf eine (mit Vorschlagswerten) gefüllte Zelle
Nach Betätigen der Enter-Taste ergibt sich ein anderes Bild. Der Wert verschwindet wieder:
Abbildung 7: Neue Darstellung nach Betätigen der Enter-Taste
Die Rückschreibtabelle bleibt ebenfalls unverändert und enthält weiterhin nur die zwölf oben gezeigten Datensätze.
Wo liegt nun das Problem? Natürlich an dem Ort, wo die Vorschlagswerte gespeichert sind – der T_FACT-Tabelle. Aber warum?
Mit etwas technischem Hintergrund gibt einem das Hybrid-Planungs-Log einen ersten Hinweis auf die Problematik. Das Log kann man mit folgendem Aufruf abfragen:
EXEC dbo.P_SYSLOG_WBLOG @LogLevel = 2
Der übergebene LogLevel-Parameter beeinflusst dabei die Detailtiefe, in der das Log angezeigt wird. Mit dem Wert 0 wird das Log verdichtet auf Transaktionsebene ausgeben, mit dem (Standard-)Wert 1 verdichtet auf Eingabeebene und mit 2 detailliert über alle Ebenen. Im Log fällt folgendes auf:
Abbildung 8: Hybrid-Planungs-Log
Im zweiten fehlerhaften Schreibvorgang ergeben die ermittelten Steuerkennzeichen ein inkonsistentes Bild. Der MeasureValueOld wird übergeben (die Zelle ist ja gefüllt), weshalb das Kennzeichen „TargetMeasureFilled“ korrekterweise als 1 ermittelt wird. Bei der anschließenden Prüfung der Daten in der Zieltabelle werden aber keine Datensätze gefunden. Das Flag „TargetRecordsExisting“ sowie der Zähler „RecCountExisting“ sind beide 0. Und genau hier kommt das Problem her. In der Rückschreibroutine wird der Pfad für existierende Werte eingeschlagen. Beim anschließenden Versuch den Datenraum zu laden, der nun verändert werden soll, werden keine Daten in der Rückschreibtabelle gefunden. Damit greift der Schreibversuch ins Leere.
Im ersten Vorgang wurde das Flag „TargetMeasureFilled“ als 0 erkannt (es war ja kein Wert vorhanden) und so ein anderer Pfad in der Rückschreibroutine eingeschlagen, der den Datenraum komplett neu erstellt.
Richtig
Wie schon erwähnt, ist es grundsätzlich richtig, die Daten zunächst in die „normale“ Faktentabelle (T_FACT) zu laden, da hier (im Gegensatz zu den Rückschreibtabellen) alle Fremdschlüssel ordentlich gesetzt sind. Für ein ordnungsgemäßes Funktionieren des Rückschreibens auch auf die Vorschlagswerte, sind diese allerdings nach dem Laden in die T_FACT-Tabelle noch in die T_WriteBackSQL zur transferieren. Dies muss aktuell manuell passieren, da es aufgrund der sehr individuellen Modellkonstellationen aktuell noch keinen Automatismus gibt.
Die zu erstellende Stored Procedure hat in der Regel folgenden Aufbau:
1) Löschen des Zielbereichs in der T_WriteBackSQL-Tabelle
2) Übertrag der Vorschlagswerte aus der T_FACT in die T_WriteBackSQL
3) Löschen der Vorschlagswerte aus der T_FACT-Tabelle
Der mit der meisten Vorsicht zu behandelnde Schritt ist das Löschen des Zielbereichs in der T_WriteBackSQL-Tabelle. In dieser stehen die Eingaben der Anwender, die stets das höchste Gut in einer Planungslösung sind. Wird hier falsch gelöscht, könnte das ungewünschte Folgen haben. Weiterhin ist mit dem Besitzer des Zielsystems zu klären, was passieren soll, wenn neue Vorschlagswerte geladen werden, wenn bereits Anwender Daten erfasst haben. Sollen die alten Daten gelöscht werden oder die Eingaben erhalten bleiben? Egal welche Variante gewünscht ist, in jedem Fall müssen die Daten, die gelöscht werden sollen über diverse Kriterien identifiziert werden. Hier bieten sich mehrere Varianten an. In der Regel kann man sich an den neu zur Verfügung gestellten Vorschlagsdaten orientieren. Mindestens die gelieferte Wertart, meist jedoch die Kombination aus Wertart, Zeit und (falls vorhanden) Planungszyklus und -version können im Ziel gelöscht werden. Wenn man nur über die Wertart geht, muss man sicher sein, dass keine historischen Planungsdaten in der Zieltabelle enthalten sind. Sollen veränderte Werte im Ziel erhalten bleiben, muss jeder geänderte Datensatz gekennzeichnet werden. Hier hat sich das Info-Feld „SourceID“ etabliert, welches automatisch in DeltaMaster ETL ergänzt wird, sobald eine MeasureGroup zum Planen aktiviert wird. Vorschlagswerte werden immer mit der SourceID = 3 geladen, von einem Anwender geänderte Werte erhalten die SourceID 4. Die vorbereiteten Ausprägungen sind in der Tabelle T_MODELSYS_WriteDataSource nachzulesen.
Ein exemplarisches Löschstatement für den genannten Schritt könnte folgendermaßen aussehen:
--Delete existing data in Writetables DELETE FROM wb FROM dbo.T_WriteBackSQL_FACT_01_SalesPlanning wb INNER JOIN dbo.T_FACT_01_SalesPlanning fact on wb.ValuetypeID = fact.ValuetypeID AND wb.PlanningCycleID = fact.PlanningCycleID AND wb.VersionID = fact.VersionID AND fact.ValuetypeID = 2 AND fact.SourceID = 3 --3 = Proposal value
Beim Übertrag der Daten aus der T_FACT in die T_WriteBackSQL ist lediglich darauf zu achten, dass man nur die geladenen Vorschlagswerte überträgt und nicht versehentlich alte Plan- oder Istwerte. Hier gilt ähnliches wie beim Löschen. Die Werte müssen über die richtigen Dimensionen identifiziert werden. Alternativ kann man sich auch hier gut mit einem Filter auf SourceID = 3 behelfen, da man davon ausgehen kann, dass außer dem aktuellen Lauf keine alten Vorschlagswerte in der Faktentabelle enthalten sind.
Auch hier ein Beispiel:
--Insert new proposal data to T_WriteBack_FACT INSERT INTO dbo.T_WriteBackSQL_FACT_01_SalesPlanning ( MonthID, PeriodViewID, CumulationID, ValuetypeID, PlanningCycleID, VersionID, EmployeeID, CustomerID, ProductID, Revenue, SourceID ) SELECT MonthID, PeriodViewID, CumulationID, ValuetypeID, PlanningCycleID, VersionID, EmployeeID, CustomerID, ProductID, Revenue, SourceID FROM dbo.T_FACT_01_SalesPlanning WHERE SourceID = 3
Schließlich müssen die Daten noch in der T_FACT-Tabelle aufgeräumt werden. Die Identifikation der korrekten Daten wird analog zu Schritt zwei vorgenommen:
--Delete data from T_FACT DELETE FROM dbo.T_FACT_01_SalesPlanning WHERE SourceID = 3
Ist die Prozedur erstellt, muss diese lediglich noch in die DeltaMaster-ETL-Routine „P_Transform_All“ eingebunden werden. Wichtig ist, dass dies nach dem Schritt „P_Transform_13_P_Facts_Ausfhren“ passiert, da erst dort die T_FACT-Inhalte geladen werden. Ab der ETL-Version 6.1.6 kann die TransferProzedur in die Standardroutine „P_Transform_99_PostProcess“ eingebunden werden, die am Ende des Transform All läuft.
Im Übrigen ist dieses Thema nicht nur für die Hybridplanung relevant. Auch in OLAP-Planungssystemen sollte man darauf achten, dass die Vorschlagswerte immer in die Planungstabelle übertragen werden. Dort könnte es sonst dazu kommen, dass bei erneutem Laden der Vorschlagswerte (nachdem bereits Anwender eingegeben haben) völlig neue Werte entstehen, die nie ein Anwender erfasst hat.
