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 la gestion des données sans versions. L’approche non versionnée gère la mise à jour de transactions courtes tandis que celle qui est versionnée 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.
Le tableau suivant récapitule les options de workflow de mise à jour prises en charge avec ces types de jeux de données dans une géodatabase d’entreprise :
| Types de jeux de données | Versionnement de branche | Versionnement traditionnel | Versionnement traditionnel (déplacement des mises à jour dans la base) | Mise à jour non versionnée |
|---|---|---|---|---|
Classe d’entités |  | | | |
Tableau | | | | |
Annotation | | | | |
Dimension | | | | |
Classe de relations | | | | |
Classe d’entités d’objets 3D | | |||
Réseau de traces | | |||
Réseau de distribution | | |||
Atelier parcellaire | | |||
Topologie | | | ||
Jeu de données réseau | | |||
Jeu de données de MNT | |
Remarque :
En plus des types de jeux de données répertoriés dans le tableau ci-dessus, il existe d’autres fonctionnalités de géodatabase, telles que la réplication, l’archivage et les règles attributaires, qui ne fonctionnent qu’avec des jeux de données d’inscription de géodatabase spécifiques. Pour plus d’informations, consultez les rubriques se rapportant à chacune de ces fonctionnalités.
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 AllSource, chaque transaction est automatiquement validée dans la base de données ; il est donc inutile 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.
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. 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 des données géographiques dans des applications existantes en autorisant les 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 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.
- 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 enregistre sa modification, 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 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 conception ou un groupe de bons de travaux) 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 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 l’ascendant de toutes les autres versions.
Le versionnement permet la flexibilité et l’évolutivité des stratégies de gestion des données. Deux types de versionnement sont disponibles, chacun s’appliquant à des besoins particuliers des workflows et des options de déploiement :
Reportez-vous aux rubriques Scénarios de versionnement de branche et Scénarios de versionnement traditionnel pour découvrir des configurations illustrant l’application de la technologie de versionnement dans une organisation.
Vous avez un commentaire à formuler concernant cette rubrique ?