Transfer data between "similar" dimensions

[Klaus]

Hi,

following situation: I have 3 cubes with individual product dimensions, 1 cube per saison. Now I would need a summary cube that contains all products of this saisonal cubes. Due to the structure I see no chance to have only 1 product-dimension and work with a subset per saisons cube.

Example:

Products season 1:
-brand a
--- product 1
--- product 3
-brand b
--- product 2
--- product 4

Products season 2:
-brand a
--- product 5
-brand b
--- product 6
-brand c
--- product 7

Products complete
-brand a
--- product 1
--- product 3
--- product 5
-brand b
--- product 2
--- product 4
--- product 6
-brand c
--- product 7


Is there a possibility to write a rule that maps the individual products (leaves) of a seasonal-cube to the summary cube?

Thanks for helping!
klaus

[Alan Kirk]

Hi,

following situation: I have 3 cubes with individual product dimensions, 1 cube per saison. Now I would need a summary cube that contains all products of this saisonal cubes. Due to the structure I see no chance to have only 1 product-dimension and work with a subset per saisons cube.

I don't see why not; all you'd need to do is change the "brand a" consolidation for season 1 to "Brand a season 1", the one for season 2 to "Brand a Season 2" and so on. This would in fact mean that, assuming that your other dimensions are all the same, you could dispense with the use of three cubes and load the data straight into the product code in a centralised cube. Remember that TM1 doesn't restrict you to a single hierarchy in a dimension; you can have four hierarchies, one for each season and one for the total, in the same dimension as long as you use different consolidation names in each one.

[Klaus]

Hi Allan,

That's a possible workaround - thank you very much. The labels/attributes are not so readable due to the cominbations (the hierarchy is much complexer than in my sample) but at least it should work.
I did not except to solve the problem in that way - I still think a bit in "Enterprise Planning" ways where the soulution is more comfortable - but sometimes you have to make a compromise.

So just a last question: there is no possibility to write a rule like
[leaves of dimesion X, measure 1] = [Cube2, leaves of dimension Y, measure 2]?

Thanks!
Best regards
klaus

[Alan Kirk]

Hi Allan,

That's a possible workaround - thank you very much. The labels/attributes are not so readable due to the cominbations (the hierarchy is much complexer than in my sample) but at least it should work.
I did not except to solve the problem in that way - I still think a bit in "Enterprise Planning" ways where the soulution is more comfortable - but sometimes you have to make a compromise.

So just a last question: there is no possibility to write a rule like
[leaves of dimesion X, measure 1] = [Cube2, leaves of dimension Y, measure 2]?

No, it's certainly possible. In fact if the dimension structures are all the same it's the easiest rule in existence to write. This section of the documentation ("Using DB Functions to Move Data Between Cubes ") will give you all you need to know about it. However it would be a rather inefficient solution compared to having a single cube.

Bear in mind that another alternative option is to rebuild the consolidated cube with one extra dimension called Seasons (consisting of 1, 2, 3 and the consolidation Total) and add all of the products for every season under their brands. When you do a zero suppressed view of the cube, you'll only see the products which relate to the season(s) selected from the Seasons dimension.

[Klaus]

Hi,

there are different reasons why there are 3 cubes (different planning periods, different logic in some rules, ...).

I know the db-rule and I had no problems when I move data from a cube to another with the same dimension(s).
Maybe I missunderstand something but i cannot find the solution for my problem, because I do not know how to form that rule. I could create a rule for a named product like
['Saison A','Product 1'] = N:DB('Saisoncube A', 'Product 1', !Dimension1, !Dimension2, ...);
That works for this named product

But I was not able to chance this rule to map all products.

Thanks
klaus

[Duncan P]

Do you need to get the source cube name from an attribute of the product?

Code: Select all

 DB( ATTRS('products', !products, 'source cube'), !products, ... )

Mind you I have no idea how this will perform.

HTH

[Martin Ryan]

['Saison A','Product 1'] = N:DB('Saisoncube A', 'Product 1', !Dimension1, !Dimension2, ...);

To genericize this, just get rid of the 'Product 1' hardcoding. If the names of the elements are identical in the two cubes then you can simply write
['Saison A'] = N: DB('Saisoncube A', !Product, !Dimension1, !Dimension2, ...);
Note that the element names have to be identical between the two cubes, but the two dimensions don't have to be the same dimension. But you need to write the rule in the context of the cube you're writing the rule for, so the !Product dimension needs to be the name of the product dimension in the cube you're writing the rule for, not the 'Saisoncube A' cube, otherwise you'll get a syntax error.

If the element names are not identical then, as Duncan suggest, you can just use an attribute. Again the !Product is the dimension in the cube you're writing the rule for, not the Saisoncube A.
['Saison A'] = N: DB('Saisoncube A', attrs('Product', !Product, 'Saison A Variation'), !Dimension1, !Dimension2, ...);

HTH,
Martin