525

27 InfoProvider

Der Zugriff auf Datenziele mit physisch vorhandenen Daten erfllt nureinen Teil der Anforderungen, die an die Analytical Engine gestelltwerden. Ebenso wichtig kann es sein, bei der Analyse von Daten meh-rere physische Datenbestnde in einen gemeinsamen Kontext zu stellenoder Daten sogar aus ganz anderen Quellen zu beziehen.

Zu diesem Zweck bietet das BW ber die Datenziele hinaus wei-tere InfoProvider, die lediglich als Metadatenobjekte definiert werdenund Lesezugriffe an die Datenstrukturen physischer Datenziele rich-ten. Je nachdem, welches Ziel mit dem Einsatz eines solchen InfoProvi-ders verfolgt wird und welche Datenquellen zur Analyse herangezogenwerden sollen, knnen unterschiedliche Typen von InfoProvider ver-wendet werden:

MultiProvider, um Daten mehrerer InfoProvider in einen gemein-samen Kontext zu stellen (Abschnitt 27.1),

semantisch partitionierte Objekte, um die Daten aus den Partitio-nen semantisch partitionierter Objekte in einen gemeinsamen Kon-text zu stellen (Abschnitt 27.2),

InfoSets, um Daten von InfoCubes, DataStore-Objekten und Info-Objekten mit Stammdaten relational zu verknpfen (Abschnitt 27.3),

TransientProvider, um ohne vorangehende Datenmodellierung Ad-hoc-Analysen (auch im SAP ERP) auszufhren oder um Daten inanalytischen Indizes zu analysieren (Abschnitt 27.4),

CompositeProvider, um die Inhalte unterschiedlicher analytischerIndizes zusammenzufhren und ggf. mit Daten normaler Info-Provider des BW zu verbinden (Abschnitt 27.5),

VirtualProvider mit Funktionsbaustein und BAPI zur Implementie-rung spezifischer Analyseanforderungen, die nur durch eigendefi-nierte Programmlogik erfllt werden knnen (Abschnitt 27.6).

Die Definition und Funktionsweise dieser InfoProvider wird in dennachfolgenden Abschnitten erlutert.

Christian Mehrwald, Data Warehousing mit SAP BW 7.3, dpunkt.verlag, ISBN 978-3-86490-037-2

D3kjd3Di38lk323nnm

27 InfoProvider526

27.1 MultiProvider

MultiProvider dienen dazu, die Daten unterschiedlicher InfoProviderzusammenzufhren und damit in einen gemeinsamen Kontext zu stel-len. Dies kann aus unterschiedlichen Grnden erforderlich sein:

Es existieren mehrere InfoProvider, die betriebswirtschaftlich abge-schlossene Bereiche darstellen. Diese verfgen zwar ber einegemeinsame Schnittmenge mit identischem Zeitbezug (zum Bei-spiel enthalten alle InfoProvider eine Kundennummer und bezie-hen ihre Daten auf eine Geschftsperiode), haben aber ansonsteneine heterogene Datenstruktur. Die Merkmale, die die Schnitt-menge bilden, sollen in einen gemeinsamen Kontext gestellt wer-den, um sie im Reporting zusammenzufhren.

Es sollen die Daten unterschiedlicher InfoProvider, die aus techni-schen Grnden nicht in einem InfoProvider vorgehalten werden(zum Beispiel weil strukturhnliche Daten auf InfoCubes, virtuelleCubes und DataStore-Objekte verteilt sind), in einen gemeinsamenKontext gestellt werden.

Es sollen Daten, die aus Designgrnden auf mehrere InfoProviderverteilt sind (zum Beispiel Plan- und Istdaten) in einen gemeinsa-men Kontext gestellt werden.

Daten wurden zur Verbesserung der Performance auf mehrereInfoProvider verteilt und mssen zur Analyse der Daten wiederzusammengefgt werden1.

Welche InfoProvider einem MultiProvider zugrunde liegen sollen, wirdbereits beim Anlegen des MultiProviders bestimmt, kann jedoch nach-trglich verndert werden. Zur Auswahl stehen dabei alle Typen vonInfoCubes und DataStore-Objekten, HybridProvider, InfoSets undAggregationsebenen der integrierten Planung nicht jedoch andereMultiProvider (siehe Abb. 271). Werden InfoCubes oder DataStore-Objekte als semantisch partitionierte Objekte angelegt, so knnen ent-weder die dadurch definierten Partitionen oder das semantisch parti-

ber die Zusammenfhrung unterschiedlicher InfoProvider hinaus bilden Multi-Provider auch eine logische Schicht ber die ausgewhlten InfoProvider undabstrahieren damit die Definition der Datenanalyse von den genutzten InfoPro-vidern. Setzen Sie MultiProvider daher stets ein selbst wenn nur Daten auseinem einzigen InfoProvider gelesen werden mssen. Weitere Einzelheiten wer-den im Abschnitt zum BW-Design in Kapitel 35 erlutert.

1. Siehe Abschnitt 12.4.

52727.1 MultiProvider

tionierte Objekt selbst in den MultiProvider aufgenommen werden.Letzteres ist zu empfehlen, da hierdurch auch die fr semantisch parti-tionierte Objekte spezifischen Optimierungen Anwendung finden2.InfoObjekte knnen nur dann in MultiProvider aufgenommen wer-den, wenn sie als InfoProvider definiert wurden3.

Die Zusammenfhrung mehrerer InfoProvider zu einem MultiProvi-der erfolgt nach dem Prinzip einer Union-Abfrage, in der smtlicheTabellenfelder (=InfoObjekte) mit identischem Namen aufeinanderabgebildet werden. Kennzahlenfelder mit identischem Namen werdendabei aggregiert (siehe Abb. 272).

Identifikation von

Merkmalen

Die InfoObjekte, die ein MultiProvider zur Datenanalyse bereit-stellen kann, werden durch die zugrunde liegenden InfoProvider vor-gegeben. Diese sind bei der Modellierung ebenso wie bei InfoCubes inDimensionen zu gliedern, wobei die Gliederung in diesem Fall keineAuswirkung auf die physische Datenhaltung hat, sondern lediglichsemantischer Natur ist und nach fachlichen Gesichtspunkten erfolgenkann.

2. Siehe Abschnitt 27.2.3. Siehe Kapitel 4.

Abb. 271Anlegen von

MultiProvidern

SAP AG

Christian Mehrwald, Data Warehousing mit SAP BW 7.3, dpunkt.verlag, ISBN 978-3-86490-037-2

27 InfoProvider528

Auf welche Weise Merkmals-InfoObjekte der einzelnen InfoProviderin einem MultiProvider aufeinander abgebildet werden, ist in der Defi-nition des jeweiligen MultiProviders vorzugeben. Dabei kann fr jedenInfoProvider festgelegt werden, ob er Werte zu einem Merkmals-Info-Objekt liefert und aus welchem InfoObjekt der Wert geliefert werdensoll (sofern es sich um Merkmale handelt, die auf identische Basis-merkmale referenzieren4). Die InfoObjekte sind hierfr in der Pflegedes MultiProviders entsprechend zu identifizieren. Abbildung 273zeigt ein Beispiel, in dem das InfoObjekt 0SOLD_TO5 im MultiProvideraus den InfoObjekten 0SOLD_TO (InfoProvider QDX1) und 0CUSTOMER(InfoProvider QDX2) versorgt wird und der InfoProvider QDX3 keinenWert beisteuert, obwohl er ber ein geeignetes InfoObjekt verfgenwrde.

4. Siehe Abschnitt 4.1.7.5. Das InfoObjekt 0SOLD_TO referenziert im BI Content auf das InfoObjekt 0CUSTOMER.

Abb. 272Zusammenfhrung von

Daten durch MultiProvider

52927.1 MultiProvider

In der Praxis werden blicherweise immer identische InfoObjekte auf-einander abgebildet. Zu diesem Zweck besteht die Mglichkeit, beider Identifikation eines Merkmals oder Navigationsattributs einenentsprechenden Vorschlag erzeugen zu lassen. Wird die Identifikationeines Merkmals aus einem InfoProvider nicht aktiviert oder enthlt einInfoProvider kein passendes Merkmal, so wird dem entsprechendenInfoProvider die Lieferung des Initialwerts (#) unterstellt.

Identifikation

geklammerter Merkmale

und Klammerungs-

bestandteile

Besondere Beachtung erfordert die Identifikation geklammerterMerkmale und ihrer Klammerungsbestandteile: Diese sollten stetskonsistent zueinander identifiziert werden, d.h., jeder InfoProvidersollte das geklammerte Merkmal und alle Klammerungsbestandteilevollstndig aus derselben Basis oder gar nicht liefern. So sollten bei-spielsweise die Merkmale 0GL_ACCOUNT6 und 0CHRT_ACCTS beide aus denInfoObjekten eines InfoProviders oder aus den Navigationsattributendesselben InfoObjekts dieses InfoProviders identifiziert werden.

Alternativ knnen auch beide InfoObjekte nicht identifiziert wer-den, jedoch wrde beispielsweise eine unvollstndige Identifikation

SAP AG

Abb. 273Identifizieren von

Merkmalen bei der

Definition von

MultiProvidern

6. Das InfoObjekt 0GL_ACCOUNT (Sachkonto) ist im BI Content an das InfoObjekt0CHRT_ACCTS (Kontenplan) geklammert.

Christian Mehrwald, Data Warehousing mit SAP BW 7.3, dpunkt.verlag, ISBN 978-3-86490-037-2

27 InfoProvider530

dazu fhren, dass durch den MultiProvider Merkmalswerte geliefertwerden, die tatschlich in keinem der beteiligten InfoProvider vorhan-den sind. Abbildung 274 verdeutlicht dies anhand zweier InfoProvi-der, die das InfoObjekt 0GL_ACCOUNT mit der Klammerung an0CHRT_ACCTS jeweils nur zum Teil identifizieren.

hnlich problematische Situationen knnen entstehen, wenn Klamme-rungsbestandteile nicht aus derselben Basis gezogen werden, wenn alsobeispielsweise 0GL_ACCOUNT aus einem Merkmal in den Dimensioneneines InfoCubes und 0CHRT_ACCTS aus den Navigationsattributen einesanderen Merkmals des InfoCubes identifiziert wird.

Die Nutzung von Merkmalswerten in der Datenanalyse, zu denenkeine SID bestehen, ist fr das BW problematisch: Wird eine entspre-chende MultiProvider-Abfrage beispielsweise an den BWA gerichtet,verweigert dieser Teile der Abfrage und gibt sie an die AnalyticalEngine des BW zurck (die derartige Umstnden beherrscht). Dies istzwar in erster Linie ein Performance-Problem, jedoch knnen auchhier unter Umstnden fehlerhafte Ergebnisse entstehen.

Aus diesem Grund meldet das BW die Definition eines MultiProvi-ders grundstzlich als fehlerhaft, wenn die Identifikation geklammer-ter Merkmale und ihrer Klammerungsbestandteile so gestaltet ist, dassdie beschriebenen Inkonsistenzen entstehen knnen. Im Sprachge-brauch des BW wird in einem solchen Fall auch von einem Compoun-ding oder CMP-Problem gesprochen.

Soll eine derart inkonsistente Modellierung dennoch durchgefhrtwerden, so kann die Fehlermeldung individuell fr jeden MultiProvi-der in eine Warnung umgewandelt werden (siehe Abb. 275).

Abb. 274Inkonsistente

Identifikation

geklammerter Merkmale

53127.