Data Modeling:Criteria to add a logical column to a DIM or FACT table

Question

Hi,
Scenario:
Physical Layer:
- Table_T has following columns: COL_A, COL_B, COL_C
- COL_C is a measure. COL_A and COL_B refer to dimensions.
- COL_A is primary key of Table_A, COL_B is primary key of Table_B
BMM Layer:
1- Dimension table: DIM_A(TABLE_A), Fact table: contains COL_A, COL_B, COL_C
2- Dimension tables: DIM_A(TABLE_A), DIM_B(TABLE_B), Fact table: contains COL_A, COL_B, COL_C
Additional Information:
We can model the BMM layer using the above-mentioned approaches, but either of the two will have some advantages over the other to model COL_B. Some of the advantages of (2) as highlighted by the OBIEE team:
a). Drill down capability will be supported for COL_B,
b). Useful in scenarios where multiple facts need to refer to TABLE_B.
Concern:
We agree with the above technical comments but if someone can provide us with more insight on both the approaches and how an end user can benefit from either approach, it will help us a lot.
We basically need to understand what are the implications if we leave something as just an attribute on the fact and do not model it as a dimension.
Thank you,
Abhishek
P.S. The OBI Server Admin guide does provide us with useful information on the implementation aspect, but we need more information from the end user's perspective.

Answer 1

Very similar to the question below. In pure terms your FACT table should contain no Dimension attributes, Facts tables should contain measures.
Where you have a Physical table that contains a mixture of aggregates and non-aggregate Dimension Attributes then you should split them out in the logical layer into 2 Logical Tables one for the Fact one for the Dimension.
From an end user perspective (certainly the ones I have coached) it is easy for them to understand the the Measures are all in one place, and then if they need to slice and dice then they select the appropriate attributes from the Dimension folders.