cubes best practices

hello,

Are there any best practices in terms of entites in a cube ?

I have the cube below which has only several entries and I'm not able to display it with a dataview on a screen but I'm able to display it in a flex grid. What is strange is that I'm able to display it when i run a procedure with breakpoints. The difference with the screen is that I have the CFI - valeur dimension on my screen on which I have securities.

Display with breakpoints:

thank you,

Catalina

Find more posts tagged with

Accepted answers

Kevin Kowalski

Hi Catalina,

Thanks for sharing the cube structure and the context — this helps clarify the behavior you’re observing.

You’ll find below a key reference on Board best practices regarding sparsity, which is directly relevant to your case:
Best Practices
Cube definition insights
Sparsity

That said, beyond sparsity alone, I need to highlight that the cube structure you shared is well below the modeling standards expected for a Board application.

In particular:

The cube includes a very large and dense dimension (AT – Identifiant unique with ~1,000,000 members).
Using such a dimension on a dense axis is strongly discouraged and goes against Board best practices.
This kind of design typically leads to unexpected behaviors in DataViews (while Flex Grid or breakpoint execution may still display data), performance issues, and limitations in screen usability.

In standard Board applications, large technical identifiers should either:

Be avoided in cubes altogether, or
Be handled through alternative modeling approaches (relationships, filters, or technical cubes), keeping reporting cubes lean and business-oriented.

I would therefore strongly recommend revisiting the cube design and simplifying its dimensionality to align with Board modeling standards. This should resolve the display inconsistencies and significantly improve robustness and performance.

Best regards,
Kevin

All comments

Robert Barkaway

Hi Catalina, you have an entity with 1m max item number as a dense dimension, I would certainly suggest looking at making that sparse. A million is very high for a max item number, typically it wouldn't be recommended to go that high apart from in exceptional cases, and even then it would need to be very carefully handled.

Kevin Kowalski

Hi Catalina,

Thanks for sharing the cube structure and the context — this helps clarify the behavior you’re observing.

You’ll find below a key reference on Board best practices regarding sparsity, which is directly relevant to your case:
Best Practices
Cube definition insights
Sparsity

That said, beyond sparsity alone, I need to highlight that the cube structure you shared is well below the modeling standards expected for a Board application.

In particular:

The cube includes a very large and dense dimension (AT – Identifiant unique with ~1,000,000 members).
Using such a dimension on a dense axis is strongly discouraged and goes against Board best practices.
This kind of design typically leads to unexpected behaviors in DataViews (while Flex Grid or breakpoint execution may still display data), performance issues, and limitations in screen usability.

In standard Board applications, large technical identifiers should either:

Be avoided in cubes altogether, or
Be handled through alternative modeling approaches (relationships, filters, or technical cubes), keeping reporting cubes lean and business-oriented.

Best regards,
Kevin

Catalina

Hello Kevin,

Thank you very much for your reply! It's very clear.

I based AT - Identifiant unique setup on Année (Year) thinking that normally a Year type dimension should be a sparse dimension. I should have looked further to find the meaning of the colours displayed in front of each dimension :).

Have a nice day!