Praxishandbuch SAP Business Warehouse mit BW/4HANA. Jürgen Noe
Чтение книги онлайн.

Читать онлайн книгу Praxishandbuch SAP Business Warehouse mit BW/4HANA - Jürgen Noe страница 5

Название: Praxishandbuch SAP Business Warehouse mit BW/4HANA

Автор: Jürgen Noe

Издательство: Автор

Жанр: Программы

Серия:

isbn: 9783960120278

isbn:

СКАЧАТЬ

      Abbildung 1.3 stellt die Referenzarchitektur der LSA von SAP in der Übersicht dar.

      Abbildung 1.3: LSA-Blöcke (eigene Darstellung)

      Die einzelnen Blöcke werden nacheinander durchlaufen, und im Zuge dessen werden die einzelnen Bausteine an den Bedürfnissen und Prozessen des Kunden ausgerichtet. Mit dem Kunden werden innerhalb des Blocks »Bausteine« beispielsweise die Granularität der Schichten definiert und Vorgaben für Datenmodelle sowie Entwicklungsrichtlinien festgelegt. Damit entsteht eine kundenindividuelle LSA, die die Prozesse und die Umgebung des Kunden exakt widerspiegelt. Die LSA bietet somit weit mehr als die reine Schichtenarchitektur des bisherigen Data Warehouse, indem sie alle Prozesse beschreibt, die für den Aufbau sowie für den reibungslosen Betrieb eines Business Warehouse erforderlich sind. Für die Gliederung in einzelne Schichten findet sich in der Referenzarchitektur ein Vorschlag (siehe Abbildung 1.4).

      Abbildung 1.4: LSA-Schichtenmodell

      Man erkennt hier eine Fünf-Schichten-Architektur. Die Eingangsschicht entspricht dem Staging-Bereich in Bill Inmons CIF (vgl. Abschnitt 1.2.2). Die Ebenen Datenqualitäts- und Harmonisierungsschicht, Datenverteilungsschicht sowie Schicht zu Umwandlung in Fachbereichsdaten entsprechen zusammengenommen grob der ETL aus Bill Inmons CIF. Die oberste Schicht, die Berichtsebene mit den Data Marts der Fachabteilungen, entspricht dem Enterprise Data Warehouse. Das Corporate Memory hält die Daten der Eingangsschicht harmonisiert und in Unternehmensbegrifflichkeiten übersetzt zum Wiederaufbau der Applikationen vor, falls die Daten nicht mehr aus dem Quellsystem geladen werden können. Dies kann der Fall sein, wenn die Daten im Quellsystem aus Datenschutz- oder Archivierungsgründen gelöscht werden mussten.

      Schon seit Mitte der Siebzigerjahre war das Konzept der spaltenbasierten Datenbanken bekannt, in denen die Daten nicht wie bei herkömmlichen relationalen Datenbanken in Zeilen, sondern in Spalten abgelegt sind. Diese Form der Speicherung eignet sich besonders für Data Warehouses und OLAP-Systeme. Erweitert wurde das Konzept durch sogenannte In-Memory-Datenbanken, wie beispielsweise 1997 durch QlikView.

      2007 stellte die SAP ihre erste In-Memory-Lösung unter dem Namen SAP Business Warehouse Accelerator vor. Dabei handelte es sich um zusätzliche Hardware, in der die Daten nicht mehr Zeile für Zeile, sondern in Spalten abgelegt wurden. Mit einem an das BW angeschlossenen Business Warehouse Accelerator konnte die Abfrageperformance deutlich erhöht werden.

      In den folgenden Jahren wurde diese Technologie ständig weiterentwickelt. 2010 präsentierte das Hasso-Plattner-Institut in Berlin die neue Lösung SAP HANA. Bei SAP HANA handelt es sich nicht nur um eine reine In-Memory-Datenbank, die in sehr kurzer Zeit auf sehr große Datenmengen zugreifen kann. Es ist vielmehr eine komplette Plattform. Zu dieser gehören neben der SAP HANA Appliance und SAP HANA In-Memory Appliance auch die SAP In-Memory Computing Engine. Die SAP-HANA-Datenbank speichert sowohl Daten aus OLTP- als auch aus OLAP-Systemen.

      SAP BW und SAP HANA

      SAP HANA wird erst mit SAP BW 7.3 als Datenbank unterstützt. Frühere Releases von SAP BW können nicht mit dieser Technologie genutzt werden.

      Mit dem Einsatz der SAP-HANA-Plattform ergeben sich Änderungen an der Layered Scalable Architecture. 2012 veröffentlichte die SAP Anpassungen an der LSA unter der Bezeichnung LSA++. Abbildung 1.5 stellt die Architektur zusammenfassend dar.

      Abbildung 1.5: Architektur von LSA++

      Ein Bestandteil der Architektur ist u.a. eine virtuelle Data-Marts-Schicht in BW, in der sich die Daten aus den vorhergehenden Schichten als sogenannte externe View in SAP HANA ablegen lassen. Dadurch können Queries mit optimalen Zugriffszeiten auf operationale Daten gebaut werden. Während die LSA noch – überwiegend aus Performancegründen – eine Trennung zwischen Berichtsebene und den operationalen Daten vollzog, entfällt diese Trennung durch den Einsatz von SAP HANA. Mit dieser neuen Datenbanktechnologie von SAP kann auf alle Schichten der LSA++-Architektur gleichermaßen leistungsfähig zugegriffen werden, was letztlich ein operatives und taktisches Berichtswesen zulässt. Die großen Vorteile liegen hier in einer Auflösung des starren Schichtenmodells, das mehrfach redundante Speicherung erzwang, und einem flexibleren Aufbau der Unternehmensberichte auf operationalen und taktischen Daten.

      Migration auf SAP BW/4HANA

      Eine Darstellung aller Funktionalitäten sowie Migrationsmöglichkeiten von einem Business Warehouse on any DB oder SAP BW on HANA auf SAP BW/4HANA sprengt den Rahmen dieses Buches. Als weiterführende Lektüre verweise ich auf das Buch »SAP BW/4HANA und BW auf HANA«, 2., erweiterte Auflage (Sauer/Riesner, Espresso Tutorials, 2017)

      Als Folge der Einführung von SAP HANA als grundlegende Plattform war es nur logisch, SAP Business Warehouse ebenfalls technologisch auf neue Füße zu stellen. Mit der Version 7.5 des SAP Business Warehouse liefert SAP die letzte Version eines auf SAP NetWeaver basierten Warehouse. Weiterentwicklungen oder neue Funktionalitäten sind aktuell für SAP BW 7.5 nicht geplant. Da die neue technologische Basis für SAP Business Warehouse die Datenbank SAP HANA ist, erhielt das neue Produkt auch einen entsprechenden Namen: »SAP BW/4HANA«. SAP HANA dient dabei sowohl zur Speicherung der Daten als auch zur Abwicklung von Logiken im Bereich des ETL oder zur Umwandlung der Fachbereichsdaten. Für die Beschreibung Letzterer stellt SAP HANA beispielweise spezielle mathematische, statistische oder auch String-Verarbeitungsfunktionen zur Verfügung. Aus Gründen der Abwärtskompatibilität verfügt SAP BW/4HANA über einen kleinen ABAP Stack, mit dem der Entwickler Business-Logik in ABAP hinterlegen kann.

      1.3.1 Elemente und Struktur von SAP BW/4HANA

      Wie in Abbildung 1.5 ersichtlich, können Sie an SAP BW/4HANA verschiedene Quellsysteme anschließen. Dies können andere SAP-Systeme, Dateien, relationale Datenbanken, aber auch Webservices sein.

      Die Anbindung der verschiedenen Quellsysteme erfolgt über sogenannte DataSources, die ein Eins-zu-eins-Abbild der Quelldaten darstellen.

      Die Eingangsebene der Daten kann in SAP BW/4HANA mit sogenannten Advanced DataStore Objects (aDSO) in der Ausprägung eines schreiboptimierten DSO modelliert werden. Dies sind flache Tabellen, in denen die Daten aus dem Vorsystem unverändert abgelegt, historisiert und im nächsten Schritt über ETL-Methoden an das SAP Business Warehouse übertragen werden können.

      Das kleinste Element der Modellierung in SAP BW/4HANA stellt das sogenannte InfoObject dar. InfoObjects lassen sich wiederum nach Merkmalen und Kennzahlen unterscheiden.

      Methoden der Datenverarbeitung stehen in SAP BW/4HANA ausschließlich in Form von Transformationen zur Verfügung. Als Lademethode dient der Datentransferprozess. Datenziele einer Transformation heißen in SAP BW/4HANA allgemein InfoProvider. Die beiden wichtigsten Typen der InfoProvider sind das bereits erwähnte aDSO sowie der CompositeProvider. CompositeProvider bieten eine für die mehrdimensionale Analyse optimierte Sicht auf die Daten. Der CompositeProvider vereint technisch die Möglichkeiten einer SQL-UNION und eines SQL-JOIN aus den verschiedenen beteiligten InfoProvidern.

      SQL-JOIN

      Ein СКАЧАТЬ