Defining Member Keys and Names Appropriately

Defining Member Keys and Names Appropriately

Each member has both a name and an internal key. By default, these are the same, except for time levels. Both of these identifiers are strings. When you define your model, you should consider the following items:

• Very long member keys can trigger a SUBSCRIPT error. If you are working with source data that yields very long member keys, you may implement source processing in your level's sourceExpression to ensure the data is preserved in a manner of your choosing.

• It can be correct to have duplicate member names. Different people, for example, can have the same name. When a user drags and drops a member, the system uses the member key, rather than the name, in its generated query.

• InterSystems recommends that you ensure that member keys are unique in each level. Duplicate member keys make it difficult to refer to all the individual members.

  In particular, if you have duplicate member keys, users cannot reliably drill down by double-clicking.

• To help users distinguish the members, if a level has multiple members with the same name, InterSystems also recommends that you add a property to the level whose value is the same as the key. To do so, simply base the property on the same source property or source expression that the level uses.

  Then the users can display the property to help distinguish the members.

  Or add a tooltip to the level, and have that tooltip contain the member key.

The following sections describe the scenarios in which you might have duplicate member keys and names.

Ways to Generate Duplicate Member Names

Duplicate member names may or may not be undesirable, depending on your business needs.

Except for time levels, each unique source value for a level becomes a member name, by default. (For time levels, the system generates unique names for all members.)

There are only two ways in which the system can generate multiple members with the same name:

• There is a higher level in the same hierarchy. This higher level might or might not be suitable. See Defining Hierarchies Appropriately.

• You have defined a level as follows:

  • The member names are defined separately from the level definition itself.

  • The member names are based on something that is not unique.

  See Using Property Values as Member Names.

Note that InterSystems IRIS does not automatically trim leading spaces from string values as it builds the fact table. If the source data contains leading spaces, you should use a source expression that removes those. For example:

$ZSTRIP(%source.myproperty,"<W")

Otherwise, you will create multiple members with names that appear to be the same (because some of the names have extra spaces at the start).