Can we group star schema database, ROLAP, client MOLAP and server MOLAP into OLAP strategies? Are there any new OLAP strategies we should be considering?


Les Barbusinski’s Answer: Your question reminds me of an insightful comment made by industrialist S.R. Hadden to Jodie Foster’s character in the movie Contact: "First rule in government spending: Why build one when you can have two for twice the price?"

Many companies do employ multiple OLAP technologies in their data warehouses, but not (usually) as the result of a deliberate architectural decision. IT organizations simply inherit a number of departmental data marts that were developed independently using disparate business intelligence technologies, and they integrate them into the enterprise data warehouse as best they can.

MOLAP and ROLAP analytic engines work on fundamentally different principles and, therefore, require different data structures, ETL logic and infrastructures. You’d have to duplicate almost everything … at "twice the price." So, although it’s possible to combine ROLAP and MOLAP technologies into an effective DW strategy, why would you want to?

Scott Howard’s Answer: Allow me to help define each of these which should help you with your own groupings. A star schema database, a database hosting a star schema, is seldom considered an OLAP strategy, but rather a data structure that is optimized for OLAP analysis or loading. ROLAP, relational OLAP solutions usually access these star schemas and are best for high-end analytical needs where the underlying data is dynamic or continually changing or restated. Let’s not worry about distinguishing between client and server MOLAP because they differ only by which machine performs some of the processing. Focusing on core MOLAP, multidimensional OLAP, these solutions provide their own data stores, which are usually a unique array structured data store organized by the dimensions required for OLAP analysis. These are also called cubes. These solutions are best for data sources that are fairly static or if your solutions can tolerate the latency associated with infrequent batched loads. Now there is a wide gap between the two technologies. What if you have dynamic data and cannot tolerate the stale data introduced that some MOLAP solutions may provide? Let’s look at how the other strategies that you should consider address this.

Some vendors offer DOLAP or distributed OLAP. It’s a MOLAP structure that mitigates the latency issue by providing cube partitioning. Its cubes are subsets of the entire master cube structure together forming all the data needed for your solution. The smaller size of these cubes combined with the partitioning feature allow you to refresh partitions faster than the entire cube and/or add new partitions with new data.

Another popular approach is HOLAP or hybrid OLAP. This architecture combines the best of ROLAP and MOLAP to provide a solution that can also address the stale data issue. HOLAP solutions use a MOLAP data store to host the most commonly accessed summarized or aggregated values. They also have transparent links to a relational structure where the detailed data resides in a star schema, much like a ROLAP solution. Most queries should be able to be sources by the MOLAP component. However, if detailed data is required, the HOLAP server will automatically drill through to the star schema and retrieve the required data just like a ROLAP solution. It truly is the best of both worlds. Both Hyperion Essbase and DB2 OLAP Server provide MOLAP, DOLAP and HOLAP options. If you’re considering other solutions, check with your vendor for their supported strategies.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access