182
Chapitre 7 • Applications avancées en SQL
Si le résultat ne semble guère complexe 13 , son élaboration demande cependant un
peu de soin, ainsi qu’en témoigne l’exercice 7.22.
Remarques
1. Une base de données classique, non temporelle, ne contient rien d’autre que
l’état courant actuel du domaine d’application.
2. Nous n’avons considéré que les données historiques. Une base de données
réellement temporelle peut également représenter des états futurs, c’est-à-dire
des états dont debut est supérieur à l’instant présent ou qui se terminent dans
un futur fini.
3. On peut envisager d’associer à tout état deux types de temps : le temps logique,
qui indique pendant quelle période cet état était valide dans le domaine d’application, et le temps physique (ou de transaction), qui spécifie pendant quel
laps de temps l’information a été courante dans la base de données. Considérons, pour distinguer ces deux concepts l’événement suivant : l’employé
C400 quitte Paris le 1-10-2005 pour s’établir à Nevers. Nous prenons connaissance de ce fait le 15-10-2005 et nous l’enregistrons immédiatement dans
la base de données. Le nouvel état de notre employé sera, si on considère le
temps logique,
('C400','1-10-2005','1-01-3000','FERARD,'Nevers','C1')
et, si on considère le temps physique,
('C400','15-10-2005','1-01-3000','FERARD,'Nevers','C1')
Une table représentant les états selon ces deux types de temps comporte
quatre colonnes temporelles; elle permet de consigner sans perte non seulement les changements d’état du domaine d’application, mais également la
correction d’informations concernant les états passés. Une telle base de
données, dite bi-temporelle, est particulièrement utile lorsqu’on veut reconstituer l’état de nos connaissances sur le domaine d’application à une date
déterminée. On conçoit aisément que la gestion et le traitement de données
bi-temporelles est beaucoup plus complexe que ce que nous avons étudié
dans cette section, où nous nous sommes limités au temps physique.
4. Le modèle relationnel-objet permet de représenter de manière plus naturelle
l’évolution individuelle de chaque colonne 14 . Les requêtes n’en sont cependant pas simplifiées, bien au contraire.
5. Remarquons enfin que la base de données que nous venons de décrire est un
très bel exemple de base de données active.
13. Signalons tout de même que le traitement proposé est un peu simpliste. Trois exemples : (1)
il est interdit de modifier l’identifiant primaire (à défaut de quoi il n’est plus possible de reconstituer l’historique d’un client), (2) lors d’un update, au moins une des valeurs doit avoir changé
(sinon on crée deux états de mêmes valeurs, ce qui exige un coalescing), (3) l’intégrité référentielle doit être vérifiée.
14. L’une des techniques est la suivante : chaque colonne est représentée par un tableau de deux
sous-colonnes reprenant une valeur et une période de validité.
Chapitre 7 • Applications avancées en SQL
Si le résultat ne semble guère complexe 13 , son élaboration demande cependant un
peu de soin, ainsi qu’en témoigne l’exercice 7.22.
Remarques
1. Une base de données classique, non temporelle, ne contient rien d’autre que
l’état courant actuel du domaine d’application.
2. Nous n’avons considéré que les données historiques. Une base de données
réellement temporelle peut également représenter des états futurs, c’est-à-dire
des états dont debut est supérieur à l’instant présent ou qui se terminent dans
un futur fini.
3. On peut envisager d’associer à tout état deux types de temps : le temps logique,
qui indique pendant quelle période cet état était valide dans le domaine d’application, et le temps physique (ou de transaction), qui spécifie pendant quel
laps de temps l’information a été courante dans la base de données. Considérons, pour distinguer ces deux concepts l’événement suivant : l’employé
C400 quitte Paris le 1-10-2005 pour s’établir à Nevers. Nous prenons connaissance de ce fait le 15-10-2005 et nous l’enregistrons immédiatement dans
la base de données. Le nouvel état de notre employé sera, si on considère le
temps logique,
('C400','1-10-2005','1-01-3000','FERARD,'Nevers','C1')
et, si on considère le temps physique,
('C400','15-10-2005','1-01-3000','FERARD,'Nevers','C1')
Une table représentant les états selon ces deux types de temps comporte
quatre colonnes temporelles; elle permet de consigner sans perte non seulement les changements d’état du domaine d’application, mais également la
correction d’informations concernant les états passés. Une telle base de
données, dite bi-temporelle, est particulièrement utile lorsqu’on veut reconstituer l’état de nos connaissances sur le domaine d’application à une date
déterminée. On conçoit aisément que la gestion et le traitement de données
bi-temporelles est beaucoup plus complexe que ce que nous avons étudié
dans cette section, où nous nous sommes limités au temps physique.
4. Le modèle relationnel-objet permet de représenter de manière plus naturelle
l’évolution individuelle de chaque colonne 14 . Les requêtes n’en sont cependant pas simplifiées, bien au contraire.
5. Remarquons enfin que la base de données que nous venons de décrire est un
très bel exemple de base de données active.
13. Signalons tout de même que le traitement proposé est un peu simpliste. Trois exemples : (1)
il est interdit de modifier l’identifiant primaire (à défaut de quoi il n’est plus possible de reconstituer l’historique d’un client), (2) lors d’un update, au moins une des valeurs doit avoir changé
(sinon on crée deux états de mêmes valeurs, ce qui exige un coalescing), (3) l’intégrité référentielle doit être vérifiée.
14. L’une des techniques est la suivante : chaque colonne est représentée par un tableau de deux
sous-colonnes reprenant une valeur et une période de validité.