SAP Business Warehouse / Business Intelligence – eine Einführung

(Last Updated On: 29. Januar 2015)

Was ist eine Warehouse-Lösung

Eine Warehouse-Lösung erlaubt es seinen Anwendern, analytische Abfragen auf Basis der gespeicherten Informationen in einem ERP-System (Enterprise Resource Planning) anzuwenden.

NOrmalerweise werden Warehouse-Lösungen als OLAP-Software (Online Analytical Application) oder als Data Warehousing-Software bezeichnet.

Mit diesen analytischen Abfragen können Voraussagen für die Zukunft getroffen werden. Beispielsweise im Hinblick afu die Finanezn und das Controlling eines Unternehmens.

Ein ERP-System ist mehr auf die Mitarbeiter  und das kleine bis mittlere Management eines Unterenhmens in den einzelnen Abteilungen zugeschnitten – der Personaler kann beispielsweise mit dem SAP HR (Human REsources) Modul des ERP-Systems von SAP seine Personalstellen planen, Personal-Mitarbeiter können Urlaubszeiten, Zeiterfassung, Schichtpläne und Ähnliches in der HR-Lösung bearbeiten. Desweiteren wird mit den Daten des ERP-Systems das sogenannte Day-to-Day-Reporting realisiert. Das heißt auch mit den Daten im ERP-System sind bereits einfache Analysen im kleinen und mittleren Management mögliuch, beispielsweise kann man feststellen, wei viele Artikel heute verkauft wurden, wie viele Bestellungen eingegangen sind usw.

Das Data Warehousing-System hingegen ist an das Top-Management des Unternehmens gerichtet, welches anhand der Daten, welche die Mitarbeiter im ERP-System hinterlegt haben, Analysen durchführen können. Das Top Management möchte Trends und Vorhersagen aus den Daten gewinnen und nutzt dafür diese Softwarelösung. Das ist mit den simplen Daten aus dem ERP-System nicht ohne weiteres möglich. Ein Data Warehousing-System wird also für Reporting und Analysen in größeren Zeitspektren, also Wochen-, monats- oder jahresbasis, benutzt.

Damit ein Data Warehousing-System Sinn macht, ist es natürlich zunähcst einmal notwendig, dass es ein ERP-System gibt, in welchem Daten eingetragen und gepflegt werden. ERP-Systeme sind transaktionsbasierte Systeme, deswegen werden sie auch OLTP-Syteme genannt.  Aus Sicht der Datenbank, in welcher die Daten gespeichert und hinterlegt werden, dient das ERP-System zum eintragen und ändern von Informationen (INSERT / UPDATE) und das Data-Warehousing-System zum Abfragen der Daten (SELECT). natürlich kann man Daten aus der datnebank auch im ERP-System abfragen, snst könnte man Datensätze ja nicht lesen, um sie danach zu ändern. aber die möglichkeiten sind eben für das Management nicht ausreichend und sehr begrenzt.

Das Besondere an Data-Warehousing Systemen ist auch, dass Daten über Jahrzehnte hinweg gehalten und in eine Analyse miteinbezogen werden können.

Da also Unmengen an Daten gespeichert und auf einmal abgefragt werden müssen, ist die Last auf der Datenbank durch das Data Warehousing-System sehr groß. Die Last auf der Datenbank durch das ERP-System, in welchem Daten beinahe sekündlich geändert und eingetragen werden, ist aber auch nicht zu verachten. Deswegen ist es gängige Praxis, zwei verschiedene Datenbanken zu erstellen – eine Datenbank für das ERP-System – und eine für das Data WArehousing System. Damit das funktioniert, müssen sich ändernde oder hinzukommende daten im ERP-System auf das Data Warheousing-System übertragen werden. Es würde natürlich keinen Sinn machen, jedes mal den kompletten Datenbestand der ERP-Datenbank it der BI-Datenbank zu synchronisieren. Deswegen werden immer nur die Änderungen übertragen. Auf diese Art und Weise sit die Last auf die Datenbanken geringer, als wenn man ERP- und BI-System in der selben Datenbank vorhalten würde.

Ein weiterer Mechanismus, der die Last auf den Datenbanken gering hätl, ist der, dass die Daten im ERP-System aggegriert werden. Wenn also beispeilsweise im ERP-Sytem genau hinterlegt ist, wie viele Tassen mit welcher Farbe und welchem Motiv von welchem Zulieferer beschafft wurden und nun im Lager vorrätig sind, ist man im Rahmen seiner BI-Analyse nicht auf so viele Details angeweisen. Deswegen werden die wichtigen Daten (Anzahl der Tassen) verallgemeinert (aggregiert) und entsprechend in die BI-Datenbank geschrieben,. das bedeutet: die BI-Datenbank muss und soll auch nicht so detailliert sein wie die ERP-Datenbank. Das spart weiterhin Ressourcen.

Desweiteren sind die daten in einer anderen STruktur hinterlegt als auf den relationalen OLTP-Datenbanken. Die OLTP-Datenbanken folgen dem Schema der Normalisierung. Das bedeutet: Die Daten liegen in der Regel in der 3. Normalenform oder höher vor. auf den Prozess der normalisierung werde ich jetzt hier nicht wirklich eingehen. Bei einer OLAP-Datenbank jedenfalls sind die Daten wieder entnormnalisiert, denn: die Daten in dieser datenbank werden meist nur gelesen und analysiert. Eine normalisierte Datenbank versucht, Redundanzen zu eliminieren, um dadurch Speicherplatz zu sparen. Also versucht eine normalisierte OLTP-datenbank, möglichst effektiv auf die Datenbank zu schreiben. Das Problem ist: durch die normalisierung müssen beim Lesen der Datenbank immer wieder referenzen gelesen und zu anderen Stellen einer Datenbank gesprungen werden, da man mit Schlüsseln auf die werte in anderen Tabellen referenziert und diese referenzierten Werte erst gelesen werden müssen. Eine normalisierte datenbank ist also nicht optimal, wenn man sie größtenteils nur lesen möchte. Um die Daten möglichst effektiv lesen zu könne, müssen wir die Datenbank denormalisieren – und genua das passiert in der OLAP-Datenbank.

Desweiteren werden die Daten verschiedener OLTP-Systeme von verschiedenen STandorten einer firma in dieser Datenbank gesammelt, so dass ein Manager beispielsweise nicht erst umständlich sämtliche Informationen aller OLTP-Systeme seines Enterprise einzeln abrufen und im Anschluss zusammenfassen müsste: die infomrationen liegen bereits gesammelt in der OLAP-Datenbank vor. Es köntne sogar möglich sein, dass die verschiedenen OLTP-System jeweils unterschiedliche Datenbanken (Oracle, DB2, Microsoft SQL server etc.) nutzen, und diese verschiedenen Datenbestände in unserer OLAP-Datenbank vereinheitlicht werden.

Damit die OLAP-Software die Daten von den OLTP-Diensten bekommt, muss sie auf der anwendungsschicht Anfragen an die OLTP-Server stellen, damit diese ihre Daten an die Data Warehousing-Lösung schicken.

ein Data Warehouse bereitet also Informationen aus dem ERP-System für das Management auf. Dabei gibt es grundsätzlich ein Problem zu bewältigen: das Management braucht unterschiedlcihe Inforamtionen für Entscheidungen in unterschiedlichen Abteilungen. So müssen Daten für beispielsweise das Personalmanagement (Human Resources) anders aufbereitet werdne als für das Rechnungswesen (Finance and Controlling).

Zu diesem zweck baut ein Data Warehouse-System sogenannte Data Marts, welche Daten auf die Bedürfnisse einer bestimmten Abteilung zuschneiden und vorhalten.

Nur, weil die Daten jetzt aber aufbereitet sind, sind sie noch lange nicht für einen Menschen lesbar aufbereitet. Aus dem Informatik-Unterricht wissen wir, dass Informationen für einen Menschen am besten über Statistiken, Diagramme, Kalkulationstabellen oder Ähnlichem aufbereitet werden. Man fasst diese Möglichkeiten zur Präsentation von Daten aus einem Data Warehouse als REports zusammen. Man spricht in idesem Zusammenhang auch von Intelligenct Reporting oder auch von Multi Dimensional Analysis (MDA).

Zur Erstellung dieser reports stellt SAP die sogenannten SAP Business Object Tools (SAP BO) zur Verfügung. Diese sind also für die Präsentation der aus dem data Warehouse gewonnen Informationen zuständig.

Damit alle diese Ziele erreicht werden können, gibt es in einer Data Warehousing-Lösungen drei grundsätzliche Aufgaben zu bewältigen, die durch die Data-Warehousing-Lösung ausgeführt werden.

  • Modeling. Im ersten Schritt nehmen wir die Daten aus den verschiedenen OLTP-Systemen, die möglciherwiese in verschiedenen Datenstrukturen hinterlegt sind, weil beispielsweise ein System seine Daten auf einer Oracle-Datenbank und ein anderes seine Daten auf einem MS SQL Server hinterlegt. Alle diese Daten sind also in einem herstellerspezifischen Entity Relationship Modell hinterlgt. Im Modeling-Schritt analysiert unsere Data Warehousing-Lösungen die Datenbanken der verschiedenen OLTP-Systeme und konvertieren das ER-Model der herstellerdatenbanken in ein sogenanntes Multi Dimensional Model (MDM). Wir füphren also eine Konvertierung vom ER-Model in ein MDM Model durch und übertragen die Daten aus den herstellerspezifischen Er-Models in unser OLAP-System. Jetzt wissen wir, welche Struktur die Datenbanken der OLTP-Systeme haben, und haben die Strukturen der Daten in unser OLAP-system übertragne.
  • Extract transform and Load (ETL). Jetzt wo wir die Datenbankstruktur der verschiedenen Quell-OLTP-Systeme in unser Data Warheousing System übertragen haben, brauchen wir jetzt eine Verbindung zwischen unseren OLTP-Qeullen und unserem OLAP-Data-Warehousing-System. Durch diese Verbindung werden dann die Daten aus den relationalen Datenbanken der OLTP-Quellen extrahiert sowie in unser MDM-model umgewandelt / transformiert. die sogenannten Business Rules entscheiden, wie die Daten der OLTP-Quellen umzuwandeln sind, damit sie in das MDM-Modell unserer OLAP-Software passen. Nachdem die extrahierten Daten umgewandelt sind, werden sie in unser OLAP-System geladen und dort abgelegt.
  • Reporting. Wir habena slo jetzt die Daten unserer OLTP-Systeme in unserem OLAP-System zusammengefasst und abgelegt. Wie bereits oben erwähnt, sind diese Daten aber noch lange nicht vom Menschen wirklich lesbar hinterlegt.

SAP lösungen im Warehousing-Bereich

SAP Business INformation Warehouse (BIW) ist das Ursprungsprodukt im Warehousing-Bereich von SAP und wurde imn Jahre 1997 released.

Später wurde das Produkt umbebnannte in SAP Business Warehouse (BW) und später dann in SAP Business Intelligence (BI).

Eigentlich stehen also SAP Business WArehouse und Business Intelligence für ein und das selbe Produkt. SAP hat mit der Umbenennung zu Business Intelligence bekannt gegeben, dass das Backend seiner Data Warehousing-Lösung nun unter dem Namen SAP BW kursiert, bestehend aus Information Objects, Data Flows, Info Queues und die Logik zwischen diesen Elementen.

die SAP Data Warehousing Komponetnen werden oft als Appliance beworben, das bedeutet SAP BI muss auf von SAP zertifizierter Hardware installiert sein. Im Gegenzug garantiert SAP die Leistungsfähigkeit dieser Lösungen.

SAP BI wird heutzutage mehr und mehr als appliance mit dem Datenbankmanagementsystem SAP HANA angeboten. 

SAP BI in Verbindung mit einer SAP HANA Datenbank ist der marktführende Platzhirsch im Bereich der data Warehousing-Plattformen. sie steht in Konkurrenz zu anderen Appliance-Lösungen, beispielsweise

  • Microsoft Parallel Data Warehouse
  • Teradata Active enterprise Data Warehouse 5600
  • Oralce exadata Database Machine
  • Oralce exalytics In-Memory Machine
  • EMC greenplum Data computing appliance
  • IBM Netezza Dta warehouse Appliance
  • HP Vertica analytics Platform

die Objekte im SAP BI Data Warehousing

  • DSOs
  • Info cubes
  • INfo Objects
  • Multi Provider (MP)

 Was macht ein SAP BI Berater?

Ein SAP BI Berater macht nichts anderes als sich darum zu kümmern, Daten aus den OLTP-Systemen zu extrahieren, um sie zur Analyse auf dem OLAP-System vorzubereiten. Desweiteren kümmert er sich oft um das Reporting mittels SAP Business Objects.

In der ersten Phase, dem modelling, analysiert der Berater, die die Daten aus dem ECC/ERP, CR, APO System usw. in das SAP Business Warehouse integriert werden können. Eine Tabelle aus dem ERP-modul FICO wird irgendwie konvertiert in einen sogenannten DAta Cube für das Business Intelligence System. Ein infoCube beschreibt einen in sich geschlossenen Datenbestnad eines betriebswirtschaftlichen Bereichs, also beispielsweise aus dme Bereich FICO. Ein InfoCube aus technischer Sicht ist also eine menge von relationalen TAbellen aus unseren OLTP-Systemen, die zusammengestellt wurden. Die Modellierung dieser Übertragung vom ER-modell der OLTP-Datenbank in einen InfoCube für die OLAP-Datenbank nennt man Multi Dimensional Modelling (MDM) oder auch ein Sternschema (Star Schema).

wie wir bereits festgestellt haben, werden die Daten aus der OLTP-Datenbank im OLAP-System zusammengefasst. Und wir haben ebenfalls festgestellt, dass wir ein entnormalisiertes Datenbankmodell einem normalisierten Datenbankmodell vorziehen, da wir in unserem OLAP-Sysytem viele Abfragen machen werden.

Was wir also machen, wenn wir OLTP-Daten in unser OLAP-System ummodellieren und daraus InfoCubes machen, ist, dass wir ein sogenanntes Sternschema (Star Schema) erstellen. Wie wir bereits wissen, ist ein InfoCube ein Zusammenschluss aus mehreren relationalen Tabellen. Dabei nehmen wir nur die wichtigsten Daten aus den zusammengestellten relationalen Tabellen, die sogeanntenn Key Performance Indicators (KPI), die für unser Reporting wichtig sind. Wir würfeln dabei die KPIs mehrerer relationaler Tabellen zusammen und erstellen daraus eine einzige Tabelle, die alle KPIs in einem Datensatz enthält.

Beispiel: Eine bestellung ist im ER-modell abgebildet durch einen Kunden, der in der relationalen Tabelle „Kunden“ gespeichert ist, einem Artikel, der ind er Tabelle Artikel gespeichert ist, und einem SAchbearbeiter, der in der tabelle mitarbeiter gespeichert ist – und seine Position / Stelle al sSachbearbeiter ist vielleicht in einer Tabelle Stellen gespeichert. Was wir tun ist, wir erstellen nun aus diesen vier relationalen Tabellen einen Infocube, und haben einen Datensatz in dem wir nur noch die Artikel, ihre Anzahl und den Verkaufspreis aufführen – alles andere werfen wir weg, da es für unser Reporting uninteressant ist.

Sobald die Modelling-Phase abgeschlossen ist, müssen wir Daten letztendlich extrahieren. Hier geht es um die technische Umsetzung, wie man die informationen von mehreren Tabellen in einen einzigen Datencube zusammenfassen kann. Hierbei ist in der Regel umfassendes Wissen über Datenbankstrukturen verschiedener Hersteller notwendig.

Nachdem die Daten extrahiert und im BI-System in einen INfoCube zusammengefasst wurden, muss ich für meine INfoCubes Queries (Abfragen) schreiben. Diese Queries werden im Data Warehousing Tool erstellt und dienen dem Zweck, die in den infoCubes vorliegenden Daten in Reports umzuwandeln, sodass für das Maangement verstehbare Reports erstlelt werden können. Diese Queries können beispielsweise mit SAP Business Objects erstellt werden.

 

 

Andreas Loibl ist SAP-Berater, Ethical Hacker und Online Marketing Manager und schreibt auf seinem Blog DaFRK Blog über verschiedene Themen in den Sektoren Projektmanagement, Informationstechnik, Persönlichkeitsentwicklung, Finanzen und Zeitmanagement.

DaFRK

Andreas Loibl ist SAP-Berater, Ethical Hacker und Online Marketing Manager und schreibt auf seinem Blog DaFRK Blog über verschiedene Themen in den Sektoren Projektmanagement, Informationstechnik, Persönlichkeitsentwicklung, Finanzen und Zeitmanagement.

Das könnte Dich auch interessieren …

1 Antwort

  1. 23. Juni 2015

    […] eifnach verständlichen Vergleich zwischen OLAP und OLTP-anwendungen und deren Datenbanken habe ich in meinem Post zu SAP Business Warehouse […]

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.