Wir stellen uns folgende Situation vor: Ihre Kollegen erfassen in der üblichen Hektik ihre Plandaten in DeltaMaster, der Abgabetermin rückt immer näher und die Zeit wird langsam knapp. Jetzt tritt die vollkommen unwahrscheinliche Situation ein, dass der Controlling-Leiter plötzlich noch eine neue Kennzahl im OLAP-Würfel benötigt. Sie pflegen also in DeltaMaster Modeler die neue Kennzahl ein, erstellen das Snowflake-Schema und den Würfel neu und schwups sind alle Plandaten weg… Klingt nicht gut, oder?

Aus dem Grund haben wir in DeltaMaster Modeler eine Logik eingebaut, die sich um das Retten der bestehenden Daten kümmert. Und nicht nur das. Er macht sogar einen Vorschlag für die Restauration der gesicherten Daten in die neuen Rückschreibetabellen, so dass Sie ohne großen Aufwand wieder Ihre Daten in die neue Struktur integrieren können. Wie das geht lesen Sie im folgenden Artikel.

Was muss gesichert werden?

Seit der Version 209 unterstützt uns DeltaMaster Modeler auch vorzüglich in der Erstellung von Planungsapplikationen. Er legt die Rückschreibetabellen an und erzeugt sogar den für den SQL Server 2005 so dringend notwendigen Rückverdichtungsprozess. Beide Objekte kann man getrennt voneinander aktivieren. Wird nur das Rückschreiben aktiviert, legt Modeler jeweils nur eine Tabelle nach dem Schema „T_WriteTable_…“ an. Ist die Rückverdichtung auch aktiv, werden zusätzlich noch die Tabellen „T_WriteBack_…“ und „T_WriteTable_…_Archiv“ angelegt. In jeder Tabelle sind bei einer aktiven Planung irgendwann Werte enthalten, die es zu retten gilt. Vereinfachend nehmen wir für den restlichen Artikel an, dass nur das Rückschreiben aktiv ist und nur eine Tabelle berücksichtigt werden muss. Für die beiden anderen Tabellen würde ohnehin die identische Logik angewendet werden.

Die Sicherungslogik

Wird das Snowflake-Schema neu erstellt, werden normalerweise alle Tabellen gelöscht und neu generiert. Bei den Rückschreibtabellen darf genau das nicht passieren. Die Sicherungslogik ist dabei ganz einfach. Zu Beginn prüft Modeler, ob die Rückschreibtabelle Daten enthält. Ist die Tabelle leer, wird sie wie alle anderen auch gelöscht und neu erstellt. Ist sie befüllt, legt Modeler zwei neue Objekte an. Eine Sicherungstabelle „_BACKUP_T_WriteTable_…“, welche alle Daten enthält, sowie einen Prozess „_P_RESTORE_T_Writetable_…“, um die gesicherten Daten wieder in die neue Rückschreibtabelle zu überführen. Nach erfolgreichem Backup wird die Originaltabelle gelöscht und neu erstellt. Anschließend prüft Modeler, ob es in der neuen Tabelle eine relevante Strukturänderung gab. Als relevante Strukturänderung wird dabei das Umbenennen von Ebenen oder Kennzahlen sowie das Entfernen von Dimensionen oder Kennzahlen aus der MeasureGroup betrachtet. Gab es keine relevante Strukturänderung, führt Modeler eine vollautomatische Restaurierung der Plandaten durch und entfernt nach erfolgreicher Durchführung die Sicherungstabelle sowie den Restaurierungsprozess. Das heißt, dass selbst das Hinzufügen einer neuen Kennzahl keine manuelle Aktion erfordert und vollautomatisch behandelt wird, obwohl die internen Spaltennamen der Rückschreibtabelle sich verändert haben (z.B. neu: Periode_2 / alt: Periode_1)!

Nur im Falle einer relevanten Strukturänderung wird eine Fehlermeldung in der Oberfläche ausgegeben und eine manuelle Aktion seitens des Administrators wird notwendig. Was zu tun ist, wird im weiteren Artikel beschrieben. Nachfolgende Grafik veranschaulicht noch einmal die gesamte Prozesslogik:

Manuelle Rücksicherung

Wird eine Spalte aus der Schreibtabelle gelöscht oder umbenannt, kann nicht automatisch entschieden werden, was mit den bestehenden Inhalten geschehen soll. Daher wird an der Stelle der Faktor Mensch notwendig, welcher die Entscheidung selbst treffen muss. Sehen wir uns einen solchen Fall an.

Wir starten mit einer Rückschreibtabelle „T_WriteTable_Planeingaben“, in der Daten enthalten sind:

Zum Testen führen wir zunächst eine nicht relevante Strukturänderung durch und legen in Modeler die neue Kennzahl „Absatz“ an. Anschließend lassen wir das Snowflake-Schema neu erzeugen. Die Datensätze der Tabelle werden automatisch rückgesichert. Die Tabelle sieht nun wie folgt aus:

Auch wenn dies in der DeltaMaster-Oberfläche problemlos möglich wäre, übersetzen wir nun unsere Kennzahlen ins Englische und Löschen die Kennzahl Absatz wieder. Damit erzeugen wir zwei relevante Strukturänderungen. Modeler kann nun nicht mehr wissen, dass die Kennzahl „Umsatz“ nun „Revenue“ heißt und was mit den alten Inhalten der Absatz-Spalte passieren soll. Somit kann er die Rücksicherung nicht mehr automatisch durchführen. Folgende Fehlermeldung wird beim Erzeugen des Snowflake-Schemas ausgegeben:

Freundlicherweise gibt uns unser Kumpel Modeler in der Fehlermeldung bereits alle Informationen, die wir benötigen. Der Name der gesicherten Tabelle sowie der Name der Prozedur zum Wiederherstellen werden genannt. Ein lästiges Suchen entfällt. Durch den Präfix “_” sind die Objekte weiterhin ganz oben in der SQL-Server-Objektliste zu finden.

Die gesicherte Backup-Tabelle sieht inhaltlich und strukturell so aus wie die Originaltabelle. Da diese bereits weiter oben dargestellt ist, müssen wir sie nicht mehr weiter betrachten. Spannender ist die generierte Prozedur:

ALTER PROCEDURE [dbo].[_P_RESTORE_WriteTable_Planeingaben] as
--RESTORE TABLE Test.dbo.T_WriteTable_Planeingaben FROM _BACKUP TABLE
--Restore records from backup

INSERT INTO Test.dbo.T_WriteTable_Planeingaben
(
--Revenue_0,
MonatID_1
,WertartID_2
,Test_1ID_3
,MS_AUDIT_TIME_4
,MS_AUDIT_USER_5
)
SELECT
--Umsatz_0,
--Absatz_1,
MonatID_2
,WertartID_3
,Test_1ID_4
,MS_AUDIT_TIME_5
,MS_AUDIT_USER_6
--select *
FROM
Test.dbo._BACKUP_T_WriteTable_Planeingaben

--Check target entries
--SELECT * FROM Test.dbo.T_WriteTable_Planeingaben

--Drop Backup table
IF @@error = 0
BEGIN
DROP TABLE Test.dbo._BACKUP_T_WriteTable_Planeingaben
END

Die Prozedur liefert bereits vorkonfektioniert das INSERT-Statement, um die Daten aus der Backup-Tabelle in die neue Schreibtabelle zu überführen. Dabei ordnet Modeler anhand des echten Namens (ohne den laufenden Index) die Spalten der beiden Tabellen einander zu. Aber nicht nur das. Er nennt außerdem auskommentiert die Namen der nicht zuordenbaren Spalten in der richtigen Reihenfolge. Von daher reicht ein einfaches Entfernen der Kommentierung aus, um alle Inhalte wiederherstellen zu können. Eine mühsame Suche nach Spaltennamen in Quell- und Zieltabelle entfällt. Obendrein wird bereits auskommentiert ein SELECT-Statement erzeugt, um das Ergebnis zu überprüfen. Das notwendige DROP-Statement um die Backup-Tabelle im Erfolgsfall wieder aufzuräumen, ist ebenfalls enthalten.

In unserem Beispiel würde man also einfach die beiden Umsatz-Spalten wieder aktivieren und dann die Prozedur schrittweise ausführen:

ALTER PROCEDURE [dbo].[_P_RESTORE_WriteTable_Planeingaben] as
--RESTORE TABLE Test.dbo.T_WriteTable_Planeingaben FROM _BACKUP TABLE
--Restore records from backup

INSERT INTO Test.dbo.T_WriteTable_Planeingaben
(
Revenue_0, --<<-- ANPASSUNG
MonatID_1
,WertartID_2
,Test_1ID_3
,MS_AUDIT_TIME_4
,MS_AUDIT_USER_5
)
SELECT
Umsatz_0, --<<-- ANPASSUNG
--Absatz_1,
MonatID_2
,WertartID_3
,Test_1ID_4
,MS_AUDIT_TIME_5
,MS_AUDIT_USER_6
--select *
FROM
Test.dbo._BACKUP_T_WriteTable_Planeingaben

--Check target entries
--SELECT * FROM Test.dbo.T_WriteTable_Planeingaben

--Drop Backup table
IF @@error = 0
BEGIN
DROP TABLE Test.dbo._BACKUP_T_WriteTable_Planeingaben
END

Restore vergessen, und jetzt?

Das oben beschriebene Vorgehen beschreibt den Optimalfall. Jetzt kann es natürlich mal passieren, dass der manuelle Eingriff vergessen wird und die Backup-Tabelle nicht wiederhergestellt wird. Werden in der Zwischenzeit keine Daten mehr erfasst, ist das unproblematisch. In dem Fall wird beim Neuerzeugen des Snowflake-Schemas die oben gezeigten Fehlermeldung erneut ausgegeben und man kann jederzeit die Wiederherstellung manuell durchführen.

Problematischer stellt sich die Situation dar, wenn mittlerweile neue Daten erfasst wurden. In dem Fall enthält die Backup-Tabelle Daten zum Restaurieren und die Rückschreibtabelle enthält Daten, die nicht gelöscht werden dürfen und gesichert werden müssten. Damit beißt sich die Katze in den Schwanz. Doch unser treuer Gefährte hat auch dies bedacht und beschwert sich (zu Recht) beim Modellierer mit einer neuen Fehlermeldung:

Wenn diese Meldung erscheint, fasst Modeler die beiden Tabellen nicht an und sorgt dafür, dass keine Daten verloren gehen. Um sich aus dieser Zwickmühle zu befreien, muss man zunächst die oben beschriebene, manuelle Wiederherstellung der gesichert Daten in die Rückschreibtabelle durchführen und die Backup-Tabelle löschen. Anschließend kann das Snowflake-Schema neu erzeugt werden. Je nachdem was im Modell geändert wurde, kann es nun selbstverständlich sein, dass eine erneute manuelle Wiederherstellung notwendig ist, die Fehlermeldung bezüglich der noch existierenden Backup-Tabelle sollte nun allerdings verschwunden sein.

Und damit schließt ein erneutes Kapitel aus der Reihe: „DeltaMaster Modeler“ oder „Das Leben wie es sein sollte“.