praktische datenmodellierung für sap netweaver bi...ven einsatz. der schulungsleiter andreas worch,...

Daniel Knapp

Praktische Datenmodellierung für SAP NetWeaver® BI

Bonn � Boston

944.book Seite 3 Donnerstag, 4. September 2008 9:34 09

5

Inhalt

Danksagung ............................................................................................. 9

1 Einleitung ............................................................................. 11

1.1 Einführung in SAP NetWeaver BI ............................................. 111.2 Datenmodell der SAP im Business Content .............................. 141.3 Aufbau des Buches .................................................................. 161.4 Zielgruppen ............................................................................. 17

2 Das Enterprise Data Warehouse (EDW) .............................. 19

2.1 Einführung in das Enterprise Data Warehouse ......................... 192.1.1 Die Corporate Information Factory (CIF) ..................... 192.1.2 Von der CIF zum EDW ................................................ 232.1.3 Bezeichnungen der Ebenen ......................................... 252.1.4 Aufwand beim Aufbau eines EDW .............................. 26

2.2 Ebene 1 – Data Acquisition Layer ............................................ 272.2.1 Anzahl extrahierter Daten ........................................... 282.2.2 Umgang mit Business Content ..................................... 282.2.3 Bereinigung von Daten ............................................... 292.2.4 Datenspeicherung ....................................................... 29

2.3 Ebene 2 – Enterprise Data Warehouse Layer ............................ 312.3.1 Speicherung der Daten ................................................ 312.3.2 Transformation in die EDW-Ebene .............................. 32

2.4 Ebene 3 – Operational Data Store Layer .................................. 362.5 Ebene 4 – Architected Data Mart Layer ................................... 37

2.5.1 Objekte in der Ebene .................................................. 372.5.2 Art der Datentransferprozesse ..................................... 382.5.3 Speicherung der Daten ................................................ 382.5.4 Reporting auf der ADM-Ebene .................................... 39

2.6 Neuanforderungen im Enterprise Data Warehouse .................. 402.6.1 Fortschreibung von Merkmalen ................................... 412.6.2 Bildung von Kennzahlen ............................................. 422.6.3 Erweiterung des EDW-Modells ................................... 43

2.7 Vor- und Nachteile eines Enterprise Data Warehouses ............. 452.8 Variationen im EDW-Konzept .................................................. 47

2.8.1 Variation 1 – Verkleinerung des Data Acquisition Layer ........................................................................... 47


Inhalt

6

2.8.2 Variation 2 – Performance-Erhöhung des ETL-Prozesses ............................................................. 49

2.8.3 Variation 3 – Vermeidung von Redundanzen ............... 502.8.4 Variation 4 – Erhöhung der Reporting-Performance .... 512.8.5 Variation 5 – Erhöhung der Flexibilität bei

Neuanforderungen ...................................................... 522.9 Zusammenfassung ................................................................... 52

3 Entwicklung eines Enterprise Data Warehouses anhand von Beispielen ......................................................... 55

3.1 Vorstellung des Beispiels ......................................................... 563.1.1 HCM-Infotypen ........................................................... 563.1.2 Anforderungen an die Applikation .............................. 58

3.2 Konzeption des Enterprise Data Warehouses ........................... 593.2.1 Ermittlung erforderlicher Merkmale ............................ 593.2.2 Bestimmung der Datenherkunft .................................. 603.2.3 Bezug zum Business Content ....................................... 603.2.4 Entwurf des Datenmodells .......................................... 613.2.5 Entwurf des ETL-Prozesses .......................................... 623.2.6 Weitere Besonderheiten des SAP ERP

HCM-Systems ............................................................. 653.3 Implementierung der DataSources ........................................... 67

3.3.1 Aktivierung von DataSources aus dem Business Content ...................................................................... 67

3.3.2 Erstellen von Views ..................................................... 683.3.3 Anlegen kundeneigener DataSources .......................... 71

3.4 Entwurf der Grundstruktur im BI-System ................................. 733.4.1 Replikation der DataSources ....................................... 733.4.2 Anlegen von InfoAreas ................................................ 75

3.5 Anlegen von InfoObjects ......................................................... 763.6 Modellierung des Data Acquisition Layer ................................. 78

3.6.1 Modellierung der Stammdaten .................................... 783.6.2 Modellierung der Bewegungsdaten ............................. 81

3.7 Modellierung des Enterprise Data Warehouse Layer ................ 823.7.1 Modellierung der Stammdaten .................................... 843.7.2 Modellierung der Bewegungsdaten ............................. 86

3.8 Modellierung des Architected Data Mart Layer ........................ 883.8.1 Modellierung des Personalbestands (GP3_PB) ............. 893.8.2 Modellierung der Personalmaßnahmen (GP3_PM) ...... 923.8.3 Modellierung der Bezügeauswertungen (GP3_PY) ....... 933.8.4 Modellierung der Reporting-Ebene ............................. 95


Inhalt

7

3.9 Implementierung der Stammdaten-Transformationen .............. 973.9.1 Transformationen der DataSources in die A-Ebene ...... 973.9.2 Transformationen der A-Ebene in die EDW-Ebene ...... 1003.9.3 Transformationen von der EDW-Ebene in die

ADM-Ebene ................................................................ 1053.10 Implementierung der Bewegungsdaten-Transformationen ....... 107

3.10.1 Transformationen der DataSources in die A-Ebene ...... 1073.10.2 Transformationen der A-Ebene in die EDW-Ebene ...... 1073.10.3 Transformationen von der EDW- in die ADM-Ebene ... 111

3.11 Zusammenfassung ................................................................... 115

4 Erweiterung des Enterprise Data Warehouses .................... 117

4.1 Beschreibung der neuen Anforderungen .................................. 1174.1.1 Neuanforderungen der Fachabteilung ......................... 1174.1.2 Klassifizierung der Anforderungen ............................... 117

4.2 Fortschreibung von Merkmalen ............................................... 1184.3 Erweiterung des EDW-Modells ................................................ 120

4.3.1 Erweiterungen im Quellsystem .................................... 1204.3.2 Erweiterungen des Datenmodells ................................ 1234.3.3 Erweiterungen des ETL-Prozesses ................................ 1264.3.4 Erweiterung der Prozessketten .................................... 130


5 Häufige Anforderungen an Business-Intelligence-Systeme ................................................................................ 133

5.1 Historisierung von Objekten .................................................... 1345.1.1 Möglichkeiten der Historisierung in SAP

NetWeaver BI ............................................................. 1345.1.2 Art und Auswirkung der Modellierung auf die

Historisierung ............................................................. 1385.2 Anzahl aufzunehmender Objekte ............................................. 139

5.2.1 Auswirkung auf den InfoCube ..................................... 1405.2.2 Methoden zur Modellierung vieler Objekte ................. 140

5.3 Aufnahme zukünftiger Daten ................................................... 1505.4 Zusammenfassung ................................................................... 153

6 Ladesteuerung ...................................................................... 155

6.1 Prinzipien der Datenaktualität ................................................. 1556.1.1 Historische Szenarien .................................................. 156


Inhalt

8

6.1.2 Häufigkeit der Datenaktualisierung ............................. 1586.2 Ladesteuerung mit SAP NetWeaver BI ..................................... 1596.3 Entwurf einer einfachen Ladesteuerung ................................... 1606.4 Entwurf einer komplexen Ladesteuerung ................................. 166

6.4.1 Konzeption der Ladesteuerung .................................... 1676.4.2 Implementierung der Ladesteuerung ........................... 169


Anhang........................................................................................ 181

A Literaturverzeichnis ............................................................................ 183B Abkürzungsverzeichnis ....................................................................... 185C Glossar ............................................................................................... 187D InfoObjects aus dem Business Content ............................................... 189E Der Autor ........................................................................................... 191

Index ........................................................................................................ 193


11

1 Einleitung

Beginnen möchte ich dieses Buch mit einer kurzen Erläuterung von SAP Net-Weaver Business Intelligence (BI) und dem im SAP Business Content ausge-lieferten Datenmodell. Das soll Ihnen verdeutlichen, wie zum einen SAPNetWeaver BI, aber auch das Datenmodell des Business Content arbeitet. Siewerden sehen, dass der Business Content in Form von InfoCubes sehr gut fürPrototyping-Zwecke geeignet ist, aber im Projektverlauf keine Anwendungmehr findet. Gerade in dem in Kapitel 2 vorgestellten Enterprise Data Ware-house sind nur noch die Extraktoren von Belang.

Am Ende dieses Kapitels erfahren Sie, wie das Buch aufgebaut ist und welcheZielgruppen ich beim Schreiben im Blick hatte.

1.1 Einführung in SAP NetWeaver BI

Wenn Sie die Systemlandschaft in Ihrem Unternehmen betrachten, so findenSie meist mehr als ein System vor, das der Unternehmenssteuerung dient. Jegrößer Ihr Unternehmen ist, desto mehr Systeme werden in der Regel vor-handen sein. Dies erklärt sich zum einen aus Datenschutzaspekten und zumanderen aus der Historie heraus. Kleine Unternehmen benötigen meist nurein System zur Verwaltung und Steuerung. Wenn das Unternehmen expan-diert und weitere Gesellschaften integriert, wächst auch die Anzahl der Sys-teme. Diese neuen Systeme unterscheiden sich typischerweise stark von denderzeit verwendeten (siehe Abbildung 1.1).

Problematisch sind die heterogenen Systeme und Systemlandschaften, wennSie ein konsolidiertes Reporting über den gesamten Unternehmensbestanddurchführen möchten. Aufgrund der Differenzen der einzelnen Systeme istein enorm hoher, meist manueller Konsolidierungsaufwand notwendig, umdie Daten auf einen Nenner zu bringen und damit auswertbar zu machen.Eine Lösung könnte sein, Ihre Systemlandschaft zu konsolidieren. Dasgelingt Ihnen aber nur bis zu einem gewissen Maße. Eine weitere Lösung istdas sogenannte Data Warehouse, das als Zwischensystem in Ihrem Unter-


Einleitung1

12

nehmen betrachtet werden kann (siehe Abbildung 1.2). Bei der SAP AGheißt die Data-Warehouse-Lösung SAP NetWeaver BI und ist fester Bestand-teil der SAP NetWeaver-Plattform.

Abbildung 1.1 Heterogene Systemlandschaft in großen Unternehmen

Abbildung 1.2 Nutzung von SAP NetWeaver BI für unternehmensweites konsolidiertes Reporting

Unternehmensweites Reporting

…

Auswertung 1 Auswertung 2

HCM

FI/CO

MS Excel

Gesellschaft 1

HCM

FI/CO

MS Excel

Gesellschaft 2

HCM

FI/CO

MS Excel

Gesellschaft n

Nicht-SAP-System Nicht-SAP-System Nicht-SAP-System

Auswertung n

HCM

FI/CO

Nicht-SAP-System

MS Excel

Gesellschaft 1

Unternehmensweites Reporting

HCM

FI/CO

MS Excel

Gesellschaft 2

HCM

FI/CO

…Nicht-SAP-System

MS Excel

Gesellschaft n

Nicht-SAP-System

SAP NetWeaver BI


Einführung in SAP NetWeaver BI 1.1

13

Die zentrale Aufgabe eines Data Warehouses besteht darin, ein unterneh-mensweites Reporting zu ermöglichen, indem die als »Quellsysteme«bezeichneten ERP-Systeme an das Data Warehouse angeschlossen werden.Die Daten der Quellsysteme werden anschließend bereinigt (»auf einen Nen-ner gebracht«), konsolidiert, angereichert und in speziellen, für das Repor-ting optimierten Datenmodellen gespeichert. Die Rede ist vom multidimen-sionalen Datenmodell, das in SAP NetWeaver BI durch das erweiterteSternschema der SAP abgebildet wird.

Das zu entwerfende Datenmodell ist das Herzstück eines Data Warehouses.Mit ihm steht und fällt die Applikation und damit die Akzeptanz des Sys-tems. Gute Datenmodelle sollten daher immer mindestens folgende Eigen-schaften aufweisen:

� hochperformantes Reporting

� schnelle Reaktion auf Neuanforderungen und Änderungen

� flexible Auswertungsmöglichkeiten

Es gibt viele Wege, Datenmodelle zu entwerfen, die diese Kriterien erfüllen.Ein besonderer Ansatz ist der Enterprise-Data-Warehouse-Ansatz (EDW-Ansatz), den ich Ihnen in den folgenden Kapiteln näherbringen möchte. DasEnterprise Data Warehouse besteht aus unterschiedlichen Ebenen (auch:Schichten, Layer), die zum einen ein performantes, flexibles Reporting bie-ten und zum anderen Effizienz in der Datenmodelländerung.

Damit weist das EDW die Grundvoraussetzungen eines guten Datenmodellsauf. Diese sehr positiven Eigenschaften werden allerdings durch eine Reihevon Nachteilen erkauft:

� Erhöhter SpeicherbedarfDurch die unterschiedlichen Ebenen, die ich Ihnen im Laufe des Buchesnäherbringen werde (siehe Kapitel 2 und 3), werden Daten redundantgehalten und verursachen damit einen erhöhten Speicherplatzbedarf.

� Höherer Realisierungsaufwand zu BeginnDer Aufbau der Ebenen ist mit erhöhtem Realisierungsaufwand verbun-den. Der Aufwand relativiert sich zwar mit zunehmendem Alter des DataWarehouses, ist aber anfangs höher als bei konventionellen Data Ware-houses, die als Projektlösung entstanden sind (»Insellösung«).

� DatenschutzaspekteDie erste Ebene im EDW extrahiert mehr Daten als für die Auswertungnotwendig sind. Dies kann beim Datenschutz zu Problemen führen. Auf


Einleitung1

14

die Datenschutzaspekte werde ich in Abschnitt 2.2, »Ebene 1 – DataAcquisition Layer«, noch genauer eingehen.

Die Vor- und Nachteile des EDW-Ansatzes werde ich in Abschnitt 2.7, »Vor-und Nachteile eines Enterprise Data Warehouses«, im Detail besprechen.

1.2 Datenmodell der SAP im Business Content

Bei dem Entwurf von Datenmodellen gehen Sie prinzipiell immer den glei-chen Weg: Sie entwerfen ein Datenmodell auf Basis von Berichtsanforderun-gen, entwickeln die Extraktoren aus den Quellsystemen und konsolidierenund bereinigen die Daten für die Auswertung vom Weg der Quellsystemebis in die Auswertungsebene. Gerade der Entwurf von Extraktoren ist hier-bei sehr aufwendig und sollte nicht unterschätzt werden.

Hier hebt sich ein SAP NetWeaver BI-System von anderen Data-Warehouse-Lösungen ab. SAP NetWeaver BI bietet Ihnen eine Reihe vorkonfigurierterObjekte in Form des sogenannten Business Contents an, die Sie für Ihr Daten-modell verwenden können. Der Business Content deckt dabei alle Facetteneines Reporting-Systems ab. Er enthält Datenmodelle in Form von InfoCu-bes, Extraktoren aus SAP-Quellsystemen sowie Berichte auf dem Datenmo-dell. Gerade die Extraktoren aus dem Logistikbereich oder der Personalab-rechnung sind sehr komplex und bieten Ihnen für die Entwicklung einesData Warehouses einen echten Mehrwert.

Das Datenmodell des Business Contents hingegen, das ich Ihnen im Folgen-den kurz vorstellen möchte, dient mehr dem Prototyping als dem produkti-ven Einsatz. Der Schulungsleiter Andreas Worch, SAP-Schulung BW360 »BIPerformance und Administration« hat es sehr treffend ausgedrückt: Die Info-Cubes aus dem Business Content seien »schön« modelliert, aber nicht perfor-mant. Daher finden die InfoCubes aus dem Business Content selten Anwen-dung in produktiven Umgebungen und werden vorrangig im Prototypingverwendet. Dazu sind sie jedoch hervorragend geeignet, da Sie dem Anwen-der ein System zur Verfügung stellen, das intuitiv bedienbar ist, und ihm soeinen ersten Eindruck eines BI-Systems vermitteln kann.

Die Mehrheit der Objekte im Business Content ist nach dem gleichenSchema aufgebaut: Es existieren eine oder mehrere DataSources (Extrakto-ren), die die Daten aus einem SAP-Quellsystem beziehen und über eine Info-Source die Daten an einen InfoCube weiterreichen (siehe Abbildung 1.3).Weiterhin basiert der größte Teil des Datenflusses noch auf dem 3.x-Daten-


Datenmodell der SAP im Business Content 1.2

15

flusskonzept, d.h. die neuen Funktionen aus SAP NetWeaver BI 7.0 wieDatentransferprozesse und Transformationen werden (noch) nicht genutzt.Mehr zu den Themen neuer und alter Datenfluss sowie fachliche Migrationkönnen Sie im Buch »Erfolgreiche Migration nach SAP NetWeaver BI 7.0«von SAP PRESS nachlesen (in Anhang A finden Sie ein Literaturverzeichnis).

Der InfoCube ist anschließend so modelliert, dass betriebswirtschaftlichzusammengehörige Objekte in einer Dimension liegen, also das Merkmal»Material« unter der Dimension »Material«, das Merkmal »Mitarbeiter«unter der Dimension »Mitarbeiter« und so weiter. Dadurch findet sich derAnwender schneller in der Anwendung zurecht, jedoch ist diese Art derDatenmodellierung nicht immer performant. Mehr zum Thema Performancein Datenmodellen erfahren Sie in Abschnitt 5.2, »Anzahl aufzunehmenderObjekte«, sowie in der SAP-Schulung BW360 »BI Performance and Adminis-tration«. In Abbildung 1.4 sehen Sie als Beispiel den InfoCube »Mitarbeiter-genaue Abrechnungsdaten« mit seinen Dimensionen und den untergeordne-ten Merkmalen.

Abbildung 1.3 Typischer Datenfluss im Business Content

DataSource 1 DataSource n

InfoSource

InfoCube

Extraktion aus dem Quellsystem

Extraktion aus dem Quellsystem

Übertragungsregeln

Fortschreibungsregel

…


Einleitung1

16

Für die performante und flexible Datenmodellierung ist es daher notwendig,die InfoCubes aus dem Business Content zu remodellieren. Da dies aber fastebenso aufwendig ist wie der Entwurf eines neuen Datenmodells, verwendetman die InfoCubes aus dem Business Content meist nicht im Projektverlaufund entwirft eigene Objekte.

1.3 Aufbau des Buches

Das Buch ist wie folgt aufgebaut:

� Kapitel 2: Das Enterprise Data Warehouse (EDW)In Kapitel 2 lernen Sie das Enterprise Data Warehouse von Grund auf ken-nen. Sie erfahren zu Beginn, dass das Enterprise Data Warehouse aus derCorporate Information Factory (CIF) entstanden ist und inzwischen alsSynonym für ein Ebenenmodell steht. Ich erläutere Ihnen detailliert denAufbau der einzelnen Schichten und wie Sie diese in SAP NetWeaver BIimplementieren können. Neben dem klassischen EDW-Ansatz gibt es eineVielzahl von Variationen, die ich Ihnen ebenfalls vorstellen werde.

� Kapitel 3: Entwicklung eines Enterprise Data Warehouses anhand vonBeispielenNachdem Sie die Herkunft und den Aufbau eines EDW kennengelernthaben, führe ich Sie anhand einer Beispielapplikation aus dem Personal-controlling in die Modellierung und Umsetzung eines EDW ein. Sie erfah-ren den Aufbau und die Implementierung von der Entwicklung im Quell-system bis zur Modellierung und Realisierung der einzelnen Ebenen undihrer Transformationen.

Abbildung 1.4 Dimensionen und Merkmale des InfoCubes »Mitarbeitergenaue Abrechnungsdaten«


Zielgruppen 1.4

17

� Kapitel 4: Erweiterung des Enterprise Data WarehousesDie in Kapitel 3 vorgestellte Beispielapplikation soll anschließend umNeuanforderungen ergänzt werden. Damit möchte ich Ihnen zeigen, wieder Prozess aussieht und welche Schritte durchlaufen werden müssen. DieErweiterung wird am aus Kapitel 3 bekannten Enterprise Data Warehouseaus dem Personalcontrolling vorgenommen.

� Kapitel 5: Häufige Anforderungen an Business-Intelligence-SystemeBei der Einführung eines Data Warehouses gibt es Anforderungen, diesehr häufig von Fachabteilungen gestellt werden. So besteht oft derWunsch, so viele Objekte historisiert mit aufzunehmen wie möglich, wasdie Performance des Systems negativ beeinflussen kann. Weiterhin sollein Data Warehouse i.d.R. auch Zukunftsdaten mit berücksichtigen. DieseAnforderungen sind auch im EDW-Umfeld anzutreffen; ich zeige Ihnen indiesem Kapitel, wie Sie diese Anforderungen dort umsetzen können.

� Kapitel 6: LadesteuerungIn Data Warehouses können Daten sehr unterschiedlich geladen undgespeichert werden. So sind Szenarien denkbar, die historisch stabileDaten, aber auch historisch korrekte Daten speichern sollen. Zu Beginnmöchte ich Sie daher mit der Problematik historisch stabiler und korrekterDaten vertraut machen. Anschließend erfahren Sie, wie Sie diese Anforde-rungen über Prozessketten umsetzen können. Ich zeige Ihnen die Imple-mentierung an einem einfachen sowie einem komplexen Beispiel, wobeiich die Beispielapplikation aus Kapitel 3 als Basis nutze.

� AnhangIm Anhang finden Sie neben dem Literatuverzeichnis ein Abkürzungsver-zeichnis sowie ein Glossar. Um Kapitel 3 im Lesefluss nicht zu stören,habe ich Ihnen hier auch die aus dem Business Content stammenden Info-Objects zusammengefasst aufgelistet.

1.4 Zielgruppen

Folgende Zielgruppen erhalten in diesem Buch wertvolle Informationen zumThema »Enterprise Data Warehousing« bzw. praktische Datenmodellierung:

� Entwickler aus dem Umfeld Business Intelligence, die mit der Einführungoder Konsolidierung von Data Warehouses konfrontiert sein werden,erhalten umfangreiches Wissen über das Enterprise Data Warehouse undausführliche Beispiele, die sie bei der Implementierung unterstützen.


Einleitung1

18

� Berater aus dem Umfeld Business Intelligence, die Data-Warehouse-Pro-jekte bei Kunden durchführen, erhalten Praxistipps und Vorgehensweisenzur erfolgreichen Einführung eines Enterprise Data Warehouses und derdamit verbundenen Ladesteuerungen.

� Administratoren, die ein Enterprise Data Warehouse später bewirtschaftenund warten müssen, erhalten einen Überblick über die durchzuführendenTätigkeiten.

� Interessierte, Studierende und andere Anwender, die ausführliche Informati-onen zu Konzepten des Enterprise Data Warehousing, Ladesteuerungenund Praxisinformationen benötigen, finden in den Kapiteln 2, 5 und 6umfangreiche Erläuterungen.

� Fachabteilungen, die vor der Einführung eines SAP NetWeaver BI stehen,erhalten einen Überblick über die Flexibilität und die Eigenschaften einesEnterprise Data Warehouses und können so die Einführung besser beur-teilen.


55

3 Entwicklung eines Enterprise Data Warehouses anhand von Beispielen

In diesem Kapitel entwickle ich eine Beispielapplikation nach den Erkennt-nissen aus dem vorherigen Kapitel, »Das Enterprise Data Warehouse(EDW)«. An einem nicht zu einfachen Beispiel möchte ich Ihnen zeigen, wieein EDW-Ebenenmodell aufgebaut werden kann.

Ich habe dazu ein Beispiel aus dem Bereich Human Capital Management(HCM) gewählt, das sich sehr gut für den Einsatz eines Enterprise Data Ware-houses eignet. HCM-Systeme sind grundsätzlich sehr stammdatenlastig, imGegenzug sind die Kennzahlen einfacher zu ermitteln. Die Schwierigkeit imHCM-Bereich besteht aber vor allem darin, die unterschiedlichen Zeitschei-ben der Infotypen »abzumischen«, um korrekte Stammdaten zu erhalten.

Ich werde Ihnen zu Beginn das Beispiel vorstellen, das ich in diesem Kapitelimplementieren werde, und ein paar notwendige Grundbegriffe von SAPERP HCM erläutern. Anschließend zeige ich Ihnen, wie die Implementierungeines Enterprise Data Warehouses aussehen könnte, um die gegebenenAnforderungen abzudecken.

Wichtige Anmerkung

Ich möchte Sie noch darauf hinweisen, dass es sich hier um eine Beispielapplikationhandelt, das bedeutet, dass ich die Applikation an gewissen Stellen vereinfachenwerde (Anzahl aufgenommener Felder, kein Hinzulesen von Texten, keine Beach-tung indirekt bewerteter Lohnarten, nur ein angeschlossenes Quellsystem). DasBeispiel eignet sich aber dennoch hervorragend, um in das EDW-Konzept einzu-steigen.

Viele Wege führen nach Rom, und meine Implementierung erhebt nicht denAnspruch auf den Königsweg für HCM-BI-Implementierungen. Ich werde Sie angegebener Stelle darauf hinweisen, wenn alternative Möglichkeiten der Modellie-rung existieren. Allerdings kann das Beispiel durchaus als Grundlage einer Projekt-lösung dienen, da es die notwendige Komplexität besitzt und zwar im Umfang,nicht aber in der Funktionalität der Entwicklung begrenzt ist.


Entwicklung eines Enterprise Data Warehouses anhand von Beispielen3

56

3.1 Vorstellung des Beispiels

Wie eingangs bereits erwähnt, werde ich ein Beispiel aus dem BereichHuman Capital Management (HCM) umsetzen, um das EDW-Modell einzu-führen. Das Enterprise Data Warehouse soll nach der Umsetzung dazu die-nen, Personalcontrolling auf Basis wichtiger Infotypen durchführen zu kön-nen.

Die Schwierigkeit in der Implementierung besteht später darin, die Zeit-scheiben der Infotypen abzumischen. Im folgenden Abschnitt möchte ich Sieetwas näher mit Infotypen vertraut machen. Wenn Sie sich mit Infotypenbereits auskennen, können Sie diesen Abschnitt auch überspringen.

3.1.1 HCM-Infotypen

Infotypen, die Kurzform für Informationstypen, sind logische Gruppierun-gen von Mitarbeiterstammsätzen. Um Infotypen zu klassifizieren, hat SAPihnen Namen und Nummern gegeben. Erfahrene HCM-Berater und HCM-Sachbearbeiter verwenden meist nur noch Nummern. Beispielhafte Info-typen sind:

� Infotyp 0001 (Organisatorische Zuordnung)

� Infotyp 0006 (Anschriften)

� Infotyp 0021 (Familie/Bezugsperson)

� Infotyp 2001 (Abwesenheiten)

Wie Sie sehen, sind die Nummern grundsätzlich vierstellig, es gibt also eineVielzahl von Infotypen. In der Tat sind in einem SAP-System mehrere Hun-dert Infotypen vorhanden, von denen nur ein Bruchteil in einem Unterneh-men eingesetzt wird (ca. 20–200, je nach Größe des Unternehmens).

Die erste Stelle der Nummer gibt Aufschluss über die Bereiche, zu denen einInfotyp gehört. Die erste 0 aus Infotyp 0001 besagt z.B., dass es sich umeinen Infotypen aus der Personaladministration handelt. Die Infotypen, diemit einer »1« beginnen, stammen aus dem Organisationsmanagement, diemit einer »2« aus der Personalzeitwirtschaft etc. Eine Sonderstellung neh-men die Infotypen ein, die mit einer »9« beginnen. Man spricht hier vonkundeneigenen, d.h. selbst angelegten Infotypen. In manchen Fällen reichtder SAP-Standard nicht aus, um die Bedürfnisse des Unternehmens abzude-cken, daher gibt es die Möglichkeit, eigene Infotypen modifikationsfrei zuentwerfen.


Vorstellung des Beispiels 3.1

57

Jeder Infotyp hat grundsätzlich die gleichen Schlüsselfelder (siehe Tabelle3.1).

Sie erkennen, dass jeder Infotyp einen Gültigkeitszeitraum besitzt (FelderBeginndatum BEGDA und Enddatum ENDDA). Dieser Gültigkeitszeitraumlegt fest, dass die in den Datenfeldern enthaltenen Informationen nur in die-sem Zeitraum gültig sind. Nach Ablauf des Enddatums können die Informa-tionen wieder anders aussehen.

Feldname Beschreibung

MANDT Mandant

PERNR Personalnummer

SUBTY Subtyp

OBJPS Objekt-Identifikation

SPRPS Sperrkennzeichen

ENDDA Gültigkeitsende

BEGDA Gültigkeitsbeginn

SEQNR Nummer eines Satzes bei gleichem Schlüssel

Tabelle 3.1 Schlüsselfelder eines Infotyps

Beispiel für einen Gültigkeitszeitraum

Infotyp 0002 legt die Daten zur Person fest, enthält also Felder wie Name undGeburtsdatum. Das Beginndatum ist meist identisch mit dem Geburtsdatum, z.B.05.01.1950. Der Infotyp ist anfangs bis »Ultimo« gültig, d.h. er hat kein echtes End-datum. In SAP wird dieses Enddatum mit 31.12.9999 gekennzeichnet. Heiratet derMitarbeiter nun und nimmt den Namen seines Partners an, bedeutet es, dass derInfotyp seit dem Zeitpunkt der Hochzeit, z.B. 10.10.2010, nicht mehr gültig ist, dader Mitarbeiter einen anderen Namen angenommen hat. Demzufolge wird einneuer Satz in Infotyp 0002 angelegt, der am Tag der Eheschließung beginnt. Deralte Satz wird bis zum Vortag der Heirat begrenzt. Die Tabelle zum Infotyp 0002sieht damit wie in Tabelle 3.2 gezeigt aus.

PERNR ENDDA BEGDA NACHN

4711 09.10.2010 05.01.1950 Müller

4711 31.12.9999 10.10.2010 Meier

Tabelle 3.2 Beispiel eines Ausschnitts aus Infotyp 0002 (Daten zur Person)



58

Jeder Mitarbeiter wird mit ca. 20–200 Infotypen charakterisiert, die unter-schiedliche Gültigkeitszeiträume besitzen. Manche Infotypen erlauben sogarmehrere Sätze zum gleichen Zeitraum. Man spricht hier von der sogenann-ten Zeitbindung von Infotypen. Manche Infotypen sind obligatorisch, man-che sind optional, und zu manchen gibt es auch mehrere Datensätze zumgleichen Zeitraum. Mehr zu diesem Thema erfahren Sie z.B. in Figaj, Haß-mann, Junold 2007 (siehe Anhang A, »Literaturverzeichnis«).

Da in einem SAP NetWeaver BI-System der Mitarbeiter nicht mehr überInfotypen abgebildet wird, sondern nur noch durch ein einzelnes Objekt,nämlich ein InfoObject, charakterisiert wird, muss zu jedem Zeitpunkt desInfoObjects die korrekte Information der zugrunde liegenden Infotypen vor-handen sein. Aus diesen 20–200 verschiedenen Zeitscheiben muss eine all-gemeingültige Zeitscheibe für den Mitarbeiter abgeleitet werden. Hierinliegt die eigentliche Schwierigkeit bei der Implementierung von HCM-BI-Systemen. In Abschnitt 3.9, »Implementierung der Stammdaten-Transforma-tionen«, erfahren Sie, wie diese Implementierung aussieht.

Im folgenden Abschnitt gehe ich auf die Anforderungen an die zu entwi-ckelnde Applikation ein.

3.1.2 Anforderungen an die Applikation

Die Applikation soll ein einfaches Personalcontrolling ermöglichen. Dazu istes erforderlich, folgende Kennzahlen abzudecken und in Berichten zur Ver-fügung zu stellen:

� Personalkosten pro Monat

� Personalkosten aktiver Mitarbeiter

� Personalbestand pro Monat

� Anzahl aktiver Mitarbeiter

� Durchschnittsalter der Mitarbeiter

� Vollzeitäquivalente der Mitarbeiter

� Anzahl Eintritte

� Anzahl Austritte

� Fluktuationsquote

Um die Kennzahlen aussagekräftig zu machen, ist es erforderlich, diese ingeeigneter Form einzuschränken. Als Anforderung besteht, folgende Merk-male als Einschränkung in die Berichte mit aufnehmen zu können:


Konzeption des Enterprise Data Warehouses 3.2

59

� Personalnummer

� Personalbereich und -teilbereich

� Mitarbeitergruppe und -kreis

� Buchungskreis

� Organisationseinheit

Auf Basis dieser Information, die Sie von der Fachabteilung erhalten haben,müssen Sie das Datenmodell und das EDW-Konzept entwerfen.

3.2 Konzeption des Enterprise Data Warehouses

In diesem Abschnitt zeige ich Ihnen detailliert, wie Sie ein EDW konzipierenund die Implementierung vorbereiten.

3.2.1 Ermittlung erforderlicher Merkmale

Am Anfang der Implementierung brechen Sie zunächst die Anforderungenauf die technischen Felder (Datenherkunft) herunter. Klären Sie dahergenau, was die Fachabteilung unter »Personalkosten pro Monat« versteht.Im Regelfall umfasst die Kategorie »Personalkosten« eine Menge vonbestimmten Lohnarten, wobei die Lohnarten von der Fachabteilung darzule-gen sind.

Dies gilt auch für die Berechnung eines Vollzeitäquivalents von Mitarbei-tern. Hier benötigen Sie eine genaue Berechnungsvorschrift, um ableiten zukönnen, welche Merkmale Sie zusätzlich zu denen aus der Anforderunggenannten aufnehmen müssen. Diese Übersetzungsleistung ist z.B. bei derKennzahl »Anzahl aktiver Mitarbeiter« zu erbringen. Hier müssen Sie erken-nen, dass der Beschäftigungsstatus als Merkmal erforderlich ist. Bei den Voll-zeitäquivalenten könnte es die Soll- oder die Ist-Arbeitszeit sein, aber auchder Beschäftigungsgrad. Verständigen Sie sich daher mit der Fachabteilungüber diese Details, um die korrekten Berechnungen zu erhalten. Anschlie-ßend erstellen Sie eine Excel-Tabelle, die die Kennzahlen und die benötigtenMerkmale enthält. In diesem Beispiel hat die genauere Analyse die Excel-Tabelle aus Abbildung 3.1 ergeben.



60

Abbildung 3.1 Mapping der Kennzahlen zu notwendigen Merkmalen

3.2.2 Bestimmung der Datenherkunft

Wenn Sie die Merkmale identifiziert haben, die für das Datenmodell erfor-derlich sind, können Sie die Datenherkunft bestimmen. Sie bestimmen, wel-che Infotypen benötigt werden, um die obigen Anforderungen an Kennzah-len und Merkmalen abzudecken. Für diese Anforderungen habe ich diefolgenden Infotypen identifiziert:

� Infotyp 0000 (Maßnahmen)

� Infotyp 0001 (Organisatorische Zuordnung)

� Infotyp 0002 (Daten zur Person)

� Infotyp 0008 (Basisbezüge)

� Infotyp 0014 (Wiederkehrende Be- und Abzüge)

� Infotyp 0015 (Ergänzende Zahlung)

Bei der Implementierung eines Enterprise Data Warehouses ist nun zubeachten, dass in der Data-Acquisition-Ebene grundsätzlich mehr Informa-tionen aufgenommen werden als die Anforderungen benötigen. Das bedeu-tet, dass die identifizierten Infotypen nicht nur mit den benötigten, sondernmit allen Feldern in die A-Ebene extrahiert werden. Dieses Vorgehen erlaubtes, in Zukunft flexibler auf Neuanforderungen zu reagieren, da die meistenFelder bereits im Data Warehouse vorliegen. Ferner erleichtert es die Imple-mentierung der Extraktoren, da diese als View DataSources angelegt werdenkönnen.

3.2.3 Bezug zum Business Content

Sie haben nun die Datenherkunft der Felder identifiziert. In jedem BI-Projektist spätestens jetzt der Bezug zum Business Content vorzunehmen, da eineReihe der Felder bereits als Extraktoren vorliegt. Diese Extraktoren können

Lohnart Kalenderjahr/Monat Maßnahmeart Maßnahmegrund Mitarbeiter Beschäftigungsstatus Geburtsdatum Beschäftigungsgrad

Personalkosten pro Monat X X

Personalkosten aktiver Mitarbeiter X X X

Personalbestand pro Monat X

Anzahl aktiver Mitarbeiter X X X

Durchschnittsalter der Mitarbeiter X X

Vollzeitäquivalente der Mitarbeiter X X X

Anzahl Eintritte X X X

Anzahl Austritte X X X

Fluktuationsquote X X X


193

Index

A

Aggregat 145, 162Aggregation 145Altdaten 42Alternative Storage 22Anfangsaufwand 26, 46Anwendungskomponente 71, 74, 123Anwendungskomponenten-Hierarchie

67Application 21Applikationen 21applikationsneutral 35Architected Data Mart Layer 25, 37, 88Archiv 22Attribut

zeitabhängig 76, 108, 128, 133, 136zeitunabhängig 135

Außenwelt 20

B

Basiskennzahl 42Batch-Event 174Bauplan 21Bereinigung 29Bericht-Bericht-Schnittstelle 45, 141BI Accelerator 147BI-integrierte Planung 150Bitmap-Index 150Break-Even 27B-Tree-Index 150Business Content 14, 28, 60, 67, 160,

189

C

CIF 19, 52Corporate Data 22Corporate Information Factory � CIFCorporate Memory 23, 31, 46Customizing-Tabelle 166

D

Data Acquisition 20Data Acquisition Layer 25, 27, 47, 60, 78Data Delivery 20Data Mart 22Data Mining Warehouse 22Data Store Object 21, 187

schreiboptimiertes 30Standard 36

Data Warehouse 11, 22Data Warehousing Workbench 35, 75,

123DataSource 28, 71, 123, 187

0EMPLOYEE_ATTR 61, 64, 68, 78, 176

0HR_PA_0 61, 63, 68, 112, 1700HR_PA_1 61, 68, 1690HR_PY_1 29, 64, 1610PERSON_ATTR 61, 68, 78, 176

Datenaktualisierung 158Datenaktualität 155Datenauswertung 20Datenbank-View 68, 120, 167Datenbereitstellung 20Datenflusskonzept 15Datenherkunft 59, 60Datenmodell 13, 61Datenpaket 98Datenschutz 13, 26, 29Datentransferprozess 187Datenübergabe 20Datenziel 187Decision Support System 22Deltaverfahren 46Direktzugriff 47Dummy-Transformation 35

E

EDW 13, 19, 23, 55, 133, 163klassisches 24

EDW Layer 25, 31, 82Endroutine 32


194

Index

Enterprise Data Warehouse 19Enterprise Data Warehouse � EDWEntwicklungspaket � PaketE-Tabelle 144ETL-Prozess 49, 62, 126, 187Event 174Expertenroutine 32, 45, 102, 109, 127External World 20, 21Extract Once, Deploy Many 19, 27Extraktor 14, 28, 60, 115, 120

F

Faktentabelle 143Feldsymbol 187Flexibilität 52F-Tabelle 144Funktionsbaustein

BP_EVENT_RAISE 168, 173RP_FILL_WAGE_TYPE_TABLE_EXT 66RSAU_READ_MASTER_DATA 111,

113

G

Granularität 61, 83

H

Harmonisierung 32, 45Harmonisierungsschicht 26Historie 156historische Korrektheit 156historische Stabilität 156Historisierung 133Hochrechnung 151Hohe Kardinalität 150Human Capital Management 55,

139, 166

I

InfoArea 75InfoCube 88, 187

Abrechnungsdaten 15Bezügeauswertungen 93Personalbestand 90Personalmaßnahmen 92

InfoObject 63, 1870CALMONTH 1080DATEFROM 760DATETO 760EMPLOYEE 640PERSON 64ZEMPLOYEE 87ZPERSON 87

InfoPackage 187InfoProvider 187Infotyp 56, 60, 117

0000 (Maßnahmen) 60, 68, 71, 78, 97, 100

0001 (Org. Zuordnung) 56, 60, 68, 100, 117

0002 (Daten zur Person) 57, 60, 68, 85, 100, 120, 132

0004 (Behinderung) 117, 1320006 (Anschriften) 560008 (Basisbezüge) 60, 65, 68, 80, 100,

1080014 (Wiederk. Be-/Abzüge) 60, 69,

1080015 (Ergänz. Zahlung) 60, 69, 1080021 (Familie/Bezugsperson) 560041 (Datumsangaben) 652001 (Abwesenheiten) 56

Insellösung 13Integration and Transformation 22

K

Komprimierung 143

L

Ladesteuerung 99, 155, 167Langzeitspeicherung 31, 53Line Item Dimension 91, 149Löschen von überlappenden Requests 38Lückenbildung 33


195

Index

M

Metadata Management 20Metadaten 22Migration 15MultiProvider 39, 95

N

Neuanforderung 26, 40, 117, 120

O

Operational Data Store 21, 25, 36

P

Paket 68Partitionierung 39, 51, 147Performance 15, 30, 39, 49, 88, 133, 140Persistent Staging Area 25, 27, 47, 188Personalcontrolling 58, 117Plausibilitätsprüfung 31Primäre Datenhaltung 20Primary Store Management 20Programm

ZBI_PC_FINISH 168, 172ZBI_PC_START 168, 178

Prototyping 14PROVIDE 101, 105Prozesskette 130, 159

Q

Query 188Query Designer 188

R

Redundanz 46, 50, 52, 87Remodeling Toolbox 44Repartitionierung 149Reporting 76, 95

Request 145überlappend 38

Routine 38, 164

S

SAP Business Explorer Suite 188SAP-Schulung

BW350 32BW360 14, 15, 89, 138

Selektionsbedingung 127Selektionsparameter 72Separierung 148SID 86

Erzeugung von 86Single Point of Truth 31Sockelaufwand 27Sparcity 33Staging Layer 25Startprozess 160Startroutine 99Sternschema 90Steuerungsprogramm 172Stichtag 167Surrogat-IDs � SID

T

TransaktionMM01 143RSA1 74, 123, 144, 159RSBBS 141RSMON 159RSPC 159SBIW 67, 71, 121SE80 68, 101SM62 174

Transformation 97, 188

W

Wahrheitaktuelle 136echte 137historische 138


196

Index

Web Application 188Wiederholungsstruktur 65, 80, 97

Z

zeitabhängig 76, 108, 128, 133, 136Zeitbindung 58Zeitscheibe 56, 100zeitunabhängig 135Zielgruppe 17


SAP PRESS – LeseprobePraktische Datenmodellierung für SAP NetWeaver BIDaniel Knapp----------------------------------------------------Inhalt----------------------------------------------------Kapitel 1: Einleitung1.1 Einführung in SAP NetWeaver BI1.2 Datenmodell der SAP im Business Content1.3 Aufbau des Buches1.4 Zielgruppen

Kapitel 3: Entwicklung eines Enterprise DataWarehouses anhand von Beispielen3.1 Vorstellung des Beispiels3.1.1 HCM-Infotypen3.1.2 Anforderungen an die Applikation

3.2 Konzeption des Enterprise Data Warehouses3.2.1 Ermittlung erforderlicher Merkmale3.2.2 Bestimmung der Datenherkunft3.2.3 Bezug zum Business Content

----------------------------------------------------Index----------------------------------------------------www.sap-press.de(c) Galileo Press GmbH 2008

praktische datenmodellierung für sap netweaver bi...ven einsatz. der schulungsleiter andreas worch,...

Documents