Escenarios de versiones

Este tema presenta la aplicación del versionado, es decir, cómo se puede aplicar esta tecnología dentro de la organización, e ilustra las configuraciones de versión que están disponibles.

Los flujos de trabajo varían enormemente 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. Generalmente, cada etapa del proceso total representa una unidad de trabajo discreta, como una orden de trabajo. Para administrar cada orden de trabajo, puede crear una versión separada aislada y modificarla. Una vez que esté conforme con el trabajo terminado, puede integrar los cambios en la versión publicada de la base de datos. Trabajar con versiones de esta manera permite tener en cuenta los procesos más básicos del flujo de trabajo así como los más complejos.

En general, se utiliza la edición concurrente de la base de datos publicada, con varios editores que modifican la versión DEFAULT, o alguna combinación de las otras configuraciones. La comprensión de los requisitos organizacionales y de negocios y la evaluación de las ventajas y desventajas de cada configuración, ayudará en el momento de elegir cual es la mejor opción para la organización.

Para mantener la simplicidad y tener en cuenta las consideraciones de la administración de geodatabases, se recomienda mantener un árbol de versiones plano o tener varios editores que editen en forma concurrente la versión DEFAULT.

Edición simultánea de la base de datos publicada

Muchos usuarios pueden editar la misma versión simultáneamente, de modo que la manera más simple de admitir la edición multiusuario es permitir que muchos editores editen directamente la versión DEFAULT.

Cuando cada editor empieza a editar la versión DEFAULT, 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 envían a la versión DEFAULT.

Si otro usuario ha editado la versión DEFAULT desde que se inició la edición, al guardar el trabajo, ArcGIS concilia y envía 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. Puede evitar este mensaje de advertencia habilitando la conciliación automática en el cuadro de diálogo Opciones de ArcMap. Tanto si evita este mensaje como si no, si hay conflictos deberá resolverlos con el cuadro de diálogo de resolución de conflictos antes de poder guardar correctamente las ediciones.

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

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

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 envían directamente a la versión DEFAULT.

Inconvenientes:

• La versión DEFAULT está cambiando constantemente y es vulnerable a modificaciones accidentales o no autorizadas; por consiguiente, es posible que el administrador de bases de datos tenga que crear copias de seguridad de la base de datos con más 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 envío 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 envío. En un 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 el envío bloquean exclusivamente la versión; mientras este bloqueo está vigente, los demás usuarios no pueden completar sus tareas.

Varios múltiples

Si está administrando varios proyectos u órdenes de trabajo, necesitará un enfoque más estructurado a la administración del flujo 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 DEFAULT. 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 continuado para una conducción de gas.

Cuando se inicia una orden de trabajo o un proyecto, se crea una versión como un elemento secundario de la versión DEFAULT. 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, el editor o el administrador de ArcSDE concilia con la versión DEFAULT, resolviendo los conflictos que surjan. A continuación, envía las modificaciones a la versión DEFAULT, 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 DEFAULT pueden restringirse para forzar este flujo de trabajo y asegurarse de que no se modifique la versión DEFAULT. El administrador de ArcSDE podría establecer el permiso de la versión DEFAULT en protegido; esto permite que los usuarios continúen viendo la versión DEFAULT, pero restringe su nivel de acceso a solo lectura. Cualquier editor que desee modificar los datos debe crear una nueva versión.

Si los usuarios de solo lectura no necesitan la capacidad de ver los cambios tan pronto como se envíen a la versión DEFAULT, podría crear una versión protegida, estática, a partir de la versión DEFAULT 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 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 (FastTrak en la ilustración siguiente), 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 obsoletas ni se fragmentan. Después de cada compresión programada de la base de datos, esta versión se recrearía, permitiendo el acceso de los usuarios de solo lectura a los cambios realizados desde la última compresión de la base de datos.

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 DEFAULT, 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 los procesos de conciliación y envío por lotes.

Inconvenientes:

• 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.

Proyectos múltiples con subproyectos

Los proyectos complejos requieren una estructura de flujo de trabajo más elaborada que la proporcionada por los enfoques de edición simultánea o de varios proyectos. Estos proyectos se pueden dividir a su vez en varias unidades funcionales o geográficas, a partir de las cuales se desarrolla una jerarquía de versiones más compleja. Por ejemplo, un proyecto para diseñar y construir un nuevo centro comercial podría tener distintas fases de construcción subdivididas en secciones este y oeste, o subdivididas por actividades de construcción, tales como edificación, instalación de servicios o paisajismo.

Para proyectos grandes que implican diferentes equipos y numerosas unidades discretas de trabajo, un árbol de versiones con varios niveles es una manera efectiva de organizar el flujo de trabajo. Los equipos que trabajan en diferentes aspectos del mismo proyecto crean su propia versión para mantener una vista privada de sus actualizaciones. Una vez completado el proyecto, las versiones se pueden conciliar y enviarse de vuelta a la versión DEFAULT, y se convierten en una parte integral de la base de datos publicada.

Ventajas:

• Admite proyectos complejos
• Admite transacciones de larga duración que abarquen muchas sesiones de edición
• Admite procesos automatizados de conciliación y envío por lotes

Inconvenientes:

• Debe conciliar y enviar las versiones en orden, empezando por las versiones más lejanas eliminadas de la versión DEFAULT y retrocediendo. En otras palabras, las versiones secundarias de tercer nivel de la versión DEFAULT se deben enviar a sus versiones primarias, que son versiones secundarias de segundo nivel de la versión DEFAULT. Estas versiones secundarias de segundo nivel se pueden enviar entonces a las versiones secundarias de primer nivel de la versión DEFAULT. Finalmente, las versiones secundarias de primer nivel se pueden enviar a la versión DEFAULT.

  Una vez que se envía cada versión secundaria a su versión primaria respectiva, la versión secundaria se puede eliminar.

• La conciliación y el envío solo pueden tener lugar entre versiones en la ruta de acceso directa; no es posible conciliar y enviar a través de rutas de versión.
• Mantener un árbol de versiones complejas tiene algunos costes de rendimiento asociados: cuantas más filas haya en las tablas delta de la versión, mayor será el impacto potencial sobre el rendimiento de las consultas.

Proyectos escalonados

Muchos proyectos evolucionan a través de un grupo prescrito o regulado de etapas que requieren aprobaciones de ingeniería, administrativas o legales antes de pasar a la etapa siguiente. Por ejemplo, dentro del dominio de los servicios, algunas etapas comunes son trabajando, propuesto, aceptado, construcción y construido. Este proceso en particular es esencialmente cíclico: una orden de trabajo se asigna inicialmente a un ingeniero y se modifica con el tiempo, a medida que el proyecto evoluciona a través de las diferentes fases hasta de la integración completa con la base de datos de producción.

En este enfoque, se crea una versión para representar cada etapa de este proceso: diseño inicial o versión propuesta, una versión aprobada y una versión para la fase de construcción. A medida que el proyecto avanza a través de diversos hitos de proyecto, cada etapa se revisa y se aprueba y, a continuación, es reemplazada por la siguiente versión hasta que se alcanza y se completa la última etapa. Las versiones anteriores se puede mantener como referencia histórica o se pueden eliminar, según sea necesario.

Cuando el proyecto ha finalizado, la versión construida se puede conciliar y enviar directamente a la versión DEFAULT, sin tener que conciliarse ni enviarse con las versiones anteriores del linaje.

Ventajas:

• Este método es adecuado para proyectos que evolucionan a través de una serie de etapas, donde cada etapa se debe aislar como una unidad de trabajo distinta.
• Como ocurre con todas las demás configuraciones de varios niveles, este flujo de trabajo permite a los editores desarrollar propuestas y alternativas de diseño sin afectar a la base de datos de producción.
• Los cambios se pueden enviar directamente a DEFAULT, que elimina la sobrecarga de enviar cambios progresivamente subiendo por el árbol de versiones hasta la versión DEFAULT.

Inconvenientes:

• No conveniente para los procesos de conciliación y envío por lotes

Archivar

Un requisito clave para muchos proyectos es la preservación de varios estados de la base de datos a medida que cambia con el tiempo. Algunas de las consultas típicas que una geodatabase puede tener que admitir son las siguientes:

• ¿Qué aspecto tenía la base de datos en un momento determinado?
• ¿Cómo ha cambiado una entidad determinada con el tiempo?
• Dado que una entidad se quitó de la base de datos en una determinada fecha, ¿qué entidades existen actualmente conde estaba la entidad eliminada?

Un requisito común para mantener un registro histórico es conservar un archivado de la versión DEFAULT, dado que habitualmente representa la versión publicada de la base de datos. Los cambios en DEFAULT puede producirse como resultado de ediciones en DEFAULT o de la conciliación y el envío de cambios desde otras versiones. Una geodatabase se puede configurar para que registre estos cambios automáticamente. Esta funcionalidad está integrada en la geodatabase; no se necesita ningún modelado de datos ni ninguna personalización de la aplicación adicional para admitir el archivado automatizado.

Algunos proyectos requieren el archivado de una versión distinta de DEFAULT. Dado que una versión representa el estado de su versión primaria en el momento que se crea, puede crear una versión con el único propósito de registrar el aspecto que tenía su versión primaria en un momento determinado. Por ejemplo, podría crearse una nueva versión histórica a partir de la versión de diseño. Cuando la versión de diseño se conciliara y se enviara a su versión primaria, la versión histórica permanecería como un registro del diseño en un momento determinado.

Para obtener más información detallada sobre el archivado, vea El proceso de archivado.

Administración de datos distribuidos

Algunos proyectos requieren que dos o más oficinas distantes trabajen sobre 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 de una ubicación, el cambio también se debe aplicar a los datos de la otra ubicación. Para mantener las copias de las bases de datos sincronizadas, los sitios pueden transferir entre sí los cambios de manera programada. Esta capacidad se conoce como replicación de geodatabases.

La replicación también permite llevar al campo un subconjunto de la geodatabase y editarla sin conexión; es un requisito común para los equipos de mantenimiento de campo. Al volver a la oficina, se puede volver a conectar a la red y combinar los cambios en la base de datos de producción.

La replicación también es útil para cualquiera que tenga que editar datos a través de una red lenta por cualquier otro motivo. En este caso, la replicación permite extraer un subconjunto de los datos al equipo local, para poder trabajar sobre ellos sin tener que comunicarse a través de la red. Una vez finalizada la edición, puede transferir los cambios a través de la red, combinándolos de vuelta en la base de datos de producción. Para obtener más información, vea Escenarios que utilizan datos distribuidos.