Und tatsächlich ist der MERGE Befehl auch noch um einiges mächtiger als ich in dem Beispiel für einen einfachen ELT Ladeprozess gezeigt hatte. Und natürlich lässt sich damit mehr machen als nur einen ELT Prozess zu unterstützen.

Hier noch mal die grundlegende Syntax:

MERGE <Ziel>
USING <Quelle>
ON <Bedingung>
WHEN MATCHED THEN <Update oder Delete>
WHEN NOT MATCHED THEN <meist ein Insert>;

Nun, was geht jetzt noch? :-)

Eine interessante Möglichkeit ist, dass sowohl zwei MATCHED als auch mehrere NOT MATCHED Klauseln unterstützt werden. Für den Einsatz gibt es aber Bedingungen.

Wenn mit zwei MATCHED Klauseln gearbeitet werden soll, dann muss die erste Klausel auf jeden Fall eine erweiterte Bedingung mittels AND Klausel beinhalten. Des Weiteren kann nur einmal UPDATE und einmal DELETE genutzt werden! Also ein "wenn Du so, dann Update A und wenn Du so, dann Update B" geht nicht. Dafür muss dann die OUTPUT Klausel verwendet werden, um den Befehl mit einem weiteren zu verbinden.

Ein möglicher Anwendungsfall für zwei MATCHED ist zum Beispiel wenn ein Kennzeichen in der Quelle für das Löschen eines Datensatzes im Ziel mit übergeben wird.

Wie ist das mit der NOT MATCHED Klausel? Erst mal der Hinweis, dass T-SQL standardmäßig davon ausgeht, dass wir meinen, dass ein Satz aus der Quelle nicht im Ziel gefunden wird. Logisch, oder? Aber es gibt durchaus auch die Version WHEN NOT MATCHED BY SOURCE. Damit werden Aktionen ausgelöst, wenn ein Satz aus dem Ziel nicht "mehr" in der Quelle gefunden wurde. Für alle Mengenlehre Fans unter Euch, dass ist dann ein Right outer join. Überhaupt ist der MERGE Befehl weniger eine Mischung aus UPDATE, INSERT und DELETE als eher ein JOIN mit der Option auf Aktionen. Und WHEN NOT MATCHED BY SOURCE darf wiederum zweimal vorkommen und als Aktionen entweder ein UPDATE oder DELETE auslösen. Also ähnlich einem MATCHED.

So, und nun nicht die OUTPUT Klausel vergessen. Und nochmals der Hinweis, die gibt es auch für INSERT, DELETE und UPDATE !!!

Zwischenstand, was haben wir denn bisher:

MERGE <Ziel>
USING <Quelle>
ON <Bedingung>
WHEN MATCHED (AND .) THEN <Update oder Delete>
WHEN MATCHED (AND .) THEN <Update oder Delete>
WHEN NOT MATCHED (BY TARGET (AND)) THEN <Insert>
WHEN NOT MATCHED (BY SOURCE (AND)) THEN <Update oder Delete>
WHEN NOT MATCHED (BY SOURCE (AND)) THEN <Update oder Delete>
OUTPUT $ACTION (,.);

Des Weiteren ist wichtig zu verstehen, dass jede Zeile nur einmal evaluiert wird! Also eine ON Bedingung, welche eine 1:N Verknüpfung enthält, wird fehlschlagen, wenn diese nicht durch eine weitere Bedingung "ausgebremst" wird. Der SQL Server wirft sonst folgende Fehlermeldung:

"Die MERGE-Anweisung hat versucht, dieselbe Zeile mehr als einmal zu aktualisieren oder zu löschen. Dies passiert, wenn eine Zielzeile mehr als einer Quellzeile entspricht. Eine MERGE-Anweisung kann dieselbe Zeile der Zieltabelle nicht mehrfach aktualisieren/löschen. Optimieren Sie die ON-Klausel, um sicherzustellen, dass eine Zielzeile mindestens einer Quellzeile entspricht, oder verwenden Sie die GROUP BY-Klausel, um die Quellzeilen zu gruppieren."

Was kann nun alles damit realisiert werden?

Gerade WHEN NOT MATCHED (BY SOURCE (AND)) THEN ermöglicht schöne Sachen. Zum Beispiel eine Historisierung von Daten, wenn diese im Quellsystem nicht mehr vorhanden sind. Also wenn Satz im Ziel vorhanden ist, aber in der Quelle nicht mehr, dann können wir diesen Löschen (wie öde) oder mittels UPDATE ein inaktiv Kennzeichen setzen. Dieses inaktiv Kennzeichen sollte dann aber auch als zusätzliche Bedingung aufgenommen werden, weil wir ja sonst immer dieses UPDATE durchführen würde, was recht suboptimal wäre.

So, und zum Abschluss noch der Hinweis an Alle, dass ich MERGE häufig als Alternative oder auch als deutliche Optimierung zum klassischen Cursor verwende! Viele Logiken, welche auf der Basis einer zeilenweise Betrachtungsweise von Tabellen basieren, lassen sich mittels MERGE bzw. auch einem zusammengesetzten Statement mit der Verwendung von OUTPUT, wesentlich effizienter gestalten!

"In diesem ersten Teil der Webcast-Reihe von Sascha Lorenz und Peter Kirchner zum SQL Server 2008 R2 erhalten Sie einen kurzen Überblick über die Inhalte dieser Webcast-Reihe sowie als Einstieg in das Thema einige Grundlagen, die jeder besitzen sollte, wer mit dem SQL Server arbeitet. Bereits diese Grundlagen können gängige Fehler in Implementierungen, die den SQL Server betreffen, vermeiden und sogar bereits positive Auswirkungen auf die Performance Ihrer Softwarelösungen haben. Insbesondere das Verständnis für Abfragen soll geschärft werden, beim SQL Server in Mengen anstatt in Datensätzen zu denken. Gerade dieses Thema dürfte für Entwickler, die mit Oracle vertraut sind und nun für den Microsoft SQL Server entwickeln, von besonderem Interesse sein."

Vielen Dank an Lori und Peter für Ihre Unterstützung für dieses kleine Community Projekt!

Die Aussage mit den Expressions (Ausdrücken) und der Konfiguration ist für sich genommen natürlich korrekt und wird von mir bzw. meinen Kollegen in Projekten auch verwendet.

Wichtig ist aber die Einsicht, dass sich halt nur "fast" alles damit steuern lässt! Und aufgrund der Architektur der Integration Services lässt sich während der Laufzeit eines Paketes der Inhalt eines Datenflusstasks nicht verändern! Und gerade da setze ich häufig an, um die Erstellung und Wartung von SSIS Paketen weitestgehend zu automatisieren.

Oft sehe ich aber Ansätze von Kunden oder in der Community für dynamisches SSIS, welche so nicht funktionieren können. Um solchen Missverständnissen vorzubeugen, möchte ich heute mal ein Beispiel zeigen, was eben gerade nicht funktionieren kann. Den Ansatz brachte neulich ein Kunde zum SSIS Coaching mit.

Also, sein Ansatz sieht vor, dass er zwei Variablen hat. Eine für den Namen einer Tabelle und einen für die SQL Query.

Dann kommt er mit der Idee, die Eigenschaft "EvaluateAsExpression" der Variable "SQL" zu nutzen, um die Query zusammenzusetzen. Damit hat die Variable den Value, welcher sich aus der Expression ergibt.

Nun kommt in einem Datenflusstask eine OLE DB Quelle, in welcher die Variable "SQL" verwendet wird. Alles gut, wir sehen die Query unten. Das scheint zu passen.

Den Datenfluss erweitern wir nun um einen Multicast, damit er lauffähig wird. Multicast kann ja durchaus aus mal zum Testen von Paketen verwendet werden da es "auch" ein NULL-Ziel sein kann. Noch ein Blick auf die Metadaten, die sind ja das A&O eines Datenflusstasks. Sind auch da. Immer noch alles gut!

Und wir lassen das Paket mal laufen. Wenige Sekunden später. Es funktioniert. Also, wozu die ganze Aufregung?

Kommen wir zum eigentlichen Zweck der Variablen. Ändern wir die Variable für die Tabelle ab, um eine andere Tabelle als Quelle zu verwenden. Ich habe hier gerade noch die Demotabelle für meinen RDLInput liegen, nehmen wir einfach die.

Und wieder starte ich das Paket. Und was passiert? Ein Fehler kommt hoch! Hier ist nämlich der Denkfehler versteckt. Und zwar gibt es ein Problem mit den Metadaten.

Schließen wir die Meldung und öffnen mal unsere Quelle. Und wieder kommt eine Meldung hoch. Und zwar möchte uns die Quelle mitteilen, dass die SQL Query (in der Variable) und die Metadaten der Quelle nicht mehr synchron sind. Also nicht mehr übereinstimmen. Klar, wir wollten nun ja auch eine andere Tabelle haben und natürlich hat diese andere Spalten. Selbst das automatische Beheben des Fehlers würde nur die Quelle "heilen", aber die weiteren Datenflusselemente hätten ebenfalls mit den Metadaten zu kämpfen. Also stände uns viel manuelles Doing bevor, um das alles wieder anzupassen. Die dynamische Konfiguration hat sich also nicht gelohnt.

Wie kommt es nun dazu?

Die Architektur der Integration Services sieht vor, dass die Metadaten eines Datenflusstasks zur Entwurfszeit bekannt sind, damit alle der Quelle folgenden Elemente korrekte Input & Output Spalten haben können. Wenn also während der Laufzeit in die Metadaten eingegriffen wird, wie zum Beispiel durch das Neusetzen einer Variable, welche eine Query enthält, dann schützen sich die SSIS und werfen sofort einen Fehler! Wenn Pakete mit den Microsoft Bibliotheken per Repository erzeugt werden, dann befindet sich das Paket in dem Moment ebenfalls im Entwurfsmodus und es können die Metadaten korrekt zugewiesen werden. Das ist die Magie eine SSIS Paket Generators gegenüber der Konfiguration.

Wo dieser Ansatz aber sehr wohl funktioniert, ist eine Umgebung, in der zwar der Tabellenname sich ändern kann, aber die Metadaten (Spalten) identisch bleiben. Selten, kann es aber auch geben. Häufiger kommt eigentlich vor, dass der Connectionstring einer Quelle und eines Ziels mittels Konfiguration geändert wird, damit man zwischen Entwicklungs-, Test- und Produktivumgebung wechseln kann. Das macht durchaus Sinn! :-)

Es ging dabei um einen Pitch für den SQL Server und all seine Möglichkeiten. Ihr wisst schon, diese "Zeigen Sie mal, was das kann." Termine in 90Min. Also war wieder selektives & spontanes Highlights zeigen angesagt. Hat ja keiner die notwenigen 48h Zeit.

Ein echtes Highlight aus meiner Sicht sind die Reporting Services (SSRS). Aber ähnlich wie die Integration Services (SSIS), welche gerne mal nach wenigen Minuten mit "sagen Sie doch gleich Schnittstelle." abgetan werden, sind die Reporting Services für viele einfach "ach so, Berichte, haben wir natürlich schon." und liegen damit wohl verpackt in einer Schublade, die den Möglichkeiten einfach nicht gerecht wird.

Sofern Ihr auch mal in diese Situation kommen solltet, hier ein paar Anregungen (ohne den Anspruch auf Vollständigkeit) wofür die SQL Server Reporting Services noch alles genutzt werden können.

Berichtswesen (Enterprise Reporting) & Self-Service BI Tool
Klar, das ist DIE Domäne der Reporting Services und da muss sich das Produkt auch nicht vor Marktbegleitern verstecken. Neben den Möglichkeiten im eigentlichen Bericht (Tablix & co), sollte da aber immer auch auf die "Enterprise" Features eingegangen werden, wenn denn ein CIO im Raum ist. Denn Enterprise steht für mich als das Synonym für "Große, komplexe bis unübersichtliche Umgebungen". Hier können die Reporting Services durch ihren Ansatz als zentraler hochverfügbarer Dienst punkten. Die Verwaltung lässt sich auch weitestgehend automatisieren.

Nur was kann jetzt noch kommen? Was können die Reporting Services nun noch außer Berichte erzeugen? Eine ganze Menge!

Dashboards
Auf Basis der Reporting Services lassen sich aussagekräftige Armaturenbretter (neudeutsch Dashboards) erstellen. Und dabei können diese von Tachometer (Gauge) bis hin zur Sparkline alle geschätzten Visualisierungsansätze verwirklichen. Diese können, sofern notwendig, sich sogar automatisch in quasi Echtzeit aktualisieren.

Benutzeroberfläche für die Endanwender einer Business Intelligence Lösung
Da ja der Microsoft Business Intelligence Stack keine "eigene" Oberfläche mitbringt, steht der geforderte Berater häufig in der Pflicht hier eine kompetente Aussage machen zu müssen. Die korrekte Antwort wäre hier sicherlich SharePoint, aber es gibt immer wieder Gründe, welche den spontanen Einsatz von SharePoint verhindern. Eigentlich schade, aber was dann? Hier können die Reporting Services helfen, da diese ganz hervorragend ein zentraler Anlaufpunkt für die Endanwender sein können. Des Weiteren bietet die Möglichkeit die RDLs untereinander zu verlinken, dem Endanwender ein geschlossenes Benutzererlebnis. Und Funktionen, welche nicht dabei sind, können in ASP.NET relativ leicht nachgereicht werden. Vielleicht sollte ich später mal mehr zu diesem Punkt schreiben.

Benutzeroberfläche für die ETL/Reporting/BI Prozess Verantwortlichen
Das geht dann natürlich auch, denn irgendjemand ist ja für die Prozesse im Hintergrund verantwortlich und möchte oder sollte sich nicht immer gleich aufs Management Studio stürzen müssen, um mal was nachzusehen. Und wo wir gerade in der IT unterwegs sind. Natürlich lassen sich da auch alle anderen IT Prozesse ganz hervorragend mit kapseln und, über die Möglichkeit klassische Hyperlinks dynamisch einzubinden, auch noch interaktiv steuern.

Export Schnittstelle, welche die Fachabteilungen selbst "pflegen" können (Self-Service Schnittstelle)
Die Reporting Services können ja nicht "nur" HTML, Excel, Word & PDF exportieren, sondern auch schnödes CSV & XML. Damit lassen sich sehr einfach zentral gesteuerte (Zugriffsrechte & co) Schnittstellen für Fachabteilungen aufsetzen, welche dann im Detail, wie zum Beispiel Spaltenwahl, vor Ort gepflegt werden können. Damit lässt sich die eine oder andere Access Installation vermeiden.

Datenquelle
Nun aber, die Reporting Services können nicht nur als Daten-Konsument herhalten, sondern mittels Data Feeds (& CSV s.o.) auch als Datenquelle für weitere Prozesse und Anwendungen. Das wohl mittlerweile prominenteste Beispiel dafür ist PowerPivot, welches sich direkt aus existierenden Reports bedienen kann.

Erzeugen von Images
Und hier noch der Hinweis auf ein häufig unterschätztes Feature der Reporting Services. Es können nämlich sehr einfach Images in fast allen benötigten Formaten (jpg, png etc.) erzeugt werden. Damit lassen sich einige sehr schöne Anforderungen umsetzen! :-)

Hier endet meine kleine Liste. Wichtig wären mir noch zwei Hinweise:

1. Berücksichtigt bitte immer, dass die Reporting Services auf unterschiedlichste Wege anzusteuern und einzubinden sind. Erweiterbarkeit und die Möglichkeit der Automatisierung sind meiner Meinung nach fast schon einzigartig für einen "Berichtsserver". Kreativität zählt hier!

2. Habt bitte immer ein Auge auf die Lizenzierung der Umgebung! Also wer von den Ergebnissen Eurer Prozesse profitiert und damit lizenziert sein müsste usw. Bei Fragen zu Details dazu wendet Euch bitte einfach an Euren Ansprechpartner bei Microsoft! :-)

Der Hinweis, doch bitte ein Vorgehensmodell zu nutzen, hat Wellen geschlagen. Denn wie kommt denn nun der interne als auch externe BI Entwickler/Implementierer/Berater an ein solches Vorgehensmodell. Oder fassen wir die Frage ein wenig allgemeiner: Wie kommt ein Unternehmen, welches den Microsoft Business Intelligence Stack einführen möchte, an einen entsprechenden Plan?

Und was ist überhaupt so ein Modell? Ein Projektplan? Nein, ist es nicht, sondern eher eine Art Handlungsanweisung zur Erreichung des Ziels. Nenne wir es mal nicht Karte sondern Kompass! Dieser Vergleich leuchtet vielen meist schnell ein! Projektplan ist die Karte, Modell der Kompass!