Да уж, разговор пошел не туда...

Рискну описать, как на данный момент делается у меня. А делается тупо (и думаю, ничего нового не скажу) - в таблице фактов хранятся обороты за день, в кубе прописаны MDX формулы для расчета остатков на конец каждого периода, начиная с уровня [День] по этим оборотам, далее для средних за период остатков в количестве и сумме. Такой подход уже не очень устраивает, приходится делать ряд допущений и упрощений в формулах, так как начинает страдать сорость расчетов.

С другой стороны экперименты расчетов того же на основе snapshot' а остатков на даты, когда были их изменения, пока не привели к положительным результатам. А хранить остатки в таблице фактов на каждый день для меня, кажется, нереальным. Посчитаем на основе данных, имеющихся в моем распоряжении:

полный справочник товаров - 63722 артикула, складов (т. е. неких сущностей, по которым фирме интересно знать движение товара и его остатки) - 30, дней, за которые имеются данные - 1186 (с 01.01.2001 г.). В предположении, что не на каждом складе есть полная номенклатура товаров, подсчитал DISTINCT ArtcleID, WarehouseID, получилось 139 327 комбинаций. За весь период времени (1186 дней) надо создать таблицу и залить в нее 139 327 * 1186 = 165 241 822 записей, и каждый день добавлять по 139 327 штук. А номенклатура растет, как и кол-во складов.

Пока успокоился на том, что для кубов разного назначения настроил разную гранулярность измерений времени и товара. В итоге товародвижение можно смотреть с детализацией до недели (хотя, в принципе никого из пользователей не убъет, если она уменьшится и до месяца), ну а другие отчеты - до дня, но медленнее.