SAP HANA optimize InfoCubes

[Former Member]

HANA optimized InfoCubes

Hana - InfoCubes optimized form in "SAP BW powered by SAP Hana" the counterpart to realtionalen InfoCubes in the BW system with relational database system. Although your model is focused on the main memory column-oriented structure of the HANA database, relational aspects of her relatives live on in them, so that the understanding of relational InfoCubes, even using HANA is advantageous.

Before the one-eight of HANA optimized InfoCubes is important to note that when using HANA and DataStore objects can constitute a useful data base for analysis - this was not the case for relational databases. Since DataStore objects represent data suppliers for InfoCubes in the rule (see BW design), can be completely eliminated in this way may redundate the storage of data in InfoCubes. The Exertion of HANA optimized InfoCubes is primarily a design decision in these circumstances.

An exception is the treatment of Ledegem cumulative values ​​and the observance of the request status, which are not supported by Data Store objects, that is, the use of HANA optimized InfoCubes alternative. Creating a HANA optimized InfoCubes is, as with relational data in the InfoCubes goods Housing Workbanch in the context menu of the info area, which should be subordinate to an InfoCube.

Creating a HANA optimized InfoCubes in the Data Warehousing Workbench

Newly created InfoCubes are basically as HANA optimized InfoCubes " HANA optimized InfoCubes are called in some places in BW as in-memory InfoCubes. This is especially the case if not mandatory written at the particular point is whether that is stored InfoCube row-or column -based. " Modeling a HANA optimized InfoCubes is analogous to relational InfoCubes. It measures and dimensions are included in the model , as if a star schema model . Also the restrictions that are known from relational InfoCubes are for HANA optimized InfoCubes , a maximum of 233 key figures and a maximum of 13 dimensions can be freely defined and the maximum of 248 InfoObjects contained his " despite this " that HANA itself does not require this restriction .

dimension tables

However, only the package dimension is created as a dimension table , while the master data IDs of all other characteristics are stored directly in the fact table to database. The fact table of an InfoCube HANA optimized far more like a fact table , the only line-item dimensions are modeled , but without the restriction to a maximum of 16 key fields , which is known from the ABAP Dictionary . " In the ABAP Dictionary uncompressed fact table of an InfoCube is described . In this the dimension ID is displayed for the package dimension as the primary key and all master data IDs as non-key fields . This is however only the presentation of Faktenta - table in the ABAP Dictionary , and not the actual definition in HANA .

The advantage he flat table structures with HANA optimized InfoCubes is among other things the fact that the design of the dimensions and the distribution of features on dimen-sions are for grouping and order and has no influence on the performance of de Detention Models . It does not create any large or small dimension tables that need to be optimized time-consuming under circumstances whereby the modeling of Hana - optimized Info Cubes is faster and easier than a comparable rational InfoCube.

Facts table

The fact table of an InfoCube optimized HANA is only represented by a table in the ABAP Dictionary . " The table name is the table for the fact table of the relational uncompressed InfoCube. " In fact, the table consists of multiple index partitions ren " The partition are visible in HANA Studio " whose interaction is to consider:

• 1 partition for uncompressed requests

• 1 partition for compressed requests

• 1 partition for Bestandsinitialisierungen

• 1 partition for historical resources

The latter two index partitions are created , even if it is not an InfoCube with stocks.

The purpose of the partition is partially comparable to their relational counterparts. In the de-tails , however, very significant differences are observed, which are highlighted in the following description . The interplay of partitions as further evidence of the delta index for fact table and possibly the validity table for stocks are also relevant. Below the description is divided into two topics :

               • posting in the delta index , the delta volume and the interaction of the partition tions for uncompressed and compressed requests in the context of                  compression ( delta merge and compression)

               • Dealing with stock figures ( InfoCubes with non-cumulative key figures)

As with relational InfoCubes is subject to the modeling of HANA optimized InfoCubes restrictions when data is contained in a cube. These limitations are the subject of "remodeling of HANA optimized InfoCubes described by me . "