analyse-prozess-designer - business . intelligence ....
TRANSCRIPT
1 Einleitung
- 1 -
Projektarbeit
Thema:
„Analyse-Prozess-Designer“
Funktionen und Einsatzgebiete im SAP
® Business Warehouse
An der Fachhochschule Dortmund
im Fachbereich Informatik
erstellte Projekt-/Diplomarbeit
im Studiengang Wirtschaftsinformatik
in Zusammenarbeit mit der evu.it GmbH, Dortmund
Dennis Halboth
geboren am 13.12.1981
(Matr.-Nr.: 7064539)
Betreuer: Prof. Dr. Engels
Dortmund, 15.03.2009
Markenrechtlicher Hinweis
- 2 -
Markenrechtlicher Hinweis
Die in dieser Arbeit wiedergegebenen Gebrauchsnamen, Handelsnamen,
Warenzeichen usw. können auch ohne besondere Kennzeichnung geschützte Marken
sein und als solche den gesetzlichen Bestimmungen unterliegen. Sämtliche in dieser
Arbeit abgedruckten Bildschirmabzüge unterliegen dem Urheberrecht © des
jeweiligen Herstellers.
SAP, R/3, mySAP ERP, ABAP, BAPI, SAP Business Warehouse (BW), SAP
Customer Relationship Management (CRM), SAP Netweaver und ABAP sind
Marken oder eingetragene Marken der SAP AG, Deutschland.
Microsoft, Microsoft Windows, Microsoft Office, Visio, Word, Excel sind Marken
oder eingetragene Marken der Microsoft Corp., USA.
Kurzfassung
- 3 -
Kurzfassung
Die vorliegende Arbeit befasst sich mit den Funktionen und Einsatzgebieten des
Analyse-Prozess-Designers (APD) im SAP Business Warehouse (SAP BW). Der
APD ist ein vollständig in das SAP BW integriertes Tool, das es ermöglicht, Daten
aus verschiedenen internen und externen Quellen zu verknüpfen und zu
transformieren. So können aus den vorhandenen Daten neue Informationen
gewonnen werden, die von besonderer Bedeutung für ein wirtschaftlich handelndes
Unternehmen sein können.
Der Analyse-Prozess-Designer stellt die konsequente Weiterentwicklung des
Business Warehouse dar, um komplexe Modellierungs- und Analyseprozesse
einfach, übersichtlich und transparent erstellen zu können. Darüber hinaus
ermöglicht er es, Analysen spezifischer und individueller auszuführen, um bei den
stetig steigenden Datenmengen eines Energieversorgungsunternehmens das
Reporting, trotz erhöhter Anforderungen, performant zu gestalten.
Um die Daten dem Analyseprozess zur Verfügung zu stellen, wird zunächst der
ETL-Prozess (Extraktion, Transformation, Laden) der Datenbeschaffung, mit Fokus
auf die Stammdaten, näher betrachtet. Dazu wird das Objektkonzept sowie der
gesamte Datenfluss vom Quellsystem zum Business Warehouse erläutert.
Anschließend erfolgt eine Beschreibung, wie die Funktionen und Möglichkeiten des
Analyse-Prozess-Designers genutzt werden können. Dabei wird deutlich, welchen
Einfluss der APD auf den eigentlichen ETL-Prozess des BW haben kann.
Durch die Abgrenzung der Möglichkeiten des APD von denen des Business
Warehouse wird herausgearbeitet, wie der ETL-Prozess durch die Kombination der
Funktionen optimiert und erweitert werden kann. Es wird dargestellt, wie der
Analyse-Prozess-Designer das Business Warehouse sinnvoll ergänzt und um
Funktionalitäten erweitert, die die Datenmodellierung im BW vereinfachen und
komplexe Prozesse ermöglichen. Zusätzlich werden die wesentlichen Änderungen in
der Entwicklung des APD dargestellt.
Mit Hilfe eines Fallbeispiels erfolgt die exemplarische Umsetzung eines
Analyseprozesses mit definierten Zielsetzungen anhand realer Daten. Dabei wird
offensichtlich, welche Prozesse und Transformationen mit den Möglichkeiten des
Business Warehouse und welche mit den Funktionalitäten des Analyse-Prozess-
Designers vollzogen werden sollten. In diesem Zusammenhang werden weitere
Einsatzgebiete genannt, in denen der APD sinnvoll verwendet werden kann.
Abstract
- 4 -
Abstract
The present work deals with the functions and applications of the Analysis Process
Designer in SAP Business Warehouse. The APD is a full-fledged SAP BW
integrated tool that enables to link-up as well as transform the data between different
internal and external data sources. In this way from the existent data, new
information can be gained and used for all decision and application processes and
thus can be decisive in many respects (strategically, tactically and operatively).
The APD represents the consistent further development of Business Warehouse,
where complex modelling and analyze processes are made simple, clear and
transparent. Moreover, it allows analysis to be specific and individual in order to
tackle the steadily increasing data of an energy supplying company despite
increasing demands to generate reports.
For the availability of the data of the analysis process, initially the ETL process of
the data acquisition, having the focus on the master data, is closely observed. In
addition to that, the object concept and the complete dataflow from the source system
to the Business Warehouse are elucidated.
This is followed by a description of how the features and the capabilities of Analysis
Process Designer can be used. It makes clear what impact the APD can have on the
ETL process of the BW.
The separation of the possibilities of the APD with those of Business Warehouse are
identified and developed. It describes how the ETL process, by means of the
combination of the functions in APD and BW, can be optimized and extended. It is
hence made clear how the APD is sensibly supplemented with the Business
Warehouse and the functionalities are therefore complimented. This helps the data
modelling in BW to be simple and allows complex processes. In addition, the
significant changes in the development of the APD are demonstrated.
With the help of an example, an analysis process with defined objectives can be
successfully implemented for actual data. It would therefore be clear which processes
and transformations should be completed with the BW, and which with the
functionalities of APD. In this context, further areas are mentioned where the APD
can be implemented.
Inhaltsverzeichnis
- 5 -
Inhaltsverzeichnis
1 Einleitung .................................................................... 7
1.1 Beschreibung der Thematik .......................................... 7
1.1.1 evu.it GmbH ..................................................................................... 7
1.2 Zielsetzung der Arbeit ................................................... 8
1.3 Abgrenzung .................................................................. 9
1.4 Eingesetzte Software .................................................... 9
2 ETL-Prozess der Stammdatenbeschaffung ............ 11
2.1 ETL-Prozess ............................................................... 11
2.2 Stammdaten im SAP BW ............................................ 14
2.3 Objektkonzept im SAP BW 3.x ................................... 15
2.4 Business Content ........................................................ 21
2.5 ETL-Prozess für Stammdaten im SAP BW 3.x ........... 22
2.5.1 Übertragungsregeln ....................................................................... 23
2.5.2 Fortschreibungsregeln ................................................................... 24
2.5.3 Direkte Fortschreibung .................................................................. 25
2.5.4 Flexible Fortschreibung ................................................................. 26
2.5.5 Verbuchungsarten ......................................................................... 27
2.5.6 Delta-Verfahren ............................................................................. 28
2.6 Änderungen im BW 7.0 ............................................... 30
3 Analyse-Prozess-Designer ....................................... 33
3.1 Integration des APD in das SAP BW .......................... 34
3.2 Prozessphasen ........................................................... 34
3.2.1 Phase 1 - Datenquellen ................................................................. 35
3.2.2 Phase 2 - Transformationen .......................................................... 37
3.2.3 Phase 3 - Datenziele ..................................................................... 44
3.3 Anwendungen ............................................................. 46
3.4 Funktionsweise ........................................................... 47
3.5 Versteckte Funktionen ................................................ 49
3.6 Abgrenzung zu den Möglichkeiten im BW .................. 50
3.7 Auswirkungen des APD auf den ETL-Prozess ............ 51
3.8 Unterschiede zwischen den Versionen des APD ........ 52
4 Fallbeispiel „Anlagen-Analyse“ ............................... 53
4.1 Einführung in die Thematik ......................................... 53
4.1.1 SAP for Utilities .............................................................................. 53
4.1.2 IS-U Haus ...................................................................................... 55
4.1.3 Ablauf der Vertragsabrechnung .................................................... 57
Inhaltsverzeichnis
- 6 -
4.2 Zielsetzung ................................................................. 59
4.3 Konzept ....................................................................... 60
4.4 Datenauswahl ............................................................. 61
4.5 Datenbeschaffung ....................................................... 64
4.6 Analyseprozess .......................................................... 66
4.6.1 Grundlegender Ablauf ................................................................... 67
4.6.2 Detaillierte Modellbeschreibung .................................................... 67
4.7 Datenspeicherung ....................................................... 81
4.8 Datenauswertung ........................................................ 82
4.9 Optimierungen ............................................................ 84
5 Abschluss .................................................................. 86
5.1 Zusammenfassung ..................................................... 86
5.2 Fazit ............................................................................ 86
5.3 Ausblick ...................................................................... 87
6 Anhang ...................................................................... 90
6.1 Anlagen-Analyse-Prozess ........................................... 90
6.2 A selection of useful ISU-Tables ................................. 91
6.3 ABAP-Routine des Analyseprozesses ........................ 92
7 Abkürzungsverzeichnis ............................................ 94
8 Abbildungsverzeichnis ............................................. 95
9 Tabellenverzeichnis .................................................. 98
10 Listingverzeichnis .................................................... 99
11 Quellenverzeichnis ................................................. 100
12 Glossar .................................................................... 103
13 Eidesstattliche Erklärung ....................................... 107
14 Stichwortverzeichnis .............................................. 108
1 Einleitung
- 7 -
1 Einleitung
1.1 Beschreibung der Thematik
Mit der Neuregelung des Energiewirtschaftsgesetzes (EnWG) im Jahre 1998 und
dem „Zweiten Gesetz zur Neuregelung des Energiewirtschaftsrechtes“ 2005 kam es
zu einer Liberalisierung und Öffnung des Energiemarktes. Dies führte zu
tiefgreifenden Veränderungen in der Energiebranche, insbesondere in der IT der
Versorgungsunternehmen. Die neue Konkurrenzsituation und der daraus
resultierende Zwang zum wirtschaftlichen Handeln führten zu einer verstärkten
Nutzung der operativen ERP-Systeme und damit auch zu einem enormen Anstieg der
vorhandenen Datenmengen. Um diese Datenmengen verarbeiten, vor allem aber
auswerten zu können, wurden zunehmend Data Warehouse Lösungen eingesetzt.
Der Grundstein zu einer optimierten Analyse der vorhandenen Massendaten ist also
gelegt. Nun sollen im nächsten Schritt, durch Verbindung verschiedenster Daten,
Auswertungen ermöglicht werden, die es erlauben, die vorhandenen Bestands- und
Vorgangsstatistiken abzulösen und zu entlasten, einzelne Statistiken zu erweitern und
miteinander zu verknüpfen. Dadurch sollen neue, nicht triviale Zusammenhänge
sichtbar gemacht werden, die die Produktivität und Wirtschaftlichkeit von
Versorgungsunternehmen weiter erhöhen können.
Mit Hilfe des Analyse-Prozess-Designers wurde im SAP Business Warehouse die
Basis geschaffen um solche Verknüpfungen und komplexen Transformationen der
Daten durchführen zu können. So können verschiedenste interne und externe
Datenquellen miteinander kombiniert, transformiert und anschließend analysiert
werden.
1.1.1 evu.it GmbH1
Die evu.it GmbH ist ein international tätiges Beratungsunternehmen für die Ver- und
Entsorgungswirtschaft, die öffentliche Verwaltung sowie dem öffentlichen
Personennahverkehr. Mit ihrem Hauptsitz in Dortmund, sowie weiteren Standorten
in Kiel, Mannheim, Nürtingen und Rostock, bietet die evu.it GmbH ein breites
Angebot an Beratungs- und Entwicklungsleistungen mit Schwerpunkt auf die
Produkte SAP sowie Microsoft Dynamics NAV.
1 Vgl. [EVU-IT, 2008]
1 Einleitung
- 8 -
Die Geschäftsbereiche der evu.it GmbH untergliedern sich wie folgt:
■ Enterprise Solution Consulting
■ Billing
■ Business Intelligence
■ Customer Relationship Management
■ Energy Data Management
■ Enterprise Resource Planning
■ Public Sector
■ Development
Die evu.it GmbH ist eine 100%ige Tochter der rku.it GmbH in Herne. Das
Leistungsangebot der rku.it GmbH umfasst neben der Bereitstellung von
Anwendungssystemen und deren individueller Anpassung auch das Hosting von
Systemen im rku.it-Rechenzentrum. Umfangreiche Schulungsprogramme und
umfassender Support runden das Leistungsspektrum ab.
1.2 Zielsetzung der Arbeit
Ziel dieser Arbeit ist es, anhand eines Fallbeispiels die Möglichkeiten,
Funktionsweisen und Einsatzgebiete des Analyse-Prozess-Designers zu erörtern.
Dazu ist es zunächst erforderlich, Daten aus den verschiedenen Datenbanktabellen
eines SAP R/3 Quellsystems in das SAP BW zu transferieren, um die Daten dem
APD zur Verfügung stellen zu können. Dort werden sie, entsprechend der
Zielsetzung der Fallstudie, mit Hilfe der Funktionalitäten des APD verknüpft,
aggregiert, eingeschränkt, erweitert, transformiert und zur späteren Auswertung in
ein geeignetes Datenziel gespeichert.
Darüber hinaus soll deutlich werden, wie der APD in das SAP BW eingebunden ist,
welche Auswirkungen der Einsatz des Tools auf den eigentlichen ETL-Prozess
(Extraktion, Transformation, Laden) des BW haben kann und wie der Einsatz des
APD sinnvoll mit den Funktionalitäten des Business Warehouse kombiniert wird.
Zusätzlich gilt es die Entwicklung des APD in Bezug auf dessen Funktionalität
zwischen den SAP BW Versionen 3.x und 7.0 festzuhalten.
1 Einleitung
- 9 -
1.3 Abgrenzung
Der Analyse-Prozess-Designer stellt im eigentlichen Sinne die Arbeitsumgebung der
SAP Data Mining Lösung dar, in der die Daten für die spezifischen Verfahren des
Data Mining vorbereitet werden. Insbesondere ab der BW Version 3.5 ist eine enge
Verknüpfung zwischen dem APD und dem Data Mining festzustellen.
Die Möglichkeiten des Data Mining sollen jedoch nicht Bestandteil dieser
Projektarbeit sein, sondern werden in der darauf aufbauenden Diplomarbeit
detailliert betrachtet.
Darüber hinaus werden die Grundlagen bezüglich des Data Warehouse Konzeptes,
der Ebenen des Data Warehouses sowie der Modellierung multidimensionaler
Datenräume (einfaches Star-Schema, Snowflake-Schema usw.) in dieser Arbeit nicht
näher erläutert.1
1.4 Eingesetzte Software
Die offiziellen Produktbezeichnungen der SAP sind recht unübersichtlich. Bis zu der
Version 3.3 wird das System als „SAP Business Information Warehouse“ bezeichnet.
Die Bezeichnung des Nachfolgers lautet „SAP Netweaver 2004“. Das aktuellste in
dieser Arbeit verwendete System trägt die offizielle Bezeichnung „SAP Netweaver
7.0“ bzw. „SAP Neatweaver 2004s“. Das neueste derzeit verfügbare System ist
„SAP Netweaver 7.1“.
Obwohl SAP den Begriff BW nicht mehr verwenden möchte, haben sich in der
Praxis, sowie in einem Großteil der Literatur die inoffiziellen Bezeichnungen BW
3.x bzw. BW 7.0 durchgesetzt. Deshalb werden auch in dieser Arbeit die Begriffe
SAP BW 3.x (für die Versionen 3.1.und 3.5) sowie BW 7.0 verwendet.
Folgende SAP-Systeme kommen zum Einsatz:
■ SAP Business Warehouse 3.1 Testsystem der evu.it
(interne Bezeichnung TB1)
■ SAP BI 7.0 Testsystem der rku.it und evu.it
(interne Bezeichnung T7B)
■ SAP R/3 4.6c mit IS-U (Industry Solution for Utilities)-Modul2
(interne Bezeichnung EE1)
■ SAP GUI 640 mit Business Explorer (BEx Analyzer, BEx Query Designer)
Die Umsetzung der Fallstudie erfolgt im Testsystem TB1 (BW 3.1), da dieses an das
R/3 Quellsystem (EE1) angeschlossen ist und eine performante Durchführung der
1 Weiterführende Informationen siehe [Kemper et al., 2006] S.17ff, [Egger et al., 2005] S.21ff,
[Gómez et al., 2006] S.3ff, [BW310, 2005] S.2ff, [Mehrwald, 2007] S.47ff
2 Siehe auch Abschnitt 4.1.1, SAP for Utilities, auf Seite 54
1 Einleitung
- 10 -
Beispielanwendung ermöglicht. Obwohl das System nicht die neueste Version des
SAP BW darstellt, haben sich die wesentlichen Konzepte nicht verändert. Die
bedeutenden Änderungen im Bereich des Objektkonzepts und des Datenflusses
werden jedoch kurz erläutert.
Das System EE1 ist eine Kopie eines älteren Kundensystems und stellt daher die
ideale Basis für die Datenbeschaffung und Analyse mit realen Daten dar.
Das System T7B (BW 7.0) wird genutzt, um die wesentlichen Unterschiede in der
Funktionalität des APD im Vergleich zum SAP BW 3.x zu erläutern.
2 ETL-Prozess der Stammdatenbeschaffung
- 11 -
2 ETL-Prozess der Stammdatenbeschaffung
Dieses Kapitel beschreibt den ETL-Prozess für Stammdaten sowie dessen
Umsetzung im SAP Business Warehouse. Im weiteren Verlauf wird nicht nur der
Prozess der Datenbeschaffung, sondern auch das zugrunde liegende Objektkonzept
im BW 3.x detailliert erläutert. Abschließend werden die grundlegenden Änderungen
und Neuerungen des Datenflusses im SAP BW 7.0 angesprochen.
2.1 ETL-Prozess
»Ein Ziel des ETL-Prozesses […] ist es, die Daten der Quellsysteme, die an den
operativen Abläufen ausgerichtet sind, in eine für die Entscheidungsunterstützung
optimierte Verwendungssicht zu transformieren und schließlich in den [Datenzielen]
dauerhaft zu speichern, ein anderes Ziel ist die Konsolidierung von Daten
unterschiedlicher Quellsysteme.«1
Der ETL-Prozess ist der wichtigste und zugleich aufwändigste Schritt im Data
Warehousing.
»Die Vielzahl unterschiedlicher Datenquellen, das unter Umständen beträchtliche
Datenvolumen sowie die komplexen Konsolidierungsvorgänge zur kontinuierlichen
Datenversorgung des Data Warehouse stellen eine große Herausforderung an die
IT-Abteilung, die beteiligten Systeme und die Werkzeuge dar.«2
Der ETL-Prozess wird in die folgenden Phasen unterteilt3:
■ Extraktion
Auswahl und Replikation der relevanten Daten im Quellsystem
■ Transformation
Konsolidierung und Transformation der Daten
■ Laden
Übernahme der Daten in das Data Warehouse
Der Prozess ist von entscheidender Bedeutung für den weiteren Verlauf des Data
Warehousing Prozesses, da nur auf Basis einer hohen Datenqualität aussagekräftige
Analysen und Auswertungen durchgeführt werden können. Man spricht in diesem
1 Vgl. [Seemann et al., 2001] S.142
2 Vgl. [Gómez et al., 2006] S.33
3 Siehe [Egger et al., 2005] S. 44 ff
2 ETL-Prozess der Stammdatenbeschaffung
- 12 -
Zusammenhang auch vom sogenannten „Garbage in, Garbage out“-Syndrom. Wenn
fehlerhafte, doppelte, inkonsistente oder anderweitig qualitativ minderwertige Daten
vorliegen, werden alle nachfolgenden Prozesse der Analyse beeinflusst. Dies führt zu
fehlerhaften Aussagen und damit zu falschen operativen oder strategischen
Entscheidungen.
Abbildung 1: Der ETL-Prozess
Der ETL-Prozess wird unterstützt durch das Metadata Repository, das alle Objekte
des BW sowie deren Beziehungen zueinander enthält. Metadaten werden oft als
„Daten über Daten“ bezeichnet. Das Metadaten Repository verwaltet diese Daten
und erlaubt ein konsistentes und homogenes Datenmodell über alle Ebenen des Data
Warehouse- und ETL-Prozesses hinweg.
Die einzelnen Phasen des ETL-Prozesses werden im Folgenden näher betrachtet.
2 ETL-Prozess der Stammdatenbeschaffung
- 13 -
Extraktion
Die Phase der Extraktion dient der Auswahl und Replikation von Daten aus
verschiedenen heterogenen und operativen Quellsystemen. Zu diesem Zweck werden
Regeln für die Verbindung des Quellsystems mit dem Data Warehouse sowie für die
Übertragung der Daten erzeugt.
Bei der erstmaligen Ausführung des Datenimports müssen alle Daten geladen
werden. Dies hat eine erhöhte Belastung der Quellsysteme zur Folge, weshalb dieser
Prozess in einem Zeitraum gestartet werden sollte, in dem die notwendigen
Ressourcen zur Verfügung stehen, z.B. nachts oder am Wochenende.
Bei Änderungen im Quellsystem, nach dem initialen Extraktionsvorgang, ist es
möglich ein Delta-Verfahren (siehe Abschnitt 2.5.6) zu verwenden, um so nur noch
die Daten nachladen zu müssen, die seit dem letzten Extraktionsvorgang neu
hinzugekommen sind, sich verändert haben oder gelöscht wurden.
Um die Datenmenge weiter zu reduzieren ist es möglich, schon vor dem eigentlichen
ETL-Transformationsvorgang Abfragen und Transformationen direkt auf den Daten
im operativen Quellsystem durchzuführen. So kann die Anzahl der zu übertragenden
Datensätze, z.B. mittels View oder durch Änderungen an den Extraktionsstrukturen,
auf das Nötigste beschränkt werden, um damit auch die nachgelagerten ETL-
Prozesse schon im Vorfeld zu optimieren.
Transformation
Die Heterogenität der verschiedenen Quellsysteme führt in der Regel zu Problemen
bei der Überführung in das Data Warehouse.
Dies können beispielsweise folgende sein:
■ fehlende Werte
■ unterschiedliche Datentypen
■ unterschiedliche Formatierungen
■ verschiedene Attribute mit gleichem Attributnamen
■ unterschiedliche Werte für gleiche Attribute
■ Dubletten
■ redundante Datensätze
■ …
Diese Inkonsistenzen und fehlerhaften Daten gilt es zu beseitigen, um eine möglichst
hohe Datenqualität als Basis der nachfolgenden Prozesse zu erreichen. Denn nur
durch Datenkonsistenz und -qualität lässt sich das Vertrauen in die Daten steigern.
Zudem wird die Möglichkeit der Rückkopplung zu den operativen Systemen
geschaffen.
2 ETL-Prozess der Stammdatenbeschaffung
- 14 -
»Der Schlüssel zum Erfolg in der Implementierung und dem Betrieb von Business-
Intelligence-Applikationen liegt nicht in der erfolgreichen Implementierung
irgendwelcher Datenqualitätswerkzeuge, sondern im Management des Daten-
qualitätsprozesses, was eine kontinuierliche Aufgabe ist.«1
Laden
Die abschließende Phase des ETL-Prozesses befasst sich, nach der Extraktion,
Transformation und Bereinigung, mit dem Laden der ausgewählten Daten in das
Data Warehouse und den darin spezifizierten Datenzielen. Um Inkonsistenzen zu
vermeiden, werden während des Ladevorganges die zu übertragenden Tabellen
gesperrt. Das Laden der Daten belastet lediglich das Data Warehouse und nicht, wie
beim Extraktionsvorgang, das Quellsystem.
2.2 Stammdaten im SAP BW
Als Stammdaten werden im Allgemeinen jene Daten bezeichnet, die über einen
längeren Zeitraum unverändert bleiben. Oftmals sind es Informationen, die an
verschiedenen Stellen immer wieder benötigt werden.
Im SAP BW gibt es verschiedene Arten von Stammdaten2:
■ Texte
Mit bis zu drei Textbeschreibungen (Kurz-, Mittel- und Langtext) kann ein
Stammdatum näher beschrieben werden, wenn dessen Werte alleine nicht
ausreichend verständlich sind, z.B. bei Abkürzungen eines Länderschlüssels. Die
unterschiedlichen Längen der Texte sind deshalb sinnvoll, da auf der einen Seite
kürzere Texte u.a. bei Auswertungen übersichtlicher sind, wohingegen in anderen
Situationen längere Texte zum besseren Verständnis beitragen. Sie können
sprach- und zeitabhängig gespeichert werden, da auch in Bezug auf Stammdaten
Änderungen in einem Unternehmen auftreten können, z.B. beim Materialnamen
zu einer Materialnummer. Die Zeitabhängigkeit geht jedoch zu Lasten der
Performance und sollte daher nur sinnvoll angewendet werden.
■ Attribute
Attribute sind Felder, die Stammdaten mit Hilfe zusätzlicher Informationen näher
beschreiben. Beispiel für ein solches Attribut ist die Materialgruppe zu einer
Materialnummer. Attribute sind Objekte, die beliebig viele weitere Objekte (und
damit Attribute) besitzen können. So beinhaltet das Objekt Kunde als Attribute
beispielsweise den Kundennamen und die Kundenadresse. Attribute können,
ähnlich wie die Texte, zeitabhängig sein, d.h. sie besitzen einen definierten
Gültigkeitszeitraum.
1 Vgl. [Egger et al., 2005] S. 49
2 Siehe [Gómez et al., 2006] S.58 ff
2 ETL-Prozess der Stammdatenbeschaffung
- 15 -
■ Hierarchien
»Eine Hierarchie bildet eine Zusammenfassung und Gliederung eines Merkmals
nach individuellen Ordnungskriterien«1, z.B. die Kostenstellenhierarchie. In Form
einer Baumstruktur werden einzelne Knoten in die Hierarchie eingegliedert. Die
Bezeichnung und die Hierarchie selbst können zeit- und versionsabhängig
abgelegt werden, um so z.B. organisatorischen Änderungen Rechnung zu tragen.
2.3 Objektkonzept im SAP BW 3.x
In den folgenden Abschnitten wird das Objektkonzept des SAP Business Warehouse
3.x. näher beschrieben.2 Dabei werden alle wichtigen Objekte, die für die
Übertragung, Fortschreibung und Analyse der Daten notwendig sind, erläutert. Das
gesamte Datenmodell des Business Warehouse basiert auf diesen Objekten.
Der Datenfluss, also die Verknüpfung der einzelnen Objekte im Datenmodell, wird
in Abschnitt 2.5 erläutert.
Im Vergleich zum BW 3.x, gibt es im SAP BW 7.0 einige Änderungen bezüglich des
Datenflusses und der dafür benötigten Objekte. Auf die wesentlichen Unterschiede
wird im Abschnitt 2.6 kurz eingegangen.
InfoObject
InfoObjects sind die kleinsten Einheiten im SAP Business Warehouse. Sie werden
oft auch als betriebswirtschaftliche Auswertungsobjekte bezeichnet und bilden die
Basis aller größeren BW-Objekte.
Abbildung 2: Verwendung von InfoObjects im SAP BW
3
1 Vgl. [SAPBib3x, 2008]
2 Siehe [SAPBib3x, 2008], [BW310, 2005] S. 45ff, [Gómez et al., 2006] S.63 ff
3 In Anlehnung an [BW310, 2005] S.46
2 ETL-Prozess der Stammdatenbeschaffung
- 16 -
Es gibt unterschiedliche Typen von InfoObjects:
■ Kennzahl
■ Merkmal
■ Zeit
■ Einheit
■ Stammdatentragende Merkmale
Kennzahl
InfoObjects vom Typ „Kennzahl“ enthalten die Werte, die im späteren Verlauf
ausgewertet werden sollen, z.B. Menge, Betrag, Umsatz. Diese quantitativen Zahlen
müssen immer mit Merkmalen in Verbindung gebracht werden, da sonst ein Bezug
der Zahlen zu bestimmten Geschäftsvorfällen nicht möglich ist.
Kennzahlen werden in der Analyse mittels arithmetischer Operationen
zusammengefasst und ausgewertet. Sie können auch aus anderen Kennzahlen
abgeleitet werden, z.B. Bestandskennzahlen mit Hilfe der Bestandsveränderungen.
Merkmal
Merkmal-InfoObjects dienen dazu, die Kennzahlen zu beschreiben. Beispiele sind
Material, Kundengruppe, Produkt oder Lieferant. Ohne einen betriebs-
wirtschaftlichen Bezug der Kennzahlen zu bestimmen Merkmalen kann somit kein
sinnvolles Reporting durchgeführt werden.
Merkmale werden in den Dimensionen abgelegt und bestimmen damit die
Granularität (Feinheitsgrad) der Kennzahlen innerhalb eines multidimensionalen
Datenziels.
Stammdatentragendes Merkmal
Von stammdatentragenden Merkmalen spricht man, wenn Merkmale Attribute, Texte
oder Hierarchien besitzen. So ist es möglich, dass Merkmale beliebig viele Attribute
(in Form von InfoObjects) enthalten. Beispielsweise kann das Merkmal Kunde ein
InfoObject Kundenadresse (Merkmal) und ein InfoObject letzter Umsatz (Kennzahl)
enthalten.
Stammdatentragende Merkmale können darüber hinaus einerseits Datenziele für die
Speicherung von Daten im BW sein, andererseits als Datenquellen für Analysen
genutzt werden.
2 ETL-Prozess der Stammdatenbeschaffung
- 17 -
Zeit
Zeitmerkmale ermöglichen die Berücksichtigung eines zeitlichen Bezugs bei der
Analyse von Daten. Sie haben direkten Einfluss auf die Granularität. Beispiele für
zeitliche Merkmale sind Kalendertag, Kalenderjahr, Geschäftsjahr oder
Kalenderwoche.
Zeitmerkmale können zwar nicht neu definiert, jedoch modifiziert werden und bieten
darüber hinaus die Möglichkeit der automatischen Berechnung von Zeiten. So kann
z.B. auf Basis der Kalenderwoche, der Kalendermonat berechnet werden.
Einheit
Einheiten-InfoObjects werden dazu verwendet, Kennzahlen mit Einheiten zu
versehen, z.B. Währung oder Mengeneinheit.
DataSource
DataSources stellen das zentrale Element zur Datenbeschaffung dar.
»Eine DataSource beschreibt jeweils eine betriebwirtschaftliche Einheit von Stamm-
oder Bewegungsdaten (z.B. Kostenstellenrechnung), die aus einem Quellsystem
extrahiert werden kann.«1
In Abhängigkeit von den zu extrahierenden Daten unterscheidet man zwischen
DataSources für Bewegungsdaten, Attribute, Texte und Hierarchien.
Sie stellen zwei Feldstrukturen für die Extraktion und die Übertragung der Daten aus
dem Quellsystem zur Verfügung:
■ Extraktstruktur
Durch die sogenannten Extraktoren werden im Quellsystem die Daten in Form
einer Tabelle gesammelt. Die Felder dieser Tabelle bilden eine flache Struktur, die
sogenannte Extraktstruktur. Alle Daten in der Extraktstruktur sind lediglich
temporär gespeichert und werden unverändert an die Transferstruktur
weitergereicht.
■ Transferstruktur
Die Transferstruktur bildet den Übergang vom Quellsystem zum BW. Sie enthält
wahlweise alle oder nur einen ausgewählten Teil der Felder der Extraktstruktur.
InfoSource
Eine InfoSource beinhaltet alle Daten, die zu einem Geschäftsvorfall oder einer
bestimmten Art von betriebswirtschaftlichen Vorgängen gehören. Sie besteht aus
einer Vielzahl an InfoObjects, die zusammengefasst die sogenannte
Kommunikationsstruktur bilden. Dabei werden einer InfoSource eine oder mehrere
DataSources zugewiesen. Entsprechend der Kommunikationsstruktur der InfoSource,
können die Daten dann von der DataSource übernommen werden.
1 Vgl. [BW350, 2005] S.17
2 ETL-Prozess der Stammdatenbeschaffung
- 18 -
Die InfoSource stellt demnach eine Art Sammelstelle dar, an der die Daten
zusammengeführt, strukturiert, gefiltert und ggf. auch schon transformiert werden
können.
Persistent Staging Area
Die Persistent Staging Area (PSA) ist ein temporärer Zwischenspeicher. Beim
Übertragungsvorgang der Daten aus dem Quellsystem, werden die Daten
unverändert (bis auf technische Konvertierungen) in transparenten Tabellen abgelegt.
Auf diese Weise können die Quelldaten, die denen aus der Transferstruktur
entsprechen, bezüglich ihrer Qualität überprüft und bei Bedarf modifiziert werden.
Obwohl die Daten aus den PSA-Tabellen auch in einem späteren Prozess weiter
fortgeschrieben werden können, wird die PSA nicht zur dauerhaften Speicherung
verwendet, sondern als Zwischenspeicher verstanden.
Die Verwendung der PSA ist eine von zwei möglichen Transfermethoden im SAP
BW. Eine Alternative ist die IDOC Interface Technology (Intermediate Document).
Hierbei werden die Daten in IDOC-Container verpackt und anschließend verschickt.
Auch die PSA verwendet die IDOC-Schnittstelle, jedoch nur um Informationen
bezüglich des Quellsystems zu versenden, z.B. die Anzahl der Datensätze oder
Monitorinformationen.1
InfoCube
Der InfoCube dient der physischen Speicherung sowie der Bereitstellung der Daten
für die Analysen. Er ist das zentrale multidimensionale Objekt der Datenhaltung im
SAP BW und besteht aus InfoObjects (Kennzahlen und Merkmale), die nach dem
sogenannten „erweiterten Sternschema“2 miteinander verknüpft sind (siehe
Abbildung 3).
Dieses Schema, das auch als SAP BW Sternschema bezeichnet wird, besteht aus der
Faktentabelle, den Dimensionstabellen sowie den SID-Tabellen (Surrogat-ID). Die
Faktentabelle enthält die Fakten, also die Kennzahlen, die zu einer bestimmten
Merkmalkombination gehören. Die Dimensionstabellen werden über eine
Schlüsselbeziehung mit der Faktentabelle verknüpft.
1 Weiterführende Informationen siehe [SAPBib3x, 2008]
2 Siehe [BW310, 2005] S.25 ff
2 ETL-Prozess der Stammdatenbeschaffung
- 19 -
Abbildung 3: erweitertes Sternschema im SAP BW
1
Im Vergleich zum klassischen Sternschema ist das SAP BW Sternschema um die
SID-Tabellen erweitert worden, was bedeutet, dass die Dimensionstabellen nicht
länger die Stammdaten (Attribute, Texte, Hierarchien) enthalten. Diese befinden sich
in den sogenannten Stammdatentabellen und werden über die SID-Tabelle mit den
Dimensionstabellen verknüpft. So generiert das System zu jedem Merkmal einen
Schlüssel, der anstelle der eigentlichen Ausprägung in die Dimensionstabelle
eingefügt wird.
Diese Technik erlaubt es die Stammdaten aus dem Cube auszulagern. So sind sie
cube-unabhängig und können von verschiedenen InfoCubes gemeinsam verwendet
werden.
Der normale InfoCube wird oftmals auch als Basis-InfoCube bezeichnet. Daneben
existiert der transaktionale InfoCube. Dieser ist für (parallele) Schreibzugriffe
optimiert, wohingegen der Basis-InfoCube seine Stärken im Lesen der Daten, also im
Bereich der Auswertungen und Analysen, hat.
Die beiden genannten InfoCubes stellen eine physische Datenspeicherung im SAP
BW dar. Zusätzlich gibt es virtuelle InfoCubes. Diese besitzen selbst keine Daten,
sondern greifen direkt auf das Quellsystem zu und bilden damit eine logische Sicht
auf das vorhandene Datenmaterial.
1 In Anlehung an [BW310, 2005] S.34
2 ETL-Prozess der Stammdatenbeschaffung
- 20 -
Operational Data Store
»Ein ODS-Objekt dient der Ablage von konsolidierten und bereinigten Daten (z.B.
Bewegungsdaten oder Stammdaten) auf Belegebene (atomarer Ebene).«1
Im Vergleich zu InfoCubes (mit ihren Fakten- und Dimensionstabellen) ist ein ODS-
Objekt lediglich durch (eine) flache Tabelle(n) repräsentiert. Es gibt Schlüssel- und
Datenfelder, deren Anordnung, je nach Datenumfang, eine beträchtliche Satzlänge
zur Folge haben kann.
ODS-Objekte erlauben im Gegensatz zu den InfoCubes eine Veränderung der
vorhandenen Daten. In InfoCubes ist prinzipiell nur das Einfügen und das Löschen
auf Basis von Requests vorgesehen, während in ODS-Objekten die Daten auch
während des Durchladevorganges geändert werden können.
Standard-ODS-Objekte können ebenfalls mittels Abfragen ausgewertet werden.
Alternativ bilden sie die Grundlage für die Weiterverarbeitung im SAP BW, indem
die Daten z.B. in weitere ODS-Objekte oder InfoCubes fortgeschrieben werden.
Darüber hinaus gibt es transaktionale ODS-Objekte. Diese unterscheiden sich von
den Standard-ODS-Objekten in der Form, dass sie die Daten in nur einer Version zur
Verfügung stellen. Standard-ODS-Objekte besitzen mehrere Tabellen mit aktiven
und modifizierten Daten, sowie dem Delta zu den schon vorhandenen Einträgen.
InfoSet
Ein InfoSet ist ein weiteres Objekt im SAP BW, mit dessen Hilfe Abfragen
durchgeführt werden können. InfoSets speichern jedoch keine Daten, sondern greifen
mittels Join-Operationen auf vorhandene InfoCubes, ODS-Objekte oder Merkmale
zu.
Sinnvoll eingesetzt werden InfoSets vor allem in Bereichen, in denen Analysen sehr
spezifisch sind und so selten eingesetzt werden, dass eine separate physische
Speicherung der Daten unnötig ist. InfoSets beschränken sich jedoch auf die reine
Präsentation der Ergebnisse. Navigationen, die Verwendung von Hierarchien sowie
die Währungsumrechnung sind nicht möglich. In Kombination mit der sehr
schlechten Performance gilt es im Einzelfall abzuwägen, ob der Einsatz eines
InfoProviders2, z.B. InfoCube oder ODS-Objekt, bei häufiger Verwendung nicht
sinnvoller wäre.3
MultiProvider
MultiProvider sind InfoProvider, die aus mehreren anderen InfoProvidern
zusammengesetzt werden. So kann ein MultiProvider aus mehreren Objekten, wie
1 Vgl. [SAPBib3x, 2008]
2 InfoProvider ist ein Oberbegriff für alle Objekte auf die Anfragen durchgeführt werden können.
3 Siehe [Gómez et al., 2006] S.66
2 ETL-Prozess der Stammdatenbeschaffung
- 21 -
InfoCubes, ODS-Objekte oder InfoObjects bestehen. Die einzelnen Objekte werden
dabei, anders als die InfoSets, mit Hilfe der Union-Operation miteinander verknüpft.
Sinnvoll eingesetzt werden Multiprovider dort, wo aus technischen oder
designtechnischen Gründen der Datenbestand auf mehrere InfoProvider aufgeteilt
werden muss, z.B. aufgrund der Leistungsfähigkeit des Systems. So können, zum
Zweck des Reportings, alle beteiligten Objekte wieder zusammengefügt und
anschließend analysiert werden.
Somit stellen Multiprovider, wie auch die InfoSets, lediglich eine logische Sicht über
die Objekte dar, beeinflussen deren Funktion jedoch nicht und beinhalten selbst
keine Daten.
InfoPackage
Mit Hilfe eines InfoPackages wird definiert, welche Daten wann und wie vom
Quellsystem über eine DataSource ins BW angefordert werden sollen. Dabei kann
man mit Hilfe von Selektionsbedingungen die Menge der Daten einschränken und
über Hintergrundjobs den zeitlichen Ablauf des Durchladevorganges bestimmen.
Zusätzlich kann über die Durchführung eines Delta-Verfahrens sowie die
Verwendung einer PSA entschieden werden.
Details werden in Abschnitt 2.5 näher erläutert.
2.4 Business Content
»Der Business Content des SAP BW bietet vorkonfigurierte, auf konsistente
Metadaten basierende rollen- und aufgabenbezogene Informationsmodelle. Er stellt
den Benutzern in einem Unternehmen das Angebot an Informationen [und Objekten]
zur Verfügung, das sie zur Erfüllung ihrer Aufgaben benötigen.«1
Der Business Content enhält:
■ InfoCubes
■ Kennzahlen
■ Merkmale
■ Fortschreibungsregeln
■ Queries
■ Benutzerrollen
■ Arbeitsmappen
■ Extraktoren
■ …
1 Vgl. [Seemann et al., 2001] S.197
2 ETL-Prozess der Stammdatenbeschaffung
- 22 -
Durch die Verwendung des Business Content können der administrative Aufwand
und die damit verursachten Kosten deutlich gesenkt werden. So ist es nicht nötig, bei
der Modellierung im SAP BW alles von Grund auf neu zu entwerfen, da viele
branchenspezifische Objekte und Modelle bereits vorhanden sind und genutzt
werden können.
Obwohl der Business Content von SAP, in ständigem Kontakt mit den Kunden,
weiterentwickelt und aktualisiert wird, ist eine kundenabhängige Anpassung oftmals
notwendig. Dabei gilt es abzuwägen, ob es sinnvoller ist, bestimmte Modelle selbst
anzulegen oder ein Customizing des vorhandenen Business Content durchzuführen.
2.5 ETL-Prozess für Stammdaten im SAP BW 3.x
Neben den bereits erläuterten BW-Objekten sind weitere Komponenten für den ETL-
Prozess von Bedeutung. So z.B. die Übertragungs- und Fortschreibungsregeln, aber
auch die Auswahl bestimmter Verfahren, wie das Delta-Verfahren, die Entscheidung
zwischen direkter und flexibler Fortschreibung oder die verschiedenen
Verbuchungsarten.
Abbildung 4: Beispiel – Datenfluss im SAP BW
Zur besseren Einordnung der Komponenten in den ETL-Prozess wird ein möglicher
Zusammenhang zwischen den verschiedenen BW-Objekten sowie deren Verbindung
mittels Übertragungs- und Fortschreibungsregeln vereinfacht in Abbildung 4
dargestellt.
Aus dem Quellsystem werden die Daten mit Hilfe des Extraktors in die Struktur
einer DataSource übertragen. Über die Logik der Übertragungsregeln erfolgt die
Transformation in eine InfoSource, um dann alle Daten in ein Datenziel, z.B. ein
ODS-Objekt, abzulegen. Abschließend erfolgt eine erneute Fortschreibung in einen
InfoProvider (InfoCube), so dass die Daten mit Hilfe von Analysewerkzeugen
ausgewertet werden können.
Die Funktionsweise von Übertragungs- und Fortschreibungsregeln wird in den
folgenden Abschnitten erläutert.
2 ETL-Prozess der Stammdatenbeschaffung
- 23 -
2.5.1 Übertragungsregeln
Die Logik, wie die Daten von einer DataSource (Transferstruktur) zu einer
InfoSource (Kommunikationsstruktur) übertragen werden, ist in den
Übertragungsregeln definiert.
Zunächst wird das sogenannte Mapping vorgenommen, in dem festgelegt wird,
welche Felder der Transferstruktur in welche Felder der Kommunikationsstruktur
übertragen werden (spaltenweise Zuordnung). Anschließend kann für jede
Zuordnung ein Übertragungsverfahren ausgewählt werden.
Folgende Übertragungsverfahren sind möglich:1
■ Direkte Übernahme (1:1-Regel)
■ Zuweisung eines konstanten Wertes
■ Transformation mittels ABAP-Routine
■ Berechnungen mit Hilfe von Formeln
In Abbildung 5 werden die Übertragungsregeln in einem größeren Zusammenhang
dargestellt. Der Ablauf von der Quelle bis zur InfoSource ist demnach wie folgt
aufgebaut:
Abbildung 5: Übertragungsregeln
2
1 Siehe [Egger et al., 2005] S.56
2 In Anlehnung an [BW350, 2005] S.18
2 ETL-Prozess der Stammdatenbeschaffung
- 24 -
Werden die Daten aus einem SAP-Quellsystem bereitgestellt, so geschieht dies über
eine DataSource, die schon vorhanden ist oder angelegt werden muss. Diese
DataSource enthält die Extrakt- sowie die daraus abgeleitete Transferstruktur. Durch
den Vorgang der Replikation wird die DataSource im SAP BW bekannt gemacht und
steht dort mit der identischen Transferstruktur zur Verfügung. Mit Hilfe der
Übertragungsregeln wird die Transferstruktur mit der Kommunikationsstruktur
„gemapped“ sowie die Art der Übertragung festgelegt.
Handelt es sich bei der Datenquelle alternativ um eine flache Datei, so wird eine
DataSource im SAP BW erzeugt, die der Struktur der Datei entspricht. Anschließend
wird erneut mit Hilfe der Übertragungsregeln festgelegt, wie die Daten in die
InfoSource übertragen werden sollen.
Eine InfoSource kann mehrere Quellen besitzen. Es ist jedoch wichtig zu beachten,
dass eine DataSource immer nur einer InfoSource zugeordnet sein darf.
2.5.2 Fortschreibungsregeln
Die Fortschreibungsregeln dienen der Definition, wie Daten von einer InfoSource in
ein Datenziel oder einen InfoProvider fortgeschrieben werden sollen. Dabei ist die
Art und der Aufbau des InfoProviders von Bedeutung.
Für Kennzahlen (bei InfoCubes), Datenfelder (bei ODS-Objekten) und Attribute (bei
InfoObjects) gibt es folgende grundlegende Fortschreibungsarten:1
■ Keine Fortschreibung
■ Addition
■ Minimum
■ Maximum
■ Überschreiben (bei ODS-Objekten)
Je Kennzahl können anschließend die folgenden Regeln für die Fortschreibung der
Merkmale (bei InfoCubes) bzw. Schlüsselfelder (bei ODS-Objekten und
InfoObjects) angelegt werden:
■ Direkte Übernahme (1:1-Regel)
■ Zuweisung eines konstanten Wertes
■ Transformation mittels ABAP-Routine
■ Berechnungen mit Hilfe von Formeln
1 Siehe [Egger et al., 2005] S.56
2 ETL-Prozess der Stammdatenbeschaffung
- 25 -
Das folgende Beispiel soll den Vorgang der Fortschreibungsregeln veranschaulichen:
Abbildung 6: Fortschreibungsregeln
Im Beispiel liefert die DataSource einen Datensatz 1 und einen Datensatz 2. Beide
Datensätze besitzen dieselben Merkmalwerte. Aus diesem Grund werden die
Kennzahlen, bei einer Fortschreibungsregel Addition, während der Übertragung in
den InfoCube miteinander verrechnet.
Die Merkmale PLZ und Typ in der DataSource weisen eine andere Bezeichnung als
die korrespondierenden Merkmale im InfoCube auf. Mit Hilfe des Mappings und der
1:1-Zuordung der entsprechenden Felder, ist die korrekte Zuweisung der Daten
jedoch kein Problem.
»Im Allgemeinen kann empfohlen werden, die Übertragungsregeln zur Herstellung
einer hinreichenden Datenhygiene und die Fortschreibungsregeln für logische
Umsetzungen zu verwenden. Dieser (nicht durch SAP vorgegebene) Ansatz hat den
Vorteil, dass die Daten sofort „am Eingang“ zum SAP BW bereinigt werden. Somit
entfallen ggf. erforderliche redundante Bereinigungsfunktionen und die Gefahr,
Bereinigungen nicht an allen erforderlichen Stellen vorzunehmen und damit
inkonsistente und fehlerhafte Daten für das Reporting bereitzustellen«1
2.5.3 Direkte Fortschreibung
Eine direkte Fortschreibung ermöglicht es, Daten direkt, ohne Verwendung von
Fortschreibungsregeln, in die Stammdatentabellen eines gewählten Merkmals zu
speichern (siehe Abbildung 7). In dieser Situation repräsentiert das Merkmal selbst
die InfoSource, wodurch die Daten sofort in das Datenziel gespeichert werden.
1 Vgl. [Egger et al., 2005] S.57
2 ETL-Prozess der Stammdatenbeschaffung
- 26 -
Abbildung 7: Direkte Fortschreibung
1
Die Methode arbeitet zwar performanter als die flexible Fortschreibung, jedoch ist es
so nicht möglich, Daten aus mehreren Datenquellen zu konsolidieren und sie
anschließend in verschiedene Datenziele zu speichern.
2.5.4 Flexible Fortschreibung
Wie aus Abbildung 8 deutlich wird, ermöglicht die flexible Fortschreibung das
Ablegen der Daten in alle verfügbaren BW-Objekte, die als Datenziel geeignet sind.
Darüber hinaus können verschiedene Quellen (z.B. auch Bewegungsdaten) auf Ebene
der InfoSource zusammengeführt werden. So hat man die Möglichkeit nicht nur
innerhalb der Übertragungsregeln auf die Daten zuzugreifen, sondern auch mit Hilfe
der Fortschreibungsregeln, um so den Datenbestand an die individuellen
Erfordernisse des Datenziels anzupassen.2
1 In Anlehnung an [BW310, 2005] S.177
2 Siehe [BW310, 2005] S.178
2 ETL-Prozess der Stammdatenbeschaffung
- 27 -
Abbildung 8: Flexible Fortschreibung
1
2.5.5 Verbuchungsarten
Wird in den Übertragungsregeln die Transfermethode PSA ausgewählt, stehen, im
Gegensatz zur IDOC-Methode, verschiedene Verbuchungsarten zur Verfügung. Die
Art der Verbuchung wird über das InfoPackage konfiguriert. Bei der Wahl der
Datenverbuchung gilt es, wie so oft im Umfeld des SAP BW, einen Kompromiss
zwischen Datensicherheit und Performanz beim Ladeprozess zu finden.2
1 In Anlehnung an [BW310, 2005] S.178
2 Siehe [SAPBib3x, 2008]
2 ETL-Prozess der Stammdatenbeschaffung
- 28 -
Verarbeitungsoption Erläuterung
PSA und Datenziele parallel
Die Verbuchung der Daten erfolgt bei dieser Verarbeitungs-option paketweise parallel. Dabei werden die Daten nach erfolgreichem Verbuchen in die PSA, mit Hilfe eines zweiten Prozesses, parallel in die Datenziele geschrieben.
Diese Methode wird verwendet, um Daten performant in die Datenziele zu schreiben.
PSA und anschließend Datenziele
Diese Option arbeitet mit nur einem Prozess pro Datenpaket. Nachdem die Daten erfolgreich in die PSA verbucht wurden, schreibt derselbe Prozess die Daten anschließend in die Datenziele. Die Verarbeitung erfolgt somit paketweise seriell.
Vorteil dieser Methode ist die bessere Kontrolle über den gesamten Datenfluss, da nur ein Prozess pro Datenpaket verwendet wird.
Nur PSA Bei dieser Verarbeitungsoption werden die Daten nur in die PSA geschrieben, aber nicht weiter verbucht. Man kann jedoch automatisch oder manuell die Daten in die Datenziele verbuchen. Dafür wird jedoch nur ein Prozess pro Request gestartet, der nacheinander die Daten in die Datenziele schreibt. Die Verarbeitung erfolgt demnach requestweise seriell.
Vorteil dieser Methode ist die sichere Ablage der Daten im BW, ohne dass sich die Einstellungen im Quellsystem, bezüglich der Anzahl an maximalen Prozessen, auf die Anzahl der Prozesse im BW auswirken.
Tabelle 1: Verbuchungsarten1
2.5.6 Delta-Verfahren
Werden sehr große Datenmengen aus den Quellsystemen geladen, führt dies nicht
nur zu einer hohen Belastung der Hardware und Systemressourcen, sondern ist auch
mit teilweise langen Wartezeiten verbunden. Um nicht bei jeder Aktualisierung der
Datenbestände alle Daten erneut laden zu müssen ist es möglich, das sogenannte
Delta-Verfahren anzuwenden. Dabei werden nur die Datensätze übertragen, die sich
seit der letzten Aktualisierung verändert haben oder neu hinzugekommen sind. Diese
werden in eine Tabelle, die als Delta-Queue bezeichnet wird, übertragen, sobald es
zu einer Änderung an den betroffenen Daten im Quellsystem kommt.2
Durch das Delta-Verfahren wird die Menge an zu übertragenden Daten und somit
auch die Systembelastung massiv gesenkt. Bei den derzeitigen Größenordungen der
Massendaten, ist der Betrieb eines Data Warehouses in der Praxis, ohne die
Verwendung des Delta-Verfahrens, nur noch selten denkbar.
1 Siehe [SAPBib3x, 2008]
2 Je nach Quelle arbeitet das Deltaverfahren auch ohne eine Delta-Queue
2 ETL-Prozess der Stammdatenbeschaffung
- 29 -
Aufgrund der Komplexität der Thematik wird an dieser Stelle lediglich das Delta-
Verfahren in Bezug auf ein SAP Quellsystem beschrieben.1
Ob ein Delta-Verfahren angewendet werden kann oder nicht, hängt von der jeweils
verwendeten DataSource ab. Diese ist entweder „von Haus aus“ deltafähig, kann um
eine Delta-Fähigkeit erweitert werden oder ist generell nicht deltafähig.
Handelt es sich bei der DataSource um eine Datenquelle aus dem SAP BW, ist ein
Delta-Verfahren immer möglich. Bei DataSources eines SAP Quellsystems verhält
es sich wie folgt: Ist die DataSource Bestandteil des Business Content, so kann oft
ein Delta-Verfahren angewandt werden. Jedoch sind nicht alle Business Content
DataSources deltafähig. Erzeugt man, in Form von generischen Extraktoren, eigene
DataSources im Quellsystem, so ist ein Delta möglich, jedoch nicht automatisch
integriert.
Bei nicht deltafähigen DataSources kann es dennoch möglich sein, in Abhängigkeit
von den angeforderten Daten und unter Verwendung spezifischer Selektions-
bedingungen, nur neue oder geänderte Daten in das SAP BW zu übertragen. Dieses
Verfahren als solches wird jedoch nicht den Delta-Verfahren zugeordnet.2
Im Bezug auf Stammdaten erzeugen manche DataSources das Delta anhand von
ALE-Änderungszeigern (Applikation Link Enabling). Diese Technik arbeitet
unabhängig von einer Delta-Queue, indem Änderungen an definierten Tabellen
protokolliert werden.
Die Verwendung des Delta-Verfahrens wird in den InfoPackages gesteuert und
initialisiert. Folgende Fortschreibungsmodi (Updatemodi) können ausgewählt
werden:
■ Full-Update
Bei einem Full-Update werden alle Daten entsprechend der Selektionskriterien im
InfoPackage übertragen.
■ Initialisierung des Delta-Verfahrens
Die Initialisierung des Delta-Verfahrens ist die Voraussetzung für die Durchführung
von Delta-Updates. Wenn sich die Selektionsbedingungen und damit die Datensätze
nicht überlappen, kann auch mehrmals ein Delta-Verfahren initialisiert werden. So
ist es z.B. möglich, aufgrund großer Datenmengen, die Initialisierung des Delta-
Verfahrens schrittweise umzusetzen.
■ Delta-Update
Wie bereits erwähnt, ist für das Delta-Update die Initialisierung zwingend
notwendig. Ist dies geschehen, werden mit diesem Updatemodus nur die Daten
übertragen, die sich seit der letzten Aktualisierung verändert haben oder neu
hinzugekommen sind.
1 Weiterführende Informationen siehe [BW350, 2005] S.153ff
2 Siehe [BW350, 2005] S.153
2 ETL-Prozess der Stammdatenbeschaffung
- 30 -
■ Wiederholung eines Delta-Updates
Mit dieser Funktion kann das Delta-Update wiederholt werden, sollte es beim
vorherigen Ladevorgang zu einem Fehler gekommen sein.
■ Early-Delta-Initialisierung
Die Early-Delta-Initialisierung ermöglicht es, ein Delta-Init durchzuführen und
gleichzeitig die aktuellen Änderungen im Quellsystem mit Hilfe der Delta-Queue
aufzuzeichnen. So kann im Quellsystem weitergearbeitet werden, ohne das
Änderungen verloren gehen. Bei der Ausführung der „normalen“ Delta-
Initialisierung muss die Belegbearbeitung in vielen Anwendungen ruhen. Die
Möglichkeit der Early-Delta-Initialisierung ist nicht obligatorisch, sondern muss von
der DataSource unterstützt werden.
DataSources verwenden, je nach Struktur der Daten, unterschiedliche Delta-
Verfahren. Welches Verfahren verwendet wird kann über die Tabellen
ROOSOURCE (im Quellsystem) oder RSOLTPSOURCE (im BW) festgestellt
werden. Welche Eigenschaften ein Delta-Verfahren besitzt, ist in der Tabelle
RODELTAM (sowohl im BW als auch im Quellsystem) definiert. Die Eigenschaften
entscheiden z.B. darüber,
■ welche Datensätze in der Delta-Queue stehen,
■ wie neue oder geänderte Datensätze in die Delta-Queue gelangen,
■ ob Änderungen in ihrer ursprünglichen Reihenfolge bereitgestellt werden,
■ ob der Extraktor oder die Anwendung das Delta zur Verfügung stellt und
■ wie Änderungen in Datensätzen aufgezeichnet werden (z.B. bei Mengen-
änderungen in einem Auftrag)
Aufgrund der Vielzahl an Ausprägungen können die verschiedenen Delta-Verfahren
an dieser Stelle nicht im Detail erläutert werden.1
2.6 Änderungen im BW 7.0
Wie der Sprung von 3.x auf 7.0 verdeutlicht, kam es mit der neuen Version des SAP
BW zu einer Vielzahl an Neuerungen und Änderungen. Auf alle diese Änderungen
kann jedoch an dieser Stelle nicht eingegangen werden.2 Trotz aller Neuerungen
haben sich die grundlegenden Konzepte jedoch nur wenig verändert.
Dieser Abschnitt soll daher lediglich einen kurzen Überblick über die wesentlichen
Änderungen im SAP BW 7.0 bezüglich des neuen Objektkonzeptes und Datenflusses
bieten.3
1 Weiterführende Informationen siehe [BW350, 2005] S.173ff
2 Weiterführende Informationen siehe [SAPBib3xDelta7, 2008]
3 Siehe [SAPBib7, 2008], [Mehrwald, 2007]
2 ETL-Prozess der Stammdatenbeschaffung
- 31 -
Zu beachten ist, dass die aus der Version 3.x bekannten Konzepte und Technologien
bezüglich des Datenflusses weiterhin unterstützt werden. Die Vorteile in der neuen
Konzeption im SAP BW 7.0 sind jedoch groß genug, so dass sie durch eine
Migration der vorhandenen Datenmodelle genutzt werden sollten.
DataSource
Bisher war die Übertragung von Daten erst nach der Zuordnung einer InfoSource zu
einer DataSource und dem Anlegen und Aktivieren von Übertragungsregeln
möglich. Nur so wurde eine PSA-Tabelle erzeugt, in die Daten geladen werden
konnten.
Im SAP BW 7.0 hat sich das Konzept der DataSources (im Zusammenhang mit den
anderen Änderungen im Datenfluss) geändert. Mit Aktivierung einer DataSource
wird automatisch eine PSA-Tabelle in der Eingangsschicht des SAP BW erzeugt,
wodurch sofort Daten geladen werden können. In welche Datenziele die Daten später
gespeichert werden sollen, wird in dem neuen Konzept der Transformation
festgelegt.
Bei der Replikation von BI Content DataSources entscheidet zumeist das System, ob
als Ergebnis eine „neue“ DataSource oder eine DataSource vom Typ 3.x erstellt
wird. Bei generischen, selbst erstellten DataSources entscheidet der Benutzer
darüber. Vorhandene DataSources können bei Bedarf auf das neue Konzept migriert
werden.
Persistent Staging Area
Wie aus den Ausführungen zu den DataSources deutlich wird, sind PSA und
DataSource nun enger miteinander verknüpft. Die PSA ist im BW 7.0 nicht länger
optional, sondern zwingend erforderlich und wird automatisch mit der Aktivierung
der DataSource erzeugt. Auch die Verwaltung der PSA erfolgt über die DataSource.
Transformation
In SAP BW 3.x wurde der Datenfluss bisher über die Übertragungs- und
Fortschreibungsregeln in Kombination mit einer InfoSource definiert. Diese Aufgabe
wird im SAP BW 7.0 von dem neuen Konzept der Transformationen übernommen.
Dabei werden Quelle, InfoSource (beliebig viele) und Ziel mit je einer
Transformation verbunden.
Im Zusammenhang mit den Transformationen und Routinen sollte nicht unerwähnt
bleiben, dass die Verwendung der Programmiersprache ABAP Objects im SAP BW
7.0 empfohlen wird. Zwar kann auch weiterhin mit dem klassischen ABAP
programmiert werden, jedoch kann dies ggf. zu einem deutlichen Mehraufwand
führen.
InfoSource
InfoSources vom Typ 3.x können nicht von einer Transformation verwendet werden.
Durch Migration der InfoSource auf die „neue“ InfoSource, kann jedoch auch auf
2 ETL-Prozess der Stammdatenbeschaffung
- 32 -
Grundlage der Übertragungs- und Fortschreibungsregeln automatisch eine
Transformation erzeugt werden.
Datentransferprozess & InfoPackage
Der Datentransferprozess (DTP) löst das aus dem SAP BW 3.x bekannte
InfoPackage teilweise ab. Während das InfoPackage ab sofort ausschließlich für den
Datenfluss bis zur PSA zuständig ist, übernimmt der DTP die Übertragung der Daten
innerhalb des BW zwischen den Objekten (siehe Abbildung 9).
Datenfluss
Die Änderungen im Datenfluss sowie die Einführung der neuen Konzepte sind in der
folgenden Abbildung noch einmal dargestellt:
Abbildung 9: Datenfluss im SAP BW 7.0
1
Die Daten werden aus den verschiedenen Quellsystemen mit Hilfe der InfoPackages
in die PSA-Tabellen der DataSource geladen. Ab der Ebene der DataSources
übernehmen die Datentransferprozesse die Ausführung und Steuerung der
Ladevorgänge. Die Transformationen ersetzen die Übertragungs- und
Fortschreibungsregeln. Werden mehrere InfoSources hintereinander geschaltet,
geschieht dies ebenfalls über eine Transformation. Auch zwischen verschiedenen
InfoProvidern ist der Einsatz einer Transformation notwendig.
1 In Anlehnung an [SAPBib7, 2008]
3 Analyse-Prozess-Designer
- 33 -
3 Analyse-Prozess-Designer
Im SAP BW werden Daten aus verschiedenen Quellen (Datenbanktabellen, externe
Systeme, flache Dateien) gesammelt, konsolidiert, verwaltet und für spätere
Analysen und Auswertungen zur Verfügung gestellt.
In den bereits im BW vorliegenden Daten steckt jedoch noch ein weitaus höheres,
unentdecktes und ggf. für das Unternehmen wertvolles Potential.
»Dabei handelt es sich um vollkommen neue Informationen, die sich in Form von
sinnvollen Zusammenhängen zwischen den Daten darstellen, jedoch zu verborgen
oder komplex sind, um durch reines Betrachten oder Intuition aufgedeckt zu
werden.«1
Abbildung 10: Zentrale Funktionen des APD
2
Der Analyse-Prozess-Designer stellt einen strukturierten Werkzeugkasten zur
Verfügung, um diese versteckten und komplexen Zusammenhänge und Beziehungen
1 Vgl. [SAPBib3x, 2008]
2 In Anlehnung an [BW380, 2005] S.29
3 Analyse-Prozess-Designer
- 34 -
zwischen den Daten sichtbar zu machen und um damit vollkommen neue
Informationen zu gewinnen.
»Über Analyseprozesse ist es möglich, die Informationsplattform […] für strate-
gische, taktische und operative Entscheidungen zu ergänzen.«1
Mit Hilfe der APD Workbench können selbst komplexe analytische Prozesse einfach
mittels „Drag&Drop“ modelliert, gesteuert und überwacht werden.
Durch gezielte Transformationstechniken und die Anbindung an verschiedene Data-
Mining-Verfahren steht dem Anwender eine Vielzahl an Möglichkeiten offen, neue
Informationen zu schaffen und zu entdecken, die für Unternehmen von enormer
Bedeutung sein können.
3.1 Integration des APD in das SAP BW
Der APD ist vollständig in die Administrator Workbench des Business Warehouse
integriert. Dieser Umstand ermöglicht es im APD eine Vielzahl an BW-Objekten
ohne Umwege als Datenquelle und Datenziele zu verwenden. Somit sind die
Analyseprozesse auch in das Konzept der Versionierung (aktive, inaktive Version,
Contentversion, Auslieferungsversion) und des Transportanschlusses2 eingebunden.
Da der APD nur auf eine Datenbank und nicht auf mehrere verschiedene
Quellsysteme zugreift, werden mögliche Probleme bezüglich der Datenintegrität,
Datenqualität und Systemperformance deutlich vermindert.
3.2 Prozessphasen
Die Aufgaben des APD sowie der Modellierung von analytischen Prozessen
veranschaulicht Abbildung 11.
Zunächst gilt es, eine geeignete Auswahl an Daten und Datenquellen zu treffen, um
diese im anschließenden Prozess, je nach Zielsetzung, miteinander zu verknüpfen, zu
aggregieren, einzuschränken, zu erweitern oder anderweitig zu transformieren. Diese
vorbereitenden Maßnahmen haben eine sehr hohe Bedeutung für die Ergebnisse des
Analyseprozesses. Denn nur qualitativ hochwertige Eingangsdaten, als Basis des
Modells, können zu guten Auswertungen und Endergebnissen führen.
Da viele verschiedene Transformationsschritte aufeinander folgen können, machen
diese auch einen Großteil des späteren Prozessmodells aus.
Bevor die neu gewonnenen Ergebnisse und Daten verwendet werden können (z.B.
durch Queries), müssen diese in geeigneten Datenzielen abgelegt werden.
1 Vgl. [BW380, 2005] S.27
2 Siehe auch Abschnitt 12, Glossar, auf Seite 104
3 Analyse-Prozess-Designer
- 35 -
Abbildung 11: Schritte im Analyse-Prozess-Designer
1
Auf einer höheren Abstraktionsebene lassen sich die o.g. Schritte grob in 3
Prozessphasen einteilen:2
■ Datenquelle
Festlegen der Quellen, aus denen die Daten zur weiteren Verwendung extrahiert
werden sollen.
■ Transformation
Auf- und vorbereiten der extrahierten Daten durch verschiedene Transformations-
schritte.
■ Datenziel
Speichern der Ergebnisse in geeigneten Datenzielen für die spätere Analyse und
Präsentation.
3.2.1 Phase 1 - Datenquellen
In der ersten Phase des Analyseprozesses werden die Datenquellen definiert.
Entsprechend der Anforderungen an den Analyseprozess wird festgelegt, welche
Daten woher zur Verfügung gestellt werden. Dabei werden die Daten jedoch nicht
„eingelesen“, sondern es wird, wie im gesamten Modellierungsprozess, lediglich die
Struktur des Analyseprozesses festgelegt. Das Einlesen und Laden der Daten findet
erst beim Starten des fertig modellierten Analyse-Prozesses statt. Zwischendurch
besteht die Möglichkeit, die Daten und damit den bisher erstellten Analyseprozess zu
überprüfen. Hierbei werden jedoch nur die ersten ca. 2000 Datensätze ausgegeben,
anhand derer bei Bedarf der richtige Ablauf festgestellt werden kann.
1 In Anlehnung an [SAPBib3x, 2008]
2 Vgl. [KiVA, 2007] S.40
3 Analyse-Prozess-Designer
- 36 -
In Abhängigkeit von der Anwendung und dem eingesetzten BW-System1, stehen
folgende Möglichkeiten zur Verfügung:
■ Attribute eines Merkmals lesen
■ Daten aus InfoProvider lesen
■ Daten über Query lesen
■ Daten aus Datei lesen
■ Daten aus Datenbanktabelle lesen
Die genannten Datenquellen werden in den folgenden Abschnitten näher erläutert.
Attribute eines Merkmals lesen 2
Mit Hilfe dieses Datenquellentyps können aus einem ausgewählten Merkmal
(InfoObject) alle aktiven Stammdaten sowie die zugehörigen zeitabhängigen und
zeitunabhängigen Attribute ausgelesen werden.
Daten aus InfoProvider lesen
Dieser Datenquellentyp ermöglicht die Datenbereitstellung durch InfoProvider. Nach
geltender SAP-Festlegung können dies
■ InfoCubes
■ DataStore-Objekte (DSO bzw. ODS3)
■ InfoObjects als InfoProvider
■ Multiprovider oder
■ InfoSets
sein. In Abhängigkeit vom gewählten InfoProvider können diejenigen Merkmale und
Kennzahlen ausgewählt werden, die für den weiteren Analyseprozess verwendet
werden sollen.
Zu beachten ist, dass die Daten in einfacher Tabellenform zur Verfügung gestellt
werden, d.h., es werden keine Abhängigkeiten von Merkmalen und Kennzahlen
berücksichtigt.
Auch bezüglich des Aggregationsverhaltens gilt es einige Besonderheiten zu
beachten. So werden Kennzahlen ausschließlich per Standardaggregation verdichtet.
Eine Ausnahmeaggregation4 kann nur über nachfolgende Prozessschritte
durchgeführt werden.
1 Siehe auch Abschnitt 3.8, Unterschiede zwischen den Versionen des APD, auf Seite 53
2 Die Darstellung der Symbole entspricht der SAP BW Version 7.0
3 Bezeichnung im SAP BW 3.x
4 Siehe auch Abschnitt 12, Glossar, auf Seite 104
3 Analyse-Prozess-Designer
- 37 -
Daten über Query lesen
Mit diesem Datenquellentyp ist es möglich, Daten aus einer BW Query zu erhalten.
Alle Felder der Query werden dabei ausgelesen und zur weiteren Verwendung zur
Verfügung gestellt. Die Query muss jedoch zwingend ODBO-fähig (OLE DB for
OLAP) sein, d.h. der externe Zugriff auf die Query wird zugelassen1.
Daten aus Datei lesen
Mit diesem Knoten können Daten aus flachen Dateien im ASCII- (American
Standard Code for Information Interchange) oder CSV-Format (Comma Separated
Value) gelesen werden. Die einzulesende Datei kann sich dabei entweder auf dem
Applikationsserver oder dem lokalen Rechner befinden. Von letzterem ist jedoch
außerhalb der Testphase abzuraten, da der Verweis auf eine lokale Datei
rechnerabhängig ist. Dadurch ist die Durchführung des gesamten Analyseprozesses
nur auf dem lokalen Rechner und nicht mittels Hintergrundverarbeitung möglich.
Daten aus Datenbanktabelle lesen
Diese letzte Möglichkeit der Datenbeschaffung erlaubt es, Daten aus einer
transparenten und aktivierten Datenbanktabelle oder einem Datenbankview zu laden.
Alle in der Tabelle bzw. dem View vorhandenen Felder, stehen so zur weiteren
Verarbeitung zur Verfügung.
3.2.2 Phase 2 - Transformationen
Die zweite Phase im Modellierungsprozess umfasst den bedeutenden Teil der
Transformationen.
Folgende Transformationstypen stehen zur Auswahl:
■ Datenmenge einschränken
■ Daten aggregieren
■ Daten aus zwei Quellen miteinander verknüpfen (Join)
■ Daten aus zwei Quellen vereinigen (Union)
■ Spalten ausblenden oder umbenennen (Projektion)
■ Daten sortieren
■ Formel
■ Liste in einen Datensatz transformieren
■ Datensatz in eine Liste transformieren
■ ABAP Routine
Zu den Transformationen gehören auch diejenigen, die dem Data Mining zugeordnet
werden. Diese werden jedoch in dieser Arbeit nicht weiter erläutert.
1 Vgl. [KiVA, 2007] S.51
3 Analyse-Prozess-Designer
- 38 -
In den folgenden Abschnitten werden die genannten Transformationen näher
betrachtet.
Datenmenge einschränken
Mit Hilfe dieses Knotens können Datenmengen zeilenweise eingeschränkt und
gefiltert werden. Die Spalten der Datenstruktur bleiben dabei erhalten. Somit
entspricht die Funktionsweise einer oder mehrerer Selektionsbedingungen. Als
Ergebnis wird eine Teilmenge der Eingangsdaten erzeugt.
Abbildung 12: Beispiel – Datenmenge einschränken
1
In Abbildung 12 ist zu erkennen, wie die Kunden selektiert werden, wenn als
Filterbedingung für das Feld Kunde das Intervall 1000 bis 2000 angegeben wird.
Eine Exclude-Selektionsbedingung wird standardmäßig nicht unterstützt. Es existiert
jedoch die Möglichkeit eine Selektionserweiterung vorzunehmen, wonach alle
Selektionsoperationen zur Verfügung stehen2.
Daten aggregieren
Der Knoten „Daten aggregieren“ bietet die Möglichkeit ausgewählte Daten zu
verdichten. So können Daten bestimmter Felder anhand ihrer Werte gruppiert
werden, um anschließend ausgewählte Felder zu aggregieren.
Folgende Aggregationsverhalten werden angeboten:
■ SUM
Die Werte der Aggregationsfelder, deren Gruppierungsfelder identisch sind,
werden summiert.
■ MIN
Nur das Minimum im Aggregationsfeld wird weitergeben.
■ MAX
Nur das Maximum im Aggregationsfeld wird weitergeben.
■ AVG
Der Durchschnitt aller Werte im Aggregationsfeld wird berechnet und
weitergegeben.
1 In Anlehnung an [SAPBib3x, 2008]
2 Weiterführende Information siehe [KiVA, 2007] S.61
3 Analyse-Prozess-Designer
- 39 -
■ AV0
Der Durchschnitt aller Werte im Aggregationsfeld wird berechnet, jedoch ohne
Berücksichtigung der Nullwerte.
■ NOP
Es wird keine Aggregation durchgeführt.
Die beiden folgenden Verhalten stellen Sonderaggregationen dar, die für die
Auswertung der Anzahl der aggregierten Datensätze von Bedeutung sein können:
■ CNT
Gibt die Anzahl der aggregierten Datensätze weiter.
■ CN0
Gibt die Anzahl der aggregierten Datensätze weiter, ohne jedoch die Nullwerte zu
berücksichtigen.
Es ist zu beachten, dass die Auswahl an Aggregationsverhalten vom Typ des
Aggregationsfeldes abhängig ist. So kann beim Typ „Character“ nur MIN oder MAX
für die Aggregation ausgewählt werden, da andere Verhaltensweisen nicht sinnvoll
sind.
Das Aggregieren von Daten soll anhand von zwei Beispielen verdeutlicht werden:
Abbildung 13: Beispiel 1 – Daten aggregieren
1
Die Abbildung 13 zeigt die Merkmale (Attribute) Kunde, Material und
Warengruppe sowie die Kennzahlen Erlös und Kosten. Durch die Angabe von Kunde
und Warengruppe als Gruppierungsfelder sowie Erlös und Kosten als
Aggregationsfelder, findet eine Verdichtung auf der Ebene Kunde/Warengruppe
statt. Die beiden Kennzahlen werden aufgrund ihres Aggregationsverhaltens (SUM)
addiert.
1 In Anlehnung an [SAPBib3x, 2008]
3 Analyse-Prozess-Designer
- 40 -
Abbildung 14: Beispiel 2 – Daten aggregieren
1
Abbildung 14 zeigt die Aggregation auf Kundenebene, wobei die Erlöse summiert
(SUM) und für die Kosten der Durchschnitt (AVG) berechnet wird.
Daten aus zwei Quellen miteinander verknüpfen (Join)
Der Knoten vom Typ „Join“ ermöglicht es, zwei Datenquellen miteinander zu
verknüpfen. Dabei ist es wichtig, alle Felder anzugeben, die weitergegeben werden
sollen.
Abbildung 15: Beispiel – Daten zweier Quellen miteinander verknüpfen
2
Abbildung 15 veranschaulicht, wie über das gemeinsame Merkmal Kunde eine
Verknüpfung der beiden Datenquellen realisiert werden kann.
Standardmäßig wird zur Verknüpfung der „Inner Join“ verwendet. Es besteht jedoch
auch die Möglichkeit einen „Left Outer Join3“ zu verwenden, wobei die zuerst
angebundene Tabelle die „linke“ Tabelle darstellt. Unterschiede im Ergebnis
zwischen beiden Verknüpfungsarten ergeben sich dann, wenn gemeinsame
Merkmale unterschiedliche Ausprägungen besitzen.
1 In Anlehnung an [SAPBib3x, 2008]
2 In Anlehnung an [SAPBibBI, 2008]
3 Siehe auch Abschnitt 12, Glossar, auf Seite 104
3 Analyse-Prozess-Designer
- 41 -
Daten aus zwei Quellen vereinigen (Union)
Mit Hilfe dieser Transformation können zwei Datenquellen vereinigt werden. Da im
Gegensatz zum „Join“ ggf. nur eine Schnittmenge weitergegeben wird, werden bei
der Vereinigung alle Felder der Quellstruktur im Ergebnis verwendet.
Als einzige Einschränkung gilt: Gleichnamige Felder müssen von demselben
Datentyp sein.
Abbildung 16: Beispiel – Daten aus zwei Datenquellen vereinigen
1
Abbildung 16 zeigt, wie zwei Datenquellen vereinigt werden und wie dabei, im
Gegensatz zum Join, auch leere Attributwerte im Merkmal Land entstehen können
Spalten ausblenden oder umbenennen (Projektion)
Besitzt eine Datenquelle zu viele oder unnötige Felder, können mit Hilfe dieser
Transformation einzelne Spalten ausgeblendet werden. Darüber hinaus hat man die
Möglichkeit, unpassende Feldnamen umzubenennen, um so die Verständlichkeit des
Analyseprozesses zu optimieren.
Daten sortieren
Dieser Knoten ermöglicht es, die Daten nach ausgewählten Feldern zu sortieren.
Diese Transformation wird jedoch ausschließlich zur Überprüfung von
Zwischenschritten verwendet.
Fast immer führen die Transformationen selbst eine Sortierung anhand der
Gruppierungsfelder durch, wodurch eine vorangestellte, separate Sortierung nur zu
einer verschlechterten Performance führt.
1 In Anlehnung an [SAPBibBI, 2008]
3 Analyse-Prozess-Designer
- 42 -
Abbildung 17 zeigt beispielhaft die Sortierung einer Kundenliste nach Umsatz.
Abbildung 17: Beispiel – Daten sortieren
1
Formel
Mit Hilfe der Formel-Transformation kann die Datenstruktur um weitere Felder
ergänzt werden, die anschließend mit den Ergebnissen der Formel-Berechnungen
gefüllt werden. Dabei stehen nicht nur die mathematischen Grundfunktionen und
logischen Vergleichsoperatoren sondern auch Transformationen im Hinblick auf
Datum und Zeichenketten zur Verfügung. So können auf Basis der Eingangsdaten
Berechnungen durchgeführt werden.
Die Transformationsbibliothek stellt bereits eine Vielzahl an vorgefertigten
Funktionen zur Verfügung. In Kombination mit dem Formeleditor lassen sich
weitere Funktionen einfach und ohne ABAP2 Code (Advanced Business Application
Programming) anfertigen.
Liste in Datensatz transformieren
Der Knoten „Liste in Datensatz transformieren“ erlaubt es, die interne Datenstruktur
der Eingangsdaten dahingehend zu verändern, dass gewählte Spalten in Zeilen
transponiert werden. Dementsprechend wird, bei Angabe der Transformier- und der
Transponierfelder, aus einer Liste von Datensätzen ein einzeiliger Datensatz
generiert.
Abbildung 18: Beispiel – Liste in Datensatz transformieren
3
1 In Anlehnung an [SAPBib3x, 2008]
2 Siehe auch Abschnitt 12, Glossar, auf Seite 104
3 In Anlehnung an [SAPBib3x, 2008]
3 Analyse-Prozess-Designer
- 43 -
Abbildung 18 veranschaulicht den Vorgang anhand eines einfachen Beispiels. Die
Fragebogen-Nr wird einfach übernommen, wohingegen die Frage-Nr als
Transformationsfeld und die Antwort als Transponierfeld angeben wird.
Anschließend lässt sich die Antwort jeder Frage in einem eigenen Feld wiederfinden.
Datensatz in Liste transformieren
Die Funktion „Datensatz in Liste transformieren“ bildet den Gegensatz zur o.g.
Transformation „Liste in Datensatz transformieren“. Auch hier wird die interne
Datenstruktur geändert, jedoch so, dass aus einem Datensatz mehrere Sätze in Form
einer Liste erzeugt werden.
Abbildung 19: Beispiel – Datensatz in Liste transformieren
1
Die Funktionsweise wird in Abbildung 19 dargestellt und entspricht dem
gegenteiligen Ablauf zu der Funktion „Liste in Datensatz transformieren“.
ABAP Routine
Die ABAP Routine ist die flexibelste Möglichkeit der Transformation. Hier können
individuelle Transformationen, die nicht durch die bereits genannten Knoten
durchgeführt werden können, mittels ABAP Code programmiert werden.
Die Eingangsdaten können in Gruppierungsfelder und Quellfelder unterteilt werden.
Gruppierungsfelder werden unverändert weitergegeben, wohingegen Quellfelder in
der ABAP Routine zur Verfügung stehen. Zusätzlich muss die Definition der
Zielfelder erfolgen, in der die Routine ihre Ergebnisse ablegen kann. Sie werden an
die Datenstruktur angehängt und erweitern somit die Eingangsdatentabelle. Sollen
die Quellfelder zusätzlich unverändert weitergegeben werden, müssen diese als
gleichnamige Zielfelder definiert werden.
1 In Anlehnung an [SAPBibBI, 2008]
3 Analyse-Prozess-Designer
- 44 -
Innerhalb der Routine ist es möglich, auf folgende Strukturen zuzugreifen1:
■ IS_GROUP
enthält die Struktur der Gruppierungsfelder (kann nicht verändert werden)
■ IT_SOURCE
enthält die Eingangstabelle ohne die Gruppierungsfelder
■ ET_TARGET
entspricht der Ausgangstabelle, die durch die Routine gefüllt wird. Wenn die
Routine beendet ist, wird die Tabelle wieder um die Elemente der
Gruppierungsfelder ergänzt.
Innerhalb eines Loop-Statements, das die gesamte interne Tabelle mit den
Quellfeldern durchläuft, kann nun die Transformationslogik implementiert werden.
...
*---------------------- Begin of transformation code --------------
DATA: ls_source TYPE y_source_fields,
ls_target TYPE y_target_fields.
LOOP AT it_source INTO ls_source.
ls_target-UMSATZ = ls_source-MENGE * ls_source-PREIS
MOVE-CORRESPONDING ls_source TO ls_target.
APPEND ls_target TO et_target.
ENDLOOP.
*----------------------- End of transformation code ----------------
...
Listing 1: Beispiel – ABAP-Routine
In dem Beispiel wird für jeden Datensatz, mit Hilfe der Quellfelder ls_source-
MENGE und ls_source-PREIS, der Umsatz berechnet und in das Zielfeld ls_target-
UMSATZ gespeichert.
3.2.3 Phase 3 - Datenziele
Nachdem die Quelldaten in der zweiten Phase entsprechend der Zielsetzungen und
Anforderungen transformiert und aufbereitet wurden, müssen die Ergebnisse in
geeigneten Datenzielen abgelegt werden.
Zu den möglichen Datenzielen gehören auch solche, die dem Bereich des Data
Mining zugeordnet werden. Diese werden, aus den bereits bekannten Gründen, an
dieser Stelle nicht näher betrachtet.
»Innerhalb eines Analyseprozesses darf nur ein Datenziel verwendet werden. Dies
bedeutet, dass alle Datenquellen […] konsolidiert werden müssen.«2
1 Vgl. [KiVA, 2007] S.71
2 Vgl. [KiVA, 2007] S.72
3 Analyse-Prozess-Designer
- 45 -
Aktuell sind folgende Datenziele verfügbar:
■ Attribute eines Merkmals ändern
■ ODS/DSO-Objekt schreiben
■ CRM-Attribute aktualisieren
Die genannten Datenziele werden nun näher betrachtet:
Attribute eines Merkmals ändern
Dieser Datenziel-Knoten ermöglicht es, die Attributwerte eines Merkmals zu ändern,
d.h. die aufbereiteten Daten werden in die Attribute eines bereits aktiven Merkmals
gespeichert. Dabei gilt es zu beachten, dass es nicht möglich ist die Struktur des
Merkmals hinsichtlich zusätzlicher Attribute zu verändern. Die Attribute aus dem
Ergebnis des Analyseprozesses müssen entweder durch die Struktur des Merkmals
abgebildet sein oder können nicht fortgeschrieben werden.
ODS/DSO-Objekt schreiben
In Abhängigkeit der verwendeten Version des Business Warehouse können die
Analyseergebnisse entweder in ein transaktionales ODS- oder DataStore-Objekt
gespeichert werden.1 Von dort ist eine Fortschreibung in einen InfoCube möglich.
Bei ODS-Objekten kann mittels InfoSet auch ein direktes Query auf die Daten
erstellt werden. Bei DataStore-Objekten ist dies auch ohne InfoSet möglich.
CRM-Attribute aktualisieren
Mit Hilfe dieses Knotens können Ergebnisse des Analyseprozesses direkt in das SAP
CRM (Customer Relationship Management) übertragen werden. Dort müssen die
Datenziele jedoch zuvor definiert werden. Dadurch wird deutlich, dass die Auswahl
an Datenzielen sowie deren Eigenschaften von dem Releasestand des eingesetzten
SAP CRM abhängig sind. In erster Linie können mit diesem Knoten Daten zum
Geschäftspartner gespeichert werden.
Daten in Datei schreiben
Dieses Datenziel erlaubt das Speichern der Analyseergebnisse in einer flache Datei,
die entweder auf dem Applikationsserver oder auf dem lokalen Rechner abgelegt
sein kann.
1 d.h. bei jedem Lauf des Analyseprozesses werden die Daten vor dem Speichern gelöscht.
3 Analyse-Prozess-Designer
- 46 -
3.3 Anwendungen
Eine Besonderheit des APD liegt in der Tatsache, dass Analyseprozesse nur
innerhalb der von SAP vorgegebenen Anwendungen angelegt werden können.
Abhängig von der gewählten Anwendung werden ausschließlich die Funktionen1
(Datenquellen, Transformationen und Datenziele) für die Modellierung des Prozesses
angeboten, die für die jeweilige Anwendung relevant sind. Bei Bedarf gibt es die
Möglichkeit die Anwendungen zu verändern bzw. neue, eigene Anwendungen zu
erzeugen, um so den Analyseprozess individuell gestalten zu können.2
Folgende Anwendungen werden standardmäßig von SAP ausgeliefert:
■ CRM-Attribute füllen (CRM_ATTRIBUTES)
■ Zielgruppe für BW-Umfragen anlegen (SATISFACTION_TGT)
■ Berechnung der Wichtigkeit (SATISFACTION_SVY)
■ Prognose Modelltraining (RT_MDL_TRAIN)
■ Allgemein (GENERIC)
Abbildung 20: Standardanwendungen von SAP
Wie in Abbildung 20 zu erkennen ist, stellt der Anwendungstyp „Allgemein“
(GENERIC) die Obermenge aller zur Verfügung stehenden Knoten dar. Um alle
Funktionen nutzen zu können, empfiehlt es sich daher, den Analyseprozess in der
Anwendung „Allgemein“ zu erzeugen.
1 Die Elemente des Modells werden auch Knoten genannt
2 Weiterführende Information siehe [KiVA, 2007] S.114
3 Analyse-Prozess-Designer
- 47 -
3.4 Funktionsweise
Die Benutzeroberfläche des APD ist klar strukturiert und stellt alle Funktionen und
Informationen und damit den gesamten analytischen Prozess übersichtlich dar (siehe
Abbildung 21). Dies ist ein entscheidender Faktor bei der Verwendung des APD im
Zusammenhang mit komplexen analytischen Modellierungsvorgängen.1
Abbildung 21: APD-GUI
2
Die Modellierung des Analyseprozesses im Arbeitsbereich erfolgt mit Hilfe von
Knoten und Datenflusspfeilen.
Knoten
Die Knoten werden durch die bereits beschriebenen Datenquellen, Transformationen
und Datenziele repräsentiert. Sie werden anhand von Symbolen per Drag&Drop auf
den Arbeitsbereich gezogen, dort miteinander verbunden und mittels Doppelklick in
ihren Eigenschaften verwaltet.
Anhand der sogenannten Dekorationen werden die unterschiedlichen Knoten
deutlicher gekennzeichnet. Die Dekorationen befinden sich in der rechten oberen
Ecke des Knotens und zeigen an, ob es sich bei dem Knoten um eine Datenquelle
(kleiner Würfel), eine Transformation (kleines Dreieck) oder ein Datenziel (kleiner
Kreis) handelt. Hierdurch lassen sich gleichartige Symbole aus den verschiedenen
Funktionsbereichen deutlicher unterscheiden.
1 Siehe auch Abschnitt 3.6, Abgrenzung zu den Möglichkeiten im BW, auf Seite 51
2 Vgl. [BW380, 2005] S.25
3 Analyse-Prozess-Designer
- 48 -
Darüber hinaus besitzt jeder Knoten einen oder mehrere Konnektoren (kleine rote
Dreiecke). Diese symbolisieren die Eingänge (links am Knoten) bzw. die Ausgänge
(rechts am Knoten). Über diese Konnektoren können die Knoten mit Hilfe von
Datenflusspfeilen miteinander verbunden werden.
Abbildung 22: Dekoration, Konnektor, Datenflusspfeil
Datenflusspfeile
Über die Datenflusspfeile werden die verschiedenen Knoten eines Analyseprozesses
miteinander verknüpft. Dies geschieht ebenfalls mittels Drag&Drop an den
Konnektoren der Knoten. Nur für Datenflusspfeile mit einem Symbol ist es
notwendig, durch Doppelklick eine Feldzuordnung zwischen den Knoten
durchzuführen. Bei Datenflusspfeilen ohne Symbol findet das Mapping automatisch
statt.
Daten anzeigen lassen
Ein weiterer wesentlicher Aspekt bei der Modellierung von komplexen
Analyseprozessen ist es, jeden einzelnen Verarbeitungsschritt auf seine Richtigkeit
überprüfen zu können. Ohne diese Möglichkeit wäre eine Fehlersuche enorm
aufwändig und schwierig. Mit Hilfe der Funktion „Daten anzeigen“ kann die
Datenqualität, anhand einer Auswahl von ca. 2000 Datensätzen, nach jedem Schritt
im Analyseprozess überprüft werden.
Genutzt werden kann diese Funktion entweder über das Kontextmenü eines Knotens
oder den Aufruf über die Funktionsauswahl (je nach Version).
Elementare Statistik anzeigen
Eine weiterführende Analyse in den einzelnen Schritten des Analyseprozesses ist
über die Funktion „Elementare Statistik anzeigen“ möglich. In Abhängigkeit von den
gewählten Feldern werden grundlegende, statistische Informationen bezüglich des
3 Analyse-Prozess-Designer
- 49 -
aktuellen Datenbestandes des Knotens angezeigt. Neben Histogrammen, Verteilungs-
und Häufigkeitsberechnungen werden, je nach Werttyp des Feldes, auch weitere
einfache Statistikkennzahlen, wie z.B. arithmetisches Mittel, Standardabweichung
oder Korrelation ausgegeben.
Die Statistiken sind vor allem im Bereich des Data Mining von Bedeutung und
können dort ein hilfreiches Mittel zur Überprüfung und Analyse des aktuellen
Datenbestandes sein.
Zwischenergebnis berechnen
Mit Hilfe der Funktion „Zwischenergebnis berechnen“ kann die teilweise
Durchführung des Analyseprozesses bis zu einem definierten Knoten gestartet
werden. Die Durchführung erfolgt wahlweise direkt oder als eingeplanter Job im
Hintergrund. Die berechneten Daten werden dann in einer temporären Tabelle
gespeichert. Sie wird jedoch ungültig, sobald der Knoten verändert wird.
Im Arbeitsbereich wird ein Zwischenergebnis optisch durch das Icon in der
rechten unteren Ecke des Knotens dargestellt.
Das Erzeugen eines Zwischenergebnisses »ist zum einen hilfreich, wenn Sie bei der
Modellierung des Analyseprozesses verschiedene Möglichkeiten ab diesem Knoten
ausprobieren möchten. Zum anderen dienen die Zwischenergebnisse der
Performanceoptimierung beim Ausführen des Analyseprozesses bei großen
Datenmengen.«1
3.5 Versteckte Funktionen
Es gibt noch eine Vielzahl weiterer Funktionen, die jedoch ausschließlich über den
Anwendungstyp2 DEVELOPMENT verfügbar sind. Dieser Anwendungstyp ist
jedoch nicht im SAP-Standard enthalten, sondern in erster Linie für die
Weiterentwicklung des APD und dessen Funktionalitäten gedacht. Obwohl einige
Funktionen sicherlich nützlich sein können, muss eine Verwendung gut überlegt
sein, da jede dieser Funktionen mit einem gewissen Risiko verbunden ist.
Manche Funktionen, wie „Quantilbildung“, „Top-Down-Verteilung“ oder „Daten in
Datenbank schreiben“ können bei Bedarf ohne erhöhtes Risiko eingesetzt werden, da
ihre Funktionsweise nicht sehr komplex und damit nachvollziehbar ist. Andere
Funktionen wie „Normalisierung“ weisen jedoch Fehler auf und sollten daher nicht
eingesetzt werden. 3
Es gilt also festzuhalten, dass aufgrund des Entwicklungsstadiums und der
ausschließlichen internen Verwendung einiger Funktionen durch SAP, ohne
1 Vgl. [SAPBib3x, 2008]
2 Siehe auch Abschnitt 3.3, Anwendungen, auf Seite 47
3 Weiterführende Information siehe [KiVA, 2007] ab S.117
3 Analyse-Prozess-Designer
- 50 -
detaillierte Kenntnisse über die Arbeitsweise, der Einsatz dieser versteckten
Funktionen genau geprüft werden sollte. Darüber hinaus werden sinnvolle
Weiterentwicklungen in naher Zukunft sicherlich, in Form von Standardfunktionen,
in den APD eingebunden.
3.6 Abgrenzung zu den Möglichkeiten im BW
Trotz der vielen Möglichkeiten und Funktionen des Analyse-Prozess-Designers
lassen sich viele der Verknüpfungen und Transformationen auch mit den Mitteln des
Business Warehouse sowie den Übertragungs- und Fortschreibungsregeln
durchführen. Dabei ist die Verarbeitung in der Regel effizienter und performanter.
Dennoch besitzt der APD seine Daseinsberechtigung. Ein Einsatzgebiet in dem der
Analyse-Prozess-Designer besondere Bedeutung hat, ist das Data Mining. Nur mit
ihm können Daten, die bereits im BW vorliegen, für das Data Mining Verfahren
zusammengeführt und aufbereitet werden.
Aber auch ohne Data Mining Methoden hilft der APD bei komplexen
Problemstellungen eine übersichtliche Struktur zu schaffen. Es können beliebige
Datenobjekte, die auch schon in anderen Prozessen und Datenflüssen verwendet
werden, aus dem SAP BW genutzt und weiter aufbereitet werden. Dies geht über den
normalen ETL-Prozess des Business Warehouse weit hinaus. Der APD ermöglicht
es, eine beliebig lange Folge von Transformationen durchzuführen (siehe Abbildung
23), während dem BW dort deutliche Grenzen gesetzt sind. Die übersichtliche
Darstellung sowie die Möglichkeit der Zwischenprüfungen erlauben es, den
Analyseprozess deutlich transparenter zu gestalten. Letztlich verwendet der APD
Daten, die schon im BW vorliegen oder durch vorangestellte Analyseprozesse
erzeugt wurden. Dies können auch Teilmengen vorhandener Datenbestände sein
(Queries als Datenquelle). Somit werden das produktive Quellsystem und auch das
Business Warehouse durch den Analyseprozess des APD weniger belastet.
Idealerweise ergänzen sich die Vorteile des SAP BW sowie des APD, indem ein
Kompromiss aus Funktionalität, Flexibilität und Transparenz auf der einen Seite, und
Effizienz und Performanz auf der anderen Seite geschaffen wird. So empfiehlt z.B.
SAP »InfoSets zu benutzen, um große ODS-Objekte und Stammdatentabellen zu
verknüpfen, da die Verarbeitung effizienter [als im Analyse-Prozess-Designer] ist.«1
Inwieweit solche Kompromisse ohne Einschränkungen zu schließen sind, hängt
maßgeblich von den Anforderungen an den Analyseprozess ab.
Eine detaillierte Übersicht der Vorteile und Einsatzgebiete des APD ist im Abschnitt
5.2 zu finden.
1 Vgl. [BW380, 2005] S.252
3 Analyse-Prozess-Designer
- 51 -
Abbildung 23: Beispiel eines Analyseprozesses
1
3.7 Auswirkungen des APD auf den ETL-Prozess
Im Grunde entspricht die Verwendung des APD, vor allem ohne den Einsatz von
Data Mining Techniken, einem weiteren, flexibleren ETL-Prozess im Anschluss an
den eigentlichen ETL-Prozess des BW. Genau wie im BW werden die Daten im
APD zunächst extrahiert (wenn auch aus dem gleichen System), transformiert und
geladen.
Diese Tatsache hat auch Auswirkungen auf den ETL-Prozess der Datenbeschaffung
im BW. So ist es von Bedeutung, wie und welche Daten extrahiert und transformiert
werden und ob dies Auswirkungen auf die Verwendung der Daten in einem oder
mehreren möglichen Analyseprozessen hat. So können z.B. im Rahmen eines
Datenflusses bestimmte Daten so verändert (oder gar nicht erst übertragen) werden,
dass sie in einem anderen späteren Analyseprozess keine Verwendung mehr finden.
Andererseits ist es jedoch nicht sinnvoll, provisorisch „alle“ Daten in das BW zu
laden, nur weil ein Teil davon eventuell in einem Analyseprozess verwendet werden
könnte.
Es gilt also auch hier wieder, einen Kompromiss zwischen Flexibilität und Effizienz
zu finden.
1 In Anlehnung an [KiVa, 2007] S.78
3 Analyse-Prozess-Designer
- 52 -
3.8 Unterschiede zwischen den Versionen des APD
Mit der SAP BW Version 3.0 wurde der Analyse-Prozess-Designer eingeführt.
Vergleichsweise klein ist dementsprechend der Funktionsumfang zu den aktuellen
Releaseständen. Sowohl die Anbindung an die Methoden des Data Mining als auch
deren Reifegrad sind nicht sehr ausgeprägt.
Mit der Einführung des SAP BW 3.5 und der Weiterentwicklung im SAP BI 7.0
haben das »Spektrum an Verfahren, die Möglichkeit zum modulübergreifenden
Einsatz und die Integration in grafische Entwicklungswerkzeuge […] einen vorläuf-
igen Höhepunkt erreicht.«1
Die folgende Tabelle stellt die wesentlichen Änderungen und Erweiterungen bei den
Funktionen des Analyse-Prozess-Designers dar:
Unterscheidungsmerkmal SAP BW 3.1 SAP BW 3.5 SAP BI 7.0
Transformation „Spalten ausblenden oder umbenennen“ (Projektion)
nein ja ja
Transformation „Daten aus zwei Quellen vereinigen“ (Union)
nein nein ja
Transformation „Formel“ nein nein ja
Datenziel „Daten in Datei schreiben“ nein versteckt ja
Sonderaggregationsverhalten nein ja ja
Programmiersprache in der Funktion „ABAP Routine“
ABAP ABAP ABAP Objects
Zugriff auf Funktion „Daten anzeigen“ Funktionsauswahl Kontextmenü Kontextmenü
Funktion „Elementare Statistik anzeigen“ nein ja ja
Funktion „Zwischenergebnis“ nein ja ja
Anzahl integrierter Data Mining Methoden 1 5+2 5+
Dekorationen nein ja ja
Tabelle 2: Unterschiede zwischen den Versionen des APD
Zusätzlich gibt es noch eine Vielzahl an Änderungen an der grafischen Oberfläche.
(z.B. bei Symbolen für die jeweiligen Funktionen) sowie im Funktions- und
Informationsangebot in den verschiedenen Leisten der APD-Workbench. Da diese
Änderungen jedoch für den Benutzer offensichtlich sind, bedürfen sie keiner
weiteren Erläuterung.
1 Vgl. [KiVa, 2007] S.12
2 Erweiterungen über Drittanbieter möglich
4 Fallbeispiel „Anlagen-Analyse“
- 53 -
4 Fallbeispiel „Anlagen-Analyse“
Anhand eines Fallbeispiels soll die Umsetzung eines Analyseprozesses mit Hilfe des
Analyse-Prozess-Designers durchgeführt werden. Durch Verknüpfungen und
Transformationen von realen Daten1 eines Energieversorgungsunternehmens sollen
neue, nützliche Informationen geschaffen werden.
Um einen Einblick in die branchenspezifischen Gegebenheiten eines
Energieversorgungsunternehmens zu bekommen, die für das Fallbeispiel relevant
sind, werden die wichtigen Begrifflichkeiten und Zusammenhänge zunächst in einer
kurzen Einführung erläutert. Anschließend werden die Zielsetzungen des
Fallsbeispiels definiert und daraus ein Konzept für die Umsetzung abgeleitet. In den
darauf folgenden Abschnitten folgen die Prozesse der Datenbeschaffung,
Transformation, Datenspeicherung und Datenauswertung. Zuletzt werden mögliche
Optimierungsvorschläge genannt, um die Systembelastung zu minimieren.
4.1 Einführung in die Thematik
Um die Zielsetzung sowie die nachfolgenden Schritte der Umsetzung nachvollziehen
zu können, gilt es zunächst die wichtigen Begriffe und Prinzipien eines
Energieversorgungsunternehmens, in Bezug auf das Fallbeispiel der Anlagen-
Analyse, zu erläutern.
4.1.1 SAP for Utilities
» SAP Utilities ist ein geschäftsprozessorientiertes Vertriebs- und Informations-
system für alle Versorgungsarten und Serviceleistungen eines Versorgungs- und
Dienstleistungsunternehmens. Die Branchenkomponente Versorgungsindustrie(IS-U)
dient gleichermaßen zur Verwaltung und Abrechnung von Tarifkunden,
Sonderkunden, Dienstleistungskunden und Interessenten.«2
1 Als Quelle dient das System EE1 (siehe auch Abschnitt 1.4, Eingesetzte Software, auf Seite 10)
2 Vgl. [SAPBibUtil, 2008]
4 Fallbeispiel „Anlagen-Analyse“
- 54 -
SAP for Utilities besteht aus folgenden Komponenten:1
■ IS-U/CSS (Industry Solution Utilities / Customer Care Service)
□ Grundfunktionen
Verwalten von Adressen und Erzeugen von Terminen für Ablesungen,
Abschläge und Abrechnungen.
□ Stammdatenverwaltung
Verwalten der Stammdaten wie Geschäftspartner, Verträge, Anschlussobjekte,
Anlagen.
□ Geräteverwaltung
Verwaltung der Installation und Beglaubigung von Geräten.
□ Abrechnung
Abrechnung der Dienste Strom, Gas, Wasser, Abwasser, Fernwärme, Abfall,
Multimedia-Dienste.
□ Fakturierung
Zusammenführung von Leistungen auf einer Rechnung sowie deren
gemeinsame Fakturierung. Darüber hinaus können Steuern, Gebühren und
Abgaben ermittelt und erhoben werden.
□ Kundenservice
Über den Kundenservice können die wichtigen Geschäftsprozesse gestartet
sowie alle dafür benötigten Daten angezeigt werden. Bestandteile des
Kundenservice sind das Customer-Interaction-Center (CIC) bzw. das Front-
Office (für die Mitarbeiter) sowie die Internet-Self-Services (für die Kunden).
■ EDM (Energy Data Management)
In diesem Bereich erfolgen alle Funktionen bezüglich Lastgangmessung,
Energiemengenbilanzierung, Fahrplan-Management sowie Abrechnung von
Zeitreihen mit Hilfe der Real-Time-Pricing-Abrechnung. Das EDM besitzt dafür eine
zentrale Datenbank mit allen Energiedaten.
■ Work Management
Kombiniert verschiedene SAP-Komponenten und ergänzt sie um verschiedene
branchenabhängige Funktionen.
■ IS-U-WA (Waste and Recycling)
Deckt die betriebswirtschaftlichen Abläufe von Entsorgungsunternehmen ab.
■ IDE
IDE ist der unternehmensübergreifende Datenaustausch zwischen z.B. Lieferant,
Netzbetreiber und Kunden, der aufgrund der Deregulierung der Energiemärkte
notwendig ist.
1 Siehe auch [SAPBibUtil, 2008]
4 Fallbeispiel „Anlagen-Analyse“
- 55 -
Die Komponente IS-U ist für dieses Fallbeispiel von zentraler Bedeutung, da alle
Daten, die der Analyse-Prozess-Designer im weiteren Verlauf verarbeitet, aus dieser
Branchenlösung extrahiert werden.
SAP Utilities, und damit auch IS-U, integriert verschiedene Standardkomponenten
des SAP-Systems oder anderer externer Systeme. Die folgende Abbildung soll diesen
Zusammenhang kurz darstellen:
Abbildung 24: Integrationsmodell des ISU
1
4.1.2 IS-U Haus
Das IS-U Haus ist eine grafische Darstellung der branchenspezifischen Stammdaten
eines Versorgungsunternehmens. Sie verdeutlicht die Eigenschaften sowie den
Zusammenhang der einzelnen Stammdaten untereinander.
1 In Anlehnung an [IUT110, 2005] S.24
4 Fallbeispiel „Anlagen-Analyse“
- 56 -
Abbildung 25: IS-U Haus
1
Die Stammdaten werden unterteilt in kaufmännische und technische Stammdaten.
Die wichtigsten Stammdaten werden in der folgenden Übersicht erläutert:
Kaufmännische Stammdaten
■ Geschäftspartner
Der Geschäftspartner ist eine natürliche Person, eine Organisation oder Gruppe
von natürlichen Personen und besitzt ein oder mehrere Vertragskonten. Der
Geschäftspartner ist identisch mit dem Vertragspartner.
■ Vertragskonto
Das Vertragskonto sammelt alle Verträge zu einem Geschäftspartner und enthält
z.B. Daten über die Zahlungskonditionen oder die Bankverbindung.
■ Vertrag
Ein Vertrag bezieht sich immer auf eine Sparte, z.B. Strom oder Wasser und ist
u.a. für die Abrechnung sowie die Abschlagsplanerstellung von Bedeutung.
Technische Stammdaten
■ Anschlussobjekt
Bei dem Anschlussobjekt handelt es sich zumeist um ein Gebäude oder ein
Grundstück. Es beinhaltet eine oder mehrere Verbrauchsstellen.
■ Verbrauchsstelle
Die Verbrauchsstelle ist eine räumlich abgetrennte Einheit, z.B. eine Wohnung.
Einer Verbrauchsstelle können eine oder mehrere Anlagen zugeordnet haben.
1 In Anlehnung an [IUT110, 2005] S.36
4 Fallbeispiel „Anlagen-Analyse“
- 57 -
■ Anlage
Die Anlage umfasst alle Geräte und Zählwerke einer Sparte, die gemeinsam
abgerechnet werden.
■ Geräteplatz
Der Geräteplatz bezeichnet den Ort im Anschlussobjekt, an dem sich Geräte
befinden, z.B. Korridor oder Keller.
■ Zählpunkt
Der Zählpunkt ist eine Stelle, an der eine Leistung erbracht wird. Er besitzt eine
Zählpunktbezeichnung, die aus einem 33-stelligen Schlüssel zusammengesetzt
und innerhalb von Deutschland eindeutig ist. Der Zählpunkt wird für die
Kommunikation zu externen Systemen verwendet.
4.1.3 Ablauf der Vertragsabrechnung
Auf einer hohen Abstraktionsebene lässt sich der Vorgang der Vertragsabrechnung
in die Teilschritte Ablesung, Abrechnung und Fakturierung unterteilen.
Abbildung 26: Ablauf der Vertragsabrechnung (vereinfacht)
Abbildung 26 zeigt den Vorgang in einer stark vereinfachten Form. In der Praxis
verbirgt sich hinter den Teilschritten eine Vielzahl weiterer Prozesse, Komponenten
und Zusammenhänge. Nachfolgend werden nur die Aspekte näher betrachtet, die für
die Fallstudie von besonderer Bedeutung sind.1
Ablesung
Bei dem Vorgang der Ablesung wird der aktuelle Zählerstand der Geräte zum Zweck
der Abrechnung abgelesen. Dieser Vorgang kann auf verschiedene Arten
durchgeführt werden (manuell, maschinell, Kundenselbstablesung). Gemeinsam
haben diese Verfahren, dass zunächst Ableseaufträge erstellt werden, sobald der
Termin der Ablesung erreicht ist. Die Ablesung wird durchgeführt und die
Ergebnisse werden in einem Ablesebeleg erfasst. Nachdem sie übermittelt wurden,
folgt eine Plausibilitätsprüfung und ggf. eine Korrektur der Ableseergebnisse.
Zusammen mit dem Ableseauftrag wird ein Abrechnungsauftrag erzeugt. Der
Abrechnungsauftrag benötigt den Ablesebeleg mit plausiblen Zählerständen, um das
Kennzeichen „abrechenbar“ zu erhalten.
Mehrere Ablesungen werden in der Regel in sogenannten Ableseeinheiten
zusammengefasst. Diese beinhalten verschiedene Stadtteile, Straßen, Anschluss-
1 Weiterführende Informationen siehe [IUT110, 2005] S.215ff
4 Fallbeispiel „Anlagen-Analyse“
- 58 -
objekte, Geräteplätze bis zu den einzelnen Geräten und werden über eine
Ablesereihenfolge effektiv abgearbeitet.
Jede Ablesung hat einen spezifischen Ablesegrund. Im IS-U sind 31 verschiedene
Gründe definiert, wie z.B. Turnusablesung (z.B. jährlich), Zwischenablesung,
Einzugsablesung oder Kontrollablesung.
Abrechnung
In der Abrechnung werden die bereits erzeugten Abrechnungsaufträge verarbeitet.
Die aus der Ablesung bekannten Verbräuche sowie andere Leistungen des
Unternehmens werden mit Preisen bewertet. Das Ergebnis der Abrechnung ist der
Abrechnungsbeleg. Dieser wird für die Fakturierung benötigt. Der
Abrechnungsauftrag wird nach erfolgreicher Abrechnung gelöscht.
Fakturierung
Die Fakturierung stellt die Verbindung zum Vertragskontokorrent1 her. In der
Fakturierung werden die angefallenen Forderungen gesammelt und mit den bisher
geleisteten Abschlagszahlungen des Kunden verrechnet. Auch die Verwaltung und
Erzeugung von Abschlagsplänen erfolgt in der Fakturierung. Darüber hinaus sind das
Mahnwesen und das Sperren Aufgabengebiete der Fakturierung. Abschließend
werden die Rechnungen erstellt und gedruckt. Dieser Vorgang erzeugt einen
Druckbeleg.
Der gesamte Abrechungsvorgang mit den beteiligten Komponenten ist noch einmal
in der folgenden Abbildung dargestellt:
Abbildung 27: Ablauf der Vertragsabrechnung
2
1 Siehe auch Abschnitt 12, Glossar, auf Seite 104
2 In Anlehnung an [IUT100, 2005] S.300
4 Fallbeispiel „Anlagen-Analyse“
- 59 -
Stornierung
Bei der Stornierung werden einzelne Belege mit einem Stornierungskennzeichen
versehen und dadurch als fehlerhaft gekennzeichnet. Die Datensätze befinden sich
dabei weiter im System, werden jedoch in den anschließenden Prozessen nicht weiter
betrachtet. Wird z.B. ein Abrechnungsbeleg storniert, erhält dieser ein Storno-
Kennzeichen, wonach ein neuer, korrekter Abrechnungsbeleg erzeugt wird.
Man unterscheidet zwischen Einzelstorno und Gesamtstorno. Bei der
Einzelstornierung wird nur ein Abrechnungsbeleg oder ein Fakturierungsbeleg
storniert. Beim Gesamtstorno werden alle zusammenhängenden Belege gleichzeitig
storniert.
Simulation
Mit Hilfe der Simulation können Abrechnungen und Fakturierungen simuliert
werden. Mit diesem Verfahren ist es z.B. möglich Prognosen zu erstellen, Aspekte
der bilanziellen Abgrenzung zu berücksichtigen oder Abschlagspläne zu generieren.
Bei der Simulation der Abrechnung werden Simulationsbelege erstellt. Sie werden
ausschließlich in der Fakturierungssimulation verwendet.1
4.2 Zielsetzung
Das Ziel der Fallstudie ist es, einen Überblick zu erhalten, welche Anlagen eines
Energieversorgungsunternehmens abgelesen, abgerechnet und fakturiert wurden.
Folgende Fragestellungen sollen mit den Ergebnissen beantwortet werden:
■ Welche Anlagen wurden abgelesen?
■ Welche Anlagen wurden nicht abgelesen?
■ Welche Anlagen wurden abgerechnet?
■ Welche Anlagen wurden nicht abgerechnet?
■ Welche Anlagen wurden fakturiert?
■ Welche Anlagen wurden nicht fakturiert?
■ Welche Anlagen wurden abgelesen, jedoch nicht abgerechnet?
■ Welche Anlagen wurden abgelesen und abgerechnet, jedoch nicht fakturiert?
Zudem soll eine weitere Aufschlüsselung der Ergebnisse anhand folgender Kriterien
möglich sein:
■ Sparte
■ Ableseeinheit
■ Anlage
■ Abrechnungsrelevantes Datum
1 Weiterführende Informationen siehe [IUT110, 2005] S.303ff
4 Fallbeispiel „Anlagen-Analyse“
- 60 -
■ Abrechnungsrelevantes Jahr
■ Ablesegrund
Mögliche Beispielfragen in diesem Zusammenhang können sein:
■ Wie viele und welche Anlagen wurden in der Sparte Strom nicht abgelesen?
■ Wie viele Ablesungen mit dem Ablesegrund „Turnusablesung“ wurden zum
abrechnungsrelevanten Datum „17.08.2007“ zwar abgerechnet, jedoch nicht
fakturiert?
■ Zu welchen Ableseeinheiten gehören die Ablesungen, die vermehrt nicht
abgerechnet werden?
■ …
Die Kombination der verschiedenen Kriterien erlaubt dabei eine Vielzahl an
möglichen Sichten auf die Ergebnisse.
4.3 Konzept
Abbildung 28: Grobkonzept der Umsetzung der Fallstudie
Der erste Schritt der Umsetzung ist, zunächst die Ziele und die dahinter stehenden
Geschäftsprozesse zu analysieren und zu verstehen. Nur so ist es möglich, die Daten
zu identifizieren, die für den Analyseprozess und damit für das Erreichen der
definierten Ziele notwendig sind.
4 Fallbeispiel „Anlagen-Analyse“
- 61 -
Es ist wichtig festzulegen, welche Daten von Bedeutung sind, aus welcher Tabelle
sie extrahiert werden können und ob möglicherweise Verknüpfungen verschiedener
Tabellen vor dem eigentlichen Prozess der Datenbeschaffung sinnvoll sind.
Anschließend müssen die Daten für die Weiterverarbeitung im Analyse-Prozess-
Designer in das Business Warehouse übertragen werden. Dazu sollte der Business
Content zunächst näher betrachtet werden, um den Prozess der Datenbeschaffung zu
standardisieren und zu vereinfachen. Ist es nicht möglich, alle benötigten Daten über
den vorhanden Business Content zu extrahieren, müssen die DataSources selbst
erzeugt oder der Business Content angepasst werden. Sowohl im Prozess der
Datenbeschaffung als auch im späteren Verlauf des Analyseprozesses sollte die
Datenqualität optimiert werden.
Anschließend werden die Daten im Analyse-Prozess-Designer verknüpft und
transformiert. Eine regelmäßige Prüfung der Zwischenergebnisse vereinfacht das
Auffinden von Fehlern sowie deren Beseitigung direkt an der Stelle an der sie
auftreten. Nach der Durchführung des Analyseprozesses werden die Endergebnisse
geprüft sowie Queries für die verschiedenen Abfragen erzeugt.
Die Optimierung und ggf. Erweiterung sind ein begleitender Prozess, da die
einzelnen Phasen immer wieder zu Erkenntnissen führen, die das gesamte Konzept
und damit auch die Ergebnisse verbessern können.
4.4 Datenauswahl
Dieser Abschnitt beschreibt, welche Daten für die Zielsetzungen der Fallstudie
benötigt werden und aus welchen Datenbanktabellen des IS-U diese zu beschaffen
sind.
Anlagen
Um Aussagen darüber machen zu können, ob eine Anlage abgelesen, abgerechnet
und fakturiert worden ist, werden zunächst alle aktiven Anlagen benötigt. Diese
werden über ihre Anlagennummer eindeutig identifiziert. Um die aktiven von den
inaktiven Anlagen trennen zu können, werden darüber hinaus die zeitabhängigen
Daten (gültig ab, gültig bis) zu den Anlagen benötigt.
Die zeitunabhängigen Daten befinden sich im IS-U in der Tabelle EANL. Dabei
werden nur folgende Daten benötigt:
■ Anlagennummer
■ Sparte
Die Sparte ist laut Zielsetzung für die Differenzierung in der späteren Auswertung
von Bedeutung. Da in der Tabelle EANL jeder Anlage eine Sparte zugeordnet ist,
werden diese Informationen an dieser Stelle direkt mit extrahiert.
4 Fallbeispiel „Anlagen-Analyse“
- 62 -
Die zeitabhängigen Daten befinden sich in der Tabelle EANLH. Es werden folgende
Daten benötigt:
■ Anlagennummer
■ gültig bis
Über das Feld gültig bis werden im späteren Verlauf die inaktiven Anlagen
ausgefiltert.
Obwohl in beiden Tabellen jeweils alle Anlagen mit ihrer Anlagennummer vertreten
sind, ist es dennoch nötig, beide Tabellen auszulesen, da die Informationen bezüglich
der Sparte nicht in der Anlagen-Tabelle mit den zeitabhängigen Daten vorhanden
sind. Darüber hinaus ist es nur an dieser Stelle möglich, die Daten auszulesen, wenn
einer Anlage die weder abgelesen, noch abgerechnet, noch fakturiert wurde, eine
Sparte zugeordnet werden soll.
Ablesebeleg
Um eine Aussage darüber machen zu können, ob eine Anlage abgelesen wurde,
werden die Ablesebelege benötigt.
Die Daten über die Ablesebelege befinden sich in der Tabelle EABL. Es werden
folgende Daten benötigt:
■ Ablesebelegnummer
■ abrechnungsrelevantes Datum
■ Ablesestatus
In dieser Tabelle gibt es u.a. noch die Felder geplantes Ablesedatum und
tatsächliches Ablesedatum. Letzteres ist nur dann mit Daten gefüllt, wenn das
geplante Ablesedatum nicht eingehalten wurde. Das abrechnungsrelevante Datum
entspricht jedoch immer dem späteren der beiden Daten und ist damit immer das
Datum, am dem die Ablesung stattgefunden hat. Somit können komplizierte
Verfahren zum Abgleich zwischen geplantem und tatsächlichem Ablesedatum
vermieden werden.
Das abrechnungsrelevante Datum wird für die Auswertung verwendet, um zeitliche
Bezüge zwischen den Ablesungen, Abrechungen und Fakturierungen herzustellen.
Der Ablesestatus gibt u.a. Auskunft darüber, ob bisher lediglich ein Ableseauftrag
erstellt wurde oder ob eine Ablesung tatsächlich schon stattgefunden hat.
Ablesegrund
Die Datenbanktabelle mit den Ablesegründen wird in zweifacher Hinsicht benötigt.
Zum Einen um eine Differenzierung in der späteren Auswertung bezüglich der
Gründe der Ablesung machen zu können, zum Anderen um den Anlagen einen
Ablesebeleg zuzuordnen.
4 Fallbeispiel „Anlagen-Analyse“
- 63 -
Die Daten bezüglich des Ablesegrundes befinden sich in der Tabelle EABLG. Es
werden folgende Daten benötigt:
■ Ablesebelegnummer
■ Anlagennummer
■ Ablesegrund
So kann mit dieser Tabelle aufgrund der Felder Ablesebelegnummer und
Anlagennummer die Verbindung zwischen den Anlagen und den Ablesebelegen
geschaffen werden.
Abrechnungsbeleg
Der Abrechnungsbeleg ist das Ergebnis der Abrechnung und dient als Beweis, dass
eine Anlage abgelesen wurde.
Die Daten des Abrechnungsbelegs befinden sich in der Tabelle ERCH. Folgende
Daten werden benötigt:
■ Abrechnungsbelegnummer
■ Stornodatum
■ Simulation
Existiert ein Stornodatum zu einem Abrechnungsbeleg, wurde die Abrechnung
storniert. Somit ist dieser Eintrag für die Auswertung nicht mehr relevant und wird
im späteren Verlauf ausgefiltert.
Wurde der Abrechnungsbeleg nur zum Zweck der Simulation erzeugt, so wird dies
über das Feld Simulation deutlich. Auch diese Abrechnungsbelege werden im
Analyseprozess aussortiert.
Abrechnungsbelegzeilen
Im IS-U werden die einzelnen Positionen des Abrechnungsbelegs in der Tabelle
DBERCHZ gespeichert. Mit Hilfe dieser Tabelle kann die Verbindung zwischen
einem Ablesebeleg und einem Abrechnungsbeleg hergestellt werden. Dies ist
entscheidend, um eine Aussage darüber treffen zu können, ob eine Anlage zwar
abgelesen aber ggf. nicht abgerechnet wurde.
Folgende Daten werden benötigt:
■ Abrechnungsbelegnummer
■ Ablesebelegnummer
Aufgrund der o.g. Felder wird deutlich, dass mit Hilfe der Abrechnungsbelegnummer
und der Ablesebelegnummer die Verknüpfung der beiden Belege ermöglicht wird.
Fakturierungsbelege/Druckbelege
Mit Hilfe der Fakturierungsbelege bzw. der Druckbelege, die das Ergebnis der
Fakturierung darstellen, kann festgestellt werden, ob eine Anlage fakturiert wurde.
4 Fallbeispiel „Anlagen-Analyse“
- 64 -
Diese Daten befinden sich in der Tabelle ERCHC. Folgende Daten werden benötigt:
■ Abrechnungsbelegnummer
■ Druckbelegnummer
■ Datum Fakturastornierung
■ Beleg gebucht
Eine Zuordnung der Druckbelege zu den Abrechnungsbelegen erfolgt über die Felder
Abrechnungsbelegnummer und Druckbelegnummer. Ist ein Beleg gebucht, befindet
sich ein Eintrag im Feld Beleg gebucht. Simulierte Belege besitzen dort keinen
Eintrag. Das Datum der Fakturastornierung wird benötigt, um im Analyse-Prozess-
Designer die stornierten Fakturierungen aussortieren zu können.
Die o.g. Daten bilden die Grundlage für den späteren Analyseprozess. Zusätzlich zu
diesen Daten können aus den bereits ausgewählten Tabellen eine Vielzahl weiterer
Informationen extrahiert werden, um die spätere Auswertung noch detaillierter
gestalten zu können. In diesem Fallbeispiel beschränken sich die benötigten Daten
jedoch auf die Anforderungen, die aus den Zielsetzungen hervorgehen. Eine
Erweiterung des gesamten Konzepts um weitere Daten ist jedoch ohne großen
Aufwand möglich.
4.5 Datenbeschaffung
Nachdem die benötigten Daten und Tabellen identifiziert sind, gilt es nun die Daten
für den Analyseprozess im SAP BW zur Verfügung zu stellen. Dafür wird zunächst
geprüft, ob und in welcher Form der vorhandene Business Content für diesen
Datenbeschaffungsprozess verwendet werden kann. Ist dies nicht möglich, werden
generische DataSources, welche die Daten aus dem Quellsystem extrahieren, neu
erzeugt.
Analyse des vorhandenen Business Content
Da der Analyseprozess, wie bereits beschrieben, in einem SAP BW 3.1 Testsystem
durchgeführt wird, der eine ältere Version des Business Content verwendet, ist es
vielfach nicht möglich mit Hilfe der vorgefertigten Objekte die benötigten Daten aus
dem Quellsystem in das SAP BW zu übertragen. Lediglich die zeitabhängigen und
zeitunabhängigen Daten der Anlagen werden mit Hilfe der vorhandenen DataSources
extrahiert.
Bei näherer Betrachtung des BW 7.0 Testsystems wird deutlich, dass der Business
Content im Laufe der Jahre erheblich erweitert wurde. So wäre es hier durchaus
möglich, fast alle Daten mit Hilfe des Content zu extrahieren und in das BW zu
laden.
In der Praxis wird versucht, möglichst den vorhandenen Business Content zu
verwenden. Aus diesem Grund und der Tatsache, dass das verwendete Testsystem
4 Fallbeispiel „Anlagen-Analyse“
- 65 -
sich nicht auf dem neuesten Stand befindet, wird im weiteren Verlauf dieses
Abschnittes nur kurz auf die Datenbeschaffung mit Hilfe von generischen
DataSources eingegangen.
Generische DataSources
Mit den generischen DataSources ist es möglich, eigene Strukturen für die Extraktion
von Daten zu erzeugen, wenn der vorhandene Business Content nicht ausreichend ist.
So kann z.B. eine Datenbanktabelle oder ein View als Quelle dienen. Dabei können
beliebige Felder ausgewählt werden, die extrahiert werden sollen. Zusätzlich kann
über ein Deltaverfahren und die Möglichkeit der Datenselektion innerhalb der
InfoPackages entschieden werden.
Wie bereits erwähnt, ist es möglich, im Quellsystem Views als Basis der
DataSources zu verwenden, um so mit Hilfe nur weniger DataSources alle benötigten
Daten extrahieren zu können. Um eine größere Transparenz und Flexibilität des
Analyseprozesses zu ermöglichen, wird jedoch in diesem Fallbeispiel zu jeder
Tabelle aus der Daten extrahiert werden sollen, eine eigene generische DataSource
erzeugt. Im weiteren Verlauf werden die Daten in separaten ODS-Objekten
gespeichert.
Datenfluss
Aufgrund der Verwendung von jeweils einer DataSource für jede auszulesende
Datenbanktabelle ist der Datenfluss zum SAP BW für alle Daten nahezu identisch.
Aus diesem Grund wird in der folgenden Abbildung lediglich ein Datenfluss
beispielhaft dargestellt.
Abbildung 29: Beispiel Datenfluss der Umsetzung
4 Fallbeispiel „Anlagen-Analyse“
- 66 -
Aus dem Quellsystem werden die Daten mit Hilfe der replizierten DataSources über
die PSA und die InfoSource in das ODS-Objekt gespeichert. Die Übertragungs- und
Fortschreibungsregeln werden zunächst nicht für die Transformationen der Daten
verwendet, um die Flexibilität des Analyseprozesses nicht zu beeinflussen und alle
Transformationen transparent und übersichtlich im APD darzustellen.1
Datenübertragung
Zu Testzwecken wird zunächst nur ein Teil der Datenmenge aus dem Quellsystem in
das Business Warehouse übertragen und im Analyseprozess verwendet. So ist eine
schnelle Durchführung des Prozesses sowie die Überprüfung der Zwischen- und
Endergebnisse möglich. Deshalb werden in den InfoPackages die Selektionskriterien
so gewählt, dass nur 500-1000 Datensätze aus den Tabellen übertragen werden.
Erst nachdem das Modell mit den Teildaten vollständig getestet und überprüft ist,
werden alle zur Verfügung stehenden Daten in das Modell übertragen.
Die Daten werden bei der vollständigen Extraktion nicht gefiltert, d.h. es findet keine
zeilenweise Selektion statt. Stattdessen findet die Filterung im Analyseprozess statt
(z.B. alle inaktiven Anlagen entfernen), um alle durchgeführten Transformationen
übersichtlich mit Hilfe des APD durchzuführen und darzustellen.
Lediglich die Extraktion der Abrechnungsbelegzeilen aus der Tabelle DBERCHZ
bildet hierbei eine Ausnahme. Die Tabelle ist so umfangreich, dass es sinnvoll ist
schon beim Ladevorgang die Daten zu filtern, um so nur die Datensätze zu
transferieren in denen sich die Beziehungen zwischen Abrechnungsbelegnummern
und Ablesebelegnummern widerspiegeln. Alle weiteren unnötigen Datensätze
werden an dieser Stelle bereits aussortiert.
4.6 Analyseprozess
Nachdem die Daten im SAP BW zur Verfügung stehen, kann der Analyseprozess mit
Hilfe des APD modelliert werden.
Um das Gesamtkonzept des Analyseprozesses besser zu veranschaulichen, wird
zunächst der grundsätzliche Gedankengang auf einem höheren Abstraktionsniveau
beschrieben. Anschließend wird das vollständige Modell dargestellt und schrittweise
erläutert.
1 Siehe auch Abschnitt 3.6, Abgrenzung zu den Möglichkeiten im BW, auf Seite 51
4 Fallbeispiel „Anlagen-Analyse“
- 67 -
4.6.1 Grundlegender Ablauf
Abbildung 30: Ablauf des Analyseprozesses
Zunächst werden alle Anlagen ermittelt, die sich aktiv im System befinden und gültig
sind (also vom Kunden verwendet werden).
Anschließend werden den Anlagen die Ablesebelege zugeordnet. Ist ein Ablesebeleg
zu einer Anlage vorhanden, wurde diese zum entsprechenden Datum abgelesen.
Dann werden die Abrechnungsbelege den Ablesebelegen zugeordnet. Existiert ein
Abrechnungsbeleg zu einem Ablesebeleg, so wurde die Anlage nicht nur abgelesen,
sondern auch abgerechnet. Existiert kein Abrechnungsbeleg zu einem Ablesebeleg,
wurde die Anlage zwar abgelesen, jedoch nicht abgerechnet.
Im letzten Schritt werden die Fakturierungs- bzw. Druckbelege den Abrechnungs-
belegen zugeordnet. Gibt es einen Druckbeleg zu einem Abrechnungsbeleg, wurde
die Anlage fakturiert. Andernfalls wurde sie zwar abgelesen und abgerechnet, jedoch
nicht fakturiert.
Dieser grundlegende Ablauf abstrahiert viele Gegebenheiten und Einschränkungen.
Er bildet jedoch das Grundgerüst für den vollständigen Analyseprozess.
4.6.2 Detaillierte Modellbeschreibung
In Abbildung 31 ist das vollständige Modell des Analyseprozesses für das
Fallbeispiel der Anlagen-Analyse dargestellt.
Um die einzelnen Transformationen und Verknüpfungen verständlich beschreiben zu
können, wurde jeder Teilschritt mit einer Nummer versehen.1 Jeder dieser Schritte
wird in den folgenden Abschnitten detailliert erläutert. Die Bezeichnungen der
Schritte können von denen aus der Abbildung abweichen, da für das Modell eine
möglichst kurze Bezeichnung aus Gründen der Übersichtlichkeit sinnvoll ist.
1 Eine vergrößerte, nicht nummerierte Darstellung befindet sich in Abschnitt 6.1, Anhang, auf Seite 91
4 Fallbeispiel „Anlagen-Analyse“
- 68 -
Abbildung 31: Anlagen-Analyse-Prozess
Schritt 1 – Anlage (zeitunabhängige Daten)1
Der erste Schritt stellt lediglich die zeitunabhängigen Daten der Anlage dem APD-
Prozess zur Verfügung. Dafür wird das ODS-Objekt, in das die Anlage-Daten bei der
Extraktion geladen wurden, als Datenquelle ausgewählt.
4 Fallbeispiel „Anlagen-Analyse“
- 69 -
Ein Ausschnitt der Daten wird in der folgenden Abbildung dargestellt:
Abbildung 32: Zwischenergebnis Schritt 1
Somit stehen alle vorhandenen Anlagen, identifiziert über ihre Anlagennummer,
sowie die dazugehörigen Sparten zur Verfügung.
Schritt 2 – Anlage (zeitabhängige Daten) 2
Im zweiten Schritt werden die zeitabhängigen Daten der Anlagen als Quelle
definiert.
Abbildung 33: Zwischenergebnis Schritt 2
Zu jeder Anlagennummer existiert damit ein Eintrag bis zu welchem Datum eine
Anlage gültig ist. In Abbildung 33 gibt es zu der Anlagennummer 1230000003 zwei
Einträge. Aus dem ersten Datensatz wird deutlich, dass die Anlage bis zum
30.09.2001 gültig war. Anschließend wurde sie erneut aktiviert und ist bis zu dem
aktuellen Datum gültig (dies ist am Datum 31.12.9999 ersichtlich).
Schritt 3 – Inaktive Anlagen entfernen3
In Schritt 3 werden alle inaktiven Anlagen aus Schritt 2 entfernt. Diese Selektion
erfolgt anhand des Feldes gültig bis. Alle Einträge die nicht 31.12.9999 als Wert
besitzen, werden aussortiert. Durch dieses Vorgehen werden zusätzlich diejenigen
Anlagen weitergereicht, die zwischenzeitlich nicht aktiv waren, aktuell aber wieder
gültig sind.
4 Fallbeispiel „Anlagen-Analyse“
- 70 -
Abbildung 34: Zwischenergebnis Schritt 3
Wie die Abbildung zeigt, wurden alle Einträge mit einem anderen Datum als dem
31.12.9999 entfernt.
Schritt 4 – Aktive Anlagen mit Sparte4
Mit Hilfe dieser Verknüpfung werden die Anlagennummern aus Schritt 1 mit denen
aus Schritt 3 verknüpft. Zusätzlich wird die Sparte übernommen. Der eigentliche
Sinn liegt jedoch darin, dass aus der Tabelle der Anlagen mit den Sparten alle
inaktiven Anlagen gelöscht werden.
Abbildung 35: Verknüpfung in Schritt 3
Dies geschieht durch die Verknüpfung der Tabellen mittels Inner Join über die
Felder der Anlagennummer. Somit werden nur die Anlagen in die Ergebnismenge
übernommen, die sich in beiden Tabellen befinden.
Abbildung 36: Zwischenergebnis Schritt 4
Das Ergebnis sind demnach alle aktiven Anlagen mit ihren Sparten. Das Feld gültig
bis hat seinen Zweck erfüllt und wird im weiteren Verlauf nicht weiter benötigt und
somit auch nicht übernommen.
Der Umweg der Filterung der Daten über die genannten Schritte ist deshalb
notwendig, weil auf der einen Seite nur in den zeitabhängigen Daten das Feld gültig
bis vorhanden ist und sich auf der anderen Seite die Angabe zu den Sparten nur in
der Tabelle mit den zeitunabhängigen Daten befindet.
Alternativ wäre es auch möglich, zunächst die Verknüpfung der beiden Tabellen
durchzuführen und anschließend die inaktiven Daten auszusortieren. Das Ergebnis ist
4 Fallbeispiel „Anlagen-Analyse“
- 71 -
in beiden Fällen dasselbe. Die Performance erhöht sich jedoch, wenn die zu
verknüpfende Datenmenge möglichst gering ist.
Schritt 5 – Ablesebelege5
In diesem Schritt werden alle Ablesebelege mit ihren eindeutigen Nummern, dem
Ablesestatus sowie dem abrechnungsrelevanten Datum zur Verfügung gestellt.
Abbildung 37: Zwischenergebnis Schritt 5
Schritt 6 – Bisher nicht durchgeführte Ablesungen entfernen6
Es existieren Ablesebelege, zu denen noch keine Ablesung durchgeführt wurde.
Diese sind durch den Ablesestatus 0 gekennzeichnet und werden in diesem Schritt
ausgefiltert.
Schritt 7 – Ablesegrund7
Schritt 7 versorgt den APD-Prozess mit den Daten der Ablesegründe.
Abbildung 38: Zwischenergebnis Schritt 7
Wie aus der Abbildung deutlich wird, kann es zu einem Ablesebeleg mehrere
Ablesegründe geben. So gehören beispielsweise die Ablesegründe 08, 06 und 21
zusammen (sie stehen für die Vorgänge Einzugsablesung, Ablesung zum technischen
Einbau und Ablesung zum abrechnungstechnischen Einbau).
Zusätzlich werden neben den Ableseeinheiten auch die Anlagennummern, die zu
einem Ablesebeleg gehören, zur Verfügung gestellt.
4 Fallbeispiel „Anlagen-Analyse“
- 72 -
Schritt 8 – Ablesegründe ohne Abrechnung entfernen8
Wie aus den Ausführungen zu den Ablesegründen deutlich wird, folgt nicht
zwangsläufig auf einen Ablesebeleg mit einem bestimmten Ablesegrund auch eine
Abrechnung (z.B. Ablesung zum technischen Einbau). Ablesebelege die keine
Abrechnung zur Folge haben, sind für die Auswertung nicht relevant und verfälschen
das Ergebnis. Aus diesem Grund werden nur folgende Ablesegründe berücksichtigt:
■ 01 – Turnusablesung
■ 02 – Zwischenablesung mit Abrechnung
■ 03 – Schlussablesung mit Umzug
■ 04 – Gebietsablesung mit Abrechnung
Die Ablesebelege mit anderen Gründen werden in diesem Schritt aussortiert. Sollen
dennoch andere Ablesegründe weiter berücksichtigt werden, ist dies durch einfache
Modifikation dieses einzelnen Transformationsschrittes möglich.
Abbildung 39: Zwischenergebnis Schritt 8
Im Vergleich zu Abbildung 38 wird in dieser Grafik deutlich, dass nur die
Ablesebelege mit den genannten Ablesegründen weitergegeben werden.
Schritt 9 – Zuordnung Ablesegründe zu den Ablesebelegen9
An dieser Stelle werden die Ergebnisse der Schritte 6 und 8 miteinander verknüpft.
Somit werden nicht nur den Ablesebelegen die Ablesegründe zugeordnet, sondern
auch alle Ablesebelege entfernt, deren Ablesegründe nicht betrachtet werden sollen.
Abbildung 40: Verknüpfung Schritt 9
4 Fallbeispiel „Anlagen-Analyse“
- 73 -
Die Verbindung erfolgt mittels Inner Join über die Felder Ablesebelegnummer.
Alternativ hätten erst die Verknüpfungen der Ablesebelege mit den Gründen und
anschließend die beiden Filteraktionen durchgeführt werden können. Jedoch ist es,
wie bereits in Schritt 4 erläutert, aus Performancegründen sinnvoll, die zu
verknüpfenden Datenmengen möglichst zu minimieren.
Abbildung 41: Zwischenergebnis Schritt 9
Das Ergebnis dieses Schrittes sind die Ablesebelege mit ihren Ableseeinheiten,
Ablesegründen und den abrechungsrelevanten Daten.
Schritt 10 – Zuordnung Ablesebelege zu Anlagen10
In diesem Schritt erfolgt die Zuordnung der Anlagen zu den Ablesungen, d.h. bereits
nach diesem Schritt kann eine Aussage darüber getroffen werden, ob eine Anlage
abgelesen wurde.
Abbildung 42: Verknüpfung Schritt 10
Über die Anlagennummer, die sich sowohl in der Tabelle der Ablesebelege als auch
in der Anlagen-Tabelle befindet, werden alle Daten miteinander kombiniert. In
diesem Fall erfolgt die Verknüpfung über einen Left Outer Join, wobei die aktiven
Anlagen die „linke Tabelle“ darstellen. Dadurch werden zum Einen die Ablesebelege
den richtigen Anlagen zugeordnet, andererseits bleibt das Feld der
Ablesebelegnummer in der Ergebnistabelle leer, wenn es keinen Ablesebeleg zu
einer Anlage gibt. Nur so ist es möglich festzustellen, dass eine Anlage nicht
abgelesen wurde.
4 Fallbeispiel „Anlagen-Analyse“
- 74 -
Abbildung 43: Zwischenergebnis Schritt 10
Aus der Ergebnismenge wird deutlich, dass eine Anlage mehrere Ablesebelege
besitzen kann. Dieser Umstand ergibt sich daraus, dass Ablesungen immer wieder
durchgeführt werden, z.B. jährlich.
Schritt 11 – Abrechnungsbeleg11
Schritt 11 liefert lediglich die Daten zu den Abrechnungsbelegen und beinhaltet
neben der Abrechnungsbelegnummer auch ein mögliches Stornodatum sowie ein
Kennzeichen, ob der Beleg ausschließlich zur Simulation erzeugt wurde.
Abbildung 44: Zwischenergebnis Schritt 11
Schritt 12 – Stornierte u. simulierte Abrechnungsbelege entfernen12
In diesem Schritt werden die Abrechnungsbelege gefiltert. Nur solche Belege, die
weder storniert, noch ausschließlich zum Zweck der Simulation erzeugt wurden,
werden weitergegeben.
Abbildung 45: Zwischenergebnis Schritt 12
Somit befindet sich in der Ergebnismenge zu keinem Datensatz ein Stornodatum
oder ein Simulationskennzeichen.
4 Fallbeispiel „Anlagen-Analyse“
- 75 -
Schritt 13 – Abrechnungsbelegzeilen13
Schritt 13 stellt die Abrechnungsbelegzeilen zur Verfügung. Diese ermöglichen die
Zuordnung von Abrechnungsbeleg zu Ablesebeleg. Dabei können zu einem
Abrechnungsbeleg mehrere Ablesebelege existieren.
Abbildung 46: Zwischenergebnis Schritt 13
Schritt 14 – Stornierte Belegzeilen entfernen14
Durch die Verknüpfung der Schritte 12 und 13 ist es möglich, all jene Zuordnungen
von Abrechnungs- und Ablesebelegen zu löschen, die durch stornierte oder
simulierte Belege entstanden sind.
Abbildung 47: Verknüpfung Schritt 14
Technisch erfolgt diese Umsetzung erneut mit Hilfe des Inner Join. Dieser sorgt
dafür, dass alle Abrechnungsbelegzeilen entfernt werden, die zu den stornierten oder
simulierten Abrechnungsbelegen gehören.
Das Stornodatum sowie das Kennzeichen für die Simulation werden nicht weiter
benötigt und daher nicht übernommen.
Abbildung 48: Zwischenergebnis Schritt 14
4 Fallbeispiel „Anlagen-Analyse“
- 76 -
Schritt 15 – Zuordnung Abrechnungsbelege zu Ablesebelegen15
Schritt 15 ordnet den Anlagen mit den Ablesebelegen die Abrechnungsbelege zu.
Somit kann ab dieser Stelle eine Aussage darüber getroffen werden, ob eine Anlage
abgerechnet wurde.
Abbildung 49: Verknüpfung Schritt 15
Die Verknüpfung erfolgt erneut mittels Left Outer Join über das Feld der
Ablesebelegnummer. Die Felder der Anlagen mit Ablesebelegen, die keinen
Abrechnungsbeleg haben, bleiben leer. Nur so ist eine Aussage möglich, welche
Anlagen zwar abgelesen, aber nicht abgerechnet wurden.
Abbildung 50: Zwischenergebnis Schritt 15
Schritt 16 – Sortierung nach Anlagen16
In diesem Schritt werden die Daten aufsteigend nach den Anlagennummern sortiert.
Mit Hilfe der Sortierung können die Zwischenergebnisse besser kontrolliert und
dargestellt werden. Auf den weiteren Verlauf des Prozesses hat die Sortierung keinen
Einfluss, da die Daten bei den meisten Transformationen schon im Vorfeld intern
sortiert werden, so dass eine separate Sortierung lediglich zu Performanceeinbußen
führt. Aus diesem Grund sollten die Sortierungen bei umfangreichen
Analyseprozessen nach erfolgreichem Testen der Zwischen- und Endergebnisse
entfernt werden.
4 Fallbeispiel „Anlagen-Analyse“
- 77 -
Schritt 17 – Nicht simulierte Fakturierungsbelege (Druckbelege) 17
Schritt 17 stellt dem Prozess die Druckbelege zur Verfügung. Dabei wurden die
simulierten Belege bereits bei der Extraktion der Daten ausgefiltert.
Abbildung 51: Zwischenergebnis Schritt 17
Neben der Zuordnung von Abrechnungsbeleg und Fakturierungsbeleg befinden sich
in den gegebenen Daten das Buchungsdatum der Fakturastornierung sowie das
Kennzeichen, ob der Abrechnungsbeleg fakturiert wurde.
Schritt 18 – Stornierte Fakturierungen entfernen18
In diesem Schritt werden alle stornierten oder nicht gebuchten Druckbelege entfernt,
da sie zu falschen Ergebnissen in der Auswertung führen würden. Somit werden nur
solche Datensätze weitergegeben, die einen Eintrag im Feld Beleg gebucht und
keinen Eintrag im Feld Buchungsdatum Fakturastornierung besitzen.
Abbildung 52: Zwischenergebnis Schritt 18
Schritt 19 – Zuordnung Druckbelege zu Abrechnungsbelege19
Nun erfolgt die Zuordnung der Druckbelege zu den Abrechnungsbelegen. Somit
kann eine Aussage darüber getroffen werden, ob eine Anlage fakturiert wurde.
Befindet sich kein Eintrag im Feld für den Druckbeleg, wurde die Anlage mit dem
jeweiligen Ablesebeleg und dem entsprechenden Abrechnungsbeleg nicht fakturiert.
4 Fallbeispiel „Anlagen-Analyse“
- 78 -
Abbildung 53: Verknüpfung Schritt 19
Technisch wird die Verknüpfung erneut mit Hilfe des Left Outer Joins realisiert. Die
Felder Buchungsdatum der Fakturastornierung sowie Belege gebucht haben ihren
Zweck erfüllt und werden nicht weiter benötigt.
Das sortierte Ergebnis von Schritt 19 sieht wie folgt aus:
Abbildung 54: Zwischenergebnis Schritt 20
An dieser Stelle wird deutlich, dass eine Anlage an einem bestimmten Datum zwar
abgelesen (es existiert eine Ablesebelegnummer) und auch abgerechnet (es existiert
eine Abrechnungsbelegnummer), jedoch ggf. nicht fakturiert wurde (es existiert
keine Druckbelegnummer).
Schritt 20 – Sortieren nach Anlagen20
Wie bereits in Schritt 16 erläutert, wird die Sortierung der Anlagen nur zum Zweck
der übersichtlicheren Darstellung verwendet.
Schritt 21 – Routine zur Ermittlung von Kennzahlen und Jahr21
Die ABAP-Routine in Schritt 21 verfolgt zwei Ziele. Zum Einen soll aus dem
abrechnungsrelevanten Datum die Jahreszahl in ein separates Feld geschrieben
werden. Zum Anderen sollen die Felder Anlage abgelesen, Anlage nicht abgelesen,
Anlage abgerechnet, Anlage nicht abgerechnet, Anlage fakturiert, Anlage nicht
fakturiert erzeugt und mit 0 oder 1 gefüllt werden (siehe Abbildung 55). Diese
generierten Kennzahlen erlauben in der späteren Auswertung die Aggregation der
Anlagen.
4 Fallbeispiel „Anlagen-Analyse“
- 79 -
Aus Gründen der Performance werden beide Aufgaben innerhalb von nur einer
Routine abgearbeitet. Andernfalls müssten alle Datensätze zweimal durchlaufen
werden, was den gesamten Prozess deutlich verlangsamen würde.
Das Ergebnis wird aus Abbildung 55 deutlich.
Abbildung 55: Zwischenergebnis Schritt 21
1
In der Routine werden die Felder Ableseeinheit, Ablesegrund, Sparte und Anlage als
Gruppierungsfelder definiert. Sie stehen der Routine somit nicht zur Verfügung und
werden einfach weitergereicht.
Die Felder abrechnungsrelevantes Datum, Ablesebelegnummer, Abrechnungs-
belegnummer sowie Druckbelegnummer werden als Quellfelder definiert und werden
benötigt, um die neuen Felder mit Inhalt zu füllen.
Als Zielfelder werden alle Quellfelder sowie die neu erzeugten Felder festgelegt. Nur
Quellfelder die auch als Zielfelder definiert sind, werden am Ende der Routine neben
den Gruppierungsfeldern weitergegeben.
Die Routine durchläuft jeden Datensatz der Quellfelder. Wenn sich ein Datum im
Feld abrechungsrelevantes Datum befindet, werden in das Zielfeld Jahr die ersten 4
Zeichen des Quellfeldes geschrieben. Diese entsprechen aufgrund der Art der
Speicherung von Datumsfeldern dem jeweiligen Jahr.2
Die anderen Zielfelder werden in Abhängigkeit davon ob die Quellfelder
Ablesebelegnummer, Abrechnungsbelegnummer und Druckbelegnummer Daten
1 Aufgrund der Anzahl der Spalten wurde die Abbildung aufgeteilt
2 Beispielsweise 20080406 für den 06.04.2008
4 Fallbeispiel „Anlagen-Analyse“
- 80 -
beinhalten, mit 0 oder 1 gefüllt. Gibt es beispielsweise zu einer Anlage einen
Ablesebeleg, erfolgt im Feld Anlage abgelesen der Eintrag 1. Analog verhält es sich
bei den restliche Zielfeldern.
...
*-------------------- Begin of transformation code -------------------------
DATA: ls_source TYPE y_source_fields,
ls_target TYPE y_target_fields.
LOOP AT it_source INTO ls_source.
IF ls_source-ADAT NE SPACE.
ls_target-ZJAHR = ls_source-ADAT(4).
ENDIF.
IF ls_source-ABLBELNR NE SPACE.
ls_target-ANLABG = '1'.
ls_target-ANLNABG = '0'.
ELSE.
ls_target-ANLABG = '0'.
ls_target-ANLNABG = '1'.
ENDIF.
IF ls_source-ZBELENR NE SPACE.
ls_target-ANLABGR = '1'.
ls_target-ANLNABGR = '0'.
ELSE.
ls_target-ANLABGR = '0'.
ls_target-ANLNABGR = '1'.
ENDIF.
IF ls_source-OPBEL NE SPACE.
ls_target-ANLFAK = '1'.
ls_target-ANLNFAK = '0'.
ELSE.
ls_target-ANLFAK = '0'.
ls_target-ANLNFAK = '1'.
ENDIF.
MOVE-CORRESPONDING ls_source TO ls_target.
APPEND ls_target TO et_target.
ENDLOOP.
*---------------------- End of transformation code -------------------------
...
Listing 2: ABAP Routine Schritt 211
1 Der vollständige Code befindet sich in Abschnitt 6.3, Anhang, auf Seite 93
4 Fallbeispiel „Anlagen-Analyse“
- 81 -
Schritt 21 – Sortieren nach Anlagen22
Wie in Schritt 16 und 20 findet an dieser Stelle eine Sortierung aufsteigend nach den
Anlagennummern statt.
Schritt 22 – Duplikate entfernen23
An dieser Stelle werden mit Hilfe der Aggregationsfunktion doppelte Einträge, die
durch die verschiedenen Verknüpfungen entstanden sind, entfernt. Dabei werden alle
Felder als Gruppierungsfelder angegeben. So findet keine Aggregation von
Kennzahlen statt, sondern es werden lediglich alle Duplikate aussortiert.
Schritt 23 – Feldzuordnung zum ODS-Objekt24
Letztlich muss noch eine Feldzuordnung vorgenommen werden, die definiert, welche
Felder der Ergebnistabelle des letzten Schrittes auf welche Felder des ODS-Objektes
zugeordnet werden sollen.
Schritt 24 – ODS-Objekt25
Das ODS-Objekt beinhaltet alle Felder der Ergebnismenge aus Schritt 23 in Form
von InfoObjects und nimmt damit alle Ergebnisdaten des Analyseprozesses auf.
4.7 Datenspeicherung
Für die Speicherung der Ergebnisse des Analyseprozesses wird für dieses
Fallbeispiel ein transaktionales ODS-Objekt gewählt. Dieses kann die Daten nicht
nur sehr performant abspeichern, sondern bei Bedarf auch in nachfolgenden
Datenzielen weiter fortschreiben. So wäre es, je nach Fragestellung und Zielsetzung,
auch sinnvoll, die Daten nachträglich in einen InfoCube abzulegen, um so eine
bessere Analyse und Auswertung großer Datenbestände zu ermöglichen.
Im Fallbeispiel wird dieses Vorgehen jedoch nicht weiter betrachtet. Stattdessen wird
ein InfoSet erzeugt, das als einzige Quelle das transaktionale ODS-Objekt
zugewiesen bekommt. Durch dieses Vorgehen ist es möglich, indirekt ein
transaktionales ODS-Objekt als Quelle von Queries zu verwenden.
4 Fallbeispiel „Anlagen-Analyse“
- 82 -
Abbildung 56: Eigenschaften des transaktionalen ODS-Objekts
4.8 Datenauswertung
Das zugrunde liegende Datenmaterial der Ergebnismenge des APD-Prozesses erlaubt
eine Vielzahl an möglichen Auswertungen und Abfragen. Im Folgenden sollen die
wichtigsten Aspekte anhand zweier Queries beispielhaft erläutert werden.
Abbildung 57: Beispiel-Query 1
In der ersten Query werden alle Kennzahlen (als Spalten) sowie die Merkmale Jahr,
Sparte und Ablesegrund (als Zeilen) definiert. Zusätzlich wird das Jahr auf den Wert
2000 beschränkt.
4 Fallbeispiel „Anlagen-Analyse“
- 83 -
Das Ergebnis dieser Query ist in der folgenden Abbildung dargestellt:
Abbildung 58: Ergebnis Beispiel-Query 1
Bereits diese sehr spezifische Auswertung erlaubt es, eine Vielzahl an Fragen zu
beantworten, z.B.:
■ Wie viele Ablesebelege wurden im Jahr 2000 abgelesen, abgerechnet, fakturiert?
■ Wie viele Ablesebelege wurden im Jahr 2000 abgelesen, aber nicht abgerechnet?
■ Wie viele Ablesebelege wurden im Jahr 2000 abgelesen, abgerechnet aber nicht
fakturiert?
■ Zu welcher Sparte gehören die Anlagen der Ablesebelege?
■ Welche Ablesegründe gab es für die Ablesebelege?
■ Sind fehlende Abrechnungen für bestimmte Sparten oder bei bestimmten
Ablesegründen besonders auffällig?
■ …
In der folgenden Query sollen alle Anlagen angezeigt werden, die zwar abgerechnet
aber nicht fakturiert worden sind. Eine mögliche Umsetzung dieser Fragestellung ist,
mit Hilfe einer Query, in der folgenden Abbildung dargestellt:
Abbildung 59: Beispiel-Query 2
4 Fallbeispiel „Anlagen-Analyse“
- 84 -
Einen Ausschnitt der Ergebnisse der Query zeigt die folgende Abbildung:
Abbildung 60: Ergebnis Beispiel-Query 2
Obwohl die Auswertungen bei Bedarf sehr stark auf eine bestimmte Fragestellung
eingeschränkt werden können, ist es oft hilfreich den Gesamtzusammenhang zu
betrachten, um so die Ergebnisse richtig interpretieren zu können. So ist es z.B. nicht
ungewöhnlich, dass eine Anlage, die vor einem Tag abgelesen wurde, nicht schon am
Folgetag fakturiert ist.
In diesem Zusammenhang ist es auch von Bedeutung, wann und zu welchem
Zeitpunkt die Statistik erstellt und aktualisiert wird. Diesen Aspekt gilt es in
Absprache mit den Fachabteilungen zu berücksichtigen und entsprechend
umzusetzen.
4.9 Optimierungen
Bereits im aktuellen Zustand des Analysemodells lassen sich die beteiligten Prozesse
sehr performant durchführen. Dennoch gibt es viele Möglichkeiten einen
Analyseprozess, vor allem mit größeren Datenmengen, weiter zu optimieren. Einen
kurzen Überblick über die Optimierungspotentiale gibt Tabelle 3.
Neben den in der Tabelle genannten technischen Optimierungen gibt es auch
verschiedene fachliche Erweiterungen, die sinnvoll durchgeführt werden könnten. Da
dieses Fallbeispiel jedoch in erster Linie zur Darstellung der Möglichkeiten und
Einsatzgebiete des APD dient, wird auf eine detaillierte Betrachtung an dieser Stelle
verzichtet.
4 Fallbeispiel „Anlagen-Analyse“
- 85 -
Optimierung Beschreibung
InfoSets für Verknüpfungen verwenden
Verknüpfungen von verschiedenen Objekten können innerhalb des BW mit Hilfe von InfoSets schneller durchgeführt werden als dies im APD möglich ist. So könnten in der Fallstudie z.B. die zeitabhängigen Daten mit den zeitunabhängigen Daten der Anlage schon im Vorfeld durch ein Infoset verknüpft werden. Das InfoSet wird anschließend als eine Quelle des APD-Prozesses verwendet.
Für Verknüpfungen, die im späteren Verlauf des Analyseprozesses vollzogen werden sollen, können jedoch keine InfoSets verwendet werden.
Spalten umbennen
Ab der Version 3.5 des Business Warehouse gibt es die Möglichkeit mit Hilfe einer Transformation die Spalten der Ergebnismenge umzubennen. Diese Funktion kann sinnvoll genutzt werden, um ähnlich klingende oder schlecht bezeichnete Felder verständlicher zu machen.
Nur benötigte Daten aus dem Quellsystem laden
Indem zuvor klare Anforderungen definiert werden, können die zu extrahierenden Daten auf das benötigte Minimum beschränkt werden. Dies führt zu einer deutlichen Verbesserung des Ladevorganges, erschwert auf der anderen Seite jedoch die Erweiterbarkeit des Modells.
Filtern der Daten auf Quellsystem-ebene
Viele der in der Fallstudie verwendeten Filtertransformationen können schon auf Ebene des Quellsystems beim Extraktionsvorgang durchgeführt werden. Dies optimiert nicht nur den Ladevorgang der Daten in das BW, sondern auch den APD-Prozess selbst, indem die Filtertransformationen nicht mehr benötigt werden. Jedoch wird der gesamte APD-Prozess dadurch weniger transparent.
Sortierungen löschen
Wie bereits erwähnt, werden die Sortierungen lediglich für die Auswertung von Zwischenergebnissen verwendet. Für den eigentlichen Prozess sind sie irrelevant und sollten, nach der Validierung der Ergebnisse, entfernt werden.
Duplikate entfernen
Das Entfernen von Duplikaten sollte im Idealfall an der Stelle geschehen, an der sie entstehen. So werden die Duplikate nicht unnötigerweise durch alle weiteren Transformationen getragen.
Prozessketten verwenden
Mit Hilfe der Prozessketten können die gesamten Abläufe für einen Analyseprozess automatisiert werden. Sie sind von besonderer Bedeutung, wenn Aktualisierungen regelmäßig stattfinden sollen.
Probleme bei zeitlichen Übergängen
Werden Anlagen beispielsweise am 31.12.2007 abgelesen, jedoch erst am 01.01.2008 abgerechnet, sind die Ergebnisse bei einer Aggregation auf Jahresebene fehlerhaft, da für das Jahr 2007 die Anlage als nicht abgerechnet angezeigt wird. Dieses Problem lässt sich nur über eine Umstellung des gesamten Analyseprozesses oder mittels einer weiteren ABAP-Routine beheben.
Felder in Query berechnen
Die Felder Anlage nicht abgelesen, Anlage nicht abgerechnet, Anlage nicht fakturiert können auch mittels selbst definierter Kennzahlen in der Query mit Daten gefüllt werden. Dadurch wird der Analyseprozess und insbesondere die ressourcenintensive ABAP-Routine innerhalb des Prozesses weiter entlastet.
Texte hinterlegen
Um Merkmale nicht über Nummern interpretieren zu müssen, können zum Zweck der Auswertung Texte zu den jeweiligen Ausprägungen hinzugefügt werden (z.B. Sparte: 10 - „Strom“)
InfoCube für die Auswertung verwenden
Um Auswertungen, insbesondere bei großen Datenmengen schneller durchführen zu können, empfiehlt sich das Fortschreiben der Daten aus den transaktionalen ODS-Objekt in einen InfoCube. Dieser ist für das Lesen der Daten optimiert und erlaubt so eine performante Durchführung der Queries.
Aggregationen der Zeit-einheiten im InfoCube
Zusätzlich bietet der InfoCube bessere Möglichkeiten über Zeiteinheiten zu aggregieren. So werden innerhalb eines InfoCubes lediglich mit Hilfe einer einzelnen Zeitangabe (z.B. 13.12.2007) alle anderen Zeitmerkmale wie Kalenderwoche, Jahr, Geschäftsjahr etc. berechnet. Dadurch könnte in dem Fallbeispiel die Berechnung des Jahres mit Hilfe der ABAP-Routine entfallen.
Tabelle 3: Optimierungen des Analyseprozesses
5 Abschluss
- 86 -
5 Abschluss
5.1 Zusammenfassung
Einleitend in diese Projektarbeit wurde der ETL-Prozess der Datenbeschaffung im
SAP Business Warehouse beschrieben. Dazu war es notwendig, zunächst die Objekte
des BW, deren Zusammenspiel und Verbindung sowie den gesamten Datenfluss von
einem SAP Quellsystem in das Business Warehouse zu betrachten. Neben der
Beschreibung des Business Content wurde der gesamte ETL-Prozess für Stammdaten
im SAP BW 3.x mit all seinen Fortschreibungs- und Verbuchungsarten sowie dem
Delta-Verfahren erläutert. Zusätzlich wurden die wesentlichen Änderungen im
Objektkonzept und Datenfluss im SAP BW 7.0 kurz dargestellt.
Anschließend wurde die Funktionsweise des Analyse-Prozess-Designers
beschrieben, wie dieser in das SAP BW eingebunden ist, welche Phasen ein
Analyseprozess umfasst und welche wesentlichen Unterschiede in den verschiedenen
Versionen des APD zu finden sind. Zusätzlich wurden die Möglichkeiten des APD
von denen des BW abgegrenzt und die möglichen Auswirkungen auf den ETL-
Prozess dargestellt.
Im Fallbeispiel wurden zunächst die wichtigen branchenspezifischen
Begrifflichkeiten erläutert, die zum Verständnis des Beispiel-Analyseprozesses
notwendig sind. Anschließend wurden die benötigten Daten identifiziert, ausgewählt
und beschafft. Die detaillierte Beschreibung des gesamten Analyseprozesses in all
seinen Schritten war Bestandteil des nachfolgenden Abschnittes. Nach der
beispielhaften Auswertung und Analyse wurden abschließend noch mögliche
Optimierungspotentiale aufgezeigt, die zu einer verbesserten Performance des
gesamten Prozesses führen sollen.
Insgesamt konnte so ein Überblick über die Funktionen und Einsatzgebiete des
Analyse-Prozess-Designers geschaffen werden, der als Grundlage weiterer Arbeiten
sowie der anschließenden Diplomarbeit dienen kann.
5.2 Fazit
Der Analyse-Prozess-Designer ist die konsequente Weiterentwicklung des Business
Warehouse, um komplexe Modellierungs- und Analyseprozesse einfach,
übersichtlich, transparent und modular entwerfen zu können. Er ermöglicht die
Filterung, Verknüpfung und Transformation von Daten, die ggf. bereits im Business
5 Abschluss
- 87 -
Warehouse konsolidiert wurden, um so neue Informationen zu schaffen, die für ein
Unternehmen von besonderer Bedeutung sein können.
Vor allem im Hinblick auf das Data Mining ist der APD das entscheidende Tool, um
die Daten für die verschiedenen Verfahren und Techniken der statistisch-
mathematischen Berechnungen vorzubereiten. Aber auch ohne die Verwendung der
Data Mining Techniken erlaubt es der Analyse-Prozess-Designer komplexe
Datenmodellierungen durchzuführen, die im SAP BW gar nicht oder nur mit einem
deutlichen Mehraufwand möglich sind.
Dennoch gestattet das BW eine deutlich performantere Durchführung, zumindest der
grundlegenden Transformationen, so dass immer ein Kompromiss zwischen
Flexibilität und Transparenz auf der einen Seite, und Effizienz und Performanz auf
der anderen Seite geschaffen werden muss.
Mit Hilfe des APD kann der eigentliche ETL-Prozess des Business Warehouses
erweitert werden. Haben die Daten im BW bereits einen ETL-Prozess durchlaufen,
schließt sich durch das Extrahieren, Transformieren und Laden der Daten im APD
ein weiterer ETL-Prozess an. Oftmals sind die Daten die im APD verwendet werden
jedoch nicht von ausreichender Qualität, so dass sie, insbesondere in Bezug auf das
Data Mining, zunächst konsolidiert und bereinigt werden müssen.
Im Gegensatz zum BW erlaubt der APD eine nahezu unendliche Kette von
Transformationen, deren Umsetzung im SAP BW kaum möglich ist. Auch die
Auswahl von Daten, die sich bereits im BW befinden sowie deren Verwendung in
verschiedenen Prozessen als Quelle (z.B. mittels Queries) ist im Business Warehouse
so nicht möglich.
Sicherlich hätte das Fallbeispiel auch komplett mit Mitteln des Business Warehouse
umgesetzt werden können, jedoch ist der Mehraufwand bei derart komplexen
Prozessen um ein Vielfaches höher und deutlich schwieriger umzusetzen. Mit der
deutlich übersichtlicheren Darstellung lassen sich zudem die Analyseprozesse
wesentlich einfacher erweitern, ohne dass der gesamte Datenfluss geändert werden
muss. Komplizierte Transformationen lassen sich darüber hinaus im BW nur mittels
ABAP-Code realisieren, während im APD diese Funktionen einfach durch
Drag&Drop verwendet werden können. Dieses Vorgehen führt selbst bei einfacheren
Umwandlungen zu einer deutlichen Zeit- und damit Kostenersparnis.
5.3 Ausblick
Die vorliegende Projektarbeit kann in vielfacher Weise als Basis anderer Arbeiten
betrachtet oder in weiteren Projekten erweitert werden.
So wäre es beispielsweise möglich, die Ergebnisse der Fallstudie mit der
Verkaufsstatistik zu verknüpfen. Über die Angabe der Anlagen die ggf. nicht
abgelesen, nicht abgerechnet oder nicht fakturiert wurden, könnten in Kombination
mit den Verbräuchen der Vorjahre sowie den Daten aus der Verkaufsstatistik,
Aussagen darüber getroffen werden, wie viel Umsatz dem Unternehmen entgangen
5 Abschluss
- 88 -
ist. Neben diesen komplexen Verknüpfungen und Transformationen von Daten für
spezifische Auswertungen, gibt es eine Reihe weiterer Einsatzgebiete für den APD.
In der Praxis werden durch fortlaufende Erweiterungen der Analysemöglichkeiten
die Extraktstrukturen im Quellsystem immer umfangreicher und die InfoCubes im
Business Warehouse immer unperformanter. Mittelfristig ist dies ein grundlegendes
Problem, welches durch die Umstellung auf den APD behoben werden kann. So
können Analyseprozesse helfen, die Performanz der Datenbeschaffung sowie der
Auswertung zu erhöhen. Beispielsweise können zusätzliche Stammdaten, die nicht
regelmäßig aktualisiert werden müssen, erst in einem APD-Prozess den jeweiligen
Merkmalen zugeordnet werden. Bisher ist dies nur über eine Erweiterung des
Extraktors im Quellsystem möglich. Um jedoch die Stammdaten nicht bei jedem
Extraktionsvorgang redundant mit übertragen zu müssen, werden diese individuell in
einem Analyseprozess zu einer Abfrage hinzugefügt. Zusätzlich sind durch diese
Vorgehensweise die Faktentabellen der InfoCubes weniger umfangreich, was zu
deutlichen Performancesteigerungen bei der Auswertung führt. Darüber hinaus
können die InfoCubes weiter entlastet werden, indem Queries als Quelle eines
Analyseprozesses verwendet werden. Diese können mit anderen Daten (z.B.
Stammdaten) verknüpft und anschließend in separate Datenziele gespeichert werden.
Somit erfolgt die Auswertung auf diese Datenziele und nicht wie zuvor auf die
ausgelasteten InfoCubes. Dadurch werden die Informationen, die sich in den
InfoCubes befinden, auf Teilfragen und spezifische, rollenabhängige Auswertungen
beschränkt, indem jeder nur auf die Daten zugreift, die er für seine Analysen und
sein Reporting benötigt.
Viele weitere Kombinationen von Daten aus verschiedenen Systemen sind mit Hilfe
dieser Projektarbeit sowie den darin enthaltenen Erläuterungen zu den Funktionen
des APD möglich.
Einer der wesentlichen Gründe für die Entwicklung des Analyse-Prozess-Designers
ist jedoch das Data Mining, welches in dieser Arbeit nicht weiter betrachtet wurde,
jedoch Bestandteil der nachfolgenden Diplomarbeit sein soll. Der APD ist, vor allem
in seiner aktuellen Version, sehr eng mit den Techniken des Data Mining verbunden
und erlaubt es, verschiedene Data Mining Verfahren innerhalb eines
Analyseprozesses zu verwenden, um so weitere, nicht triviale Informationen zu
entdecken, die durch einfaches Betrachten von Daten nicht ersichtlich sind, jedoch
für ein Unternehmen von besonders hoher Bedeutung sein können.
So kann das Data Mining z.B. auf Analysen der Verkaufsstatistik in Kombination
mit weiteren Stammdaten durchgeführt werden. Dadurch können beispielsweise die
wichtigen Kunden eines Unternehmens herausgefunden oder Kundengruppen auf
verschiedene Weisen identifiziert und analysiert werden. Es kann auch berechnet
werden, wie wahrscheinlich es ist, dass ein Kunde mittelfristig kündigt und zu einem
Mitbewerber wechselt. Solche Aussagen sind im Rahmen der Öffnung des
Energiemarktes von immer größerer Bedeutung und ermöglichen beispielsweise
gezielte Marketingaktionen. Die genannten Beispiele sind jedoch nur ein kleiner Teil
möglicher Auswertungen, die mit Hilfe des Data Mining realisiert werden können.
5 Abschluss
- 89 -
Mit dieser Projektarbeit wurde ein grundlegendes Verständnis für die Funktionsweise
und Verwendung des Analyse-Prozess-Designers geschaffen. Darauf aufbauend
sollen in der nachfolgenden Diplomarbeit die Möglichkeiten erläutert werden, die
das SAP Business Warehouse in Bezug auf das Data Mining zur Verfügung stellt.
Dabei steht neben der Erläuterung der verschiedenen Verfahren vor allem die praxis-
und branchenbezogene Umsetzung von Analyse-Prozessen mit den Techniken des
Data Mining im Vordergrund. Getreu dem Motto:
»We are drowning in information, but starving for knowledge«1
1 Vgl. [Naisbitt, 1984]
6 Anhang
- 90 -
6 Anhang
6.1 Anlagen-Analyse-Prozess
6 Anhang
- 91 -
6.2 A selection of useful ISU-Tables
Vgl. [Lapa, 2008]
6 Anhang
- 92 -
6.3 ABAP-Routine des Analyseprozesses
REPORT RSAN_WB_ROUTINE_TEMP_REPORT .
TYPES: BEGIN OF y_group_fields ,
ABLEINH TYPE /BIC/OIABLEINH ,
ABLESGR TYPE /BIC/OIABLESGR ,
SPARTE TYPE /BIC/OISPARTE ,
ANLAGE TYPE /BIC/OIANLAGE ,
END OF y_group_fields .
TYPES: BEGIN OF y_source_fields ,
ZBELENR TYPE /BIC/OIZBELENR ,
ABLBELNR TYPE /BIC/OIABLBELNR ,
OPBEL TYPE /BIC/OIOPBEL ,
ADAT TYPE /BIC/OIADAT ,
END OF y_source_fields .
TYPES: yt_source_fields TYPE STANDARD TABLE OF y_source_fields .
TYPES: BEGIN OF y_target_fields ,
ADAT TYPE /BIC/OIADAT ,
ZJAHR TYPE /BIC/OIZJAHR ,
ABLBELNR TYPE /BIC/OIABLBELNR ,
ZBELENR TYPE /BIC/OIZBELENR ,
OPBEL TYPE /BIC/OIOPBEL ,
ANLABG TYPE /BIC/OIANLABG ,
ANLNABG TYPE /BIC/OIANLNABG ,
ANLABGR TYPE /BIC/OIANLABGR ,
ANLNABGR TYPE /BIC/OIANLNABGR ,
ANLFAK TYPE /BIC/OIANLFAK ,
ANLNFAK TYPE /BIC/OIANLNFAK ,
END OF y_target_fields .
TYPES: yt_target_fields TYPE STANDARD TABLE OF y_target_fields .
*---------- Begin of type definitions -------------------------------
*TYPES: ...
*----------- End of type definitions --------------------------------
FORM compute_data_transformation
USING is_group TYPE y_group_fields
it_source TYPE yt_source_fields
EXPORTING et_target TYPE yt_target_fields .
*--------- Begin of transformation code -----------------------------
DATA: ls_source TYPE y_source_fields,
ls_target TYPE y_target_fields.
6 Anhang
- 93 -
LOOP AT it_source INTO ls_source.
IF ls_source-ADAT NE SPACE.
ls_target-ZJAHR = ls_source-ADAT(4).
ENDIF.
IF ls_source-ABLBELNR NE SPACE.
ls_target-ANLABG = '1'.
ls_target-ANLNABG = '0'.
ELSE.
ls_target-ANLABG = '0'.
ls_target-ANLNABG = '1'.
ENDIF.
IF ls_source-ZBELENR NE SPACE.
ls_target-ANLABGR = '1'.
ls_target-ANLNABGR = '0'.
ELSE.
ls_target-ANLABGR = '0'.
ls_target-ANLNABGR = '1'.
ENDIF.
IF ls_source-OPBEL NE SPACE.
ls_target-ANLFAK = '1'.
ls_target-ANLNFAK = '0'.
ELSE.
ls_target-ANLFAK = '0'.
ls_target-ANLNFAK = '1'.
ENDIF.
MOVE-CORRESPONDING ls_source TO ls_target.
APPEND ls_target TO et_target.
ENDLOOP.
*---------- End of transformation code ------------------------------
ENDFORM.
7 Abkürzungsverzeichnis
- 94 -
7 Abkürzungsverzeichnis
ABAP Advanced Business Application Programming
ALE Application Link Enabling
APD Analyse-Prozess-Designer
ASCII American Standard Code for Information Interchange
DTP Datentranfserprozess
BW Business Warehouse
CCS Customer Care Service
CIC Customer Interaction Center
CRM Customer Relationship Management
CSV Comma Seperated Value
DSO Data Store Objekt
EDM Energy Data Management
EnWG Energiewirtschaftsgesetz
ERP Enterprise Ressource Planning
ETL Extraktion, Transformation und Laden
GUI Graphical User Interface
IDOC Intermediate Document
IS-U Industry Solution for Utilities
ODBO OLE DB for OLAP
ODS Operational Data Store
SAP Software Anwendungen und Programme
8 Abbildungsverzeichnis
- 95 -
8 Abbildungsverzeichnis
Abbildung 1: Der ETL-Prozess .................................................................. 12
Abbildung 2: Verwendung von InfoObjects im SAP BW .......................... 15
Abbildung 3: erweitertes Sternschema im SAP BW .................................. 19
Abbildung 4: Beispiel – Datenfluss im SAP BW ....................................... 22
Abbildung 5: Übertragungsregeln .............................................................. 23
Abbildung 6: Fortschreibungsregeln .......................................................... 25
Abbildung 7: Direkte Fortschreibung ......................................................... 26
Abbildung 8: Flexible Fortschreibung ........................................................ 27
Abbildung 9: Datenfluss im SAP BW 7.0 .................................................. 32
Abbildung 10: Zentrale Funktionen des APD ............................................ 33
Abbildung 11: Schritte im Analyse-Prozess-Designer ............................... 35
Abbildung 12: Beispiel – Datenmenge einschränken ................................. 38
Abbildung 13: Beispiel 1 – Daten aggregieren ........................................... 39
Abbildung 14: Beispiel 2 – Daten aggregieren ........................................... 40
Abbildung 15: Beispiel – Daten zweier Quellen miteinander verknüpfen . 40
Abbildung 16: Beispiel – Daten aus zwei Datenquellen vereinigen .......... 41
Abbildung 17: Beispiel – Daten sortieren .................................................. 42
Abbildung 18: Beispiel – Liste in Datensatz transformieren ...................... 42
Abbildung 19: Beispiel – Datensatz in Liste transformieren ...................... 43
Abbildung 20: Standardanwendungen von SAP ........................................ 46
Abbildung 21: APD-GUI ............................................................................ 47
Abbildung 22: Dekoration, Konnektor, Datenflusspfeil ............................. 48
Abbildung 23: Beispiel eines Analyseprozesses ........................................ 51
Abbildung 24: Integrationsmodell des ISU ................................................ 55
Abbildung 25: IS-U Haus ........................................................................... 56
Abbildung 26: Ablauf der Vertragsabrechnung (vereinfacht) .................... 57
8 Abbildungsverzeichnis
- 96 -
Abbildung 27: Ablauf der Vertragsabrechnung ......................................... 58
Abbildung 28: Grobkonzept der Umsetzung der Fallstudie ....................... 60
Abbildung 29: Beispiel Datenfluss der Umsetzung .................................... 65
Abbildung 30: Ablauf des Analyseprozesses ............................................. 67
Abbildung 31: Anlagen-Analyse-Prozess ................................................... 68
Abbildung 32: Zwischenergebnis Schritt 1 ................................................ 69
Abbildung 33: Zwischenergebnis Schritt 2 ................................................ 69
Abbildung 34: Zwischenergebnis Schritt 3 ................................................ 70
Abbildung 35: Verknüpfung in Schritt 3 .................................................... 70
Abbildung 36: Zwischenergebnis Schritt 4 ................................................ 70
Abbildung 37: Zwischenergebnis Schritt 5 ................................................ 71
Abbildung 38: Zwischenergebnis Schritt 7 ................................................ 71
Abbildung 39: Zwischenergebnis Schritt 8 ................................................ 72
Abbildung 40: Verknüpfung Schritt 9 ........................................................ 72
Abbildung 41: Zwischenergebnis Schritt 9 ................................................ 73
Abbildung 42: Verknüpfung Schritt 10 ...................................................... 73
Abbildung 43: Zwischenergebnis Schritt 10 .............................................. 74
Abbildung 44: Zwischenergebnis Schritt 11 .............................................. 74
Abbildung 45: Zwischenergebnis Schritt 12 ............................................... 74
Abbildung 46: Zwischenergebnis Schritt 13 .............................................. 75
Abbildung 47: Verknüpfung Schritt 14 ...................................................... 75
Abbildung 48: Zwischenergebnis Schritt 14 .............................................. 75
Abbildung 49: Verknüpfung Schritt 15 ...................................................... 76
Abbildung 50: Zwischenergebnis Schritt 15 .............................................. 76
Abbildung 51: Zwischenergebnis Schritt 17 .............................................. 77
Abbildung 52: Zwischenergebnis Schritt 18 .............................................. 77
Abbildung 53: Verknüpfung Schritt 19 ...................................................... 78
Abbildung 54: Zwischenergebnis Schritt 20 .............................................. 78
Abbildung 55: Zwischenergebnis Schritt 21 .............................................. 79
Abbildung 56: Eigenschaften des transaktionalen ODS-Objekts ............... 82
Abbildung 57: Beispiel-Query 1 ................................................................. 82
Abbildung 58: Ergebnis Beispiel-Query 1 ................................................. 83
8 Abbildungsverzeichnis
- 97 -
Abbildung 59: Beispiel-Query 2 ................................................................. 83
Abbildung 60: Ergebnis Beispiel-Query 2 ................................................. 84
9 Tabellenverzeichnis
- 98 -
9 Tabellenverzeichnis
Tabelle 1: Verbuchungsarten ...................................................................... 28
Tabelle 2: Unterschiede zwischen den Versionen des APD ....................... 52
Tabelle 3: Optimierungen des Analyseprozesses ........................................ 85
10 Listingverzeichnis
- 99 -
10 Listingverzeichnis
Listing 1: Beispiel – ABAP-Routine ........................................................... 44
Listing 2: ABAP Routine Schritt 21 ........................................................... 80
11 Quellenverzeichnis
- 100 -
11 Quellenverzeichnis
Literatur
[Egger et al., 2005]
N. Egger, J.R. Fiechter, R. Salzmann, R.P. Sawicki, T. Thielen;
SAP BW Datenbeschaffung;
Galileo Press; Bonn 2005; 1. Auflage; ISBN 3-89842-536-3
[FuFu; 2003]
B. Fu, H. Fu;
SAP BW – A Step-by-Step Guide;
Addinson-Wesley; 2003; ISBN 0-201-70366-1
[Gómez et al., 2006]
J.M. Gómez, C. Rautenstrauch, P. Cissek, B. Grahlher;
Einführung in SAP Business Information Warehouse;
Springer Verlag; Heidelberg 2006, ISBN 978-3-540-31124-9
[KeJa, 2002]
H. Keller, J. Jacobitz;
ABAP Objects Referenz;
Galileo Press; Bonn 2002; 1 .Auflage; ISBN 3-934358-61-6
[KeKr, 2001]
H. Keller, S. Krüger;
ABAP Objects – Einführung in die SAP-Programmierung;
Galileo Press; Bonn 2001; 2. Auflage; ISBN 3-89842-147-3
[Kemper et al.,2006]
H. Kemper, W. Mehanna, C. Unger;
Business Intelligence – Grundlagen und praktische Anwendungen;
Friedr. Vieweg & Sohn Verlag / GWV Fachverlage GmbH; Wiesbaden 2006; 2. Auflage;
ISBN 978-3-8348-0275-0
[KiVa, 2007]
M. Kießwetter, D. Vahlkamp;
Data Mining in SAP Netweaver BI;
Galileo Press; 1. Auflage; Bonn 2007; ISBN 978-3-89842-850-7
[Mehrwald, 2007]
C. Mehrwald;
Datawarehousing mit SPA BW 7 – BI in SAP Netweaver 2004s;
dpunkt.verlag GmbH; Heidelberg 2007; 4. Auflage; ISBN 978-3-89864-460-0
[Naisbitt, 1984]
J. Naisbitt;
Megatrends - Ten New Directions Transforming Our Lives
Warner Books, 1984; ISBN 978-0-44690-991-4
11 Quellenverzeichnis
- 101 -
[Seemann et al., 2001]
A. Seemann, B. Schmalzridt, P. Lehmann;
SAP Business Information Warehouse;
Galileo Press; Bonn 2001; 1. Auflage; ISBN 3-934358-41-1
SAP-Unterlagen
[BW310, 2005]
BW310; Data Warehousing; SAP Schulungsunterlagen Teilnehmerhandbuch
Version 2005/Q1; Materialnummer: 50071081; SAP AG
[BW330, 2005]
BW330; Business Information Warehouse – Modellierung
Version 2005/Q1; Materialnummer: 50069512; SAP AG
[BW350, 2005]
BW350; SAP BW – Datenxtraktion; SAP Schulungsunterlagen Teilnehmerhandbuch
Version 2005/Q2; Materialnummer: 50074682; SAP AG
[BW380, 2005]
BW380; SAP Business Intelligence - Analyseprozesse und Data Mining;
SAP Schulungsunterlagen Teilnehmerhandbuch Version 2005/Q1;
Materialnummer: 50072606; SAP AG
[BWFunctions, 2003]
SAP Business Information Warehouse – Functions in Detail
Version 2.0; SAP AG 2003
[IUT110, 2005]
IUT100; EInführung in das System ISU/CCS
SAP IS-Utilities/Customer Care Service 471; Version 2005/Q1;
Materialnummer: 50071399
Online-Quellen
[EVU-IT, 2008]
evu.it Website: Unternehmen
http://www.evu-it.de/front_content.php?idcat=31 (30.03.2008, 07:55)
[Lapa, 2008]
Marcin Lapa; Utility and SAP Consultant; http://marcinlapa.com (11.04.2008, 15:17)
[SAPBib3x, 2008]
SAP-Bibliothek: SAP Business Information Warehouse
http://help.sap.com/saphelp_nw04/helpdata/de/49/7e960481916448b20134d471d36a6b/fr
ameset.htm (31.03.2008, 11:52)
[SAPBib3xDelta7]
SAP-Bibliothek: Enterprise Data Warehousing (Neuerungen im SAP BW 7)
http://help.sap.com/saphelp_nw2004s/helpdata/de/31/ec1342eb11de2ce10000000a1550
b0/frameset.htm (09.04.2008, 10:30)
[SAPBib7, 2008]
SAP-Bibliothek: SAP Netweaver 7.0 (2004s)
http://help.sap.com/saphelp_nw70/helpdata/DE/45/dc799c25c15592e10000000a1553f7/fr
ameset.htm (09.04.2008, 10:25)
11 Quellenverzeichnis
- 102 -
[SAPBibBI, 2008]
SAP-Bibliohtek: BI Plattform
http://help.sap.com/saphelp_nw70/helpdata/DE/49/7e960481916448b20134d471d36a6b/f
rameset.htm (01.04.2008, 12:55)
[SAPBibUtil, 2008]
Sap-Bibliothek: SAP Utilities
http://help.sap.com/saphelp_utilities472/helpdata/de/c6/4dce68eafc11d18a030000e829fb
bd/frameset.htm (10.04.2008, 10:00)
12 Glossar
- 103 -
12 Glossar
Hier finden Sie kurze Erläuterungen zu den wichtigsten Fachbegriffen. Die Begriffe
sind alphabetisch aufsteigend geordnet. Das Zeichen weist auf einen ebenfalls im
Glossar aufgeführten Begriff hin.
ABAP
Die Advanced Business Application Programming (ABAP) ist eine von SAP
entwickelte Programmiersprache für die Entwicklung im SAP Umfeld.
ABAP Objects
ABAP Objects ist eine Erweiterung von ABAP um die Elemente der
objektorientierten Programmierung (außer Mehrfachvererbung und Überladen von
Methoden).
Administrator Workbench
Die Administrator Workbench ist das zentrale Element innerhalb des SAP
Business Warehouse zur Modellierung von Data-Warehousing-Prozessen. Mit
ihr können alle Prozesse der Datenbeschaffung, -haltung und –verarbeitung
gesteuert, überwacht und gepflegt werden.
ALE
Application Link Enabling erlaubt die Kommunikation mittels kontrolliertem
Nachrichtenaustausch zwischen verteilten (SAP-)Anwendungssystemen.
APD Workbench
Die APD Workbench ist die grafische Benutzeroberfläche des Analyse-Prozess-
Designers und stellt dem Anwender die Funktionalitäten zur Modellierung und
Durchführung analytischer Prozesse zur Verfügung.
Ausnahmeaggregation
Mit Hilfe eines weiteren Bezugsmerkmals wird bei einer Aggregation der zu
verwendende Wert festgelegt. Beispielsweise kann die Bestandsgröße „Anlagen“
über das Merkmal „Sparte“ aggregiert werden. Falsch wäre dagegen eine
Aggregation über verschiedene Zeiträume, denn dann würden mehr Anlagen
ermittelt als vorhanden sind. So kann z.B. die Angabe „letzter Wert“ bezogen auf
die Größe „Kalendermonat“ bewirken, dass immer der letzte Wert verwendet
wird. Weitere Ausnahmeaggregationen sind u.a. „Min“, „Max“ oder
„Durchschnitt“.
12 Glossar
- 104 -
Customizing
Beim Customizing werden die vorgegebenen oder bereits definierten Objekte des
Business Warehouse an die spezifischen Bedürfnisse und Anforderungen des
Kunden angepasst.
DataMart
Data Marts werden als Datenziele definiert, die in weitere Datenziele
fortgeschrieben werden können. Sie sind somit kleine Einheiten des Data
Warehouse, die den Austausch zwischen einem oder mehreren BW-Systemen
ermöglichen.
Data Mining
Mit Hilfe des Data Mining sollen neue, nicht triviale Informationen mit Hilfe von
mathematisch-statistischen Verfahren ermittelt werden. D.h., es wird automatisiert
nach Mustern in den vorhandenen Daten gesucht, um so die operativen, taktischen
oder strategischen Entscheidungen in einem Unternehmen unterstützen zu
können.
Data Warehouse
Ein Data Warehouse ist das konsolidierte Datenlager eines Unternehmens, das
sich aus vielen verschiedenen Quellen zusammensetzen kann. Die Daten im Data
Warehouse werden in erster Linie für analytische Auswertungen genutzt.
Drag&Drop
Durch Betätigen der linken Maustaste lassen sich grafische Objekte „Ziehen und
Fallenlassen“. Das Drag&Drop-Verfahren stellt somit eine Art der Bedienung von
grafischen Benutzeroberflächen dar.
ERP-System
Enterprise Resource Planing Systeme unterstützen das Unternehmen mit Hilfe
komplexer Anwendungssoftware bei der Ressourcenplanung und –verteilung.
Exclude-Selektionsbedingung
Die Exclude-Selektionsbedingung stellt das Gegenstück zur normalen
Selektionsbedingung dar. Dabei werden alle Daten selektiert, die nicht der
Bedingung entsprechen.
Granularität
Die Granularität beschreibt den Feinheitsgrad von Daten im Data Warehouse.
Eine hohe Granularität führt zu einer großen Datenmenge, da auch Details
beschrieben werden. Eine niedrige Granularität abstrahiert dagegen gewisse
Eigenschaften der Daten.
IDOC
Das Intermediate Document stellt eine Art Container dar, der für den
Datenaustausch zwischen den verschiedenen SAP-Systemen oder einem
Fremdsystem genutzt wird.
12 Glossar
- 105 -
InfoProvider
Ein InfoProvider ist ein Sammelbegriff für diejenigen Datenziele, auf deren
Datenbestand Analysen und Queries durchgeführt werden können und die als
Quelle für weitere Prozesse zur Verfügung stehen.
Inner Join
Diese Art von Join fügt nur die Datensätze aus zwei Tabellen zusammen, die den
angegebenen Kriterien entsprechen. Alle anderen Datensätze erzeugen keinen
Eintrag in der Ergebnismenge.
IS-U
Die Branchenkomponente Versorgungsindustrie dient innerhalb von SAP Utilities
der Verwaltung und Abrechnung von Kunden.
Left Outer Join
Der Left-Outer-Join unterscheidet zwischen linker und rechter Tabelle. Alle
Datensätze der linken Tabelle werden mit Ergänzung der Daten aus der rechten
Tabelle in die Ergebnismenge eingefügt. Existiert zu einem Datensatz der linken
Tabelle kein passender Eintrag in der rechten Tabelle, bleiben die Felder der
Ergebnismenge in Bezug auf die rechte Tabelle leer.
Metadata Repository
Das Metadata Repository verwaltet und bietet den zentralen Zugriff auf alle
Metadaten (Eigenschaften und Verknüpfungen von Objekten) im SAP
Business Warehouse.
Metadaten
Als Metadaten werden Daten bezeichnet, die Informationen über Daten beinhalten
und so z.B. die Eigenschaften von Daten beschreiben.
Prozessketten
Mit Hilfe von Prozessketten können Abläufe automatisiert werden. So wird die
Prozesskette nach Eintreten eines definierten Ergebnisses gestartet und löst
verschiedene aufeinander folgende Prozesse aus, die im Business Warehouse
durchgeführt werden sollen.
Query
Als Query bezeichnet man eine Abfrage, die auf einem InfoProvider
durchgeführt wird, um Analysen durchzuführen oder Berichte zu erzeugen.
Replikation
Mit Hilfe der Replikation werden DataSources aus einem Quellsystem im
Business Warehouse bekannt gemacht. Durch diesen Vorgang ist es möglich,
Daten aus einem Quellsystem in das BW zu übertragen.
SAP
Die SAP AG ist einer der weltweit größten Softwarehersteller der Welt. Ihre
Produkte richten sich in erste Linie an mittelständische oder große Kunden und
decken alle Geschäftsprozesse eines Unternehmens ab.
12 Glossar
- 106 -
Transportanschluss
Mit Hilfe des Transportanschlusses können komplette Strukturen von einem
System in ein anderes übertragen werden (z.B. von einem Test- und in
Produktivsystem).
Versionierung
Das Versionierungssystem von SAP erlaubt die Unterscheidung u.a. zwischen
aktiven, modifizierten und inaktiven Versionen von Objekten und Bestandteilen
des SAP-Systems. Dadurch ist es zum Beispiel möglich, Objekte zu verändern
und zu speichern, ohne dass das System durch die Änderungen beeinflusst wird.
Vertragskontokorrent
Das Vertragskontokorrent stellt eine Art Nebenbuchaltung dar, um die Vielzahl an
Buchungen eines Energieversorgungsunternehmens zu sammeln und gemeinsam
fakturieren zu können.
13 Eidesstattliche Erklärung
- 107 -
13 Eidesstattliche Erklärung
Gemäß § 26 (1) der DPO erkläre ich an Eides statt, dass ich die vorliegende Arbeit
selbständig angefertigt habe. Ich habe mich keiner fremden Hilfe bedient und keine
anderen, als die angegebenen Quellen und Hilfsmittel benutzt. Alle Stellen, die
wörtlich oder sinngemäß veröffentlichten oder nicht veröffentlichten Schriften und
anderen Quellen entnommen sind, habe ich als solche kenntlich gemacht. Diese
Arbeit hat in gleicher oder ähnlicher Form noch keiner Prüfungsbehörde vorgelegen.
Dortmund, den 15.03.2009 ______________________________
(Dennis Halboth)
14 Stichwortverzeichnis
- 108 -
14 Stichwortverzeichnis
- A -
ABAP Routine 47
Abbildungsverzeichnis 103
Abgrenzung 9
Abkürzungsverzeichnis 102
Ablesebeleg 67, 77
Ablesegrund 68, 77
Ablesung 62
Abrechnung 59, 63
Abrechnungsbeleg 68, 80
Abrechnungsbelegzeilen 69, 81
Abschluss 94
Abstract 5
Aggregationsfelder 43
ALE-Änderungszeiger 31
Analyseprozess 72 Grundlegender Ablauf 72
Analyse-Prozess-Designer 36
Änderungen im BW 7.0 32
Anlage 62
Anlagen-Analyse 58
Anschlussobjekt 61
Anwendungen 50
Anwendungstyp 53
APD Abgrenzung zum BW 54 Auswirkungen auf den ETL-Prozess 55 Funktionsweise 51 Unterschiede der Versionen 56 Versteckte Funktionen 53
ASCII 40
Attribute 15
Attribute eines Merkmals ändern 49
Attribute eines Merkmals lesen 39
Ausblick 95
- B -
Business Content 22
- C -
CRM-Attribute aktualisieren 49
CSV 40
- D -
DataSource 18, 33
Daten aggregieren 42
Daten anzeigen lassen 52
Daten aus Datei lesen 40
Daten aus Datenbanktabelle lesen 40
Daten aus InfoProvider lesen 39
Daten aus zwei Quellen miteinander verknüpfen 43
Daten aus zwei Quellen vereinigen 44
Daten in Datei schreiben 49
Daten sortieren 45
Daten über Query lesen 40
Datenauswahl 67
Datenflusspfeile 52
Datenmenge einschränken 41
Datenquellen 38
Datensatz in Liste transformieren 46
Datentransferprozess 34
Datenziele 48
Delta-Update 31
Delta-Verfahren 30
Direkte Fortschreibung 27
Druckbelege 69
- E -
Early-Delta-Initialisierung 32
EE1 11
Eingesetzte Software 10
Einheit 18
Einleitung 8
Elementare Statistik anzeigen 53
Energiewirtschaftsgesetz 8
Energy Data Management 59
ETL-Prozess 12, 55 Phasen 12
ETL-Prozess im SAP BW 3.x 23
evu.it GmbH Geschäftsbereiche 9
14 Stichwortverzeichnis
- 109 -
evu.it GmbH 8
Exclude-Selektionsbedingung 41
Extraktion 13
Extraktstruktur 19
- F -
Fakturierung 59, 63
Fakturierungsbeleg 69
Fallbeispiel 58 Datenauswertung 89 Datenbeschaffung 70 Datenspeicherung 88 Konzept 66 Optimierungen 91 Zielsetzung 65
Fazit 94
Flexible Fortschreibung 28
Formel 45
Formeleditor 45
Fortschreibungsregeln 26
Full-Update 31
- G -
Generische DataSource 70
Geräteplatz 62
Geräteverwaltung 59
Geschäftspartner 61
Glossar 111
Grundfunktionen 59
- H -
Hierarchien 16
Histogramme 53
- I -
IDE 59
IDOC 19
InfoCube 20
InfoObject 16
InfoPackage 22, 34
InfoSet 21
InfoSource 19, 34
Inhaltsverzeichnis 6
Initialisierung des Delta-Verfahrens 31
Integration des APD in das SAP BW 37
IS-U Haus 60
- K -
Kennzahl 17
Knoten 51
Konnektoren 52
Kundenservice 59
Kurzfassung 4
- L -
Laden 15
Liste in Datensatz transformieren 46
- M -
Markenrechtlicher Hinweis 3
Merkmal 17
Metadata Repository 13
Metadaten 13
Modellbeschreibung 73
MultiProvider 22
- O -
Objektkonzept im SAP BW 3.x 16
ODBO 40
ODS/DSO-Objekt schreiben 49
Operational Data Store 21
- P -
Persistent Staging Area 19, 33
Prozessphasen 37
- Q -
Quellenverzeichnis 108
Query 90
- R -
rku.it 9
Routine 84
- S -
SAP for Utilities 58
SID-Tabellen 20
Simulation 64
Sortieren 82, 84, 87
Spalten ausblenden oder umbenennen 45
Sperrvermerk 2
Stammdaten kaufmännisch 61 technisch 61
Stammdaten im SAP BW 15
Stammdatentragendes Merkmal 18
Stammdatenverwaltung 59
Standardaggregation 39
Sternschema 20
Stornierung 64
14 Stichwortverzeichnis
- 110 -
- T -
T7B 11
TB1 11
Texte 15
Thematik 8
Transferstruktur 19
Transformation 14, 33, 40
- U -
Übertragungsregeln 24
Übertragungsverfahren 24
- V -
Verbrauchsstelle 62
Verbuchungsarten 29
Vertrag 61
Vertragsabrechnung 62
Vertragskonto 61
- W -
Waste and Recycling 59
Wiederholung eines Delta-Updates 32
Work Management 59
- Z -
Zählpunkt 62
Zeit 18
Zielsetzung der Arbeit 9
Zusammenfassung 94
Zwischenergebnis berechnen 53