Best Implementation practice for high number of dimension members

Hi, yes, absolutely. You can e.g. click on the cost center parent in a cube view and this point-of-view information can be used to filter the data from stage in a grid view. In this case, the filter would filter the stage table (of the same time, entity, etc.) by the base member cost centers of the selected parent, displaying all relevant loaded projects.

As long as there is a 'relation' between the data in the cube and the data in a (relational) table such as stage, the data can be filtered accordingly and analyzed accordingly. Hence the name 'relational blend'. Especially for stage data, this is a very common and easy use case, as data is being mapped from source to target, and one can leverage this mapping easily to blend the data together.

If it's the first time you'll be doing this, you might be struggling to picture it, here's an example that works a little bit like linked cube views where you click one cell on the cube view and, in this case, the lower part of the dashboard (that queries data in staging or other relational tables) refreshes based on the selected POV:

In this case I'm selecting Total Cost Centres (drop down above), UK, and Other Benefits and based on that POV running a query against:

1. The PLP register table (employee roaster) that shows me all the related inputs (i.e.: for UK and any cost centre) initially done
2. A separate query against the PLP Calc data that shows me the detail on how the Other Benefits were calculated by Employee.

In this example I went a step further and added a dynamically calculated translated amount column (based on the FX rates loaded to OS) so you can not only show the detail but also analyse it in group currency and have it tying back to your aggregated cube data (assuming we exclude any adjustments made directly in the cube).

I hope this helps illustrating the power and flexibility that you can get with relational blending.