Tables versionnées d'une géodatabase dans Informix
Une géodatabase d'entreprise doit permettre la création et la mise à jour de volumes importants d'informations géographiques simultanément. Par conséquent, une géodatabase doit fournir un environnement de mise à jour qui prend en charge les modifications effectuées par plusieurs utilisateurs sans créer plusieurs copies des données. Dans le cadre de cette fonctionnalité, l'environnement de mise à jour doit également prendre en charge : des sessions de mise à jour s'étalant généralement sur plusieurs jours, la possibilité d'annuler ou de répéter des changements apportés à la base de données, les essais et le développement de modèles de données et de propositions alternatives de conception logicielle sans affecter la base de données publiée et enfin, la possibilité de surveiller l'évolution des données et de la base de données dans le temps.
Afin de satisfaire ces besoins, les géodatabases ArcSDE peuvent être versionnées. Pour commencer, inscrivez des jeux de classes d'entités, des classes d'entités autonomes et des tables comme versionnés. Ensuite, créez des versions de la géodatabase permettant d'apporter des modifications. Ces versions sont virtuelles ; la géodatabase n'est pas dupliquée. Les versions sont représentées par des tables delta associées à chaque jeu de données versionné et quelques tables système permettant d'assurer le suivi des états de la version.
Pour plus d'informations sur les versions, reportez-vous à la rubrique Présentation rapide du versionnement.
Tables versionnées dans ArcGIS Desktop
Dans la fenêtre Catalogue, les jeux de données versionnés ont la même apparence que les jeux de données non versionnés. La boîte de dialogue Propriétés de la classe d'entités ou de la table permet de définir si elle est versionnée. L'onglet Général indique si la classe d'entités ou la table est enregistrée comme versionnée.
Vous pouvez avoir plusieurs versions d'une géodatabase. Dans le Catalogue, vous pouvez établir des connexions à une base de données spatiale distincte pour chaque version. Lorsque vous affichez un aperçu d'un jeu de données versionné dans la version DEFAULT, celui-ci peut avoir une apparence différente et contenir plus ou moins d'enregistrements que la même classe d'entités affichée dans la version autre que DEFAULT. (Pour savoir comment établir une connexion à une base de données spatiale à une version autre que DEFAULT, reportez-vous à la rubrique Connexion à une version spécifique d'une géodatabase.)
De la même façon, l'affichage d'une classe d'entités versionnée dans une version d'ArcMap peut différer de celui trouvé dans une autre version d'ArcMap. En effet, une table ou classe d'entités affichée dans une version contient un certain nombre d'enregistrements ; cette même table ou classe d'entités peut contenir un nombre différent d'enregistrements dans une autre version.
Conseil :Pour voir quelle version des données se trouve dans la carte, cliquez sur le bouton Répertorier par source dans la table des matières ArcMap.
Lorsque vous basculez vers une version différente de la géodatabase (la version WO2557) la classe d'entités Fire hydrants contient une conduite secondaire supplémentaire. Cela signifie qu'une bouche d'incendie a été ajoutée à la classe d'entités Fire hydrants et une conduite secondaire ajoutée à la classe d'entités Water laterals en apportant des modifications avec wo2557 en tant que version de la géodatabase source.
Cela donne l'impression que chaque version est une copie distincte des données. Toutefois, au lieu de dupliquer ou de modifier les données d'origine, la géodatabase laisse la table ou la classe d'entités versionnée dans son état initial et stocke l'ensemble des mouvements apportés à ces données dans des tables système de géodatabase distinctes. Les tables de géodatabase qui enregistrent les changements de la version sont connues sous le nom de tables delta. Pour chaque table ou classe d'entités versionnée, deux nouvelles tables de deltas sont créées : une table des ajouts (a) et une table des suppressions (d).
Tables versionnées dans une base de données IBM Informix
En interne, le versionnement est géré par plusieurs tables de base de données : tables de jeu de données, tables de deltas et tables système, pour assurer le suivi des versions.
Tables delta
Lors de l'enregistrement d'un jeu de données d'entités, d'une classe d'entités autonome, ou d'une table comme versionnés, les tables de deltas (la table des ajouts et la table des suppressions) sont créées dans la base de données. Les tables delta enregistrent tout enregistrement nouveau, modifié ou supprimé dans une table ou une classe d'entités versionnée à chaque état de la base de données.
Remarque :Seul le propriétaire du jeu de données peut l'inscrire comme versionné.
a<ID_enregistrement>
La table a<ID_enregistrement> (table des ajouts) conserve les informations sur chaque enregistrement (entité) ajouté ou mis à jour dans une table métier versionnée et est interrogée pour identifier les enregistrements ajoutés ou modifiés pour un état de base de données particulier. L'identifiant ID_enregistrement du nom de la table des ajouts est la valeur du champ registration_id de la table table_registry correspondant à la table versionnée. Dans l'exemple portant sur les bouches d'incendie ci-dessus, l'identifiant registration_id de la classe d'entités Fire hydrants dans la table table_registry est 161 ; par conséquent, la table des ajouts de la classe d'entités Hydrants est a161.
La table des ajouts contient les mêmes champs que la table métier versionnée en cours de modification, plus un identifiant col_stateid.
|
Nom du champ |
Type de champ |
Description |
Nul ? |
|---|---|---|---|
|
<tous les champs de la table métier versionnée> |
<tous les types correspondants aux champs de la table métier versionnée> |
Tous les attributs de la nouvelle entité |
|
|
sde_state_id |
int8 |
Identifiant de l'état dans lequel la nouvelle entité a été ajoutée ou mise à jour |
NOT NULL |
Par exemple, si vous ajoutez une bouche d'incendie à la classe d'entités Fire hydrants au cours d'une session de mise à jour versionnée, un enregistrement est ajouté à la table des ajouts pour cette nouvelle bouche d'incendie.
d<id_enregistrement>
La table d<id_enregistrement> (ou table des suppressions) conserve des informations concernant l'ensemble des enregistrements supprimés ou mis à jour dans une table versionnée. Elle est interrogée pour identifier les enregistrements supprimés ou modifiés dans un état particulier. Lorsqu'un enregistrement est supprimé, il n'est pas supprimé physiquement : il est signalé comme supprimé et n'est jamais renvoyé dans les interrogations de base de données suivantes.
|
Nom du champ |
Type de champ |
Description |
Nul ? |
|---|---|---|---|
|
sde_state_id |
int8 |
Identifiant de l'état dans lequel la nouvelle entité a été ajoutée ou mise à jour |
NOT NULL |
|
sde_deletes_row_id |
integer |
Identifiant unique de l'entité supprimée ou mise à jour |
NOT NULL |
|
deleted_at |
int8 |
Etat dans lequel l'entité est supprimée |
NOT NULL |
Tables système
En plus des tables de deltas, certaines tables système assurent le suivi des tables versionnées et des mises à jour. Il s'agit des tables states, state_lineages, versions et mvtables_modified.
Une base de données versionnée contient en général plusieurs versions en plus de la version DEFAULT. Ces versions supplémentaires peuvent représenter des éléments tels qu'une commande de travail, une conception différente, une session de mise à jour en mode déconnecté ou une vue figée historique. La table versions contient une liste descriptive de ces versions, dans laquelle chaque version est identifiée par un nom et un identifiant uniques (les identifiants sont générés automatiquement par ArcSDE). Par ailleurs chaque version a un propriétaire, une description, une version parent, un état de base de données associé et un niveau d'accès utilisateur.
Les détails de la version DEFAULT sont automatiquement enregistrés dans la table versions lors de sa création initiale. L'administrateur ArcSDE possède la version DEFAULT, et l'identifiant initial de l'état de la base de données correspondante a la valeur 0. Voici un exemple de l'entrée DEFAULT dans la table versions :
|
Nom |
Propriétaire |
ID_version |
Etat |
ID_état |
Description |
Nom_parent |
Propriétaire_parent |
ID_version_parent |
Heure_création |
|---|---|---|---|---|---|---|---|---|---|
|
DEFAUT |
SDE |
1 |
1 |
0 |
Version par défaut de l'instance |
NULL |
NULL |
NULL |
2009-02-12 08:40:26 |
Pour la gestion des mises à jour apportées aux données, une géodatabase versionnée conserve un ensemble d'états de base de données, ou de changements élémentaires de la base de données. Un état représente une vue figée distincte de la base de données à chaque changement apporté : chaque opération de modification crée un nouvel état de la base de données. [Toute tâche ou ensemble de tâches (additions, suppressions ou modifications) effectué sur les entités ou les enregistrements est une opération de modification.] Toutes les versions de géodatabase font référence à l'un de ces états de base de données et évoluent avec le temps à travers une série d'états.
Tous les états de géodatabase ont la même structure et ne diffèrent que par le nombre de lignes qui représentent chaque table ou classe d'entités modifiée. Afin d'identifier les conflits pouvant se produire lorsqu'une entité donnée est modifiée dans une même version ou dans des versions différentes, les généalogies d'état de la version sont comparées au cours de la réconciliation de version pour détecter les différences ou les conflits de lignes.
Toutes les informations concernant les états sont gérées dans la table states. Les tables versions et state_lineages sont interrogées pour identifier les états de base de données auxquels les versions font référence.
Les états sont conservés dans une arborescence où les relations parent/enfant peuvent être déduites de la généalogie des états. Les informations sur la généalogie des états de chaque version sont conservées dans une table distincte, state_lineages. Cette table stocke un index à plusieurs entrées permettant de parcourir les relations parent/enfant des états et est utilisée pour toutes les requêtes de version.
Pour renvoyer la vue correcte d'une version, sa généalogie d'états est interrogée pour identifier les états ayant enregistré chaque modification apportée à cette version. Les entrées qui représentent correctement la version peuvent être déterminées à partir de cette liste d'états. Au fur et à mesure des modifications de la géodatabase et des changements de versions, l'arborescence des états devient plus complexe.
Chaque fois qu'une classe d'entités ou une table est modifiée dans un état, une nouvelle entrée est créée dans la table mvtables_modified. Lors de la réconciliation de deux versions, la première étape du processus est l'identification des états référencés par ces deux versions — l'état de la version mise à jour actuelle et l'état de la version cible. A partir de ces états, un état ascendant commun est identifié en retraçant la généalogie des états de ces deux versions. La table mvtables_modified est alors interrogée pour identifier toutes les tables modifiées entre l'état ascendant commun et l'état de la version cible. A partir de cette liste de tables modifiées, une deuxième liste de tables communes aux deux généalogies d'états est générée. Pour chaque table commune de cette deuxième liste sont exécutées plusieurs requêtes de recherche de différences de version — INSERT, UPDATE, DELETE, UPDATE_UPDATE et UPDATE_DELETE.
Les tables impliquées dans la classe d'entités versionnée sont présentées dans le diagramme suivant :
Les lignes pointillées indiquent les relations implicites entre colonnes.
Les numéros dans les noms des tables d'ajouts et de suppressions correspondent à l'identifiant registration_id de la table métier table_registry.
Tables versionnées dans un document XML
Une entrée dans les documents XML indique si une table ou une classe d'entités est versionnée ou non. Elle figure dans une balise Versioned. Pour une table ou une classe d'entités versionnée, la valeur sera true (vrai).
Conseil :La balise Versioned, bien que définie sur des jeux de classes d'entités, ne reflète pas nécessairement la valeur de version des classes d'entités dans le jeu de classes d'entités. Pour savoir si les classes d'entités d'un jeu de classes d'entités sont enregistrées comme versionnées, vous devez interroger les classe d'entités individuelles.
<Versioned>true</Versioned>