What is the scope of views in HANA optimized cube?

[Former Member]

Hi,

When InfoCube is converted to HANA optimized cube, the dimensions are removed and SID tables are directly connected to facts?

I know that in extended star schema, the possibility of viewing the data is 16(dimensions) * 248(SID) and maximum number of columns in facts tables is 255 (239 key figures + 16 dimension keys + 6 system defined)

How does does this scenario replicate in HANA optimized cube?

What does fact table comprise of? What is the scope of multi dimension view?

regards

[michael_devine]

Hi,

This is as detailed as it gets.

http://www.saphana.com/servlet/JiveServlet/previewBody/1363-102-2-1810/SDN_HANA_opt_InfoCube%20FINAL...

Regards,

Michael

[Former Member]

Hi,

After reading the document I can deduce that, all dimension tables are removed and in fact tables I can see is - DIM key of Package + all SIDs + key figures

In traditional Cube there is limitation of 16 DIM keys, but do we have limitation on no of SIDs that can be in a fact table of HANA optimized cube?

For ex; If in a normal cube,  I have 16 dimensions and each dimension has 248 characteristics; when I convert it to HANA optimized, will the fact table now contain (248*16) SIDs + Key figures?

[former_member60281]

Hi Akshara,

I am also curious to know this info. Please let us know if you have the answer.

Thanks,

Alok

[FCI]

I'm pretty sure (?)  this limit did not changed. As you're supposed to be able to transport a cube from a Hana BW to a non Hana BW, the old limits have  probably been kept.

Regards,

Frederic

[Former Member]

The InfoCube in BW is represented by the BW-extended star schema with 2 fact tables (E-table with read-optimized partitioning, F-table with write/delete-optimized partitioning), dimension tables as grouping sets of characteristics and shared Masterdata tables (see figure 1 – left side). While this schema is optimized for classic RDBMS technology, it is not required for a modern in-memory database like SAP HANA. The schema can be greatly simplified by using only one fact table (HANA can perform read, write and delete operations equally fast on the same layout) and joining directly to the Masterdata tables The main benefits of such a simplified structure are •Simplified modeling: Dimensions as grouping sets of characteristics are still available in the InfoCube modeling, but they are pure metadata now. They do not impact the physical representation on the database any longer, such eliminating the need to take this aspect into account when modeling an InfoCube. I.e. there will be no more “badly” modeled InfoCubes with huge dimension tables and its corresponding negative impact on querying and loading performance. Note that there are also no more Line Item dimensions (all characteristics are physically Line Items now) and there is no need to set the high cardinality flag anymore. •Simplified re-modeling: Adding a new keyfigure to an InfoCube in BW-on-HANA is easy, since adding a column on a columnar storage is a very fast operation. But now it is also easy to move characteristics from one dimension to another dimension. This is a pure metadata change and can be done without re-modeling, but directly in the InfoCube maintenance. •Faster loading: Creating the BW-extended star schema during InfoCube load can take most of the time depending on the number of characteristics and the size of the dimension tables. The DIMIDs that represent the foreign keys to join fact tables and dimensions tables need to be looked up for new tuples or have to be created if they do not yet exists. On an average we have seen in real customer examples that loading into a HANA-optimized InfoCube is 3-5 times faster than into the Standard InfoCubes. The Query performance does not improve in general due to the HANA-optimized schema. You can find queries that benefit from the classic schema as well as queries that improve on the new schema. But the runtime difference is negligible. Note that there is one exception with respect to the table layout. We still have a package dimension table for the HANA-optimized InfoCube. Here the advantage to do very fast Request deletion is simply too big, while the effect on load performance to create the package dimension entries is negligible. Currently there are no limitations known for HANA-optimized InfoCubes, also InfoCubes with noncumulative keyfigures can be converted (also if data is loaded via a “3.x dataflow” (Update rules) – we, of course, strongly recommend to switch to the new dataflow (DTP) logic, as they benefit a lot more from HANA than the old ones!). We therefore recommend to convert all InfoCubes to the new HANA-optimized type, but this can be done step-by-step and the conversion can run in load windows over night or on weekends. As for InfoCubes in a classic BW system, a maximum of 233 keyfigures, 16 dimensions, and 248 characteristics can be modeled for a HANA-optimized InfoCube.