Designing Jedox dimensions that scale
· Jedox
Cubes get the attention, but dimensions decide whether a model holds up. Get them right and everything downstream is easier.
Cubes get the spotlight, but dimensions are the backbone of every Jedox model. A dimension is reused across cubes, drives every report and subset, and is painful to restructure once data depends on it. So I spend real time here before building anything.
One concept per dimension
Each dimension should represent exactly one thing: a Products dimension, an Accounts dimension, a Time dimension, a Version dimension. The temptation is to mix, for example putting accounts and measures in the same list, or products and regions together. Resist it. Mixed dimensions balloon in size and make every report awkward to lay out.
Attributes are not dimensions
If a property only describes an element, and you would never plan or report against it as an axis of its own, it is an attribute, not a dimension. Product colour, an account's sign, a cost centre's manager: these belong as attributes on the element, where they power filtering and subsets without bloating the model. Spinning up a whole dimension for something that is really metadata is a classic early mistake.
Let consolidations do the maths
Roll-ups belong in the hierarchy. Build consolidated elements (a Quarter that sums its months, a Region that sums its countries) and the engine aggregates them for you. Do not load consolidated totals as base data, and do not write rules to sum children. Model the hierarchy and let it work.
Naming conventions you set once
Consistent element naming saves endless grief later. Decide how you write periods, codes and prefixes, then hold the line across every dimension. Integrator loads, subsets and rules all lean on those names, so a predictable scheme is the cheapest maintenance win there is.
Share dimensions across cubes
Where two cubes talk about the same thing, the same accounts or the same entities, use the same dimension. Shared dimensions keep definitions consistent, make cross-cube rules possible, and mean a change is made once rather than in three places.
Plan for growth
Dimensions change: new products, new cost centres, a new year. Design hierarchies and attributes so that adding an element is a routine load, not a rebuild. Avoid hard-coding positions, and keep your Integrator loads idempotent so rerunning one simply reflects the latest master data.
The short version
One concept per dimension, attributes for metadata, hierarchies for roll-ups, consistent names, shared where possible, and built to grow. None of it is glamorous, but it is the difference between a model you extend in an afternoon and one you are afraid to touch.