Arc h i v a g e
La méthode la plus simple pour gérer les bases d e données géographiques est d e conserver les différents états de ces données.
Ainsi, à l'image des activités d'un centre d'archivage, la base de données est conservée à différentes dates.
Cela fournit plusieurs clichés (« snapshots ») du monde réel.
Lorsqu'un rythme de mise à jour a été déterminé ou lorsque la base revêt d'un caractère légal, cela s'avère incontournable.
Ces différentes versions de la base de données sont donc non corrélées entre elles.
Base de données à la date T1 Base de données à la date T2
figure 8.8.3 : archivage de base de données
L'avantage d'un tel principe est sa simplicité de mise en place et le peu d'efforts qui en résultent.
En revanche, outre un stockage vite volumineux, ce mode de stockage ne permet pas de retrouver aisément les évolutions sur le terrain (objets créés, objets modifiés, objets détruits).
Il ne permet pas non plus de savoir l'âge de la base (et donc de connaître l'obsolescence des données).
L'actualisation de la base chez un client semble également difficile sans perdre les informations que le client a lui même saisies (il faut savoir différencier les modifications du fournisseur des modifications du client) .
Versi o n nement d ' o bjets [GANCA R S KI 95] [SNODGRASS 92]
Le second type de gestion des bases de données consiste à conserver chacun des états des objets, autrement appelé versionnement des objets, c'est-à-dire qu'un objet n'est jamais détruit mais seulement remplacé par sa nouvelle version.
Il faut alors conserver tous les états de la base à toutes les dates. Cette base est appelée un temporal composite [LANGRAN, CHRISMAN 88].
Toutes les données peuvent être regroupées ensemble ou bien réparties dans plusieurs bases selon leurs dates de création (on parle alors de partitionnement temporel) ceci afin d'accélérer les accès ou de faciliter la gestion des données (gestion de l'état courant et report de tous les états antécédents dans une autre base évitant le maintien de plusieurs graphes topologiques) .
Version nement avec esta m p i l l e
L e modèle l e plus simple pour gérer plusieurs versions des objets est d'ajouter une estampille temporelle sur les objets.
Cette estampille temporelle permet de classer les objets dans le temps et de conserver ainsi tous les états des objets.
Comme il est illustré en figure 8.8.4, deux attributs " date de création ,, et ,, date de suppression , de type Date peuvent jouer le rôle d'estampille temporelle.
C'est un mécanisme simple qui entraîne néanmoins une duplication de tout objet modifié (y compris sa partie invariante) .
Des modèles plus sophistiqués ont proposé de versionner à la fois les objets et les attributs des objets apportant ainsi un degré de finesse suffisant pour les BD relationnelles et évitant ainsi toute duplication inutile.
Cependant, ces modèles paraissent lourds à mettre en œuvre et modifient beaucoup le schéma de données initial.
Base de données à la date T1
Date de création : TO Date de suppression : ...
Base de données à la date T2
Date de création : T2 Date de suppression : . ..
Date de création : TO Date de suppression : T2 figure 8.8.4 : versionnement d'objet via un attribute estampille
Le versionnement des objets via un attribut " estampille , permet la diffusion des mises à jour et la gestion de relation de succession entre objets. En revanche, la gestion des objets complexes ainsi que le maintien de la cohérence sont plus difficiles.
Versionnement par arbre de version
Un autre modèle de versionnement des objets consiste à créer un arbre de versions pour chaque objet. L'arbre est une structure qui permet d'éviter les redondances des attributs inchangés entre les versions d'objets.
Base de données à la date T1
Création
résulte de -
-
..L
--
Base de données à la date T2
Création résulte de Extension · - - - - . 1 1
·· o
résulte defigure 8.8.5 : Versionnement d'objets via un arbre de version
Chaque objet est muni d'un identifiant de version qui correspond à la première position dans l'arbre. Si l'objet est modifié, une branche de l'arbre est créée et un nouvel identifiant de version est construit correspondant à cette branche. Ce modèle de données a pratiquement les mêmes atouts et inconvénients que le modèle précédent. Il permet de modéliser élégamment les lignages entre objets (modifications sans changement d'identité seulement) , de diffuser les mises à jour et de gérer les objets complexes.
En revanche, il est plus difficile de maintenir la cohérence et les relations de succession entre objets.
Modèle de journalisation et m utation
Le modèle de journalisation est un modèle dual du modèle de version. En effet, si le modèle de version vise à conserver tous les états des objets, le modèle de journalisation s'attache à conserver toutes les mutations qui sont intervenues sur les objets.
Ainsi, tous les événements qui font passer les objets d'une version à une autre sont enregistrés et classés, ce qui permet de reconstruire l'état de la base de données.
Le modèle de mutation [MOTET 93] [LATARGET et al 94] propose de conserver le dernier état de la base de données et toutes les mutations précédentes qui ont amené la base dans ce dernier état.
Ce modèle entraîne un volume de stockage faible mais la recherche d'un état d'un objet ou l'exécution de requêtes sur des états antérieurs nécessitent l'exécution à rebours de toutes les mutations, ce qui peut s'avérer long en temps de traitement.
Base de données à la date T1
Création
résulte de
-
..l..
- -
-
Base de données à la date T2
Création résulte de Extension 1 - -- - , 1 1
··u
résulte defigure 8.8.6 : modèle de mutation
Le principal risque encouru dans ce modèle est que les mutations soient incomplètes et qu'elles ne permettent pas de retrouver la version de l'objet à une date donnée par manque d'informations.
Par contre, les mutations peuvent fournir une information importante sur la nature des modifications subies par les objets (telle que la source d'information qui a suscité le changement, le type de modifications) .
On retient ainsi une partie de la dynamique des objets. En fait, le terme d'opération est problématique :
- il peut correspondre aux opérations de base, telles que ,, création " • ,, suppression ., et ,, modification d'un
attribut sans changement d'identité " •
- il peut correspondre aussi à des opérations plus complexes, telles que fusion, scission, déformation, etc [CLARAMUNT, THERIAUL T 95].
Or ces opérations se recouvrent entre elles et il est difficile de définir un ensemble minimal d'opérations non redondantes, ni de définir les limites de l'ensemble des opérations admises (étant donnée la complexité des données géographiques, bien des opérateurs peuvent être créés) .
Cette incertitude nous amène donc à considérer un tel modèle comme un modèle externe qui peut être fondé sur une gestion de version mais qui ne peut être adopté dans un cycle de mise à jour de données.
De plus, il est difficile de maintenir la cohérence et de gérer les objets complexes. Modèle de version de bases de données (Cellary, Jomier 90]
Dans tous les modèles précédents, les états ou mutations antérieurs à l'état actuel de la base sont stockés à l'intérieur de la base.
Ils peuvent ainsi interférer avec l'état courant, ce qui complexifie le maintien de la cohérence.
Or, dans le modèle de version de base de données, il y a une extension du modèle de version d'objets à la base de données, c'est-à-dire qu'un versionnement de bases de données est maintenu et est combiné à un versionnement d'objet (chaque version d'objet appartient au moins à une version de base de données) .
Ainsi, à l'intérieur d'une version de base de données, on respecte toutes les contraintes d'une base de données classique ce qui permet un maintien de la cohérence.
Un mécanisme sophistiqué de création d'une nouvelle version de base de données par recopie logique permet de gérer autant de versions que nécessaire.
Base de don nées à la date T1 Base de données à la date T2
a pour nouvelle version
figure 8.8. 7 : modèle de version de bases de données
Base version 2
Bâtiment v2
Base v1 Bâtiment v1
La gestion des versions successives d'objets ainsi que celle des objets complexes est donc supportée.
Cependant, l'introduction des relations de succession entre objets est difficile à implanter dans un tel modèle car elles violent les contraintes d'intégrité propres à chaque version de bases de données.
S y n t h è s e
Par rapport à nos besoins initiaux, aucun modèle n e répond exactement à nos préoccupations.
Cependant, il est clair que les modèles de versionnement sont plus performants pour les tâches " statiques , d'interrogation, d'archivage tandis qu'un modèle de mutation est plus adéquat pour des tâches dynamiques telles que l'animation ou la mise à jour.
Regardons donc maintenant comment tirer parti de cette dualité.