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 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 editores 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, de modo que cada persona que se conecta a los datos pueda 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 sistema de administración de bases de datos. La geodatabase desempeña un papel clave durante estas operaciones, ya que administra las transacciones SIG complejas de alto nivel en el marco de transacciones simples del sistema de administración de bases de datos.
En muchos casos, los flujos de trabajo de transacciones largas son esenciales para un SIG. En la mayoría de los casos, conllevan el uso de una geodatabase corporativa y ArcGIS para administrar las actualizaciones de la base de datos SIG central utilizando el 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 a lo largo de varios días o semanas.
- Edición multiusuario: varios editores necesitan actualizar con frecuencia, de manera simultánea, las mismas entidades integradas espacialmente. Cada editor necesita trabajar con un estado de datos personalizado que le permita ver sus actualizaciones y pasar por alto las actualizaciones de otros editores. Posteriormente, cada editor necesitará publicar y conciliar actualizaciones con los demás editores para identificar y resolver los conflictos.
- Transacciones checkout/check-in: con frecuencia es necesario aplicar un check-out a una parte de una geodatabase de 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, llevarla al campo 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 conservar una versión histórica de cada entidad en una geodatabase, incluso después de 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 representación cartográfica nacional.
- Transferencia de actualizaciones limitadas a modificaciones: las geodatabases corporativas 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 las modificaciones entre las geodatabases.
- Réplicas distribuidas de bases de datos geográficas: una geodatabase regional puede ser una copia parcial de una geodatabase corporativa principal para un región geográfica determinada. Periódicamente, las dos geodatabases se deben sincronizar intercambiando actualizaciones.
- Replicación débilmente acoplada entre sistemas de administración de bases de datos: a menudo, los datos SIG se deben sincronizar entre una serie de copias de la geodatabase (réplicas), donde cada sitio realiza sus propias actualizaciones en su geodatabase local. A menudo, las geodatabases solo se conectan periódicamente a través de la Web. De manera programada, se deben transferir las actualizaciones de cada réplica de la geodatabase a las demás, y su contenido se debe sincronizar. Muchas veces, los sistemas de administración de bases de datos son diferentes: por ejemplo, replicando datasets entre Microsoft SQL Server, Oracle e IBM Db2.
El modelo de transacción de geodatabase: versionado tradicional
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 varios estados de la geodatabase. El objetivo es el acceso abierto, de alto rendimiento, multiusuario. Por ejemplo, el sistema debe ser rápido y permitir un uso productivo de datasets que contienen centenares de millones de registros a los que acceden miles de clientes simultáneamente.
El modelo de transacción de geodatabases basado en versiones es relativamente simple: las actualizaciones se registran en tablas de cambios (delta).
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 los datos en un momento en el tiempo o para ver la versión actual de un editor con sus ediciones.
Las geodatabases y los datasets versionados se utilizan para administrar las transacciones largas en cada sistema de administración de bases de datos aprovechando el marco de transacciones cortas de la base de datos.
En el ejemplo de la tabla de versión, se actualiza una parcela (número 45) para que se convierta en la parcela número 47. Usando el control de versiones, la parcela original se guarda en la tabla de borrados y la parcela nueva se guarda en la tabla de adiciones. Otras tablas del sistema de la geodatabase registran información de versión sobre la transacción, 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 clientes trabajen con la versión predeterminada mientras varios editores realizan actualizaciones simultáneamente en sus propias versiones de los datos a lo largo del tiempo.
Se pueden realizar numerosas actualizaciones en cada versión, y los editores se conectan y trabajan con la versión de actualización cuando realizan ediciones adicionales de los datos. Cuando los editores están listos para compartir las actualizaciones con el resto de la empresa, se realizan operaciones de conciliación y publicación para confirmar las ediciones que contiene la versión de actualización en la versión principal. Se utiliza un proceso de resolución para identificar y conciliar los conflictos potenciales durante este proceso.
Para saber más acerca del versionado, consulte Descripción general del versionado tradicional.