Konzeptionen und Modelle für Data Warehouses: Eine Untersuchung am SAP BW

Transkript

1 MARMARA UNIVERSITÄT Fakultät für Wirtschafts- und Verwaltungswissenschaften Konzeptionen und Modelle für Data Warehouses: Eine Untersuchung am SAP BW Sami Bilal 0001 / 2004 Deutschsprachige Abteilung für Wirtschaftsinformatik Vorgelegt bei: Prof. Dr. Haldun Akpınar

2 Inhaltsverzeichnis INHALTSVERZEICHNIS... 2 ABBILDUNGSVERZEICHNIS... 4 TABELLENVERZEICHNIS... 5 ABKÜRZUNGSVERZEICHNIS... 6 EINLEITUNG BUSINESS INTELLIGENCE, DATA WAREHOUSING UND SAP Geschichtliche Entwicklung der Datenverwendung Anforderungen der Datenanalyse Der Data Warehouse-Begriff Business Intelligence SAP Data Warehousing und Business Intelligence Know-How Entwicklung im ERP-Umfeld Business Intelligence Lösung der SAP BW und Einbindung in Enterprise Portal ARCHITEKTURKONZEPTIONEN FÜR DATA WAREHOUSES Abgrenzung des DW Begriffs Definition einer Data Warehouse Der erweiterte DW-Begriff Fachbegriffe im DW-Umfeld Architekturbegriffe Analysebegriffe Speicherstrukturbegriffe Beschreibung einer DW Architekturbeschreibung nach Entstehungsprozess Architekturbeschreibung nach DW-Verwendung Architekturvarianten Morphologische Merkmale zur Zuordnung eines Systems zum DW Organisation der BW-Architektur Funktionsstruktur allgemein Datenhaltung Datenbereitstellung (Staging) Metadatenelemente in der BW-Architektur Elementare Bausteine Stammdatenbereich Speicherstrukturen Analysestrukturen ETL Strukturen

3 3 DATENMODELLE FÜR OLAP Datenmodelle als Bestandteil der Architektur Rahmenbedingungen zu relational-multidimensionalen Strukturen Ebenen der Datenmodellierung Multidimensionale Strukturen ROLAP und MOLAP Von normalisierter Struktur zum Sternenschema Logische Datenschemata für multidimensionale Strukturen Flache Strukturen Starschema Snowflake-Schema Galaxy-Schema Zusammenfassung von Schemaeigenschaften Physisches Datenschema bei BW Erweitertes Starschema Abkapselung von InfoCubes Stammdatenmodell des BW Master-Data-Modell Modellierung von Hierarchien MODELLIERUNG VON DATENBEREITSTELLUNG Staging in BW Extraction Layer Inflow Layer Transformation Layer Integration Layer Transformationsprozesse Datenintegrationstransformationen Anwendungslogik-enthaltende Transformationen Transformationsarten nach Objekten Transformationsstufen in BW Referenzstrukturen für den Datenfluss ZUSAMMENFASSUNG UND SCHLUSSWORT LITERATURVERZEICHNIS EHRENWÖRTLICHE ERKLÄRUNG

4 Abbildungsverzeichnis Abbildung 1-1: Know-How-Export aus R/3 in andere Produkte Abbildung 1-2: Struktur der SAP BI-Lösung Abbildung 2-2-1: Das Common Warehouse Metamodel Abbildung 2-2: Der erweiterte DW- Begriff Abbildung 2-3: Erste Auffassungsart für ein ODS Abbildung 2-4: Der Business Dimensional Lifecycle Abbildung 2-5: Data Warehousing Begriffe nach Kimball Abbildung 2-6: Der Corporate Information Factory Abbildung 2-7: Normierung der CIF (Abb. 2-6) Abbildung 2-8: Normierte Abbildung der CIF Abbildung 2-9: Hub & Spoke Architektur Abbildung 2-10: Architekturaufbau von BW nach SAP Abbildung 2-11: Allgemeine Funktionale Architektur des BW Abbildung 2-12: Speicherstrukturarchitektur von BW Abbildung 2-13: ETL-Services Architektur von BW Abbildung 2-14: Das Metadatenmodell von BW Abbildung 2-15: InfoObject-Typen und Attributbeziehungen Abbildung 2-16: Datenarten in BW Abbildung 2-17: Stammdaten und Stammdatenoptionen in BW Abbildung 2-18: Beispiel für externe Hierarchien Abbildung 3-1: Datenwürfel mit 3 Dimensionen Abbildung 3-2: Mittelkomplexes ERM Beispiel für ein Unternehmen Abbildung 3-3 Relationen des Verkaufsprozesses ohne Attribute Abbildung 3-4: Starschema zum Verkaufsprozess Abbildung 3-5: Flache Tabellenstruktur Abbildung 3-6: Starschema Abbildung 3-7: Snowflake-Schema Abbildung 3-8: Galaxy-Schema Abbildung 3-9: Erweitertes Starschema / InfoCube Abbildung 3-10: Stammdatenmodell des BW Abbildung 3-11: Modellierungsmöglichkeiten bei Hierarchien Abbildung 4-1: Replizierung der DataSources Abbildung 4-2: Paketweise Übermittlung von Daten Abbildung 4-3: Standardreferenzmodell für das Staging im BW

5 Tabellenverzeichnis Tabelle 1-1: Vergleich von OLTP und OLAP Tabelle 1-2: Beziehungen von SAP Produktkomponenten mit BW Tabelle 2-1: Merkmale, die von Data- und InfoMarts gewährleistet werden können Tabelle 2-2: Morphologische Merkmale zur Zuordnung eines Systems zum DW Tabelle 2-3: Datentypen für Merkmale Tabelle 2-4: Datentypen von Kennzahlen Tabelle 3-1 :Die Entwurfsebenen und korrespondierende Modellierungsmethoden Tabelle 3-2: Operationen auf einen Datenwürfel Tabelle 3-3: Schemabegriffe bei BW Tabelle 3-4: Vergleich von Datenschemata Tabelle 4-1: Datenintegrationstransformationen Tabelle 4-2: Anwendungslogik-enthaltende Transformationen Tabelle 4-3: Transformationsarten nach Objekten Tabelle 4-4: Übertragungsregeln und Transferregeln

6 Abkürzungsverzeichnis ABAP ADK APO API ASCII BAPI BI BW CRA CRM CWM DBMS DW ERM ERP ETL MDX ODBO ODBC ODS OLAP OLTP OMG PSA RDBMS RRI SAP SCM SEM SID SOAP SQL UML XMI XML XML/A Advanced Business Applications Programming Archiving Development Kit Advanced Planning & Organization Application Programming Interface American Standard Code for Information Interchange Business Applications Programming Interface Business Intelligence Business Information Warehouse Customer Relationship Analytics Customer Relationship Management Common Warehouse Metamodel Database Management System Data Warehouse Entity Relationship Model(ing) Enterprise Resource Planning Extract, Transfer, Load Multidimensional Expressions ODBC for OLAP Open Database Connectivity Operational Data Store Online Analytical Processing Online Transaction Processing Object Management Group Persistent Staging Area Relational DBMS Report-to-Report Interface Systeme, Anwendungen, Produkte Supply Chain Management Strategic Enterprise Management Stammdatenidentifikationsschlüssel Simple Objects Access Protocol Structured Query Language Unified Modelling Language XML Metadata Interchange Extensible Markup Language XML for Analysis 6

7 Einleitung Data Warehouses stellen ein relativ neues Speicherkonzept zur Organisation von großen Datenbeständen dar. Die Untersuchung von geeigneten Architekturkonzeptionen und Datenstrukturen für große Datenbestände wurde ca. Anfang 90er Jahre unter dem Namen Data Warehousing zur eigenständiger Disziplin vorgehoben. Zentrales Untersuchungsfeld dieser Disziplin war die Integration von großen Datenmengen und verschiedenen Systemlandschaften unter dem Data Warehouse- Dachgebilde, sodass die Schaffung einer vernünftigen Datenbasis zur Analysezwecken möglich sein sollte. Um geeignete Strukturen für Data Warehouses (DW) schaffen zu können, sind verschiedene Anforderungen und Randbedingungen zu beachten: Wir können diese grob in die betriebswirtschaftlichen, technischen und geographischen Klassen einteilen. Modelle sind die Instrumente, mit dem wir die Lösungen beschreiben, die diese Anforderungen befriedigen können. Modelle sind aber auch Werkzeuge, die zur Lösung von verallgemeinerten Problemstellungen geschaffen wurden. In dieser Hinsicht können Modelle und Modellierungsmethoden selbst als ein separates Untersuchungsobjekt betrachtet werden. Im Rahmen dieser Arbeit versuche Ich am Beispiel von SAP Business Information Warehouse (BW) die verschiedenen Architekturmöglichkeiten, Datenmodelle und Stagingszenarien vorzustellen. Behandelt werden also ausschließlich Datenstrukturen und ETL-Prozesse, die Datenverwendung (z. B. Reporting und Data Mining) liegt außerhalb des Untersuchungsrahmens. Die Behandlung des Inhalts erfolgt folgendermaßen: Im Kapitel 1 unternehme Ich eine kurze Einführung zu Data Warehousing und versuche den Entwicklungsumfeld von SAP BW zu beschreiben. SAP BW wurde von SAP im Haus entwickelt. Die SAP-Produktpalette übt also einen maßgeblichen Einfluss auf die Architektur von BW. In Kapitel 2 werden Rahmenbedingungen für die betriebliche Problematik für Data Warehouses näher untersucht. DW-Architekturtypen und ihre Elemente werden beschrieben. Letztendlich werden die Implementierung dieser Architekturelemente im dem BW untersucht. Mittel zur Beschreibung sind Architekturmodelle. In Kapitel 3 wird das Kernelement einer DW-Lösung untersucht: Datenschemata. Verschiedene logische Schemata werden hinsichtlich der Komplexität verglichen und das BW-Standarddatenschema vorgestellt. Eine Anleitung zur Erstellung von Modellen 7

8 nach verschiedenen Qualitätskriterien oder eine Vorstellung von Referenzmodellen aus verschiedenen Anwendungsbereichen wird nicht angestrebt. Mittel zur Beschreibung sind Datenschemata. Letztendlich untersucht Kapitel 4 den Weg, auf den Daten von transaktionalen Systemen zu Data Warehouses gelangen. Dabei werden Anforderungen an ein ETL- System aufgelistet und die Implementation der BW-Lösung beschrieben. Mittel zur Beschreibung in diesem Kapitel sind Datenflussschemata. 8

9 1 Business Intelligence, Data Warehousing und SAP 1.1 Geschichtliche Entwicklung der Datenverwendung Daten stellen in vielen informationstechnologischen Anwendungen ein zentrales Designmerkmal dar. Unter dem Begriff der Datenbank kennen wir aber die Softwareklasse, die die effiziente Verwaltung und Nutzung der Daten als Hauptfunktionalität betrachtet. Die Funktionalität und Leistungsvermögen der Datenbanken werden nach den Operationen auf Daten gemessen. Es existieren viele verschiedene Strukturen für Datenbanken. Bis in die 80er Jahre richteten diese sich hauptsächlich nach den Anforderungen der Datenoperationen. Frühere Datenbanken gaben sich zufrieden, mit einfachen Gruppierungen und Sortiermechanismen zu arbeiten. Es ging einfach darum, ein Effizientes I/O und alternative Gruppierungsmechanismen zu Filesystemen zu implementieren. Auf Datensätzen sollte beliebig zugegriffen werden (Random Access). Im Rahmen der effizienten Zugriff auf Daten haben sich relationale Datenbanken (RDBMS) am Markt durchgesetzt. Das Lesen, Schreiben, Ändern und Löschen von Datenfelder oder Datensätzen bei RDBMS wird unter dem Namen Query zusammengefasst. Ein Query stellt somit die atomare Funktion dar, die auf Daten zugreifen kann. Zur Beschreibung dieses Funktionsumfangs hat sich die Structured Query Language (SQL) durchgesetzt. Die Durchführung einer Query oder sonstigen verwaltungstechnischen Datenbankoperationen nennt man eine Transaktion. Eine transaktionsorientierte Betrachtungsweise erlaubt Leistungsoptimierungen, Sicherheits-, Überwachungs- und Wiederherstellungsfunktionen für verschiedene Operationsarten. Der Fokus der relationalen Datenbanken auf diese abgegrenzten, atomaren Funktionen erlaubte die Implementierung verschiedener Lösungen für ganz unterschiedliche Unternehmenstypen. Relationale Datenbanken und Entity Relationship Modelle (ERM) dominierten die Datenwelt Anforderungen der Datenanalyse Hochnormalisierte Tabellenstrukturen nach dem ERM bieten viele Vorteile: Sie vermeiden redundante Speicherung und verringern somit die Fehlerquote bei der Einund Ausgabe von Daten. Sie sind sehr schnell in Operationen und ermöglichen eine flexible Erweiterung des Modells. Sie haben jedoch auch große Nachteile in der Analyse. 9

10 Im Laufe der Zeit nimmt die Menge und Umfang an gespeicherten Daten ständig zu. Dementsprechend weisen integrierte Speicherstrukturen eine stetig zunehmende Komplexität. Dies schlägt sich in komplexere transaktionelle Modelle nieder, was bei normalisierten Strukturen den Aufbau einer Query erschwert. Das SQL Select -Clause sammelt eigentlich Daten von verschiedenen persistenten Tabellen und baut (join) sie zusammen zur Laufzeit zu einer Tabellenstruktur. Architekten von Datenbanken können zum Teil den Abfragebedarf von Informationsverwendern vorausahnen und notwendige Abfragen mit dem Produkt (die Datenbank) ausliefern. Dies ist z. B. bei ERP Systemen der Fall, wo das Datenmodell vor der Auslieferung feststeht und die Geschäftsprozesse der Informationskunden durch Referenzmodellen abgebildet werden kann. ERP Systeme sind jedoch primär auf operatives Reporting angepeilt. Strategische Informationen und Analysen haben unterschiedliche Sammlungsmethoden und Zielkriterien. Der Unterschied zu operativen Abfragenprozessen ist beträchtlich. So haben sich die Begriffe OLTP und OLAP entwickelt. Ziel Tabelle 1-1: Vergleich von OLTP und OLAP OLTP OLAP Effizienz der Datenverwaltung durch Automation steigern Effektivität der Entscheidungen/Prozesse durch Informationsgenerierung erhöhen Themenbezogen Inhalt der Daten Anwendungsbezogen, Funktionsbezogen Art der Daten Transaktionsdaten Aggregierte Daten Alter der Daten Aktuell und zeitnah (0-60 Tage) Datenvolumen Klein Sehr hoch Hauptfunktionalität Häufige Änderungen Zeitabhängige Auswertungen Datenintegration Gering bei isolierten Anwendungen, höher bei ERP Historisch (2-10 J, typisch 5J) und aktuell Integration aus allen möglichen Datenquellen DBMS-Technologie Relationale Datenbanken Relationale und Multidimensionale Datenbanken Datenmodell Normalisiert nach ERM Denormalisiert nach ERM, Normalisierungskriterium MNF Semantische Entity Relationship Modell Multidimensionales ERM 10

11 Modellierungsmethode Qualitätskriterium der Modellierungsmethoden NF: Nichtredundante Speicherung und Verweiseffizienz MNF: Nichtredundanz, Abbildungstreue zur Anwendungswelt, Kontextabhängigkeit der Datenverwendung Lesen Erlaubte Operationen auf Einfügen, aktualisieren, den Datenbestand löschen, lesen Quelle: Eigene Darstellung, in Anlehnung an ([TS-SapBw02], 15) Wachstum von Datenbanken Daten wurden in Unternehmen an verschiedenen stellen für verschiedene Zwecke erhoben. Manchmal wurden dieselben Daten an verschiedenen Stellen oder durch verschiedene Parteien erhoben und redundant gespeichert. Da verschiedene Abteilungen verschiedene Betrachtungsweisen auf denselben Sachverhalt hatten, wurden andere Begrifflichkeiten, Definitionen oder Formate für die Beschreibung derselben Datengrundlage verwendet. Das Management hat in verschiedenen Abteilungen unterschiedliche Antworten auf die gleiche Fragestellung bekommen. Mit der Zeit verschärften sich die Probleme der Dateninkonsistenz. Unternehmensfusionen, geographische und funktionale Unternehmensexpansion, Austausch von Daten mit den Geschäftspartnern führten zu neuen Integrationsproblemen. Der Begriff der Enterprise Integration ist heute sehr populär, und umfasst nicht nur Anwendungen, sondern Daten, Prozesse und Funktionen ERP-Systeme Eine Lösungsmöglichkeit für das Datenintegrationsproblem ist das Erfassen aller Geschäftstransaktionen auf einer integrierten Datenbasis. Häufig ist das ein Problem, weil Geschäftsprozesse durch verschiedene Anwendungen bearbeitet werden, die unterschiedlichen Speicherungskonzeptionen verschiedener Hersteller folgen. Im betrieblichen Anwendungssystemen erfordert dies der homogene Aufbau aller Anwendungen, sodass sie meistens im Form einer Suite von einem Hersteller stammen. Nach den betriebswirtschaftlichen Hintergründen dieser Softwareart werden solche Systeme Enterprise Resource Planning Systeme (ERP) genannt. Prominente Vertreter dieser Gattung von Software sind z. B. SAP R/3, Oracle Applications, PeopleSoft EnterpriseOne und SSA Baan. Die Datenbestände und Applikationslogik von ERP Systemen weisen ein wichtiges Differenzmerkmal zu herkömmlichen DBMS-Softwarepaketen auf. Da die Orientierung mehr auf Geschäftssysteme liegt, werden viele Tabellen vor der Installation fest 11

12 vorgegeben. Andere Tabellen werden im Rahmen der Customizing 1 abgeschaltet. frei- bzw. Es ist jedoch anzumerken, dass alle ERP-Systeme langsam aus ihren eigenen, betrieblichen Kernkompetenz-Anwendungsgebiet herausgewachsen sind. Dies bewirkt, dass die betriebliche Taxonomie bei ERP-Systemen teilweise sehr unterschiedlich aussieht. Diese Taxonomie schlägt sich auch in Tabellenstrukturen nieder. ERP-Systeme ermöglichten die Integration der Datenbasis auf einer höheren Normalisierungsstufe. Da sie aber eine sehr breite Palette von Geschäftsarten und Transaktionen erfassen sollen, sind ihre Tabellenstrukturen äußerst komplex. Die Größenordnung von relational/inhaltlich zusammenhängenden Tabellen wird in Tausenden gemessen. Bei solch einer Komplexität ist die Erstellung einer Abfrage- Query äußerst mühsam und wegen der langen Entwicklungszeit unrentabel. Laufzeitkosten für umfassende Queries stellen auch sehr große Probleme dar Der Data Warehouse-Begriff Die Situation in vielen Unternehmen ist durch dıe steigende Datenflut bei gleichzeitigem Informationsdefizit gekennzeichnet. Obwohl die Informationsversorgung v.a. mittels Management Information Systems (MIS) einen wichtigen Wettbewerbsfaktor darstellt, fehlt häufig die passende Information die zur zielgerichteten Entscheidungen führt. Data Warehouses (DW) sollen die Quelle für den betrieblichen Informationsfluss bilden. Dazu sollen sie einen integrierten Datenbestand liefern, der allen möglichen Informationsanforderungen gewachsen ist und somit die Infrastruktur der Informationslogistik bildet. Die Probleme der eigenentwickelten transaktionellen Datenbanken und ERP-Systemen hinsichtlich der Transparenz und Leistungsfähigkeit der Strukturen sollen bei DW-Implementationen gelöst werden. So soll der DW den single version of business truth abbilden. ([McDonald2002], 8) Ein Data Warehouse ist kein Produkt, sondern ein Konzept, das sich der Datenproblematik von managementunterstützenden Systemen annimmt. ([TS- SapBw02], 1) Business Intelligence Die Archivierung der integrierten Daten in einem Data Warehouse alleine bringt noch keine Wettbewerbsvorteile, sondern erst deren kreative und intelligente Verwendung ([Behme1996], 30f). Diese Art der Nutzung von unternehmensweit verfügbarem 1 Customizing ist die Auswahl, Parametrisierung und Erweiterung von ERP-Komponenten nach dem betrieblichen Anforderungen an eine Softwareinstallation. 12

13 Wissen wird heute trotz einiger Kontroversen als Business Intelligence (BI) bezeichnet. Vorläufer dieser Idee waren Konzepte wie Management Information Systeme (MIS), Decision Support Systeme (DSS/EUS) und Führungsinformationssysteme (FIS/EIS) ([Schinzer1999], 5f). Der Begriff Business Intelligence wurde 1989 von der Gartner Group geprägt und folgendermaßen definiert: Business Intelligence is the process of transforming data into information and, through discovery, into knowledge. ([Behme1996], 37f). 1.2 SAP Data Warehousing und Business Intelligence Hier wird kurz die Produktpalette der SAP im Umfeld der Business Intelligence Lösungen vorgestellt. Das Data-Warehouse-System von SAP heißt Business Information Warehouse (BW) Diese Vorstellung gibt eine Übersicht über die Verwendungsmöglichkeiten der BW und bietet zugleich eine Einsicht über die Reportingfunktionen der älteren SAP Produkte. Diese Einsicht werden wir dazu Nutzen, um unterschiede zwischen der Datenauswertungsarten bei transaktionalen Systemen und Datenlager zu beschreiben. Zudem werden gewisse Anforderungen an das BW gestellt, dass eine Anpassung des herkömmlichen DW-Datenmodells erfordert. Diese Modelländerungen sind nur dann nachvollziehbar, wenn die Implementierungsanforderungen der (auf dem BW aufbauenden) SAP-Produktkomponenten bekannt sind. Als letztes werde die große Bedeutung dieser Produktkomponenten auf die Entwicklung der Business Content genannt Know-How Entwicklung im ERP-Umfeld SAP hat zur Erfassung der Transaktionen den ERP-System R/3 entwickelt. In den diversen Modulen von R/3 steckt viel Wissen über die Abläufe in unterschiedlichsten Geschäftstypen aus verschiedenen Sektoren. Die neue Bezeichnung für R/3 heißt mysap. Zukünftig wird es wahrscheinlich zu einem Core Component umgebaut und umbenannt Reporting im R/3 R/3 besitzt eine modulare Aufbau (siehe Abbildung 1-1) mit Komponenten für Logistik, Finanzbuchhaltung, Personalwirtschaft und Zusatzkomponenten wie Branchenlösungen und Workflow Management Lösungen. Diese Komponenten werden von verschiedenen Entwicklungsteams entwickelt, damit die betriebswirtschaftlichen Spezialkenntnisse in einem bestimmten Bereich ausgeschöpft werden können. Eine der Folgen dieser Vorgehensweise war, dass in verschiedenen Modulen die Reportingfunktionen mit völlig verschiedenen softwaretechnischen Methoden realisiert wurden. Die Reportingfunktionalität wurde in einem Information Systems Layer integriert und harmonisiert. ([McDonald2002], 22) 13

14 Die erste OLAP Funktionalität in R/3 findet man im research processor der Controlling und Profitability Analysis (CO-PA). Heute nennt man diese Funktionalität in R/3 Drill- Down Reporting. Das browsen durch Daten wurde von dem Report-to-Report Interface (RRI) realisiert. ([McDonald2002], 23) Es handelt sich hierbei aber um ein Tool, das die Berichtnavigation über die Abfragefunktionen verschiedener Teilmodulen realisiert. Es findet also keine echte Datennavigation durch Änderung der Abfrageparameter statt. Primäre Motivation zur Erweiterung der Produktpalette mit einer hauseigenen DW war die Kundenanforderungen nach verbessertem Zugang zum Daten im R/3. ([McDonald2002], 23) Einsatz des SAP-Produktwissens bei BW Aktuelle Anwendungen aus der Wirtschaftsinformatik haben auch auf neue Produkte und Bezeichnungen bei SAP geführt. Diese sind zum Beispiel neue Produkte für Customer Relationship Management (CRM), Supply Chain Management (SCM) und Strategic Enterprise Management (SEM). Abbildung 1-1: Know-How-Export aus R/3 in andere Produkte Quelle: Eigene Darstellung Diese Anwendungen und der Business Information Warehouse (BW) haben sehr viel betriebswirtschaftliches Implementierungs-Know-how aus R/3 übernommen (vgl. [McDonald2002], 22). Die Datenanforderungen dieser Lösungen sind auf die Analyse 14

15 ausgerichtet. Dementsprechend greifen diese Lösungen nicht auf Daten aus dem ERP- System mysap, sondern aus Daten des Business Information Warehouse zu Business Intelligence Lösung der SAP Die SAP AG bietet mit ihrem Produktpaket mysap Business Intelligence, das Teil der umfassenden Strategie der mysap-familie ist, eine Lösung für das Informationsmanagement und die Entscheidungsunterstützung an. SAP bietet seine Lösungen in sogenannten Solution Maps. Diese koppeln Anwendungen wie Strategic Enterprise Management (SEM) oder Customer Relationship Management (CRM) mit Basisanwendungen der Business Intelligence Solution. Ein sehr breites Aufgabenspektrum wird mit der Business Intelligence (BI) Lösung aufgegriffen: Data Warehousing, Reporting und Analyse, Information Deployment über den mysap Workplace, Planung und Simulation, Balanced Scorecard Implementation, Web Content Management und verschiedene analytische Anwendungen ([McDonald2002], Kap. 8) Produkt (Technology Component) Tabelle 1-2: Beziehungen von SAP Produktkomponenten mit BW Anwendung Zielsetzung Beziehung mit BW (Analytic Application) reflexive Beziehung, liefert oder empfängt von BW: Hub / Spoke (Warehouse / Data Mart) BW - Datenintegration, für Analyse geeignete Datenstrukturen erstellen und verwalten SAP SEM SAP CRM SAP APO MySAP Financials Implementierung von Controlling Methoden (Scorecarding, div. Finanzplanungsmethoden), Konsolidierung verwendet Daten von BW, schreibt in transaktionelle InfoCubes zurück, baut als Modul auf BW mysap CRM Kundenanalyse per Data Mining verwendet Daten von BW (Data Mining Workbench und Business Content), Customer Relationship Analytics (CRA) ist in BW integriert mysap SCM Informationsflüsse zwischen Geschäftspartner organisieren (SCOR-Modell, SC-Planung, Monitoring) Datenquelle: ([McDonald2002],,336) APO System hat eingebettete BW- Technologie, ist von BW separat 15

16 1.2.3 BW und Einbindung in Enterprise Portal Daten im Rahmen der Business Intelligence werden in zwei Kategorien organisiert: Strukturierte und nicht-strukturierte Daten. Die strukturierten Daten werden im BW in einem DW-Format, die nicht strukturierten im Enterprise Portal erfasst. Strukturierte Daten haben eine Speicherstruktur, wodurch sie mit datenbanktechnischen Abfragen erreichbar werden. Nichtstrukturierte Daten müssen manuell oder mit Content-Management Methoden indiziert und kategorisiert werden, wenn sie in Informationssystemen mit geringem Aufwand auffindbar sein sollen. Der Enterprise Portal liefert die nötige technische Infrastruktur zur Taxonomie und Indizierung. Ein interessante Funktion bei Enterprise Portal ist Business Unification. Diese optionale Komponente erlaubt die Verlinkung eines im Repository gespeicherten Geschäftsobjekts mit einem Anderen. Somit ist es zum Beispiel möglich, dass Elemente aus Stammdaten (Master Data) in transaktionalen Systemen mit Objekten aus dem Portal-Content verlinkt werden. ([McDonald2002], 32) Dies wirkt wie ein Link zwischen strukturierten und nicht-strukturierten Inhalten. Ein Beispiel dazu wäre ein drag & drop Link der Klagefall eines Kunden mit einer spezifischen Retoure, die z. B. wegen Prezedenzfallcharakter in Portalinhalt aufgenommen wurde. Abbildung 1-2: Struktur der SAP BI-Lösung Quelle: ([McDonald2002], 25) 16

17 2 Architekturkonzeptionen für Data Warehouses 2.1 Abgrenzung des DW Begriffs Definition einer Data Warehouse W.H. Inmon hat die folgende Definition von Data Warehousing geprägt: Ein Datenlager 2 ist eine themenorientierte, integrierte, nichtvolatile und historisierte Sammlung von Daten die primär auf die Entscheidungsprozesse der Organisation unterstützt ([Inmon 2001]). Eine nähere Betrachtung der Schlüsselbegriffe (vgl. [TS- SapBw2002], 1-2): 1. subject-oriented: Die Themenausrichtung an Sachverhalten des Unternehmens, z.b. Kunden- oder Produktkriterien, wird im BW durch das konsequente Einordnen aller Daten in Fachbereiche und durch die Bezugnahme auf Geschäftsprozesse realisiert. 2. integrated: Mit dem DW-Konzept wird die unternehmensweite Integration von Daten in einem einheitlich gestalteten System angestrebt ([Behme 2000], 11f). Vereinheitlichung und Integration externer und interner Daten bedeutet weniger die physische Zentralisierung der Daten in einem zentralisierten Datenpool, sondern deren logische Verbindung. 3. nichtflüchtig (nonvolatile): Bei einer DW handelt es sich um eine dauerhafte Sammlung von Informationen, auf die im Gegensatz zu OLTP-Systemen nur in Form von Lese- und Einfügeoperationen zugegriffen werden darf, um die Nicht-Volatilität der Daten sicherzustellen. Dieser Forderung kann jedoch nur bedingt zugestimmt werden, da Korrekturen von aus Quellsystemen geladenen Daten auf jeden Fall möglich sein müssen. 3 ([Behme1996], 31f) 4. historisiert (time-variant): Während bei operativen Systemen eine zeitpunktgenaue Betrachtung der Daten im Mittelpunkt steht, liegt das Interesse bei Auswertungen im DW eher in einer Zeitraumbetrachtung, z.b. einer Trendanalyse ([Behme 1996], 31f). Die Historisierung ist daher impliziter oder expliziter Bestandteil der Daten in einem 2 Datenlager wird als Synonym zur Data Warehouse verwendet 3 Das BW bietet hierfür eine Eingangsablage in Form der Persistent Staging Area (PSA), das Korrekturen von Daten vor der Fortschreibung zulässt. Andere Anwendungen wie SEM brauchen zumindest eine Kopie von InfoCubes, damit sie im Rahmen der Planaufgaben auf InfoCubes schreibend zugreifen können. 17

18 DW. Ein Ansatz zur Herstellung dieses Zeitraumbezugs im BW ist die obligatorische Verwendung einer Zeitdimension in jeder multidimensionalen Speicherstruktur Der erweiterte DW-Begriff Viele Literaturquellen stellen aber auch Funktionen außer der reinen Speicherfunktionalität im Rahmen der Data Warehousing Aufgaben. Die vorgelagerte Aufgaben von Anbindung, Extraktion, Transformation und Übertragung von Daten werden unter dem Dachbegriff ETL 4 (Extract, Transfer, Load) vereint und werden als Teil von Data Warehousing betrachtet, da Sie viel häufiger und intensiver gegenüber den transaktionalen Systemen abgewickelt werden sollen. Dieser Aufgabenbereich wird auch Datenbereitstellung genannt. Nachgelagert ist die eigentliche Datenverwendung. Häufig bereitet ein DW die Daten für verschiedenste Aufgaben auf: Berichterstellung Analyse von Daten mittels verschiedenen Methoden (u.a. Data Mining) Meldewesen (Ausnahmen- und Kontrollwarnungen) Datenvorbereitung für Data Marts oder andere DW-Instanzen (oft als Hub bezeichnet) 4 ETL wird im Rahmen dieser Arbeit Synonym mit den Begriffen Datenbereitstellung und Datenbeschaffung verwendet. 18

19 Abbildung 2-2-1: Das Common Warehouse Metamodel Quelle: [CWMspec], 6-53 Bei Common Warehouse Metamodel (CWM) liegen die vor- und nachgelagerte Anwendungen auch im Beschreibungsrahmen der DW. Der Analysis-Package spezifiziert den Transformation Unterpaket als Beschreibungsrahmen für ETL- Dienstleistungen; OLAP, Data Mining und Information Visualization Unterpakete beschreiben die Warehouse-Funktionen Berichterstellung, Datenanalyse und Meldewesen. So können wir von einem erweiterten DW-Begriff sprechen, die die obigen Aufgaben als Teil einer Data-Warehouse Lösung aufgreift. 19

20 Abbildung 2-2: Der erweiterte DW- Begriff Quelle: Eigene Darstellung 2.2 Fachbegriffe im DW-Umfeld Architekturbegriffe Die hier vorgestellten Architekturbegriffe orientieren sich weitgehend an er zentralistischen Data Warehouse Ansatz von [Kimball1998]. Bei größeren Abweichungen werden explizite Quellangaben gemacht Quellsystem Ein Speichersystem das die Geschäftstransaktionen abbildet. Häufig handelt es sich um transaktionale Datenbanken, die auch operative Reportingfunktionen in ihrem Verantwortungsbereich erfüllen Data Mart Data Marts werden von Kimball als eine logische Teilmenge des gesamten Data Warehouse betrachtet. W.H. Inmon hat einen unterschiedlichen Ansatz. Grundlegende unterschiede zwischen beiden Konzeptionen wird im Abschnitt 2.3 näher erörtert. Vorerst geben wir uns mit der Beschreibung nach Kimball zufrieden. 20