Просто так множественный фильтр и distinctcount меры в AS2K не сведешь - тут изголятся надо. А в вашей формуле с SUM будет просто сумма, а не то что вам надо.

Ну и чем Вам AGGREGATE не угодил? На обычных мерах с аггорегацией SUM или COUNT он ни чем не отличается от функции SUM.
А если тип аггрегации DISTINCTCOUNT, то ваше выражение с SUM дает не верный результат, а AGGREGATE вообще выдает ошибку.

Что Вы считаете "сделать по-нормальному"? Как бы Вы делали?

Действительно в MEASURES Rowset поле MEASURE_AGGREGATOR определяет тип меры. Но мне с трудом представляется использование этой информации для желаемых вами функции, ибо как только мы имеем дело с CM, то имеем MDMEASURE_AGGR_CALCULATED и что дальше?

TorinВообщем, уже 3-й день мне это не удается. Измерение товаров приходиться держать в строках, а не в фильтре, поэтому кол-во торговых представителей*кол-во групп товаров полностью "ложат" мою станцию и сервер на долгие часы, ни разу не дождался результата.

Во-первых, не "ложат", а "кладут". :-)

Во-вторых, а сколько же их кол-во торговых представителей*кол-во групп товаров полностью?

Torin
На всякий случай,
CM


Для такого CM употребление Execution Location = 3 только усугубит ситуацию.

crossjoin(..., excludeempty) надо заменить на шустрого но иногда брыкающегося NECJ(...).

TorinЗабыл возразить. IMHO тип агрегации "SUM" для distinctcount меры на одном и том же измерение ведет как раз к правильному результату.
Потому что distinctcount мера не пересекается между элементами иерархии одного уровня

Боюсь, что тут я вас понял не правильно или совсем не понял. Что значит
distinctcount мера не пересекается между элементами иерархии одного уровня ? Это ваше утверждение для общего случая или для вашего конкретного? Поясните подробнее, пожалуйста.

Torinто на более высоком уровне той же иерархии результат можно считать как сумму значений этой меры на нижних уровнях. Например, если 3 номенклатуры кефира имеют distinctcount {1,1,0}, то следующий уровень иерархии "Бренд кефира" будет равен 1+1+0, а следующий уровень "Категория" будет Бренд1 +Бренд2
Все это действительно только для агрегации по тому же измерению, последние уровни которого считает distinct. Вообщем, как раз мой случай.

Позвольте с вами категорически не согласится. В общем случае DC мера счиается для каждого уровня иерархии как DC, и никогда как SUM от результата DC для предыдущего уровня.

Torin backfire Torinто на более высоком уровне той же иерархии результат можно считать как сумму значений этой меры на нижних уровнях. Например, если 3 номенклатуры кефира имеют distinctcount {1,1,0}, то следующий уровень иерархии "Бренд кефира" будет равен 1+1+0, а следующий уровень "Категория" будет Бренд1 +Бренд2
Все это действительно только для агрегации по тому же измерению, последние уровни которого считает distinct. Вообщем, как раз мой случай.

Позвольте с вами категорически не согласится. В общем случае DC мера счиается для каждого уровня иерархии как DC, и никогда как SUM от результата DC для предыдущего уровня.
"В вообщем" - да, но для того же измерения, на котором и DC лежит - нет, можно суммировать. Почему бы и нет ? Но это частности, согласен.

Смысл происходящего в том, что имея под рукой "крутонавороченную технологию" и железо _абсолютно_ невозможно проводить DC анализ даже приблизительно также просто как и анализ обычных мер. Даже сложнее не получается и надо переделывать кубы под конкретные отчеты. Даже переделывая кубы мы все равно ничего не получаем.
Кто сможет вывести на оси строк 5K торговых представителей и 44K клиентов, на оси колонок DC по купленному товару (всего до 15K товаров), при условии, что на товар наложен фильтр, урезающий его до 700 товаров, а всего исходных строк в фактах до 700K.
При этом NON EMPTY CROSSJOIN (торговые представители, клиенты) должен дать не больше 3K строк - проверено через TSQL.
И при этом отчет построиться меньше, чем за 2-3 часа (TSQL делает за 1.5 минуты) ?

Простите за вопрос, но кто будет читать эти 5K*44K? Или это выборка данных для дальнейшей обработки?

А что за фильтр вы накладываете на товар? Bы строите CM на множестве товаров, а затем ставите этот CM в WHERE?

Я бы с удовольствием помог Вам, если бы вы сформулировали задачу полностью. В лучшем случае еще схему куба приложили, если не секрет. Можно даже на e-mail.

А по какому признаку вы стаыите фильтр на товар? Он у вас как множественный фильтр потом используется? Если это базируе

Dmitry Biryukov backfireЕсли это базируе г-н "backfire", у вас мысль оборвалась буквально на полуслове.... вернитесь в форум! мы волнуемся!


Тормозим-с. :-)

А по какому признаку вы ставите фильтр на товар? Он у вас как множественный фильтр потом используется? Если это базируеруется на каком то аттрибуте товара, то я бы подумал о виртуальном измерении.

Dmitry Biryukov
В этой ситуации существенно должно помочь объединение этих измерений в одно с несколькими уровнями и объявление dependent dimensions

Можно, но не всегда нужго, особенной если этот use case один из многих и у customer еще десяток аттрибутов. Я уже писал по этому поводу.

но своё имхо я уже сказал - надо не формулу оптимизировать, а дизайн.

Построение жестких иерархий дело вкуса, тут вы правы.
Но в AS2К я не сторонник жестких иерархий. У меня только 2 иерархических измерения YQMD и YWD.
Все остальные - плоские измерения (за исключением невидимых доп уровней для решения проблемы 64к). У меня измерение Customer имеет около 10 виртуальных измерения. Тоже относится к Product. Аналитик при построении отчета сам выбирает иерархию, выбирая аоследовательность виртуальных измерений при Drill-Down.

Естественно с AS2K никакой стандартный клиент не обеспечит вам функционала и скорости жестких иерархий ибо все они, строя МДХ, используют CROSSJOIN (NON EMPTY CROSSJOIN). Но никакой стандартный клиент не использует NECJ

Вы можете сказать, что мое решение узкое и неуниверсальное, но в Юконе сделано чертовки похожн, все крутится вокруг UDM. Иерархии аттрибутов, которые приходят на смену виртуальным измерениям, делают out of box то, что в AS2K я делаю с помощью дополнительных кубов и NECJ.
Ту концепцию, что я решаю через custom sly MDX, Моша презентует всем в Юконе.

Offtop

To Torin

В АСЮ выйди, если хочешь.

Virtual dimensions do not affect cube processing time because they are calculated in memory when needed. However, queries that use virtual dimensions can be slower than queries that use regular or parent-child dimensions.

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