Présentation rapide du versionnement

Cette rubrique concerne exclusivement ArcEditor et ArcInfo.

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.

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 Desktop. Cet exemple montre la version DEFAULT et trois autres versions : une version d'assurance qualité (QA) et des versions de projet, ProjectA et ProjectB.

Le diagramme suivant montre comment les relations entre les versions. Dans l'exemple ci-après, la version QA est un enfant de la version DEFAULT et les versions ProjectA et ProjectB sont des enfants de la version QA.

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.

Dans les exemples de versions ci-dessus, plusieurs éditeurs pourraient modifier simultanément les versions ProjetA et ProjetB. Un plus petit nombre d'utilisateurs pourraient effectuer des changements dans la version QA.

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 que les changements ont été réinjectés dans la version DEFAULT, ils sont visibles indépendamment de la version à laquelle vous êtes connecté. Par contre, l'inscription d'un jeu de données (classe d'entités, jeu de classes d'entités ou table) comme versionné le prépare pour la mise à jour versionnée. Lorsque vous inscrivez un jeu de données comme versionné, deux tables delta sont créées : la table A pour les insertions et les mises à jour et la table D 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 delta. 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 delta à 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 de la mise à jour d'une géodatabase, 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 les mises à jour apportées à la version DEFAULT doivent être enregistrées dans les tables de base. Si vous spécifiez cette option, les modifications continuent d'être enregistrées dans les tables delta. Cependant, lorsque vous enregistrez la version, les modifications sont déplacées des tables delta vers la table de base (elles ne restent pas dans les tables delta).

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 n'affichent pas les tables delta. Si vous utilisez le versionnement et décidez de ne pas déplacer les modifications vers la table de base, ces applications ne verront 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 delta. Lorsque vous enregistrez la version, les modifications restent dans les tables delta. Cependant, lorsque vous fusionnez des modifications dans la version DEFAULT, ces modifications sont déplacées des tables delta vers les tables de base. La fusion des modifications dans des versions autres que DEFAULT permet de conserver ces modifications dans les tables delta, comme si vous n'aviez pas activé l'option permettant d'enregistrer les mises à jour dans la table de base.

Autorisations et mise à jour d'une version

Le propriétaire de la version (la personne qui la crée) peut définir des permissions la concernant, afin de restreindre le nombre de personnes pouvant l'afficher et la modifier. Les options de permission sont privée (seul l'utilisateur peut afficher et modifier les jeux de données de la version), protégée (n'importe quel utilisateur peut afficher les jeux de données de la version, mais seul l'utilisateur peut les modifier) et publique (n'importe quel utilisateur peut afficher et modifier les jeux de données, si tant est qu'il détient une permission les concernant).

Comme vous pouvez le voir dans la boîte de dialogue Gestionnaire de versions ci-après, la version DEFAULT est protégée et les autres versions sont publiques.

Conseil :

Reportez-vous à la rubrique Création de versions et définition d'autorisations pour plus d'informations sur les autorisations de version.

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.

Conseil :

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.

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.

En fonction des privilèges attribués aux versions dans l'exemple QA/Projet, un workflow logique de réconciliation et de réinjection irait des versions de projets à la version QA, puis à la version DEFAULT.

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.