Konzeptkarte

SAP-BW/4HANA-aDSO-Typen (Standard, schreiboptimiert, Direct-Update)

Stand 18. Oktober 2026

Redaktion: Cédric Mary, alleiniger Redakteur und verantwortlich für die Veröffentlichung — 27 Jahre im SAP-Ökosystem. Wie diese Seiten entstehen und wo Automatisierung eingesetzt wird.

Was ist SAP-BW/4HANA-aDSO-Typen (Standard, schreiboptimiert, Direct-Update)?

Die Wahl des falschen aDSO-Typs ist der häufigste Modellierungsfehler in BW/4HANA — ein Standard-aDSO mit 500 Mio. Zeilen und täglicher Aktivierung ist langsam und teuer, wo ein schreiboptimiertes Staging, das in eine Standard-Schicht einspeist, schnell und günstig wäre.

Worum es geht

Das Advanced DataStore Object (aDSO) ist der einzige physische InfoProvider in SAP BW/4HANA — der moderne Ersatz für die Vielzahl an DSO, InfoCube und PSA aus BW 7.x. Jedes aDSO ist eine einzige HANA-seitige Tabelle; was es wie ein DSO, einen Cube oder einen Staging-Bereich verhalten lässt, ist die bei der Erstellung gewählte Typeinstellung. In der Praxis sind drei Betriebstypen relevant, und die Wahl des falschen Typs ist der häufigste Modellierungsfehler, den ein junior Berater in BW/4HANA macht.

Die drei Typen. Das Standard-aDSO ist das Arbeitspferd schlechthin: Es besitzt eine Inbound-Queue (neue und geänderte Datensätze), eine Active Table (der aktuelle korrekte Zustand, dedupliziert nach Schlüssel) und ein Change Log (die Delta-Historie für die nachgelagerte Weitergabe). Es unterstützt Aktivierung, Vorher-/Nachher-Image-Deltas und Rollback. Das ist es, was 80 % der Modellierung auf der Business-Schicht benötigen. Das schreiboptimierte aDSO besitzt nur die Inbound-Queue — keine Aktivierung, kein Change Log, keine Schlüsseleindeutigkeitsprüfung; Datensätze werden beim Eintreffen einfach angehängt. Es ist das Staging-Bereich-Muster: schnell laden, nachgelagert transformieren. Das Direct-Update-aDSO besitzt nur eine über die Planungs-API beschreibbare Active Table; es ist die Persistenzschicht der Planungsanwendung, geschrieben von SAC Planning oder IBP, nicht per ETL.

Die Wahl ist operativ entscheidend, da Aktivierungskosten, Speicherbedarf und Delta-Weitergabeverhalten allesamt vom Typ abhängen. Ein Standard-aDSO mit 500 Millionen Zeilen und täglicher vollständiger Aktivierung ist langsam und teuer; dieselben Daten in einem schreiboptimierten Staging-aDSO mit nachgelagertem Standard-aDSO für die Business-Schicht sind schnell und günstig. Umgekehrt bricht die Modellierung einer Planungspersistenz als Standard-aDSO den Write-Back-Kreislauf von SAC.

Warum es zählt

Das Standard-aDSO (Aktivierung, Deltas, Rollback) deckt 80 % der Modellierungsanforderungen der Business-Schicht ab; das schreiboptimierte aDSO ist reines Staging-Muster ohne Aktivierung oder Schlüsselprüfung.
Das Direct-Update-aDSO existiert ausschließlich für Planungspersistenz, die von SAC Planning oder IBP geschrieben wird — dies als Standard zu modellieren bricht den Write-Back-Kreislauf vollständig.
Die Performance-Beschwerde, die ‚kein noch so umfangreiches HANA-Tuning behebt‘, lässt sich fast immer darauf zurückführen, dass Standard verwendet wurde, wo schreiboptimiert hingehört hätte.

Kernpunkte

Standard-aDSO — Inbound-Queue + Active Table + Change Log; Aktivierung, Vorher-/Nachher-Deltas, Rollback; Standardtyp der Business-Schicht (80 % der Anwendungsfälle).
Schreiboptimiertes aDSO — nur Inbound-Queue; keine Aktivierung, kein Change Log, keine Schlüsseleindeutigkeit; Staging-Bereich / PSA-Ersatz.
Direct-Update-aDSO — nur Active Table, beschreibbar über die Planungs-API; Persistenz für SAC Planning / IBP; nicht für ETL.
Kosten der falschen Typwahl — Standard für Staging = langsame und teure Aktivierung; Standard für Planung = bricht Write-Back; Wahl beim Design treffen, spätere Umgestaltung ist schmerzhaft.
Eine physische HANA-Tabelle pro aDSO — der Typ ist Metadatenkonfiguration, keine separate Objektart; Feldstruktur und Partitionierungsstrategie werden weiterhin pro Objekt gewählt.
Die Aktivierungskosten sind proportional zur Größe des Delta-Batches, zur Schlüsselbreite und zum Change-Log-Fan-out — nicht zur Gesamtzeilenzahl; deshalb behebt „mehr HANA“ selten ein falsch typisiertes InfoProvider.
Bei einer BW/4HANA-Konversion haben InfoCubes keinen Eins-zu-eins-Nachfolger: ein reiner Reporting-InfoCube konvertiert zu Standard; einer mit heimlicher Staging-Funktion sollte in schreiboptimiert + Standard aufgeteilt werden.
Die Active Table eines korrekt typisierten Standard-aDSO ist auch das günstigste Objekt, um es als BDC-Data-Product oder Knowledge-Graph-Grounding-Quelle zu veröffentlichen — die Typwahl überlebt das BW/4HANA-System selbst.

Begriffe auf dieser Seite

aDSO: Advanced DataStore Object — die vereinheitlichte InfoProvider-Klasse in BW/4HANA, die DSO/InfoCube/PSA aus BW 7.x ersetzt; eine HANA-Tabelle pro Objekt, deren Verhalten über den Typ konfiguriert wird.
Inbound-Queue: Der Staging-Puffer neuer und geänderter Datensätze vor der Aktivierung; persistiert die rohe Ladeausgabe; die einzige physische Schicht, die in einem schreiboptimierten aDSO vorhanden ist.
Aktivierung: Die Operation des Standard-aDSO, die Inbound-Queue-Datensätze nach Schlüssel in die Active Table konsolidiert, Deltas berechnet und das Change Log schreibt; der teure Schritt beim BW/4HANA-Laden.
Change Log: Die Vorher-/Nachher-Image-Historientabelle innerhalb eines Standard-aDSO; die Quelle für die nachgelagerte Delta-Weitergabe; das, was die Delta-Kette von BW funktionieren lässt.
Active Table: Die deduplizierte Tabelle im aktuellen Zustand innerhalb eines Standard- oder Direct-Update-aDSO, geschlüsselt nach dem Geschäftsschlüssel des Objekts — der Datensatz, den Abfragen tatsächlich lesen.
Delta-Batch: Die Menge neuer oder geänderter Datensätze, die in einem einzelnen Aktivierungslauf verarbeitet wird; ihre Größe, nicht die Gesamtzeilenzahl des InfoProviders, treibt die Aktivierungskosten.
Planungs-API: Die Schreibschnittstelle, über die SAC Planning und IBP direkt in die Active Table eines Direct-Update-aDSO posten und dabei den Standard-ETL-Pfad aus Laden und Aktivieren vollständig umgehen.
Typ-Mapping (BW/4HANA-Konversion): Die Objekt-für-Objekt-Entscheidung, die bei einer Konversion von BW 7.x zu BW/4HANA getroffen wird, zu welchem aDSO-Typ ein bestehender DSO oder InfoCube wird; InfoCubes haben keinen automatischen Eins-zu-eins-Nachfolger.

Quellen

Vollständige Karte für Mitglieder. Was die vollständige Karte ergänzt: den vollständigen Entscheidungsrahmen · den Vergleich SAP · Snowflake · Databricks · Fabric · die häufigen Fallstricke und ihre Behebung · die Kurzreferenz · die Architekturschemata · die Codeblöcke · die zitierfähigen Kennzahlen.

In der App öffnen →

Offene SAP-Projekte

Aktuelle SAP-Analytics-Projekte und Stellen im DACH-Raum: SAP-Analytics-Projekte im DACH-Raum.