Un paseo introductorio por el versionado
Este tema se aplica sólo a ArcEditor y ArcInfo.
El versionado permite que varios usuarios editen los mismos datos en una geodatabase de ArcSDE sin aplicar bloqueos o duplicar datos.
Los usuarios siempre acceden a una geodatabase de ArcSDE mediante una versión. Cuando se conecta a una geodatabase multiusuario, especifica la versión a la que se conectará. Por defecto, se conectará a la versión DEFAULT.
La versión DEFAULT
Todas las geodatabases de ArcSDE tienen una versión predeterminada que se llama DEFAULT; por lo tanto, siempre está habilitado el versionado para la geodatabase. Es una parte fundamental de la forma de operación de ArcGIS y no precisa ser instalada o configurada por separado.
A diferencia de otras versiones, la versión DEFAULT siempre existe y no se puede eliminar. En la mayoría de las estrategias de flujo de trabajo, es la versión publicada de la base de datos que representa el estado actual del sistema que se está modelando. Para mantener y actualizar la versión DEFAULT a lo largo del tiempo, debe publicarle los cambios de otras versiones. También puede editar la versión DEFAULT directamente, como cualquier otra versión.
La versión DEFAULT es la versión raíz y, por lo tanto, es anterior a todas las demás versiones.
Crear otras versiones
Se crea una versión al crear versiones secundarias o ramas de cualquier versión existente. La primera versión se crea al crear una versión secundaria de la versión DEFAULT. Cuando se crea la versión nueva, ésta es igual a la versión DEFAULT. Con el paso del tiempo, las versiones se diferenciarán a medida que se realizan cambios en la versión DEFAULT y la versión nueva.
Una geodatabase puede tener muchas versiones. El siguiente es el cuadro de diálogo Administrador de versiones, al que se accede mediante ArcGIS Desktop. Este ejemplo muestra la versión DEFAULT y otras tres versiones: una versión de garantía de calidad (QA) y versiones de proyecto: ProjectA y ProjectB.
El siguiente diagrama muestra cómo se relacionan las versiones. La versión QA es una versión secundaria de la DEFAULT y las versiones ProjectA y ProjectB son versiones secundarias de la QA.
Crear versiones da la falsa sensación de que se está creando una copia de toda la geodatabase. Esto se debe a que cada versión tiene todas las tablas y clases de entidades en la geodatabase. A medida que edita una clase de entidad o tabla en una versión, deja de ser la misma clase de entidad o tabla de la versión principal, entonces usted cree que está almacenando la clase de entidad o tabla en cada versión. Sin embargo, independientemente de la cantidad de versiones que haya, cada tabla y clase de entidad se almacena una sola vez en la base de datos. ArcGIS deja cada clase de entidad o tabla en su formato original pero registra los cambios en las tablas a las que se hace referencia como tablas delta.
Los usuarios pueden editar todas las versiones de manera simultánea. Varios usuarios también pueden editar la misma versión al mismo tiempo.
En las versiones de ejemplo más arriba, diferentes editores pudieron editar al mismo tiempo las versiones ProjectA y ProjectB. También es posible que la cantidad de usuarios que realicen cambios en la versión QA sea menor.
Cómo funcionan las versiones y las modificaciones versionadas
Antes de que pueda comenzar a realizar modificaciones versionadas en los datos de cualquier versión, los datasets deben registrarse como versionados.
Tenga en cuenta que registrar un dataset como versionado no es lo mismo que crear una versión. Al crear una versión se crea una especie de "visualización" de la geodatabase que le permite editar los datos versionados y ver los cambios inmediatamente. Otros usuarios conectados a la misma versión verán los cambios cuando actualicen la información. Sin embargo, los usuarios conectados a otras versiones no verán los cambios hasta que los concilie y los publique en la versión anterior. En el ejemplo anterior, una vez que los cambios se devuelven a la versión DEFAULT, se hacen visibles independientemente de la versión a la que esté conectado. Por el contrario, registrar un dataset (una clase de entidad, un dataset de entidad o una tabla) como versionado lo prepara para la edición versionada. Cuando registra un dataset como versionado, se crean dos tablas delta: la tabla A (o Inserciones) para inserciones y actualizaciones y la tabla D (o Borrados) para eliminaciones. Cada vez que actualiza o elimina un registro en un dataset, se agregan filas a una o ambas tablas. Por lo tanto, un dataset versionado consta de la tabla original (denominada la tabla base) más todos los cambios en las tablas delta. La geodatabase hace un seguimiento de las versiones a las que estuvo conectado cuando realizó las modificaciones que completaron las tablas delta. Cuando realiza una consulta o visualiza un dataset en una versión, ArcGIS ensambla las filas relevantes de la tabla original y de las tablas delta para presentar una vista sin interrupciones de los datos para esa versión.
Todas las modificaciones realizadas en la clase de entidad o tabla, independientemente de la versión desde la que se realizaron dichas modificaciones, se registran en las mismas tablas delta. En conjunto, todas las filas en las tablas base, A y D representan todas las versiones de la clase de entidad o tabla. Esto quiere decir que cualquier versión hace referencia sólo a un subconjunto de filas de las tres tablas. Entonces ¿cómo recuerda ArcGIS qué filas de las tablas delta pertenecen a cada versión?
Cada fila en las tablas A y D se marca con un identificador entero al que se denomina Id. de estado, que hace referencia al momento en que se agrega una fila a una tabla. Cada vez que edita una versión, se crea un nuevo estado y se agrega una nueva fila a una o ambas tablas delta. Se puede entender a los estados como parte de una estructura de árbol donde cada rama registra la evolución de una versión. Se denomina linaje a la secuencia de estados que registran una serie de cambios desde la tabla base al estado actual de una versión. Cuando visualiza o consulta una versión, ArcGIS consulta el linaje de la versión para obtener los Id. de estado, después obtiene los registros correctos de las tablas A y D.
A medida que se edita una geodatabase, las tablas delta aumentan de tamaño y crece el número de estados. Mientras más grandes sean las tablas y más estados tengan, más datos debe procesar ArcGIS cada vez que se visualiza o consulta una versión. Para mantener el rendimiento de una base de datos, el administrador de ArcSDE debe ejecutar de forma periódica el comando Comprimir para quitar los datos sin utilizar y después el comando Analizar para actualizar las estadísticas de la base de datos. Más información sobre la operación de compresión de la geodatabase
Registrar datos como versionados con la opción mover las ediciones a la base
Cuando registra datos que no participan en redes o topologías como versionados, puede especificar si desea que las modificaciones de la versión DEFAULT se muevan a las tablas base. Si especifica esta opción, los cambios siguen registrándose en las tablas delta. Sin embargo, al guardar, los cambios se mueven de las tablas delta a la tabla base, y no permanecen en las tablas delta.
La especificación de esta opción cuando registra los datos como versionados puede resultar útil, si las modificaciones que está realizando toman sólo unos minutos para completarse y si está conectado a una geodatabase versionada con una aplicación de terceros.
Las aplicaciones de terceros generalmente se configuran sólo para consultar la tabla base, no pueden ver las tablas delta. Si utiliza el versionado y no elige mover las modificaciones a la tabla base, estas aplicaciones no verán las modificaciones realizadas en otras versiones que no han sido conciliadas y publicadas en la versión DEFAULT. Tenga en cuenta que cuando edita versiones que no son la DEFAULT, los cambios se registran en las mismas tablas delta. Cuando guarda, los cambios permanecen en las tablas delta. Sin embargo, cuando se fusionan los cambios en la versión DEFAULT, éstos se mueven de las tablas delta a las tablas base. Cuando se fusionan los cambios a versiones que no son la DEFAULT se mantienen los cambios en las tablas delta, tal como si no hubiera especificado la opción de mover las modificaciones a la base.
Permisos y edición de una versión
El propietario de una versión (la persona que la crea) puede establecer permisos para una versión con el fin de restringir quienes pueden verla y editarla. Las opciones de permiso son privada (sólo el propietario puede ver y editar los datasets de la versión), protegida (cualquier usuario puede ver los datasets de la versión, pero sólo el propietario puede editarlos) y pública (cualquier usuario puede ver y editar los datasets, siempre que cuente con los permisos sobre los mismos).
Como puede ver en el siguiente cuadro de diálogo Administrador de versiones, la versión DEFAULT está protegida y las otras versiones son públicas.
Consulte Crear versiones y establecer permisos para obtener más información sobre permisos de versión.
Para editar los datos en una versión específica en ArcGIS, conéctese a una versión específica y agregue datos que han sido registrados como versionados en ArcMap.
También puede alternar las versiones a las que están conectados en ArcMap. Consulte Cambiar versiones en ArcMap para obtener más información.
Por defecto, todas las sesiones de edición en ArcMap son versionadas. Por lo tanto, si tiene datos versionados en su mapa, puede comenzar la edición apenas abra una sesión de edición. Para abrir una sesión de edición, haga clic en Iniciar la edición en la lista desplegable Editor de la barra de herramientas Editor.
Las modificaciones realizadas a cada versión se aplican sólo a esa versión. La excepción son los cambios de esquema. Cuando cambia el esquema en una versión, por ejemplo, si agrega un nuevo campo a la tabla, el cambio se aplica a todas las demás versiones.
Una vez terminada la edición, debe conciliar los cambios y publicar en la versión anterior.
Conciliar y publicar los cambios
La conciliación y la publicación integran los cambios a cualquier versión anterior de la versión en la que está trabajando, como la versión principal o DEFAULT. Cuando realiza la conciliación, se comparan los cambios en la versión que está editando con la versión a la que los quiere fusionar.
Cuando modifica datos en una versión, no se aplican bloqueos a los datos. Si dos editores trabajan en los mismos datos, ya sea en la misma o en diferentes versiones, se pueden producir conflictos. Ocurre un conflicto cuando una fila es diferente en las dos versiones que se están comparando. El proceso de conciliación muestra cada conflicto y permite elegir la representación de la fila que se desea conservar.
En la práctica, la edición de conflictos debería ser poco frecuente porque el volumen de modificaciones es pequeño en comparación con la cantidad de datos geográficos involucrados. En flujos de trabajo diseñados correctamente, el coste de conciliar conflictos es menor en comparación con el ahorro de no tener que bloquear o verificar entidades durante la transacción.
Una vez finalizada la conciliación, puede publicar los cambios. De esta manera, se aplican las modificaciones que realizó en la otra versión. Si ya no necesita la versión desde la que realizó la publicación, puede eliminarla. O bien, puede seguir editándola y volver a conciliar y publicar los cambios.
Basado en los privilegios asignados a las versiones del ejemplo QA/Project, un flujo de trabajo lógico de conciliación y publicación iría desde las versiones de proyecto a las versiones de QA y por último a la versión DEFAULT.
Versiones: Un ejemplo
Para ilustrar cómo se pueden utilizar las versiones, siga esta situación de un servicio hídrico municipal. El servicio hídrico tiene una geodatabase de entidades que representan el estado actual de todas las tuberías de agua, válvulas, bombas y otros componentes del sistema de agua. El servicio necesita agregar una extensión de línea nueva al sistema de agua.
El servicio crea una nueva versión desde la versión DEFAULT llamada proyecto de Extensión, para contener el diseño de la nueva extensión. Sin embargo, el personal del servicio no está seguro sobre si elegir un diseño de tubería de 16 o de 24 pulgadas para la nueva extensión. Entonces, desde la versión proyecto de Extensión, crean una versión para estudiar el diseño de 16 pulgadas y otra para estudiar el diseño de 24 pulgadas.
Finalmente, descubren que la tubería de 24 pulgadas servirá para la demanda de agua proyectada para 12 años más y que se justifica el coste mayor inicial de construcción. El diseño de 24 pulgadas queda aprobado, se verifica la precisión y se publica en la versión de proyecto de Extensión.
Algunos meses más tarde, se finaliza la construcción de la extensión de línea nueva. Para actualizar la versión publicada de la base de datos, se revisa la precisión de la versión de proyecto de Extensión, se concilia y se publica en la versión DEFAULT.