Members versus Elements

Post Reply
User avatar
Steve Rowe
Site Admin
Posts: 2297
Joined: Wed May 14, 2008 4:25 pm
OLAP Product: TM1
Version: TM1 v6,v7,v8,v9,v10,v11+PAW
Excel Version: Nearly all of them

Members versus Elements

Post by Steve Rowe »

Been meaning to post on this topic for a while and this thread has triggered me to write it.

tl:dr. Members instead of elements, why do / should we care?

Members and Elements have a technical definition many may be unaware of

An element is the specific element within a hierarchy of a dimension, independent of where it may sit in a consolidation.
A member is a specific occurrence of an element within a consolidation in a hierarchy in a dimension. Also referred to as MUN or member unique name.

[dim].[Hier1].[Revenue] is an element
[dim].[Hier1].[Gross Profit^Revenue] is a member and an element can exist multiple times as a member within a hierarchy.

In the legacy client world, we didn't use the concept of member, I don't believe it was ever of importance.

In the current client world, we appear to be talking about members most of the time, crucially without realising it. This appears to drive some of the behaviour that can be a bit of a challenge to explain, for example.
  • Some of the actions / gestures in the set editor are only understandable once you know that under the hood it is working with a member not an element. Users shouldn't need to know or understand about a member versus an element. (IMO)
  • Performance issues related to functions searching over members as opposed to elements, as per the post mentioned at the top of the thread.
My understanding is that it is more technically correct to talk of a member rather than an element and that in MDX and OLAP in general there is an assumption that we are always talking about a member. In fact, the concept of an element being something different to a member doesn't really exist in MDX. (I’m drifting into areas outside my field now, so if this isn’t entirely accurate, apologies!)

I'm wondering if there are any instances where we really need to be explicit about a member versus an element TM1. As far as I can tell an element and a member will always return the same value, so is the introduction of the concept of member to TM1 unnecessary?

The only time I can think of it maybe being important is where you have differently defined consolidations in different hierarchies of the same dimension.
i.e. it is possible for [dim].[Hier1].[Revenue] to not return the same value as [dim].[Hier2].[Revenue] because Revenue has different children in the two hierarchies.
My understanding (and I could be totally wrong) is that these are references to two different elements and so shouldn't be a driver for introducing members.

Am I missing some use cases that justify the introduction of member as being the default?

Technical Director
Post Reply