Описание задачи выглядит как классическое many-to-many relationship между аттрибутами, и главная тонкость здесь не столько в том чтобы промоделировать это в OLAP кубе без дупликации членов измерений, а в том чтобы это аггрегировалось как DISTINCT SUM. Делать many-to-many и DISTINCT SUM может Analysis Services 2005. Подробнее об этом например здесь:
http://sqljunkies.com/WebLog/sqlbi/archive/2004/10/04/4447.aspx

Моша
----------------------------------------------------
This posting is provided "AS IS" with no warranties, and confers no rights

Константин ЛисянскийВ таком случае, можно спроектировать под любое средство OLAP.

Dmitry Biryukovв MS AS 2k можно создать три parent-child измерения, у каждого свой Source Table Filter.

Мне кажется что Вы все таки упускаете из виду вопрос правильного аггрегирования. В предложенном Вами решениях Балтика будет фигурировать в 3-х разных измерениях и соответсвенно не будет аггрегироваться как DISTINCT SUM.

Моша
----------------------------------------------------
This posting is provided "AS IS" with no warranties, and confers no rights

Константин ЛисянскийВ таблице товаров будет три внешних ключа, ссылающихся на три разных таблицы (или иерархии таблиц).
Если бы было 3 разных аттрибута, то конечно проблем нет. Но Guest_321 в своем примере указал, что аттрибут только один. Я правда упустил что в таблице есть еще поле Klassificator_Type, которое в известной мере упрощает задачу. Когда я говорил что есть проблема DISTINCT SUM и double counting, то я имел в виду что если просто наивно создать иерархию с членами "Дешевое", "Российское", "Светлое" - то тогда будет double-counting на уровне All, т.к. пиво может быть и дешевым и светлым и российским. Интересно как Microstrategy решает такую задачу. Впрочем я за Microstrategy не волнуюсь - это ROLAP tool, и у нее не должно быть проблем генерить правильный SQL, даже если выбран multi-select "Дешевое" или "Светлое". А вот как с этим справляется Cognos - действительно интересно.
Константин ЛисянскийДа, и неужели AS не умеет работать с разветвляющимися измерениями?
Откровенно говоря, AS2K действительно не очень хорошо справляется с такими моделями. Можно конечно сделать, но надо будет сильно постараться. А вот AS2005 - без проблем.

Моша
----------------------------------------------------
This posting is provided "AS IS" with no warranties, and confers no rights

Вообще то я пытался разделить две разные проблемы, но они почему то все время путаются :) Когда внутри измерения у атрибутов отношение many to many, как например недели к месяцам, то это более простая задача. Все равно они 1-to-many к ключу измерения (дни), который фигурирует в fact table. А вот когда атрибут одного измерения имеет many-to-many relationship к атрибуту другого измерения, и не связан напрямую с fact table, вот тогда дело сложнее. Например в fact table есть ключ по продукту (пиво) и measure "Продажи", но характеристики продукта (светлое, дешевое и т.д.) в fact table не хранятся, потому что им там не место - им место в другой таблице, где продаж нету, а есть только характеристики продукта.
С первой проблемой Константин Лисянский описал как справляются OLAP продукты - строят "разветвляюшуюся иерархию". А вот про вторую проблему, которая решается в AS2005 при помощи many-to-many dimensions, никто почему то не говорит, хотя она на мой взгляд гораздо более интересная.
backfire - когда Вы говорили что решали это на AS2K, Вы имели в виду первую или вторую проблему ?

Моша
----------------------------------------------------
This posting is provided "AS IS" with no warranties, and confers no rights