Konzeptionen und Modelle für Data Warehouses - Eine ...ERP Enterprise Resource Planning ETL Extract, Transfer, Load MDX Multidimensional Expressions ODBO ODBC for OLAP ODBC Open Database

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...................................................................................................................... 7 1 BUSINESS INTELLIGENCE, DATA WAREHOUSING UND SAP .................................... 9

1.1 Geschichtliche Entwicklung der Datenverwendung.................................... 9 1.1.1 Anforderungen der Datenanalyse ......................................................... 9 1.1.2 Der Data Warehouse-Begriff .............................................................. 12 1.1.3 Business Intelligence .......................................................................... 12

1.2 SAP Data Warehousing und Business Intelligence.................................... 13 1.2.1 Know-How Entwicklung im ERP-Umfeld ......................................... 13 1.2.2 Business Intelligence Lösung der SAP............................................... 15 1.2.3 BW und Einbindung in Enterprise Portal ........................................... 16

2 ARCHITEKTURKONZEPTIONEN FÜR DATA WAREHOUSES ..................................... 17 2.1 Abgrenzung des DW Begriffs ...................................................................... 17

2.1.1 Definition einer Data Warehouse ....................................................... 17 2.1.2 Der erweiterte DW-Begriff ................................................................. 18

2.2 Fachbegriffe im DW-Umfeld ....................................................................... 20 2.2.1 Architekturbegriffe ............................................................................. 20 2.2.2 Analysebegriffe................................................................................... 22 2.2.3 Speicherstrukturbegriffe ..................................................................... 23

2.3 Beschreibung einer DW................................................................................ 24 2.3.1 Architekturbeschreibung nach Entstehungsprozess............................ 24 2.3.2 Architekturbeschreibung nach DW-Verwendung .............................. 26 2.3.3 Architekturvarianten ........................................................................... 31 2.3.4 Morphologische Merkmale zur Zuordnung eines Systems zum DW. 33

2.4 Organisation der BW-Architektur.............................................................. 36 2.4.1 Funktionsstruktur allgemein ............................................................... 36 2.4.2 Datenhaltung....................................................................................... 37 2.4.3 Datenbereitstellung (Staging) ............................................................. 38

2.5 Metadatenelemente in der BW-Architektur .............................................. 39 2.5.1 Elementare Bausteine ......................................................................... 42 2.5.2 Stammdatenbereich............................................................................. 45 2.5.3 Speicherstrukturen .............................................................................. 48 2.5.4 Analysestrukturen ............................................................................... 50 2.5.5 ETL Strukturen ................................................................................... 51

3

3 DATENMODELLE FÜR OLAP................................................................................... 53 3.1 Datenmodelle als Bestandteil der Architektur........................................... 53

3.1.1 Rahmenbedingungen zu relational-multidimensionalen Strukturen... 53 3.1.2 Ebenen der Datenmodellierung .......................................................... 54

3.2 Multidimensionale Strukturen .................................................................... 55 3.2.1 ROLAP und MOLAP ......................................................................... 56 3.2.2 Von normalisierter Struktur zum Sternenschema............................... 56

3.3 Logische Datenschemata für multidimensionale Strukturen ................... 59 3.3.1 Flache Strukturen................................................................................ 59 3.3.2 Starschema .......................................................................................... 59 3.3.3 Snowflake-Schema ............................................................................. 61 3.3.4 Galaxy-Schema................................................................................... 64 3.3.5 Zusammenfassung von Schemaeigenschaften.................................... 64

3.4 Physisches Datenschema bei BW................................................................. 65 3.4.1 Erweitertes Starschema....................................................................... 66 3.4.2 Abkapselung von InfoCubes............................................................... 67

3.5 Stammdatenmodell des BW......................................................................... 68 3.5.1 Master-Data-Modell............................................................................ 68 3.5.2 Modellierung von Hierarchien............................................................ 70

4 MODELLIERUNG VON DATENBEREITSTELLUNG..................................................... 72 4.1 Staging in BW................................................................................................ 72

4.1.1 Extraction Layer ................................................................................. 72 4.1.2 Inflow Layer ....................................................................................... 73 4.1.3 Transformation Layer ......................................................................... 74 4.1.4 Integration Layer................................................................................. 76

4.2 Transformationsprozesse ............................................................................. 77 4.2.1 Datenintegrationstransformationen..................................................... 77 4.2.2 Anwendungslogik-enthaltende Transformationen.............................. 77 4.2.3 Transformationsarten nach Objekten.................................................. 77 4.2.4 Transformationsstufen in BW............................................................. 78

4.3 Referenzstrukturen für den Datenfluss ...................................................... 78 5 ZUSAMMENFASSUNG UND SCHLUSSWORT .............................................................. 81 LITERATURVERZEICHNIS............................................................................................... 84 EHRENWÖRTLICHE ERKLÄRUNG .................................................................................. 86

4

Abbildungsverzeichnis

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

5

Tabellenverzeichnis

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

6

Abkürzungsverzeichnis

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

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

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.

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.

1.1.1 Anforderungen der Datenanalyse Hochnormalisierte Tabellenstrukturen nach dem ERM bieten viele Vorteile: Sie vermeiden redundante Speicherung und verringern somit die Fehlerquote bei der Ein- und 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.

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.

Tabelle 1-1: Vergleich von OLTP und OLAP OLTP OLAP Ziel Effizienz der

Datenverwaltung durch Automation steigern

Effektivität der Entscheidungen/Prozesse durch Informationsgenerierung erhöhen

Inhalt der Daten Anwendungsbezogen, Funktionsbezogen

Themenbezogen

Art der Daten Transaktionsdaten Aggregierte Daten Alter der Daten Aktuell und zeitnah (0-60

Tage) Historisch (2-10 J, typisch 5J) und aktuell

Datenvolumen Klein Sehr hoch Hauptfunktionalität Häufige Änderungen Zeitabhängige

Auswertungen Datenintegration Gering bei isolierten

Anwendungen, höher bei ERP

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

11

Modellierungsmethode Qualitätskriterium der Modellierungsmethoden

NF: Nichtredundante Speicherung und Verweiseffizienz

MNF: Nichtredundanz, Abbildungstreue zur Anwendungswelt, Kontextabhängigkeit der Datenverwendung

Erlaubte Operationen auf den Datenbestand

Einfügen, aktualisieren, löschen, lesen

Lesen

Quelle: Eigene Darstellung, in Anlehnung an ([TS-SapBw02], 15)

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

1.1.1.2 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

12

vorgegeben. Andere Tabellen werden im Rahmen der Customizing1 frei- bzw. abgeschaltet. 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.

1.1.2 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)

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

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 Implementierungsan-forderungen 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.

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

1.2.1.1 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)

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)

1.2.1.2 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

15

ausgerichtet. Dementsprechend greifen diese Lösungen nicht auf Daten aus dem ERP-System mySAP, sondern aus Daten des Business Information Warehouse zu.

1.2.2 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)

Tabelle 1-2: Beziehungen von SAP Produktkomponenten mit BW Produkt (Technology Component)

Anwendung (Analytic Application)

Zielsetzung Beziehung mit BW

BW - Datenintegration, für Analyse geeignete Datenstrukturen erstellen und verwalten

reflexive Beziehung, liefert oder empfängt von BW: Hub / Spoke (Warehouse / Data Mart)

SAP SEM 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

SAP CRM mySAP CRM Kundenanalyse per Data Mining verwendet Daten von BW (Data Mining Workbench und Business Content), Customer Relationship Analytics (CRA) ist in BW integriert

SAP APO mySAP SCM Informationsflüsse zwischen Geschäftspartner organisieren (SCOR-Modell, SC-Planung, Monitoring)

APO System hat eingebettete BW-Technologie, ist von BW separat

Datenquelle: ([McDonald2002], ,336)

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)

17

2 Architekturkonzeptionen für Data Warehouses

2.1 Abgrenzung des DW Begriffs

2.1.1 Definition einer Data Warehouse W.H. Inmon hat die folgende Definition von Data Warehousing geprägt: „Ein Datenlager2 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.

18

DW. Ein Ansatz zur Herstellung dieses Zeitraumbezugs im BW ist die obligatorische Verwendung einer Zeitdimension in jeder multidimensionalen Speicherstruktur.

2.1.2 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 ETL4 (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.

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.

20

Abbildung 2-2: Der erweiterte DW- Begriff


2.2 Fachbegriffe im DW-Umfeld

2.2.1 Architekturbegriffe Die hier vorgestellten Architekturbegriffe orientieren sich weitgehend an er zentralistischen Data Warehouse Ansatz von [Kimball1998]. Bei größeren Abweichungen werden explizite Quellangaben gemacht.

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

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

21

2.2.1.3 Operational Data Store Der Begriff “Operational Data Store” hat deutlich unterschiedliche Interpretationen. BW kompliziert die Situation noch mehr, indem sie „ODS Objekte“ als Strukturobjekte einführt. Die erste Auffassung von ODS besagt, dass ein ODS der Integrationspunkt für alle Datenquellen ist ([Kimball1998], 20 und 340). Sie hat mit einem Data Warehouse nichts zu tun. Die Strukturen sind normalisiert, Ziel ist eine konsistente Speicherung von Daten zu erreichen und dadurch eine schnellere transaktionsorientierte Anbindung von segmentierten Daten zu ermöglichen. Sie bildet sozusagen den Integrationspunkt für alle transaktionale Daten des Unternehmens. Beispiel wäre ein Finanzinstitut, die ihre Daten Geographie- und Quellsystemüber-greifend organisieren will. So kann eine Transaktion an einer ATM in Filiale X an einem Schalter im Filiale Y schneller reflektiert werden. Solch ein System soll repliziert werden / als Datenlieferant dienen, um Analyseanforderungen einer DW zu genügen.

Abbildung 2-3: Erste Auffassungsart für ein ODS


Die andere Auffassung betrachtet den ODS als Teil des DW-Systems. Sie ist im DW untergebracht und für „operative“ Analysen konzipiert. Somit unterstützt es direkte Abfragen, insbesondere für operative Aufgaben, die mit weniger Historisierung und

22

ohne multidimensionale Analysestrukturen auskommen.5 Der ODS enthält aber zumindest aktuellere, oft aber auch Echtzeit-Daten. In dieser Auffassung liefert der ODS seine Daten nur für Analysezwecken, Daten werden an Quellsysteme nicht zurückgeliefert.

2.2.1.4 Staging Area Der Staging Area ist für den ETL-Prozess bereitgestellter Datenbereich im Data Warehouse. Dieser Bereich gewährt eine Einsicht in die Daten, die zu den Analysestrukturen übertragen werden sollen, Gewöhnlicherweise in Form einer Zwischenablage. Verschiedene Werkzeuge (Extraktoren, Metadatentools) können in die ETL Funktionen des Stagingbereichs angebunden werden.

2.2.2 Analysebegriffe

2.2.2.1 Multidimensionale Modelle (Dimensional Model) Dimensionale Modellierung ist eine alternative Modellierungsvorgehensweise zum ERM. Sie richtet sich an die Anforderungen der Datenanalyse. Weitverbreiteste Schema dieser Disziplin ist das Starschema. Hauptmerkmale dieser Schema sind denormalisierte Strukturen, die nach betriebswirtschaftlichen Bereichen wieder in Dimensionen und Faktentabellen organisiert werden.

2.2.2.2 Abfrage (Query) Eine zur Laufzeit zusammengestellte Sammlung von Tabellen. Abfrageergebnisse können analog zu Abfragedefinitionen gespeichert werden. Gespeicherte Abfragetabellen heißen „views“. Einige Produkte verwenden den „view“ Begriff für die Abfragedefinition und den „materialized view“ Begriff für die gespeicherten Abfragetabellen. ([OracleWB2003], 3-10) In Datenlager werden die Queries durch den OLAP Prozessor abgewickelt.6

2.2.2.3 OLAP OLAP bedeutet On-line Analytical Processing. Abfrageabwicklung bei transaktionalen Systemen heißt dagegen OLTP. BW hat die eigene semantische und logische Modellierungsstruktur. ABAP-Dictionary Tabellen werden jedoch physisch auf Drittsystemdatenbanken abgebildet. BW 3 ist

5 ODS Objekte von SAP sollen für die Implementierung der zweiten Variante von ODS dienen. Zudem übernehmen ODS Objekte wichtige Aufgaben im Rahmen der sogenannten multi-level Staging. 6 BW kann sowohl auf relationelle als auch auf multidimensionale Datenbanken Abfragen durchführen.

23

primär dafür konzipiert, auf ROLAP-Datenbanken (Relational OLAP) mit Hilfe von OpenSQL-Kommandos zuzugreifen, kann jedoch mittels MDX-Kommandos auch auf die MOLAP7 (Multidimensional OLAP) Strukturen der Microsoft-SQL-Server zugreifen.

2.2.3 Speicherstrukturbegriffe

2.2.3.1 Flache Struktur Speicherstrukturen, die eine denormalisierte Struktur aufweisen. Physische Instanzen sind z. B. Textdateien oder ODS-Objekte von BW. Textdateien sind völlig denormalisiert (1.NF) und werden manchmal auch flatfile genannt

2.2.3.2 Dimension Eine Gruppierung von Attributen nach ihrer betriebswirtschaftlichen Zusammengehörigkeit. Die analoge Struktur in einem ERM wäre die Entität.

2.2.3.3 Dimensionsattribut (Dimensional Attribute) Ein Datenfeld, dass einem Dimension zugeordnet ist. Dimensionsattribute besitzen oft einen „vorhersagbaren“ Charakter, d.h. das Unternehmen verfügt über diese Information vor der Entstehung eines „Fakt“-Datensatzes und geht davon aus, dass das Attribut sich über einen längeren Zeitraum nicht verändert.

2.2.3.4 Fakten (Facts) Fakten sind Datenfelder, die betriebswirtschaftliche Beobachtungsgrößen darstellen. Sie sind grundsätzlich nicht vorhersagbar. Deswegen kommt ein Zahl-Datentyp (insbesondere Gleitkommazahlen) als die häufigste Instanz eines Faktes vor. Die am einfachsten handhabbaren Faktentypen sind numerisch und additiv. ([Kimball1998], 144) Zahl-Datentypen erlauben zudem die Bildung von Aggregate zur Beschleunigung von Queries. Fakten sind in der zentralen Faktentabelle zu finden. Unter allen Tabelleneinträgen besitzen sie die größte Kardinalität. In BW-Taxonomie heißen die Fakten Kennzahlen.

7 Manchmal wird MOLAP auch als Memory-intensive OLAP übersetzt. Die Ursache liegt darin, dass die Ausführung eines Lesezugriffs bei MOLAP Systemen besonders ressourcenintensiv (aber effizient) hinsichtlich der Hauptspeichernutzung ausfällt. (vgl. [Mehrwald2003], 138)

24

2.2.3.5 Einheitliche Dimensionen (Conformed Dimensions) Eine sorgfältige, einheitliche Definition von Dimensionen erlaubt die Wiederverwendung von Dimensionen bei vielen Faktentabellen. Diese Struktur liegt dem Galaxyschema zugrunde und wird in Verbindung mit dem Begriff Data Warehouse Bus ([Kimball1998], 164) verwendet. Einheitliche Dimensionen sind in identischer Form mit vielen Faktentabellen vereinbar(joinbar).

2.2.3.6 Künstliche Schlüssel (Surrogate Keys) Künstliche Schlüssel sind Schlüsseln, die keine Beziehung zum durch den Schlüssel repräsentierten Datensatz haben. Sie haben Bedeutung aus Datenbanktechnischer sicht, da Sie ein Mechanismus darstellen, der die Performanz optimiert und den Datensatz - trotz mehrmaligem Auftreten in verschiedenen operativen Systemen - eine eindeutige Identifikation im DW zuordnet. Im BW werden künstliche Schlüssel im Form von SIDs (Stammdatenidentifikations-schlüssel) implementiert.

2.3 Beschreibung einer DW Die Architektur von DW i.w. Sinne wird oft auch nach den drei Strukturschichten von Datenbereitstellung, Datenhaltung und Analyse beschrieben. Eine der Hauptdifferenzen liegt darin, wie die Datenhaltungsschicht (also der DW i.e.S.) abgegrenzt werden soll. W.H. Inmon definiert den ODS als die „eigentliche Datengrundlage“ des Data Warehouses während Kimball die multidimensionale Analysestrukturen als solches betrachtet. Diese unterschiedliche Wahrnehmungen haben zu verschiedenen Schwerpunkten bei der Betonung der Aufgaben geführt. Es bestehen sehr viele Gemeinsamkeiten hinsichtlich der Beschreibung von Sachverhalten im DW-Umfeld zwischen den beiden Autoren. Beide Autoren gehen zunächst von einer zentralistischen DW aus. Dennoch kann man durch eine nähere Betrachtung der Inhalte zu neuer Einsicht gelangen; deswegen soll hier auf die unterschiede tiefer eingegangen werden.

2.3.1 Architekturbeschreibung nach Entstehungsprozess In [Kimball1998] wird ausführlich beschrieben, welche Zyklen während der DW-Entstehungsprozess durchlaufen werden. „Der Business Dimensional Lifecycle“ wird als ein Entwicklungsrahmen für DW vorgestellt.

25

Abbildung 2-4: Der Business Dimensional Lifecycle

Quelle: [Kimball1998], 33

Diese Vorgehensweise betont insbesondere die iterativen Entwicklungsstufen bis zur Entstehung einer Data Warehouse. Ziel ist es, die DW nicht zu einem Monsterprojekt wachsen zu lassen, sondern iterative Entwicklungsstufen explizit im Voraus zu definieren. Somit werden zunächst Analyseziele priorisiert und danach die erste Menge von multidimensionalen Strukturen definiert. Diese Sammlung von multidimensionalen Strukturen wird zusammen mit den dazugehörigen Datenbereitstellungsfunktionen und Abfragen als ein Data Mart bezeichnet. Nach der Erstellung eines Masterplans hat jede Iteration die Zielsetzung, eine oder mehrere kleinere Data Marts nach ihrer Priorität (im Rahmen des DW-Gesamtplans) zu implementieren. Die Data Marts werden durch den sogenannten „Data Warehouse Bus“ (d.h. einheitliche Dimensionen und Galaxyschema) konsistent gehalten ([Kimball1998], 155). Die erste Reihe von Data Marts (in der Abbildung 2-5 Iterationen 1, 2, und 3) zielen darauf ab, möglichst granulare Fakten zu schaffen. In diesem Kontext bedeutet „granular“ (deutsch: Körnig) einfach das semantisch „kleinere“ bzw. detailliertere Datentyp. Beispiel dazu wären Fakten von „Stunden“ gegenüber Tagen oder Wochen. Die nächste Reihe von Data Marts können auf die granularen Strukturen aufbauen und somit geschäftsprozessabhängige Zusammenfassungen bieten. Bildet man eine einzige multidimensionale Struktur direkt auf eine andere, weniger granulare ab, so kann man

26

de facto von einer manuellen Aggregationsvorgabe für eine bestimmte multidimensionale Struktur sprechen.

Abbildung 2-5: Data Warehousing Begriffe nach Kimball


Kimball macht im [Kimball1998] wenige klare Aussagen zum Inhalt des ODS, da er die DW als eine Struktur betrachtet, die aus multidimensionalen Strukturen besteht. Die Rahmenbedingungen sind die folgende: „Der ODS sollte eine auf die Unterstützung von transaktionalen Systemen gerichtete, themenorientierte, integrierte und häufig aktualisierte Speicherform für detaillierte Daten anbieten. Alle für die entscheidungsunterstützenden Maßnahmen verwendete Daten sollten als die atomare Ebene einer DW wahrgenommen werden.“ ([Kimball1998], 341)

2.3.2 Architekturbeschreibung nach DW-Verwendung W.H. Inmon beschreibt die DW-Strukturen zunächst auf einer höheren, von Implementationsaspekten abstrahierten Ebene. Sein Ziel ist zunächst einen Blueprint des fertiggestellten Datenlagerumfelds zu erstellen. Eine Analogie wäre einen langfristigen Stadtplan zu machen und danach die zu implementierenden Teilbereiche zu definieren. Sein Referenzschema dazu heißt die „Corporate Information Factory“. (CIF)

27

Abbildung 2-6: Der Corporate Information Factory

Quelle: [URL1]

Hier sorgen die neuen Begriffe wie „exploration warehouse“ und „storage manager“ zunächst für Verwirrung. Die Ursache liegt in der unsauberen Trennung der Analyse von Data Warehouse oder Data Marts, der Präsentation von lokalen Kopien von Elementen (z.B. local ODS8 vs. Global ODS) und spezielle Bezeichnungen für neue Funktionen (wie Archivierung). Eine Normierung des Diagramms nach unserer bisherigen Vorgehensweise schafft Abhilfe:

8 „Lokaler ODS“ in diesem Zusammenhang heißt nur, dass eine Teilstruktur der ODS aus Performanzgründen repliziert wird.

28

• Staging area ist bekannt. Es handelt sich hierbei um eine Zwischenstufe der Datenbereitstellung, die dem DW und ODS vorgelagert abzubilden ist. Wird in dem normiertem Diagramm (Abb. 2-7) nicht abgebildet.

• Den „Web Environment“ bilden wir nicht ab, weil es nicht in unserem Betrachtungsrahmen passt.

• Granularity Manager wird auch nicht behandelt, da es sich hierbei um Funktionen und Metadatenhaltung handelt. Bisher haben wir exklusiv Daten und nicht Metadaten abgebildet.

• Wir bilden für jede flache Struktur die entsprechende multidimensionale Struktur ab, die in fast jeder Datenverwendungsszenario zwangsmäßig anfällt. Die explizite Angabe ermöglicht den Vergleich von Abb. 2-8 mit Abb. 2-5) Somit können die restlichen Teilstrukturen folgendermaßen abgebildet werden:

Abbildung 2-7: Normierung der CIF (Abb. 2-6)


Es soll hier hervorgehoben werden, dass Inmon die denormalisierten Strukturen als die Grundlage des Data Warehouses betrachtet. Deswegen wird in BW betont, dass die

29

ODS-Objekte, zusammen mit dem Master Data, den DW-Fundament bilden sollen. ([McDonald2002], Kap. 3)

Abbildung 2-8: Normierte Abbildung der CIF

Quelle: Eigene Darstellung, nach Abb. 2-5 und 2-6

Die obige Abbildung beschreibt, dass ein Rückschreiben der Daten aus dem Data Warehouse zurück zum ODS möglich sein soll. Diese Funktionalität wird von den Reextraktoren für BW geliefert. Dabei steht die Idee zugrunde, dass in dem DW berechnete Größen als Planvorgaben zurück in transaktionale Systeme geliefert werden können. Dies ist z.B. bei SCM wichtig, wo die Planlieferzeiten, da detaillierte Planlieferzeiten im operativen Betrieb sichtbar sein sollen. Als Entwicklungsgrundlage für den ODS im BW werden virtuelle RemoteCubes und ODS-Objekte sowohl transaktioneller als auch nichttransaktioneller Art vorgeschlagen. Virtuelle InfoCubes erlauben die Lieferung der Daten aus dem zum Quellsystem zur Laufzeit, wodurch ein Echtzeit-Datenlieferant ohne echte Datenhaltung geschaffen wird. Laut CIF soll eine Teilstruktur der ODS (operativer Data Mart) direkt für Analysezwecken verwendbar sein. Dies ist auch durch ODS-Objekten von BW realisierbar, da sie InfoProvider-Metadatenobjekte sind und deswegen für Analysezwecke herangezogen werden können. Die Data Marts haben eine zweite Bedeutung für Inmon, insbesondere im Rahmen von SAP BW. Sie sollen wieder primär aus den flachen Strukturen von BW, den ODS-

30

Objekten, bestehen. Durch den Begriff InfoMart schafft er einen neuen Begriff, der die Data Marts bei [Kimball1998] entspricht. Im Rahmen der Analyse verwendet [McDonald2002] den Begriff InfoMart. Die multidimensionalen Datenstrukturen von BW, die InfoCubes, sollen exklusiv in dieser Schicht vorkommen. Da diese von der Datenlieferung unabhängig definiert werden, sind sie relativ einfach zu erstellen. In [McDonald2002] wird vorgeschlagen, dass wegen der leichten Veränderbarkeit dieser Strukturen die Infrastruktur durch ODS Objekte modelliert und die Forschreibung von Daten von ODS Objekten in die InfoCubes öfters angepasst werden soll.

Tabelle 2-1: Merkmale, die von Data- und InfoMarts gewährleistet werden können Mögliche Merkmale InfoMart Data Mart Dynamische Datenhaltung Ja Ja Entsorgbarkeit Ja Ja Flüchtige Datenhaltung Ja Nein Nichtflüchtige Datenhaltung Ja Ja Flache Struktur Ja Nein Dimensional Ja Ja Virtuell Ja Nein Zielgruppenorientiert Ja Ja Orientierung an Analyse und Berichtswesen Ja Ja Exploration / mining Beschränkt Beschränkt

Quelle: [McDonald2002], 74

Steuert man aber die DW-Infrastuktur und insbesondere die Granularität langfristig und schwerpunktmässig durch ODS Objekte, verliert man aber an Informationen hinsichtlich der Analyse, da Aggregate nur InfoCubes vorenthalten sind. Der geringe Datenbestand an Abfrageverhalten (wegen InfoCubes mit kurzer Lebensdauer) erschwert die Aggregatoptimierung. Modellierer haben dadurch wenige Informationen zur Bestimmung der Granularität zukünftiger Analysestrukturen. Bei Löschung eines InfoCubes gehen auch die historisierten Daten verloren. Persistente Analysemöglichkeiten sollten nach wie vor durch InfoCubes realisiert werden. Im weiterführenden Teil dieses Dokuments orientiere Ich mich an die Taxonomie von:

• [Kimball1998] bezüglich des Begriffs Data Mart und Data Warehouse (InfoMart Begriff wird also nicht verwendet, weil zwischen Data und InfoMarts nicht unterschieden wird)

31

• [McDonald2002] bezüglich der ODS. Die einzige Ausnahme bezüglich ODS ist also, dass das ODS ein Teil der Data Warehouse darstellt.

2.3.3 Architekturvarianten In den vorangehenden Abschnitten wurden zwei verschiedene Blickwinkeln zum DW-Architekturbeschreibung vorgestellt. Zentral bei diesen Überlegungen ist, dass das gesamte Data Warehouse einheitlich nicht alle Analyseanforderungen decken kann und aus betriebswirtschaftlich-organisatorischen und Performanzgründen eine Anzahl von Data Marts existieren muss. Schwierigkeiten und Inkonsistenzen bei der Definition des Begriffs haben einen empirischen Grund. In der Praxis können die folgenden drei Objekte inhaltlich dieselbe Bedeutung haben:

• Multidimensionale Struktur • Data Mart • Data Warehouse

Normalerweise sollen diese Objekte nach der Auflistungsreihe größere Datenmengen beherbergen. Es ist aber möglich, dass eine multidimensionale Struktur Milliarden von Einträge beherbergt. Die Data Marts können so groß sein, dass Sie alleine eine DW-Installation anfordern. Bei den Leistungsanforderungen, die an Data Warehouses gestellt werden, kann man nicht immer von zentralisierten Lösungen ausgehen. Es muss möglich sein die Strukturen zu teilen und wieder zusammenzufassen. Voraussetzung dafür ist, dass Data Warehouse Instanzen die Daten weitergeben können. Dabei können Sie (wie BW) auch besondere Funktionen anbieten, wenn Sie aus einem Quellsystem vom gleichen DW-Hersteller empfangen. (BW zu BW Datenlieferung) Bei BW zu BW Datenlieferung verwendet BW sein Dienstleistung „Open Hub Service“, dessen wichtigster Metadatenobjekt ein InfoSpoke ist. Solche Architekturen nenn man Hub-and-Spoke Architekturen. Es gibt eine Reihe von betriebswirtschaftlichen, technischen und geopgraphische Probleme, die zu Hub-and-Spoke Landschaften führen. Häufig sind zentralisierte Lösungen nicht realisierbar wodurch verteilte Data Warehouse Landschaften entstanden sind. Die Abbildung 2-9 illustriert eine Hub & Spoke Architektur. In diesem System kann man jede Datensammlung, die mit DW beschriftet ist, als ein eigenständiges Data Warehouse betrachten. Mann kann aber die „Hubs“ als Data Warehouses die „Spokes“

32

(„DW“ ganz links und ganz rechts) als als Data Marts bezeichnen. So wären Spokes für eine bestimmte Zielvorgabe optimierte Datensammlungen. Es ist aber auch möglich, die Gesamtstruktur als ein einziges Data Warehouse zu betrachten, wobei dann die Datensammlungen zwischenstufen für das multilevel Staging darstellen würden. Hier wird nochmals deutlich, dass eine genaue Abgrenzung des DW-Systems (hinsichtlich der Datenhaltung) äußerst schwer fällt.

Abbildung 2-9: Hub & Spoke Architektur

Quelle: Eigene Darstellung, in Anlehnung an ([Mehrwald2003], 40)

2.3.3.1 Replizierende Architektur Replizierende Architekturen liefern eine Teilmenge der Daten an eine andere Data Warehouse Instanz. Grund dafür kann z. B. sein ([Mehrwald2003], 40):

• Geographische Verteilung der Endanwender (Analysten), sodass eine geographisch naheliegende Kopie der Mengen erfordert wird.

• Die gesamte Datenmenge durch viele Analysen zu stark belastet wird und die Daten müssen aus Leistungsgründen nach betrieblichen Funktionen an Data Marts ausgelagert.

• Die Staginganforderungen zu groß werden und die Datenanalyse wird dadurch behindert.

• Eine Tool die Datenmenge in einem bestimmten Aufbereitungsform oder eigenen DW-Installation verlangt (z. B. Simulation am SAP APO)

33

2.3.3.2 Aggregierende Architektur In der aggregierenden Architektur stellt die Datenbereitstellung den Engpass. Folgende gründe sind häufige Ursachen ([Mehrwald2003], 41):

• Geographische Trennung von Quellsystem und Warehouse • Die eingelieferten Datenmengen im Rahmen des Stagings sind zu Groß, um von

einem DW-Applikationsserver auszuarbeiten • Das organisatorische Rahmenwerk um den DW-Projekt und Teilprojekte zwingt

zu Teillösungen

2.3.3.3 Virtuelle Strukturen Virtuelle Strukturen ermöglichen den Austausch von Daten zum Zeitpunkt der Analyse auszutauschen. Daten werden nicht lokal im empfangenden System gespeichert, sondern erst zur Analysezeit vom Quellsystem angefordert. In SAP wird diese Funktionalität mittels RemoteCubes realisiert.

2.3.3.4 Verteilte DW-Architekturen In der Praxis werden replizierte, aggregierende und virtuelle Strukturen miteinander kombiniert. Die größere Anzahl von Data Marts und immer wachsenden Mengen von Daten lassen vorausahnen, dass die Zukunft verteilten Speicher- und Verarbeitungsstrukturen, die je nach Last die Anfragen an entsprechenden Stellen weiterleiten können, gehört. ([Kimball1998] 26, 28) Einheitlichen Dimensionen sollen das Bindeglied von verteilten Data Marts / Data Warehouses darstellen. Solche Strukturen können dann zur regionalen oder funktionalen Verteilung der DW genutzt werden. Man spricht in diesem Zusammenhang von federated data warehouses, da die lokale Datenverwaltung der lokale DBMS zusteht. Falls der zentrale DW-Instanz Daten von entfernten Instanzen braucht, soll er dann lediglich die Abfragendefinition an die lokalen DBMS zustellen, die Abarbeitung der Abfragen erfolgt intern. ([Jindal], 4)

2.3.4 Morphologische Merkmale zur Zuordnung eines Systems zum DW

Um was handelt es also, wenn wir von einem Data Warehouse System sprechen? Wie ist de Abgrenzung zwischen der Data-Warehouse-Datenbank und den restlichen Datenbanken zu treffen? Datenmengen, Quellsysteme und DBMS-Installationen können alle gültige Bezugspunkte sein. Zudem wirkt das Bild für verteilte DBMS Systeme und verteilte Abfragen noch komplexer.

34

Als Abhilfe soll der folgende Morphologischer Kasten dienen:

Tabelle 2-2: Morphologische Merkmale zur Zuordnung eines Systems zum DW Merkmal Ausprägung

Physische Distanz der Daten zu andere „Installationsinstanzen“

SELBE FESTPLATTE- ODER

HARDWARESYSTEM auf LAN auf WAN

IV-organisatorisch separate Installation Zugriffspartition Verarbeitungsfokus ANFRAGEN Datenhaltung Anbindungsmodus real Virtuell Datenfragmente Tabelleuntermenge Tabellenübergeordnet Abfragehoheit keine eigene

Anfragen Fremde Anfragen


Erklärungen

• Die physische Distanz: Bei der „physischen“ Distanz zwischen Daten handelt es sich um die „netzwerkmäßige“ Distanz der Daten. Bei einer großen geographischen Distanz handelt es sich wohl nicht um eine enge Zusammenarbeit der Datenbanken, sodass der Data Warehouse wahrscheinlich die Daten von einem anderen DBMS-Installation bezieht, die Daten aber nicht kooperativ bearbeitet. Die geographische Distanz kann also je nach verfügbarer Netzwerkleistung ein Abgrenzungsmerkmal für den Data Warehouse und anderen Systemen sein.

• IV-organisatorisch:

Die separate Installation eines DW-Produkts ist ein deutlicher Hinweis darauf, dass es sich um ein separates DW-System handelt. Es gibt aber auch Gründe, warum eine gesonderte Installation notwendig sein kann (Archivierung, Test, Leistungsoptimierung etc.), sodass hinsichtlich der Zieldefinition es sich um „ein System“ handeln kann.

• Verarbeitungsfokus:

Ein System kann verschiedene Hardwareplattformen umfassen, sodass es sich um ein DW-Instanz handelt. Insbesondere sieht SAP ein 3-Tier-Architektur vor, dass durch mehrere Präsentationsserver (Clients), mehrere Applikationsserver (Anfragebearbeiter) und einem Datenbankserver (die BW-Datenhaltung) festgeschrieben ist. Nach der einer Hardwaresystem zugeordneten Funktion kann ein Hardwaresystem als Teil eines bestimmten DW-Systems klassifiziert werden.

35

• Anbindungsmodus: Bei der virtuellen Anbindung einer Datenquelle handelt es sich in vielen Fällen um ein Teil des DW-Systems, da die Datenmenge wegen Leistungsgründen gering und die Metadatendefinitionen des Quellsystems eindeutig sein muss. Beispielsweise bindet der BW virtuelle Datenquellen durch RemoteCubes an, die eine BW-bekannte (InfoProvider) Struktur aufweisen müssen. Physisch abgespeicherte Daten können aber aus einer Datenquelle stammen, die bis zum jeweiligen Zeitpunkt kein fester Bestandteil der DW-Systemlandschaft war.

• Datenfragmentierung:

Handelt sich um eine verteilte DW-Struktur, dass auf mehrere große Tabellenstrukturen läuft, ist die Zuordnung der eine oder anderen Tabellenstruktur zu einer Abfrage-)Systemlandschaft möglicherweise von Bedeutung. Dabei kann man von der „horizontalen“ Fragmentierung von Attributswerten (bzw. Datensätzen, z.B. Gruppierung nach Produktname = „Bier“ & Produktgewicht = „<1 kg“) und die „vertikale“ Fragmentierung von Attributen selbst (z.B. Gruppierung „Produktname“ / „Produktklasse“) sprechen. ([Kemper2001], Kap. 16.3) Beide Fragmentierungsarten unterteilen Tabellen, die Fragmente müssen also gegebenenfalls zusammengeführt werden, also müssen Sie zwangsläufig als Teil derselben Data Mart/DW-System sein. Diese Fragmente kann man grob als der Größe von „Tabellenuntermengen“ bezeichnen. Tabellenübergeordnete Mengen beinhalten mehrere Tabellen (bzw. Analysestrukturen). Sie können auf verschiedene Orte (wie z. B. andere Festplatten, Netzwerke, DW-Instanzen mit virtueller Anbindung usw.) residieren. Der Unterschied liegt jedoch darin, dass sie gegebenenfalls nie zusammengeführt werden müssen. Man kann also mit Sicherheit von dem Fall ausgehen, dass zwei verschiedene Fragmente, die im selben DBMS residieren, -gegebenfalls- nie für eine Zusammenführung gedacht sind. Dies ist z. B. der Fall, wenn zwei Data Marts (oder disjunkte multidimensionale Strukturen) im selben physischen Hardwaresystem und Softwareinstallation gespeichert werden, aber die Anfragen verschiedener Nutzergruppen immer auf verschiedene Tabellenstrukturen treffen. Der SAP-BW unterstützt bisher keine verteilte DBMS, genauer gesagt: Es unterstützt keine verteilte Abfrageoperationen. Nur verteilte DBMS lassen Abfragen auf Fragmente der Größe von Tabellenuntermengen zu.

• Abfragezugriffsmodus: Die Hoheit über die eigenen Anfragen ist ein Entscheidungsfaktor bei der Zuordnung von DBMS Installationen zu DW-Landschaften. Akzeptiert dass

36

System Anfragen von anderen Datenbanken und werden die eigene Anfragen auf andere Systeme weitergeleitet, handelt es sicherlich um eine verteiltes Data Warehouse (und DBMS), womit alle „Abfragepartner“ als Teil eines Systems zu betrachten sind.

2.4 Organisation der BW-Architektur In diesem Abschnitt werden die Funktionen und Schnittstellen von BW untersucht. Zunächst wird der allgemeine Funktionsumfang von BW in einem Modellrahmen eingeordnet. Danach werden die Speicherstruktur- und Datenbereitstellungsfunktionen näher untersucht. Da der OLAP-Prozessor nicht unser Untersuchungsgegenstand ist, wird auf die Datenverwendungsfunktionalität nicht näher eingegangen..

2.4.1 Funktionsstruktur allgemein

Abbildung 2-10: Architekturaufbau von BW nach SAP

Quelle: [SAP]

37

Abbildung 2-11: Allgemeine Funktionale Architektur des BW

Quelle: In Anlehnung an ([McDonald2002], 37)

2.4.2 Datenhaltung

Abbildung 2-12: Speicherstrukturarchitektur von BW


38

Zentrale Verwaltungsobjekte in der Datenhaltungsschicht sind die Manager für InfoCubes, ODS-Objekte und Master Data, die grundsätzlich auf InfoObject-Zusammensetzungen aufbauen. Die Aggregatverwaltung erfolgt nur für InfoCubes. Sie wird durch den Aggregate Manager gewährleistet. Das Archiving Development Toolkit (ADK) und der Archiving Manager sorgen für die langfristige Speicherung der Altdaten auf Massenspeichermedien. Der ODS-BAPI stellt eine Schnittstelle für Data Mining- und Analysetools von Drittanbietern dar. Es handelt sich hierbei um eine Schnittstelle mit einen – im Vergleich zu auf den InfoCubes zugreifenden InfoSpokes – relativ direkten Zugriff zu den Inhalten eines ODS-Objektes. Andere Schnittstellen für Datenexport aus BW werden bei [McDonald2002] in der Analyse- und Zugriffsdienstleistungsschicht angegliedert. (vgl. XML/A und ODBO bei Abb. 2-10 mit Abb. 2-12)

2.4.3 Datenbereitstellung (Staging)

Abbildung 2-13: ETL-Services Architektur von BW


Der Staging Engine koordiniert den ETL-Prozess ab der Eingangsablage bei dem PSA bis zur Endgültigen Fortschreibung in Master Data Tabellen oder in einem

39

InfoProvider. Sie enthält die gesamte Datenflussdefinition ab DataSources und somit auch alle Transformationsdefinitionen (siehe Übertragungsregel und Trasformationsregel) Im DataSource Manager werden die elementarsten Dateneinheiten von Quellsystemen definiert. Sie verwaltet auch die gesamte Anwendungskomponentenhierarchie und die Anbindung von Daten ins BW. Die Schnittstellen liefern eine Einsicht in die Behandlung von lieferbaren Daten. SAP unterteilt die Datenquellen grob in drei Klassen:

• SAP Quellsysteme (haben wohlbekannte Metadaten) • Nicht-SAP-Quellsysteme (haben Metadaten, jedoch dem BW nicht

wohlbekannt) • Flatfiles (haben keine Metadaten)

Bei SAP Quellsystemen ist wegen der wohlbekannten Metadaten- und Extraktionsstruktur normalerweise kein API nötig. Die Metadaten werden im Quellsystem gespeichert und der Extraktionsprozess wird im Quellsystem installierten Extraktorprogrammen durchgeführt. Die Nicht-SAP-Systeme besitzen ihre proprietäre oder zumindest nicht SAP-konforme Datendefinitionen. Es ist aber z. B. möglich, die Metadaten im BW (als DataSource) so zu modellieren, dass diese genau die Definitionen im Quellsystem entsprechen. Diese DataSources können dann entweder, er direkten Datenbankanbindung per DB Connect oder per Extraktorprogrammen dem BW angebunden werden. Vorgefertigte Extraktionsmöglichkeiten werden von „Business Content“ - Metadatendefinitionen oder von Extraktorprogrammen von Drittherstellern bereitgestellt. Flatfiles besitzen überhaupt keine Metadatendefinition. Die Metadaten müssen auf jeden Fall manuell gepflegt werden. Es ist jedoch möglich, ein gewisser Grad von Automation zu erreichen, indem die Metadaten aus separat gepflegten Textdateien eingelesen werden.

2.5 Metadatenelemente in der BW-Architektur Eine Übersicht über die Metadatenelementen der BW ist in der Abbildung 2-14 zu sehen. Seit BW 3 werden aber die Daten durch InfoProvider und MultiProvider zu Queries geliefert. MultiProvider können mehrere InfoProvider zusammenfassen, die aus InfoCubes, ODS-Objekten und die flexible Zusammenstellung von InfoObjekten (die sogenannten InfoSets) bestehen.

40

Die im BW 3.0B eingeführte neue Exportdatenstruktur InfoSpokes sind die Hauptkomponente für die Bereitstellung von Daten an andere BW-Instanzen. InfoSpokes werden durch den Open Hub Service verwaltet (vgl. Abb. 2-10, rechts). InfoSpokes bestehen aus einem InfoProvider, ein DataSource, einfache Selektions- & Projektionskriterien für die Datenauswahl und einfache Zuordnungskriterien für die Zielstruktur im Zielsystem.

41

Abbildung 2-14: Das Metadatenmodell von BW 2.1

Quelle: ([TS-SapBw2002], 62)

42

2.5.1 Elementare Bausteine

2.5.1.1 InfoObjekte InfoObjekte stellen den elementaren Baustein für die Modellierung von Speicherstrukturen dar. Sie werden sowohl im Datenbereitstellungsschicht als auch im Datenhaltungsschicht verwendet. Ihre Hauptaufgabe liegt jedoch darin, die für die analyserelevanten Metadatenobjekte (InfoCube und ODS-Objekt) zu modellieren. Dieses Bereich wird manchmal auch lösungsabhängiger Bereich (wegen dem Bezug zur Abfragen) oder Bewegungsdatenbereich (wegen den häufiger anfallenden Updates im Vergleich zu Stammdatenbereich) genannt. Im einfachsten Sinne kann man ein InfoObjekt mit einer „Spaltendefinition“ für eine Tabelle in einer relationalen Datenbank vergleichen. Bei der Transformation der Daten dienen InfoObjekte als „Zielstrukturen“. Sie enthalten also die Definition dafür, wo und in welcher Form (Größe, Format) ein Datenatom aus dem Quellsystem in dem entsprechenden Datenziel landen wird.

Abbildung 2-15: InfoObject-Typen und Attributbeziehungen


Es existieren vier InfoObject Typen:

2.5.1.1.1 Merkmale

43

Merkmale sind die Bezugsgrößen, anhand denen die Kennzahlen in der Faktentabelle analysiert werden. Sie werden also hauptsächlich als die Dimensionsattributen im Extended-Star-Schema eingesetzt. Merkmale stellen die komplizierteste Infoobjektklasse dar. Sie können verschiedene Tabellenarten für sich führen (Namensraum /BIO/P*, Q*, X*, Y*), wodurch sie komplexere Tabellenstrukturen abbilden können. Das Snowflaking im BW-Datenmodell wird durch diesen Baustein ermöglicht. Merkmale haben einen eigenen Textwert, wodurch Sie identifiziert werden. Obwohl dieser Wert als Text gespeichert wird, ist sie eigentlich als Filterkriterium für Abfragen konzipiert.

Tabelle 2-3: Datentypen für Merkmale Datentyp Beschreibung Zulässige Länge CHAR Ziffern und Buchstaben Zeichenlänge 1-60 NUMC Nur Ziffern Zeichenlänge 1-60 DATS Datum Zeichenlänge 8 TIME Zeit Zeichenlänge 6

Quelle: ([Mehrwald2003], 60)

Merkmale können Stammdaten, Texte und externe Hierarchien haben. Stammdaten und Texte werden unter dem Begriff Master Data zusammengefasst. In Stammdaten können die Klammerung und Attribute definiert werden. Attribute haben Eigenschaften bezüglich den Zeitbezug und Navigierbarkeit. Merkmale können als Attribute von anderen Merkmalen vorkommen, wobei sie dann alle mögliche Eigenschaften eines Merkmals haben können. Referenzmerkmale haben eine Beziehung zu einem anderen Merkmal. Sie übernehmen dadurch alle Eigenschaften des referenzierten Merkmals, wobei die Eigenschaften nicht kopiert werden. Sie teilen dieselben Tabellen mit dem referenzierten Merkmal. Referenzmerkmale sind dann sinnvoll, wenn die Datenhaltung exakt dieselben Anforderungen an das Merkmal stellt, aber die betriebliche Semantik der Objekte unterschiedlich ist. Beispiel wären der Auftraggeber und Warenempfänger des Kunden, die dieselben Partnerinformationen aufweisen. ([Mehrwald2003], S82)

2.5.1.1.2 Kennzahlen Kennzahlen sind die Fakten des BW. Sie zeichnen sich hauptsächlich durch ihren unvorhersehbaren und aggregierbaren Charakter aus. Kennzahlen befinden sich hauptsächlich in der Faktentabelle, können jedoch auch in Dimensionstabellen vorkommen. Einige Kennzahlentypen können mit Einheiten versehen werden. Die

44

Kennzahlspeicherung in der Tabelle kann auch mit variablen Einheiten erfolgen (z. B. $ und €).

Tabelle 2-4: Datentypen von Kennzahlen Typ Mit Einheit Verwendungsbeschreibung Betrag Ja Währungsangaben Menge Ja Maßeinheiten (Gewicht, Länge usw.) Zahl Nein Gleitpunkt (vorzeichenbehaftet) Integer Nein Ganze Zahl mit Vorzeichen Datum Nein Datumsangabe für Verwendung im Faktentabelle Zeit Nein Zeitangabe für Verwendung im Faktentabelle

Quelle: Eigene Darstellung, in Anlehnung an ([Mehrwald2003], 68-69)

2.5.1.1.3 Zeitmerkmale Zeitmerkmale bilden den zeitlichen Bezugsrahmen für Datenanalysen. Sie sind vordefiniert und können nicht vom Benutzer geändert werden. Zeitmerkmale befinden sich immer von der BW vorgegebener Zeitdimension.

2.5.1.1.4 Einheiten Einheiten dienen als Zusatzinformationen für Beträge und Mengen. Somit sind sie erst in Verbindung mit einer Kennzahl sinnvoll. Sie liefern für verschiedene Konvertierungsroutinen (z. B. Dollar zu Euro) essentielle Datengrundlagen. Einheiten befinden sich immer von der BW vorgegebenen Einheitendimension.

Abbildung 2-16: Datenarten in BW

Quelle: Eigene Darstellung in Anlehnung an ([TS-SapBw2002], 45)

45

2.5.2 Stammdatenbereich Stammdaten repräsentieren den sogenannten „lösungsunabhängigen“ Bereich. Die Daten dieses Bereichs werden durch SID-Tabellen an den lösungsabhängigen Bereich gekoppelt (siehe Abb. 2-16 und Abb. 3-9). Grundidee des Stammdatenbereichs ist, dass ein gewisser Anteil von Daten im Warehouse sich nicht oder langsam ändert. Bei Bewegungsdaten wird die Historisierung oft explizit erwünscht. Bei Stammdaten kann die Historisierung der Daten größtenteils unterlassen werden.9 Zudem kann die Wiederverwendbarkeit der Strukturen durch einen abgekapselten lösungsunabhängigen Bereich zum Teil realisiert werden. Diese Verlängerung des Star-Schemas durch Master Data wird von einigen Autoren als Verwässerung des wichtigen Ziel des Vereinfachung des Datenmodells empfunden (vgl. [Kimball1998], 151). Insbesondere muss angemerkt werden, dass diese Struktur die relationelle Distanz der Daten zur Faktentabelle erhöht. Trotzdem sind andere der Ansicht, dass die Abwesendheit von Stammdaten bei einigen OLAP-tools zu mehr Problemen wie z. B. langsam entwickelnde Dimensionen, unbalancierte Modelle und irreguläre Hierarchien führen. ([McDonald2002], S127) Stammdaten sind Tabellenstrukturen, die als folgende Elemente eines Merkmal-InfoObjekts auftreten:

• Master Data o Stammdaten eines Merkmals

Klammerungsparameter Anzeigeattribute

• Zeitabhängige Anzeigeattribute • Zeitunabhängige Anzeigeattribute

Navigationsattribute • Zeitabhängige Navigationsattribute • Zeitunabhängige Navigationsattribute

o Texte Zeitabhängige Texte Zeitunabhängige Texte

• Externe Hierarchien o Nicht bebuchbare Knoten

Textknoten Fremde Merkmalsknoten

9 Man kann mit Hilfe von Zeitschlüsseln Attribute trotzdem historisieren.

46

o Bebuchbare Knoten

Abbildung 2-17: Stammdaten und Stammdatenoptionen in BW


Dabei kann es manchmal verwirrend sein, dass Attribute (=Stammdatenelemente) und Hierarchiestufen durch (Merkmal-) InfoObjekte und Texte definiert werden. Somit genügen nur diese zwei Datentypen, um die Tabellenstrukturen logisch abbilden zu können. Der InfoObject (Navigations-)Merkmal ist zugleich das Dachgebilde und das Baustein der Stammdatenmodellierung.

2.5.2.1 Master Data Die Klammerungsparameter sind zusätzliche Schlüssel, die dem Merkmal identifizierenden Textwert hinzugefügt werden. Dies ist generell dann sinnvoll, wenn dasselbe Merkmal zwei mal in verschiedenen Quellsystemen vorkommt aber dennoch eindeutig identifiziert werden soll. Beispiel dazu wäre eine Kunde, die in zwei Buchungskreisen10 im selben Quellsystem oder in zwei verschiedenen Mandanten11 vorkommt. 10 Buchungskreise sind selbständig bilanzierende Organisationseinheiten in SAP-Terminologie. Beispiel wären bilanzpflichtige Unternehmen X und Y, die denselben Konzern zugehören und im selben Mandanten abgebildet werden.

47

Anzeigeattribute speichern einen InfoObject zur weiteren Beschreibung des Merkmals. Navigationsattribute sind die einzigen Attributtypen, die den sogenannten drill-through erlauben. Der drill-down ist auch möglich, weil durch die Verschachtelung von Navigationsattributen eine implizite Hierarchie entsteht. Die Zeitabhängigkeit von Master Data wird mit Hilfe eines zusätzlichen Zeitschlüssels zum Merkmalsschlüssel implementiert.

2.5.2.2 Texte Texte werden für deskriptive Informationen genutzt. Sie können zeitabhängig sein, diese Einstellung ist aber in der Praxis selten notwendig. Die Texte besitzen einen Sprachschlüssel.

2.5.2.3 Hierarchien Hierarchien werden auf ABAP-Dictionary-Tabellen abgebildet. Diese Abbildung entspricht die herkömmliche Abbildung von Baumstrukturen auf Tabellenstrukturen durch Knoten und Vater/Sohn – Beziehungen. Der Vorteil der externen Hierarchien liegt darin, dass sie ohne Änderung der Modellstruktur (Dimension- bzw. InfoObjektdefinitionen) sehr flexible Hierarchien abbilden können. Diese Hierarchie kann zur Aggragatenberechnung oder zur Navigation per drill-down herangezogen werden. Der Hierarchiebaum kann unbalanciert sein. Die nicht-bebuchbaren funktionieren dabei als Hülsen für die bebuchbaren Knoten. Sie werden entweder einfach mit einem beliebigen Text beschrieben oder verwenden den Text eines fremden (referenzierten) InfoObjekts. Die bebuchbaren Knoten enthalten Merkmale. Es ist auch möglich mit einem Hierarchieintervall viele Merkmale nach ihren Merkmalswerten gleichzeitig und automatisch einer Hierarchiestufe zuzuordnen. Somit kann z. B. nach Produktnummer die ganze Produktgruppe über Nummernkreisen in eine Hierarchiestufe eingeordnet werden. In der Beispielabbildung wären wir in der Lage, „n“ Handy-Modelle mit einem Intervall der Sparte Handy zuzuordnen.

11 Ein Mandant ist in SAP-Terminologie eine SAP R/3 Installation. Beispiel für zwei Mandanten wäre ein Test und ein Produktivsystem. (engl. Begriff: Client). Aus BW-Sicht sind Mandanten separate Quellsysteme.

48

Abbildung 2-18: Beispiel für externe Hierarchien


Hierarchien können zeit- und versionsabhängig sein.

2.5.3 Speicherstrukturen Bei den folgenden „Speicherstrukturen“ handelt es sich um Metadatenobjekte, die andere Tabellenstrukturen zusammenfassen. Alle sind InfoProvider. Somit stellen Sie den „Zielspeicherobjekt“ für Abfragedefinitionen dar.

2.5.3.1 InfoCube InfoCubes sind die multidimensionalen Strukturen, auf dem die meisten Analysen basieren. Ein InfoCube besteht aus einer Faktentabelle, die Kennzeichen beherbergt; und aus Dimensionstabellen, die Merkmale gruppieren. Die Info-Bezeichnung ist nicht ganz sachgemäß, da eigentlich Daten abgebildet werden. SAP zieht die Bezeichnung „Info“ über „Data“ vor, je näher die Metadatenobjekte zur Analyseschicht liegen. (bzw. je weiter sie vom ETL-Schicht entfernt sind) Die „Cube“ Bezeichnung folgt dem in Data Warehousing Kreisen übliche Taxonomie, eigentlich kann ein InfoCube nicht nur 3, sondern bis 16 Dimensionen aufnehmen. 3 Dimensionen (Zeit, Einheit, Package) sind vordefiniert, 13 sind frei wählbar. Die Anzahl der semantisch abbildbaren Dimensionen liegt aber eigentlich weit darüber, da jede Dimension Hunderte von Merkmale aufnehmen kann.

49

Die Dimensionsdefinitionen folgen dem BW-eigene „erweitertes Sternenschema“, was die Vorzüge der Star Schema beibehalten und erweitern soll. Transaktionale InfoCubes sind eine besondere Form von InfoCube, die grundsätzlich nur mit SAP SEM verwendet werden. Sie sind zur Überschreibung der enthaltenen Daten konzipiert. Die Überschreibung der Daen ist für die Simulation von Planszenarien sinvoll. Die am häufigsten angesetzte InfoCube-Klasse, BasisCubes, sehen einen solchen Eingriff nur für Korrekturzwecken vor. Dazu wird die Package Dimension verwendet, die das Aktualisieren von InfoCubes verfolgt. Die letzte InfoCube-Klasse ist der RemoteCube. RemoteCubes enthalten nur eine Metadatendefinition. Sie speichern keine Daten. Daten werden erst zur Laufzeit vom Quellsystem angefordert.

2.5.3.2 ODS-Object ODS-Objekte sind flache (nichtmultidimensionale, denormalisierte) Datencontainer, die als Datenziel für die flüchtigeren Bewegungsdaten konzipiert wurden. Sie werden aufgrund ihrer einfacheren Struktur und atomarer Datenspeicherung oft als vorgelagerte Datenstrukturen für InfoCubes im Rahmen des multi-level-Staging angewendet. Die Qualitätssicherung der Daten und die Datenintegration sind einige ihrer Hauptaufgaben. In größerer Anzahl stellen sie die besten Datenziele für die Modellierung der Operational Data Store dar. Es soll jedoch angemerkt werden, dass von Inmon und Kimball generell empfohlene Star-join Strukturen für den ODS ([Kimball1998], 340) für ODS-Objekte im BW nicht verwendet wird. ODS-Objekte können auch zur Analysezwecken herangezogen werden. Aufgrund ihrer Struktur werden Sie als häufig Analysewerkzeug für operatives Reporting und stichtagsbezogene Aufgaben wie Auftragsverfolgung eingesetzt. ([Mehrwald2003], 102) ODS-Objekte können flüchtig formuliert werden (transactional ODS-Object), d.h. sie können zeitnah zum transaktionalen Systeme aktualisiert werden. Dies erfordert eine exakte Transaktionsverarbeitung, sodass die Zugangsschlüssel nicht von SID-Schlüsseln, sondern wie bei transaktionalen Systemen aus Primärschlüsselkombi-nationen von Merkmalen bestehen ([Mehrwald2003], 103). Außer Schlüsselfelder kann es auch Datenfelder geben. Dadurch ist es auch möglich normalisierte Tabellenstrukturen durch ODS-Objekte zu modellieren.

50

ODS Objekte kommen in zwei Formen, transaktional und nicht-transaktional. ([McDonald2002], S 72)

2.5.3.3 InfoSet Bei InfoSets handelt es sich um ein Metadaten-Objekt ohne eigene Datenhaltung. Infosets stellen somit eine Abfragedefinition dar, mit deren Hilfe beliebige InfoObjects oder ODS-Objekte abgelesen werden können. ([McDonald2002], 68) Sie eignen sich somit sehr gut für ad-hoc Analysen, sind aber nicht sehr performant und sonderlich flexibel bei der Analyse, da Sie keine Dimensionsdefinitionen besitzen ([Mehrwald2003], 104).

2.5.4 Analysestrukturen

2.5.4.1 MultiProvider InfoCubes, ODS Objekte und InfoSets gehören zu der Klasse InfoProvider. Somit wird eine zusätzliche Abstraktionsstufe für die Analyse geschaffen. Queries werden auf InfoProvider ausgeführt. MultiProvider erlauben die Zusammenfassung von mehreren InfoProvidern. Es gibt eine Reihe von Gründen, dass die Zusammenführung von InfoProviderinhalten im Rahmen der Analyse erfordert. ([Mehrwald2003], 105):

• Mehrere Infoprovider bilden die Datengrundlage für eine betriebswirtschaftlich abgeschlossene Datensammlung (z. B. ein Data Mart). Ziel ist eine Analyse auf eine Zusammenfassung mehrerer Teilstrukturen abzubilden.

• Verteilte Strukturen aus mehreren Quellsystemen sollen in einem gemeinsamen Kontext dargestellt werden.

• Das Reporting soll von der physischen Datengrundlage abstrahiert werden. Es ist z. B. möglich, ohne das Wissen der Querydefinition den zugrundeliegenden InfoProvider auszutauschen.

• Durch Partitionierung der InfoProvider und Zusammenfassung zur Laufzeit unter einem Multiprovider wird eine Verbesserung der Abfrageleistung angestrebt.

2.5.4.2 Abfragedefinitionen (Queries) Abfragen sind das Zentrale Analyseinstrument. Die Endbenutzer verwenden grundsätzlich nur die Queries. Queries laufen auf InfoProvider.

51

2.5.4.3 InfoSpokes InfoSpokes sind die zentralen Strukturelemente, womit die Daten an andere BW-Instanzen weitergegeben werden. Sie sind essenziell für den Aufbau einer Hub-And-Spoke-Architektur. InfoSpokes sind in den „Open Hub Service“ einzuordnen. ([McDonald2002], 94)

2.5.5 ETL Strukturen

2.5.5.1 DataSource Ein DataSource beschreibt jeweils eine betriebswirtschaftliche Zusammenfassung von Stamm- oder Bewegungsdaten aus einem Quellsystem. Ein DataSource repräsentiert eine technische Dateneinheit, die eine quellsystemabhängige Formatierung besitzt. Die definierbaren Datentypen bei einem DataSource sind also deutlich höher als bei einem InfoObject. Diese Tatsache berücksichtigt die vielfältigen Datenformate, die man in einem transaktionalen Quellsystem finden kann. DataSource-Typen sind

• Bewegungsdaten DataSource • Stammdaten DataSource für Attribute • Stammdaten DataSource für Texte • Stammdaten DataSource für Hierarchien

Die quellsystemabhängige DataSources werden im BW logisch in einer Anwendungskomponentenhierarchie zusammengefasst.

2.5.5.2 Quellsysteme Quellsysteme sind physische oder logische Systeme, die Daten an BW liefern. ([McDonald2002], 60) Quellsystemtypen sind

• BW-Systeme • Systeme aus der mySAP Produktpalette • Andere transaktionale Datenquellen (per DB-Connect oder Staging BAPI) • Flatfiles (können in logischen Filesystemen organisiert werden) • XML Datenflüsse

Bei transaktionalen Systemen werden DataSources per einem „Extractor“-Programm mit Daten gefüllt. Diese werden mittels der Transferstruktur in das BW übertragen. Die

52

Transferstruktur zeigt die DataSources sowohl im Quellsystem al auch im BW. Bei dieser Übertragung kann man die erforderliche Daten auswählen. Bitte beachten Sie das Extraktoren in der Regel im Quellsystem installiert sein müssen. Die Datenanbindung an ein BW-System braucht kein Extraktor. Flatfiles haben i.d.R. keine separat abgespeicherte Metadaten. (Strukturinformationen) Aus diesem Grund existieren für Sie keine Extraktoren, ihre Metadaten müssen manuell definiert werden.

2.5.5.3 InfoSource Ein InfoSource ist eine quellsystemunabhängige Zusammenfassung von logisch zusammengehörenden Informationen. Seine Aufgaben sind [Mehrwald2003]:

• Die Zielstruktur der Homogenisierung zu beschreiben • Zusammenfassung der ihm zugeordneten Übertragungsregeln • Beschreibung der Ladevorgänge

53

3 Datenmodelle für OLAP

3.1 Datenmodelle als Bestandteil der Architektur Datenmodelle beschreiben die Strukturen, womit die Daten in Data Warehouses abgebildet werden. Die Zielsetzung der Datenanalyse in Warehouses (OLAP) wurde in der Tabelle 1-1 dargestellt. Entsprechend diesen Zielen müssen in Modelle auch bestimmte Zielkriterien verfolgen. Die grundlegenden Ziele sind:

• Einfache Schemas • Saubere, konsistente und richtige Daten • Schnelle Abfragebearbeitung • Qualitative Datenbereitstellung in berechenbaren Zeitfenstern

3.1.1 Rahmenbedingungen zu relational-multidimensionalen Strukturen

Es gibt eine Reihe von Kriterien, die eine Wirkung auf die Abbildung der Tabellenstrukturen haben. Diese sind z. B.:

• Auswahl der betriebswirtschaftlich relevanten Daten • Gruppierung dieser Daten in Teilbereiche, d.h. Abgrenzung von Data Marts

durch saubere Definition von Analysezielen • Erwartete Instandhaltung und Modifikationen (erwartete Flexibilitätsstufe des

Schemas) Traditionelle normalisierte Datenschemata verursachen insbesondere Probleme mit der großen Anzahl von Relationen und die große relationelle Distanz12 zwischen Tabellen. Abfragen führen zu vielen „cascading joins“, d. h. die Tabellen werden zunächst mit den Benachbarten durch die geeigneten (Fremd-) Schlüsselpaare verbunden, um die zweitnächste Tabelle zu erreichen.

12 z.B.: eine relationelle Distanz von 3 bedeutet 3 Tabellenzusammenführungen (joins) für die Zusammensetzung der Tabellen zur Laufzeit.

54

Diese Probleme haben zu der Entwicklung einer Reihe von vereinfachten Datenschemata geführt. Die Auswahl oder Kombination von richtigen Schemas ist der erste Meilenstein bei der Definition von Analyseanforderungen.

3.1.2 Ebenen der Datenmodellierung Data Warehouse Entwicklungen brauchen einen datenorientierten Ansatz zur Lösung der Entwicklungsaufgaben. Datenmodelle stellen somit das wichtigste Entwicklungswerkzeug. Beim Datenbankentwurf von OLTP-Systemen hat sich die Unterscheidung in die Entwurfsebenen des konzeptuellen (semantischen), logischen und physischen Entwurfs mit den korrespondierenden Entwurfsergebnissen konzeptuelles, logisches und physisches Schema durchgesetzt. Diese Hierarhisierung kann auch bei Data Warehouses angewendet werden. ([TS-SapBw2002], 22) Somit können Informationssysteme nach dem Informationssystem-Beschreibungsebenen von Fachkonzept, DV-Konzept und Implementierung analysiert werden ([Scheer1998], 14ff.).

Tabelle 3-1 :Die Entwurfsebenen und korrespondierende Modellierungsmethoden Entwurfsebene Entwurfsmethoden Konzeptueller (semantischer) Entwurf

Semantisches Data Warehouse Modell Multidimensionales ERM Dimensional Fact Modeling ADAPT13

Logischer Entwurf Starschema Snowflake Schema Partial Snowflake Schema Erweitertes SAP-Starschema Galaxy Schema Fact / Constellation Schema

Physischer Entwurf Speicherungsstrukturen Zugriffsmechanismen Datenbanktuning

Quelle: ([TS-SapBw2002], 22)

Zur Zeit gibt es aber keine etablierte Modellierungsmethode für multidimensionale Strukturen. Für semantische Modellierungszwecke wird in dieser Arbeit die Darstellungsmethoden des MERMs (multidimensional Entity Relationship Modelling) verwendet. ([Totok2000], 192f)

13 ADAPT: Application Design for Analytical Processing Technologies

55

3.2 Multidimensionale Strukturen Multidimensionale Strukturen sind die zentrale Datenstrukturen in On-Line Analytical Processing (OLAP). Sie werden im BW hauptsächlich durch InfoCubes implementiert. Die Analyse von multidimensionalen Daten erfolgt mittels Dimensionen. Im InfoCube enthält jede Dimension eine Menge von Merkmalen. Jedes Merkmal kann weiterhin Attribute aufweisen. Diese entsprechen den Dimensionsattributen und Beschreibungsattributen im traditionellen Star-Schema. Eine gängige Darstellungsweise von dimensionalen Strukturen ist die 3-dimensionale Würfel. In der Praxis enthalten viele Datenstrukturen viel mehr als drei Dimensionen und sollten somit als „Hypercubes“ bezeichnet werden. Es gibt keine semantische Begrenzung zur Anzahl von Dimensionen, eine Darstellung am 3-dimensionalen Datenwürfel hat sich jedoch aus Visualisierungsgründen als sinnvoll erwiesen.

Abbildung 3-1: Datenwürfel mit 3 Dimensionen


Dimensionen dienen hauptsächlich als Filterkriterien für die Ermittlung der erwünschten Fakten. Die Filterkriterien stellen Wertbeschränkungen von Merkmalswerten dar. Dimensionsattribute (Merkmale) werden oft innerhalb einer Dimension hierarchisch gestaffelt. Eine Art der Abfrageausführung ist die Änderung der Hierarchiestufe bei gleichzeitiger Beibehaltung anderer Filterkriterien auf Dimensionsattributen. Die Navigation in Datenwürfeln folgendermaßen bezeichnet:

56

Tabelle 3-2: Operationen auf einen Datenwürfel Operation Wirkung Roll-up Wechsel zur oberen Hierarchiestufe Drill-down Wechsel zur detaillierteren Hierarchiestufe Slicing Beschränkung von eine der Dimensionen auf genau einem Merkmalswert Dicing Auswahl einer Position in einer Dimension ( Reduktion auf Teilmenge)


Hierarchien stellen einen wichtigen organisatorischen Werkzeug für die Analyse dar. In der Regel ergeben sich Hierarchien implizit aus den gespeicherten Dimensionsattributen. Im Quellsystem weisen höhergestellte Hierarchiestufen eine 1:n Relation zu ihren Gliedern auf. Beispiel wäre die Relation zwischen eine Produktgruppe und den Produkten. Viele DW-Hersteller bieten jedoch auch Möglichkeiten zur expliziten Definition von Hierarchien. So bietet BW die externe Hierarchien zur expliziten Hierarchiemodellierung.

3.2.1 ROLAP und MOLAP Die Dimensionalen Strukturen dienen zunächst zur Beschreibung der Datenorganisation. Bei der physischen Speicherungsstruktur in der Datenbank haben sich zwei datenorganisatorische Ansätze entwickelt. Die Multidimensionale Datenbanken (MDD) bilden die konzeptuellen Dimensionsstrukturen (Abb. 3.1) auch in ihrer physischen Speicherstruktur ab. Eine n-dimensionale Struktur wird grundsätzlich als eine n-dimensionale, komprimierte Felder (Arrays) abgebildet. Die Datenstrukturen von relationalen Datenbanken bauen dagegen auf die bewährten relational-tabellarische Datenstrukturen auf. Sie bieten verschiedene fortschrittliche Technologien zur Verwirklichung von logischen Schemata. Das erweiterte Starschema (extended-star model) von BW wird in ABAP-Dictionary Tabellen in implementierungsnaher Form festgehalten und auf dem darunterliegenden relationellen Datenbanksystem abgebildet. Bei der Definition von InfoCubes ist das erweiterte Starschema nicht direkt sichtbar. Erst eine Untersuchung der Tabellenstrukturen im ABAP-Dictionary gewährt Einsicht in den Aufbau des erweiterten Starschemas.

3.2.2 Von normalisierter Struktur zum Sternenschema Der betriebliche Ausgangspunkt bei der Transformation der logischen Schemas ist von besonderer Bedeutung. Die im Quellsystem ansässige Daten weisen oft eine normalisierte Struktur auf. Um die Daten in normalisierten Schemas in einem Data

57

Warehouse unterbringen zu können, müssen zunächst nach der Ermittlung der Analyseanforderungen neue Star-Schemas erstellt werden.

Abbildung 3-2: Mittelkomplexes ERM Beispiel für ein Unternehmen

Quelle: ([Kimball1998], 143)

Ein Entity Relationship Modell lässt sich in grundsätzlich in mehrere Star-Schemas abbilden. Jeder betriebswirtschaftlich sinnvolle Analysebereich kann dabei die eigene Faktentabelle und korrespondierende Dimensionen besitzen. ([Kimball1998],144) In Abbildung 3.2 wird beispielhaft ein ERM von einem Unternehmen dargestellt, das Produkte herstellt, an Handelsketten weiterverkauft und die Verkäufe in der eigenen Datenbank erfasst. Das erklärte Ziel ist die Analyse von Verkäufen. Die Abbildung 3-3 verfügt über einen Ausschnitt dieses ERMs. Als „starke Entität“ dieser Abbildung wir der „Point of Sale Sales Process“ identifiziert, da Sie die meisten Relationen zu andere Entitäten aufweist. Die Abbildung 3-3 stellt ein analysegerechtes Star Schema für die Abbildung 3-2 dar. Sie listet zudem – mögliche – Attributen aus

58

dem ERM als Dimensionsattributen auf. Es gibt keine Relationen zwischen Dimensionstabellen – eine Anforderung des Starschemas.

Abbildung 3-3 Relationen des Verkaufsprozesses ohne Attribute


Abbildung 3-4: Starschema zum Verkaufsprozess

Quelle: ([Kimball1998], 145)

59

3.3 Logische Datenschemata für multidimensionale Strukturen

3.3.1 Flache Strukturen Flache Strukturen stellen die Ausgangsbasis für verschiedene multidimensionale Strukturen dar. Bei flachen Strukturen handelt es sich um denormalisierte Strukturen, die den Gesamtdatenbestand vereinfacht abbilden. Flachen Strukturen sind wesentlich einfacher als transaktionale Strukturen aufgebaut. Daten können durch Verschmelzung von zwei Tabellen über einem Schlüssel zusammengefasst werden. Die beiden Datensätze verschmelzen dadurch zu einer dritten Entität. Verschmelzt man alle Tabellen, erhält man die flache Struktur. Die normalisierte Struktur erfordert also –gegenüber der flachen Struktur - eine zusätzliche Interpretationsschritt (der Join) bei Abfragen. Der Datenbestand (Anzahl der Datensätze und Attributen in der Tabelle) in normalisierten Strukturen ist aber wesentlich kleiner.

Abbildung 3-5: Flache Tabellenstruktur Quelle: Eigene Darstellung

Eigenschaften von flachen Strukturen ([Mehrwald2003], 51-52):

• Die Aggregation besonders einfach aus, da sämtliche Merkmale als Tabellenschlüssel abgelegt werden. Diese Tatsache verursacht aber auch Performance-Nachteile bei RDBMS.

• Die Anzahl der Felder in einer Tabelle wird in vielen Herstellersystemen begrenzt. Möglicherweise können nicht alle gewünschte Attributen in einer Tabelle untergebracht werden.

• Nur eine historisierte Darstellung der Daten ist möglich, da die Überschreibung alter Datensätze zu Redundanzen oder Fehlinformationen führen kann.

• Die gesamte Tabelle muss neu aufgebaut werden, wenn das Datenmodell verändert wird.

3.3.2 Starschema Das Starschema stellt die Grundform der im Analysebereich angewendeten Datenstrukturen dar. Es besteht aus einer zentralen Faktentabelle und damit

60

verbundenen Dimensionstabellen. Um die Relationen zwischen der Faktentabelle und Dimensionen möglichst quellsystemunabhängig und performant zu gestalten, wird die Anwendung von künstlichen Schlüsseln (vgl. Kap. 2.2.3.6.) der Dimensionstabellen als die Primärschlüsselkombination der Faktentabelle empfohlen. ([Kimball1998], 191) In BW werden Surrogate Keys in Form von SIDs mit 32-Bit Integerzahlen implementiert.

Tabelle 3-3: Schemabegriffe bei BW Klassisches Starschema Erweitertes Sternenschema (BW) Fakt Kennzahl Dimensionsattribut Merkmal Beschreibendes Attribut Attribut, Text --- Externe Hierarchien Dimensionstabellen (stammdatenenthaltend)

Dimensionstabellen (keine Stammdaten)

Dimension= Dimensionstabelle Dimension= Dimensionstabelle + SID Tabelle + Stammdatentabelle

Das Starschema ist eine der realisierbaren Strukturen des erweiterten Sternenschemas.14 Für die Implementierung in BW werden aus Leistungsgründen folgende Regeln für die Relationen vorgeschlagen15 ([Mehrwald2003], 146):

• Eine Dimension(-sschlüssel) soll eine 1:n-Beziehung zu der Faktentabelle haben • Eine Dimension kann Merkmale (Attribute im Sternenschema) haben, die eine

1:n-Relation aufweisen. Merkmale die in einer m:n-Relation stehen könnten, sollen in andere Dimensionen ausgelagert werden

• Möglichst viele Dimensionen sollten Line-Item-Dimensionen sein

14 Dabei entspricht die physische Implementierung keinesfalls dem Starschema, jedoch kann man ohne Snowflaking (im Sinne von Auslagerung der analyserelevanten Merkmalen in andere Tabellen) auskommen. Der Dimensionsbegriff im BW hat eher eine „logische“ Bedeutung, wird aber auch für Tabellen verwendet. 15 Die Regeln sind auch für allgemeine Starschemas sinnvoll. Es gibt aber kein Begriff für Line-Item-Dimensionen im Sternenschema-Kontext, da alle Dimensionen im Sternenschema sowieso Line-Item-Dimensionen sind.

61

Abbildung 3-6: Starschema Quelle: Eigene Darstellung

3.3.3 Snowflake-Schema Im Snowflake-Schema werden Felder mit niedriger Kardinalität von der zugehörigen Dimensionstabelle entfernt und in neuen Tabellen nach kontextueller Zusammengehörigkeit wieder gruppiert. Die neuen Tabellen werden durch neue künstliche Schlüsselpaare in Relation mit den Dimensionen gebracht. ([Kimball1998], 170) In gewisser Hinsicht kann man von „Normalisierung der Dimensionen“ reden.

3.3.3.1 Kontext für Snowflake-Schema-Verwendung Die ausgelagerten Tabellen werden oft für die Verfolgung von aktuellen Daten im operativen Kontext verwendet. Eine dieser Anwendungsgebieten ist Status Tracking. Bei Status Tracking wird der Statusfeld eines Objektes (Produktlieferung-, Produktbearbeitung-, Prozessstatus usw.) mehrfach überschrieben. Die ausgelagerte Tabelle verwenden wir also ausschließlich für die Verfolgung des aktuellen Attributwertes. Ein anderer Kontext für die Verwendung dieser Tabellen sind Stammdaten. Stammdaten sind per Definition solche Daten, die eine geringere Veränderlichkeit gegenüber die (historisierbaren) Bewegungsdaten der Faktentabelle aufweisen. Für einen wesentlichen Speicherplatzgewinn müssen sie jedoch einen beträchtlichen Umfang haben. BW verfolgt einen ähnlichen Ansatz, indem durch das Konzept „Master Data“ die Wiederverwendung von Tabellen gefördert wird.

62

Abbildung 3-7: Snowflake-Schema


3.3.3.2 Abfrageleistungsoptimierung bei Snowflaking Ein erklärtes Ziel der von snowflaking war die Leistungsoptimierung. Ziel dieser Optimierung ist in erster Instanz die Beschleunigung der Abfragen durch die Restriktion auf Kategorien.16 Weil die neuen Tabellen wenige Datensätze haben, die wenige Feldtypen aufweisen, sind sie bestens als Filterkriterium für Dimensionsdaten geeignet. Jede Schlüsselkombination (d.h. Datensatz) in der ausgelagerten Tabelle entspricht ein Filterkriterium. Dabei muss jedoch angemerkt werden, dass der Anschluss an die Faktentabelle über eine Dimensionstabelle erfolgt. Dies verursacht eine zusätzliche join-Operation und kann dadurch für die Abfrageleistung negative Auswirkungen haben. Letztendlich haben die Bitmap-Indizes durch Kombination von mehreren Suchkriterien in einer Schüssel ein wesentlich flexibleres Instrument geschafft, um in Datenfeldern mit niedrigere Kardinalität zu suchen. Hinsichtlich der Abfrageleistung bietet also das Snowflake-Schema gegenüber das Sternenschema keine große Vorteile.

3.3.3.3 Speicherplatzeffizienz bei Snowflaking Hinsichtlich der Speichereffizienz bietet das Snowflaking eher wenige Vorteile. Ein DW ist normalerweise einer der größten Datenbankformen. Der größte Speicherplatz wird normalerweise von den Faktentabellen beansprucht ([Kimball1998], 172). Der 16 Dimensionsattribute, die zu Snowflake-Tabellen ausgelagert werden.

63

Speicherlatzgewinn durch die nichtredundante Speicherung von ein Paar Kategorien (oft Textattribute) ist oft verhältnismäßig gering. Dazu können wir die folgenden Berechnungen aufstellen: F: Physische Größe eines ausgelagerten Datenfeldes für einen Datensatz Fi: Physische Gesamtgröße des ausgelagerten Datensamtzes S: Größe der Join-Schlüssel für ausgelagertes Schlüsselpaar R: Aufwand für die Bildung für Relationen zwischen Tabellen im System (Verweise) n: Anzahl der Datensätze in der Dimensionstabelle m: Anzahl der Datensätze in der ausgelagerten Tabelle Die Berechnung führen wir schrittweise durch: Größe der ausgelagerten Tabelle:

+∗ ∑

i

iFSm1

Verkleinerung der Dimensionstabelle:

−∗ ∑ SFn

i

i )(1

Die Gesamtformel lautet also:

RFSmSFnatzgewinnSpeicherpli

i

i

i −

+∗−

−∗= ∑∑

11)(

Bemerkungen

• Wir haben angenommen, dass m (im Verhältnis zu n) eine niedrige Kardinalität besitzt, da m Datensätze als Filter für n Datensätze dienen sollen.

• S wird bei Verwendung von künstlichen Schlüsseln gegenüber Fi vergleichsweise gering ausfallen.

• Ein Join-Schlüssel kommt in beiden Tabellen vor. • R ist von der jeweils eingesetzten Datenbank abhängig, da physische Verweise

gepflegt werden müssen. Sie soll unter diesen Umständen vernachlässigt werden.

Nach der Umformung stellt sich heraus, dass der maximale Speicherplatzgewinn mit

∗ ∑

i

iFn1

approximiert werden kann. Falls n wesentlich kleiner als die Anzahl der

64

Datensätze in der Faktentabelle ist, macht es also offensichtlich kein Sinn, aus Speicherplatzgründen eine ausgelagerte Tabelle zu erstellen. Dennoch kann durch die Wiederverwendung der ausgelagerten Tabellen durch mehrere Dimensionen einen wesentlichen Nutzen entstehen, falls Fi wesentlich größer als die Gesamtfeldgröße der Fakten ausfällt.

3.3.4 Galaxy-Schema Bei Galaxy-Schema handelt es sich um mehrere unabhängige Faktentabellen, die zum Teil die gleichen Dimensionen verwenden. Solche Dimensionen heißen einheitliche Dimensionen, da ihre Definition in verschiedenen Nutzungskontexten gültig sein soll. Wie bei dem Sternenschema sollen keine Beziehungen zwischen zwei Faktentabellen bestehen. Das Galaxy-Schema wird auch Multi-Faktentabellen-Schema genannt. ([Behme1996], 227ff)

Abbildung 3-8: Galaxy-Schema


3.3.5 Zusammenfassung von Schemaeigenschaften Hier soll eine Übersicht der Datenschemata bezüglich den verschiedenen Eigenschaften angeboten werden. Zuvor gehen wir aber kurz auf die Beurteilungskriterien ein. Sie können folgendermaßen aufgelistet werden:

• Performance (z.B. Abfragegeschwindigkeit, Zeitverbrauch im Stagingdurchlauf, Speicherplatzeffizienz)

• Flexibilität (z. B. Erweiterbarkeit des Modells, Aufwand zur Wiederaufbau bei Tabellenänderungen, Navigationsmöglichkeiten)

• Zeitliche Modellierungsmöglichkeiten

65

Mit den zeitlichen Modellierungsmöglichkeiten bei langsamen Dimensionsveränderungen (slowly changing dimensions) meint Kimball die Änderung der Dimensionsattributen bei konstant bleibenden Schlüsselwerten. Die Modellierungsmöglichkeiten listet er folgendermaßen auf ([Kimball1998], 180):

1. Überschreiben des Datensatzes (in einer Dimension) mit den neuen Werten, wodurch die Historisierung verloren geht.

2. Erstellung eines neuen Datensatzes in der Dimensionstabelle mit einem neuen künstlichen Schlüsselfeld.

3. Erstellung eines neuen Datenfeldes „alt“ in demselben Datensatz, um den letzten Wert vor der Änderung speichern zu können.

Die erste Variante wird die „aktuelle“, die zweite die „historisierte“ Darstellung genannt. Die dritte Variante wird in einer verbesserten Darstellungsform in BW implementiert: Diese Variante heißt „Stichtagsdarstellung“ und kann dazu angewendet werden, um den genauen Wert eines Dimensionsattributs (Merkmals) zu einem bestimmten Zeitpunkt in der Vergangenheit zu ermitteln.

Tabelle 3-4: Vergleich von Datenschemata Transaktional Flach Star Snowflake Erw. Star Performance Schlecht Gut Sehr gut Sehr gut ? Komplexität Hoch Gering Mittel Hoch Sehr hoch Historisiert Nein Ja Ja Ja Ja Aktuell Ja Nein Nein Ja Ja Stichtag Nein Nein Nein Nein Ja

Quelle: Eigene Darstellung, in Anlehnung an ([Mehrwald2003], 55)

3.4 Physisches Datenschema bei BW Logische Datenstrukturen werden bei SAP entweder per MOLAP-Ablage auf dem MS-Analysis-Server oder als ROLAP Strukturen auf dem verwendeten RDBMS (z. B. Oracle oder SAP DB) abgelegt. Die Tabellen werden nicht direkt aus InfoCubes erstellt, sondern werden zunächst in ABAP-Dictionary Tabellen geschrieben. Durch die zusätzliche Indirektionsstufe hat SAP die Schemaimplementation bei BW von der physischen DBMS-Implementation abstrahiert. Das Speicherschema der ABAP-Dictionary Tabellen heißt erweitertes Starschema.

66

3.4.1 Erweitertes Starschema Das erweiterte Starschema ist die fest vorgeschriebene physische Implementation von InfoCubes in BW. Star-, Snowflake-, Galaxy- Schemas sind alle durch dieses Schema modellierbar. Allerdings besteht wegen der Abkapselung der Daten in Stamm- und Bewegungsdaten (Lösungsunabhängiger bzw. abhängiger Bereich) eine Distanz über mindestens drei Relationen17 zu eigentlichen Daten. Ohne die Indirektion der Stammdaten würde dieses Schema grob zu einer komplizierten Implementierung von Snowflake-Schema entsprechen.18 Bei einer solchen Snowflake-Interpretation entspricht jedoch jedes Merkmal zwanghaft eine Snowflake-Tabelle (SID-Tabellen im BW). Somit wird die Snowflake-Struktur als „physische Modellierungsvorgabe“ interpretiert! Die Faktentabelle wird zu einer Dimensionstabelle verbunden. Die Dimensionstabelle enthält eine Gruppierung von Merkmalen, die in Form von den jeweiligen Stammdatenidentifikationsschlüsseln (SID), die auf konkrete Datensätze verweisen. Die Auswahl an SID-Einträge wird dann zu einer SID-Tabelle verbunden, dass alle SID-Einträge für ein Merkmal bestimmtes Merkmal enthält. Nicht alle SID-Einträge der SID-Tabellen müssen in einer bestimmten DIM-Tabelle vorkommen, sie können zum Beispiel in anderen Dimensionen bzw. InfoProvider verwendet werden. Somit wird ein SID-Eintrag ein Mal in der SID-Tabelle gespeichert, kann aber mehrmals in beliebigen InfoProvider verwendet werden. Die SID-Tabelle zählt zum Stammdatenbereich (Master Data und externe Hierarchien). Die detaillierte Darstellung der Stammdaten erfolgt im Abschnitt 3.4.3.

17 D.h.: Mindestens drei Tabellenzusammenführungen (joins) sind nötig, um die Fakten durch Hierarchien interpretieren zu können. 18 Bei Line-Item Dimensionen kann entsprechend von einer Sternenschema-ähnlichen Struktur ausgegangen werden.

67

Abbildung 3-9: Erweitertes Starschema / InfoCube

Quelle: In Anlehnung an [Mehrwald2003]

Bei der Definition von InfoCubes sind 3 Dimensionen vordefiniert (vgl. 2.5.3.1) Die Zeitdimension nimmt alle Zeitmerkmale, die Einheitendimension alle Einheiten (vgl. 2.5.1.1) auf. Die Package-Dimension ist für das Laden der Daten in InfoCubes verantwortlich und enthält wichtige Qualitätssicherungsdaten - zur Datenkorrektur - und Management von Delta-Updates. Eine besondere Form von Dimension ist die Line-Item-Dimension. Solche Dimensionen enthalten nur SID-Tabellen und keine DIM Tabellen, sodass die SID-Einträge direkt in die Faktentabelle eingeschrieben werden. Dabei würde die Gruppierung / Hierarchisierung der Einträge in der jeweiligen Dimension verlorengehen. Die Leistung der Abfragen wird aber verbessert, da die Daten in um eins verkürzte Relationaldistanz (d.h. join) erreicht werden.

3.4.2 Abkapselung von InfoCubes Durch den Umweg zwischen SID-Tabellen werden InfoCubes effektiv von den jeweils verwendeten Daten abgekapselt. Man kann hier in gewisser Hinsicht von der Trennung von Analyse und Staging sprechen. Außer Kennzahlen der Faktentabellen werden alle multidimensionale Daten im BW im Form von Stammdaten gespeichert. Durch InfoCubes geschieht eigentlich nur eine Auswahl an jeweils erforderlichen Datensätzen in den Stammdaten, die untereinander in Dimensionen und dimensionsübergreifend in

68

Faktentabellen zusammengesetzt werden. Das InfoObject Merkmal ist dabei mit dem komplexen Aufbau das primäre Strukturierungsobjekt in InfoCubes. Kennzahlen, Einheiten und Zeitmerkmale haben einen einfacheren und kleineren Aufbau, sodass sie in größeren Dimensionen (Zeit, Einheiten) oder in der Faktentabelle (Kennzahlen) angewendet werden. Merkmalsdaten werden im Rahmen des Staging zunächst nicht auf der InfoProvider-Ebene (ODS-Objekte und InfoCubes), sondern auf der InfoObjekt-Ebene fortgeschrieben. Die Definitionen und Inhalte der Daten fliessen in InfoObjekte, die in Master-Data-Tabellen zusammengefasst werden. Die künstlichen Schlüssel werden in die InfoProvider fortgeschrieben. Somit kann ein InfoObjekt durch denselben Schlüssel in unterschiedlichen Analysebereichen repräsentiert werden.

3.5 Stammdatenmodell des BW

3.5.1 Master-Data-Modell Master Data wird in komplexen Tabellenstrukturen modelliert. Die ABAP-Dictionary-Tabellen für Master Data verwenden den Namensraum „/BI0/*“.

3.5.1.1 Texten Texttabellen besitzen den Namensraum „/BI0/T*“. Sie können verschiedene längen und können sprachabhängig (Codepageabhängig) definiert werden. Die zeitabhängige Darstellung ist auch möglich, wird aber äußerst selten notwendig und wurde deswegen in Abbildung 3-10 nicht dargestellt. ([Mehrwald2003], 74) Für Stammdatentabellen grundsätzlich gibt es zwei Klassifikationen (vgl. 2.5.2):

3.5.1.2 Stammdaten nach Navigationsmöglichkeit Anzeigeattribute sind grundsätzlich für das Anzeigen von Werten gedacht. Sie können nicht als Filterkriterium für Abfragen verwendet werden. Beim browsen können sie nicht selektiert werden, d. h. die Navigation von einer Cube-Darstellung zu einem Anderen ist über Anzeigeattribute nicht möglich. Die Anzeigeattribut-Tabellen sind in Abbildung 3-10 als Tabellenklassen „/BI0/P*“ und „/BI0/Q*“ sichtbar. Attributsmerkmale, die drill-through ermöglichen sollen, werden Navigationsmerkmale genannt. Sie enthalten SID-Einträge, da Sie auf andere SID-Tabellen verweisen müssen, um die Navigation zu ermöglichen. (siehe Abbildung 3-10, Tabellenklasse „/BI0/X*“ und „/BI0/Y*“, beachte Attribut-SID 1,..., n)

69

Abbildung 3-10: Stammdatenmodell des BW


3.5.1.3 Stammdaten nach Zeitbezug Zeitkonstante Stammdatenattribute werden für die aktuelle und historisierte Darstellung von Daten angewendet. Die historisierte Darstellung wird durch das Nachladen von Daten bei jedem Extraktionsprozess ermöglicht (Tabellenklassen „/BI0/P*“ und „/BI0/X*“). Dabei wird üblicherweise eine neue Kombination von - nicht veränderte - SID-Einträge mit neuen Kennzahlwerten in die Faktentabelle geschrieben. Zeitabhängige Stammdatenattribute werden für die stichtagsbezogene Darstellung von Daten angewendet. Somit ist es möglich, nicht nur den zeitlichen Ablauf, sondern auch den veränderlichen Attributswert zu einem Stichtag in der Vergangenheit zu ermitteln. Dies wird durch DateTo- und DateFrom-Schlüssel ermöglicht. (Abbildung 3-10, Tabellenklasse „/BI0/Q*“ und „/BI0/Y*“)

70

3.5.2 Modellierung von Hierarchien Hierarchien können explizit durch externe Hierarchien oder implizit durch Anordnung der Merkmale bei Dimensionen- bzw. InfoObjektattributen modelliert werden. Die Hierarchisierung in Dimensionstabellen wird über die 1:n Beziehung zwischen den Merkmalen erreicht. Analog dazu können Hierarchien in allen Stammdatentabellen (P*, Q*, X*, Y*) durch 1:n – Beziehungen der Attribute abgebildet werden. Implizite Hierarchien in Dimensionen werden für die historisierte, Hierarchien in Attributen werden für die zeitlich aktuelle Darstellung verwendet.19 Beide Arten der impliziten Hierarchiemodellierung haben jedoch Nachteile ([Mehrwald2003], 149):

• Die Anzahl der Hierarchiestufen ist fest definiert und für jeden Zweig der Hierarchie identisch (balancierter Baum).

• Jede Veränderung der Hierarchiestruktur (Hierarchietiefe) muss durch die Modellierung des jeweiligen InfoObjektes erfolgen. Dies ist wesentlich aufwendiger als bei einer externen Hierarchie.

• Hierarchien in Attributen werden durch die Analysewerkzeuge von BW nicht optisch als solche dargestellt. Die Reihenfolge der Hierarchiestufen sind dem Anwender nicht sichtbar. Der Anwender muss daher wissen, dass eine bestimmte Kombination von Attributen eine Hierarchie darstellt.

Externe Hierarchien werden in Tabellen gespeichert (vgl. 2.5.2.3) und durch ein Flag an SID-Tabellen verbunden. (vgl. Abbildung 3-10, „Flags“ bei SID-Tabelle). Externe Hierarchien sind sehr flexibel ([Mehrwald2003], 149):

• Sie können Behälterknoten (nicht-bebuchbare) beistzen, die Unterknoten logisch zusammenfassen.

• Sie können eine variable Anzahl von Knoten besitzen. • Die Veränderung der Hierarchiestruktur fällt einfach aus. • Pro InfoObjekt können mehrere externe Hierarchien verwendet werden. • Die Hierarchiestruktur ist bei Analysewerkzeuge von BW sichtbar. • Sie können leicht angepasst werden, wodurch Anpassungen bei Veränderung der

Dimensionsinterpretationen20 möglich ist.

19 Man kann auch einzelne Attribute als zeitabhängig definieren. Dagegen müssen alle Texte eines Merkmals gleichzeitig zeitabhängig oder –unabhängig sein. 20 Ein Beispiel wäre die Untergliederung einer Produkt zu einer verschiedenen Produktsparte.

71

Die externen Hierarchien für die Definition parallelen Hierarchieinterpretationen geeignet. Beispiel dazu wäre eine Jahresdefinition, die sowohl in reellen Zeitgrößen (Quartale, Saisons) als auch bilanztechnischen Zeitperioden gemessen werden kann. Bei der umgekehrten Einteilung handelt es um die „gleiche Granularitätsbasis auf zwei verschiedene Hieararchiestufen“. ([Kimball1998], 281) Beispiel wäre eine Tagesdefinition, die in betriebswirtschaftliche und bilanztechnische Zeitperioden eingeordnet werden kann. (Ein Tag besitzt sowohl für das Quartal als auch für die Saison dieselbe Definition) Dies kann man als eine „inverse Hierarchie“ bezeichnen, de durch den Eintrag desselben Merkmalsknotens in zwei verschiedene Hierarchien modellierbar wäre. Der große Nachteil der externen Hierarchien gegenüber implizite Hierarchien besteht in der Verminderung der Abfrageleistung. Sie haben eine Distanz von 3 Tabellen von der Faktentabelle. Sie müssen erst durch die Interpretation einer Tabellenstruktur in eine Baumstruktur umgewandelt werden. Zudem verursachen Sie zusätzlichen Aufwand für die Aggregatberechnungen.

Abbildung 3-11: Modellierungsmöglichkeiten bei Hierarchien21


21 In der Abbildung wurden nur die P* und X* Tabellen abgebildet, die anderen Stammdatentabellentypen können aber auch für die Hierarchisierung eingesetzt werden.

72

4 Modellierung von Datenbereitstellung

4.1 Staging in BW Die zentrale Beschreibungsstruktur in der Datenbereitstellung für ein DW ist ein Datenflussmodell. Datenflussmodelle beschreiben wie die Daten von Quellsystemen zu analysegeeigneten Strukturen gelangen. In den Zwischenstufen unterlaufen die Daten möglicherweise verschiedene Transformationen, werden in verschiedenen physischen Strukturen gespeichert und können in neuen Kontexten zusammengestellt werden. „Die Daten durchlaufen während dieses Prozesses mehrere logische Ebenen, in denen sie transformiert, homogenisiert, validiert und fehlerbereinigt werden müssen. Aufgrund der stufenförmigen Anordnung hat diese Prozess im Fachjargon die Bezeichnung Staging erhalten.“ ([Mehrwald2003], 163) Das Staging erfolgt auf 4 Ebenen (Layer) im BW ([Mehrwald2003], 164). Angeordnet in der Reihe vom Quellsystem zu Analysestrukturen lauten diese:

• Extraction Layer • Inflow Layer • Transformation Layer • Integration Layer

4.1.1 Extraction Layer Aufgabe des Extraction Layer ist die Extraktion der Stamm- und Bewegungsdaten aus den jeweiligen Quellsystemen und die Belieferung des BW mit diesen Rohdaten ([Mehrwald2003], 165). Im Extraction Layer sind dementsprechend die folgenden Metadaten vorhanden ([Mehrwald2003], 166):

• Verfügbare Datenquellen und Struktur der Daten • Die Anwendungskomponentenhierarchie • Unterstützte Delta-Verfahren der Datenquellen

Der zentrale Speicherbegriff im Extraction Layer ist der sogenannte DataSource. Eine Sammlung von DataSources aus einem Quellsystem wird in einer Anwendungskomponentenhierarchie beschrieben.

73

Bei den Delta-Verfahren handelt es sich um die Möglichkeiten zur Überwachung des Datentransfers. Kann eine Dokumentation im System über die aufgeladene und noch nicht aufgeladene Daten geführt werden, so muss man nicht bei jedem Datentransfer den Gesamtdatenbestand wiederholt übertragen. Ein Beispiel zu solchen Strukturen, die keine Delta-Verfahren unterstützen, sind die Flatfiles. Die zu übertragenden Daten werden in einer Transferstruktur22 „verpackt“. Die Transferstruktur stellt somit die Definition einer Datenübertragungsstruktur dar.

4.1.2 Inflow Layer Der Inflow Layer bildet die Schnittstelle zwischen dem Extraction Layer und der weiteren Verarbeitung der Daten im BW. Im Inflow Layer müssen die folgenden Konfigurationsmaßnahmen getroffen werden ([Mehrwald2003], 189):

• Quellsystemeinrichtung • Metadatendefinitionen

Die möglichen Quellsystemarten in BW wurden in Kapitel 2.4.3 angegeben.

4.1.2.1 Replizierung von Transferstrukturen Die Transferstrukturen im Inflow Layer wiederspiegeln solche aus Quellsystemen (d.h. vom Extraction Layer) dar. Sie werden aus den Quellsystemen repliziert, werden aber nach Änderungen im BW nicht in Quellsystemen aktualisiert.

22 Die Begriffe Transferstruktur und Transferregel sind nicht verwandt. Transferstrukturen tauchen in Staging-Ebenen Extraction und Inflow, Transferregel zwischen Inflow und Transformation auf.

74

Abbildung 4-1: Replizierung der DataSources


4.1.2.2 Persistent Staging Area Aus dem Extraction Layer gelieferte Daten können unmittelbar nach dem Eingang ins BW in der Persistent Staging Area (PSA) abgelegt. Werden. Der PSA speichert die Daten in derselben Granularitätsstufe, wie sie vom Quellsystem geliefert wird. Der PSA wird hauptsächlich für die Datenvalidierung und Leistungsoptimierung im Rahmen der Ladevorgänge angewendet. Sie dient in dieser Hinsicht als Zwischenlager für Quellsysteminformationen.

4.1.3 Transformation Layer Der Transformation Layer dient zur Aufwertung der Qualität der Daten und für die Aufbereitung für Weiterverwendung. Der erste Schritt dazu wird oft mit der Homogenisierung von Daten durch Bereinigung von aus dem PSA-Bereich stammenden Datenfehlern unternommen. Dies wird durch die Übertragungsregeln (Transferregeln) gewährleistet, die Daten aus dem Inflow-Layer übermitteln.

4.1.3.1 InfoSource Das Zieldatenobjekt im BW für die Homogenisierung von Daten ist der InfoSource. ([Mehrwald2003], 214): Ein InfoSource übernimmt die folgenden Funktionen ([Mehrwald2003], 214)::

75

• Beschreibung der Zielstruktur der Homogenisierung (die Kommunikationsstruktur)

• Zusammenfassung aller Übertragungsregeln aller ihr zugeordneten DataSources • Beschreibung der Ladevorgänge

4.1.3.2 Kommunikationsstruktur Die Kommunikationsstruktur wird als

• Datenquelle für direktes Staging von Stammdaten (Attribute und Texte) im Transformation Layer

• Datenquelle für flexibles Staging im Integration Layer verwendet. ([Mehrwald2003], 214) Direktes Staging wird als eine einfachere Art für den Stammdatentransfer ins BW verwendet, während flexibles Staging mehrere Optionen bietet und für Bewegungsdaten eingesetzt wird. Eine Kommunikationsstruktur kann beliebig viele Übertragungsregeln haben, die DataSources zu der jeweiligen Kommunikationsstruktur verknüpfen.

4.1.3.3 InfoPackage Infopackages beherbergen die Definition von Ladevorgängen. Die „Verpackung“ der Dateneinheiten bedeutet einfach, dass eine bestimmte Zusammenstellung von Daten vom DataSource-Bereich zum InfoSource-Bereich gelangt. InfoPackage-Größen und Fortschreibungsorganisation haben einen wesentlichen Einfluß auf die Stagingleistung. In der Abb. 4-2 wir die sequentielle, paketweise Übertragung (PSA, anschließend Datenziele) beispielhaft illustriert.

76

Abbildung 4-2: Paketweise Übermittlung von Daten


4.1.4 Integration Layer Der Integration Layer ist für die Übernahme transformierter Daten in die InfoProvider zuständig. Die transformierten Daten werden dem Integration Layer durch InfoSources bereitgestellt. Der Integration Layer nimmt zwei Aufgaben wahr ([Mehrwald2003], 257):

• Prozessintegration durch Aufbereitung von InfoSources für die Aufnahme in InfoProvider

• Modelltransformation zur Anpassung der Staging- und Analyseanforderungen an die spezifischen InfoProvider. (InfoCubes, ODS-Objekte und InfoObjects)

Für die Integration Daten aus InfoSources in die InfoProvider werden Fortschreibungsregeln definiert. Jeder InfoProvider kann mehrere Fortschreibungsregeln haben.

77

4.2 Transformationsprozesse Die Datentransformationsprozesse in BW werden durch die Übertragungsregeln und Fortschreibungsregeln abgedeckt. Wir Teilen die Transformationsprozesse in zwei Klassen ein:

• Datenintegrationstransformationen, die technische und semantische Konflikte zwischen Daten aus verschiedenen Quellsystemen lösen sollen.

• Anwendungslogik-enthaltende Transformationen, die die Daten in ein Format transformieren, die für ein bestimmtes Analysezweck geeignet ist.

4.2.1 Datenintegrationstransformationen Die Datenintegrationstransformationen können in folgende Klassen eingeteilt werden:

Tabelle 4-1: Datenintegrationstransformationen Transformationsart Beispiel Direkte Zuordnung von Datenfelder vom Quellsystem zum Zielsystem

Feld 1 3, 2 5, ...

Typumwandlungen INTEGER NUMC Zeichenvorlagenkonvertierung zwischen verschiedene Codepages ASCII ISO-Latin Formatänderungen 25/03/2001 20010325 Eintragung von fehlenden Werten NULL „N/A“ Einheit- und Währungsumwandlung lbs kg Datenkorrektur „Male“ „M“ Gewährleistung der referenziellen Integrität Datenbankfunktion

Quelle: Eigene Darstellung, Datenquelle ([McDonald2002], 237-238)

4.2.2 Anwendungslogik-enthaltende Transformationen

Tabelle 4-2: Anwendungslogik-enthaltende Transformationen Transformationsart Beispiel Kalkulationen Datenfeld = Datenfeld/4 Selektionen /Projektionen Mandant des Datenfeldes auswählen Aggregation / De-aggregation Tagesumsatz auf Woche aufsummieren Normalisierung / Denormalisierung 3.NF ↔ 1.NF

Quelle: Eigene Darstellung, Datenquelle ([McDonald2002], 239-240)

4.2.3 Transformationsarten nach Objekten Transformationen können auf folgenden Ebenen durchgeführt werden:

78

Tabelle 4-3: Transformationsarten nach Objekten Objektgruppe Verwendungsbeispiele Datenfelder Direkte Datenfeldzuordnung, Typumwandlungen,

Formatänderungen Logische Einheiten Aggregation von Daten in einer Zielstruktur Datenpaket für Leistungsoptimierung bei Übertragung / Fortschreibung Extraktionsdurchlauf Korrekturoperationen für einen Staging- Durchlauf im PSA Ganze Datenmenge für Vergleiche/Korrekturen gegenüber andere großen

Datensätzen Quelle: Eigene Darstellung, Datenquelle ([McDonald2002], 240)

4.2.4 Transformationsstufen in BW Datentransformationen werden in den zwei Regelstrukturen, in den Übertragungsregeln und Fortschreibungsregeln festgehalten. Übertragungsregeln verknüpfen die mehrere DataSources zu einem InfoSource, womit sie die technische Integration von unterschiedlich formatierten Quellsystemdaten unter dem vereinheitlichten Dach einer InfoSource zusammenbringen. Die Fortschreibungsregeln haben die InfoProvider als Zielstruktur, wo die Analyselogik im Vordergrund steht.

Tabelle 4-4: Übertragungsregeln und Transferregeln Charakteristikum Übertragungsregel Fortschreibungsregel Fokus Datenintegration und

Harmonisierung Applikationslogik

Quellstruktur DataSource bzw. PSA InfoSource Zielstruktur InfoSource InfoCube und ODS-Objekt

(Bewegungsdaten) InfoObjekte (Stammdaten)


Einstufige Transformationsszenarien werden ausschließlich im Hauptspeicher ausgeführt. ([McDonald2002], 241) Mit dem Begriff „einstufiges Transformationsszenario“ bezeichnen wir also den Durchlauf der Daten vom Quellsystem bzw. PSA bis zu einem InfoProvider (InfoCubes, ODS-Objekte und InfoObjects), falls die Daten nicht zwischengespeichert werden.

4.3 Referenzstrukturen für den Datenfluss Im Rahmen des Datenflusses behandelt ein einstufiges Transformationsszenario die Migration der Daten vom Quellsystem zu initialen Abspeicherung in Analysestrukturen.

79

Dies umfasst den gesamten ETL-Prozess. Die Datenbereitstellung behandelt aber auch Szenarien, wo die Daten in mehrstufigen Transformationsszenarien23 beteiligt sein können. In solchen Strukturen laufen die Daten mehrere Analysestrukturen (InfoProvider) durch. Somit können in mehrstufigen Transformationsszenarien die InfoProvider als „Quellsysteme“ betrachtet werden. Die explizite Definition solcher Strukturen erlaubt Teillösungen für die Analyse. Diese Bereichslösungen können je nach Ansicht als Data Marts oder Implementationsiterationen für den Data Warehouse betrachtet werden. Beispiel wäre ein Teilimplementation, der mit dem Staging Area beginnt und in einem Data Mart endet (vgl. Abbildung 2-6, CIF). „In Projekten hat es sich als hilfreich erwiesen, das Staging nicht individuell für einzelne Anforderungen oder InfoProvider zu definieren, sondern zu Beginn der Modellierung eine Referenzarchitektur festzulegen, welche das Staging für alle Daten eines Geschäftsprozesses verbindlich vorschreibt. Dies hilft bei der Fehlersuche, dient der Dokumentation des Systems und erleichtert insbesondere die Erweiterung des Staging zur Realisierung neuer Anforderungen“ ([Mehrwald2003], 313). SAP schlägt verschiedene Referenzstrukturen zur Entwicklung von Lösungen vor. Diese richten sich nach Analyseanforderungen und Art und Umfang der Prozessdaten im Rahmen der Datenbereitstellung. Die Referenzarchitektur für eine Standardlösung seht voraus, dass keine Prozessintegration der Daten notwendig ist. Die im Daten Quellsystem sollen also einheitliche Definitionen (d.h. betriebswirtschaftliche Interpretationen) besitzen. Die folgende Abbildung beschreibt die Standardreferenzarchitektur mit assoziierten Prozessdetails.

23 Englisch: Multi-level Staging

80

Abbildung 4-3: Standardreferenzmodell für das Staging im BW


Andere Referenzarchitekturen sind ([Mehrwald2003], 317-324):

• Die Analysearchitektur, die ausschließlich auf die Datenanalyse ausgerichtet ist • Die vereinfachte Analysearchitektur, die transaktionale ODS-Objekte einsetzt,

falls die nichtdeltafähige Datenquellen einen kleinen Umfang haben • Eine Architektur mit Cube-Partitionierung, die aus Leistungsgründen die ein

BasisCube partitionsmäßig aufspaltet und die BasisCubes wieder in einem Multiprovider zusammenfasst.

• Eine Architektur zur Prozessintegration, der einen zusätzliche ODS-Objektebene einbaut, mit dem Ziel, die Daten aus verschiedenen ODS-Objekten zu harmonisieren

• Eine erweiterte Architektur zur Prozessintegration, die die Integrationsaufgaben anstatt der ODS-Objektebene durch ein Multiprovider zusammensetzt

81

5 Zusammenfassung und Schlusswort Der SAP BW setzt mit seinem großen Funktionsumfang auf eine umfassende Lösung, die alle Aufgabenbereiche von Data Warehousing abdecken soll. Konzeption, Lösungsschwerpunkte und Leistung von BW: Viele DW knüpfen auf ihr vorhandenes Know-How bei der physischen Leistungsoptimierung ihrer RDBMS. SAP ist anders vorgegangen. Anstatt eine DW-Lösung zu konstruieren, die auf die hauseigene RDBMS SAP DB setzt, hat SAP eine umfassende „Meta-DW“ geschafft, die den gesamten DW-Lösungsumgebung durch Metadaten modelliert und verwaltet. Dieses Metadatenmodell soll von der physischen Realisierung eines bestimmten RDBMS abstrahieren. So können die logischen Strukturen sowohl auf relationale (Oracle, SAP DB, DB/2,...) als auch auf multidimensionale Datenbanken (MS Analysis) abgebildet werden. BW definiert dennoch mehrere logische Schichten für die eigenen Lösungen, sodass Teilbereiche getrennt betrachtet und optimiert werden können. Die überdurchschnittlich performante Implementierung einer DW-Lösung ist aber nicht eine der Kernkompetenzen von BW. Eine andere Auswirkung des umfassenden Metadatenmodells ist die Steuerbarkeit des ganzen Systems über Metadatendefinitionen. Da sowohl Datenbereitstellung, Datenhaltung als auch Datenverwendung über Metadaten gesteuert werden kann, ist es theoretisch möglich, das gesamte DW-Projekt durch Aktivierung von Metadaten durchzuführen. Dazu setzt SAP sehr viel auf ihre mitgelieferte Metadatendefinitionen für verschiedene DW-Lösungen, den „Business Content“. Der Business Content entsteht zum großen Teil aus den „Best Practice Lösungen“ von verschiedenen Sektoren. In der Praxis kann durch Business Content sehr gute Lösungen bei BW-Einführungen binnen kurzer Zeit erreicht werden, da diese zumindest als „Templates“ für eine DW-Einführung genutzt werden können ([McDonald2002], 164-167). Insbesondere wo fertige Analysemodelle industrieweite Akzeptanz erlange, ist der bereitgestellte Business Content besonders „analysegerecht“ für das jeweilige Unternehmen. Ein Beispiel für ein Standardmodell ist das SCOR-Modell für das Supply Chain Management. Die regelmäßig erweiterte und große Anzahl an Lösungsmodellen stellt für BW aus betriebswirtschaftlich-organisatorischer Sicht ein großer Vorteil dar.

82

Ausgewählte Charakteristika: Ein auffallendes Merkmal von BW ist die physische Schemavorgabe für die relationale Implementation, das erweiterte Starschema. Dieses komplexe Tabellengebilde bietet verschiedene proprietäre Lösungen für neue Fragestellungen im Data Warehousing an. Nicht alle Lösungsimplementationen sind einfach nachvollziehbar oder besonders leistungsfähig. Die Palette der formulierbaren Lösungen durch unterschiedliche Modellierungsoptionen ist aber groß. Das erweiterte Sternenschema ist flexibel genug, um andere Datenschemata hinsichtlich des Funktionsumfangs grob nachahmen zu können. Sie stellt aber zum Teil eine Vorgabe für die physische Modellierung der Tabellenstrukturen dar, sodass die Nachahmung von Sternen- bzw. Snowflakeschemeta den ursprünglichen Zweck der Leistungsoptimierung teilweise nicht gerecht werden kann. Dafür stehen aber andere -mittlerweile in der DW-Szene zum Standardausrüstung gehörende- Abhilfen zur Leistungsoptimierung bereit: Bitmap und B-Tree Indizes, Queryoptimizer mit heuristischen Prognoseverfahren etc. SAP führt mit dem erweiterten Sternenschema aber für die DW-Welt einen eher untypischen Begriff ein, die Konsequenzen für die logische Modellierung haben: Die Trennung von Bewegungs- und Stammdaten. Die Kapselung von Bewegungsdaten in BasisCubes und Stammdaten in Master Data Tabellen erlaubt eine neue Betrachtungsweise des slowly changing dimensions (langsam entwickelnde Dimensionen) Problems. Sie erlaubt eine Trennung der Daten im DW nach ihrer zeitlichen Änderungsgeschwindigkeit. Zudem führt die Wiederverwendung der Stammdaten zu Leistungsoptimierungen in Abfragen und zu weniger redundanten Abspeicherung. Zusammenfassung Die Existenz von Master Data adressiert folgende Probleme ([McDonald], 127): „ [Die Nichtbeachtung der Existenz von Stammdaten] hat zu verschiedene Problemen für OLAP Werkzeuge und DW-Suites geführt. Unter diesen Problemen können wir die langsam entwickelnden Dimensionen, unbalanciertes Modellierungsvorgehen und andere irreguläre Hierarchien nennen.“ Zu den SID-Tabellen (Verknüpfung zwischen Stamm- und Bewegungsdaten) wird in ([Mehrwald2003], 92) die folgende Stellung genommen:

83

„Die Erweiterung des Snowflake-Schema um die SID hat weitreichende Folgen für den Funktionsumfang des Datenmodells. Insbesondere die Nutzung von Navigationsattributen, Texten, Zeitabhängigkeiten und externen Hierarchien grenzt das BW von den anderen Data-Warehouse-Systemen ab, die derartige Funktionen nicht in diesem Umfang bieten.“ Wie oben erwähnt ist die Hierarchiemodellierung in BW äußerst flexibel. Besonders das Time-Volatility-Problem wird durch die sehr flexiblen externen Hierarchien gut adressiert. Das Time-Volatility-Problem entsteht aus der Änderung der Hierarchiestrukturen zwischen den Dimensionsattributen. (Beispielsweise die Änderung der Abteilungshierarchie in einem Unternehmen) Dies führt zu Zuordnungsprobleme bei der historischen Analyse von Fakten ([Rajan], 2). Die externen Hierarchien im BW adressieren dieses Problem mit versions- und zeitabhängige Varianten. Hinsichtlich der Internationalität bietet BW die traditionellen Vorteile des ERP-Bruders R/3. Dies schlägt sich in einen soliden Funktionsumfang bezüglich der Einheiten-, Währungs- und Textbehandlung. Im Rahmen der Datenextraktion hat BW zum Teil den Ruf, „ein Front-end für R/3 Reporting“ zu sein. Der Business Content liefert aber viele Komplettlösungen, die aus verschiedenen nicht-R/3 (bzw. nicht-SAP) Quellsystemen extrahieren und darüber hinaus Stagingszenarien, Analysestrukturen und fertiggestellte Arbeitsvorlagen für die tägliche Analyseanwendung anbieten. Letztendlich scheinen mit der umfangreichen Funktionalität von BW komplexe DW-Lösungen sehr wohl modellierbar.

84

Literaturverzeichnis

Bücher und andere Publikationen im Papierform [Behme1996] Mucksch, H. und Behme, W., „Business Intelligence als Baustein des Geschäftserfolgs“. In: Das Data Warehouse-Konzept – Architektur-Datenmodelle-Anwendungen , 1. Auflage, Gabler, Wiesbaden, 1996 [Behme2000] Behme, W, Business Intelligence als Baustein des Geschäftserfolgs. In: Das Data Warehouse-Konzept – Architektur-Datenmodelle-Anwendungen. Hrsg.: Mucksch, H. u. Behme, W., 1. Aufl., Gabler, Wiesbaden, 1996 [Mehrwald2003] Mehrwald, C., SAP Business Information Warehouse 3 – Architektur, Konzeption, Implemetierung, 1.Auflage, dpunkt.Verlag, Heidelberg, 2003 [Kemper2001] Kemper, A., Eickler, A., „Datenbanksysteme – Eine Einführung“, 4. Auflage, Oldenbourg, München, 2001 [Kimball,1998] Kimball, R. et al., The Data Warehouse Lifecycle Toolkit, Wiley Computer Publishing, New York, 1998 [McDonald2002] McDonald, K et. al. “Mastering the SAP Business Information Warehouse”, Wiley, New York, 2002. [Ortner1999] E. Ortner, nichtpublizierte Unterlagen zur Vorlesung „Entwicklung von Anwendungssystemen 1“, Technische Universität Darmstadt, 1999 [Schinzer1999] Schinzer, H. et al., „Data Warehouse und Data Mining: marktführende Produkte im Vergleich“, 2. Auflage, Vahlen, München 1999. [Totok2000] Totok, A., „Grafische Notationen für die semantische multidimensionale Modellierung“, In: „Das Data Warehouse-Konzept – Architektur-Datenmodelle- Anwendungen“, Hrsg.: Mucksch, H. u. Behme, W., 4., vollst. überarb. und erw. Aufl., Gabler, Wiesbaden, 2000 Dateien im elektronischen Format (auf dem beigelegten CD) Bitte beachten Sie die Copyrighthinweise der jeweiligen Dateien! Die Dateien auf dem CD sind in der Regel mit Urheberrechten versehen und nicht für die Weitergabe geeignet!

85

PDF Dateien [CWMspec] „Common Warehouse Metamodel (CWM) Specification”, Version 1.0, 2 February 2001, www.omg.org/docs/ad/01-02-01.pdf , 01-02-01.pdf [OracleWB2003] “Oracle 9i Warehouse Builder User’s Guide”, Release 9.2, Stand Juli 2003, http://www.oracle.com, Oracle Technology Connection-Bereich, Zugriff am 05.03.2004, B10996_01.pdf [TS-SapBw2002] „Data Warehousing mit dem SAP Business Information Warehouse –Universitäres Berichtswesen - Theorieskript“, Technische Universität München, 2002, Theorieskript BW.pdf (Datei wurde umbenannt und mit PDF-Lesezeichen weiterverarbeitet) [Jindal] Jindal, R. und Acharya, A., “Federated Data Warehouse Architecture”, www.dmreview.com/whitepaper/wid1070.pdf, Zugriff am 10.03.2004, WID1070.pdf [Wan] Wan, Q., “Beyond the Star Schema – Transitioning from an Entity-Oriented Model to a Metrics-Oriented Model for Multidimensional Data Analysis, www.dmreview.com/whitepaper/wid599.pdf, Zugriff am 11.02.2004, WID599.pdf Webseiten [URL1] www.billinmon.com Die CIF-Abbildung Sonstige Quellen [SAP] SAP Webseiten: help.sap.com, service.sap.com SAP CD-Dokumentation zu SAP BW 3.1a und SAP SEM Literaturempfehlungen Der Autor empfiehlt die vier Hauptquellen für die weiteren Reschärsche dieser Arbeit vorgestellter Themen: [TS-SapBw2002], [Kimball1998], [McDonald2002] und [Mehrwald2003].

86

Ehrenwörtliche Erklärung

Hiermit versichere Ich, das vorliegende Abschlussprojekt ohne Hilfe Dritter und mit den angegebenen Quellen und Hilfsmitteln angefertigt zu haben. Alle Stellen, die aus den Quelen entnommen wurden, sind als solche kenntlich gemacht worden. Diese Arbeit hat in gleicher oder ähnlicher Form noch keiner Prüfungsbehörde vorgelegen. Istanbul, 24.Mai.2004 _____________________ Sami Bilal

Documents

Konzeptionen und Modelle für Data Warehouses - Eine ...ERP Enterprise Resource Planning ETL Extract, Transfer, Load MDX Multidimensional Expressions ODBO ODBC for OLAP ODBC Open Database