Scénarios de versions

Cette rubrique présente l'application du versionnement (mode d'application de cette technologie dans une organisation) ainsi que les configurations de version disponibles.

Les workflows présentent de grandes variations entre les différentes organisations. Ils évoluent souvent selon des étapes discrètes, chaque étape nécessitant l'attribution d'un ensemble différent de ressources et de règles commerciales. Généralement, chaque étape du processus global représente une unité de travail discrète telle qu'un bon de travail. Pour gérer chaque bon de travail, vous pouvez créer une version distincte et isolée, et la modifier. Une fois le travail correctement effectué, vous pouvez intégrer les modifications à la version publiée de la base de données. En utilisant ainsi les versions, vous pouvez gérer les processus de workflow les plus éléments et les plus complexes.

Dans la plupart des cas, vous choisissez une mise à jour simultanée de la base de données publiée dans laquelle de nombreux éditeurs modifient la version DEFAULT, ou une combinaison des autres configurations. La connaissance des exigences organisationnelles et commerciales et l'évaluation des avantages et inconvénients de chaque configuration vous aideront à choisir la solution la mieux adaptée à votre organisation.

Par souci de simplicité et en raison de considérations de gestion de géodatabase, il est conseillé de maintenir une arborescence de version plate ou de disposer de plusieurs rédacteurs effectuant des mises à jour simultanées de la version DEFAULT.

Mise à jour simultanée de la base de données publiée

Etant donné que plusieurs utilisateurs peuvent simultanément modifier la même version, la méthode la plus simple pour effectuer une mise à jour multi-utilisateurs nécessite que plusieurs éditeurs modifient directement la version DEFAULT.

Lorsque chaque éditeur commence à modifier la version DEFAULT, une version temporaire sans nom est automatiquement créée dans la session de mise à jour. Cette version temporaire est accessible uniquement à l'éditeur actuel. Lorsque l'éditeur enregistre son travail ou termine la session de mise à jour, les modifications enregistrées dans la version temporaire sont réinjectées dans la version DEFAULT.

Si un autre utilisateur a modifié la version DEFAULT depuis que vous avez commencé votre mise à jour, ArcGIS réconcilie et réinjecte automatiquement les modifications lorsque vous enregistrez votre travail. Un message vous avertit que la version a été modifiée et doit être réenregistrée pour appliquer les modifications des autres éditeurs. Vous pouvez contourner ce message d'avertissement en activant l'option de réconciliation automatique dans la boîte de dialogue Options d'ArcMap. Avec ou sans contournement de ce message, vous devez résoudre les éventuels conflits à l'aide de la boîte de dialogue de résolution des conflits avant de pouvoir enregistrer vos modifications.

Pour en savoir plus sur les paramètres d'enregistrement des données

Pour en savoir plus sur la résolution des conflits de données

Avantages:

• Cette stratégie permet également d'effectuer des modifications simples dans la base de données car les utilisateurs n'ont pas besoin de créer de nouvelles versions pour modifier les données. Elle est recommandée lorsque les unités de travail sont relativement petites ou lorsque d'autres solutions de création permanentes sont inutiles.
• En l'absence de conflits, les mises à jour enregistrées sont directement réinjectées dans la version DEFAULT.

Inconvénients:

• La version DEFAULT change constamment et s'expose donc à des modifications accidentelles ou non autorisées ; en conséquence, l'administrateur de base de données doit effectuer des sauvegardes de base de données plus fréquentes.
• Les longues transactions et la création d'autres versions de conception réparties sur plusieurs sessions de mise à jour ne sont pas prises en charge.
• Une seule opération de réconciliation par géodatabase peut être active à un moment donné. En cas d'opérations fréquentes de réconciliation et de réinjection à partir de plusieurs sessions de mise à jour, les éditeurs qui enregistrent leurs modifications doivent éventuellement attendre la fin des processus de réconciliation et de réinjection actifs. Dans une géodatabase multi-utilisateurs volumineuse, il est recommandé d'éviter que de nombreux d'utilisateurs réconcilient et réinjectent une même version. Les réconciliations et les réinjections verrouillent de façon exclusive la version et empêchent les autres utilisateurs de terminer leurs tâches.

Plusieurs projets

Si vous gérez plusieurs projets ou bons de travail, vous devez adopter une approche plus structurée pour la gestion des workflows. Les unités de travail discrètes comprenant plusieurs sessions de mise à jour et s'étalant sur plusieurs jours, semaines ou mois peuvent être gérées sans modifier la version DEFAULT. Un programme de rénovation d'autoroute, l'installation d'un nouveau service téléphonique ou un projet de maintenance de gazoduc en cours sont des exemples d'unités de travail discrètes.

Lorsqu'un bon de travail ou un projet est lancé, une version est créée comme version enfant de la version DEFAULT. Un ou plusieurs éditeurs peuvent utilisent cette version jusqu'à la fin de l'ordre de travail ou du projet. Lorsque toutes les modifications ont été effectuées dans une version, l'éditeur ou l'administrateur ArcSDE effectue la réconciliation avec la version DEFAULT, résolvant ainsi tous les conflits éventuels. Il réinjecte ensuite les modifications dans la version DEFAULT, les intégrant ainsi à la base de données publiée. A ce stade, la version enfant peut être supprimée.

Les autorisations d'accès des utilisateurs à la version DEFAULT peuvent être limitées afin d'appliquer ce workflow et s'assurer que la version DEFAULT n'est pas modifiée. L'administrateur ArcSDE peut protéger la version DEFAULT afin que les utilisateurs puissent continuer à visualiser la version DEFAULT mais ne disposent que d'un accès en lecture seule. L'éditeur qui souhaite modifier les données doit créer une nouvelle version.

Si les utilisateurs disposant d'un accès en lecture seule n'ont pas besoin de visualiser leurs modifications dès leur réinjection dans la version DEFAULT, vous pouvez mettre à leur disposition une nouvelle version statique protégée, créée à partir de la version DEFAULT. Cette version doit être créée après la compression de la base de données et la reconstruction des index et des statistiques. Ainsi, toutes les lignes nécessaires à la représentation de la version en lecture seule sont stockées dans la table de base et la base de données fonctionne de manière optimale. Dans ce cas, aucune modification n'est effectuée dans la version de la base de données des utilisateurs en lecture seule (FastTrak dans l'illustration ci-dessous) ; les requêtes de recherche des différences de versions sont donc inutiles et les statistiques et index de la base de données ne deviennent ni obsolètes ni fragmentés. Après chaque compression planifiée de la base de données, cette version est recréée pour permettre aux utilisateurs en lecture seule d'accéder aux modifications effectuées depuis la dernière compression de base de données.

Avantages:

• Simplicité : chaque unité de travail est logiquement répartie par version.
• Les longues transactions réparties sur plusieurs de sessions de mise à jour et la création d'autres versions de conception sont prises en charge, permettant ainsi aux éditeurs de développer des propositions sans affecter la base de données de production.
• La création d'une nouvelle version de la version DEFAULT protège la vue de production de la base de données contre toute modification inopinée. Une fois terminés, les projets individuels sont intégrés à la base de données de production.
• Les processus de réconciliation/réinjection par lot sont pris en charge.

Inconvénients:

• Comme dans toute configuration de version multi-niveaux, le nombre de lignes gérées dans les tables delta de la version affecte les performances de requête de la version. Vous pouvez réduire ce problème en compressant régulièrement la base de données et en actualisant les statistiques SGBD.

Projets multiples avec des sous-projets

Les projets complexes nécessitent une structure de workflow plus élaborée que la mise à jour simultanée ou la gestion de plusieurs projets. Ces projets peuvent être divisés en plusieurs unités fonctionnelles ou géographiques permettant de développer une hiérarchie de versionnement plus complexe. 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.

Pour les grands projets impliquant plusieurs équipes et de nombreuses unités de travail discrètes, une arborescence de version multi-niveaux constitue une méthode efficace pour organiser le workflow. Les équipes qui s'occupent de différentes tâches d'un même projet créent leur propre version pour conserver une vue privée de leurs mises à jour. Une fois le projet terminé, les versions peuvent être réconciliées et réinjectées dans la version DEFAULT et font alors partie intégrante de la base de données publiée.

Avantages:

• Prise en charge de projets complexes
• Prise en charge de longues transactions réparties sur plusieurs sessions de mise à jour
• Prise en charge des processus automatisés de réconciliation et réinjection par lot

Inconvénients:

• Vous devez réconcilier et réinjecter les versions dans l'ordre, en commençant par les versions les plus éloignées de la version DEFAULT et en remontant dans le temps. En d'autres termes, les versions de troisième niveau (arrière-petits-enfants) de la version DEFAULT doivent être réinjectées dans leurs parents, c'est-à-dire les versions de deuxième niveau (petits-enfants) de la version DEFAULT. Ces versions de deuxième niveau peuvent être ensuite réinjectées dans les versions de premier niveau (versions enfant) de la version DEFAULT. Enfin, les versions de premier niveau (enfant) peuvent être réinjectées dans la version DEFAULT.

  Lorsque chaque version enfant a été réinjectée dans sa version parent, la version enfant peut être supprimée.

• Les opérations de réconciliation et de réinjection sont uniquement possibles entre des versions situées sur le chemin direct; elles ne peuvent pas être exécutées sur des chemins de versions transversaux.
• La gestion d'une arborescence de version complexe représente des coûts associés en termes de performance : plus les tables de deltas de version comportent de lignes, plus l'impact potentiel sur les performances des requêtes est important.

Projets en plusieurs phases

Beaucoup de projets 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 de passer à l'étape suivante. Par exemple, dans le domaine des services publics, les étapes les plus communes d'un projet sont travail, proposé, accepté, en cours de construction et conforme à l'exécution. Ce processus est essentiellement cyclique : un bon de travail est initialement attribué à un ingénieur, modifié dans le temps au fur et à mesure des étapes du projet, avant intégration complète à la base de données de production.

Dans cette approche, une version est créée pour représenter chaque étape de ce processus : une conception initiale ou une version proposée, une version approuvée et une version pour la phase de construction. Au fur et à mesure des différentes phases du 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. Les versions plus anciennes peuvent être conservées afin de servir de référence historique, ou supprimées si nécessaire.

Une fois le projet terminé, la version construite peut être réconciliée et réinjectée directement dans la version DEFAULT, sans réconciliation et réinjection nécessaire dans les versions précédentes de la généalogie.

Avantages:

• Cette méthode est adaptée aux projets qui se déroulent en plusieurs étapes, où chaque étape doit être isolée en tant qu'unité de travail distincte.
• Comme dans toutes les autres configurations multi-niveaux, ce workflow permet aux éditeurs de développer des propositions et d'autres solutions de création sans affecter la base de données de production.
• Les modifications peuvent être réinjectées directement dans la version DEFAULT, évitant ainsi la réinjection progressive des modifications dans la version DEFAULT, en amont de l'arborescence de la version.

Inconvénients:

• N'est pas adaptée aux processus de réconciliation et de réinjection par lot

Archivage

Dans de nombreux projets, la conservation des différents états de la base de données au fur et à mesure de son évolution dans le temps constitue une exigence fondamentale. Une géodatabase doit également prendre en charge les requêtes standard suivantes :

• Quel était l'état de la base de données à moment donné ?
• Comment une entité donnée a-t-elle évolué dans le temps ?
• Si une entité a été supprimée de la base de données à une certaine date, quelles entités figurent actuellement à la place des anciennes entités?

La gestion d'un enregistrement historique nécessite la conservation d'une archive de la version DEFAULT car elle représente généralement la version publiée de la base de données. Les modifications apportées à la version DEFAULT peuvent survenir à la suite d'une mise à jour de cette version DEFAULT ou d'une réconciliation et réinjection à partir d'autres versions. Une géodatabase peut être configurée pour enregistrer automatiquement ces modifications. Cette fonctionnalité étant intégrée à la géodatabase, aucune modélisation de données ou personnalisation d'application supplémentaire n'est nécessaire à la prise en charge de l'archivage automatisé.

Certains projets exigent l'archive d'une version autre que la version DEFAULT. Une version représentant l'état de sa version parent au moment de sa création, vous pouvez créer une version dans le seul but d'enregistrer l'état de sa version parent à un instant donné. Par exemple, une nouvelle version historique peut être créée à partir de la version de création. Lorsque la version de conception est réconciliée et réinjectée dans sa version parente, la version historique représente un enregistrement de la conception à un instant donné.

Pour en savoir plus sur l'archivage, reportez-vous à la rubrique Le processus d'archivage.

Gestion répartie des données

Dans certains projets, deux ou plusieurs bureaux distants doivent partager les mêmes données. Chaque bureau nécessite un accès local à la base de données et crée donc une copie de cette base de données. Lorsqu'un bureau modifie les données, la modification doit également être appliquée aux données de l'autre bureau. Pour maintenir la synchronisation des copies de bases de données, les sites peuvent s'envoyer régulièrement les modifications. Cette fonctionnalité correspond à une réplication de géodatabase.

La réplication permet également d'emporter un sous-ensemble de la géodatabase sur le terrain afin de le mettre à jour en mode déconnecté, fonctionnalité indispensable aux équipes de maintenance. De retour au bureau, vous pouvez vous reconnecter au réseau et réinjecter les modifications dans la base de données de production.

La réplication facilite également le travail des utilisateurs qui doivent passer par un réseau lent pour mettre à jour leurs données. Dans ce cas, cette méthode vous permet d'extraire un sous-ensemble de données sur votre ordinateur local afin de pouvoir le traiter sans avoir à le diffuser sur le réseau. Une fois la mise à jour terminée, vous pouvez transférer les modifications sur le réseau afin de les réinjecter dans la base de données de production. Pour plus d'informations, reportez-vous à la rubrique Scénarios utilisant des données réparties.