Свойства класса отношений

Доступно с лицензией Standard или Advanced.

Класс отношения содержит ряд свойств, определяющих, каким образом объекты в источнике связаны с объектами в назначении. Эти свойства указываются при создании класса отношений.

• Тип: простые или сложные
• Классы-источники и классы-адресаты
• Первичные и внешние ключи
• Кардинальность: к какому типу относится отношение (один-к-одному, один-ко-многим или многие-ко-многим)?
• Направление отправки сообщения применяется при необходимости использования каскадного поведения при обновлении или удалении.
• Хотите ли вы хранить атрибуты для каждого отношения
• Имя
• Прямые и обратные подписи, которые отображаются при навигации по связанным записям в ArcMap.

После создания отношения можно указать правила, чтобы доработать кардинальность.

Простые или сложные

При создании класса отношений вы указываете, являются ли они простыми или сложными.

В простом отношении связанные объекты могут существовать независимо друг от друга. Например, в железнодорожной сети, могут быть железнодорожные стрелки, имеющие один или более связанный с ними семафор. Однако, железнодорожная стрелка может существовать без семафора, а семафоры могут существовать в железнодорожной сети и там, где нет стрелок.

Когда вы удаляете объект-источник в простом отношении, значение поля внешнего ключа для сопоставления объекту-адресату устанавливается в нулевое. Такое поведение внешнего ключа было разработано для сохранения целостности на уровне ссылок между объектами. Когда объект-источник удален, значение в строке внешнего ключа больше не связывается с объектом в источнике и, как результат, значение внешнего ключа устанавливается на нулевое и больше не используется. Основной задачей внешнего ключа является поддержание отношения между объектом-адресатом и связанным с ним объектом-источником. Если отсутствует объект-источник с соответствующим значением первичного ключа, тогда нет необходимости в поддержании значения внешнего ключа. Если в дальнейшем необходимо связать тот же объект назначения с новым или отличным объектом-источником, поле внешнего ключа (FK) можно обновить с нулевого значения на требуемое значение.

Удаление объекта-адресата никак не скажется на значении первичного ключа в связанном объекте-источнике.

Простые отношения могут иметь кардинальность «один к одному», «один ко многим» или «многие ко многим».

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

Сложное отношение может помочь вам поддерживать объекты пространственно; если отправление сообщений установлено в прямом направлении, перемещение или вращение исходного объекта заставляет соответственно перемещаться или вращаться объекты назначения.

При создании сложные отношения всегда работают по принципу один-ко-многим, но с помощью правил отношений могут быть ограничены до действия один-к-одному.

Классы-источники и классы-адресаты

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

В простом отношении также важно соблюсти этот шаг. Поскольку при удалении записи в классе-источнике простой класс отношений находит соответствующие записи в классе-адресате и обнуляет значения их ключевых полей. Если вы в качестве источника выберите неверный класс и удалите объекты в источнике, то появятся ошибки в поле внешнего ключа. На следующем примере показано, как такое может произойти.

Ситуация 1: участок - зона (неправильно)

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

Ситуация 2: участок - зона (правильно)

Для устранения ошибки установите таблицу зон в качестве источника. Удаление участка (объект-адресат) никак не скажется на таблице зон, а удаление кода зоны (объект-источник) просто обнулит значение поля зоны в соответствующих записях участка, что и должно произойти, поскольку они больше не имеют соответствующих записей в таблице зоны.

Первичные и внешние ключи

В классе отношения объекты в источнике соответствуют объектам в адресате с помощью значений в ключевых полях. В следующем примере участок 789 соответствует пропускам 2 и 3, потому что эти записи имеют одинаковый идентификатор участка.

Ключевое поле в классе-источнике отношения называется первичный ключ и часто обозначается аббревиатурой ПК (PK). В отличие от настоящего первичного ключа, значения полей первичного ключа в отношении не обязательно должны быть уникальными для каждого объекта.

Ключевое поле в классе-адресате называется внешний ключ и часто обозначается аббревиатурой ВК (FK). Оно содержит значения, которые соответствуют значениям поля первичного ключа в классе-источнике. Значения ключевого поля, опять-таки, не обязательно должны быть уникальными для каждой строки.

Ключевые поля могут иметь различные имена, но должны быть одного типа и содержать одинаковую информацию, такую как идентификаторы участков, например. Ключевыми полями могут быть поля любых типов данных, кроме больших двоичных объектов (BLOB), даты и растров. Ключевые поля указываются при создании класса отношений.

При выборе поля первичного ключа можно использовать поле идентификатора (ID) строки, часто называемого поле ObjectID. Поле ObjectID автоматически добавляется приложением ArcGIS когда вы создаете класс или таблицу объектов или регистрируете слой или таблицу многопользовательской базы геоданных. Это поле обеспечивает уникальный идентификатор для каждой записи. Оно управляется ArcGIS, вы не можете изменять его.

Значение ObjectID объекта остается неизменным все время, пока он находится в своем исходном классе, и вы не можете разбить объект, если он является пространственным. Если вы разбиваете пространственный объект, он сохраняется в виде оригинального объекта (но с обновленной геометрией) и создает новый объект с новым назначенным идентификатором ObjectID. В результате только объект с оригинальным ObjectID сохранит отношения, зависимые от значения ObjectID.

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

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

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

• Когда вы разбиваете объект, то сохраняется оригинальный объект (с обновленной геометрией) и создается новый. Если отношение основано на оригинальном идентификаторе ObjectID, только один из двух объектов, созданных в результате разбиения, сохранит это отношение. Но если вы использовали другое поле в качестве ключевого, при разбиении объекта значение идентификатора исходного объекта копируется в оба новых объекта. В результате записи в связанных таблицах привязываются к обоим новым объектам, что особенно удобно при использовании класса отношений многие-ко-многим.

  Если вы не собираетесь разбивать объекты и уверены, что объекты останутся в исходном классе, можете использовать ObjectID в качестве идентификатора. Если такой уверенности нет, лучше самому создать поле идентификатора, а не полагаться на поле ObjectID.

• Когда вы выполняете слияние двух объектов, новый объект сохраняет ObjectID одного из исходных объектов. Если вы планируете выполнять слияние объектов, но не хотите перемещать объекты из классов или разбивать их, можете использовать ObjectID в качестве первичного ключа.

Кардинальность

Кардинальность отношения определяет количество объектов в классе-источнике, которые могут быть связаны с объектами в классе-адресате. Отношение может иметь одну из трех кардинальностей:

Один-к-одному - Один объект-источник может быть связан с одним объектом-адресатом. Например, участок может иметь только одно официальное описание. В ArcGIS к этой кардинальности может также относится тип многие-к-одному. Примером отношения многие-к-одному может быть привязывание нескольких участков к одному официальному описанию.

Один-ко-многим - Один объект-источник может быть связан с несколькими объектами-адресатами. Например, на участке может быть несколько зданий. В отношении один-ко-многим одним должен быть класс-источник, а в качестве многих должен выступать класс-адресат.

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

Категории один и многие могут ввести вас в заблуждение. Один значит ноль-к-одному, много значит ноль-ко-многим. Таким образом, когда вы создаете отношение один-ко-многим, например, между участком и зданиями, это отношение предполагает следующее:

• Участок без зданий
• Здание без участка
• Участок с любым количеством зданий

Правила отношений

При создании класса отношений вы выбираете одну из кардинальностей: один-к-одному, один-ко-многим или многие-ко-многим.

Зачастую определение отношения требует более жестких правил. В отношении между участками и зданиями, например, вам может понадобиться указать, что каждое здание должно относиться к определенному участку, или участок может содержать определенное количество зданий. Важно не допустить, чтобы пользователь забыл связать здание с участком или привязал слишком много зданий к участку.

Если у вас есть подтипы, можно ограничить количество и тип объектов в источнике, которые привязываются к определенному типу объектов в адресате. Например, стальные столбы поддерживают трансформаторы класса А, в то время как деревянные поддерживают трансформаторы класса В. Более того, вам возможно понадобится указать допустимый диапазон кардинальности для каждой разрешенной пары подтипа. Например, стальной столб может поддерживать от 0 до 3 трансформаторов класса А, в то время как деревянный столб поддерживает от 0 до 2 трансформаторов класса В.

Для просмотра правил отношений для класса отношений щелкните этот класс отношений правой кнопкой в панели Каталог, чтобы открыть диалоговое окно Свойства класса отношений, и выберите вкладку Правила.

Появится список всех возможных правил, которые могут существовать данного класса отношений. Столбец, который Включен, показывает, которое из правил активно в данный момент.

Отображаемые правила классов отношений можно отсортировать, выбрав Сначала исходный, затем целевой подтип или Сначала целевой, затем исходный подтип в ниспадающем меню Сортировать по.

Для удаления правила из класса отношений снимите отметку Включено для строки, представляющей удаляемое правило, и щелкните OK.

Чтобы создать правило для класса отношений, выполните следующие действия:

1. Отметьте Включено для строки, представляющей правило, которое вы хотели бы добавить в класс отношений.
2. Задайте для правила значения Min и Max для исходного и целевого подтипов, указав целые числа в соответствующих ячейках
3. Повторите шаги 1 и 2 для каждого правила, которое вы желаете добавить.
4. Нажмите OK.

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

В следующем примере показано, что захоронение токсичных отходов может быть связано с 1-2 глубокими скважинами или 2-7 мелкими скважинами. Но, если с глубокой скважиной связана обычная свалка, и между этими подтипами не было создано правило, то команда Проверить объекты посчитает это отношение некорректным.

Направление отправки сообщения

Как уже упоминалось, при удалении объекта-источника в сложном отношении автоматически удаляются связанные объекты-адресаты.

При работе как в простых, так и в сложных отношениях существует также ряд других действий, которые для запуска обновления одного объекта требуют обновления связанного с ним объекта. Кроме того, обновления могут потребоваться как в одном направлении, так и в обоих сразу.

• Когда вы перемещаете или поворачиваете объект, необходимо чтобы перемещались или вращались также связанные с ним объекты.
• Когда вы обновляете объект, необходимо чтобы атрибут связанного объекта обновлялся автоматически.
• В процессе обновления объекта-источника может потребоваться обновление связанного объекта-адресата.
• В процессе обновления объекта-адресата может потребоваться обновление связанного объекта-источника.

Если ваше отношение требует такого поведения, можно включить обмен сообщениями между источником и адресатом для уведомления друг друга при осуществлении изменений, что позволит привязанным объектам обновляться автоматически.

Для осуществления этого задайте направление отправки сообщения при создании отношения. Если обновление источника требует обновления связанных объектов-адресатов, установите направление отправки сообщения Вперед. Если обновление адресата требует обновления связанных объектов-источников, установите направление отправки сообщений Назад. Если требуется задействовать оба направления, задайте направление отправки сообщений В обе стороны. После создания отношения, необходимо запрограммировать поведение объектов при получении сообщения, чтобы они могли ответить.

Единственным исключением являются сложные отношения, где сообщения отправляются только Вперед. Когда вы создаете сложное отношение с прямым сообщением, перемещение или вращение объекта-источника заставляет соответственно перемещаться или вращаться объекты назначения. При условии, что вы создали отношение правильно, эта функция начинает действовать сразу же после создания отношения, дополнительное программирование при этом не требуется.

Для других направлений отправки сообщений требуется пользовательское программирование. Если вы не создаете сложное отношение с прямым сообщением или же программируете нестандартное поведение, установите направление сообщения Нет, сообщения не передаются. В противном случае, сообщения будут без надобности генерироваться каждый раз при выполнении любой операции редактирования, что замедляет работу.

При установке направления в сложном отношении помните, что при удалении объекта-источника в сложном отношении все связанные объекты-адресаты также удаляются автоматически. Это происходит независимо от того, посылаются сообщения в прямом, обратном, обоих направлениях или не посылаются совсем.

Направления отправки сообщений

Направление	Действие в простых отношениях	Действие в сложных отношениях
Вперед	Не работает без пользовательского программирования	При удалении источника удаляется адресат. Перемещение или вращение источника перемещает или вращает адресата. Не работает, если не запрограммировано нестандартное поведение.
Назад	Не работает без пользовательского программирования	При удалении источника удаляется адресат. Не работает, если не запрограммировано нестандартное поведение.
Обе	Не работает без пользовательского программирования	При удалении источника удаляется адресат. Перемещение или вращение источника перемещает или вращает адресата. Не работает, если не запрограммировано нестандартное поведение.
Нет	Не допускает отправку сообщений, незначительно улучшая производительность	При удалении источника удаляется адресат. Не допускает отправку других сообщений, незначительно улучшая производительность.

Отношения многие-ко-многим

В отношениях один-к-одному и один-ко-многим значения в первичном ключе класса-источника напрямую связаны со значениями во внешнем ключе класса-адресата.

Отношения многие-ко-многим, с другой стороны, требуют использования промежуточных таблиц для связки ассоциаций. В результате при создании отношения многие-ко-многим автоматически создается промежуточная таблица. Промежуточная таблица связывает значения первичных ключей источника со значениями внешних ключей из адресата. Каждая строка связывает один объект-источник с одним объектом-адресатом.

Когда промежуточная таблица создана, для вас генерируются только поля. ArcGIS не знает, какой из объектов-источников связан с конкретным объектом-адресатом, поэтому вам необходимо вручную создать строки в таблице. Заполнение этой таблицы является наиболее трудоемким моментом во всем процессе настройки отношения.

Атрибуты отношения

Промежуточная таблица отношения многие-ко-многим может дополнительно служить в качестве хранилища атрибутов отношения. Например, в базе данных участков у вас может быть класс отношений между участками и владельцами, где владельцы владеют участками, а участки принадлежат владельцам. Атрибутом каждого отношения может быть собственность в процентах. Если требуется сохранить такие атрибуты, можно добавить их в промежуточную таблицу в процессе создания отношения или в любое другое время после этого.

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

Если добавить класс отношений на карту, он появится в виде таблицы, которую можно открыть и отредактировать. ArcGIS не предоставляет промежуточную таблицу для других операций. Например, вы не сможете отобразить ее свойства на панели Каталог, добавить или удалить поля в виде Поля, также она не поддерживает использование значений по умолчанию или доменов.

Имя

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

Начните с имени класса исходного объекта, затем добавьте Содержит (Has или Have) и закончите именем класса объекта назначения. Например, AddressHasZones или ParcelsHaveOwners. В классах исходных объектов используйте множественное число, если применяется кардинальность многие-к-одному или многие-ко-многим; используйте множественное число в классах объектов назначения, если применяется кардинальность один-ко-многим или многие-ко-многим.

Используя такой метод, вы сможете определить кардинальность отношения по его имени. Если оба класса объектов записаны во множественном числе, например, ParcelsHaveOwners, это означает, что используется отношение многие-ко-многим.

Подписи прямого и обратного отношения

Прямые и обратные надписи отображаются в диалоговых окнах Атрибуты и Результаты идентификации на панели Карта и помогают вам перемещаться между связанными объектами.

Класс отношений имеет две подписи:

• Прямая подпись отображается при навигации от источника к адресату. В примере со столбом и трансформатором эта подпись может выглядеть как «поддерживает», это означает, что столб поддерживает трансформаторы.
• Обратная подпись отображается при навигации от адресата к источнику. В примере со столбом и трансформатором эта подпись может выглядеть как «установлены», это означает, что трансформаторы установлены на столбе.