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.

Mise à jour simultanée de 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:

Inconvénients:

Les projets multiples

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.

Gestion de plusieurs projets

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.

Gestion de plusieurs projets, avec une version permettant de créer rapidement des requêtes et des rapports

Avantages:

Inconvénients:

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.

Projets multiples avec des sous-projets

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:

Inconvénients:

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.

Projets en plusieurs phases

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:

Inconvénients:

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 :

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é.

Création de versions à des fins d'archivage

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.

Les bureaux distants peuvent synchroniser leurs copies d'une 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.

Rubriques associées


3/6/2012