SSRS-Berichts-Generator - Probleme aus Erfahrung?

Question

Ich denke über die Idee nach, den webbasierten SSRS Report Builder unseren Endbenutzern zur Verfügung zu stellen, damit sie ihre eigenen Berichte mit unseren Produktionsanwendungsdatenbanken erstellen können. Von dem, was ich bisher gesehen habe, ist dieses Tool einfacher zu benutzen als der VS Biz Intel Studio Reportdesigner, außerdem ist es einfacher zu installieren und die Bereitstellung der Berichte ist für einen Endbenutzer viel verständlicher (plus das größte Ding ist kein SQL Ich vermute).

Hat jemand irgendwelche Gedanken oder Erfahrungen zu den Fallstricken, die den Benutzern diese Art von Macht verleihen? Im Moment erhalten wir viele Anfragen, die Daten in eine flache Datei zu exportieren, damit sie sie einlesen und dann Berichte in Access erstellen können. Ich denke, SSRS wäre besser als Access ...

Answer 1

Einige Tipps für Berichtsmodellentwurf:

1. Erstellen Sie ein Data-Mart

Es gibt verschiedene Tools wie Berichts-Generator: Business Objects, Oracle Discoverer ein paar zu nennen. Sie alle verfügen über Metadaten-Layer, die Ihnen den Weg zu einem Reporting-Tool für Endbenutzer weisen. Dennoch müssen sie wirklich in einem geeigneten Format mit Daten gespoolt werden, um eine effektive Lösung zu erstellen. Dies bedeutet, dass Sie in Bezug auf den Aufbau einer Art von Data-Mart auch wirklich denken müssen.

Ohne saubere Daten werden die Tools alle Fehler in der Produktionsdatenbank offenlegen, so dass Benutzer diese verstehen müssen, um korrekte Ergebnisse zu erhalten. Dies bedeutet, dass die Berichterstattung wirklich von einer sauberen Datenquelle ausgehen sollte.

Sie haben ungefähr keine Kontrolle über die SQL, die diese Tools produzieren, so dass sie durchaus in der Lage sind, Abfragen zu erzeugen, die Ihre Produktionsdatenbank herniate. Dies bedeutet, dass Ihre Berichterstattung auf einem separaten Server stattfinden sollte. Ein Schema, das für Ad-hoc-Tools (z. B. ein Sternschema) geeignet ist, mindert die schlimmsten potenziellen Probleme mit der Leistung.

2. Reinigen Sie die Daten

Es gibt kein Entwickler in der Schleife mit Ad-hoc-Tools, so dass die Nutzer naiv das Tool verwenden, ohne zu wissen, was die Datenprobleme sind. Ungenaue Abfrageergebnisse werden immer als Fehler des Tools angesehen. Aus Gründen der Glaubwürdigkeit müssen diese Fallstricke aus dem Datensatz vor dem Tool entfernt werden.

3. Machen Sie die Navigation robust und idiotensicher

Bericht Builder Einschränkungen einrichten können von einem Unternehmen zum anderen auf zu bewegen. Ohne diese ist es möglich, mehrere Tabellen in einer m: m-Beziehung miteinander zu verbinden. Dies wird Fan Trap genannt und gibt falsche Summen zurück. Sie müssen das Modell so einrichten, dass einzelne Faktentabellen auf gemeinsamen Dimensionen aggregiert werden - d. H. Zusammengerollt, bevor sie verbunden werden. Wenn Sie dies richtig machen, wird eine Klasse von Fehlern eliminiert. Die meisten Werkzeuge haben einen Mechanismus, um dies zu verhindern.

4. die Daten aggregieren Stellen

Sie dies für von Business Objects frei bekommen, aber Sie werden ein aggregiertes Maß über jede Basismaßnahme explizit mit Berichts-Generator setzen müssen. Blenden Sie die Basiswerte aus und setzen Sie die Aggregate frei. Dies bedeutet, dass das System die Daten auf die vom Benutzer ausgewählten Dimensionen aufrichtet.

Fazit

ein Ad-hoc-Tool direkt über eine Produktionsdatenbank zu setzen ist nicht wahrscheinlich, gut zu funktionieren. Die Daten haben zu viele Fallstricke und das Schema eignet sich nicht für die Berichterstattung. Das bedeutet, dass Sie sich für einen Data Mart aufmachen müssen, um die Daten zu scrubben und für das Tool vorzubereiten. Wenn Sie viel Zeit für die Erstellung von Ad-hoc-Auszügen aufwenden, kann es in der Entwicklerzeit zu einem Geschäftsfall kommen, der später eingespart werden könnte.

EDIT: Der Report Model Wizard (wie die meisten solchen Dinge) macht ziemlich viel Chaos, wenn Sie ausgeführt werden. Sie müssen die Einstellungen optimieren, z. B. die Generierung irrelevanter Aggregate einschränken. In der Vergangenheit hatte ich recht gute Ergebnisse, indem ich Summen generierte, alle Basiswerte verdeckte und die Aggregate so ausstellte, als wären sie Basiswerte. Dies gab Verhalten wie Business Objects. In bestimmten Fällen möchten Sie vielleicht auch zählen, min/max oder Durchschnittswerte.

Die bestimmte Instanz, an die ich denke, war ein ziemlich großes Berichtsmodell mit etwa 1500 Feldern, so dass das vom Assistenten generierte Aggregatfest mit über 10.000 Feldern insgesamt nicht bewältigt werden konnte. Sie können Ordnerstrukturen ähnlich wie Analysis Services einrichten und diese zum Organisieren der Felder verwenden. Wenn Sie die Beschreibung in das Feld eingeben, wird sie schließlich als Tooltip angezeigt, wenn Sie im Endbenutzerwerkzeug darüber fahren.

Answer 2

Nur ein paar Kommentare zu der vorherige Antwort:
1. Das semantische Abfrage Modell des SQL Server Reporting Services Report Builder wurde mit der ausdrücklichen Absicht entwickelt, zu verhindern, Fan Traps/falsche Summen auf m: m Beziehungen. Es ist kein zusätzlicher Aufwand erforderlich, um diese Funktionalität zu aktivieren. Dies ist in der Struktur der Abfragen enthalten, die vom Berichts-Generator generiert werden.
2. Der Modellassistent erstellt standardmäßig aggregierte Kennzahlen für numerische Felder, sodass keine zusätzlichen Anstrengungen zum Aufdecken von Aggregaten erforderlich sind. Sie können das Modell anpassen, indem Sie je nach Bedarf Aggregationsberechnungen hinzufügen oder entfernen.

Insgesamt gilt das alte Sprichwort "Müll in Müll raus". Wenn Ihre Daten nicht sauber sind, wird dies durch Report Builder oder andere Ad-hoc-Berichterstellungstools deutlicher.

Aaron Meyers
Ingenieur Software-Entwicklung, SQL Server Reporting Services