Introduction to Business Builder: Purpose and Core Entities
Understand what Business Builder is, why it exists alongside Data Builder, and the core entity types (fact models, consumption models, dimensions) used to create business-friendly semantic layers in SAP Datasphere.
Explanation
SAP Datasphere ships with two modeling personas in mind: technical modelers who use Data Builder to build graphical views, SQL views, and entity-relationship models against raw or transformed data, and business modelers who use Business Builder to assemble business-friendly semantic objects on top of that technical layer. Business Builder exists because many organizations want business analysts, finance power users, or citizen integrators to define reusable business vocabulary—dimensions like Cost Center, Product, or Customer, and fact models like Sales Volume or Actuals—without needing to understand joins, associations, or SQL. This separation of concerns keeps the technical data layer stable and governed by IT/data engineering while giving business teams a safe, guided environment to compose analytical models for consumption in SAP Analytics Cloud stories, planning models, or other BI tools. The two primary entity types in Business Builder are dimensions and fact models (sometimes described together with consumption models). A dimension in Business Builder is a business object that represents a master data perspective—for example a Cost Center dimension pulling attributes like name, hierarchy node, and responsible person from an underlying Data Builder view or table. A fact model represents measures and their relationships to dimensions—for example a Sales fact model that references a Sales Order Data Builder view and associates it with Customer, Product, and Time dimensions to allow slicing and dicing. A consumption model (in some Datasphere versions labeled as part of fact model consumption or exposed directly) determines what is actually published for external tools to query, often bundling one or more fact models with their associated dimensions into a single analytic dataset. The design workflow typically starts in Data Builder: a data engineer creates and tests a graphical or SQL view exposing cleansed, joined data (for example, sales transactions joined with product master). That view is validated and deployed. Then, in Business Builder, a business modeler creates a dimension object referencing a master data view (like a Customer view) and defines which columns are the key, texts, and attributes, plus optional hierarchies. Separately, they create a fact model referencing the sales view, mapping measure columns (quantity, revenue) and associating dimension objects via key fields. The associations must resolve correctly—Business Builder validates that join keys and cardinalities are consistent with what the underlying views expose. Once the fact model is deployed, it (or a consumption model built from it) becomes available as a data source in SAP Analytics Cloud, in a live or replicated (import) connection context. A key design intent is governed self-service: IT retains control over raw data access, security views, and complex transformations in Data Builder, while Business Builder is a constrained, template-driven interface—users pick from validated views rather than writing arbitrary SQL, which reduces the risk of inconsistent business logic proliferating across the organization. However, Business Builder is not a replacement for Data Builder; it depends entirely on well-built underlying views. If the source view has bad grain (e.g., duplicated rows from a wrong join), the fact model will produce wrong aggregates. Beginners often mistakenly treat it as a place to fix data quality, when the real fix belongs upstream in Data Builder. From a licensing and role perspective, access to Business Builder objects is controlled through space roles and privileges in SAP Datasphere; business modelers need appropriate design-time privileges scoped to a space, and consumption is further governed by data access controls (row-level security) which can be defined declaratively without SQL. Understanding this entity model—dimensions, fact models, consumption models, and their dependency on Data Builder—is the essential foundation before moving into more advanced measure definitions, hierarchies, and currency/unit conversion in later lessons.
Real project scenario
A retail company's finance analyst wants a self-service Sales Actuals model in SAC without waiting on the data engineering backlog for every new measure. The data engineering team builds and deploys a Data Builder graphical view called V_SALES_ACTUALS joining order line items with product and store master, applying row-level currency and status filters. The finance analyst, given Business Builder access in their space, creates a Product dimension and a Store dimension referencing existing master data views, then builds a Sales fact model on V_SALES_ACTUALS, mapping Net Revenue and Quantity as measures and associating them to the two dimensions. The resulting fact model is exposed to SAP Analytics Cloud as a live data source for a monthly sales story, letting the analyst iterate on measure labels and dimension groupings without filing IT tickets.
Common mistakes
• Assuming Business Builder can fix data quality or grain issues that originate in the underlying Data Builder view • Building dimensions directly on raw source tables instead of curated, deployed Data Builder views • Not deploying the underlying Data Builder view before attempting to reference it in Business Builder, causing validation errors • Confusing a fact model with a consumption model and being unsure which object to expose to SAP Analytics Cloud • Ignoring key and cardinality mismatches between fact model associations and dimension keys, leading to fan-out or missing rows
Best practices
• Always finalize and deploy underlying Data Builder views before starting Business Builder modeling • Keep dimension and fact model naming business-friendly and consistent across spaces to avoid confusion in SAC • Validate associations and cardinalities immediately after creating a fact model rather than after downstream story-building begins • Document which team owns Data Builder objects versus Business Builder objects to maintain clear governance boundaries • Use a small pilot fact model to validate the end-to-end flow into SAP Analytics Cloud before scaling to many business models
Interview angle
Interviewers commonly probe whether a candidate understands the separation of technical (Data Builder) versus business (Business Builder) modeling layers, why that separation exists for governance, and how a fact model differs from a dimension and a consumption model. Be ready to explain the dependency chain: Data Builder view must exist and be deployed before Business Builder objects can reference it, and describe a realistic scenario where business users self-serve on top of governed data.