Добрый день!
Существует куб и ODS, которые содержат признаки - физически разные объекты с разными названиями, но отражающие одну сущность.
Например, ZDEPT1 в ODS и ZDEPT2 в кубе.

По ODS и кубу необходимо построить отчет, связав эти два признака. Своего рода JOIN между ODS и кубом.

С ходу через мультипровайдер не получилось, не дает при создании меппинга связать признаки с различными именами.

Есть ли другие способы?

BW 3.5
Заранее спасибо.

Нужен не мультипровайдер (так как это по сути UNION), а инфо-набор.

в 3.5 кубы не могут входить в инфо-набор. Только ОДС и инфо-обьекты.
В очень ограниченных случаях можно получить JOIN, если извратиться через константу-выбор в запросе, но похоже здесь не тот случай.

Тогда можно попробовать добавить один признак в навигационные атрибуты другому... и связывать.

Действительно в 3.5 в инфо-набор нельзя добавить куб (не зря в исходном сообщении я указал BW 3.5)

Попробуем из ODS слепить виртуальный куб, и повязать в мультик базовый + виртуальный.

смысла последнего не понял...

Есть базовый куб и ODS.
Напрямую через мультипровайдер связать нельзя (см. исходный пост)

Из ODS делаем виртуальный куб (через FM преобразуем ZDEPT1 -> ZDEPT2), мультипровайдером накрываем базовый и вирутальный.

А не проще будет модель поменять и куб перезагрузить, чем ФМ городить ?

+1
признаки, отражающие одну сущность должны быть ссылочными, здесь явно косяк проектирования...

а весь этот огород с виртуальностью приведет к резкому падению производительности

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

Уважаемые почетные гуру!
Вроде 1 апреля уже давно прошло.

Вы всерьез считаете, что менять структуры данных (к слову повязанных на N-е кол-во объектов в продуктивной системе - этого правда не было в первоначальных условиях), вместо того, чтобы "городить" ФМ - это правильно?

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

Уважаемый IE2.

Вы всерьез считаете, что по одному посту в форуме можно дать абсолютно универсальный и правильный, в любой ситуации совет?

Люди объяснили, чем плохо конкретное решение, и какие могут быть впоследствии проблемы.

Иногда изменить структуру и перегрузить один кубик - не фатальная проблема

Не нравятся советы - не применяйте, всего и делов

а вы в серъез считаете, что на любой чих надо абапить, вместо того ,чтобы попытаться решить стандартом? Вместо того, чтобы слить данные физически в один кубик вы делаете z - разработку, которая потом будет хреново сопровождаема? Или вы смотрите на то, что я сейчас быстренько слабаю, а потом хоть трава не расти? а потом будет апгрейд и ваши последователи скажут вам большое спасибо за такое гениальное решение

не надо забывать, что виртуальный кубик с вероятностью 70% будет работать в мультике с constant selection КРИВО это проверено.