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.

Mantenimiento de datos sin versiones

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

Limitaciones

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.

Las versiones ayudan a administrar los cambios pasados, actuales y propuestos

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.

Una geodatabase puede tener muchas versiones

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.

Tablas delta
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:

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.

Mantener datos exclusivamente con aplicaciones ArcGIS

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:

Entre las aplicaciones potenciales se incluyen las siguientes:

Las versiones ofrecen muchas ventajas pero tienen algunas limitaciones:

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.

Mantener datos con ArcGIS y aplicaciones de terceros

Potenciales aplicaciones

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.

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.

Temas relacionados

4/23/2015