When you select architecture, you have to look beyond the same. A lot depends on the kind of OLAP Capabilities, which are being provided by the tool provider. Commercial aspects are also an important factor. There is entire tool-vendor evaluation exercise one has to go through to make a final choice. Here, we will be covering the bookish scenarios on what to use where purely from the architecture perspective.
The best bookish scenario is, when you have a relational database in your Data Warehouse designed as per Dimensional Model. A Dimensional Model in Data Warehouse ideally should not carry aggregates and that job should be left to a multi-dimensional cube in OLAP OR other reporting/end user tools accessing the Data Warehouse repository. This keeps the whole arrangement clean, and division of labor crystal clear.
HOLAP allows the Data warehouse to be maintaining its core task of maintaining detailed system of record and provide best possible design to enable end-user tools productivity. The summarization, aggregation etc. can be handled at cube level. HOLAP However, will work when there is a limit to the number of dimensions in a cube and we are not talking about large amounts of data.
This is useful for very large organizations asking for large number of cubes, dimensions and transaction details. This may however, give rise to the need of creating many aggregated schemas with in Data Warehouse. Most of the MOLAP vendors today hype on the in-efficient query and response of RDBMS storage. However, this argument partially becomes invalid, if the RDBMS design is as per Dimensional Model. |
