Disponible avec une licence Standard ou Advanced.
Le versionnement permet à plusieurs éditeurs de modifier les mêmes données dans une géodatabase d'entreprise ou de groupe de travail 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.
Vous accédez toujours à une géodatabase d'entreprise ou de groupe de travail en spécifiant une version. Lorsque vous vous connectez, vous spécifiez la version à laquelle vous vous connecterez. Par défaut, vous vous connectez à la version Par défaut.
Qu'est-ce qu'une version ?
Une version est un type de vue de la géodatabase qui compartimente les mises à jour. Grâce aux versions, tous les autres utilisateurs connectés à la même version voient vos modifications. Les utilisateurs connectés à d'autres versions ne voient pas les modifications tant que vous ne les avez pas réconciliés et réinjectés dans une version ascendante.
La version Par défaut
La version Par défaut est la version racine et donc l'ascendant de toutes les autres versions.
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 de la version publiée de la géodatabase, 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 Par défaut, tout comme n'importe quelle autre version.
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 Par défaut. Cette nouvelle version est identique à la version Par défaut. Avec le temps, les versions divergent au fur et à mesure que des modifications sont apportées à la version Par défaut 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 Par défaut 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 Par défaut et les versions Affaires1 et Affaires2 sont des enfants de la version Affaires.
La création d'une version vous donne l'impression que vous créez une copie de la géodatabase entière, mais ce n'est pas le cas. 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 versions peuvent être mises à jour simultanément par plusieurs utilisateurs.
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.
Lorsque vous inscrivez un jeu de données (une classe d'entités, un jeu de données d'entité ou une table) comme versionné, deux tables de deltas sont créées : la table A (ou ajouts), qui enregistre les insertions et les mises à jour et la table D (ou suppressions), qui stocke 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 ou métier), 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 mises à jour de la classe d'entités ou table sont enregistrées dans les mêmes tables de deltas, quelle que soit la version à partir de laquelle elles ont été effectuées. Cela signifie que chaque version référence uniquement un sous-ensemble de lignes des trois tables. Comment ArcGIS parvient-il à savoir quelles lignes des tables de deltas appartiennent à 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 de géodatabase doit régulièrement exécuter la commande Compresser afin de supprimer les données inutilisées.
L'option d'enregistrement des mises à jour dans la table de base
Si vous spécifiez l'option d'enregistrement des mises à jour dans la table de base lorsque vous inscrivez vos données comme versionnées, les modifications sont enregistrées dans les tables de deltas. Cependant, lorsque vous mettez à jour la version Par défaut et enregistrez vos mises à jour, les modifications sont déplacées des tables de deltas vers la table de base (elles ne restent pas dans les tables de deltas). Notez que cela n'est vrai que lorsque vous mettez à jour la version Par défaut. Les mises à jour apportées à des versions descendantes ne sont pas immédiatement déplacées dans la table de base.
L'option permettant de déplacer des entités dans la table de base est utile si ce qui suit est vrai :
- Les modifications que vous appliquez ne prendront que quelques minutes.
- Les données ne font pas partie d'un réseau ou d'une topologie.
- Vous êtes connecté à une géodatabase versionnée à l'aide 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 Par défaut. Pour rappel, lorsque vous modifiez des versions autres que Par défaut, 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 combinez des modifications dans la version Par défaut, elles sont transférées des tables de deltas vers les tables de base. La combinaison des modifications dans des versions autres que Par défaut permet de conserver ces modifications dans les tables de deltas, comme si vous n'aviez pas indiqué que les mises à jour devaient être enregistrées dans la table de base.
Autorisations et mises à 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.
Pour mettre à jour, vous connecter à une version de géodatabase spécifique depuis ArcMap et ajouter des données qui ont été inscrites comme versionnées sur la carte.
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, réconciliez vos modifications et réinjectez-les dans une version ascendante.
Réconcilier et réinjecter les modifications
La réconciliation et la réinjection des opérations permettent d'intégrer vos modifications dans toute version qui est un ascendant de la version sur laquelle vous travaillez, telle que la version parent ou Par défaut. 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.
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 Par défaut 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 Par défaut.
