Understanding SAC Models: Purpose, Types, and Core Building Blocks
Introduces what an SAC model is, why it exists as a separate layer from stories, and the fundamental differences between analytic and planning models, dimensions, measures, and data acquisition modes.
Explanation
In SAP Analytics Cloud, a Model is the semantic and structural layer that sits between raw data sources and consumption artifacts like stories, dashboards, and planning applications. Rather than every story defining its own fields and calculations, a model centralizes dimensions (descriptive attributes like Product, Customer, Region, Time), measures or accounts (numeric facts like Revenue, Quantity, Cost), and metadata such as hierarchies, currency settings, and calculated formulas. This separation matters because it enables reuse: a single well-designed model can feed dozens of stories and planning applications consistently, so a change to a hierarchy or a new calculated measure propagates everywhere it is used instead of being duplicated and maintained separately. SAC supports two primary model types. Analytic models are optimized for reporting and analysis; they support live or imported data, flexible dimension structures, and are typically used for BI-style dashboards. Planning models (sometimes called planning-enabled models) include everything an analytic model has plus planning-specific capabilities: versions (Actual, Budget, Forecast), currency conversion for multi-currency planning, data locking, and integration with planning functions like allocations and forecasting algorithms. Choosing between them at creation time is important because converting a plain analytic model into a full planning model later is not always straightforward and may require rebuilding parts of the structure. Data acquisition mode is another foundational decision. Imported models copy data into SAC's in-memory engine on a scheduled or manual basis; this gives fast performance and allows calculated dimensions, but data can become stale between refreshes. Live models (via Live Data Connections) query the source system, typically SAP Datasphere, SAP BW/4HANA, or SAP HANA, in real time, meaning no duplication of data and always-current results, but with less flexibility for adding calculated columns and dependency on source-system performance and availability. Many organizations start with imported models for prototyping and shift toward live models when governance, data volume, or freshness requirements grow. Within a model, dimensions are structured collections of members, often organized into hierarchies (e.g., Region > Country > City). Measures (in analytic models) or Accounts (in planning models, using an Account dimension) hold the actual numeric data. Every model also has an implicit or explicit Version and Date dimension used for planning and time-based analysis. Understanding these building blocks before building stories prevents common early mistakes like designing a story around raw source fields instead of a clean, reusable dimensional structure. From a runtime perspective, when a user opens a story, SAC queries the underlying model: for imported models, it queries the in-memory dataset; for live models, it sends a query to the source system and renders the returned result set. This distinction is critical for troubleshooting: performance issues in an imported model are usually about model design or story complexity, whereas performance issues in a live model are frequently rooted in the source system, network, or connection configuration.
Real project scenario
A retail analytics team was asked to build a sales performance dashboard. Instead of connecting the story directly to a flat CSV export from the sales system, the consultant first built an imported analytic model with cleanly defined dimensions (Product, Store, Time, Customer Segment) and a Sales Amount measure with a currency setting. This model was then reused across five different stories (regional dashboards, executive summary, product category deep-dive) without duplicating logic, and when finance later requested a new calculated measure for gross margin, it was added once in the model and instantly available everywhere.
Common mistakes
• Treating a model as disposable and rebuilding structures for every new story instead of designing for reuse • Choosing an analytic model when planning capabilities like versions and data locking will be needed later, forcing a rebuild • Not understanding the difference between imported and live data, leading to confusion about why numbers appear stale or slow • Skipping dimension and hierarchy planning and instead relying only on flat, ungrouped source fields • Assuming currency and unit settings are automatically correct without explicitly configuring them in the model
Best practices
• Design dimensions and hierarchies deliberately before building any stories on top of the model • Choose planning versus analytic model type based on known future requirements, not just current needs • Document the source and refresh frequency for every imported model so consumers understand data currency • Use a single shared model across multiple stories wherever the same business entities are being reported on • Explicitly configure currency and unit of measure settings rather than relying on defaults
Interview angle
Interviewers commonly ask candidates to explain the difference between analytic and planning models and when to choose imported versus live data acquisition. A strong answer explains the trade-offs (data freshness versus flexibility and performance) and ties the choice to a real business requirement such as planning versions or large source-system data volumes, rather than giving a purely textbook definition.