Wie schon im Vorjahr gibt es ein spezielles Angebot für Mitglieder von PASS Deutschland. Diese erhalten auf den jeweils gerade gültigen Preis noch einmal einen Rabatt von 10%. Bis 30.06.2012 ist der Very Early Bird: 690,00 Euro(exkl. MwSt.) gültig. Der Preis für PASS Deutschland Mitglieder beträgt also nur 621,00 Euro (exkl. MwSt.) für drei Tage volles Programm.

Lasst uns über Dokumentation in Projekten und beim späteren Betrieb der Lösung sprechen. Hey, jetzt nicht gleich umschalten. :-)

Über Dokumentation spricht keiner gerne. Sie hat den Ruf, dass das Erstellen meist im Weg steht und als lästige Pflicht gesehen wird. Klar wird jeder sofort den Nutzen einer Dokumentation nicht in Frage stellen wollen, dennoch ist sie das Stiefkind vieler Projekte.

Woran liegt das?

Meine These dazu ist, dass das Dokumentieren von Lösungen als so unangenehm wahrgenommen wird, weil vielen einfach nicht immer wirklich klar ist, was denn nun wie dokumentiert werden muss. Vorlagen existieren meist nur bei großen Organisationsstrukturen wie Konzernen und Behörden oder zertifizierten Spezialisten und oft sind diese Vorlagen dann doch nicht mit der Praxis wirklich kompatibel und führen zu mehr Verwirrung als, dass sie helfen. Es kommt Ende meist wieder auf die Kreativität des Einzelnen an.

Natürlich gibt es noch das Versprechen der Dokumentationsgeneratoren. Auch ich verwende gern solche automatisierten Tools, um eine Microsoft Business Intelligence Lösung zu "dokumentieren". Meist auf Basis der Analysis Management Objects entwickle ich kleine Helfer, welche dann entsprechende Repositories verwalten. Nur, ist das wirklich Dokumentation? Die gleiche Frage stellt sich mir bei vielen IT-Infrastruktur Visualisierungstools. Schicke Poster. Wo ist der konkrete Nutzen?

Stellen wir uns mal die total esoterische Frage: Was ist überhaupt der ganz konkrete Nutzen von Dokumentation ?

Hey, wer hat da gelacht?

Ich glaube, dass gerade diese Frage bzw. die Tatsache, dass sie häufig nicht spontan und konkret beantwortet werden kann, das primäre Problem bei der Erstellung einer (nützlichen) Dokumentation ist. Weil wenn immer klar wäre, was denn nun in einer Dokumentation erwartet werden würde, dann würde vielen armen Seelen die Erstellung einer solchen wesentlich leichter fallen.

Also, was ist der konkrete Nutzen einer Dokumentation? Wozu braucht man so etwas überhaupt?

Nein, so klar ist das nämlich gar nicht! Die Antwort kann nicht lauten: Um zu dokumentieren. :-)

Eine Dokumentation soll ja etwas bewirken können. Eine Wirksamkeit haben. Und zwar, wenn etwas geändert werden muss bzw. wenn etwas schief geht. Natürlich wird das nie im gerade aktuellem Projekt passieren. Also, dass jemand was ändern möchte. Später. oder dass gar etwas schief geht. Versprochen.

Nennen wir diese möglichen Einsatzzwecke einer Dokumentation doch einfach mal Risiken. Für mich sind die Folgen einer Änderung oder der Problemfall zukünftige Risiken, welche wir heute bereits verwalten müssen. Wir müssen Maßnahmen ergreifen, um diese Risiken zu minimieren. Und schwupps sind wir beim Risikomanagement angekommen.

Wie steht es bei Wikipedia so schön: "Risikomanagement umfasst sämtliche Maßnahmen zur systematischen Erkennung, Analyse, Bewertung, Überwachung und Kontrolle von Risiken."

Risikomanagement hat nichts mit Schwarzmalerei zu tun. Ganz im Gegenteil. Es ist für mich eine erstrebenswerte Form von Komfort im Projekt und auch gerade für den späteren Betrieb als auch weitere Anpassungen. Und idealerweise das alles nicht durch mich. Womit wir bei einem weiteren Risiko wären: Der ehemalige Berater ist aus welchen Gründen auch immer nicht verfügbar bzw. kann sich an nichts mehr erinnern. Welche Risiken entstehen dadurch und müssen durch welche Maßnahmen verhindert werden?

Eine verwandte Disziplin zur Dokumentation ist das sogenannte Betriebshandbuch. Hier ist der spätere Nutzen bereits im Namen dokumentiert. (Kleines Wortspiel. öhm. )

Zurück zur Dokumentation. Ich möchte hier jetzt keine x-te Vorlage für eine gute Dokumentation liefern. Vielmehr den Ansatz, dass sich bei der Planung und Erstellung einer Dokumentation erst mal bewusst gemacht werden muss, welche möglichen Risiken damit verringert bzw. verhindert werden sollen.

Beispiel. Klar soll eine Dokumentation eines Stück Codes helfen, dass er einfacher geändert werden kann. Nur das ist NICHT der eigentlich Nutzen. Der Nutzen ist, dass

a.) die Änderung schneller, einfacher und damit günstiger wird. (Risiko der Kosten)

b.) und, dass sie ohne unvorhersehbare Folgen für den Betrieb der gesamten Lösung sein wird. (Risiko der Katastrophe.)

Es ist zu einfach jetzt zu sagen, dass das doch klar ist. Vielmehr ist es so, dass gerade das Spiegeln von möglichen Risiken an den notwendigen Maßnahmen die Erstellung einer wirksamen Dokumentation deutlich vereinfacht. Des Weiteren wird die Pflege einer Dokumentation deutlich vereinfacht, weil "das Thema" klar ist. Wer kennt nicht noch die Aufsätze von früher mit dem Hinweis "Thema verfehlt."?

Jeder Teil einer wie immer gearteten Dokumentation sollte helfen Risiken zu minimieren. Da hat auch das IT-Poster seinen Sinn, da man sich schnell einen Überblick verschaffen kann (Spart Einarbeitungszeit) und das SQL Server BI Tool hilft die Details im Auge zu haben.

Also stellen sich beim Erstellen einer guten Dokumentation die Fragen nach dem WAS? und dem WIE? soll etwas dokumentiert werden, damit möglichst viele Risiken ausgeschlossen werden können.

Hoffe, dass diese paar Zeilen dem einen oder anderem helfen werden, um eine Dokumentation wirksamer und einfacher zu erstellen.

Hier die Beschreibung:
"In dieser Session werden die SQL-Server-Dienste Master Data Services und Data Quality Services im Kontext von Business-Intelligence-Projekten vorgestellt und erläutert. Es wird das Zusammenspiel von MDS und DQS mit den bekannten Diensten SSIS und SSAS anhand von Beispielen demonstriert. Des Weiteren wird der Nutzen für BI-Architekturen aufgezeigt."

Ich freue mich drauf.  

Eine Frage war, ob bei der Nutzung einer Datenvirtualisierung ein ETL / ELT Prozess damit überflüssig werden würde.

Die Antwort ist definitiv: Nein!
Warum? Eine Datenvirtualisierung ist kein Ersatz für einen ETL/ELT Prozess. Und sie ist nicht zwingend nur für diesen Business Intelligence orientierten Einsatzzwecks zu gebrauchen als Architekturpattern. Eine Datenvirtualisierung hat nur einen Zweck und zwar den Zugriff auf Datenquellen in den nachfolgenden Schichten zu vereinfachen durch das Konzept der Zentralisierung. Dabei wird darauf Wert gelegt, dass die Daten nicht physisch als Kopie vorliegen (wie zum Beispiel in einer Landing Zone) sondern auf diese "verwiesen" wird. Daher auch die Bezeichnung als "virtuell". Auch klassische Integrationslösungen wie BizTalk oder Master Data Services können davon profitieren.

Dann kam die Frage, was denn nun wiederum das Besondere wäre an der Verwendung von Linked Servern und Views. Wozu da ein Repository?

Erst mit der Nutzung eines Repositorys, welches die Meta Daten der Linked Server und Views enthält, wird für mich daraus ein valides Vorgehen. Natürlich können die Linked Server und Views auch manuell hinzugefügt und später auch gepflegt werden. Aber nur durch die Automatisierung, welche auf Basis des Repositorys möglich wird, ist diese Architekturkomponente wirklich wirksam in der Anwendung. Es entsteht ein echter Nutzen für die Gesamtumgebung.

Und dann natürlich noch der Klassiker. Wenn schon Views, warum dann nicht alles als Views implementieren? Also auch den kompletten ETL/ELT Prozess!

Die Antwort ist wieder definitiv: Nein!
Weil dann wäre ich zumindest nicht mehr bereit den Bewirtschaftungsprozess als ETL/ELT Prozess zu benennen. Dann hätten wir eine Art einfache Schnittstelle. Wenn überhaupt. Nicht dass ich jetzt falsch verstanden werde. Ich habe nichts gegen Views. Ganz im Gegenteil. Im richtigen Kontext können diese sehr nützlich sein. Ein valider ETL/ELT Prozess ist mehr als nur die Summe seiner Technologien. Damit er "überlebt" und wirksam bleibt ist auch immer ein Stück Implementierungsphilosophie notwendig.

Microsoft Niederlassung Hamburg
Gasstraße 6a.

Heute gibt es einem sehr interessanten Vortrag vom Thomas Martens:

Dokumentation von SSAS Modellen unter Verwendung von SSAS DMVs und dem OpenSource Tool Graphviz
Entwurf einer Dokumentations-Methode von SSAS Modellen. Als Grundlage für die Dokumentation der SSAS Modelle werden SQL Server StoredProcedures verwendet, die verschiedene DMVs durch Joins miteinander verknüpfen. Einzelne Objekte wie Dimensionen, MeasureGroups, Cubes und Perspektiven werden dabei als Nodes und die Beziehung dieser Objekte untereinander als Edges interpretiert. Für Objekte vom Typ MeasureGroup wird dabei bspw. das Granularitätsattribut der Dimension bzw. die Kardinalität der Beziehung der Dimension zur MeasureGroup angegeben. Die Visualierung von Nodes und Edges erfolgt anschließend in einem pdf-Dokument.

ich bin sehr gespannt, da ich zwar selber sehr gerne und ausgiebig automatisierte Dokumentationen und Repositorys für SQL Server Analysis Services Datenbanken (aka OLAP Cubes) erstelle und nutze, aber mich bisher so gar nicht mit Graphviz beschäftigt habe. Interessanter Ansatz!

Um zahlreiches Erscheinen wird gebeten! Sofern möglich, meldet Euch bitte vorher kurz beim Rolf Keyser unter rky@sqlpass.de an.

Freue mich drauf Euch vor Ort zu treffen!

Integration der Master Data Services in produktive Umgebungen
In dieser Session wird anhand von Praxisbeispielen erläutert, wie die SQL Server Master Data Services (MDS) in vorhandene und produktive Softwarelandschaften eingebunden werden können. Es muss nicht immer das große allumfassende Master-Data-Management-Projekt sein. Die MDS bieten aufgrund ihrer offenen Architektur eine ganze Reihe von interessanten Einsatzmöglichkeiten in bestehenden Lösungen.

http://basta.net/2012/sessions/#session-21779

Wie aus der Beschreibung der Session schon ersichtlich wird, geht es mir wieder mal nicht um die pure Darstellung einer Technologie sondern um die praxisbezogene Integration eines Dienstes in vorhandene Umgebungen. Des Weiteren werde ich dort erläutern, wie die MDS als Architekturkomponente in Integrations- und Business Intelligence-Projekten einzusetzen sind.

Der very early Bird für die BASTA! läuft noch bis zum 28.6.2012 (Stand heute.).

Ein prominentes Beispiel dafür ist u. a. Master Data Management. Grundsätzlich lässt sich "das" mit Bordmitteln lösen, dennoch bieten Hersteller dafür eigenständige Produkte an, welche diese Herausforderung deutlich einfacher und damit besser lösen. Microsoft selbst legt seiner Datenplattform SQL Server mittlerweile in der zweiten Version die Master Data Services dafür bei.

Eine weitere dieser Disziplinen ist die sogenannte Datenvirtualisierung (Data virtualization).

Vieles wird ja heutzutage virtualisiert. Server, Desktops, Anwendungen und Storage. Warum also nicht auch Daten?

Was ist nun Datenvirtualisierung? Der Wiki Artikel dazu verrät uns, dass es im Groben darum geht, dass der Zugriff auf Daten mittels einer weiteren Abstraktionsebene virtualisiert wird. Wer hier jetzt spontan an Views (Sichten.) denkt, liegt da gar nicht so falsch. Des Weiteren geht es darum, dass der Zugriff auf Daten zentralisiert wird ohne die Notwendigkeit die Daten zu replizieren bzw. zu duplizieren. Und wer hier jetzt an Linked Server (Verbindungsserver.) denkt. Ja, genau.

Ein einfacher und valider Ansatz ist damit sich für alle Datenbanken in der Organisation auf einem SQL Server System als Linked Server einzurichten und diese wiederum auf Basis von Views freizugeben. Nennen wir es einfach mal "extrem Viewing".

Eine solche Abstraktionsschicht werden viele schon mal im Rahmen eines Business Intelligence oder Datenintegration Projektes gebaut haben. Nur haben wir es viele von uns so bisher nicht genannt.

Es hilft sich die Bereitstellung von Daten in der Organisation als Dienst vorzustellen. Es wird also nicht direkt auf den jeweiligen Datenbankserver zugegriffen, sondern auf einen zentralen Server, welcher als Dienst die Anbindung an die Daten (und damit "echten" Datenbanken) ermöglicht.

Wie wird so etwas nun verwaltet? Nicht ohne Grund nenne ich so ein Szenario ja "extrem Viewing" :-) . In der Regel löse ich das als Repository Fan über ein Managed Linked Views (MLV) Szenario mit dem ich die Linked Server und Views zentral verwalte.

Weitere Beispiele diesen direkten Zugriff, häufig auch als Federated Database System bezeichnet, können ROLAP Cubes oder in BISM DirectQuery Mode in Tabular Model Szenarien sein. Wir sind da immer in quasi Echtzeit unterwegs.

Bleiben wir aber noch kurz bei dem Gedanken, dass Daten als Dienst bereitgestellt werden in einer Organisation, dann wird schnell der Ruf nach Qualität in den Daten laut. Hier hilft der direkte Zugriff auf die Daten nicht weiter. Da muss ein Stück Logik zwischen. Idealerweise eine Technologie, welche Daten eh auf Basis Views bereitstellt und sich mittels eines Repositorys steuern lässt, also unser MLV Szenario nahtlos ergänzend bzw. unterstützt.

Hier kommen wieder mal die Master Data Services (MDS) des SQL Servers ins Spiel. Mit diesen lässt sich eine Datenvirtualisierungslösung hervorragend unterstützen und für den Nutzer der Daten völlig transparent einbinden. Meine Erfahrung mit den Master Data Services haben gezeigt, dass sich die MDS sehr einfach und schnell in solche Umgebungen integrieren lassen. Es stehen alle Funktionen der MDS für die Steigerung der Qualität der Daten zur Verfügung bis hin zur Einbindung der Data Quality Services (DQS) des SQL Servers.

Kommen wir zurück zum Wiki Artikel über Datenvirtualisierung. In diesem werden die Features einer solchen Lösung kurz skizziert:

• Abstraction
• Virtualized Data Access
• Transformation / Integration
• Data Federation
• Flexible Data Delivery

Merken wir uns, dass die Anforderungen an eine Datenvirtualisierungslösung vom SQL Server auf jeden Fall erfüllt werden und entsprechende Projekte damit umsetzbar sind. Sofern ein Ansatz mittels eines Repositorys gewählt wird, wie mein Managed Linked Views Konzept, dann kann der Aufwand für den Betrieb sehr schlank gehalten werden. Hängt natürlich auch von der Größe der Umgebung und der Komplexität ab, ob dieser Ansatz sich rentiert. Meine Erfahrungen mit Repositorys hat gezeigt, dass sich das Beschäftigen mit solchen Strukturen durchaus lohnt in größeren Umgebungen.

Auch wenn "der Kunde" nicht direkt nach einer Datenvirtualisierung fragt, macht diese Art der Architektur durchaus Sinn bei BI und Integrationsprojekten, um eine durchaus nützliche Abstraktionsschicht anbieten zu können. Der dafür notwendige Aufwand ist eine gute Investition in die Zukunft einer Lösung und schafft eine Investitionssicherheit für ein Projekt.

Des Weiteren ist es ein Beispiel dafür, dass eine "neue" Disziplin nicht immer gleich auch ein neues Produkt in einer IT-Landschaft benötigt.

Microsoft Niederlassung Hamburg
Gasstraße 6a

Dieses Mal gibt es einen Vortrag von unserem Gastsprecher Sebastian Meine. Sein Vortrag handelt von den Interna des SQL Servers.

Index Internals - How SQL Server stores and accesses data
In this session we will examine one of SQL Servers' most fundamental yet most important functions - how does SQL Server store data on disk and how does it find it again when executing a query. Using a combination of demos, lecture and discussions we will begin with the structure of the data on disk by delving into the world of HoBTs and Extends, RIDs and Keys and especially Pages. From there we will tackle topics concerning the retrieval of data such as Index levels, Index Scans and Seeks and Lookups.

Um zahlreiches Erscheinen wird gebeten! Sofern möglich, meldet Euch bitte vorher kurz beim Rolf Keyser unter rky@sqlpass.de an.

Freue mich drauf Euch vor Ort zu treffen!