Escenarios de datos distribuidos

Disponible con una licencia Standard o Advanced.

La replicación de geodatabase admite muchas opciones de flujo de trabajo además de los que ya ofrece el versionado tradicional. Los siguientes son varios escenarios alojados a través de la replicación de geodatabases.

Árbol de réplicas

La replicación de geodatabases se puede utilizar para crear árboles de réplicas, similares a los árboles de versiones, que permitan a las organizaciones distribuir sus datos entre varias geodatabase en una estructura jerárquica.

Por ejemplo, algunas organizaciones requieren la capacidad de replicar una única geodatabase de la organización entre diferentes oficinas. Cada oficina tiene una réplica con solo los datos aplicables a su área y puede transferir cambios de estos datos a la oficina central. Permite que la oficina central analice datos actualizados en toda la extensión. Las conexiones dentro de una oficina son rápidas, pero son mucho más lentas entre oficinas. Las oficinas regionales también pueden replicar sus geodatabases a las oficinas locales del mismo modo que la oficina central replica su geodatabase a las regiones.

Estructura jerárquica como posible escenario de datos distribuidos

Nodo central

Una geodatabase de réplica se puede utilizar como un nodo central para alojar lectores y editores. Para mantener unas velocidades de conexión rápidas, los editores pueden crear una réplica para realizar un check-out de los datos del nodo central, realizar ediciones y, después, realizar un check-in de los cambios sincronizando con la geodatabase.

El nodo central también se puede utilizar para propagar cambios entre varias réplicas secundarias. Para mover cambios de una réplica a otra, los cambios de una réplica se sincronizan primero con la réplica primaria (o nodo central). A continuación, una segunda réplica secundaria se puede sincronizar con la primaria para obtener estos cambios.

Estructura de nodo central como posible escenario de datos distribuidos

Usuarios móviles

Los usuarios móviles dentro de una organización, como un equipo de mantenimiento, necesitan poder editar una parte de la geodatabase corporativa sobre el terreno. Necesitan desconectarse completamente de la infraestructura de la organización, a menudo durante un período prolongado de tiempo. Durante la preparación para un trabajo o proyecto determinado, los datos relevantes se replican y se transfieren a un dispositivo portátil, tal como un equipo portátil. Este dispositivo se desconecta entonces de la red, permitiendo que equipo de campo trabaje independientemente de la red. El equipo de campo puede continuar trabajando con los datos replicados y puede modificarlos, aunque estén desconectados de la red. Cuando se restablece una conexión a la red, los cambios realizados en los datos se vuelven a transferir y se sincronizan con los datos que se mantienen en la geodatabase corporativa.

Sugerencia:

Para este escenario, se recomienda que cada editor de campo tenga su propia réplica con la que trabajar. Si hay muchos editores que se van a sincronizar al mismo tiempo, se recomienda que cada editor tenga su propia versión y cree una réplica de dicha versión. Esto simplifica el proceso de sincronización y evita entrar en conflicto con la recogida de datos.

Usuarios móviles o trabajadores de campo como posible escenario de datos distribuidos

Contratistas

Algunas organizaciones necesitan subcontratar el mantenimiento de parte de su geodatabase y hacer que el contratista proporcione actualizaciones todos los meses. La organización necesita poder incorporar los cambios del contratista sin volver a cargar los datos completamente. También necesita una manera fácil de revisar solo las actualizaciones del mes, en lugar de tener que realizar comprobaciones de control de calidad en todo el dataset.

Esto se puede lograr enviando al contratista una réplica de los datos adecuados para las actualizaciones. Cuando el contratista devuelve los cambios a la organización, se pueden sincronizar con los datos que se mantienen en la geodatabase corporativa.

Planteamiento de solo lectura de un contratista externo como posible escenario de datos distribuidos

Geodatabases de producción y publicación

Una organización debe admitir un grupo de editores, así como usuarios que tengan acceso al sistema con acceso de solo lectura. Para satisfacer los requisitos de cada grupo, la organización tiene dos geodatabases corporativas. Una es la geodatabase de producción, que editan directamente los editores, mientras que la otra es una réplica de esta geodatabase y permite el acceso de lectores. Los lectores pueden acceder a estos datos a través de ArcGIS Enterprise.

En este escenario, la réplica de la geodatabase de publicación es una copia de solo lectura de la geodatabase de producción. Los datos de la geodatabase de publicación no necesitan estar versionados. La replicación se puede restringir al envío de datos en una sola dirección. Las ediciones se realizan en la geodatabase de producción y se envían desde ella a la geodatabase de publicación. Estas ediciones se transfieren y se sincronizan con los datos de la geodatabase de publicación y, después, se proporcionan a los lectores.

Estructura de producción/publicación como posible escenario de datos distribuidos

Administración de datos multigrupo

Dentro de la organización, la administración de datos puede estar dividida entre varios grupos diferentes. Por ejemplo, un grupo puede estar a cargo de administrar los activos físicos, mientras que otro se ocupa de administrar los datos base del terreno para la misma área. Otro ejemplo es donde varios equipos trabajan en muchos proyectos completamente independientes. Los datasets para cada proyecto pueden ser en su mayor parte de áreas geográficas diferentes, pero la organización desea un repositorio central para todos los proyectos.

La organización puede utilizar la replicación de geodatabases para distribuir los datos entre varios grupos, dividiendo los datos en proyectos adecuados. Cada equipo del proyecto recibe una réplica de los datos necesarios de la geodatabase corporativa central. Después, los equipos editan las réplicas de manera independiente, probablemente en ubicaciones geográficas separadas, y transfieren esas ediciones a la geodatabase corporativa central. A la inversa, las ediciones realizadas en la geodatabase corporativa central también se transfieren a las réplicas adecuadas de los equipos de proyecto.

Estructura de administración de datos multigrupo como posible escenario de datos distribuidos

Datos centralizados de varios orígenes

Otro ejercicio de replicación común consiste en tener una ubicación centralizada donde se recopilan los datos. Las organizaciones configuradas de esta manera tienen una geodatabase central que aloja una colección de datos de otras oficinas.

Un ejemplo es la distribución de datos entre oficinas estatales y nacionales. Cada oficina regional funciona independientemente, administrando sus propios datasets y enviando actualizaciones periódicamente a la oficina nacional. Las ediciones de cada región se sincronizan en un dataset completo en la geodatabase nacional. En esta configuración de replicación de elemento secundario a elemento primario, la geodatabase nacional tiene asignada la función de elemento primario y las geodatabases regionales tienen asignada la función de elemento secundario.

Ejemplo de datos centralizados de varios orígenes cuando se utilizan como posible escenario de datos distribuidos

Temas relacionados