Welcome to the topic of SAP HANA modeling views.

Transcription

1 Welcome to the topic of SAP HANA modeling views. 1

2 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.

3 In this topic we describe the three types of views and how to work with them in the SAP HANA studio. 3

4 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

5 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

6 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

7 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 multidimensional 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

8 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

9 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

10 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

11 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

12 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

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

14 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.

15 This concludes introduction to the SAP HANA views. Thank you for your time. 15

16 16