Konzeptkarte

SAP Datasphere — Open-SQL-Schemas

Stand 6. 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 Datasphere?

Open SQL Schemas sind eine Bring-your-own-SQL-Ausweichlösung innerhalb des Governance-Perimeters von Datasphere — Tabellen dort erhalten weder Catalog-Auffindbarkeit noch Lineage noch Modellunterstützung, sodass ihre Nutzung als Standard einen Tenant ohne semantische Schicht zurücklässt.

Worum es geht

Ein Open SQL Schema ist ein SAP-Datasphere-Konstrukt, das ein Standard-SAP-HANA-Cloud-Datenbankschema direkt für autorisierte Nutzer und externe Tools freigibt — es umgeht die Modellierungsschicht von Datasphere und erlaubt Entwicklern, natives HANA-SQL (DDL + DML) auszuführen, beliebige HDBSQL-/JDBC-Clients anzubinden und HANA-Entwicklertools gegen Tabellen einzusetzen, die dennoch zum Speicher- und Governance-Perimeter des Datasphere-Space gehören. Es ist die Bring-your-own-SQL-Ausweichlösung, wenn die grafischen Modellierungsoberflächen von Datasphere für einen bestimmten Anwendungsfall zu restriktiv sind.

Wozu Open SQL Schemas dienen. Sie sind die Antwort auf drei wiederkehrende Bedürfnisse. Native HANA-Entwicklung: der Aufbau von HANA Stored Procedures, Calculation Views mit SQLScript oder HANA-nativen Anwendungen innerhalb des Datasphere-Governance-Perimeters — ohne eine erneute Implementierung im Transformation Flow von Datasphere. Direkter Zugriff externer Tools: die direkte Anbindung von SAP Analysis for Office, Drittanbieter-BI-Tools oder eigenen Python-/R-Skripten an ein Schema, ohne den Umweg über die Consumption Views von Datasphere. Code-first-ETL: Data Engineers schreiben DDL- und DML-Skripte, um Daten über codegesteuerte Pipelines (git-versioniert) zu laden und zu transformieren, statt über den Flow-Editor von Datasphere.

Der Kompromiss. Open SQL Schemas existieren im selben HANA-Cloud-Tenant neben den Modellierungsschemas von Datasphere; sie teilen sich die Speicherkapazität, den Sicherheitsperimeter und denselben Arbeitsspeicher. Doch Inhalte innerhalb eines Open SQL Schema profitieren nicht vom Katalog, der Lineage oder den fachlich-semantischen Funktionen von Datasphere — es ist reines HANA-SQL, mit der Disziplin, die das mit sich bringt. Tabellen hier sind nicht automatisch im Katalog auffindbar; die Lineage endet an der Schemagrenze; analytische Modelle können nicht direkt auf Open-SQL-Schema-Tabellen aufgebaut werden (sie müssen zunächst über eine Datasphere-View freigegeben werden).

Warum es zählt

Sie lösen drei reale Bedürfnisse — native HANA Stored Procedures, direkten Zugriff externer Tools (SAP Analysis for Office, Drittanbieter-BI, Python/R) und git-versioniertes Code-first-ETL.
Die Lineage endet an der Schemagrenze, und analytische Modelle können nicht direkt auf Open-SQL-Schema-Tabellen aufgebaut werden — sie müssen zunächst über eine Datasphere-View freigegeben werden.
Der häufigste Fehler ist, standardmäßig das Open SQL Schema als primäre Modellierungsschicht zu nutzen statt Datasphere-Spaces, lokaler Tabellen und Views.

Kernpunkte

Direkter HANA-Cloud-Schemazugriff innerhalb eines Datasphere-Space — natives SQL (DDL + DML), HDBSQL-/JDBC-Clients, HANA-Entwicklertools.
Drei Anwendungsfälle — HANA-native Entwicklung von Prozeduren/Views; direkter Zugriff externer Tools (Analysis for Office, BI-Tools, Python/R); Code-first-ETL mit git-versionierten Skripten.
Teilt sich Speicher, Sicherheit und Arbeitsspeicher mit den Datasphere-Modellierungsschemas im selben Tenant — aber der Inhalt ist NICHT im Katalog, die Lineage endet an der Schemagrenze.
Analytische Modelle können nicht direkt auf Open-SQL-Schema-Tabellen aufgebaut werden — zunächst über eine Datasphere-View freigeben.
Anti-Pattern — Open SQL Schema als primäre Modellierungsschicht; zunichte macht den semantischen und Lineage-Mehrwert von Datasphere.
Open SQL Schema ist der Ort für die Engineering-Arbeit einer HANA-Cloud-RAG-/Vektor-Pipeline (natives SQL, NLP-Funktionen, Embedding-Aufrufe) — aber eine dort entstandene Tabelle ist für den Datasphere-Catalog (C127) unsichtbar und kann keinen Joule-Agenten erden, bevor sie nicht in eine Datasphere-View übergegangen ist.
Das Zwei-Sprung-Muster für KI wie für BI: in Open SQL Schema entwickeln (Code, Git, schnelle Iteration), eine schlanke Datasphere-View als einzige Schnittstelle veröffentlichen, die jeder Konsument oder Agent lesen darf.
Eine View-Schicht zwischen dem rohen Schema und seinen Konsumenten bedeutet, dass sich die interne Struktur des Schemas ändern kann (neue Spalten eines neu trainierten Modells), ohne jeden nachgelagerten Bericht oder Agenten zu brechen — die View absorbiert die Änderung.

Begriffe auf dieser Seite

Open SQL Schema: Ein SAP-Datasphere-Konstrukt, das ein Standard-SAP-HANA-Cloud-Datenbankschema direkt für autorisierte Nutzer und externe Tools freigibt und dabei die Modellierungsschicht von Datasphere umgeht; für HANA-native Entwicklung und Code-first-Muster innerhalb des Datasphere-Governance-Perimeters.
HDBSQL: Der SAP-HANA-Kommandozeilen-SQL-Client; der kanonische Weg, natives SQL gegen ein Open SQL Schema von einer Entwickler-Workstation oder einer CI-Pipeline aus auszuführen.
Consumption View: Ein Datasphere-Objekt, das eine kuratierte, fachlich-semantische Sicht auf zugrunde liegende Tabellen für nachgelagerte analytische Modelle bereitstellt; der kanonische Weg, Open-SQL-Schema-Inhalte für analytische Modelle freizugeben.
Bring-your-own-SQL: Das Architekturmuster, Entwicklern neben einer übergeordneten Modellierungsoberfläche direkten SQL-Zugriff bereitzustellen; SAP Datasphere setzt dies über Open SQL Schemas um.
hdbcli: SAPs HANA-Python-Treiber; der übliche Weg für einen Data Engineer, natives SQL zu skripten und externe APIs (einschließlich SAP AI Core) gegen ein Open SQL Schema aus Code heraus aufzurufen.
Vektortabelle (HANA Cloud): Eine Tabelle in HANA Cloud mit einer Vektor-typisierten Spalte für Embeddings, üblicherweise innerhalb eines Open SQL Schema als Teil der Engineering-Arbeit einer RAG-Pipeline erstellt und befüllt, dann über eine Datasphere-View für Grounding freigegeben.
Schnittstellenstabilität: Die Eigenschaft, die eine Datasphere-View bietet, indem sie zwischen einer rohen Open-SQL-Schema-Tabelle und ihren Konsumenten sitzt — die interne Struktur der rohen Tabelle kann sich weiterentwickeln, ohne die veröffentlichte, konsumierte Form zu brechen.

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.