Scénarios de données réparties

Disponible avec une licence Standard ou Advanced.

La réplication de géodatabase prend en charge de nombreuses options de processus en plus de celles déjà disponibles dans le versionnement traditionnel. Les sections suivantes présentent différents scénarios mis en œuvre lors de la réplication de géodatabase.

Arborescence de réplicas

La réplication de géodatabase peut être utilisée pour créer des arborescences de réplicas, semblables aux arborescences de versions, permettant aux organisations de répartir leurs données sur plusieurs géodatabases à l'aide d'une structure hiérarchique.

Par exemple, certaines organisations ont besoin de répliquer une seule grande géodatabase d’entreprise dans différents bureaux. Chaque bureau dispose d’un réplica contenant uniquement les données qui le concernent, et il peut transférer les modifications apportées à ces données vers le siège social. Le siège social peut ainsi analyser les données mises à jour dans toute l’étendue. Les connexions à l’intérieur d’un bureau sont rapides, mais beaucoup plus lentes entre les bureaux. Les bureaux régionaux peuvent également répliquer leurs géodatabases vers les bureaux locaux de la même façon que le siège social réplique sa géodatabase vers les régions.

Structure hiérarchique constituant un scénario de données réparties possible

Hub central

Une géodatabase de réplica peut être utilisée comme un hub central hébergeant des lecteurs et des éditeurs. Pour maintenir une vitesse de connexion élevée, les éditeurs peuvent créer un réplica afin d’extraire des données du hub central, effectuer des mises à jour, puis réinjecter les modifications en les synchronisant avec la géodatabase.

Le hub central permet également de propager des modifications entre plusieurs réplicas enfant. Pour déplacer des modifications d’un réplica à un autre, les modifications d’un réplica sont d’abord synchronisées avec le réplica parent (ou hub). Un second réplica enfant peut ensuite être synchronisé avec le réplica parent afin d'obtenir ces modifications.

Structure de hub central comme possible scénario de données réparties

Utilisateurs mobiles

Les utilisateurs itinérants d’une organisation, par exemple une équipe de maintenance, ont besoin de mettre à jour sur le terrain une partie de la géodatabase d’entreprise. Ils doivent pouvoir se déconnecter complètement de l’infrastructure de l’organisation, souvent pour une longue période. Lors de la préparation à une commande de travail ou un projet particulier, les données nécessaires sont répliquées et transférées vers un appareil portable, par exemple un ordinateur portable. Cet appareil est ensuite déconnecté du réseau, ce qui permet à l’équipe sur le terrain de travailler indépendamment du réseau. Elle peut ensuite poursuivre son travail et modifier les données répliquées, même en étant déconnectée du réseau. Lorsque la connexion au réseau est rétablie, les mouvements effectués sur les données sont retransférés et synchronisés avec les données de la géodatabase d’entreprise.

Conseil :

Pour ce scénario, il est recommandé que chaque éditeur de champ possède son propre réplica à utiliser. Si un grand nombre d’éditeurs doit être synchronisé à la fois, il est recommandé que chaque éditeur possède sa propre version et qu’il crée un réplica à partir de cette version. Cela simplifie la synchronisation et évite de collecter des données conflictuelles.

Utilisateurs itinérants ou travailleurs sur le terrain constituant un scénario de données réparties possible

Prestataires

Certaines organisations doivent sous-traiter la gestion d’une partie de leur géodatabase, en demandant au prestataire de fournir des mises à jour mensuelles. L’organisation doit pouvoir intégrer les modifications du prestataire, sans avoir à recharger complètement les données. Elle doit également bénéficier d'une méthode rapide pour réviser uniquement les mises à jour d'un mois donné, sans avoir à effectuer des tests d'assurance-qualité sur la totalité du jeu de données.

Cette opération est possible en envoyant au prestataire un réplica des données à mettre à jour. Lorsque le prestataire renvoie les modifications à l’organisation, ces dernières peuvent être synchronisées avec les données de la géodatabase d’entreprise.

Structure de prestataires externes en lecture seule constituant un scénario de données réparties possible

Géodatabases de production et de publication

Une organisation doit prendre en charge un groupe d’éditeurs, ainsi que des éditeurs qui accèdent au système en lecture seule. Pour satisfaire les besoins de chaque groupe, l’organisation dispose de deux géodatabases d’entreprise : l’une est une géodatabase de production mise à jour directement par les éditeurs, tandis que l’autre est un réplica de cette géodatabase, accessible par les lecteurs. Ces données sont accessibles aux lecteurs via ArcGIS Enterprise.

Dans ce scénario, le réplica de la géodatabase de publication représente une copie en lecture seule de la géodatabase de production. Les données de la géodatabase de publication n’ont pas besoin d’être versionnées. La réplication peut se limiter à l’envoi de données dans une seule direction. Les mises à jour sont effectuées dans la géodatabase de production, puis envoyées à la géodatabase de publication. Ces mises à jour sont transférées et synchronisées avec les données de la géodatabase de publication, puis distribuées aux lecteurs.

Structure de production/publication constituant un scénario de données réparties possible

Gestion des données en plusieurs groupes

Au sein de votre organisation, la gestion des données peut être répartie entre différents groupes. Par exemple, un groupe peut être chargé de la gestion des ressources physiques, tandis qu’un autre groupe gère les données foncières pour la même zone. Dans un autre exemple, plusieurs équipes travaillent sur de nombreux projets entièrement indépendants. Les jeux de données de chaque projet proviennent pour la plupart de différentes zones géographiques, mais l'organisation souhaite créer un référentiel central pour tous les projets.

Votre organisation peut utiliser la réplication de géodatabase pour distribuer vos données entre différents groupes, en divisant ces données en projets appropriés. Chaque équipe du projet reçoit un réplica contenant les données nécessaires de la géodatabase d’entreprise. Les équipes mettent ensuite à jour indépendamment chaque réplica, éventuellement dans des zones géographiques distinctes, puis transfèrent ces mises à jour vers la géodatabase d’entreprise centrale. Inversement, toutes les mises à jour effectuées dans la géodatabase d’entreprise centrale sont également transférées au réplica correspondant des équipes du projet.

Structure de gestion des données en plusieurs groupes constituant un scénario de données réparties possible

Centralisation de données provenant de nombreuses sources

Une pratique de réplication courante consiste à disposer d’un emplacement centralisé de rassemblement des données. Les organisations installées de cette manière disposent d'une géodatabase centrale hébergeant une collection de données d'autres bureaux.

La distribution de données entre les bureaux des États et un bureau national constitue un exemple de cette pratique. Chaque bureau d’un Etat fonctionne indépendamment, en gérant ses propres jeux de données et en envoyant régulièrement des mises à jour au bureau national. Les mises à jour de chaque Etat sont synchronisées en un jeu de données complet dans la géodatabase nationale. Dans cette configuration de réplication enfant vers parent, le rôle de parent est affecté à la géodatabase nationale et le rôle d'enfant est affecté aux géodatabases d'état.

Exemple de centralisation de données de plusieurs sources dans le cadre d’un possible scénario de données réparties

Rubriques connexes