ProzessModellierung ohne persistente Datenablage

 

In diese Modellen werden die Daten nicht persistent im BW-System abgelegt, sondern für Reporting und Analyse direkt gelesen.

Prozess

Einfaches Modell mit VirtualProvider

Die Daten werden über einen VirtualProvider direkt im Quellsystem gelesen.

Analyse und Reporting auf einem VirtualProvider ist eine geeignete Alternative, wenn

  • eine zeitnahe Verfügbarkeit von Daten aus dem Quellsystem erforderlich ist.

  • wenn nur sporadisch auf eine kleine Datenmenge zugegriffen werden soll und im Vergleich dazu eine Replikation der Daten ins BW zu aufwendig ist.

  • wenn nur wenige Benutzer gleichzeitig Queries auf dem angeforderten Datenbestand des Quellsystems ausführen.

Eine Query auf einem VirtualProvider kann, unter der Voraussetzung, dass ein geeigneter Extraktor vorhanden ist, einen Drill through mittels Bericht-Bericht-Schnittstelle auf ein SAP Quellsystem ersetzen. In beiden Fällen erhält man Real-Time-Daten, beim Drill through werden Sie jedoch in einer SAP Query präsentiert, beim VirtualProvider in einer BEx Query.

Einschränkungen:
  • Ständige Verfügbarkeit des Quellsystems ist notwendig.

  • Die Datenanalyse auf einem VirtualProvider erzeugt eine zusätzliche Last auf dem Quellsystem, die umso höher ausfällt, je mehr Benutzer im BEx Query auf VirtualProvidern ausführen und je höher das Aggregationsniveau der Queries ist.

  • VirtualProvider unterstützen keine Navigationsattribute.

Eine weitere Einsatzmöglichkeit liegt im Prototyping unter Einsatz des generischen Extraktors. Dabei können Sie auch mit Hilfe von DB Connect relativ schnell und einfach Fremdsysteme erreichen.

Da VirtualProvider keine persistente Datenablage im BW-System erfordern, können Strukturänderungen (Extraktstruktur, Transformationsregeln) im gesamten Staging-Prozess in der Prototyp-Phase schnell durchgeführt werden.

Data Mart Szenario mit dem VirtualProvider

Die Daten werden zunächst in einem BW-System (BW 1) in DataStore-Objekten oder InfoCubes abgelegt. Für die Analyse werden sie in aus einem weiteren BW-System (BW 2) über einen VirtualProvider ausgelesen.

Beim Aufbau einer Systemlandschaft mit mehreren BW-Systemen stehen Sie hinsichtlich der Verteilung der Bewegungsdaten vor den Alternativen, die Daten entweder vorab zu replizieren oder erst bei Anforderung aus dem Quell-BW zu lesen. Für die zweite Alternative stehen Ihnen die VirtualProvider zur Verfügung. Die Einschränkung, die im Falle des Einsatzes bei einem SAP-System gelten, haben bei der Kopplung zweier BI-Systeme ein geringeres Gewicht. So kann die Performancebelastung des Quellsystems (BW 1) bei der Verwendung von InfoCubes durch den Einsatz geeigneter Aggregate oder BW Accelerator Indizes deutlich reduziert werden. Die Einschränkung bzgl. Systemverfügbarkeit und Navigationsattributen bleibt natürlich weiterhin bestehen.

In der Regel ist es nicht sinnvoll, in einem Data Mart Szenario Daten auf Belegebene in alle angeschlossenen BW-Systeme zu replizieren. Da auf diese Daten in den angeschlossenen BW-Systeme im Detail nur sporadisch zugegriffen wird, ist dieser Anwendungsfall für den Einsatz von VirtualProvidern gut geeignet.