Data Builder Fundamentals: Purpose, Object Types, and Workspace Layout

Explanation

Data Builder is the primary modeling tool inside SAP Datasphere (formerly SAP Data Warehouse Cloud) where consultants and data engineers design the semantic and physical shape of data before it reaches business users in SAP Analytics Cloud (SAC) or other BI tools. Unlike a pure ETL tool, Data Builder blends data integration concepts (bringing data in, transforming it) with semantic modeling concepts (defining dimensions, measures, associations) inside a single workspace scoped to a Space. Why it matters: business users rarely query raw replicated or federated tables directly. Data Builder is where you clean, join, harmonize, and label that raw data into views that are understandable and performant for consumption. Getting this layer right determines whether downstream SAC stories are fast, accurate, and maintainable, or fragile and confusing. Core object types available in Data Builder: 1. Graphical Views - built using a visual, node-based canvas (drag source tables, add joins, unions, projections, aggregations, calculated columns) without writing SQL. Ideal for most business modelers and for transparency/maintainability. 2. SQL Views - written using SQL Editor (SQL as understood by Datasphere's engine). Useful for complex logic that graphical nodes cannot easily express, or for consultants who prefer code-first approaches. 3. Table objects - define physical structures (columns, data types, keys) that can hold data physically persisted in Datasphere, often used as targets for replication flows or manually loaded reference data. 4. Entity-Relationship (ER) Models - a modeling layer to visually define relationships between multiple tables/views, useful for laying out a data model conceptually before or after building views. Workspace layout: Data Builder is scoped per Space (a Datasphere tenant is divided into Spaces representing departments, projects, or environments). Inside a Space, you see a repository list of objects (tables, views, ER models) you can create, edit, and organize into folders. Each object has a design-time definition and a separate deployment status - you build/design first, then explicitly deploy to make it queryable and available in the space's runtime. Key properties you configure on views: exposure for consumption (a toggle that determines whether the view is visible to consuming tools like SAC), semantic usage type (fact, dimension, or relational dataset), and the underlying source objects (which can be local tables, remote tables via connections, or other views - enabling layered modeling). A typical project pattern is layering: raw/staging views close to source structure, an intermediate harmonization layer applying business rules and joins, and a top consumption layer marked with semantic usage and exposed for consumption - keeping each layer's responsibility clear and easing maintenance and impact analysis when sources change. Data Builder does not replace the separate Business Builder layer (used for higher-level business semantics like perspectives and consumption models in some Datasphere editions); rather, Data Builder produces the technical/analytical views that Business Builder or SAC can consume directly or build further semantics upon. Understanding this boundary avoids confusion for beginners about where to model what.

Code example

-- Example: a simple SQL View created in Data Builder's SQL editor-- Purpose: harmonize sales order header data from a remote source table-- into a cleaner shape for downstream graphical views to consume SELECT    "SALES_ORDER_ID"          AS SALES_ORDER_ID,    "CUSTOMER_ID"             AS CUSTOMER_ID,    "ORDER_DATE"              AS ORDER_DATE,    "NET_VALUE"               AS NET_VALUE,    "CURRENCY"                AS CURRENCY_CODEFROM "SRC_SALES_ORDERS"   -- remote table exposed via a connectionWHERE "NET_VALUE" IS NOT NULL; -- This SQL view would then be deployed, and a graphical view built-- on top of it to add currency conversion and join to a customer-- dimension view for full business context.

Real project scenario

A retail analytics team onboarding SAP Datasphere needs to expose harmonized sales data to SAC for a regional performance dashboard. The consultant starts in Data Builder by inspecting remote tables exposed through an existing connection to the source ERP replication flow, creates a staging graphical view to rename and filter unnecessary technical columns, then layers a second view to join customer master data and calculate net revenue in local currency. Only the final layer is marked exposed for consumption so business users in SAC only see the clean, business-friendly view rather than dozens of intermediate technical objects.

Common mistakes

• Exposing every intermediate staging view for consumption, cluttering the SAC model list and confusing business users. • Not understanding the difference between saving a design and deploying it, then wondering why a new view is not visible to consumers. • Mixing raw source column names directly into consumption views instead of renaming them into business-friendly labels early. • Forgetting to set the correct semantic usage type (fact vs dimension), which affects how the view behaves when consumed in analytic models. • Attempting complex transformations entirely in one giant view instead of layering, making the model hard to debug and reuse.

Best practices

• Use a consistent layering convention (e.g., prefixes like STG_, HRM_, CON_) to distinguish staging, harmonization, and consumption views. • Only mark final consumption-layer views as exposed for consumption to keep the SAC model catalog clean. • Prefer graphical views for transparency and easier handover unless SQL logic is genuinely simpler or more powerful for the use case. • Document semantic usage type decisions (fact/dimension) as part of the data model design so downstream analytic model builders understand intent. • Review and rename technical column names to business-friendly labels as early in the layering as practical, not only in the last view.

Interview angle

Interviewers often ask candidates to explain the difference between designing and deploying an object in Data Builder, and why layered modeling (staging, harmonization, consumption) is preferred over building one large monolithic view. Be ready to explain semantic usage types and when you would choose a graphical view versus a SQL view.