Skip to main content

01. SAP Datasphere Foundations

Learning objective​

By the end of this phase, you should be able to explain SAP Datasphere to a technical or business stakeholder without relying on product jargon.

You should be able to answer:

  • What is SAP Datasphere?
  • Why does an enterprise need it?
  • What problem does it solve?
  • How is it different from a traditional data warehouse, data lake, database, and BI tool?
  • What is a tenant?
  • What is a space?
  • What are Data Builder, semantic modeling, catalog, and data integration?
  • What is the difference between virtual access and persisted data?
  • How does Datasphere fit with S/4HANA, BW/4HANA, BW Bridge, HANA Cloud, SAC, and non-SAP platforms?
  • When should Datasphere be used — and when should another platform be used?

The objective is not to memorize definitions. The objective is to build a mental model that remains useful when the product evolves.

1.1 What is SAP Datasphere?​

SAP Datasphere is SAP's cloud data platform for bringing together data integration, data warehousing, semantic modeling, cataloging, and workload virtualization.

The important word is together.

A Datasphere implementation is not simply:

Load some SAP tables and create a report.

A mature implementation creates a governed path from source systems to business-ready data.

A useful logical model is:

Sources
  ↓
Connectivity
  ↓
Acquire / Federate / Replicate
  ↓
Prepare / Harmonize
  ↓
Semantic Model
  ↓
Expose / Consume
  ↓
Analytics / Applications / Data Products

Cross-cutting the entire platform:

Security
Governance
Metadata
Monitoring
Lifecycle
Performance

SAP positions Datasphere as a unified service for data integration, cataloging, semantic modeling, data warehousing, and virtualizing workloads across SAP and non-SAP data.

That positioning is important because Datasphere is neither just a database nor just a reporting layer.

1.2 The problem Datasphere is designed to solve​

Enterprise data is normally fragmented.

A large organization may have:

  • SAP S/4HANA
  • SAP ECC
  • SAP BW/4HANA
  • SAP SuccessFactors
  • SAP Ariba
  • SAP Concur
  • SAP HANA
  • relational databases
  • cloud data warehouses
  • data lakes
  • SaaS applications
  • files
  • APIs
  • operational applications
  • third-party analytics platforms

The problem is not merely storing this data.

The harder problems are:

  1. How do we connect to it?
  2. How do we move only what is necessary?
  3. How do we preserve business meaning?
  4. How do we combine SAP and non-SAP data?
  5. How do we avoid multiple conflicting versions of the same KPI?
  6. How do we control who can access sensitive records?
  7. How do we make data discoverable?
  8. How do we expose governed data to analytics consumers?
  9. How do we operate the platform reliably?
  10. How do we modernize without destroying existing SAP investments?

Datasphere addresses these problems as an integrated cloud data service.

1.3 Datasphere is not a BI tool​

A common beginner mistake is:

Datasphere = backend for SAC.

That is too narrow.

SAC can consume data from Datasphere, but Datasphere has responsibilities before consumption:

Source integration
       ↓
Data acquisition
       ↓
Transformation
       ↓
Harmonization
       ↓
Semantic modeling
       ↓
Governance
       ↓
Consumption

SAC is primarily a consumption and analytics experience.

Datasphere is a data platform.

They are complementary.

1.4 Datasphere is not simply HANA Cloud​

Datasphere uses SAP HANA Cloud technology, but the products should not be treated as interchangeable.

Think about the abstraction level:

HANA Cloud​

Primarily a cloud database and application data platform.

Datasphere​

An enterprise data service that provides data integration, warehousing, semantic modeling, cataloging, sharing, and governed consumption capabilities.

A useful mental model is:

HANA Cloud
    = database technology

Datasphere
    = governed data platform

This distinction becomes important when deciding whether a requirement belongs in HANA Cloud, Datasphere, SAP Analytics Cloud, SAP BW Bridge, SAP Business Data Cloud, or another platform.

1.5 Datasphere and SAP Business Data Cloud​

Modern SAP architecture increasingly needs to be understood in the context of SAP Business Data Cloud.

SAP positions Datasphere as a central component of Business Data Cloud and continues developing Datasphere for Business Data Cloud use cases.

Do not interpret this as:

Datasphere is being replaced.

The better mental model is:

SAP Business Data Cloud
        |
        +-- Datasphere
        |
        +-- SAP-managed / governed data products
        |
        +-- SAP analytics and AI ecosystem
        |
        +-- Other BDC capabilities

The exact service composition evolves over time, so this course treats BDC integration as an architectural topic rather than a fixed product diagram.

1.6 Business Data Fabric​

Datasphere is strongly associated with the business data fabric concept.

A business data fabric is not simply another storage technology.

Its purpose is to connect distributed data while preserving:

  • business meaning
  • relationships
  • context
  • governance
  • discoverability
  • trust

Imagine that procurement data lives in S/4HANA, supplier information lives in another system, and logistics data lives in a third platform.

A technical data integration can join records.

A business data fabric aims to make the resulting information understandable as a business concept.

For example:

Supplier
   |
   +-- Supplier ID
   +-- Supplier Name
   +-- Country
   +-- Purchasing Organization
   +-- Spend
   +-- Contract
   +-- Risk

The important result is not merely a joined table.

The result is a governed business view of the supplier domain.

1.7 Datasphere logical architecture​

Do not start by memorizing every application in the UI.

Start with layers.

Layer 1 — Source systems​

Examples:

  • S/4HANA
  • BW/4HANA
  • SAP applications
  • HANA
  • databases
  • files
  • cloud services
  • APIs

Layer 2 — Connectivity​

Connections determine how Datasphere reaches source systems.

Layer 3 — Acquisition​

Data can be:

  • accessed remotely
  • replicated
  • loaded
  • transformed
  • incrementally updated

The correct method depends on workload and source capability.

Layer 4 — Data preparation​

Data may be:

  • filtered
  • joined
  • unioned
  • aggregated
  • enriched
  • cleansed
  • standardized

Layer 5 — Semantic modeling​

The technical dataset becomes business-oriented.

Examples:

  • facts
  • dimensions
  • measures
  • associations
  • hierarchies
  • analytical models

Layer 6 — Governance​

Governance controls:

  • who can access data
  • what data is exposed
  • how data is classified
  • where data originated
  • how objects are shared
  • how data is discovered

Layer 7 — Consumption​

Consumers may include:

  • SAP Analytics Cloud
  • Microsoft Excel
  • BI tools
  • applications
  • APIs
  • data products
  • downstream platforms

1.8 Tenant​

A Datasphere tenant is the cloud environment in which the service operates.

At a conceptual level:

Cloud environment
       ↓
Datasphere tenant
       ↓
Users / Roles / Spaces / Connections / Objects

Do not confuse:

  • tenant
  • space
  • database schema
  • user
  • role

They represent different scopes.

The tenant is the overall environment.

A space is a governed working area inside the tenant.

1.9 Space​

Spaces are one of the most important Datasphere concepts.

SAP documentation describes a space as a secure area in which data acquisition, preparation, and modeling occur.

Think of a space as a governed boundary for a data domain or workload.

Example:

Datasphere Tenant
|
+-- FINANCE
|
+-- PROCUREMENT
|
+-- SALES
|
+-- HR
|
+-- SHARED

But do not blindly create one space per department.

That is a design decision.

Space topology must consider:

  • ownership
  • security
  • lifecycle
  • data sharing
  • isolation
  • workload
  • operating model
  • administration
  • cross-domain reuse

This becomes an architecture topic later in the course.

1.10 Why spaces matter​

Suppose Finance owns sensitive employee compensation data.

If all enterprise users work inside one unrestricted modeling area, security becomes difficult.

A better architecture might establish:

HR Space
   ↓
Protected employee data

Finance Space
   ↓
Financial reporting data

Shared Analytics Space
   ↓
Approved cross-domain data

The shared space should not automatically expose everything from HR or Finance.

Instead, the organization explicitly shares approved entities.

This creates a boundary between ownership and consumption.

1.11 Data Builder​

Data Builder is where many technical modeling activities take place.

It is used to create and manage data objects such as:

  • tables
  • graphical views
  • SQL views
  • analytic models
  • task chains
  • data access controls
  • other modeling objects

The exact object set evolves with the product.

The important architectural concept is:

Data Builder is where technical data structures and transformation logic are designed.

1.12 Graphical modeling​

Graphical views allow data preparation using a visual modeling environment.

Conceptually:

Source A ──┐
           ├── Join ── Filter ── Projection ── Output
Source B ──┘

This approach is useful when:

  • the transformation is easier to understand visually,
  • the team wants low-code modeling,
  • lineage should be visually understandable,
  • business and technical modelers collaborate.

Graphical modeling does not mean no engineering.

Poor graphical models can still create:

  • expensive joins
  • unnecessary columns
  • excessive data movement
  • confusing lineage
  • difficult maintenance

1.13 SQL modeling​

Datasphere also provides SQL-based modeling.

SQL is useful when:

  • transformations are easier to express as code,
  • the team has strong SQL skills,
  • complex logic is required,
  • reusable SQL patterns are appropriate,
  • performance needs to be reasoned about explicitly.

SQL and graphical modeling are complementary.

The question is not:

Which one is better?

The question is:

Which approach best fits the transformation, team, governance, maintainability, and performance requirements?

1.14 Federation versus replication​

This is one of the most important architecture decisions.

Federation​

Data remains at the source.

Datasphere accesses it remotely.

Source Data
    ↑
Remote Access
    ↑
Datasphere

Advantages can include:

  • reduced duplication
  • fresher source data
  • simpler movement

Risks can include:

  • network dependency
  • source-system load
  • unpredictable source performance
  • limited transformation pushdown
  • runtime dependency on source availability

Replication​

Data is copied into Datasphere-managed persistence.

Source
  ↓
Replication
  ↓
Datasphere Storage
  ↓
Transformation / Consumption

Advantages can include:

  • predictable query performance
  • reduced dependency on source runtime
  • better control over analytical workloads
  • easier downstream processing

Trade-offs include:

  • storage
  • data freshness management
  • replication operations
  • duplicate persistence

There is no universal winner.

Architecture decides based on workload.

1.15 Virtual versus persisted data​

A virtual object does not necessarily mean the underlying data is physically copied into Datasphere.

A persisted object has data stored in Datasphere-managed persistence.

A useful decision model is:

Need source freshness?
      |
      +-- Yes → consider federation

Need predictable analytics performance?
      |
      +-- Yes → consider persistence

Need complex transformation?
      |
      +-- evaluate pushdown + persistence

Need source isolation?
      |
      +-- persistence often becomes attractive

Real architecture decisions must also consider:

  • source capability
  • data volume
  • concurrency
  • latency
  • network
  • licensing
  • refresh frequency
  • operational ownership
  • query behavior

1.16 Semantic modeling​

Semantic modeling is what separates a raw technical dataset from a useful analytical model.

Consider:

POSTING_DATE
COMPANY_CODE
GL_ACCOUNT
AMOUNT
CURRENCY

A technical table contains values.

A semantic model explains what those values mean.

For example:

  • Posting Date → calendar dimension
  • Company Code → organizational dimension
  • GL Account → financial dimension
  • Amount → measure
  • Currency → unit/currency context

The semantic layer answers:

What does this field mean?

not merely:

What data type is this field?

1.17 Grain comes before joins​

One of the most important rules in this entire course:

Define the grain before designing the model.

Suppose a sales fact is:

One row = one sales order item

And another table is:

One row = one customer per day

Joining them without understanding grain can multiply records.

Example:

Sales Item
Customer Daily Snapshot
       ↓
Unexpected row multiplication
       ↓
Inflated revenue

The problem is not SQL syntax.

The problem is architecture.

Every major modeling exercise will explicitly document:

  • business grain
  • technical grain
  • keys
  • cardinality
  • measures
  • expected row counts

1.18 Datasphere versus BW/4HANA​

Datasphere and BW/4HANA overlap in data warehousing capabilities, but they are not simply the same product with different deployment models.

A simplified comparison:

AreaBW/4HANADatasphere
Primary modelEnterprise BWCloud data platform
DeploymentSAP BW landscapePublic cloud SaaS
BW modelingDeepAvailable through BW Bridge for applicable scenarios
Non-SAP integrationStrongStrong
Cloud-native operating modelLowerCore design
Semantic modelingStrongStrong
Business data fabricNot its primary positioningCore positioning
BDC alignmentAdjacentCentral

The correct choice depends on:

  • existing investment
  • target operating model
  • migration timeline
  • source landscape
  • business requirements
  • BW-specific requirements
  • cloud strategy

1.19 Datasphere versus a traditional data warehouse​

A traditional warehouse may be designed around:

Extract → Transform → Load → Warehouse → BI

Datasphere supports a broader set of patterns:

Federate
Replicate
Transform
Persist
Model
Share
Govern
Consume

This does not mean traditional warehousing is obsolete.

It means Datasphere provides multiple data access and modeling strategies.

Architects must select the appropriate pattern rather than force every workload through one pipeline.

1.20 Datasphere versus a data lake​

A data lake generally emphasizes inexpensive, scalable storage for diverse data.

Datasphere emphasizes governed enterprise data integration, semantic modeling, warehousing, and business consumption.

They can coexist.

For example:

Operational SAP
      ↓
Datasphere
      ↓
Business semantic layer
      ↓
SAC

Data Lake / Lakehouse
      ↓
Large-scale engineering / ML
      ↓
Datasphere or another consumption layer

The architecture should be driven by workload rather than product ideology.

1.21 Datasphere versus Databricks​

At a high level:

Datasphere tends to be strong when​

  • SAP business semantics are central
  • SAP source integration is important
  • business users need governed semantic models
  • SAC is a major consumer
  • SAP Business Data Cloud is strategic
  • BW modernization is part of the program

Databricks tends to be strong when​

  • large-scale data engineering is central
  • Spark/Python workloads dominate
  • lakehouse architecture is preferred
  • ML/AI engineering is a major workload
  • broad cloud-native engineering is required

They can coexist.

Example:

SAP S/4HANA
     ↓
Datasphere
     ↓
Business semantic layer
     ↓
SAC

Operational / External / Large-scale Data
     ↓
Databricks
     ↓
Data Engineering / ML / AI

The course will not assume that one platform must replace the other.

1.22 Datasphere workload categories​

A useful way to classify workloads is:

Analytical workload​

Example: monthly revenue reporting.

Operational analytics​

Example: near-real-time order monitoring.

Data integration​

Example: ingest S/4HANA sales data.

Data harmonization​

Example: standardize customer master data across regions.

Semantic modeling​

Example: create a governed procurement spend model.

Data product​

Example: publish a supplier performance dataset for multiple domains.

Data sharing​

Example: expose approved finance data to a central analytics space.

Data virtualization​

Example: query source data without full replication.

Data modernization​

Example: move BW workloads into a cloud architecture.

The implementation technique depends on the workload category.

1.23 The five architectural questions​

Before creating any Datasphere object, ask:

Question 1 — Where does the data originate?​

Do not start modeling before identifying the source of truth.

Question 2 — What is the business grain?​

Every model needs a defined grain.

Question 3 — Where should computation happen?​

Possible locations include:

  • source system
  • Datasphere
  • HANA
  • BW Bridge
  • external platform

Question 4 — Who consumes the result?​

The consumer affects:

  • semantics
  • latency
  • model shape
  • security
  • performance

Question 5 — How will it operate?​

Production design must include:

  • monitoring
  • ownership
  • failure handling
  • transport
  • security
  • recovery

1.24 Foundation terminology​

TermMeaning
TenantOverall Datasphere cloud environment
SpaceSecure modeling and data boundary
Data BuilderTechnical data modeling environment
ConnectionConfiguration used to access a source
Remote tableObject providing access to remote source data
Local tableTable persisted in Datasphere
Graphical viewVisual transformation/modeling object
SQL viewSQL-based transformation/modeling object
Data flowGraphical data movement and transformation
Replication flowReplication and acquisition pattern for supported sources
Task chainOrchestration of tasks
Data access controlRow-level security mechanism
Analytic modelConsumption-oriented semantic model
CatalogDiscovery and governance capability
BW BridgeBW capabilities delivered through Datasphere for applicable scenarios
Business Data CloudSAP's broader enterprise data and analytics platform context

1.25 Common beginner mistakes​

Mistake 1 — Treating every source as a replication problem​

Sometimes federation is better.

Mistake 2 — Treating every source as virtual​

Sometimes persistence is required.

Mistake 3 — Modeling without defining grain​

This causes incorrect joins and measures.

Mistake 4 — Creating one giant space​

Space topology should follow governance and operating requirements.

Mistake 5 — Creating one space per table​

That creates administrative and sharing complexity.

Mistake 6 — Building directly for the dashboard​

The analytical model should represent a reusable business concept.

Mistake 7 — Ignoring security until production​

Security must be designed before data is exposed.

Mistake 8 — Assuming SAP data is automatically semantic​

Source metadata helps, but enterprise semantic harmonization is still an architecture responsibility.

Mistake 9 — Using graphical modeling for everything​

SQL can be the better engineering choice for some workloads.

Mistake 10 — Using SQL for everything​

Graphical models can improve maintainability, collaboration, and transparency.

1.26 Architect exercise​

Scenario​

A global company has:

  • S/4HANA for finance
  • S/4HANA for procurement
  • BW/4HANA for historical reporting
  • Salesforce for CRM
  • an external supplier database
  • SAP Analytics Cloud for executive reporting

The company wants a global procurement analytics platform.

Requirements:

  • global supplier spend
  • supplier performance
  • purchase-order cycle time
  • finance reconciliation
  • regional data restrictions
  • daily executive reporting
  • near-real-time operational monitoring
  • future AI use cases

First architecture questions​

Do not design objects yet.

Answer:

  1. What are the systems of record?
  2. Which data must be replicated?
  3. Which data can remain virtual?
  4. What should be the domain boundaries?
  5. What is the grain of spend?
  6. What is the grain of supplier performance?
  7. Where should harmonization occur?
  8. What belongs in Datasphere?
  9. What should remain in BW/4HANA?
  10. Should any workload belong in Databricks or another platform?
  11. What is the security model?
  12. What is the consumption model?
  13. What monitoring is required?
  14. How will historical data be handled?
  15. How will the architecture evolve?

You should not yet be able to answer every question.

That is intentional.

The following phases provide the technical depth needed to answer them.

1.27 Hands-on lab​

Lab: Build the mental model before touching the UI​

Create an architecture document with:

1. Business requirement
2. Sources
3. Data ownership
4. Data grain
5. Integration method
6. Persistence strategy
7. Semantic model
8. Security
9. Consumption
10. Monitoring
11. Failure handling
12. Future evolution

Then draw:

Sources
  ↓
Integration
  ↓
Acquisition
  ↓
Harmonization
  ↓
Semantic Model
  ↓
Consumption

Do not create Datasphere objects yet.

The objective is to prove that you understand the architecture before configuration.

1.28 Interview preparation​

What is SAP Datasphere?​

Strong answer:

SAP Datasphere is SAP's cloud data platform that combines data integration, data warehousing, semantic modeling, cataloging, and virtualization capabilities for SAP and non-SAP data. It is designed to preserve business context and support governed enterprise data consumption.

Is Datasphere a database?​

It includes managed persistence and is built around SAP cloud data capabilities, but it should not be treated as merely a database. Its value is the integrated platform around integration, modeling, semantics, governance, sharing, and consumption.

What is a space?​

A space is a secure environment in Datasphere where users acquire, prepare, model, and manage data according to assigned permissions.

Federation or replication?​

Neither is universally better. The decision depends on freshness, source-system impact, latency, volume, transformation requirements, network characteristics, concurrency, performance, and operating requirements.

Why is semantic modeling important?​

Because enterprise analytics needs business meaning, not just technically correct columns. Semantics define measures, dimensions, relationships, hierarchies, and business interpretation.

How does Datasphere relate to SAC?​

Datasphere provides governed data and semantic models; SAC can consume that data for analytics and planning scenarios. They solve different layers of the architecture.

How does Datasphere relate to BW/4HANA?​

They overlap in data warehousing capabilities but have different architectural positions. BW Bridge provides a path for applicable BW capabilities and investments into the Datasphere public-cloud environment.

1.29 Production checklist​

Before calling a Datasphere solution designed, verify:

  • Source of truth documented
  • Business grain documented
  • Integration method selected intentionally
  • Federation versus persistence decision documented
  • Space ownership defined
  • Security model defined
  • Semantic model defined
  • Consumer requirements understood
  • Performance assumptions documented
  • Monitoring requirements documented
  • Failure behavior understood
  • Lifecycle and transport approach defined
  • Data quality expectations documented
  • Future growth considered

1.30 Final mental model​

Remember:

Datasphere is not where data simply goes. Datasphere is where enterprise data is integrated, organized, semantically understood, governed, and made usable.

The progression is:

Source
  ↓
Connect
  ↓
Acquire
  ↓
Prepare
  ↓
Model
  ↓
Secure
  ↓
Govern
  ↓
Expose
  ↓
Consume
  ↓
Operate

That sequence will remain the backbone of this masterclass.

What comes next​

Phase 02 — Platform & Tenant Architecture

You will move from "What is Datasphere?" to:

  • tenant architecture
  • users
  • global roles
  • scoped roles
  • spaces
  • space administrators
  • modelers
  • integrators
  • resource allocation
  • space sharing
  • cross-space architecture
  • security boundaries
  • tenant operating model
  • development/test/production topology
  • enterprise space design
  • architect-level topology decisions