Dimension with 2 Hierarchies, Lowest Member w/ Different Long Descriptions

Question

I'm trying to create a dimension that would allow Discoverer For OLAP users to choose between different LONG DESCRIPTIONs, and I am trying to accomplish this by using multiple hierarchies.
For example, when a user is trying to create a report and eventually stumbles upon the Dimensions part of the Workbook creation, he can choose a different description other than the default by choosing from the Hierarchy drop down list.
The following is the dimension details:
Dimension: TEST_DIM
Hierarchy #1: HIER_NAME
Levels: TOTAL_DIM_NAME
        TEST_LVL_NAME
Hierarchy #2: HIER_CODE
Levels: TOTAL_DIM_CODE
        TEST_LVL_CODE
Dimension View: V_TEST_DIM
Fields: TOTAL_DIMENSION_NAME_ID   ---mapped to-->  TOTAL_DIM_NAME
        TOTAL_DIMENSION_NAME_DESC ---mapped to-->  TOTAL_DIM_NAME_LONG_DESCRIPTION
        NAME_LEVEL_ID             ---mapped to-->  TEST_LVL_NAME
        NAME_LEVEL_DESC           ---mapped to-->  TEST_LVL_NAME_LONG_DESCRIPTION
        TOTAL_DIMENSION_CODE_ID   ---mapped to-->  TOTAL_DIM_CODE
        TOTAL_DIMENSION_CODE_DESC ---mapped to-->  TOTAL_DIM_CODE_LONG_DESCRIPTION
        CODE_LEVEL_ID             ---mapped to-->  TEST_LVL_CODE
        CODE_LEVEL_DESC           ---mapped to-->  TEST_LVL_CODE_LONG_DESCRIPTION
Cube: TEST_CUBE
Measure: TEST_MEASURE
-----------------------------------------------------------------------------------------With the above dimension having 2 hierarchies, Discoverer users can choose between HIER_NAME or HIER_CODE. The problem with this setup is that for this to work, different fields must be mapped to the lowest levels of each hierarchy, because the values of NAME_LEVEL_ID and CODE_LEVEL_ID fields from the V_TEST_DIM dimension view are different from each other, even though they share the same set of records, which means they can be considered as one.
The values of NAME_LEVEL_ID and CODE_LEVEL_ID must be different, because if they are not, I receive the following error during maintenance:
***Error Occured: Data for at least One of the Hierarchies for TEST_DIM.DIMENSION controdicts the Definition of such Hierarchy as Level
Based.After making the NAME_LEVEL_ID and CODE_LEVEL_ID values different from each other, I tried mapping the fact table to the cube. Mapping details are as follows:
Cube View: V_TEST_CUBE
Fields: TEST_VALUE       --mapped to-->  TEST_MEASURE
        NAME_LEVEL_ID    --mapped to-->  TEST_DIM.TEST_LVL_NAME.NAME_LEVEL_ID
     CODE_LEVEL_ID    --mapped to-->  TEST_DIM.TEST_LVL_CODE.CODE_LEVEL_ID
-----------------------------------------------------------------------------------------Unfortunately, the above mappings does not work, because I get the following error when I do so:
Invalid Mapping:
Levels in a dimension TEST_DIM have to be mapped to the same column for summary fact_tableBut despite the error(s) above, I've actually made this work, by leaving the one ID field (NAME_LEVEL_ID or CODE_LEVEL_ID) unmapped. Say, I map NAME_LEVEL_ID to TEST_DIM.TEST_LVL_NAME.NAME_LEVEL_ID but leave CODE_LEVEL_ID unmapped, then maintain to load data for TEST_DIM (HIER_NAME hierarchy). Then I unmap NAME_LEVEL_ID and map CODE_LEVEL_ID. I maintain the cube again to load data for the other hierarchy which is HIER_CODE.
Now, if that works, why won't AWM let me map NAME_LEVEL_ID and CODE_LEVEL_ID at the same time?
I tried running the following DML command to manually map the fields:
call set_measure_key_expression('TEST_CUBE.MAPGROUP1.CUBEMAPGROUP',NA,'TEST_DIM.HIER_NAME.LEVEL\nTEST_DIM.HIER_CODE.LEVEL','VIEW_OWNER.V_TEST_DIM.NAME_LEVEL_ID\nVIEW_OWNER.V_TEST_DIM.CODE_LEVEL_ID',FALSE)I checked the mappings afterwards and the two fields are indeed mapped, but when I try to maintain, I got an error stating that 'VIEW_OWNER.V_TEST_DIM.NAME_LEVEL_ID\nVIEW_OWNER.V_TEST_DIM.CODE_LEVEL_ID' does not exits or something like that.
Does any know a better way to implement this?
Please help.

Answer 1

I understand what you are trying to achieve, and technically it should be possible. In practice, however, Disco caches dimensional information as it is not expecting information such as descriptions to change from one query to the next.
The complication is the description objects do not have any additional dimensionality beyond their base dimension, however, there is a language dimension that might be useful in this case. If you created an additional language with a formula that calls a program to set the underlying AWM language dimension you could assign this measure to the first worksheet in your workbook and allow users to swap between different versions of their long descriptions. However, this would be a session wide setting and not worksheet specific.
In the AWM tree you will need to add additional languages to your AW which can then be used a placeholders for your different descriptions. This will affect all your dimensions so you will need to either use OLAP DML to copy the base language descriptions to all the other languages or using the mapping editor.
In the dimension mapping tool you will now see multiple entry points for descriptions - English, French, German etc depending on which languages you picked. You can assign any column from your source view/table to these columns.
Should work - I did something similar for another customer. It is not ideal, and does require the users to open/create a worksheet to switch the descriptions but it was all I could think of at the time.
Keith Laker
Oracle EMEA Consulting
BI Blog: http://oraclebi.blogspot.com/
DM Blog: http://oracledmt.blogspot.com/
BI on Oracle: http://www.oracle.com/bi/
BI on OTN: http://www.oracle.com/technology/products/bi/
BI Samples: http://www.oracle.com/technology/products/bi/samples/
Does that make sense?