Есть куб остатков на складе из которого получаем остаток товара в натуральном и в денежном исчислении продажи на конец каждого месяца.
Есть куб движений из которого получаем информацию о закупках/продажах.
Стоит задача оценить товарный запас на складе в средних фактических продажных ценах.

Первое что приходит в голову, так это то, что следующая вычисляемая мера (CM)



[Товар].[Товар] - это листовой уровень.

[Measures].[Остаток количество] - уже является CM для определения остатка
на конец месяца (квартала, года), как
(ClosingPeriod([Календарь].[Mecяц],[Календарь].[Mecяц]), [Measures].[Остаток количество физич.]) и работает на более высоких уровнях чем месяц со свистом.

Но "остаток в ценах продажи" это таккииее тооормозаааа (на листовом уровне порядка полумиллиона элементов) и всякая предаггрегация на этапе процессинга - коту под хвост .

Но что то ничего более путевого не приходет в голову. Мысли крутятся даже вокруг того чтобы в DWН чего нибудь насчитать, чтоб в AS не делать sum(descendants(...))

Может кого какая светлая идея посетит?

user007мысль 1, как вы сказали, на высоких уровнях запрос считается быстро,
сделать еще один уровень для того чтобы в листьях небыло 0,5мил элементов.

мысль 2, сделать еще один куб в котором будет храниться остаток в ценах продажи по товарам и месяцам.


По поводу 1. Я как раз этого не говорил. Я сказал это о мере [Measures].[Остаток количество]. Она считается со свистом. А вот мера [Остаток в ценах продажи] считается ужастно долго. И чем выше в иерархии измерения товар, тем хуже.

MoshaУ меня такая мысль:

1. Перейти на Юкон


Хорошая мысль. Как только так сразу. За мной дело не станет.
Вам же остается пожелать
Arbeiten, Arbeiten, Arbeiten!!!

Mosha
2. Определить в MDX Script:

SCOPE(Measures.[Остаток в ценах продажи]);
SCOPE(Leaves(Товар));
this = [Measures].[Продажи Сумма]*[Measures].[Остаток количество] /[Measures].[Продажи Количество]));
END SCOPE;
END SCOPE;

(Обратите внимание что я поменял порядок множителей).

1. В чем собственно фишка перемены мест множителей? Не уж то операция умножения не коммутативна?
2. В чем эта калькуляция круче CM в AS2K. Она ведь тоже рассчитывается по запросу, а не при процессинге куба.

Mosha
При этом наверное придется сделать Остаток в ценах продажи физической мерой, чтобы она агрегировалась правильно.

Мне кажется это будет оптимальным решением, но, конечно, надо проверить.


То есть надо считать в DWH это поле таблицы фактов для куба остатков?
И это альтенатива к вашей калькуляции, а не дополнение, если я вас правильно понял?

Ну вы прям как герой Мкртычяна из "Мимино" - "я так думаю".

конечно Вы меня заинтриговали предложением проверить это в Юконе, но я пока что сумлеваюсь в этом очень.
Не могли бы вы приоткрыть тайну ваших мыслей, ведь согласно всех законов физики не может калькуляция быть такой же быстрой как и физическая мера.