Datenbankabstraktion in einer Berichtsanwendung

Question

Ist es möglich, in einer Berichtsanwendung die Berichtslogik und die Details des Datenbankschemas zu abstrahieren?

Ich habe eine Reporting Services-Anwendung mit einer recht komplexen Berichtslogik. Ich versuche, die Anwendung auf einige andere Datenbanken zu migrieren. (Datenbanken, die für denselben Zweck gebaut, aber von verschiedenen Softwarehäusern entwickelt wurden. )

Ist es eine kluge Entscheidung, eine Webservices/WCF-Schicht in der Mitte zu verwenden? Welche anderen Optionen können in Betracht gezogen werden?

Answer 1

Es wäre schwierig, so etwas in einem allgemeinen Fall zu tun, aber Sie könnten es mit einer dieser Methoden versuchen:

• Erstellen Sie einige Ansichten über das Datenbankschema und schreiben die Berichtsspracs gegen diese. Dies bedeutet, dass Sie eine gewisse Flexibilität im zugrunde liegenden Datenbankschema haben und die Ansichten als Abstraktionsschicht verwenden können.

• Aufbau einer Art von Data Warehouse Plattform und schreiben Sie einen ETL-Prozess, um sie aus den verschiedenen Datenquellen zu befüllen. Dies ist zwar flexibler, aber auch aufwändiger und funktioniert nur bei einer regelmäßigen Aktualisierung. Wenn dieses Maß an Latenz für Ihre Anwendung akzeptabel ist, würde ich vorschlagen, dass das Data-Warehouse-System der bessere Ansatz ist.

  Der Hauptvorteil eines Data Warehouse besteht darin, dass es für die Berichterstattung optimiert ist und über eine einheitliche Schnittstelle für alle Datenquellen verfügt - Sie konsolidieren sie in einer einzigen Datenbank mit einem einzigen Schema. Die Berichte werden anhand dieses Schemas entwickelt. Das Hinzufügen neuer Systeme erfolgt durch das Schreiben eines ETL-Prozesses zum Auffüllen des Data Warehouse; die Berichte funktionieren unabhängig von der Datenquelle weiter.

WCF ist ein Netzwerkkommunikationssystem. Sie werden feststellen, dass es schwierig ist, mit dieser Art von Architektur große Datenmengen auf Transaktionsbasis zu verarbeiten - ein ETL-Prozess mit Stapelverarbeitung wäre viel effizienter. Wenn Sie jedoch einen Echtzeit-Feed benötigen (z. B. für ein Handelssystem), könnten Sie dies mit einer ähnlichen Lösung erreichen.

Wenn Sie eine Einspeisung mit geringer Latenz benötigen, wäre ein anderer Ansatz, eine Art von Tooling zu untersuchen, das Integration von Unternehmensinformationen . Das vielleicht am weitesten verbreitete Tool, das dies leisten kann, ist ein Ansicht der Datenquelle en SSIS was Ihnen eine gewisse Flexibilität bei der Zuordnung beliebiger Datenquellen zu einem konsistenten Schema bietet. Es ist nicht so ausgereift wie die besten EII-Tools, aber Sie können SSIS-Pakete darauf aufsetzen und diese als Datenquelle für Ihre Berichte verwenden, wenn Sie die Daten weiter transformieren müssen.

Allerdings habe ich noch nie ein so strukturiertes System aufgebaut, so dass ich mich nicht wirklich dafür verbürgen kann, wie gut es in der Praxis funktioniert. Ich würde vermuten, dass es ziemlich anfällig und schwer in Teile zu zerlegen ist, die in Einheiten getestet werden können, so dass Entwicklung und Wartung für ein System von nicht-trivialer Komplexität ziemlich zeitaufwändig sein werden.

Wenn Sie sich über andere EII-Systeme auf dem Markt informieren möchten Dieser Link ist ein Verzeichnis verschiedener Artikel über EII und einige andere Anbieter von EII-Werkzeugen.

Answer 2

Ich stimme dem Vorschlag von NXC für ein Data Warehouse zu:

• Wenn es sich um einen einmaligen Auftrag handelt, nein, aber da es sich um eine "Berichtsanwendung" handelt, ist es sehr wahrscheinlich, dass viele Ihrer Berichte in das OLAP-Paradigma passen.
• Das ist natürlich eine machbare Aufgabe, denn es gibt viele erfolgreiche OLAP-Abfragetools auf dem Markt, die unterschiedlich komplex sind
• OLAP-Schemata, z. B. das Standard Sternschema sind entworfen leicht abfragbar sein. Sie sind von Natur aus flach, wobei die Faktentabelle mit einer oder mehreren Dimensionstabellen unter Verwendung einfacher Schlüssel auf sehr unkomplizierte Weise verbunden wird.
• Die Arten von Operationen, die mit den Berichten durchgeführt werden sollen, sind vorhersehbar: Filtern, Sortieren, Gruppieren nach, Hinzufügen oder Entfernen von Spalten, Export in CSV usw.
• Sie erhalten ein hohes Maß an Flexibilität bei den erstellten Berichten - die Möglichkeit, Daten für verschiedene Beziehungen zu untersuchen, ist sehr fesselnd
• Wenn Sie das Abfragetool einmal geschrieben haben, ist es portabel und kann mit jedem anderen Sternschema wiederverwendet werden - nicht schlecht!
• "Ist es möglich, die Berichtslogik und die Details des Datenbankschemas zu abstrahieren?" - Ja, OLAP-Schemata dienen genau diesem Zweck - sie sorgen dafür, dass alle Daten einem standardisierten Schema entsprechen. Natürlich wird dadurch die Geschäftslogik in die ETL-Schicht verlagert, aber ich würde argumentieren, dass sie dorthin gehört.

Bei diesem Ansatz müssen Sie also ETL durchführen - eine Möglichkeit ist die Durchführung einer Form von ROLAP In der Praxis habe ich jedoch festgestellt, dass es genauso einfach ist, ETL-Skripte zu schreiben, wie eine gute Leistung aus einer ROLAP-Einrichtung herauszuholen.

Answer 3

Eine Lösung, die meiner Meinung nach in der Regel nach hinten losgeht, die aber andere, die ich kenne, gut finden, besteht darin, die Daten als XML aus jeder Datenbank zu erzeugen. So erhalten Sie einen konsistenten Datensatz in einer Form, die die meisten Produkte problemlos verarbeiten können.

Wenn Sie dies tun, stellen Sie sicher, dass die XPath-Abfragen, die Sie darauf ausführen werden, schnell sind.