Подскажите кто знает, или может натолкните, пожалуйста, на подходящую литературу.

Есть ОЛАП куб. В нём - 4-5 calculated member'ов.
В последнем, который отображает именно то, что требуется, нужно сделать так, что когда по одному(конкретному) из измерений значение isleaf, чтобы отображалось то, что считает формула, а при любой аггрегации на более высокий уровень значение считалось не по общей формуле для calculated member'а, а раскрывалось до списка isleaf'ов и брало их среднее значение.

Перепробовала массу вариантов, среди них: соответствующее написание самого calculated member'а, написание  calculated cell'а, изменение измерения в Custom rollup formula.
В результате я ни разу не увидела того, чтоо мне надо, и вот по какой причине - ВРЕМЯ.
В правильности написания всех трёх вариантов я уверена на 99%, когда я убираю это последнее условие куб работает почти молниеносно, но как только ставлю одну из этих надстроек - всё... пиши пропало...
Что делать?
Куда копать?

MS SQl Server 2000, MS Analysis Server, БД на десятки миллионов записей.

Calculated field и проиндексировать его?

Calculated field - что это? Я такое даже в хелпе не нашла...
Может имеется ввиду Calculated cell?
А как его проиндексировать?

Нет, я имел ввиду, что любой анализ данных работает быстрее на индексированных полях. Если у вас какое-то значение вычисляемое на основании значений таблицы (например в таблице есть цена и количество, а вы включаете в обработку  значение цена*количество), то для этого вычисляемого значения может иметь смысл сделать вычисляемое поле в таблице и по нему создать индекс (благо MS SQL Server поддерживает индексирование вычисляемых полей). И в анализе использовать не вычисляемое значение, а вычисляемое поле... Это не всегда работает, но если по логике такая технология подходит то имеет смысл попробовать.

Да нет, если бы я могла результат вычисления посчитать в MS SQL было бы гораздо проще
А у меня рассчитывается дистрибьюция, это - результат вычислений 4-х calculated member' ов...  А в каждом из них - и кроссджойны, и лукапы в другие кубы и т.д. и т.п....  

Ну тогда сложно... думай в сторону упрощения самого анализа... Например для анализа создавать специальные таблицы в которых данные во-первых максимально денормализировать, во-вторых отобрать только используемые в анализе поля, в третьих сделать все промежуточные вычисления по максимуму, и в червёртых добавить индексов на "всё что движется"...

Если есть ссылки на какие-то другие вычисляемые объекты, то можно сначала сделать их записать результаты во временные таблицы...

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

Ну во-первых для анализа вовсе не нужны все поля, как правило не нужны "тяжёлые" мемо, блобы, и диннные строки с адресами, кроме того обычно не нужны данные по всем строкам, нужны данные за определённые временные интервалы, только активные клиенты и т.п... Так что даже на самых навороченных базах данных временные таблицы для репортов как правило не превосходят по размерам 5-10% от реальных таблиц, как правило база данных должна иметь соответствующие резервы для роста... 


А логика в общем-то такова - какие бы кубы и репорты вы не строили, в конечном итоге они сводятся к вполне банальным Select.... А теперь представим себе обычный запрос:



В данном случае участвует выборка по 6 полям! А значит будут использоваться только какие-то индексы так как вряд ли будет в таблице существовать составной индекс на все эти поля... А значит число вариантов для плана выполнения такого запроса будет значительным... Если запрос усложнить раза в 3, то количество вариантов его выполнения окажется за пределами возможностей перебора SQL Server'a - т.е. анализ скорости работы каждого варианта выполнения запроса при использовании каждого доступного индекса окажется столь долгим, что SQL Server просто не будет над этим думать, возьмёт средне-потолочный наиболее красивый индекс, отберёт данные а потом будет тупо сканировать все остальные объекты на оставшиеся условия... Если же предварительно отобрать данные и занести в отдельные временные таблицы можно существенно сократить время, так как это позволит гораздо более толково выполнять запросы.  У меня таким способом удавалось сократить время выполнения некоторых запросов на 1-2 порядка.

Насколько я знаю задача у человека и стоит постоянно проводить расчеты над полным перечнем данных! И расчетные ячейки могут ссылаться на данные из всего обьема. 

ВСЁ...
Победила   
Расскажу как - вдруг кому понадобится
В SQL Server'е делать какие-либо аггрегации оказалось невозможным, "в лоб" тормозило невероятно, поэтому я сделала ещё один дополнительный куб и часть условий и вычислений "нацепила" на него, распределив таким образом нагрузку на 2 куба.
+ нашла у себя один минус.
В одном измерении у меня было связано 5 таблиц, одна пара была связана полем типа варчар. Это смерть...
ВСЁ
Теперь только Интеджер!

Mephisto,  спасибо за PointUID