Conception de Bases de Données 2

Conception de bases de données
Aspects temporels
par Carine SOUVEYET
et Rébecca DENECKÈRE
Centre de recherche en informatique
Université Paris I Panthéon-Sorbonne
1. Objectifs des SGBDs temporels ........................................................... H 3 268 - 2

1.1 Objectif .......................................................................................................... — 2
1.2 Problématique de conception des applications temporelles.................... — 2
2. Les prérequis sur le temps ..................................................................... — 3
2.1 Problématique liée à la gestion du temps.................................................. — 3
2.2 La représentation du temps......................................................................... — 3
2.2.1 Structure temporelle ........................................................................... — 3
2.2.2 Mesures temporelles : calendrier et granules................................... — 4
2.2.3 Types de temps : absolu, relatif et périodique.................................. — 5
2.2.4 Estampiller versus historiser .............................................................. — 5
2.3 Les dimensions temporelles........................................................................ — 6
3. La modélisation conceptuelle temporelle ......................................... — 8
3.1 Rappel des concepts du modèle conceptuel.............................................. — 8
3.2 Extension temporelle du modèle conceptuel ............................................ — 9
3.2.1 Les calendriers..................................................................................... — 9
3.2.2 Les domaines temporels..................................................................... — 11
3.2.3 Extension temporelle des classes d’objets ....................................... — 12
3.2.4 Extension aux contraintes temporelles ............................................. — 18
3.3 Extension de la démarche conceptuelle..................................................... — 19
4. Extension temporelle du niveau logique............................................ — 22
4.1 SGBD temporel et orienté objet : extension temporelle du SGBD O2..... — 22
4.2 Règles de passage........................................................................................ — 23
5. Conclusion .................................................................................................. — 26
Références bibliographiques .......................................................................... — 27
L es bases de données (BDs) conventionnelles sont conçues pour stocker et

restituer, à la demande, les données les plus récentes, celles qui représen-
tent l’état courant des objets de la réalité. Lors de mises à jour, les données
représentatives de situations réelles qui ont évolué sont effacées et remplacées
par leurs nouvelles valeurs. Il n’y a donc pas conservation des données du
passé, mais seulement de celles du présent, à moins que le concepteur de
l’application ait explicitement prévu de le faire.
L’importance du temps dans les bases de données a été mise en évidence dès
1975 par les concepteurs du système TOD et de plus en plus d’applications sem-
blent requérir une gestion des données du passé, du présent et du futur.
Cela justifie que l’on envisage :
— de doter les SGBDs de mécanismes appropriés de définition, d’interroga-
tion, de stockage et de manipulation des bases de données dépendantes du
temps ;
— de doter les méthodes de concepts spécifiques à la prise en compte du
temps durant la spécification d’application bases de données.
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
© Techniques de l’Ingénieur, traité Informatique H 3 268 - 1
CONCEPTION DE BASES DE DONNÉES - ASPECTS TEMPORELS __________________________________________________________________________________
Cette tendance se confirme par l’intégration de SQL/T (extension temporelle

de SQL) dans la prochaine norme SQL3.
Cette nouvelle génération de SGBDs temporels intègre le temps au modèle de
données, ce qui facilite la manipulation des aspects temporels dans les modules
applicatifs et simplifie l’interrogation des données historisées. Mais, si la mani-
pulation des données temporelles est simplifiée, la définition de la base, la spé-
cification des traitements et le contrôle de la cohérence de la base sont autant
d’activités qui se sont considérablement complexifiées.
L’objectif de cet article est de proposer une méthode de conception d’applica-
tions bases de données qui aide à l’analyse des aspects temporels de celles-ci
pour faciliter l’usage d’un SGBD temporel.
■ Manipuler les données temporelles

1. Objectifs des SGBDs Le SGBD temporel fournit un langage de manipulation et d’inter-
temporels rogation adapté à la fois aux données non temporelles et aux don-
nées temporelles.
■ Maintenir la cohérence des données temporelles
Une donnée non temporelle est cohérente si son état courant est
Pour déterminer l’importance du temps dans les bases de
cohérent. Une donnée temporelle est cohérente lorsque tous ces
données, on se reportera à [1]. La méthode proposée dans cet
états passés, présents et futurs sont cohérents. Tous les états d’une
article est une extension de la méthode orientée objet présentée
donnée temporelle sont susceptibles d’être incohérents puisqu’une
dans les deux articles « Conception d’une base de données :
modification peut porter sur un état passé, présent ou futur. Mainte-
une méthode orientée objet et événement » et « Application
nir la cohérence d’une base de données temporelles revient à assu-
d’une méthode de conception orientée objet et événement
rer, après chaque modification de la base, que tous les états passés,
[2], [12] » de ce traité.
présent ou futurs de toutes les données temporelles de la base sont
cohérents.
■ Maintenir les performances
1.1 Objectif Le problème crucial d’un SGBD temporel est de gérer l’accroisse-
ment constant et rapide du volume de la base de données. L’admi-
nistrateur de la base doit mettre en place des procédures de
L’objectif des SGBDs temporels par rapport à celui des SGBDs nettoyage des données temporelles pour maintenir un niveau
conventionnels est de garder l’évolution des données dans le d’exploitation de la base tout en assurant la cohérence de celle-ci
temps. Cette particularité nécessite de se conformer aux impératifs dans le temps.
suivants.
■ Représenter le temps
Le temps est matérialisé dans les SGBDs conventionnels avec les 1.2 Problématique de conception
domaines DATE, TIME et TIMEZONE que l’on associera à un attribut. des applications temporelles
Exemple : la date de naissance d’un patient est un attribut dont le
domaine de valeurs est DATE. De même, l’heure de décollage d’un
avion est un attribut dont le domaine de valeurs est TIMEZONE. La conception d’une application bases de données à l’aide d’une
méthode objet et événementielle peut se résumer à définir les
La représentation du temps avec ces trois domaines est pauvre ; classes d’objets pertinentes pour l’application, en décrivant
on ne peut pas représenter : comment ces objets sont susceptibles d’évoluer. Se focaliser sur les
— des phénomènes temporels à des niveaux de granularité diffé- aspects temporels d’une application bases de données revient à
rents comme l’année, le mois ou la minute ; déterminer :
— des unités temporelles spécifiques comme l’année universi- 1. Quelles sont les unités temporelles qui rythment la vie de
taire, l’année comptable, la semaine, le calendrier en jours ouvrés l’organisation ;
ou en jours ouvrables permettant de définir les rythmes particuliers 2. Quelle est la sémantique et le domaine temporel le plus appro-
d’une administration ou d’une entreprise ; prié à chaque attribut (renseignements ayant une sémantique de
— le temps relatif comme la date de la visite 2 est prévue 3 semai- temps) ;
nes après la visite 1.
3. Quelles sont les données dont l’évolution est pertinente à gar-
La représentation du temps dans les SGBDs temporels permet la der et à gérer dans la base de données ;
prise en compte de tous ces aspects.
4. Quelles sont les contraintes à définir pour pouvoir assurer la
■ Définir et gérer des données temporelles cohérence des états passés, présent ou futurs des données tempo-
Un langage de définition de données est offert par le SGBD pour relles.
décrire les unités temporelles spécifiques à l’organisation ainsi que Ces problèmes sont abordés dans l’extension temporelle de la
les données qu’elle est intéressée à voir évoluer (appelées par la méthode par l’introduction de concepts dédiés à la mesure et la
suite données temporelles). représentation du temps ainsi qu’à la gestion d’historiques. Ces
H 3 268 - 2 © Techniques de l’Ingénieur, traité Informatique
_________________________________________________________________________________ CONCEPTION DE BASES DE DONNÉES - ASPECTS TEMPORELS
concepts permettent de prendre en compte les aspects temporels — enfin, par les types de temps (absolu, relatif et périodique).
d’une application au niveau conceptuel. Nous rappelons que, classi- Cette distinction peut se faire intuitivement en disant que « le
quement, une méthode propose une conception en deux étapes : 25 juillet 1995 » est un temps absolu, « deux jours après la fin du
l’étape conceptuelle et l’étape logique [12]. prêt » est un temps relatif et enfin « chaque dimanche » est un
L’étape conceptuelle se focalise sur la description des phénomè- temps périodique (cf. § 2.2.3).
nes pertinents à prendre en compte, qu’ils soient temporels ou non, ■ Quelles sémantiques de temps gérer
à la différence de l’étape logique qui doit permettre d’obtenir une
nouvelle description de la base de données en complétant la des- Les données évoluent au rythme des événements réels. Par
cription obtenue, au terme de l’étape conceptuelle, en prenant en conséquent le temps à associer à un historique est le temps de
compte les aspects techniques et opérationnels de la gestion et de l’application appelé temps de validité. La base de données doit être
l’utilisation des données qu’elles soient temporelles ou non. le miroir fidèle du monde réel mais, dans la réalité, il existe souvent
un délai non négligeable de rafraîchissement de cette base par rap-
La présentation de l’extension temporelle se compose : port au monde réel. Cette différence entre le temps de l’application
— de l’extension du niveau conceptuel : de nouveaux concepts et le temps de la base de données (appelé aussi temps de transac-
sont introduits pour prendre en compte les aspects temporels de tion) est exploitée par les SGBDs temporels pour pouvoir prendre
l’application ; en compte ce délai de rafraîchissement. Ces différentes sémanti-
— de l’extension du niveau logique : l’étape logique est étendue ques de temps sont introduites et combinées si nécessaire dans les
également pour prendre en compte les aspects temporels par : historiques. Enfin, si la base de données doit mémoriser une donnée
• un langage de définition de classes (temporelles ou non tem- temporelle n’appartenant pas à ces deux sémantiques, nous parlons
porelles) basé sur une extension temporelle du SGBD O2 faite dans ce cas de temps utilisateur (temps dont la sémantique est
dans le projet Esprit TOOBIS, gérée par l’utilisateur). Les sémantiques de temps et leurs utilisa-
• un ensemble de règles de passage permettant d’obtenir un tions dans des historiques sont détaillées dans le paragraphe 2.3.
schéma de base de données temporelles adapté à un SGBD tem-
porel et un ensemble cohérent de transactions utilisant la struc-
ture au mieux pour garantir que les données évolueront d’une
manière cohérente. 2.2 La représentation du temps
Nota : le projet Esprit n° 20671 de nom Temporal Object Oriented dataBases & Informa-
tion Systems et d’acronyme TOOBIS a comme objectif de définir un SGBD OO temporel
au-dessus du SGBD O2 avec une méthode de conception adaptée. Ce projet a comme 2.2.1 Structure temporelle
partenaires : Matra, GlaxoWellcome, O2 Technology, 01-Pliroforiki, l’université d’Athènes
et l’université Paris 1-Panthéon Sorbonne. La structure temporelle permet de définir les éléments primitifs
Avant d’introduire cette extension temporelle, nous allons donner sur lesquels on veut travailler. Globalement, il existe deux options :
une vue générale des différents problèmes liés à la gestion du le temps vu comme un ensemble de points (ou instants) ou le temps
temps. vu comme un ensemble d’intervalles (ou durées). La structure ponc-
tuelle est utilisée en général dans les bases de données temporelles,
alors que la structure par intervalle est souvent utilisée dans le
domaine de l’intelligence artificielle appliquée à la planification
2. Les prérequis sur le temps automatique. Depuis les travaux d’Allen [3], la communauté de
l’intelligence artificielle utilise intensivement l’approche par inter-
valles temporels pour raisonner sur des connaissances temporelles
floues et imprécises. Les bases de données temporelles ont une pro-
2.1 Problématique liée blématique différente puisqu’elles mémorisent des connaissances
à la gestion du temps précises sur des événements observés, par conséquent la structure
ponctuelle est la plus adaptée.
La représentation de l’évolution des phénomènes réels dans le ■ Structure temporelle ponctuelle

temps pose les problèmes suivants. Le temps est considéré comme un axe infini mais, pour des rai-
sons pratiques, il est borné à gauche par le bing bang (il y a 144 mil-
■ Comment représenter le temps dans une base de données
lions d’années) et à droite par le bing crush (quelque part dans le
temporelles
futur). Ces deux limites sont notées beginning et forever. Le modèle
Le temps est traditionnellement vu dans les SGBDs comme un du temps que l’on considère dans les bases de données temporelles
champ de type date. La gestion du temps se résume alors à un type est discret ; cela veut dire que le temps est isomorphe à l’ensemble
de données, comme les entiers, avec les opérateurs de translation et des entiers (Z). Chaque entier est représenté par un point sur une
de comparaison. Cette gestion est trop restrictive et ne permet pas branche de l’axe du temps. Par contre, l’exploitation de ces points
de prendre en compte, par exemple, que les acteurs d’une organisa- sur l’axe du temps se fait en tenant compte de la continuité du
tion peuvent avoir des activités rythmées par des unités temporelles temps à travers les périodes et les intervalles de temps.
différentes qu’il faut pouvoir comparer ou rapprocher.
La structure temporelle est définie comme un ensemble de points
Exemple : un responsable de projet remplit sa feuille mensuelle avec une relation de précédence (<) qui est asymétrique et transi-
d’activités en jours ouvrés alors que l’activité du comptable est tive. Cette relation définit un ordre total.
rythmée par le calendrier comptable. La structure temporelle peut être linéaire ou arborescente.
Les problèmes liés à la représentation du temps et les La structure utilisée dans les bases de données temporelles est
solutions apportées par la communauté « des bases de données linéaire ; c’est-à-dire que deux points quelconques vérifient la rela-
temporelles » sont abordés paragraphe 2.2. La représentation du tion de précédence (il n’existe qu’une seule branche).
temps dans les SGBDs temporels peut se résumer : Par contre, le temps est arborescent lorsque plusieurs branches
— premièrement, par la structure temporelle qui est différente sont gérées et que la relation de précédence s’applique uniquement
selon les applications (cf. § 2.2.1) ; à l’intérieur d’une même branche. Avec le temps arborescent, on
— deuxièmement, par la mesure du temps abordant le problème peut gérer plusieurs passés, présents ou/et futurs. Cette fonctionna-
des données temporelles exprimées dans des unités temporelles lité est souvent utile dans des applications telles que la gestion de
spécifiques et/ou avec des niveaux d’imprécision différents (cf. l’hypothétique des systèmes militaires ou la gestion des événe-
§ 2.2.2) ; ments dans des systèmes parallèles.
Les bases de données temporelles utilisent en général une struc- Les différentes conversions entre unités doivent être définies
ture linéaire puisqu’un seul passé, présent et futur sont nécessaires. dans le calendrier.
■ Les types temporels définis pour manipuler le temps sont : ins- Exemple : la minute vaut 60 secondes.
tant, intervalle et période.
Transformer un instant d’une unité Ti en une unité Tj plus grande
Un point isolé sur l’axe du temps est appelé un instant. revient à perdre de la précision sur la localisation de cet instant sur
Le temps entre deux instants est appelé un intervalle de temps. l’axe du temps.
Un intervalle de temps est précisément décrit par un couple d’ins- Exemple : l’instant 1er janvier 1996 au niveau du jour devient l’ins-
tants : les bornes inférieure et supérieure. Un instant peut être tant janvier 1996 au niveau du mois.
considéré comme un intervalle de durée nulle (la borne inférieure
est égale à la borne supérieure). Les bornes d’un intervalle peuvent Par contre, transformer un instant d’une unité Ti en une unité Tj
être incluses ou pas. Nous verrons par la suite que, dans les histori- plus fine produit un instant ayant une estampille indéterminée.
ques, les intervalles sont fermés à gauche et ouverts à droite,
comme par exemple [20/12/96-25/12/96). Exemple : l’instant 1er janvier 1996 devient l’instant indéterminé
1er janvier 1996 00h ~ 1er janvier 1996 23h au niveau heure. L’estam-
Une période de temps est définie comme une durée, c’est-à-dire pille indéterminée exprime uniquement que sa valeur est l’un des ins-
une quantité de temps qui n’est pas localisable sur l’axe du temps. tants compris entre 00h et 23h.
Par opposition, un intervalle de temps est une quantité de temps qui
est bien située sur l’axe du temps. Dans la mesure où les conversions entre granules peuvent donner
Nota : il est à noter que l’intervalle correspond au type PERIOD de TSQL2. des résultats différents selon le point de vue que l’on a, TSQL2 [5]
De même la période représente le type INTERVAL de TSQL2. introduit deux opérateurs de conversion pour expliciter le résultat
attendu.
Les deux opérateurs de conversion sont scale et cast.
2.2.2 Mesures temporelles : calendrier et granules L’opérateur scale effectue toutes les conversions d’une unité en
une autre. Mais, il retourne un instant indéterminé lors d’une
L’axe du temps est un segment T qui peut être divisé en un nom- conversion en une unité plus fine alors que l’opérateur cast
bre fini de plus petits segments appelés granules. Chaque ensemble retourne un instant déterminé. La règle utilisée par cet opérateur
de granules définit un ensemble ordonné, puisque chaque granule pour lever l’indétermination est de prendre le premier instant de la
est associé à une sous-partie du segment T. Le partitionnement de période de temps.
l’axe du temps fournit une vue discrète de l’axe du temps. Par exem- SCALE(DATE 06/01/1994 AS MONTH) = 01/1994
ple, une partition du temps au niveau du jour permet de définir des SCALE(DATE 06/01/1994 AS HOUR) = 06/01/1994 00 ~ 06/01/1994 23
segments qui ont une durée d’un jour. Cette vue discrète du temps
CAST(DATE 06/01/1994 AS MONTH) = 01/1994
est dynamique, elle se construit lors de l’exécution des requêtes uti-
lisateurs. Lorsque l’utilisateur choisit une unité, il peut voir le temps CAST(DATE 06/01/1994 AS HOUR) = 06/01/1994 00
comme un ensemble de secondes, de jours, d’années, etc. CAST(DATE 06/01/1994 AS MINUTE) = 06/01/1994 00:00
Si l’on regarde un instant avec différents granules, l’information Dans le calendrier grégorien, les conversions entre unités sont
que l’on obtient est différente. régulières ou irrégulières.
Exemple : l’instant « 01/01/1970 » au niveau jour devient un instant Exemple : la transformation d’une minute en 60 secondes est dite
dans l’intervalle [01/01/1970 00h00min00s - 02/01/1970 00h00min00s) régulière, alors que la transformation d’un mois en jours est irrégulière
exprimé avec l’unité seconde. puisqu’elle dépend du mois ; janvier équivaut à 31 jours, février vaut
29 jours pour les années bissextiles et 28 sinon, etc.
L’univers temporel [4] est une suite finie de domaines temporels
disjoints <T0 , T1, ..., Tn >. Chaque domaine temporel Ti est une parti- La figure 1 montre le système de conversion du calendrier grégo-
tion du domaine temporel Ti + 1. Le plus petit domaine temporel T0 rien. La mesure de la seconde est basée sur la rotation de la Terre.
est partitionné à l’aide du chronon. Par exemple, <seconde, minute, Cependant, la Terre ralentit d’environ 2 millisecondes par jour, soit
heure, jour, mois, année> est un univers temporel. Dans cet univers, environ une seconde de décalage au bout de 500 jours. En consé-
il est impossible d’insérer les semaines puisqu’une semaine peut quence, une seconde intercalaire est ajoutée à la minute avant
chevaucher deux mois ou deux années. minuit à certaines dates sélectionnées à l’avance par l’International
Earth Rotation Service (IERS). La dernière minute de l’année 1995
La plus petite quantité de temps représentable est le chronon. La contenait 61 secondes.
taille d’un instant est égale à la taille du chronon. Une estampille
informe qu’un fait s’est passé durant un chronon ou un granule par-
ticulier. L’instant exact modélisé par l’estampille n’est jamais connu,
seul le granule est localisé sur l’axe du temps. De même, deux
estampilles exprimées dans le même domaine temporel peuvent
représenter deux instants physiquement différents. Par conséquent,
l’estampille « 01/01/1970 » exprime une incertitude au niveau de Année
l’heure. Nous supposerons que l’estampille représente le premier 1/12 12
instant du granule où elle se trouve. Nous supposons également Mois
qu’un instant représente le chronon ou le granule où il est localisé irrégulier irrégulier
en entier. Il est à noter qu’un instant a une durée nulle alors qu’un Jour
granule ou un chronon a une durée non nulle. Un instant s’exprime 1/24 24
par rapport à un granule défini dans le système d’unité choisi. Heure
L’unité de base internationale est la seconde. Les calendriers ont 1/60 60
été introduits pour rythmer et mesurer les faits de la vie quoti- Minute
dienne. Un calendrier est une abstraction de l’axe du temps. Un 1/60 60
calendrier est défini par son nom, son origine, une collection de gra- Seconde
nules ainsi qu’un système de conversion entre les différentes unités.
Le calendrier par défaut est le calendrier grégorien composé des
unités : seconde, minute, heure, jour, mois et année. Figure 1 – Système de conversion du calendrier grégorien
Les périodes de temps permettent de manipuler des quantités de ■ Temps relatif

temps qui ne sont pas localisées sur l’axe du temps ; 3 mois ou
Une référence temporelle est dite relative lorsqu’elle est liée à une
15 secondes sont des exemples de périodes de temps. On distingue
autre référence temporelle.
deux types de périodes : fixes et variables. Un mois est une période
variable puisque la quantité de jours dans un mois est variable. Par Exemple : « 4 jours après le début du prêt de numéro 357 » ou « la
contre, 15 secondes est une période fixe. Un problème survient sou- tâche 2 du projet est précédée par la tâche 3 » sont des exemples de
vent lorsque l’on fait des opérations entre les instants et les pério- références temporelles relatives puisqu’elles s’expriment par rapport à
des. une autre référence temporelle « début du prêt de numéro 357 » ou
Supposons un instant au niveau jour et une durée d’un mois à « intervalle de validité de la tâche 3 ».
ajouter, les trois stratégies suivantes peuvent être appliquées : En règle générale, ce type de références temporelles est exploité
— le même jour dans le mois suivant : en intelligence artificielle, puisque l’objectif est de trouver les ordon-
• par exemple : 03/05/1996 + 1 mois = 03/06/1996 nancements possibles entre faits qui ont des estampilles temporel-
• mais que fait : 31/05/1996 + 1 mois = ? les relatives. Dans ce cas-là, il faut appliquer un raisonnement
— le même nombre de jours à partir du début du mois : d’inférence sur les références temporelles relatives des faits. Ces
• par exemple : 30/05/1996 + 1 mois = 30/06/1996 références temporelles relatives peuvent se voir comme les
contraintes temporelles existant entre ces faits. Elles s’expriment le
• mais que fait : 31/05/1996 + 1 mois = ?
plus souvent à l’aide des 13 opérateurs d’Allen entre intervalles [6]
— le même nombre de jours à partir de la fin du mois : (précède, rencontre, chevauche, débute...).
• par exemple : 31/05/1996 + 1 mois = 30/06/1996
Dans les bases de données temporelles, la problématique est dif-
• mais que fait : 01/05/1996 + 1 mois = ?
férente puisque l’idée est de stocker la succession des images de
La solution la plus généralement adoptée est une combinaison faits réels précis.
des deux derniers cas :
Le temps relatif qui est introduit dans les bases de données tem-
— si l’instant est dans la première moitié du mois, l’opération uti- porelles [5], [7] se réduit à une translation d’une quantité de temps
lise le nombre de jours à partir du début du mois ; sur une référence temporelle (renseignée ou non renseignée). Cette
— si l’instant est dans la deuxième moitié du mois, l’opération référence temporelle est représentée par une requête base de don-
utilise le nombre de jours à partir de la fin du mois. nées. L’objectif ici n’est pas de trouver les ordonnancements possi-
Le milieu du mois est fixé au seizième jour à minuit, sauf pour le bles à partir de contraintes temporelles entre faits, mais plutôt
mois de février (quinzième jour à minuit). Par conséquent les opéra- d’aider l’utilisateur dans ses tâches de planification en lui fournis-
tions précitées deviennent : sant, pour la manipulation des références temporelles relatives, les
— 31/05/1996 + 1 mois = 30/06/1996 ; mêmes opérateurs que sur les références temporelles absolues.
— 01/05/1996 + 1 mois = 01/06/1996. ■ Temps périodique
L’addition de durées décimales se fait en deux étapes : addition de
Le temps périodique est défini comme une suite infinie d’instants
la partie entière puis l’addition de la partie décimale.
ou d’intervalles (séries temporelles) où la distance temporelle entre
Exemple : 10/05/1996 + 1,5 mois donne comme résultat 10/06/ deux éléments est exprimée par une durée.
1996 + 0,5 mois, et enfin 25/06/1996 parce que juin contient 30 jours
Exemple : « le 25e jour de chaque mois » exprime un temps pério-
(30 ´ 0,5 = 15).
dique.
Si le nombre de jours obtenu excède la durée du mois, l’excédent
est appliqué sur le mois suivant. La gestion de ce type de temps est nécessaire pour déclencher un
traitement lorsqu’un événement de cette série temporelle survient.
Exemple : 21/06/1996 + 0,5 mois donne 01/07/1996 + 1/6 mois Nous pouvons restreindre la définition du temps périodique que
(30 ´ 0,5 = 15, 15 – 10 = 5 et 5/30 = 1/6), ce qui donne 06/07/1996. l’on veut gérer au dernier élément survenu et à la distance tempo-
relle entre deux éléments.
Les secondes intercalaires sont utilisées dans le calcul des inter-
valles variables lorsque les niveaux mois et jours sont déterminés. Les temps absolu et relatif peuvent être utiles pour estampiller
des informations à stocker dans la base de données. Le temps pério-
dique est utilisé pour décrire le moment du déclenchement d’un trai-
2.2.3 Types de temps : absolu, relatif et périodique tement sur la base de données.
■ Temps absolu
Il existe trois types de temps : absolu, relatif et périodique. 2.2.4 Estampiller versus historiser
Une référence temporelle est dite absolue lorsqu’elle est liée à un
instant d’un calendrier, on parle de temps absolu. Il nous est apparu intéressant de faire la distinction entre les ter-
mes estampiller et historiser.
Exemple : l’instant absolu 1996/07/06 04h04min48sec est exprimé
au niveau de la seconde dans le calendrier grégorien. De même, l’inter- Pour différencier ces deux termes, nous utilisons les concepts du
valle [1er janvier 1996, 31 mars 1996) est un exemple d’intervalle modèle TIGRE [8] : la photographie, l’album et le film.
absolu puisque la borne inférieure et la borne supérieure de cet inter- La photographie est une vue de la base matérialisée à un instant
valle sont des instants absolus. donné ; elle permet de garder une image de certains objets de la
Le traitement des références temporelles absolues se résume à base dans l’état où ils se trouvaient au moment où la photographie
un calcul de points sur une droite. Il nécessite : a été prise. Le concept de photographie permet d’associer, à un état
de la base, un instant représentant le moment où l’on a pris la pho-
— d’avoir des opérateurs de conversion d’unités (conversion tographie. Estampiller est un concept équivalent puisqu’il va per-
entre granules d’un même calendrier ou d’un calendrier différent) ; mettre d’associer un temps à l’état d’un objet. Comme nous le
— d’avoir des opérateurs arithmétiques pour faire des transla- verrons au paragraphe 2.3, la sémantique du temps peut être le
tions de points ainsi que des opérateurs de comparaison. temps de modification dans la base (temps de transaction) ou/et le
En règle générale, les bases de données temporelles sont dotées temps de modification dans le monde réel (temps de validité).
de ces fonctionnalités. L’estampille matérialise le temps que l’on associe à l’état d’un objet.
Les concepts d’albums et de films dans le système TIGRE [9] [10] Nous présentons, dans ce qui suit, les propriétés inhérentes à cha-
permettent de gérer des historiques de photographies, néanmoins cun de ces types, que nous illustrons à l’aide d’un exemple pour la
ils ne retracent pas tous les états possibles de la base mais tous ses gestion du personnel d’une entreprise. Dans l’exemple que l’on
états photographiés. Historiser est un concept permettant de gérer développe, l’estampille temporelle considérée est un intervalle de
tous les états d’un objet avec leur estampille temporelle. temps matérialisé par deux instants : début et fin.
Dans la problématique de conception, le besoin d’estampiller
■ Les objets statiques sont présents dans les bases conventionnel-
exprime le fait que l’on veut associer le temps de modification au
les modélisant le monde réel par un « instantané » (snapshot) repré-
dernier état d’un objet. Par contre, l’historique se rencontre lorsque
sentatif de l’état du monde réel à l’instant courant. Un changement
tous les états d’un objet doivent être gardés. Dans le paragraphe sui-
d’état de la base de données correspond à une opération d’inser-
vant, nous aborderons des travaux qui se concentrent sur la défini-
tion, de suppression ou de modification des données. Les opéra-
tion et la représentation des historiques.
tions de mise à jour et de suppression provoquent la perte de l’état
précédent des données impliquées par le changement de la base.
Les applications développées autour de bases de données ne gérant
que des objets statiques se doivent de gérer elles-mêmes les diver-
2.3 Les dimensions temporelles ses informations temporelles.
■ Les objets historiques permettent, comme leur nom l’indique, de

Les premiers travaux significatifs sur l’intégration du temps dans préserver l’historique des données. Les états successifs d’un objet
les modèles de données ont permis de comprendre qu’il n’était pas sont indexés par le temps de validité (temps du monde réel).
suffisant de représenter le temps avec une seule et unique dimen-
sion temporelle. La raison en est le délai inévitable qui existe entre Les erreurs détectées dans les objets historiques peuvent être cor-
le moment où un événement est constaté dans la réalité et le rigées (les nouvelles valeurs remplacent physiquement les ancien-
moment où cet événement est pris en compte dans la base de don- nes).
nées. Les opérations appliquées pour obtenir les objets du tableau 1
Afin de clarifier la situation engendrée par les multiples termino- sont les suivantes :
logies en vigueur autour de la notion de dimension temporelle, — les objets Durand (a) et Martin (c), créés le 1/01/95 à
Snodgrass et Ahn [11] ont proposé, en 1985, trois types de temps 9h20min15s (cf. tableau 2), ne prennent pas effet dans le monde
permettant de définir quatre types de bases de données dépendan- réel aux mêmes dates. L’objet Durand a la fonction de program-
tes du temps. Ces typologies restent d’actualité. meur dans le monde réel depuis le 12/12/94 (date de début de vali-
dité) alors que l’objet Martin sera analyste programmeur à partir
Dans les bases de données temporelles [5] [11] trois dimensions
du 1/02/95 ;
temporelles sont introduites :
— l’objet Martin est initialement créé le 1/01/95 à 9h20min15s
— le temps de validité (valid time) est le temps auquel (ou durant (cf. tableau 2) avec, pour date de début de validité, le 1/02/95. Mais
lequel) l’information mémorisée dans la base est valide dans le il y a eu erreur sur sa fonction. L’opération de correction est effec-
monde réel ; tuée le 10/01/96 à 14h56min50s. Cela conduit à changer la fonction
Exemple : l’employé Dupond a été employé par la compagnie sans historiser l’état précédent ; aucune trace de la modification
expert du 2/01/95 au 12/10/96. n’apparaît dans l’historique avec le temps de validité ;
— le 1/01/96 à 14h56min50s, l’objet Durand est modifié consécu-
Cette définition permet de représenter soit l’instant où un fait est tivement au changement de fonction prenant effet le 20/12/95 : le
valide (un point du temps), soit la période de validité d’un fait (un temps de fin de validité du n-uplet (a) devient le 20/12/95 et le n-uplet
intervalle). La période de validité de l’information précédente est un (b) est créé (correspondant à la nouvelle fonction) avec la date de
intervalle [2/01/95,12/10/96). début de validité du 20/12/95 (et une date de fin de validité égale à
— le temps de transaction (transaction time) représente l’instant forever) ;
où le fait survenu est enregistré dans la base ; — le 15/10/96 à 10h50min10s, l’objet Dupond est logiquement
supprimé avec, pour date d’effet (dans le monde réel), le 12/10/96 ;
Exemple : l’enregistrement de l’embauche de M. Dupond dans la le temps de fin d’existence devient ainsi physiquement le 15/10/96 à
base s’est effectué le 10/01/95 à 14h56min50s et son départ a été 10h50min10s (cf. tableau 2).
effectif en base le 15/10/96 à 10h50min10s.
■ Les objets rétrospectifs permettent de préserver les états
Par conséquent, le temps de transaction de cette information est successifs d’un objet en les indexant par le temps de transaction
l’intervalle [10/01/95 14h56min50s, 15/10/96 10h50min10s). (transaction time), c’est-à-dire le temps auquel l’information est
— le temps utilisateur (user-defined time) est nécessaire pour effectivement mémorisée dans la base. La sémantique de temps est
toutes les informations temporelles dépendantes de l’application ; il différente de celle adoptée par les objets historiques : le temps de
s’agit d’une information ayant une sémantique de temps gérée par validité est remplacé par le temps de transaction.
l’application.
Exemple : la date de naissance d’un individu.
LR. Snodgrass et I. Ahn proposent une classification des bases de Tableau 1 – Exemples d’objets historiques
données reflétant leur capacité à représenter les diverses dimen-
sions temporelles. Cette classification est fondée sur le temps de Temps de validité
validité et le temps de transaction. Elle permet de distinguer quatre Employé Nom Fonction
types de bases de données : statiques, historiques, rétrospectives et Début Fin
temporelles. Nous appliquons comme dans [7] la classification de
Snodgrass aux objets plutôt qu’aux bases de données. Elle conduit (a) Durand programmeur 12/12/94 20/12/95
aux 4 types d’objets suivants :
— les objets statiques (static objects) ; (b) Durand chef de projet 20/12/95 forever
— les objets rétrospectifs (rollback objects) ; (c) et (d) Martin ingénieur 1/02/95 forever
— les objets historiques (historical objects) ;
— les objets temporels (bi-temporal objects). (c) Dupond chef de service 2/01/95 12/10/96
Tableau 2 – Exemples d’objets rétrospectifs

Temps de transaction
Employé Nom Fonction
Début Fin
(a) Durand programmeur 1/01/95 9h20min15s 1/01/96 14h56min50s
(b) Durand chef de projet 1/01/96 14h56min50s now
(c) Martin analyste-programmeur 1/01/95 9h20min15s 10/01/96 14h56min50s
(d) Martin ingénieur 10/01/96 14h56min50s now
(e) Dupond chef de service 10/01/95 14h56min50s 15/10/96 10h50min10s
L’une des caractéristiques essentielles des objets rétrospectifs est la cible de requêtes rétrospectives (concernant l’état de l’objet à un
que toute opération de mise à jour des données (insertion, modifica- instant donné), que celle de questions historiques (concernant, cette
tion, suppression) porte obligatoirement sur le dernier état de la fois-ci, l’état du monde réel valide à un temps donné).
base et donne lieu à un nouvel état. Par l’intégration du temps de Pour ce faire, ils prennent simultanément en compte les notions
transaction, aucune modification n’est réellement effectuée sur les de temps de transaction et de temps de validité, ce qui leur permet
données. De plus, les informations deviennent valides dès lors de représenter les objets valides, à un certain instant, dans le monde
qu’elles sont énoncées. De ce fait, les objets rétrospectifs mémori- réel, tels qu’ils étaient connus du système à un autre instant.
sent l’historique de leurs mises à jour plutôt que l’historique des
faits du monde réel. Cette dualité de la sémantique temporelle a pour incidence que,
tout comme sur les objets rétrospectifs, toute opération de mise à
Les corrections apportées à des objets historiques ne génèrent, en
jour des données (insertion, modification, suppression) conduit à la
aucun cas, un nouvel état de l’objet : les nouvelles valeurs rempla-
création d’un nouvel état de la base (append-only).
cent physiquement les anciennes. Le fait même qu’il y ait eu correc-
tion n’est pas mémorisé. Les objets historiques ressemblent, sur ce Les objets temporels permettent également de prendre en
point, aux objets statiques. compte les opérations de mise à jour rétroactives/postactives. Les
notions de rétroaction (en retard) et de postaction (en avance) sont
Les objets rétrospectifs permettent de revenir à un état antérieur
issues du fait qu’il s’avère nécessaire, dans de nombreux cas, de
de l’objet qui peut s’avérer faux, à l’instant présent, dans le monde
distinguer la notion de temps de validité de celle de temps trans-
réel. Inversement, les objets historiques ne permettent pas de reve-
actionnel, c’est-à-dire de prendre en compte l’éventuelle différence
nir à un état antérieur de l’objet, mais s’attachent à représenter les
existant entre le temps d’occurrence d’un événement dans le monde
états passés du monde réel tels qu’ils sont actuellement connus (les
réel et son temps de prise en compte effective dans la base.
données fausses ayant été éliminées).
Les divers objets présentés dans le tableau 2 résultent des mêmes Les objets présentés dans le tableau 3 résultent des mêmes opé-
opérations ayant conduit aux objets présentés dans le tableau 1. rations que celles ayant conduit aux objets des tableaux 1 et 2.
Les différences proviennent de la divergence sémantique concer- Toutes les étapes de l’évolution des données sont, cette fois-ci,
nant la notion d’historique entre objets rétrospectifs et objets histori- mémorisées :
ques. — l’objet Durand occupe la fonction de programmeur depuis
Le tableau 2 illustre la gestion d’un historique avec le temps de le 12/12/94 et ce fait a été enregistré, de façon rétroactive, le 1/
transaction. Les objets précédents résultent des opérations sui- 01/95 à 9h20min15s (le temps transactionnel de fin d’existence
vantes : du n-uplet (a) est initialement now). Sa fonction devient chef de
projet le 20/12/95 ; ce fait est enregistré en base le 1/01/96 à
— l’objet Durand (a) et l’objet Martin (c) sont créés le 1/01/95 à 15h56min50s. Cette modification logique conduit à la modifica-
9h20min15s ; tion du temps (transactionnel) de fin d’existence de l’état (a),
— l’objet Dupond (e) est créé le 10/01/95 à 14h56min50s ; ainsi qu’à la création des états (b) et (c). La création de l’état
— le 10/01/96 à 14h56min50s, l’objet Martin (c) est corrigé suite à (b), plutôt que la modification du temps de fin de validité de
une erreur, la fonction n’est pas analyste-programmeur mais ingé- l’état (a), permet de représenter le fait qu’il y a eu modification
nieur. Par conséquent, l’état (c) de l’objet a son temps de fin d’exis- du n -uplet et non que le temps de fin de validité de la valeur
tence qui est porté au 10/01/96 à 14h56min50s et la version (d) est programmeur avait toujours été fixé au 20/12/95 ;
créée dont le temps de début d’existence est cette même donnée (le
— l’état (d) de l’objet Martin est créé, de façon rétroactive, le
temps de fin d’existence est la marque dynamique now) ;
1/01/95 à 9h20min15s, puis corrigé le 10/01/95 à 14h56min50s ;
— l’objet Durand a été modifié le 1/01/96 à 14h56min50s : la
il n’y a création que d’un seul n-uplet dans le cas d’une correc-
fonction devient chef de projet. Cette modification logique conduit
tion, alors que deux nouveaux n -uplets sont créés lors d’une
à la modification physique de la version (a) (son temps de fin
modification ;
d’existence devient le 1/01/96 à 14h56min50s), ainsi qu’à la création
— enfin, l’état (f) de l’objet Dupond est créé le 10/01/95 à
du n-uplet (b) dont le temps de début d’existence est le 1/01/96 à
14h56min50s, pour être supprimé (de façon logique) le 15/10/96 à
14h56min50s et celui de fin est la marque dynamique now ;
10h50min10s.
— le 15/10/96 à 10h50min10s, l’objet Dupond (e) est logiquement
supprimé, ce qui conduit à la modification (par le SGBD) de son Ce type d’objet est donc sémantiquement le plus riche.
temps de fin d’existence. On peut résumer cette classification des objets dépendant du
Nota : il s’avère impossible, dans le cadre des objets rétrospectifs, de distinguer une temps sous la forme du tableau 4.
modification due à une évolution du monde réel, d’une modification correspondant à une
correction d’erreur. Pour faire cette distinction, nous offrons deux opérations de modifica- Après avoir présenté un bref état de l’art sur le temps et la ges-
tion ; l’une s’appelle évolution et l’autre correction. Ces opérations gèrent un indicateur
pour savoir si l’état de l’objet est issu d’une évolution ou d’une correction.
tion du temps dans les bases de données temporelles, nous abor-
dons, dans le paragraphe suivant, l’extension temporelle de la
■ Les objets temporels conjuguent les avantages des objets rétros- méthode conceptuelle orientée objet et événement présentée dans
pectifs et des objets historiques. En effet, ils peuvent aussi bien être [2] et [12].
Tableau 3 – Exemples d’objets temporels

Temps de validité Temps de transaction
Employé Nom Fonction
Début Fin Début Fin
(a) Durand programmeur 12/12/94 forever 1/01/95 9h20min15s 1/01/96 15h56min50s
(b) Durand programmeur 12/12/94 20/12/95 1/01/96 15h56min50s now
(c) Durand chef de projet 20/12/95 forever 1/01/96 15h56min50s now
(d) Martin analyste-programmeur 1/02/95 forever 1/01/95 9h20min15s 10/01/95 14h56min50s
(e) Martin ingénieur 1/02/95 forever 10/01/95 14h56min50s now
(f) Dupond chef de service 2/01/95 forever 10/01/95 14h56min50s 15/10/96 10h50min10s
(g) Dupond chef de service 2/01/95 12/10/96 15/10/96 10h50min10s now
Les contraintes statiques du modèle sont de trois types : contrain-

Tableau 4 – Taxonomie d’une base de données tes de propriété, contraintes d’unicité et contraintes d’héritage.
Temps de transaction Exemple : « la date de naissance du patient ne peut pas être infé-
Temps de validité rieure à 1870 » est une contrainte de propriété.
Non présent Présent « Les numéros de commande sont uniques dans l’ensemble des
commandes » est un exemple de contrainte d’unicité,
Non présent Objets statiques Objets rétrospectifs « Une personne est nécessairement un homme ou une femme mais
Présent Objets historiques Objets temporels pas les deux » exprime une contrainte de partition sur la classe généra-
lisée Personne (contrainte d’héritage).
3. La modélisation Composition Référence
conceptuelle temporelle
Lien dynamique :
Héritage événement
Classe
3.1 Rappel des concepts d'objet
du modèle conceptuel Mécanisme

d'instanciation
Objet
Les concepts de base de la méthode sont détaillés dans [12]. Nous
illustrons brièvement les concepts de classe, d’événement et d’opé-
ration.
■ Une classe décrit un ensemble d’objets de même nature, qui sont Figure 2 – Les principaux concepts du modèle OO
qualifiés d’instances de la classe. Une classe définit la structure et le
comportement de ses instances. La structure est décrite en termes
de propriétés et de contraintes. Le comportement est décrit en ter-
mes d’opérations et d’événements. Les principaux liens qui relient
les objets sont mentionnés à la figure 2.
● Une classe est caractérisée par des propriétés statiques. Ces
propriétés sont les liens de composition, les liens de référence et les Commande Client
attributs. Comme l’illustre la figure 3, la classe commande est
composée d’un ensemble de lignes de commande, référence un Lien de référence
client et a comme attributs le numéro de commande et la date de Lien de composition
passation de commande. Ligne multiple
Le lien d’héritage entre deux classes établit une relation de spé-
cialisation-généralisation entre chaque objet de la première classe Classe COMMANDE
dit objet spécialisé et un objet de la seconde classe dit objet généra- Proprietés
lisé. Par extension, on parlera respectivement de classe spécialisée numéroCommande : Entier
et de classe généralisée, la classe spécialisée héritant de la classe dateCommande : Date
généralisée. L’héritage concerne aussi bien les propriétés statiques détail : comp ( ensemble (LIGNE))
que les propriétés dynamiques. Il permet de modéliser plusieurs refclient : ref (CLIENT)
perspectives d’un même phénomène du monde réel, chaque pers-
pective étant représentée par un objet. La figure 4 illustre le fait
qu’une personne peut se différencier par rapport soit à son sexe,
soit à sa situation familiale. Figure 3 – Exemple de classe
Personne
Homme Femme Célibataire Marié Divorcé
Classe Personne Classe Femme Classe Marié

Propriétés Hérite de Personne Hérite de Personne
Nom : Chaîne Propriétés Propriétés
Prénom : Chaîne Nom-de-jeune-fille : Chaîne Date-mariage : Date
Figure 4 – Exemples de liens d’héritage
● Les propriétés dynamiques sont décrites en termes d’opéra- ■ En résumé :

tions et d’événements. — la description conceptuelle de la base de données est compo-
Les opérations décrivent, de manière locale à une classe, l’ensem- sée de l’ensemble des descriptions de classes d’objets qu’elle doit
ble des traitements qu’il est possible de faire sur les objets tandis gérer. Une classe d’objets est décrite par : des propriétés statiques,
que les événements permettent de décrire les interactions de type des contraintes, des opérations et des événements internes ;
causal entre objets qui existent (l’évolution d’un objet pouvant — l’environnement de la base de donnée est pris en compte dans
entraîner l’évolution d’autres objets). la spécification conceptuelle ; il est constitué d’un ensemble
Suivant le principe d’encapsulation du paradigme objet, l’évolu- d’acteurs et d’une horloge ; les uns et les autres agissent sur la base
tion d’un objet n’est possible qu’au travers des opérations définies de données par l’intermédiaire des événements qu’ils déclenchent.
sur sa classe. Une opération est une procédure ou une fonction dont La base de données peut être amenée à agir sur les acteurs par l’inter-
le déclenchement provoque la création, la modification ou la sup- médiaire d’envoi de messages comme l’illustre l’événement rupture
pression d’un objet de la classe. Les opérations sont définies dans le de stock. L’horloge est décrite par la classe Calendrier qui regroupe
schéma de la classe. l’ensemble des événements temporels alors que les acteurs sont
définis au travers des classes d’acteurs. Une classe d’acteur regroupe
Une occurrence d’événement est une projection d’un phénomène les messages que les acteurs envoient à la base (événements exter-
du monde réel qui survient à un instant donné et qui a un impact sur nes) et ceux qu’ils reçoivent (opérations externes).
les objets de la base.
Le modèle présenté en détail dans [12] et rappelé dans ce paragra-
Exemple : l’arrivée du patient Dupond à l’hôpital le 21/5/96 et la phe ne tient pas explicitement compte des aspects temporels. Le
livraison de la commande n° 36 du client Martin sont des occurrences paragraphe 3.2 suivant propose une extension temporelle du
d’événement. Le premier a un impact sur l’objet patient Dupond et le modèle.
second modifie l’objet commande n° 36.
Un événement décrit un ensemble d’occurrences d’événement de
même nature. Cette description comprend la cause de la survenance 3.2 Extension temporelle
d’une occurrence d’événement et son impact sur les objets de la du modèle conceptuel
base.
Un événement est typé selon sa condition d’occurrence : L’extension temporelle du modèle [13], [14], [15] comprend :
— un événement interne constate le changement d’état remar- — la redéfinition de la classe Calendrier ;
quable d’un objet base de données ; — la définition de domaines temporels ;
— un événement temporel survient à un instant déterminé à — l’introduction de deux types de classes : les classes instanta-
l’avance ; nées (des objets statiques au sens du paragraphe 2) et les classes
— un événement externe a pour origine un stimulus en prove- temporelles (gestion d’estampillage ou d’historique) ;
nance d’un acteur de l’environnement du système d’information. — l’extension de la typologie des contraintes.
Cet événement est associé à un message informationnel.
L’emplacement dans lequel est défini l’événement dépend de son
type. Un événement interne est défini dans la classe des objets à 3.2.1 Les calendriers
partir desquels il constate un changement d’état. Un événement
temporel est défini sur la classe particulière nommée Calendrier qui La première extension proposée consiste à se doter d’un calen-
regroupe tous les événements temporels du système d’information. drier adapté à la spécificité des aspects temporels de l’application à
Enfin la classe d’acteurs regroupe l’ensemble des événements développer. Traditionnellement, les bases de données se basent sur
qu’un acteur de cette classe peut déclencher sur la base de données. un seul calendrier, le calendrier grégorien. Les types temporels
La passation d’une commande est un événement externe prove- DATE ou DATETIME permettent de représenter des estampilles tem-
nant de l’acteur client qui déclenche la création d’une commande. porelles avec des granules grégoriens différents (jour ou seconde).
Par contre, l’événement interne rupture de stock est constaté lors- Mais, si l’organisation a des rythmes temporels qui lui sont spécifi-
que la quantité en stock d’un produit devient inférieure au seuil ques, l’application doit explicitement les gérer.
limite ; une alerte est alors envoyée au responsable des stocks. Enfin
chaque jour, on annule les commandes qui ne sont pas réglées une Exemple : si le comptable rythme ses activités sur le « calendrier
semaine avant la date de livraison souhaitée est un exemple d’évé- comptable » et que le chef de projet utilise le « calendrier des jours
nement temporel. Ces trois événements sont illustrés graphique- ouvrés », l’application doit gérer les deux calendriers avec les opéra-
ment à la figure 5. teurs de translation et de conversion qui leur sont associés.
Produit Client
passation d'une commande Horloge

rupture_de_stock
Responsable Commande
stock chaque jour
Créer
Alerte_stock
Annuler
f1
f1 : ensemble des commandes non réglées une semaine avant la livraison souhaitée
Événement externe Événement interne Événement temporel
f1 : itération selon f1 déclenche
Figure 5 – Exemples d’événements
L’objectif de l’extension est de doter le modèle :

— d’un calendrier par défaut (le calendrier grégorien) ;
— d’un mécanisme de définition d’un nouveau calendrier ; classe calendrier grégorien
— d’un mécanisme de gestion de plusieurs calendriers pour une origine : « 01/01/0001 :00 :00 :00 »
même application. unité de base : chronon
granules :
Le modèle conceptuel initial contient le concept de « classe seconde : { 1 chronon, 1 seconde }
calendrier » qui représente le calendrier grégorien. minute : { irrégulier, irrégulier }
Nous étendons la classe Calendrier de la façon suivante ; un heure : { 60 minutes, 1/60 heure }
calendrier est défini par : jour : { 24 heures, 1/24 jour }
mois : { irrégulier, irrégulier }
— un nom ; année : { 12 mois, 1/12 année }
— une origine, qui est l’instant bornant à gauche l’axe du temps ; opérations :
— un système de mesure matérialisé par une liste ordonnée de opérateur translation (instant, période)
granules, contenant, pour chacun d’eux, la conversion ascendante instant opérateur cast (instant, granule)
et la conversion descendante. Lorsque la conversion est régulière, instant opérateur vers_grégorien (instant)
on précise le coefficient à appliquer mais, lorsque la conversion est instant opérateur à partir_grégorien (instant)
irrégulière, l’irrégularité doit être prise en compte dans les opéra- fin Classe
tions de translation et de conversion ;
— une opération de translation d’un instant en une période
(durée) ; Figure 6 – Définition du calendrier grégorien
— une opération de conversion entre granules d’un même calen-
drier ;
deux opérations de conversion, l’une vers le calendrier grégorien
et l’autre partant du calendrier grégorien. Ces deux opérations per-
mettent d’avoir des conversions intercalendriers. classe calendrier : universitaire
origine : « 01/01/0001 :00 :00 :00 »
Exemple : le calendrier grégorien se définit comme suit (figure 6) : unité de base : jour grégorien
La minute et le mois sont des granules irréguliers, leur quantité de granules :
temps est variable. La minute vaut généralement 60 secondes sauf semaine : { 6 jours, 1/6 jour }
lorsque l’on ajoute une seconde intercalaire. De même, le nombre de semestre : { 12 semaines, 1/12 semestre }
jours dans un mois varie selon le mois considéré. année : { 2 semestres, 1/2 année }
L’université rythme ses formations sur la notion d’année universi-
opérations :
taire composée de deux semestres contenant chacun 24 semaines. La
opérateur translation (instant, période)
figure 7 illustre la définition du calendrier universitaire. instant opérateur cast (instant, granule)
On suppose qu’une semaine d’enseignement peut se faire du lundi instant opérateur vers_grégorien (instant)
au samedi (6 jours). instant opérateur à partir_grégorien (instant)
fin Classe
Le modèle fournit le calendrier grégorien par défaut en permet-
tant la définition de nouveaux calendriers comme l’illustre l’exem-
ple précédent. Figure 7 – Définition du calendrier universitaire
Il permet la gestion de plusieurs calendriers simultanés pour une

même application. La coexistence de plusieurs calendriers implique
la définition de règles de conversion intercalendriers. Elles sont classe : Employé
associées aux opérateurs vers_grégorien et à partir_grégorien propriétés
(figure 7). datenaissance : INSTANT < grégorien, jour >
3.2.2 Les domaines temporels

Figure 8 – Exemple d’attribut temporel
L’objectif de cette extension est de doter la base de données tem-
porelles de mécanisme de représentation du temps permettant :
— de s’adapter aux calendriers définis par le concepteur ; — INSTANT-R et INTERVALLE-R sont les domaines représentant
— d’exprimer l’estampille temporelle à des niveaux différents les instants ou les intervalles de temps relatif ;
d’imprécision ; — INSTANT et INTERVALLE sont conservés pour représenter des
— d’exprimer et de gérer aussi bien le temps absolu que le temps instants ou des intervalles dont le type de temps n’est pas fixé à
relatif. l’avance.
Rappelons qu’il existe trois types temporels : instant, intervalle et En affinant l’exemple de la figure 9, nous pouvons définir, comme
période (cf. paragraphe 2.2.1). Un instant représente un point sur temps absolu, le temps des attributs temporels datenaissance, sem.
l’axe du temps (12/12/1996). Un intervalle est la quantité de temps Par contre, l’intervalle de temps du projet (attribut Dates) reste de
comprise entre deux instants localisés sur l’axe du temps ([12/12/ type INTERVALLE (type de temps non déterminé), parce que certains
1996, 15/12/1996)). Par contre, la période est une durée (quantité) de projets pourraient l’exprimer de manière absolue (comme, par
temps qui ne se localise pas sur l’axe du temps (3 mois). Ces trois exemple, durant l’intervalle de temps [97/10/02 ; 98/06/02)) et
types temporels s’expriment par rapport à un granule d’un calen- d’autres de manière relative (comme, par exemple, entre
drier. [date_signature ; date_signature+18mois)).
Les domaines temporels sont nécessaires pour définir le domaine Par exemple, la date de fin du projet est égale à « J0+30mois », J0
de valeurs des attributs ayant une sémantique temporelle. étant un repère temporel. De même, la tâche1 de ce projet se
Exemple : l’attribut datenaissance de la classe Employé se décrit déroule durant l’intervalle en temps relatif suivant : [début du pro-
comme un instant exprimé au niveau jour du calendrier grégorien jet+7 jours, début du projet+2mois7jours). Le temps relatif s’appa-
comme l’illustre la figure 8. rente à un attribut temporel dérivable ou calculé. La formule de
calcul est limitée à l’addition du repère temporel à une durée
La figure 9 montre d’autres exemples de domaines temporels (<repère temporel> + <durée>). La particularité de l’attribut tempo-
associés à deux calendriers. La charge de travail déclarée par un rel relatif est qu’il n’a pas de valeur tant que la valeur du repère tem-
employé pour une semaine et un projet donnés est une quantité de porel n’est pas connue. Le repère temporel est un attribut temporel
temps exprimée en heures. Mais la semaine de référence (attribut qui s’exprime lui-même de manière relative ou absolue.
sem) est exprimée avec le calendrier MaSemaine. Ce calendrier défi- Comme l’illustre la figure 10, l’attribut temporel début du projet
nit les granules : année et semaine. Le format de l’estampille est
est un instant absolu exprimé en jours alors que les attributs tempo-
« année/semaine ». Une semaine a une durée normale de 7 jours, rels relatifs fin du projet et dates sont respectivement de type INS-
l’année contient 53 semaines, la 1re semaine de l’année 1997 n’a que TANT et INTERVALLE. Par exemple, le projet DBT a un instant de fin
5 jours et la 53e semaine de 1996 n’a que 2 jours. déterminé par la formule : « début du projet + 6 mois ». C’est un ins-
Exemple : l’instant « 1996/44 » relatif au calendrier MaSemaine tant relatif à un autre attribut temporel début du projet qui est un
est converti dans le calendrier grégorien en l’instant « 28/10/1996 instant absolu. Le projet DBT est décomposé en 2 tâches. Les dates
00:00:00 ». de la première tâche sont déterminées par l’intervalle relatif
suivant : [« début du projet + 7 jours », « début du projet +
Le modèle permet de raisonner en temps absolu ou en temps 2mois7jours ») ; la deuxième tâche se déroule durant l’intervalle
relatif. Cela est réalisé par une spécialisation des domaines tempo- relatif : [« (tâche1()).dates.fin + 7 jours », « (tâche1()).dates.fin +
rels INSTANT et INTERVALLE : 3mois7jours »). Le repère temporel utilisé est la fin de la tâche1, lui-
— INSTANT-A et INTERVALLE-A permettent de représenter les même relatif. La fonction tâche1() correspond à la requête SQL per-
instants ou les intervalles de temps absolu ; mettant d’obtenir l’objet tâche1 du projet DBT à partir de la tâche2.
Classe : Employé
Propriétés
Nom : Chaîne
DateNaissance : INSTANT < grégorien, jour >
relatif à
Employé
Classe : Charge de travail
Propriétés
Charge : Période < grégorien, heure >
Charge de travail
Sem : INSTANT < MaSemaine, semaine >
Relatif à : ref (Employé)
Pour : ref (Projet)
Projet
pour
Classe : Projet
Propriétés
Nom : Chaîne
Dates : INTERVALLE < grégorien, jour >
Figure 9 – Exemples de classes
utilisant plusieurs calendriers
Classe : Projet
Propriétés
Nom du projet : Chaîne
Début projet : INSTANT_ A < grégorien, jour >
relatif à Fin du projet : INSTANT_ R < grégorien, jour >
Tâche Tâches : comp (ensemble (tâche))
Classe : Tâche
Propriétés
Projet
Nom de la tâche : Chaîne
Dates : INTERVALLE-R < grégorien, jour >
Objectif : Chaîne
Descriptif : Chaîne
Figure 10 – Exemples d’attributs

temporels relatifs
3.2.3 Extension temporelle des classes d’objets Par exemple, prenons pour C la classe Stock, o l’identité de l’objet
représentant le stock du produit X423. À l’instant t1, la quantité en
L’objectif de cette extension est de doter le modèle conceptuel du stock de ce produit a la valeur 100 (état D1). Cette valeur peut être
moyen d’estampiller et/ou d’historiser les données si nécessaire. modifiée, soit par la livraison d’une commande client, soit par le
Comme nous l’avons vu dans les prérequis (cf. paragraphe 2.3), les réapprovisionnement du produit par un fournisseur.
deux dimensions temporelles qui sont le temps de validité et le Si l’on considère la séquence suivante d’événements applicables
temps de transaction doivent être prises en compte dans le raison- à l’objet o :
nement de modélisation des données temporelles. Cette extension — l’événement de livraison au temps t3 diminue le stock de 70
conduit à deux types de classes : les classes instantanées et les clas- (état D3) ;
ses temporelles. — l’événement de réapprovisionnement à l’instant t10 augmente
le stock de 150 unités (état D10).
3.2.3.1 Classe instantanée Par conséquent, la fonction r (o)2 retourne D1 et la fonction r (o)4
retourne D3.
Une classe instantanée (cf. objets statiques, paragraphe 2.3) est
une classe dont les objets représentent l’état courant de leurs cor- Le schéma d’une classe instantanée est celui d’une classe comme
respondants réels. En d’autres termes, l’objet informationnel ne nous l’avons décrit dans le paragraphe 3.1. Il comporte la descrip-
garde pas trace de son évolution dans le temps. Il ne conserve que tion des propriétés, des contraintes, des opérations et des événe-
son dernier état. Par conséquent, comme les objets statiques intro- ments internes.
duits dans le paragraphe 2.3, les mises à jour sur ce type d’objet Exemple : la classe personne est décrite dans la figure 11.
entraînent une perte de l’état précédent au profit du nouvel état. Une
classe peut être naturellement « instantanée » si les propriétés sont Temps utilisateur
permanentes (elles n’évoluent pas au cours du temps) ou bien par Une classe instantanée peut avoir des attributs temporels dont la
décision si la représentation des états successifs des objets est sans sémantique dépend de l’application (temps utilisateur). Par exem-
intérêt. ple, la date de naissance de la classe personne est un attribut tem-
porel, la sémantique du temps est gérée par l’application (temps
Exemple : la classe commande est une classe instantanée si les utilisateur). La classe instantanée ne doit pas contenir des attributs
aspects d’une commande sont immuables. temporels ayant une sémantique de temps de validité ou de temps
de transaction.
Cette classe n’est pas sensible au temps. Chaque fois qu’un objet
d’une classe instantanée est modifié ou supprimé, le nouvel état de
l’objet remplace l’ancien état. Rappelons que l’état d’un objet est
l’ensemble des valeurs de ses propriétés et que l’identité d’un objet
est une propriété immuable qui permet de distinguer un objet indé-
pendamment de son état.
classe instantanée personne
propriétés
Étant donné une classe C appartenant à l’ensemble des clas- nom : CHAÎNE
ses instantanées C I, et quel que soit un objet de la classe instan- prénom : CHAÎNE
tanée C (on notera o l’identité de cet objet) : datenaissance : INSTANT-A < grégorien, jour >
adresse : CHAÎNE
la fonction r (o)i retourne l’état de l’objet o obtenu
contraintes
au temps ti , cet état sera noté Di .
datenaissance > « 01/01/1700 »
L’évolution de l’objet o dans le temps se fait parce que l’on opérations
applique, sur cet objet, une séquence d’événements EV0, créer
EV1, ..., EVn (EVi représente l’événement appliqué à l’instant ti ). modifier
Par conséquent, l’exécution de l’événement EV à l’instant ti supprimer
sur l’état de l’objet au même instant produit l’état Di +1 et r (o)k finClasse
retourne Di +1 si l’instant tk > à l’instant ti et tel qu’il n’existe pas
d’événement appliqué sur cet objet entre l’instant ti +1 et l’ins-
tant tk.
Figure 11 – Description de la classe personne
3.2.3.2 Classe temporelle Les propriétés d’une classe temporelle sont associées à une
estampille du temps de validité et/ou à une estampille du temps de
Une classe temporelle est une variante temporelle d’une classe transaction.
instantanée. En d’autres termes, une classe temporelle permet de
conserver l’évolution dans le temps d’un ensemble de propriétés Exemple : le salaire d’un employé est estampillé par la date de vali-
relatives à un objet d’une classe instantanée. Par conséquent, la dité de son salaire.
fonction r permettant d’obtenir l’état d’un objet à partir de son iden-
tité n’est plus suffisante ; pour obtenir un état particulier d’un objet
La classe temporelle permet de grouper des propriétés qui évo-
temporel, il faut mentionner quelle estampille temporelle est inté-
luent en même temps et sont associées à la(aux) même(s) dimen-
ressante.
sion(s) temporelle(s).
Exemple : le salaire et la fonction d’un employé sont dans deux

Définition générale des capacités d’une classe temporelle classes temporelles différentes puisqu’elles n’évoluent pas en même
temps.
Étant donné une variante temporelle T de la classe instanta-
née C et quel que soit un objet a de la classe temporelle T : Une classe temporelle décrit une variante temporelle des objets
l’objet a est une variante temporelle d’un objet instantané o d’une classe instantanée.
et l’identité de a (ida) est égale à l’identité de o.
Si r (ida , tj )i retourne l’état de l’objet a à l’instant tj , si l’instant Exemple : la fonction d’un employé est une variante temporelle de
tj > à l’instant t0 , cet état est noté Di (ti représente le temps de la classe Employé.
requête).
L’évolution de l’objet a dans le temps se fait parce que l’on Dans l’orientation objet, il existe au moins une propriété qui ne
applique, sur cet objet, une séquence d’événements EV0, change jamais : l’identité de l’objet. En outre, une classe instantanée
EV1, ..., EVn (EVi représente l’événement appliqué à l’instant ti ). peut avoir plusieurs variantes temporelles. Le lien d’une classe
temporelle à sa classe instantanée s’appelle « est-une-variante-
Par conséquent, l’exécution de l’événement EV à l’instant ti temporelle ». La figure 12 illustre le fait qu’un employé a trois varia-
sur l’état de l’objet a au même instant produit l’état Di +1 et tions temporelles : son salaire, sa fonction et son statut familial.
r (ida ,ti )k retourne Di +1 si l’instant ti > à l’instant t0.
■ Estampillage versus historisation
Nous intégrons, dans le concept de classe temporelle, la possibi-
Une telle classe inclut une gestion d’estampillage et d’historique lité d’avoir une historisation ou un estampillage du dernier état.
(cf. objets historiques, rétrospectifs et temporels, § 2.3). Toutes les ● La notion d’état estampillé permet d’associer, au dernier état
propriétés d’une classe temporelle évoluent et leur évolution est d’un objet, une estampille temporelle qui est le temps de validité de
intéressante à mémoriser. Comme illustré à la figure 12, la classe cet état dans le monde réel et/ou le temps de mise à jour de cet état
Salaire peut être vue comme une variante temporelle de la classe dans la base de données (temps de transaction). Nous parlons
Employé si l’évolution de la propriété salaire doit être gardée dans d’état valide lorsque l’estampille est le temps de validité, d’état sys-
la base de données. tème lorsque le temps associé est le temps de transaction et enfin
Une classe temporelle est une classe estampillant ou historisant l’état est dit bitemporel lorsque l’estampille comprend les temps de
les états d’objet par rapport à l’une, à l’autre ou aux deux dimen- validité et de transaction. Lorsque la classe temporelle gère le der-
sions temporelles. nier état estampillé, sa définition est la suivante.
ClasseInstantanée Employé
Fonction propriétés
Salaire Nom : Chaîne
Adresse : Chaîne
Employé
finClasse
Statut_familial
ClasseTemporelle Fonction
Variante de Employé
dimensions temporelles Valide
INTERVALLE <grégorien, mois>
Classe Classe propriétés
Est-une-variante-temporelle
instantanée temporelle titre : Chaîne
finClasse
Classe Temporelle Statut_familial Classe Temporelle Salaire
Variante de Employé Variante de Employé

dimensions temporelles Valide INTERVALLE < grégorien, jour > dimensions temporelles Valide INTERVALLE < grégorien, mois >
propriétés propriétés
status : FAMILYSTATUS Montant : REAL
finClasse finClasse
Figure 12 – Exemples de classes temporelles
La classe temporelle est caractérisée par la dimension temporelle

Étant donné une variante temporelle T gérée par estampillage à gérer et les deux options : estampillage ou historisation. Le croise-
de la classe instantanée C et quel que soit un objet a de la classe ment de ces deux caractéristiques permet de connaître toutes les
temporelle T : options possibles de gestion du temps associées à la classe tempo-
l’objet a est une variante temporelle d’un objet instantané o relle. Le tableau 5 synthétise les options possibles.
et l’identité de a(ida) est égale à l’identité de o. ● La fonction d’un employé évolue au cours du temps. Son évo-
Si r (ida)i retourne le dernier état de l’objet a avec l’estampille lution étant pertinente pour l’entreprise, elle est définie comme une
associée tj , cet état est noté Di (ti représente le temps de variante temporelle de la classe instantanée Employé. Les différents
requête). états et les différentes histoires sont illustrés dans le tableau 6. On
L’évolution de l’objet a dans le temps se fait parce que l’on suppose que l’employé Durand était programmeur avant de devenir
applique, sur cet objet, une séquence d’événements EV0 , chef de projet (cf. exemple § 2.3).
EV1, ..., EVn (EVi représente l’événement appliqué à l’instant ti ). L’estampillage permet de garder uniquement la dernière fonction
Par conséquent, l’exécution de l’événement EV à l’instant ti de l’employé Durand avec l’estampille que l’on souhaite exploiter
sur l’état de l’objet a au même instant produit l’état Di +1 avec (temps valide ou/et temps de transaction).
l’estampille ti et r (ida)k retourne Di +1 avec l’estampille associée L’historisation permet de garder les différentes fonctions de
ti si l’instant tk > à l’instant ti et tel qu’il n’existe pas d’événement l’employé Durand avec, pour chaque état, l’estampille que l’on sou-
appliqué sur cet objet entre l’instant ti +1 et l’instant tk . haite exploiter (temps valide ou/et temps de transaction).
L’estampille temporelle associée à l’état peut représenter L’état valide à l’intersection de la colonne estampillage et de la
l’instant où l’événement doit être appliqué dans le monde réel ligne temps de validité permet de connaître depuis quand l’employé
(temps de validité) ou/et l’instant où l’événement est appliqué Durand a la fonction actuelle de chef de projet. Par contre, l’histoire
dans le système d’information (temps de transaction). valide (colonne historisation, ligne temps de validité) est plus inté-
ressante puisqu’elle permet de retracer la carrière de l’employé
● La notion d’histoire permet de garder tous les états estampillés Durand dans l’entreprise.
d’un objet afin de retracer son évolution au cours du temps. L’his- L’état système (colonne estampillage, ligne temps de transaction)
toire valide d’un objet reflète son évolution par rapport au monde permet uniquement de savoir depuis quand l’information est dispo-
réel (temps de validité). L’histoire système d’un objet permet d’avoir nible dans le système d’information. En l’occurrence, le fait que
l’évolution de ses mises à jour (temps de transaction). L’histoire est Durand soit chef de projet a été disponible dans le système d’infor-
dite bitemporelle lorsqu’elle combine le point de vue du monde réel mation le 1er janvier 1996. De même, l’histoire système (colonne his-
et celui de la représentation. Lorsque la classe temporelle gère l’historisation, ligne temps de transaction) permet de retracer quelles
toire de l’objet, sa définition est la suivante. ont été les différentes valeurs de fonction de l’employé Durand dans
le système d’information. Ce journal permet plus généralement de
connaître l’état du système d’information à un instant t du passé.
Étant donné une variante temporelle T gérée par historisation
de la classe instantanée C et quel que soit un objet a de la classe
temporelle T : Tableau 5 – Options possibles dans une classe temporelle
l’objet a est une variante temporelle d’un objet instantané o
et l’identité de a(ida) est égale à l’identité de o. Temps de transaction
Temps
Si r (ida , ti )i retourne l’état de l’objet a à l’instant tj , si l’ins-
de validité
tant tj > à l’instant t0 , cet état est noté Di (ti représente le temps Néant Estampillage Historisation
de requête).
L’évolution de l’objet a dans le temps se fait parce que l’on Néant Sans gestion Dernier état Histoire
du temps système système
applique, sur cet objet, une séquence d’événements EV0 , (classe
EV1, ..., EVn (EVi représente l’événement appliqué à l’instant ti ). instantanée)
Par conséquent, l’exécution de l’événement EV à l’instant ti
sur l’état de l’objet a au même instant produit l’état Di +1 et r (ida , Estampillage Dernier Dernier Histoire
état valide état bitemporel système
ti )k retourne Di +1 si l’instant ti > à l’instant t0. et dernier état
L’estampille temporelle associée à l’état peut représenter valide
l’instant où l’événement doit être appliqué dans le monde réel
Historisation Histoire valide Histoire valide Histoire
(temps de validité) ou/et l’instant où l’événement est appliqué et dernier état bitemporelle
dans le système d’information (temps de transaction). système
Tableau 6 – Contenu informationnel de l’objet Durand selon le type de gestion
État Estampillage (1) Historisation
Temps Chef de projet, VT[20-12-95,forever) Programmeur, VT[12-12-94, 20-12-95)

de validité Chef de projet, VT[20-12-95,forever)
Temps Chef de projet, TT[01-01-96 15:56:50,’now ’) Programmeur, TT[01-01-95 9:20:15, 01-01-96 15:56:50)
de transaction Chef de projet, TT[01-01-96 15:56:50,’now ’)
Temps Chef de projet, VT[20-12-95,forever), Programmeur, VT[12-12-94,forever), TT[01-01-95 9:20:15, 01-01-96 15:56:50)
de validité TT[01-01-96 15:56:50,’now ’) Programmeur, VT[12-12-94, 20-12-95), TT[01-01-96 15:56:50,’now ’)
et de transaction Chef de projet, VT[20-12-95,forever), TT[01-01-96 15:56:50,’now ’)
(1) VT : temps de validité.
TT : temps de transaction.
Tableau 7 – Choix de gestion de la dimension temporelle

Temps de transaction Classe temporelle Salaire mensuel
Temps Variante de Personne
de validité Dimensions temporelles
Néant État Histoire
Valide INTERVALLE < grégorien, mois > histoire
Néant Transaction histoire
Propriétés
État Dernier Fiabilité montant : entier
état valide de l’information Contraintes
sur l’état connu ...
Histoire Fonction Fonction de Fonction Opérations
de mouvement mouvement de rejeu créer/* création du salaire mensuel*/
+ fiabilité modifier/* modification du salaire mensuel*/
de l’information Événements
sur le dernier ...
état connu FinClasse
L’état bitemporel (colonne estampillage, ligne temps de validité et

de transaction) permet de savoir si l’état est connu à l’avance ou en Figure 13 – Spécification d’une classe temporelle
retard. Dans notre exemple, la fonction de Durand est connue dans
le système d’information avec un retard d’une dizaine de jours, par
conséquent, un rattrapage de salaire a dû être fait pour décembre figure 14. Par exemple, une voiture est possédée par une personne
1996. L’histoire bitemporelle (colonne historisation, ligne temps de et le possesseur peut changer durant la vie de la voiture. L’adminis-
validité et de transaction) permet de retracer aussi bien la carrière de tration veut noter les différents propriétaires du véhicule, en men-
l’employé que l’histoire contenue dans le système d’information. À tionnant, à chaque fois, le montant d’achat et le kilométrage. Par
chaque état de cette histoire, nous pouvons évaluer le délai de mise conséquent, la classe Propriétaire est une variante temporelle de la
à jour du système d’information par rapport au monde réel et classe instantanée Voiture ; donc les propriétés à historiser sont la
rejouer les processus de l’entreprise basés sur ces données. référence sur la personne propriétaire, le montant d’achat et le kilo-
métrage lors de l’achat (cf. la description textuelle figure 15).
■ Choix de gestion de la variante temporelle
Le travail du concepteur consiste à définir les caractéristiques de ■ Cas des liens statiques entre classes
chaque dimension temporelle à gérer en fonction des besoins. Les liens statiques définis entre les classes d’objets sont les liens
de référence, de composition et d’héritage.
La position géographique d’une unité « ennemie » dans un
● Lien de composition
système d’information militaire est modélisée par une classe tem-
porelle de la classe instantanée « unité ennemie ». Selon les carac- La composition permet de définir des objets complexes. La
téristiques choisies, les fonctionnalités supportées sont différentes. commande, par exemple, est composée de lignes de commande
Extrapoler le mouvement de l’unité est une fonction qui ne peut se (cf. figure 16). La sémantique de la composition présente dans le
faire que sur une histoire valide ; l’état bitemporel permet de raison- modèle conceptuel est stricte et les règles méthodologiques expo-
ner sur la fiabilité de l’information stockée. Par ailleurs, l’histoire sées dans [12] imposent qu’un objet composant soit lié de manière
bitemporelle permet la fonction de rejeu d’une guerre (tableau 7). permanente (sans variation temporelle) à un objet composé. Il n’y a
donc pas de variation temporelle du lien de composition.
■ Spécification d’une classe temporelle ● Lien de référence
La spécification d’une classe temporelle (figure 13) est semblable Au contraire, un lien de référence est un lien temporaire qui peut
à celle d’une classe instantanée puisqu’elle contient les parties pro- évoluer au cours du temps. Il y a donc lieu ici de considérer les varia-
priétés, contraintes, opérations et événements. Pour une classe tem- tions temporelles du lien.
porelle, on ajoute la description de deux caractéristiques :
Exemple : une voiture est possédée par une personne à un
— la classe instantanée dont la classe temporelle est issue. Elle instant t. La référence est vue comme une propriété de la classe Voi-
est introduite par le mot clé variante de ; ture et un lien inverse est géré dans la classe Personne.
— la définition des dimensions temporelles nécessaires est
annoncée par le mot clé dimensions temporelles. La définition La description textuelle de la référence se fait comme sur la
comporte le type de gestion (estampille et histoire) pour chaque figure 17.
dimension temporelle et le domaine temporel de l’estampille (pour Dans cet exemple, si l’application est intéressée à l’historique des
le temps de validité). propriétaires pour une voiture, la propriété propriétaire devient une
variation temporelle de la classe Voiture (cf. figure 17 et figure 18a).
■ Une classe instantanée peut être spécialisée par variantes
Par ailleurs, si l’application est intéressée à l’historique des posses-
temporelles
sions de voiture pour une personne, la propriété possède devient
La figure 14 illustre la spécialisation possible de deux classes ins- une variante temporelle de la classe Personne (figure 18b). Enfin, si
tantanées. La classe Employé possède deux propriétés, fonction et l’application nécessite l’historique à partir des deux classes Per-
salaire mensuel qui peuvent représenter des variantes temporelles sonne et Voiture, chacune des classes a sa variante temporelle
d’un employé puisque leurs évolutions sont pertinentes à garder. comme l’illustre la figure 18c.
Ces deux propriétés forment deux variantes temporelles différentes La référence entre une classe instantanée et une classe tempo-
car elles n’évoluent pas en même temps. De plus, l’entreprise est relle exprime un lien entre objets. L’objet temporel contient l’évolu-
intéressée à connaître le dernier statut familial de ses employés tion de sa référence ou de sa référence inverse. Considérons le cas
avec leur temps de validité. Par conséquent, le statut familial appa- de la figure 18a, la référence entre la classe instantanée personne et
raît comme une variante temporelle de Personne avec l’estam- la classe temporelle propriétaire exprime le fait qu’une personne
pillage comme option. possède plusieurs voitures et qu’une voiture n’est possédée que par
Il faut noter qu’une classe temporelle n’est pas restreinte à une une seule personne à un instant t ; mais une voiture est décrite par
seule propriété comme pourrait le laisser supposer l’exemple de la l’ensemble des propriétaires qu’elle a eu au cours du temps.
Personne employé
nom : Chaîne numéro : entier
anniversaire : INSTANT < grégorien, jour > Est un numéro SS : Chaîne
téléphone : Chaîne salaire mensuel : réel
adresse : ADRESSE fonction : Chaîne
status familial : STATUT FAMILIAL
Rattaché à
département
Personne
propriétés Est une variante temporelle

nom : Chaîne statut familial
anniversaire : INSTANT < grégorien, jour >
téléphone : Chaîne propriétés
adresse : ADRESSE status familial : STATUT FAMILIAL
etat < VT >
Employé Est une fonction

variante
tempore
lle
propriétés Es propriétés
tu
numéro : entier ne fonction : Chaîne
va
numéro SS : Chaîne ria
nte
tem Histoire < VT >
po
rel
le
Est une variante temporelle salaire mensuel
propriétés
rattachement salaire mensuel : réel
propriétés Histoire < VT, TT >
Histoire < VT >

département
Figure 14 – Exemple de décomposition d’une classe en variantes temporelles
ClasseInstantanée Voiture Classe Temporelle Propriétaire

propriétés Variante de Voiture
numéroIdent : Chaîne Dimensions temporelles Valide INTERVALLE < grégorien, jour >
type : Modèle histoire
marque : Chaîne propriétés
finClasse possédée par : ref (Personne)
Montant Achat : réel
kilométrage : réel
finClasse
Figure 15 – Exemple de variante temporelle avec plus d’une propriété
Commande Ligne de commande
Classe Instantanée Commande Classe Instantanée Ligne de commande

possède : comp (ensemble (Ligne de commande)) ...
... finClasse
finClasse
La composition est décrite dans la classe Commande
Figure 16 – Exemple de lien de composition
possède
Voiture Personne
Classe Instantanée Voiture Classe Instantanée Personne

propriétaire : ref (Personne), ref inverse (Personne : :possède) possède : ref inverse (ensemble, Voiture : :propriétaire)
... ...
finClasse finClasse
La référence est décrite dans la classe Voiture et la référence inverse La propriété possède est la référence inverse
est matérialisée par la propriété possède de la classe personne. de la propriété propriétaire de la classe Voiture
Figure 17 – Exemple de lien de référence
● Lien d’héritage
L’héritage ne s’applique que sur les classes instantanées.
Exemple : un employé hérite d’une personne. La classe Employé
Voiture
hérite de toutes les propriétés statiques et dynamiques de la classe
a Personne et tout particulièrement des variantes temporelles de la
classe Personne. Mais l’héritage ne s’applique pas directement sur les
propriétaire Personne classes temporelles.
3.2.3.3 Impact sur la définition des événements internes

Les événements internes sont constatés lorsqu’un changement
Personne d’état particulier d’objet survient.
b Exemple : la rupture de stock est constatée lorsque la quantité en
stock devient inférieure au seuil de réapprovisionnement.
Voiture possessionVoiture
Le modèle incluant des objets « à histoire », nous pouvons éten-
dre la notion d’événement interne à la constatation d’un change-
ment d’état remarquable de l’histoire d’un objet temporel.
On distingue donc les événements sur état des événements sur
Voiture Personne
histoire. Un événement sur état se constate sur le changement du
c dernier état d’un objet alors que l’événement sur histoire est basé
sur l’état de l’histoire. L’exemple illustré sur la figure 19 montre que
propriétaire possessionVoiture la rupture de stock est un événement interne sur état ; alors que
l’événement « AnomalieStock » détecté « lorsque la quantité est
devenue inférieure à 20 plus de trois fois en une semaine » est un
Figure 18 – Introduction du temps dans un lien de référence événement sur histoire.
Classe Stock
Variante de Produit
Dimensions temporelles Valide INSTANT < grégorien, jour > Histoire
Propriétés
quantité-en-stock : entier
Contraintes
quantité-en-stock > = 0
Opérations
créer (quantité : réel)
sortir (quantité : réel)
entrer (quantité : réel)
Événements
Rupture-de-stock sur état
predicat « quantité en stock < seuil de réapprovisionnement »
...
Anomalie-stock sur histoire
predicat « quantité inférieure à 20 plus de trois fois en une semaine »
...
FinClasse
Figure 19 – Exemple de la classe Stock
Les événements sur l’état d’un objet sont applicables sur toutes À un instant t donné, combien de clients sont associés à une
les classes. Par contre, les événements sur l’histoire ne sont définis commande ? Un et un seul client. La contrainte de cardinalité instan-
que sur les classes temporelles gérant une historisation. tanée n’exprime pas ici que, durant la vie de la commande, le client
associé ne peut pas changer. L’aspect permanent ou variable de
l’association n’est pas traité dans la cardinalité.
3.2.4 Extension aux contraintes temporelles Exemple : une voiture est possédée à un instant t par une seule
personne, n’empêche pas d’avoir plusieurs propriétaires différents
Les contraintes d’intégrité associées à une base de données sont durant la vie de la voiture.
le plus souvent statiques, c’est-à-dire relatives au dernier état des
données de la base. La gestion temporelle des données implique ● Une contrainte d’héritage s’exprime entre une classe générali-
une prise en compte du temps dans l’expression des contraintes. sée et un ensemble de classes spécialisées. Les contraintes sont les
contraintes de disjonction, de couverture et de partition. Les classes
Exemple : on peut être amené à dire « qu’un examinateur est Homme et Femme sont des spécialisations disjointes de la classe
affecté à un projet s’il n’a jamais été (ou n’est pas) employé par l’une Personne ; car une personne ne peut pas être à la fois un homme et
des entreprises participant au consortium du projet ». une femme. De plus les classes Homme et Femme couvrent la
Dans les classes d’objets, nous décrivons les contraintes que doi- classe Personne ; car une personne est obligatoirement une femme
vent vérifier les objets de cette classe (cf. paragraphe 3.1 et [12]). Les ou un homme. Enfin si les classes spécialisées combinent la
contraintes sont principalement des contraintes : contrainte de disjonction et la contrainte de couverture, elles consti-
tuent une partition. Par conséquent, les classes Homme et Femme
— d’unicité ; forment une partition de la classe Personne.
— de cardinalité ;
● Une contrainte d’attribut est une contrainte qui s’applique sur
— d’héritage ;
une propriété statique d’un objet (cf. § 4.1).
— d’attribut.
Les contraintes d’unicité, d’héritage et d’attribut sont explicite- Exemple : le poids du patient ne peut pas excéder 200 kilos ou la
ment définies par le concepteur, alors que les contraintes de cardi- date de naissance du patient ne peut pas être antérieure à 1800 sont
nalité sont incluses dans les liens statiques. des exemples de contraintes d’attribut.
Nous allons d’abord rapidement rappeler la signification de cha- ■ Choix de classification des contraintes
cune de ces contraintes et les définir dans un contexte temporel. On propose une classification des contraintes qui combine les
■ Rappel sur les définition des contraintes types classiques et ceux relatifs au temps. Cette classification est
utile pour déterminer l’impact d’une contrainte :
● Une contrainte d’unicité garantit l’unicité des objets d’une
classe à partir de l’unicité des valeurs d’une propriété ou d’un — locale à un objet ou globale pour un ensemble d’objets ;
ensemble de propriétés de la classe. Elle correspond à la contrainte — à un instant t ou pour un ensemble d’états à des instants t dif-
de clé du relationnel. férents.
● Dans les SGBD actifs orientés objets comme ODE [16], les
Exemple : le numéro de sécurité sociale (numss) d’une personne
contraintes sont classées en deux catégories : les contraintes intra-
est unique dans l’ensemble des personnes (Personne) : unique
objet et les contraintes interobjet.
(numss, Personne).
Une contrainte intraobjet permet de définir l’intégrité localement
● Une contrainte de cardinalité est définie dans chaque classe à un objet par opposition à une contrainte interobjet qui détermine
participant à une association ou à une agrégation. l’intégrité globalement à un ensemble d’objets.
Exemple : une commande n’est passée que par un seul client. La L’application de cette classification aux cinq contraintes précéden-
contrainte exprime une cardinalité instantanée. tes conduit au résultat du tableau 8.
La classification proposée combine ces deux modes de typage.

Tableau 8 – Classification des contraintes usuelles
■ Classification des contraintes de l’extension temporelle
Contraintes Intraobjet Interobjet ● La contrainte de cardinalité s’applique aux références et aux
Unicité X compositions. Quel que soit le type de classe participant à la réfé-

rence, la sémantique de la cardinalité ne change pas ; elle est consi-
Cardinalité X dérée comme instantanée, le temps à considérer ici est le temps de
Héritage X validité.
● La contrainte d’unicité s’applique aux classes instantanées et
Attribut X (1) X (2) aux classes temporelles.
(1) Contraintes d’attribut n’accédant à aucun autre objet dans sa définition.
La contrainte d’unicité non temporelle se définit sur une collec-
Exemple, le poids du patient ne peut pas excéder 200 kilos.
(2) Contraintes d’attribut accédant à d’autres objets dans sa définition. tion non temporelle.
Exemple, la date de visite ne doit pas excéder d’un mois la visite précé- Exemple : le numéro de sécurité sociale doit être unique dans
dente. l’ensemble des personnes.
La contrainte d’unicité temporelle locale (intraobjet) s’applique à
● La deuxième classification est inspirée de celle proposée par une collection temporelle d’une même classe.
Böhlen dans « Classifications of temporal constraints » ; elle distin- Exemple : le propriétaire d’une voiture est unique dans l’historique
gue les contraintes intratemps et intertemps. des propriétaires de toutes les voitures (une personne ne peut pas pos-
Une contrainte intratemps se définit localement à un instant t. séder la même voiture plusieurs fois).
Chaque instant t doit vérifier la contrainte. La sémantique est diffé-
rente selon la dimension temporelle utilisée dans la contrainte : La contrainte d’unicité temporelle globale (interobjet) s’applique
à une collection temporelle intégrant plusieurs classes.
— une contrainte intratemps associée au temps de validité
s’applique à l’état du monde réel à un instant t ; Exemple : le propriétaire d’une voiture est unique à un instant t
dans l’historique des propriétaires de toutes les voitures (à un instant t
Exemple : l’affectation d’un employé à un projet doit exister pour la une personne ne possède qu’une voiture).
semaine de la charge hebdomadaire déclarée par cet employé pour ce
projet. ● Les contraintes d’héritage ne changent pas ; elles sont intem-
porelles.
— une contrainte intratemps associée au temps de transaction
● Les contraintes de propriété s’appliquent sur des classes ins-
s’applique à l’état de la base de données à un instant t ;
tantanées et des classes temporelles. La catégorie de la contrainte
Exemple : si le nom d’une société est stocké dans une his- dépend des objets participant à sa définition. Le tableau 9 donne un
toire<TT>, l’unicité du nom pour chaque état de la base de données est exemple de chacune des catégories.
vérifié aux temps de transaction.
Cette classification des contraintes selon les deux canevas intra/
— une contrainte intratemps associée à une estampille bitempo- inter objet/temps est utile pour la compréhension des contraintes
relle s’applique à l’état du monde réel à un instant v stocké dans que l’on formule mais aussi pour la phase logique où les contraintes
l’état de la base de données à un instant t. devront être traduites dans le langage spécifique d’un SGBD tempo-
rel et orienté objet.
Exemple : si le poids du patient est dans une histoire<VT,TT>, la
● Spécification d’une classe avec contraintes
contrainte « le poids ne doit pas excéder 200 kilos » doit se vérifier
pour chaque couple <VT,TT>. Prenons l’exemple d’une gestion de projet où les efforts travaillés
par un employé pour une semaine et un projet sont renseignés par
Une contrainte intertemps se définit en utilisant des informations l’employé dans la classe temporelle AffectationHebdomadaire, alors
à des temps différents. Chaque instant t doit vérifier la contrainte. La que l’effort travaillé dans sa globalité pour un projet et une semaine
sémantique change selon la dimension temporelle : est déclaré par le chef de projet dans la classe temporelle EffortRéa-
— une contrainte intertemps associée au temps de validité définit lisé. L’effort réalisé par un employé ne peut pas excéder 40 heures et
l’intégrité pour un ensemble d’états du monde réel ; l’effort hebdomadaire déclaré par le chef de projet doit être égal à la
somme des efforts réalisés par l’ensemble des employés affectés à
Exemple : une personne ne peut pas être embauchée plusieurs
ce projet pour cette semaine. Une contrainte est décrite par le texte
fois par la même compagnie nécessite le parcours de la variation tem-
annoncé par le mot clé assertion et sa catégorie par rapport aux
porelle « employé » d’une personne.
classifications (intra/inter objet/temps) (figure 20).
— une contrainte intertemps associée au temps de transaction
définit l’intégrité pour un ensemble d’états de la base de données ;
Exemple : si le nom d’une personne est stocké dans une his- 3.3 Extension de la démarche
toire<TT>, la contrainte « une personne ne peut pas changer de nom conceptuelle
plus de trois fois » requiert l’accès à plusieurs temps de transaction.
— une contrainte intertemps associée à une estampille bitempo- Ce paragraphe a pour but de présenter comment s’insère l’ana-
relle s’applique à plusieurs états bitemporels. lyse des aspects temporels dans le processus de modélisation asso-
cié au modèle orienté objet qui nous sert de référence. Nous
Exemple : si le poids du patient est dans une histoire<Bi>, la rappelons qu’une démarche conceptuelle propose un ensemble de
contrainte « le poids à un instant de validité donné ne doit pas être cor- règles méthodologiques pour aider le concepteur à la satisfaction
rigé plus de 3 fois » utilise plusieurs états ayant une estampille bitem- des objectifs suivants :
porelle.
— la prise en compte aussi exhaustive que possible des phéno-
Les contraintes intratemps sont faciles à vérifier puisqu’elles mènes pertinents du domaine d’application ;
s’appliquent à l’état du monde réel ou l’état courant de la représen- — la modélisation de ces phénomènes au moyen des concepts
tation que l’utilisateur vient de modifier. Par contre, les contraintes du modèle, en tenant compte de l’objectif global assigné à l’applica-
intertemps sont plus difficiles à vérifier car elles nécessitent un tion ;
accès à tous les états du monde réel que l’on connaît. — la validation et la vérification du schéma conceptuel.
Classe temporelle EffortRéalisé Classe temporelle affectationhebdomadaire

Variante de Projet Variante de Employé
Dimensions temporelles Valide INTERVALLE < grégorien, semaine > Dimensions temporelles Valide INTERVALLE < grégorien, semaine >
Propriétés Propriétés
quantité : entier quantité : entier
Contraintes assertion (quantité est égale à la somme des pour : ref (projet)
quantités déclarées dans affectationhebdomadaire pour ce Contraintes
projet et cette semaine), inter-objet, intra-temps Opérations assertion (quantité < 40 heures), intra-objet, intra-temps
créer Opérations
... créer
FinClasse ...
FinClasse
Figure 20 – Spécification d’une classe avec contraintes
Tableau 9 – Exemples de contraintes de propriétés

Contrainte Intraobjet Interobjet
Sans temps La date de naissance d’une personne est postérieure à La date de visite 2 < la date de visite 1 + 1,5 mois.
l’année 1800.
Intra-VT Pour chaque état du monde réel, l’effort déclaré par un L’effort déclaré par un employé pour une semaine doit être
employé pour un projet et pour une semaine ne peut excé- égal à la somme des efforts qu’il a déclaré par projet pour
der 60 heures. cette même semaine.
Intra-TT Pour chaque état base de données, le poids d’un patient Pour chaque état base de données, l’affectation d’un
(classe temporelle avec Histoire<TT>) est inférieur à employé a un projet est possible s’ils appartiennent au
200 kilos. même département.
Intra-Bi Pour chaque état de la classe temporelle effort Projet (his- Pour chaque état de la classe temporelle, effortTotal (His-
toire<VT,TT>), l’effort déclaré par un employé pour un pro- toire<VT, TT>), l’attribut effort total déclaré par un employé
jet et une semaine doit être inférieur à 60. pour une semaine doit être égal à la somme des efforts
déclarés par projet pour la même semaine.
Inter-VT Le salaire d’un employé (classe temporelle avec une His- Le salaire d’un employé (classe temporelle avec une His-
toire<VT>) ne peut pas varier plus de 3 fois dans la même toire<VT>) ne peut pas avoir une augmentation supérieure
année. à la limite fixée par département pour la même période.
Inter-Bi Le poids d’un patient (classe temporelle avec une His- Un examinateur est affecté à un projet (classe temporelle
toire<VT, TT>) pour un temps de validité donné ne peut pas avec une histoire<VT,TT>) s’il n’a jamais été (ou n’est pas)
être corrigé plus de trois fois. employé par l’une des entreprises participant au consor-
tium du projet.
Le modèle en fontaine (figure 21) est utilisé pour visualiser le pro- ● Les acteurs sont des artefacts concrets de l’organisation intera-
cessus de modélisation comme étant itératif, et le recouvrement des gissant avec le système d’information à développer. Le client, le res-
étapes permet d’illustrer qu’une activité peut, selon les cas, être ponsable des locations, le mécanicien et le manager sont des
menée dans une étape ou dans une autre. La démarche se compose exemples d’acteurs interagissant sur le système de location d’une
de six étapes qui sont [12] : voiture.
— étape 1 : inventaire des objets du domaine ; ● Les événements survenant dans l’organisation vont être des
— étape 2 : description initiale des objets ; phénomènes pertinents que l’on va vouloir prendre en compte dans
— étape 3 : étude locale des classes ; l’application base de données. L’arrivée d’une demande de location,
— étape 4 : étude globale des aspects statiques ; la restitution du véhicule sont des exemples d’événements qu’il va
— étape 5 : étude globale des aspects dynamiques ; falloir prendre en compte dans le système de location de voitures.
— étape 6 : validation et vérification. ● Pour la prise en compte des aspects temporels de l’application,
■ L’étape 1 consiste à inventorier les objets pertinents du domaine. nous inventorions les calendriers spécifiques de l’organisation. Les
Les phénomènes retenus sont : les entités, les acteurs, les événe- calendriers permettent de décrire les différents rythmes temporels
ments et les calendriers. Les calendriers ont été ajoutés pour la prise que l’organisation utilise pour synchroniser les activités de ces
en compte le plus tôt possible des rythmes temporels qui seraient acteurs. Le calendrier universitaire, le calendrier grégorien, le calen-
spécifiques à l’organisation considérée. drier comptable sont des exemples de calendriers.
● Les entités représentent des artefacts concrets ou abstraits. Les ■ L’étape 2 a pour objectif l’étude des caractéristiques des objets
premiers ont une existence physique propre comme une voiture qui ont été recensés lors de l’étape 1. Cette étape est informelle et
dans un système de location de voitures. Par opposition, les entités consiste, pour le concepteur, à acquérir des informations supplé-
abstraites n’ont pas d’existence physique comme l’abonnement mentaires auprès des spécialistes du domaine d’application pour
d’une personne à une société de location de voitures. procéder :
La recherche des liens de composition et de référence entre clas-

ses permet de compléter la description statique des classes. L’évolu-
tion des liens de référence dans le temps doit être étudiée afin de
6 déterminer s’ils doivent être décrits comme une variante temporelle
ou pas.
Validation
et ■ L’étape 5 consiste en une étude globale des aspects dynamiques.
vérification
L’objectif de cette étape est de compléter la définition des classes
grâce à une vue globale de la dynamique permettant de décrire les
interactions entre les classes au moyen d’événements. Durant cette
étape, on identifiera plus précisément les événements externes, les
événements internes et les événements temporels.
4 5
Le temps peut aider à affiner le raisonnement du concepteur. Par
Étude globale Étude globale exemple, si l’on considère que l’événement externe permet de four-
des aspects 3 des aspects nir une information au système d’information, le concepteur pourra
statiques dynamiques se poser la question : est-ce que l’information de l’événement
Structure Étude locale Comportement externe est fournie par l’acteur à temps, en avance ou en retard ?
des classes
Ce raisonnement permettra peut-être de faire émerger de nou-
veaux besoins de traitements selon le temps de validité du message
2 de l’événement externe.
L’introduction d’objets temporels avec histoire dans la description
Description du système d’information permet d’identifier de nouveaux événe-
initiale des ments : les événements sur histoire permettant de déclencher un
objets traitement particulier selon le changement d’état de l’histoire d’un
objet temporel.
1 Exemple : « lorsque la quantité est devenue inférieure à 20 plus de
trois fois en une semaine » est un événement sur histoire.
Inventaire Enfin, les événements temporels doivent être classés selon qu’ils
des objets du sont absolus, relatifs au temps d’occurrence d’un événement, rela-
monde réel tifs à un attribut temporel stocké dans un objet ou périodique. Ils
sont en général rattachés à une classe de calendrier. Cette analyse
peut faire émerger un nouveau calendrier qui n’avait pas été identi-
fié dans les étapes précédentes. À la fin de cette étape, les classes
Figure 21 – Modèle en fontaine d’objets, d’acteurs et de calendriers sont décrites en termes de
structure (par des propriétés, des liens entre classes et des contrain-
tes) et en termes de comportement (par des opérations et des évé-
— à la description des objets du domaine ; nements).
— au choix des caractéristiques qui seront retenues dans le
schéma conceptuel ; ■ L’étape 6 est composée d’une activité de vérification et d’une acti-
— au recensement, parmi ces entités, de celles dont l’évolution vité de validation.
serait importante à conserver, par rapport aux objectifs assignés à la ● L’activité de vérification consiste à s’assurer que le schéma
base de données. conceptuel est correctement défini en effectuant un ensemble de
■ L’étape 3, comme les suivantes, a pour but de représenter la contrôles de conformité, de cohérence et de complétude par rapport
connaissance obtenue dans les étapes précédentes avec le forma- au modèle conceptuel. L’extension temporelle du modèle concep-
lisme du modèle conceptuel. Elle décrit principalement localement tuel implique l’énoncé de nouveaux contrôles de conformité comme
les classes de phénomènes (classe d’objets, classe d’acteurs et « une classe temporelle n’est la variante temporelle que d’une seule
classe de calendrier). Pour chacune de ces classes, le concepteur classe instantanée », « il ne peut pas y avoir de liens de composition
s’attachera à décrire ses aspects statiques et ses aspects dynami- dans une classe temporelle », « le lien d’héritage ne s’applique pas
ques. Les aspects statiques locaux à une classe sont décrits en ter- pour les classes temporelles ». De plus la cohérence temporelle de
mes de propriétés et de contraintes, alors que les aspects la base de données doit être respectée.
comportementaux locaux à une classe se décrivent en termes Exemple : « si une classe temporelle a comme propriété une réfé-
d’opérations et d’événements. Une analyse plus spécifique de l’évo- rence vers une classe instantanée (cf. figure 15), cela implique que
lution dans le temps des propriétés d’une classe permettra de recen- tous les objets référencés dans cet historique doivent exister ».
ser et de décrire toutes les variantes temporelles (classes
temporelles) qu’il serait nécessaire d’introduire à partir d’une classe En d’autres termes, la durée de vie de l’objet référencé (instan-
dite instantanée. À l’introduction d’une variante temporelle, il faut tané) dans la base de données temporelles n’est pas limitée à sa
décrire la gestion du temps nécessaire, revoir les contraintes par durée de vie dans le monde réel, mais peut être déterminée par rap-
rapport aux dimensions temporelles, identifier de nouvelles opéra- port à l’utilisation de cet objet dans un historique.
tions de manipulation de ces données temporelles.
● L’activité de validation vise à vérifier que le schéma satisfait les
■ L’étape 4 permet de réorganiser l’ensemble des classes d’objets besoins énoncés par les utilisateurs. Il faut s’assurer que la structure
d’un point de vue statique, par les liens de composition, de réfé- et la dynamique décrites dans le schéma conceptuel sont en adé-
rence et d’héritage. Cette étape permet, par les mécanismes de quation avec les besoins utilisateurs. Cette validation peut être sup-
généralisation et de spécialisation, de découvrir de nouvelles clas- portée par des outils de simulation ou de prototypage. Pour une
ses. Cette réorganisation peut impliquer l’introduction ou la réor- application centrée sur une base de données temporelles, il faudra
ganisation de variantes temporelles de classes existantes ou en plus valider, auprès des utilisateurs, l’adéquation des données
nouvellement identifiées. temporelles par rapport à leurs besoins informationnels.
4. Extension temporelle
du niveau logique ODL n'existe pas
dans le SGBD O2
ODL C++ binding OQL
ODM
Moteur du SGBDOO
L’étape logique permet de compléter le schéma conceptuel, par la
prise en compte des aspects techniques et opérationnels de la ges-
tion et de l’utilisation des données.
C++ binding est un exemple d'interface
Le concepteur doit s’attacher à définir comment les classes
de programmation proposé par ODMG
d’objets vont s’organiser pour répondre aux demandes de rensei-
gnements des différents utilisateurs de la future base de données.
En d’autres termes, le concepteur est amené à décrire le modèle de
Figure 22 – Architecture d’un SGBDOO telle que la propose ODMG
données du SGBD qui a été retenu pour gérer la base de données.
C’est ici que le concepteur doit optimiser la structure conceptuelle
par rapport aux critères de performances (temps de réponse des
requêtes, temps des mises à jour, occupation physique...) et d’utili- tés objet. Ce standard se compose d’un modèle objet (ODM), d’un
sations. langage de définition (ODL) et d’un langage de requêtes (OQL).
L’architecture d’un SGBDOO telle que le propose ODMG est décrite
De plus, le concepteur est amené, à partir des classes d’acteurs et
figure 22.
du graphe global de la dynamique, à définir l’interface utilisateur et
l’ensemble cohérent de transactions garantissant que les données Nous ne détaillerons pas le modèle objet (ODM), mais nous pren-
seront créées, mises à jour et détruites de manière cohérente. Cette drons les principales notions : classe, attribut, relation (rela-
activité amène le concepteur à faire des choix sur la réalisation de tionships) et littéral. Employé est une classe qui se décrit à l’aide des
l’interface utilisateur (par exemple, avoir une interface par classe attributs salaire et fonction et une relation avec son département de
d’acteurs ou avoir une interface généralisée valable pour toutes les rattachement (object department). Le salaire est un attribut ayant,
classes d’acteurs...) et sur la réalisation de la dynamique de l’appli- comme domaine de valeurs, les réels. Les réels, les chaînes de
cation. Il doit notamment regrouper de manière optimale les événe- caractères sont des exemples de littéraux.
ments conceptuels dans des transactions. Si l’on considère le schéma sans les aspects temporels de la
Enfin, le concepteur doit, à partir des classes de calendriers, éta- figure 14, il se décrit en ODL comme sur la figure 23.
blir la liste des calendriers nécessaires à l’application temporelle et Si l’on veut connaître les employés du département « Avant
déterminer comment seront traités les événements temporels, par ventes » qui sont célibataires avec un salaire supérieur à 40 000 F, on
des transactions bases de données déclenchées manuellement par déclenche la requête OQL suivante :
un acteur ou déclenchées automatiquement par le système d’alerte
temporel d’une machine ou d’un SGBD.
select tuple (NuméroEmployé : y->numéro, NomEmployé :
La spécification résultant de l’étape logique s’appelle un schéma y->nom)
logique. Il est composé de : from y IN employés
— la structure des données temporelles ; where y. rattachéà.nomdépartement = « Avant Ventes » and
— la liste des calendriers ; y.salaire > 40000 frs and
— la liste des transactions de mise à jour de données ; y.statut = « célibataire ».
— l’interface utilisateur.
Cette démarche est valable dans tous les cas de SGBD, mais le Le code associé aux opérations est décrit avec un langage de pro-
contenu du schéma logique varie selon le SGBD cible choisi, qu’il grammation orienté objet supporté par le SGBDOO. ODMG définit
soit temporel ou pas. Si le SGBD est temporel, les données tempo- comme interface de programmation : C++, Smalltalk et bientôt Java.
relles seront facilement réalisées grâce aux concepts temporels du O2 a défini deux interfaces de programmation : C++ binding et
SGBD. Par contre, dans le cas d’un SGBD conventionnel, il faudra Smalltalk binding.
gérer les mises à jour et les consultations de données historiques au L’extension temporelle du SGBDOO O2 appelée TOOBIS s’effec-
niveau de l’applicatif. tue dans le cadre du projet européen TOOBIS. L’objectif est double :
De même, si le SGBD est relationnel ou orienté objet, le modèle étendre les travaux proposés par ODMG (modèle objet, langage de
de données sera différent. Dans le premier cas, le modèle de don- définition et langage de requête) aux concepts temporels et réaliser
nées ne décrira que la structure des données en termes de n-uplets, cette extension pour le SGBD O2 (figure 24).
tandis que, dans le second cas, il est décrit par une structure d’objets Si l’on considère le modèle TODM [7], conçu et réalisé par Matra
qui encapsule les opérations nécessaires à leur manipulation. Systèmes et Information, il définit :
Dans la suite, nous expliquerons la démarche à suivre pour la — les calendriers (tels qu’ils sont décrits dans le paragraphe
construction du schéma logique adapté à un SGBD temporel et 3.2.1) ;
orienté objet TOOBIS [17] qui est une extension temporelle de O2. — les domaines temporels (tels qu’ils sont décrits dans le para-
Les principales caractéristiques de ce SGBD sont présentées dans le graphe 3.2.2) comme de nouveaux littéraux ;
paragraphe 4.1. Les règles de passage du schéma conceptuel au — les classes statiques, rétrospectives, historiques et temporel-
schéma logique TOOBIS sont développées dans le paragraphe 4.2. les comme de nouveaux types de classe ;
• une classe statique correspond à une classe instantanée dans
le modèle conceptuel (cf. § 3.2.3.1) ;
• une classe est dite rétrospective lorsqu’elle gère un historique
4.1 SGBD temporel et orienté objet : basé sur le temps de transaction. Elle correspond, dans le modèle
extension temporelle du SGBD O2 conceptuel, à une classe temporelle gérant une historisation avec
le temps de transaction ;
• une classe est dite historique lorsqu’elle gère un historique sur
Le groupe de travail ODMG (Object Database Management le temps de validité. Elle correspond, dans le modèle conceptuel,
Group), sous-groupe de OMG (Object Management Group) à l’instar à une classe temporelle gérant l’historisation avec le temps de
du groupe de travail SQL, définit un standard pour les SGBD orien- validité ;
interface Personne interface Employé : Personne

(extent personnes) (extent employés key numéro)
{ attribute Date Anniversaire ; {
attribute String nom ; attribute Integer numéro ;
attribute String téléphone ; attribute String fonction ;
attribute Adresse adresse ; attribute Float salaire ;
attribute StatutFamilial statut ; relationship Département rattaché à ;
// opérations // opérations
} }
Le mot clé extent permet de mentionner le nom de la collection L'héritage entre la classe Personne et la classe Employé
contenant les objets persistants. est introduit par le sigle : après le nom de la classe à définir.
Le mot clé attribute intoduit un attribut. Adresse est un domaine Le mot clé relationship introduit une relation entre classes.
structuré et statutFamilial est un domaine énuméré. Dans notre exemple, Département représente une classe.
Figure 23 – Exemple de classes définies avec ODL
Extension temporelle TODL C++ binding TOQL Extension temporellle

de ODL de OQL
TODM
Extension temporelle Moteur du SGBDOO O2
de ODM
Figure 24 – Extension temporelle
du SGBDOO O2 proposé par TOOBIS
• une classe est dite temporelle lorsqu’elle gère un historique — la liste des transactions de mise à jour de données : les tran-
sur le temps de validité et le temps de transaction. Elle corres- sactions sont décrites en C++. Elles doivent contenir des appels aux
pond, dans le modèle conceptuel, à une classe temporelle gérant opérations des classes persistantes et effectuer des requêtes TOQL
l’historisation avec le temps de validité et le temps de afin de manipuler les données temporelles ;
transaction ; l’interface utilisateur : elle est composée d’un ensemble de des-
— les attributs statiques, rétrospectifs, historiques et temporels sins d’écrans qui s’enchaînent. Cela permet de décrire sommaire-
comme de nouveaux types d’attributs ; ment les unités de dialogue entre les utilisateurs et le système, tout
— les relations statiques, rétrospectives, historiques et temporel- en sachant que la finalité de ce dialogue est le déclenchement d’une
les comme de nouveaux types de relations. ou de plusieurs transactions de mises à jour sur la base de données
Nota : les types d’attributs ont une sémantique similaire aux types de classes. temporelles.
Les types de relations ont une sémantique similaire aux types de classes.
Le langage TODL (conçu et réalisé par l’université d’Athènes) [18]
est une extension du langage ODL. Il permet de décrire les concepts
temporels du modèle TODM. Par exemple, le schéma temporel, 4.2 Règles de passage
décrit à la figure 14, peut se décrire en TODL comme sur la
figure 25.
Nous expliquerons, dans le paragraphe suivant, les règles de pas- On propose les règles de passage d’un schéma conceptuel à un
sage du schéma conceptuel à la description TODL des classes per- schéma logique TOOBIS. Dans ce paragraphe, nous considérons
sistantes. uniquement les règles de passage spécifiques à l’extension tempo-
relle du modèle conceptuel (c’est-à-dire classe instantanée, classe
Le langage TOQL [19] (conçu et réalisé par l’université d’Athènes)
temporelle avec historisation et avec estampillage, calendrier,
permet de formuler des requêtes sur des données temporelles.
domaine temporel et contrainte). Toutes les règles de passage rela-
Nous illustrons ce langage par deux requêtes simples relatives à
tives aux classes d’acteurs, événements interne, externe et temporel
l’attribut historique fonction de la classe employé (figure 26).
vers une spécification O2 sont déjà décrites dans [12] et sont sem-
Dans l’environnement TOOBIS, le langage de programmation blables pour l’environnement TOOBIS.
orienté objet qui a été choisi est C++ (et plus précisément VisualC++
Nous illustrons, pour chaque concept de l’extension temporelle
de Microsoft). Ce langage est utilisé comme langage de développe-
du modèle conceptuel, comment passer à la spécification logique.
ment pour le code des opérations des classes persistantes et pour
Nous proposons six règles de passage :
l’interface utilisateur de l’application.
— classe instantanée ;
L’étape logique doit produire un schéma logique adapté au SGBD
— classe temporelle avec historisation ;
que l’on a choisi. Pour le SGBD temporel et orienté objet TOOBIS, le
schéma logique se compose de : — classe temporelle avec estampillage ;
— calendrier ;
— la structure des données temporelles : elle est composée de la
— domaine temporel ;
définition des classes persistantes en TODL ;
— la liste des calendriers : chaque calendrier est décrit par une — contrainte.
instruction de définition du langage TODL (l’instruction de définition La règle 1 s’applique pour chaque classe instantanée qui n’appa-
est strictement similaire à celle du modèle conceptuel, cf. § 3.2.1) ; raît jamais comme composante d’une autre classe (figure 27).
interface Personne interface Employé : Personne

(extent personnes) (extent employés key numéro)
{ attribute Instant granularity Day anniversaire ; { attribute Integer numéro ;
attribute String nom ; attribute String numéroSS ;
attribute String téléphone ; attribute String fonction valid granularity day ;
attribute Adresse adresse ; attribute Float salaire valid granularity day transaction ;
attribute StatutFamilial statut valid granularity day ; relationship Département rattaché valid granularity day ;
// opérations // opérations
} }
Le domaine temporel de l'attribut anniversaire se traduit par Le mot clé valid introduit la gestion du temps de validité et le mot
un instant du calendrier grégorien exprimé au niveau jour (si le clé transaction introduit la gestion du temps de transaction.
calendrier n'est pas mentionné, c'est, par défaut, le calendrier Les attributs numéro et numéroSS sont statiques. L'attribut fonction
grégorien qui est utilisé). est un attribut historique, l'attribut salaire est un attribut temporel.
Enfin la relation rattaché est une relation historique.
Figure 25 – Exemple de classes définies avec TODL
er
La liste des employés qui étaient « chef de projet » au 1 janvier 1990 L'évolution des fonctions de chaque employé entre 1990 et 1994
select tuple (NuméroEmp: y.numéro , NomEmp: y.nom) select tuple (NuméroEmp: y.numéro , NomEmp: y.nom,
from y IN employés, y.fonction [PERIOD « 1990/01/01,1994/01/01 » DAY] (2))
where from y IN employés.
y.fonction [INSTANT « 1990/01/01 » DAY] (1) = « chef de projet ».
(1) Sélectionner l'employé si la fonction de l'employé à l'instant « 1990/01/01 » était « chef de projet »
(2) Sélectionner toutes les fonctions qu'à eu l'employé durant l'intervalle de temps [1990/01/01,1994/01/01).
Figure 26 – Illustration du langage TOQL
À partir d'une classe instantanée C elle devient dans TODL une classe statique C
Ses attributs deviennent des attributs statiques de la classe C

Ses liens de référence deviennent des relations statiques de la classe C
Ses liens de composition deviennent :
-- des attributs statiques car l'objet composant est décrit par un domaine structuré plutôt qu'une classe ;
-- des liens de référence statiques car le lien de composition est transformé en lien de référence.
Son lien d'héritage devient un lien d'héritage identique.
Figure 27 – Règle 1 : classe instantanée
La règle 2 s’applique pour chaque classe temporelle gérant une La règle 4 s’applique à chaque classe de calendrier qui n’est pas le
historisation (figure 28). calendrier grégorien. La description des granules et des opérations
de manipulation sont reprises dans le langage TODL tel que le décrit
La règle 3 s’applique pour chaque classe temporelle gérant un le modèle conceptuel.
estampillage (figure 29). La règle 5 s’applique sur les attributs qui ont un domaine tempo-
Ces trois règles permettent de déduire, à partir des classes rel. Le domaine spécifié dans la spécification conceptuelle est gar-
d’objets, la structure de données en TODL. Les classes TODL décri- dée dans la spécification TODL (figure 30).
tes dans le paragraphe précédent ont été déduites en appliquant ces La règle 6 s’applique aux contraintes décrites dans les classes
trois règles sur le schéma conceptuel de la figure 14. d’objets (qu’elles soient instantanées ou temporelles) (figure 31).
Classe temporelle T d'une classe devient :

instantanée C avec une historisation -- un attribut historique de la classe statique C, si la classe temporelle ne contient qu'un attribut comme
basée sur le temps de validité propriété ;
-- une relation historique de la classe statique C, si la classe temporelle ne contient qu'un lien
de référence comme propriété ;
-- une classe historique de la classe statique C, si la classe temporelle contient plusieurs propriétés ;
-- un attribut historique de la classe statique C, car classe T n'a que des attributs qui sont traduits
par un domaine structuré.

instantanée C avec une historisation -- un attribut rétrospectif de la classe statique C, si la classe temporelle ne contient qu'un attribut
basée sur le temps de transaction comme propriété ;
-- une relation rétrospective de la classe statique C, si la classe temporelle ne contient qu'un lien
-- une classe rétrospective de la classe statique C, si la classe temporelle contient plusieurs propriétés ;
-- un attribut rétrospectif de la classe statique C, car classe T n'a que des attributs qui sont traduits

instantanée C avec une historisation -- un attribut temporel de la classe statique C, si la classe temporelle ne contient qu'un attribut comme
basée sur le temps de transaction et propriété ;
le temps de validité -- une relation temporelle de la classe statique C, si la classe temporelle ne contient qu'un lien
-- une classe temporelle de la classe statique C, si la classe temporelle contient plusieurs propriétés ;
-- un attribut temporel de la classe statique C, car classe T n'a que des attributs qui sont traduits
Figure 28 – Règle 2 : classe temporelle avec historisation

instantanée C avec un estampillage -- un ou plusieurs attributs statiques de la classe C couplé(s) à un attribut représentant son estampille
basé sur le temps de validité valide. Cette estampille est gérée par l'applicatif ;
-- un attribut statique de la classe C, associé à un domaine structuré composé de l'ensemble des attributs
de la classe temporelle T plus l'estampille valide. Cette estampille est gérée par l'applicatif ;
-- on transforme l'estampillage de la classe T en historisation et on applique la règle 2 sur cette nouvelle
définition.

basé sur le temps de transaction système. Cette estampille est gérée par l'applicatif ;
-- un attribut statique de la classe C associé à un domaine structuré composé de l'ensemble des attributs
de la classe temporelle T plus l'estampille système. Cette estampille est gérée par l'applicatif ;
définition.

basé sur le temps de validité et le bitemporelle. Cette estampille est gérée par l'applicatif ;
temps de transaction -- un attribut statique de la classe C associé à un domaine structuré composé de l'ensemble des attributs
de la classe temporelle T plus l'estampille bitemporelle. Cette estampille est gérée par l'applicatif ;
définition.
Figure 29 – Règle 3 : classe temporelle avec estampillage
INSTANT < c,g > INSTANT calendar c granulary g

INSTANT-A < c,g > Absolute INSTANT calendar c granularity g
INSTANT-R < c,g > relative INSTANT calendar c granularity g
INTERVALLE < c,g > PERIOD calendar c granularity g
INTERVALLE-A < c,g > Absolute PERIOD calendar c granularity g
INTERVALLE-R < c,g > relative PERIOD calendar c granularity g
PÉRIODE < c,g > INTERVAL calendar c granularity g
Figure 30 – Règle 5 : domaine temporel
Pour chaque contrainte, il faut :

-- écrire une fonction qui vérifie la contrainte ;
-- définir la classe d'exception pour cette contrainte ;
-- décrire la procédure à déclencher quand l'exception est levée.
Pour une contrainte intra-time la fonction vérifiant la contrainte ne contient qu'une requête OQL.
Pour une contrainte inter-objet la fonction vérifiant la contrainte ne contient qu'une requête TOQL.
Pour chaque classe contenant il faut écrire des procédures :

des contraintes -- controlesImmédiats( ) pour déclencher les fonctions des contraintes de type intra-objet (procédure
déclenchée à chaque invocation d'opération sur l'objet).
-- controlesDifferes( ) pour déclencher les fonctions des contraintes de type inter-objet (procédure
déclenchée à la fin de la transaction base de donnée).
Pour chaque transaction modifiant il faut ajouter le bloc d'instructions pour lequel des exceptions doivent être interceptées (try bloc) et
la classe d'objet l'instruction permettant de décrire quelles exceptions doivent être interceptées (catch instruction).
Figure 31 – Règle 6 : contraintes
5. Conclusion nous a semblé minimal de prérequis sur cette notion de « temps »

afin qu’il comprenne mieux la problématique engendrée par la prise
en compte des aspects temporels dans les applications bases de
Le pilotage des organisations est de plus en plus pointu et il données.
nécessite d’avoir un réservoir informationnel représentant le plus L’extension temporelle est présentée selon trois parties :
fidèlement possible l’évolution de l’organisation dans son entier. Ce
réservoir est la mémoire commune de l’organisation et doit se struc- — extension de l’étape conceptuelle ; elle est présentée par
turer par rapport à l’axe du temps, puisque l’on veut surveiller son l’extension temporelle du modèle conceptuel ;
évolution. Les modèles de conception et les SGBDs doivent donc — extension de la démarche conceptuelle ;
être dotés de concepts et de mécanismes spécifiques aux aspects — extension de l’étape logique illustrée par un schéma logique
temporels relatifs à l’information. Ce constat nous a amené à tra- spécifique et des règles de passage à un SGBD temporel et orienté
vailler sur ce domaine par l’intermédiaire du projet esprit TOOBIS, objet TOOBIS construit au dessus de O2.
qui a comme vocation de définir une méthode temporelle et orien- Le travail réalisé au sein du projet TOOBIS et appliqué sur le
tée objet et un SGBD temporel et orienté objet. SGBDOO O2 sera de le généraliser :
Nous avons présenté dans cet article la méthode temporelle — à un autre SGBDOO comme Poete qui suit les recommanda-
comme une extension temporelle d’une méthode orientée objet tions de ODMG ;
déjà présentée dans [2] et [12]. — à un SGBD objet relationnel comme Oracle.
Le temps est une notion qui apparaît simple car elle est utilisée au Du point de vue méthode, les concepts introduits ne sont pas
quotidien, mais elle peut devenir complexe lorsque l’on doit la pren- dépendants de ceux du SGBD ciblé ; par conséquent, ce travail
dre en compte et la gérer dans les systèmes informatiques. Pour consiste à définir, pour chaque type de cible différente, des règles de
toutes ces raisons, nous avons proposé au lecteur l’ensemble qui passage et un schéma logique adaptés.
Références bibliographiques
[1] WIEDERHOLD (G.), FRIES (J.F.) et WEYL (S.). – [8] ADIBA (M.) et LINDSAY (B.). – Database [14] SOUVEYET (C.), DENECKÈRE (R.) et ROL-
Structured organisation of clinical databases. snapshot. Proc 6th Int. Conf. on VLDB, Mon- LAND (C.). – The object oriented methodology
Proc AFIPS National Computer Conf. (1975). treal, Canada (1980). (OOM). TOOBIS project. Deliverable T23D1.1,
[2] ROLLAND (C.). – Application d’une méthode [9] BUI-QUANG (N.). – Aspects dynamiques et chap. 3 (1997). http ://www.di.uoa.gr/~toobis/
de conception orientée objet et événement. gestion du temps dans les systèmes de ges- Deliverables.html.
Techniques de l’Ingénieur, H 3 258, vol. H3. tion de bases de données. Thèse de doctorat, [15] SOUVEYET (C.), DENECKÈRE (R.) et ROL-
Traité Informatique (1996). Grenoble (1986). LAND (C.). – The temporal extension (TOOM).
[3] ALLEN JAMES (F.). – An Interval-Based Repre- [10] ADIBA (M.) et BUI-QUANG (N.). – Dynamical TOOBIS project. Deliverable T23D1.1, chap. 4
sentation of Temporal Knowledge. IJCAI, Database Snapshots. Albums and Movies, (1997). http ://www.di.uoa.gr/~toobis/Delive-
p. 221-226 (1981). IFIP 87 (1987). rables.html.
[4] CLIFFORD et RAO. – A simple, General Struc- [11] SNODGRASS et AHN (I.). – A taxonomy of [16] GEHANI (N.) et JAGADISH (H.V.). – ODE as an
ture for Temporal Domains. IFIP 87 p. 247-265 time in databases. Proc. of ACM SIGMOD active database : constraints and triggers.
(1988). Conference (1985). Proc of the 17th VLDB, Barcelone (Espagne),
[5] TSQL2 language design committee, p. 327-336 (1991).
[12] ROLLAND (C.). – Conception de bases de
« TSQL2 ». Ed Richard T. Snodgrass. Kluwer données : une méthode orientée objet et évé- [17] Sites Web dédiés au projet TOOBIS. http ://
Academic Publisher (1995). nement. Techniques de l’Ingénieur, H 3 248, www.di.uoa.gr/~toobis. http ://.zpal.01p.gr/
[6] ALLEN JAMES (F.). – Maintening Knowledge vol. H3. Traité Informatique (1996). toobis.
about Temporal Intervals. Communication of [13] SOUVEYET (C.), DENECKÈRE (R.) et ROL- [18] TODL Specifications & design. – TOOBIS
the ACM 26(11), p. 832-843 (1983). LAND (C.). – State of art : a comparison of project. Deliverable T32TR.1 (1997). http ://
[7] Specification of temporal support. – TOO- six object-oriented analysis methods. TOO- www.di.uoa.gr/~toobis/Deliverables.html.
BIS project. Deliverable T31TR.1, chap. 6 BIS project. Deliverable T23D1.1, chap. 2, [19] TOQL Specifications & design. – TOOBIS
(1997). http ://www.di.uoa.gr/~toobis/Delive- (1997). http ://www.di.uoa.gr/~toobis/Delive- project. Deliverable T33TR.1 (1997). http ://
rables. html. rables.html. www.di.uoa.gr/~toobis/Deliverables.html.

Conception de Bases de Données 2

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Conception de Bases de Données 2

Transféré par

Droits d'auteur :

Formats disponibles

Conception de bases de données

1. Objectifs des SGBDs temporels ........................................................... H 3 268 - 2

L es bases de données (BDs) conventionnelles sont conçues pour stocker et

Cette tendance se confirme par l’intégration de SQL/T (extension temporelle

■ Manipuler les données temporelles

La représentation de l’évolution des phénomènes réels dans le ■ Structure temporelle ponctuelle

Les périodes de temps permettent de manipuler des quantités de ■ Temps relatif

■ Les objets historiques permettent, comme leur nom l’indique, de

Tableau 2 – Exemples d’objets rétrospectifs

Tableau 3 – Exemples d’objets temporels

Les contraintes statiques du modèle sont de trois types : contrain-

3. La modélisation Composition Référence

du modèle conceptuel Mécanisme

Homme Femme Célibataire Marié Divorcé

Classe Personne Classe Femme Classe Marié

Figure 4 – Exemples de liens d’héritage

● Les propriétés dynamiques sont décrites en termes d’opéra- ■ En résumé :

passation d'une commande Horloge

Événement externe Événement interne Événement temporel

f1 : itération selon f1 déclenche

Figure 5 – Exemples d’événements

L’objectif de l’extension est de doter le modèle :

Il permet la gestion de plusieurs calendriers simultanés pour une

3.2.2 Les domaines temporels

Figure 10 – Exemples d’attributs

Exemple : le salaire et la fonction d’un employé sont dans deux

Classe Temporelle Statut_familial Classe Temporelle Salaire

Variante de Employé Variante de Employé

Figure 12 – Exemples de classes temporelles

La classe temporelle est caractérisée par la dimension temporelle

Tableau 6 – Contenu informationnel de l’objet Durand selon le type de gestion

État Estampillage (1) Historisation

Temps Chef de projet, VT[20-12-95,forever) Programmeur, VT[12-12-94, 20-12-95)

Tableau 7 – Choix de gestion de la dimension temporelle

L’état bitemporel (colonne estampillage, ligne temps de validité et

propriétés Est une variante temporelle

Employé Est une fonction

propriétés Histoire < VT, TT >

Histoire < VT >

Figure 14 – Exemple de décomposition d’une classe en variantes temporelles

ClasseInstantanée Voiture Classe Temporelle Propriétaire

Figure 15 – Exemple de variante temporelle avec plus d’une propriété

Commande Ligne de commande

Classe Instantanée Commande Classe Instantanée Ligne de commande

La composition est décrite dans la classe Commande

Figure 16 – Exemple de lien de composition

Classe Instantanée Voiture Classe Instantanée Personne

Figure 17 – Exemple de lien de référence

3.2.3.3 Impact sur la définition des événements internes

Figure 19 – Exemple de la classe Stock

La classification proposée combine ces deux modes de typage.

Unicité X compositions. Quel que soit le type de classe participant à la réfé-

Classe temporelle EffortRéalisé Classe temporelle affectationhebdomadaire

Figure 20 – Spécification d’une classe avec contraintes

Tableau 9 – Exemples de contraintes de propriétés

La recherche des liens de composition et de référence entre clas-

interface Personne interface Employé : Personne

Figure 23 – Exemple de classes définies avec ODL

Extension temporelle TODL C++ binding TOQL Extension temporellle

interface Personne interface Employé : Personne

Figure 25 – Exemple de classes définies avec TODL

Figure 26 – Illustration du langage TOQL

Ses attributs deviennent des attributs statiques de la classe C

Figure 27 – Règle 1 : classe instantanée