Grundbegriffe zum BW310 Data Warehousing

A
Administrator Workbench .......................................................................................................................... 4
Aggregat ..................................................................................................................................................... 4
ALE (Application Link Enabling) ................................................................................................................ 6
Anwendungskomponentenhierarchie ........................................................................................................ 6
Archivierung ............................................................................................................................................... 6
Attribut........................................................................................................................................................ 7

B
BAPI (Business Application Programming Interface) ............................................................................... 7
BasisCube .................................................................................................................................................. 8
Business Content (BCT)............................................................................................................................. 9
Business Explorer (BEx) .......................................................................................................................... 10

C
Cleansing/Homogenisierung.................................................................................................................... 10

D
Datengranularitt...................................................................................................................................... 10
Data Dictionary ......................................................................................................................................... 10
Data Mart Interface ................................................................................................................................... 11
DataSource ............................................................................................................................................... 11
DataStaging .............................................................................................................................................. 11
Data Warehouse (DWH)............................................................................................................................ 11
Datenziel ................................................................................................................................................... 12
DB Connect .............................................................................................................................................. 12
Dimension ................................................................................................................................................ 12
Dimension-Identifikation (DIM-ID) ............................................................................................................ 12
Delta-Update ............................................................................................................................................. 12
E
Error-Handling .......................................................................................................................................... 13
ETL-Prozess ............................................................................................................................................. 13
Extraktstruktur ......................................................................................................................................... 13
Extraktor ................................................................................................................................................... 13
F
Flatfile ....................................................................................................................................................... 13
Fremdsystem ............................................................................................................................................ 14
Full-Update ............................................................................................................................................... 14

H
1

Hierarchie ................................................................................................................................................. 14

I
IDoc .......................................................................................................................................................... 15
InfoArea .................................................................................................................................................... 16
InfoCube ................................................................................................................................................... 16
InfoObject ................................................................................................................................................. 16
InfoObjectCatalog .................................................................................................................................... 17
InfoPackage .............................................................................................................................................. 17
InfoProvider .............................................................................................................................................. 17
InfoSet ...................................................................................................................................................... 17
InfoSource ................................................................................................................................................ 18

K
Kennzahl................................................................................................................................................... 18
Klammerung ............................................................................................................................................. 19
Kommunikationsstruktur ......................................................................................................................... 19
M
Merkmal .................................................................................................................................................... 20
Metadata Repository ................................................................................................................................ 20
Monitor ..................................................................................................................................................... 20
MultiProvider ............................................................................................................................................ 20
O
DSO-Objekt ............................................................................................................................................... 21
Online Analytical Processing (OLAP) ...................................................................................................... 22
Online Transaction Processing (OLTP) ................................................................................................... 22
P
PSA-Tabelle .............................................................................................................................................. 23
Prozesskette ............................................................................................................................................. 23
Q
Quellsystem.............................................................................................................................................. 23
Query ........................................................................................................................................................ 24
R
Referentielle Integritt .............................................................................................................................. 24
RFC (Remote Function Call)..................................................................................................................... 24

S
Service-API (SAPI).................................................................................................................................... 24
Surrogat-Identifikation (SID) .................................................................................................................... 24

T
Technischer Content (TCT) ...................................................................................................................... 25
2

Text ........................................................................................................................................................... 25
Transaktionaler BasisCube ...................................................................................................................... 25
Transferstruktur ....................................................................................................................................... 25
Transformationsreln................................................................................................................................. 14

bertragungsregel ................................................................................................................................... 25
bertragungsroutine ................................................................................................................................ 26

V
Virtueller Cube.......................................................................................................................................... 26

X
XML (Extensible Markup language) Integration .................................................................................... 26

Anhang
Abkrzungen ............................................................................................................................................ 27
Transaktionscodes................................................................................................................................... 28
Metadaten-Tabellen .................................................................................................................................. 30

Administrator Workbench (AWB)

3

Die AWB ist das zentrale Werkzeug zur Steuerung, berwachung und Pflege aller mit der Datenbeschaffung,
Datenverarbeitung sowie der Datenbereitstellung verbundenen Prozesse im BW. Die Aufgaben werden in den
folgenden Funktionsbereichen durchgefhrt:
Modellierung ( Transaktion: RSA1)
Dieser Funktionsbereich dient dem Anlegen und Pflegen der zum Datenbereitstellungs- bzw. Datenladeprozess
relevanten (Meta-)Objekte des BW.
Monitoring ( Transaktion: RSMON)
Das Monitoring ermglicht es, den Datenladeprozess sowie weitere Prozesse der Datenverarbeitung im BW zu
berwachen und zu steuern.
Reporting Agent ( Transaktion: RSA1
Drucktaste: Reporting Agent)
Der Reporting Agent ist ein Werkzeug, mit dem Reporting-Funktionen im Hintergrund ( Batch) eingeplant und
ausgefhrt werden, wie z.B. das Auswerten von Exceptions und Drucken von Queries
Transportanschluss ( Transaktion: RSA1
Drucktaste: Transportanschluss)
Mit dem Transportanschluss knnen neu angelegte bzw. genderte BW-Objekte gesammelt und mit Hilfe des
Change and Transport Organizer (CTO) in andere BW-Systeme transportiert werden.
Dokumente ( Transaktion: RSA1
Drucktaste: Dokumente)
Dieser Funktionsbereich ermglicht es, ein oder mehrere Dokumente in verschiedenen Formaten,
Versionen und Sprachen hinzuzufgen, zu verlinken und zu durchsuchen.
Business Content ( Transaktion: RSORBCT)
Der Business Content bietet auf konsistente Metadaten basierend u.a. vorkonfigurierte rollen- und aufgabenbezogene Informationsmodelle ( siehe Business Content).
bersetzung
Transaktion: RSA1
Drucktaste: bersetzung)
In diesem Funktionsbereich knnen Kurz- und Langtexte von BW-Objekten bersetzt werden.
Metadata Repository ( Transaktion: RSOR)
Mit dem HTML-basierten BW Metadata Repository werden zentral alle BW Meta-Objekte und deren
Verknpfungen zueinander verwaltet, wodurch ein konsistentes und homogenes Datenmodell ber alle
Quellsysteme ermglicht wird ( siehe Metadata Repository).
Aggregat
Ein Aggregat speichert den Datenbestand eines BasisCube in verdichteter Form redundant und persistent auf der
Datenbank. Da Aggregate die gleiche Speicherform (Fakten-/Dimensionstabellen) wie BasisCubes haben, werden
diese auch hufig als Aggregat Cubes bezeichnet. Aggregate werden zur Verbesserung der Query-Performance
verwendet, d.h. es wird ein schnellerer Zugriff auf die Daten eines BasisCubes im Reporting ermglicht. Da ein
BasisCube mehrere Aggregate besitzen kann, greift der Optimizer des OLAP-Prozessors beim Ausfhren einer
Query automatisch auf das jeweils am besten geeignete Aggregat zu. D.h. die Entscheidung, ob fr das Reporting
ein BasisCube oder ein Aggregat verwendet wird, ist fr den Endanwender nicht transparent. Informationen zu
Aggregaten, wie technische Eigenschaften sowie inhaltliche und Status-Eigenschaften sind in der Tabelle
RSDDAGGRDIR abgelegt.
Pflege von Aggregaten im BW-System:
1. Transaktion: RSDDV
2. Einstieg: AWB Modellierung InfoProvider InfoArea whlen
Im Kontextmen des gewhlten BasisCube Aggregate pflegen whlen
Beim Aufbau eines Aggregates aus Merkmalen und Navigationsattributen eines BasisCube knnen die Daten
nach verschiedenen Aggregationsstufen gruppiert werden:
Alle Merkmalswerte ( * )
Die Daten werden nach allen Werten, der fr die Aggregatsdefinition kombinierten Merkmale bzw.
Navigationsattribute gruppiert.
Hierarchielevel ( H )
Die Daten werden nach den Knoten eines Hierarchielevels gruppiert.
4

Festwert ( F )
Die Daten werden nach einem Einzelwert eines Merkmals bzw. Navigationsattribut gefiltert und gruppiert.
In Hinblick auf das Laden von Daten in Aggregate eines BasisCube unterscheidet man zwischen Aktivieren/Fllen
und Hochrollen:
Aktivieren und Fllen
Mit dieser Funktion wird das erstmalige Laden von Daten in Aggregate ermglicht. Die aktiven und gefllte
Aggregate sind dann fr das Reporting verfgbar.
Roll-Up (Hochrollen)
Unter dem Roll-Up versteht man das Laden von Requests eines BasisCubes, die in den zugehrigen
Aggregaten noch nicht vorhanden sind, in alle Aggregate dieses BasisCubes. Ein Rolll-Up ist erforderlich,
sobald sich die BasisCube-Daten gendert haben, um Datenkonsistenz zwischen Aggregate und BasisCube
zu gewhrleisten. Nach dem Roll-Up werden die neuen Daten beim Ausfhren einer Query verwendet.
Roll-Up Hierarchie (Aggregatshierarchie)
In der Roll-Up-Hierarchie wird die Abhngigkeit von Aggregaten zum BasisCube und zueinander im bezug
auf das Roll-Up angezeigt, d.h. ob beim Roll-Up ein Aggregat ber ein bergeordnetes Aggregat oder direkt
ber den BasisCube gefllt wird. Mit Hilfe der Roll-Up-Hierarchie knnen hnliche Aggregate identifiziert,
und auf dieser Grundlage die Aggregate manuell gezielt optimiert werden.
Weitere Funktionalitten:
Ein-/Ausschalten
Wird ein Aggregat temporr ausgeschaltet, so wird beim Ausfhren einer Query dieses Aggregat nicht
verwendet. Beim erneuten Einschalten des Aggregats muss dieses nicht nochmals aktiviert und gefllt werden.
Damit hat man die Mglichkeit, die Laufzeiten der Queries mit bzw. ohne dieses Aggregat zu vergleichen,
um zu prfen, ob die Verwendung dieses Aggregats sinnvoll ist.
Deaktivieren
Deaktivieren eines Aggregates bedeutet, dass alle Daten des Aggregats gelscht werden, jedoch die Struktur
des Aggregats erhalten bleibt.
Lschen
Beim Lschen wird das Aggregat deaktiviert und zustzlich auch die Struktur des Aggregats gelscht.
Komprimieren
Die Komprimierung von Aggregaten entspricht der Komprimierung von BasisCubes.
D.h. komprimierte Requests knnen nicht mehr aus dem Aggregat gelscht werden. Es ist aber mglich,
die Komprimierung nach dem Roll-Up auszuschalten, so dass die Aggregate Request-erhaltend sind.
Hierarchie-/Attributsnderungslauf ( Change Run)
Wenn sich Hierarchien und Navigationsattribute von Merkmalen, die in Aggregaten verwendet werden,
gendert haben, werden Strukturnderungen in den Aggregaten ntig, um die Daten entsprechend
anzupassen. Bei einer Strukturnderung werden smtliche von den nderungen an Hierarchien und
Navigationsattribute betroffenen Aggregate aller BasisCubes angepasst:
Einstieg: AWB Werkzeuge Hierarchie/Attributs-nderungen fr das Reporting ausfhren
Mit Hilfe des ABAP-Programmes RSDDS_CHANGE RUN_MONITOR ist es mglich zur Laufzeit des Change
Run die anzupassenden Attribute, Hierarchien und Aggregate zu ermitteln. Stammdatennderungen sind erst
wirksam, wenn ein Change Run fr diese Stammdaten durchgefhrt wurde. Ab einer bestimmten Grenordnung der nderung wird das Modifizieren des Aggregates aufwendiger als ein
Neuaufbau. Diesen Schwellwert kann man selbst festlegen:
1. Transaktion: RSCUSTV8
2. BW Customizing Einfhrungsleitfaden Business Information Warehouse
Allgemeine BW Einstellungen Parameter fr Aggregate

ALE (Application Link Enabling)

ALE untersttzt die Konfiguration und den Betrieb von verteilten Anwendungssystemen (zwischen SAP-Systemen
einerseits und SAP-Systemen und Fremdsystemen andererseits). Fr die Kommunikation (Datenaustausch)
zwischen verteilten Anwendungssystemen stellt ALE bestimmte Services und Tools zur Verfgung, wie z.B.
Konsistenzprfungen, Monitoring der Datenbertragung, Fehlerbehandlung und synchrone/asynchrone
Verbindungen. Dadurch ist eine ein kontrollierter Datenaustausch zwischen den verteilten Anwendungssystemen
bei konsistenter Datenhaltung gewhrleistet
Anwendungskomponentenhierarchie
SAP-Quellsystem:
Die Anwendungskomponentenhierarchie ist Bestandteil des SAP-Quellsystems Business Content, welcher
mit dem Plug-In eingespielt wird. Sie kann kann aber auch manuell gepflegt werden. Sie dient der Organisation
der DataSources.
Anwendungskomponentenhierarchie ndern:
1. Transaktion: RSA8
2.. Transaktion: SBIW Nachbereitung von DataSources Anwendungskomponentenhierarchie ndern
Im BW-System:
Die Anwendungskomponentenhierarchie ist ebenfalls Bestandteil des BW Business Content; sie kann auch
hier manuell gepflegt werden. Hier dient sie der Organisation von InfoSources im InfoSource-Baum und PSATabellen im PSA-Baum.
Archivierung
Die Datenarchivierung ermglicht es, Daten aus BasisCubes und DSO-Objekten (Tabelle mit den aktiven Daten) zu
archivieren, d.h. als flache Struktur in einem Datei-System abzulegen und aus dem BasisCube bzw. DSO-Objekt zu
lschen. Die Archivierung von Daten dient unter anderem dazu,
das Datenvolumen zu verkleinern und somit Speicherplatz einzusparen.
aufgrund des geringeren Datenvolumens die Performance, wie z.B. bei Analysen,
bei der Fortschreibung, beim Roll-Up und Change Run zu verbessern.
die gesetzlichen Vorgaben zur Aufbewahrung von Daten einhalten zu knnen
ADK (Archiving Development Kit)
Zur Archivierung wird das Werkzeug ADK der mySAP Technology Basis eingesetzt. Das ADK stellt die
Laufzeitumgebung fr die Archivierung bereit. Es dient hauptschlich zum Schreiben und Lesen von Daten
in und aus Archivdateien. Das ADK gewhrleistet die Plattform- und Release-Unabhngigkeit fr die
archivierten Daten.
Archivierungsprozess
Der Archivierungsprozess im BW besteht aus den folgenden Teilprozessen:
Schreiben der Daten in die Archive (Transaktion: SARA )
Lschen der archivierten Daten aus dem BasisCube/DSO-Objekt (Transaktion: SARA )
Werden archivierte Daten aus einem BasisCube gelscht, so werden diese Daten auch aus den zum
BasisCube gehrigen Aggregaten gelscht. Werden Daten aus einem DSO-Objekt gelscht, so bleiben
Datenziele, die mit den Daten aus diesem DSO-Objekt versorgt wurden, von der Archivierung unberhrt.
Wiederherstellen archivierter Daten im BW-System
Das Wiederherstellen archivierter Daten erfolgt ber die Export-DataSource des BasisCube bzw. des
DSO-Objektes, aus dem die Daten archiviert wurden. Das ADK stellt dabei die Funktionen fr das Lesen
der Archivdateien zur Verfgung. Die weitere Fortschreibung erfolgt dann ber die bekannten Datenladeprozesse im BW-System.

Archivierungsobjekte
6

Voraussetzung fr jede Archivierung sind sogenannte Archivierungsobjekte, die betriebswirtschaftlich

zusammengehrige Daten durch eine Datenstruktur beschreiben und mit denen das Lesen, Schreiben und
Lschen im Rahmen des Archivierungsprozess definiert und durchgefhrt. Sie sind das Bindeglied zwischen
dem ADK und den BW-Objekten.
Das Anlegen eines Archivierungsobjektes erfolgt ber:
Einstieg: AWB Modellierung InfoProvider InfoArea whlen
Im Kontextmen des gewhlten BasisCube/DSO-Objekts ndern whlen Zustze Archivierung

Attribut
Attribute sind InfoObjects (Merkmal/Kennzahl), die zur nheren Beschreibung von Merkmalen verwendet werden.
Beispiel:
Merkmal:
Kostenstelle
Attribute:
'Kostenstellenverantwortlicher' (Merkmal als Attribut),
'Gre der Kostenstelle in Quadratmeter' (Kennzahl als ausschlieliches Attribut)
In der InfoObject-Pflege zu einem Merkmal hat man die Mglichkeit, dem Merkmal Attribute mit Attributseigenschaften mitzugeben:
Anzeige
Attribute mit dieser Eigenschaft knnen nur als zustzliche Information in Kombination zum Merkmal im
Reporting verwendet werden, d.h. es ist keine Navigation in Queries mglich. Ein Sonderfall bei der Definition
von InfoObjects ist die Option, InfoObjects (Merkmale bzw. Kennzahlen) als ausschlieliches Attribute zu
definieren, d.h. diese Attribute knnen nicht als Navigationsattribut definiert werden, sondern nur als Anzeigeattribut genutzt werden.
Navigation
Attribute vom InfoObject-Typ Merkmal knnen als Navigationsattribute definiert werden. Derartige Attribute
knnen zur Navigation analog zu (Dimensions-) Merkmalen in Queries verwendet werden, d.h. alle
Navigationsfunktionen von (Dimensions-) Merkmalen in Queries gelten auch fr Navigationsattribute. Im Gegensatz zu (Dimensions-) Merkmalen sind mit Navigationsattributen aktuelle und stichtagsbezogene Datensichten
auf Query-Ebene mglich ( .Tracking History). Damit diese Attribute als Navigationsattribute im Reporting
verfgbar sind, mssen diese auf Datenziel-Ebene zustzlich eingeschaltet werden. Ein Merkmal, welches als
Navigationsattribut genutzt wird, kann selbst ber Navigationsattribute verfgen, sogenannte transitive
Attribute ( zweistufige Navigationsattribute). Diese knnen ebenfalls eingeschaltet werden und somit zur
Navigation in Queries zur Verfgung stehen.
Zeitabhngigkeit
Sowohl Anzeige- als auch Navigationsattribute knnen als zeitabhngige Attribute gekennzeichnet werden,
falls fr jede Attributsausprgung ein Gltigkeitsbereich bentigt wird.
BAPI (Business Application Programming Interface)
BAPIs sind offene, standardisierte Schnittstellen, die auf Anwendungsebene definiert werden.
Transaktion: BAPI
Diese von der SAP bereitgestellten Schnittstellen ermglichen die Kommunikation zwischen SAP-Systemen
und Anwendungen, die von Drittherstellern entwickelt wurden. Aus technischer Sicht ist der Aufruf eines BAPI
der Aufruf eines Funktionsbausteins ber RFC oder tRFC.
Staging BAPI
ber Staging BAPIs knnen Daten (Meta-, Stamm- und Bewegungsdaten) aus Fremdsystemen in das
BW-System bertragen werden.

BasisCube
Ein BasisCube ist ein InfoCube, der einen in sich geschlossenen, themenbezogenen abgespeicherten Datenbestand darstellt, auf den Queries definiert werden knnen. Er wird ber eine oder mehrere InfoSources via
Fortschreibungsregeln mit analyserelevanten Bewegungsdaten versorgt. Er ist der fr die multidimensionale
Modellierung relevante InfoCube, da fr das BW-Datenmodell nur Objekte bercksichtigt werden, die Daten
beinhalten. Aus technischer Sicht ist ein BasisCube eine Menge von relationalen Tabellen, die multidimensional
(mittels Sternschema) zusammengestellt sind:
Faktentabellen
Ein BasisCube besteht aus zwei Faktentabellen, in der die Kennzahlen abgelegt werden.
F- Tabelle: normale Faktentabelle ( bzgl. der Request-ID partitioniert)
E-Tabelle: komprimierte Faktentabelle ( F-Tabelle ohne Request-ID)
Dabei knnen maximal 233 Kennzahlen abgespeichert werden.
Die Nutzung der E-Tabelle ist optional (siehe unten Komprimierung).
Dimensionstabellen
Ein BasisCube besteht maximal aus 16 Dimensionstabellen. Davon werden die Zeitdimensions- und
Datenpaketdimensionstabelle vom System automatisch generiert. Die Einheitendimensionstabelle wird nur
dann vom System generiert, wenn mindestens eine Kennzahl vom Typ Betrag oder Menge ist. In diesem
Fall muss nmlich der Kennzahl eine fixe oder variable Whrung/Einheit mit gegeben werden ( siehe
Kennzahlen).
SID-Tabellen/Stammdatentabellen
Die Relation zwischen den Stammdatentabellen zu einem Merkmal-InfoObject und den Dimensionstabellen
wird mit Hilfe systemgenerierter INT4-Schlssel, der sogenannten SIDs (Surrogat Identifications), der jeweiligen
Merkmal-InfoObjects hergestellt. In den Dimensionstabellen werden ausschlielich SIDs der jeweiligen
Merkmal-InfoObjects, niemals Merkmalsausprgungen abgelegt. Dabei knnen maximal 248 SIDs der
jeweiligen Merkmal-InfoObjects in einer Dimensionstabelle stehen. Die Relation zwischen einer Faktentabelle
und den zugehrigen Dimensionstabellen wird mit Hilfe knstlicher systemgenerieter INT4-Schlssel, der
sogenannten DIM-IDs (Dimension-Identifikationen) realisiert.
1. Anlegen von BasisCubes:
Einstieg: AWB
Modellierung InfoProvider
InfoArea whlen
Im Kontextmen der gewhlten InfoArea InfoCube anlegen und den Typ BasisCube whlen
2. Pflege von BasisCubes
Transaktion: RSDCUBE
BasisCubes administrieren:
Selektives Lschen ( Registerkarte Inhalt)
Mit dieser Funktion knnen durch eine vorherige Selektion gezielt Datenstze, die diesen Selektionskriterien
entsprechen, aus dem BasisCube gelscht werden. Wird das selektive Lschen verwendet, um fehlerhafte
Datenstze aus dem BasisCube zu lschen, so kann man die richtigen bzw. korrigierten Datenstze mit Hilfe
eines Reparatur-Request im Scheduler
Scheduler InfoPackage pflegen) wieder einbuchen.
Indizes prfen/lschen/reparieren ( Registerkarte Performance)
Fr jede DIM-ID ist ein Index auf der Faktentabelle von BasisCubes angelegt. Diese Indizes sind notwendig,
um ein optimales Auffinden/Selektieren der Daten zu gewhrleisten. Allerdings mssen diese Indizes bei
Schreibzugriffen durch das Datenbanksystem angepasst werden, was zu wesentlichen Einbuen der
Performance fhren kann. Mit der Funktion Indizes lschen besteht bei der Fortschreibung in BasisCubes
daher die Mglichkeit, die Schreibzugriffe zu beschleunigen. Nach Beendigung der Fortschreibung mssen
die Indizes mit der Funktion Indizes reparieren wieder aufgebaut werden. Mit der Funktion Indizes prfen
kann festgestellt werden, ob Indizes gelscht ( rote Ampel), aufgebaut ( gelbe Ampel) oder aktiv sind
grne Ampel).
Requests lschen ( Registerkarte Requests)
Mit dieser Funktion hat man die Mglichkeit gezielt Requests zu lschen, die in den BasisCubes geladen
wurden (falls diese noch nicht in Aggregate hochgerollt wurden).

Requests neu aufbauen ( Registerkarte Neuaufbau)

Mit dieser Funktion knnen bereits gelschte Requests zu einem BasisCube wiederhergestellt
werden. Des Weiteren knnen diese Requests auch fr andere BasisCubes verwendet werden.
Diese Funktion ist nur mglich, falls die Requests in den PSA-Tabellen gehalten werden.
Requests hochrollen ( Registerkarte Roll-Up)
siehe Aggregate Roll-Up)
Komprimieren ( Registerkarte Komprimieren)
Jeder BasisCube besitzt, vom System vorgegeben, eine Datenpaketdimensionstabelle in der die SID
zum technischen Merkmal 0REQUID (Request-ID) abgelegt ist. Diese Dimensionstabelle wird beim jedem
Ladevorgang automatisch gefllt. Folglich werden in der Faktentabelle Daten mit einem hheren Detaillierungsgrad abgelegt, was aus betriebswirtschaftlicher Sicht nicht erforderlich ist. Je nach Modellierung des
BasisCube, Hufigkeit der Ladevorgnge und Zusammensetzung der geladenen Daten kann sich diese
Detaillierung erheblich auf das Datenvolumen des BasisCube auswirken. Mit dem Verschwinden der RequestID ( wird auf Null gesetzt) kann das Datenvolumen um ein Vielfaches verringert werden, ohne Nachteile aus
betriebswirtschaftlicher Sicht in Kauf zu nehmen. Um diese Verringerung zu erreichen, besteht jeder BasisCube
aus zwei Faktentabellen:
F-Tabelle: normale Faktentabelle
E-Tabelle: komprimierte Faktentabelle (= F-Tabelle ohne Request-ID)
Mit der Funktion Komprimieren wird die E-Tabelle mit Daten aus der F-Tabelle gefllt. Dabei kann die gesamte
F-Tabelle komprimiert oder nur ein lterer Teil der Requests komprimiert werden. Neue Requests werden in die
F-Tabelle geschrieben und knnen anschlieend komprimiert werden. Analog verhlt es sich mit der Komprimierung bei Aggregaten. Nachteil der Komprimierung ist, dass sie nicht rckgngig gemacht werden kann!
Business Content (BCT)

Ein wesentlicher Vorteil des BW gegenber anderen Data Warehouse Lsungen ist der von der SAP mit dem BW
ausgelieferte BCT, der permanent weiterentwickelt wird. Dabei handelt es sich um umfassend vordefinierte
Informationsmodelle fr die Analyse von Geschftsprozessen.
Darin enthalten ist die gesamte Definition aller erforderlichen BW-Objekte, wie z.B.: InfoAreas, InfoObjectCatalogs,
Rollen, Arbeitsmappen, Query-Elemente, InfoCubes, InfoObjects, DSO-Objekte, Fortschreibungsregeln,
InfoSources, bertragungsregeln, Whrungsumrechnungsarten, Extrakoren, DataSources. Demnach werden zwei
Bereiche des BCT unterschieden:
BCT fr die Quellsysteme (z.B. Anwendungskomponentenhierarchie, DataSources)
BCT fr das BW-System
Der BCT fr SAP-Quellsysteme (fr R/3-Systeme: Release 3.1 I) wird ber Plug-Ins eingespielt.
Falls BW-Systeme als Quellsysteme an andere BW-Systeme angeschlossen, ist das Einspielen von Plug-Ins nicht
erforderlich.
Bevor Bestandteile des BCT genutzt werden knnen, mssen diese explizit bernommen bzw.
aktiviert werden. Dies geschieht im Quellsystem ber die Transaktion: SBIW und im BW-System ber die
Transaktion: RSORBCT.
Objekt-Versionen
Alle BW-Objekte werden zunchst in der D(elivered)-Version mit dem BCT ausgeliefert. Durch die bernahme
dieser Objekte aus dem BCT wird eine A(ctive)-Version angelegt, dabei bleibt die D-Version erhalten. Werden
diese aktivierten Objekte verndert, so wird eine neue M(odified)-Version generiert. Diese kann aktiviert
werden und berschreibt dann die ltere aktive Version. Die nderung von BW-Objekten, die aus dem BCT
bernommen sind, werden bei einer erneuten bernahme einer neueren Content-Version nicht berschrieben.

Business Explorer (BEx)

Der BEx ist ein Werkzeug, um zentral gespeicherte Daten, die aus verschiedenen Quellen stammen knnen,
auszuwerten. Der BEx beinhaltet folgende Komponenten:
BEx Analyzer (Transaktion: RRMX)
Analyse- und Reportingwerkzeug des BEx, das als Add-In fr Microsoft Excel implementiert ist und damit auf
die komplette Excel-Funktionalitt zurckgreift. Der BEx Analyzer wird verwendet:
zur Erstellung und nderung von Berichten
fr Auswertungen von und Navigation innerhalb von Berichten
zum Aufrufen und Speichern von Berichten in Rollen bzw. persnlichen Favoriten
zur Publikation von Berichten fr das Web-Reporting
BEx Browser
Werkzeug zum Organisieren und Verwalten von Arbeitsmappen und Dokumenten.
Mit dem BEx Browser kann man auf alle Dokumente des BW zugegriffen werden, die seiner Rolle zugeordnet
sind und die man in seinen Favoriten abgelegt hat. Im BEx Browser kann mit folgenden Dokumenttypen
gearbeitet werden:
BW Arbeitsmappen
Dokumente, die im Business Document Service (BDS) abgelegt sind
Verknpfungen (Referenzen auf das Dateisystem, Shortcuts)
Links auf Internetseiten (URLs)
SAP Transaktionsaufrufe
Web Applications und Web Templates
Formatiertes Reporting
Mit Hilfe des formatierten Reporting ist es mglich, die Daten nicht nur fr die interaktive Analyse bereitzustellen, sondern auch in formatierte Drucklayouts aufzubereiten. Das formatierte Reporting basiert auf den
im BEx Analyzer definierten Queries. Hinter dem formatierten Reporting stehen die Crystal Reports von CrystalDecission, die im BW integriert sind.
BEx Web Application Designer
Mit dem BEx Web Application Designer hat man die Mglichkeit, Queries und HTML-Dokumente ins Intranet
oder Internet zu stellen.
Cleansing/Homogenisierung
Mit Hilfe von sogenannten bertragungsregeln knnen im BW die Daten aus den Quellsystemen vor der
Verbuchung im bezug auf die Datenstruktur und Semantik homogenisiert bzw. harmonisiert werden. Dabei knnen
Fehlinformationen herausgefiltert bzw. bereinigt oder korrigiert werden.

Datengranularitt
Mit der Datengranularitt wird der Detaillierungsgrad von Daten beschrieben. Sehr detaillierte Daten haben eine
niedrige Granularitt; mit wachsender Verdichtung (= Aggregation) der Daten wird eine hohe Granularitt erreicht.
Die Granularitt wirkt sich u.a. auf den Speicherplatz, Informationsgehalt sowie der Leseperformance aus. Im BW
werden fr das Reporting detaillierte Daten in DSO-Objekten und aggregierte Daten in BasisCubes bzw. Aggregate
abgespeichert.
Data Dictionary (DDIC)
Das (ABAP) Data Dictionary ermglicht eine zentrale Beschreibung und Verwaltung aller im System verwendeten
Datendefinitionen. Das DDIC ist vollstndig in die ABAP Workbench integriert. Das DDIC untersttzt die Definition
benutzerdefinierter Typen (Datenelemente, Strukturen und Tabellentypen). Im DDIC kann auch die Struktur von
Objekten der Datenbank (Tabellen, Indizes und Views) definiert werden. Diese Objekte knnen dann mit dieser
Definition automatisch auf der Datenbank erzeugt werden.
Transaktion: SE11
10

Data Mart Interface

Die Data Mart Schnittstelle ermglicht die Fortschreibung von Daten aus einem Datenziel in ein weiteres Datenziel.
Diese Art der Fortschreibung kann zum einen innerhalb eines BW-Systems, d.h. das BW ist als Quellsystem an
sich selbst angeschlossen (Myself Data Mart) und zum anderen zwischen mehreren BW-Systemen realisiert
werden. Beim Einsatz von mehreren BW-Systemen wird das datenliefernde System als Quell-BW, das Daten
empfangende System als Ziel-BW bezeichnet. Die einzelnen BWs einer derartigen Anordnung werden als Data
Marts bezeichnet. Fr die Datenbertragung aus einem Datenziel in ein weiteres Datenziel ist eine sogenannte
Export-DataSource erforderlich, die aus der Struktur des Quell-Datenziels abgeleitet wird. Ist das Quell-Datenziel
ein DSO-Objekt, so wird im Gegensatz zum BasisCube beim Aktivieren eines neu angelegten DSO-Objektes die
Export-DataSource automatisch generiert.
DataSource
Eine DataSource beschreibt jeweils eine betriebliche Einheit von Stammdaten (z.B. Materialstammdaten) sowie
Bewegungsdaten (z.B. Vertriebsdaten). Aus Sicht der Quellsysteme gehren zu jeder DataSource MetaInformationen wie z.B. die Felder/Feldbeschreibungen zu den Stamm- und Bewegungsdaten und Programme, die
beschreiben, wie die Extraktion durchgefhrt wird. Diese Informationen sind Quellsystem-spezifisch, d.h. eine
DataSource ist Quellsystem-abhngig. Diese DataSource-Informationen bzw. -Eigenschaften werden im SAPQuellsystem in den Tabellen ROOSOURCE und RODELTAM. und im BW-System in der Tabelle RSOLTPSOURCE.
abgelegt. Aus technischer Sicht unterscheidet man bei einer DataSource zwei Arten von Feldstrukturen:
Extraktstruktur
Transferstruktur
Man unterscheidet die folgenden Typen von DataSources:
DataSources fr Bewegungsdaten
DataSources fr Stammdaten-Attribute
DataSources fr Stammdaten-Texte
DataSources fr Stammdaten-Hierarchien
Mit der Definition sogenannter generischer DataSources hat man die Mglichkeit, Daten aus beliebigen DDICTabellen/Views, SAP Queries/InfoSets oder Funktionsbausteinen aus SAP-Quellsystemen zu extrahieren. Damit
knnen auch Daten aus SAP-Quellsystemen extrahiert werden, die nicht durch BCT-DataSources extrahiert werden
Transaktion: RSO2 ). Die Extraktion von Daten fr externe Hierarchien ist mit generischen DataSources nicht
mglich!
Data Staging
Aufbereitungsprozesse fr die Datenbereitstellung im BW
Data Warehouse (DWH)
Unter einem DWH versteht man ein System, in dem die entscheidungsrelevanten Daten themen- orientiert,
integriert, nicht flchtig und zeitbezogen gespeichert werden. Die Aufgabe eines DWH besteht darin, Daten aus
unterschiedlichen firmeninternen und externen Quellen zu bereinigen, zu konsolidieren und den Zugriff mittels
OLAP-Tools bereitzustellen. Dabei ist die Integration von OLAP-Tools in einem DWH-System nicht zwingend.
Allerdings bieten Hersteller in der heutigen Zeit immer mehr DWH-Systeme mit integrierten OLAP-Tools an.
Solche DWH-Systeme werden auch hufig OLAP-System oder DWH-Lsungen bezeichnet. Demnach ist das SAP
BW eine DWH-Lsung.

11

Datenziel
Ein Datenziel ist ein BW-Objekt, in das Daten geladen werden knnen (= physisches Objekt). Datenziele sind die
Objekte, die bei der Modellierung des BW-Datenmodells relevant bzw. bercksichtigt werden. Datenziele knnen
sein:
BasisCubes
DSO-Objekte
Merkmal-InfoObjects
DB Connect
Mit DB Connect wird ein direkter Zugriff auf (externen) relationalen Datenbanken ermglicht. Dazu wird ber das
SAP DB MultiConnect eine Verbindung zum Datenbankmanagesystem (DBMS) der externen Datenbank hergestellt. ber das Einlesen von Metadaten sowie den orginren Daten knnen auf sehr einfache Weise die notwendigen Strukturen im BW generiert und die Daten geladen werden. Voraussetzung dafr ist, dass es sich dabei um
ein von der SAP untersttztes DBMS handelt. Diese Daten knnen dann ber DataSources dem BW-System
bekannt gemacht und extrahiert werden. Untersttzte DBMS sind:
SAP DB
Informix
Microsoft SQL Server
Oracle
IBM DB2 390//400/UDB
Des Weiteren muss der SAP spezifische Teil der Datenbankschnittstelle Database Shared Library (DBSL) fr das
jeweilige Quell-DBMS auf dem BW-Applikationsserver installiert werden.

Dimension
Unter einer Dimension (= Perspektive) versteht man die Gruppierung logisch zusammengehriger Merkmale unter
einem gemeinsamen Oberbegriff. Dabei knnen innerhalb einer Dimension maximal 248 Merkmale zusammengefasst werden. Aus technischer Sicht besteht eine Dimension eines BasisCube aus einer Dimensionstabelle
(falls keine Line Item Dimension) sowie SID- und Stammdatentabellen.
Line Item Dimernsion
Merkmale knnen als Line Items definiert werden, d.h. neben diesem Merkmal knnen keine weiteren
Merkmale einer Dimension zugeordnet werden. Eine solche Dimension bezeichnet man als Line Item
Dimension (= degenerierte Dimension). Im Gegensatz zu einer gewhnlichen Dimension enthlt die Line Item
Dimension keine Dimensionstabelle. Hier ist die SID-Tabelle des Line Items ber eine Fremd-/Primrschlssel
beziehung direkt mit der Faktentabelle verbunden. Diese Mglichkeit wird genutzt, falls ein Merkmal, wie z.B.
die Auftragsnummer, sehr viele Werte besitzt. Dadurch kann die Query-Performance verbessert werden.
Dimension-Identifikation (DIM-ID)
Die Relation zwischen einer Faktentabelle und ihren Dimensionstabellen eines BasisCubes wird mit Hilfe systemgenerierter INT4-Schlssel, der sogenannten DIM-IDs, umgesetzt. Beim Laden von Bewegungsdaten in den
BasisCube werden die DIM-ID-Werte eindeutig vergeben, dabei wird jedem DIM-ID-Wert eindeutig eine
Kombination von SID-Werten der unterschiedlichen Merkmale zugeordnet.

Delta-Update
Ein Delta-Update fordert jeweils nur die Daten an, die seit dem letzten Update angefallen sind und fllt mit
diesen Daten die entsprechenden Datenziele. Bevor man ein Delta-Update anfordern kann, muss man erst
die Initialisierung des Delta-Verfahrens durchfhren. Ein Delta-Update ist DataSource-abhngig!
Diese Eigenschaft einer DataSource sind in den Tabellen ROOSOURCE und RODELTAM im SAP-Quellsystem
bzw. in der Tabelle RSOLTPSOURCE im BW-System abgelegt.
12

Error-Handling
Mit Hilfe der Funktion Fehlerbehandlung auf der Registerkarte Fortschreibungsparameter im InfoPackage des
Schedulers hat man beim Laden von Daten ber die PSA die Mglichkeit, das Verhalten des BW-Systems beim
Auftreten fehlerhafter Datenstze zu steuern. Dabei stehen die folgenden Optionen zur Verfgung:
Keine Verbuchung, kein Reporting (Default)
Verbuchung gltiger Stze, kein Reporting (Request rot)
Verbuchung gltiger Stze, Reporting mglich (Request grn)
Ferner kann festgelegt werden:
nach wie viel fehlerhaften Stzen der Ladeprozess abgebrochen wird. Falls hierzu keine Eintragung gemacht
wird, wird der Ladeprozess beim ersten Fehler abgebrochen.
der Request wird als fehlerhaft gewertet, falls die Anzahl der empfangenen Stze nicht mit
der Anzahl der verbuchten Stze bereinstimmt (Kennzeichen: Keine Aggregation erlaubt)
ETL-Prozess
Ein ETL-Prozess setzt sich aus den folgenden Teilprozessen zusammen:
Extraktion von Daten aus einem Quellsystem
Transformation der Daten
Laden der Daten in das BW-System
Extraktstruktur
Die Extraktstruktur enthlt smtliche Felder des SAP-Quellsystems, die von sogenannten Extraktoren im
Quellsystem fr den Datenladeprozess bereitgestellt werden. Extraktstrukturen von DataSources knnen im
Quellsystem definiert, bearbeiten und erweitert werden.
Transaktion im Quellsystem: SBIW
Extraktor
Ein Extraktor ist ein Programm fr die:
Bereitstellung von Metadaten aus einem SAP-Quellsystem ber die Extraktstruktur einer DataSource
Verarbeitung von Datenanforderungen
Durchfhrung der Extraktion
Diese Extraktoren werden mit den DataSources in Form eines Plug-Ins in die SAP-Quellsysteme eingespielt.

Flatfile
Die Daten knnen ber eine Dateischnittstelle in das BW eingespielt werden. Als Quelldateien fr das BW werden
die folgenden zwei Dateiformate untersttzt:
ASCII (American Standard Code for Information Interchange) Dateien mit fixer Feldlnge
CSV (Colon Separated Variables) Dateien mit variabler Lnge, wobei die Trennzeichen
(= Separator) benutzerdefiniert festgelegt werden knnen (Transaktion: RSCUSTV1 ).
Durch die Verwendung von Flatfiles (flache Dateien) knnen Schnittstellenproblematiken reduziert werden,
hingegen mssen die Metadaten manuell im BW gepflegt werden.

13

Transformationssregel
ber die Transformationsregeln gelangen die Stamm- und Bewegungsdaten nach einer definierten Logik in die
Datenziele (BasisCubes, DSO-Objekte, Merkmal-InfoObjects mit Attributen oder Texten).
Demnach sind Transformationsregeln im Gegensatz zu bertragungsregeln nicht Quellsystem-spezifisch, sondern
Datenziel-spezifisch. Jedoch knnen Transformationsregeln eines Datenziels fr ein weiteres Datenziel kopiert
werden. Mit Hilfe dieser Regeln knnen die Datenziele ber eine oder mehrere DataSources und/oder Info Sources
versorgt werden. Sie dienen der Verbuchung der Daten in die Datenziele sowie der Modifikation und Anreicherung
der Daten.
Definition von Transformationssregeln:
Einstieg: AWB Modellierung InfoProvider
InfoArea whlen
Im Kontextmen des gewhlten Datenziels Transformationsregeln anlegen whlen
Beispiele fr Transformationsregeln sind:
Nachlesen von Stammdaten-Attribute
Felder im Datenziel mit einer Konstante fllen
Felder im Datenziel ber eine Routine (ABAP-Coding) bzw.ber eine Formel (Transformationsbibliothek)
versorgen
Whrungsumrechnung
Rckgabetabelle ( Splitting von Kennzahlen)
Bei der Fortschreibung jeder Kennzahl muss zwischen den folgenden Fortschreibungsarten ausgewhlt werden:
-

Addition / Maximum / Minimum

Das Standard-Aggregationsverhalten einer Kennzahl wird in der Kennzahl-Pflege festgelegt und in der Pflege
der Fortschreibungsregeln zu dieser Kennzahl entweder als Addition, Maximum oder Minimum angeboten.
Speziell die Addition ist auch fr Datenfelder von DSO-Objekten mglich, falls diese vom numerischen Datentyp sind. Diese Forschreibungsart gilt nicht fr Merkmal-InfoObjects als Datenziel.
berschreiben
Diese Fortschreibungsart ist nicht fr BasisCubes, sondern nur fr DSO-Objekte und Merkmal- InfoObjects
mglich.
Keine Fortschreibung
Wird diese Fortschreibungsart gewhlt, so wird fr die betreffende Kennzahl kein Wert berechnet. Ebenso wird
die Berechnung der zugehrigen Merkmale/Schlsselfelder nicht durchgefhrt.

Fremdsystem
Fremdsysteme sind Nicht-SAP-Systeme (inklusive R/2-System, R/3-Systeme Release < 3.1i), die Metadaten und
Daten fr das BW bereitstellen und damit dem BW als Quellsystem dienen. Die Extraktion, Transformation und das
Laden dieser Daten kann ber Staging BAPIs mit Hilfe von Third Party Extraction-Tools umgesetzt werden.
Full-Update
Ein Full-Update fordert alle Daten an, die den im Scheduler InfoPackage festgelegten Selektionskriterien
entsprechen. Im Gegensatz zum Delta-Update untersttzt jede DataSource ein Full-Update.
Hierarchie
Unter dem Begriff Hierarchie wird gewhnlich eine Anordnung von Objekten verstanden,
die in einer 1:N Beziehung stehen. In diesem Sinn gibt es im BW Hierarchien in den
Dimensions-, Attributs- und Hierarchietabellen. In der DWH-Terminologie ist dieser HierarchBegriff eng verbunden mit dem Begriff Drill-down ( vordefinierter Drill-down Pfad).

14

Externe Hierarchien
Im BW versteht man unter dem Begriff externe Hierarchien Prsentationshierarchien, die zur Strukturierung
der Ausprgungen eines Merkmals in sogenannten Hierarchietabellen abgelegt werden. D.h. sie sind losgelst
von den Attributen/Texten eines Merkmal-InfoObject und knnen somit unabhngig von den Attributen/Texten
des Merkmal-InfoObject gepflegt werden. Wird das Kennzeichen Mit Hierarchie in der Merkmal-Pflege gesetzt,
so knnen zu einem Merkmal (kein referenzierendes Merkmal) Hierarchien innerhalb des BW angelegt, aus
SAP-Quellsystemen oder ber Flatfiles in das BW geladen werden.
Pflege von Hierarchien zu einem Merkmal:
1. Transaktion: RSH1
2. Einstieg: AWB Modellierung InfoObjects InfoArea whlen
Im Kontextmen des gewhlten Merkmal-InfoObjects Hierarchie anlegen whlen
(Bereits existierende Hierarchien zu einem Merkmal werden im InfoObject-Baum unterhalb dieses
Merkmals angezeigt, und knnen ber das zugehrige Kontextmen bearbeitet werden)
Eigenschaften von externen Hierarchien:
Versionsabhngigkeit
Externe Hierarchien knnen in verschiedenen Versionen verwendet werden. Versionsabhngige
Hierarchien knnen bspw. fr planungs- und simulationshnliche Reportingaufgaben verwendet werden.
D.h. Hierarchieversionen knnen in einer Query miteinander verglichen werden.
Zeitabhngigkeit
Bei der Zeitabhngigkeit unterscheidet man:
- zeitabhngige Gesamthierarchie
D.h. die Zeitabhngigkeit bezieht sich auf die Hierarchiewurzel, und wird damit auf alle Hierarchieknoten bertragen. Je nach Auswahl des Stichtages der Query knnen dabei verschiedene Hierarchien
verwendet werden.
- zeitabhngige Hierarchiestruktur
D.h. die Zeitabhngigkeit bezieht sich auf Hierarchieknoten. Damit wird festgelegt, fr welchen Zeitraum
der Knoten an der angebenen Stelle der Hierarchie stehen soll.
Hierarchie-Intervalle
Es ist mglich, unter einem Hierarchieknoten Merkmalsausprgungen in Form von Intervallen zu hngen.
Anstatt z.B. in einer Kostenarten-Hierarchie die Kostenartenausprgungen zu Materialkosten alle einzeln
unter den Knoten Materialkosten zu hngen, knnen die Kostenartenausprgungen in der Form Kostenart
100 bis 1000 angegeben werden.
Vorzeichenumkehr fr Knoten
Mit dieser Funktion knnen die Vorzeichen der Werte, die einem Hierarchieknoten zugeordnet sind,
umgekehrt werden.
IDoc
Ein IDoc (Intermediate Document) ist ein Datenbehlter fr den Austausch von Daten zwischen
SAP-Systemen einerseits und SAP-Systemen und Fremdsystemen andererseits unter Nutzung
der ALE-Technlogie. Ein IDoc besteht aus:
einen Kopfsatz
Der Kopfsatz enthlt Informationen ber Sender, Empfnger, Nachrichten- und IDoc-Typ und
zusammenhngende Datensegmente
Jedes Datensegment enthlt einen Standardheader, der aus einer fortlaufenden Segment-nummer sowie
einer Beschreibung des Segmenttyps besteht, und eine 1000-Byte lange Feldleiste, die die Daten des Segments
beschreiben.
Statusstze
Die Statusstze beschreiben die bisherigen Verarbeitungsschritte des IDoc.

15

InfoArea
InfoAreas dienen als oberstes Ordnungskriterium von InfoProvider und InfoObjects im BW. Diese Objekte werden
in der AWB in entsprechenden Bumen angeordnet:
InfoProvider-Baum
InfoObjects-Baum
Dabei muss jeder InfoProvider genau einer InfoArea im InfoProvider-Baum zugeordnet sein. InfoObjects knnen
ber sogenannte InfoObjectCatalogs verschiedenen InfoAreas im InfoObjects-Baum zugeordnet werden.
Analog zu anderen BW-Objekten werden InfoAreas durch einen technischen Namen und eine Beschreibung
definiert und innerhalb des InfoProvider- oder InfoObjects-Baum angelegt.
InfoCube
InfoCubes sind die zentralen Objekte im BW, auf denen multidimensionale Analysen und Berichte basieren.
Ein InfoCube beschreibt aus Reporting-Sicht, d.h. fr den Reporting-Endanwender, einen in sich geschlossenen
Datenbestand eines betriebswirtschaftlichen Bereichs, auf den Queries definiert bzw. ausgefhrt werden. Sie
stellen somit InfoProvider dar.
Im BW werden folgende InfoCube-Typen unterschieden:
BasisCube
Allgemeiner RemoteCube
SAP RemoteCube
Virtueller InfoCube mit Services
1. Anlegen eines InfoCubes im InfoProvider-Baum:
Einstieg: AWB Modellierung InfoProvider InfoArea whlen
Im Kontextmen der InfoArea InfoCube anlegen whlen
2. Berabeiten von InfoCubes
Transaktion: RSDCUBE

InfoObject
Im BW werden die kleinsten Informationsbausteine (= Felder) als InfoObjects bezeichnet, die ber ihren
technischen Namen eindeutig identifizierbar sind. Als Bestandteil des Metadata Repository tragen InfoObjects die
technischen und fachlichen Informationen der Stamm- und Bewegungsdaten im BW. Sie werden systemweit zum
Aufbau von Tabellen und Strukturen eingesetzt, wodurch die Informationen im BW in strukturierter Form abgebildet
werden knnen. InfoObjects werden nach ihrer Funktion und Aufgabe in die nachstehenden Klassen unterteilt:
Kennzahl (z.B. Umsatz, Menge)
Kennzahl-InfoObjects liefern die Werte, die ausgewertet werden sollen.
Merkmal (z.B. Material, Kunde, Quellsystem-ID)
Merkmal-InfoObjects sind betriebswirtschaftliche Bezugsobjekte, anhand derer die Kennzahlen
ausgewertet werden.
Zeitmerkmal (z.B. Kalendertag, -monat)
Zeitmerkmale bilden den Bezugsrahmen fr viele Datenanalysen und Auswertungen. Diese Merkmale werden
mit dem BCT ausgeliefert; es knnen keine eigenen Zeitmerkmale definiert werden.
Einheit (z.B. Whrungsschlssel, Mengeneinheit)
Den Kennzahlen knnen Einheit-InfoObjects mitgegeben werden, um in den Auswertungen eine Verknpfung
zwischen den Kennzahlwerten und zugehrigen Einheiten zu ermglichen.
technisches Merkmal
Diese Merkmale haben eine organisatorische Bedeutung innerhalb des BW. So liefert z.B. das technische
Merkmal 0REQUID die Nummern, die beim Laden von Requests vom System vergeben werden und das
technische Merkmal 0CHNGID die Nummern, die bei Aggregats- nderungslufen vergeben werden.

16

1. Anlegen eines InfoObjects im InfoObjects-Baum:

Einstieg: AWB Modellierung InfoObjects InfoArea whlen
InfoObjectCatalog whlen
Im Kontextmen des InfoObjectcatalog InfoObject anlegen whlen
2. Pflege von InfoObjects
Transaktion: RSD1 bis RSD5

InfoObjectCatalog
Ein InfoObjectCatalog ist eine Gruppierung von InfoObjects nach anwendungsspezifischen Gesichtspunkten.
Er ist dabei ein rein organisatorisches Hilfsmittel und dient nicht zu Auswertungszwecken. Ein InfoObjectCatalog
ist im InfoObjects-Baum einer InfoArea zugeordnet. Ein InfoObjectCatalog ist vom Typ Merkmal oder vom Typ
Kennzahl und enthlt dementsprechend entweder Merkmale oder Kennzahlen.
1. Anlegen eines InfoObjectCatalog im InfoObjects-Baum:
Einstieg: AWB Modellierung InfoObjects InfoArea whlen
Im Kontextmen der InfoArea InfoObjectCatalog anlegen whlen
2. Bearbeiten von InfoObjectCatalogs
Transaktion: RSDIOBC
InfoPackage
Ein InfoPackage beschreibt, welche Daten aus einem Quellsystem ber eine DataSource angefordert werden
sollen. Dabei knnen die Daten anhand von Selektionsparametern gezielt ausgewhlt werden. Die Einplanungsoptionen werden mit Hilfe des Schedulers bestimmt. Dabei knnen zu einer DataSource mehrere InfoPackages
definiert werden.
Anlegen eines InfoPackage im InfoSources-Baum:
Einstieg: AWB Modellierung InfoSources InfoSource whlen Quellsystem whlen
Im Kontextmen des Quellsystems InfoPackage anlegen whlen (und im Scheduler einplanen)
(Bereits existierende InfoPackages werden im InfoSources-Baum unterhalb eines Quellsystems angezeigt,
und knnen ber das zugehrige Kontextmen bearbeitet werden)
InfoProvider
Ein InfoProvider ist ein BW-Objekt, ber das Queries definiert bzw. ausgefhrt werden knnen. Infoprovider
knnen sein:
InfoCubes (BasisCubes, virtuelle Cubes)
DSO-Objekte
Merkmal-InfoObjects (mit Attributen oder Texten)
InfoSets
MultiProvider
InfoSet
Ein InfoSet ist ein InfoProvider, welche selbst keine Daten enthlt. Ein InfoSet ist eine Abfragedefinition, mit deren
Hilfe Daten in der Regel ber Joins von DSO-Objekten und/oder Merkmal-InfoObjects (mit Attributen oder Texten)
im BW-System zur Laufzeit der Datenanalyse gelesen werden. Eine mgliche Anwendung von InfoSets ist das
Reporting ber Stammdaten.
1) Anlegen eines InfoSets im InfoProvider-Baum:
Einstieg: AWB Modellierung InfoProvider InfoArea whlen
Im Kontextmen der InfoArea InfoSet anlegen whlen
2) Pflege von InfoSets: Transaktion: RSISET
17

InfoSource
Eine InfoSource ist eine Menge von logisch zusammengehrigen InfoObjects, die alle verfgbaren Informationen
zu einem Geschftsprozess enthlt (z.B. Kostenstellenrechnung). Die Info Sourcen in BI 7.0 sind eine flache
Tabellenstruktur, die eine temporre Zwischenspeicherung von Daten nach einem Verarbeitungsschritt im Rahmen
von Transformationsregeln ermglichen sollen. Ziel von Info Sourcen ist es, die Daten fr den nchsten
Verarbeitunsschritt vorzubreiten. Einer InfoSource knnen mehrere Transformationsregeln zugewiesen werden.
Kennzahl
Kennzahl-InfoObjects, wie z.B. Umsatz, Menge, liefern die Werte, die bzgl. Merkmale ausgewertet werden sollen.
Das BW unterscheidet folgende Kennzahltypen:
Betrag
Menge
Zahl
Integer
Datum
Zeit
Whlt man den Kennzahltyp Betrag oder Menge, so mssen entsprechende Einheiten mitgegeben werden, d.h.
die Kennzahl wird an einem Einheiten-InfoObject oder an einem fixen Wert fr eine Einheit geklammert.
Kennzahl als Flussgre (= zeitraumbezogene Gre)
In jeder Zeiteinheit, fr die Werte zu dieser Kennzahl berichtet werden sollen, mssen Werte fr diese Kennzahl
gebucht sein ( z.B. Umsatz).
Kennzahl als Bestandsgre (= zeitpunktbezogene Gre)
Fr die Bestandskennzahl werden nur fr ausgewhlte Zeitpunkte (Sttzstellen) Werte gespeichert.
Die Werte fr die brigen Zeitpunkte werden aus dem Wert in einer Sttzstelle und den dazwischenliegenden Bestandsvernderungen errechnet (z.B. Lagerbestand). Dabei gibt es zwei Mglichkeiten,
Bestandsgren zu definieren:
Bestand mit Bestandsvernderung
Bei der Definition der Bestandsgre wird zustzlich eine Flussgre als Kennzahl-InfoObject,eine
sogenannte Bestandsvernderung bentigt, die in der Typdefinition mit
der zu definierenden Bestandsgre bereinstimmt.
Bestand mit Zu- und Abgngen
Bei der Definition der Bestandsgre werden zwei Flussgren Zugang und Abgang
bentigt, die in der Typdefinition mit der zu definierenden Bestandsgre bereinstimmen.

Aggregationen von Kennzahlen

Standard-Aggregation (SUM/Max/Min)
Mit der Standard-Aggregation legt man in der Kennzahl-Pflege fest, wie die Kennzahl im Datenziel
(BasisCube, DSO-Objekt) aggregiert wird. Beim DSO-Objekt spielt diese Einstellung nur dann eine Rolle,
wenn in der Pflege der Fortschreibungsregeln die berschreiben-Funktion nicht ausgewhlt wird..
Ausnahmeaggregation (letzter Wert, erster Wert, Max, Min,)
Mit der Ausnahmeaggregation, die in der Kennzahl-Pflege festgelegt wird, kann eine komplexere
Aggregation von Kennzahlen ausgefhrt werden.
Beispiel:
Die Kennahl Anzahl der Mitarbeiter wird summiert ber das Merkmal Kostenstelle
Standard-Aggregation). In diesem Fall knnte man fr die Ausnahmeaggregation
letzter Wert ein Zeitmerkmal als Bezugsmerkmal whlen.
Referenzkennzahl
Es besteht die Mglichkeit, eine Kennzahl mit Referenz auf eine andere Kennzahl (= Referenzkennzahl)
anzulegen. Ein Referenzkennzahl bentigt man in der Regel fr die Binnenumsatzeleminierung.
1. Anlegen eines Kennzahl-InfoObject im InfoObjects-Baum
18

Einstieg: AWB Modellierung InfoObjects InfoArea whlen

InfoObjectCatalog vom Typ Kennzahl whlen
Im Kontextmen des InfoObjectCatalog InfoObject anlegen whlen
2. Pflege von Kennzahlen:
Transaktion: RSD1 bis RSD5
Klammerung
Es ist hufig erforderlich, Merkmalswerte (Ausprgungen eines Merkmals) zu klammern, um eine eindeutige
Zuordnung von Merkmalswerten zu ermglichen. Die Klammerung wird in der Merkmal-InfoObject Pflege
umgesetzt. Dabei knnen mehrere Merkmale als geklammerte Merkmale verwendet werden. Generell sollte mit
geklammerten Merkmalen sparsam umgegangen werden, da ansonsten die Reporting-Performance beeintrchtigt
wird ( geklammerte Merkmal sind Bestandteil des Primrschlssels der entsprechenden Stammdatentabellen)
Beispiel:
Die Kostenstelle 100 im Kostenrechnungskreis 1000 ist der Einkauf und im Kostenrechnungskreis 2000 der
Vertrieb, d.h. es ist keine eindeutige Auswertung mglich. Durch die Klammerung der Kostenstelle an den
Kostenrechnungskreis wird die Eindeutigkeit gewhrleistet.
Merkmal
Merkmal-InfoObjects (z.B. Kunde, Artikel) sind Bezugsobjekte. Sie werden genutzt, um Kennzahlen zu
beschreiben, zu selektieren und auszuwerten. Merkmale knnen ferner Trger von Stammdaten (in Form von
Stammdatentabellen) sein:
Attribute
Texte
Hierarchien
Stammdatentragende Merkmale knnen ebenso als InfoSource mit direkter Fortschreibung fr das Laden
von Stammdaten verwendet werden. (Ausnahme: Referenzmerkmale, Einheit-InfoObjects und das merkmal
0SOURSYSTEM)
Besondere Merkmale:
Einheiten (z.B. 0CURRENCY (Whrungsschlssel), 0UNIT (Mengeneinheit))
Zeitmerkmale (z.B 0CALYEAR (Kalenderjahr))
technische Merkmale (z.B. 0REQUID (Request-ID))
1. Anlegen eines Merkmal-InfoObject im InfoObjects-Baum
Einstieg: AWB Modellierung InfoObjects InfoArea whlen
InfoObjectCatalog vom Typ Merkmal whlen
Im Kontextmen des InfoObjectCatalog InfoObject anlegen whlen
2. Pflege von Merkmalen:
Transaktion: RSD1 bis RSD5
Referenzmerkmal
Zur Wiederverwendbarkeit definierter Merkmal-InfoObjects, knnen Referenzmerkmale verwendet werden.
Referenzmerkmale liefern die technischen Eigenschaften zu einem anderen Merkmal. Diese Eigenschaften
sind nur beim Referenzmerkmal pflegbar. (Unter technische Eigenschaften fallen Stammdatentabellen
(Attribute, Texte, Hierarchien) Datentyp, Lnge, Anzahl und Art der geklammerten Merkmale, Kleinbuchstaben
und Konvertierungsroutine)
Metadata Repository
Das Metadata Repository umfasst alle Meta-Objekte (InfoCubes, InfoObjects, Queries, etc.) im BW und deren
Beziehungen zueinander.
1. Einstieg: AWB Metadata Repository
19

2. Transaktion: RSOR
Metadaten
Metadaten sind Daten/Informationen ber Daten. D.h. Metadaten beschreiben Herkunft, Historie und weitere
Aspekte der Daten. Durch die Metadaten knnen die Informationen, die im BW gespeichert sind, effektiv fr das
Reporting und der Analyse genutzt werden. Dabei unterscheidet man zwischen:
technische Metadaten
(z.B. Ablagestrukur der Daten, wie etwa das Zahlenformat einer Kennzahl)
betriebswirtschaftliche/fachliche Metadaten
(z.B. Verantwortliche fr die Daten, Datenherkunft)
Monitor
Mit Hilfe des Monitors knnen Datenanforderungen (Requests) und die Datenverarbeitung innerhalb der AWB
berwacht werden.
1. Einstieg: AWB Monitoring
2. Transaktionen: RSMON (Monitoring) bzw. RSMO (Monitor)
MultiProvider
Ein MultiProvider ist ein spezieller InfoProvider, der Daten aus mehreren InfoProvidern zusammenfhrt und sie
gemeinsam fr das Reporting zur Verfgung stellt. Ein MultiProvider enthlt selbst keine Daten. Seine Daten
ergeben sich ausschlielich aus den zugrunde liegenden InfoProvidern. Ein MultiProvider kann sich aus
verschiedenen Kombinationen der nachstehenden InfoProvider zusammensetzen:
InfoCube
DSO-Object
Merkmal-InfoObject (mit Attributen oder Texten)
InfoSet
Definition von MultiProvider:
Einstieg: AWB
Modellierung InfoProvider
InfoArea whlen
Im Kontextmen der gewhlten InfoArea MultiProvider anlegen und die InfoProvider whlen
DSO-Objekt

Ein Operational Data Store Objekt (DSO-Objekt) dient der Ablage von konsolidierten und bereinigten Daten
(Bewegungs- oder Stammdaten) auf Belegebene. Ein DSO-Objekt enthlt Schlsselfelder (Merkmale) sowie
Datenfelder, die im Gegensatz zum BasisCube neben Kennzahlen auch Merkmale sein knnen.
Im Unterschied zu BasisCubes bestehen DSO-Objekte aus drei (flachen) Tabellen:
Activation Queue ( = Eingangstabelle des DSO-Objektes)
In dieser Tabelle werden die neuen Daten abgelegt, bevor sie aktiviert werden. Sie ist von der Struktur hnlich
wie eine PSA-Tabelle aufgebaut, d.h. der Schlssel wird aus Request-, Datenpaket- und Datensatznummer
gebildet. Nachdem alle in der Activation Queue stehenden Requests erfolgreich aktiviert sind, werden die
Requests aus der Activation Queue gelscht.
Tabelle mit den aktiven Daten
Hier ist der aktuelle Zustand der Daten abgelegt. Diese Tabelle besitzt einen semantischen Schlssel, der vom
Modellierer definiert werden kann (z.B. Auftragsnummer, -position). Das Reporting setzt auf diese Tabelle auf.
Werden angeschlossene Datenziele im Fortschreibungsmodus Full-Update versorgt, so werden diese aus der
Tabelle mit den aktiven Daten fortgeschrieben.
Change Log ( = Ausgangstabelle fr angeschlosssene Datenziele)
Beim Aktivierungslauf werden die nderungen im Change Log abgelegt. Dort findet man also
die gesamte (Aktivierungs-)Historie der nderungen, da der Inhalt des Change Log nicht automatisch gelscht
wird. Werden angeschlossene Datenziele aus dem DSO-Objekt im Deltaverfahren mit Daten versorgt, so
werden diese aus dem Change Log fortgeschreiben. Das Change Log ist eine PSA-Tabelle und auch im PSABaum der AWB pflegbar. Demnach besitzt das Change Log einen technischen Schlssel aus RequestDatenpaket-, Datensatznummer).

20

Der neue Zustand der Daten wird parallel in das Change Log und in die Tabelle mit den aktiven Daten geschrieben!
Man unterscheidet die folgenden DSO-Objekt Typen:
Standard DSO-Objekt
Bei diesem Objekt handelt es sich um das oben beschriebene DSO-Objekt ( drei Tabellen).
Analog zu BasisCubes werden DSO-Objekte ber eine oder mehrere InfoSources via
Fortschreibungsregeln versorgt. Bei den Fortschreibungsregeln hat man neben denen,
die auch fr BasisCubes gelten, die zustzliche Option, Datenfelder zu berschreiben.
1. Standard DSO-Objekt anlegen:
Einstieg: AWB
Modellierung InfoProvider InfoArea whlen
Im Kontextmen der gewhlten InfoArea DSO-Objekt anlegen whlen
2. Bearbeiten von Standard DSO-Objekten:
Transaktion: RSDDSO
3. Standard DSO-Objekt administrieren:
Einstieg: AWB
Modellierung InfoProvider InfoArea whlen
Im Kontextmen des gewhlten DSO-Objektes Administrieren whlen
Selektives lschen ( Registerkarte Inhalt)
Analog zum BasisCube knnen mit dieser Funktion durch eine vorherige Selektion gezielt Datenstze,
die diesen Selektionskriterien entsprechen, aus dem DSO-Objekt gelscht werden. Das selektive
Lschen hat nur Auswirkungen auf die Tabelle mit den aktiven Daten! D.h. nur in dieser Tabelle
werden die Eintrge gelscht.
Wird das selektive Lschen verwendet, um fehlerhafte Datenstze aus dem DSO-Objekt zu lschen,
so kann man die richtigen bzw. korrigierten Datenstze mit Hilfe eines Reparatur-Request
Scheduler InfoPackage pflegen) wieder einbuchen.
Requests lschen ( Registerkarte Requests)
Mit dieser Funktion hat man die Mglichkeit gezielt Requests zu lschen, die in das DSO-Objekt
geladen wurden (falls diese noch nicht in angeschlossene Datenziele fortgeschrieben sind). Dabei
unterscheidet man zwei Ausganssituationen:

nicht aktivierte Requests

In diesem Fall werden die Requests nur aus der Activation Queue gelscht
aktivierte Requests
In diesem Fall werden die Requests aus der Tabelle mit den aktiven Daten und aus dem Change
Log gelscht
Requests neu aufbauen ( Registerkarte Neuaufbau)
Mit dieser Funktion knnen bereits gelschte Requests zu einem DSO-Objekt
wiederhergestellt werden. Diese werden dann wieder in die Activation Queue abgelegt.
Diese Funktion ist nur mglich, falls die Requests in der PSA-Tabelle gehalten werden.
Change Log lschen
Mit dieser Funktion knnen Requests aus dem Change Log gelscht werden, die nicht mehr zur
Fortschreibung oder zum Neuaufbau von angeschlossenen Datenzielen bentigt werden. Des Weiteren
macht es Sinn Change Log Requests zu lschen, sofern das Change Log berhaupt nicht bentigt
wird.
Administrieren: Umfeld
Change Log Daten lschen
-

Direkt update DSO-Objekt

Ein DSO-Objekt diesen Typs besitzt nur die Tabelle mit den aktiven Daten. Folglich kann dieser DSO-Typ nicht in den
Staging-Prozess eingebunden werden, da sowohl die Activation Queue als auch das Change Log nicht verwendet
werden. Diese DSO-Objekt Typen werden durch APIs gefllt und knnen ber ein BAPI gelesen werden. Sie dienen als
Datenablage fr externe Applikationen, wie z.B. das SAP SEM (Strategic Enterprise Management). Transaktionale DSOObjekte sind automatisch fr das Reporting verfgbar.

21

1. transaktionales DSO-Objekt anlegen:

Einstieg: AWB
Modellierung InfoProvider InfoArea whlen
Im Kontextmen der gewhlten InfoArea DSO-Objekt anlegen whlen
Unter Einstellungen Typ DSO-Objekt whlen
Im Kontextmen Typ ndern whlen
2. Bearbeiten von Standard DSO-Objekten:
Transaktion: RSDDSO
Write optimized DSO-Objekt
Ein DSO-Objekt diesen Typs besitzt nur die Tabelle mit den aktiven Daten. Dieses Objekt ist optimiert fr die bernahme
von Massendaten aus einem Vorsystem. Die Daten werden dabei 1:1 bernommen. Jeder Datensatz wird mit einem
eindeutigen technischen Schlssel versehen, der eine weitere Verarbeitung im Rahmen der Datentransferprozesse
ermglicht. Ein Reporting ist generell auf diesem Objekttyp mglich, die Aussagekraft ist jedoch nicht in allen Fllen
eindeutig.

Online Analytical Processing (OLAP)

Kernpunkt dieser Softwaretechnologie ist die multidimensionale Bereitstellung der Daten.
Durch die Multidimensionalitt lassen sich sehr flexible Abfrage- und Analysewerkzeuge erstellen, die einen
schnellen, interaktiven, flexiblen Zugriff auf relevante Informationen ermglichen
ROLAP (Relationales OLAP)
Aufgabe der ROLAP-Engine ist es, relationale Daten (mittels Sternschema) in multi- dimensionalen Strukturen
aufzubereiten, um so fr einen effizienten Zugriff zu sorgen. Beispiel fr ein ROLAP-System ist das SAP BW.
MOLAP (multidimensionales) OLAP
Hier werden die Daten bereits physikalisch in multidimensionalen Strukturen (Zell-/Array-Strukturen)
gespeichert, weshalb eine weitere Aufbereitung der Analysewerkzeuge nicht mehr ntig ist sehr schnelle
Antwortzeiten bei Abfragen und Kalkulationen. Bisher sind aber MOLAP-Systeme fr groe Datenmengen
weniger geeignet als ROLAP-Systeme.
Online Transaction Processing (OLTP)
Kernpunkt dieser Softwaretechnologie ist die relationale Bereitstellung der Daten fr die Abwicklung und
Dokumentation von Geschftsprozessen (z.B. Fakturierung, Lagerbestands- verwaltung). Durch die notwendige
Normalisierung ( i.d.R. die 3.Normalform garantiert Datenkonsistenz und referentielle Integritt) werden
aber die Abfragen komplexer, da viele Tabellen gelesen werden mssen. (z.B. das klassische R/3-System ist ein
OLTP-System).
PSA-Tabelle
Die Persistent Staging Area (PSA) stellt die Eingangsschicht in der SAP BW Architektur dar. Die PSA besteht aus
transparenten DB-Tabellen, den sogenannten PSA-Tabellen, in denen aus dem Quellsystem stammende Daten
ohne Modifikation (= Rohdaten) abgelegt bzw. zwischengespeichert werden knnen. Der Aufbau der PSA-Tabellen
entspricht im wesentlichen der Transferstruktur. Genau: Schlsselfelder der PSA + Felder der Transferstruktur,
wobei sich der Schlssel aus der Request-, Datenpaket-, Datensatznummer zusammensetzt. PSA-Tabellen
(technischer Name: /BIC/B000*) werden pro DataSource beim Aktivieren der bertragungsregeln vom System nur
dann generiert, falls die Transfermethode PSA in der Pflege der bertragungsregeln gewhlt wurde.
Beim Laden von Daten in die Datenziele Merkmal-InfoObject/BasisCube/DSO-Objekt kann zwischen den folgenden
Verbuchungsarten im Scheduler gewhlt werden:
PSA und danach InfoObject/Datenziele (paketweise)
Bei dieser Verbuchungsart wird ein Datenpaket eines Requests zunchst aus dem Quellsystem extrahiert und
in die PSA-Tabelle geschrieben. Sobald das Datenpaket vollstndig in die PSA-Tabelle bertragen wurde,
beginnt die Verbuchung der Daten in die Stammdatendaten- tabellen/Datenziele. Zeitgleich mit der Verbuchung
beginnt auch die Extraktion des nchsten Datenpaketes, so dass Extraktion und Verbuchung parallel ausgefhrt
werden.
PSA und danach InfoObject/Datenziele parallel (paketweise)
22

Bei der parallelen Verbuchung beginnt die Verbuchung in die Stammdatendatentabellen /Datenziele zeitgleich
mit dem Schreiben der Datenpakete in die PSA-Tabelle.
Nur PSA und anschlieend in die InfoObjects/Datenziele fortschreiben
Bei dieser Verbuchungsart werden alle Datenpakete eines Requests zunchst in die PSA-Tabelle geschrieben
und anschlieend in die Stammdatentabellen/Datenziele verbucht. D.h. hier findet keine Parallelisierung von
Verbuchung und Extraktion statt.
Nur PSA
Diese Verbuchungsart ermglicht es, alle zu extrahierenden Datenpakete eines Requests in die PSA-Tabelle
abzulegen, ohne sie in die Stammdatentabellen/Datenziele fortzuschreiben. Die Weiterverbuchung wird zu
einem anderen Zeitpunkt angestoen.
Nur InfoObject/Datenziel
Bei dieser Verbuchungsart werden die Datenpakete eines Requests direkt in die Stammdatentabellen/Datenziele verbucht, d.h. die Datenpakete werden nicht in einer PSA-Tabelle zwischengespeichert.
Prozesskette
Unter einer Prozesskette versteht man eine Reihe von Prozessen, die im Hintergrund (= Batch) eingeplant auf ein
Ereignis (Event) warten. Einige dieser Prozesse lsen ein eigenes Ereignis aus, das wiederum andere Prozesse
starten kann. Mit Prozessketten lassen sich:
die komplexen Ablufe, wie z.B. die Ladeprozesse, im BW mit Hilfe der ereignisgesteuerten Verarbeitung
automatisieren
die Ablufe durch die Verwendung von Netzplangraphiken visualisieren
das Verarbeiten der Prozesse zentral steuern und berwachen
Pflege von Prozessketten: Transaktion: RSPC

Quellsystem
Quellsysteme sind datenliefernde Instanzen fr das BW:
Fremdsysteme (NonSAP-System, R/2-System, R/3-System ( Rel. 3.1i)
SAP-Systeme
BW-Systeme (Data Marts)
Datenbanken (DB Connect)
Flatfiles (CSV- und ASCII-Dateien)
Flatfiles fr externe Marktdaten (z.B. Marktdaten von Dun & Bradstreet (D&B))
XML-Datei
Query
Mit Hilfe einer Query (= Abfrage) lassen sich Merkmal- und Kennzahl-InfoObjects zur Analyse der Daten eines
InfoProvider im Query-Designer zusammenstellen. Eine Query bezieht sich immer auf einen InfoProvider, whrend
zu einem InfoProvider beliebig viele Queries definiert werden knnen.
Referentielle Integritt
Die Prfung auf referentielle Integritt kann nur fr Bewegungsdaten und fr Stammdaten erfolgen, falls diese
flexibel fortgeschrieben werden ( InfoSource mit flexibler Fortschreibung). Sie ermittelt die gltigen Werte des
InfoObjects. Die Verprobung erfolgt nach dem Fllen der Kommunikationsstruktur, aber noch vor dem Anwenden
der Fortschreibungsregeln. Geprft wird gegen die SID-Tabelle eines Merkmals oder gegen ein DSO-Objekt, das in
der Pflege eines Merkmal-InfoObject ausgezeichnet wurde. Um die Prfung auf referentielle Integritt nutzen zu
knnen, muss im Scheduler (InfoPackage pflegen) innerhalb der Registerkarte Fortschreibung die Option Daten
immer verbuchen, auch wenn keine Stammdaten fr Daten existieren gewhlt werden, da sonst die Prfung auf
referentielle Integritt bersteuert wird. Ferner mssen die Merkmal-InfoObjects, die auf referentielle Integritt
gegen SID-Tabellen/DSO-Objekte geprft werden sollen, in der InfoSource-Pflege in der Spalte Referentielle
Integritt gekennzeichnet werden.
23

RFC (Remote Function Call)

ber den RFC knnen Daten zwischen SAP-Systemen und eigenentwickelten Programmen sicher und zuverlssig
bertragen werden. Mit dem RFC wird ein Funktionsbaustein in einem fremden SAP-System, BW-System,
eigenentwickelten Programmen oder innerhalb eines SAP-Systems aufgerufen. Dabei werden die Daten ber
TCP/IP oder X.400 als Bytestrom bergeben. Im Fall eines asynchronen Aufrufs spricht man von einem
transktionalen RFC (tRFC).
SAPI (Service-API)
Das (BW-)SAPI ist die Schnittsstelle, die mit dem Plug-In eingespielt wird. ber das SAPI findet die
Kommunikation bzw. der Datenaustausch zwischen den SAP-Systemen (z.B. SEM, CRM, APO, R/3) und
dem BW-System, zwischen XML-Dateien und BW-System und zwischen BW-Systemen statt. Das SAPI beruht
ausschlielich auf SAP Technologie und ist fr SAP-Systeme ab Basis Release 3.1I verfgbar.
Die BW Service-API Technologie wird an verschiedenen Stellen innerhalb der SAP BW Architektur verwendet:
Zur bertragung von Daten und Metadaten aus SAP-Systemen
Bei Datenbertragungen zwischen BW-Datenzielen innerhalb eines BW-Systems
(Data Mart Myself Interface) oder in ein anderes BW-System (Data Mart Interface)
Bei der bertragung von Daten aus XML-Dateien
Surrogat-Identifikation (SID)
Die SIDs sind systemgenerierter INT4-Schlssel. Dabei wird zu jedem Merkmal (Ausnahme: Merkmal ist ein
ausschlieliches Attribut) ein SID-Schlssel generiert. Diese Zuordnung wird in einer SID-Tabelle zum jeweiligen
Merkmal umgesetzt, wobei das Merkmal Primrschlssel der SID-Tabelle ist. Die SID-Tabelle ist ber den
Merkmalschlssel mit den zugehrigen Stammdatentabellen (falls vorhanden) verbunden. Wird ein Merkmal
beim Anlegen eines BasisCube einer Dimension zugeordnet, so wird nach der Aktivierung des BasisCube die
SID-Tabelle dieses Merkmals mit der entsprechenden Dimensionstabelle verbunden. Die SID-Werte werden beim
Laden von Stamm- bzw. Bewegungsdaten generiert und in die entsprechenden SID-Tabellen geschrieben.
Bei Bewegungsdaten werden diese zum Aufbau der DIM-ID auch in die Dimensionstabellen geschrieben. Die
Verwendung von INT4-Schlsseln (SID-/DIM-ID Schlssel) ermglicht einen schnelleren Datenzugriff als bei
langen alphanumerischen Schlsseln. Durch die SID-Technik im BW Sternschema wird ferner ermglicht, die
Stammdaten BasisCube-bergreifend zu verwenden.
Technischer Content (TCT)
Mit dem TCT werden die ntigen BW-Objekte/Werkzeuge zur Nutzung der BW Statistik bereitgestellt.
Die BW Statistik ist ein Werkzeug zur Analyse und Optimierung der Prozesse, wie z.B. Zugriffszeiten auf Daten
mit Queries, Ladeprozesszeiten. Die Daten der BW Statistik werden im BW gespeichert und werden ber einen
MultiProvider, der auf mehrere BW BasisCubes basiert. Die bernahme des TCT erfolgt analog zum BCT.
Um die BW Statistik schlielich nutzen zu knnen, muss diese vorher fr ausgewhlte InfoProvider aktiviert werden
(Einstieg: AWB
Werkzeuge BW Statistiken fr InfoProvider).
Text
Texte (z.B. Bezeichnung einer Kostenstelle) gehren wie Attribute und Hierarchien zu den Stammdaten im BW. In
der Pflege eines Merkmal-InfoObject ( Registerkarte Stammdaten/Texte) legt man fest, ob das Merkmal ber
Texte verfgen soll. Falls ja, muss man mindestens eine Textauswahl treffen: Kurz-, Mittellanger-, und Langtext
(20, 40, 60 Zeichen). Ferner kann ausgewhlt werden, ob die Texte zeit- und/oder sprachabhngig sind. Texte
werden in einer Stammdatentabelle fr Texte zum Merkmal abgelegt.

24

Transaktionaler BasisCube
Transaktionale BasisCubes finden meist nur in Verbindung mit SEM Verwendung. Auf die Daten eines solchen
BasisCube wird transaktional zugegriffen, d.h. Daten werden (evtl. von mehreren Benutzern gleichzeitig) in den
BasisCube geschrieben und mglicherweise sofort wieder gelesen; (Standard-)BasisCubes sind dafr nicht
geeignet. Fr einen reinen Lesezugriff sollten Standard-BasisCubes verwendet werden.
Transferstruktur
Die Transferstruktur dient dem BW zur Bereitstellung aller zu einem Geschftsprozess bzw. zu einer Geschftseinheit verfgbaren Metadaten eines SAP-Quellsystems. Sie stellt eine Auswahl der Felder einer Extraktstruktur
des SAP-Quellsystems dar. In der Transferstrukturpflege im BW wird durch Zuordnung von DataSource und
InfoSource festgelegt, welche Felder Ladeprozess genutzt werden sollen. Mit dem Aktivieren der bertragungsregeln wird die Transferstruktur sowohl im BW-System als auch im SAP-Quellsystem generiert. Die Transferstruktur
wird im BW-System in der Tabelle RSTS und im SAP-Quellsystem in der Tabelle ROOSGEN abgelegt. Die Daten
werden 1:1 von der Transferstruktur des SAP-Quellsystems in die Transferstruktur des BW bernommen und dann
mit Hilfe der bertragungsregeln der Kommunikationsstruktur des BW bergeben. Ist das Quellsystem ein DateienSystem, so werden die Metadaten im BW-System gepflegt, somit muss auch die die Transferstruktur manuell im
BW-System definiert werden. Dabei muss die Struktur der Transferstruktur die Struktur der Datei beschreiben.
bertragungsregel
Mit den bertragungsregeln wird festgelegt, wie Quelldaten ber die BW-Transferstruktur an die Kommunikationsstruktur weitergegeben werden, d.h. bertragungsregeln gelten nur fr die Daten aus einem Quellsystem. Man
spricht daher auch von lokalen bertragungsregeln. Man unterscheidet folgende bertragungsregeln:
Daten werden 1:1 fortgeschrieben
Versorgung mit einer Konstanten
Die Felder der Kommunikationsstruktur knnen whrend des Ladeprozesses mit fixen Werten versorgt werden,
d.h. die Felder werden nicht ber die Transferstruktur versorgt.
Mit Hilfe von ABAP-Routinen bzw. des Formel-Editors knnen bertragungsregeln flexibel gestaltet werden.
Bearbeiten von bertragungsregeln:
Einstieg: AWB Modellierung InfoSources Anwendungskomponente whlen
InfoSource whlen
Quellsystem whlen
bertragungsregeln ndern/lschen whlen
bertragungsroutine
In der Pflege eines Merkmal-InfoObject hat man die Mglichkeit, eine sogenannte (globale) bertragungsroutine
(ABAP-Routine/kein Formel-Editor)) anzulegen. Im Gegensatz zur lokalen bertragungsroutine ist die globale
bertragungsroutine quellsystembergreifend verwendbar. Diese bertragungsroutine wird nur genutzt, falls das
Merkmal als InfoSource mit direkter Fortschreibung verwendet wird. Falls eine lokale und eine globale bertragungsroutine genutzt wird, so wird erst die lokale und dann die globale bertragungsroutine durchlaufen.
Virtueller Cube
Virtuelle Cubes sind spezielle InfoCubes. Ein virtueller stellt eine logische Sicht dar. Im Gegensatz
Zum BasisCube werden aber keine Daten physisch im BW abgelegt. Die Daten werden erst bei der Ausfhrung von
Queries aus den Quellsystemen beschafft. Man unterscheidet im Hinblick auf die Datenbeschaffung folgende
Typen:
SAP RemoteCube
Ein SAP RemoteCube erlaubt die Definition von Queries mit direktem Zugriff auf Bewegungsdaten in anderen
SAP-Systemen. Voraussetzungen fr das Nutzen von SAP RemoteCubes:
die Funktionalitt des BW SAPI ist installiert ( enthalten im Plug-In des SAP-Quellsystems
der Releasestand des Quellsystems ist mindestens 4.0B
25

der InfoSource des RemoteCube sind DataSources aus dem Quellsystem zugeordnet, die fr den
Direkzugriff freigegeben sind, und es bestehen aktive bertragungsregeln fr diese Kombination.
Ob eine DataSource den direkten Zugriff untersttzt, kann man sich in der Tabelle ROOSOURCE
anschauen. Falls das Feld VITCUBE die Ausprgungen 1 oder 2 hat.
Allgemeiner RemoteCube
Ein Allgemeiner RemoteCube ermglicht das Reporting von Daten aus Nicht-SAP Systemen.
Das Fremdsystem bergibt die angeforderten Daten ber BAPIs an den OLAP-Prozessor. Dabei mssen die
Daten bereits aus dem Quellsystem in der Form geliefert werden, wie sie bei der Analyse bentigt werden, d.h.
es knnen im BW System keine bertragungsregeln definiert werden.
Virtueller InfoCube mit Services
Dieser Typ ermglicht es, Analysen auf den Daten eines selbstentwickelten Funktionsbaustein aufzubauen.
Dieser Typ wird bei komplexen Berechnungen eingesetzt, die durch Queries mit Formeln und Ausnahmeaggregationen nicht vorgenommen werden knnen., wie z.B. beim SEM)
-

XML (eXtensible Markup Language) Integration

Der Datenaustausch mittes XML basiert auf den Standards, die von der Object Management Group (OMG) definiert
werden. Die OMG versucht Industriestandards fr den Datenaustausch zwischen verschiedenen Systemen zu
entwickeln. Im BW sind solche Transfermethoden fr die Integration von Daten mittels XML implementiert. Die
bertragung der XML-Daten in das BW erfolgt ber das SOAP (Simple Object Access Protocol) unter Verwendung
des HTTP (Hypertext Transfer Protocol). Dabei werden die Daten selbst im XML-Format beschrieben. Diese Daten
werden zunchst in die Delta-Queue geschrieben und anschlieend ber eine DataSource zum Quellsystem Myself
in die gewnschten Datenziele fortgeschrieben. Diese Transfermethode sollte nicht fr Massendaten verwendet
werden; groe Datenmengen sollten dann ber das Flatfile-Interface geladen werden.

26

Anhang 1: Abkrzungen
ABAP
ADK
ALE
API
ASCII
AWB
BAPI
BCT
BEx
BW
CSV
DDIC
DIM-ID
DWH
ETL
IDoc
ODBO
OLAP
OLTP
RFC
SAPI
SID
SOAP
SQL
TCT
tRFC
WAS
XML

Advanced Business Application Programming

Archiving Development Kit
Application Link Enabling
Application Programming Interface
American Standard Code for Information Interchange
Administrator Workbench
Business Application Programming Interface
Business Content
Business Explorer
Business Information Warehouse
Colon Separated Variables/Values
Data Dictionary
Dimension-Identifikation
Data Warehouse
Extraktion, Transformation und Laden
Intermediate Document
OLE DB (Object Linking and Embedding Database) for OLAP
Online Analytical Processing
Online Transaction Processing
Remote Function Call
Service-API
Surrogat-Identifikation
Simple Object Access Protocol
Structured Query Language
Technischer Content
transaktionaler RFC
Web Application Server
eXtensible Markup Language

27

Anhang 2: Transaktionscodes
1. Transaktionen im BW-System
Transaktion
BAPI
CMOD
FILE
LISTCUBE
LISTSCHEMA
RRMX
RS12
RSA1
RSA3
RSA5
RSA6
RSA7
RSA9
RSCUSTV1
RSCUSTV6
RSCUSTV8
RSD1, RSD2, RSD3
RSD4, RSD5
RSDBC
RSDDV
RSDIOBC
RSDMD
RSDMPROM
RSDDSO
RSDV
RSFH
RSIMG
RSISET
RSKC
RSMD
RSMO
RSMON
RSMONCOLOR
RSO2
RSO3
RSOR
RSORBCT
RSPC
RSRT
RSRTRACE
RSRV
RSSM
RSU1 / RSU2 / RSU3

Bedeutung
BAPI Explorer
Projektverwaltung von SAP-Erweiterungen
Pflege von logischen dateipfaden
Listviewer fr Datenziele ( BasisCubes, DSO-Objekte, Merkmal-InfoObjects)
Schemaviewer fr BasisCubes (inklusive Aggregate)
Starten des BEx Analyzer
Sperreintrge (von Tabellen) anzeigen und lschen
Administrator Workbench ( Modellierung)
Extraktorchecker SAPI 3.0
DataSources aus dem Business Content bernehmen
DataSources und Anwendungskomponentenhierarchie nachbearbeiten
Pflege der Delta-Queue
Anwendungskomponente aus dem Business Content bernehmen
Einstellungen fr flache Dateien ndern
Tausender-, Dezimal-, Feldtrenner sowie Feldbegrenzer)
Schwellwerte fr Datenladen ndern
Paketgre, Gre einer PSA-Partition, Frequenz Status-IDOC)
Einstellungen zum Aggregatsnderungslauf (Change Run) ndern
Schwellwert fr Neuaufbau, Blockgre)
Pflege von InfoObjects vom Typ Merkmale / Kennzahlen / Einheiten)
Bearbeiten von technischen Merkmalen und Zeitmerkmalen
DB Connect: Tabellen und Views selektieren
Pflege von Aggregaten
Bearbeiten von InfoObjectCatalogs
Pflege von Stammdaten (zu einem Merkmal)
Bearbeiten von MultiProvider
Bearbeiten von DSO-Objekten
Pflege der Gltigkeitsscheibe
BasisCubes mit Kennzahlen vom Typ Bestandsgre)
Test-Tool fr Bewegungsdatenextraktoren
BW Customizing Einfhrungsleitfaden
Pflege von InfoSets
Pflege der erlaubten Zusatzzeichen im BW
Test-Tool fr Stammdatenextraktoren
Monitor
Administrator Workbench ( Monitoring)
Wertung von Requests
Pflege von generischen DataSources
Einrichten der Delta-Extraktion fr Attribute und Texte
Administrator Workbench ( Metadata Repository)
Administrator Workbench ( Business Content)
Pflege von Prozessketten
Querymonitor
Query-Trace
Analyse und Reparatur von BW-Objekten
Pflege von Reporting-Berechtigungsobjekte
Fortschreibungsregeln anlegen/ndern/anzeigen ( BasisCubes und DSO-Objekte)

28

Transaktion
SARA
SBIW
SE03
SE09
SE11
SE37
SE38
SM04
SM12
SM37
SM38
SM50
SM59
SM62
SM66
SPRO
ST05
TRSA

Bedeutung
Archivadministration
Anzeigen des Einfhrungsleitfadens ( Customizing der Extraktoren)
Transport Organizer Tools
Transport Organizer
ABAP Dictionary
Function Builder ( Pflege von Funktionsbausteinen)
ABAP Editor ( Pflege von ABAP-Programmen)
Benutzerliste
Sperreintrge selektieren
Job-bersicht
Queue (Job) Definition
Prozessbersicht
Pflege von RFC-Verbindungen
Pflege von Events
Globale Workprozess-bersicht
Customizing-Leitfaden
Performance-Analyse ( SQL-Trace)
Test-Tool fr Service-API

2. BW-relevante Transaktionen im SAP-R/3-System

Transaktion
RSA3
RSA5
RSA6
RSA7
RSA9
RSO2
RSO3
SBIW
TRSA

Bedeutung
Extraktorchecker SAPI 3.0
DataSources aus dem Business Content bernehmen
DataSources und Anwendungskomponentenhierarchie nachbearbeiten
Pflege der Delta-Queue
Anwendungskomponente aus dem Business Content bernehmen
Pflege von generischen DataSources
Einrichten der Delta-Extraktion fr Attribute und Texte
Anzeigen Einfhrungsleitfadens ( Customizing der Extraktoren)
Test-Tool fr Service-API

29

Anhang 3: Metadaten-Tabellen
InfoObject
Tabelle
RSDIOBJ
RSDIOBJT
RSDATRNAV
RSDATRNAVT
RSDBCHATR
RSDCHABAS
RSDCHA
RSDDPA
RSDIOBJCMP
RSKYF
RSDTIM
RSDUNI

Bedeutung
Verzeichnis aller InfoObjects
Texte von InfoObjects
Navigationsattribute
Navigationsattribute
Stammdaten-Attribute
Basismerkmale (fr Merkmale, Zeitmerkmale und Einheiten)
Merkmalskatalog
Datenpaketmerkmale
Klammerung (Abhngigkeiten) von InfoObjects
Kennzahlen
Zeitmerkmale
Einheiten

InfoCube
Tabelle
RSDCUBE
RSDCUBET
RSDCUBEIOBJ
RSDDIME
RSDDIMET
RSDDIMEIOBJ
RSDCUBEMULTI
RSDICMULTIIOBJ
RSDICHAPRO
RSDIKYFPRO
RSDICVALIOBJ

Bedeutung
Verzeichnis der InfoCubes
Texte zu den InfoCubes
Navigationsattribute
Verzeichnis der Dimensionen
Texte zu Dimensionen
InfoObjects je Dimension (Verwendungsnachweis)
An MultiCube beteiligte InfoCubes
MultiProvider: Auswahl/Identifikation von InfoObjects
InfoCubespezifische Merkmaleigenschaften
InfoCubespezifische Kennzahleigenschaften
InfoObjects der Bestandsgltigkeitstabelle zum InfoCube

Aggregat
Tabelle
RSDDAGGRDIR
RSDDAGGRCOMP
RSDDAGGRT

Bedeutung
Verzeichnis der Aggregate
Beschreibung der Aggregate
Texte zu den Aggregaten

DSO-Objekt
Tabelle
RSDO
RSDOT
RSDOIOBJ
RSDOATRNAV
RSDOTABL

Bedeutung
Verzeichnis aller DSO Objekte
Texte von DSO-Objekten
InfoObjects des DSO-Objektes
Navigationsattribute im DSO-Objekt
Verzeichnis aller DSO Tabellen

30

PSA
Tabelle
RSTSDSO

Bedeutung
Verzeichnis aller PSA-Tabellen

DataSource (= OLTP-Source)
Tabelle
ROOSOURCE
RODELTAM
RSOLTPSOURCE

Bedeutung
Kopf Tabelle fr SAP BW DataSources (SAP-Quellsystem/BW-System)
BW Deltaverfahren (SAP-Quellsystem)
Replikatstabelle fr DataSources im BW

InfoSource
Tabelle
RSIS
RSIST
RSISFIELD

Bedeutung
Verzeichnis der InfoSources mit flexibler Fortschreibung
Texte zu den InfoSources mit flexibler Fortschreibung
InfoObjects einer InfoSource

Kommunikationsstruktur
Tabelle
RSKS
RSKSFIELD
RSISFIELD

Bedeutung
Kommunikationsstruktur zur InfoSources mit flexibler Fortschreibung
Kommunikationsstruktur (View) fr Attribute zur InfoSource mit direkter Fortschreibung
Texte zu den InfoSources mit flexibler Fortschreibung
InfoObjects einer InfoSource mit flexibler Fortschreibung

Transferstruktur
Tabelle
RSTS
ROOSGEN

Bedeutung
Transferstruktur im BW
Generierte Objekte zur DataSource (z.B.Transferstruktur) im SAP-Quellsystem

Mapping
Tabelle
RSISOSMAP
RSOSFIELDMAP

Bedeutung
Mapping zwischen InfoSources und DataSources (= OLTP-Sources)
Mapping zwischen DataSource-Feldern und InfoObjects

31