Escenarios de versión

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.

Edición simultánea de 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:

Inconvenientes:

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.

Administrar varios proyectos

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.

Administrar varios proyectos, con una versión que admita consultas e informes rápidos

Ventajas:

Inconvenientes:

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.

Proyectos múltiples con subproyectos

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:

Inconvenientes:

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 varias etapas, hasta 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 la 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.

Proyectos escalonados

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:

Inconvenientes:

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:

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.

Crear versiones para propósitos de archivado

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.

Las oficinas distantes pueden sincronizar sus copias de una geodatabase

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.

Temas relacionados


3/6/2012