AlexPAVНарод!

Хочется обсудить одну проблему: Сотрудникам хочется , чтобы в отчетах OLAP присутствовал такой атрибут как номер накладной.

Решение 1 : Вынести все такие отчеты в блок оперативной отчетности (OLAP будет использоваться только для задач анализа без такой детализации). Для данного решения придется приложить усилия для доказывания данного факта начальству (А что в OLAPе это нельзя ??? А почему? А нельзя ли подумать? :-((( )

Решение 2 : Сделать shared измерение "Номер накладной" по таблице фактов (в принципе можно построить иерархию или по датам и номерам накладных (Год-Квартал-Месяц-День-Номер накладной) или по контрагентам (Контрагент-Номер накладной) или просто использовать группировку). Такой вариант в принципе может работать, но с ростом количества фактов может привести к созданию очень большого измерения сопоставимого с размером таблицы фактов (конечно, поменьше - ведь накладная имеет несколько строк). Что может ухудшить скорость отклика.

Вопрос: Кто как решает данную проблему? Может есть какие то другие пути решения?

P.S. Пока накладных не так много, но ожидается довольно приличный объем данных (несколько десятков тысяч накладных в день)


Я делал по варианту 2.
"Жить можно сносно" до размера измерения в пару лимонов. Затем начинается ..па. Про то, чтоб с Excel туда смотреть, можно забыть. Только custom MDX.

ПашкаЯ тоже сделал иерархию по таблице фактов. Склад-Дата-НомерНакладной.
Документов за год у меня примерно 200 тысяч, но эксель с таким измерением работает крайне неохотно, точнее охотно но медленно! Особенно если делать с этим измерением Crossjoun-ы.

А Вы гляньте, что за MDX генерит Excel, тогда станет все понятно.
А на больших измерениях, я только с NonEmptyCrossJoin работаю.

Mosha
1. В AS2K вынести номер накладной в DRILLTHROUGH колонку. Тогда она будет выдаваться как результат SQL query к fact table

Очень много задач, которые этим способом не решить, т.к. DRILLTHROUGH показывает всегда сырые данные из таблицы фактов, а вопросы ставятся к данным, аггрегированным до уровня счета.

Mosha
P.S. В отличие от backfire у меня нет нареканий к MDX который генерит Excel. Нарекания у меня к AS engine, который в версии AS2K не всегда может оптимально этот MDX обработать. В AS2005 query optimizer гораздо умнее...

Здоровая самокритика это всегда похвально :-).

Но Excel всего один из многих клиентов, работающих с MSAS. А MSAS один на сегодняшний день. А когда с оптимальным MDX добиваешься результа на порядок лучшего, чем Excel, то здоровая логика подсказывает, сто проблемы не у AS, а в Excel.

Так что проще заменить Excel, чем ждать жутко оптимизированного движка Юкона. :-) Тем более если он придет в срок, то будет с багами. Это же не мои слова :-)