Lasset die Daten zu mir kommen

Transcrição

3
Lasset die Daten zu mir
kommen
113
Import der Umsatzdaten des Unternehmens aus dem Altsystem
114
Die Data Transformation Services des SQL Server 2000
116
Die Neuerungen im SQL Server 2005
Import der Umsatzdaten des Unternehmens
aus dem Altsystem
Der erste Schritt ist getan: Für die wichtigsten Daten der Edikta GmbH gibt es jetzt SQL Server-Tabellen, die aber noch überwiegend leer sind. Der Übergang in diese neue Welt muss für
die Firma aber noch realisiert werden, denn bisher ist die gesamte Buchhaltung und die Produktionsplanung hauptsächlich mit Excel-Tabellen realisiert worden – für die Lagerbestände
hat mal ein Mitarbeiter eine Access-Datenbank gestrickt, und der Vertrieb erhält die neuesten
Verkaufszahlen regelmäßig als Textdatei per E-Mail zugeschickt. Jetzt müssen alle diese Daten
in den SQL Server importiert werden – teils nur einmalig, teils muss dies auch regelmäßig zeitgesteuert wieder erfolgen. Die Buchhaltung schließlich traut dem Ganzen noch nicht so recht
und wünscht sich ihre Daten als automatischen Excel-Export wieder zurück.
Ein erster Blick auf die Altdaten zeigt, dass sich dort auch sehr viel Müll angesammelt hat: In
den Excel-Tabellen stehen in vielen Spalten, die eigentlich Geldbeträge enthalten sollten, Dinge
wie »k.A.«, »NN« oder »--,--«, die Kosten stehen mal in Euro, mal in Dollar in der Spalte und
haben davor » « oder »$« stehen, kurz: Es muss auch viel aufgeräumt und umgerechnet werden.
Zunächst wird diese Aufgabe an die Entwickler herangetragen, die natürlich, Entwickler, die
sie nun mal sind, sofort ihr Visual Studio starten und für die Importe eigene Programme
schreiben wollen. Der IT-Leiter kann dann gerade noch rechtzeitig eingreifen und dies verhindern! Mit Recht wendet er ein, dass ein selbst geschriebenes Importprogramm zwar sehr schick
ist, dass es dann aber wieder nur von den Entwicklern angepasst und erweitert werden kann,
und die haben doch wirklich schon genug zu tun. Er schlägt vor, für diese Aufgabe die neuen
Integration Services von SQL 2005 zu verwenden, und damit die Kopiervorgänge als stets wiederholbare »Pakete« abzuspeichern. Für diese Pakete gibt es eine grafische Oberfläche, die die
Bearbeitung auch ohne große Programmierkenntnisse möglich macht. Und als die Entwickler
erst sehen, wie schön man die Integration Services auch programmieren kann, machen sie sich
113
Rupprecht Dröge, Markus Raatz: SQL Server 2005 - Konfigurierung, Administration, Programmierung - 2. Auflage. Microsoft Press 2006 (ISBN 978-3-86063-997-9)
doch mit großer Freude ans Werk. Schließlich werden einige Abteilungen übergangsweise noch
weiter mit ihren Altlösungen arbeiten, und die neu hinzugekommenen Werte müssen inkrementell importiert werden.
Wie schon in Kapitel 1 im Abschnitt »This is not your father’s DTS« beschrieben, betritt man
bei den neuen SQL Server Integration Services, die die Nachfolge der enorm beliebten Data
Transformation Services (DTS) antreten, wirklich eine neue Welt. Aus der Praxis wissen wir,
dass die allermeisten Nutzer des SQL Server 2000 Bekanntschaft mit diesem mitgelieferten
Import-Export-Tool gemacht haben, und für die meisten war es ein positives Erlebnis. Die Popularität dieses Werkzeugs in der Entwicklerszene war schon kurz nach seinem Erscheinen
gewaltig. Legendär sind die vielen Kunden, die ausschließlich z. B. mit Oracle-Datenbanken
arbeiten, die aber, von den Import/Export-Möglichkeiten enttäuscht, extra SQL ServerLizenzen gekauft haben, allein um die DTS verwenden zu können. Das ist vor allem verständlich, wenn man weiß, dass andere ETL-Tools1 wie Trillium oder Informatica natürlich mehr
können als die DTS, aber dafür auch gerne mal Lizenzgebühren in der Höhe von Jahresgehältern kosten! Die SQL Server Integration Services versuchen nun die Erfolgsgeschichte der DTS
bruchlos fortzusetzen. Das betrifft zum einen den Funktionsumfang (der stark erweitert wurde), zum anderen die Grundbegriffe (die gleich geblieben sind). Um den leichteren Übergang in
die neue Welt der Integration Services zu schaffen, betrachten wir noch einmal die wesentlichen Komponenten der Vorgänger-Version im Überblick. Dann werden die vergleichbaren
Objekte der neuen Version im Detail vorgestellt, bevor wir gemeinsam ein erstes Integration
Services Import-Paket erzeugen. Und schließlich erzählen wir noch von unseren liebsten neuen
Features!
Die Data Transformation Services des
SQL Server 2000
Die Data Transformation Services erschienen erstmalig auf dem Markt als integrierter Bestandteil des SQL Server 7.0. Die OLAP-Dienste, die ebenfalls mit dem SQL Server 7.0 eingeführt
wurden, sollten zur Realisierung von Data Warehouses2 dienen. Grundlegender Gedanke dabei
war, diese Data Warehouses über die DTS mit Daten aus den verschiedensten Produktionsdatenbanken, den so genannten OLTP-Systemen3 zu beliefern. Später erkannte Microsoft das
große Potential der DTS und erweiterte im SQL Server 2000 den Funktionsumfang erheblich.
Die DTS sind das ETL-Werkzeug des SQL Servers zur Übertragung von Daten, aber auch von
Datenbankobjekten und Datenbanken selbst. DTS nutzt OLE DB, um unterschiedlichste Datenquellen anzusprechen. Dadurch werden Verbindungen zwischen SQL Servern und anderen
Datenbanksystemen, aber auch zu Text- oder Tabellenkalkulationen ermöglicht. DTS ist quasi
1
ETL bezeichnet den gesamten Extract-Transform-Load-Prozess des Daten-Imports und Daten-»Veredelung«
bis hin zur Bereitstellung der Daten für die Nutzer.
2
Data Warehouses oder ihre kleinen Brüder, die »Data Marts«, sind »nur lesen«-Datenbanken, in denen man
Daten aus verschiedenen Quellsystemen sammelt, um sie zu analysieren. Um die Abfragen schneller zu machen, wird dabei oft auch die Struktur vereinfacht (weniger Tabellen).
3
OLTP steht dabei für »Online Transaction Processing«, im Gegensatz zur Datenanalyse mit OLAP, dem »Online Analytical Processing«.
114
Kapitel 3
eine universelle Schnittstelle zum Zugriff auf alle Daten, die in einfachen Zeilen- und Spaltenformaten gegliedert sind. Datenübertragsvorgänge werden in so genannten DTS-Paketen entwickelt. Diese Pakete sind ein geschlossener Behälter (Container), in dem die für den jeweiligen Arbeitsschritt benötigten DTS-Komponenten definiert und programmiert werden. Solche
Komponenten können Verbindungen, Tasks, Transformationen und der Workflow sein; sie sind
natürlich innerhalb jedes Paketes verschieden oder werden in unterschiedlicher Anzahl benötigt.
DTS-Verbindungen
Eine DTS-Verbindung (Connection) stellt eine Verbindung zu einer anzusteuernden Datenquelle her. SQL Server 2000 nutzt innerhalb der DTS so genannte »OLE DB Data Provider« für
die unterschiedlichsten Verbindungen. Die älteren und noch weit verbreiteten ODBC-Schnittstellen werden mit Hilfe der angebotenen Provider für ODBC in ihr entsprechendes OLE DBGegenstück für den SQL Server übersetzt. Darüber hinaus gibt es entsprechend vorgefertigte
Anbindungen für Datenquellen wie HTML-Seiten oder Textdateien. Damit man die angebundenen Datenquellen auch nutzen kann, werden in den DTS vordefinierte Arbeitsvorlagen bereitgestellt, die DTS-Tasks.
DTS-Tasks, Transformationen und Workflows
Abhängig von der Datenquelle und dem Bestimmungsort der Daten sind unterschiedliche Verarbeitungsabläufe notwendig. Um verschiedenste Arbeitschritte zu ermöglichen, sind im DTS
als Tasks bezeichnete Vorlagen verfügbar. Mit diesen Tasks kann man einen Datentransfer
flexibel programmieren. Der Funktionsumfang ist für das Erstellen durchaus komplexer Datenübertragungsanwendungen ausgelegt. Sollten die von Haus aus vorhandenen StandardTasks nicht ausreichen, so können eigene benutzerdefinierte Tasks (»Custom-Tasks«) im DTSPaket eingebunden werden; dies sind COM-Dlls, die man im Visual Studio selbst programmieren kann. Dadurch ist es möglich, den Funktionsumfang gemäß dem eigenen Bedarf zu erweitern und anzupassen.
Für die Transformation von Spalten stehen innerhalb der Tasks Daten transformieren
form Data«)- und Datengesteuerte Abfrage (»Data Driven Query«) unterschiedliche
nen zur Verfügung. Die Möglichkeiten erstrecken sich hier vom einfachen Kopieren
Anwenden von String- und Datums-Funktionalitäten bis hin zur Verwendung von
Skripten für spezielle Spaltentransformationen.
(»TransFunktioüber das
ActiveX-
Über den Workflow wird der interne logische Ablauf eines DTS-Pakets festgelegt und gesteuert.
Dieser verläuft zwischen den zuvor definierten Objekten wie Tasks und Verbindungen. Der
Workflow stellt drei Zustands-Optionen zur Verfügung. Da ein DTS-Paket zwei Beendigungszustände bei der Ausführung eines Objektes kennt, bei Erfolg und bei Fehler, kann durch den
Workflow dem betreffenden Endzustand begegnet werden und eine daran orientierte Reaktion
erfolgen. Ist diese Unterscheidung nicht nötig, kann durch die dritte Workflow-Option auch
unabhängig vom Beendigungszustand bei Abschluss reagiert werden, beispielsweise um eine
von Erfolg oder Misserfolg unabhängige Meldung anzuzeigen.
Dieser grundsätzliche Aufbau von DTS-Paketen hat natürlich in seiner Basis auch in der neuen
Server-Version Bestand. Was ist nun allerdings neu in den Data Transformation Services des
115
SQL Servers 2005? Es wird Zeit für einen genaueren Blick auf die SQL Server Integration
Services.
Die Neuerungen im SQL Server 2005
Neu ist, dass der SQL Server 2005 eine strikte Trennung zwischen Datenbank-Verwaltung und
Anwendungsentwicklung verfolgt. Die Applikationsentwicklung erfolgt nun ausschließlich im
Business Intelligence Development Studio. Das BI Development Studio ist die Integration der
Visual Studio.NET-Entwicklungsumgebung für den SQL Server. Somit zeichnen sich auch im
Bereich der ehemaligen DTS, wo man ja die Pakete früher direkt in der Administrationsoberfläche, dem »Enterprise Manager« entwarf, starke Veränderungen ab.
SQL Server Integration Services
Im Zuge der fünfjährigen Weiterentwicklung wurden die DTS völlig neu entwickelt und in SQL
Server Integration Services (SSIS)4 umbenannt. Im Gegensatz zum SQL Server 2000 ist die
Verwaltungsoberfläche, das Management Studio, nicht mehr Entwicklungsumgebung für die
IS-Pakete, sondern ausschließlich für das Ausführen der auf dem Server hinterlegten (»bereitgestellten«) Pakete verantwortlich. Die IS-Paketentwicklung erfolgt im Business Intelligence
Development Studio und ist dort, wie in .NET üblich, als eigenes Projekt realisiert. Dies bedeutet auch, dass man unterschiedliche Entwicklungsstände der Pakete in Versionsverwaltungstools wie »Visual Source Safe« ablegen kann, was die Arbeit im Team an größeren ETLProjekten erleichtert.
Ein ganz neuer Bestandteil der IS ist der im Betriebssystem des Servers laufende WindowsDienst mit dem Namen – man höre und staune – »SQL Server Integration Services«. Dieser ist
standardmäßig nach der Installation ausgeschaltet und muss gesondert gestartet werden. Dabei
kann er dann auch gleich konfiguriert werden, sodass er beim nächsten Systemstart – wie die
anderen Serverdienste – automatisch hochgefahren wird. Nötig ist das allerdings nicht etwa
dafür, dass die Kopieraufträge etwa unter der Kennung dieses Dienstes laufen, sondern nur
dafür, dass man sich Statusinformationen von aktuell laufenden Ladevorgängen abrufen kann.
Integration Services-Projekt
Zu einem Projekt können ein oder auch mehrere IS-Pakete gehören, die über das Projekt
selbst zu einer zusammenhängenden Lösung (»Solution«) zusammengefasst werden. Durch die
Kapselung mehrerer Pakete in einer Lösung wird das übergreifende Zusammenwirken der
Einzelpakete erleichtert. Weitere Pakete können innerhalb eines bestehenden Projektes problemlos neu erzeugt werden. Bereits existierende Pakete werden einem Projekt hinzugefügt und
sind danach Bestandteil dieser Lösung. Auf die gleiche Art und Weise lassen sich Pakete vom
Projekt entkoppeln, ohne gleich gelöscht zu werden.
Der Entwicklungsumgebung eines Projektes können während der Konstruktion der IS-Pakete
unterstützende Datenquellen (»Data Sources«) und Datenquellensichten (»Data Source
4
Der Begriff ist zum Zweck der Vollständigkeit aufgeführt und wird im weiteren Verlauf als Integration Services
(IS) bezeichnet. Die Abkürzung »SSIS« ist bei den Amerikanern zwar üblicher, hat aber im deutschen Kulturkreis irgendwie einen üblen Beigeschmack.
116
Kapitel 3
Views«) hinzugefügt werden, die auch nur in der Entwurfsphase zur Verfügung stehen. Die
Pakete des Projekts können sie innerhalb der Entwicklungsumgebung gemeinsam nutzen.
Nach der Weitergabe (»Deployment«) und während der Laufzeit auf dem Server ist der Zugriff
auf diese Datenquellen nicht möglich. Dafür benötigt jedes Paket eigene, definierte Verbindungen, die unabhängig vom Projekt sind und über den Verbindungs-Manager (»Connection Manager«) definiert und verwaltet werden.
Integration Services-Pakete im Überblick
Der wesentliche Unterschied zur Vorgängerversion innerhalb der IS-Pakete besteht auch hier
in einer strikten Trennung der Kontrollflusssteuerung vom eigentlichen Datenfluss. Ein Paket
besteht immer aus einer Ablaufsteuerung) (»Control Flow«) und optional aus einem oder mehreren Datenflusstasks (»Data Flows«).
Ablaufsteuerung
Die Ablaufsteuerung besteht aus logisch miteinander verbundenen oder auch in so genannten
Containern zusammengefassten Tasks. Die Tasks sind die kleinsten in der Ablaufsteuerung
enthaltenen Ausführungseinheiten, wobei der Datenflusstask (»Data Flow Task«) die eigentliche Datenfluss-Pipeline darstellt, die gesondert implementiert werden muss. Die logische Aufeinanderfolge der Tasks, schon als Workflow bekannt, verknüpft die Objekte untereinander mit
den bekannten Bedingungslogiken bei Erfolg, bei Fehler und bei Abschluss. Die in der Ablaufsteuerung enthaltenen Tasks sind durch Container gruppierbar und bilden damit eine zusammenhängende logische Einheit bezüglich des äußeren Workflow. Innerhalb dieser Container werden die enthaltenen Tasks dann über eine innere Workflow-Logik miteinander verbunden. An dieser Stelle ist eine Abgrenzung des inneren vom äußeren Task-Ablauf durch den
Container zu erkennen. Zusätzlich sind die Container dazu gedacht, die in ihnen gruppierten
Tasks als Schleife auszuführen, eine neue Fähigkeit, die bei der Vorversion noch schmerzhaft
gefehlt hat. Abbildung 3.1 zeigt eine Ablaufsteuerung in der Übersicht.
117
Abbildung 3.1: IS-Paket-Designer mit Tasks innerhalb der Ablaufsteuerung
Datenfluss
Der Datenfluss (»Data Flow«) ist ein Task der Ablaufsteuerung; in ihm werden dann wirklich
die Daten übertragen. In der Ablaufsteuerung ist er als ungefüllter Baustein enthalten, der ohne
weitere Entwicklung ineffektiv bleibt. Im Datenfluss sind aber auch weitere spezifische Tasks
enthalten, die speziell auf die Übertragung und Transformation von Daten aus verschiedensten
Quellen und mit den unterschiedlichsten Zielen abgestimmt sind. Die Bandbreite reicht vom
Textdatei-Zugriff über Aggregat-Funktionen und programmierbare Visual Basic.NET-Skripte
bis hin zum Zusammenfassen oder »Splitten« von Datenabfrage-Ergebnissen für eine getrennte
oder zusammengefasste Übergabe der Ergebnisse. Die Komponenten werden wie in der Ablaufsteuerung in logischer Abfolge miteinander verbunden. Dabei ist der Output des vorhergehenden Tasks der zu bearbeitende Input für den anschließenden Task. Näheres wird dazu später noch im Abschnitt »Flatfilequelle und Verbindungs-Manager-Editor für Flatfiles« ausgeführt. Abbildung 3.2 zeigt Ablaufsteuerung und Datenflusstasks im Überblick.
118
Kapitel 3
Abbildung 3.2: Zusammenhang zwischen Ablaufsteuerung und Datenfluss
Wie in der Abbildung zu erkennen, ist der gesamte Designer umfangreicher gestaltet als beim
SQL Server 2000. Sämtliche im BI Development Studio enthaltenen Komponenten basieren
auf .NET. Neben den getrennt zu entwickelnden Ablaufsteuerungen und Datenflusstasks ist
eine umfangreiche Verwaltung von Ereignishandlern (»Event Handlern«) verfügbar.
Ereignishandler
Der Ereignishandler (»Event Handler») gibt uns die Möglichkeit, auf die Ereignisse eines Paketes, Tasks oder Containers zu reagieren, die von einem dieser Objekte während der Laufzeit
ausgelöst werden. Jedes Objekt und das Paket selbst besitzen eigene Ereignishandler, die eine
Reihe von Ereignissen beinhalten, auf die wir wahlweise reagieren können. In jedem dieser
Zustände stehen, genau wie bei der Programmierung eines Paketes, eine Ablaufsteuerung und
wiederum optional auch Datenflusstasks zur Verfügung. Damit ist es möglich, über jeden dieser
wählbaren Zustände ein weiteres IS-Paket, z. B. für einen alternativen Ablauf, zu implementieren. Abbildung 3.3 zeigt rechts die programmierbaren Ereignisse des Ereignishandlers für einen
ausgewählten Task der ursprünglichen Ablaufsteuerung.
119
Abbildung 3.3: Beispiel für einen umfangreichen Ereignishandler
Da jedes hier angelegte Objekt selbst wieder Ereignisse auslöst, besteht die Möglichkeit, innerhalb des gerade bearbeiteten Ereignisses – denn es handelt sich ja auch um ein IS-Paket – weitere Ereignishandler zu integrieren. Das heißt, jedes hier aktivierte und entwickelte Ereignis
stellt wieder ein eigenes IS-Paket dar. Damit lässt sich eine abhängige, durch die Ereignishandler geschachtelte Struktur alternativer Ablaufmöglichkeiten erzeugen, die an das Paket gebunden sind und mit ihm zusammen gespeichert werden. Jedes implementierte Ereignis ist selbst
ein Paket und unterstützt diese Funktionalität in vollem Umfang. Eine Struktur verschachtelter
Ereignisse zeigt Abbildung 3.4
Abbildung 3.4: Darstellung der
Verschachtelungsmöglichkeiten des Ereignishandlers
Die abgebildete Strukturierung zeigt eine erweiterte Steuerung des Paketablaufes durch eine
gezielte Reaktion auf vordefinierte Ereignisse des Ereignishandlers. Damit können also innerhalb eines Paketes weitere vollständige Paket-Logiken entwickelt und eingebunden werden.
Das bedeutet, dass ein IS-Paket jetzt unter Umständen aus mehreren ineinander geschachtelten
Paketlogiken besteht, und das noch zusätzlich zum ohnehin möglichen Workflow.
Durch die Erweiterung mit Ereignishandlern kann man also jetzt IS-Pakete flexibler und umfangreicher gestalten als in der vorherigen Version. Klar, dass dadurch auch die Fehlersuche
120
Kapitel 3
viel komplexer wird. Deshalb tut es gut zu wissen, dass es auch einen ebenfalls neuen, integrierten Debugger gibt.
Integration Services-Debugger
Die Entwicklungsumgebung ist mit einem Debugger ausgerüstet, der die Fehlersuche beim
Entwerfen von Paketen unterstützt. Beim Standardlauf eines Paketes in der Business Intelligence Development Studio-Umgebung ist der Debugger grundsätzlich eingeschaltet. Er kann
aber über den Menüeintrag Debuggen/Starten ohne Debuggen umgangen werden.
Eine neue Möglichkeit bei der IS-Entwicklung sind die Haltepunkte (»Breakpoints«). Sie können auf die einzelnen Zustände des Ereignishandlers gesetzt sein, wie z. B. OnPreExecute oder
OnInformation. Das heißt aber nicht, dass auch ein Ereignishandler für dieses Ereignis in diesem Task existieren muss. Die Haltepunkte arbeiten lediglich mit den gleichen Ereignissen, die
auch der Ereignishandler nutzt. Abbildung 3.5. zeigt die Haltepunkte-Konfiguration eines
Tasks. Dieses Task-Menü steht uns nur in der Ablaufsteuerung zur Verfügung und ist durch
einfachen Rechtsklick auf den Task unserer Wahl und die anschließende Menüwahl Haltepunkte bearbeiten zu erreichen.
Abbildung 3.5: Konfigurationsmenü der Haltepunkte eines Ablaufsteuerungstasks
Wie in der Abbildung gut zu erkennen ist, haben wir hier nicht nur die Wahl zwischen den
unterschiedlichsten Ereignissen, sondern auch noch die Möglichkeit festzulegen, wann unser
Haltepunkt aktiviert werden soll. Ein kleines Beispiel dazu: Wir haben eine Schleife in unserem Paket eingebaut, und in jedem der Testdurchläufe tritt ab der zweiten von insgesamt zehn
Wiederholungen der Schleife ein Fehler auf. Nun wäre es recht anstrengend, wenn jedes Mal
während der Fehlersuche schon beim ersten Auftreten eines Fehlers der Haltepunkt ausgelöst
würde. Interessant wäre es ja, den dritten oder vierten Punkt zu untersuchen. Es ist ja nicht
ungewöhnlich, in alternativen Abläufen mit bestimmten Fehlertoleranzen zu arbeiten. Um das
zu ermöglichen, kann hier über den Typ der Trefferanzahl (»Hit Count Type«) bzw. über die
Trefferanzahl) (»Hit Count«) die Bedingung und nötige Anzahl des Auftretens für jedes zur
Verfügung stehende Ereignis festgelegt werden. Der Typ der Trefferanzahl sagt dabei aus, ob der
Haltepunkt z. B. bei immer, gleich oder größer als oder mehrfach ausgelöst werden soll. Die
121
Trefferanzahl selbst gibt die Anzahl an, wie oft das definierte Ereignis eintreten muss, um den
Haltepunkt zu aktivieren.
Für unser Beispiel würde das bedeuten, dass wir den Typ der Trefferanzahl des Ereignisses OnError auf den Eintrag Trefferanzahl ist gleich und die Trefferanzahl selbst auf die Anzahl 3
setzen müssen, um den Haltepunkt beim dritten auftretenden Fehler zu aktivieren. Damit
stoppt die Ablaufsteuerung dann, wenn das von uns definierte Ereignis zum dritten Mal auftritt, und das Paket wird an der von uns konfigurierten Position unterbrochen; das kann wahlweise ein Task oder auch ein Container sein. Über weitere Debug-Optionen kann man dann
den Zustand des Paketes und seiner Komponenten während der Laufzeit näher betrachten.
Unabhängig davon wird beim Ausführen eines Paketes im Debug-Modus in einem AusgabeFenster der während des Paketlaufes gesetzte Erfolg- oder Misserfolgstatus mit entsprechender
Meldung angezeigt. Meistens wird der auftretende Fehler dabei näher erläutert, was für die
Fehlersuche innerhalb des Paketes während der Entwicklung hilfreich ist.
Wird ein Paket im Debug-Modus gestartet, so zeigen farbliche Kennzeichnungen der Komponenten beim Durchlauf deutlich den Ausführungszustand an. Die farblich gekennzeichneten
Ausführungszustände kann man auf Abbildung 3.6 in Aktion sehen.
Abbildung 3.6: Paketdurchlauf mit den Ausführungszuständen der Tasks
Neben der farblichen Kennzeichnung der einzelnen Ausführungsschritte lässt sich der Ablauf
eines Paketes anhand der Status-Registerkarte im Zusammenhang betrachten. Dabei wird das
Paket und jeder innerhalb des Paketes tatsächlich ausgeführte Task mit einer Start- und Endzeit sowie einer Ausführungsdauer ausgewiesen. Die Darstellung richtet sich dabei nach dem
real durchlaufenen Workflow und lässt ungenutzte Tasks unberücksichtigt.
122
Kapitel 3
Die Darstellung des Prozessablaufes, wie in Abbildung 3.7 zu sehen, ist keine grundlegend
neue Innovation des SQL Server 2005. In der Vorversion wurde die Ausführung eines Paketes
ebenfalls grafisch dargestellt und die durchgeführten Tasks inklusive Ausführungszeiten ausgegeben. Die neue Prozesslaufübersicht ist jedoch wesentlich übersichtlicher gegliedert, und sie
gibt die Durchführungsdauer im Gegensatz zum Vorgänger mit einer Genauigkeit von tausendstel Sekunden an, was die Prüfung von Performancegewinnen bei der Entwicklung von
Alternativlösungen vereinfacht.
Abbildung 3.7: Zusammenhängender
Paketablauf in der Status-Registerkarte
Nun schauen wir uns im folgenden Abschnitt die Realisierung von Paketen etwas genauer an.
Dabei werden wir das erste Beispielpaket für einen Datenimport aus einer Textdatei in eine
SQL Server Tabelle gemeinsam entwickeln.
Entwicklung von Integration Services-Paketen auf dem SQL
Server 2005
Der Softwareentwickler, der sich zum ersten Mal den neuen Integration Services gegenübersieht, wird sich vielleicht durch die vertraute Visual Studio-Umgebung nicht ganz so fremd
fühlen. Für den Administrator oder den Data Warehouse-Designer ist es unbekanntes Terrain,
das sich da vor ihm auftut. Um das Hineinfinden in diese Umgebung zu erleichtern, ist es vielleicht am besten, wenn man sich einmal an das System setzt und einen einfachen Import selbst
durchführt.
Zur nachfolgenden gemeinsamen ersten Paket-Entwicklung auf dem SQL Server ist eine entsprechende Server- und Business Intelligence Development Studio-Umgebung erforderlich.
Dazu muss man eine Instanz des SQL Server 2005 zusammen mit der Entwicklungsumgebung
123
auf einem Rechner installiert haben. Ist dies geschehen, betrachten wir uns erst einmal das
mitgelieferte Portierungswerkzeug des SQL Servers.
Migration von Paketen aus dem SQL Server 2000
Die denkbar einfachste Variante zur Übernahme bestehender DTS-Pakete aus den Vorversionen des SQL Servers ist die Benutzung eines von Microsoft im BI Development Studio integrierten Paketmigrations-Assistenten (»SSIS Migration Wizard«). Dieser dient dazu, DTSPakete der Serverversionen 7.0 und 2000 in ein IS-Projekt im BI Development Studio zu übertragen. Die Portierung kann entweder durch eine direkte Verbindung zum Quellserver der
Pakete durchgeführt werden, oder man bindet die Pakete als so genannte Strukturierte Speicherdateien (»Structured Storage Files«) ein, sofern diese vorher von DTS gespeichert worden
sind. Strukturierte Speicherdateien sind Sicherungen der bisherigen Pakete im Dateiformat
.dts. Über einen intuitiven Dialog mit dem Assistenten wird die Zusammenstellung der zu portierenden Pakete vereinfacht.
Wahlweise kann der Start des Assistenten über den Menü-Eintrag Projekt/DTS 2000-Paket
migrieren oder per Rechtsklick auf den Ordner SSIS-Pakete (»SSIS Packages«) ausgewählt
und gestartet werden. Der Paketmigrations-Assistent importiert danach die ausgesuchten Pakete in das geöffnete Projekt und übernimmt dabei den Workflow, die Serververbindungen sowie
angelegte Variablen und deren Werte in vollem Umfang. Es sind jedoch ausschließlich DTSPakete portierbar, die keine selbst entwickelten Benutzerdefinierten Tasks (»Custom Tasks«)
enthalten. Damit eignet sich der Paketmigrations-Assistent nur zur Übernahme von Paketen,
die ausschließlich aus den klassischen Tasks der herkömmlichen DTS zusammengesetzt sind.
Das sind traurige Nachrichten für die vielen Entwickler, die Mannjahre in DTS-Pakete gesteckt
haben, die maßgeblich mit Eigenentwicklungen bestückt sind. Leider lag gerade in der leichten
Erweiterungsmöglichkeit für viele der Hauptgrund, DTS einzusetzen. Weil die Migration von
alten DTS-Paketen mit dem Assistenten nur eingeschränkt möglich ist, muss man jedes Paket
neu entwerfen, das Eigenentwicklungen enthält. Dabei gibt es natürlich die Möglichkeit, aus
einer Kopie des Originalpaketes sämtliche Eigenanpassungen zu entfernen, um wenigstens das
Grundgerüst der Standard-Tasks per Assistent übertragen zu können.
Realisierung von Paketen
Betrachten wir uns nun jedoch die Realisierung eines neuen Paketes genauer, das dazu dienen
soll, Daten aus einer Excel- bzw. .csv-Datei5 auszulesen und in eine dafür vorgesehene Tabelle
des SQL Servers zu übertragen. Dazu werden einerseits eine entsprechende Zieltabelle auf
dem SQL Server und andererseits ein entsprechendes IS-Projekt benötigt, in welchem das
Paket für den Import von Daten – hier sind es Kundenadressen – entworfen wird. Die .csvDatei hat folgenden Inhalt und wartet lediglich auf das Auslesen durch das zu entwickelnde ISPaket.
KundenNr
Titel
1
2
5
Dr.
Anrede Name
Vorname
Strasse
Herr
Peter
Schmidt
Im Winkel
Herr
Ulrich
Lehmann
Hauptstrasse
HausNr
PLZ
Wohnort
2
12345
München
43
54321
Freiburg
CSV-Dateien können aus einer Excel-Datei heraus erzeugt werden und bilden die tabellarische Struktur der
XLS-Daten mit Hilfe von einfachen Trennzeichen (Tabulator, Komma, Semikolon) im Textformat ab.
124
Kapitel 3
KundenNr
Titel
Anrede Name
Vorname
Strasse
HausNr
PLZ
Wohnort
3
Frau
Ulrike
Schulze
Nebengasse
12
34521
Hannover
4
Frau
Karolin
Müller
Gartenweg
56
24531
Dortmund
5
Herr
Hans
Strasser
Am Brunnen
17 a
42531
Hamburg
Tabelle 3.1: Beispieldaten für einen IS-Import
Die vorgegebene Tabelle 3.1 enthält die zu importierenden Kundendaten, wobei die Spaltenbezeichnungen in der ersten Zeile enthalten sind. Um die Möglichkeiten der Integration Services
darzustellen, beginnen wir zuerst mit der Erzeugung des entsprechend notwendigen ISProjektes im Business Intelligence Development Studio, welches man nach der Installation des
SQL Servers im Programmordner Start/Programme/Microsoft SQL Server 2005 vorfindet.
Nach dem Start des BI Development Studio legen wir zuerst ein neues Projekt an, wobei wir
uns im Dialog für ein IS-Projekt entscheiden, welchem dann eine entsprechende Bezeichnung
(in unserem Fall ISProjekt_Kunden) zuteil wird. Bitte nicht vergessen, das Ablageverzeichnis
für dieses Projekt festzulegen, damit aufwändige Suchaktionen nach den Projektdateien unnötig bleiben. Mit der Bestätigung dieses Dialoges wird das erste IS-Projekt ins Leben gerufen
und als leere Projektmappe (»Solution«) implementiert. Standardmäßig wird ein IS-Paket
angelegt und dem Entwickler ebenfalls ungefüllt zur Verfügung gestellt. Abbildung 3.8 zeigt das
erzeugte zusammenhängende Projekt.
Abbildung 3.8: Standard-Projektlösung nach dem Anlegen eines Projektes
Um nun den einfachen Import der Kundendaten in eine SQL Server Tabelle zu verwirklichen,
muss zuerst die Ablaufsteuerung und danach der Datenfluss des Paketes »Package.dtsx« entworfen und für den Datenimport spezifiziert werden.
Der erste Import – das erste Paket
Für die erste Version unseres Kundendatenimports wird innerhalb des Ablaufsteuerung zuerst
ein Datenfluss angelegt. Dies erfolgt durch dessen Auswahl innerhalb der bereitgestellten Toolbox, in der sämtliche nutzbaren Tasks der Ablaufsteuerung bereitliegen. Der so erzeugte Datenfluss kann nun weiter entwickelt werden. Durch einen Wechsel auf die Registerkarte Datenfluss, stehen uns plötzlich ganz andere Tasks als in der Ablaufsteuerung zur Verfügung. Die
Tasks des Datenflusses sind unterteilt in Datenflussquellen (»Sources«), Datenflusstransformationen (»Transformations«) und Datenflussziele (»Destinations«) und sind damit eigens für
Datenübertragungen ausgelegt. Zwischen Quelle und Ziel der Daten können damit jede Menge
Datentransformationen durchgeführt werden, doch dazu kommen wir später, im Abschnitt
»Datentransformationen mit Tasks«.
125
Für den Zugriff auf die aus dem Excel heraus erzeugte .csv-Datei benötigen wir nun eine Flatfilequelle (»Flat File Source«) aus der zur Verfügung gestellten Toolbox. Diese können wir einfach per Drag&Drop dem Paket hinzufügen. Interessant ist an dieser Stelle, dass der so erzeugte Task sofort als fehlerhaft ausgewiesen wird, da noch keine Verbindung angelegt oder andere
Einstellungen vorgenommen worden sind. Also definieren wir zuerst unsere neu erzeugte Datenquelle.
Flatfilequelle und Verbindungs-Manager-Editor für Flatfiles
Im Konfigurationsmenü unter dem Punkt Verbindungs-Manager (»Connection Manager«) muss
man nun entweder eine neue Verbindung zur Datei anlegen, oder man benutzt eine vordefinierte Verbindung, falls die gewünschte Dateianbindung schon existiert. Bereits definierte Verbindungen bleiben erhalten, selbst wenn der Task entfernt wird, der sie benutzt hat; sie müssen
gesondert gelöscht werden.
Wenn die Verbindung neu erzeugt wird, befinden wir uns im nächsten Konfigurationsmenü –
dem Menü für den Verbindungs-Manager-Editor für Flatfiles (»Flat File Connection Manager»«). Dieser Manager wird DTS-Entwicklern der 2000er Version in seiner Oberfläche nicht
völlig unbekannt sein. Im Menüpunkt Allgemein (»General«) kann man die Verbindung genauer bezeichnen und die einzulesende Datei über den Dateibrowser genau definieren. Das
sieht dann für unser Szenario wie in Abbildung 3.9 aus.
Abbildung 3.9: Verbindung zu einer Textdatei herstellen – erstes Menü
Ebenfalls bekannt aus der Vorgängerversion sind die Einstellungen des Menüpunktes Spalten
(»Columns«), in dem ersichtlich und damit prüfbar wird, dass die erste Zeile der .csv -Datei
tatsächlich als Spaltenbezeichnung für die Importdaten genutzt wird, und dass die Trennzeichen zwischen den Datenspalten auch ordnungsgemäß funktionieren.
126
Kapitel 3
Abbildung 3.10: Verbindung zu einer Textdatei herstellen – zweites Menü
Bis hier entspricht die Konfiguration der DTS-Pakete dem SQL Server 2000. Spannend wird es
nun im Menüpunkt Erweitert (»Advanced«), der mit seiner Bezeichnung für sich selbst spricht.
An dieser Stelle kann bereits aus der Verbindung heraus jede Spalte gesondert spezifiziert werden. Das bezieht sich insbesondere auf die Spaltenbezeichnung und den Datentyp. Um das
Entwicklerleben zu versüßen, hat Microsoft in diesem Menü eine »Typ-Vorschlagsfunktion«
integriert. Damit wird eine automatisierte Quelldatenanalyse ermöglicht. Die Tiefe der Analyse
ist durch Angabe der zu prüfenden Zeilenanzahl selbst bestimmbar! Das System ermittelt die
potentiellen Datentypen anhand des Quelldatei-Inhaltes. Die passenden Vorschläge werden
dann im erweiterten Einstellungskontext der Verbindung angeboten und für jede der Spalten
eingetragen. Damit wäre dann das Verbindungs-Manager-Menü definiert und für den weiteren
Verlauf nutzbar.
Abbildung 3.11: Verbindung zu einer Textdatei herstellen – drittes Menü
127
Im Anschluss daran stellen wir mit der noch nicht abgeschlossenen Konfiguration der Flatfilequelle den Verweis zwischen der Verbindung und dem Datenfluss her. Die definierte Verbindung des Tasks wird dazu genutzt, die spezifizierten Spalten aus der Verbindung zur Textdatei
zu übernehmen und dem anschließenden Task als Ausgabe-Spalten bereitzustellen. Dabei können die Spalten wiederum direkt bezeichnet werden, um sie später besser zuordnen zu können.
Wir besitzen damit im Gegensatz zur Vorversion also zwei Ansatzpunkte, um Datenspalten
direkt aus der Datei heraus bezeichnen zu können. Das Mapping der Spalten aus der Textdateiverbindung und dem Task ist im Menü Spalten (»Columns«) – richtig, das existiert in der
Flatfilequelle auch noch einmal – übersichtlich angeordnet und erlaubt uns im Bereich Externe
Spalte (»External Column«) (das sind die Spalten der Verbindung zur Textdatei) eine komfortable Spaltenauswahl per Dropdown-Menü. Die Ausgabespalte (»Output Column«) bildet den
Bereich der Task-Ausgabe ab, der den sich anknüpfenden Tasks als Eingabespalten zur Verfügung gestellt wird. Und genau hier liegt die zweite Möglichkeit der Spaltenbezeichnung, wie
man in der Abbildung 3.12 am Beispiel der »Kundennummer« sieht.
Abbildung 3.12: Spaltenzuweisung der Flatfile-Verbindung im Quelleneditor für Flatfiles
Das Zusammenwirken von Verbindung zur Textdatei und Task stellt die Daten der .csv-Datei
generell für die weitere Verarbeitung bereit. In unserem Beispiel werden wir nun direkt dazu
übergehen, diese Daten in eine SQL Server-Tabelle zu überführen.
SQL Server-Ziel
Dazu benötigen wir ein SQL Server-Ziel (»SQL Server Destination«) innerhalb des Datenflusses, die man genauso leicht per Drag&Drop hinzufügen kann. Nun muss diese noch konfiguriert werden, was sofort durch das im Task enthaltene Fehlersymbol ersichtlich wird. Wir öffnen einfach mit einem Doppelklick das Konfigurationsmenü und landen wieder umgehend bei
den Einstellungen zum Verbindungs-Manager. Viele werden jetzt eine Warnung mit folgendem
Wortlaut bekommen haben: »Diese Komponente besitzt keine verfügbaren Eingabespalten«
128
Kapitel 3
(»This component has no available input columns«). Ja, genau – bevor wir das SQL ServerZiel konfigurieren, sollte auch klar sein, was es zu verarbeiten hat. Deshalb stellt man an dieser
Stelle zuerst die Verbindung zur Quelle – also zu der zuvor definierten Flatfilequelle – her und
stellt damit deren Ausgabedaten zur Verarbeitung bereit. Dazu ziehen wir den grünen Pfeil der
Quelle (»Source«) auf das Ziel (»Destination«). Das war es schon.
Nun konfigurieren wir den Verbindungs-Manager. Bei Klick auf die Schaltfläche Neu (»New«)
stellt sich dieser ein wenig anders dar als zuvor. Wir wollen einen Zugriff zum SQL Server
konfigurieren, man erzeugt aber nur eine neue OLE DB-Verbindung, die auf den SQL Server
zugreifen soll. Abbildung 3.13 zeigt das Konfigurationsmenü mit erfolgreichem Verbindungstest.
Abbildung 3.13: Konfiguration des
OLE DB Verbindungs-Manager
Also suchen wir uns an dieser Stelle den Ziel-Server und auf diesem die Ziel-Datenbank für
unsere zu überführenden Kundendaten heraus. Dann ist die erste OLE DB-Verbindung konfiguriert, und wird auch sogleich für das SQL Server-Ziel verwendet. Die Abbildung 3.14 zeigt
uns das Konfigurationsmenü im Zusammenhang.
129
Abbildung 3.14: Erzeugen
einer Tabelle durch Konfiguration des SQL ServerZiels
Interessant an dieser Stelle ist weniger, dass wir auf der zuvor definierten Datenbank die ZielTabelle wählen können, sondern dass es auch möglich ist, innerhalb dieses Kontextes eine ZielTabelle zu erstellen. Das wirklich Nützliche dabei ist aber, dass man nur durch das Drücken
der Neu-Schaltfläche eine CREATE TABLE-Anweisung in SQL-Syntax erhält, die in Struktur
und verwendeten Datentypen genau der Ausgabe der Flatfilequelle entspricht.
Abbildung 3.15: Spaltenzuweisung zwischen Eingabespalten und gerade erzeugten Spalten der Tabelle
130
Kapitel 3
Damit ist es nicht notwendig, zuvor eine mit Struktur und Datentypen übereinstimmende SQL
Server Tabelle von Hand auf dem Server zu erzeugen, die bei einer Änderung der Datenimportstruktur innerhalb des Paketes als Zieltabelle ohnehin nicht mehr zu gebrauchen wäre.
Wie in Abbildung 3.15 gut zu erkennen, findet vom System eine automatisierte Spaltenzuordnung statt, wenn Eingabe- und Zielspalten die gleiche Bezeichnung tragen. Dies kann natürlich
manuell angepasst werden bzw. muss sogar manuell durchgeführt werden, wenn die Bezeichnungen keine Übereinstimmung aufweisen. Damit wäre der erste Datenfluss fertig gestellt und
bereit für den Testlauf, um die ersten Daten zu übertragen.
Bereitstellung und zeitgesteuerte Ausführung
Ist das erste Paket erst einmal fertig gestellt und getestet, kommt in der Regel der nächste
Schritt, nämlich die Bereitstellung (»Deployment«), des Pakets; auf einen Server, auf dem es
dann gespeichert liegt, und auf dem es in Zukunft auch zeitgesteuert ausgeführt werden kann.
Diese Bereitstellung ist nur mit dem gesamten Projekt und nicht für einzelne Pakete durchführbar. Dazu muss durch einen Rechtsklick auf das Projekt im Projektmappen-Explorer der
Menüeintrag Eigenschaften des Projektes geöffnet werden. Danach öffnet sich das in
Abbildung 3.16 dargestellte Konfigurationsmenü des Projekts. Nun wählen Sie den Eintrag
Bereitstellungsprogramm (»Deployment Utility«), und die beiden ersten Einträge, wie in der
Abbildung zu sehen, setzen Sie auf True.
Abbildung 3.16: Konfiguration des Projektes für die Bereitstellung
Die Angabe des DeploymentOutputPath erzeugt unter Verwendung des Standardeintrags den
Ordner Deployment im Verzeichnis Projekt-Name/bin, in dem sämtliche für die Weitergabe
notwendigen Dateien hinterlegt werden. Diese Einstellungen bestätigen Sie mit OK und wechseln nochmals mit einem Rechtsklick auf das Projekt. Dort wählen Sie nun den Eintrag Erstellen (»Build«), und das System erzeugt die nötigen Bereitstellungsdateien. Danach befindet sich,
wenn es zu keinem Fehler kommt, im beschriebenen Ordner Deployment eine Datei mit der
Endung SSISDeploymentManifest. Beim Starten dieser Datei öffnet sich der in Abbildung 3.17
131
abgebildete Paketinstallations-Assistent (»SSIS Package Installer«), mit dessen Hilfe nun die
Pakete auf den von uns gewählten SQL Server übertragen werden, wo sie anschließend ausführbar hinterlegt sind.
Abbildung 3.17: Integration Services
Paketinstallations-Assistent Dialog
Aber wie wird dieses Paket nun immer wieder z.B. jede Nacht um 23:00 ausgeführt? Dazu
muss man aus der Entwurfsoberfläche zum SQL Server Management Studio wechseln und das
eben übertragene Projekt mit einem oder mehreren enthaltenen Paketen ausführen. Bei oberflächlicher Betrachtung sind diese gar nicht vorhanden. Sind sie aber schon – es existiert nur
kein eigener Ordner dafür in der Oberfläche, wie es beim SQL Server 2000 der Fall war. Als
erfahrene Entwickler wissen wir natürlich eines: Es muss nicht alles zu sehen sein, was physisch vorhanden ist. Lassen Sie sich deswegen nicht beirren, und legen Sie einfach im SQL
Server-Agent einen neuen Auftrag (»Job«) an. Dort klicken Sie auf Schritte (»Steps«) und anschließend auf Neu (»New«); im Dropdown-Menü wählen Sie den Eintrag für die IS-Pakete.
Danach suchen Sie noch den richtigen Server aus (vorzugsweise den, auf dem wir gerade das
Projekt bereitgestellt haben) und klicken auf den Erweiterungsbutton unter dem Eintrag Paket:
Da sind sie dann auch, wie in Abbildung 3.18 zu sehen, die mit viel Mühe, Schweiß und Liebe
entwickelten Pakete. Nun nehmen Sie nur noch die bereits bekannten Einstellungen vor und
schon haben Sie das erste Paket als Job auf dem Server integriert.
132
Kapitel 3
Abbildung 3.18: SQL Server-Agent Konfiguration
Nützliche und neue Tasks der Ablaufsteuerung
Eine der nützlichsten Features der DTS von SQL 2000 besteht darin, dass man eigene Variablen, so genannte DTSGlobalVariables, für ein Paket erzeugen kann, auf deren Inhalt man dann
aus jedem Paketschritt heraus zugreifen kann. Meist geschieht dieser Zugriff aus selbst geschriebenen Skripten, und die »alten Hasen« der DTS fragen sich mit Sicherheit, was wohl
ActiveX-Skripte in den Integration Services zu leisten im Stande sind. Nun, die Benutzung von
ActiveX-Skripten ist nach wie vor möglich, sie werden bei Nutzung des PaketmigrationsAssistenten auch ohne Mängelanzeigen übernommen. Der Zugriff auf die Variablen des ISPaketes wird dagegen nicht mehr unterstützt. Das neue Konzept der Entwicklung erlaubt diesbezüglich nur die Nutzung von VB.NET-Skripten. Damit ist man gezwungen, sämtliche vorhandenen ActiveX-Skripte, die die Variablen eines Paketes be- und verarbeiten, in entsprechende VB.NET-Anwendungen umzuschreiben. Das führt bei einigen Anwendungen, die mit
ActiveX-Skripten gespickt sind, zu einem erheblichen Aufwand. Demgegenüber steht allerdings
die verbesserte Handhabung von Paketvariablen innerhalb der Integration Services, die über
die einmalige Mühe bei der Umstellung hinwegtrösten sollte.
133
Variablen des IS-Paketes und Task ‘Paket ausführen’
Die Übersicht und Handhabung der in einem Paket definierten Variablen ist deutlich erweitert
worden. Im so genannten Paket-Explorer (»Package Explore«r) sind sämtliche im Paket verfügbaren Komponenten enthalten und nach Objektkategorien übersichtlich gegliedert. So findet man unter dem Eintrag Variablen (»Variables«) die gesamte Reihe der im Paket verwendbaren Variablen wieder. Neu daran ist die Erweiterung um systemeigenen Paketkonstanten mit
lesendem Zugriff. Alle zusätzlich von uns erzeugten Variablen sind farbig hervorgehoben. Auch
diese sind über die Einstellung ihrer Eigenschaften für einen schreibenden Zugriff sperrbar, um
die unabsichtliche Änderung von einmal fest zugewiesenen Werten unterbinden zu können.
Neu ist auch, dass ungefüllte Variablen, die erst während der Laufzeit ihre Werte zugewiesen
bekommen, bei Beendigung des Paketes wieder vollständig geleert werden. Das heißt, im Gegensatz zum vorhergehenden DTS bleiben uns gesetzte Laufzeitwerte (von uns selbst eingetragen oder von anderen Tasks gesetzte Werte) nicht in den Variablen erhalten. Damit sind Skripte, mit denen man beim Start eines Pakets die Variablen erst mal leeren musste (»Sind sie denn
auch wirklich leer?«) entbehrlich. Abbildung 3.19 zeigt uns hier sehr übersichtlich die Zusammenstellung der IS-Paketvariablen.
Abbildung 3.19: Nutzer- und SystemVariablen des IS-Paketes
Besonders kompliziert wird es, wenn man diese Variablen von einem Paket an das andere
übergeben möchte. Will man seinen ETL-Vorgang in verschiedene Pakete zerlegen, also modularisieren, ist dies unabdingbar! Bei den DTS ging das auch schon, aber manche Nutzer hatten sicherlich bisher ihre Probleme dabei, den verwirrenden Dialog des Tasks ‚Paket ausführen’
(»Execute Package Task«) bezüglich der Übergabe von Variablen an ein weiteres auszuführendes Paket (»Child Package«) schnell und sauber zu konfigurieren. Dabei war auch die Rückgabe von ermittelten Werten an die Variablen des aufrufenden Paketes nur indirekt möglich,
nämlich nur, indem man den kompletten Aufruf des Kind-Pakets über ActiveX-Skripte realisiert und komplett auf den Task ‚Paket ausführen’ verzichtet.
Auch diese ActiveX-Skripte, die den Task ‚Paket ausführen’ ersetzen sollten, sind nun mit den
Integration Services entbehrlich. Der Workflow, der sich an das aufgerufene Paket anschließt,
bekommt auch den Ausführungsstatus (was ehemals ja nicht immer reibungslos verlief) völlig
unproblematisch gemeldet und reagiert entsprechend seiner Logik. Über einen Ereignishandler
134
Kapitel 3
sind an dieser Stelle auch erweiterte alternative Reaktionen für verschiedenste Ausführungszustände möglich. Die Übernahme von Variablen durch ein Kind-Paket stellt sich zudem als völlig unkompliziert heraus. In dem Konfigurationsmenü, das in Abbildung 3.20 dargestellt ist,
kann man dem Kind-Paket den Zugang zu Parametern des Vater-Paketes mit wenigen Schritten erlauben.
Das vereinfacht die bislang verwirrende Handhabung von Wertübergaben zwischen Paketen
der herkömmlichen DTS erheblich. Die Kenner werden bei genauerem Hinsehen an dieser
Stelle ein wenig überrascht sein, denn bei den Wertzuweisungen der Variablen müssen die
Variablennamen in beiden Paketen unterschiedlich sein, im Gegensatz zur DTS-Variante! Identische Bezeichner waren ja vorher die Voraussetzung dafür, Wertübergaben zwischen Paketen
überhaupt realisieren zu können. Nun ist es notwendig, unterschiedliche Namen für die Variablen zu vergeben, sonst wird der übergebene Wert der Vater-Variablen von der gleich bezeichneten lokalen Variablen des Kind-Paketes überdeckt.
HINWEIS: Wenn man den Task ‚Paket ausführen’ benutzt, werden dem Kind-Paket sämtliche
Variablen des aufrufenden Vater-Paketes vom System zur Verfügung gestellt. Damit kann
ohne eine Konfiguration grundsätzlich auf die Variablen des Vater-Paketes zugegriffen werden. Durch einfache Werteänderung der Variablen im Vater-Paket lassen sich auch Rückgabewerte vom Kind- an das Vater-Paket umsetzen. Dies ist im Konfigurationsmenü nicht enthalten, aber man kann es über Skripte realisieren. Die zugewiesenen Werte bleiben nachhaltig für den restlichen Paketdurchlauf erhalten und stehen auch nach der Beendigung des
Kind-Paketes zur Verfügung. Das Ganze ist aber nur dann möglich, wenn im Kind-Paket
keine gleich benannte Variable existiert, weil diese durch ihren lokalen Status den Zugriff
auf die Variable im Vater-Paket verhindert.
Abbildung 3.20: Konfiguration eines IS-Paketes zur Übernahme von Variablen
135
Somit kann mit dem VariableDispenser der VB.NET-Skripte (mehr dazu im folgenden Abschnitt) direkt auf die Variablen im Vater-Paket zugegriffen und auch deren Wert nachhaltig
verändert werden. Will man über das Konfigurationsmenü direkte Zuweisungen vornehmen, so
sei darauf hingewiesen, dass die Einstellungen zur Übernahme von Vater-Variablen im Menü
des Kind-Paketes (Menü-Aufruf über SSIS/Paketkonfigurationen) von uns vorgenommen werden müssen. Dies war bisher ebenfalls im Vater-Paket zu erledigen.
ACHTUNG: Bereits konfigurierte Zuweisungen von Variablen im Menü Paketkonfigurationen
behalten ihre Gültigkeit auch dann, wenn dieses Menü später wieder deaktiviert wird.
Der angesprochene Paketkonfigurationsplaner kann überhaupt etwa das, was der Task ‚Dynamische Eigenschaften’ (»Dynamic Properties Task«) bei DTS konnte: dynamische Einstellungen zur Laufzeit an das Paket übergeben. Die Übergabe dynamischer Werte (wie z. B. der Name des aktuellen Nutzers, der Servername etc.) ist für jede Paketkomponente über den Paketkonfigurations-Assistenten komfortabel einzurichten. Im Gegensatz zum SQL Server 2000
kann der Entwickler aber nicht mehr alle Eigenschaften der Komponenten eines Paketes während der Laufzeit verändern, was ja in der 2000er-Version sogar mehrfach geschehen konnte.
Das neue Entwicklungskonzept erlaubt lediglich beim Starten eines Paketes dynamische Initialisierungen, um potentiellen Fehlern bei mehrfachen Änderungen innerhalb eines Paketdurchlaufes vorzubeugen. Wer aber dennoch mehr Dynamik und individuelle Anpassungen braucht,
der kann dies durch die Integration der VB.NET-Skripte erreichen.
Skriptentwicklung in VB.NET
Die Entwicklungsumgebung für VB.NET-Skripte ist besser umgesetzt als ihr Vorgänger, der auf
ActiveX basierte. Grundlage der VB-Skripte bilden die in die Umgebung integrierten Programmierunterstützungen des Visual Studio.NET, Syntax Highlighting und IntelliSense, das zur
automatisierten Vervollständigung programmierter Elemente dient und dadurch enorm hilfreich ist. Damit lässt es sich bedeutend komfortabler entwickeln! Der zusätzliche Vorteil für
den Programmierer liegt in der eingebetteten Echtzeit-Syntaxkontrolle, mit der Logiken, Objekte und Ausdrücke während der Code-Entwicklung analysiert und bei auftretenden Mängeln,
wie z. B. Datentypproblemen oder nicht zusammenpassenden Objekten, mit einem zusätzlichen Hilfstext hervorgehoben werden.
136
Kapitel 3
Abbildung 3.21: ActiveX- und VB.NET-Skript im direkten Vergleich
Diese Unterstützung der Programmierung spart uns Zeit bei der Entwicklung bzw. Fehlersuche.
Gerade eine komplexe Anwendung, die umfangreich mit Skripten realisiert werden muss, wird
von den Vorteilen der VB.NET-Umgebung profitieren können. Abbildung 3.21 zeigt den direkten Vergleich zwischen beiden Skriptarten.
Hier ist deutlich der Unterschied zwischen den Skriptentwicklungen zu erkennen. Entwickler
des Visual Studio werden sich von der Oberfläche her wie zu Hause fühlen, sind aber in der
Wahl der Sprache etwas eingeschränkt: Die einzige implementierte Entwicklungssprache für
Skripte innerhalb der Integration Services ist derzeit VB.NET.
Schauen wir uns nun als nächstes den Task ‚SQL ausführen’ (»Execute SQL Task«) an, der in
den DTS oft zu Schwierigkeiten führte, speziell wenn man ihn für gespeicherte Prozeduren
verwendet hat.
Gespeicherte Prozeduren und der Task ‚SQL ausführen’
Ein Problem, das mit den neuen Integration Services behoben wurde, ist der Aufruf von gespeicherten Prozeduren des SQL Servers. Wie beim Vorgänger ist der Task ‚SQL ausführen’ für
die Ausführung von einfachen SQL-Anweisungen vorgesehen. Dazu gehört prinzipiell auch der
Aufruf parametrisierter gespeicherter Prozeduren (»Stored Procedures«), was aber bislang in
DTS sehr schwierig war, besonders wenn man Ausgabewerte aus der Prozedur erwartet. In der
zugehörigen SQL Anweisung werden die Ein- und Ausgabeparameter über den Platzhalter »?«
realisiert und wie folgt im Task ‚SQL ausführen’ eingetragen.
EXEC test_procedure ? OUTPUT, ?
137
Der bekannte Aufruf einer Prozedur auf dem Server würde mit definierten Parametern dagegen
wie folgt aussehen:
EXEC test_procedure @param1 OUTPUT, @param2 = 'test-string'
Der Platzhalter »?« im Task ‚SQL ausführen’ wird bei der Ausführung durch festgelegte PaketVariablen ersetzt und vervollständigt damit die Anweisung. Die Zuweisung der Variablen zu
den entsprechenden Parametern nimmt man im Konfigurationsmenü des Tasks vor. Abbildung
3.22 zeigt den Task bei der Zuweisung der Variablen.
Abbildung 3.22: Zuweisung
von Variablen an Parameter
des SQL Tasks
Mit diesen Einstellungsoptionen ist die Parameterübergabe aus dem Katalog der zur Verfügung
stehenden Variablen unkompliziert und übersichtlich – im Gegensatz zur Vorversion. Aus der
Prozedur zurückgegebene Output-Werte werden auch an das Paket zurückgegeben, den dafür
vorgesehenen Variablen zugewiesen und lassen sich im Anschluss problemlos verarbeiten. Damit sind zeitraubende Beschäftigungen mit diesem Task Vergangenheit, und selbst entwickelte
Alternativ-Lösungen zum Aufruf gespeicherter Prozeduren, wie man sie häufig fand, sind ebenfalls entbehrlich geworden.
Das Ausführen von DTS 2000 Paketen
Monate, ja sogar Jahre der Entwicklung und Wartung der DTS-Pakete auf dem SQL Server
2000, und nun können sie nicht einmal mit dem Assistenten auf die neue Server-Version übertragen werden? Das werden viele Entwickler denken, es ist aber so schlimm auch wieder nicht.
Zum Ausgleich dafür gibt es einen Task ‚DTS 2000-Paket ausführen’ (»Execute DTS Package
Task«), der die Pakete dort wo sie sind und wie sie sind ausführt. Einfach Servernamen angeben und Login eintragen, dann das Paket aussuchen und starten lassen. Wahlweise können wir
hier auch wieder mit den Strukturierten Speicherdateien (.dts-Dateien) im alten Format arbeiten, das macht die Angelegenheit noch einfacher, da hier der Server und Login-Eintrag nicht
nötig sind. Sogar im SQL Server Management Studio gibt es einen eigenen Ordner in der Oberfläche, in dem die herkömmlichen und mit viel Schweiß und Mühe geschaffenen DTSPakete einen Zufluchtsort finden.
138
Kapitel 3
Abbildung 3.23: Konfigurationsmenü des Tasks DTS
2000-Paket ausführen
Der FTP-Task der Integration Services
Eine hilfreiche Möglichkeit, innerhalb der Integration Services-Pakete erzeugte oder modifizierte Daten in andere Systeme zu übertragen, ist der FTP-Task6. Im DTS hatte dieser Task
leider nur lesenden Zugriff auf Dateien in einer FTP-Verbindung, aber er konnte während der
Ausführung eines Paketes Dateien durch den FTP-Zugang abrufen. Die überarbeitete Version
dieser Komponente stellt nun sogar mehrere Dateioperationen bereit. Neben der realisierten
Übertragung von Dateien aus dem Paket heraus können nun auch Verzeichnisoperationen, wie
z. B. das Anlegen oder Löschen eines Ordners oder einer Datei durchgeführt werden. Das Konfigurationsmenü zeigt uns die Abbildung 3.24.
6
FTP ist die Abkürzung für eine Übertragungsart des Netzwerkes und bedeutet File Transfer Protocol
139
Abbildung 3.24: Operationen des FTP-Tasks
Wie hier gut zu sehen ist, wurde auch hier viel Mühe investiert, den Funktionsumfang weit
reichend auszudehnen, und das ist auch gut so, schließlich liegen viele große Datenbanken auf
UNIX-Systemen, mit denen es sich über FTP vortrefflich kommunizieren lässt.
Schleifen der IS – For-Schleife und Foreach-Schleife
Erstmalig in die IS-Entwicklung integriert sind Schleifenlogiken zum wiederholten Ausführen
zusammenhängender Tasks. Die Schleifen werden in Containern ausgeführt und grenzen die
enthaltenen Komponenten von den restlichen Tasks des Paketes ab. Es existieren zwei Arten
von Schleifencontainern, der For-Schleifencontainer (»For Loop Container«)und der ForeachSchleifencontainer (»Foreach Loop Container«). Beide führen die integrierten Tasks bis zum
Erreichen einer vordefinierten Abbruchbedingung durch. Der Unterschied zwischen beiden
Schleifencontainern besteht in der Definition der Abbruchbedingung: Im For-Schleifencontainer wird über einen einfachen Ausdruck, der ein boolesches Ergebnis liefert, die Abbruchbedingung an den Container übergeben. Ein einfaches Beispiel dafür wäre eine Paketvariable, die
während des Schleifendurchlaufes inkrementiert wird, bis sie irgendwann die Abbruchbedingung erfüllt. Abbildung 3.25 zeigt den For-Schleifen-Editor (For Loop Editor) mit einem gültigen Ausdruck, der auf einer Paketvariablen beruht. Zu beachten dabei ist auf jeden Fall, dass
der Ausdruck zum Abbruch der Schleife von »falsch« auf den Zustand »wahr« wechseln muss,
um die Schleife zu beenden. Über diese Abbruchlogik stolpert man als Entwickler öfter mal!
Abbildung 3.25: Konfigurationsmenü des ForSchleifencontainers
140
Kapitel 3
Der andere der beiden Schleifencontainer bietet eine komfortable Möglichkeit der Entwicklung
von dateigestützten Datenimporten, wie dies etwa in unserem ersten Import-Beispiel geschehen ist. Der Foreach-Schleifencontainer kann ebenfalls die in ihm enthaltenen Tasks bis zum
Erreichen einer Abbruchbedingung wiederholen. Durch einen vordefinierten, so genannten
Foreach-Dateienumerator (»For Each File Enumerator«) erhalten wir Zugriff auf die Dateien
des angegebenen Verzeichnisses. In Abbildung 3.26 ist zu sehen, wie man auf die .csv-Dateien
des C:\Import-Verzeichnisses zugreifen kann. Die Schleife des Importprozesses wird für jede im
Verzeichnis enthaltene .csv-Datei durchlaufen, was auch gleichzeitig die Abbruchbedingung
definiert. Damit wir Zugriff auf den kompletten Pfad der Quelldatei erhalten, müssen wir in
den Einstellungen des Enumerators die Option Vollqualifiziert (»Fully qualified«) auswählen.
Mit dem Anlegen und Konfigurieren dieses Schleifencontainers wird vom System eine zusätzliche Paketvariable erzeugt, die bei jedem Schleifendurchlauf den vollständigen Pfad der Datei
enthält, die jetzt gerade aktuell verarbeitet wird.
Abbildung 3.26: Konfigurationsmenü des Foreach-Schleifencontainers
Mit Hilfe dieser Systemvariablen können wir innerhalb eines VB.NET-Skripts den Dateipfad
inklusive des Dateinamens als Zeichenkette bearbeiten. In den Skripten sind dann mit Hilfe
des Pfades auch Dateioperationen wie Verschieben oder Löschen möglich, sodass jeder erfolgreiche Schleifendurchlauf die importierte Datei beispielsweise in einen Unterordner mit der
Bezeichnung importiert verschiebt. Diese essentiell bedeutende Variable des Schleifencontainers wird in VB.NET-Skripten unter dem Namen EnumeratedValue zur Verfügung gestellt.
141
Entwicklungsunterstützende Funktionen
Flexible Taskoptionen
Als hilfreich und praktisch für den Entwickler erweist sich die Deaktivierungsoption (»Disable«) einzelner Tasks innerhalb der Ablaufsteuerung. Die damit gesperrten Tasks werden bei
der Ausführung nicht berücksichtigt, und auch augenfällig optisch gekennzeichnet, wie in
Abbildung 3.6 schon zu sehen war. Das hat den wesentlichen Vorteil, dass man z. B. für einen
Testlauf unnötige Abschnitte des Paketes nicht entfernen muss – man schließt sie lediglich vom
Durchlauf aus. Komplette Teilprozesse können dabei variabel hinzu- oder abgeschaltet werden.
Das ist insbesondere dann ein Zeitgewinn, wenn bereits implementierte komplexe Prozesse
beim Hinzufügen und Testen weiterer Tasks ausgeklammert werden können.
Erweiterte Verbindung für Textdateien
Die schon in unserem Import-Beispiel verwendete Flatfile-Verbindung zu einer Textdatei ist in
den Integration Services optionsreicher gestaltet. So kann neben den bisherigen Grundfunktionen und Einstellungen zusätzlich die Eigenschaft jeder einzelnen Quellspalte definiert werden. Die wichtigste Neuerung dabei stellt die Einstellung des Datentyps dar, was angesichts der
Tatsache, dass die Quelle ja eine reine Textdatei ist, überraschend ist. Man kann damit aber
schon aus der Verbindung heraus festlegen, welche Zieldatentypen diese Quellspalte besitzen
soll. Bei Nutzung der zusätzlichen Vorschlagsfunktion, die den Datentyp durch das Prüfen des
Dateiinhalts ermittelt, kann man die Tiefe der Quelldatenanalyse durch Festlegen der zu prüfenden Zeilenanzahl beschränken.
Die zu dieser Verbindung gehörende Flatfilequelle verbindet die Verbindung zur Textdatei mit
dem Datenfluss. Er ist jedoch weder für Datentransformationen gedacht, noch bindet er eine
Zieltabelle an die Quellspalten der Textdatei. Zweck dieses Tasks ist es, eine gezielte Bezeichnung der Spalten zu ermöglichen und bei Bedarf Einstellungen an Quell- und Zieldatentypen
zu verändern. Die Ausgabe dieses Tasks dient für die im Workflow nachfolgenden Tasks als
entsprechende Eingabe.
Wie bereits andeutet, erfolgen Transformationen von Daten nicht weiterhin innerhalb eines
einzelnen Tasks. Der zusammenfassende Task ‚Daten transformieren’ (»Data Transformation
Task«) der DTS existiert nicht mehr und wird durch eine Aufteilung in mehrere einzelne Tasks
ersetzt. So ist beispielsweise die vorher enthaltene Lookup-Funktionalität, die für jeden Datensatz eine Abfrage in einer anderen Datenbank ausführt, als eigenständiger Task ausgegliedert
worden. Ebenso neu wie nützlich sind auch die Transformationen Abgeleitete Spalte (»Derived
Column Task«) und Bedingtes Teilen (»Conditional Split Task«), die beide im nächsten Abschnitt betrachtet werden.
Datentransformationen mit Tasks
Der für Transformationen von Quelldaten bedeutendste Task des neuen DTS bildet der funktionsreiche Task Abgeleitete Spalte . Dieser übernimmt die Ausgabe anderer Tasks als Eingabe
und ermöglicht die Anwendung umfangreicher Funktionen und Operatoren, um die eingehenden Daten zu bearbeiten. Die Möglichkeit, den ankommenden Datensätzen zusätzliche Spalten für den zusammenhängenden Output hinzuzufügen, ist für den Entwickler von großem
Vorteil. Für diese zusätzlichen wie auch die eingehenden Spalten stehen mathematische Funktionen, Stringfunktionen, Datums- und Zeitfunktionen sowie Typenumwandlungen zur Verfü-
142
Kapitel 3
gung. Eine Liste von Operatoren ermöglicht sogar mathematische Operationen mit den Werten
eingehender Spalten oder Paketvariablen untereinander. Derart umfangreiche Datenumformungen waren in den DTS nur unter Verwendung von ActiveX-Skripten realisierbar, die aber
der Performance immer wenig zuträglich sind, weil für jede Zeile einzeln eine Skripting Engine
gestartet werden muss.
Abbildung 3.27: Ausschnitt aus dem Funktionsumfang des abgeleitete Spalte-Tasks
Das Beispiel in der Abbildung 3.27 zeigt die Möglichkeiten der Transformationen bestehender
Spalten sowie die Erzeugung neuer und zusätzlicher Spalten. Dabei wird eine Stringfunktion
zum Entfernen von Leerzeichen benutzt, mit einer Datumsfunktion wird der Importzeitpunkt
festgehalten, und zwei Zusatzspalten werden mit Werten von zuvor angelegten Paket-Variablen
gefüllt. Dieser Task fasst seine Eingabespalten und Zusatzspalten zu einem Ausgabestrom zusammen und stellt sie so den anknüpfenden Tasks wieder als Eingabe zur Verfügung.
Der Task Bedingtes Teilen sieht in seiner Einstellungsoberfläche dem Task Abgeleitete Spalte
äußerst ähnlich, dient aber dazu, eingehende Spalten basierend auf einem Entscheidungskriterium in zwei Datenströme aufzuteilen. Durch das bedingte Teilen erhalten wir eine Trennbedingung für die Ausgabe dieses Tasks, der wieder unterschiedlichen Ziel-Tabellen zugeordnet
werden kann. Damit wäre zum Beispiel eine Trennung in verschiedene Ausgabedateien für
jeden Postleitzahlbereich möglich.
143
Abbildung 3.28:Trennbedingung »Fall 2« als Eingabedaten für anknüpfenden Task zuweisen
In der anschließenden Selektion der definierten Trennbedingung lassen sich dann problemlos
die so aufgeteilten Daten zuweisen, wie das in Abbildung 3.28 gut zu erkennen ist. Damit kann
der Entwickler recht einfach die Trennung von Daten durch komplexe Prüfbedingungen realisieren. In diesem Zusammenhang kommen wir nun zu unserem letzten Feature.
Daten-Viewer des Datenflusses
Innerhalb der Ablaufsteuerung haben wir ja nun mehrere Möglichkeiten gesehen, als Entwickler auf den Ablauf des Pakets Einfluss zu nehmen, vom Deaktivieren der Tasks bis zu den Haltepunkten. Nun wäre es ja recht angenehm, auch den Datenfluss irgendwie überprüfen zu können, und siehe da: es ist möglich! Der zwischen den einzelnen Tasks laufende Datenfluss kann
»angezapft« werden, um etwa sehen zu können, wie eigene Berechnungen oder Funktionen die
Daten verändert haben, bevor sie an den nächsten Task übergeben werden. Interessant dabei
ist, dass der Inhalt des Datenflusses auf mehrere Arten betrachtet werden kann. So haben wir
die Wahlmöglichkeit zwischen einem einfachen Raster über ein konfigurierbares Histogramm
bis hin zu Diagrammen spezifischer Daten. Und das nicht nur einzeln, sondern für jeden Datenfluss und mit sämtlichen Optionen auf einmal. Damit können übertragene Daten nicht nur
kontrolliert, sondern sogar während der Übertragung ausgewertet werden. Abbildung 3.29 zeigt
das Konfigurationsmenü in der Übersicht.
144
Kapitel 3
Abbildung 3.29: Daten-Viewer des Datenflusses in der Übersicht
Selbstverständlich gibt es noch viele neue Funktionalitäten mehr, und ganz bestimmt haben
wir das Wichtigste und Spannendste vergessen. Jeder Autor, der ein Buch über Integration
Services schreiben darf, in dem jedes Feature gebührend gewürdigt werden muss, ist nicht zu
beneiden! In diesen wenigen Seiten konnten wir eigentlich nur versuchen, etwas Appetit zu
machen. Aber um wenigstens die Richtung klar werden zu lassen, in die es für die Integration
Services geht, wird es Zeit, noch einmal alles zusammenzubringen.
Zusammenfassung
Die Implementierung von ETL-Prozessen ist in der neuen SQL Server Version im Vergleich zur
bisherigen Entwicklung grundlegend verändert. Grund dafür ist das verbesserte Entwicklungskonzept, im Zusammenhang mit der neuen Entwicklungsumgebung. Die IS-Pakete sind nicht
weiterhin reiner Bestandteil des Servers. Ihre Erstellung wurde komplett in ein Client-Tool
ausgegliedert, die Speicherung erfolgt lokal als .dtsx-Datei in einem zusammenhängenden Projektverzeichnis. Der projektorientierte Aufbau der Entwicklungsumgebung ermöglicht eine
Sicherung der unterschiedlichen Entwicklungsstände in verschiedenen Versionen, wie dies in
Visual Studio.NET-Projekten üblich ist. Dieser Aspekt wirkt sich für den Programmierer auch
positiv aus, wenn er zwischen alternativen Lösungsansätzen umschalten muss.
Die Gliederung der Paketoberfläche ist sehr übersichtlich. Innerhalb der unterschiedlichen
Registerkarten eines Paketes wie Ablaufsteuerung, Datenfluss, Ereignishandler und PaketExplorer sind die Komponenten gut strukturiert und überschaubar gegliedert. Insgesamt wurde
145
das Erscheinungsbild der IS-Umgebung für die Entwicklung komfortabler gestaltet und ist
intuitiver als in der vorherigen Version.
Die verbesserte Skript-Programmierung in der neu integrierten Entwicklungsumgebung ist
besonders gut gelungen. Es ist kaum noch ein vorher existenter Mangel übrig geblieben! Die
Ausführung der gespeicherten Prozeduren, die Wertübergaben von und an ausgeführte Pakete
sowie die Handhabung von Paketvariablen im Allgemeinen sind deutlich verbessert worden.
Als förderlich für die einfache und leicht erlernbare Paketentwicklung haben sich die flexibleren Einstellungsmöglichkeiten der einzelnen Paketkomponenten herausgestellt. So ist durch
die Kapselung mehrerer Tasks jetzt eine Gruppierung von Komponenten möglich, wodurch die
unterschiedlichen Schleifenformen benutzbar werden. Bei einem Import von Daten über .csvDateien ist die erweiterte Verbindung zu Textdateien sehr unterstützend und hilfreich. Weil
spezielle Transformationsfunktionen ausgegliedert worden sind, wurde eine Vielzahl neuer
Tasks geschaffen, die umfangreiche Be- und Verarbeitungsmöglichkeiten von Daten im Datenfluss eines Paketes zulassen. Ein gutes Beispiel dafür sind die Transformationen Abgeleitete
Spalte und Bedingtes Teilen, die dem Entwickler übersichtlich und verständlich eine Fülle von
Funktionen für die Datenbe- und -verarbeitung bereitstellen. Dabei stellt jeder in den Datenfluss eingebundene Task die eingehenden und ausgehenden Datenspalten in anschaulichen
Mappings gegenüber.
Fazit: Man müsste sich mal mit den Integration Services und einem Laptop für drei Wochen
auf eine einsame Insel zurückziehen können…
146
Kapitel 3

Lasset die Daten zu mir kommen

Transcrição

Documentos relacionados

Netzwerktechnik CHS Villach Mag. Rainer Swatek Dauer: 2

Versionsvergleich 2010 - 2016

pzetrm21-win - Terminal Systems

Überblick zu den Editionen von SQL Server 2008 R2

MATRIX Vollversion Systemvoraussetzungen

IT-Voraussetzung_7-6-0-x

Offene Ports der Firewall bei Server/Client Installation

DOC PPS-FM11-WIN - Terminal Systems

Vorkonfigurierte Server für Medienpark - silber

Quelle Referenz Microsoft SQL Datenbank