Konzeptkarte

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

Stand 2026-07-23

Redaktion: Cédric-Olivier Mâry, 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.

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.
SAP-BW/4HANA-aDSO-Typen (Standard, schreiboptimiert, Direct-Update) sind erst dann beherrscht, wenn sie eine benannte Käuferentscheidung verändern.
Beginnen Sie mit dem semantischen Vertrag und dem Kontrollmodell, bevor Sie das Tool vorführen.
Nutzen Sie aktuelle SAP-, Analysten-, Studien-, KG- und Nachrichtensignale als Beleg, nicht als Dekoration.
Trennen Sie verifizierte Fakten von richtungsweisenden Trends und modellierten Annahmen.
Definieren Sie Owner, Metrik, Schwellenwert, Support-Pfad und Rollback, bevor Sie skalieren.

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.
Entscheidungsträger: Die verantwortliche Person, die den Trade-off akzeptiert und die nächste Maßnahme finanziert.
Semantischer Vertrag: Die gemeinsame Definition von Geschäftsbegriffen, Metriken, Entitäten und Zugriffsregeln, die von Tools und Teams verwendet wird.
Kontrollebene: Die Schicht, die Richtlinien, Zugriff, Herkunftsnachweis (Lineage), Monitoring und Eskalation im gesamten Betriebsmodell durchsetzt.
Evidenzgrad: Eine Kennzeichnung, die verifizierte Fakten, richtungsweisende Signale, modellierte Annahmen und Feldbeobachtungen voneinander trennt.

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.

In der App öffnen →