Das Problem begegnet uns immer dann, wenn in der Datenbank Werte in einer anderen Granularität gespeichert werden (in diesem Fall monatsgenau) als diese von der darauf aufsetzenden Anwendung geliefert werden (diese erlaubt nur jahresgenaue Werte). Für spätere Auswertungen oder Änderungen möchten wir monatsgenaue Werte speichern, ohne den korrekten Jahreswert (die Summe der 12 Monate) zu verlieren.

Auch hier führen wieder viele Wege nach Rom, daher zeige ich im ersten Teil neben der eigentlichen Problemstellung und dem Kern der Lösung eine von vier (!) Möglichkeiten die ich gefunden habe um die Aufgabe zu lösen.

Zunächst einmal überlege ich mir geeignete Ausdrücke um die oben genannte Anforderung innerhalb eines SSIS-Datenfluss’ umsetzen zu können. Für die Monate 1 bis 11 genügt folgender Ausdruck:

(DT_NUMERIC,6,2)(Value / 12)

Der Monat 12 erfordert eine Sonderbehandlung, welche durch folgenden Ausdruck gewährleistet wird:

(DT_NUMERIC,6,2)(Value – (DT_NUMERIC,6,2)(11 * (DT_NUMERIC,6,2)(Value / 12)))

Im Grunde ermittelt dieser Ausdruck die Differenz zwischen dem Jahreswert und der Summe der 11 Monatswerte um den Wert für Monat 12 zu berechnen. Beachten Sie dabei, dass es egal ist ob bei der Ermittlung der Monatswerte ab- oder aufgerundet oder gar abgeschnitten wird (was hier der Fall ist), der Wert für Monat 12 wird stets korrekt ermittelt.

Einer der naheliegendsten Wege um diese Logik umzusetzen ist die Nutzung eines Cross Joins zwischen dem Jahreswert und 12 Monaten. Damit wird der Jahreswert von einer Zeile auf 12 Zeilen verteilt. Anschließend kann in einem “Abgeleitete Spalte”-Task der Wert mit Hilfe der oben beschriebenen Ausdrücke manipuliert werden.

Folgender Screenshot zeigt den Datenfluss und zwei Data Viewer: einen nach dem Cross Join und einem nach dem Anwenden der Ausdrücke. Beachten Sie, dass sich der Wert für Monat 12 von allen anderen unterscheidet um einen korrekten Jahreswert zu gewährleisten.

Im zweiten Teil zeige ich drei (!) weitere Vorgehensweisen, sowie die Ergebnisse eines Performancetests um zu ermitteln, wie sich die unterschiedlichen Wege im produktiven Einsatz bewähren könnten.

Aber beginnen wir von vorne: immer wenn die Bearbeitung mehrere gleichartiger Dateien mittels SSIS gefragt ist, kommt früher oder später der ForEach-Loop-Container zum Einsatz. Damit lässt sich z.B. recht komfortabel über Dateien mit einer bestimmten Namensstruktur innerhalb eines Ordners iterieren. So könnte ein mögliches Importszenario vorsehen, dass mehrere Exceldateien in einem Ordner ausgelesen werden sollen – den ForEach-Loop-Container könnte man dann wie folgt konfigurieren:

Soweit so gut, der Rest des Paketes könnte dann wie folgt aussehen. Innerhalb des Loops wird eine Variable mit dem aktuellen Dateipfad ausgelesen um alle gefundenen Dateien nach Beendigung des Containers in einer MessageBox anzuzeigen:



Ich habe bisher den Inhalt des betroffenen Ordners unterschlagen, hier ist er:



Und siehe da: unser Paket findet zwei Exceldateien – wunderbar! Oder doch nicht? Störend an dieser Stelle könnte die Excel-Datei sein, die im neuen 2007er Format gespeichert wurde. Diese hat die Endung .xlsx! Eigentlich ganz praktisch, denn die beiden Exceltypen unterscheiden sich grundlegend und erfordern ggf. eine differenzierte Behandlung innerhalb der SSIS. Weitere prüfende Blicke in die Konfiguration des ForEach-Loops lassen letztlich nur einen Schluss zu: egal wie man es dreht und wendet, der Ausdruck im “Files”-Feld des Editors lässt sich nicht dahingehend ändern dass er nur .xls Dateien erwischt (was man eigentlich erwarten würde) – der Ausdruck verhält sich also wie *.xls*!

An dieser Stelle wirken die Books Online einmal mehr erhellend und decken auf, dass es sich quasi um erwünschtes Verhalten handelt – der Ausdruck verhält sich nämlich wie beim dir-Befehl in Windows (siehe: http://msdn.microsoft.com/en-us/library/ms187670.aspx). Dieser wiederum ist aus Kompatibilitätsgründen so gestrickt, dass er nur drei Zeichen der Dateinamenerweiterung betrachtet – die gute alte 8.3-Dateinamenbeschränkung aus MS-DOS Zeiten schlägt hier also wieder einmal zu!

Eine Differenzierung nach Dateierweiterung muss also später geschehen, die könnte dann z.B. so aussehen: innerhalb des ForEach-Loop-Containers fügen wir eine Rangfolgeeinschränkung (zu deutsch: einen Pfeil) ein und binden daran eine SSIS-Expression. Diese prüft, ob die letzten drei Buchstaben des ausgelesenen Dateinamens auch tatsächlich x, l und s sind:





So modifiziert, verrichtet das Paket ordnungsgemäß seinen Dienst und findet tatsächlich nur eine Excel-Datei:



Da kann man sich natürlich schon fragen ob es sich um ein Bug oder ein Feature handelt, aber genau wegen diesen Ecken und Kanten lieben wir die Integration Services so sehr – man entdeckt eben immer wieder etwas Neues!

Doch mit steigender Komplexität der Pakete (Verbindungsmanager, Paketvariablen) und ausgiebiger Nutzung der Paketkonfiguration gelangt man mit den SSIS-Bordmitteln einmal mehr an die Grenzen des Wartbaren. Die Integration Services bieten von Haus aus die Möglichkeit, andere SSIS Pakete aufzurufen, doch die Übergabe von Variablen und Verbindungsmanagern an das “Kindpaket” gestaltet sich sehr aufwändig (viel Expression-Hacking). Die Möglichkeit, Rückgabewerte vom Kindpaket zu empfangen fehlt gar gänzlich.

In diese Nische stürzt sich ein Codeplex-Projekt, welches ich im Folgenden kurz vorstellen möchte: der “Enhanced SSIS Execute Package Task”. Unter http://ssisexec.codeplex.com/ ist das noch recht unbekannte Projekt zu finden (derzeit für SSIS 2005 und SSIS 2008 R2 – siehe “Downloads”). Hilfreich bei der Installation (es wird eine dll und ein schmales readme geliefert) ist folgender Eintrag in den Books Online: http://msdn.microsoft.com/en-us/library/ms403356.aspx Hat man die Komponente erfolgreich installiert lässt sie sich über einen Rechtsklick in die Toolbox -> Choose Items in die Liste der Kontrollfluss Tasks aufnehmen.



Die Komponente bietet eine grafische Oberfläche zum Mappen der Variablen bzw. Verbindungsmanagern zwischen den Paketen. Diese können entweder im Dateisystem oder in der MSDB serverseitig gespeichert sein. Somit lassen sich recht schnell und komfortabel Konfigurationen zwischen Paketen übergeben. Wie das aussehen könnte sieht man in folgendem screenshot: Hier wird von einem Steuerpaket, welches den Pfad zu einer Exceldatei via Paketkonfiguration erhält, ein Kindpaket aufgerufen wobei der Verbindungsmanager zwischen den Paketen übergeben wird.



Hinweis: Das Projekt hat derzeit noch den Alpha-Status – vom Einsatz in einer Produktivumgebung rate ich also dringend ab! Laut Aussage des Authors scheint es aber stabil zu laufen und dieser freut sich mit Sicherheit über ausgiebiges feedback in Form von Kommentaren oder Anmerkungen. In diesem Sinne: happy testing!

Abhilfe schafft hier ein kleiner Trick, der in den screenshots unten zu sehen ist. Mittels des Tasks “Abgeleitete Spalte” erstellt man eine neue Textspalte, deren Inhalt die Spalte mit den führenden Nullen eingebettet in Hochkommata und ein vorangestelltes Gleichheitszeichen ist (Escape-Sequenz beachten!).





Als Resultat interpretiert Excel fortan den Wert in der Spalte als Formel und die führende Null wird korrekt dargestellt.

Weg #1: Abgeleitete Spalte

Der “Standardweg” zeichnet sich durch Übersichtlichkeit und Einfachheit aus. Mit dem Toolbox-Element “Abgeleitete Spalte” lassen sich bekanntlich neue Spalten erstellen. So können wir ganz bequem zwei neue Spalten mit den gewünschten Namen erstellen, deren Inhalt einfach aus den alten Spalten abgeleitet wird:

Der große Nachteil hierbei ist die Tatsache, dass unser Datenfluss von nun an vier Spalten enthält, wobei wir nur zwei benötigen. Ich halte meine SSIS-Pakete gerne übersichtlich, und spätestens wenn es an das Wegschreiben der Daten geht hilft es, wenn die Spalten in Bezeichnung und Anzahl übereinstimmen. Abhilfe schafft hier das “Union All” Element, welches das Löschen überflüssiger Spalten ermöglicht. Hinter dem Union-Element erscheinen dann nur noch die gewünschten Spalten:

Weg #2: Der Erweiterte Editor

Bei vielen Toolbox-Elementen lassen sich Ausgangsspalten auch direkt umbenennen, so z.B. bei dem Element “Suche”. Für alle gewünschten Suchspalten lässt sich ein Alias definieren:

Manchmal hilft auch der Blick in den “erweiterten Editor”, der für viele Toolbox-Elemente dieselbe Funktionalität bietet, nur eben etwas versteckter.

Weg #3: Das Union-Element

“In der Kürze liegt die Würze” – so oder so ähnlich könnte das Tooltip für das Union-Element lauten, denn es erlaubt die Umbenennung der Ausgangsspalten nach Belieben:

Aber Vorsicht! Diese Lösung erscheint solange praktikabel bis sich die Metadaten der betroffenen Spalten irgendwo überhalb des Union-Elements ändern. Dann erwartet Sie (je nach Art der Metadatenänderung) eine regelrechte “Klickorgie”, da die betroffenen Spalten aus dem Union-Element entfernt, neu eingefügt und umbenannt werden müssen. Das alles natürlich erst nachdem SSIS Sie freundlich mit einem Pop-Up auf die Metadaten-Änderung hingewiesen hat. Im schlimmsten Fall haben Sie beim Troubleshooting vergessen, wie die eigentliche Umbenennung lautete…

Weg #4: Abgeleitete Spalte für Fortgeschrittene

Einen sehr eigenwilligen Weg habe ich erst kürzlich entdeckt. Bei der Einarbeitung in ein bestehendes SSIS-Paket verfolgte ich den Verlauf einer Spalte, wobei mir auffiel, dass die Spaltenbezeichner vor und nach einem Element “Abgeleitete Spalte” komplett unterschiedlich waren und weder ersichtlich wurde an welcher Stelle eine Umbenennung stattgefunden hatte, noch welche Ausgangsspalte den Inhalt welcher Eingangsspalte trug. Nach langem Probieren war ich in der Lage folgenden “hack” zu rekonstruieren:

Zunächst nutzt man das Element “Abgeleitete Spalte” um den Inhalt der beiden Spalten mit deren Inhalt zu ersetzen – intuitiv, nicht wahr?

Anschließend folgt die Umbenennung, indem man in der linken Spalte den gewünschten Bezeichner einträgt und [Enter] drückt. Der screenshot zeigt, dass die erste Spalte (given_name) bereits umbenannt wurde und die zweite Spalte kurz vor der Umbenennung steht.

Von nun an sind die Spalten in diesem Element nur noch unter dem neuen Namen zu finden – keine Spur mehr von den alten Bezeichnern! Dies bezeugen auch die die Metadaten des folgenden Pfades:

Diese “gespenstische” Lösung realisiert die Spaltenumbenennung im Verborgenen und ist alles andere als transparent für den Nutzer. Viel schlimmer ist allerdings noch, dass die Zuordnung der Eingangs- zu den Ausgangsspalten überhaupt nicht mehr ersichtlich wird und man damit auf die Semantik der Bezeichner angewiesen ist. Semantik – igitt.

Im “daily business” bevorzuge ich übrigens wann immer es geht Weg #2 und dort wo mir nichts anderes übrig bleibt Weg #1. Ein wichtiges Kriterium beim Entwickeln von ETL-Paketen ist aus meiner Sicht die Lesbarkeit und Verständlichkeit, denn eher früher als später wird sich ein anderer Entwickler oder gar der Kunde mit Ihrem Paket auseinandersetzen müssen/wollen – erst dann zeigt sich wie lesbar Sie entwickelt haben!

Und? Alles kalter Kaffee für Sie? Oder war doch etwas Neues dabei? Haben Sie noch weitere Lösungen? Wie handhaben Sie die Spaltenumbenennung in Ihrem “daily business”? Ich freue mich auf Ihr feedback!

Die SQL Server Integration Services bieten dem Benutzer daher einen SCD-Wizard, in dem er schnell und unkompliziert die veränderliche Dimension bearbeiten kann. Wer ihn schon einmal benutzt hat, kennt aber die beiden Hauptärgernisse:

1. Änderungen an der Komponente zerstören schnell die mühsam erstellten Beziehungen zu folgenden Komponenten.
2. Größere Dimensionen werden äußerst unperformant behandelt.

So wird die SCD Komponente oft von workarounds abgelöst und fristet ihr Schattendasein zwischen Skript-Task und SQL-Befehlen.

In den vergangenen Monaten wurde auf Microsofts Community-Plattform Codeplex ein Projekt namens KimballsMethodSCD entwickelt, welches der Slowly Changing Dimension in den SSIS zu neuem Glanz verhelfen soll. Autor der Komponente ist Todd McDermid; als Pate für den Projektnamen stand Ralph Kimball ein, dessen SCD-Best Practices aus seinem Buch The Data Warehouse Toolkit signifikanten Einfluss auf die Entwicklung der Komponente hatten. Aber nun zum Addon: die Installation gestaltet sich dank msi-Installer problemlos; die KimballMethodSCD Komponente ist dann als Datenfluss-Komponente verfügbar. Eine erschöpfende Beschreibung der Fähigkeiten der Komponente würde genügend Stoff für zehn Blog-Einträge liefern, daher seien an dieser Stelle die „Perlen“ erwähnt:

- Umsetzung der Best Practices nach Kimball: unknown member Unterstützung; Angabe eines Änderungsgrundes als Spalte für geänderte Spalten; einfaches Row Auditing für Einfüge- und Updateoperationen
- die existierende Dimension wird aus einem Datenfluss heraus gelesen statt aus einem Connection Manager; dies ermöglicht mehr Flexibilität und besseres Cacheverhalten
- Änderungen wirken sich nicht zerstörerisch auf darunterliegende Komponenten aus
- flexible Spaltenvergleiche sind möglich: z.B. können Spalten Case-(un)sensitiv und Space (un)sensitiv verglichen werden
- eine Performancesteigerung gegenüber der Standard Komponente um den Faktor 100 (!) kann bei großen Dimensionen ohne weiteres erreicht werden

Während die ersten Punkte im Wesentlichen Designhilfen für den Entwickler darstellen, ist die Performancesteigerung ein netter Nebeneffekt der guten Implementierung des Addons: durch die Nutzung multipler Threads und einer Sortieroptimierung sind Ausführungszeiten möglich, die mit dem Standard Wizard undenkbar sind. Dieser nutzt einen langsamen Row-by-Row Lookup auf die Dimensionstabelle, während der KimballlMethod SCD die gesamte Tabelle in einem Stream einliest.

Obiges Beispiel, welches neben dem Addon auch als SSIS-Solution zum Download angeboten wird, zeigt den imposanten Performancegewinn: Eine Dimensionstabelle wurde mit 120.000 Datensätzen geladen. Anschließend wurden die Quelldatensätze dahingehend manipuliert, dass 33 SCD1 Änderungen und 42 SCD2 Änderungen entstanden, wodurch ein winziger Bruchteil der Dimensionsdatensätze geändert werden mussten. Bei den Ausführungszeiten zeigte sich, dass der SSIS Standard Wizard 29 Minuten brauchte, der KimballMethod SCD hingegen nur 15 Sekunden (!). Zwar musste das ausführende System einen 10fach gestiegenen Hauptspeicherbedarf kompensieren, der Anwender wurde aber mit einer 118fachen Leistungssteigerung belohnt.

Die Ausführungszeiten, die nach Ralph Kimballs Best Practices erweiterte Funktionalität und letztlich auch die Einfachheit der KimballMethod SCD machen diese zu einer echten Alternative zum Standard Wizard und verhelfen der etwas eingestaubten Slowly Changing Dimension in den SSIS zu neuem Glanz.