Доступно с лицензией Standard или Advanced.
Класс отношения содержит ряд свойств, определяющих, каким образом объекты в источнике связаны с объектами в назначении. Эти свойства указываются при создании класса отношений.
- Тип: простой или составной
- Классы-источники и классы-адресаты
- Первичные и внешние ключи
- Кардинальность: к какому типу относится отношение (один-к-одному, один-ко-многим или многие-ко-многим)?
- Направление отправки сообщения применяется при необходимости выполнения каскадного обновления или удаления поведения.
- Хотите ли вы сохранить атрибуты для каждого отношения.
- Имя (Name)
- Прямые и обратные подписи, которые отображаются при навигации по связанным записям в ArcMap.
После создания отношения можно указать правила, чтобы доработать кардинальность.
Простой и составной
При создании класса отношений вы указываете, является ли он простым или составным.
В простом отношении связанные объекты могут существовать независимо друг от друга. Например, в железнодорожной сети, могут быть железнодорожные стрелки, имеющие один или более связанных с ними семафоров. Однако, железнодорожная стрелка может существовать без семафора, а семафоры могут существовать в железнодорожной сети и там, где нет стрелок.
Когда вы удаляете объект-источник в простом отношении, значение поля внешнего ключа для сопоставления объекту-адресату устанавливается в нулевое. Такое поведение внешнего ключа было разработано для сохранения целостности на уровне ссылок между объектами. Когда объект-источник удален, значение в строке внешнего ключа больше не связывается с объектом в источнике и, как результат, значение внешнего ключа устанавливается на нулевое и больше не используется. Основной задачей внешнего ключа является поддержание отношения между объектом-адресатом и связанным с ним объектом-источником. Если отсутствует объект-источник с соответствующим значением первичного ключа, тогда нет необходимости в поддержании значения внешнего ключа. Если в дальнейшем необходимо связать тот же объект назначения с новым или отличным объектом-источником, поле внешнего ключа (FK) можно обновить с нулевого значения на требуемое значение.
Удаление объекта-адресата никак не скажется на значении первичного ключа в связанном объекте-источнике.
Простые отношения могут иметь кардинальность «один к одному», «один ко многим» или «многие ко многим».
Как и в случае простых отношений, сложные отношения также поддерживают целостность на уровне ссылок при удалении объектов, но реализуется это по-другому. В сложном отношении объекты-адресаты не могут существовать независимо от объектов-источников, т.е. при удалении источника связанный объект-адресат тоже удаляется в процессе каскадного удаления.
Это правило зависимости также подкрепляется командой ArcMap Проверить объекты (Validate Features), которая запускается в сеансе редактирования для проверки целостности ссылочных данных. Если вы создали объект-адресат, но не связали его с объектом-источником, то инструмент Проверить объекты (Validate Features) выдаст сообщение об ошибке.
Сложное отношение может помочь вам поддерживать объекты пространственно; если отправление сообщений установлено в прямом (Forward) направлении, перемещение или вращение исходного объекта заставляет соответственно перемещаться или вращаться объекты назначения.
При создании сложные отношения всегда работают по принципу один-ко-многим, но с помощью правил отношений могут быть ограничены до действия один-к-одному.
Классы-источники и классы-адресаты
При создании класса отношений вы выбираете один класс в качестве источника и один в качестве адресата. Важно не перепутать эти классы. Учитывая поведение каскадного удаления в сложных отношениях, важность этого момента очевидна.
В простом отношении также важно соблюсти этот шаг. Поскольку при удалении записи в классе-источнике простой класс отношений находит соответствующие записи в классе-адресате и обнуляет значения их ключевых полей. Если вы в качестве источника выберите неверный класс и удалите объекты в источнике, то появятся ошибки в поле внешнего ключа. На следующем примере показано, как такое может произойти.
Ситуация 1: участок в зону (неправильно)
Это типичный сценарий, приводящий к ошибке. Таблица зон содержит описания различных кодов зон и концептуально сходна со справочной таблицей ArcGIS for Desktop Advanced. В этом случае класс участков является источником, а таблица зон — адресатом. Именно так следует устанавливать отношение в ArcGIS for Desktop Advanced. Проблема в том, что при удалении участка значение ключевого поля (зона) для соответствующей записи в таблице зон обнуляется, а другие участки, имеющие идентичный код зоны, не будут сопоставлены в таблице зон.
Ситуация 2: зона в участок (правильно)
Для устранения ошибки установите таблицу зон в качестве источника. Удаление участка (объект-адресат) никак не скажется на таблице зон, а удаление кода зоны (объект-источник) просто обнулит значение поля зоны в соответствующих записях участка, что и должно произойти, поскольку они больше не имеют соответствующих записей в таблице зоны.
Первичные и внешние ключи
В классе отношения объекты в источнике соответствуют объектам в адресате с помощью значений в ключевых полях. В следующем примере участок 789 соответствует пропускам 2 и 3, потому что эти записи имеют одинаковый идентификатор участка.
Ключевое поле в классе-источнике отношения называется первичный ключ (primary key) и часто обозначается аббревиатурой ПК (PK). В отличие от настоящего первичного ключа, значения полей первичного ключа в отношении не обязательно должны быть уникальными для каждого объекта.
Ключевое поле в классе-адресате называется внешний ключ (foreign key) и часто обозначается аббревиатурой ВК (FK). Оно содержит значения, которые соответствуют значениям поля первичного ключа в классе-источнике. Значения ключевого поля, опять-таки, не обязательно должны быть уникальными для каждой строки.
Ключевые поля могут иметь различные имена, но должны быть одного типа и содержать одинаковую информацию, такую как идентификаторы участков, например. Ключевыми полями могут быть поля любых типов данных, кроме больших двоичных объектов (BLOB), даты и растров. Ключевые поля указываются при создании класса отношений.
При выборе поля первичного ключа можно использовать поле идентификатора (ID) строки, часто называемого поле ObjectID. Поле ObjectID автоматически добавляется ArcGIS когда вы создаете класс или таблицу объектов или регистрируете слой или таблицу ArcSDE. Это поле обеспечивает уникальный идентификатор для каждой записи. Оно управляется ArcGIS, вы не можете изменять его.
Значение ObjectID объекта остается неизменным все время, пока он находится в своем исходном классе, и вы не можете разбить объект, если он является пространственным. Если вы разбиваете пространственный объект, он сохраняется в виде оригинального объекта (но с обновленной геометрией) и создает новый объект с новым назначенным идентификатором ObjectID. В результате только объект с оригинальным ObjectID сохранит отношения, зависимые от значения ObjectID.
Поэтому правильнее будет не полагаться на поле ObjectID и самому создать поле первичного ключа. Следующий пример показывает, как созданное вами поле первичного ключа помогает поддерживать отношения при выполнении следующих операций.
- Когда вы импортируете записи в другой класс объектов или таблицу, назначаются новые значения ObjectID, а отношения, основанные на исходных значениях ObjectID, теряются. Если вместо этого вы основываете отношение на другом первичном ключе, то при импорте записей значения идентификатора в первичном ключе не изменяются. Это позволяет сохранить отношения при импорте связанных наборов объектов в новые классы.
Исключением является использование функции Копировать/Вставить (Copy/Paste). Копировать/Вставить (Copy/Paste) сохраняет значения ObjectID, поэтому, если вы собираетесь перемещать объекты только этим методом, можете использовать поле ObjectID в качестве первичного ключа.
- Репликация с классами отношений, в которых поле ObjectID используется как первичный ключ требует дополнительной обработки в ходе синхронизации, который может повлиять на ход работы. В некоторых случаях это может привести к непредвиденному поведению. Более подробно об использовании ObjectID в качестве первичного ключа с репликацией см. Репликация связанных данных.
- Когда вы разбиваете объект, то сохраняется оригинальный объект (с обновленной геометрией) и создается новый. Если отношение основано на оригинальном идентификаторе ObjectID, только один из двух объектов, созданных в результате разбиения, сохранит это отношение. Но если вы использовали другое поле в качестве ключевого, при разбиении объекта значение идентификатора исходного объекта копируется в оба новых объекта. В результате записи в связанных таблицах привязываются к обоим новым объектам, что особенно удобно при использовании класса отношений многие-ко-многим.
Если вы не собираетесь разбивать объекты и уверены, что объекты останутся в исходном классе, можете использовать ObjectID в качестве идентификатора. Если такой уверенности нет, лучше самому создать поле идентификатора, а не полагаться на поле ObjectID.
- Когда вы выполняете слияние двух объектов, новый объект сохраняет ObjectID одного из исходных объектов. Если вы планируете выполнять слияние объектов, но не хотите перемещать объекты из классов или разбивать их, можете использовать ObjectID в качестве первичного ключа.
Кардинальность
Кардинальность отношения определяет количество объектов в классе-источнике, которые могут быть связаны с объектами в классе-адресате. Отношение может иметь одну из трех кардинальностей:
Один-к-одному: один объект-источник может быть связан с одним объектом-адресатом. Например, участок может иметь только одно официальное описание. В ArcGIS к этой кардинальности может также относится тип многие-к-одному. Примером отношения многие-к-одному может быть привязывание нескольких участков к одному официальному описанию.
Один-ко-многим: один объект-источник может быть связан с несколькими объектами-адресатами. Например, участок может иметь несколько зданий. В отношении один-ко-многим одним должен быть класс-источник, а в качестве многих должен выступать класс-адресат.
Многие-ко-многим: один объект-источник может быть привязан к нескольким объектам-адресатам и, наоборот, один объект-адресат может быть привязан к нескольким объектам-источникам. Например, у одной собственности может быть несколько владельцев или у одного владельца может быть несколько объектов собственности.
Категории один и многие могут ввести вас в заблуждение. Один значит ноль-к-одному, много значит ноль-к-множеству. Таким образом, когда вы создаете отношение один-ко-многим, например, между участком и зданиями, это отношение предполагает следующее:
- Участок без зданий
- Здание без участка
- Участок с любым количеством зданий
После создания отношения можно уточнить кардинальность с помощью установки правил для отношения. Вы можете установить правила, определяющие количество объектов в источнике, которые могут быть привязаны к объектам в адресате.
Правила отношений
При создании класса отношений вы выбираете одну из кардинальностей: один-к-одному, один-ко-многим или многие-ко-многим.
Зачастую определение отношения требует более жестких правил. В отношении между участками и зданиями, например, вам может понадобиться указать, что каждое здание должно относиться к определенному участку или участок может иметь определенное количество зданий. Важно не допустить, чтобы пользователь забыл связать здание с участком или привязал слишком много зданий к участку.
Если у вас есть подтипы, можно ограничить количество и тип объектов в источнике, которые привязываются к определенному типу объектов в адресате. Например, стальные столбы поддерживают трансформаторы класса А, в то время как деревянные поддерживают трансформаторы класса В. Более того, вам возможно понадобится указать допустимый диапазон кардинальности для каждой разрешенной пары подтипа. Например, стальной столб может поддерживать от 0 до 3 трансформаторов класса А, в то время как деревянный столб поддерживает от 0 до 2 трансформаторов класса В.
После создания класса отношения можно указать правила, подкрепляющие целостность ссылочных данных:
- В ArcCatalog или в окне Каталога щелкните правой кнопкой на существующем классе отношений, чтобы вызвать диалоговое окно Свойства класса отношений (Relationship Class Properties), и щелкните вкладку Правила (Rules).
- Выберите подтип из класса-источника и отметьте соответствующий подтип в классе-адресате.
- Установите отметки для кардинальности источника и адресата. Установите подходящие мин. и макс. значения кардинальности для правила. Диалоговое окно не дает установить мин. значение больше макс., поэтому сначала установите макс. значение кардинальности.
Когда правило отношения добавлено в класс отношения, это правило становится единственным возможным корректным отношением. Чтобы активировать другие комбинации отношений и кардинальностей, необходимо добавить дополнительные правила отношений.
В следующем примере показано, что свалка токсичных отходов может быть привязана к одному или двум колодцам и находиться между двумя или семью родниками. Но, если обычная свалка привязана к колодцу, и для этих подтипов не было создано правила, то команда Проверить объекты (Validate Features) посчитает это отношение некорректным.
После того, как вы установили правила и начали редактирование, можно запустить проверку с помощью команды ArcMap Проверить объекты (Validate Features). Команда Проверить объекты (Validate Features) проверяет, нарушают ли выбранные в данный момент объекты правила отношений.
Направление отправки сообщения
Как уже упоминалось, при удалении объекта-источника в сложном отношении автоматически удаляются связанные объекты-адресаты.
При работе как в простых, так и в сложных отношениях существует также ряд других действий, которые для запуска обновления одного объекта требуют обновления связанного с ним объекта. Кроме того, обновления могут потребоваться как в одном направлении, так и в обоих сразу.
- Когда вы перемещаете или поворачиваете объект, необходимо чтобы перемещались или вращались также связанные с ним объекты.
- Когда вы обновляете объект, необходимо чтобы атрибут связанного объекта обновлялся автоматически.
- В процессе обновления объекта-источника может потребоваться обновление связанного объекта-адресата.
- В процессе обновления объекта-адресата может потребоваться обновление связанного объекта-источника.
Если ваше отношение требует такого поведения, можно включить обмен сообщениями между источником и адресатом для уведомления друг друга при осуществлении изменений, что позволит привязанным объектам обновляться автоматически.
Для осуществления этого задайте направление отправки сообщения при создании отношения. Если обновление источника требует обновления связанных объектов-адресатов, установите направление отправки сообщения Вперед (Forward). Если обновление адресата требует обновления связанных объектов-источников, установите направление отправки сообщений Назад (Backward). Если требуется задействовать оба направления, задайте направление отправки сообщений В обе стороны (Both). После создания отношения, необходимо запрограммировать поведение объектов при получении сообщения, чтобы они могли ответить.
Единственным исключением являются сложные отношения, где сообщения отправляются только Вперед (Forward). Когда вы создаете сложное отношение с прямым сообщением, перемещение или вращение объекта-источника заставляет соответственно перемещаться или вращаться объекты назначения. При условии, что вы создали отношение правильно, эта функция начинает действовать сразу же после создания отношения, дополнительное программирование при этом не требуется.
Для других направлений отправки сообщений требуется пользовательское программирование. Если вы не создаете сложное отношение с прямым сообщением или же программируете нестандартное поведение, установите направление сообщения Нет, сообщения не передаются (None). В противном случае, сообщения будут без надобности генерироваться каждый раз при выполнении любой операции редактирования, что замедляет работу.
При установке направления в сложном отношении помните, что при удалении объекта-источника в сложном отношении все связанные объекты-адресаты также удаляются автоматически. Это происходит независимо от того, посылаются сообщения в прямом, обратном, обоих направлениях или не посылаются совсем.
| Направление | Действие в простых отношениях | Действие в сложных отношениях |
|---|---|---|
Следующий экстент | Не работает без пользовательского программирования |
|
Обратно (Backward) | Не работает без пользовательского программирования |
|
Оба (Both) | Не работает без пользовательского программирования |
|
Нет | Не допускает отправку сообщений, незначительно улучшая производительность |
|
Отношения многие-ко-многим
В отношениях один-к-одному и один-ко-многим значения в первичном ключе класса-источника напрямую связаны со значениями во внешнем ключе класса-адресата.
Отношения многие-ко-многим, с другой стороны, требуют использования промежуточных таблиц для связки ассоциаций. В результате при создании отношения многие-ко-многим автоматически создается промежуточная таблица. Промежуточная таблица связывает значения первичных ключей источника со значениями внешних ключей из адресата. Каждая строка связывает один объект-источник с одним объектом-адресатом.
Когда промежуточная таблица создана, для вас генерируются только поля. ArcGIS не знает, какой из объектов-источников связан с конкретным объектом-адресатом, поэтому вам необходимо вручную создать строки в ArcMap. Заполнение этой таблицы является наиболее трудоемким моментом во всем процессе настройки отношения.
Атрибуты отношения
Промежуточная таблица отношения многие-ко-многим может дополнительно служить в качестве хранилища атрибутов отношения. Например, в базе данных участков у вас может быть класс отношений между участками и владельцами, где владельцы владеют участками, а участки принадлежат владельцам. Атрибутом каждого отношения может быть собственность в процентах. Если требуется сохранить такие атрибуты, можно добавить их в промежуточную таблицу в процессе создания отношения или в любое другое время после этого.
Маловероятно, но когда вы настраиваете отношения один-к-одному или один-ко-многим, вам также может понадобиться сохранить атрибуты отношений. В таком случае для создания промежуточной таблицы вам нужно указать это в процессе создания отношения. Так же, как и в отношениях многие-ко-многим, промежуточная таблица связывает значения первичных ключей источника со значениями внешних ключей адресата, позволяя вам сохранять любое количество атрибутов для каждого отношения.
Вы можете предварительно просмотреть промежуточную таблицу в ArcCatalog или в окне каталога, чтобы проверить содержащиеся в ней данные. Если добавить класс отношений в ArcMap, он появится в виде таблицы, которую можно открыть и отредактировать. ArcGIS не предоставляет промежуточную таблицу для других операций. Вы не сможете отобразить ее свойства в ArcCatalog или в окне каталога, чтобы добавить или удалить поля, также она не поддерживает использование значений по умолчанию или доменов.
Имя (Name)
Каждый класс отношений имеет имя, которое отображается в дереве каталога. Чтобы сделать структуру базы данных простой для понимания, назначайте классам отношений имена, которые описывают эти отношения.
Начните с имени класса исходного объекта, затем добавьте союз и (Has/Have), и закончите именем класса объекта назначения. Например, AddressHasZones или ParcelsHaveOwners. В классах исходных объектов используйте множественное число, если применяется кардинальность многие-к-одному или многие-ко-многим; используйте множественное число в классах объектов назначения, если применяется кардинальность один-ко-многим или многие-ко-многим.
Используя такой метод, вы сможете определить кардинальность отношения по его имени. Если оба класса объектов записаны во множественном числе, например, ParcelsHaveOwners, это означает, что используется отношение многие-ко-многим.
Прямые и обратные подписи
Прямые и обратные подписи отображаются в диалоговых окнах Атрибуты (Attributes) и Результаты идентификации (Identify results) в ArcMap и помогают при навигации между связанными объектами.
Класс отношений имеет две подписи:
- Прямая подпись отображается при навигации от источника к адресату. В примере со столбом и трансформатором эта подпись может выглядеть как «поддерживает» (supports), это означает, что столб поддерживает трансформаторы (pole support transformers).
- Обратная подпись отображается при навигации от адресата к источнику. В примере со столбом и трансформатором эта подпись может выглядеть как «установлены» (is mounted on), это означает, что трансформаторы установлены на столбе (transformers are mounted on this pole).