BW on HANA Useful Design Patterns
When you use BW on HANA, there are more options avaiable to you for data modelling. There are design patterns available that are not possible in BW on non-HANA scenarios. Some of these have been mentioned before on SCN and in the BW on HANA OpenSAP course (see week 3).
However, I’d like to highlight some more patterns that you may not yet be familiar with. The document linked below is a PDF of potentially useful design patterns for BW on HANA scenarios:
What the document covers is summarised below:
1) Activation-less Loading / Near-Real Time BW Master Data
This pattern allows the loading of BW master data without a master data activation step. This is useful if you want to provide near real-time master data.
2) Navigational Attribute of a Navigational Attribute
This pattern allows modelling a navigational attribute of a navigational attribute.
3) Horizontal Partitioning of BW Master Data
This pattern involves partitioning master data records in a similar way to the logical partitioning of InfoProvider data. Master data can be distributed across multiple smaller InfoObjects and unioned together. This could be useful when there are very large master data volumes.
4) Vertical Partitioning of BW Master Data
This pattern involves partitioning master data records by attribute. Each partitioned InfoObject has a different structure but they share the same key. This is useful for template configuration where separate global / local master data designs are desirable, but they need viewed as one object in reporting.
5) Modelling Lifetime to Date Key Figures
Sometimes “inception to date” or “lifetime to date” key figures are required in reports over document transaction data. This design pattern describes one possible solution to this (without using any balance carry forward or non-cumulative concepts).
6) Handling BW Extraction and HANA Live Replication of Similar Data
There is a design challenge when the same source ECC data is extracted via HANA Live/SLT and via normal BW extractors. There is redundancy if the same data comes into BW via two different routes. This design pattern explains the problem and a possible solution for certain cases.