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