Inkrementelles Löschen – Vanilla Style

Der DeltaMaster Modeler 213 bietet weitreichende Unterstützung für inkrementelle Befüllungsszenarien. Neben der im Blogbeitrag erwähnten Möglichkeit, das Snowflake-Schema inkrementell zu erzeugen, ist noch ein weiteres wertvolles Feature hinzugekommen, was eine Lücke in dem skizzierten Ladeprozess schließt: das inkrementelle Löschen von Daten. Wie diese neue Funktion konfiguriert wird, ist Thema dieses Blogbeitrags.

Was ist inkrementelles Löschen und warum?

Wer den Blogbeitrag „Inkrementelles Laden – Vanilla Style“ aufmerksam studiert hat, wird bemerkt haben, dass eine entscheidende Lücke beim inkrementellen Befüllen noch offen ist. Wir bekommen zwar Teile an Daten in die Faktentabelle geladen, aber gelöscht wird entweder die gesamte Faktentabelle oder gar nichts. Damit können nur sehr einfache Szenarien vollautomatisch unterstützt werden. Zum Beispiel wenn jeden Tag die Tagesabschlussdaten des Vortages „dazugeladen“ werden sollen. Was aber, wenn in der Datenlieferung des Vortages fehlerhafte Daten enthalten waren? Oder was, wenn die Zieltabelle die Daten nicht auf Tagesebene, sondern auf Monatsebene hält? In beiden Fällen müssten die Daten der Faktentabelle irgendwie durch neue Daten ersetzt werden. Das Neuladen der Daten war nicht das Problem, das vorherige partielle Löschen der Zieltabelle basierend auf den Quelldaten musste im Projekt allerdings individuell umgesetzt werden (Schritt 1 in nachfolgender Grafik):

Abbildung 1: Datenbasiertes inkrementelles Löschen

Da diese Fälle des „Nachladens“ relativ häufig in der Praxis vorkommen, kann uns der Modeler auch hier komfortabel unterstützen.
Warum kompliziert wenn’s auch einfach geht – die Modeler-Basiskonfiguration
Nach ein wenig rhythmischem Nachdenken kam ein ziemlich einfacher Lösungsansatz heraus, der mit lediglich vier Konfigurationsspalten auskommt:

Abbildung 2: Bericht “Meas.grp. incremental deletion”

Die meisten Informationen sind nämlich im Metamodell des Modelers bereits vorhanden. Aus dem Bericht „Meas.grp. dimensions“ wissen wir bereits an welche Dimensionen eine MeasureGroup ange-bunden ist. Eigentlich müssen wir nur noch wissen über welche Spalten das Löschen stattfinden soll. Dies sind in der Regel nicht alle Spalten aus denen eine MeasureGroup zusammengesetzt ist. Da sich die Löschlogik weiterhin pro SourceTable unterscheiden kann, ist die Wahl auf einen neuen Bericht gefallen (im Gegensatz zu einer Erweiterung des Berichts „Meas.grp. dimensions“). Dort trägt man einfach für eine MeasureGroup und eine SourceTable die Dimensionen ein, über die künftig gelöscht werden soll. Sprich, der Modeler schaut genau für die konfigurierten Spalten in die SourceTable und löscht die gelieferten Inhalte in der (Ziel-)Faktentabelle.
Zur besseren Verständlichkeit ein Beispiel: Angenommen wir bekommen in unserer Importtabelle jeden Tag die Ist-Daten des letzten abgeschlossenen Tages geliefert. In unserer Zieltabelle liegen die Daten auf Tagesebene vor und es sind Ist- und Plandaten enthalten. Dann würde folgende Konfiguration die Aufgabe erledigen:

Abbildung 3: Einfache Konfiguration für das inkrementelle Löschen

Bei der Ausführung des Create-Snowflake-Prozesses wird anschließend eine Prozedur in dem neuen Namensraum P_INCRDEL_… erstellt. Diese ist ab der Version 213 in den Standard-Transform-All-Prozess eingebunden und wird bei jedem Lauf mit ausgeführt. Die Prozeduren sind recht kompakt. Bei oben gezeigtem Beispiel wird folgende Prozedur erzeugt:

Abbildung 4: Erzeugte P_INCRDEL-Prozedur

Zunächst werden die unterschiedlichen Kombinationen aus Wertart und Periode aus der Quelltabelle ermittelt, in einer temporäreren Tabelle zwischengespeichert und anschließend die Fakten in der Zielta-belle auf dieser Basis gelöscht.
Damit bekommen wir das oben zuerst beschriebene Szenario wunderbar automatisiert. Was aber wenn die Zieltabelle nicht auf Tagesebene sondern auf Monatsebene aufgebaut ist, wir jedoch trotzdem täg-lich die Daten des Vortages bekommen?

Einfach kann auch kompliziert – Löschen über Nicht-Dimensionsfelder

Anstatt nun die Möglichkeit in der GUI zu bieten, den Code mit individuellen SQL-Freitextfeldern zu er-weitern oder eine Schnittstelle zu individuellem SQL-Code einzubauen, hat uns Modeler einen viel einfa-cheren Weg offenbart. Zusätzlich zu den Dimensionsfeldern bieten wir im Konfigurationsbericht auch noch Infofelder als Löschkriterium an. Wer eben aufgepasst hat, hat bestimmt bemerkt, dass die Spalte „Del. field Type“ bei der Erklärung übersprungen wurde. Hier gibt es zwei Optionen „Dim“ und „Info“. Das bedeutet, man kann wählen, ob man über eine Dimensionsspalte oder eine Infospalte löschen möchte. In Abhängigkeit der Typauswahl bietet dann die letzte Spalte „Del. field“ die zur MeasureGroup gehörigen Dimensionen oder die Infofelder an.
In unserem Beispiel müssen wir uns also lediglich ein neues Infofeld an der Faktentabelle anlegen, in dem wir den Monat hinterlegen und dieses anschließend in dem Bericht für das inkrementelle Löschen verwenden. Den Monat könnte man beispielsweise so hinterlegen:

Abbildung 5: Neues Infofeld “Monat” als Vorbereitung für das inkr. Löschen

Im Bericht „Meas.grp. incremental deletion“ stellen wir nun einfach von dem Feld Dim – Periode auf Info – Monat um:

Abbildung 6: Inkr. Löschen nach Infofeld “Monat”

Schauen wir uns nun das Ergebnis in der Prozedur an, sehen wir eine Übersetzung unserer ausschwei-fenden Phantasie in blitzsauberem T-SQL-Code:

Abbildung 7: Erzeugte P_INCRDEL-Prozedur bei Löschen über Infofeld