Hi MTY,

"aggregate column which is more than key columns"

I think what you mean is a measure column which is duplicated across rows. The Kimball term for this situation is: the measure doesn't match the grain of the fact table. Generally, this means that that measure does not belong to this fact table and you would have to build another fact table for that measure, with the right grain.

"how exactly I will call my report and my aggregates"

A typical star join query used to retrieve measures from the fact table is

select d1.attribute1, d2.attribute1, sum(f.measure1)

from fact1 f

inner join dimension1 d1 on d1.d1_key = f1.d1_key

inner join dimension2 d2 on d2.d2_key = f1.d2_key

group by d1.attribute1, d2.attribute1

If your measure doesn't satisfy the grain of the fact table you will encounter double counting. Hence the recommendation is that you have to move that measure column to other fact table so that it can be summed up correctly.

If however, you insist of putting that measure in this fact table, then you would have to take a max, min or average (or other aggregate SQL function like rank).

"some aggregate columns are percentages or probability calculations"

With percentage measures generally we will have to persist (store) it as 2 columns in the fact table: the nominator (A) and the denominator (B). The report or cube will then do the calculation A/B to get the percentage. Same with probability.

Hope this helps,

Vincent