Disponible con una licencia Standard o Advanced.
El versionado tradicional permite que varios editores modifiquen los mismos datos en una geodatabase corporativa o de grupo de trabajo sin aplicar bloqueos o duplicar datos. Para ello, el versionado tradicional almacena ediciones en tablas laterales denominadas tablas delta.
Para editar las clases de entidad que participan en una topología, un dataset de red o una red geométrica, o para editar una estructura de parcelas, debe registrar los datos como versionados. Esto se debe a que cuando edita una entidad en una red, topología o estructura de parcelas, no todas las entidades se bloquean, lo que significa que otros editores pueden editar otra parte de la red, topología o estructura de parcela de manera tal que entra en conflicto con sus ediciones.
Los usuarios siempre acceden a una geodatabase corporativa o de grupo de trabajo a través de una versión. Cuando se conecta inicialmente a la geodatabase desde ArcGIS, se conecta a la versión Default. Para conectarse a una versión diferente y almacenar esa información con el archivo de conexión de base de datos (.sde), debe especificar la versión en las propiedades de la geodatabase.
¿Qué es una versión?
Una versión es una especie de vista de la geodatabase que compartimenta las ediciones. Cuando distintos usuarios se conectan a la misma versión, ven las ediciones realizadas en dicha versión. Los clientes que se conectan a otras versiones no verán los cambios hasta que los concilie y los publique en una versión anterior común.
La versión Default
La versión Default es la versión raíz y, por tanto, es anterior a todas las demás versiones.
A diferencia de otras versiones, la versión Default siempre existe y no se puede eliminar. En la mayoría de estrategias de flujo de trabajo, la versión Default es la que publica o utiliza como su sistema de registro acreditado, ya 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 publicar en ella los cambios realizados en otras versiones. También puede editar la versión Default directamente, como cualquier otra versión.
Crear otras versiones de la geodatabase
Para crear una versión tradicional en una geodatabase, se deben crear versiones secundarias o ramas de cualquier versión tradicional existente. La primera versión que crea es una versión secundaria de la versión Default. Cuando se crea esta versión secundaria, es idéntica a la versión Default. Con el paso del tiempo, las versiones se diferencian a medida que se realizan cambios en la versión Default y en la versión secundaria.
Una geodatabase puede tener muchas versiones tradicionales. En la siguiente captura de pantalla se muestra el cuadro de diálogo Administrador de versiones de ArcMap. Este ejemplo muestra las tres vistas del cuadro de diálogo, que representan la versión Default y las otras cuatro versiones, junto con la relación que hay entre las versiones. Las versiones Base y Cases son secundarias de la versión Default y las versiones Case1 y Case2 son secundarias de la versión Cases.
Crear versiones da la falsa sensación de que se está creando una copia de toda la geodatabase, pero no es así. Con independencia del número de versiones tradicionales 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.
Las versiones pueden ser editadas simultáneamente por varios usuarios.
Cómo funcionan las versiones tradicionales y las ediciones versionadas
Antes de que pueda comenzar a realizar ediciones versionadas en los datos de cualquier versión tradicional, es necesario registrar los datasets para que participen en el versionado tradicional.
Cuando se registra un dataset (una clase de entidad, un dataset de entidades o una tabla) para su uso en flujos de trabajo de versionado tradicional, se crean dos tablas delta: la tabla A (o de adiciones), que registra las inserciones y las actualizaciones, y la tabla D (o de eliminaciones), que almacena las 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 registrado para el versionado tradicional consta de la tabla original (denominada la tabla base o tabla de negocios) más los cambios de las tablas delta. La geodatabase hace un seguimiento de las versiones de la geodatabase a las que estuvo conectado cuando realizó las ediciones que completaron las tablas delta. Cuando realiza una consulta o visualiza un dataset en una versión de la geodatabase, 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 ediciones realizadas en una clase de entidad o una tabla específicas se registran en las mismas tablas delta, con independencia de la versión desde la que se realizaron dichas ediciones. Esto quiere decir que cualquier versión hace referencia sólo a un subconjunto de filas de las tres tablas. Entonces ¿cómo sabe 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. Cuanto 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 la base de datos, el administrador de la geodatabase debe ejecutar periódicamente el comando Comprimir para eliminar los datos no usados.
Mover las ediciones a la base
Si se especifica la opción para mover las ediciones a la base cuando se registran los datos para que participen en el versionado tradicional, los cambios se registran en las tablas delta. Sin embargo, al editar la versión Default y guardar los cambios, estos se mueven inmediatamente de las tablas delta a la tabla base, no permanecen en las tablas delta. Esto solo es así cuando se edita la versión Default. Las ediciones realizadas en las versiones descendientes no se mueven de inmediato a la tabla base.
La opción para mover las ediciones a la tabla base resulta útil si se cumplen las siguientes condiciones:
- Solo se tardan unos minutos en completar las ediciones.
- Los datos no forman parte de una red o una topología.
- Para acceder a una geodatabase que utiliza el versionado tradicional, se utiliza una aplicación de terceros.
La mayoría de aplicaciones de terceros solo consultan la tabla base; no pueden acceder a las tablas delta. Si utiliza el versionado tradicional y no elige mover las ediciones a la tabla base, estas aplicaciones no incluirán las ediciones realizadas en otras versiones que no hayan 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 sus ediciones en estas otras versiones, los cambios permanecen en las tablas delta. Sin embargo, cuando se fusionan los cambios en la versión Default a través de los procesos de conciliación y publicación, estos cambios se mueven de las tablas delta a las tablas base. Cuando se fusionan los cambios en versiones que no son la Default, los cambios se mantienen en las tablas delta, como si no se hubiera especificado que las ediciones se muevan a la base.
Permisos y ediciones de versiones
El propietario de la versión de la geodatabase (la persona que la crea) o el administrador de la geodatabase pueden otorgar permisos de acceso a una versión. Las opciones de permiso de acceso son las siguientes:
- Privada: solo el propietario de la versión o el administrador de la geodatabase pueden ver y editar los datasets de esa versión.
- Protegida: cualquier usuario puede ver los datos de la versión, pero solo el propietario o el administrador de la geodatabase pueden editarlos.
- Pública: cualquier usuario puede ver y editar los datos, siempre que se le haya otorgado privilegios de edición de las tablas y las clases de entidad.
El acceso a las versiones se establece cuando se crea la versión, pero también el propietario de la versión o el administrador de la geodatabase pueden cambiar posteriormente los permisos mediante el cuadro de diálogo Administrador de versiones. Consulte Crear versiones y establecer permisos de acceso y Propiedades de versiones para obtener más información.
Una vez que la tabla o clase de entidad está registrada como versionada y cuando usted crea una versión (en caso necesario), usted u otros editores pueden editar los datos. Para editar en ArcMap, conéctese a la versión de la geodatabase que desee editar y agregue al mapa la tabla o la clase de entidad versionada.
Por defecto, todas las sesiones de edición en ArcMap son sesiones de edición con control de versiones. Por lo tanto, si tiene datos versionados en su mapa, puede comenzar la edición apenas abra una sesión de edición.
Las ediciones que realice se aplican únicamente a la versión a la que esté conectado en el momento de la edición. Una vez terminada la edición, debe conciliar los cambios y publicarlos en una versión anterior.
Conciliar versiones y publicar cambios
Las operaciones de conciliación y publicación integran los cambios en cualquier versión anterior a la versión en la que se está trabajando, como la versión principal o la 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. Por ello, pueden surgir conflictos si hay varios editores trabajando en los mismos datos, ya sea en la misma versión o en otra. 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 ediciones 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 de edición.
Una vez finalizadas la conciliación y la resolución de conflictos, puede publicar los cambios. De esta manera, se aplican las ediciones que realizó en la versión anterior. Si ya no necesita la versión desde la que realizó la publicación (la versión secundaria), puede eliminarla. O bien, puede seguir editándola y volver a conciliar y publicar los cambios.
Versiones: un ejemplo
Para ilustrar cómo se pueden utilizar las versiones tradicionales, siga esta situación de un servicio hídrico municipal. Una compañía de suministro de agua tiene una geodatabase de entidades que representa el estado actual de todas las tuberías de agua, válvulas, bombas y otros componentes del sistema de agua. La compañía necesita agregar una nueva extensión de línea al sistema de agua.
Un editor crea una nueva versión a partir de la versión Default y asigna a la nueva versión el nombre Extension_project. Esta nueva versión contendrá las ediciones realizadas para 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 Extension_project, crean una versión para estudiar el diseño de 16 pulgadas y otra para estudiar el diseño de 24 pulgadas.
Finalmente, el personal decide que la tubería de 24 pulgadas responderá a la demanda de agua proyectada para 12 años más y que se justifica el mayor coste inicial de construcción. El diseño de 24 pulgadas se aprueba, se comprueba para confirmar su precisión y se concilia y publica en la versión Extension_project.
La construcción de la nueva extensión de la línea de agua se completa pocos meses después. Para actualizar la versión publicada de la geodatabase, la versión Extension_project se revisa para comprobar su precisión, se concilia y se publica en la versión Default.
