A mapping question
A mapping question
Hi Everyone, I have two cubes A and B. Both cubes have the same dimensions. What I'm trying to do is move the data between the cubes where the mapping of one of the dimensions is based on an attribute. For example, both cubes contain a dimension called 'Type'. There is data against the accounts under 'Type A'. A simple rule can move the data to cube B to Type A. But I would like to base the mapping on an attribute for the account that would say Type B. So the data would be in type A in cube A and type B in cube B based on the attribute rather than what it actually was in the source cube. Hope this sounds clear. Is there a simple way to do this. Thanks!
-
Gregor Koch
- MVP
- Posts: 263
- Joined: Fri Jun 27, 2008 12:15 am
- OLAP Product: Cognos TM1, CX
- Version: 9.0 and up
- Excel Version: 2007 and up
Re: A mapping question
Hi
Yes, there are two simple ways, one being Rules and the other being Turbo Integrator.
To tell you which one is better for you I would need to know why you have the data in two different cubes in the first place and whether the data needs to be 'live'.
If both cubes have the same dimensionality and the only difference is that the data sits in the different Type, which is a dimension in both cubes, one could argue that you don't need two cubes and a simple rule takes the values from Type A to Type B.
It could look something like this:
['Type B']=N: DB(cubename, ATTRS('Account',!account,'mapping') ,'Type A');
In your case this would also work across cubes if you replace the cubename.
Please note that you would also need the mapping the other way around for the correct feeder of this rule. Obviously it becomes more complex if there is no one to one mapping.
If you are splitting out the cubes because of concurrency, Turbo Integrator might be the better option.
Again, for a better answer I would need to know more details.
Hope that helps
Yes, there are two simple ways, one being Rules and the other being Turbo Integrator.
To tell you which one is better for you I would need to know why you have the data in two different cubes in the first place and whether the data needs to be 'live'.
If both cubes have the same dimensionality and the only difference is that the data sits in the different Type, which is a dimension in both cubes, one could argue that you don't need two cubes and a simple rule takes the values from Type A to Type B.
It could look something like this:
['Type B']=N: DB(cubename, ATTRS('Account',!account,'mapping') ,'Type A');
In your case this would also work across cubes if you replace the cubename.
Please note that you would also need the mapping the other way around for the correct feeder of this rule. Obviously it becomes more complex if there is no one to one mapping.
If you are splitting out the cubes because of concurrency, Turbo Integrator might be the better option.
Again, for a better answer I would need to know more details.
Hope that helps
Re: A mapping question
Hi Gregory, thanks for your answer! The reasoning behind the two cubes is this: The initial cube is used to collect and store 'Actual' data. Now, some of these accounts (not all) will go against a specific Type based on how they have been entered in the Actuals database. The user wants the functionality to forecast for these accounts at a Type level that is not based on what is in the actuals database. The reason for this is that not all the data has been entered against the correct 'Type' in the database and also it is easier and more meaningful to forecast some of the accounts using another Type. So in effect, the task of moving the data from the first cube to the second cube is an ETL process. At the moment, I can do all this in SQL server, and fix the data before loading it into TM1. However, I was curious to see if it was possible to do this in TM1 using a rule. I will have a go at your suggestion. Just to point out though, the Type attribute sits in the Account dimension as the change will be by account level (rather than at Type level). I hope this has made things a little clearer. Thank you!