В данном разделе Работа с версиями, таким образом, предоставит вам возможность управления процессами как самых основных, так и сложных рабочих потоков.
В различных организациях структура рабочих потоков может различаться. Часто они представляются отдельными этапами, причем на каждом этапе появляется необходимость в размещении различных видов ресурсов и бизнес-правил. Как правило, каждый этап в общем процессе представляет собой отдельную часть работы, например, рабочий наряд. Для управления каждым рабочим нарядом вы можете создать отдельную, изолированную версию и изменять уже ее. Как только вы закончите работу и будете удовлетворены ее результатом, вы сможете внести произведенные изменения в публикуемую версию базу данных. Работая с версиями подобным образом, вы получаете возможность обеспечивать основные рабочие потоки, а также наиболее сложные.
Скорее всего, вы будете использовать либо параллельное редактирование публикуемой базы данных (когда множество редакторов изменяют версию DEFAULT), либо некоторое сочетание других конфигураций. Понимание задач бизнеса и организации, а также оценки «за» и «против» в использовании каждой из конфигураций, поможет вам принять решение, которое будет оптимальным для вашей организации.
Для удобства и простоты рекомендуется либо поддерживать плоское дерево версий, либо чтобы несколько редакторов одновременно редактировали версию DEFAULT.
Параллельное редактирование опубликованной базы данных
Несколько пользователей могут редактировать одну и ту же версию одновременно, так что самым простым способом поддержки многопользовательского редактирования для множества пользователей является редактирование версии DEFAULT напрямую.
Как только каждый редактор начнет редактировать версию DEFAULT, то автоматически в данной сессии редактирования будет создана безымянная временная версия. Данная временная версия будет доступна только для текущего редактора. Когда редактор сохранит свою работу или завершит сессию редактирования, изменения, которые были записаны во временной версии, будут закреплены в версии DEFAULT.
Если другой пользователь отредактировал версию DEFAULT после того, как вы начали редактирование, то при сохранении вашей работы, ArcGIS автоматически произведет согласование и закрепление изменений. Вы будете оповещены о том, что версия была изменена и что вы должны сохраниться еще раз, чтобы принять изменения, выполненные другими редакторами. Вы можете сделать так, чтобы это сообщение с предупреждением не выводилось, установив опцию автосогласования в диалоговом окне Опции (Options) ArcMap. Независимо от того будет выводиться сообщение или нет, если в данных появятся какие-то конфликты, то вам придется их решить с использованием диалогового окна разрешения конфликтов, до сохранения ваших изменения.
Более подробно о настройках для сохранения данных
Более подробно о разрешении конфликтов в данных
Преимущества:
- При использовании данного подхода вы можете обеспечить нормальную работу при внесении в базу данных простых изменений, потому что пользователям не нужно создавать новые версии для редактирования данных. Данный подход будет оптимальным в том случае, если число выполняемых работ незначительное или когда нет необходимости в постоянном наличии вариантов развития проекта.
- Если конфликтов не будет, то сохраненные изменения будут закреплены в версии DEFAULT напрямую.
Недостатки:
- Версия DEFAULT постоянно изменяется и подвержена случайным или неавторизованным изменениям. Следовательно, администратору баз данных может потребоваться создавать резервные копии баз данных чаще.
- Не поддерживается выполнение длинных транзакций или создание альтернативных версий проектов, которые могут длиться в течение нескольких сессий редактирования.
- Одномоментно в одной базе геоданных активной может быть только одна операция согласования. Если в вашей работе часто производятся согласования и закрепления изменений из различных сессий редактирования, то редакторам, сохраняющим изменения, может понадобиться ждать завершения каких-либо согласований и закреплений. При работе с большой многопользовательской базой геоданных лучше избегать ситуаций, в которых большое количество пользователей будет производить согласование и закрепление изменений в общей версии одновременно. Согласование и закрепление версии установит на нее эксклюзивную блокировку; во время блокировки другие пользователи не могут завершить их задачи.
Несколько проектов
При управлении несколькими проектами или рабочими нарядами вам потребуется использовать более структурированный подход в управлении рабочими потоками. Обслуживание отдельных работ, включающих в себя множество сессий редактирований и длящихся несколько дней, недель или месяцев, может выполняться без влияния на версию DEFAULT. Примерами таких отдельных единиц работы может быть схема улучшения автомагистрали, установка нового переговорочного пункта или проект постоянного обслуживания газопровода.
В начале выполнения рабочего наряда или проекта производится создание версии, которая является дочерней версией версии DEFAULT. До завершения работы над проектом и рабочего наряда над этой версией могут работать несколько редакторов. По завершении всех изменений версии редактор или администратор ArcSDE производит согласование версии DEFAULT и разрешает любые возникающие конфликты. После этого закрепляются все изменения в версии DEFAULT, добавляя произведенные изменения в публикуемую базу данных. После этого дочерняя версия может быть удалена.
Вы можете ограничить права доступа пользователей к версии DEFAULT для обеспечения работы данного рабочего потока, а также для того, чтобы версия DEFAULT не была изменена. Администратор ArcSDE может установить ограничение на право доступа к версии DEFAULT. Это дает пользователям возможность продолжать просматривать версию DEFAULT, ограничивает их права доступа до уровня «только для чтения». Любой редактор, который захочет изменить данные, будет должен создать новую версию.
Если вашим пользователям с правами доступа «только для чтения» не нужна возможность просмотра изменений сразу же после закрепления изменений в версии DEFAULT, то вы можете создать защищенную, статичную версию из версии DEFAULT, которую они смогут использовать. Данная версия должна быть создана после сжатия базы данных, перепостроения индексов и обновления статистики. Это позволит вам обеспечить то, что все строки, необходимые для представления версии только для чтения, хранятся в основной таблице, и что производительность базы данных будет оптимальна. При использовании типа доступа «только для чтения» в версии не производится никаких изменений (FastTrak на рисунке ниже) следовательно, нет необходимости выполнять запросы на сравнение версий и статистика базы данных и индексы не становятся устаревшими или фрагментированными. После выполнения каждого запланированного сжатия базы данных эта версия создается заново, позволяя пользователям с доступом «только для чтения» иметь доступ к изменениям, которые были произведены с момента последнего сжатия базы данных.
Преимущества:
- Простота: каждая единица работы логически выделяется версией.
- Поддержка длинных транзакций, длящихся несколько сессий редактирования, а также создание альтернативных версий проектов, позволяющих редакторам производить ввод предполагаемых изменений без оказания влияния на представление базы данных.
- Создание новой версии из версии DEFAULT защищает представление базы данных от ненамеренных изменений. Отдельные рабочие проекты объединяются с представлением базы данных после их завершения.
- Поддержка пакетных согласований/процессов закрепления.
Недостатки:
- Как и при любой многоуровневой конфигурации версии, чем больше строк будет обслуживаться в версионных дельта-таблицах, тем большее влияние будет оказываться на производительность в обработке запросов к версии. Влияние таких издержек может быть сведено к минимуму путем регулярного выполнения сжатия базы данных и обновления статистики СУБД.
Наличие большого количества проектов с подпроектами
Работа со сложными проектами потребует от вас более тщательной структуризации рабочих потоков по сравнению с подходом по параллельному редактированию или работе с несколькими проектами. Данные проекты могут быть в последующем разделены на множество функциональных или географических единиц, из которых может быть развита более сложная иерархия версий. Например, проект проектирования и постройки нового торгового центра может иметь определенные этапы постройки, разделяемые на восточную и западную части, или подразделяемые по типу строительных работ, например, стройка, проведение коммуникаций или дизайн ландшафта.
При работе с большими проектами, которые включают в себя различные группы специалистов и многочисленные отдельные единицы работы, эффективным способом организации рабочих потоков является использование многоуровневого дерева версий. Команды специалистов, работающих над различными частями одного и того же проекта, создают свою собственную версию для обслуживания частного представления их обновлений. Как только проект будет завершен, версии можно будет согласовать и закрепить в версии DEFAULT, и они станут неотъемлемой частью публикуемой базы данных.
Преимущества:
- Поддержка сложных проектов
- Поддержка длинных транзакций, длящихся несколько сессий редактирования
- Поддержка автосогласования и автозакрепления
Недостатки:
- Вы должны согласовать и закрепить версии в определенном порядке, начиная с версий, наиболее удаленных от версии DEFAULT, и двигаясь обратно к ней. Иначе говоря, версии, являющиеся версиями третьего уровня (правнуки (great grandchildren)) версии DEFAULT должны быть закреплены в их родителях, которые являются версиями второго уровня (внуки) версии DEFAULT. Данные версии второго уровня затем могут быть закреплены в версиях первого уровня (дочерние версии) версии DEFAULT. Наконец, версии первого уровня (дочерние версии) могут быть закреплены в версии DEFAULT.
После того, как каждая дочерняя версия будет закреплена в ее родительской версии, дочерняя версия может быть удалена.
- Согласование и закрепление может производиться между версиями только по прямому пути; вы не можете согласовывать и закреплять изменения между несколькими путями версий.
- Обслуживание сложного дерева версий имеет влияние на производительность: чем больше строк в дельта-таблицах версии, тем больше влияние на производительность при обработке запросов.
Проекты с фазами
Многие проекты проходят свое развитие через установленную или регламентируемую группу стадий, для каждой из которых требуется проектировочное, административное или юридическое одобрение для перехода к следующей стадии. Например, в рамках проекта коммунального хозяйства стандартными стадиями развития проекта являются разработка и принятие предложения, конструирование и исполнение. Именно этот процесс можно считать циклическим: рабочий наряд исходно назначается инженеру и изменяется с течением времени по мере прохождения проекта через различные этапы до момента полного объединения результатов работы с представлением базы данных.
При таком подходе версия создается для представления каждой стадии данного процесса: исходный проект или предлагаемая версия, одобренная версия и версия для этапа конструирования. По мере прохождения проекта через различные контрольные точки на пути его выполнения происходит обзор и одобрение каждой стадии. Затем переходят к следующей версии, и так происходит до тех пор, пока не будет достигнута и завершена последняя стадия. Старые версии могут обслуживаться для получения архивных сведений или могут быть при необходимости удалены.
Как только проект будет выполнен, разрабатываемая версия может быть согласована с версией DEFAULT и напрямую закреплена в ней. Вам не нужно согласовывать и закреплять версию вашего проекта с предыдущими версиями ее родословной.
Преимущества:
- Этот метод подходит для проектов, развитие которых проходит через серии стадий, где каждая стадия должна быть выделена в отдельную единицу работы.
- Как и в случае всех других многоуровневых конфигураций, данный рабочий поток позволяет редакторам разрабатывать предполагаемые версии проекта, а также создавать альтернативные версии развития проекта, не оказывая влияния на представление базы данных.
- Вы можете закреплять изменения в версии DEFAULT напрямую. При таком подходе уходит необходимость в постоянном закреплении изменений вверх по дереву версий вплоть до версии DEFAULT.
Недостатки:
- Не подходит для пакетных согласований и процессов закрепления
Архивирование
Важным требованием для многих проектов является наличие возможности сохранения различных состояний базы данных по мере ее изменения с течением времени. Некоторые типичные запросы, на которые у базы геоданных должны быть ответы, включают следующее:
- Какой была база данных в определенный момент времени?
- Как изменялся с течением времени конкретный объект?
- Допустим, какой-то объект был удален из базы данных в определенный день, какие объекты в настоящий момент времени существуют на месте расположения удаленного объекта?
Наиболее общим требованием, предъявляемым для обслуживания архивной версии, является наличие возможности сохранения архива версии DEFAULT, поскольку чаще всего она представляет публикуемую версию базы данных. Изменения версии DEFAULT могут возникнуть в результате внесения изменений в версию DEFAULT, а также могут быть согласованы и закреплены изменения других версий. База геоданных может быть настроена на автоматическую запись этих изменений. Эта функциональность уже встроена в базу геоданных; вам не потребуется дополнительное моделирование данных или настройка приложения для поддержки опции автоматического архивирования.
В некоторых проектах требуется архивировать другие, чем DEFAULT версии. Поскольку версия представляет собой состояние ее родительской версии в момент времени ее создания, то вы можете создать версию только для записи того, как выглядела ее родительская версия в конкретный момент времени. Вы можете произвести запись состояния проекта в определенный момент времени, можете создать новую архивную версию из версии проекта. Когда версия проекта будет согласована и закреплена в ее родительской версии, эта архивная версия может остаться в качестве записи состояния проекта в определенный момент времени.
Для получения более подробной информации об архивировании см.Процесс архивирования.
Управление распределенными данными
При выполнении некоторых проектов требуется наличие двух и более удаленно расположенных офисов, работающих над одними данными. Для каждого из этих офисов требуется наличие локального доступа к базе данных, а также создание копий этой базы данных. При выполнении изменений в данных, расположенных в одном месте, эти изменения должны также быть внесены в данные, расположенные в другом месте. Чтобы в удаленных друг от друга офисах были синхронизированные копии баз данных, сотрудники офисов могут передавать эти изменения друг другу на регулярной основе. Данная функциональная возможность называется репликацией базы геоданных.
Репликации также позволяют вам извлечь определенную часть базы геоданных для ее использования вне офиса и редактировать ее в автономном режиме. Это стандартное требование для сотрудников, работающих с данными на местности. Как только вы вернетесь в офис, вы сможете снова подключиться по сети к базе данных и внести произведенные вами изменения обратно в представление базы данных.
Репликации будут также удобны для тех, кто вынужден редактировать данные по сети с низкой скоростью передачи данных по каналу. В этом случае репликация может позволить вам извлечь определенный набор данных на ваш локальный компьютер, чтобы вы могли работать с ними без необходимости подключения по сети. Как только вы закончите редактирование, вы можете передать изменения по сети, внеся данные обратно в рабочую базу данных. Более подробно см. в разделе Примеры использования распределенных данных.