Styles

mardi 13 octobre 2009

Bases de données temporelles

Quand il s'agit de gérer des périodes de temps, SQL n'est pas très bien pourvu, et le modèle relationnel classique ne s'y prête pas naturellement. Sans essayer de passer par du TSQL2 et de s'attacher une technologie que finalement peu de monde utilise (l’utilisez-vous ?, je ne l’ai jamais vu en pratique sur des applications d'entreprise), on peut, avec malice, trouver des solutions pour représenter les différents états dans le temps d'un fait.

Tout est affaire de point de vue. Si vous avez une application tournant au dessus d’un modèle relationnel, il n’est pas nécessaire de modifier le code de celle-ci pour permettre l’historisation automatique des données manipulées.

Il n’y a qu’à remplacer les tables à historiser par des vues :
  • la vue a exactement les mêmes colonnes que la table qu’elle remplace
  • la vue est construite au dessus d’une table d’historisation contenant les mêmes colonnes qu’initialement, plus 2 nouvelles colonnes :
- DEBUT
- FIN
  • [DEBUT;FIN[ correspond à l’interval de temps pendant lequel l’entité a la même valeur (dans ses autres colonnes) (attention : DEBUT est inclus, FIN est exclu)
On peut vouloir stocker le temps-valide ou le temps transaction :

* Le temps-valide (ou « temps logique ») dénote la période de temps durant laquelle un fait est vrai par rapport avec la réalité.

* Le temps-transaction (ou « temps physique ») est la période de temps pendant laquelle un fait est stocké dans la base de données.

* La donnée bitemporelle combine à la fois le temps-valide et le temps-transaction.

A noter que ces deux périodes de temps n'ont pas à être égales pour un fait unique. Imaginez que nous ayons une base de données temporelle stockant des données relatives au 18ème siècle. Le temps-valide de ces faits se situe quelque part entre 1701 et 1800, tandis que le temps transaction débute quand on insère le fait dans la base de données, par exemple le 21 janvier 1998.

L’objectif est de pouvoir consulter la base de données à un instant T. Pour cela, il faut faire attention d’historiser aussi les données dépendantes par contrainte.

Les bases temporelles permettent souvent de différencier les programmeurs sur framework des programmeurs sur base de données. Un programmeur sur base de données va implémenter une base de données temporelle avec des vues et des triggers, offrant une vue propre des données à un instant T. Le programmeur sur framework va implémenter les règles de gestion du temps en Java au lieu d’utiliser des triggers et des vues et va aboutir, avec une grande probabilité, à une machine à gaz inmaintenable au bout de 3 mois.

Les vues et les triggers des bases de données sont des outils puissants et naturels pour implémenter :
  • le contrôle d’accès fin aux données,
  • l’historisation des données sous la forme de base de données temporelle.
Il est vain d’essayer de reproduire ces fonctionnalités au niveau de la couche applicative. Bizarrement, la mise en place de base de données temporelle est rarement évoquée sur asktom.oracle.com

Pour info, j'ai traduit la page Temporal database (Base de données temporelle) dans Wikipedia, histoire de combler à mon humble mesure le vide sidéral des articles informatiques en Français.

Pour en savoir plus sur les bases de données temporelle, autant consulter la liste de liens de Troels ou encore cette Introduction aux bases de données temporelles.

Aucun commentaire: