MemberLabel and MemberName are the two fundamental properties of Dimension Members. Technically, they differ in only one way: MemberLabels have to be unique, while MemberNames don't.
In simple Dimensions (e.g., Scenario and Currency) the MemberLabel and MemberName of the same Dimension Member can be the same. But with more complex Dimensions (e.g., Cost Center, Customer, and Project), two different members might share the same name. Users need to resolve the naming overlap.
The question is: what values should we use for each property?
In Kepion, the default display in Forms is the MemberName. Therefore, we suggest using a descriptive value that is user-friendly as the MemberName. Users can modify MemberNames whenever needed as these values do not impact any system functions.
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
Tip: Select Show all properties to view the Member Name and other Attributes for each Member.
As a result, we want them to remain static to minimize ongoing changes to Kepion assets. Moreover, MemberLabels have to be unique. We, therefore, strongly recommend naming MemberLabels with business codes or keys such as Cost Center #, Customer ID, etc.
Consideration for External Tools
If a customer plans to use external reporting tools such as Pivot Tables or PowerBI, we will need to reconsider the values of MemberLabels. External reporting tools use MemberLabels as the default display of Dimension Members. Let's say we used codes or keys unfamiliar to users; those reports become unreadable to the target audience.
In this case, we suggest using keys followed by friendly name as the MemberLabel. Keys will make them unique, while friendly names will make them readable. Please keep in mind that the data type length of both MemberLabel and MemberName is 200, so aim for a concise value.
Manually Updating Member Labels
If we go with key + friendly name approach and there will be ongoing changes to MemberLabels, we will need to manually update the three definitional and structural areas listed above. Follow this guide to script the whole database, and use Ctrl + F to locate all areas that the old MemberLabel is used. Then update the MemberLabels in these areas one by one.