SAP Referenzarchitekturen

SAP Referenzarchitekturen

Screenshot-2025-11-14-174950
Der Begriff Data Warehouse gibt nur eine grobe Vorstellung davon, wie ein Warehouse auszusehen hat. Es gibt den Begriff der ETL-Prozesse für alles was mit dem zusammensuchen, aufbereiten und laden der Daten zu tun hat. Es gibt den Begriff des Sternschemas für eine analyseorientierte Datenorganisation und zuletzt den Begriff des Staging für Prozesse innerhalb des Warehouses. SAP bietet mit seinem Business Warehouse nun einen Baukasten für ein geschäftsorientiertes Data Warehouse an, für das es eine Best Praxis Architektur entworfen hat: Die Layered Scalable Architecture. Es ist nur eine Vermutung weil ich nicht weiß, ob es sich jetzt um eine Analogie handelt oder ob ein kausaler Zusammenhang existiert: Pate der Layered Scalable Architecture ist ein Lager, wie es sie in jedem Betrieb gibt.

SAP Layered Scalable Architecture

LSA

Konventionelles DBMS

SAP Layered Scalable Architecture++

LSA++

SAP HANA DBMS

Der Übergang zwischen den Welten ist nicht abrupt vollzogen worden, über Zwischenversionen (7.x) sind die Features sukzessive Eingeführt worden.

Beide Architekturen sind strukturell identisch. Die Unterschiede resultieren aus den universelleren Datenflusselementen und Fähigkeiten der SAP HANA Datenbank.

Unterschiede in den Welten

Jenachdem wie es mir als alten Rentner einfällt wird die Liste ergänzt.

Aus meiner Sicht als Rentner ein nicht zu unterschätzender Punkt für die Architektur des Systems. In der Welt der konventionellen Datenbank läuft die Kommunikation zwischen DBMS und Data Warehouse über eine vom Hersteller des DBMS definierten Schnittstelle. Es sind also im Universum mindestens zwei Welten vorhanden, die über einen Kanal verbunden sind. Das macht eine DBMS recht universell, ermöglicht sie doch dadurch eine Applicationsentwicklung ohne auf Persistenz übermäsig rücksicht nehmen zu müssen. Bei speziellen Anwendungen, wie sie zum Beispiel bei einem Data Warehouse mit seiner analyseorientierten Architekur kann dieses zu Problemen führen, weil die Prozesse aufwendig und langsam sein können.

Da SAP Eigentümer des DBMS ist, kann SAP das Datenbankmanagement an die eigene Bedürfnisse anpassen und muss sich nicht mit einem vorgegebenen Standard begnügen. Dieses betrifft auch die Einbeziehung der Datenbank in die Anwendungen.

Im SAP HANA-Universum findet alles im Arbeitsspeicher statt. Benötigte Daten müssen nicht von mechanischen Drehorgeln oder SSD-Speichern gelesen werden.

In der klassischen BW-Welt praktisch ausgeschlossen: Die direkte Verwendung der Datenbankfunktionalität aus einem Datenfluss heraus. Klassische BW-Systeme bestehen aus einer Datenbank und einem ABAP-Layer, in dem die Engines für den Betrieb des Systems implementiert sind. BW ist ein Offset hierfür. Direkte Zugriffe wie sie im Datenfluss von SAP BW4/HANA möglich sind, waren in der klassischen Welt nicht möglich.

Die Trennung zwischen ABAP-Layer und Datenbank löst sich.

Sind bestimmt durch die Fähigkeiten und Struktur der Datenbank und den daraus resultierenden Modellierungselementen.

Layered Scalable Architecture (LSA)

Konventionelles DBMS

Elemente:

  • InfoObject
  • HybridProvider
  • InfoCube
  • DataStore Objekct
  • PSA
  • CompositProvider
  • MultiProvider
  • InfoSet
  • VirtualProvider

Datenzugriff Quellsysteme:

  • PUT

Layered Scalable Architecture ++ (LSA++)

SAP HANA DBMS

Elemente:

  • InfoObject
  • Advanced DataStore Object
  • Open ODS View
  • CompositProvider

Datenzugriff Quellsysteme:

  • GET

Ebenen SAP Layered Scalable Architecture++ (LSA++)

Layer können, müssen aber nicht verwendet werden.

no images were found

Bereich, in dem eine Kopie der eingegangenen Daten abgelegt wird um eine Historie der Daten zu bekommen. Das Corporate Memory dient dazu, den Datenbestand ohne Zugriff auf die Quellsysteme wieder Aufbauen zu können.

Die Datentemperatur der Daten im Corporate Memory ist kalt, so dass HANA die Daten aus dem Arbeitspeicher auf das Datenarray auslagern kann.

Notwendig ist ein Corporate Memory dann, wenn die Quelle nicht in der Lage ist historische Daten zu liefern oder dieses nicht in ausreichender Qualität kann. Dieses ist oft bei Transaktionalen Systemen wie ERP-Systen der Fall, wo nicht benötigte oft ausserhalb der Quelle inr Archivsystemen aufbewahrt werden um gesetzliche Aufbewahrungsfristen zu erfüllen.

Ebene auf der die eingeganenen Daten aus den Quellsystemen bereinigt und harmonisiert werden.

Fuktional ist die Ebene in beiden Welten gleich.

Ebene der für das Reporting bereitgestellten Daten entsprechend den Vorgaben des Business. Funktional ist die Ebene in beiden Welten gleich, unterscheidet sich jedoch durch die Fähigkeiten der verwendieten Modellierungselemente

  • LSA: Reporting Layer
  • LSA++: Architected Data Marts

In beiden Welten werden die Daten über die Business Transformations aus den persistenten Ebenen des Enterprise-Data-Warehouse-Layer aufbereitet.

Modellierung:

  • LSA: InfoCube, MultiProvider, CompositProvider
  • LSA++: CompositProvider, aDSO
Schlagwörter: ,
Close Menu
error: Content is protected !!