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