Ab der kommenden DeltaMaster ETL Version wird es möglich sein, Dimension, Cube und/oder Measure Groups wahlweise zu deaktivieren. Diese werden dann bei den folgenden Modellaufbauschritten nicht berücksichtigt, obwohl die Objektdefinition weiterhin vorliegt. Die Einsatzmöglichkeiten der neuen Funktion und die zu berücksichtigenden Aspekte sind Bestandteil des vorliegenden Blogbeitrags.

Wo finde ich die Funktion?

Wie bereits erwähnt, ist die Funktion in der aktuellen DeltaMaster ETL Version noch nicht enthalten und wird planmäßig mit dem Release 6.2.5 ausgerollt. Deshalb könnte es sein, dass beschriebene Optionen nicht in der aktuellen Anwendung enthalten sind.

Künftig wird es vier Stellen geben, an denen Modellobjekte deaktiviert werden können – Dimensionen, Role-Playing Dimensionen, Cubes und Measure Groups:

Jedes Objekt kann für sich deaktiviert werden, wirkt aber auch auf die darunterliegenden Objekte. Sprich, wenn ein Cube deaktiviert wird, sind automatisch auch alle enthaltenen Measure Groups deaktiviert. Selbiges gilt für die Role-Playing Dimensionen, welche automatisch deaktiviert werden, wenn die zugrundeliegende Dimension deaktiviert wird.

Objekte können in beliebigen Kombinationen deaktiviert werden, so können beispielsweise auch gleichzeitig Dimensionen und Measure Groups deaktiviert werden.

Nach dem Update auf die neue ETL-Version sind alle Objekte (wie bisher) aktiviert.

Was bewirkt die Funktion?

Wie bereits einleitend erwähnt, werden deaktivierte Objekte im Modellaufbauprozess nicht berücksichtigt. Das betrifft alle Schritte des Modellaufbaus, sprich “Create relational schema”, “Fill relational schema” sowie “Create OLAP database” (und in der Folge auch “Fill OLAP database”). Im Ergebnis sieht es so aus, als wäre das Modell ohne das deaktivierte Objekt erstellt worden.

Sehen wir uns ein Extrembeispiel an, in dem wir die Periode deaktivieren:

Alle anderen Modellkonfigurationen bleiben auch nach der Deaktivierung erhalten:

Baut man nun das Modell vollständig auf, funktioniert dies (natürlich) ohne Probleme:

Wirft man nun einen Blick in die relationale und die OLAP-Datenbank, stellt man fest, dass trotz vorhandener Modelldefinitionen die Perioden-Dimension komplett außen vor ist.

Die Tabellen der Dimensionsebenen werden nicht erstellt und die Spalten werden aus den Faktentabellen herausgelassen:

Die Befüllungsroutinen werden für die Periode nicht erstellt:

In der Fakten-Befüllungsroutine wird die Periode ebenfalls ignoriert:

Außerdem wird die Dimension erwartungsgemäß in der OLAP-Datenbank nicht berücksichtigt:

Q.E.D – Blogbeitrag fertig!

…Nicht ganz. Zunächst stellen wir fest, dass das neue Feature tut was es soll, wenn das Modell komplett aufgebaut wird. Aktiviert man das Objekt vor dem nächsten Aufbau wieder, wird es wie gewohnt mit aufgebaut.

Wir wären aber nicht das ETL-Team, wenn wir nicht noch einen Schritt weitergedacht hätten. Das Feature lässt sich sogar live benutzen. Das bedeutet, dass man ein Objekt deaktivieren kann und es bereits bei der nächsten Befüllung des Modells im Schritt “Fill relational schema” wirkt – ohne, dass man die relationalen Objekte neu erzeugt. Wie das genau geht und was zu beachten ist, ist im nächsten Abschnitt zu lesen.

Deaktivierung ohne “Create relational schema”

Schauen wir uns zunächst an, was passiert, wenn wir die Dimension deaktivieren und anschließend das Modell nur neu befüllen (nicht neu erzeugen):

Was zunächst auffällt ist, dass die Befüllungsroutinen trotz Deaktivierung weiterhin im Log auftauchen. Dies ist korrekt und durchaus beabsichtigt. Warum das so ist, kann ein Vorher-Nachher-Vergleich der befüllten Faktentabelle erklären. Nach einer Befüllung mit aktivierter Dimension sieht die Faktentabelle folgendermaßen aus:

Die Daten werden auf die “korrekten” Tage aus der Quelltabelle geschrieben.

Nach der Deaktivierung der Dimension werden die Daten immer noch geladen, allerdings werden alle Datensätze auf das Dummy-Element der deaktivierten Dimension umgeleitet:

Damit dies funktioniert, ist natürlich die oben entdeckte Ausführung der Dimensionsprozeduren notwendig. Hier wird im Falle einer deaktivierten Dimension allerdings nur das Default-Element eingefügt (sofern noch nicht vorhanden), die restlichen Elemente werden nicht geladen. Dafür sorgt ein neuer IF-Block in den entsprechenden P_DIM-Routinen:

Dies funktioniert natürlich nur, wenn für die Dimension auch das Einfügen der Default-Elemente aktiviert ist (Bericht “Level Source Columns”, Spalte “Insert Default Value”).

Der zweite Teil der “Magie” liegt in den P_FACT-Routinen. Hier müssen die Daten im Falle einer Deaktivierung immer auf das Default-Element umgeleitet werden. Dafür müssen zwei Dinge passieren. Es muss (live) geprüft werden, ob eine Dimension aktiv oder inaktiv ist und dann an der entsprechenden Stelle statt dem “echten” Element das Default-Element verwendet werden. Die entsprechenden Code-Blöcke sind hier exemplarisch zu sehen:

Diese Logik der “Umleitung” wird nur für Dimensionen erstellt, welche das Einfügen des Default-Elements aktiviert haben. In unserem Beispiel ist dies nur bei der Periode der Fall.

WICHTIG:

Diese neue Logik innerhalb der P_FACT-Routinen kann per Parameter ein- und ausgeschaltet werden. Der Parameter befindet sich im Block “Relational Object Creation Parameters”:

Aufgrund möglicher negativer Performance-Einflüsse wird diese Logik nur bei neuen Modellen standardmäßig aktiviert. In allen Bestandsmodellen bleibt die Logik ausgeschaltet, so dass die Faktenroutinen wie bisher aufgebaut werden. Sollte die hier beschriebene “Live-Deaktivierung” von Dimensionen dennoch gewünscht werden, muss der Parameter manuell aktiviert und die Befüllungsroutinen per “Create relational schema” neu erzeugt werden.

Für die Fakten funktioniert die “Live-Deaktivierung” hingegen immer. Hier wird sowohl in den P_FACT-Routinen selbst, als auch in der Iteration des Schritts “Fill relational schema” geprüft, ob die jeweilige Measure Group aktiv ist. Nach einer Deaktivierung taucht der Schritt, anders als bei den Dimensionen, auch nicht mehr im Log auf.

Wofür braucht man das?

Die ursprüngliche Idee zu der Funktion kam aus der Ecke der Content Packages. Also der Möglichkeit, Standardmodelle und -content auszuliefern. Hier weiß man nie, welche Kriterien für einen Kunden relevant sind und welche nicht. Bisher konnte man die fraglichen Objekte entweder ganz weglassen, wobei es ärgerlich war, wenn man dieses dann später im Projekt doch gebraucht hat und die Modellierung manuell nachziehen musste. Alternativ konnte man einfach alle eventuell notwendigen Objekte einschließen. Das Ergebnis war jedoch ein sehr großes und unübersichtliches Modell mit teilweise unnötigen Objekten. Mit der Möglichkeit der Aktivierung kann man nun Standardcontent sauber definieren und ausliefern und alle fragwürdigen Objekte erstmal deaktivieren. Bei Bedarf können diese dann einfach später aktiviert werden.

Doch auch weitere Einsatzszenarien sind möglich. Wenn beispielsweise eine umfangreiche Dimension beim Neubau eines Modells größere Probleme bereitet, muss man künftig die Dimension nicht mit all ihren Elementen komplett löschen, sondern kann sie einfach vorübergehend deaktivieren. Gerade in hektischen Workshop-Situationen ein unschätzbarer Vorteil, um den Kollegen nicht bei der Arbeit oder der Präsentation zu behindern.

Durch die “Live-Deaktivierung” kann das Feature aber letztlich auch im Rahmen der Betriebsunterstützung verwendet werden, wenn beispielsweise aufgrund von Fremdschlüsselverletzungen der nächtliche Ladeprozess auf die Bretter gegangen ist. Durch Deaktivierung der Dimension kann man das System sehr schnell wieder verfügbar machen und den Fehler parallel beheben. Die betroffene Dimension hat zwar zu dem Zeitpunkt dann alle Daten nur auf dem Dummy-Element, aber wenn diese nicht gar so wichtig ist, ist das ggfs. für den Zeitraum der Fehlerbehebung vertretbar.

Von daher hoffen wir auch damit mal wieder einen wertvollen Beitrag zur Erleichterung des Projektalltags geleistet zu haben.