Как правильно связать наборы данных в СКД и передать значение в параметр

При разработке сложных отчетов на системе компоновки данных (СКД) часто возникает необходимость использовать несколько наборов данных. Типичная ситуация: основной запрос получает список объектов (например, Информационные Системы), а второй запрос должен получить детальные сведения по каждому объекту из другого регистра. В этой статье мы подробно разберем, как реализовать такую связь, правильно настроить передачу параметров и избежать распространенных ошибок вроде "Поле не найдено".

Механизм работы связи наборов данных

Для начала проанализируем, как СКД обрабатывает связи между наборами данных типа «Запрос». Важно понимать, что система работает по принципу вложенного цикла. Рассмотрим этот процесс по шагам:

1. Выполняется первый (ведущий) набор данных. Система получает итоговую выборку строк.
2. Для каждой строки из результата первого набора СКД инициирует выполнение второго (ведомого) набора данных.
3. Если в настройках связи указан Параметр, то значение из поля первой выборки подставляется в этот параметр перед выполнением второго запроса.
4. Результаты объединяются в одну структуру данных.

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

Настройка ведомого запроса (НаборДанных2)

Допустим, у нас есть первый набор, который выбирает поле ИС. Во втором наборе нам нужно отфильтровать данные именно по этой информационной системе. Рассмотрим пример кода для второго набора данных, где мы используем параметр в виртуальной таблице:

ВЫБРАТЬ
    тТипыРесурсов.ТипРесурса КАК ТипРесурса,
    ЕСТЬNULL(ОбъемыРесурсовИСОстатки.ФактОбъемОстаток, 0) КАК ФактОбъем,
    &ИС КАК ИС_Связь
ИЗ
    тТипыРесурсов КАК тТипыРесурсов
ЛЕВОЕ СОЕДИНЕНИЕ РегистрНакопления.ОбъемыРесурсовИС.Остатки(
    &Период,
    ИС = &ИС
) КАК ОбъемыРесурсовИСОстатки
ПО тТипыРесурсов.ТипРесурса = ОбъемыРесурсовИСОстатки.ТипРесурса

Обратим внимание на важный нюанс: чтобы связь работала стабильно и СКД «видела» поле для сопоставления, рекомендуется добавить сам параметр в список выбора запроса, как показано в строке &ИС КАК ИС_Связь. Это помогает избежать некоторых внутренних ошибок платформы при сопоставлении метаданных.

Настройка вкладки «Связи наборов данных»

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

1. Источник связи: выбираем «НаборДанных1».
2. Приемник связи: выбираем «НаборДанных2».
3. Выражение источник: указываем поле из первого набора, которое содержит значение (например, ИС).
4. Выражение приемник: указываем поле из второго набора. Если вы добавили параметр в выборку, как мы делали выше, укажите ИС_Связь.
5. Параметр: это критически важное поле. Здесь нужно выбрать имя параметра из второго запроса — ИС.

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

Разбор ошибки «Поле не найдено»

Проанализируем ситуацию, когда система выдает ошибку «Поле не найдено» при попытке формирования отчета. Это происходит по нескольким причинам:

• Отсутствие поля в «Пути к данным»: Проверьте на вкладке «Наборы данных», что для нужных полей установлены флажки и заполнены пути к данным. Если поле используется в запросе, но исключено из компоновки, связь по нему не сработает.
• Несоответствие типов: Если в первом запросе ИС имеет составной тип, а во втором параметр &ИС жестко ограничен одним типом справочника, СКД может не найти соответствия. Выясним причину через функцию ВЫРАЗИТЬ. Попробуйте привести поле к конкретному типу в обоих наборах данных: ВЫРАЗИТЬ(Поле КАК Справочник.ИнформационныеСистемы).
• Автозаполнение: Если в конструкторе запроса включено «Автозаполнение», СКД может автоматически переименовывать поля. Проверьте итоговый список полей на закладке «Набор данных».

Оптимизация: Проблема N+1

Рассмотрим ситуацию с точки зрения производительности. Как мы уже выяснили, связь наборов данных — это цикл. Если первый набор вернет 1000 строк, второй запрос выполнится 1000 раз. Это классическая проблема N+1.

Посмотрим, когда стоит использовать связи, а когда — нет:

• Используйте связи, если: вы объединяете данные из разных баз (через внешние наборы данных — объекты) или когда использование одного запроса невозможно из-за ограничений виртуальных таблиц (например, нужно получить остатки на разные даты для каждой строки).
• Используйте один запрос, если: все данные находятся в одной информационной базе. В 90% случаев ЛЕВОЕ СОЕДИНЕНИЕ внутри одного запроса будет работать быстрее, чем связь наборов данных в СКД.

Практические советы по отладке

Если данные все равно не выводятся, проанализируем следующие моменты:

1. Проверьте параметры в настройках отчета. Если параметр &ИС имеет флаг «Ограничение доступности», убедитесь, что он заполняется через механизм связей. Для отладки временно снимите этот флаг, чтобы увидеть параметр в пользовательских настройках и проверить работу второго запроса вручную.
2. Убедитесь, что в первом наборе данных поле, по которому идет связь, не является пустым (NULL). Если в источнике NULL, ведомый запрос может вообще не выполниться или выполниться с пустым параметром, что приведет к неожиданным результатам.
3. Используйте Консоль системы компоновки данных. Это лучший инструмент для анализа того, какие именно запросы и с какими параметрами уходят в СУБД.

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