Disponible avec une licence Standard ou Advanced.
Le versionnement traditionnel 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. Il parvient à ce résultat en stockant les mises à jour dans des tables secondaires nommées tables de deltas.
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 effectuer une mise à jour (d’une autre partie du réseau, de l’atelier ou de la topologie) 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 initialement à une géodatabase à partir d’ArcGIS, vous vous connectez à la version par défaut. Pour se connecter à une version différente et conserver cette information dans le fichier de connexion à la base de données (.sde), vous devez spécifier la version dans les propriétés de la géodatabase.
Qu'est-ce qu'une version ?
Une version est un type de vue de la géodatabase qui compartimente les mises à jour. Lorsque différents utilisateurs se connectent à la même version, ils voient les mises à jour qui ont été effectuées dans cette version. Les clients connectés à d’autres versions ne voient pas les modifications tant que vous ne les avez pas réconciliées et réinjectées dans une version Ascendant commun.
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 que vous publiez ou utilisez comme système d’archivage officiel car il représente 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 de géodatabase
Vous créez une version traditionnelle à l’aide d’une géodatabase en créant des enfants ou des branches à partir d’une version traditionnelle existante. La première version que vous créez est une version enfant de la version Par défaut. A sa création, cette 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 version enfant.
Une géodatabase peut avoir de nombreuses versions traditionnelles. La capture d’écran suivante montre la boîte de dialogue Version Manager (Gestionnaire de versions) in ArcMap. 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 traditionnelles 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 traditionnelles et des mises à jour versionnées
Avant de commencer à effectuer des mises à jour versionnées des données d’une version traditionnelle quelconque, vous devez inscrire les jeux de données pour qu’elles participent au versionnement traditionnel.
Lorsque vous inscrivez un jeu de données (une classe d’entités, un jeu de classes d’entités ou une table) à utiliser dans des workflows de versionnement traditionnel, 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 est inscrit pour versionnement traditionnel et 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 de la géodatabase à laquelle vous étiez connecté lorsque vous avez effectué les mises à jour qui ont renseigné les tables de deltas. Lorsque vous interrogez ou affichez un jeu de données dans une version de géodatabase, 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 d’une classe d’entités ou d’une 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 d’états est élevé et plus les tables sont grandes, 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.
Enregistrer les 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 dans le cadre de leur participation au versionnement traditionnel, 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 immédiatement 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 :
- La réalisation de vos mises à jour ne prend que quelques minutes.
- Les données ne font pas partie d'un réseau ou d'une topologie.
- Vous pouvez utiliser une application tierce pour accéder à une géodatabase qui utilise le versionnement traditionnel.
La plupart des applications tierces interrogent uniquement la table de base : elles ne peuvent pas accéder aux tables de deltas. Si vous utilisez le versionnement traditionnel et décidez de ne pas déplacer les mises à jour vers la table de base, ces applications n’incorporeront pas les mises à jour 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 mettez à jour des versions autres que Par défaut, les modifications sont enregistrées dans les mêmes tables de deltas. Lorsque vous enregistrez vos mises à jour dans d’autres versions, les modifications restent dans les tables de deltas. Cependant, lorsque vous combinez des modifications dans la version Par défaut via les processus de réconciliation et de réinjection, 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 de la géodatabase (personne qui la crée) ou l’administrateur de la géodatabase peut attribuer les autorisations permettant d’accéder à une version. Les options d'autorisation d'accès sont les suivantes :
- Private (Privée) : seul le propriétaire de la version ou l’administrateur de la géodatabase peut afficher et modifier les jeux de données dans cette version.
- Protected (Protégée) : n’importe quel utilisateur peut afficher les données dans la version, mais seul le propriétaire ou l’administrateur de la géodatabase peut les mettre à jour.
- Public : n’importe quel utilisateur peut afficher et mettre à jour les données, à condition qu’il dispose des privilèges de mise à jour sur les tables et classes d’entités.
L’accès à la version est défini lorsque la version est créée, mais il peut également être modifié par la suite par le propriétaire ou l’administrateur de la géodatabase dans la boîte de dialogue Version Manager (Gestionnaire de versions). Reportez-vous aux rubriques Création de versions et définition d'autorisation d'accès et Propriétés de la version pour plus d'informations.
Lorsqu’une table ou une classe d’entités a été enregistrée sous forme versionnée et que vous créez (si nécessaire) une version, d’autres éditeurs ou vous-même pouvez mettre à jour les données. Pour mettre à jour les données dans ArcMap, connectez-vous à la versionnement de la géodatabase à modifier et ajoutez la table ou la classe d’entités versionnée à la carte.
Par défaut, toutes les sessions de mise à jour dans ArcMap sont des sessions de mise à jour 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.
Les mises à jour que vous apportez s’appliquent à la version à laquelle vous êtes connecté lors de la mise à jour. 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. Pour cette raison, lorsque deux éditeurs utilisant les mêmes données, la même version ou une version différente, cela risque 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 de mise à jour.
Une fois la réconciliation et la résolution des conflits terminée, vous pouvez réinjecter les modifications. Cette opération applique les modifications que vous avez effectuées dans la version ascendante. Si vous n’avez plus besoin de la version depuis laquelle vous avez réinjecté des données (c’est-à-dire la version d’enfant), 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 traditionnelles, étudions le cas de ce réseau de distribution d’eau municipal. La compagnie 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.
Un éditeur crée une nouvelle version à partir de la version Par défaut et nomme la version Extension_project. Cette nouvelle version contient les mises à jour apportées à 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 Extension_project, 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.
Le personnel conclut 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 approuvée, vérifiée, réconciliée, puis réinjectée dans la version du Extension_project.
La construction de la nouvelle ligne d’attache est terminée quelques mois plus tard. Pour actualiser la version publiée de la géodatabase, la version Extension_project est vérifiée, réconciliée, puis réinjectée dans la version Default.
