Phase 09 — Analytic Models & Consumption

Goal: Turn reusable semantic models into focused analytical contracts that answer specific business questions and can be consumed safely by SAP Analytics Cloud and other supported clients.

1. What This Phase Solves

Phase 08 established semantic meaning:

• Facts
• Dimensions
• Measures
• Attributes
• Associations
• Keys
• Units
• Currencies
• Time semantics

That is necessary, but it is still not the final analytical product.

A Fact may contain dozens of measures and many associated dimensions.

A business consumer usually does not need all of them.

For example, an enterprise Sales Fact might contain:

• gross sales,
• net sales,
• tax,
• discount,
• quantity,
• cost,
• margin,
• customer,
• product,
• plant,
• sales organization,
• channel,
• order date,
• billing date,
• delivery date,
• document currency,
• local currency,
• company currency,
• operational attributes,
• technical metadata.

An executive sales model might need only a carefully selected subset.

An operational fulfillment model needs a different subset.

A profitability model needs another subset.

This is the purpose of the Analytic Model.

2. The Core Mental Model

Use this progression:

Source data → Relational model → Semantic foundation → Analytic Model → Consumer

The Analytic Model is the controlled boundary between reusable semantic data and a specific analytical use case.

Think of it as an analytical contract:

Here are the measures, dimensions, calculations, filters, variables, relationships and business rules that are valid for this analytical question.

3. Current Product Architecture

Current SAP Datasphere recommends the following pattern:

Fact + associated dimensions → Analytic Model → Consumption

The older Analytical Dataset semantic usage is deprecated.

Analytical Datasets should not be the default architecture for new implementations.

The modern approach gives you:

• focused measure and attribute exposure,
• calculated measures,
• restricted measures,
• count distinct measures,
• exception aggregation,
• reusable analytical definitions,
• variables,
• filters,
• structures,
• focused models for different BI contexts.

4. Why Analytic Models Exist

Without an Analytic Model, consumers may need to understand:

• which measures are valid,
• which dimensions are relevant,
• which calculations should be used,
• which filters are mandatory,
• which currencies apply,
• which aggregations are safe,
• which relationships are intended.

That pushes architectural responsibility into every consuming report.

An Analytic Model centralizes the analytical contract.

Therefore:

Do not make every SAC story become its own semantic engineering project.

5. Phase 08 vs Phase 09

Phase 08 — Semantic Modeling

Defines reusable business meaning.

Examples:

• Sales Fact
• Customer Dimension
• Product Dimension
• Calendar Dimension
• Supplier Dimension

Phase 09 — Analytic Models

Defines a focused analytical perspective.

Examples:

• Executive Sales
• Regional Sales
• Product Profitability
• Procurement Spend
• Customer Performance

The semantic foundation should be reusable.

The Analytic Model should be purpose-driven.

6. One Fact, Many Analytic Models

A single Fact can support multiple Analytic Models.

Example:

FCT_SALES_ORDER_ITEM

can support:

1. Executive Sales
2. Regional Sales
3. Product Sales
4. Customer Performance
5. Channel Performance
6. Margin Analysis

Each model can expose different:

• measures,
• attributes,
• dimensions,
• filters,
• calculated measures,
• restricted measures,
• variables.

This is one of the strongest reasons to separate semantic modeling from analytical consumption.

7. The Analytical Contract

For every Analytic Model, document:

Contract Area	Question
Purpose	What business question does it answer?
Fact	Which Fact is the analytical foundation?
Grain	What does one underlying Fact row represent?
Measures	Which metrics are exposed?
Dimensions	Which analysis axes are exposed?
Filters	Which records are included?
Calculations	Which derived metrics are defined?
Currency	Which currency context applies?
Units	Which units apply?
Security	Who can see which data?
Freshness	How current must the data be?
Consumer	SAC, Excel, BI client, application, etc.
Owner	Who owns the business meaning?

If these questions cannot be answered, the model is not ready for production.

8. Analytic Model vs View

A View primarily solves relational modeling.

An Analytic Model solves analytical consumption.

A View asks:

How should rows and columns be produced?

An Analytic Model asks:

Which business measures and dimensions should an analytical consumer use, and how should those measures behave?

This distinction prevents the common mistake of trying to make one giant SQL or Graphical View serve every consumption scenario.

9. Analytic Model vs Fact

A Fact is a reusable semantic foundation.

An Analytic Model is a focused analytical composition built from a Fact and its associated dimensions.

Think:

Fact = reusable business measurement foundation

Analytic Model = analytical product

10. Analytic Model vs SAC Story

An Analytic Model is a governed data-modeling artifact.

A SAC Story is a visualization and user-experience artifact.

Do not put enterprise metric definitions into individual stories when they can be defined once in the Analytic Model.

For example:

Gross Margin %

should not be independently reimplemented in ten stories if the business definition is shared.

Define it once in the governed analytical layer where appropriate.

11. Analytic Model Construction

A typical design sequence is:

1. Select the Fact.
2. Review associated dimensions.
3. Select required measures.
4. Select required attributes.
5. Add calculated measures where appropriate.
6. Add restricted measures where appropriate.
7. Define exception aggregation when required.
8. Add variables where required.
9. Add structures where required.
10. Define global filters where appropriate.
11. Apply security.
12. Preview and validate.
13. Deploy.
14. Connect the supported consumer.
15. Test end to end.

Do not start by adding every available field.

Start with the business question.

12. Business Question First

Bad approach:

"Expose everything from the Sales Fact."

Better:

"Build a model for executive monthly sales performance by region and product group."

This immediately narrows:

Measures

• Net Sales
• Quantity
• Margin

Dimensions

• Month
• Region
• Product Group

Optional metrics

• Margin %
• Average Order Value

The model becomes easier to understand and safer to consume.

13. Measure Selection

Not every Fact measure belongs in every Analytic Model.

Suppose the Fact contains:

• Gross Sales
• Net Sales
• Tax
• Discount
• Cost
• Margin
• Freight
• Internal Transfer Value

An executive sales model may expose:

• Net Sales
• Margin
• Margin %

while an operational finance model may expose:

• Gross Sales
• Tax
• Discount
• Net Sales
• Cost

Measure selection is therefore an architectural decision.

14. Attribute Selection

The same principle applies to attributes.

Avoid exposing:

• technical IDs unless useful,
• ETL metadata,
• internal audit fields,
• source-system artifacts,
• irrelevant operational fields.

Expose attributes that answer the intended analytical question.

15. Dimension Selection

A Fact may be associated with many dimensions.

Do not expose all of them automatically.

For an executive sales model:

• Customer Region
• Product Group
• Month
• Sales Organization

may be sufficient.

Adding:

• source record ID,
• technical material ID,
• load timestamp,
• CDC operation

does not improve the analytical product.

16. Focused Models

A focused Analytic Model has:

• clear purpose,
• limited scope,
• understandable measures,
• relevant dimensions,
• controlled filters,
• governed calculations.

This improves:

• discoverability,
• usability,
• performance,
• governance,
• testing.

17. Calculated Measures

A calculated measure derives a metric from other measures.

Examples:

Margin = Net Sales - Cost

Margin % = Margin / Net Sales

Average Order Value = Net Sales / Number of Orders

Calculated measures belong in the analytical layer when the calculation is genuinely analytical and reusable.

18. When to Calculate in the Analytic Model

Prefer the Analytic Model when:

• the calculation is consumption-oriented,
• the calculation is post-aggregation,
• different consumers need the same metric,
• the calculation depends on measures,
• the calculation should be governed centrally.

Example:

Margin %

should generally be calculated from aggregated Margin and Net Sales rather than averaging row-level percentages.

19. The Post-Aggregation Principle

Consider:

Order	Sales	Cost
A	100	90
B	900	720

Margin % should be:

(100 + 900 - 90 - 720) / (100 + 900) = 19%

Do not calculate:

Average of row percentages

unless that is explicitly the business definition.

This is why analytical calculation semantics matter.

20. Restricted Measures

A restricted measure applies a measure to a defined subset.

Example:

Total Sales

and:

European Sales

where European Sales is Net Sales restricted to Region = Europe.

Another example:

2026 Sales

where the measure is restricted to Calendar Year = 2026.

Restricted measures are useful for:

• regional comparisons,
• period comparisons,
• scenario analysis,
• channel comparisons,
• product categories,
• organizational slices.

21. Restricted Measure vs Global Filter

These are different concepts.

Global Filter

Restricts the dataset available to the entire Analytic Model.

Restricted Measure

Restricts one measure while leaving the broader model available.

Example:

A global filter:

Company = 1000

means all measures and dimensions operate within Company 1000.

A restricted measure:

Sales for Company 1000

can coexist with another measure for Company 2000 if the model design allows it.

Use the correct scope.

22. Count Distinct

Count distinct is different from count.

Example:

100 sales-order items may belong to only:

20 distinct orders

Therefore:

COUNT(Order Item) ≠ COUNT DISTINCT(Order ID)

Use the metric that matches the business question.

Examples:

• Order count
• Customer count
• Product count
• Supplier count

Do not use row count as a substitute for business entity count.

23. Exception Aggregation

Exception aggregation is required when a measure does not aggregate normally across all dimensions.

Typical examples include:

• inventory balance,
• headcount,
• account balance,
• ending balance,
• first/last values,
• averages across a designated dimension.

The standard aggregation handles normal dimensions.

Exception aggregation handles the special dimension or aggregation behavior.

24. Non-Cumulative Measures

Consider daily inventory:

Date	Stock
Jan 1	100
Jan 2	120
Jan 3	110

The monthly stock is not:

100 + 120 + 110 = 330

If the business definition is month-end stock, the answer may be:

110

The model therefore needs the appropriate exception aggregation and time reference design.

25. Time Reference Dimension

For non-cumulative measures, time context matters.

Ask:

• What time dimension defines the aggregation?
• Is the measure first value, last value, minimum, maximum or average?
• What does "monthly stock" actually mean?
• What happens when dates are missing?

Do not choose Last simply because inventory sounds like a closing balance.

The business definition determines the aggregation.

26. Average Is Not Always Additive

Suppose:

Month	Average Order Value
Jan	100
Feb	200

The annual average is not necessarily:

150

unless both months have the same number of orders.

The correct calculation may need:

Total Sales / Total Orders

This is another reason to retain underlying components.

27. Variables

Variables allow consumers to provide values used by the analytical model.

Typical examples:

• Fiscal Year
• Company Code
• Region
• Product
• Date range
• Scenario

Use variables when the consumer needs controlled runtime input.

Do not create variables simply because the UI supports them.

28. Variable Design

A good variable has:

• clear business purpose,
• defined data type,
• appropriate default behavior,
• controlled value help where applicable,
• predictable impact,
• documented ownership.

Bad variable:

Enter anything

Good variable:

Fiscal Year

with a controlled set of valid values.

29. Variables vs Filters

A filter defines a restriction.

A variable provides a controlled input that can influence the analytical model.

Think:

Filter = model rule

Variable = user/runtime input

The distinction becomes important for reusable models.

30. Structures

Structures allow analytical calculations and restrictions to be organized and reused.

Use structures when several measures share a common calculation or restriction pattern.

Example:

A regional sales structure might contain:

• Europe Sales
• Americas Sales
• APJ Sales

with consistent measure logic.

Avoid creating structures merely to make the model visually complex.

31. Analytic Model Reuse

SAP Datasphere supports using one Analytic Model as a source for other Analytic Models.

This enables layered analytical products.

Example:

Enterprise Sales Analytic Model

↓

Executive Sales Model

Regional Sales Model

Product Sales Model

Use this deliberately.

Do not create ten layers simply because reuse is possible.

32. Reuse Decision

Reuse an existing Analytic Model when:

• its semantics are stable,
• its calculations are trusted,
• its scope is compatible,
• its performance is acceptable,
• its ownership is clear.

Build directly from the Fact when:

• the analytical purpose is different,
• the existing model contains irrelevant restrictions,
• reuse would create unnecessary dependency,
• the performance profile is unsuitable.

Reuse should reduce complexity, not hide it.

33. Global Filters

A global filter can reduce the data available to the entire Analytic Model.

Good uses:

• permanently scoped model,
• organizational boundary,
• active records,
• domain-specific subset,
• agreed analytical population.

Example:

Model = Current Active Suppliers

The filter becomes part of the analytical contract.

34. Global Filter vs Source Filter

Do not confuse:

source/modeling filter

with:

Analytic Model global filter

A source filter changes what enters the semantic foundation.

An Analytic Model filter changes what a particular analytical product exposes.

Use the earliest appropriate layer without accidentally changing reusable business meaning.

35. The Reuse Trap

Suppose the Sales Fact is reusable.

If you hard-code:

Region = Europe

inside the Fact, you have reduced reuse.

If only the European Sales Analytic Model needs that restriction, apply it at the Analytic Model layer.

Architectural principle:

Apply business-question-specific restrictions as close to the business-question layer as possible.

36. Analytical Model and Currency

If the Fact contains multiple currencies, the Analytic Model must provide a clear currency interpretation.

Questions:

• Is the measure stored in document currency?
• Is it already converted?
• Is conversion required?
• Which exchange-rate date applies?
• Which target currency is required?
• Are totals meaningful before conversion?

Never let a consumer infer currency semantics.

37. Analytical Model and Units

Quantity measures require unit context.

Example:

100 KG + 100 EA

is not a meaningful total.

If conversion is required:

• identify source unit,
• identify target unit,
• define conversion rules,
• validate dimensions where conversion is physically meaningful.

Do not assume every unit is convertible.

38. Analytical Model and Hierarchies

Dimensions may expose hierarchies for analytical navigation.

Examples:

Region → Country → City

Product Group → Category → Product

Company → Division → Department

Hierarchies allow users to:

• drill down,
• drill up,
• analyze at different levels.

Detailed hierarchy design is covered in Phase 10.

Phase 09 focuses on consuming the semantic hierarchy correctly.

39. Analytical Model and Text

A consumer-friendly analytical model should expose meaningful descriptions.

Example:

Instead of:

100023

the consumer should see:

Laptop Pro 14

when the appropriate text association is available.

Text handling becomes especially important for:

• multilingual organizations,
• SAP master data,
• product descriptions,
• organizational names.

40. Analytical Model and Time

Time dimensions should support the analytical questions being asked.

Typical attributes:

• Year
• Quarter
• Month
• Week
• Date
• Fiscal Year
• Fiscal Period

Do not assume calendar year equals fiscal year.

For finance, the fiscal calendar is often the authoritative analytical time.

41. Preview Is a Test Harness

The Analytic Model preview is not just a demo feature.

Use it to test:

• measure values,
• dimension navigation,
• filters,
• calculated measures,
• restricted measures,
• aggregation behavior,
• hierarchy behavior,
• exception aggregation.

A model that has never been previewed is not adequately validated.

42. Analytical Validation Workflow

For every new Analytic Model:

1. Test one measure.
2. Test the measure at the base grain.
3. Add one dimension.
4. Validate totals.
5. Add another dimension.
6. Revalidate totals.
7. Test filters.
8. Test calculated measures.
9. Test restricted measures.
10. Test exception aggregation.
11. Test null and missing values.
12. Test security.
13. Compare against a trusted source.

This incremental approach isolates semantic errors.

43. The Drill-Down Test

For every important measure:

1. Check grand total.
2. Drill by one dimension.
3. Compare sum of visible groups to total.
4. Drill by another dimension.
5. Look for unexpected duplication.
6. Test filters.
7. Test the same measure at different grains.

If totals change unexpectedly, investigate the model rather than the visualization first.

44. The Reconciliation Test

Choose a trusted source.

For example:

SAP S/4HANA Finance

Compare:

• record population,
• gross amount,
• net amount,
• document count,
• customer count,
• currency,
• posting period.

Document allowed differences.

Never say:

"The numbers look close."

Define reconciliation tolerance.

45. Golden Analytical Dataset

Build a small expected-result dataset for every critical model.

Example:

Dimension	Expected
Germany	1,000
France	2,000
India	3,000

Then validate:

• total,
• each slice,
• restricted measures,
• calculated measures.

This becomes an analytical regression test.

46. Security

An Analytic Model can participate in secured consumption.

Security must be evaluated at multiple layers:

1. Space access
2. Object privileges
3. Data Access Controls
4. Analytic Model exposure
5. Consumer authorization

A model being visible does not mean every user should see every row.

47. Data Access Controls

For row-level restrictions, evaluate Data Access Controls.

Typical scenarios:

• Sales Manager sees assigned region.
• Finance user sees assigned company codes.
• Procurement user sees assigned purchasing organizations.

The security design should be tested using representative identities.

Do not validate row-level security using only an administrator account.

48. Security Test Matrix

Test at least:

User	Expected Access
Global analyst	All authorized regions
Europe analyst	Europe only
India analyst	India only
Finance analyst	Authorized company codes
Unauthorized user	No access

Record expected and actual results.

49. Consumption Architecture

Current SAP Datasphere documentation describes multiple exposure paths.

Analytic Models are designed for analytical consumption, especially through SAP Analytics Cloud.

Other exposed objects and interfaces can support other clients and integration patterns.

The architect should select the consumption path based on:

• analytical vs relational workload,
• real-time requirements,
• security,
• client capabilities,
• governance,
• performance.

50. SAP Analytics Cloud Live Connection

A major consumption pattern is:

SAP Analytics Cloud → Live Connection → SAP Datasphere → Analytic Model

The analytical model provides the governed semantic and analytical contract.

The SAC story then provides:

• charts,
• tables,
• filters,
• dashboards,
• user interaction.

This separation is healthy:

Datasphere = governed analytical data model

SAC = analytical experience

51. Why Live Consumption Matters

Live consumption can avoid copying the analytical dataset into another reporting store.

Benefits may include:

• centralized semantics,
• current data according to source freshness,
• reduced duplication,
• centralized security,
• reusable analytical definitions.

But live does not mean free.

Performance still depends on:

• query complexity,
• data volume,
• federation,
• persistence,
• modeling,
• consumer behavior,
• network and platform conditions.

52. Microsoft Excel

SAP Datasphere can expose Analytic Models for consumption through supported SAP Excel integration.

Typical use cases:

• finance analysis,
• controlled operational reporting,
• analyst exploration,
• ad hoc pivoting.

The same analytical contract should remain valid.

Do not create a separate business definition merely because the consumer is Excel.

53. ODBC/JDBC and OData

Not every consumer should use an Analytic Model.

For relational integration, SAP Datasphere also supports exposed views through supported interfaces such as ODBC/JDBC and OData.

Architectural rule:

Choose the interface according to the workload.

Use analytical consumption patterns for analytical questions.

Use relational interfaces when a consuming application genuinely needs relational access.

Do not expose an analytical model as a generic application API by default.

54. Consumption Decision Matrix

Requirement	Preferred Direction
Governed analytical model	Analytic Model
SAC analytical story	Analytic Model
Excel analytical analysis	Analytic Model / supported live integration
Relational application access	Exposed View / supported API
OData integration	Exposed View where appropriate
Reusable business semantics	Fact + Dimensions
Highly specific analytical question	Focused Analytic Model

Always validate the exact supported interface for the current tenant release.

55. Analytical Model Performance

A model can be semantically correct and still perform poorly.

Performance depends on:

• underlying Fact design,
• dimension relationships,
• remote vs local data,
• persistence,
• filter selectivity,
• calculated measures,
• restricted measures,
• exception aggregation,
• model reuse,
• query shape,
• consumer behavior.

Do not optimize only the Analytic Model editor.

Trace the complete execution path.

56. Performance Investigation

When a model is slow:

1. Reproduce the slow query.
2. Identify the exact consumer request.
3. Identify selected measures.
4. Identify selected dimensions.
5. Identify filters.
6. Check whether the model is federated.
7. Inspect the underlying Fact.
8. Inspect associations.
9. Check persistence.
10. Analyze runtime behavior.
11. Reduce unnecessary fields.
12. Re-test.

Never optimize without a reproducible workload.

57. Wide Model Performance

A model exposing 200 attributes does not necessarily execute 200-column queries.

Consumers may request subsets.

However, wide models can still create:

• poor discoverability,
• accidental broad queries,
• governance problems,
• harder testing.

Focused models remain preferable.

58. Calculated Measure Performance

A calculated measure can be inexpensive or expensive depending on:

• source measure complexity,
• aggregation behavior,
• nested calculations,
• filters,
• underlying joins,
• data volume.

Do not assume:

"It is only a formula, so it cannot be expensive."

Measure performance using actual workloads.

59. Exception Aggregation Performance

Exception aggregation can require additional processing.

For non-cumulative measures:

• verify the time reference dimension,
• validate aggregation behavior,
• test at multiple drill levels,
• benchmark realistic periods.

Correctness comes before optimization.

60. Analytic Model Layering

A possible enterprise pattern is:

Reusable Fact

↓

Enterprise Sales Analytic Model

↓

Regional Sales Analytic Model

↓

Consumer

But do not automatically create all three.

Layer only when it provides:

• reusable calculations,
• reusable restrictions,
• governed business definitions,
• meaningful separation of responsibility.

Excessive layering creates dependency chains.

61. Dependency Risk

If:

Model A → Model B → Model C → Model D

then a change to A can affect all downstream consumers.

Before introducing reuse, ask:

• Who owns each layer?
• What is the contract?
• How is compatibility tested?
• What is the deployment order?
• What happens when a field is removed?
• How are consumers notified?

Architectural reuse requires lifecycle discipline.

62. Breaking Changes

Examples:

• rename a measure,
• remove a dimension,
• change measure meaning,
• change aggregation,
• change currency,
• change key,
• change filter population.

These are not cosmetic changes.

Treat analytical contract changes as governed changes.

63. Backward Compatibility

Prefer additive evolution where possible.

For example:

Safe:

Add New Measure

Potentially breaking:

Rename Existing Measure

Potentially dangerous:

Change Revenue Definition

Always classify changes as:

• additive,
• non-breaking,
• behavior-changing,
• breaking.

64. Model Versioning Strategy

For major semantic changes, consider:

Sales Model v1

and:

Sales Model v2

rather than silently changing the meaning of v1.

The exact lifecycle mechanism depends on the organization's deployment model, but the architectural principle is stable:

Never silently change the meaning of a production metric.

65. Consumption Contract

For every production Analytic Model document:

• model purpose,
• exposed measures,
• exposed dimensions,
• calculation definitions,
• filters,
• security,
• freshness,
• source dependencies,
• owner,
• expected performance,
• known limitations.

This is the model's consumer contract.

66. Model Naming

Recommended convention:

AM_<BUSINESS_PURPOSE>

Examples:

• AM_EXECUTIVE_SALES
• AM_REGIONAL_SALES
• AM_PROCUREMENT_SPEND
• AM_PRODUCT_PROFITABILITY
• AM_CUSTOMER_PERFORMANCE

Use names that describe the analytical purpose rather than the underlying technical object.

67. Measure Naming

Use business names.

Prefer:

• Net Sales
• Gross Margin
• Margin %
• Order Count
• Average Order Value

Avoid consumer-facing names such as:

• ZNETVAL
• NET_VAL_01
• CALC_004

Technical lineage can retain source names internally.

68. Folder and Package Discipline

Organize models according to the enterprise lifecycle.

Possible grouping:

Semantic Foundation

• Facts
• Dimensions
• Text
• Hierarchies

Analytic Products

• Executive
• Finance
• Procurement
• Sales
• Operations

The exact folder structure is organizational, but the principle is important:

Consumers should be able to discover the intended analytical product.

69. Production Ownership

Every production Analytic Model should have:

• business owner,
• technical owner,
• support owner,
• data source owner.

Example:

Model: Procurement Spend

Business owner: Procurement Analytics

Technical owner: Data Platform

Source owner: S/4HANA Procurement

Support: Analytics Operations

Ownership prevents "orphan models."

70. SLA and Freshness

A model is not complete without understanding freshness.

Examples:

• daily,
• hourly,
• near real time,
• intraday,
• monthly close.

The model's freshness depends on the complete pipeline:

Source → Acquisition → Transformation → Persistence → Consumption

Do not promise real-time analytics merely because the consumer uses a live connection.

71. Data Freshness Test

Record:

• source update time,
• acquisition completion time,
• transformation completion time,
• semantic availability time,
• consumer availability time.

Then calculate:

End-to-end freshness

This is much more useful than saying:

"The dashboard is live."

72. Consumer Query Patterns

Before optimizing an Analytic Model, identify actual queries.

Examples:

Executive

• Net Sales by Region and Month

Finance

• Actual Cost by Company Code and Fiscal Period

Procurement

• Spend by Supplier and Purchasing Organization

Operations

• Inventory by Plant and Material

The model should be designed around these workloads.

73. Anti-Pattern — One Model for Everything

A single "Enterprise Everything" Analytic Model may appear reusable.

In reality it often becomes:

• too wide,
• difficult to understand,
• difficult to secure,
• difficult to test,
• difficult to optimize,
• difficult to govern.

Prefer multiple focused models over one universal consumption model.

74. Anti-Pattern — One Model Per Story

The opposite extreme is also bad.

If every SAC story creates its own model:

• calculations are duplicated,
• definitions drift,
• governance becomes difficult,
• testing multiplies.

The goal is:

Reusable semantics + focused analytical products

75. Anti-Pattern — Calculating Ratios at Row Level

Do not calculate:

Margin % = Row Margin / Row Sales

and then average the percentages unless that is the explicit business definition.

Prefer a governed aggregate calculation:

Aggregated Margin / Aggregated Sales

when that represents the business definition.

76. Anti-Pattern — Global Filters Used for Every Requirement

Do not put:

Region = Europe

into a reusable enterprise model merely because one report needs Europe.

Use the narrowest appropriate analytical layer.

77. Anti-Pattern — Hard-Coded Period

Avoid hard-coding:

Year = 2026

inside a reusable model unless the model is explicitly intended to represent that fixed population.

Prefer variables or consumer-level filters when the requirement is dynamic.

78. Anti-Pattern — Hiding Semantic Errors with Calculations

If a measure is wrong because of duplicate relationships, do not "fix" it with:

• DISTINCT,
• arbitrary aggregation,
• manual correction factors,
• hidden filters.

Fix the semantic foundation.

79. Anti-Pattern — Treating Preview as Proof

A model can produce a plausible preview and still be wrong.

Test:

• totals,
• drill-down,
• filters,
• edge cases,
• security,
• multiple currencies,
• multiple units,
• historical data.

80. Troubleshooting — Measure Too High

Checklist:

1. Validate Fact grain.
2. Check dimension key uniqueness.
3. Check associations.
4. Check many-to-many paths.
5. Check restricted measures.
6. Check filters.
7. Check calculation logic.
8. Compare against source.
9. Test at the lowest meaningful grain.

81. Troubleshooting — Measure Too Low

Check:

• unintended filters,
• global filters,
• missing dimension members,
• restricted measure conditions,
• null handling,
• date boundaries,
• source completeness.

82. Troubleshooting — Correct Total, Wrong Drill-Down

This is a classic semantic warning.

Possible causes:

• incorrect association,
• duplicate dimension members,
• hierarchy issue,
• wrong grain,
• non-unique key,
• aggregation mismatch.

A correct grand total does not prove dimensional correctness.

83. Troubleshooting — Wrong Percentage

Check:

1. Numerator definition.
2. Denominator definition.
3. Aggregation level.
4. Null handling.
5. Zero denominator.
6. Currency context.
7. Filter context.

Do not average percentages blindly.

84. Troubleshooting — Slow SAC Query

Investigate:

• requested dimensions,
• requested measures,
• filters,
• model dependencies,
• remote data,
• persistence,
• calculated measures,
• exception aggregation,
• high-cardinality dimensions.

Reproduce the actual SAC query pattern before changing architecture.

85. Troubleshooting — User Sees Data They Should Not See

Check:

1. Space assignment.
2. Object privileges.
3. Data Access Controls.
4. Permissions entity.
5. User identity mapping.
6. Consumer connection.
7. Cached consumer behavior where applicable.

Security defects are production incidents.

86. Troubleshooting — User Cannot See Model

Check:

• model deployment,
• exposure state,
• space assignment,
• consumption privileges,
• connection,
• consumer model discovery,
• whether the model is supported by the chosen client.

Do not immediately recreate the model.

87. Hands-On Lab 1 — Executive Sales Model

Starting point:

FCT_SALES_ORDER_ITEM

Create:

AM_EXECUTIVE_SALES

Expose:

• Net Sales
• Margin
• Margin %
• Quantity

Dimensions:

• Month
• Region
• Product Group

Tasks:

1. Remove unnecessary measures.
2. Remove unnecessary attributes.
3. Create Margin %.
4. Preview.
5. Validate totals.
6. Test regional drill-down.
7. document the analytical contract.

88. Hands-On Lab 2 — Restricted Measures

Create:

• Total Sales
• Europe Sales
• India Sales
• Americas Sales

Validate that the restricted measures remain comparable within the same model context.

Test:

• total,
• each region,
• month,
• product group.

89. Hands-On Lab 3 — Count Distinct

Create:

• Order Item Count
• Distinct Order Count
• Distinct Customer Count

Compare them at:

• month,
• region,
• product group.

Explain why the numbers differ.

90. Hands-On Lab 4 — Non-Cumulative Inventory

Create:

FCT_INVENTORY_SNAPSHOT

with:

• Material
• Plant
• Date
• Stock Quantity
• Unit

Design an Analytic Model that returns meaningful period-end inventory.

Test:

• day,
• week,
• month,
• plant,
• material.

Document the time reference and aggregation behavior.

91. Hands-On Lab 5 — Variable-Driven Model

Create:

AM_PROCUREMENT_SPEND

with a runtime variable for:

Fiscal Year

Test:

• one year,
• another year,
• no valid value,
• boundary period.

Document expected behavior.

92. Hands-On Lab 6 — Global Filter

Create:

AM_ACTIVE_SUPPLIERS

with a global filter for active suppliers.

Then explain why the same filter should not necessarily be placed into the reusable Supplier Dimension.

93. Hands-On Lab 7 — Model Reuse

Create:

AM_ENTERPRISE_SALES

Then derive:

AM_REGIONAL_SALES

and:

AM_PRODUCT_SALES

Document:

• inherited logic,
• additional restrictions,
• ownership,
• dependency,
• performance implications.

94. Hands-On Lab 8 — SAC Consumption

Connect SAP Analytics Cloud to the Datasphere environment using a supported live connection.

Use the Analytic Model as the data source.

Validate:

• model discovery,
• dimensions,
• measures,
• filters,
• drill-down,
• calculations,
• security.

Do not begin by building a complex dashboard.

First prove the analytical contract.

95. Hands-On Lab 9 — Excel Consumption

Consume an Analytic Model through the supported SAP Excel integration.

Validate:

• measure values,
• dimensions,
• filtering,
• pivoting,
• totals.

The numbers should reconcile with the SAC test.

96. Hands-On Lab 10 — Break the Metric

Create:

Margin %

incorrectly as an average of row-level percentages.

Compare it with:

Aggregated Margin / Aggregated Sales

Identify the difference.

Then document why the governed calculation is preferable.

97. Architect Exercise — Executive Sales

Requirement:

CEO wants monthly net sales, margin, margin %, quantity and customer count by region and product group.

Design:

• Fact,
• dimensions,
• measures,
• restricted measures,
• calculated measures,
• filters,
• variables,
• security,
• freshness,
• consumer.

Then defend every choice.

98. Architect Exercise — Finance

Requirement:

CFO wants actual cost by company code, account, cost center and fiscal period.

Decide:

• document currency,
• company-code currency,
• group currency,
• sign convention,
• reversal handling,
• fiscal calendar,
• aggregation,
• security.

Do not proceed until currency and fiscal semantics are explicit.

99. Architect Exercise — Procurement

Requirement:

Procurement leadership wants spend by supplier, purchasing organization, material group and month, with current-year and prior-year comparison.

Design:

• reusable measures,
• restricted measures,
• period logic,
• dimensions,
• supplier semantics,
• currency,
• security,
• freshness.

Explain where each rule belongs.

100. Architect Exercise — Inventory

Requirement:

Operations wants month-end stock by plant and material.

Design:

• snapshot fact,
• time reference,
• exception aggregation,
• unit semantics,
• dimensions,
• analytic model.

Explain why SUM over time is incorrect.

101. Architect Exercise — Enterprise Analytical Product

Design an enterprise Sales analytical product containing:

Semantic foundation

• Sales Fact
• Customer
• Product
• Calendar
• Organization

Analytic products

• Executive Sales
• Regional Sales
• Product Performance
• Customer Performance

For each model define:

• scope,
• measures,
• dimensions,
• filters,
• ownership,
• security,
• consumer,
• SLA.

102. Architect Exercise — Model Consolidation

You discover 17 SAC stories containing their own definitions of:

Revenue

12 definitions are slightly different.

Design a remediation plan.

Expected thinking:

1. Inventory existing definitions.
2. Identify business owner.
3. Establish canonical definition.
4. Build reusable Fact semantics.
5. Build governed Analytic Model.
6. Reconcile results.
7. Migrate stories.
8. retire conflicting calculations.
9. monitor adoption.

This is an architecture problem, not a dashboard problem.

103. Production Readiness Review

Before approving an Analytic Model, ask:

Business

• What question does it answer?
• Who owns it?
• What does each measure mean?

Semantic

• Is the Fact grain correct?
• Are dimensions conformed?
• Are keys unique?
• Are associations safe?

Analytical

• Are measures correctly aggregated?
• Are ratios calculated at the correct level?
• Are restricted measures correct?
• Are exception aggregations tested?

Security

• Who can consume it?
• Is row-level security required?
• Has security been tested with non-admin users?

Performance

• What is the expected query pattern?
• What is the baseline?
• Is federation involved?
• Are calculations expensive?

Operations

• What is the freshness SLA?
• What are upstream dependencies?
• What happens when the model changes?

Consumption

• Which clients consume it?
• Is the interface appropriate?
• Has end-to-end reconciliation been completed?

104. Enterprise Consumption Architecture

A mature pattern looks like:

SAP / Non-SAP Sources

↓

Acquisition & Integration

↓

Preparation

↓

Relational Modeling

↓

Semantic Foundation

Facts + Dimensions + Text + Hierarchies

↓

Analytic Models

Executive / Finance / Procurement / Operations

↓

Consumers

SAP Analytics Cloud / Excel / Supported BI and Integration Clients

The key architectural boundary is:

Do not let every consumer redefine enterprise business meaning.

105. Architectural Trade-Off — One Large Model vs Many Focused Models

One large model

Advantages:

• fewer objects,
• broad reuse.

Risks:

• complexity,
• poor discoverability,
• difficult security,
• wider testing scope,
• consumer confusion.

Many focused models

Advantages:

• clarity,
• purpose-driven scope,
• easier testing,
• easier consumer experience.

Risks:

• duplication,
• model proliferation,
• governance overhead.

Recommended enterprise approach:

Few reusable semantic foundations + focused analytical products

106. Architectural Trade-Off — Calculate in SQL or Analytic Model?

Use SQL/Graphical modeling when:

• the logic changes the relational dataset,
• the result should be reusable by multiple semantic consumers,
• the calculation is row-level,
• the logic is transformation-oriented.

Use the Analytic Model when:

• the logic is analytical,
• it is measure-oriented,
• it depends on aggregation,
• it belongs to a specific analytical perspective.

Example:

Net Sales = Gross Sales - Discount

could belong in the semantic foundation if universally defined.

Margin % = Aggregated Margin / Aggregated Net Sales

is a strong candidate for the analytical layer.

107. Architectural Trade-Off — Global Filter or Restricted Measure?

Use a global filter when:

The entire model represents a constrained population.

Use a restricted measure when:

Only one metric needs the restriction.

This simple distinction prevents many modeling mistakes.

108. Architectural Trade-Off — Reuse or Direct Fact?

Reuse an Analytic Model when:

• the business definition is shared,
• the inherited scope is appropriate,
• dependency is acceptable.

Build directly from the Fact when:

• the analytical purpose is materially different,
• inherited filters are wrong,
• dependency would be excessive,
• performance requires a different composition.

109. Architectural Trade-Off — Live vs Persisted

A live analytical consumption path can reduce duplication, but it still depends on the underlying model and source performance.

Persistence may be appropriate when:

• calculations are expensive,
• the source is remote,
• the same data is queried repeatedly,
• freshness allows persistence,
• runtime performance requires it.

Do not choose live or persisted based on ideology.

Measure the workload.

110. Production Monitoring

Monitor at least:

• model availability,
• consumer query failures,
• runtime behavior,
• upstream freshness,
• security changes,
• model deployment status,
• dependency changes.

A dashboard being available today does not mean the analytical product is operationally healthy.

111. Change Management

Before changing a production Analytic Model:

1. Identify downstream consumers.
2. Identify dependent models.
3. Classify the change.
4. Test semantic impact.
5. Reconcile critical measures.
6. Test security.
7. Test performance.
8. communicate the change.
9. deploy through the organization's lifecycle.

Analytical models are shared contracts.

112. Interview Preparation

What is an Analytic Model?

An Analytic Model is a focused analytical object built from a Fact and its associated dimensions to expose only the data, calculations, filters and semantics needed for a particular analytical question.

Why not consume a Fact directly?

Facts are reusable semantic foundations. The Analytic Model provides a focused consumption contract and supports analytical calculations, restrictions, variables and other analytical behavior.

What replaced Analytical Dataset?

The current preferred pattern is Fact + Analytic Model. Analytical Dataset semantic usage is deprecated.

What is a calculated measure?

A measure derived from other measures using analytical calculation logic.

What is a restricted measure?

A measure restricted to a defined subset of data.

What is exception aggregation?

An aggregation method applied according to a specific dimension or business rule, useful for measures such as balances and other non-cumulative values.

Why is Margin % dangerous?

Because percentages are generally not additive and often must be calculated from aggregated numerator and denominator values.

Why use a global filter?

To define a population-wide restriction for the entire analytical model.

Why use a restricted measure?

To restrict one measure while leaving the broader analytical context available.

Why create multiple Analytic Models from one Fact?

To provide focused analytical products for different business questions while reusing common semantic foundations.

113. Production Checklist

Model purpose

• Business question documented
• Consumer documented
• Owner assigned
• SLA documented

Semantic foundation

• Fact grain validated
• Dimensions validated
• Keys validated
• Associations validated
• Currency semantics validated
• Unit semantics validated
• Time semantics validated

Measures

• Required measures selected
• Unnecessary measures removed
• Calculated measures documented
• Restricted measures documented
• Count distinct requirements reviewed
• Exception aggregation tested
• Ratios validated after aggregation

Filters and variables

• Global filters justified
• Restricted measures scoped correctly
• Variables documented
• Defaults validated

Security

• Space access reviewed
• Object privileges reviewed
• Data Access Controls reviewed
• Non-admin security test completed

Consumption

• SAC test completed
• Excel test completed if required
• Other client interface validated
• Model discovery confirmed
• End-to-end reconciliation completed

Performance

• Baseline recorded
• Representative query tested
• Federation impact reviewed
• Persistence decision documented
• Expensive calculations reviewed

Operations

• Dependencies documented
• Freshness monitored
• Change impact understood
• Regression dataset available
• Support ownership assigned

114. Final Mental Model

Remember:

SEMANTIC FOUNDATION → ANALYTICAL CONTRACT → CONSUMPTION

The semantic foundation says:

"What does this data mean?"

The Analytic Model says:

"Which part of that meaning answers this business question, and how should it behave analytically?"

The consumer says:

"How should I interact with the answer?"

This separation is fundamental to enterprise analytics architecture.

115. Architect Takeaway

A strong Datasphere architect does not simply create an Analytic Model that works.

They can explain:

• why this Fact is the foundation,
• why these dimensions are exposed,
• why these measures are selected,
• why a calculation belongs here,
• why a restriction belongs here,
• why a global filter is or is not appropriate,
• how non-cumulative measures aggregate,
• how security is enforced,
• how SAC consumes the model,
• how performance was validated,
• how changes affect consumers,
• and why alternative designs were rejected.

The ultimate goal is:

One governed semantic foundation can support many focused analytical products without allowing business meaning to fragment.

Official SAP Documentation Anchors

Use current SAP documentation as the implementation authority:

• SAP Datasphere — Acquiring, Preparing, and Modeling Data
• SAP Datasphere — Analytical Datasets (Deprecated)
• SAP Datasphere — Consuming Data Exposed by SAP Datasphere
• SAP Datasphere — Consume Data in SAP Analytics Cloud via a Live Connection
• SAP Datasphere — Non-Cumulative Measures
• SAP Datasphere — Creating a Graphical View

Version discipline: SAP Datasphere evolves continuously. For tenant-release-specific editor behavior, supported functions, connection capabilities and consumption behavior, verify the current SAP Help documentation before implementation.