2 Дмитрий:

спокойно делай измерение поставщики, а чтобы суммы не фильтровались добавь СМ (Поставщики.Все,Сумма)

А как в таком случае связать таблицу справочника поставщиков и таблицу фактов? Я считаю что измерением Поставщиков сделать в этой задаче нельзя (так как нельзя будет для каждой записи таблицы фактов по упомянутому там коду товара понять, кто является поставщиком этого товара).

2 Сиквел:

Я вижу только один путь в решении этой задачи (если хотите решать ее средствами OLAP, а не средствами SQL-запросов):
Создаете свойство для каждого товара - его поставщики, через запятую например, как текстовая строка. Потом в OLAP-клиенте делаете выборку, в свойства каких товаров входит название или код того или иного поставщика. Не все OLAP-клиенты могут этот сделать, но некоторые - умеют :)

2 Dmitry Biryukov:

Видимо в таблице фактов есть ещё и поле поставщик если Сиквел не хочет чтобы суммы фильтровались.

Я думаю Вы неправильно поняли задачу, сформулированную г-ном Сиквелом. В таблице фактов нет поля с кодом поставщика. Если бы он там был - то не было бы никаких проблем и никаких задач.

Мне кажется что Вы специально подгоняете дизайн куба так, чтобы описанную выше задачу мог решить только один клиент. не будем говорить какой :-)

Не скатывайтесь на оффтопик. Ничего я не подгоняю. Я лишь привел единственное решение для этой задачи, сведя ее к следующему виду:
Документ, Товар, Сумма, ПоставщикТовара
1, Товар5, 100, Иванов Петров Сидоров
2, Товар1, 70, Петров Сергеев
3, Товар4, 120, Иванов

По полю ПоставщикТовара (когда оно стало в OLAP-кубе свойством товара) фильтр не наложить, но можно с помощью поиска найти нужные подстроки. Например, поиск по подстроке "Петров" вернет первые 2 записи. И я не думаю, что такие возможности по поиску подмножеств есть только в одном OLAP-клиенте :)

2 backfire:

Документ, Товар, Сумма, ПоставщикТовара
1, Товар5, 100, Иванов Петров Сидоров
Супер дизайн, ничего не скажешь. Нарушаем даже первую нормальную форму. Юра Вы серьезно такие решения внедряете? Я не завидую тому, кто придет после Вас разгребать это

Почитайте эту дискуссию с самого начала, не вырывайте мой постинг из контекста. Если я чем-то грешу, то только тем, что иногда недостаточно подробно разжевываю свои мысли, надеясь, что уровень читателей этого форума достаточно высок...
Подобная неказистая структура - это не то, что я призываю хранить в реляционном хранилище данных. Это данные (в виде вьюшки или временной таблицы), подготовленные для закачки в OLAP-куб.
На входе у автора дискуссии как я понимаю есть 2 следующие таблицы:
Таблица фактов:
Документ, Товар, Сумма
1, Товар5, 100
2, Товар1, 70

И таблица связи между товаром и поставщиком:
Товар, Поставщик
Товар5, Иванов
Товар5, Петров
Товар5, Сидоров
Товар1, Петров
Товар1, Сергеев

Если мы свяжем эти таблицы по полю Товар, то получится дублирование строк таблицы фактов, и отчеты будут правильны если их строить не по всем, а только по одному конкретному поставщику.
Я предлагаю не плодить записи в таблице фактов, а присвоить товару его поставщиков, сконкатенированных в одну строку.

P.S. А для любителей нормализации могу добавить, что конечно же по-правильному надо товары вынести в отдельный справочник, а названия товаров в вышеупомянутых таблицах надо заменить на их айдишники. И то же самое надо проделать для поставщиков.

2 backfire:

Советую посмотреть топик
Хитрая иерархия (классификатор)Хитрая иерархия (классификатор)
Там поднималась на обсуждение сходная тематика.

Почитал, пожалуй надо будет принять участие в этой дискуссии. Она начиналась с несложного вопроса (поскольку в таблице фактов ЕСТЬ ссылка по коду на справочник товаров).

В этой дискуссии в таблице фактов НЕТ ссылки по коду на справочник поставщиков, и такие ситуации в жизни встречаются редко. Однако, решение на основе MS AS 2005, приведенное в дискуссии про хитрую иерархию, похоже неплохо подходит для решения задачи из этой дискуссии.