Escenarios de versiones tradicionales

Disponible con una licencia Standard o Advanced.

El versionado se puede aplicar en varios escenarios y puede variar en función de los requisitos empresariales de cada organización. Las consideraciones generales para editar flujos de trabajo y configuraciones de versionado recomendadas se describen con ilustraciones a continuación.

Los flujos de trabajo varían entre organizaciones. A menudo, se transforman en etapas discretas y cada etapa requiere la asignación de un conjunto específico de recursos y reglas de negocios. Normalmente, cada etapa del proceso general representa una sola unidad de trabajo, como una orden de trabajo. Para administrar cada orden de trabajo, puede crear una versión separada aislada y modificarla. Una vez que el trabajo esté terminado, puede integrar los cambios en la versión publicada de la base de datos. Trabajar con las versiones de esta forma le permite acomodar los procesos de flujo de trabajo más básicos, así como los más complejos.

El concepto de versionado es el mismo independientemente de si utiliza versionado en rama o versionado tradicional. El versionado proporciona varias representaciones de los datos sin copiar datos, permite la edición concurrente y permite a los usuarios tener versiones durante períodos de tiempo prolongados. Consulte Descripción general del versionado para más información.

Versionado tradicional proporciona la flexibilidad para trabajar en versiones para transacciones largas accediendo directamente desde la geodatabase corporativa, así como una experiencia de edición simplificada al utilizar servicios de entidades para acomodar transacciones más cortas.

Se muestra una descripción general del flujo de trabajo de versionado tradicional.

Lo más probable es que utilice la edición simultánea de la configuración de la base de datos publicada, con varios editores modificando la versión predeterminada, o una mezcla de las otras configuraciones. Entender los requisitos empresariales y de la organización, así como las ventajas y las limitaciones de cada escenario de versionado tradicional, le ayudará a elegir lo mejor para su organización.

Para mayor sencillez y por razones relacionadas con la administración de geodatabases, se recomienda mantener un árbol de versiones plano.

Editar la versión predeterminada

La versión predeterminada es la versión inicial creada cuando los datos se registran como con versionado tradicional. Cuando utiliza el versionado tradicional y el acceso a versiones se establece en Público, varios editores pueden editar y ver datos simultáneamente utilizando la versión predeterminada. La forma más sencilla de admitir la edición multiusuario es permitir que varios editores editen la versión predeterminada directamente.

Si el acceso a la versión Predeterminada (naranja) está definido como público, los editores pueden editar directamente la versión Predeterminada. Los visualizadores que se conecten a la presión predeterminada verán las actualizaciones realizadas en la versión Predeterminada.

Cuando cada editor empieza a editar la versión predeterminada, en la sesión de edición se crea automáticamente una versión temporal, sin nombre. Esta versión temporal solo es accesible al editor actual. Cuando el editor guarda su trabajo o finaliza la sesión de edición, los cambios registrados en la versión temporal se publican en la versión predeterminada.

Si otro editor ha editado la versión predeterminada desde que se inició la edición, al guardar el trabajo, ArcGIS concilia y Publica los cambios automáticamente. Se le notifica que la versión ha cambiado y debe guardarse de nuevo para aceptar los cambios realizados por otros editores. Si existen conflictos, debe resolverlos con el cuadro de diálogo de resolución de conflictos para poder guardar las ediciones correctamente.

Consideraciones

Tenga en cuenta las siguientes ventajas y limitaciones al trabajar con la versión predeterminada o al editarla:

• Ventajas
  • Esta estrategia admite bien las modificaciones simples de la base de datos, porque los usuarios no tienen que crear nuevas versiones para editar los datos. Esto es adecuado cuando las unidades de trabajo son bastante pequeñas o cuando no se requieren alternativas de diseño persistentes.
  • Si no hay ningún conflicto, las ediciones guardadas se publican directamente en la versión predeterminada.
• Limitaciones
  • La versión predeterminada cambia constantemente y es susceptible de modificaciones accidentales o no autorizadas; por tanto, es posible que el administrador de base de datos deba realizar copias de seguridad de la base de datos con mayor frecuencia.
  • No se admiten las transacciones de larga duración ni la creación de versiones de diseño alternativo que abarquen muchas sesiones de edición.
  • Solo puede haber una operación de conciliación activa por geodatabase en un momento dado. Si hay frecuentes operaciones de conciliación y publicación desde varias sesiones de edición, es posible que los editores que guarden sus cambios tengan que esperar a que se completen los procesos activos de conciliación y publicación. En una geodatabase grande, multiusuario, es mejor evitar las situaciones donde muchos usuarios concilian y envían a una versión común. La conciliación y publicación bloquean exclusivamente la versión. Mientras este bloqueo está en su lugar, se evita que otros usuarios completen sus tareas.

Más información sobre configuración para guardar los datos

Más información sobre cómo resolver conflictos de datos

Editar una versión secundaria

Si está administrando varios proyectos, órdenes de trabajo o trabajos, necesitará un planteamiento estructurado de administración de flujos de trabajo. Es posible mantener unidades de trabajo discretas que impliquen muchas sesiones de edición y abarquen varios días, semanas o meses sin que ello afecte a la versión predeterminada. Algunos ejemplos de estas unidades de trabajo discretas podrían ser un esquema de mejora de carreteras, la instalación de un nuevo servicio telefónico o un proyecto de mantenimiento en curso para una conducción de gas.

Si utiliza el versionado tradicional, al iniciar una orden de trabajo o un proyecto, se crea una versión como un elemento secundario de la versión predeterminada.

Si el acceso a la versión Predeterminada (naranja) está definido como público, los editores pueden editar directamente la versión Predeterminada o pueden crear y editar una versión secundaria, como la Versión A (verde) o la Versión B (morado). A continuación, los editores pueden conciliar (R) y (P) sus ediciones en la versión Predeterminada. Los visualizadores que se conecten a la presión predeterminada verán las actualizaciones realizadas o publicadas en la versión Predeterminada.

Uno o más editores pueden trabajar en esta versión hasta que se complete la orden de trabajo o el proyecto. Cuando se completan todas las modificaciones de una versión secundaria, el editor o el administrador concilia con la versión predeterminada y resuelve los conflictos. A continuación, se publican las modificaciones en la versión predeterminada, integrando las modificaciones en la base de datos publicada. En este punto, se puede quitar la versión secundaria.

Los permisos de acceso de usuario a la versión predeterminada pueden restringirse para forzar este flujo de trabajo y asegurarse de que no se modifique la versión predeterminada. El administrador puede establecer el permiso de la versión predeterminada como Protegido, lo cual permite que los usuarios sigan viendo la versión predeterminada, pero restringe su nivel de acceso a solo lectura. Cualquier editor que desee modificar los datos debe crear una nueva versión secundaria.

Si el acceso a la versión Predeterminada (naranja) está definido como protegido, los editores solo pueden realizar ediciones en una versión secundaria, como la Versión A (verde) o la Versión B (morado). Los editores pueden conciliar (R) y publicar (P) sus ediciones en la versión predeterminada protegida y los visualizadores que se conectan a la versión predeterminada ven las actualizaciones realizadas o publicadas en la versión predeterminada.

Cuando utiliza el versionado tradicional, el acceso a versiones se determina mediante una combinación de los privilegios del usuario de la base de datos y el nivel de permiso de acceso (Público, Protegido o Privado) establecido para la versión.

Consideraciones

Tenga en cuenta las siguientes ventajas y limitaciones al trabajar con la versión secundaria o al editarla:

• Ventajas
  • Simplicidad: cada unidad de trabajo se segrega lógicamente por versión.
  • Se admiten las transacciones de larga duración que abarcan muchas sesiones de edición, así como la creación de diseños alternativos, permitiendo que los editores desarrollen propuestas sin afectar a la base de datos de producción.
  • Al crear una nueva versión a partir de la versión predeterminada, se protege la vista de producción de la base de datos frente a modificaciones involuntarias. Los proyectos de trabajo individuales se integran con la base de datos de producción cuando se completan.
  • Se admiten procesos de conciliación y publicación por lotes.
• Limitaciones
  • Como ocurre con cualquier configuración de versión multinivel, cuantas más filas se mantengan en las tablas delta de versión, mayor será el impacto potencial sobre el rendimiento de las consultas de versión. Esta sobrecarga se puede minimizar comprimiendo la base de datos periódicamente y actualizando las estadísticas del DBMS.

Admitir editores y visualizadores

Si su organización necesita admitir un grupo de editores y los usuarios que acceden al sistema con acceso de solo lectura, los editores utilizan el flujo de trabajo de versionado tradicional descrito en el escenario Editar una versión secundaria. Si los usuarios de solo lectura no necesitan la capacidad de ver los cambios tan pronto como se publiquen en la versión predeterminada, puede crear una versión protegida, estática, a partir de la versión predeterminada para que la utilicen. Esta versión se debe crear una vez comprimida la base de datos y reconstruidos los índices y las estadísticas. Haciendo esto se asegura de que todas las filas necesarias para representar la versión de solo lectura se almacena en la tabla básica y que la base de datos rinda de manera óptima. En este escenario, no se realiza ningún cambio en la versión de los usuarios de solo lectura de la base de datos, de modo que no es necesario ejecutar las consultas de diferencias de versión, y las estadísticas y los índices de la base de datos no quedan obsoletos ni se fragmentan. Tras cada compresión programada de la base de datos, se vuelve a crear esta versión, lo cual permite a los usuarios de solo lectura acceder a los cambios realizados desde la última compresión de la base de datos.

Una vez que los editores publican las ediciones en la versión Predeterminada (naranja), se puede crear una versión estática o de solo lectura protegida a partir de la versión Predeterminada. Esta Versión B de solo lectura (morado) se debe crear después de que todas las ediciones de la Versión A secundaria (verde) se hayan conciliado (R) y publicado (P) en la versión Predeterminada y se haya comprimido la base de datos y se hayan reconstruido los índices y las estadísticas. Este proceso garantiza que los visualizadores que se conectan a esta Versión B de solo lectura puedan acceder a los cambios realizados desde la última compresión de la base de datos.

Administración de datos distribuidos

Existen varias formas de distribuir datos versionados entre su organización para facilitar distintos flujos de trabajo.

Replicación de geodatabases

La replicación de geodatabase funciona directamente con geodatabases o servicios de geodatos y admite flujos de trabajo para mantenerlos sincronizados. Se proporcionan herramientas en ArcGIS Pro para realizar la replicación de geodatabase como se proporcionaron en ArcGIS Desktop. La mayoría de estos flujos de trabajo requieren datos con versionado tradicional.

Por ejemplo, algunos proyectos requieren que dos o más oficinas distantes trabajen en los mismos datos. Cada oficina requiere acceso local a la base de datos y, por lo tanto, cada una crea una copia de la base de datos. Cuando se hace un cambio en los datos en una ubicación de oficina, el cambio también se debe aplicar a los datos de la otra ubicación de oficina. Para mantener las copias de las bases de datos sincronizadas, las oficinas pueden transferir entre sí los cambios de manera programada. Esta funcionalidad se conoce como replicación de geodatabases.

La replicación también es útil para un editor que, de lo contrario, tendría que editar datos a través de una red lenta. En este caso, la replicación permite extraer un subconjunto de los datos en un equipo local para que el editor pueda trabajar en él sin utilizar la red. Una vez completadas las ediciones, se pueden transferir a través de la red y volver a fusionarlas en la base de datos de producción. Para obtener más información, consulte Escenarios de datos distribuidos.

Servicios de entidades

Los datos con versionado tradicional también se pueden publicar como servicios de entidades habilitados para la sincronización. Permiten flujos de trabajo con aplicaciones de captura de datos móviles o ArcGIS Pro donde los editores pueden descargar una copia de los datos, realizar ediciones locales y, después, llamar a la sincronización en el servicio de entidades. Al trabajar con datos con versionado tradicional y editores móviles, aprenda a usar y trabajar con datos con versionado tradicional en servicios de entidades que utilice sin conexión.

Los servicios de entidades también pueden participar en flujos de trabajo de colaboración distribuida. Por ejemplo, la colaboración distribuida (o simplemente, colaboración) admite servicios de entidades que incluyen capas de entidades que se ejecutan en datos con versionado tradicional. Permite compartir como una copia servicios de entidades con la sincronización habilitada cuando los servicios de entidades compartidos con la colaboración se ejecutan en copias separadas de los datos. Para obtener más información sobre el proceso y los conceptos de colaboración, consulte Cómo funciona la colaboración.