Donnerstag, 14. Juli 2011

Wo ist Project Crescent in SQL Server Denali CTP 3?

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

Digg This

Freitag, 17. Juni 2011

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

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!

Digg This

Donnerstag, 9. Juni 2011

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

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.”

image

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

Digg This

Mittwoch, 8. Juni 2011

BASTA! 2011 – Bin als Sprecher dabei

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.

Digg This

Dienstag, 7. Juni 2011

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

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!

Digg This

Samstag, 4. Juni 2011

MDXScript Service – Repository driven calculations

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.

Digg This

Donnerstag, 2. Juni 2011

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

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
Digg This

Mittwoch, 1. Juni 2011

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

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.

Hier klicken für das Video!

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

Digg This

Freitag, 13. Mai 2011

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

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.

Samstag, 7. Mai 2011

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

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.

image

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.

image

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.

image

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!

image

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

image

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.

image

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.

image

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.

image

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

Donnerstag, 5. Mai 2011

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

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

Mittwoch, 4. Mai 2011

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

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!

Sonntag, 1. Mai 2011

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

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

Samstag, 30. April 2011

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

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);

    }

}

Donnerstag, 28. April 2011

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

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!

Mittwoch, 27. April 2011

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

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!

image

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);
    }

Montag, 25. April 2011

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

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.

Samstag, 23. April 2011

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

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.

image

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.

image

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

image

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

image

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

image

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:

image

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

image

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

Donnerstag, 21. April 2011

Reporting Services RS.EXE mit Parametern nutzen

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”.

image 

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)

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.

Mittwoch, 20. April 2011

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

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!

Dienstag, 19. April 2011

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

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:

image

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.

image

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

image

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

image

Und eine kleine Hierarchie darf auch nicht fehlen.

image

Damit bekommen wir folgende Dimension:

image 

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.

image

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

image

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.

 image

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”. 

image

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

image

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:

image

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:

  image Dieses kleine Beispiel basiert auf folgenden Formeln:

image

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:

image

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