Los flujos de trabajo que utilizan datos geográficos pueden variar ampliamente en su duración y complejidad. Las geodatabases corporativas admiten dos estrategias de administración de datos que equilibran las necesidades de flujo de trabajo de los usuarios y las aplicaciones para realizar transacciones cortas y largas en los datos: administración de datos con versiones y sin versiones. El planteamiento sin control de versiones administra la edición de transacciones cortas y el versionado se adapta a las transacciones largas.
Ambas estrategias, con o sin versiones, se puede aplicar por clases de entidad o por tablas, de modo que es posible utilizar ambas en la misma geodatabase corporativa. La administración de datos versionados se amplía además a tres opciones: versionado en rama, versionado tradicional y versionado con la opción de mover las ediciones a la base. La estrategia que elija dependerá de las capacidades que desee en su SIG, dado que existen algunas diferencias en cuanto a qué datos puede editar y los tipos de flujos de trabajo que puede realizar.
Consulte la tabla que aparece a continuación para obtener un resumen de las opciones de flujo de trabajo de edición admitidas en una geodatabase corporativa:
| Tipos de datos | Versionado en rama | Versionado tradicional | Versionado tradicional (mover las ediciones a la base) | Edición no versionada |
|---|---|---|---|---|
Clase de entidad |  | | | |
Tabla | | | | |
Annotation | | | | |
Dimensión | | | | |
Clase de relación | | | | |
Realizar trazado de red** | ** | |||
Red de servicios | | |||
Estructura de parcela | | |||
Topología | | | ||
Dataset de red | | |||
Dataset de terreno | |
**Solo compatible en una geodatabase de archivos
Administración de datos sin versionado
Esta estrategia no implica trabajar con varias versiones de sus datos; utiliza el modelo de transacciones del DBMS subyacente. Las ediciones sin control de versiones equivalen a transacciones cortas estándar de base de datos.
Para editar los datos, haga clic en la pestaña Editar de la cinta y lleve a cabo las operaciones requeridas, como agregar, eliminar o mover entidades y actualizar atributos. La primera edición realizada en la sesión de edición inicia la transacción, y las operaciones de edición efectuadas se confirman en la base de datos como una transacción única. Cuando se editan datos no versionados en ArcGIS Pro, cada transacción se confirma automáticamente en la base de datos sin necesidad de guardar las ediciones. Los cambios realizados están disponibles para todos los demás usuarios y aplicaciones que acceden a los datos cuando la transacción se ha completado.
Cuando se edita, se aplican los índices únicos, las restricciones y los desencadenadores definidos en los datos con el DBMS. Se aplica el mismo comportamiento de bloqueo que si se estuviera realizando transacciones en los datos directamente con el DBMS. Por consiguiente, existe la posibilidad de que usuarios o aplicaciones que obtengan acceso o modifiquen los mismos datos se bloqueen entre sí.
Nota:
Cuando utilice la edición sin control de versiones en un entorno de edición multiusuario, debe entender cómo funcionan los niveles de aislamiento y de bloqueo en el DBMS y, si es necesario, establecer el nivel de aislamiento correcto en el DBMS antes de empezar a trabajar con ArcGIS.
Esta estrategia es adecuada para entidades simples para las que no se necesite trabajar con varias representaciones de los datos dentro de las versiones. Puesto que esta estrategia no usa versiones, también es útil si se necesita que tanto aplicaciones SIG como no SIG compartan el acceso a una base de datos común.
Ventajas
Entre las ventajas de la administración de datos no versionados están las siguientes:
- Integre los datos geográficos de en aplicaciones existentes permitiendo que aplicaciones de terceros (no creadas con software Esri) lean y modifiquen los mismos datos a los que tienen acceso las aplicaciones de ArcGIS. Por ejemplo, los partners de negocio de Esri crean con frecuencia complementos y aplicaciones de extensión que requieren un acceso abierto para actualizar los datos almacenados en el DBMS subyacente.
- Administrar proyectos con flujos de trabajo y ediciones simples. Si las transacciones son siempre simples y de corta duración, puede modificar los datos directamente sin necesidad de combinar cambios y administrar periódicamente las tablas adicionales requeridas para las versiones.
Limitaciones
Entre las limitaciones de la administración de datos no versionados están las siguientes:
- Solo es posible editar entidades simples: puntos, líneas, polígonos, anotaciones y relaciones. No es posible editar clases de entidad que participen en una topología, red de servicios, estructura de parcelas u otros datasets con funcionalidades avanzadas.
- Dado que la fuente de datos se edita directamente, no se puede deshacer ni rehacer una edición individual si se comete un error.
- Con la edición sin control de versiones no hay ninguna detección de conflictos. Si un usuario actualiza una entidad y la guarda y otro usuario actualiza la misma entidad y la guarda, la última actualización realizada sobrescribe la primera.
- En los escenarios de edición multiusuario, mientras un usuario edita una entidad, el DBMS aplica bloqueos que impiden a otros editores hacer ediciones simultáneas en la misma entidad.
Administración de datos con versionado
La geodatabase corporativa utiliza el versionado para satisfacer las necesidades de los escenarios de edición multiusuario y las transacciones largas. La geodatabase extiende el modelo de transacción estándar del DBMS permitiendo varios que estados simultáneos de las bases de datos, conocidos como versiones, existan al mismo tiempo. Así, varios usuarios pueden editar los mismos datos en una geodatabase a la vez, sin aplicar bloqueos ni duplicar datos.
Los editores pueden trabajar dentro de su propia versión personal de la geodatabase, de forma que los otros usuarios no ven el trabajo incompleto ni los editores se impiden uno a otro acceder a los datos.
Cada versión puede representar trabajo en curso, tal como un diseño o un grupo de órdenes de trabajo, trabajo que puede abarcar varias conexiones a la base de datos y extenderse sobre un período de semanas o meses, si es necesario. Una vez que un editor ha completado su trabajo, puede integrar sus cambios de nuevo en la versión principal.
Aquí ofrecemos algunos ejemplos de flujos de trabajo que utilizan versiones:
- Proyectos que requieren un análisis de hipótesis: cree un diseño en una versión separada. Si se aprueba el diseño, puede combinarse con el resto de la base de datos. Si no se aprueba, puede descartarlo.
- Proyectos con requisitos de control de calidad concretos: recopilar cambios de datos, tales como importaciones masivas, en una versión aislada de otros usuarios de la base de datos. Pruebe y apruebe los cambios antes de combinarlos con la versión publicada de la base de datos.
- Proyectos que dividen el trabajo en unidades funcionales o geográficas: por ejemplo, un proyecto para diseñar y construir un nuevo centro comercial puede tener distintas fases de construcción subdivididas en secciones este y oeste o en actividades de construcción, como edificación, instalación de servicios o paisajismo. Cada unidad de trabajo se emprende en una versión separada; cuando se completa cada versión, se envía a la versión publicada de la base de datos.
- Proyectos que evolucionan a través de un grupo prescrito o regulado de etapas, en el que cada etapa requiere aprobación de ingeniería, administrativa o legal antes de poder considerarla completada: los flujos de trabajo para estos proyectos pueden administrar cada etapa como una versión separada, tal como un diseño inicial o una versión propuesta, una versión aprobada y una versión para la fase de construcción. A medida que un proyecto avanza a través de diversos hitos, 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.
- Proyectos que requieren personal de mantenimiento sobre el terreno para actualizar los datos con dispositivos móviles: los editores de campo pueden trabajar dentro de sus propias versiones y fusionar los cambios con las actualizaciones realizadas por los editores que trabajan desde la oficina.
Todas las geodatabases corporativas tienen una versión denominada Predeterminada. 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 publicar en ella los cambios realizados en otras versiones. También puede editar la versión predeterminada directamente, como con cualquier otra versión. La versión Default es la versión raíz y, por tanto, es anterior a todas las demás versiones.
El versionado aporta flexibilidad y escalabilidad a sus estrategias de administración de datos. Existen dos tipos de versionado disponible, cada uno dedicado a opciones particulares de flujos de trabajo e implementación:
Consulte escenarios de versiones en rama y escenarios de versiones tradicionales para conocer configuraciones que ilustran cómo puede aplicarse la tecnología de versionado dentro de una organización.