SSM-5. Обогащение связей

Разворачивание массива связей

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

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

Однако, если построить эту модель через генератор таблиц связи, то мы уже не сможем посчитать, например, кол-во PhotoID в разрезе StageID.

Это произойдет потому что таблица связи разносит значение полей связи по строкам, относящимся к определенной таблице.

И если в конкретной таблице нет идентификаторов другой таблицы, то связь между ними работать не будет. Механизм восстановления связей (vSSM_Restore_Links) также не будет работать в этом случае, потому что он восстанавливает связи по цепочке ссылок на первичные ключи. А ObjectID — это вторичный ключ.

Решение — приджойнить к таблице Stages поле PhotoID по совпадению ObjectID, и использовать его как обычное ключевое поле. Но не все так просто. Каждому ObjectID соответствует несколько PhotoID.

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

Для решения таких ситуаций реализован функционал разворачивания связей. Вы можете создать в таблице поле, которое будет содержать в себе массив идентификаторов, разделенных «|».

Данные из этого поля будут развернуты в таблице связи в индивидуальные идентификаторы, если задать их имя следующим образом:

  1. Слева от вертикальной черты: итоговое имя поля в модели;
  2. Справа от вертикальной черты: наименование поля связи, в роли которого должны разворачиваться значения.

В результате, при формировании таблицы связей значения из этого поля будут развернуты функцией subfield().

При этом в модели поле останется с заданным в левой части именем.

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

❗ При формировании массива связей контролируйте отсутствие пропущенных значений в массиве, или окончание массива вертикальной чертой. Например, 123456||789 или 123|456|789|. Такие записи создадут вам пустые значения идентификаторов (не Null()), по которым будут строиться связи, и, возможно, портить вам картину.

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

Многовариантные связи

Предположим, у нас есть данные о перемещениях сделок по воронке продаж. Мы собираемся анализировать их в разрезе сотрудников. А сотрудники представлены двумя разными полями: ID сотрудника, который переместил сделку и ID сотрудника, который отвечает за сделку сейчас.

Нам нужны оба сценария.

Конечно, мы можем продублировать справочник сотрудников для каждого поля и сказать пользователям, чтобы они делали выборки в полях Ответственный_за_перемещение_сделки или Текущий_ответственный_за_сделку_в_перемещениях_сделки. Но это может быть несколько контринтуитивно.

Для этих случаев имеется следующая функциональность: расширение связей позволяет объединить несколько полей таблицы в одно поле связи, если его указать во второй половине для нескольких полей. Также, расширяемые связи аналогичным образом взаимодействуют с обычными полями связи, размеченными через «|L».

Это приводит к тому, что для записей связи таблицы в указанное ключевое поле попадают значения обоих полей (массивы при этом разворачиваются). Также, создается дополнительное поле КлючевоеПоле.Type, которое содержит наименование поля, из которого взяты значения.

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

Управляющие поля с типом .Type попадают в мониторинг конструктора выражений на предмет выбора конкретного сценария связи.

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

Добавить комментарий

Ваш адрес email не будет опубликован.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.