Всем хорошего вечера.

В одном кубе вводятся пользователями и хранятся данные по мальчикам, девочкам и их домашним животным, как-то так:

Соответствия Мальчик + Девочка и Мальчик + Собака + Девочка + Кошка уникальное на весь куб; строки могут повторяться, но обозначенные комбинации всегда в одном и том же сочетании. Т.е. Петя будет только с Машей, при этом у них всегда будут Бобик и Муська. Бобик может быть и у Васи, но при этом он будет с Настей и Муркой.

В другой куб заливаются соответствия Мальчик + Девочка, уникальность аналогична первому кубу.
Нужно, чтобы при загрузке к каждой паре Мальчик + Девочка прицепились свои Собаки и Кошки, после чего в куб легла строчка Мальчик + Собака + Девочка + Кошка, в разрезе аналогичном первому кубу. Данных, кроме как из первого куба, вытащить неоткуда.

Как с наименьшими потерями это сделать, какой ФМ запустить? И есть ли хау-тушка на тему?
Или загрузить данные из первого куба во второй, с показателями 0, а потом как-нибудь сжать запросы в один, чтобы в кубе не болтались лишние нули? А с этим куда смотреть?

Вариант
1) Если данных в 1 кубе не так много, то прям в трансформации у 2-ого читаем ФМ-ом данные из 1-ого во внутреннюю таблицу в подпрограмме завершения, а дальше read по ключам.
2) Если данных много, но не жалко места и ещё одной сущности, да и вообще производительности - то сначала куб 1 сливаем в одску(только необходимые признаки), а дальше SELECT SINGLE в цикле в подпрограмме завершения (не очень красиво, нагрузка на базу, но прокатит)
3) Написать эксперт-рутину
4) Другие варианты)

4) Я бы посмотрел, нет ли связи между М, Д, С и К по атрибутам, и каким образом обеспечивается уникальность комбинаций в кубе1. Имхо, описанные правила вполне соответствуют схеме, когда у инфо-объекта Мальчик есть атрибуты Девочка и Собака, а у Девочки атрибут Кошка. Если об этом условие задачи умалчивает, то можно сделать своих Мальчик2 и Девочка2 с такими атрибутами и обновлять в них данные из куба1. Далее, в самом сложном случае со своими Мальчик2 и Девочка2, придется добавить эти два поля в источник данных для куба2 и заполнять в start routine правил переноса, а соответствующие атрибуты подтягивать уже в правилах обновления (трансформации) в куб2. Если же можно будет обойтись имеющимися Мальчик и Девочка, то дорабатываем только правила обновления (трансформацию). Также в тумане остался вопрос, как обеспечивается соответствие пар М-Д в двух кубах, может там вообще Мальчик с тремя остальными атрибутами?

Dimarik
1) Данных много. А ФМ-то какой и к каким таблицам куба обращаться (предположим, куб называется ZFAMILY)?
2) Жалко.
3) ненене, я не абапер.

Online
Уникальность совершенно точно только по М + Д и по всей четвёрке. Не выйдет с атрибутами, уже пытались.

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

Несколько раз перечитал Ваш вопрос...
Можете ответить на вопрос - зачем нужна такая операция с получением "ограниченного" куба?
Зачем дублирование данных...
опять же пользователи внесли в 1й куб данные - Вам надо перегрузить...


Просто то что Вы написали по задаче - очень сильно смахивает на info-set

С другой стороны... Если Вам надо вывести в отчете конретные пары М + Д, естественно Вы не можете ограничить значения в отчете парами. Получаете пересечение... т.е. при ограничении Ваня + Даша у вас так же появляется

Вася Бобик Настя Мурка << лишная строка
Ваня Тузик Даша Маркиза

В общем можно пойти другим путем... создайте в кубе объединенный признак - заполняйте его и ограничивайте в отчете. Получите ограничение по конретным парам... и не надо ничего ни куда перегружать

ToliK
Есть понятие "коммерческая тайна", по причине которого не всегда возможно объяснить ситуацию полностью; а анонимности в интернете нет. О прецедентах "нечего на форумах вопросы задавать, вы выдаёте информацию о заказчике" я слышала, к сожалению, не лично в мой адрес, к счастью.
Вариантов "почему" полно, не все мои, так что вырайте любой, одного хватит: в разные кубы могут заливаться в разрезе разных временных признаков и показателей, изменять уже существующие признаки и даже инфопровайдеры может быть категорически запрещено административно или полномочиями, два новых компаунда нужно как-то вести и это лишние цепочки, при очень большом объёме данных не стоит отдавать на откуп ABAP-у, FOX-у или BEx-у (сиречь VBA) сложные вычисления "на лету" и т.п.

Мона замутить дополнительный ОДС перед первым кубом с мальчиками и девочками,
причем таким образом, чтобы он содержал точно все данные куба (набрать достаточно
ключей и остальное аккуратненько сложить в поля данных).
ОДС лучше делать без генерации сидов, чтобы загрузка через него не сильно
отражалась на производительности вцелом.

Соответсвенно имеем джля первого куба:
[незнамо-какой-источник-данных]-ОДС-1-ый куб с мальчиками и девочками

При загрузке во второй кубик делаем семантические группы в ДТП, соответствующих
мальчиков и девочек селектим по ключам из вновь созданной ОДС-ки и размазываем по
полям как надо. Один селектик = хорошая производительность.

Думаю, должно прокатить, если в первом кубике не сильно много мальчико-девочковых
полей-атрибутов.

Алексей.