Konzeptkarte

SAP Datasphere — Open SQL Schemas

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 Datasphere — Open SQL Schemas?

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.

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.
SAP Datasphere — Open SQL Schemas ist erst dann beherrscht, wenn es eine konkret benannte Kaufentscheidung verändert.
Beginnen Sie mit dem semantischen Vertrag und dem Kontrollmodell, bevor Sie das Tool demonstrieren.
Nutzen Sie aktuelle SAP-, Analysten-, Studien-, Knowledge-Graph- und Nachrichtensignale als Beleg, nicht als Dekoration.
Trennen Sie verifizierte Fakten von richtungsweisenden Trends und modellierten Annahmen.
Definieren Sie Owner, Kennzahl, Schwellenwert, Support-Pfad und Rollback, bevor Sie skalieren.

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.
Entscheidungsverantwortlicher: Die verantwortliche Person, die den Kompromiss akzeptiert und die nächste Aktion finanziert.
Semantischer Vertrag: Die gemeinsame Definition von Geschäftsbegriffen, Kennzahlen, Entitäten und Zugriffsregeln, die von Tools und Teams verwendet wird.
Kontrollebene: Die Schicht, die Richtlinien, Zugriff, Lineage, Monitoring und Eskalation über das Betriebsmodell hinweg anwendet.
Evidenzgrad: Eine Kennzeichnung, die verifizierte Fakten, richtungsweisende Signale, modellierte Annahmen und Feldbeobachtungen voneinander unterscheidet.

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 →