Identify Types of SAP HANA Calculation Views

Let's first introduce the most important terminology in SAP HANA Modeling:

• A measure (such as price or volume) is a numeric value, such as a price, quantity, or volume, on which you can process arithmetic or statistics operations. For example, sum, average, top N values, and calculations.

• An attribute is an element that is used to describe a measure. Tt can be used as a filter or to split an aggregated value into single entities.

The key modeling object in SAP HANA is called a calculation view.

There are different types of calculation views. The settings are chosen when you first create the calculation view. The four data category types of calculation views are as follows:

• Dimension.

• Cube.

• Cube with Star Join.

• SQL Access Only.

The purpose of a calculation view with the data category Dimension is to define a group of related attributes, such as:

• Material
• Material color
• Material weight
• Material price

You can think of the calculation views of the data category dimension as the central master data views. You define them once and reuse them many times in other views.

Dimension data category type calculation views cannot contain measures: only attributes are allowed. This means that any numerical field such as days vacation remaining can only be defined as an attribute. This is still useful to provide supporting information about a main entity, in this case an employee. Because the field cannot be defined as a measure, you cannot calculate on it or aggregate the values.

Reporting tools usually cannot directly access calculation views of data category Dimension. It is most likely to be found as a reusable component to support a calculation view of the data category Cube with Star Join.

For time dimension views, SAP HANA has a specific type of Calculation View, called subtype Time. In a time view, only time characteristics of the same kind of calendar are allowed. The following two types of the calendar are offered:

• Gregorian: The Gregorian calendar is made up of years, months, and days. You can adjust the level of granularity, down to hours, minutes, or seconds.

• Fiscal: The fiscal calendar is organized into fiscal years and fiscal periods. Several fiscal year variants can be defined depending on your reporting needs.

The next type of calculation view is the data category Cube. This type of calculation view is used to define a data set comprised of attributes and measures, and measures are required. This means they are ideal for transactional data modeling. With measures, you can define aggregation behavior so that business users can slice and dice the data in an ad-hoc manner. Note that a Cube calculation view is not a star schema as there are no dimensions included.

Reporting tools can directly access this type of calculation view. These views can also be accessed through SQL Select statements.

Now, we come to the most powerful of all the calculation views: this is still based on the Cube type, but with an additional setting: star join. This is how we model a star schema. The foundation of this view is a cube type of calculation view, but we now join one or more dimension calculation views to the model. This provides a powerful and flexible data model that enables drill-down, slice and dice analysis over any combination of attributes and measures. Adding multiple dimensions dramatically enhances the analysis possibilities versus the simple cube type calculation views.

The Private tab shows the attributes and measures from the transaction data.

The Shared tab shows the attributes from the Calculation View–Data Category Dimension used in the Calculation View–Data Category Cube with Star Join.

Calculation views are modeled on top of each other in a stack with each calculation view consuming lower level calculation views. The basic idea is to develop reusable views. Only the lower calculation views usually consume tables. The top calculation view is the only view that must be visible to the consuming application or reporting tool.

SAP has provided a general-purpose calculation view that has the data category SQL ACCESS ONLY. This type of view is simple and is not meant for multidimensional modeling. It produces flattened result sets that can contain attributes and measures. It is not a star schema and cannot contain dimensions. It is not visible to reporting tools and is consumed only by SQL or by other calculation views. Unlike other calculation views, this view does not expose its metadata to the consuming applications. It helps to think of this type of view as an internal view that is only meant to be used within a stack.

The preceding figure explains the different types of nodes that can be used in calculation views:

• Projection nodes can be added to select existing fields, or to add extra fields. For example, you can create a calculated column to concatenate two fields, extract a substring, or add a flag indicating the record as an Actual versus Planned value record.

  (This feature is also available in the other node types, but if you need fields before the other nodes, use a projection view.)

• An Aggregation node allows a definition of an aggregation type for each measure.

• A Join node can be added to enhance the records of one view with columns from another view.

• A Union node can be added to bring values from different sources into one common set of data.

• An Intersect node only provides records that exist in both sources.

• A Minus node can be added to compare values from different sources. The minus node provides the records from one source that are not available in the other one.

• A Star Join node connects a central fact table or view with one or more dimension views.

• A Rank node can be added to keep only a top or bottom values list.

• The Semantics node represents the data flow graph end. It contains all properties and allows you to generate labels, hierarchies, semantic types, input parameters, and variables. It is the interface to the next calculation view or reporting tool.

The main benefits of using Calculation Views in SAP HANA are as follows:

• You can define a subset of data that is relevant for specific business tasks. You can make the data more meaningful than in the source tables by customizing the columns names, assigning label columns to key columns, and joining additional attributes.

• New values can be derived on the fly, for example as mathematical calculations or as substrings.

• You don't need to store any results. Different versions of views may exist without extra data storage. This is called a virtual data model (VDM).

• No aggregates need to be precalculated, and the front-end reporting tools delegate most of the data processing workload (filtering, aggregation, calculations) to the SAP HANA in-Memory engines. This achieves high performance.

• Realtime access: SAP HANA views provide immediate access to changing values, based on the data that resides in the SAP HANA database schemas and on remote data that is accessible using virtual tables.

• Reusability: Each Calculation View can be used (referenced) by other Calculation Views.

• Flexibility: Calculation Views provide various features that make them flexible. For example, defining hierarchies, filtering data, generating prompts for variables and input parameters, and performing currency conversion.

• Adaptability: An SAP HANA Calculation View can adapt its behavior to the list of columns that are selected or projected on top of it. For example, the granularity of a Rank node can be determined dynamically depending on whether your query results by Country or by Country and Customer.

• Easy to transport: SAP HANA provides powerful tools to transport information models between different SAP HANA databases. For instance, to install SAP-delivered information models, or transport your own information models between your Development, Quality Assurance, and Production landscapes.