Kleinere Modellanpassungen stehen für ein Data Warehouse in vielen Umgebungen an der Tagesordnung. Häufig geht es dabei um die Erweiterung von Attributen oder Kennzahlen in bestehenden Dimensions- und Faktentabellen. DeltaMaster ETL unterstützt die Architekten des Data Warehouse bei solchen Anpassungen, indem inkrementelle Modellaufbereitungen angeboten werden. Dabei wird manchmal mehr neu erstellt als notwendig wäre, da betroffene Datenbankobjekte samt aller Abhängigkeiten neu erzeugt werden. Dieser Beitrag stellt eine Anleitung für die zeitsparende Umsetzung von kleineren Modellanpassungen zur Verfügung.

Zunächst gehen wir für ein besseres Verständnis auf die verschiedenen Varianten der inkrementellen Modellaufbereitung mit DeltaMaster ETL ein, gefolgt von einer Anleitung für das Hinzufügen eines Attributs.

Inkrementelle Modellaufbereitungen mit DeltaMaster ETL

Um Modelländerungen inkrementell vornehmen zu können, merkt sich DeltaMaster ETL sämtliche Änderungen am Metamodell seit der letzten Modellaufbereitung. Im Bericht „Objects Affected by Next Incremental Run“ in der Analysesitzung „DeltaMaster ETL.das“ wird eine Übersicht der betroffenen Tabellen zur Verfügung gestellt. Es empfiehlt sich vor sämtlichen Meta­modell­änderungen, diesen Bericht zu prüfen. Gerade in Umgebungen mit mehreren Modellierenden kann es noch unverarbeitete Änderungen geben – diese sollten zunächst bereinigt werden und der Bericht leer sein. Wird nun anschließend die beabsichtigte Änderung durchgeführt, beispielsweise das Hinzufügen einer Kennzahl, so zeigt der Bericht ausschließlich die Tabelle an, die von der Änderung betroffen ist:

Abb. 1: Darstellung der betroffenen Objekte bei inkrementeller Modellaufbereitung

Um nun eine inkrementelle Modellaufbereitung durchzuführen, bietet DeltaMaster ETL drei verschiedene Varianten an:

Abb. 2: Alternativen für die inkrementelle Modellaufbereitung

Für kleinere Modellanpassungen ist die inkrementelle Aufbereitung inklusive Tabellen („Incremental mode: changed & dependant tables, all views & all procs“) in den meisten Fällen der Standard. Hierbei werden sowohl die betroffenen Tabellen im Data Mart (T_DIM_* und T_FACT_*) als auch die zugehörigen Befüllungs­prozeduren (P_DIM_* und P_FACT_*) neu erstellt sowie weitere virtuelle Objekte wie beispielsweise Views. Für den Anwender ist es hier nicht möglich, relevante Objekte für die Modellanpassung zu vergessen. Somit ist diese Methode der sicherste Weg der inkrementellen Modellaufbereitung. Gleichzeitig kann aber auch mehr neu erstellt werden als notwendig, was zu unnötigen Befüllungszeiten führt (dies wird im nächsten Abschnitt genauer erläutert).

Bei der Aufbereitung von virtuellen Objekten („Incremental mode: all views & all procs“) werden lediglich Sichten und Befüllungs­prozeduren neu erstellt. Diese Variante ist für Szenarios gedacht, in denen die Tabellen im Data Mart bereits die Struktur aufweisen, die im Metamodell definiert ist. Werden im Metamodell beispielsweise nur die Quellspalten für Dimensionen oder Faktentabellen geändert, hat dies keine Auswirkung auf die Zieltabellen im Data Mart – lediglich die Befüllungs­prozeduren benötigen eine Aktualisierung. Diese Methode kann auch nach manuellen Anpassungen in den Data-Mart-Tabellen verwendet werden, um die virtuellen Objekte anzugleichen.

Die dritte Möglichkeit ist die Simulation („Simulate: no changes in database objects“) – eine Auf­berei­tungs­variante, die zunächst wenig hilfreich für inkrementelle Änderungen zu sein scheint: Hierbei werden keinerlei Änderungen an Objekten in der Datenbank vorgenommen (mit Ausnahme der Erstellung von Synonymen). Im Hintergrund wird jedoch der komplette Quellcode für die Modellaufbereitung erzeugt – damit kann dieser als Vorlage für zielgerichtete Anpassungen verwendet werden. Diese Variante ist auch die Basis für den hier vorgestellten Ansatz.

Inkrementelle Erweiterung um ein Attribut

Ein häufiger Anwendungsfall für kleinere Modellanpassungen ist die Ergänzung von Attributen in vorhandenen Dimensionen. Dabei kann es sich um einfache Attribute zur Anzeige handeln (Elementeigenschaften) oder Attribute als Basis für zusätzliche Hierarchien in einer Dimension. In unserem Beispiel möchten wir die Kundendimension um die Information erweitern, ob ein Kunde eine neu eingeführte Kundenkarte besitzt oder nicht. Nach Hinzufügen des Attributs im Metamodell werden die Objekte, die von einer inkrementellen Verarbeitung betroffen sind, im eingangs beschriebenen Bericht angezeigt:

Abb. 3: Betroffene Objekte nach Erweiterung um ein Attribut

Es fällt auf, dass neben der angepassten Dimension auch sämtliche Faktentabellen, an denen die Dimension angebunden ist, von einer inkrementellen Modellaufbereitung betroffen sind. Das liegt an der Logik, mit der eine Anpassung auf der Datenbank erfolgt: Die Dimensionstabelle wird gelöscht und anschließend in geänderter Form neu erstellt. Aufgrund von potenziellen Auswirkungen der Änderung auf die Faktentabellen (z. B. eine Umbe­nennung der Ebene, die den Schlüssel der Dimension beinhaltet), werden auch die entsprechenden Faktentabellen sicherheitshalber neu erstellt. Als Konsequenz sind diese dann jedoch leer und müssen neu befüllt werden, was einige Zeit in Anspruch nehmen kann. Und das, obwohl es keine Änderungen an den Faktentabellen gibt – diese werden also identisch erneut erstellt. Um das zu umgehen, kann der angesprochene Modus „Simulate“ in DeltaMaster ETL verwendet werden.

Nach Hinzufügen des gewünschten Attributs muss hierfür in den „Create options“ der entsprechende Modus ausgewählt werden. Dabei ist darauf zu achten, dass lediglich der erste Schritt mit einem Haken ausgewählt ist:

Abb. 4: Auswahl der Aufbereitungsvariante „Simulate“

Die angezeigten Meldungen unterscheiden sich nicht von einer „tatsächlichen“ Modellaufbereitung, man erhält nach der Ausführung also die gewohnte Rückmeldung „Relational schema created successfully“. Im Hintergrund fügt DeltaMaster ETL sämtliche SQL-Befehle in die Tabelle „T_MODELSYS_CreateSnowflakeCode“ auf der Model-Datenbank ein, die für eine vollständige Erzeugung des relationalen Modells notwendig sind. Hierbei werden auch vergangene Erstellungsvorgänge protokolliert – der nun relevante Vorgang muss also erst eingeschränkt werden. Eine Abfrage, um an den Erstellungsbefehl für die angepasste Dimensionsebene zu gelangen, kann wie folgt aussehen:

SELECT
CSCmd --SQL-Befehl für die Erstellung der Tabelle
FROM dbo.T_MODELSYS_CreateSnowflakeCode
WHERE 1=1
AND CSID = (SELECT MAX(CSID) FROM dbo.T_MODELSYS_CreateSnowflakeCode) --Eingrenzung auf die zuletzt ausgeführte Modellaufbereitung
AND CSCmdType = 'CREATE' --Eingrenzung auf Befehle, die Objekte erstel-len
AND CSObjType = 'DIMLVL_TAB' --Eingrenzung auf Dimensionstabellen
AND CSObjName LIKE '%Kunde%' --Eingrenzung auf die Ebene der betroffenen Dimension

Der resultierende SQL-Befehl kann dann in ein neues Abfragefenster kopiert werden, um die Tabellendefinition zu erhalten:

Abb. 5: Generierter SQL-Befehl zur Erstellung der Dimensionstabelle

Das neu hinzugefügte Attribut ist in diesem Befehl erwartungsgemäß vorhanden (gelb markiert). Um nun ein Löschen der Dimensionstabelle zu vermeiden, verwenden wir die generierte Tabellendefinition, um einen ALTER-TABLE-Befehl zu erstellen (der beibehaltene Teil ist gelb markiert):

Abb. 6: Angepasster SQL-Befehl zum Ändern der bestehenden Dimensionstabelle

Bei einer Enterprise-Architektur ist dieser Befehl auf der Data-Mart-Datenbank auszuführen. Nach der Ausführung des Befehls hat die Dimensionstabelle grundsätzlich die korrekte Struktur, da die im Metamodell definierte Spalte für das neue Attribut jetzt vorhanden ist. Nun gilt es, auch die entsprechende Befüllungsprozedur sowie ggf. vorhandene Views zu aktualisieren. Dies übernimmt DeltaMaster ETL mit dem inkrementellen Aufbereitungsmodus „Incremental mode: all views & all procs“:

Abb. 7: Inkrementeller Modus für Views und Prozeduren

Ist dieser Schritt abgeschlossen, kann die Befüllungsprozedur die Dimensionsebene wieder korrekt mit Daten versorgen. Dies ist in Anbetracht des neuen Attributs auch notwendig: Es ist momentan zwar vorhanden, aber noch nicht befüllt. Auch hierbei greift uns DeltaMaster ETL unter die Arme. In der Model-Datenbank gilt es, die entsprechende Befüllungsprozedur zu bearbeiten. Darin befindet sich in der Regel ein auskommentierter Teil, der mit „Update from source table“ beginnt. Diesen Teil muss man nun markieren bis inklusive „OPTION (RECOMPILE)“ und ausführen.

Abb. 8: Beginn des UPDATE-Statements inkl. neuem Attribut

Mit dieser Aktualisierung werden sämtliche Attribute der Dimensionsebene aktualisiert, ergo auch das neu angelegte Attribut. Zuletzt muss die vorgenommene Änderung auch im Würfel angewendet werden. Hierfür verwenden wir die letzten beiden Aufbereitungsschritte aus DeltaMaster ETL:

Abb. 9: Anpassung der OLAP-Datenbank

Das neue Attribut ist anschließend im Modell vorhanden, ohne dass die Faktentabellen neu befüllt werden mussten, die von der Dimension abhängig sind.

Diskussion und Limitationen

Der vorgestellte Ansatz richtet sich an erfahrene Nutzer von DeltaMaster ETL, die gelegentliche Modellanpassungen selbst vornehmen. Die erforderlichen Berechtigungen auf den betroffenen Datenbanken haben wir daher als gegeben angenommen – sie sind jedoch eine Voraussetzung für die Durchführung dieser Schritte. Darüber hinaus gilt es, eine wichtige Eigenschaft der Auf­berei­tungs­variante „Simulate“ zu berücksichtigen: Wird diese ausgeführt, protokolliert DeltaMaster ETL das Modell als „verarbeitet“. Damit werden auch sämtliche Anpassungen im Metamodell seit der letzten tatsächlichen Aufbereitung vergessen. Sollte es bei den manuellen Anpassungen zu Fehlern kommen oder die Modellanpassung abgebrochen werden, ist anschließend keine klassische inkrementelle Verarbeitung mehr möglich. Dann muss der „Full Mode“ verwendet werden, um das Modell aufzubereiten. Neben dem Hinzufügen von Attributen kann auf diese Art und Weise grundsätzlich jede Anpassung des Modells vorgenommen werden. Im Fall von neuen Kennzahlen, die auch mit Werten gefüllt sein sollen, empfiehlt sich jedoch der inkrementelle Modus inklusive Tabellen, da hier ausschließlich die betroffenen Faktentabellen neu erstellt werden. Eine Möglichkeit zur komfortablen Befüllung der zuletzt neu erstellten Objekte bietet in diesem Fall der Bericht „Objects affected by Last Incremental Run“.

Ausblick: Möglichkeit der Automatisierung

Der vorgestellte Ansatz eignet sich nur bedingt für die Automatisierung, insbesondere durch die zielgerichtete Verwendung und Anpassung des generierten SQL-Befehls für die Dimensionsebene. Eine Variante, die deutlich leichter zu automatisieren ist, ist die Löschung und Neuerstellung von Fremdschlüsseln der Faktentabellen auf die betroffene Dimension. Allerdings versetzt diese Methode das Modell potenziell in einen inkonsistenten Zustand. In diesem Fall können die vollständigen SQL-Befehle zur Erstellung der Dimensionstabellen und -objekte verwendet werden, eine manuelle Anpassung ist nicht mehr erforderlich. Im Anschluss werden die entfernten Fremdschlüssel wiederhergestellt, um die Konsistenz des Modells weiterhin zu gewährleisten. Eine Prozedur, die diese Logik abbildet und damit Dimensionsanpassungen weiter beschleunigt, befindet sich derzeit in Entwicklung und ist im Fall von erfolgreichen Tests für den Standard von DeltaMaster ETL vorgesehen.