Sascha Lorenz

Wo ist Project Crescent in SQL Server Denali CTP 3?

2011-07-14T21:14:00.001+02:00

So, seit wenigen Tagen (nun ja, fast Stunden) ist die CTP 3 vom SQL Server Denali draußen. Und groß in der Ankündigung von Microsoft steht drin, dass auch das sagenumwogende “Project Crescent” dabei sein soll.

Und schon geht die Sucherei los. Wo ist Crescent? Wir wollen auch diese ultra-coolen Reports bauen!

Die Antwort dazu ist relativ einfach. Es ist dabei, aber… Crescent ist ein Bestandteil von PowerPivot für SharePoint! Und das wiederum bedeutet, dass Ihr einen SharePoint 2010 Enterprise mit Service Pack 1 für die Nutzung von Crescent benötigt.

Details findet Ihr hier: Deployment Checklist: Reporting Services, Project Crescent, and PowerPivot for SharePoint

Mehr zu MERGE in T-SQL - Der Cursor Alternative!

2011-06-17T14:24:00.001+02:00

Zu meinem Post über den MERGE Befehl des SQL Servers habe ich viel Feedback bekommen und das Interesse an mehr dazu scheint recht groß. Danke dafür!

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!

Community Webcast Reihe: Das kleine SQL Server 1x1 für Software Entwickler auf Channel 9

2011-06-09T09:39:00.001+02:00

Gestern ist auf Channel 9 der erste Teil einer kleinen Community Webcast Reihe vom Peter Kirchner und mir zum Thema SQL Server speziell für ISVs online gegangen. Die weiteren Teile werden dann ebenfalls in den nächsten Wochen online gehen. Was machen wir in diesen Casts? Hier der “Klappentext”:

“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!

BASTA! 2011 – Bin als Sprecher dabei

2011-06-08T10:03:00.001+02:00

Vom 26. bis zum 30.09.2011 findet in Mainz wieder die BASTA! statt.

Was ist die BASTA! ?
“Die BASTA! ist die renommierteste unabhängige Konferenz für .NET-Technologien im deutschsprachigen Raum. Hier kommen die besten Experten aus ganz Europa zusammen, um Ihnen ihr praxiserprobtes Wissen und ihre Erfahrung weiter zu geben. Technisches Know-how auf höchstem Niveau für Entwickler, exzellentes Erfahrungswissen für Softwarearchitekten und Projektleiter – das ist es, was die BASTA! auszeichnet.” Zitat von der Website

Die BASTA! setzt sich mittlerweile aus drei “Konferenzen” zusammen:

BASTA! – Entwickler, Entwickler…
SQLCON – SQL Server…
ShareConnect – SharePoint Server…

Und als Teil der SQLCON darf ich dieses Jahr zwei Vorträge zu meinen Lieblingsthemen halten:

Die Entwicklersicht auf Microsofts Business Intelligence am 27.09.2011 | 17:15 - 18:30 Uhr
In dieser Session wird anhand von Beispielen gezeigt, wie durch die Nutzung der offenen und dokumentierten APIs des SQL Servers und seiner Dienste BI-Projekte deutlich effektiver geplant und durchgeführt werden können. Es werden sowohl Anregungen für den gestandenen BI-Berater zur Nutzung von .NET-Code gegeben als auch Beispiele für Entwickler für die Integration in ihren Lösungen gezeigt.

Entwicklung eigener Business Intelligence Clients am 28.09.2011 | 08:30 - 09:45 Uhr
In dieser Session wird gezeigt, wo der Nutzen in der Erstellung eigener Clients für operative und analytische BI liegt und wie diese mit dem SQL Server und C# entwickelt werden können. Dafür werden die Technologien Analysis Services, Integration Services, ADOMD.NET, AMO, WinForms, ASP.NET und Silverlight miteinander kombiniert vorgestellt.

Das verspricht ein cooles Event zu werden! Freue mich schon drauf. Vielleicht treffe ich ja auch wieder den einen oder anderen von Euch.

Weitere Details findet Ihr u.a. auf http://basta.net/2011/sessions/?l=de&id=5&tid=2015.

MERGE in T-SQL – Der unbekannte Befehl im BI Projekt für ELT

2011-06-07T13:09:00.001+02:00

Wenn ich Diskussionen über die Entscheidung für eine ETL oder ELT Architektur führe oder auch nur moderiere, dann bringe ich als ein mögliches Beispiel für eine ELT Architektur gerne die Verwendung des MERGE Befehls. Nur wenige scheinen diesen Befehl bisher aktiv zu nutzen, dabei ist er schon seit SQL Server 2008 dabei und gehört auch zum SQL:2008 Standard!

Was macht nun der Befehl MERGE? Laut den BOL das hier:

“Führt Einfüge-, Aktualisierungs- oder Löschvorgänge in einer Zieltabelle anhand der Ergebnisse eines Joins mit einer Quelltabelle aus. Sie können z. B. zwei Tabellen synchronisieren, indem Sie Zeilen in einer Tabelle anhand von Unterschieden, die in der anderen Tabelle gefunden wurden, einfügen, aktualisieren oder löschen.”

Und damit ist er perfekt geeignet für den Ladeprozess von Dimensionen in Data Warehouse/BI Projekten. Denn dort benötigen wir ja sowohl ein INSERT als auch ein UPDATE für unsere Geschäftsobjekte in den Dimensionen. Ok, und ganz selten mal ein DELETE, sollte aber nicht die Regel sein.

Wie wende ich MERGE nun an? Auf den ersten Blick wirkt der MERGE Befehl ein wenig “unübersichtlich”.

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

Wie muss ein MERGE Befehl gelesen werden? Also, wir haben hinter dem MERGE das sogenannte “Ziel” und hinter dem USING die “Quelle”. Über das ON werden diese beiden verbunden (join). Nun kommt das WHEN MATCHED THEN. Hier kommt unsere Aktion hin, welche ausgeführt wird bei einer Erfüllung der Bedingung. Ok, und bei WHEN NOT MATCHED kommt halt die Aktion, wenn die Bedingung nicht erfüllt wurde. Soweit ganz einfach, oder?

Hier ein erstes einfaches Beispiel:

MERGE DimTarget as t
USING ELTSource as s
ON t.bk = s.bk
WHEN MATCHED THEN
    update set t.bk = s.bk, t.attribute1 = s.attribute1, t.attribute2 = s.attribute2
WHEN NOT MATCHED THEN
    insert (bk, attribute1, attribute2)
    values (s.bk, s.attribute1, s.attribute2);

Das war doch schon nicht schlecht. Nun ist es aber so, dass hier wenn immer der BK (BusinessKey, Geschäftsschlüssel aus der DWH Lehre…) gleich ist auch ein Update durchgeführt wird. Das sollte natürlich nur sein, wenn sich was an den Attributen geändert hat! Eine erste Idee wäre nun die ON Klausel zu erweitern, aber dadurch würden wir unser Zielt nicht erreichen, da dann ja der Vergleich auf den BK nicht mehr passt. Wir benötigen eigentlich eine Zweiteilung der Bedingung, also wenn BK gleich und Attribute ungleich. MERGE unterstützt dies, indem wir das “WHEN MATCHED” erweitern!

MERGE DimTarget as t
USING ELTSource as s
ON t.bk = s.bk
WHEN MATCHED AND (t.attribute1 != s.attribute1 or t.attribute2 != s.attribute2)
    THEN
        update set t.bk = s.bk, t.attribute1 = s.attribute1, t.attribute2 = s.attribute2
WHEN NOT MATCHED
    THEN
        insert (bk, attribute1, attribute2)
        values (s.bk, s.attribute1, s.attribute2);

Das ist schon eine deutliche Vereinfachung, aber nun kommt die Herausforderung der Slowly Changing Dimensionen vom Typ 2, also dem Historisieren von Attributen. Wie lässt sich so etwas nun mittels MERGE realisieren? Gar nicht! Wobei das so natürlich nicht stimmt, aber wir brauchen ein ganz klein wenig mehr als nur ein MERGE.

Aber zuerst mal kurz nachdenken, was wir bei einem SCD2 tatsächlich alles an möglichen Fällen haben.

BK ist neu, damit auch die Zeile –> Insert
BK ist bekannt, aber es wurden nur Typ 1 (also überschreiben) Attribute geändert –> Update
BK ist bekannt und es haben sich Attribute vom Typ 2 geändert –> Update (von aktiv auf inaktiv) & Insert (also die neue aktive Zeile) !

Fangen wir einfach mal an.

MERGE DimTarget AS t
USING ELTSource AS s
ON t.bk = s.bk
WHEN MATCHED AND t.aktiv = 1 AND t.attribute2 != s.attribute2
    THEN -– BK ist gleich und Attribute hat sich geändert, daher auf inaktiv setzen
        UPDATE SET t.aktiv = 0, t.ende_datum = getdate(), t.attribute2 = s.attribute2
WHEN NOT MATCHED
    THEN -– BK ist unbekannt, daher neuer Satz
        INSERT (bk, attribute1, attribute2, aktiv, start_datum)
        VALUES (s.bk, s.attribute1, s.attribute2,1, getdate());

Nur wie bekommen wir jetzt die neuen Zeilen hinzugefügt, nachdem wir die “alten” auf inaktiv gesetzt haben? Dafür benötigen wir ein wenig Hilfe von einer Klausel, welche aber auch relativ unbekannt ist. Und zwar OUTPUT. by the way, UPDATE, INSERT & DELETE kennen die auch! Ist äußerst nützlich.

MERGE DimTarget AS t
USING ELTSource AS s
ON t.bk = s.bk
WHEN MATCHED AND t.aktiv = 1 AND t.attribute2 != s.attribute2
    THEN
       UPDATE SET t.aktiv = 0, t.ende_datum = getdate()
WHEN NOT MATCHED
    THEN
        INSERT (bk, attribute1, attribute2, aktiv, start_datum)
        VALUES (s.bk, s.attribute1, s.attribute2,1, getdate())
OUTPUT $Action Befehl, s.bk, s.attribute1, s.attribute2;

Damit bekommen wir quasi als Resultat des MERGE Befehls eine Zusammenfassung der durchgeführten Aktionen. Uns interessieren wiederum nur die UPDATEs und nutzen den Output für ein INSERT als Input.

INSERT INTO DimTarget
SELECT bk, attribute1, attribute2, 1, GETDATE(), null
FROM
(
MERGE DimTarget AS t
USING ELTSource AS s
ON t.bk = s.bk
    WHEN MATCHED AND t.aktiv = 1 AND t.attribute2 != s.attribute2
      THEN
         UPDATE SET t.aktiv = 0, t.ende_datum = getdate()
    WHEN NOT MATCHED
      THEN
         INSERT (bk, attribute1, attribute2, aktiv, start_datum)
         VALUES (s.bk, s.attribute1, s.attribute2,1, getdate())
    OUTPUT $Action Befehl, s.bk, s.attribute1, s.attribute2
) AS out
WHERE Befehl = 'UPDATE';

Und schon haben wir in nur einem Befehl Slowly Changing Dimensions Typ 2 abgebildet. Der Vorteil der Verwendung von MERGE ist, dass Quelle und Ziel nur einmal durchlaufen werden müssen für alle Operationen, da für alles nur ein Queryplan erstellt wird. Gerade bei größeren Datenmengen können ELT Architekturen damit deutlich vereinfacht und beschleunigt werden!

MDXScript Service – Repository driven calculations

2011-06-04T15:59:00.001+02:00

Vor einiger Zeit hatte ich ja schon mal beschrieben wie das MDXScript Objekt ohne das BIDS bzw. den BIDS Helper geändert werden kann. Des Öfteren wurde ich danach gefragt, wozu denn so etwas gut sein soll. Wenn der Würfel neu verarbeitet wird, dann wird das MDXScript doch eh neu durchgerechnet.

Nun ja, so einfach ist es dann nicht!

Das MDXScript wird ja nicht durchgerechnet! Es wird einfach in der OLAP Datenbank (aka Cube) bereitgestellt. Erst wenn Teile des MDXScriptes für das Auflösen einer MDX Query benötigt werden, wird es genutzt! Des Weiteren bleibt die eigentliche Analysis Services Datenbank gültig und alles Verbindungen bestehen. Diese Tatsachen ermöglichen einige interessante Lösungen! :-)

Zum Beispiel die Bereitstellung eines MDXScript Services! Auch gerne Calculations Services genannt.

Die Idee dahinter ist recht einfach und wird von mir gerne verwendet, wenn des Öfteren im Laufe eines Tages eine dynamische Änderung bzw. Anpassung eines “Würfels” notwendig ist und der verwendete Client diese Art von Änderung nicht unterstützt. Zum Beispiel um Szenarien dynamisch mittels Scope Anweisungen durchzurechnen. Es ist durchaus möglich, dass mehrere Anwender voneinander getrennt diesen Dienst für einen Würfel nutzen können, wenn die Zuweisung über ein Member eines Szenario Attributes gesteuert wird.

Alle einzelnen Berechnungen (neue Member, Scopes, KPIs etc.) liegen in einer relationalen Datenbank oder auch in einer SharePoint Liste vor. Die Berechnungen können entweder manuell gepflegt oder, was häufiger der Fall ist, durch eine Anwendung erzeug werden. Die einzelnen Statements werden dann zu einem String zusammengesetzt und als ein MDXScript veröffentlicht. Und alle Änderungen am Würfel sind sofort online und sichtbar! Häufig geht die kreative Verwendung von Scope Anweisungen auch weit über die Möglichkeiten des Update Statements hinaus.

SQL Server Versionen & Editionen im Vergleich – Entscheidung vor dem BI Projekt?

2011-06-02T19:44:00.003+02:00

Immer wieder werde ich gefragt, welche Edition denn nun für ein BI Vorhaben bzw. Projekt die geeignete sei? Hintergrund dieser Frage ist häufig die Entscheidung zwischen der sogenannten “Standard” und “Enterprise” Edition.

Des Weiteren kommt häufig die Frage, ob sich denn der Wechsel auf eine aktuellere Version lohnen würde? Viele Kunden von Microsoft haben einen SQL Server 2008 im Einsatz und noch mehr einen SQL Server 2005. Und natürlich gibt es noch durchaus Anwender des SQL Server 7 & 2000, aber da stellt sich aus Supportsicht die Frage eigentlich nicht.

Oft kommt auch noch die Frage, ob sich denn das Warten auf die nächste Version lohnen würde. Zurzeit warten wir ja alle ganz gespannt auf SQL Server 2011 aka Denali.

Und natürlich ist der Fragesteller dann immer schnell bei der Hand die guten alten “Best Practices” zu bemühen. Also da muss es doch auch so eine richtig vs. falsch Regel für geben. Wieder mal gibt es diese nicht, denn die Antwort auf so eine Frage kann natürlich nur das wiederum gute alte “Kommt ganz drauf an…” sein.

Ach ja, das Thema Lizenzierung lassen wir mal für den Moment ganz außen vor, ist aber nicht weniger spannend! Glaubt mir!

Ich will hier nun keinen detaillierten Vergleich der Editionen durchführen. Dafür hat Microsoft selbst gute Seiten. Siehe unten.

Fangen wir mit der häufigsten Frage an. Welche Edition für das Projekt?

Immer wieder habe ich in Workshops und Proof-of-Concepts die Diskussion, dass Kunden & Partner erwarten die gerade für sie “selbstverständlichen” Features in der Standard Edition vorzufinden. Mein Einwand ist dann meist, dass es sich da um ein semantisches Missverständnis handelt. Nicht nur, dass der SQL Server mit seinem Namen eh schon ein Problem hat, da die wenigsten BDM bei etwas mit diesem Namen eine komplette “Data Plattform inkl. BI” vermuten, sondern auch “Standard” in Abgrenzung zu “Enterprise” ist verwirrend in der Kommunikation.
Daher beantworte ich diese Frage meist damit, dass in meinem Verständnis die “Enterprise” Edition die eigentliche “Standard” Edition ist. Schon verwirrend, was für Labels der Hersteller da auf seine Boxen klebt. :-)

Die eigentliche “Enterprise” Edition, also das was viele damit verbinden (GROSSE Umgebungen…), ist für mich die “Data Center” Edition. In der “Data Center” Edition liegt zum Beispiel die Premium Edition von StreamInsight bei. Die wird benötigt für Umgebungen mit mehr als 5000 Events pro Sekunde und einer Latenz unter 5 Sek. Das ist sehr wahrscheinlich gar nicht so selten. Wesentlich bekannter ist die Eigenschaft, dass sie tatsächlich alle verfügbaren CPUs des Betriebssystems unterstützt. Und wem das nicht genug ist, kann ja gerne mal auf die “Fast Track” Konfiguration und “Parallel Data Warehouse” Edition hinweisen!

Nur was sind denn jetzt die wesentlichen Unterschiede in den Editionen (Standard vs. Enterprise) bezogen auf Business Intelligence Projekte?

Unterscheiden wir mal die einzelnen Dienste des SQL Server 2008 R2:

In der Datenbank Engine sind die wesentlichen Unterschiede in der “Enterprise” Edition:

wichtig für Data Warehouse Umgebungen

Partitionierung in der relationalen Datenbank
Parallele Indexvorgänge
volle Unterstützung von Indizierte Sichten
Datenkomprimierung
Optimierung von Sternjoinabfragen
SQL Server Audit
Transparente Datenbankverschlüsselung

praktisch für Integrationsprozesse (ETL/ELT) im Quellsystem

Datenbank-Momentaufnahmen (Snapshots)
Change Data Capture

In den SQL Server Integration Services (SSIS) kommt folgendes hinzu:

High-Performance-Oracle-Ziel
High-Performance-Teradata-Ziel
SAP BW-Quelle und –Ziel (ja, ja… so etwas gibst!)
Zieladapter des Data Mining-Modelltrainings
Zieladapter für Dimensionsverarbeitung
Zieladapter für Partitionsverarbeitung
Persistente Suchen
Fuzzygruppierung und –suche
Ausdrucksextrahierung und -suche

Bei den Analysis Services (SSAS) würde uns ohne “Enterprise” Edition folgendes fehlen:

Partitionierte Cubes
Finanzaggregationen & Kontointelligenz
Semiadditive Measures

Vorsicht, das liest sich hier für die SSAS jetzt von der Menge her nicht sehr tragisch, kann einen Architekten bzw. Berater aber empfindlich eingrenzen und leicht zum Misserfolg eines Projektes führen!

Und bei den Reporting Services fehlt uns eigentlich “nur” das Feature “Datengesteuerte Berichtsabonnements”, aber auch das kann fehlen. Und immer daran denken, dass nachmachen nicht gilt! :-)

Master Data Services und PowerPivot für SharePoint haben wir nur ab der “Enterprise Edition”!

Wie kann nun im Rahmen eines Proof-of-Concepts entschieden oder in den ersten Projekt Phasen eine belastbare Entscheidung herbeigeführt werden für die Auswahl einer Edition? Wie oben bereits gesehen, hängt die Auswahl der Edition stark von den Anforderungen ab! Daher ist es sehr wichtig den Anforderungskatalog für das geplante Projekt durchzugehen und zu klären, ob echte Showstopper dabei sind. Sofern sich die Projektbeteiligten nicht einig sind, ob die Features wirklich benötigt werden, empfehle ich einen Piloten auf Basis der kostenlosen “Evaluierung” Edition aufzusetzen. Diese Edition hat den Umfang der “Enterprise” Edition.

Nun zur Wahl der Version. Wichtig der Hinweis, dass diese Entscheidung, wenn sie denn tatsächlich ansteht, vor der Wahl einer Edition erfolgen sollte.

Hier ist der Rat sehr einfach. Eigentlich sollte immer auf die aktuell verfügbare Version zurückgegriffen werden. Wenn bereits eine Version vorhanden ist und keine Möglichkeiten bestehen im Rahmen des Lizenzvertrages mit Microsoft auf die aktuelle Version zu wechseln, also eine nicht kostenneutrale Entscheidung ansteht, dann empfehle ich wieder auf Basis des Anforderungskatalogs zu klären, welche neuen Features benötigt werden.

Ein häufiger Grund für den Wechsel von 2008 auf 2008 R2 waren in der Vergangenheit u. a. die zahlreichen Erweiterungen der Reporting Services.

Ein Hinweis noch zur sogenannten “Developer Edition”, da diese relativ unbekannt ist. Mit dieser dürfen Entwickler bzw. BI Berater auf Entwicklungssystemen bzw. lokalen Rechner isoliert von den produktiven Systemen an der Lösung arbeiten. Solche extra Server sind bei anderen Herstellern immer recht kostenintensiv, bei Microsoft hat sich über Jahre ein Preis von unter 100€ pro Lizenz gehalten. Das ist äußerst günstig und sollte in Projekten auf jeden Fall genutzt werden, da es zumindest keinen lizenztechnischen Grund gibt direkt auf dem produktiven Systemen die Lösung weiterzuentwickeln.

Bei allen Angaben in diesem Post beziehe ich mich als Quelle auf diese Seite von Microsoft: http://technet.microsoft.com/de-de/library/cc645993.aspx

SharePoint Business Intelligence bei Microsoft in Unterschleißheim (ShareCamp)

2011-06-01T10:42:00.001+02:00

Nun ist das ShareCamp in Unterschleißheim ja schon ein paar Tage her. Hatte gleich danach viel um die Ohren.

Unter anderem war ich gleich noch am folgenden Montag Abend in Köln im Microsoft Regional Office, um dort bei der SQL Server Community (PASS Deutschland e.V.) einen Vortrag über Repository Driven BI zu halten. Vielen Dank an die Organisatoren und die vielen Teilnehmer, hat mir großen Spaß gemacht!

Aber nun ist die Zeit gekommen für ein kurzes Resümee zum ShareCamp.

Erst mal vielen herzlichen Dank an die Organisatoren aus der Community und von Microsoft! Das ShareCamp ist eine wirklich gelungene Community Veranstaltung gewesen! Selten war der Community Gedanke auf einer Konferenz so unmittelbar greifbar! Das lag sicherlich auch an der für mich neuen Veranstaltungsform als Barcamp. War anders, aber hat viel Spaß gemacht, da das flexible Format gerade meiner persönlichen Nähe zur Spontanität zugesagt hat. :-)

Ach ja, aus Tradition… Essen war gut & lecker!

Aber ich war ja nicht allein auf dem ShareCamp. Wir, die PSG Projekt Service GmbH aus Hamburg, waren als Sponsor dabei. Und das wiederum auch nicht allein, denn gemeinsam mit der Layer 2 GmbH (auch aus Hamburg), haben wir einen norddeutschen Gemeinschaftsstand in Unterschleißheim aufgemacht. Genaugenommen hatten uns die Kollegen von der Layer 2 den Vorschlag dazu gemacht. U.a. hatten wir eine gemeinsame Demoumgebung für die Vorträge erstellt, welche auch von Layer 2 gehostet wurde. Vielen Dank für die super Zusammenarbeit im Vorfeld und Vorort an Gabriella, Björn, Carsten, Frank, Jörn & Matthias von Layer 2. Des Weiteren auch einen herzlichen Dank an meine Kollegen Jan, Michael (vor Ort) & Olaf-Christian für die Unterstützung der SharePoint Community!

Vorträge wurden natürlich auch gehalten. Mein Thema war Business Intelligence im Kontext SharePoint Server bzw. Technologie. Der Inhalt wurde von vielen Teilnehmern interessiert aufgenommen. Spontan (ist ja ein Barcamp) haben wir dann vor Ort entschieden noch eine gemeinsame Session mit dem Matthias Hupe von Layer 2 durchzuführen, um einmal komplett sowohl die SQL Server Business Intelligence Seite (PerformancePoint Services, Analysis Services & Co) als auch in vergleichbarer Tiefe die notwendige SharePoint Infrastruktur zu erläutern.

Das wiederum hat uns die Aufmerksamkeit von Microsoft, in Person Lori Grosland (Community Developer Evangelist), eingebracht, welche uns dann noch zum Thema interviewt hat. Das Ergebnis steht mittlerweile im Netz! Einfach aufs Bild klicken oder auf den Link.

Lori steht in der Mitte (ach…), rechts der Matthias und links bin ich.

http://channel9.msdn.com/Blogs/Lori/ShareCamp-2011-Business-Intelligence--SharePoint

Des Weiteren habe ich aus dem Event viele Anregungen mitgenommen. Und habe auch schon wieder eine ganze Reihe von Ideen, wie die Integration von Business Intelligence in SharePoint noch unterstützt werden kann. Was mich noch zu einem anderen Thema bringt und zwar bereite ich eifrig den Start der Community Website rund um die Entwicklersicht auf die Microsoft Business Intelligence Komponenten von Microsoft vor. Unter anderem werde ich dort einige meiner Community Projekte aus meinen Vorträgen zusammenführen und um weitere Informationen erweitern. Der Wunsch nach Sourcecode und Beispielen für meine bzw. unsere Ansätze in Projekten wird immer lauter und lässt sich meiner Meinung nach wohl nicht nur über diesen Blog erfüllen.

Und zu guter Letzt noch der Hinweis, dass bei mir gerade die Bestätigungen als Sprecher für weitere Konferenzen in 2011 eintrudeln, also die Wahrscheinlichkeit mich auf einem Community Event zu treffen ist weiterhin hoch. Details folgen, wenn die Inhalte offiziell freigeschaltet werden. :-)

ShareCamp, ich bin auf dem Weg – Business Intelligence mit SharePoint

2011-05-13T23:09:00.001+02:00

Langsam nähere ich mich Unterschleißheim. Dort ist ja am kommenden Wochenende das ShareCamp im HQ von Microsoft Deutschland.

Nachdem ich vorgestern ja noch beim PASS (SQL Server Usergroup) Treffen in Hamburg dabei war, habe ich noch kurz Station gemacht in der PASS Regionalgruppe Hannover und dort einen Vortrag über “The Developer Side of Microsoft BI” gehalten. Hat großen Spaß gemacht! Sehr interessante Diskussionen. Besonders mit den drei Regionalgruppenverantwortlichen vor Ort: Christoph Seck, Artus Krohn-Grimberghe & Vladimir Stepa. Gerade die Diskussionen mit Vladimir, einem der Mitentwickler des berühmten MDX Studios, waren anspruchsvoll aber sehr auch inspirierend!

Danke, dass ich dabei sein durfte! Ich hoffe, dass für alle ein paar Anregungen dabei waren!

Heute geht die Fahrt weiter nach München.

Auf dem ShareCamp gibst dann von mir Einiges zum Thema BI mit dem SharePoint Server.

Auf Rückweg können wir uns dann noch in Köln am Montag Abend beim PASS Treffen im Microsoft RO begegnen. Da halte ich dann ja auch noch einen Vortrag.

ps:Sorry für die Verspätung des Posts, Blogger war teilweise down.

SSIS (Integration Services) als ETL Lösung – Dynamisches SSIS? [Coaches’ Hell]

2011-05-07T12:16:00.001+02:00

Eine häufige Frage an mich ist, warum ich überhaupt so viel Zeit investiere in die Entwicklung von projektspezifischen SSIS Generatoren. Schließlich lasse sich doch in SSIS fast alles über Expressions und den Mechanismus der Paket-Konfiguration von außen dynamisch steuern! Wozu also der ganze Aufwand?

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! :-)

PASS, PASS, ShareCamp & PASS – Meine nächste Woche

2011-05-05T18:58:00.001+02:00

So, jetzt ist es amtlich! Meine nächste Woche wird ein “wenig” Community-lastig…

Mittwoch, den 11.5., PASS Treffen Hamburg zum Thema “Denali” (da bin ich nur Co-Sprecher…) –> Dank an Markus Thomanek von Microsoft!

Donnerstag, den 12.5., PASS Treffen Hannover zum Thema “Developer Side of Microsoft BI” (mit mir als Sprecher)

Freitag, den 13.5., bis zum Sonntag, den 15.5., bin ich dann als Sponsor (& als Sprecher) auf dem ShareCamp 2011 in Unterschleißheim, München dabei

und weil es so schön in der Community ist…

Montag, den 14.5., PASS Treffen Köln zum Thema “Developer Side of Microsoft BI” (wieder mit mir als Sprecher).

Sehen wir uns? Bei der Tour gibt es fast keine Ausrede mehr! :-)

SSIS (Integration Services) – ETL vs. ELT Lösung?

2011-05-04T22:15:00.001+02:00

Und wieder war es ein Meeting, welches mich zu einen Blogpost animiert.

Wir sprachen über die Einführung eines Data Warehouses, ETL etc. pp. und dann kam da einer mit einer ganz tollen Frage: Was ist denn mit ELT und wo sei der Unterschied? Und ob das denn die Integration Services auch könnten? Ist doch die Zukunft des Integrationsprozesses, sagt doch der andere Hersteller. Also wäre ja zu erwarten, dass Microsoft solche Innovationen unterstützt. Der klassische ETL Prozess wäre ja quasi von gestern und mit ELT dann ja auch dazu noch überflüssig geworden.

Erwartungsvolle Gesichter in der Runde. Was ist denn nun ELT und kann das der SQL Server? Ich liebe meinen Job…

Also, klassisches ETL (Extract, Transform, Load) meint, stark vereinfacht ausgedrückt, dass Daten aus verschiedenen Vorsystemen extrahiert werden. Diese werden in der Regel in Form von “Datenpaketen” in einer sogenannten Landing Zone gesammelt. Von dort aus werden die Pakete i. d. Regel mehrstufig weiterverarbeitet, sprich transformiert. Der letzte Schritt ist das Laden der Daten in das relationale Data Warehouse, wobei dann noch die Historisierung von Daten durchgeführt werden kann.

Was kann nun eine ELT Lösung dazu Innovatives beitragen? Das Offensichtliche zuerst. ELT steht für Extract, Load & Transform. Ok, ist halt vertauscht. Und? :-)

Die Idee dabei ist, dass Daten wiederum zuerst aus Vorsystemen extrahiert werden. Die Methoden, Konzepte, Ideen und auch Herausforderungen sind 100% identisch zur ETL Welt. Auch können diese Daten in Form von Datenpaketen organisiert werden. Nur dann kommt der wesentliche Unterschied! Die Daten werden beim ELT Ansatz gleich wieder in ein relationales Datenbanken System geladen. Häufig ist es das System, welches auch das eigentliche Data Warehouse hält. Und auf diesem System werden die Daten mittels SQL Statements transformiert. Das ist schon alles.

Ok, ok… wozu jetzt die ganze Aufregung? Dazu müssen wir noch ein wenig mehr ins Detail gehen beim ETL Prozess. Beim ETL findet häufig eine Verarbeitung der Daten außerhalb einer relationalen Datenbank statt. In der Regel werden die Daten zeilenweise verarbeitet. In den Integration Services wird das durch den konsequenten Einsatz der Datenflusskomponente und des RAW-Dateiformates erreicht. Ab einer sehr großen Datenmenge ist dieses Vorgehen deutlich schneller als die relationale Engine zu bemühen.

Bei ELT gibt es aber keine extra Verarbeitungsengine, sondern “alles” findet innerhalb einer relationalen Datenbank statt. Es wird damit eine Technologie “gespart”. Das ist der häufig ins Feld geführte Vorteil einer ELT Architektur. In der Praxis heißt das auch oft, dass ein extra System gespart wird.

Meine 2 Cent dazu sind:
ELT klingt gut, kann es sogar sein, ja wenn… die Rahmenbedingungen stimmen! Wenn ich keine wirklich komplexe und unübersichtliche Umgebung habe. Des Weiteren sollte die Anzahl der Vorsysteme überschaubar sein. Und, steht ja schon oben, die Datenmenge sollte auch gewisse Grenzen haben (und nein, da gibt es keine one-size-fits-all Antwort drauf!).

Die Wahrheit ist, dass es da draußen eine Unmenge an ETL Prozessen gibt, welche sehr wahrscheinlich ELT Prozesse sind. Und bisher hat es keinen gestört! :-)

Ach ja, und natürlich lassen sich auch ELT Integrationsprozesse mit dem Microsoft SQL Server abbilden. Alles eine Frage der Architektur!

SQL Server Reporting Services (SSRS) – Wofür können diese eigentlich alles genutzt werden?

2011-05-01T12:06:00.001+02:00

Ein schon ein paar Tage zurückliegendes Meeting mit einem Kunden brachte mich auf die Idee für diesen Post.

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! :-)

SSIS (Integration Services) als ETL Lösung – Package Tools im Eigenbau – Teil 2 – Connection Manager auslesen

2011-04-30T13:51:00.001+02:00

Hier ist der nächste Teil meiner kleinen Reihe über die Entwicklung von eigenen Werkzeugen für das Auslesen und Verändern von SSIS Paketen (dtsx).

Wie bereits im ersten Teil, machen wir noch was ganz harmloses und lesen dieses Mal die Verbindungsmanager eines Paketes aus. Das Codebeispiel dient für den Moment hauptsächlich dazu, zu zeigen wie einfach der Zugriff auf einzelne Eigenschaften eines SSIS Paketes ist. Des Weiteren demonstriere ich noch, wie wir bereits hier auf die Verwendung von Expressions prüfen können. Expressions, also die Arbeit mit dynamischen Ausdrücken innerhalb einer SSIS Lösung, lassen äußerst mächtige Architekturen möglich werden, sind aber in der späteren Wartung ein wenig tricky, wenn der Verantwortliche für den Betrieb der Lösung nicht immer hundertprozentig weiß, wofür gerade überall Ausdrücke verwendet werden. Gerade im Zusammenspiel mit mehrstufigen Paket-Konfigurationen kann die Fehlersuche durchaus anspruchsvoll werden. Aber deswegen bauen wir uns ja einen eigenen Satz Werkzeuge, um später den Überblick zu behalten.

Hier das entsprechende Codefragment, welches wieder ein Paket öffnet und alle Verbindungen ausliest. Und über GetExpression wird auf die Verwendung der Eigenschaft ConnectionString geprüft.

app = new Microsoft.SqlServer.Dts.Runtime.Application();

DialogResult result = openFileDialog1.ShowDialog();
if (result == DialogResult.OK)
{
p = app.LoadPackage(openFileDialog1.FileName, null); // Hier haben wir unser Paket in 'p'

    foreach (ConnectionManager ConMan in p.Connections)
    {
        listBox1.Items.Add(ConMan.CreationName + " - " + ConMan.ConnectionString);

        String ExConString = ConMan.GetExpression("ConnectionString");
        if (ExConString != null)
            listBox1.Items.Add("ConnectionString Expression -> "+ExConString);

}

SSAS (Analysis Services) OLAP Cubes – Der Stern ist nicht der Würfel!

2011-04-28T16:03:00.001+02:00

Das Geschäft als Berater bzw. als Coach besteht ja auch zum Teil daraus, dass man zur richtigen Zeit den richtigen Spruch bzw. Lehrsatz auf den Lippen hat.

“Der Stern, die Schneeflocke oder die Galaxie ist nicht gleichzusetzen mit dem daraus entstehenden multidimensionalem Raum!”

Kurzfassung:

Der Stern ist nicht der Würfel!

Viele Anwender der Analysis Services arbeiten aber gerne mit der Vorstellung, dass das Starschema nicht nur die Quelle darstellt, sondern auch, dass im Cube die Trennung zwischen Dimensionen und Fakten existiert. Dimensions- und Faktentabellen sind aber “nur” relationale Strukturen, welche als Datenquellen für den Würfel dienen. Viele Frontends, wie auch Excel, unterscheiden aber sehr deutlich in der Darstellung zwischen Attributen (Dimensionen) und Measures. Der eigentliche Cube bzw. der, wie ich finde korrektere Ausdruck, multidimensionale Raum haben aber ihre ganz eigene “Logik”.

Wie kommen wir da jetzt raus?

Muss nun jeder Endanwender eine hochesoterische MDX Schulung erhalten? Bitte nicht! Das führt nicht gerade zur Akzeptanz einer Lösung!

Aber jeder, der sich für das Erstellen von OLAP Cubes mit den SQL Server Analysis Services interessiert, sollte frühzeitig in den “echten” multidimensionalen Raum einsteigen. Selbst wenn nie geplant ist mit MDX Berechnungen etc. pp. einzubauen, so ist das bloße Beschäftigen damit und Hinterfragen schon sehr nützlich, um auch die “einfachen” Funktionen von SSAS noch besser zu nutzen. Ehrlich!

SSIS (Integration Services) als ETL Lösung – Package Tools im Eigenbau – Teil 1

2011-04-27T21:54:00.001+02:00

In der Vergangenheit habe ich ja schon mehrmals auf die Möglichkeiten der “Developer Side of Microsoft Business Intelligence” hingewiesen. Häufig habe ich dabei auch die Erstellung bzw. Modifikation von SSIS Paketen durch .NET Code gestresst.

Ein Missverständnis dabei ist, dass ich diese Methode ausschließlich für die automatisierte Erstellung von SSIS Paketen (dtsx) empfehle! Der Aufwand, der dafür getrieben werden muss, um eine solche Lösung einzusetzen, ist tatsächlich sehr hoch und ist bei weitem nicht was für jedes Projekt.

Aber, meine Empfehlung ist die “Developer Side” auch für bestehende Lösungen zu nutzen. U. a. für die automatisierte Inventarisierung und Erweiterung von SSIS Paketen, um zum Beispiel Logging und Debug Funktionen. Dieser Ansatz ist gerade für Lösungen interessant, bei denen am Anfang auf die konsequente Verwendung von Templates aus einem Framework verzichtet wurde. Für diesen Verzicht kann es diverse Gründe geben. Häufig ist, dass einfach keine Zeit war und der Kunde möglichst schnell Resultate sehen wollte. Später dann alle Pakete manuell umzustellen wird dann auch wieder oft vermieden, weil der Aufwand auch dann wieder immens sein kann.

Daher habe ich mich entschlossen eine kleine Reihe von Artikeln zu veröffentlichen, um die Möglichkeiten der “Developer Side” für SSIS aufzuzeigen. Die Reihe startet mit diesen wenigen Zeilen Code, welche ein bestehendes SSIS Paket quasi per Knopfdruck um einen SQL Task inkl. Connection erweitern, um ein T-SQL Statement abzufeuern beim Start des Paketes. Das ist noch ein sehr einfaches Beispiel, aber zeigt schon erste wichtige Strukturen. Wir öffnen ein bestehendes Paket, modifizieren es und speichern es wieder.

Dieses Beispiel werde ich dann in den nächsten Wochen weiter verfeinern. Viel Spaß beim Mitmachen!

using Microsoft.SqlServer.Dts.Runtime;
using Microsoft.SqlServer.Dts.Pipeline.Wrapper;
using wrap = Microsoft.SqlServer.Dts.Runtime.Wrapper;

…

Microsoft.SqlServer.Dts.Runtime.Application app;
Package p;

…

private void bAuswahl_Click(object sender, EventArgs e)
{
app = new Microsoft.SqlServer.Dts.Runtime.Application();

    DialogResult result = openFileDialog1.ShowDialog();
    if (result == DialogResult.OK)
    {
        p = app.LoadPackage(openFileDialog1.FileName, null);

        ConnectionManager ConnManager = p.Connections.Add("OLEDB");
        ConnManager.Name = "Source"+tbDescription.Text;
        ConnManager.ConnectionString = tbConnString.Text;

        TaskHost th = p.Executables.Add("STOCK:SQLTask") as TaskHost;
        th.Name = tbDescription.Text;
        th.Description = tbDescription.Text;

th.Properties["SqlStatementSource"].SetValue(th, tbSQL.Text);
th.Properties["Connection"].SetValue(th, "Source" + tbDescription.Text);

app.SaveToXml(openFileDialog1.FileName, p, null);
}

SSIS (Integration Services) als ETL Lösung – Entscheidungen vor dem Einsatz

2011-04-25T21:56:00.001+02:00

Heute mal wieder ein paar Gedanken zur Architektur einer ETL Lösung. Genaugenommen sind wir bei der Klärung von einigen grundlegenden Fragestellungen. Welche können das beim Einsatz von Integration Services (SSIS) als ETL Lösung sein?

Viele Fragestellungen bzw. Herausforderungen, welche ich im Rahmen von Coachings gestellt bekommen habe bzw. wir als Team in Projekten angetroffen haben, lassen sich auf einige grundlegende Missverständnisse und inkonsequente Entscheidungen zurückführen. Dabei geht es nicht um technische Details.

Ist tatsachlich die Entscheidung für eine echte ETL Lösung getroffen worden?

ETL heißt nicht, dass ein bestimmtes Tool verwendet wird! Also, wir verwenden die Integration Services heißt nicht automatisch, dass man da von ETL sprechen kann oder sollte. ETL ist für mich die konsequente Verfolgung eines Konzeptes. Und es heißt viel mehr als nur in Extract, Transform und Load zu denken, denn das trifft auch auf die meisten üblichen Schnittstellen zu.

ETL heißt u. a., dass alle Beteiligen sehr wahrscheinlich in Zukunft in Datenpaketen denken müssen. Und damit ist nicht gemeint, dass SSIS Task in Paketen organisiert werden, sondern “wieder” klassische Batchverarbeitung von Datensätzen angesagt ist. Aber nur mit diesen einfachen aber effektiven Methoden können Datenmengen in Enterprise Umgebungen auch nachhaltig bewältigt werden.

Ist jemand im Team, der schon mal ein echtes Data Warehouse gesehen hat?

Ok, provokant, aber leider eine berechtigte Frage! Denn mit Integration Services zu arbeiten heißt nicht, dass man später nur noch mit bunten Pfeilen Kästchen verbinden darf und alles andere ist dann von ganz allein im Lot. Viel zu häufig erlebe ich, dass die SSIS unterschätzt werden. Das grundlegende Konzept ist ja auch sehr einfach. Da kommt dann gerne mal im Workshop oder Proof-of-Concept viel zu schnell ein “Schnittstelle, verstanden, lassen Sie uns jetzt bitte mit diesen Würfeln weitermachen…”. Daher, da muss jemand ins Team, der das Ziel kennt.

Ist eine Entscheidung für den Einsatz des Datenflusstasks getroffen worden?

Was soll das denn jetzt? Der Datenflusstask ist doch das Herz der Integration Services! Korrekt, aber ich kenne einige sehr erfolgreiche und durchaus komplexe BI Projekte, welche komplett auf den Datenfluss Task verzichtet haben. Warum? Ja, weil einfach die Anforderung für den Einsatz fehlte. Zwar wurde der Bewirtschaftungsprozess komplett in SSIS gekapselt, aber es wurden konsequent SQL Statements für die Verarbeitung der Daten eingesetzt.

Den Datenflusstask einzusetzen heißt, dass sich das Team bewusst dazu entscheidet ab sofort neben einem “Thinking in Sets” (ja, ich meine damit auch das Buch von Joe Celko) mit der Prämisse “Thinking in Rows” zu leben. Den Datenflusstask einzusetzen heißt auch eine nicht unerhebliche Lernkurve mitzumachen. Dann hat das Team eine äußerst leistungsfähige Technologie zur Hand, um wirkliche Massendaten bei jedem Lauf des Prozesses zu bewegen. Wenn es aber wie so häufig um wenige 100.000 Sätze pro Tag geht, dann sollte vorher entschieden werden, ob sich der Aufwand beim Einsatz lohnt. Wichtig ist mir hier der Hinweis, dass es da kein Richtig oder Falsch gibt! Es gilt immer die Fallentscheidung.

Sind die politischen Aspekte eines solchen Projektes klar?

Natürlich ist jedes Projekt irgendwie politisch. Wer kennt das Spiel um die Förmchen und Schäufelchen nicht aus eigener Erfahrung. ETL Projekte, also wenn wir von einem echten sprechen (s.o.), sind anders, denn hier nehmen wir allen den Sand aus dem Sandkasten weg, um ihn erst mal richtig gut durchzuwaschen, zu sieben und dann färben wir den Sand auch der Größe der Körner nach ein. Und dann wird auch noch entschieden wer ab sofort mit dem blauen, roten und grünen Sand spielen darf. Vielleicht werden im Zuge des Projektes auch noch die liebgewonnen Eimer und Siebe standardisiert. Mit diesem Bild vor Augen sollte jedem die Situation und Herausforderung klar sein, in die er sich da begibt. Mein Ratschlag: Nehmen wir viele Lollies mit, welche dann vom Business Intelligence Competence Center verteilt werden sollten. Nicht ohne Grund ist die Gründung eines BICC häufig ein Teil eines ETL/DWH Projektes, um den Anwendern das Ganze schmackhaft zu machen.

Integration Services & Reporting Services gemeinsam für die Bereitstellung von Reports nutzen

2011-04-23T09:54:00.001+02:00

Im Rahmen eines Projektes evaluiere ich gerade Möglichkeiten, um eine automatisierte Bereitstellung von Reports zu ermöglichen. Es geht dabei um 1-2 Reports mehr. :-)

Die Verwendung von RS.EXE für die Ansteuerung der Reporting Services hatte ich in diesem Kontext ja schon beschrieben. Wobei mir bei RS.EXE die Anbindung von Datenquellen für die Parametrisierung nicht so gefällt.

Daher heute ein weiterer Ansatz: Nutzung der Reporting Services aus den Integration Services heraus!

Von der Logik her unterscheidet sich der Weg zum Report gar nicht so sehr vom Skriptingansatz, da wir wieder mit den selben Objekten konfrontiert werden. Nur jetzt verwende ich mal den Webservice für die Kommunikation.

Was brauchen wir also alles?

Einen Report! Da nehme ich wieder mal meinen einfachen Report mit nur einem Parameter, um die Ansteuerung der Parameter zu testen.

Ein SSIS Paket, welches nur aus einem Datenflusstask besteht, welcher wiederum nur eine OLE-Quelle und ein Skriptkomponente hat, welche heute mal als Ziel herhalten muss.

Die Datenquelle hat ein vergleichsweises einfaches Design, aber wird ihren Job machen.

Die Eingabespalte für unsere Skriptkomponente ist einfach “Text”. Mehr Einstellungen braucht die Komponente auch nicht.

Hier der Verweis auf den Webdienst der Reporting Services. Ab 2008 können wir ja auch Webdienste in der Komponente ansteuern. Danke nochmals dafür! :-)

Und natürlich noch das Stück Code für die Skriptkomponente.

public override void Eingabe0_ProcessInputRow(Eingabe0Buffer Row)
{
    byte[] result = null;
    string devInfo = @"<DeviceInfo><Toolbar>False</Toolbar></DeviceInfo>";
    string encoding;
    string mimeType;
    string extension;
    Warning[] warnings = null;
    string[] streamIDs = null;

    ParameterValue[] parameters = new ParameterValue[1];
    parameters[0] = new ParameterValue();
    parameters[0].Name = "DemoParameter";
    parameters[0].Value = Row.Text; // Übergabe des Parameters von außen…

ReportExecutionService rs = new ReportExecutionService();
rs.Credentials = System.Net.CredentialCache.DefaultCredentials;

rs.LoadReport("/Vertrieb/Demo", null);
rs.SetExecutionParameters(parameters, "de-de");

result = rs.Render("PDF", devInfo, out extension, out encoding, out mimeType, out warnings, out streamIDs);

    FileStream stream = File.Create(@"c:\MyProjects\output\report_"+ Row.Text +".pdf", result.Length);
    stream.Write(result, 0, result.Length);
    stream.Close();
}

So, diese Teile alle in einem SSIS Projekt bringt dann folgenden Output:

Und als Beweis kurz noch der Blick in eines der Dokumente.

Damit bin ich jetzt schon eindeutig zufriedener, wenn es darum geht automatisiert eine größere Menge an Reports zu erzeugen. Der Ansatz scheint eine gute Grundlage zu sein.

Viel Spaß beim Nachmachen! Und nochmals FROHE OSTERN! :-)

Reporting Services RS.EXE mit Parametern nutzen

2011-04-21T14:55:00.001+02:00

Vor ein paar Tagen habe ich hier gepostet wie Ihr mit dem Tool RS.exe (dem Reporting Services Skript Tool) einen Report bereitstellen könnt.

Dazu kamen nun ein paar Fragen rein. Eine Frage wiederholte sich und zwar: Wie Parameter an den Report übergeben werden können?

Das ist natürlich möglich, dazu müssen wir nur das Skript ein wenig erweitern für. Dann könnt Ihr das gleich zu Ostern ausprobieren! :-)

Zu erst aber brauchen wir einen Report mit einem Parameter. Dazu nehmen wir mal nichts komplexen, sondern diesen schönen Report. Der hat keinerlei Quellen etc., sondern nur einen Parameter mit dem schönen Namen “DemoParameter”.

Kommen wir zum Inhalt unseres “render.rss” Skripts.

Public Sub Main()
Dim fileName as String = "C:\Users\Administrator\Desktop\demo.png"
Dim reportPath as String = "/Vertrieb/ParameterDemo"
Dim results() as Byte

Dim parameters(0) As ParameterValue

parameters(0) = New ParameterValue()
parameters(0).Name = "DemoParameter"
parameters(0).Value = myText

rs.Credentials = System.Net.CredentialCache.DefaultCredentials

rs.LoadReport(reportPath, Nothing)
rs.SetExecutionParameters(parameters,"en-us")
results = rs.Render("IMAGE", Nothing, Nothing, Nothing, Nothing, Nothing, Nothing)
Dim stream As FileStream = File.OpenWrite(fileName)
stream.Write(results, 0, results.Length)
stream.Close()
End Sub

Hier sehen wir auch die Erweiterungen für die Arbeit mit Parametern. Wir nutzen ein Array vom Typ ParameterValue und übergeben dieses mittels “SetExecutionParameters()” an den Report. Nur kommt unser Parameter nun von außen in das Skript?

Dazu hier unsere Kommandozeile:

rs.exe –i render.rss –s http://localhost/ReportServer –e Exec2005 –v myText=”Hallo SQL Server Community…”

Mit dem Parameter “–v” legen wir eine globale Variable im Skript an, welche wir nutzen können. Siehe oben im Skript. Das war es schon!

Frohe Ostern!

ShareCamp 2011 in München, Unterschleißheim (Microsoft)

2011-04-21T10:21:00.001+02:00

Hier noch schnell vor Ostern der erste Hinweis, dass wir (die PSG) gemeinsam mit unserem Partner Layer2 auf dem ShareCamp, dem Community Event für SharePoint in Deutschland, dabei sind.

Das ShareCamp 2011 findet auch dieses Mal wieder in der Zentrale von Microsoft in Unterschleißheim statt. Termin ist der 14.-15.05.2011 (ja, das ist ein Wochenende!).

Vor Ort werde u. a. ich sein und ein wenig die Business Intelligence Flagge für SharePoint hochhalten und die Integration von Analysis Services, Reporting Services etc. in SharePoint evangelisieren. Dazu gehört es natürlich auch, dass ich gerne die PerformancePoint Services erläutere und einen tiefen Einblick in die Technologie OLAP (so mit Dimensionen, Attributen, Tuples, MDX etc. pp.) gebe, um die PPS auch wirklich sinnvoll nutzen zu können.

Ich freue mich schon sehr auf dieses Community Event! In den nächsten Tagen werde ich noch weitere Details dazu posten und was ihr von uns vor Ort sehen könnt.

SQL Server Community Vorträge in Hannover & Köln

2011-04-20T09:28:00.001+02:00

Wie die Zeit doch rennt! :-)

Hier der Hinweis, dass ich als Gastsprecher am

12.05.2011 beim Treffen der PASS Deutschland e.V. Gruppe Hannover / Göttingen

& am

16.05.2011 beim Treffen der PASS Deutschland e.V. Gruppe Köln / Bonn / Düsseldorf

bin!

Ich werde bei beiden Treffen über eines meiner Lieblingsthemen sprechen dürfen und zwar

“The Developer Side of Microsoft Business Intelligence”
Der Microsoft SQL Server bietet eine ganze Reihe von äußerst mächtigen Diensten und Werkzeugen für die Erstellung von Business Intelligence Lösungen. Warum sollte sich dann überhaupt ein BI Berater mit den Möglichkeiten der Programmierbarkeit des SQL Servers beschäftigen? Weicht er damit nicht vom Standard ab? Und warum sollte sich ein Programmierer mit BI befassen? Sind die BI relevanten Dienste vom SQL Server etwa nicht fertig?

Die Wahrheit ist, dass eine wesentliche Stärke des SQL Servers, neben den bekannten Werkzeugen, die Verfügbarkeit von diversen sehr gut dokumentierten APIs ist. Diese APIs können sehr gut im Rahmen von BI Projekten genutzt werden und die Integrationsfähigkeit einer BI Lösung um ein vielfaches erhöhen. Alle in diesem Workshop vorgestellten Schnittstellen sind offiziell von Microsoft beschrieben worden und werden in zukünftigen Versionen unterstützt werden.

Vor dem Einsatz von Technologie kommt aber immer die zielgerichtete Konzeption der Lösung. Es wird gezeigt, wann und wie sich der Einsatz von Programmierung in BI Projekten tatsächlich rechnet und welche Voraussetzungen dafür erfüllt sein müssen.

Ein ganz wesentlicher Punkt aus der Erfahrung heraus ist die Nutzung der Abstraktion der Anforderungen und der Technologie als Architekturansatz im Design von Business Intelligence Lösungen.

Zwar geht der Vortrag bei einigen Punkten ein wenig ins Eingemachte, aber auch SQL Server BI Rookies werden eine Menge mitnehmen können. Versprochen!

Ich freue mich schon sehr auf die Treffen und die Chance möglichst viele SQL Server Interessierte und Community-Begeisterte aus der jeweiligen Region kennenzulernen!

SQL Server Analysis Services & Excel – “Bewegliche Ziele” oder wie wichtig ist eigentlich ein deterministischer Attribute Key?

2011-04-19T16:06:00.001+02:00

Ein Thema kam beim letzten Treffen der SQL Server Community (PASS) in Hamburg auf und zwar die Frage: Wie wichtig ist die deterministische Vergabe des Attribute Keys in Analysis Services?”. Nun ja, und die Antwort darauf ist wie so oft: Kommt ganz drauf an!

Was ist überhaupt gemeint mit der deterministische Vergabe von Attribute Keys?

Am Beispiel von Excel 2010 als Frontend möchte ich kurz die Herausforderung skizzieren.

In Excel 2010 können wir ohne weitere Plug-Ins mittels einer Pivot-Tabelle und/oder den Excel Cube Funktionen auf Analysis Services Datenbanken (aka “Cubes”) zurückgreifen. Und Excel gibt es mittlerweile sowohl als Tool für den Desktop als auch als Excel Services im SharePoint.

Für unser kleines Beispiel habe ich hier eine Tabelle DimKunde mit folgenden Einträgen:

Wichtig dabei ist, dass die Dimensionszeile einen eindeutigen Schlüssel mit der Spalte ID hat. Die Spalte OrtId wird in diesem Fall automatisch erzeugt und enthält damit einen eindeutigen Key für jedes Member des Attributes. Das automatische Erzeugen machen wir zum Beispiel mit dem Ansatz aus meinem Blogpost über DENSE_RANK(). Die Vergabe der OrtId erfolgt immer direkt bei der Aufbereitung der Analysis Services Datenbank. Vielleicht ist da ja ein View oder ähnliches zwischengeschaltet.

Wir setzen die “KeyColumns” Eigenschaft des Attributes in Analysis Services (also im BIDS) auf OrtID und die “NameColumn” auf Ort.

Damit nun die Member nicht in der Reihenfolge der Schlüssel angezeigt werden, setzen wir noch die Eigenschaft “OrderBy" auf “Name”.

Und eine kleine Hierarchie darf auch nicht fehlen.

Damit bekommen wir folgende Dimension:

Natürlich gibt es noch Fakten dazu, aber darauf gehen wir hier mal nicht im Detail ein. :-)

Und schon können wir uns unsere multidimensionale Datenbank in Excel darstellen lassen. Nicht viel dran mit einer Dimension und einer Faktentabelle, aber es reicht für den Moment.

Nun filtern wir in Excel die Darstellung so, dass nur noch Umsätze für Hamburg angezeigt werden sollen:

Noch schnell eine Überschrift drüber und schon ist ein einfacher “Report” fertig, wie er wahrscheinlich in etwas komplexerer Form in zahllosen Unternehmen tagtäglich erstellt wird. Den könnten wir nun gut abspeichern und später wieder nutzen, wir haben ja nun unsere Umsätze für Hamburg “herausgefiltert”. Nützlich so etwas und kann auch gerne dem Management zur Verfügung gestellt werden.

Nun kommt der Tag, an wir einen weiteren Kunden dazu bekommen. Kein Problem, der bekommt ja sofort eine eindeutige ID zugeordnet. Aber, bei der täglichen Vergabe der OrtId ist nun auf einmal das Member “Essen” zwischen “Berlin” und “Hamburg” gerückt und bekommt damit die automatische OrtId “2”.

Wenn wir uns nun die erweiterte Dimension anschauen, dann ist die korrekt ergänzt worden. Sieht alles unverdächtig aus!

Aber wenn wir nun unser gespeichertes Excel Dokument anschauen und mittels Aktualisieren die Darstellung aktualisieren, dann haben wir auf einmal folgendes in unserem “Report” stehen:

Was ist denn jetzt passiert? Ganz offensichtlich speichert Excel den Key des Members ab. Und sobald wir aktualisieren, wird aus Hamburg Essen, da nun Essen die OrtId “2” hat. Ein solches Verhalten von auf Excel basierenden Reports wird sehr wahrscheinlich das Vertrauen der Endanwender in die Business Intelligence Lösung nicht unbedingt festigen!

Wie schaust mit den Excel Cube Funktionen aus? Hierzu legen wir in Excel ein Beispielszenario an:

Dieses kleine Beispiel basiert auf folgenden Formeln:

Der obere Wert verwendet den Key “&[2]”. Der untere Wert bezieht sich direkt auf den Namen des Members “Hamburg”. Nach der Erweiterung um unseren Kunden in Essen, sieht unser Excel Dokument nun so aus:

Der obere Wert hat sich geändert auf den Wert von Essen, der untere ist erhalten geblieben. Wobei nun gesagt werden muss, dass die Funktion in C7 mit dem Standardverhalten von Excel erstellt wurde.

Fragestellung ist nun: Wie kommen wir da jetzt nur raus?

Es bleiben uns drei Varianten:

1.) Wir verwenden keine extra Key Columns und nutzen den hoffentlich einmaligen Namen des Attributes. Ok, dann geht die Performance sehr wahrscheinlich recht bald den Bach runter, aber irgendwas ist ja immer… (mal im Ernst, damit kommen wir nicht weiter..)

2.) Wir sagen den Anwendern, dass sich unser BI auf magische Weise über Nacht verändern kann und sie bitte auf den einen oder anderen Client verzichten sollten. (ok, ist auch nix… sehe ich ja ein…).

3.) Wir investieren wesentlich mehr Zeit in die Datenbewirtschaftung und sorgen dafür, dass die Schlüssel der Attribute deterministisch sind! (bin offen für Punkt 4, 5 etc…)

Also, sobald unser SSAS Projekt den Status Proof-of-Concept oder Prototyp verlässt und tatsächlich von den Anwendern produktiv eingesetzt wird, müssen wir uns mit dieser Thematik auseinandersetzen. Einen Ansatz dazu hatte ich schon mal kurz angerissen und zwar die Verwaltung der Dimensionen in Key-Value-Tabellen erfolgen zu lassen. Auf den ersten Blick scheint dieser Ansatz unnötig kompliziert, aber er hat einige Vorteile. Einen zeigt dieser Artikel, da in den Key-Value Tabellen die Schlüssel für die Attribute bereits gepflegt werden. Damit umgehen wir die Herausforderung der “spontanen deterministischen” Vergabe! :-)

SQLBits 8 – Analysis Services Scale-Out Vortrag PowerPoint ist online

2011-04-16T11:36:00.001+02:00

Mittlerweile ist der Download für die PowerPoint Folien für meinen Scale-Out für Analysis Services aktiv. In der Regel dauert es ein paar Wochen bis auch die Videoaufzeichnungen der Vorträge online gehen. Geduld! :-)

Die Slides bekommt Ihr hier!

Reporting Services Skripte nutzen für die Bereitstellung von Reports

2011-04-14T16:31:00.001+02:00

Hier aktuell eine Notiz aus dem Feld zu den Reporting Services.

Vielen Kunden als auch Kollegen ist es nicht bekannt, dass die Reporting Services auch auf sehr einfache Art und Weise per Skript-Sprache genutzt werden können. Daher hier ein kleines Beispiel dazu.

Den SQL Server Reporting Services liegt ein Kommandozeilentool namens RS.EXE bei. Dieses kann sowohl für administrative Aufgaben als für die Bereitstellung von Reports genutzt werden. Gerade das Skript (Batch) gesteuerte Erstellen von Reports in einem der Exportformate (z. B. PDF, XLS, DOC… ) ist für viele Kunden attraktiv. Wie kann so etwas umgesetzt werden?

Es wird auf jeden Fall eine RSS Datei benötigt! RSS steht in diesem Fall für Reporting Services Script. :-)

Hier der Inhalt einer Datei mit dem Namen “process.rss”, welche ich mit Notepad erstellt habe. Wie man sieht, ist das Ganze ein VBA Dialekt. Dieses einfache Beispiel rendert einen Report im PDF Format, für den das RDL File auf dem Report Server im Pfad “/Vertrieb/Demo” liegt. Das PDF wird direkt auf einem Fileshare im Pfad “f:\output\demo.pdf” erzeugt.

Public Sub Main()
Dim fileName as String = "f:\output\demo.pdf"
Dim reportPath as String = "/Vertrieb/Demo"
Dim results() as Byte

rs.LoadReport(reportPath, Nothing)

results = rs.Render("PDF", Nothing, Nothing, Nothing, Nothing, Nothing, Nothing)

Dim stream As FileStream = File.OpenWrite(fileName)
stream.Write(results, 0, results.Length)
Exec stream.Close()
End Sub

Ausgeführt wird dieses kleine Skript mit folgender Kommandozeile:

rs.exe –i process.rss –s http://localhost/ReportServer –e Exec2005

Diese kann entweder direkt oder als Teil eines Batches und/oder zeitgesteuert ausgeführt werden. Allein schon mit diesem einfachen Skript lassen sich eine ganze Menge von Anforderungen in komplexeren Projekten “erschlagen” ohne extra dafür ein Tool in .NET zu erstellen! Wobei, ich mag ja .NET…

Viel Spaß beim Ausprobieren!

Analysis Services Synchronisieren von Cubes – Wer bleibt online? (Coaches’ Hell)

2011-04-13T13:06:00.001+02:00

Vor ein paar Tagen habe ich ja über das Synchronisieren von Cubes einen kleinen Artikel geschrieben und einen Webcast augenommen. Auf den SQLBits in Brighton hatte ich das Thema auch in meiner Session dabei.

Ein Feedback dazu erreichte mich in den letzten Tagen immer wieder: Bleibt da alles online? Bleiben alle Connections erhalten?

Dazu von mir der Hinweis: Nein, der “Target”, also die Analysis Services Instanz, welche die Synchronisation auslöst, bricht laut meiner Erfahrung die bestehenden Connections ab und braucht einen Re-Connect.

SQL Server Usergroup Treffen in Hamburg April 2011 (Analysis Services Interna)

2011-04-11T19:55:00.001+02:00

Und schon wieder ist ein Monat rum und die Hamburger SQL Server Szene trifft sich am Donnerstag, den 14. April 2011, 18:30-20:30.

Das ist dann unser 60. Treffen! Wow…

Im April geht es um Interna in den SQL Server Analysis Services. Wir werfen gemeinsam einen Blick hinter die Kulissen der multidimensionalen Datenbank. Sowohl für den BI Berater als auch für den DBA interessant.

Sicherlich finden wir auch noch die Zeit, um uns ein wenig über die gerade vergangene SQLBits Konferenz in UK auszutauschen.

Veranstaltungsort ist:

Deutscher Pressevertrieb, Düsternstraße 1, 20355 Hamburg
Ansprechpartner vor Ort: Wolfgang Gottschalk

Würde mich sehr freuen, möglichst viele von Euch dort zu treffen! :-)

SQLBits 8 - Resümee

2011-04-11T14:51:00.001+02:00

So, die SQLBits 8 Konferenz ist nun vorbei. Zeit für ein letztes umfassendes Resümee!

Super Sprecher!

Super Lokation!

Super Community Event!

Und die SQLBits haben es sogar bis in die deutschen Nachrichten geschafft. Golem berichtet über sie, wenn auch leicht versteckt, beim zitieren eines Interviews mit Steve Wozniak (Mitgründer von Apple). http://www.golem.de/1104/82675.html Der Hinweis, dass es sich um die größte europäische SQL Server Konferenz handelt wäre noch nett gewesen.

Des Weiteren tauchen immer mehr Videos auf youtube auf. Unter anderem dieses hier… und ja, es war früh am Morgen… :-)

Attribute Keys für Analysis Services optimieren mit Hilfe von Dense_Rank (Coaches' Diary)

2011-04-10T19:25:00.001+02:00

Vor einigen Tagen habe ich einen Tipp veröffentlicht mit dem herausgefunden werden kann welche Attribute innerhalb einer SSAS Dimension einen String als Key haben. Das gilt es ja in einem SSAS Projekt aus diversen Gründen (einer ist Performance und ich glaube der zweite Grund war Performance, auf den Dritten komme ich noch…) zu vermeiden.

Nun kam die Frage auf, wie denn nun mit einfachen Mitteln dafür gesorgt werden kann, dass denn ein Integer Key auch immer verfügbar ist für das Attribut? Sofern das nicht über die Datenbewirtschaftung eines Data Warehouses gelöst wird (größeres Projekt…), dann muss das halt beim Aufbereitungsprozess für das Star-Schema eines “Cubes” (ich spreche ja eigentlich immer von SSAS Datenbanken) passieren.

Häufig sind diese Aufbereitungsprozesse aber direkt an das Quellsystem gebunden und die Aufbereitung wird über Sichten (Views) realisiert. Wo ist da noch Platz für die Zuordnung von Integer Keys? Diese Herausforderung habe ich in der Praxis schon häufig vorgefunden und damit auch eine ganze Reihe von Lösungen, welche sich der jeweilige Kunde dazu überlegt hatte. Da wird mit gespeicherten Prozeduren gearbeitet, da werden Tabellen umkopiert und mit Update-Statements aufgefüllt und natürlich spielt das Distinct Argument dabei häufig eine wichtige Rolle, um überhaupt die eindeutigen Werte des Attributes zu finden.

Hier möchte ich einen Lösungsansatz zeigen, welchen ich gerne verwende. Dazu nutze ich eine sogenannte Fensterrangfunktionen. Und zwar: DENSE_RANK(). Was steht zu dieser Funktion in den BOL?

“Gibt den Rang von Zeilen innerhalb der Partition eines Resultsets ohne Lücken in der Rangfolge an. Der Rang einer Zeile ist 1 plus die Anzahl der Ränge vor der fraglichen Zeile.”

Ok, klar! Also genau was wir brauchen, oder? Nun ja, der Sinn und ganz besonders der Nutzen erschließt daraus nicht auf den ersten Blick. Daher ein Beispiel.

Nehmen wir von der guten alten AdventureWorks2008R2 die Dimension DimProduct. In dieser Dimension gibt es eine ganze Reihe von Attributen für welche nur Keys als String bereitstehen. Zum Beispiel Color und es ist recht wahrscheinlich, dass unsere Anwender nach Color den Cube schneiden wollen. Also muss eine Optimierung des Schlüssels her.

Nur wie kommen wir jetzt mit ohne Umweg an einen eindeutigen Integer Key für Color? Hier ein erstes Beispiel für DENSE_RANK().

select
color,
DENSE_RANK() OVER (ORDER BY COLOR) as Color_Key
from dbo.DimProduct;

Hier nutzen wir die Rangfunktion, um für die Spalte Color den Rang für jeweils eine sogenannte Partition zu ermitteln. Diesen Rang nennen wir Color_Key. Natürlich geht das nicht nur mit einem Attribute in einer Abfrage, sondern auch mit weiteren Attributen!

select
*,
DENSE_RANK() OVER (ORDER BY COLOR) as Color_Key,
DENSE_RANK() OVER (ORDER BY SIZE) as Size_Key,
DENSE_RANK() OVER (ORDER BY SizeRange) as SR_Key
from dbo.DimProduct;

Wir sehen, dass wir in unsere Abfrage ohne weiteres eine Funktion einbauen können, welche uns für unsere Attribute die “notwendigen” Keys liefert. Damit kann also ohne größeren Umweg oder Aufwand unser Analysis Services Cubes optimiert werden.

Viel Spaß beim Ausprobieren!

SQLBits 8 – Brighton, UK - Freitag

2011-04-08T20:49:00.001+02:00

So, der Freitag in Brighton neigt sich dem Ende. Und selten wurde ein Motto so konkret umgesetzt: Beside the seaside…

Die letzten Partygäste verlassen das Haus. Auf der Ausklang Party gab es u.a. Fish & Chips und ein kühles Wetter, was bei dem Wetter hier auch dankend angenommen wurde! Wobei englisches Essen polarisierte schon ein wenig bei den nicht-englischen Teilnehmern.

Meine Session “28 weeks later – How to scale-out your MS Business Intelligence environment ”verlief weitestgehend wie erwartet und ohne größere Probleme. Es waren trotz prominenter “Konkurrenz” erstaunlich viele Teilnehmer bei so einem recht speziellem Thema im Raum. Vielen Dank dafür!

Und es waren dieses mal deutlich mehr Teilnehmer aus Deutschland dabei.

Bin schon sehr gespannt wohin es die SQLBits 9 dann wohl verschlagen wird… nur das Königreich steht schon fest! :-)

SQLBits 8 in Brighton/UK – Morgen geht es los!

2011-04-06T18:52:00.001+02:00

Und schon wieder ist es soweit! Morgen startet in Brighton, UK die wohl größte europäische SQL Server Konferenz! Wie immer haben die Organisatoren einen schönen Ort in England ausgesucht. Die Konferenz findet dieses mal im “The Grand” in Brighton statt. Hier mal eine Impression. Allein deswegen wird sich wohl der Weg lohnen.

Am Freitag bin ich ja dann als Sprecher dabei und darf als “quasi” Fortsetzung zum “The Developer Side of Microsoft Business Intelligence” einen Vortrag über Scale-Out Projekte mit den SQL Server Analysis Services halten. Mein Vortrag heißt dieses mal “28 Weeks later - How to scale-out your MS Business Intelligence Environment”. Spannendes Thema, hoffentlich finden das die Teilnehmer auch.

Hier eine kleine Vorschau auf das Slidedeck.

Vieleicht treffe ich ja dieses mal mehr Deutsche (oder zumindest deutschsprachige) Teilnehmer der SQL Server Community als in York! Würde mich sehr freuen!

Coaches’ Diary: Wie finde ich ganz einfach und schnell in einem Analysis Services Projekt alle Attribute, welche keinen Integer als Key haben…

2011-03-30T18:04:00.001+02:00

Hier ein kleiner Kniff aus der Coaching Praxis!

Da erkläre ich einem Kunden im Coaching lang und breit in Farbe und 3D, dass Attribute das A bis Z in einer multidimensionalen Datenbank sind und, ganz ganz wichtig, bitte als Keys bitte nur Integer Spalten verwendet werden sollten. So von wegen Performance und so! Ok, haben die meisten von Euch wohl auch schon von gehört bzw. gelesen. Ist bei größeren und komplexeren Umgebungen wirklich wichtig! Ehrlich!

Natürlich kommt vom Kunden die Aussage, dass sie das ganz sicher bedacht hätten. Ich hatte da so meine Zweifel, aber keinerlei Tools zur Hand bzw. auf dem Kundenserver, um das nun kurz mal zu überprüfen. Alternative wäre ein manuelles Suchen gewesen. Da fiel mir etwas ein! Mit der Power der Kommandozeile lässt sich das nämlich herausfinden!

Es folgt dieses magische Kommando:

dir *.ksstore /s

Und schon werden alle Attribute & die Dimensionen angezeigt, welche einen String im Key haben! Da ich die Kundendatenbank nicht nehmen kann, hier die AdventureWorks2008R2 als Beispiel:

Der Befehl ist im jeweiligen Ordner auf der Server abzusetzen, in welchem die SSAS DB liegt. Also hier beim Beispiel für ADW2008R2..

Wenn nicht klar sein sollte, wo die Datenbanken liegen, dann die SSAS Eigenschaft DataDir anschauen im Management Studio.

Natürlich könnte das DIR auch eine Ebene höher ausgeführt werden, dann würden wir für alle Datenbanken alle Attribute mit Strings im Key sehen.

Ein schönes Beispiel in Adventure Works 2008 R2 ist in Geography das Attribute City! Hier unser Output…

Und hier die Eigenschaften des Attributes im Projekt:

Ach ja, und was ist jetzt ein *.ksstore?

Relativ einfach zu sagen. Im Gegensatz zur relationalen Engine, wo wir ja “nur” mdf, ndf’s und ein ldf pro Datenbank haben, zerlegt SSAS die Datenbank in Tausende von Dateien. Mehrere Dateien pro Attribute zum Beispiel. Allein für den Key eines Attributes gibt es eine *.kstore (Key Store) und eine *.khstore (Key Hash Store). Nun ja, und NUR für den Fall, dass der Key aus Strings besteht auch noch eine *.ksstore (Key String Store)! Die ist sozusagen optional! :^)

SQL Server Analysis Services Synchronization fürs Deployment mit SSMS, SSIS & ADOMD.NET

2011-03-30T08:24:00.001+02:00

Im Rahmen der von mir durchgeführten Coachings & Trainings für die SQL Server Analysis Services stelle ich immer wieder fest, dass sich viele Anwender/Entwickler damit zufrieden geben einen “Cube” auf einem Server zu verarbeiten und diesen von dort aus zu nutzen bzw. die Anwender darauf zugreifen zu lassen. In vielen Umgebungen ist dieses Vorgehen, um die Anforderungen zu erfüllen, völlig ausreichend. Für komplexere Umgebungen und mit mehr Last und/oder keinem echten Wartungsfenster sind die Anforderungen aber deutlich höher. Die Arbeit mit mehreren SSAS Instanzen wird dabei durchaus in Betracht gezogen, aber das Deployment der SSAS DB wird häufig manuell durchgeführt bzw. es wird “nur” das Projekt verschoben. Resümee ist, dass multidimensionale Datenbanken häufig auf jedem Server aufs Neue verarbeitet werden. Dabei hat Microsoft den SSAS einige sehr nützliche Funktionen auf den Weg gegeben, um genau das zu vermeiden.

Eine davon ist die Synchronisation von SSAS Datenbanken. Hierbei wird vom Ziel-Server ausgehend eine Datenbank (aka Cubes) von einem Quell-Server übertragen. Dieses Feature kann sowohl in der GUI des SQL Server Management Studios (SSMS) durchgeführt werden, als auch in Integration Services und in .NET Code. Es gibt sicherlich noch weitere Möglichkeiten wie PowerShell etc., aber das sprengt dann irgendwann den Rahmen. :-)

In dem folgenden kleinen Cast demonstriere ich einige der Möglichkeiten, um den Synchronisationsprozess anzustoßen. Auf Details wie Remote Partitionen gehe ich bewusst nicht ein, da dafür noch ein wenig mehr Theorie für die Nutzung notwendig ist. Liefere ich aber bei Zeiten nach!

Viel Spaß mit dem Cast! Bei Fragen, Kommentaren, Anregungen und gar Wünschen für weitere Themen…–> einfach melden!

Landing Area (Zone) im SQL Server Data Warehouse

2011-03-25T18:56:00.001+01:00

Noch ein wenig was zum Thema Data Warehouse Design.

Diese Woche hatte ich u. a. ein Meeting, bei dem erwähnt wurde, dass der Begriff Landing Zone bzw. Landing Area im Zusammenhang mit Data Warehouse Architekturen bisher den Teilnehmern nicht bekannt war. Für mich ist die Nutzung einer Landing Area in einer Data Warehouse Umgebung ein wesentliches Element, um eine beherrschbare Lösung zu erstellen. Ihr erinnert Euch vielleicht, dass für mich die spätere “Beherrschung” der Business Intelligence Lösung ein elementarer Punkt ist und mir meist wichtiger ist, als irgendwelche technischen Spielereien auf der “Bit-Ebene…”. Und daher hier kurz eine Erläuterung meiner Sicht auf eine Landing Zone, welche gerne auch mal Landing Area heißt.

Die Aufteilung eines ETL Prozesses in sogenannte Stages ist mittlerweile relativ bekannt. Also die Daten, welche für das Data Warehouse benötigt werden, durchlaufen im Datenbewirtschaftungsprozess diverse Schritte (Stages) zur Überprüfung und Verarbeitung, bevor sie im finalen Load-Prozess ins DWH geladen werden.

Die Landing Zone setzt nun auf der gegenüberliegenden Seite an! Hier fängt der ETL Prozess an. Wichtig ist die Erkenntnis, dass der ETL Prozess eigentlich aus diversen voneinander getrennten Prozessen/Jobs/Paketen/What-ever besteht. Es gibt u.a. diverse Extract-Prozesse (das E in ETL), welche die Daten aus den Vorsystemen “einsammeln”. Nun gibt es aber auch noch den häufigen Fall, dass die Vorsysteme die Daten von sich aus automatisch liefern. Wohin also mit diesen gepushten Daten? Das ist die ursprüngliche Idee hinter der Landing Zone. Hier laden die Vorsysteme Ihre Daten ab. Entweder Deltas, Transaktionslog, Backups, Flats usw. Meist ist die Landing Area aus technischer Sicht eine Ordnerfreigabe auf einem Server. Aus dieser holen sich dann die Prozesse des ETL Jobs die dort “gelandeten” Daten ab und verarbeiten diese weiter. Natürlich kann es auch vorkommen, dass Datenpakete abgewiesen werden, weil die Datenqualität nicht die Geschäftsregeln erfüllen oder einfach was fehlerhaft ist im Format.

Meine Nutzung der Landing Zone geht noch ein wenig weiter, da ich einfach (ich mag einfache Lösungen bei komplexen Herausforderungen) alle Extract Prozesse ihre Ergebnisse in die Landing Zone ablegen lasse. Auch die Jobs, welche klassisch exportieren. Dazu nutze ich i. d. R. beim SQL Server die Integration Services (SSIS) und lasse die Daten im Rohdatenformat (RAW Format) in der Freigabe ablegen. Die weiteren Prozesse nehmen dann diese Dateien als Quelle auf und verarbeiten sie entsprechend weiter.

Der Vorteil einer Landing Area ist u.a., dass der ETL Prozess nicht direkt an den Vorsystemen hängt, sondern von diesen losgelöst ist. Eine asynchrone Verarbeitung zahlt sich auch hier aus, wenn das Ganze ein wenig unübersichtlicher von der Anzahl der Quellen und Prozesse wird. Des Weiteren kann der Inhalt der Landing Area, welcher im übrigen immer nur temporär dort liegt, ganz hervorragend mit einem Komprimierungstool in Paketform historisiert werden. Die Historisierung führe ich gerade bei ganz frischen Data Warehouse Umgebungen gerne durch, um noch evtl. Fehler in der Verarbeitung durch einen “Reset” des DWHs zu kompensieren ohne eine Datenverlust in der Historisierung zu haben. Daher gehört für mich eine Landing Area zu jedem komplexeren Data Warehouse!

Der Presentation Layer im Allgemeinen und speziell in einem SQL Server Data Warehouse

2011-03-22T19:20:00.001+01:00

In meinem letzten Blogpost habe ich ja ein wenig über Vorschläge für den Entwurf von Data Warehouse Umgebungen im Kontext SQL Server geschrieben. Und mir war klar, dass ich polarisieren werde. Hab es ja so gewollt. Gab dann ja auch schön Feedback von der Community zurück. Daher hier nun weitere Erläuterungen zu dem Thema.

Ein Punkt, welcher Inhalt des Feedbacks an mich war, ist das Thema Presentation Layer im Data Warehouse. Dazu wird viel in der begleitenden Literatur geschrieben und ich habe auch schon viel PowerPoint dazu gesehen. Teilweise wird sowohl in Form eines Prozesses von einem Presentation Layer gesprochen wird als auch bei einer statischen Architektur. Da sehe ich aber durchaus einen Unterschied!

Hier zur Visualisierung ein paar Beispiele:

Bei der Prozessdarstellung kommt der Presentation Layer meist “am Ende” des Prozesses, als der Teil, welcher dann von “Außen” sichtbar sein wird. Der Presentation Layer wird zum Beispiel im Rahmen eines ETL Prozesses am Ende “erzeugt”.

Dann gibt es den Ansatz bei einer Architektur vom Presentation Layer zu sprechen. Ich habe also diverse´Ebenen in meiner Architektur und wieder ist nur eine von “Außen” sichtbar.

Jetzt kann natürlich diskutiert werden, wo denn nun der Presentation Layer anfängt? Im Data Warehouse oder sind Cubes in den Analysis Services erst der Presentation Layer? Dann hätte das Data Warehouse in dem Sinne gar keinen Presentation Layer, sondern die OLAP Cubes erfüllen diese Rolle. Das käme dem Prozessbeispiel auch wieder nahe, da die Cubes ja erst am Ende des Datenbewirtschaftungsprozesses “entstehen”. Die Cubes wären dann so etwas wie Data Marts.

Kommen wir zu meinen Anregungen aus meinem Blogpost. Dort schlug ich ja vor, dass das Schema des Data Warehouse für sich bereits diverse Abstraktionen enthalten dürfte, sofern diese die Entwicklungs- und Betriebsprozesse unterstützen und den Anwendern nicht im Weg stehen. Dabei ist mein Vorschlag, dass auch einzelne Objekte wie Attribute, Dimensionen, Hierarchien etc. gerne jeweils ihre eigene Abstraktion haben dürfen und sich auch gegenüber den anderen Objekten nur durch diese “mitteilen”. Im Hintergrund gibt es dann ein Meta-Universum, welches die Objekte zusammenhält. Das mag der eine oder andere aus der objektorientierten Programmierung kennen.

Nur von den Faktentabellen lasse ich in der Regel die Finger was Abstraktionen angeht, da diese bei echten Massendaten äußerst kontraproduktiv wären!

Hier also ein Beispiel für einen Ansatz, bei dem die Objekte jeweils Ihren eigenen Presentation Layer für eine Abstraktion haben. Das darf dann gerne auch mehrmals geschachtelt sein, wenn es denn die Prozesse genügend unterstützt.

Es ist immer zu klären, ob sich der Aufwand und die Komplexität, welche die Arbeit mit Abstraktionen mit sich bringt, auch wirklich rentiert. Die IT ist voll von Beispielen für positive als auch negativen Ansätzen. Das muss im Einzelfall jeweils mit dem Kunden diskutiert werden.

Im Zweifel ist aber das Ziel der Suche nach dem Presentation Layer immer eine Definitionsfrage! :-)

Die reine Lehre vom SQL Server Data Warehouse Entwurf…

2011-03-21T13:42:00.001+01:00

Heute Abend ist zwar schon wieder ein Treffen der Hamburger SQL Server Community (PASS Chapter), aber ich kam noch gar nicht dazu das letzte Treffen zu reflektieren. War ein super Treffen, viele Leute, gute Diskussionen und eine klasse Lokation!

Bei dem Treffen habe ich eine lockere Liste von Punkten vorgestellt, welche aus meiner Sicht wichtig für den Erfolg von komplexeren Data Warehouse & Business Intelligence Projekten sind. Ein Punkt dabei war, dass ich vorgeschlagen habe, beim Entwurf für ein Data Warehouse ganz bewusst zwischen dem Presentation Layer und der eigentlichen technischen Implementierung in der Datenbank zu unterscheiden. Ich ging dabei soweit, dass ich vorschlagen habe für die physische Modellierung der Dimensionen sogenannte Key-Value-Tabellen einzusetzen. Dabei geht mein Ansatz wieder vom Attribut als Mittelpunkt aus. Das löste natürlich Diskussionen aus!

Wobei ich immer sage, dass es ja KEINE Silver Bullet gibt! Also eine universelle wirklich für jeden passende Lösung! Habe ich ja schon oft drauf hingewiesen. Und auch dieser Ansatz passt bei weitem nicht auf jedes Projekt.

Mir ist nur über die Jahre hinweg aufgefallen, dass sich langsam die Meinung durchsetzt, ein Data Warehouse muss sowohl logisch als auch physisch dem klassischen Star-Schema folgen. Und viele Herausforderungen, oder heute nenne ich sie mal bewusst Probleme, entstehen da heraus, dass sich die DWH Entwickler fast ein Bein ausreißen dieser Linie zu folgen.

Achtung! Ich meine nicht, dass wir auf Dimensionen und Fakten verzichten sollen! Ganz im Gegenteil. Bin immer wieder fasziniert bis entsetzt, was so als Dimension oder Fakt durchgeht. Diese Aufteilung (und der restliche theoretische Background eines Kimball etc.) macht auf jeden Fall Sinn! Nur halt nicht immer wirklich auf der physischen Ebene.

Natürlich stellt sich dann die Frage: Warum geht der Trend in diese Richtung? Ich kann mich noch durchaus an Zeiten erinnern, da waren Data Warehouse Systeme noch hoch komplizierte Werke, welche kein Reporting (bzw. OLAP)Tool dieser Welt wirklich nutzen konnte. Da ist eine Orientierung in Richtung Star-Schema natürlich von Vorteil. Des Weiteren scheinen die heute verfügbaren Werkzeuge die DWH Entwickler dazu zu motivieren, gleich in Dimensionen und Fakten zu denken. Zweischneidig das Ganze.

Das nimmt auch die Integration Services des SQL Servers (SSIS) nicht aus. Gerade die Integration Services geben dem DWH Entwickler äußerst leistungsfähige Komponenten an die Hand, welche unmoderiert leicht über das eigentliche Ziel hinausschießen. SSIS Komponenten für SCDs tun da ein übriges.

Jegliche Abstraktion bleibt dabei auf der Strecke und wer meinen Empfehlungen und Vorträgen ein wenig gefolgt ist, weiß ja schon wie sehr ich eine gute und saubere Abstraktion in Systemen schätze! :-)

Die Frage nach den Vorteilen ist da natürlich gerechtfertigt und lässt in der Regel auch nicht lange auf sich warten:

- Anreicherung der Strukturen im Hintergrund durch Metadaten
- Integration von Data Quality Informationen und Prozessen
- Anbindung an ein Master Data Management System (wie z.B. Master Data Services)
- Nutzung eines Repositorys (wen hätte es gewundert…)
- etc.

Wenn ich das Thema bringe, dann weht mir natürlich oft gleich ne steife Brise ins Gesicht. Nur solange die Argumentation in die Richtung “Darum!” oder “Weil man das halt so macht…” geht, dann läuft da was falsch und das Thema muss mal sachlich diskutiert werden

Und um eventuelle Bedenken bezüglich der Performance auszuräumen, möchte ich an dieser Stelle die Indizierung von Views als Feature der Wahl vorstellen. Damit lässt sich so eine Umgebung dann auch durchaus zügig nutzen, also sofern nötig.

Ein weiterer Punkt ist meiner Meinung nach zu erwähnen: Der Presentation Layer hat nichts im Data Source View (DSV) der Analysis Services zu suchen!

Und ja, ich möchte an dieser Stelle durchaus polarisieren! :-)

Meine Top 10 Ratschläge für komplexere SQL Server BI Projekte aus dem PASS Vortrag vom 9.3.2011 in Hamburg

2011-03-10T17:22:00.002+01:00

Gestern Abend hatten wir in Hamburg ein volles Haus! Vielen Dank an alle aktiven Teilnehmer unser Community!
Hier meine gestrige Liste der Ratschläge für komplexere und anspruchsvollere Business Intelligence Projekte. Ich hoffe, dass für jeden was dabei war. Das eine oder andere Thema werden wir sicherlich in den nächsten Monaten noch vertiefen. Es gab gestern ja schon einge sehr gute Diskussionen. Hat Spaß gemacht!
10. Think big, act small
9. (Be)herrsche und teile
8. Denke und spreche in Pattern
7. Wähle ein „quasi“ wiederverwendbares Datenbank Schema
6. RAW & Staging nutzen
5. Vermeide Optimierungen
4. Lerne alles über Partitionen!
3. Arbeite mit Queues / sein immer asynchron unterwegs
2. Paketausführung extern steuern & verhindern
1. Nutze den „ganzen“ Microsoft Technologie Stack

Best Practices in BI Projekten Vortrag auf dem SQL Server Usergroup Treffen in Hamburg (PASS)

2011-03-08T10:40:00.001+01:00

Morgen ist es ja schon wieder soweit! Unser reguläres Märztreffen für die SQL Server Community in Hamburg seht für Morgen Abend an.

Thema wird sein “Best Practices für die Arbeit mit SSIS & SSAS in komplexen und anspruchsvolleren Umgebungen”. Dabei werden wir uns 10 Ratschläge aus der Projektpraxis anschauen. Details zum Treffen findet Ihr auf www.sqlpass.de unter der Regionalgruppe Hamburg. Freue mich möglichst viele von Euch auf dem Treffen zu sehen!

Eigenschaften eines SSIS Paketes mittels DTSProperty auslesen

2011-03-04T22:32:00.001+01:00

Heute noch schnell eine Antwort auf eine Frage aus der Community.

In meinen “The Developer Side of Microsoft Business Intelligence” Vorträgen verweise des Öfteren darauf, dass es möglich ist die Eigenschaften eines SSIS Paketes bzw. eines Taskhosts eines Paketes auszulesen. Hier meine übliche Folie dazu.

Nur wie können nun die Eigenschaften ausgelesen werden ohne, dass man weiß wie die Eigenschaften denn nun im Detail jeweils heißen?

Da hilft mein bester Freund, die “foreach” Schleife, weiter! Und ein klein wenig müssen wir auch mit Try-Catch arbeiten.

Hier der Code, um die grundlegenden Eigenschaften eines Paketes auszulesen:

Microsoft.SqlServer.Dts.Runtime.Application app = new Microsoft.SqlServer.Dts.Runtime.Application();

           DialogResult result = openFileDialog1.ShowDialog();
           if(result == DialogResult.OK)
           {
               Package p = app.LoadPackage(openFileDialog1.FileName, null);
               foreach (DtsProperty dp in p.Properties)
                   {
                       try
                       {
                           listBox2.Items.Add(dp.Name +" = "+ dp.GetValue(p).ToString());
                       }
                       catch
                       {
                           listBox2.Items.Add(dp.Name + " <Error> ");
                       }
                   }
          }

Und so sieht das dann in meiner “offiziellen” Demo Anwendung aus. Hoffe doch sehr, dass hilft Euch bei Euren Dokumentationsprojekten weiter! Wenn nicht, dann einfach fragen.

März 2011 SQL Server Usergroup Treffen in Hamburg (PASS)

2011-03-02T17:25:00.001+01:00

Und schon wieder steht ein PASS Treffen vor der Tür! Nächste Woche (Mittwoch, den 9.3.2011) treffen wir uns wieder. Laut meinen letzten Infos treffen wir uns direkt in der Innenstadt. Der genaue Ort kommt mit der Einladung. Wie kommt Ihr an eine solche? Einfach auf www.sqlpass.de für die RG Hamburg registrieren! :-)

Dieses Mal bin ich mal wieder der Sprecher. Thema meines Community Vortrags wird sein “Best Practices für SSIS & SSAS in komplexen MS BI Umgebungen”. Es werden sowohl technische Hinweise gegeben als auch Ratschläge für die Vorgehensweise in BI Projekten gegeben.

Hoffe, dass viele von Euch die Zeit finden vorbei zu kommen!

Des Weiteren bitte ich Euch den Abend des 21.3.2011 schon mal zu blocken. Denn dort ist ein Extra PASS Event in Hamburg geplant. Wir werden wieder mal Besuch von “Ausserhalb” bekommen und ein super Community Abend steht uns allen bevor! Details folgen wieder per Einladung.

Was ist hier eigentlich installiert? SQL Server Versionen, Editionen etc. im Überblick

2011-02-26T10:44:00.001+01:00

Häufig treffe ich im Rahmen meines Jobs auf mir unbekannte SQL Server Installationen. Da macht es durchaus Sinn sich mal schnell einen groben Überblick über die installierten Instanzen, Versionen, Edition, Features etc. zu verschaffen.

Wie kommt man nun schnell und einfach an diesen Überblick? Welche kryptische DMV hilft? :-)

Es geht viel einfacher! Auf der SQL Server 2008 R2 DVD befindet das SQL Server-Installationscenter, welches nichts anderes ist als das SQL Server Setup. Das werden die meisten Leser schon mindestens einmal gesehen haben. Auf der linken Seite befindet sich ein Menü. Dort den Punkt Extras auswählen (im Englischen Tools). Nun kann der Bericht zur Ermittlung installierter SQL Server-Funktionen aufgerufen werden.

Es folgt der Microsoft SQL Server 2008 R2 Setup Discovery Report ! Dieser zeigt übrigens auch Details über SQL Server 2000 & SQL Server 2005 Installationen an.

Hier ein Beispiel:

Coaches’ Hell: Wie entwickle ich denn jetzt so ein Vorgehensmodell für Microsoft Business Intelligence Projekte?

2011-02-25T18:06:00.001+01:00

Kaum schreibe ich ein wenig aus der Praxis als Coach, schon kommen die Fragen. Bin ja selbst schuld.

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!

Eine Lösung kann natürlich sein, sich einen entsprechenden Partner zu suchen, welcher ein fertiges Modell liegen hat. Grundsätzlich ein guter Plan! Eine Sache gebe ich aber zu bedenken bzw. mit auf den Weg. Ruhig mal fragen, ob die Kollegen denn mehr als ein Modell dabei haben. Wenn schon von der Stange, dann bitte auch in der richtigen Größe und Farbe kaufen. Nicht jedem passt ja schließlich jedes Modell!

Und wenn man nun selbst drauf kommen muss! Was dann? Woher nehme ich meinen Kompass?

Puh… weites Feld, gibt viel zu tun!

Wie fängt man denn nun an? Es gibt eine Business Seite und eine Technik Seite. Da das hier ein SQL Server orientierter Blog ist, bleibe ich mal bei der technischen Seite. Und einigen wir uns kurz mal, dass die Einführung Projektmanagement auch übersprungen wird. :-)

Was bleibt? Genau, fast zu viel! Zum Beispiel die Definition des Ziels bzw. der Modellierung eines Cubes. Immer ein super spannendes gruppendynamisches Erlebnis für die ganze Arbeitsgruppe!

Ein Punkt, welcher Teilnehmer häufig weiterbringt, ist eine für sie verständliche Vorstellung des Ziels. Gerade für Einsteiger in das Thema BI sind Konzepte wie ein OLAP Cube doch recht abstrakt, oder? Da hilft für den Anfang dann eine vereinfachte Sicht auf die Dinge oft weiter. Das gilt besonders für Kollegen aus den kaufmännischen Abteilungen, welche spontan dem Projektteam zugeordnet wurden. Ihr seit uns herzlich willkommen!

Nur wie kann man sich nun so einen Cube vorstellen? Anwender als auch Berater schauen sich dann gern in Excel einen fertigen Cube an. Ja, das ist das Endergebnis, welches in einer GUI aufbereitet vorliegt. Meiner Erfahrung nach kommen aber gerade Anwender von diesem Standort aus schwer auf die notwenige abstrakte Ebene. Da wird sich mit Händen und Füssen an Excel geklammert. Bringt keinen Spaß.

Auch ein Sterndiagramm hilft hier meist nur bedingt weiter. Da es ja nun mal nicht wirklich einen Cube beschreibt, sondern die perfekte Quelle. Es muss eine Vorstellung des multidimensionalen Raums her.

Ok, bei drei Achsen usw. ist das ja noch fast kein Problem. Dummerweise haben Cubes häufig wesentlich mehr Achsen, sprich Dimensionen. Ein Ansatz aus meinen Coachings ist, dass sich die Teilnehmer diesen doch bitte mal als ein mehrdimensionales Array vorstellen sollen. Was ist ein Array? Das kennen die jüngeren noch aus dem Programmierkurs in der Schule.

Das hier

Array[i] = Wert

wird vielen bekannt vorkommen. Ist ein eindimensionales Array. Das “Teil” hat einfach mehrere Schubladen, welche durchnummeriert sind und wir sagen über i welche Schublade es sein darf.

Werden wir hiermit komplexer

Array[x,y] = Wert .

Das ist jetzt ein zweidimensionales Array. Ideal für einfache Koordinatensysteme.

Wie kommen wir jetzt zum Cube?

Das hier ist vereinfacht ausgedrückt ein Cube

Cube[a₁,a₂,a₃,a₄,….a_n] = Wert .

Jede Dimension in unserem Array steht nun für ein Attribut innerhalb des Cubes! Das lässt sich übrigens super am Flip Chart oder Whiteboard live entwickeln! :-)

Warum jetzt Attribut? Weil, hier werden sich jetzt die Älteren von uns dran erinnern können, wir ab spätestens SQL Server Analysis Services 2005 von einem attributsorientierten OLAP Cube sprechen. Das Attribut steht im Vordergrund. Was ist ein Attribut? Eine Eigenschaft innerhalb einer Dimension. Zum Beispiel eine Produktnummer, eine Produktgruppe oder ein Produktsegment. Alles Beispiele für Attribute. Und diese Attribute haben Ausprägungen. Also zum Beispiel “Holzschrauben” und “Metallschrauben” als Produktgruppen.

Wenn also a₁die Produktgruppe ist unda₂die Produktnummer, dann sieht unser Array nun so aus

Cube[Holzschrauben,4711-42,a₃,a₄,…a_n] = Wert

Unsere a₁& a₂ beschreiben eine sehr sehr einfache Dimension Produkte. Und a₃& a₄sind einfach mal Dimension Zeit mit Jahr und Quartal.

Cube[Holzschrauben,4711-42,2011,Q1,…a_n] = Wert

Schon bauen wir uns einen sehr einfachen Cube. Durch weitere Klammern, können wir nun noch die Dimensionen kenntlich machen.

Cube[ (Holzschrauben,4711-42) , (2011,Q1) ,…a_n] = Wert

Denke mal, dass die Idee verstanden ist. Und was ist Wert? Unsere Measure? Nein! Hier werden wir gleich ein wenig technischer im Modell und weisen drauf hin, dass Measures ja am Ende auch “nur” eine Dimension sind. Also unsere a_n ist die Measure Dimension.

Cube[ (Holzschrauben,4711-42) , (2011,Q1) , Umsatz in Euro] = Wert

Auf Basis dieses Modells können wir nun mit dem Würfel spielen. Zum Beispiel den Umsatz für eine andere Schraubenart abrufen.

Cube[ (Holzschrauben,0815-05) , (2011,Q1) , Umsatz in Euro] = Wert

Und uns auch in der Zeit bewegen.

Cube[ (Holzschrauben,0815-05) , (2011,Q2) , Umsatz in Euro] = Wert

Und auch andere Measures abfragen.

Cube[ (Holzschrauben,0815-05) , (2011,Q2) , Menge in Stück] = Wert

Damit wird auch dem Laien im übrigen schnell deutlich, dass ein multidimensionaler Raum sehr wahrscheinlich recht dünn besiedelt ist. Hilft auch bei vielen Diskussionen! Glaubt mir!

So, aber genug dazu. Damit stellt Ihr das Attribut in den Mittelpunkt. Wenn Ihr nun Eurer eigenes Vorgehensmodell definieren wollt oder müsst, dann orientiert Euch daran, dass Ihr die Attribute wirklich sauber definieren müsst. Sowohl für einen OLAP Cube als auch schon im Data Warehouse. Das ist natürlich einfach so dahin geschrieben. Es ist in Projekten oft eine echte Herausforderung!

Mit den Cube = Array Modell kann aber zumindest relativ schnell über das Wesentliche diskutiert werden. Klar, jetzt fehlen noch ein paar Seiten Projektmanagement dazu. Des Weiteren macht häufig ein Reifegradmodell für eine saubere projektübergreifende Strategie Sinn.

Ich hoffe mal, dass Euch dieser Kompass und die Dialogvorlage aus der Praxis ein klein wenig den Weg in Richtung Vorgehensmodell gewiesen hat.

Coaches’ Diary: Wie verwende ich SSIS & SSAS in Business Intelligence Projekten mit dem SQL Server denn nun wirklich richtig?

2011-02-23T18:45:00.001+01:00

Eine Frage höre ich im Verlauf von Coachings und Workshops immer wieder:

„Wie setzen wir denn nun die Werkzeuge bzw. die Dienste rund um den SQL Server wirklich richtig ein?“

Häufig stehen dabei die Werkzeuge wie das SSMS und das BIDS im Kontext von Business Intelligence Projekten im Vordergrund.

Es geht um die klassische Frage: Was ist richtig, was ist falsch? Und schon wird es alles andere als einfach!

Die Verantwortlichen in den Unternehmen für BI Projekte möchten nach Möglichkeit schnell zum Ziel kommen. Möglichst wenig Schleifen fliegen müssen. Zeit und damit Geld soll möglichst wenig verbrannt werden. Idealerweise soll schon vor dem Start klar sein wo, wann und wie die Ladung stattfindet und was während des Fluges so alles gereicht wird. Alles äußerst löbliche Ziele für ein Projekt! Wenn da das „aber“ nicht wäre.

Genaugenommen ist unser „aber“ hier ein „Randbedingungen“.

Jedes Projekt hat Randbedingungen. Und jeder Kunde definiert diese anders. Dazu kommt, dass diese Definition in den seltensten Fällen ein zu 100% bewusster Prozess ist.

Die Randbedingungen in Projekten bestimmen in der Regel, was sich später als falsch oder richtig herausstellen wird. Genau, das wird auch erst später deutlich! Dabei müssen doch jetzt Entscheidungen getroffen werden. Idealerweise noch vor dem Start eines Projektes! Und schon sind wir in der Schublade mit den Herausforderungen des klassischen Projektmanagements gelandet. Ein wenig muffig hier.

Wie kommen wir hier wieder raus?

Reduzieren wir das Ganze doch erst mal auf den technischen Aspekt. Technik wird sich ja wohl nur richtig oder falsch anwenden lassen, oder? Das trifft auf viele technische Werkzeuge zu. Bestimmt auch auf die eine oder andere Software, vielleicht sogar auf einige BI Lösungen. Nur bestimmt nicht auf den Business Intelligence Stack von Microsoft.

Der Microsoft BI Stack ist ein ehrlicher und gut ausgestatteter Werkzeugkasten, welcher keine falsche Versprechungen macht. Mittlerweile zieht der Vergleich mit dem Werkzeugkasten auch nicht mehr, eigentlich müssten wir hier schon von einem ganzen Schrank sprechen. Nehmen wir zum Beispiel auch noch die SharePoint Welt mit auf, dann sind wir sinnbildlich schon fast bei einer ganzen Garage. Und wurden in diesen nicht die innovativsten Lösungen entwickelt? Aber wir schweifen ab.

Was ist denn nun richtig oder falsch? Hier möchte ich kurz das Bild des Golfers bemühen. Ja, genau diese Gattung Mensch, welche einen kleinen Ball mit einem teilweise wirklich nicht ergonomischen Schläger in einem unübersichtlichem Gelände in ein viel zu kleines Loch befördern möchte. Wenn man es genau bedenkt, dann ist der Vergleich zum BI Projekt gar nicht so weit, oder? Und diese Golfer nehmen Stunden bei Golftrainern. So weit, so gut. Nun ist es aber so, dass es beim Golfen kein falsch oder richtig gibt. Wie kommst? Da steht nun der ehrgeizige Golfer. Möchte seinen Schlag verbessern, was in der Regel bedeutet, weiter und öfter mal dahin wo er ihn hinhaben will. Der Trainer gibt Tipps. Mehr Gewicht nach links, weniger das Handgelenk bewegen usw. Was passiert beim ersten Schlag? Geht völlig quer. Warum? Weil der letzte Trainer, den man hatte, genau das Gegenteil geraten hat. Mehr Gewicht nach rechts, Schwung aus der Schlägerhaltung usw. Wer hat nun Recht? Das fragt sich unser Golfer und zahl ein wenig zerknirscht die Trainerstunde. Beide Trainer schlagen im Übrigen total tolle Bälle und haben ein traumhaftes Handicap. Sie haben jeweils ihren eigenen Stil beim Abschlag und diesem bleiben sie treu. Wir könnten hier auch von einem Plan sprechen. Und wer sich mal mit einem professionellen Golfer unterhalten hat, der bekommt auch eine Impression davon wie komplex dieser Plan sein kann. Und wenn wir nun munter zwischen diesen Stilen bzw. Plänen wechseln, nun ja, klar, dass es uns da den Abschlag verhagelt. Angeblich erkennt man einen guten Golftrainer auch daran, dass er nicht versucht dem Golfer seinen Stil aufzudrücken, sondern bestrebt ist die vorhandene Technik zu verbessern.

Also gibt es kein richtig oder falsch. Nur ein “passt zum Plan” oder “passt nicht zum Plan”! Was ist nun in unserem BI Projekt der Plan? Nennen wir es mal Konzept.

Und was lernen wir da draußen an der Projektfront? Eine deutliche Unterschätzung bzw. Abwertung von klassischen konzeptionellen Phasen. Mitunter kommt sogar das Gefühl auf, dass „das Konzept“ bereits ein Unwort geworden ist. Alles muss mittlerweile pragmatisch und agil sein. Nicht, dass diese Ansätze falsch wären, aber auch hier ist ein mehr oder weniger klar definiertes Ziel von Vorteil.

Aber kommen wir zur Ausgangsfrage zurück: Wie verwende ich SSIS & SSAS denn nun richtig?

Unterscheiden wir mal zwischen allgemeinen Best Practices, welche sich um Performance Fragen drehen, und Architekturen, welche das Gesamtbild der späteren Lösung entscheidend bestimmen.

Best Practices gibt es mittlerweile viele. Und die meisten sind auch in den häufigsten Fällen allgemein genug, um sie fast immer anzuwenden.

Kommen wir zur Architektur. Hier stellt sich die Frage: Wie viel Feenstaub darf es denn sein?

Hier hilft eine klare und möglichst realistische Vorstellung des Ziels deutlich weiter. Klare Antworten auf Fragen wie „Wer arbeitet später mit dem System?“ oder „Wie viele arbeiten später damit?“. Auch immer gern im Vorwege gewusst: „Warum arbeiten die überhaupt damit?“. Viel zu häufig wird davon ausgegangen, dass das doch klar ist. Fragen lohnt sich hier auf jeden Fall. Allein schon der Antworten wegen.

Ok, Versuch es auf den Punkt zu bringen. :^)

Der Microsoft BI Stack ist eine erwachsende Umgebung, welche neben einer gewissen technischen Expertise auch einen belastbaren Plan benötigt, um ans Ziel zu kommen!

Dieser Plan darf durchaus mehrstufig sein. Ich mag ja die Worte Grob- und Feinkonzept kaum schreiben.

Des Weiteren ist es in Projekten gar nicht so unüblich, dass Entscheidungen unterwegs mal zurückgenommen werden. Alles gut, ehrlich. Es muss nur in geordneten Bahnen verlaufen. Viel zu häufig wird Projektmanagement mit dem Abarbeiten eines unveränderlichen Plans verwechselt.

Es gibt eine ganze Reihe von Randbedingungen, welche für die Auswahl der jeweiligen Methode, Vorgehensweise, Vorgangs- und Reifegradmodells berücksichtigt werden müssen.

Hier ein paar Tipps aus der Coaching Praxis:

Stellt Euch die Frage, welche Entscheidungen getroffen werden müssen. Das fängt schon mit der Wahl der SQL Edition an. Entwickelt im Dialog einen Entscheidungsbaum, welcher die jeweiligen Entscheidungen beinhaltet. Dokumentiert damit, welche Auswirkungen auf ein Projekt die jeweilige Entscheidung hat. Visio hilft hier gern.

Spiegelt an diesem Entscheidungsbaum später Eure Anforderungen. Also so etwas wie 24x7 Betrieb oder auch near-real time latency der Daten. Natürlich ist auch das erwartete Datenvolumen wichtig. Sprechen wir über 80 GB oder 8 TB? Der SQL Server kann beides stemmen. Nur der Weg ist halt ein anderer.

Berücksichtigt die Rahmenbedingungen des Projektes. Also zum Beispiel: Wie viele Berater sollen, müssen oder können parallel was zum Erfolg beitragen? Die Antwort ist meist erschreckend.

Bei uns kommt zum Beispiel noch die Frage dazu, ob wir in dem Projekt mit Repositories für SSIS & SSAS arbeiten oder nicht. Das passt auch nicht immer.

Wir sehen, dass der Plan (und ja, ich nenne es Konzept) den Einsatz der Werkzeuge bestimmt und nicht umgekehrt.

„It depends!“

(Alte Beraterweisheit, welche sicherlich schon beim Bau der Pyramiden ein alter Hut war.)

Analysis Services Scale-out Vortrag auf der SQLBits 8 in Brighton, UK

2011-02-06T13:08:00.001+01:00

Wie die Zeit doch rennt! Gerade erst wurde auf der SQLBits Site mein Vortrag von der SQLBits 7 Konferenz als Video veröffentlicht, schon gibst die SQLBits 8 ! Die Engländer geben da echt Gas.

Und ich bin stolz berichten zu dürfen, dass ich wieder als Sprecher dabei sein darf! Bin wieder als Sprecher für den Freitag ausgewählt worden. Ihr wisst ja noch, dass die SQLBits Konferenz aus drei Tagen besteht:

Pre Conference full day training seminars
Pay Friday (content is hand picked) <- da bin ich bei… :-)
free Community Saturday

Dieses Mal darf ich von meinen Erfahrungen mit Scale-Out Szenarien mit Analysis Services (und ein wenig SSIS) berichten. Weiter unten ist mein Abstract für die Session.

Wie ich ja schon mal geschrieben habe: Die SQLBits Konferenzen lohnen sich auf jeden Fall für jeden SQL Server Pro! UK ist günstig zu erreichen und man mal gar nicht mehr so teuer wie früher. Daher, kommt vorbei und besucht die SQLBits! Vielleicht kommen die Deutschen vor Ort dieses Mal sogar in den zweistelligen Bereich. Ich freu mich drauf!

28 Weeks later - How to scale-out your MS Business Intelligence environment
This session will demonstrate possibilities to scale-out your existing Microsoft Business Intelligence environment. The SQL Server provides much functionality that increases the scalability and flexibility of your solution by distributing data and jobs among low-priced commodity servers.
We will explore the ways how to use link dimensions, link measure groups and remote-partitions in Analysis Services. With the approach of synchronization and load balancing we can increase the high availability of the service.
We also take a close look on the Shared Scalable Database feature and how to use your SAN environment wisely.
This session will demonstrate an approach how to use Analysis Management Objects (AMO) to manage our scalable environment very flexible and without much pain.
But wait, there's much more, because our ETL Jobs also need assistance to scale out. This session will provide an approach to build an alternative decentralized SSIS scheduling system. This approach is also cloud ready!
This session delivers many samples and source code to demonstrate the approaches.

Der MSDN Tour Bus kommt nach Hamburg und besucht die SQL Server Community PASS!

2011-01-27T12:21:00.001+01:00

Hier schon mal die ersten Infos zum MSDN Tour Bus Stopp in Hamburg.

Wie ja schon einige von Euch mitbekommen haben, ist es uns gelungen genau an unserem Community Abend, dem 10.02.2011, den MSDN Tour Bus in unsere schöne Stadt zu bekommen! Vielen Dank dafür an all die Community Feen und Elfen bei Microsoft und den Agenturen! Wir führen den Stopp in Kooperation mit der wiedererwachten .net Usergroup in Hamburg durch! Super Jungs (und Mädels?), dass Ihr wieder aktiver seit!

Der Bus wird laut der aktuellen Planung gegenüber der Microsoft Niederlassung in Hamburg stehen. Also sehr gut mit allen Verkehrsmitteln zu erreichen. Die SQL Server Community PASS Deutschland e.V. Hamburg hat den Bus exklusiv von 17 Uhr bis 19 Uhr.

Hier der offizielle Text von MS dazu:

MSDN, das Microsoft Developer Network, geht mit hochwertigen Vorträgen zu aktuellstem Entwicklerwissen im technikbeladenen, komfortablen MSDN-Bus auf Deutschland-Tour und macht auch in Ihrer Nähe Halt.

Nutzen Sie als Entwickler die Möglichkeit, im MSDN-Bus direkt von Microsoft-Referenten das Neueste aus der Softwareentwicklung zu erfahren und aktuelle Technik hautnah erleben zu können. Sei es Visual Studio 2010, Web-Entwicklung und Internet Explorer 9, Cloud-Dienste wie Windows Azure, das Schreiben von sicherem Code oder eines vieler weiterer Themen, etwa Windows Phone 7 oder Open Source & Standards bei Microsoft.

Im Umfeld zahlreicher Demos, How-To-Anleitungen und Sourcecodes können Sie mit Microsofts Experten und Gleichgesinnten fachsimpeln und netzwerken. Außerdem zeigen wir Ihnen, welche Services und Programmatiken MSDN für Sie anbietet.

Bitte beachtet, dass es sich um eine Geschlossene Veranstaltung handeln wird. Daher dieses Mal besonders auf die Einladung vom Rolf achten und sich registrieren, da wir verhindern wollen, dass jemand bei dem Wetter draußen stehen muss.

Wir werden Euch über die weiteren Details wie Themen und MS Speaker auf dem Laufenden halten!

Hier findet Ihr erste Infos, Karte und Bilder: http://www.msdn-on-tour.de/Details1002.aspx

SQL Server asynchrone Trigger & Service Broker im Repository

2011-01-26T15:55:00.001+01:00

Da schreibe ich über unsere Repositories und schon gibst Schimpfe aus der Community! Sascha hat gesagt, dass er Trigger einsetzt… geht ja man mal gar nicht! So von wegen schlechtes Vorbild und so! Trigger sind doch so was von bööööööööse…… kommen gleich nach Cursorn! :-)

Recht habt Ihr! Grundsätzlich in einer LOB / OLTP Umgebung bin ich sehr selten ein Fan von Triggern. Wobei ich diese Diskussion immer wieder mit ISVs führen muss. Daher hier jetzt mal ein paar Worte dazu…

Warum sind Trigger eigentlich böse? Sind doch ne coole Sache, oder?
Ja, Trigger sind von der Idee her sogar äußerst praktisch. Logik wird ausgelöst durch ein DML oder DDL Statement. Es muss nicht extra eine Prozedur gestartet werden. Das unerfreulich an einem Trigger ist die Tatsache, dass er out-of-the-box immer synchron ist. Das geht leider ganz gewaltig zu Kosten der Gesamtperformance eines Systems, wenn da ein wenig mehr Last drauf kommt. Damit ist gemeint, dass die Aktion, welche der Trigger startet, immer GENAU in dem Moment “passiert”, in welchem der Trigger aufgerufen wird. Das macht in einigen Bereichen durchaus Sinn, aber in den meisten Fällen ist diese 100% Synchronität nicht notwendig. Zum Beispiel in fast all meinen Repository Beispielen. Daher verwenden wir so genannte asynchrone Trigger!

Ok, was sind denn jetzt bitte asynchrone Trigger?
Mit asynchronen Triggern meinen wir in der Regel einen Trigger, welcher einen Service Broker Service (Service ist immer wichtig…) nutzt! Service Broker führt leider in sehr vielen Umgebungen ein Schattendasein, obwohl es jedem, wirklich JEDEM, SQL Server seit 2005 “beiliegt”. (Ok, von kleinen Einschränkungen mal abgesehen.) Und Trigger sind, neben vielen anderen, ein sehr gutes Beispiel für den produktiven und überhaupt nicht esoterischen Einsatz von Service Brokern!

Und was ist dieser “Service Broker”? Und brauche ich dafür eine Enterprise Edition?
Hier kommt ein wenig Text aus der BOL: “Service Brokerunterstützt Datenbankentwickler beim Erstellen zuverlässiger und skalierbarer Anwendungen. Da Service Broker Teil von Database Engine (Datenbankmodul) ist, ist auch die Verwaltung dieser Anwendungen Teil der routinemäßigen Verwaltung der Datenbank.

Service Broker stellt für SQL Server Queuing und zuverlässiges Messaging bereit. Service Broker wird für Anwendungen verwendet, die eine einzige Instanz von SQL Server verwenden, sowie für Anwendungen, die Arbeit über mehrere Instanzen verteilen.

Innerhalb einer SQL Server-Instanz stellt Service Broker ein leistungsfähiges asynchrones Programmierungsmodell bereit. Datenbankanwendungen verwenden normalerweise asynchrone Programmierung, um die interaktive Antwortzeit zu verkürzen und den Anwendungsdurchsatz allgemein zu erhöhen.

Außerdem bietet Service Broker zuverlässiges Messaging zwischen SQL Server-Instanzen. Service Broker unterstützt Entwickler beim Konzipieren von Anwendungen aus unabhängigen, eigenständigen Komponenten, den so genannten Diensten. Anwendungen, die die über diese Dienste bereitgestellte Funktionalität benötigen, verwenden für die Interaktion mit den Diensten Nachrichten. Service Broker verwendet TCP/IP für den Austausch von Nachrichten zwischen Instanzen. Service Broker enthält Features, die den nicht autorisierten Zugriff über das Netzwerk verhindern helfen und über das Netzwerk gesendete Nachricht verschlüsseln.”

Das liest sich für viele Entwickler äußerst spannend, aber leider häufig auch ein wenig weit weg von ihren täglichen Herausforderungen! Dem ist aber gar nicht so! Daher, gebt dem Service Broker eine Chance! Bald wollt Ihr nicht mehr ohne! –> “Service Broker” gefällt mir!

Wieder einmal das Repository… oder auch Repository driven BI / everything in SQL Server FAQ…

2011-01-24T08:58:00.001+01:00

Auf Repositorys und Meta Daten komme ich ja immer wieder gerne zu sprechen. :^)

Zuletzt hatte ich die Gelegenheit meine Ideen von Repository getriebenen Architekturen einer Community in Nürnberg, in der PASS Regionalgruppe Franken, vorzustellen. Vielen Dank an den Klaus Oberdalhoff für die Organisation dieses Events und vielen Dank an die Raumsponsoren! Kommt gar nicht so häufig vor, dass ich bei einem RG Treffen vor mehr als 40 Teilnehmern spreche. Kam fast ein wenig Konferenzstimmung auf. Des Weiteren war die Session schön interaktiv und es wurden einige sehr gute Fragen gestellt.

Ein paar dieser Fragen und natürlich die Antworten hier nun für den Online Teil der Community. Fragen folgen in Fett.

Ein wesentlicher Teil der Fragen zielte darauf ab, was denn nun so ein Repository ausmache bzw. ob das nichts anderes ist als eine Konfiguration?

Zwar bauen meine Ansätze immer auf einem Repository auf, welches die beschreibenden Daten für die eigentliche Zielplattform hält, aber es handelt sich dabei nicht nur um eine andere Organisationsform einer Konfigurationsdatei für eine existierende Technologieplattform!

Ich vergleiche das gerne mit einem Navigationsgerät. Technologie ist klar, das gute Stück kann sich super orientieren und mit ein wenig Kartenzauber und Routenfindung äußerst praktisch. Nur wie verwenden wir es? Wir geben in der Regel die Route nicht im Detail vor, also jede Straße, jede Kreuzung usw. Wir kommunizieren über eine Metaebene mit der eigentlichen Logik, welche eine für uns plausible Information abfragt: Eine Zieladresse. Die restliche Magie findet auf sehr wahrscheinlich mehreren Ebenen darunter statt. Der letzte Level kennt den aktuellen Standort und kommuniziert wiederum mit dem Routenplaner eine Etage über ihm, usw. Also ist das Adressbuch eine Metaebene (-> Repository) und auch das Kartenmaterial (noch eine Ebene).

Daher ist ein wesentlicher Aspekt des Ansatz, dass es mir NICHT allein um das an-codieren der SQL Server Funktionen geht, sei es nun SMO oder AMO. Die eigentliche Magie spielt sich meiner Meinung nach in den Ebenen darüber ab. Denn in diesen Ebenen werden erweiterte Funktionalitäten hinzugefügt. Ein bei mir sehr beliebtes Muster (ich sage mal absichtlich nicht Pattern, das führt nur zu Missverständnissen) ist das Hinzufügen der Möglichkeit Objekte zu Gruppen zusammenzufassen, was in der Regel auf der Zielplattform nicht möglich bzw. nicht “Solution” übergreifend anwendbar ist.

Beispiele für Ziel- bzw. Technologieplattformen können sein: SQL Server Analysis Services (SSAS), SQL Server Integration Services (SSIS), SQL Server Replikation, Trigger, Service Broker, Extended Events oder auch SharePoint.

Und Beispiele für Gruppen können damit sein:

- Attribute in SSAS Projekten, aber über mehrere Dimension und auch Solutions hinweg.
- Steuerung von Triggern bzw. asynchronen Triggern, welche auch noch mit Service Broker Diensten verbunden sind.
- Abonnenten innerhalb einer Replikationsstruktur können sehr gut zu Gruppen zusammengefasst werden, um diese mittels eines Eintrags im Repository an einen anderen Verteiler “zu hängen”. Glaubt mir, sowas macht in schön großen Replikationsstrukturen (>200 Abonnenten) und 1-2 mehr Servern richtig Spaß!
- Listen und was alles damit zusammenhängt (hehe…) innerhalb von SharePoint. Damit lassen sich auch schöne Projekte realisieren, aber sprengt gerade den Rahmen hier.

Wie steuere ich das dann alles von oben? In der Regel durch eine domänenspezifische Sprache, wobei ich gerne noch weiter gehen möchte und das einfach mal projektspezifische Sprache (PSL) nenne. Also hier drin steckt meiner Meinung nach die eigentliche Magie (ich mag das Wort in dem Zusammenhang) in den Projekten.

Wie komme ich auf sowas? Schon sehr früh, noch zu Zeiten als ich mit Clipper (und es war Sommer 87…*flöt*) und MUMPS unterwegs war, habe ich mir Codegeneratoren entwickelt, welche zum Beispiel das damalige Clipper (vor dem CA Zeug) um die Möglichkeit von eigenen Klassen erweitert haben. Sowas prägt fürs ganze IT-Leben! by the way, Dank an den Jan Welker für den Tipp mit T4! Äußerst spannend!

Wie speichere ich das Repository? Schwieriges Thema… gerne als einfache relationale Struktur. Dann kann mittels SQL DML Befehlen direkt darauf eingewirkt werden und auch evtl. notwendige GUIs brauchen “nur” SQL DML beherrschen. Damit auch mal was passiert in den Strukturen kommen da dann ausnahmsweise Trigger dazu, welche auf Veränderungen reagieren. Die Daten im Repository bildet dann die Strukturen auf der jeweiligen Zielplattform ab.

So, damit sind die wohl häufigsten Fragen persistiert worden. Bei weiteren Fragen einfach auf mich zukommen!

Für Alle, die die Session Repository Driven Business Intelligence aka The Developer Side of MS BI bisher nicht gesehen haben, die gibt es als englischen Cast auch noch auf den SQLBits Seiten!

Repository driven SQL Server Business Intelligence Vortrag in der Region Franken ( Nürnberg / Fürth )

2011-01-10T17:17:00.001+01:00

In der nächsten Woche am 18.01.2011 halte ich in der Community PASS Deutschland e.V. Regionalgruppe Franken in Nürnberg meinen “Einsteiger" Vortrag zum Thema Repository driven Business Intelligence mit dem SQL Server:

Developer Side of Microsoft Business Intelligence

Der Microsoft SQL Server bietet eine ganze Reihe von äußerst mächtigen Diensten und Werkzeugen für die Erstellung von Business Intelligence Lösungen. Warum sollte sich dann überhaupt ein BI Berater mit den Möglichkeiten der Programmierbarkeit des SQL Servers beschäftigen? Weicht er damit nicht vom Standard ab? Und warum sollte sich ein Programmierer mit BI befassen? Sind die BI relevanten Dienste vom SQL Server etwa nicht fertig?

Die Wahrheit ist, dass eine wesentliche Stärke des SQL Servers, neben den bekannten Werkzeugen, die Verfügbarkeit von diversen sehr gut dokumentierten APIs ist. Diese APIs können sehr gut im Rahmen von BI Projekten genutzt werden und die Integrationsfähigkeit einer BI Lösung um ein vielfaches erhöhen. Alle in diesem Workshop vorgestellten Schnittstellen sind offiziell von Microsoft beschrieben worden und werden in zukünftigen Versionen unterstützt werden.

Vor dem Einsatz von Technologie kommt aber immer die zielgerichtete Konzeption der Lösung. Es wird gezeigt, wann und wie sich der Einsatz von Programmierung in BI Projekten tatsächlich rechnet und welche Voraussetzungen dafür erfüllt sein müssen.

Ein ganz wesentlicher Punkt aus der Erfahrung heraus ist die Nutzung der Abstraktion der Anforderungen und der Technologie als Architekturansatz im Design von Business Intelligence Lösungen.

Es werden sowohl Analysis Services, Integration Services als auch die relationale Engine untersucht und entsprechend mit einem Repository angesteuert und genutzt.

Details zum Treffen findet Ihr hier:

http://www.sqlpass.de/Regionen/Deutschland/Franken/tabid/71/Default.aspx

https://www.xing.com/events/developer-side-of-microsoft-business-intelligence-665284

Würde mich freuen möglichst viele von Euch dort aus der Community kennenzulernen!

Frohes neues Jahr 2011 !

2011-01-02T18:04:00.001+01:00

Wow, es ist schon 2011! Wie die Zeit doch vergeht. Hoffe Ihr seit alle gut reingekommen!

Die letzten Monate des Jahres waren wieder sehr arbeitsreich und so geht es auch gleich weiter… aber ich habe diverses organisiert bekommen in Sachen Community Arbeit! Daher bin ich mir recht sicher, dass es 2011 einiges Neues für die Community auf diesem Kanal geben wird!

Aber erst mal zu den akutellesten Terminplanungen für 2011. Ist zwar noch früh, aber die ersten Termine stehen schon:

Bereits am 18.1.2011 bin ich als Redner zu Gast in der SQL PASS Regionalgruppe Franken (Nürnberg)

und am 16.5.2011 bin ich als Redner in der SQL PASS Regionalgruppe Köln/Bonn dabei.

Des Weiteren findet vom 7. bis zum 9.4.2011 die SQL Server Konferenz SQLBits 8 in Brighton, UK statt. Immer für einen Besuch gut! Und wo wir gerade bei den SQLBits sind, mittlerweile sind die Sessions der SQLBits 7 online gegangen. Hier gehst zum Video meiner Session >The Developer Side of the Microsoft Business Intelligence stack<.

PASS Summit, TechEd & TechNet… was für eine Woche!

2010-11-13T12:41:00.001+01:00

Wow, das war doch mal eine Woche! Da gab es endlich wieder etliche Überschneidungen im Kalender.

Wir hatten den PASS Summit in Seattle, die TechEd Europe in Berlin und noch ein TechNet MS SQL & BI Seminar in Hamburg.

Die Keynotes des Summits gabs auch gleich noch als Livestream. Sessions der TechEd sind wie gewohnt bereits online verfügbar.

Sowohl auf dem Summit als auch auf der TechEd wurden diverse Ankündigungen bzgl. des neuen SQL Servers gemacht. Highlights sind wohl u. a.:

Project Crescent (ultra cooles Reporting / Dashboard Tool auf Basis Silverlight)
Business Intelligence Semantic Model (BISM)
VertiPaq in der relationalen Welt (eine Renaissance von ROLAP ?)
und vieles, vieles mehr…

Und es gab dazu viele Emotionen diese Woche.

Chris Webb z. B. sprach da wohl vielen von uns aus der Seele.

http://cwebbbi.wordpress.com/2010/11/11/pass-summit-day-2/

Da wurde wohl das eine oder andere ein wenig zu euphorisch angekündigt und präsentiert. Zumindest entstand bei einigen der nachhaltige Eindruck, dass das klassische UDM keine große Zukunft mehr hat. Das Gerücht, dass MDX tot sei und DAX nun für alles herhalten muss entstand. Microsoft hat (fast schon ungewohnt) schnell auf diese Gerüchte reagiert.

Selbst Amir Netz hat den Post von Chris mit einem Kommentar bedacht. Müsst Ihr ein wenig nach unten blättern.

Als Antwort an Alle, die nun ähnliche Bedenken haben, was die Zukunft von UDM, MDX, OLAP & Co ist, hat das SQL Server Team (namentlich T.K. Anand) nun folgenden Post verfasst:

http://blogs.technet.com/b/dataplatforminsider/archive/2010/11/12/analysis-services-roadmap-for-sql-server-denali-and-beyond.aspx

Kurzfassung: BISM soll UDM (OLAP) nicht ersetzen! Wir werden noch viele weitere Jahre (Releases) unseren Spaß und Freude mit MDX & Co haben können. Sofern natürlich gewünscht, da wir alle (also mal so als BI Pro an BI Pro) dem BISM und DAX eine Chance geben sollen. Ich für meinen Teil bin auf jeden Fall neugierig auf diese weitere Seite von MS BI und werde sie darauf gehend prüfen, ob sie weitere Bemühungen hinsichtlich einer umfassenden Repository Umgebung überflüssig machen wird. Bin ja bekanntlich ein Fan von Repositories für die Vereinfachung und Steuerung von komplexeren DWH und BI Umgebungen. Schauen wir mal, es bleibt weiterhin Spannend!

Wo wir gerade bei DAX sind. Da war ja auch noch das TechNet Seminar in Hamburg. Thema war “Managed Self-Service Business Intelligence mit …” aktuellen Bits und Bytes. Mein Job während dieser Tagesveranstaltung in der Hamburger MS Niederlassung war eine zweistündige recht technische Session über das aktuelle PowerPivot in Excel und SharePoint. Hat mir auf jeden Fall viel Spaß gemacht unsere (PSG) Erfahrungen mit dieser Technologie an Kunden & Partner weiterzugeben.

Im Anschluss an das TechNet Seminar fand bei Microsoft auch noch das monatliche Treffen der Hamburger SQL Server Community (PASS) statt. Vielen Dank an MS für den Raum, den Sprecher (Frank) und das Catering!

MDXScript Object in Analysis Management Objects (AMO)

2010-11-04T17:51:00.001+01:00

Eine Frage kommt im Zusammenhang mit den Analysis Management Objects immer wieder: Wie kann auf das MDX Skript zugegriffen werden?

Und auch dafür sind tatsächlich nur wenige Zeilen Code notwendig! AMO sei Dank!

Mit diesem Codeschnipsel lese ich das MDX Skript aus und zeige ihn in einer Textbox an. Statt der Textbox könnt Ihr natürlich auch eine Variable oder sonst was verwenden.

using Microsoft.AnalysisServices;

…

Server srv = new Server();

srv.Connect("localhost"); // Dein Server Name!

myTB.Text = srv.Databases.GetByName("Adventure Works DW 2008").Cubes.GetByName("Adventure Works").MdxScripts[0].Commands[0].Text; // Deine SSAS DB & Dein Cube

srv.Disconnect();

So, und natürlich kommt auch gleich wieder die Frage wie denn nun das MDX Skript geschrieben werden kann? Mit dem BIDSHelper ist es ja möglich dies innerhalb des Business Intelligence Development Studios (BIDS halt) zu machen.

Auch hierfür sind nur wenige Zeilen Code notwendig. Also genaugenommen brauche ich dazu nur eine weitere Zeile.

using Microsoft.AnalysisServices;

…

Server srv = new Server();

srv.Connect("localhost");

srv.Databases.GetByName("Adventure Works DW 2008").Cubes.GetByName("Adventure Works").MdxScripts[0].Commands[0].Text = myTB.Text;

srv.Databases.GetByName("Adventure Works DW 2008").Cubes.GetByName("Adventure Works").MdxScripts[0].Update(); // Wichtig! Hiermit wird das “kurz” mal aktualisiert.

srv.Disconnect();

Die Bereitstellung des MDX Skriptes geht äußerst schnell. Probiert es einfach mal aus!

LastProcessed Status einer Cube Partition mittels SSIS auslesen

2010-10-30T17:00:00.001+02:00

Als ein Feedback auf meine letzten Casts bekam ich die Nachfrage, ob und wie denn der LastProcessed Status einer SSAS Cube Partition mittels der SSIS Skriptkomponente und Analysis Management Objects ausgelesen werden kann. Als Antwort darauf habe ich wieder einen kleinen Cast aufgenommen. Ich hoffe alle wesentlichen Schritte sind klar und verständlich geworden.

Viel Erfolg damit!

SSIS Skriptkomponente als Datenquelle verwenden für z. B. AMO, MDX Queries etc.

2010-10-27T18:00:00.001+02:00

Aufgrund des Feedbacks zum Post über meine AMO Aktivitäten für den Aufbau eines Microsoft Business Intelligence Repositorys, habe ich wieder einen kleinen Webcast aufgenommen. In diesem zeige ich die Verwendung des SSIS Skripttasks als Datenquelle für Analysis Management Objects oder auch MDX Abfragen. Des Weiteren zeige ich auch wie Ihr Euch mit SSIS Test- bzw. Demodaten erzeugen könnt.

Viel Erfolg beim selbst ausprobieren!

Analysis Services Metadaten mittels AMO in einem SSIS Task auslesen

2010-10-24T14:56:00.001+02:00

Kurze Rückmeldung von mir. Bin vom PASS Camp 2010 R2 zurück. Meine Session lief wohl soweit erfolgreich. Das Camp als Ganzes war aus meiner Sicht ein voller Erfolg! Details dazu werden noch folgen!

Bin an der weiteren Integration eines umfassenden Repositorys für die Microsoft BI Umgebung. Ein Aspekt dabei ist der Zugriff auf die Metadaten eines SSAS Cubes mittels Analysis Management Objects. Bin zurzeit am entwickeln einer Komponente für die Integration Services für den direkten Zugriff auf einen Würfel und seine Informationen. Erste Tests mit der Skriptkomponente laufen bereits sehr gut. :-)

Microsoft hat auch eine Software für 3D Modelle!

2010-10-14T09:02:00.001+02:00

Hätte ich ja fast vergessen! Mal was ganz anderes…

Ich war vorgestern Abend auf dem MS TechTalk zum Windows Phone 7. Da kam unteranderem das Thema Entwicklung von Spielen für das WP7 auf und die Frage woher der Entwickler denn 3D Modelle bekommen könnte bzw. womit er diese erstellen sollte. Es wurden alle Top Tools am Markt genannt. Da fiel mir ein, dass ja Microsoft vor ein paar Jahren ein ähnliches Tool gekauft hatte (bzw. die Company drum rum), ich kam zwar nicht auf den Namen, aber eine Stimme hinter mir erinnerte sich dann: TrueSpace! Dank an den Unbekannten! Yepp, TrueSpace (Caligari) gehört zu MS und TrueSpace gibst schon seit einiger Zeit for-free!

TrueSpace kann meinem Kenntnisstand nach auch Modelle für DirectX (und XNA) erstellen. Habe gerade keine Zeit dieses zu testen, aber hier der Link zum Download.

Excel Cube Funktionen (dynamische CUBEMENGE)

2010-10-13T14:37:00.001+02:00

Auf meinen Cast für das Beispiel für die Excel Cube Funktion CUBEMENGE bekam ich nun das Feedback, dass das zum Teil zu schnell ging. Zwar kann ja die Pause Taste gedrückt werden, aber nicht jeder kam mit, wie ich die Zellen denn nun im Excel miteinander verknüpfe. Daher hier nun eine Übersicht darüber:

Also, im oberen Ausschnitt aus Excel habe ich eine Liste (keine Excel Liste!) erstellt, welche eine Nummerierung, einen endbenutzerfreundlichen Namen und die jeweilige Beschreibung einer Menge (Set) in MDX enthält. Das läuft zusammen in einer Excel Formel mit der Funktion VERWEIS. Diese holt sich als “Parameter” eine Zahl (oben die “1”). Die Zelle wird aber gefüllt über das Listboxelement, welches ich im eigentlichen Report/Dashboard im unteren Ausschnitt verwende. Diese Listbox holt sich ihre Elemente für die Darstellung wiederum aus der selben Liste.

Die eigentliche Magie steckt aber in der Formel in C3 (untere rote Ellipse) mit der CUBEMENGE Funktion. Wir geben dort als Bezeichner einfach “menge” aus, aber mittels der CUBERANGELEMENT Funktion greifen wir dann in der Spalte D auf die (unsichtbaren) Elemente innerhalb der Menge in C3 zu! Die Elemente in der Spalte D wiederum dienen den CUBEWERT Funktionen in den Spalten E & F als Parameter.

Durch die Auswahl eines Eintrags in der Listbox wird die Ordnungszahl des Eintrags in eine Zelle geschrieben (obere rote Ellipse) und dient der VERWEIS Funktion als Parameter. Das Ergebnis (ein MDX Ausdruck) ist dann der Parameter für die CUBEMENGE Funktion (untere Ellipse).

Hoffe, das hier hat das Konzept noch ein wenig verdeutlicht. Bei Fragen, mich sonst bitte einfach ansprechen!

Weiterer Webcast über die Cube Funktionen in Excel (dynamische CUBEMENGE)

2010-10-12T16:40:00.001+02:00

Damit habe ich nicht gerechnet! Vielen Dank für das Feedback und die vielen Fragen zu meinem kleinen Cast über die Cube Funktionen in Excel.

Eine Frage kam dabei gleich häufiger: Ist die Funktion CUBEMENGE nun nur statisch? Wo ist dann der wirkliche Vorteil für mich als Controller?

Ok, das kann beantwortet werden.

Nein, es ist sehr wohl möglich CUBEMENGE dynamisch zu nutzen. Es kann sogar die Dimension, Hierarchie und der Level dynamisch ausgetauscht werden. Wie? Das zeige ich in diesem zweiten kleinen Cast! Hoffe, dass dieser wieder ein wenig Licht ins Dunkel bringen kann und noch mehr von den Möglichkeiten der Cube Funktionen in Excel zeigt. Bin mir sehr sicher, dass ich dazu in Zukunft noch ein wenig was zeigen werde.

Analysis Management Objects (aka AMO) Overview

2010-10-10T14:44:00.001+02:00

Hier ein Slide aus meinem Deck über Analysis Management Objects. Bin gerade am “Aufräumen”, da ich nächste Woche im PASS Chapter Hamburg einen kleinen Vortrag darüber halten werde und in der Woche drauf dann während des PASS Camps das Thema im Detail mit den Teilnehmern durchgehen werde.

Ich poste das Slide, da ich in meiner Rolle als Coach & Berater immer wieder auf die Meinung treffe, dass die SQL Server Analysis Services sich primär um den OLAP Cube als Objekt drehen. Das ist aber nur bedingt richtig. Zwar ist “der Cube” meist das Ziel in der Arbeit mit den Analysis Services, aber im Vordergrund steht die Arbeit mit der SSAS Datenbank. Ein OLAP Cube ist nur ein Teil dieser Datenbank! Aus diesem Missverständnis heraus entstehen meist irrtümliche Annahmen über den Aufbau von Cubes und der darunterliegenden Strukturen. Als Coach empfehle ich jedem, der mit SSAS zu tun hat, dass er sich bei Zeiten mal näher mit den Analysis Management Objects auseinandersetzt, da “das Codieren” eines Cubes (und damit einer SSAS Datenbank) durchaus neue Erkenntnisse und Einsichten über den Aufbau der Analysis Services bringen kann.

Einladung zum 54. PASS Treffen in Hamburg

2010-10-10T11:31:00.001+02:00

Diese Woche ist es wieder soweit! Das monatliche PASS Treffen in Hamburg steht an.

Wir werden uns im Detail die Analysis Management Objects (aka AMO) zum Zugriff auf die SQL Server Analysis Services anschauen und anhand von Codebeispielen lernen, wie diese für den Aufbau von OLAP Cubes auf Basis eines Repositories genutzt werden können. AMO ist bitte nicht zu verwechseln mit ADOMD.NET, welches eher für den Zugriff auf die Daten eines OLAP Cubes genutzt wird.

Details zum Treffen findet Ihr unter http://bit.ly/ciRv5e!

Webcast über Cube Funktionen in Excel

2010-10-07T17:45:00.001+02:00

Im Mai diesen Jahres hatte ich einen Blogbeitrag geschrieben über die Cube Funktionen in Excel 2007 & 2010. Die letzten Monate habe ich eine ganze Menge Feedback dazu bekommen. Die Funktionen scheinen bisher nicht so bekannt gewesen zu sein und viele haben sich an meiner Schritt-für-Schritt Anleitung versucht. Von einigen Teilnehmern der Community kam der Wunsch nach einen Video zu dem Thema. Diesem bin ich nun endlich nachgekommen. Hoffe, dass der Einstieg in die Arbeit mit den Cube Funktionen nun noch ein wenig einfacher wird. Viel Erfolg!

Erfahrungsbericht SQLBits 7 Konferenz in York, UK

2010-10-05T18:11:00.001+02:00

So, und schon wieder von was zurück… :-)

Dieses Mal von der größten SQL Server Konferenz in Europa. Der SQLBits Konferenz. Diese fand nun schon zum siebten mal statt. Als Veranstaltungsort wurde die University of York gewählt. Genauer gesagt das Exhibition Center des Heslington Campus in York. Ein modernes Universitätsgelände mit dem entsprechenden geselligen und gelehrigen Charme.

Für mich war es die erste SQLBits. Und nicht genug, ich war auch gleich Sprecher.

Die Konferenz bestand aus drei Tagen:

- einem Workshop Tag, also klassische kostenpflichte Pre-Con (Donnerstag)
- einem Tag, für den bezahlt werden musste, da “hochwertiger” Content (Freitag)
- und einem Community Tag, welcher von Sponsoren finanziert wurde (Samstag)

Die Organisatoren hatten meine Session für den Freitag ausgewählt. Die Session hatte den Titel “The Developer Side of the Microsoft Business Intelligence stack”, welche eine 60 min. Zusammenstellung der vielseitigen Möglichkeiten der Nutzung des Microsoft SQL Servers in Enterprise Business Intelligence und Data Warehouse Umgebungen bot. Durch meine Erfahrung (als Teil von PSG) in Projekten, konnte ich das fast ausschließlich englische Publikum, von denen wiederum wohl fast jeder in irgendeiner Bank in the City of London arbeitete, hoffentlich über die eine oder andere Audit und Compliance Hürde helfen. Als Raum war mir das Lecture Theatre zugewiesen worden, eine Mischung aus Hörsaal und Multiplex-Kino.

Meine Session verlief gut. War ja auch genau mein Thema, hätte noch locker 2-3 Stunden weitergehen können. Hatte im Anschluss noch einige sehr gute Gespräche zu dem Thema. Der Vortrag wird in den nächsten Tagen auf den SQLBits Seiten veröffentlicht werden.

So, nun aber zu der Frage: Wie war denn nun so die SQLBits insgesamt? Lohnt es sich dafür extra nach England zu kommen? Ach ja, wie viele Teilnehmer aus Deutschland denn waren da?

Also, mir hat die Konferenz sehr gut gefallen! Und es lohnt sich definitiv dafür nach England zu kommen! Daher meine SQL Konferenz Empfehlungen fürs nächste Jahr: Besucht die European PASS und nimmt eine SQLBits mit! Eine? Ja, davon gibst immer zwei im Jahr! Der Flug nach England ist günstig und Ihr könnt alles gut mit der Bahn erreichen. Ach ja, also ich glaube, es waren mit mir vier Deutsche (liebe Grüße an Sabrina und Tillmann, welche mir vom Vierten erzählten) dort und Klaus Aschenbrenner aus Österreich.

Vielen Dank an die Organisatoren und Teilnehmer der SQLBits für dieses großartige Event!

Many thanks to the organizers and participants of the SQLBits for this great event!

Wenn Euch das Thema meiner Session interessiert und Ihr mehr darüber erfahren wollt oder gar mit mir diskutieren wollt über Euren eigenen Anforderungen und wie wir diese gemeinsam lösen könnten mit dem MS SQL Server Business Intelligence Stack… dann… kommt zum PASS Camp in der übernächsten Woche in Mettmann bei Neuss! Wir werden dort alles was ich in York gezeigt habe anfassen, ausprobieren, weiterentwickeln, zerlegen und neumachen… ach ja, und wir werden viel diskutieren, Ideen entwickeln und ich werde versuchen, Euch meine Konzepte und Denkweise bei der Entwicklung solcher Lösungen nahezubringen.

Twitter-> #passcamp :-)

Back from Vacation

2010-09-27T15:46:00.002+02:00

Bin nun seit ein paar “Tagen” aus meinem letzten Urlaub zurück. Und schon wieder unermüdlich mit meinen Kollegen aus den unterschiedlichen Teams unterwegs gewesen. Es lagen sowohl spannende Workshops als auch herausfordernde Projekte rund um den SQL Server an. Vielen Dank an meine Kollegen für die zahlreiche Unterstützung vor Ort!

Eine Überraschung habe ich direkt vor meiner Haustür vorgefunden! Und zwar scheint nun auch in meinem Dorf das Highspeed-Internet Zeitalter zu beginnen. Anbei seht Ihr ein Foto von meinem ganz privaten Glasfaserkabel direkt ins Haus. Angeblich sollen darüber “demnächst” bis zu 50 MBit möglich sein. Ich bin gespannt und werde berichten. Habe auch schon die eine oder andere Idee, wie die SQL Community davon profitieren könnte.

Kommen wir zu einem sehr wichtigen Punkt: Der Mitgliederversammlung des PASS Deutschland e.V. am 18. Oktober 2010 !

Im Rahmen des PASS Camp findet dieses Jahr wieder eine MV statt. Ein wichtiger Punkt dabei ist die Wahl des Vorstandes. Ich bitte Euch zahlreich zu erscheinen, denn IHR SEID DIE COMMUNITY! Es gibt als Vortrag “drum rum” das spannende Thema „Parallel Data Warehouse“ von Ralph Kemperdick (Microsoft Deutschland).

Und wo wir gerade beim PASS Camp sind! Dieses findet vom 19. bis 21. Oktober 2010 bei Mettmann (Gut Höhne) statt. Wir haben dort 4 spannende 3-Tages Workshops dabei. Es gibt BI-Front End, SQL Azure und das SQLCAT Team mit BI for Administrators. Natürlich möchte ich nicht meinen Workshop “BI für Entwickler” unerwähnt lassen, welcher dem BI Berater den Nutzen von Programmierung in Business Intelligence Projekten nahebringen wird! Wir werden gemeinsam über den Einsatz von Meta Daten diskutieren und in Form von Hand-on Labs unsere eigenen Tools für die Nutzung eines BI Repositories in SQL Server Umgebungen schreiben. Wir werden dynSSIS erforschen und mittels AMO Cubes aus Meta Daten generieren. Reports (RDL) untersuchen und inventarisieren. Und vieles mehr! Ich freue mich schon auf den Austausch mit Euch!

Aber vorher gehst für mich nach York, UK zur “SQLBits - The 7 Wonders of SQL” Konferenz. Dort halte ich diesen Freitag die Session “The Developer Side of the Microsoft Business Intelligence stack”. Ihr seht, bin zurzeit voll im Thema Backend unterwegs! :-)

Und ich möchte noch Werbung machen für folgendes Microsoft TechNet Seminar in Hamburg am 10.11.2010: Managed Self-Service Business Intelligence mit SQL Server 2008 R2, Sharepoint 2010 und Office 2010! Im Anschluss an das Treffen findet in der Microsoft Niederlassung auch noch unser monatliches PASS Treffen statt! Wenn Ihr Zeit und Lust habt, dann könnt Ihr also einen ganzen Tag mit SQL Server Themen und der Community verbringen. Hoffe möglichst viele von Euch dort zu treffen!

Business Intelligence Framework Vortrag auf der SQLBits 7 in York, UK

2010-08-12T10:39:00.001+02:00

Diese Woche habe ich erfahren, dass ich auf der Konferenz SQLBits 7 (The 7 Wonders of SQL) eine Session halten darf!

Die SQLBits ist wohl mit die größte SQL Server Konferenz, welche man auf dieser Seite des Atlantiks finden kann und findet in UK statt. Dieses mal geht es nach York an die York University. Die Konferenz findet vom 30.9. – 2.10. statt. Weitere Details hier –> www.sqlbits.com . Vielleicht treffe ich ja den einen oder anderen von Euch dort!!?

Meine Session dreht sich um Business Intelligence und den sinnvollen Einsatz von Developer Tools für die Bereitstellung einer BI Middleware bzw. eines BI Frameworks, welches die Dienste des SQL Server ein wenig fester verbindet.

The Developer Side of the Microsoft Business Intelligence stack

The Microsoft SQL Server provides a complete library of programmatically accessed objects for all Business Intelligence relevant services. With this set of functions almost any customer challenge can be solved without the need to purchase additional products. This possibility is often underestimated in projects.
We will explore the ways how to create powerful solutions with Integration Services, Reporting Services and, of course, Analysis Services. This session provides many samples and .net sourcecode to demonstrate the possibilities of creating your own tools with Windows Forms and Silverlight for your daily work. Many manual clicks and tasks can be automated, really!
Finally we build a complete Business Intelligence Middleware as a blueprint for your own projects.

Die Themen, welche ich dort in 60 Min anreißen werde, gibt aber auch noch mal im Detail und zwar ganze drei Tage lang mit Hands-on von mir auf dem PASS Camp 2010 R2 in Mettmann bei Düsseldorf!

Die Website für die Anmeldung zum PASS Camp 2010 (R2) ist online!

2010-08-06T10:09:00.001+02:00

Hier nur “kurz” die Meldung, dass die Website für die Anmeldung zum PASS Camp 2010 (R2) online gegangen ist!

Ihr erinnert Euch vielleicht, da bin ich dieses Mal als Sprecher dabei und werde Euch mein absolutes Lieblingsthema drei Tage am Stück nahebringen: Microsoft Business Intelligence für Entwickler!

Hier gehst zum PASS Camp 2010!

Das ist die Agenda für meinen Track:

Dienstag, 19.10.2010

Einleitung - Warum überhaupt programmieren?
Der Microsoft SQL Server bietet eine ganze Reihe von äußerst mächtigen Diensten und Werkzeugen für die Erstellung von Business Intelligence Lösungen. Warum sollte sich dann überhaupt ein BI Berater mit den Möglichkeiten der Programmierbarkeit des SQL Servers beschäftigen? Weicht er damit nicht vom Standard ab? Und warum sollte sich ein Programmierer mit BI befassen? Sind die BI relevanten Dienste vom SQL Server etwa nicht fertig?
Die Wahrheit ist, dass eine wesentliche Stärke des SQL Servers, neben den bekannten Werkzeugen, die Verfügbarkeit von diversen sehr gut dokumentierten APIs ist. Diese APIs können sehr gut im Rahmen von BI Projekten genutzt werden und die Integrationsfähigkeit einer BI Lösung um ein vielfaches erhöhen. Alle in diesem Workshop vorgestellten Schnittstellen sind offiziell von Microsoft beschrieben worden und werden in zukünftigen Versionen unterstützt werden.
Vor dem Einsatz von Technologie kommt aber immer die zielgerichtete Konzeption der Lösung. Es wird gezeigt, wann und wie sich der Einsatz von Programmierung in BI Projekten tatsächlich rechnet und welche Voraussetzungen dafür erfüllt sein müssen.
Ein ganz wesentlicher Punkt aus der Erfahrung heraus ist die Nutzung der Abstraktion der Anforderungen und der Technologie als Architekturansatz im Design von Business Intelligence Lösungen.
Einführung mittels Crashkurs in die Entwicklung mit dem Visual Studio 2010
Damit alle mit den gleichen Voraussetzungen starten können, gibt es nach dem ersten Brocken Theorie, einen Crashkurs für die Nutzung des Visual Studios 2010.
Anhand von Labs wird die grundlegende Handhabung des Visual Studios vermittelt und in die Programmierung mit dem .net Framework eingeführt.
Dabei werden folgende Themen erläutert:
- Command Line Tools
- PowerShell (CmdLets)
- Entwicklung von einfachen GUIs
- XML-Files als Parameter verwenden
- Nutzung von ADO.NET für den Zugriff auf den SQL

Mittwoch, 20.10.2010

SQL Server Analysis Services
Nun kommen die Analysis Services an die Reihe. Zunächst beschäftigen wir uns kurz mit ein wenig MDX Grundlagen, um dann mittels ADOMD.NET OLAP Cubes direkt abzufragen. Damit haben wir die Grundlage für eigene OLAP Clients geschaffen.
Als nächstes beschäftigen wir uns mit den Analysis Services Management Objects (kurz AMO), um die Erstellung von OLAP Cubes entweder teilweise oder gar vollständig auf der Basis von Metadaten zu automatisieren. Wir erstellen Dimensionen und Measures. Des Weiteren schaffen wir die Grundlagen für einen eigenen KPI Designer für Cubes. Diese Technologie lässt sich ganz hervorragend kombinieren mit unseren neuen Kenntnissen vom Vortag über dynamisches SSIS.
SQL Server Reporting Services
Mit den Reporting Services geht es weiter. Wir entwickeln zuerst eigene Berichtselemente. Des Weiteren beschäftigen wir uns mit der Flexibilität der Reporting Services bei der Umsetzung von Anforderungen für die Integration von Berichten in vorhandene Umgebungen.
Zwischendurch schauen wir uns noch den Ansatz an die Reporting Services als Benutzeroberfläche zu verstehen und BI entsprechend zu konzeptionieren.
Auch bei den Reporting Services wenden wir uns zum Abschluss den Möglichkeiten zur automatischen Erstellung und Wartung zu. Wir erstellen gemeinsam Werkzeuge mit denen RDL Dateien (aka Reports) auf Basis von Metadaten erstellt als auch inventarisiert werden können.
Weboberflächen mit ASP.NET / Ajax
Zeit sich intensiver mit der Entwicklung von Benutzeroberflächen und Visualisierungen zu beschäftigen. Es gibt Grundlagen für die Erstellung von Weboberflächen mit ASP.NET / Ajax und der Kommunikation mit den SQL Server Diensten via Web Services und WCF. Dann aber experimentieren wir gemeinsam mit GDI+, um erste alternative Visualisierungen umzusetzen.
Da wir ja nicht alles selbst schreiben wollen, schauen wir uns auch noch das Chart Control des .net Frameworks ein wenig genauer an.

Donnerstag, 21.10.2010

Silverlight
Heute kommt noch mehr Interaktivität ins Spiel. Mittels Expression Blend entwerfen wir erste Entwürfe für moderne Benutzeroberflächen (RIA) und beschäftigen uns dabei mit der Beschreibungssprache XAML.
Dann drehen wir das Ganze um und steigen in die Steuerung einer Silverlight Anwendung vom Code aus ein. Nun nehmen wir unsere Erkenntnisse über SSIS, SSRS, ADOMD.NET und AMO und binden diese in unsere Silverlight Anwendungen ein. Damit haben wir auf der einen Seite sehr dynamische Oberflächen und auf der anderen Seite einen Zugriff auf die Dienste des SQL Servers für den Zugriff auf Daten (ADOMD.NET) und die Steuerung der Prozesse zur Verarbeitung (SSIS & AMO) dieser.
Abschließend entwickeln wir gemeinsam die Grundlagen für einen universellen OLAP Client unter Silverlight, welcher sich flexibel an Anforderungen in Projekten anpassen lässt.
Erweiterungen für Office & SharePoint 2007/2010
Nach soviel Neuem wenden uns nun wieder unserem alten Freund Excel zu und erweitern diesen um selbsterstellte Aufgabebereiche für den Zugriff auf Daten und unsere erstellten Dienste.
Zum Abschluss des Workshops werfen wir noch einen Blick auf den SharePoint Server. Wir entwickeln eigene Webparts, welche wiederum auf unsere Daten und Dienste zugreifen werden. Und wo wir gerade dabei sind, werden wir die SharePoint Search Funktionalität für unsere BI Lösungen zu nutzen lernen.

Microsoft Visual Studio LightSwitch (managed Access?)

2010-08-04T19:01:00.001+02:00

Bin ja sonst nicht mehr so der Fan von Product-Placement, aber das hier scheint ein paar Zeilen wert zu sein!

Hier kommt ein neues Visual Studio (Codename Kittyhawk), welches u. a. für den ambitionierten und kreativen Endanwender gedacht sein wird. LightSwitch ist damit das langerwartete “managed Access”!?!

Es macht einen durchdachten Eindruck, wie da in den Demos SQL Server, SQL Azure, SharePoint usw. mittels einer wirklich einfachen Oberflächen zusammengebracht werden. Ohne es bisher selbst in den Händen gehabt zu haben, kann ich mir trotzdem vorstellen, dass es einen deutlichen Drive in die Entwicklung von diesen kleinen fiesen aber geschäftskritischen Anwendungen bringen wird, welche in diesem Paralleluniversum neben dem ERP System existieren!

http://www.microsoft.com/visualstudio/en-us/lightswitch

Die Beta soll ab dem 23. August verfügbar sein.

Schön ist auch der Claim: “THE SIMPLEST WAY TO BUILD BUSINESS APPLICATIONS FOR THE DESKTOP AND CLOUD”

We are all in! :-)

Nutzung eines Jobpools in Business Intelligence Umgebungen

2010-08-03T23:22:00.001+02:00

Da ich vor ein paar Tagen ja über Repositories in Data Warehouse Umgebungen geschrieben habe, hier noch ein paar weitere Gedanken dazu. Im Rahmen der European PASS Conference 2009 habe ich zwei Vorträge gehalten. In dem einen ging es primär um dynamisch erstellte SSIS Pakete. Eine äußerst leistungsfähige Technologie, wenn in umfangreicheren Projekten eine größere Menge an SSIS Tasks und Paketen benötigt wird, welche auf Basis von Metadaten erzeugt werden sollen. Ein sekundärer Aspekt dieser Session, welcher ein wenig unterging, war die Nutzung eines Jobpools innerhalb eines Repositorys.

Damit sind wir wieder beim Thema. Es geht mir dabei um die Arbeit mit einer großen Menge an einzelnen Paketen und Jobs, welche zum Beispiel im Rahmen einer Datenbewirtschaftung eines Data Warehouses verarbeitet werden müssen. Natürlich gibt es eine ganze Reihe von Abhängigkeiten, welche bei der Abarbeitung berücksichtigt werden müssen! Als Lösung für eine solche Herausforderung wird gerne die Ablaufsteuerung von SSIS verwendet. Mit dieser lassen sich Abhängigkeiten zwischen einzelnen Paketen sehr leicht visuell modellieren. Dabei werden Jobs in immer der identischen sequentiellen Reihenfolge bzw. parallel abgearbeitet.

Ein Nachteil dieser Vorgehensweise ist aber die Handhabung in sehr großen Umgebungen, welche auch noch zum Teil dynamisch sind. Wenn dann noch der Wunsch nach automatischer Lastverteilung, Skalierbarkeit und Ausfallsicherheit an die Umgebung gestellt wird, dann kann es schon äußerst komplex werden!

Als eine mögliche Lösung für dieses Szenario setze ich gerne auf einen sogenannten Jobpool. Dabei werden die einzelnen Aufgaben bzw. Jobs zentral in einem Pool abgelegt. Von “außen” greifen nun sogenannte Agents auf diesen Pool zu und “suchen” sich die Pakete, welche sie verarbeitet werden dürfen.

Ob ein Paket aus dem Pool genommen werden darf und verarbeitet werden kann, wird auf Basis von Regeln entschieden. Zum Beispiel kann eine sehr einfache Regel sein, dass erst alle Pakete der Gruppe “ExtraktionCRM” fertig sein müssen, bevor mit der Verarbeitung der “Dimension Kunde” begonnen werden kann. Dabei ist es aber nicht entscheidend, in welchen Reihenfolge die Pakete der Gruppen “ExtraktionCRM” ausgeführt werden.

Wenn nun ein neuer Job dem Pool hinzugefügt wird, dann muss dieser nicht mit anderen Jobs “verdrahtet” werden, sondern er wird einem Regelsatz zugewiesen. Die Agents, welche die Pakete bzw. Jobs verarbeiten, können für unterschiedliche Aufgaben zur Verfügung stehen. Zum Beispiel dem einfachen Ausführen von SSIS Paketen oder dem Verarbeiten von AMO Anweisungen für den Aufbau von Cubes. Die Agents können über mehrere Server verteilt werden. Dadurch ist eine Lastverteilung und Skalierbarkeit gegeben, ohne, dass eine Ablaufsteuerung manuell an die neue Hardware (welche auch gern virtuell sein kann) angepasst werden muss. Der Ausfall eines Server ist zwar bedauerlich, da seine Leistung fehlt, aber führt nicht mehr zum Abbruch der gesamten Verarbeitung!

Wichtig ist mir die Abgrenzung, dass ein Jobpool erst in größeren Umgebungen Sinn macht! In einer überschaubaren Umgebung ist die SSIS Ablaufsteuerung mit ihren Möglichkeiten wesentlich sinnvoller. Der Moment über einen Jobpool nachzudenken ist gekommen, wenn der Verantwortliche für die Datenbewirtschaftung erst ein paar Minuten braucht, um die vermeintlich richtige Stelle in einem Paket zu finden, um einen neuen Job hinzuzufügen. Auch Anforderungen wie Skalierbarkeit, Lastverteilung und Ausfallsicherheit können Treiber für diesen Ansatz sein.

Die verwendeten Spalten und Tabellen einer beliebig komplexen SQL Query ermitteln

2010-08-01T18:40:00.001+02:00

Mein letzter Blogeintrag zum Thema Repository im Data Warehouse scheint einige Fragen aufgeworfen zu haben!

Neben dem eigentlichen Thema “Repository”, danke für die Rückmeldungen, kam oft die Frage, wie ich denn nun aus einer SQL Query die in dieser verwendeten Spalten der Quelltabellen auslese und was der Queryplan damit zu tun hat. Daher hier jetzt ein paar mehr Informationen dazu.

Die Vorgehensweise ist ein Abfallprodukt aus der Entwicklung eines Performancetuning Tools in einem Projekt.

Kurz zur Sicherheit erwähnt, wofür ich sowas in Projekten überhaupt benötige. Es geht um die Aufgabenstellung, dass ich hunderte von Queries habe und sehr gerne “auf-Knopfdruck” sehen möchte, welchen Einfluss eine Änderung am Datenmodell auf eben diese Queries hätte. Woher habe ich diesen Berg Abfragen? Entweder aus einem Profiler Trace einer OLTP Anwendung oder aus RDL-Dateien. Auch schon gemacht, daher hier als möglich aufgezählt, die Quellen in SSIS Paketen und Analysis Services Projekten. Auf jeden Fall sind die von einer Lösung verwendeten Queries immer gute Kandidaten in einem entsprechenden Repository gespeichert zu werden.

Gerne empfehle ich ISVs auch ein solches Repository als Grundlage einer Dokumentation zu führen und vor Änderungen am Datenmodell wie hier beschrieben vorzugehen. Damit fängt ein gutes Qualitätsmanagement doch erst an. Das Performancetuning kann dann gleich “daneben” gepflegt werden. So sah übrigens das ursprüngliche Projekt aus.

Die Aufgabenstellung nach den verwendeten Spalten hatte ich schon oft, aber häufig ist der erste Gedanke der Kunden, dass man dafür doch einen separaten SQL Parser bräuchte. Nun ja, sicherlich machbar, also mit entsprechend Zeit usw., aber nutzen wir doch den SQL Server als Tool dafür!

Nehmen wir mal eine einfache Query für das AdventureWorksDW2008

select SUM(salesamount) as summe
from dbo.FactInternetSales f
left join dbo.DimCustomer c on f.CustomerKey = c.CustomerKey
where c.HouseOwnerFlag = '0'

Mittels SET SHOWPLAN_XML ON bringe ich den SQL Server dazu, dass dieser…

a.) die Query nicht ausführt
b.) mir den geschätzten Ausführungsplan im XML Format liefert

Schon mal total toll. Nur bringt es mich überhaupt nicht weiter, da ich den Prozess ja automatisieren möchte. Also Management Studio zu, Visual Studio auf und ein wenig C#.

SqlConnection con = new SqlConnection(<ConnectionString>);
con.Open();
SqlCommand showplan_on = new SqlCommand("set showplan_xml on", con);
showplan_on.ExecuteNonQuery();

SqlCommand query = new SqlCommand(<Query>, con);
SqlDataReader showplan_results = query.ExecuteReader();
if (showplan_results.Read())
tbOutput.Text = showplan_results[0].ToString();
showplan_results.Close();

SqlCommand showplan_off = new SqlCommand("set showplan_xml off", con);
showplan_off.ExecuteNonQuery();
con.Close();

Und schon habe ich den geschätzten Ausführungsplan erhalten und zwar ohne, dass meine Query ausgeführt wurde!

Mit so einem Ausführungsplan kann man nun sehr spannende Sachen machen, aber für unseren Fall hier interessieren uns nur die Elemente mit dem Namen ColumnReference. Da stecken nämlich unsere Spalten drin. Wie kommen wir da nun ran? Der Ausführungsplan ist bereits geladen. Aber er ist noch als String verpackt. Das kann das .net Framework aber besser, daher nix wie ab in eine XML Datenstruktur und die Elemente gesucht.

XmlDocument dom = new XmlDocument();
dom.LoadXml(tbOutput.Text);

XmlElement root = dom.DocumentElement;

XmlNamespaceManager nsmgr = new XmlNamespaceManager(dom.NameTable);
nsmgr.AddNamespace("bk", "http://schemas.microsoft.com/sqlserver/2004/07/showplan");

XmlNodeList nodelist = root.SelectNodes("//bk:ColumnReference[@Database]", nsmgr);

Und wir haben eine NodeList mit unseren Elementen! Diese können wir nun ausgeben.

xn.Attributes.GetNamedItem("Database").InnerText + "." + xn.Attributes.GetNamedItem("Schema").InnerText + "." + xn.Attributes.GetNamedItem("Table").InnerText + ".[" + xn.Attributes.GetNamedItem("Column").InnerText + "]"

Da haben wir unsere Spalten! War doch ganz einfach, oder?

Und das funktioniert dann natürlich nicht nur mit SELECT Statements! Hier mal ein Beispiel für ein UPDATE Statement mit Unterabfragen.

Ergibt folgende Ausgabe:

Mit dieser Vorlage sollte sich eigentlich jeder sein eigenes Tool für diese Art von Fragestellung bauen können. Viel Spaß damit!

Überlegungen über den Aufbau eines Repositorys in einer Business Intelligence Umgebung

2010-07-29T18:56:00.001+02:00

Ein kürzlich geführtes Gespräch mit einem Community Kollegen über das Thema Repositorys in Microsoft Business Intelligence Umgebungen, brachte mich auf die Idee meine Überlegungen und Erfahrungen zu dem Thema hier mal kurz zu skizzieren.

Meine Definition eines Repositorys ist eine zentrale Sammlung von Metadaten, Versionsständen und Protokollen. Ein solches Repository gehört meiner Meinung nach primär zu dem Themenkomplex Data Warehouse.

Das Versprechen einer Business Intelligence Lösung bzw. eines Data Warehouses ist u. a. die Bereitstellung der sogenannten “einzigen Wahrheit” in der Organisation. Das ist zum Beispiel durch den Einsatz von OLAP Cubes technisches relativ leicht durchzusetzen. Alle weiteren Frontend Werkzeuge (zum Beispiel Reporting Services oder Excel) greifen auf diese Datenquellen zu. Was passiert aber nun, wenn sich Strukturen des Data Warehouses und/oder der OLAP Cubes verändern? Diese Veränderungen ziehen sich in der Regel bis zu den Frontends durch und haben sehr wahrscheinlich auch Einfluss auf die schon bereitgestellten Reports in Reporting Services und Excel.

In einer klassischen Microsoft Business Intelligence Umgebung greifen die Dienste direkt auf die jeweils anderen Dienste zu.

Die Dienste des SQL Servers sind technisch gesehen eigenständig. In einer BI Lösung werden diese zwar miteinander verbunden, aber diese Kopplung ist recht lose. Auf der einen Seite sind damit äußerst flexible Architekturen möglich, auf der anderen Seite gibt es kein zentrales Element, welches die Kommunikation zwischen den Diensten steuert. Szenarien, wie das oben geschilderte, werden durch keine Architekturschicht “aufgefangen”.

Die Verwendung eines zentralen Repositorys, welches zwischen den Dienste steht, unterstützt die Business Intelligence Umgebung dabei das Versprechen einer einzigen Wahrheit nachhaltig einzulösen.

Die Technologie hinter einem solchem Repository ist in unseren Projekten die relationale Engine des SQL Servers. Die notwendige Flexibilität gibt mir aber die Kombination aus strukturierten und semi-strukturierten Daten. Ein Ziel ist es, dass im Projekt als auch bei der späteren Verwendung der Business Intelligence Umgebung nicht mehr an unterschiedlichen Orten nach Informationen gesucht werden muss, sondern, dass gezielt das Repository genutzt werden kann.

Bereits während der Einführung einer Business Intelligence Lösung sollte daher auf den konsequenten Aufbau eines durchgängigen Repositorys geachtet werden.

Das ist zwar jetzt sehr theoretisch, aber gehen wir mal bei einem Beispiel ein wenig ins Detail. Die Reporting Services sind ein sehr leistungsfähiger Dienst. Die Definition der Reports liegen in sogenannten RDL-Dateien vor. Als Beschreibungssprache wird die Report Definition Language verwendet. Diese ist auch sauber von Microsoft dokumentiert.

Innerhalb einer RDL-Datei wird auf eine Datenquelle verwiesen, welche gesondert beschrieben wird. Aber die eigentliche Definition der verwendeten Felder innerhalb des Reports ergibt sich im Report direkt aus dem CommandText der Query und den definierten Feldern. Es ist mit Hausmitteln später nicht mehr einfach herauszufinden, woher die Felder im Report kommen. Dazu müsste die Query analysiert werden (komme ich noch zu). Auch das neue Feature der Shared datasets bringt hierfür nicht wirklich etwas (sonst äußerst praktisch!), da es nur eine weitere Abstraktionsebene zwischen Report und Datenquelle zieht, aber keine eindeutiges Mapping der Felder zu Tabellen (oder Cubes) zulässt. Hier mal ein Blick direkt in eine RDL-Datei. Wir sehen die Query und die einzelnen Felder, aber kein Mapping!

Eine konkrete Überlegung für das Repository ist, dass dieses Mapping aber für Impact-Analysen auf jeden Fall stattfinden muss. Wie kann sowas nun realisiert werden?

Im Falle einer relationalen Quelle, also zum Beispiel des direkten Zugriffs von Reports auf das Data Warehouse, lässt sich das recht einfach mittels automatischer generierter Views lösen. Das Data Warehouse stellt über das Repository, als eine Art Presentation Layer, eine Reihe von Views bereit, welche in den Reports verwendet werden können. Wichtig ist dabei, dass die Flexibilität nicht künstlich beschnitten wird. Es sollte auch nicht verschwiegen werden, dass es durchaus Möglichkeiten gibt auf Basis der Query innerhalb eines Reports an die verwendeten Tabellen und Views zu kommen. Realisierbar ist das mit einer Mischung aus RDL-Datei auslesen und Queryplan abfragen! Damit bringen uns selbst Sub-Queries und geschachtelte Views nicht um den Verstand! :-)

Bei einer multidimensionalen Quelle, also einem OLAP Cube, ist es leider nicht ganz so einfach. Da haben wir out-of-the-box keine Views, die wir dafür verwenden können. Um dieser Herausforderung Herr zu werden, macht es Sinn sich mit AMO zu beschäftigen. Den Analysis (Services) Management Objects. Mittels dieses praktischen Frameworks können Cubes auf Basis unserer Metadaten aus dem Repository automatisiert erzeugt werden. Damit haben wir zumindest eine zuverlässige und saubere Datenbasis, auf welcher wir dann aufsetzen können mit den Frontends. Die Metadaten, welche AMO nutzt, greifen zum Beispiel wiederum auf die oben erwähnten Views des Data Warehouses zu.

Wie Ihr seht gibt es durchaus Anwendungsfälle für ein Repository im Rahmen eines Business Intelligence Projektes!

Ein Repository wird bei der Erstellung eines ersten Prototypen einer Business Intelligence Lösung bzw. Umgebung aber meist als überflüssig empfunden. Vielleicht entsteht sogar der Verdacht, dass der Berater künstlich zusätzlichen Zeitaufwand generieren möchte und keinen echten Gegenwert dafür liefert. Dabei gibt es ja eine ganze Reihe von sehr guten Gründen für den Einsatz einer solchen Architektur!

Ein guter Ansatz ist es wesentlich mehr Aufmerksamkeit (und das ist nicht zu verwechseln mit Zeit!) in die Pflege der verwendeten Quellen zu legen. Wenn es geschafft wird die Quellen als eigenständige Objekte zu verstehen, welche entsprechend auch für sich gepflegt werden, dann ist das Projekt meist auf einem guten Weg. Im Rahmen eines standardisierten Deployment Prozesses sollten später neue Objekte auch direkt in das Repository aufgenommen werden.

Ich denke, dass ich mit Sicherheit auf dem PASS Camp im Oktober das eine oder andere zu diesem Thema zeigen werde. Wir werden zum Beispiel RDL-Dateien auseinandernehmen und uns eigene AMO Prozesse codieren.

ADOMD.NET und die CellSet Klasse

2010-07-24T17:28:00.001+02:00

So, als eine Ergänzung zu meinen letzten Einträgen zum Thema ADOMD.NET, habe ich heute ein paar weitere Details zur CellSet Klasse.

Ich hatte ja bereits gezeigt, wie Ihr generell mittels ADOMD.NET und der CellSet Klasse auf Daten eines Cube zugreifen könnt. Dazu hatte ich auch ein paar Eigenschaften und Methoden der CellSet Klasse erläutert. Hier nun ein Beispiel für den Zugriff auf ein Resultset innerhalb eines CellSets.

Hier nochmal ein Stück Code, welches sich mit einem Analysis Services Cube verbindet und eine MDX Query ausführt.

AdomdConnection mdcon = new AdomdConnection(“<ConnectionString>”);
mdcon.Open();
AdomdCommand cmd = mdcon.CreateCommand();
cmd.CommandText = “Query”;
CellSet cs = cmd.ExecuteCellSet();
mdcon.Close();

Entscheidend für uns ist hier das CellSet cs, welches wir nun ein wenig mehr “auseinandernehmen” werden!

Dafür brauchen wir aber auch die MDX Query:

SELECT
{[Date].[Calendar].[Calendar Year].&[2003], [Date].[Calendar].[Calendar Year].&[2004]} on Columns,
NON EMPTY CROSSJOIN({[Product].[Product Categories].[All Products].children}, {[Customer].[Customer Geography].[All Customers].children}) on Rows
FROM [Adventure Works]
WHERE ([Measures].[Internet Sales Amount])

Wir sind mal wieder auf “Adventure Works” unterwegs. Hier lassen wir uns für die Jahre 2003 und 2004 die Internet Umsätze aufgeschlüsselt nach Produktkategorien und Kundenregionen darstellen.

Das Ergebnis können wir uns so vorstellen:

Nur wie kommen wir jetzt mittels des CellSet Objektes cs an die einzelnen Zellen? Um das mal anschaulich darzustellen, habe ich hier für das Resultset von oben die jeweiligen “Pfade” durch das Objekt zu den Daten und Überschriften aufgeführt.

Das ist ja schon mal übersichtlich. Nur was sind jetzt diese ganzen Auflistungen und Objekte?

Fangen wir einfach an. Bei der Aufbereitung eines CellSets sollten wir uns zunächst fragen: Wie viele Achsen hat das Resultset? Wer sich mit MDX schon mal beschäftigt hat, weiß ja, dass durchaus mehr als nur zwei Achsen möglich sind. Sowas sollten wir abfangen!

Also mit cs.axes.count kommen wir an die Anzahl der Achsen.

Von der Achse aus kommen wir zur Auflistung Positions, welche uns zu den Tuples der jeweiligen Achse bringt. Unterhalb der Positions haben wir die Members. Hier müssen wir klären, wie viele Members wir haben. Also kommt hier zum Beispiel ein cs.Axes[1].Positions[0].Members.Count. Damit können wir die Beschriftung oben und an der Seite durchführen. Wenn wir uns den UniqueName mit merken, können wir auch bereit sein für weitere Filtervorgänge.

An die eigentliche Werte kommen wir sehr einfach. Wir nehmen das CellSet und adressieren die jeweilige Position innerhalb des Resultsets direkt. Oben im Beispiel seht Ihr das Verfahren sehr deutlich! Und schon haben wir alles Wesentliche vom Resultset ausgelesen.

Schaut doch eigentlich ganz einfach aus, oder?

Analysis Services Metadata mittels ADOMD.NET auslesen

2010-07-22T22:23:00.001+02:00

Ok, mein Blogartikel über ADOMD.NET war ja auch nur als Einstieg und Anregung gedacht! Aber es kamen nun die Wünsche nach Beispielen und Demos. Daher heute mal ein wenig Democode inkl. Download. Ich hoffe, dass ich in den nächsten Tagen noch mehr dazu beisteuern kann.

Also, ich habe ein kleines Beispiel in WinForms gebaut, welches die Metadaten aus einer Verbindung mit den Analysis Services ausliest und in einem TreeView darstellt. Das ist jetzt bewusst keine fertige BI Anwendung, sondern soll als Beispiel für den Zugriff auf besagte Metadaten dienen.

Wichtig ist, dass Ihr auf Eurem Rechner eine ADOMD.NET DLL habt. Sprich Ihr solltet ADOMD.NET installiert haben!

Der eigentliche Code ist recht “einfach” gehalten und hält sich mit wenig auf. Es geht hier ja auch um ein erstes Demo.

int nCubes = 0;

tvMetadata.Nodes.Clear();

AdomdConnection mdcon = new AdomdConnection(tbConnString.Text);
mdcon.Open();

            foreach (CubeDef cube in mdcon.Cubes)
            {
                if (cube.Name.StartsWith("$"))
                    continue;
                tvMetadata.Nodes.Add(cube.Name + " (" + cube.LastProcessed.ToString() + ")");

                tvMetadata.Nodes[nCubes].Nodes.Add("Measures");
                foreach (Measure mes in cube.Measures)
                    tvMetadata.Nodes[nCubes].Nodes[0].Nodes.Add(mes.Name);

                tvMetadata.Nodes[nCubes].Nodes.Add("Dimensionen");
                int nDims = 0;
                foreach (Dimension dim in cube.Dimensions)
                {
                    tvMetadata.Nodes[nCubes].Nodes[1].Nodes.Add(dim.Name);

                    foreach(Hierarchy hier in dim.Hierarchies)
                        tvMetadata.Nodes[nCubes].Nodes[1].Nodes[nDims].Nodes.Add(hier.Name);
                    nDims++;
                }

                tvMetadata.Nodes[nCubes].Nodes.Add("KPIs");
                foreach (Kpi kpi in cube.Kpis)
                    tvMetadata.Nodes[nCubes].Nodes[2].Nodes.Add(kpi.Name);

nCubes++;
}

mdcon.Close();

}

Mehr ist für das Darstellen der Metadaten eines Cubes erst mal nicht notwendig!

Eine mögliche Erweiterung wäre sich neben den sprechenden Bezeichnungen auch gleich noch die UniqueNames ausgeben zu lassen bzw. zu speichern. Dafür müsst Ihr statt “Name” nur “UniqueName” verwenden. Hier mal ein Beispiel wie sowas auf der Ebene der Hierarchien aussehen kann.

Des Weiteren ignoriere ich zurzeit komplett die DisplayFolder, diese könnten natürlich auch eingebaut werden. Also da ist noch Raum für Kreativität. Und bevor ich es vergesse, dieses Demo und viele weitere gibt es auf dem kommenden PASSCamp 2010 in meinem Track!

Das Projekt gibt es als Download genau hier: http://www.sascha-lorenz.de/downloads/ADOMD.NETMetadataSample.zip

Microsoft SQL Server 2008 R2 Update for Developers Training Course

2010-07-19T21:35:00.001+02:00

Es gibt auf Basis des SQL Server 2008 R2 Update for Developers Training Kit nun auch noch auf Channel9 einen passenden Kurs in Form von Webcasts!

Also, hier geht es zum Microsoft SQL Server 2008 R2 Update for Developers Training Course ! :-)

PivotViewer Extension for Reporting Services CTP1

2010-07-17T17:38:00.001+02:00

Vielleicht erinnert Ihr Euch noch an Pivot? Ich hatte schon mal kurz drüber geschrieben. Dazu ist mittlerweile einiges passiert.

Es gibt nun ein PivotViewer Silverlight Control als Download, welches Ihr auf Euren Seiten einsetzen könnt!

Aber was noch cooler wird, ist die Tatsache, dass Microsoft nun für den SharePoint 2010 ebenfalls eine Erweiterung, welche auf dem Control basiert, als CTP auf der Straße. Diese wird zwar als Designstudie bezeichnet, aber das wirkt schon durchdacht für den Moment.

Den Download der “PivotViewer Extension for Reporting Services CTP1” gibt es hier: http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=d31f609d-a353-41ad-a1a4-f81456e3a6c4

Den Blog zum Projekt und einer sehr nützlichen Anleitung für die Installation hier: http://petcu40.blogspot.com/2010/07/pivotviewer-extension-for-reporting.html

Erste Schritte mit ADOMD.NET

2010-07-17T11:57:00.001+02:00

In den letzten Jahren habe ich eine ganze Reihe von Vorträgen über den Zugriff auf Analysis Services Cubes mittels .net Code und ADOMD.NET gehalten. Da die Funktionsweise eigentlich äußert einfach ist, habe ich aber bisher wenig bis wohl gar nichts dazu geschrieben. Das möchte ich nun nachholen, da sich hier bei mir die Nachfragen langsam häufen! :-)

Also, was ist ADOMD.NET eigentlich, was kann das und kostet das was?

ADOMD.NET ist ein sogenannter Data Provider von Microsoft für das .net Framework und bietet u. a. aus meiner .net Anwendung heraus die Möglichkeit auf SQL Server Analysis Services Cubes zuzugreifen. Wichtig ist dabei zu verstehen, dass ADOMD.NET kein fertiges BI Tool oder Control ist, welches ich nur noch einbinden muss und damit eine Art Excel-BI-Grid-GUI in meiner Anwendung habe. ADOMD.NET bietet mir im Code alle Möglichkeiten für den Zugriff auf die Daten, aber ich muss diese selbst kreativ nutzen . Wäre es dann nicht einfacher sich nicht gleich was Fertiges zu kaufen? Ok, wer schon mal eine Session von mir zum Thema gesehen hat, der kennt meine Antwort darauf. In der Regel wollen wir ja nicht den x’ten BI Client schreiben (auch wenn das wirklich Spaß machen kann!) oder unsere Anwendung um das Look & Feel von Excel erweitern, sondern unsere Anwender auf intelligente Art und Weise von den Fähigkeiten eines wahrscheinlich eh schon existierenden Cubes profitieren lassen. Mit Fähigkeiten meine u. a. ich die Flexibilität und Performance in Bezug auf sogenannte Ad-Hoc Queries und die damit verbundenen fast schon magischen Berechnungsmöglichkeiten. Das mit SQL Queries auf einer relationalen Datenbank abzubilden ist zwar meist möglich, aber dazu ist schon einiges an Experten KnowHow erforderlich und an die Performance eines Cubes ist meist gar nicht zu denken. Es lässt sich halt nicht jede Ad-Hoc Query vorher mit einem entsprechenden Index vorbereiten. Liegt nun mal in der Natur der Sache mit diesen Ad-Hoc Abfragen! Kommen wir kurz zu den Kosten. Good news, ADOMD.NET gibst von Microsoft zum SQL Server einfach dazu und ist Bestandteil des Feature Packs. Für den Zugriff wird nur eine gültige Lizenz für den Client benötigt. Also, wenn es aus lizenztechnischer Sicht möglich ist Excel als Client zu nutzen für die SSAS, dann auch ADOMD.NET. Details zu Lizenzen gibst bei Eurem freundlichen Microsoft Kontakt! Ach ja, Feature Packs! Hier kurz die Links, falls Ihr die nicht zur Hand habt:

Microsoft SQL Server 2008 R2 Feature Pack, Microsoft SQL Server 2008 Feature Pack & Microsoft SQL Server 2005 Feature Pack

Wie Ihr seht, gibst das Feature Pack für jede aktuellere Version des SQL Servers. Alles was ich Euch hier über ADOMD.NET schreibe, sollte auch mit jeder dieser Versionen möglich sein. Falls jemand andere Erfahrungen macht, dann Feedback an mich bitte.

Ok, auf was für Daten können wir nun in so einem Cube zugreifen? Ohne jetzt einen Grundlagenartikel über SSAS Cubes zu schreiben, hier mal kurz das Wichtigste kurz zusammengefasst:

Ein Cube besteht aus Dimensionen und Measures. Dabei könnt Ihr Euch die Dimensionen aus Geschäftsobjekte vorstellen und die Measures als die damit verbundenen Geschäftsprozesse bzw. die Ergebnisse der Geschäftsprozesse. Ein einfaches Beispiel ist der Verkauf von Artikel, dabei sind die Geschäftsobjekte “Artikel” und “Kunden” vorhanden und der Prozesse “Verkauf” und die damit verbundenen Umsätze. Nun kann in einem Cube entweder die Summe aller getätigten Verkäufe betrachtet werden oder diese werden auf Basis der Geschäftsobjekte gefiltert. Menschen mit einem Business Intelligence Hintergrund sprechen auch gern von dem “Schneiden” von Daten. Also zeige mir zum Beispiel nur die Verkäufe für die Artikelgruppen A, B & Z und nur für gewerbliche Kunden in Süddeutschland. Klingt doch einfach? Ist es auch, wobei irgendwann wird die Arbeit mit Cubes ein wenig tricky, aber für den Moment reicht uns das an Hintergrund. Das Schöne an Cubes ist es, dass sie solche und ähnliche Abfragen quasi in Gedankengeschwindigkeit verarbeiten und beantworten.

Eine Datenbank in Analysis Services ist in der Lage sich mittels einer ganzen Reihe von sogenannten Metadaten ausführlich selbst zu beschreiben. Wir haben u.a. folgende Metadaten im Zugriff:

Cubes
Dimensionen
Hierarchien
Level
Measures
KPIs
Named Sets

Macht es eigentlich Sinn, dass unsere Clients sich immer wieder alle Metadaten ziehen müssen? Auch dazu habe ich mich ja schon öfters geäußert. Aus der Erfahrung heraus ist dafür der Einsatz einer BI Middleware sinnvoll, welche u. a. ein Repository bereitstellt, welches alle Entitäten aller in der BI Umgebung verfügbaren Objekte bereitstellt. Dazu gehören neben der Datenbewirtschaftung (SSIS Pakete) und Reports (RDL Dateien) auch Informationen über unsere Cubes.

Häufig höre ich bei Vorträgen oder auch bei Coachings, dass es doch sicherlich viel zu aufwändig sei so einen Cube mit einzubinden. Da ist es doch einfacher zu versuchen mit den bisherigen Techniken voran zu kommen. Nun ja, was der Bauer nicht kennt, dass frisst er nicht.

Und bevor wir zu sehr in die Details einsteigen, hier ein erstes Codebeispiel für das Herstellen einer Verbindung mit einem Cube:

using Microsoft.AnalysisServices.AdomdClient;
…
AdomdConnection mdcon = new AdomdConnection(<constring>);
mdcon.open();

Wir machen was hoffentlich Sinnvolles…

mdcon.close();

Ok, das sieht doch schon mal ganz schlank aus. Kommen wir kurz zum Connectionstring.

Eine ganz einfache Variante ist die folgende: “datasource=localhost;catalog=adventure works dw 2008”. Ideal für Demo- und Testzwecke. Dummerweise reicht das nicht im echten Leben und es gibt fast schon unverschämt viele Parameter mit denen die Verbindung konfiguriert werden kann. Für den Moment soll das aber reichen. Unser Connectionstring zeigt auf den Server “localhost” und die Datenbank “Adventure Works DW 2008”. Und immer daran denken, eine Datenbank in SSAS kann mehrere Cubes umfassen!

So, ein weiterer Punkt ist der Namespace “Microsoft.AnalysisServices.AdomdClient” den wir hier verwenden. Damit wir ADOMD.NET überhaupt nutzen können, müssen wir zuerst im Visual Studio einen Verweis auf die “C:\Program Files\Microsoft.NET\ADOMD.NET\100\Microsoft.AnalysisServices.AdomdClient.dll” anlegen! Ab dann klappt das auch mit dem Namespace.

Und was können wir nun mit so einem AdomdConnection Objekt anfangen? Eine ganze Menge! Zunächst fragen wir einfach mal die Umgebung ab, damit wir wissen was uns da eigentlich so geboten wird. Also hier ein wenig mehr Code:

foreach (CubeDef cube in mdcon.Cubes)
{
                if (cube.Name.StartsWith("$"))
                    continue;
                lbT1.Items.Add(cube.Name+ " ("+cube.LastProcessed.ToString()+")");

                foreach (Dimension dim in cube.Dimensions)
                {
                    lbT1.Items.Add(" -> "+dim.Name);

                    foreach (Hierarchy hier in dim.Hierarchies)
                    {
                        lbT1.Items.Add("   -> " + hier.Name);

                    }
                }
    }

Ist eigentlich recht einfach. Wir nehmen “mdcon”, also die Connection, und lassen uns in der Auflistung “Cubes” alle, nun ja, Cubes zeigen. Wir bekommen ein Cube Objekt, welches wiederum Eigenschaften hat, wie zum Beispiel “Name” & “LastProcessed”. In dem kleinen Codebeispiel schreibe ich die Werte in eine Listbox “lbT1”, daher dieses “lbT1.Items.Add” usw. Nun ja, und genauso machen wir weiter. Jeder Cube hat eine Auflistung für die verwendeten Dimensionen und die wiederum für die Hierarchien usw. Das ist doch einfach, oder?

Was können wir nun mit diesen Daten, welche die Cubes beschreiben, anfangen? Bereits eine ganze Menge! Hängt auch ein wenig von unserer Rolle im Unternehmen oder dem Projekt ab.

Wir können die Metadaten als Basis für spätere Abfragen nehmen. Gute Idee! Merken wir uns mal.

Wir können aber auch die Daten verwenden für den Aufbau einer Dokumentation. Wir lesen die Metadaten aus und schreiben sie relational weg. Vielleicht speichern wir auch die Daten gleich historisch ab, damit uns Änderungen auffallen bzw. wir diese dokumentiert haben. Darauf lassen sich super Reports bauen. Wozu? Kommt auf die Rolle von uns an. Wir können unsere eigene Arbeit dokumentieren und Veränderungen festhalten, also quasi unseren Arbeitsfortschritt. Aber genauso gut können wir die Arbeit anderer damit kontrollieren bzw. protokollieren wie sich über die Zeit hinweg ein Cube verändert. Das geht dann so in Richtung Projekt – und Qualitätsmanagement.

Kommen wir nun zu der eigentlichen Abfrage von Daten.

Einen Pferdefuss hat die Arbeit mit ADOMD.NET, denn Ihr müsst MDX für die Queries nutzen. Sofern Ihr bisher MDX aus dem Weg gegangen seit oder es einfach keinen Grund gab für Euch sich damit zu beschäftigen, nun ja, jetzt ist der Moment gekommen in dem MDX in Euer Leben tritt!

AdomdConnection mdcon = new AdomdConnection(tbConString.Text);
…
mdcon.Open();
AdomdCommand cmd = mdcon.CreateCommand();
cmd.CommandText = strMDXQuery;
CellSet cs = cmd.ExecuteCellSet();

Wir machen was Nützliches mit dem CellSet…

mdcon.Close();

Und schon haben wir unser Resultset als CellSet im Objekt “cs” vorliegen. Hier kommen so die wohl wichtigsten Zeilen mit denen Ihr ein CellSet zerlegen könnt. Mit den beiden folgenden Zeilen bekommt Ihr die Große des Resultsets zurück.

int x = cs.Axes[0].Positions.Count; // Anzahl Spalten

int y = cs.Axes[1].Positions.Count; // Anzahl Zeilen

So, nun wollen wir die Spalten- und Zeilenbeschriftungen auslesen. Für die Darstellung hat das CellSet die Eigenschaft “Caption” dabei und für Abfragen haben wir den UniqueName.

cs.Axes[0].Positions[xi].Members[0].Caption;

cs.Axes[0].Positions[xi].Members[0].UniqueName;

Ach ja, der eigentliche Wert ist ja auch noch da. Also nichts wie ran.

Value = cs[xi,yi].Value.ToString();

Das Ganze hier und noch viel, viel mehr schauen wir uns übrigens während des zweiten PASS Camp 2010 gemeinsam im Detail an.

Warum sollten Tabellenhinweise (table hints) vermieden werden?

2010-07-14T11:29:00.001+02:00

Immer wieder sehe ich bei der Analyse von Anwendungen, dass mit sogenannten Tabellenhinweisen (table hints) gearbeitet wird. Meist ist die Begründung, dass der “doofe” SQL Server einfach nicht verstanden hat, dass es doch extra einen nicht-gruppierten Index für die Abfrage gibt. Den hat der doch einfach ignoriert! Und von anderen Entwicklungsumgebungen sei man ja schließlich auch gewöhnt die Verwendung von Indizes explizit anzugeben. Wo ist also das Problem?

Nun ja, das Problem ist, dass die Erfahrung gezeigt hat, dass wenn soweit alles in Ordnung ist, der SQL Server ziemlich genau weiß, was er da so macht bei der Aufbereitung von Abfragen. Und wenn er einen Index nicht nutzen möchte, dann hat er in der Regel einen verdammt guten Grund dafür. Dummerweise wird dieser nicht angeben.

Der häufigste Grund dafür, dass der SQL Server einen Index nicht verwendet, ist die Vermeidung von unnötiger Arbeit. Der SQL Server kann nämlich auf Basis der sogenannten Statistiken ziemlich genau abschätzen wie viele Datensätze er berühren muss für die Verarbeitung einer Abfrage. Daher ist es extrem wichtig, dass die Statistiken aktuell sind! Also nicht einfach in den Optionen für eine Datenbank deaktivieren, wenn Ihr nicht noch zumindest einen entsprechenden Job dafür aufgesetzt habt! Ist wirklich wichtig!

Was meine ich nun mit unnötiger Arbeit? Dazu ein einfaches Beispiel.

Wir nehmen als Datenbank mal nicht AdventureWorks, sondern die neue Contoso BI. Da ist ein klein wenig mehr Futter drin. Die Tabelle FactOnlineSales bringt es zumindest auf 12.627.608 Datensätze. Das ist zwar noch nicht wirklich viel, aber für unser Beispiel reichst auf jeden Fall. Auf “statistics io on” bin ich schon mal kurz eingegangen. Damit sind die IO-Operationen gemeint und nicht die Statistiken in den Indizes!

set statistics io on;

select SUM(SalesAmount)
from FactOnlineSales
where DateKey between '31.12.2007' and '01.01.2009';

Als Wert für die “logische Lesevorgänge” bekomme ich 46648. Den gilt es zu nun minimieren. Die Tabelle hat zurzeit nur einen gruppierten Index. Der scheint zwar auch alles andere als optimal gewählt zu sein, aber das ein anderes Thema. Im Ausführungsplan sehen wir, dass ein “Clustered Index Scan” durchgeführt wird.

Nun fügen wir einen nicht-gruppierten Index hinzu für DateKey. Das macht doch Sinn, schließlich suchen wir ja nach DateKey.

Und nun? Wir führen die Query nochmal aus und bekommen wieder ein ähnliches Ergebnis. Im Ausführungsplan ist immer noch ein “Clustered Index Scan”. Hier ist nun der Moment, wo der eine oder andere schwach wird und dem SQL Server nun den Index aufzwingen will.

select SUM(SalesAmount)
from FactOnlineSales with (index(ix_datekey))
where DateKey between '31.12.2007' and '01.01.2009';

So, jetzt aber! Im Ausführungsplan sehen wir nun endlich, dass der Index verwendet wird. Und was kommt raus? 11186313 logische Lesevorgänge!!! Ist mein SQL Server kaputt? :-)

Natürlich nicht! Wir sehen jetzt nur, warum der SQL Server den Index bisher vermieden hat. Der Index war nämlich alles andere als optimal für diese Abfrage. Zwar nutzt der SQL Server nun den Index, aber der eigentliche Wert, der SalesAmount, steckt ja noch im gruppierten Index. Daher fliegt unsere Abfrage nun immer eine schöne Schleife zwischen nicht-gruppierten und gruppierten Index. Das kostet uns so richtig Leseoperationen und damit Zeit. Wir nennen sowas eine Schlüsselsuche (bookmark lookup).

Das Coole daran ist, dass hat der SQL Server aufgrund der Statistiken kommen sehen und daher entschieden, dass ein simpler Scan auf dem gruppierten Index am Ende günstiger wird. Daher mein Hinweis, dass der SQL Server schon ziemlich genau weiß, warum er einen Index mal nimmt und mal nicht. Ehrlich!

Und unsere Query? Haben wir denn nun keine Chance diese mit einem Index zu unterstützen? Aber sicher doch!

Wir nehmen wieder unseren nicht-gruppierten Index und fügen als eingeschlossene Spalte den SalesAmount hinzu. Und los. Jetzt bekomme wir nur noch 10512 logische Lesevorgänge. Und ganz wichtig, im Ausführungsplan sehen wir nur noch einen Index Seek auf unserem nicht-gruppierten Index.

Da der SQL Server nun alle notwenigen Spalten in unserem Index findet, gibt es keine Notwendigkeit mehr für den Ausflug in den gruppierten Index. Das ist bewusst eingesetzt Redundanz, wobei wir um die Pflege nicht kümmern müssen. Ach ja, und wir brauchten dafür natürlich keinen Tabellenhinweis!

Indizes mit eingeschlossenen Spalten sind zwar äußerst nützlich, aber bitte übertreibt jetzt nicht die Verwendung! Die Pflege kostet im Hintergrund immer Zeit beim Schreiben.

Und letzte Worte zu Tabellenhinweisen: Ja, es gibt ganz, ganz wenige Sonderfälle in denen die Verwendung Sinn macht. Aber glaubt mir, die sind wirklich selten!!!

Reifegradmodelle im Projektmanagement

2010-07-12T17:44:00.001+02:00

Mich erreichte die Nachfrage, was ich denn mit Reifegradmodellen im Projektmanagement meinen würde. In einem Post hatte ich den Begriff kurz fallengelassen als Hinweis auf einen möglichen Projektverlauf im Rahmen eines Performance Tunings.

Oft beschreiben Reifegradmodelle themenbezogen die möglichen Entwicklungsschritte einer ganzen Organisation. Es gibt dabei Modelle für ganz unterschiedliche Herausforderungen: IT-Infrastruktur & Security, Business Intelligence, Projektmanagement usw. Dabei wird in der Regel als Orientierung festgelegt, wo die Organisation im Referenzmodell gerade steht, was die nächste Stufe ist und durch welche Merkmale diese zu erreichen wäre. Das Reifegradmodell fasst dabei durch sein “Modell” die einzelnen “Reifegrade” der notwendigen Prozesse innerhalb der Organisation zusammen.

Es geht mir nun darum, wie große, unhandliche und komplexere Projekte “eingefangen” werden können und damit das Risiko eines Scheiterns bereits während der Planung minimiert werden kann.

Im Rahmen von Projekten werden häufig eine ganze Reihe von Prozessen bzw. Funktionalitäten implementiert oder auch erweitert. Während der Planung von Projekten gilt es für diese Implementierungen bzw. Änderungen einen Entwurf zu erstellen, welcher beschreibt wann was wie umgesetzt wird. Die Praxis zeigt, dass dieser Vorgang häufig damit endet, dass der Planer vom Hundertsten ins Tausendste kommt. Dieser Umstand kommt häufig daher, dass nicht immer klar ist, wie weit eine Implementierung in dem jeweiligen Teilprojekt gehen soll bzw. muss! So entstehen oft große undhandliche Projekte, welche dann leider auch meist zum Scheitern verurteilt sind.

Schauen wir uns mal ein plakatives Beispiel an. Es soll ein komplettes Data Warehouse erstellt werden. Dieses Vorhaben als ein einziges großes Projekt abzubilden ist nicht unüblich. Das Scheitern solcher Projekte leider auch nicht.

Erfolgsversprechender ist es die für den Betrieb eines Data Warehouse notwendigen Prozesse in einem so genannten Implementierungsprojekt ans Laufen zu bringen. Das Projekt ist erfolgreich, wenn die Prozesse “leben” und funktionieren. Änderungen und Erweiterungen am DWH sind dann meist keine Projekte mehr, sondern fallen in die Kategorie Change Request. Damit befinden wir uns dann mitten im Change Management des Life-Cycle-Managements eines DWHs.

Trotz alledem wird es bei größeren Erweiterungen oder gar neuen Funktionen wieder die Notwendigkeit von Projekten geben. Was für Erweiterungen können das sein? Dafür ist das Thema Daten Qualität ein schönes Beispiel. Wie weit wollen oder müssen wir im Implementierungsprojekt beim Thema Daten Qualität im Data Warehouse gehen? Wäre es nicht sinnvoll für den Prozess DQ eine Reihe von Reifegraden zu definieren, mit denen wir die Entwicklungsstände dieses Teilprozesses dokumentieren und planen können?

Wenn wir bei dem Data Warehouse bleiben, dann gibt es zum Beispiel auch das Thema nachhaltige Protokollierung des Zugriffs auf Daten (kurz Audit). Ist in vielen Umgebungen ein sehr wichtiges Thema, nur wie weit soll bereits im Implementierungsprojekt dieser Prozess vollständig abgebildet werden? Wieder kann hier eine Reihe von Reifegraden die Planung vereinfachen, da diese die künftige Entwicklungsschritte der Funktionalität vorbereiten und klar voneinander abgrenzen.

Fassen wir nun die vorgesehenen Reifegrade der geplanten Prozesse und Funktionalitäten zusammen, so erhalten wir ein Referenzmodell für die angestrebte “komplette” Lösung, welche wir schrittweise erreichen können. Die Reifegrade sind damit auch die Grundlage für die Planung der Teilprojekte, welche wieder ganz klassisch im Projektmanagement stattfinden kann. Hier kommen sich unser Reifegradmodell und er Begriff Strategie sehr nahe.

Unterstützt kann diese Vorgehensweise dadurch werden, dass wir für unsere diversen technischen Objekte in unserer Lösung ein Repository nutzen und in diesem u. a. den jeweiligen Entwicklungsstand festhalten und auch gleich die weitere Planung daran binden. Wichtig ist mir hier die Abgrenzung zur klassischen separaten Dokumentation. Diese hat zwar ihre Daseinsberechtigung, aber hat in der Regel keine direkte Bindung mit den Objekten in der Lösung. Objekte in einem solchen Repository können zum Beispiel SSIS Pakete, DQ Regeln, Inhalte von Reports (RDL), Dimensionen und Fakten eines Cubes und / oder eines Data Warehouses sein.

Die Kombination aus einem Reifegradmodell für die angestrebte Lösung und Repository ist eine wertvolle Unterstützung für das Projektmanagement, da es sowohl die Planung als auch die Kommunikation im Teilprojekt vereinfacht. Dieses Vorgehensmodell lässt sich leicht auf andere komplexere IT-Projekte ausdehnen. SharePoint Projekte sind zum Beispiel ebenso prädestiniert für diese Vorgehensweise.

Size matters! Woher bekomme ich größere Testdatenbanken?

2010-07-08T19:23:00.001+02:00

Häufig bekomme ich zu hören, dass die Adventure Works Datenbank ja zu klein sei, um mal wirklich Performance Tuning Szenarios im stillen Kämmerlein zu testen.

Ok, zuerst natürlich die Anmerkung, dass wohl die wenigsten in besagtem Kämmerlein auch eine entsprechende Hardware haben, um “echte” Erlebnisse zu haben und damit Erfahrung zu sammeln. Sowas bekommt Ihr nur im Feld!

Aber gut, ich gebe gern zu, dass die Adventure Works Umgebung tatsächlich ein wenig schlank ist. Daher hier ein paar Tipps wie Ihr an wesentlich mehr Daten kommen könnt!

Erst mal die Frage an den Hersteller Microsoft, was dieser uns so bietet? Und siehe da, es gibt eine wesentlich größere Datenbank:

Microsoft Contoso BI-Demodatensatz für die Einzelhandelsbranche

Woher kommen die denn nun? Das ist u. a. das Futter für PowerPivot Demos! :-)

Hey, wer sagt da jetzt, dass ihm der Download zu groß ist? Ihr wolltet doch mehr…

Ach so, es sollen mehr Datensätze aus dem Nix entstehen und zwar genau jetzt! Auch da kann geholfen werden. Es gibt zwar diverse Skripte dafür im Netz, aber die haben wir natürlich nie dann zur Hand, wenn wir diese brauchen. Müssen wir also kurz lernen, wie wir das quasi aus dem Kopf immer wieder schaffen werden.

Es gibt zwar Ansätze mit Schleifen und einzelnen Inserts. Wir wollen das aber mal in einer Query versuchen. Vielleicht wird es auch noch eine Sub-Query.

Rettung naht in Form der master.sys.columns. Wie das jetzt? Nun ja, die ist hoffentlich immer da und hat einige Zeilen. Daher merken:

master.sys.columns

Und? Folgende Query wirft doch gerade mal 659 Zeilen bei mir und da ist auch gar nix nützliches drin!

select COUNT(*)
from master.sys.columns a;

Natürlich sind das jetzt noch zu wenig Zeilen, aber jetzt kommt der zweite Teil zum merken:

cross join

Was? Wozu sollen das denn jetzt taugen? Ok, schaut Euch die folgende Query an:

select COUNT(*) as Anzahl
from master.sys.columns a
cross join master.sys.columns b

Das macht schon mal 434.281 Zeilen bei mir. Und die hier?

select COUNT(*) as Anzahl
from master.sys.columns a
cross join master.sys.columns b
cross join master.sys.columns c

Wow, da kommen nun 286.191.179 Zeilen bei rum. Nur was haben wir damit gewonnen? Den Zähler an den wir unsere Testdaten anhängen können! Nun brauchen wir nur noch kurz eine laufende Nummer. Moment mal, es gibt doch zum Beispiel ROW_NUMBER(). Aber die ist ja vorgesehen für die Over Klausel, aber das lässt sich relativ leicht “aushebeln”. Und mit dem TOP lässt dich die Anzahl genau steuern.

select top 500000
ROW_NUMBER() over( order by a.is_filestream ) as nummer
from master.sys.columns a
cross join master.sys.columns b
cross join master.sys.columns c

ROW_NUMBER() over( order by a.is_filestream ) as nummer

Hey, jetzt nicht schlapp machen beim merken! Ok? Führen wir mal alles zusammen. Mit der folgenden Query haben wir schon 50.000.000 Zeilen. Mit den Spalten Produkt, Lieferant und Umsatz könnt Ihr wenig spielen.

select
nummer,
N'Produkt'+ CAST( nummer % 100 as nvarchar(15)) as Produkt,
N'Lieferant' + CAST (nummer % 10 as nvarchar(15)) as Lieferant,
CAST(5000+ (nummer % 5000) as money) as Umsatz
into t9
from
(
select top 50000000
ROW_NUMBER() over( order by a.is_filestream ) as nummer
from master.sys.columns a
cross join master.sys.columns b
cross join master.sys.columns c
) x

So, ich hoffe, dass nun der eine oder andere was für sich mitnehmen konnte bzw. nun eine Idee hat, wie aus dem Nix Testdaten entstehen können. Und nun viel Spaß beim Indizieren und passt mir bitte auf, dass Ihr nun nicht produktive Server mit Testdaten flutet!

Indizes? Haben wir doch schon längst! Lassen Sie uns nun bitte zu den echten Tuning Methoden kommen.

2010-07-07T19:35:00.001+02:00

Das ist häufig eine spontane Antwort, welche ich auf den Vorschlag bekomme eine Anwendung mittel Indizes zu optimieren, wenn so das Gröbste aus dem Weg ist.

Sowohl Entwickler als auch Administratoren scheint durchaus bewusst zu sein, dass Indizes und das Laufzeitverhalten einer Datenbank durchaus zusammenhängen (können). Aber ihnen scheint oft nicht die mögliche Tiefe des Themas bewusst zu sein, denn sie suchen häufig den wahren heiligen Gral der Performance Optimierung. Indizes haben sie schon, also muss es da draußen noch etwas anderes geben. Ist doch logisch, oder? :-)

Mit diesem Post möchte ich den Leser, welcher sich angesprochen fühlt, dafür sensibilisieren, dass Indizierung viel mehr zu bieten hat, als er sich für den Moment vielleichtnvorstellen kann.

Es hat sicherlich auch etwas damit zu tun, welche Rolle Indizes früher gespielt haben. Unter dbase III+ waren Indizes zum Beispiel eigentlich nichts anderes als nur zusätzliche Sortierreihenfolgen, welche auch für eine schnellere Suche genutzt werden konnten. Wer kann sich noch an FIND und SEEK erinnern? :-)

In einem modernen relationalem Datenbank System wie dem SQL Server schaust ein wenig anders aus. Daten liegen meist bereits in Form eines B-Trees vors. Was ist ein B-Tree? –> http://de.wikipedia.org/wiki/B-Baum. Und ja, es gibt wohl tatsächlich Fälle, in denen ein sogenannter Stapel (Heap) Sinn machen würde. Sind aber recht selten und legen wir gedanklich mal zur Seite.

Es gibt pro Tabelle daher einen gruppierten (clustered index, CI), der entspricht auch gleichzeitigt DEN DATEN, und meist eine ganze Reihe von nicht gruppierten Indizes (non-clustered index, NCI). Damit scheint das Thema bereits durch zu sein. Es werden die Spalten mit einem Index hinterlegt, nach denen später “gesucht” werden soll. Damit ist meist die Verwendung mittels WHERE gemeint. Alles Mögliche wurde getan. Dabei fängt der Spaß doch jetzt erst richtig an!

Ein Index ist nicht nur ein Weg um Daten schneller zu finden, häufig ist der Index gleichzusetzen mit den Daten. Nun ja, oder zumindest einem Teil der Daten. Am Besten den Teil der Daten, den ich gerade benötige. Ich hatte ja in einem Post darauf hingewiesen, dass die Vermeidung von IO Operationen das Ziel sein sollte. Mir bringen die schönsten Indizes nichts, wenn sich der SQL Server durch Unmengen Datenbankseiten wühlen muss.

Worauf kann geachtet werden? Und, nein, ich möchte hier keine Kurzanleitung für die effektive Indizierung liefern, sondern nur mal kurz anreißen wie weit das Thema gehen kann. by the way, viel Sinnvolles über Indizierung steht in der SQL Server Hilfe (BooksOnline)!

Fangen wir mal mit was Einfachem an. Die Wahl des richtigen Clustered Index Keys ist bereits entscheidend. Viele schauen dann auf und fragen: Welche Wahl? Ist das nicht immer der Primäre Schlüssel? Ja, per default ist er das meist, aber das muss nicht so sein und macht auch oft keinen Sinn! Denn die Reihenfolge in welcher meine Daten vorliegen ist gerade bei sogenannten Bereichsabfragen von Vorteil, aber wer fragt schon ständig von Kundennummer 4711 bis 5289 ab? Eher kommt wohl sowas vor wie “Alle Kunden in Köln” oder “Alle Umsätze in 2009”. Also ist hier die erste Chance zum Mitmachen.

Kommen wir mal zu den nicht-gruppierten Indizes. Das ist doch “nur” ein Verweis auf die Daten im gruppierten Index, oder? Ja, aber das muss nicht so sein! Weil wenn der SQL Server im NCI alles findet, was er für die Beantwortung einer Abfrage benötigt, dann ist der so clever und lässt den CI doch tatsächlich links liegen und bedient sich aus dem NCI. Nun kommt natürlich sofort die Frage: “Aber was soll eine Abfrage in der nur Ort vorkommt, weil mehr steht doch nicht im Index?!? Ich brauche doch auch noch den Umsatz!” Und da fängt der Zauber an, denn es hält uns nichts davon ab, dass wir den Umsatz einfach mit in den Index legen. Ab SQL Server 2005 gibt es für sogenannte abdeckende Indizes sogar ein extra GUI Erlebnis (Eingeschlossene Spalten). Wir erzeugen bewusst Redundanz. Das ist immer ein Moment, da zeigt sich, ob der Berater den starrenden Augen des Kunden gewachsen ist. “Was, bewusst Redundanz herbeiführen? So ein Blödsinn! Und wie wird das gepflegt?” Das Schöne ist, dass sich das selbst pflegt. Ok, die Pflege kostet extra Zeit beim Schreiben, aber wenn der lesende Zugriff unterstützt werden soll, dann macht sowas durchaus Sinn. Die meisten Anwendungen sind eh viel mehr am Lesen als am Schreiben. Passt schon, aber besser vorher mal prüfen und nicht übertreiben.

Die Reihenfolge der Spalten in einem Index spielt auch noch eine entscheidende Rolle! Hier kommt das Thema Selektivität zum tragen.

Dann kann doch tatsächlich ein View wiederum in Form eines gruppierten Index persistiert werden. Damit lässt sich häufig auch eine Menge machen. Und natürlich lassen sich auf diesem CI auch wieder NCIs anlegen.

NCI können gefiltert werden, es wird nur ein Teil der Zeilen im CI vorgehalten. Spart wiederum Zeit bei der Pflege und Platz!

Und pro Partition können auch wieder unterschiedliche Indizes verwendet werden. Viele Indizes nur für die aktuellen Daten und für das historische Zeug nur das nötigste.

Um wem das noch nicht reicht, dem der Hinweis, dass selbst die Wahl auf welchen Festplatten welche Indizes liegen, oft zur Performance des Systems beitragen kann.

Und so weiter… wir wollten das ja auch nur mal kurz anreißen!

Das Thema Performance Tuning kann äußerst tief in die Interna des SQL Servers gehen. Häufig kommt die Frage nach dem “richtigen” Tuning. Die ist man mal meist gar nicht so einfach zu beantworten. Wie viel Tuning darf es denn sein? Am Anfang eines Performance Tuning Projektes kann meist mit einfachen Mitteln eine ganze Menge Performance rausgeholt werden. Dann geht es in die Detailanalyse, um den vielen kleinen aber lästigen Abfragen auf die Spur zu kommen. Pflicht ist dann noch ein Blick auf die Auswirkungen von parallelen Transaktionen, damit kann der Berater auch noch viel Spaß haben.

Performance Tuning ist immer ein laufender Prozess, kein einmaliges Projekt! Um trotzdem allen Maßnahmen, Möglichkeiten und Abhängigkeiten Herr zu werden empfehle ich die Verwendung eines Reifegradmodells, in welchem festgelegt wird wie viel Zeit für welches Thema wann aufgebracht werden soll. Sonst kann das Ganze leider ziemlich schnell ins Endlose ausufern und keine messbaren Erfolge bringen.

Der Lernprozess beim Performance Tuning ist wohl nie vorbei, da es immer noch eine tiefere Ebene gibt im SQL Server. Damit man aber mit seinem SQL Server überhaupt vom Fleck kommt, sollte ganz ordentlich beim Fundament angefangen werden und dann darf es nach und nach komplizierter werden. Viel es sein muss, nun ja, da empfehle ich von Koch “Die 80/20 Regel” Basiswerk zu.

GROUP BY mit ROLLUP

2010-07-06T20:30:00.001+02:00

Anbei ein Thema, welches mir neulich erst wieder aufs Flipchart kam. Wie errechne ich in einem gruppierten Resultset möglichst einfach Zwischensummen?

Nun ja, da sieht der Berater draußen schon recht spannende Konzepte in denen diverse UNION ALL eine entscheidende Rolle spielen! Dabei gibt es dafür in der Abfragesprache SQL extra ein Argument für diese Herausforderung.

Kurze Anmerkung dazu, wenn Ihr zum Beispiel mit den Reporting Services unterwegs seit, dann habt Ihr diese Fragestellung sehr wahrscheinlich gar nicht, da dort Zwischensummen durch die Gruppierungsfunktion im Report abgebildet wird. So, der Rest von uns kann nun weiterlesen.

Ach ja, und das betrifft jetzt nicht nur den SQL Server, wir bewegen uns da durchaus im ANSI Standard! :-)

Wir nehmen unsere gute alte AdventureWorksDW2008. Als Beispiel wollen wir uns den Umsatz aus der FactInternetSales aufgeteilt nach Attributen aus der Dimension Product darstellen lassen.

select EnglishProductCategoryName, EnglishProductSubcategoryName, EnglishProductName, SalesAmount
from FactInternetSales fis
left join DimProduct dp on fis.ProductKey = dp.ProductKey
left join DimProductSubcategory dps on dps.ProductSubcategoryKey = dp.ProductSubcategoryKey
left join DimProductCategory dpc on dpc.ProductCategoryKey = dps.ProductCategoryKey

Ok, so im Detail muss es ja man mal gar nicht sein, also bilden wir Gruppen mittels GROUP BY.

select EnglishProductCategoryName, EnglishProductSubcategoryName, EnglishProductName, sum(SalesAmount) as Umsatz, COUNT(*) as Anzahl
from FactInternetSales fis
left join DimProduct dp on fis.ProductKey = dp.ProductKey
left join DimProductSubcategory dps on dps.ProductSubcategoryKey = dp.ProductSubcategoryKey
left join DimProductCategory dpc on dpc.ProductCategoryKey = dps.ProductCategoryKey
group by EnglishProductCategoryName, EnglishProductSubcategoryName, EnglishProductName
order by EnglishProductCategoryName, EnglishProductSubcategoryName, EnglishProductName

Besser! Aber jetzt fragt doch tatsächlich jemand nach Zwischensummen für Category und Subcategory! Wie bringen wir die nun in das Resultset? Dafür gibt es die GROUP BY Erweiterung ROLLUP!

Und hier jetzt ein Beispiel mit GROUP BY ROLLUP.

select EnglishProductCategoryName, EnglishProductSubcategoryName, EnglishProductName, sum(SalesAmount) as Umsatz, COUNT(*) as Anzahl
from FactInternetSales fis
left join DimProduct dp on fis.ProductKey = dp.ProductKey
left join DimProductSubcategory dps on dps.ProductSubcategoryKey = dp.ProductSubcategoryKey
left join DimProductCategory dpc on dpc.ProductCategoryKey = dps.ProductCategoryKey
group by rollup( EnglishProductCategoryName , EnglishProductSubcategoryName, EnglishProductName)
order by EnglishProductCategoryName, EnglishProductSubcategoryName, EnglishProductName

Was ist passiert? Wir sehen in der ersten Zeile nun die Umsätze gesamt über alle drei Attribute. Das ist noch keine Kunst, dafür hätten wir kein GROUP BY benötigt, dass hätte auch ein einfaches SUM geschafft. Aber nun bekommen wir auch die Summen je Subcategory und Category dargestellt. Das NULL zeigt jeweils an, dass es sich um eine Summenzeile für das jeweilige Attribut handelt.

Und wer jetzt sagt, dass er das schon alles kennt aber eine andere Syntax dafür verwendet. Der sei gewarnt! Denn die Notation mit “with rollup” ist nicht ANSI-konform und läuft daher aus! Fällt Euch also vielleicht bei einem späteren Update auf die Füße!

Wer sich nun noch an den NULLs stört und diese nicht in seiner Anwendung nutzen möchte, der kann diese natürlich auch direkt in der Abfrage in was Sprechendes ändern .

select
isnull(EnglishProductCategoryName,'Summe') as Produktkategorie,
isnull(EnglishProductSubcategoryName, 'Summe') as Produktunterkategorie,
isnull(EnglishProductName,'Summe') as Produkt,
sum(SalesAmount) as Umsatz, COUNT(*) as Anzahl
from FactInternetSales fis
left join DimProduct dp on fis.ProductKey = dp.ProductKey
left join DimProductSubcategory dps on dps.ProductSubcategoryKey = dp.ProductSubcategoryKey
left join DimProductCategory dpc on dpc.ProductCategoryKey = dps.ProductCategoryKey
group by rollup( EnglishProductCategoryName , EnglishProductSubcategoryName, EnglishProductName)
order by EnglishProductCategoryName, EnglishProductSubcategoryName, EnglishProductName

Und noch was. Da AdventureWorksDW2008 ja die Basis des Microsoft Beispiel-Cubes für die Analysis Services ist, können wir die Ergebnisse unserer Query auch mittels Cube überprüfen bzw. den Cube mit unserer Query gegenprüfen. Hey, cool, geht auf! :-)

Für viele Anwendungsfälle wäre es sehr wahrscheinlich einfacher, wenn wir direkt aus unserer Applikation auf einen OLAP Cube zugreifen würden. Das wird aber noch seltener genutzt als die ROLLUP Erweiterung, dabei ist die Anwendung fast einfacher. Das bringt mich zu ADOMD.NET, aber das beschreibe ich ein anderes mal im Detail.

Wie messe ich eigentlich den Erfolg der Optimierung einer SQL Abfrage?

2010-07-05T22:38:00.001+02:00

Hier ein Thema, welches mir immer wieder in Coachings von Einsteigern und Juniorberatern begegnet. Daher speziell für diese Zielgruppe ein paar Grundlagen.

Wie messe ich eigentlich, ob dank einer Maßnahme eine Query “schneller” geworden ist?

Der eine oder andere mag denken, dass das doch eine überflüssige Frage ist. Die Optimierung war erfolgreich, wenn eine Abfrage schneller fertig ist. Wo ist also das Problem? Und schließlich hat doch das Management Studio in der rechten untern Ecke extra dafür einen Timer. Und im Profiler kann ich mir doch auch die Dauer einer Abfrage anschauen. Damit sollte das Thema doch eigentlich durch sein, oder? Und bei vielen Queries steht da unten doch eh nur 00:00:00, die können also doch gar nicht weh tun.

Nun ja, ganz so einfach ist es dann doch nicht. Die Zeit, welche eine Query benötigt, ist immer relativ und kann von vielem abhängig sein. Die wesentlich entscheidendere Größe beim Tuning ist die Anzahl der für die Beantwortung notwendigen Datenbankseiten! Und dabei ist es fast egal, ob die Seiten gerade warm und trocken im Cache liegen oder gar erst vom Plattensystem gelesen werden müssen. Seite bleibt Seite. Daher sollte ein Ziel von Optimierungsmaßnahmen immer sein, dass die Anzahl der für ein Resultset notwendigen Datenbankseiten minimiert wird! Auch bei Abfragen, welche gefühlt flott laufen, kann es Sinn machen diese entsprechend zu optimieren, wenn diese auf einem Server vielleicht viele tausend Mal am Tag ausgeführt wird.

Ok, nur wie kommen wir nun an diese Anzahl der notwendigen Seiten und wie reduzieren wir diese?

Für den Einstieg in das Thema ist es nicht immer notwendig gleich den SQL Profiler mitlaufen zu lassen. Auch Querypläne müssen nicht immer gleich zerlegt werden, auch wenn das einen bereits deutlich nach vorne bringen würde.

Mit folgender Anweisung schalten wir die Darstellung einer Statistik ein, welche uns die Anzahl der Datenbankenseiten pro verwendeter Tabelle zeigen wird:

set statistics io on;

Und nun noch eine kleine Abfrage für die gute alte AdventureWorksDW2008:

select SUM(SalesAmount), COUNT(*)
from dbo.FactInternetSales fis
left join dbo.DimCustomer dc on dc.CustomerKey = fis.CustomerKey
where dc.YearlyIncome > 50000;

Und schon sehen wir im Management Studio unter Meldungen folgendes:

(1 Zeile(n) betroffen)
Worktable-Tabelle. Scananzahl 0, logische Lesevorgänge 0, physische Lesevorgänge 0, Read-Ahead-Lesevorgänge 0, logische LOB-Lesevorgänge 0, physische LOB-Lesevorgänge 0, Read-Ahead-LOB-Lesevorgänge 0.
FactInternetSales-Tabelle. Scananzahl 1, logische Lesevorgänge 1030, physische Lesevorgänge 0, Read-Ahead-Lesevorgänge 0, logische LOB-Lesevorgänge 0, physische LOB-Lesevorgänge 0, Read-Ahead-LOB-Lesevorgänge 0.
DimCustomer-Tabelle. Scananzahl 1, logische Lesevorgänge 978, physische Lesevorgänge 0, Read-Ahead-Lesevorgänge 0, logische LOB-Lesevorgänge 0, physische LOB-Lesevorgänge 0, Read-Ahead-LOB-Lesevorgänge 0.

Das “Ziel” habe ich mal markiert. Diese Werte gilt es im Rahmen einer Optimierung zu reduzieren. Denn je weniger Seiten benötigt werden, um so schneller wird die Abfrage und, kleiner Nebeneffekt, um so geringer sind Probleme durch Sperren. Performanceschwierigkeiten kann so viele Gründe haben, aber das würde hier zu weit gehen.

Aber wie kommen wir nun zu einer Optimierung? Es gibt zwei grundsätzliche Wege:

durchdachtere SQL Abfragen (weites Feld, würde den Rahmen dessen hier für den Moment sprengen)
bessere Indizierung (wird von viel zu vielen unterschätzt und von einigen tatsächlich auch überschätzt)

Am Ende geht es um weniger Seiten oder wie der Profi sagt: Weniger IO Operationen.

Wir versuchen es mal mit der Erzeugung von zwei Indizes, um die Lesevorgänge deutlich reduzieren. Für Details einfach mal einen Blick in die BooksOnline des SQL Server werfen.

CREATE NONCLUSTERED INDEX [ix_DimCustomer_YearlyIncome] ON [dbo].[DimCustomer]
(
[CustomerKey] ASC
)
INCLUDE ( [YearlyIncome]) ON [PRIMARY]

CREATE NONCLUSTERED INDEX [ix_FactInternetSales_CustomerKey_SalesAmount] ON [dbo].[FactInternetSales]
(
[CustomerKey] ASC
)
INCLUDE ( [SalesAmount]) ON [PRIMARY]

So, identische Query nochmal starten und schon sehen wir, dass unsere Bemühungen erste Erfolge zeigen. Ach ja, natürlich bleibt das Ergebnis der SQL Abfrage identisch!

(1 Zeile(n) betroffen)
FactInternetSales-Tabelle. Scananzahl 1, logische Lesevorgänge 257, physische Lesevorgänge 0, Read-Ahead-Lesevorgänge 0, logische LOB-Lesevorgänge 0, physische LOB-Lesevorgänge 0, Read-Ahead-LOB-Lesevorgänge 0.
DimCustomer-Tabelle. Scananzahl 1, logische Lesevorgänge 44, physische Lesevorgänge 0, Read-Ahead-Lesevorgänge 0, logische LOB-Lesevorgänge 0, physische LOB-Lesevorgänge 0, Read-Ahead-LOB-Lesevorgänge 0.

Was passiert da? Kurzgefasst kann gesagt werden, dass der Queryoptimizer nun nur noch unsere beiden Indizes verwendet, welche genau die Spalten bereitstellen, die unsere Query benötigt. Und damit wäre normalerweise noch nicht Schluss mit der Optimierung, aber für den Moment soll das reichen, um das Konzept zu verdeutlichen wie wir den Erfolg einer Maßnahme messen können. Denn darum ging es mir hier.

Also, nochmal wiederholt: Erfolgreiche Optimierung heißt u. a. Reduzierung von Seitenzugriffen!

Und messen könnt Ihr das u. a. mittels set statistics io on.

PASS Camp 2010 R2 – Save the Date!

2010-06-30T13:31:00.001+02:00

Vielleicht habt Ihr es im PASS Newsletter ja schon gelesen. Es wird dieses Jahr ein weiteres PASS Camp geben!

Vom 19. – 21.10.2010 geht es im Gut Höhne in Mettmann wieder nur um das Thema SQL Server.

Themen werden sein Self-Service BI, BI für Developer und BI für Admins.

Nachdem ich beim ersten PASS Camp in diesem Jahr eine Late Night Session hatte, gibt es mich nun ganze 3 Tage lang zum Thema BI für Developer. Details dazu werden aber noch folgen. Wer meinen Blog hier in den letzten Jahren verfolgt hat, kann sich schon denken, was wir da gemeinsam machen werden. Gemeinsam? Genau, da bei den PASS Camps immer ein großer Wert auf viele Hands-On gelegt wird ist mitmachen gefordert. Also werdet Ihr mir nicht nur beim Codieren zusehen (wie öde…), sondern selbst Eure Ideen umsetzen dürfen!

Ich freue mich schon drauf und hoffe viele Euch vor Ort zu treffen!

ps: Und für den Fall, dass Ihr den PASS Newsletter gar nicht bekommen… dann schnell unter www.sqlpass.de anmelden!

Interaktive Referenzhandbücher für Office 2010!

2010-06-07T12:07:00.001+02:00

Der eine oder andere wird sich vielleicht noch an einen Post vom Juni 2007 erinnern, in welchem ich die interaktiven Referenzhandbücher für Office 2007 vorgestellt habe.

Nun ist Zeit für Office 2010! Und schon gibt die interaktiven Referenzhandbücher für 2010! Wie schon 2007 eine sehr gelungene Hilfe für Einsteiger in das aktuelle Office. Technologisch wird nun natürlich auf Silverlight gesetzt. Ein Vorteil ist, dass die Handbücher nun auch offline installiert werden.

Klönschnack för Lüüd, de dat suur hebbt mit de SQL Server

2010-06-04T22:03:00.001+02:00

Am nächsten Donnerstag, den 10. Juni 2010, findet das 50. Treffen der Regionalgruppe Hamburg des PASS Deutschland e.V. statt!

Zum 50. Treffen halten wir einen „Tech-Talk“ zum Thema Troubleshooting ab. Jeder kann seine ganz persönliche Herausforderung mit dem SQL Server mitbringen und wir werden dann versuchen, gemeinsam einen Lösungsansatz dafür zu finden!

Unter allen Teilnehmern des Treffens verlosen wir eine NFR Vollversion von Microsoft Expression Web 3!

Zwei Community Abende in Böblingen und einer in Hamburg

2010-06-03T12:29:00.001+02:00

Nächste Woche ist mal wieder eine Community Woche! Es stehen ganze drei Community Events an.

Dienstag und Mittwoch (8. und 9.6.2010) bin ich im Raum Stuttgart unterwegs und werde Abends in der Microsoft Niederlassung Böblingen jeweils einen kleinen Vortrag zum Thema SQL Server halten.

Am Dienstag werde ich vor der Partner Technical Community Stuttgart (https://www.xing.com/net/msptc/) sprechen. Thema ist die Vermittlung von Basis Wissen für den Administrator über den SQL Server mit (fast ganz) ohne Marketing. :-)

Sofern Ihr die Partner Technical Communities noch nicht kennt, hier ein wenig Werbung für diese:

“Diese Gruppe ist eine Networking-Plattform für technische Mitarbeiter aus dem Microsoft Partner-Netzwerk. Ziel ist der Aufbau einer Community, die sich regelmäßig zu technischen Produktfragen austauscht und Neuentwicklungen kritisch & zielorientiert begleitet. Die Gruppe soll Basis für regionale Aktivitäten sein und vor allem Partner außerhalb der Ballungsgebiete eng einbinden. Wir bieten Know how Austausch und eine Diskussionsplattform - jedoch keinen technischen Support!“ (frech geklaut von der Beschreibung in Xing)

Den Mittwoch geht es dann zu meiner Stamm-Community, dem PASS Deutschland e.V., zur Regionalgruppe Stuttgart (http://www.sqlpass.de/Regionalgruppen/Stuttgart/tabid/87/Default.aspx). Dort werde ich über den Einsatz von ADOMD.net für den Zugriff auf Analysis Services Cube sprechen. Ich werde die notwendigen Grundlagen vermitteln (äh, nein, das wird kein MDX Crashkurs!) und auch ein paar Einsatzbeispiele zeigen.

Dann wieder schnell zurück nach Hamburg, weil am Donnerstag Abend ist dort das 50. Treffen der PASS Regionalgruppe Hamburg (http://www.sqlpass.de/Regionalgruppen/Hamburg/tabid/78/Default.aspx)!

Das verspricht eine interessante Woche mit vielen neuen Gesichtern zu werden. Ich freue mich darauf! Vielleicht sehen wir uns ja bei einem der Events?!?

Cube Funktionen in Excel 2007 & 2010

2010-05-09T08:50:00.001+02:00

In der letzten Woche kam während eines SSAS Workshops die Frage nach dem Sinn der Cube Funktion in Excel 2007 & 2010 auf. Zwar war den meisten Teilnehmern die Existenz der Funktionen bekannt, da sie diese über den Menüpunkt “In Formeln konvertieren” in Excel (s. Screenshot) kannten, aber bisher hatte kein Teilnehmer Erfolg dabei einen Bericht von Grund auf mit den Funktionen zu erstellen.

Die offizielle Online Hilfe von Microsoft kennt zwar die Funktionen, aber die Beschreibung der Funktionsweise als auch die Beispiele dort sind eher knapp gehalten bzw. leider auch ein wenig substanzlos.

Welche Funktionen für die Arbeit mit Analysis Services Cubes kennt ein Excel überhaupt? Das lässt sich leicht herausfinden. Einfach mal “=cube” in eine Zelle eingeben. Die AutoVervollständigen Funktion von Excel zeigt uns alle Excel Funktionen an.

Das sind ganze 7 Excel Funktionen. Fangen wir mit einem einfachen Beispiel für CUBEWERT an. Dazu geben wir in eine Zelle “=cubewert(” ein.

Als ersten Parameter benötigen wir eine Verbindung. Nach der Eingabe eines Anführungszeichen bekommen wir eine Auswahl aller gespeicherten Verbindungen zu Analysis Services Würfeln.

Wie kommt aber Euer Excel nun an eine solche Verbindung? Wenn Ihr von einer leeren Arbeitsmappe aus startet, dann kennt diese noch keine Verbindungen. Verbindungen werden über den Tab “Daten” und den Punkt “Verbindungen” hinzugefügt.

Und die vorhandenen Verbindungen entstehen, wenn Ihr Euch schon mal mit Würfeln verbunden habt. Dazu ist dieser Dialog im Datenverbindungs-Assistent. Der kommt Euch sicher bekannt vor.

Aber zurück zu unserem CUBEWERT Beispiel. Wir wählen nun eine Verbindung aus indem wir die “Tab”-Taste drücken und mit Anführungszeichen die Bezeichnung der Verbindung abschließen.

Nun noch ein Semikolon und Excel erwartet den nächsten Parameter. Geben wir erst mal wieder Anführungszeichen ein.

Was ist das? Das sind ja alle Dimensionen unseres Cubes! Wie hilfreich! Wählen wir erst mal “[Date]” aus. Einfach mit den Cursortasten markieren und wieder die “Tab”-Taste betätigen. Und nun? Einfach mal einen Punkt eingeben.

Und schon sind wir auf dem nächsten Level der Hierarchie der Date Dimension. Dort wählen wir nun “[Date].[Calendar]” aus. Zum Abschluss geben wir noch “.&[2003]”)” ein, da uns das Jahr 2003 interessiert. Eine andere Art der Auswahl gibst gleich.

Mit der Enter-Taste bestätigen wir die Eingabe der Formel. Bei mir erscheint nun folgendes:

Cool! Nur was sagt uns dieses Ergebnis? Wir haben doch bisher nur ein Jahr angegeben und nichts weiter. Woher weiß denn Excel nun was wir wollen? Eigentlich weiß Excel rein gar nichts über unsere Absichten. Das Ergebnis kommt direkt von den Analysis Services und zeigt den Wert des Default Measures “Reseller Sales Amount” an. Starten wir kurz den SQL Profiler und schauen uns mal die MDX Query an, welche Excel absendet für diese Abfrage. Dieses mal interessiert uns das Jahr 2004.

Hier die MDX Query im Detail:

SELECT {([Date].[Calendar Year].&[2004])} ON 0 FROM [Adventure Works] CELL PROPERTIES VALUE, FORMAT_STRING, LANGUAGE, BACK_COLOR, FORE_COLOR, FONT_FLAGS

Auch hier steht nichts vom dem Measure, welches uns tatsächlich interessiert. In unserem Beispiel soll es um den “Internet Sales Amount” gehen. MDX ist bekanntlicherweise nicht ganz einfach und denkt sich schon mal seinen Teil, wenn etwas weggelassen wird. Warum stresse ich diesen Punkt hier? Wenn ich mit den Cube Funktionen arbeiten möchte, dann sind zumindest Grundkenntnisse in MDX hilfreich!

Und MDX ist u.a. die Kunst des Weglassens.

Aber wieder zurück in die Zelle mit unserer Formel. Bearbeiten wir unsere Formel und ergänzen diese mit einem Semikolon um den Wunsch nach einem weiteren Parameter.

Nun steuern wir die Dimension [Measures] an. Moment mal, warum denn die Dimension Measures? Teilt sich ein Cube nicht in Dimensionen und Measures auf? Nun ja, noch ein Beweis dafür, dass wir auf der dunklen Seite der Macht unterwegs sind. Für MDX sind Measures nichts weiter als eine Art weitere Dimension! Wählen wir den “Internet Sales Amount” aus.

Hmm, langsam wir die Formel recht lang.

Aber wir bekommen nun unseren Wert.

Kurz in der klassischen Pivot Darstellung überprüft:

Stimmt! Und was dem geneigten Leser vielleicht aufgefallen ist, ist die Tatsache, dass auch bei den Cube Funktionen die Formatierung als Währung mit übergeben wurde vom Cube. Wie praktisch.

Nun wollen wir den Wert noch weiter filtern. Also Formel wieder bearbeiten und durch ein weiteres Semikolon einen weiteren Parameter beginnen. Die Eingabe der Anführungszeichen bringt uns wieder in die Auswahlbox. Hier wählen wir “[Customer]” und geben wieder einen Punkt an für den nächsten Level. Das machen wir bis wir “[Customer].[Customer Geography].[All Customers].[Germany]” zusammen haben.

Wie Ihr seht, kommen wir auch direkt an die Länder innerhalb der Dimension. Wie komfortabel! Darüber hätten wir weiter oben übrigens auch das Jahr auswählen können. Ihr erinnert Euch?

Wir können also direkt die Formel bearbeiten oder quasi alles das AutoVervollständigen erledigen lassen. Wie ist eigentlich nun unser Wert?

Schick! Und, stimmt er? Schnell wieder ein klassisches Pivot genutzt.

Strike! Was für ein Spaß, oder? Wenn wir uns nun vorstellen, dass wir noch weitere Dimension schneiden wollen, dann stellt sich schnell die Frage nach dem Nutzen der Cube Funktionen. Das ist doch recht umständlich!?!

Wenn wir so weitermachen würden wie bisher, dann ist das tatsächlich recht mühsam und auch ohne echten Nutzen in Excel. Aber wir haben uns bisher ja auch nur eine von 7 Funktionen angeschaut. Und wie so häufig liegt der Nutzen in der Kombination!

Kommen wir zur Excel Funktion CUBEMENGE. Laut Doku bekommen wir damit einen berechneten Satz von Elementen oder Tupeln. Na super, probieren wir das mal aus. Die Basics kennen wir ja schon.

Jetzt brauchen wir einen Mengen Ausdruck? Ok, schauen wir mal.

So, und das ergänzen wir jetzt noch um ein “.children”.

Damit sollten wir, sofern mich meine MDX Kenntnisse nicht komplett verlassen haben, ein Set (Menge) bekommen. Und los! Und was kommt dabei raus?

Nee, schon klar. Was ist das jetzt? Ein Set! Wie soll auch Excel eine unbekannte Anzahl an Daten in nur einer Zelle darstellen? Nur was soll das dann? Und wie bekommen wir raus, was sich dort befindet?

Als erstes nutzen wir mal den Parameter, um eine Beschriftung zu hinterlegen.

Damit haben wir nun zumindest dort was stehen.

Aber was steckt da nun hinter? Nehmen wir gleich mal die nächste Cube Funktion und zwar CUBEMENGENANZAHL. Diese braucht nur einen Parameter und zwar eine Menge. Das trifft sich gut, da wir ja gerade eine über. Also los.

Und was kommt raus?

In unserer “unsichtbaren” Menge stecken also 6 Elemente. Schauen wir uns diese mal an. Und dazu kommt gleich die nächste Cube Funktion ins Spiel und zwar CUBERANGELEMENT.

Auch brauchen wir wieder eine Menge (F8) und einen Rang, sprich die Ansage das wievielte Element unserer Menge wir haben wollen. Und was ist das erste Element?

Ok, das ist doch schon mal was. Holen wir uns die restlichen fünf Elemente dazu. Und damit wir den Rang nun nicht manuell durchzählen, legen wir erst mal eine Zahlenreihe daneben. Dann können wir die Formel gleich schön runterziehen. Statt mit der Zahlenreihe zu arbeiten wäre auch die Verwendung von ZEILE(A1) möglich. Das ist ein alter Excel Trick, um aus dem nichts eine Zahlenreihe innerhalb von Formeln zu erzeugen. Aber zurück zu unserem Beispiel.

Cool, nun haben wir schon unsere Vertriebsgebiete.

Ein paar Zahlen wären nun ganz nett, oder? Da kommt unser alter Freund CUBEWERT wieder ins Spiel. Aber vorher sollten wir nur noch kurz festlegen welche Measures wir sehen wollen. Das können wir ebenfalls hinterlegen. Wir nutzen wir dafür die Cube Funktion CUBEELEMENT.

Nehmen wir wieder unseren “Internet Sales Amount”.

Und die “Internet Freight Cost” haben wir gleich daneben gelegt. Was haben wir denn nun davon außer einer Überschrift? Das sehen wir, wenn wir nun endlich die CUBEWERT Funktion nutzen.

Nun bauen wir uns nämlich die Parameter einfach ein. Zuerst kommt das Gebiet.

Und das erste Measure. Und damit haben wir für den Moment bereits alles zusammen. Das ging doch nun viel schneller, oder?

Damit haben eine Zahl! Nun die Formel auf die restlichen Zellen kopieren und schon haben wir den Rest!

Das ging doch nun richtig schnell, oder? Glückwunsch, damit sind wir schon recht weit gekommen. Alles was uns für den Moment fehlt ist ein wenig Interaktivität, oder? Dazu nutzen wir Filter vom PivotTable ohne die starre Struktur eines solchen zu verwenden. Wie das? Dafür fügen wir an einer freien Stelle einen PivotTable basierend auf der bisher auch verwendeten Verbindung ein. Warum eine freie Stelle? Sonst wird unsere bisherige Arbeit überschrieben!

Da ist nun unser PivotTable. Was machen wir nun damit?

Wir fügen in den Berichtsfilter die Hierarchien “Date Calendar” und “Produkt Categories” ein. Das war es schon! Dann markieren wir die beiden Filterzeilen und verschieben diese über unsere Tabelle.

Es liegt Business Intelligence in der Luft, oder? Nun noch schnell die CUBEWERT Formeln erweitern um die beiden Filter (G5 & G6). Und schön auf alle Zellen kopieren.

Und nun können wir die Filter nutzen.

Und die Auswahl wirkt sich jeweils sofort auf unsere Zahlen aus!

Damit haben wir nun in unserem Arbeitsblatt die Möglichkeit geschaffen direkt auf Cube Daten zuzugreifen ohne die starre Struktur einer PivotTable. Des Weiteren haben wir gleich noch zwei interaktive Filter eingebaut. Das ist schon mal gutes Handwerkszeug, um anspruchsvollere Controllingaufgaben zu meistern. Nun können wir eine weitere Dimensionen hinzufügen und noch ein kleines Chart. Die notwendige Basis dafür haben wir schon geschaffen.

Das mag von der Komplexität und der nötigen Zeit her aufwändig erscheinen, aber mit ein klein wenig Übung geht das schnell und zügig von Hand und der Excel Profi wird diese Möglichkeit einfach und schnell mit immer aktuellen Zahlen zu arbeiten nicht mehr missen wollen. Wann immer sich die Daten im Analysis Services Cube ändern bzw. weitere Daten dazu kommen, werden auch die Informationen im Arbeitsblatt aktualisiert.

Ich hoffe, dass ich dem einen oder anderen mit dieser Schritt-für-Schritt Anleitung einen Einstieg in die Arbeit mit den Cube Funktionen von Excel ermöglicht habe. Viel Freude damit!