TM1 Forum

Dear all,

The problem i'm facing with is that one dimension was missing when we built up cubes. How can i add dimension in these cubes now?
The only way is to re-create the cubes? Pls help me to solve this issue.

Thanks in advance
Rgds
Wilson Wu

wilson wu wrote: The problem i'm facing with is that one dimension was missing when we built up cubes. How can i add dimension in these cubes now?
The only way is to re-create the cubes? Pls help me to solve this issue.

I'm afraid you will need to recreate the cubes, as you can't add a new dimension once a cube has been created.

Paul Segal wrote:

wilson wu wrote: The problem i'm facing with is that one dimension was missing when we built up cubes. How can i add dimension in these cubes now?
The only way is to re-create the cubes? Pls help me to solve this issue.

I'm afraid you will need to recreate the cubes, as you can't add a new dimension once a cube has been created.

Yes ,you're right. There's something wrong with the cubes when we design them.As a finance people ,i would say that it is to diffcult for me to recreate the cubes, but i have found an another way to solve this issue.
Many thanks for ur comments.

This is why the Best Practices team, some years ago, recommended that all cubes be created with an additional 'measure' dimension at the end. We follow that and it's saved our proverbials a number of times. Doesn't eliminate the need for cube restructuring, but reduces it a fair amount. And it's not a huge deal to rebuild a cube with an extra dimension. Main challenge is naming.

David Usherwood wrote:This is why the Best Practices team, some years ago, recommended that all cubes be created with an additional 'measure' dimension at the end. We follow that and it's saved our proverbials a number of times. Doesn't eliminate the need for cube restructuring, but reduces it a fair amount. And it's not a huge deal to rebuild a cube with an extra dimension. Main challenge is naming.

How does adding a Measure dimension to a cube solve the problem? I don't understand, unless you are implying that the Measure dimension is superfluous and using it gives you an "extra" dimension to work with so you can just replace it with the new one, when needing to add one. I don't think that's the reason a Measure dimension is best practice. It's best practice because Cognos BI, and I think a few other OLAP tools, give special properties to a Measure dimension and its a good idea to have one in your TM1 cubes to be consistent with those other tools in the case you want to integrate them.

Am dealing with a customer at the moment who wants to create 5 additional dummy dimensions in the cube in case their dataset changes and they need additional dimensions. The issue I have with this is, how is it user friendly to have to remember that 'Dimension10' is Product and 'Dimension12' is Region? It isn't.

Similarly, having a spare 'measure' dimension just-in-case you now need to add in 'Product' seems odd. How can you be sure you won't need two extra dimensions over time?

Yes, it is time-consuming to rewrite rules and TIs, but if we're going to take the approach of future-proofing cubes then why stop at one? Why not 15?

tomok wrote:

David Usherwood wrote:This is why the Best Practices team, some years ago, recommended that all cubes be created with an additional 'measure' dimension at the end. We follow that and it's saved our proverbials a number of times. Doesn't eliminate the need for cube restructuring, but reduces it a fair amount. And it's not a huge deal to rebuild a cube with an extra dimension. Main challenge is naming.

How does adding a Measure dimension to a cube solve the problem? I don't understand, unless you are implying that the Measure dimension is superfluous and using it gives you an "extra" dimension to work with so you can just replace it with the new one, when needing to add one. I don't think that's the reason a Measure dimension is best practice. It's best practice because Cognos BI, and I think a few other OLAP tools, give special properties to a Measure dimension and its a good idea to have one in your TM1 cubes to be consistent with those other tools in the case you want to integrate them.

I think it's just a way to ensure a cube designer includes a measures dimension in every cube, not for the (deprecated) "special properties" but for flexibility. For some cubes, it's obvious to have a measures dim since you're already thinking about storing many kinds of data that match up with your non-measure dimensionality, e.g. Employee cube with employee, dept, and measures dim to store salary, office location, fringe code, etc mix of strings and values.

For others, it's less so, e.g. a P&L cube. For this (or any currency-focused cube), I bet many new cube builders would easily make the mistake of having an "assumed" single-element dimension of "USD" (or whatever currency) which paints them into a corner if they ever want to add other measures (new currencies, comments, allocations, etc) without rebuilding or creating a new cube. For example:

Bad P&L Cube:

• Version
• Dept
• Account
• Period
• Year

("assumed" measures dim of local currency)

Better P&L Cube:

• Version
• Dept
• Account
• Period
• Year
• Measures

Christopher Kernahan wrote:Am dealing with a customer at the moment who wants to create 5 additional dummy dimensions in the cube in case their dataset changes and they need additional dimensions. The issue I have with this is, how is it user friendly to have to remember that 'Dimension10' is Product and 'Dimension12' is Region? It isn't.

The customer doesn't understand how OLAP works and is trying to fit it into their relational database mindset. I have never seen a good reason for "extra" dimensions-- you're just pointlessly increasing sparsity. The only times I've ever seen a real need to increase dimensionality are to add versions or a missing measures dim, both of which can be solved at the beginning by forcing them into the cube even if you don't think you want them (you will).

Matt

Just to add, the same amount of filled cells in two cubes requires more RAM for the cube with more dimensions.

jstrygner wrote:Just to add, the same amount of filled cells in two cubes requires more RAM for the cube with more dimensions.

No not really. Assuming the dimension order is optimal sparsity and number of dimensions don't affect memory consumption (or has a negligible effect). The critical factor concerning cube volume is number of populated data points. If the same data with the same number of populated numeric cells is held in 2 cubes but one cube happens to have double the dimensions then memory consumption will be the same. Its only when you start to uSE those extra dimensions and split data to a more granular level that memory consumption will increase.

I think its off topic to the thread but the correction is worth making.

lotsaram, instead of saying "I disagree" I'll just say, what my opinion was based on

About a year ago I did a test, where i had 25 dimensions with 100 elements each.
Dimensions were pretty much the same (elements like El001, El002, ..., El100) and names like Dim01, Dim02, ..., Dim25.
I created cubes: Cube03 (with dimensions Dim01, Dim02, Dim03), Cube04 (Dim01, ..., Dim04), ..., Cube25 (Dim01, ..., Dim25).
I filled them with data. Every cube had 1000 cells filled with a value of 1.
I do not remember exactly now, but am 90% sure the cells I filled were for all elements in Dim01, first 10 elements in Dim02 and first element of each remaining dimension.

Attached, you can see a simple summary of my results.

This led me to a conclusion that amount of dimensions does influence amount of RAM (which was not surprising for me, because TM1 needs to store more coordinates for values in larger cubes).
Something that would confirm this is one of my projects, where I had to rebuild one of cubes at customer's side, their cube got additional two dimensions and it became significantly bigger than the old one, although the number of filled cells was the same.

lotsaram wrote:Its only when you start to uSE those extra dimensions and split data to a more granular level that memory consumption will increase.

I am afraid I don't understand this one. If you have 5 dimensions you use 5, but if you have 10, you need to use 10.

lotsaram wrote:I think its off topic to the thread but the correction is worth making.

I put my comment because of deliberations like "Why not put additional 2 or additional 5 spare dimensions?". Assuming I was right (and that was my assumption ) this was supposed to be one of the cons.

I realise this post is old but another post which referred back to this exchange just jogged my memory on this one. http://www.tm1forum.com/viewtopic.php?f ... 082#p25063
I agree and don't dispute the fact that more dimensions equates to more memory per populated numeric cell due to having a longer address pointer. The point I was making but maybe didn't fully express at the time is that any increase in memory is relatively inexpensive when compared to the additional cube volume from adding additional dimensions. To illustrate this I have taken your table and added additional columns for the relative ratios of memory per numeric cell and increase in data sparsity. I started the ratios from an 8 dimensional cube as a basis as this would seem more typical than a 3 dimensional cube but the relativity of the results would be the same. Going from 8 dims to 25 dims results in a 2.4 times increase in bytes per cell whereas based on your sample data set the relative increase in sparsity is 10^34 times. I agree that based on your analysis that extra dimensions use extra memory (I don't think I ever disputed this or at least didn't intend to), but also based on your analysis I think it is obvious that the additional memory consumption per cell is in fact very cheap versus the additional cube volume or sparsity that is being added.

I think 2.4 x versus 10^34 x could accurately be described as "negligible" which is the point I was trying to make that additional dimensions are in general not all that significant. It is much more important to pay critical attention to whether cube dimension order is optimized as this alone can often lead to 80% + savings in memory consumption for stored data.

That said I would really interested to see this analysis repeated with:
i) a more representative and "real world" number of populated cells and sparsity
ii) cubes with optimized dimension order
... and see if these findings hold true.

Wow, these last posts are incredibly interesting from a TM1 workings point of view. Thanks guys, really insightful.

I am afraid the cubes in test given above in the table do not seem to be optimized for dimension order, as the memory per data record is too much. Hence would not think they would be good test results for deriving conclusions.

This does not mean I do not agree the conclusions. As per my observations, I agree that more dimensions mean more memory per data record in the cube (assuming the sparcity is the same and both cubes are optmized for dimension order.)