El proceso de archivado

Habilitar el archivado en un dataset versionado crea y llena la clase de archivado con los datos actuales presentes en la versión DEFAULT. La clase de archivado utiliza gdb_from_date y gdb_to_date para mantener la hora en la que se archivó el cambio.

Representar la hora

Es importante entender cómo ArcGIS representa la hora cuando se registra el cambio. El historial se puede registrar como hora válida o tiempo de transacción. La hora válida es el momento real en el que se produjo un cambio en el mundo real y suele registrarla el usuario que está aplicando el cambio. La hora de transacción es la hora en la que se registró un evento en la base de datos. El sistema genera automáticamente las horas de transacción.

ArcGIS utiliza la hora de transacción, que se basa en la hora del servidor actual, para registrar los cambios en los datos cuando los cambios se guardan o se envían a la versión DEFAULT. La hora de transacción y la hora en la que se produjo el evento en el mundo real raramente son la misma hora. Transcurrirá tiempo entre el momento en que sucede un evento en el mundo real y el momento en el que se registra en la base de datos. Por ejemplo, una parcela se vende el 14 de mayo de 2006; sin embargo, el cambio no se registra en los datos hasta el 5 de junio de 2006. En la clase de archivado para este cambio se registra el momento de la transacción del 5 de junio de 2006.

Cuando se produce la edición, ArcGIS archiva la transacción en la clase de archivado. La diferencia entre el momento del evento del mundo real y el momento de la transacción puede parecer insignificante, pero se hace más aparente cuando se realizan consultas contra la información archivada. Los trabajos acumulados de edición y actualización de datos no son raros en los sistemas de producción, y producen diferencias de tiempo y retrasos entre las horas válidas y de transacción.

La diferencia entre las horas válidos y de transacción también son un problema en situaciones en las que el historial se registra en un entorno multiusuario con muchos usuarios o departamentos diferentes que editan la base de datos. Es posible que la secuencia en la que se realizan y se registran los cambios no siga el mismo orden en el que se produjeron esos cambios en el mundo real.

Habilitar el archivado

Tras habilitar el archivado, todas las filas que representan la versión DEFAULT para la clase determinada se copian en la clase de archivado con la misma marca de tiempo. En el atributo gdb_from_date para todas las filas se marca la fecha y la hora de la operación de habilitación del archivado. En el atributo gdb_to_date de todas las filas se marca el tiempo 12/31/9999. Siempre que un atributo tenga el valor de gdb_to_date 12/31/9999, es la representación actual del objeto en la versión DEFAULT. Cuando las ediciones se guardan o se envían a la versión DEFAULT, la geodatabase archiva los campos en la clase de archivado. Esto significa lo siguiente

La actualización de la tabla de archivo se realiza dentro de una única transacción de base de datos. Si se encuentra cualquier error durante la transacción, toda la operación de archivado se deshace y, por lo tanto, la operación de guardado o envío no se completa. Una vez rectificado el error, realice de nuevo la operación de guardado o envío.

Para cada operación de archivado, el marcador histórico DEFAULT se actualiza con el valor de la operación de archivado. Esto garantiza que, al elegir el marcador histórico DEFAULT cuando se trabaja con una versión histórica, la representación actual de la clase de almacenamiento sea equivalente a la representación de la clase versionada en la versión DEFAULT transaccional.

El acceso a la clase de archivado puede consumir en realidad menos recursos de la base de datos que trabajar con la clase equivalente versionada.

Los desarrolladores de aplicaciones interesados en el evento que captura el momento de la operación del archivado pueden consultar el evento OnarchiveUpdated de la interfaz Iversionevents2 del Kit de desarrollo de software.

Las consultas sobre versiones históricas se hacen sobre la clase de archivado:

Tabla de archivado
Tabla de archivado

Las consultas sobre versiones transaccionales continúan en las tablas base y delta:

Tablas base, de adiciones y de eliminaciones
Tablas base, de adiciones y de eliminaciones

Agregar una entidad

Esta entidad de una base de datos catastral muestra la parcela número 116 y su fila correspondiente en la clase de archivado. El atributo gdb_from_date muestra la hora y la fecha de creación, mientras que gdb_to_date muestra 12/31/9999, porque la entidad no se ha modificado ni eliminado desde que se habilitó el archivado.

agregar una entidad

Cuando se inserta una entidad (parcela 117) y las ediciones se envían a la versión DEFAULT, se inserta una fila en la clase de archivado con el atributo gdb_from_date actualizado con la marca de tiempo de esta operación de envío. El atributo gdb_to_date de la nueva fila muestra 12/31/9999 porque esta entidad aún no se ha actualizado o eliminado.

agregar una entidad2

Actualizar una entidad

Cuando se actualiza una entidad, gdb_to_date se establece en la marca de tiempo de la operación de archivado, y se inserta una fila para mostrar la representación actual de la entidad. El atributo gdb_from_date de esta nueva fila se establece en el momento de la operación de archivado, mientras que gdb_to_date muestra 12/31/9999, puesto que aúno no se ha modificado o eliminado.

El siguiente diagrama muestra dos parcelas, 116 y 117, con sus correspondientes atributos gdb_from_date y gdb_to_date en la clase de archivado antes de realizar la operación de actualización.

Actualizar una entidad

Si se extiende el límite de la parcela 117, y estas ediciones se envían a la versión DEFAULT, gdb_to_date se actualiza con la marca de tiempo de la operación de archivado y, a continuación, se crea una nueva fila. El atributo gdb_from_date de esta nueva fila se establece con la hora y la fecha de la operación de archivado.

Actualizar una entidad2

Por ejemplo, las consultas que investigan los momentos anteriores a la actualización (7/14/2005 5:34:22 PM) muestran la parcela 117 tal como existía antes de la actualización. Al consultar los momentos anteriores al 7/9/2005 2:33:43 PM, no se mostrará la parcela 117, porque no se había creado. Cualquier consulta de un momento posterior la actualización (7/14/2005 3:45:23 AM) mostrarán la parcela 117 en su representación actual con el límite extendido.

Más información sobre cómo consultar la clase de archivado

Eliminar una entidad

Cuando se elimina una entidad, gdb_to_date se actualiza con la marca de tiempo de la operación de archivado. El siguiente diagrama muestra las parcelas 116 y 117 con sus correspondientes atributos gdb_to_date y gdb_from_date en la clase de archivado.

Eliminar una entidad

Si ahora se elimina la parcela 117 y estas ediciones se envían a la versión DEFAULT, el atributo gdb_to_date se actualizará con la marca de tiempo de la operación de archivado.

Eliminar una entidad2

Nota técnica sobre el archivado

El siguiente escenario puede crear un hueco de tiempo en la clase de archivado:

Un editor está editando directamente la versión DEFAULT y elimina un objeto en una sesión de edición.

A continuación, el editor guarda las ediciones, lo que actualiza el atributo gdb_to_date de la clase de archivado con la marca de tiempo de la eliminación de ese objeto.

Si el mismo objeto se actualiza en una versión secundaria y se concilia con la versión DEFAULT, habrá un conflicto.

Si, durante el proceso de resolución de conflictos, el editor decide reemplazar el conflicto con la representación actualizada de la fila, la fila se restaurará en la versión DEFAULT cuando se envíe la versión. La operación de archivado inserta una nueva fila en la clase de archivado y establece el atributo gdb_from_date en la marca de tiempo y gdb_to_date en 12/31/9999.

Por consiguiente, cuando el editor observe el linaje del objeto a través del tiempo, las fechas contendrán un hueco entre gdb_to_date y gdb_from_date cuando el objeto no existía en la versión DEFAULT.

Temas relacionados


3/6/2012