TM1 Forum

When do we select element type as simple and when we do select element type as string...Simple can be either string or numeric...I ahve a confuson in this..Please clarify to me anyone?

I got 1 thread but it is not very clear to me

http://www.cognoise.com/index.php?topic=18325.0

Here in this link he is saying that last Dimension's in a cube element type should be string if the cube cell data is string otherwise simple...Is it corrcet that it depends on last dimension?

Yes, that is correct.
String elements should only exist in the last dimension (the measures dimension.)
They can exist in other dimensions but the corresponding cell is only dependent on whether the measure dimension element is string or numeric.

Yeah, I can see why you would have been confused by that thread.

Wow. That's all I'll say about that one. Just... wow.

I can also understand your confusion about the "simple" thing because Iboglix has assigned so many different names to refer to N elements (leaf, level 0, N type, simple), depending on the part of the interface involved, that older hands probably have trouble seeing it through new eyes and realising just how confusing it can be.

So here's the gist of it:
- A "simple" element is an "N" element. They mean the same thing. If you go to Dimension Editor you will see that when you want to add an N element, you are adding a "simple" element.
- A String element is an S element. Contrary to what you believed in your first post, it is NOT a "simple" element in the Dimension Editor sense. S elements are used when you want to store a string (text) in a cell.
- To store a piece of text in a cube, the S element that it is stored against must be in the last dimension of the cube. If you have S elements in any other dimensions of a cube, they are treated as N elements for the purposes of that cube. This does not stop you from having N elements in the last dimension as well if you want to store a mixture of numbers and text. But if you want to store any text at all, you must have one or more S elements in the last dimension of the cube.

dilip wrote:When do we select element type as simple and when we do select element type as string...

Short answer is - depends on what data are you trying to store and against what elements (level N/C) within your cube.

One reason for adding string elements is to store data at N and C levels for a particular hierarchy e.g. If you have a dimension with City, Region, Province, Country and you need to store data like for example the Area Manager associated with each, a String element would be the way to go (I am assuming that this may change over time, hence not an attribute).

You could also store numeric values as text in the strings where you do not want accumulation. An example of this may be where you are doing scorecarding where cities are ranked against other cities, areas against other areas. The results of the ranking (assumed calculated in Excel) would then be stored against the N and C levels as text and would not aggregate. You would not be able to store the ranking at the C level as TM1 would want to accumulate or apply a rule you have written.

Hope that answers it.

You could also store numeric values as text in the strings where you do not want accumulation. An example of this may be where you are doing scorecarding where cities are ranked against other cities, areas against other areas

What exactly you are alluding to here,I am sorry I didn't get it,Do you mean storing the values like one,two ... in the string cell .Thanks

dilip wrote:When do we select element type as simple and when we do select element type as string...

I would give a different answer than George. In a typical "business dimension" you would never use string elements, only simple numeric and consolidated. You should only have string elements in the "measure" dimension of each cube. As Alan pointed out earlier it is the element type of the last dimension in the cube that determines whether numeric or string data is stored so this is the only place where string elements are required.

String elements do have some drawbacks as they are unable to be grouped into consolidations (obviously for purely organizational reasons as strings by definition don't consolidate). For this reason some people prefer to use N & C elements only in measure dimensions and add a "helper" dimension as the last dimension of a cube that just has 2 elements "Numeric" type N and "String" type S.

BariAbdul wrote:

You could also store numeric values as text in the strings where you do not want accumulation. An example of this may be where you are doing scorecarding where cities are ranked against other cities, areas against other areas

What exactly you are alluding to here,I am sorry I didn't get it,Do you mean storing the values like one,two ... in the string cell .Thanks

I have models where the monthly ranking is required to be shown on various dashboards, at various levels within the organization. To store the outcome i.e. ranking, I have a string element against which I upload the ranking. This then allows me to have something like:
Country 1 - 3/10
-Province 1-2/4
-Province 2-1/4
-Province 3-3/4
-Province 4-4/4
--Region 1-1/5

etc. etc.

gtonkin wrote:I have models where the monthly ranking is required to be shown on various dashboards, at various levels within the organization. To store the outcome i.e. ranking, I have a string element against which I upload the ranking. This then allows me to have something like:
Country 1 - 3/10
-Province 1-2/4
-Province 2-1/4
-Province 3-3/4
-Province 4-4/4
--Region 1-1/5

etc. etc.

I have also dome a few ranking dashboards in the past using MDX in TI to get the rankings and send them into a ranking cube. I have always done it using numeric data but with flattened dimensions to enable storing values on a "consolidated" node. Using string values is a nice alternative if the data volume is not too big as strings consume more memory and limit the option to reorder the cube to optimize for memory consumption and query performance.

Thanks everyone....I appreciate your answers...Now My confusion is gone.