Administración de transacciones de geodatabases

Las transacciones son los paquetes de trabajo que realizan los cambios en las bases de datos. Las bases de datos de los sistemas de información geográfica (SIG), como otras aplicaciones de base de datos, deben admitir transacciones de actualización que hagan cumplir la integridad de datos y el comportamiento de la aplicación. En muchos casos, los usuarios pueden utilizar el marco de transacciones del sistema de administración de bases de datos (DBMS) para administrar las ediciones y actualizaciones en las geodatabases.

Sin embargo, los usuarios de SIG tienen también universalmente algunos requisitos transaccionales especializados. Por ejemplo:

• A menudo, varios registros se actualizan a la vez como una única transacción.
• Numerosas transacciones deben abarcar períodos largos de tiempo (a veces días y meses, no solo segundos o minutos).

Además, los usuarios necesitan poder deshacer y rehacer los cambios. Las sesiones de edición pueden abarcar varias horas o incluso días. A menudo, las ediciones se deben realizar en un sistema que está desconectado de la base de datos central, compartida.

Dado que los procesos de flujo de trabajo de SIG pueden abarcar días o meses, la base de datos SIG debe permanecer continuamente disponible para las operaciones cotidianas, donde cada usuario podría tener una vista o un estado personal de la base de datos SIG compartida. En una base de datos multiusuario, las transacciones SIG se deben administrar en el marco de transacciones cortas del DBMS. La tecnología ArcSDE representa un papel clave durante estas operaciones administrando las complejas transacciones de alto nivel del SIG en el marco simple de transacciones del DBMS.

Los usuarios de SIG tienen muchos casos en los que son críticos los flujos de trabajo de transacciones largas. En la mayoría de los casos, son posibles mediante el uso de un DBMS multiusuario y ArcSDE para administrar las actualizaciones de la base de datos SIG central utilizando control de versiones, sobre el que puede leer más a continuación.

Los siguientes son ejemplos de flujos de trabajo de compilación de datos SIG que requieren un modelo de transacciones basado en versiones:

• Varias sesiones de edición: una única actualización de la base de datos SIG puede requerir numerosos cambios que abarcan varias sesiones de edición que se producen a lo largo de días o semanas.
• Edición multiusuario: varios editores necesitan actualizar con frecuencia, de manera simultánea, las mismas entidades integradas espacialmente. Cada usuario necesita trabajar con un estado personalizado de la base de datos, viendo actualizaciones individuales y omitiendo las actualizaciones de otros editores. Finalmente, cada usuario necesita enviar y conciliar actualizaciones con los demás editores para identificar y resolver los conflictos.
• Transacciones checkout/check-in: con frecuencia es necesario desproteger una parte de una base de datos para un área o un distrito determinado para un PC y actualizar esa información en una sesión desconectada que podría durar días o semanas o, cada vez más, para llevarla sobre el terreno para su edición y actualización móvil. Esas actualizaciones se deben enviar a la base de datos principal.
• Historial: a veces es ventajoso mantener una versión histórica de cada entidad en una base de datos SIG, incluso una vez actualizada esa versión en particular, para mantener una copia de las entidades retiradas y modificadas en un archivo, o para realizar el seguimiento del historial de una entidad individual; por ejemplo, el linaje de parcela o las propiedades de actualización de entidad en una base de datos de cartografía nacional.
• Transferencia de actualizaciones limitadas a modificaciones: las bases de datos empresariales y las infraestructuras de datos espaciales en las que la información se comparte entre varias organizaciones son esfuerzos colaborativos que exigen compartir actualizaciones a través de Internet en un esquema de lenguaje de marcado extensible (XML) bien definido para compartir actualizaciones limitadas a modificaciones entre las bases de datos.
• Réplicas distribuidas de bases de datos geográficos: una base de datos regional puede ser una copia parcial de una base de datos SIG corporativa principal para un región geográfica determinada. Periódicamente, las dos bases de datos se deben sincronizar intercambiando actualizaciones.
• Replicación débilmente acoplada entre DBMS: a menudo, los datos SIG se deben sincronizar entre una serie de copias de la bases de datos (réplicas), donde cada sitio realiza sus propias actualizaciones en su base de datos local. A menudo, las bases de datos solo se conectan periódicamente a través de Web. De manera programada, se debe transferir las actualizaciones de cada réplica de la base de datos a las demás, y su contenido se debe sincronizar. Muchas veces, los DBMS son diferentes: por ejemplo, replicando datasets entre Microsoft SQL Server, Oracle e IBM DB2.

El modelo de transacciones de geodatabases: control de versiones

El mecanismo de geodatabases para administrar éstos y otros mucho flujos de trabajo críticos de SIG consiste en mantener varios estados en la geodatabase y, lo que es más importante, hacerlo garantizando la integridad de la información geográfica, las reglas y el comportamiento. Esta capacidad para administrar, trabajar con y ver varios estados se basa en el control de versiones. Como el nombre implica, el control de versiones registra explícitamente versiones de entidades individuales y objetos a medida que se modifican, se agregan y se retiran a través de varios estados. Cada versión registra explícitamente cada estado de una entidad u objeto como una fila en una tabla, junto con información importante de la transacción. Cualquier número de usuarios pueden trabajar simultáneamente con varias versiones y administrarlas.

Las versiones permiten registrar todas las transacciones como una serie de cambios en la base de datos a través del tiempo. Esto significa que varios usuarios pueden trabajar con varias vistas o estados de la geodatabase. El objetivo es el acceso abierto, de alto rendimiento, multiusuario. Por ejemplo, el sistema debe ser rápido y dar soporte de manera productiva al uso de datasets que contienen centenares de millones de registros a los que acceden miles de usuarios simultáneos.

El modelo de transacción de geodatabases basado en versiones es relativamente simple: las actualizaciones se registran en tablas de cambios.

Las versiones registran explícitamente los estados de los objetos de una geodatabase en dos tablas delta:

• La tabla de adiciones
• La tabla de eliminaciones

Se utilizan consultas simples para ver y trabajar con cualquier estado deseado de la geodatabase, por ejemplo, para ver el estado de la base de datos en un momento en el tiempo o para ver la versión actual de un usuario determinado con sus ediciones.

ArcSDE desempeña un papel crítico en las aplicaciones de geodatabase con control de versiones, y se utiliza para administrar las transacciones largas en cada DBMS aprovechando su marco de transacciones cortas, así como para trabajar con DBMS diferentes.

En el ejemplo de la tabla de versiones, una parcela (número 45) se actualiza para convertirse en la parcela número 47. Utilizando el control de versiones, la parcela original se guarda en la tabla de eliminaciones y la nueva parcela se guarda en la tabla de adiciones. Otras metatablas registran información de versión sobre la transacción, tal como la hora y la secuencia de cada actualización, el nombre de la versión y el ID de estado de cada actualización. Cada versión tiene también su propia seguridad y sus propios privilegios de acceso.

Esto permite que la mayoría de los usuarios trabajen con la versión predeterminada mientras varios editores están realizando actualizaciones simultáneamente en sus propias versiones de la base de datos a lo largo del tiempo.

Se pueden realizar numerosas actualizaciones en cada versión, y los usuarios se conectan y trabajan con la versión de actualización cuando realizan ediciones adicionales de los datos. Cuando los usuarios están listos para compartir las actualizaciones con el resto de la empresa, se realiza una operación de conciliación y publicación para confirmar las ediciones que contiene la versión de actualización en la versión principal (predeterminada). Se utiliza un proceso de resolución para identificar y conciliar los conflictos potenciales durante este proceso.

Para obtener más información sobre la versión, vea Información sobre el control de versiones.