Les transactions sont des paquetages de tâches qui modifient les bases de données. Les bases de données SIG (système d'information géographique), comme d'autres applications de base de données, doivent prendre en charge les transactions de mise à jour qui assurent l'intégrité des données et le comportement de l'application. Dans de nombreux cas, vous pouvez utiliser la structure de transaction du système de gestion de base de données pour gérer les mises à jour apportées aux géodatabases.
Toutefois, les utilisateurs SIG respectent généralement certains critères transactionnels particuliers. Par exemple :
- Il arrive souvent que plusieurs enregistrements soient enregistrés conjointement dans une seule transaction.
- De nombreuses transactions doivent couvrir de longues périodes (parfois des jours et des mois, pas seulement des secondes ou des minutes).
En outre, les éditeurs doivent être capables d'annuler et de rétablir les modifications. Les sessions de mise à jour peuvent s'étendre sur plusieurs heures, voire sur plusieurs jours. Les mises à jour doivent souvent s'exécuter dans un système déconnecté de la base de données partagée centrale.
Comme les processus des workflows SIG peuvent couvrir plusieurs jours ou mois, la base de données SIG doit rester disponible en permanence pour les opérations quotidiennes au cours desquelles chaque personne qui se connecte aux données peut avoir un état ou une vue personnel de la base de données SIG partagée. Dans une base de données à plusieurs utilisateurs, les transactions SIG doivent être gérées dans la structure de transactions courtes du système de gestion de base de données. La géodatabase joue un rôle clé lors de ces opérations en gérant les transactions SIG complexes et de haut niveau dans la structure de transactions du système de gestion des bases de données.
Dans de nombreux cas, les workflows de transactions longues sont essentiels pour un SIG. Dans la plupart des cas, ils sont rendus possibles via l'utilisation d'une géodatabase d'entreprise et d'ArcGIS pour gérer les mises à jour de la base de données SIG centrale à l'aide du versionnement. Le versionnement est expliqué plus en détail ci-dessous.
Voici des exemples de workflows de compilation de données SIG qui nécessitent un modèle de transaction basé sur les versions :
- Plusieurs sessions de mise à jour :une seule mise à jour SIG peut nécessiter de nombreuses modifications qui couvrent plusieurs sessions de mise à jour sur quelques jours ou semaines.
- Mise à jour multi-utilisateurs :plusieurs éditeurs ont fréquemment besoin de mettre à jour simultanément les mêmes entités intégrées spatialement. Chaque éditeur doit utiliser un état personnalisé des données, en affichant les mises à jour individuelles et en ignorant celles réalisées par d'autres éditeurs. Chaque éditeur doit ensuite réinjecter et réconcilier les mises à jour avec celles des autres éditeurs pour identifier et résoudre les conflits éventuels.
- Extraire/insérer des transactions :il est souvent nécessaire d'extraire une partie d'une géodatabase pour une surface ou un secteur donné sur un ordinateur personnel et de mettre à jour ces informations dans une session déconnectée qui peut durer des jours ou des semaines, ou (de plus en plus souvent) d'utiliser cette partie sur le terrain afin de la mettre à jour en mode nomade. Ces mises à jour doivent être réinjectées dans la base de données principale.
- Historique :il est parfois judicieux de gérer une version historique de chaque entité d'une géodatabase, même après la mise à jour de cette version en particulier, afin de conserver une copie des entités retirées et modifiées dans une archive ou pour effectuer le suivi de l'historique d'une entité individuelle (par exemple, les propriétés de mise à jour de la généalogie des parcelles ou des entités dans une base de données cartographique nationale).
- Transférer les mises à jour incrémentielles uniquement :les géodatabases d'entreprise et les infrastructures de données spatiales dans lesquelles les informations sont partagées au sein de différentes organisations requièrent le partage de mises à jour sur Internet dans une structure XML bien définie en vue de partager uniquement les mises à jour incrémentielles entre les géodatabases.
- Réplicas de bases de données géographiques distribuées :une géodatabase régionale peut être une copie partielle d'une géodatabase d'entreprise principale pour une région géographique donnée. Les deux géodatabases doivent régulièrement être synchronisées en échangeant les mises à jour.
- Réplication sans connexion directe parmi les systèmes de gestion de base de données :Les données SIG doivent souvent être synchronisées parmi une série de copies de géodatabases (réplicas), où chaque site effectue ses propres mises à jour sur sa géodatabase locale. Les géodatabases ne sont souvent connectées via le Web que ponctuellement. Les mises à jour doivent être régulièrement transférées entre chaque réplica de base de données et leur contenu synchronisé. Les systèmes de gestion de base de données sont souvent différents (par exemple lors de la réplication de jeux de données entre Microsoft SQL Server, Oracle et IBM Db2).
Modèle de transaction de géodatabase : Versionnement traditionnel
Le mécanisme des géodatabases pour gérer ces workflows et de nombreux autres workflows SIG critique consiste à conserver plusieurs états dans la géodatabase tout en assurant l'intégrité des informations géographiques, des règles et du comportement. La capacité de gérer, d'utiliser et d'afficher plusieurs états repose sur le versionnement. Comme son nom l'indique, le versionnement enregistre explicitement des versions d'entités et d'objets individuels lorsqu'ils sont modifiés, ajoutés et retirés à travers différents états. Chaque version enregistre explicitement chaque état d'une entité ou d'un objet sous forme de ligne d'une table avec des informations de transactions importantes. Plusieurs utilisateurs, quel que soit leur nombre, peuvent utiliser et gérer simultanément différentes versions.
Les versions permettent d'enregistrer toutes les transactions sous forme de série de modifications dans la base de données au fil du temps. En d'autres termes, différentes personnes peuvent utiliser plusieurs vues ou états de la géodatabase. L'objectif est de parvenir à un accès multiutilisateur ouvert aux performances optimales. Par exemple, le système doit être rapide et prendre en charge de manière productive l'utilisation de jeux de données contenant des centaines de millions d'enregistrements accessibles par des milliers de clients simultanément.
Le modèle de transaction de géodatabase basé sur les versions est relativement simple : les mises à jour sont enregistrées dans des tables de changements (deltas).
Les versions enregistrent explicitement les états des objets d'une géodatabase dans deux tables de deltas :
- Table des ajouts
- Table des suppressions
Les requêtes simples permettent d'afficher et d'utiliser tous les états voulus de la géodatabase. Vous pouvez par exemple afficher l'état de données d'un instant précis ou afficher la version actuelle d'un éditeur en particulier avec ses mises à jour.
Les géodatabases et jeux de données versionnés permettent de gérer les longues transactions dans chaque système de gestion de bases de données en tirant parti de la structure des courtes transactions de la base de données.
Dans la table de version d'exemple, une parcelle (numéro 45) est mise à jour pour devenir la parcelle numéro 47. A l'aide du versionnement, la parcelle d'origine est enregistrée dans la table des suppressions et la nouvelle parcelle est enregistrée dans la table des ajouts. D'autres tables système de géodatabase enregistrent des informations de version sur la transaction, telles que la durée et la séquence de chaque mise à jour, le nom de la version et l'ID d'état de chaque mise à jour. Chaque version possède également ses propres privilèges d'accès et paramètres de sécurité.
Ceci permet à la plupart des clients d'utiliser la version par défaut, tandis que différents éditeurs mettent à jour simultanément leurs propres versions des données au fil du temps.
Plusieurs mises à jour peuvent être appliquées à chaque version. Les éditeurs se connectent à la version de mise à jour et l'utilisent lorsqu'ils apportent des modifications supplémentaires aux données. Une fois les éditeurs prêts à partager les mises à jour avec le reste de l'entreprise, des opérations de réconciliation et de réinjection ont lieu pour intégrer les modifications de la version de mise à jour dans la version parent. Un processus de résolution permet d'identifier et de réconcilier tout conflit potentiel au cours du processus.
Pour en savoir plus sur le versionnement, reportez-vous à la rubrique Présentation générale du versionnement.