Подскажите, пожалуйста.

Была поставлена следующая задача:
Оценить сколько дней не было возможности продавать товар из-за того, что товара не было на складе. Для групп товаров агрегировать эту оценку по сумме.

Есть виртуальный куб на MSAS2000, объединяющий остатки с продажами, в котором в числе прочих имееются измерения времени (до дня) и товаров (~10000). Задачу решает calculated member, т.к. я не нашел простого способа включить эту оценку в меры куба (со всеми плюсами серверного агрегирования), чтобы при этом структура куба не трансформировалась настолько, что для интерпретации данных куба требуется специально обученный толкователь.

В итоге, calculated member как-то работает. Для расчета, случился ли Out Of Stock (OOS) по товару в этот день используются меры начального остатка (BR) и транзакций (Tr) за день. OOS1=1, если BR<=0 и Tr>0 (продавали, но могли продать больше), OOS2=1, если BR<=0 и Tr=0 (не могли продавать). Понятно, что при такой организации вычислений на верхних уровнях времени/товара похвастаться большой скоростью работы этого MDX нельзя. Пытался повысить скорость по крайней мере правильным агрегированием Tr и BR, а именно как-то принудить систему создавать агрегаты по уровню "товары" измерения товаров (это не самый нижний уровень - ниже партия производителя ~50000 и я предполагаю, что использование агрегатов по уровню продуктов ~10000 несколько повысит скорость выполнения MDX), но нашел только возможность блокировать некоторые уровни при создании агрегатов, что мне не подходит (1. это не гарантирует создание агрегата по требуемому уровню, 2.не хочу блокировать другие запросы). Может принудить его к созданию нужных агрегатов сегмента через DSO AddGoalQuery (clsPartitionAnalyzer)?

Что можно сделать, чтобы по крайней мере, понизить уровень проблемы? Нельзя ли, все же, как-то обойтись агрегированием и не прибегать к глубокому перепроектированию куба? Я слышал, что MDX выполняет компьютер клиента, если это так, то я так понимаю, в моей реализации OOS ОЛАП выступает по отношению к клиенту практически в роли файл-сервера. Нельзя ли с этим что-либо сделать? Естественно, требуется решение задачи в рамках MSAS2000.

Заранее спасибо всем, кто отзовется.

Остатки хранятся в виде неагрегированного куба остатков (Remainder), в котором хранятся остатки на начало месяцев. Нижние уровни времени в этом кубе заблокированы. Логистические транзакции хранятся в другом (агрегированном) кубе (Transaction) c детализацией по времени до дня. Остатки/движения на любую точку времени получаются в виртуальном кубе (Rest), построенном над этими двумя. При этом для получения остатка на элемент иерархии времени (в общем случае отличный от месяца) используется остаток из Remainder родителя-месяца текущего элемента времени плюс сумма (Transaction) на всех уровнях (между месяцем и тек. уровнем) "старших братьев" текущего элемента (предполагается что тек. элемент - ниже месяца). Мои иерархии времени: Год, Квартал, Месяц, День (YQMD) и Год, Неделя, День (YWD). Для получения остатка на элемент в YWD, элемент отображается (LinkMember) в соответствующий день иерархии YQMD из которой и извлекается значение.

backfireЭта величина аггрегирется суммирование, идти по иерархии времени вверх. Аггрегировать ее по иерархии товара смысла нет. Веди если товара А небыло в продаже 5 дней в выбраннй период, а товара Б - 10 дней в период. То о мы разумного умозаключения сделать не сможем.
Действительно, сначала она агрегировалась только по времени, а на уровне групп товаров оценка строилась на основании остатка и продажи группы - так потребовали логисты. Надо сказать, я тоже не видел физического смысла такой оценки для групп товаров, однако утверждалось, что он есть. Такая "облегченная" схема в моей реализации работала вполне эффективно. Однако, в реальном применении для групп оценка оказалась малоприменима, т.к. по моим наблюдениям над логистами она не выполняла 2 - х главных задач: 1. Привлекать внимание к группе товаров, имеющих OOS (в общем случае она их может пропускать) и 2. Давать более-менее здравую оценку степени OOS товаров группы (она дает какую-то валовую оценку OOS группы). В общем случае можно сказать, что оценка на уровне группы в такой постановке никак напрямую не кореллировала с OOS товаров группы.
В новой постановке все же требуется агрегирование по товарным группам. Конечно, "потенциально упущенную продажу" мы для группы не получим, но например средний % OOS для товара группы получить удастся - что в общем удовлетворяет двум выше сформулированным критериям "триггерируемости" и "адекватности" (условно, назовем так :)).

Константин ЛисянскийВалентин, а как может остаток быть меньше нуля? Знак перепутали?

За какой период надо считать потерянные продажи?

У Вас розница или опт?

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

По поводу периода. Вероятно, Вы хотите узнать верхний уровень времени, на котором еще кого-то интересует эта оценка - мне верхний уровень не ограничивали, однако, All Members из области определения я исключил... чтобы определять по нему используемую иерархию времени, т.к. пересечения YQMD и YWD уж точно лишены всякого смысла. Можно сказать, что оценка определена на области, когда одна (и только одна :)) из иерархий установлена на All Members.

Задачи считать потерянные продажи мне поставлено не было. В данном случае интерес скорее направлен на эффективность работы склада, обеспечивающего продажи.

Далее, есть и опт и розница, дистрибьюция.