Dense dimensions typically have a high degree of data population, so dimensions such as; - period, year, scenario, version are ideal candidates for being dense dimensions.
Sparse dimensions are typically dimensions where there are a larger number of members, where a large number of combinations of sparse data may not have values populated.
So sparse dimensions act as indexes to take the end user to specific blocks of data, blocks of data being populated densley (most permutations have values).
Precise tuning of the balance is a case of looking at what are obvious candidates for being dense and sparse, and then thinking of the practical considerations of block size and thinking how this will change over time and finding best fit.
Hope this helps,
accont dense 500 load dense 30 dense 10 scnario sparce 5 year sparce 5 period sparce 12 customer sparce 20 entitty sparce 47 currecny sparce 25 entuity1 sparce 87 customer2 region sparce 167 customer anotehr type sparce 200 ares of business sparce 324 product sparce 500
here is my outline i tried with hour glass model but yet its very bad in performance any suggestion
My suggestion would be consider making your non-dynamic with a smaller number of members sparse dimensions dense; - so consider currency, scenario, period (there may be others - I don't know your business!); and do the maths on block size and total density, taking into account how this may change over the likely useful life of your application.
imagine you have a country dimension and a business unit dimension.
As all business units are NOT in all countries then this already argues for sparsity.
With accounts (expense types) these are typically used with a high degree of regularity across your entire organisation (dense).
Entities will only be used in limited subsets of the entire cube (typically it will be in one geographic location), so the argument typically here is for sparse.
But, these are generalist comments, you need to know how the segments are used in your business circumstances.