Добрый день!
Есть контракт, он может иметь несколько залогов.

Сделали соединение (Compound) Залога c Контрактом.
Контракты и залоги загружаются в куб с разных ODS.
В отчете в разрезе контракта предстает следующая картина:

Хотелось бы, чтобы отчет имел вид:

Куда копать, в сторону инфо-набора?

Определись в каком DSO у тебя находятся необходимые показатели. Он будет базовым.

Из него по-хорошему надо сделать загрузку в другой DSO , в который ты подтягиваешь все необходимые аттрибуты (возможен ABAP) и затем только загружай в куб.

С инфо-набором дельты не будет, если только неявную сам сделаешь.

То есть вы предлагаете, чтобы в DSO была следующая картина:


и только после этого грузить в куб? Не очень хорошая затея по-моему.


Что значит дельта для инфо-набора?! Инфо-набор - это JOIN двух инфо-объектов (ODS или инфо-объектов). Так что дельта будет определяться на уровне самого ODS.

Эта проблема общая. Решают её несколькими вариантами.

1. Подтянуть все необходимые аттрибуты в консолидированный DSO и затем грузить.
2. Подтягивать аттрибуты при загрузке из DSO в куб.
3. Использовать инфо-наборы.

2 метод плох тем что аттрибуты могут измениться и в кубе появяться левые данные.
А 3 не поддерживает дельту. Загрузка из инфо-набора всегда Full.

Compound не правильно работает (не так как этого все ожидают)

через атрибуты надо сделать, тогда будет выведен весь перечень залогов по отфильтрованному контракту

Загрузку из инфо-набора вы имеете ввиду путь через APD ?, когда данные кидаются в транзакционный ODS из которого идет всегда FULL UPDATE. Через APD я не хотел извращаться
А вот напрямую создать инфо-источник из инфо-набора в SAP BW 3.5 я не знаю. (При нажатии правой кнопки мыши для меня доступно только "Изменить", "Удалить", "Обзор объектов")
То есть это стандартный подход?:



Как вы себе это представляете?, - поделитесь соображениями! Один контракт может иметь несколько залогов, причем один и тот же залог может покрывать несколько контрактов. Есть необходимость выводить все контракты.

А вот интересно тогда, какой из контрактов вы суете в Compound залога, если залог покрывает несколько контрактов?
Зачем тогда Compound, вставляйте просто оба признака в инфо-провайдер.

Вообще то я имел ввиду BI 7.0

Ленч дело говорит. Такой компаунд не нужен. Если необходима комбинация признаков, то лучше создать DSO с ключами контракт и залог.

Допустим залог покрывает два контракта, для залога ключевыми полями будут ID_Залога и ID_Контракта.

Атрибутами кстати тоже можно сделать, если добавить код контракта просто в код залога. получится полный аналог Compound только с возможностью привязки атрибута Контракт

Спасибо за советы. Очень Вам благодарен.
Вот какие существуют преимущества и недостатки конкатенации:
+ При активации и использовании БК. Потому что нет необходимости изменять структуру ключей, только необх. изменения длины ключей.
+ Не оказывает влияния на существующие связаные объекты (Инфо-кубы, ОДС или др. инфо-объекты).
+ может быть легко описана в ретроспективе - после загрузки основных данных или транзакционных данных.
+ потенциально от нее можно отказаться после осуществления глобальной интеграции данных. (например, при исп. MDM).
+ построение отчетов облегчается , поскольку нет зависимости от разных ключей, как в случае Соединения (Compounding) инфо-объектов.
Недостатки:
- необходимо создавать доп. инфо-объекты,которые хранят ключевые значения отдельных полей, которые образуют составной ключ.
- Конкатенация может оказать влияние на весь процесс репортинга и производительность загрузки данных увеличивая размер таблиц основных данных.

В общем, если залог - справочник в исходной системе, а контракт это просто его группировка, то лучше использовать DSO для хранения данных комбинаций значений признаков.

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

ИМХО собирай данные до загруки в куб предварительно в DSO. Из двух DSO в куб есть смысл грузить, если они формируют при загрузке одинаковые аналитики.

Косяк с фильтрацией Compound пришел к нам с семеркой
На 3.5 помнится работало