Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

Welcome To The Topic of SAP HANA Modeling Views

Download as pdf or txt
Download as pdf or txt
You are on page 1of 16

Welcome to the topic of SAP HANA modeling views.

1
At the end of this topic, you will be able to describe the three types of SAP HANA modeling
views and use the SAP HANA Studio to work with views in the SAP HANA database.
In this topic we describe the three types of views and how to work with them in the SAP HANA
studio.

3
Now let us take a deeper look at the modeling views used in SAP HANA: attribute views,
analytic views and calculation views.

As we learned in an earlier topic:


Attribute views are used to model master data dimensions by joining related master data
tables.
Analytic views join transactional data with master data dimensions. Analytic views can be
enhanced by adding attribute views.
Calculation views are used for even more complex modeling, for example, when you need a
union between tables.

4
Attribute views allow us to represent tables together to give a context to measures in reporting.
Normally attribute views are built from master data tables since master data, such as business
partner details or item details, are fields that give context to measures in reporting. Attribute
views do not contain any transactional data.
Attribute views can be linked to transactional tables in analytic views. For example, we can use
the attribute view for business partners in an analytic view for transactions that contain business
partners, such as invoices. Then when we report on invoices we can aggregate invoice totals
by business partner groups and label the columns with the group names.
In the graphic, we see an attribute view composed of business master data tables connected by
table references. In every attribute view there is a key attribute which defines the key for those
attributes.
In the main table for the business partner, OCRD, you have attributes like the group code.
However, a group code such as 102 is not necessarily very meaningful in a report. Instead you
would like to see the name of the business partner group. An attribute view for a business
partner allows us to create that link between the OCRD table and the table OCRG which
contains the group names.
Attribute views also allow us to simplify the set of attributes (or properties) we would like to see
in a report. For example, we can narrow our list of attributes to business partner code, business
partner name, group name and country if we like.

5
Analytic views are typically defined on at least one table containing transactional data. This
main table is often referred to as a fact table. The fact table contains the measures in a
transaction (such as document totals) and attributes that link to master data tables or attribute
views. We design an analytic view by selecting measures from a transactional table, adding
attributes and joining attribute views.

Here we see the fact table in the center, linked to attribute tables in a star schema. We call it a
star schema because when it is shown graphically it appears to look like a star. When creating
an analytic view, we choose the measures we would like to see and link them to the attribute
views instead of the original tables. You can think of them as a fact table joined against
modeled attribute views. We can see our central fact table labeled as data foundation in the
graphic. The data foundation represents the transactional table with attribute keys. The
attribute keys can then link to attribute views. Another word often used for an attribute view in a
star schema is “dimension”.

Because of this star schema structure, an analytic view can be regarded as a cube for on-line
analytical processing (or OLAP) and for multi-dimensional queries.

One key point to remember: Analytic views only maintain data tables, views and relationships
between them. They do not store data. The query calculations will be done at runtime.

This is considered to be the fastest model in SAP HANA, so if possible we recommend this
view for analytic purposes.

6
The third type of view is the calculation view.

Basically, the calculation view is used to support additional operations, for example, the union
operation to analytic views, since analytic views cannot support union operations. So, SAP
provides the capability of unions or joins between other views by using the calculation view.

Like the analytic view, the calculation view can also be regarded as a cube during multi-
dimensional queries.

Calculation views can be created in a graphical user interface (like the other views) or as the
result of a SQL script query. In most of the complicated cases, we use a calculation view to
combine analytic views and tables. You can see from the example on this slide, this calculation
view is built upon a script.

7
SAP HANA’s semantic layers only contain models for the relationship between tables and
queries, no data.
The models include the views we just spoke about: attribute views, analytic views and
calculation views, as well as procedures.
When you run the query, the in-memory computing engine of SAP HANA pulls data from the
SAP HANA database and calculates the query results based on the views in the semantic layer.

8
Now that we have learned the definitions of each type of view, we will take a look at how we
navigate to the different functions for developing and managing views. We will use the example
of an analytic view to discuss how to use nodes to work with views.

When you are working with new or existing views, you can use the view editor to develop or
manage the views. The view is organized by nodes. Depending on the type of view, different
nodes appear.

When we look at an analytic view we see it automatically contains 3 nodes: the semantics,
logical join and data foundation nodes. The analytic view we see here in the graphic is an
analytic view for A/R invoices. Now let us discuss each node in more detail using this analytic
view as an example.

9
The node that is open appears highlighted in the Scenario pane on the left.

When you edit a view, the Semantics node opens first. The Semantics node represents the
output for the view. In this node, you can see and manage the details of the output.

10
The Logical Join node displays those tables and views you have chosen to include in the model.

In the center of the graphic we see the fact table containing the fields we have chosen. The fact
table is joined to two attribute views. The fact table is the data foundation for the view.

In this node, we can make all needed joins between the fact table and the different attribute
views we selected for our analytic view. We can set any join conditions or cardinality for the
joins.

11
Here we see the details behind the Data Foundation node. The Data Foundation contains the
table we have chosen. When we double-click on the table in the Data Foundation box, this
opens a visual of the physical table with a list of fields that can be incorporated into the final
model.

12
Now we recommend you view the demo where we take a look at modeling views in the SAP
HANA Studio.

13
Here are some key points to take away from this course.
SAP HANA’s semantic layer only contains models for the relationship between tables and
queries, no data.
At runtime, the in-memory computing engine pulls data from storage and calculates results.
The semantic layer is composed of views – attribute views, analytic views and calculation views
– and procedures.
Attribute views are used to model master data dimensions
Analytic views typically contain a fact table joined to attribute views.
Analytic views can be regarded as cubes.
Calculation views are used for even more complex modeling, for example, when you need a
union between tables.
This concludes introduction to the SAP HANA views. Thank you for your time.

15
16

You might also like