virtual levels duplicate attributes

[maxchuie]

I have a situation where I have duplicate attributes names in 1  dimension but at 2 different levels so do I split them out to 2 dimensions

is there a way in to bring them back into 1 dimension with 2 levels again.  Or I am going down the wrong path?

I did read the user guide about virtual dimensions and hierarchies but cant figure it out

example
1 dimension has 2 hierarchies 1 named A  and B 
Level A
    Attribute name           Variable
    attribute name            impact rating
    ...many more
Level B
   Attribute  name         address
   attribute name          Variable

Variable attributes are the same attributes. 
The product owner did not want users to have to go to a different dimension for the attribute again
They rather not rename them to unique attributes names due to redoing report authoring

[bus_pass_man]

Yeah.  Attribute names need to be unique in a dimension for dynamic cubes. 

There's no guarantee that a report created with a FM package will work with a package which uses a dynamic cube.  MUNs, object references, even the namespaces can be different and there might not be a way to get them to conform you what you had in the FM package.  I was never able to get any of my reports to work with the dynamic cube substituted.  If you can good for you.

What's the grain of the variable attribute?  What you're being asked to do only make sense if the grain is of the higher level, level A.  The attribute value of the members of the lower level, level b, would inherit the value of their parent member.

If it's the other way around it wouldn't make sense.  Whatever value which would be assigned to the attribute would just be that of the first record encountered for the key of level a. 

For example, the attribute grain of colour in the products dimension is product detail.   You can have multiple colours for some products (they are all in personal accessories (watches and something else; can't remember)).   If you put the colour attribute into the product line level you'rd get the arbitary first colour encountered.  For example, assume that there is some camping equipment product which is pink and that this product just happens to be the first record where the value for the product line key matches camping equipment.  The report would generate 'pink' as the colour of camping equipment.  See? Meaningless.

I think that cube designer will trim any blank spaces that you try to append to one of those variable attribute names.  But even if that worked, it would break your report (even assuming that some other thing did not break your report).  Do both attributes really really really really need to be exactly the same name, especially considering that it might have been giving you bogus results all along?

If I understand correctly, you're thinking of trying to have two dimensions, one with level A and the other with level b.   You want to figure out if you could merge the dimensions and jiggle them so that level b is below level a.  It won't work.  The VC will munge the two levels together.  You can't say, use this level from this source cube and put a level from the second source cube below it in the vc.

I've never tried it but you might be able to get this to work:

1.  Create duplicate cubes which will act as the source cubes for your VC.  The only difference would be one cube would have the dimension with the attribute in level A (you would need to have level b in this dimension too.).  The second cube would have another instance of the the dimension with the attribute in level b (you would need to have level a in this dimension).

2.  Merge the cubes.

3.  Fiddle about with the measures so that you don't get them to double count.  This is the weak part; I'm not sure if it would work.  You might try to see if you can get the merge operator to not merge the measures. That probably won't work.   You might need to delete the measure references from the second source cube from the virtual measures.   

Even if that worked I don't know if a query from the second cube which uses the attribute will return results for the measures from the first source cube.  Actually I'm fairly certain that the attribute would only be able to get stuff from the second source cube.

But all that is a bit much, especially considering paragraph 2.

The general idea about how virtual cubes are implemented is this: stuff is blindly merged together based on name and position.  There's no grace, beauty, or elegance to their design, just brutal basic functionality. You need to experiment to watch it in action to get a feel for it.  Once merged you're stuck with them.  If you want to update the source cubes the only way to get that to propagate to the VC is to recreate the VC. You remember my posting yesterday where I babbled on about Platonic forms of GUI?  Virtual cubes ain't it.


Have a nice day.