Tablas versionadas en una geodatabase en Informix
Una geodatabase corporativa debe proporcionar soporte para varios usuarios que crean y actualizan grandes cantidades de información geográfica al mismo tiempo. Por lo tanto, una geodatabase debe proporcionar un entorno de edición que admita la edición multiusuario concurrente sin crear varias copias de los datos. Si proporciona esta funcionalidad, este entorno de edición también debe admitir sesiones de edición que generalmente abarcan varios días, la facilidad de deshacer o rehacer cambios realizados en la base de datos, la evaluación y el desarrollo de modelos de datos y propuestas de diseño de aplicaciones alternativas sin que afecte la base de datos publicada y la facilidad de controlar cómo los datos y la base de datos evolucionan con el tiempo.
Para lograr estos requisitos, las geodatabases de ArcSDE se pueden versionar. Para empezar, registre los dataset de entidades, las clases de entidad independiente y las tablas como versionadas. Después cree versiones de la geodatabase en las que realizará la edición. Estas versiones son virtuales; no se realizan copias de la geodatabase. Las versiones están representadas por tablas delta asociadas con cada dataset versionado y unas pocas tablas del sistema para rastrear los estados de la versión.
Para obtener información sobre las versiones, consulte Un recorrido rápido por las versiones.
Tablas versionadas en ArcGIS Desktop
En la Ventana de catálogo, los datasets versionados aparecen igual que los datasets no versionados. Puede obtener información acerca de si una clase de entidad o tabla es versionada si abre el cuadro de diálogo Propiedades. En la pestaña General se indica si la clase de entidad o la tabla está registrada como versionada.
Puede tener varias versiones de la geodatabase. En el Catálogo, puede realizar conexiones de base de datos espaciales por separado para cada versión. Cuando realiza una vista previa de un dataset versionado en la versión DEFAULT, puede verse diferente y contener más o menos registros que la misma clase de entidad con vista previa en una versión diferente a la DEFAULT. (Para obtener información sobre cómo realizar una conexión de base de datos espaciales a una versión diferente a DEFAULT, consulte Conectarse a una versión de geodatabase específica).
Del mismo modo, si ve una clase de entidad versionada en una versión en ArcMap y después ve la clase de entidad en otra versión de ArcMap, puede verse diferente. Eso se debe a que una tabla o clase de entidad que ve en una versión contiene una cierta cantidad de filas y la misma clase de entidad en otra versión puede contener una cantidad de filas diferente.
Sugerencia:Para ver qué versión de los datos se encuentra en el mapa, haga clic en el botón Lista por fuente en la tabla de contenido de ArcMap.
Cuando cambia a una versión diferente de la geodatabase (versión wo2557) la clase de entidad Boca de incendios contiene una boca de incendios adicional y un flujo lateral. Esto significa que se agregó una boca de incendios a la clase de entidad Boca de incendios y se agregó un flujo lateral a la clase de entidad Flujo lateral de agua al editar wo2557 como versión de la geodatabase de origen.
Esto da la impresión de que cada versión es una copia por separado de los datos. Sin embargo, en lugar de crear una nueva copia o modificar los datos originales, la geodatabase deja la tabla o la clase de entidad versionada en su forma original y almacena cualquier cambio en los datos en tablas del sistema de la geodatabase por separado. Las tablas de la geodatabase que registran los cambios de la versión se denominan tablas delta. Para cada tabla o clase de entidad que se ha versionado, se crean dos nuevas tablas delta: una tabla de inserciones (a) y una tabla de borrados (d).
Tablas versionadas en una base de datos de IBM Informix
Internamente, una cantidad de tablas de base de datos (las tablas de dataset, tablas delta y tablas del sistema) administran el versionado para rastrear versiones.
Tablas delta
Cuando registra un dataset de entidades, una clase de entidad independiente o una tabla como versionada, las tablas delta (las tablas de inserciones y de borrados) se crean en la base de datos. Las tablas delta registran cualquier inserción, actualización o eliminación realizada en la tabla o la clase de entidad versionada en cada estado de la base de datos.
Nota:Solo el propietario del dataset la puede registrar como versionada.
a<registration_id>
La tabla a<registration_id> (la tabla de inserciones) mantiene la información en cada registro (entidad) insertado o actualizado en una tabla de negocios versionada y se la consulta para identificar qué registros se han agregado o modificado en un estado en particular de la base de datos. El registration_id en el nombre de la tabla de inserciones es el valor en el campo registration_id de la tabla table_registry que corresponde a la tabla versionada. En el ejemplo anterior de las bocas de incendio el registration_id de la clase de entidad Boca de incendios de la tabla table_registry es 161; por lo tanto, la tabla de inserciones para la clase de entidad de las bocas es a161.
La tabla de inserciones contiene todos los mismos campos que la tabla de negocios versionada que se edita, más un col_stateid.
|
Nombre de campo |
Tipo de campo |
Descripción |
¿Nulo? |
|---|---|---|---|
|
<all the fields from the versioned business table> |
<all corresponding types for the fields in the versioned business table> |
Todos los atributos de la nueva entidad |
|
|
sde_state_id |
int8 |
Identificador del estado en el cual se agregó o se actualizó la nueva entidad |
NOT NULL |
Por ejemplo, si agrega una boca de incendios a la clase de entidad Boca de incendios durante una sesión de edición versionada, se agrega un registro en la tabla de inserciones para esa nueva boca de incendios.
d<registration_id>
La tabla d<registration_id> (o tabla de borrados) mantiene la información de todas las filas que se eliminaron o se actualizaron en una tabla versionada y se la consulta para identificar qué filas se han eliminado o modificado en un estado en particular. Cuando se elimina una fila, el registro no se elimina físicamente: se marca como eliminado y nunca se devuelve en las subsiguientes consultas a la base de datos.
|
Nombre de campo |
Tipo de campo |
Descripción |
¿Nulo? |
|---|---|---|---|
|
sde_state_id |
int8 |
Identificador del estado en el cual se agregó o se actualizó la nueva entidad |
NOT NULL |
|
sde_deletes_row_id |
entero |
Identificador único de la entidad eliminada o actualizada |
NOT NULL |
|
deleted_at |
int8 |
Estado en el cual se elimina la entidad |
NOT NULL |
Tablas del sistema
Además de las tablas delta, las tablas del sistema rastrean las versiones y ediciones versionadas. Estas son las tablas states, state_lineages, versions y mvtables_modified.
Por lo general, una base de datos versionada contiene una cantidad de versiones además de la versión DEFAULT. Estas versiones adicionales pueden representar cosas como una orden de trabajo, una alternativa de diseño, una sesión de edición sin conexión o una instantánea histórica. La tabla versions contiene una lista descriptiva de estas versiones con cada versión identificada por un nombre e Id. únicos (ArcSDE genera los Id. automáticamente). Además, cada versión tiene un propietario, una descripción, una versión principal, un estado de la base de datos asociada y un nivel de acceso del usuario.
Cuando se crea la tabla versions, los detalles de la versión DEFAULT se registran automáticamente en esta tabla. El administrador de ArcSDE posee la versión DEFAULT y el Id. inicial del estado de la base de datos correspondiente está establecido en 0. A continuación, se presenta un ejemplo de la entrada DEFAULT en la tabla versions:
|
Nombre |
Propietario |
Version_ID |
Estado |
State_ID |
Descripción |
Parent_name |
Parent_owner |
Parent_version_ID |
Creation_time |
|---|---|---|---|---|---|---|---|---|---|
|
POR DEFECTO |
SDE |
1 |
1 |
0 |
Versión predeterminada de instancia |
NULL |
NULL |
NULL |
2009-02-12 08:40:26 |
Para administrar las ediciones que se realizan en los datos, una geodatabase versionada mantiene un conjunto de estados de la base de datos o unidades de cambio a la base de datos. Un estado representa una instantánea discreta de la base de datos cuando se realiza un cambio: cada operación de edición crea un nuevo estado de la base de datos. (Una operación de edición es cualquier tarea o conjunto de tareas, inserciones, eliminaciones o modificaciones, que se llevan a cabo en entidades y filas). Todas las versiones de la geodatabase hacen referencia a uno de estos estados de la base de datos y evolucionan con el tiempo a través de una serie de estados.
Todos los estados de la geodatabase tienen el mismo esquema y sólo difieren en la cantidad de filas que representa cada tabla o clase de entidad modificada. Para identificar conflictos, que pueden ocurrir cuando se edita la misma entidad en versiones iguales o diferentes, los linajes del estado de la versión se comparan para ver las diferencias o los conflictos de fila durante la conciliación de la versión.
Toda la información relacionada con los estados se administra en la tabla states. Se consulta versions y state_lineages para identificar a qué estado de la base de datos hace referencia cada versión.
Los estados se mantienen en una estructura de árbol donde las relaciones principal-secundaria se pueden derivar del linaje del estado. La información sobre el linaje del estado de cada versión se mantiene en una tabla separada, state_lineages. Esta tabla almacena un índice de varias entradas para recorrer las relaciones principal-secundaria y se utiliza para todas las consultas de la versión.
Para volver a la vista correcta de una versión, se consulta el linaje de estados para identificar todos los estados que registraron cada cambio realizado a esa versión. A partir de esta lista de estados se puede determinar las filas de tabla que representan correctamente la versión. A medida que la geodatabase se edita y las versiones cambian con el tiempo, el árbol de estado se torna más complejo.
Cada vez que se modifica una clase de entidad o una tabla en un estado, se crea una nueva entrada en la tabla mvtables_modified. Cuando se reconcilian dos versiones, el primer paso del proceso es identificar los estados a los que hacen referencia estas dos versiones: el estado de la versión de edición actual y el estado de la versión de destino. De estos estados se identifica un estado de antepasado común al rastrear el linaje de estados de estas dos versiones. Después se consulta la tabla mvtables_modified para identificar todas las tablas que se modificaron entre el estado de antepasado común y el estado de la versión de destino. De esta lista de tablas modificadas, se genera una segunda lista de tablas en común con ambos linajes de estado. Para todas las tablas en común de esta segunda lista, se ejecuta una cantidad de consultas sobre las diferencias en la versión: INSERT, UPDATE, DELETE, UPDATE_UPDATE y UPDATE_DELETE.
Las tablas que forman parte de la clase de entidad versionada se pueden ver en el siguiente diagrama:
Las líneas discontinuas indican relaciones implícitas entre las columnas.
El número de los nombres de las tablas de inserciones y de borrados es el registration_id de la tabla de negocios de la tabla table_registry.
Tablas versionadas en un documento XML
Una entrada en los documentos XML indica si la clase de entidad o tabla es versionada o no. La misma se encuentra entre etiquetas versionadas. Para una clase de entidad o tabla versionada, el valor es verdadero.
Sugerencia:La etiqueta versionada, aunque se establece en datasets de entidades, no necesariamente refleja el valor de la versión para las clases de entidad dentro del dataset de entidades. Para determinar si las clases de entidad dentro de un dataset de entidades están registradas como versionadas, consulte las clases de entidad individuales.
<Versioned>true</Versioned>