daten-remodellierung in sap netweaver bw - thali.ch · sap netweaver bw ..... 199 4.1 struktur und...

Matthias Zinke

Daten-Remodellierung in SAP NetWeaver® BW

Bonn � Boston

1481.book Seite 3 Donnerstag, 11. März 2010 1:10 13

5

Inhalt

Vorwort ..................................................................................................... 9

1 Analyse bestehender BW-Anwendungen ............................ 15

1.1 Motivation für eine Remodellierung ........................................ 171.1.1 Kombination von Releasewechsel und

Remodellierung .......................................................... 171.1.2 Hardwareentwicklung und technische Möglichkeiten ... 211.1.3 Bewertungskriterien für BW-Anwendungen ................ 221.1.4 Risiken der Remodellierung ......................................... 311.1.5 Kosten-Nutzen-Analyse .............................................. 32

1.2 Analyse, Prüfung und Bewertung von Datenmodellen .............. 341.2.1 Theoretische Ansätze zur Datenmodellierung .............. 351.2.2 Datenmodell und Datenfluss ....................................... 391.2.3 Visualisierung von Datenmodellen .............................. 401.2.4 Analyse und Prüfung von Datenflüssen ....................... 441.2.5 Bewertung bestehender Datenmodelle ....................... 47

1.3 Datenqualität von BW-Systemen ............................................. 501.3.1 Manuelle Analyse der Abweichungen .......................... 501.3.2 Fehlerquellen .............................................................. 511.3.3 Zeitlicher Horizont von Berichten ................................ 541.3.4 Technischer Datenabgleich .......................................... 56

1.4 Technische Analyse und Bewertung von Query-Laufzeiten ....... 701.4.1 Ablauf einer BW-Abfrage ............................................ 701.4.2 Technische Faktoren der Query-Laufzeit ...................... 711.4.3 Transaktionen für die Ermittlung der Performance ....... 721.4.4 Indizes auf Stammdatentabellen .................................. 781.4.5 Datenbankstatistik ...................................................... 791.4.6 Bewertung von Aggregaten ......................................... 80

1.5 Identifikation und Bewertung der Reporting-Objekte .............. 821.5.1 Bestandsaufnahme ...................................................... 841.5.2 Analyse und Bewertung der identifizierten Objekte ..... 891.5.3 Statistische Verteilung der Daten im InfoCube ............ 921.5.4 Analyse von DSOs ....................................................... 971.5.5 Aufwand für Pflege und Wartung von

Reporting-Objekten .................................................... 981.5.6 Erweitern von Reporting-Objekten .............................. 103


Inhalt

6

2 Konzeption der Remodellierung .......................................... 105

2.1 Planung der Maßnahmen ......................................................... 1052.1.1 Detaillierte Zeitplanung ............................................... 1082.1.2 Personelle Ressourcenplanung .................................... 1092.1.3 Ausarbeitung des Projektplans .................................... 109

2.2 Technische Datenmodellierung ................................................ 1092.2.1 Technische Grundlagen ............................................... 1102.2.2 Anbindung von Nicht-SAP-Systemen .......................... 1202.2.3 Einsatz von InfoSources ............................................... 1222.2.4 Transformationen ........................................................ 1232.2.5 Start- und Endroutinen ............................................... 1242.2.6 Expertenroutine .......................................................... 1272.2.7 Umsetz- und Mapping-Tabellen .................................. 130

2.3 Optimierung bestehender Querys ............................................ 1332.3.1 Query-Modellierung und Performance ........................ 1332.3.2 Zähler ......................................................................... 1352.3.3 Ausnahme-Aggregationen ........................................... 1352.3.4 Darstellung von Ergebnissen ....................................... 1362.3.5 Konstante Selektion .................................................... 1382.3.6 Sprungziele vs. Drilldown-Funktionen ......................... 1392.3.7 Virtuelle Kennzahlen und Merkmale ........................... 140

2.4 Remodellierung von InfoProvidern .......................................... 1442.4.1 InfoCube-Modellierung ............................................... 1452.4.2 DSOs als Datenprovider .............................................. 1522.4.3 InfoObjects als Datenprovider ..................................... 1532.4.4 Virtuelle Provider ........................................................ 1542.4.5 MultiProvider .............................................................. 1582.4.6 Aggregate ................................................................... 158

2.5 Praxisbeispiele ......................................................................... 1642.5.1 Remodellierung einer Einkaufsanwendung .................. 1642.5.2 Remodellierung einer Tarifberechnung ........................ 167

3 Implementierung, Test und Transport ................................. 169

3.1 Testphasen und Nutzerschulungen .......................................... 1703.1.1 Testphasen in einem Remodellierungsprojekt .............. 1713.1.2 Schulungen der Nutzer ................................................ 174

3.2 Remodellierung in der klassischen Variante ............................. 1763.2.1 Kopie der zu remodellierenden InfoProvider ............... 1773.2.2 Transfer der Daten in den kopierten InfoProvider ........ 177


Inhalt

7

3.2.3 Remodellierung des InfoProviders ............................... 1793.2.4 Transfer der Daten in den remodellierten

InfoProvider ................................................................ 1813.3 Remodellierung mit dem SAP-Tool .......................................... 1813.4 Transport geänderter Datenmodelle ........................................ 185

3.4.1 Transportkonzepte in SAP NetWeaver BW 7.0 ............ 1853.4.2 Hilfsprogramme zum Nachaktivieren ........................... 1883.4.3 Reparaturkennzeichen an Objekten ............................. 1893.4.4 Manuelle Aufnahme von Transportobjekten ................ 1893.4.5 Transport Workbench in SAP NetWeaver BW 7.0 ....... 1933.4.6 Import in das Zielsystem ............................................. 1953.4.7 Nacharbeiten im Zielsystem ........................................ 198

4 Informationsbeschaffung und Informationsablage in SAP NetWeaver BW ............................................................. 199

4.1 Struktur und Aufbau von Reporting-Objekten .......................... 1994.1.1 Technische Strukturen eines InfoCubes ....................... 2004.1.2 Wichtige Merkmale von DSOs .................................... 2024.1.3 Strukturdefinitionen in MultiProvidern ........................ 204

4.2 Tabellen für Transformationen und Mappings .......................... 2044.2.1 InfoSources (Strukturinformationen aus der

Workbench) ................................................................ 2044.2.2 Transformationen ........................................................ 205

4.3 Datenbeschaffung innerhalb von SAP NetWeaver BW ............. 2064.3.1 Nachlesen von Stammdaten ........................................ 2064.3.2 Datenbeschaffung aus anderen Objekten .................... 207

4.4 Querys und Transaktionen für den Administrator ..................... 2084.4.1 Transaktion RSPCM zur Überwachung täglicher

Prozessketten .............................................................. 2084.4.2 Virtuelle Provider und DataSources für

Administrator-Querys ................................................. 2094.4.3 Wichtige Tabellen für den Aufbau von Querys zur

Systemüberwachung ................................................... 209

5 Tools und Hilfsprogramme ................................................... 211

5.1 Standardwerkzeugkasten von SAP NetWeaver BW 7.0 ............ 2115.1.1 Transaktion RSRT (Start des Berichtsmonitors) ............ 2115.1.2 Transaktion RSTT (RS Trace Tool Monitor) .................. 2145.1.3 Transaktion RSRV (Analyse und Reparatur von

BW-Objekten) ............................................................ 215


Inhalt

8

5.1.4 Transaktion DB05 (Analyse einer Tabelle bezüglich des Index) ................................................... 216

5.2 Traces und Statistiken .............................................................. 2175.2.1 Transaktion ST01 (System-Trace) ................................. 2175.2.2 Transaktion ST05 (Performance-Analyse) ..................... 2195.2.3 Transaktion SE30 (ABAP-Objects-Laufzeitanalyse) ....... 2195.2.4 Transaktion ST03N (Systemlast und Performance-

Statistik) ...................................................................... 2215.3 Hilfsprogramme selbst erstellen ............................................... 222

5.3.1 Allgemeine Programmierempfehlungen in SAP NetWeaver BW .................................................... 222

5.3.2 Funktionsbausteine und statische Methoden ............... 2265.3.3 Daten vom Server einlesen .......................................... 232

Anhang ....................................................................................... 237

A Ergänzende Informationen ................................................................. 237A.1 Checkliste zur Remodellierung ................................................. 237A.2 SAP-Hinweise .......................................................................... 238A.3 Coding der vorgestellten Programme ....................................... 241A.4 Zulässige Änderungen an InfoObjects ...................................... 259

B Der Autor ........................................................................................... 263

Index ........................................................................................................ 265


Analyse bestehender BW-Anwendungen1

82

Benchmarking von BW-Berichten

Die reine Laufzeit kann nicht zur Bewertung von Query-Laufzeiten herange-zogen werden. Für ein Benchmarking über die Applikationsgrenzen hinaussollten Sie einen Matrixvergleich durchführen, in dem Sie die gemesseneLaufzeit des Berichts, die Häufigkeit der Durchführung (Monatsberichte =strategische Berichte, Tagesberichte = operative Berichte) und die erwarteteDatenqualität in einer Matrix darstellen. Abbildung 1.48 zeigt ein Beispielfür den Vergleich unterschiedlicher Applikationen.

Berichte, die in der Matrix im Bereich 1 stehen, brauchen Sie keiner weite-ren Überprüfung zu unterziehen; die Gefahr, die Datenqualität zugunsten derBerichtslaufzeit zu verschlechtern, ist sehr groß. Im Matrixbereich 2 solltenSie entscheiden, ob es sich um strategische oder operative Berichte handelt.Im Falle strategischer Berichte rate ich von einer weiteren Optimierung ab,da diesen Berichten eine hohe Datenqualität zugrunde liegen sollte und dieLaufzeit nur eine untergeordnete Rolle spielt. Berichte im Matrixfeld 3 soll-ten in Bezug auf die Datenqualität optimiert werden; hier sind vor allem Re-modellierungen im Datenmodell durchzuführen. Sollten Sie Berichte in Ma-trixfeld 4 vorfinden, ist eine Optimierung am Datenmodell unumgänglich.

1.5 Identifikation und Bewertung der Reporting-Objekte

Dieser Abschnitt widmet sich ausführlich der Identifikation und Bewertungder in Ihrem Datenmodell verwendeten Reporting-Objekte. Am Ende IhrerAnalyse sollten Sie einen umfassenden Überblick über Ihre Reporting-

Abbildung 1.48 Bewertungsmatrix für Querys

Daten-qualität

Query-Laufzeit in Sekundenniedrig hoch

hoch kein Handlungsbedarf

großer Handlungsbedarf

berichtsabhängig

berichtsabhängig


Identifikation und Bewertung der Reporting-Objekte 1.5

83

Objekte haben. Sie können dann entscheiden, welche Objekte Sie z. B. ausIhrem Datenmodell entfernen können, und Sie gewinnen wertvolle Informa-tionen darüber, welche Aggregationsebenen Sie in Ihr Datenmodell ein-bauen können. Darüber hinaus erfahren Sie, wie Sie Ihre InfoCubes hinsicht-lich des strukturellen Ausbaus analysieren und wie Sie Ihre DSOsanalysieren, um sie in InfoCubes umzuwandeln.

Unter Reporting-Objekten werden all die BW-Objekte zusammengefasst, dieim Query Designer bei der Query-Definition zur Verfügung stehen bzw. ineinen MultiProvider eingebunden werden können. In Ihrem SAP NetWea-ver BW-System werden all diese Objekte als InfoProvider bezeichnet, Sie fin-den Sie daher auch an dieser Stelle in der Administrator Workbench. Ausge-nommen hiervon sind die ERP-Tabellen1: Diese sind nicht direkt in derQuery-Definition verfügbar, sollen hier aber der Vollständigkeit halber mitaufgeführt werden, da sie auch über User Exits mit in die Query-Gestaltungaufgenommen werden können. Reporting-Objekte bzw. InfoProvider kön-nen sein:

� MultiProvider

� InfoCubes

� DSOs

� virtuelle Provider

� InfoObjects

� InfoSets

� ERP-Tabellen

Da Ihre Daten überwiegend in InfoObjects gespeichert werden, sollten Sieauf diese ein besonderes Augenmerk richten. In der Hauptsache teilen sichIhre InfoObjects in Merkmale und Kennzahlen auf. Die in Ihrem Datenmo-dell verwendeten InfoObjects fassen Sie in einem für Ihre Applikation gülti-gen InfoObject-Katalog zusammen. Dies kann bereits während der Analyseerfolgen, da es sich bei den Katalogen um Ordner handelt, die der Übersicht-lichkeit dienen und Ihnen unter Umständen auch den Transport IhrerObjekte erleichtern. Legen Sie jeweils einen Katalog für Ihre Kennzahlen undeinen für Ihre Merkmale an, und strukturieren Sie so Ihr BW-System nachden von Ihnen entwickelten Applikationen. Sie können das gleiche Info-Object auch in zwei verschiedene Kataloge aufnehmen, um eine bessereÜbersichtlichkeit zu erreichen.

1 Hiermit sind auch Datenbanktabellen in SAP NetWeaver BW gemeint, die über User ExitsDaten für das Reporting zur Verfügung stellen.



84

Fragen Sie sich auch, welche die wichtigsten InfoObjects in Ihrem Datenmo-dell sind. Suchen Sie z. B. nach Organisationsebenen, die oft für die Aggrega-tion der Daten verwendet werden. Kennzeichnen Sie auch InfoObjects, dieeine hohe Anzahl an unterschiedlichen Ausprägungen haben. Sie benötigendiese Information später für die Remodellierung. Treffen Sie eine Unter-scheidung in Stammdaten und Bewegungsdaten, dies kann unter anderemdabei helfen, über Navigationsattribute zu entscheiden.

Wie in Abschnitt 2.1, »Planung der Maßnahmen«, beschrieben, werden fürdas Reporting vor allem InfoObjects in MultiProvidern angeboten. Da Siesich aber noch in der Analysephase befinden, ist es unerlässlich, alle repor-tingrelevanten Objekte aufzulisten. Auch wenn es etwas mühsam ist, eineListe in Excel zu erstellen, in der alle verwendeten InfoObjects aufgelistetwerden, ist eine Dokumentation außerhalb Ihres BW-Systems für die einge-hende Analyse unumgänglich, um so einen genauen Überblick zu erhalten.Nach der Auflistung kann die Beurteilung der Objekte durchgeführt werden.

1.5.1 Bestandsaufnahme

Zu einer gründlichen Bestandsaufnahme gehört es auch, zu ermitteln, wel-che Objekte in den Querys überhaupt verwendet werden. Dafür brauchenSie einen Verwendungsnachweis für Ihre Reporting-Objekte. Um nicht jedeeinzelne Query nach den verwendeten InfoObjects durchsuchen zu müssen,können Sie mit dem Analyseprogramm Z_REFERENCE_Q_OBJECTS InfoPro-vider für InfoProvider vorgehen. Sie können dann in Kombination mit derAnalyse des InfoCubes entscheiden, welche Objekte Sie in Zukunft nichtmehr in der Modellierung berücksichtigen müssen.

Verwendungsnachweis für Reporting-Objekte

Bestimmen Sie, welche Merkmale und Kennzahlen aus Ihren Datenprovi-dern verwendet werden, denn für ein schlankes Datenmodell benötigen Siegenau diese Informationen. Im SAP-System gibt es kein Tool, das diese Infor-mation bereitstellt. Da Sie bereits eine Liste mit Ihren verwendeten Info-Cubes angefertigt haben, können Sie mithilfe dieser Liste jeden InfoCubeanalysieren und sich so einen Überblick über die verwendeten InfoObjectsverschaffen. Hier hilft das im Anhang dieses Buches aufgeführte Analyse-programm Z_REFERENCE_Q_OBJECTS. Es gibt Ihnen pro InfoCube die inQuerys verwendeten InfoObjects aus. Hierbei handelt es sich, wie bereitserwähnt, nicht um ein Standard-SAP-Programm, das Sie aber dennoch ohneAnpassungen implementieren können.



85

Geben Sie in der Selektionsmaske einfach den technischen Namen IhresInfoCubes ein, und starten Sie das Programm. Als Ergebnis erhalten Sie eineListe mit den verwendeten Query-Objekten (Abbildung 1.49). Diese könnenSie als Teil Ihrer Dokumentation ausdrucken oder sie z. B. in Excel überneh-men. Im zweiten Teil der Liste werden alle Navigationsattribute aufgelistet.Vergessen Sie diese bitte nicht bei der Analyse Ihres InfoCubes. Sie könnenauf diese Weise auch Ihre MultiProvider analysieren, auf denen Querys auf-gebaut sind.

Vergleichen Sie nun die im InfoCube modellierten Kennzahlen und Merk-male mit denen aus dem Verwendungsnachweis. Sie werden feststellen, dasseine ganze Reihe von Kennzahlen und Merkmalen nicht in der Query-Defi-nition verwendet, aber im InfoCube modelliert wurde. Im Rahmen der Ana-lyse notieren Sie bitte nur die »überflüssigen« Merkmale und Kennzahlen.Das eigentliche Remodellieren sollte erst nach der vollständigen Analyseerfolgen.

Virtuelle Kennzahlen und Merkmale

Virtuelle Kennzahlen und Merkmale sind nicht auf den ersten Blick zu iden-tifizieren. Da es sich hier um performancerelevante Objekte handelt, solltenSie sie besonders kritisch analysieren. Virtuelle Kennzahlen und Merkmalewerden erst zur Laufzeit der Query mit Leben gefüllt. Für die Analyse dieserKennzahlen müssen Sie in den User Exit für das Reporting schauen. NähereAngaben hierzu finden Sie in Abschnitt 2.3.7, »Virtuelle Kennzahlen undMerkmale«.

Abbildung 1.49 Ergebnisliste von »Z_REFERENCE_Q_OBJECTS«



86

Prinzipiell werden diese Objekte auch im Verwendungsnachweis aufgelistet.Sie können dort aber nicht erkennen, ob es sich um eine virtuelle Kennzahlhandelt. Analysieren Sie das Coding, und stellen Sie zusammen, aus welchenDatenquellen Ihre virtuellen Objekten befüllt werden. Auch Indizes und dieAnzahl an SELECT-Statements sind entscheidend.

Beachten Sie bitte, dass das Coding für jede Query durchlaufen wird. AmAnfang Ihrer Implementierung sollte also auf jeden Fall eine CASE-Anwei-sung stehen, die den beteiligten InfoCube abfragt (Listing 1.7).

*&-------------------------------------------------------*& Include ZXRSRU02*&------------------------------------------------------DATA: L_S_CHANM TYPE RRKE_S_CHANM.

CASE I_S_RKB1D-INFOCUBE.when 'INFUCUBE_NAME'.

L_S_CHANM-CHANM = '0MATERIAL'. " BezugsmerkmalL_S_CHANM-MODE = RRKE_C_MODE-READ.APPEND L_S_CHANM TO E_T_CHANM.

L_S_CHANM-CHANM = 'VK001'. " virtuelle KennzahlL_S_CHANM-MODE = RRKE_C_MODE-NO_SELECTION.APPEND L_S_CHANM TO E_T_CHANM.when others.

ENDCASE.

Listing 1.7 Beispielimplementierung für das Include »ZXRSRU02«

Das eigentliche Coding für das Füllen der virtuellen Kennzahlen und Merk-male finden Sie im Include ZXRSRZZZ. Eine beispielhafte Implementierungkann aussehen, wie in Listing 1.8 gezeigt.

*&--------------------------------------------------------*& Form USER_ICMP03*&--------------------------------------------------------* text*---------------------------------------------------------* -->I_S_RKB1D text* -->C_S_DATA text*---------------------------------------------------------FORM user_icmp03 USING i_s_rkb1d TYPE rsr_s_rkb1d

CHANGING c_s_data TYPE any.FIELD-SYMBOLS <l_material>.FIELD-SYMBOLS <l_knz_alt_material>.



87

ASSIGN COMPONENT g_pos_icmp03_ms1001OF STRUCTURE c_s_data TO <l_knz_alt_material>.ASSIGN COMPONENT g_pos_icmp03_0material OF STRUCTUREc_s_data To <l_material>.

SELECT single flag FROM z_matnr_sel INTO <l_knz_alt_material>where matnr = <l_material>.

ENDFORM. " USER_ICMP03

Listing 1.8 Beispielimplementierung für das Include »ZXRSRZZZ«

Weitere Beispiele für eine Implementierung finden Sie im SAP-System in derTransaktion CMOD (Erweiterungen) oder in der Beispielimplementierungzum BAdI (Business Add-In).

Virtuelle InfoProvider

Mussten Sie sich bei den anderen Reporting-Objekten nur wenig um dieDatenquellen kümmern, stehen diese bei der Analyse der virtuellen InfoPro-vider an erster Stelle. Ähnlich wie bei den virtuellen Kennzahlen und Merk-malen sind die Daten für die virtuellen InfoProvider nicht in InfoObjects imSystem gespeichert, sondern werden zur Laufzeit z. B. aus ERP-Tabellennachgelesen. Dieses kann auch über die RFC-Schnittstelle erfolgen. BeachtenSie bei der Analyse dieser Provider unbedingt die Laufzeiten zur Daten-beschaffung. Oft ist es hilfreich, sich eine Query nur für die Messung derLaufzeit anzulegen.

Aggregate

Betrachten Sie Ihre Aggregate auch als eigenständige Modellierungsobjekte!Sie sollten ihnen genau die gleiche Sorgfalt beim Analysieren widmen wieIhren InfoCubes. Aggregate stellen einen Ausschnitt der Daten Ihres Info-Cubes zur Verfügung, man kann sich ein Aggregat also wie einen kleinenInfoCube vorstellen. Die Daten werden physisch auf der Datenbank gespei-chert und stehen in aggregierter Form für die Analyse zur Verfügung. Siesollten auf jeden Fall die Aggregate identifizieren, die auch für das Reportingverwendet werden. Löschen Sie Aggregate, die nie für eine Query genutztwerden. Wie oft ein Aggregat bereits verwendet worden ist, können Sie inder Transaktion RSA1 in der Definition der Aggregate ablesen (Abbildung1.50). Wie Sie Aggregate effektiv definieren, erfahren Sie in Abschnitt 2.4.6,»Aggregate«.



88

Datenquellen/Speicherorte

Berücksichtigen Sie bei der Identifizierung der Reporting-Objekte auchderen Speicherplätze, denn es macht einen Unterschied, wie und wo IhreDaten im BW-System abgelegt sind. Bei der Analyse der Reporting-Objekteerwarten wir, dass die Daten möglichst schnell von der Datenbank gelesenwerden. Um dies zu erreichen, können Daten über SID-Schlüssel verknüpftabgelegt werden. Diese Form der indirekten Zuweisung finden Sie in IhrenInfoCubes und deren Aggregaten, in Stammdaten und Navigationsattributenund teilweise in DSOs, wenn diese mit SID-Schlüssel-Erzeugung angelegtsind.

Die direkte Zuweisung finden Sie, wenn Sie die Daten in ERP-Tabellen spei-chern oder z. B. in schreiboptimierten DSOs ablegen. Diese Form der Daten-speicherung hat jedoch den Nachteil, dass nicht über SID-Schlüssel gelesenwerden kann. Sie sollten für Ihre Reporting-Objekte immer die indirekteSpeicherung bevorzugen, da hier die Selektionszeiten der Datenbank undOLAP-Zeiten reduziert werden. Nur für kleinere Datenmengen, etwa für dasHinzulesen aktueller Daten aus einem ERP-System, sollten Sie eine direkteSpeicherung in Erwägung ziehen.

Da Sie in Ihrem Remodellierungsprojekt immer auf Daten und vorhandenenQuerys aufbauen, sollten Sie auch einen genauen Blick in die von SAP zurVerfügung gestellten Statistikdaten werfen. Dafür gibt es verschiedene Mög-lichkeiten. Sie können z. B. den im SAP-Content ausgelieferten Datenflussverwenden, um komplette Berichte über das Ladeverhalten und die Query-Nutzung zu erstellen. Diese Berichte werten dann die gesammelten Statistik-daten aus, die während der Query-Ausführung im BW-System gespeichertwerden.

BW-Statistik

SAP gibt Ihnen eine ganze Reihe von statistischen Informationen an dieHand. Nutzen Sie die zur Verfügung gestellten BW-Statistiken, um ganz

Abbildung 1.50 Verwendung einzelner Aggregate



89

gezielt Informationen aufzubauen und abzurufen. Wenn Sie sich den Auf-wand für die Einrichtung des BW-Contents sparen wollen, steht Ihnen dieTransaktion ST03N zur Verfügung. Mithilfe dieser Transaktion können Siez. B. leicht auswerten, welche Berichte in Ihrem BW-System am häufigstenverwendet werden. Eine ausführliche Erklärung dieser Transaktion findenSie in Abschnitt 1.4, »Technische Analyse und Bewertung von Query-Lauf-zeiten«.

Ziel der Analyse dieser Statistikdaten sollte es sein, sich einen genauen Über-blick darüber zu verschaffen, welche Berichte in den vergangenen Wochenoder Monaten besonders oft aufgerufen wurden oder bei welchen Berichtenes zu sehr langen Laufzeiten gekommen ist. An dieser Stelle sollten Sie wie-der eng mit der betroffenen Fachabteilung zusammenarbeiten. StimmenAussagen wie »Das sind unsere wichtigsten Berichte.« oder »Dieser Berichtläuft immer sehr lange.« mit den gesammelten Statistikdaten überein? Erstel-len Sie eine Liste mit Berichten, die Sie auf jeden Fall optimieren möchten,und identifizieren Sie die Berichte, die nicht geändert werden müssen. Sieerhöhen durch einen hohen Grad an Kommunikation auch die Akzeptanz fürdie Applikation.

Beschäftigen Sie sich an dieser Stelle Ihrer Analyse zudem damit, welcheBerichte überhaupt von der Fachabteilung aufgerufen werden. Oft habensich im Laufe der Jahre Dutzende Testberichte angesammelt, die nur im Ent-wicklungssystem existieren. Hier sollten Sie InfoProvider für InfoProvidervorgehen, um diese Berichte gegebenenfalls zu löschen.

1.5.2 Analyse und Bewertung der identifizierten Objekte

Nachdem Sie sich einen genauen Überblick über die verwendeten Objektegemacht haben, sollten Sie diese nun bewerten. Das kann am besten in einerMatrix erfolgen, in der Sie jedes Objekt auflisten und hinsichtlich Perfor-mance, Speicherbelegung und tatsächlicher Verwendung in Querys bewer-ten. Folgende Fragen dürfen Sie nicht außer Acht lassen:

� Welches sind die wichtigsten Kennzahlen und Merkmale?

� Welche Merkmale bzw. Kennzahlen lassen sich in die Stammdaten aus-lagern?

Wie Sie die einzelnen Objekte hinsichtlich ihrer Performance beurteilen,sehen Sie in Tabelle 1.4.



90

Speicherung von Kennzahlen

Auch wenn es auf den ersten Blick ungewöhnlich erscheint: Sie könnenKennzahlen nicht nur in der Faktentabelle des InfoCubes, sondern, wenn essich um Konstanten handelt, auch in den Stammdatentabellen abspeichernund über die Formelvariablen für das Reporting verfügbar machen. Analysie-ren Sie daher jede Kennzahl dahingehend, ob es sich um eine zeitlich verän-derbare Größe handelt oder um eine Konstante wie z. B. den aktuellenSicherheitsbestand für ein Material, der sich über Jahre nicht verändert. DerVorteil für die Speicherung in den Stammdatentabellen liegt auf der Hand.Sie vermeiden redundante Datenhaltung in Ihrem BW-System, da Sie nichtbei jedem Ladezyklus die gleichen Daten abspeichern, und Sie erhöhen diePerformance Ihrer Berichte, da diese dann auf eine kleinere Faktentabellezugreifen. Folgende Eigenschaften und Speicherorte von Kennzahlen solltenSie daher kennen und mit in Ihre Analyse einbeziehen:

� Speicherung von Kennzahlen im InfoCube in der Faktentabelle

� aggregierte Kennzahlen in Aggregaten

� Kennzahlen mit konstanten Ausprägungen in den Stammdaten

� Zähler für Ausprägungen, z. B. Anzahl der Belege als Formelvariablen imQuery Designer

Analyse der Zeitabhängigkeit von Stammdaten

Nutzen Sie die vorhandenen Daten, um zu überprüfen, ob es sich um zeitab-hängige oder zeitunabhängige Stammdaten handelt. Leider lassen sich nurschwer generelle Regeln dafür aufstellen, ob ein Merkmal in die Dimension

Objekt Performance

MultiProvider kein Einfluss auf die Performance

InfoCube modellierungsabhängig

DSO schlecht

virtueller Provider von der Anzahl der Daten und der Anzahl eventueller RFC-Zugriffe abhängig

InfoObject modellierungsabhängig

InfoSet eher schlecht

ERP-Tabelle wie DSO eher schlecht

Tabelle 1.4 Performanceeigenschaften von Reporting-Objekten



91

eines InfoCubes gehört oder als Navigationsattribut zur Verfügung gestelltwerden sollte. Daher sollten Sie für eine Entscheidung auf jeden Fall fol-gende Fragen beantworten:

� Sollen historische oder aktuelle Wahrheiten oder beide abgebildet werden?

� Wie hoch sind die verschiedenen Ausprägungen der Merkmale?

� Wie oft werden Merkmale in Querys verwendet?

In der Praxis zeigt sich, dass nur ein Viertel der vorhandenen Merkmale ineinem InfoCube wirklich für das Reporting genutzt wird. Der Rest ist oftdurch eine zu große Dimensionierung in den InfoCubes modelliert wordenund kann in Navigationsattribute ausgelagert werden, ohne dass Sie die Fle-xibilität Ihres Datenmodells verlieren. In Abschnitt 2.1, »Planung der Maß-nahmen«, zeige ich Ihnen dann, wie Sie diese Informationen nutzen, um einschlankes Datenmodell zu entwerfen.

Indizes auf Stammdatentabellen

Neben den von SAP angelegten Indizes kann es auch notwendig sein, eigeneIndizes auf den Stammdatentabellen anzulegen, um einen performanterenZugriff auf diese Daten zu erreichen. Analysieren Sie deshalb die vorhande-nen Merkmale in Ihren Stammdaten, um zu entscheiden, bei welchen es sichlohnt, zusätzliche Indizes anzulegen. Hilfsprogramme können Sie bei derAnalyse der unterschiedlichen Ausprägungen in Ihren Stammdatentabellenunterstützen. Nutzen Sie zum Beispiel das im Anhang gelistete ProgrammZ_STAT_MASTER_DATA für die Ermittlung der Ausprägungen in IhrenStammdatentabellen. Geben Sie in die Selektionsmaske des Programms daszu analysierende Stammdaten-InfoObject ein (Abbildung 1.51), und führenSie es aus.

Als Ergebnis erhalten Sie eine Liste mit den unterschiedlichen Ausprägungeninnerhalb der Stammdatentabelle (Abbildung 1.52).

Abbildung 1.51 Selektionsmaske des Programms Z_STAT_MASTER_DATA



92

Wenn Sie einen eigenen BW-Namensraum nutzen, müssen Sie das Pro-gramm entsprechend anpassen. Folgende Zeile müssen Sie ändern:

CONCATENATE '/BIC/M' p_iobj into l_tab_name.

Dabei ist /BIC/ der von Ihnen in der Transaktion RSNSPACE gewählte bzw.voreingestellte Namensraum (Abbildung 1.53). Achtung: Führen Sie das Pro-gramm nur für InfoObjects aus, die auch Stammdaten haben, weil naturge-mäß nur diese InfoObjects auch Stammdatentabellen besitzen und es ansons-ten zu einem Programmabbruch kommt.

1.5.3 Statistische Verteilung der Daten im InfoCube

Das für die Reporting-Anforderungen am besten ausgelegte Objekt ist derInfoCube. Durch sein erweitertes Sternschema können hier auch Millionenvon Datensätzen innerhalb weniger Sekunden ausgelesen und dem OLAP-

Abbildung 1.52 Ergebnisliste des Programms Z_STAT_MASTER_DATA

Abbildung 1.53 Namensräume in Transaktion RSNSPACE



93

Prozessor zur Bearbeitung übergeben werden. Der technische Aufbau einesInfoCubes wird in Abschnitt 4.1.1, »Technische Strukturen eines InfoCubes«,beschrieben.

Sie sollten Ihrem InfoCube bei der Analyse die größte Aufmerksamkeitschenken, weil hier der größte Einfluss auf die Performance Ihrer Berichteauszumachen ist. SAP stellt Ihnen für die Analyse einen ganzen Werkzeug-kasten zusammen, den Sie in der Transaktion RSRV (Analyse und Reparaturvon BW-Objekten) finden. Eine ausführliche Dokumentation dieser Transak-tion finden Sie im Internet unter http://help.sap.com. Im ersten Schritt solltenSie sich mithilfe der Transaktion LISTSCHEMA einen Überblick über denAufbau Ihres InfoCubes verschaffen (Abbildung 1.54).

Geben Sie in der Selektionsmaske den technischen Namen Ihres InfoCubesein, oder verwenden Sie die Wertehilfe ((F4)). Führen Sie die Transaktionaus. Im Ergebnis erhalten Sie eine grafische Darstellung der Zuordnungeninnerhalb der Faktentabelle (Abbildung 1.55).

Abbildung 1.54 Einstiegsbild der Transaktion LISTSCHEMA

Abbildung 1.55 Ausgabeliste der Transaktion LISTSCHEMA



94

Diese Darstellung des strukturellen Aufbaus eines InfoCubes ist eine aus denTabellen der InfoCube-Definition abgeleitete hierarchische Darstellung. Siezeigt Ihnen die Faktentabelle und die zugehörigen Dimensionstabellen an.Klicken Sie mit dem Cursor auf die zu analysierende Tabelle, in unserem Bei-spiel auf die Zeile /BI0/D0CSAL_C031; diese Tabelle entspricht der erstenDimension. Klicken Sie auf das Brillen-Icon. So gelangen Sie automatisch indie Transaktion SE12 (ABAP-Dictionary-Anzeige), die in Abbildung 1.56 zusehen ist.

Im erweiterten Sternschema bestehen die Dimensionstabellen nur aus SID-Einträgen, die ihrerseits auf die Stammdatentabellen verweisen. VerzweigenSie nun über den Button Indizes in die Darstellung der Indizes. In Abbildung1.57 sehen Sie den Aufbau des Index für die analysierte Datenbanktabelle.

Abbildung 1.56 Dimensionstabelle zur Dimension »Geschäftspartner«

Abbildung 1.57 Index zur Dimensionstabelle »Geschäftspartner«



95

Indizes im erweiterten Sternschema

Die wichtigsten von SAP standardmäßig zur Verfügung gestellten Indizessollten Sie nutzen, um ein performantes Leseverhalten Ihrer InfoCube-Datenzu ermöglichen. Für das Lesen der Daten auf der Datenbank ist es nun vongroßer Bedeutung, wie dieser Index aufgebaut ist und in welcher Reihen-folge die einzelnen Felder eingetragen sind.

Der Datenbankindex lässt sich für gefüllte InfoCubes mit der TransaktionDB05 (Analyse einer Tabelle bezüglich des Index) weiter analysieren. TragenSie im Selektionsbild den Namen der zu untersuchenden Tabelle ein, undführen Sie die Transaktion für kleinere InfoCubes direkt aus. Entfernen Siedazu das Häkchen im Kästchen Submit Analysis in Background. Hier kön-nen Sie am besten die Faktentabelle Ihres InfoCubes untersuchen, zu erken-nen am F im Namenspräfix. Sollten Sie mit komprimierten InfoCubes arbei-ten, müssen Sie das F durch ein E im Namen der Tabelle ersetzen, da hier dieDaten in der sogenannten E-Faktentabelle gespeichert (komprimiert) sind.

Im Idealfall ist die Verteilung der einzelnen Einträge ansteigend; dies gilt fürdie Faktentabelle, aber auch für die Daten in den einzelnen Dimensionen.Stellen Sie sich diese Verteilung am besten wie eine Treppe vor (Abbildung1.58).

Das hier dargestellte Stufenmodell des InfoCube-Designs ist der Schlüssel zuperformanten Querys. Mithilfe dieser Modellierung erhalten Sie eine opti-male Verteilung Ihrer Daten im InfoCube, um optimale Datenbankzugriffezu gewährleisten. Dabei spielt es keine Rolle, ob es sich bei den Dimensio-nen um Line-Item-Dimensionen handelt oder um »normale« Dimensionen.Wichtig ist in jedem Fall, dass die hohen Ausprägungen ans Ende der Info-

Abbildung 1.58 Stufenmodell des InfoCube-Designs

Dimensionen innerhalb der Faktentabelle

Anzahl der Ausprägungen innerhalb der Dimensionen

Dimension 6: 1.000.000 Datensätze

Dimension 5: 10.000 Datensätze

Dimension 4: 1.000 Datensätze

Dimension 3: 100 Datensätze





96

Cube-Definition gestellt werden. Eine derartige Modellierung kann erst seitSAP NetWeaver BI 7.0 verwirklicht werden, da Sie durch die neu gestalteteWorkbench einen direkten Einfluss auf die Reihenfolge der Dimensionenund deren Inhalte haben.

Innerhalb der einzelnen Dimensionen sollten Sie nach dem gleichen Schemavorgehen und Merkmale mit vielen Ausprägungen ans Ende stellen. DieseSortierung können Sie auch für die von SAP gestalteten Dimensionen, z. B.die Zeitdimension, vornehmen. Hierfür empfiehlt es sich, z. B. den Kalender-tag ans Ende zu stellen. Wie Sie dabei genau vorgehen sollten, wird ausführ-lich in Abschnitt 2.1, »Planung der Maßnahmen«, behandelt.

Oft werden Dimensionen nach betriebswirtschaftlichen Gesichtspunkten zu-sammengestellt. So kann es schon mal passieren, dass Material und Kunde,die in einer n:m-Beziehung stehen, in einer Dimension auftauchen. Sie kön-nen jetzt jede Ihrer Dimensionstabellen analysieren und die Anzahl der Ein-träge ermitteln. Oder Sie nutzen das im Anhang mitgelieferte Analyse-programm Z_CUBE_STAT, mithilfe dessen Sie leicht die komplette statis-tische Verteilung der Daten in Ihren InfoCubes ermitteln können.Implementieren Sie das Programm, wie im Anhang beschrieben. Rufen Siedann das Programm auf, tragen Sie den technischen Namen des InfoCubes inder Selektionsmaske ein (Abbildung 1.59), und führen Sie das Programm aus.

Im Ergebnis erhalten Sie eine Liste der einzelnen Dimensionen und die darinenthaltenen InfoObjects. Entscheidend für Ihre Analyse ist hierbei die Spaltemit den Einträgen auf der Datenbank. Die folgenden Abbildungen zeigenIhnen exemplarisch, wie ein Analyseergebnis aussehen kann. Abbildung1.60 zeigt eine schlecht gestaltete Dimension: Die Summe der Einträge aufder Datenbank (Zeile DIMID) ist sehr viel größer, als die größte Einzelzeile(hier 0MOVETYPE) ausweist.

Abbildung 1.61 hingegen zeigt eine besser modellierte Dimension: DieSumme der Einträge (Zeile DIMID) ist nur wenig höher als die größte Einzel-zeile, 0VENDOR. Zudem stehen hier die Einträge in einer aufsteigenden Rei-henfolge.

Abbildung 1.59 Selektionsbild des Programms Z_CUBE_STAT



97

Da Sie in einem Remodellierungsprojekt immer schon Daten in Ihren Info-Cubes vorfinden, sollten Sie diese wie beschrieben auch für die Analyse nut-zen. Wie Sie den »idealen«, weil schlanken InfoCube erstellen, wird ausführ-lich in Abschnitt 2.1, »Planung der Maßnahmen«, beschrieben.

1.5.4 Analyse von DSOs

Sie können Daten für das Reporting auch in DSOs zur Verfügung stellen.Diese sind unter Performancegesichtspunkten jedoch nicht ideal für dasReporting, da hier die Daten nicht im Sternschema abgelegt sind, sondern inrelationalen Datenbanktabellen. Sie haben deshalb nicht den in Abschnitt1.5.3, »Statistische Verteilung der Daten im InfoCube«, beschriebenen Vor-teil der Datenbankindizes. Bei der Analyse der DSOs ist es deshalb besonderswichtig, dass Sie auf die Indizes schauen. Legen Sie Indizes für dieses Objektaus der Administrator Workbench (Transaktion RSA1) heraus an und nichtdirekt auf der Datenbank, da diese auf der Datenbank für den Administratornicht ersichtlich sind. Für die Analyse müssen Sie aber in jedem Fall auch aufder Datenbank nachschauen, ob zusätzliche Indizes angelegt wurden, weildiese nicht in der Transaktion RSA1 ersichtlich sind. Fragen Sie hierzu einen

Abbildung 1.60 Schlechte Verteilung innerhalb eines InfoCubes

Abbildung 1.61 Bessere Verteilung innerhalb einer Dimension



98

Kollegen von der Datenbankadministration, oder nutzen Sie die Transaktio-nen zur Datenbankanalyse (je nach Datenbanksystem sehen diese unter-schiedlich aus). Informieren Sie sich im Internet unter http://help.sap.comüber die für Ihr Datenbanksystem richtigen Transaktionen und deren Aus-führung.

Sie können die Verteilung Ihrer Daten im DSO auch analysieren, um danneinen InfoCube aus den Daten zu gestalten. Analysieren Sie hierzu dieAnzahl der verschiedenen Einträge in der Datenbanktabelle. Analog zumAnalyseprogramm für InfoCubes können Sie das im Anhang gelisteteHilfsprogramm Z_ODS_STAT nutzen. Dieses gibt Ihnen für jedes InfoObjectinnerhalb Ihres DSOs die Anzahl der verschiedenen Einträge wieder.

Als Ergebnis können Sie ablesen, in welchen Objekten Daten mit hoherunterschiedlicher Ausprägung gespeichert sind. Wollen Sie aus Designgrün-den aus Ihrem DSO einen InfoCube modellieren, gehen Sie wie in Abschnitt2.4.1, »InfoCube-Modellierung«, beschrieben vor, und modellieren Sie nachtechnischen Gesichtspunkten, um das hier beschriebene Stufenmodell zurealisieren. Unter Umständen müssen Sie einmal im produktiven SystemDaten in Ihren so gestalteten InfoCube laden, um das Programm Z_CUBE_STAT benutzen zu können.

Im Idealfall erstellen Sie aus den so gewonnenen Daten eine Matrix, die diejeweiligen Ausprägungen des DSOs zueinander in Relation setzt. Aus diesenInformationen können Sie dann ablesen, welche Merkmale in einer Dimen-sion zusammengefasst werden können.

1.5.5 Aufwand für Pflege und Wartung von Reporting-Objekten

In den vorangegangenen Abschnitten haben wir uns eher mit der quantitati-ven Analyse der verwendeten BW-Objekte beschäftigt, und nun gehe ich aufdie Analyse des zeitlichen Aufwands für Pflege und Wartung ein. Dabeispielt im letzten Teil dieses Abschnitts auch die Administration von Prozess-ketten eine Rolle. Da diese meist erst am Ende einer Projektphase angelegtwerden, wird oft aus Zeitmangel auf eine eingehende Konzeptionierung ver-zichtet.

Achtung!

Führen Sie dieses Programm unbedingt im Hintergrund aus, da es zu einer langenLaufzeit kommen kann.



99

Wartungsaufwand für Reporting-Objekte

Schon bei der Modellierung, spätestens aber bei der Analyse oder Überarbei-tung eines Datenmodells, sollten Sie den Aufwand für Pflege und Wartungbeurteilen. Am Anfang dieser Analyse klassifizieren Sie Ihre Objekte in zweiGruppen: wartungsintensive und wartungsarme Objekte.

Wartungsintensive Objekte

Wartung und Pflege und damit administrativer Aufwand treten immer dortauf, wo Sie eine physische Speicherung von Daten vornehmen. Die betref-fenden Objekte sind:

� Stammdaten (Attributsänderungsläufe, Indexpflege)

� Standard-DSO (Aktivieren der Daten)

� schreiboptimiertes DSO (Speicherplatz)

� InfoCube (Komprimieren, Index und Statistik pflegen)

� Aggregat (Hochrollen)

Die in Klammern beschriebenen Vorgänge sind die Wartungsaufgaben fürdie einzelnen Objekte und werden im Folgenden näher erläutert.

� Wartungsaufgaben bei Stammdaten und deren AttributenNeben den Bewegungsdaten, die Sie in DSOs und InfoCubes speichern,nehmen die Stammdaten in Ihrem BW-System eine wichtige Rolle ein.Dabei gilt der Grundsatz, dass nur aktuelle und vollständige Stammdatenvom Endanwender akzeptiert werden. Wenn Sie die Wahl haben, einenFull Upload in 60 Minuten durchzuführen und alternativ einen Delta-Upload in zehn Minuten, sollten Sie sich aus Gründen der Verlässlichkeitder Daten immer für den zeitaufwendigeren Full Upload entscheiden,weil Sie dann mit korrekten Daten für Ihre Stammdaten rechnen können.Oft werden nämlich kundeneigene Felder nicht vom Delta-Mechanismusberücksichtigt, und um nicht jedes Feld testen zu müssen, sollten Sie sichaus praktischen Erwägungen für den Full Upload entscheiden.

Analysieren Sie, wie oft während eines Ladezyklus der Attributsände-rungslauf läuft und zu welchen Zeiten. Dies ist wichtig, weil aus techni-schen Gründen immer nur ein Attributsänderungslauf zur gleichen Zeiterfolgen kann. Abhilfe schafft hier ein zentraler Änderungslauf am Endeeines Ladezyklus, in dem Sie alle geänderten Stammdaten sammeln.



100

� Wartungsaufgaben bei InfoCubesIhr zentrales Reporting-Objekt, den InfoCube, sollten Sie mit großer Sorg-falt bei der Administration behandeln. Die wesentlichen Gesichtspunktezur Verbesserung des Leseverhaltens sind, neben einem schlanken Daten-modell, das Komprimieren, Indizes und die Datenbankstatistik. Bestim-men Sie auch, ob und wie Ihre Faktentabelle partitioniert ist. Diese Ana-lyse können Sie bequem aus der Administrator Workbench Ihres BW-Sys-tems vornehmen (Transaktion RSA1).

Die Einstellungen für Indizes, das Komprimieren und die Datenbanksta-tistik steuern Sie am besten über Prozessketten. Generell sollten Sie beimDatenladen folgende Reihenfolge für Ihre InfoCubes einhalten:

1. Index löschen

2. Daten laden

3. Index aufbauen

4. Datenbankstatistik aufbauen

5. Initiales Befüllen von Aggregaten

6. Hochrollen von Aggregaten

7. InfoCube komprimieren

Wartungsarme Objekte

Objekte, die keine physische Datenablage haben, sondern nur Strukturinfor-mationen beinhalten, können Sie gesondert bewerten. Dies sind:

� MultiProvider

� InfoSets

Beachten Sie bei der Analyse unbedingt die Verknüpfungseigenschafteninnerhalb dieser Objekte. In MultiProvidern werden die Daten immer übereine Union-Operation zusammengefasst. In InfoSets können Sie dagegenJoin-Beziehungen definieren. Union-Operationen sind keine Join-Beziehun-gen, sondern addieren die beteiligten Tabellen.

Mit einem Beispiel möchte ich den Unterschied zwischen MultiProvider(Union-Operation) und InfoSet (Join) veranschaulichen. In den Tabellen 1.5und 1.6 sehen Sie die Daten der an dem MultiProvider beteiligten InfoCubes.



101

Wie Sie in Tabelle 1.7 sehen können, werden die Ergebniszeilen getrenntdargestellt.

Es ist nicht möglich, Bestelldaten und Rechnungsdaten in einer Zeile darzu-stellen. Dieses gelingt nur bei der Verknüpfung der beiden InfoCubes mit-hilfe eines InfoSets (Tabelle 1.8).

Eine Ausnahme sind homogene MultiProvider, die zwei gleiche InfoCubesmiteinander verknüpfen. Hier ist die Ergebnismenge mit einem Join-Ergeb-nis vergleichbar, und die Ergebnisse aus beiden InfoCubes werden Ihnenauch auf einer Zeile angezeigt.

Zeitplanung von Prozessketten

Pflegeaufwand bedeutet vor allem auch zeitlichen Aufwand, der in ersterLinie während des Ladens der Daten auftritt. Deshalb empfiehlt es sich, einabgestimmtes Zeitmanagement für Ihre Prozessketten einzuführen. Diesgelingt aber nur durch eine Analyse der vorhandenen Prozesse. Für die

Werk Material Bestellnummer Bestellwert

InfoCube 1 0001 4711 120001 100,00

Tabelle 1.5 Daten von InfoCube 1

Werk Material Rechnungsnummer Rechnungs-wert

InfoCube 2 0001 4711 300001 110,00

Tabelle 1.6 Daten von InfoCube 2

Werk Material Bestell-nummer

Bestell-wert

Rechnungs-nummer

Rechnungs-wert

0001 4711 120001 100,00 – –

0001 4711 – – 300001 110,00

Tabelle 1.7 Ergebnis für einen MultiProvider

Werk Material Bestell-nummer

Bestell-wert

Rechnungs-nummer

Rechnungs-wert

0001 4711 120001 100,00 300001 110,00

Tabelle 1.8 Ergebnis für ein InfoSet (Join)



102

Gestaltung der Prozessketten ist es hilfreich, wenn Sie sich ein Konzept inForm eines Flowcharts anlegen. Unterteilen Sie dabei drei Ebenen:

� Masterketten

� Metaketten

� Basisketten

Mit diesen drei Ebenen haben Sie genug Gestaltungsspielraum, um Ihre Pro-zessketten zu gliedern. Eine Masterkette steuert dann alle Metaketten einerApplikation, während die Metaketten wieder mehrere Basisketten zusam-menfassen.

Stamm- und Bewegungsdaten sollten Sie konzeptionell trennen, um dieMöglichkeit zu haben, Ihre Bewegungsdaten unabhängig von den Stammda-ten zu laden. Generell sollten Sie immer erst die Stammdaten und dann dieBewegungsdaten laden. So verlagert sich die zeitaufwendige Ermittlung derSID-Schlüssel auf das Laden der Stammdaten, also in einen von SAP opti-mierten Prozess. Sollte es in Ihrem Unternehmen eine zentrale Stelle zur Ein-planung von Prozessketten geben, modellieren Sie am besten zwei zentraleMasterketten, in denen Sie alle Stamm- und alle Bewegungsdaten-Metaket-ten zusammenfassen. Im Fall eines Abbruchs können Sie dann die abgebro-chenen Teilprozesse wieder anstarten, ohne die gesamte Kette noch einmalstarten zu müssen.

Auch bei den Prozessketten ist es sinnvoll, sich schon während der Konzep-tion des Flowcharts eine Namenskonvention für das spätere Anlegen derKetten zu überlegen. Beachten Sie hierbei, dass Sie neben dem technischenNamen immer auch eine Beschreibung angeben müssen. Sie können zumBeispiel für die technischen Namen folgende Syntax verwenden:

� Für die ProzesskettenHier empfehle ich eine Syntax, die sich aus TYP_ART_PROZESS zusammen-setzt. Dabei können Sie den Typ als MASTER, META oder BASIS bestimmen.Die Art der Prozessketten teilt sich dann in MD (Stammdaten) oder MOVE(Bewegungsdaten), und der Prozess wird als LOAD_ALL etc. angegeben.Einige Beispiele:

� MASTER_MD_LOAD_ALL = Laden der Stammdaten für alle Applikationen

� BASIS_MOVE_MM_PURCH = Laden der Bewegungsdaten für den Einkauf

Durch die Einhaltung einer solchen Syntax werden die Anlage und Ver-waltung der Prozessketten wesentlich erleichtert.



103

� Für die einzelnen Prozesse innerhalb der ProzessketteHier können Sie folgende Syntax verwenden:

� ...CREATE_INDX für den Aufbau eines Datenbankindex

� ...DROP_INDX für das Löschen eines Index

� ...ROLL_AGG für den Aufbau eines Aggregats

� ...LOAD_DATA für den Datenladeprozess

Archivierung von Daten

Als Ergänzung zur Analyse des Speicherplatzes Ihrer physischen Datenabla-gen sollten Sie auch bei der Analyse schon an eine mögliche Datenarchivie-rung denken. In der Regel archivieren Sie Daten aus Ihren Bewegungsdaten-speichern, z. B. InfoCube oder DSO. Stammdaten werden für gewöhnlichnicht archiviert.

Um schon während der Modellierung der Daten eine spätere Archivierungzu planen, stimmen Sie mit den beteiligten Fachabteilungen ab, wie langebeispielsweise Detaildaten zur Verfügung stehen müssen. Ein Zeitraum vonzehn Jahren für Detaildaten auf Belegebene kann schnell zu einer Ver-schlechterung der Performance führen, weil damit das Datenvolumen inner-halb eines Detail-InfoCubes sehr groß wird.

Analysieren Sie, in welche »Datenscheiben« (Partitionen) Sie Ihre Datenschneiden können. Diese Partitionen können Sie dann während der Remo-dellierung Ihrer InfoCubes berücksichtigen. Wir sprechen dann von physi-scher Partitionierung, da Partitionen physisch auf der Datenbank angelegtwerden. Eine andere Möglichkeit ist die logische Partitionierung, bei der Siezeitliche Partitionen bilden, indem Sie einen InfoCube für zum Beispiel zweiJahre gestalten und nur Bewegungsdaten dieser zwei Jahre in diesen Info-Cube laden. Für die Query-Performance ist es dann entscheidend, dass Sieeine zeitliche Selektion in der Query mit berücksichtigen, weil so das Lesender Daten auf die richtige logische Partition geleitet wird.

1.5.6 Erweitern von Reporting-Objekten

In diesem Abschnitt beschäftigen wir uns mit der Erweiterung von Repor-ting-Objekten. Dabei ist es nicht von Bedeutung, ob es sich um von SAPausgelieferte Content-Objekte handelt oder um selbst erstellte Objekte. Siesollten nie die Eigenschaften von Objekten einschränken; Erweiterungenhingegen sind oft möglich, ohne das Datenmodell gravierend anpassen oderDaten neu laden zu müssen.



104

Beachten Sie, dass Sie die Eigenschaften Ihrer Objekte in der Regel ändernkönnen, wenn diese Änderungen nicht direkt Einfluss auf die Speicherungder Daten nehmen. Bei Änderungen von gefüllten Datenbanktabellen ist esimmer notwendig, diese Tabellen technisch umzusetzen. Sie können deshalbkeine Änderungen an der Reihenfolge innerhalb der Dimensionen vorneh-men, weil eine Tabellenumsetzung mit Daten dies nicht zulässt. Eine Erwei-terung ist technisch möglich, führt aber in der Regel dazu, dass Ihnen Datenfür die Historie fehlen. Fehlt Ihnen ein InfoObject im InfoCube, prüfen Siezuerst, ob Sie diese Information über ein Navigationsattribut zur Verfügungstellen können. Dies gelingt auch, wenn Sie schon Daten in Ihren InfoCubegeladen haben. Dabei dürfen Sie natürlich nicht die historische und die aktu-elle Wahrheit vernachlässigen.

Änderungen an MultiProvidern sind am einfachsten durchzuführen, da essich hier um Strukturinformationen handelt. Beachten Sie hier jedoch auchden oben angeführten Grundsatz der Erweiterung von Objekten, weil dieQuerys sonst nicht mehr aufrufbar sind. Nach Änderungen an Ihren Multi-Providern kommt es in Querys zu Meldungen, dass sich die Strukturen desInfoProviders geändert haben. Diese Meldungen sind lediglich Informatio-nen, die nur einmalig aufgerufen werden. Dennoch ist es wichtig, dass Sieauch Ihre Anwender auf die Möglichkeit solcher Informationsmeldungenhinweisen, da es ansonsten nach der Änderung an Ihren MultiProvidern zuRückfragen kommt.

Änderungen an InfoObjects lassen sich schnell realisieren. Im Anhang findenSie eine Tabelle, die auflistet, welche Änderungen an InfoObjects in einemproduktiven System zulässig sind, ohne dass bereits bestehende Daten verlo-ren gehen oder andere Applikationen gestört werden.

Erweiterungen von InfoCubes

Wenn Sie einen InfoCube erweitern möchten, gehen Sie am besten wie inAbschnitt 3.2, »Remodellierung in der klassischen Variante«, und Abschnitt3.3, »Remodellierung mit dem SAP-Tool«, beschrieben vor. So retten Sie IhreDaten im InfoCube und müssen sie nicht erneut aus dem Quellsystem extra-hieren, denn das könnte unter Umständen zu Problemen führen, wenn dieDaten nicht mehr vorhanden sind. Befinden sich bereits Daten im InfoCube,bleibt Ihnen nur die Möglichkeit, zusätzliche Navigationsattribute zu benen-nen. Achten Sie bitte darauf, dass Sie gegebenenfalls auch Ihre Aggregateanpassen müssen. Alle anderen Änderungen, die zu Änderungen der Daten-bankstrukturen führen, sind nicht im laufenden Betrieb, d. h. nicht mitgefüllten InfoCubes möglich.


265

Index

A

Abnahmetest 173Abweichungsanalyse, manuelle 51Administration 29Administrator 209Administrator Workbench 19, 97, 100Aggregat 27, 29, 75, 80, 99, 240

Aufbau 210Bewertung 80Definition 80, 87, 158Festwert 162Index 160InfoCube-Modellierung 181Modellierung 87Monitoring 154Query-Laufzeit 81Transportobjekt 191

AggregationEbene 83Schicht 36

AnalysePhase 106Sicht 78

Anreicherungsschicht 36Antwortzeit 16, 26Applikationsserver 22, 163Archivierung 103Attribut 199Attributsänderungslauf 29, 99, 238Auftrag entsperren 193Aufwand, administrativer 29, 34, 237Ausfallzeit 31Ausnahme-Aggregation 135, 136

B

Backend 65Backup 31Basiskette 102Bedienbarkeit 27, 28Benchmarking 22, 34, 47, 70, 82Berechtigung 238

fehlerhafte 52

Berechtigung (Forts.)für das Reporting 52Rolle 218

BerichtLayout 28Monitor 26operativer 82Performance 34, 70, 133, 237Schicht 36strategischer 82

Betriebssystem 22Bewegungsdaten 29, 84, 102Bewertung 24, 28

Datenmodell 34Kriterien 22, 23, 27, 29, 34, 70Matrix 30

Business Content 18Änderung 21Version 19

BW-ApplikationAusfallzeit 31Bedienbarkeit 27Bewertung 22Lebenszyklus 15ROI 33

BW-Icon 42BW-Objekt 19

C

Central Processing Unit 22Change and Transport Organizer 185Change Request 33CMOD 87, 140, 144Code Inspector 173Content-Version 21CPU 22CTO 185

D

Data Browser 25Data Dictionary 113


266

Index

Data Transfer Process � DTPDataMart-Schicht 36DataSource 239

Real-Time 55DataStore Object � DSODaten

Abweichung 24Archivierung 103laden 45Qualität 16, 23, 30, 34, 50, 82, 237Quelle 88Zuverlässigkeit 23

Datenabgleich 50, 56DSO 65manueller 50technischer 56

Datenablage, redundante 56Datenbank 21

Anfrage 78Cursor 69Index 78Parameter 72Server 22Statistik 79View 25

Datenbestand, inkorrekter 37Datenfluss 35, 39, 40

Analyse 44Darstellung 41

Datenhaltung 39, 42Datenmodell 16, 34, 39, 71, 237

Abhängigkeiten 43ändern 32bewerten 34, 47lineares 37, 38migrieren 18, 239nicht-lineares 37Schichtenmodell 35schlankes 91, 146Transport 31, 32Visualisierung 41

DatenproviderDSO 152InfoObject 153

Datensatzdoppelter 52fehlender 53

DB05 95, 202, 216DB-Connect 120, 121

DBSEL 27DBTRANS 27, 75DDIC 113Delta-Upload 99Dialogprozess 72Dimensionstabelle 96, 201DO-ENDO-Schleife 68Dokumentation 34

Transformation 44Drilldown 133, 139DSO 32, 97, 202, 239

Aktivierung 188Analyse 97Aufbau 203Daten nachlesen 124Datenabgleich 65Datenanalyse 53Datenmodelländerung 32Datenprovider 152Datensätze zählen 135Index anlegen 153InfoProvider 83Ladeprozess 37Nachlesen 43, 206Namenskonvention 111Schlüsselfelder 208schreiboptimiertes 99SID-Schlüssel 88Transportobjekt 192Vergleichsprogramm 57

DTP 36, 45, 111, 124, 179

E

Eigenentwicklung 19, 35Eingangsschicht 36Eingangsstruktur 48Einkaufsanwendung 164Einzelbeleginformation 147Endroutine 122Entwicklungstest 171Ersetzungspfad 135ETL 36Event 234Expertenroutine 127Extract, Transform, Load 36Extraktor 53


267

Index

F

Faktentabelle 24, 25, 49, 90, 163, 200Fehlerquelle 51Feldsymbol 222Feldzuweisung 54FETCH NEXT CURSOR 69FILE 233Flat-File 120, 232Flowchart 102Formelvariable 133Full Upload 99Funktionsbaustein 226, 227

CHECK_EXIST_LIMU_FUNC 228CONVERSION_EXIT_*****_INPUT 227CONVERSION_EXIT_*****_OUTPUT

227DATE_GET_WEEK 229finden 230RSPC_API_CHAIN_START 228

G

Gruppe, semantische 111

H

HardwareEinsatz 22Entwicklung 21

Harmonisierungsschicht 36Hauptspeicher 22, 67Hilfsmittel, technisches 16, 241Hilfsprogramm 241

I

Implementierung 106, 170Index 91InfoCube 76, 239

Aggregat 75, 80, 87, 158Aktivierung 188Analyse 97Datenbankstatistik 79Datenfluss 39

InfoCube (Forts.)Dimension 148Einkauf 48Faktentabelle 24, 25, 163, 200Fehleranalyse 53historische Wahrheit 55Index 95, 201Kennzahl hinzufügen 184Komprimierung 25kopieren 177Ladereihenfolge 100Ladeverhalten 210Ladezeit 48logische Partitionierung 103Merkmal hinzufügen 183Modellierung 145, 181Navigationsattribut 91Releasewechsel 18Remodellierung 32, 179, 181statistische Verteilung 92Struktur 200Stufenmodell 95Transaktion LISTSCHEMA 202Transportobjekt 191Verwendungsnachweis 84, 85virtuelle Kennzahlen und Merkmale 86Währungsumrechnung 54Wartungsaufgaben 100

InfoObject 19, 239Aktivierung 188aktuelle Wahrheit 55, 104Ausnahme-Aggregation 135Conversion Exit 227Datenmodell 42Datenprovider 153Dokumentation 84erlaubte Änderung 32, 104, 259historische Wahrheit 104Katalog 83Namenskonvention 110Stammdaten 91Stammdatentabelle 150Transaktion RSNSPACE 92Version 19, 21Verwendungsnachweis 84virtueller Provider 87, 209

InfoProvider 83, 87Informationsverlust 37InfoSource 36, 122


268

Index

J

Jobauswahl 53Join-Beziehung 100

K

Kalendertag 96Kennzahl 116

virtuelle 85, 140Key User 174Konsolidierungsschicht 36Kostenkalkulation 164Kosten-Nutzen-Analyse 17, 32

L

Ladeperformance 48, 237Ladeprozess 45Ladezeit 45, 46, 48Ladezyklus 65, 90, 99Laufzeit 17, 24

Analyse 73Layout 28Lebenszyklus 15, 16LISTCUBE 179LISTSCHEMA 24, 93, 202

M

Mapping 19Tabelle 130

Masterdokument 43Masterkette 102Matrixvergleich 82Meilenstein 106Merkmal, virtuelles 85, 140Messverfahren 23Metadaten 19Metakette 102Methode, statische 226, 229, 230Migration 18MultiProvider 100, 154, 158

Aktivierung 188InfoCube 100

N

Nachaktivierung 188Namenskonvention 110, 111Namensraum

Pflege 25SAP NetWeaver BW 110

Navigationsattribut 85, 115, 149Nested Loop 79Neuaufbautabelle 52Nicht-SAP-System 120Non-Unique-Index 151Nutzer

Akzeptanz 15, 16, 70Schulung 174, 175Zufriedenheit 10, 34

O

Object Navigator 65Objekt

Änderbarkeit 187Icon 42Katalog 113wartungsarmes 100wartungsintensives 99

OPEN CURSOR FOR SELECT 224

P

Paket 35, 113Parameter 231Partitionierung 103, 147Performance 240

ermitteln 72Statistik 30Transaktionen 72, 76Tuning 237

Persistent Staging Area � PSAPilotsystem 107, 170Programm

RS_TRANSTRU_ACTIVATE_ALL 188RSAU_UPDR_REACTIVATE_ALL 188RSDG_AFTER_IMPORT_FOR_CORR

188RSDG_CUBE_ACTIVATE 188


269

Index

Programm (Forts.)RSDG_IOBJ_ACTIVATE 188RSDG_MPRO_ACTIVATE 188RSDG_ODSO_ACTIVATE 188RSDRI_INFOPROV_READ_DEMO 208Z_CHECK_FF 249Z_CUBE_MOD 146Z_CUBE_MODE 255Z_CUBE_STAT 96, 98, 148, 166, 176,

181, 229, 246Z_ODS_STAT 98, 248Z_STAT_MASTER_DATA 91, 244

Projektplan 17, 109zyklischer 106

Provider, virtueller 87, 154, 209Prozesskette 29, 98, 100, 240

Zeitplanung 101PSA 48, 112, 240

Q

Query Designer 18Query-Laufzeit 24, 26, 70, 80

technische Faktoren 71

R

Ranking 23Real-Time DataSource 55Referenzvariable 230Releasewechsel 17, 35Remodellierung

Checkliste 237Kosten 32Motivation 17Regel 182Risiko 31

Remote Function Call � RFCReparaturkennzeichen 188, 189Reporting-Ebene 38, 42Reporting-Objekt 17, 82

Wartungsaufwand 99Repository-Infosystem 230Ressourcenplanung 109Return on Investment 32

RFC 56, 65, 226Baustein 67, 69, 70Schnittstelle 87

Risiko 31Rohdatenschicht 36ROI 32, 33RSA1 20, 87, 97, 100, 155, 185, 186,

187, 188, 193, 194, 198, 202, 204, 205, 209

RSNSPACE 25, 92RSPC 209, 228RSPCM 208RSRCATTTRACE 214RSRT 26, 72, 73, 75, 81, 133, 139, 161,

174, 211, 215RSRTRACE 214RSRV 93, 215RSSM 52RSTT 214Rundungsfehler 50, 54

S

SAP Business Content 18, 88Erweiterung 19

SBIW 209Schichtenmodell 35, 36Schlüsselfeld 208SE01 190, 194SE03 114, 186, 194SE11 130, 149, 159, 202SE12 94SE16 25, 26, 112, 135, 202SE30 219SE37 67, 141, 226, 227, 229SE80 65, 67, 114, 127, 142, 143, 172,

205, 229SE84 227, 230Selektion, konstante 138Selektionskriterium 65SID 47

Schlüssel 88Tabelle 78

Sizing 22SM21 72SM37 53SM50 163, 175SM62 235


270

Index

Speicherbereich, allokierter 222Speicherplatz 22, 99Speicherverwaltung 72Sprungziel 134, 139ST01 217ST03N 30, 76, 89, 221ST05 219ST22 72Staging-Ebene 38, 42Stammdaten 29, 49, 84, 102

Tabelle 90, 91Wartungsaufgaben 99zeitabhängige 90zeitunabhängige 90

Standardapplikation 18Startroutine 44, 53, 122, 126Statement

FETCH NEXT CURSOR 69OPEN CURSOR FOR SELECT 224

StatistikDaten 174Tabelle 154

Sternschema 200erweitertes 92, 94, 95, 147, 215

STMS 195Strukturinformation 104Surrogate-ID � SIDSwap 222Systemlast 30

Monitor 76Systemressource 51

T

Tabelle, interne 224Tabellenvergleich 67Taktfrequenz 22Testphase 171TLOGO-Objekt 185Trace-Werkzeug 52Transaktion

CMOD 87, 140, 144DB05 95, 202, 216FILE 233LISTCUBE 53, 179LISTSCHEMA 24, 93, 202

Transaktion (Forts.)RSA1 20, 87, 97, 100, 155, 185, 186,

187, 188, 193, 194, 198, 202, 204, 205, 209

RSNSPACE 25, 92RSPC 209, 228RSPCM 208RSRCATTTRACE 214RSRT 26, 72, 73, 75, 81, 133, 139,

161, 174, 211, 215RSRTRACE 214RSRV 93, 215RSSM 52RSTT 214SBIW 209SE01 190, 194SE03 114, 186, 194SE11 130, 149, 159, 202SE12 94SE16 25, 26, 112, 135, 202SE30 219SE37 67, 141, 226, 227, 229SE80 65, 67, 114, 127, 142, 143, 172,

205, 229SE84 227, 230SM21 72SM37 53SM50 163, 175SM62 235ST01 217ST03N 30, 76, 89, 221ST05 219ST22 72STMS 195

Transformation 18, 36, 123, 241Dokumentation 44Prozess 111Regel 48Schicht 36zentrale 166

TransportManager 195Objekt 191Steuerungsprogramm 197Transport Workbench 193

Treppenaufbau 181Trigger 122Tupel 199


271

Index

U

Überholerproblematik 197Umsetztabelle 130, 132Union-Operation 100Unique-Index 151

V

Vergleichsobjekt 65Vergleichstabelle 65Version 19, 20Verzögerung 23View 226

W

Wahrheitaktuelle 55, 91, 104, 115historische 55, 91, 104, 115

Währungsumrechnung 24, 54, 240Wartungsaufwand 99WHERE-Klausel 68

Z

Z_CUBE_STAT 166, 229Zähler 133Zeiger 222Zeit

Dimension 149Ersparnis 34Planung 108

Zuverlässigkeit der Daten 23


daten-remodellierung in sap netweaver bw - thali.ch · sap netweaver bw ..... 199 4.1 struktur und...

Documents