В этом случае в качестве фактов лучше использовать не table, а view и создать в нем еще одну поле, как произведение двух вышеупомянутых. Затем в AS его можно использовать как основу для обычной меры с функцией SUM. В этом случае Вы облегчите жизнь не только своим клиентам но и серверу, хотя объем хранимой информации естественно возрастет.

Dmitry Biryukov
лучше использовать не table
в этом случае нет никакой разницы. а иногда вью создать просто невозможно.
1. разница есть - table может быть рабочая со всеми вытекающими последствиями
2. честно говоря, не припомню ни одного случая, когда нельзя создать view
3. из любой ситуации всегда можно найти выход, в частности создать другую table

Dmitry Biryukov
объем хранимой информации естественно возрастет
возрастёт по сравнению с чём?

Если использовать Calculated member, то хранится только его описание, которое вычисляется в момент запроса к AS, к тому же, вычисление происходит на стороне клиента (по-умолчанию, естественно все настраивается :)). А при использовании "штатной" меры - под нее отводится отдельное место на сервере, для каждого факта и агрегата, отсюда и увеличение в объемах.

Dmitry Biryukov
1. view ссылается на ту же таблицу и могут быть точно такие же последствия
2. например прав нет. или субд такая, что view там в принципе нет
3. выход есть всегда, но вот ещё одна таблица - это один из худших, т.к. такую таблицу надо регулярно обновлять и она действительно занимает место.

Так-то оно так, но всегда ищется разумный компромис между объёмом хранимой информации и скоростью исполнения запросов.
Место для современных серверов - не проблема, а время аналитика или топ-менеджера стоит дорого и его не вернуть.

Я, например, в storage design wizarde, предпочитаю отдать 10-20 гиг "лишнего" места, но чтобы все запросы выполнялись быстрее, чем человек успеет подумать.
1. проблем как раз меньше:
во-первых таблицы, как учили, обычно в нормализованом виде, а OLAPу лучше денормализовать все. во-вторых, опять же как учили, не давайте пользователям (OLAP тоже пользователь) глядеть в таблицы напрямую.
в-третьих перечислять преимущества представления в данном случае можно долго...
2. прав нет - значит кривой админ, или кривая политика, или в конечном счете этому пользователю и OLAP не нужен..
а view нет - так вроде мы про MS SQL беседу ведем - не отвлекайтесь от темы..
3. А вот я так не считаю - сами же написали:
Dmitry BiryukovМесто для современных серверов - не проблема
и еженочно у меня такая опреация происходит. Из рабочей базы с помощью DTS идет выгрузка на другой сервер, в другую базу, с денормализацией, с дополнителными расчетами типа того, который стоит в вопросе этой темы.
И плохого я в этом не вижу ничего. Потому что:
Dmitry Biryukov...время аналитика или топ-менеджера стоит дорого и его не вернуть.
И предлагаю на этом тему закрыть... спорить можно бесконечно и придумать можно всякие оправдания в пользу одного и другого подхода. Человек с другим вопросом обратился а мы в дебри полезли... :)
если интересно можно просто пообщаться by mail, by icq
ok?