Freitag, 11. Dezember 2015

Data Vault 2.0

Seit vielen Jahren schon war ich in unterschiedlichen BI / Data Warehouse Projekten engagiert. Gemäß Ralph Kimballs Methodik des dimensionalen Modellierens haben wir versucht, so gut wie möglich die Anforderungen zu ermitteln, dimensionale Modelle mit Fakten- und Dimensionstabellen zu bauen und mit beeindruckenden ETL Prozessen zu beladen. Gelegentlich begegnete ich dem geheimnisvollen Stichwort "Data Vault", aber abgesehen von ein paar Schlagworten konnte ich lange Zeit nichts damit verbinden. Es fehlte nach meiner Einschätzung auch nichts in unseren Projekten - die Ergebnisse waren meistens ganz zufriedenstellend.

Mit den ersten Projekten, die Data Vault einsetzen, hat sich mein Blickwinkel auf BI Projekte jedoch gründlich verändert. Tatsächlich lassen sich damit einige grundlegende Probleme sehr effizient lösen.

Was ist denn nun dieses Data Vault?


Das dimensionale Standard Data Warehouse nach Kimball geht von einer zweistufigen Architektur aus, wie sie die nachfolgende Grafik zeigt:
Zweistufige Architektur nach Kimball
Mit Data Vault kommt eine weitere Stufe zwischen Staging Area und dem dimensionalen Data Warehouse hinzu.
Dreistufige Architektur mit Data Vault
 Diese Schicht, gelegentlich auch Enterprise Data Warehouse genannt, hat zwei Aufgaben:
  • Integrieren der Daten aus unterschiedlichen Quellen
  • Aufbau der Historie aller Daten, die diese Quellen liefern
Dabei handelt es sich um eine Datenbank, in der drei Typen von Tabellen modelliert sind:
  • Hubs - enthalten nur Business Keys eines Typs von Geschäftsobjekt
    (z.B. Kunde, Vertrag, Tarif)
  • Links - verbinden Hubs
    (z.B. ein Kunde schließt einen Vertrag)
  • Satelliten - enthalten ergänzende Daten zu Hubs
    (z.B. Vertragsart, Anfangsdatum, Vertragsdauer)
In diesen Tabellen werden die Daten weitestgehend so abgelegt, wie sie aus den Quellen kommen - inklusive aller Änderungen über die Zeit. Erst beim Beladen der obersten Schicht, des dimensionalen Data Warehouse, kommen Geschäftsregeln zur Anwendung, welche die Daten interpretieren und in Informationen umwandeln. Beispielsweise wenn zu einem Kunden aus zwei unterschiedlichen Quellen zwei unterschiedliche Adressen geliefert werden, entscheidet eine Geschäftsregel darüber, welche die vertrauenswürdige Quelle ist.

Der Vorteil dieser Trennung offenbart sich spätestens, wenn eine Geschäftsregel sich ändert: Bei der zweistufigen Lösung hat die Interpretation der Daten bereits beim Laden von der Staging Area in das dimensionale DWH stattgefunden. Ändern diese sich, wird es schwierig: oft ist die Historie der Daten nicht oder nur schwer aus der Staging Area zu rekonstruieren. Mit Data Vault ist das Problem wesentlich kleiner, denn im Data Vault liegen die originalen Quelldaten mitsamt ihrer gesamten Historie - das dimensionale DWH kann jederzeit mit neuen Geschäftsregeln neu beladen werden.

Darüber hinaus bietet die standardisierte Tabellenstruktur im Data Vault die Möglichkeit, das Laden der Tabellen weitgehend zu automatisieren. Auch Erweiterungen wie das Hinzufügen neuer Datenquellen und neuer Attribute erfolgen ganz geradlinig, weil die bestehenden Ladeprozeduren nicht modifiziert und auch nicht erneut getestet werden müssen. Kein Wunder, dass agiles Vorgehen in BI Projekten erst mit Data Vault so richtig gut funktioniert.

Brauchen nun alle BI Projekte einen Data Vault?


Data Vault ersetzt also keineswegs das dimensionale Data Warehouse und die Kimball Methodik, sondern fügt der BI Architektur eine weitere Schicht hinzu. Wann lohnt sich dieser zusätzliche Aufwand?

Bei kleinen und mittleren BI Lösungen, die nicht auditiert werden müssen, ist eine zweistufige Architektur oft völlig ausreichend: Eine Staging Area in der ersten Stufe und ein dimensionales Data Warehouse in der zweiten Stufe.

Wird mit Data Vault alles einfacher?


Durch Hinzufügen der Data Vault Schicht wird zunächst einmal der initiale Aufwand größer. Und vor allem braucht das Team Erfahrung und Anleitung bei der Data Vault Modellierung. Nur wenn die Konzepte durchgängig umgesetzt werden, liefert Data Vault die erwarteten Vorteile. Aber mit wachsender Größe eines DWH Projekts und mit jeder Quelle, die im Lauf der Lebensdauer einer BI Lösung hinzukommt, treten auch die Vorteile stärker in den Vordergrund.

Die Antwort auf die Frage ist also, wie so oft, ein qualifiziertes "Ja, aber". Mein Vorschlag: Machen Sie sich mit dem Thema vertraut, zum Beispiel über die unten aufgeführten Links. Ein DWH Architekt sollte auf jeden Fall Data Vault in seinem Methodenkoffer haben um das in der jeweiligen Situation am besten Passende daraus anzuwenden. Jetzt ist ein perfekter Zeitpunkt sich ernsthaft mit diesem Thema auseinanderzusetzen, denn in seinem gerade erschienen Buch "Building a Scalable Data Warehouse with Data Vault 2.0" stellt Dan Linstedt seine umfassende Methodik und eine ausgereifte Modellierungstechnik anhand vieler Beispiele vor. Alle BI Spezialisten, die wie ich den Microsoft SQL Server als Schwerpunkt haben, wird es freuen, dass viele Beispiele in diesem Buch mit SSIS und T-SQL umgesetzt sind.

Dan Linstedts Blog
Roelant Vos Blog
datavaultmodeling.de

Happy vaulting!


Mittwoch, 3. Juni 2015

Self-Service BI - eine Aufgabe für die IT Abteilung

Frage: Was müssen Sie tun, um Self-Service BI im Unternehmen zu einem Misserfolg zu machen?
Antwort: Überlassen Sie dieses Thema den Endanwendern

Mit Produkten wie PowerPivot, Power Query, Power View, SharePoint und Report Builder bietet Microsoft eine ganze Palette von Werkzeugen an, die den Fachabteilungen mehr Flexibilität und Unabhängigkeit von IT Spezialisten geben sollen. Im Rahmen meiner Arbeit habe ich nun schon mehrere Unternehmen erlebt, die diese Möglichkeiten einsetzen. Einige Initiativen waren sehr erfolgreich, andere sind weitgehend gescheitert.

Warum Self-Service BI ohne die IT Spezialisten nicht funktioniert

Der größte Irrtum in Bezug auf Self-Service BI ist, dass die Fachanwender nun auf einmal die Arbeit der IT Abteilung übernehmen könnten. Dies ist übrigens auch eine gelegentlich geäußerte Befürchtung von IT Spezialisten - ob sie denn nun arbeitslos werden, weil ihre Kenntnisse nicht mehr benötigt werden.

Das Gegenteil ist der Fall.

Aus den Augen der Fachanwender betrachtet ist das Versprechen der neuen Werkzeuge, nämlich mit ihren "eigenen Leuten" den Bedarf an Reporting und Datenanalyse abzudecken, die Befreiung von vielen lästigen Restriktionen der Unternehmens-IT:
  • fehlende Daten
  • langwierige, aufwändige Prozesse bis neue Daten in Reports erscheinen
  • unflexible Lösungen, die am tatsächlichen Bedarf vorbei gehen
  • hohe Kosten
Verlockende Aussichten. Ein Heer von Vertriebsleuten schürt diese Vision.

So kommt es, dass eine "ganz normale" Mitarbeiterin in einer Fachabteilung zunächst Rechnungs-Informationen in einer Excel Datei zusammenstellt, darauf ein PowerPivot Modell baut und erste Erfolge publiziert. Hoch motiviert bindet sie eine weitere Datenquelle ein, sagen wir eine CSV-Datei mit SAP Daten. Und eine weitere, nun eine Datenbank mit Abrechnungsinformationen. Hier unterstützt ein Access-erfahrener Kollege. Beide zusammen polieren das PowerPivot Modell auf, fügen ein paar DAX Ausdrücke hinzu und publizieren das Ergebnis in SharePoint. Ein großer Erfolg! Die Abteilung hat ihr eigenes Abrechnungs-Reporting unabhängig von der geschmähten IT Abteilung hinbekommen.

Noch etwas warten, dann ist der Punkt erreicht, wo ich für gewöhnlich ins Spiel komme. Denn im nächsten, spätestens im übernächsten Monat sind die selbst gebauten Reports nicht mehr so ganz korrekt. Unbeherrschbare DAX Ausdrücke, Fehler nach dem Aktualisieren der Daten, nur halb funktionierende Kennzahlen. Jetzt beginnt die eigentliche Arbeit: Fragen nach den Datenquellen, Aufräumen des PowerPivot Modells, Konsolidieren der Daten.

Was ist hier schief gelaufen?

Eigentlich haben die Anwender alles richtig gemacht. Nur haben sie die Komplexität der Aufgabe unterschätzt. Solange der überwiegende Anteil der Daten für ein PowerPivot Modell aus einer Datenbank kommt, ist alles überschaubar. Aber die Informationen aus Textdateien oder Excel Dateien abzurufen, aufzubereiten und mit den anderen Datenquellen zu harmonisieren, das wird mit jeder zusätzlichen Datei um ein Vielfaches aufwändiger. Die Fachabteilung findet sich auf einmal in der Modellierung von ETL-Prozessen wieder - etwas, worauf sie nicht vorbereitet waren und wofür sie auch keine Methodik kennen.

Die richtige Mischung macht's

Wir IT Spezialisten sehen solche Aufgabenstellungen mit anderen Augen. Datenmodellierung, ETL und Datenqualität sind dank Ralph Kimball bestens erschlossene Gebiete. Aber wir haben ja nun auch viel Zeit in unsere Ausbildung und in die Umsetzung der best practices investiert. Die Fallstricke der Modellierung und das erforderliche akribische Vorgehen beim Extrahieren und Laden von Daten in ein Data Warehouse haben wir in hunderten Stunden Projektarbeit kennengelernt. Das sind Aufgaben, die eine genaue Klärung, eine routinierte Umsetzung und geplante Tests erfordern. Nichts, was man "nebenbei" erledigen könnte. Der Lohn der Arbeit sind stabile, automatisch ablaufende Daten-Aktualisierungen und eine hohe Datenqualität.

Wenn wir den Fachabteilungen solche Datenquellen liefern, dann können sie diese tatsächlich einfach verwenden, um darauf ihr eigenes Reporting und ihre eigenen Analysen aufzusetzen. Dann können sie die Berichte schnell so gestalten, wie es ihren Bedürfnissen am besten entspricht. Und sie können sich auf die Zahlen verlassen. In so einer Umgebung ist es auch einfach, noch die eine oder andere Information aus einer zusätzlichen Datei oder aus dem Internet hinzuzufügen.

Um es ganz deutlich zu sagen: Dies ist ein Plädoyer für das klassische Data Warehouse! Das Data Warehouse stellt hoch qualitative Daten bereit, so dass Fachanwender einfach darauf zugreifen und sie nach Herzenslust miteinander verknüpfen können. Gerade in Zeiten von Self-Service BI kommt dieser Vorteil so richtig zum Tragen.

Was Self-Service BI tatsächlich leisten kann

Die erfolgreichen Self-Service BI Initiativen, die ich kennenlernen durfte, zeichnen sich alle durch ein Merkmal aus: Entscheidungsträger aus dem obersten Management wollten, unterstützten und überwachten die Maßnahmen.
Die nicht erfolgreichen Initiativen waren allesamt dadurch gekennzeichnet, dass sie entweder ausschließlich technisch betrachtet wurden ("mit den richtigen Tools kommt der Erfolg von selbst") oder dass sie nur von wenigen Personen getragen wurden ("was interessiert mich dieser neumodische Kram").

Die positiven Effekte für die Fachanwender wie Flexibilität, Geschwindigkeit und passgenaue Lösungen können sich nur dann einstellen, wenn diese Bedingungen gegeben sind:
  1. die Self-Service BI Initiative hat die volle Unterstützung durch das oberste Management
  2. die Ziele der Initiative sind allen Betroffenen klar
  3. der Erfolg oder Misserfolg wird durch das oberste Management engagiert überwacht
  4. die Fachanwender haben Zugriff auf ein hervorragend gepflegtes Data Warehouse (das ist mit Abstand der kostenintensivste Teil)
  5. die Fachanwender haben im Rahmen von Schulungen ihre neuen Werkzeuge gründlich kennengelernt
  6. die Fachanwender erhalten Unterstützung durch Mitarbeiter, die sowohl die Self-Service Tools bestens kennen als auch mit der IT Landschaft vertraut sind. Anwenderunterstützung, End User Computing, Daten Analysten, Business Analysten - wie auch immer die Rollenbezeichnung lautet - Menschen mit solidem und umfangreichem IT Hintergrundwissen aber auch mit einem Verständnis für die Anforderungen der Fachabteilungen schlagen Brücken. Sie unterstützen die Anwender beim Auffinden der für sie besten Datenquellen, bei komplexeren SQL Statements, bei ausgefeilten DAX Ausdrücken und sie erkennen vor allem, wann die Grenzen der Self-Service Tools erreicht sind und wann eine professionelle ETL Lösung erforderlich ist.
Wenn diese Voraussetzungen gegeben sind, dann entfalten die anfangs aufgezählten Tools eine belebende Wirkung. Dann erstellen pfiffige Mitarbeiter in den Fachbereichen auf einmal neuartige Reports und Analysen, die ein Unternehmen effizienter, profitabler, schneller und kundenfreundlicher machen können. Dann lösen sie das Versprechen von Self-Service BI ein. An jede dieser Lösungen, die ich unterstützen durfte, denke ich mit großer Begeisterung zurück.

Wenn das Management und die IT die richtigen Rahmenbedingen schaffen, dann ermöglichen sie die Erfolgsgeschichte von Self-Service BI. Arbeiten wir daran!

Dienstag, 31. März 2015

Liste der SQL Server Fehlercodes

Eine Liste der Fehlercodes, die der SQL Server ausgeben kann, findet sich in der Dokumentation. Wenn Sie jedoch gerade keinen Zugriff aufs Internet haben, können Sie auch den SQL Server direkt fragen:

select * from sys.messages

Das ist sehr praktisch, wenn Sie einen Fehlercode  haben und den vollständigen Text der Fehlermeldung nachschlagen möchten. Oder wenn Sie die deutsche Fehlermeldung kennen und den englischen Text wissen möchten um ihn zum Beispiel in einer Suchmaschine einzugeben. Das ist möglich, weil die Tabelle sys.messages alle Fehlermeldungen in 22 verschiedenen Sprachen enthält.


Tabelle sys.messages enthält jede Fehlermeldung in verschiedenen Sprachen
Welche language_id zu welcher Sprache gehört, können Sie in einer anderen Systemtabelle nachschlagen:

select *
from sys.syslanguages


In der Spalte msglangid dieser Tabelle finden Sie den zu language_id korrespondierenden Wert. In welcher Sprache Sie die Fehlermeldungen sehen, hängt von den Ländereinstellungen auf dem Betriebssystem des Clients ab, der die Verbindung zum SQL Server aufgebaut hat. Wenn Sie die Sprache für eine Verbindung umstellen möchten, können Sie das mit diesem Befehl machen:

SET LANGUAGE FRENCH; 

Mehr zur SET LANGUAGE Anweisung finden Sie in der MSDN.

Sonntag, 1. März 2015

SQL Server Migration Assistant (SSMA) und die Sortierreihenfolge der Datenbanken

Bei der Migration einer größeren Oracle Datenbank nach MS SQL Server haben wir den SQL Server Migration Assistant (SSMA) for Oracle in der Version 6 eingesetzt. Wirklich ein sehr hilfreiches Tool!

Laufzeitprobleme nach Umzug der Datenbank


Ein größeres Problem trat auf, nachdem wir die migrierte SQL Server Datenbank gesichert und auf einer anderen SQL Server Instanz wiederhergestellt hatten. Beim Ausführen von gespeicherten Prozeduren, die der SSMA generiert hatte, gab es auf einmal diesen Laufzeitfehler:

Msg 217, Level 16, State 1, Line 1
Maximum stored procedure, function, trigger, or view nesting level exceeded (limit 32).

Auf dem alten SQL Server funktionierten dieselben Funktionsaufrufe weiterhin fehlerfrei. Die Ursache musste also irgend etwas mit dem neuen Server zu tun haben.

Sortierreihenfolge als Fehlerursache


Um es kurz zu machen: Die Sortierreihenfolge der neuen SQL Server Instanz (Server Collation) war eine andere als auf dem alten Server. Dadurch hatte auch die Systemdatenbank master eine andere Sortierreihenfolge (Database Collation) als die auf dem alten Server. Erst einmal ist nicht ersichtlich, warum das zu Problemen führen könnte. Der Hintergrund ist Folgender: In der master Datenbank werden durch das SSMA Extension Pack drei Extended Stored Procedures installiert. Der vom SSMA generierte T-SQL Code verwendet Kompatibilitätsfunktionen (das sind die im Schema ssma_oracle), welche ihrerseits wiederum diese Extended Stored Procedures in master aufrufen.

Wenn die master Datenbank und die Benutzerdatenbank mit vom SSMA generierten T-SQL Code unterschiedliche Sortierreihenfolgen aufweisen, dann tritt reproduzierbar dieser Fehler auf.

Das Aufspüren dieser Fehlerursache hat unser Team viel Zeit gekostet. Vielleicht hilft diese Erläuterung ja jemandem, der ebenfalls auf dieses etwas exotische Problem stößt. Wir haben es übrigens beseitigt, indem wir die Sortierreihenfolge der Benutzerdatenbank umgestellt haben. Das ist einen weiteren Blog-Post wert, den ich in den nächsten Tagen schreiben werde.

Samstag, 28. Februar 2015

SSMS: Mit Suchen und Ersetzen Zeilenumbrüche einfügen

Oft wäre es nützlich, im SQL Editor von SQL Server Management Studio mit Suchen und Ersetzen auch Sonderzeichen wie "neue Zeile" einfügen zu können. Beispielsweise um vor jedem "CREATE" Statement noch ein "GO" einzufügen, denn nach "GO" muss immer eine neue Zeile beginnen.
Auf dem direkten Weg ist es nicht möglich Sonderzeichen einzugeben. Doch durch die Verwendung regulärer Ausdrücke eröffnen Sie sich diese und noch eine ganze Palette weiterer Möglichkeiten.

Reguläre Ausdrücke sind der Schlüssel


Die im Bild dargestellte Option "Use - Regular expressions" interpretiert die Zeichenfolgen in den Eingabefeldern "Find what" und "Replace with" unter Berücksichtigung der Regeln für reguläre Ausdrücke.

Mit regulären Ausdrücken wird das Suchen und Ersetzen erheblich leistungsfähiger
Weil in regulären Ausdrücken die Zeichenfolge "\n" die Bedeutung "neue Zeile" hat, fügt das im Bild dargestellte Beispiel vor jedem "CREATE" ein "GO" und eine neue Zeile ein.

Vor allem aber können Sie reguläre Ausdrücke bei der Suche von Mustern im Text verwenden, indem Sie diese im Eingabefeld "Find what:" eingeben. Gerade erst musste ich in einem sehr langen SQL Skript alle Funktionsaufrufe finden, denen kein Schemaname vorangestellt war. Da die Funktionsnamen alle mit "fn_" begannen, konnte ich die betreffenden Stellen im Text mit diesem Ausdruck in "Find what:" schnell finden:
[^.]fn_  Dieser reguläre Ausdruck liefert alle Stellen, wo vor fn_ kein Punkt steht. Ist diese Hürde erst einmal genommen, ist es ein Leichtes, mit Suchen und Ersetzten an diesen Stellen noch den Schemanamen hinzuzufügen. In meinem Fall dauerte das für ca. 400 Ersetzungen nur wenige Sekunden.

Eine vollständige Dokumentation regulärer Ausdrücke finden Sie zum Beispiel in der MSDN oder in diesem Wikipedia Artikel.

Noch ein Tipp: Gerade wenn das gesuchte Muster an sehr vielen Stellen im Text vorkommt, dann ist die Option "Find in Files" eine großartige Hilfe. Sie erreichen diese Funktion hier:

Find in Files erstellt eine Liste mit allen Stellen, wo der Suchausdruck gefunden wurde

Fazit: Der Texteditor im Management Studio bietet viele leistungsstarke Funktionen für das Suchen und Ersetzen in Texten. Man muss nur genau hinsehen um sie zu finden.

Sonntag, 15. Februar 2015

Zahl der zertifizierten Business Analysten wächst weiter

Auch im Jahr 2014 ist die Zahl der nach den Anforderungen der IIBA zertifizierten Business Analysten weiter stark gewachsen. Die Grafik zeigt das eindrucksvoll:

Auch 2014 ist die Zahl der zertifizierten Business Analysten stark gewachsen

CBAP: Certified Business Analysis Professional
CCBA: Certified Competency in Business Analysis

In Deutschland ist die Zahl auf 33 CBAP und 2 CCBA angewachsen, zeigt aber im europäischen Vergleich z.B. gegenüber England, Italien und der Schweiz immer noch einen deutlichen Nachholbedarf. Es fällt auch auf, dass inzwischen die Anzahl der CCBA, das sind jüngere Business Analysten, die noch nicht über so viel Berufserfahrung verfügen wie CBAP, deutlich gestiegen ist. Damit gewinnt dieses Zertifikat weitere Anerkennung. Das entspricht meiner Wahrnehmung, dass die Rolle des Business Analysten als Partner des Projektmanagers und als Garant für den Projekterfolg in Bezug auf die Qualität immer bekannter wird. Nicht zuletzt deswegen, weil Projekte, in denen ein qualifizierter Business Analyst mitwirkt, in aller Regel zuverlässiger und mit besserem Erfolg abgeschlossen werden.

Zumindest sind das die Erfahrungen, die ich in meinem beruflichen Umfeld "Business Intelligence" mache. Gerade in BI Projekten, die naturgemäß komplex sind und viele Beteiligte haben, kommen bei Fehlplanungen schnell fünf- und sechsstellige zusätzliche Beträge zusammen, die sich durch die Arbeit eines Business Analysten hätten vermeiden lassen. Das liegt auch daran, dass der Business Analyst wie die IIBA ihn definiert, viel mehr leistet, als lediglich die Anforderungen (Requirements) aufzunehmen, qualitativ hochwertig zu machen und systematisch die Änderungen von Anforderungen zu klären und genehmigen zu lassen. Der Business Analyst stellt darüber hinaus auch zum Beispiel Fragen in Bezug auf die Versionierung einer Lösung (in welchen Schritten wird die Lösung bereitgestellt), die erforderlichen Änderungen bei den Fachanwendern (Schulung, Änderungen bestehender Abläufe, Konvertierung von Daten) und vor allem immer wieder nach dem Wert, den eine neue Lösung (oder ihre Teile) dem Unternehmen liefert. So trägt der Business Analyst entscheidend dazu bei, dass das Projekt auf Kurs bleibt und dass das eingesetzte Geld den größtmöglichen Nutzen für den Auftraggeber bringt. Das sich daraus ergebende positive Arbeitsklima ist ein weiterer angenehmer Nebeneffekt für alle Beteiligten.

Nun bin ich gespannt, was das Jahr 2015 der Business-Analysten Gemeinde bringt und wann wir die Marke von 10.000 CBAPs und CCBAs "knacken" werden.

Quelle: IIBA

Sonntag, 11. Januar 2015

Mit ReportItems auf Inhalte in Tablix-Zellen zugreifen

In etwas anspruchsvolleren Berichten benötigen Sie gelegentlich die Möglichkeit, den Inhalt der Zelle in einer Tabelle oder Matrix an anderer Stelle noch einmal zu verwenden. Das ist durchaus möglich aber nicht ganz offensichtlich.

Ein einfaches Beispiel

Im vorliegenden Beispiel sehen Sie zwei Tabellen, in denen die Umsätze unterschiedlicher Länder dargestellt werden. Der Bericht soll nun noch um ein Textfeld erweitert werden, das die Summe der beiden "Total" Zellen berechnet.


Das Textfeld rechts unten zeigt die Summe der "Total"-Zellen der beiden Tabellen an

Um das zu erreichen, ist es nützlich den beiden Tabellenzellen erst einmal sprechende Namen zu geben. Exakter ausgedrückt: Eine Tabelle (Tablix) in SSRS besteht aus TextBoxen. Diejenigen TextBoxen in den Tabellen, welche den "Total" Wert enthalten, bekommen die Namen "SummeTablix1" und "SummeTablix2". Das folgende Bild zeigt dies deutlicher.


Der Name dieser TextBox wird geändert nach "SummeTablix1"
Nach dieser Vorbereitung kann die neue TextBox rechts unten im Bericht hinzugefügt werden. Der folgende Ausdruck leistet das Gewünschte: 

 =ReportItems!SummeTablix1.Value + ReportItems!SummeTablix2.Value

Die hier verwendete ReportItems Collection enthält alle TextBoxen einer Berichtsdatei. Allerdings ist sie an der grafischen Oberfläche nicht sichtbar. Sie müssen einfach wissen, dass es diese Collection gibt und dann können Sie diese in einer Expression eintippen. Lassen Sie sich nicht irritieren - erst nachdem Sie das Ausrufezeichen nach dem Wort "ReportItems" eingegeben haben, erscheint die Drop-Down Liste als Eingabeunterstützung und bietet Ihnen die Namen aller TextBoxen in diesem Bericht zur Auswahl an. Dies ist der Punkt, wo sich die sprechenden Namen der betreffenden TextBoxen als nützlich erweisen.

Erst nach Eingabe des Ausrufezeichens hinter dem Wort ReportItems nimmt die Eingabehilfe ihre Arbeit auf

Wenn sie diese Hürde genommen haben, ist es ein Leichtes den Ausdruck vollständig einzugeben.

Noch ein Beispiel

Sie möchten in einer Tabelle Verhältniszahlen berechnen? Mit ReportItems ist das kein Problem mehr. Nehmen wir folgende Anforderung als Beispiel: Neben dem Umsatz eines Jahres soll sein prozentualer Anteil am Umsatz aller Jahre angezeigt werden.

Der "Sales Amount" für das Jahr 2005 entspricht 20% des "Sales Amount" über alle Jahre

Der Ausdruck in der Spalte "% Umsatz" ist der Umsatz eines Jahres geteilt durch die Summe des Umsatzes über alle Jahre:

=ReportItems!SalesAmount1.Value / ReportItems!SummeTablix1.Value

ReportItems in Kopf- und Fußzeilen

Noch ein schöner Anwendungsfall ist der Einsatz von ReportItems in Kopf- oder Fußzeilen eines Berichts. Nehmen wir an, in der Kopfzeile soll das erste und das letzte Jahr angezeigt werden, das auf der jeweiligen Seite zu sehen ist. Um das besser demonstrieren zu können, habe ich meinen Beispiel-Bericht so verändert, dass nur noch maximal 3 Jahre auf einer Seite dargestellt werden. (Hierfür habe ich einfach in der Eigenschaft des Berichts "InteractiveSize" die Höhe auf 3 Zentimeter reduziert.)

In der Kopfzeile werden die erste und die letzte Jahreszahl auf dieser Seite angezeigt
Mit Hilfe der Aggregatfunktionen First() und Last() können Sie das erste Jahr und das letzte Jahr in der Spalte "OrderYear" ermitteln. Jedoch gibt es noch eine kleine Hürde zu nehmen. Denn wenn Sie versuchen, einen Ausdruck wie den folgenden zu verwenden, erhalten Sie eine Fehlermeldung:

="Von " & First(ReportItems!OrderYear.Value) & " bis " & Last(ReportItems!OrderYear.Value)

Die Fehlermeldung besagt, dass Sie in Kopf- und Fußzeilen pro Ausdruck jeweils nur ein ReportItem verwenden dürfen.
Zur Lösung könnten Sie zwei nahe nebeneinander gelegene TextBoxen verwenden. Noch eleganter finde ich allerdings die Verwendung von zwei Platzhaltern in derselben TextBox. Jeder Platzhalter wird über einen eigenen Ausdruck mit Inhalt gefüllt.

Eine TextBox kann mehrere Platzhalter enthalten
Der erste Platzhalter enthält diesen Ausdruck:

="Von " & First(ReportItems!OrderYear.Value) & " bis "

Der zweite Platzhalter enthält diesen Ausdruck:

=Last(ReportItems!OrderYear.Value)

Voilá!

Die offizielle Dokumentation

ReportItems sind natürlich auch in der MSDN dokumentiert, wenn auch etwas abstrakt, wie ich finde. Das entsprechende Kapitel in der MSDN enthält hierzu noch einige interessante Anmerkungen über die interne Arbeitsweise von Reporting Services.

Mittwoch, 7. Januar 2015

Auswahl mehrerer Werte im Bericht anzeigen

Reporting Services bietet die Möglichkeit, dass ein Berichtsparameter mehrere Werte enthalten kann. Im folgenden Beispiel ist das eine Liste von Ländern. Dieser Beitrag soll zeigen, wie Sie die Liste der ausgewählten Länder ganz einfach als Text im Bericht anzeigen können (im folgenden Bild grün hinterlegt).

Dieser einfache Bericht zeigt die Umsätze der ausgewählten Länder
 

Das sind die Schritte zur Lösung

Zunächst einmal braucht es einen Berichtsparameter, bei dem die Eigenschaft "allow multiple values" gesetzt ist.

Das hat zur Folge, dass der Parameter dem Anwender in dieser Form angezeigt wird:
 
Um jetzt die ausgewählten Länder im Bericht anzuzeigen, habe ich dem Bericht zwei TextBoxen hinzugefügt: eine mit dem statischen Text "Umsatz für folgende Länder:" und darunter eine TextBox mit einer Expression.


Die Expression nutzt die Funktion Join(). Diese Funktion wandelt den Inhalt eines mehrwertigen Parameters in eine Zeichenkette um. Das zweite Argument dieser Funktion gibt an, durch welche Zeichen die einzelnen Parameterwerte getrennt werden sollen.

Join(Parameters!pCountries.Value, ", ")

Eine Dokumentation der Join() Funktion sowie viele weitere nützliche Informationen über die Verwendung von Berichtsparametern in Expressions finden Sie hier in der MSDN.

Dienstag, 6. Januar 2015

Spaltenüberschriften auf jeder Seite wiederholen

Es ist eine typische Anforderung an einen Bericht, dass die Spaltenüberschriften einer langen Tabelle sich auf jeder Seite wiederholen. Dafür bietet Reporting Services eine scheinbar einfach zu verwendende Eigenschaft, die nach einem Rechtsklick auf die Tabelle und Auswahl von "Tablix Properties" zu sehen ist. Sie heißt "Column Headers" und bietet zwei Checkboxen. Die erste dient zum Wiederholen der Spaltenüberschriften auf jeder Seite und die zweite blendet die Spaltenüberschriften auch dann am oberen Bildrand ein, wenn Sie eine lange Seite im Browser herunterscrollen.

Diese Option hat bei Tabellen keine Auswirkung
Allerdings hat diese Eigenschaft bei Tabellen einen entscheidenden Nachteil: Sie funktioniert nicht. Die Spaltenüberschriften werden NICHT wiederholt, unabhängig davon, ob Sie den Haken setzen oder nicht.

Mit einer Matrix geht's

So ganz wirkungslos sind diese Checkboxen allerdings nicht. Wenn Sie mit einer Matrix anstelle einer Tabelle arbeiten, dann werden die Spaltenüberschriften sehr wohl wiederholt.


Bei einer Matrix werden die Spaltenüberschriften wiederholt
 
Was ist hier anders? Die Matrix zeichnet sich ja dadurch aus, dass die Anzahl der Spalten von den Daten im Dataset bestimmt wird. Im Beispiel gibt es Daten für die Jahre 2005 bis 2008. Gäbe es darüber hinaus noch Daten für das Jahr 2009, würde der Matrix automatisch eine entsprechende Spalte hinzugefügt. Man könnte auch sagen, dass bei der Matrix die Spalten dynamisch sind. Die Eigenschaft "Repeat header columns on each page" bezieht sich also auf dynamische Spalten.

Die Lösung für Tabellen

In einer Tabelle hingegen sind die Spalten statisch. Zur Entwurfszeit legen Sie fest, welche Spalten der Tabelle im Bericht angezeigt werden sollen. Und für statische Spalten gilt die Eigenschaft "Repeat header columns on each page" eben nicht.
Die Lösung für statische Spalten ist leider nicht so einfach, aber dafür zeigt sie uns tiefer liegende Eigenarten von Reporting Services. Es wird also spannend.
Schauen wir uns zunächst das Problem genauer an. Dazu habe ich einen Bericht erstellt, der eine Tabelle mit Umsatzzahlen pro Monat darstellt. Jedes Jahr beginnt auf einer neuen Seite. Die statischen Spaltenüberschriften (Order Year, Order Month und Sales Amount) werden auf der ersten Seite angezeigt, aber auf den Folgeseiten nicht mehr.
 
Bei einer Tabelle werden die statischen Spaltenüberschriften nicht wiederholt
 
Um die Eigenschaften der statischen Spaltenüberschriften zu sehen, brauchen Sie das wohl am besten versteckte Bedienelement der Visual Studio Oberfläche: rechts unten, im Bereich der Gruppenkonfiguration, finden Sie bei genauem Hinsehen einen kleinen Pfeil.
Dieser unscheinbare Pfeil (rot umrandet) ist der Schlüssel zur Lösung
Nach Klicken auf den Pfeil können Sie den "Advanced Mode" einschalten. Diese Betriebsart stellt in den beiden Fenstern der Gruppenkonfiguration (Row Groups und Column Groups) auch die statischen Elemente dar.

Nach Anklicken eines "Static" Eintrags wird das entsprechende Feld in der Tabelle dick umrandet
Was Sie jetzt noch brauchen, ist nach dem Anklicken des ersten "Static" Elements in der Row Group das "Eigenschaften" Fenster, um die Eigenschaften dieses statischen Elements zu sehen. Falls das Fenster nicht schon in Visual Studio angezeigt wird, können Sie es über den Menüpunkt "Ansicht" - "Eigenschaftenfenster" oder mit der Taste [F4] einblenden. Wenn Sie die Eigenschaft "KeepWithGroup" auf "After" einstellen und die Eigenschaft "RepeatOnNewPage" auf "True", dann erreichen Sie den gewünschten Effekt.

Die Eigenschaften KeepWithGroup und RepeatOnNewPage der statischen Spaltenüberschrift führen zur Lösung
Interessanterweise funktioniert das nur dann, wenn Sie diese Einstellung bei der ersten statischen Spaltenüberschrift durchführen.

Spaltenüberschriften beim Scrollen immer anzeigen

Am Anfang dieses Beitrags hatte ich noch eine weitere Eigenschaft erwähnt, die bei dynamischen Spaltenüberschriften möglich ist: "Keep header visible while scrolling". Auch bei statischen Überschriften können Sie das konfigurieren, allerdings heißt die entsprechende Eigenschaft im Eigenschaften-Fenster "FixedData".

Die (gelb hinterlegten) Spaltenüberschriften bleiben auch beim Scrollen am oberen Bildrand sichtbar
Übrigens finden Sie eine Beschreibung dieses Verhaltens auch in der MSDN Dokumentation. Allerdings in einer Form, die für mich nicht so offensichtlich war. Ich musste mich einige Zeit mit diesem Thema beschäftigen, bevor mir die Hintergründe klar wurden. Von daher hoffe ich, dass dieser Beitrag Ihnen das Arbeiten mit statischen Spaltenüberschriften in Reporting Services etwas einfacher macht.