Semantic Modeling in SAP Datasphere
Build a governed semantic layer that defines business concepts once and exposes them consistently to SAC, Power BI, Tableau, and Python. Datasphere's graphical and SQL-based modeling objects—graphical views, analytic models, associations, hierarchies, and seamless planning with SAC—provide the foundation for trustworthy, reusable analytics across your entire platform stack.
The Datasphere Semantic Modeling Stack
Datasphere transforms raw data into trusted analytics through a layered semantic architecture. Data flows from sources into the platform, passes through replication and federation layers, gets organized into local and remote tables, then emerges as graphical views, SQL views, and analytic models that power your business layer. From there, consumption tools—SAC, Power BI, Tableau, and custom applications—expose analytics to decision-makers.
Analytic Models: Star Schema for Analytics
The analytic model is Datasphere's answer to dimensional modeling. It combines fact tables (transactions, events, measures) with dimension tables (products, customers, dates, locations) in a classic star schema. Analytic models expose measures, dimensions, semantic types, associations, and hierarchies to SAC through live connections and to external tools through the OData API.
Fact Tables
Contain measures (quantity, revenue, cost, discount) and references to dimensions. Represent business transactions at the lowest granularity.
Dimensions
Describe entities (product, customer, date, location). Include attributes and hierarchies for drill-down analysis.
Measures
Calculated or atomic metrics exposed for aggregation in dashboards. Examples: revenue, unit_count, gross_margin_pct.
Semantic Types
Classify each entity by semantic usage — Fact, Dimension, Text, Hierarchy, Hierarchy with Directory, or Relational Dataset — and each column by semantic type (for example an amount with its currency, or a date). This tells SAC and other tools how to render columns and apply default aggregations.
Associations
Define relationships between fact and dimension tables (like foreign keys). Datasphere uses associations to enable drill-down in SAC and automatic joins in queries.
Hierarchies
Multi-level drill paths. Example: Country → State → City → Customer. SAC dashboards inherit these hierarchies for interactive exploration.
Datasphere Modeling Objects: From Raw Data to Ready-to-Use
Six Core Modeling Objects
Datasphere provides six primary modeling objects to organize your semantic layer. Each addresses a different use case in the journey from raw data to consumption.
Graphical Views
Drag-and-drop interface for joining tables, applying filters, and creating projections. No SQL required. Ideal for straightforward semantic joins and transformations that business analysts can own and maintain.
SQL Views
Write custom SQL for complex transformations, window functions, and calculations. Full expressiveness for data engineers and analysts comfortable with SQL syntax.
Analytic Models
Star schema with fact and dimension tables, semantic types, associations, and hierarchies. The primary object for exposing analytics to SAC, Power BI, Tableau, and external consumers.
Entity-Relationship Models
Design tables, views, and the associations between them on one canvas. Useful for documenting and building the relational structure of a domain before it reaches analytic models.
Data Flows
Graphical orchestration of table transformations. Combine multiple sources, apply business logic, and load results into tables for downstream modeling.
Transformation Flows
Load data from source tables or views into a target table through a graphical or SQL transformation, with delta support and, in file spaces, Spark-based processing. The persisted, delta-aware option for heavy transformations.
Semantic Layer Governance and Exposure
Business Layer: Governed Definitions
The business layer—analytic models and the governed definitions in them—provides definitions that are reusable across all consumption tools. When finance changes the revenue calculation, it changes once in the analytic model, and every dashboard built on it, in SAC or in tools reading it through OData, picks up the change on its next query or refresh.
Data Persistence Options
Datasphere supports multiple persistence strategies to balance freshness, performance, and cost:
- Local Tables: Data replicated into Datasphere's storage. Full query capability, optimal performance for analytics.
- Remote Tables: Federation mode. Query source systems directly without replication. Fresher data and no storage cost, but slower for large aggregations.
- Replicated Tables: Remote tables can also be replicated as scheduled snapshots or in real time where the connection supports it. Hybrid approach for large datasets where you replicate frequently accessed fact data but leave slowly-changing dimensions remote; persisted views add a further option by storing the result of an expensive view.
Exposure Mechanisms
Datasphere exposes semantic models through multiple channels so different tools and use cases can be served:
- Live Connection (SAC): Real-time access to Datasphere analytic models. Stories built on live connections show current data but depend on network latency.
- OData API: Standardized REST API for any client (Python, JavaScript, external BI tools), for analytic models as well as views. Respects the model's semantics, such as measures and variables.
- SQL / ODBC: Database users read views exposed for consumption through SQL (ODBC/JDBC) from Power BI, Tableau, and custom applications; analytic models reach external tools through the OData API.
- Row-Level Security (RLS): Data access controls apply row-level security to the views and analytic models they protect, including when those objects are consumed in SAC or shared to other spaces. Test every exposure path (OData, SQL) with sample users so people see only data they are authorized to access.
Seamless Planning with SAC
With seamless planning, SAC planning models store their fact and master data directly in a Datasphere space (SAC on SAP HANA Cloud, tenants linked one-to-one). Planners enter data in SAC; it lands in Datasphere, where it is available read-only for views, analytic models, and transformation flows—closing the loop between plan and actuals.
Key Principles for Datasphere Semantic Modeling
Define revenue once in the business layer. All dashboards, reports, and analyses use the same definition. When the definition changes, it propagates everywhere.
Semantic models are versioned, documented, and maintained by assigned stewards. Changes to critical measures require review and communication.
Every measure is traceable back to source systems. Datasphere's impact and lineage analysis traces objects back to their sources so you can audit compliance and debug errors.
Model at the detail level that supports actual business questions. Avoid both under-granular (losing detail needed for drill-down) and over-granular (unnecessary complexity).
When finance, sales, and marketing all use the same customer dimension and revenue measure, they get consistent answers. Inconsistency is expensive and erodes trust.
A slow semantic layer gets bypassed. Persist or partition large facts, denormalize where needed, and test query performance early. Governance means nothing if dashboards time out.
Migration from BW Semantic Models to Datasphere
Enterprises with SAP Business Warehouse (BW) have existing semantic layers in the form of InfoObjects (dimensions), InfoCubes and DSOs (facts), and calculated KPIs. Datasphere provides clear mapping paths and migration tooling to modernize these structures.
BW → Datasphere Mapping
- BW InfoObjects → Datasphere Dimensions: BW customer and product InfoObjects map to Datasphere dimensions. Attributes and hierarchies map to dimension attributes and hierarchy entities, usually with some redesign.
- BW InfoCubes / DSOs → Datasphere Analytic Models: The multidimensional structures in BW become fact views and analytic models in Datasphere with the same semantic meaning but with modern graphical and SQL tooling; BW queries can be brought across with model transfer or the Query Template Generator, within limits.
- BW Calculated KPIs → Datasphere Calculated Measures: Complex BW KPIs and calculated measures are expressed in Datasphere measure definitions with explicit documentation.
- BW Hierarchies → Datasphere Hierarchies: BW drill hierarchies (product line → family → product) become Datasphere dimension hierarchies with the same structure.
Most enterprises migrate in phases. Identify the most critical measures (revenue, cost, customer) and dimensions (date, product, customer, region), migrate those first with pilot SAC users, then progressively migrate less critical structures. During transition, you might run both BW and Datasphere semantics in parallel, with a planned retirement date for BW.
Semantic Modeling Decision Tree
When building a new model, ask three questions to determine the right tool: What is the source data? How will it be consumed? How much transformation is needed?
When to use Graphical Views
Characteristics: Source data is already clean. Transformation is light (joins, filters, projections). Team prefers visual tools over SQL.
Use case: Join customer master to account transactions. Filter to active customers. Project customer name, account balance, region.
Pros: No SQL required. Business analysts can own. Fast to build. Cons: Complex logic (for example window functions) is easier in SQL.
When to use SQL Views
Characteristics: Transformation is complex. Need window functions, aggregations, or conditional logic. Team is comfortable with SQL.
Use case: Calculate month-over-month revenue growth. Rank customers by spend. Identify top 10% spenders with conditional rules.
Pros: Full SQL expressiveness. Handles any transformation. Cons: Requires SQL knowledge. Harder for non-technical users to modify.
When to use Analytic Models
Characteristics: Data is ready for consumption. Need semantic types, hierarchies, and associations. Multiple downstream consumers (SAC, BI tools, APIs).
Use case: Star schema with sales facts (revenue, quantity) and dimensions (product, customer, date). Expose via live connection to SAC and OData to Power BI.
Pros: Semantic richness. Hierarchies enable drill-down. Reusable across tools. Cons: Requires dimensional thinking. More upfront design work.
Real-World Modeling Example: Sales Analytics
Walk through building a complete sales analytics model in Datasphere, from source data to dashboard-ready consumption.
Step 1: Source Integration
Sales transactions live in S/4HANA sales documents (VBAK, VBAP). Customer master is in customer info records (KNA1). Product master is in material master (MARA). Replicate them into Datasphere as local tables—preferably through released CDS extraction views with a replication flow rather than raw tables. Refresh daily.
Step 2: Transformation with SQL View
Build a SQL view that:
- Joins sales documents to customer master and product master
- Calculates line-item revenue (quantity × price) and cost (quantity × unit cost)
- Derives gross margin (revenue - cost)
- Filters to only completed sales (document type and status)
- Handles currency conversion to reporting currency
Step 3: Analytic Model with Star Schema
Create an analytic model with:
Step 4: Business Semantics
Apply semantic types and business rules:
- Revenue and Quantity are facts (additive measures)
- Gross margin % is a calculated measure (sum revenue - sum cost) / sum revenue
- Customer and Product are dimensions (non-additive)
- Date is a time dimension
- Define default aggregation (sum for revenue and cost); margin % is calculated after aggregation, never averaged
Step 5: Consumption & Exposure
The analytic model is now ready for consumption:
- SAC live connection: Executives build dashboards with drill-down hierarchies
- OData API: Python data scientists query revenue by customer segment for ML models
- SQL / ODBC or OData: Power BI reads the underlying views exposed for consumption (or the analytic model through OData) and builds interactive reports
- Row-level security: Sales reps see only their territory's data in SAC and in every other exposure path you have tested
Model Stacking: Composable Semantic Layers
Advanced Datasphere implementations build models on top of models—stacking semantic layers to encapsulate business logic at different abstraction levels. This approach, called model stacking, improves maintainability and enables reusability. Since 2025, Datasphere supports it natively: an analytic model can use another analytic model as its source and inherit its definitions (at release, within one space).
In practice, I've seen organizations establish three layers:
Layer 1: Core Semantics (Foundation)
Fundamental business definitions that rarely change. Examples: Customer master with standard attributes and hierarchies. Product master with category hierarchies. Date dimension with fiscal calendar. Financial GL with account hierarchies. These core models are versioned heavily and treated as platforms—many downstream models depend on them.
Layer 2: Domain Composites (Mid-Level)
Domain-specific models that combine core semantics with domain logic. Finance domain builds Revenue Analytic Model on top of Sales fact (core) + GL Account (core) + Customer (core). Supply Chain domain builds Inventory Analytic Model on top of Material (core) + Warehouse Location (core) + Movement Transactions (domain). These models are domain-owned and change when domain requirements change, but rarely impact other domains.
Layer 3: Business Views (Consumption)
Task-specific views built for particular audiences. Example: A CFO dashboard might composite the Revenue model + Inventory model + Headcount model to show "Revenue per FTE by region." A sales rep dashboard might composite Revenue model + Customer model for territory performance. These views are lightweight and can be refreshed without rebuilding underlying models.
Model stacking eliminates duplication. Instead of 20 teams each defining "revenue" slightly differently, one Finance domain owns the Revenue model. When the definition changes, everyone updates automatically. It also makes debugging easier: if a number is wrong, you trace it through the stack and identify which layer introduced the error. In my experience, stacking also slows down modeling initially (more governance overhead) but accelerates analytics velocity long-term (fewer definitions to maintain, more confidence in numbers).
Joule and AI-Assisted Discovery
Joule — SAP's generative-AI copilot, generally available in SAP Datasphere since the first quarter of 2026 — lets data professionals navigate the platform, get answers about functionality (with references to the documentation) and about objects in their tenant, and execute tasks in conversational language. It is a copilot for the people who build and run the semantic layer, not a natural-language query engine over analytic models. Natural-language questions about the data itself are answered in the consumption layer, and the Business Data Cloud agentic capabilities announced at SAP Sapphire 2026 (data-product search and creation, generated analytical and planning models, natural-language insights) were in private preview at the time of this review.
What AI-Assisted Discovery Depends On
Whether a question comes through Joule while modeling or through a natural-language feature in the consumption layer, the AI has to map business terms (revenue, customer, segment) to the right objects, measures, and dimensions. It can only do that reliably when the semantic layer is well described.
This capability requires rich metadata. The semantic layer must include:
- Business descriptions: Not just "REVENUE_AMT" but "Total transaction revenue, net of discounts and returns, in reporting currency"
- Synonyms: Users might say "sales," "revenue," or "net income"—all should map to the correct measure
- Relationships: When a user asks for "revenue by segment," the system must know which models contain both revenue (measure) and customer segment (dimension)
- Context: Is the user asking about ytd revenue, monthly revenue, or the revenue forecast? Context clues in the question guide semantic resolution
Practical Application: Self-Service Analytics for Business Users
Natural-language access breaks down barriers between data and business users. The goal is that a sales manager can ask "Which customers in EMEA have declined by more than 10% this quarter?" without writing SQL or waiting for an analyst to build a dashboard. That only works when the Revenue model's measures, dimensions, and descriptions are unambiguous—the semantic work in Datasphere is what makes such answers trustworthy.
From a practitioner perspective, this requires investment in metadata governance. You cannot build natural language search on top of poorly-described data. But the ROI is high: organizations that invest in semantic richness unlock self-service analytics that scales without proportionally increasing the analytics team.
Packaging Semantic Models as Data Products
Data products in Business Data Cloud add operational semantics to curated data. A custom data product is built in the Data Sharing Cockpit from local tables in a file space—not by wrapping an analytic model—and published to the catalog with documentation and, since September 2026, terms of use and steward approval. (Data Product Studio was announced with general availability planned for H1 2026, but GA had not been confirmed at the time of this review.) A data product is not just a model—it is curated data plus operational commitments.
When a domain publishes a data product alongside its Datasphere analytic model:
- The analytic model defines dimensions and measures for in-house consumption
- The data product packages the curated local tables with an owner, documentation, and your version number, SLA (refresh frequency, availability target), and quality indicators (completeness %, freshness)
- Consumers discover the data product in the Business Data Cloud catalog, read its documentation, SLA, and quality indicators, and request access under its terms of use before deciding to build on it
- When the data product changes, your release process notifies consumers and announces deprecations for breaking changes
- BDC Connect shares the data product zero-copy with Databricks, Snowflake, and Google BigQuery (Microsoft Fabric in public preview), together with its metadata, so every platform reads the same definitions
This "semantic models as data products" approach unifies the governance layer and analytic layer. Organizations that invest in semantic richness are best placed to package and govern data products—and to share them across platforms with BDC Connect.
Performance Optimization for Large Datasets
Semantic models that serve high-volume queries need careful optimization. Apply these practices early to avoid painful refactoring later.
1. Dimension Table Design
Keep dimension tables lean. Include only attributes needed for reporting. Move historical tracking (slowly-changing dimensions) to separate tables if it causes bloat. Test join performance with fact tables containing 500M+ rows.
2. Granularity Decisions
Model at the lowest atomic level (daily, transaction). Pre-aggregate only if queries are too slow. Document why aggregates exist. Monitor whether aggregates are actually used; retire unused ones.
3. Measure Calculation Strategy
Store atomic measures in the fact table (revenue, quantity, cost). Calculate derived measures at query time (margin %, growth %). Pre-calculate only if calculation is complex and used heavily. Use Datasphere calculated measures for reusable formulas.
4. Persistence, Partitioning & Analysis
Persist expensive views and partition large local tables and persisted views (for example by date). Analyze slow views with the View Analyzer and execution plans (PlanViz), and watch expensive statements in the System Monitor.
5. Data Persistence Strategy
Replicate hot data (current fiscal year, active customers). Use remote tables or file spaces (object store) for historical archives (years 1-5). Hybrid approach reduces storage while keeping performance. Monitor replication cost vs. remote query cost.
6. Testing & Monitoring
Load-test models before production rollout with realistic query patterns. Monitor average query time. Set SLAs (e.g., 95th percentile < 5 seconds). Alert on performance degradation. Track which queries are slowest and optimize accordingly.
Common Semantic Modeling Mistakes
The Semantic Layer as Data Governance Foundation
A modern data governance program rests on the semantic layer. Governance includes data quality, lineage, access control, and stewardship. The semantic layer is where you define what data means (governed definitions), trace where it comes from (lineage), control who uses it (row-level security), and ensure it is accurate and consistent.
Without semantic modeling, governance is fragmented. Each team maintains its own definitions. Compliance audits find multiple conflicting sources of truth. The semantic layer consolidates governance into one place: Datasphere. This is why Datasphere semantic modeling is not a technical detail—it is a business capability that enables trust, compliance, and scalable analytics.