Wo gehören Vorschlagswerte hin? Richtiger Import von Vorschlagswerten in Hybrid-Planungssysteme

PDF Download
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 & 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.

1 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. In Delta-Hybrid-Lösungen gibt es 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?

2 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 habe ich 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 daneben 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.

3 Richtig

Wie schon geschrieben 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. Hier stehen die Eingaben der Anwender drin, 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 drauf 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.

4 Ausblick

Leider ist dieser Standardprozess noch nicht so automatisiert wie er sein könnte. Hier werde ich in Zukunft aber mal ein ernstes Wörtchen mit dem DeltaMaster-ETL-Produktmanager reden. Vielleicht kann ich ihn von einer Erweiterung überzeugen?!

Zum einen könnte eine Fehlerprüfung ergänzt werden, die den o. g. Fall abfängt und eine entsprechende Meldung ausgibt, sodass sich der Datenbankentwickler direkt selbst helfen kann.

Außerdem könnte solch eine Routine auch automatisch aus DeltaMaster ETL heraus erstellt werden. Hier ist lediglich die Frage, wie genau entschieden werden kann, über welche Dimensionen die Zieltabelle gelöscht werden soll. Zudem ist dies ein sehr heikler Prozessschritt. Aber es muss ja nicht immer einfach sein, wir können schließlich auch komplex. In dem Sinne, frohes Planen.

Schreibe einen Kommentar