MultiProvider 

Definition

Ein MultiProvider ist ein Typ eines InfoProviders, der Daten aus mehreren InfoProvidern zusammenführt und sie gemeinsam für das Reporting zur Verfügung stellt. Der MultiProvider enthält selbst keine Daten; seine Daten ergeben sich ausschließlich aus den zugrundeliegenden InfoProvidern, die per Union-Operation zusammengefasst werden.

Verwendung

Ein MultiProvider erlaubt das Reporting über mehrere InfoProvider.

 

InfoCube und InfoCube: Sie haben einen InfoProvider mit Ist-Daten zu einem logisch geschlossenen betriebswirtschaftlichen Bereich sowie einen entsprechenden InfoProvider mit Plan-Daten. Sie können die beiden InfoProvider zu einem MultiProvider kombinieren, um Ist- und Plan-Daten in einer Query vergleichen zu können. Diese Kombination aus zwei InfoCubes wurde in BW Release 2.0B/2.1C noch MultiCube genannt.

InfoCube und InfoObject: Sie haben einen InfoCube mit Ihren Produkten und Umsätzen. Dazu kombinieren Sie das InfoObject 0MATERIAL. Damit können Sie sich "Ladenhüter" anzeigen lassen, da auch die Produkte angezeigt werden, die keinen Umsatz erzielen. Zur detaillierten Vorgehensweise siehe die Beschreibung des Ladenhüter-Szenarios.

Struktur

Ein MultiProvider kann sich aus verschiedenen Kombinationen der folgenden InfoProvider zusammensetzen: InfoCube, DataStore-Objekt, InfoObject, InfoSet, VirtualProvider und Aggregationsebene.

Die Daten dieser Objekte werden im MultiProvider per Union-Operation zusammengefasst, wodurch die Vereinigungsmenge der beteiligten Datenbestände gebildet wird. Es werden also alle Werte dieser Datenbestände zusammengeführt. Zum Vergleich: InfoSets werden über Joins gebildet, die nur Werte zusammenführen, die in beiden Tabellen vorhanden sind. Joins bilden also im Gegensatz zu einem Union die Schnittmenge der beteiligten Tabellen.

Siehe zum Vergleich auch InfoSet.

In einem MultiProvider muss jedes Merkmal des MultiProviders in jedem beteiligten InfoProvider genau einem Merkmal bzw. Navigationsattribut entsprechen (sofern es in diesem vorhanden ist). In mehrdeutigen Fällen muss bei der Definition des MultiProviders angegeben werden, welchem InfoObject das Merkmal des MultiProviders zuzuordnen ist.

Der MultiProvider enthält das Merkmal : 0COUNTRY (= Land), ein beteiligter InfoProvider enthält sowohl das Merkmal 0COUNTRY als auch das Navigationsattribut 0CUSTOMER__0COUNTRY (= Land des Kunden). Markieren Sie in diesem Fall genau eines dieser InfoObjects in der Zuordnungstafel.

Eine Kennzahl, die in einem MultiProvider enthalten ist, muss aus mindestens einem der beteiligten InfoProvider selektiert werden. Im allgemeinen wird die Kennzahl aus genau einem InfoProvider versorgt. Es gibt jedoch auch Anwendungsfälle, in denen sinnvoll aus mehreren InfoProvidern selektiert wird:

Ist die Kennzahl: 0SALES (Umsatz) in mehreren InfoProvidern redundant abgelegt (d.h. vollständig in allen Wertekombinationen der Merkmale enthalten), ist eine Selektion aus genau einem der beteiligten InfoProvider gewünscht und ausreichend (ansonsten würde der mehrfach vorliegende Wert im MultiProvider fälschlich addiert).

Ist 0SALES aber in einem InfoProvider z.B. als Ist-Wert, in einem anderen als Plan-Wert gespeichert, so dass keine Überschneidungen in den Datensätzen auftreten (d.h. mit anderen Worten: der Umsatz ist auf mehrere InfoProvider disjunkt aufgeteilt worden), so ist eine Selektion aus mehreren InfoProvidern sinnvoll.

Man kann MultiProvider in folgende Kategorien einteilen:

...

       1.      homogene MultiProvider:

bestehen aus technisch gleichartigen InfoProvidern, z.B. InfoCubes mit genau denselben Merkmalen und Kennzahlen, wobei ein InfoCube beispielsweise Daten aus dem Jahr 2001 enthält, ein zweiter InfoCube Daten aus dem Jahr 2002 usw. Homogene MultiProvider stellen eine Möglichkeit der Partitionierung auf der Modellierungsebene der InfoProvider dar.

       2.      heterogene MultiProvider:

bestehen aus InfoProvidern, die nur einen Teil der Merkmale und Kennzahlen gemeinsam haben.  Heterogene MultiProvider können dazu dienen, die Modellierung von Szenarien zu vereinfachen, indem diese in Unterszenarien zerlegt werden. Jedes Unterszenario wird dabei durch einen eigenen InfoProvider repräsentiert. Ein Beispiel dafür ist ein Verkaufsszenario, das aus den Teilprozessen Auftrag, Lieferung und Bezahlung besteht. Jeder dieser Teilprozesse hat eigene (private) InfoObjects (z.B. Lieferort, Rechnungsnummer), aber auch prozessübergreifende (z.B. Kunde, Auftragsnummer). Hier bietet es sich an, jeden Teilprozess in einem eigenen InfoProvider zu modellieren, die über einen MultiProvider zusammengeführt werden. Es ist nun möglich,

¡        alle Unterszenarien in einem InfoProvider zu modellieren, oder

¡        pro Unterszenario einen InfoProvider anzulegen und diese dann in einem MultiProvider zusammenzuführen.

Die letztgenannte Variante führt in der Regel zu einfacheren Modellen und kann günstige Auswirkungen auf Lade- und Lese-Performance (siehe unten: Parallelisierung von MultiProvider-Queries) haben.

Integration

MultiProvider existieren nur als eine logische Definition. Die Daten sind weiterhin in den zugrundeliegenden InfoProvidern gespeichert.

Eine Query auf einem MultiProvider wird intern in Teil-Queries zerlegt. Dabei entsteht eine Teil-Query pro am MultiProvider beteiligtem InfoProvider. Die entstehenden Teil-Queries werden in der Regel parallel verarbeitet.

Detaillierte Informationen dazu finden Sie unter:

Zerlegung einer MultiProvider-Query in Teil-Queries

Parallelisierung von Teil-Queries zu einem MultiProvider

Technisch gibt es keine Einschränkungen bzgl. der Anzahl von InfoProvidern, die in einen MultiProvider aufgenommen werden können. Wir empfehlen jedoch, nicht mehr als 10 InfoProvider aufzunehmen, da in etwa ab dieser Anzahl die Zerlegung (der MultiProvider-Queries) und das Wiederzusammenführen (der Resultate  aus der einzelnen InfoProvidern) einen erheblichen zeitlichen Umfang annehmen, der im allgemeinen kontraproduktiv ist. Darüber hinaus ist die Modellierung derartiger MultiProvider unübersichtlich.

MultiProvider mit Bestandskennzahlen

In  einem MultiProvider sollten Sie nicht mehr als einen Bestands-InfoCube (InfoCube mit mindestens einer Bestandskennzahl) verwenden, da dies zu falschen Query-Ergebnissen führen kann.