Behave as member property

[Version: 2024 - April]
[Build: 24.05.03003] 

In BI terminology, a 'Member Property' can be defined as any additional piece of information that can be added to an existing dimension with a 1:1 relation.

E.g., if you have a Customer dimension with the Customer Name, you can add all the customer's other formal information as member properties - formal information such as: 

• Address
• Phone number
• Email address
• Etc.

Typically, you will achieve a performance gain when working with member properties. (Read another article on how to set it up in a Data Warehouse: Member properties)  

However, you can also achieve a similar positive effect for objects in the TARGIT client, even if your dimension does not have any Data Warehouse designed member properties (e.g. when working with Tabular models).

Note: Presenting data in the TARGIT client is actually the combined result of at least two behind-the-scenes actions - requesting the data and delivering the data. Only the latter part, delivering the data, can be optimized by this setting.

When you design the content of your object (crosstabs or other objects types), you will see the 'Behave as member property' option:

When fetching data, the standard subtotals will be disabled, but more importantly, performance will be a lot better - especially for large crosstabs with many dimensions on the same axis.

Grand Totals and Subtotals

Some connection types may also offer to include/exclude Totals and Subtotals in the data delivery. Where these options are offered, excluding the Totals and Subtotals may further improve the data delivery performance.

Connection types where inclusion/exclusion of Totals and Subtotals is possible:

• Analysis Services Multidimensional
• Analysis Services Azure
• Analysis Services Tabular (DAX)

Requirements

• Dimensions to behave as member properties must be on the same axis as the "primary" dimension.
• Dimensions to behave as member properties must have a 1:1 relation to the "primary" dimension.
• Only attributes (single-level hierarchies) are allowed for 'Behave as member property'.

If a dimension does not fulfill the requirements, you may get an error like this:

Typical pitfalls

Beware of typical pitfalls when you think two dimensions should have a 1:1 relationship.

Examples:

• A salesperson may have changed Department during the employee period. Thus two or more departments may be associated with the salesperson.
• If a social security number is used as the primary dimension, some people may have changed name. Thus multiple names may be associated with the social security number.
• If your source system allows for multiple phone numbers or multiple email addresses per customer contact, you cannot be certain about a 1:1 relationship.

Technical note

"Behave as member property" should only be regarded as a substitute to real, data warehouse based member properties. Data warehouse based member properties are still superior to the client based "behave as member property".

"Behave as member property" is primarily meant as a fix to the lack of real member properties on DAX connections.