Información general sobre el mantenimiento de datos y las transacciones

Resource Center » Biblioteca para profesionales » Administración de datos » Administrar geodatabases » Transacciones y versiones de

geodatabase » Transacciones y mantenimiento de datos

Una geodatabase almacena datos geográficos organizados en datasets. Una geodatabase puede mantener tanto datos espaciales como no espaciales. Algunos ejemplos de los tipos de datasets que se podrían mantener en una geodatabase incluyen las clases de objeto y de entidad, clases de relación, topologías, redes, terrenos, datasets ráster y catálogos ráster. Una geodatabase de ArcSDE almacena datos en una base de datos relacional y utiliza las capacidades de la base de datos relacional para admitir el almacenamiento de datasets grandes y proporcionar acceso eficiente a datos multiusuario.

Un ciclo de vida típico para una geodatabase de ArcSDE implica los siguientes pasos:

Diseño de la geodatabase

Creación de la geodatabase

Carga inicial de los datos

Durante esta fase, se cargan datos para un área de interés. Los datos que se cargan pueden proceder de bases de datos o de bibliotecas de mapas corporativas existentes, o se puede comprar.

Edición y mantenimiento de datos

Durante esta fase, se modifican datos existentes y se agregan nuevos datos a la base de datos según sea necesario. Se realizan ediciones en la base de datos que corresponden a unidades de trabajo definidas por la aplicación, o transacciones tales como la adición de una nueva cloaca o la actualización de un límite de parcela. La fase de edición y mantenimiento de datos puede incluir también la carga incremental de datos, que expande los límites de la base de datos. Esta carga incremental de datos puede producirse cuando una compañía adquiere nuevos territorios o cuando se expande la extensión de un área de estudio.

Algunos ejemplos de cambios que se podrían realizar en una geodatabase durante la edición y el mantenimiento de los datos son los siguientes:

Actualizar la dirección de un cliente en una base de datos de servicios

Subdividir una parcela para reflejar una venta en una base de datos catastral

Agregar un servicio a un nuevo cliente en una base de datos de servicios

Actualizar un bloque de bosque para reflejar una operación de tala planeada

Diseñar una nueva subestación en una base de datos de servicios

Desproteger una sección de una base de datos de servicios, modificarla sobre el terreno para reflejar los daños relacionados con una tormenta y proteger de nuevo el trabajo en la base de datos central

Planear una nueva subdivisión en una base de datos de planificación del terreno

Realizar un escenario hipotético para una simulación de la recuperación ante un desastre

Cada uno de los cambios anteriores corresponde a una unidad de trabajo definida por la aplicación o una transacción que se realiza contra una geodatabase.

El tema Estrategias de mantenimiento de datos explica cómo admitir transacciones de complejidad y duración variables contra datos geográficos tanto simples como complejos.

Temas relacionadosEstrategias de mantenimiento de datosTransacciones y datos geográficos

Copyright © 1995-2011 Esri. Todos los derechos reservados.

1

Qué es una transacciónResource Center » Biblioteca para profesionales » Administración de datos » Administrar geodatabases » Transacciones y versiones de

geodatabase » Transacciones y mantenimiento de datos

Una transacción es una unidad de trabajo definida por la aplicación realizada contra una base de datos. Se inicia una transacción, se realizan modificaciones contra la base de datos y, a continuación la transacción se confirma o se deshace. Una vez confirmada la transacción, los cambios realizados por la transacción se hacen visibles para otros usuarios y aplicaciones.

Las transacciones tienen las siguientes propiedades "ACID" estándar, en las que confían los usuarios y las aplicaciones:

Atómica: una transacción exhibe un comportamiento todo o nada. Si se confirma, todos los cambios se aplican a la base de datos. Si se deshace, ninguno de sus cambios se aplica.

Coherente: una transacción deja la base de datos en un estado coherente.

Aislada: una transacción puede aislar sus cambios de otras transacciones hasta que los confirme. Otros usuarios no ven el trabajo interno de la transacción mientras está en curso.

Duradera: una vez que una transacción se confirma, sus resultados son persistentes.

Para lograr estas propiedades, los sistemas de administración de bases de datos utilizan una variedad de mecanismos de bloqueo para garantizar que varias transacciones simultáneas se blinden o se aíslen entre sí.

Transacciones y datos geográficosResource Center » Biblioteca para profesionales » Administración de datos » Administrar geodatabases » Transacciones y versiones de

geodatabase » Transacciones y mantenimiento de datos

En la mayoría de las aplicaciones, cada transacción implica un número pequeño de operaciones que pueden completarse en una fracción de segundo o, a lo sumo, en un minuto o dos. Algunos ejemplos son retirar dinero de una cuenta bancaria, actualizar las horas de trabajo en una aplicación de nómina o escribir un registro médico.

En algunos aspectos, los datos geográficos no son diferentes. Actualizar datos, tales como la dirección de un cliente o la designación de zona de una parcela, es una operación que podría completarse en una transacción corta que tarda uno o dos minutos.

A menudo, no obstante, es necesario pasarse una o dos horas desplazando gráficamente, modificando y agregando datos para completar una orden de trabajo. Hay también casos en los que se necesita trabajar en una transacción durante días o incluso meses para completar todas las ediciones, por ejemplo para un diseño de ingeniería. Aunque puede hacer un número muy grande de cambios, todavía deseará confirmarlos como una transacción larga única.

Temas relacionadosEstrategias de mantenimiento de datosQué es una transacción

Estrategias de mantenimiento de datosResource Center » Biblioteca para profesionales » Administración de datos » Administrar geodatabases » Transacciones y versiones de

geodatabase » Transacciones y 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 y realizar las operaciones requeridas, tales 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

2

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 desharán y no se confirmarán en la base de datos.

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 se requiera la capacidad de 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.

Aplicaciones potenciales

Integrar fácilmente datos geográficos en aplicaciones existentes permitiendo que aplicaciones de terceros (no creadas con software ESRI) lean y modifiquen los mismos datos obtenidos a los que tienen acceso las aplicaciones ArcGIS.

Administrar proyectos con flujos de trabajo y ediciones simples. Si las transacciones son siempre simples y de corta duración, puede modificar los datos directamente sin necesidad de combinar cambios y administrar periódicamente las tablas adicionales requeridas para las versiones.

Limitaciones

Solo se puede editar datos simples: puntos, líneas, polígonos, anotaciones y relaciones. No se puede editar clases de entidad que participen en una topología, una red geométrica o un terreno.

Dado que la fuente de datos se edita directamente, no se puede deshacer ni rehacer una edición individual si se comete un error. La única manera de deshacer las ediciones es anular todas las ediciones realizadas desde la última vez que se guardó deteniendo la sesión de edición sin guardar.

Cada transacción se debe iniciar y finalizar dentro de una sesión de edición única. Una sesión de edición solo puede durar un tiempo limitado; habitualmente, se debe finalizar después de unas horas, para poder cerrar la sesión al final del día.

Con la edición sin control de versiones no hay ninguna detección de conflictos. Si un usuario actualiza una entidad y la guarda y, a continuación, otro usuario actualiza la misma entidad y la guarda, la última actualización realizada sobrescribe la primera.

Para obtener más información, vea Un recorrido rápido por el trabajo con datos no versionados.

Mantenimiento de datos con versiones

3

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.

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.

4

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 eliminaciones para las eliminaciones. 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.

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:

Guardando todos los cambios, sin tener en cuenta qué versión, en las tablas delta

Guardando todas las ediciones de las versiones diferentes a DEFAULT en las tablas delta, pero guardando todas las ediciones de la versión DEFAULT en las tablas básicas

5

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 de varias versiones.

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 de varias versiones que permiten a estas aplicaciones leer una versión determinada con SQL. Las vistas de varias 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 de varias versiones requiere el uso de tipos de geometría de SQL, que son totalmente compatibles con ArcGIS.

Este enfoque ofrece estas ventajas:

Deshacer o rehacer cambios mientras se está editando.

La ausencia de bloqueos permite la introducción de conflictos de edición. ArcGIS ofrece la capacidad de detectar con facilidad, conciliar y resolver conflictos.

Archivar cambios automáticamente y consultar qué aspecto tenía la base de datos en un momento determinado.

Tiene la capacidad de editar entidades en una red geométrica o una topología.

Puede hacer que dos o más oficinas dispersas geográficamente trabajen simultáneamente en copias sincronizadas de una geodatabase. Las oficinas necesitan enviarse sus cambios entre sí periódicamente de modo que cada una de ellas tenga una vista actualizada de la geodatabase. ArcGIS hace referencia a esta función como replicación de geodatabase.

Los usuarios móviles, desconectados de la red, tienen la capacidad de editar una parte de la geodatabase en un equipo portátil o un dispositivo de mano sobre el terreno. Cuando los usuarios vuelven a la oficina, integran sus cambios en la geodatabase. ArcGIS también hace referencia a esta función como replicación de geodatabase.

6

Entre las aplicaciones potenciales se incluyen las siguientes

Proyectos que requieren el almacenamiento y la consulta de los datos almacenados.

Proyectos que requieren un análisis de hipótesis: crear un nuevo diseño en una versión separada. Si se aprueba el diseño, puede combinarse con el resto de la base de datos. Si no se aprueba, puede descartarlo.

Proyectos con requisitos de control de calidad concretos: recopilar cambios de datos, tales como importaciones masivas, en una versión aislada de otros usuarios de la base de datos. Pruebe y apruebe los cambios antes de combinarlos con la versión publicada de la base de datos.

Proyectos que dividen el trabajo en unidades funcionales o geográficas: por ejemplo, un proyecto para diseñar y construir un nuevo centro comercial podría tener distintas fases de construcción subdivididas en secciones este y oeste, o subdivididas por actividades de construcción, tales como edificación, instalación de servicios o paisajismo. Cada unidad de trabajo se emprende en una versión separada; cuando se completa cada versión, se envía a la versión publicada de la base de datos.

Proyectos que evolucionan a través de un grupo prescrito o regulado de etapas, en el que cada etapa requiere aprobación de ingeniería, administrativa o legal antes de poder considerarla completada: los flujos de trabajo para estos proyectos pueden administrar cada etapa como una versión separada, tal como un diseño inicial o una versión propuesta, una versión aprobada y una versión para la fase de construcción. A medida que un proyecto avanza a través de diversos hitos, cada etapa se revisa y se aprueba y, a continuación, es reemplazada por la siguiente versión hasta que se alcanza y se completa la última etapa.

Proyectos con requisitos de auditoría administrativa: mantener un archivo persistente para permitir la consulta de los cambios.

Proyectos con oficinas geográficamente distantes que necesitan trabajar simultáneamente en la misma geodatabase: requieren la capacidad de sincronizar periódicamente sus copias de los datos.

Proyectos que requieren personal de mantenimiento sobre el terreno para actualizar los datos con equipos portátiles.

Proyectos que exigen a los programadores de software que prueben instrucciones SQL y lógica de aplicación en su propia versión privada de la base de datos.

Las versiones ofrecen muchas ventajas pero tienen algunas limitaciones:

Las aplicaciones de terceros deben estar adaptadas con vistas de varias versiones para poder leer los datos.

Hay restricciones sobre el uso del comportamiento activo del DBMS, tales como las restricciones únicas y los desencadenadores, cuando se trabaja con datos versionados. Esto se debe a que las inserciones y las actualizaciones crean nuevas filas en las tablas delta en lugar de inserciones y actualizaciones en la tabla básica.

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, puede que necesite la capacidad de 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.

Al editar los datos registrados de esta manera, las versiones funcionan de la misma manera descrita 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.

Las aplicaciones escritas sin el software de ESRI pueden continuar obteniendo acceso y modificando los datos con transacciones estándar, aunque se estén editando al mismo tiempo en la versión DEFAULT o en otra versión.

Siempre que ArcGIS o una aplicación escrita con ArcObjects guarda cambios en la versión DEFAULT o combina cambios en la versión DEFUALT, se aplican los índices únicos, las restricciones y los desencadenadores definidos en los datos con el DBMS.

Cuando una aplicación modifica los datos, los cambios quedan inmediatamente a disposición de cualquier otra aplicación que tenga acceso a los datos. Dado que los cambios de la versión DEFUALT no se almacenan en tablas delta, no hay ninguna

7

necesidad de adaptar aplicaciones de terceros con vistas de varias versiones para que puedan leer estas tablas.

Aplicaciones potenciales

Proyectos que requieren la edición de los datos por ArcGIS y otras aplicaciones: configurar un flujo de trabajo donde las otras aplicaciones obtienen acceso y modifican datos no espaciales en la base de datos con transacciones estándar del DBMS, mientras otros usuarios trabajan en versiones concretas de los mismos datos, realizando transacciones de duración relativamente larga aisladas de todos los demás usuarios de la base de datos hasta que se envían a la versión DEFAULT.

Las mismas aplicaciones potenciales que cuando el mantenimiento de los datos se realiza exclusivamente con aplicaciones ArcGIS Proyectos que requieren un análisis de hipótesis

Proyectos con requisitos de control de calidad concretos

Proyectos que dividen el trabajo en unidades funcionales o geográficas

Proyectos que evolucionan a través de un grupo prescrito o regulado de etapas

Proyectos que requieren personal de mantenimiento sobre el terreno para actualizar los datos con equipos portátiles.

Proyectos que exigen a los programadores de software que prueben instrucciones y lógica de aplicación SQL

Limitaciones

Al registrar un dataset como versionado con la opción Mover ediciones a la base, tiene limitada la forma de trabajar con versiones.

Solo se puede editar datos simples: puntos, líneas, polígonos, anotaciones y relaciones. No puede editar una clase de entidad en una topología, una red geométrica o un terreno.

No puede archivar cambios para el dataset.

No puede replicar el dataset.

Al editar la versión DEFAULT o envía una versión a DEFAULT, no tiene la capacidad de resolver conflictos, así que es posible sobrescribir las ediciones de otro usuario.

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 relacionadosDecidir cómo registrar los datos

8

Copyright © 1995-2011 Esri. Todos los derechos reservados.

9

Decidir cómo registrar los datosResource Center » Biblioteca para profesionales » Administración de datos » Administrar geodatabases » Transacciones y versiones de

geodatabase » Transacciones y mantenimiento de datos

Al determinar cómo registrar los datos para la edición, los modelos de datos avanzados y los flujos de trabajo siempre son la primera consideración. Para editar una clase de entidad en una topología, una red geométrica o un terreno, archivar datos o administrar los datos con replicación, debe registrar los datos como versionados sin la opción de trasladar las ediciones a la base. Esto ofrece muchas ventajas, permitiendo aprovechar todas las entidades transaccionales avanzadas de la geodatabase, incluyendo deshacer y rehacer las ediciones, el aislamiento completo dentro de una sesión de edición y el uso de versiones con nombre para diseños y proyectos.

Deje los datos sin registrar o regístrelos como versionados con la opción de desplazar las ediciones a la base si la capacidad de compartir fácilmente los datos con aplicaciones de terceros es una prioridad. Registrar los datos como versionados con la opción de trasladar ediciones a la base es útil si se necesitan las ventajas de las versiones, pero también se necesita compartir actualizaciones con aplicaciones distintas de ArcGIS.

Como consideración final, cada vez que los datos forman parte de una relación con otra clase de entidad o tabla, debe asegurarse de registrar los datos de ambos lados de la relación de la misma manera.

Sin control de versionesCon control de versiones con la opción de desplazar ediciones a la base

Con control de versiones sin la opción de desplazar ediciones a la base

Tipos de datos compatibles Todos los tipos de datos excepto las clases de entidad de una topología, una red geométrica o un terreno

Todos los tipos de datos excepto las clases de entidad de una topología, una red geométrica o un terreno

Todos los tipos de datos

Flujos de trabajo compatibles Flujos de trabajo simples Flujos de trabajo simples y avanzados con versiones no compatibles: archivado y replicación

Flujos de trabajo simples y avanzados, incluyendo versiones, replicación y archivado

Transacción Confinada a una única sesión de edición

Puede abarcar muchas sesiones de edición

Puede abarcar muchas sesiones de edición

Permite deshacer/rehacer No Sí Sí

Compatible con entidades de integridad de datos de DBMS

Sí Al editar la versión DEFAULT: sí, pero solo al guardar. Al editar las otras versiones: No

No

Pueden ser leídos por aplicaciones cliente no creadas con ArcObjects (aplicaciones de terceros)

Sí Versión DEFAULT: Sí. Clases de entidad en otras versiones: No. Tablas en otras versiones: Sí, a través de las vistas de varias versiones

Clases d entidad: No. Tablas: Sí, a través de vistas de varias versiones

Una comparación de tipos de registro

El siguiente diagrama le ayudará a decidir qué nivel de registro de los datos requiere un flujo de trabajo determinado.

10

Este diagrama le ayuda a decidir cómo registrar los datos

Para obtener más información sobre el aislamiento de la sesión de edición, vea Simultaneidad y bloqueo.

Para obtener más información sobre las ventajas y desventajas de cada opción de edición, vea Estrategias de mantenimiento de datos.

De forma predeterminada, las sesiones de edición de ArcMap están configuradas para realizar ediciones versionadas. Con esta configuración, solo se puede editar datos registrados como versionados. Para obtener información sobre cómo configurar una sesión de edición para permitir ediciones sin control de versiones, veaConfigurar una sesión de edición de ArcMap para realizar ediciones sin control de versiones.

Temas relacionadosEstrategias de mantenimiento de datos

Copyright © 1995-2011 Esri. Todos los derechos reservados.

11

Un recorrido rápido por el trabajo con datos no versionadosResource Center » Biblioteca para profesionales » Administración de datos » Administrar geodatabases » Transacciones y versiones de

geodatabase » Trabajar con datos no versionados

Editar datos no versionados almacenados en una geodatabase de ArcSDE es el equivalente de realizar transacciones de base de datos estándar. Las transacciones se realizan dentro del ámbito de una sesión de edición de ArcMap. Se inicia la sesión de edición y se realizan las operaciones requeridas, tales como agregar, eliminar o mover entidades y actualizar atributos. Al guardar las ediciones, las ediciones realizadas se confirman en la geodatabase como una transacción única. Si no desea confirmar los cambios en la geodatabase, debe salir de la sesión de edición sin guardar. Esto deshace todas las ediciones realizadas desde que se abrió la sesión de edición o desde la última vez que se guardó. Cada transacción puede incluir tantas operaciones como se necesite, siempre que queden dentro de una única sesión de edición.

Al editar datos no versionados en una sesión de edición de ArcMap, se edita directamente la fuente de datos; las sesiones de edición no versionadas no almacenan los cambios en otras tablas, como hacen las sesiones de edición con control de versiones. Esto evita la sobrecarga de administrar estas tablas adicionales y permite adaptar fácilmente aplicaciones de terceros para que puedan leer y editar los datos. Sin embargo, la desventaja es que, dado que se edita la fuente de datos directamente, no es posible deshacer o rehacer una edición individual si se comete un error. La única manera de deshacer ediciones consiste en deshacer todas las ediciones saliendo de la sesión de edición sin guardar.

Solo se puede editar datos simples no versionados: puntos, líneas, polígonos, anotaciones y relaciones. No se puede editar clases de entidad en una topología o una red geométrica. Esto es así porque, al editar una entidad en una red o una topología, no todas las entidades de la red o la topología se bloquean, lo que significa que otros editores pueden editar otra parte de la red o la topología de manera que entren en conflicto con sus ediciones.

Al editar datos no versionados en una geodatabase de ArcSDE, debe tener en cuenta comportamientos del DBMS tales como el bloqueo, los niveles de aislamiento y las restricciones y desencadenadores que el DBMS utiliza para forzar la integridad de los datos. Para ver información detallada, consulte los temas correspondientes:

Simultaneidad y bloqueo

Niveles de aislamiento

Trabajar con entidades de integridad de datos

El trabajo con datos no versionados es solo para la edición por parte de un único usuario. Si varios usuarios van a editar el mismo dataset, se recomienda utilizar la edición con control de versiones. Las ediciones de datos no versionados realizadas por varios usuarios provocan problemas con el bloqueo, los niveles de aislamiento, y las restricciones y desencadenadores del sistema de administración de bases de datos que la base de datos utiliza para exigir la integridad de los datos.

Para editar datos no versionados en una sesión de ArcMap, necesita hacer lo siguiente:

1. Asegurarse de que los datos estén registrados en la geodatabase.

Todos los datasets creados con ArcGIS Desktop se registran automáticamente con la geodatabase. La única ocasión en que tendrá que preocuparse por registrar datos con la geodatabase será si crea los datos fuera de ArcGIS Desktop; por ejemplo, si creara una tabla mediante el comando sdetable. Para obtener información sobre cómo registrar datos con la geodatabase, vea Registrar una capa con una geodatabase.

2. Asegurarse de que los datos no estén registrados como versionados.

Cuando se crea un dataset en la geodatabase, no se registra como versionada. Si hay un dataset existente que ya se ha registrado como versionados, puede anular su registro.

Nota:Las ediciones versionadas realizadas en el dataset sin conciliación y enviadas a la geodatabase se perderán si anula el registro del control de versiones; en consecuencia, debe asegurarse de que el dataset no contenga ninguna de esas ediciones no enviadas antes de anular el registro del control de versiones.

 Para obtener más información sobre cómo anular el registro de los datos como versionados, veaRegistrar datos como versionados y Anular el registro de datos como versionados.

3. Configure la sesión de edición de ArcMap para realizar ediciones sin control de versiones.

Para obtener información sobre cómo hacerlo, vea Configurar una sesión de edición de ArcMap para realizar ediciones no versionadas.

Copyright © 1995-2011 Esri. Todos los derechos reservados.

Configurar una sesión de edición de ArcMap para realizar ediciones sin control de versionesResource Center » Biblioteca para profesionales » Administración de datos » Administrar geodatabases » Transacciones y versiones de

geodatabase » Trabajar con datos no versionados

De forma predeterminada, las sesiones de edición de ArcMap están configuradas para realizar ediciones versionadas. Esto significa que solo se puede editar datos registrados como versionados.

Para realizar ediciones sin control de versiones sobre datos no versionados, debe establecer primero una opción en la ficha Versionado del cuadro de diálogo Opciones de Edición. Esencialmente, debe desactivar la edición con control de versiones desactivando Editar una versión de una base de datos con la habilidad de deshacer y rehacer..

Cuando se inicia la edición, no se puede cambiar el tipo de sesión de edición mientras la sesión de edición está abierta. Si más tarde necesita realizar ediciones con control de versiones, debe cerrar la sesión de edición sin control de versiones, volver a activar la opción Editar una versión de una base de datos con la habilidad de deshacer y rehacer. e iniciar una sesión de edición con control de versiones.

Sugerencia:Al iniciar la sesión de edición sin control de versiones, si recibe un mensaje de error que indica que no puede editar porque todas las fuentes de datos del mapa están registradas como versionadas o no tiene privilegios para modificar las fuentes de datos que no estén registradas como versionadas, asegúrese de que haya realmente datasets no versionados presentes en ArcMap, que tiene privilegios para editar el dataset no versionado, y que el dataset no versionado no participe en una relación con otro dataset registrado como versionado.

Pasos:

1. Si la barra de herramientas Editor aún no está abierta, haga clic en Personalizar en el menú principal, seleccione Barras de herramientas y haga clic en Editor.

2. Haga clic en el menú desplegable Editor en la barra de herramientas Editor.3. Haga clic en Opciones.4. Haga clic en la ficha Versionado.5. Desactive Editar una versión de una base de datos con la habilidad de deshacer y rehacer..6. Haga clic en Aceptar.

Sugerencia:Si necesita crear entidades durante una sesión de edición sin control de versiones y los campos tienen restricciones de valor NOT NULL o UNIQUE, se debe satisfacer estas restricciones al crear las entidades. Vea Editar datos no versionados con restricciones.

Temas relacionadosUn recorrido rápido por el trabajo con datos no versionados

Copyright © 1995-2011 Esri. Todos los derechos reservados.

Simultaneidad y bloqueoResource Center » Biblioteca para profesionales » Administración de datos » Administrar geodatabases » Transacciones y versiones de

geodatabase » Trabajar con datos no versionados

Para ayudar a garantizar la integridad de los datos, todos los sistemas de administración de bases de datos (DBMS) aplican bloqueos a los datos. Por ejemplo, cuando un usuario empieza a actualizar filas, las filas se bloquean para evitar que otro usuario las modifique. Cuando la transacción ha finalizado, los bloqueos se liberan.

Cada DBMS aplica bloqueos e interpreta los niveles de aislamiento de manera diferente. Además, ArcGIS no funciona con todos los DBMS de la misma manera. Como resultado, la probabilidad de que se produzcan problemas de simultaneidad al realizar ediciones no versionadas difiere ligeramente entre los diversos DBMS. En este tema se proporciona una introducción breve a la aplicación de la simultaneidad y el bloqueo dentro del contexto de ArcGIS. Para obtener información más detallada, consulte la documentación del DBMS.

ArcGIS y los niveles de aislamiento

Al editar una geodatabase de Oracle, DB2 o Informix en una sesión de edición sin control de versiones, funcionan los mismos mecanismos de bloqueo del DBMS subyacente que con cualquier otra aplicación; ArcGIS no modifica este entorno estableciendo el nivel de aislamiento. En su lugar, utiliza el nivel de aislamiento actual establecido en el DBMS. Como resultado, es posible establecer el aislamiento en cualquier nivel y hacer uso de ese nivel al editar en una sesión de edición sin control de versiones.

Al editar una geodatabase de SQL Server en una sesión de edición sin control de versiones, ArcGIS establece el nivel de aislamiento en UNCOMMITTED READ antes de cada transacción. No hay ninguna manera de cambiar o evitar este comportamiento; si establece el aislamiento en otro nivel antes de una transacción, ArcGIS lo establecerá de nuevo en UNCOMMITTED READ antes de que se inicie la transacción.

En las siguientes secciones se describe el potencial para problemas de simultaneidad bajo condiciones comunes. A menos que se indique lo contrario, estas explicaciones suponen que se ha establecido el nivel de aislamiento predeterminado UNCOMMITTED READ, o su equivalente, en el DBMS subyacente.

Oracle

Los escritores bloquean a los escritores: al realizar una operación de edición en una entidad o un grupo de entidades, tales como moverlas o modificar sus atributos, el DBMS bloquea las filas. Las entidades continúan bloqueadas hasta que se guarda o se detiene la sesión de edición sin guardar. Por consiguiente, cualquier entidad o registro que edite se bloqueará mientras dure la sesión de edición.

Cuando dos usuarios intentan editar la misma entidad al mismo tiempo, la entidad se bloquea cuando el primer usuario completa una operación. El bloqueo se continúa manteniendo, aunque este usuario esté trabajando en otras entidades. La entidad permanece bloqueada hasta que este usuario guarde la sesión de edición, confirmando así los cambios en la base de datos, o la detenga sin guardar, lo que deshace todas las ediciones realizadas en esa sesión de edición.

Mientras la entidad está bloqueada, el segundo usuario intenta modificar la misma entidad. La sesión de ArcMap del segundo usuario espera al bloqueo o a la liberación, mostrando el conocido reloj de arena. El reloj de arena se continúa mostrando hasta que se libera el bloqueo cuando el primer usuario guarda los cambios (confirma los cambios en la base de datos) o finaliza la sesión de edición sin guardar los cambios (deshace las ediciones). En ese momento, el reloj de arena de la pantalla del segundo usuario desaparece, y se puede realizar la operación de edición del segundo usuario. (Observe que esto significa que las ediciones del segundo usuario sobrescriben las ediciones del primer usuario.)

Este problema de bloqueo también se puede producir simultáneamente entre dos usuarios cada vez que sucede lo siguiente:

Los dos usuarios están editando simultáneamente.

Los usuarios han modificado filas en su sesión de edición actual.

Cada usuario intenta modificar una fila ya modificada por el otro usuario.

El primero de los usuarios que intenta modificar una fila bloqueada ve un reloj de arena mientras la sesión de ArcMap espera a que se libere el bloqueo. Cuando el segundo usuario intenta modificar una fila bloqueada por el primer usuario, se produce una situación conocida como interbloqueo, puesto que ambos usuarios se están bloqueando entre sí. El DBMS elige rápidamente una de las transacciones para deshacerla, de modo que el otro pueda continuar. El usuario cuya transacción se deshizo debe rehacer las ediciones realizadas desde que se guardaron las últimas ediciones.

Los escritores no bloquean a los lectores: los usuarios que escriben en la base de datos no impiden que otros usuarios lean los mismos datos, sin tener en cuenta el nivel de aislamiento. Para los usuarios que leen los datos bloqueados, aparecen como estaban antes de que se iniciara la transacción actual.

Los lectores no bloquean a los escritores: los usuarios que leen la base de datos no impiden que otros usuarios modifiquen los mismos datos en cualquier nivel de aislamiento.

DB2 e Informix

Los escritores bloquean a los escritores: los escritores bloquean a los escritores en DB2 e Informix de manera similar a como los escritores bloquean a los escritores en Oracle. Para obtener información detallada, vea la explicación bajo "Oracle".

Los escritores bloquean a los lectores: en DB2 e Informix, los escritores impiden que otros usuarios lean los mismos datos en cualquier nivel de aislamiento superior a UNCOMMITTED READ. En estos niveles de aislamiento superiores, el bloqueo de los datos hasta que las ediciones se guardan o se deshacen pueden provocar problemas de simultaneidad; mientras está trabajando en una sesión de edición, nadie más puede leer los datos que está editando. Esto puede provocar que ocurra lo siguiente:

Si otro usuario agrega la misma capa a ArcMap, aparece el reloj de arena y la capa no se dibuja hasta que se liberen los bloqueos.

Si otro usuario intenta desplazarse a los datos que se están editando, ArcMap espera a que se libere el bloqueo antes de actualizar la visualización.

Si otro usuario identifica una entidad bloqueada, el reloj de arena aparece y no se devuelve ninguna información hasta que se libere el bloqueo.

Los lectores bloquean a los escritores: en DB2 e Informix, los lectores pueden impedir que otros usuarios modifiquen los mismos datos en cualquier nivel de aislamiento superior a UNCOMMITTED READ. Sin embargo, en realidad esto apenas se nota en ArcGIS, puesto que los bloqueos de lectura sobre las filas se mantienen durante muy poco tiempo; en el momento en que aparecen los datos, ya se ha liberado el bloqueo. Los lectores solo pueden bloquear realmente a los escritores en una aplicación que abra un cursor en el DBMS, obtenga una fila cada vez y recorra el conjunto de resultados a medida que procesa los datos. En este caso, DB2 e Informix inician la adquisición y el mantenimiento de bloqueos cuando se procesa el conjunto de resultados.

PostgreSQL

Los escritores bloquean a los escritores: en PostgreSQL, una fila no se puede actualizar hasta que la primera transacción realizada en en la fila se confirma en la base de datos o se deshace. Cuando dos usuarios intentan editar la misma entidad al mismo tiempo, el primer usuario bloquea las actualizaciones del otro en esa fila. Otros usuarios no pueden editar esa fila hasta que este usuario la guarde, confirmando los cambios en la base de datos, o detenga la sesión de edición sin guardar, lo que deshace todas las ediciones realizadas en esa sesión de edición.

Mientras la entidad está bloqueada, el segundo usuario intenta modificar la misma entidad. La sesión de ArcMap del segundo usuario espera al bloqueo o a la liberación, mostrando el conocido reloj de arena. El reloj de arena se continúa mostrando hasta que el primer usuario guarda sus cambios (confirma los cambios en la base de datos) o finaliza la sesión de edición sin guardar los cambios (deshace las ediciones). En ese momento, el reloj de arena de la pantalla del segundo usuario desaparece, y se puede realizar la operación de edición del segundo usuario. (Observe que esto significa que las ediciones del segundo usuario sobrescriben las ediciones del primer usuario.)

Los escritores no bloquean a los lectores: si utiliza el control de simultaneidad multiversión (MVCC) de PostgreSQL, que es el comportamiento predeterminado y recomendado para la base de datos, las transacciones del usuario que escriben en la base de datos no bloquean a los lectores que consultan la base de datos. Esto es verdad si se utiliza el nivel de aislamiento predeterminado READ COMMITTED en la base de datos o se establece el nivel de aislamiento en SERIALIZABLE.

Los lectores no bloquean a los escritores: no importa qué nivel de aislamiento se establezca en la base de datos, los lectores no bloquean los datos.

SQL Server

ArcGIS establece el nivel de aislamiento en READ UNCOMMITTED antes de cada transacción en una geodatabase de SQL Server. A continuación se describen algunos problemas de simultaneidad potenciales que pueden surgir dentro del contexto de ArcGIS. Para obtener más información sobre el nivel de aislamiento READ UNCOMMITTED, consulte la documentación de SQL Server.

Los escritores bloquean a los escritores: los escritores bloquean a los escritores en SQL Server de manera similar a como los escritores bloquean a los escritores en Oracle. Para obtener información detallada, vea la explicación bajo "Oracle".

Los escritores no bloquean a los lectores: dado que ArcGIS establece el nivel de aislamiento en READ UNCOMMITTED antes de cada transacción, los escritores no bloquean a los lectores en las geodatabases de SQL Server. Sin embargo, cuando algunos usuarios están modificando los datos mientras otros están leyendo los mismos datos, es posible que los usuarios lean datos que se hayan cambiado pero todavía no se hayan confirmado. Esto se conoce como una lectura modificada y puede provocar que una consulta devuelva lo siguiente:

Valores de datos inexactos

Que no se devuelva ningún dato, cuando los datos existen

Que se devuelvan datos duplicados cuando no existe ninguno

Los lectores no bloquean a los escritores: dado que ArcGIS establece el nivel de aislamiento en READ UNCOMMITTED antes de cada transacción, los lectores no bloquean a los escritores en las geodatabases de SQL Server.

Evitar problemas de simultaneidad

Afortunadamente, hay maneras de minimizar los problemas de simultaneidad:

Diseñe las aplicaciones y los flujos de trabajo pensando en los bloqueos: las solicitudes a la espera de la liberación de bloqueos suelen ser el resultado de aplicaciones o flujos de trabajo mal diseñados. Al desarrollar una aplicación o un flujo de trabajo, asegúrese de que los bloqueos se soliciten de manera organizada. Puede lograr esto normalizando la secuencia de actualizaciones en todas las tablas. Esto debería evitar los interbloqueos. Para reducir la cantidad de tiempo que se mantienen los bloqueos, es mejor emitir todas las solicitudes de modificación de datos al final de cada unidad de lógica de la aplicación o del flujo de trabajo que ejecute una transacción.

Establezca el nivel de aislamiento adecuado (Oracle, DB2, Informix): el nivel de aislamiento afecta a la cantidad de tiempo durante el que una transacción bloquea los datos. Cuanto más alto es el aislamiento, mas tiempo mantiene el bloqueo la transacción. Cuanto más tiempo mantiene el bloqueo la transacción, más aumenta la integridad de los datos, pero al precio de reducir la simultaneidad. Si es aceptable para la aplicación, puede reducir el nivel de aislamiento para mejorar la simultaneidad.

Registre los datos como versionados: mejore la simultaneidad registrando los datos como versionados para trasladar las ediciones a la tabla base. Esto permite a los usuarios continuar manteniendo los datos con aplicaciones que no utilicen ArcGIS, pero aporta a los usuarios de la aplicación de ArcObjects y ArcGIS, que de otra manera se verían afectados por los problemas de simultaneidad, o que los provocarían, la capacidad de editar y administrar versiones de los datos. Cuando un usuario edita una versión, el usuario no aplica bloqueos, lo que permite editar los datos en aislamiento completo de otros usuarios.

El bloqueo de bases de datos es un tema complejo. Además, cada DBMS realiza el bloqueo de manera diferente. Como resultado, es necesario estudiar el comportamiento del DBMS para determinar en qué nivel establecer los bloqueos, cómo establecer los niveles de aislamiento y cómo tratar los tiempos de espera de bloqueo y los interbloqueos.

Temas relacionadosUn recorrido rápido por el trabajo con datos no versionados

Copyright © 1995-2011 Esri. Todos los derechos reservados.

Trabajar con entidades de integridad de datosResource Center » Biblioteca para profesionales » Administración de datos » Administrar geodatabases » Transacciones y versiones de

geodatabase » Trabajar con datos no versionados

Para facilitar la tarea de garantizar la integridad de los datos, la geodatabase proporciona la propiedad de campo Permitir valores nulos, dominios, subtipos, clases de relación y valores predeterminados. De igual forma, el DBMS proporciona sus propias entidades de integridad de datos, que incluyen restricciones sobre valores nulos, restricciones sobre valores únicos, restricciones referenciales, restricciones de comprobación y desencadenadores. ESRI recomienda utilizar entidades de geodatabase en lugar de restricciones y desencadenadores de DBMS para garantizar la integridad de los datos. Las entidades de geodatabase son más flexibles y más potentes, y funcionan igual en todos los DBMS y formatos de geodatabase personal.

Sin embargo, si tiene una aplicación de terceros que tenga acceso a los datos de la geodatabase, la aplicación solo tener acceso a los datos del nivel del DBMS, omitiendo las entidades de integridad configuradas en el nivel de geodatabase. Para dar soporte a esta aplicación, quizá desee implementar restricciones y desencadenadores del DBMS.

Al editar datos en una sesión de edición no versionada, las ediciones están sometidas a las restricciones del DBMS establecidas sobre los datos. Siempre que desee realizar una operación de edición individual desde el interior de ArcMap o de una aplicación escrita en ArcObjects e infrinja una restricción, un mensaje del DBMS le informará del error. De manera similar, la edición en una sesión de edición no versionada activa los desencadenadores; si una edición actualiza una columna que tenga definido un desencadenador, el desencadenador se dispara.

Temas relacionadosEditar datos no versionados con restricciones

Copyright © 1995-2011 Esri. Todos los derechos reservados.

Editar datos no versionados con restriccionesResource Center » Biblioteca para profesionales » Administración de datos » Administrar geodatabases » Transacciones y versiones de

geodatabase » Trabajar con datos no versionados

Si necesita agregar entidades a una tabla o clase de entidad sin control de versiones, y esa tabla o clase de entidad contiene campos a los que se hayan aplicado restricciones NOT NULL o UNIQUE, debe actualizar los valores de los atributos en el momento de la creación de la entidad. Para hacerlo, puede establecer la tabla de atributos para que se muestre de modo que pueda agregar valores a los campos con restricciones.

Pasos:

1. Si la barra de herramientas Editor aún no está abierta, haga clic en Personalizar en el menú principal, seleccione Barras de herramientas y haga clic en Editor.

2. Haga clic en el menú desplegable Editor en la barra de herramientas Editor.3. Haga clic en Opciones.4. Haga clic en la ficha Atributos del cuadro de diálogo Opciones de Edición.5. Elija la opción Mostrar el cuadro de diálogo de atributos antes de almacenar nuevas entidades.6. Haga clic en Para las siguientes capas.7. Active la casilla junto a las capas que no tengan restricciones de valor NOT NULL o UNIQUE.

Esto provoca que la tabla de atributos se muestre automáticamente durante la edición solo para las capas que se elijan en la lista.

Copyright © 1995-2011 Esri. Todos los derechos reservados.

Edición sin control de versiones y la caché de entidadResource Center » Biblioteca para profesionales » Administración de datos » Administrar geodatabases » Transacciones y versiones de

geodatabase » Trabajar con datos no versionados

Generar una caché de entidad puede acelerar tareas comunes de ArcMap, tales como dibujar, seleccionar, etiquetar y editar entidades. La caché de entidad contiene las entidades de la extensión actual del mapa en la memoria del equipo local. Una caché de entidad produce un procesamiento más rápido, porque ArcMap no tiene que recuperar datos del servidor cada vez que se actualiza la visualización.

Se debe tener cuidado, no obstante, al utilizar cachés de entidad para editar en sesiones de edición sin control de versiones. Después de generar una caché de entidad de algunos datos, si otro usuario edita esos datos, ya no estará trabajando con datos correctos. Cuando confirme, es posible que sobrescriba las ediciones del otro usuario. La siguiente secuencia de eventos proporciona un ejemplo de cómo puede suceder esto:

1. Tom inicia la edición, genera una caché de entidad de pozo y muestra los puntos en ArcMap.

2. Susan inicia su propia sesión de edición, mueve un punto de pozo y confirma el cambio.3. Tom generó su caché de entidad antes de que Susan iniciara la edición, así que en este momento Tom

continúa viendo el pozo en su ubicación original. Tom mueve el pozo a otra ubicación diferente y confirma, sobrescribiendo las ediciones de Susan.

Temas relacionadosUn recorrido rápido por el trabajo con datos no versionados

Copyright © 1995-2011 Esri. Todos los derechos reservados.

Qué es una versiónResource Center » Biblioteca para profesionales » Administración de datos » Administrar geodatabases » Transacciones y versiones de

geodatabase » Trabajar con datos versionados

Una versión representa una instantánea en el tiempo de la geodatabase completa y contiene todos los datasets de la geodatabase.

Las versiones no son copias separadas de la geodatabase. En su lugar, se realiza el seguimiento en tablas del sistema de las versiones y de las transacciones que tienen lugar dentro de ellas. Esto aísla el trabajo de un usuario entre varias sesiones de edición, permitiendo que los usuarios editen sin bloquear las entidades de la versión de producción ni afectar inmediatamente a los otros usuarios, y sin tener que realizar copias de los datos.

Licencia:Las versiones solo se admiten en geodatabases de ArcSDE.

Vea Un recorrido rápido por el control de versiones para obtener más información detallada sobre las versiones y el control de versiones.

Copyright © 1995-2011 Esri. Todos los derechos reservad

Un paseo introductorio por el versionadoResource Center » Biblioteca para profesionales » Administración de datos » Administrar geodatabases » Transacciones y versiones de

geodatabase » Trabajar con datos versionados

Este tema se aplica sólo a ArcEditor y ArcInfo.

El versionado permite que varios usuarios editen los mismos datos en una geodatabase de ArcSDE sin aplicar bloqueos o duplicar datos.

Los usuarios siempre acceden a una geodatabase de ArcSDE mediante una versión. Cuando se conecta a una geodatabase multiusuario, especifica la versión a la que se conectará. Por defecto, se conectará a la versión DEFAULT.

La versión DEFAULT

Todas las geodatabases de ArcSDE tienen una versión predeterminada que se llama DEFAULT; por lo tanto, siempre está habilitado el versionado para la geodatabase. Es una parte fundamental de la forma de operación de ArcGIS y no precisa ser instalada o configurada por separado.

A diferencia de otras versiones, la versión DEFAULT siempre existe y no se puede eliminar. En la mayoría de las estrategias de flujo de trabajo, es la versión publicada de la base de datos que representa el estado actual del sistema que se está modelando. Para mantener y actualizar la versión DEFAULT a lo largo del tiempo, debe publicarle los cambios de otras versiones. También puede editar la versión DEFAULT directamente, como cualquier otra versión.

La versión DEFAULT es la versión raíz y, por lo tanto, es anterior a todas las demás versiones.

Crear otras versiones

Se crea una versión al crear versiones secundarias o ramas de cualquier versión existente. La primera versión se crea al crear una versión secundaria de la versión DEFAULT. Cuando se crea la versión nueva, ésta es igual a la versión DEFAULT. Con el paso del tiempo, las versiones se diferenciarán a medida que se realizan cambios en la versión DEFAULT y la versión nueva.

Una geodatabase puede tener muchas versiones. El siguiente es el cuadro de diálogo Administrador de versiones, al que se accede mediante ArcGIS Desktop. Este ejemplo muestra la versión DEFAULT y otras tres versiones: una versión de garantía de calidad (QA) y versiones de proyecto: ProjectA y ProjectB.

El siguiente diagrama muestra cómo se relacionan las versiones. La versión QA es una versión secundaria de la DEFAULT y las versiones ProjectA y ProjectB son versiones secundarias de la QA.

Crear versiones da la falsa sensación de que se está creando una copia de toda la geodatabase. Esto se debe a que cada versión tiene todas las tablas y clases de entidades en la geodatabase. A medida que edita una clase de entidad o tabla en una versión, deja de ser la misma clase de entidad o tabla de la versión principal, entonces usted cree que está almacenando la clase de entidad o tabla en cada versión. Sin embargo, independientemente de la cantidad de versiones que haya, cada tabla y clase de entidad se almacena una sola vez en la base de datos. ArcGIS deja cada clase de entidad o tabla en su formato original pero registra los cambios en las tablas a las que se hace referencia como tablas delta.

Los usuarios pueden editar todas las versiones de manera simultánea. Varios usuarios también pueden editar la misma versión al mismo tiempo.

En las versiones de ejemplo más arriba, diferentes editores pudieron editar al mismo tiempo las versiones ProjectA y ProjectB. También es posible que la cantidad de usuarios que realicen cambios en la versión QA sea menor.

Cómo funcionan las versiones y las modificaciones versionadas

Antes de que pueda comenzar a realizar modificaciones versionadas en los datos de cualquier versión, los datasets deben registrarse como versionados.

Tenga en cuenta que registrar un dataset como versionado no es lo mismo que crear una versión. Al crear una versión se crea una especie de "visualización" de la geodatabase que le permite editar los datos versionados y ver los cambios inmediatamente. Otros usuarios conectados a la misma versión verán los cambios cuando actualicen la información. Sin embargo, los usuarios conectados a otras versiones no verán los cambios hasta que los concilie y los publique en la versión anterior. En el ejemplo anterior, una vez que los cambios se devuelven a la versión DEFAULT, se hacen visibles independientemente de la versión a la que esté conectado. Por el contrario, registrar un dataset (una clase de entidad, un dataset de entidad o una tabla) como versionado lo prepara para la edición versionada. Cuando registra un dataset como versionado, se crean dos tablas delta: la tabla A (o Adiciones) para inserciones y actualizaciones y la tabla D (o Eliminaciones) para eliminaciones. Cada vez que actualiza o elimina un registro en un dataset, se agregan filas a una o ambas tablas. Por lo tanto, un dataset versionado consta de la tabla original (denominada la tabla base) más todos los cambios en las tablas delta. La geodatabase mantiene un registro de las versiones a las que estuvo conectado cuando realizó las modificaciones que completaron las tablas delta. Cuando realiza una consulta o visualiza un dataset en una versión, ArcGIS ensambla las filas relevantes de la tabla original y de las tablas delta para presentar una vista sin interrupciones de los datos para esa versión.

Todas las modificaciones realizadas en la clase de entidad o tabla, independientemente de la versión desde la que se realizaron dichas modificaciones, se registran en las mismas tablas delta. En conjunto, todas las filas en las tablas base, A y D representan todas las versiones de la clase de entidad o tabla. Esto quiere decir que cualquier versión hace referencia sólo a un subconjunto de filas de las tres tablas. Entonces ¿cómo recuerda ArcGIS qué filas de las tablas delta pertenecen a cada versión?

Cada fila en las tablas A y D se marca con un identificador entero al que se denomina Id. de estado, que hace referencia al momento en que se agrega una fila a una tabla. Cada vez que edita una versión, se crea un nuevo estado y se agrega una nueva fila a una o ambas tablas delta. Se puede entender a los estados como parte de una estructura de árbol donde cada rama registra la evolución de una versión. Se denomina linaje a la secuencia de estados que registran una serie de cambios desde la tabla base al estado actual de una versión. Cuando visualiza o consulta una versión, ArcGIS consulta el linaje de la versión para obtener los Id. de estado, después obtiene los registros correctos de las tablas A y D.

A medida que se edita una geodatabase, las tablas delta aumentan de tamaño y crece el número de estados. Mientras más grandes sean las tablas y más estados tengan, más datos debe procesar ArcGIS cada vez que se visualiza o consulta una versión. Para mantener el rendimiento de una base de datos, el administrador de ArcSDE debe ejecutar de forma periódica el comando Comprimir para quitar los datos sin utilizar y después el comando Analizar para actualizar las estadísticas de la base de datos. Más información sobre la operación de compresión de la geodatabase

Registrar datos como versionados con la opción mover las ediciones a la base

Cuando registra datos que no participan en redes o topologías como versionados, puede especificar si desea que las modificaciones de la versión DEFAULT se muevan a las tablas base. Si especifica esta opción, los cambios siguen registrándose en las tablas delta. Sin embargo, al guardar, los cambios se mueven de las tablas delta a la tabla base, y no permanecen en las tablas delta.

La especificación de esta opción cuando registra los datos como versionados puede resultar útil, si las modificaciones que está realizando toman sólo unos minutos para completarse y si está conectado a una geodatabase versionada con una aplicación de terceros.

Las aplicaciones de terceros generalmente se configuran sólo para consultar la tabla base, no pueden ver las tablas delta. Si utiliza el versionado y no elige mover las modificaciones a la tabla base, estas aplicaciones no verán las modificaciones realizadas en otras versiones que no han sido conciliadas y publicadas en la versión DEFAULT. Tenga en cuenta que cuando edita versiones que no son la DEFAULT, los cambios se registran en las mismas tablas delta. Cuando guarda, los cambios permanecen en las tablas delta. Sin embargo, cuando se fusionan los cambios en la versión DEFAULT, éstos se mueven de las tablas delta a las tablas base. Cuando se fusionan los cambios a versiones que no son la DEFAULT se mantienen los cambios en las tablas delta, tal como si no hubiera especificado la opción de mover las modificaciones a la base.

Permisos y edición de una versión

El propietario de una versión (la persona que la crea) puede establecer permisos para una versión con el fin de restringir quienes pueden verla y editarla. Las opciones de permiso son privada (sólo el propietario puede ver y editar los datasets de la versión), protegida (cualquier usuario puede ver los datasets de la versión, pero sólo el propietario puede editarlos) y pública (cualquier usuario puede ver y editar los datasets, siempre que cuente con los permisos sobre los mismos).

Como puede ver en el siguiente cuadro de diálogo Administrador de versiones, la versión DEFAULT está protegida y las otras versiones son públicas.

Sugerencia:Consulte Crear versiones y establecer permisos para obtener más información sobre permisos de versión.

Para editar los datos en una versión específica en ArcGIS, conéctese a una versión específica y agregue datos que han sido registrados como versionados en ArcMap.

Sugerencia:También puede alternar las versiones a las que están conectados en ArcMap. Consulte Cambiar versiones en ArcMap para obtener más información.

Por defecto, todas las sesiones de edición en ArcMap son versionadas. Por lo tanto, si tiene datos versionados en su mapa, puede comenzar la edición apenas abra una sesión de edición. Para abrir una sesión de edición, haga clic en Iniciar la edición en la lista desplegable Editor de la barra de herramientas Editor.

Las modificaciones realizadas a cada versión se aplican sólo a esa versión. La excepción son los cambios de esquema. Cuando cambia el esquema en una versión, por ejemplo, si agrega un nuevo campo a la tabla, el cambio se aplica a todas las demás versiones.

Una vez terminada la edición, debe conciliar los cambios y publicar en la versión anterior.

Conciliar y publicar los cambios

La conciliación y la publicación integran los cambios a cualquier versión anterior de la versión en la que está trabajando, como la versión principal o DEFAULT. Cuando realiza la conciliación, se comparan los cambios en la versión que está editando con la versión a la que los quiere fusionar.

Cuando modifica datos en una versión, no se aplican bloqueos a los datos. Si dos editores trabajan en los mismos datos, ya sea en la misma o en diferentes versiones, se pueden producir conflictos. Ocurre un conflicto cuando una fila es diferente en las dos versiones que se están comparando. El proceso de conciliación muestra cada conflicto y permite elegir la representación de la fila que se desea conservar.

En la práctica, la edición de conflictos debería ser poco frecuente porque el volumen de modificaciones es pequeño en comparación con la cantidad de datos geográficos involucrados. En flujos de trabajo diseñados correctamente, el coste de conciliar conflictos es menor en comparación con el ahorro de no tener que bloquear o verificar entidades durante la transacción.

Una vez finalizada la conciliación, puede publicar los cambios. De esta manera, se aplican las modificaciones que realizó en la otra versión. Si ya no necesita la versión desde la que realizó la publicación, puede eliminarla. O bien, puede seguir editándola y volver a conciliar y publicar los cambios.

Basado en los privilegios asignados a las versiones del ejemplo QA/Project, un flujo de trabajo lógico de conciliación y publicación iría desde las versiones de proyecto a las versiones de QA y por último a la versión DEFAULT.

Versiones: Un ejemplo

Para ilustrar cómo se pueden utilizar las versiones, siga esta situación de un servicio hídrico municipal. El servicio hídrico tiene una geodatabase de entidades que representan el estado actual de todas las tuberías de agua, válvulas, bombas y otros componentes del sistema de agua. El servicio necesita agregar una extensión de línea nueva al sistema de agua.

El servicio crea una nueva versión desde la versión DEFAULT llamada proyecto de Extensión, para contener el diseño de la nueva extensión. Sin embargo, el personal del servicio no está seguro sobre si elegir un diseño de tubería de 16 o de 24 pulgadas para la nueva extensión. Entonces, desde la versión proyecto de Extensión, crean una versión para estudiar el diseño de 16 pulgadas y otra para estudiar el diseño de 24 pulgadas.

Finalmente, descubren que la tubería de 24 pulgadas servirá para la demanda de agua proyectada para 12 años más y que se justifica el coste mayor inicial de construcción. El diseño de 24 pulgadas queda aprobado, se verifica la precisión y se publica en la versión de proyecto de Extensión.

Algunos meses más tarde, se finaliza la construcción de la extensión de línea nueva. Para actualizar la versión publicada de la base de datos, se revisa la precisión de la versión de proyecto de Extensión, se concilia y se publica en la versión DEFAULT.

Temas relacionadosEscenarios de versión

Copyright © 1995-2011 Esri. Todos los derechos reservados.

Vocabulario esencial para versionadoResource Center » Biblioteca para profesionales » Administración de datos » Administrar geodatabases » Transacciones y versiones de

geodatabase » Trabajar con datos versionados

Los siguientes son términos comunes que encontrará en la documentación sobre versionado:

Término Descripción

versión de la geodatabase

La versión de la geodatabase representa una instantánea en el tiempo de la geodatabase de ArcSDE completa. Permite editar las geodatabases para aislarlas y así evitar que se bloqueen, incluso si las sesiones de edición se prolongan durante largos períodos de tiempo.

Las versiones se crean a partir de versiones existentes. Esto genera un linaje con una versión principal y versiones secundarias.

versión DEFAULT

La versión DEFAULT es la versión original de la geodatabase de ArcSDE. Todas las demás versiones de la geodatabase son descendientes de la versión DEFAULT.

versión principal La versión principal es la versión de la geodatabase desde la que se genera la otra versión. No se puede eliminar una versión principal si esta otra versión todavía existe.

versión secundaria

Una versión secundaria es la versión de la geodatabase que se creó a partir de la versión principal. Cuando se crea inicialmente, la versión secundaria contiene los mismos datos y tiene el mismo estado que la versión principal. Después de que se realizan las ediciones en la versión secundaria, se publican nuevamente en la versión principal.

árbol de versiones

Un árbol de versiones es un gráfico organizativo de versiones de geodatabase relacionadas. Similar a un árbol genealógico, un árbol de versiones muestra cómo se relacionan las versiones, qué versiones son las principales y cuáles las secundarias, y permite rastrear el origen de una versión secundaria en particular desde de la versión DEFAULT.

registrar como versionada

Al registrar una clase de entidad como versionada, se crea una tabla de "adiciones" y "eliminaciones". Estas tablas registran las ediciones realizadas en el dataset y permiten editar un dataset sin bloquear a otros usuarios que quieran acceder a él o editarlo.

Cuando registra un dataset como versionado, puede registrarlo como completamente versionado (opción predeterminada) o con la opción para mover las ediciones a la base.

tabla de adiciones

La tabla de adiciones almacena todos los registros insertados o actualizados en un dataset versionado.

tabla de borrados

La tabla de eliminaciones registra todos los elementos eliminados de un dataset versionado. También contiene registros de registros actualizados, ya que una actualización equivale a un registro eliminado que fue reemplazado por un registro modificado.

La tabla de eliminaciones también se conoce como la Tabla D.

tablas delta Las tablas de adiciones y eliminaciones para un dataset se conocen como las tablas delta ya que almacenan cambios realizados en el dataset.

tabla base La tabla base es la tabla fundamental de una clase de entidad. Contiene todos los atributos no espaciales, y, si utiliza un tipo de geometría SQL, también el atributo espacial.

La tabla base de términos se utiliza para diferenciar esta tabla fundamental de otras tablas secundarias, como las tablas delta, las tablas XML de ArcSDE o las tablas f y s utilizadas por el tipo de almacenamiento de geometría binaria de sde.

Cuando observe una clase de entidad a través de la interfaz de usuario del sistema de administración de bases de datos, verá la tabla base. Por ejemplo, si la geodatabase contiene una clase de entidad versionada llamada prj_sites, encontrará una tabla llamada prj_sites en la base de datos. Esa tabla es la tabla base.

Las tablas base también se conocen como tablas de negocios.

mover las ediciones a la base

Esta opción está disponible cuando se registran los datos como versionados. Permite mover inmediatamente las ediciones realizadas en la versión DEFAULT de la geodatabase desde las tablas delta hasta las tablas base.

La especificación de esta opción cuando registra los datos como versionados puede resultar útil, si las modificaciones que está realizando toman sólo unos minutos para completarse y si está conectado a una geodatabase versionada con una aplicación de terceros.

No puede utilizar la opción para mover las ediciones a la base en datasets que contienen una topología o red, que estén archivados o participen en una replicación.

estado El estado de una geodatabase es un registro de un cambio realizado en la versión. Cada vez que edite una entidad dentro de una versión, se creará un nuevo estado.

linaje de estado o árbol de estado

Un linaje de estado o árbol de estado es una secuencia de estados, que comienza con el estado inicial y termina con el estado actual. Representa una serie de cambios realizados en la geodatabase. Cada rama en el árbol o linaje registra cómo evolucionó la versión.

Cuando visualiza o consulta una versión, ArcGIS consulta el linaje de la versión para obtener los Id. de estado, después obtiene los registros correctos de las tablas A y D.

versión de edición

La versión de edición es la versión secundaria que está actualizando.

En la base de datos, la versión de edición es un conjunto de cambios de estados realizados durante la sesión de edición. Durante el proceso de conciliación, este linaje de estados se compara con el linaje de estados de la versión de destino (principal) para detectar conflictos.

versión de destino

La versión de destino es el linaje de estados de la versión principal contra la que se concilian las ediciones.

conciliar El proceso de conciliación es parte del flujo de trabajo de edición de versionado que compara los linajes de estados de la versión de edición y de la versión de destino para buscar conflictos entre ellas. Los conflictos aparecen cuando las ediciones contradicen las modificaciones realizadas por otro usuario en la versión de destino.

Puede establecer reglas para definir conflictos (sin importar si los conflictos son cambios realizados en una fila o cambios realizados en una columna) y el comportamiento predeterminado para la resolución de conflictos (sin importar si tiene prioridad la versión de edición o la versión de destino).

La conciliación sólo actualiza la versión de edición para que ArcGIS pueda verificar los conflictos; no fusiona los cambios con la versión de destino. Debe revisar y resolver cualquier tipo de conflicto detectado durante el proceso de conciliación antes de fusionar (publicar) los cambios con la versión de destino.

publicar El proceso de publicación fusiona los cambios de la versión de edición con la versión de destino.

La operación de envío solo se puede completar si la versión objetivo no se ha modificado desde que se completó la operación de conciliación. Si la versión de destino se ha modificado mientras tanto, tendrá que conciliar de nuevo antes de enviar.

comprimir La operación de compresión se realiza en geodatabases versionadas. Su objetivo principal es quitar los estados a los que no se hace referencia y las filas de las tablas delta asociadas a ellos y mover las entradas en las tablas delta que son comunes a todas las versiones a las tablas base. Esto reduce la cantidad de datos que la base de datos tiene que revisar en cada consulta de versión y, de ese modo, mejora el rendimiento de consulta y tiempo de respuesta del sistema.

Las geodatabases versionadas, que se editan en forma activa, se deben comprimir con frecuencia (todos los días o semanalmente, según el volumen de edición). Mientras más tiempo pase entre las operaciones de compresión, más tiempo tomará para completar la misma.

Temas relacionados

La operación de compresión y las geodatabasesRegistrar datos como versionadosUn paseo introductorio por el versionadoUn paseo introductorio por la conciliación de una versión

Copyright © 1995-2011 Esri. Todos los derechos reservados.

Escenarios de versiónResource Center » Biblioteca para profesionales » Administración de datos » Administrar geodatabases » Transacciones y versiones de

geodatabase » Trabajar con datos versionados

Este tema presenta la aplicación del versionado, es decir, cómo se puede aplicar esta tecnología dentro de la organización, e ilustra las configuraciones de versión que están disponibles.

Los flujos de trabajo varían enormemente entre organizaciones. A menudo, se transforman en etapas discretas y cada etapa requiere la asignación de un conjunto específico de recursos y reglas de negocios. Generalmente, cada etapa del proceso total representa una unidad de trabajo discreta, como una orden de trabajo. Para administrar cada orden de trabajo, puede crear una versión separada aislada y modificarla. Una vez que esté conforme con el trabajo terminado, puede integrar los cambios en la versión publicada de la base de datos. Trabajar con versiones de esta manera permite tener en cuenta los procesos más básicos del flujo de trabajo así como los más complejos.

En general, se utiliza la edición concurrente de la base de datos publicada, con varios editores que modifican la versión DEFAULT, o alguna combinación de las otras configuraciones. La comprensión de los requisitos organizacionales y de negocios y la evaluación de las ventajas y desventajas de cada configuración, ayudará en el momento de elegir cual es la mejor opción para la organización.

Para mantener la simplicidad y tener en cuenta las consideraciones de la administración de geodatabases, se recomienda mantener un árbol de versiones plano o tener varios editores que editen en forma concurrente la versión DEFAULT.

Edición simultánea de la base de datos publicada

Muchos usuarios pueden editar la misma versión simultáneamente, de modo que la manera más simple de admitir la edición multiusuario es permitir que muchos editores editen directamente la versión DEFAULT.

Cuando cada editor empieza a editar la versión DEFAULT, en la sesión de edición se crea automáticamente una versión temporal, sin nombre. Esta versión temporal solo es accesible al editor actual. Cuando el editor guarda su trabajo o finaliza la sesión de edición, los cambios registrados en la versión temporal se envían a la versión DEFAULT.

Si otro usuario ha editado la versión DEFAULT desde que se inició la edición, al guardar el trabajo, ArcGIS concilia y envía los cambios automáticamente. Se le notifica que la versión ha cambiado y debe guardarse de nuevo para aceptar los cambios realizados por otros editores. Puede evitar este mensaje de advertencia habilitando la conciliación automática en el cuadro de diálogo Opciones de ArcMap. Tanto si evita este mensaje como si no, si hay conflictos deberá resolverlos con el cuadro de diálogo de resolución de conflictos antes de poder guardar correctamente las ediciones.

Más información sobre configuración para guardar los datos

Más información sobre cómo resolver conflictos de datos

Ventajas:

Esta estrategia admite bien las modificaciones simples de la base de datos, porque los usuarios no tienen que crear nuevas versiones para editar los datos. Esto es adecuado cuando las unidades de trabajo son bastante pequeñas o cuando no se requieren alternativas de diseño persistentes.

Si no hay ningún conflicto, las ediciones guardadas se envían directamente a la versión DEFAULT.

Inconvenientes:

La versión DEFAULT está cambiando constantemente y es vulnerable a modificaciones accidentales o no autorizadas; por consiguiente, es posible que el administrador de bases de datos tenga que crear copias de seguridad de la base de datos con más frecuencia.

No se admiten las transacciones de larga duración ni la creación de versiones de diseño alternativo que abarquen muchas sesiones de edición.

Solo puede haber una operación de conciliación activa por geodatabase en un momento dado. Si hay frecuentes operaciones de conciliación y envío desde varias sesiones de edición, es posible que los editores que guarden sus cambios tengan que esperar a que se completen los procesos activos de conciliación y envío. En un geodatabase grande, multiusuario, es mejor evitar las situaciones donde muchos usuarios concilian y envían a una versión común. La conciliación y el envío bloquean exclusivamente la versión; mientras este bloqueo está vigente, los demás usuarios no pueden completar sus tareas.

Dado que todas las operaciones de conciliación se emprenden automáticamente, esta estrategia no admite procesos de conciliación por lotes. La operación de conciliación por lotes se trata en el temaConciliación y envío automáticos.

Varios múltiples

Si está administrando varios proyectos u órdenes de trabajo, necesitará un enfoque más estructurado a la administración del flujo de trabajo. Es posible mantener unidades de trabajo discretas que impliquen muchas sesiones de edición y abarquen varios días, semanas o meses sin que ello afecte a la versión DEFAULT. Ejemplos de estas unidades de trabajo discretas podrían ser un esquema de mejora de carreteras, la instalación de un nuevo servicio telefónico, o un proyecto de mantenimiento continuado para una conducción de gas.

Cuando se inicia una orden de trabajo o un proyecto, se crea una versión como un elemento secundario de la versión DEFAULT. Uno o más editores pueden trabajar en esta versión hasta que se complete la orden de trabajo o el proyecto. Cuando se completan todas las modificaciones de una versión, el editor o el administrador de ArcSDE concilia con la versión DEFAULT, resolviendo los conflictos que surjan. A continuación, envía las modificaciones a la versión DEFAULT, integrando las modificaciones en la base de datos publicada. En este punto, se puede quitar la versión secundaria.

Los permisos de acceso de usuario a la versión DEFAULT pueden restringirse para forzar este flujo de trabajo y asegurarse de que no se modifique la versión DEFAULT. El administrador de ArcSDE podría establecer el permiso de la versión DEFAULT en protegido; esto permite que los usuarios continúen viendo la versión DEFAULT, pero restringe su nivel de acceso a solo lectura. Cualquier editor que desee modificar los datos debe crear una nueva versión.

Si los usuarios de solo lectura no necesitan la capacidad de ver los cambios tan pronto como se envíen a la versión DEFAULT, podría crear una versión protegida, estática, a partir de la versión DEFAULT para que la utilicen. Esta versión se debe crear una vez comprimida la base de datos y reconstruidos los índices y las estadísticas. Haciendo esto se asegura de que todas las filas necesarias para representar la versión de solo lectura se almacena en en la tabla básica y que la base de datos rinda de manera óptima. En este escenario, no se realiza ningún cambio en la versión de los usuarios de solo lectura de la base de datos (FastTrak en la ilustración siguiente), de modo que no es necesario ejecutar las consultas de diferencias de versión, y las estadísticas y los

índices de la base de datos no quedan obsoletas ni se fragmentan. Después de cada compresión programada de la base de datos, esta versión se recrearía, permitiendo el acceso de los usuarios de solo lectura a los cambios realizados desde la última compresión de la base de datos.

Ventajas:

Simplicidad: cada unidad de trabajo se segrega lógicamente por versión.

Se admiten las transacciones de larga duración que abarcan muchas sesiones de edición, así como la creación de diseños alternativos, permitiendo que los editores desarrollen propuestas sin afectar a la base de datos de producción.

Al crear una nueva versión a partir de la versión DEFAULT, se protege la vista de producción de la base de datos frente a modificaciones involuntarias. Los proyectos de trabajo individuales se integran con la base de datos de producción cuando se completan.

Se admiten los procesos de conciliación y envío por lotes.

Inconvenientes:

Como ocurre con cualquier configuración de versión multinivel, cuantas más filas se mantengan en las tablas delta de versión, mayor será el impacto potencial sobre el rendimiento de las consultas de versión. Esta sobrecarga se puede minimizar comprimiendo la base de datos periódicamente y actualizando las estadísticas del DBMS.

Proyectos múltiples con subproyectos

Los proyectos complejos requieren una estructura de flujo de trabajo más elaborada que la proporcionada por los enfoques de edición simultánea o de varios proyectos. Estos proyectos se pueden dividir a su vez en varias unidades funcionales o geográficas, a partir de las cuales se desarrolla una jerarquía de versiones más compleja. Por ejemplo, un proyecto para diseñar y construir un nuevo centro comercial podría tener distintas fases de construcción subdivididas en secciones este y oeste, o subdivididas por actividades de construcción, tales como edificación, instalación de servicios o paisajismo.

Para proyectos grandes que implican diferentes equipos y numerosas unidades discretas de trabajo, un árbol de versiones con varios niveles es una manera efectiva de organizar el flujo de trabajo. Los equipos que trabajan en diferentes aspectos del mismo proyecto crean su propia versión para mantener una vista privada de sus actualizaciones. Una vez completado el proyecto, las versiones se pueden conciliar y enviarse de vuelta a la versión DEFAULT, y se convierten en una parte integral de la base de datos publicada.

Ventajas:

Admite proyectos complejos

Admite transacciones de larga duración que abarquen muchas sesiones de edición

Admite procesos automatizados de conciliación y envío por lotes

Inconvenientes:

Debe conciliar y enviar las versiones en orden, empezando por las versiones más lejanas eliminadas de la versión DEFAULT y retrocediendo. En otras palabras, las versiones secundarias de tercer nivel de la versión DEFAULT se deben enviar a sus versiones primarias, que son versiones secundarias de segundo nivel de la versión DEFAULT. Estas versiones secundarias de segundo nivel se pueden enviar entonces a las versiones secundarias de primer nivel de la versión DEFAULT. Finalmente, las versiones secundarias de primer nivel se pueden enviar a la versión DEFAULT.

Una vez que se envía cada versión secundaria a su versión primaria respectiva, la versión secundaria se puede eliminar.

La conciliación y el envío solo pueden tener lugar entre versiones en la ruta de acceso directa; no es posible conciliar y enviar a través de rutas de versión.

Mantener un árbol de versiones complejos tiene algunos costes de rendimiento asociados: cuantas más filas haya en las tablas delta de la versión, mayor será el impacto potencial sobre el rendimiento de las consultas.

Proyectos escalonados

Muchos proyectos evolucionan a través de un grupo prescrito o regulado de etapas que requieren aprobaciones de ingeniería, administrativas o legales antes de pasar a la etapa siguiente. Por ejemplo, dentro del dominio de los servicios, algunas etapas comunes son trabajando, propuesto, aceptado, construcción y construido. Este proceso en particular es esencialmente cíclico: una orden de trabajo se asigna inicialmente a un ingeniero y se modifica con el tiempo a medida que el proyecto evoluciona a través de varias etapas, hasta la integración completa con la base de datos de producción.

En este enfoque, se crea una versión para representar cada etapa de este proceso: diseño inicial o versión propuesta, una versión aprobada y una versión para la fase de la construcción. A medida que el proyecto avanza a través de diversos hitos de proyecto, cada etapa se revisa y se aprueba y, a continuación, es reemplazada por la siguiente versión hasta que se alcanza y se completa la última etapa. Las versiones anteriores se puede mantener como referencia histórica o se pueden eliminar, según sea necesario.

Cuando el proyecto ha finalizado, la versión construida se puede conciliar y enviar directamente a la versión DEFAULT, sin tener que conciliarse ni enviarse con las versiones anteriores del linaje.

Ventajas:

Este método es adecuado para proyectos que evolucionan a través de una serie de etapas, donde cada etapa se debe aislar como una unidad de trabajo distinta.

Como ocurre con todas las demás configuraciones de varios niveles, este flujo de trabajo permite a los editores desarrollar propuestas y alternativas de diseño sin afectar a la base de datos de producción.

Los cambios se pueden enviar directamente a DEFAULT, que elimina la sobrecarga de enviar cambios progresivamente subiendo por el árbol de versiones hasta la versión DEFAULT.

Inconvenientes:

No conveniente para los procesos de conciliación y envío por lotes

Archivar

Un requisito clave para muchos proyectos es la preservación de varios estados de la base de datos a medida que cambia con el tiempo. Algunas de las consultas típicas que una geodatabase puede tener que admitir son las siguientes:

¿Qué aspecto tenía la base de datos en un momento determinado?

¿Cómo ha cambiado una entidad determinada con el tiempo?

Dado que una entidad se quitó de la base de datos en una determinada fecha, ¿qué entidades existen actualmente conde estaba la entidad eliminada?

Un requisito común para mantener un registro histórico es conservar un archivado de la versión DEFAULT, dado que habitualmente representa la versión publicada de la base de datos. Los cambios en DEFAULT puede producirse como resultado de ediciones en DEFAULT o de la conciliación y el envío de cambios desde otras versiones. Una geodatabase se puede configurar para que registre estos cambios automáticamente. Esta funcionalidad está integrada en la geodatabase; no se necesita ningún modelado de datos ni ninguna personalización de la aplicación adicional para admitir el archivado automatizado.

Algunos proyectos requieren el archivado de una versión distinta de DEFAULT. Dado que una versión representa el estado de su versión primaria en el momento que se crea, puede crear una versión con el único propósito de registrar el aspecto que tenía su versión primaria en un momento determinado. Por ejemplo, podría crearse una nueva versión histórica a partir de la versión de diseño. Cuando la versión de diseño se conciliara y se enviara a su versión primaria, la versión histórica permanecería como un registro del diseño en un momento determinado.

Para obtener más información detallada sobre el archivado, vea El proceso de archivado.

Administración de datos distribuidos

Algunos proyectos requieren que dos o más oficinas distantes trabajen sobre los mismos datos. Cada oficina requiere acceso local a la base de datos y, por lo tanto, cada una crea una copia de la base de datos. Cuando se hace un cambio en los datos de una ubicación, el cambio también se debe aplicar a los datos de la otra ubicación. Para

mantener las copias de las bases de datos sincronizadas, los sitios pueden transferir entre sí los cambios de manera programada. Esta capacidad se conoce como replicación de geodatabases.

La replicación también permite llevar al campo un subconjunto de la geodatabase y editarla sin conexión; es un requisito común para los equipos de mantenimiento de campo. Al volver a la oficina, se puede volver a conectar a la red y combinar los cambios en la base de datos de producción.

La replicación también es útil para cualquiera que tenga que editar datos a través de una red lenta por cualquier otro motivo. En este caso, la replicación permite extraer un subconjunto de los datos al equipo local, para poder trabajar sobre ellos sin tener que comunicarse a través de la red. Una vez finalizada la edición, puede transferir los cambios a través de la red, combinándolos de vuelta en la base de datos de producción. Para obtener más información, vea Escenarios que utilizan datos distribuidos.

Temas relacionadosUn paseo introductorio por el versionado

Copyright © 1995-2011 Esri. Todos los derechos reservados.

Un recorrido rápido por el registro y la anulación del registro de los datos como versionadosResource Center » Biblioteca para profesionales » Administración de datos » Administrar geodatabases » Transacciones y versiones de

geodatabase » Trabajar con datos versionados » Registrar y dar de baja datos como versionados

Este tema se aplica sólo a ArcEditor y ArcInfo.

Los datasets de la geodatabase de ArcSDE se pueden registrar como versionados sin la opción de trasladar las ediciones a la base, registrarse como versionados con la opción de trasladar las ediciones a la base, o no registrarse como versionados. De forma predeterminada, al agregar o crear un dataset en una geodatabase de ArcSDE, los datos no se registran como versionados. Para ver una introducción a estas opciones, veaEstrategias de mantenimiento de datos.

Nota:Solo el propietario de los datos puede registrar o anular el registro como versionados.

Registrar como versionados sin la opción de trasladar las ediciones a la base

Registrar los datos como versionados sin la opción de trasladar las ediciones a la base permite aprovechar toda la funcionalidad de la edición con control de versiones. Esto incluye lo siguiente:

Deshacer y rehacer ediciones.

Realizar ediciones de transacción larga.

Usar versiones con nombre para diseños y proyectos.

Usar el archivado de geodatabases.

Usar la replicación.

Imponer una restricción única sobre la tabla básica de una clase de entidad.

Nota:

Si, al comprimir la base de datos, los cambios escritos en la tabla básica de las tablas delta incumplen la restricción, se producirá un error en la compresión y tendrá que quitar la restricción, o averiguar qué fila incumplió la restricción y corregir el error.

Sin embargo, antes de registrar los datos, considere que hay ciertas operaciones de ArcGIS que no se pueden realizar sobre los datos registrados como versionados. Estas operaciones son las siguientes:

Crear una topología.

Agregar o quitar clases de entidad de una topología.

Agregar o quitar reglas topológicas.

Modificar la tolerancia de cluster o de rangos.

Crear una red geométrica.

Agregar o quitar una clase de entidad de una red geométrica.

Además, al importar una cantidad grande de datos, el rendimiento es mejor si se importa en una clase de entidad o tabla no registrada como versionada.

Si decide registrar un dataset de entidad, una clase de entidad independiente o una tabla como versionados, haga clic con el botón derecho en el árbol de catálogo y haga clic en Registrar como versionada. Esto abre el cuadro de diálogo Registrar como versionada. Deje desactivada la opción de trasladar ediciones a la base y haga clic en Aceptar. Al dejar esta opción desactivada, las ediciones de todas las versiones, incluso DEFAULT, se conservan en las tablas delta.

Cuadro de diálogo Registrar como versionada

Nota para el administrador de bases de datos:

Al registrar un dataset se crean las tablas delta de apoyo: las tablas de adiciones (a) y eliminaciones (d), así como los índices de atributo. Las tablas a y d, y sus índices de atributos, pueden estar entre las más activas de la geodatabase. En este caso, estas tablas se leen durante todas las consultas contra la clase de entidad o tabla. Además, siempre que un usuario realiza una edición, se agrega una fila a una o ambas de estas tablas, de modo que estas tablas crecerán rápidamente en una geodatabase donde haya mucha actividad de edición. Por esta razón, es necesario planear su almacenamiento y compresión periódica para mantener un rendimiento óptimo.

Registrar como versionados con la opción de trasladar las ediciones a la base

Registrar los datos como versionados con la opción de trasladar las ediciones a la base permite realizar con los datos ediciones con control de versiones. Aunque el registro de datos de esta manera se diseñó para permitir ediciones sin control de versiones por parte de aplicaciones de terceros, no es posible realizar ediciones sin control de versiones a través de ArcGIS.

Tenga presente que además de las operaciones de ArcGIS que no se pueden realizar cuando los datos se registran como versionados (como se ha descrito anteriormente), si registra los datos como versionados y especifica la opción de trasladar las ediciones a la base, no podrá hacer lo siguiente:

Editar clases de entidad que participen en una topología o en una red geométrica.

Archivar datos con la funcionalidad de archivo integrada en la geodatabase.

Usar la replicación de geodatabases.

Si decide registrar un dataset de entidad, una clase de entidad independiente o una tabla como versionados con la opción de trasladar las ediciones a la base, haga clic en el elemento en cuestión con el botón derecho en el árbol de catálogo y haga clic en Registrar como versionada para abrir el cuadro de diálogo Registrar como versionada. Active Registrar los objetos seleccionados con la opción de mover ediciones a la base. Activar esta opción provoca que las ediciones que se hayan guardado en la versión DEFAULT, ya se hayan realizado directamente o se hayan combinado desde otras versiones, se guardarán en las tablas de negocio. Las ediciones en otras versiones permanecen en las tablas delta al guardar.

Opción Mover a base activada

Esta opción está disponible solo para entidades simples, aquellas que no participan en una topología ni en una red geométrica. Por consiguiente, si abre el cuadro de diálogo Registrar como versionada y descubre que no está disponible la casilla de verificación de trasladar las ediciones a las tablas base, esto significa que el dataset contiene una topología o una red geométrica.

Mover a base deshabilitado

No registrados como versionados o anular el registro de datos como versionados

Como ya se ha mencionado, los datos no están registrados inicialmente como versionados. Si permanece en este estado, puede realizar ediciones sin control de versiones, así como crear o modificar una topología o una red geométrica.

Si ya ha registrado una clase de entidad como versionada y necesita realizar alguna de las operaciones anteriores, deberá anular el registro de la clase de entidad como versionada. Al anular el registro de una clase de entidad, las tablas delta se suprimen de la base de datos; esto significa que todas las ediciones realizadas con control de versiones pero no publicadas se perderán. Para evitar la pérdida de estas ediciones, comprima todas las ediciones en la tabla base antes de anular el registro de los datos o comprímalas en la versión DEFAULT desde el cuadro de diálogo Dar de baja como versionada. El software le solicita que comprima las ediciones en la tabla base al intentar anular el registro de una clase de entidad como versionada.

De forma predeterminada, el comando Dar de baja como versionado no está presente en el menú contextual del dataset.

Para evitar la necesidad de anular el registro de clases de entidad, intente aplicar toda la topología y todo el comportamiento de la red geométrica a la geodatabase antes de registrar datos. Pruebe la topología y la red geométrica en una geodatabase personal o en un servidor de producción para asegurarse de que no pierde ninguna regla. Esto puede ahorrarle tener que anular el registro de clases de entidad más adelante en producción.

Copyright © 1995-

egistrar datos como versionadosResource Center » Biblioteca para profesionales » Administración de datos » Administrar geodatabases » Transacciones y versiones de

geodatabase » Trabajar con datos versionados » Registrar y dar de baja datos como versionados

Este tema se aplica sólo a ArcEditor y ArcInfo.

Los datos se deben registrar como versionados para utilizar la edición con control de versiones. Al registrar un dataset como versionado, se crean dos tablas delta se crean para realizar el seguimiento de las operaciones de inserción, actualización y eliminación realizadas en los datos. Por consiguiente, un dataset versionado está compuesto de la tabla original (llamada tabla de negocio o básica) más los cambios almacenados en las tablas delta.

Para ver una descripción de la edición con control de versiones, vea la sección Mantenimiento de datos con versiones de Estrategias de mantenimiento de datos.

Precaución:Al registrar un dataset de entidad como versionado, todas las clases de entidad del dataset de entidad se registran como versionados.Sin embargo, si agrega una nueva clase de entidad al dataset de entidad después de haber registrado ya el dataset de entidad como versionado, la nueva clase de entidad no se registrará como versionada. Dado que no es posible registrar clases de entidad individuales dentro del dataset de entidad como versionadas, necesitará registrar de nuevo el dataset de entidad como versionado. Siga los pasos anteriores para hacerlo. Las clases de entidad existentes continúan registradas como versionadas. Al registrar de nuevo el dataset de entidad como versionado, simplemente se registran las nuevas clases de entidad como versionadas. Si no registra el dataset de entidad como versionado después de agregarle nuevas clases de entidad, no podrá editar ninguna de las clases de entidad en el dataset de entidad.

 

Nota:Solo el propietario de los datos puede registrar o anular el registro como versionados.

Pasos:

1. En el árbol de catálogo, haga clic con el botón derecho en un dataset de entidad, una clase de entidad o una tabla.

2. Haga clic en Registrar como versionada en el menú contextual.

Esto abre el cuadro de diálogo Registrar como versionada.

3. Opcional: si está disponible Registrar los objetos seleccionados con la opción para mover ediciones a la base está disponible y desea guardar en las tablas de negocio las ediciones guardadas en la versión DEFAULT, ya de hayan realizado directamente o se hayan combinado desde otras versiones, active Registrar los objetos seleccionados con la opción para mover ediciones a la base.

Vea Decidir cómo registrar los datos para obtener más información sobre la opción de trasladar ediciones a la base.

4. Haga clic en Aceptar.

Copyright © 1995-2011 Esri. Todos los derechos reservados.

Agregar el comando Dar de baja como versionado a ArcCatalogResource Center » Biblioteca para profesionales » Administración de datos » Administrar

geodatabases » Transacciones y versiones de geodatabase » Trabajar con datos versionados » Registrar y dar

de baja datos como versionados

Este tema se aplica sólo a ArcEditor y ArcInfo.

De forma predeterminada, el botón Dar de baja como versionado no está en la barra de herramientas. Para utilizarlo, debe agregarlo al catálogo.

Pasos:

1. Haga clic en Personalizar > Personalizar modo.

2. Haga clic en la ficha Comandos en el cuadro de diálogo Personalizar.3. Haga clic en Herramientas de geodatabase en la lista Categorías.4. Arrastre el comando Dar de baja como versionado de la lista Comandos

a la barra de herramientas Estándar.5. Haga clic en Cerrar en el cuadro de diálogo Personalizar.

Anular el registro de datos como versionadosResource Center » Biblioteca para profesionales » Administración de datos » Administrar geodatabases » Transacciones y versiones de

geodatabase » Trabajar con datos versionados » Registrar y dar de baja datos como versionados

Este tema se aplica sólo a ArcEditor y ArcInfo.

Normalmente, una vez que los datos se registran como versionados, no se retiran del control de versiones. Sin embargo, en algunas ocasiones es necesario anular el registro en el control de versiones. Entre ellas cabe citar:

Crear una topología.

Agregar o quitar clases de entidad de una topología.

Agregar o quitar reglas topológicas.

Modificar la tolerancia de cluster o de rangos.

Crear una red geométrica.

Agregar o quitar una clase de entidad de una red geométrica.

Pasos:

1. Si desea guardar ediciones en todas las versiones, concilie y envíe cada versión de la base de datos contra la versión DEFAULT.

Precaución:

Si no lo hace, puede perder las ediciones realizadas en los datos.

2. Después de enviar, elimine cada versión. Haga clic con el botón derecho en la conexión de base de datos y haga clic en Comprimir.

3. Agregue el comando Dar de baja a ArcCatalog (vea Agregar el comando Dar de baja a ArcCatalogpara obtener instrucciones).

Sugerencia:

También puede utilizar la herramienta de geoprocesamiento Dar de baja como versionado en lugar del comando Dar de baja en ArcCatalog. Vea Dar de baja Versioned para obtener más información.

4. Haga clic con el botón derecho en el dataset de entidad cuyo registro desea anular y haga clic en Dar de baja.

5. Si no completó el paso 1 y desear guardar las ediciones en la versión DEFAULT, active Comprime todas las ediciones en la versión predeterminada en la tabla base.

Precaución:

Esto comprime todas las ediciones versionadas realizadas solo en la versión a la que se está conectado.Si no completó el paso 1 antes de anular el registro pero activóComprimir todas las ediciones en la versión predeterminada en la tabla base, perderá las ediciones realizadas en versiones distintas de la versión a la que se conectó. Si no completó el paso 1 antes de anular el registro y no activó Comprimir todas las ediciones en la versión predeterminada en la tabla base, perderá todas las ediciones de todas las versiones.

6. Haga clic en Aceptar.

Copyright © 1995-2011 Esri. Todos l

Crear permisos de versiones y de configuraciónResource Center » Biblioteca para profesionales » Administración de datos » Administrar

geodatabases » Transacciones y versiones de geodatabase » Trabajar con datos versionados » Administrar

versiones de geodatabases

Este tema se aplica sólo a ArcEditor y ArcInfo.

Puede crear una versión nueva derivada de una versión existente, utilizando ArcCatalog o ArcMap. Al crear una versión, usted especifica el nombre, una descripción opcional y el permiso de la versión. Como propietario de la versión, puede cambiar estas propiedades o eliminar una versión en cualquier momento.

(Para obtener la definición de una versión, consulte Comprender las versiones).

Usted establece el permiso de una versión para protegerla de ser editada o vista por usuarios que no sean el propietario de la versión. Puede establecer uno de tres permisos en una versión:

Private: sólo el propietario o el administrador de ArcSDE puede visualizar la versión y modificar los datos versionados.

Protected: cualquier usuario puede ver la versión, pero sólo el propietario o el administrador de ArcSDE puede editar los datasets para los cuales tiene permiso de lectura/escritura.

Public: cualquier usuario puede ver la versión. Cualquier usuario al que se han otorgado permisos de lectura/escritura (UPDATE, INSERT y DELETE o leer/escribir) en los datasets pueden modificar esos datasets.

Al establecer los permisos de las versiones, tenga en cuenta su estrategia de flujo de trabajo de la versión y las necesidades de los distintos usuarios que trabajan dentro de ese marco. Debe utilizar los permisos de versiones junto con los permisos de datasets para controlar el acceso a los datos.

Al establecer los permisos, preste especial atención a cómo protegerá la versión DEFAULT. La versión DEFAULT es anterior a todas las otras versiones en una geodatabase y, generalmente, representa la versión publicada de una geodatabase. Las entidades o filas que se eliminan de la versión DEFAULT, a pesar de estar grabadas en los archivos delta versionados, no se pueden restaurar a menos que el dataset se dé de baja como versionado (con la suposición de que la base de datos no se ha comprimido de antemano). Al darle de baja a un dataset como versionado, el dataset se restaurará a su configuración en la última comprensión del dataset; sin embargo, se perderán todas las ediciones que no fueron comprimidas. De esa forma, es esencial proteger la versión DEFAULT para prevenir modificaciones o daños accidentales.

Existen tres maneras de proteger la versión DEFAULT:

Si ha elegido una estrategia en la cual los usuarios editan la versión DEFAULT directamente, puede crear una versión nueva de sólo lectura, una versión DEFAULT de archivo. Cualquier entidad que sea eliminada accidentalmente de la versión DEFAULT se podrá restaurar a partir de esta versión según se requiera.

Si ha elegido una estrategia en la cual algunos, pero no todos los usuarios necesitan editar la versión DEFAULT directamente, puede crear versiones nuevas a partir de la DEFAULT para que algunos de los usuarios las editen.

Si ha elegido una estrategia en la cual nadie edita directamente la DEFAULT, el usuario administrativo de ArcSDE debe establecer el permiso de la versión DEFAULT en PROTECTED y no en PRIVATE; PRIVATE evitará que todos los usuarios, excepto el usuario administrativo de ArcSDE, se conecten a la base de datos. Con los permisos establecidos en PROTECTED, cualquier usuario puede ver la versión DEFAULT, pero sólo el usuario administrativo de ArcSDE pueden editar directamente o conciliar y publicar ediciones a partir de otras versiones.

Para leer un escenario de ejemplo de cómo crear versiones y establecer permisos en las versiones, consulteEjemplo de creación de versiones y permisos.

Licencia:Para crear una versión o establecer sus permisos, se necesita una licencia de ArcEditor o ArcInfo.

Pasos:

1. Abra el cuadro de diálogo Administrador de versiones utilizando uno de los siguientes métodos:

En el árbol de catálogo, haga clic con el botón derecho del ratón en una conexión a la geodatabase y haga clic en Versiones.

En ArcMap, haga clic en el botón Administrador de versiones de la barra de herramientas Versionado.

Se abrirá el cuadro de diálogo Administrador de versiones.

2. Para crear una versión nueva, haga clic con el botón derecho del ratón en la versión a partir de la cual desea derivar la versión nueva y haga clic en Nuevo.

De esta manera se abrirá el cuadro de diálogo Nueva versión.

3. Introduzca un nombre para la nueva versión.

Sugerencia:

La longitud del nombre de la versión tiene un límite de 62 caracteres.

4. Escriba una descripción de la versión (opcional).

Sugerencia:

Puede utilizar la descripción de la versión para brindar información adicional con respecto al propósito de la versión. El límite del tamaño de la descripción es de 62 caracteres.

5. Elija el nivel de permiso deseado para la versión: Private, Public o Protected.

6. Haga clic en Aceptar para crear la nueva versión.

Copyright © 1995-20

Ejemplo de creación de versiones y permisosResource Center » Biblioteca para profesionales » Administración de datos » Administrar

geodatabases » Transacciones y versiones de geodatabase » Trabajar con datos versionados » Administrar

versiones de geodatabases

Este tema se aplica sólo a ArcEditor y ArcInfo.

A continuación se describe un escenario en el que una pequeña empresa privada de detectives utiliza el control de versiones para administrar los datos de su geodatabase. Los empleados utilizan los datos para realizar análisis que los ayudan con sus investigaciones. En este escenario se explicará cómo se crean las versiones y se establecen los permisos de las versiones en la empresa.

ConfiguraciónEl administrador de ArcSDE de la empresa crea la versión DEFAULT de la geodatabase al crear la geodatabase. Puesto que se trata de una empresa pequeña, el administrador de ArcSDE es a la vez administrador de bases de datos. Añade cinco usuarios a la base de datos, uno por cada empleado de la agencia que accederá a la geodatabase. Todos los empleados editarán algunos datos y algunos usuarios tendrán que crear nuevos datasets, de modo que el administrador de ArcSDE les concede los permisos que necesitan en la base de datos para editar o crear datos.

Sugerencia:Vea los temas sobre permisos de usuario de la Biblioteca del administrador para obtener más información sobre los permisos.

Una de las empleadas, Maxine, se encarga de cargar y mantener los datos base en la geodatabase. Maxine carga datos (como ortofotografías, direcciones, carreteras y edificios) en la geodatabase. Puesto que Maxine ha cargado los datos, automáticamente tiene permiso para editarlos.

El investigador principal, Angus, creará datasets relacionados con las investigaciones, por ejemplo escenas del crimen e información de los testigos. Frank y Gertrude, otros dos investigadores, serán quienes realicen la mayor parte de la edición de los datasets relacionados con la investigación, de modo que Angus les conceda permisos de edición en estos datasets. Para obtener información sobre cómo establecer permisos de los datasets, vea Conceder y revocar privilegios en datasets.)

Se ha decidido que la agencia utilizará el control de versiones para editar los datos. Con objeto de realizar modificaciones con control de versiones, los datasets se deben registrar como versionados. Únicamente el usuario propietario del dataset (el usuario que lo creó) puede registrarlo como versionado. En consecuencia, Maxine registra los datasets de direcciones, carreteras y edificios como versionados y Angus registra como versionados dichos datasets, como ubicaciones de delitos e información de testigos.

En este momento, solo hay una versión: la versión DEFAULT. Será la versión que se considere versión maestra, o de producción, de los datos. Se crearán otras versiones para que los empleados puedan editar datos sin bloquear los datos de otros usuarios ni impedir que otros usuarios vean datos completos.

Nota:Recuerde, las versiones son como distintas vistas de la geodatabase, no copias de la geodatabase. En la geodatabase solo hay una copia de cada dataset, independientemente del número de versiones que se cree.

Proteger DEFAULT y crear otra versión

Puesto que es la versión de producción, el administrador de ArcSDE desea proteger la versión DEFAULT contra modificaciones erróneas en los datasets existentes. Para hacerlo, el administrador de ArcSDE establece el permiso de la versión DEFAULT en protegido mediante el cuadro de diálogo Propiedades de versión, al que se accede desde el cuadro de diálogo Administrador de versiones del árbol de catálogo o la barra de herramientas Versionado de ArcMap.

Una vez que el administrador de ArcSDE cambia el permiso al valor predeterminado y hace clic en Aceptar, vuelve a estar en el cuadro de diálogo Administrador de versiones. En él crea una nueva versión a partir de la versión DEFAULT.

El administrador da a la nueva versión el nombre de Base y establece su permiso en Público.

Crear una nueva versión denominada Base

En este momento hay dos versiones: DEFAULT y Base.

Todos los empleados se pueden conectar a ambas versiones. Solo el administrador de ArcSDE puede editar datos cuando se conecta a la versión DEFAULT y realizar envíos a la versión DEFAULT. Cuando los empleados se conectan a través de la versión Base, pueden editar los datasets para los que se les hayan concedido los permisos de dataset necesarios.

Utilizar la nueva versiónComo ya se ha indicado, Maxine editará los datos base. Se conectará a la versión Base para editar los datos base, como carreteras, direcciones y edificios. En el siguiente cuadro de diálogo Propiedades de conexión de base de datos espaciales se muestra que Maxine se está conectando a la versión Base en ArcCatalog.

Sugerencia:Para obtener información sobre las conexiones a geodatabases, vea los libros correspondientes en la Biblioteca del administrador.

Cuando Maxine finaliza una serie de modificaciones, el administrador de ArcSDE las comprueba en la versión Base. Si los cambios son correctos, se concilian con la versión DEFAULT para incorporar las modificaciones que hayan realizado en la versión DEFAULT. Puesto que solo Maxine debe estar modificando estos datos, no debería encontrarse ningún conflicto durante la conciliación. En este momento, el administrador de ArcSDE envía los cambios a la versión DEFAULT.

De esta forma, todas las modificaciones de Maxine se incorporan a la versión DEFAULT.

Para obtener información sobre conciliación, resolución de conflictos y envíos, vea los siguientes temas:

Conciliar una versión Revisar conflictos Resolución interactiva de conflictos Enviar cambios

Crear otra versión

Angus necesita tener los datos pertinente a los casos que la empresa investiga. Se conecta a la versión DEFAULT de la geodatabase en ArcCatalog.

A continuación, en el cuadro de diálogo Administrador de versiones, Angus crea una nueva versión a partir de DEFAULT.

La versión se denomina Cases y el permiso se establece en Público. Será la versión principal de las versiones creadas para cada uno de los casos. Angus utilizará esta versión para realizar comprobaciones de control de calidad en todos los datos de los casos antes de que el administrador de ArcSDE los concilie con la versión DEFAULT y los envíe.

En este momento hay tres versiones: DEFAULT, Base y Cases.

Todos los empleados se pueden conectar a las tres versiones. Solo el administrador de ArcSDE puede editar datos cuando se conecta a la versión DEFAULT y realizar envíos a la versión DEFAULT. Cuando los empleados se

conectan a través de la versiones Base o Cases, pueden editar los datasets para los que se les hayan concedido los permisos de dataset necesarios.

Creando versiones a partir de una versión que no sea DEFAULT

Cuando se asigna un caso a un investigador, crea una nueva versión de la versión Cases para añadir los nuevos datos pertinentes al caso.

Estas versiones se establecen en protegidas, de forma que solo el investigador que trabaja en el caso en ese momento puede editar los datasets cuando se conecta a esta versión.

Como puede ver en el cuadro de diálogo Administrador de versiones siguiente, Gertrude ha creado la versión Case1 y Frank creó Case2. Gertrude se conectará a Case1 cuando edite los datasets relacionados con el caso, para añadir los datos relativos a ese caso. De igual forma, Frank se conectará a Case2 y modificará los datasets relacionados con ese caso, añadiendo los datos relativos a su caso. Todos los demás empleados se pueden conectar a estas versiones, pero no pueden realizar ningún cambio a sus datasets, porque las versiones están establecidas en protegidas.

Todas las versiones anteriores se relacionan como se indica a continuación:

Cuando Gertrude finaliza de modificar Case1, concilia los cambios y los envía a Cases. Frank podría estar modificando los mismos datasets, y conciliando y enviando los cambios a Cases, por lo que en este momento existe la posibilidad de que generen conflictos. Una vez revisados y resueltos los conflictos, Gertrude puede realizar su envío a Cases.

Vea los siguientes temas para obtener información sobre conciliación, revisión y envío:

Guardar los cambios de una versión Conciliar una versión Revisar conflictos Resolución interactiva de conflictos Enviar cambios

Angus revisa los cambios en la versión Cases. Si son aceptables, el administrador de ArcSDE enviará los cambios de Cases a la versión DEFAULT.

Una vez terminado el trabajo con Case1, y revisados y enviados los datos a DEFAULT, Gertrude puede eliminar Case1.

Nota:

Es necesario estar conectado como propietario para eliminar una versión. Por ejemplo, Gertrude no podría eliminar la versión Case2.

Así, quedan las siguientes versiones:

Frank seguirá el mismo procedimiento con los cambios realizados a través de Case2 (conciliar, resolver conflictos, enviar a Cases), Angus comprobará su trabajo en la versión Cases, el administrador de ArcSDE enviará los cambios aceptados a DEFAULT y Frank eliminará la versión Case2.

Pasos siguientesUna vez eliminadas las versiones de cada uno de los casos, el administrador de ArcSDE debe comprimir la geodatabase y actualizar las estadísticas de la base de datos. Vea Comprimir una geodatabase de ArcSDE con licencia bajo ArcGIS Server Enterprise para obtener información sobre cómo comprimir una geodatabase versionada y Actualizar las estadísticas de una geodatabase mediante Analyze para obtener información sobre cómo mantener al día las estadísticas utilizadas en la base de datos.

Temas relacionadosCrear permisos de versiones y de configuración

Copyright © 1995-2011 Esri. Todos los derechos reservados.

Cambiar versiones en ArcMapResource Center » Biblioteca para profesionales » Administración de datos » Administrar

geodatabases » Transacciones y versiones de geodatabase » Trabajar con datos versionados » Administrar

versiones de geodatabases

En ArcMap, puede visualizar cualquier versión, cambiar de una versión a otra y visualizar distintas versiones simultáneamente.

Cuando inicialmente agregue datos desde una geodatabase de ArcSDE, los datos vienen desde la versión que haya especificado en el cuadro de diálogo Propiedades de conexión a base de datos. Puede cambiar a la versión que desee visualizar.

Cuando cambie de una versión a otra, todas las clases de entidad cambian desde esa geodatabase actual en el mapa a la versión a la que ha cambiado. Esto simplifica el proceso de visualización de las diferencias entre clases de entidad o la realización de un análisis con dos versiones.

Puede cambiar las versiones tanto desde la barra de herramientas Versionar como desde la tabla de contenido. Los siguientes pasos describen cómo cambiar las versiones desde la tabla de contenido:

Pasos:

1. Haga clic en el icono Mostrar por fuente en la tabla de contenido y haga clic con el botón derecho del ratón en una espacio de trabajo de versión.

Un espacio de trabajo de versión es una conexión de geodatabase de ArcSDE.

2. Haga clic en Cambiar versión.

Se abrirá el cuadro de diálogo Cambiar versión.

3. Haga clic en el menú desplegable Tipo de versión y elija Transaccional o Histórico.

4. Haga clic en una versión en la lista para seleccionarla.5. Haga clic en Aceptar.

La versión que se muestra ahora en el documento de ArcMap es la versión que ha elegido. Esto se refleja en el nombre del espacio de trabajo de versión.

Temas relacionadosUn paseo introductorio por el versionado

Copyright © 1995-2011 Esri. Todos los derechos reservado

ctualizar una versiónResource Center » Biblioteca para profesionales » Administración de datos » Administrar

geodatabases » Transacciones y versiones de geodatabase » Trabajar con datos versionados » Administrar

versiones de geodatabases

Al trabajar en un entorno de edición multiusuario, otro usuario puede modificar clases de entidad al mismo tiempo que usted las está viendo. Por consiguiente, es posible que las clases de entidad que está mostrando en ArcMap queden obsoletas. Para actualizarlas, actualice uno o todos los espacios de trabajo de versión

presentes haciendo clic en el botón Actualizar en la barra de herramientas Versionado.

Nota:El botón Actualizar no está disponible si está editando los datos.

Pasos:

1. Si la barra de herramientas Versionado aun no está abierta, haga clic en Personalizar en el menú principal, seleccione Barras de herramientas y haga clic en Versionado.

Es posible que deba desplazarse hacia abajo en la lista de las barras de herramientas para ver la opción de la barra de herramientas Versionado.

2. Haga clic en el botón Actualizar en la barra de herramientas Versionado.

Copyright © 1995-2011 Esri. Todos los derechos reservados.

El proceso de edición de versiónResource Center » Biblioteca para profesionales » Administración de datos » Administrar geodatabases » Transacciones y versiones de

geodatabase » Trabajar con datos versionados » Editar versiones

Este tema se aplica sólo a ArcEditor y ArcInfo.

A continuación, se explica el proceso de edición de una versión, conciliación, resolución de conflictos y, finalmente, publicación de los cambios en la versión de destino. La versión de destino en la cual realiza la conciliación y publicación puede ser la versión DEFAULT, una versión principal, o cualquier otra versión principal directa.

Por defecto, las sesiones de edición de ArcMap están configuradas para realizar modificaciones versionadas. Esto significa que puede editar los datos que fueron registrados como versionados. Para garantizar que la sesión de edición esté configurada de esta manera, abra el cuadro de diálogo Opciones de edición, haga clic en la ficha Versionado y después marque la opción Editar una versión de una base de datos con la habilidad de deshacer y rehacer.

1. Iniciar la edición

Al iniciar la edición en ArcMap, si el mapa hace referencia a una versión, esa versión se abrirá automáticamente para la edición. Solo se puede editar una versión por sesión de edición, así que si el mapa hace referencia a varias versiones, debe elegir una de ellas para iniciar la edición.

Al iniciar la edición, trabajará con su propia representación de la versión. Los demás usuarios que estén conectados a la misma versión no podrán ver ninguno de los cambios hasta que los guarde.

Suponga que, desde que se empezó a editar una versión, otro usuario ha guardado ediciones en la misma versión. ¿Qué ocurre cuándo se guardan las ediciones? ArcGIS concilia las dos representaciones de la versión. Si hay conflictos, puede resolver inicialmente todos ellos a favor de la sesión de edición o de la representación de la base de datos de la versión. Según las opciones de edición de versiones que establezca en ArcMap, puede revisar los conflictos de uno en uno y resolver cada uno de ellos manualmente con un cuadro de diálogo interactivo, puede decidir no guardar las ediciones realizadas que estén en conflicto con la base de datos, o puede decidir sobrescribir manualmente lo que haya en la base de datos.

Más información sobre el establecimiento de opciones de edición

Puede trabajar con una versión en tantas sesiones de edición como necesite. Cuando haya finalizado la edición y desee combinar los cambios en una versión objetivo, el próximo paso es la conciliación.

2. Conciliación

Desde que comenzó a editar su versión, es posible que la versión de destino haya sido modificada por otros usuarios de manera tal que entró en conflicto con sus modificaciones. La operación de conciliación busca dichos conflictos.

Cómo conciliar una versión

Si la versión de destino fue modificada, la versión que está editando se actualizará con los cambios de la versión de destino. Tal vez note que las entidades en la visualización cambian a medida que los elementos insertados, actualizados o eliminados de cualquier entidad o registro de la versión de destino, se aplican a la sesión de edición.

Durante una operación de conciliación, se detectan conflictos cuando dos o más usuarios editan entidades que están muy próximas entre sí. Hay dos tipos de conflictos:

Los que surgen al guardar ediciones en una versión cuando la misma entidad se ha actualizado en esa versión en una sesión de edición diferente (o se ha actualizado en una sesión de edición y se ha eliminado en otra)

Los que surgen cuando se actualiza la misma entidad tanto en la versión objetivo como en la versión secundaria (o se actualiza en una versión y se elimina en la otra)

En la mayoría de las operaciones de conciliación, no se encontrarán conflictos. Esto se debe a que en la mayoría de las organizaciones, los proyectos y versiones representan áreas geográficas diferentes. Si usted y sus colegas están editando distintas partes de un mapa, no debería haber ningún conflicto.

Conflictos al guardar ediciones en una versión: proceso de conciliación implícita

En el caso del primer tipo de conflicto, diferentes editores cambian la misma entidad en la misma versión de la geodatabase en sesiones de edición diferentes, o la misma entidad se elimina en una sesión de edición y se modifica en la otra. Al guardar las ediciones, ArcGIS detecta cualquier conflicto entre sesiones de edición dentro de esa versión de la geodatabase y resuelve conflictos sobre la base de las preferencias de guardado establecidas en la ficha Versionado del cuadro de diálogo Opciones de Edición. Dado que este proceso de conciliación se realiza sobre la base de configuraciones predeterminadas, es un proceso implícito.

Más información sobre cómo establecer preferencias de guardado

Conflictos al conciliar una versión secundaria y una versión objetivo: proceso de

conciliación explícito

El segundo tipo de conflicto surge al conciliar explícitamente una versión secundaria con su versión primaria haciendo clic en el botón Conciliar de la barra de herramientas Versionado.

Más información sobre la conciliación de una versión

Al realizar la conciliación, aparece un cuadro de diálogo en el cual se decide resolver los conflictos a favor de la versión editada o de la versión objetivo.

3. Revisar conflictos

ArcGIS resuelve inicialmente los tipos de conflictos antes descritos.

Tiene la opción de revisar los conflictos de uno en uno con un cuadro de diálogo interactivo y, si es necesario, realizar cambios. Para cada conflicto, puede decidir si revertir la entidad al estado en que se encontraba al iniciar la sesión de edición, mantenerla tal cual está en la sesión de edición, o reemplazarla por la entidad de la sesión de edición en conflicto o la versión objetivo.

Más información sobre la revisión de conflictos

Nota:Para los conflictos en la misma versión que se encuentran al guardar, si las preferencias de guardado establecen que los cambios se guarden automáticamente en todos los casos, no se le dará la oportunidad de revisar los conflictos; los cambios se concilian sobre la base de la regla de conflicto establecida en la ficha Versionado de Opciones de Edición.

4. Enviar cambios

En este punto, ha terminado de realizar la conciliación y, si había algún conflicto, lo ha revisado. Cuando esté listo para combinar los cambios en la versión objetivo, haga clic en el botón Publicar en la barra de herramientas Versionado. Al realizar el envío, en primer lugar se guarda la sesión de edición actual y, a continuación, la versión objetivo se aplica a la versión actual.

Otros usuarios que lean la versión enviada no verán los resultados del envío hasta que actualicen sus espacios de trabajo versionados. El envío no se puede deshacer, dado que se está aplicando cambios a una versión que no se está editando actualmente.

Más información sobre el envío de cambios

Después de enviar, puede continuar realizando más ediciones en la sesión de edición. Para aplicar estos cambios a la versión objetivo, debe realizar de nuevo los procesos de conciliación, resolución de conflictos y envío.

Si el envío marca el fin del proyecto o de su parte del flujo de trabajo, puede eliminar la versión que ha estado editando con ArcCatalog o ArcMap. Puede eliminar una versión, siempre que se eliminen todas las versiones secundarias. Solo el propietario de la versión o el administrador de bases de datos (el usuario sde o dbo) puede eliminar una versión.

Temas relacionadosConciliar una versiónEnviar cambiosGuardar los cambios de una versiónUn paseo introductorio por la revisión de conflictos

Copyright © 1995-2011 Esri. Todos los derechos reservado

Guardar los cambios de una versiónResource Center » Biblioteca para profesionales » Administración de datos » Administrar geodatabases » Transacciones y versiones de

geodatabase » Trabajar con datos versionados » Editar versiones

Este tema se aplica sólo a ArcEditor y ArcInfo.

Al iniciar la edición de una versión, se empieza trabajando con una representación propia de la versión. Los demás usuarios que estén conectados a la misma versión no podrán ver ninguno de los cambios hasta que los guarde. Mientras está realizando cambios, otros usuarios pueden estar editando la misma versión.

Suponga que, desde que se empezó a editar una versión, otro usuario ha guardado cambios en la misma versión. ¿Qué ocurre cuándo se guardan las ediciones? Cuando pasa esto, ArcGIS debe conciliar las dos representaciones de la versión. El usuario controla cómo tiene lugar esta operación estableciendo lo siguiente:

Cómo se definen los conflictos

Existen las siguientes opciones:Definir los conflictos en este nivel

Detectar los casos en que

Fila Otro usuario edita la misma fila, entidad o entidades relacionadas topológicamente que usted. El conflicto se da aunque se hayan modificado atributos diferentes. Este es el valor predeterminado.

Columna Otro usuario modifica el mismo atributo de una entidad o registro.

Opciones para definir un conflicto

Cómo desea que ArcGIS resuelva los conflictos inicialmente: dando prioridad a su sesión de edición o a la representación en la base de datos

Si decide resolver los conflictos dando prioridad a la sesión de edición, todas las entidades en conflicto de la sesión de edición tienen prioridad sobre las representaciones en la base de datos. Si decide dar prioridad a la base de datos, las representaciones en la base de datos reemplazan a todas las entidades en conflicto de la sesión de edición. Si varios usuarios están modificando la misma versión y se detectan conflictos, la entidad que se guardó en primer lugar reemplaza a la representación de la sesión de edición.

Si desea que se le notifiquen las modificaciones del otro usuario al guardar

Existen estas opciones:

No guardar los cambios automáticamente. De esta forma, se le notifican las modificaciones del otro usuario, pero los cambios no se guardan. Puede revisar los resultados de la fusión antes de guardar los cambios.

Guardar los cambios automáticamente si no hay conflictos. Solo se le notifican los cambios del otro usuario si hay conflictos; si no hay ningún conflicto, se fusionan las dos representaciones de la versión.

Guardar automáticamente los cambios en todos los casos. Con esta opción, nunca se le notifican los cambios del otro usuario, las dos representaciones de la versión se fusionan siempre y los conflictos se resuelven según la regla de resolución de conflictos, que indica si los conflictos se resuelven dando prioridad a la sesión de edición o a la base de datos.

Si hay conflictos, puede resolver inicialmente todos ellos a favor de la sesión de edición o de la representación de la base de datos de la versión. Una vez resueltos inicialmente, puede decidir revisarlos uno por uno, resolviéndolos manualmente con un cuadro de diálogo interactivo. Para obtener más información sobre cómo resolver conflictos manualmente, vea Resolver conflictos.

Puede trabajar con una versión en tantas sesiones de edición como necesite. Cuando haya finalizado la edición y desee fusionar los cambios en una versión de destino, el próximo paso es la conciliación.

Debe establecer cómo se definen y resuelven los conflictos de forma predeterminada, al empezar una sesión de edición; para hacerlo:

Pasos:

1. Para iniciar ArcMap, haga clic en Inicio > Todos los programas > ArcGIS > ArcMap 10.

2. Si la barra de herramientas Editor aún no está abierta, haga clic en Personalizar en el menú principal, seleccione Barras de herramientas y haga clic en Editor.

3. Haga clic en el menú desplegable Editor en la barra de herramientas Editor.4. Haga clic en Comenzar la edición.

De esta forma se inicia una sesión de edición.

5. Haga clic en el menú desplegable Editor en la barra de herramientas Editor.

6. Haga clic en Opciones.7. Haga clic en la ficha Versionado del cuadro de diálogo Opciones de edición.8. Especifique cómo desea definir los conflictos durante la conciliación automática. Para hacerlo, realice uno

de los pasos siguientes: Haga clic en Por objeto (por fila) si desea que se considere como un conflicto todos los cambios

realizados en la misma fila o entidad. Haga clic en Por tributo (por columna) si desea que se considere como un conflicto los cambios

realizados en la misma columna del dataset.9. Especifique cómo resolver todos los conflictos inicialmente. Para hacerlo, realice uno de los pasos

siguientes: Haga clic en A favor de la base de datos si desea que la información de la base de datos tenga

prioridad. Haga clic en A favor de la sesión de edición si desea que sus cambios tengan prioridad.

10. Especifique cómo guardar los cambios después de la conciliación automática. Para hacerlo, realice uno de los pasos siguientes: Haga clic en No guardar cambios automáticamente si no desea que los cambios se guarden

después de la conciliación automática. Puede revisar los conflictos detectados antes de volver a guardar.

Haga clic en Guardar cambios automáticamente solo si no hay conflictos si desea que se le notifiquen los conflictos detectados. Si no hay ningún conflicto, las dos representaciones de la versión se fusionarán sin ningún otro mensaje ni ninguna acción por su parte.

Haga clic en Guardar cambios automáticamente en todas las clases si no desea que se le notifiquen los cambios en conflicto de otro usuario y desea fusionar siempre las dos representaciones de las versiones. Los conflictos detectados se resuelven según la regla de resolución de conflictos.

11. Haga clic en Aceptar.

Temas relacionadosConciliar una versiónUn paseo introductorio por la revisión de conflictos

Copyright © 1995-2011 Esri. Todos los derechos reservados.

tilizar el comando Cambios de versiónResource Center » Biblioteca para profesionales » Administración de datos » Administrar geodatabases » Transacciones y versiones de

geodatabase » Trabajar con datos versionados » Editar versiones

Este tema se aplica sólo a ArcEditor y ArcInfo.

El cuadro de diálogo Cambios de versión proporciona la capacidad de ver los cambios realizados en una versión desde que se creó o se concilió por última vez con una versión antecesora.

El cuadro de diálogo muestra todas las clases modificadas, inserciones, actualizaciones y eliminaciones, y permite verlas en una experiencia similar al cuadro de diálogo interactivo Conflictos.

También permite ver los cambios realizados durante la sesión de edición actual.

No es necesario estar en una sesión de edición para abrir el cuadro de diálogo Cambios de versión y se puede ver los cambios antes de que se concilien las versiones.

El cuadro de diálogo Cambios de versión mostrará todos los cambios realizados en la versión para todas las capas del documento de mapa basado en el espacio de trabajo seleccionado. Si la capa no está actualmente visible, los cambios en esa capa continuarán estando presentes en el cuadro de diálogo. Opcionalmente, los cambios pueden restringirse a los cambios en la extensión de mapa presente activando la casilla de verificación "Filtrar cambios utilizando una extensión de mapa" del cuadro de diálogo Selección de la versión.

Para abrir el cuadro de diálogo, seleccione un espacio de trabajo en la ficha de origen y haga clic en el botón Cambios

de versión   en la barra de herramientas Versionado.

El próximo paso es elegir una versión para comparar los cambios. Las versiones disponibles que se muestran son las de un linaje hereditario con la versión previamente seleccionada en la ficha de origen. Si la versión DEFAULT es la versión

seleccionada, en el cuadro de diálogo se mostrarán todas las versiones accesibles, porque todas son versiones descendientes de la versión DEFAULT.

Si ha iniciado una sesión de edición y elige la versión que está editando actualmente, el cuadro de diálogo presentará todos los cambios realizados durante la sesión de edición actual.

El cuadro de diálogo Cambios de versión muestra el número de cambios realizados en la versión desde el momento en que esta versión y la versión objetivo elegida eran idénticas. El número de cambios se subdivide por clases y, a continuación, se subdivide en las categorías Insertar, Eliminar y Actualizar. Al hacer clic en un número de ObjectID se muestran sus cambios en la ventana de la derecha. Se muestran todos los valores de atributo para las dos versiones que se están comparando y para su antecesor común. Los valores de atributo que se muestran

en negrita significan que se ha realizado un cambio en la versión para ese atributo.

Al hacer clic en el botón Cambiar visualización se abre el Visor de visualización de cambios. Esto permite ver los cambios cuando aparecen en el mapa, así como desplazarse e identificar entidades en la visualización. Puede alternar la visualización para que muestre cualquiera de las dos versiones, así como su antecesor común.

Al hacer clic con el botón derecho en una clase, se muestra un menú con las siguientes opciones:

Destacar: el objeto parpadeará brevemente en rojo en la visualización del mapa.

Zoom a: hace zoom en la visualización del mapa para centrarse en el objeto seleccionado.

Desplazarse panorámicamente a: desplaza el mapa al objeto seleccionado.

Seleccionar: selecciona el objeto en la visualización del mapa.

Temas relacionadosEl proceso de edición de versión

Copyright © 1995-2011 Esri. Todos los derechos reservados.

Un paseo introductorio por la conciliación de una versiónResource Center » Biblioteca para profesionales » Administración de datos » Administrar geodatabases » Transacciones y versiones de

geodatabase » Trabajar con datos versionados » Editar versiones » Conciliar y publicar modificaciones en una versión

Este tema se aplica sólo a ArcEditor y ArcInfo.

Una vez finalizada la edición de una versión, puede fusionar los cambios con cualquier versión anterior a ésta, como la versión principal o DEFAULT.

Para fusionar los cambios, debe realizar una conciliación, resolver los posibles conflictos y publicar. Este tema trata el primer paso de este proceso: conciliación.

Desde que comenzó a trabajar en su versión, es posible que la versión de destino haya sido modificada por otros usuarios de manera tal que entró en conflicto con sus ediciones. El proceso de conciliación busca dichos conflictos. Los conflictos se producen en las siguientes circunstancias:

La misma entidad se actualiza tanto en la versión actual que se está editando como en la versión de destino.

La misma entidad se actualiza en una versión y se elimina en la otra.

Una clase de relación o entidad relacionada topológicamente se modifica en la versión actual que se está editando y en una versión de destino.

Cuando realiza una conciliación, la versión que está editando se actualiza con los cambios de la versión de destino. Es posible que observe que los cambios en las entidades, como inserciones, actualizaciones y eliminaciones de cualquier entidad o registro, de la versión de destino se aplican a su sesión de edición.

Si se producen conflictos, ArcGIS los resuelve inicialmente a favor de la representación de la versión que está editando o de la versión de destino, según su preferencia. Una vez que se resuelven inicialmente los conflictos, puede revisarlos de a uno por vez y realizar los cambios necesarios. Por ejemplo, si un conflicto se resuelve a favor de la versión de edición, puede elegir reemplazarlo a favor de la versión de destino o incluso puede utilizar las herramientas de edición para modificarlo de otra manera.

Nota:La conciliación sólo actualiza la versión de edición para que ArcGIS pueda verificar los conflictos; no fusiona los cambios con la versión de destino. Una vez que termina de conciliar y revisar los conflictos, debe completar el proceso de fusión al publicar los cambiosen la versión de destino.

Requisitos previos

Para poder realizar la conciliación, se deben dar las siguientes condiciones:

Debe ser el único usuario que esté editando la versión que desea conciliar.

No puede haber otro usuario editando la versión de destino. La excepción es si la versión de destino es DEFAULT, ya que puede realizar la conciliación con la versión DEFAULT incluso si otros usuarios la están editando.

Debe poder ver la versión de destino, es decir, puede ser pública o protegida. Si es privada, debe ser el propietario de la versión o el administrador de ArcSDE.

Si utiliza un flujo de trabajo en el que un usuario edita y otro concilia, asegúrese de que el usuario que realice la conciliación posea todos los permisos para todas las tablas y clases de entidad que han sido modificadas en la versión. De no ser así, no se podrá realizar la conciliación. El usuario que realiza la conciliación debe tener todos los permisos para ambos lados de cualquier relación que se haya modificado, incluidas las relaciones simples o compuestas. En este tipo de flujo de trabajo, el usuario que realiza la conciliación también debe tener los permisos de versión necesarios. El usuario que realiza la conciliación debe poder modificar la versión que va a conciliar, lo que significa que ésta debe ser pública, y debe poder ver la versión de destino, es decir, el usuario debe ser el propietario de la versión o ésta debe ser pública o protegida.

El proceso de conciliación

El proceso de conciliación se inicia en la barra de herramientas Versionado. Cuando se abre el cuadro de diálogo Conciliar, debe proporcionar la siguiente información:

La versión de destino

Cómo desea que se definan los conflictos. Cuenta con las siguientes opciones:Defina los conflictos en este nivel

Para detectar estos casos

Fila Un segundo usuario edita la misma fila o entidad, o entidades relacionadas topológicamente, como lo hizo usted. El conflicto ocurre incluso si editó atributos distintos. Esta es la configuración predeterminada.

Columna Un segundo usuario edita el mismo atributo de una entidad o tabla.

Opciones para definir un conflicto

Cómo desea que ArcGIS resuelva inicialmente los conflictos: a favor de la versión que está editando (que se denomina versión de edición) o de la versión de destino. Si decide que se resuelva a favor de esta última, todas las entidades en conflicto en la sesión de edición actual se remplazan por sus representaciones en la versión de destino. Si múltiples usuarios están editando la misma versión y se detectan conflictos, la entidad que se guardó primero reemplaza la representación de la sesión de edición. Si resuelve los conflictos a favor de la versión de edición, todas las entidades en conflicto en la sesión de edición actual tienen precedencia sobre las representaciones en conflicto en la versión de destino.

Nota:No puede utilizar la operación Deshacer para volver atrás una operación de conciliación. Si intenta deshacer una operación de conciliación, aparecerá un mensaje de error porque la operación Deshacer no es compatible. Para deshacer una conciliación, debe salir de su sesión de edición sin guardar los cambios.

Temas relacionadosConciliación y envío automáticosGuardar los cambios de una versión

Copyright © 1995-2011 Esri. Todos los der

Conciliar una versiónResource Center » Biblioteca para profesionales » Administración de datos » Administrar geodatabases » Transacciones y versiones de

geodatabase » Trabajar con datos versionados » Editar versiones » Conciliar y publicar modificaciones en una versión

Este tema se aplica sólo a ArcEditor y ArcInfo.

Cuando realiza una conciliación, la versión que está editando se actualiza con los cambios de la versión de destino. Es posible que observe que los cambios en las entidades, como inserciones, actualizaciones y eliminaciones de cualquier entidad o registro, de la versión de destino se aplican a su sesión de edición.

Nota:La conciliación sólo actualiza la versión de edición para que ArcGIS pueda verificar los conflictos; no fusiona los cambios con la versión de destino. Una vez que termina de conciliar y revisar los conflictos, debe completar el proceso de fusión al publicar los cambiosen la versión de destino.

Para seguir estas instrucciones, se supone que está trabajando en ArcMap y que está conectado a la versión que desea conciliar con la versión anterior.

Sugerencia:Si lo desea, puede automatizar la conciliación y los procesos posteriores. Para obtener más información, consulte Automatización de la conciliación y procesos posteriores.

Pasos:

1. Si la barra de herramientas Versionado aun no está abierta, haga clic en Personalizar en el menú principal, seleccione Barras de herramientas y haga clic en Versionado.

Es posible que deba desplazarse hacia abajo en la lista de las barras de herramientas para ver la opción de la barra de herramientas Versionado.

2. Haga clic en el botón Conciliar en la barra de herramientas Versionado.

3. Haga clic en la versión de destino.

4. Especifique cómo desea que se definan los conflictos.Defina los conflictos en este nivel

Para detectar estos casos

Fila Un segundo usuario edita la misma fila o entidad, o entidades relacionadas topológicamente, como lo hizo usted. El conflicto ocurre incluso si editó atributos distintos. Esta es la configuración predeterminada.

Columna Un segundo usuario edita el mismo atributo de una entidad o tabla.

5. Opciones para definir un conflicto

6. Especifique si todos los conflictos se deben resolver a favor de la versión de edición o la versión de destino.

Si resuelve el conflicto en favor de la versión de destino, todas las entidades conflictivas de la sesión de edición actual se reemplazarán por sus respectivas representaciones en la versión de destino. Si varios usuarios están modificando la misma versión y se detectan conflictos, la entidad que se guardó en primer lugar reemplaza a la representación de la sesión de edición. Si resuelve los conflictos en favor de la versión de edición, todos las entidades conflictivas de la sesión de edición tendrán preferencia sobre las representaciones conflictivas de la versión de destino.

7. Haga clic en Aceptar.

Temas relacionadosConciliación y envío automáticosGuardar los cambios de una versión

Copyright © 1995-2011 Esri. Todos los derechos reservados.

Un paseo introductorio por la revisión de conflictosResource Center » Biblioteca para profesionales » Administración de datos » Administrar geodatabases » Transacciones y versiones de

geodatabase » Trabajar con datos versionados » Editar versiones » Conciliar y publicar modificaciones en una versión

Este tema se aplica sólo a ArcEditor y ArcInfo.

ArcGIS detecta conflictos cuando realiza conciliaciones. Los conflictos se producen cuando

La misma entidad se actualiza tanto en la versión actual que se está editando como en la versión de destino.

La misma entidad se actualiza en una versión y se elimina en la otra.

Una clase de relación o entidad relacionada topológicamente se modifica en la versión actual que se está editando y en una versión de destino.

Si se producen conflictos, ArcGIS los resuelve a favor de la representación de la versión de edición o de la versión de destino, según su preferencia. Una vez que se resuelven los conflictos, puede revisarlos de a uno por vez y realizar los

cambios necesarios. Por ejemplo, si un conflicto se resuelve a favor de la versión de edición, puede elegir reemplazarlo a favor de la versión de destino o puede utilizar las herramientas de edición para modificarlo de otra manera.

Resolución interactiva de conflictos

Cuando realiza una conciliación y se detectan conflictos, puede elegir revisarlos con el cuadro de diálogo interactivo Conflictos. Este cuadro contiene todas las clases de conflicto y las entidades o filas en conflicto. También le permite

Determinar los campos o las filas que están en conflicto.

Ver los conflictos.

Resolver los conflictos designando la representación que se utilizará para remplazar entidades o atributos.

Determinar los campos o las filas que están en conflicto.

Todas las entidades y clases de conflicto aparecen en el cuadro de lista en el lado superior izquierdo del cuadro de diálogo Conflictos. Esta lista Conflictos informa la cantidad total de conflictos que se han revisado y la cantidad total de conflictos en todas las clases de conflicto. Inicialmente, estas cantidades serán iguales. En el ejemplo siguiente, hay un total de dos objetos en conflicto y ninguno ha sido revisado.

Conflicts (2/2)

Debajo de Conflictos hay una lista de las clases de entidad que contienen conflictos, seguidas por la cantidad de conflictos visitados o reemplazados en la clase de entidad y la cantidad de conflictos en la clase de entidad. En este ejemplo, hay dos clases de entidad y cada una contiene un conflicto.

Conflicts (2/2) sde.RJP.ponds (1/1) sde.RJP.lakes (1/1)

Debajo de cada clase de entidad, aparecen los Id. de objeto de las entidades en conflicto. En este ejemplo, hay un conflicto en el Id. de objeto 30 en la clase de entidad lagunas y un conflicto para la entidad 11 en la clase de entidad lagos.

Conflicts (2/2) sde.RJP.ponds (1/1) 30 sde.RJP.lakes (1/1) 11

Puede ver que no se han visitado ni reemplazado ninguno de los objetos porque la relación entre el total de conflictos revisados y el total de conflictos sigue siendo (2/2) y (1/1) para cada clase de entidad. También puede ver que ninguno de los conflictos se ha revisado ni reemplazado porque todos los Id. de objetos y las clases de entidad aparecen en negrita.

Cuando marca los objetos como visitados (consulte la sección "Marcar como visitado o marcar como no visitado" a continuación) o los reemplaza (consulte la sección "Resolver conflictos" a continuación), el primer número entre paréntesis disminuye y el Id. del objeto revisado deja de aparecer en negrita. Si todos los Id. de objetos en una clase de entidad se han marcado como visitados o reemplazados, la clase de entidad deja de aparecer en negrita. En el ejemplo de lagunas y lagos, si marca el Id. de objeto 30 como visitado, verá lo siguiente en el cuadro de lista que aparece en el cuadro de diálogo Conflictos:

Conflicts (1/2) sde.RJP.ponds (0/1) 30 sde.RJP.lakes (1/1) 11

Si hubiese habido una segunda entidad de laguna en conflicto, la lista se vería así:

Conflicts (2/3) sde.RJP.ponds (1/2) 5 30 sde.RJP.lakes (1/1) 11

Esta lista indica que hay un total de tres conflictos como resultado de la conciliación y que uno de esos tres ha sido revisado o reemplazado. La lista también muestra que 30 es el Id. de objeto de la entidad en conflicto que ha sido visitada o reemplazada y esta entidad se encuentra en la clase de entidad lagos.

Cuando selecciona una entidad individual de la lista, las columnas y los atributos en las versiones pre-reasignada, de conflicto y de antecesor común de la entidad aparecen en la lista ubicada a la derecha del cuadro de diálogo Conflictos.

La versión pre-reasignada representa las modificaciones que realizó en la entidad y el atributo.

La versión de conflicto representa la entidad y sus atributos editados y conciliados por otro usuario.

La versión de antecesor común es la representación de la entidad y sus atributos como aparecen en la base de datos; es cómo se encontraban la entidad y los atributos antes de que se les realicen modificaciones.

Un punto rojo a la izquierda del nombre de campo identifica un conflicto. Por ejemplo, si la geometría de la entidad se editó en cada versión, aparece un punto rojo junto al campo Forma.

Si hay otros campos de atributo en conflicto, aparecerá un punto rojo junto a ellos. Si se ha eliminado una entidad en cualquiera de las dos versiones, aparecerá <eliminado> para el valor de atributo de esa versión.

Tener en conflicto los atributos y valores de todas las representaciones de una entidad le permite ver cómo difieren los valores de atributo y sirve como ayuda para elegir la representación de los datos que se va a conservar.

Ver los conflictos

Si hace clic en el botón Mostrar conflicto en el cuadro de diálogo, en la parte inferior del cuadro de diálogo, verá dos representaciones (la versión pre-reasignada y la de conflicto) de las entidades en conflicto.

Si utiliza las listas desplegables ubicadas debajo de cada representación, puede alternar entre tres representaciones diferentes de las entidades en conflicto: Pre-reasignada, Conflicto y Antecesor común. Observe que éstas sólo serán diferentes si las geometrías de las entidades están en conflicto.

Debajo de cada representación hay una barra de herramientas con herramientas que puede utilizar para navegar e identificar la representación correspondiente.

Puede acercarse a una versión específica de una entidad en conflicto en el mapa si hace clic con el botón derecho del ratón en la lista y hace clic en Acercar a versión pre-reasignada, Acercar a versión de conflicto o Acercar a versión antecesor común de una entidad.

Si existen conflictos de geometría, también puede ver diferentes representaciones en el mapa si hace clic con el botón derecho del ratón en el campo Forma del cuadro de lista y luego hace clic en Visualización.

Esto abrirá el cuadro de diálogo Configuración de la visualización de conflictos. Haga clic en la representación que desea dibujar en el mapa.

Una vez que hizo clic en Aceptar, ocurrirá lo siguiente en el mapa:

La representación de la versión de conflicto (de destino) se muestra en rojo.

La representación pre-reasignada se muestra en verde.

La representación de la versión de antecesor común de una entidad se muestra en azul.

El siguiente es un ejemplo de lo que se mostraría en el mapa si se eligiera la configuración de la visualización de conflictos que se muestra arriba:

El siguiente es un ejemplo de lo que se mostraría en el mapa si sólo se marcara Dibujar versión actual en el cuadro de diálogo Configuración de la visualización de conflictos:

Una vez observados los conflictos, puede marcarlos como visitados o elegir una opción de reemplazo para resolver el conflicto.

Marcar como visitado o marcar como no visitado

Tal como se menciona en la sección "Determinar los campos o las filas que están en conflicto", puede marcar una entidad como visitada. Esto indica que ha revisado el conflicto pero no desea elegir una opción de reemplazo en esta oportunidad. Puede llevar un registro de las entidades de la lista que ha revisado ya que aquellas marcadas como visitadas dejan de aparecer en negrita.

Si decide que desea volver a un conflicto de entidad más tarde, puede hacer clic con el botón derecho del ratón en el Id. de objeto en la lista Conflictos y hacer clic en Marcar como no visitado. Esto hace que la entidad vuelva a aparecer en negrita.

Resolver conflictos

Reemplazo de atributo

Reemplazo de entidad

Reemplazo de nivel de clase

Reemplazo completo

Fusionar geometrías

Esto ocurre en el nivel del campo y se asocia específicamente con el atributo Forma. La opción para fusionar geometrías está disponible cuando hay un conflicto que involucra al campo Forma. Si dos editores editan la geometría de la misma entidad pero no la misma área de dicha entidad, tienen la opción de resolver el conflicto mediante la fusión de geometrías y de aceptar ambas ediciones.

La opción de fusionar geometrías sólo está disponible en el menú de acceso directo del campo Forma.

Una vez que se han fusionado las geometrías, el resultado final es una entidad que contiene las ediciones realizadas por ambos editores:

Si las ediciones realizadas por un editor comparten una región editada también por otro editor, las áreas editadas se superponen. A pesar de que se encuentre disponible la opción para fusionar geometrías, esta acción no se podrá llevar a cabo. Cuando esto sucede, aparece el siguiente mensaje de error:

Conflictos en redes geométricas

Cuando se editan entidades de red, los cambios en la red geométrica y la red lógica pueden crear conflictos.

Por ejemplo, cuando agrega un servicio a una tubería principal, ésta no se dividirá físicamente en la red geométrica pero sí lo hará en la red lógica. Por lo tanto, aunque no ha editado directamente la geometría de la tubería principal, la ha editado lógicamente. Si la versión de destino que está conciliando también ha modificado la tubería principal, el servicio nuevo que insertó creará un conflicto con la misma.

Revisar un conflicto que involucra clases de entidades de red geométrica requiere conocimientos sobre cómo el comando Reemplazar por, en el cuadro de diálogo Conflictos, actualiza la topología de red existente presente en la sesión de edición.

En el ejemplo de servicio de la tubería principal, dos usuarios modificaron la tubería principal de agua: uno modificó un atributo y el otro conectó un servicio nuevo. Revisar el conflicto simplemente requiere investigar las diferencias y verificar si el conflicto es válido; no se requieren otras medidas. Dado que la tubería principal contiene el atributo correcto para el diámetro, el servicio nuevo se conecta adecuadamente a la tubería. Pero hay casos en los que resolver los conflictos que involucran una clase de entidad de cruce también actualiza el borde de red conectado.

Conflictos en anotación vinculada a entidad

Para trabajar con una anotación vinculada a entidad debe recordar una regla: Cuando reemplaza una entidad que tiene una anotación vinculada a entidad, tanto la entidad como la anotación son reemplazadas por la entidad y la anotación nuevas. Por lo tanto, es probable que deba realizar otras modificaciones en la anotación nueva para evitar que queden dos anotaciones.

Por ejemplo, puede encontrarse con un conflicto en el que movió una entidad y reposicionó la anotación. La versión de conflicto realizó la misma edición, es decir, movió la entidad y rotó la anotación. Si decide reemplazar la entidad por la entidad de la versión de conflicto, se elimina la anotación vinculada a entidad existente, se inserta la entidad en conflicto y se crea una nueva anotación. A continuación, deberá editar la nueva anotación; para ello, muévala y rótela según sea necesario.

O puede encontrar un conflicto en el que otro editor ha eliminado una entidad en la versión DEFAULT de la geodatabase, lo que también elimina su anotación vinculada a entidad asociada. En una versión secundaria de la geodatabase, edita la anotación que se acaba de eliminar. Si cuando realiza la conciliación decide reemplazar la entidad por la versión de edición, se reemplazarán la entidad que se había eliminado en la versión DEFAULT y su anotación vinculada asociada, y obtendrá la anotación de la sesión de edición, lo que dará como resultado dos anotaciones para la misma entidad.

Conflictos en relaciones

Las relaciones tienen dependencias similares a una anotación vinculada a entidad. Si se elimina una entidad de una clase de relación de origen, aparecerá un mensaje para que elimine una entidad de la clase de relación de destino. Por lo tanto, esté atento a las ramificaciones que se producen simplemente al reemplazar conflictos que involucran clases de entidades que participan en clases de relaciones.

El siguiente es un ejemplo de un conflicto que puede surgir entre clases de relación:

Actualiza el campo Primario de la clase de origen y rompe la relación en la versión A.

Al mismo tiempo, actualiza la entidad de destino relacionada a la clase en la versión B.

Dado que la clase de destino es dependiente de la clase de origen, se detecta un conflicto cuando concilia las versiones.

Otro ejemplo es el siguiente:

En el dataset de entidades de servicio eléctrico, elimina un polo que tiene relación con un transformador, lo que hace que también se elimine el transformador relacionado.

En otra sesión de edición que se lleva a cabo al mismo tiempo, un editor altera los atributos del transformador que usted acaba de eliminar cuando eliminó el polo relacionado.

Cuando se concilian las ediciones, se detectará un conflicto de actualización-eliminación.

En este último ejemplo, si el segundo editor elige reemplazar todos los conflictos por las representaciones de sesión de edición, se volverán a crear el polo y el transformador eliminados durante su sesión de edición, y se creará el transformador de la sesión del segundo editor, lo que dará como resultado dos transformadores. Es posible que no pueda detectar esto mirando el mapa, porque los transformadores estarán uno encima del otro; sin embargo habrá dos registros para el transformador en la tabla de atributos.

Conflictos en topologías

Dado que las entidades en las clases de entidad que participan en una topología pueden compartir geometría con otras entidades, el proceso de revisión de conflictos entre versiones de clases de entidad topológicas es distinto al de reemplazar conflictos con clases de entidad simples. También es diferente del proceso que se utiliza para reemplazar conflictos con redes geométricas, clases de relaciones y anotación vinculada a entidad.

Cuando se edita una clase de entidad que participa en una topología, es posible que se modifiquen de manera simultánea otras entidades relacionadas topológicamente. Las entidades modificadas pueden pertenecer a la misma clase de entidad o a una o más clases de entidad. Para administrar el proceso de detección de nuevos errores de topología que pueden haberse introducido con las ediciones, las topologías registran los lugares donde se realizaron ediciones como áreas sin validar. Editar entidades en una topología crea áreas sin validar en la topología.

Cuando se concilian las versiones principal y secundaria editadas, se pueden producir nuevos errores de topología, incluso cuando las áreas sin validar dentro de cada versión se han validado para confirmar que no contienen errores. Para detectar tales errores de topología, todas las áreas sin validar en una versión secundaria se regresan al estado sin validar después de que se traen los cambios de la versión principal durante una conciliación. Una vez realizada la conciliación, estas áreas se pueden revalidar para detectar la presencia de errores.

Conciliar dos versiones que no contengan áreas sin validar activas puede resultar en áreas sin validar. Toda área sin validar que haya estado presente en la versión secundaria, independientemente de que haya sido validada, será un área sin validar después de conciliar las versiones. En general, cuando se concilia una versión

Toda área sin validar que la versión secundaria haya heredado de la versión principal, independientemente de que esté validada en la versión secundaria, será un área sin validar después de la conciliación.

Toda área sin validar que se haya creado para una entidad que fue creada, actualizada o eliminada en la versión secundaria, independientemente de que esté validada, será un área sin validar después de la conciliación.

Temas relacionadosConciliar una versiónGuardar los cambios de una versión

Copyright © 1995-2011 Esri. Todos los derechos reservados.

Resolución de conflictos interactivaResource Center » Biblioteca para profesionales » Administración de datos » Administrar geodatabases » Transacciones y versiones de

geodatabase » Trabajar con datos versionados » Editar versiones » Conciliar y publicar modificaciones en una versión

Este tema se aplica sólo a ArcEditor y ArcInfo.

Si surgen conflictos entre la versión editada y la versión objetivo al realizar la conciliación, puede resolver interactivamente estos conflictos en el cuadro de diálogo Conflictos. El cuadro de diálogo Conflictos solo aparece si se establecen sus opciones de edición para guardar automáticamente los cambios solo si no hay ningún conflicto.

Más información sobre la configuración de las opciones de edición con control de versiones

Al resolver conflictos, debe decidir qué representación de las entidades y atributos desea mantener.

Los conflictos se pueden resolver en varios niveles diferentes:

Nivel de campo (atributo): elija qué representación desea utilizar para reemplazar los valores de atributo específicos de su versión de edición de los datos. Estos cambios se aplican a un campo o campos determinados.

Por ejemplo, si el campo Color para la boca de incendios 1297 de una clase de entidad Boca de incendios contiene los siguientes atributos: Rojo para la versión antecesora común, Amarillo para la versión previa a la conciliación y Naranja para la versión en conflicto, debería elegir qué color (qué valor de atributo de versión) desea utilizar para reemplazar el valor de atributo del campo Color de su versión de edición. Los campos son los nombres de campo que se muestran bajo la columna Propiedad en la parte de información de atributos del cuadro de diálogo Conflictos.Vea Resolver conflictos interactivamente en el nivel de campo para obtener instrucciones.

Nivel de fila (entidad individual): una fila de una tabla representa una entidad; por ejemplo, el punto que representa la boca de incendios 1297. Se muestran en la lista de conflictos (lado izquierdo del cuadro de diálogo Conflictos) utilizando su ObjectID.

Resolver los conflictos en el nivel de fila significa que la representación elegida se aplica a todos los conflictos de esa entidad. Por lo tanto, si tanto el campo Color como el campo Forma de la boca de incendios 1297 tienen conflictos, la representación que elija para reemplazar su versión de edición reemplazará los valores de atributo para el campo Color y el campo Forma.Vea Resolver conflictos interactivamente en el nivel de fila para obtener instrucciones.

Nivel de clase (clase de entidad completa): las clases de entidad están en la lista Conflictos del cuadro de diálogo Conflictos. Verá el nombre de la clase de entidad en la lista.

Resolver conflictos en el nivel de clase significa que la representación de los datos elegida para reemplazar su versión de edición de los datos se aplica a todas las entidades y atributos en conflicto de esa clase. Por ejemplo, si decide utilizar la versión en conflicto de la clase de entidad Boca de incendios para reemplazar su versión de

edición de la clase de entidad Boca de incendios, todos los atributos en conflicto de todas las entidades se reemplazan con los valores de atributo de la versión en conflicto.Vea Resolver conflictos interactivamente en el nivel de clase para obtener instrucciones.

Nivel de raíz (todos los conflictos de todas las clases de entidad y entidades para una operación de conciliación en particular). El nivel de raíz del cuadro de diálogo Conflictos es el nivel superior de la lista Conflictos.

Si resuelve los conflictos en el nivel de raíz, todos los conflictos detectados durante el proceso de conciliación se resuelven utilizando la misma representación. Por ejemplo, si decide reemplazar la versión anterior a la conciliación en el nivel de raíz, todos los conflictos de todas las clases de entidad y entidades de la lista se resolverán a favor de sus ediciones.Vea Resolver conflictos interactivamente en el nivel de raíz para obtener instrucciones.

Resolver conflictos no guarda las ediciones en la versión primaria; enviar los cambios a la versión objetivo sí lo hace.

Temas relacionadosConciliar una versiónUn paseo introductorio por la revisión de conflictos

Copyright © 1995-2011 Esri. Todos los derechos reservados.

Resolver conflictos interactivamente en el nivel de campoResource Center » Biblioteca para profesionales » Administración de datos » Administrar geodatabases » Transacciones y versiones de

geodatabase » Trabajar con datos versionados » Editar versiones » Conciliar y publicar modificaciones en una versión

Este tema se aplica sólo a ArcEditor y ArcInfo.

Si surgen conflictos entre la versión editada y la versión objetivo al realizar la conciliación, puede resolver interactivamente estos conflictos en el cuadro de diálogo Conflictos. El cuadro de diálogo Conflictos solo aparece si se establecen sus opciones de edición para guardar automáticamente los cambios solo si no hay ningún conflicto.

Al resolver conflictos en el nivel de campo, se elige qué representación utilizar para reemplazar los valores de atributo concretos en la versión revisada de los datos. Estos cambios se aplican a un campo o campos determinados.

Pasos:

1. Elija un ID de objeto en la lista Conflictos.

2. En el cuadro de lista de la esquina superior derecha del cuadro de diálogo Conflictos, haga clic con el botón derecho en el campo para el que haya un conflicto.

Sugerencia:

Si desea elegir varios campos, mantenga presionada la tecla CONTROL y haga clic en cada uno que desee elegir.

3. En el menú contextual, haga clic en la representación, Pre-Reasignado, Conflicto o Antepasado común, que contiene el valor de atributo que desea utilizar para resolver el conflicto.

Sugerencia:Si un editor modifica una entidad y otro editor la elimina, no podrá reemplazarla con ninguna de las representaciones y esas opciones de menú estarán desactivadas.

Temas relacionadosConciliar una versiónUn paseo introductorio por la revisión de conflictos

Copyright © 1995-2011 Esri. Todos los derechos reservados.

Resolver conflictos interactivamente en el nivel de filaResource Center » Biblioteca para profesionales » Administración de datos » Administrar

geodatabases » Transacciones y versiones de geodatabase » Trabajar con datos versionados » Editar

versiones » Conciliar y publicar modificaciones en una versión

Este tema se aplica sólo a ArcEditor y ArcInfo.

Si surgen conflictos entre la versión editada y la versión objetivo al realizar la conciliación, puede resolver interactivamente estos conflictos en el cuadro de diálogo Conflictos. El cuadro de diálogo Conflictos solo aparece si se establecen sus opciones de edición para guardar automáticamente los cambios solo si no hay ningún conflicto.

Resolver los conflictos en el nivel de fila significa que la representación elegida se aplica a todos los conflictos de esa entidad. Por lo tanto, si tanto el campo Color como el campo Forma de la boca de incendios 1297 tienen conflictos, la representación que elija para reemplazar su versión de edición reemplazará los valores de atributo para el campo Color y el campo Forma.

Pasos:

1. En la lista Conflictos, haga clic con el botón derecho en el ID de objeto de la entidad para la que haya uno o más conflictos.

2. En el menú contextual, haga clic en la opción, Reemplazar Objeto con la Versión Pre-Reasignada,Reemplazar Objeto con la Versión de Conflicto o Reemplazar Objeto con Versión Antepasado Común, que designe qué representaciones se utilizarán para reemplazar los atributos en conflicto en esas entidad de la representación de edición.

Temas relacionadosConciliar una versiónUn paseo introductorio por la revisión de conflictos

Copyright © 1995-2011 Esri. Todos los derechos reservados.

Resolver conflictos interactivamente en el nivel de claseResource Center » Biblioteca para profesionales » Administración de datos » Administrar geodatabases » Transacciones y versiones de

geodatabase » Trabajar con datos versionados » Editar versiones » Conciliar y publicar modificaciones en una versión

Este tema se aplica sólo a ArcEditor y ArcInfo.

Si surgen conflictos entre la versión editada y la versión objetivo al realizar la conciliación, puede resolver interactivamente estos conflictos en el cuadro de diálogo Conflictos. El cuadro de diálogo Conflictos solo aparece si se establecen sus opciones de edición para guardar automáticamente los cambios solo si no hay ningún conflicto.

Al resolver conflictos, debe decidir qué representación de las entidades y atributos desea mantener.

Resolver conflictos en el nivel de clase significa que la representación de los datos elegida para reemplazar su versión de edición de los datos se aplica a todas las entidades y atributos en conflicto de esa clase. Por ejemplo, si decide utilizar la versión en conflicto de la clase de entidad Boca de incendios para reemplazar su versión de edición de la clase de entidad Boca de incendios, todos los atributos en conflicto de todas las entidades se reemplazan con los valores de atributo de la versión en conflicto.

Pasos:

1. En la lista Conflictos, haga clic con el botón derecho en la clase de entidad para la que desea resolver conflictos.

2. Haga clic en una de las siguientes opciones: Reemplazar Objeto con la Versión Pre-Reasignada,Reemplazar Objeto con la Versión de Conflicto o Reemplazar Objeto con Versión Antepasado Común para designar qué representación se utilizará para reemplazar todos los atributos en conflicto en todas las entidades de la representación de edición.

Sugerencia:Al hacer clic o hacer clic con el botón derecho en una clase de entidad en la lista Conflictos, los campos y atributos de la derecha del cuadro de diálogo desaparecen, así como las visualizaciones de conflictos de la parte inferior del cuadro de diálogo.

Temas relacionadosConciliar una versión

Un paseo introductorio por la revisión de conflictos

Copyright © 1995-2011 Esri. Todos los derechos reservados.

esolver conflictos interactivamente en el nivel de raízResource Center » Biblioteca para profesionales » Administración de datos » Administrar geodatabases » Transacciones y versiones de

geodatabase » Trabajar con datos versionados » Editar versiones » Conciliar y publicar modificaciones en una versión

Este tema se aplica sólo a ArcEditor y ArcInfo.

Si surgen conflictos entre la versión editada y la versión objetivo al realizar la conciliación, puede resolver interactivamente estos conflictos en el cuadro de diálogo Conflictos. El cuadro de diálogo Conflictos solo aparece si se establecen sus opciones de edición para guardar automáticamente los cambios solo si no hay ningún conflicto.

Si resuelve los conflictos en el nivel de raíz, todos los conflictos detectados durante el proceso de conciliación se resuelven utilizando la misma representación. Por ejemplo, si decide reemplazar la versión anterior a la conciliación en el nivel de raíz, todos los conflictos de todas las clases de entidad y entidades de la lista se resolverán a favor de sus ediciones.

Pasos:

1. En la lista Conflictos, haga clic con el botón derecho en la raíz de la jerarquía de la lista de conflictos, Conflictos.

2. En el menú contextual, haga clic en la opción, Reemplazar Objeto con la Versión Pre-Reasignada,Reemplazar Objeto con la Versión de Conflicto o Reemplazar Objeto con Versión Antepasado Común, que designe qué representación se usará para reemplazar todos los atributos en conflicto de todas las entidades de todas las clases de entidad de la lista Conflictos de la representación de edición.

Sugerencia:Al hacer clic o hacer clic con el botón derecho en una clase de entidad en la lista Conflictos, los campos y atributos de la derecha del cuadro de diálogo desaparecen, así como las visualizaciones de conflictos de la parte inferior del cuadro de diálogo.

Temas relacionadosConciliar una versiónUn paseo introductorio por la revisión de conflictos

Copyright © 1995-2011 Esri. Todos los derechos reservados.

Enviar cambiosResource Center » Biblioteca para profesionales » Administración de datos » Administrar geodatabases » Transacciones y versiones de

geodatabase » Trabajar con datos versionados » Editar versiones » Conciliar y publicar modificaciones en una versión

Este tema se aplica sólo a ArcEditor y ArcInfo.

Cuando haya conciliado y revisado algún conflicto, puede enviar los cambios a una versión antecesora.

Sugerencia:Otros usuarios que lean la versión objetivo a la que haya enviado los cambios no verán los resultados del envío hasta que actualicen sus espacios de trabajo versionados.

La operación de envío solo se puede completar si la versión objetivo no se ha modificado desde que se completó la operación de conciliación. Si la versión de destino se ha modificado mientras tanto, tendrá que conciliar de nuevo antes de enviar.

La operación de envío no se puede deshacer, puesto que se está aplicando cambios a una versión que no se está editando actualmente.

Después de enviar, puede continuar realizando más ediciones en la sesión de edición. Para aplicar estos cambios a la versión objetivo, debe realizar de nuevo los procesos de conciliación, resolución de conflictos y envío.

Pasos:

1. Si la barra de herramientas Versionado aun no está abierta, haga clic en Personalizar en el menú principal, seleccione Barras de herramientas y haga clic en Versionado.

Es posible que deba desplazarse hacia abajo en la lista de las barras de herramientas para ver la opción de la barra de herramientas Versionado.

2. Haga clic en el botón Publicar en la barra de herramientas Versionado.

Si el envío marca el fin del proyecto o de su parte del flujo de trabajo, puede eliminar la versión que ha estado editando. Puede eliminar una versión siempre que se eliminen primero todas las versiones secundarias y si es el propietario de la versión.

Temas relacionadosConciliar una versión

Copyright © 1995-2011 Esri. Todos los derechos reservados.

Conciliación y envío automáticosResource Center » Biblioteca para profesionales » Administración de datos » Administrar geodatabases » Transacciones y versiones de

geodatabase » Trabajar con datos versionados » Editar versiones » Conciliar y publicar modificaciones en una versión

Este tema se aplica sólo a ArcEditor y ArcInfo.

Para las operaciones de edición grandes, con varios usuarios, normalmente es mejor automatizar los procesos de conciliación y envío. Esto ayuda a simplificar las operaciones de edición, reduce la sobrecarga de administración de versiones y garantiza que todos los cambios realizados en las versiones se propaguen automáticamente a través del árbol de versiones como se requiere. Estos dos procesos se pueden automatizar con una herramienta de conciliación de versiones por lotes o implementando un servicio de conciliación de versiones. Ambos están disponibles como ejemplos de desarrollador de ArcGIS.

Conciliar versiones de ArcSDE en modo de lotes

Servicio de control de versiones

Conciliación por lotes

La utilidad de conciliación por lotes permite que un editor o un jefe de proyecto se conecte a una geodatabase con control de versiones, seleccione una versión, la concilie y (opcionalmente) envíe cada versión bajo esa versión. Si la conciliación y el envío son correctos, es decir, si no se detecta ningún conflicto, tiene la opción de eliminar las versiones secundarias. Cualquier conflicto detectado detendría el proceso de conciliación. Los conflictos se deben tratar de la manera habitual utilizando las herramientas disponibles en ArcMap. Esta tarea administrativa se podría realizar al final de cada día o semana, o de cualquier intervalo de tiempo adecuado. La utilidad de conciliación de lotes se puede personalizar para que se inicie automáticamente a una hora predeterminada con los parámetros operativos que pueda configurar.

Los programas de conciliación y envío por lotes funcionan bien para organizaciones que tengan pedidos de trabajo que procesar al final del día o de la semana. Los escenarios de control de versiones que podrían beneficiarse incluyen los siguientes:

Varios múltiples

Proyectos múltiples con una base de datos protegida y publicada

Proyectos múltiples con subproyectos

Administración distribuida de datos, replicación y edición desconectada

Algunos flujos de trabajo de control de versiones que no son adecuados para la conciliación y el envío por lotes son los siguientes:

Edición simultánea de la versión DEFAULT: dado que todas las operaciones de conciliación son automáticas, no admite la conciliación y el envío por lotes.

Proyectos que progresan en fases: dado que exigirían alguna lógica de aplicación concreta para determinar qué versiones deben conciliarse y enviarse con cada versión principal, estos proyectos son generalmente inadecuados para las conciliaciones por lotes.

Servicios de conciliación de versiones

Un servicio de conciliación de versiones es un programa que se ejecuta como un proceso en segundo plano en un equipo cliente. Cuando un editor ha terminado de editar una versión, el editor envía la versión al servicio de conciliación. El servicio de conciliación comprueba periódicamente si las versiones se han marcado como listas para la conciliación. Si se detecta alguna versión de este tipos, el servicio las concilia y envía automáticamente a sus versiones primarias. La utilidad de servicio de conciliación se puede personalizar para modificar la frecuencia con la que el servicio comprueba las nuevas versiones para la conciliación y el envío.

La automatización del proceso de conciliación de versiones de esta manera ayuda a administrar el flujo de trabajo delegando la responsabilidad de la conciliación al servicio de conciliación. Los editores de datos son entonces libres

para continuar con otras tareas. Simplificando el flujo de trabajo de esta manera, las operaciones de edición de datos pueden escalarse más fácilmente para admitir datos y editores adicionales.

Temas relacionadosConciliar una versiónEnviar cambios

La operación de compresión y las geodatabasesResource Center » Biblioteca para profesionales » Administración de datos » Administrar

geodatabases » Transacciones y versiones de geodatabase » Trabajar con datos versionados » Comprimir una

geodatabase versionada

Este tema se aplica sólo a ArcEditor y ArcInfo.

A medida que se edita una geodatabase a lo largo del tiempo, las tablas delta aumentan de tamaño, y el número de estados aumenta. Cuanto mayores sean las tablas y más sean los estados, más datos debe procesar ArcGIS cada vez que se muestre o se consulte una versión. Por consiguiente, el mayor impacto sobre el rendimiento no lo tiene el número de versiones, sino la cantidad de cambios contenidos en las tablas delta para cada versión. Como resultado, las versiones pueden tener diferentes tiempos de respuesta a las consultas.

Para mantener el rendimiento de la base de datos, el administrador de ArcSDE debe ejecutar periódicamente el comando Comprimir de ArcCatalog para quitar los datos no usados. Solo el administrador de ArcSDE (el usuario sde o dbo) puede ejecutar una operación de compresión. Al comprimir se realizan dos tareas clave:

Quita los estados sin referencia y las filas asociadas de la tabla delta.

Mueve a las tablas base las entradas de las tablas delta comunes a todas las versiones, reduciendo la cantidad de datos que la base de datos necesita buscar para cada consulta de versión, y mejorando así el rendimiento de las consultas y el tiempo de respuesta del sistema.

Cuando se ha acumulado un gran volumen de cambios sin comprimir, la compresión de la base de datos puede tardar horas. Para evitarlo, comprima de manera periódica. Es una buena idea comprimir al final de cada día o después de un período de elevada actividad de la base de datos, tal como la carga de datos.

Durante una compresión, los usuarios pueden permanecer conectados a la geodatabase. Si cualquier usuario está editando una versión, la rama para ese estado se bloquea y no toma parte en la compresión. Por consiguiente, es mejor hacer que todos los usuarios se desconecten antes de empezar para asegurarse de que se pueda comprimir el árbol de estados completo. No es necesario desconectar las sesiones que sean de solo lectura, tales como una sesión de ArcIMS.

Si se encuentra alguna vez esperando a que se complete la compresión porque necesite el equipo para otra cosa, puede finalizar la compresión en cualquier momento. Esto no dejará la base de datos en un estado incoherente. Puede continuar con la compresión más tarde.

Es importante actualizar las estadísticas para cada clase de entidad y cada tabla versionada, tanto antes como después de comprimir. Después de que se produzcan ediciones y una compresión de la base de datos, las estadísticas de la base de datos ya no serán precisas. Esto perjudica al rendimiento de las consultas.

Para obtener más información sobre las tablas delta, los estados y la operación de compresión, lea las notas del producto tituladas Control de versiones. Vaya a http://support.esri.com y haga clic en el vínculo White Papers en la ficha Knowledge Base.

Copyright © 1995-2011 Esri. Todos los derechos reservados.

Agregar el comando Comprimir a ArcCatalogResource Center » Biblioteca para profesionales » Administración de datos » Administrar geodatabases » Transacciones y versiones de

geodatabase » Trabajar con datos versionados » Comprimir una geodatabase versionada

Este tema se aplica sólo a ArcEditor y ArcInfo.

El comando Comprimir no se encuentra de forma predeterminada en ArcCatalog. Para utilizarlo, debe agregarlo a la interfaz.

Pasos:

1. Haga clic en Personalizar > Personalizar modo.

2. Marque la casilla de verificación Menús contextuales en la lista de barras de herramientas.

Se abre el cuadro de diálogo Menús contextuales.

3. Expanda la lista Menús contextuales.

4. Haga clic en la flecha junto al menú contextual Base de datos remota.

Tal vez sea necesario desplazarse hacia abajo para verlo.

5. Haga clic en la ficha Comandos del cuadro de diálogo Personalizar.

6. Haga clic en Herramientas de geodatabase en la ventana Categorías.7. Arrastre el comando Comprimir base de datos desde la lista Comandos hasta el menú contextual.

El comando aparece en el menú contextual.

8. Haga clic en Cerrar en el cuadro de diálogo Personalizar.

Comprimir una geodatabase de ArcSDE con licencia bajo ArcGIS Server EnterpriseResource Center » Biblioteca para profesionales » Administración de datos » Administrar geodatabases » Transacciones y versiones de

geodatabase » Trabajar con datos versionados » Comprimir una geodatabase versionada

Este tema se aplica sólo a ArcEditor y ArcInfo.

Para mantener el rendimiento de la base de datos, el administrador de ArcSDE debe ejecutar periódicamente el comando Comprimir de ArcCatalog para quitar los datos no usados.

Pasos:

1. Inicie ArcCatalog y cree una nueva conexión de base de datos. Asegúrese de conectarse como usuario administrativo de ArcSDE.

2. Agregue el comando Comprimir a ArcCatalog. Vea Agregar el comando Comprimir a ArcCatalog para obtener instrucciones.

3. Haga clic con el botón derecho en la nueva conexión de base de datos y haga clic en Comprimir Base de datos.

Copyright © 1995-2011 Esri. Todos los derechos reservad

omprimir una geodatabase en un servidor de base de datosResource Center » Biblioteca para profesionales » Administración de datos » Administrar geodatabases » Transacciones y versiones de

geodatabase » Trabajar con datos versionados » Comprimir una geodatabase versionada

Este tema se aplica sólo a ArcEditor y ArcInfo.

La operación de compresión quita los estados a los que una versión ya no hace referencia y puede mover las filas de las tablas delta a la tabla base. Para obtener más información sobre cómo funciona la operación de compresión y en qué casos debe utilizarla, consulte Operación de compresión de geodatabase.

Sólo un administrador del servidor o un administrador de geodatabase puede realizar la operación de compresión. No tendrá acceso a la función Comprimir base de datos si no pertenece a uno de estos roles.

Sugerencia:Para saber cuándo fue la última vez que se comprimió la geodatabase, haga clic en la ficha Administración en el cuadro de diálogo Propiedades de la geodatabase. La fecha de la última compresión se encuentra en la secciónComprimir.

Pasos:

1. Inicie sesión como administrador del servidor o administrador de geodatabase, inicie ArcMap y, a continuación, abra la ventana Catálogo.

2. Haga doble clic en el servidor de base de datos que contiene la geodatabase que desea comprimir.

Esto lo conectará al servidor de base de datos.

3. Haga clic con el botón derecho del ratón en la geodatabase que desea comprimir.

4. Haga clic en Administración en el menú de acceso directo de la geodatabase y haga clic enComprimir base de datos.

Aparecerá una barra de progreso mientras se ejecuta la operación de compresión. La barra avanzará hasta que se complete la operación.

Copyright © 1995-2011 Esri. Todos los derechos reservados.