Working with Views for Harmonization

In SAP Datasphere, you can use the graphical view editor in the Data Builder to create a view in an intuitive graphical interface.

When building a graphical view, you can use the following objects as sources:

• (Shared) local tables
• (Shared) remote tables
• (Shared) views (graphical or SQL)
• External sources accessed through predefined connections in your space, from which you can import remote tables directly into the graphical view editor.
• Tables and views delivered into your space via an Open SQL schema

You can create views with the following semantic usage:

• Dimension
• Text
• Hierarchy
• Hierarchy with directory
• Relational dataset
• Fact

Views which are used in the harmonization layer are typically classified as view with semantic usage relational dataset. This type has the following properties:

• It contains columns with no specific analytical purpose and is essentially a flat relational view with no built-in semantic behavior.
• Columns carry no semantic type meaning for analytic engines.
• No measures are defined; all columns are treated as generic attributes with no analytical classification.
• No associations to dimensions, text entities, or hierarchies.
• Not intended for direct consumption in an analytic model or SAP Analytics Cloud story.

These are the key functions you typically use when using views in the harmonization layer:

• Projection and renaming: Use a projection to select only the columns you need and rename fields to standardize naming across different source systems.
• Filtering: Apply constant filters early in the harmonization layer to reduce the dataset size before data flows into the propagation layer. Filtering as early as possible avoids large result sets and improves downstream performance.
• Data standardization: Standardize data from different source systems using common business terminology and unified data structures.
• Calculated Columns: Add calculated columns to derive new fields or apply currency conversions, enriching the data without modifying the underlying source tables.

When you persist a view, a snapshot copy of the view's result set is created. Downstream views and dashboards built on top of it immediately start reading from the persistency table. If you remove persistence, they automatically fall back to the virtual path.

Then following options are available:

• Start data persistence (manual): Trigger a one-time snapshot from the Data Integration Monitor. The result is materialized and the view switches to Persisted status.
• Schedule persistence: Create a simple or recurring schedule to keep the persisted view up to date. You can also use task chains for coordinated refresh sequences across multiple objects.
• Remove persisted data: Switches the view back to virtual access. This is useful for freeing storage or memory, or when the view is no longer frequently queried.
• Partial persistence via input parameters: If a view uses a single input parameter with a defined default value, it can be persisted, but only for records matching that default. Views with multiple parameters or missing defaults cannot be persisted.
• Partitioned persistence: For large data volumes, you can split the persistence load into smaller partitions based on a column. This makes persistence feasible for very large views and improves refresh performance.
• Run mode selection: When triggering or scheduling persistence, you can choose between Performance-optimized for faster execution and higher memory use or Memory-optimized for lower memory footprint but slower execution.
• Persistence guidance: The built-in View Analyzer evaluates your entire lineage graph and recommends which views are best candidates for persistence, based on memory consumption, runtime metrics, and query complexity. It can also simulate persistence to estimate the memory cost before you commit.