Einführung in SAP Business Information Warehouse 9783540311256, 3540311254 [PDF]

Zitiervorschau

Einführung in SAP Business Information Warehouse

Jorge Marx Gómez Claus Rautenstrauch Peter Cissek Björn Grahlher

Einführung in SAP Business Information Warehouse Mit 195 Abbildungen und 6 Tabellen

123

Professor Dr.-Ing. Jorge Marx Gómez Universität Oldenburg Department für Informatik Abteilung Wirtschaftsinformatik Ammerländer Heerstraße 114-118 26129 Oldenburg E-mail: [email protected] Professor Dr. Claus Rautenstrauch Otto-von-Guericke-Universität Fakultät Informatik Institut Technische/Betriebliche, Informationssysteme Universitätsplatz 2 39106 Magdeburg E-mail: [email protected]

Peter Cissek Champagne 7 40822 Mettmann E-mail: [email protected] Björn Grahlher Am Thing 24 21244 Buchholz E-mail: [email protected]

Die Deutsche Bibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.ddb.de abrufbar.

ISBN-10 3-540-31124-6 Springer Berlin Heidelberg New York ISBN-13 978-3-540-31124-9 Springer Berlin Heidelberg New York Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte, insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen, bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik Deutschland vom 9. September 1965 in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des Urheberrechtsgesetzes. Springer ist ein Unternehmen von Springer Science+Business Media springer.de © Springer-Verlag Berlin Heidelberg 2006 Printed in Germany Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften. Einbandgestaltung: design & production GmbH Herstellung: Helmut Petri Druck: Strauss Offsetdruck SPIN 11609759

Gedruckt auf säurefreiem Papier – 42/3153 – 5 4 3 2 1 0

Vorwort

Data-Warehouse-Systeme sind heute fester Bestandteil der taktischen und strategischen Informationssysteme in Unternehmen. Mit dem SAP® Business Information Warehouse (BW®) hat es die SAP AG in erstaunlich kurzer Zeit geschafft, sowohl die Markt- als auch Technologieführerschaft im Marktsegment der DataWarehouse-Systeme zu übernehmen. Schon allein dies ist Grund genug, dass Studierende, Lehrende und Praktiker zumindest Grundkenntnisse im Umgang mit derartigen Systemen erwerben. Studierende mit Kenntnissen über das SAP BW haben einen erleichterten Berufseinstieg und Praktiker können bei der Entscheidungsunterstützung in Unternehmen fundiert mitreden, wenn sie BW-Kenntnisse erwerben und umsetzen. Dieses Buch hat den Anspruch, den Einstieg in die Welt des SAP BW auf einfache und fundierte Weise zu erleichtern. Aufbauend auf den technologischen und konzeptionellen Grundlagen von Data Warehouses werden praxisnahe und erprobte Fallstudien präsentiert, anhand derer die theoretischen Konzepte nachvollzogen und vertieft werden. So hat der geneigte Leser die Möglichkeit, Erkenntnisse sowohl aus der theoretischen Betrachtung sowie aus dem Nachspielen von Fallstudien zu gewinnen. So ist der Lernerfolg hoffentlich vorprogrammiert. Für die Lehre an Universitäten, Fachhochschulen und Berufsakademien ist die flächendeckende Versorgung mit SAP BW durch die SAP Hochschulkompetenzzentren (SAP HCC) an der Otto-von-Guericke-Universität Magdeburg und der TU München sichergestellt. So sind die Fallstudien in enger Zusammenarbeit mit den SAP HCC Magdeburg entstanden, deren Mitarbeiter trotz stets stressreichem Tagesgeschäft dieses Buchprojekt in dankenswerter Weise mit Rat und Tat unterstützten. Damit sei dann auch der Reigen der Danksagungen eröffnet. Nicht genug kann man stets den Familien und Partnern danken, die unter der Arbeitswut der Autoren unverschuldet zu leiden haben. Leidensfähigkeit verlangen die Autoren aber auch oft von den Partnern auf der Seite des Verlags. Hier gilt unser Dank Herrn Dr. Werner A. Müller, der dieses Projekt mit stets konstruktiver Kritik, fundierten Ratschlägen und Professionalität begleitet hat. Für die abschließenden Korrekturund Formatierungsarbeiten danken wir Herrn Dirk Schlehf. Wir wünschen allen Lesern viel Spaß und Erfolg bei der Lektüre.

Die Autoren

Magdeburg, im Dezember 2005

Inhalt

Vorwort ................................................................................................................. V Verzeichnis der Abkürzungen und Akronyme .................................................XI Verzeichnis der eingetragenen Marken......................................................... XIII 1 Einführung ins SAP Business Information Warehouse ..................................1 1.1 Ziele und Aufbau dieses Buches..................................................................1 1.2 Vorbereitung der Fallstudien .......................................................................2 2 Theoretische Grundlagen der Data Warehouse Technologie.........................3 2.1 Einführung ...................................................................................................3 2.1.1 Bedeutung der Information für die Entscheidungsunterstützung .........3 2.1.2 Operative Systeme................................................................................4 2.1.3 Data Warehouse Systeme.....................................................................6 2.2 Daten und Architektur .................................................................................7 2.2.1 Geschäftsdaten .....................................................................................7 2.2.2 Metadaten .............................................................................................9 2.2.3 Komponenten .......................................................................................9 2.3 Datenmodell...............................................................................................11 2.3.1 Fakten, Kennzahlen und Dimensionen...............................................12 2.3.2 Modellierung von Zeit........................................................................15 2.3.3 Multidimensionale Anfragestrukturen................................................15 2.3.4 OLAP Operationen.............................................................................16 2.3.5 ADAPT ..............................................................................................18 2.3.6 Speicherung multidimensionaler Daten, Star- und SnowflakeSchema ........................................................................................................21 2.4 Datenquellen und Datenqualität.................................................................26 2.4.1 Quellen für Geschäftsdaten ................................................................26 2.4.2 Quellen für Metadaten........................................................................27 2.4.3 Datenqualität ......................................................................................27 2.4.4 Qualitätsmetriken ...............................................................................30 2.4.5 Data Cleaning.....................................................................................31 2.5 Typisches ETL-Prozessmodell ..................................................................33 2.5.1 Vorbereitungsphase ............................................................................34

VIII

Inhalt

2.5.2 Extraktionsphase ................................................................................ 34 2.5.3 Transformationsphase ........................................................................ 35 2.5.4 Ladephase........................................................................................... 36 2.6 Bewertung eines Data Warehouse ............................................................. 36 2.6.1 Stärken eines Data Warehouse ........................................................... 37 2.6.2 Schwächen eines Data Warehouse ..................................................... 37 3 Theoretische Grundlagen des SAP Business Information Warehouse ........ 41 3.1 Umgang mit SAP Systemen ...................................................................... 41 3.1.1 SAPlogon ........................................................................................... 41 3.1.2 SAP Fenster........................................................................................ 42 3.1.3 Elemente der SAP Bildschirmmasken................................................ 45 3.2 Komponenten des SAP BW....................................................................... 47 3.2.1 Datenschicht....................................................................................... 48 3.2.2 Administrationsschicht....................................................................... 48 3.2.3 Analyseschicht ................................................................................... 49 3.3 Datenmodellierung .................................................................................... 50 3.3.1 Struktur – InfoArea, InfoProvider und InfoObjectCatalog................. 50 3.3.2 InfoObjects......................................................................................... 51 3.3.3 InfoCubes und Dimensionen .............................................................. 63 3.3.4 ODS-Objekte...................................................................................... 64 3.3.5 InfoSets .............................................................................................. 66 3.3.6 MultiProvider ..................................................................................... 67 3.4 Datenbeschaffung ...................................................................................... 69 3.4.1 Extraktion........................................................................................... 71 3.4.2 Transformation ................................................................................... 77 3.4.3 Laden.................................................................................................. 79 3.5 Berichtswesen ............................................................................................ 83 3.5.1 BEx Query Designer .......................................................................... 84 3.5.2 BEx Analyzer ..................................................................................... 89 3.5.3 Web-basiertes Berichtswesen............................................................. 90 3.5.4 BEx Web Application Designer ....................................................... 102 3.5.5 Formatiertes Reporting..................................................................... 108 3.5.6 Mobile Intelligence .......................................................................... 108 3.5.7 Weitere Funktionen: Offline Reporting und Integration in das SAP Enterprise Portal ............................................................................... 109 4 Fallstudie I – Ist-Daten-Analyse.................................................................... 111 4.1 Teil I – Datenmodellierung...................................................................... 113 4.1.1 Anlegen der InfoArea....................................................................... 115 4.1.2 Anlegen des InfoObjectCatalogs und der InfoObjects ..................... 117 4.1.3 Anlegen des InfoCubes für die Ist-Daten ......................................... 130 4.2 Teil II – Datenbeschaffung ...................................................................... 138 4.2.1 Anlegen der InfoSources .................................................................. 140 4.2.2 Einlesen von Stammdaten aus Flat Files .......................................... 143 4.2.3 Manuelle Pflege der Stammdaten..................................................... 154

Inhalt IX

4.2.4 Pflege der Shape Files für die Kartendarstellung .............................159 4.2.5 Einlesen der Bewegungsdaten..........................................................162 4.3 Teil III – Reporting ..................................................................................170 4.3.1 Anlegen der Query ...........................................................................172 4.3.2 Reporting mit dem BEx Analyzer unter MS Excel ..........................176 4.3.3 Ad hoc – Reporting im Webbrowser................................................182 4.3.4 Reporting mit dem BEx Web Application Designer ........................188 5 Fallstudie II – Soll-Ist Vergleich....................................................................199 5.1 Teil I – Datenmodellierung......................................................................200 5.1.1 Anlegen eines ODS-Objekts.............................................................201 5.1.2 Anlegen des InfoCubes für die Soll-Daten.......................................204 5.1.3 Anlegen des Multiproviders .............................................................205 5.2 Teil II – Datenbeschaffung ......................................................................212 5.2.1 Anlegen der InfoSource für die Soll-Daten ......................................213 5.2.2 Schreiben der Daten in das ODS-Objekt..........................................218 5.2.3 Fortschreiben der Soll-Daten in den InfoCube sowie der korrigierten Ist-Daten ................................................................................224 5.3 Teil III – Reporting ..................................................................................228 5.3.1 Anlegen der Query ...........................................................................229 5.3.2 Reporting im BEx Web Application Designer .................................235 6 Fallstudie III – Bestandsdatenanalyse ..........................................................245 6.1 Teil I – Datenmodellierung......................................................................246 6.1.1 Anlegen der Kennzahlen ..................................................................246 6.1.2 Anlegen des InfoCubes für die Bestandsdaten .................................249 6.2 Teil II – Datenbeschaffung ......................................................................250 6.2.1 Anlegen der InfoSources für Anfangsbestand und Bestandsveränderungen.............................................................................251 6.2.2 Einlesen des Anfangsbestands und der Bestandsveränderungen......254 6.3 Teil III – Reporting ..................................................................................257 6.3.1 Anlegen der Queries.........................................................................258 6.3.2 Reporting im BEx Web Application Designer .................................261 Literatur.............................................................................................................271

Verzeichnis der Abkürzungen und Akronyme

ABAP ADAPT ALE API APO ARIS ASCII BAPI BEx CR CRM CSS CSV DB DBMS DOM DV EIS ERP ETL GUI HOLAP HTML HTTP IDoc MOLAP ODS OLAP OLTP OMG PDA PSA SAP SEM SMS SOAP SQL

Advanced Business Application Programming Application Design for Analytical Processing Technologies Application Linking and Embedding Application Programming Interface Advanced Planner and Optimizer Architektur integrierter Informationssysteme American Standard Code for Information Integration Business Application Programming Interface Business Explorer Carriage Return Customer Relationship Management Cascading Style Sheets Character Separated Values Datenbank (engl. Database) Database Management System Document Object Model Datenverarbeitung Executive Information System Enterprise Resource Planning Extraktion Transformation Laden Graphical User Interface Hybrid Online Analytical Processing Hypertext Markup Language Hypertext Transfer Protocol Intermediate Document Multidimensional Online Analytical Processing Operational Data Store Online Analytical Processing Online Transaction Processing Object Management Group Personal Digital Assistant Persistant Staging Area Systeme, Anwendungen und Produkte in der Datenverarbeitung Strategic Enterprise Management Short Message Service Simple Object Access Protocol Structured Query Language

XII

Verzeichnis der Abkürzungen und Akronyme

URL WAP WWW XML

Uniform Resource Locator Wireless Application Protocol World Wide Web Extensible Markup Language

Verzeichnis der eingetragenen Marken

ADAPT® ist eine eingetragene Marke der Symmetry Corporation. Crystal Reports® ist eine eingetragene Marke der Business Objects SA. CSS®, DOM®, HTML®, HTTP® und XML® sind eingetragene Marken des W3C®, World Wide Web Consortium, Massachusetts Institute of Technology. i-Mode® ist eine eingetragene Marke der NTT DoCoMo Inc. JavaScript® ist eine eingetragene Marke der Sun Microsystems, Inc., verwendet unter der Lizenz der von Netscape entwickelten und implementierten Technologie. Microsoft®, Excel®, Internet Explorer®, PowerPoint®, Windows® sowie Grafiken und entsprechende Logos sind eingetragene Marken der Microsoft Corporation. Netscape® und Netscape® Navigator und weitere im Text verwendete NetscapeProdukte sind eingetragene Marken der Netscape Communications Corporation und America Online, Inc. Nokia® und Nokia Mobiltelefone sind eingetragene Marken der Nokia Corporation. Palm® und Palm® Pilot sind eingetragene Marken der Palm, Inc. SAP®, ABAP®, BAPI®, SAP iView®, SAP NetWeaver®, SAP SEM®, R/3® sowie Grafiken, entsprechende Logos und weitere im Text verwendete SAPProdukte sind eingetragene Marken der SAP AG. Six Sigma® ist eine eingetragene Marke der Motorola Inc. Alle anderen Namen von Produkten und Dienstleistungen sind Marken der jeweiligen Firmen.

1 Einführung ins SAP Business Information Warehouse

1.1 Ziele und Aufbau dieses Buches Das Ziel dieses Buches ist es, dem Leser anhand von Fallstudien einen praktischen Einstieg in die Software SAP Business Information Warehouse zu ermöglichen. Dem Leser werden dabei keinerlei Vorkenntnisse im Bereich des Data Warehousing oder Erfahrungen mit Produkten der SAP AG abverlangt, sämtliches Basiswissen wird in den Kapiteln 2 Theoretische Grundlagen der Data Warehouse Technologie und 3 Theoretische Grundlagen des SAP Business Information Warehouse vermittelt. Das Lehrbuch richtet sich primär an Lehrende und Studierende der Fachrichtungen Informatik, Wirtschaftsinformatik und der Wirtschaftswissenschaften. Gleichsam unterstützt es den Anwender im Unternehmen bei seinen ersten Schritten im SAP BW. An das vorliegende Werk kann auf drei verschiedene Weisen herangegangen werden. Wenn bereits fundierte Kenntnisse der Data Warehouse Technologie vorhanden sind, kann der theoretische Teil übersprungen und direkt im Kapitel 4 Fallstudie I – Ist-Daten-Analyse mit der Fallstudie begonnen werden. Die zweite Herangehensweise besteht darin, streng nach der Kapitelstruktur vorzugehen und somit vor Bearbeitung der Fallstudie zunächst den kompletten Theorieteil zu lesen. Die dritte und von den Autoren empfohlene Möglichkeit ist, grundsätzlich der Kapitelstruktur zu folgen, jedoch parallel zum Kapitel 3 Theoretische Grundlagen des SAP Business Information Warehouse das Kapitel 4 Fallstudie I – IstDaten-Analyse zu bearbeiten. Diese Vorgehensweise wird dadurch unterstützt, dass im Verlauf des dritten Kapitels an geeigneter Stelle auf die entsprechenden Abschnitte des vierten Kapitels verwiesen wird. Bevor mit der Ausführung der Fallstudien begonnen wird, ist sicherzustellen, dass die in Kapitel 1.2 Vorbereitung der Fallstudien beschriebenen Maßnahmen zur Einrichtung und Konfiguration des SAP BW Systems vom Systemadministrator durchgeführt worden sind. Neben zahlreichen Screenshots und Abbildungen wird der Leser bei der Arbeit mit diesem Buch zusätzlich durch das Textlayout unterstützt. In herausgestellten Kästen finden sich bedeutsame Definitionen, Hinweise der Autoren und Zusammenfassungen sowie die Verknüpfung von theoretischem und praktischem Teil.

2

1 Einführung ins SAP Business Information Warehouse

Innerhalb der Fallstudien sind Bezeichnungen in Bildschirmmasken stets kursiv und zu betätigende Schaltflächen oder über die Tastatur einzugebende Zeichenketten immer fett gekennzeichnet.

1.2 Vorbereitung der Fallstudien Voraussetzung für eine erfolgreiche Durchführung der Fallstudien ist eine installierte SAP BW Instanz. Den Teilnehmern der Fallstudie sollte durch den Systemadministrator im System eine InfoArea sowie eine Anwendungskomponente zugewiesen werden, außerdem ist ein Quellsystem des Typs Filesystem (Metadaten manuell, Daten über Dateischnittstelle) mit A_QS_FSBW als Logischer Systemname und Externe Daten Fallstudie BW als Name des Quellsystems anzulegen. Es wird empfohlen, die Zugangsdaten der Teilnehmer derart zu gestalten, dass der Benutzername mit einer dreistelligen Zahlenkombination abschließt. Diese Zahlenkette bezeichnet Gruppe (erste Position) und Benutzer ID (zweite und dritte Position) und wird von den Teilnehmern im Verlauf der Fallstudien zur eindeutigen Benennung von Objekten benötigt. Neben dem SAP BW System müssen auf den Rechnern der Teilnehmer das Microsoft Office Paket in der Version 2000 oder neuer und ein Texteditor installiert sein. Die Dateien, auf deren Daten die Fallstudie basiert, müssen zum Beispiel über das Internet herunterladbar sein oder über ein lokales Netzwerk bereitgestellt werden.

2 Theoretische Grundlagen der Data Warehouse Technologie

2.1 Einführung In diesem Kapitel werden die Data Warehouse Systeme in die Systemlandschaft eines Unternehmens eingeordnet. Es wird darauf eingegangen, zu welchem Zweck ein Data Warehouse eingesetzt wird und welche Charakteristika es beschreiben. 2.1.1 Bedeutung der Information für die Entscheidungsunterstützung Entscheidungsträger haben das bedeutsame Potential der Information zur positiven Beeinflussung der Wettbewerbsposition des Unternehmens erkannt (vgl. Gupta, 1997). Der Grad der Automatisierung in der Geschäftsprozessabwicklung ist so weit angestiegen (vgl. Fuller, 2002b), dass durch weitere Investitionen in diesem Bereich nur geringe Verbesserungen der Produktivität und Profitabilität zu erwarten sind (vgl. Anahory und Murray, 1997). Information ist handlungsbestimmendes Wissen über historische, gegenwärtige und zukünftige Zustände der Wirklichkeit und Vorgänge in der Wirklichkeit, mit anderen Worten: Information ist Reduktion von Ungewissheit (Heinrich, 1999). Die Anforderungen an Informationsintegration und -versorgung haben sich in den Bereichen der Flexibilität, Verfügbarkeit und Qualität weiterentwickelt. Eine auf die Bedürfnisse der Anwender zugeschnittene Bereitstellung der Daten und anpassungsfähigere Auswertungen können neue Informationssysteme leisten. Eine Steigerung der Informationsqualität und –quantität hängt dagegen vom Prozess der Informationsgewinnung aus intern und extern beschafften Daten ab. Diese beeinflusst die erfolgreiche Planung und Umsetzung von Maßnahmen und dadurch indirekt den Unternehmenserfolg positiv (vgl. Holthuis, 1999). Daten sind zum Zwecke der Verarbeitung zusammengefasste Zeichen (Rautenstrauch, 2001).

4

2 Theoretische Grundlagen der Data Warehouse Technologie

Typische Fragestellungen, die mit entscheidungsunterstützenden Systemen beantwortet werden können, sind Analysen zur Bewertung der Rentabilität von Standorten und die Überprüfung des Produktportfolios auf Ladenhüter und Verkaufsrenner. Im Fokus steht nicht nur eine auf numerische Werte beschränkte Auswertung, sondern besonders eine graphisch aufbereitete Präsentation der Informationen, in der kritische Aspekte eines Sachverhalts hervorgehoben werden können. Für wiederkehrende oder periodische Analysen werden vorgefertigte Berichte eingesetzt (Reporting), individuell gestaltete und flexible Anfragen werden als Queries bezeichnet (vgl. Sattler und Saake, 2004). Die in Unternehmen weit verbreiteten operativen Systeme wurden für die Erfassung, Verarbeitung und Verwaltung auf der Datenebene konzipiert. Ein typisches Beispiel hierfür ist das Anzeigen der vollständigen Kontaktdaten eines Geschäftspartners nach Eingabe der Kundennummer in eine Adressverwaltungssoftware. Die Systeme stellen eine Sicht auf die Daten bereit, vollziehen jedoch nicht den Schritt zur Generierung von Information (vgl. Holthuis, 1999). Gleichzeitig mit dem gewachsenen Informationsbedarf haben sich auch die Organisationsstrukturen dahingehend verändert, dass ein unternehmensweiter, ganzheitlicher Überblick für die Unternehmensführung höchste Priorität hat (vgl. Gupta, 1997). Dieser Anspruch macht eine detaillierte und zugleich flexible Sicht auf die Daten, wie sie zuvor nur auf der Ebene der jeweiligen Abteilung gegeben war, zwingend erforderlich. Die Unternehmensführung hat somit direkten Zugriff auf die Daten, so dass eine hohe Aktualität der Informationen gewährleistet ist sowie eine wirksame und aktive Steuerung und Kontrolle untergeordneter Instanzen. In der heutigen Konkurrenzsituation globaler Märkte ist es unabdingbar, Tendenzen frühzeitig zu erkennen und schnell auf Veränderungen zu reagieren. Außerdem sollen Vergleiche mit externen Marktdaten ermöglicht und die Ergebnisse dieser in die Entscheidungsfindung mit einbezogen werden. Unternehmensweite Informationssysteme haben das Potential, einen großen Beitrag zur Bewältigung dieser Aufgaben zu leisten (vgl. Devlin, 1997). Im Folgenden werden zunächst die Eigenschaften operativer Systeme erläutert und denen des Data Warehouse gegenübergestellt, um eine klare Abgrenzung der Systeme zu erreichen. 2.1.2 Operative Systeme Die operativen Systeme unterstützen Anwender, die durch Transaktionen sämtliche in Geschäftsprozessen anfallende Daten erfassen, verarbeiten und verwalten. Wird kein vollständig integriertes System wie SAP R/3 eingesetzt, so obliegt die Verantwortung für Einsatz und Betrieb der operativen Systeme den Abteilungen. Der Umfang der erfassten Daten und die Funktionalität gehen nicht über die Abteilungsgrenzen hinaus, so dass sich die Systeme stark hinsichtlich der Form der gespeicherten Daten und der unterstützten Aufgaben unterscheiden (vgl. Smith, 2002).

2.1 Einführung

5

In der Regel bezieht ein jedes operatives System seine Daten aus lediglich einer Quelle, das Volumen der Daten eines Systems beträgt dabei bis zu mehreren Gigabyte (vgl. Bauer und Günzel, 2001). Diese Daten lassen sich charakterisieren als nicht abgeleitet, zeitaktuell, dynamisch und unabhängig. Abgeleitete Daten gehen aus anderen Daten durch Anwendung einer Berechnungsvorschrift hervor, zum Beispiel wird der Deckungsbeitrag eines Produktes durch die Differenz aus Erlösen und variablen Kosten bestimmt. Zeitaktualität und Dynamik bedeuten, dass stets ausschließlich die aktuellste Version eines Datenwertes gehalten wird. Zusammengefasst repräsentieren alle diese Werte die derzeitige Situation des Unternehmens. Die Daten unterliegen häufigen Änderungsvorgängen, die vorherige Version wird jeweils überschrieben. Unter abhängigen Daten versteht man Interdependenzen zwischen zwei oder mehr Elementen, zum Beispiel kann man in Deutschland aus der Kombination von Straße, Hausnummer und Ort eindeutig auf die Postleitzahl schließen. Im Gegensatz zu abgeleiteten Daten handelt es sich lediglich um eine Zuordnung, es liegt keine Funktion oder Regel zugrunde. Die vom Benutzer ausgeführten Transaktionen umfassen das Lesen, Anlegen, Modifizieren und Löschen von Datensätzen, deshalb sind die Systeme für kurze Lese- und Schreiboperationen und für wiederkehrende Abläufe optimiert (vgl. Gupta, 1997). Typische Anfragen sind vordefiniert, einfach strukturiert und betreffen nur wenige Datensätze, meist werden lediglich einzelne Tupel der Datenbank angefordert. In der Regel greifen viele Anwender, die aus unterschiedlichen Fachbereichen stammen können, auf die Systeme zu (vgl. Sattler und Saake, 2004). Ansätze, um die zur Entscheidungsunterstützung gewünschten Informationen direkt aus den operativen Systemen zu gewinnen, liefern kein befriedigendes Ergebnis (vgl. Inmon, 2001). Es bestehen Schwierigkeiten für die Anwender, in der heterogenen, daher komplexen und unübersichtlichen Systemlandschaft alle benötigten Daten aufzufinden. Darüber hinaus stehen dem einzelnen Anwender unter Umständen nicht alle erforderlichen Berechtigungen für den Zugriff zur Verfügung. Es fehlt oft eine hinreichende Dokumentation der Daten, so dass Anfragen nicht exakt formuliert werden können und so nicht das erwartete Ergebnis liefern. Um Anfrageresultate schließlich in seiner Arbeitsumgebung verwenden zu können, muss der Benutzer die Daten zunächst in diese transferieren. Aufgrund des Zeitpunktbezugs der Daten lassen sich keine Trends ableiten, die Antwortzeiten bei Analysen über die Datenbestände mehrerer operativer Systeme übersteigen schnell ein von den Nutzern akzeptiertes Maß und verzögern zudem die Verarbeitung geschäftsprozessrelevanter Transaktionen anderer Anwender (vgl. Devlin, 1997). Die operativen Systeme können die Anforderungen der Anwender wie Manager, Abteilungsleiter und Fachkräfte an die Entscheidungsunterstützung also nicht hinreichend erfüllen. Es kommt somit zu einer Unterscheidung von den Informationssystemen, die nicht die Verwaltung, sondern die Analyse der Daten als zentrale Aufgabe haben. Entscheidungsträger entwickeln häufig erst beim Betrachten einer Auswertung, die verschiedene Perspektiven auf die Daten zulässt, Ideen und Strategien zur Lösung des anstehenden Problems. Eine mög-

6

2 Theoretische Grundlagen der Data Warehouse Technologie

lichst große Flexibilität hinsichtlich der Auswahl der Perspektive unmittelbar während der Betrachtung ist wünschenswert (vgl. Holthuis, 1999). Um eine flexible und leistungsfähige Entscheidungsunterstützung zu gewährleisten, ist es notwendig, alle zur Analyse benötigten Daten in einer einzigen Quelle konsistent und nicht redundant zu speichern. Dazu müssen die Daten verschiedener Quellen in ein einheitliches Format überführt werden, Datenqualität und Datenschutz sind von besonderer Bedeutung. Die IT-Abteilung wird durch den Betrieb eines Informationssystems, das auf einen eigenen Datenbestand zugreift, weniger belastet als durch eine direkt auf den operativen Systemen basierende Lösung (vgl. Inmon, 2001). Diese bereitet Probleme, wenn operative Systeme Änderungen unterzogen werden, da eine Anpassung der Informationssysteme unmittelbar erforderlich ist. Eine Konsolidierung der Daten lassen die Eigenschaften der operativen Systeme nicht zu, zum Beispiel kann eine redundante Datenhaltung oft nicht vermieden werden (vgl. Devlin, 1997). 2.1.3 Data Warehouse Systeme Der Begriff Data Warehouse wird häufig synonym mit dem Begriff Data Warehouse System gebraucht. In dieser Arbeit wird daher ebenfalls der verkürzte Ausdruck Data Warehouse verwendet, lediglich in Kapitel 2.2.3 Komponenten, in dem detailliert die Komponenten des Data Warehouse Systems vorgestellt werden, wird eine strenge begriffliche Unterscheidung vorgenommen. Inmon definierte Data Warehouse wie folgt: A Data Warehouse is a subject-oriented, integrated, non-volatile and timevariant collection of data in support of management decisions (vgl. Inmon, 1999a). In dieser Definition sind Fachorientierung sowie eine integrierte und persistente Haltung historischer Daten zentrale Kriterien für die Unterstützung von Entscheidungsprozessen der Unternehmen. Eine Umsetzung der Definition findet sich in den Versprechen wieder, die mit einem Data Warehouse verbunden werden (vgl. Inmon 2001): • Möglichkeit des Zugriffs auf Daten, die inkonsistent in Altsystemen eines Unternehmens vorliegen • Erreichen eines hohen Grades an Integration bei der Informationsverarbeitung • Nutzen aus neuen Plattformen und neuer Softwaretechnologie ziehen • Schaffung, Verwaltung und Möglichkeit zur wettbewerbsfähigen Nutzung von Informationen, nicht Daten • Bereitstellen von Strukturen, um historische wie auch aktuelle Daten handhaben zu können

2.2 Daten und Architektur

7

Der Data Warehouse Prozess, der alle Schritte der Beschaffung, der Modellierung und der Analyse umfasst, wird als Data Warehousing bezeichnet (vgl. Bauer und Günzel, 2001). Ein Data Warehouse überwindet die Heterogenität auf System-, Schema- und Datenebene (vgl. Sattler und Saake, 2004). Es bezieht seine Daten sowohl aus unternehmensexternen Quellen als auch aus einer Vielzahl verschiedener -interner operativer Systeme (Überwindung der Heterogenität auf Systemebene). In den Quellsystemen sind die Daten nach unterschiedlichen Schemata abgelegt, dies betrifft zum Beispiel Abhängigkeiten zwischen Datensätzen. Daher müssen die Daten vor dem Einfügen in das Data Warehouse in ein einheitliches Format überführt werden, zusätzlich müssen etwa Duplikate entfernt werden (Homogenität auf Datenebene). Sind die Daten einmal in den Datenbestand eingefügt, so werden sie in der Regel nicht mehr verändert. Dies geschieht nur in Ausnahmefällen, unter anderem wenn sich Daten im Nachhinein als fehlerhaft erwiesen. Änderungen im Datenbestand der operativen Systeme wirken sich erst nach der nächsten Extraktion aus, der Grad der Aktualität der Daten des Data Warehouse hängt somit von der Häufigkeit des Ladevorgangs ab (vgl. Holthuis, 1999). Die Anfragen an ein Data Warehouse sind komplex und betreffen eine Vielzahl Datensätze, dies führt zu längeren Antwortzeiten als sie aus dem Einsatz operativer Systeme bekannt sind (vgl. Gupta, 1997). Sie erfolgen ausschließlich lesend und die Ergebnisse sind aufgrund der Nicht-Volatilität des Datenbestandes jederzeit reproduzierbar. Um die genannten Anforderungen zu erfüllen, werden in einem Data Warehouse multidimensionale Strukturen zur Datenhaltung verwendet.

2.2 Daten und Architektur Es existieren im Unternehmen verschiedene Typen von Daten, die sich nicht alle für eine Verwendung im Data Warehouse eignen. Lediglich Geschäfts- und Metadaten können in einem solchen System erfasst werden. Nach der Unterscheidung der beiden Datenarten wird die typische logische Architektur eines Data Warehouse erläutert. 2.2.1 Geschäftsdaten Geschäftsdaten werden bei der Abarbeitung von Geschäftsprozessen verwendet und sind das Betrachtungsobjekt von Auswertungen. Man unterscheidet sie in drei Schichten: Echtzeitdaten sind die Datenbasis für die operativen Systeme. Sie sind hochaktuell, sehr detailliert und werden im laufenden Betrieb durch Schreib- und Leseoperationen manipuliert. In dieser nicht konsolidierten Form werden die Echtzeitdaten nicht zum Entscheidungsprozeß herangezogen und daher nicht im Data Warehouse dauerhaft gespeichert, sie bilden jedoch die Grundlage für alle weiteren Schichten (vgl. Devlin, 1997). Als Beispiel können die Umsätze einer Periode

8

2 Theoretische Grundlagen der Data Warehouse Technologie

in den Vereinigten Staaten von Amerika (in US-Dollar) und in Europa (in Euro) dienen. Konsolidierte Daten haben historischen Charakter und wurden mit Betonung auf höchste systemweite Konsistenz aus den Echtzeitdaten erzeugt. Diese Konsistenz betrifft sowohl den Datentyp als auch die Semantik und den Zeitbezug. Das Datenmodell muss gegenwärtige und zukünftig mögliche Beziehungen zwischen den Daten abbilden können. Im Konsolidierungsprozess werden keine neuen Daten hinzugefügt. Für das obige Beispiel bedeutet dies, dass die Umsätze der verschiedenen Kontinente in die Einheitswährung Euro überführt werden. Abgeleitete Daten werden traditionell zur Entscheidungsunterstützung genutzt. Sie werden durch einen wohldefinierten Prozess aus konsolidierten Daten gewonnen, der Aggregationsgrad hängt dabei von den Anforderungen der jeweiligen Aufgabe ab (vgl. Lambert, 1996). So kann eine abgeleitete Größe ohne Umformung aus der Menge konsolidierter Daten hervorgehen oder durch die Kombination vorhandener, logisch zusammenhängender Daten angereichert werden. Die Verwendung abgeleiteter Daten für Anfragen verbessert das Antwortzeitverhalten, da aggregierende Operationen bereits bei der Ableitung aus den konsolidierten Daten erfolgt sind und nicht erneut ausgeführt werden müssen. Im Beispiel werden die konsolidierten Umsätze zu einem Gesamtumsatz der Periode aufsummiert und bilden einen einzigen Datensatz. Extern bezogene Daten müssen zur Sicherstellung von Konsistenz und Qualität zunächst in Geschäftsdaten überführt und somit mit dem lokalen Unternehmensdatenmodell vereint werden, bevor sie im Data Warehouse verwendet werden können (vgl. Devlin, 1997). Die dauerhafte Speicherung konsolidierter Daten erscheint zunächst überflüssig und eine temporäre Datenhaltung ausreichend. Gegen diese Verfahrensweise spricht, dass neue, nicht vorhergesehene Bedarfe an Daten schneller und mit weniger Aufwand befriedigt werden können weil eine erneute aufwändige Konsolidierung entfällt. Unter Umständen wird das Unternehmensdatenmodell allein in dieser Schicht verwirklicht, dadurch wird die Verständlichkeit des Modells erhöht. Dies kann nützlich sein, wenn sich bei der Entwicklung einer neuen Applikation auf das Modell bezogen wird. Im Bereich der Konsolidierung konzentriert sich die Verantwortung für die Sicherung der Datenqualität. Um dafür eine langfristig stabile Grundlage zu schaffen, müssen die konsolidierten Daten persistent gespeichert werden. Zudem wird redundante Datenhaltung im Entscheidungsunterstützungssystem vermieden, da eine einzige Quelle für die abgeleiteten Daten geschaffen wird und nicht mehr auf die Echtzeitdaten verschiedener operativer Systeme zugegriffen werden muss. Besonders das Reengineering operativer Systeme wird durch die Trennung der Systemlandschaft in OLTP-System und Entscheidungsunterstützungssystem erleichtert, da historische Daten hoher Granularität bereits im Data Warehouse abgelegt und für Analysen verfügbar sind (vgl. Devlin, 1997).

2.2 Daten und Architektur

9

2.2.2 Metadaten Nur in Verbindung mit Metadaten können gespeicherte Daten aussagekräftig interpretiert werden. Die Ziffer 5 wird erst durch den Zusatz der Einheit Euro als Geldbetrag verstanden. Unter Metadaten versteht man die Abstraktion betrieblicher Datenobjekte. Sie beschreiben unternehmensweit Daten, Funktionen sowie Komponenten, dokumentieren die Verknüpfungen zwischen Daten und Geschäftsprozessen und dienen der Organisation der Benutzerberechtigungen. Metadaten werden bei der Entwicklung und Anwendung der operativen Systeme erstellt. Sie befinden sich zum Beispiel in Datenbankkatalogen oder werden von Werkzeugen für die Softwareentwicklung erstellt (vgl. Inmon 1999e). Sie werden im Rahmen der Datenmodellierung und Datenübernahme ins Data Warehouse übertragen und konsolidiert (vgl. Inmon, 1999c). Daten externer Quellen werden um entsprechende Metadaten ergänzt, bevor sie in das System aufgenommen werden. Erst die Metadaten ermöglichen ein schnelles und sicheres Auffinden der benötigten Daten. Aus Anwendersicht unterteilen sich die Metadaten in betriebswirtschaftliche und technische (vgl. Fuller, 2002c, und Inmon, 1999g). Betriebswirtschaftliche Metadaten sind für geschäftliche Anwender relevant (vgl. McDonald et al., 2002), es handelt sich um Kontextinformationen wie etwa die Terminologie betrieblicher Kommunikation oder das Unternehmensmodell. Technische Metadaten dagegen richten sich an das IT-Personal, sie liefern Informationen, die zur Administration der Systeme benötigt werden wie etwa den Datentyp oder Zugriffsstatistiken (vgl. Devlin, 1997). Die Metadaten werden im Metadaten Repository konsistent abgelegt und können dort bei Bedarf eingesehen werden. Es wird mit dem Ziel verwendet, einen optimalen Informationsgewinn für alle Anwender zu gewährleisten und so den Aufwand für Aufbau und Betrieb des Data Warehouse zu minimieren (vgl. Inmon, 1999f). Metadaten sind stabil, d.h. sie unterliegen nur geringen zeitlichen Änderungen. Findet eine Änderung einzelner Metadaten statt, müssen vorherige Versionen im System verbleiben, um das Verständnis zeitlich zurückliegender Datensätze zu erhalten (vgl. Sattler und Saake, 2004, und Inmon, 1999h). Mit dem Common Warehouse Metamodel (OMG Standard 1999) und dem Open Information Model (Standard der Metadata Coalition) wurden Standards zur Definition und zum Austausch von Metadaten formuliert (vgl. Inmon, 1999e). 2.2.3 Komponenten Die Komponenten eines Data Warehouse Systems können in drei Funktionsgruppen gegliedert werden. Arbeitsbereich, Basisdatenbank, Data Warehouse und Repository dienen der Datenhaltung. Extraktion, Transformation, Laden und Analysewerkzeuge unterstützen den Anwender im Data Warehouse Prozess. Die Steuerungs- und Kontrollfunktionen werden durch Data Warehouse Manager,

10

2 Theoretische Grundlagen der Data Warehouse Technologie

Metadaten Manager und Monitor bereitgestellt. Nachstehende Abb. 2.1. Komponenten eines Data Warehouse Systems (vgl. Bauer und Günzel, 2001) zeigt mit der Referenzarchitektur die Anordnung der Komponenten im Data Warehousing und ihre Beziehungen:

Abb. 2.1. Komponenten eines Data Warehouse Systems (vgl. Bauer und Günzel, 2001)

Der Arbeitsbereich ist eine der zentralen Datenhaltungskomponenten und dient der temporären Speicherung der Echtzeitdaten. Die zur Konsolidierung notwendigen Operationen werden direkt im Arbeitsbereich ausgeführt, nach Abschluss der Transformation werden die Daten in die Basisdatenbank geladen. Die Quelldaten der operativen Systeme bleiben somit unverändert und die Übernahme fehlerhafter Daten in das Data Warehouse wird vermieden. Aufgabe der Basisdatenbank ist die Bereitstellung detaillierter, historischer, konsistenter, modellierter und normalisierter Daten für die Weiterverwendung im Data Warehouse. Das Data Warehouse enthält die abgeleiteten Daten und stellt sie für Analysezwecke bereit. Die Metadaten über Geschäftsdaten, Funktionen und Abläufe sind im Repository abgelegt. Ausschnitte der Datenbasis des Data Warehouse Systems aus Basisdatenbank und Data Warehouse können aus Gründen der Performance und Übersichtlichkeit in so genannten Data Marts redundant gespeichert werden (vgl. Inmon, 1999d). Da sich die zu durchsuchende Datenmenge verkleinert, wird die Verarbeitung von Anfragen beschleunigt. Außerdem kann durch die physische Partitionierung eine effiziente Zugriffssteuerung vorgenommen werden (vgl. Holthuis, 1999). Der Einsatz von Data Marts muss sorgfältig überdacht werden, da den Vorteilen einige Nachteile gegenüberstehen. Die Wahrung der Konsistenz wird erschwert, da unter Umständen einzelne Abteilungen individuelle Veränderungen nur lokal in Data Marts vornehmen, um diese möglichst gut ihren Bedürfnissen anzupassen. Der Betrieb von Data Marts verursacht hohe Kosten für zusätzliche Hard- und Software, einmal implementierte Strategien können zudem nicht ohne

2.3 Datenmodell

11

erheblichen Aufwand geändert werden. Es ist also empfehlenswert, die Data Marts ausschließlich über das zentrale Data Warehouse System zu befüllen (vgl. Anahory und Murray, 1997). Die Übertragung der Daten aus den internen und externen Datenquellen in den Arbeitsbereich erfolgt über die Extraktionskomponente. Die Funktion kann periodisch, auf Anfrage, ereignisgesteuert oder sofort gestartet werden und überträgt die Daten über Schnittstellen in das Data Warehouse System. Die Transformationskomponente bereitet die Daten für den Konsolidierungsprozess auf, sie werden in ein einheitliches Format überführt und von Fehlern bereinigt. Zum Erkennen von Auffälligkeiten können Data Mining Verfahren ausgeführt werden. Nach der Transformation überträgt die Ladekomponente die Daten zur persistenten Speicherung in die Basisdatenbank und von dort in das Data Warehouse. Die Ladevorgänge können online (die Datenbasis steht den Nutzern weiterhin zur Verfügung) oder offline (die Datenbasis wird für den Ladevorgang gesperrt) erfolgen. Die Steuerung der Metadatenverwaltung erfolgt über den Metadaten Manager. Er stellt Werkzeuge für Zugriff, Anfrage, Navigation sowie Versions- und Konfigurationsverwaltung bereit. Monitoring Software überwacht Datenquellen auf Manipulationen des Datenbestandes. Es können verschiedene Strategien zur Überwachung eingesetzt werden, so können zum Beispiel aktive Datenbankmechanismen (Trigger) bei einer Änderung einer Tabelle ausgelöst werden. Eine weitere Möglichkeit ist die Verwendung von Log – Dateien, welche die einzelnen Änderungen protokollieren, oder Delta-Snapshots, die den kompletten Datenbestand periodisch erfassen und paarweise auf Unterschiede untersucht werden. Auch die den Datensätzen zugeordneten Zeitstempel können für eine Identifikation der seit der letzten Datenübernahme veränderten Tupel verwendet werden (vgl. Bauer und Günzel, 2001).

2.3 Datenmodell Modelle lassen Gesetzmäßigkeiten der Systemstruktur erkennen und helfen dem Betrachter beim Verständnis der Zusammenhänge, um Konsequenzen seiner möglichen Aktionen mit der Umwelt abschätzen zu können. Ein Modell ist ein abstraktes, immaterielles Abbild realer Strukturen bzw. des realen Verhaltens für Zwecke des Subjekts (vgl. Rautenstrauch, 2003). Das Datenmodell enthält korrekte und aussagekräftige Definitionen der Unternehmensdaten. Es identifiziert valide konstante Strukturen der Daten, aus denen Informationen abgeleitet werden können, und es zeigt Unterschiede und Gemeinsamkeiten zwischen Daten verschiedener Quellen auf. Daneben enthält es eine Reihe von Regeln zur Datenverwendung, damit die Konsistenz, Korrektheit und Vollständigkeit gewahrt bleiben. Die Abbildung erfolgt auf konzeptueller Ebene, die vom Zielsystem weitgehend unabhängig ist (vgl. Holthuis, 1999).

12

2 Theoretische Grundlagen der Data Warehouse Technologie

Das Datenmodell bildet die Grundlage zur Kommunikation zwischen IT-Abteilung und Entscheidungsträgern. Für das Verständnis bei Entscheidungsträgern ist es erforderlich, dass das Modell möglichst einfach und leicht überschaubar und somit ohne DV-Fachkenntnisse schnell nachvollziehbar ist. Mitarbeiter der IT-Abteilung hingegen verwenden es, um die Anwendungen eng an den Erfordernissen des Unternehmens orientiert zu entwickeln. Da das Datenmodell etwa zur Erstellung eines Datenbankschemas herangezogen wird, ist eine hinreichende Detaillierung notwendig. Die Anforderungen von Entscheidungsträgern und IT-Abteilung an das Datenmodell divergieren also. Eine Lösung kann zum Beispiel eine Unterteilung in drei Schichten sein, nämlich Fach-, DV- und Implementierungskonzept. Im Fachkonzept wird die betriebswirtschaftliche Problemstellung semiformal und implementierungsunabhängig beschrieben. Das Fachkonzept wird im DV-Konzept um Anforderungen und Restriktionen der DV-technischen Umsetzung angereichert, die Formulierung der DV-technischen Umsetzung erfolgt schließlich im Implementierungskonzept (vgl. Bauer und Günzel, 2001). Eine Implementierung dieses Konzepts findet sich in der Modellierungssoftware ARIS Toolset wieder, das mit Organisations-, Daten-, Funktions- und Steuerungssicht das gesamte Unternehmen abbildet. Das Datenmodell ist Teil dieses umfassenden Unternehmensmodells. Die Organisationssicht beinhaltet alle Organisationseinheiten eines Unternehmens und die Beziehungen zwischen ihnen, die Datensicht beschreibt eine Abstraktion der Datenobjekte und ihrer Zusammenhänge. Vorgänge und Funktionen, die durch das Informationssystem unterstützt werden sollen, werden durch die Funktionssicht wiedergegeben. Die zentrale Steuerungssicht stellt die Verbindungen zwischen den Objekten der Organisations-, Daten- und Funktionssicht dar, um Geschäftsprozesse abzubilden (vgl. Karcher, 2005). Die Verbindungen zwischen den einzelnen Sichten werden durch das ARIS Haus repräsentiert. Alle diese Sichten lassen sich jeweils in Fach-, DV- und Implementierungskonzept unterteilen. Das ARIS Toolset ermöglicht also eine Erstellung umfassender Modelle mit variablem Detaillierungsgrad und bietet daher für Fach- und Führungskräfte gleichermaßen ein großes Nutzenpotential (vgl. Karcher, 2005). 2.3.1 Fakten, Kennzahlen und Dimensionen Die Geschäftsdaten eines Data Warehouse werden in Fakten, Kennzahlen und Merkmale unterteilt. Fakten sind numerische Messgrößen, die betriebliche Sachverhalte beschreiben (vgl. Sattler und Saake, 2004). Fakten werden auch als Basiskennzahlen bezeichnet, da aus ihnen durch arithmetische Operationen weitere Kennzahlen abgeleitet werden. Beispiele sind Umsatz und Kosten als Fakten, aus denen die Kennzahl Gewinn berechnet wird.

2.3 Datenmodell

13

Kennzahlen sind Fakten oder aus Fakten abgeleitete Größen. Sie haben informativen Charakter und dienen dazu, durch systematisches Vergleichen Ursachen und Trends ableiten zu können (vgl. Rautenstrauch, 2004). Kennzahlen gewinnen erst an Aussagekraft, wenn ihnen weitere beschreibende Attribute wie ein Verkaufsland oder Quartal zugeordnet werden. Merkmale sind betriebswirtschaftliche Bezugsgrößen, nach denen eine sinnvolle Gruppierung von Kennzahlen möglich ist (vgl. Mehrwald, 2004). Das Datenmodell eines Data Warehouse kann anhand eines Würfels visualisiert und als Grundlage einer Anfrage gesehen werden. Dessen Achsen werden als Dimensionen bezeichnet, auf denen die Kriterien zur Einordnung der Daten abgetragen werden, während im Inneren des Würfels an den Schnittpunkten der Dimensionsausprägungen die Daten enthalten sind. Dimensionen beschreiben die technische Struktur der Daten und so eine mögliche Sicht auf die assoziierte Kennzahl (vgl. Sattler und Saake, 2004). Der gesamte Würfel ist also wiederum aus mehreren kleinen Würfeln zusammengesetzt, die auf elementarer Ebene einzelne Datensätze repräsentieren. In der Praxis geht die Anzahl der Dimensionen über drei hinaus, dies prägt den Begriff der Multidimensionalität, kann jedoch nicht mehr sinnvoll grafisch veranschaulicht werden.

Abb. 2.2. Datenwürfel

Die Dimensionen werden hinsichtlich ihres Typs unterschieden, ihre Ausprägungen können diskrete Werte oder einen Wertebereich repräsentieren. Nicht-hierarchische Dimensionen verfügen über eine einfache interne Struktur, die durch keine vertikalen Beziehungen gekennzeichnet ist. Daher ist es nicht möglich, Aggregationen über mehrere Ausprägungen zu bilden (vgl. Holthuis, 1999). Ein Beispiel ist eine Dimension mit den Elementen Ist, Soll und Abweichung. Diese Elemente

14

2 Theoretische Grundlagen der Data Warehouse Technologie

können nicht in einem einzigen Hierarchiebaum so angeordnet werden, dass sich jeweils aus der Summe der Kindknoten der Wert des Vaterknotens ergibt. Hierarchische Dimensionen dagegen ermöglichen unterschiedliche Verdichtungsstufen und Niveaus, die anhand fester Regeln und Berechnungsvorschriften gebildet werden. Eine Produkthierarchie kann aus den Verdichtungsstufen Produkthauptgruppe und Produktgruppe bestehen, die Werte der Produkthauptgruppen sind mit der Summe der jeweils untergeordneten Produktgruppen identisch. Dimensionen des kategorischen Typs verwendet man, wenn einzelne Ausprägungen für die Problemstellung von herausragender Bedeutung sind. Zum Beispiel können beim Marketing detaillierte Kundeninformationen derart bedeutsam sein, dass die Ausprägungen der Kundendimension eigenen Dimensionen zugeordnet werden.

Abb. 2.3. Kategorischer Dimensionstyp

Innerhalb von Dimensionen kann es zu einer Reihe von Strukturanomalien kommen (vgl. Holthuis, 1999). So ist es etwa für die Durchführung von Aggregationsoperationen von Bedeutung, ob einer Dimension ein ausgeglichener Hierarchiebaum zugrunde liegt. Zum Beispiel ist eine weltweite Auswertung nach Bundesländern nicht möglich. Außerdem kann in einem Hierarchiebaum nicht gewährleistet werden, dass jeder Knoten lediglich einen Vaterknoten besitzt (so genannte multiple Hierarchie). So kann eine Rechnungslegungsabteilung für zwei oder mehr übergeordnete Abteilungen tätig sein. Sollen nun auf der übergeordneten Ebene die Personalkosten verglichen werden, so ist eine eindeutige Zurechnung der Kosten dieser Rechnungslegungsabteilung nicht ohne weiteres möglich. In einer Dimension kann es der Fall sein, dass mehrere Ausprägungen jeweils alle erhobenen Werte enthalten. Die Anzahl der Ausprägungen auf der darunter liegenden Ebene sowie die Aufteilung der Elemente zwischen diesen unterscheiden sich. Als Beispiel kann eine gleichzeitige Unterteilung in der Kundendimension nach Familienstand und Alter dienen. In beiden Gruppen sind sämtliche Kunden erfasst, die Anzahl der Untergruppen kann variieren. Es kann weiterhin erforderlich sein, Dimensionshierarchien zu verändern, wenn beispielsweise eine Produktgruppe so umsatzstark wird, dass sie zur Hauptgruppe aufsteigen soll.

2.3 Datenmodell

15

2.3.2 Modellierung von Zeit Da im Data Warehouse historische Daten gespeichert werden, kommt der zeitlichen Dimension eine besondere Bedeutung zu (vgl. Kimball, 1997). Grundsätzlich ist zwischen Zeitpunkt- und Zeitraumbezug zu unterscheiden (vgl. Holthuis, 1999). Mit zeitpunktbezogenen Daten werden Bestände im Unternehmen erfasst, die Zeit zwischen den Bestandsaufnahmen sollte zur Verstärkung der Aussagekraft konstant gehalten werden. Bei zeitraumbezogenen Daten sind die konsolidierten Daten in der feinsten für die Auswertungen benötigten Granularität in das Data Warehouse einzuspielen. Eine Vergleichbarkeit der erfassten Daten ist nur gegeben, wenn die Erfassungszeiträume identisch sind. Kennzahlen werden in einem Unternehmen unter Umständen mit unterschiedlichem Zeitbezug abgebildet, so können etwa tägliche Umsätze in der Kostenrechnung zu Tageskursen und in der Rechnungslegung mit einem Durchschnittswert des jeweiligen Monats bewertet werden. Probleme bei der Modellierung von Zeit entstehen auch dadurch, dass bei zeitraumbezogener Erfassung die Daten nicht unbedingt korrekt in die nächst höhere Ebene überführt werden können. So können aus wochenweise erhobenen Daten durch mathematische Operationen keine Monatsdaten erzeugt werden. Außerdem können sich einzelne Zeiträume auf ein- und derselben Stufe überschneiden, wenn etwa Daten nach Jahreszeiten und ebenfalls nach Quartalen erfasst werden. Weitere Schwierigkeiten entstehen, da vielfältige abzubildende Zeiträume existieren (z.B. Kalenderjahr und Fiskaljahr, weitere Abweichungen zwischen unterschiedlichen Staaten möglich). 2.3.3 Multidimensionale Anfragestrukturen Anders als die Datenbanken operativer Systeme, ist das Data Warehouse komplexen Anfragen ausgesetzt, deren Verarbeitung mit einem hohen zeitlichen Aufwand verbunden ist. Die Anfragen sollen sowohl flexibel als auch intuitiv zu erstellen sein, dem Anwender sollen dazu keine tieferen Kenntnisse der internen Strukturen der Datenhaltung abverlangt werden. Die multidimensionale Struktur gewährleistet kürzere Antwortzeiten, da sie auf zeilenübergreifende Summenoperationen optimiert ist. Ein relationales Datenbanksystem müsste zunächst die korrespondierenden Attribute durch ihre Werte identifizieren. Die Notwendigkeit dieser zeitaufwändigen Join-Operation entfällt bei multidimensionalen Strukturen (vgl. Sattler und Saake, 2004). Es besteht der Bedarf einer speziellen Anfragesprache für multidimensionale Systeme sowie der Bereitstellung einer leicht zu erlernenden Navigation im Datenbestand über eine intuitive Benutzeroberfläche. Mit der Komplexität einer Anfrage sollte der Anwender möglichst nicht konfrontiert werden. Als letzte Anforderung ist eine entsprechende Ergebnisaufbereitung zu nennen, damit die Resultate vom Anwender in Entscheidungen umgesetzt werden können (vgl. Holthuis, 1999).

16

2 Theoretische Grundlagen der Data Warehouse Technologie

Tabelle 2.1. OLAP Charakteristika Typische Operation Ansichten der Daten Datenmenge je Transaktion Niveau der Daten Zeitbezug der Daten Verarbeitungseinheit

Read-only Benutzerdefiniert Groß Verdichtet / aufbereitet Historisch, gegenwärtig oder zukünftig Matrizen, sachbezogen, übergreifend

OLAP stellt also unternehmensinterne Informationen in aufbereiteter und verdichteter Form bereit. Von Interesse sind dabei nicht mehr einzelne Transaktionen, sondern die Analyse managementrelevanter Kenngrößen. OLAP eignet sich aufgrund der intuitiven Datenbearbeitung und Navigation innerhalb der verschiedenen Dimensionen und Verdichtungsstufen zur Unterstützung von Situationsanalyse und Planung, es stellt jedoch keine Methoden für die Zielbildung oder Prognose bereit. Es kann lediglich versucht werden, für bestimmte Kenngrößen anhand historischer Daten eine Entwicklung abzuleiten und zu visualisieren. So können mögliche Problemlösungen vorgeschlagen und analysiert werden, die endgültige Entscheidung ist aber stets vom Manager selbst zu treffen. Das eigentliche Haupteinsatzgebiet des OLAP liegt in der Unterstützung von Kontrollaufgaben wie der Ad hoc-Berichterstattung und dem Exception Reporting. Auch hier bleibt dem Anwender die Interpretation der vom System zurück gelieferten Werte vorbehalten (vgl. Holthuis, 1999). 2.3.4 OLAP Operationen Die typischen Operationen auf multidimensionalen Datenstrukturen während der Datenanalyse werden als Pivotierung, Roll-Up, Drill-Down, Drill-Across, Slicing und Dicing bezeichnet. Sie lassen sich anhand des bereits beschriebenen Datenwürfels erklären (vgl. Sattler und Saake, 2004, und Kimball, 1996a). Pivotierung: Diese Operation dient der Analyse der Daten aus verschiedenen Perspektiven. Hierzu wird der Datenwürfel durch Vertauschen der Dimensionen gedreht, daher wird die Pivotierung ebenfalls als Rotation bezeichnet.

Abb. 2.4. Pivotierung

2.3 Datenmodell

17

Roll-Up: Das Roll-Up erzeugt neue Informationen durch Aggregation entlang des Verdichtungspfades. Die Anzahl der Dimensionen bleibt somit erhalten, es wird nur auf einzelnen Dimensionen ein höheres Verdichtungsniveau erreicht. Drill-Down: Das Drill-Down verhält sich komplementär zum Roll-Up, es wird anhand einer Dimensionshierarchie von aggregierten zu Detaildaten navigiert.

Abb. 2.5. Drill-Down und Roll-Up

Drill-Across: Wechsel von einem Datenwürfel zu einem anderen, dies kann etwa erfolgen, wenn Ist- und Soll-Daten in separaten Würfeln gehalten werden. Slice: Durch das Herausschneiden von Schichten aus dem Würfel werden individuelle Sichten erzeugt und die Dimensionalität verringert (zum Beispiel Betrachtung der Werte des aktuellen Jahres).

Abb. 2.6. Slice

Dice: Die Dice Operation extrahiert einzelne Teilwürfel und schafft so neue Sichten auf die Daten. Die Dimensionalität bleibt erhalten, jedoch verändert sich die Hierarchie einzelner Dimensionen, wenn nur über bestimmte Produkte oder Regionen analysiert wird.

18

2 Theoretische Grundlagen der Data Warehouse Technologie

Abb. 2.7. Dice

2.3.5 ADAPT Ein erster Ansatz um multidimensionale Datenstrukturen zu modellieren, ist ADAPT (Application Design for Analytical Processing Technologies). Es wurde mit dem Ziel entwickelt, einen von der Implementation unabhängigen Modellierungsstandard für die Kommunikation zwischen Entwicklern und Anwendern zu schaffen (vgl. Bulos und Forsman, 2001). ADAPT besteht aus den neun Elementen Hypercube, Dimension, Dimensionselement und Elementgruppe, Hierarchie und Hierarchieebene, Attribut, Berechnungsvorschrift und Contextcube.

Abb. 2.8. ADAPT Notation

2.3 Datenmodell

19

Der Hypercube, ähnlich dem bereits beschriebenen Würfel, enthält eine mit Dimensionen assoziierte Kennzahl, die durch eine multidimensionale Datenstruktur beschrieben wird. Die Dimensionen sind aus Dimensionselementen aufgebaut, die in einer Hierarchie, also einem eindeutigen Konsolidierungspfad, angeordnet sein können. Parallele Hierarchien können im Modell auch abgebildet werden, so kann es bei der zeitlichen Dimension sowohl das Kalenderjahr als auch das Fiskaljahr geben.

Abb. 2.9. Dimension und Hierarchie

Es können für das Verständnis besonders relevante Ausprägungen einer Dimension explizit mit aufgeführt werden. So wird eine detailliertere Sicht ermöglicht oder ein Beispiel gegeben, etwa ein bedeutendes Produkt. Die Ausprägungen können auch auf Gruppenebene hervorgehoben werden, ein Beispiel ist die Gruppe der Stammkunden. Zusätzliche Informationen zu Dimensionen wie ein Produktname oder die Anzahl Arbeitsstunden eines Tages können als Attribute eingefügt werden. Sie werden verwendet, wenn sie das Verständnis des Modells erleichtern. So kann beispielsweise hervorgehoben werden, dass ein Produkt über ein Attribut Käufermarkt verfügt, welches mit der Dimension Region verknüpft ist.

20

2 Theoretische Grundlagen der Data Warehouse Technologie

Abb. 2.10. Dimensionselemente, Elementgruppen und Attribute

Berechnungsvorschriften in ADAPT geben an, aus welchen Elementen ein Dimensionselement oder eine Kennzahl hervorgeht. Allerdings wird die Regel, nach der die Berechnung ausgeführt wird, nicht explizit genannt. Die Vorschriften sind nicht für die Entwicklung der Datenschemas notwendig, aber für die Umsetzung des Modells in das Data Warehouse nützlich.

Abb. 2.11. Berechnungsvorschrift

Der Contextcube ist wie der Hypercube aufgebaut, sein Inhalt wird aber durch Dimensionselemente und Elementgruppen eingeschränkt, wenn eine partielle Be-

2.3 Datenmodell

21

trachtung gewünscht ist. So können beispielsweise Vorhersagen für ein Hauptprodukt in einem Contextcube, der aus dem Produkt Hypercube und einer Berechnungsvorschrift hervorgeht, gesondert aufgeführt werden. Um das Datenmodell aufzustellen, werden die als bedeutsam identifizierten Fakten und Kennzahlen mit ihren Merkmalen in den Hypercube und dessen Dimensionen überführt. Anschließend werden die Strukturen innerhalb der Dimensionen untersucht, ob sie hierarchisch, nicht-hierarchisch oder kategorisch abgebildet werden sollen. Eine von anderen Ausprägungen abhängige Dimension wird unter dem Begriff Property-Dimension geführt. Sie stellt eine logische Verknüpfung dar, so ist die Dimension Lebenszyklusphase eines Produktes von der Existenz der Dimension Produkt abhängig. Das ADAPT-Modell ist in der betrieblichen Praxis von Unternehmensberatungen entwickelt worden und wird für die Modellierung der Struktur eines Data Warehouse empfohlen. Später wurde das um eine Historisierung von Hierarchien erweiterte T-ADAPT Konzept veröffentlicht, in dem Hierarchien Gültigkeitszeiträume zugewiesen werden können (vgl. Hahne, 2004). Der besondere Vorteil einer Modellierung in ADAPT wird in der verbesserten Kommunikation auf fachkonzeptueller Ebene gesehen, die durch die selbsterklärende Syntax des Modells unterstützt wird. Das Verständnis der betriebswirtschaftlichen Anforderungen ist Grundlage für die Entwicklung einer leistungsfähigen Software. Die multidimensionalen Strukturkomponenten finden sich in den Symbolen des ADAPT-Modells wieder. Sämtliche Aspekte der abzubildenden Zusammenhänge werden in einer einzigen Sicht erfasst. Dadurch kann das Modell zunehmend komplex und somit schwer verständlich werden, so dass der Nutzen als Diskussionsgrundlage eingeschränkt wird. Wird dieser Aspekt bei der Modellierung beachtet, so stellt ADAPT die zurzeit beste verfügbare Lösung zur Abbildung multidimensionaler Strukturen dar. 2.3.6 Speicherung multidimensionaler Daten, Star- und SnowflakeSchema Aufgrund der Data Warehouse Architektur müssen multidimensionale Datenbanken in einer Client-Server-Umgebung arbeiten können und die Auswertung der Daten durch verschiedene Front-End Werkzeuge unterstützen. Betriebswirtschaftlich bedeutsame und häufig wiederkehrende Aspekte wie die Modellierung von Zeit sollten über Standarddimensionen mit vordefinierter Struktur zur Verfügung gestellt werden, so dass beim Aufbau einer neuen Datenbank nicht stets neue umfangreiche Dimensionshierarchien anzulegen sind (vgl. Holthuis, 1999). Ein klarer Trend im Bereich der multidimensionalen Datenbanken ist nicht abzusehen. Ein Teil der kommerziell verfügbaren Systeme setzt das multidimensionale Modell auch in die physische Speicherstruktur um, andere Ansätze basieren auf relationalen Datenbanken mit einer den Daten angepassten Struktur. Es existiert derzeit kein Standard, der festlegt, welche Grundfunktionalitäten ein multidimensionales Datenbanksystem bereitstellen muss. Es gibt weder eine ein-

22

2 Theoretische Grundlagen der Data Warehouse Technologie

heitliche Form des Zugriffs, wie SQL für relationale Datenbanken, noch allseits unterstützte Anwendungs-Programm-Schnittstellen (API). Multidimensionales OLAP (MOLAP) stellt in der Regel ein hohes Maß an Funktionalität zur Anaylse und Auswertung der Daten bereit. Dieser Teil der Datenbanksysteme verfolgt den so genannten Hypercube Ansatz, bei dem alle Daten in einer multidimensionalen Matrix gespeichert werden. Der Datenwürfel wird vollständig im Hauptspeicher gehalten, das Antwortzeitverhalten ist daher sehr günstig. Allerdings ist die Datenmenge durch die Kapazität des Hauptspeichers begrenzt (vgl. Sattler und Saake, 2004). Es kommt außerdem zu Problemen mit dünn besiedelten Matrizen, da eine Zelle mit einem initialen oder NULL-Wert genau so viel Ressourcen an Speicherplatz und Verarbeitungskapazität belegt wie eine Zelle, die einen relevanten Eintrag enthält. Spezielle Verfahren wie die Identifizierung und anschließendes Löschen von leeren Zellen mit einhergehender Komprimierung der Matrix sollen helfen, mit dieser in der Realität häufig auftretenden Problematik umzugehen (z.B. kauft ein Kunde in der Regel nur einen sehr kleinen Ausschnitt der gesamten Produktpalette eines Unternehmens). Mit steigender Anzahl Dimensionen wächst der Speicherbedarf überproportional an, daher sind Möglichkeiten zu diskutieren, die Anzahl der Dimensionen sowie die Größe der Matrizen zu reduzieren (vgl. Holthuis, 1999). Beim relationalen OLAP (ROLAP) werden die Daten in mehreren unterschiedlichen Matrizen für die verschiedenen Anwendungsgebiete gespeichert (so genannter Multicube-Ansatz). Die daraus entstehende Struktur wird auch als StarSchema bezeichnet. Es klassifiziert die Daten in zwei Gruppen: Kennzahlen und Dimensionsdaten. Die Kennzahlen stehen im Mittelpunkt der Analyse, während Dimensionsdaten die relevanten Dimensionen beschreiben und entlang der Achsen der multidimensionalen Matrix abgetragen werden. Im Star-Schema werden sowohl Kennzahlen als auch Dimensionsdaten in Tabellen gespeichert. Die so genannten Faktentabellen, in denen die Kennzahlen enthalten sind, stehen im Zentrum, die Dimensionsdaten sind um sie herum angeordnet. Sie sind nur mit den Faktentabellen und somit nicht untereinander verknüpft, so dass eine sternförmige Anordnung entsteht (vgl. Humm und Wietek, 2005). Das Star-Schema ist dahingehend eingeschränkt, dass keine hierarchischen Strukturen innerhalb der Dimensionen, wie sie in der Realität üblich sind, dargestellt werden können. Die semantischen Beziehungen müssen somit gesondert hinterlegt und können als mögliche Verdichtungsstufen in einer zusätzlichen Dimensionstabelle gespeichert werden. Die logischen Abhängigkeiten zwischen den Hierarchiestufen lassen sich jedoch in der Datenbankstruktur nicht darstellen, es handelt sich lediglich um eine Auflistung der möglichen Verdichtungsstufen (vgl. Sattler und Saake, 2004).

2.3 Datenmodell

23

Abb. 2.12. Star-Schema

Alternativ können die Dimensionsausprägungen einer Hierarchieebene jeweils in einer eigenen Tabelle abgelegt werden. Dieses so genannte Snowflake-Schema geht durch Normalisierung der Dimensionstabellen aus dem Star-Schema hervor. Die Dimensionstabellen enthalten dann nicht mehr sämtliche Dimensionselemente, sondern lediglich Beschreibungen der Dimensionshierarchien. Sie sind gemäß der Dimensionshierarchie über Schlüsselattribute untereinander verknüpft, jedoch verfügt lediglich die Dimensionstabelle auf höchster Granularität über eine direkte Verbindung zur Faktentabelle (vgl. Sattler und Saake, 2004).

Abb. 2.13. Snowflake-Schema

24

2 Theoretische Grundlagen der Data Warehouse Technologie

Der Vorteil des Snowflake-Schemas liegt in zum Teil deutlich kürzeren Zugriffszeiten, allerdings erschwert die Architektur das Navigieren in den Tabellen. Der Nachteil der höheren Komplexität wird nur dann kompensiert, wenn die Dimensionstabellen sehr groß sind und viele Attribute der Dimensionshierarchie auf niedrigen Ebenen liegen. Diese Lösung stößt außerdem an ihre Grenzen, wenn innerhalb einer Dimension, wie beispielsweise bei der Modellierung von Zeit, multiple Hierarchien vorkommen. Beiden Ansätzen zur Speicherung multidimensionaler Daten ist es somit gemein, dass semantische Abhängigkeiten zwischen den einzelnen Elementen einer Verdichtungsebene in einem relationalen Datenbanksystem nicht vollständig wiedergegeben werden können. Es handelt sich bei den Beziehungen um Meta-informationen, die von einem separaten Metainformations-System verwaltet werden müssen (vgl. Sattler und Saake, 2004). Bei der Verwendung von Star- und Snowflake-Schemata treten keine Probleme dünn besiedelter Matrizen auf, denn es werden in den Faktentabellen nur Dimensionskombinationen aufgeführt, denen auch ein konkreter Wert zugeordnet ist. Dennoch wirken sich auch hier eine große Anzahl Dimensionen oder eine hohe Komplexität der Dimensionshierarchien negativ auf die Performance aus, so dass hier ebenfalls Verfahren zur Reduktion der Anzahl und der Hierarchien von Dimensionen zum Einsatz kommen. Außerdem nimmt aufgrund der vielfältigen Verknüpfungsmöglichkeiten unter den Dimensionen die Faktentabelle sehr schnell ein großes Ausmaß an (vgl. Holthuis, 1999). Dadurch, dass die Anfragen meist mehrere Tabellen betreffen, müssen in traditionellen Datenbanksystemen diese Tabellen durch Join-Operationen verknüpft werden. Die Ermittlung der optimalen Reihenfolge für die Verknüpfung der Tabellen ist hierbei essentiell, da sie die Antwortzeit der Anfrage nachhaltig beeinflusst. In relationalen Datenbanksystemen wird diese Reihenfolge dadurch optimiert, dass mit Tabellen begonnen wird, die direkte Beziehungen zum Beispiel in Form von Schlüsselattributen aufweisen. Diese Art von Beziehungen existieren jedoch im Star- und Snowflake-Schema nur zwischen den Fakten- und den Dimensionstabellen, daher ist diese Strategie für multidimensionale Strukturen ungeeignet. Beim Ausführen paarweiser Join-Operationen relationaler Datenbanktabellen wird aufgrund der fehlenden Beziehungen zwischen den Dimensionstabellen zwingend die Faktentabelle mit berücksichtigt. So entsteht bereits zu einem frühen Zeitpunkt ein großes Zwischenergebnis und die Verarbeitungszeit der Operation wird unnötig lang (vgl. Sattler und Saake, 2004). Der Join mit der Faktentabelle kann aber auch bis zum letzten Verbund herausgezögert werden, wenn zunächst über die kleineren Dimensionstabellen das kartesische Produkt gebildet wird (Betrachtung aller möglicher Joins nicht verknüpfter Spalten). Die Werte der umfangreichen Faktentabelle gehen also nicht in die Zwischenergebnisse ein, diesem Vorteil steht jedoch das aufwändige Generieren des kartesischen Produktes gegenüber. Diese Strategie kommt somit nur zum Einsatz, wenn das kartesische Produkt über die ausgewählten Dimensionstabellen erheblich kleiner ist als die Anzahl der Zeilen in der Faktentabelle (vgl. Holthuis, 1999).

2.3 Datenmodell

25

Von einem Star-Join spricht man, wenn ohne Bildung des kartesischen Produktes mehrere Tabellen in einem Schritt verknüpft werden. Für eine performante Durchführung ist eine Indexierung der Faktentabelle unerlässlich, sie wird als Star-Index bezeichnet. Tests haben ergeben, dass die Verwendung von Star-Joins wesentlich leistungsfähiger ist als der Einsatz des kartesischen Produktes (vgl. Holthuis, 1999). Das Sampling führt Anfragen nur auf einer Stichprobe des Datenbestandes aus. Dies ist bei signifikant kürzerer Antwortzeit oft hinreichend genau (in der Praxis etwa 90% Genauigkeit vollständiger Analysen), wenn durch eine Anfrage lediglich ein Überblick oder erster Eindruck verschafft werden soll. Die Ergebnisse werden in Sampling-Tabellen abgelegt und stehen so auch anderen Applikationen zur Verfügung (vgl. Acharya, Gibbons und Poosala, 1999). Auch parallele Technologien können im Data Warehouse zum Einsatz kommen. Auf dem Markt ist immer leistungsfähigere parallele Hardware verfügbar, Man unterscheidet beim Einsatz paralleler Technologie die Effekte in Speed-Up und Scale-Up. Speed-Up sagt aus, wie sich durch die Steigerung der Hardware Ressourcen die Antwortzeit einer Anfrage verkürzt. Der erlangte Vorteil durch die Abarbeitung zusätzlicher Aufgaben wird dagegen als Scale-Up bezeichnet (vgl. Heiß, 2005). Data Warehouse-Lösungen sind jedoch oft nur schwer skalierbar, da die auszuführenden Anfragen nicht beliebig teilbar sind und zusätzlicher Koordinationsaufwand entsteht. Der Leistungszuwachs verhält sich in der Regel unterproportional zu den Kosten und steigt sogar noch mit der Anzahl eingesetzter paralleler Ressourcen. Außerdem wächst unter Umständen mit der Komplexität der Systeme die Gefahr geringer Zuverlässigkeit, es ist also im Einzelfall sorgfältig zu prüfen, ob der Einsatz paralleler Technologien als rentabel beurteilt werden kann. Parallele Technologien allein reichen also nicht aus, um die Einschränkungen relationaler Datenbanksysteme zu überwinden (vgl. Holthuis, 1999). Das hybride OLAP (HOLAP) zielt darauf ab, die Vorteile des MOLAP und ROLAP zu verbinden. Es sollen sowohl die bestehenden Standards und die Skalierbarkeit relationaler Datenbanksysteme als auch die analytischen Fähigkeiten und die direkte OLAP-Unterstützung einer multidimensionalen Speicherung zum Tragen kommen. Dazu werden die Detaildaten in einer relationalen Datenbank, aggregierte Daten hingegen in einer multidimensionalen Datenbank gespeichert. Die Anforderung aggregierter Daten erfolgt über ein multidimensionales Abfragesystem (vgl. Sattler und Saake, 2004). Dem Star- und Snowflake-Schema liegt die Technologie relationaler Datenbanken zugrunde. Für Datenbanksysteme dieses Typs ist eine Vielzahl an Werkzeugen auf dem Markt erhältlich und auch ein großes Maß an Fachwissen bereits in den Unternehmen vorhanden, so dass eine hohe Akzeptanz der Schemata zu erwarten ist. Mängel bestehen darin, dass relationale Datenbanksysteme und die Standardanfragesprache SQL auf transaktionsorientierte Anwendungen ausgerichtet sind. Einige multidimensionale Funktionalitäten, wie sie etwa für die Standardoperationen Roll-Up oder Drill-Down und die Handhabung der Zeitdimension benötigt werden, können im Star-Schema derzeit nur unter Zuhilfenahme eines zusätzlichen Meta-Informationssystems, das Informationen über die Hierarchien in

26

2 Theoretische Grundlagen der Data Warehouse Technologie

den Dimensionen liefert, bewältigt werden (vgl. Holthuis, 1999). Im SnowflakeSchema sind diese Beziehungen zwar enthalten, es ist jedoch zu beachten, dass die Verständlichkeit der Datenmodelle gewahrt bleibt. Werden diese besonderen Anforderungen bei der Entwicklung eines Data Warehouse berücksichtigt, so sind das Star- und Snowflake-Schema trotz der geschilderten Probleme gut für die Speicherung und Verwaltung multidimensionaler Daten geeignet.

2.4 Datenquellen und Datenqualität Datenquellen gehören faktisch nicht zur Architektur des Data Warehouse dazu. Weil aber die Daten des Data Warehouse aus den Quellen repliziert werden, ist eine nähere Betrachtung dieser sinnvoll. Bei Datenquellen wird zwischen unternehmensinternen und –externen unterschieden, die Daten selbst werden in Geschäftsdaten und Metadaten unterteilt. Die Güte, mit der diese die Anforderungen der Anwender erfüllen, wird als Datenqualität bezeichnet. Wegen ihres bedeutenden Einflusses auf die Akzeptanz eines Data Warehouse ist die Datenqualität ein zentraler Aspekt in der Diskussion um Informationssysteme. 2.4.1 Quellen für Geschäftsdaten Unternehmensinterne Geschäftsdaten werden zum größten Teil aus operativen Systemen gewonnen, da in ihnen die meisten Geschäftsdaten eines Unternehmens enthalten sind. Es können auch Geschäftsdaten aus Managementunterstützungssystemen bezogen werden, um für Auswertungen im Data Warehouse bereitzustehen. Von Anwendern für individuelle Zwecke in lokalen Arbeitsumgebungen erstellte und gepflegte Daten bilden in diesem Zusammenhang die kleinste Datenmenge. Außer den internen werden auch unternehmensexterne Daten in einem Data Warehouse abgelegt. Dies können Marktanalysen über die zukünftige Entwicklung der Nachfrage von Endverbrauchern, Daten über die aktuelle Verfügbarkeit von Produkten eines Zulieferers oder die Bestellmenge des Auftraggebers sein. Die Daten haben gemeinsam, dass sie für Auswertungen unternehmensübergreifender Prozesse benötigt werden. Die Datenquellen werden entsprechend dem Zweck des Data Warehouse ausgewählt (vgl. Sattler und Saake, 2004). Bei integrierten Systemen liegen die Geschäftsdaten meist in einheitlichen Zeichenkodierungen und somit ohne Medienbrüche vor (vgl. Holthuis, 1999). Unterschiede werden erst bei einer systemübergreifenden Zusammenführung der Daten in ein einziges System deutlich, die zumeist von verschiedenen Formaten und Schemata herrühren. Die Güte des Transformationsprozesses zur Überwindung der Heterogenität verschiedener Datenquellen stellt im Hinblick auf die Datenqualität die größte Herausforderung dar.

2.4 Datenquellen und Datenqualität

27

2.4.2 Quellen für Metadaten Metadaten über Datensätze werden in den Anwendungen und Datenbanken im laufenden Systembetrieb erstellt. So wird in Datenbanken beispielsweise das letzte Änderungsdatum eines Datensatzes als so genannter Timestamp abgespeichert oder aber der letzte Zugriff auf ein Objekt in einer Anwendung mit Datum und Nutzer-ID protokolliert. Zu diesen technischen Metadaten, die direkt aus den Quellen bezogen werden und mit relativ geringem Aufwand konsistent zu halten sind, zählt auch das Datenbankschema (vgl. Rahm, 2004). Bei betrieblichen Metadaten handelt es sich um Beschreibungen der Geschäftsregeln und -prozesse sowie begriffliche Definitionen. Sie sind zumeist nicht unmittelbar aus den Datensätzen abrufbar, sondern werden aus den Metadata Repositories bezogen. Ihre Entstehung datiert in die Zeit der Konzeption und Planung operativer Systeme, also vor dem Zeitpunkt der Implementation. Anders als die technischen Metadaten unterliegen die betrieblichen nur selten Veränderungen. Meist erfolgen diese nur dann, wenn ein System an modifizierte Geschäftsprozesse angepasst wird. Dies kann bei einer Änderung der Hierarchieebenen im Unternehmen erfolgen, so muss zum Beispiel das Organigramm angepasst werden, welches Aufschluss über die Datenverantwortlichen gibt (vgl. Devlin, 1997). 2.4.3 Datenqualität Die Güte der bereitgestellten Daten bestimmt, wie präzise und verlässlich Aussagen über einen Sachverhalt formuliert werden können. Je besser die Anwender informiert werden, desto sicherer werden ihre taktischen und strategischen Entscheidungen (vgl. DataFlux, 2005). Mangelhafte Datenqualität führt also zu einer geringen Güte der Informationen und erhöht letztendlich das Risiko von Fehlentscheidungen (vgl. Devlin, 1997, und Knightsbridge, 2005). Die Anwender werden zunächst die Daten, später den gesamten Prozess der Informationsgewinnung in Frauge stellen und schließlich das Informationssystem wegen Unzuverlässigkeit ablehnen. Es müssen dabei nicht nur unternehmensinterne Anwender betroffen sein, in einer integrierten Lieferkette sind auch die Zulieferer und Auftraggeber an den Datenfluss gekoppelt und gleichermaßen von der Datenqualität abhängig. Datenqualität ist der Grad, in dem ein Satz inhärenter Merkmale eines Datenprodukts Anforderungen erfüllt (vgl. Hinrichs, 2002). Bevor Datenqualität gesichert werden kann, müssen zunächst ihre Ausprägungen bestimmt und die Messbarkeit durch Metriken festgelegt werden. Einen Überblick über Aspekte der Datenqualität gibt die folgende Abb. 2.14. Aspekte der Datenqualität (vgl. Hinrichs, 2002):

28

2 Theoretische Grundlagen der Data Warehouse Technologie

Abb. 2.14. Aspekte der Datenqualität (vgl. Hinrichs, 2002)

Wegen seiner Rolle als zentrale Datenquelle für unternehmensweite Analysen muss der Datenbestand im Data Warehouse den Qualitätsanforderungen entsprechen. Dies sicherzustellen ist die Aufgabe der IT-Abteilung. Als erstes Kriterium für die Glaubwürdigkeit der Daten wird die Korrektheit genannt. Korrekte Daten stimmen mit den Sachverhalten in der Realwelt überein. So sollten Preise nur in positiven Werten dargestellt werden. Falsche Werte können beispielsweise durch Eingabefehler in den Datenbestand gelangen und Analysen verfälschen. Im schlimmsten Fall kann das zu Fehlentscheidungen in Führungsebenen mit weit reichenden Folgen für das Unternehmen führen. Ein versäumtes Trennzeichen für die Nachkommastelle veranschaulicht eine kleine Fehlerursache mit großen Auswirkungen, zumal der Fehler in aggregierten Daten kaum zu entdecken ist. Konsistenz, also die Widerspruchsfreiheit der Daten untereinander, ist ein weiterer Aspekt der Glaubwürdigkeit. Besonders wenn Daten aus unterschiedlichen Quellen in eine gemeinsame Struktur überführt werden, ist darauf zu achten, dass zum Beispiel die Wertebereiche und die Semantik identisch sind. Schließlich sollten die Werte durch präzise und konstante Ausprägungen ein Maß an Zuverlässigkeit erlangen, um keine Ermessensspielräume bei der Interpretation zu lassen. Die Anzahl der Leser einer Zeitung kann nicht zuverlässig aus der Auflage abgeleitet werden. Es ist möglich, dass dieselbe Zeitung von mehreren Personen oder ein von einer Fluggesellschaft ausgelegtes Exemplar gar nicht gelesen wird. Da der Anwender die Daten erst dann im vollen Umfang verwenden wird, wenn sie ihm hilfreich erscheinen, bildet die Nützlichkeit die zweite Gruppe von Anforderungen. Um von Bedeutung für den Anwender zu sein, müssen die ge-

2.4 Datenquellen und Datenqualität

29

haltenen Daten dem Anspruch der Vollständigkeit genügen. Sind Werte einzelner Kombinationen von Dimensionsausprägungen nicht enthalten, kann es für die Auswertungen verheerende Auswirkungen haben. Häufig sollen regionsübergreifende Daten, zum Beispiel europaweit Verkaufszahlen, verglichen werden. Dafür ist es unerlässlich, dass für sämtliche Produkte, Länder und betrachtete Zeiträume auch Umsätze vorhanden sind. Die bei der Konzeption festgelegte Granularität, mit der die Daten abgelegt werden, ist beim Replizieren einzuhalten. Eine höhere Genauigkeit der Daten kann im Sinne der Flexibilität jedoch nützlich sein, um auf zukünftige Anforderungen der Anwender angemessen zu reagieren. Datenaktualität ist auch im Kontext des Data Warehouse bedeutsam, da die Daten möglichst schnell für Auswertungen bereitstehen sollen. Auf zeitnahe Daten wird häufiger zugegriffen als auf historische, die nur für Berichte mit Vergangenheitsbezug benötigt werden. Die Auswirkungen einer gestarteten Werbekampagne wird die Marketingabteilung anhand aktueller Daten öfter nachfragen als zum Beispiel die Position eines Produktes in seinem Lebenszyklus, wofür man auch historische Daten heranzieht. Datenaktualität betrifft aber auch das Data Warehousing, denn manche Daten sind erst zu bestimmten Uhrzeiten verfügbar, weil die Berechnungen beispielsweise nach Geschäftsschluss erfolgen. Eine Aktualisierung muss daher sorgfältig geplant werden. Sind Daten redundant vorhanden, fällt es oftmals schwer, das gesuchte Tupel zu identifizieren. Werden zu einer Kunden-ID zwei verschiedene Lieferadressen gehalten, kann es zu Problemen im Warenausgang kommen. Der Datenbestand sollte also frei von Duplikaten sein. Um für den Betrachter nutzbringend zu sein, müssen die Daten für ihn relevant sein. Erst wenn sie im Kontext seiner Auswertung zu Informationen verarbeitet werden können, wird sein Bedarf befriedigt. So sind meteorologische Daten für einen Maschinenbaukonzern eher irrelevant, für einen Baubetrieb hingegen können sie Einfluss auf die Planung der Bauzeit haben. Daten sollen nicht nur nützlich, sondern auch interpretierbar sein. Einheitliche Daten, die immer in der gleichen Struktur repräsentiert werden, sind für Auswertungen unumgänglich. Dies betrifft auch die Festlegung eines übereinstimmenden Formates, wie zum Beispiel des Datumsformates. Fehler beim Transformieren des Datums können nach dem Einlesen unter Umständen nur durch einen genauen Vergleich mit den Quelldaten entdeckt werden, wenn sie denn überhaupt erkannt werden. Der 01.02.2005 kann als 01/02/2005 oder aber als 02/01/2005 abgelegt sein, in beiden Fällen erscheint das Datenformat auf den ersten Blick richtig. Eindeutige Werte haben eine konstante Bedeutung, die in den Metadaten festgeschrieben ist. Im Datenfeld Kundenname darf sich nicht die Produktbeschreibung oder eine Bewertung über die Kaufintensität des Kunden wieder finden, da sonst der Anwender viel Zeit mit der Suche nach einer geeigneten Quelle für seine Analysen zubringt. Zuletzt müssen die Daten verständlich sein, um vom Betrachter sinnvoll in Entscheidungen umgesetzt werden zu können. Ein Beispiel ist die Fehlerrate von vier Einheiten pro Million. Wird im Rahmen der Qualitätssicherung in der Abteilung das Six Sigma – Verfahren angewandt, bei dem für eine erfolgreiche Zertifizie-

30

2 Theoretische Grundlagen der Data Warehouse Technologie

rung einen Wert von mindestens 3,4 zu erreichen ist, nimmt der subjektiv geringe Wert eine gänzlich andere Bedeutung an. Die Schlüssel- und referenzielle Integrität der Daten ist mit Bezug zur relationalen Datenbank zu sehen. Es ist erforderlich, dass die Tupel durch Schlüssel eindeutig identifiziert werden und die Abhängigkeiten der Fremd-schlüssel gesichert sind, damit sich die Datenhaltung weniger aufwändig gestaltet. Die Datenqualität ist im Zusammenhang mit dem Data Warehouse als Quelle konsolidierter Daten zu sehen. Sind die Daten für den Anwender plausibel, von hohem Nutzen und interpretierbar, so kann das gesamte Potential eines Data Warehouse als zentrales, unternehmensweites Informationssystem ausgeschöpft werden. Ist der Transformationsprozess zusätzlich überschau- und leicht nachvollziehbar, so wird die Glaubwürdigkeit der Daten und das Vertrauen der Anwender in die aus den Daten gewonnenen Informationen und die IT-Abteilung gestärkt. Wie auch Geschäftsdaten können Metadaten mit unterschiedlichen Werkzeugen erstellt worden sein. Eine Überführung dieser in eine einheitliche Form ist eine zentrale Maßnahme, um die Datenqualität zu sichern. Bei Änderungen muss sichergestellt werden, dass die Metadaten nicht gelöscht werden, wenn durch sie beschriebene Geschäftsdaten noch vorhanden sind. Besonders bei historischen Geschäftsdaten wird der Bedarf deutlich, wenn man das Verständnis dieser bis in die Gegenwart erhalten will. Die Anforderungen an die Datenqualität gelten für Metadaten genauso wie für Geschäftsdaten. 2.4.4 Qualitätsmetriken Im Rahmen des Managements zur Planung, Lenkung, Sicherung und Verbesserung von Qualität werden Methoden angewendet, die den Erfüllungsgrad der Anforderungen messen. Die Zielbereiche wurden in den Anforderungen bereits formuliert, doch das Ausmaß und die Merkmale der Zielerreichung müssen noch im Vorfeld bestimmt werden. So kann ein gewünschter Soll-Zustand durch verschiedene Kennzahlen beschrieben werden. Um den Ist-Zustand der Datenqualität zu messen, werden Metriken herangezogen. Metrik ist die Lehre des Bestimmens von Messwerten und den Verhältnissen zwischen diesen. Erst mit der Unterstützung durch Metriken, die unter Verwendung der technischen Metadaten präzisiert werden, ist eine Steuerung der Datenqualität möglich (vgl. Hinrichs, 2002). Ohne Messwerte kann keine präzise Aussage über die gegenwärtige und durch Maßnahmen veränderte Güte der Daten getroffen werden. Das Verhältnis von Kosten und Nutzen einer Verbesserung der Datenqualität ist in einem solchen Fall unbekannt, so dass ein Eingriff auch nicht stichhaltig begründet werden kann. Die Anforderungen an eine Metrik sind Verständlichkeit, Präzision und Kombinierbarkeit der Werte. Außerdem muss sie anwendbar und wirtschaftlich sein, damit ihr Einsatz möglichst effektiv ist (vgl. Hinrichs, 2002).

2.4 Datenquellen und Datenqualität

31

Mögliche Methoden zur Bestimmung der Datenqualität sind die Messung einzelner Werte und das Durchführen von Umfragen. Im Gegensatz zu Messungen müssen Umfragen aber keine objektiven Ergebnisse liefern. Die Ermittlung von Messwerten wird stichprobenartig auf den in den Datenbestand zu integrierenden Objekten ausgeführt. Die Resultate werden mit der im Bestand realisierten Datenqualität verglichen, einzelne Werte können aggregiert werden, um größere Zusammenhänge zu überwachen. Umfragen geben wieder, wie Zustände von den Anwendern wahrgenommen werden. Bei starken Abweichungen zwischen den Messergebnissen und Umfragewerten kann es notwendig sein, die Strategie zur Sicherung der Datenqualität zu überdenken (vgl. Sattler, 2005). Die Messung der Konsistenz kann etwa durch die Überprüfung von Geschäftsregeln erfolgen. Eine Geschäftsregel ist zum Beispiel die Berechnung des Alters einer Person, das aus der Differenz zwischen dem heutigen und dem Geburtsdatum errechnet wird. Um eine Aussage über die geprüften Daten treffen zu können, wird eine Verhältniszahl aus der Anzahl Tupel, die nicht im Widerspruch mit den Regeln steht, und der Gesamtzahl überprüfter Tupel gebildet. Messungen können nicht immer vollständig automatisiert werden. Als Beispiel dient die Inventur in einem Lager, die nur manuell ausgeführt werden kann und in deren Rahmen die Bestandswerte im System korrigiert werden. Die Bewertung kann hier durch ein Abstandsmaß erfolgen, das über einen Vergleich von SollDaten mit den vorhandenen Ist-Daten berechnet wird. Problematisch an Metriken ist, dass Datenqualität im betrieblichen Zusammenhang gesehen werden muss und oft großes Domänenwissen zur Festlegung der Metrik und dem Bewerten der Daten notwendig ist (vgl. Sattler und Saake, 2004). Dadurch wird eine Bewertung subjektiv und schwer operationalisierbar. Für die Abteilung, die sich mit Lieferanten beschäftigt, sind vollständige Kontaktdaten weit wichtiger als für die Buchhaltung oder das Lager. Eine Vergleichbarkeit der Datenqualität zwischen den Unternehmen ist nicht gegeben, weil die Messvorschriften in der Regel unterschiedlich gewählt sind und die Ergebnisse unterschiedlich interpretiert werden können. Außerdem werden diese Daten der Öffentlichkeit kaum zugänglich gemacht. Ein weiteres Problem ist die oft große Datenmenge, welche es zu überprüfen gilt. Der Replikationsprozess ist bereits die zeitaufwändigste Phase im Data Warehousing, die Messung der Datenqualität muss als zusätzlicher Aufwand gesehen werden (vgl. Sattler, 2005). Allerdings werden die Daten bei einer Bewertung nicht direkt beeinflusst, wodurch die Messung überflüssig erscheint. Erst durch die Umsetzung der Ergebnisse aus der Qualitätsmessung in Maßnahmen zur Steigerung der Datenqualität wird ein Nutzen aus dem Aufwand gezogen. 2.4.5 Data Cleaning Die Sicherung der Datenqualität erfolgt im Transformationsprozess und wird soweit wie möglich durch automatisierte Data Cleaning Operationen unterstützt. Die Ziele des Data Cleaning sind das Erkennen fehlerhafter Daten und die Korrektur der Fehler. Dies umfasst das Beheben von Inkonsistenzen, das Berich-

32

2 Theoretische Grundlagen der Data Warehouse Technologie

tigen falscher und das Ergänzen fehlender Werte sowie das Überführen der Daten in ein einheitliches Format mit dem Ziel der Qualitätsverbesserung. Im Data Warehousing kann bis zu 80% des Aufwandes allein für das Data Cleaning anfallen (vgl. Sattler, 2005, und Inmon, 1999i). Die Nachvollziehbarkeit der Änderungen, die vom System an den Daten durchgeführt werden, ist neben der Zuverlässigkeit einer der zentralen Aspekte. Werden die Änderungen nicht protokolliert, ist bei Konflikten die Ursache eines fehlerhaften Tupels schwer ermittelbar. Wurde ein Datensatz zu einem Produkt entfernt, weil die Daten inkonsistent waren, so kann unter Zuhilfenahme des Protokolls plausibel begründet werden, weshalb der Anwender auf diesen nicht zugreifen kann. Generell muss angemerkt werden, dass nicht alle Werte vollständig oder in einem akzeptablen Zeitraum bereinigt werden können (vgl. Moss und Adelman, 1999). Sind die Daten nicht mehr konsolidierbar, so kann das Werkzeug diese entweder entsprechend markieren oder direkt löschen. Man geht davon aus, dass bei Realweltproblemen das Erreichen einer Datenqualität von 80% als das Optimum angesehen werden kann (vgl. Sattler und Saake, 2004). Strategien für eine Bereinigung der Daten können von Anwendungsbereich zu Anwendungsbereich variieren. Eine allgemeingültige Richtlinie für den Prozess kann somit nicht formuliert werden. Vielmehr sind die Bedingungen zu betrachten, welche die Daten beeinflussen. Zum Beispiel wird in der Buchhaltung eine monetäre Bewertung des Lagerbestandes bevorzugt, in der Produktionssteuerung sind dagegen die vorhandenen Stückzahlen von Interesse.

Abb. 2.15. Data Cleaning Prozess (vgl. Sattler, 2005)

Bevor eine Bereinigungsaktion ausgeführt werden kann, wird zunächst ein Profil der Daten erstellt. In diesem Schritt werden die Probleme der Datenqualität identifiziert und bewertet sowie deren Ursachen erkannt. Dazu werden unter Verwendung der Metadaten die Datentypen definiert und der Wertebereich festgelegt.

2.5 Typisches ETL-Prozessmodell

33

Statistische Verfahren erlauben es, Aussagen über die Häufigkeit, die Varianz und den genutzten Wertebereich zu machen. Außerdem werden Abhängigkeiten verschiedener Intensität zwischen den Attributen untersucht, um etwa potentielle Primärschlüssel für die Speicherung zu entdecken. Die Daten werden ebenso auf falsche und fehlende Werte geprüft wie auf redundante Datensätze, um festzustellen, in welchem Zustand sich die Daten befinden (vgl. Sattler, 2005). Das eigentliche Bereinigen der Daten erfolgt in den Phasen der Schemaintegration, der Fehlerkorrektur und der Erkennung von Duplikaten. Die Integration verschiedener Schemata erfolgt durch Abbildung der Daten auf dem Weg vom Arbeitsbereich, der über ein ähnliches Schema wie die Quelle verfügt, in die Basisdatenbank, die ein multidimensionsionales Schema aufweist. Auf Instanzenebene werden die Datentypen normiert. Unterschiedliche Formate werden in ein gemeinsames überführt, sei es das Datum oder aber Namen und Adressen. Eine wohldefinierte Beschreibung der Typen in Quell- und Zielsystem ist hierzu Voraussetzung (vgl. Sattler, 2005). Nachdem die Daten in einem einheitlichen Format vorliegen, können fehlerhafte Daten sicherer behandelt werden. Auch die Ausreißererkennung, die auf Basis des Datenprofils arbeitet, kann wirksam falsche Werte registrieren. Zuletzt werden die Daten über Ähnlichkeitsmaße auf Duplikate untersucht und bei Bedarf zusammengeführt.

2.5 Typisches ETL-Prozessmodell Der ETL-Prozess (Extraktion – Transformation – Laden) ist häufig die aufwändigste Aufgabe im Data Warehousing. Die Vielzahl unterschiedlicher Datenquellen, das unter Umständen beträchtliche Datenvolumen sowie die komplexen Konsolidierungsvorgänge zur kontinuierlichen Datenversorgung des Data Warehouse stellen eine große Herausforderung an die IT-Abteilung, die beteiligten Systeme und die Werkzeuge dar. Denn einerseits müssen die leistungskritischen Phasen des Ladens und der Transformation in möglichst kurzer Zeit ausgeführt werden, andererseits sind die Anforderungen an die Datenqualität zu erfüllen (vgl. Sattler und Saake, 2004). Die Phasen des ETL-Prozesses eines sich im Betrieb befindlichen Data Warehouse sind die Überwachung der Datenquellen auf Änderungen (Monitoring), das Replizieren der relevanten Daten in den Arbeitsbereich (Extraktion), die Konsolidierung der Daten (Transformation) sowie das anschließende Kopieren in die Basisdatenbank und in das Data Warehouse selbst (Laden). Im letzten Vorgang der Prozesskette werden auf den konsolidierten Daten im Data Warehouse Analysen ausgeführt (Berichtswesen). Das Ziel der modellgetriebenen Replikation ist die geschäftsorientierte Abbildung des ETL-Prozesses unter Verwendung der im Unternehmensmodell hinterlegten Metadaten. Ausgangspunkt ist die Definition der Übertragungs-, Transformations- und Fortschreibungsregeln für die Replikation mit anschließender logischer und physischer Implementation. Unterstützt wird der Vorgang durch

34

2 Theoretische Grundlagen der Data Warehouse Technologie

integrierte Werkzeuge zur geplanten, steuerbaren und zu überwachenden Replikation der Daten, die theoretisch unendlich viele Zyklen haben kann (vgl. Devlin, 1997). 2.5.1 Vorbereitungsphase Bevor das Prozessmanagement eines Data Warehouse die Steuerung der Laufzeitkomponenten übernehmen kann, ist eine Reihe administrativer Schritte notwendig. Zunächst identifiziert man die benötigten Daten und die Quellen, die für eine Replikation in das Data Warehouse verwendet werden sollen. Dabei müssen verschiedene Systeme unterstützt werden, denn nur so ist mit dem Data Warehouse die unter Umständen heterogene Systemlandschaft und räumliche Trennung der Quellen zu überwinden. Grundlage für die Entscheidung, eine Datenquelle zu verwenden, ist das Unternehmensmodell, denn entsprechend den Metadaten werden in der Beschaffungskomponente die Quellsysteme definiert und die vom Replikationsprozess betroffenen Daten identifiziert. Dabei können Einschränkungen getroffen werden, um unbeteiligte Daten direkt aus der Betrachtung auszuschließen. Gleichzeitig müssen die Quellen für eine Replikation vorbereitet werden, um den Prozess ohne Hindernisse wie Lesesperren ausführen zu können. Auf der anderen Seite muss der ETL-Prozess die Sperrzeiten auf den Daten der Quellsysteme minimal halten, damit diese den Anwendern möglichst uneingeschränkt zur Verfügung stehen (vgl. Devlin, 1997). 2.5.2 Extraktionsphase In diesem Schritt müssen die Regeln für die Verbindung des Quellsystems mit dem Data Warehouse und die Übertragung der Daten angelegt werden, um anschließend den Replikationsprozess auszuführen. Sie geben an, wie und vor allem wann welche Daten vom Quell- in das Zielsystem übertragen werden. Gleichzeitig wird über einen geeigneten Zeitpunkt und Typ der Extraktion entschieden. Eine zeitlich synchrone Extraktion erfolgt bei jeder Änderung der Quelldaten. Replikationen durch asynchrone Verfahren erfolgen periodisch, ereignis- oder aber anfragegesteuert. Ein synchrones Replizieren der Daten hat eine moderate Belastung der Netzverbindung und der betroffenen Systeme zur Folge, weil jede Änderung direkt an das Data Warehouse geschickt wird. Sind die Systeme und das Netzwerk bereits zu einem hohen Grad ausgelastet, kann sich die zusätzliche Reduzierung der verfügbaren Leistung allerdings negativ bemerkbar machen. Um die Belastung zu minimieren, wird der Extraktionsprozess daher nicht unmittelbar, sondern in Zeitfenstern angestoßen, in denen die Ressourcen in ausreichender Menge zur Verfügung stehen, wie zum Beispiel nachts oder am Wochenende. Wenn die Präsenz bestimmter Daten für Auswertungen zwingend erforderlich ist, etwa bei der Quartalsanalyse, dann wird der Prozess ereignisgesteuert angestoßen. Die dritte Strategie bei der asynchronen Extraktion ist das

2.5 Typisches ETL-Prozessmodell

35

Anfragen am Zielsystem, ob die in der Analyse verwendeten Daten geändert worden sind. Dies wird bei Berichten angewandt, die hochaktuell sein müssen oder aber bei Daten, die selten verwendet werden und darum nicht kontinuierlich in das Data Warehouse zu laden sind (vgl. Sattler und Saake, 2004). Neben der Entscheidung über den zeitlichen Aspekt des Replikationsprozesses ist auch zwischen einer statischen oder inkrementellen Extraktion zu wählen (vgl. Devlin, 1997). Die statische ist mit einer Momentaufnahme des gesamten Datenbestandes zu vergleichen. Ein solcher Snapshot der Quelldatenbank kann ein sehr großes Volumen haben und wird zum Beispiel im Falle der Erstbefüllung eines Data Warehouse eingesetzt. Um das bei der Beschaffung zu übertragende Datenvolumen zu vermindern, wird die inkrementelle Extraktion eingesetzt. Ein simpler Vertreter dieses Typs ist das Delta-Update, bei dem nur die Änderungen zwischen dem aktuellen und dem vorherigen Snapshot übertragen werden. Snapshots bergen jedoch die Gefahr, dass der Verlauf der Änderungen nicht mehr vollständig abgebildet werden kann. Eine aufwändigere Lösung, die die Möglichkeit zum späteren Nachvollziehen der Änderungen bietet, ist das Übertragen protokollierter Änderungen. Das Quellsystem überwacht den Datenbestand und trägt Änderungen in Log-Dateien ein. Aus diesen kann entnommen werden, wie es zum Ergebnis gekommen ist. 2.5.3 Transformationsphase Nachdem der Extraktionsprozess eingeplant wurde und sich das Data Warehouse erfolgreich mit der Quelle verbunden hat, werden die Daten transferiert. Wurden die Daten in den Arbeitsbereich geladen, so werden sie nun durch das System zunächst in das Schema der Basisdatenbank überführt und anschließend konsolidiert. Dieser Prozess kann teilweise durch Werkzeuge automatisiert werden, einige Korrekturen müssen allerdings durch Mitarbeiter der betreuenden ITAbteilung selbst vorgenommen werden. Der Prozess wird hier am Beispiel des CLIQ-Vorgehensmodells (Data Cleansing mit intelligentem Qualitätsmanagement) veranschaulicht. Als erstes werden im Arbeitsbereich die Daten in einem relationalen Schema normalisiert und in das quellenunabhängige Schema der Basisdatenbank überführt. Anschließend wird das Datenformat vereinheitlicht und die Daten werden in den Transformationsbereich geladen. Hier erfolgt eine statistische Prozesskontrolle zur Profilerstellung und Prüfung der Daten auf prozessbedingte Defekte, etwa das Fehlen einer ganzen Spalte. In der domänenspezifischen Konsistenzprüfung werden die Daten auf die Verletzung von Geschäftsregeln überprüft. Anschließend werden Duplikate entfernt und die Daten zusammengeführt. Nun kann die Datenqualität im Konsolidierungsbereich gemessen werden. Nach der Freigabe für die Basisdatenbank wird die Datenqualität durch Analyse von Indikatoren, zum Beispiel der Anwenderzufriedenheit, überprüft (vgl. Hinrichs, 2002).

36

2 Theoretische Grundlagen der Data Warehouse Technologie

2.5.4 Ladephase Nach der Transformation werden die Daten in das Zielsystem geladen. Während die Extraktionsphase im Wesentlichen die Quellsysteme betrifft, wird beim Laden der Daten der Betrieb des Data Warehouse beeinflusst. Für die Dauer des Prozesses werden die betroffenen Tupel mit Sperren belegt, so dass Auswertungen auf diesen Daten nicht möglich sind. Ein weiterer wichtiger Aspekt ist die Aktualisierung bestehender Daten. Diese können zum einen durch die Anwendung von Regeln überschrieben werden, allerdings geht der alte Wert dadurch verloren. Ein Beispiel ist der Lagerbestand, dessen Wert in der Zeit zwischen den Replikationsprozessen im operativen System durch eine Inventur geändert worden sein kann. Nun wird der neue, aktuelle Wert an die Stelle des alten gesetzt. Aktuelle Daten können aber auch als neue Datensätze in die Basisdatenbank eingefügt werden, ohne dass die bestehenden Daten betroffen sind. In der Regel erfolgt der Ladevorgang mit Unterstützung durch spezielle Werkzeuge der Systeme, die ein schnelles Laden der Daten ermöglichen, indem der Kontext der Daten berücksichtigt wird. Es werden so gesamte Tabellen gesperrt und auf einmal mit Daten befüllt. Der Leistungsgewinn resultiert unter anderem daraus, dass wegen der kompletten Sperre keine transaktionale Sperrverwaltung notwendig ist und Indizes erst nach dem Abschluss des gesamten Vorganges neu erstellt werden. Zur Sicherung des Vorganges werden Prüfpunkte gesetzt, um bei Komplikationen das Laden an geeigneter Stelle fortsetzen zu können (vgl. Sattler und Saake, 2004). Nachdem der Ladevorgang vollzogen wurde, erfolgt die Bestätigung über einen erfolgreichen Replikationsprozess oder aber die Meldung über einen Fehlschlag der Operation. In allen Phasen müssen Fall-Back Operationen möglich sein, um den Fehler abzufangen und das System zum Einsatz wieder freizugeben. Die einzelnen Prozessschritte werden in den Metadaten dokumentiert, damit sie durch den Anwender nachvollzogen werden können. Mit Hilfe einer verständlichen Dokumentation können Fehler im Prozess leichter identifiziert und behoben werden. Zum Abschluss werden die Definitionen der Parameter für Quellen, Übertragungsregeln und das Zielsystem gespeichert, damit sie für zukünftige Prozesse zur Verfügung stehen (vgl. Sattler und Saake, 2004).

2.6 Bewertung eines Data Warehouse In den vorherigen Abschnitten ist das Data Warehouse-Konzept vorgestellt worden. Es wurden die Problemstellungen im Bereich der Entscheidungsunterstützung auf Führungsebene genannt und ihr Einfluss auf die Entwicklung eines multidimensionalen Informationssystems verdeutlicht. Nun werden die mit einem Data Warehouse verbundenen Chancen und Risiken angesprochen.

2.6 Bewertung eines Data Warehouse

37

2.6.1 Stärken eines Data Warehouse Die Vorteile, die durch den Einsatz eines Data Warehouse entstehen, sind eine Steigerung der Effektivität im Bereich der betrieblichen Informationssysteme und das Entdecken neuer Analysefelder im Unternehmen. Die durch operative Systeme gegebenen Einschränkungen in der Entscheidungsunterstützung werden überwunden, ohne dass tief greifende Veränderungen an der bestehenden Software nötig wären (vgl. Devlin, 1997). Ein Data Warehouse wird in einem eigenen System realisiert, das unabhängig von den Quellsystemen betrieben wird und so deren Kapazitäten nicht belastet. Es trägt sogar zu einer Entlastung bei, da es für viele Berichtsoperationen zuständig ist, die zuvor auf den operativen Systemen ausgeführt wurden. Das Data Warehouse integriert verschiedene Quellsysteme und repliziert die Daten, ohne sie in den Quellen zu verändern, und ist dadurch auch logisch weitgehend unabhängig. Auswertungen werden in der multidimensionalen Umgebung eines Data Warehouse schneller ausgeführt als auf einem OLTP-System und durch intuitive Werkzeuge unterstützt. Dadurch reduziert sich der Zeitaufwand für das Berichtswesen, so dass die für die Erstellung zuständigen Fachabteilungen entlastet werden, während gleichzeitig die Qualität der Berichte verbessert wird. Die Suche nach Daten in verschiedenen Systemen entfällt und den Anwendern wird ein breiteres Spektrum an Daten in konstanter Qualität geboten. Darüber hinaus wird Anwendern der Zugriff auf Metadaten, die sonst häufig nur der IT-Abteilung zugänglich waren, ermöglicht (vgl. Devlin, 1997). Eine unternehmensweite Sicht auf den Datenbestand wird möglich und somit die Entscheidungsunterstützung von Abteilungs- auf Unternehmensebene transferiert (vgl. Holthuis, 1999). Auf lange Sicht wird neben den Endanwendern ebenfalls die IT-Abteilung entlastet. In Form einer einzigen, strukturierten und konsistenten Datenquelle erleichtert das Data Warehouse der IT-Abteilung, ihre Hauptaufgabe zu erfüllen, nämlich den Informationssystemen Daten zur Verfügung zu stellen. Ein weiterer Vorteil zugunsten der IT-Abteilung liegt darin, dass Datenextraktionswerkzeuge nur noch an das Data Warehouse angepasst werden müssen und nicht mehr an verschiedene operationale Systeme (vgl. Devlin, 1997). 2.6.2 Schwächen eines Data Warehouse Das größte Problem des Data Warehouse Konzepts ist der Mangel an allgemein anerkannten Standards (vgl. Holthuis, 1999). Dies reicht von der Speicherung der Daten bis hin zu den Schnittstellen, insbesondere eine Standardabfragsprache wie beispielsweise SQL bei den operativen Systemen wäre wünschenswert. Die mit der Einführung eines Data Warehouse einhergehenden Redundanzen in der Datenhaltung verursachen weiteren Aufwand zur Erhaltung der Konsistenz. Zusätzlich können Fehler in Planung und Realisierung entstehen, die nicht auf das Konzept zurückzuführen sind. Die Einführung eines neuen umfassenden Systems wie dem Data Warehouse in die Informationssystemarchitektur eines Unternehmens ist sehr aufwändig. Wer-

38

2 Theoretische Grundlagen der Data Warehouse Technologie

den diese Aufgaben unterschätzt und die Besonderheiten eines Data Warehouse nicht ausreichend berücksichtigt, führt dies zum Scheitern des Projekts (vgl. Raizada, 2002). Fehler bei der Einführung sind meist auf eine Fehleinschätzung der Situation, der Ziele und des Aufwandes zurückzuführen (vgl. Karakizis, 2002, und Kimball, 1996b). Die Aufgabe ist häufig schwieriger als erwartet, da die Gegebenheiten in einem Unternehmen nicht ausreichend analysiert worden sind. Neben dem ERPSystem können auch EIS- und CRM-Systeme operativ eingesetzt werden, so dass die Systemlandschaft sehr heterogen sein kann. Eine Situationsanalyse schließt auch das Nachvollziehen der Geschäftsprozesse mit ein. Da das Data Warehouse die zentrale Quelle für unternehmensweite Auswertungen ist, muss auch das gesamte Unternehmen mit seinen Daten und Geschäftsprozessen verstanden werden (vgl. Raizada, 2002). Perfekte vordefinierte Schnittstellen zu sämtlichen bestehenden Systemen sind nicht vorauszusetzen, genauso wenig unternehmensübergreifende Standards. Ebenso wie die Integration der Daten aus den verschiedenen operativen Systemen stellen auch die Bedürfnisse der Anwender an komplexen und komplizierten Berichten eine große Herausforderung dar. Werden die dringendsten Bedarfe der Anwender nicht in die Ziele aufgenommen, Hauptanwender ignoriert und gleichzeitig zu hohe Erwartungen an das Data Warehouse geweckt, ist ein erfolgreicher Einsatz kaum möglich. Die Fehler, die in der Zieldefinition und Analyse gemacht wurden, sind nicht mehr oder nur mit erheblichem Aufwand zu korrigieren. Die Einführung eines Data Warehouse ist eine strategische Investition, die mit einem bedeutenden finanziellen Aufwand verbunden ist (vgl. Manning, 2003). Dabei entsteht der Großteil der Kosten nicht durch Lizenzgebühren, sondern durch Pflege der Systeme und Beratung der Anwender (vgl. CIO, 2005). Die vollständige Umsetzung kann eine Reorganisation von Geschäftsabläufen erfordern, wodurch beträchtliche Folgekosten entstehen können, die unter Umständen erst während des Projektes absehbar sind (vgl. Holthuis, 1999). Zusätzliche und ausreichend dimensionierte Hardwarekapazitäten sind notwendig, da zum Beispiel der ETL-Prozess die Ressourcen sehr belastet. Ist es nicht möglich, die für eine erfolgreiche Durchführung des Projektes zusätzlich benötigten Mittel bereitzustellen, kann das Data Warehouse gar nicht oder nur sehr eingeschränkt genutzt werden. Bei Data Warehouse Projekten kommt es außerdem zu Problemen, da Architektur, Design und Bestandteile erst dann vervollständigt werden können, wenn die Anforderungen komplett vorliegen. Es besteht die Gefahr, dass dieser Prozess in einer ständigen Veränderung der Anforderungen ohne Fertigstellung des Data Warehouse mündet (vgl. Bange, 2005). Daher ist bei Data Warehouse Projekten eine Vorgehensweise empfehlenswert, die sich von der traditionellen Vorgehenswiese bei Software Projekten, die häufig dem Wasserfallmodell folgen, unterscheidet (vgl. Holthuis, 1999, und Sherman, 2004). Die Erfahrung zeigt, dass Data Warehouse Lösungen eine Entwicklungszeit von bis zu zwei Jahren aufweisen, sich der Ertrag der beträchtlichen Investitionen aber erst nach Fertigstellung einstellt. Es ist daher darauf zu achten, dass die ange-

2.6 Bewertung eines Data Warehouse

39

strebten Nutzeffekte stets klar herausgestellt und schon während der Entwicklung verwertbare Ergebnisse gewonnen werden. Diese Ergebnisse fördern die Akzeptanz und Glaubwürdigkeit des Data Warehouse Projektes und verringern das Projektrisiko, da bereits frühzeitig erkannt werden kann, ob sich der gewünschte Erfolg einstellt oder ein Projekt gestoppt bzw. auf andere Geschäftsbedürfnisse ausgerichtet werden soll (vgl. Holthuis, 2002). War die Einführung erfolgreich, so wird im Betrieb das Potential eines Data Warehouse oft nicht ausgeschöpft. Durch Fehler in der Entwicklungsphase kann es sein, dass die Erwartungen der Anwender nicht erfüllt werden. Dass nicht jede Abteilung den gleichen Nutzen aus dem Data Warehouse ziehen kann, ist verständlich. Die Unterstützung kritischer Unternehmensbereiche und der Geschäftsleitung sind sicherzustellen. Die Nutzung des Systems durch Anwender muss untersucht und die dadurch erkannten Mängel müssen behoben werden. Nach Abschluss der Entwicklung werden die Anwender oft im Betrieb vernachlässigt. Schulungen und Endbenutzerunterstützung durch Fachkräfte der IT-Abteilung sind unerlässlich, weil es die Anwender sind, insbesondere die Führungskräfte, die aus dem System den größten Nutzen ziehen sollen. Wenn die Anwender das System erfolgreich annehmen, können die Anforderungen an Konzept und Hardware stark zunehmen. Wurde keine Erweiterungsstrategie formuliert, kommt es daraufhin zu Engpässen (vgl. Folger, 2002). Eine Integration des Data Warehouse in bestehende Informationslösungen, wie etwa ein Unternehmensportal, wird oft in einer Strategie nicht bedacht, obwohl die Integration auf der Analyseebene erforderlich ist. Es fehlt oft an Richtlinien für Betrieb und Pflege des Systems, wie zum Beispiel mit veralteten Berichten umgegangen werden soll (vgl. Folger, 2002). Die Datenqualität ist ein zentraler Aspekt bei der Bewertung des Data Warehouse. Es liegt ein erhebliches Gefahrenpotential in der Identifizierung und Konsolidierung der Geschäftsdaten und Interpretation der Metadaten sowie der Auswahl der zur Unterstützung von Prozessen eingesetzten Werkzeuge (vgl. Devlin, 1997). Außerdem wird die Datensicherheit in einem Data Warehouse oft nicht ausreichend beachtet. Es muss schon bei der Konzeption des Datenmodells sichergestellt werden, dass Datenschutzrichtlinien eingehalten werden können (vgl. Büllesbach, 2002).

3 Theoretische Grundlagen des SAP Business Information Warehouse

Das SAP Business Information Warehouse ist die Data Warehouse Lösung der SAP AG. Es wird zum Bereich der SAP Business Intelligence gezählt und gehört der Integrations- und Anwendungsplattform SAP NetWeaver an. Nachdem im ersten Kapitel die theoretischen Grundlagen für das Verständnis eines Data Warehouse vermittelt wurden, wird nun im zweiten Kapitel die Software SAP BW vorgestellt. Der folgende Abschnitt führt den Benutzer in die Interaktion mit SAP Systemen ein. Anschließend wird auf die Umsetzung des Data Warehouse Konzepts im SAP BW eingegangen. Den Hauptabschnitten schließt sich jeweils der Hinweis auf den entsprechenden Teil der praktischen Fallstudie an.

3.1 Umgang mit SAP Systemen SAP Systeme werden über eine gemeinsame Oberfläche bedient, welche als SAPgui bezeichnet wird. Anwender, die bereits Erfahrung im Umgang mit SAP Systemen gesammelt haben, können diesen Abschnitt überspringen und mit Kapitel 3.2 Komponenten des SAP BW fortfahren. 3.1.1 SAPlogon

Abb. 3.1. SAPlogon

42

3 Theoretische Grundlagen des SAP Business Information Warehouse

Das SAPlogon ist eine für die Microsoft Windows Plattform entwickelte Anwendung, mit deren Hilfe die Verbindung vom Client zum SAP-System hergestellt wird. Sie wird aus der Windows-Betriebssystem-Oberfläche heraus gestartet und enthält ein Menü, in dem neue SAP Systeme hinzugefügt oder bereits bestehende Einträge ausgewählt werden können (vgl. SP AG, 2005). Mit der Anmeldung am im Menü selektierten SAP System versucht das SAPlogon, eine Verbindung mit diesem herzustellen. Wenn sich das Programm erfolgreich mit dem Server in Verbindung gesetzt hat, wird auf dem Client die Oberfläche SAPgui gestartet und der Anmeldebildschirm angezeigt. 3.1.2 SAP Fenster Die SAPgui stellt das SAP Fenster dar, welches die Schnittstelle zwischen dem Benutzer und dem SAP System bildet. In diesem werden dem Anwender einerseits Informationen präsentiert und Systemmeldungen ausgegeben, andererseits können über Eingabefelder Daten an das System übertragen und mittels Schaltflächen Funktionen ausgeführt werden. Für eine Anmeldung am gewählten System muss in der ersten Bildschirmmaske die Mandantennummer, der Benutzername und das Kennwort eingeben werden. Optional kann ein Sprachkennzeichen gesetzt werden, um Beschriftungen im SAP System sprachabhängig darzustellen. Erfolgt die Anmeldung am System zum ersten Mal, so sind die vom Systemadministrator vergebenen Zugangsdaten einzugeben. Ist die Anmeldung am System erfolgreich gewesen, wird in der Bildschirmmaske das SAP Easy Access Benutzermenü des SAP Business Information Warehouse aufgerufen. Es enthält Verknüpfungen zu Transaktionen, Berichten und Internetadressen, die der Anwender zur Bewältigung seiner Aufgaben benötigt. Transaktionen sind funktional zusammengehörige Verarbeitungseinheiten, die konsistente und betriebswirtschaftlich zulässige Datenbankänderungen durchführen (vgl. Rautenstrauch, 2003). Im Navigationsbereich können die Menüstruktur geöffnet und die in dieser hinterlegten Anwendungen ausgeführt werden. Alternativ lassen sich die Anwendungen über die direkte Eingabe von Transaktionscodes in das Befehlsfeld aufrufen. Der Transaktionscode zu einer Anwendung im Navigationsmenü kann in Erfahrung gebracht werden, indem der betroffene Eintrag markiert und in der SAP Menüleiste das Menü Zusätze aufgeklappt wird. Auf die Funktion Technische Detailinformationen folgt ein Dialog, aus dem die gewünschte Information entnommen werden kann (vgl. SAP AG, 2005).

3.1 Umgang mit SAP Systemen

43

Abb. 3.2. SAP Fenster

Hauptbestandteile des SAP Fensters sind die Menüzeile, die Systemfunktionsleiste, Titelleiste, Anwendungsfunktionsleiste sowie der Bildrumpf und die Statuszeile. In der Menüleiste können über die Menüstruktur Transaktionen aufgerufen werden, deren Umfang von der im Fenster aktuell ausgeführten Anwendung abhängig ist. Das Menü für Funktionen des Systems und das Hilfemenü sind in allen Fenstern verfügbar. Im Bildbereich der Menüleiste sind in der Nähe der SAP-Grafik auch Symbolschaltflächen für die Minimierung, Maximierung und zum Schließen des Fensters vorhanden (vgl. SAP AG 2005). Die Systemfunktionsleiste stellt häufig verwendete Funktionen zur Verfügung, die über das Betätigen der entsprechenden Schaltflächen ausgeführt werden. Die im Rahmen der Fallstudie verwendeten Schaltflächen werden nachfolgend in Tabelle 3.1. Übersicht der Schaltflächen erläutert.

44

3 Theoretische Grundlagen des SAP Business Information Warehouse

Tabelle 3.1. Übersicht der Schaltflächen Funktion Enter

Befehlsfeld

Sichern

Zurück

Beenden

Abbrechen

Modus erzeugen

Hilfe (F1)

Beschreibung Mit Betätigung dieser Schaltfläche werden die in einer Bildschirmmaske getroffenen Eingaben bestätigt. Dieses Feld dient dazu, Anwendungen durch die direkte Eingabe von Transaktionscodes aufzurufen. Um die in einer Bildschirmmaske getätigten Eingaben zu sichern, kann die Schaltfläche angeklickt werden. Diese Schaltfläche bewirkt ein Zurückgehen in der Anwendungshierarchie. Mit dieser Schaltfläche wird die aktuelle Anwendung beendet. Beim Abbrechen wird die Anwendung verlassen, ohne dass die seit dem letzten Öffnen oder Speichern vorgenommenen Änderungen gesichert werden. Wird diese Schaltfläche angeklickt, so erzeugt das System einen neuen Modus in einem neuen SAP Fenster. Die hinterlegte Funktion zu dieser Schaltfläche ruft Informationen der Hilfe zu dem Objekt auf, welches zuvor markiert wurde.

Unterhalb der Systemfunktionsleiste sind die Titelleiste mit dem Anwendungstitel und die Anwendungsleiste mit anwendungsspezifischen Schaltflächen angeordnet. Im Bildrumpf wird die Bildschirmmaske der Anwendung gezeigt, die aus verschiedenen grafischen Elementen wie etwa Schaltflächen, Tabellen und Registerkarten bestehen kann. Die Statuszeile ist die unterste aller Zeilen im SAP Fenster. In ihr werden Meldungen des SAP-Systems ausgegeben, zum Beispiel wenn ein Sicherungsvorgang erfolgreich ausgeführt wurde. Auf der rechten Seite befindet sich ein Ausgabefeld, dessen Inhalt Aufschluss über Eigenschaften der Verbindung zum SAP System gibt. Zusätzlich erhält der Benutzer die Auskunft, ob er sich im Überschreib- (OVR) oder Einfügemodus (INS) befindet. Ein Wechsel zwischen den Modi erfolgt durch Anklicken des Feldes (vgl. SAP AG, 2005).

3.1 Umgang mit SAP Systemen

45

Das SAP-System bietet die Möglichkeit, mehr als nur ein Fenster und damit mehrere Anwendungen zur gleichen Zeit auszuführen. Aus jedem Fenster heraus kann ein neuer, vom aktiven Fenster unabhängiger Modus gestartet werden. Mit den Standardeinstellungen können bis zu sechs Fenster gleichzeitig geöffnet sein. Zwischen den einzelnen Modi kann ohne Kollisionen oder Datenverlust gesprungen werden, allerdings ist zu beachten, dass man mit einem Modus Daten für die anderen sperren kann. Vor dem Schließen eines Modus sollten die Einstellungen gesichert werden, da nur beim Beenden des letzten SAP Fensters ein Dialog mit dem Hinweis auf Speichern erscheint. Wird ein Modus nicht mehr benötigt, so sollte dieser geschlossen werden, da er das Antwortzeitverhalten des SAP Systems negativ beeinflusst. Wenn das letzte SAP Fenster geschlossen wird, erfolgt die Abmeldung vom System (vgl. SAP AG, 2005). 3.1.3 Elemente der SAP Bildschirmmasken Die zur Präsentation von Inhalten und zur Interaktion mit dem Anwender verwenden Bildschirmmasken der SAP Anwendungen verfügen über grundlegende Objekte wie Bezeichnungs- oder Eingabefelder sowie Schaltflächen zum Aufrufen hinterlegter Funktionen. Daneben sind Objekte zur Selektion von Optionen, zur Gruppierung von Bildschirmelementen und zur tabellarischen Darstellung von Daten vorhanden, die im Folgenden näher erläutert werden. Auswahlknöpfe werden eingesetzt, wenn aus einer Menge möglicher Optionen nur eine einzige gewählt werden soll. Um eine Option zu selektieren, wird der entsprechende Auswahlknopf neben dem Text markiert. Diese Markierung kann durch Anklicken eines anderen Auswahlknopfes innerhalb der gleichen Gruppe verschoben werden (vgl. SAP AG, 2005). Neben Auswahlknöpfen werden auch Ankreuzfelder verwendet, wenn mehrere Optionen zur Auswahl stehen. Hierbei sind im Gegensatz zu Auswahlknöpfen alle, einige oder keine Optionen selektierbar. Durch Klicken auf ein Ankreuzfeld wird dieses markiert, auf die gleiche Weise kann eine Markierung wieder aufgehoben werden (vgl. SAP AG, 2005). Wenn eine Menge von Eingabefeldern zu einem Sachverhalt aufgrund der Anzahl der Elemente nicht übersichtlich innerhalb einer Bildschirmmaske dargestellt werden kann, so werden in SAP Fenstern Register eingesetzt. Meist sind die Register nach Relevanz oder der Reihenfolge der Arbeitsschritte geordnet. Einzelne Registerkarten können über ihre Überschriften angewählt und somit in den Vordergrund gestellt werden. Allerdings kann bei einer größeren Anzahl ein Teil dieser Kartentitel der Übersichtlichkeit wegen versteckt sein. Die vollständigen Titel werden angezeigt, wenn durch die einzelnen Karten geblättert wird (vgl. SAP AG, 2005).

46

3 Theoretische Grundlagen des SAP Business Information Warehouse

Abb. 3.3. Registerkarten

Tabellen stellen Daten in einer Struktur aus Zeilen und Spalten dar. In der Kopfzeile befinden sich die Spaltenüberschriften, die einen Hinweis auf den Inhalt der Spalte geben. Die Spaltenbreiten sind nicht fixiert und können individuell verändert werden. In den Eingabefeldern mancher Spalten wird ein zusätzliches Suchmenü angeboten, über welches aus einer Menge vorhandener Einträge der gewünschte selektiert werden kann. Eine Zeile wird markiert, indem man auf das Feld vor der ersten Werte tragenden Spalte klickt. Durch Verschieben der Bildlaufleisten wird der sichtbare Bereich der Tabelle verschoben, wobei einige Felder in der Ansicht fixiert sein können und nicht aus dem sichtbaren Bildausschnitt herausgenommen werden (vgl. SAP AG, 2005).

Abb. 3.4. Tabelle

Neben dem SAP Fenster existieren auch kleinere Masken, die unter dem Begriff Dialogfenster geführt werden. Sie werden eingesetzt, wenn weitere Informationen für die Abarbeitung einer Funktion notwendig sind oder wichtige Meldungen zu einem Sachverhalt ausgegeben werden. Dies kann beispielsweise der Hinweis auf Speichern der Änderungen vor dem endgültigen Verlassen einer Anwendung. Im

3.2 Komponenten des SAP BW

47

Dialogfenster muss eine der zur Verfügung stehenden Optionen in Form von Schaltflächen ausgewählt werden, bevor man in den Hauptbildschirm zurückkehren kann (vgl. SAP AG, 2005).

Abb. 3.5. Dialogfenster

3.2 Komponenten des SAP BW Die Bestandteile des SAP Business Information Warehouse können drei Schichten zugeordnet werden. In der Datenhaltungsschicht sind alle Komponenten enthalten, deren primäre Aufgabe es ist, Daten aufzunehmen und diese Anfragen zur Verfügung zu stellen. Die Administrationsschicht enthält Funktionen zur Verwaltung, Steuerung und Kontrolle der Objekte des SAP BW, während die letzte Schicht die Basisfunktionen und Werkzeuge zur Entscheidungsunterstützung umfasst (vgl. SAP AG, 2005).

Abb. 3.6. Komponenten des SAP BW

48

3 Theoretische Grundlagen des SAP Business Information Warehouse

3.2.1 Datenschicht In der Datenschicht ist der korrekte Ablauf des Data Warehousing organisiert. Sie umfasst den Bereich Datenmodellierung, die Extraktion und Bereitstellung der Daten sowie die Data Warehouse Management Prozesse. In der Anfangsphase des Data Warehousing werden die benötigten Objekte des SAP BW mitsamt den Regeln für die Datenübertragung, Konsolidierung, Fortschreibung und Bereitstellung angelegt. Das Datenmodell bildet die Grundlage für die Datenablage und für spätere Vorgänge zur Umsetzung der Daten in Informationen. Die Architektur der Datenschichten entspricht dem im Kapitel 2.2.3 Komponenten vorgestellten Aufbau mit Arbeitsbereich, Basisdatenbank und Data Warehouse (vgl. SAP AG, 2005). Daten können aus unterschiedlichen Quellsystemen über definierte Schnittstellen bezogen werden. Die Quellen werden als Fremdsysteme bezeichnet, wenn es sich dabei nicht um eine SAP BW-Instanz oder ein SAP R/3-System ab Version 3.0D handelt. Die Fremdsysteme umfassen flache Dateien, Datenbanken, XMLDaten und von Drittanbietern bereitgestellte Extraktoren (vgl. Mehrwald, 2004). Das SAP BW kann ebenfalls als Quelle einer Datenübertragung in Erscheinung treten, wenn Daten innerhalb des SAP BW internen und externen Analysewerkzeugen oder anderen Applikationen bereitgestellt werden sollen. Im SAP BW sind Mechanismen zur Bereitstellung von Stamm-, Bewegungs- und Metadaten enthalten (vgl. Egger, 2004). Das Data Warehouse Management dient der Steuerung, Überwachung und Automatisierung von Prozessen, beispielsweise der Verwaltung der Datenziele. Außerdem werden hier die Benutzerberechtigungen gepflegt, in Rollen zusammengefasst und Benutzerprofilen zugeordnet. Das Management umfasst auch die Organisation von und den Zugriff auf Dokumente im SAP BW, die zusätzliche Informationen zu Objekten enthalten können. Ebenso gehören die Datenarchivierung, der technische Content beispielsweise mit Zugriffsstatistiken, die Analyseund Reparaturumgebung sowie das Transportwesen zum Data Warehouse Management dazu. Letzteres ermöglicht die Übertragung von Objekten und Metadaten über den Transportanschluss vom Testsystem in das operative Data Warehouse (vgl. SAP AG, 2002a). 3.2.2 Administrationsschicht Das zentrale Werkzeug für die Modellierung und Pflege der Objekte und Regeln sowie die Steuerung und Überwachung aller Prozesse im SAP Business Information Warehouse ist die Administrator Workbench. Zu den im Navigationsbereich vorhandenen Anwendungen des Werkzeuges gehören unter anderem die Modellierung, der Business Content und der Zugriff auf das Metadata Repository. In der Modellierung werden die für den produktiven Einsatz benötigten Objekte und Regeln angelegt und mit Hilfe spezifischer Funktionen konfiguriert. Die definierten Modellbestandteile werden in einer hierarchischen Baumstruktur abgebildet, über die man zu anderen Elementen, die in enger Verbindung mit dem

3.2 Komponenten des SAP BW

49

Bezugsobjekt stehen, navigieren und diese direkt bearbeiten kann. Alle Objekte im SAP BW basieren auf konsistenten Metadaten, die ebenfalls über die Administrator Workbench verwaltet werden. Die Bedeutung der Konsistenz zeigt sich, wenn mehrere Objekte identische Dimensionen verwenden. Die Merkmale der Dimension Produkt können in verschiedenen Datenwürfeln wieder verwendet werden, wodurch eine kombinierte Auswertung über mehrere Datenwürfel hinweg möglich ist. Ein erneutes Anlegen der Merkmale und der damit verbundene Aufwand für die Konsistenzprüfung entfallen. Dieses Prinzip wird auch Conformed Dimensions genannt (vgl. SAP AG, 2003a). Der SAP Business Content wird zusammen mit dem SAP BW ausgeliefert und stellt bereits vorkonfigurierte Informationsmodelle bereit. Diese orientieren sich an bestimmten Verwendungszwecken und Einsatzmöglichkeiten. Elemente des SAP Business Content können in eigene Modelle übernommen und dort unverändert verwendet werden, es ist aber auch möglich, die Elemente an die Bedingungen der Aufgabenstellung anzupassen (vgl. Egger, 2004). Auf Metadaten des SAP BW kann zentral über das Metadata Repository zugegriffen werden (vgl. SAP AG, 2003b). Hier werden die Informationen über die im System enthaltenen Objekte im HTML-Format textuell und um Grafiken angereichert präsentiert. Vorrangig handelt es sich um technische Metadaten über das SAP BW und seine Elemente, es können auch individuell gestaltete Dokumente abgelegt werden. Das Repository bietet über eine Suchfunktion die Möglichkeit, eine Recherche anhand von Suchkriterien auszuführen. Auf die Metadaten kann über den Transportanschluss oder XML von externen Quellen aus zugegriffen werden, sie lassen sich aber auch lokal als HTML-Dateien abspeichern (vgl. Mehrwald, 2004). 3.2.3 Analyseschicht Die Schicht zur Entscheidungsunterstützung umfasst grundlegende Funktionen für die Unterstützung von Auswertungen und Werkzeuge zum Gestalten und Ausführen dieser Berichte auf den in der Datenschicht abgelegten Daten. Die Analyseschicht setzt sich zusammen aus der SAP Business Intelligence Platform und der SAP Business Intelligence Suite. Durch die SAP Business Intelligence Platform werden das Berichtswesen unterstützende Funktionen bereitgestellt. Sie umfassen unter anderem den OLAPProzessor für die multidimensionale Anfrageverarbeitung und das Data Mining zum Erkennen von Mustern und regelmäßigen Strukturen im Datenbestand. Das Metadata Repository wird ebenfalls zur SAP Business Intelligence Platform hinzugezählt. Die SAP Business Intelligence Suite besteht aus den Komponenten des SAP Business Explorers, mit dessen Werkzeugen Abfragen angelegt und die Resultate dem Anwender in verschiedenen Arbeitsumgebungen präsentiert werden. Dies kann zum Beispiel im Webbrowser oder unter MS Excel erfolgen.

50

3 Theoretische Grundlagen des SAP Business Information Warehouse

3.3 Datenmodellierung In der Datenmodellierung werden die zur Übertragung, Fortschreibung und Analyse der Daten erforderlichen Daten tragenden Objekte und ihre Struktur gepflegt. Angelegt und bearbeitet werden diese Objekte über die Administrator Workbench, sie werden zur Wahrung der Übersichtlichkeit in einer Baumstruktur angeordnet dargestellt. Im Folgenden werden zunächst die zur Strukturierung eingesetzten Elemente erläutert, im Anschluss wird näher auf die im System erfassten Elemente eingegangen. 3.3.1 Struktur – InfoArea, InfoProvider und InfoObjectCatalog Die im SAP BW modellierten Objekte sind in einer hierarchischen Struktur abgelegt, der so genannten InfoArea-Hierarchie.

Abb. 3.7. InfoProvider-Baum

Diese unterteilt sich wiederum in InfoProvider- und InfoObject-Baum. Als InfoProvider werden alle Objekte bezeichnet, die durch Analysewerkzeuge auswertbar sind. Jeder InfoProvider ist einer InfoArea zuzuordnen und kann nur einmal in die Hierarchie aufgenommen werden (vgl. Mehrwald, 2004). InfoObjects können im Gegensatz zu den InfoProvidern mehrfach in der InfoArea-Hierarchie auftreten. So kann es etwa notwendig sein, ein InfoObject in

3.3 Datenmodellierung

51

mehreren thematisch divergierenden Datenwürfeln als Merkmal anzuführen. Zur mehrfachen Aufnahme der InfoObjects und der damit einhergehenden, an Verwendungsbereichen orientierten Strukturierung der InfoArea-Hierarchie wurden die InfoObjectCatalogs eingeführt. Diese müssen genau wie InfoProvider einem Knoten der InfoArea-Hierarchie zugeordnet sein, können jedoch beliebig viele InfoObjects enthalten. Da InfoObjects zudem in beliebig vielen InfoObjectCatalogs auftreten dürfen, ist es also möglich, sie ebenfalls beliebig vielen InfoAreas zuzuordnen (vgl. Mehrwald, 2004).

Abb. 3.8. InfoObject-Baum

Hinweis: Um den bis hierhin vermittelten theoretischen Inhalt praktisch zu vertiefen, kann an dieser Stelle das Kapitel 4.1.1 Anlegen der InfoArea bearbeitet werden.

3.3.2 InfoObjects InfoObjects bilden als kleinste Informationseinheiten im SAP BW die Grundlage zum Aufbau sämtlicher größerer SAP BW-Objekte, so werden etwa die InfoProvider vollständig über InfoObjects definiert. InfoObjects werden über eindeutige technische Namen identifiziert und durch eine Beschreibung, einen Datentyp und eine Datenlänge näher charakterisiert. Zusätzlich wird in Abhängigkeit vom Typ

52

3 Theoretische Grundlagen des SAP Business Information Warehouse

des InfoObjects eine Vielzahl weiterer Eigenschaften in den Metadaten hinterlegt. InfoObjects können vom Typ Merkmal, Zeit, Einheit oder Kennzahl sein und gleichzeitig auch als InfoProvider auftreten, wenn sie über Stammdaten verfügen (vgl. Mehrwald, 2004). Merkmale Merkmale beschreiben die im SAP BW erfassten Geschäftsvorfälle. Sie sind Ordnungsbegriffe wie Kundengruppe, Region oder Produkt und geben somit Klassifizierungsmöglichkeiten des Datenbestandes vor. Sämtliche zulässigen Ausprägungen eines Merkmals, die so genannten Merkmalswerte, sind in den Stammdaten hinterlegt, in den Dimensionen eines Datenwürfels tritt jedoch meist nur eine Teilmenge dieser Merkmalswerten auf. So können zum Beispiel in den Stammdaten eines Merkmals Land sämtliche existierende Länder codiert sein, in den erfassten Geschäftsvorfällen müssen jedoch nicht alle auftreten. (vgl. Mehrwald, 2004).

Abb. 3.9. Pflegebildschirm Merkmal

Die nachfolgende Tabelle 3.2. Datentypen von Merkmalen gibt die möglichen Datentypen und deren zulässige Länge an, für Auswertungen werden jedoch stets nur die ersten 32 Zeichen berücksichtigt.

3.3 Datenmodellierung

53

Tabelle 3.2. Datentypen von Merkmalen Datentyp CHAR NUMC DATS TIMS

Beschreibung Ziffern und Buchstaben Nur Ziffern Datum Zeit

Zulässige Länge Zeichenlänge 1 - 60 Zeichenlänge 1 - 60 Zeichenlänge 8 Zeichenlänge 6

Neben dem Datentyp können noch einige weitere Einstellungen für Merkmale getroffen werden, wie beispielsweise Konvertierungsroutinen und die Zulässigkeit von Kleinbuchstaben. Grundsätzlich interpretiert das SAP BW sämtliche Merkmalsschlüssel als Großbuchstaben. Wenn allerdings beim Ladevorgang eine Konsistenzprüfung der Merkmalswerte durchgeführt wird, erkennt das SAP BW Kleinbuchstaben als Fehler. Eine Ausnahme kann in der InfoObject-Pflege des betreffenden Objektes eingestellt werden, jedoch ist bei bestehenden Stammdaten ein Entfernen der Markierung nicht mehr möglich (vgl. SAP AG, 2005). Im SAP BW wird bei der Speicherung von Merkmalen zwischen der internen und der externen Darstellung unterschieden. Die interne beschreibt das Format zur Verarbeitung, während die externe Darstellung die Form der Ausgabe festlegt. Interne und externe Darstellung müssen nicht übereinstimmen, sie können etwa in führenden Nullen oder Tausendertrennzeichen differieren. Konvertierungsroutinen bieten INPUT-Bausteine zur Umwandlung des externen ins interne Format und OUTPUT-Bausteine für den Transfer in entgegengesetzter Richtung. Wird die Konvertierungsroutine zu einem InfoObject nachträglich geändert und liegen zu diesem InfoObject bereits Daten im System vor, so muss das interne Format dieser Daten nachträglich an die neue Konvertierungsroutine angepasst werden (vgl. Mehrwald, 2004). In den Registerkarten der Merkmalspflege wird auch das Erscheinungsbild im SAP Business Explorer beeinflusst. Es wird festgelegt, ob das Merkmal etwa mit dem Schlüssel, Kurz- oder Langtext dargestellt werden soll. Für georelevante Merkmale kann die Darstellung in der SAP BEx Map aktiviert werden, man unterscheidet folgende Typen geographischer Merkmale (vgl. Mehrwald, 2004): • Ein statisches Geomerkmal beschreibt eine Fläche (ein Polygon), dessen Koordinaten sich nicht oder nur selten ändern. Beispiele für statische Geomerkmale sind Länder und Kontinente. Die den Geomerkmalen zugrunde liegenden Landkarten werden über so genannte Shape Files ins BW eingebunden. • Ein dynamisches Geomerkmal beschreibt einen Ort (punktförmige Information), dessen Koordinaten sich ändern können, wie etwa die Adresse eines Kunden oder einer Produktionsstätte. Die Koordinaten werden im Rahmen einer Geocodierung ermittelt. • Ein dynamisches Geomerkmal kann Attributswerte aus einem anderen geocodierten Merkmal übernehmen. Die Attributswerte werden zur Laufzeit aus der Stammdatentabelle des Bezugsmerkmals gelesen und müssen nicht redundant gespeichert werden.

54

3 Theoretische Grundlagen des SAP Business Information Warehouse

• Statische Merkmale können auch Geokoordinaten beinhalten und bilden einen Bezugspunkt für die Geomerkmale des dritten Typs. Außerdem wird in der Merkmalspflege bestimmt, ob ein Merkmal Stammdaten und / oder Texte enthalten soll. Nur wenn die Option Mit Stammdaten aktiviert ist, kann ein Merkmal über Attribute verfügen und es können über einen separaten Dialog Stammdaten gepflegt werden. Wird die Option Mit Texten gewählt, so muss mindestens eine der Textformen Kurz-, Mittel- oder Langtext als stets vorhanden selektiert werden. Zusätzlich können die zu einem Merkmal hinterlegten Texte als sprachabhängig markiert sein, so dass sie entsprechend der verwendeten Sprache dargestellt werden. Sollen zu einem späteren Zeitpunkt Hierarchien für das aktuelle Merkmal angelegt oder aus einem Quellsystem geladen werden, so ist bereits beim Erstellen des Merkmals das Kennzeichen Mit Hierarchien zu setzen. Ebenso wird eingestellt, über welche Attribute oder Navigationsattribute ein Merkmal verfügen soll. Als Attribute können bereits gepflegte InfoObjects eingesetzt werden, die dem neuen Merkmal logisch zugeordnet sind. Zugewiesene Attribute lassen sich von Anzeige- in Navigationsattribut durch gesonderte Markierung umwandeln. Zeitmerkmale Obwohl Zeitmerkmale dieselben Aufgaben wie Merkmale haben, so sind sie dennoch als eigener InfoObject-Typ im SAP BW umgesetzt. Bei allen anderen InfoObject-Typen hat der Anwender die Möglichkeit, eigene InfoObjects zu definieren, bei Zeitmerkmalen können jedoch nur die vorgegebenen InfoObjects des SAP Business Contents verwendet werden. Dies hat den Vorteil, dass bei der Modellierung der Zeitdimension diese nicht gesondert validiert werden muss und auch keine separaten Konvertierungsroutinen erstellt werden müssen (vgl. Mehrwald, 2004). Erfüllen die angebotenen Zeitmerkmale die Anforderungen des Anwenders nicht, so bestehen für diesen zwei Möglichkeiten zur Modifikation: Erfüllt lediglich die Bezeichnung nicht die Bedürfnisse, so können Zeitmerkmale, deren Funktionsumfang grundsätzlich den Anforderungen genügt, in der InfoObjectPflege umbenannt werden. Gehen die Anforderungen über den Funktionsumfang bestehender Zeitmerkmale hinaus, können auch gänzlich neu angelegte Merkmale anstatt der Zeitmerkmale verwendet werden. Diese Vorgehensweise führt allerdings dazu, dass die Vorteile der Zeitmerkmale (Validierungsmöglichkeit des Modells und Konvertierung im Staging) entfallen (vgl. Mehrwald, 2004). Referenzierende Merkmale Merkmale können mit Bezug auf ein so genanntes Referenzmerkmal definiert werden. Für das neu angelegte Merkmal werden dann sämtliche technischen Einstellungen des Referenzmerkmals übernommen. Dies betrifft Attribute, Stammdaten, Texte, Hierarchien, Datentyp, Länge, Klammerungen, Kleinbuchstaben und Konvertierungsroutinen. Diese Einstellungen werden jedoch nicht kopiert, es wird

3.3 Datenmodellierung

55

nur auf die physisch selben Datenelemente verwiesen. Dies bedeutet, dass etwa neu geladene Stammdaten des Referenzmerkmals automatisch dem referenzierenden Merkmal zur Verfügung stehen. Zu einem Merkmal können beliebig viele referenzierende Merkmale angelegt werden (vgl. SAP AG, 2005). Das referenzierende Merkmal ist lediglich in der betriebswirtschaftlichen Beschreibung und Darstellung vom Referenzmerkmal unabhängig. Ein typisches Beispiel ist der Einsatz von Partnerrollen: Auftraggeber und Lieferanten eines Unternehmens werden beide durch eine Kundennummer eindeutig identifiziert und können mit Bezug auf ein Referenzmerkmal Kunde angelegt werden, das über das Attribut Kundennummer verfügt. Im Hinblick auf weitere Ausprägungen können sich die Partnerrollen Auftraggeber und Lieferant sowohl unterscheiden als auch gleichen. Würden in diesem Beispiel keine Referenzmerkmale verwendet werden, so müssten drei InfoObjects mit den gleichen Stammdaten definiert werden. Kennzahlen Kennzahlen sind quantifizierende Größen, mit denen mathematische Operationen möglich sind. Sie werden bei Analysen im SAP BW stets in Verbindung mit Merkmalen verwendet, die alleinige Verwendung von Kennzahlen in einem Data Warehouse ist nicht sinnvoll (vgl. Kapitel 2.3.1 Fakten, Kennzahlen und Dimensionen).

Abb. 3.10. Pflegebildschirm Kennzahl

56

3 Theoretische Grundlagen des SAP Business Information Warehouse

In der Datenanalyse werden Kennzahlen mittels arithmetischer Operationen zusammengefasst, die Operationen können zum Beispiel die Bildung von Durchschnitts- oder MIN-/MAX-Werten sein. Außerdem können aus Kennzahlen weitere Kenzahlen wie etwa Differenzen oder prozentuale Veränderungen abgeleitet werden (vgl. Mehrwald, 2004). Neben der Grundeinstellung für jedes InfoObject, dem Datentyp (vgl. Tabelle 3.3. Datentypen von Kennzahlen mit Einheit (vgl. SAP AG, 2005) und Tabelle 3.4. Datentypen von Kennzahlen ohne Einheit (vgl. SAP AG, 2005)), können den Kennzahlen im SAP BW Währungen oder Mengeneinheiten zugewiesen werden. Vorgeschriebene Arten der Aggregation und Ausnahmeaggregation sowie die Anzahl der Dezimalstellen sind festzulegen. Tabelle 3.3. Datentypen von Kennzahlen mit Einheit (vgl. SAP AG, 2005) Typ

Datentyp

Betrag

CURR FLTP QUAN

Menge

FLTP

Beschreibung Währungsfeld abgelegt als DEC Gleitpunktzahl mit 8 Byte Genauigkeit Mengenfeld, zeigt auf Einheitenfeld mit Format UNIT Gleitpunktzahl mit 8 Byte Genauigkeit

Tabelle 3.4. Datentypen von Kennzahlen ohne Einheit (vgl. SAP AG, 2005) Typ Zahl

Datentyp DEC

Integer Datum

FLTP INT4 DEC

Zeit

DATS DEC TIMS

Beschreibung Rechen- oder Betragsfeld mit Komma und Vorzeichen Gleitpunktzahl mit 8 Byte Genauigkeit 4-Byte-Integer, ganze Zahl mit Vorzeichen Rechen- oder Betragsfeld mit Komma und Vorzeichen Datumsfeld (JJJJMMTT), abgelegt als CHAR (8) Rechen- oder Betragsfeld mit Komma und Vorzeichen Zeitfeld (hhmmss), abgelegt als CHAR (6)

Einer Kennzahl vom Typ Betrag oder Menge muss stets eine fixe oder variable (Währungs-) Einheit zugeordnet werden. Diese Einheiten sind für Extraktion, Staging und Datenanalyse bedeutsam, wenn die Kennzahlen mit Bezug zu ihrer Einheit präsentiert oder in andere Einheiten umgerechnet werden sollen. Wird eine fixe Einheit ausgewählt, so wird sie in der Definition der Kennzahl gespeichert. Beim Laden muss also gegebenenfalls eine Umrechnung stattfinden, dafür ist die Einheit später im Datenmodell nicht mehr explizit zu hinterlegen, sondern kann aus der Kennzahldefinition entnommen werden. Bei einer variablen Einheit dagegen wird beim Laden der Daten ein zusätzliches Einheiten-InfoObject angegeben (vgl. Mehrwald, 2004).

3.3 Datenmodellierung

57

Kennzahlen der Typen Zahl, Integer, Datum und Zeit sind ohne Einheit. Die Typen Datum und Zeit sind nicht mit Zeitmerkmalen zu verwechseln, sie können nicht als Ordnungsmerkmale eingesetzt werden. Analog zu Merkmalen können auch referenzierende Kennzahlen definiert werden, die der Eliminierung innerbetrieblicher Umsätze dienen. Die referenzierende Kennzahl wird dann mit dem Ausgangswert der referenzierten Kennzahl gefüllt, die weiteren Berechnungen können sich dann von der Referenzkennzahl unterscheiden. Gesonderte Fortschreibungsregeln für referenzierende Kennzahlen können nicht angelegt werden (vgl. SAP AG, 2005). Aggregationsverhalten von Kennzahlen Bewegungsdaten werden zwischen Quellsystem, BasisCubes und Datenanalyse häufig mehrfach entsprechend dem in der Kennzahlpflege festgelegten Aggregationstyp verdichtet. Unter einer Standardaggregation versteht man das einfache Aufsummieren oder die Ermittlung von MIN-/MAX-Werten. Ausnahmeaggregationen sind Aggregationsverfahren mit Bezug auf andere InfoObjects und nur unter Angabe einer Bezugsgröße sinnvoll (vgl. SAP AG, 2005). Ein Beispiel ist die Durchschnittsbildung, bei der stets ein zeitlicher Bezug hergestellt werden muss. Bei Bestandskennzahlen ist in der Definition der InfoObjects zu hinterlegen, wie der Bestand ermittelt wird. Das Erfassen der Bestandsveränderungen kann entweder über eine einzige Kennzahl oder über zwei Kennzahlen mit getrennten Zu- und Abgängen erfolgen (vgl. SAP AG, 2005). Eine Aggregation über Zeitmerkmale ist für Bestandskennzahlen nur über Ausnahmeaggregationen möglich, so ist es zum Beispiel wenig sinnvoll, die Anzahl Mitarbeiter einer Abteilung über eine Periode zu addieren. Demgegenüber werden Flusskennzahlen über alle Merkmale, also auch die zeitlichen, aufsummiert. Neben den Bezugsmerkmalen haben Bestandskennzahlen einen Gültigkeitsbereich, der in der Gültigkeitstabelle abgelegt wird. Dieser legt fest, welchem Zeitraum der Bestand zugeordnet wird, da aus dem Ladezeitpunkt der Daten nicht unbedingt auf den Bezugszeitraum geschlossen werden kann. So kann eine zeitraumbezogene Auswertung mit höherer Genauigkeit ausgeführt werden (vgl. SAP AG, 2005). Bei der Verwendung von Bezugsmerkmalen sollte darauf geachtet werden, keine InfoObjects mit mehr als 30 Merkmalsausprägungen als Bezugsmerkmal auszuwählen. Die Anzahl der Merkmalsausprägungen beeinflusst die Komplexität der bei Auswertungen auszuführenden SQL-Kommandos und damit direkt die Performance der Analyse (vgl. Mehrwald, 2004). Einheiten In Einheiten-InfoObjects ist erfasst, ob es sich bei der verknüpften Kennzahl um eine Währung oder eine Mengeneinheit handelt. Sie treten stets als zusätzliche Information zu einem Betrag oder einer Menge auf. Beim Anlegen des EinheitenInfoObjects ist daher nur zwischen Mengeneinheit und Währung zu wählen, sämt-

58

3 Theoretische Grundlagen des SAP Business Information Warehouse

liche Einheiten-InfoObjects basieren technisch auf 0CURRENCY bzw. 0UNIT (vgl. Mehrwald, 2004). Stammdaten – Texte, Attribute und Hierarchien Stammdaten werden im SAP BW dazu verwendet, ergänzende Eigenschaften zu Merkmalen aktuell oder stichtagsbezogen anhand von Gültigkeitszeiträumen darzustellen. Stammdaten erfahren nur selten Änderungen und umfassen Texte, Attribute und Hierarchien eines Merkmals. Die Dateninhalte werden zumeist aus den Quellsystemen importiert, können aber auch manuell im SAP BW erstellt werden. Texte Unter Texten versteht man Beschreibungen der Merkmalsausprägungen, deren Werte, wie der Länderschlüssel DK für Dänemark, allein für den Betrachter nicht ausreichend verständlich sein müssen. In der InfoObject-Pflege wird neben der Information, ob zu einem Merkmal Texte vorhanden sind, ebenfalls die Länge der vom Quellsystem gelieferten Texte festgelegt. Unterschiedliche Textlängen sind für Auswertungen sinnvoll, die aus Gründen der Übersichtlichkeit kürzere Texte verwenden sollen als andere. Tabelle 3.5. Textlängen Textart Kurztext Mittellanger Text Langtext

Maximale Textlänge 20 Zeichen 40 Zeichen 60 Zeichen

3.3 Datenmodellierung

59

Abb. 3.11. Pflegebildschirm Texte

Bei Aktivierung der Sprachabhängigkeit wird in der Texttabelle eine zusätzliche Spalte für den Sprachschlüssel eingefügt. Je nach eingestellter Sprache greift das System dann auf den korrespondierenden Eintrag zurück. Die Sprachabhängigkeit sollte nur dann verwendet werden, wenn das Quellsystem auch Textinformationen in verschiedenen Sprachen zur Verfügung stellen kann und die Informationen für die Analyse tatsächlich in verschiedenen Sprachen benötigt werden, da sich mit jeder neu hinzugefügten Sprache die Anzahl der Datensätze in den Texttabellen vervielfacht. In den InfoObjects des Business Content ist die Sprachabhängigkeit vielfach standardmäßig aktiv, diese Einstellung sollte bei Verwendung der entsprechenden Objekte gegebenenfalls korrigiert werden (vgl. Mehrwald, 2004). Wie alle Stammdaten können auch Texte nur für einen bestimmten Zeitraum gültig sein. Die Texttabelle wird dafür um ein Datenfeld für den Gültigkeitszeitraum ergänzt, so dass beim Reporting der für den Analysezeitraum gültige Eintrag bezogen werden kann. Sind einmal Daten in die Texttabellen geladen worden, kann nachträglich nicht mehr auf eine zeitabhängige Präsentation umgestellt werden. Aus Gründen der Performance ist auch die Zeitabhängigkeit nur dann zu verwenden, wenn sie für die Auswertungen als besonders nützlich beurteilt wird (vgl. Mehrwald, 2004). Attribute Im Gegensatz zu Texten können Attribute nicht nur als beschreibende Elemente, sondern auch zur Selektion und Navigation während der Datenanalyse eingesetzt werden. Attribute sind bereits angelegte InfoObjects und werden wie die anderen

60

3 Theoretische Grundlagen des SAP Business Information Warehouse

Stammdaten auch in der InfoObject-Pflege aktiviert. Jedes InfoObject mit Stammdaten kann beliebig viele weitere InfoObjects aufnehmen, die in geklammerte, zeitkonstante und zeitabhängige Attribute sowie Navigationsattribute unterschieden werden (vgl. Mehrwald, 2004). Bei der Option Klammerung werden die Datensätze eines Merkmals zur eindeutigen Identifikation mit einem zusammengesetzten Primärschlüssel verbucht. Enthalten zwei unterschiedliche Produktionsstätten jeweils ein Lager A, so können diese erst durch die Ergänzung des Schlüssels um eine Information zur Produktionsstätte unterschieden werden. Diese zusätzlichen Informationen sind jedoch nur zur Anzeige bestimmt, sie sind nicht als Filter oder für eine Drill-Down Operation geeignet. Zeitkonstante Attribute liegen unabhängig vom Betrachtungszeitraum nur in einer aktuellen Form zu einem InfoObject vor. Analog zur Speicherung von Texten können auch Attribute stichtagsbezogen abgelegt werden, allerdings wird hier die Zeitabhängigkeit nicht wie bei den Texten global, also für sämtliche Attribute, bestimmt, sondern kann für jedes Attribut separat zugeschaltet werden (vgl. SAP AG, 2005). Beispielsweise kann der Kontinent als zeitkonstantes Attribut zum Land auftreten, da diese Zuordnung nicht geändert wird. Ändert sich das Produktsortiment eines Unternehmens erheblich, so kann es vorkommen, dass ein Attribut für ein neues Produkt nicht mehr gültig ist. Da die älteren Produkte aber noch immer in Auswertungen benötigt werden, wird das Attribut mit einem Gültigkeitszeitraum versehen.

Abb. 3.12. Pflegebildschirm Attribute

3.3 Datenmodellierung

61

InfoObjects, die ausschließlich Anzeigeattribute sind, werden stets zusammen mit dem Bezugsmerkmal in einer Auswertung abgebildet. Anzeigeattribute können nicht in Dimensionstabellen aufgenommen werden und tragen zudem selbst keine Attribute (vgl. Mehrwald, 2004). Das Gewicht eines Produkts kann ein typisches Anzeigeattribut sein. Navigationsattribute sind zur Definition der Sicht auf den Datenbestand und als Filter in Anfragen geeignet. Dabei ist es möglich, sowohl zeitkonstante als auch zeitabhängige Attribute als Navigationsattribut anzulegen. Hat ein Navigationsattribut selbst zugeordnete Attribute, so stehen diese nun ebenfalls dem übergeordneten, Stammdaten tragenden InfoObject zur Verfügung (vgl. SAP AG, 2005). Trägt die Produktgruppe das Navigationsattribut Produkthauptgruppe, so können die Kennzahlen auch nach Produkthauptgruppen angeordnet und aggregiert werden. Ist der Produkthauptgruppe wiederum ein Attribut Lagerort zugeordnet, so kann dieses Attribut ebenfalls direkt zur Produktgruppe abgerufen werden. Attribute Hierarchien dienen der Zusammenfassung und Gliederung verschiedener Merkmalsausprägungen, jede Hierarchie kann nur einem einzigen InfoObject zugewiesen werden. Sie können in Form von Bäumen modelliert werden, d. h. es existiert ein oberster Hierarchieknoten, die Hierarchiewurzel, sowie weitere darunter liegende Hierarchieknoten, die je genau einen Vaterknoten besitzen. Je nach Entfernung von der Hierarchiewurzel werden verschiedene Hierarchieebenen unterschieden, im Rahmen der Datenanalyse werden die Werte stets auf die Knoten der direkt übergeordneten Ebene aggregiert (vgl. Mehrwald, 2004). Es existieren drei Möglichkeiten, Hierarchien im SAP BW abzubilden: externe Hierarchien, Hierarchien in Merkmalsattributen und Hierarchien in Dimensionsattributen. Externe Hierarchien werden außerhalb der Stammdatenpflege eines InfoObjects angelegt, jedes InfoObject kann mehrere externe Hierarchien besitzen. Sie sind sehr flexibel zu handhaben, da sie verändert werden können, ohne dass Anpassungen im Datenmodell erforderlich wären. Bei der Analyse mit den Werkzeugen des SAP Business Explorer werden die Hierarchien als solche dargestellt, d. h. dem Anwender wird die Reihenfolge der Hierarchiestufen fix vorgegeben. Demgegenüber steht der Nachteil, dass externe Hierarchien bei der Analyse wenig performant sind (vgl. Mehrwald, 2004). Man unterscheidet zwei Typen von Hierarchieknoten: nicht bebuchbare Knoten bilden die Struktur der Hierarchie. Der Anwender hat beim Aufbau hinsichtlich der Bezeichnung und der Tiefe der Verästelung alle Freiheiten, so dass die Struktur vollständig an den fachlichen Anforderungen ausgerichtet werden kann. Es ist etwa möglich, auch unbalancierte Bäume zu definieren. Zu den nicht bebuchbaren Knoten zählen Text- und Merkmalsknoten. Textknoten werden ausschließlich durch ihren Namen und ihre Beschreibung identifiziert, in Merkmalsknoten werden anstatt einer Bezeichnung die Ausprägungen eines InfoObjects hinterlegt, welche bei Verwendung der Hierarchie aus den Texttabellen des InfoObjects abgerufen werden und somit immer den aktuellen Datenbestand wiedergeben. In bebuchbaren Knoten sind die Merkmalsausprägungen des InfoObjects enthalten und in die Hierarchie eingeordnet. Ein Sonderfall der bebuchbaren Knoten sind

62

3 Theoretische Grundlagen des SAP Business Information Warehouse

die Hierarchieintervalle, in denen eine Menge von Merkmalswerten abgelegt wird (vgl. Mehrwald, 2004).

Abb. 3.13. Hierarchie

Wird eine Hierarchie in Attributen hinterlegt, ist auch bei großen Hierarchien eine hohe Leistungsfähigkeit bei der Auswertung gewährleistet. Jedoch ist in diesem Fall die Anzahl der möglichen Hierarchiestufen fest vorgegeben und der Hierarchiebaum muss balanciert sein. Veränderungen in der Hierarchiestruktur können ausschließlich über die Pflege der betreffenden InfoObjects erfolgen und sind somit bedeutend aufwändiger zu realisieren als in externen Hierarchien. In einer SAP Business Explorer Auswertung werden die Hierarchien nicht optisch als solche dargestellt, der Anwender muss also wissen, welche Kombination von Attributen eine Hierarchie bildet (vgl. Mehrwald, 2004). Externe Hierarchien können sowohl versions- als auch zeitabhängig im System gespeichert werden, Hierarchien in Attributen nur zeitabhängig. Die Zeitabhängigkeit verhält sich analog zu der Zeitabhängigkeit der übrigen Stammdaten und kann entweder für die gesamte Hierarchie oder für jeden Knoten separat bestimmt werden. Bei der Verwendung unterschiedlicher Versionen ist dagegen stets eine aktive Version festzulegen (vgl. SAP AG, 2005). Dies kann sinnvoll sein, wenn sich eine Präsentation eines Berichtes an unterschiedliche Adressaten richtet, die einen individuellen Aufbau der Hierarchie erwarten. Eine Dimensionshierarchie wird in einem InfoProvider angelegt und ist nur für diesen gültig. Sie kann nicht mehr nachträglich verändert werden, es sei denn, der InfoProvider wird neu geladen. Wie auch bei der Hierarchiemodellierung durch Attribute müssen die Hierarchiebäume balanciert sein (vgl. Mehrwald, 2004). Hinweis: Um den bis hierhin vermittelten theoretischen Inhalt praktisch zu vertiefen, kann an dieser Stelle das Kapitel 4.1.2 Anlegen des InfoObjectCatalogs und der InfoObjects bearbeitet werden.

3.3 Datenmodellierung

63

3.3.3 InfoCubes und Dimensionen InfoCubes dienen im SAP BW der physischen Speicherung von Daten in Faktenund Dimensionstabellen sowie der Bereitstellung der Daten für Analysezwecke. Es werden zwei Arten physisch Daten tragender InfoCubes unterschieden: Standard-BasisCubes und transaktionale BasisCubes. Erstgenannte sind optimiert für performante Lesezugriffe, während transaktionale BasisCubes parallele Schreibzugriffe unterstützen (vgl. SAP AG, 2002a). BasisCubes sind nach dem so genannten erweiterten Star-Schema aufgebaut, das SAP BW-spezifisch konzipiert und unter anderem um unbalancierte Hierarchien und die stichtagsbezogene Historisierung von Attributen ergänzt wurde. Sie können 16 Dimensionen à 253 Merkmale aufnehmen, das ergibt eine maximale Anzahl von 4048 InfoObjects pro BasisCube. 13 dieser Dimensionen können vom Anwender individuell definiert werden, fest vorgegeben sind die Dimensionen Zeit, Einheit und Paket. In letzterer sind technische Details zum Ladevorgang erfasst, so dass einzelne Ladevorgänge gezielt administriert werden können (vgl. Mehrwald, 2004).

Abb. 3.14. Pflegebildschirm InfoCube

Eine spezielle Form zur Speicherung von Dimensionen ist die Line-Item-Dimension. Hierbei wird kein zusätzlicher Schlüssel aus einer Dimensionstabelle in die Faktentabelle geschrieben, stattdessen wird die Stammdaten-ID des Merkmals direkt in die Faktentabelle aufgenommen. Die Dimensionstabelle entfällt somit gänzlich, daher führen Line-Item-Dimensionen zu einer Verbesserung der Perfor-

64

3 Theoretische Grundlagen des SAP Business Information Warehouse

mance, können aber nur eingesetzt werden, wenn eine Dimension lediglich aus einem einzigen InfoObject besteht (vgl. SAP AG, 2003c). Aus Gründen der Leistungsfähigkeit wird ein möglichst breiter Einsatz der Line-Item-Dimensionen empfohlen, bei großen Datenvolumen kann es sogar sinnvoll sein, gezielt nur ein InfoObject pro Dimension zu modellieren (vgl. Mehrwald, 2004). Wenn beispielsweise das InfoObject Belegnummer eine Dimension in einem InfoCube bildet, so ist eine Line-Item Dimension hier sinnvoll, da genau ein Eintrag aus der Faktentabelle eindeutig mit einer Belegnummer verknüpft ist (vgl. SAP AG, 2005). Neben den physischen Daten tragenden InfoCubes existieren im SAP BW auch virtuelle Datenablagen. RemoteCubes sind InfoCubes, deren Bewegungsdaten nicht im SAP BW gespeichert sind. Stattdessen wird hier nur die Struktur des Datenwürfels definiert, die Daten werden zur Auswertung über Schnittstellen aus anderen Systemen gelesen. Auf diese Weise können sowohl der Speicherplatzbedarf als auch der Administrationsaufwand des SAP BW Systems gering gehalten werden. SAP RemoteCubes erlauben die Definition von Anfragen auf Bewegungsdaten, die sich in anderen SAP-Systemen befinden. Stammdaten und Hierarchien werden nicht aus dem Quellsystem gelesen und sollten daher bei Ausführung einer Anfrage bereits im SAP BW hinterlegt worden sein. SAP RemoteCubes sollten zum Einsatz kommen, falls zeitnahe Daten aus einem SAP Quellsystem benötigt werden, gleichzeitig aber nur wenige Zugriffe auf den Datenbestand erfolgen (vgl. SAP AG, 2005). Virtuelle InfoCubes mit Services sind ebenfalls InfoCubes ohne physische Datenablage im SAP BW. Als Datenquelle dient diesem InfoProvider ein vom Anwender konfigurierbarer Funktionsbaustein. Dadurch ist ein virtueller InfoCube mit Services im Vergleich zu einem RemoteCube flexibler, aber auch aufwändiger zu implementieren (vgl. SAP AG, 2005). Hinweis: Um den bis hierhin vermittelten theoretischen Inhalt praktisch zu vertiefen, kann an dieser Stelle das Kapitel 4.1.3 Anlegen des InfoCubes für die Ist-Daten bearbeitet werden.

3.3.4 ODS-Objekte Ebenso wie BasisCubes dienen die ODS-Objekte zur Aufnahme von Bewegungsdaten. Während erstere jedoch nicht-volatile Daten beinhalten, kann man ODSObjekte auch mit veränderbaren Daten befüllen (vgl. Inmon, 1999b). Daneben wird das ODS-Objekt auch für die Integration und Speicherung konsolidierter Daten und damit als Grundlage für die weitere Verarbeitung dieser im SAP BW verwendet. Der Einsatz von ODS-Objekten entspricht also weitgehend der klassischen Definition einer Basisdatenbank im Data Warehouse, die um die Analyse veränderlicher Transaktionsdaten in der Qualität konsolidierter Daten erweitert wurde (vgl. SAP AG, 2000, und Inmon, 1999b). Das mit ODS-Objekten mögliche operative Reporting umfasst das Status Tracking (Nachvollziehen von Änderungen), selektive Analysen auf atomarer Ebene sowie die Unterstützung von Staging

3.3 Datenmodellierung

65

und Extraktion. Die Daten werden in flachen Datenbanktabellen und nicht in einer Struktur aus Fakten- und Dimensionstabellen gespeichert (vgl. SAP AG, 2002a). ODS-Objekte enthalten nicht aggregierte Daten, also Daten hoher Granularität (vgl. Fuller, 2002a, und Inmon, 1999b). Definiert werden sie durch Schlüssel- und Datenfelder, bei denen es sich jeweils um InfoObjects handelt. Schlüsselfelder sind diejenigen Felder einer Transaktion, welche die Transaktion kennzeichnen und es so möglich machen, Transaktionsveränderungen korrekt verarbeiten zu können. Alle weiteren Felder, die nicht Teil der Schlüssel und damit selbst abhängig von den Schlüsselfeldern sind, werden als Datenfelder bezeichnet (vgl. SAP AG, 2002a). Daten aus ODS-Objekten können entweder in weitere ODS-Objekte oder in InfoCubes fortgeschrieben werden, sie lassen sich aber auch direkt für das Reporting einsetzen. Je nach Aufgabe werden Standard-ODS-Objekte und transaktionale ODS-Objekte unterschieden. Standard-ODS-Objekte enthalten bereits konsolidierte Daten und verfügen über zwei zusätzliche Funktionen: zum einen kann die Fortschreibung aus mehreren DataSources parallelisiert und damit beschleunigt werden, zum anderen kann das Überschreiben von Datenfeldern als Delta-Information an andere InfoProvider übermittelt werden, so dass das bei Updates zu übertragende Datenvolumen verringert wird (vgl. Mehrwald, 2004).

Abb. 3.15. Pflegebildschirm ODS-Objekte

Transaktionale ODS-Objekte eignen sich auch als Datenquelle für Auswertungen und ermöglichen das Überschreiben bei der Fortschreibung von Bewegungsdaten. Im Gegensatz zu Standard-ODS-Objekten wird in transaktionalen nur eine einzige

66

3 Theoretische Grundlagen des SAP Business Information Warehouse

Version der Daten gehalten. Dadurch verhalten sie sich ähnlich wie einfache Tabellen in einem operativen System. Ihr Nachteil liegt darin, dass sie nicht den Staging Prozess durchlaufen und kein Status der Ladevorgänge beschrieben werden kann. Alle Objekte werden ohne Prüfung der Fehlerfreiheit oder Vollständigkeit der Analyse zur Verfügung gestellt. Eine Fortschreibung der Daten in andere BW-Objekte ist nicht möglich (vgl. SAP AG, 2005). 3.3.5 InfoSets InfoSets sind Metadaten Objekte, die über keinen physischen Datenspeicher verfügen. Stattdessen werden die benötigten Daten zum Zeitpunkt der Analyse direkt aus den Datenquellen wie ODS-Objekten oder Stammdaten geladen. Sie werden dort eingesetzt, wo Daten über mehrere InfoProvider hinweg analysiert und mittels Join Operation relational verknüpft werden sollen. Beispiele sind das Stammdatenreporting oder sehr spezifische Analysen, die so selten ausgeführt werden, dass für sie kein eigener physischer Speicher eingerichtet werden soll. Die Analyse beschränkt sich jedoch ausschließlich auf die Präsentation der Abfrageergebnisse, Operationen wie Navigation, Verwendung von Hierarchien oder Währungsumrechnung sind mit InfoSets nicht möglich. Aufgrund der immensen Nachteile bezüglich der Performance und des Funktionsumfangs sollten InfoSets bei häufigerem Gebrauch durch InfoProvider ersetzt werden (vgl. Mehrwald, 2004).

Abb. 3.16. InfoSet

3.3 Datenmodellierung

67

3.3.6 MultiProvider Soll die Datenanalyse nicht auf einem einzigen InfoProvider basieren, so können die Daten mehrerer Reportingobjekte logisch in MultiProvidern zusammengeführt werden. Dies kann aus verschiedenen Gründen sinnvoll sein (vgl. Mehrwald, 2004): • Verschiedene InfoProvider repräsentieren jeweils betriebswirtschaftlich abgeschlossene Bereiche und verfügen neben gemeinsamen Merkmalen ansonsten über eine heterogene Struktur. Die gemeinsamen Merkmale sollen nun im Reporting zusammengeführt werden. • Aus technischen Gründen können Daten nicht in einem einzigen InfoProvider gehalten werden und müssen somit auf mehrere (z.B. BasisCubes, virtuelle Cubes und ODS-Objekte) verteilt werden. Diese Daten sollen nun in einen Zusammenhang gestellt werden. • Der Datenbestand ist aus Gründen des Designs auf mehrere InfoProvider aufgeteilt (z.B. getrennte InfoProvider für Plan- und Ist-Daten), diese sollen nun verglichen werden. • Es soll eine logische Schicht über den einzelnen InfoProvidern aufgebaut werden, um das Reporting auf eine von der Struktur der InfoProvider abstrahierte Ebene zu transferieren. • Zur Verbesserung der Leistungsfähigkeit des Systems wurde der Datenbestand auf mehrere InfoProvider verteilt und soll nun zu Zwecken der Analyse wieder zusammengeführt werden. Ein MultiProvider stellt stets nur eine zusätzliche logische Schicht über den InfoProvidern dar und beeinflusst deren Funktion nicht. Dabei kann ein InfoProvider gleichzeitig Bestandteil mehrerer MultiProvider sein. Queries an MultiProvider werden in Teilanfragen zerlegt und von den beteiligten InfoProvidern in der Regel parallel bearbeitet, was sich günstig auf die Performance von Lesevorgängen auswirkt (vgl. Mehrwald, 2004). Die beim Anlegen eines MultiProviders notwendigen Einstellungen sind grundsätzlich gleich denen eines InfoCubes, es müssen etwa Dimensionen und Navigationsattribute angelegt werden. Im Gegensatz zu physisch Daten tragenden Objekten werden jedoch diese Informationen lediglich in den Metadaten gesichert. Während der Definition werden keine zur Aufnahme von Daten fähigen Tabellen dem MultiProvider zugeordnet, sondern die Daten der verknüpften InfoObjects durch Union Operation zusammengeführt (vgl. SAP AG, 2005). Da die MultiProvider nur in den Metadaten definiert sind, kann diese Zuordnung flexibel durch Hinzufügen oder Entfernen von InfoProvidern verändert werden, ohne dass dies bereits definierte analyserelevante Einstellungen wie Queries betrifft. Die Verwendung von MultiProvidern kann durchaus auch dann sinnvoll sein, wenn keine Datenbestände verschiedener InfoProvider zusammengeführt werden sollen, da über die InfoProvider ihr Datenbestand flexibel und unabhängig von der Analyse ausgetauscht werden kann (vgl. Mehrwald, 2004).

68

3 Theoretische Grundlagen des SAP Business Information Warehouse

Bei der Definition eines MultiProviders kann der Fall eintreten, dass mehrere InfoProvider über InfoObjects gleicher Bedeutung verfügen und diese im MultiProvider auch als einzelne Objekte behandelt werden müssen. Daher ist es notwendig, sämtliche InfoObjects zu identifizieren und so die fachlich identischen Merkmale aufeinander abzubilden. Das BW erstellt für diese Identifikation einen automatischen Vorschlag, der vom Anwender manuell angepasst werden kann, jedoch ist für jedes InfoObject im MultiProvider mindestens ein InfoObject eines InfoProviders zu identifizieren. Die Identifikation erfolgt getrennt für Kennzahlen und Merkmale, zudem ist eine Zusammenführung unterschiedlicher Kennzahlen (z.B. durch Aufsummieren) nicht möglich (vgl. SAP AG, 2005).

Abb. 3.17. Pflegebildschirm MultiProvider

3.4 Datenbeschaffung

69

3.4 Datenbeschaffung Die Datenbeschaffung ist die erste Phase des Data Warehousing. In ihr werden alle erforderlichen Maßnahmen ergriffen, um Daten aus Quellsystemen in das Data Warehouse zu replizieren. Inhalte der Phase sind die Definition der für den ETL-Prozess notwendigen Objekte, Regeln und Parameter sowie das Überwachen des gesamten Vorgangs vom Anlegen der Quellsysteme im SAP BW bis hin zum Laden der Daten in die Datenziele. Das für den ETL-Prozess von der SAP AG empfohlene Modell beginnt mit der Übertragung der Daten vom Quellsystem in die PSA. Die für den Vorgang erforderlichen Metainformationen werden in einer so genannten DataSource hinterlegt, diese beschreibt die Struktur des Quellsystems. Gemeinsam mit der DataSource wird die Transferstruktur für das Übertragen der Daten aus dem Quellsystem in das SAP BW verwendet. Mit ihrer Hilfe wird definiert, wie die Daten in das SAP BW repliziert werden. Wenn sich die Daten in der PSA befinden, können bereinigende Schritte zur Sicherung der Datenqualität erfolgen. Von der PSA aus werden die Daten entsprechend der Transferstruktur der DataSource und der Kommunikationsstruktur der InfoSource in das ODS-Objekt übertragen. Auf dem Weg zum ODS-Objekt können die Daten über geeignete Übertragungsregeln konsolidiert werden. Durch Fortschreibungsregeln werden die Daten anschließend aus der langlebigen Datenablage in die InfoCubes geladen, die auch als Reportingablage bezeichnet werden (vgl. SAP AG, 2002b).

Abb. 3.18. ETL-Prozess Standardmodell

Die Standard-Vorgehensweise bei der Durchführung des ETL-Prozesses muss jedoch nicht zwingend befolgt werden. Das SAP BW lässt auch eine Datenbeschaffung ohne Fortschreibung in InfoCubes zu. Besonders wenn die Daten häufigen Änderungen unterliegen, ist diese Methode der Standard-Empfehlung vorzuziehen (vgl. SAP AG, 2005).

Abb. 3.19. ETL Prozess mit ODS-Objekt und ohne InfoCube

Wenn die Konsolidierung der Daten nicht erforderlich ist, weil sie bereits den Ansprüchen an die Datenqualität genügen, so kann auf die Befüllung der ODS-Ob-

70

3 Theoretische Grundlagen des SAP Business Information Warehouse

jekte verzichtet werden. Die Daten werden dann ohne Umwege aus der PSA direkt in den InfoCube geladen (vgl. SAP AG, 2005).

Abb. 3.20. ETL Prozess ohne ODS-Objekt und mit InfoCube

Das Befüllen eines InfoCubes kann auch über einen anderen InfoCube erfolgen. Diese Art der Datenbeschaffung spiegelt sich bei Data Mart Konzepten wieder, in denen die Daten aus einem Data Warehouse in ein anderes transferiert werden, um die Belastung der Systeme auszugleichen oder die Übersichtlichkeit der Systemarchitektur zu erhöhen (vgl. SAP AG, 2005).

Abb. 3.21. Weiterverarbeitung von InfoCube zu InfoCube

Werden bei der Datenbeschaffung SAP RemoteCubes eingesetzt, die ihre Daten zeitnah aus den OLTP-Systemen beziehen, so entfällt die PSA gänzlich. Dieses Szenario wird besonders bei geringen, hochaktuellen Datenmengen mit niedriger Komplexität eingesetzt, die für einen kleinen Benutzerkreis von Bedeutung sind (vgl. SAP AG, 2005).

Abb. 3.22. ETL mit SAP RemoteCube

Weil das SAP BW auch als Datenquelle für andere Systeme in Erscheinung treten kann, werden an dieser Stelle die Möglichkeiten des Open Hub Service vorgestellt. Die Systemlandschaft eines Unternehmens kann auch im Bezug auf die Entscheidungsunterstützung heterogen sein. Für diesen Fall werden externe Anwendungen an das SAP BW über die InfoSpoke angebunden. Sie legt die Quellobjekte der Daten und die Struktur des Zielsystems fest, außerdem wird in ihr definiert, ob ein Full-Update oder Delta-Update Extraktionsmodus verwendet werden soll. Beim Full-Update werden alle für die Übertragung vorgesehenen Daten aus der Datenquelle übertragen, beim Delta-Update nur die Datensätze, die seit der letzten Extraktion geändert wurden oder neu hinzugekommen sind. Als Quellobjekte kön-

3.4 Datenbeschaffung

71

nen InfoCubes, ODS-Objekte sowie InfoObjects mit Texten oder Attributen dienen, allerdings ist das Delta-Update auf ODS-Objekte und InfoCubes beschränkt. Als Zielsystem sind flache Dateien im CSV-Format oder Tabellen der Datenbank möglich, auf der auch das BW seine Daten ablegt (vgl. SAP AG, 2005).

Abb. 3.23. Open Hub Service

3.4.1 Extraktion Mit der Extraktion der Daten aus dem Quellsystem beginnt der Prozess der Datenbeschaffung. Entsprechend dem von der SAP AG empfohlenen Standard-Prozess werden zunächst die Quellsysteme für die Extraktion identifiziert und im SAP BW über Metadaten als DataSources definiert. Anschließend werden die Daten aus dem Quellsystem gelesen und unter Verwendung von unterschiedlichen Technologien entsprechend der Transferstruktur in die PSA übertragen. Damit endet die Phase der Extraktion. Quellsysteme und Anbindungstechnologien Ein Quellsystem stellt Daten für das SAP BW bereit und gestattet es, diese über Schnittstellen zu beziehen. Viele dieser Quellen bieten Metadaten an, die eine Schnittstelle zu ihnen beschreiben. Ausnahmen sind zum Beispiel flache Dateien, da sie keine SAP BW-kompatiblen Informationen für die Definition einer DataSource liefern. Um das SAP BW in die oft verschiedenartige Systemlandschaft eines Unternehmens zu integrieren, wurden bei der Entwicklung Möglichkeiten geschaffen, um Daten aus einer Vielzahl von Quellsystemen zu laden. Die Pflege der Quellsysteme wird in der Administrator Workbench im gleichnamigen Bereich vollzogen.

72

3 Theoretische Grundlagen des SAP Business Information Warehouse

Abb. 3.24. Anbindung verschiedener Quellsysteme

Fast selbstverständlich ist die Anbindung an SAP-Systeme wie das SAP R/3, das SAP CRM (Customer Relationship Management) oder aber das SAP SEM, welches das strategische Unternehmensmanagement unterstützt. Um Daten aus SAPSystemen zu beziehen, werden Extraktoren eingesetzt. Diese stellen die Datenfelder eines SAP-Systems in einer so genannten Extraktstruktur bereit. Diese für die Extraktion maßgebliche Struktur einer DataSource wird direkt im betroffenen SAP-Quellsystem gepflegt und aus diesem über einen Metadaten-Upload in das SAP BW repliziert. Anwendungsspezifische Extraktoren werden von der SAP AG im Rahmen der Service-API ausgeliefert und können mit DataSources des SAP Business Content verbunden werden. Die anwendungsspezifischen Extraktoren sind bereits auf bestimmte SAP-Anwendungen vorkonfiguriert, weil die Struktur der Datenbanktabellen dieser Anwendungen bei der Einführung in ein Unternehmen meist nicht vom Auslieferungszustand abweicht. Bei anderen SAP-Anwendungen ist es hingegen notwendig, das Datenmodell durch tief greifende Veränderungen auf die Bedarfe des Kunden einzurichten. Darum können neben den voreingestellten Extraktoren auch generische eingesetzt werden, die individuell an die Datenbank eines bereits eingerichteten Systems angepasst werden können (vgl. Egger, 2005). Neben SAP-Systemen können fremde relationale Datenbanken an das SAP BW angebunden werden, sofern sie von der im SAP BW eingesetzten DB ConnectMethode unterstützt werden. Das SAP BW kommuniziert über die vom Application Server erstellte Verbindung mit dem Datenbankmanagementsystem der fremden Datenbank und greift auf die Dateninhalte zu, ohne dass hierzu separate Anwendungen erforderlich wären. Es müssen allein ein DB-Client und eine Erweiterung der SAP Datenbankschnittstelle Database Shared Library (DBSL) für die korrespondierende Datenbank vorliegen. Die DB Connect Technologie erlaubt es, SQL-Befehle automatisch über die erstellte Verbindung an die Datenbank zu übermitteln und damit Anfragen auf Tabellen oder Sichten relationaler Datenbanken

3.4 Datenbeschaffung

73

auszuführen. Welche Tabellen betroffen sind, wird zuvor in der DataSource durch Metadaten festgelegt. Die Ergebnistabelle der Anfrage wird wie andere Daten auch über die dafür eingerichtete DataSource in das BW hineingeladen. Dort werden die Daten entsprechend den Anforderungen verarbeitet und weitergeleitet (vgl. SAP AG, 2002b). Wenn Massendaten in das SAP BW geladen werden sollen und die Anbindung einer Datenbank nicht möglich ist, so können strukturierte Schnittstellendateien eingesetzt werden. Diese auch Flat Files genannten Dateien können entweder im Character Separated Values-Format (CSV) oder aber im American Standard Code for Information Integration-Format (ASCII) vorliegen (vgl. Leslie und Nithiananda, 2003). Über diese Dateien können sämtliche Bewegungs- und Stammdaten in das BW übertragen werden. Die für den Ladevorgang benötigten Dateien können sich auf beliebigen, für das SAP BW zugänglichen Systemen befinden. Um die Ladezeiten zu verkürzen, empfiehlt es sich, die Dateien auf einem Applikationsserver abzulegen (vgl. Mehrwald, 2004). Im CSV-Format werden die einzelnen Daten eines Datensatzes durch spezielle Zeichen von einander getrennt. Häufig wird hierfür das Komma oder Semikolon verwendet, es können aber auch andere Zeichen als Separator definiert werden. Dabei ist zu beachten, dass diese Trennzeichen nicht als Dateninhalt verwendet werden dürfen, da sonst die korrekte Zuordnung der Spalten nicht mehr gegeben ist. Leere Felder werden in einer CSV-Datei abhängig vom Feldtyp mit einem Leerzeichen oder einer 0 gekennzeichnet. Metadaten zu den Datenfeldern in Form von Überschriften können in der Kopfzeile aufgeführt werden, die beim Einlesen der Daten ignoriert werden kann (vgl. SAP AG, 2005).

Abb. 3.25. CSV und ASCII

74

3 Theoretische Grundlagen des SAP Business Information Warehouse

Das Laden von Daten im ASCII-Format ist performanter als die Verwendung einer CSV-Datei. Eine ASCII-Datei enthält keine Trennzeichen, stattdessen werden die Länge und die Reihenfolge der Datenfelder fest angegeben. Am Ende eines Datensatzes wird ein Carriage Return (CR)-Separator gesetzt, um das Zeilenende kenntlich zu machen (vgl. Mehrwald, 2004). Der Pfad zu flachen Dateien wird erst kurz vor dem Abschluss der Definition des Ladevorganges festgelegt. Der Ladevorgang kann auch automatisiert erfolgen, in diesem Fall kann ein variabler Dateiname vergeben werden (vgl. SAP AG, 2005). Das SAP Business Information Warehouse ist auch in der Lage, an einem Datenaustausch mit einem Web Application Server und dessen Simple Object Access Protocol (SOAP)-Dienst teilzunehmen. Bei einem eingehenden WebRequest versendet der Web Application Server einen Stream im Datenformat XML. Ähnlich der Auszeichnungssprache HTML für Internetseiten ist die Extensible Markup Language eine strukturbeschreibende Metasprache. Sie ist mit dem Ziel entwickelt worden, als universelle Sprache dem Austausch, Auffinden und der Verwaltung semantisch qualifizierter Daten zu dienen (vgl. Arndt, 2002). Wenn regelmäßig kleine Datenmengen automatisiert in das SAP BW über das HTTP und SOAP geladen werden sollen, so kann dies im das XML-Datenformat erfolgen. Dagegen können Hierarchiedaten nicht auf diese Weise übertragen werden. Um Daten im XML-Format in das SAP BW laden zu können, ist eine DataSource notwendig, die von der für flache Dateien abgeleitet wird. Die Struktur der XML-Datei muss der Extraktstruktur dieser DataSource entsprechen. Das SAP BW ist hier allerdings ein passiver Teilnehmer, denn anders als bei den Anbindungstechnologien zuvor geht einer XML-Übertragung keine vom SAP BW veranlasste, sondern eine extern angestoßene Datenanforderung voraus (vgl. SAP AG, 2005). Über eine besondere Form der Schnittstelle, dem Staging-BAPI (Business Application Programming Interface), kann auf Daten aus beliebigen Fremdsystemen zugegriffen werden. Ein Datentransfer erfolgt, indem externe Anwendungen, die über das BAPI mit dem SAP BW kommunizieren, Daten aus dem Quellsystem entnehmen und in das SAP BW übertragen (vgl. SAP AG, 2005). In einem Data Mart Szenario kann das SAP BW als Quellsystem für eine andere SAP BW-Instanz oder das SAP APO, den Advanced Planner and Optimizer, eingesetzt werden. Die Verbindung zwischen den Systemen wird über das Data Mart Interface hergestellt, über welches die Daten vom Quell- in das Zielsystem fortgeschrieben werden. Im Quellsystem wird eine Export-DataSource erstellt, welche eine Struktur für das Extrahieren von Stamm- und Bewegungsdaten enthält. Die Metadaten dieser Export-DataSource werden in die InfoSource des Zielsystems übernommen, in der alle weiteren Schritte zur Fortschreibung in Datenziele vorgenommen werden (vgl. SAP AG, 2005). Basiert das Zielsystem des Data Marts auf einer Lösung eines Drittanbieters, so wird für die Anbindung die InfoSpoke des Open Hub Service verwendet (vgl. SAP AG, 2005).

3.4 Datenbeschaffung

75

Persistent Staging Area In der Datenbeschaffung mit persistenter Datenablage wird für die Kombination eines Quellsystems und einer DataSource eine Persistent Staging Area (PSA) angelegt. In diese Eingangsablage werden Stamm- und Bewegungsdaten entsprechend der Transferstruktur aus dem Quellsystem in relationale Datenbanktabellen des SAP BW geladen (vgl. Mohr, 2002). Auf die Qualität der Daten wird bei diesem Vorgang jedoch nicht Einfluss genommen, die möglichen Änderungen beziehen sich allein auf technische Konvertierungen wie sie etwa beim Datum erforderlich sein können. Die Daten in der PSA sind somit Abbildungen ihrer Quellen mit identischem Verdichtungsgrad. Wird die DataSource verändert, so muss eine neue PSA angelegt werden, da die Struktur der vorhandenen PSA nicht nachträglich angepasst werden kann (vgl. SAP AG, 2005). Wenn der Datenbestand in die PSA geladen wurde, kann er Änderungen und Data Cleaning Operationen unterzogen werden, um die Datenqualität sicherzustellen, bevor eine Schemaintegration ausgeführt wird (vgl. SAP AG, 2000). In der PSA kann man auf einzelne Datensätze über deren Schlüsselfelder zugreifen, um diese technisch auf Vollständigkeit und Fehlerfreiheit zu prüfen und sie bei Bedarf zu bearbeiten, noch bevor sie in die Datenziele fortgeschrieben werden. Eine Änderung kann durch die unmittelbare Bearbeitung der Datenbanktabellen oder durch ABAP-Programme erfolgen, die umfangreichere und wiederkehrende Veränderungen vornehmen (vgl. SAP AG, 2005). Für den Prozess der Datenbeschaffung stehen im Bereich der PSA zwei verschiedene Methoden für die weitere Verbuchung zur Auswahl. Um die Daten möglichst schnell in die Datenziele zu laden, können die einzelnen Datenpakete in Serie oder parallel in die PSA und in die Datenziele fortgeschrieben werden. In der langsameren, aber mit mehr Kontrollmöglichkeiten verbundenen ersten Variante, werden die Daten erst fortgeschrieben, nachdem alle Datenpakete einer Anforderung in die PSA geladen worden sind. Neben den realen Prozessen ist ebenfalls eine Simulation des Vorgangs auf Datenpaketebene möglich. Dies ist besonders im Testbetrieb sinnvoll, wenn neue ABAP-Routinen auf ihre Funktion geprüft werden sollen (vgl. Mehrwald, 2004). Die für die Datenziele des SAP BW bestimmten Daten hält die PSA unterschiedlich lange im Rohzustand. Damit historische Daten in InfoCubes nachgelesen werden können, werden diese Daten länger gehalten als jene, die in ODSObjekte fortgeschrieben werden (vgl. SAP AG, 2005). Erfolgt die Extraktion der Daten unter Verwendung der PSA, wird die Performance des Quellsystems und des SAP BW gesteigert, weil der direkte Ladevorgang ohne gleichzeitige Datenbereinigung schneller erfolgt. Der Datenbestand in der PSA wächst jedoch schnell an, weil die Daten nach dem Laden in die Datenziele nicht sofort gelöscht werden. Deshalb ist eine regelmäßige Pflege des Bestandes unumgänglich (vgl. SAP AG, 2005).

76

3 Theoretische Grundlagen des SAP Business Information Warehouse

Transferstruktur Das Quellsystem stellt für das SAP BW Daten bereit, die in der PSA physisch abgelegt werden. Die Verbindung der beiden Systeme auf der Metaebene erfolgt durch eine DataSource. Sie besteht aus einer flachen Struktur, die eine betriebswirtschaftliche Einheit von Stamm- und Bewegungsdaten beschreibt. DataSources werden für die Extraktion und Übertragung jeglicher Daten aus Quellsystemen in das SAP BW verwendet. In den DataSources wird auch eingestellt, welche Art von Extraktion die Quelle unterstützt. Für alle Datenziele steht das Full-Update zur Verfügung, in diesem Modus werden immer die kompletten Daten einer Quelle zum SAP BW übertragen. Ein Delta-Update eines Datenbestandes über ODS-Objekte erfolgt, indem nur die neuen, geänderten oder gelöschten Datensätze übertragen werden. Beim additiven Delta-Update wird nur die Änderung der Kennzahl eingespielt, nicht die geänderte Kennzahl selbst. Dieses additive DeltaUpdate ist ausschließlich für Kennzahlen möglich, deren Summenbildung zulässig ist, und kann sowohl für InfoCubes als auch für ODS-Objekte eingesetzt werden (vgl. SAP AG, 2005).

Abb. 3.26. Pflegebildschirm DataSource und Transferstruktur

In der Transferstruktur einer DataSource wird festgelegt, welche Datenfelder des Quellsystems an das SAP BW übergeben werden. Die verfügbaren Datenfelder können bereits in einer Quelle durch die Extraktstruktur vorgegeben sein, wenn ein SAP Extraktor eingesetzt wird. Die Vorgabe kann ergänzt oder für die Extraktion um einzelne Datenfelder reduziert werden. Wird kein Extraktor eingesetzt, so werden die Felder für die Zuordnung manuell angelegt (vgl. SAP AG, 2005). Zu einer Transferstruktur wird durch die zu verwendende Transfermethode eine erste

3.4 Datenbeschaffung

77

Datenablage festgelegt. Die Standardeinstellung ist die PSA, jedoch können die Daten auch als IDoc an das SAP BW übertragen und in Datenziele fortgeschrieben werden (vgl. Egger, 2005). Im SAP Business Information Warehouse sind vier verschiedene DataSourceVarianten verfügbar, deren erste bei der Übertragung von Bewegungsdaten verwendet wird. Die anderen werden bei der Extraktion von Stammdaten eingesetzt, je eine ist für Attribute, Texte und Hierarchien zuständig (vgl. SAP AG, 2005). Die Transferstruktur der DataSource steht der InfoSource im Falle einer Weiterverbuchung der Daten in Datenziele des SAP BW zur Verfügung. Sie bezieht sich daher sowohl auf die DataSource für das Quellsystem als auch auf die InfoSource für die Datenziele (vgl. SAP AG, 2005). 3.4.2 Transformation Nach dem Extrahieren der Daten folgt im ETL-Prozess die Transformation. An dieser Stelle werden die in das SAP BW geladenen Daten Maßnahmen zur Qualitätssicherung unterzogen. Die Konsolidierung der Daten kann im SAP BW sowohl in der PSA als auch in der Phase der Übertragung in die Datenziele erfolgen. InfoSource InfoSources werden in einer Anwendungskomponentenhierarchie abgelegt und enthalten all jene Informationen, die für die Übertragung der verfügbaren Daten aus der PSA in die Datenziele benötigt werden. Zu einer InfoSource werden die Einstellungen der DataSource und der Transferstruktur, die Übertragungsregeln und die Kommunikationsstruktur gezählt. Durch Fortschreibungsregeln erfolgt die Verknüpfung der Kommunikationsstruktur einer InfoSource mit den Datenzielen, beispielsweise einem InfoCube. Ein Datenziel kann mit mehreren InfoSources verbunden sein, welchen wiederum jeweils mindestens eine, beim Laden von Hierarchien höchstens eine DataSource zugeordnet wird (vgl. Egger, 2005). InfoSources werden anhand der Alternativen zur Fortschreibung unterschieden. Bei einer InfoSource mit flexibler Fortschreibung können außer den Hierarchien alle Daten unter Verwendung von Fortschreibungsregeln in die Datenziele geladen werden, alle Stammdaten lassen sich hingegen auch ohne Bezug zu expliziten Regeln direkt in die Stammdatentabellen fortschreiben (vgl. SAP AG, 2002a). In der Kommunikationsstruktur einer InfoSource werden die InfoObjects abgelegt, in welche die Daten geladen werden sollen. Diese Struktur ist es auch, auf die sich die Fortschreibungsregeln beziehen. Werden Stammdaten auf flexible Weise fortgeschrieben, so ist es möglich, die übertragenen Daten auf referenzielle Integrität mit den entsprechenden Werten zu überprüfen, die sich in Stammdatentabellen oder in ODS-Objekten befinden (vgl. Nolan, 2003). Als ungültig erkannte Ausprägungen führen zu einem Abbruch des Ladevorganges (vgl. Egger, 2005).

78

3 Theoretische Grundlagen des SAP Business Information Warehouse

Abb. 3.27. Pflegebildschirm InfoSource und Kommunikationsstruktur

Übertragungsregeln Für jedes InfoObject, das in der Kommunikationsstruktur enthalten ist, werden Übertragungsregeln zur semantischen Prüfung des Datenbestandes angelegt. Diese Regeln sind unabhängig von der direkten oder flexiblen Fortschreibung, sie werden in beiden Fällen aktiv. Mit Hilfe der Übertragungsregeln wird festgelegt, auf welche Weise die Daten zu transformieren sind, bevor sie die Kommunikationsstruktur passieren. Die Transformationen sind Teil des Konsolidierungsprozesses, der gemeinsam mit der Schemaintegration dazu dient, die Anforderungen an die Datenqualität zu erfüllen. Obwohl die Übertragungsregeln auch unabhängig von den Objekten der Transferstruktur sein können, beziehen sie sich meist auf diese Struktur. Zum Beispiel werden die Daten aus der PSA durch Übertragungsregeln in ein bezüglich Struktur und Semantik einheitliches Format überführt, bevor man sie an die korrespondierenden InfoObjects in der Kommunikationsstruktur weiterleitet. Fehlerhafte Daten verbleiben zur Korrektur in der PSA. In einem anderen Szenario wird ein InfoObject der Kommunikationsstruktur nicht durch ein entsprechendes Feld in der Transferstruktur befüllt, weil dieses nicht in der DataSource vorhanden ist. Zum Beispiel könnte ein Prognosesystem den Währungstyp für vorhergesagte Umsätze nicht mitliefern. Wenn jedoch bekannt ist, dass die prognostizierten Umsätze in der Währung Euro geführt werden, so kann diese Information verwendet werden, um das InfoObject 0CURRENCY korrekt zu befüllen. Dazu wird

3.4 Datenbeschaffung

79

diesem der konstante Wert EUR im Rahmen der Übertragungsregeln zugewiesen (vgl. SAP AG, 2005).

Abb. 3.28. Pflegebildschirm Übertragungsregeln

Durch verschiedene Methoden zur Übertragung wird bestimmt, welche Daten auf welche Weise aus den Feldern der Transferstruktur einer DataSource in die Kommunikationsstruktur einer InfoSource geladen werden. Wenn die Daten bereits in konsolidierter Form vorliegen und keine Änderungen vorgenommen werden müssen, transferiert die Übertragungsregel die Quelldaten unverändert an die Kommunikationsstruktur. Die simpelste Form der Transformation ist die Zuweisung eines konstanten Wertes zu einem Feld in der Kommunikationsstruktur, so dass auf die Daten der DataSource kein Bezug genommen wird. Wenn der zu übergebende Wert über eine Berechnungsvorschrift ermittelt werden soll, so kann eine Formel eingesetzt werden. Formeln erlauben den Einsatz vordefinierter Funktionen wie zum Beispiel zum Ermitteln des Tagesdatums und können auch mit den Werten aus einer Transferstruktur operieren. Machen die Anforderungen an die Transformation eine komplexere Logik erforderlich, oder sollen Daten aus anderen Datenbanktabellen bezogen werden, so können lokale Konvertierungsroutinen in Form von ABAP-Programmen erstellt werden. 3.4.3 Laden Die letzte Phase im Prozess der Datenbeschaffung ist das Laden der Daten aus der Kommunikationsstruktur der InfoSource in die Datenziele. Hier erfolgt die Transformation des Datenmodells von InfoSource zu InfoProvider. Der Zustand des Ladevorgangs kann über den Monitor geprüft werden.

80

3 Theoretische Grundlagen des SAP Business Information Warehouse

Fortschreibungsregeln Mit Fortschreibungsregeln wird festgelegt, ob und auf welche Art Daten aus der Kommunikationsstruktur einer InfoSource in die Datenziele zu laden sind.

Abb. 3.29. Pflegebildschirm Übertragungsregeln

Die Fortschreibungsregeln werden für die in einem InfoCube enthaltenen Kennzahlen und die jeweiligen Merkmale, Zeitmerkmale und Einheiten sowie für die Daten- und Schlüsselfelder eines ODS-Objektes festgelegt. Sie können auch als Vorlage für Datenziele gleichen Typs verwendet werden und so den Erstellungsaufwand verringern. Für Stammdaten der InfoObjects werden in der Regel keine Fortschreibungsregeln definiert, sie können direkt in die InfoObjects geladen werden. Fortschreibungsregeln werden auch in den Staging-Szenarien eingesetzt. Werden in einem Szenario die konsolidierten Daten zunächst in ODS-Objekten gehalten, ist es mit Fortschreibungsregeln möglich, die Daten in andere Datenziele zu laden (vgl. SAP AG, 2002a). Die Fortschreibungsart tritt in Aktion, wenn die Daten, die in das Datenziel zu laden sind, den gleichen Primärschlüssel aufweisen wie bereits im Datenziel enthaltene Datensätze. Ebenso können in der Kommunikationsstruktur Einträge mit

3.4 Datenbeschaffung

81

identischen Primärschlüsseln auftreten, die auf die gleiche Weise behandelt werden (vgl. SAP AG, 2005). Der Schreibkonflikt kann beim Laden von Kennzahlen auf verschiedene Arten gelöst werden. Es kann generell auf eine Fortschreibung des neuen Wertes verzichtet oder in Abhängigkeit von den Einstellungen die Kennzahl zum vorhandenen Wert addiert oder durch das Maximum bzw. Minimum der beiden Werte ersetzt werden. Bei ODS-Objekten kann nur zwischen Addition oder Überschreiben des alten Wertes gewählt werden, dabei muss darauf geachtet werden, dass einige Datentypen wie Character (CHAR) eine Addition nicht unterstützen. Zudem muss die DataSource die Fähigkeit zur additiven DeltaFortschreibung haben (vgl. SAP AG, 2005). Über die Fortschreibungsmethoden kann festgelegt werden, ob die Werte der Kennzahlen und Merkmale unverändert aus der Quelle übernommen oder modifiziert werden sollen. Diese Methoden treten ebenfalls in Kraft, wenn keine Schlüsselkollision auftritt (vgl. Mehrwald, 2004). Zum einen können die aus der Kommunikationsstruktur bezogenen Daten über Formeln berechnet werden, dabei sind neben arithmetischen und logischen Operationen auch geschachtelte Abfragen und Konvertierungsoperationen mit Hilfe vordefinierter Funktionen möglich. Zum anderen können Konvertierungsroutinen individuell definiert werden, wenn die Komplexität einer Berechnung den Funktionsumfang vordefinierter Formeln übersteigt. Diese Routinen werden selektiv für Kennzahlen und Merkmale in der ABAP-Programmiersprache angelegt und können mehr als nur einen Rückgabewert haben, indem sie eine ganze Tabelle zurückliefern. Eine Überschreibung ist bei der Verwendung von ODS-Objekten mittels Routinen nicht möglich (vgl. SAP AG, 2005). Bei Stammdaten können zusätzlich zu den genannten Methoden auch weitere zum Einsatz kommen, so kann ein Merkmal den initialen Wert beibehalten oder aber einen konstanten Wert zugewiesen bekommen. Ist in der Kommunikationsstruktur ein Attribut eines Merkmals, das in das Datenziel geladen werden soll, nicht enthalten, so kann im SAP BW über die Stammdatentabelle des Attributes der entsprechende Wert nachgelesen werden. Zum Beispiel genügt es, die Produkthauptgruppe zu einer Produktgruppe in den Stammdaten nachzulesen, anstatt sie gemeinsam mit der Produktgruppe aus der DataSource zu übertragen. Werden Kennzahlen mit einer Währungseinheit geführt, so bietet das SAP BW im Rahmen der Fortschreibungsregeln eine Währungsumrechnung an. Diese Funktion ermöglicht eine Umrechnung von der Quellwährung in einer Kommunikationsstruktur in die Zielwährung eines Datenzieles. Die Umrechnung erfolgt durch individuelle Routinen oder in der Administrator Workbench definierte Umrechnungsarten (vgl. SAP AG, 2005).

82

3 Theoretische Grundlagen des SAP Business Information Warehouse

Abb. 3.30. Fortschreibungsregeln für Merkmale

Obwohl die Transformation der Daten in den Übertragungsregeln wie auch in den Fortschreibungsregeln erfolgt, so sind sie dennoch nicht als substituierbar anzusehen. In einem Szenario mit PSA als Eingangsablage, ODS-Objekt als langlebige Datenablage und InfoCube in der Funktion der Reportingablage dienen nur die Übertragungsregeln der Bereinigung des Datenbestandes. Die Fortschreibungsregeln werden auch beim Befüllen des ODS-Objektes verwendet, besonders aber bei der Fortschreibung der Daten aus dem ODS-Objekt in den InfoCube. Dieser kann eine andere Struktur aufweisen als das ODS-Objekt, so dass die Fortschreibungsregeln für die Umformungen beim Laden genutzt werden (vgl. SAP AG, 2005). InfoPackage Der gesamte Vorgang der Datenbeschaffung und -transformation wird in InfoPackages zusammengefasst. Hier werden die zu übertragenden Daten ausgewählt, die Bedingungen für die Datenverarbeitung gesetzt und die Prozesse eingeplant. Ein InfoPackage, in dem etwa für das Laden der Daten aus flachen Dateien die Datenquelle angegeben wird, hat immer Bezug zu einem Quellsystem, einer DataSource und einer InfoSource. Die Anforderung der Daten wird über den Scheduler gestartet (vgl. SAP AG, 2005). In einem InfoPackage kann eine einschränkende Selektion der im Quellsystem vorhandenen Daten erfolgen. Sofern diese beim Anlegen der Transferstruktur als selektierbar markiert worden sind und die DataSource die Selektionskriterien unterstützt, können zum Beispiel nur Daten der Verkaufsregion DK übernommen werden (vgl. Egger, 2005). Neben der Auswahl der zu übertragenden Daten werden die Bedingungen für die Datenverarbeitung gesetzt und die Prozesse eingeplant. In der Verarbeitung kann eine Konsistenzprüfung der Merkmalswerte in den Übertragungsregeln eingestellt werden. Dadurch werden die Werte nach dem Auslesen der Daten aus der PSA oder IDoc auf enthaltene Kleinbuchstaben und Sonderzeichen, auf typgerechte Formate und die korrekte Verwendung der Konvertierungsroutine ALPHA

3.5 Berichtswesen

83

geprüft. Neben der Konsistenzprüfung steht eine Reihe von Verbuchungsmethoden zur Verfügung. Neben den zusammen mit der PSA vorgestellten Optionen wird auch eine direkte Verbuchung in die Datenziele ohne Verwendung der PSA angeboten, diese Methode birgt im Falle eines Fehlschlags jedoch die Gefahr des Datenverlustes. Bei der Verwendung von IDocs ist eine Verbuchung in den ALE-Eingang des SAP BW allein oder eine Weiterverbuchung in das Datenziel möglich (vgl. Egger, 2005). Der Ladeprozess kann sofort gestartet werden, nachdem die Einstellungen getroffen wurden. Außerdem kann ein Batch-Prozess aktiviert werden, der den Ladevorgang im Hintergrund periodisch, zu einem bestimmten Zeitpunkt oder nachdem ein Ereignis aufgetreten ist ausführt (vgl. Egger, 2005). Hinweis: Um den bis hierhin vermittelten theoretischen Inhalt praktisch zu vertiefen, kann an dieser Stelle das Kapitel 4.2.1 Anlegen der InfoSources bearbeitet werden.

3.5 Berichtswesen Die Datenanalyse im SAP BW befindlicher Daten ist sowohl mit Reportingwerkzeugen von Drittanbietern als auch mit SAP-eigenen Tools möglich. Das SAP BW umfasst die Komponente SAP Business Explorer (BEx), die leistungsfähige und flexible Werkzeuge mit Query-, Reporting- und OLAP-Funktionen bereitstellt. Historische und aktuelle Daten können über das Web, MS Excel oder das Unternehmensportal in unterschiedlicher Granularität und aus verschiedenen Perspektiven ausgewertet werden. Im BEx Query Designer werden Queries zu den InfoProvidern definiert. Dazu werden die InfoObjects (Kennzahlen und Merkmale) der InfoProvider ausgewählt, die zur Analyse bereit stehen sollen. Zusätzlich können wieder verwendbare Strukturen erstellt und der Anfrage hinzugefügt werden, hierbei handelt es sich zum Beispiel um eine neue Kennzahl, die mit Hilfe einer Formel berechnet wird. Mittels Sortierung, Filtern sowie dem Austausch von Merkmalen oder der Neuberechnung von Kennzahlen wird eine flexible Navigation im Datenbestand realisiert. Die Daten können in Diagrammen und Grafiken visualisiert und, sofern sie einen geographischen Bezug haben, auf Landkarten dargestellt werden. Die Anwendungen der BEx Suite sind der MS Excel-basierte BEx Analyzer und die BEx Web Applications. Zusammen mit dem formatierten Reporting auf Crystal-Report-Basis sind die Werkzeuge vollständig integriert, alle verwenden im BEx Query Designer erstellte Anfragen. Das Web Application Design der BEx Web Applications ermöglicht es, die Oberfläche des Reporting völlig individuell zu gestalten. Das Exception Reporting ermittelt abweichende und kritische Objekte und benachrichtigt über Ausnahmen auf Wunsch per E-Mail oder SMS.

84

3 Theoretische Grundlagen des SAP Business Information Warehouse

3.5.1 BEx Query Designer Der BEx Query Designer dient der Definition von Anfragen auf die InfoProvider. Diese Anfragen bilden die Basis für alle Präsentationen von Informationen aus dem SAP BW mit dem Business Explorer. Alle definierten Queries können sowohl für das OLAP-Reporting im BEx Analyzer und in BEx Web Applications als auch für das formatierte Reporting verwendet werden (vgl. Egger, 2004).

Abb. 3.31. BEx Query Designer

Die im System gespeicherten Queries sind unmittelbar ausführbar. Wird dagegen eine neue Query erstellt, so muss zunächst ein InfoProvider ausgewählt werden. Anschließend ordnet man die gewünschten Merkmale und Kennzahlen per Drag & Drop in den Zeilen und Spalten einer Tabellenstruktur an, die den Aufbau des Anfrageergebnisses charakterisiert. Zusätzliche Merkmale, die durch Anwenderinteraktion während der Analyse optional hinzugefügt werden können, werden im Bereich Freie Merkmale positioniert. Über Filter können die Werte in den Zeilen und Spalten eingeschränkt werden, es sind aber auch global wirksame Selektionen möglich. Die Anordnung der Kennzahlen und Merkmale definiert die Startsicht einer Query. Durch die Navigation in der Query können verschiedene Sichten auf

3.5 Berichtswesen

85

die in den InfoProvidern gespeicherten Daten generiert werden (vgl. SAP AG, 2005). Bevor die Query in einem Reporting Tool ausgeführt werden kann, ist sie unter Angabe eines technischen Namens und einer Bezeichnung zu sichern. Die Präsentation der Ergebnisse kann z.B. durch Normierung und Sortierung der Merkmale oder durch Anpassen der Zahldarstellung hinsichtlich Dezimalstellen und Skalierungsfaktor vielfältig beeinflusst werden. Kennzahlen und Merkmale im BEx Query Designer Strukturen werden im BEx Query Designer angelegt, um die vorhandenen Merkmale und Kennzahlen dauerhaft anzuordnen sowie neue Elemente individuell zu gestalten und so die Form der Ergebnistabelle vorzugeben. Sie können zu einem InfoProvider abgespeichert und für diesen auch in weiteren Queries wieder verwendet werden. In einer Query können gar keine, eine oder zwei Strukturen angelegt werden, maximal eine davon kann vom Typ Kennzahlenstruktur sein. Jede Kennzahlenstruktur muss mindestens eine Kennzahl enthalten, außerdem gibt es eine Reihe weiterer Möglichkeiten, die Präsentation der Kennzahlen zu beeinflussen (vgl. Egger, 2004). Diese werden nachfolgend beschrieben.

Abb. 3.32. Formel für eine berechnete Kennzahl

Es lassen sich neue Kennzahlen anlegen, die sich bei der Analyse nicht von den physischen Kennzahlen unterscheiden. Sie werden in der Query Definition anhand von Formeln berechnet. Diese Formeln können flexibel in jeder Query erstellt

86

3 Theoretische Grundlagen des SAP Business Information Warehouse

werden, es wird jedoch empfohlen, wieder verwendbare Formeln zu nutzen. Lokale Formeln haben neben dem höheren Aufwand bei der Erstellung den Nachteil, dass inkonsistente Definitionen auftreten können. Außerdem ist es zwingend erforderlich, dass der Anwender genaue Kenntnis vom Datenmodell hat, diese kann aber nicht immer vorausgesetzt werden (vgl. SAP AG, 2005). Kennzahlen können anhand einzelner Merkmalsausprägungen eingeschränkt werden. Diese eingeschränkten Kennzahlen sind Teilmengen der Ursprungskennzahl und treten in der Datenanalyse völlig unabhängig voneinander auf. Durch die Definition von Formeln lassen sich die eingeschränkten Kennzahlen zusätzlich in einen Zusammenhang stellen, ein Beispiel ist etwa die Ermittlung der Differenz zwischen auf die jeweiligen Jahre eingeschränkten Umsatzkennzahlen. Der Anwender kann zudem die Beschreibung, Darstellung (z.B. Hervorhebung und Anzahl Dezimalstellen), Berechnung und Währungsumrechnung für Kennzahlen im BEx Query Designer seinen Bedürfnissen anpassen (vgl. SAP AG, 2005).

Abb. 3.33. Eingeschränkte Kennzahl

Es kann ebenfalls erforderlich sein, Strukturen für Merkmale anzulegen, so dass die Reihenfolge der Merkmale auf einer Achse festgelegt ist. Dabei werden basierend auf den Ausprägungen existierender Merkmale neue Merkmale eingeführt, wobei ein Merkmal Bestandteil nur einer einzigen Struktur sein darf. In Formeln wird beschrieben, wie die Kennzahlen in Bezug auf die neuen Merkmale berech-

3.5 Berichtswesen

87

net und präsentiert werden sollen (vgl. SAP AG, 2005). Über Merkmalsstrukturen lassen sich zum Beispiel die prozentualen Anteile der Umsätze einzelner Produkte am Gesamtumsatz darstellen. Werden innerhalb einer Query mehrere Formeln verwendet, so kann es zu so genannten Formelkollisionen kommen (vgl. SAP AG, 2005). Dies ist unter anderem dann der Fall, wenn etwa die Werte einer Tabelle horizontal durch additive, vertikal aber durch multiplikative Verknüpfung ermittelt werden sollen. Weitere Funktionen des BEx Query Designers Hierarchien können im BEx Query Designer als Anzeigeeigenschaft eingestellt werden. Die Hierarchien werden dann auch als solche in einer Baumstruktur während der Datenanalyse präsentiert, dabei ist es möglich, sowohl in den Spalten als auch in den Zeilen Hierarchien darzustellen. Außerdem können Objekten Dokumente aus Meta-, Stamm- und Bewegungsdaten zugeordnet werden, die dann bei der Ausführung der Query als Links dargestellt werden und zu denen per Mausklick direkt navigiert werden kann (vgl. SAP AG, 2005). Bedingungen in Anfragen dienen zur Einschränkung des Ergebnisraums. Pro Anfrage können mehrere Bedingungen definiert werden, diese werden dann logisch durch Und-Operatoren verknüpft. Die Bedingungen können in absolute Bedingungen und Ranglisten unterteilt werden. Absolute Bedingungen filtern Zeilen aus der Tabelle, wenn bestimmte Einschränkungen hinsichtlich des Bezugswertes gelten. Diese Einschränkungen können sein (vgl. Egger, 2004): • • • •

gleich / ungleich kleiner / größer kleiner gleich / größer gleich innerhalb / außerhalb

Ranglisten werden stets sortiert präsentiert, die Position in der Liste entscheidet, ob eine Zeile im Ergebnis präsentiert wird. Zur Erstellung von Ranglisten stehen folgende Operatoren zur Verfügung (vgl. Egger, 2004): • Top N / Bottom N: es werden die obersten / untersten N Zeilen angezeigt • Top % / Bottom %: es werden die obersten / untersten % Zeilen angezeigt • Top Summe / Bottom Summe: Alle Zeilen oberhalb / unterhalb einer bestimmten Summe werden angezeigt In Ausnahmezellen können die durch Bedingungen und Selektionen vorgegebenen Zellinhalte überschrieben werden. Voraussetzung ist, dass die Query zwei Strukturen enthält. Den Kreuzungspunkten von Strukturelementen werden dann explizite Zellinhalte zugewiesen (vgl. SAP AG, 2002a). Ausnahmezustände, d. h. Daten, die von vorgegebenen Schwellwerten abweichen, können in Queries mittels farbiger Kennzeichnung optisch hervorgehoben werden. Dieses so genannte Exception Reporting bildet die Grundlage für Alerts, durch das Setzen von Ober- und Untergrenzen werden verschiedene Alert Level definiert. Die Exceptions werden später online während der Analyse im BEx Web

88

3 Theoretische Grundlagen des SAP Business Information Warehouse

Applications oder im BEx Analyzer ausgewertet. Im Reporting Agent der Administrator Workbench definierte Einstellungen werden im Hintergrund ausgewertet und im Exception Log protokolliert (vgl. SAP AG, 2005). Eine Parametrisierung der Anfragen ist empfehlenswert, um die Datenmenge bereits beim Starten der Query auf die tatsächlich benötigten Informationen zu beschränken. Eine zentrale Rolle bei der Querydefinition nehmen die Variablen ein, sie fungieren als Platzhalter, die bei Ausführung auf verschiedene Art und Weise mit Werten befüllt werden können. Es sind folgende Variablentypen implementiert (vgl. Egger, 2004): • Merkmalswertvariablen repräsentieren Merkmalswerte, so kann zum Beispiel bei Durchführung eines Vorjahresvergleichs das aktuelle Jahr als Variable hinterlegt und beim Ausführen der Query abgefragt werden. Das Vorjahr kann nun berechnet werden, indem man ein Jahr von der Variablen subtrahiert. • Hierarchievariablen dienen der Auswahl von Teilbäumen einer Hierarchie beim Start der Query. • Textvariablen ermöglichen eine dynamische Benennung von Merkmalswerten unter Verwendung von Schlüsselwerten und Stammdatentexten. Zusätzlich kann gewählt werden, ob Schlüssel, Text oder Schlüssel und Text darzustellen sind. • Formelvariablen repräsentieren Zahlenwerte und können damit als Variablen für Kennzahlen eingesetzt werden. Verwendet werden sie unter anderem im Exception Reporting zur Definition variabler Schwellwerte der einzelnen Exception Level. Verarbeitungsarten legen fest, wie die Variablen zur Laufzeit mit Werten gefüllt werden. Diese Verarbeitungsarten sind möglich (vgl. Egger, 2004): • Manuelle Eingabe / Vorschlagswert steht für jeden Variablentyp zur Verfügung. Der gewünschte Wert kann manuell eingegeben oder ein in der Variablendefinition vorgegebener Vorschlagswert verwendet werden. • Der Ersetzungspfad definiert, durch welchen Wert die Variable beim Start der Anfrage automatisch ersetzt wird, und kann für Merkmalswert-, Text- und Formelvariablen ausgewählt werden. • Customer-Exit steht für alle Variablentypen zur Verfügung und enthält eine anwenderspezifische Programmlogik zur Verarbeitung. • SAP-Exit ist nur für Objekte des Business Contents wählbar. • Bei der Verarbeitungsart Berechtigung werden die Variablen mit Werten aus der Berechtigung des Benutzers befüllt, sie kann für Merkmalswert- und Hierarchievariablen eingesetzt werden. Die Query kann aus dem BEx Query Designer heraus in einer tabellarischen Darstellung angezeigt werden. Es werden stets Präsentationen für beide Modi erzeugt, lediglich Anfragen mit zwei Strukturen können ausschließlich im standardmäßigen OLAP-Reporting ausgeführt werden. Im Gegensatz zum OLAP-Reporting gibt es in der tabellarischen Darstellung keine freien Merkmale, außerdem können die Merkmale und Kennzahlen ausschließlich in der Kopfzeile angeordnet werden,

3.5 Berichtswesen

89

so dass die Summenbildung lediglich je Spalte erfolgt. Der Aufbau der Tabelle ist nicht durch Navigationsoptionen wie dem Hinzufügen oder Entfernen eines Aufrisses konfigurierbar, es können während der Datenanalyse lediglich Filter gesetzt werden (vgl. Egger, 2004). Hinweis: Um den bis hierhin vermittelten theoretischen Inhalt praktisch zu vertiefen, kann an dieser Stelle das Kapitel 4.3.1 Anlegen der Query bearbeitet werden.

3.5.2 BEx Analyzer Der BEx Analyzer ist derjenige Bestandteil der SAP Business Explorer Suite, der für die Einbindung von Queries unter MS Excel zuständig ist. Es handelt sich um ein SAP BW Add-On, das MS Excel um eine SAP BW-spezifische Symbolleiste zur Selektion und Ausführung von Anfragen sowie um das Öffnen von Queries enthaltenden Arbeitsmappen ergänzt (vgl. McDonald et al., 2002). Über die Symbolleiste können Queries in Arbeitsmappen hinzugefügt und diese Sichten auf einem Datenträger gespeichert werden. Außerdem können Queries aufgefrischt werden, das bedeutet, dass vom SAP BW Server aktuelle Daten angefordert und angezeigt werden. Diese Funktion wird bei jeder Navigationsoperation oder Änderung von Einstellungen automatisch ausgeführt, kann bei Bedarf aber auch manuell gestartet werden. Über die Funktion Springen sind gespeicherte Query Sichten sowie Exceptions schnell erreichbar, für zur Query gehörende Zellen können außerdem über das Kontextmenü OLAP Funktionen wie etwa das Setzen von Filterwerten aufgerufen werden. Der Anwender kann in der Formatierung zum Beispiel Farben und Schriftarten verändern und im Layout Grafiken wie Diagramme und Landkarten einbinden, so dass das Erscheinungsbild der Query im BEx Analyzer an seine Bedürfnisse angepasst wird. Die Symbolleiste gewährleistet ebenfalls einen schnellen Zugriff auf die Standardsicht von Queries im Webbrowser und den BEx Query Designer (vgl. SAP AG, 2005).

90

3 Theoretische Grundlagen des SAP Business Information Warehouse

Abb. 3.34. BEx Analyzer

Hinweis: Um den bis hierhin vermittelten theoretischen Inhalt praktisch zu vertiefen, kann an dieser Stelle das Kapitel 4.3.2 Reporting mit dem BEx Analyzer unter MS Excel bearbeitet werden.

3.5.3 Web-basiertes Berichtswesen Bevor es möglich war, Queries über einen Webbrowser zu betrachten, wurde der BEx Analyzer in der MS Excel-Umgebung für Analysen auf dem Datenbestand verwendet. Da dieser nur über eine begrenzte Funktionalität verfügt, wurde das Web Reporting eingeführt. Eine Web Application ist eine Anwendung zur Ausführung von Queries, die auf einem Web Application Server abgelegt wird und über das Enterpriseportal im SAP System oder Intranet des Unternehmens erreichbar ist (vgl. Alexander, 2003). Die Auswertungen der Queries können auch in SAP-Rollen hinterlegt und aus dem Rollenmenü aufgerufen werden (vgl. SAP AG, 2005).

3.5 Berichtswesen

91

Abb. 3.35. Web Application

Die Ergebnisdarstellung sowie die Interaktion mit der Anwendung erfolgen über einen Webbrowser, der online durch eine in der URL formulierte HTTP-Anfrage mit dem Web Application Server kommuniziert. Dieser verarbeitet die HTTPAnfrage, indem er aus einem Template-Objekt eine HTML-Seite ableitet und erst Data Provider und dann Web Items erzeugt, die sich auf genau einen Data Provider beziehen (vgl. Leslie und Mayer, 2003). Sollten die Sicht auf die Daten durch den Anwender, die dargestellten Daten selbst oder Attribute während der Ausführung der Analyse verändert worden sein, so wird die Seite neu geladen und die in ihr enthaltenen Web Items werden vom System neu erzeugt (vgl. SAP AG, 2005). Ein fester Bestandteil der SAP Business Explorer Suite ist das Werkzeug zur Erstellung von Berichten, die auf einem Web Application Server bereitgestellt werden. Diese kann der Anwender über einen Standard Webbrowser aufrufen, der das Ergebnis einer Query in Abhängigkeit von der erstellten Web Seite auf verschiedene Arten dargestellt. Durch verschiedene Funktionen zur Navigation und zur Anpassung der Query-Sicht kann die Ergebnisdarstellung aktiv beeinflusst werden. Die Änderungen werden nach dem Auffrischen der Web Seite sofort wirksam (vgl. SAP AG, 2005). Die Funktionalität einer Web Application hängt dabei vom verwendeten Webbrowser ab. Sofern dieser die Mindestanforderungen an die Interpretationsfähigkeiten von z.B. HTML 4.0, DOM Stufe 2 und CSS 1.0 unterstützt, ist die Ergebnisdarstellung und die Funktionalität vergleichbar mit den Referenz-Webbrowsern MS Internet Explorer 6.x und Netscape Navigator 6.x (vgl. SAP AG, 2005).

92

3 Theoretische Grundlagen des SAP Business Information Warehouse

Standard Web Application Das Grundobjekt einer Web Application ist eine Datei im HTML-Format. Darin sind sowohl statische Elemente als auch dynamische Objekte enthalten, die der Anzeige von Inhalten und der Interaktion mit dem Benutzer dienen. Die Objekte werden als Web Items bezeichnet und stellen zum Beispiel Tabellen oder Diagramme dar. Die Daten werden basierend auf der Query aus den InfoProvidern bezogen, von den Web Items verarbeitet und in Form von HTML-Code an die Web Application geliefert. Die Formatierung wird über Cascading Style Sheets (CSS) und Attribute bestimmt, die über den BEx Web Application Designer gepflegt werden. Die im Web Template enthaltenen Web Items stellen über das Kontextmenü verschiedene Funktionen bereit, die etwa eine Navigation im Datenbestand erlauben (vgl. Egger, 2004). In Form des Standard Web Templates wird bereits eine strukturierte HTMLDatei mit dem BEx ausgeliefert. Sie wird verwendet, wenn das Ergebnis einer Query aus dem BEx Query Designer heraus im Webbrowser angezeigt werden soll, um einen ersten Eindruck des Query-Verhaltens zu gewinnen. Das Standard Web Template bietet bereits eine Reihe von OLAP Operationen sowie Funktionen zur Darstellung der Ergebnisse an. Es ist aus der Titelleiste mit dem Namen der Query, der Symbolleiste, dem generischen Navigationsblock und der Tabelle aufgebaut (vgl. Egger, 2004). Web Items der Symbolleiste Die Symbolleiste des Standard Web Template ermöglicht es, verschiedene Funktionen auszuführen, welche die Ansicht der Resultate, Informationen und Einstellungen zur Query sowie Methoden für den Export des Inhalts in eine Datei umfassen.

Abb. 3.36. Web Items der Symbolleiste

Tabelle Eines der grundlegenden Web Items ist die Ergebnistabelle, die das Resultat einer Query in einer zweidimensionalen Zellstruktur abbildet. Diese enthält in Zeilen und Spalten entsprechend der Query-Definition Merkmale und Kennzahlen, die in der Tabelle individuell angeordnet, entfernt und um freie Merkmale oder Kennzahlen ergänzt werden können. Je nach Anzahl der abzubildenden Merkmale und Kennzahlen kann der Tabellenkopf mehrere Zeilen oder Spalten umfassen.

3.5 Berichtswesen

93

Abb. 3.37. Ergebnistabelle einer Query in MS Excel

Für jede Merkmalskombination wird eine Zwischensumme der Kennzahlen erstellt und farblich abgesetzt. Am Ende einer jeden Zeile und Spalte werden die Gesamtsummen gebildet. Sind für eine Merkmalskombination keine Kennzahlen verfügbar, so bleibt die betroffene Zelle leer. Anhand der Tabelle können die OLAP-Operationen einfach nachvollzogen werden, da eine Änderung der Sicht über den Navigationsblock oder Funktionen des Kontextmenüs sich unmittelbar auf die Tabellenstruktur auswirkt. Diagramme In Diagrammen werden Informationen zu einer Kennzahl in grafischer Form ausgegeben. Der BEx stellt eine Vielzahl verschiedener Diagrammtypen zur Verfügung, für die eine bestimmte Sicht auf die Daten erforderlich ist, um eine sinnvolle Darstellung der Informationen zu gewährleisten. Werden die Informationen nicht wie gewünscht abgebildet, kann die Sicht auf den Datenbestand zum Beispiel über die Funktion Achsen vertauschen verändert werden. Je nach Diagrammtyp werden unterschiedliche Datentabellen als Grundlage herangezogen (vgl. SAP AG, 2005). Der erste Diagrammtyp erwartet in den Spalten die Ausprägung eines Merkmals, während in den Zeilen die Kennzahlen zu den Merkmalsausprägungen enthalten sein müssen. Zu diesem Typ zählen die meisten der Diagramme wie das Säulen-, Linien- und Kreisdiagramm. Allerdings sind nicht alle Diagramme an die empfohlene Struktur gebunden, unter Umständen können auch Merkmalsausprägungen in den Zeilen verständlich dargestellt werden. • Das Säulendiagramm eignet sich dazu, die Kennzahlen zu einzelnen Merkmalsausprägungen miteinander zu vergleichen. Besonders zeitliche Entwicklungen können geeignet abgebildet werden. Die Werte werden auf der Ordinate abgetragen, während sich die Ausprägungen in Form von Kategorien auf der Horizontalen befinden. Werden in die Zeilen ebenfalls Merkmale aufgenommen, so sind die Säulen zusätzlich vertikal jeweils farblich unterteilt. Bei einem Balkendiagramm werden die Dimensionen genau gegensätzlich angeordnet, wodurch ein Vergleich der Werte stärker in den Vordergrund rückt. Säulen- und Balkendiagramme können alternativ dreidimensional dargestellt

94

3 Theoretische Grundlagen des SAP Business Information Warehouse

werden, so dass Merkmalsausprägungen nicht vertikal innerhalb der Säulen bzw. horizontal innerhalb der Balken, sondern auf einer zusätzlichen Achse unterschieden werden.

Abb. 3.38. Säulendiagramm

• Im Liniendiagramm werden die Datenpunkte durch eine Linie miteinander verbunden. Es eignet sich ebenso wie das Säulendiagramm dazu, Trends abzubilden. Eine Linie steht für eine Merkmalsausprägung der Spalte, während in den Zeilen befindliche Merkmale auf der Abszisse abgetragen werden. Die Werte einer Kennzahl werden wie beim Säulendiagramm vertikal angeordnet. Das Profildiagramm verhält sich zum Liniendiagramm wie das Balken- zum Säulendiagramm.

Abb. 3.39. Liniendiagramm

3.5 Berichtswesen

95

• Das Kreisdiagramm, das auch Tortendiagramm genannt wird, ist ein Vertreter des an Merkmalsausprägungen gebundenen Diagrammtyps. Befinden sich Merkmalsausprägungen sowohl in den Zeilen als auch in den Spalten, findet sich lediglich die erste Zeile der Ergebnistabelle im Diagramm wieder. Kreisdiagramme sind besonders dazu geeignet, die Anteile einzelner Kategorien an der Gesamtsumme bezüglich einer einzigen relevanten Ausprägung in Sektoren abzubilden. Das mit dem Kreisdiagramm verwandte Ringdiagramm ist hingegen in der Lage, mehrere Datenzeilen darzustellen, indem sie jeweils einem Ring zugeordnet werden.

Abb. 3.40. Kreisdiagramm

Zum zweiten Diagrammtyp gehören das Punkt- und Zeitpunktdiagramm sowie das Histogramm. Die Merkmalsausprägungen werden für die einzelnen Zeilen in der ersten Spalte hinterlegt, während die Kennzahlen in den folgenden eingetragen sind. Die erste Datenspalte bildet die X-Achse, während die nachfolgenden Kennzahlen auf der Ordinate abgetragen werden. • Das Punktdiagramm bildet entsprechend der zugrunde liegenden Datentabelle die Tupel als Punkte in einem Koordinatensystem ab. Die Tupel sind aus der ersten Datenspalte und einer der nachfolgenden Spalten aufgebaut. In der Variante Zeitpunktdiagramm kann der Datentyp der ersten Datenspalte ein Datum oder eine Uhrzeit sein. • Das Histogramm interpretiert die Daten anders als das Punktdiagramm. Die erste Datenspalte hat hier eine Schlüsselfunktion, die einen Datensatz identifiziert. Im Diagramm werden die Häufigkeiten der Datensätze nach Intervall in einer Säule je Intervall abgebildet. Der letzte Diagrammtyp wird durch das Portfoliodiagramm gebildet. Dieses ist zweidimensional und besteht aus vier Quadranten. In diese Matrix werden die

96

3 Theoretische Grundlagen des SAP Business Information Warehouse

Werte der ersten und zweiten Datenspalte eingetragen und als Kreis abgebildet. Der Kreisradius ergibt sich aus der dritten Datenspalte. Die Quadranten dienen dazu, die Datenpunkte anhand ihrer Position zu bewerten. Infos Über das Symbol Infos werden die zur Query verfügbaren Informationen im Browserfenster ausgegeben. Die Metadaten betreffen das Datum des Stichtages, die Aktualität der Daten und der Query sowie den Namen des Anwenders, der die letzte Änderung vorgenommen hat. Außerdem werden die in der Query angewandten Filtereinstellungen sowie die Werte der verwendeten Variablen ausgegeben. Exceptions Das Exception Reporting wird dazu verwendet, um die Abweichung kritischer Werte optisch kenntlich zu machen. Dies ist in der Ergebnistabelle, aber auch in Diagrammen und auf Landkarten möglich. Der durch den Webbrowser dargestellte Pflegebildschirm enthält eine Liste von Exceptions mit ihrem aktuellen Status, der angibt, ob sie verwendet werden oder inaktiv sind. Im Pflegebildschirm können neue Exceptions definiert und vorhandene bearbeitet werden. Neben einer Beschreibung werden für die zu prüfende Kennzahl Intervalle oder Schwellwerte für gute, kritische und schlechte Exception Levels festgelegt. Diese wirken sich auf die farbliche Hervorhebung der betroffenen Zellen in der Ergebnistabelle aus, für deren Darstellung die Farbtöne rot, gelb und grün in jeweils drei Abstufungen angeboten werden. Außerdem können die Merkmale und ihre Ausprägung bestimmt werden, für deren Kombination eine Prüfung der betroffenen Kennzahl gewünscht ist. Die aufgetretenen Ausnahmen werden durch den Reporting Agent protokolliert, der gegebenenfalls eine Aktion auslöst (vgl. SAP AG, 2005).

3.5 Berichtswesen

97

Abb. 3.41. Pflegebildschirm Exceptions

Bedingungen Wenn die Datenprovider einer Query viele Daten enthalten, so kann das Ergebnis der Auswertung schnell unübersichtlich werden. Ist für den Betrachter nicht die gesamte Datenmenge von Interesse, so kann sie durch Bedingungen eingeschränkt werden. Die Einschränkung der Sicht ist dabei rein optisch, so dass also die Zwischen- und Gesamtsummen konsistent bleiben, auch wenn einige Kennzahlen nicht aufgeführt werden. Dabei hängt es von jedem der am Aufriss beteiligten Merkmale ab, ob eine Bedingung erfüllt wird. Wird die Bedingung für eines der in der Selektion verwendeten Merkmale nicht erfüllt, so wird der Wert nicht angezeigt, auch wenn andere Merkmale im Aufriss für sich genommen nicht von der Einschränkung betroffen sind (vgl. Egger, 2004).

98

3 Theoretische Grundlagen des SAP Business Information Warehouse

Abb. 3.42. Definition von Bedingungen

In einer Query kann eine Mehrzahl Bedingungen angelegt und aktiv sein. Das Resultat bildet die Schnittmenge aus allen aktiven Bedingungen. Für Bedingungen stehen unterschiedliche Optionen zur Verfügung, um die Werte einzuschränken. Schwellwerte beschreiben eine Grenze, die festlegt, bis zu oder ab welchem Wert die Kennzahlen angezeigt werden. Die Liste der Bedingungen und ihr aktueller Aktionszustand werden im Pflegebildschirm tabellarisch abgebildet. Alle vorhandenen Bedingungen können gepflegt und neue angelegt werden (vgl. Egger, 2004). Ranglisten zeigen nur eine bestimmte Anzahl Elemente an, die abhängig sein kann vom Verhältnis zur Zwischen- oder Gesamtsumme. Eine Rangliste kann zum Beispiel die ersten oder letzten fünf Elemente enthalten. Es kann aber auch vom Anteil am Summenwert abhängig gemacht werden, ob die Daten darzustellen sind (vgl. SAP AG, 2005). Bedingungen sind nicht immer anwendbar. Dies kann der Fall sein, wenn das Merkmal, für das eine Bedingung gültig ist, sich nicht im Aufriss befindet oder aber die selektierten Merkmale sich nicht auf einer Achse befinden. Wird ein Merkmal in einer anderen Bedingung verwendet, so kommt es bei simultaner Anwendung der Bedingungen zu einer Kollision. Es können nicht gleichzeitig beide Bedingungen verwendet werden (vgl. SAP AG, 2005). Variableneingabe Wenn in der Querydefinition Variablen angelegt worden sind, so können diese automatisch oder durch Interaktion mit dem Anwender belegt werden. Über das

3.5 Berichtswesen

99

Variablenbild können die Variablen gesetzt werden, wenn die Web Application im Browser gezeigt wird (vgl. SAP AG, 2005). Ad hoc-Query Designer Eine Querydefinition kann nicht nur mit Hilfe des BEx Query Designers in der BEx Suite gepflegt werden, sondern auch über den Ad hoc-Query Designer. Er wird über die Oberfläche des Webbrowsers bedient und verfügt über eine begrenzte Funktionalität im Vergleich zum Desktop-Pendant. Es können zwar neue Queries angelegt und vorhandene bearbeitet werden, eine Einbindung von Variablen in die Query ist jedoch ebenso wenig möglich wie das Anlegen wieder verwendbarer Strukturen, wieder verwendbarer eingeschränkter oder berechneter Kennzahlen und lokal berechneter Kennzahlen. Die Anzahl bereits vorhandener Strukturen in einer Query, die mit dem Ad hoc-Query Designer bearbeitet werden kann, ist auf eins begrenzt (vgl. SAP AG, 2005).

Abb. 3.43. Ad hoc-Query Designer

Bookmark und Export Wenn der Navigationszustand einer Auswertung beim Aufruf der Query wiederhergestellt werden soll, so kann über die Bookmark Funktion der Symbolleiste eine spezielle, speicherbare URL erzeugt und aus der Adresszeile des Webbrowsers kopiert werden. Ein Bookmark erwartet jedoch, dass die Web Items im Template nicht zwischenzeitlich umbenannt oder entfernt wurden, da sonst eine Zuordnung nicht mehr möglich ist. Ebenso werden neu hinzugefügte Web Items nicht darge-

100

3 Theoretische Grundlagen des SAP Business Information Warehouse

stellt, weil die entsprechenden Verweise fehlen. Neben dem Navigationszustand können beim Setzen eines Bookmarks auch die zum Zeitpunkt der Analyse vorhandenen Daten mitgespeichert werden. Diese Funktion muss jedoch im Kontextmenü durch den BEx Web Application Designer frei geschaltet werden (vgl. SAP AG, 2005). Die Ansicht einer Auswertung kann im MS Excel-Arbeitsmappen Format oder als CSV-Datei gespeichert werden. Dabei werden keine OLAP-Funktionen oder Diagramme in die Dateien übertragen, sondern nur die Sicht und die Datentabelle. Die CSV-Datei enthält nur die Datentabelle, der Filterinformationen und Formatierung gänzlich fehlen. Kontextmenü Einigen Web Items wie zum Beispiel Tabellen und Diagrammen wird ein Kontextmenü zur Verfügung gestellt, welches durch einen Linksklick in das Objekt aufgerufen wird. Das Menü ist an die Objekte angepasst und bietet verschiedene Funktionen, so können zum Beispiel der letzte oder alle getätigten Navigationsschritte rückgängig gemacht werden. Die Anzahl der Menüeinträge wird durch die Funktion Erweitertes Menü vergrößert, kann zur besseren Übersicht aber auch wieder verringert werden (vgl. SAP AG, 2005).

Abb. 3.44. Kontextmenü

Einige Web Items wie der Navigationsblock und die Tabelle erlauben das Anlegen von Filterwerten für Merkmale und anschließenden Aufriss nach ihnen. Die Merkmale können dabei aus Gründen der Verständlichkeit entweder in der Tabelle verbleiben oder aus der Tabellenansicht entfernt werden. Die Aufrissfunktionen sind mit denen des Navigationsblocks vergleichbar. Das Navigationsmenü bietet eine menübasierte Auswahl der Merkmale, die auf Zeilen oder Spalten angeordnet werden können. Anders als der Navigationsblock beziehen sich Aufrisse auf den aktuellen Aufbau der Sicht. Die Operationen können auf ein vorhandenes Merkmal bezogen werden, wodurch man dieses gezielt entfernen oder es durch andere ersetzen, aber auch die Position des neu anzufügenden Merkmals genau festlegen kann.

3.5 Berichtswesen

101

Ein Aufriss kann mit dem Setzen eines Filters kombiniert werden, es ist ebenfalls möglich, die Achsen der Tabelle vertauscht anzuordnen (vgl. SAP AG, 2005). Für den Umgang mit Hierarchien stehen die Funktionen zum Aufklappen und Schließen einer Hierarchie sowie eines einzelnen Hierarchieknotens zur Verfügung. Außerdem wird der Aufriss in einer Hierarchie nach einem neuen Merkmal ermöglicht. Neben den Hierarchiefunktionen und dem Aufriss sind im Kontextmenü die Einstellung der Sortierreihenfolge oder das pivotisierte Sortieren nach einem Merkmal möglich. Außerdem kann die Berechnung der Zwischen- und Gesamtsumme beeinflusst werden, anstatt einer Summe kann zum Beispiel der Durchschnitt berechnet oder das Maximum bestimmt werden. Ebenso kann man die Berechnung der Einzelwerte verändern, indem etwa eine Normierung auf die Einzelwerte durchgeführt wird. Die Währungsumrechnung ermöglicht es, in der Query die Bezugswährung zu verändern, ohne die Daten der InfoProvider zu beeinflussen. Dadurch kann die Währung schnell den Bedürfnissen des Anwenders angepasst werden (vgl. SAP AG, 2005). Das Kontextmenü der Bookmark Funktion verfügt auch über eine Erweiterung zur Speicherung der Daten. So wird nicht nur der Navigationszustand, sondern auch der Datenbestand gesichert und kann über eine URL aufgerufen werden. Neben dem Bookmark ist auch der Export zur MS Excel Arbeitsmappe oder CSVDatei möglich (vgl. SAP AG, 2005). Wird das Kontextmenü auf einer Kennzahl ausgeführt, so ist der Eintrag Kennzahldefinition enthalten. Darüber können die Metadaten abgerufen werden, um die Herkunft und die Zusammensetzung einer Kennzahl nachvollziehen zu können. Neben dem Standard-Kontextmenü kann auch ein spezielles Menü für die Navigation in Hierarchien eines Merkmals verfügbar sein. Die Einträge des Menüs stellen die Hierarchieknoten dar, entsprechend denen auch Filter aus dem Menü heraus gesetzt werden können (vgl. SAP AG, 2005). Generischer Navigationsblock Im Standard Web Template werden außer den über die Symbolleiste zugänglichen Web Items noch weitere verwendet. Um die Sicht auf die Daten einer Query dynamisch aus der Anzeige heraus zu verändern, kann der generische Navigationsblock verwendet werden. In einer Tabellenstruktur werden alle in der Query verwendeten Merkmale, dynamische Filterwerte und Kennzahlen sowie der Navigationszustand dargestellt. Die Veränderungen können mit Hilfe von Schaltflächen zur Anordnung von Merkmalen, Strukturen und Kennzahlen in Zeilen und Spalten sowie zur Auswahl von Filterwerten erfolgen und im Navigationsblock angezeigt werden. Aufgrund der klaren Strukturierung der Informationen lässt sich der aktuelle Navigationszustand leicht ablesen (vgl. SAP AG, 2005).

102

3 Theoretische Grundlagen des SAP Business Information Warehouse

Abb. 3.45. Generischer Navigationsblock

Label Über das Label werden sprachabhängige Bezeichnungen zu einem Web Item und den referenzierten Merkmalen, Strukturen und Attributen dargestellt und mit einem Link versehen. Dieser Link erlaubt während der Ausführung einer Query den Aufruf eines Pflege-Popups oder eines auf den Inhalt angepassten Kontextmenüs (vgl. Egger, 2004). Gruppierung Zur gruppierten Darstellung einer endlichen Menge von Optionen werden Dropdownboxen, Radio Button-Gruppen und Checkboxen verwendet. Sie verhalten sich identisch wie die im SAPgui verwendeten Objekte gleichen Namens und treten im Standard Web Template häufig in Pflegedialogen zu anderen Web Items auf. Dropdownboxen werden oft mit Merkmalswerten befüllt, um die Sicht nach einem der enthaltenen Werte zu filtern. Die Radio Button Group empfiehlt sich bei einer geringen Anzahl einander ausschließender Optionen, während die Checkbox die unbeschränkte Auswahl von Merkmalen ermöglicht (vgl. Egger, 2004). Hinweis: Um den bis hierhin vermittelten theoretischen Inhalt praktisch zu vertiefen, kann an dieser Stelle das Kapitel 4.3.3 Ad hoc – Reporting im Webbrowser bearbeitet werden.

3.5.4 BEx Web Application Designer Der BEx Web Application Designer dient dem Anwender als Werkzeug, um HTML-Seiten vom PC-Desktop aus für die Informationspräsentation zu erstellen, zu bearbeiten und im BW abzuspeichern. Er ermöglicht die Entwicklung einer Web Applikation ohne die Notwendigkeit, sich mit dem Quellcode einer Seite oder mit dem System im Detail befassen zu müssen. Der HTML-Quellcode kann auch exportiert oder importiert werden, um eine verteilte Entwicklung zu unterstützen. Durch den BEx Web Application Designer wird der Bedarf nach einem Werkzeug für die Erstellung individueller Reports für umfangreiche Szenarien wie eine ins Unternehmensportal integrierte Reporting Platform oder Business Intelligence Cockpits befriedigt. Die Reports können an die Corporate Identity des

3.5 Berichtswesen

103

Unternehmens angepasst werden, um ein einheitliches Layout der Berichte sicherzustellen. Der BEx Web Application Designer bietet den Funktionsumfang eines einfachen HTML-Editors. Neben dem Einfügen von Texten und Bildern ermöglicht er die Konstruktion einer Tabelle, welche das Grundgerüst eines Web Templates bildet. Zu einer aufwändigen grafischen Gestaltung einer Web Seite ist dieses Werkzeug nicht geeignet, dies ist allerdings auch nicht seine Hauptaufgabe und kann durch die Import- und Exportfunktion mit Werkzeugen anderer Anbieter realisiert werden. Der Schwerpunkt des BEx Web Application Designers liegt auf der Einbindung und Definition von Web Items in Web Templates.

Abb. 3.46. BEx Web Application Designer

Für die Formatierung der Web Templates und ihrer Objekte werden im BEx Web Application Designer Cascading Stylesheets (CSS) verwendet. Sie bieten umfangreichere Formatierungsbefehle als HTML allein. Das SAP BW stellt bereits eine gewisse Anzahl vorgefertigter Stylesheets zur Verfügung, mit denen das Schriftbild und die farbliche Gestaltung der Objekte beeinflusst werden. Um eine individuelle Darstellung zu erreichen, können eigene Stylesheets in das System geladen werden. Spezielle Druck-Stylesheets passen die Ausgabe an die Anforderungen einer druckbaren Version an, falls das Layout der im Webbrowser gezeigten Version etwa aufgrund der Schriftgröße nicht für einen Ausdruck geeignet ist (vgl. SAP AG, 2005). Um das Darstellungsverhalten, den Inhalt oder die Navigationsfunktionen der Tabelle oder des Navigationsblocks weitgehender zu verändern, als es mit den

104

3 Theoretische Grundlagen des SAP Business Information Warehouse

Standard-Eigenschaften der Objekte möglich ist, kann eine ABAP-Klasse geschrieben werden. Dafür stellt das BW ein Web Design API für Tabellen zur Verfügung (vgl. SAP AG, 2005). Der Web Application Wizard ist ein in das Werkzeug integrierter Assistent, der dem Anwender die Einbindung eines Web Items erleichtert. In einer Reihe von aufeinander abgestimmten Dialogbildschirmen werden die Eigenschaften eines Web Items festgelegt, zu denen auch die Query und der verknüpfte InfoProvider gehören (vgl. SAP AG, 2005). Web Templates Die SAP Business Explorer Suite wird mit einem Standard Web Template ausgeliefert, welches in einem Webbrowser dargestellt wird. Es kann als Grundlage für individuelle Entwicklungen verwendet und erweitert werden. Das Standard Web Template verfügt bereits über mehr Funktionen, als der BEx Analyzer aufweisen kann. Die Struktur einer Web Seite wird in ihrem HTML-Code hinterlegt. Spezielle Tags binden Objekte in die Seite ein, die über Attribute zur Steuerung, Darstellung und zur Datenquelle näher spezifiziert werden. Der Webbrowser interpretiert die entsprechenden Befehle und stellt die Objekte dar. Den Unterschied zu gewöhnlichen Web Seiten machen die in den HTML-Code eingebetteten, speziellen Objekte des SAP BW aus, die als Web Items bezeichnet werden. Im Web Template wird definiert, aus welcher Quelle die Web Items ihre Daten beziehen und auf welche Weise sie darzustellen sind. Die möglichen Operationen werden im selben Template als SAP BW URLs hinterlegt. Sie verändern die Eigenschaften der Web Items und stellen Exportfunktionen sowie Verknüpfungen zu anderen Berichten bereit (vgl. SAP AG, 2005). Um eine einfache Programmlogik in HTML-Seiten zur komplexeren Verarbeitung der Benutzerinteraktion zu erzeugen, wird JavaScript verwendet. Diese Programmiersprache wurde 1995 von Netscape entwickelt und ist kein Bestandteil von HTML, wird aber von den meisten Webbrowsern interpretiert. Auch in Web Templates wird JavaScript eingesetzt, um auf Aktionen des Anwenders reagieren zu können (vgl. SAP AG, 2005). Web Items In der Arbeitsumgebung des BEx Web Application Designers werden die Web Items angeordnet und konfiguriert. Am Beispiel des Web Items Chart wird im folgenden Abschnitt der Umfang der Konfigurationseinstellungen vorgestellt. Zusätzlich zu den bereits in der Standard-Symbolleiste sowie im Kontextmenü und im Navigationsblock genannten Web Items sind die Karte, der Alert Monitor und Dokumente im SAP BW vorhanden, auch auf diese Elemente wird später eingegangen.

3.5 Berichtswesen

105

Konfiguration von Charts In Web Applications können unterschiedliche Diagrammtypen verwendet werden. Sind diese relativ einfach aufgebaut und verfügen sie über eine übersichtliche Datentabelle, so kann die Formatierung auch automatisch durch das System erfolgen. Das System kann zum Beispiel die Überschrift und die Achsenbeschriftungen setzen. Ist eine stärkere Individualisierung des Diagramms erwünscht, etwa die gemeinsame Darstellung unterschiedlicher Chart-Typen in einem einzigen Diagramm, so müssen die Eigenschaften manuell im BEx Web Application Designer angepasst werden. Die Auswirkungen der Veränderungen können in einem Vorschaufenster nachvollzogen werden. Auch dieses ist konfigurierbar, um eine ergebnisnahe Darstellung während der Entwicklung zu ermöglichen (vgl. SAP AG, 2005). Ein Chart verfügt über einen Hintergrund, eine Zeichnungsfläche mit Achsen und Gitternetzlinien, verschiedene Beschriftungen und Titel sowie eine Legende mit Informationen zu den Datenlinien. Das Darstellungsverhalten aller Elemente wird über eine Reihe verschiedener Attribute beeinflusst. So kann die Größe des Diagramms und der Elemente angepasst sowie deren Position frei bestimmt werden. Der Hintergrund und die Zeichnungsfläche können mit einer anderen Farbe oder einem Muster gefüllt sein und einen variablen Rand aufzeigen (vgl. SAP AG, 2005). Diagramme können bis zu drei Achsen haben, auf denen Größen und Rubriken abgetragen werden. Der Koordinatenursprung kann ebenso wie die Reihenfolge der Werte und Rubriken an den Achsen frei bestimmt werden. Der Anwender kann entscheiden, ob, auf welche Weise und mit welchem Abstand die Haupt- und Zwischenskalenstriche an den Achsen abgebildet werden und wie häufig eine Beschriftung erfolgen soll. Bei Größenachsen kann der erste und der letzte Wert festgelegt sowie ein optisch hervorgehobener Wertebereich vorgegeben werden. Auch die Skalierung einer Größenachse kann verändert werden, indem sie von linear nach logarithmisch umgestellt wird. Zur besseren Lesbarkeit der Datenreihen kann die Zeichnungsfläche zu den Achsen parallele Gitternetzlinien enthalten, die einen Wert oder eine Ausprägung über die gesamte Fläche kennzeichnen. Die Gitternetzlinien können in einer eigenen Farbe dargestellt und an die Achsenskalierung angepasst werden (vgl. SAP AG, 2005). Die Datenquelle für Diagramme sind Datenreihen. Jede enthält eine Anzahl Tupel, die im Diagramm dargestellt werden. Sämtliche Tupel einer Datenreihe haben die gleiche Farbe oder das gleiche Muster. Eine zweite, parallele Achse kann eingeführt werden, um mehrere Datenreihen, die sich in Wertebereich oder Einheit unterscheiden, in einem gemeinsamen Diagramm abzubilden. Datenreihen werden an den jeweiligen Diagrammtyp angepasst dargestellt, so dass die Möglichkeiten zur Formatierung nicht für alle Typen gleichermaßen gelten können. Bei linienartigen Diagrammen können die Linien durch Interpolation fehlender Datenpunkte geglättet werden. Einige Diagramme können Trendlinien enthalten, die eine Prognose der zukünftigen Werte visualisieren. Je nach Diagrammtyp sind bei der Pflege im BEx Web Application Designer folgende Besonderheiten zu beachten (vgl. SAP AG, 2005):

106

3 Theoretische Grundlagen des SAP Business Information Warehouse

• Bei Kreis- und Ringdiagrammen kann der Kreis gedreht und die Farbe aller Segmente festgelegt werden, bei letzterem auch die gemeinsame Breite der Ringe. • Zu Histogrammen kann eine Normalverteilung mit Mittelwert und Standardabweichung hinzugefügt und bearbeitet werden. • Das Tachometer Diagramm kann in der Farbwahl und in den Extremwerten der Bereiche angepasst werden. • Dreidimensionale Diagramme erlauben das Bearbeiten der Objekte in der Tiefendimension und die Gestaltung der drei Wandflächen. • Die Farben und die Wertebereiche der Quadranten im Portfolio- oder Quadrantendiagramm können verändert und die Zeichnung der Grenzen der Quadranten ausgeschaltet werden. • Flächen- und Liniendiagramme erlauben das Setzen von Bezugslinien für jeden Datenpunkt, so dass dessen Wert präzise abgelesen werden kann. • Die Darstellung der Datenpunkte beispielsweise in Säulen- und Balkendiagrammen kann bezüglich des Abstandes der Gruppen und der Überlappung der Datenpunkte angepasst werden. Um ein Diagramm verständlicher zu gestalten, wird vom System eine Legende hinzugefügt, welche die Farben und Muster in Bezug mit den Datenreihen stellt. Die Formatierung der Legende kann vom Anwender beeinflusst und somit die voreingestellte Formatierung verändert werden. Auch der Diagrammtitel, Achsenund Datenbeschriftungen geben Aufschluss über die dargestellten Werte. Um die Werte in einem Diagramm nachvollziehen zu können, kann auch die Datentabelle, auf welcher das Diagramm basiert, dargestellt und formatiert werden (vgl. SAP AG, 2005). Wenn Diagramme im produktiven Einsatz auch ausgedruckt werden sollen, so kann das Ergebnis bei der Erstellung vorweggenommen und aus der Vorschau heraus gedruckt werden. Hierzu kann zuvor das Seitenformat und das Seitenlayout unabhängig von den Parametern im Web Item eingestellt werden (vgl. SAP AG, 2005). Karte Informationen können nicht nur in Diagrammen grafisch ausgegeben werden. Wurde bei der InfoObject-Pflege ein Merkmal mit geografischen Shape Files ausgestattet, so ist eine Darstellung der Informationen auf einer Landkarte möglich. Durch diese Art der Darstellung der Informationen können geografische Besonderheiten und Zusammenhänge leichter ersichtlich werden als in einer Tabelle oder einem Diagramm. Die Kennzahlen zu einer Region werden durch Einfärbung der Fläche, durch Kreis- oder Balkendiagramme dargestellt. Das Web Item Karte bietet mehrere Schichten für die Darstellung an, so dass Informationen zu verschiedenen Kennzahlen in einer Karte gemeinsam in verschiedenen Formen abgebildet werden können. So kann eine Kennzahl durch eine eingefärbte Fläche, eine andere als Kreisdiagramm dargestellt werden (vgl. SAP AG, 2005). Das Web Item Karte bietet erweiterte Funktionen zur Navigation. Neben einer Vergrößerung eines Bereiches und dem Verschieben eines Kartenausschnitts kann

3.5 Berichtswesen

107

die Granularität der Darstellung verändert werden, so dass die Sicht zum Beispiel von der kontinentalen zur Landesebene verfeinert wird. Auf Karten können auch geografische Merkmale wie Flüsse und Gebirge abgebildet werden (vgl. SAP AG, 2005).

Abb. 3.47. Web Item Karte

Alert Monitor Im Alert Monitor ist es möglich, Informationen über aufgetretene Exceptions und im Hintergrund ausgeführte Operationen des Reporting Agents aufzulisten. Die beim Auftreten der Ausnahmebedingungen aktuellen Sichten können aus dem Alert Monitor aufgerufen werden (vgl. SAP AG, 2005). Dokumente Ein Web Template kann durch die Web Items Dokument und Liste von Dokumenten um zusätzliche Informationsträger erweitert werden. In Dokumenten kann man unstrukturierte Informationen hinterlegen, die das Verständnis der Auswertung unterstützen oder Zusammenhänge zu anderen Quellen herstellen. Denkbar sind zum Beispiel erweiterte Produktinformationen, die zu einem Eintrag in der Ergebnistabelle verfügbar sind. Das Dokument kann im selben oder einem eigenen Fenster geöffnet werden. Durch den Eintrag Springen im Kontextmenü ist ein direkter Aufruf der vorhandenen Dokumente möglich (vgl. SAP AG, 2005).

108

3 Theoretische Grundlagen des SAP Business Information Warehouse

Hinweis: Um den bis hierhin vermittelten theoretischen Inhalt praktisch zu vertiefen, kann an dieser Stelle das Kapitel 4.3.4 Reporting mit dem BEx Web Application Designer bearbeitet werden.

3.5.5 Formatiertes Reporting Die Crystal Reports der Business Objects SA sind im formatierten Reporting in das SAP BW integriert. Für formatierte Berichte sind pixelgenaues Layout und umfassende Druckoptionen von wesentlicher Bedeutung. Basis für das formatierte Reporting ist die Darstellung einer Query in tabellarischer Form. Im SAP Business Content sind vorgefertigte Templates für formatierte Berichte zu Business Content Queries enthalten, zur Erstellung eigener formatierter Berichte ist der Crystal Reports Designer erforderlich (vgl. Mehrwald, 2004). 3.5.6 Mobile Intelligence Die im BEx Web Application Designer erstellten Web Applications können ebenfalls auf mobilen Geräten dargestellt werden, unterstützt werden folgende Technologien (vgl. SAP AG, 2002c): • PDAs (Personal Digital Assistants) mit Betriebssystem Windows CE 3.0 und Pocket Internet Explorer • WAP-fähige Mobiltelefone • i-Mode-fähige Mobiltelefone • Mobile Geräte mit EPOC32 Betriebssystem (etwa Nokia Communicator 9210) • Weitere Handhelds wie etwa der Palm Pilot werden abhängig vom installierten Browser unterstützt Der Umfang der unterstützten Funktionen ist dabei beim PDA am größten, bei der Erstellung der Applikationen sollte zusätzlich auf die Darstellungsmöglichkeiten der verwendeten Endgeräte hinsichtlich Farben und Größe des Displays geachtet werden (vgl. Matthee und Kaufmann, 2001). Grundlage der Übertragung zu mobilen Geräten ist entweder das Wireless Application Protocol (WAP) oder das Hypertext Transfer Protocol (HTTP), der Typ des jeweils verbundenen mobilen Endgerätes wird vom BW Application Server automatisch identifiziert und die Daten werden entsprechend übermittelt. Der Aufruf erfolgt über die gleiche URL wie bei den Web Applications. Einzig beim PDA ist neben dem online Betrieb auch eine Analyse offline über vorberechnete HTML-Seiten möglich (vgl. SAP AG, 2002a).

3.5 Berichtswesen

109

Abb. 3.48. Mobile Intelligence

3.5.7 Weitere Funktionen: Offline Reporting und Integration in das SAP Enterprise Portal Web Applications stehen nicht nur online, sondern auch offline für das Reporting zur Verfügung. Die Downloads vorberechneter HTML-Seiten können mit dem BEx Download Scheduler zeitlich eingeplant und die erforderlichen Webseiten lokal gespeichert werden (vgl. SAP AG, 2004). Reports können sowohl auf PCs als auch auf mobilen Endgeräten offline verfügbar gemacht werden (vgl. SAP AG, 2005). Allerdings ist zu beachten, dass die Berichte einen rein statischen Charakter haben und nicht über die Navigationsfunktionen und Kontextmenüs der Online-Reports verfügen.

110

3 Theoretische Grundlagen des SAP Business Information Warehouse

Die Funktionen zur Personalisierung ermöglichen eine anwenderspezifische Belegung von Variablen, anwenderspezifische Startbildschirme von Web Applications und eine Historie der zuletzt verwendeten Reporting Objekte. Unternehmensinterne Portale gewinnen im Bereich der Business Intelligence immer stärker an Bedeutung, daher können Web Templates als iView gespeichert werden. Diese iViews ermöglichen das Einbinden von Daten aus Anwendungen, Dokumenten und dem Internet in das Enterprise Portal der SAP AG (vgl. Polus, 2003). Die Integration in das Enterprise Portal als so genannter single point of entry vereinfacht unterschiedlichen Bereichen eines Unternehmens den Zugriff auf Daten und Reports wesentlich. Die Definition von Rollen stellt sicher, dass die zur Verfügung gestellten Informationen ausschließlich von autorisierten Personen eingesehen werden können (vgl. SAP AG, 2005).

4 Fallstudie I – Ist-Daten-Analyse

Das vierte Kapitel vermittelt den praktischen Einstieg in das SAP BW anhand einer durchgängigen Fallstudie. Diese ist in drei Abschnitte unterteilt, die dem typischen Ablauf des Data Warehousing entsprechen. Ein Beispielszenario soll die betriebswirtschaftlichen Hintergründe vorstellen, welche das Datenmodell und somit den Aufbau und die Struktur der SAP BW-Objekte determinieren. Entscheidungen, die aus der betriebswirtschaftlichen Aufgabenstellung resultieren, können von Beginn an praktisch am SAP BW nachvollzogen werden. Die Anforderungen an das Datenmodell werden in der im Kapitel 2.3.5 ADAPT beschriebenen ADAPTNotation dargestellt (siehe Abb. 4.1. Szenario in ADAPT Notation). Die erforderlichen Schritte sind in präzisen Anweisungen ausformuliert und werden durch Screenshots unterstützt, die helfen, den Bezug zur Benutzeroberfläche herzustellen. Sämtliche Angaben bezüglich des Unternehmens im Szenario sind frei erfunden und stehen in keinem Zusammenhang mit realen Gesellschaften. Aufgabenstellung und Szenario Eine große deutsche Elektronik–Einzelhandelskette, die auf dem europäischen Markt tätig ist, führt ihr gesamtes Reporting bisher MS Excel-basiert durch. Die Daten werden manuell aus der Datenbank des operativen Systems über eigens zu diesem Zweck formulierte SQL-Abfragen beschafft und durch eine Export-Funktion in eine CSV-Datei geschrieben. Diese wird mit MS Excel geöffnet und in ein von der Unternehmensleitung definiertes Format überführt. Durch verschiedene Formeln und Makros werden die Daten aufbereitet und die Kennzahlen bestimmt. Die MS Excel-Tabellen werden farblich hinterlegt und um Diagramme ergänzt, damit die relevanten Informationen schnell erkennbar sind. Auf diese Weise entstehen Report-Dateien, die per E-Mail an die Entscheidungsträger versendet oder deren Ergebnisse als Diagramme in MS Powerpoint-Präsentationen einfließen. Der gesamte Prozess der Datenbeschaffung und Aufbereitung wird von den verantwortlichen Mitarbeitern in den Fachabteilungen periodisch wiederholt, etwa für den Bericht der Quartalsumsätze, meist jedoch auf Wochenbasis. Das Management war bisher in der Lage, die Restriktionen und Risiken einer MS Officebasierten Lösung zu tolerieren, doch der zunehmende Wettbewerb macht es kaum mehr möglich, das Reporting ohne tief greifende Veränderungen weiterzuführen. Der durch die Ausreizung der Möglichkeiten von MS Excel entstehende zeitliche Aufwand sowie das immense Fehlerpotential und nicht zuletzt der zeitliche wie datenbezogene Mangel an Flexibilität dieser Lösung zwingen die Entscheidungsträger zu einer Reorganisation des Berichtswesens. Ein Ausbau des

112

4 Fallstudie I – Ist-Daten-Analyse

operativen Systems wurde wegen der hohen Kosten, des bedeutsamen Aufwandes zur Erstellung und Pflege einer solchen Lösung sowie der Belastung des Systems verworfen. Um das Berichtswesen sinnvoll zu vereinheitlichen und seine Leistungsfähigkeit zu erhöhen, soll zur Reportingfunktion zukünftig ein SAP BW System eingesetzt werden. Das System ist bereits angeschafft und steht in einer lauffähigen Version eingerichtet bereit, jedoch sind noch keine Strukturen der Daten erstellt worden. Der Informationssystemabteilung wurde die Aufgabe übertragen, einen Prototyp zu erstellen, der exemplarisch lediglich die Umsätze dreier vom Unternehmen vertriebener Produktgruppen in Deutschland, Dänemark und den Niederlanden berücksichtigt. Der Prototyp soll einen ersten Eindruck über die Potentiale des Systems vermitteln und dem betreuenden Fachpersonal die Möglichkeit geben, sich mit dem SAP BW vertraut zu machen. Man hat Sie damit beauftragt, den Prototypen gemäß den Anforderungen der Entscheidungsträger aufzubauen. Als Mitarbeiter der Informationssystemabteilung hat man sie damit beauftragt, den Prototypen gemäß den Anforderungen der Entscheidungsträger aufzubauen. Besonders interessiert sich die Geschäftsführung für die Entwicklung der Umsätze in den einzelnen Produktgruppen, um Informationen für die zukünftige Gestaltung der Produktpalette abzuleiten. Außerdem soll herausgearbeitet werden, welche Produktgruppe in den jeweiligen Ländern besonders umsatzstark ist. Das Ziel ist es, das SAP BW derart einzurichten, dass Analysen auf den Quartalsumsätzen der drei Produktgruppen für einen Zeitraum von zwei Jahren möglich sind. Diese werden zusätzlich nach den verschiedenen Vertriebsorganisationen unterschieden, die jeweils für einen Markt in Europa stehen. Die Analysen sollen durch BEx Queries auf InfoProvidern des SAP BW aufsetzen und sowohl in MS Excel als auch im Webbrowser dargestellt werden. Außerdem möchte man einen Eindruck vom BEx Web Application Designer gewinnen. Von der Informationssystemabteilung werden Ihnen die Ist-Daten für eine Analyse bereitgestellt. Das zugehörige Datenmodell können Sie dem ADAPT-Diagramm (siehe Abb. 4.1. Szenario in ADAPT Notation) entnehmen. Der Plan sieht zunächst die Modellierung der Datenobjekte vor. Sie werden einige Objekte zur Strukturierung anlegen und anschließend die Merkmale Produkthauptgruppe, Produktgruppe und Land im System erstellen. Als Kennzahl werden Sie den Umsatz definieren. Anschließend wird von Ihnen der Datenwürfel modelliert und mit den zuvor angelegten InfoObjects befüllt. Für die Zeitmerkmale werden Sie den bereits im System enthaltenen SAP Business Content verwenden. Die Dimensionen Produkt und Region werden Sie im InfoCube anlegen und ihnen die korrespondierenden Merkmale zuordnen. In der Phase der Datenbeschaffung werden die Stamm- und Bewegungsdaten aus den bereitgestellten flachen Dateien in das SAP BW geladen. Für die Produktgruppe und die Produkthauptgruppe werden die Stammdaten aus den CSV-Dateien entnommen, für das Land werden Sie die Stammdaten manuell anlegen. Die Bewegungsdaten werden über Fortschreibungsregeln aus der PSA direkt in den InfoCube fortgeschrieben. Für das Reporting legen Sie eine Query an, deren InfoProvider der zuvor beschriebene InfoCube ist. Sie werden anschließend die Möglichkeiten des BEx Analyzer, des Ad hoc – Reportings und des BEx Web Application Designers kennen lernen. Die

4.1 Teil I – Datenmodellierung

113

von der Geschäftsleitung gewünschten Informationen stellen Sie im Ad hoc-Reporting bereit.

Abb. 4.1. Szenario in ADAPT Notation

Die Bewegungs- und Stammdaten liegen als Schnittstellendateien im CSV – Format vor und können unter http://rom.hcc.uni-magdeburg.de/BW_Buch/ herunter geladen werden.

4.1 Teil I – Datenmodellierung Um die Modellierung der zur Lösung der Aufgabe erforderlichen Objekte vornehmen zu können, wird nach dem Anmeldevorgang im SAP Easy Access Fenster durch die Eingabe eines Transaktionscodes die Administrator Workbench geöffnet. Diese Komponente ermöglicht es, durch verschiedene Sichten das SAP BW zu verwalten. So ist neben der Modellierungssicht beispielsweise auch das Metadata Repository verfügbar, welches einen Einblick in die Metadaten der Objekte des SAP BW gewährt. Der im SAP Easy Access eingegebene Transaktionscode bewirkt, dass die Administrator Workbench automatisch in der Sicht Modellierung

114

4 Fallstudie I – Ist-Daten-Analyse

geöffnet wird. Hier wird das Datenmodell angelegt und die Einstellungen für die Datenbeschaffung vorgenommen. Als erstes Objekt ist eine InfoArea anzulegen. In einer InfoArea werden die InfoObjects wie Kennzahlen und Merkmale sowie die InfoProvider wie InfoCubes und ODS-Objekte strukturiert abgelegt, so dass beim Anlegen der Objekte die Übersichtlichkeit gewahrt wird. In einer InfoArea werden InfoObjectCatalogs erstellt, der dem geordneten Anlegen von InfoObjects dienen. In einem InfoObjectCatalog können sich entweder Kennzahlen oder Merkmale befinden. Die InfoObjects dürfen mehrfach in verschiedenen InfoObjectCatalogs über Referenzen auftreten, so dass ein wiederholtes Anlegen nicht erforderlich ist. Durch InfoObjects vom Typ Merkmal ist es möglich, eine Zuordnung von Kennzahlen zu einem Sachverhalt zu vollziehen. So können durch das Merkmal Produktgruppe Aussagen über die Kennzahlen je Produktgruppe formuliert werden. Wird zusätzlich noch das Merkmal Land hinzugezogen, so kann man die Kennzahlen kombiniert für jede Produktgruppe und jedes Land analysieren. Für Merkmale können im System Stammdaten hinterlegt werden. In der InfoObjectPflege wird festgelegt, ob ein Merkmal über Texte verfügt, die statt des Merkmalsschlüssels dargestellt werden können. Texte zu Merkmalswerten erleichtern das Verständnis, da sie dem Sprachgebrauch näher kommen als die oft für Merkmalswerte verwendeten alphanumerischen Zeichenfolgen. Neben Texten zählen auch externe Hierarchien zu den Stammdaten. Hierarchien werden in der InfoObject-Pflege lediglich frei geschaltet und mit Parametern versehen. Die eigentliche Einordnung der Merkmalswerte in eine hierarchische Struktur erfolgt außerhalb der InfoObject-Pflege. Merkmale können in einer festgelegten Relation zu einem anderen Merkmal stehen, welche unter dem Begriff des Attributes das dritte und letzte Stammdatenelement bildet und unter der Option Stammdaten frei geschaltet wird. Ein Attribut wird in einer Auswertung zusammen mit dem Merkmal angeordnet. Wenn beispielsweise die Produktgruppe in einer Auswertung verwendet wird, so ist automatisch die dazugehörige Produkthauptgruppe mit aufgeführt. Soll die Produkthauptgruppe hingegen auch zur Navigation im Datenbestand verwendet werden, so kann sie bei der InfoObject-Pflege entsprechend eingerichtet werden. Diese Verknüpfung minimiert den Erstellungsaufwand eines InfoProviders, denn das Attribut zu einem Merkmal ist in der Auswertung verfügbar, ohne dass es wie das Merkmal explizit im InfoProvider definiert wurde. Das Merkmal Land soll ein Geomerkmal sein. Geomerkmale können über besondere Dateianlagen, so genannte Shape Files, verfügen. In den Shape Files sind Einträge enthalten, welche einem Standard für die Geokodierung entsprechen. Das SAP BW ist in der Lage, aus diesen Dateien die für die Darstellung einer Landkarte benötigten Informationen auszulesen. Um das Hochladen geografischer Daten vorzunehmen, muss die Option unter den Einstellungen des Business Explorer eingestellt werden. InfoObjects vom Typ Kennzahl stellen quantifizierende Größen dar, mit denen mathematische Operationen möglich sind. Es gibt Fluss- und Bestandskennzahlen. Flusskennzahlen können über die zeitliche Dimension aggregiert werden. So ist es etwa möglich, den in dieser Fallstudie verwendeten Umsatz über mehrere Perio-

4.1 Teil I – Datenmodellierung

115

den aufzusummieren. Einen Bestand wie die Anzahl im Unternehmen eingesetzter Personalcomputer kann nicht sinnvoll über einen Zeitraum summiert werden. Bei der InfoObject-Pflege wird der Umsatz im System als Betrag mit Währungsschlüssel hinterlegt. Dadurch wird diese Kennzahl mit einem Merkmal verbunden, welches über verschiedene Währungen verfügt. Alternativ wäre es auch möglich gewesen, eine feste Währung anzugeben, jedoch wird dadurch die Flexibilität eingeschränkt. InfoProvider werden alle direkt für das Reporting verwendbaren Objekte bezeichnet. In dieser Fallstudie wird ein InfoCube angelegt, in welchem Bewegungsdaten physisch enthalten sein werden. InfoCubes sind entwickelt worden, um effiziente OLAP-Operationen zur Navigation im Datenbestand auszuführen. Das Modell eines solchen Datenwürfels ist aus InfoObjects aufgebaut. Merkmale werden in Dimensionen angeordnet und beschreiben die Charakteristik der Bewegungsdaten, während die Kennzahlen in die Faktentabelle des InfoCubes aufgenommen werden. Jeder InfoCube verfügt über drei voreingestellte Dimensionen. Die zeitliche Dimension kann mit verschiedenen InfoObjects aus dem SAP Business Content gestaltet werden. In der Fallstudie werden zum Beispiel die Zeitmerkmale Jahr und Quartal aus dem SAP Business Content verwendet. Die Dimension der Einheiten wird automatisch vom System im InfoCube angelegt und enthält in der Fallstudie die Währung des Umsatzes. Daneben existiert noch die Dimension Paket, in der technische Informationen zu den im InfoCube enthaltenen Datenpaketen enthalten sind. Alle weiteren Dimensionen können vom Anwender von Grund auf frei definiert werden. So werden zunächst die Merkmale, Zeitmerkmale und Kennzahlen in den InfoCube eingepflegt, anschließend werden die individuellen Dimensionen definiert und eine Zuordnung von Merkmalen zu Dimensionen vollzogen. Damit das Navigationsattribut zur Produktgruppe im Reporting entsprechend verwendet werden kann, wird es als solches im InfoCube kenntlich gemacht. Damit sind die für die Datenmodellierung erforderlichen Arbeitsschritte abgeschlossen. 4.1.1 Anlegen der InfoArea Starten Sie aus dem MS Windows Startmenü die Anwendung SAPlogon und melden Sie sich am zugewiesenen SAP BW System an. Nach der Eingabe von Benutzer und Kennwort öffnet sich der SAP BW Startbildschirm. Geben Sie den Transaktionscode RSA1 in das Kommandofeld ein und bestätigen Sie mit Enter (siehe Abb. 4.2. SAP Easy Access, Schritt 1), um zur Administrator Workbench zu gelangen. Sie sehen die Liste der angelegten InfoProvider.

116

4 Fallstudie I – Ist-Daten-Analyse

Abb. 4.2. SAP Easy Access

Wechseln Sie im Menübaum zu InfoObjects (siehe Abb. 4.3. Anlegen der InfoArea, Schritt 1) und markieren Sie durch einen Linksklick die InfoArea zur Fallstudie (siehe Abb. 4.3. Anlegen der InfoArea, Schritt 2, und vgl. Kapitel 1.2 Vorbereitung der Fallstudien). Mit einem Rechtsklick öffnet sich das kontextsensitive Menü, in dem Sie Anlegen... auswählen (siehe Abb. 4.3. Anlegen der InfoArea, Schritt 3). Im folgenden Dialog geben Sie den technischen Namen A_IA_### Ihrer InfoArea ein (siehe Abb. 4.3. Anlegen der InfoArea, Schritt 4), wobei die Zeichenkette ### Ihre Gruppennummer und ID bezeichnet (im Folgenden wird diese Schreibweise als bekannt vorausgesetzt, die Zeichenfolge ### ist dann stets wie zuvor beschrieben zu ersetzen). Vergeben Sie außerdem als Beschreibung lang Fallstudie BW ###. Anschließend bestätigen Sie Ihre Angaben durch Drücken der Taste Enter. Ihre InfoArea ist nun unter der InfoArea zur Fallstudie angelegt worden.

4.1 Teil I – Datenmodellierung

117

Abb. 4.3. Anlegen der InfoArea

4.1.2 Anlegen des InfoObjectCatalogs und der InfoObjects Klicken Sie mit der rechten Maustaste auf Ihre selbst erstellte InfoArea A_IA_### (siehe Abb. 4.4. Anlegen des InfoObjectCatalogs, Schritt 1) und wählen Sie den Menüpunkt InfoObjectCatalog anlegen... (siehe Abb. 4.4. Anlegen des InfoObjectCatalogs, Schritt 2). Im Dialog InfoObjectCatalog bearbeiten geben Sie unter InfoObjCat den technischen Namen A_IOCM_### und im Textfeld rechts davon die Beschreibung Merkmale Fallstudie BW ### ein (siehe Abb. 4.4. Anlegen des InfoObjectCatalogs, Schritt 3). Achten Sie darauf, dass im Gruppierungsfeld InfoObjectTyp die Selektion Merkmal getroffen ist. Zum Abschluss klicken Sie auf die Schaltfläche Anlegen (siehe Abb. 4.4. Anlegen des InfoObjectCatalogs, Schritt 4).

118

4 Fallstudie I – Ist-Daten-Analyse

Abb. 4.4. Anlegen des InfoObjectCatalogs

In der folgenden Übersicht InfoObjectCatalog bearbeiten werden im Gruppierungsfeld InfoObjects die verfügbaren und dem InfoObjectCatalog zugeordneten InfoObjects aufgelistet. Klicken Sie nun auf die Schaltfläche InfoObject(s) anlegen (siehe Abb. 4.5. InfoObjectCatalog bearbeiten, Schritt 1). Im anschließenden Dialog Merkmal anlegen werden Sie aufgefordert, den technischen Namen und eine Beschreibung zu vergeben. Tragen Sie hier unter Merkmal A_MPH_### und unter Beschreibung lang Produkthauptgruppe ### ein (siehe Abb. 4.5. InfoObjectCatalog bearbeiten, Schritt 2), die anderen beiden Textfelder Referenzmerkmal und Vorlage bleiben leer. Schließen Sie den Dialog mit Enter ab (siehe Abb. 4.5. InfoObjectCatalog bearbeiten, Schritt 3).

4.1 Teil I – Datenmodellierung

119

Abb. 4.5. InfoObjectCatalog bearbeiten

Die Eigenschaften des neu angelegten Merkmals A_MPH_### werden in der Eingabemaske Merkmal A_MPH_### anlegen: Detail gepflegt. Stellen Sie sicher, dass als Beschreibung kurz nur der Text Produkthauptgruppe hinterlegt ist (siehe Abb. 4.6. Merkmal Produkthauptgruppe anlegen 1, Schritt 1). Klicken Sie im Kartenreiter Allgemeines ins Feld Datentyp und wählen Sie aus der sich öffnenden Liste den ersten Eintrag CHAR – Zeichenfolge aus (siehe Abb. 4.6. Merkmal Produkthauptgruppe anlegen 1, Schritt 2). Im unterhalb befindlichen Textfeld Länge tippen Sie 20 ein. Wechseln Sie ins nächste Register Business Explorer. Unter Allgemeine Einstellungen wählen Sie für die Darstellung statt Text Langtext aus (siehe Abb. 4.6. Merkmal Produkthauptgruppe anlegen 1, Schritt 3).

120

4 Fallstudie I – Ist-Daten-Analyse

Abb. 4.6. Merkmal Produkthauptgruppe anlegen 1

In der Statuszeile erscheint die Meldung InfoObject A_MPH_###: Textart Langtext inkonsistent zu Eigenschaft der Texttabelle /BIC/TA_MPH_###. Die Inkonsistenz besteht darin, dass in der Texttabelle für das Merkmal nur ein Kurztext voreingestellt ist. Um die Konsistenz wiederherzustellen, setzen Sie im Kartenreiter Stammdaten/Texte das Häkchen vor Langtext existiert (siehe Abb. 4.7. Merkmal Produkthauptgruppe anlegen 2, Schritt 1) und entfernen das Häkchen vor Kurztext existiert (siehe Abb. 4.7. Merkmal Produkthauptgruppe anlegen 2, Schritt 2). Deaktivieren Sie ebenfalls die Option Mit Stammdaten. Überprüfen Sie, ob im Textfeld InfoArea Ihre InfoArea zur Fallstudie A_IA_### eingetragen ist (siehe Abb. 4.7. Merkmal Produkthauptgruppe anlegen 2, Schritt 3). Abschließend lassen Sie Ihre Eingaben vom System durch betätigen der Schaltfläche Alle prüfen überprüfen (siehe Abb. 4.7. Merkmal Produkthauptgruppe anlegen 2, Schritt 4), in der Statuszeile erscheint die Meldung Merkmale o.k.. Das Merkmal wird nun durch einen Klick auf Aktivieren aktiviert (siehe Abb. 4.7. Merkmal Produkthauptgruppe anlegen 2, Schritt 4).

4.1 Teil I – Datenmodellierung

121

Abb. 4.7. Merkmal Produkthauptgruppe anlegen 2

Das nächste Merkmal legen Sie über die Schaltfläche Anlegen... an (siehe Abb. 4.7. Merkmal Produkthauptgruppe anlegen 2, Schritt 5). Analog zum zuvor angelegten Merkmal Produkthauptgruppe ### tragen Sie hier unter Merkmal A_MPG_### und unter Beschreibung lang Produktgruppe ### ein (siehe Abb. 4.8. Merkmal Produktgruppe anlegen 1, Schritt 1) und schließen den Dialog mit Enter (siehe Abb. 4.8. Merkmal Produktgruppe anlegen 1, Schritt 2). Vergeben Sie die Beschreibung kurz Produktgruppe (siehe Abb. 4.8. Merkmal Produktgruppe anlegen 1, Schritt 3). Nehmen Sie in den einzelnen Kartenreitern zu Produkthauptgruppe identische Einstellungen vor, lediglich die Option Mit Stammdaten im Register Stammdaten/Texte bleibt aktiviert (siehe Abb. 4.8. Merkmal Produktgruppe anlegen 1, Schritt 4). Achten Sie wiederum darauf, dass im selben Register Ihre InfoArea A_IA_### eingetragen ist (siehe Abb. 4.8. Merkmal Produktgruppe anlegen 1, Schritt 5).

122

4 Fallstudie I – Ist-Daten-Analyse

Abb. 4.8. Merkmal Produktgruppe anlegen 1

Zusätzlich ist im Kartenreiter Attribute in die oberste weiß hinterlegte Zelle der Spalte Attribut das Merkmal A_MPH_### als Navigationsattribut zu hinterlegen, dies kann sowohl durch eine direkte Tastatureingabe als auch per Maus über die Auswahlliste erfolgen (siehe Abb. 4.9. Merkmal Produktgruppe anlegen 2, Schritt 1). Im letzteren Fall erscheint ein Popup Trefferliste, dieses kann mit OK übergangen und anschließend das gewünschte Merkmal aus der Liste über einen Doppelklick selektiert werden. Durch Klicken auf die Schaltfläche in der Spalte Navigationsattribut ein/aus wird das Merkmal A_MPH_### als Navigationsattribut frei geschaltet (siehe Abb. 4.9. Merkmal Produktgruppe anlegen 2, Schritt 2). Anschließend lassen Sie das System die Spalte Beschr. Navigationsattribut mit Produkthauptgruppe ### und die Spalte Kurzt. Navigationsattribut mit der Zeichenfolge Produkthauptgruppe befüllen, indem Sie das Häkchen bei Texte vom Merkmal setzen (siehe Abb. 4.9. Merkmal Produktgruppe anlegen 2, Schritt 3). Prüfen Sie Ihre Eingaben und Aktivieren Sie das Merkmal (siehe Abb. 4.9. Merkmal Produktgruppe anlegen 2, Schritt 4). Hinweis: Steht Ihnen der Kartenreiter Attribute nicht zur Auswahl, so ist im Register Stammdaten/Text das Häkchen Mit Stammdaten nicht gesetzt.

4.1 Teil I – Datenmodellierung

123

Abb. 4.9. Merkmal Produktgruppe anlegen 2

Als nächstes wird durch erneutes Betätigen der Schaltfläche Anlegen... das Merkmal Land erstellt (siehe Abb. 4.9. Merkmal Produktgruppe anlegen 2, Schritt 5). Der technische Name lautet A_ML_###, die Beschreibung Land ### (siehe Abb. 4.10. Merkmal Land anlegen 1, Schritt 1). Bestätigen Sie Ihre Eingaben mit Enter (siehe Abb. 4.10. Merkmal Land anlegen 1, Schritt 2). Im Pflegebildschirm Merkmal A_ML_### anlegen: Detail vergeben Sie die Kurzbeschreibung Land (siehe Abb. 4.10. Merkmal Land anlegen 1, Schritt 3) und wählen im Register Allgemeines als Datentyp CHAR – Zeichenfolge mit der Länge 20 (siehe Abb. 4.10. Merkmal Land anlegen 1, Schritt 4). Wechseln Sie in die nächste Registerkarte Business Explorer. Hier ändern Sie die Darstellung in Langtext (siehe Abb. 4.10. Merkmal Land anlegen 1, Schritt 5) und treffen im Bereich BExMap unter Geographischer Typ die Selektion Statisches Geomerkmal (siehe Abb. 4.10. Merkmal Land anlegen 1, Schritt 6).

124

4 Fallstudie I – Ist-Daten-Analyse

Abb. 4.10. Merkmal Land anlegen 1

Im Kartenreiter Stammdaten/Texte entfernen Sie die Markierungen Mit Stammdaten (siehe Abb. 4.11. Merkmal Land anlegen 2, Schritt 1) sowie Kurztext existiert und aktivieren stattdessen Langtext existiert (siehe Abb. 4.11. Merkmal Land anlegen 2, Schritt 2). Beachten Sie, dass Ihre InfoArea A_IA_### eingetragen ist (siehe Abb. 4.11. Merkmal Land anlegen 2, Schritt 3). Wechseln Sie nun ins Register Hierarchie und setzen Sie den Haken mit Hierarchien (siehe Abb. 4.11. Merkmal Land anlegen 2, Schritt 4), als Hierarchieeigenschaft muss Hierarchie nicht zeitabhängig selektiert sein. Klicken Sie auf Alle prüfen und Aktivieren Sie das Merkmal (siehe Abb. 4.11. Merkmal Land anlegen 2, Schritt 5).

4.1 Teil I – Datenmodellierung

125

Abb. 4.11. Merkmal Land anlegen 2

Durch Betätigen der Schaltfläche Zurück gelangen Sie erneut zur Übersicht InfoObjectCatalog bearbeiten. Die zuvor angelegten InfoObjects sind in der Vorlage bereits markiert und sind über die Schaltfläche Felder übernehmen in die Struktur zu übertragen (siehe Abb. 4.12. InfoObjectCatalog Merkmale bearbeiten, Schritt 1). Die Markierung wird nun vom System ausgeblendet, das Fenster mit den übernommenen Merkmalen sollte auf Ihrem Bildschirm aussehen wie Abb. 4.12. InfoObjectCatalog Merkmale bearbeiten, Schritt 2. Prüfen und Aktivieren Sie die Selektion (siehe Abb. 4.12. InfoObjectCatalog Merkmale bearbeiten, Schritt 3) und kehren Sie anschließend durch Zurück in die Administrator Workbench zurück.

126

4 Fallstudie I – Ist-Daten-Analyse

Abb. 4.12. InfoObjectCatalog Merkmale bearbeiten

Nachdem die Merkmale nun vollständig im System hinterlegt sind, muss noch die Kennzahl erstellt werden. Legen Sie dazu zunächst einen weiteren InfoObjectCatalog mit dem Namen A_IOCK_### in Ihrer InfoArea an (siehe Abb. 4.13. InfoObjectCatalog Kennzahlen anlegen, Schritt 1 und Schritt 2) und vergeben Sie die Beschreibung Kennzahlen Fallstudie BW ### (siehe Abb. 4.13. InfoObjectCatalog Kennzahlen anlegen, Schritt 3). Als InfoObjectTyp selektieren Sie Kennzahl (siehe Abb. 4.13. InfoObjectCatalog Kennzahlen anlegen, Schritt 4) und schließen den Vorgang mit Anlegen ab (siehe Abb. 4.13. InfoObjectCatalog Kennzahlen anlegen, Schritt 5).

4.1 Teil I – Datenmodellierung

127

Abb. 4.13. InfoObjectCatalog Kennzahlen anlegen

Über die Schaltfläche InfoObject(s) anlegen (siehe Abb. 4.14. Kennzahl Umsatz anlegen, Schritt 1) hinterlegen Sie die Kennzahl A_KU_### mit der Beschreibung Umsatz ###, die Felder Referenzkennzahl und Vorlage bleiben leer (siehe Abb. 4.14. Kennzahl Umsatz anlegen, Schritt 2). Bestätigen Sie mit Enter (siehe Abb. 4.14. Kennzahl Umsatz anlegen, Schritt 3).

128

4 Fallstudie I – Ist-Daten-Analyse

Abb. 4.14. Kennzahl Umsatz anlegen

Im Bildschirm Kennzahl A_KU_### anlegen: Detail tragen Sie als Beschreibung kurz Umsatz ein (siehe Abb. 4.15. Kennzahl Umsatz ändern, Schritt 1). Achten Sie darauf, dass als Typ / Datentyp der Radiobutton bei Betrag gesetzt (siehe Abb. 4.15. Kennzahl Umsatz ändern, Schritt 2) und der Datentyp CURR – Währungsfeld, abgelegt als DEC ist (siehe Abb. 4.15. Kennzahl Umsatz ändern, Schritt 3). Tragen Sie als Einheit / Währung im Gruppierungsfeld Währung/Mengeneinheit 0CURRENCY ein (siehe Abb. 4.15. Kennzahl Umsatz ändern, Schritt 4). Prüfen und Aktivieren Sie die Kennzahl (siehe Abb. 4.15. Kennzahl Umsatz ändern, Schritt 5).

4.1 Teil I – Datenmodellierung

129

Abb. 4.15. Kennzahl Umsatz ändern

Betätigen Sie die Schaltfläche Zurück und übernehmen Sie die gerade angelegte Kennzahl aus der Vorlage in die Struktur (siehe Abb. 4.16. InfoObjectCatalog Kennzahlen bearbeiten, Schritt 1). Die Markierung wird nun vom System ausgeblendet, das Fenster mit den übernommenen Kennzahlen sollte auf Ihrem Bildschirm aussehen wie Abb. 4.16. InfoObjectCatalog Kennzahlen bearbeiten, Schritt 2. Prüfen und Aktivieren Sie den InfoObjectCatalog (siehe Abb. 4.16. InfoObjectCatalog Kennzahlen bearbeiten, Schritt 3). Verlassen Sie die Maske über Zurück. Hinweis: Aktualisieren Sie die Ansicht in der Administrator Workbench über die Schaltfläche Baum aktualisieren, damit die getätigten Änderungen sich auf die Baumstruktur auswirken.

130

4 Fallstudie I – Ist-Daten-Analyse

Abb. 4.16. InfoObjectCatalog Kennzahlen bearbeiten

4.1.3 Anlegen des InfoCubes für die Ist-Daten Wechseln Sie im Menübaum zum Eintrag InfoProvider und wählen Sie Ihre InfoArea A_IA_### an (siehe Abb. 4.17. InfoCube Ist anlegen, Schritt 1). Hinweis: Sollte Ihre InfoArea nicht in der Liste angezeigt werden, so aktualisieren Sie diese über die Schaltfläche Baum aktualisieren. Mittels Rechtsklick öffnet sich das kontextsensitive Menü zur InfoArea, in dem Sie InfoCube anlegen... auswählen (siehe Abb. 4.17. InfoCube Ist anlegen, Schritt 2). Tragen Sie im Dialog InfoCube bearbeiten A_ICI_### als technischen Namen sowie Ist-Daten Fallstudie BW ### als Beschreibung ein (siehe Abb. 4.17. InfoCube Ist anlegen, Schritt 3). Achten Sie darauf, dass als Typ des InfoCubes lediglich BasisCube selektiert ist (siehe Abb. 4.17. InfoCube Ist anlegen, Schritt 4), und schließen Sie die Eingabe durch Anlegen ab (siehe Abb. 4.17. InfoCube Ist anlegen, Schritt 5).

4.1 Teil I – Datenmodellierung

131

Abb. 4.17. InfoCube Ist anlegen

Es öffnet sich der Bildschirm InfoCube bearbeiten: Merkmale. Im Kartenreiter Merkmale markieren Sie Ihre Merkmale Produktgruppe ### und Land ### (siehe Abb. 4.18. InfoCube Ist bearbeiten 1, Schritt 1). Durch Betätigen der Schaltfläche Felder übernehmen übertragen Sie die Merkmale aus der Vorlage in die Struktur (siehe Abb. 4.18. InfoCube Ist bearbeiten 1, Schritt 2 und Schritt 3). Klicken Sie nun auf Dimensionen... (siehe Abb. 4.18. InfoCube Ist bearbeiten 1, Schritt 4) und schließen das Popup Dimensionen anlegen mit der Schaltfläche Nein (siehe Abb. 4.18. InfoCube Ist bearbeiten 1, Schritt 5).

132

4 Fallstudie I – Ist-Daten-Analyse

Abb. 4.18. InfoCube Ist bearbeiten 1

Im Pflegedialog Dimensionen definieren legen Sie im Kartenreiter Definieren über die Schaltfläche Anlegen eine neue Dimension an (siehe Abb. 4.19. InfoCube Ist bearbeiten 2, Schritt 1) und tragen als Beschreibung lang Produkt ein (siehe Abb. 4.19. InfoCube Ist bearbeiten 2, Schritt 2). Analog erstellen Sie eine zweite Dimension Region. Im nächsten Schritt wechseln Sie in das Register Zuordnen (siehe Abb. 4.19. InfoCube Ist bearbeiten 2, Schritt 3) und setzen das Häkchen hinter Land ### (siehe Abb. 4.19. InfoCube Ist bearbeiten 2, Schritt 4). Weisen Sie das selektierte Merkmal durch Anklicken des Textfeldes mit dem Inhalt Region im Gruppierungsfeld Dimensionen zu (siehe Abb. 4.19. InfoCube Ist bearbeiten 2, Schritt 5) und vollziehen Sie die Zuordnung über die Schaltfläche Zuordnen (siehe Abb. 4.19. InfoCube Ist bearbeiten 2, Schritt 6). Ordnen Sie auf die gleiche Weise das Merkmal Produktgruppe ### der Dimension Produkt zu. Klicken Sie auf die Schaltfläche Weiter um den Pflegedialog zu schließen (siehe Abb. 4.19. InfoCube Ist bearbeiten 2, Schritt 7).

4.1 Teil I – Datenmodellierung

133

Abb. 4.19. InfoCube Ist bearbeiten 2

Sie kehren zurück zum Bildschirm InfoCube bearbeiten: Merkmale, in dem Sie die Schaltfläche Nav.Attribute... anklicken (siehe Abb. 4.20. InfoCube Ist bearbeiten 3, Schritt 1). Im folgenden Dialog schalten Sie das Navigationsattribut Produkthauptgruppe ### durch Setzen des Häkchens in der Spalte Ein/Aus ein (siehe Abb. 4.20. InfoCube Ist bearbeiten 3, Schritt 2). Schließen Sie den Dialog über die Schaltfläche Weiter (siehe Abb. 4.20. InfoCube Ist bearbeiten 3, Schritt 3).

134

4 Fallstudie I – Ist-Daten-Analyse

Abb. 4.20. InfoCube Ist bearbeiten 3

Wählen Sie nun den Kartenreiter Zeitmerkmale. Markieren Sie in der Vorlage die Zeitmerkmale Quartal, Kalenderjahr / Quartal und Kalenderjahr (siehe Abb. 4.21. InfoCube Ist bearbeiten 4, Schritt 1) und übernehmen Sie diese in die Struktur (siehe Abb. 4.21. InfoCube Ist bearbeiten 4, Schritt 2).

4.1 Teil I – Datenmodellierung

135

Abb. 4.21. InfoCube Ist bearbeiten 4

Im Register Kennzahlen fügen Sie die Kennzahl Umsatz ### der Struktur hinzu (siehe Abb. 4.22. InfoCube Ist bearbeiten 5, Schritte 1 bis 3). Prüfen und Aktivieren Sie den InfoCube (siehe Abb. 4.22. InfoCube Ist bearbeiten 5, Schritt 4) und kehren Sie mittels Zurück zur Administrator Workbench zurück.

136

4 Fallstudie I – Ist-Daten-Analyse

Abb. 4.22. InfoCube Ist bearbeiten 5

Wurden alle Objekte korrekt im System hinterlegt, wird der InfoCube Ist-Daten Fallstudie BW ### in der Administrator Workbench nun dargestellt wie in Abb. 4.23. Korrekt modellierter InfoCube Ist.

4.1 Teil I – Datenmodellierung

Abb. 4.23. Korrekt modellierter InfoCube Ist

Zusammenfassung: Im ersten Teil der Fallstudie haben Sie sich im Rahmen der Datenmodellierung mit InfoObjects und InfoCubes auseinandergesetzt. Zur Strukturierung der Objekte wurden von Ihnen die InfoArea Fallstudie BW ### und die InfoObjectCatalogs für Merkmale und Kennzahlen angelegt. Im InfoObjectCatalog Merkmale Fallstudie BW ### wurden von Ihnen die Merkmale Produkthauptgruppe ### und Produktgruppe sowie das Geomerkmal Land ### erstellt. Die Produkthauptgruppe ist als Navigationsattribut der Produktgruppe eingetragen worden. Im InfoObjectCatalog Kennzahlen ### haben Sie die Flusskennzahl Umsatz ### eingepflegt. Nachdem Sie die grundlegenden InfoObjects angelegt haben, wurde der InfoCube Ist-Daten Fallstudie BW ### modelliert. Dessen Struktur haben Sie mit den zuvor angelegten InfoObjects gefüllt und anschließend die beiden Dimensionen Produkt, Region angelegt, die Zeitdimension wird vom System automatisch erstellt. Der Achse Produkt haben Sie das InfoObject Produktgruppe ### und der Achse Region das InfoObject Land ### zugeordnet. Die Produkthauptgruppe wurde als Navigationsmerkmal aktiviert. Als Zeitmerkmale wurden von Ihnen Elemente des SAP Business Content verwendet, deren feinstes Merkmal das Quartal darstellt. Einzige Kennzahl des InfoCubes ist der Umsatz ###.

137

138

4 Fallstudie I – Ist-Daten-Analyse

4.2 Teil II – Datenbeschaffung Die zuvor erstellten SAP BW-Objekte sollen nun mit Stamm- und Bewegungsdaten befüllt werden. Zu diesem Zweck wird eine Anwendungskomponente erstellt, die wie auch die InfoArea den Zweck der strukturierten Ablage der Objekte zum Ziel hat. Innerhalb einer Anwendungskomponentenhierarchie wird eine InfoSource definiert und dieser eine DataSource und ein Quellsystem zugewiesen. Im Rahmen der Fallstudie wird ein Quellsystem verwendet, welches den Zugriff auf lokal abgelegte flache Dateien ermöglicht. Das SAP BW bietet neben einer Schnittstelle zu flachen Dateien auch Technologien für die Anbindung eines SAP Systems, einer relationalen Datenbank, von XML-Datenströmen über SOAP und für den Zugriff auf Fremdsysteme über das BAPI. Die CSV-Datei stellt ein universelles Format für die Datenübertragung bereit und kann über Standard-Werkzeuge wie Texteditoren oder MS Excel bearbeitet werden. Andere Schnittstellen wie zum Beispiel eine Datenbankanbindung eignen sich jedoch besser für eine periodische Übertragung von Massendaten in das SAP BW. In einer InfoSource werden die für die Übertragung der Daten aus der Persistent Staging Area des SAP BW in die Datenziele benötigten Einstellungen hinterlegt. Diese betreffen zunächst die Transferstruktur der Daten, in der festgelegt wird, welche Datenfelder in der Datenquelle verfügbar sind. Zu diesen Datenfeldern werden auch der Datentyp und die Konvertierungsroutine definiert. Beide bestimmen, auf welche Weise die Zeichenfolgen in der Quelle vom SAP BW interpretiert werden sollen. Als nächstes werden die Übertragungsregeln angelegt, mit deren Hilfe es möglich ist, die Daten auf dem Weg von der PSA in das Datenziel zu transformieren. Es ist beispielsweise ein Szenario denkbar, in dem die zu übertragenden Daten inkonsistente Merkmalsausprägungen haben und daher an die der im Datenmodell hinterlegten Werte angepasst werden müssen. Dieser Schritt würde in den Übertragungsregeln etwa durch Formeln oder ABAPRoutinen erfolgen. Als letztes kann die Kommunikationsstruktur gepflegt werden, die Auskunft über das Datenmodell im Datenziel gibt, da sie mit diesem meist übereinstimmt. Daher kann die Kommunikationsstruktur auch als zu erreichender Zielzustand betrachtet werden. Mit Hilfe von Fortschreibungsregeln wird bestimmt, wie die Daten aus der Kommunikationsstruktur in das Datenziel geladen werden sollen. Besonders wenn nur ein Teil der Daten für ein Datenziel in Frage kommt, erfolgt die Verteilung über Fortschreibungsregeln. Fortschreibungsregeln kommen aber auch zum Einsatz, wenn Daten von einem Datenziel in ein anderes übertragen werden sollen. In der Stammdatenbeschaffung, bei der Fortschreibungsregeln nicht eingesetzt werden müssen, erstellt das System bereits einen Vorschlag zur Transferstruktur. Entsprechend den in der Datenmodellierung getroffenen Selektionen muss die Datenquelle der Sprachabhängigkeit wegen über ein Sprachkennzeichen verfügen. Außerdem hat sie einen Merkmalsschlüssel und einen entsprechenden Langtext zu enthalten. Durch die Auswahl einer geeigneten DataSource wird auch die Übertragung der Stammdaten für Attribute in der InfoSource definiert.

4.2 Teil II – Datenbeschaffung

139

Die für den eigentlichen Ladevorgang benötigten Informationen sind in InfoPackages zusammengefasst. Für jede Kombination von DataSource und InfoSource wird ein InfoPackage erstellt. Darin wird die Datenquelle bestimmt und der Lesevorgang über Parameter wie zum Beispiel das Tausendertrennzeichen an die Anforderungen angepasst. Im InfoPackage ist auch eine Vorschau und Simulation des Ladens der Daten möglich. Dadurch können Fehler in den Daten oder in den getroffenen Einstellungen frühzeitig erkannt werden. Außerdem bietet sich die Möglichkeit, die Verarbeitung der Daten in den einzelnen Stadien des ETL-Prozesses nachzuvollziehen. Im InfoPackage kann festgelegt werden, ob die Daten zunächst in die PSA oder direkt in das Datenziel fortgeschrieben werden sollen. Dieses Vorgehen kann einen höheren Ressourcenbedarf zur Folge haben und birgt das Risiko des Datenverlustes im Falle einer fehlerhaften Fortschreibung. Für das Laden von wenigen Stammdaten wie in der Fallstudie ist diese Methode nicht als kritisch anzusehen, zudem wird so der Datenbestand in der PSA gering gehalten. Die Definition der InfoSource für Bewegungsdaten ähnelt den Einstellungen zur Stammdatenbeschaffung, erfordert jedoch die manuelle Anordnung der Datenfelder in der Transferstruktur. Außerdem werden die Daten zunächst in die PSA geschrieben und erst im Anschluss in die Datenziele verbucht. Dadurch kann die SAP BW-interne Übertragung der Daten bei Bedarf wiederholt werden, ohne dass ein erneutes Laden aus dem Quellsystem erforderlich wäre. Anders als Stammdaten werden Bewegungsdaten unter der Verwendung von Fortschreibungsregeln in das Datenziel geladen. Eine Transformation der Daten findet an dieser Stelle nicht statt, da alle Daten in den InfoCube übertragen werden sollen. Stammdaten können auch manuell im System hinterlegt werden. Beim InfoObject Land wird eine entsprechende Tabelle im SAP BW editiert. Dazu werden der Merkmalsschlüssel und der Langtext eingetragen, der Sprachschlüssel ist bereits durch die Anmeldesprache vorgegeben. Die Hierarchie wird in einem SAP BW-internen Editor modelliert. Dieser erlaubt das Anlegen von Textknoten, die nur über einen technischen Namen und eine Bezeichnung verfügen und zur Strukturierung einer Hierarchie eingesetzt werden. Außerdem können fremde Merkmalsknoten in die Hierarchie aufgenommen werden, die zwar ebenfalls der Strukturierung dienen, aber im Gegensatz zu Textknoten ihre Werte zentral über das Merkmal beziehen, so dass sich Veränderungen am Merkmal unmittelbar auf die Hierarchie auswirken. Bebuchbare Knoten sind diejenigen Ausprägungen des Merkmals, für das eine Hierarchie angelegt wird. Sie bilden in der Regel die Blätter in einer hierarchischen Struktur. In der Fallstudie beschränkt man sich auf die Merkmalswerte des InfoObjects Land. Diese werden unterhalb des Textknotens für Europa angeordnet, so dass im Reporting die Hierarchie an den Knoten Welt und Europa aufgeklappt werden kann. Auf unterster Ebene zeigen sich die entsprechenden Texte der Merkmalswerte des InfoObjects Land. Das Merkmal Land ist den Einstellungen nach ein Geomerkmal. Das bedeutet, dass es auf einer Landkarte darstellbar ist. Um dem SAP BW die geografischen Daten zu diesem Merkmal verfügbar zu machen, werden diese aus einem Merkmal des SAP Business Content in Form von speziellen Dateien exportiert und anschließend für das Merkmal Land importiert.

140

4 Fallstudie I – Ist-Daten-Analyse

4.2.1 Anlegen der InfoSources Markieren Sie in durch einen Linksklick die Anwendungskomponente zur Fallstudie im Menüpunkt InfoSources des Navigationsbereiches der Administrator Workbench (siehe Abb. 4.24. Anwendungskomponente, Schritt 1). Öffnen Sie durch einen Rechtsklick auf die Ihnen zugewiesene Anwendungskomponente das kontextsensitive Menü (siehe Abb. 4.24. Anwendungskomponente, Schritt 2) und wählen Sie Anlegen... aus (siehe Abb. 4.24. Anwendungskomponente, Schritt 3). Geben Sie als Anwendungskomp. A_AK_### und als Beschreibung lang Fallstudie BW ### an (siehe Abb. 4.24. Anwendungskomponente, Schritt 4). Schließen Sie den Dialog über Weiter (siehe Abb. 4.24. Anwendungskomponente, Schritt 5).

Abb. 4.24. Anwendungskomponente

Klicken Sie nun mit der rechten Maustaste auf die eben erstellte Anwendungskomponente ZA_AK_### (siehe Abb. 4.25. InfoSource anlegen, Schritt 1) und wählen Sie den Menüpunkt InfoSource anlegen... (siehe Abb. 4.25. InfoSource anlegen, Schritt 2). Wählen Sie Direkte Forschreibung von Stammdaten (siehe Abb. 4.25. InfoSource anlegen, Schritt 3) und als InfoObject A_MPH_### (siehe Abb. 4.25. InfoSource anlegen, Schritt 4). Übernehmen Sie die Angaben mit Übernehmen (siehe Abb. 4.25. InfoSource anlegen, Schritt 5) und bestätigen Sie das nächste Popup mit Weiter.

4.2 Teil II – Datenbeschaffung

141

Abb. 4.25. InfoSource anlegen

Aktualisieren Sie den Baum (siehe Abb. 4.26. DataSource zuweisen, Schritt 1) und wählen Sie im Kontextmenü der InfoSource Produkthauptgruppe ### (siehe Abb. 4.26. DataSource zuweisen, Schritt 2) den Eintrag DataSource zuweisen... (siehe Abb. 4.26. DataSource zuweisen, Schritt 3), anschließend wählen Sie im Dialog Stammdaten-InfoSource: Quellsystem zuweisen als Quellsystem A_QS_FSBW (siehe Abb. 4.26. DataSource zuweisen, Schritt 4) und klicken auf Übernehmen (siehe Abb. 4.26. DataSource zuweisen, Schritt 5).

142

4 Fallstudie I – Ist-Daten-Analyse

Abb. 4.26. DataSource zuweisen

Das darauf folgende Popup Änderungen sichern? mit dem Hinweis zum Sichern der Zuweisung bestätigen Sie mit Ja (siehe Abb. 4.26. DataSource zuweisen, Schritt 6) und gelangen in die Maske InfoSource A_MPH_### ändern, in der bereits der Bereich Transferstruktur / Übertragungsregeln aufgeklappt ist. Stellen Sie sicher, dass als Quellsystem das A_QS_FSBW – Externe Daten Fallstudie BW und als DataSource der Eintrag A_MPH_###_TEXT – Produkthauptgruppe (Texte) selektiert sind. Wechseln Sie in den Kartenreiter DataSource/Transferstruktur (siehe Abb. 4.27. InfoSource aktivieren, Schritt 1) und setzen Sie einen Haken in der Spalte Selektion für das InfoObject 0LANGU (siehe Abb. 4.27. InfoSource aktivieren, Schritt 2). Aktivieren Sie die InfoSource (siehe Abb. 4.27. InfoSource aktivieren, Schritt 3) und verlassen Sie den Bildschirm mit Beenden.

4.2 Teil II – Datenbeschaffung

143

Abb. 4.27. InfoSource aktivieren

4.2.2 Einlesen von Stammdaten aus Flat Files In der Sicht InfoSources der Administrator Workbench befindet sich unterhalb der InfoSource Produkthauptgruppe ### nun ein Knoten mit dem Namen der zugewiesenen DataSource (siehe Abb. 4.28. InfoPackage anlegen, Schritt 1). Wählen Sie diesen Knoten mit der rechten Maustaste an und selektieren Sie den Menüpunkt InfoPackage anlegen... (siehe Abb. 4.28. InfoPackage anlegen, Schritt 2). Im Pflegedialog vergeben Sie die InfoPackage-Bezeichnung A_IPPH_###_Text (siehe Abb. 4.28. InfoPackage anlegen, Schritt 3) und markieren in der Tabelle DataSource die Zeile Produkthauptgruppe ### (Texte) (siehe Abb. 4.28. InfoPackage anlegen, Schritt 4). Speichern Sie das InfoPackage mit Sichern (siehe Abb. 4.28. InfoPackage anlegen, Schritt 5).

144

4 Fallstudie I – Ist-Daten-Analyse

Abb. 4.28. InfoPackage anlegen

Im Scheduler (InfoPackage pflegen) wechseln Sie in den Kartenreiter Fremddaten (siehe Abb. 4.29. InfoPackage pflegen 1, Schritt 1). Dort wählen Sie unter Name der Datei das Flat File Produkthauptgruppe_Text.csv aus (siehe Abb. 4.29. InfoPackage pflegen 1, Schritt 2). Setzen Sie den Dateityp auf CSV-Datei (siehe Abb. 4.29. InfoPackage pflegen 1, Schritt 3) und geben Sie die Anzahl der zu ignorierenden Kopfzeilen mit 1 an (siehe Abb. 4.29. InfoPackage pflegen 1, Schritt 4). Starten Sie anschließend die Vorschau (siehe Abb. 4.29. InfoPackage pflegen 1, Schritt 5) und bestätigen Sie den Dialog Parameter für Vorschau mit Ausführen (siehe Abb. 4.29. InfoPackage pflegen 1, Schritt 6).

4.2 Teil II – Datenbeschaffung

145

Abb. 4.29. InfoPackage pflegen 1

Die Vorschau für Datei-Upload wird angezeigt, in der Sie kontrollieren, ob die Struktur der Daten korrekt ist (siehe Abb. 4.30. Vorschau Datei Upload). Wenn Sie die Vorschau ausreichend studiert haben, schließen Sie das Fenster mit Weiter (siehe Abb. 4.30. Vorschau Datei Upload, Schritt 1).

146

4 Fallstudie I – Ist-Daten-Analyse

Abb. 4.30. Vorschau Datei Upload

Wechseln Sie im Scheduler zum Register Verarbeitung und selektieren Sie unter Daten verbuchen... den Eintrag Nur InfoObject (siehe Abb. 4.31. InfoPackage pflegen 2, Schritt 1). Im letzten Kartenreiter Einplanen (siehe Abb. 4.31. InfoPackage pflegen 2, Schritt 2) betätigen Sie die Schaltfläche Start (siehe Abb. 4.31. InfoPackage pflegen 2, Schritt 3), um das Laden der Daten zu beginnen. Mit Klick auf das Symbol Monitor kontrollieren Sie den Status des Vorgangs, dieser sollte erfolgreich abgeschlossen sein (siehe Abb. 4.31. InfoPackage pflegen 2, Schritt 4).

4.2 Teil II – Datenbeschaffung

147

Abb. 4.31. InfoPackage pflegen 2

Klicken Sie sich durch die Kartenreiter Kopf, Status und Detail um weitere Informationen über den Vorgang zu erhalten. Verlassen Sie die Ansicht über zweimal Beenden. Die korrekt modellierte InfoSource mit InfoPackage sehen Sie in Abb. 4.32. Korrekt modellierte InfoSource und InfoPackage.

148

4 Fallstudie I – Ist-Daten-Analyse

Abb. 4.32. Korrekt modellierte InfoSource und InfoPackage

Legen Sie analog die InfoSource für das InfoObject A_MPG_### in Ihrer Anwendungskomponente Fallstudie BW ### in der Administrator Workbench an. Im Kontextmenü zur InfoSource Produktgruppe ### wählen Sie den Eintrag DataSource zuweisen..., anschließend selektieren Sie im Dialog Stammdaten-InfoSource: Quellsystem zuweisen als Quellsystem A_QS_FSBW und klicken auf Übernehmen. Diesmal folgen zwei Popups Änderungen sichern? mit dem Hinweis zum Sichern der Zuweisung von Attributen und Texten, beide bestätigen Sie mit Ja. Sie gelangen in die Maske InfoSource A_MPG_### ändern, in der bereits der Bereich Transferstruktur / Übertragungsregeln aufgeklappt ist. Stellen Sie sicher, dass als Quellsystem das A_QS_FSBW – Externe Daten Fallstudie BW und als DataSource der Eintrag A_MPG_###_ATTR – Produktgruppe (Stammdaten) (siehe Abb. 4.33. InfoSource Produktgruppe ändern 1, Schritt 1) selektiert sind und Aktivieren Sie die InfoSource (siehe Abb. 4.33. InfoSource Produktgruppe ändern 1, Schritt 2).

4.2 Teil II – Datenbeschaffung

149

Abb. 4.33. InfoSource Produktgruppe ändern 1

Stellen Sie nun als DataSource A_MPG_###_TEXT - Produktgruppe (Texte) ein (siehe Abb. 4.34. InfoSource Produktgruppe ändern 2, Schritt 1) und wechseln Sie anschließend in den Kartenreiter DataSource/Transferstruktur, in welchem Sie einen Haken in der Spalte Selektion für das InfoObject 0LANGU setzen (siehe Abb. 4.34. InfoSource Produktgruppe ändern 2, Schritt 2). Aktivieren Sie die InfoSource erneut (siehe Abb. 4.34. InfoSource Produktgruppe ändern 2, Schritt 3) und schließen Sie den Dialog mit Beenden.

150

4 Fallstudie I – Ist-Daten-Analyse

Abb. 4.34. InfoSource Produktgruppe ändern 2

Unterhalb der InfoSource befindet sich nun ein Knoten mit dem Namen der zugewiesenen DataSource. Wählen Sie diesen Knoten mit der rechten Maustaste an (siehe Abb. 4.35. InfoPackage Produktgruppe anlegen, Schritt 1) und selektieren Sie den Menüpunkt InfoPackage anlegen... (siehe Abb. 4.35. InfoPackage Produktgruppe anlegen, Schritt 2). Im Pflegedialog vergeben Sie die InfoPackageBezeichnung A_IPPG_###_Text (siehe Abb. 4.35. InfoPackage Produktgruppe anlegen, Schritt 3) und markieren die Zeile Produktgruppe ### (Texte) (siehe Abb. 4.35. InfoPackage Produktgruppe anlegen, Schritt 4). Speichern Sie das InfoPackage mit Sichern (siehe Abb. 4.35. InfoPackage Produktgruppe anlegen, Schritt 5).

4.2 Teil II – Datenbeschaffung

151

Abb. 4.35. InfoPackage Produktgruppe anlegen

Im Scheduler (InfoPackage pflegen) wechseln Sie in den Kartenreiter Fremddaten. Dort wählen Sie unter Name der Datei das Flat File Produktgruppe_Text.csv aus. Setzen Sie den Dateityp auf CSV-Datei und geben Sie die Anzahl der zu ignorierenden Kopfzeilen mit 1 an. Starten Sie anschließend die Vorschau und bestätigen Sie den Dialog Parameter für Vorschau mit Ausführen. Die Vorschau für Datei-Upload wird angezeigt, in der Sie kontrollieren, ob die Struktur der Daten korrekt ist. Wenn Sie die Vorschau ausreichend studiert haben, schließen Sie das Fenster mit Weiter. Hinweis: Ist die Schaltfläche Vorschau deaktiviert, so stellen Sie sicher, dass die Übertragungsregeln korrekt angelegt worden sind. Wechseln Sie im Scheduler zum Register Verarbeitung und selektieren Sie unter Daten verbuchen... den Eintrag Nur InfoObject. Im letzten Kartenreiter Einplanen betätigen Sie die Schaltfläche Start, um das Laden der Daten zu beginnen. Mit Klick auf das Symbol Monitor kontrollieren Sie den Status des Vorgangs, dieser sollte erfolgreich abgeschlossen sein. Verlassen Sie die Ansicht über zweimal Beenden. Legen Sie für dieselbe InfoSource wie zuvor ein weiteres InfoPackage mit der Bezeichnung A_IPPG_###_Attr an und markieren Sie die Zeile Produktgruppe ### (Stammdaten). Speichern Sie das InfoPackage mit Sichern. Im Scheduler (InfoPackage pflegen) wechseln Sie in den Kartenreiter Fremddaten. Dort wählen Sie unter Name der Datei das Flat File Produktgruppe_Attr.csv aus.

152

4 Fallstudie I – Ist-Daten-Analyse

Setzen Sie den Dateityp auf CSV-Datei und geben Sie die Anzahl der zu ignorierenden Kopfzeilen mit 1 an. Starten Sie anschließend die Vorschau und bestätigen Sie den Dialog Parameter für Vorschau mit Ausführen. Dieses Mal haben Sie die Möglichkeit, das Stammdatenladen zu simulieren, da in beiden betroffenen InfoObjects nun auch Stammdatentexte vorhanden sind. Wählen Sie in der Vorschau für Datei-Upload die Simulation und betrachten Sie im Bildschirm Simulation Stammdatenupdate : Merkmal : A_MPG_### die Kommunikationsstruktur (siehe Abb. 4.36. Simulation Datei Upload, Schritt 1). Öffnen Sie den Baum auf der linken Seite vollständig (siehe Abb. 4.36. Simulation Datei Upload, Schritt 2) und klicken sie doppelt auf den letzen Knoten Einfügen in /BIC/XA_MPG_### (siehe Abb. 4.36. Simulation Datei Upload, Schritt 3). Im rechten Bildschirmelement mit der Überschrift Kommunikationsstruktur wird der Aufbau der Tabellen verdeutlicht, beachten Sie besonders die SID Spalten. Sie können erkennen, dass auf die Produkthauptgruppe mit der letzten SID-Spalte verwiesen wird, da die Einträge der letzten beiden Zeilen identisch sind. Verlassen Sie das Fenster mit Zurück. Es erscheint ein Popup mit einer Nachricht vom Monitor über das Ende des Prozesses. Schließen Sie dieses und beenden Sie danach die Vorschau für Datei-Upload mit Weiter (siehe Abb. 4.36. Simulation Datei Upload, Schritt 4).

4.2 Teil II – Datenbeschaffung

153

Abb. 4.36. Simulation Datei Upload

Wechseln Sie im Scheduler zum Register Verarbeitung und selektieren Sie unter Daten verbuchen... den Eintrag Nur InfoObject. Im letzten Kartenreiter Einplanen betätigen Sie die Schaltfläche Start, um das Laden der Daten zu beginnen. Schließen Sie die Nachricht vom Monitor und kontrollieren Sie mit Klick auf das Symbol Monitor den Status des Vorgangs, dieser sollte erfolgreich abgeschlossen sein. Verlassen Sie die Ansicht über zweimal Beenden und kehren so zur Administrator Workbench zurück. Überprüfen Sie in der Sicht InfoSources die Stammdateneinträge durch Stammdaten pflegen im Kontextmenü der Produktgruppe ### (siehe Abb. 4.37. Stammdaten pflegen, Schritt 1 und Schritt 2) und anschließendes Betätigen der Schaltfläche Ausführen (siehe Abb. 4.37. Stammdaten pflegen, Schritt 3). Wenn Sie diese Ansicht mit der aus der Vorschau vergleichen, so erkennen Sie, dass hier keine SID-Einträge dargestellt werden, sondern die Verknüpfung zwischen den beiden InfoObjects Produktgruppe und Produkthauptgruppe verständlicher abgebildet wird. Verlassen Sie diese Ansicht mittels zweimal Beenden.

154

4 Fallstudie I – Ist-Daten-Analyse

Abb. 4.37. Stammdaten pflegen

4.2.3 Manuelle Pflege der Stammdaten Für das Merkmal Land werden Sie die Stammdaten manuell pflegen. Wechseln Sie zurück in den Baum InfoObjects (siehe Abb. 4.38. Stammdaten manuell pflegen 1, Schritt 1) und öffnen Sie mit einem Rechtsklick das kontextsensitive Menü zu Land ### (siehe Abb. 4.38. Stammdaten manuell pflegen 1, Schritt 2) und führen Sie die Funktion Stammdaten pflegen aus (siehe Abb. 4.38. Stammdaten manuell pflegen 1, Schritt 3). Im Bildschirm Merkmal A_ML_### Stammdaten pflegen: Selektion wählen Sie Ausführen (siehe Abb. 4.38. Stammdaten manuell pflegen 1, Schritt 4).

4.2 Teil II – Datenbeschaffung

155

Abb. 4.38. Stammdaten manuell pflegen 1

Sie gelangen in die Pflegemaske Merkmal A_ML_### - Stammdaten pflegen: Liste. Über die Schaltfläche Anlegen wird ein Dialogfenster geöffnet (siehe Abb. 4.39. Stammdaten manuell pflegen 2, Schritt 1), in dem Sie unter Land DE (siehe Abb. 4.39. Stammdaten manuell pflegen 2, Schritt 2) und unter Beschreibung lang Deutschland eintragen (siehe Abb. 4.39. Stammdaten manuell pflegen 2, Schritt 3). Bestätigen Sie Ihre Eingaben mit Weiter (siehe Abb. 4.39. Stammdaten manuell pflegen 2, Schritt 4). Analog legen Sie die Ländercodes DK (Dänemark) und NL (Niederlande) an (siehe Abb. 4.39. Stammdaten manuell pflegen 2, Schritt 5). Speichern Sie die Einträge durch Sichern (siehe Abb. 4.39. Stammdaten manuell pflegen 2, Schritt 6) und verlassen Sie den Bildschirm durch zweimaliges Betätigen der Schaltfläche Zurück.

156

4 Fallstudie I – Ist-Daten-Analyse

Abb. 4.39. Stammdaten manuell pflegen 2

Das Merkmal Land soll über eine externe Hierarchie verfügen. Dazu wählen Sie aus dem Kontextmenü diesmal den Eintrag Hierarchie anlegen... (siehe Abb. 4.40. Hierarchie anlegen, Schritte 1 bis 3) und vergeben im Pflegedialog Hierarchie anlegen den Hierarchienamen A_HL_### (siehe Abb. 4.40. Hierarchie anlegen, Schritt 4). Tragen Sie als Beschreibung kurz Hierarchie Land ### ein (siehe Abb. 4.40. Hierarchie anlegen, Schritt 5) und schließen Sie das Fenster mit Weiter (siehe Abb. 4.40. Hierarchie anlegen, Schritt 6).

4.2 Teil II – Datenbeschaffung

157

Abb. 4.40. Hierarchie anlegen

Im folgenden Bildschirm Hierarchie ‘Hierarchie Land ###’ ändern: ‘Modifizierte Version’ legen Sie über die Schaltfläche Textknoten (siehe Abb. 4.41. Hierarchie ändern 1, Schritt 1) einen neuen Hierarchieknoten A_HKW_### mit der Kurzbeschreibung Welt an (siehe Abb. 4.41. Hierarchie ändern 1, Schritt 2). Bestätigen Sie mit Weiter (siehe Abb. 4.41. Hierarchie ändern 1, Schritt 3). Markieren Sie anschließend den eben erstellten Knoten Welt mit der linken Maustaste (siehe Abb. 4.41. Hierarchie ändern 1, Schritt 4).

158

4 Fallstudie I – Ist-Daten-Analyse

Abb. 4.41. Hierarchie ändern 1

Betätigen Sie erneut die Schaltfläche Textknoten (siehe Abb. 4.41. Hierarchie ändern 1, Schritt 5) und definieren Sie einen neuen Knoten A_HKK_### mit der Kurzbeschreibung Europa. Schließen Sie auch dieses Fenster über Weiter und markieren Sie wiederum den zuletzt erstellten Knoten Europa. Über die Schaltfläche ‘Land’ öffnen Sie den Pflegedialog Land anlegen: Mehrfachauswahl (siehe Abb. 4.42. Hierarchie ändern 2, Schritt 1). Setzen Sie die Häkchen vor den zuvor angelegten Ländern DE, DK und NL (siehe Abb. 4.42. Hierarchie ändern 2, Schritt 2) und ordnen Sie die Länder mittels Übernehmen in die Hierarchiestruktur ein (siehe Abb. 4.42. Hierarchie ändern 2, Schritt 3). Führen Sie die Hierarchie Konsistenzprüfung durch und drücken Sie Hierarchie aktivieren (siehe Abb. 4.42. Hierarchie ändern 2, Schritt 4).

4.2 Teil II – Datenbeschaffung

159

Abb. 4.42. Hierarchie ändern 2

Beenden Sie die Eingabe über Zurück und wählen Sie in der Administrator Workbench die Schaltfläche Baum aktualisieren. Nun sollte die angelegte Hierarchie im InfoObject-Baum enthalten sein. 4.2.4 Pflege der Shape Files für die Kartendarstellung Da das Merkmal Land als Geomerkmal angelegt wurde, muss zusätzlich eine Verbindung zwischen den Merkmalsausprägungen und der geographischen Darstellung in Landkarten hergestellt werden. Es soll das mit dem BW gelieferte Kartenmaterial verwendet werden, dazu ist es notwendig, die BW Stammdaten als dBase Datei in Ihr lokales SAPWorkDirectory zu laden. Öffnen Sie aus der Administrator Workbench über die Schaltfläche Neuen Modus erzeugen ein weiteres Fenster und rufen Sie die Transaktion RSD1 auf. Tragen Sie als InfoObject 0D_COUNTRY ein (siehe Abb. 4.43. Shape Files exportieren 1, Schritt 1) und wählen Sie Anzeigen (siehe Abb. 4.43. Shape Files exportieren 1, Schritt 2). Wechseln Sie in die Registerkarte Business Explorer und klicken Sie auf Shape Files anzeigen im Bereich BexMap (siehe Abb. 4.43. Shape Files exportieren 1, Schritt 3).

160

4 Fallstudie I – Ist-Daten-Analyse

Abb. 4.43. Shape Files exportieren 1

Expandieren Sie in der folgenden Bildschirmmaske Business Document Navigator den Baum BW Meta Objekte vollständig (siehe Abb. 4.44. Shape Files exportieren 2, Schritt 1) und setzen Sie das Häkchen beim neuesten Eintrag im Bereich BW_GIS_DBF (siehe Abb. 4.44. Shape Files exportieren 2, Schritt 2). Klicken Sie auf die Schaltfläche Dokument exportieren (siehe Abb. 4.44. Shape Files exportieren 2, Schritt 3) und bestätigen Sie das vorgeschlagene Zielverzeichnis mit Weiter (siehe Abb. 4.44. Shape Files exportieren 2, Schritt 4). Es erscheint ein Popup mit der Nachricht, dass das Dokument erfolgreich exportiert wurde, welches Sie mit Weiter schließen (siehe Abb. 4.44. Shape Files exportieren 2, Schritt 5).

4.2 Teil II – Datenbeschaffung

161

Abb. 4.44. Shape Files exportieren 2

Exportieren Sie anschließend auf dieselbe Weise nacheinander die zugehörige SHP-Datei und SHX-Datei. Schließen Sie nun diesen zweiten Modus wieder und kehren Sie in das Fenster mit der geöffneten Administrator Workbench zurück. Navigieren Sie in Ihrer InfoArea Fallstudie BW ### zum InfoObject A_ML_### und öffnen Sie den dazugehörigen Pflegebildschirm mit einem Doppelklick auf das Objekt. Wechseln Sie in den Kartenreiter Business Explorer, klicken Sie auf Shape Files hochladen (siehe Abb. 4.45. Upload der Shape Files, Schritt 1), selektieren Sie die zuvor gesicherte SHP-Datei aus Ihrem SAPWorkDirectory (siehe Abb. 4.45. Upload der Shape Files, Schritt 2) und drücken Sie Öffnen (siehe Abb. 4.45. Upload der Shape Files, Schritt 3). Schließen Sie den folgenden Dialog Business Document Service mit Weiter (siehe Abb. 4.45. Upload der Shape Files, Schritt 4).

162

4 Fallstudie I – Ist-Daten-Analyse

Abb. 4.45. Upload der Shape Files

Nachfolgend werden die DBF-Datei und die SHX-Datei auf dieselbe Weise ausgewählt. Die Geomerkmale sind nun eingepflegt und stehen im Reporting zur Verfügung. Klicken Sie auf Beenden. 4.2.5 Einlesen der Bewegungsdaten Wählen Sie im Navigationsmenü der Administrator Workbench den Bereich InfoSources. Rechtsklicken Sie auf den Knoten Ihrer Anwendungskomponente ZA_AK_### und selektieren Sie im kontextsensitiven Menü InfoSource anlegen..... Achten Sie darauf, dass Flexible Fortschreibung in beliebige Datenziele (außer Hierarchien) aktiviert ist (siehe Abb. 4.46. InfoSource zum InfoCube anlegen, Schritt 1). Vergeben Sie als technischen Namen der InfoSource zu Ihrem InfoCube A_ISI_### und tragen Sie als Beschreibung lang Ist-Daten Fallstudie BW ### ein (siehe Abb. 4.46. InfoSource zum InfoCube anlegen, Schritt 2). Bestätigen Sie mit Übernehmen (siehe Abb. 4.46. InfoSource zum InfoCube anlegen, Schritt 3). Weisen Sie der angelegten InfoSource A_ISI_### (siehe Abb. 4.46. InfoSource zum InfoCube anlegen, Schritt 4) über das Kontextmenü eine DataSource zu (siehe Abb. 4.46. InfoSource zum InfoCube anlegen, Schritt 5). Im nachfolgenden Popup tragen Sie als Quellsystem A_QS_FSBW ein und Übernehmen die Einstellungen (siehe Abb. 4.46. InfoSource zum InfoCube anlegen, Schritt 6 und Schritt 7), Hinweismeldungen zur Sicherung bestätigen Sie mit Ja.

4.2 Teil II – Datenbeschaffung

163

Abb. 4.46. InfoSource zum InfoCube anlegen

Sie gelangen in den Pflegedialog InfoSource A_ISI_### ändern. Im Kartenreiter DataSource/Transferstruktur ist nun die Struktur der CSV-Datei zu hinterlegen. Tragen Sie in der Spalte InfoObject nacheinander die InfoObjects A_MPG_###, A_ML_###, 0CALQUARTER und A_KU_### ein (siehe Abb. 4.47. InfoSource zum InfoCube ändern 1, Schritt 1 und Schritt 2).

164

4 Fallstudie I – Ist-Daten-Analyse

Abb. 4.47. InfoSource zum InfoCube ändern 1

Verzweigen Sie in die Registerkarte Übertragungsregeln und bestätigen Sie die Hinweismeldung zum InfoObject 0CURRENCY mit Weiter (siehe Abb. 4.47. InfoSource zum InfoCube ändern 1, Schritt 3). Betätigen Sie anschließend die Schaltfläche Übertragungsregeln vorschlagen (siehe Abb. 4.48. InfoSource zum InfoCube ändern 2, Schritt 1), es werden fünf Übertragungsregeln in der Tabelle Kommunikationsstr./Übertragungsregeln angezeigt (siehe Abb. 4.48. InfoSource zum InfoCube ändern 2, Schritt 2). Aktivieren Sie die InfoSource (siehe Abb. 4.48. InfoSource zum InfoCube ändern 2, Schritt 3) und verlassen Sie den Bereich mit Beenden.

4.2 Teil II – Datenbeschaffung

165

Abb. 4.48. InfoSource zum InfoCube ändern 2

Wechseln Sie im Navigationsmenü der Administrator Workbench in den Bereich InfoProvider (siehe Abb. 4.49. Fortschreibungsregeln anlegen, Schritt 1). Klappen Sie den Knoten Ihrer InfoArea A_IA_### auf und selektieren Sie im Kontextmenü des InfoCubes A_ICI_### (siehe Abb. 4.49. Fortschreibungsregeln anlegen, Schritt 2) Fortschreibungsregeln anlegen (siehe Abb. 4.49. Fortschreibungsregeln anlegen, Schritt 3). Selektieren Sie als Datenquelle Ihre InfoSource A_ISI_### (siehe Abb. 4.49. Fortschreibungsregeln anlegen, Schritt 4). Durch Klicken auf Prüfen (siehe Abb. 4.49. Fortschreibungsregeln anlegen, Schritt 5) erzeugt das System einen Vorschlag zu den Fortschreibungsregeln, dieses wird in der Statuszeile vermeldet. Öffnen Sie über die Schaltfläche Nächstes Bild die Maske Fortschreibungsregeln anlegen: Regeln (siehe Abb. 4.49. Fortschreibungsregeln anlegen, Schritt 5). Hier Prüfen und Aktivieren Sie die Fortschreibungsregeln (siehe Abb. 4.49. Fortschreibungsregeln anlegen, Schritt 6). Kehren Sie mittels Beenden zur Administrator Workbench zurück.

166

4 Fallstudie I – Ist-Daten-Analyse

Abb. 4.49. Fortschreibungsregeln anlegen

Jetzt können die Bewegungsdaten hochgeladen werden. Legen Sie dazu zunächst im Bereich InfoSources unter der InfoSource A_ISI_### zum Quellsystem A_QS_FSBW ein InfoPackage an. Benennen Sie es mit A_IPI_### und markieren Sie in der Tabelle DataSource die Zeile mit dem technischen Namen A_ISI_###. Sichern Sie die Selektion. Es folgt der Bildschirm Scheduler (InfoPackage pflegen). Wechseln Sie in den Kartenreiter Fremddaten. Geben Sie als Name der Datei Daten_Ist.csv an, markieren Sie den zugehörigen Dateityp und setzen Sie die Anzahl der zu ignorierenden Kopfzeilen auf 1. Kontrollieren Sie über die Vor-

4.2 Teil II – Datenbeschaffung

167

schau, ob die Struktur der Daten korrekt ist. Sie sollte wie in Abb. 4.50. Vorschau und Simulation zum Befüllen des InfoCubes dargestellt werden. Führen Sie auch in der Vorschau für Datei-Upload die Simulation aus (siehe Abb. 4.50. Vorschau und Simulation zum Befüllen des InfoCubes, Schritt 1). Sie haben hier nun die Möglichkeit, neben dem Zustand nach der Übertragung der Daten auch das Format der Daten nach der Kommunikationsstruktur und im InfoCube zu studieren, indem Sie für die erstere Sicht die Schaltfläche Kommunikationsstruktur (siehe Abb. 4.50. Vorschau und Simulation zum Befüllen des InfoCubes, Schritt 2) und für die letztere Datenziel anklicken (siehe Abb. 4.50. Vorschau und Simulation zum Befüllen des InfoCubes, Schritt 3). Verlassen Sie über Zurück die Übersicht (siehe Abb. 4.50. Vorschau und Simulation zum Befüllen des InfoCubes, Schritt 4) und beenden Sie die Vorschau für Datei-Upload mit Weiter (siehe Abb. 4.50. Vorschau und Simulation zum Befüllen des InfoCubes, Schritt 5).

Abb. 4.50. Vorschau und Simulation zum Befüllen des InfoCubes

Sie erhalten daraufhin die Benachrichtigung vom Monitor, dass die Verarbeitung des Vorgangs erfolgreich beendet wurde. Schließen Sie die Meldung und die Vorschau für Datei-Upload. Importieren Sie die Daten über die Schaltfläche Start im Register Einplanen (siehe Abb. 4.51. Starten des Datei Uploads, Schritt 1). Schließen Sie das öffnende Popup (siehe Abb. 4.51. Starten des Datei Uploads,

168

4 Fallstudie I – Ist-Daten-Analyse

Schritt 2) und kontrollieren Sie den Status im Monitor (siehe Abb. 4.51. Starten des Datei Uploads, Schritt 3).

Abb. 4.51. Starten des Datei Uploads

Die Verbuchung sollte wie in Abb. 4.52. Abgeschlossene Verbuchung im Monitor korrekt beendet worden sein. Schließen Sie den Vorgang durch zweimaliges Beenden ab.

4.2 Teil II – Datenbeschaffung

Abb. 4.52. Abgeschlossene Verbuchung im Monitor

169

170

4 Fallstudie I – Ist-Daten-Analyse

Zusammenfassung: Der zweite Teil der ersten Fallstudie hat Sie mit der Datenbeschaffung aus flachen Dateien heraus vertraut gemacht. In der Anwendungskomponente A_AK_### haben Sie die InfoSources zu den InfoObjects Produkthauptgruppe ### und Produktgruppe ### angelegt und in diesen die DataSources für Texte gepflegt. Im Zuge dieser Einstellungen haben Sie außerdem das gegebene Quellsystem A_QS_FSBW an die DataSource angebunden sowie die Transferstruktur, die Übertragungsregeln und die Kommunikationsstruktur festgelegt. Für das Merkmal Produktgruppe ### haben Sie zusätzlich die DataSource für Attribute bearbeitet. Sie haben in den InfoPackages A_IPPH_###_Text und A_IPPG_###_Text den Ladevorgang der Stammdatentexte für Produkthauptgruppe ### wie auch für die Produktgruppe ### eingeplant und ausgeführt. Zusätzlich zu den Texten wurden zur Produktgruppe die Attribute im InfoPackage A_IPPG_###_Attr hochgeladen. Für das Merkmal Land ### haben Sie die Stammdatentexte und die Hierarchie A_HL_### manuell eingetragen. Für die Texte haben Sie den eindeutigen Länderschlüssel und die Bezeichnung vergeben. Die Hierarchie wurde von Ihnen beginnend mit dem Textknoten Welt über einen weiteren Knoten Europa bis hin zu den Merkmalsausprägungen Dänemark, Deutschland und Niederlande aufgebaut. Um das Merkmal Land ### später in einer Karte darstellen zu können, haben Sie unter Verwendung des SAP Business Content Shape Files in das System geladen. Schließlich haben Sie auch für den InfoCube A_ICI_### eine InfoSource angelegt, die den technischen Namen A_ISI_### trägt. Allerdings wurden für den InfoCube A_ICI_### anders als bei den InfoObjects zuvor auch Fortschreibungsregeln definiert. Abschließend haben Sie die Bewegungsdaten in die PSA des SAP BW geladen und in den InfoCube A_ICI_### fortgeschrieben.

4.3 Teil III – Reporting Nachdem das Datenmodell erstellt und das SAP BW mit Stamm- und Bewegungsdaten befüllt wurde, können die Queries für Analysen auf dem Datenbestand angelegt werden. Zu diesem Zweck wird im BEx Query Designer eine Query definiert, die ihre Daten aus dem mit Ist-Daten gefüllten InfoCube beziehen wird. Eine Query ist eine Datenbankanfrage, die eine Sicht auf den Datenbestand eines InfoProviders zur Verfügung stellt. Neben den im InfoProvider enthaltenen Kennzahlen und Merkmalen enthält das Query-Fenster je einen Bildbereich für Filter, freie Merkmale, Zeilen und Spalten. Filter schränken die Sicht auf bestimmte Merkmalsausprägungen ein. So kann bereits bei der Querydefinition festgelegt werden, dass zum Beispiel nur eine bestimmte Produktgruppe im Bericht erfasst wird. Freie Merkmale werden nicht von vornherein in einer Zeile oder Spalte angeordnet, sie können zur Laufzeit der Query durch den Anwender in die Navigation aufgenommen werden. Kennzahlen und Merkmale, die bei der Query-Definition in Zeilen

4.3 Teil III – Reporting

171

oder Spalten angeordnet wurden, können zur Laufzeit daraus entnommen und zu freien Merkmalen werden. Mit einer Query wird somit eine erste Sicht auf den Datenbestand gebildet und ein Rahmen für die Veränderungen dieser gesetzt. Das Merkmal Land ist in der Anfrage zur Fallstudie nicht nur Geomerkmal, sondern besitzt auch eine externe Hierarchie. Diese wird in der Query-Pflege für das Merkmal in den Eigenschaften frei geschaltet und selektiert. Damit steht sie als baumartige Menüstruktur beim Ausführen der Query zur Verfügung. Der BEx Analyzer ist eine Erweiterung zu MS Excel und ermöglicht die Verwendung einer im BEx Query Designer angelegten Query, indem der Analyzer mit dem SAP BW-System kommuniziert. Das Reporting wird komplett in MS Excel integriert, über Makros werden zum Beispiel Navigationsoperationen realisiert. Daher kann auch der Funktionsumfang von MS Excel genutzt werden, um Berichte zu vervollständigen. Die in der Query enthaltenen Kennzahlen und Merkmale werden in einer Gruppe aus Zeilen und Spalten im oberen Bereich der Query angeordnet. Über das Kontextmenü zu den Zellen können Navigationsoperationen ausgeführt werden, etwa das Anordnen eines freien Merkmals in Zeilen oder Spalten. In der darunter befindlichen Tabelle ist das Query Resultat entsprechend der Sicht aufgeführt. In den linken Spalten sowie den oberen Zeilen sind die Merkmale aufgeführt, wie sie in der Query-Definition angeordnet worden sind. Der Tabellenraum dazwischen wird mit den dazugehörigen Kennzahlen vervollständigt. Die Funktionen des BEx Analyzer erlauben unter anderem das Einfügen eines Diagramms und die Erstellung einer Karte. In der Datenmodellierung wurde hierzu das Merkmal Land als Geomerkmal hinterlegt und mit Shape Files befüllt. Wenn sich das Merkmal Land im Aufriss, also in der aktuell gültigen Sicht in Zeilen oder Spalten enthalten ist, können über die Karte die Kennzahlen zu den einzelnen Ländern grafisch ausgegeben werden. In einer Karte können auch weitere Merkmale durch verschiedene Diagrammtypen gleichzeitig abgebildet werden, so dass der Informationsgehalt zunimmt. Aus dem BEx Query Designer heraus kann die Query in einem Webbrowser ausgeführt werden. Hierzu wird vom System das Standard Web Template verwendet. Darin sind Funktionen und Objektreferenzen hinterlegt, die eine Vielzahl Funktionen und SAP BW-spezifische Webelemente zur Verfügung stellen. Das Standard Web Template bietet über die Werkzeugleiste mehr Möglichkeiten zur Navigation im Datenbestand als der BEx Analyzer und wird vor allem eingesetzt, um die definierte Query umgehend auf ihre Tauglichkeit und Korrektheit zu überprüfen. Das für die Navigation verwendete Objekt heißt generischer Navigationsblock und befindet sich im oberen Bereich der Webseite. Wie im BEx Analyzer sind hier alle in der Query enthaltenen Kennzahlen und Merkmale tabellarisch aufgeführt. Die Einträge und Symbole verfügen über ein Kontextmenü, dessen Funktionen die Navigation, aber auch den Export und den Zugriff auf hinterlegte Dokumente erlauben. Zudem kann der aktuelle Navigationszustand über den generischen Navigationsblock abgelesen werden. In der Tabelle unterhalb des bereits vorgestellten Bereichs befindet sich die Ergebnistabelle. Diese bildet wie auch die Tabelle im BEx Analyzer die Daten einer Sicht ab. Die Einträge verfügen ebenfalls über Kontextmenüs, die Operationen zur Navigation erlauben, aber auch Hinweise zu den Einstellungen der verwendeten

172

4 Fallstudie I – Ist-Daten-Analyse

Merkmale und Kennzahlen liefern. Über die Werkzeugleiste können statt der Ergebnistabelle auch Diagramme in der Webseite dargestellt werden. Je nach Diagrammtyp ist allerdings zu beachten, dass der zu Grunde liegende Navigationszustand das Diagrammverhalten beeinflusst. So muss für eine übersichtliche Darstellung oft der Aufriss modifiziert werden, da sonst die Anzahl der dargestellten Linien oder Balken schnell eine akzeptable Menge überschreitet. Über die Werkzeugleiste sind auch Filter erreichbar, die auf zur Laufzeit in der Query verwendete Merkmalswerte angewendet werden können. Man kann sie im Gegensatz zu den fest eingerichteten Filtern in der Query-Definition umgehend wieder entfernen. Im BEx Web Application Designer können individuell gestaltete Web Templates entwickelt werden. Grundlage eines Web Templates ist eine leere HTML-Seite, die mit SAP BW-spezifischen Objekten wie dem generischen Navigationsblock oder der Ergebnistabelle ausgestattet werden kann. Um eine an das Standard Web Template angelehnte Anordnung der SAP BW-Objekte zu erreichen, wird zunächst eine Grundstruktur aus HTML-Tabellen erstellt. In die Tabellenstruktur können anschließend die als Web Items bezeichneten SAP BWObjekte in Form eines Textfeldes, eines generischen Navigationsblocks und einer Ergebnistabelle eingefügt werden. Das Textfeld dient der Ausgabe von Texten und soll die Funktion einer Überschrift übernehmen. Über die Eigenschaften des Web Items werden individuelle Einstellungen vorgenommen, so soll bei der Betrachtung der Query die Überschrift der Bezeichnung der Query entsprechen und automatisch vom System bezogen werden. Die Funktionen des generischen Navigationsblockes und der Ergebnistabelle bleiben fast unverändert. Alle im Web Template eingesetzten Web Items werden ihre Daten aus der zuvor angelegen Query beziehen. Über die Auswahl des DataProviders wird die Verknüpfung zwischen Web Template und Datenbankanfrage hergestellt. Um eine Kartendarstellung zu ermöglichen, wird auf Basis des ersten Web Templates ein weiteres erstellt. Dadurch reduziert sich der Erstellungsaufwand, denn es muss nur das Diagramm entfernt und eine Karte hinzugefügt werden. Um in der Karte zur Laufzeit die Ansicht individuell verändern zu können, indem ein Kartenausschnitt verschoben oder vergrößert wird, erfolgt in den Eigenschaften die Pflege der erforderlichen Charakteristika. Weil die Karte zur korrekten Darstellung im Aufriss ein geosensitives Merkmal benötigt, eine neue Query wegen einer derart geringen Anpassung zu erstellen allerdings nicht sinnvoll ist, wird ein View auf die bestehende Query angelegt. Darin ist es möglich, das Merkmal Land aufzureißen und so die erforderliche Sicht auf die Daten zu generieren. Als DataProvider wird im Web Template eben dieser View eingesetzt. So muss beim Ausführen der Query nicht erst das Merkmal aufgerissen werden, um eine gültige Kartendarstellung zu erhalten. 4.3.1 Anlegen der Query Öffnen Sie über das Windows – Startmenü den Query Designer im Ordner Programme, Business Explorer. Melden Sie sich an Ihrem SAP BW System an und

4.3 Teil III – Reporting

173

erstellen Sie über die Schaltfläche Neue Query eine neue Query (siehe Abb. 4.53. Auswahl des InfoProvider im BEx Query Designer, Schritt 1). Betätigen Sie im Dialog Neue Query: InfoProvider auswählen die Schaltfläche InfoAreas (siehe Abb. 4.53. Auswahl des InfoProvider im BEx Query Designer, Schritt 2). Klappen Sie den InfoArea Baum zu Ihrer InfoArea Fallstudie BW ### auf und markieren Sie Ihren InfoCube Ist-Daten Fallstudie BW ###. Bestätigen Sie die Auswahl mit OK (siehe Abb. 4.53. Auswahl des InfoProvider im BEx Query Designer, Schritt 3).

Abb. 4.53. Auswahl des InfoProvider im BEx Query Designer

Klappen Sie im Bereich Ist-Daten Fallstudie BW ### den Teilbaum Kennzahl auf (siehe Abb. 4.54. Query anlegen, Schritt 1) und ziehen Sie per Drag & Drop die Kennzahl Umsatz in den Bereich Spalten (siehe Abb. 4.54. Query anlegen, Schritt 2). Dort wird diese automatisch der vom System erstellten Struktur Kennzahlen untergeordnet. Expandieren Sie die Teilbäume unter Dimensionen (siehe Abb. 4.54. Query anlegen, Schritt 3) und ziehen Sie auf identische Art und Weise die

174

4 Fallstudie I – Ist-Daten-Analyse

Merkmale Produkthauptgruppe und Produktgruppe aus der Dimension Produkt, das Merkmal Land aus der Dimension Region sowie die Merkmale Kalenderjahr, KalJahr/Quartal und Quartal in den Bereich Freie Merkmale (siehe Abb. 4.54. Query anlegen, Schritt 4). Klicken Sie mit der rechten Maustaste auf das Merkmal Land im Feld Freie Merkmale (siehe Abb. 4.54. Query anlegen, Schritt 5) und selektieren Sie im Kontextmenü die Funktion Eigenschaften (siehe Abb. 4.54. Query anlegen, Schritt 6). Im folgenden Popup betätigen Sie im Gruppierungsfeld Präsentationshierarchie die Schaltfläche Werte (siehe Abb. 4.54. Query anlegen, Schritt 7). Markieren Sie im Dialog Hierarchie auswählen die Hierarchie Land ### (siehe Abb. 4.54. Query anlegen, Schritt 8) und bestätigen Sie mit OK (siehe Abb. 4.54. Query anlegen, Schritt 9). Setzen Sie in den Hierarchieeigenschaften den Haken bei Expandieren bis Stufe (siehe Abb. 4.54. Query anlegen, Schritt 10). Schließen Sie auch die Eigenschaften des Merkmals Land mit OK (siehe Abb. 4.54. Query anlegen, Schritt 11).

4.3 Teil III – Reporting

175

Abb. 4.54. Query anlegen

Klicken Sie auf Query speichern (siehe Abb. 4.54. Query anlegen, Schritt 12). Im Speicherdialog erstellen Sie mit der Schaltfläche Ordner anlegen einen neuen Ordner unter Ihren Favoriten (siehe Abb. 4.55. Sichern der Query, Schritt 1) mit der Bezeichnung Fallstudie BW ### (siehe Abb. 4.55. Sichern der Query, Schritt 2). Betätigen Sie die Schaltfläche Weiter (siehe Abb. 4.55. Sichern der Query, Schritt 3) und vergeben Sie anschließend die Beschreibung Umsatz Ist-Daten ### sowie den technischen Namen QUERY1_### (siehe Abb. 4.55. Sichern der

176

4 Fallstudie I – Ist-Daten-Analyse

Query, Schritt 4). Sichern Sie Ihre erste Query (siehe Abb. 4.55. Sichern der Query, Schritt 5).

Abb. 4.55. Sichern der Query

4.3.2 Reporting mit dem BEx Analyzer unter MS Excel Starten Sie MS Excel und über das Windows – Startmenü das Programm Analyzer in der Programmgruppe Business Explorer. Falls ein Sicherheitshinweis erscheint, ob Makros der SAP AG verwendet werden sollen, so bestätigen Sie diesen mit der Schaltfläche Makros aktivieren. Im MS Excel Hauptfenster steht Ihnen nun eine neue Werkzeugleiste Business Explorer zur Verfügung. Klicken Sie in dieser Werkzeugleiste auf Öffnen und wählen Sie den Menüpunkt Queries aus (siehe Abb. 4.56. Öffnen der Query im BEx Analyzer, Schritt 1). Melden Sie sich an Ihrem SAP BW System an und laden Sie aus der Historie Ihre Query Umsatz Ist-Daten ### (siehe Abb. 4.56. Öffnen der Query im BEx Analyzer, Schritt 2).

4.3 Teil III – Reporting

177

Beenden Sie den Dialog mit OK (siehe Abb. 4.56. Öffnen der Query im BEx Analyzer, Schritt 3).

Abb. 4.56. Öffnen der Query im BEx Analyzer

Rechtsklicken Sie auf das hellblau hinterlegte Feld in der Spalte B neben dem Eintrag Land (siehe Abb. 4.57. OLAP im BEx Analyzer, Schritt 1) und wählen im kontextsensitiven Menü Aufreißen aus. Es öffnet sich ein zusätzliches Menü, in dem Sie einen senkrechten Aufriss des Merkmals auswählen (siehe Abb. 4.57. OLAP im BEx Analyzer, Schritt 2). Daraufhin wird die Excel-Arbeitsmappe neu geladen und die vorgenommenen Änderungen auf die Ergebnistabelle angewandt. Reißen Sie als nächstes das Merkmal Produktgruppe waagerecht auf (siehe Abb. 4.57. OLAP im BEx Analyzer, Schritt 3 und Schritt 4).

178

4 Fallstudie I – Ist-Daten-Analyse

Abb. 4.57. OLAP im BEx Analyzer

Klicken Sie nun auf die Schaltfläche Layout der Werkzeugleiste Business Explorer (siehe Abb. 4.58. Einbinden eines Diagramms im BEx Analyzer, Schritt 1) und selektieren Sie Diagramm anbinden (siehe Abb. 4.58. Einbinden eines Diagramms im BEx Analyzer, Schritt 2). Platzieren Sie das Diagramm unterhalb der Wertetabelle.

4.3 Teil III – Reporting

179

Abb. 4.58. Einbinden eines Diagramms im BEx Analyzer

Betätigen Sie erneut Layout (siehe Abb. 4.59. Einbinden einer Landkarte im BEx Analyzer, Schritt 1) und anschließend Landkarte anbinden (siehe Abb. 4.59. Einbinden einer Landkarte im BEx Analyzer, Schritt 2). In der MS Excel Arbeitsmappe wird nun ein neues Arbeitsblatt mit der Bezeichnung BEx Map angelegt und erhält sogleich den Fokus.

180

4 Fallstudie I – Ist-Daten-Analyse

Abb. 4.59. Einbinden einer Landkarte im BEx Analyzer

Hinweis: Sollte die Kartendarstellung fehlerhaft sein, so verschieben Sie den Bildausschnitt im Arbeitsblatt nach unten bis die Karte aus dem sichtbaren Bildbereich sich nicht mehr im sichtbaren Bereich befindet. Scrollen Sie anschließend zur Karte zurück. Betätigen Sie die Schaltfläche Auf Karte anzeigen (siehe Abb. 4.60. Kartendarstellung 1, Schritt 1) und vergrößern / verschieben Sie den Kartenausschnitt derart, dass die unterschiedliche Einfärbung der relevanten Länder zu erkennen ist (siehe Abb. 4.60. Kartendarstellung 1, Schritt 2).

4.3 Teil III – Reporting

181

Abb. 4.60. Kartendarstellung 1

Wählen Sie anschließend aus der Choicebox nach den Eintrag Produktgruppe (siehe Abb. 4.61. Kartendarstellung 2, Schritt 1) und aus mit das Kreisdiagramm (siehe Abb. 4.61. Kartendarstellung 2, Schritt 2). Durch einen Klick auf Auf Karte anzeigen wird der Umsatz je Produktgruppe als Kreisdiagramm im jeweiligen Land dargestellt (siehe Abb. 4.61. Kartendarstellung 2, Schritt 3). Schließen Sie MS Excel ohne zu speichern.

182

4 Fallstudie I – Ist-Daten-Analyse

Abb. 4.61. Kartendarstellung 2

4.3.3 Ad hoc – Reporting im Webbrowser Öffnen Sie Ihre Query Umsatz Ist-Daten ### nun wieder im BEx Query Designer und führen Sie diese über Query im Web zeigen aus. Sie werden vom Webbrowser aufgefordert, sich erneut mit Benutzerkennung und Passwort am System anzumelden. Der Webbrowser zeigt nun Ihre Query an. Zuerst sollen die Umsätze aufgegliedert nach Produktgruppen über die Jahre und Quartale analysiert werden. Klicken Sie dafür auf das Symbol In den Zeilen aufreißen neben KalJahr/Quartal (siehe Abb. 4.62. OLAP im Webbrowser 1, Schritt 1) und auf das Symbol In den Spalten aufreißen neben Produktgruppe (siehe Abb. 4.62. OLAP im Webbrowser 1, Schritt 2). Die tabellarische Darstellung der Ergebnisse Ihrer Query wird automatisch aktualisiert. Wechseln Sie in die Ansicht Kreisdiagramm (siehe Abb. 4.62. OLAP im Webbrowser 1, Schritt 3).

4.3 Teil III – Reporting

183

Abb. 4.62. OLAP im Webbrowser 1

Wenn Sie den Mauszeiger innerhalb des Diagramms positionieren, wird der zugehörige Umsatz als Tooltipp angezeigt (siehe Abb. 4.63. Kreisdiagramm, Schritt 1). Beachten Sie, dass der Umsatz nur für das erste Quartal des Jahres 2003 präsentiert wird. Setzen Sie einen Filter, indem Sie das Symbol Filterwert auswählen für KalJahr/Quartal anklicken (siehe Abb. 4.63. Kreisdiagramm, Schritt 2). Setzen Sie den Haken im folgenden Fenster bei 4.2004 (siehe Abb. 4.63. Kreisdiagramm, Schritt 3) und bestätigen Sie Ihre Selektion mit Übernehmen (siehe Abb. 4.63. Kreisdiagramm, Schritt 4). Nun wird das Diagramm für das vierte Quartal des Jahres 2004 angezeigt, das Verhältnis der Sektoren hat sich verschoben. Löschen Sie den Filter anschließend über das Symbol Filter entfernen.

184

4 Fallstudie I – Ist-Daten-Analyse

Abb. 4.63. Kreisdiagramm

Rufen Sie nun das Liniendiagramm auf (siehe Abb. 4.64. Liniendiagramm 1, Schritt 1). Dieses zeigt Ihnen die zeitliche Entwicklung der Umsätze je Produktgruppe.

4.3 Teil III – Reporting

185

Abb. 4.64. Liniendiagramm 1

Im nächsten Schritt wählen Sie das Säulendiagramm (siehe Abb. 4.65. Balkendiagramm, Schritt 1). Die aktuelle Darstellung mit den Produktgruppen in der Abszisse und den Zeitabschnitten innerhalb der Säulen ist jedoch unübersichtlich und daher wenig zweckmäßig. Ändern Sie die Achsenzuordnung mittels des Symbols Achsen vertauschen (siehe Abb. 4.65. Balkendiagramm, Schritt 2).

186

4 Fallstudie I – Ist-Daten-Analyse

Abb. 4.65. Balkendiagramm

Als nächstes ist der Umsatz in den einzelnen Produkthauptgruppen zwischen den Ländern zu vergleichen. Entfernen Sie dazu zunächst KalJahr/Quartal und Produktgruppe, indem Sie das jeweilige Symbol Aufriss entfernen betätigen (siehe Abb. 4.66. 3D Säulendiagramm, Schritt 1 und Schritt 2). Positionieren Sie nun die Produkthauptgruppe in der Abszisse (siehe Abb. 4.66. 3D Säulendiagramm, Schritt 3) und das Land in der Ordinate (siehe Abb. 4.66. 3D Säulendiagramm, Schritt 4). Rufen Sie im generischen Navigationsblock das Kontextmenü zum Land mittels Linksklick auf, selektieren sie das Erweiterte Menü und rufen Sie den Eintrag Hierarchie deaktivieren auf (siehe Abb. 4.66. 3D Säulendiagramm, Schritt 5 und Schritt 6). Wechseln Sie in das 3D Säulendiagramm (siehe Abb. 4.66. 3D Säulendiagramm, Schritt 7). So sind etwa die Produkthauptgruppen in Deutschland am umsatzstärksten und es ähneln sich die Summen der Umsätze in Dänemark und den Niederlanden, die genauen Zahlenwerte erhalten Sie als Tooltipp.

4.3 Teil III – Reporting

187

Abb. 4.66. 3D Säulendiagramm

Wählen Sie erneut das Liniendiagramm (siehe Abb. 4.67. Liniendiagramm 2, Schritt 1) aus und vertauschen Sie die Achsen (siehe Abb. 4.67. Liniendiagramm 2, Schritt 2). Die Steigung der Strecken gibt an, wie sich der Umsatz eines jeden Landes anteilsmäßig zusammensetzt. Setzen Sie einen Filterwert, um alle Länder außer Deutschland abzubilden. Platzieren Sie dazu den Haken im Bereich Beschreibung der Filterwerte (siehe Abb. 4.67. Liniendiagramm 2, Schritt 3). Wählen Sie als Operand =, als ersten Wert DE (siehe Abb. 4.67. Liniendiagramm 2, Schritt 4) und in der Dropdownbox statt einschließen ausschließen (siehe Abb. 4.67. Liniendiagramm 2, Schritt 5). Wenden Sie den Filter auf die Query mit Übernehmen an (siehe Abb. 4.67. Liniendiagramm 2, Schritt 6). Jetzt können Sie erkennen, dass in Dänemark die Produkthauptgruppe Video & DVD einen größeren Beitrag zum Gesamtumsatz leistet als in den Niederlanden. Schließen Sie Webbrowser sowie BEx Query Designer.

188

4 Fallstudie I – Ist-Daten-Analyse

Abb. 4.67. Liniendiagramm 2

4.3.4 Reporting mit dem BEx Web Application Designer Starten Sie den Web Application Designer aus dem MS Windows Startmenü in der Programmgruppe Business Explorer. Melden Sie sich mit Ihren Zugangsdaten am System an. Der BEx Web Application Designer öffnet sich mit einem neuen Template. Wählen Sie in der Menüleiste den Eintrag Einfügen aus (Abb. 4.68. Tabelle erstellen im BEx Web Application Designer, Schritt 1) und navigieren dort zum Untermenü Tabelle. Hier selektieren Sie Tabelle einfügen (siehe Abb. 4.68. Tabelle erstellen im BEx Web Application Designer, Schritt 2). Setzen Sie die Anzahl Zeilen sowie die Anzahl Spalten jeweils auf 1 (siehe Abb. 4.68. Tabelle

4.3 Teil III – Reporting

189

erstellen im BEx Web Application Designer, Schritt 3) und bestätigen Sie mit OK (siehe Abb. 4.68. Tabelle erstellen im BEx Web Application Designer, Schritt 4).

Abb. 4.68. Tabelle erstellen im BEx Web Application Designer

Legen Sie darunter eine weitere Tabelle mit ebenfalls einer Zeile und einer Spalte an. Abschließend folgt eine Tabelle mit zwei Zeilen und nur einer Spalte. Hinweis: Sie können die Position der Tabelle ändern, in dem Sie den Cursor vor eine Tabelle Positionieren und durch Betätigen der ReturnTaste an dieser Stelle einen leeren Abschnitt erzeugen. Durch Anklicken des Tabellenrandes können Sie mit gedrückter Maustaste die Tabelle verschieben. Ziehen Sie nun aus der Liste Web Items das Objekt Textelemente in die oberste Tabelle (siehe Abb. 4.69. Textfeld erstellen im BEx Web Application Designer, Schritt 1). Im Fenster Eigenschaften: Neues Template1 wechseln Sie ins Register Web Item (siehe Abb. 4.69. Textfeld erstellen im BEx Web Application Designer, Schritt 2) und entfernen die Häkchen im Bereich Allgemein zu den Einträgen Überschrift generieren (siehe Abb. 4.69. Textfeld erstellen im BEx Web Application Designer, Schritt 3) und Objekte mit Navigationslinks (siehe Abb. 4.69. Textfeld erstellen im BEx Web Application Designer, Schritt 4). Im Abschnitt Speziell deaktivieren Sie die Markierungen Statische Filterwerte anzeigen sowie Variablenwerte anzeigen, stattdessen wählen Sie Nur Werte anzeigen (siehe Abb. 4.69. Textfeld erstellen im BEx Web Application Designer, Schritt 5).

190

4 Fallstudie I – Ist-Daten-Analyse

Anschließend klicken Sie links in das Wertefeld des Eintrages Liste der Textelemente und daraufhin auf die sich öffnende Schaltfläche (siehe Abb. 4.69. Textfeld erstellen im BEx Web Application Designer, Schritt 5). Im Pflegedialog Liste der Textelemente wählen Sie in der ersten Zeile Allgemeines Textsymbol als Typ des Elements und vergeben REPTXTLG als Name des Elements (siehe Abb. 4.69. Textfeld erstellen im BEx Web Application Designer, Schritt 6). Schließen Sie den Dialog mit OK (siehe Abb. 4.69. Textfeld erstellen im BEx Web Application Designer, Schritt 7).

Abb. 4.69. Textfeld erstellen im BEx Web Application Designer

Ziehen Sie im nächsten Schritt das Web Item Generischer Navigationsblock in die mittlere Tabelle. Setzen Sie in den Eigenschaften das Häkchen bei Einträge nebeneinander anordnen. Anschließend positionieren Sie das Web Item Tabelle in der oberen Zeile und das Web Item Chart in der unteren Zeile der verbliebenen dritten Tabelle. Selektieren Sie das Web Item TABLE_1 und tragen Sie in den Eigenschaften als Überschrift Ergebnistabelle ein. Markieren Sie anschließend das Web Item Chart und setzen Sie in den Eigenschaften im Kartenreiter Web Item die Breite in Punkten auf 600 und vergeben Sie als Überschrift Balkendiagramm. Nun werden die einzelnen Web Items an einen DataProvider angebunden. Markieren Sie das Web Item TEXTELEMENTS_1 (siehe Abb. 4.70. Query zum Web Template auswählen, Schritt 1) und stellen den Kartenreiter Allgemein im Bereich der Eigenschaften: Neues Template 1 in den Vordergrund (siehe Abb. 4.70. Query zum Web Template auswählen, Schritt 2). Im Gruppierungsfeld DataProvider stehen Ihnen zwei Eingabefelder zur Verfügung. Im ersten, mit Name

4.3 Teil III – Reporting

191

gekennzeichneten Feld, ist bereits der DataProvider DATAPROVIDER_1 eingetragen, dieser bezieht sich aber noch auf keine Query. Betätigen Sie die Schaltfläche Query auswählen (siehe Abb. 4.70. Query zum Web Template auswählen, Schritt 3), wählen Sie in Ihren Favoriten (siehe Abb. 4.70. Query zum Web Template auswählen, Schritt 4) aus dem Ordner Fallstudie BW ### die Query Umsatz Ist-Daten ### aus (siehe Abb. 4.70. Query zum Web Template auswählen, Schritt 5) und schließen Sie das Popup Query / View öffnen mit OK (siehe Abb. 4.70. Query zum Web Template auswählen, Schritt 6). Damit haben Sie Ihr Web Template angelegt und Speichern dieses nun (siehe Abb. 4.70. Query zum Web Template auswählen, Schritt 7). Im Dialog Web Template sichern markieren Sie nun den Ordner Fallstudie BW ### (siehe Abb. 4.70. Query zum Web Template auswählen, Schritt 8) und vergeben die Beschreibung Umsatz IstDaten ### und den technischen Namen WEBTEMPLATE1_### (siehe Abb. 4.70. Query zum Web Template auswählen, Schritt 9). Sichern Sie Ihr Web Template (siehe Abb. 4.70. Query zum Web Template auswählen, Schritt 10). Nun können Sie das Web Template betrachten, indem Sie in der Werkzeugleiste auf Ausführen im Browser... klicken (siehe Abb. 4.70. Query zum Web Template auswählen, Schritt 11).

192

4 Fallstudie I – Ist-Daten-Analyse

Abb. 4.70. Query zum Web Template auswählen

Melden Sie sich erneut am System an. Um die Verteilung der Umsätze je Region und Produktgruppe darzustellen, reißen Sie im Navigationsblock das Land in den Zeilen (siehe Abb. 4.71. Web Template im Webbrowser, Schritt 1) und die Produktgruppe in den Spalten auf (siehe Abb. 4.71. Web Template im Webbrowser, Schritt 2). Expandieren Sie die Regionshierarchie in der Ergebnistabelle (siehe Abb. 4.71. Web Template im Webbrowser, Schritt 3) und betrachten Sie Ihre Web Application. Schließen Sie den Webbrowser.

4.3 Teil III – Reporting

193

Abb. 4.71. Web Template im Webbrowser

Im BEx Web Application Designer rufen Sie in der Menüleiste Web Template auf und wählen die Funktion Speichern unter... aus. Markieren Sie erneut Ihren Ordner Fallstudie BW ###, vergeben Sie die Beschreibung Umsatz Ist-Daten Karte ### und den technischen Namen WEBTEMPLATE2_###. Sichern Sie auch dieses Web Template. Markieren Sie das Web Item Chart in Ihrem Web Template und drücken Sie entf. Ziehen Sie in das nun freigewordene Tabellenfeld das Web Item Karte. Im Register Web Item der Eigenschaften (siehe Abb. 4.72. View anlegen im BEx Web Application Designer, Schritt 1) setzen Sie die Breite in Punkten auf 600 (siehe Abb. 4.72. View anlegen im BEx Web Application Designer, Schritt 2). Im Abschnitt Speziell markieren Sie außerdem die Kästchen Kartographieinformationen an/aus (siehe Abb. 4.72. View anlegen im BEx Web Application Designer, Schritt 3) sowie Erweiterte Geo-Funktionsleiste (siehe Abb. 4.72. View anlegen im BEx Web Application Designer, Schritt 4) und wählen im Feld Geo-Funktionen den Eintrag links (siehe Abb. 4.72. View anlegen im BEx Web Application Designer, Schritt 5). Weil das Web Item Karte für eine korrekte Darstellung im Zeilenaufriss ein Geomerkmal wie zum Beispiel das Land benötigt, ist die zuvor verwendete Query

194

4 Fallstudie I – Ist-Daten-Analyse

zunächst ungeeignet, um an den DataProvider angebunden zu werden. Neben Queries allein können allerdings auch Sichten auf Queries, so genannte Views, bei der DataProvider-Pflege eingesetzt werden. Diese geben einen festgelegten Navigationszustand in einer Query wieder. Um einen View anzulegen, wählen Sie aus der Menüzeile des BEx Web Application Designers den Eintrag Werkzeuge (siehe Abb. 4.72. View anlegen im BEx Web Application Designer, Schritt 6) und bewegen den Mauszeiger auf den Menüpunkt View Definition. Daraufhin öffnet sich ein weiteres Menü, in welchem Sie die Funktion basierend auf einer Query... aufrufen (siehe Abb. 4.72. View anlegen im BEx Web Application Designer, Schritt 7). Im sich öffnenden Dialog Web Template öffnen selektieren Sie Ihre Query mit der Beschreibung Umsatz Ist-Daten ### aus den Favoriten (siehe Abb. 4.72. View anlegen im BEx Web Application Designer, Schritt 8). Bestätigen Sie anschließend mit OK (siehe Abb. 4.72. View anlegen im BEx Web Application Designer, Schritt 9).

Abb. 4.72. View anlegen im BEx Web Application Designer

Es wird nun ein Webbrowser-Fenster mit der Aufforderung, sich am System anzumelden, geöffnet. Tragen Sie Ihren Benutzernamen und das Passwort in die entsprechenden Felder ein und bestätigen Sie. Nachdem Sie sich erfolgreich angemeldet haben, wird im Webbrowser eine Seite mit dem Titel Ihrer Query aufge-

4.3 Teil III – Reporting

195

baut, die dem aus dem Ad hoc – Reporting bekannten Standard Web Template ähnelt. Tragen Sie im Bereich View sichern als Beschreibung Umsatz Ist-Daten View Land ### ein und vergeben Sie als technischen Namen VIEW1_### (siehe Abb. 4.73. View sichern im BEx Web Application Designer, Schritt 1). Reißen sie abschließend das Merkmal Land in den Zeilen auf, indem Sie durch einen Linksklick auf das Label zum Merkmal Land das Kontextmenü öffnen und im Untermenü Aufreißen den Eintrag Senkrecht wählen (siehe Abb. 4.73. View sichern im BEx Web Application Designer, Schritt 2). Daraufhin wird die Ergebnistabelle verändert, die Länder stehen nun in den Zeilen. Damit haben Sie die View Definition abgeschlossen und können nun die Sicht abspeichern, indem Sie mit der linken Maustaste auf View sichern klicken (siehe Abb. 4.73. View sichern im BEx Web Application Designer, Schritt 3). Das Webbrowser-Fenster wird nun aktualisiert und es erscheint im oberen Bildbereich die Meldung, dass der View erfolgreich gespeichert wurde. Schließen Sie den Webbrowser.

Abb. 4.73. View sichern im BEx Web Application Designer

Wechseln Sie in den BEx Web Application Designer zurück und ordnen Sie nun dem DataProvider den soeben angelegten View zu, indem Sie aus der Dropdownbox in den Eigenschaften zur Karte den Eintrag MAPLAYER_1 selektieren (siehe Abb. 4.74. View einbinden im BEx Web Application Designer, Schritt 1) und die Registerkarte Allgemein in den Vordergrund stellen (siehe Abb. 4.74. View einbinden im BEx Web Application Designer, Schritt 2). Dort klicken Sie auf die Schaltfläche View auswählen (siehe Abb. 4.74. View einbinden im BEx Web Application Designer, Schritt 3). Im neu geöffneten Dialog Query / View öffnen

196

4 Fallstudie I – Ist-Daten-Analyse

wählen Sie Ihren View Umsatz Ist-Daten View Land ### aus (siehe Abb. 4.74. View einbinden im BEx Web Application Designer, Schritt 4) und bestätigen mit OK (siehe Abb. 4.74. View einbinden im BEx Web Application Designer, Schritt 5). Speichern Sie Ihr Web Template (siehe Abb. 4.74. View einbinden im BEx Web Application Designer, Schritt 6) und führen Sie es im Webbrowser aus (siehe Abb. 4.74. View einbinden im BEx Web Application Designer, Schritt 7).

Abb. 4.74. View einbinden im BEx Web Application Designer

Zoomen Sie über die erweiterte Funktionsleiste im linken Bereich der Karte auf Mitteleuropa (vgl. Abb. 4.75. Kartendarstellung im Webbrowser).

4.3 Teil III – Reporting

Abb. 4.75. Kartendarstellung im Webbrowser

Zusammenfassung: In diesem dritten und letzten Teil der ersten Fallstudie haben Sie eine Query Umsatz Ist-Daten ### mit dem BEx Query Designer erstellt. Sie bezieht die Daten aus dem in den ersten beiden Teilen dieser Fallstudie gepflegten InfoCube A_ICI_###. Die Auswertung der Query haben Sie im BEx Analyzer unter MS Excel vorgenommen und neben den OLAP-Operationen zur Navigation im Datenbestand die Darstellung in einer MS Excel-Tabelle, die Karte und das Kreisdiagramm kennen gelernt. Bei der Betrachtung der Query-Resultate im Webbrowser konnten Sie verschiedene Diagramme auswählen und haben die Auswirkung unterschiedlicher Sichten auf die Darstellung der Daten in einem Diagramm beobachten können. Zudem haben Sie einen Filter gesetzt, der den auswertbaren Datenbestand derart eingeschränkt hat, dass die Darstellung in Diagrammen übersichtlicher gestaltet werden konnte. Im BEx Web Application Designer haben Sie den Aufbau eines Web Templates praktisch nachvollzogen. Als Datenquelle für die eingearbeiteten Web Items Ihres ersten Web Templates haben Sie die zuvor erstellte Query Umsatz Ist-Daten ### angebunden. Im Web Template befinden sich der generische Navigationsblock, die Ergebnistabelle und das Chart. Für die Darstellung in einer Karte haben Sie die Sicht Umsatz Ist-Daten View Land ### in Ihrer Query Umsatz Ist-Daten ### hinterlegt und einem neuen Web Template zugewiesen.

197

5 Fallstudie II – Soll-Ist Vergleich

Diese zweite Fallstudie baut inhaltlich auf der ersten Fallstudie auf und erweitert das Spektrum des Anwenders in Bezug auf die Funktionen des SAP BW. Die in der ersten Fallstudie angelegten BW-Objekte werden hier wieder verwendet und die Inhalte als bekannt vorausgesetzt. Daher sind einfache Arbeitsschritte, die in ähnlicher Form in der ersten Fallstudie auftreten, nur dann in Screenshots abgebildet, wenn es die Umstände erforderlich machen. Der inhaltliche Aufbau wurde konsistent in die Struktur der Datenmodellierung, der Datenbeschaffung und des Reporting überführt. Aufgabenstellung und Szenario Nachdem Sie den Prototypen im SAP BW erfolgreich fertig gestellt haben, wird Ichnen nun eine weitere Aufgabe zugeteilt. Man möchte nun neben Ist-Daten auch Soll-Daten in das SAP BW Reporting integrieren. Für die Erstellung der SollDaten ist die Planungsabteilung zuständig. Diese verwendet ein anderes operatives System als der Vertrieb, dessen Daten Sie zuvor aus CSV-Dateien eingelesen haben. Auch das Datenmodell wurde nicht einheitlich gestaltet. Nachdem Sie die Metadaten des Datenmodells und eine Schnittstellendatei mit Soll-Daten aus der Planungsabteilung analysiert haben, stellen Sie fest, dass der einzige Unterschied im Länderkennzeichen für das Land Deutschland besteht. Im SAP BW wird die Zeichenfolge DE eingesetzt, während das System der Planungsabteilung nur D verwendet. Sie werden also in den Übertragungsregeln eine Cleaning-Operation vornehmen müssen. Die IT-Verantwortlichen raten Ihnen, dieses Mal den Standard-ETL-Prozess der SAP AG zu befolgen und die Daten über die PSA zunächst in ein ODS-Objekt zu laden und anschließend in einen InfoCube. Sollte der Ladevorgang nicht wie erwartet verlaufen, so können Sie den Datenrequest aus dem ODS-Objekt löschen, ohne dass die für das Reporting bedeutsamen Inhalte betroffen wären. Die Struktur des InfoCubes für die Soll-Daten wird identisch mit der des InfoCubes für Ist-Daten sein. Sie machen den Vorschlag, diese beiden InfoCubes über einen MultiProvider zu verbinden, um dadurch eine sinnvolle Grundlage für das Reporting zu schaffen. Man begrüßt Ihre Initiative und nimmt die Anregung nach einer Prüfung in die Aufgabenbeschreibung mit auf. Für das Reporting wünscht man sich einen Bericht, in dem die Abweichungen der Ist-Umsätze von den Soll-Werten je Land für alle Produktgruppen deutlich werden. Die Navigation soll über Web Items erfolgen. Als die Anforderungen gerade spezifiziert wurden, erhalten Sie die Nachricht, dass die Ist-Daten für das vierte Quartal des Jahres 2004 nicht vollständig waren.

200

5 Fallstudie II – Soll-Ist Vergleich

Die damals nicht erfassten Umsätze sind nachträglich in das SAP BW fortzuschreiben. Ihre Aufgabe ist es nun, zunächst ein ODS-Objekt und einen InfoCube zu definieren, die sich eng an der Struktur des bereits angelegten InfoCubes orientieren. Anschließend legen Sie einen MultiProvider an, der ebenfalls der Struktur der bereits angelegten InfoProvider ähnelt und die beiden InfoCubes miteinander verknüpft. Zum Zwecke der Datenbeschaffung werden Sie die InfoSource für das ODS-Objekt anlegen und Übertragungsregeln zur Sicherstellung der Datenqualität pflegen. Die InfoSource hat eine andere Struktur als die aus der ersten Fallstudie, weil sie einem ODS-Objekt zugeordnet wird. Wenn Sie die Datenbeschaffung für das ODS-Objekt abgeschlossen haben, legen Sie in den Fortschreibungsregeln des InfoCubes fest, dass dieser seine Daten aus dem ODS-Objekt beziehen soll. Nachdem die Einstellungen vorgenommen worden sind, laden Sie die Soll-Daten aus der CSV-Datei und überprüfen diese. Anschließend werden Sie die Daten in den InfoCube fortschreiben. Als letztes laden Sie auch die geforderten aktuellen IstDaten in das entsprechende Datenziel. Im Reporting werden Sie einen einzigen Bericht erstellen. Er wird über eine Dropdownbox die Möglichkeit bieten, verschiedene Kennzahlen auszuwählen und in einem hierarchischen Kontextmenü das gewünschte Land zu selektieren. Unter Zuhilfenahme von Exceptions werden im Bericht die Abweichungen farblich hervorgehoben. Der Report soll über das Menü einer Webseite aufgerufen werden können, die über die Favoriten des SAP Fensters erreichbar ist. Dadurch werden dem Betrachter keine Kenntnisse im Umgang des BEx Query Designers abverlangt. Bevor Sie eigene Web Templates generieren, führen Sie die Query im Standard Web Template aus, um einen Eindruck vom Zielzustand zu erlangen.

5.1 Teil I – Datenmodellierung In diesem Abschnitt werden im SAP BW die für das Laden der Daten und das Reporting erforderlichen Objekte angelegt. Die Bewegungsdaten sollen über ein ODS-Objekt in einen InfoCube geladen werden, der für das Reporting in einem MultiProvider eingesetzt wird. ODS-Objekte werden in einem anderen Zusammenhang eingesetzt als InfoCubes. Ein ODS-Objekt ist ein Datenziel für konsistente Daten mit feiner Granularität. Zugleich kann es Quelle für InfoCubes sein, die aus diesem Datenbestand die Bewegungsdaten beziehen und in aggregierter Form abspeichern können, um die Leistung bei Lesezugriffen im Reporting zu erhöhen. ODS-Objekte werden zum Teil auch eingesetzt, um dem Berichtswesen veränderliche Daten zur Verfügung zu stellen. In einem InfoCube können die Datensätze nicht überschrieben werden, ein ODS-Objekt hingegen lässt einen Schreibvorgang auf bestehenden Daten zu. Dadurch können auch hochaktuelle Daten, die in naher Zukunft Änderungen unterzogen werden, im Berichtswesen Verwendung finden. Das Datenmodell für ein ODS-Objekt besteht aus Schlüsselfeldern, die aus der Kombination der Merkmale und der Request-ID zusammenge-

5.1 Teil I – Datenmodellierung

201

setzt sind, und Datenfeldern, welche die Kennzahlen enthalten. Als Request bezeichnet man die Datensätze eines Ladevorganges. Der neue InfoCube wird angelegt, indem der bereits im System enthaltene Datenwürfel zur Speicherung der Ist-Daten als Vorlage verwendet wird. Dadurch wird der Modellierungsaufwand reduziert und es kann sichergestellt werden, dass die Datenmodelle identisch und damit voll integriert sind. Die Struktur beider InfoCubes ist auf die gleiche Weise aufgebaut, so dass eine vollkommene Vergleichbarkeit der ebenfalls identischen Kennzahlen gegeben ist, auch wenn sie sich in ihren Ausprägungen unterscheiden. Der Multiprovider führt nun die beiden InfoCubes zusammen. Dadurch werden sie in einer Query als eine einzige, ganzheitliche Datenquelle sichtbar. Durch den identischen Aufbau der beteiligten InfoCubes kann im MultiProvider eine vollständige Vernetzung der Merkmale und Kennzahlen erreicht werden. Diese hat große Vorteile bei der Erstellung einer Query, da nicht auf Besonderheiten einer Kennzahl oder unterschiedliche Ausprägungen der Merkmale geachtet werden muss. Zum MultiProvider wird ein Textdokument erstellt, welches Aufschluss über die Verwendung dieses InfoProviders gibt. Wird die Hilfe zu diesem Objekt aufgerufen, so wird das Dokument gemeinsam mit den Metadaten verfügbar gemacht und kann dem Verständnis nützen. 5.1.1 Anlegen eines ODS-Objekts Melden Sie sich erneut am SAP BW an und starten Sie über die Transaktion RSA1 die Administrator Workbench. Klicken Sie in der Sicht InfoProvider (siehe Abb. 5.1. ODS-Objekt anlegen, Schritt 1) mit der rechten Maustaste auf Ihre InfoArea Fallstudie BW ### (siehe Abb. 5.1. ODS-Objekt anlegen, Schritt 2) und selektieren Sie aus dem sich öffnenden Kontextmenü den Eintrag ODS-Objekt anlegen..., um das neue ODS-Objekt anzulegen (siehe Abb. 5.1. ODS-Objekt anlegen, Schritt 3). Vergeben Sie den technischen Namen A_OS_### (siehe Abb. 5.1. ODS-Objekt anlegen, Schritt 4) und die Beschreibung Soll-Daten Fallstudie ### (siehe Abb. 5.1. ODS-Objekt anlegen, Schritt 5). Schließen Sie Ihre Eingaben mit Anlegen ab (siehe Abb. 5.1. ODS-Objekt anlegen, Schritt 6).

202

5 Fallstudie II – Soll-Ist Vergleich

Abb. 5.1. ODS-Objekt anlegen

Im Pflegebildschirm ODS-Objekt bearbeiten öffnen Sie im rechten Fenster das Kontextmenü des Knotens Schlüsselfelder (siehe Abb. 5.2. ODS-Objekt bearbeiten 1, Schritt 1). Wählen Sie InfoObjects einfügen (siehe Abb. 5.2. ODS-Objekt bearbeiten 1, Schritt 2). Im Dialog InfoObjects einfügen tragen Sie in der Spalte InfoObject nacheinander A_MPG_###, A_ML_### und 0CALQUARTER ein (siehe Abb. 5.2. ODS-Objekt bearbeiten 1, Schritt 3). Bestätigen Sie mit Weiter (siehe Abb. 5.2. ODS-Objekt bearbeiten 1, Schritt 4).

5.1 Teil I – Datenmodellierung

203

Abb. 5.2. ODS-Objekt bearbeiten 1

Unter Datenfelder legen Sie analog die Kennzahl A_KU_### an, vom System wird automatisch ein Eintrag Währungsschlüssel ergänzt. Aktivieren Sie durch Setzen des Häkchens in der Spalte Ein/Aus das ebenfalls vom System erstellte Navigationsattribut Produkthauptgruppe ### im Ordner NavAttribute (siehe Abb. 5.3. ODS-Objekt bearbeiten 2, Schritt 1). Prüfen und Aktivieren Sie das ODSObjekt (siehe Abb. 5.3. ODS-Objekt bearbeiten 2, Schritt 2). Kehren Sie über Zurück in die Administrator Workbench zurück.

204

5 Fallstudie II – Soll-Ist Vergleich

Abb. 5.3. ODS-Objekt bearbeiten 2

5.1.2 Anlegen des InfoCubes für die Soll-Daten Legen Sie unter Ihrer InfoArea einen zusätzlichen InfoCube an (siehe Abb. 5.4. InfoCube mit Vorlage anlegen, Schritt 1 und Schritt 2). Der technische Name lautet A_ICS_### (siehe Abb. 5.4. InfoCube mit Vorlage anlegen, Schritt 3), als Beschreibung vergeben Sie Soll-Daten Fallstudie BW ### (siehe Abb. 5.4. InfoCube mit Vorlage anlegen, Schritt 4). Verwenden Sie den InfoCube der IstDaten A_ICI_### als Vorlage (siehe Abb. 5.4. InfoCube mit Vorlage anlegen, Schritt 5) und drücken Sie Anlegen (siehe Abb. 5.4. InfoCube mit Vorlage anlegen, Schritt 6).

5.1 Teil I – Datenmodellierung

205

Abb. 5.4. InfoCube mit Vorlage anlegen

Die Einstellungen im Dialog InfoCube bearbeiten: Merkmale sind nun für den neuen InfoCube bereits gepflegt, aktivieren Sie den InfoCube und kehren Sie mittels Beenden zur Administrator Workbench zurück. 5.1.3 Anlegen des Multiproviders Führen Sie wiederum einen Rechtsklick auf Ihre InfoArea A_IA_### aus (siehe Abb. 5.5. MultiProvider anlegen 1, Schritt 1) und selektieren Sie den Eintrag MultiProvider anlegen... (siehe Abb. 5.5. MultiProvider anlegen 1, Schritt 2). Vergeben Sie im Feld MultiProv. den Namen A_MP_### (siehe Abb. 5.5. MultiProvider anlegen 1, Schritt 3) und die Bezeichnung Soll-Ist Vergleich Fallstudie BW ### (siehe Abb. 5.5. MultiProvider anlegen 1, Schritt 4).

206

5 Fallstudie II – Soll-Ist Vergleich

Abb. 5.5. MultiProvider anlegen 1

Betätigen Sie die Schaltfläche Anlegen (siehe Abb. 5.5. MultiProvider anlegen 1, Schritt 5) und wählen Sie im folgenden Dialog MultiProvider: Beteiligte InfoProvider im Kartenreiter InfoCubes Ihre InfoCubes A_ICI_### und A_ICS_### durch Setzen der korrespondierenden Haken in der Spalte Beteiligt aus (siehe Abb. 5.6. MultiProvider anlegen 2, Schritt 1).

5.1 Teil I – Datenmodellierung

207

Abb. 5.6. MultiProvider anlegen 2

Durch Weiter (siehe Abb. 5.6. MultiProvider anlegen 2, Schritt 2) gelangen Sie in die Maske MultiProvider bearbeiten: Merkmale. Markieren Sie im Register Merkmale in der Vorlage die Zeilen der Einträge A_ML_### und A_MPG_### (siehe Abb. 5.7. MultiProvider bearbeiten 1, Schritt 1). Übertragen Sie die Merkmale in die Struktur, indem Sie die Schaltfläche Felder übernehmen betätigen (siehe Abb. 5.7. MultiProvider bearbeiten 1, Schritt 2). Klicken Sie nun auf die Schaltfläche Dimensionen... (siehe Abb. 5.7. MultiProvider bearbeiten 1, Schritt 3) und wählen Sie im Popup Dimensionen anlegen Nein. Anschließend legen Sie die Dimensionen Produkt und Region an und ordnen das Land der Dimension Region und die Produktgruppe der Dimension Produkt zu (vgl. Abb. 5.7. MultiProvider bearbeiten 1). Kehren Sie in die Ansicht MultiProvider bearbeiten: Merkmale zurück und klicken Sie die Schaltfläche Nav.Attribute... (siehe Abb. 5.7. MultiProvider bearbeiten 1, Schritt 4) an.

208

5 Fallstudie II – Soll-Ist Vergleich

Abb. 5.7. MultiProvider bearbeiten 1

Setzen Sie in der Tabelle Struktur das Häkchen Produkthauptgruppe ###, um das Navigationsattribut einzuschalten. Schließen Sie das Fenster durch Weiter. Fügen Sie im Kartenreiter Zeitmerkmale die Einträge Quartal, Kalenderjahr / Quartal und Kalenderjahr der Struktur hinzu (siehe Abb. 5.8. MultiProvider bearbeiten 2, Schritt 1 und Schritt 2). Wählen Sie nun Identifikation (siehe Abb. 5.8. MultiProvider bearbeiten 2, Schritt 3) und im öffnenden Dialog Identifikation beteiligter Merkmale Vorschlag erstellen (siehe Abb. 5.8. MultiProvider bearbeiten 2, Schritt 4). Es sollten nun in der Spalte entspricht sämtliche Haken gesetzt sein.

5.1 Teil I – Datenmodellierung

209

Abb. 5.8. MultiProvider bearbeiten 2

Bestätigen Sie die Auswahl mit Weiter (siehe Abb. 5.8. MultiProvider bearbeiten 2, Schritt 5) und rufen Sie das Register Kennzahlen auf. Hier übernehmen Sie aus der Vorlage die Kennzahl Umsatz in die Struktur (siehe Abb. 5.9. MultiProvider bearbeiten 3, Schritt 1 und Schritt 2) und klicken auf Selektion (siehe Abb. 5.9. MultiProvider bearbeiten 3, Schritt 3). Ordnen Sie beide InfoObjects A_KU_### durch Setzen der Häkchen in der Spalte Auswahl der Kennzahl A_KU_### zu (siehe Abb. 5.9. MultiProvider bearbeiten 3, Schritt 4). Schließen Sie auch diese Selektion mit Weiter ab (siehe Abb. 5.9. MultiProvider bearbeiten 3, Schritt 5). Prüfen und Aktivieren Sie den MultiProvider (siehe Abb. 5.9. MultiProvider bearbeiten 3, Schritt 6) und kehren Sie über Beenden zur Administrator Workbench zurück.

210

5 Fallstudie II – Soll-Ist Vergleich

Abb. 5.9. MultiProvider bearbeiten 3

Für den neu erstellten MultiProvider A_MP_### soll ein die Eigenschaften näher beschreibendes Dokument hinterlegt werden. Navigieren Sie in die Sicht Dokumente (siehe Abb. 5.10. Dokumentation zum MultiProvider erstellen, Schritt 1), wählen Sie den Objekttyp MPRO für MultiProvider (siehe Abb. 5.10. Dokumentation zum MultiProvider erstellen, Schritt 2) und vergeben Sie als Objektname A_MP_### (siehe Abb. 5.10. Dokumentation zum MultiProvider erstellen, Schritt 3). Klicken Sie auf Anlegen... (siehe Abb. 5.10. Dokumentation zum MultiProvider erstellen, Schritt 4), anschließend öffnet sich der Dialog Neues Dokument anlegen. In diesem benennen Sie das Dokument mit A_MP_###_Doku und tragen als Beschreibung Dokumentation A_MP_### ein (siehe Abb. 5.10. Dokumentation zum MultiProvider erstellen, Schritt 5). Klicken Sie auf Editor starten (siehe Abb. 5.10. Dokumentation zum MultiProvider erstellen, Schritt 6), um ein leeres Textdokument im Texteditor zu öffnen. Schreiben Sie eine kurze Dokumentation und speichern Sie die Datei über die Menüleiste des Editors (siehe Abb. 5.10. Dokumentation zum MultiProvider erstellen, Schritt 7). Schließen Sie

5.1 Teil I – Datenmodellierung

211

den Texteditor (siehe Abb. 5.10. Dokumentation zum MultiProvider erstellen, Schritt 8).

Abb. 5.10. Dokumentation zum MultiProvider erstellen

Im Pflegebildschirm Administrator Workbench: Dokumente sehen Sie, dass das Dokument in die Tabelle aufgenommen wurde. Kehren Sie über den Navigationsbereich in die Sicht Modellierung zurück. Wählen Sie Ihren MultiProvider A_MP_### mit der linken Maustaste an und drücken Sie F1. Ihr Webbrowser wird gestartet, melden Sie sich mit Ihren Zugangsdaten am System an. Im Webbrowser werden nun die Metadaten zum MultiProvider angezeigt, im Abschnitt Weitere Dokumente finden Sie die zuvor angelegte Dokumentation. Schließen Sie den Webbrowser.

212

5 Fallstudie II – Soll-Ist Vergleich

Zusammenfassung: Im ersten Teil der zweite Fallstudie haben Sie das ODS-Objekt A_OS_### angelegt. Es ähnelt der Struktur des in der ersten Fallstudie angelegten InfoCubes, wird jedoch nicht für das Berichtswesen eingesetzt. Derselbe InfoCube dient als Vorlage für den neuen InfoCube A_ICS_### mit Soll-Daten, wodurch der Definitionsvorgang sehr schnell ausgeführt werden konnte. Als letztes haben Sie den MultiProvider A_MP_### zum Verbinden der beiden InfoCubes erstellt und für diesen eine Online-Dokumentation geschrieben.

5.2 Teil II – Datenbeschaffung Die Empfehlung der SAP AG den ETL-Prozess (Extraktion Transformation und Laden) betreffend sieht neben dem Quellsystem, der PSA und einem InfoCube die Verwendung eines ODS-Objektes als Quelle für konsolidierte Daten vor. Anders als im ETL-Prozess der ersten Fallstudie werden hier die Daten zunächst aus der PSA in das ODS-Objekt geladen und erst im Anschluss daran in den InfoCube fortgeschrieben. Die InfoSource wird daher im Hinblick auf die Anforderungen eines ODS-Objektes definiert. Dieses erfordert im Gegensatz zum InfoCube ein technisches Merkmal 0RECORDMODE, welches über die verwendeten Daten und den beabsichtigten Ladevorgang Aufschluss gibt. So können Daten beispielsweise im Delta-Verfahren in das ODS-Objekt geladen werden, dabei wird nicht der gesamte Request, sondern nur die veränderten Daten übertragen. Das DeltaVerfahren kann dem SAP BW durch einen entsprechenden Eintrag in der Spalte 0RECORDMODE kenntlich gemacht werden, in dieser Fallstudie werden aber nur neue Daten in das SAP BW eingespielt und die Datenquelle verfügt nicht über eine entsprechende Spalte. Dem entsprechenden Datenfeld der Kommunikationsstruktur in den Übertragungsregeln wird daher ein konstanter Wert zugewiesen. Die Übertragungsregeln sind neben der PSA die Komponente im SAP BW, die für die Bereinigung der Daten eingesetzt wird. Die Daten werden hier in das Datenmodell des SAP BW konsistent überführt. In dieser Fallstudie erfolgt über eine Funktion die Bereinigung des Datenfeldes für das Merkmal Land, weil die Merkmalswerte in der Datenquelle nicht der im SAP BW festgelegten Form entsprechen. In den Fortschreibungsregeln für den InfoCube wird das ODS-Objekt eingetragen, Unterschiede zum Fortschreiben der Daten aus der PSA heraus sind aufgrund der automatischen Erzeugung der Regeln für den Anwender nicht auszumachen. Beim Anlegen des InfoPackages der für das ODS-Objekt verwendeten InfoSource kann in der Vorschau zum Datei-Upload der Zustand der Daten in den verschiedenen Stadien beobachtet werden. Hier ist zu erkennen, dass die Daten wie gewünscht durch die Übertragungsregeln transformiert werden, während sie im Bereich der Transferstruktur noch inkonsistent sind. Nachdem der Ladevorgang aus der CSV-Datei erfolgreich abgeschlossen wurde, können die Daten

5.2 Teil II – Datenbeschaffung

213

im ODS-Objekt begutachtet werden. Sie liegen noch als neue Daten vor und können nicht im Reporting oder zur Fortschreibung genutzt werden. Damit man sie verwenden kann, muss als Freigabe der Qualitätsstatus auf OK gesetzt und der Datenbestand aktiviert sein. Die Fortschreibung in den InfoCube erfolgt über den Aufruf der entsprechenden Funktion im Kontextmenü des ODS-Objektes. In Anschluss werden weitere Daten in den InfoCube geladen, der die Ist-Daten Fallstudie BW enthält. Es wird wiederum die aus der ersten Fallstudie bekannte verkürzte Variante des ETL-Prozesses angewandt wird. Dabei ist kein ODS-Objekt für die Speicherung konsolidierter Daten erforderlich, stattdessen werden die Daten direkt aus der PSA in den InfoCube fortgeschrieben. Werden Datensätze in den InfoCube geladen, der bereits über Bewegungsdaten mit identischen Merkmalswerten verfügt, so tritt die Fortschreibungsart in Kraft. Für die Kennzahl Umsatz wurde die Addition als Fortschreibungsart definiert. Beim Laden von Datensätzen mit identischen Merkmalswerten werden die Kennzahlen jedoch nicht sofort im InfoCube aufsummiert, sondern verbleiben darin als zwei getrennte Datensätze. Erst wenn die Query ausgeführt wird, erfolgt eine Aggregation der Daten und sie erscheinen als ein einziger Eintrag. 5.2.1 Anlegen der InfoSource für die Soll-Daten Legen Sie unter Ihrer Anwendungskomponente im Bereich InfoSources eine neue InfoSource an. Tragen Sie den technischen Namen A_ISS_### und die Beschreibung Soll-Daten Fallstudie BW ### ein und bestätigen Sie mit Übernehmen. Weisen Sie der InfoSource das Quellsystem A_QS_FSBW als DataSource zu und sichern Sie die Änderungen im nachfolgenden Popup mit Ja. Anschließend muss im Bildschirm InfoSource A_ISS_### ändern in der Tabelle des Registers DataSource/Transferstruktur die Struktur der in der Schnittstellendatei enthaltenen InfoObjects hinterlegt werden. Geben Sie dazu in der Spalte InfoObject A_MPG_###, A_ML_###, 0CALQUARTER und A_KU_### an. Das System informiert Sie darüber, dass das InfoObject 0CURRENCY hinzugefügt wurde. Rufen Sie anschließend den Kartenreiter Übertragungsregeln auf und betätigen Sie die Schaltfläche Übertragungsregeln vorschlagen. Wechseln Sie über Aufklappen (siehe Abb. 5.11. InfoSource ändern 1, Schritt 1) in die Kommunikationsstruktur, tragen Sie in der Spalte InfoObject in das Feld unter 0CURRENCY 0RECORDMODE ein (siehe Abb. 5.11. InfoSource ändern 1, Schritt 2) und drücken Sie Enter. Mögliche Hinweismeldungen über den Referenztyp CUKY übergehen Sie mir Enter.

214

5 Fallstudie II – Soll-Ist Vergleich

Abb. 5.11. InfoSource ändern 1

Schließen Sie die Tabelle Kommunikationsstruktur über Einklappen (siehe Abb. 5.12. InfoSource ändern 2, Schritt 1). Jetzt müssen die Übertragungsregeln für den Update Modus noch angepasst werden. Klicken Sie auf die Schaltfläche in der Spalte Tp der Zeile 0RECORDMODE (siehe Abb. 5.12. InfoSource ändern 2, Schritt 2). Weil für den Update Modus kein entsprechendes Objekt in der Transferstruktur vorhanden ist, tragen Sie als Konstante den Wert N ein (siehe Abb. 5.12. InfoSource ändern 2, Schritt 3). Dies bedeutet, dass dieser Satz ein neues Image liefert. Übernehmen Sie Ihre Eingaben (siehe Abb. 5.12. InfoSource ändern 2, Schritt 4).

5.2 Teil II – Datenbeschaffung

215

Abb. 5.12. InfoSource ändern 2

Da in der Schnittstellendatei die Merkmalsausprägung Deutschland statt mit DE nur mit dem Schlüssel D codiert ist, ist ebenfalls eine Anpassung der Übertragungsregeln für das Merkmal Land erforderlich, um die Konsistenz der Daten wiederherzustellen. Klicken Sie auf die Schaltfläche in der Spalte Tp der Zeile des InfoObjects A_ML_### (siehe Abb. 5.13. InfoSource ändern 3, Schritt 1). Es öffnet sich der Dialog Übertragungsregel bearbeiten, in dem Sie im Bereich Übertragungsregel den Radiobutton Formel selektieren (siehe Abb. 5.13. InfoSource ändern 3, Schritt 2). Betätigen Sie die Schaltfläche Anlegen (siehe Abb. 5.13. InfoSource ändern 3, Schritt 3) und vergeben Sie die Beschreibung lang Konvertierung (D-DE) A_ML_### (siehe Abb. 5.13. InfoSource ändern 3, Schritt 4). Schließen Sie das Fenster mit Weiter (siehe Abb. 5.13. InfoSource ändern 3, Schritt 5).

216

5 Fallstudie II – Soll-Ist Vergleich

Abb. 5.13. InfoSource ändern 3

Es öffnet sich der Bildschirm Formel Konvertierung (D-DE) A_ML_### (A_ML_###) anlegen. Betätigen Sie in der zentralen Gruppe der Schaltflächen die IF-Funktion (siehe Abb. 5.14. Formel zur Konvertierung anlegen, Schritt 1). Entsprechend der Syntax der Formel muss zunächst die Bedingung der Formel definiert werden. Führen Sie einen Doppelklick auf die Zeile mit der Bezeichnung Land der linken Tabelle aus (siehe Abb. 5.14. Formel zur Konvertierung anlegen, Schritt 2). Betätigen Sie nun den Operator = (siehe Abb. 5.14. Formel zur Konvertierung anlegen, Schritt 3) und anschließend die Schaltfläche String (siehe Abb. 5.14. Formel zur Konvertierung anlegen, Schritt 4). Im Popup geben Sie die Zeichenkette D ein (siehe Abb. 5.14. Formel zur Konvertierung anlegen, Schritt 5) und bestätigen mit Weiter (siehe Abb. 5.14. Formel zur Konvertierung anlegen, Schritt 6). Klicken Sie mit der linken Maustaste im Formelfenster in den Bereich Ergebnis_bei_“Wahr“. Fügen Sie einen String mit der Zeichenfolge DE ein und bestätigen Sie mit Weiter. Wird der Formel also D als Merkmalsausprägung Land übergeben, so gibt sie den Wert DE zurück. Andere Merkmalswerte sollen dagegen unverändert behandelt werden. Geben Sie daher als Ergebnis_bei_“Falsch“ über einen Doppelklick in die Zeile Land der linken Tabelle den Eingangswert als

5.2 Teil II – Datenbeschaffung

217

Ausgabe an. Prüfen Sie die Formel (siehe Abb. 5.14. Formel zur Konvertierung anlegen, Schritt 7) und verlassen Sie die Formel Konvertierung über Zurück (siehe Abb. 5.14. Formel zur Konvertierung anlegen, Schritt 8).

Abb. 5.14. Formel zur Konvertierung anlegen

Übernehmen Sie die neu erstellte Formel. Aktivieren Sie die InfoSource und verlassen Sie den Pflegedialog durch Beenden. Öffnen Sie das Kontextmenü Ihres ODS-Objekts A_OS_### im Abschnitt InfoProvider und wählen Sie den Eintrag Fortschreibungsregeln anlegen. Tragen Sie unter Datenquelle als InfoSource A_ISS_### ein, Prüfen Sie Ihre Angaben und wechseln Sie über Nächstes Bild in die nächste Maske. Aktivieren Sie dort die Fortschreibungsregeln und kehren Sie über Beenden zur Administrator Workbench zurück. Wählen Sie nun auch für den InfoCube A_ICS_### im Kontextmenü Fortschreibungsregeln anlegen. Als Datenquelle selektieren Sie im Bildschirm Fortschreibungsregeln anlegen: Einstieg das ODS-Objekt A_OS_### und Prüfen Ihre Eingaben. Anschließend betätigen Sie die Schaltfläche Nächstes Bild und Aktivieren die Fortschreibungsregeln für den InfoCube. Wechseln Sie durch Beenden zurück in die Administrator Workbench.

218

5 Fallstudie II – Soll-Ist Vergleich

5.2.2 Schreiben der Daten in das ODS-Objekt Legen Sie unter InfoSources das InfoPackage A_IPS_### zur DataSource Ihrer InfoSource Soll-Daten ### an. Markieren Sie in der Tabelle DataSource den Eintrag Soll-Daten Fallstudie BW ### und Sichern Sie Ihre Einstellungen. Wählen Sie im Scheduler (InfoPackage pflegen) das Register Fremddaten. Selektieren Sie die Datei Daten_Soll.csv (siehe Abb. 5.15. InfoPackage anlegen, Schritt 1), den Dateityp CSV-Datei (siehe Abb. 5.15. InfoPackage anlegen, Schritt 2) und 1 zu ignorierende Kopfzeile (siehe Abb. 5.15. InfoPackage anlegen, Schritt 3). Sehen Sie sich die Vorschau (siehe Abb. 5.15. InfoPackage anlegen, Schritt 4) über 10 Zeilen zum Datenimport an (siehe Abb. 5.15. InfoPackage anlegen, Schritt 5 und Schritt 6), hier wird der Inhalt der zu importierenden Datei angezeigt, in der Deutschland durch ein D repräsentiert wird.

Abb. 5.15. InfoPackage anlegen

Führen Sie die Simulation aus (siehe Abb. 5.16. InfoPackage Vorschau und Simulation, Schritt 1). Im folgenden Bildschirm Transferstruktur-Datensätze wurde der Länderschlüssel unverändert in die Transferstruktur übernommen. Betätigen Sie die Schaltfläche Kommunikationsstruktur (siehe Abb. 5.16. InfoPackage Vorschau und Simulation, Schritt 2) und kontrollieren Sie, ob der Länderschlüssel korrekt transformiert, also D durch DE für Deutschland ersetzt wurde. Kehren Sie über Beenden in die Vorschau für Datei-Upload zurück (siehe Abb. 5.16. InfoPackage Vorschau und Simulation, Schritt 3), schließen Sie die

5.2 Teil II – Datenbeschaffung

219

Nachricht des Monitors und die Vorschau für Datei-Upload über Weiter (siehe Abb. 5.16. InfoPackage Vorschau und Simulation, Schritt 4).

Abb. 5.16. InfoPackage Vorschau und Simulation

Sie kehren zum Scheduler zurück, hier starten Sie den Daten-Upload im Kartenreiter Einplanen. Kontrollieren Sie den Status des Auftrags im Monitor, der Ihnen mitteilt, dass die Daten erfolgreich in das ODS-Objekt geladen worden sind (vgl. Abb. 5.17. Monitor). Eine Aktivierung der Daten steht jedoch noch aus. Wechseln Sie zurück in den Bildschirm der Administrator Workbench.

220

5 Fallstudie II – Soll-Ist Vergleich

Abb. 5.17. Monitor

In der Modellierungssicht InfoProvider (siehe Abb. 5.18. ODS-Objekt administrieren, Schritt 1) klicken Sie mit der rechten Maustaste auf das ODS-Objekt A_OS_### (siehe Abb. 5.18. ODS-Objekt administrieren, Schritt 2) und wählen aus dem Kontextmenü den Eintrag Administrieren (siehe Abb. 5.18. ODSObjekt administrieren, Schritt 3). In der Maske Administrieren der Datenziele verzweigen Sie in den Kartenreiter Inhalt (siehe Abb. 5.18. ODS-Objekt administrieren, Schritt 4) und lassen sich die inaktiven Daten über Neue Daten anzeigen (siehe Abb. 5.18. ODS-Objekt administrieren, Schritt 5).

5.2 Teil II – Datenbeschaffung

221

Abb. 5.18. ODS-Objekt administrieren

Im darauf folgenden Bildschirm nehmen Sie keine Einträge vor, sondern drücken Ausführen. Nun können Sie den zuvor geladenen Dateninhalt des ODS-Objektes einsehen (vgl. Abb. 5.19. Dateninhalt des ODS-Objektes). Über zweimaliges Beenden kehren Sie zurück zum Administrieren der Datenziele.

222

5 Fallstudie II – Soll-Ist Vergleich

Abb. 5.19. Dateninhalt des ODS-Objektes

Hier stellen Sie das Register Requests in den Vordergrund (siehe Abb. 5.20. Administrieren der Datenziele 1, Schritt 1). Setzen Sie den QM-Status des Requests nach dem Verbuchen manuell auf Status OK, indem Sie auf das Ampelsymbol klicken (siehe Abb. 5.20. Administrieren der Datenziele 1, Schritt 2) und im Fenster Gesamt-Status setzen den Radiobutton neben der grünen Ampel anwählen (siehe Abb. 5.20. Administrieren der Datenziele 1, Schritt 3). Sichern Sie Ihre Änderungen (siehe Abb. 5.20. Administrieren der Datenziele 1, Schritt 4) und schließen Sie das nachfolgende Popup über Änderungen durchführen (siehe Abb. 5.20. Administrieren der Datenziele 1, Schritt 5).

5.2 Teil II – Datenbeschaffung

223

Abb. 5.20. Administrieren der Datenziele 1

Markieren Sie nun die gesamte Zeile Ihres Requests (siehe Abb. 5.21. Administrieren der Datenziele 2, Schritt 1) und Aktivieren Sie dieses (siehe Abb. 5.21. Administrieren der Datenziele 2, Schritt 2). Im Fenster Daten in ODS-Objekt SollDaten Fallstudie BW ### (A_OS_###) aktivieren markieren Sie erneut den Request (siehe Abb. 5.21. Administrieren der Datenziele 2, Schritt 3) und betätigen die Schaltfläche Start (siehe Abb. 5.21. Administrieren der Datenziele 2, Schritt 4). Nachdem der Job erfolgreich eingeplant wurde, Schließen Sie das Fenster (siehe Abb. 5.21. Administrieren der Datenziele 2, Schritt 5).

224

5 Fallstudie II – Soll-Ist Vergleich

Abb. 5.21. Administrieren der Datenziele 2

Wechseln Sie zurück in das Register Inhalt und betätigen Sie diesmal die Schaltfläche Aktive Daten. Das nächste Fenster wird wiederum über Ausführen übergangen. Ihnen wird angezeigt, dass alle Daten von der inaktiven in die aktive Version überführt worden sind. Kehren Sie durch mehrmaliges Beenden zur Administrator Workbench zurück. 5.2.3 Fortschreiben der Soll-Daten in den InfoCube sowie der korrigierten Ist-Daten Rufen Sie erneut das Kontextmenü Ihres ODS-Objekts A_OS_### auf (siehe Abb. 5.22. ODS-Daten fortschreiben, Schritt 1) und selektieren Sie den untersten Eintrag ODS-Daten in Datenziele fortschreiben... (siehe Abb. 5.22. ODS-Daten fortschreiben, Schritt 2). Wählen Sie im Dialog ODS-Tabelle Fortschreiben die Option Full-Fortschreiben (siehe Abb. 5.22. ODS-Daten fortschreiben, Schritt 3) und betätigen die Schaltfläche Fortschreiben (siehe Abb. 5.22. ODS-Daten fortschreiben, Schritt 4).

5.2 Teil II – Datenbeschaffung

225

Abb. 5.22. ODS-Daten fortschreiben

Im Scheduler (InfoPackage pflegen) beginnen Sie den Ladevorgang über Start. Im Monitor überprüfen Sie, ob der Vorgang erfolgreich beendet wurde. Kehren Sie durch zwei Mal Beenden zur Administrator Workbench zurück. In der Sicht InfoProvider Administrieren Sie über das Kontextmenü Ihren InfoCube Soll-Daten Fallstudie BW ###. Im Pflegebildschirm Administrieren der Datenziele wird im Kartenreiter Requests der gerade in den InfoCube fortgeschriebene Request aufgeführt. Schließen Sie den Pflegebildschirm durch Beenden. Wechseln Sie in die Sicht InfoSources. Dort expandieren Sie den Teilbaum zur InfoSource A_ISI_### und öffnen durch einen Doppelklick das InfoPackage A_IPI_###. Im Bildschirm Scheduler (InfoPackage pflegen) laden Sie im Register Fremddaten die neuen korrigierten Ist-Datensätze über die Datei Daten_Ist_Neu.csv hoch. In der Vorschau erkennen Sie, dass zur Korrektur des vierten Quartals 2004 lediglich die Veränderung und nicht der absolute Betrag erfasst ist. Schließen Sie die Vorschau und stellen Sie anschließend das Register Einplanen in den Vordergrund. Dort führen Sie über Start den Ladevorgang aus. Nachdem Sie den erfolgreichen Abschluss des Ladevorgangs im Monitor überprüft haben, verlassen Sie den Pflegebildschirm und wechseln in die InfoProvider Sicht und Administrieren den InfoCube Ist-Daten Fallstudie BW ###. In der Maske Administrieren der Datenziele markieren Sie den Tabelleneintrag Ist-Daten Fallstudie BW ### und wählen Inhalt. Im folgenden Bildschirm betätigen Sie die Schaltfläche Feldauswahl zur Ausgabe (siehe Abb. 5.23. Feldauswahl zur Ausgabe, Schritt 1). Im Fenster Datenziel Browser: „A_ICI_###“, Feldauswahl zur Ausgabe setzen Sie die Häkchen bei Produktgruppe, Land, Request ID,

226

5 Fallstudie II – Soll-Ist Vergleich

KalJahr/Quartal, Währung und Umsatz (siehe Abb. 5.23. Feldauswahl zur Ausgabe, Schritte 2 bis 8). Klicken Sie auf Ausführen (siehe Abb. 5.23. Feldauswahl zur Ausgabe, Schritt 9).

Abb. 5.23. Feldauswahl zur Ausgabe

Sie gelangen daraufhin erneut in den Bildschirm Datenziel Browser: ‚A_ICI_###’, Selektionsbild, wo Sie ebenfalls auf Ausführen drücken. Aus der Tabelle Datenziel Browser: „A_ICI_###“, List-Ausgabe können Sie den Dateninhalt des InfoCubes entnehmen. Für das vierte Quartal des Jahres 2004 sind je Kombination von Produktgruppe und Land zwei Einträge aus verschiedenen Requests enthalten (siehe Abb. 5.24. List-Ausgabe, Schritt 1). Diese werden bei Ausführung einer Query paarweise zu einem einzigen Wert für das betreffende Quartal aggregiert. Verlassen Sie das SAP System, indem Sie den Modus schließen.

5.2 Teil II – Datenbeschaffung

Abb. 5.24. List-Ausgabe

227

228

5 Fallstudie II – Soll-Ist Vergleich

Zusammenfassung: Im Teil Datenbeschaffung der zweiten Fallstudie haben Sie die InfoSource A_ISS_### angelegt. Da diese für das ODS-Objekt A_OS_### vorgesehen ist, haben Sie das InfoObject 0RECORDMODE in die Kommunikationsstruktur aufgenommen. Es dient als Indikator für das Delta-Update, das bei einem ODS-Objekt verschiedenartig ausgeführt werden kann. Sie haben in den Übertragungsregeln für 0RECORDMODE das Kennzeichen N für Neues Image als Konstante definiert. Für das Merkmal Land ### haben Sie im Rahmen eines Data Cleaning Szenarios in den Übertragungsregeln eine Formel angelegt, in der die Merkmalsausprägung D in DE innerhalb einer IF-Abfrage transformiert wird, um die Konsistenz der Daten wiederherzustellen. Für den InfoCube A_ICS_### wurden von Ihnen Fortschreibungsregeln erstellt, mit deren Hilfe die Daten aus dem ODS-Objekt A_OS_### in den InfoCube übertragen werden. Im Rahmen der InfoPackage-Pflege für das Objekt A_IPS_### haben Sie in der Vorschau und Simulation den Dateiinhalt und die Struktur der Daten in der Transferstruktur betrachtet. Im Bereich der Kommunikationsstruktur haben Sie festgestellt, dass die Daten nun im Vergleich zur Transferstruktur in geänderter Form vorliegen. In der Administration des ODSObjektes A_OS_### konnten Sie nachvollziehen, dass die Daten aus Ihrem Request zunächst in einer inaktiven Form vorliegen und erst von Ihnen aktiviert werden müssen. Um sie zu aktivieren, haben Sie den Qualitätsstatus auf OK gesetzt. Anschließend wurden die Daten in den InfoCube A_ICS_### fortgeschrieben. Als letzte Aufgabe wurde von Ihnen die Fortschreibung neuer Daten in den InfoCube A_ICI_### bewältigt, der aus der ersten Fallstudie bekannt ist. Sie haben in der Administration des InfoCubes erkannt, dass nachträglich geladene Datensätze mit identischen Merkmalsausprägungen im InfoCube nicht zu einem einzigen Datensatz zusammengefasst werden.

5.3 Teil III – Reporting Basierend auf dem zuvor definierten MultiProvider wird eine Query erstellt, welche die Soll- und Ist-Daten gegenüberstellt. Zu diesem Zweck wird eine Merkmalsstruktur in der Query angelegt, die über Selektionen eine Unterscheidung der Kennzahlen des MultiProviders anhand des technischen Merkmals InfoProvider vornimmt. Durch diese Selektionen werden Ist-Daten und Soll-Daten des MultiProviders getrennt in der Query abgebildet. Über eine Formel wird eine weitere Komponente dieser Struktur bestimmt, die über eine Berechnungsvorschrift aus den beiden zuvor definierten Selektionen hervorgeht. Die Merkmalsstruktur hat

5.3 Teil III – Reporting

229

für alle Kennzahlen im MultiProvider Gültigkeit. Um kritische Kennzahlwerte im Bericht hervorzuheben, werden in der Query Ausnahmebedingungen definiert. Diese werden für jede Kennzahl in Kombination mit einem oder mehreren Merkmalen festgelegt und verfügen über einen Schwellwert oder ein Schwellwertintervall. Wenn sich die Kennzahl zur Querylaufzeit in diesem Intervall befindet, so wird beispielsweise die betroffene Zelle in der Ergebnistabelle entsprechend der ausgelösten Ausnahmebedingung farblich hinterlegt. Dadurch sind kritische Werte einer Auswertung für den Betrachter auffälliger. Im Anschluss wird im BEx Web Application Designer ein neues Web Template auf Basis des bereits abspeicherten Web Templates aus der vorherigen Fallstudie erstellt. Um die Startansicht zur Laufzeit der Query zu optimieren, wird erneut ein View als Datengrundlage verwendet. Allerdings wird der generische Navigationsblock aus dem Web Template entfernt und durch eine Dropdownbox und ein hierarchisches Kontextmenü ersetzt. Die Reduzierung der Navigationsmöglichkeiten ist erwünscht, weil dadurch die Handhabung des Berichtes vereinfacht wird. Die beiden zur Navigation eingesetzten Web Items erhalten die Eigenschaft, dass sie nur bestimmte Merkmale des Views enthalten und auf diesen Einfluss haben. Zur Querylaufzeit wirken sie sich wie Filter aus. In ein leeres Web Template wird das Web Item Rollenmenü eingebunden, welches es möglich macht, die bisher erstellten Reports komfortabel aus einer Baumstruktur heraus aufzurufen. Es wird dahingehend angepasst, dass nur ein Teil der für das Reporting eingesetzten Elemente zur Selektion freigegeben ist. Dadurch sind etwa nur die Web Templates sichtbar, während die Queries verborgen bleiben. Der BEx Web Application Designer verfügt nur über begrenzte Möglichkeiten zum Editieren von HTML-Dokumenten. Darum wird eine extern erstellte Webseite in das SAP BW geladen, die über zwei Frames verfügt, so dass sowohl das Rollenmenü als auch die Reports in einem einzigen Fenster eines Webbrowsers dargestellt werden können. Somit ergibt sich ein Informationsportal, welches Zugriff auf alle vom Anwender erstellten Reports bietet. 5.3.1 Anlegen der Query Legen Sie im BEx Query Designer eine neue Query an, für die Sie den MultiProvider Soll-Ist Vergleich Fallstudie BW ### als InfoProvider auswählen. Ziehen Sie die Kennzahl Umsatz in das Feld Spalten (siehe Abb. 5.25. Struktur anlegen, Schritt 1). Klicken Sie anschließend rechts innerhalb des Feldes Spalten und wählen Sie im kontextsensitiven Menü den Eintrag Neue Struktur (siehe Abb. 5.25. Struktur anlegen, Schritt 2).

230

5 Fallstudie II – Soll-Ist Vergleich

Abb. 5.25. Struktur anlegen

Öffnen Sie mit der rechten Maustaste das Kontextmenü zur eben angelegten Struktur (siehe Abb. 5.26. Selektion anlegen, Schritt 1) und legen Sie eine Neue Selektion an (siehe Abb. 5.26. Selektion anlegen, Schritt 2). Geben Sie im Feld Beschreibung den Text Ist ein (siehe Abb. 5.26. Selektion anlegen, Schritt 3), klappen Sie den Baum Dimensionen am Knoten Datenpaket auf (siehe Abb. 5.26. Selektion anlegen, Schritt 4) und expandieren dessen Kindknoten InfoProvider. Öffnen Sie den Knoten Werte (siehe Abb. 5.26. Selektion anlegen, Schritt 5) und ziehen Sie den Eintrag Ist-Daten Fallstudie BW ### in das Feld Beschreibung (siehe Abb. 5.26. Selektion anlegen, Schritt 6). Hinweis: Abhängig von Ihrer Version der SAPgui kann beim Öffnen des Knotens Werte der Dialog Auswahl für InfoProvider erscheinen. Fügen Sie in diesem Fall den Eintrag Ist-Daten Fallstudie BW ### zur Auswahl hinzu. Bestätigen Sie die Selektion, indem Sie den Dialog mit OK schließen und den Eintrag Ist-Daten Fallstudie BW ### in das Feld Beschreibung ziehen. Schließen Sie das Fenster mit OK (siehe Abb. 5.26. Selektion anlegen, Schritt 7) und erstellen Sie analog die Selektion Soll mit dem InfoProvider Soll-Daten Fallstudie BW ### als Inhalt.

5.3 Teil III – Reporting

231

Abb. 5.26. Selektion anlegen

Öffnen Sie erneut das Kontextmenü zur Struktur (siehe Abb. 5.27. Formel anlegen, Schritt 1) und wählen Sie Neue Formel (siehe Abb. 5.27. Formel anlegen, Schritt 2). Im Pflegedialog vergeben Sie die Beschreibung Abweichung (siehe Abb. 5.27. Formel anlegen, Schritt 3) und legen die Formel ‚Ist’ % ‚Soll’ an, indem Sie per Drag & Drop die Strukturelemente (siehe Abb. 5.27. Formel anlegen, Schritt 4 und Schritt 7) und per Mausklick die prozentuale Abweichung aus dem Bereich Funktionen (siehe Abb. 5.27. Formel anlegen, Schritt 5) im Feld Formel anordnen (siehe Abb. 5.27. Formel anlegen, Schritt 6). Klicken Sie auf OK (siehe Abb. 5.27. Formel anlegen, Schritt 8).

232

5 Fallstudie II – Soll-Ist Vergleich

Abb. 5.27. Formel anlegen

Ziehen Sie aus der Dimension Produkt die Produktgruppe in die Spalten, aus der Dimension Zeit das Merkmal KalJahr/Quartal in die Zeilen sowie das Merkmal Land aus der Dimension Region in den Bereich Freie Merkmale. Legen Sie nun Ausnahmebedingungen an, indem Sie auf Exception klicken (siehe Abb. 5.28. Exceptions anlegen, Schritt 1). Tragen Sie unter Beschreibung Exception Abweichung ein (siehe Abb. 5.28. Exceptions anlegen, Schritt 2). Selektieren Sie aus der Choicebox Kennzahlen den Eintrag Umsatz und aus Struktur Abweichung (siehe Abb. 5.28. Exceptions anlegen, Schritt 3). Anschließend betätigen Sie die Schaltfläche Neu (siehe Abb. 5.28. Exceptions anlegen, Schritt 4) und tragen im Feld Bis –5 ein (siehe Abb. 5.28. Exceptions anlegen, Schritt 5). Als Alert Level wählen Sie Schlecht 7 (siehe Abb. 5.28. Exceptions anlegen, Schritt 6) und klicken auf Übernehmen (siehe Abb. 5.28. Exceptions anlegen, Schritt 7). Legen Sie als weitere Alert Levels die Wertebereiche –5 bis 5 als Mittel 4 und 15 bis # als Gut 1 an. Wechseln Sie in den Kartenreiter Gültigkeitsbereich der Exception (siehe Abb. 5.28. Exceptions anlegen, Schritt 8) und ändern Sie den

5.3 Teil III – Reporting

233

Gültigkeitsbereich für alle nicht aufgeführten Merkmale auf Alles (empfohlen bei relativen Größen) (siehe Abb. 5.28. Exceptions anlegen, Schritt 9). Schließen Sie den Dialog mit OK (siehe Abb. 5.28. Exceptions anlegen, Schritt 10). Sichern Sie Ihre Query (siehe Abb. 5.28. Exceptions anlegen, Schritt 11) im Ordner Fallstudie BW ### mit der Beschreibung Umsatz Soll-Ist Vergleich ### und dem technischen Namen QUERY2_###. Starten Sie anschließend aus dem BEx Query Designer heraus die Funktion Query im Web zeigen (siehe Abb. 5.28. Exceptions anlegen, Schritt 12).

234

5 Fallstudie II – Soll-Ist Vergleich

Abb. 5.28. Exceptions anlegen

Nachdem Sie sich am System eingeloggt haben, klicken Sie auf das Symbol Filterwert auswählen im Bereich Struktur und deselektieren Ist und Soll durch Entfernen der Häkchen. Übernehmen Sie den Filter. Wechseln Sie abschließend in das Liniendiagramm. Sie sollten nun eine Entwicklung der Abweichungen der Gesamtumsätze wie in Abb. 5.29. Query2 im Standard Web Template erkennen. Durch das Filtern nach einzelnen Ländern generieren Sie die Sichten der übrigen drei Reports.

5.3 Teil III – Reporting

235

Abb. 5.29. Query2 im Standard Web Template

5.3.2 Reporting im BEx Web Application Designer Einen ähnlichen Aufbau soll auch das Web Template zur Betrachtung der nach Produktgruppen differenzierten Abweichungen haben. Schließen Sie den BEx Query Designer sowie den Webbrowser und starten Sie stattdessen den BEx Web Application Designer. Klicken Sie in der Werkzeugleiste auf Öffnen.... Wählen Sie im Dialog Web Template öffnen das Web Template Umsatz Ist-Daten ### aus und bestätigen Sie mit OK. Wählen Sie in der Menüleiste unter Web Template die Funktion Speichern unter... aus. Markieren Sie den Ordner Fallstudie BW ### und Sichern Sie unter der Beschreibung Umsatz Soll-Ist Vergleich ### sowie dem technischen Namen WEBTEMPLATE3_###. Wählen Sie im Web Template den generischen Navigationsblock an und drücken Sie entf. Klicken Sie mit der rechten Maustaste in die nun leere Tabelle und selektieren Sie im Kontextmenü Spalte einfügen. In die linke Spalte ziehen Sie das Web Item Dropdownbox (siehe Abb. 5.30. Web Template anpassen, Schritt 1), in die rechte das Web Item Hierarchisches Kontextmenü (siehe Abb. 5.30. Web Template anpassen, Schritt 2). Legen Sie über den Punkt Werkzeuge der Menüleiste (siehe Abb. 5.30. Web Template anpassen, Schritt 3) eine neue View Definition an und wählen Sie basierend auf einer Query... (siehe Abb. 5.30. Web Template anpassen, Schritt 4).

236

5 Fallstudie II – Soll-Ist Vergleich

Markieren Sie Ihre Query Umsatz Soll-Ist Vergleich ### und bestätigen Sie mit OK.

Abb. 5.30. Web Template anpassen

Melden Sie sich am SAP System an. Setzen Sie im Bereich Struktur einen Filter derart (siehe Abb. 5.31. View anlegen, Schritt 1), dass nur Abweichung angezeigt wird (siehe Abb. 5.31. View anlegen, Schritt 2 und Schritt 3). Geben Sie als Beschreibung Umsatz Soll-Ist Vergleich View ### sowie als Technischer Name VIEW2_### (siehe Abb. 5.31. View anlegen, Schritt 4) ein und klicken Sie auf View sichern (siehe Abb. 5.31. View anlegen, Schritt 5). Schließen Sie den Webbrowser und wechseln Sie zurück in den BEx Web Application Designer. Hier sollte das Web Item Hierarchisches Kontexmenü noch markiert sein.

5.3 Teil III – Reporting

237

Abb. 5.31. View anlegen

Klicken Sie im Bereich Eigenschaften: Umsatz Soll-Ist Vergleich ### in der Registerkarte Allgemein auf View auswählen. Im Popup Query / View öffnen wählen Sie den Eintrag Umsatz Soll-Ist Vergleich View ### an und bestätigen mit OK. Im Kartenreiter Web Item (siehe Abb. 5.32. Beeinflussten DataProvider auswählen, Schritt 1) im Abschnitt Allgemein tragen Sie die Überschrift Auswahl Region (siehe Abb. 5.32. Beeinflussten DataProvider auswählen, Schritt 2) und im Abschnitt Speziell in der Zeile Merkmal/Struktur Land ein (siehe Abb. 5.32. Beeinflussten DataProvider auswählen, Schritt 3). Klicken Sie in das Feld Hierarchiename und wählen Sie die Hierarchie A_HL_### aus (siehe Abb. 5.32. Beeinflussten DataProvider auswählen, Schritt 3). Der Beeinflusste DataProvider ist der DATAPROVIDER_1 (siehe Abb. 5.32. Beeinflussten DataProvider auswählen, Schritte 4 bis 6).

238

5 Fallstudie II – Soll-Ist Vergleich

Abb. 5.32. Beeinflussten DataProvider auswählen

Markieren Sie nun die DROPDOWNBOX_1 (siehe Abb. 5.33. Eigenschaften der Dropdownbox pflegen, Schritt 1) und tragen im Register Web Item als Überschrift Filterwerte Struktur ein (siehe Abb. 5.33. Eigenschaften der Dropdownbox pflegen, Schritt 2). Im Bereich Speziell wählen Sie als Merkmal/Struktur Struktur (siehe Abb. 5.33. Eigenschaften der Dropdownbox pflegen, Schritt 3), setzen den Lesemodus auf Gebuchte Werte, aktivieren den Eintrag „Alle Werte“ nicht anzeigen und wählen als Beeinflusste DataProvider den DATAPROVIDER_1 (siehe Abb. 5.33. Eigenschaften der Dropdownbox pflegen, Schritt 4).

5.3 Teil III – Reporting

239

Abb. 5.33. Eigenschaften der Dropdownbox pflegen

Markieren Sie anschließend den CHART_1 und vergeben Sie als Überschrift Liniendiagramm (siehe Abb. 5.34. Eigenschaften des Diagramms bearbeiten, Schritt 1). Selektieren Sie im Abschnitt Speziell die Einträge Achsen zur Anzeige vertauschen (siehe Abb. 5.34. Eigenschaften des Diagramms bearbeiten, Schritt 2) und Exceptions bei der Chart Anzeige ignorieren (siehe Abb. 5.34. Eigenschaften des Diagramms bearbeiten, Schritt 3). Klicken Sie unter Grafik bearbeiten auf die Schaltfläche in der Spalte Wert (siehe Abb. 5.34. Eigenschaften des Diagramms bearbeiten, Schritt 4). Im Pflegedialog Chart bearbeiten setzen Sie die Anzahl Datenreihen auf 3 und die Anzahl Datenpunkte auf 8 (siehe Abb. 5.34. Eigenschaften des Diagramms bearbeiten, Schritt 5). Dann klicken Sie mit der rechten Maustaste in die Diagrammvorschau und wählen aus dem Kontextmenü Chart Type... (siehe Abb. 5.34. Eigenschaften des Diagramms bearbeiten, Schritt 6). In der Liste Chart Type: setzen Sie den Diagrammtyp auf Lines (siehe Abb. 5.34. Eigenschaften des Diagramms bearbeiten, Schritt 7), anschließend markieren Sie den vierten Chart Subtype (siehe Abb. 5.34. Eigenschaften des Diagramms bearbeiten, Schritt 8). Bestätigen Sie Ihre Auswahl mit OK (siehe Abb. 5.34. Eigenschaften des Diagramms bearbeiten, Schritt 9). Über die Kontextmenüs der Diagrammelemente können Sie die Farbwahl der Diagrammfläche und der Datenreihen Ihren Wünschen anpassen. Beenden Sie den Dialog Chart bearbeiten mit OK (siehe Abb. 5.34. Eigenschaften des Diagramms bearbeiten, Schritt 10). Speichern Sie abschließend Ihr Web Template.

240

5 Fallstudie II – Soll-Ist Vergleich

Abb. 5.34. Eigenschaften des Diagramms bearbeiten

Legen Sie über die Schaltfläche Neu ein neues Template an. Ziehen Sie das Web Item Rollenmenü in das Template Fenster. In den Eigenschaften zum Rollenmenü wechseln Sie in das Register Web Item (siehe Abb. 5.35. Web Template Rollenmenü anlegen, Schritt 1) und setzen im Abschnitt Speziell Web Templates als Filter (siehe Abb. 5.35. Web Template Rollenmenü anlegen, Schritt 2). Unter Name des Ziel-Frame tragen Sie report ein (siehe Abb. 5.35. Web Template Rollenmenü anlegen, Schritt 2). Setzen Sie abschließend das Häkchen zu Anzeige von Benutzer und Logo (siehe Abb. 5.35. Web Template Rollenmenü anlegen, Schritt 3) und Keine Anzeige der ersten Ebene (siehe Abb. 5.35. Web Template Rollenmenü anlegen, Schritt 4). Speichern Sie das Template in Ihrem Ordner Fallstudie BW ### unter der Beschreibung Rollenmenü ### und dem technischen Namen WEBTEMPLATE4_###. Schließen Sie den Dialog mit Sichern ab.

5.3 Teil III – Reporting

241

Abb. 5.35. Web Template Rollenmenü anlegen

Öffnen Sie in einem Editor die Datei Startseite.htm und ersetzen Sie im Quelltext alle Vorkommen der Zeichenkette ### durch Ihre Gruppennummer und ID (siehe Abb. 5.36. Bearbeiten der Datei Startseite.htm, Schritt 1).

Abb. 5.36. Bearbeiten der Datei Startseite.htm

242

5 Fallstudie II – Soll-Ist Vergleich

Sichern Sie die Änderungen und schließen Sie den Editor. Anschließend wählen Sie in der Menüleiste des BEx Web Application Designers Web Template (siehe Abb. 5.37. Upload der Startseite.htm, Schritt 1) und führen die Funktion Datei zum Server hochladen aus (siehe Abb. 5.37. Upload der Startseite.htm, Schritt 2). Wählen Sie im Popup die zuvor bearbeitete Datei Startseite.htm aus (siehe Abb. 5.37. Upload der Startseite.htm, Schritt 3) und Öffnen sie (siehe Abb. 5.37. Upload der Startseite.htm, Schritt 4). Im darauf folgenden Dialog markieren Sie Ihren Ordner Fallstudie BW ### (siehe Abb. 5.37. Upload der Startseite.htm, Schritt 5), vergeben als Beschreibung Startseite ### und als Technischer Name WEBSITE1_### (siehe Abb. 5.37. Upload der Startseite.htm, Schritt 6). Sichern Sie Ihre Angaben (siehe Abb. 5.37. Upload der Startseite.htm, Schritt 7).

Abb. 5.37. Upload der Startseite.htm

Melden Sie sich über das SAPlogon am System an. In Ihrem Ordner Favoriten finden Sie den Ordner zu Ihrer Fallstudie, in welchem Sie doppelt auf den Link zur Startseite ### klicken. Nachdem Sie sich über den Webbrowser erneut angemeldet haben, wird Ihnen Ihre Web Application präsentiert. Rufen Sie über das Rollenmenü im linken Frame den Report Umsatz Soll-Ist Vergleich ### auf (siehe Abb. 5.38. Web Application im Frame Startseite.htm, Schritt 1). Selektieren Sie im hierarchischen Kontextmenü Auswahl Region nacheinander die einzelnen

5.3 Teil III – Reporting

243

Länder (siehe Abb. 5.38. Web Application im Frame Startseite.htm, Schritt 2). Sie können über die Diagramme oder die Einfärbung der Ergebnistabellen ablesen, dass die Produktgruppe Videorecorder in allen Ländern hinter den Sollwerten zurückgeblieben ist und die Abweichung tendenziell zunimmt. Demgegenüber übertreffen die Umsätze im Bereich DVD – Player regelmäßig die Vorgabewerte. Die Produktgruppe Plasma & LCD erfüllt allein in Dänemark nicht die Erwartungen der Geschäftsleitung.

Abb. 5.38. Web Application im Frame Startseite.htm

244

5 Fallstudie II – Soll-Ist Vergleich

Zusammenfassung: Der letzte Abschnitt der zweiten Fallstudie hat Ihnen die Möglichkeit gegeben, sich im BEx Query Designer mit individuellen Strukturen und Formeln zu befassen. Sie haben eine Struktur erstellt, um die Kennzahlen nach Soll- und Ist-Daten zu unterscheiden und die Abweichung zu berechnen. Die Ist-Daten werden allein aus dem InfoProvider Ist-Daten Fallstudie BW ### bezogen, die Soll-Daten hingegen liefert der InfoCube A_ICS_###. In der Struktur haben Sie eine Formel zur Berechnung der prozentualen Abweichung der Ist- von den Sollwerten erstellt. Abschließend legten Sie die Ausnahmebedingung Exception Abweichung an. In dieser wurden drei Stufen definiert, die in Abhängigkeit vom Wertebereich die Zellen in der Ergebnistabelle mit einem grünen, gelben oder roten Hintergrund versehen. Diese Ausnahmebedingung gilt nur für die Kennzahl Umsatz ### und das Strukturelement Abweichung. Sie haben im Webbrowser einen ersten Eindruck von den zu erstellenden Web Templates gewonnen. Bei der Betrachtung des Liniendiagramms ist Ihnen aufgefallen, dass im Standard Web Template die Ausnahmebedingungen sich auch im Diagramm wieder finden. Im BEx Web Application Designer stellt der View Umsatz Soll-Ist Vergleich View ### sicher, dass das Web Template Soll-Ist Vergleich Fallstudie BW ### bereits beim Aufruf über selektierte Filterwerte verfügt. Dieses neue Web Template basiert auf dem WEBTEMPLATE1_###, verfügt aber nicht über den generischen Navigationsblock, sondern über eine Dropdownbox und ein hierarchisches Kontextmenü. Sie haben zusätzlich das WEBTEMPLATE4_### für das Web Item Rollenmenü erstellt und anschließend eine eigene Webseite auf den Server übertragen. Zum Abschluss haben Sie Ihre Web Application ausgeführt, indem Sie die zuvor hochgeladene Webseite Startseite ### im Favoritenmenü des SAP Easy Access Fensters angewählt haben. Ihren zuvor erstellten Report haben Sie über das Rollenmenü aufgerufen und in den Frames Ihrer separat hochgeladenen Webseite betrachtet.

6 Fallstudie III – Bestandsdatenanalyse

In der dritten Fallstudie werden die in den ersten beiden Fallstudien erworbenen Kenntnisse in einem neuen Umfeld angewandt. Die zum Anlegen und zur Pflege der Objekte notwendigen Schritte sind aus den vorhergehenden Fallstudien bereits bekannt und dienen dem Festigen des praktischen Wissens. Der Schwerpunkt dieser Fallstudie liegt auf dem Bestandsdatenreporting, da sich hier die Kennzahlstruktur wesentlich von der zuvor verwendeten Kennzahl für Umsätze unterscheidet. Auch diese Fallstudie verfügt über eine Strukturierung in die Phasen der Datenmodellierung, der Datenbeschaffung und des Reporting. Aufgabenstellung und Szenario Mit der von Ihnen entwickelten Web Application für den Soll-Ist Vergleich und die Ist-Daten Analyse ist man im Unternehmen zufrieden und möchte darauf aufbauend weitere Reports verfügbar machen. Neben den Umsätzen werden vom Unternehmen die Kennzahlen zur Verwaltung der Lagerbestände als erfolgskritisch erachtet. Zur Senkung der Kosten will man den Bestand gelagerter Waren möglichst gering halten. Um sich einen Eindruck vom Einfluss der laufenden Maßnahmen zur Senkung des Lagerbestandes machen zu können, will die Geschäftsführung zum einen die Entwicklung des Lagerbestandes über den gesamten Zeitraum untersuchen, zum anderen will man einen Vergleich mit der Vorjahresperiode ziehen, um den Grad der Verbesserung ableiten zu können. Die IT-Abteilung entschließt sich, die Bestandsdatenanalyse über eine Bestandskennzahl und über je eine Flusskennzahl für Zu- und Abgänge zu realisieren. Ihre Aufgabe besteht darin, zunächst die Flusskennzahlen für Zu- und Abgänge anzulegen. Anschließend werden Sie eine Bestandskennzahl erstellen und dieser die zuvor angelegten Flusskennzahlen zuordnen. Danach werden Sie einen neuen InfoCube modellieren und diesem die Bestandskennzahl zuweisen. In der Phase der Datenbeschaffung werden Sie eine InfoSource derart definieren, dass sie für das initiale Befüllen des InfoCubes mit Bestandsdaten eingesetzt werden kann. In einer zweiten InfoSource werden Sie das Laden der Bestandsveränderungen einstellen. Der Ladevorgang selbst wird wie in den Fallstudien zuvor aus CSV-Dateien erfolgen, die Daten liegen bereits in konsistenter Form vor und werden aus der PSA direkt in den InfoCube fortgeschrieben. Sämtliche Bestandsdaten sind tagesgenau erfasst. Um die Wünsche der Unternehmensführung umsetzen zu können, werden zwei Queries erforderlich sein. Eine der Queries soll über Variablen zur Angabe eines Bezugsjahres verfügen und das Vorjahr automatisch ermitteln. Das Reporting soll sich in Bezug auf Handhabung und Anordnung der Web Items an den bereits erstellten Web Items orientieren.

246

6 Fallstudie III – Bestandsdatenanalyse

6.1 Teil I – Datenmodellierung Bestandskennzahlen werden in dieser Fallstudie für eine Lagerbestandsanalyse verwendet. Im Gegensatz zu Flusskennzahlen, bei den Lagerzugängen kann etwa der gesamte Zugang einer Periode über die Summe der einzelnen Zugänge ermittelt werden, können Bestandskennzahlen nicht über die Zeit aufsummiert werden. Das SAP BW bietet zwei verschiedene Möglichkeiten, um Bestandskennzahlen zu erfassen. Beide verwenden eine Bestandskennzahl, die den Bestand zu einem bestimmten Zeitpunkt abbildet. Die Zu- und Abgänge werden auf unterschiedliche Art und Weise abgebildet. Zum einen kann es nur eine einzige Flusskennzahl geben, die Bestandsveränderungen enthält. Zum anderen können die Zu- und Abgänge über zwei getrennte Flusskennzahlen erfasst werden. Welche Methode angewandt wird, ist vom Datenmodell und den verfügbaren Quelldaten abhängig. In der Fallstudie werden die Bestandsveränderungen über zwei getrennte Flusskennzahlen in das SAP BW geladen. Beide Kennzahlen müssen über identische Parameter verfügen, sie erhalten als Datentyp die Menge und als Mengeneinheit das grundlegende Merkmal 0UNIT, welches Mengeneinheiten wie zum Beispiel Stück enthält. An der Bestandskennzahl werden weitgehend identische Einstellungen vorgenommen, allerdings wird eine Ausnahmeaggregation eingestellt. Sie tritt in Kraft, wenn über die zeitliche Dimension aggregiert wird. Da dies bei Beständen nicht sinnvoll ist, muss eine Auflösung eines solchen Ereignisses vorgegeben werden, um eine Fehldeutung zu vermeiden. Abschließend werden die beiden Flusskennzahlen in die Definition der Bestandskennzahl aufgenommen, um einen Bezug zu den Zu- und Abgängen zu schaffen. Bestandskennzahlen beziehen sich im SAP BW auf das Zeitmerkmal Kalendertag, sie sind also tagesgenau abgelegt. In der InfoCube-Definition muss dieses daher in die zeitliche Dimension aufgenommen werden. Das Bezugsmerkmal einer Bestandskennzahl ist für die Ausnahmeaggregation entscheidend, da die Aggregation auf Basis dieses Merkmals durchgeführt wird. Neben dem Zeitbezugsmerkmal, das immer gesetzt sein muss, können auch andere Merkmale verwendet werden. 6.1.1 Anlegen der Kennzahlen Melden Sie sich über das SAPlogon am SAP BW System an und rufen Sie über die Transaktion RSA1 die Administrator Workbench auf. In der Modellierungssicht InfoObjects legen Sie in Ihrer InfoArea A_IA_### im InfoObjectCatalog Kennzahlen Fallstudie ### eine neue Kennzahl an. Vergeben Sie den technischen Namen A_KA_### und die Beschreibung lang Abgang ### (siehe Abb. 6.1. Kennzahl Abgang anlegen, Schritt 1) und schließen Sie Ihre Eingaben mit Weiter ab (siehe Abb. 6.1. Kennzahl Abgang anlegen, Schritt 2). Im Pflegebildschirm Kennzahl A_KA_### anlegen: Detail selektieren Sie als Typ den Eintrag Menge (siehe Abb. 6.1. Kennzahl Abgang anlegen, Schritt 3). Der Datentyp wird vom System automatisch auf QUAN – Mengenfeld, zeigt auf ein Einheitenfeld mit dem Format UN geändert. Wählen Sie im Feld Einheit / Währung 0UNIT

6.1 Teil I – Datenmodellierung

247

(siehe Abb. 6.1. Kennzahl Abgang anlegen, Schritt 4 und Schritt 5). Ändern Sie anschließend die Beschreibung kurz in Abgang (siehe Abb. 6.1. Kennzahl Abgang anlegen, Schritt 6). Prüfen und Aktivieren Sie die Kennzahl (siehe Abb. 6.1. Kennzahl Abgang anlegen, Schritt 7).

Abb. 6.1. Kennzahl Abgang anlegen

Definieren Sie nun über Anlegen... (siehe Abb. 6.1. Kennzahl Abgang anlegen, Schritt 8) die Kennzahl Zugang ### mit dem technischen Namen A_KZ_###, indem Sie die zuvor angelegte Kennzahl A_KA_### als Vorlage verwenden. Vergeben Sie noch die Beschreibung kurz Zugang und Aktivieren Sie auch diese Kennzahl. Betätigen Sie erneut die Schaltfläche Anlegen.... Tragen Sie als technischen Namen A_KB_### und als Beschreibung lang Bestand ### ein. Analog zu den beiden vorherigen Kennzahlen setzen Sie den Typ auf Menge (siehe Abb. 6.2.

248

6 Fallstudie III – Bestandsdatenanalyse

Kennzahl Bestand anlegen, Schritt 1) und die Einheit / Währung auf 0UNIT (siehe Abb. 6.2. Kennzahl Bestand anlegen, Schritt 2). Ändern Sie die Beschreibung kurz in Bestand (siehe Abb. 6.2. Kennzahl Bestand anlegen, Schritt 3). Wechseln Sie nun in das Register Aggregation (siehe Abb. 6.2. Kennzahl Bestand anlegen, Schritt 4). Dort setzen Sie als Ausnahmeaggregation letzter Wert (siehe Abb. 6.2. Kennzahl Bestand anlegen, Schritt 5). Selektieren Sie im Gruppierungsfeld Fluß-/Bestandsgröße den Eintrag Bestand mit Zu- und Abgang. Tragen Sie unter Zugang A_KZ_### und unter Abgang A_KA_### ein (siehe Abb. 6.2. Kennzahl Bestand anlegen, Schritt 6). Prüfen Sie auch diese Kennzahl (siehe Abb. 6.2. Kennzahl Bestand anlegen, Schritt 7) und schließen Sie das Popup Protokoll mit Weiter (siehe Abb. 6.2. Kennzahl Bestand anlegen, Schritt 8). Aktivieren Sie abschließend die Kennzahl Bestand (siehe Abb. 6.2. Kennzahl Bestand anlegen, Schritt 7), schließen Sie erneut das Protokoll (siehe Abb. 6.2. Kennzahl Bestand anlegen, Schritt 8) und bestätigen Sie das Popup Aktivieren mit Ja (siehe Abb. 6.2. Kennzahl Bestand anlegen, Schritt 9). Kehren Sie über Beenden zur Administrator Workbench zurück.

Abb. 6.2. Kennzahl Bestand anlegen

6.1 Teil I – Datenmodellierung

249

6.1.2 Anlegen des InfoCubes für die Bestandsdaten Legen Sie in der Sicht InfoProvider in Ihrer InfoArea Fallstudie BW ### den InfoCube A_ICB_### mit der Beschreibung Bestandsdaten Fallstudie BW ### an. Betätigen Sie die Schaltfläche Anlegen. Ordnen Sie im Register Merkmale der Tabelle Struktur die Merkmale A_ML_### und A_MPG_### aus der Vorlage zu. Klicken Sie auf Dimensionen..., schließen Sie das Popup Dimensionen anlegen mit Nein und legen Sie im Pflegebildschirm Dimensionen definieren die Dimensionen Produkt und Region an. Ordnen Sie das Land der Region und die Produktgruppe der Dimension Produkt zu. Verlassen Sie die Maske mit Weiter. Über die Schaltfläche Nav.Attribute... öffnen Sie das Popup Navigationsattribute ein-/ausschalten, hier setzen Sie das Häkchen hinter Produkthauptgruppe ###. Bestätigen Sie auch hier mit Weiter. Verzweigen Sie in den Kartenreiter Zeitmerkmale. Übernehmen Sie die Zeitmerkmale Kalendertag, Kalenderjahr / Monat, Quartal, Kalenderjahr / Quartal und Kalenderjahr aus der Vorlage in die Struktur. Schließlich stellen Sie die Registerkarte Kennzahlen in den Vordergrund und übertragen den Eintrag A_KB_### (siehe Abb. 6.3. InfoCube für Bestandsdaten anlegen, Schritt 1) aus der Vorlage in die Struktur (siehe Abb. 6.3. InfoCube für Bestandsdaten anlegen, Schritt 2). Das System ergänzt automatisch die geklammerten Kennzahlen A_KA_### sowie A_KZ_###. Prüfen Sie den InfoCube (siehe Abb. 6.3. InfoCube für Bestandsdaten anlegen, Schritt 3) und beachten Sie im Popup Bestandsparameter zum InfoCube, dass als Merkmale der Gültigkeitstabelle für Bestände das vom System für die Bestandskennzahl erwartete Zeitmerkmal Kalendertag vorausgewählt ist. Schließen Sie das Popup mit Weiter (siehe Abb. 6.3. InfoCube für Bestandsdaten anlegen, Schritt 4), Aktivieren Sie den InfoCube (siehe Abb. 6.3. InfoCube für Bestandsdaten anlegen, Schritt 5) und verlassen Sie den Pflegebildschirm durch Beenden.

250

6 Fallstudie III – Bestandsdatenanalyse

Abb. 6.3. InfoCube für Bestandsdaten anlegen

Zusammenfassung: In der Datenmodellierung der dritten Fallstudie haben Sie die Kennzahlen für die Verarbeitung von Beständen angelegt, bestehend aus der Bestandskennzahl A_KB_### für den Lagerbestand sowie den Flusskennzahlen A_KA_### für Abgänge und A_KZ_### für Zugänge. Die InfoObjects wurden in den InfoCube A_ICB_### gepflegt, der mehr und zudem feinere Zeitmerkmale als die bisher erstellten InfoCubes aufweist. Für Bestandskennzahlen wird der Kalendertag als Zeitbezugsmerkmal eingetragen, so dass diese bis auf den Tag genau im InfoCube abgelegt werden müssen.

6.2 Teil II – Datenbeschaffung Das Befüllen eines InfoCubes mit Bestandsdaten kann entweder mit oder ohne initialen Bestand erfolgen. Wenn kein initialer Bestand vorliegt, so wird von einem leeren Lager zu Beginn der Bestandsveränderungen ausgegangen. Ein Anfangsbestand kann verwendet werden, wenn die Bestände bei der Einführung einer Lagerbestandsanalyse bekannt sind. Es ist dann weiterhin möglich, historische Bestandsveränderungen in den InfoCube zu laden, allerdings müssen nicht alle Zuund Abgänge geladen werden, um den aktuell gültigen Lagerbestand zu erhalten.

6.2 Teil II – Datenbeschaffung

251

Um einen initialen Ladevorgang vornehmen zu können, muss in der InfoSource und im InfoPackage eine entsprechende Markierung gesetzt sein, damit der Anfangsbestand aus der DataSource entnommen wird. In den Fortschreibungsregeln des InfoCubes wird eine Zuordnung des Datenfeldes Bestand zur Kennzahl Zugang vorgenommen. Um die Performance des InfoCubes zu erhöhen, wird der Request nach erfolgreichem Ladevorgang komprimiert. Die Bestandsveränderungen werden über eine weitere InfoSource in das Datenziel übertragen. An dieser Stelle kann keine Bestandskennzahl verwendet werden, sondern nur Flusskennzahlen. In den Fortschreibungsregeln erfolgt eine exakte Zuordnung von Zu- und Abgängen. 6.2.1 Anlegen der InfoSources für Anfangsbestand und Bestandsveränderungen Wechseln Sie in der Administrator Workbench zur Sicht InfoSources. Legen Sie in Ihrer Anwendungskomponente Fallstudie BW ### eine neue InfoSource A_ISB_### mit der Beschreibung lang Bestandsdaten initial Fallstudie BW ### an. Weisen Sie dieser über DataSource zuweisen... das Quellsystem A_QS_FSBW zu. Das Popup Änderungen sichern? bestätigen Sie mit Ja. Tragen Sie im Pflegebildschirm InfoSource A_ISB_### ändern im Kartenreiter DataSource/Transferstruktur in der Spalte InfoObject untereinander A_MPG_###, A_ML_###, 0CALDAY, 0UNIT, A_KB_###, A_KZ_### und A_KA_### ein (siehe Abb. 6.4. InfoSource für Anfangsbestand anlegen, Schritt 1). Setzen Sie das Häkchen bei Anfangsbestand (siehe Abb. 6.4. InfoSource für Anfangsbestand anlegen, Schritt 2). Verzweigen Sie ins Register Übertragungsregeln (siehe Abb. 6.4. InfoSource für Anfangsbestand anlegen, Schritt 3) und klicken Sie auf Übertragungsregeln vorschlagen (siehe Abb. 6.4. InfoSource für Anfangsbestand anlegen, Schritt 4). Zum Abschluss Aktivieren Sie Ihre InfoSource (siehe Abb. 6.4. InfoSource für Anfangsbestand anlegen, Schritt 5).

252

6 Fallstudie III – Bestandsdatenanalyse

Abb. 6.4. InfoSource für Anfangsbestand anlegen

Beenden Sie (siehe Abb. 6.4. InfoSource für Anfangsbestand anlegen, Schritt 6) und legen Sie in der Administrator Workbench eine weitere InfoSource an. Diese trägt den technischen Namen A_ISV_### und die Beschreibung lang Bestandsveränderungen Fallstudie BW ###. Weisen Sie auch hier das Quellsystem A_QS_FSBW zu, bestätigen Sie das Popup Änderungen sichern? mit Ja und tragen Sie in der Registerkarte DataSource/Transferstruktur nacheinander in der Spalte InfoObject A_MPG_###, A_ML_###, 0CALDAY, 0UNIT, A_KA_### und A_KZ_### ein (siehe Abb. 6.5. InfoSource für Bestandsveränderungen anlegen, Schritt 1). Im Register Übertragungsregeln (siehe Abb. 6.5. InfoSource für Bestandsveränderungen anlegen, Schritt 2) betätigen Sie die Schaltfläche Übertragungsregeln vorschlagen (siehe Abb. 6.5. InfoSource für Bestandsveränderungen anlegen, Schritt 3) und Aktivieren die InfoSource (siehe Abb. 6.5. InfoSource für Bestandsveränderungen anlegen, Schritt 4). Verlassen Sie die Ansicht über Beenden (siehe Abb. 6.5. InfoSource für Bestandsveränderungen anlegen, Schritt 5).

6.2 Teil II – Datenbeschaffung

253

Abb. 6.5. InfoSource für Bestandsveränderungen anlegen

Navigieren Sie in der Administrator Workbench in den Bereich InfoProvider und legen Sie für den InfoCube A_ICB_### Fortschreibungsregeln an. Weisen Sie als Datenquelle die InfoSource A_ISB_### zu (siehe Abb. 6.6. Fortschreibungsregeln für Anfangsbestand pflegen, Schritt 1) und Prüfen Sie Ihre Eingaben (siehe Abb. 6.6. Fortschreibungsregeln für Anfangsbestand pflegen, Schritt 2). Schließen Sie den Hinweis Fortschreibungsregeln: Einstieg durch Weiter (siehe Abb. 6.6. Fortschreibungsregeln für Anfangsbestand pflegen, Schritt 3). Wechseln Sie über Nächstes Bild in den folgenden Bildschirm Fortschreibungsregeln anlegen: Regeln (siehe Abb. 6.6. Fortschreibungsregeln für Anfangsbestand pflegen, Schritt 4) und übergehen Sie erneut das Popup Fortschreibungsregeln: Einstieg (siehe Abb. 6.6. Fortschreibungsregeln für Anfangsbestand pflegen, Schritt 3).

254

6 Fallstudie III – Bestandsdatenanalyse

Abb. 6.6. Fortschreibungsregeln für Anfangsbestand pflegen

Prüfen und Aktivieren Sie die Fortschreibungsregel, in der die Kennzahl Zugang ### aus dem Quellfeld Bestand ### fortgeschrieben wird. Kehren Sie mit Beenden zur Administrator Workbench zurück und legen Sie erneut Fortschreibungsregeln für den InfoCube A_ICB_### an. Wählen Sie als Datenquelle die InfoSource A_ISV_###: Prüfen Sie und klicken Sie auf Nächstes Bild. Prüfen und Aktivieren Sie auch diese Fortschreibungsregeln. Kehren Sie über Beenden zur Administrator Workbench zurück. 6.2.2 Einlesen des Anfangsbestands und der Bestandsveränderungen Rufen Sie die Sicht InfoSources auf und wählen Sie für die InfoSource Bestandsdaten initial Fallstudie BW ### den Eintrag des Kontextmenüs InfoPackage anlegen.... Als InfoPackage-Bezeichnung vergeben Sie A_IPB_###. Markieren Sie die Zeile A_ISB_### in der Tabelle DataSource und Sichern Sie Ihre Angaben. Im Pflegebildschirm Scheduler (InfoPackage pflegen) stellen Sie das Register Fremddaten in den Vordergrund. Tragen Sie als Name der Datei den Pfad zur Datei Anfangsbestand.csv ein, wählen Sie Dateityp CSV-Datei und setzen Sie den Eintrag Anzahl der zu ignorierenden Kopfzeilen auf 1. Führen Sie in der Vorschau die Simulation durch und kontrollieren Sie die Datensätze (vgl. Abb. 6.7. Vorschau und Simulation Anfangsbestand).

6.2 Teil II – Datenbeschaffung

255

Abb. 6.7. Vorschau und Simulation Anfangsbestand

Nachdem Sie die Betrachtung abgeschlossen haben, kehren Sie zum Pflegebildschirm Scheduler (InfoPackage pflegen) und markieren Sie im Kartenreiter Fortschreibung den Fortschreibungsmodus mit der Bezeichnung Anfangsbestand aufbauen. Im Register Einplanen beginnen Sie das Laden der Daten über die Schaltfläche Start. Überprüfen Sie die korrekte Verbuchung der Datensätze im Monitor und kehren Sie zur Administrator Workbench zurück. Navigieren Sie in den Bereich InfoProvider und wählen Sie aus dem Kontextmenü Ihres InfoCubes Bestandsdaten Fallstudie BW ### die Funktion Administrieren. Markieren Sie im Kartenreiter Requests das soeben importierte Datenpaket mit dem Eintrag A_IPB_### in der Spalte InfoPackage (siehe Abb. 6.8. InfoCube komprimieren, Schritt 1). Wechseln Sie in die Registerkarte Komprimieren (siehe Abb. 6.8. InfoCube komprimieren, Schritt 2) und stellen Sie sicher, dass im gleichnamigen Gruppierungsfeld im Feld bis Request-ID die Nummer Ihres Requests eingetragen ist (siehe Abb. 6.8. InfoCube komprimieren, Schritt 3). Komprimieren Sie den InfoCube über die Schaltfläche Freigeben (siehe Abb. 6.8. InfoCube komprimieren, Schritt 4). Beenden Sie das Administrieren der Datenziele (siehe Abb. 6.8. InfoCube komprimieren, Schritt 5).

256

6 Fallstudie III – Bestandsdatenanalyse

Abb. 6.8. InfoCube komprimieren

In der Administrator Workbench kehren Sie in die Sicht InfoSources zurück und legen nun ein InfoPackage für die InfoSource A_ISV_### an. Tragen Sie unter InfoPackage-Bezeichnung A_IPV_### ein und markieren Sie in der Tabelle DataSource die Zeile Bestandsveränderungen Fallstudie BW ###. Sichern Sie Ihre Angaben. Verzweigen Sie in das Register Fremddaten und wählen Sie die Datei Bestandsveränderungen.csv aus. Setzen Sie den Dateityp auf CSV-Datei und die Anzahl der zu ignorierenden Kopfzeilen auf 1. Betrachten Sie in der Vorschau den Dateiinhalt und führen Sie die Simulation aus (vgl. Abb. 6.9. Vorschau und Simulation Bestandsveränderungen).

6.3 Teil III – Reporting

257

Abb. 6.9. Vorschau und Simulation Bestandsveränderungen

Wenn Sie in den Bildschirm Scheduler (InfoPackage pflegen) zurückgekehrt sind, beginnen Sie das Laden der Daten im Register Einplanen über die Schaltfläche Start. Kontrollieren Sie den Status des Ladevorgangs im Monitor. Zusammenfassung: In der Phase der Datenbeschaffung der dritten Fallstudie wurden zwei verschiedene InfoSources erstellt. Die InfoSource A_ISB_### wurde dazu verwendet, um den Anfangsbestand in den InfoCube zu laden. In den Fortschreibungsregeln dieses InfoCubes erfolgt die Zuordnung von den Beständen zu den Zugängen. Die zweite von Ihnen angelegte InfoSource A_ISV_### definiert die Übertragung der Bestandsveränderungen in den InfoCube A_ICB_###. In diesem Ladevorgang werden die Zugänge und Abgänge erfasst, keine absoluten Bestände.

6.3 Teil III – Reporting Im BEx Query Designer wird neben einer Query zur Bestandsdatenanalyse eine Anfrage zum Vergleich der Bestandsdaten eines Bezugsjahres und des dazugehörigen Vorjahres erstellt. Das Bezugsjahr wird der Query über eine Variable mitge-

258

6 Fallstudie III – Bestandsdatenanalyse

teilt und kann bei der Ausführung individuell angegeben werden. Dadurch kann flexibler auf die Query Einfluss genommen werden, als es mit Filtern möglich ist. Dem steht allerdings das Erfordernis einer Benutzereingabe beim Aufrufen des Berichtes entgegen. Variablen werden in einer Merkmalsstruktur ähnlich einer Selektion angelegt und zu einem Merkmal entweder neu definiert oder aus den bereits vorhandenen selektiert. In der Query wird eine weitere Variable hinzugefügt, die über einen Variablen-Offset um eine Einheit reduziert wird. Dadurch kann eine automatische Berechnung des Vorjahres erfolgen und muss nicht wie das Bezugsjahr vom Anwender eingetragen werden. Basierend auf den bereits erstellten Web Templates werden im BEx Web Application Designer zwei neue Web Templates für das Bestandsdatenreporting erstellt. Die Besonderheit liegt in den Einstellungen zum Web Item Chart. Um die Entwicklung der Datenreihen prägnanter abzubilden, werden die Diagramme mit logarithmischen Trendlinien versehen. Es werden insgesamt drei Trendlinien in das Diagramm eingefügt, da eine größere Anzahl an Linien aufgrund der vergleichsweise geringen Größe der Zeichnungsfläche nicht mehr übersichtlich dargestellt wird. 6.3.1 Anlegen der Queries Starten Sie aus dem Startmenü den BEx Query Designer. Betätigen Sie die Schaltfläche Neue Query und wählen Sie im Dialog Neue Query: InfoProvider auswählen aus Ihrer InfoArea Fallstudie BW ### den InfoCube Bestandsdaten Fallstudie BW ###. Schließen Sie die Eingabe mit OK ab. Ziehen Sie nun die Merkmale Produktgruppe und Land (siehe Abb. 6.10. Query anlegen, Schritt 1) sowie sämtliche Kennzahlen (Bestand, Abgang und Zugang) in die Spalten (siehe Abb. 6.10. Query anlegen, Schritt 2). Positionieren Sie einzig das Zeitmerkmal KalJahr/Quartal in den Zeilen (siehe Abb. 6.10. Query anlegen, Schritt 3). Betätigen Sie die Schaltfläche Query speichern (siehe Abb. 6.10. Query anlegen, Schritt 4) und Sichern Sie die Query im Ordner Fallstudie BW ### unter der Beschreibung Bestandsentwicklung ### und dem technischen Namen QUERY3_###.

6.3 Teil III – Reporting

259

Abb. 6.10. Query anlegen

Legen Sie nun für denselben InfoProvider eine weitere Query an. Platzieren Sie das Zeitmerkmal Quartal in den Zeilen (siehe Abb. 6.11. Selektion anlegen 1, Schritt 1), die Merkmale Produktgruppe und Land (siehe Abb. 6.11. Selektion anlegen 1, Schritt 2) sowie die Kennzahlen Bestand, Abgang und Zugang in den Spalten (siehe Abb. 6.11. Selektion anlegen 1, Schritt 3). Legen Sie außerdem eine Neue Struktur an, indem Sie rechts auf die Kopfzeile des Feldes Spalten klicken und den entsprechenden Eintrag des Kontextmenüs auswählen. Klicken Sie mit der rechten Maustaste auf die soeben angelegte Struktur (siehe Abb. 6.11. Selektion anlegen 1, Schritt 4) und führen Sie die Funktion Neue Selektion aus (siehe Abb. 6.11. Selektion anlegen 1, Schritt 5). Vergeben Sie die Beschreibung Selektiertes Jahr (siehe Abb. 6.11. Selektion anlegen 1, Schritt 6). Expandieren Sie im Dialog Neue Selektion den Teilbaum Zeit vollständig für den Knoten Kalenderjahr (siehe Abb. 6.11. Selektion anlegen 1, Schritt 7). Ziehen Sie nun die Merkmalswertvariable YEAR in das rechte Fenster Beschreibung (siehe Abb. 6.11. Selektion anlegen 1, Schritt 8) und bestätigen Sie mit OK (siehe Abb. 6.11. Selektion anlegen 1, Schritt 9).

260

6 Fallstudie III – Bestandsdatenanalyse

Abb. 6.11. Selektion anlegen 1

Legen Sie für die Struktur eine weitere Neue Selektion an (siehe Abb. 6.12. Selektion anlegen 2, Schritt 1 und Schritt 2) und benennen sie Vorjahr (siehe Abb. 6.12. Selektion anlegen 2, Schritt 3). Ziehen Sie wiederum die Merkmalswertvariable YEAR des Zeitmerkmals Kalenderjahr in das rechte Fenster Beschreibung (siehe Abb. 6.12. Selektion anlegen 2, Schritt 4) und wählen Sie dort aus dem Kontextmenü zu YEAR den Eintrag Einschränken (siehe Abb. 6.12. Selektion anlegen 2, Schritt 5). Im Popup Auswahl für Kalenderjahr klicken Sie mit der rechten Maustaste auf den Listeneintrag YEAR im rechten Bereich Auswahl (siehe Abb. 6.12. Selektion anlegen 2, Schritt 6). Führen Sie die Funktion Variablen-Offsets eingeben aus (siehe Abb. 6.12. Selektion anlegen 2, Schritt 7) und tragen Sie als Offset: -1 ein (siehe Abb. 6.12. Selektion anlegen 2, Schritt 8). Bestätigen Sie sämtliche offenen Popups mit OK (siehe Abb. 6.12. Selektion anlegen 2, Schritte 9 bis 11).

6.3 Teil III – Reporting

261

Abb. 6.12. Selektion anlegen 2

Klicken Sie auf Query speichern und tragen Sie als Beschreibung Bestand Vorjahresvergleich ### sowie als technischen Namen QUERY4_### ein. Sichern Sie Ihre Query und verlassen Sie den BEx Query Designer. 6.3.2 Reporting im BEx Web Application Designer Im BEx Web Application Designer betätigen Sie in der Werkzeugleiste die Schaltfläche Öffnen.... Wählen Sie das Web Template Umsatz Soll-Ist Vergleich ### aus und drücken Sie OK. Selektieren Sie anschließend in der Menüleiste den Ein-

262

6 Fallstudie III – Bestandsdatenanalyse

trag Web Template und die Funktion Speichern unter.... Tragen Sie die Beschreibung Bestandsentwicklung ### und den technischen Namen WEBTEMPLATE5_### ein. Schließen Sie das Fenster mit Sichern. Klicken Sie mit der rechten Maustaste in die linke Spalte der mittleren Tabelle und selektieren Sie Spalte einfügen. Hinweis: Die zusätzliche Spalte wird mit minimaler Breite dargestellt, da kein Objekt enthalten ist. Die Breite wird automatisch erhöht, sobald ein Objekt in der Spalte platziert wird. Ziehen Sie das Web Item Dropdownbox in die neu erstellte Spalte (siehe Abb. 6.13. Query zuweisen, Schritt 1). Drücken Sie in den Eigenschaften im Register Allgemein die Schaltfläche Query auswählen (siehe Abb. 6.13. Query zuweisen, Schritt 2). Wählen Sie aus dem Ordner Fallstudie BW ### die Query Bestandsentwicklung ### (siehe Abb. 6.13. Query zuweisen, Schritt 3). Schließen Sie den Dialog mit OK (siehe Abb. 6.13. Query zuweisen, Schritt 4).

Abb. 6.13. Query zuweisen

Wechseln Sie in den Kartenreiter Web Item (siehe Abb. 6.14. Eigenschaften der Dropdownbox, Schritt 1) und vergeben Sie als Überschrift Filterwert Produktgruppe (siehe Abb. 6.14. Eigenschaften der Dropdownbox, Schritt 2) und setzen

6.3 Teil III – Reporting

263

die Breite in Punkten auf 200 (siehe Abb. 6.14. Eigenschaften der Dropdownbox, Schritt 3). Im Abschnitt Speziell klicken Sie in das Feld Merkmal/Struktur und selektieren den Eintrag Produktgruppe (siehe Abb. 6.14. Eigenschaften der Dropdownbox, Schritt 4). Im Feld Lesemodus ändern Sie die Einstellung auf Gebuchte Werte (siehe Abb. 6.14. Eigenschaften der Dropdownbox, Schritt 4), der Beeinflusste DataProvider ist wiederum der DATAPROVIDER_1 (siehe Abb. 6.14. Eigenschaften der Dropdownbox, Schritt 5).

Abb. 6.14. Eigenschaften der Dropdownbox

Markieren Sie das Web Item DROPDOWNBOX_1 in der mittleren Spalte und stellen Sie auch hier die Breite in Punkten auf 200 und ändern die Überschrift in Filterwerte Kennzahl. Im Abschnitt Speziell hinterlegen Sie als Merkmal/Struktur Kennzahlen. Entfernen Sie das Häkchen hinter Eintrag „Alle Werte“ nicht anzeigen. Selektieren Sie nun das hierarchische Kontextmenü und setzen auch für dieses die Breite in Punkten auf 200. Klicken Sie mit der rechten Maustaste in das CHART_1 und wählen Sie aus dem Kontextmenü Chart bearbeiten. Markieren Sie durch Anklicken die Datenreihe Series 1 im Diagramm und öffnen Sie mit der rechten Maustaste das dazugehörige Kontextmenü. Aus diesem wählen Sie die Funktion Add Trendline... (siehe Abb. 6.15. Trendlinien hinzufügen, Schritt 1) und setzen die Markierung im Bereich Trend/Regression Type des Dialogs Format Trendline auf Logarithmic (siehe Abb. 6.15. Trendlinien hinzufügen, Schritt 2). Wechseln Sie ins Register Line (siehe Abb. 6.15. Trendlinien hinzufügen, Schritt 3) und selektieren Sie als Color: (siehe Abb. 6.15. Trendlinien hinzufügen, Schritt 4) die Farbe der zugehö-

264

6 Fallstudie III – Bestandsdatenanalyse

rigen Datenreihe (siehe Abb. 6.15. Trendlinien hinzufügen, Schritt 5). Bestätigen Sie mit OK (siehe Abb. 6.15. Trendlinien hinzufügen, Schritt 6).

Abb. 6.15. Trendlinien hinzufügen

Legen Sie anschließend analog für die beiden weiteren Datenreihen ebenfalls eine farblich entsprechende logarithmische Trendlinie an. Klicken Sie mit der rechten Maustaste in eine freie Fläche der Legende und wählen Sie aus dem Kontextmenü die Funktion Format Legend... aus (siehe Abb. 6.16. Legende formatieren, Schritt 1). Verzweigen Sie in das Register Legend (siehe Abb. 6.16. Legende formatieren, Schritt 2) und selektieren Sie diejenige Einstellung, welche die Legende oberhalb des Graphen positioniert (siehe Abb. 6.16. Legende formatieren, Schritt

6.3 Teil III – Reporting

265

3). Bestätigen Sie die Änderung mit OK (siehe Abb. 6.16. Legende formatieren, Schritt 4) und verlassen Sie den Dialog Chart bearbeiten ebenfalls mit OK. Sichern Sie das Web Template (siehe Abb. 6.16. Legende formatieren, Schritt 5).

Abb. 6.16. Legende formatieren

Selektieren Sie in der Menüleiste den Eintrag Web Template und die Funktion Speichern unter.... Tragen Sie die Beschreibung Bestand Vorjahresvergleich ### und den technischen Namen WEBTEMPLATE6_### ein. Schließen Sie das Fenster mit Sichern. Markieren Sie das Objekt DROPDOWNBOX_1 und klicken Sie in den Eigenschaften in der Registerkarte Allgemein auf Query auswählen. Selektieren Sie im Popup Query / View öffnen Bestand Vorjahresvergleich ### und bestätigen Sie mit OK. Im Kartenreiter Web Item wählen Sie im Abschnitt Speziell für die Eigenschaft Merkmal/Struktur erneut den Eintrag Kennzahlen aus. Dies ist notwendig, da sich der technische Name der Kennzahlen zur vorherigen Query unterscheidet. Ziehen Sie ein zusätzliches Web Item Textelemente in die obere Tabelle, so dass es sich rechts vom bereits vorhandenen Web Item befindet (siehe Abb. 6.17. Web Template anpassen, Schritt 1). Deselektieren Sie in den Eigenschaften die Einträge Überschrift generieren (siehe Abb. 6.17. Web Template anpassen, Schritt 2), Allgemeine Textelemente anzeigen sowie Statische Filterwerte anzeigen (siehe Abb. 6.17. Web Template anpassen, Schritt 3).

266

6 Fallstudie III – Bestandsdatenanalyse

Abb. 6.17. Web Template anpassen

Klicken Sie nun in die freie Fläche des Web Template und setzen Sie in den Eigenschaften unter Allgemein den Haken bei Variablenbildanzeige erzwingen. Sichern Sie das Web Template und beenden Sie den BEx Web Application Designer. Melden Sie sich über das SAPlogon am System an. In Ihrem Ordner Favoriten finden Sie den Ordner zu Ihrer Fallstudie, in welchem Sie doppelt auf den Link zur Startseite ### klicken. Nachdem Sie sich über den Webbrowser erneut angemeldet haben, wird Ihnen Ihre Web Application präsentiert. Rufen Sie über das Rollenmenü im linken Frame den Report Bestand Vorjahresvergleich ### auf (siehe Abb. 6.18. Web Application im Webbrowser 1, Schritt 1). Geben Sie für die Variable YEAR den Wert 2004 ein und klicken Sie auf Ausführen. Selektieren Sie im Feld Filterwert Produktgruppe Videorecorder (siehe Abb. 6.18. Web Application im Webbrowser 1, Schritt 2), im Feld Filterwerte Kennzahl den Eintrag Bestand (siehe Abb. 6.18. Web Application im Webbrowser 1, Schritt 3) und im Feld Auswahl Region Dänemark (siehe Abb. 6.18. Web Application im Webbrowser 1, Schritt 4).

6.3 Teil III – Reporting

267

Abb. 6.18. Web Application im Webbrowser 1

Sie können nun für das selektierte Jahr einen abnehmenden Bestand an Videorecordern ablesen, während im Vorjahr der Bestand noch eine zunehmende Tendenz hatte. Betrachten Sie nacheinander die Entwicklung der verschiedenen Kennzahlen für die jeweiligen Produktgruppen und Regionen. Rufen Sie nun den Report Bestandsentwicklung ### auf (siehe Abb. 6.19. Web Application im Webbrowser, Schritt 1). Wählen Sie als Produktgruppe Plasma & LCD (siehe Abb. 6.19. Web Application im Webbrowser, Schritt 2), die Kennzahl Bestand (siehe Abb. 6.19. Web Application im Webbrowser, Schritt 3) und die Region Deutschland (siehe Abb. 6.19. Web Application im Webbrowser, Schritt 4).

268

6 Fallstudie III – Bestandsdatenanalyse

Abb. 6.19. Web Application im Webbrowser

Sie können erkennen, dass der Bestand an Plasma- und LCD-Fernsehern kontinuierlich gesunken ist, während der Kurvenverlauf der Produktgruppe Videorecorder bis zum vierten Quartal des Jahres 2003 aufgrund der sinkenden Absatzzahlen ein beständiges Wachstum erfuhr und erst im Jahr 2004 wieder verringert werden konnte. Betrachten Sie auch in diesem Report die Bestände für die weiteren Kombinationen von Produktgruppe und Land.

6.3 Teil III – Reporting

Zusammenfassung: Im letzten Abschnitt in der dritten Fallstudie wird das Reporting zur Auswertung von Beständen betrachtet. Die von Ihnen erstellte Query Bestandsentwicklung ### ermöglicht Analysen über den gesamten erfassten Zeitraum, die Query Bestand Vorjahresvergleich ### dagegen enthält als erste Ihrer Queries Merkmalswertvariablen. Diese erlauben es, unter der Angabe eines Bezugsjahres das Vorjahr zu ermitteln. In den Web Templates Bestandsentwicklung ### und Bestand Vorjahresvergleich ### haben Sie den Liniendiagrammen logarithmische Trendlinien zugeordnet. Dadurch fällt es dem Betrachter leichter, die Entwicklung einer Zahlenreihe abzulesen. Aus Ihren Favoriten heraus konnten Sie über die Startseite ### neben Ihren bereits angelegten Reports auch die neuen Web Templates aufrufen. Durch die verschiedenen Möglichkeiten zur Einschränkung der Sicht auf die Daten war es Ihnen möglich, mit geringem Aufwand Bestände, Abgänge und Zugänge für alle Produktgruppen und Länder zu analysieren.

269

Literatur

Acharya, S.; Gibbons, P.; Poosala, V. (1999): Congressional Samplex for Approximate Answering of Group-By Queries. Bell Laboratories. Murray Hill, NJ. USA. Alexander, S. (2003): SAP BW wächst zur Analyseplattform heran. Computerwoche. Anahory, S.; Murray, D. (1997): Data Warehouse. Planung, Implementation und Administration. Bonn. Arndt, H. (2002): Informations- und Kommunikationssysteme. Manuskript zur Vorlesung, Otto-von-Guericke Universität. Magdeburg. Bange, C. (2005): Elf Probleme mit SAP BW. Computerwoche. Bauer, A.; Günzel, H. (2001): Data Warehouse Systeme: Architektur, Entwicklung, Anwendung. Heidelberg. Büllesbach, A. (2002): Datenschutz im Data Warehouse – eine ungeliebte Fragestellung. 7. Data-Warehouse-Forum. St. Gallen. Schweiz. Bulos, D.; Forsman, S. (2001): Getting Started with ADAPT. Symmetry Corporation. San Rafael, CA. USA. DataFlux (2005): Data Management. http://www.dataflux.com/default.asp. 31. August 2005. Devlin, B. (1997): Data Warehouse: From Architecture to Implementation. Reading, MA. USA. Egger, N. (2004): Praxishandbuch SAP BW 3.1. Bonn. Egger, N. (2005): SAP BW Datenbeschaffung. Bonn. Folger, D. (2002): The Top Ten Pitfalls in Business Intelligence Deployments. Stamford, CT. USA. Fuller, D. (2002a): The Fundamentals of Data Warehousing: ODS. DM Review Magazine. Fuller, D. (2002b): The Fundamentals of Data Warehousing: What is a Data Warehouse? DM Review Magazine. Fuller, D. (2002c): The Fundamentals of Data Warehousing: Glue it Together – The Role of Meta Data. DM Review Magazine. Gupta, V. (1997): An Introduction to Data Warehousing. System Services corporation. Chicago, IL, USA. Hahne, M. (2004): Modellierung für BI-Systeme. TDWI Konferenz. München. Heinrich, L. (1999): Informationsmanagement: Planung, Überwachung und Steuerung der Informationsinfrastruktur. München. Heiß, H. (2005): Cluster Computing. Skript zur Vorlesung. Technische Universität Berlin. Hinrichs, H. (2002): Datenqualitätsmanagement in Data Warehouse Systemen. Dissertation, Carl von Ossietzky Universität. Oldenburg. Holthuis, J. (1999): Der Aufbau von Data Warehouse-Systemen. 2. Auflage, Wiesbaden. Humm, B.; Wietek, F. (2005): Architektur von Data Warehouses und Business Intelligence Systemen. Informatik Spektrum. Inmon, W. (1999a): Definition of a Data Warehouse.

272

Literatur

Inmon, W. (1999b): Introduction: The Operational Data Store. Inmon, W. (1999c): The Data Warehouse Infrastructure. Inmon, W. (1999d): The Top Ten Contemporary Issues for Warehousing. Inmon, W. (1999e): Metadata Sources. Inmon, W. (1999f): Metadata in the Data Warehouse Environment. Inmon, W. (1999g): Business and Technical Metadata. Inmon, W. (1999h): Metadata and Historical Data. Inmon, W. (1999i): Integration and Transformation. Inmon, W. (2001): What a Data Warehouse is not. Karakizis, S. (2002): How to Win with Your Data Warehouse. DM Review Magazine. Karcher, A. (2005): Einführung in die Wirschaftsinformatik 1. Manuskript zur Vorlesung, Universität der Bundeswehr. München. Kimball, R. (1996a): Drilling Down, Up and Across – Understanding the vocabulary of navigating dimensions. DBMS online. Kimball, R. (1996b): Mastering Data Extraction – Steps you must complete when migrating legacy data into a data warehouse. DBMS online. Kimball, R. (1997): It’s Time für Time – The importance of the time dimension in data marts and data warehouses. DBMS online. Lambert, B. (1996): Data Warehousing Fundamentals: What You Need To Know To Succeed. DM Review Magazine. Leslie, G; Mayer, O. (2003): Advanced Web Reporting with SAP BW. SAP AG. Leslie, G; Nithiananda, S. (2003): Openness and SAP BW: Interface Overview. SAP AG. Manning, I. (2003): Data Warehousing – What Exactly Is It? DM Review Magazine. Matthee, S.; Kaufmann, T. (2001): Business Explorer Mobile Intelligence in SAP BW 3.0 – How to ... Guide. SAP AG. McDonald, K. et al. (2002): Mastering the SAP Business Information Warehouse. Wiley & Sons. Mehrwald, C. (2004): Business Information Warehouse 3. Heidelberg. Mohr, M. (2002): Business Intelligence Anwendungen am Beispiel SAP BW. Manuskript zur Vorlesung, Technische Universität. München. Moss, L., Adelman, S. (1999): Data Warehouse Goals And Objectives. DM Review Magazine. Nolan, G. (2003): Advanced BW Data Transformation. SAP America Inc. Polus, J. (2003): BW 3.0 Portal Integration. SAP AG. Rahm, E. (2004): Data Warehousing und Data Mining. Manuskript zur Vorlesung, Universität Leipzig. Leipzig. Raizada, S. (2002): Eleven Steps to Success in Data Warehousing. Syntel Inc. Beaverton, OR, USA. Rautenstrauch, C. (2001): Einführung in die Wirtschaftsinformatik. Manuskript zur Vorlesung, Otto-von-Guericke Universität. Magdeburg. Rautenstrauch, C. (2003): Prozessmodellierung. Manuskript zur Vorlesung, Otto-vonGuericke Universität. Magdeburg. Rautenstrauch, C. (2004): Strategisches Informationsmanagement. Manuskript zur Vorlesung, Otto-von-Guericke Universität. Magdeburg. SAP AG (2000): BW Operational Data Store. SAP AG (2002a): SAP Business Information Warehouse: Functions in Detail. SAP AG (2002b): Data Warehousing mit mySAP Business Intelligence. SAP AG (2002c): Business Information Warehouse Release 3.0 – Overview.

Literatur

273

SAP AG (2003a): Enterprise Data Warehousing mit SAP BW. SAP AG (2003b): mySAP Business Intelligence – Overview. SAP AG (2004): Offline Reporting with the SAP BW 3.x Reporting Agent. SAP AG (2005): SAP Bibliothek – SAP Business Information Warehouse. http://help.sap.com/content/documentation/netweaver/index.htm. 31.August 2005. Sattler, K. (2005): Datenqualität – eine datenbankorientierte Sichtweise. 10. DatenbankTutorientage. Karlsruhe. Sattler, K., Saake, G. (2004): Data Warehouse Technologien. Manuskript zur Vorlesung, Otto-von-Guericke Universität. Magdeburg. Sherman, R. (2004): Data Integration Advisor: Software Development Standards Enhance Your Data Warehouse ROI. DM Review Magazine. Smith, A. (2002): Data Warehousing and ERP – A Combination of Forces.