Доступно с лицензией Standard или Advanced.
В процессе создания реплики, строки и объекты добавляются в реплику на основании фильтров, определенных в приложении. Как только фильтры будут применены, для включения дополнительных связанных объектов будут обрабатываться классы отношений.
Обработка класса отношений включает в себя изучение каждого набора данных, который участвует по меньшей мере в одном классе отношений. По окончании изучения набора данных все строки, которые уже были реплицированы, группируются и используются для организации запроса к связанным строкам в связанных наборах данных. Любые связанные строки, которые будут возвращены после выполнения запросов, будут добавлены к реплике. Каждый набор данных будет изучен один раз в течение данного процесса.
Каждый класс отношений будет обработан только в одном направлении. По умолчанию это направление будет направленным вперед, но вы сможете изменить направление на обратное во время создания. Направление вперед означает, что класс-источник (origin class) будет изучен для добавления в него связанных строк из класса-адресата (destination class) в реплику. Обратное направление означает, что класс-адресат будет изучен для добавления связанных строк из класса-источника в реплику. Вы также можете отключить обработку определенного класса отношений в процессе создания реплики.
Поскольку каждый набор данных изучается всего один раз, а каждый класс отношений обрабатывается не более чем в одном направлении, то порядок, в котором наборы данных будут изучаться, очень важен. У системы имеется определенная логика обработки наборов данных в том порядке, в котором будет добавлено большинство связанных объектов. Вы можете повлиять на порядок, в котором наборы данных будут обрабатываться, путем изменения направления или отключения обработки определенных классов отношений.
В расположенных ниже примерах будет изображена модель поведения по отношению к связанным объектам. В этих примерах используется модель данных простого отношения источник-адресат (origin–destination) между объектами собственности, зданиями и связанными с ними аннотациями.
Пример №1
В данном примере показано, что область реплики включает в себя восемь земельных участков и шесть зданий. После создания реплики были добавлены два дополнительных здания, поскольку они связаны с земельными участками. Обработка класса отношений также добавит аннотацию для здания и земельных участков в реплику.
Пример №2
В данном примере показана репликация отношений при обработке с направлением вперед. Путем выбора двух зданий в родительской реплике для репликации и используя стандартную направленную вперед обработку для связанных записей, аннотация, которая связана с этими зданиями, также будет реплицирована в дочернюю реплику.
На изображенной ниже схеме изображен случай, где вы решили выбрать те же самые два здания, но решили использовать для класса отношений prop_build обработку в обратном направлении. Помимо связанной аннотации здания будут включены также сами земельные участки, которые связаны с этими зданиями, и аннотации этих земельных участков.
Пример №3
В предыдущих примерах реплика была создана с использованием стандартных моделей поведения процесса включения связанных объектов. Для настройки репликации вы можете заменить эту модель поведения либо на глобальном, либо на локальном уровне. На глобальном уровне процесс репликации может быть настроен так, чтобы никакие связанные объекты, которые имеют связь с объектами, выбранными для репликации, не были включены.
В данном примере здания и объекты собственности выбраны в области реплики, но поскольку была выбрана опция исключения связанных записей, то аннотация, связанная со зданиями и земельными участками, не будет реплицирована.
Пример №4
В данном примере, хотя область реплики включает в себя четыре объекта собственности (17691, 17692, 17698, 17697), которые имеют связанные с ними зданиями, все здания были вручную исключены из репликации. Поскольку на глобальном уровне модель поведения, настроенная на включение связанных объектов, все еще имеет силу для других классов пространственных объектов, то аннотация объекта собственности будет снова включена в создаваемую реплику.
Пример №5
В данном примере показано то, что произойдет в случае наличия кольцевых отношений (circular relationship). В течение процесса создания реплики система использует определенную логику для разрыва круга с целью предотвращения бесконечного продолжения обработки по кругу. Однако данная логика делает это таким образом, что предсказать порядок, в котором отношения будут обработаны, становится невозможным.
Чтобы вы могли получить ожидаемый результат в случае наличия кольцевых отношений (circular relationship), вы можете выбрать соответствующую опцию, чтобы не обрабатывать одно из отношений или выбрать обработку в обратном направлении для одного из классов отношений. Например, на расположенной ниже схеме показан случай, где для R3 установлена обработка в обратном направлении. Теперь порядок обработки предсказуем T1 - T2 - T3. В такой схеме T3 будет иметь связанные записи, добавленные из T1 и T2, но из T3 в T1 или T2 записи добавляться не будут.
Классы отношений, в которых поле ObjectID является первичным ключом
Репликация с классами отношений, в которых поле ObjectID используется как первичный ключ требует дополнительной обработки в ходе синхронизации, который может повлиять на ход работы. В некоторых случаях это может привести к непредвиденному поведению. Рассмотрим это немного подробнее. Возможно, после прочтения этого раздела, вы решите изменить ваши классы отношений с использованием полей первичного ключа, нежели просто поля ObjectID. Преимущества включают следующее:
- Классы отношений с полем первичного ключа типа GlobalID и полем внешнего ключа типа GUID
- Ваше личное поле первичного ключа, уникальное для всей базы данных
Дополнительная обработка в ходе синхронизации, когда поле ObjectID является полем первичного ключа
Значения ObjectID в классе объектов или таблицы не являются уникальными для всей базы геоданных. Новая строка в реплике базы геоданных может получить тот же ObjectID, что и другая строка в другой реплике. Процесс синхронизации должен учесть эти изменения при трансфере отношений между репликами баз геоданных, когда первичный ключ является столбцом ObjectID. Для этого процесс синхронизации выявляет классы отношений, которые используют столбец ObjectID. Если такие классы существуют, процесс передает дополнительную информацию, которая затем используется при выполнении дополнительной обработки. Она включает корректировку значений внешнего ключа для того, чтобы назначить соответствующее значение ObjectID в целевой базе геоданных для каждого измененного отношения. В случаях, когда редактируется большое число отношений, эта дополнительная обработка может оказать значительное влияние на процесс синхронизации.
Непредвиденное поведение, когда поле ObjectID является полем первичного ключа
Ниже перечислены случаи, когда вы можете получить непредвиденное поведение:
Изменения, в которых исходная строка не существует в целевой реплике базы геоданных—Как описано выше, процесс синхронизации запускает дополнительную обработку для поддержки отношений, когда поле ObjectID является полем первичного ключа в классе отношений. Однако, отношения не поддерживаются в случаях, когда редактирование включает ссылку на исходную строку, которая не существует в связанной реплике базы геоданных. При вставке это отражается во внешнем ключе, для которого устанавливает нулевое значение в строке назначения. При обновлении значение внешнего ключа остается таким же, каким оно было до синхронизации в строке назначения. Обратите внимания, что при откреплении реплик этого не произойдет.
Рисунок выше показывает случай, в котором простой класс отношений существует между участками и зданиями, где поле ObjectID класса участков является исходным первичным ключом. В данном примере реплика создается только для участков и зданий в рамках пространственного экстента. Однако, после создания реплики выявляется ошибка оцифровки, показывающая, что здание было оцифровано на неверном участке. Это исправлено в родительской реплике базы геоданных путем перемещения здания и редактирования отношения таким образом, что это здание связывается с правильным участком. Затем реплика синхронизируется, чтобы применить изменения к дочерней реплике. В этом случае здание перемещено, но до сих пор связано с неправильным участком в дочерней реплике. Класс отношений не был изменен в дочерней реплике, поскольку корректная исходная строка (участок с ObjectID 102 в родительской) не существует в дочерней реплике базы геоданных. В этих случаях отношения не изменяются.
Висячие внешние ключи—
При создании реплики строки копируются их базы геоданных-источника в целевую базу геоданных на основании того, как определена реплика. При определении реплики вы можете выбрать, включать ли строки из таблицы назначения без связанных строк в исходной таблице. Значения внешнего ключа в таблице-адресате для этих несвязанных строк те же, что и в базе геоданных-источнике. Это висячие внешние ключи, поскольку строка-источник, на которую они ссылаются, не существуют в целевой базе геоданных.
Рисунок выше описывает пример того, где непредвиденное поведение может отразиться при наличии висячих внешних ключей. В данном случае родительская реплика базы геоданных имеет простой класс отношений между участками и зданиями. Класс участков является исходным и использует поле ObjectID в качестве первичного ключа. Реплика создана, чтобы собрать все здания города и участки в единый блок. Процесс создания реплики копирует соответствующие участки и здания из родительской реплики базы геоданных в дочернюю реплику базы геоданных. В дочерней реплике здания, связанные с участками за пределами города, имеют висячие внешние ключи, поскольку эти участки не являются частью реплики. Например, здание с внешним ключом 100 имеет висячий внешний ключ, поскольку участок с ObjectID 100 не существует в дочерней версии. Если в дочерней реплике будет создан новый участок со значением ObjectID, равным 100, он будет неумышленно связан со зданием.