Доступно с лицензией Standard или Advanced.
В процессе создания реплики, строки и объекты добавляются в реплику на основании фильтров, определенных в приложении. Как только фильтры будут применены, для включения дополнительных связанных объектов будут обрабатываться классы отношений.
Обработка класса отношений включает в себя изучение каждого набора данных, который участвует по меньшей мере в одном классе отношений. По окончании изучения набора данных все строки, которые уже были реплицированы, группируются и используются для организации запроса к связанным строкам в связанных наборах данных. Любые связанные строки, которые будут возвращены после выполнения запросов, будут добавлены к реплике. Каждый набор данных будет изучен один раз в течение данного процесса.
В ArcGIS AllSource класс отношений всегда обрабатывается только в одном направлении, вперед. Направление вперед означает, что класс-источник будет изучен для добавления в него связанных строк из класса-адресата в реплику. Вы также можете отключить обработку определенного класса отношений во время создания реплики.
В приведенных ниже примерах показано поведение репликации по отношению к связанным объектам. В этих примерах используется модель данных простого отношения источник-адресат между объектами собственности, зданиями и связанными с ними аннотациями.
Пример №1
В данном примере показано, что область реплики включает в себя восемь земельных участков и шесть зданий. После создания реплики были добавлены два дополнительных здания, поскольку они связаны с земельными участками. Обработка класса отношений также добавит аннотации для зданий и земельных участков в реплику.
В предыдущем примере реплика создана с применением поведения по умолчанию, которое включает связанные объекты. В ArcGIS AllSource можно настроить репликацию и заменить это поведение на глобальном уровне при использовании инструмента геообработки Создать реплику. На глобальном уровне процесс репликации может быть настроен так, чтобы никакие связанные объекты, которые имеют связь с объектами, выбранными для репликации, не были включены.
Пример №2
В данном примере показано то, что произойдет в случае наличия кольцевых отношений. В течение процесса создания реплики система использует логику для разрыва круга с целью предотвращения бесконечного продолжения обработки по кругу. Однако данная логика делает это таким образом, что предсказать порядок, в котором отношения будут обработаны, становится невозможным.
Классы отношений, в которых поле ObjectID является первичным ключом
Репликация с классами отношений, в которых поле ObjectID используется как первичный ключ, требует дополнительной обработки в ходе синхронизации, что может повлиять на производительность. В некоторых случаях это может привести к непредвиденному поведению. Рассмотрим это немного подробнее. Возможно, после прочтения этого раздела, вы решите изменить ваши классы отношений, чтобы использовать поля первичного ключа, отличные от поля ObjectID. Далее приведены хорошие альтернативные варианты:
- Классы отношений с полем первичного ключа типа GlobalID и полем внешнего ключа типа GUID
- Создать и использовать собственное поле первичного ключа, уникальное для всей базы данных
Дополнительная обработка в ходе синхронизации, когда поле ObjectID является полем первичного ключа
Значения ObjectID в классе объектов или таблицы не являются уникальными для всей базы геоданных. Новая строка в реплике базы геоданных может получить тот же ObjectID, что и другая строка в другой реплике. Процесс синхронизации должен учитывать эти различия при передаче отношений между репликами баз геоданных, когда первичным ключом в отношениях является столбец ObjectID . Для этого процесс синхронизации выявляет классы отношений, которые используют столбец ObjectID. Если такие классы существуют, процесс передает дополнительную информацию, которая затем используется при выполнении дополнительной обработки.
Она включает корректировку значений внешнего ключа для того, чтобы назначить соответствующее значение ObjectID в целевой базе геоданных для каждого измененного отношения. В случаях, когда редактируется большое число отношений, эта дополнительная обработка может оказать значительное влияние на процесс синхронизации.
Непредвиденное поведение, когда поле ObjectID является полем первичного ключа
Далее описываются случаи, когда при использовании поля ObjectID в качестве первичного ключа может наблюдаться непредвиденное поведение:
- Изменения, в которых исходная строка не существует в целевой реплике базы геоданных—Как описано выше, процесс синхронизации запускает дополнительную обработку для поддержки отношений, когда поле ObjectID является полем первичного ключа в классе отношений. Однако, отношения не поддерживаются в случаях, когда редактирование включает ссылку на исходную строку, которая не существует в связанной реплике базы геоданных. При вставке это отражается во внешнем ключе, для которого устанавливает нулевое значение в строке назначения. При обновлении значение внешнего ключа остается таким же, каким оно было до синхронизации в строке назначения. Обратите внимание, что такое поведение не встречается с репликами открепления/прикрепления.
- Рисунок выше показывает случай, в котором простой класс отношений существует между участками и зданиями, где поле ObjectID класса участков является исходным первичным ключом. В данном примере реплика создается только для участков и зданий в рамках пространственного экстента. Однако, после создания реплики выявляется ошибка оцифровки, показывающая, что здание было оцифровано на неверном участке. Это исправлено в родительской реплике базы геоданных путем перемещения здания и редактирования отношения таким образом, что это здание связывается с правильным участком. Затем реплика синхронизируется, чтобы применить изменения к дочерней реплике. В этом случае здание перемещено, но до сих пор связано с неправильным участком в дочерней реплике. Класс отношений не был изменен в дочерней реплике, поскольку корректная исходная строка (участок с ObjectID 102 в родительской реплике) не существует в дочерней реплике базы геоданных. В этих случаях отношения не изменяются.
- Висячие внешние ключи – при создании реплики строки копируются из исходной базы геоданных в целевую базу геоданных на основании того, как определена реплика. При определении реплики вы можете выбрать, включать ли строки из таблицы назначения без связанных строк в исходной таблице. Значения внешнего ключа в таблице-адресате для этих несвязанных строк те же, что и в базе геоданных-источнике. Это висячие внешние ключи, поскольку исходная строка, на которую они ссылаются, не существует в целевой базе геоданных.
- Рисунок выше описывает пример того, где непредвиденное поведение может отразиться при наличии висячих внешних ключей. В данном случае родительская реплика базы геоданных имеет простой класс отношений между участками и зданиями. Класс участков является исходным и использует поле ObjectID в качестве первичного ключа. Реплика создана, чтобы собрать все здания города и участки в единый блок. Процесс создания реплики копирует соответствующие участки и здания из родительской реплики базы геоданных в дочернюю реплику базы геоданных. В дочерней реплике здания, связанные с участками за пределами города, имеют висячие внешние ключи, поскольку эти участки не являются частью реплики. Например, здание с внешним ключом 100 имеет висячий внешний ключ, поскольку участок с ObjectID 100 не существует в дочерней версии. Если в дочерней реплике будет создан новый участок со значением ObjectID, равным 100, он будет неумышленно связан со зданием.