Wer kennt diese Situation nicht? In einem spannenden, iterativen Prozess hat man mit dem Kunden eine Dimension Measure Matrix erarbeitet und sich auf Dimensionen, Attribute, Hierarchien und Measure Groups verständigt. Mit dem guten Kumpel DeltaMaster ETL und standardisiertem Vorgehen beim Aufbau des relationalen Modells inklusive Schnittstellen, ist das Modell in kürzester Zeit erstellt und es geht an den Berichtsbau.

Im Bericht werden munter Attributshierarchien „kreuztabelliert“ und die ersten Berichte bringen schon wertvolle Erkenntnisse für die Fachabteilung.

Zusätzlich zu den Hierarchien sollen weitere Attribute, wie zum Bespiel Kundentypen, Orte etc. im Bericht dargestellt werden. Kurzer Einwurf des Kunden, ob man nicht die Bezeichnungen statt den Keys zu den Elementen anzeigen könnte.

Gemäß gängiger Lehrmeinung haben wir ja Schlüssel für den Aufbau der Attribute verwendet und keine Textfelder. Die Befüllung der Eigenschaften KEY und NAME in normalen Attributen geht nicht? Geht doch, kann DeltaMaster ETL schon sehr lange!

DeltaMaster ETL und die Attribute

Bei der Entwicklung von DeltaMaster ETL sind immer wieder Features und Funktionen eingebaut worden, die in der Hektik des Consulting Alltags nicht die gebührende Aufmerksamkeit bekommen haben. Zum besseren Verständnis holen wir etwas weiter aus, um die Funktion besser einordnen zu können.
Wir nehmen uns die bekannte Customer Dimension aus der ChairInternational als Beispiel und schauen uns zunächst die Definition der Levels an.

Abbildung 1: DeltaMaster ETL Levels

Zu den Leveln definieren wir die Quellen, aus denen sie befüllt werden. Jeder Level hat gemäß der Trennung in KEY und NAME Eigenschaft in SSAS, die entsprechenden Quellspalten.

Abbildung 2: DeltaMaster ETL Level source columns

Im Bericht Level Attributes werden unter anderem die Sortierung innerhalb der einzelnen Level und die optionale Erstellung von Hierarchien definiert. Weiterhin können hier zu bestehenden Leveln zusätzliche Attribute erstellt werden.

Abbildung 3: DeltaMaster ETL Level attributes

Diesen (neuen) Attributen müssen dann selbstverständlich noch fehlende Quellen zugeordnet werden.

Abbildung 4: DeltaMaster ETL Level attribute source columns

Der geneigte Leser hat sicherlich schon bemerkt, dass es ein zusätzliches Attribut CustomerType auf der Ebene Customer gibt, welches nicht in der Standardhierarchie als Level verwendet wird.

Bei diesen Attributen fehlt die Option, getrennte Spalten für KEY und NAME einzutragen. Als Source Column ist hier die Spalte „CustomerTypeName_EN“ angegeben.

Diesem Attribut wollen wir im folgendem trotzdem einen KEY zuordnen und im DeltaMaster den NAME zur Anzeige benutzen.

Wie man Attributen Bezeichnung und Keys beibringt

Damit kommen wir nun zu dem eigentlichen dafür zu verwendenden Feature, welches sich unter den etwas sperrigen Namen „Level attribute keys“ und „Level attribute key source columns“ im Ordner „Advanced modeling“ versteckt.

Abbildung 5: DeltaMaster ETL Advanced modeling

In diesem Bericht erscheinen die einzelnen für die Dimensionen definierten Levels und deren zugeordnete Attribute. Die Spalten „Dimension“, „Level“, „Attribute“, „Type of attr. NAME“ und „Default value for attr. NAME“ sind vorbefüllt mit den Inhalten aus dem Bericht „Level attributes“.

Abbildung 6: DeltaMaster ETL Level attribute keys

Über die Spalte „Type of attr. KEY“ wird definiert, dass dieses Attribut eine „Sonderbehandlung“ bekommen soll. Da wir hier einen Schlüssel definieren wollen, wird der Typ Integer empfohlen.

Durch den Eintrag in dieser Spalte erscheint die Zeile in dem nachfolgenden Bericht.

Abbildung 7: DeltaMaster ETL Level attribute key source columns

Nun kann hier schließlich für das Attribut auch das KEY Feld mit der Spalte „CustomerTypeID“ befüllt werden. Die Modellierung ist damit robust, performant und lehrbuchmäßig über das KEY Feld erfolgt.

Die Darstellung im DeltaMaster in den Dialogen erfolgt hingegen über die NAME Eigenschaft.
Abbildung 8: DeltaMaster Attributs Auswahl

Abbildung 9: DeltaMaster Attributs Darstellung

Da bekanntlich immer mehrere Wege nach Rom führen, hätte man diese Anforderung auch alternativ über Attribute Relations lösen können. Es müssten dann allerdings zwei Attribute angelegt werden, eines mit KEY eines mit NAME. Dann muss im NAME noch eine Attribute Relation auf KEY definiert werden. Welches Vorgehen eleganter oder einfacher ist, bleibt der eigenen Phantasie überlassen.

Damit sind wir am Ende des heutigen Artikels angelangt. Ich hoffe, dass dieses relativ unbekannte Feature für den einen oder anderen Anwendungsfall nützlich ist.