Для понимания того, как представления работают в версионной среде, важно сначала уяснить основные принципы версионного редактирования и то, как представления класса пространственных объектов хранятся в базе геоданных.
Как представления работают в версионной среде?
Классы пространственных объектов с представлениями принимают большее участие в версионной среде, нежели классы пространственных объектов без них. Ниже перечислены несколько ключевых моментов:
- Создание представлений - это изменение схемы — Поскольку в схему в разных версиях вносить изменения нельзя, представление, добавленное в версионный класс пространственных объектов, будет отображаться во всех версиях. Точно так же, удаление представления из класса пространственных объектов отразится во всех версиях. Представления могут быть созданы только при выключенном сеансе редактирования. Информация о правиле представления хранится в неверсионной системной таблице, то есть существует в базе данных.
- Создание и изменение правил представления - это изменение схемы - Все вновь созданные правила, изменения в структуре, значениях свойств или замещениях полей в правиле представления являются изменением схемы и будут немедленно отражены во всех версиях. Информация о правиле представления хранится в неверсионной системной таблице, то есть существует в базе данных. Правила представления могут быть изменены только при выключенном сеансе редактирования.
- Применение правил представления к объектам - это изменение атрибутов — Правила представления присваиваются объектам с использованием поля идентификаторов RuleID. Применение другого правила к объекту или удаление для объекта всех правил являются изменением атрибутов. Это будет отражено только в текущей версии. Конфликты могут быть разрешены с помощью стандартных процедур улаживания и записи.
- Замещение формы - это изменение атрибутов — Замещения формы будут отражены только в текущей версии до тех пор, пока не будут осуществлены улаживание конфликтов и запись.
- Замещение свойства правила представления - это изменение атрибутов — Замещения будут отражены только в текущей версии. Конфликты могут быть разрешены с помощью стандартных процедур улаживания и записи.
- Конвертация представления объекта в свободное представление - это изменение атрибутов — Процесс создания свободного представления будет влиять как на поле RuleID, так и на поле Override. Значение поля RuleID, если представление объекта является свободным, всегда равно -1. Конфликты могут быть разрешены с помощью стандартных процедур улаживания и записи.
Существующие рекомендации для использования представлений в версионной среде
Сценарий 1
- Родительская (целевая) версия изменяет представление RuleID с R на R* для представления пространственного объекта.
- Дочерняя (редактируемая) версия редактирует представление этого же объекта, но вместо этого добавляет замещение атрибута, которое сохраняется в поле Override как O*.
- Дочерняя версия - это открепление родительской версии. В зависимости от того, как определяются конфликты, вы можете получить разные результаты.
- Уровень строки: так как в обеих версиях редактируется один и тот же объект, выявляется конфликт. Конфликт разрешается в пользу одной из версий, в зависимости от приоритетности. Таким образом, в итоге в представлении будет либо правило RuleID R с замещением Override O* , либо правило RuleID R* с замещением Override O. Результаты согласованы между собой.
- Уровень столбца: так как редактируется одно и то же представление пространственного объекта, изменения вносятся в два разных поля или атрибута, называющихся RuleID и Override. Это не выявит конфликт. После согласования у представления правило RuleID равно R*, а замещение атрибута - O*. У представления пространственного объекта есть замещение атрибута для свойства, которое на принадлежит правилу представления, с которым представляется. Результаты противоречивы.
- Чтобы избежать подобной ситуации, используйте вместо этого опцию замещения на уровне строки row_level.
Сценарий 2
- Родительская (целевая) версия изменяет форму представления пространственного объекта или добавляет замещение формы, которое сохраняется в поле замещений Override как O*.
- Дочерняя (редактируемая) версия редактирует это же представление объекта, но добавляет вместо этого замещение атрибута, которое сохраняется в поле замещений Override как O**.
- Дочерняя версия - это открепление родительской версии. Независимо от версии, для которой вы решили разрешать конфликты, результат будет одним и тем же.
- Уровень строки или столбца: одно представление объекта редактируется в обеих версиях. К тому же правка вносится в замещение одного и того же атрибута. Хотя замещения формы и атрибутов - это два разных элемента, правка вносится в одно и то же поле замещений Override. Конфликты выявляются, и вам приходится оставить лишь одно из этих замещений - O* или O**.
- Обходной путь: Сохраняйте изменения атрибутов в явном поле, а не в поле замещений Override. При согласовании - в случае, если выбирается определение на уровне столбца, - у вас не будет выявлено никаких конфликтов, так как правка вносится в два разных поля (поле замещений Override и в явное поле). В результате, вы сможете сохранить оба изменения.
Сценарий 3
- Родительская версия (целевая) создает замещение атрибута для представления пространственного объекта. Поле замещений Override обновляется до O*.
- Дочерняя версия (редактируемая) изменяет это же представление, но конвертирует представление пространственного объекта в свободное представление. Значение RuleID меняется на -1, и графический объект заносится в поле замещений Override. В результате, на этом шаге изменяются оба поля - правил RuleID и замещений Override - на R* и O**.
- Дочерняя версия - это открепление родительской версии.
- На уровне строки или столбца: Возникает конфликт. Если вы разрешаете конфликты в пользу родительской (целевой) версии, результат будет противоречивый. Замещение атрибута O* будет существовать со значением RuleID равным -1 или R*.
- Обходной путь: Чтобы избежать противоречивых результатов, разрешайте конфликты в пользу дочерней версии. В этом случае сохраняйте внесенные в дочернюю версию изменения и игнорируйте изменения родительской версии. Однако вам необходимо обратить внимание, что в этом случае теряются изменения, внесенные в родительскую версию.
Сценарий 4
Если у вас есть несколько картографических продуктов, основанных на нескольких представлениях одного и того же класса пространственных объектов, используйте сценарий нескольких проектов (Multiple Project) для редактирования картографических продуктов. Например, создайте по отдельной версии для каждого картографического продукта: M1, M2, M3 и т. д. После редактирования этих версий, согласуйте и отправьте в родительские версии (или SDE.Default) с использованием определения и разрешения любых конфликтов на уровне столбца в пользу редактируемой версии. Если вы хотите записать замещения атрибутов в дополнительное поле вместо поля замещений Override, тогда создайте по дополнительному полю для каждого из картографических продуктов.
наилучшие способы
- Почему конфликт на уровне столбцов появляется, когда я замещаю два разных свойства объекта в двух разных версиях?
Неполадки могут возникнуть, когда два разделенных свойства замещаются в двух разных версиях. Конфликт появится в обоих замещениях, хранящихся в поле Override, которое является полем для хранения замещений по умолчанию. Например, объекту приписывается правило Проселочная дорога (Cart Track) в версии 1 и версии 2. В версии 1 толщина линии для условного обозначения проселочной дороги для данного объекта была замещена. В версии 2 был замещен только цвет условного символа проселочных дорог для данного объекта, но толщина линии осталась той же, как указано в правиле. Поскольку оба замещения хранятся в поле Override, конфликт возникнет при использовании обоих способов разрешения конфликтов - на уровне строк и на уровне столбцов, несмотря на то, что изменения на самом деле не конфликтуют. Чтобы предупредить эту ситуацию, лучшее, что можно сделать - внести свойства, которые вы хотели бы заместить, в явные поля. Это разделит изменения в уникальных полях, поэтому они не будут выявляться при проверке строк и столбцов.
- У меня имеется большая рабочая база данных с большим количеством версий и длинной историей. Необходимо ли мне отменить регистрацию класса пространственных объектов в качестве версионного до того, как я начну создание представлений?
Создание новых представлений класса пространственных объектов приводит к созданию двух новых полей - RuleID и Override - в таблице класса пространственных объектов во всех версиях. Если вы создадите представление, конвертировав слой условных обозначений, поле RuleID появится только в текущей версии. Представление класса пространственных объектов появится и во всех остальных версиях, но значения поля RuleID в них будут нулевыми. Обновление идентификаторов RuleID для всех версий базы данных может оказаться трудоемким. Если ваш рабочий процесс позволяет, создайте представления до того, как зарегистрируете вашу базу данных в качестве версионной. Это будет быстрее, чем создание представлений для версионных классов пространственных объектов, потому что таблицы разностей не должны быть заполнены. Если все изменения будут занесены в версию DEFAULT, или база данных была сжата с целью сохранения изменений, отмените регистрацию данных в качестве версионных до создания новых представлений классов пространственных объектов. При создании нового представления добавляются два поля, RuleID и Override (изменение схемы), а также заполняются значения поля RuleID. Если вы создали новое представление класса пространственных объектов в дочерней (производной) версии, тогда новые поля создаются во всех остальных версиях, но в родительской версии значения поля RuleID не заполняются. Очень хорошая практика — создавать представления новых классов пространственных объектов в версии SDE.Default, чтобы значения правил представлений переходили в поле RuleID во всех производных версиях.
Создание новых представлений для класса пространственных объектов, зарегистрированного в качестве версионного, будет осуществляться медленнее, так как поле RuleID обновляется для всех пространственных объектов, а потому обновляются и дельта-таблицы. Этот процесс занимает много времени и напрямую зависит от размера вашей базы данных.