Markenrechtlicher Hinweis

Die in dieser Arbeit wiedergegebenen Gebrauchsnamen, Handelsnamen, Warenzeichen usw. können auch ohne besondere Kennzeichnung geschützte Marken sein und als solche den gesetzlichen Bestimmungen unterliegen. Sämtliche in dieser Arbeit abgedruckten Bildschirmabzüge unterliegen dem Urheberrecht © des jeweiligen Herstellers.

SAP, R/3, SAP Business Warehouse (BW) und SAP NetWeaver sind Marken oder eingetragene Marken der SAP AG, Deutschland.

Microsoft Excel und Microsoft Dynamics NAV sind Marken oder eingetragene Marken der Microsoft Corp., USA.

2

Kurzfassung

Diese Diplomarbeit beschreibt die Konzeption und Entwicklung eines Dashboards für ein fiktives Energieversorgungsunternehmen im SAP Business Intelligence 7.0 und die anschließende Integration in das SAP NetWeaver Portal.

Dabei wird zunächst auf die besonderen Merkmale von Versorgungsunternehmen eingegangen, um die Anforderungen an die Funktionalität und Detailtiefe des Dashboards darzulegen.

Des Weiteren wird die Frage geklärt, weshalb es für Unternehmen generell wichtig ist, Informationen so aufzubereiten, dass diese als Grundlage für strategische und operative Entscheidungen verwendet werden können.

Die technische Darstellung der Optionen zur Realisierung eines Dashboards erfolgt mit Hilfe der Standardwerkzeuge der „SAP Business Explorer Suite“. Im Detail wird hier auf die Werkzeuge Business Explorer, Query-Designer und Web Application Designer eingegangen.

Die Verbesserungspotentiale der Standard-Werkzeuge werden zukünftig durch eine weitgehende Integration von Business Objects behoben. Zu Demonstrationszwecken wird innerhalb dieser Arbeit das Programm Xcelsius der SAP Business Objects vorgestellt, mit welchem Dashboards entwickelt werden können.

Abschließend wird ein Vergleich des Web Application Designers und des Xcelsius durchgeführt sowie ein Ausblick auf die zukünftige Weiterentwicklung der SAP Front-Endprodukte gegeben.

3

Abstract

This thesis describes the concept and development of a dashboard for an imaginary utility company in SAP Business Intelligence 7.0 and the subsequent integration into the SAP NetWeaver Portal.

At first, the thesis will outline the special characteristics of a utility company in order to identify the required functionality and depth of detail of the dashboard.

In addition, the thesis will discuss why it is so important for companies to prepare information in such a way that it can be used as the basis for strategic and operative decisions.

The technical visualisation of the options available to implement a dashboard occurs with the aid of the standard tools of the „SAP Business Explorer Suite“. For the purpose of demonstration, the program Xcelsius of the SAP Business Objects, which can be used to create dashboards, will be presented.

Finally, the thesis will provide a comparison of Web Application Designer and Xcelsius as well as an outlook into the future evolution of SAP front end products.

4

Inhaltsverzeichnis

1.  Einleitung.  9

1.1  Aufbau der Arbeit  10

1.2  Ziel und Abgrenzungen der Arbeit  11

1.3  Eingesetzte Software.  12

2.  Theoretische Grundlagen  13

2.1  Dashboard  13

2.2  Definition des Portalbegriffs  14

2.3  Grundlagen Data Warehouse  15

2.3.1  Charakteristika  15

2.3.2  Metadatenkonzept des SAP NetWeaver BI 7.0  16

2.3.3  Architektur des SAP NetWeaver BI 7.0.  20

2.3.4  ETL-Prozess des SAP NetWeaver BI7.0  21

2.3.5  Datenmodelle  23

2.3.6  Kennzahlenmodellierung  27

2.3.7  Kennzahlensystem.  29

2.4  Reportingtools.  31

2.4.1  Anwendertypen  32

2.4.2  BEx Query Designer  33

2.4.3  Frontend SAP-Tools.  34

2.4.3.1  BEx Analyzer  35

2.4.3.2  BEx Web Application Designer.  36

2.4.4  Weitere Webmöglichkeiten.  38

2.4.4.1  Web Dynpro.  38

2.4.4.2  Business Server Pages.  38

2.5  Vergleich der Standardtools.  38

2.6  Integration in das SAP NetWeaver Portal.  40

2.6.1  Darstellungsmöglichkeiten von BW-Inhalten im Portal  41

2.6.2  Layout-Gestaltung.  41

2.7  Business Objects  42

2.7.1  Xcelsius.  43

2.7.2  Vorteile Xcelsius gegenüber WAD.  45

3.  Konzeption  46

3.1  Projektphasen eines Dashboards  46

3.2  CRISP-Prozessmodell  51

3.3  Prototyp.  52

5

3.4  Probleme eines schlechten Dashboards.  54

4.  Fallbeispiel „Dashboard-Versorger“  55

4.1  Einführung in die Thematik  55

4.1.1  Merkmale eines Energieversorgungsunternehmens.  55

4.1.2  Themenbezug IS-U  55

4.1.3  IS-U Haus.  56

4.1.4  Abrechungsstammdaten  58

4.1.5  Relevanz der Verkaufsstatistik.  60

4.1.6  Bilanzielle Abgrenzung.  60

4.2  Unternehmensstruktur  62

4.3  Projektablauf  63

4.3.1  Projektdefinition.  63

4.3.2  Analyse.  64

4.3.3  Pflichtenheft  65

5.  Realisierung  68

5.1  Einstellungen im Query Designer  68

5.1.1  Elemente einer Query.  68

5.1.2  Anlegen von Kennzahlen  69

5.1.3  Formel  71

5.1.4  Anlegen von Variablen  72

5.1.5  Formatierungsmöglichkeiten in Query-Elementen  76

5.1.6  Bedingungen  80

5.1.7  Anlegen von Exceptions  81

5.1.8  Hierarchien.  83

5.2  Einstellungen im BW  84

5.2.1  Implementierung des Firmenlogos.  84

5.2.2  Sprungziele definieren  85

5.3  Einstellungen im WAD  87

5.3.1  Anlegen eines DataProviders  87

5.3.2  Anlegen von Web Items.  88

5.3.3  Beeinflusste DataProvider.  91

5.3.4  Exception-Visualisierung.  91

5.3.5  Web Template einer Grafik zuordnen.  93

5.3.6  Verwendung von Variablen  93

5.4  Web Template publizieren  93

5.4.1  Publizieren in Rolle.  93

5.4.2  Publizieren ins Portal  95

5.4.2.1  Anlegen von Seiten  97

5.4.2.2  Anlegen von Rollen.  100

5.4.3  URL-iView.  101

5.5  Business Objects  102

6.  Zusammenfassung.  115

6.1  Fazit.  115

6.2  Probleme  115

6.3  Ausblick Business Explorer und Business Objects.  116

7.  Anlagen  118

8.  Abbildungsverzeichnis.  119

9.  Tabellenverzeichnis  122

10.  Quellenverzeichnis.  123

11.  Glossar  127

13.  Stichwortverzeichnis  133

Abkürzungsverzeichnis

AIR Adobe Integrated Runtime BCT Business Content BEx Business Explorer BSP Business Server Pages BW Business Information Warehouse CRISP CRoss Industriy Standard Process CSS Cascading Style Sheets DSO Data Store Object DTP Data Transfer Process DWH Data Warehouse EDM Energy Data Management ER Entity-Relationship KM Knowledge Management IDE Intercompany Data Exchange IFRAME Inlineframe IS-U Industry Solution Utilities IS-U/CCS Industry Solution Utilities/Customer Care Service IS-U-WA Industry Solution Utilities-SAP Waste and Recycling ITS Internet Transaction Server MIME Repository Multimedia Internet Message Extensions Repository PCD Portal Content Directory RS Reporting Services SSO Single Sign-on WAD Web Application Designer

Einleitung

1. Einleitung

Unternehmen haben einen stetig wachsenden Bestand an verschiedenen Informationen aus ihren IT-Systemen. Auf Grundlage dieser Daten müssen zukünftige Entscheidungen getroffen werden. Daher ist es zwingend notwendig diese Daten richtig zu verwalten und aufzubereiten, damit eben diese Entscheidungen auch die richtigen sind.

Ein Unternehmen kann nur durch die richtige Anwendung dieser Informationen auf Dauer überleben. Dabei ist nicht die Menge an Informationen relevant, sondern die vorhandenen Informationen so zu nutzen, dass daraus positiver Erfolg entstehen kann. Der Bibliotheksvorstand der Yale Universität Rutherford schilderte dieses Problem wie folgt:

Da der geplante Unternehmensverlauf mit einer großen Anzahl von Entscheidungen und Maßnahmen verbunden ist, muss die Unternehmensführung die verschiedenen Einflussfaktoren rechtzeitig erkennen und diese als Rahmenbedingungen für die Zielformulierung und Planungen nutzen.

Zahlen liefern Fakten und diese Fakten müssen helfen, eine richtige Frage zu formulieren, um sich an die veränderte Marktsituation richtig anzupassen. Da das Berichtswesen meistens auf Word- oder Excel-Dokumenten beruht, die an die entsprechenden Personengruppen verschickt werden, stellt diese jedoch eine große Herausforderung an das Berichtswesen der Unternehmen dar.

Um profitabel und wettbewerbsfähig agieren zu können, benötigen Unternehmen eine Möglichkeit, die definierte Unternehmensstrategie anhand von festen Größen zu kontrollieren und zu steuern.

Dashboards bieten als Hilfsmittel eine Vernetzung von Auswertungen, um einen Überblick zur aktuellen Situation zu liefern, aber auch um Wechselwirkung von unterschiedlichen Prozessen darzustellen. Somit können kritische Prozesse rechtzeitig identifiziert und entsprechende Entscheidungen und Gegenmaßnahmen eingeleitet werden.

9

Einleitung

1.1 Aufbau der Arbeit

Diese Arbeit ist in sechs Abschnitte unterteilt und setzt sich wie folgt zusammen: Einleitung

In der Einleitung wird zunächst ein Überblick über die definierten Ziele sowie die Abgrenzung des Themas gegeben. Theoretische Grundlagen

Mit den theoretischen Grundlagen soll ein Basiswissen für das Verständnis der Diplomarbeit geschaffen werden. Dabei soll auf den Aufbau und die darin enthaltenen Objekte eines Data Warehouse Systems eingegangen sowie die Begriffsdefinition des Dashboards und des Portals erläutert werden. Das Augenmerk soll vor allem auf den Reportingtools, SAP NetWeaver Portal sowie den Business Objects liegen. Im Abschnitt Reportingtools wird auf die unterschiedlichen Werkzeuge des Business Explorers eingegangen. Dabei werden die Unterschiede zwischen den einzelnen Tools erörtert und deren Möglichkeiten dargestellt.

Des Weiteren wird im Abschnitt SAP NetWeaver Portal erläutert, wie die Daten aus dem BW in das SAP NetWeaver Portal integriert werden und wie diese aufgebaut sind. Im weiteren Verlauf wird bei den Business Objects das Tool Xcelsius vorgestellt und dessen Möglichkeiten bei der Entwicklung eines Dashboards erläutert.

10

Einleitung

Konzeption

Bei der Konzeption werden die Schritte beschrieben, die bei einer allgemeinen Realisierung eines Dashboards notwendig sind. Hierbei werden unter anderem die einzelnen Projektphasen und unterschiedliche Projektmodelle erläutert. Fallbeispiel

Anhand eines Fallbeispiels soll die Konzeption und Entwicklung eines Dashboards realisiert werden. Dazu werden in diesen Abschnitt zunächst Informationen zum Aufbau eines Energieversorgungsunternehmens dargelegt, welche es ermöglichen die spezifischen Anforderungen des Dashboards zu verstehen. Realisierung

Mit Hilfe des Fallbeispiels werden die vorzunehmenden Einstellungen im SAP BW, Business Explorer und im Programm Xcelsius Engage (Business Objects) erläutert, die für die Erstellung eines Dashboards notwendig sind. Zusammenfassung

Die Zusammenfassung setzt sich aus einem Fazit und einer Auflistung der einzelnen Probleme, die während des Projektes aufgetreten sind, zusammen. Dabei wird zusätzlich auf die Lösung der einzelnen Probleme eingegangen, wobei abschließend ein Ausblick auf die Produkte Business Explorer und Business Objects gegeben wird.

1.2 Ziel und Abgrenzungen der Arbeit

Ziel dieser Arbeit ist es, die Möglichkeiten und Funktionen die bei der Entwicklung eines Dashboards in SAP NetWeaver BI 7.0 und SAP Business Objects geboten werden, zu beschreiben.

Aufgrund der zur Entwicklung eines Dashboards eingesetzten Komponenten des SAP NetWeaver 7 BI soll zunächst das Grundkonzept und der Aufbau des SAP NetWeaver BI 7.0 erläutert werden. Hierbei werden lediglich die Grundlagen dieses Konzeptes beschrieben. Die Entwicklung eines Dashboards ist immer unternehmensspezifisch, deshalb soll neben der Entwicklung eines Dashboards auch die Konzeption erörtert werden. Zum Schluss dieser Arbeit soll anhand eines Fallbeispiels aus der Versorgungsindustrie die Konzeption und Entwicklung eines Dashboards und anschließende Integration in das SAP NetWeaver Portal schrittweise durchgeführt und beschrieben werden. Deshalb ist vorgesehen, zunächst die wichtigsten Aspekte der Versorgungsunternehmen zu erläutern. Da die Energiebranche einen großen Wirtschaftszweig ausmacht, würde es den Umfang dieser Arbeit sprengen, wenn auf alle Besonderheiten eines Versorgungsunternehmens eingegangen werden würde.

Einleitung

Des Weiteren wird nicht auf alle Funktionalitäten des Portals eingegangen, da nur die Integration des Dashboards in das SAP NetWeaver Portal im Vordergrund steht.

1.3 Eingesetzte Software

Für die Entwicklung des Dashboards wurde folgende Software verwendet: SAP NetWeaver BI 7.0 (Testsystem der evu.it und rku.it) SAP NetWeaver Portal SAP R/3 mit IS-U-Modul

Das System stellt eine Kopie einer älteren Kundendatenbank dar, welche reale Daten enthält. SAP GUI 640 mit Business Explorer SAP Business Objects (Xcelsius)

Theoretische Grundlagen

2. Theoretische Grundlagen

In diesem Kapitel werden für das bessere Verständnis dieser Arbeit, die Begriffe Dashboard, Portal sowie das Data Warehouse und dessen Eigenschaften erläutert, wobei auf tiefer gehende Details verzichtet wird. Im Vordergrund dieses Kapitels stehen vor allem die Reportingtools, das SAP NetWeaver Portal sowie die Möglichkeiten zur Erstellung eines Dashboards mit Hilfe der Business Objects.

2.1 Dashboard

Mit Hilfe eines Dashboards werden die relevanten Unternehmensdaten aus unterschiedlichen Quellen in einer Sicht zusammengefasst. Dabei sollen Dashboards überschaubar aufgebaut sein, da diese eine Einsicht in wirtschaftliche Zusammenhänge bieten. Somit können Business User und Manager auf einem Blick die Unternehmensleistung aus verschiedenen Gesichtspunkten beobachten, um rechtzeitig Entscheidungen zu treffen. Dadurch können Unternehmensziele besser überwacht, analysiert und gesteuert werden. Die Darstellungsform eines Dashboards ist immer unternehmensspezifisch aufgebaut und muss individuell geplant werden. In der Abbildung 2 ist ein Ausschnitt eines Dashboards für das Management (sogenanntes Management-Cockpit) dargestellt.

Theoretische Grundlagen

Für die Managementebene eignen sich Management-Cockpits, um die Geschäftsführung beispielsweise bei der Gewinnplanung und Gewinnkontrolle zu unterstützen.

2.2 Definition des Portalbegriffs

In den Anfängen des Internets gab es nur einige wenige Seiten und die Anzahl der Benutzer war sehr gering. Im Laufe der Zeit entwickelte sich das Internet jedoch zu einem globalen Netz, was dazu führte, dass die Anzahl der Informationen und der Benutzer extrem stark zunahm. Dies machte die gezielte Suche nach Informationen sehr schwierig. Um den Problem entgegenzuwirken, wurden so genannte Portale entwickelt, die sich aus Themenbereichen mit integrierten Suchfunktionalitäten zusammensetzen.

Richtig populär wurden Portale Mitte der 1990er Jahre, als Unternehmen wie beispielsweise YAHOO damit anfingen, ihren Internetauftritt als Web-Portal darzustellen. Da Portale in unterschiedlichen Bereichen zum Einsatz kommen, existiert im IT-Bereich keine exakte Definition des Portalbegriffs. Im Allgemeinen bieten Portale eine einheitliche Benutzeroberfläche sowie eine gemeinsame Datenbasis. 1

Im folgenden Abschnitt wird auf Web-Portale im Unternehmensbereich eingegangen. Web-Portale dienen in Unternehmen als Collaboration-Plattform und als zentrale Anlaufstelle für den Zugriff auf Prozesse. Des Weiteren bieten Portale die Möglichkeit, Informationen in personalisierten und übersichtlichen Form darzustellen. Beim Zugriff auf das Web-Portal ist keine erneute Anmeldung nötig, da durch das Single-Sign-On die benötigten Anmeldedaten vom Betriebssystem, an das Portal weitergegeben werden. 2

¹ Vgl.[Nicolescu et. al., 2007] S.18

² Vgl. [Gurzki, 2004]

Theoretische Grundlagen

2.3 Grundlagen Data Warehouse

Für das Data Warehouse, gibt es in der Literatur keine allgemein zutreffende Definition. Die verschiedenen Definitionen unterscheiden sich prinzipiell im Nutzen oder im Umfang eines Data Warehouses. Jedoch kann man grob festhalten, dass ein Data Warehouse ein zentraler Punkt ist, an dem die Unternehmensdaten zusammengeführt, aufbereitet und abschließend für die Analyse ausgewertet werden. Ein Data Warehouse ist somit ein Hilfsmittel zur Analyse von Daten, mit denen Prozesse bewertet, kontrolliert und optimiert werden. Aus diesem Grund sollte ein Data Warehouse zweckmäßigerweise als Hilfsmittel für Unternehmensentscheidungen eingesetzt werden.

2.3.1 Charakteristika

Der US-amerikanische Informatiker W.H. Inmon, definierte erstmalig im Jahre 1992 den Begriff des Data Warehouse. Im Laufe der Jahre wurde durch die Verbreitung des DWH dieser Begriff oftmals neu beschrieben.

Die vier von Inmon genannten Merkmale, sind wie folgt zu verstehen: 4

subject-oriented

Subjekt-orientiert bedeutet, dass die Daten des DWH nicht wie bei operativen Systemen keine Relevanz zu den Geschäftsprozessen eines Unternehmens haben, sondern an den relevanten Informationen der Adressaten ausgerichtet sind. Somit erhalten die Entscheider alle relevanten Informationen zu den jeweiligen Prozessen. Integrated

In einem Data Warehouse werden alle relevanten Informationen aus verschiedenen betrieblichen Informationssystemen separiert und inhaltlich integriert zusammengeführt. Dafür müssen die Daten in einer einheitlichen und bereinigten Form dargestellt werden. non-volatile

Die Daten in einem DWH sind nicht volatil, dies bedeutet dass diese nachdem sie abgespeichert sind, nicht mehr verändert werden. Das heißt, dass eine dauerhafte und nicht änderbare Speicherung erfolgt.

³ Zitat aus [Inmon, 1996] S. 33

⁴ Vgl. [Jung et. al., 2000] S.4-5

Theoretische Grundlagen

time-variant

In einem DWH, können anders als bei operativen Informationssystemen, Daten über einen längeren Zeitraum hinweg aufgerufen werden. Dadurch ist es möglich, beispielsweise Trendanalysen über einen längeren Zeitraum zu erstellen.

Wird stattdessen die Definition von Bauer und Günzel betrachtet, kann festgestellt werden, dass diese für den Zweck der Analysefunktion bestimmt ist:

Laut dieser Definition, erfolgt eine Abgrenzung zwischen physischen und logischen Datenbanksystemen. Im Vergleich zu anderen Datenbanksystemen werden die Daten in einem Data Warehouse System üblicherweise nicht verändert. Das heißt, dass die geschriebenen Daten nicht mehr modifiziert werden dürfen. Jedoch können neue Daten übernommen werden, ohne die zuvor verfügbaren Daten zu überschreiben. 6

2.3.2 Metadatenkonzept des SAP NetWeaver BI 7.0

Bei dieser Art von Systemen gestaltet sich die Fehlersuche und Anpassung schwieriger als bei transparent aufgebauten Systemen.

Dieses Problem wird im Business Warehouse mit Hilfe des Metadaten Repository gelöst. Als Metadaten werden „Daten über Daten“ bezeichnet. Bei diesem Datentyp handelt es sich um beschreibende Daten, mit denen Sichten über Daten geschaffen werden. Das Metadaten Repository verwaltet diese Daten in sämtlichen Objekten, wobei ein konsistentes und homogenes Datenmodell über alle Ebenen des DWH-Systems hinweg ermöglicht wird. ⁸ Dazu verwendet das Metadaten-Konzept im BI das Objektkonzept, welches sich an die logische Sicht der Daten richtet. Die Verwaltung der Datenstrukturen erfolgt durch das System, wobei diese von den einzelnen Objekten dargestellt werden. Dadurch kann der Entwickler die

⁵ Zitat aus [Bauer et.al.,2009]S.8

⁶ Vgl. [Bauer et.al.,2009]S.8

⁷ Zitat aus [Mehrwald, 2007] S. 33

⁸ Vgl. [Mehrwald, 2007] S. 33

Theoretische Grundlagen

Gestaltung des Datenflusses und der Datenhaltung frei gestalten, ohne auf die technische Umsetzung im Hintergrund zu achten. Dabei richtet sich das technische Konzept des BW an einem Metadatenmodell aus. Innerhalb dieses Datenmodells werden beschreibende Datenobjekte definiert, die durch das BW technisch in der zugrundliegenden Datenbank umgesetzt werden. Somit werden innerhalb des BW Daten über Daten definiert. Da der Schwerpunkt der Arbeit auf der Entwicklung eines Dashboards liegt, wird auf die Objekte im SAP BW 7.0 nicht detailliert eingegangen.

InfoObjekt

Ein InfoObjekt ist die kleinste Einheit im SAP BW und stellt die Basis der Datenmodellierung dar. Erst wenn die benötigten InfoObjekte angelegt wurden, können die Datenziele definiert werden. Diese können nach dem Bausteinprinzip - ähnlich dem Legosystem - zusammengesetzt werden. Somit bilden InfoObjekte die Grundlage aller InfoProvider wie Data Store Objekte oder InfoCubes. InfoObjekte dienen der Speicherung von Merkmalen, Zeitmerkmalen, Kennzahlen und Einheiten. 9

Die genannten Eigenschaften sind im Einzelnen wie folgt zu verstehen: 10

Merkmale

Merkmale lassen sich zur weiteren Definition in Attribute unterteilen. Als so genannte Attribute werden Merkmale bezeichnet, die in Abhängigkeit zu anderen Merkmalen stehen.

Des Weiteren können Referenz-Merkmale angelegt werden, welche auf Vorlage eines vorhandenen InfoObjekts erzeugt werden. Zeitmerkmale

Bei den Zeitmerkmalen, wird auf die zur Verfügung gestellten Objekte im Business Content (BCT) zurückgegriffen. Im SAP BW können Zeitmerkmale nur unter normalen Merkmals-InfoObjekten angelegt werden. Jedoch stehen diesen Merkmalen die Vorzüge der BCT Zeitmerkmale, wie beispielsweise der Partitionierung und Validierung, nicht zur Verfügung. Kennzahlen

Bei Kennzahlen, handelt es sich um quantifizierende Größen, wie beispielsweise Preis oder Menge. Mit Hilfe von mathematischen Operationen können diese manipuliert werden, wobei jeder Kennzahl ein entsprechendes Merkmal zu geordnet werden muss.

⁹ Vgl. [Mehrwald, 2007] S.59

¹⁰ Vgl. [Hahne, 2005] S.43-44

Theoretische Grundlagen

Einheiten

Die Einheiten in einem InfoObjekt besitzen als Grundlage vorhandene Objekte, die als Referenz auf Währungen und Mengeneinheiten zeigen.

InfoProvider

Als InfoProvider ist ein Datenmodell zu verstehen, auf dessen Datenbasis spätere Analyseprozesse, mit Hilfe von Queries, durchgeführt werden. Im Sinne des BW ist darunter ein DataMart ¹¹ anzusehen, in dem Daten für Auswertungen vorgehalten oder bereitgestellt werden. Je nachdem, ob der InfoProvider Daten speichert oder nicht, wird von einem physischen oder virtuellen InfoProvider gesprochen. Da der virtuelle InfoProvider selber keine Daten bereitstellt, wird der Zugriff auf andere Daten (physische InfoProvider, DSO, etc.) ermöglicht. Dabei arbeitet der InfoProvider nach dem Join-Prinzip. ¹² Das heißt, dass nur die Datensätze berücksichtigt werden, die von den Tabellen her gleiche Eigenschaften besitzen.

Die Art des Info-Provider ist für die Abfragedefinition nicht von Bedeutung, da diese gleichartig behandelt werden. Jedoch wirken sich die verschiedenen Arten der Info-Provider, unterschiedlich stark auf die Performance aus.

Data Store Objekte

Data Store Objekte werden zur Aufnahme und Zusammenführung von bereinigten und konsolidierten Bewegungsdaten verwendet. Bei einem Data Store Objekt werden die Daten in transparente, flache Datenbanktabellen abgelegt. Dieser kann zusätzlich auf atomarer Ebene für Analysen (z.B. für Abrechnungsbelegzeilen) verwendet werden, die mit Hilfe des BEx Query Designers ausgewertet werden können. 13

InfoCubes

InfoCubes stellen die wichtigsten Objekte für die Analysen und Berichte im SAP BW-System dar. Die Organisation der Daten erfolgt multidimensional, somit sind InfoCubes auf OLAP Basis ausgerichtet. Innerhalb der InfoCube werden über InfoObjekte Kennzahlen und Merkmale erstellt. Dabei werden verschiedene Arten von InfoCubes unterschieden, die Basis-Cubes und die Remote-Cubes.

¹¹ Unter einem DataMart wird eine Datenbasis, die sich auf einen Unternehmensbereich oder die Kopie eines

Teilaspekts eines Data Warehouses bezieht, bezeichnet. Somit wird ein DataMart für einen gewissen Bereich bzw. eine Anwendung entwickelt.

¹² Vgl. [SAPJoin, 2009]

¹³ Vgl. [Mehrwald, 2007] S.98

Theoretische Grundlagen

Bei den Basis-Cubes erfolgt eine physische Speicherung der Daten, wobei sich diese aus mehreren relationalen Tabellen zusammensetzt, die nach dem Starschema verknüpft sind. Bei einem Remote-Cube sind die Daten extern im Quellsystem gespeichert. Remote-Cubes werden für das Bereitstellen kleinerer Datenbestände aus dem Quellsystem für das Reporting verwendet. Der Nachteil des Remote-Cubes liegt bei der Performance zur Ausführungszeit, da das Laden der Daten von einem externen System zur Belastung führt. 14

MultiProvider

In der Praxis werden häufig verschieden Gesichtspunkte benötigt, die auf der Basis eines InfoCubes nicht dargestellt werden können. Deshalb werden MultiProvider im BW verwendet. Als MultiProvider wird die Zusammensetzung aus mehreren InfoProvidern bezeichnet, die Daten für das Reporting und die Analyse bereitstellen. Da der MultiProvider selbst keine Daten besitzt, setzen sich seine Daten aus den jeweiligen InfoProvidern zusammen. Er stellt lediglich die verwendeten Quelldaten bereit. Der MultiProvider arbeitet nach dem Union-Prinzip. Das heißt, dass alle Datensätze der verschiedenen Quellen berücksichtigt werden. ¹⁵ Um Mehrdeutigkeiten sowie redundante Daten und Fehlerberechnungen zu vermeiden, muss für jedes verwendete Merkmal und für deren Kennzahlen ein entsprechender InfoProvider ausgewählt werden.

In Abbildung 3 sind die unterschiedlichen InfoCube Typen zusammengefasst.

¹⁴ Vgl.[Hahne, 2005]S.48

¹⁵ Vgl. [Egger et al., 2005] S.52

Theoretische Grundlagen

InfoSets

InfoSets enthalten, wie MultiProvider, selbst keine Daten. Im Gegensatz zu MultiProvider werden bei InfoSets die Objekte mittels Join-Abfragen zusammengeführt und für das Reporting zur Verfügungen gestellt. Da auf Grundlage der Join-Abfragen die Performance nicht optimal ist, finden InfoSets kaum Anwendung beim Reporting. 16

2.3.3 Architektur des SAP NetWeaver BI 7.0 17

Bei dem Business Information Warehouse handelt es sich um eine Data Warehouse-Lösung der SAP, die Daten aus unterschiedlichen Quellen zusammenführt, integriert und anschließend verdichtet. Daher lässt sich das SAP BW System in drei Stufen unterteilen: die Datenbereitstellungsebene, die Datenhaltungsebene und die Informationsanalyse. In der nachfolgenden Abbildung ist der Aufbau eines DWH-Systems graphisch dargestellt, wobei im folgenden Abschnitt auf die Stufen näher eingegangen wird.

Datenbereitstellungsebene

Auf dieser Ebene werden die Daten aus unterschiedlichen Datenquellen (SAP-Systeme, Fremdsysteme, Dateien) extrahiert sowie transformiert und in das DWH geladen.

¹⁶ Vgl.[Hahne, 2005]S.50

¹⁷ Vgl. [Seemann et. al., 2001] S.25

Theoretische Grundlagen

Datenhaltungsebene

Mit der Datenhaltungsebene erfolgt die dauerhafte Speicherung der Daten, wobei diese in multidimensionalen Strukturen abgelegt werden. Je nach Verwendungszweck werden die Daten in unterschiedlichen Datenmodellen gehalten, die in weiteren Verlauf dieses Kapitels näher erläutert werden.

Informationsanalyse

In dieser Ebene werden die Daten für die Auswertung aufbereitet und präsentiert.

2.3.4 ETL-Prozess des SAP NetWeaver BI 7.0

Im DWH wird durch den Datenfluss bestimmt, wie die Übertragung der Daten vom Quellsystem zum BW System verläuft. Des Weiteren legt der Datenfluss fest, wie die Daten aus dem Quellsystem vereinheitlicht und umgewandelt werden, um diese anschließend für Analyse-und Berichtzwecke zu verwenden. Da durch Unternehmensprozesse eine Vielzahl an Anforderungen gestellt wird, bietet das Datenflusskonzept eine große Anzahl an Ausgestaltungsmöglichkeiten.

In der Abbildung 5 wird der Datenfluss in der Architektur des SAP BW 7.0, mit den darin enthaltenen BI-Objekten, dargestellt. Wie bereits im Abschnitt 2.3.3 Architektur des SAP NetWeaver BI 7.0 erwähnt, lässt sich das SAP BW System in drei Stufen unterteilen, die Datenbereitstellungsebene, die Datenhaltungsebene und die Informationsanalyse. Der ETL-Prozess bezieht sich auf die Datenbereitstellungsebene und Datenhaltungsebene.

Theoretische Grundlagen

Datenbereitstellungsebene

In der Datenbereitstellungsebene werden mit Hilfe von Quellsystemen dem SAP BW Daten zur Verfügung gestellt. Hierbei können unteranderem Quellsysteme wie beispielsweise SAP-Systeme, andere ERP-Systeme, BW-Systeme oder Flat Files als Datenquelle verwendet werden. Bei diesem Prozess wird mit dem InfoPackage bestimmt, welche Quelldaten für eine DataSource in die PSA geladen werden, bevor die weitere Verarbeitung im BW stattfindet kann. Hierbei können Selektionsbedingungen durchgeführt werden, um die Datenmenge zu beschränken. 18

Datenhaltungsebene

Innerhalb dieser Schicht werden der DataSource die einzelnen Quellsysteme zugeordnet, welche dann die Metadaten abbildet. Bei einer DataSource werden die Daten aus den Quellsystemen extrahiert und in die PSA übertragen. Die PSA ist ein temporärer Zwischenspeicher, der die Daten vom Quellsystem in transparente Tabellen ablegt und zur weiteren Verarbeitung ihre Qualität prüft und bei Bedarf diese ändert oder löscht. Die Ladeperformance wird über die PSA verbessert, indem die beiden Prozesse zum Laden und Weiterverarbeiten der Daten getrennt werden. 19

Anschließend wird durch die Transformation die Zuordnung des Datenflusses vom Quell- zum Zielsystem gesteuert. Die sogenannte Transformation löst im SAP BW 7.0 die Übertragungsbzw. Fortschreibungsregeln der älteren BW-Versionen ab. Die Aufgabe einer Transformation liegt darin, die Daten einer Quellstruktur zu konsolidieren, zu bereinigen und in das Zielformat zu überführen. 20

Bei diesem Prozess steuert der Datentransferprozess (DTP) den Datenfluss, unter Anwendung von Transformationen und Filtern, von einem Quellobjekt (DataSource) zu einem Zielobjekt (InfoProvider).

Das InfoPackage aus dem SAP BW 3.x wird zum Teil durch den DTP ersetzt. Ab der SAP BW 7.0 Version ist das InfoPackage nur für die Übertragung der Daten bis zur PSA verantwortlich. Somit steuert der DTP den Datenfluss zwischen den Objekten im BW-System. Aufgrund des parallelen Datenladens wird die Performance gesteigert. 21

¹⁸ Vgl. [Egger et al., 2005] S.47

¹⁹ Vgl. [Hahne, 2005] S.44-45

²⁰ Vgl. [Mehrwald, 2007] S. 439

²¹ Vgl. [Mehrwald, 2007] S.469

Theoretische Grundlagen

Im Datenflusskonzept werden die InfoSources nur verwendet, wenn eine komplexe Transformation stattfindet. Das heißt, dass die InfoSource nur bei einer Vielzahl von nacheinander geschalteten Transformationen zum Einsatz kommt.

Abschließend werden die Daten in den InfoProvider dargestellt, welche die Basis für die Informationsanalyseebene bildet.

2.3.5 Datenmodelle

Um die Datenmodelle eines Data Warehouse Systems besser zu verstehen, wird zunächst eine Abgrenzung zwischen OLTP und OLAP-Systemen dargestellt.

Beim Online Transaction Processing (OLTP) werden Daten transaktional innerhalb einer Datenbank gespeichert und abgerufen. OLTP-Systeme kommen daher hauptsächlich in prozessorientierten Bereichen zum Einsatz. Das Datenbankdesign richtet sich hier nach einer granularen Form der Speicherung, wobei das Datenbankschema der 1. 2. und 3. Normalform angepasst wird.

Den Gegensatz dazu bildet das „Online Analytical Processing“. Auch hier werden Daten in einer relationalen Datenbank gespeichert, allerdings mit der Zielsetzung, leistungsstarke Analysen auf größeren Datenbeständen durchführen zu können. Hier kommen spezielle Modellierungsmethoden zum Einsatz (Star- oder Snowflake-Schema). 22

Mit Hilfe eines Datenmodells wird ein Abbild der Realität in einer datentechnischen Form geschaffen.

Ein Data Warehouse System enthält üblicherweise folgende Datenmodellkonzepte: ER-Diagramm nach Normalform Flache Struktur Star-Schema Snowflake-Schema

Die Unterscheidung der Konzepte erfolgt hinsichtlich der Komplexität, Performance und ob es sich bei den Daten um historisierte oder aktuelle Daten handelt. Aufgrund der unterschiedlichen Ziele der Datenmodelle, muss deren Aufbau in Bezug auf die betrieblichen Anforderungen stehen. Hierbei geht es um Daten, die beim Übergang ins Data Warehouse kaum oder im geringen Maße modifiziert werden. Als Grundlage für die Datenmodellierung dienen

²² Vgl. [Bauer et.al.,2009] S.47

Theoretische Grundlagen

hauptsächlich Kennzahlen und deren Merkmale, diese Merkmale lassen sich in Merkmale und Attribute einteilen. 23

ER-Diagramm

Die Daten eines OLTP-Systems (z.B. Betriebsdatenerfassungssystem) werden mit Hilfe von transaktionalen Strukturen in einer relationalen Datenbank abgelegt. Beim Einsatz solcher Datenbanken wird der Versuch angestrebt, weitestgehend auf die Normalisierung ²⁵ innerhalb des Datenbestandes zu achten. Dazu wird ein Datenbankschema entwickelt, welches darauf ausgelegt ist, Daten weitestgehend zu gruppieren und in einen semantischen Kontext zu setzen.

Ein Beispiel einer solchen Trennung wäre die Aufteilung von Rechnungsbelegen in eine Tabelle für die Kopfdaten einer Rechnung (z.B. Rechnungsdatum, Sachbearbeiter, etc.) und in eine Tabelle für die Positionen (z.B. Materialnummer, Einzelpreis, etc.). Die Verknüpfung findet über die Rechnungsnummer statt.

Bei den für die Analyse benötigten Daten, greifen OLAP-Tools auf direktem Wege auf die Transaktionsdaten im OLTP System zu. Dies verursacht neben eingeschränkten Analysemöglichkeiten eine schlechte Performance. Bedingt dadurch, dass analytische Anwendungen auf die Ergebnisse mehrerer Transaktionen zurückgreifen, entsteht eine schlechte Performance, da mit einzelnen Transaktionen keine verwertbaren Informationen erzeugt werden

können. Aufgrund der oben genannten Nachteile werden OLTP-Systeme in neueren Data-

²³ Vgl.[Mehrwald, 2007] S.47

²⁴ In Anlehnung an [Mehrwald, 2007] S.50

²⁵ Unter Normalisierung wird die Schrittweise Aufschaltung einer Relation in mehreren kleineren Relationen, mit dem Ziel der Redundanzminimierung verstanden. Bei der Normalisierung spielen die Abhängigkeiten zwischen den Tabellenattributen eine wichtige Rolle.

Theoretische Grundlagen

Warehouse-Systemen nur noch zum einmaligen Auslesen von Daten verwendet. Diese werden dann in spezielle Datenmodelle (flache Strukturen, Star-Schema, Snowflake-Schema) umgewandelt, welche für analytische Anwendungen entwickelt wurden. ²⁶ Die hier genannten Datenmodelle werden in den nächsten Abschnitt ausführlicher erläutert.

Flache Strukturen 27

Mit einer flachen Struktur können analytische Daten von transaktionalen Daten getrennt werden. Dabei ist die Struktur der Daten analog zu den PSA-Daten und Data Store Objekten. Da die Daten in einer aggregierten Form gespeichert werden, kann bei Analysen auf eine kleine Datenmenge zugegriffen werden.

Innerhalb einer Tabelle werden die Daten in einer nicht normalisierten Form abgelegt, um diese in einer detailierte und einfachere Form zu bringen.

Eine flache Struktur dient in erster Linie dem Datenaustausch und bietet den Vorteil, dass diese unabhängig von relationalen Datenbanken ist und als Flat File abgelegt werden kann.

Star-Schema 29

²⁶ Vgl. [Mehrwald, 2007] S.49-S.50

²⁷ Vgl. [Mehrwald, 2007] S.51-53

²⁸ In Anlehnung an [Mehrwald, 2007] S.51

²⁹ Vgl. [Mehrwald, 2007] S.54

³⁰ In Anlehnung an [Mehrwald, 2007] S.54

Theoretische Grundlagen

Neben den flachen Strukturen werden auch beim Star-Schema die Daten historisch dargestellt. Da das Star-Schema ein relationales Datenmodell ist, ist es auf die Leistungsmerkmale dieses Modells angepasst. Somit ergeben sich keine Performancenachteile, wie es bei den flachen Strukturen der Fall ist, lediglich ergibt sich bei den Tabellen eine Redundanzbehaftung, wie bei der flachen Struktur.

Das Star-Schema zeichnet sich dadurch aus, dass die Daten auf mehreren Tabellen implementiert werden. Zu einem auf Dimensionstabellen, die relativ statische Merkmale beinhalten, und zum anderen die Faktentabelle, die Kennzahlen zu den Dimensionstabellen enthält. Dabei ist die Struktur des Star-Schemas analog zu einem InfoCube aufgebaut.

Snowflake-Schema 31

Das Snowflake-Schema ergänzt das Star-Schema um weitere Stammdatentabellen. Dabei wird die Option geboten, Daten in den Stammdatentabellen abzulegen, wo diese dann relationale Verknüpfungen mit den Merkmalen in den Dimensionstabellen enthalten. Im Vergleich zu den oben genannten Modellen kann das Snowflake-Schema zusätzlich zu der historisierten Darstellung von Attributen auch aktuelle Gegenwartsdaten darstellen. Ein weiterer Vorteil ist die Normalisierung der Dimensionstabellen, da dadurch der Speicherplatzverbrauch reduziert wird.

³¹ Vgl. [Mehrwald, 2007] S.56

³² In Anlehnung an [Mehrwald, 2007] S.56

Theoretische Grundlagen

Vergleich der Datenmodelle

2.3.6 Kennzahlenmodellierung

Bei der Kennzahlenmodellierung wird zwischen den folgenden zwei Modellierungstechniken unterschieden:

- Kennzahlenmodell

- Kontenmodell

Kennzahlenmodell

Im Kennzahlenmodell wird für jede Kennzahl ein eigenes Feld vorgesehen. Diese Felder werden bei jedem Datensatz aufgelistet, unabhängig davon, ob dieser Daten für das Feld der Kennzahl enthält oder nicht.

Um das Kennzahlenmodell anwenden zu können, muss eine einheitliche Struktur der anzuzeigenden Kennzahlen vorhanden sein. Zu einem hohen Ressourcenverbrauch kann es kommen, wenn aus einer Vielzahl von Kennzahlen nur eine geringe Anzahl in einem Datensatz verwendet wird.

³³ In Anlehnung an [Mehrwald, 2007] S.56

³⁴ In Anlehnung an [Mehrwald, 2007] S.53