HANA Optimized InfoCubes
The core of the new optional SAP HANA-optimized InfoCube is that when you assign characteristics and/or key figures to dimensions, while the system does not create any dimension tables except for the package dimension.
Instead, the master data identifiers (SIDs) are simply written in the fact table and the dimensional keys (DIM IDs) are no longer used, resulting in faster data read execution and data loads. In short, dimensions become logical units instead of physical data tables. The logical concept of 'dimensions' is used only to simplify the query development in BEx Query Designer.
It is important to note that since the physical star-schema tables change during the HANA optimization, any custom developed program that access InfoCubes directly instead of going through standard interfaces, will have to be re-written. I.e., companies using ODBC directly at the database level.
However, since very few companies have ventured into this area, the optional HANA InfoCube conversion will have little impact to most organization except for providing faster InfoCube performance.
To convert existing InfoCubes, simply go to the program RSDRI_CONVERT_CUBE_TO_INMEMORY and select the InfoCubes you want to convert. The job is execute in the background as a store procedure and is extremely fast. Typically, you can expect 10-20 minutes even for very large InfoCubes with hundreds of millions of rows. During the conversion, users can even query the InfoCubes. However, data loads must be suspended. Currently, traditional InfoCubes with a maximum of 233 key figures and 248 characteristics can be converted to HANA optimized InfoCubes.
After the conversion to HANA optimized InfoCubes are maintained in the SAP HANA database's column-based store and are assigned a logical index (CalculationScenario). However, if the InfoCube was stored only in BWA before the conversion, the InfoCubes are set to inactive during the conversion and you will need to re-activate it and reload the data if you want to use it.
Do I Need InfoCubes In HANA?
Many have asked, if InfoCubes are needed with a HANA system. Currently, there is significant debate/arguments on blogs and forums on the Internet on this topic. However, for the interim period there are several reasons why InfoCubes are needed:
First, transactional InfoCubes are needed for Integrated Planning and write-back options. InfoCubes are also needed to store and manage non-cumulative key figures and the RSDRI write interface only works for InfoCubes. In addition, the transition from SAP BW to HANA is simplified by allowing customers to move to the new platform without having to rewrite application logic, queries, MultiProviders and data transformations from DSOs to InfoCubes.
However, the continued use of InfoCubes has to be questioned. The propose of introducing the star-schema, snowflakes and other Dimensional Data Modeling (DDM) techniques in the 1990s was to reduce costly table joins in relational databases, while avoiding the data redundancy of data stored in 1st normal form (1NF) in Operational Data Stores (ODSs).
The removal of the relational database from HANA's in-memory processing makes most of the benefits of DDM mute, and continued use of these structures is questionable. In the future, we may see multi-layered DSOs with different data retention and granularity instead. But, for now InfoCubes will serve a transitional data storage role for most companies.