Leseprobe
Inhaltsverzeichnis
1. Einleitung
1.1 Aufbau der Arbeit
1.2 Ziel und Abgrenzungen der Arbeit
1.3 Eingesetzte Software
2. Theoretische Grundlagen
2.1 Dashboard
2.2 Definition des Portalbegriffs
2.3 Grundlagen Data Warehouse
2.3.1 Charakteristika
2.3.2 Metadatenkonzept des SAP NetWeaver BI 7.0
2.3.3 Architektur des SAP NetWeaver BI 7.0
2.3.4 ETL-Prozess des SAP NetWeaver BI7.0
2.3.5 Datenmodelle
2.3.6 Kennzahlenmodellierung
2.3.7 Kennzahlensystem
2.4 Reportingtools
2.4.1 Anwendertypen
2.4.2 BEx Query Designer
2.4.3 Frontend SAP-Tools
2.4.3.1 BEx Analyzer
2.4.3.2 BEx Web Application Designer
2.4.4 Weitere Webmoglichkeiten
2.4.4.1 Web Dynpro
2.4.4.2 Business Server Pages
2.5 Vergleich der Standardtools
2.6 Integration in das SAP NetWeaver Portal
2.6.1 Darstellungsmoglichkeiten von BW-Inhalten im Portal
2.6.2 Layout-Gestaltung
2.7 Business Objects
2.7.1 Xcelsius
2.7.2 Vorteile Xcelsius gegenuber WAD
3. Konzeption
3.1 Projektphasen eines Dashboards
3.2 CRISP-Prozessmodell
3.3 Prototyp
3.4 Probleme eines schlechten Dashboards
4. Fallbeispiel „Dashboard-Versorger“
4.1 Einfuhrung in die Thematik
4.1.1 Merkmale eines Energieversorgungsunternehmens
4.1.2 Themenbezug IS-U
4.1.3 IS-U Haus
4.1.4 Abrechungsstammdaten
4.1.5 Relevanz der Verkaufsstatistik
4.1.6 Bilanzielle Abgrenzung
4.2 Unternehmensstruktur
4.3 Projektablauf
4.3.1 Projektdefinition
4.3.2 Analyse
4.3.3 Pflichtenheft
5. Realisierung
5.1 Einstellungen im Query Designer
5.1.1 Elemente einer Query
5.1.2 Anlegen von Kennzahlen
5.1.3 Formel
5.1.4 Anlegen von Variablen
5.1.5 Formatierungsmoglichkeiten in Query-Elementen
5.1.6 Bedingungen
5.1.7 Anlegen von Exceptions
5.1.8 Hierarchien
5.2 Einstellungen im BW
5.2.1 Implementierung des Firmenlogos
5.2.2 Sprungziele definieren
5.3 Einstellungen im WAD
5.3.1 Anlegen eines DataProviders
5.3.2 Anlegen von Web Items
5.3.3 Beeinflusste DataProvider
5.3.4 Exception-Visualisierung
5.3.5 Web Template einer Grafik zuordnen
5.3.6 Verwendung von Variablen
5.4 Web Template publizieren
5.4.1 Publizieren in Rolle
5.4.2 Publizieren ins Portal
5.4.2.1 Anlegen von Seiten
5.4.2.2 Anlegen von Rollen
5.4.3 URL-iView
5.5 Business Objects
6. Zusammenfassung
6.1 Fazit
6.2 Probleme
6.3 Ausblick Business Explorer und Business Objects
7. Anlagen
8. Abbildungsverzeichnis
9. Tabellenverzeichnis
10. Quellenverzeichnis
11. Glossar
13. Stichwortverzeichnis
Abkurzungsverzeichnis
Abbildung in dieser Leseprobe nicht enthalten
1. Einleitung
Unternehmen haben einen stetig wachsenden Bestand an verschiedenen Informationen aus ihren IT-Systemen. Auf Grundlage dieser Daten mussen zukunftige 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 uberleben. 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 Universitat Rutherford schilderte dieses Problem wie folgt:
„Wir ertrinken in einer Informationsflut und hungern trotzdem nach Wissen“ [Rutherford D.Rogers, Bibliothesvorstand, Yale, 1985]
Da der geplante Unternehmensverlauf mit einer groBen Anzahl von Entscheidungen und MaBnahmen verbunden ist, muss die Unternehmensfuhrung die verschiedenen Einflussfaktoren rechtzeitig erkennen und diese als Rahmenbedingungen fur die Zielformulierung und Planungen nutzen.
Zahlen liefern Fakten und diese Fakten mussen helfen, eine richtige Frage zu formulieren, um sich an die veranderte Marktsituation richtig anzupassen. Da das Berichtswesen meistens auf Word- oder Excel-Dokumenten beruht, die an die entsprechenden Personengruppen verschickt werden, stellt diese jedoch eine groBe Herausforderung an das Berichtswesen der Unternehmen dar.
Um profitabel und wettbewerbsfahig agieren zu konnen, benotigen Unternehmen eine Moglichkeit, die definierte Unternehmensstrategie anhand von festen GroBen zu kontrollieren und zu steuern.
Dashboards bieten als Hilfsmittel eine Vernetzung von Auswertungen, um einen Uberblick zur aktuellen Situation zu liefern, aber auch um Wechselwirkung von unterschiedlichen Prozessen darzustellen. Somit konnen kritische Prozesse rechtzeitig identifiziert und entsprechende Entscheidungen und GegenmaBnahmen eingeleitet werden.
1.1 Aufbau der Arbeit
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 1: Gliederung der Arbeitsschritte
Diese Arbeit ist in sechs Abschnitte unterteilt und setzt sich wie folgt zusammen:
- Einleitung
In der Einleitung wird zunachst ein Uberblick uber die definierten Ziele sowie die Abgrenzung des Themas gegeben.
- Theoretische Grundlagen
Mit den theoretischen Grundlagen soll ein Basiswissen fur das Verstandnis 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 erlautert 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 erortert und deren Moglichkeiten dargestellt. Des Weiteren wird im Abschnitt SAP NetWeaver Portal erlautert, 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 Moglichkeiten bei der Entwicklung eines Dashboards erlautert.
- 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 erlautert.
- Fallbeispiel
Anhand eines Fallbeispiels soll die Konzeption und Entwicklung eines Dashboards realisiert werden. Dazu werden in diesen Abschnitt zunachst Informationen zum Aufbau eines Energieversorgungsunternehmens dargelegt, welche es ermoglichen 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) erlautert, die fur die Erstellung eines Dashboards notwendig sind.
- Zusammenfassung
Die Zusammenfassung setzt sich aus einem Fazit und einer Auflistung der einzelnen Probleme, die wahrend des Projektes aufgetreten sind, zusammen. Dabei wird zusatzlich auf die Losung der einzelnen Probleme eingegangen, wobei abschlieBend 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 Moglichkeiten 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 zunachst das Grundkonzept und der Aufbau des SAP NetWeaver BI 7.0 erlautert 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 erortert werden.
Zum Schluss dieser Arbeit soll anhand eines Fallbeispiels aus der Versorgungsindustrie die Konzeption und Entwicklung eines Dashboards und anschlieBende Integration in das SAP NetWeaver Portal schrittweise durchgefuhrt und beschrieben werden. Deshalb ist vorgesehen, zunachst die wichtigsten Aspekte der Versorgungsunternehmen zu erlautern. Da die Energiebranche einen groBen Wirtschaftszweig ausmacht, wurde es den Umfang dieser Arbeit sprengen, wenn auf alle Besonderheiten eines Versorgungsunternehmens eingegangen werden wurde.
Des Weiteren wird nicht auf alle Funktionalitaten des Portals eingegangen, da nur die Integration des Dashboards in das SAP NetWeaver Portal im Vordergrund steht.
1.3 Eingesetzte Software
Fur 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 alteren Kundendatenbank dar, welche reale Daten enthalt.
- SAP GUI 640 mit Business Explorer
- SAP Business Objects (Xcelsius)
2. Theoretische Grundlagen
In diesem Kapitel werden fur das bessere Verstandnis dieser Arbeit, die Begriffe Dashboard, Portal sowie das Data Warehouse und dessen Eigenschaften erlautert, wobei auf tiefer gehende Details verzichtet wird. Im Vordergrund dieses Kapitels stehen vor allem die Reportingtools, das SAP NetWeaver Portal sowie die Moglichkeiten 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 uberschaubar aufgebaut sein, da diese eine Einsicht in wirtschaftliche Zusammenhange bieten. Somit konnen Business User und Manager auf einem Blick die Unternehmensleistung aus verschiedenen Gesichtspunkten beobachten, um rechtzeitig Entscheidungen zu treffen. Dadurch konnen Unternehmensziele besser uberwacht, 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 fur das Management (sogenanntes Management-Cockpit) dargestellt.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 2: Management-Cockpit
Fur die Managementebene eignen sich Management-Cockpits, um die Geschaftsfuhrung beispielsweise bei der Gewinnplanung und Gewinnkontrolle zu unterstutzen.
2.2 Definition des Portalbegriffs
In den Anfangen 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 fuhrte, 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 Suchfunktionalitaten zusammensetzen.
Richtig popular 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 Benutzerober- flache 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 fur den Zugriff auf Prozesse. Des Weiteren bieten Portale die Moglichkeit, Informationen in personalisierten und ubersichtlichen Form darzustellen. Beim Zugriff auf das Web-Portal ist keine erneute Anmeldung notig, da durch das Single-Sign-On die benotigten Anmeldedaten vom Betriebssystem, an das Portal weitergegeben werden.[2]
Abbildung in dieser Leseprobe nicht enthalten
2.3 Grundlagen Data Warehouse
Fur 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 zusammengefuhrt, aufbereitet und abschlieBend fur 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 zweckmaBigerweise als Hilfsmittel fur Unternehmens- entscheidungen 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.
“A data warehouse is a subject-oriented integrated, non-volatile, and time-variant collection of data in support of management’s decisions.”[3]
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 Geschaftsprozessen 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 zusammengefuhrt. Dafur mussen 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 verandert werden. Das heiBt, dass eine dauerhafte und nicht anderbare Speicherung erfolgt.
time-variant
In einem DWH, konnen anders als bei operativen Informationssystemen, Daten uber einen langeren Zeitraum hinweg aufgerufen werden. Dadurch ist es moglich, beispielsweise Trendanalysen uber einen langeren Zeitraum zu erstellen.
Wird stattdessen die Definition von Bauer und Gunzel betrachtet, kann festgestellt werden, dass diese fur den Zweck der Analysefunktion bestimmt ist:
„Ein Data-Warehouse ist eine physische Datenbank, die eine integrierte Sicht auf beliebig Daten darstellt, um Analysen zu ermoglichen. “[5]
Laut dieser Definition, erfolgt eine Abgrenzung zwischen physischen und logischen Datenbanksystemen. Im Vergleich zu anderen Datenbanksystemen werden die Daten in einem Data Warehouse System ublicherweise nicht verandert. Das heiBt, dass die geschriebenen Daten nicht mehr modifiziert werden durfen. Jedoch konnen neue Daten ubernommen werden, ohne die zuvor verfugbaren Daten zu uberschreiben.[6]
2.3.2 Metadatenkonzept des SAP NetWeaver BI 7.0
„Data-Warehouse-Systeme geraten schnell zu einer „Black Box“, wenn die verwendeten Datenstrukturen und Datenflusse nicht transparent gestaltet sind.“[7]
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 gelost. Als Metadaten werden „Daten uber Daten“ bezeichnet. Bei diesem Datentyp handelt es sich um beschreibende Daten, mit denen Sichten uber Daten geschaffen werden. Das Metadaten Repository verwaltet diese Daten in samtlichen Objekten, wobei ein konsistentes und homogenes Datenmodell uber alle Ebenen des DWH-Systems hinweg ermoglicht wird.[8] 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
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 uber 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 benotigten InfoObjekte angelegt wurden, konnen die Datenziele definiert werden. Diese konnen nach dem Bausteinprinzip - ahnlich 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 Abhangigkeit zu anderen Merkmalen stehen.
Des Weiteren konnen Referenz-Merkmale angelegt werden, welche auf Vorlage eines vorhandenen InfoObjekts erzeugt werden.
Zeitmerkmale
Bei den Zeitmerkmalen, wird auf die zur Verfugung gestellten Objekte im Business Content (BCT) zuruckgegriffen. Im SAP BW konnen Zeitmerkmale nur unter normalen Merkmals-InfoObjekten angelegt werden. Jedoch stehen diesen Merkmalen die Vorzuge der BCT Zeitmerkmale, wie beispielsweise der Partitionierung und Validierung, nicht zur Verfugung.
Kennzahlen
Bei Kennzahlen, handelt es sich um quantifizierende GroBen, wie beispielsweise Preis oder Menge. Mit Hilfe von mathematischen Operationen konnen diese manipuliert werden, wobei jeder Kennzahl ein entsprechendes Merkmal zu geordnet werden muss.
Einheiten
Die Einheiten in einem InfoObjekt besitzen als Grundlage vorhandene Objekte, die als Referenz auf Wahrungen und Mengeneinheiten zeigen.
InfoProvider
Als InfoProvider ist ein Datenmodell zu verstehen, auf dessen Datenbasis spatere Analyseprozesse, mit Hilfe von Queries, durchgefuhrt werden.
Im Sinne des BW ist darunter ein DataMart[11] anzusehen, in dem Daten fur 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.) ermoglicht. Dabei arbeitet der InfoProvider nach dem Join-Prinzip.[12] Das heiBt, dass nur die Datensatze berucksichtigt werden, die von den Tabellen her gleiche Eigenschaften besitzen.
Die Art des Info-Provider ist fur 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 Zusammenfuhrung von bereinigten und konsolidierten Bewegungsdaten verwendet. Bei einem Data Store Objekt werden die Daten in transparente, flache Datenbanktabellen abgelegt. Dieser kann zusatzlich auf atomarer Ebene fur Analysen (z.B. fur Abrechnungsbelegzeilen) verwendet werden, die mit Hilfe des BEx Query Designers ausgewertet werden konnen.[13]
InfoCubes
InfoCubes stellen die wichtigsten Objekte fur 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 uber InfoObjekte Kennzahlen und Merkmale erstellt. Dabei werden verschiedene Arten von InfoCubes unterschieden, die Basis-Cubes und die Remote-Cubes.
Bei den Basis-Cubes erfolgt eine physische Speicherung der Daten, wobei sich diese aus mehreren relationalen Tabellen zusammensetzt, die nach dem Starschema verknupft sind.
Bei einem Remote-Cube sind die Daten extern im Quellsystem gespeichert.
Remote-Cubes werden fur das Bereitstellen kleinerer Datenbestande aus dem Quellsystem fur das Reporting verwendet. Der Nachteil des Remote-Cubes liegt bei der Performance zur Ausfuhrungszeit, da das Laden der Daten von einem externen System zur Belastung fuhrt.[14]
MultiProvider
In der Praxis werden haufig verschieden Gesichtspunkte benotigt, die auf der Basis eines InfoCubes nicht dargestellt werden konnen. Deshalb werden MultiProvider im BW verwendet. Als MultiProvider wird die Zusammensetzung aus mehreren InfoProvidern bezeichnet, die Daten fur 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 heiBt, dass alle Datensatze der verschiedenen Quellen berucksichtigt werden.[15] Um Mehrdeutigkeiten sowie redundante Daten und Fehlerberechnungen zu vermeiden, muss fur jedes verwendete Merkmal und fur deren Kennzahlen ein entsprechender InfoProvider ausgewahlt werden.
In Abbildung 3 sind die unterschiedlichen InfoCube Typen zusammengefasst.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 3: Arten von InfoCubes
InfoSets
InfoSets enthalten, wie MultiProvider, selbst keine Daten. Im Gegensatz zu MultiProvider werden bei InfoSets die Objekte mittels Join-Abfragen zusammengefuhrt und fur das Reporting zur Verfugungen 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
Bei dem Business Information Warehouse handelt es sich um eine Data Warehouse-Losung der SAP, die Daten aus unterschiedlichen Quellen zusammenfuhrt, integriert und anschlieBend verdichtet. Daher lasst 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 naher eingegangen wird.[17]
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 4: Architektur des SAP NetWeaver BI 7.0
Datenbereitstellungsebene
Auf dieser Ebene werden die Daten aus unterschiedlichen Datenquellen (SAP-Systeme, Fremdsysteme, Dateien) extrahiert sowie transformiert und in das DWH geladen.
Datenhaltungsebene
Mit der Datenhaltungsebene erfolgt die dauerhafte Speicherung der Daten, wobei diese in multidimensional Strukturen abgelegt werden. Je nach Verwendungszweck werden die Daten in unterschiedlichen Datenmodellen gehalten, die in weiteren Verlauf dieses Kapitels naher erlautert werden.
Informationsanalyse
In dieser Ebene werden die Daten fur die Auswertung aufbereitet und prasentiert.
2.3.4 ETL-Prozess des SAP NetWeaver BI 7.0
Im DWH wird durch den Datenfluss bestimmt, wie die Ubertragung der Daten vom Quellsystem zum BW System verlauft. Des Weiteren legt der Datenfluss fest, wie die Daten aus dem Quellsystem vereinheitlicht und umgewandelt werden, um diese anschlieBend fur Analyse- und Berichtzwecke zu verwenden. Da durch Unternehmensprozesse eine Vielzahl an Anforderungen gestellt wird, bietet das Datenflusskonzept eine groBe Anzahl an Ausgestaltungsmoglichkeiten.
In der Abbildung 5 wird der Datenfluss in der Architektur des SAP BW 7.0, mit den darin enthaltenen Bl-Objekten, dargestellt. Wie bereits im Abschnitt 2.3.3 Architektur des SAP NetWeaver BI 7.0 erwahnt, lasst 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.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 5: Datenflusskonzept des SAP NetWeaver BI 7.0
Datenbereitstellungsebene
In der Datenbereitstellungsebene werden mit Hilfe von Quellsystemen dem SAP BW Daten zur Verfugung gestellt. Hierbei konnen 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 fur eine DataSource in die PSA geladen werden, bevor die weitere Verarbeitung im BW stattfindet kann. Hierbei konnen Selektionsbedingungen durchgefuhrt werden, um die Datenmenge zu beschranken.[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 ubertragen. Die PSA ist ein temporarer Zwischenspeicher, der die Daten vom Quellsystem in transparente Tabellen ablegt und zur weiteren Verarbeitung ihre Qualitat pruft und bei Bedarf diese andert oder loscht. Die Ladeperformance wird uber die PSA verbessert, indem die beiden Prozesse zum Laden und Weiterverarbeiten der Daten getrennt werden.[19]
AnschlieBend wird durch die Transformation die Zuordnung des Datenflusses vom Quell- zum Zielsystem gesteuert. Die sogenannte Transformation lost im SAP BW 7.0 die Ubertragungs- bzw. Fortschreibungsregeln der alteren BW-Versionen ab. Die Aufgabe einer Transformation liegt darin, die Daten einer Quellstruktur zu konsolidieren, zu bereinigen und in das Zielformat zu uberfuhren.[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 fur die Ubertragung 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]
Im Datenflusskonzept werden die InfoSources nur verwendet, wenn eine komplexe Transformation stattfindet. Das heiBt, dass die InfoSource nur bei einer Vielzahl von nacheinander geschalteten Transformationen zum Einsatz kommt.
AbschlieBend werden die Daten in den InfoProvider dargestellt, welche die Basis fur die Informationsanalyseebene bildet.
2.3.5 Datenmodelle
Um die Datenmodelle eines Data Warehouse Systems besser zu verstehen, wird zunachst 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 hauptsachlich 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 groBeren Datenbestanden durchfuhren zu konnen. Hier kommen spezielle Modellierungsmethoden zum Einsatz (Star- oder Snowflake-Schema).[22]
Mit Hilfe eines Datenmodells wird ein Abbild der Realitat in einer datentechnischen Form geschaffen.
Ein Data Warehouse System enthalt ublicherweise folgende Datenmodellkonzepte:
- ER-Diagramm nach Normalform
- Flache Struktur
- Star-Schema
- Snowflake-Schema
Die Unterscheidung der Konzepte erfolgt hinsichtlich der Komplexitat, 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 Ubergang ins Data Warehouse kaum oder im geringen MaBe modifiziert werden. Als Grundlage fur die Datenmodellierung dienen hauptsachlich Kennzahlen und deren Merkmale, diese Merkmale lassen sich in Merkmale und Attribute einteilen.[23]
ER-Diagramm
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 6: ER-Diagramm[24]
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[25] 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 ware die Aufteilung von Rechnungsbelegen in eine Tabelle fur die Kopfdaten einer Rechnung (z.B. Rechnungsdatum, Sachbearbeiter, etc.) und in eine Tabelle fur die Positionen (z.B. Materialnummer, Einzelpreis, etc.). Die Verknupfung findet uber die Rechnungsnummer statt.
Bei den fur die Analyse benotigten Daten, greifen OLAP-Tools auf direktem Wege auf die Transaktionsdaten im OLTP System zu. Dies verursacht neben eingeschrankten Analysemoglichkeiten eine schlechte Performance. Bedingt dadurch, dass analytische Anwendungen auf die Ergebnisse mehrerer Transaktionen zuruckgreifen, entsteht eine schlechte Performance, da mit einzelnen Transaktionen keine verwertbaren Informationen erzeugt werden konnen. Aufgrund der oben genannten Nachteile werden OLTP-Systeme in neueren Data- Warehouse-Systemen nur noch zum einmaligen Auslesen von Daten verwendet. Diese werden dann in spezielle Datenmodelle (flache Strukturen, Star-Schema, Snowflake-Schema) umgewandelt, welche fur analytische Anwendungen entwickelt wurden.[26] Die hier genannten Datenmodelle werden in den nachsten Abschnitt ausfuhrlicher erlautert.
Flache Strukturen[27]
Mit einer flachen Struktur konnen 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.
Abbildung in dieser Leseprobe nicht enthalten
1: Flache Analysetabelle[28]
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 unabhangig von relationalen Datenbanken ist und als Flat File abgelegt werden kann.
Star-Schema[29]
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 7: Star-Schema[30]
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 enthalt. Dabei ist die Struktur des Star-Schemas analog zu einem InfoCube aufgebaut.
Snowflake-Schema[31]
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 8: Snowflake-Schema[32]
Das Snowflake-Schema erganzt das Star-Schema um weitere Stammdatentabellen. Dabei wird die Option geboten, Daten in den Stammdatentabellen abzulegen, wo diese dann relationale Verknupfungen mit den Merkmalen in den Dimensionstabellen enthalten. Im Vergleich zu den oben genannten Modellen kann das Snowflake-Schema zusatzlich zu der historisierten Darstellung von Attributen auch aktuelle Gegenwartsdaten darstellen. Ein weiterer Vorteil ist die Normalisierung der Dimensionstabellen, da dadurch der Speicherplatzverbrauch reduziert wird.
Vergleich der Datenmodelle
Abbildung in dieser Leseprobe nicht enthalten
Tabelle 2: Uberblick der Datenmodelle[33]
2.3.6 Kennzahlenmodellierung
Bei der Kennzahlenmodellierung wird zwischen den folgenden zwei Modellierungstechniken unterschieden:
- Kennzahlenmodell
- Kontenmodell
Kennzahlenmodell
Im Kennzahlenmodell wird fur jede Kennzahl ein eigenes Feld vorgesehen. Diese Felder werden bei jedem Datensatz aufgelistet, unabhangig davon, ob dieser Daten fur das Feld der Kennzahl enthalt oder nicht.
Abbildung in dieser Leseprobe nicht enthalten
Tabelle 3: Kennzahlenmodell[34]
Um das Kennzahlenmodell anwenden zu konnen, 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.
Abbildung in dieser Leseprobe nicht enthalten
Tabelle 4: Vor- und Nachteile Kennzahlenmodell[35]
Kontenmodell
Die Modellierung des Kontenmodells gestaltet sich so, dass pro Kennzahl ein Datensatz gefuhrt wird. Das bedeutet, wenn bei einem Kennzahlenmodell in einem Datensatz drei Kennzahlen vorhanden sind, wurden im Kontenmodell drei Datensatze dafur benotigt werden.
Abbildung in dieser Leseprobe nicht enthalten
Tabelle 5: Kontenmodell[36]
Die Anzahl der Datensatze ist bei einem Kontenmodell um eine Vielzahl hoher als beim Kennzahlenmodell, allerdings zeichnet sich das Kontenmodell durch seine hohe Flexibilitat und die bestmogliche Nutzung der dargelegten Datenstruktur aus.
Abbildung in dieser Leseprobe nicht enthalten
Tabelle 6: Vor- und Nachteile Kontenmodell[37]
Vergleich Kennzahlen- und Kontenmodell
Es kann festgehalten werden, dass das Kennzahlenmodell verwendet werden sollte, wenn mit einer beschrankten und konstanten Anzahl von Kennzahlen gearbeitet wird. Des Weiteren ist es von Vorteil, wenn die Kennzahlen eines Datensatzes auch in den anderen Datensatzen Verwendung finden.
Stattdessen sollte das Kontenmodell Verwendung finden, wenn mit einer hohen und abwechselnden Anzahl von Kennzahlen gearbeitet wird. Wenn stattdessen mit dem Kennzahlenmodell gearbeitet werden soll, wurde innerhalb eines Datensatzes eine Vielzahl von Kennzahlen nicht befuhlt werden.
2.3.7 Kennzahlensystem
In diesem Abschnitt erfolgt ein Uberblick uber die unterschiedlichen Arten von Kennzahlen.
Im BW sind Kennzahlen quantifizierende betriebswirtschaftliche GroBen, die entsprechenden Merkmalen zugeordnet werden. Das heiBt, dass beispielsweise die Kennzahl Umsatz sowohl Angabe eines Kunden als auch eines Produktes benotigt.
Bei der Query-Definition konnen Basiskennzahlen, die bereits im InfoProvider vorhanden sind, integriert und ausgewertet werden. Dabei konnen Basiskennzahlen aus einem InfoProvider in einer Vielzahl von Queries verwendet werden.
Bei der Erstellung von Queries spielt die Anordnung der Kennzahlen eine entscheidende Rolle. Hierbei muss geklart werden, welcher Sachverhalt wie dargestellt werden soll. Dabei muss entschieden werden, ob die Kennzahlen in den Zeilen- oder Spalten angezeigt werden mussen und ob innerhalb der Query zusatzliche Kennzahlen wie eingeschrankte und berechnete Kennzahlen erstellt werden mussen. Die Definition von eingeschrankten und berechneten Kennzahlen erfolgt auf der gleichen Ebene wie bei den InfoProvidern. Somit stehen allen Queries des jeweiligen InfoProviders die genannten Kennzahlen zur Verfugung.
Im Vergleich zu den Basiskennzahlen zahlen eingeschrankte und berechnete Kennzahlen zu den virtuellen Kennzahlen. Als virtuelle Kennzahlen werden Kennzahlen bezeichnet, die erst zur
Laufzeit berechnet werden konnen und sich somit negativ auf die Performance von komplexen Queries auswirken. Der Vorteil der virtuellen Kennzahlen besteht darin, dass diese Kennzahlen nur einmal angelegt werden mussen und diese in verschiedenen Queries Verwendung finden. Daraus folgt, dass der Wartungsaufwand aufgrund der einmaligen Definition gering gehalten wird.
Eingeschrankte Kennzahlen
Als eingeschrankte Kennzahlen werden Kennzahlen bezeichnet, die einer Einschrankung durch eine definierte Merkmalskombination unterworfen sind. Eine Einschrankung ist beispielsweise, wenn eine Kennzahl, die den Umsatz darstellt, auf eine bestimmte Verkaufsorganisation oder Verkaufsgruppe eingeschrankt wird. Als Folge dieser Einschrankung wird nur der Umsatz fur diese eine Gruppe dargestellt.
Im Unterschied zu den Filtern gilt die Einschrankung nicht fur die gesamte Query, sondern nur fur einzelne Werte, Intervalle oder Hierarchiekonten.
Berechnete Kennzahlen
Werden stattdessen Kennzahlen benotigt, die nicht in dem entsprechenden InfoProvider vorhanden sind, sich jedoch aus den verfugbaren Daten herleiten lassen, konnen berechnete Kennzahlen erstellt werden. Hierbei konnen mathematische Funktionen verwendet werden, die von einfachen Grundrechenarten bis zu aufwandigen trigonometrischen Funktionen reichen.
Vergleich der Kennzahlenarten
Abbildung in dieser Leseprobe nicht enthalten
Tabelle 7: Vor- und Nachteile der Kennzahlenarten
2.4 Reportingtools
Analyse- und Reportingapplikationen werden mit Hilfe von Reportingtools entwickelt. Dazu wird mit Hilfe des Tool-Sets auf den Datenbestand des DWH zuruckgegriffen. Die Basis fur die Analysearbeiten stellt im Umfeld des SAP Netweaver BI 7.0 die Query dar.
Dabei stehen verschiedene Hilfsmittel fur die Entwicklungsarbeit zur Verfugung. Die nachfolgende Grafik soll hier den integrativen Ansatz der SAP verdeutlichen.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 9: Business Explorer
Mit den Business Exporer Tools konnen tabellearische und auch grafische Darstellungen erzeugt werden. Weiterhin bieten die entwickelten Applikationen die Moglichkeiten von DrillDown und Drill-Up-Funktionalitaten.
Die in einem Business Information Warehouse enthaltenen Abfragen und Auswertungen werden auf der Basis von Queries erzeugt, worauf die verschiedenen Front-End Werkzeuge aufsetzen, die in weiteren Verlauf des Kapitels Reportingtools noch naher erlautert werden. Jedoch wird auf den BEx Report Designer nicht naher eingegangen, da dieses Tool nicht bei der Erstellung eines Dashboards Verwendung findet.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 9: Business Explorer
Mit den Business Exporer Tools können tabellearische und auch grafische Darstellungen erzeugt werden. Weiterhin bieten die entwickelten Applikationen die Möglichkeiten von Drill Down und Drill-Up-Funktionalitäten. Die in einem Business Information Warehouse enthaltenen Abfragen und Auswertungen werden auf der Basis von Queries erzeugt, worauf die verschiedenen Front-End Werkzeuge aufsetzen, die in weiteren Verlauf des Kapitels Reportingtools noch näher erläutert werden. Jedoch wird auf den BEx Report Designer nicht näher eingegangen, da dieses Tool nicht bei der Erstellung eines Dashboards Verwendung findet.
2.4.1 Anwendertypen
Durch die Vielzahl der verschiedenen Benutzertypen, ist zu beachten, dass durchaus verschiedene Anforderungen und Praferenzen an das Front-End gestellt werden, die mit Hilfe des Business Explorer abgedeckt werden.[38]
Benutzergruppen konnen grob in Autoren, Analysten und Konsumenten unterteilt werden.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 10: Anwendertypen
Die einfachsten Anwender im DWH-System sind die Konsumenten, die nur statische Berichte ausfuhren. Insofern nutzen Konsumenten die analytischen Funktionen des Systems nur in geringem MaBe. Daher benotigen sie eine einfache bedienbare Benutzeroberflache, die sie mit dem BEx Analyzer erhalten. Mit dem BEx Analyzer wird der Zugriff auf alle Berichte einfach dargestellt und konnen direkt gestartet werden.
Im Gegensatz zu den Konsumenten benotigen Analysten und Autoren die Moglichkeit, die Berichte in unterschiedlichen Darstellung zu erzeugen, um die Daten aus verschiedenen Sichtweisen analysieren zu konnen. Autoren benotigen zudem Berechtigungen, mit der Sie befahigt werden, neue Queries anzulegen. Mit Hilfe des BEx Analyzers konnen Analysten und Autoren Berichte analysieren und Autoren konnen zusatzlich neue Berichte erzeugen. Werden stattdessen Reports im Web benotigt, verwenden Autoren den Web Application Designer.
2.4.2 BEx Query Designer
Der BEx Query Designer ist innerhalb der „Business Explorer“-Suite das zentrale Werkzeug fur das Design von Auswertungen bzw. Abfragen.
Dabei orientiert sich der Query-Designer in der Handhabung ahnlich wie bei Excel-Pivot- Tabellen an einer Drag & Drop-Technologie. Aus diesen Grund ist es Anwendern ohne Programmierkenntnisse moglich, Analysen uber dieses Tool zu erstellen. Fur die Analyseauswertungen werden OLAP-Funktionen sowie tabellarische und grafische Darstellungsmoglichkeiten bereitgestellt. Jedoch erfogt die Anzeige der Daten fur alle Queries im Web in einer einheitlichen Oberflache. Da sich die Ergebnisse von mehreren Queries nicht in einer Webanwendung anzeigen lassen, ist das Erstellen eines Dashboards mit dem BEx Query Designer nicht durchfuhrbar. AuBerdem konnen Grafiken, wie z.B. ein Firmenlogo, nicht in die Anwendung eingefugt werden.
Daher besteht die Moglichkeit, diese erstellten Auswertungen uber den „Business-Explorer“ aufzurufen oder innerhalb des Portals in einer WAD-Applikation zu publizieren.
[...]
[1] Vgl.[Nicolescu et. al., 2007] S.18
[2] Vgl. [Gurzki, 2004]
[3] Zitat aus [Inmon, 1996] S. 33
[4] Vgl. [Jung et. al., 2000] S.4-5
[5] Zitat aus [Bauer et.al.,2009]S.8
[6] Vgl. [Bauer et.al.,2009]S.8
[7] Zitat aus [Mehrwald, 2007] S. 33
[8] Vgl. [Mehrwald, 2007] S. 33
[9] Vgl. [Mehrwald, 2007] S.59
[10] Vgl. [Hahne, 2005] S.43-44
[11] 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 fur einen gewissen Bereich bzw. eine Anwendung entwickelt.
[12] Vgl. [SAPJoin, 2009]
[13] Vgl. [Mehrwald, 2007] S.98
[14] Vgl.[Hahne, 2005]S.48
[15] Vgl. [Egger et al., 2005] S.52
[16] Vgl.[Hahne, 2005]S.50
[17] Vgl. [Seemann et. al., 2001] S.25
[18] Vgl. [Egger et al., 2005] S.47
[19] Vgl. [Hahne, 2005] S.44-45
[20] Vgl. [Mehrwald, 2007] S. 439
[21] Vgl. [Mehrwald, 2007] S.469
[22] Vgl. [Bauer et.al.,2009] S.47
[23] Vgl. [Mehrwald, 2007] S.47
[24] In Anlehnung an [Mehrwald, 2007] S.50
[25] Unter Normalisierung wird die Schrittweise Aufschaltung einer Relation in mehreren kleineren Relationen, mit dem Ziel der Redundanzminimierung verstanden. Bei der Normalisierung spielen die Abhangigkeiten zwischen den Tabellenattributen eine wichtige Rolle.
[26] Vgl. [Mehrwald, 2007] S.49-S.50
[27] Vgl. [Mehrwald, 2007] S.51-53
[28] In Anlehnung an [Mehrwald, 2007] S.51
[29] Vgl. [Mehrwald, 2007] S.54
[30] In Anlehnung an [Mehrwald, 2007] S.54
[31] Vgl. [Mehrwald, 2007] S.56
[32] In Anlehnung an [Mehrwald, 2007] S.56
[33] In Anlehnung an [Mehrwald, 2007] S.56
[34] In Anlehnung an [Mehrwald, 2007] S.53
[35] Vgl. [SAPBibKModell, 2009]
[36] In Anlehnung an [Mehrwald, 2007] S.53
[37] Vgl. [SAPBibKModell, 2009]
[38] [Seemann et. al., 2001] S.36