Lade Inhalt...

Auswirkungen der Umstellung eines SAP Business Warehouse auf SAP HANA

Studienarbeit 2014 55 Seiten

Informatik - Wirtschaftsinformatik

Leseprobe

Inhaltsverzeichnis

Abbildungsverzeichnis

Tabellenverzeichnis

Vorwort

1 Grundlagen des SAP Netweaver BW
1.1 Grundobjekte der Datenmodellierung
1.1.1 InfoObjects
1.1.2 DataStore-Objekte
1.1.3 InfoCubes
1.2 Referenzarchitektur des SAP Business Warehouse – Layered Scalable Architecture (LSA)
1.2.1 Schichtenmodell der Referenzarchitektur
1.2.2 Data Acquisition Layer
1.2.3 Corporate Memory (Layer)
1.2.4 Quality and Harmonization Layer
1.2.5 Data Propagation Layer
1.2.6 Business Transformation Layer
1.2.7 Reporting Layer (Architected Data Mart Layer)
1.2.8 Virtualization Layer
1.2.9 Operational Data Store (Layer)
1.2.10 Domänenbildung in der LSA
1.2.11 LSA-Hilfsgerüst

2 Elemente SAP HANA Appliance und technischen Grundlagen der SAP HANA Datenbank
2.1 In-Memory-Technologie
2.2 Zeilen- und spaltenbasierte Datenspeicherung
2.3 Multi-Core Prozessoren
2.4 Technische Grundlagen der SAP HANA Datenbank

3 SAP BW on HANA
3.1 LSA ++ und SAP HANA EDW
3.2 Neue Features in SAP BW 7.40 SP
3.2.1 Gemeinsame Entwicklungsumgebung auf Basis von Eclipse
3.2.2 Nahtloser Datenkonsum in einem EDW – Flexible Anbindung von unterschiedlichen Datenbanken
3.2.3 Eine verbesserte Datenmodellierung
3.2.4 BPC NW „unified“
3.2.5 Verbessertes Mobile Enablement
3.2.6 Feature Übersicht

4 Migration des SAP NW BW auf die HANA Datenbank - Gründe, Vorgehen und Hardwareanforderungen

Fazit und zukünftige Entwicklungen

Literaturverzeichnis

Abbildungsverzeichnis

Abbildung 1: Schritte des Datenladens

Abbildung 2: Integration des OLAP-Prozessors in SAP BW

Abbildung 3: Erweitertes Sternschema SAP

Abbildung 4: LSA-Referenzschichtenmodell

Abbildung 5: Sub-Layer des Reporting Layer

Abbildung 6: Bildung von Domänen in der LSA

Abbildung 7: Zielen- vs. Spaltenorientierung

Abbildung 8: Unterschied zeilen- und spaltenbasierter Abfragen

Abbildung 9: Komponenten der SAP HANA Appliance

Abbildung 10: Architektur der SAP HANA Datenbank

Abbildung 11: LSA mit InfoProvidern

Abbildung 12: LSA++ Principal Layers

Abbildung 13: LSA++ als ganzheitliches Framework für BW on HANA

Abbildung 14: Consistent Flexible EDW Core

Abbildung 15: LSA++ Virtual Data Mart Layer

Abbildung 16: Vergleich traditioneller BW Stack mit HANA Stack

Abbildung 17: Smart Data Access

Abbildung 18: Open ODS Layer Szenario

Abbildung 19: Evolution der Planung

Abbildung 20: Featureübersicht und Platformverfügbarkeit SAP BW 7.40

Abbildung 21: Schritte für die erfolgreiche Migration

Tabellenverzeichnis

Tabelle 1: Ausgewählte Funktionen des OLAP-Prozessors

Tabelle 2: Gründe für dei Migration auf BW on HANA

Vorwort

In der heutigen Zeit ändern sich die Anforderungen der Nutzer einer Data Warehouse Lösung hin zu immer performanteren Applikationen, die Daten in sekundenbruchteilen verarbeiten und bereitstellen können. Durch die stetig wachsenden Datenmengen in den Unternehmen wird es jedoch immer schwieriger den Anforderungen der Endnutzer zu entsprechen. Mit der High Performance Analytic Appliance (HANA) versucht die SAP AG sich dieser Schwierigkeit zu stellen.

Das SAP Business Warehouse (SAP BW) ist ein zentraler Bestandteil der SAP NetWeaver Plattform. Als leistungsfähige Enterprise Data Warehouse Applikationsplattform bietet das BW flexible Reporting- und Analysewerkzeuge, wodurch Unternehmen in der Lage sind fundierte Entscheidungen auf der Grundlage dieser Analysen zu machen. Business Content der SAP und aus anderen Datenquellen kann in einem BW on HANA integriert und konsolidiert und durch die technologischen Neuerungen, die BW on HANA bietet in performanten analytischen Applikationen umgesetzt werden.

SAP HANA (HANA) ist eine neue Datenbank und eine Analyse-Engine. Die Daten liegen jetzt im Hauptspeicher und nicht mehr auf der Festplatte. Komplexe Berechnungen werden nicht mehr nur in der Anwendungsschicht durchgeführt, sondern immer stärker auf Datenbankebene. Durch diese Maßnahmen erhalten Queries und Reports einen signifikanten Geschwindigkeitszuwachs und Entscheidungen können auf einer aktuelleren und schneller verfügbaren Datenbasis getroffen werden. Somit macht es Sinn für Unternehmen sich mit den Vorteilen, die eine Migration auf SAP HANA mit sich bringt zu beschäftigen und sich über die Auswirkungen auf die bestehende Systemlandschaft Gedanken zu machen.

Diese Arbeit beleuchtet die Vorgehensweise und die Auswirkungen, die sich durch die Umstellung eines klassischen SAP BW Systems auf die SAP HANA Plattform ergeben, indem Aspekte wie Systemvorrausetzungen, Datenmodellierung und mögliche Auswirkungen auf bestehende analytische Applikationen betrachtet werden.

1 Grundlagen des SAP Netweaver BW

Dieses Kapitel gibt eine Einführung zu dem grundsätzlichen Aufbau des SAP Netweaver BW (SAP BW). Es werden aber nicht alle Aspekte des SAP BW in vollem Umfang betrachtet, sondern nur die Aspekte die wichtig für die Datenmodellierung sind.

Im Folgenden werden die Grundlagen zur Datenmodellierung im SAP BW skizziert, die im späteren Vergleich zur Datenmodellierung in SAP BW 7.40 on HANA für das Verständnis unerlässlich sind. Es wird die Architektur des SAP BW im Allgemeinen vorgestellt und insbesondere das Konzept der LSA (Layered Scalable Architecture), die als Referenzarchitektur für die Datenmodellierung in SAP BW vorgesehen ist.

1.1 Grundobjekte der Datenmodellierung

Bei der Modellierung eines Datenmodells gibt das SAP BW eine Menge an BW-Objekten[1] zur Auswahl vor. Die Objekte dienen zur Implementierung der Datenmodelle und in der Folge werden Ihre grundlegenden Eigenschaften und Einsatzzwecke vorgestellt.

Zunächst werden die InfoObjects als die elementaren Bausteine eines BW-Datenmodells vorgestellt, die zum Speichern von Stammdaten und Merkmalen dienen. Darauf aufbauend werden die sogenannten InfoProvider vorgestellt, diese dienen einmal zur physischen Speicherung von flachen Daten aber auch zur Organisation und Speicherung mehrdimensionaler Daten, um optimierte Strukturen für das Reporting erzeugen zu können. Um den Nachteil von physisch gespeicherten Daten, nämlich das Laden bzw. „Staging“ der Daten, was eben zu einer zeitlichen Verzögerung der Datenbereitstellung führt, auszugleichen, stellt das BW die sogenannten VirtualProvider zur Verfügung. Diese ermöglichen es in (nahezu) Echtzeit auf die Daten zuzugreifen.

1.1.1 InfoObjects

InfoObjects sind Elemente aus denen sich ein DataProvider zusammensetzt. InfoCubes, DataStore-Objekte (DSOs), Multiprovider und InfoSets basieren also auf den im Vorfeld angelegten InfoObjects. InfoObjects können aber auch selbst als DataProvider Verwendung finden um die Erstellung von Stammdatenberichten, die auf Merkmalsattributen basieren, zu ermöglichen.

Das SAP BW bietet verschiedene InfoObject-Typen an, welche im Folgenden charakterisiert werden:

- Merkmals-InfoObjects können verschiedene Werte eines Datentyps annehmen, die Merkmalsausprägung. Diese Menge an Werten beschreibt zulässige Ausprägungen eines Ordnungsbegriffs, z.B. Kunde, Kundengruppe, Land, Region, Geschäftsjahr, usw. Neben einem identifizierenden Schlüsselfeld enthält das InfoObject auch manchmal weitere Texte und beschreibende Attribute. Die Merkmale sind Kriterien nach denen sich die Kennzahlen eines DataProviders auswerten und sortieren lassen. Wie oben bereits erwähnt kann das InfoObject auch als Auswertungsdatenbasis dienen
- Kennzahlen-InfoObjects dienen der Speicherung von Zahlen, die Auswertungen in Berichten ermöglichen. Unterschieden werden Kennzahlen für Mengen, Beträge und Stückzahlen
- Einheiten-bzw. Währungs-InfoObjects ergänzen Kennzahlen um eine Mengeneinheit oder Währung
- Zeitmerkmale dienen dazu einen Zeitbezug für die Auswertungen herstellen zu können, bspw. anhand von Kalenderjahr, Fiskaljahr, Kalendertag, Quartal usw.

Der Business Content[2] liefert eine Reihe vorgefertigter InfoObjects für bestimmte Zwecke aus. Diese InfoObjects erkennt man daran, dass ihr technischer Name mit 0 beginnt, z.B. 0CALYEAR für Kalenderjahr oder 0QUANTITY für Menge.

Wie bereits erwähnt dienen die InfoObjects zum Aufbau der verschiedenen InfoProvider. In der Folge werden die InfoProvider mit Ihren Besonderheiten beleuchtet.

1.1.2 DataStore-Objekte

DSOs definieren eine flache Datenstruktur, die InfoObjects zusammenfasst und ist mit einer Datenbanktabelle vergleichbar, die verschiedene Felder bzw. Spalten enthält. Jedoch kann das System, je nachdem welcher DSO-Typ verwendet wird, mehrere Tabellen erzeugen um die Typfunktionalität zu ermöglichen.

Folgende DSO-Typen werden von SAP BW zur Verfügung gestellt:

- Standard-DSO
- schreiboptimiertes DSO
- DSO für direktes Schreiben

Ein Standard-DSO besteht nicht nur aus einer Tabelle. Das System erzeugt zum einen eine Tabelle für die aktiven Daten, also für die aktuelle dem Reporting zur Verfügung stehenden Daten, eine Tabelle für die neuhinzugekommen Daten, die erst durch die Aktivierung in die für das Reporting verfügbaren Daten übernommen werden und das Change Log, dass alle Änderungen protokolliert.

Standard-DSOs ermöglichen nicht nur die Übernahme von Änderungen aus den neuen Daten in aktive Daten, es können durch den Abgleich von alten mit neunen Inhalten sog. Delta-Informationen erzeugt werden und somit die Veränderungen separat gespeichert werden.[3]

Die neunen Daten werden häufig auch als „Activation Queue“ bezeichnet. Die folgende Abbildung zeigt die einzelnen Teilschritte beim Datenladen in ein Standard-DSO auf:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Schritte des Datenladens(Wolf & Yamada, 2010, S. 142)

Daten können aus verschiedenen Quellen parallel geladen werden 1). Hierbei können auch verschiedene Deltaverfahren zum Einsatz kommen. Die „Activation Queue“ (neue Daten) speichert die noch zu aktivierenden Daten 2). Während des Aktivierungsprozesses werden Change-Log-Informationen generiert 4) und es werden auch SID-Werte für alle neuen Merkmalsausprägungen erzeugt 5). Darüber hinaus werden natürlich die aktiven Daten selbst um die neuen Daten erweitert 3). Das Change Log kann dazu dienen, weitere InfoProvider mit Delta-Informationen zu versorgen 6). Der Schlüssel der neuen Daten die SID der Request-Nr. und die Package-ID im Schlüssel, damit sichergestellt ist, dass der Aktivierungsvorgang parallelisiert werden kann, ohne das die Reihenfolge der Änderungen verändert wird.

Ein schreiboptimiertes DSO ist spezialisiert auf die Speicherung von Rohdaten. Der Aktivierungsmechanismus wird bei dieser Art von DSO nicht verwendet. Und es gibt keine Tabelle mit aktivierten Daten somit stehen die Daten direkt zur Verfügung. Der Haupteinsatzbereich für diesen DSO-Typ sind sog. „Pass-through-Szenarien“: Durch das Wegfallen der Aktivierung können die Daten schnell „durchgereicht“ werden. Somit kann man dieses DSO voll in den Datenfluss integrieren und eine Archivierung der Daten vornehmen und ein schreiboptimiertes DSO kann die Änderungshistorie über das Feld 0RECORDMODE vollständig und exakt abbilden und an im Datenfluss darüber liegende InfoProvider weitergeben.

DSO für direktes Schreiben sind anders als Standard-DSOs oder schreiboptimierte DSOs nicht vollständig in den Datenfluss integriert. Zwar können sie im Datenfluss als Quelle verwendet werden, das Beschreiben erfolgt aber über eine selbstentwickelte ABAP-Routine, über einen vordefinierten Funktionsbaustein oder mit dem Analyseprozess-Designer[4] (APD).

Zusammenfassend kann man folgende Einsatzzwecke darlegen:

- Daten sollen quellsystemnah abgelegt werden
- Daten sollen bereinigt und konsolidiert werden
- Ergebnisse müssen zwischen gespeichert werden
- Daten sollen auf Vorrat und möglichst allgemein abgespeichert werden

Der folgende Abschnitt betrachtet InfoCubes. InfoCubes stehen im Mittelpunkt der Datenhaltung im SAP BW bzw. einem Data Warehouse im Allgemeinen. Sie stellen die eigentliche Datenbasis für das Reporting und deren optimale Implementierung ist der auschlaggebende Faktor für die Akzeptanz seitens des Endanwenders.

1.1.3 InfoCubes

Ein Data Warehouse hat die Aufgabe für entscheidungsunterstützende Systeme eine Datenbasis zur Verfügung zu stellen. Auf dieser Datenbasis werden unterschiedlichste Anwendungen realisiert, von einfachen Standardberichten über Online-Analysen bis hin zu speziellen Analysen und Data-Mining Auswertungen. Im Besonderen stellt die Online-Analyse hohe Anforderungen an die Antwortzeiten der Berichte, die vor allem durch die geeignete Implementierung des Datenmodells beeinflusst werden. Wird auf aggregierte Daten oder auf einen großen Umfang an Daten zurückgegriffen, sollte eine flüssige Navigation durch die Daten mit möglichst kurzen Antwortzeiten gewährleistet werden. Hierzu kommt in einem Data Warehouse die OLAP[5] -Technologie zum Einsatz.

Der OLAP-Server ist eine Komponente des BW Servers. Er vermittelt zwischen Endanwender und der Datenbank indem er Frontend-Werkzeugen, sowohl SAP- als auch Drittanbieter-Werkzeugen, die multidimensional aufbereiteten Daten zur Verfügung stellt. Die Daten werden, soweit eben möglich, im Hauptspeicher vorgehalten und bei Bedarf aus der Datenbank nachgelesen. Für diese Verarbeitung ist insbesondere der OLAP-Prozessor verantwortlich.

Die folgende Abbildung[6] beleuchtet die Stellung und die Aufgaben des OLAP-Prozessors innerhalb der Datenverarbeitungsprozesse bei der Durchführung von multidimensionalen Analysen:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Integration des OLAP-Prozessors in SAP BW, Quelle(SAP AG, Help - OLAP)

Der Zugriff und die Darstellung der Daten erfolgt über den Business Explorer (BEx), Business Objects Tools oder anderen Abfragewerkzeugen von Drittanbietern. Für den Anschluss von Frontend-Werkzeugen stehen die folgenden Schnittstellen zu Verfügung:

- OLE DB für OLAP (ODBO)
- OLAP BAPI (Business Application Programming Interface)
- XML for Analysis (XML/A)

Die Schnittstellen stellen über die multidimensionale Abfragesprache MDX (MultiDimensional Expressions) Daten bereit und ermöglichen somit auch die wesentlichen Funktionen des OLAP-Prozessors, die in der folgenden Tabelle[7] aufgelistet sind:

Tabelle 1: Ausgewählte Funktionen des OLAP-Prozessors

Abbildung in dieser Leseprobe nicht enthalten

Ein klassischer Weg ein OLAP-fähiges Datenmodell in einer relationalen Datenbank abzubilden ist mit Hilfe eines „Star“-bzw. „Snow Flake“-Schemas, das den in SAP BW verwendeten InfoCubes zu Grunde liegt. Hier werden um eine zentrale Faktentabelle beschreibende Dimensionstabellen sternförmig angeordnet. Die Faktentabelle beschreibt die Kennzahlen und deren direkte Zuordnung zu allen wesentlichen Entitäten. Die Dimensionstabellen beschreiben die Entitäten näher und liefern weitere Zusatzinformationen. Da die Faktentabelle die eigentlichen Geschäftsdaten enthält und die Dimensionstabellen eigentlich nur beschreibende Merkmale, hat die Faktentabelle bei weitem mehr Einträge. Die performante Datenabfrage ist nur möglich, da durch Selektionskriterien die Abfrage zunächst auf den kleinen Datenbanktabellen (Dimensionstabellen) eine Vorselektion von relevanten Entitätsschlüsselwertpaaren stattfinden kann. Somit wird ein „Join“ nur für relevante Datensätze vorgenommen. Dieser Vorteil geht verloren, wenn aufgrund von ungeeigneter Modellierung eine oder mehrere Dimensionstabellen zu groß werden. Um diesem Sachverhalt entgegen zu wirken hat die SAP ein erweitertes Star-Schema[8] bzw. Snow-Flake-Schema im SAP BW implementiert (s. Abbildung 3):

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Erweitertes Sternschema SAP Quelle:(SAP AG, Help)

Hier halten die Dimensionstabellen selbst nicht die Stammdaten, sondern separate Tabellen sog. Stammdatentabellen. Hier wird eine Redundanzminimierung durch Normalisierung erreicht. Somit hat man beide Vorteile: eine Leseoptimierung und eine Speicherplatzoptimierung.

Nur das Datenmodell eines InfoCubes ist im Hinblick auf das performante Lesen von großen (Bewegungs-)Datenmengen optimiert. Daher kommt diesem Datenmodell in der Modellierung des Reporting Layers (siehe Kapitel 1.2) eine große Bedeutung zu.

Da InfoCubes Datenabfragen performant unterstützen sollen, dient hierzu im ersten Schritt die Modellierung in Form eines erweiterten Star-Schemas, wie oben bereits beschrieben, und die automatische Indizierung der entsprechenden Tabellen. Das SAP BW bietet aber noch zusätzliche Möglichkeiten[9] die Performanz des Cubes zu erhöhen:

- Modellierung kleiner Dimensionstabellen
- Bildung von Aggregaten
- Komprimierung
- Partitionierung
- geeignete Parametrisierung des OLAP Cache
- gegebenenfalls Einsatz des BWA[10]

Die Queries (Datenabfragen) werden nicht direkt auf den InfoCube definiert, hierzu empfiehlt die SAP den Virtual Layer (siehe Kapitel 1.2) zu verwenden, also eine Schicht, die die sogenannten Virtual Provider vorhält. Diese Schicht speichert selbst keine Daten und hat nur Sichten auf den Datenbestand. Dies hat den Vorteil, dass bei (nahezu) Echtzeitdatenverbuchung, kein physischer Datenbestand für das Reporting aufgebaut werden muss und somit die Daten einfach schneller für das Reporting zur Verfügung stehen.

Abschließend kann man zusammenfassen, dass das SAP BW eine Vielzahl verschiedener DataProvider zur Verfügung stellt, wobei jeder einen spezifischen Einsatzbereich hat.

DSOs speichern die Daten in einer flachen Struktur um Daten Schritt für Schritt aufzubereiten. Standard-DSOs implementieren einen Mechanismus zum Aktivieren von Daten und zur Generierung von Delta-Informationen. Da DSOs nur bedingt als Basis für Berichte geeignet sind kommen an dieser Stelle InfoCubes zum Einsatz. Neben InfoCubes, die die Daten physisch vorhalten, gibt es noch Virtual Provider, die nur eine Struktur ohne eigene Datenhaltung beschreiben. In Abgrenzung zu Virtual Providern sind MultiProvider eine übergreifende Sicht auf mehrere InfoProvider (DSOs, InfoCubes, usw.). Stammdaten spielen die wichtigste Rolle in einem Datenmodell und es ist deshalb wichtig diese datenmodellübergreifend abzustimmen und zu harmonisieren.

Um die oben angesprochenen Aspekte zu standardisieren hat die SAP mit der Layered Scalable Architecture eine Referenzarchitektur entwickelt, die einen Rahmen für die Implementierung bereitstellt. Das Ziel der Referenzarchitektur ist die Implementierung zielgruppenorientierter und kundenindividueller gestalten zu können. Im nächsten Kapitel wird das Konzept der LSA vorgestellt.

1.2 Referenzarchitektur des SAP Business Warehouse – Layered Scalable Architecture (LSA)

Das vorhergehende Kapitel hat die einzelnen Bausteine eines BW-Datenmodells vorgestellt. Theoretisch kann man die einzelnen DataProvider gemäß seinen Anforderungen flexibel kombinieren, dementsprechend steigt auch die Anzahl möglicher Datenmodelle. Nun stellt sich die Frage welche Kriterien ein gutes Datenmodell ausmachen. Diese Frage versucht das Konzept der LSA[11] zu beantworten.

Die Referenzarchitektur der SAP berücksichtigt die Anforderungen an eine große Data-Warehouse-Implementierung. Hierzu gehören unter anderem die Anforderungen an eine hohe Verfügbarkeit des Systems (24/7), eine zeitnahe Bereitstellung der Daten mit hohen Datenvolumina und einer sich stetig ändernden Umgebung.

Die zentralen Bestandteile der Architektur bezeichnet die SAP als Grundgerüst (Landmark Building Blocks). Bestandteile dieses Grundgerüsts, die die spätere Implementierung grundlegend beeinflussen, sind:

- Schichten und Datenmodell
- Domänen
- Datenintegration

Zusätzlich zum Grundgerüst sind sogenannte Hilfsgerüste (Assistant Building Blocks) definiert und ergänzen die Landmark Building Blocks:

- Datenqualitätsprozesse
- BW-Landschaft
- Extraktion, Transformation, Load (ETL)
- Speicherung/Archivierung
- Organisation und Vorgehensweise
- Entwicklungs-Betriebsprozesse

Das Hilfsgerüst bestimmt die Architektur nicht in dem Maße wie das Grundgerüst dennoch werden die verschiedenen Themen kurz angeschnitten.

1.2.1 Schichtenmodell der Referenzarchitektur

Das Schichtenmodell der Referenzarchitektur besteht aus sieben bzw. acht (Virtualization Layer ist Bestandteil des Reporting Layer) Data-Warehouse-Schichten, wobei jede Schicht eine bestimmte Aufgabe übernimmt. Jede Schicht bietet bestimmte Dienste (Services) an, die wiederum von anderen Schichten in Anspruch genommen werden können.

[...]


[1] Vgl.(Wolf & Yamada, 2010), S.91 ff.

[2] Vgl.(Wolf & Yamada, 2010), S.199 ff

[3] Vgl.(Wolf & Yamada, 2010), S.141 ff

[4] Anwendung zur Erstellung und Ausführung von Analyseprozessen mit verschiedenen Analysemethoden, z.B. Regressionsanalyse, Entscheidungsbaum oder Cluster-Analyse

[5] Vgl. Online Analytical Processing,(SAP AG, Help - OLAP)

[6] Vgl.(Schröder, 2006), S. 256

[7] Vgl.(Schröder, 2006), S. 257

[8] Vgl.(SAP AG, Help - Erweitertes Starschema)

[9] Vgl.(Wolf & Yamada, 2010), S.151

[10] BWA – Der Business Warehouse Accelerator hält Datenindizes im Arbeitsspeicher vor und unterstützt so das schnellere Laden der Daten

[11] Vgl.(Wolf & Yamada, 2010), S. 162ff

Details

Seiten
55
Jahr
2014
ISBN (eBook)
9783656655893
ISBN (Buch)
9783656655886
Dateigröße
3.1 MB
Sprache
Deutsch
Katalognummer
v273340
Institution / Hochschule
Fachhochschule Worms
Note
1,3
Schlagworte
SAP HANA SAP BW Business Warehouse; Datenmodellierung

Autor

Teilen

Zurück

Titel: Auswirkungen der Umstellung eines SAP Business Warehouse auf SAP HANA