Remote Tables

Remote Tables sind Tabellen in SAP Datasphere, die keine eigenen Daten speichern, sondern bei jeder Abfrage direkt aus einem angebundenen Quellsystem (zum Beispiel einem SAP-ERP oder einer klassischen Datenbank) lesen. Sie zeigen also immer den aktuellen Stand der Quelle, ohne dass eine Kopie in Datasphere angelegt wird. Verbunden wird die Tabelle über einen Adapter, ein Verbindungsmodul, das die Anfrage an die Quelle übersetzt. In den meisten Fällen kommt dafür SAP HANA Smart Data Integration (SDI) zusammen mit dem Data Provisioning Agent (DPA) zum Einsatz, einer Software-Komponente, die die Verbindung zu On-Premises-Systemen herstellt.

Was sind Remote Tables?

Remote Tables sind ein Objekttyp im [Data Builder](/insights/glossar/data-builder/), dem Modellierungswerkzeug von SAP Datasphere. Datasphere organisiert seine Inhalte in Spaces (abgegrenzten Arbeitsbereichen für ein Team oder eine Fachdomäne). Innerhalb eines Space taucht eine Remote Table wie jede andere Tabelle auf, mit dem Unterschied, dass ihre Zeilen im Quellsystem verbleiben. Im Data Builder erscheint sie als „Table" vom Typ „Remote". Das Gegenstück heißt „Local" und steht für persistierte Tabellen (Tabellen, deren Daten tatsächlich in Datasphere gespeichert sind) in der zugrundeliegenden [HANA-Cloud](/insights/glossar/hana-cloud/)-Datenbank. Technisch stützt sich jede Remote Table auf eine sogenannte Virtual Table in HANA Cloud, die über den Adapter mit der Quelle verbunden ist. Datasphere ergänzt darum herum eine Verwaltungshülle mit Metadaten, Zugriffsrechten und der Zuordnung zu einer Connection (der eingerichteten Verbindung zum Quellsystem).

Der Zugriff läuft föderiert: Wenn eine Abfrage im Data Builder oder Business Builder eine Remote Table anspricht, generiert die HANA-Cloud-Engine eine Anfrage an den Adapter. Filter, Projektionen und teils Joins oder Aggregationen werden über Query-Pushdown an das Quellsystem verlagert, sodass nur das benötigte Ergebnis zurückkommt. Operationen, die der Adapter nicht abgeben kann, fallen in den lokalen Ausführungspfad zurück und lesen die Zeilen zur Verarbeitung in HANA Cloud. Zwei Adapter-Familien dominieren: die HANA Smart Data Integration mit dem Data Provisioning Agent für Anbindungen an On-Premises-Systeme (etwa SAP-ABAP-Systeme, klassische Datenbanken, Datei-Ablagen) und Smart Data Access für direkte HANA-zu-HANA-Konnektivität.

Der Begriff existiert, weil Datasphere-Spaces zwischen kopierten und verlinkten Datenbeständen unterscheiden. Remote Tables tragen die Verlinkungs-Variante mit drei Effekten: Aktualität ohne Duplikat-Storage, Zugriff jederzeit auf den Quellstand und Verzicht auf HANA-Cloud-Speicherbelegung. Die Gegenseite bilden Netzwerk-Latenz, eine Abhängigkeit von der Erreichbarkeit und Performance des Quellsystems sowie zusätzliche Last dort. Im [Data-Tiering](/insights/glossar/data-tiering/)-Modell von Datasphere besetzt der Objekttyp die „Remote"-Ebene neben Hot, Warm und Cold.

Abgrenzung: Replication Flow, Federation, Transformation Flow, View, Virtual Table

Die häufigsten Verwechslungen entstehen an vier Stellen: gegenüber dem Replication Flow als Kopier-Mechanismus, gegenüber Federation als Oberbegriff, gegenüber Transformation Flow als Verarbeitungsschritt und gegenüber Views als rein logischen Objekten. Zusätzlich lohnt die Trennung von der HANA-Cloud-nativen Virtual Table, die technisch unter der Remote Table sitzt.

Die Entscheidung Remote vs. Local fällt an zwei Punkten: fachlich (soll auf den aktuellen Quellstand zugegriffen werden oder reicht ein definierter Refresh-Zyklus?) und kommerziell (soll HANA-Cloud-Speicher belegt oder die Last dem Quellsystem aufgeladen werden?). Beide Objekttypen können in derselben Modellierung koexistieren und werden pro Tabelle bewusst gewählt.

Beispiel: Remote Table auf S/4HANA-Buchhaltungssalden

Ein Datasphere-Space „Finance" bindet aktuelle Buchhaltungssalden aus einem produktiven S/4HANA-System als Remote Table FI_GL_Balances_Live an. Die Verbindung nutzt den Data Provisioning Agent mit einem SDI-Adapter für ABAP-CDS. Ein Bericht im Business Builder filtert nach Buchungskreis 1000 und Periode 2026-06; SDI reicht beide Filter und die Spalten-Projektion an das S/4HANA-System durch, sodass nur die relevanten Zeilen zurückgeliefert werden. Der Zugriff bleibt tagesaktuell, ohne dass Datasphere Storage belegt oder ein Replikationsjob erforderlich wird.

Für die monatliche Abschlussauswertung wechselt der Space auf Kopie: Derselbe Datenausschnitt wird per Replication Flow in eine Local Table FI_GL_Balances_Snapshot überführt. Grund ist die Zugriffs-Frequenz. Die Abschlussberichte laufen mehrfach am Tag und bei mehreren Analysten parallel; ein wiederholter Föderations-Zugriff würde das S/4HANA-System spürbar belasten und die Antwortzeit von der Netzwerkstrecke abhängig machen. Die Wahl zwischen Remote und Local ist damit eine Verrechnungsfrage zwischen Aktualitäts-Anforderung und Quellsystem-Last, wie sie im [SAP-Datasphere-Pricing-Guide](/insights/sap/sap-datasphere/pricing-guide/) ausführlich durchgerechnet ist.