Adding New Dimension In An Existing Cube (Block)

Question

Hi fellows,
Im not an expert so need you feedback.
I am supporting a cube that was built a decade ago using Essbase 6.5. It has 7 dimensions (3 dense, 4 sparse). With the new reporting requirement, I need to add a new dimension to be called "BaseTimePeriod" that seems like a Time dimension but will show the "Constant Dollar" amount calcuation for difference Scenarios.
Since the cube has been there for so long, and the expert that has pioneered that cube is no longer in the company. All of our reports uses API being called in MS Excel to retrieve data from the cube and format it the way the users wanted it to be. As well as 75% of our data are user input using the Essbase Excel Add-in, "lock/send" commands.
My problem now is that, since I need to introduce another dimension for the "Constant Dollar" calculation, is there any way that if I add a new dimension the existing process of uploading data by the users as well as retrieving data through Excel API will not be affected?
I tried to add new dimension in the R&D server that we have when I try to retrieve historical data from the cube in the Excel since there is "BaseTimePeriod" dimension before, the Excel report layout gets affected and inserts a new row placing "BaseTimePeriod" in that cell since this not yet there before. And when I try to upload data through Excel Add-in "lock/send" action, it did allow me unless I put a member from the "BaseTimePeriod" to complete the dimension member combination.
My questions now are:
1) How can I add a new dimension without impact from the historical data?
2) Is there any way to place a default value for the new dimension for the historical data so it would complete the dimension member combination, so whenever I retrieve and upload data there will be no problem?
Any insights related to this questions is highly appreciated. Thanks!
obelisk

Answer 1

If you add the new dimension to a cube that already has data, you should get a prompt when you save the outline to associate the existing data with a member from the new dimension. You will then go into a dense restructure which could take a while, depending on the size of your database. Another option would be to export your data in column format and load it into a relational table in something like SQL or Access, you can then add the new dimension to the export in the relational tool, export it back out to a text file and use a load rule to reload it.
As far as the lock & send and existing reports, in most cases, adding a new dim will result in all of those needing to be updated. This is why we try not to add new dims to existing cubes, especially ones that have been around a while.
Another thing to consider is the impact of adding a new dim. I don't know the size of your existing database, but you are going to increase it by adding a new dim and things like consolidation time and retrievals can be impacted, so you need to test all of this.
You should evaluate why you need a new dim and determine if you can achieve the same result without adding a new dim. While a new dim might be the preference in a new cube design, when dealing with something that has been around a while you might want to be creative and somewhat more compromising if it is the lesser of two evils. If everyone is committed to a rebuild then go ahead and rebuild especially if it's been around a while, there are probably other things that can stand to be cleaned up as well, but if nobody wants to deal with that, then look to see if you can get their without adding a new dim, perhaps a new roll up in a existing dim or an attribute dim. A more thorough explanation of what the business case is would help to provide an alternate solution.