Local Tables

Local Tables sind eigene Tabellen in einem Space (abgeschottetem Arbeitsbereich) von SAP Datasphere, deren Daten physisch in der darunterliegenden Datenbank SAP HANA Cloud gespeichert werden. Sie sind das Gegenstück zu Remote Tables, die keine Daten kopieren, sondern bei jedem Zugriff auf ein Quellsystem (z. B. ein SAP-ERP) durchgreifen.

Was sind Local Tables?

Local Tables bezeichnen einen konkreten Objekttyp (also einen Baustein-Typ) im [Data Builder](/insights/glossar/data-builder/) von SAP Datasphere: eine klassische Datenbank-Tabelle mit Zeilen und Spalten, die zu einem bestimmten Space gehört und deren Datensätze dauerhaft in der Datenbank abgelegt sind. Im Data Builder erscheinen sie als „Table" vom Typ „Local"; davon abgegrenzt ist der Typ „Remote", der nur einen Verweis auf ein Quellsystem darstellt. Technische Grundlage ist [SAP HANA Cloud](/insights/glossar/hana-cloud/), die Datenbank hinter Datasphere: dort wird jede Local Table als echte Tabelle im Bereich des Space angelegt und wie eine gewöhnliche Datenbank-Tabelle gepflegt.

Befüllt werden Local Tables über die Datasphere-eigenen Bausteine: Replication Flows für Extract-and-Load aus SAP- oder Non-SAP-Quellen, Transformation Flows für Delta-basierte Umformungen, [Data Flows](/insights/glossar/data-flow/) als Fallback-Objekttyp und Open-SQL-Procedures für datenbanknahe Logik. Ergänzend erlaubt das Open-SQL-Schema eines Spaces direkten SQL-Zugriff aus externen Tools, die dann in dieselben Local Tables schreiben.

Pro Local Table lässt sich die Storage-Klasse wählen und damit die Position im Datasphere-Tiering-Modell steuern. Der In-Memory Column Store hält heiße Daten hauptspeicherresident für schnelle OLAP-Zugriffe; die Native Storage Extension (NSE) legt warme Daten auf Disk ab und lädt sie über einen Buffer-Cache bedarfsgetrieben in den Hauptspeicher. Beide Klassen bleiben aus Sicht des Konsumenten dieselbe Tabelle im Space; der Unterschied liegt im Kosten- und Latenzprofil. Local Tables existieren als eigener Begriff, weil Datasphere-Spaces bewusst zwischen kopierten und verlinkten Datenbeständen trennen. Die Wahl des Objekttyps entscheidet über Datenhaltung, Aktualisierungsrhythmus, Governance und Verrechnung.

Abgrenzung: Remote Tables, Virtual Tables, Delta Table, Open-SQL-Tabelle

Die häufigsten Verwechslungen entstehen an drei Stellen: gegenüber dem Datasphere-Objekttyp Remote Table, gegenüber Virtual Tables in HANA Cloud selbst und gegenüber der Delta Table aus der Databricks-Welt. Zusätzlich lohnt die Trennung von der reinen Open-SQL-Schema-Tabelle innerhalb desselben Spaces.

Die Entscheidung Local vs. Remote fällt zwei Ebenen: fachlich (wird der Datenbestand für Reporting und Modellierung im Space gebraucht, mit definierter Aktualität?) und kommerziell (wird HANA-Cloud-Speicher belegt oder Data-Integration-Load auf ein Quellsystem verlagert?). Beide Objekttypen können in derselben Modellierung koexistieren; die Wahl ist keine Grundsatzfrage, aber pro Tabelle bewusst zu treffen.

Beispiel: Local Table mit Tiering im Finance-Space

Ein Datasphere-Space „Finance" konsumiert täglich die Buchhaltungssalden aus einem angebundenen S/4HANA-System. Ein Replication Flow überträgt die aktuellen Perioden per Change-Data-Capture in eine Local Table FI_GL_Balances_Hot im In-Memory Column Store. Historische Salden älter als 24 Monate liegen auf einer zweiten Local Table FI_GL_Balances_Cold mit Storage-Klasse Native Storage Extension. Eine Union-View im Data Builder abstrahiert beide Tabellen zu einem einheitlichen Zugriffsobjekt, das der Business Builder als Fact-Basis für Analytic Models einsetzt.

Ein zweiter Standardfall ist der Ziel-Container einer Transformation. Ein Transformation Flow liest aus einer Staging-Local-Table SD_Order_Items_Raw, wendet eine Provisions-Regel an und schreibt in die Ziel-Local-Table Provision_pro_Beleg, die anschließend im Business Builder als Kennzahlenbasis dient. Die Entscheidung, das Transformationsergebnis als Local Table statt als Remote Table oder View zu materialisieren, folgt der Häufigkeit der Konsum-Zugriffe: bei mehrfachen Reports pro Tag lohnt die Persistierung; bei einmaliger Auswertung wäre eine [View-Persistency-](/insights/glossar/data-tiering/)Materialisierung oder ein reines View-Objekt der günstigere Weg.

Die kommerzielle Wirkung wird im [SAP-Datasphere-Pricing-Guide](/insights/sap/sap-datasphere/pricing-guide/) sichtbar: Local Tables verbrauchen HANA-Cloud-Speicher, die Storage-Klasse steuert die Kosten (In-Memory teurer als NSE), und die Beladung erzeugt Data Integration Hours. Remote Tables verlagern beides in das Quellsystem und in den Federation-Zugriff.