Поднимаю на обсуждение достопочтенного All следующую проблему по MDX и дизайну кубиков/измерений в MS AS.

Проблема.
В произвольном кубе имеется некотрое множество виртуальных измерений построенных на одном из физических измерений данного куба.
С точки зрения клиентского приложения, обращающегося к кубу через МДХ эти измерения являютя тем не менее независимыми.

Например. (Пример банально прост, но именно поэтому я его и привожу чтобы всем было понятно о чем идет речь)

Куб - "Продажи"
Физические Измерения
"Клиент", "Товар", "Время"
На атрибутах измерения "Клиет" построены виртуальные измерения
"Регион", "Пол", "Образование", "Среднегодовой доход".
На атрибутах измерения "Товар" построены виртуальные измерения
"Группа товара", "Группа скидок", "Производитель",

Меры "Сумма продаж", "Количество", "Скидка", "Скидка %", "Прибыль", "Прибыль %"

Задача
Вывести отчет "Скидка %" и "Прибыль %" по клиентам, при произвольном сочетании фильтров. для выбранных временных интервалов.

Вариат MDX


Запрос работает, но выдает абсолютно всех клиентов (и не Урюпинцев, и женщин и ПТУшников) :-)

Если мы используем NON EMPTY, то в выборку клиентов не попадают те, кто ничего не покупал в ферврале или январе.

Если вместо WHERE использовать FITER по аттрибутам измерения клиент время выполнения запроса растет на порядок, составлять такой МДХ на порядок гемморойнее, ибо пользователь выбирает членов измерений, а не значения атрибутов.

Пока мы живем с MS AS 2000 (а это нам грозит еще как минимум года полтора-два) - надо искать обходной маневр, но как?

У меня созрела идея.
А что если создать кубик "Relation_Клиент", таблицей фактов которого будет таже таблица, что и таблица измерения "Клиент". В этом кубике участвуют измерение "Клиент" и все что ней висит (виртуальные измерения ."Регион", "Пол", "Образование", "Среднегодовой доход"). В кубике одна единственная мера. Сount(Клиент.Id) "Relation". Сводим кубик "Relation_Клиент" и "Продажи" в один виртуальный "Продажи+" и

модифицируем запрос.



И получаем желаемый результат.

То Mosha

Идея толковая, но в этом случае мы получаем парочку не очень желательных побочных эффектов:

1. В результате запроса будет не "Клиенты", tupel(Kлиент, Регион, Пол, Образование), а нам требуются только Клиенты. Хотя от этого можно уйти с помощью с функций MDX

Set2 AS 'Extract(Set1, [Клиент])'

2. Генератор запросов, а уменя именно генератор запросов, должен "просканировать" все не пустые (не All) slicers и перекинуть те, которые относятся к зависимым измерениям измерения клиент из Where в Set1. Надо будет попробовать. Нет ли там каких то подводных камней.

В догонку

Извините не заметил, что вы уже поставили "1" для "Crossjoin Set Count", так что Extract абсолютно не нужен.

To Mosha.


Кстати.

SET [Set1] AS
'
NonEmptyCrossJoin([Клиент].[Все клиенты].members,
([Регион].[Все регионы].[Урюпинск],
[Пол].[Все].[М],
[Образование].[Все].[Высшее],
[Measures].[Relation_Клиент]), 1)
'

совсем не обязательно, так как
SET [Set1] AS
'
NonEmptyCrossJoin([Клиент].[Все клиенты].members,
[Measures].[Relation_Клиент], 1)
'

Дает тот же результат если в Where отстается

([Регион].[Все регионы].[Урюпинск],
[Пол].[Все].[М],
[Образование].[Все].[Высшее])

к тому же в Where могут и другие измерения, которые не участвуют в кубике
"Relation_Клиент" (такие как "Группа товара", "Группа скидок"), а по сему мы должны вместо [Measures].[Relation_Клиент] использовать ValidMeasure([Measures].[Relation_Клиент]).
Странно только. Согласно документации NonEmptyCrossJoin работает только с физическими мерами, а не с виртуальными. Или я чего то не правильно понял.

To Mosha

Spasibo za predlozhenie, na bolshih imereniyah (okolo 1*10^6 listovih elementov) NonEmptyCrossJoin daet 2-h kratnoe uvelichenie skorosti vipolnieniya zaprosov i prakticheski 2-h kratnoe umenschenie potreblyaemoi klientom (Pivot Table Services) pamyati.