Очень неудобно, что это свойство доступно только в редакторе измерения и, соответственно, действует одинаково на все кубы...
Допустим, есть shared dimension Товар, используемое в 6 кубах. Причем в 3 из них оно используется с одним фильтром, а еще в 3 - с другим. Если создавать 2 общих измерения, то придется назвать их, скажем, Товар_1 и Товар_2. Что будет не очень-то красиво смотреться для конечного пользователя. Возможности задать алиас для имени измерения в кубе я не нашел. Этот вопрос кстати тоже интересен. Делать 6 частных измерений тем более не хочется. (А вдруг еще больше групп кубов/кубов в группах будет?)
Идеальным было бы 1 общее измерение + возможность индивидуально задавать для него Source Table Filter в каждом кубе, где оно используется...
Как можно обойти such a problem, может есть какое красивое решение?

MS AS, Excel 2002.

Согласен, если такие измерения будут иметь разные имена, это может и будет хорошо с точки зрения проектирования, но с точки зрения пользователя это будет лишним. Ведь измерение Товар уникально в каждом конкретном кубе, и никакие фильтр 1 или 2 не нужны, и так понятно что оно относится к кубу, с которым работает юзер. Поэтому и встал вопрос о возможности задавать для конечного просмотра алиас дименшену в соответствующих кубах на сервере (лучше всего) или хотя бы на клиенте. Или найти work around для использования одного общего измерения.

To Mosha:
Как я уже говорил в первом посте, делать 6 (а может и больше) частных измерений, одинаковых с точки зрения реализации, мне кажется нерациональным. Плюс теряется возможность оптимизации структуры куба по данным измерениям.
А все-таки, с чем связано отсутствие возможности задавать свой Source Table Filter для shared dimension в каждом кубе? Или это логически неправильно?

Va1entinВидимо, никто этого раньше не придумал. И если бы что-то похожее существовало, фильтровать надо не исходную таблицу (Source Table), а члены самого измерения, уже построенного на Source Table.
Да, наверно, это должен был бы быть аналог Data slice для partition, только для измерения :) Вообще я пробовал делать такие фильтры для измерения, только через Manage roles кубов для нужной роли -> Restricted dimensions -> Select members. Но способ, конечно, муторный...

Mosha...Ну и кроме того неправильный - security здесь явно ни при чем, и будет давать разные результаты в зависимости от того является пользователь администратором или нет.
Полностью согласен, просто я попробовал такой подход ради эксперимента, т.к. пользователи у меня не имеют админских прав :)
MoshaДа, но все partitions всегда private - у AS2K нет "shared partitions" :)Я имею в виду то, что Va1entin сказал правильно, реализация подобной фичи должна была бы представлять собой фильтр на
Va1entinчлены самого измерения, уже построенного на Source Table.
А выбор нужных членов мог бы выглядеть аналогично выбору Data slice, ну или в том же Manage Roles. Извиняюсь за неясное объяснение, суть вобщем-то не в этом :)
backfireЭто связано с тем, что это методически не правильно.
Shared Dimension придуманы в первую очередь, не для того чтобы сэкономить труд разрабочика по созданию и поддержке N приватных измерений в N кубах, а для объединения нескольких кубов в виртуальные по общим измерениям. И этот принцип не зависит от применяемого инструмента.
Судя по BOL эти аспекты практически равнозначны:
Shared dimensions that share the same data source can be included in any cube or virtual cube in the database. By creating shared dimensions and using them in multiple cubes, you avoid the time-consuming alternative of creating duplicate private dimensions within each of the cubes.
Даже если измерения не учавствуют в виртуальных кубах, все равно хочется иметь standardization of business metrics among cubes , где они используются, а с большим количеством частных измерений это заметно труднее: в случае изменения измерения в одном кубе, приходится делать ручками аналогичные изменения и в других.

Проблема все в той же невозможности использовать индивидуальный фильтр членов shared измерений для разных кубов. Чтобы было более понятно, попробую привести свой пример.

Есть несколько кубов с фактическими данными.
Несколько кубов с плановыми данными.
Измерение Время (2000 - 2005 г.г.).

Кубы с фактом содержат данные по всему измерению Время, в то время как кубы с планом - только текущий год. Старый план остается в предыдущих кубах за прошлый год, т.к. аналитикам он уже не интересен. Помимо того, каждый год меняется как минимум содержание некоторых других используемых в плане измерений, а как максимум их структура. Так вот, измерение Время по идее должно быть общим и для плана, и для факта, т.к. имеет один и тот же логический смысл для всех кубов. Однако тогда при просмотре кубов плана будем видеть в измерении Время много лишнего. Аналогичная ситуация с измерением География, т.к. факт имеет бОльшую гранулярность, чем план, и при просмотре измерения География в кубах плана мы тоже будем видеть большое количество лишних членов. Все это затрудняет навигацию по измерению для конечного пользователя. В виртуальных кубах пока используется лишь небольшое подмножество данных, поэтому необходима прямая работа с кубами-источниками.

Поэтому пришлось сделать отдельные shared измерения для факта и плана, хотя концептуально это не есть верно :( Отсюда вопрос и про систему имен, много больно таких измерений может быть. Хотя копать надо, наверно, не с этой стороны

To Zohar
Да, именно это я и хочу сказать

To Евгений Краснов
Я, честно говоря, не совсем понял, как использование виртуальных измерений может помочь решить описанную мной проблему. Объясните, пожалуйста, подробнее.
Вы ведь сами пишете, что все равно нельзя задать фильтр на виртуальное измерение. К тому же, хоть мне ни разу не приходилось ими пользоваться, по-моему, виртуальные измерения нужны совсем для других целей.

Небольшое уточнение к примеру: в плане гранулярность по измерению География, как бы сказать, разнородная. Т.е. по одному региону детализация максимальная, по остальным - лишь на уровне региона, поэтому просто отключить нижний уровень нельзя.

backfireМне так кажется, что вы пытаетесь проблему представления данных их куба, что собственно есть задача клиента, протянуть на гораздо более низкий уровень - на уровнь модели . Согласитесь, что если бы Ваше клиентское ПО было в состоянии это делать, то Вам бы не пришло в голову что то менять в модели.
В том-то все и дело, что если существует привязка к OLAP клиенту (зачастую это Pivot Table в Excel), не умеющему делать это, то нелохо было бы иметь такую возможность на сервере. К тому же, мне кажется, эта задача как раз должна решаться на уровне модели, т.к. подмножество элементов общего измерения, используемое в кубе, является свойством именно куба, а не его представления пользователю.