Phase 06 — Graphical Modeling

Architectural objective: learn to design SAP Datasphere Graphical Views as deliberate analytical models—not merely as diagrams of connected nodes.

Phase 05 taught data preparation and transformation. Phase 06 focuses on the central graphical modeling experience:

How do I express reusable relational logic visually, control its grain and semantics, validate its runtime behavior, and make it production-ready?

SAP documents Graphical Views as graphical query/modeling objects that can combine sources with joins and unions, refine them with filters and projections, create calculated columns, aggregate data, and define an output structure. The editor also provides SQL preview, lineage/impact analysis and runtime metrics, with Explain Plan and View Analyzer available for performance analysis.

---

1. Graphical Modeling Mental Model

Think in this sequence:

Sources
   |
   +--> Combine: Join / Union
   |
   +--> Refine: Filter / Projection
   |
   +--> Derive: Calculated Columns
   |
   +--> Summarize: Aggregation
   |
   v
Output Contract
   |
   v
Semantic / Consumption Layer

Not every view needs every operator.

A simple dimension may be:

Table → Projection → Output

A complex model may be:

Fact + Dimensions
       ↓
     Joins
       ↓
     Filters
       ↓
  Calculations
       ↓
  Aggregation
       ↓
     Output

The objective is not maximum node count. The objective is clear, correct and maintainable data logic.

---

2. Graphical View vs Data Flow

Graphical View	Data Flow
Primarily a query/modeling object	Data movement and transformation pipeline
Virtual by default	Executes a pipeline into a target
Reusable relational logic	Materialized transformation
Output is a view	Output is a target table
Good for query-time composition	Good for physical loading

SAP describes Data Flows as pipelines that transform data before writing to a target table, while Graphical Views are used to query and model sources.

Architect rule: do not select an object because its canvas looks convenient. Select it because its execution and lifecycle match the workload.

---

3. Graphical View vs SQL View

Both represent relational logic.

Prefer Graphical View when

• relationships are easier to review visually;
• standard operators are sufficient;
• lineage visibility matters;
• teams benefit from visual collaboration;
• the model will be maintained by mixed-skill teams.

Prefer SQL View when

• SQL expresses the logic more clearly;
• relational logic is complex;
• a large graphical diagram would be difficult to maintain;
• precise SQL control improves readability.

The correct question is:

Which representation makes the model easiest to understand, test, optimize and operate?

Phase 07 will go deep into SQL and SQLScript modeling.

---

4. Editor Workflow

A practical development sequence is:

Select Space
   ↓
Data Builder
   ↓
New Graphical View
   ↓
Add Sources
   ↓
Build Operators
   ↓
Configure Output
   ↓
Validate
   ↓
Preview
   ↓
Deploy
   ↓
Measure Runtime
   ↓
Review Lineage

SAP's current editor supports drag-and-drop source addition and graphical creation of joins and unions.

---

5. Source Nodes

A source is the starting point of a model.

Depending on the object and connection capabilities, sources can include:

• local tables;
• remote tables;
• views;
• supported modeling objects.

Before adding a source, write its contract:

Property	Example
Object	Purchase Order Item
Grain	PO + Item
Key	EBELN + EBELP
Volume	500 million
Freshness	Hourly
Change behavior	Delta
Important measures	Quantity, value

The key question is not:

“Can I add this source?”

It is:

“What does this source represent, what is its grain, and what execution behavior does consuming it introduce?”

---

6. Projection

Projection controls columns.

Typical uses:

• include required columns;
• exclude unused columns;
• rename columns;
• reorder columns.

SAP documents Projection as the operator for adding, removing, reordering and renaming columns.

Example:

180 source columns
       ↓
25 required columns

Projection can reduce memory, intermediate result size, processing and model complexity.

Projection is not filtering

Projection changes columns.

Filter changes rows.

---

7. Filter

A filter removes rows using a condition.

Examples:

COMPANY_CODE = '1000'
STATUS = 'OPEN'
FISCAL_YEAR >= 2026

SAP's Graphical View editor supports filter expressions.

A filter must have a reason.

Bad:

“Filter it because the dashboard is slow.”

Better:

“This reusable view intentionally represents active procurement commitments.”

Performance optimization must not silently become undocumented business logic.

---

8. Filter Placement

Consider:

Fact
 ↓
Join 500M rows
 ↓
Filter to 20M

versus:

Fact
 ↓
Safe filter to 20M
 ↓
Join

The second may be cheaper.

But never move a filter blindly. Validate:

• join semantics;
• business population;
• source pushdown;
• downstream requirements;
• delta behavior.

Optimization is valid only when semantics remain unchanged.

---

9. Join Operator

A join combines datasets according to a relationship.

Common choices:

• inner;
• left outer;
• right outer;
• full outer.

Example:

PO_ITEM
   LEFT JOIN
VENDOR

means:

Preserve the PO item population even when vendor enrichment is missing.

Choose joins from business semantics, not from whichever option produces the desired preview.

---

10. Join Conditions

A join condition must represent the actual relationship.

Simple:

PO_ITEM.VENDOR_ID = VENDOR.VENDOR_ID

Compound:

PO_ID = PO_ID
AND
PO_ITEM = PO_ITEM

Temporal:

FACT.DATE >= MASTER.VALID_FROM
AND
FACT.DATE < MASTER.VALID_TO

Language-sensitive:

MATERIAL_ID = MATERIAL_ID
AND
LANGUAGE = 'EN'

A partial key can create silent duplication.

---

11. Join Cardinality

Before a join, state:

Left grain:
1 row per PO item

Right grain:
1 row per vendor

Expected output:
1 row per PO item

If the right side contains two records per vendor:

1 PO item × 2 vendor records = 2 rows

Measures may now be duplicated.

Golden rule

Never call a join safe until its cardinality is understood and validated.

---

12. Join Explosion

When output is wrong, compare:

Rows before join
Rows after join
Distinct business keys before
Distinct business keys after
Measure totals before
Measure totals after

Example:

Before join:        100M
After join:         100M
After second join:  180M

If the intended grain did not change, the second join deserves immediate investigation.

Typical causes:

• duplicate dimension keys;
• many-to-many relationships;
• missing join predicates;
• missing validity dates;
• missing language;
• missing organizational keys.

---

13. Join Order

Join order can influence:

• intermediate row count;
• memory;
• runtime;
• readability;
• debugging.

A large fact joined to a validated small dimension may behave very differently from two large transactional datasets being joined first.

Do not optimize join order by intuition alone.

Use runtime evidence.

---

14. Union

Union combines compatible rows.

Sales_2025
    +
Sales_2026
    ↓
Sales_All

Join vs Union

Join	Union
Adds columns	Adds rows
Requires relationship	Requires compatible schema
Horizontal composition	Vertical composition

Do not use union as a substitute for a join.

---

15. Union Mapping

Define a common schema before unioning.

Example:

Source A:
CUSTOMER_ID
AMOUNT
DATE

Source B:
CLIENT_ID
VALUE
POSTING_DATE

Map:

CLIENT_ID    → CUSTOMER_ID
VALUE        → AMOUNT
POSTING_DATE → DATE

Then standardize datatypes.

A union is only as correct as its schema mapping.

---

16. Calculated Columns

Calculated Columns create derived values with SQL expressions.

Example:

NET_VALUE = QUANTITY * NET_PRICE

SAP documents calculated columns with SQL expressions, validation, functions, column selection, parameters and preview.

For every calculation ask:

• Is it deterministic?
• Is the datatype correct?
• What happens with NULL?
• Does it change grain?
• Does it belong in this layer?
• Is it reusable?
• Is it expensive?

---

17. Calculation Layering

Avoid unreadable expressions.

Instead of one huge expression:

Gross Amount
     ↓
Discount %
     ↓
Discount Amount
     ↓
Net Amount

Meaningful intermediate calculations improve reviewability.

But avoid the opposite extreme: creating separate objects for every trivial expression.

The goal is meaningful modularity.

---

18. NULL Semantics

NULL is not zero.

For example:

10 × NULL = NULL
10 × 0    = 0

Do not blindly use COALESCE(QUANTITY, 0) unless the business meaning of missing quantity is genuinely zero.

Changing unknown to zero is a data-quality decision.

---

19. CASE and Business Classification

CASE expressions are useful for classifications:

CASE
  WHEN NET_VALUE >= 1000000 THEN 'HIGH'
  WHEN NET_VALUE >= 100000 THEN 'MEDIUM'
  ELSE 'LOW'
END

But thresholds may be business policy.

Ask whether policy values should be:

• governed;
• configurable;
• parameterized;
• maintained in mapping/reference data.

Do not hard-code changing business policy without an ownership decision.

---

20. Parameters

Input parameters can provide controlled runtime variation.

Examples:

• reporting date;
• fiscal year;
• scenario;
• threshold.

Conceptually:

Parameter
   ↓
Filter / Calculation
   ↓
Result

Parameters should represent meaningful runtime choices, not be added merely to make a model appear flexible.

---

21. Currency Conversion

Currency conversion requires explicit business semantics:

• source currency;
• target currency;
• exchange-rate type;
• rate date;
• quotation direction;
• missing-rate behavior.

Do not assume:

Historical Amount × Today's Rate

is correct for historical reporting.

SAP's current documentation also lists currency conversion columns among Graphical View capabilities.

---

22. Unit Conversion

Unit conversion similarly requires:

• source unit;
• target unit;
• conversion factor/rule;
• material or business context where relevant.

Never aggregate incompatible units.

A technically valid number can still be a semantically invalid measure.

---

23. Aggregation

Aggregation changes grain.

Example:

Input:
1 row per PO item

Group:
Vendor + Month

Output:
1 row per Vendor + Month

SAP documents Aggregation as a standard Graphical View operator.

Before aggregation, document the output grain.

---

24. Measure Semantics

Additive

Examples:

• sales amount;
• order quantity.

Semi-additive

Examples:

• inventory balance;
• account balance.

Non-additive

Examples:

• ratio;
• percentage;
• unit price;
• load factor.

For a ratio, this is often more meaningful:

SUM(Numerator)
---------------
SUM(Denominator)

than:

AVG(Ratio)

The business definition decides.

---

25. Output Node

Treat the output node as the model's public contract.

For each field define:

• business meaning;
• technical name;
• business name;
• datatype;
• grain;
• measure/attribute role;
• consumer.

Example:

Field	Meaning	Grain
PO_ID	Purchase order	PO item
PO_ITEM	Item	PO item
NET_VALUE	Net item value	PO item
CURRENCY	Transaction currency	PO item
VENDOR_ID	Vendor	PO item

Do not expose every upstream technical column.

---

26. Business Names and Technical Names

Use stable technical names and human-readable business names.

Example:

Technical: NET_VALUE
Business:  Net Value

Naming is part of the data contract.

A late rename can affect downstream models and consumers.

---

27. Consumption Exposure

SAP documents Expose for Consumption for applicable views to make data available outside Datasphere through OData or ODBC/JDBC. It is not required when the view is consumed through an Analytic Model.

Therefore:

Graphical View
     |
     +--> Analytic Model
     |
     +--> External SQL/API consumption

External exposure is an architecture decision, not a checkbox to enable everywhere.

---

28. Analytical Mode

SAP provides Run in Analytical Mode for applicable exposed views. SAP documents that it sends the USE_OLAP_PLAN hint to the SQL optimizer and may improve performance, particularly for unions.

Treat this as a measured optimization.

Never enable performance options without understanding the workload.

---

29. Virtual vs Persisted Graphical Views

Graphical Views are virtual by default.

Virtual:

Consumer
   ↓
Execute View
   ↓
Sources

Persisted:

Sources
   ↓
Compute
   ↓
Stored Result
   ↓
Consumer

SAP documents persistence as a way to improve performance where appropriate.

Virtual advantages

• freshness;
• less storage;
• simpler refresh model.

Persistence advantages

• reusable physical result;
• less repeated computation;
• potentially more predictable query performance.

Persistence introduces:

• storage;
• refresh;
• freshness decisions;
• monitoring;
• recovery requirements.

---

30. Persistence Decision Framework

Ask:

1. How often is the view queried?
2. How expensive is the logic?
3. How large is the result?
4. What freshness is required?
5. Can the source handle repeated execution?
6. What is the refresh SLA?
7. Does persistence reduce total workload?

Do not persist merely because a query is slow.

Measure first.

---

31. Runtime Metrics

Runtime analysis should answer:

• Which operation is expensive?
• Which source dominates?
• How much data is processed?
• Is a join multiplying data?
• Is a union expensive?
• Is a calculation repeated?
• Would persistence help?

SAP's Graphical View tooling exposes Runtime Metrics and options for Explain Plan/View Analyzer analysis.

---

32. Generated SQL

Generated SQL is a critical bridge between graphical modeling and HANA Cloud execution.

Use it to inspect:

• selected columns;
• joins;
• filters;
• calculations;
• aggregations.

The development loop becomes:

Graphical Model
      ↓
Generated SQL
      ↓
Execution Plan
      ↓
Runtime Evidence
      ↓
Architecture Decision

SAP provides Preview SQL directly from the Graphical View tooling.

---

33. Explain Plan

Explain Plan helps investigate how the database plans to execute the model.

Look for:

• large scans;
• expensive joins;
• unexpected operations;
• large intermediate results;
• aggregation cost;
• ineffective filtering.

Do not optimize the plan by blindly moving nodes.

First verify the intended result and grain.

---

34. View Analyzer

View Analyzer is an architect-level tool.

SAP describes it as analyzing the entities composing graphical or SQL views, including consumed views, local tables and sources behind remote tables. It can help identify persistence candidates and investigate memory problems.

Use it when:

• the view is complex;
• runtime is unclear;
• memory consumption is high;
• you need dependency visibility;
• you are deciding where to persist.

---

35. Lineage and Impact Analysis

Typical dependency:

Source
  ↓
Base View
  ↓
Enrichment View
  ↓
Consumption View
  ↓
Analytic Model
  ↓
SAC / BI

A change to a source field can affect every downstream object.

SAP provides Impact and Lineage Analysis in the Graphical View tooling.

Before changing production models, inspect:

• upstream lineage;
• downstream impact.

---

36. Naming Graphical Nodes

Use names that communicate intent.

Good:

J_PO_VENDOR
P_ACTIVE_PO
CALC_NET_VALUE
AGG_VENDOR_MONTH
UNION_SALES_REGION

Avoid:

Node1
Node2
NewNode
Final2
TestNode

Readable diagrams reduce support time.

---

37. Model Layering

A practical pattern:

Source
  ↓
Base Projection
  ↓
Enrichment
  ↓
Business Transformation
  ↓
Aggregation
  ↓
Reusable Output

The layers are logical, not mandatory physical objects.

Do not create a new view for every operator.

---

38. The Giant-View Anti-Pattern

Avoid designs like:

20 sources
15 joins
12 filters
30 calculations
8 aggregations
1 enormous output

Problems:

• difficult debugging;
• poor ownership;
• difficult lineage;
• large model definitions;
• high cognitive load.

SAP notes that Graphical Views are stored in CSN files with a maximum file size of 25 MB and that very complex objects can encounter save/transport issues.

Decompose where there is a genuine business or technical boundary.

---

39. The Over-Decomposition Anti-Pattern

The opposite mistake is:

Projection 1
  ↓
Projection 2
  ↓
Projection 3
  ↓
Calculation 1
  ↓
Calculation 2
  ↓
Calculation 3

when one clear operation would suffice.

Over-decomposition creates:

• model sprawl;
• lineage noise;
• maintenance overhead;
• harder performance investigation.

Use meaningful modularity.

---

40. Reusable Enterprise Views

A reusable view should have:

• clear purpose;
• stable grain;
• stable contract;
• documented semantics;
• controlled dependencies;
• known performance characteristics.

Ask:

Can another team consume this object without reverse-engineering its logic?

If not, it is not yet a strong enterprise reusable object.

---

41. Security in Graphical Models

A view can expose sensitive information even if its transformation is technically correct.

Review:

• personal data;
• sensitive personal data;
• exposed columns;
• space permissions;
• downstream consumption;
• external exposure.

Security is part of the model contract.

---

42. Data Quality

Graphical models can surface or validate quality conditions:

VENDOR_ID IS NOT NULL
PO_ID IS NOT NULL
QUANTITY >= 0
CURRENCY IS VALID

But distinguish:

• validation;
• rejection;
• correction;
• quarantine.

Do not silently hide bad data simply to make a dashboard look clean.

---

43. Testing Strategy

Test at four levels.

Structural

• deployment;
• dependencies;
• datatypes;
• output fields.

Data

• row counts;
• null counts;
• distinct keys;
• duplicates;
• totals.

Semantic

• business rules;
• KPI definitions;
• historical behavior.

Performance

• runtime;
• memory;
• source impact;
• concurrency.

Also maintain regression tests against an approved baseline.

---

44. Golden Dataset

Build a small deterministic dataset containing:

• normal record;
• missing lookup;
• duplicate lookup;
• NULL;
• zero;
• negative amount;
• boundary date;
• deleted record;
• multiple currencies;
• multiple units.

Then test each operator.

A golden dataset makes transformation defects reproducible.

---

45. Debugging a Graphical View

Use a controlled upstream walk:

Output
  ↓
Previous Node
  ↓
Preview
  ↓
Check Grain
  ↓
Check Row Count
  ↓
Check Measures
  ↓
Repeat

Do not inspect the entire graph at once.

Binary-search the transformation path.

---

46. Debugging a Join

For every suspicious join:

1. Preview left input.
2. Preview right input.
3. Validate key uniqueness.
4. Preview join result.
5. Compare row counts.
6. Compare distinct keys.
7. Compare measure totals.
8. Check unmatched records.

This turns a complex model into controlled experiments.

---

47. Debugging an Aggregation

Check:

• grouping columns;
• aggregation type;
• input grain;
• duplicate rows;
• NULL behavior;
• expected totals.

If detail total is 1,000 and aggregate total is 1,400, investigate preceding joins before blaming the aggregation operator.

---

48. Debugging a Union

Check:

• source schema;
• datatypes;
• column mapping;
• missing columns;
• overlapping populations;
• duplicate records.

If yearly datasets are supposed to be mutually exclusive but overlap, the union can legitimately contain duplicates.

---

49. Performance Engineering

For a large graphical model:

1. Remove unnecessary columns.
2. Apply semantically safe filters early.
3. Validate join cardinality.
4. Avoid accidental many-to-many joins.
5. Aggregate only at the correct grain.
6. Avoid repeated expensive calculations.
7. Inspect generated SQL.
8. Measure runtime.
9. Use View Analyzer where appropriate.
10. Persist only when evidence supports it.

Performance optimization is evidence-driven.

---

50. SAP Datasphere + Native HANA Thinking

Your HANA background is especially useful here.

Think about:

• column pruning;
• predicate reduction;
• join cardinality;
• intermediate result size;
• pushdown;
• generated SQL;
• Explain Plan;
• runtime metrics;
• persistence.

But do not assume every classic HANA Calculation View behavior maps one-to-one to Datasphere Graphical Views.

Use HANA knowledge as a reasoning advantage, then verify Datasphere-specific behavior.

---

51. SAP Datasphere + BW Thinking

Useful conceptual bridges:

BW/4HANA concept	Datasphere conceptual bridge
Transformation logic	Graphical operators / flows
Persisted ADSO data	Local persisted tables
Composite composition	View composition
Query semantics	Semantic/analytic layer
Process Chain	Task-chain orchestration
Virtual provider patterns	Virtual modeling patterns

These are learning bridges, not one-to-one product mappings.

---

52. Production Design Pattern

A mature Graphical View has:

Defined Purpose
      ↓
Defined Grain
      ↓
Defined Sources
      ↓
Controlled Operators
      ↓
Validated Output
      ↓
Runtime Evidence
      ↓
Lineage
      ↓
Ownership

If several of these are missing, the model is not production-ready.

---

53. Hands-On Lab 1 — First Graphical View

Build:

PO_ITEM
   ↓
Projection
   ↓
Output

Tasks:

1. Add a source.
2. Identify its grain.
3. Add projection.
4. Remove unused columns.
5. Rename fields.
6. Preview.
7. Deploy.
8. Document the output contract.

Deliverable:

Reusable PO item base view.

---

54. Hands-On Lab 2 — Enrichment Join

Build:

PO_ITEM + VENDOR
        ↓
     LEFT JOIN
        ↓
   Enriched PO

Tasks:

1. Validate vendor uniqueness.
2. Define join condition.
3. Preview.
4. Compare row counts.
5. Test missing vendors.
6. Verify measures are unchanged.

Deliverable:

Join-cardinality validation record.

---

55. Hands-On Lab 3 — Union

Build:

Sales_2025
    +
Sales_2026
    ↓
Sales_All

Tasks:

1. Map columns.
2. Standardize types.
3. Add source-year indicator.
4. Check overlap.
5. Reconcile totals.

Deliverable:

Common-schema union model.

---

56. Hands-On Lab 4 — KPI Aggregation

Input:

One row per PO item.

Output:

One row per Vendor + Month.

Create:

• total value;
• total quantity;
• PO count;
• average item value.

Then reconcile KPI totals against the detailed model.

---

57. Hands-On Lab 5 — Generated SQL

Create a moderately complex view.

Tasks:

1. Preview generated SQL.
2. Identify joins.
3. Identify filters.
4. Identify calculated expressions.
5. Identify aggregations.
6. Compare SQL to the graphical diagram.
7. Identify one optimization hypothesis.

Deliverable:

Graphical model → SQL interpretation document.

---

58. Hands-On Lab 6 — Runtime Investigation

Create a model containing:

• large fact;
• enrichment join;
• calculated columns;
• aggregation.

Tasks:

1. Establish baseline.
2. Inspect Runtime Metrics.
3. Generate Explain Plan where available.
4. Run View Analyzer.
5. Identify dominant cost.
6. Test one optimization.
7. Compare before/after.

Deliverable:

Performance decision record.

---

59. Hands-On Lab 7 — View Decomposition

Start with an intentionally oversized view.

Tasks:

1. Identify logical boundaries.
2. Split it into reusable components.
3. Preserve output semantics.
4. Compare lineage.
5. Compare runtime.
6. Explain the architectural improvement.

Deliverable:

Before/after model architecture.

---

60. Architect Exercise — Enterprise Procurement

Design a Graphical View architecture for:

• 500 million PO items;
• 20 million vendors;
• 10 million materials;
• historical vendor attributes;
• multiple currencies;
• hourly consumption.

Specify:

1. Source objects.
2. Grain of every source.
3. Join keys.
4. Join strategy.
5. Projection boundaries.
6. Filter placement.
7. Calculated columns.
8. Aggregation boundary.
9. Output contract.
10. Persistence strategy.
11. Runtime analysis.
12. Security implications.

---

61. Architect Exercise — The 100x Problem

A model works at 5 million rows but will grow to 500 million.

Explain:

• which operators become risky;
• which joins need uniqueness guarantees;
• whether persistence is justified;
• whether decomposition helps;
• how you would prove the optimization;
• which metrics you would monitor.

The architect answer is not simply:

“Add more hardware.”

It is:

Understand the workload, reduce unnecessary work, and prove the resulting design.

---

62. Common Anti-Patterns

Node-driven design

Adding nodes because the canvas allows them.

Preview-driven design

Assuming sample correctness proves production correctness.

Join without grain

The most dangerous modeling mistake.

Giant view

Everything is placed into one object.

Excessive decomposition

Every trivial expression becomes an object.

Hidden business logic

Critical rules are buried in expressions.

Persist everything

Storage and refresh cost grow unnecessarily.

Never persist

Repeated expensive virtual execution creates avoidable workload.

Ignore generated SQL

The diagram looks fine while execution is misunderstood.

Optimize without measurement

Changes are made without runtime evidence.

---

63. Interview Preparation

What is a Graphical View?

A reusable graphical modeling object that combines sources and transformation operators into a queryable output structure.

Graphical View vs Data Flow?

A Graphical View primarily defines query/modeling logic; a Data Flow executes a transformation pipeline into a target table.

Why is grain important?

Because joins and aggregations can change row multiplicity and measure correctness.

What does Projection do?

Controls output columns by selecting, excluding, renaming and reordering them.

What does Filter do?

Controls which rows continue through the model.

Why can a left join duplicate data?

Because the right side can contain multiple records for the same join key.

When should you use Union?

When compatible populations should be combined vertically.

Why inspect generated SQL?

To understand what the graphical model asks the database to execute and to support performance analysis.

What is View Analyzer?

A tool for examining entities composing a view and their runtime/memory characteristics to support optimization and persistence decisions.

Should every Graphical View be persisted?

No. Persistence is a workload and performance decision.

How do you optimize a Graphical View?

Validate grain, reduce unnecessary rows/columns, control join cardinality, inspect generated SQL and runtime evidence, and persist only when justified.

---

64. Production Checklist

• Purpose documented.
• Input grain documented.
• Output grain documented.
• Sources documented.
• Join relationships documented.
• Cardinality validated.
• Projection strategy reviewed.
• Filters justified.
• Calculated columns documented.
• NULL semantics defined.
• Currency/unit logic validated.
• Aggregation grain documented.
• Output contract documented.
• Business names reviewed.
• Security reviewed.
• Consumption exposure reviewed.
• Lineage reviewed.
• Runtime measured.
• Generated SQL inspected for complex models.
• View Analyzer considered.
• Persistence decision justified.
• Regression tests defined.
• Ownership documented.
• Lifecycle/transport impact reviewed.

---

65. Architect Takeaway

The beginner asks:

“Which node should I drag?”

The developer asks:

“How do I build this transformation?”

The senior engineer asks:

“Why is this join multiplying rows?”

The architect asks:

“What is the data contract, what is the grain, what workload will this create, and how will we prove that this design remains correct and performant at enterprise scale?”

That is the level this phase is designed to teach.

Next:

Phase 07 — SQL & SQLScript Modeling

That phase will connect Datasphere SQL capabilities with HANA Cloud execution, SQL Views, supported SQL syntax, SQLScript/table functions where applicable, parameters, advanced relational logic, debugging, performance, and the decision boundary between graphical and code-based modeling.

---

Official SAP Documentation Anchors

Use these current SAP sources as implementation references:

• SAP Datasphere — Creating a Graphical View
• SAP Datasphere — Creating a Calculated Column in a Graphical View
• SAP Datasphere — Exploring Views with View Analyzer
• SAP Datasphere — Creating a Data Flow
• SAP Datasphere — Persist Data in a Graphical or SQL View