Open SQL Schema

Ein Open SQL Schema ist eine Zugriffs-Tür zu einem Arbeitsbereich (Space) in SAP Datasphere: Über sie erreichen externe Werkzeuge (Auswertungs-Tools, Skripte, Datenbank-Programme) die Daten direkt per SQL, also der Standard-Sprache für Datenbank-Abfragen. Ohne diese Tür sind die Daten nur über die grafische Oberfläche von Datasphere (den Data Builder) zugänglich.

Was ist ein Open SQL Schema?

Ein Open SQL Schema ist ein optionaler Namensraum (Schema, ein benannter Ordner für Datenbank-Objekte) innerhalb eines [Datasphere-Arbeitsbereichs](/insights/sap/business-data-cloud/) (Space), der pro Space in den Einstellungen ausdrücklich eingeschaltet werden muss. Technisch ist es ein Schema in der darunterliegenden Datenbank [SAP HANA Cloud](/insights/glossar/hana-cloud/) und liegt im selben Space wie die Objekte des Data Builder (der grafischen Modellierungs-Oberfläche). Der Zugang läuft über einen eigenen Datenbank-Nutzer für diesen Space mit einer SQL-Adresse (Host und Port für Datenbank-Verbindungen); angebunden wird per Standard-Datenbanktreiber (JDBC oder ODBC, die üblichen Verbindungs-Bausteine zwischen Anwendung und Datenbank), per Kommandozeile (HDBSQL), per Python-Baustein hdbcli oder direkt aus Auswertungs-Werkzeugen wie Power BI, Tableau und dem Modellierungs-Werkzeug dbt.

Das Open SQL Schema fungiert als Zugriffs-Fassade auf den bestehenden Datenbestand des Space. Alle Objekte darin liegen in derselben HANA-Cloud-Instanz wie die Space-Objekte des Data Builder und teilen sich CPU, Hauptspeicher und Storage mit den anderen Space-Nutzungen. Verrechnung und Ressourcen-Zuteilung erfolgen daher weiterhin auf Space-Ebene über die Datasphere-[Kostenmechanik](/insights/sap/sap-datasphere/pricing-guide/) (Capacity Units, HANA-Cloud-Speicher, Data Integration Hours). Ein Space kann höchstens ein Open SQL Schema haben; der Schema-Name ist im Rahmen der SAP-Namensregeln frei wählbar und wird bei der Aktivierung fixiert.

Der Zugriff funktioniert in beide Richtungen. Datasphere-verwaltete Read-Objekte im Space, insbesondere [Local Tables](/insights/glossar/local-tables/) und persistierte Views, sind für das Open SQL Schema über automatische Grants lesbar. Umgekehrt lassen sich Tabellen, die per SQL im Open SQL Schema angelegt und befüllt wurden, über die Table-Import-Funktion des [Data Builder](/insights/glossar/data-builder/) als Space-Objekt hochziehen und im Business Builder weiterverarbeiten. Damit dient das Open SQL Schema als Kopplungspunkt zwischen externen ELT-Werkzeugen (Python, dbt, Airflow, Fivetran) und der Datasphere-eigenen Modellierungsschicht.

Der Begriff „open" grenzt das Konstrukt vom Datasphere-internen Schema ab, das für User nicht direkt zugreifbar ist. Datasphere generiert intern eigene HANA-Objekte mit systemischen Namen und schützt sie vor externem SQL. Das Open SQL Schema ist der explizit exponierte, Datasphere-verwaltete Zwilling: kontrolliert freigeschaltet, mit lesbarer Namensgebung, aber weiterhin an die Governance-Grenzen des Space gebunden.

Abgrenzung zu Space, Data Builder, Open SQL Procedure und Database Schema

Der Begriff wird häufig mit dem Space selbst, mit dem Data Builder oder mit einer Open SQL Procedure gleichgesetzt. Die folgende Tabelle sortiert die häufigsten Verwechslungen.

Zwei Trennlinien sind für die Einordnung besonders wichtig. Die erste liegt zwischen Space und Open SQL Schema: der Space existiert immer, das Open SQL Schema ist optional und muss aktiv eingeschaltet werden. Ein Space ohne Open SQL Schema ist ein reiner Datasphere-Modellierungs-Container ohne externen SQL-Endpunkt. Die zweite Trennlinie liegt zwischen Data Builder und Open SQL Schema: beide arbeiten auf denselben zugrundeliegenden HANA-Objekten, aber der Data Builder verwaltet Metadaten, Sichtbarkeit und Business-Semantik, während das Open SQL Schema den direkten Datenbankzugriff öffnet und Governance-Regeln nur soweit trägt, wie sie im Datenbank-User verankert sind.

Beispiel: ELT-Ingestion und Data-Builder-Anschluss

Ein Datasphere-Space „Sales" ist so konfiguriert, dass für den Fachbereich ein Analytic Model auf Salesforce-Opportunity-Daten bereitsteht. Die Ingestion läuft über ein Python-Skript, das auf einem AirFlow-Worker außerhalb der SAP-Welt ausgeführt wird und die Salesforce-REST-API konsumiert. Weil Datasphere keinen nativen Salesforce-Replication-Konnektor mit dem gewünschten Delta-Verhalten anbietet, ist die Extraktion und das initiale Laden Aufgabe des Skripts.

Im Space „Sales" ist ein Open SQL Schema mit dem Namen SALES_OPEN aktiviert. Ein Space Database User USR_SALES_ELT besitzt Schreibrechte auf SALES_OPEN. Das Python-Skript öffnet mit hdbcli eine Verbindung zum HANA-Cloud-Endpunkt des Space, legt einmalig die Zieltabelle SALES_OPEN.SFDC_OPPS an und schreibt bei jedem Lauf die veränderten Datensätze in diese Tabelle. Externe Werkzeuge wie dbt oder Airflow eignen sich für dieselbe Rolle; entscheidend ist die Existenz des SQL-Endpunkts als Ingestion-Ziel.

Auf Datasphere-Seite zieht der Data Builder die Tabelle SFDC_OPPS per Table Import in den Space und legt sie als Local Table an. Ab diesem Punkt greifen die Datasphere-Semantik-Werkzeuge: eine Analytic View kombiniert die importierten Opportunity-Daten mit Kundenstammdaten aus einem [Replication Flow](/insights/glossar/data-flow/) aus dem S/4HANA-System, der Business Builder ergänzt Kennzahlen und Dimensionen, das Analytic Model bedient SAP Analytics Cloud. Für Power-BI-Anwender, die keinen Zugriff auf den Business Builder benötigen, öffnet die IT einen zweiten Zugang direkt auf SALES_OPEN über einen weiteren Space Database User mit reinen Leserechten.

Der Space „Sales" verbindet damit drei Zugriffs-Pfade auf dieselbe HANA-Cloud-Grundlage: den Data Builder für Datasphere-native Modellierung, den [Business Builder](/insights/glossar/business-builder/) für Semantik-Aufbau und das Open SQL Schema als offenen SQL-Endpunkt für ELT und externe Konsumenten. Alle drei laufen im selben Ressourcen-Budget des Space und teilen sich denselben Storage-Pool.