SSIS-Components.net

SQL Server Spatial Data und Mapnik

till — Sun, 26 Feb 2012 01:12:25 +0100

Alastair Aitchison, Autor des Buchs Beginning Spatial with SQL Server 2008, hat im letzten Jahr in seinem Blog eine kleine Blog-Serie gestartet, in der er erklärt, wie man Mapnik zusammen mit dem SQL Server verwenden kann. Mapnik ist ein Open Source Renderer der unter anderem vom freien Geodaten Projekt OpenStreetMap verwendet wird.

Leider gab es zum Zeitpunkt seines ersten Beitrags noch einige Probleme mit der damaligen Mapnik Version unter Windows, wodurch Alastair zu MapServer gewechselt ist.

Da ich den Einstieg äußerst interessant fand und Mapnik in der Version 2.0 eine bessere Unterstützung für Windows und den SQL Server bietet, möchte ich in diesem Blog-Beitrag das Rendern mit der aktuellen Mapnik Version 2.0.1 RC0 dann doch noch einmal detaillierter beschreiben. Der Beitrag ist jedoch auch mehr als Einstieg zu verstehen, viele Tutorials und detaillierte Informationen sind im Mapnik Wiki sehr gut erklärt und würden den Rahmen eines Beitrages erheblich sprengen.

Installation

Die Installation von Mapnik unter Windows ist in der aktuellen Version recht einfach und sehr gut auf der Seite Windows binaries (Release Candidate 0) erklärt. Neben den Windows binaries wird Python in der Version 2.7 (32-Bit) benötigt.

Nachdem beides heruntergeladen und installiert bzw. in das Verzeichnis C:\mapnik-2.0.1rc0 entpackt wurde, müssen noch die folgenden Pfad-Angaben hinzugefügt werden:

set PATH=%PATH%;c:\mapnik-2.0.1rc0\lib
set PYTHONPATH=%PYTHONPATH%;c:\mapnik-2.0.1rc0\python\2.7\site-packages
set PATH=%PATH%;c:\Python27

Danach sollten sowohl alle Mapnik Bibliotheken sowie die Python Bibliotheken zur Verfügung stehen. Um die Installation zu prüfen, kann am besten die Python Demo rundemo.py aus dem Verzeichnis C:\mapnik-2.0.1rc0\demo\python ausgeführt werden.

Das Python Script sollte dann folgende Grafik in den verschiedensten Versionen generieren:

Vorbereiten der Daten

Um eigene Karten zu Rendern werden natürlich zuerst auch eigene Daten benötigt. Mapnik liefert bereits Demo Daten mit, die in dem Verzeichnis C:\mapnik-2.0.1rc0\demo\data liegen und auf denen auch die entsprechenden Demos basieren.

Ich möchte für diese Demo allerdings OSM Karten verwenden und habe mir dafür die OSM Karten von Köln als ShapeFile heruntergeladen. Die Karten werden täglich neu von der Geofabrik angeboten. In den zur Verfügung gestellt Daten stehen für unterschiedliche Objekte der Karte einzelne ShapeFiles zur Verfügung. So existieren die ShapeFiles Buildings, Landuse, Natural, Places, Points, Railways, Roads und Waterways.

Um die ShapeFiles in den SQL Server zu laden, können entweder die SQL Server 2008 Spatial Tools von Morten Nielsen verwendet werden, oder meine SSIS ShapeFileSource von Codeplex. Die Spatial Tools sind normalerweise die einfacher Lösung, da hier die Daten ohne weitere Schritte in den SQL Server importiert werden können. Aus einem mir derzeit nicht bekannten Grund funktionieren die Tools aber nicht immer mit alle ShapeFiles und/oder Zielen, weswegen ich in diesem Fall auf meinen SSIS Task zurückgreife…was mir im Endeffekt dann doch auch mehr Spaß macht!

Ein Beispiel SSIS Paket kann hier heruntergeladen werden: Cologne.dtsx

Das Python-Scripts

Um auf den SQL Server zuzugreifen werden in Mapnik sogenannte Layer verwendet, die über OGR Library und den XML basierten Treiber OGR Virtual Format dargestellt werden. Für jede Abfrage muss ein eigener Layer in Form einer Datei (OVF) erstellt werden. Für die Demo-Karte werde ich mich hier nur auf Strassen und Buildings konzentrieren.

Neben dem Connection String wird in einer OVF Datei auch der SQL Befehl sowie verschiedene Zuordnung definiert. Zum einen muss die Spalte mit den Geodaten als GeometryField angegeben werden, zum anderen müssen die Felder, die später im Python Script verwendet werden definiert werden. Da Mapnik nicht direkt mit den Geometry Daten des SQL Server umgehen kann, werden die Daten als Text geladen und entsprechend als WKT definiert.

        1: <OGRVRTDataSource>

       2:  

       3:     <OGRVRTLayer name="Roads">

       4:     

       5:         <SrcDataSource>MSSQL:server=localhost;Initial Catalog=Cologne;Integrated Security=SSPI;</SrcDataSource>

       6:         <SrcLayer>Roads</SrcLayer>

       7:         <SrcSQL>SELECT [name], [type], [ref], [points].STAsText() AS geom FROM [Cologne].[dbo].[Roads]</SrcSQL>

       8:         <GeometryField encoding="WKT" field="geom"/>

       9:         <Field name="name" type="String" src="name" />

      10:         <Field name="type" type="String" src="type" />

      11:         <Field name="ref" type="String" src="ref" />

      12:     

      13:     </OGRVRTLayer>

      14:  

      15: </OGRVRTDataSource>

Nachdem die einzelnen OVF-Dateien für alle zu verwendeten Layer erstellt worden sind, kann das eigentliche Python Script erstellt werden.

Ein sehr gutes Tutorial für die ersten Gehversuche ist Getting started in Python aus dem Mapnik Wiki. Anstatt jedoch wie in dem Tutorial beschrieben direkt auf das ShapeFile zuzugreifen

ds = mapnik.Shapefile(file='ne_110m_admin_0_countries.shp')

muss die Datenquelle hier auf die OVF Datei verweisen

ds = mapnik.Ogr(file='roads.ovf',layer="roads")

Wobei roads.ovf die entsprechende Datei ist und roads der darin definierte Layer.

Das Zeichnen der einzelnen Objekte ist eigentlich nicht sonderlich schwierig, eine genaue Erläuterung sprengt dann aber doch wie bereits erwähnt diesen Blog-Beitrag. Wer sich intensiver mit dem Zeichnen einzelner Objekte beschäftigen möchte, sollte sich unbedingt auch die Beispiel-Dateien aus dem Mapnik Installations-Verzeichnis anschauen.

Ich möchte allerdings noch auf 2 Punkte hinweisen, die mir beim erstellen einer Karte als wichtig erschienen sind.

Layer

Mapnik arbeitet grundlegend mit Layern. Das heißt alle Objekte werden als Layer über einander gelegt und “überzeichnen” damit auch den drunter liegenden Layer. Hierdurch muss man sich die Reihenfolge der Layer recht genau überlegen.

Liegen zum Beispiel kleinere Straßen über größere Straßen, werden diese durch die größere Straße durchgezeichnet, dies sieht in einer Karte recht unschön aus.

Möchte man eine Straße zweifarbig bzw. mit einem Rahmen darstellen, wie es bei größeren Straßen häufig der Fall ist, so macht man sich dieses Verhalten jedoch zu nutzen. Hier wird zuerst z.B. eine dickere Straße in grau gezeichnet und danach die gleiche Straße dünner in Gelb. Diese Darstellung lässt sich in der obigen Beispiel Karte bei dem gelben Hauptstraßen recht gut erkennen.

Filter

In der OVF Datei wird eine Tabelle oder Abfrage definiert um die Daten zu Laden, die in der Karte dargestellt werden sollen. In den OSM Daten haben Straßen einen Typ, der definiert ob es sich um eine Autobahn, eine Hauptstraße, einen Fußgängerweg usw. handelt. Sollen diese Straßen in unterschiedlichen Farben in der Karte dargestellt werden, so sollte man jedoch nicht für jeden Straßentyp eine eigene OVF Datei erstellen. Innerhalb des Python Scripts kann ein Filter für einen einzelnen Layer definiert werden, der an dieser Stelle besser verwendet werden sollte.

roads1_rule_1.filter = mapnik.Expression("[type] = 'primary'")

Durch diesen Filter werden z.B. nur die Daten im Layer dargestellt, die dem Filter [type] = 'primary' entsprechen. So können Layer für alle verschiedenen Straßentypen auf Basis einer Datenquelle erstellt werden. Wichtig, das Feld, auf das durch den Filter zugegriffen werden soll, muss zuvor in der OVF Datei über den Parameter Field definiert werden.

Wie man an der obigen Karte sieht, lassen sich so sehr nette Karten erzeugen. Die genaue Farbgestaltung, die Filterung der einzelnen Straßen, Gebäude, Plätze usw. ist jedoch eine ziemliche Detailarbeit. Das Zeichnen einer Karte mit vielen Layern kann schon ein paar Minuten dauern; bei einer zu großen Karte (Abmessung und Anzahl der Layer) kam es auf meinem Notebook auch zu Speicherproblemen.

Leider konnte ich in der OVF Datei in den Abfragen keine < oder > Zeichen verwenden. Um nur Daten zu selektieren die in einem definierten Umkreis eines Objektes, hier das Odysseum in Köln, liegen, musste ich also jeweils eine Sicht für Roads und Buildings erstellen.

   1: SELECT     dbo.Buildings.*

   2: FROM         dbo.Buildings

   3: WHERE Points.STDistance(

   4:     (SELECT POINTS FROM Buildings WHERE [Name] LIKE '%Odysseum%')

   5:     ) < 0.005

Anstatt der bisherigen Tabelle Roads greife ich über die OVF Datei dann auf die entsprechende Sicht zu. So entsteht zum Beispiel die folgende – noch nicht wirklich hübsche - Karte.

SQL Server Launch 2012 – Noch 1 Tag

Till — Sat, 25 Feb 2012 23:30:00 +0100

Am Montag startet nun die erste Deutsche Microsoft SQL Server Konferenz, die sowohl vom 27.02.2012 bis zum 28.02.2012 wie auch mit dem zusätzlichen Essentials Tag am 29.02.2012 stattfindet.

Die vollständigen Informationen zu dem Event sind auf der Konferenz-Seite von Microsoft zu finden. Hier ist nun auch seit einigen Tagen die (voraussichtlich) endgültige Agenda veröffentlicht. Sowohl die Konferenz am Montag und Dienstag wie auch der zusätzlich geschaffene Essentials Tag sind mittlerweile allerdings vollständig ausgebucht.

Die PASS wird natürlich auf der Konferenz - wie auch Microsoft und einige andere Partner – mit einem eigenen Stand vertreten sein und freut sich über einen regen Austausch und Diskussionen mit anderen Mitglieder aus der Community und jedem der sich über den SQL Server informieren möchte.

Wer es leider nicht geschafft hat sich ein Ticket zu ergattern, aber dennoch wissen möchte, was auf der Konferenz an spannenden Themen erzählt wird, der kann am besten die verschiedenen Kanäle der PASS im Auge behalten.

Wie auch schon zum PASS Summit 2011 werden wieder einige PASS’ler von den Vorträgen berichten und zwitschern, als offiziellen Hashtag für die Konferenz ist #sqlconfde vorgesehen.

Microsoft SQL Server 2012 Integration Services - Data Taps

Till — Thu, 23 Feb 2012 23:08:00 +0100

Mit dem Release der SQL Server 2012 Integration Services kommen nicht nur neue Funktionen, einige bestehende Funktionen mussten leider auch gehen. Um Daten innerhalb des Datenflusses schnell zu visualisieren gibt es in den SSIS 2005 und 2008 Data Viewers, die einem Datenfluss-Pfad hinzugefügt werden können.

Hier konnten die Ergebnisse in einem Grid ausgegeben oder auch in Form verschiedener Grafiken dargestellt werden. Dazu boten die Integration Services bisher Histogramme, Scatter Plot (x,y) oder einen einfachen Column Chart an. Ich habe - speziell die Column Charts - in einigen Projekten während der Entwicklung zu Debugging-Zwecken eingesetzt, habe aber auch in dem ein oder anderen Vortrag feststellen müssen, dass im Allgemeinen die Visualisierung der Daten in einem Diagramm nicht sehr häufig verwendet wurde.

In die SSIS 2012 haben es die Data Viewer Charts nicht mehr geschafft, so dass über den Datenfluss-Pfad die Daten nur noch in einem Grid (rechtes Bild) dargestellt werden können.

Hinzugekommen in den SQL Server 2012 Integration Services sind die sogenannten Data Taps, die jedoch nicht als Ersatz für die zuvor beschriebenen Data Viewer Charts zu verstehen sind. Bei den Data Taps handelt es sich vielmehr um eine Ergänzung/Erweiterung der bestehenden Debugging-Möglichkeiten innerhalb des Datenflusses und sind eher die persistierte Version des Data Viewer. Mit den Data Taps wird den Entwicklern z.B. in Produktivumgebungen, in denen normalerweise kein direkter Zugriff auf die SSIS-Pakete und somit auf den Datenfluss besteht, endlich eine Analysemöglichkeit in die Hand gegeben, mit denen einzelne Ausgaben innerhalb des Datenflusses überprüft werden können. Hierzu können während der Laufzeit eines Paketes eine Kopie der Daten eines speziellen Datenfluss-Pfad als CSV-Datei gespeichert werden.

Grundinformationen über das Paket

Im Folgenden möchte ich in mit Hilfe eines kleinen Demo Paketes zeigen, wie Data Taps eingerichtet und verwendet werden können. Das Demo-Paket lädt Daten aus der AdventureWorks Datenbank, fügt dann eine Spalte mit Daten über den Task “Transformation” hinzu und speichert die Daten wieder auf dem SQL Server.

Um Data Taps einzurichten werden ein paar Informationen über das SSIS-Paket benötigt:

Folder Name
Der Name des Ordners in dem das SSIS Paket welches ausgeführt werden soll gespeichert wurde. Der Name des Paketes ist ein nvarchar(128).

Project Name
Der Name des SSIS Projektes welches das Paket das ausgeführt werden soll enthält. Der Name des Projektes ist ein nvarchar(128).

Package Name
Der Name des SSIS-Paketes das ausgeführt werden soll. Der Name des Paketes ist ein nvarchar(128).

Data Flow Path Identification String
Der Identification String, der den Datenfluss-Pfad innerhalb des SSIS Paketes definiert. Der Identification String wird nicht über den Datenfluss-Pfad selber definiert, sondern durch die ihm vorgelagerte Komponente. Bei einer “OLEDB Source” oder einer “Abgleiteten Spalte” kann dieser z.B. über den “Erweiterten Editor” angepasst werden.

Data Flow Package Path

Der Pfad innerhalb des Paketes auf das man sich bezieht. Normalerweise der Paketname gefolgt vom Name des Datenfluss Task, z.B. “\Package\DataFlowTask_001”. Der Pfad ändert sich durch das Anpassen von Paket- oder Task-Namen innerhalb des Paketes

Gespeicherte Prozeduren im SSIS Catalog

Sobald die Grundinformationen über das Paket bereit stehen, können die Data Taps dem Paket hinzugefügt und konfiguriert werden. Hierfür existieren verschiedene gespeicherten Prozeduren, die fester Bestandteil des SSIS Catalogs sind. An dieser Stelle sind für die Demo die Prozeduren [catalog].[create_execution] und [catalog].[add_data_tap] sowie die Prozedur [catalog].[start_execution] für die eigentlich Ausführung des Paketes wichtig.

Als erstes wird mit der Prozedur [catalog].[create_execution] eine Instanz einer Ausführung erstellt:

EXEC [catalog].[create_execution]        
@folder_name = N'Demo',
@project_name = N'DataTaps',
@package_name = N'Package.dtsx',
@execution_id = @execution_id OUTPUT

Über die gespeicherte Prozedure kann zusätzlich auch definiert werden ob die 32-Bit Runtime bei der Ausführung verwendet werden soll. Alle Ausführungen die erstellt worden sind, können über die Sicht [catalog].[executions] ausgegeben werden. Eine Instanz einer Ausführung kann grundsätzlich nur einmal gestartet werden.

Danach wird über die gespeicherte Prozedur [catalog].[add_data_tap] zu dieser Ausführung ein Data Tap hinzugefügt:

EXEC [catalog].[add_data_tap]        
@execution_id = @execution_id,        
@task_package_path = N'\Package\Produkte',        
@dataflow_path_id_string = N'Paths[Produkte.Quelle]',        
@data_filename = N'OriginalDaten.csv',        
@data_tap_id = @data_tap_id OUTPUT

Bei dieser Prozedur kann über den Parameter @max_rows zusätzlich auch noch die Anzahl an auszugebenden Datensätzen definiert werden. Wird der Parameter nicht angegeben, wird MaRows automatisch auf –1 gesetzt und gibt somit alle Datensätze aus, die durch den Pfad “fließen”.

Mit der gespeicherten Prozedur [catalog].[start_execution] kann dann die entsprechende Execution ausgeführt werden:

EXEC [catalog].[start_execution] @execution_id

Die Ausgabe findet grundsätzlich als CSV Datei statt. Die entsprechende Datei ist nach erfolgreicher Ausführung im Verzeichnis

C:\Program Files\Microsoft SQL Server\110\DTS\DataDumps

zu finden.

Alle DataTaps, sowohl von bereits ausgeführten wie auch von noch nicht ausgeführten Ausführung können über die Sicht [catalog].[execution_data_taps] abgerufen werden. Über diese Sicht gelangt man auch an die data_tap_id, welche wiederum benötigt wird, wenn man ein Data Tap mit Hilfe der Prozedur [catalog].[remove_data_tap] wieder löschen möchte.

Weitere Informationen zu Data Taps und dem SSIS Catalog sind natürlich in der MSDN zu finden:

Views (Integration Services Catalog)

Stored Procedures (Integration Services Catalog)

SSIS GoogleAnalyticsSource & ReportGeneratorTask

Till — Wed, 22 Feb 2012 23:46:00 +0100

In den letzten Wochen sind einige Bugs und Kommentare zu der SSIS GoogleAnalyticsSource Komponente bei Codeplex gepostet worden.

Ich bin aktuell dabei eine neue Version der Komponente zu planen und hoffe diese Ende März, Anfang April zu veröffentlichen.

Ein wesentlicher Punkt für die neue Version wird die Integration der geänderten Google API sein, so wie sie derzeit häufig im Forum gefordert wird. Zusätzlich werde ich mit dem nächsten Update die Komponente auch als SQL Server 2012 Komponente veröffentlichen. Hinzu kommen auch noch einige kleinere Änderungen und Bugs.

Ich würde mich freuen, wenn bis dahin das Forum oder der Issue Tracker weiterhin stark genutzt werden um möglichst viele Anmerkungen und Wünsche für das neue Release zu erhalten.

Ebenso in Planung ist eine neue Version des ReportGeneratorTask, bei dem ich endlich die SQL Server 2012 Version bei Codeplex veröffentlichen möchte. Derzeit steht diese nur als MSI-File hier in meinem Blog als Download zur Verfügung. Eine der zusätzlichen Änderung in der nächsten Version wird eine verbesserte Anpassung der ReportParameter sein.

Auch hier würde ich mich freuen, wenn Fehler oder neue Features Ihren Weg in die entsprechenden Tools (Discussions/Issue Tracker) bei Codeplex finden.

Treffen der Regionalgruppe Köln/Bonn/Düsseldorf am 16.01.2012

Till — Wed, 11 Jan 2012 18:43:10 +0100

Unser erstes Treffen in 2012 findet wieder bei Microsoft in Köln statt. Wir starten am Montag um 18:00 Uhr, die Vorträge gehen bis ca. 21:00 Uhr.

Weitere Informationen zu der Veranstaltung sind wie immer auch auf der Seite der Regionalgruppe Köln/Bonn/Düsseldorf zu finden.

Bitte meldet euch auch über die Seite bei uns zu dem Treffen an.

HP Enterprise Database Consolidation Appliance - Christoph Muthmann (SQL Server MVP)

Im Oktober haben Microsoft und HP auf dem PASS Summit eine neue Maschine vorgestellt, die sie gemeinsam für die Konsolidierung von Datenbanken in der "Private Cloud" konzipiert haben. Ein Konzept dazu war schon vorher öffentlich verfügbar, nun gibt es sie auch schlüsselfertig.
Der Vortrag gibt einen kurzen Einblick in diese Technologie und beleuchtet diese abschliessend im Hinblick auf die neue Lizenzpolitik für den SQL Server 2012.

Christoph Muthmann ist seit 20 Jahren mit dem Design und der Administration von Datenbanken beschäftigt. Seit 17 Jahren arbeitet er für den "Verband der Vereine Creditreform" in Neuss im Bereich der Betreuung und Weiterentwicklung der Datenbanken auf Oracle, iSeries und SQL Server. Sein Schwerpunkt ist die Weiterentwicklung und Administration der SQL Server mit über 400 Datenbanken, welche er seit ca. 12 Jahren, beginnend mit der Version 6.5 betreut. Seit 2008 ist er SQL Server MVP und berichtet über SQL Server und PASS in seinem Blog auf insidesql.org.

The Practitioner’s Guide to Data Profiling - Tillmann Eitelberg

In diesem Vortrag werden die Grundlagen und Methoden eines Data Profiling erklärt. Dabei wird gezeigt welche Möglichkeiten Microsoft seit der Version 2008 mit den SQL Server Integration Services bietet und welche Neuerungen in diesem Bereich mit den Data Quality Services kommen. Ein gutes Data Profiling gehört mit zu den wichtigsten Aufgaben für praktisch jedes datenbasiertes Programm oder Projekt, ob Datenqualitätsprüfungen und/oder -validierungen, Master Data Management, ETL-Prozessen, Datenmigration oder der Modernisierung bestehender Applikationen. Am Ende des Vortrags wird kurz die aktuelle Beta Version der SSIS Komponente datenfabrik.profiler vorgestellt.

Tillmann Eitelberg ist Prokurist der datenfabrik GmbH & Co. KG, die sich auf Datenintegrations- und Datenqualitätslösungen mit dem Microsoft SQL Server spezialisiert hat. Er beschäftigt sich mit dem SQL Server seit der Version 2000 und seit über 8 Jahren mit dem Thema Datenintegration, zuerst mit den Data Transformation Services und nun mit den Integration Services. Sein Blog sowie einige Open Source Projekte sind unter www.ssis-components.net zu finden. Tillmann unterstützt den PASS Deutschland e.V. im Vorstand und als RGV für die Regionalgruppe Köln/Bonn/Düsseldorf.

Das Treffen findet wieder bei Microsoft in Köln statt.

Microsoft Deutschland GmbH
Geschäftsstelle Köln
Holzmarkt 2a
50676 Köln

Wie üblich bitten wir um vorherige Anmeldung, sämtliche Kontaktinformationen sind auf der Seite der Regionalgruppe zu finden.

Microsoft “Data Explorer”

till — Wed, 28 Dec 2011 12:17:15 +0100

Vor ein paar Wochen hat Microsoft einem ersten Benutzerkreis Zugang zu ihrem neuen “Data Explorer” Cloud Service gewährt. Am 13.12. wurde der SQL Azure Labs Codename “Data Explorer” Client in einer öffentlichen Variante nachgelegt.

Der “Data Explorer” ist eine Anwendung, mit der Daten aus verschiedenen Daten geladen, konvertiert, angereichert und wieder ausgegeben werden können. Wer jetzt an ein ETL Tool denkt, der liegt meiner Ansicht nach eigentlich gar nicht so verkehrt. Jedoch handelt es sich bei dem “Data Explorer” nicht um eine komplexe “Workflow-Engine” mit der vollständig automatisierte Prozesse inkl. Fehlerbehandlung usw. aufgesetzt werden können, sondern eher um ein Programm, das zum bearbeiten und verarbeiten einzelner, gezielter Datenquellen dient.

Mit dem Data Explorer werden sogenannte Mashups erstellt, die Daten aus den verschiedensten Quellen konsumieren können. Hierzu gehören SQL Datenquellen, Web-Seiten, Data Feeds, Sharepoint Listen, der Windows Azure Marketplace, verschiedene Dateien wie Excel oder CSV, Data Explorer Mashups, die direkte Texteingabe oder Daten die über Formeln generiert und geladen werden. Dateien können nicht nur vollständig importiert werden, sondern es kann auf diese auch verlinkt werden, wodurch dann auch Änderungen aus den Quellen übernommen werden.

Der “Data Explorer” besitzt eine Vielzahl von Funktionen, mit denen die Daten verarbeitet werden können, derzeit sind diese in die Kategorien “Filter”, “Order”, “Column Names” und “Transform” gruppiert. Hierunter befinden sich z.B. Funktionen wie Umbenennen, Löschen von Zeilen oder Spalten, Zusammenführen oder Trennen von Spalten oder auch z.B. eine Funktion namens “Fill Down”, mit der NULL Werte in einer Spalte mit einem speziellen Wert aufgefüllt werden können.

Sehr nett finde ich die Verwendung der aus dem Web bekannten “Breadcrumbs” als Navigation für die Verarbeitungshistorie der Daten.

Der Anwender kann über diese Breadcrumbs an jede beliebige Stelle innerhalb der einzelnen Schritte zurückspringen oder einzelne Verarbeitungsschritte löschen.

Die mit dem Client erstellten Daten können derzeit nur als “.import”-Datei gespeichert werden, einem Austauschformat zwischen den Clients oder der Azure Version. Mit der Installation des Clients wird aber auch ein Excel Plugin installiert, mit dem Daten direkt aus den Workspaces des lokalen Data Explorers in Excel importiert werden können. Über die Azure-Version können Mashups auch online publiziert werden. Die so publizierten Mashups stehen als OData Feed zur Verfügung oder können direkt als Excel und CSV Datei heruntergeladen werden.

Allgemein finde ich den Data Explorer einen sehr guten Ansatz um Daten aufzubereiten. Speziell die Möglichkeit Daten über die integrierte Formula Language zu laden bietet einem umfangreiche Möglichkeiten. Derzeit reagiert die Client Version leider noch ein bisschen träge.

Auf der Seite Learn More about Microsoft Codename "Data Explorer" hat Microsoft umfangreiche Videos zur Verfügung gestellt, die einen sehr guten Einblick in das Programm liefern. Jamie Thomson hat in seinem Blog mit Data Explorer walkthrough – Parsing a Twitter list und Querying RSS feed subscriber count on Google Reader using Data Explorer‏ auch zwei sehr gute Artikel veröffentlicht, die intensiver auf die integrierte Formula Language eingehen.

/n Software Christmas Promo

till — Thu, 22 Dec 2011 23:52:24 +0100

Die Firma /n Software hat pünktlich zu Weihnachten ein kleine Promoaktion gestartet.

Unter http://www.nsoftware.com/promo/xmas/ kann man sich bis zum 31.12.2011 eine Single CPU Server License der /n Software SSIS Tasks sichern, für mehr Kerne gibt es in diesem Zeitraum 50% Rabatt. In der Suite von /n Software sind unter anderem Tasks für FTP, SFTP, SNPP, XMPP, S3, ZIP und GZIP enthalten.

Da bleibt mir nur noch zu sagen: Frohe Weihnachten!

SSRS und Spatial Data–zu genau produziert Fehler

Till — Sat, 19 Nov 2011 11:00:00 +0100

Bei der Erstellung eines SQL Server Reports mit einer Weltkarte kam es bei mir die Tage leider immer wieder zu folgenden Fehlermeldungen:

Erst später ist mir bewusst geworden, das der Report mit meiner eingebetteten Weltkarte eine Größe von ca. 10 MB hat.

Der Fehler an dieser Stelle ist eigentlich bekannt und auch eigentlich kein direkter Fehler, erst recht nicht der der SQL Server Reporting Services. ASP.NET Anwendungen sind prinzipiell so konfiguriert, dass nur Dateien mit einer max. Größe von 4MB (28 MB im IIS 7) auf den Server übertragen werden können. Die Einstellung selber lässt sich durch Anpassungen an der web.config beheben, jedoch wird hiervon im Rahmen von Security Best Practices abgeraten.

Das Problem liegt aber eigentlich an den Shape-Dateien. Möchte ich nämlich folgenden Report darstellen

so beinhalten die Daten auch die folgende Informationen:

Ähnliche detaillierte Daten sind auch in der oberen Region von Canada oder an der Küste von Chile zu finden. Diese Menge an Daten, die wahrscheinlich für die meisten Anwender und einer einfachen Darstellung der Erde viel zu komplex sind, sind primär dafür zuständig, dass die Daten nicht auf den Server geladen werden können.

Eine Möglichkeit den Report kleiner zu bekommen, ist den ShapeFile inkl. der DBF Datei auf einen ReportServer zu laden, jedoch gilt auch hier die oben angesprochene Größenbeschränkung und hilft damit nicht wirklich weiter.

Eine weitere Möglichkeit die Größe des Reports zu verkleinern ist alle nicht benötigten Daten zu entfernen. Hiermit meine ich im ersten Moment Daten aus der zum ShapeFile gehörenden dbase Datei. Hier werden häufig viele Felder mitgeliefert die später nicht im Bericht verwendet und/oder angezeigt werden.

Eine weitere Möglichkeit den Bericht bzw. die Datenmengen zu verkleinern, ist es die ShapeFiles direkt im BIDS oder im Report Builder zu bearbeiten und nicht benötigte Polygone zu löschen.

Zumindest bei meiner Weltkarte sind jedoch beide Methoden nicht ausreichend um die Daten so zu reduzieren, dass der Bericht auf dem Server gespeichert werden kann. Und dabei würden meine “neuen” Karten mit Sicherheit noch nicht einmal jedem so gut gefallen.

Grundsätzlich kann man an der Stelle sagen, die Daten nicht im Report zu speichern sondern diese dynamisch - wie oben angesprochen - aus einem ShapeFile oder von einem SQL Server zu laden ist wesentlich besser.

Hier zeichnet sich natürlich der Vorteil des SQL Servers gegenüber den ShapeFiles ab, da ich keiner direkten Größenbeschränkung unterliege. Habe ich meine Spatial Data im SQL Server gespeichert und nicht im Bericht eingebettet, so kommt meiner Beispielreport auf gerade einmal 20 KB.

Möchte ich Daten aber dennoch in meinem Bericht einbetten, so kann ich die einmal aus dem SQL Server geladenen Daten ganz einfach per Maus-Click wieder in meinen Bericht einbetten, womit der Bericht dann allerdings nur noch ca. 450 KB groß wird. Beim Einbetten der Daten wird nur der sichtbare Bereich der Daten eingebettet und dabei die Daten drastisch reduziert. Hat alleine Chile mit der stark zerklüfteten Küste aus dem ShapeFile heraus noch eine Größe von knapp 400 KB, so kommt das Land beim Einbetten der Daten aus dem SQL Server nur noch auf knapp 8 KB, die oben im Screenshot dargestellte Vergrößerung der Falklandinseln spart über 30 KB. Zu finden sind die entsprechenden Daten im übrigen jeweils in der RDL-Datei unter <VectorData>, im den darauf folgenden Tags <MapFields> sind auch die aus der DBF zugeordneten Daten wiederzufinden.

Um ShapeFiles in den SQL Server zu Laden kann man meine SSIS ShapeFileSource oder das Programm Shape2SQL von Morten Nielsen verwenden.

Nützliche Informationen zum Download von Spatial Data findet sich in meinem Blog Beitrag Geodaten – Teil 1 oder auch im Blog Beitrag “Addresses for geographical Data, ESRI-Shapefiles and other SQL Server geographical related stuff” meines PASS RGV Kollegen Andreas Wolter.

SQL Server "Denali" Data Quality Services – Teil 1

Till — Fri, 11 Nov 2011 15:40:00 +0100

Nun hab ich endlich mal ein bisschen Zeit gefunden, um mich mit den Data Quality Services aus der aktuellen SQL Server “Denali” CTP3 zu beschäftigen und werde dazu (hoffentlich) in den nächsten Tagen weitere Beiträge veröffentlichen können. Der erste Teil enthält einen kleinen Überblick zu den DQS zusammen mit ein paar Tipps zur Installation.

DQS - von Microsoft als “knowledge-driven data cleansing solution” bezeichnet – ermöglicht die Bereinigung und Deduplizierung von Daten. Dafür kann entweder eine der mit ausgelieferten Knowledge Base verwendet oder ein eigene Knowledge Base angelegt werden. Eine entsprechende KB ist in anderen Projekten wiederverwendbar.

Mit der CTP3 wurden die DQS zum ersten mal öffentlich zur Verfügung gestellt. Ein Vorversion stand schon im Rahmen der CTP2 einem ausgewählten Benutzerkreis zur Verfügung.

Im SQL Server Team Blog findet sich der Artikel New and Exciting in SQL Server Code Name “Denali”: Knowledge Driven Data Quality Services (DQS) inkl. eines Videos von David Faibush (Senior Programm Manager des Data Quality Services Team), in dem er ein bisschen auf die Vorteile der Lösung eingeht.

Data Quality Services–What’s new in SQL Server Denali

Installation

Die Installation der DQS im Denali erfolgt über den Standard Installations-Wizard.
Nach der Installation muss derzeit jedoch noch ein zusätzliches Installation Script über die Anwendung “DQSInstaller.exe” ausgeführt werden, mit dem die entsprechende Datenbanken und Rollen angelegt werden. Die entsprechende Datei befindet sich im Verzeichnis C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\Binn.

Eine genaue Installationsanleitung ist in der MSDN zu finden.

Aufpassen muss man jedoch ein bisschen bei der Installation des SQL Server. Aktuell lädt das Setup des SQL Server “Denali” während der Installation standardmäßig zwei Produkt-Updates herunter. Das entsprechende Update kann während der Ausführung des Installationsscriptes “DQSInstaller.exe” zu einem Fehler führen, so dass die Installation nicht erfolgreich beendet werden kann. Nach Möglichkeit sollte dieses Update/Hotfix also nicht mitinstalliert werden.

Ist das Update bereits installiert, muss über das Windows Update der HotFix 1515 für SQL Server deinstalliert werden, um eine erfolgreiche Installation zu gewährleisten. Dieses Problem und die dazugehörige Lösung ist recht gut im innerhalb des Microsoft Forums SQL Server "Denali" Data Quality Services (Pre-Release) erklärt.

Sind die DQS erfolgreich installiert worden, so kann man sich über einen der durch das SQL Server Setup installierten Clients (x86/x64) mit den DQS verbinden.

Spielt man mit den DQS Client ein bisschen herum, so kommt man bei der CTP3 unter umständen an einem Punkt folgende Fehlermeldung angezeigt, obwohl der DQS Client vorher Daten aus der Datenbank laden konnte:

Um dieses Fehler zu beheben, muss den beiden SQL Server Logins ##MS_dqs_db_owner_login## und ##MS_dqs_service_login## Zugriff auf die jeweiligen Schemata in der Datenbank gewährt werden, dies sind bei der AdventureWorks200R2 z.B. HumanResources, Person, Production, Purchasing und Sales.

Falls weitere Fehler beim Anmelden and die DQS auftreten, so kann dies auch mit einigen .NET Updates zusammenhängen. In diesem Fall sollte man dann noch einmal einen Blick auf die Microsoft SQL Server Code-Named "Denali" CTP3 Release Notes, speziell auf den Bereich 4.23 Some .NET Framework 4 Updates Might Cause DQS to Fail, werfen. Diese Fehler können auch später durch Updates nach einer bereits erfolgreichen Installation und einem ersten Testing auftreten

Weitere Ressourcen zum Thema DQS:

Data Profiling - Teil 4 – Monitoring und Alerts

Till — Wed, 09 Nov 2011 16:00:00 +0100

Im Rahmen des Data Quality Lifecycles den wir mit unseren “Data Quality Components for SQL Server Integration Services” unterstützen, adressieren wir mit dem datenfabrik.profiler die beiden Zyklen Profiling und Monitoring.

Welchen Funktionsumfang wir für den Zyklus Profiling bieten, habe ich zum Teil in dem Data Profiling – Teil 3 aufgezeigt. Den Monitoring Zyklus unterstützen wir mit einigen weiteren Funktionen.

Statistics Save Mode

Im Repository können die Daten des Profiling historisiert gespeichert werden, wodurch die Qualität der geladenen Daten durchgehend überprüft werden kann. Hierfür bietet der datenfabrik.profiler zwei unterschiedliche Speicher-Modi an. Die jeweils mit dem SSIS Paket geladenen und verarbeiteten Daten können bei jeder Ausfürhung vollständig gespeichert werden (Version Control) oder die Daten werden über den den Speicher-Modus “Update existing statistics” mit den jeweils neuen Ergebnisse aktualisiert. Dieser Speichermodus eignet sich insbesondere für inkrementelle Ladeprozesse, bei denen man nicht die einzelnen Ausführungen dediziert überwachen möchte, sondern eine Analyse über die gesamten Informationen zu dem jeweiligen Zeitpunkt eines Ladeprozess benötigt.

Sämtliche Ergebnisse werden im Repository gespeichert und können nachträglich immer wieder analysiert werden. Hierdurch können auch Trends innerhalb der Daten erfasst werden.

Ein dritter existierender Speichermodus “Overwrite existing statistics” speichert die Daten nicht historisiert, sondern jeweils nur die letzte Ausführung.

Alerts

Eine weitere Funktion die das Monitoring innerhalb des datenfabrik.profiler unterstützt, sind die sogenannten Alerts. Über diese Alerts können die Ergebnisse einzelner Regeln auf Spaltenebene überwacht werden. Wenn das Ergebnis im Rahmen eines Alerts über- oder unterschritten wird und nicht gleich dem voreingestellten Wert ist, so wird ein Alarm erzeugt. Die zu prüfenden Werte können dabei absolut oder prozentual sein.

Es werden derzeit insgesamt 3 Alert Types unterstützt (Management Log, Email und SSIS Compopnent) und drei verschiedene Satus (Information, Warning, Error).

Wird ein Staus an die SSIS Komponente weitergereicht, so erscheint das Ergebnis im Status Log innerhalb der Paketausführung, im Falle eines Errors wird das Paket dadurch auch abgebrochen. Mit Hilfe der Alerts können die zu ladenden Daten also sehr detailliert überwacht werden und im Zweifelsfall kann sogar der Import oder die Weiterverarbeitung der Daten gestoppt werden.