Mises a jour

Les operations classiques de mise a jour (Insert, Up date et Delete) sont adaptees au contexte temporel.

Dans le cas d'historiques suivant le temps de validite, l'utilisateur doit fournir, outre eventuellementune valeur structurelle, une valeur temporelledatant la mise a jour. Dans le cas du temps de transaction, cette estampille est automatiquement fournie par le systeme. Nous illustrons ces operations de mise a jour, pour le temps de validite, dans le cadre du langage TSQL 2:

{ Insert: permet l'insertion de nouveaux n-uplets dans la base. Dans le cas ou le domaine temporel du temps de validite associe au nouveau n-uplet recoupe le temps de validite d'un n-uplet de m^eme valeur alors deux cas sont possibles:

{ Le systeme refuse l'insertion si une telle contrainte a ete explicitement denie par l'utilisateur.

Exemple:

INSERT INTO CamionEntretiens

VALUES ('735 AOC 38', 'batterie', '800') VALID TIMESTAMP '3/3/1997'

{ Up date. La mise a jour des attributs non-temporels se fait comme en SQL 2: les valeurs d'un ou plusieurs attributs du n-uplet sont modiees, sans que le temps de validite en soit aecte.

Exemple:

UPDATE CamionEntretiens SET Nature TO 'vidange'

WHERE Immat = '735 AOC 38' AND Nature = 'batterie'

Le temps de validite peut aussi ^etre modie:

UPDATE CamionEntretiens

SET Nature TO 'vidange' VALID TIMESTAMP '3/4/1997' WHERE Immat = '735 AOC 38' AND Nature = 'batterie'

{ Delete. Cela permet de supprimer des n-uplets d'une relation en annulant des periodes

de validite. Deux cas sont possibles suivant la nature de la relation:

{ valid state(la periode de validite associee est un intervalle): les tuples concernes par la condition donnee verront leur periode de validite amputee de la periode donnee. Dans le cas ou la periode resultante est vide, le n-uplet est eectivement supprime de la relation.

{ valid event(la periode de validite associee est un instant): les tuples concernes par la condition donnee et dont l'estampille correspond a la valeur donnee sont supprimes de la relation.

Exemple:

DELETE FROM CamionEntretiens

WHERE Immat = '735 AOC 38' AND Nature = 'vidange' VALID TIMESTAMP '3/4/1997'

1.4.1 Architectures classiques

Il existe de nombreuses propositions d'extensions temporelles pour des SGBD, parfois completees par la realisation de prototypes. Parmi tous ces travaux, [VGS96] degage trois principaux types d'architecture:

{ L'extensibilite propre aux SGBD a objets rend possible l'implantation de modeles de donnees temporels au dessus d'un SGBD existant sans avoir a intervenir sur son noyau. Par exemple, les modeles TF-ORM et TOM ont ete implantes avec le SGBD O2 au moyen de bibliotheques de classes implantant les types temporels (instants, intervalles, etc.), les sequences temporelles (suites de couples<instant, valeur>) et eventuellement les operateurs sur des collections d'objets temporels.

{ D'autres modeles temporels sont implantes en rajoutant une interface entre les applica-tions et un SGBD h^ote (par exemple,[Boh94, BBJS97]). Cette approche est necessaire-ment utilisee pour toutes les extensions temporelles de modeles de donnees relationnels n'orant pas la possibilite de denir de nouveaux types abstraits.

{ Une troisieme option, peu exploree a notre connaissance, consiste a integrer les fonc-tionnalites temporelles dans le noyau du SGBD. Ainsi, la structure de l'extension tem-porelle est transparente aux applications et les performances du SGBD sont conservees. [VGS96] analyse ces diverses architectures selon des criteres comme la completude des fonctionnalites temporelles, la compatibiliteavec une utilisation non-temporelle, la facilite d'implantation, les performances, etc.

Ainsi les propositions adoptant la premiere option sont facilement realisable tandis que leur facilite d'utilisation est discutable. Dans le deuxieme cas, la facilite d'utilisation est amelioree mais les performances sont diminuees car l'extension temporelle est une couche logicielle intermediaire entre les applications et le SGBD. Enn, l'integration dans le noyau du SGBD est sans doute la solution la plus performante, mais elle est peu utilisee car elle necessite en general la complicite du constructeur du SGBD. De plus, une telle solution n'est guere portable.

1.4.2 Prototypes: recapitulatif

La gure 1.20 regroupe l'ensemble des propositions presentee dans ce document, que ce soit des produits commerciaux, des prototypes ou des articles de recherches. Ne sont referencees ici que les propositions globales denissant un modele de donnees et/ou un langage de requ^ete; les travaux speciques sont cites lorsqu'il en est question.

Nom Naturea Type Modele Reference(s)

SQL 2 MD, LR non temp. Standard Relationnel [Ins92, CO93]

Oracle SGBD Industrie Relationnel [Ora92]

TempSQL MD, LR Recherche Relationnel [GN93]

TSQL 2 MT, MD, LR Recherche Relationnel [TSQ, Sno95b]

[DBS96] MD, LR Recherche Relationnel [DBS96]

Temp. modules MT, MD, LR Recherche Relationnel [WJS93, WJS95]

TFDL MD, LR Recherche Entites [SK94]

MCO Conception Recherche Objets [Cas93]

ODMG MD, LR non temp. Standard Objets [ADF+94]

O2 SGBD Industrie Objets [Tec95]

OSAM*/T MD, LR Recherche Objets [SC91]

TMAD MD, LR Recherche Objets [KS92]

TIGUKAT MD, LR Recherche Objets [GO93, OPS+95]

TF-ORM MD, LR Recherche Objets [EPP93, PEA+95]

OODAPLEX MT, MD, LR Recherche Objets [WD93]

TOOSQL MD, LR Recherche Objets [RS93]

Time Sequences MD, LR Recherche Independant [SS93]

aMT: Modele du temps, MD: Modele de donnees temporel, LR: Langage de requ^etes temporel Fig. 1.20 {Propositionsetudiees

Remarques concernant le choix des propositions:

{ SQL 2: Nous avons choisi SQL 2 plut^ot que SQL 3 pour plusieurs raisons. Tout d'abord, c'est SQL 2 qui est implante par la plupart des SGBD relationnels du commerce. De plus le projet SQL/Temporal (aspects temporels dans SQL 3) n'a commence ocielle-ment qu'en janvier 1996 (communiquede presse de l'AccreditedStandards Committee* X3), et n'est pas encore nalise; celui-ci tend a se rappocher fortement de TSQL 2. { ODMG: Nous faisons reference ici a la version 1 de la specication. L'ODMG a annonce

le 28 juillet1997 la version 2, mais celle-cine fait pas de nouvelle proposition concernant les aspects temporels (Cf. serveur WWW de l'ODMG,http://www.odmg.org/).

Pour chacune de ces propositions, nous avons resume ses principales caracteristiques suivant les points abordes pendant ce chapitre (Cf. gure 1.21): types temporels, multi-granularite (et extensibilite des unites), types historiques et mode d'interrogation.