OBIEE 11g best practice - when to use the new "presentation hierarchies"

Question

Hi, maybe a dumb question, but what are the rules of thumb for when to expose a presentation hierarchy to end users. Obviously this must be done when using a parent / child hierarchy, as there is no level info that would allow drilling the "10g" way. However, I'm not so sure what the bonuses / drawbacks are when using level based hierarchies.
I have noticed that the SQL seems more complex and less performant when using the hierarchy. As an example, I have a simple dimension (business unit) that has a hierarchy with a total level, and 3 members in the detail level.
If I create this as a 10g style report, I add business unit column, dollar amounts, and a table total (so I can see grand total amounts), the SQL launched looks like this:
WITH
SAWITH0 AS (select sum(1) as c1,
sum(T45393.SPEND_AMOUNT) as c2,
T45273.BUSINESS_UNIT_CODE as c3
from
DIM_BUSINESS_UNIT T45273,
FACT_SPEND_ANALYTICS T45393
where ( T45273.BUSINESS_UNIT_KEY = T45393.BUSINESS_UNIT_KEY )
group by T45273.BUSINESS_UNIT_CODE)
select distinct 0 as c1,
D1.c3 as c2,
D1.c2 as c3,
D1.c1 as c4,
0 as c5,
0 as c6
from
SAWITH0 D1
This is simple and efficient, and OBIEE "knows" the grand total can be calculated by simply summing the business unit totals together.
But if I create this as an 11g style report using the presentation hierarchy, with all members selected (so I can get the detailed business units plus the grand total), the SQL is much less efficient, it actually fires two queries - one for the detail level, another for the total level:
WITH
SAWITH0 AS (select distinct sum(1) as c1,
sum(T45393.SPEND_AMOUNT) as c2
from
FACT_SPEND_ANALYTICS T45393)
select distinct 0 as c1,
NULL as c2,
'All Business Units' as c3,
1 as c4,
NULL as c5,
D1.c2 as c6,
D1.c1 as c7
from
SAWITH0 D1
AND
WITH
SAWITH0 AS (select sum(1) as c1,
sum(T45393.SPEND_AMOUNT) as c2,
T45273.BUSINESS_UNIT_CODE as c3
from
DIM_BUSINESS_UNIT T45273,
FACT_SPEND_ANALYTICS T45393
where ( T45273.BUSINESS_UNIT_KEY = T45393.BUSINESS_UNIT_KEY )
group by T45273.BUSINESS_UNIT_CODE)
select distinct 1 as c1,
D1.c3 as c2,
'All Business Units' as c3,
1 as c4,
D1.c3 as c5,
D1.c2 as c6,
D1.c1 as c7
from
SAWITH0 D1
Not only does this fire off two queries - but it doesn't use the existing cache for the "detail" level generated by the "non-hierarchy" query.
So I'm trying to figure out pros and cons of exposing hierarchies for end users. I've come up with the following:
Pros:
- Users can click on the + and - signs to drill / collapse individual members while still keeping all other members on the report
Cons:
- Queries fired at all levels, doesn't seem like it's smart enough to figure out it doesn't need to send a level query to database if all children were already queried
- In 10g if I want to expand all children (i.e. drill down all quarters to the month level) I could just click on the column header. Doesn't appear to be any way to do that using the hierarchical drills, I have to click each and every one to see all the months.
Any insights would be appreciated!
Thanks,
Scott

Answer 1

Hi, no, I haven't tried setting options such as "report based totals" - simply because I wouldn't want an option that requires users to tweak settings on each and every report they create to get stuff working efficiently.
Thanks,
Scott