Сначала задача:
телефонный трафик: бывает входящий и исходящий, каждое направление характеризуется параметрами: (1) количество соединений и (2) разговоров, длительность и (3) тех и (4) других, (5) количество каналов в пучке. На основании этих параметров (по 5 на каждое направление - всего 10) строится еще куча дополнительных: от простеньких - типа процента эффективности, до не самых тривиальных - типа нахождение часа наибольшей нагрузки на суммарном (исходящий + входящий) трафике.
Решение:
начиналось все с 7-го SQLServera и ввиду множества вычисляемых параметров, таблица фактов состояла из 10 колонок для основных параметров, по 5 на каждое направление. Все производные параметры рассчитывались формулами в самом кубике.
Собственно вопрос:
SQLServer 2000 позволяет создавать вычисляемые члены измерения. В связи с этим все параметры и основные и производные можно было бы выделить в отдельное измерение, а в таблице фактов осталось бы одно поле - для значения конкретного параметра.
Вопрос в том стоит ли овчинка выделки?
Новая архитектура выглядит логичней, но однако и сложней, в том числе и при создании формул для вычисляемых параметров в измерении, и в конечном использовании, а юзеры у меня умом не блещут...
Кроме логичности и красоты, я так предполагаю, должны быть более весомые аргументы для переделки хранилища...
Какие? И достаточно ли весомые для изменения структуры хранилища???

to backfire:
Сейчас с SQLServer 7 и старой структурой хранилища, основные 10 параметров хранятся в таблице фактов каждый в своей колонке, а все дополнительные параметры оформлены как calculated member в Measures.
В SQLServer 2000, можно в самом измерении заводить вычисляемые члены, то есть в дименшине можно завести member, который будет вычисляться по заданной формуле.
Отсюда вариант действий: завести новое измерение, в которое включить все предыдщие 10 параметров и плюс все необходимые вычисления, которые сейчас у нас calculated members в Measures. Тогда соответственно, в таблице фактов просто появится кей на это измерение параметров и только одна, вместо 10, колонка со значением этого параметра.

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

to олапист:
вот именно в этом и вопрос, стоит ли?
с одной стороны, так логичней и гибче, хотя может это сказывается oltp стереотипы...
опять же, трансвер данных из олтп системы облегчится.
с другой стороны, для олап - старая архитектура, если я правильно понимаю, кажется производительней
короче, я в некоторой растерянности по этому вопросу, потому и спрашиваю

а ссылку погляжу, сенкс