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 versiones administra la edición de transacciones cortas y el con versiones 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 viene determinada por las capacidades que desee en su SIG, dado que existen diferencias en cuanto a los datos que puede editar y los tipos de flujos de trabajo que puede realizar.
En la tabla siguiente se ofrece un resumen de las opciones de flujo de trabajo de edición admitidas con estos tipos de datasets en una geodatabase corporativa:
| Tipos de dataset | Versionado en rama | Versionado tradicional | Versionado tradicional (mover las ediciones a la base) | Edición no versionada |
|---|---|---|---|---|
Clase de entidad |  | | | |
Tabla | | | | |
Anotación | | | | |
Dimensión | | | | |
Clase de relación | | | | |
Clase de entidad Objeto 3D | | |||
Red de trazado | | |||
Red de servicios | | |||
Estructura de parcela | | |||
Topología | | | ||
Dataset de red | | |||
Dataset de terreno | |
Nota:
Además de los tipos de datasets enumerados en la tabla anterior, existen otras capacidades de geodatabase, como la replicación, el archivado y las reglas de atributos, que solo funcionan con datasets de registro de geodatabase específicos. Consulte estos temas de capacidades individuales para obtener más información.
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 enArcGIS AllSource, cada transacción se confirma automáticamente en la base de datos, por lo que no es necesario que guarde 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 aplican los mismos comportamientos de bloqueo que si se estuvieran realizando transacciones en los datos directamente con el DBMS. Existe la posibilidad de que usuarios o aplicaciones que tengan acceso o modifiquen los mismos datos puedan bloquearse 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 (las que no incluyen 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 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 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.
- Con la edición sin control de versiones no hay ninguna detección de conflictos. Si un usuario actualiza una entidad y guarda el cambio y otro usuario actualiza la misma entidad y guarda el cambio que realiza, 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 adecuarse a 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 en 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, 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.
A continuación se muestran 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 en sus propias versiones y fusionar los cambios con las actualizaciones realizadas por los editores en la oficina.
Todas las geodatabases corporativas tienen una versión denominada Predeterminada. A diferencia de otras versiones, la versión predeterminada 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 predeterminada 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 predeterminada es la versión raíz y es anterior a todas las demás versiones.
El versionado aporta flexibilidad y escalabilidad a las estrategias de administración de datos. Existen dos tipos de versionado disponible, cada uno aplicable 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 en una organización.