semantic-modeling

---

id: semantic-modeling title: "Phase 08 — Semantic Modeling" sidebar_label: "08. Semantic Modeling" description: "Master SAP Datasphere semantic modeling from facts and dimensions to associations, measures, attributes, semantic types, text entities, time dependency, analytical grain, reusable business semantics, testing, and enterprise architecture."

Phase 08 — Semantic Modeling

Goal: Turn technically correct relational data into a business-aware analytical model that consumers can understand, navigate, aggregate, filter, and reuse correctly.

1. What This Phase Solves

Phases 01–07 taught you how Datasphere is structured, how data arrives, how it is prepared, and how Graphical Views and SQL/SQLScript models are engineered.

That still does not make a data model analytically safe.

A relational model can contain technically valid columns, correct joins, correct SQL and correct row counts and still produce a wrong business answer.

Analytics needs meaning.

A business user does not ask:

"Return rows from table X joined to table Y."

They ask:

"What was net sales by product, customer, month and region?"

To answer that reliably, the platform must understand:

• what is a measure,
• what is an attribute,
• what is a fact,
• what is a dimension,
• how the fact relates to the dimension,
• what uniquely identifies a dimension member,
• how a value should aggregate,
• what unit or currency a measure uses,
• which text describes a key,
• whether a relationship is valid at the required grain,
• whether the model is intended for analytical consumption.

This phase teaches that semantic layer.

2. The Architect Mental Model

Think about Datasphere modeling as four progressively stronger contracts:

1. Physical correctness — the data exists and can be read.
2. Relational correctness — joins, filters, unions and transformations produce the intended rows.
3. Semantic correctness — the platform knows facts, dimensions, measures, attributes, keys, associations, text, units and currencies.
4. Analytical correctness — consumers receive correct answers for aggregation, slicing, filtering, drill-down and navigation.

The most important principle is:

A semantic model is not decoration added after SQL. It is an executable business contract.

3. Current Datasphere Semantic Architecture

Current SAP Datasphere supports semantic usages including:

• Fact
• Dimension
• Text
• Hierarchy
• Hierarchy with Directory
• Relational Dataset

The older Analytical Dataset semantic usage is deprecated.

The preferred modern analytical pattern is:

Fact + associated semantic entities → Analytic Model → Consumption

This is a major architectural distinction from older Datasphere tutorials.

Do not build new enterprise architecture around deprecated Analytical Dataset patterns simply because older tutorials still show them.

4. Where Phase 08 Fits

The masterclass progression is:

Sources → Acquisition → Preparation → Relational Modeling → Semantic Modeling → Analytic Models → Consumption

Phase 08 therefore sits between relational correctness and analytical consumption.

Phase 08 defines reusable business meaning.

Phase 09 will then focus more deeply on analytic models and consumption.

Phase 10 will take semantic modeling further into advanced semantics and hierarchies.

5. Semantic Usage Is an Architectural Decision

Semantic Usage answers:

"What role does this entity play in the analytical model?"

It does not simply describe what the table happens to contain today.

A sales transaction entity may be technically a table but semantically a Fact.

A product master entity may be technically a table but semantically a Dimension.

A multilingual product-description entity may be semantically a Text entity.

A parent-child organizational structure may be a Hierarchy.

Semantic designation communicates intended analytical behavior and relationships.

6. Fact — The Center of Measurement

A Fact contains measurable business data.

Typical examples:

• sales orders,
• invoices,
• shipments,
• procurement spend,
• inventory movements,
• flight operations,
• production quantities,
• financial postings.

A fact commonly contains:

• keys to dimensions,
• measures,
• attributes where appropriate,
• associations to dimensions and other semantic entities.

The critical architectural question is:

What does one row represent?

That is the fact grain.

7. Fact Grain

Never define a fact before defining its grain.

Example:

One row = one sales order item.

Possible key:

Order ID + Order Item

Another fact might be:

One row = one product × plant × day.

That is a completely different analytical model.

Grain controls:

• measure meaning,
• join correctness,
• aggregation correctness,
• dimensional navigation,
• duplication risk,
• historical interpretation.

Therefore:

Grain is established in relational modeling and reinforced in semantic modeling.

8. Dimension — Business Context

A Dimension provides descriptive business context used to analyze facts.

Typical dimensions:

• Customer
• Product
• Supplier
• Plant
• Company
• Cost Center
• Profit Center
• Calendar
• Geography
• Employee

Example Customer Dimension attributes:

• Customer ID
• Customer Name
• Country
• Region
• Customer Group
• Industry

The dimension should provide stable, meaningful context for grouping and filtering measures.

9. Fact vs Dimension

Question	Fact	Dimension
Primary purpose	Measurement	Context
Typical contents	Measures + keys	Attributes
Typical grain	Business event/snapshot	Business entity/member
Example	Invoice item	Customer
Aggregated?	Frequently	Usually grouped/filterable
Center of star	Yes	Surrounding context
Consumer role	Measures	Analysis axes

A common beginner mistake is:

"Anything with a numeric column is a fact."

Wrong.

A customer dimension can contain employee count, credit limit or annual revenue without becoming a fact.

Semantic role depends on business meaning, grain and analytical usage.

10. Relational Dataset

Relational Dataset is appropriate when an entity does not have a specific analytical semantic role.

Examples:

• technical staging data,
• helper datasets,
• intermediate relational objects,
• operational lookup structures,
• objects intended primarily for relational access.

Do not force every technical object into Fact or Dimension merely because those labels sound more analytical.

11. Text Entity

Text entities provide multilingual textual content for attributes.

Typical pattern:

Business Key + Language + Description

A text entity supplies language-dependent descriptions for semantic attributes.

Text modeling becomes important when:

• dimensions are multilingual,
• consumers need language-aware descriptions,
• master data has separate language-dependent texts.

Do not blindly flatten multilingual text into every dimension.

Text has its own semantic purpose.

12. Hierarchy

A Hierarchy represents parent-child relationships between members.

Examples:

• company organizational structures,
• account hierarchies,
• product category trees,
• cost center structures.

Detailed hierarchy implementation is intentionally reserved for Phase 10.

For this phase, understand the architectural role:

A hierarchy adds navigational structure to dimensional members.

13. Semantic Usage vs Semantic Type

These concepts are frequently confused.

Semantic usage describes the role of an entity.

Examples:

• Fact
• Dimension
• Text
• Hierarchy

Semantic type describes the meaning of a column.

Examples:

• Amount with Currency
• Quantity with Unit
• Currency Code
• Unit of Measure
• Date
• Time
• Timestamp
• textual or geographical types

Think:

Entity semantic usage + column semantic type + relationships = analytical meaning

14. Measures

A Measure is a value intended for analytical aggregation or calculation.

Examples:

• Revenue
• Quantity
• Cost
• Discount
• Margin
• Flight Hours
• Procurement Spend

A measure must have an aggregation interpretation.

Do not confuse:

numeric data type

with:

analytical measure

A numeric column is not automatically a business measure.

15. Additivity

Additivity is one of the most important semantic concepts.

Fully additive

Can be summed across all relevant dimensions.

Example:

Sales Amount

Semi-additive

Can be summed across some dimensions but not others.

Example:

Account Balance

You may sum balances across accounts, but summing daily closing balances across time is normally meaningless.

Non-additive

Should not be summed.

Examples:

• percentages,
• ratios,
• rates,
• already-calculated averages.

The semantic model must preserve these distinctions.

16. The Ratio Trap

Suppose:

Product	Revenue	Margin %
A	100	10%
B	900	20%

Incorrect:

10% + 20% = 30%

Correct weighted margin:

(100 × 10% + 900 × 20%) / 1000 = 19%

The architecture should therefore preserve the components required to calculate the ratio.

Do not treat the final ratio as an additive measure.

17. Amount and Currency Semantics

An amount without its currency is incomplete business meaning.

Weak model:

NET_VALUE = 100

Better model:

NET_VALUE = 100 + CURRENCY_CODE = EUR

A monetary measure should have the appropriate amount-with-currency semantic meaning and a currency-code attribute.

This becomes essential when multiple currencies coexist.

18. Quantity and Unit Semantics

Quantity also requires a unit.

500 KG

is not the same as:

500 EA

or:

500 L

A quantity measure should therefore be associated with the appropriate unit-of-measure attribute.

A numeric quantity without unit context is incomplete business meaning.

19. Attributes

Attributes describe members and provide analytical axes.

Examples:

• Product ID
• Product Name
• Product Group
• Brand
• Category

A dimension usually contains attributes.

A fact can also contain descriptive attributes, but ask:

Does this attribute belong to the event grain or to a reusable business entity?

If it belongs to the reusable business entity, centralizing it in a dimension often improves consistency.

20. Keys Are Semantic Contracts

A dimension needs a reliable way to identify members.

Example:

CUSTOMER_ID

If CUSTOMER_ID is not unique in the dimension, analytical navigation becomes ambiguous.

Example:

CUSTOMER_ID	COUNTRY
C100	DE
C100	US

Which customer is C100?

There is no safe answer without additional key semantics.

Therefore:

Dimension uniqueness must be established before analytical navigation.

21. Business Keys vs Technical Keys

A business key may be:

MATERIAL_NUMBER

A technical or warehouse key may be:

MATERIAL_SURROGATE_KEY

Do not assume they are interchangeable.

Document:

• source business key,
• semantic key,
• surrogate key if present,
• uniqueness,
• nullability,
• source-system scope.

22. Source-System Scope

A source-system business key may not be globally unique.

Example:

Material 1000

may exist independently in System A and System B.

An enterprise semantic model may therefore need:

Source System + Material ID

as the uniqueness context.

Never assume source-system keys are globally unique.

23. Associations

An association expresses a semantic relationship between entities.

Conceptually:

Sales Fact → Customer

Sales Fact → Product

Sales Fact → Calendar

Sales Fact → Plant

The relationship allows analytical navigation without repeatedly hard-coding the physical join into every consuming model.

This is a major architectural advantage.

24. Association vs Physical Join

These are not the same.

Physical Join

Combines rows as part of relational processing.

Association

Declares a semantic relationship between entities.

Think:

JOIN = row-combination operation

ASSOCIATION = semantic relationship contract

An association does not mean:

"Always physically join these two entities."

It means:

"These entities have a defined relationship that analytical consumers can navigate."

25. Association Cardinality

A relationship should reflect expected business cardinality.

Common analytical pattern:

Many fact records → one dimension member

For example:

Many sales records relate to one customer.

If the dimension contains multiple matching members for one key, the relationship becomes unsafe.

Possible consequences:

• duplicated measures,
• unexpected row multiplication,
• ambiguous navigation,
• inconsistent analytical results.

26. The Many-to-Many Warning

Many-to-many relationships deserve architectural scrutiny.

Example:

Customer ↔ Promotion

A customer may have many promotions.

A promotion may apply to many customers.

Many-to-many is not automatically wrong.

But putting it directly into a measure-bearing analytical path can change the grain.

Potential solutions include:

• bridge entities,
• allocation logic,
• dedicated relationship facts,
• factless facts,
• pre-aggregated analytical models.

27. Star Schema

The classic analytical pattern is:

Customer + Product + Calendar + Plant → Sales Fact

The fact is central.

Dimensions provide context.

This structure is readable, reusable and analytically intuitive.

But do not implement a star schema mechanically.

First establish:

1. business process,
2. grain,
3. measures,
4. dimensions,
5. keys,
6. relationships,
7. aggregation behavior.

28. Snowflake Modeling

A dimension may reference another semantic entity.

Example:

Sales Fact → Product → Product Category → Product Group

This resembles a snowflake.

It can improve reuse and reduce duplication.

But deeper relationship chains can increase navigation complexity.

Architectural rule:

Normalize reusable business semantics deliberately; do not create relationship depth merely because the source system is normalized.

29. Semantic Layering

A robust Datasphere implementation commonly separates:

Source → Preparation → Relational Model → Semantic Model → Analytic Model → Consumption

Each layer has a different responsibility.

Source

Acquire data.

Preparation

Clean and transform.

Relational model

Establish stable relational logic and grain.

Semantic model

Define business meaning.

Analytic model

Shape the model for a specific analytical question.

Consumption

Expose to tools and users.

Do not collapse all responsibilities into one giant view.

30. Why Semantic Modeling Should Not Be Done Too Early

If you mark an unstable staging table as a Fact before understanding its grain, you create false confidence.

Better sequence:

Acquire → Profile → Prepare → Validate grain → Define keys → Define measures → Define relationships → Assign semantic usage

Semantic modeling should be deliberate.

31. Business Meaning Before Technical Names

Avoid exposing only technical names such as:

• ZSD source object names,
• temporary transformation names,
• ETL helper names,
• generated technical identifiers.

A semantic layer should expose understandable business concepts.

Examples:

• Sales Order Item Fact
• Customer Dimension
• Product Dimension
• Calendar Dimension

Technical names still matter internally, but business names should help consumers understand the model.

32. Naming Standard

Recommended enterprise convention:

Facts

FCT_<BUSINESS_PROCESS>

Examples:

• FCT_SALES_ORDER_ITEM
• FCT_PROCUREMENT_SPEND
• FCT_FLIGHT_OPERATION

Dimensions

DIM_<BUSINESS_ENTITY>

Examples:

• DIM_CUSTOMER
• DIM_PRODUCT
• DIM_SUPPLIER
• DIM_AIRPORT

Text

TXT_<BUSINESS_ENTITY>

Hierarchy

HIER_<BUSINESS_ENTITY>

The exact convention can differ by organization. Consistency matters more than the specific prefix.

33. Measure Design Contract

For every important measure document:

Property	Example
Name	Net Sales
Source	Net Value
Grain	Order Item
Data type	Decimal
Currency	Document Currency
Aggregation	SUM
Null policy	Defined
Sign convention	Positive revenue
Business definition	Revenue after discounts
Owner	Finance

This turns a column into a governed metric.

34. Metric Definition

Weak definition:

Revenue = NET_VALUE

Stronger definition:

Net Sales represents invoiced sales value after applicable discounts, expressed in document currency and aggregated as a sum at order-item grain.

The second definition is testable.

A governed metric should be:

• understandable,
• testable,
• reproducible,
• owned,
• traceable.

35. Sign Conventions

Finance and operational data frequently contain signs.

Example:

• Invoice: +1000
• Credit Note: -100
• Net Sales: 900

Document:

• whether credits are negative,
• whether reversals are negative,
• whether cancellations are excluded,
• whether signs are source-derived or transformed.

Do not silently flip signs without documenting the business rule.

36. NULL Semantics

NULL is not zero.

NULL = unknown / unavailable

0 = known zero

If revenue is NULL, that does not automatically mean no revenue occurred.

Semantic design should establish whether:

• missing means unknown,
• missing means not applicable,
• missing should become zero,
• missing should remain NULL.

This is especially important for measures.

37. Default Values

Do not apply a blanket rule such as converting every measure NULL to zero.

Ask:

Does zero represent the absence of a value in this business process?

For quantities, sometimes yes.

For rates, percentages, exchange rates and balances, often no.

38. Time Semantics

Dates often have different business meanings:

• order date,
• posting date,
• billing date,
• delivery date,
• requested date,
• actual shipment date,
• accounting date.

Do not create one generic Date field and assume every analytical question uses the same meaning.

A fact may legitimately have multiple date roles.

39. Role-Playing Date Dimensions

Example:

Sales Fact → Order Date

Sales Fact → Billing Date

Sales Fact → Delivery Date

All may refer to the same Calendar dimension.

The semantic model must preserve the role.

This is an architectural pattern rather than merely a technical join.

40. Time-Dependent Dimensions

Some master data changes over time.

Example:

Customer	Region	Valid From	Valid To
C100	North	2025-01-01	2025-12-31
C100	South	2026-01-01	9999-12-31

If historical reporting is required, the model must respect the correct version of the dimension member.

This is the conceptual foundation of time-dependent semantic modeling.

Detailed implementation patterns are addressed again in advanced semantics.

41. Historical Truth Problem

Suppose a customer moved from Europe to Asia.

A current-only dimension says:

C100 = Asia

But a 2025 sales report may need:

C100 = Europe

If historical reporting is required, current master data cannot simply overwrite historical meaning.

Architectural question:

Are dimensions current-state or historically effective?

Never leave that ambiguous.

42. Attribute Selection

Not every source column belongs in the semantic model.

Ask:

1. Is the attribute business-relevant?
2. Is it stable enough?
3. Does it belong to this grain?
4. Is it reusable?
5. Does exposing it create security concerns?
6. Does it create ambiguity?
7. Is its business definition understood?

Avoid exposing hundreds of technical columns merely because they exist.

43. Semantic Width

A semantic model with hundreds of attributes can become difficult to use.

Too many fields cause:

• discoverability problems,
• consumer confusion,
• accidental use of technical attributes,
• wider queries,
• governance difficulty,
• maintenance cost.

Prefer focused, reusable semantic entities.

44. Association Path Design

Suppose:

Sales Fact → Customer → Country → Region

The architect must ask:

• Is each relationship unique?
• Can the path multiply rows?
• Is the path business-valid?
• Is the path needed?
• Is the path reusable?
• Is the navigation depth justified?

More associations are not automatically better.

45. Semantic Ambiguity

Avoid attributes whose meaning is unclear.

Example:

REGION

Could mean:

• customer region,
• sales region,
• plant region,
• shipping region.

Prefer explicit business semantics such as:

• Customer Region
• Sales Region
• Plant Region
• Ship-To Region

Semantic clarity beats short names.

46. Conformed Dimensions

A conformed dimension is shared across multiple facts.

Example:

Customer Dimension → Sales Fact

Customer Dimension → Service Fact

Both facts interpret Customer consistently.

This is one of the strongest benefits of semantic modeling.

Without conformance, different domains may slowly create incompatible customer definitions.

47. Why Conformed Dimensions Matter

If Finance and Sales both ask:

"Revenue by customer region"

the customer and region definitions should not change depending on the fact.

Conformed semantics reduce:

• metric fragmentation,
• reconciliation effort,
• duplicate master-data logic,
• inconsistent reporting.

48. Shared Dimensions vs Copying Dimensions

Avoid unnecessary duplicates such as:

• DIM_CUSTOMER_SALES
• DIM_CUSTOMER_FINANCE
• DIM_CUSTOMER_SERVICE

when all three represent the same enterprise customer.

Prefer a reusable Customer semantic entity when the business definition is genuinely shared.

Create separate domain dimensions only when the business definitions are actually different.

49. Domain-Owned Semantics

Enterprise reuse does not mean one central team owns every attribute.

A mature model identifies:

• business owner,
• technical owner,
• data steward,
• source system,
• business definition,
• quality expectation.

Example ownership:

Customer

• Business owner: Sales Operations
• Source owner: CRM
• Semantic steward: Enterprise Data

This becomes increasingly important in governance phases.

50. Semantic Model Quality Dimensions

Evaluate a semantic model across:

Correctness

Does it produce the right business answer?

Consistency

Do different consumers interpret the model the same way?

Reusability

Can multiple analytic models reuse it?

Discoverability

Can users understand what it means?

Performance

Does navigation remain efficient?

Security

Does exposure respect authorization requirements?

Operability

Can changes be tested and deployed safely?

51. Fact Readiness Checklist

Before marking a Fact complete:

• grain documented,
• measures identified,
• measure definitions documented,
• aggregation behavior defined,
• keys validated,
• dimensions identified,
• associations validated,
• currency/unit semantics defined,
• null behavior understood,
• date roles understood,
• business names assigned,
• unnecessary technical columns removed,
• security requirements reviewed.

52. Dimension Readiness Checklist

Before marking a Dimension complete:

• key uniqueness validated,
• attributes documented,
• master-data ownership identified,
• text requirements identified,
• hierarchy requirements identified,
• time dependency assessed,
• source-system scope documented.

53. Anti-Pattern — Everything Is a Fact

If every table is marked Fact:

• semantics lose meaning,
• analytical navigation becomes unclear,
• consumers cannot distinguish events from master data.

Use Fact only where measurable analytical data is the intended semantic role.

54. Anti-Pattern — Every Numeric Column Is a Measure

A numeric attribute such as customer employee count does not automatically make the entity a Fact.

The semantic question is:

Is this a measure of the analytical event, or an attribute describing a business member?

Context matters.

55. Anti-Pattern — Join First, Semantics Later

A giant relational model can already contain:

• duplicated rows,
• mixed grains,
• ambiguous measures,
• accidental many-to-many paths.

Assigning Fact or Dimension semantics afterward does not repair the relational design.

Semantic design should influence relational design.

56. Anti-Pattern — Giant Fact

A fact containing:

• hundreds of attributes,
• multiple unrelated business processes,
• mixed grains,
• customer master data,
• product master data,
• inventory snapshots,
• transactions

is not an enterprise semantic model.

It is a data dump.

Split by business process and grain.

57. Anti-Pattern — Current Master Data for Historical Reporting

Do not assume today's customer attributes can explain yesterday's business event.

If historical truth matters, model time dependency deliberately.

58. Anti-Pattern — Exposing Technical Columns

Examples:

• load timestamp,
• ETL run ID,
• hash value,
• CDC operation,
• source record ID.

These may be operationally useful but are not necessarily business semantics.

Keep technical metadata available where needed without making it the primary analytical contract.

59. Semantic Testing

Semantic testing should not stop at row counts.

Test:

Grain

Does one row represent what the model says it represents?

Measures

Do totals match trusted sources?

Dimensions

Are keys unique?

Associations

Do navigation paths return expected members?

Currency and unit

Are values associated with the correct context?

NULL behavior

Are missing values interpreted correctly?

Historical behavior

Do time-dependent attributes produce expected historical results?

60. Golden Dataset

Create a small trusted dataset containing:

• known facts,
• known dimensions,
• known keys,
• edge cases,
• NULL values,
• duplicate-key scenarios,
• multiple currencies,
• multiple units,
• historical changes.

Use it as the semantic regression suite.

61. Semantic Regression Example

Suppose the expected result is:

Customer	Revenue
C01	1,000
C02	2,000

After changing an association, the result becomes:

Customer	Revenue
C01	1,500
C02	2,000

The model may still deploy successfully.

The SQL may still execute successfully.

But the semantic contract has been broken.

Regression tests should catch this.

62. Debugging Wrong Totals

When a measure is too high:

1. Check fact grain.
2. Check duplicate fact rows.
3. Check dimension key uniqueness.
4. Check association cardinality.
5. Check many-to-many paths.
6. Check filters.
7. Check aggregation behavior.
8. Check currency/unit handling.
9. Compare before and after each relationship.

Do not immediately blame SAC or the BI tool.

The semantic model is often the source of the error.

63. Debugging Missing Members

If a customer disappears:

1. Check relationship behavior.
2. Check key nullability.
3. Check dimension completeness.
4. Check source-system scope.
5. Check filters.
6. Check historical validity.
7. Check whether the fact actually contains the customer.

Missing data is not automatically a platform defect.

64. Debugging Duplicate Members

If one customer appears multiple times:

1. Profile the dimension key.
2. Check duplicate source records.
3. Check time-dependent records.
4. Check language-dependent records.
5. Check source-system key scope.
6. Check whether a composite key is required.
7. Check whether text data was incorrectly flattened.

65. Semantic Modeling and Performance

Semantics do not eliminate physical performance concerns.

A semantically elegant model can still be expensive.

Performance depends on:

• data volume,
• relationship depth,
• source locality,
• federation,
• persistence,
• pruning,
• filter selectivity,
• join behavior,
• analytical query patterns.

Therefore:

Semantic correctness first; performance engineering immediately after the semantic contract is stable.

66. Persistence and Semantics

Persistence is not a semantic decision alone.

Ask:

• Is the source remote?
• Is the data volatile?
• Is the model reused frequently?
• Is the calculation expensive?
• Can filters be pushed down?
• Is near-real-time access required?
• What is the freshness SLA?

Use the persistence decision framework from earlier phases.

Do not persist merely because a model is semantic.

67. Semantic Modeling with Federated Data

Federation can be appropriate for:

• low-volume reference data,
• operational lookup scenarios,
• near-real-time requirements,
• sources where copying is undesirable.

Federated semantic navigation can become expensive when:

• large facts are repeatedly scanned,
• multiple remote sources are joined,
• predicates cannot be pushed down,
• network transfer becomes dominant.

Semantic modeling does not remove distributed-system costs.

68. Enterprise Semantic Architecture

A strong enterprise pattern is:

Sources → Acquisition → Preparation → Relational Model → Semantic Foundation → Analytic Models → Consumption

The semantic foundation contains reusable:

• Facts,
• Dimensions,
• Text,
• Hierarchies,
• Measures,
• Attributes,
• Associations.

The analytic model then creates a focused analytical perspective.

69. One Fact, Multiple Analytic Models

One reusable fact can support several analytic models.

Example:

Sales Fact

can support:

• Executive Sales,
• Regional Sales,
• Product Profitability,
• Customer Performance,
• Plant Performance.

The fact remains reusable.

Each analytic model can expose only the measures and dimensions needed for a particular analytical question.

70. Semantic Model vs Analytic Model

Do not confuse them.

Semantic Model

Defines reusable business meaning.

Analytic Model

Answers a specific analytical question using that semantic foundation.

Example semantic foundation:

• Sales Fact,
• Customer,
• Product,
• Calendar,
• Plant.

Possible analytic models:

• Executive Sales,
• Regional Sales,
• Product Profitability,
• Customer Performance.

71. Semantic Modeling and SAP Analytics Cloud

The modern pattern is:

Fact + Dimensions → Analytic Model → SAP Analytics Cloud

This prevents each story from independently rediscovering business definitions.

It also makes analytical calculations and model-specific selection reusable.

72. Semantic Modeling and BW/4HANA

If you know BW/4HANA, several concepts will feel familiar.

BW/4HANA concept	Datasphere conceptual bridge
ADSO / provider	Fact or relational entity depending on purpose
Characteristic	Dimension attribute
Key figure	Measure
Master data	Dimension
Text	Text entity
Hierarchy	Hierarchy
CompositeProvider	Semantic/analytical composition
Query	Analytic Model / consumption layer

This is a conceptual bridge, not a one-to-one implementation mapping.

Do not teach:

Datasphere Fact = ADSO.

Instead:

Both participate in analytical architecture, but their lifecycle, semantics, execution model and consumption patterns differ.

73. Semantic Modeling and Native HANA

If you know HANA modeling:

HANA relational/calculation logic → Datasphere relational model → Datasphere semantic model → Analytic model

HANA SQL and calculation logic solve relational computation.

Datasphere semantic modeling adds business meaning and analytical relationships.

A strong HANA developer can therefore still produce a weak Datasphere analytical model if semantics are ignored.

74. Semantic Modeling and SAP Business Data Cloud

Datasphere semantic models become more valuable when enterprise data products and analytical workloads span SAP and non-SAP domains.

The architectural principle remains:

Standardize business meaning before multiplying consumption models.

Do not create a separate definition of Customer, Product, Revenue or Supplier for every consuming application.

75. Central vs Domain Semantic Model

Central semantic model

Advantages:

• stronger conformance,
• centralized governance,
• reusable dimensions.

Risks:

• bottlenecks,
• excessive centralization,
• slower change.

Domain semantic model

Advantages:

• ownership close to business,
• faster iteration,
• domain-specific semantics.

Risks:

• duplication,
• inconsistent definitions,
• reconciliation problems.

A mature enterprise balances:

Enterprise standards + domain ownership + conformed shared semantics

76. One Fact or Multiple Facts?

Use separate facts when business processes have different grains.

Examples:

• Sales Order Item Fact
• Invoice Item Fact
• Shipment Item Fact

Do not combine them simply because they all contain:

• Customer,
• Product,
• Date,
• Amount.

Different business processes can share dimensions without sharing a fact.

77. Wide vs Narrow Dimensions

Wide dimension

Advantages:

• easy consumption,
• fewer navigation steps.

Risks:

• large model,
• governance burden,
• unnecessary attributes.

Narrow dimensions

Advantages:

• reuse,
• clear ownership,
• potentially simpler governance.

Risks:

• deeper navigation,
• more relationships.

Choose based on business semantics and consumption patterns.

78. Flatten or Associate?

Flatten attributes when:

• the attribute is essential,
• the grain is stable,
• reuse is limited,
• performance requirements justify it.

Associate when:

• the entity is reusable,
• business meaning is independent,
• master data is governed separately,
• multiple facts need the same dimension.

This is an architecture decision, not a personal modeling preference.

79. Semantic Model Review Questions

Before approving a model, ask:

1. What is the grain?
2. What is the business process?
3. What are the measures?
4. What are the dimensions?
5. What is the key of every dimension?
6. Are keys unique?
7. What are the association cardinalities?
8. Which measures are additive?
9. Which require currency?
10. Which require units?
11. Which attributes are time-dependent?
12. Which texts are language-dependent?
13. Which dimensions are conformed?
14. Which relationships are many-to-many?
15. Which fields are technical only?
16. Who owns each definition?
17. Which analytic models consume it?
18. What is the expected freshness?
19. What is the expected query volume?
20. What security applies?

If these cannot be answered, the model is not architecturally ready.

80. Hands-On Lab 1 — Customer Dimension

Create a Customer Dimension containing:

• Customer ID
• Customer Name
• Country
• Region
• Customer Group

Tasks:

1. Validate key uniqueness.
2. Set semantic usage to Dimension.
3. Assign business names.
4. Identify the key.
5. Identify analytical attributes.
6. Decide whether a text entity is required.
7. Document ownership.

Expected outcome:

A reusable Customer Dimension.

81. Hands-On Lab 2 — Sales Fact

Create a sales fact containing:

• Order ID
• Order Item
• Customer ID
• Product ID
• Order Date
• Net Value
• Quantity
• Currency Code
• Unit

Define:

One row = one sales order item.

Tasks:

1. Identify measures.
2. Identify attributes.
3. Identify keys.
4. Define aggregation behavior.
5. Define currency semantics.
6. Define quantity semantics.
7. Associate dimensions.

82. Hands-On Lab 3 — Build the Star

Create:

Customer + Product + Calendar + Plant → Sales Fact

Validate:

• key uniqueness,
• association direction,
• expected cardinality,
• measure totals,
• dimension navigation.

83. Hands-On Lab 4 — Break the Model

Intentionally duplicate a customer key.

Observe:

• association behavior,
• row multiplication,
• measure distortion.

Then repair the dimension.

Lesson:

Semantic relationships are only as reliable as their underlying keys.

84. Hands-On Lab 5 — Currency Semantics

Create facts in:

• EUR,
• USD,
• INR.

Attach currency-code semantics.

Verify that:

100 EUR + 100 USD

is not treated as:

200 of one currency

without a defined conversion context.

85. Hands-On Lab 6 — Quantity Semantics

Create:

• Product A = 100 KG
• Product B = 100 EA

Demonstrate why unit metadata matters.

Then define the appropriate unit attributes.

86. Hands-On Lab 7 — Historical Customer Region

Create two customer versions:

• C100 / Europe / 2025
• C100 / Asia / 2026

Determine how a 2025 sales report and a 2026 sales report should classify the customer.

This prepares you for advanced time-dependent modeling.

87. Hands-On Lab 8 — Conformed Dimension

Create:

Customer Dimension → Sales Fact

and:

Customer Dimension → Service Fact

Verify that both facts use the same customer definition.

Document:

• key,
• attributes,
• ownership,
• definition,
• source,
• refresh expectation.

88. Architect Exercise — Procurement Analytics

Requirement:

Procurement spend by supplier, material, purchasing organization and month.

Potential Fact:

Procurement Line Item Fact

Potential measures:

• gross spend,
• net spend,
• quantity.

Potential dimensions:

• supplier,
• material,
• purchasing organization,
• calendar.

Questions:

• What is the grain?
• What currency is spend stored in?
• What unit applies to quantity?
• Is supplier historically changing?
• Are supplier IDs globally unique?
• Are purchasing organizations shared?

Do not implement until these questions have answers.

89. Architect Exercise — Flight Analytics

Requirement:

Revenue and operational performance by flight, route, airport, aircraft and travel date.

Potential fact:

Flight Operation Fact

Potential dimensions:

• Date,
• Airport,
• Route,
• Aircraft,
• Flight.

Questions:

• What is one row?
• Is revenue at ticket level or flight level?
• Can one flight have multiple currencies?
• Is aircraft assignment historically changing?
• Does route depend on origin/destination?
• Are airport attributes conformed?

90. Architect Exercise — Finance

Requirement:

Actual cost by company code, cost center, account and posting month.

Potential fact:

Finance Posting Fact

Potential dimensions:

• Company,
• Cost Center,
• Account,
• Calendar.

Questions:

• Is amount signed?
• What is document currency?
• What is company-code currency?
• What is group currency?
• What is the posting grain?
• How are reversals represented?
• Which date is analytical time?

Never model finance measures without resolving currency and sign semantics.

91. Architect Exercise — Enterprise Customer

Design one enterprise Customer semantic entity for:

• Sales,
• Service,
• Finance,
• Procurement.

Document:

• global key,
• source-system mapping,
• business definition,
• ownership,
• attributes,
• text,
• historical behavior,
• security,
• refresh expectation.

Then identify where domain-specific customer semantics genuinely differ.

92. Architect Exercise — Many-to-Many Promotion

Requirement:

Analyze sales performance by promotion.

A customer can participate in many promotions.

A promotion can apply to many customers.

Determine whether you need:

• a bridge,
• a relationship fact,
• allocation,
• a promotion fact,
• a separate analytical model.

Explain how you prevent sales from being duplicated.

93. Architect Exercise — Metric Governance

Choose three metrics:

• Revenue,
• Margin,
• Average Order Value.

For each, document:

• business definition,
• numerator,
• denominator,
• grain,
• aggregation behavior,
• currency,
• null behavior,
• owner,
• source,
• validation rule.

Then explain which metrics can safely be summed.

94. Architect Exercise — Semantic Review Board

Pretend you are reviewing a production model.

The development team says:

"The model deploys successfully, so it is ready."

Reject or approve it using these questions:

• Is the grain documented?
• Are dimension keys unique?
• Are relationships safe?
• Are measures additive?
• Are currencies defined?
• Are units defined?
• Are historical requirements understood?
• Are business definitions owned?
• Is there a regression dataset?
• Is there a consumer use case?

The purpose is to develop architecture judgment rather than configuration memorization.

95. Troubleshooting Matrix

Symptom	Likely Cause	First Investigation
Measures too high	Duplicate relationship	Dimension key uniqueness
Customer appears multiple times	Duplicate dimension key	Dimension profile
Missing customer	Relationship/filter issue	Key and relationship
Wrong currency interpretation	Missing currency semantics	Currency code
Wrong quantity analysis	Missing unit semantics	Unit attribute
Historical classification wrong	Current-only dimension	Time dependency
Different domains disagree	Non-conformed dimensions	Definition comparison
Model difficult to consume	Excessive semantic width	Attribute review
Queries slow	Deep relationships / federation	Runtime analysis
Business users misunderstand field	Weak business definition	Semantic documentation

96. Production Acceptance Criteria

A semantic model is production-ready only when:

• grain is documented,
• keys are validated,
• measures are defined,
• dimensions are identified,
• associations are tested,
• semantic types are correct,
• currency/unit context is complete,
• historical behavior is understood,
• business ownership is assigned,
• consumer requirements are tested,
• regression cases exist,
• performance baseline exists.

Deployment success alone is not production readiness.

97. Interview Preparation

What is semantic usage?

Semantic usage defines the analytical role of an entity, such as Fact, Dimension, Text or Hierarchy.

What is a Fact?

A Fact is a semantic entity containing measurable business data, normally associated with dimensions and consumed through analytic models.

What is a Dimension?

A Dimension contains descriptive business attributes used to categorize and analyze measures.

Fact vs Analytical Dataset?

Current Datasphere architecture prefers Fact plus Analytic Model. Analytical Dataset semantic usage is deprecated.

Why are associations important?

Associations express semantic relationships between entities and enable reusable analytical navigation without embedding every relationship as a physical join in every consuming model.

What is a conformed dimension?

A dimension whose definition and keys are consistently shared across multiple business processes or facts.

Why is grain important?

Aggregation correctness, joins, measures and semantic relationships all depend on what one row represents.

Why is a percentage not additive?

Because adding percentages generally produces a mathematically incorrect result. Ratios normally need to be calculated from their underlying components.

Why does currency matter?

An amount has no complete business meaning without its currency context.

98. Production Checklist

Fact

• Grain documented
• Measures documented
• Aggregation behavior defined
• Keys validated
• Currency semantics defined
• Unit semantics defined
• Sign convention documented
• Null behavior documented

Dimension

• Key uniqueness validated
• Business attributes identified
• Text requirements assessed
• Hierarchy requirements assessed
• Time dependency assessed
• Source-system scope documented

Relationships

• Associations documented
• Cardinality validated
• Many-to-many paths reviewed
• Navigation paths tested
• Conformed dimensions identified

Governance

• Business owner assigned
• Technical owner assigned
• Definition documented
• Naming standard followed
• Sensitive attributes reviewed

Consumption

• Analytic models identified
• Required measures selected
• Required dimensions selected
• Unnecessary fields excluded
• SAC/BI use cases tested

Operations

• Lineage understood
• Dependencies documented
• Deployment dependencies understood
• Regression dataset available
• Performance baseline established

99. Final Mental Model

Remember:

DATA → GRAIN → RELATIONAL MODEL → SEMANTIC MEANING → ANALYTIC MODEL → BUSINESS QUESTION → TRUSTED ANSWER

Semantic meaning includes:

• Fact,
• Dimension,
• Text,
• Hierarchy,
• Measures,
• Attributes,
• Associations,
• Keys,
• Units,
• Currencies,
• Time behavior.

The architect's job is not simply to make data available.

The architect's job is to make the meaning of the data explicit, reusable, testable and trustworthy.

100. Architect Takeaway

A mature Datasphere semantic model should let you answer, without opening the source system:

What does this number mean?

At what grain is it stored?

How should it aggregate?

What dimension does it belong to?

How is that dimension related?

What key identifies the member?

What currency or unit applies?

Does the meaning change over time?

Which analytic models consume it?

Who owns the definition?

If the model cannot answer those questions, it is still a technical model rather than an enterprise semantic model.

Official SAP Documentation Anchors

Use current SAP documentation as the implementation reference:

• SAP Datasphere — Acquiring, Preparing, and Modeling Data
• SAP Datasphere — Specify Semantic Types for Measures and Attributes
• SAP Datasphere — Analytical Datasets (Deprecated)
• SAP Datasphere — Creating a Graphical View
• SAP Datasphere — Getting Started with SAP Datasphere
• SAP Datasphere — Consuming Data Exposed by SAP Datasphere

Version discipline: Datasphere evolves. When an implementation detail is version-sensitive, verify the current SAP Help documentation for the tenant release rather than relying on older tutorials.