1 SAP Business Information Warehouse SAP R/3 BW. 2 Stimmen zum SAP BW Besonders geeignet zur Analyse...
-
Upload
sigismund-muenchow -
Category
Documents
-
view
112 -
download
2
Transcript of 1 SAP Business Information Warehouse SAP R/3 BW. 2 Stimmen zum SAP BW Besonders geeignet zur Analyse...
1
SAP Business Information Warehouse
SAP R/3 BW
3
Namenskonventionen
Selbst definierte Objekte werden nach dem Muster VBH3XX… benannt
• VB BIB Paderborn• H3 die aktuelle Gruppe• XX Platz-Nr. / Team-Nr.
• Beispiel: VBH310_Cube01
Richtlinien zum Umgang mit dem SAP BW
4
Navigation im SAP BW
• SAP Easy Access Menü
• Favoriten• Transaktionscodes
– Eingeben– Kombination mit /o
und /n– Technische Namen
einschalten
© SAP AG
5
Hilfe zum SAP BW
• Feldhilfe (F1)• Wertehilfe (F4)• Hilfe zu Fehlermeldungen
• SAP-Bibliothek• Glossar• http://help.sap.com,
Bereich SAP NetWeaver™• http://service.sap.com/bi
© SAP AG
6
Werkzeuge des SAP BW
AdministratorWorkbench (AWB)Administrationdes Systems
BEx AnalyzerAufbereitung undPräsentation von Reports
BEx BrowserVerwaltung undAusführen von Reports,Portalfunktion
BEx Query DesignerDefinition von Reports
Web Application DesignerErstellung von Web Applications
7
Administrator Workbench (AWB)
• Datenbereitstellung und –haltung
• Aufbau, Pflege und Betrieb des BW-Systems
• Datenladeprozess• Administrator-
Werkzeug
8
Business Explorer Analyzer (BEx Analyzer)
• Reporting- und Analysewerkzeug
• Definition von Reports
• läuft in Excel• ermöglicht Web-
Reports
9
Business Explorer Browser
• Verwaltung und Ausführung von Reports
• Links auf Favoriten: externe und SAP R/3 Transaktionen
10
Werkzeuge und Zielgruppen
11
Arten von Analyse-Anwendern
• Konsumenten: – einfache Anwender, – nutzen vorgefertigte Queries über feste Datenmengen
• Analysten– navigieren innerhalb von Berichten und betrachten
diese aus verschiedenen Perspektiven
• Autoren– = Queryentwickler– vollständiger Zugriff auf Queries und
Datenzusammenstellungen– Erstellung neuer Queries
12
Anwendergruppen und deren Anforderungen
Metamodell Querydefinition und Query
• Querydefinitionen beziehen sich auf einen InfoProvider
• Querydefinition werden auf BW-Server gespeichert
• Query wird mit Excel-Arbeitsmappe gespeichert (lokal oder zentral in Business Content Service)
• Individuelle Query-Zustände können als View gespeichert werden
13
Komponenten einer Query
• Kennzahlen: Zahlen aus Faktentabelle des InfoCubes
• Merkmale: Daten aus Dimensionen des InfoCubes
• Berechnete Kennzahlen: Formel auf Kennzahlen. In Infocube speicherbar.
• Variablen: sind beim Aktualisieren einer Query in einem Formular änderbar; auf ihnen können z.B. Filter basieren
14
15
Bereiche einer SAP-Query
© SAP AG
16
Exception Reporting
17
Exception Reporting
• Ziel: Potenzielle Probleme möglichst frühzeitig erkennen
• Kennzahlen innerhalb bestimmter Wertebereiche als Ausreißer definieren
• Ausreißer innerhalb eines Berichts kenntlich machen
• Entscheider über Ausreißer informieren– Alert-Monitor– EMail-Nachricht
18
Schritte zur Implementierung eines Frühwarnsystems
1. Exception definieren
2. Output: Farbliche Hervorhebungen im Query-Arbeitsblatt
3. Reporting Agent Einstellungen definieren
4. Einplanen
5. Output: Alert Monitor und Nachrichten
19
Ablauf des Exception Reporting
20
Reporting Agent
• Administrator Workbench -> Reporting Agent• Hintergrundfunktionen• Verwaltungsfunktionen• Alert-Monitor-Funktionen• u.A.
– Auswerten von Exceptions– Drucken von Queries– Vorberechnen von Web Templates– Verwalten von Bookmarks
21
Reporting Agent Einstellungen
• Administrator Workbench -> Reporting Agent -> Exceptions
1. Einplanungspaket definieren
2. Exception erstellen
3. Exception einplanen
22
Grundobjekte der Modellierung
23
InfoObjects• InfoObjects bezeichnen die kleinsten Informationsbausteine
(vergleichbar mit Feldern)
• durch technischen Namen identifizierbar
• Durch InfoObjects werden die fachlichen und technischen Informationen der Stamm- und Bewegungsdaten im SAP BW beschrieben.
• InfoObjects werden zum Aufbau von Tabellen und Strukturen eingesetzt
• InfoObjects werden für die Definition von Berichten verwendet
• InfoObjects werden unterschieden in
– Merkmale
– Kennzahlen
– Einheiten
– Zeitmerkmale.
24
Info-Objects: Kennzahlen
25
InfoObjects: Merkmalen
26
Stammdaten• Stammdaten sind dadurch gekennzeichnet, dass sie
über einen längeren Zeitraum unverändert bleiben• Stammdaten werden im BW zu den Merkmalen gezählt
(stammdatentragende Merkmale)• Den Stammdaten können Texte, Hierarchien und
Attribute zugeordnet werden• Man unterscheidet zeitabhängige und zeitunabhängige
Stammdaten
27
• Attribute
Attribute sind selbst InfoObjects, die zur näheren Beschreibung von Merkmalen verwendet werden. So sind z.B. dem Merkmal Kunde u.a. die Attribute PLZ und Ort zugeordnet.
- Anzeigeattribute: nur in Kombination mit Merkmal in Abfrage- Navigationsattribute: erlauben Navigieren anhand des Attributes innerhalb einer Abfrage
• Texte
können einem Schlüsselwert zugeordnet werden. Texte können sprach- und zeitabhängig definiert werden. Beispiel: dem Merkmal Warengruppe sind Texte zugeordnet.
• Hierarchien
Hierarchien können in der Analyse zur Beschreibung alternativer Sichten auf die Daten verwendet werden. Eine Hierarchie besteht aus Knoten und Blättern, wobei die Knoten in einer Parent-Child-Beziehung stehen und die Blättern durch Merkmalsausprägungen repräsentiert werden.
Stammdaten
28
Erweitertes Sternschema von SAP BW
29
Hierarchien• Einem Merkmal kann eine Hierarchie zugeordnet werden.
30
InfoProviderAlle mit Hilfe des Reporting auswertbaren Objekte werden unter dem Begriff InfoProvider gruppiert.
Es wird unterschieden:• Physisch datentragende Objekte, d.h. die Daten zu diesen
Objekten sind in zugeordneten Datenbanktabellen im SAP BW gespeichert.– ODS-Object (Operational Data Store)– BasisCubes– Stammdatentragende InfoObjects
• Logische Sichten, d.h. Objekte, deren Daten in einem anderen System oder in anderen physischen Objekten gespeichert sind.– InfoSets (enthalten keine Daten, nur Schlüssel, verbinden (z.B. flache)
Tabellen über Joins)– RemoteCubes (Datenstrukturen und Stammdaten in SAP BW,
Bewegungsdaten in externem Quellsystem)– MultiProvider (führt Daten aus mehreren InfoProvidern zusammen,
enthält selbst jedoch keine Daten)Infoprovider werden in InfoAreas gegliedert.
31
ODS-Objekte
• ODS = Operational Data Store• Ein ODS-Objekt dient zur Ablage von konsolidierten und bereinigten
Bewegungsdaten.• ODS-Objekte werden durch einfache Tabellen realisiert.• Die in ODS-Objekten abgelegten Daten sind (falls freigeschaltet),
direkt für das Reporting zugänglich.• Die in ODS-Objekten abgelegten Kennzahlen können nicht nur
durch Summation, sondern auch durch Überschreiben geändert werden.
• Es gibt Einschränkungen zu beachten:– Die Anzahl der Schlüsselfelder ist auf 16 begrenzt
– Die Anordnung aller Schlüssel- und Nichtschlüsselmerkmale und Kennzahlen in einem Datensatz führt zu erheblichen Satzlängen
32
InfoCube• InfoCubes sind die zentralen Objekte im SAP BW,
auf denen Berichte und Analysen basieren.• Ein InfoCube beschreibt aus Sicht eines Reporting-
Anwenders einen in sich geschlossenen Datenbestand eines betriebswirtschaftlichen Bereichs, auf dem Queries definiert bzw. ausgeführt werden können.
• InfoCubes sind InfoProvider• Folgende InfoCube-Typen werden unterschieden:
– BasisCube: Daten im Cube – RemoteCube: Bewegungsdaten liegen außerhalb BW– Virtueller InfoCube: Datenloser Cube, Daten intern oder
extern
Dimension• Unter einer Dimension versteht man die
Gruppierung logisch zusammengehöriger Merkmale unter einem gemeinsamen Oberbegriff. In einer Dimension können maximal 248 Merkmale zusammengefasst werden.
• Dimension eines BasisCubes besteht aus– einer Dimensionstabelle– SID-Tabelle (Surrogat-ID), von BW erstellt– u.U. mehreren Stammdatentabellen
33
34
BasisCube• Ein BasisCube besteht aus
– Einer Faktentabelle, in der bis zu 233 Kennzahlen abgespeichert werden
– bis zu 16 Dimensionstabellen, die mit den Stammdatentabellen verknüpft sind. (bis zu 248 Merkmale)3 Dimensionen sind durch SAP vordefiniert:
1. Zeit
2. Einheit
3. InfoPackage (Def. von Datenladevorgängen)
• und weitere, z.B. Material- oder Kundendimensionstabelle
35
Multidimensionale Datenstrukturen
36
Multidimensionalität
Vertriebsweg
Zeit
Produk
tWeitere Dimensionen sind
nicht dargestellt:• Verkaufsorganisation• Sparte• Auftraggeber
Umsatz:2 Mio.
Fakten (Kennzahl(en))
Dimension
37
Was bedeutet Multidimensionalität?
• Multidimensionalität ist meist ein Hauptcharakteristikum von Daten in DWs– Andere
Datenstrukturierungen sind aber gängig (z.B. rein hierarchisch)
• Keine tabellenartige Darstellung
• Beliebig viele analyserelevante Kriterien (Dimensionen bzw. Merkmale)
• Möglichst genaue, detaillierte Beschreibung der Daten
• Veranschaulichung oft durch einen Datenwürfel– Besser n-dimensionaler
Quader
38
Analysetechniken und SAP BW
• Für detaillierte Fragestellungen des Anwenders stehen im multidimensionalen Datenmodell verschiedenartige Operationen zur Manipulation des Datenwürfels zur Verfügung.
• Hierbei handelt es sich überwiegend um einen Wechsel von Dimensionen und Verdichtungsstufen, d.h. um eine Navigation im Datenraum.
• Diese Analysemöglichkeiten werden im BEx Analyzer z.B. über das Kontextmenü im Ergebnisbereich angeboten, an den OLAP-Prozessor weitergegeben und von diesem interpretiert und auf den Datenbestand angewendet.
39
Operationen auf Datenwürfeln
• Sicht ist die Einschränkung auf bestimmte Dimensionen• Filtern ist das Einschränken der Datenmenge auf
Teilmengen in einer Dimension• Dicing (engl. dice = Würfel) ist das Erzeugen eines
„kleineren“ Datenwürfels durch Filtern in mehreren Dimensionen
• Slicing (engl. slice = Scheibe) ist Dicing in einer Dimension mit einelementiger Teilmenge
• Pivoting ist ein Wechsel der Sicht (anschaulich ist das Drehen des Datenwürfels)
• Drill down ist Pivoting mit erweiterter Sicht• Roll up = Gegenteil von Drill down
40
Mehrdimensionale Analyse
41
Business Content
42
Warum vorkonfigurierte Informationsmodelle?
• Modellierung anforderungsgerechter Datenmodelle ist eine langwierige und teilweise hoch komplexe Angelegenheit
• Der Aufwand ist umso höher, je individueller die Anforderungen sind und je weniger die Entwickler auf bereits existierende Vorlagen zurückgreifen können.
• Unternehmen modellieren in vielen Fällen immer dieselben Sachverhalte
43
Inhalt des Business Content
© SAP AG
© SAP AG, Marianne Kollmann, Product Management BI
44
Def. Business Content
• Business Content sind umfassend vorgefertigte Informationsmodelle für die Analyse von Geschäftsprozessen
• Komponenten dieser Modelle sind:– Extraktoren in SAP-Systemen– Elemente des Datenmodells (wie Kennzahlen, Merkmale,
InfoCubes und ODS-Objekte)– Komponenten für den Datenladeprozess (wie InfoSources
und Fortschreibungsregeln)– Reportingkomponenten (wie Queries, Web Templates und
Arbeitsmappen)• SAP BW liefert einen sehr umfangreichen Satz an Business
Content mit: 2500 InfoObjects, 450 Reports, 60 Rollen• Der technische Name aller Business-Content-Objekte in SAP
BW beginnt mit 0
45
Arbeiten mit dem Business Content
BusinessContent
OhneAnpassungverwenden
Verfeinerungoder
Vergröberung
Vorlage füreigenen
Business Content
46
Business Content Versionen
• Im BW werden 3 Objektversionen des BC unterschieden:– D-Version: SAP-Auslieferungsversion– A-Version: aktive Version– M-Version: überarbeitete Version
• Um mit den Objekten des BC arbeiten zu können, müssen diese in die aktive Version (A-Version) überführt werden.
47
Auf der Suche nach dem richtigen Business Content
• Business Content kann im Metadata Repository durchsucht werden.
• Das Metadata Repository ist in der Administrator Workbench (AWB) integriert.
48
Metadata-Repository
49
Metadata-Repository 1
50
Was sind (eigentlich) Metadaten?
• Informationen über die Datenstrukturen und ihre Beziehungen sind „Daten über Daten“ und werden als Metadaten bezeichnet– Z.B. „Jede Klasse hat genau eine
Superklasse“ – Oder: „Eine Query referenziert genau einen
InfoProvider. Ein InfoCube ist ein InfoProvider“
51
„Das Metadata Repository“
• Etwas missverständliche Bezeichnung für ...– ... das Verzeichnis aller in SAP vorhandenen Objekte in
Zusammenhang mit OLAP-Funktionalität (Business Content)– Dient der Administration eines DW– Z.B. vorgefertigte (und hinzugefügte)
• Merkmale
• InfoCubes
• Queries
• Datenmodelle
• Mappings (z.B. Fortschreibungsregeln)
technische/fachliche Metadaten
• Technische Metadaten: Administratoren-Sicht auf Daten. DB-Felder, DB-Tabellen, Speicherbedarf der DB, Datenmodelle, Mappings.
• Fachliche Metadaten: Anwendersicht auf Daten. Kommentare, Beschreibungen, Geschäftsregeln, Details über Auswertungen. Genutzt in Frontend-Tools.
52
53
Modellierung von Datenstrukturen
1. InfoObjects und InfoCubes erstellen und bearbeiten
2. Semantische Datenmodellierung3. Logische Datenmodellierung
54
Datenbankentwurf OLAP
Entwurfsebene Entwurfsmethoden
Konzeptueller
(semantischer)
Entwurf
Semantisches Data Warehouse Modell
Multidimensionales ERM
Dimensional Fact Modeling
Application Design for Analytical Processing Technologies
Logischer Entwurf Starschema
Erweitertes SAP-Starschema
Galaxy Schema
Snowflake Schema
Physischer Entwurf Speicherungsstrukturen
Zugriffsmechanismen
Datenbanktuning
usw.
55
Modellierung von Datenstrukturen: InfoObjects und InfoCubes
erstellen und bearbeiten
56
InfoObjects erstellen
• Unterscheiden zwischen Kennzahlen und Merkmalen
• Jedes InfoObject ist einem InfoObject-Katalog zugeordnet– Kennzahlen-InfoObject-Katalog– Merkmale-InfoObject-Katalog
• Jedes InfoObject liegt in einer InfoArea
57
1. InfoObject-Katalog anlegen2. InfoObject innerhalb dieses Kataloges
anlegen3. InfoObject prüfen
auf syntaktische Korrektheit4. InfoObject aktivieren
Datenbanktabellen werden generiert
InfoObjects neu erstellen
58
InfoCube anlegen
1. InfoCube erstellen
2. Kennzahlen hinzufügen
3. Merkmale hinzufügen
4. Dimensionen hinzufügen
5. Merkmale in Dimensionen einordnen
6. Prüfen, sichern, aktivieren
59
Modellierung von Datenstrukturen:Semantische Datenmodellierung
60
semantischer OLAP Entwurf
• Warum semantischer Entwurf eines Data Warehouse?– Begriffsklärung– Informationsbedarfsanalyse bei Fachabteilungen– Dokumentation– Datendefinition
• muss Basis-Bausteine eines multidimensionalen Informationsssystems abbilden können
• noch keine allgemein akzeptierte Notation - verschiedene Ansätze
• eine Möglichkeit: Multidimensionales Entity-Relationship-Modell (MERM)
61
Entity-Relationship-Modell ERMfür OLTP-Datenbanken
62
Multidimensionales Entity-Relationship Modell (MERM)
• angelehnt an das Entity-Relationship-Modell der OLTP-Datanbanken
• minimale Anzahl von Strukturelementen• in MERM neu gegenüber ERM:
– Faktenrelation– hierarchische Beziehung– Dimensionsfeld
63
Beispiel eines MERM
64
Schritt Bezeichnung Beschreibung
1 Relevante Daten der Geschäftsprozesse identifizieren
Analyse und Aufspaltung eines ERM in einen oder mehrere Teilbereiche von relevanten Daten der Geschäftsprozesse
2 Faktenrelation erzeugen n-m-Beziehungen zwischen starken Entitäten ergeben z.B. die Faktenrelation, die numerischen Attribute sind Kandidaten für Kennzahlen
3 Dimensionen bilden Inhaltliche Zusammenfassung der verbleibenden Entitäten zu Gruppen, die von starken Entitäten dominiert werden
Transformation ERM -> MERM
• Ein ERM -> evtl. mehrere MERM• Grund: ERM zu komplex. Sie bilden oft viele/alle
Geschäftsprozesse gleichzeitig ab.• Die MERM können sich überschneiden.
65
ERM->MERM: 1. Relevante Daten identifizieren
66
ERM->MERM: 2. Überschneidungsentitäten suchen
67
Beispiel für eine Überschneidungsentität
Customer
Material Sales Person
Material group Sales Department
Customer noCustomer nameCityRegion
Material noMaterial nameMaterial type color price
Material group noMaterial group name....
Sales TransactionDateCustomer noMaterial noSales pers noAmountQuantityCurrency
Sales pers. noSales pers. name.......
Sales dep. noSales dep. location.......
68
ERM->MERM: 3. Dimensionen bilden
69
ERM->MERM: 4. fertiges MERM
70
Granularität
• = "Detail" einer Datenstruktur• hohe Granularität: die Daten werden von vielen
Merkmalen beschrieben• niedrige Granularität: die Daten werden von
wenigen Merkmalen beschrieben
• Hohe Granularität hat:• positive Auswirkung auf Möglichkeiten in
Queries: drill down • negative Auswirkungen auf Performanz der
Abfragen und Ladezeit
71
Relativ hohe Granularität
72
Relativ niedrige Granularität
73
• Transformation ERM ->MERM in 3 Schritten• Granularität von Artikel und Zeit: Wie wird sie ausgedrückt, wie lässt sie sich verfeinern?
74
Modellierung von Datenstrukturen: Logische Datenmodellierung
75
Vom MERM zum SternschemaFaktentabelle• Zentrale Faktenrelation
Faktentabelle mit Kennzahlen• numerische Attribute der
Faktenrelation werden zu Kennzahlen
• Der Primärschlüssel setzt sich aus den Dimensions-IDs zusammen
Dimensionstabellen• Dimensionen
Dimensionstabellen• Attribute der Dimensions-
entitäten werden zu Feldern der Dimensionstabellen
• Jeder Datensatz der Dimensionstabelle bekommt eine eindeutige Dimensions-ID zugewiesen
76
einfaches Sternschema in BW
Kennzahlen
Faktentabelle
Dimensions-attribute
Dimension 2
Dimensions-attribute
Dimension 1
Dimensions-attribute
Dimension 3
Dimensions-attribute
Dimension 4
77
Probleme beim einfachen Sternschema
• keine Unterstützung der Mehrsprachigkeit• Alphanumerische Fremdschlüssel möglich• keine Unterstützung von zeitabhängigen
Stammdaten• Hierarchiebeziehungen müssen als Attribute
einer Dimensionstabelle modelliert werden
78
Erweitertes Sternschema von BW
• Faktentabelle bleibt unverändert
• Die Merkmale der Dimensionen werden in Segmente aufgeteilt– Attribute– Texte– Hierarchien
• Attribute und Texte können zeit- und sprachabhängig definiert werden
• Einführung von SID
79
Erweitertes Sternschema
Trennung von Stammdaten (Merkmale) und Bewegungsdaten (Faktentabelle). Die Stammdaten stehen für das ganze DataWarehouse zur Verfügung.
80
Lösungsabhängige und –unabhängige Daten
• Lösungsabhängige Daten:Fakten- und Dimensionstabellen
• Lösungsunabhängige Daten:Merkmale
G e b ie t 1 G e b ie t 2 G e b ie t 3
B e z irk 1
G e b ie t 3 a
B e z irk 2
R e g io n 1
G e b ie t 4 G e b ie t 5
B e z irk 3
R e g io n 2
G e b ie t 6
B e z irk 4
G e b ie t 7 G e b ie t 8
B e z irk 5
R e g io n 3
V e rtr ie b s o rg a n is a t io n
M a t e r i a l G r o u p
M a t e r i a l H i e r a r c h y T a b l e
M a t e r i a l N u m b e rL a n g u a g e C o d e
M a t e r i a l N u m b e rL a n g u a g e C o d e
M a t e r i a l N a m e
M a t e r i a l T e x t T a b l eM a t e r i a l _ D i m e n s i o n _ I D
M a t e r i a l N u m b e r
M a t e r i a l D i m e n s i o n T a b l e
M a t e r i a l M a s t e r T a b l e
M a t e r i a l N u m b e rM a t e r i a l N u m b e r
M a t e r i a l T y p e
M a t e r i a lM a t e r i a l D i m e n s i o n D i m e n s i o n
81
Surrogat-ID SID • SID-Tabellen verbinden den lösungsabhängigen InfoCube-
Bereich mit dem lösungsunabhängigen Stammdatenbereich• SID-Tabellen sind Zeigertabellen• Verknüpfung zwischen Dimensionstabelle und
Merkmalstabelle• Verknüpfung zwischen Merkmal und zugehörigen Attributs-,
Text- und Hierarchietabellen• 4-Byte-Ganzzahl• künstlicher Primärschlüssel
• Vorteile:– DataWarehouse-eigene Primärschlüssel performanter als
importierte Primärschlüssel– aus mehreren externen Quellen kommende Primärschlüssel sind
nicht unbedingt eindeutig oder haben unpassende Datentypen
82
SID-Tabellen
Text
SID Tables
Master
Hierarchies
Hierarchies
Master
SID Tables
Text
Hierarchies
Master
SID Tables
Text
Hierarchies
Master
SID Tables
Text
Hierarchies
Master
SID Tables
Text
Hierarchies
Master
SID Tables
Text
Text
SID Tables
Master
Hierarchies
Text
SID Tables
Master
Hierarchies
Text
SID Tables
Master
Hierarchies
DimensionTable
Text
SID Tables
Master
Hierarchies
DimensionTable
DimensionTable
DimensionTable
DimensionTable
Hierarchies
Master
SID Tables
Text
FACT
Masterdata: Stammdaten
83
Schneeflocken- und Galaxyschema in BW
• Schneeflockenschema– Merkmalsattribute verweisen auf andere
Merkmale
• Galaxyschema– Beliebig viele Faktentabellen– Einheitliche Merkmale (Stammdaten) können
von beliebig vielen Faktentabellen genutzt werden.
84
Unternehmensweites Data Warehouse
• ein unternehmensweites Data Warehouse kann sehr groß werden.
• Aufgrund der Größe findet häufig eine thematische Trennung in Teilbereiche statt:Data Marts
• Problem: Redundanz• Lösung:
– einheitliche Merkmale. Können von allen Faktentabellen genutzt werden. Galaxyschema.
– standardisierte Kennzahlen
85
• Entwickeln Sie aus folgenden Anforderungen ein SAP-Sternschema:„Wir wollen in unserem Data Warehouse Umsätze, (variable) Kosten und Verkaufsmengen unserer Produkte auswerten können. Die Auswertungen benötigen wir hinsichtlich unserer Kunden, Regionen, Produkte und Sparten. Unser Chef benötigt die Berichte eigentlich meistens monats-, manchmal auch tagesgenau“
• Ändern Sie das Sternschema aufgrund folgender Anforderungen zu einem erweiterten Sternschema:– Auswertung nach Ländern ermöglichen– Produktbezeichnung, Entwicklerteam– Produktbezeichnung in den Sprachen Deutsch,
Englisch und Spanisch
86
Stagingszenarien
Staging=Datenbereitstellung
87
Staging-Szenarien• Stagingszenarien mit
nicht persistenter Datenablage
• Daten werden immer wieder neu beschafft und nur für die Dauer einer Transaktion im BW-System gehalten.
• RemoteCubes, virtuelles DW. Nur die Struktur wird bereitgestellt, Daten liegen extern.
• Sinnvoll, wenn zeitnahe Verfügbarkeit der Daten aus Quellsystem erforderlich ist oder nur kleine Datenmengen sporadisch bearbeitet werden.
• Stagingszenarien mit persistenter Datenablage
• Die aus dem Quellsystem ins SAP BW-System geladenen Daten werden über die Dauer einer Transaktion hinaus gespeichert
• Standard
• wird im Folgenden behandelt
Datenfluss
(DTP)
(IP)
Infoprovider
• E:- Extraktion• T:- Transformation [TR]• L:- Laden• PSA:- Persistent staging area
89
Staging
DataSource mit Transferstruktur in PSA
InfoCube
Transformation
quellsystem-unabhängiges Datenformat
Fortschreibungssregeln
PS
AD
aten
ziel
.txt DBF SAP R/3 Quellsysteme
Extraktion
InfoObjectsODS-Objekte
Dat
enqu
elle
Altes versus neues Staging
90
91
SAP BW-Objekte für den Datenfluss
• Eine DataSource beschreibt das Datenangebot eines Quellsystems in Form von Feldstrukturen. Die DataSource besteht aus der Extraktstruktur (sämtliche bereitgestellte Felder) und der Transferstruktur (Auswahl von Feldern der Extraktstruktur).
• Eine InfoSource ist eine zu einer Einheit zusammengefasste Menge von logisch zusammengehörigen Informationen. Die Kommunikationsstruktur ist die Feldstruktur, in der die Informationen abgelegt werden.
• Übertragungsregeln transformieren Daten aus gegebenenfalls mehreren Transferstrukturen in einer Kommunikationsstruktur.
• Fortschreibungsregeln transformieren Daten aus einer Kommunikationsstruktur in ein oder mehrere Datenziele.
• Für jedes Quellsystem kann einer DataSource nur eine InfoSource zugewiesen werden.
92
Quellsysteme
• Alle Systeme, die Daten zur Extraktion in das SAP BW liefern– SAP R/3– Textdateien (ASCII)– Datenbanksysteme– andere BW-Systeme
• Voraussetzung: Daten liegen strukturiert vor
93
DataSources
• Im Quellsystem liegen logisch zusammen-gehörige Daten in Form von DataSources vor.
• DataSources sind quellsystembezogen.• Sie umfassen eine Menge von Feldern, die in
einer flachen Struktur (Extraktstruktur) zur Datenübertragung ins BW angeboten werden.
• In Form einer Auswahl an Feldern der Extraktstruktur, der Transferstruktur, werden die Daten vom Quellsystem in das BW übertragen.
94
PSA
• Die Persistent Staging Area (PSA) stellt innerhalb des SAP BW die Eingangsablage von angeforderten Daten aus verschiedenen Quellsystemen dar. Die angeforderten Daten werden unverändert in Form der Transferstruktur in transparenten, relationalen Datenbanktabellen abgelegt und können somit auch fehlerhaft sein, wenn sie schon im Quellsystem fehlerhaft sind. Die logischen Datenpakete (Requests) können nun auf Qualität und Sinnhaftigkeit, Reihenfolge und Vollständigkeit überprüft werden.
© SAP AG
95
Persistentes Stagingszenario
Quell-system
PSA
InfoCube
InfoObjects(Merkmale)
96
Stagingszenarien: Überblick
ohne persistenteDatenablage
mit persistenterDatenablage
InfoCube/ODS RemoteCube
Quellsystem RemoteCube
Quellsystem PSA InfoCube
ODS InfoCubeQuellsystem PSA ODS
InfoCube
InfoCube InfoCube
Quellsystem PSA ODS
Stagingszenarien
97
Transformationen• Transformationen dienen dazu, Daten von der Datenquelle
(DataSource) in das Datenziel (InfoProvider, z.B. InfoCube oder Merkmal) zu übertragen und dabei eventuell zu transformieren und zu modifizieren.
• Folgende Methoden gibt es :– Daten werden 1:1 übertragen (keine Manipulation der Daten)
– Die Felder des Datenziels werden mit einer Konstanten gefüllt.
– Die Transformation mit Hilfe des Formel-Editors erstellt
– Durch eine ABAP-Routine können Übertragungsregeln flexibel gestaltet werden.
• Die Kommunikationsstruktur einer InfoSource ist quellsystemunabhängig, hingegen sind die Übertragungsregeln quellsystemspezifisch.
98
Übertragungsregeln - wieÜbertragungs-
regeln
Feld in Feldschreiben konstanten Wert
zuweisenABAP-Routine
Formel
© SAP AG
99
InfoSource definieren
• InfoSource – Menge aller verfügbaren Daten zu einem
Geschäftsvorfall – Einheit von logisch zusammengehörigen
Informationen– kann unter Verwendung von
Übertragungsregeln Daten aus einer oder mehreren DataSources beziehen
– Die Struktur der InfoSource heißt Kommunikationsstruktur.
100
Fortschreibungsregel – Definition
Fortschreibungsregeln:– spezifizieren, wie die Daten (Kennzahlen,
Zeitmerkmale, Merkmale) aus der Kommunikationsstruktur einer InfoSource in die Datenziele fortgeschrieben werden
– verbinden eine InfoSource mit einem InfoCube, Merkmal oder ODS-Objekt
101
Fortschreibungsarten
Flexible Fortschreibung• Bewegungsdaten• Stammdaten
= mit Fortschreibungsregeln
• Die Daten einer InfoSource werden unter Verwendung von Fortschreibungsregeln in die Datenziele (InfoCube, ODS-Objekt, InfoObject) geladen.
Direkte Fortschreibung• Nur Stammdaten (Merkmale mit
Attributen, Texten oder Hierarchien)
• = ohne Fortschreibungsregeln• Stammdaten eines InfoObjects
werden direkt ohne Fortschreibungsregeln nur unter Verwendung von Transferregeln über die Kommunikationsstruktur in die Stammdatentabelle fortgeschrieben.
Einfacher, daher vorzuziehen, wenn keine Transformationen in den Fortschreibungsregeln benötigt werden.
102
Datenfluss bei flexibler Fortschreibung
© SAP
103
Fortschreibungsregel – InfoObjects
• Bei InfoObjects gibt es die Fortschreibungsregel Überschreiben
• Mit dieser Option werden neue Werte in das InfoObject fortgeschrieben
104
InfoPackage anlegen und einplanen
• Datenanforderung
• beinhaltet diverse Parameter für den Upload
• können per Jobverwaltung eingeplant und terminiert werden
105
Monitor
• Der Monitor ist das Überwachungswerkzeug der Administrator Workbench.
• Mit Hilfe des Monitors wird die Datenanforderung (Request) und Datenverarbeitung der Administrator Workbench überwacht. In den verschiedenen Ebenen der Detailanzeige wird der Status der Datenverarbeitung angezeigt.
© SAP AG
106
Laden von Stammdaten
= Master Data Staging
107
Daten im SAP BW
Daten im BW
MetadatenAnwendungs-
daten
fachlicheMetadaten
technischeMetadaten
Bewegungs-daten
Stammdaten
Attribute Texte Hierarchien
108
Hinweise für das Laden aus Flatfiles
• Spalten-Überschriften beachtenBeim Ladeprozess können Kopfzeilen ignoriert werden.
• Datumsangaben: JJJJMMDDZeitangaben: hhmmss
109
Stammdaten laden ohne InfoPackage
1. Merkmal als Datenziel festlegen
2. DataSource anlegen
3. Transformation zwischen DataSource und Datenziel anlegen
4. Datentransferprozess anlegen und starten
110
Stammdaten laden mit InfoPackage
1. Merkmal als Datenziel festlegen
2. DataSource anlegen
3. InfoPackage erstellen und Daten in PSA laden
4. Transformation zwischen DataSource und Datenziel anlegen
5. Datentransferprozess anlegen und starten
111
Laden von Bewegungsdaten
112
Daten im SAP BW
Daten im BW
MetadatenAnwendungs-
daten
fachlicheMetadaten
technischeMetadaten
Bewegungs-daten
Stammdaten
Attribute Texte Hierarchien
Laden von BewegungsdatenData Store Object (DSO) als Kopie der Struktur des InfoCubes anlegen.1.Quellsystem auswählen2.DataSource anlegen3.InfoPackage anlegen,Daten in PSA laden und prüfen4.Transformation anlegen zwischen Data Store Object und Data Source5.Datentransferprozess zum DSO anlegen6.DTP ausführen7.Transformation anlegen zwischen DSO und InfoCube8.Datentransferprozess zum InfoCube anlegen und ausführen.
113
114
Open Hub Service
115
Open Hub Service
Der Open Hub Service ermöglicht es, Daten aus einem SAP BW System in nicht-SAP Data Marts, Analytical Applications und anderen Anwendungen zu verteilen. Damit wird die kontrollierte Verteilung über mehrere Systeme hinweg gewährleistet.
Zentrales Objekt für den Datenexport: Open Hub Destination. Durch sie wird definiert, aus welchem Objekt welche Daten bezogen werden und in welches Ziel sie weitergeleitet werden. Transformationen sind möglich.
116
Factless Fact Tables
117
Universitäre Wahlen
• Studenten nehmen an universitären Wahlen teil (oder auch nicht)
• Die Wahlen finden in einem bestimmten Raum statt.
• Die Wahlen haben einen Anlass.• Die Wahl findet in einem bestimmten
Semester statt.• Nicht erfasst werden darf: das
Wahlergebnis des einzelnen Studenten
118
Merkmale & Kennzahlen
Merkmale• Student-Name• Alter• Wahlanlass• Semesterbezeichnung• Raum-Nr• ...
Kennzahlen• ?
119
Abbildung von Factless Fact Tables
Theoretisch• Faktentabelle enthält
keine Kennzahlen• Faktentabelle besteht
lediglich aus Fremd-schlüsseln (auf die Dimensionstabellen)
SAP BW• Faktentabelle muss
mindestens eine Kennzahl enthalten
• Integration einer Dummy-Kennzahl (=1)
120
Vorgehensweise
1. Eine numerische, ganzzahlige Dummy-Kennzahl Dummy wird definiert.
2. Man integriert die Kennzahl Dummy in einen bislang faktenlosen InfoCube.
3. Beim Laden der Bewegungsdaten in den InfoCube wird der Kennzahl Dummy der konstante Wert „1“ zugewiesen.
4. Bei Auswertungen auf den InfoCube kann der Dummy dazu verwendet werden, die Anzahl der Ereignisse, hier der Wahlbesuche, darzustellen.