An attribute in a Fact table? It's not supposed to be there, if it's an attribute (not aggregate mesure) it's supposed to be in a dimension.
So model your fact as a degenerate dimension, set the content levels etc. as your did for your other dims and things are supposed to work fine.
However, when I add an extra attribute column from Fact A (for example TYPE columns), Fact B column seen as NULL
THOU SHALT NOT BASE ATTRIBUTE ON A FACT TABLE!
Seriously: Create a proper degenerate dimension. Attributes don't belong into a fact.
Quit copying me
As mine is before yours .... it's you copying me... But I don't mind, not your fault if a bit slow
:-P I probably clicked "Post" after you because you kept me occupied in the chat
Hi thx for your answers
Yes it is an attribute columns but it shows table data version. Meaning, fact table data has 3 versions, first, second and last. So, when I want to compare first version of Fact A, and Fact B I got the error.
Fact A: ID joined to Dim B, YEAR joined to Dim A
VERSION YEAR ID MEASURE
1 2015 100 500
2 2014 200 450
3 2011 300 345
Fact B: ID joined to Dim C, YEAR joined to Dim A
YEAR ID MEASURE
2011 45 120
2010 48 56
So, in analysis my goal is to compare first version of Fact A, and Fact B for same years.
Can't I do this?
Yes it is an attribute columns but it shows table data version. Meaning, fact table data has 3 versions, first, second and last.
Sorry I'm not following that train of thought there?
What we're saying is a very basic concept of dimensional modelling stating simply that you must not place dimensional attributes into a fact table - for OBIEE that means a logical fact table only contains measures and keys (which are never exposed and used further than the logical layer) AND an alias of the fact table (or the physical object itself again a second time but explicitly modeled) as a logical dimension holding every single column which is to be used as an attribute which can mean IDs used as attributes and measures used as attributes
Example: HR analysis for "Age" - now "Age" can mean 2 things: once a measure meaning "Average Age" across whatever dimension you analyze it or "Age" as the attribute of the specific person you are looking at. No need for 2 physical tables holding that information in a redundant way.
To make it short:
Yes you have an attribute meaning the data version in your database on the same row as your measures, but in OBIEE you must model it for what it is: an attribute and not a measure.
According to Ralph Kimball, in a data warehouse, a degenerate dimension is a dimension key in the fact table that does not have its own dimension table, because all the interesting attributes have been placed in analytic dimensions. The term "degenerate dimension" was originated by Ralph Kimball
So it's just something you must model in a different way, not that you can't use it or something else...
So basically you +1 what I wrote above :-P
Of course +1 what you (Christian) wrote above
But I'm also translating what you said in a different language so everybody understand (it's Friday)
Hahahaha yeah because Ralph is less complex in his explanations :-D