Author: Joyce Zhou
MemberLabel and MemberName are the two fundamental properties of Dimension Members in Kepion. Technically, there is only one difference between these two properties; MemberLabels have to be unique, while MemberNames don't.
In simple Dimensions, such as Scenario, Currency, etc., the MemberLabel and MemberName of the same Dimension Member can be the same. When it comes to more complex Dimensions, such as Cost Center, Customer, Project, etc., where two different members may have the same name, these two properties will need to be set differently. Then the question is: what values should we use for each of these?
In Kepion, the default display in Forms is the MemberName. Therefore, we suggest using a descriptive value that is user-friendly as the MemberName. MemberName values can be modified whenever needed. It will not impact any system functions.
On the other hand, MemberLabels are used in many definitional and structural areas in Kepion including:
Data Rules and SQL Rules
WHERE [AccountID] = (SELECT [MemberId] FROM [dbo].[D_Account] WHERE [MemberLabel] = N'Travel Expense')
MDX Rules and MDX Scripts
As a result, we want them to be static to minimize on-going changes to Kepion assets. Moreover, MemberLabels have to be unique. Therefore, we suggest using business codes or keys such as Cost Center #, Customer ID, etc., as the MemberLabel.
Consideration for External Tools
However, if a customer is going to use external reporting tools such as Pivot Tables or PowerBI, we will need to reconsider the values of MemberLabels, because the default display of Dimension Members in those tools are the MemberLabel. If we use codes or keys, and if users are not familiar with those codes or keys, reports may become unreadable.
Therefore, in this case, we suggest using keys followed by friendly name as the MemberLabel. Keys will make them unique, whereas friendly names will make them readable. However, please keep in mind that the data type length of both MemberLabel and MemberName are 200. The friendly name should be concise in order to keep the MemberLabel within this length.
Manually Updating Member Labels
If we go with key + friendly name approach, and if there will be on-going changes to MemberLabels, we will need to manually update the three areas we talked about above that are using MemberLabels. Follow this guide to script the whole database, and use Ctrl + F to locate all areas that the old MemberLabel is used. Then you can update the MemberLabels in these areas one by one.