Phase 10 — Advanced Semantics & Hierarchies

Goal: Move from a correct semantic model to an enterprise semantic model that can represent organizational structures, product trees, account structures, time-dependent relationships, controlled navigation, and business hierarchies without corrupting analytical meaning.

1. Why This Phase Exists

Phase 08 established the semantic foundation.

Phase 09 turned that foundation into analytical products.

Phase 10 addresses a harder problem:

How do we represent business structure correctly when relationships are hierarchical, recursive, changing over time, or used for analytical roll-up and authorization?

Examples:

• Company → Division → Department
• Region → Country → State → City
• Product Group → Category → Product
• Account Group → Account
• Cost Center → Cost Center Group
• Employee → Manager
• Bill of Materials → Component
• Supplier Group → Supplier
• Parent Customer → Child Customer

A hierarchy is not merely a visual tree.

It can affect:

• navigation,
• aggregation,
• filtering,
• authorization,
• reporting,
• planning,
• master-data interpretation,
• historical analysis.

2. Current Datasphere Hierarchy Semantics

Current SAP Datasphere supports dedicated semantic usages for:

• Hierarchy
• Hierarchy with Directory

A Hierarchy contains parent-child relationships for members of a dimension.

A Hierarchy with Directory can contain one or more parent-child hierarchies and has an association to a directory dimension describing the available hierarchies.

This is different from simply putting a parent ID column into an arbitrary relational table.

The semantic usage tells the analytical layer what the relationship represents.

3. Hierarchy Mental Model

Think of a hierarchy as:

Members + relationships + identity + optional time validity + analytical behavior

For a simple organization:

Member	Parent
Global	—
Europe	Global
Germany	Europe
France	Europe
India	Global

The hierarchy is the relationship graph:

Global → Europe → Germany

Global → Europe → France

Global → India

4. Two Fundamental Hierarchy Shapes

There are two important modeling patterns.

Level-based hierarchy

The business structure has known levels.

Example:

Region → Country → City

Parent-child hierarchy

The structure is recursive.

Example:

Employee → Manager

or:

Cost Center → Parent Cost Center

The correct choice depends on the business structure.

5. Level-Based Hierarchy

Use a level-based hierarchy when the business defines stable conceptual levels.

Example:

Product Group → Product Category → Product

Every member has an expected place in the level structure.

Another example:

Region → Country → State → City

This makes drill-down predictable.

6. Parent-Child Hierarchy

A parent-child hierarchy represents relationships between members of the same conceptual type.

Examples:

• Employee → Manager
• Cost Center → Parent Cost Center
• Account → Parent Account
• Product → Parent Product
• Organizational Unit → Parent Organizational Unit

SAP describes parent-child hierarchies as value-based structures where a parent attribute determines the relationship; unlike level-based hierarchies, they do not require named fixed levels.

7. Level-Based vs Parent-Child

Requirement	Level-Based	Parent-Child
Fixed business levels	Excellent	Less natural
Recursive organization	Poor fit	Excellent
Employee-manager	Poor fit	Excellent
Region-country-city	Excellent	Possible but unnecessary
Cost-center tree	Possible	Excellent
Product taxonomy	Excellent	Possible
Dynamic depth	Poor fit	Excellent
Named levels	Natural	Not inherent

Architect rule:

Choose the hierarchy structure from the business relationship, not from what is easiest to draw.

8. Hierarchy Identity

A hierarchy should have a stable identity.

At minimum consider:

• hierarchy ID,
• hierarchy name,
• description,
• member ID,
• parent member ID,
• validity,
• source system,
• ownership.

For enterprise landscapes, the same business hierarchy may arrive from multiple systems.

Never assume the source member ID alone is globally unique.

9. Compound Keys

Some hierarchies require compound identity.

Example:

Controlling Area + Cost Center

A cost center ID may only be unique within a controlling area.

Therefore:

Member Key = Controlling Area + Cost Center

and:

Parent Key = Controlling Area + Parent Cost Center

This prevents accidental cross-domain relationships.

The same principle applies to:

• company + account,
• sales organization + customer,
• plant + material,
• tenant + organizational unit.

10. Parent-Child Integrity

For every parent-child hierarchy validate:

• child exists,
• parent exists unless root,
• no self-parent,
• no circular relationship,
• no unintended duplicate parents,
• compound key consistency,
• valid member identity.

A single cycle can make a hierarchy invalid.

11. Cycles

Example:

A → B

B → C

C → A

This is not a valid tree.

Detect cycles before exposing the hierarchy.

Do not rely on the consumer to discover them.

12. Multiple Parents

A strict tree normally has one parent per child.

Some business structures are naturally graphs or have multiple parents.

Example:

A product may belong to multiple categories.

Do not force a multi-parent graph into a single-parent hierarchy without defining the intended analytical behavior.

Possible strategies:

• choose a primary hierarchy,
• create separate hierarchies,
• use a bridge model,
• use a spanning-tree approach when the business explicitly accepts one selected parent.

SAP HANA provides hierarchy functions for standard parent-child, temporal, spanning-tree and leveled structures; these are useful technical bridges when advanced recursive processing is required.

13. Hierarchy with Directory

A hierarchy directory is useful when the business has multiple named hierarchies.

Example:

Cost Center Hierarchies

• Corporate
• Finance
• Operations
• Regulatory

The directory provides the catalog of available hierarchy definitions.

This is different from storing one parent-child relationship without identifying which hierarchy it belongs to.

14. Directory Architecture

Think:

Hierarchy Directory

↓

Hierarchy A

Hierarchy B

Hierarchy C

Each hierarchy can represent a different analytical view of the same underlying dimension.

This becomes powerful for:

• management reporting,
• statutory reporting,
• operational reporting,
• authorization,
• alternative organizational views.

15. Hierarchy as Master Data

A hierarchy is usually not isolated.

It depends on:

• dimension members,
• descriptions,
• keys,
• source-system ownership,
• validity,
• sometimes language.

Therefore the enterprise pattern is:

Dimension

Hierarchy

Text

Optional Directory

This gives the consumer both the member and the business structure.

16. Text in Hierarchies

A hierarchy node should be understandable to consumers.

Avoid exposing only:

CC_100023

Prefer:

100023 — Bengaluru Corporate IT

when the appropriate text is available.

For multilingual organizations, ensure that hierarchy labels can be interpreted consistently across supported languages.

17. Hierarchy and Dimension Association

The hierarchy should correspond to the dimension it organizes.

Example:

DIM_COST_CENTER

associated with:

HIER_COST_CENTER

The member keys must align.

If the hierarchy contains values not present in the dimension, decide whether those values are:

• legitimate hierarchy nodes,
• missing master data,
• obsolete members,
• data-quality defects.

Do not silently ignore them.

18. Orphan Members

An orphan member is a member that cannot be placed into the expected hierarchy.

Examples:

• child with missing parent,
• hierarchy node not found in dimension,
• inactive master-data member,
• invalid compound key.

Track orphan records explicitly.

A production hierarchy should have an agreed orphan policy.

19. Root Nodes

A hierarchy may have one or more roots.

Example:

Global

or:

North America

Europe

APJ

Multiple roots may be valid.

Do not create an artificial "Total" root merely for visual convenience unless that has a defined business meaning.

20. Leaf Nodes

Leaves have no children.

Example:

Germany → Berlin

If Berlin has no child members, Berlin is a leaf.

Analytical behavior can differ between:

• node values,
• leaf values,
• aggregated parent values.

Test both.

21. Hierarchy Levels

Level-based hierarchies have named conceptual levels.

Example:

Level 1 — Region

Level 2 — Country

Level 3 — State

Level 4 — City

Do not confuse hierarchy level with database row depth.

A parent-child hierarchy can have variable depth.

22. Depth

Parent-child hierarchies can contain:

Root → A → B → C

or:

Root → A → B → C → D → E

The depth may vary.

Do not design a parent-child hierarchy as if it had a fixed number of levels.

23. Hierarchy Navigation

Common analytical actions include:

• drill down,
• drill up,
• expand,
• collapse,
• filter at node,
• select descendants,
• select ancestors.

Navigation must preserve analytical meaning.

For example:

Selecting:

Europe

may need to include:

Germany + France + Italy + ...

depending on the consumer and hierarchy behavior.

24. Hierarchy Roll-Up

Suppose:

City	Sales
Berlin	100
Munich	200
Paris	300

Country totals can be:

Germany = 300

France = 300

Region total:

Europe = 600

This is hierarchy roll-up.

But it is only correct if:

• each leaf is counted once,
• relationships are valid,
• the measure is additive across that hierarchy.

25. Non-Additive Measures and Hierarchies

Hierarchy navigation does not magically make every measure additive.

Example:

Headcount

Germany = 100

France = 100

Europe = 200 may or may not be correct depending on the definition.

If the same employee appears in multiple organizational structures, summing can double-count.

Hierarchy design and measure semantics must be reviewed together.

26. Parent Values vs Leaf Values

There are two common business definitions:

Bottom-up aggregation

Parent value = aggregation of descendants.

Independently maintained node value

Parent value comes directly from source data.

These are not equivalent.

If source systems provide explicit parent-level postings, do not automatically recalculate them from children.

Document which interpretation applies.

27. Hierarchy and Exception Aggregation

For measures such as:

• inventory,
• headcount,
• balances,

hierarchy aggregation must be combined with the measure's aggregation semantics.

A correct hierarchy with an incorrect measure aggregation still produces incorrect results.

The analytical question is always:

What does this measure mean at this hierarchy level?

28. Time-Independent Hierarchy

A time-independent hierarchy has one structure regardless of reporting date.

Example:

Product Category → Product

where the structure does not change historically.

This is appropriate when the business relationship is stable.

29. Time-Dependent Hierarchy

A time-dependent hierarchy changes according to validity periods.

Example:

2025:

Sales Employee A → Manager X

2026:

Sales Employee A → Manager Y

If reporting organizational history matters, the hierarchy must represent its validity.

Do not overwrite history with today's organization.

30. Why Time Dependency Matters

Suppose an employee moved from:

Europe → Germany

to:

APJ → India

If a 2025 report uses today's hierarchy, historical analysis can be misleading.

Time-dependent semantics allow the analytical structure to reflect the appropriate period.

SAP distinguishes time-dependent hierarchy concepts in its hierarchy modeling documentation; historical hierarchy behavior must be designed deliberately rather than assumed.

31. Validity Intervals

A time-dependent relationship can be represented conceptually as:

Child	Parent	Valid From	Valid To
Employee A	Manager X	2025-01-01	2025-12-31
Employee A	Manager Y	2026-01-01	9999-12-31

Validate:

• no overlapping intervals,
• no gaps where continuity is required,
• valid date ordering,
• correct timezone/date semantics,
• source change history.

32. Historical Reporting

Ask:

Should a historical report use the hierarchy as it exists today or as it existed at the reporting date?

These are different analytical questions.

Current-structure reporting

"Show current organization with historical measures."

Historical-structure reporting

"Show each period according to the organization that existed then."

Do not treat them as interchangeable.

33. Key Date

A key date can determine which hierarchy version is relevant.

Conceptually:

Query Date → Valid Hierarchy Structure → Analytical Result

The exact consumer behavior depends on the supported analytical interface.

Always test the current tenant/client combination.

34. Slowly Changing Dimensions vs Time-Dependent Hierarchy

These solve related but different problems.

Slowly Changing Dimension

Preserves historical attribute values.

Example:

Employee Department changes from IT to Finance.

Time-Dependent Hierarchy

Preserves historical structural relationships.

Example:

Finance Department moves under a different Division.

You may need both.

35. Hierarchy Versioning

A business can maintain multiple hierarchy definitions.

Example:

• Management hierarchy
• Legal hierarchy
• Operational hierarchy
• Regulatory hierarchy

Do not force all use cases into one hierarchy.

The hierarchy identity should make the intended interpretation explicit.

36. Hierarchy and Security

Hierarchy semantics can participate in authorization design.

For example:

A user authorized for:

Europe

may need access to:

Germany, France, Italy...

and their descendants.

SAP Datasphere supports Data Access Controls using hierarchy values in a hierarchy with directory, where authorized hierarchy values can govern access to matching records and descendants.

This makes hierarchy correctness a security concern, not just a reporting concern.

37. Security Failure Scenario

Suppose:

Europe

contains:

• Germany
• France
• India

because of a bad parent assignment.

A hierarchy-based authorization may grant the wrong data.

Therefore:

Hierarchy data quality is security data quality.

38. Hierarchy and SAC

In SAP Analytics Cloud, hierarchies can support:

• drill-down,
• expand/collapse,
• hierarchical tables,
• navigation,
• filtering.

The exact behavior depends on the exposed model and consumer capabilities.

Test the hierarchy through the actual production consumption path.

39. Hierarchy and Excel

Hierarchy behavior in Excel-based consumption can differ from SAC presentation behavior.

Validate:

• expansion,
• filtering,
• totals,
• node selection,
• member descriptions.

Do not assume identical UX.

40. Hierarchy and SQL

SQL is useful for validating hierarchy source data.

Typical validation questions:

• Are all parents present?
• Are there duplicate children?
• Are there cycles?
• Are there overlapping validity intervals?
• Are keys unique?
• Are there orphan members?

For advanced recursive processing, HANA hierarchy functions can provide technical support for generating and navigating hierarchy structures.

41. Cycle Detection

Before production, test for cycles.

Conceptually:

A → B → C → A

must be detected.

A hierarchy is a business graph with integrity constraints.

Treat hierarchy validation like referential-integrity validation.

42. Duplicate Parent Detection

For a strict parent-child tree:

A child should not unexpectedly have:

Parent A

and:

Parent B

unless the business explicitly supports multiple parents.

Detect this before publication.

43. Orphan Detection

Find:

Child exists

but:

Parent does not exist

Possible causes:

• incomplete load,
• deleted parent,
• source-system inconsistency,
• timing issue,
• key mapping error.

Do not hide orphan records.

Track them.

44. Overlapping Validity Detection

For time-dependent relationships:

Child A → Parent X

valid:

2025-01-01 to 2025-12-31

and:

Child A → Parent Y

valid:

2025-06-01 to 2026-12-31

creates an overlap.

Unless explicitly supported, this creates ambiguity.

Validate intervals before consumption.

45. Hierarchy Data Quality Score

A useful enterprise KPI can include:

Hierarchy completeness

= valid members / expected members

Parent integrity

= children with valid parents / total children

Cycle rate

= cyclic relationships / total relationships

Validity conflict rate

= overlapping relationships / total time-dependent relationships

This turns hierarchy quality into an operational metric.

46. Hierarchy Ownership

Every production hierarchy needs an owner.

Examples:

• Finance owns Chart of Accounts hierarchy.
• HR owns Organization hierarchy.
• Procurement owns Purchasing Organization hierarchy.
• Sales owns Sales Territory hierarchy.

IT should not silently become the business owner.

47. Hierarchy Change Process

A controlled process:

1. Business proposes change.
2. Owner approves.
3. Source is updated.
4. Datasphere ingestion completes.
5. Integrity checks run.
6. Hierarchy is validated.
7. Security impact is tested.
8. Analytical regression tests run.
9. Consumer validation completes.
10. Production release occurs.

Hierarchy changes can change both reports and security.

48. Hierarchy Anti-Pattern — Flatten Everything

Flattening:

Region + Country + State + City

into a wide dimension may simplify one query.

But it does not replace semantic hierarchy behavior.

Use flattening when it genuinely simplifies a specific analytical workload, not as a universal replacement.

49. Hierarchy Anti-Pattern — Parent ID Without Semantics

A column named:

PARENT_ID

does not automatically create a governed hierarchy.

The relationship must have:

• member identity,
• parent identity,
• semantic usage,
• ownership,
• validation,
• consumption behavior.

50. Hierarchy Anti-Pattern — Overwriting History

Never overwrite historical hierarchy structure when historical reporting matters.

Maintain validity or version semantics.

51. Hierarchy Anti-Pattern — Artificial Total Node

Do not create:

TOTAL

as a hierarchy parent merely to force a visual grand total.

Analytical totals should come from the model's aggregation semantics.

52. Hierarchy Anti-Pattern — Multiple Parents Without a Rule

If a member belongs to multiple parents, define the analytical interpretation.

Otherwise different consumers may produce different totals.

53. Hierarchy Anti-Pattern — Security Before Data Quality

Do not implement hierarchy-based authorization before hierarchy integrity is proven.

Bad hierarchy + good security mechanism = secure delivery of incorrect access boundaries.

54. Hierarchy Anti-Pattern — Consumer-Specific Business Logic

Do not build one hierarchy in SAC, another in Excel and another in an application when they are intended to represent the same enterprise structure.

Centralize governed business hierarchy semantics where appropriate.

55. Advanced Semantic Type — Text

Text entities provide translated descriptions.

Think:

Code → Language → Description

Example:

1000 → EN → Germany

1000 → DE → Deutschland

Text semantics become especially important for:

• products,
• organizations,
• accounts,
• countries,
• hierarchy labels.

56. Advanced Semantic Type — Fact

A Fact contains measurable analytical data.

Hierarchy design should not change the fundamental grain of the Fact.

Example:

One Sales Order Item

remains one Sales Order Item even if the Product dimension gains a hierarchy.

57. Advanced Semantic Type — Dimension

Dimensions provide descriptive and analytical context.

A hierarchy organizes members of a dimension.

Therefore:

Dimension = members and attributes

Hierarchy = structural relationship among members

Do not merge the concepts mentally.

58. Semantic Modeling Stack

The mature semantic stack is:

Fact

↓

Dimensions

↓

Text

↓

Hierarchies

↓

Analytic Models

↓

Consumers

Each layer has a distinct responsibility.

59. Hierarchy Directory Architecture

For enterprises with multiple hierarchy definitions:

DIM_ORG

HIER_ORG_DIRECTORY

HIER_ORG_RELATIONSHIPS

can represent:

• hierarchy identity,
• hierarchy description,
• parent-child relationships.

The exact physical design depends on source and Datasphere modeling requirements.

60. Multiple Hierarchies for One Dimension

Example:

DIM_ACCOUNT

can support:

• Management hierarchy
• Statutory hierarchy
• Cash-flow hierarchy

The same account member may appear in different structures.

This is a legitimate enterprise requirement.

61. Hierarchy Selection

The consumer should know which hierarchy is active.

Do not present:

"Account Hierarchy"

when five incompatible hierarchy definitions exist.

Use business names:

• Management P&L
• Statutory P&L
• Regulatory Reporting

Naming is part of semantic governance.

62. Hierarchy and Metric Governance

A metric may behave differently under different hierarchies.

Example:

Sales

may roll up naturally across:

Product hierarchy

but a specialized allocation metric may not.

Always test critical measures against every hierarchy that consumers can select.

63. Hierarchy Regression Testing

For every important hierarchy:

Structural tests

• member count,
• parent count,
• roots,
• leaves,
• depth,
• orphan count,
• cycle count.

Analytical tests

• totals,
• drill-down,
• drill-up,
• filters,
• node selection,
• restricted measures.

Security tests

• authorized nodes,
• descendants,
• unauthorized branches.

64. Golden Hierarchy Dataset

Maintain a small known hierarchy.

Example:

Global

→ Europe

→ Germany

→ Berlin

→ Munich

→ France

→ Paris

Use this dataset to validate:

• navigation,
• roll-up,
• security,
• descriptions,
• hierarchy changes.

65. Hands-On Lab 1 — Organization Hierarchy

Create:

DIM_ORGANIZATION

with:

• Organization ID
• Organization Name
• Parent Organization ID

Build:

HIER_ORGANIZATION

Test:

• root,
• child,
• leaf,
• drill-down,
• orphan.

66. Hands-On Lab 2 — Product Level Hierarchy

Create:

Product Group → Category → Product

Build a level-based hierarchy.

Validate:

• member uniqueness,
• level ordering,
• drill-down,
• totals.

67. Hands-On Lab 3 — Employee Parent-Child

Create:

Employee → Manager

Build a parent-child hierarchy.

Test:

• multiple depth levels,
• root employees,
• orphan employees,
• invalid managers.

68. Hands-On Lab 4 — Hierarchy Directory

Create multiple organization structures:

• Management
• Legal
• Operations

Expose them through a hierarchy directory pattern.

Document:

• hierarchy ID,
• owner,
• purpose,
• validity,
• consumer.

69. Hands-On Lab 5 — Time-Dependent Organization

Create:

Employee	Manager	From	To
E01	M01	2025-01-01	2025-12-31
E01	M02	2026-01-01	9999-12-31

Test reporting for:

• 2025,

Explain why current hierarchy alone is insufficient.

70. Hands-On Lab 6 — Cycle Detection

Inject:

A → B

B → C

C → A

Build a validation query/process that detects the cycle.

Document how production ingestion should reject it.

71. Hands-On Lab 7 — Orphan Detection

Inject:

Child C → Parent X

where X does not exist.

Detect and report the orphan.

Define:

• reject,
• quarantine,
• or repair

policy.

72. Hands-On Lab 8 — Hierarchy Security

Create a hierarchy:

Global → Europe → Germany

Assign a user to Europe.

Validate whether descendants are correctly authorized according to the chosen Data Access Control design.

Test an unauthorized branch.

73. Hands-On Lab 9 — Hierarchy + Analytic Model

Create:

AM_REGIONAL_SALES

with:

• Net Sales
• Margin
• Region hierarchy

Test:

• region total,
• country drill-down,
• city drill-down,
• restricted measure,
• hierarchy filter.

74. Hands-On Lab 10 — Multiple Hierarchies

Create:

Account Management Hierarchy

and:

Account Statutory Hierarchy

Use the same Account Dimension.

Compare:

• structure,
• totals,
• drill-down,
• ownership.

75. Architect Exercise — Finance

Requirement:

CFO needs management P&L and statutory P&L from the same account master.

Design:

• Account Dimension,
• Text,
• Management Hierarchy,
• Statutory Hierarchy,
• hierarchy directory,
• Analytic Models,
• security,
• ownership.

Explain why one hierarchy is insufficient.

76. Architect Exercise — Organization

Requirement:

HR needs current organization reporting, while executives need historical organizational reporting.

Design:

• employee dimension,
• organization hierarchy,
• time-dependent relationships,
• historical semantics,
• current reporting model.

Explain the trade-off.

77. Architect Exercise — Sales Territory

Requirement:

Sales leadership changes territory ownership every quarter.

Design:

• territory hierarchy,
• validity intervals,
• ownership,
• historical reporting,
• security impact.

78. Architect Exercise — Product Taxonomy

Requirement:

Marketing uses one product taxonomy while Finance uses another.

Decide:

• one hierarchy,
• multiple hierarchies,
• separate dimensions,
• hierarchy directory.

Defend the choice.

79. Architect Exercise — Multi-Parent Product

Requirement:

A product can belong to multiple marketing categories.

Decide whether a strict hierarchy is appropriate.

Evaluate:

• primary hierarchy,
• multiple hierarchies,
• bridge model,
• graph-like representation.

Explain aggregation consequences.

80. Production Hierarchy Review

Before production:

Structure

• Member keys unique
• Parent keys valid
• Roots validated
• Leaves validated
• Cycles absent
• Orphans handled
• Multiple-parent behavior defined

Semantics

• Hierarchy type documented
• Dimension association validated
• Text validated
• Ownership assigned
• Purpose documented

Time

• Time dependency requirement assessed
• Validity intervals tested
• Historical reporting requirement documented

Analytical

• Roll-up validated
• Non-additive measures tested
• Restricted measures tested
• Hierarchy navigation tested

Security

• Data Access Control tested
• Descendant access tested
• Unauthorized branch tested
• Hierarchy change impact reviewed

Operations

• Source owner identified
• Change process defined
• Data-quality metrics monitored
• Regression dataset available

81. Enterprise Hierarchy Architecture

A mature architecture can look like:

Source Systems

↓

Master Data / Integration

↓

Dimensions

↓

Text

↓

Hierarchy / Hierarchy Directory

↓

Facts + Associations

↓

Analytic Models

↓

SAC / Excel / Supported Consumers

Security can intersect at the hierarchy layer when hierarchy-based Data Access Controls are used.

82. Architect Decision Framework

When designing a hierarchy ask:

1. What business relationship does it represent?
2. Is the structure fixed-level or recursive?
3. Is one parent guaranteed?
4. Can members have multiple parents?
5. Is the structure time-dependent?
6. Does the same dimension need multiple hierarchies?
7. Does hierarchy selection affect security?
8. Does the measure aggregate correctly through the structure?
9. Who owns the hierarchy?
10. How will changes be validated?
11. How will consumers select the correct hierarchy?
12. What is the historical reporting requirement?

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

83. Interview Preparation

What is a hierarchy in Datasphere?

A semantic object representing relationships among dimension members for analytical drill-down and navigation. Datasphere supports hierarchy and hierarchy-with-directory semantic usages.

Level-based vs parent-child?

Level-based represents defined conceptual levels. Parent-child represents recursive relationships among members of the same type.

Why use a hierarchy directory?

To manage one or more parent-child hierarchies with a directory describing the available hierarchy definitions.

Why does hierarchy quality matter for security?

Because hierarchy-based Data Access Controls can authorize a hierarchy value and its descendants. Incorrect relationships can therefore create incorrect access boundaries.

Why time-dependent hierarchies?

Because organizational or business relationships can change, and historical analysis may require the structure valid at the relevant date.

Is a parent ID column enough?

No. Enterprise hierarchy modeling requires semantic meaning, identity, integrity, ownership and validated consumption behavior.

84. Final Mental Model

Remember:

DIMENSION = WHO / WHAT

HIERARCHY = HOW MEMBERS ARE STRUCTURED

FACT = WHAT IS MEASURED

ANALYTIC MODEL = HOW THE BUSINESS QUESTION IS EXPOSED

CONSUMER = HOW USERS INTERACT WITH IT

This distinction is fundamental.

85. Architect Takeaway

A hierarchy is not decoration.

It is a governed business structure.

A strong Datasphere architect can defend:

• why the hierarchy is level-based or parent-child,
• why one or multiple hierarchies are required,
• how keys are scoped,
• how cycles and orphans are prevented,
• how history is preserved,
• how measures roll up,
• how security uses hierarchy semantics,
• how SAC consumes the structure,
• how hierarchy changes are governed,
• and what happens when the hierarchy is wrong.

The ultimate principle is:

Model the business structure once, validate it rigorously, preserve its historical meaning where required, and make every analytical and security consumer use the intended hierarchy semantics.

Official SAP Documentation Anchors

• SAP Datasphere — Acquiring, Preparing, and Modeling Data
• SAP Datasphere — Create an External Hierarchy for Drill-Down
• SAP Datasphere — Create a Hierarchy with Directory
• SAP Datasphere — Hierarchy with Directory Data Access Control
• SAP HANA Cloud — Hierarchy Functions

Version discipline: hierarchy editor behavior, supported hierarchy features, consumer behavior and security capabilities can evolve with the tenant release. Use the current SAP Help documentation for the exact tenant release before implementation.