Skip To Content

Stratégies de gestion des données d’entreprise

Les workflows utilisant des données géographiques peuvent être très variables en termes de durée et de complexité. Les géodatabases d’entreprise prennent en charge deux stratégies de gestion des données qui ajustent la nécessité d’effectuer des transactions longues et courtes sur les données pour les utilisateurs et les applications : la gestion des données avec versions et sans versions. L’approche non versionnée gère la mise à jour de transactions courtes tandis que le versionnement traite les transactions longues.

Chaque stratégie, qu’elle soit avec ou sans versions, peut être appliquée classe d’entités par classe d’entités ou table par table, de sorte qu’il est possible d’utiliser les deux dans la même géodatabase d’entreprise. La gestion des données versionnées est déclinée en trois options : le versionnement de branche, le versionnement traditionnel et le versionnement avec option de déplacement des mises à jour dans la base. La stratégie que vous choisissez est déterminée par les fonctionnalités dont vous souhaitez disposer dans votre SIG car les types de données que vous pouvez mettre à jour et les types de workflows que vous pouvez effectuer diffèrent.

Reportez-vous à la table suivante récapitulant les options de processus prises en charge dans une géodatabase d’entreprise :

Types de donnéesVersionnement de brancheVersionnement traditionnelVersionnement traditionnel (déplacement des mises à jour dans la base)Mise à jour non versionnée

Classe d'entités

Oui Oui Oui Oui

Tableau

Oui Oui Oui Oui

Annotation

Oui Oui Oui Oui

Cotation

Oui Oui Oui Oui

Classe de relations

Oui Oui Oui Oui

Réseau de distribution

Oui

Atelier parcellaire

Oui

Topologie

Oui

Jeu de données réseau

Oui

Jeu de données de MNT

Oui

Gestion des données sans versions

Cette stratégie n’implique pas l’utilisation de plusieurs versions des données. Elle recourt simplement au modèle de transaction SGBD sous-jacent. Les mises à jour non versionnées équivalent aux transactions courtes de base de données standard.

Pour mettre à jour des données, cliquez sur l’onglet Edit (Modifier) sur le ruban et exécutez les opérations requises, telles que l’ajout, la suppression ou le déplacement d’entités, ainsi que la mise à jour d’attributs. Votre première mise à jour dans la session de mise à jour initie la transaction et chaque opération de mise à jour que vous exécutez est validée dans la base de données en tant que transaction unique. Lorsque vous mettez à jour des données non versionnées dans ArcGIS Pro, chaque transaction est automatiquement validée dans la base de données sans avoir besoin d’enregistrer les mises à jour. Les modifications que vous apportez sont disponibles pour tous les autres utilisateurs et applications qui accèdent aux données lorsque votre transaction est terminée.

Mise à jour de données non versionnées

Lorsque vous procédez à une mise à jour, les index uniques, les contraintes et les déclencheurs définis sur les données avec le SGBD s'appliquent. Le comportement de verrouillage qui s'applique est le même que si vous effectuiez des transactions sur les données avec le SGBD directement. Par conséquent, il est possible que les utilisateurs ou applications qui accèdent ou modifient les mêmes données se bloquent mutuellement.

Remarque :

Lorsque vous utilisez la mise à jour non versionnée dans un environnement de mise à jour multi-utilisateurs, vous devez comprendre le fonctionnement des niveaux d'isolement et du verrouillage dans votre SGBD et, le cas échéant, définir le niveau d'isolement approprié dans le SGBD avant de commencer à utiliser ArcGIS.

Cette stratégie est idéale pour les entités simples pour lesquelles vous n’avez pas besoin d’utiliser plusieurs représentations des données au sein des versions. Comme cette stratégie n’utilise pas de versions, elle est également utile si vous souhaitez que des applications SIG et non SIG partagent l’accès à une base de données commune.

Avantages

Les avantages de la gestion des données non versionnées sont les suivants :

  • Intégrez facilement des données géographiques dans des applications existantes en autorisant des applications tierces (celles non créées avec un logiciel Esri) à lire et à modifier les données auxquelles les applications ArcGIS accèdent. Ainsi, les partenaires commerciaux d’Esri créent souvent des compléments et des applications d’extension qui nécessitent un accès ouvert pour la mise à jour des données stockées dans le SGBD sous-jacent.
  • Gérez des projets avec des mises à jour et des workflows simples. Si les transactions sont toujours simples et de courte durée, vous pouvez modifier directement les données sans avoir à combiner les modifications et gérer régulièrement des tables supplémentaires requises pour les versions.

Limitations

Les limitations de la gestion des données non versionnées sont les suivantes :

  • Vous pouvez seulement mettre à jour des entités simples telles que des points, des lignes, des polygones, des annotations et des relations. Vous n’êtes pas autorisé à mettre à jour des classes d’entités faisant partie d’une topologie, d’un réseau technique, d’un atelier parcellaire ou d’autres jeux de données comportant des fonctions avancées.
  • Comme vous modifiez directement la source de données, vous ne pouvez pas annuler ni répéter une modification en cas d'erreur.
  • Aucune détection des conflits n'a lieu avec la mise à jour non versionnée. Si un utilisateur met à jour une entité et l’enregistre, puis qu’un autre utilisateur met à jour la même entité et l’enregistre, la dernière mise à jour apportée remplace la première.
  • Dans les scénarios de mise à jour multi-utilisateurs, lorsqu’un utilisateur met à jour une entité, des verrouillages sont appliqués par le SGBD pour empêcher d’autres éditeurs d’effectuer des mises à jour simultanées sur la même entité.

Gestion des données avec versionnement

La géodatabase d’entreprise utilise le versionnement pour prendre en compte les besoins des scénarios de mise à jour multi-utilisateurs et les transactions longues. La géodatabase optimise le modèle de transaction SGBD standard en autorisant plusieurs états concurrents des bases de données, connus sous le nom de versions, à coexister en même temps. Cela permet à plusieurs utilisateurs de mettre à jour simultanément les mêmes données de la géodatabase sans appliquer de verrouillages ni dupliquer de données.

Les éditeurs peuvent utiliser leur propre version de la géodatabase de telle sorte que les autres utilisateurs ne voient pas un travail incomplet et ne se voient pas bloquer l’accès aux données.

Chaque version peut représenter le travail en cours (tel qu'une création ou un groupe de commandes de travaux), travail qui peut couvrir plusieurs connexions à la base de données et se prolonger sur une période de plusieurs semaines ou mois, le cas échéant. Lorsqu’un éditeur a terminé ses tâches, il peut intégrer ses changements dans la version parent.

Voici quelques exemples de workflows utilisant les versions :

  • Projets exigeant une analyse hypothétique : création d’une nouvelle conception dans une version distincte. Si la conception est approuvée, vous pouvez la combiner avec le reste de la base de données. Si elle n'est pas approuvée, vous pouvez l'ignorer.
  • Projets avec des exigences spécifiques en matière d’assurance qualité : collecte des modifications apportées aux données, par exemple des importations par lots, dans une version isolée des autres utilisateurs de base de données. Test et approbation des modifications avant de les combiner avec la version publiée de la base de données.
  • Projets qui divisent le travail en plusieurs unités fonctionnelles ou géographiques : par exemple, un projet de conception et de construction d’un nouveau centre commercial peut être organisé en plusieurs phases de construction distinctes, subdivisées en sections est et ouest, ou en activités de construction telles que la construction des bâtiments, l’installation des équipements ou l’aménagement du paysage. Chaque unité de travail est exécutée dans une version distincte. Au fur et à mesure de l'achèvement de chaque version, elle est réinjectée dans la version publiée de la base de données.
  • Projets qui se déroulent selon un certain nombre d’étapes prescrites et réglementées nécessitant une phase d’ingénierie, d’administration ou d’approbation légale avant d’être considérée comme terminées : les processus de ces projets peuvent gérer chaque étape en tant que version distincte, telle qu’une conception initiale ou une version proposée, une version approuvée et une version destinée à la phase de construction. Au fur et à mesure des différentes phases d’un projet, chaque étape est révisée et approuvée, puis remplacée par la version suivante jusqu’à ce que la dernière étape soit atteinte et terminée.
  • Projets qui demandent aux membres des équipes de maintenance sur le terrain de mettre à jour les données avec des appareils portables : les opérateurs (editors) sur le terrain peuvent utiliser leur propre version et fusionner les modifications avec les mises à jour des autres editors lorsqu’ils reviennent au bureau.

Chaque géodatabase d’entreprise dispose d’une version nommée Default (Par défaut). Contrairement à d'autres versions, la version Par défaut existe toujours et ne peut pas être supprimée. Dans la plupart des stratégies de workflow, il s'agit la version publiée de la base de données, représentant l'état actuel du système modélisé. Vous gérez et mettez à jour la version Par défaut au fil du temps en y réinjectant les modifications effectuées dans d'autres versions. Vous pouvez également mettre à jour la version Default (Par défaut), tout comme n’importe quelle autre version. La version Par défaut est la version racine et donc l'ascendant de toutes les autres versions.

Arborescence de versions simple

Le versionnement permet la flexibilité et l’évolutivité de vos stratégies de gestion des données. Deux types de versionnement sont disponibles, chacun répondant aux besoins particuliers des workflows et des options de déploiement :

  • Versionnement de branche
  • Versionnement traditionnel
    • Versionnement traditionnel avec l’option de déplacement des mises à jour dans la table de base

Versionnement de branche

La plateforme ArcGIS est un SIG Web complet, à savoir un système de systèmes capable de partager des données avec et entre des individus, des équipes et des organisations. Cela est rendu possible grâce à la collaboration via des services en ligne ou au sein du portail d’une organisation. Le versionnement de branche est le mécanisme sous-jacent aux transactions longues des services. Si vous avez besoin que plusieurs éditeurs accèdent simultanément aux services avec la possibilité d’annuler et de rétablir leurs mises à jour, vous devez d’abord inscrire vos données en tant que branche versionnée.

Si un jeu de données inscrit en tant que branche versionnée est partagé sous forme de service, vous pouvez activer la fonctionnalité Version Management (Gestion des versions) au moment de la publication. Cela crée un service de gestion des versions (VM Service dans l’image ci-dessous) qui facilite la création et la gestion des versions. Les éditeurs peuvent ensuite commencer à utiliser leurs services d’entités dans leurs propres versions, à mettre à jour les données et à fusionner leurs modifications avec la version Default (Par défaut) une fois qu’ils ont terminé.

Mise à jour avec le versionnement de branche

Avantages

Les avantages du versionnement de branche sont les suivants :

  • La mise à jour et l’administration des versions sont réalisées au sein de l’environnement de portail ArcGIS Enterprise.
  • Annulez et rétablissez les modifications au cours de la mise à jour des services d’entités.
  • ArcGIS offre la possibilité de détecter, réconcilier et résoudre facilement les conflits.
  • La résolution des conflits intervient simultanément et sur plusieurs sessions.
  • Vous pouvez mettre à jour les entités d’un réseau technique ou d’un atelier parcellaire. Ces jeux de données basés sur des services sont uniquement disponibles par le biais d’un déploiement SIG Web.
  • Des fonctionnalités améliorées de suivi de l’éditeur vous permettent également d’assurer le suivi des utilisateurs qui suppriment des entités d’une version.
  • A la différence du versionnement traditionnel, l’opération de compression n’est pas requise pour les géodatabases comportant des jeux de données de branche versionnée.

Limitations

Les limitations du versionnement de branche sont les suivantes :

  • Les jeux de données faisant partie d’une branche versionnée ne sont pas accessibles dans ArcMap et ArcGIS Pro 2.1, ni une version antérieure de ces produits.
  • La mise à jour n’est pas disponible si vous accédez directement aux jeux de données de branche versionnée à partir de la connexion à une base de données.
  • Les entités simples, les tables, les annotations, les dimensions, les classes de relations, les réseaux techniques et les ateliers parcellaires sont pour l’instant les seuls jeux de données disponibles dans le cadre de la mise à jour par le biais du versionnement de branche. Si vous souhaitez mettre à jour la topologie, un jeu de données réseau ou un jeu de données de MNT dans un environnement versionné, vous devez utiliser le versionnement traditionnel.
  • Le versionnement de branche n’autorise qu’un seul éditeur par version de branche et plusieurs lecteurs. Lorsqu’un éditeur commence à effectuer une mise à jour dans une version de branche, un verrouillage exclusif est mis en place et aucun utilisateur ne peut plus se connecter à la version.

Versionnement traditionnel

Si vous n’utilisez pas de services d’entités nécessitant des transactions longues, mais que vous souhaitez pouvoir bénéficier de la mise à jour multi-utilisateurs et des avantages de workflow offerts par les versions, vous pouvez utiliser le versionnement traditionnel comme stratégie de gestion des données. Vous bénéficiez ainsi de la flexibilité permettant de prendre en compte plusieurs éditeurs et des versions isolées pour gérer vos workflows, comme les scénarios hypothétiques, l’analyse prédictive et les propositions de lieu de travail.

Le versionnement traditionnel est destiné aux utilisateurs qui emploient des workflows de mise à jour multi-utilisateurs en accédant à la géodatabase d’entreprise directement via la connexion à la base de données. Si vous devez utiliser des versions pour les transactions longues lorsque l’accès s’effectue directement à partir de la géodatabase d’entreprise mais que vous n’avez pas besoin de ce niveau de fonctionnalités de gestion des versions pour les données partagées au niveau du service d’entités, il est conseillé d’employer le versionnement traditionnel. Les jeux de données peuvent toujours être partagés via des services d’entités, mais ils ne disposent pas du même niveau de fonctionnalités de gestion des versions multi-utilisateurs (par exemple, la version à partir de laquelle vous effectuez la publication est la version que vous mettez à jour et il n’est pas possible d’annuler ni de rétablir des mises à jour).

Une géodatabase d’entreprise peut avoir un nombre illimité de versions traditionnelles. Les versions peuvent être organisées dans différentes configurations et prennent en charge toute une gamme de workflows, notamment les hiérarchies multi-niveaux comportant des versions petits-enfants, des versions arrière-petits-enfants, etc. Toutefois, par souci de simplicité et pour la bonne gestion des géodatabases, nous vous recommandons de conserver une arborescence des versions plate ou d’autoriser la mise à jour simultanée de la version Default (Par défaut) par plusieurs éditeurs.

Mise à jour avec les versions traditionnelles

Avantages

Les avantages du versionnement traditionnel sont les suivants :

  • L’environnement de mise à jour isolé permet des scénarios de déploiement multi-utilisateurs flexibles.
  • Mise à jour des jeux de données avancés tels que les jeux de données réseau et les topologies.
  • Annulation et rétablissement des modifications au cours de la mise à jour.
  • Mise à jour sans blocage des autres éditeurs. Détection et réconciliation facilitées des conflits.

Limitations

Les limitations du versionnement traditionnel sont les suivantes :

  • En fonction du nombre de versions et du volume des mises à jour, il est nécessaire d’effectuer régulièrement un certain nombre de tâches d’administration sur les versions afin d’assurer le bon fonctionnement de votre système.
  • Les applications tierces doivent être adaptées avec des vues versionnées pour lire les données.
  • Des restrictions s’appliquent à l’utilisation du comportement du SGBD actif, par exemple des déclencheurs et des contraintes uniques lorsque vous utilisez des données versionnées.
  • Il n’existe aucune fonctionnalité de gestion des versions lors de l’utilisation de services.

Versionnement traditionnel avec l’option de déplacement des mises à jour dans la table de base

Dans un environnement informatique hétérogène où plusieurs applications départementales différentes accèdent à la même base de données, vous pouvez être amené à prendre en charge à la fois des applications ArcGIS et tierces. Si tel est le cas, vous pouvez enregistrer vos données comme versionnées avec l’option de déplacement des mises à jour dans la table de base. Cette stratégie de gestion des données hybride vous permet de créer des versions répondant aux besoins des transactions longues et des mises à jour multi-utilisateurs, et d’effectuer des mises à jour dans la version Default (Par défaut) en tant que transactions courtes immédiatement accessibles par toutes les applications accédant à la base de données.

Cela se produit par exemple lorsqu’un département gère les données géographiques dans la base de données avec ArcGIS Pro et qu’un autre département gère les enregistrements client dans la même base de données avec une application personnalisée. L'application personnalisée doit appliquer les contraintes et déclencheurs du SGBD lorsque les transactions sont créées et risque de ne pas reconnaître les tables versionnées. En même temps, l'autre département doit mettre à jour les données géographiques dans sa propre version isolée, sans partager les mises à jour départementales tant qu'elles ne sont pas terminées et approuvées.

En gardant ces exigences à l’esprit, le versionnement avec l’option de déplacement des mises à jour dans la table de base vous permet d’effectuer des mises à jour versionnées dans une classe d’entités ou une table tout en conservant la possibilité de partager les mises à jour avec d’autres applications. L’option de déplacement des mises à jour dans la table de base autorise l’utilisation de la même base de données par toutes les applications.

Mise à jour avec des versions et avec l’option de déplacement des mises à jour dans la table de base

Avantages

Les avantages du versionnement avec l’option de déplacement des mises à jour dans la table de base sont les suivants :

  • Mêmes avantages que le versionnement traditionnel.
  • Fonctionnement des transactions longues dans une version nommée et des transactions courtes lors de la mise à jour de la version Default (Par défaut).
  • Prise en charge de projets nécessitant un accès simultané aux données par ArcGIS Pro et d’autres applications.

Limitations

Les limitations du versionnement avec l’option de déplacement des mises à jour dans la table de base sont les suivantes :

  • Vous pouvez uniquement mettre à jour des entités simples comme des points, des lignes, des polygones, des annotations et des relations. Vous ne pouvez pas modifier de classe d’entités dans une topologie, un jeu de données réseau ou un réseau de distribution.
  • Lorsque vous mettez à jour la version Default (Par défaut) ou que vous réinjectez une version dans Default (Par défaut), vous n’avez pas la possibilité de résoudre les conflits. Par conséquent, il est possible de remplacer les mises à jour d’un autre utilisateur.

Pour plus d’informations sur le versionnement et sur les processus qu’il fournit, reportez-vous à la rubrique Présentation du versionnement