Estrategias de mantenimiento de datos

Las transacciones contra datos geográficos pueden variar ampliamente en duración y complejidad. La geodatabase admite dos estrategias de mantenimiento de datos, el mantenimiento con y sin versiones, que equilibran las necesidades de los usuarios y de las aplicaciones de realizar transacciones cortas y largas sobre datos simples o complejos.

Cada estrategia se puede aplicar por clases de entidad o por tablas, de modo que es posible utilizar ambas en la misma geodatabase.

La manera edita los datos en cada una de estas estrategias es similar: se edita dentro de una sesión de edición y se trabaja con muchas de las mismas herramientas. Lo que varía es cómo se mantienen las fuentes de datos subyacentes. También hay algunas diferencias en qué datos se puede editar y en el tipo de flujos de trabajo que se puede realizar. En este tema se explican estas diferencias.

Mantenimiento de datos sin versiones

Esta estrategia no implica trabajar con varias versiones; simplemente, utiliza el modelo de transacciones del DBMS subyacente. Las ediciones sin control de versiones equivalen a transacciones estándar de base de datos.

Para editar datos, debe habilitar la edición sin control de versiones en el cuadro de diálogo Opciones del Editor; iniciar una sesión de edición, después realizar las operaciones requeridas, como agregar, eliminar o mover entidades y actualizar atributos. La primera edición de la sesión de edición inicia la transacción. Al guardar, las operaciones de edición individuales realizadas se confirman en la base de datos como una transacción única. Después de guardar, la siguiente edición que se realiza comienza una nueva transacción. Puede guardar a la vez tantas operaciones como necesite durante la sesión de edición, aunque es recomendable guardar con frecuencia para evitar bloquear los datos que se está editando y bloquear a otros usuarios el acceso o la edición de los datos. Una vez guardados, los cambios están disponibles para todos los otros demás usuarios y aplicaciones que tengan acceso a los datos.

Si no desea confirmar las ediciones en la base de datos, detenga la edición sin guardar. Todas las ediciones de esa transacción, que son todas las ediciones desde la última vez que se guardó o si aún no se ha guardado, todas las ediciones desde que se inició la sesión de edición, se eliminarán y no se confirmarán en la base de datos.

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í. 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 necesita administrar el historial ni varias representaciones de los datos con versiones. Puesto que esta estrategia no requiere 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.

Potenciales aplicaciones

• Integrar fácilmente datos geográficos en aplicaciones existentes permitiendo que aplicaciones de terceros (no creadas con software Esri) lean y modifiquen los mismos datos obtenidos a los que tienen acceso las aplicaciones ArcGIS.
• 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

• Solo se puede editar datos simples: puntos, líneas, polígonos, anotaciones y relaciones. No se pueden editar clases de entidad que participen en una topología, dataset de red, red geométrica o un terreno.
• Dado que la fuente de datos se edita directamente, no se puede deshacer ni rehacer una edición individual si se comete un error. La única manera de deshacer las ediciones es anular todas las ediciones realizadas desde la última vez que se guardó deteniendo la sesión de edición sin guardar.
• Cada transacción se debe iniciar y finalizar dentro de una sesión de edición única. Una sesión de edición solo puede durar un tiempo limitado; habitualmente, se debe finalizar después de unas pocas horas, por ejemplo, para poder cerrar la sesión al final del día.
• 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, a continuación, otro usuario actualiza la misma entidad y la guarda, la última actualización realizada sobrescribe la primera.

  Para obtener más información, vea Un recorrido rápido por el trabajo con datos no versionados.

Mantenimiento de datos con versiones

La geodatabase extiende la transacción estándar del DBMS permitiendo varios que estados simultáneos de las bases de datos, conocidos como versiones, existan al mismo tiempo. 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. Las versiones permiten administrar cambios pasados, presentes y propuestos en los datos, todo en la misma geodatabase.

Para administrar los cambios pasados, debe guardar los cambios de los datos en tablas de archivado separadas. Puede mantener estos cambios tanto tiempo como necesite, permitiendo ver a los usuarios qué aspecto tenía la base de datos en algún momento anterior. Esta función se conoce como archivado y está integrada en ArcGIS; no se requiere ningún desarrollo. Al habilitar esta función, los cambios realizados en la versión DEFAULT, utilizada normalmente como la versión publicada de la base de datos, se archivan automáticamente.

Para administrar los cambios actuales, los editores pueden modificar su versión privada de la geodatabase para que otros usuarios no puedan ver el trabajo incompleto. Al editar una versión de los datos, no se aplican bloqueos. Por consiguiente, se maximiza la simultaneidad, porque otros usuarios pueden leer y editar los mismos datos que se están modificando; no se bloquean entre sí el acceso a la base de datos. Cuando un editor ha finalizado sus cambios, puede integrarlos en la versión publicada.

Para administrar los cambios propuestos, puede desarrollar un escenario o realizar un análisis de hipótesis dentro de una versión de la base de datos. El escenario se puede administrar como una unidad única de cambio, que abarque varias sesiones de edición y días, semanas o meses. Puede agregar entidades propuestas libremente, realizar análisis geográficos y generar mapas, todo sin que afecte a la base de datos a la que otros usuarios están obteniendo acceso. Una vez completados y aprobados los cambios, puede integrarlos en el resto de la geodatabase.

No hay ningún límite al número de versiones que una geodatabase puede tener. Las versiones se pueden organizar en varias configuraciones y admiten una amplia variedad de flujos de trabajo. Sin embargo, para simplificar y por razones de administración de la geodatabase, una práctica recomendada es mantener un árbol de versiones plano o hacer que varios editores editen simultáneamente la versión DEFAULT.

Para admitir las funciones de control de versiones, ArcGIS no duplica los datos. En su lugar, deja cada clase de entidad y cada tabla en su formato original, pero registra cualquier cambio en tablas conocida como tablas delta. Las tablas delta constan de una tabla de adiciones para las inserciones y actualizaciones y una tabla de borrados para los borrados. Cada vez que se actualiza o se elimina un registro en cualquier versión, se agregan filas a una o ambas de estas tablas. Al consultar o mostrar una clase de entidad o una tabla en una versión, ArcGIS ensambla las filas pertinentes de las tablas delta y la tabla original para presentar una vista sin fisuras de los datos.

Editar una clase de entidad versionada

Las tablas con control de versiones requieren el mantenimiento periódico por un administrador de bases de datos. A medida que se edita una geodatabase a lo largo del tiempo, las tablas delta aumentan de tamaño, lo que afecta al rendimiento de la visualización y de las consultas. Para mantener el rendimiento, el administrador de bases de datos puede comprimir periódicamente una base de datos versionada, una operación que quita información redundante de las tablas delta. Las bases de datos con control de versiones se deben comprimir siempre que haya finalizado un periodo de elevada actividad en la base de datos, por ejemplo al final de un turno o después de cargar nuevos datos. El proceso de compresión se puede ejecutar mientras hay otros usuarios conectados y utilizando la base de datos.

ArcGIS puede administrar las tablas delta subyacentes que dan soporte a las versiones de una de dos maneras:

• Guardando todos los cambios, sin tener en cuenta qué versión, en las tablas delta
• Guardando todas las ediciones de las versiones diferentes a DEFAULT en las tablas delta, pero guardando todas las ediciones de la versión DEFAULT en las tablas básicas

La primera manera está diseñada para dar soporte en exclusiva a las aplicaciones ArcGIS. La segunda manera es útil si se necesita mantener los datos tanto con ArcGIS como con aplicaciones de terceros.

Mantener datos exclusivamente con aplicaciones ArcGIS

En un entorno donde los datos se mantengan exclusivamente con aplicaciones ArcGIS, la mejor manera de administrar las versiones consiste en guardar todos los cambios en las tablas delta. Esto permite aprovechar al máximo las funciones de la geodatabase, incluido el archivado, la replicación y la capacidad de editar redes geométricas y topologías.

Para habilitar este comportamiento en la clase de entidad o la tabla, registre los datos como versionados sin la opción de trasladar las ediciones a la tabla base. Siempre que se guardan cambios en un dataset registrado de esta manera, los cambios se guardan en las tablas delta. Con este enfoque, el acceso directo a las tablas originales no es posible; los usuarios siempre tienen acceso a una versión de los datos.

En el siguiente ejemplo se muestra una configuración en la que los datos se administran completamente a través del uso de versiones. Los editores exigen el uso de ArcGIS u otra aplicación Esri para hacer cambios en los datos. Las aplicaciones no SIG pueden tener acceso a la versión publicada o a cualquier otra versión, siempre que se adapten con vistas con control de versiones.

Debido a las tablas delta y a otras tablas necesarias para el soporte de las versiones, las aplicaciones escritas para tener acceso directamente a los datos del DBMS sin el uso de bibliotecas de software de Esri no tienen la capacidad inherente para leer versiones. ArcGIS proporciona vistas con control de versiones que permiten a estas aplicaciones leer una versión determinada con SQL. Las vistas con control de versiones pueden tener acceso tanto a tablas como a clases de entidad. El acceso a los atributos geométricos de las clases de entidad mediante una vista con control de versiones requiere el uso de tipos de geometría de SQL, que son totalmente compatibles con ArcGIS.

Este enfoque ofrece estas ventajas:

• Deshacer o rehacer cambios mientras se está editando.
• La ausencia de bloqueos permite la introducción de conflictos de edición. ArcGIS ofrece la capacidad de detectar con facilidad, conciliar y resolver conflictos.
• Archivar cambios automáticamente y consultar qué aspecto tenía la base de datos en un momento determinado.
• Tiene la capacidad de editar entidades en una red geométrica, dataset de red o una topología.
• Puede hacer que dos o más oficinas dispersas geográficamente trabajen simultáneamente en copias sincronizadas de una geodatabase. Las oficinas necesitan enviarse sus cambios entre sí periódicamente de modo que cada una de ellas tenga una vista actualizada de la geodatabase. ArcGIS hace referencia a esta función como replicación de geodatabase.
• Los usuarios móviles, desconectados de la red, tienen la capacidad de editar una parte de la geodatabase en un equipo portátil o un dispositivo de mano sobre el terreno. Cuando los usuarios vuelven a la oficina, integran sus cambios en la geodatabase. ArcGIS también hace referencia a esta función como replicación de geodatabase.

Entre las aplicaciones potenciales se incluyen las siguientes:

• Proyectos que requieren el almacenamiento y la consulta de los datos almacenados.
• Proyectos que requieren un análisis de hipótesis: Crear un nuevo diseño en una versión separadas. 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 garantía 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 podría tener distintas fases de construcción subdivididas en secciones este y oeste o por actividades de construcción, tales 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, 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 con requisitos de auditoria administrativa: mantener un archivo persistente para admitir la consulta de los cambios.
• Proyectos con oficinas geográficamente distantes que necesitan trabajar simultáneamente en la misma geodatabase: Requieren la capacidad de sincronizar periódicamente sus copias de los datos.
• Proyectos que requieren personal de mantenimiento sobre el terreno para actualizar los datos con equipos portátiles.
• Proyectos que exigen a los programadores de software que prueben instrucciones SQL y lógica de aplicación en su propia versión privada de la base de datos.

Las versiones ofrecen muchas ventajas pero tienen algunas limitaciones:

• Las aplicaciones de terceros deben estar adaptadas con vistas con control de versiones para poder leer los datos.
• Hay restricciones sobre el uso del comportamiento activo del DBMS, tales como las restricciones únicas y los desencadenadores, cuando se trabaja con datos versionados. Esto se debe a que las inserciones y las actualizaciones crean nuevas filas en las tablas delta en lugar de inserciones y actualizaciones en la tabla básica.

Mantener datos con ArcGIS y otras aplicaciones

En un entorno informático heterogéneo donde haya varias aplicaciones departamentales diferentes que tengan acceso a la misma base de datos, es posible que sea necesario admitir tanto aplicaciones ArcGIS como aplicaciones de terceros. Un ejemplo de esto es si se tiene un departamento que mantiene los datos geográficos en la base de datos con ArcGIS y otro departamento que mantiene los registros del cliente en la misma base de datos con una aplicación personalizada. La aplicación personalizada necesita aplicar restricciones y desencadenadores del DBMS a medida que se realizan las transacciones y no puede reconocer tablas versionadas. Al mismo tiempo, el otro departamento necesita editar los datos geográficos en su propia versión aislada, sin compartir las ediciones departamentales hasta que se completen y se aprueben.

Con estos requisitos en mente, ArcGIS permite realizar ediciones con control de versiones en una clase de entidad o una tabla, conservando la capacidad de compartir las ediciones con otras aplicaciones. Para habilitar esta capacidad en la clase de entidad o la tabla, registre los datos como versionados con la opción de trasladar las ediciones a la tabla base. Esta opción está disponible en el cuadro de diálogo del proceso de registro.

Cuando edita datos registrados de esta manera, las versiones funcionan de la misma manera según se describe en el enfoque anterior: los cambios se guardan en las tablas delta. La excepción es la versión DEFAULT. Siempre que se guardan las ediciones en la versión DEFAULT, ya sea editándola directamente o combinando cambios de otra versión, las ediciones se guardan en las tablas base. Las ediciones no permanecen en tablas delta, como es el caso cuando se desactiva la opción mover ediciones a la base .

Esto permite que todas las aplicaciones trabajen sobre la misma base de datos.

• Las aplicaciones escritas sin el software de Esri pueden continuar obteniendo acceso y modificando los datos con transacciones estándar, aunque se estén editando al mismo tiempo en la versión DEFAULT o en otra versión.
• Siempre que ArcGIS o una aplicación escrita con ArcObjects guarda cambios en la versión DEFAULT o combina cambios en la versión DEFAULT, se aplican los índices únicos, las restricciones y los desencadenadores definidos en los datos con el DBMS.
• Cuando una aplicación modifica los datos, los cambios quedan inmediatamente a disposición de cualquier otra aplicación que tenga acceso a los datos. Dado que los cambios de DEFAULT no se almacenan en tablas delta, no hay ninguna necesidad de adaptar aplicaciones de terceros con vistas con control de versiones para que puedan leer estas tablas.

Potenciales aplicaciones

• Proyectos que requieren la edición de los datos por ArcGIS y otras aplicaciones: configurar un flujo de trabajo donde las otras aplicaciones obtienen acceso y modifican datos no espaciales en la base de datos con transacciones estándar del DBMS, mientras otros usuarios trabajan en versiones concretas de los mismos datos, realizando transacciones de duración relativamente larga aisladas de todos los demás usuarios de la base de datos hasta que se envían a la versión DEFAULT.
• Las mismas aplicaciones potenciales que cuando el mantenimiento de los datos se realiza exclusivamente con aplicaciones ArcGIS
  • Proyectos que requieren un análisis de hipótesis
  • Proyectos con requisitos de control de calidad concretos
  • Proyectos que dividen el trabajo en unidades funcionales o geográficas
  • Proyectos que evolucionan a través de un grupo prescrito o regulado de etapas
  • Proyectos que requieren personal de mantenimiento para actualizar los datos con equipos portátiles.
  • Proyectos que exigen a los programadores de software que prueben instrucciones y lógica de aplicación SQL

Limitaciones

Al registrar un dataset como control de versiones con la opción Mover ediciones a la base, tiene limitada la forma de trabajar con versiones.

• Solo se puede editar datos simples: puntos, líneas, polígonos, anotaciones y relaciones. No puede editar una clase de entidad en una topología, dataset de red, red geométrica o un terreno.
• No puede archivar cambios para el dataset.
• No puede replicar el dataset.
• Al editar la versión DEFAULT o publica una versión a DEFAULT, no tiene la capacidad de resolver conflictos, así que es posible sobrescribir las ediciones de otro usuario.

Para obtener más información sobre las versiones y las funciones que proporcionan, vea Información sobre el control de versiones y Escenarios de versión.