SAP Data Builder Tutorial (Part 1)

SAP Datasphere's Data Builder is the primary workspace where consultants and data engineers construct the semantic and physical data layer that other tools consume. Before Data Builder existed as a distinct area, cloud modeling in earlier SAP Cloud Platform tools was fragmented; Datasphere consolidated table definition, view building, and entity-relationship modeling into one space-scoped interface. Understanding 'why' matters because most project failures in early Datasphere adoption stem from teams treating Data Builder like a simple query tool rather than a governed modeling layer that feeds SAC stories, planning models, and potentially federated consumption by other BTP services.

The Data Builder operates inside a space (a tenant-level container with its own storage, memory quota, and security boundary). Every object you create in Data Builder—tables, graphical views, SQL views, entity-relationship models, or analytic models—belongs to exactly one space, and objects can only be shared across spaces through an explicit space-sharing action, not by default. This is a deliberate architectural choice: it prevents accidental cross-space coupling and forces conscious data governance decisions.

The main object types you will encounter: (1) Local Tables, which are physical tables you can populate manually, through file upload, or via replication flows from source connections; (2) Remote Tables, virtual representations of tables in remote sources that can operate in either replicated or federated (virtual) access mode; (3) Graphical Views, built using a drag-and-drop canvas with nodes for projection, join, union, aggregation, and rank operations, ultimately compiled into an underlying SQL view definition; (4) SQL Views, for consultants who prefer or need hand-written SQL logic that the graphical canvas cannot easily express; (5) Entity-Relationship Models, which define business entities, relationships (associations), and cardinalities in a way that generates or aligns with underlying tables; (6) Analytic Models, which define measures, dimensions, and calculated elements on top of a fact source, forming the layer most directly consumed by SAC as a live data source.

The runtime flow matters for beginners to visualize: data lands as tables (physical or virtual), gets shaped through graphical/SQL views into a reusable semantic layer, and is finally exposed through an analytic model or view marked 'expose for consumption,' which becomes visible to SAC's data source picker or to other Datasphere spaces. Nothing is consumable outside the space until that explicit exposure flag is set—this is a common point of confusion for new users who build a perfectly good view and then can't find it in SAC.

Deployment context: this is a purely cloud (SAP Datasphere, formerly SAP Data Warehouse Cloud) concept; there is no on-premise ECC or S/4HANA equivalent to Data Builder itself, although Datasphere can connect to S/4HANA systems as a data source via remote tables. Consultants coming from BW/4HANA backgrounds should not assume InfoObject or InfoProvider concepts map one-to-one; Data Builder's model is closer to a modern ELT/semantic-layer pattern than classic BW modeling, though similarities exist in the use of associations and hierarchies.

A retail analytics team onboarding SAP Datasphere spent their first sprint building graphical views for sales data but could not see any of them in SAC. Investigation revealed that none of the views had been marked with the 'expose for consumption' setting, and the team had also not shared the space with the SAC-connected space used by the reporting team. The fix involved a short governance session clarifying that Data Builder objects are private-by-default at both the space and object level, after which the team documented a checklist: build view, validate output, expose for consumption, confirm space sharing, then hand off to SAC modelers.

• Assuming a completed view is automatically visible in SAC without setting it as exposed for consumption
• Building all objects in one shared 'catch-all' space instead of separating raw, harmonized, and consumption layers
• Confusing remote tables with local tables and not understanding replicated versus federated access implications on freshness and performance
• Treating entity-relationship models as purely diagrammatic when they also drive object generation and association behavior
• Not checking space storage/memory consumption early, leading to unexpected capacity issues later in the project

• Establish a layered space strategy (e.g., raw/staging, harmonized, consumption) before building objects
• Use naming conventions that indicate object type and layer (e.g., T_ for tables, V_ for views, AM_ for analytic models)
• Explicitly document which objects are exposed for consumption and to which spaces they are shared
• Validate object output with sample data before marking it exposed
• Avoid building directly against production source connections without a staging layer for large or frequently changing datasets

Interviewers commonly ask candidates to explain the difference between a table, a view, and an analytic model in Datasphere, and why exposure and space-sharing are separate governance steps. A strong answer distinguishes the physical layer (tables), the transformation layer (views), and the consumption layer (analytic models/exposed views), and explains that space isolation is a deliberate multi-tenant governance mechanism, not an oversight.