Présentation rapide du versionnement

Cette rubrique s'applique uniquement à ArcGIS for Desktop Standard et ArcGIS for Desktop Advanced.

Le versionnement permet à plusieurs utilisateurs de modifier les mêmes données dans une géodatabase ArcSDE sans appliquer de verrouillages ni dupliquer des données.

Pour mettre à jour des classes d'entités participant à une topologie, à un jeu de données réseau ou à un réseau géométrique, ou pour modifier un atelier parcellaire, vous devez inscrire les données comme étant versionnées. En effet, lorsque vous mettez à jour une entité dans un réseau, un atelier parcellaire ou une topologie, les entités ne sont pas toutes verrouillées, ce qui signifie que les autres éditeurs peuvent mettre à jour une autre partie du réseau, de l'atelier ou de la topologie d'une manière entrant en conflit avec vos modifications.

Les utilisateurs accèdent toujours à une géodatabase ArcSDE à l'aide d'une version. Lorsque vous vous connectez à une géodatabase multi-utilisateurs, vous spécifiez la version à laquelle vous vous connecterez. Par défaut, vous vous connectez à la version DEFAULT.

La version DEFAULT

Chaque géodatabase ArcSDE comporte une version par défaut appelée DEFAULT ; ainsi, le versionnement est toujours activé pour la géodatabase. Il s'agit d'un composant essentiel du fonctionnement d'ArcGIS qui n'a pas besoin d'être installé ou configuré séparément.

Contrairement à d'autres versions, la version DEFAULT 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 maintenez et mettez à jour la version DEFAULT dans le temps en y réinjectant les modifications effectuées dans les autres versions. Vous pouvez également directement mettre à jour la version DEFAULT, tout comme n'importe quelle autre version.

La version DEFAULT est la version racine et donc l'ascendant de toutes les autres versions.

Création d'autres versions

Vous créez une version à l'aide des enfants ou branches d'autres versions existantes. Vous créez la première version en générant une version enfant de la version DEFAULT. Cette nouvelle version est identique à la version DEFAULT. Avec le temps, les versions divergent au fur et à mesure que des modifications sont apportées à la version DEFAULT et à la nouvelle version.

Une géodatabase peut avoir de nombreuses versions. Voici la boîte de dialogue Gestionnaire de versions, qui est accessible par l'intermédiaire d'ArcGIS for Desktop. Cet exemple montre l'arborescence de la boîte de dialogue, en illustrant la version DEFAULT et les quatre autres versions, ainsi que la façon dont elles sont liées. Les versions Base et Affaires sont des enfants de la version DEFAULT et les versions Affaires1 et Affaires2 sont des enfants de la version Affaires.

La création d'une version vous donne la fausse impression que vous créez une copie de la géodatabase entière. Ceci s'explique par le fait que chaque version comporte toutes les tables et classes d'entités de la géodatabase. Lorsque vous mettez à jour une classe d'entités ou une table dans une version, la classe d'entités ou table de la version parent n'est plus la même et vous avez donc l'impression de stocker la classe d'entités ou la table dans chaque version. Quel que soit le nombre de versions que vous utilisez, chaque table et classe d'entités est stockée seulement une seule fois dans la base de données. ArcGIS conserve chaque classe ou table d'entités dans son format original, mais enregistre toutes les modifications dans des tables appelées tables de deltas.

Les utilisateurs peuvent modifier toutes les versions simultanément. Plusieurs utilisateurs peuvent également modifier simultanément la même version.

Fonctionnement des versions et des mises à jour versionnées

Avant de commencer à effectuer des mises à jour versionnées des données d'une version quelconque, vous devez inscrire les jeux de données comme étant versionnés.

Sachez que l'inscription d'un jeu de données comme versionné est différent de la création d'une version. La création d'une version crée une sorte d'"affichage" de la géodatabase qui vous permet de mettre à jour les données versionnées et de voir immédiatement les changements apportés. Les autres utilisateurs connectés à la même version verront les changements lorsqu'ils actualiseront l'affichage. Cependant, les utilisateurs connectés à d'autres versions ne verront pas les changements tant que vous ne les aurez pas réconciliés et réinjectés dans une version ascendant. Dans l'exemple ci-dessus, une fois les modifications réinjectées dans la version DEFAULT, ceux-ci sont visibles quelle que soit la version à laquelle vous êtes connecté.

En revanche, l'inscription d'un jeu de données (classe d'entités, jeu de données d'entité ou table) comme versionné le prépare pour une mise à jour versionnée. Lorsque vous inscrivez un jeu de données comme versionné, deux tables de deltas sont créées : la table A (ou ajouts) pour les insertions et les mises à jour et la table D (ou suppressions) pour les suppressions. A chaque mise à jour ou suppression d'un enregistrement dans le jeu de données, des lignes sont ajoutées à l'une de ces tables, voire les deux. Un jeu de données versionné contient par conséquent la table d'origine (appelée table de base) ainsi que toutes les modifications apportées aux tables de deltas. La géodatabase enregistre la version à laquelle vous étiez connecté lorsque vous avez effectué les modifications qui ont renseigné les tables de deltas. Lorsque vous interrogez ou affichez un jeu de données dans une version, ArcGIS assemble les lignes correspondantes de la table d'origine et des tables de deltas afin de fournir une vue optimale des données de cette version.

Toutes les modifications de la classe ou table d'entités, quelle que soit la version à partir de laquelle elles ont été effectuées, sont enregistrées dans les mêmes tables de deltas. Regroupées, toutes les lignes de la table de base A de tables D représentent toutes les versions de la classe ou table d'entités. Cela signifie que chaque version référence uniquement un sous-ensemble de lignes des trois tables. Comment le système ArcGIS parvient-il à associer les lignes des tables de deltas à chaque version ?

Chaque ligne des tables A et D comporte un identifiant entier appelé identifiant d'état qui enregistre le moment où la ligne est ajoutée à la table. Chaque fois que vous modifiez une version, un nouvel état est créé et une nouvelle ligne est ajoutée à l'une de ces tables voire les deux. Les états s'apparentent à une partie d'arborescence dans laquelle chaque branche enregistre l'évolution d'une version. Une généalogie est une séquence d'états permettant d'enregistrer une série de modifications de la table de base vers l'état actuel de la version. Lorsque vous affichez ou interrogez une version, ArcGIS interroge la généalogie d'une version afin d'obtenir les identifiants d'état, puis extrait les enregistrements correspondants des tables A et D.

Au fur et à mesure qu'une géodatabase est modifiée, la taille des tables de deltas et le nombre d'états augmentent. Plus le nombre de tables et d'états est élevé, plus ArcGIS doit traiter de données à chaque fois que vous affichez ou interrogez une version. Pour maintenir les performances de la base de données, l'administrateur ArcSDE doit régulièrement exécuter la commande Compresser afin de supprimer les données inutilisées, puis la commande Analyser afin d'actualiser les statistiques de la base de données.

Pour en savoir plus sur l'opération de compression de géodatabase

Inscription des données comme versionnées avec l'option d'enregistrement des mises à jour dans la table de base

Lorsque vous inscrivez comme versionnées des données qui ne font pas partie de réseaux ou de topologies, vous pouvez spécifier si vous souhaitez déplacer les modifications apportées à la version DEFAULT vers les tables de base. Si vous spécifiez cette option, les modifications sont toujours inscrites dans les tables de deltas. Cependant, lorsque vous enregistrez la version, les modifications sont déplacées des tables de deltas vers la table de base (elles ne restent pas dans les tables de deltas).

Utilisez cette option lors de l'enregistrement des données comme versionnées si les modifications que vous effectuez ne prennent que quelques minutes et si vous vous connectez à une géodatabase versionnée à partir d'une application tierce.

Les applications tierces sont généralement configurées pour interroger uniquement la table de base : elles ne peuvent pas accéder aux tables de deltas. Si vous utilisez le versionnement et décidez de ne pas déplacer les modifications vers la table de base, ces applications n'incorporeront pas les modifications apportées aux autres versions qui n'ont pas été réconciliées ni réinjectées dans la version DEFAULT. Pour rappel, lorsque vous modifiez des versions autres que DEFAULT, les modifications sont enregistrées dans les mêmes tables de deltas. Lorsque vous enregistrez la version, les modifications restent dans les tables de deltas. Cependant, lorsque vous fusionnez des modifications dans la version DEFAULT, ces modifications sont déplacées des tables de deltas vers les tables de base. La fusion des modifications dans des versions autres que DEFAULT permet de conserver ces modifications dans les tables de deltas, comme si vous n'aviez pas indiqué que les les mises à jour devaient être enregistrées dans la table de base.

Autorisations et mise à jour d'une version

Le propriétaire de la version (personne qui la crée) peut définir qui peut accéder à la version. Les options d'autorisation d'accès sont les suivantes :

• Privée : seul le propriétaire de la version peut afficher et modifier les jeux de données dans cette version.
• Protégée : n'importe quel utilisateur peut afficher les jeux de données dans la version, mais seul le propriétaire peut les modifier.
• Public : n'importe quel utilisateur peut afficher et modifier les jeux de données, à condition qu'il dispose d'autorisations sur les jeux de données.

L'accès à la version est défini lorsque la version est créée, mais il peut également être modifié dans la boîte de dialogue Gestionnaire de versions. Reportez-vous aux rubriques Création de versions et définition d'autorisation d'accès et Utilisation des propriétés de version pour plus d'informations.

Vous pouvez mettre à jour les données dans une version spécifique dans ArcGIS en vous connectant à une version spécifique et en ajoutant des données qui ont été inscrites comme versionnées dans ArcMap.

Astuce:

Vous pouvez également changer la version à laquelle elles sont connectées dans ArcMap. Reportez-vous à la rubrique Changement de version dans ArcMap pour plus d'informations.

Par défaut, toutes les sessions de mise à jour dans ArcMap sont des sessions de modifications versionnées. Par conséquent, si vous avez des données versionnées dans votre carte, vous pouvez commencer la mise à jour dès que vous ouvrez une session de mise à jour. Pour ouvrir une session de mise à jour, cliquez sur Ouvrir une session de mise à jour dans la liste déroulante Editeur de la barre d'outils Editeur.

Les modifications apportées à chaque version ne s'appliquent qu'à cette version. Cette règle ne concerne pas les mouvements de structure. Lorsque vous modifiez la structure d'une version, en ajoutant par exemple un nouveau champ à une table, la modification s'applique à toutes les autres versions. Seuls les propriétaires des données peuvent modifier la structure d'un jeu de données.

Lorsque vous avez fini la mise à jour, vous réconciliez vos modifications et vous les réinjectez dans une version ascendant.

Réconciliation et réinjection de modifications

Réconcilier et réinjecter intègre vos changements dans toute version qui est un ascendant de la version sur laquelle vous travaillez, telle que la version parent ou DEFAULT. Lors de la réconciliation, les modifications de la version que vous mettez à jour sont comparées avec la version dans laquelle vous voulez les fusionner.

Lorsque vous modifiez les données d'une version, aucun verrouillage n'est appliqué aux données. Deux éditeurs utilisant les mêmes données, la même version ou une version différente, risquent de générer des conflits. Un conflit survient lorsqu'une ligne est différente dans les deux versions comparées. Le processus de réconciliation vous indique chaque conflit et vous permet de choisir la représentation de ligne à conserver.

En pratique, la modification des conflits reste exceptionnelle car le volume des modifications est négligeable comparé à la quantité des données géographiques utilisées. Dans des workflows correctement conçus, le coût des conflits de réconciliation est largement compensé par le fait que vous n'avez pas besoin de verrouiller ni d'extraire les entités tout au long de la transaction.

Une fois la réconciliation terminée, vous pouvez réinjecter les modifications. Cette opération applique les modifications que vous avez effectuées dans l'autre version. Si vous n'avez plus besoin de la version depuis laquelle vous avez réinjecté des données, vous pouvez la supprimer. Vous pouvez poursuivre la mise à jour de la version, puis réconcilier et réinjecter les modifications ultérieurement.

Astuce:

Au lieu d'une réconciliation manuelle, vous pouvez utiliser l'outil de géotraitement Réconcilier les versions pour réconcilier plusieurs versions ou un script Python pour réconcilier par lot et publier des versions.

Versions : Exemple

Pour illustrer les différentes utilisations possibles des versions, étudions le cas de ce réseau de distribution d'eau municipal. Le réseau de distribution d'eau dispose d'une géodatabase d'entités représentant l'état actuel de l'ensemble des conduites, vannes, pompes et autres composants du système. Une nouvelle ligne d'attache doit être ajoutée au réseau de distribution.

Le réseau crée une nouvelle version de la version DEFAULT appelée Projet d'extension, qui contiendra la conception de la nouvelle extension. Cependant, le personnel du réseau se demande si la nouvelle extension doit être équipée d'une conduite avec un diamètre de 16 ou 24 pouces. Grâce à la version Projet d'extension, ils peuvent ainsi étudier deux versions : une avec une conduite d'un diamètre de 16 pouces, et une autre avec une conduite d'un diamètre de 24 pouces.

Ils en concluent que la conduite d'un diamètre de 24 pouces permettra de couvrir les besoins d'alimentation en eau pour les 12 prochaines années et que par conséquent son coût de construction supérieur est justifié. La version 24 pouces est donc adoptée, vérifiée, puis réinjectée dans la version du projet d'extension.

Quelques mois plus tard, la nouvelle ligne d'attache est construite. Pour actualiser la version publiée de la base de données, la version du projet d'extension est vérifiée, réconciliée, puis réinjectée dans la version DEFAULT.