Quantcast
Channel: Applied dimensionality » oracle
Viewing all articles
Browse latest Browse all 10

Oracle Essbase and Oracle BI 11

0
0

Just in case you missed it — read this two posts by Mark Rittman (OBIEE 11g for Hyperion Users – Are We There Yet?, Incremental Essbase Metadata Imports Now Possible with OBIEE 11g) on the oh-so painful topic of Essbase-BI integration. I participated in some projects with this combination a couple of  years ago (when BI 10g was the only option) and this experience left me very confused. Reading Mark’s cover-up for 11g — it seems a lot has changed, but still not enough (

Both Oracle BI and Essbase are totally great tools, but this 3 (or even 4) year long integration story gives us a couple interesting points to think about.

  1. Efficient MDX-generation is hard. 50+ MDX queries for a single BI 11g report are a real showstopper, since you can kill even such a mammoth as Essbsase with such load. Moreover, such query patterns (1 query for a couple of cells) negate Essbase caching and calculation efficiency. So almost all Oracle BI reports on Essbase I’ve encountered are handwritten MDX, tied to BI report by using Evaluate functions. And that’s a thing everyone should avoid.
  2. Managing OLAP metadata in relational repository is hard. When you’re trying to incorporate both conventional table structures and flatten OLAP dimensions in the same wire-model, you get cut by torn strings. Incremental OLAP model updates are very hard, since you have to preserve user changes and yet to ”find out what’s new”.

So everyone using Oracle BI + Essbase I’ve talked to end up using scheme like this:

  • Use some tool for rapid OLAP data exploration (Excel Add-In, Visual Explorer)
  • After some query layout is formally accepted — molten it in concrete by adding handwritten MDX for Oracle BI report

Given that in this OLAP + RDBMS BI scheme there’s also a problem of security settings synchronization (no built-in integration for this as well), introducing OLAP in BI system is always a big decision.

I may be overly pessimistic, but given the rate of RDBMS adapting for analytic purposes (aggregate awareness, partitioning, MPP-architecture, compression, columnar storage) and BI tools complexities when working with OLAP, we might witness slow decrease of  OLAP engines usage for reporting (whereas in areas like planning  OLAP is still unbeatable).

To cover both sides of the story I’m aware of — I’ll write about the way Cognos works with OLAP engines in next post.


Viewing all articles
Browse latest Browse all 10

Latest Images

Trending Articles





Latest Images