Разворачивание массива связей
Иногда стандартный механизм таблицы связи не может реализовать сценарии, которые доступны при последовательном соединении таблиц.
Например, в такой модели нет никаких проблем, чтобы проанализировать данные одной таблицы в разрезе другой.
Однако, если построить эту модель через генератор таблиц связи, то мы уже не сможем посчитать, например, кол-во PhotoID в разрезе StageID.
Это произойдет потому что таблица связи разносит значение полей связи по строкам, относящимся к определенной таблице.
И если в конкретной таблице нет идентификаторов другой таблицы, то связь между ними работать не будет. Механизм восстановления связей (vSSM_Restore_Links) также не будет работать в этом случае, потому что он восстанавливает связи по цепочке ссылок на первичные ключи. А ObjectID — это вторичный ключ.
Решение — приджойнить к таблице Stages поле PhotoID по совпадению ObjectID, и использовать его как обычное ключевое поле. Но не все так просто. Каждому ObjectID соответствует несколько PhotoID.
Это значит, что при простом джойне кол-во записей в Stages увеличится пропорционально кол-ву фото для каждого объекта. Это приведет к искажению данных, что недопустимо.
Для решения таких ситуаций реализован функционал разворачивания связей. Вы можете создать в таблице поле, которое будет содержать в себе массив идентификаторов, разделенных «|».
Данные из этого поля будут развернуты в таблице связи в индивидуальные идентификаторы, если задать их имя следующим образом:
- Слева от вертикальной черты: итоговое имя поля в модели;
- Справа от вертикальной черты: наименование поля связи, в роли которого должны разворачиваться значения.
В результате, при формировании таблицы связей значения из этого поля будут развернуты функцией subfield().
При этом в модели поле останется с заданным в левой части именем.
В таблице можно использовать несколько таких полей. Эта методика очень удобна тем, что позволяет хранить в таблице всю необходимую информацию о связях. Кроме того, это позволяет управлять связями по сложным сценариям. Т.к. массив связей может быть получен через вычисления со сложной логикой, которую нельзя повторить через связи таблиц.
❗ При формировании массива связей контролируйте отсутствие пропущенных значений в массиве, или окончание массива вертикальной чертой. Например, 123456||789 или 123|456|789|. Такие записи создадут вам пустые значения идентификаторов (не Null()), по которым будут строиться связи, и, возможно, портить вам картину.
❗ Использование этого метода (особенно для нескольких полей в одной таблице) может очень сильно увеличить кол-во записей в таблице связей. Используйте с осторожностью, и анализируйте возможность изменить структуру данных так, чтобы не использовать данный прием.
Многовариантные связи
Предположим, у нас есть данные о перемещениях сделок по воронке продаж. Мы собираемся анализировать их в разрезе сотрудников. А сотрудники представлены двумя разными полями: ID сотрудника, который переместил сделку и ID сотрудника, который отвечает за сделку сейчас.
Нам нужны оба сценария.
Конечно, мы можем продублировать справочник сотрудников для каждого поля и сказать пользователям, чтобы они делали выборки в полях Ответственный_за_перемещение_сделки или Текущий_ответственный_за_сделку_в_перемещениях_сделки. Но это может быть несколько контринтуитивно.
Для этих случаев имеется следующая функциональность: расширение связей позволяет объединить несколько полей таблицы в одно поле связи, если его указать во второй половине для нескольких полей. Также, расширяемые связи аналогичным образом взаимодействуют с обычными полями связи, размеченными через «|L».
Это приводит к тому, что для записей связи таблицы в указанное ключевое поле попадают значения обоих полей (массивы при этом разворачиваются). Также, создается дополнительное поле КлючевоеПоле.Type, которое содержит наименование поля, из которого взяты значения.
Используя этот параметр в анализе множеств, можно контролировать, по какому сценарию выполняется агрегирование по данной связи. Можно использовать эту методику для любого кол-ва полей в одной таблице, а также для одинаковых полей в разных таблицах.
Управляющие поля с типом .Type попадают в мониторинг конструктора выражений на предмет выбора конкретного сценария связи.
❗ По возможности, планируйте использование этого метода заранее, потому что добавление новых сценариев связи приведет к необходимости актуализировать формулы, которые на содержат этого параметра.