SAP Business Information Warehouse SAP R/3 BW

Präsentation zum Thema: "SAP Business Information Warehouse SAP R/3 BW"—  Präsentation transkript:

1 SAP Business Information Warehouse SAP R/3 BW

2 „Stimmen“ zum SAP BW Besonders geeignet zur Analyse und Darstellung der im DW gespeicherten Daten Gute Werkzeuge zur Erstellung individueller Anwendungen (BEx Analyzer, Webreporting) Vordefinierte Informationsmodelle (Business Content) Theoretisch nicht von R/3 abhängig Die Strukturen basieren teilweise auf R/3-Geschäftsprozessen Business Content ist auf R/3-Strukturen ausgerichtet Optimale Leistung in Zusammenarbeit mit R/3 (spezielle Extraktoren usw.)

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 Bereich SAP NetWeaver™ © SAP AG

6 Werkzeuge des SAP BW Administrator Workbench (AWB)
Administration des Systems Web Application Designer Erstellung von Web Applications BEx Analyzer Aufbereitung und Präsentation von Reports BEx Browser Verwaltung und Ausführen von Reports, Portalfunktion BEx Query Designer Definition von Reports

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

13 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

14 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

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 -Nachricht

18 Schritte zur Implementierung eines Frühwarnsystems
Exception definieren Output: Farbliche Hervorhebungen im Query-Arbeitsblatt Reporting Agent Einstellungen definieren Einplanen 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 Einplanungspaket definieren Exception erstellen 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: Merkmale

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 Stammdaten 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.

28 Erweitertes Sternschema von SAP BW

29 Hierarchien Einem Merkmal kann eine Hierarchie zugeordnet werden.

30 InfoProvider Alle 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

33 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

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: Zeit Einheit InfoPackage (Def. von Datenladevorgängen) und weitere, z.B. Material- oder Kundendimensionstabelle

35 Multidimensionale Datenstrukturen

36 Multidimensionalität
Fakten (Kennzahl(en)) Umsatz: 2 Mio. Dimension Weitere Dimensionen sind nicht dargestellt: Verkaufsorganisation Sparte Auftraggeber Zeit Produkt Vertriebsweg

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
Ohne Anpassung verwenden Vorlage für eigenen Business Content Verfeinerung oder Vergröberung

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)

52 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.

53 Modellierung von Datenstrukturen
InfoObjects und InfoCubes erstellen und bearbeiten Semantische Datenmodellierung 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 InfoObjects neu erstellen
InfoObject-Katalog anlegen InfoObject innerhalb dieses Kataloges anlegen InfoObject prüfen auf syntaktische Korrektheit InfoObject aktivieren Datenbanktabellen werden generiert

58 InfoCube anlegen InfoCube erstellen Kennzahlen hinzufügen
Merkmale hinzufügen Dimensionen hinzufügen Merkmale in Dimensionen einordnen 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 ERM fü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 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. 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

65 ERM->MERM: 1. Relevante Daten identifizieren

66 ERM->MERM: 2. Überschneidungsentitäten suchen

67 Beispiel für eine Überschneidungsentität

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 Sternschema
Faktentabelle 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

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ösungsunabhängige Daten: Merkmale Lösungsabhängige Daten: Fakten- und Dimensionstabellen

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 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 Staging=Datenbereitstellung
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

88 Datenfluss Infoprovider (DTP) (IP) E:- Extraktion
T:- Transformation [TR] L:- Laden PSA:- Persistent staging area Achtung: FlatFile kann ohne PSA geladen werden Bei der Übertragung ins PSA werden die Konvertierungen extern  internes Format vorgenommen DTP pro Datenziel (Abbildung aus Foliensatz „EDW Overview“, Folie 20) (IP)

89 Transferstruktur in PSA
Staging InfoObjects Datenziel InfoCube ODS-Objekte Fortschreibungssregeln Transformation PSA quellsystem-unabhängiges Datenformat DataSource mit Transferstruktur in PSA Extraktion Datenquelle Quellsysteme .txt DBF SAP R/3

90 Altes versus neues Staging

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
InfoCube Quell- system PSA InfoObjects (Merkmale)

96 Stagingszenarien: Überblick

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
Formel Feld in Feld schreiben ABAP-Routine konstanten Wert zuweisen © SAP AG

99 InfoSource definieren
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

108 Hinweise für das Laden aus Flatfiles
Spalten-Überschriften beachten Beim Ladeprozess können Kopfzeilen ignoriert werden. Datumsangaben: JJJJMMDD Zeitangaben: hhmmss

109 Stammdaten laden ohne InfoPackage
Merkmal als Datenziel festlegen DataSource anlegen Transformation zwischen DataSource und Datenziel anlegen Datentransferprozess anlegen und starten

110 Stammdaten laden mit InfoPackage
Merkmal als Datenziel festlegen DataSource anlegen InfoPackage erstellen und Daten in PSA laden Transformation zwischen DataSource und Datenziel anlegen Datentransferprozess anlegen und starten

111 Laden von Bewegungsdaten

112 Daten im SAP BW

113 Laden von Bewegungsdaten
Data Store Object (DSO) als Kopie der Struktur des InfoCubes anlegen. Quellsystem auswählen DataSource anlegen InfoPackage anlegen, Daten in PSA laden und prüfen Transformation anlegen zwischen Data Store Object und Data Source Datentransferprozess zum DSO anlegen DTP ausführen Transformation anlegen zwischen DSO und InfoCube Datentransferprozess zum InfoCube anlegen und ausführen.

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 Kennzahlen 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 Eine numerische, ganzzahlige Dummy-Kennzahl Dummy wird definiert. Man integriert die Kennzahl Dummy in einen bislang faktenlosen InfoCube. Beim Laden der Bewegungsdaten in den InfoCube wird der Kennzahl Dummy der konstante Wert „1“ zugewiesen. Bei Auswertungen auf den InfoCube kann der Dummy dazu verwendet werden, die Anzahl der Ereignisse, hier der Wahlbesuche, darzustellen.