Stratégies de gestion des données

Les transactions effectuées par rapport à des données géographiques peuvent varier considérablement en durée et en complexité. La géodatabase prend en charge deux stratégies de gestion des données (avec et sans versions), qui équilibrent les besoins des utilisateurs et des applications afin d'exécuter des transactions courtes et longues avec des données simples ou complexes.

Chaque stratégie pouvant être appliquée sur une entité de type classe par classe d'entités ou table par table, il est donc possible d'utiliser ces deux stratégies dans la même géodatabase.

Chacune de ces stratégies permet de modifier les données de façon similaire : vous les modifiez dans une session de mise à jour à l'aide des mêmes outils. La différence se situe dans la gestion des sources de données sous-jacentes. Des différences existent également au niveau des données que vous pouvez modifier et du type de workflow que vous pouvez exécuter. Cette rubrique explique ces différences.

Gestion des données sans versions

Cette stratégie n'implique pas l'utilisation de plusieurs versions, mais simplement du modèle de transaction du SGBD sous-jacent. Les modifications non versionnées équivalent aux transactions de base de données standard.

Pour modifier les données, vous activez la mise à jour non versionnée dans la boîte de dialogue des options de l'Editeur, vous ouvrez une session de mise à jour et exécutez les opérations requises telles que l'ajout, la suppression ou le déplacement d'entités, ainsi que la mise à jour d'attributs. La première modification que vous apportez lors de la session de mise à jour débute la transaction. Lors de l'enregistrement, les opérations de modification individuelles que vous avez exécutées sont appliquées à la base de données comme une seule transaction. Après l'enregistrement, la modification suivante commence une nouvelle transaction. Vous pouvez enregistrer un nombre d'opérations aussi faible ou aussi élevé que nécessaire lors de la session de mise à jour. Toutefois il est conseillé d'effectuer des enregistrements fréquents, afin d'éviter de verrouiller les données que vous modifiez et de ne pas empêcher les autres utilisateurs d'accéder aux données ou de les modifier. Une fois enregistrées, les modifications sont disponibles pour tous les autres utilisateurs et applications qui accèdent aux données.

Si vous ne voulez pas appliquer les mises à jour à la géodatabase, cessez les modifications sans les enregistrer. Toutes les modifications apportées au cours de cette transaction (à savoir toutes celles effectuées depuis le dernier enregistrement ou, si vous n'avez pas encore enregistré, depuis le début de la session) seront annulées et ne seront pas validées dans la base de données.

Lorsque vous effectuez une mise à jour, tous les index uniques, contraintes et déclencheurs définis sur les données avec le SGBD s'appliquent. Le même comportement de verrouillage s'applique comme si vous exécutiez directement des transactions sur les données avec le SGBD. Par conséquent, les utilisateurs ou applications qui affichent ou modifient les mêmes données risquent de se bloquer mutuellement. Si vous effectuez une mise à jour non versionnée dans un environnement autorisant des modifications par plusieurs utilisateurs, vous devez comprendre le fonctionnement des niveaux d'isolement et du verrouillage dans votre SGBD et, si nécessaire, définir le niveau d'isolement approprié dans le SGBD avant de commencer à utiliser ArcGIS.

Cette stratégie est adaptée aux entités simples pour lesquelles vous n'avez pas besoin de gérer l'historique ou plusieurs représentations des données avec des versions. Cette stratégie ne nécessitant aucune version, elle se révèle également utile si vous avez besoin d'applications SIG et non SIG pour partager l'accès à une base de données commune.

Applications possibles

• Intégrez facilement des données géographiques dans des applications existantes en permettant à des applications tierces (qui n'ont pas été créées avec des logiciels ESRI) de lire et modifier les mêmes données utilisées par des applications ArcGIS.
• Gérez des projets contenant des workflows et des modifications simples. Si les transactions sont toujours simples et de courte durée, vous pouvez directement modifier les données sans avoir besoin de combiner les modifications et gérer les tables supplémentaires nécessaires aux versions.

Limitations

• Vous pouvez uniquement modifier des données simples telles que des points, des lignes, des polygones, des annotations et des relations. Vous ne pouvez pas modifier les classes d'entités participant à une topologie, un réseau géométrique ou un MNT.
• Puisque vous modifiez directement la source de données, vous ne pouvez pas annuler ni répéter une modification individuelle en cas d'erreur. La seule façon d'annuler des modifications consiste à annuler toutes les modifications apportées depuis la dernière sauvegarde en fermant la session de mise à jour sans enregistrer.
• Chaque transaction doit être démarrée et terminée au cours d'une seule session de mise à jour. Une session de mise à jour ne peut durer qu'un temps limité ; vous devez généralement la fermer après quelques heures afin de pouvoir vous déconnecter en fin de journée.
• La mise à jour non versionnée ne permet aucune détection de conflits. Par conséquent, si un utilisateur modifie une entité, enregistre, et qu'un autre utilisateur met à jour la même entité et enregistre, la dernière modification écrase la première.

  Pour plus d'informations, reportez-vous à la rubrique Présentation rapide de l'utilisation de données non versionnées.

Gestion des données avec versions

La géodatabase étend la transaction SGBD standard en permettant à plusieurs états de bases de données, appelés versions, d'exister en même temps. Chaque version peut représenter un travail en cours, par exemple une conception ou un groupe de commandes de travaux, pouvant recouvrir plusieurs connexions à la base de données et durer plusieurs semaines ou mois si nécessaire. Les versions vous permettent de gérer les modifications passées, présentes et en projet dans une seule et même géodatabase.

Pour gérer des modifications passées, vous enregistrez les changements apportés aux données dans des tables d'archive distinctes. Vous pouvez conserver ces changements aussi longtemps que nécessaire, en permettant aux utilisateurs de visualiser l'état de la base de données à différents moments dans le passé. Cette fonctionnalité, connue sous le nom d'archivage, est intégrée à ArcGIS et aucun développement n'est nécessaire. Lorsque vous activez cette fonctionnalité, les modifications apportées à la version DEFAULT, normalement utilisée comme version publiée de la base de données, sont automatiquement archivées.

Pour gérer les modifications actuelles, les éditeurs peuvent modifier leur version privée de la géodatabase afin que les autres utilisateurs ne puissent pas visualiser le travail incomplet. Lorsque vous modifiez une version des données, vous n'appliquez aucun verrouillage. Vous optimisez par conséquent l'accessibilité simultanée, car d'autres utilisateurs peuvent lire et mettre à jour les mêmes données que vous modifiez et les utilisateurs ne se bloquent pas mutuellement l'accès à la base de données. Lorsqu'un éditeur a terminé ses modifications, il peut les intégrer à la version publiée.

Pour gérer des modifications en projet, vous pouvez développer un scénario ou effectuer une analyse hypothétique dans une version de la base de données. Le scénario peut être géré comme une seule unité de modification recouvrant plusieurs sessions de mise à jour et s'étalant sur plusieurs jours, semaines ou mois. Vous pouvez librement ajouter des entités en projet, effectuer une analyse géographique, et créer des cartes sans affecter la base de données à laquelle d'autres utilisateurs accèdent. Une fois les modifications terminées et approuvées, vous pouvez les intégrer au reste de la géodatabase.

Une géodatabase peut avoir un nombre illimité de versions. Les versions peuvent être organisées selon différentes configurations et prendre en charge une large gamme de workflows. Toutefois, 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.

Afin de prendre en charge les fonctionnalités de versionnement, ArcGIS ne duplique pas les données. A la place, ArcGIS conserve chaque classe et table d'entités dans son format original mais enregistre toutes les modifications dans des tables appelées tables delta. Les tables delta se composent d'une table d'ajouts pour les insertions et les mises à jour et d'une table de suppressions pour les suppressions. A chaque mise à jour ou suppression d'un enregistrement dans une version, des lignes sont ajoutées à l'une de ces tables voire les deux. Lorsque vous interrogez ou affichez une classe ou une table d'entités dans une version, ArcGIS assemble les lignes correspondantes des tables delta et de la table d'origine afin de fournir une vue optimale des données.

Mise à jour d'une classe d'entités versionnée

Les tables versionnées nécessitent une gestion régulière de la part d'un administrateur de base de données. Lorsqu'une géodatabase est mise à jour dans le temps, la taille des tables delta augmente, ce qui affecte les performances d'affichage et d'interrogation. Pour maintenir la performance, l'administrateur de base de données peut régulièrement compresser une base de données versionnée, opération qui supprime les informations redondantes des tables delta. Les bases de données versionnées devraient être compressées chaque fois qu'une période de forte activité de base de données se termine, par exemple, à la fin d'un décalage ou après le chargement de nouvelles données. Le processus de compression peut être exécuté pendant que d'autres utilisateurs sont connectés et exploitent la base de données.

ArcGIS offre deux méthodes de gestion des tables delta sous-jacentes prenant en charge des versions :

• En enregistrant toutes les modifications, quelle que soit la version, dans les tables delta
• En enregistrant toutes les modifications des versions autres que DEFAULT dans les tables delta, mais en enregistrant toutes les modifications de la version DEFAULT dans les tables de base

La première méthode est conçue pour prendre en charge exclusivement des applications ArcGIS. La seconde est utile si vous devez gérer les données à la fois dans ArcGIS et des applications tierces.

Gestion des données exclusivement dans des applications ArcGIS

Dans un environnement où vous gérez exclusivement des données dans des applications ArcGIS, la meilleure méthode pour gérer des versions consiste à enregistrer toutes les modifications dans les tables delta. Cela vous permet de tirer le meilleur parti des capacités de la géodatabase, notamment l'archivage, la copie et la possibilité de modifier des réseaux géométriques et des topologies.

Pour appliquer ce comportement à une classe ou une table d'entités, enregistrez les données comme versionnées sans activer l'option permettent de déplacer des modifications vers une table de base. Lorsque vous enregistrez des modifications dans un jeu de données inscrit de cette façon, celles-ci sont enregistrées dans les tables delta. Cette méthode ne permet pas un accès direct aux tables d'origine : les utilisateurs accèdent toujours à une version des données.

L'exemple suivant montre une configuration dans laquelle les données sont entièrement gérées à l'aide de versions. Les éditeurs doivent utiliser ArcGIS ou une autre application ESRI pour modifier les données. Les applications non-SIG peuvent accéder à la version publiée ou à toute autre version, à condition d'être adaptées aux vues multi-versionnées.

En raison des tables delta et autres nécessaires à la prise en charge des versions, les applications conçues pour accéder directement aux données du SGBD sans passer par des bibliothèques de logiciels ESRI n'intègrent pas la fonctionnalité de lecture des versions. ArcGIS fournit des vues multi-versionnées qui permettent à ces applications de lire une version donnée à l'aide de SQL. Les vues multi-versionnées peuvent accéder aux tables et classes d'entités. L'accès aux attributs géométriques des classes d'entités à l'aide d'une vue multi-versionnée nécessite l'utilisation de types de la géométrie SQL entièrement pris en charge par ArcGIS.

Cette méthode offre les avantages suivants :

• Vous pouvez annuler ou répéter des modifications au cours d'une mise à jour.
• L'absence de verrouillages permet d'accéder aux conflits de mise à jour. ArcGIS permet de détecter, de réconcilier et de résoudre facilement les conflits.
• Vous pouvez automatiquement archiver les modifications et visualiser comment la base de données analyse un point particulier dans le temps.
• Vous pouvez mettre à jour les entités d'un réseau géométrique ou d'une topologie.
• Deux bureaux géographiquement éloignés ou plus peuvent travailler simultanément sur des copies synchronisées d'une géodatabase. Les bureaux doivent régulièrement échanger leurs modifications afin que chacun dispose d'une vue actualisée de la géodatabase. Dans ArcGIS, cette fonctionnalité correspond à une réplication de géodatabase.
• Les utilisateurs itinérants, déconnectés du réseau, peuvent mettre à jour une partie de la géodatabase sur le terrain à l'aide d'un ordinateur ou d'un périphérique portable. Lorsque les utilisateurs retournent au bureau, ils intègrent leurs modifications à la géodatabase. Dans ArcGIS, cette fonctionnalité correspond également à une réplication de géodatabase.

Applications possibles

• Projets nécessitant le stockage et l'interrogation de données archivées.
• Projets nécessitant une analyse hypothétique : créez un nouveau dessin dans une version distincte. Si le dessin est approuvé, vous pouvez le fusionner avec le reste de la base de données. S'il n'est pas approuvé, vous pouvez le supprimer.
• Projets présentant des besoins d'assurance qualité spécifiques : regroupez les modifications appliquées aux données, par exemple des importations globales, dans une version isolée des autres utilisateurs de la base de données. Vous pouvez vérifier et approuver les modifications avant de les fusionner avec la version publiée de la base de données.
• Projets fractionnant le travail en unités fonctionnelles ou géographiques : 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. Chaque unité de travail est exécutée dans une version distincte ; lors de la réalisation de chaque version, les informations sont réinjectées dans la version publiée de la base de données.
• Projets se déroulant selon plusieurs étapes prescrites ou réglementées, où chaque étape nécessite une phase d'ingénierie, d'administration ou d'approbation légale avant d'être considérée comme terminée : les workflows de ces projets peuvent gérer chaque étape sous forme de version distincte, par exemple 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 d'un 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.
• Projets nécessitant un audit de réglementation : conservez une archive permanente pour gérer les requêtes sur les modifications.
• Projets impliquant des bureaux géographiquement distants qui doivent utiliser simultanément la même géodatabase : ces bureaux ont besoin de synchroniser régulièrement leurs copies des données.
• Projets nécessitant que les équipes de maintenance sur le terrain actualisent les données à l'aide d'ordinateurs portables.
• Projets nécessitant que les développeurs de logiciels testent les instructions SQL et la logique d'application sur leur propre version privée de la base de données.

Les versions offrent de nombreux avantages mais comportent quelques limites :

• Les applications tierces doivent être adaptées aux vues multi-versionnées pour pouvoir lire les données.
• Certaines limites s'appliquent au comportement SGBD actif, telles que des contraintes uniques et des déclencheurs lors de l'utilisation de données versionnées. En effet, les blocs d'insertion et les mises à jour créent des lignes dans les tables delta au lieu de blocs d'insertion et de mises à jour dans la table de base.

Gestion des données avec ArcGIS et d'autres applications

Dans un environnement informatique hétérogène où plusieurs applications de différents départements accèdent à la même base de données, la prise en charge ArcGIS et d'applications tierces peut être nécessaire. Par exemple, un département gère les données géographiques de la base de données avec ArcGIS, tandis qu'un autre département gère les enregistrements client de la même base de données avec une application personnalisée. L'application personnalisée doit appliquer des contraintes SGBD et des déclencheurs lorsque des transactions sont effectuées, et risque de ne pas reconnaître les tables versionnées. En même temps, l'autre département doit modifier les données géographiques dans sa propre version isolée, sans partager les modifications du département tant qu'elles ne sont pas terminées et approuvées.

Compte tenu de ces exigences, ArcGIS vous permet d'effectuer une mise à jour versionnée d'une classe ou table d'entités, tout en vous offrant la possibilité de partager des modifications avec d'autres applications. Pour appliquer cette fonctionnalité à une classe ou une table d'entités, enregistrez les données comme versionnées à l'aide de l'option permettent de déplacer des modifications vers une table de base. Cette option est disponible dans la boîte de dialogue d'inscription.

Lorsque vous modifiez des données inscrites de cette façon, les versions fonctionnent comme avec la méthode précédente, c'est-à-dire que les modifications sont enregistrées dans les tables delta. Cette règle ne s'applique pas à la version DEFAULT. Lorsque vous enregistrez des modifications dans la version DEFAULT, ou la mettant directement à jour ou en fusionnant les modifications d'une autre version, les modifications sont enregistrées dans les tables de base. Les modifications ne sont pas conservées dans les tables delta comme c'est le cas lorsque l'option d'enregistrement des mises à jour dans la table de base est désactivée.

Cela permet à toutes les applications d'utiliser la même base de données.

• Les applications écrites sans un logiciel développé par ESRI peuvent continuer d'utiliser et modifier des données avec des transactions standard, même si ces données sont modifiées simultanément dans la version DEFAULT ou une autre version.
• Lorsqu'une application ArcGIS ou écrite avec ArcObjects enregistre ou fusionne les modifications dans la version DEFAULT, tous les index uniques, les contraintes et les déclencheurs définis sur les données à l'aide du SGBD s'appliquent.
• Lorsqu'une application modifie les données, les modifications sont aussitôt disponibles dans une autre application qui accède à ces données. Les modifications apportées à la version DEFAULT n'étant pas stockées dans les tables delta, vous n'avez pas besoin d'adapter des applications tierces avec des vues multi-versionnées afin qu'elles puissent lire ces tables.

Applications possibles

• Projets nécessitant une mise à jour des données à l'aide d'ArcGIS et d'autres applications - Configurez un workflow dans lequel les autres applications affichent et modifient les données non-spatiales de la base de données à l'aide de transactions SGBD standard, tandis que d'autres utilisateurs utilisent des versions spécifiques de ces mêmes données. Ces derniers effectuent alors des transactions relativement longues et isolées de tous les autres utilisateurs de la base de données jusqu'à ce que les modifications soient réinjectées dans la version DEFAULT.
• Autres exemples possibles lorsque vous gérez des données exclusivement dans des applications ArcGIS
  • Projets nécessitant une analyse hypothétique
  • Projets nécessitant des besoins d'assurance qualité spécifiques
  • Projets fractionnant le travail en unités fonctionnelles ou géographiques
  • Projets se déroulant selon plusieurs étapes prescrites ou réglementées
  • Projets nécessitant que les équipes de maintenance actualisent les données sur le terrain à l'aide d'ordinateurs portables
  • Projets nécessitant que les développeurs de logiciels testent les instructions SQL et la logique d'application

Limitations

Lorsque vous inscrivez un jeu de données comme versionné avec l'option d'enregistrement des mises à jour dans la table de base, l'utilisation de ces versions est limitée.

• Vous pouvez uniquement modifier des données simples telles que des points, des lignes, des polygones, des annotations et des relations. Vous ne pouvez pas modifier une classe d'entités dans une topologie, un réseau géométrique ou un MNT.
• Vous ne pouvez pas archiver les modifications d'un jeu de données.
• Vous ne pouvez pas répliquer le jeu de données.
• Lorsque vous modifiez la version DEFAULT ou réinjectez une version dans la version DEFAULT, vous n'avez pas la possibilité de résoudre les conflits et vous risquez donc d'écraser les modifications d'un autre utilisateur.

Pour en savoir plus sur les versions et leurs fonctionnalités, consultez les rubriques Maîtrise du versionnement et Scénarios de versions.