II.B - La dimension temporelle dans la BDUni
La dimension temporelle, nous l'avons abordée dans la
partie précédente, possède deux aspects : l'historisation
de la donnée et son suivi. Elle présente également deux
définitions, que nous avons mentionnées sans les
développer, l'une « informatique », l'autre «
thématique », qui correspondent à la différence entre
le temps de la mise à jour et le temps réel ou temps du
terrain.
La prise en compte de la dimension temporelle dans la BDUni
est celle du temps informatique. C'est une base de données
rollback (Paque, 2004, p. 10) : elle enregistre le temps de la
transaction. Elle correspond aux besoins actuels des utilisateurs de la base :
une information à jour, le plus rapidement possible. Les tables
d'historiques servent concrètement à pouvoir revenir sur une mise
à jour dans le cas d'une erreur. L'historisation des données
n'est pas liée au suivi du terrain, mais au suivi de la donnée.
Le modèle d'historisation qui a été mis en place pour la
BDUni répond en premier lieu aux attentes de production.
Le suivi des évolutions est quant à lui un autre
besoin. Il demande l'enregistrement du temps réel dans une base de
données historique - elle n'enregistre que le temps réel - ou
temporel - elle enregistre le temps informatique et réel (Paque, 2004,
p. 10). Le temps réel peut être évalué à
partir de la BDUni, c'est-à-dire qu'on peut considérer le temps
informatique comme un temps réel, mais il n'est pas contenu absolument
dans la base. Quelques exceptions existent : les routes, bâtiments, etc.,
en construction ou en projet, et les alertes ponctuelles saisies par les
collecteurs. Ces objets indiquent une information temporelle réelle.
Lors de leur saisie, il est possible de renseigner la date d'actualisation de
la modification (d'après un document daté avec précision
ou un déplacement sur le terrain).
Toutefois, considérant la production en continu et les
thèmes évoluant le plus dans la base (routier, bâti), on
peut dire que ce type d'intégration du temps est suffisant pour le suivi
des changements, le temps de saisie et le temps réel étant en
effet proche dans 99% des cas. Néanmoins, il reste toujours un
problème : l'impossibilité de corriger à posteriori les
données sans compromettre la temporalité des données
(Heres, 2000, p. 46)
Enfin, dernière remarque concernant
l'intégration du temps dans la BDUni, celle-ci nous parait ne pas
optimiser sa structure relationnelle. Les colonnes « daterec »,
« numrec » et « numrecmodif » sont nécessaires
à la création de l'intervalle de durée de vie d'un objet.
La colonne « date_creation » est utile, car elle évite de
devoir retrouver le premier état d'un objet pour connaître sa date
de création. Mais les colonnes « date_modifcation » et «
date_destruction » nous semble contenir, de ce point de vue, des
informations redondantes dans la base concernant la temporalité des
données. Ces colonnes pourraient être supprimées, puisque
les informations qu'elles contiennent sont aussi présentes dans la table
des réconciliations : elles correspondent à la date du «
numrec ». Toutefois, elles existent peut-être pour des raisons de
performances techniques.
xlvii
| 
