Scénarios des données réparties

La réplication de géodatabase prend en charge plusieurs options de processus, qui viennent compléter celles déjà disponibles avec 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éplica

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 à jour sur toute l’étendue. Les connexions au sein d’un bureau sont rapides, mais bien plus lentes d’un bureau à un autre. 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 d’un possible scénario de données réparties

Hub central

Une géodatabase de réplica peut être utilisée comme un hub central hébergeant des lecteurs et des éditeurs. Dans le souci de maintenir des connexions rapides, les éditeurs peuvent créer un réplica pour extraire des données du hub central, effectuer des mises à jour, puis réinsérer les modifications par une synchronisation 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 d’un possible scénario de données réparties

Utilisateurs mobiles

Les utilisateurs mobiles d’une organisation, notamment ceux de l’équipe de maintenance, doivent pouvoir mettre à jour une partie de la géodatabase d’entreprise sur le terrain. 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. Une fois la connexion au réseau rétablie, toutes les modifications apportées aux données sont retransférées et synchronisées avec les données conservées dans la géodatabase d’entreprise.

Astuce :

Pour ce scénario, il est recommandé que chaque éditeur de champ possède son propre réplica à utiliser. Si de nombreux éditeurs doivent réaliser simultanément une synchronisation, il est préférable que chacun dispose de sa propre version à partir de laquelle créer un réplica. Cela simplifie la synchronisation et évite de collecter des données conflictuelles.

Utilisateurs mobiles ou équipe de terrain dans le cadre d’un possible scénario de données réparties

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. Les données renvoyées à l’organisation par le prestataire peuvent ensuite être synchronisées avec les données conservées dans la géodatabase d’entreprise.

Dispositif en lecture seule d’un prestataire tiers dans le cadre d’un possible scénario de données réparties

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 aux conditions de chaque groupe, l’organisation compte 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 transmises aux lecteurs.

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

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. Un groupe peut être chargé de la gestion des ressources matérielles, et un autre de la gestion des données foncières de base pour la même surface. 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 de projet reçoit un réplica des données nécessaires de la géodatabase d’entreprise centrale. Ensuite, les équipes mettent à jour chaque réplica indépendamment, éventuellement à des emplacements géographiques distincts, puis transfèrent ces mises à jour vers la géodatabase d’entreprise centrale. Réciproquement, les mises à jour apportées à la géodatabase d’entreprise centrale sont transférées vers le réplica correspondant des équipes de projet.

Structure de gestion multigroupe des données d’un possible scénario de données réparties

Centralisation des données de plusieurs 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.

Prenons pour exemple la distribution des données entre les bureaux d’un État et un bureau national. 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