Feeding a ConsolidatedMax rule

[java_to_tm1]

Consider a measure where N-cells are being rule-calculated. Also assume that @ C-level I have one of the following functions: ConsolidatedMax, ConsolidatedMin, ConsolidatedAvg, ConsolidatedCount.
To get the ConsolidatedAvg or ConsolidatedCount functions to calculate correctly, ALL the N-level cells must be fed.

But to get ConsolidatedMin and ConsolidatedMax to show the correct value @C level, I'm betting that I don't actually need to feed EVERY N-level element. If there's something that tells me which of the N-level elements will have the max (or min) value, I should be able to get away with feeding just that element.

Cube: RealEstateCost has 6 dims (one of which is the region dim listed below) + 1 measure dim.
Example: A Region dimension with the following hierarchy

Code: Select all

-Midwest - Division 3 - ENC
--Illinois
----Chicago
----Springfield
--Ohio
----Cinci
----Dayton
----Columbus

Measure:

Code: Select all

['RealEstatePricePerSqFoot'] = C: ConsolidatedMax (2, ', !dim1, !dim2, !dim3, ... , !msr );

Now if Chicago has the highest Price-per-Sq-foot in Illinois and Dayton has the Highest price-per-sq-foot in Ohio, I dont really need to feed any of the other cities in the region Dim. Feeding Chicago will ensure that Illinois is fed and calculates properly. Feeding Dayton ensures that Ohio gets fed and Calculatd properly. Similarly feeding the equivalent cities in the other 3 states will ensure that the EastNorth Central Division of Midwest Division gets fed and properly.

Essentially the value shown on ConsolidatedMax with ALL elements fed = Value calculated on a ConsolidatedMax calc with only a single element (with the highest value) fed.

Your thoughts guys? Does this make sense? or have completely lost it?

How does this help me?
My users will have access only to the Consolidated Elements (States and above) in this reporting cube anyway, so I don't need to worry about the unfed cities not being visible on SupressZeroes.

[declanr]

Interesting idea but would raise the question of; If you know which of the elements is going to be calculated as part of the consolidated calculation then why use ConsolidatedMax at all? You could just say one is equal the other (or if there are no other measures just weight only that element.)

It doesn't feel like a very "robust" or future proofed method of calculating and feeding.

[java_to_tm1]

Interesting idea but would raise the question of; If you know which of the elements is going to be calculated as part of the consolidated calculation then why use ConsolidatedMax at all? You could just say one is equal the other (or if there are no other measures just weight only that element.)

It doesn't feel like a very "robust" or future proofed method of calculating and feeding.

Agree fully with the suggestion to use a simpler rule to reference the max-values element instead of using ConsolidatedMax. The original idea was to not edit the rule itself, but see if the feeders could be optimized by selectively feeding only the right cells.

[Michel Zijlema]

Consider a measure where N-cells are being rule-calculated. Also assume that @ C-level I have one of the following functions: ConsolidatedMax, ConsolidatedMin, ConsolidatedAvg, ConsolidatedCount.
To get the ConsolidatedAvg or ConsolidatedCount functions to calculate correctly, ALL the N-level cells must be fed.

But to get ConsolidatedMin and ConsolidatedMax to show the correct value @C level, I'm betting that I don't actually need to feed EVERY N-level element. If there's something that tells me which of the N-level elements will have the max (or min) value, I should be able to get away with feeding just that element.

I don't really agree on the last part. Feeding is required to make sure that all relevant cells are evaluated on the consolidated level. It doesn't make a difference whether the consolidated level is a standard hierarchical aggregation, or is calculated with a rule.
I see what you're getting at, but as Declan already mentioned, the consolidated max and min function would not be required if you knew upfront what the max or min value element would be. To be able to determine the min or max you would need to evaluate all relevant cells... Also note that you're looking at a multidimensional space - the max from one perspective would not necessarily be the max from another perspective.
So I wouldn't break my head on this one and look for other means/options to optimize your model.

Michel