OBIEE Report based on attribute dim or say base attribute value

Question

Hi,
I have OBIEE and Essbase implementation and have set of attribute dimensions. I am trying to understand how can I create reports in OBIEE where I can use the attribute values to filter, group, sum my fact data. For example I have a hierarchy for Dimension Supplier Geography as below -
Geography (Gen1 - Dimension)
(Gen2, Region)
(Gen3, Country)
(Gen4, Supplier Parent)
(Gen5, Supplier) (Attribute as Company Name)
Sample :
Supplier Geography
-- East
-- C1
-- PS1
-- S1 (Comp1)
-- S2 (Comp2)
-- West
-- C2
-- PS2
-- S3 (Comp1)
-- S4 (Comp2)
-- C3
-- PS3
-- S5 (Comp3)
-- S6 (Comp4)
-- North
-- C4
-- PS4
-- S7 (Comp3)
-- S8 (Comp4)
-- South
-- C5
-- PS5
-- S9 (Comp1)
-- S10 (Comp2)
Now, I would like to report where I can display information based on the attribute and display across different level. This would require to create drop down for this attribute values. For example -
A drop down showing values are Comp1, Comp2, Comp3, Comp4. When user selects Comp1 and assume that I have fact as sales amount, it should show report as below -
Comp1
Region Sales Amount
East - 10,000
West - 5,000
South - 7,000
I don't want to add a level as company as it would result in lot of redundant information. Also, I have got almost half million members and it would explode the size if I add more levels. Is there any better way to achieve this? Can I model this using alternate hierarchy? If so how would this exposed in OBIEE again?
Appreciate your inputs.
Thanks

Answer 1

If you are sure of the number of attributes the user will be using as criteria is fixed and will not change, you should able to bind the literals to page items like:
select emp.ename
from emp
join attribute_value a1 on a1.empno = emp.empno and a1.att_name = 'DEPT'
join attribute_value a2 on a2.empno = emp.empno and a2.att_name = 'SALARY'
join attribute_value a3 on a3.empno = emp.empno and a3.att_name = 'HIREDATE'
where a1.att_numeric_value = :P1_dept_value
and   a2.att_numeric_value = :P1_salary_value
and   a3.att_date_value = to_date(:P1_hiredate_value,'YYYY-MM-DD');or
select emp.ename
from emp
join attribute_value a1 on a1.empno = emp.empno and a1.att_name = :P1_att1_name
join attribute_value a2 on a2.empno = emp.empno and a2.att_name = :P1_att2_name
join attribute_value a3 on a3.empno = emp.empno and a3.att_name = :P1_att3_name
where a1.att_numeric_value = :P1_att1_value
and   a2.att_numeric_value = :P1_att2_value
and   a3.att_date_value = to_date(:P1_att3_value,'DD-MM-DD');What happens when your user wants to add another attribute and use it as search criteria. You have to:
1) add a JOIN clause to the SELECT
2) add to the WHERE clause to the SELECT
Warning personal opinion to follow: I would give up binding (i.e.. skipping parsing os the SELECT statement) for the flexibility of generating the SELECT at runtime. If the user adds a new attribute, then the PL/SQL code that assembles the SELECT statement would not have to be changed. All the meta data is stored in the database as to what the new column is and which column in the attributes table to use (ATT_NUMERIC_VALUE or ATT_DATE_VALUE). If your method of displaying the attributes and receiving the user's criteria is dynamic like my example, then you would not have to change the application at all for new attributes.
Just my 2 cents worth of opinion,
Mike