Les versions dans les bases de données orientées objet
Les modèles relationnels
Parmi les travaux qui étendent le modèle relationnel, deux approches se distinguent : – l’intégration du temps au niveau des attributs (McKenzie, 91), (Gadia, 92), – l’intégration du temps au niveau des n-uplets (Ben-Zvi, 82), (Snodgrass, 87), (Navathe, 89). Le langage d’interrogation est également étendu pour permettre l’interrogation selon des conditions temporelles (Snodgrass, 87), (Navathe, 89).
Le temps au niveau des attributs
L’intégration du temps au niveau d’un attribut consiste à conserver les valeurs successives prises par l’attribut d’une entité. Lors de la définition de schéma, une composante de type intervalle de temps est associée à chaque attribut. Pour chaque n-uplet, chaque valeur prise par un attribut est conservée et associée à la date, ou la période à laquelle elle correspond. Une entité est donc décrite, pour chaque attribut, par un ensemble de couples (valeur, date). Les relations dans ce cas ne sont plus en première forme normale mais s’apparentent au modèle NF2 (Sheck, 82). Exemple I-1 : Dans le modèle relationnel intégrant des aspects temporels de Chakravarthy & Kim (Chakravarthy, 93), certains attributs sont couplés à un attribut de type intervalle de temps. La période associée à la valeur d’un attribut est en général la période de validité (appelée également période de l’événement ou période logique) de la valeur associée. La période de validité d’une valeur est l’intervalle pendant lequel le fait décrit est vrai dans le monde réel modélisé (Jensen, 94). Certains travaux introduisent la notion de date de transaction (appelée également date physique) à la place de la date de validité ou en plus de celle-ci (Gadia, 92). La date de transaction est la date à laquelle une valeur est enregistrée dans la base de donnée. Pour manipuler le temps, différents types sont définis : – les points de temps : instants isolés dans le temps (ex. les dates d’obtention de diplôme de Durand), – les périodes : intervalles de temps (ex. la période d’emploi de secrétaire de Durand), – les durées : quantités de temps (ex. la durée d’emploi de secrétaire de Durand), – les valeurs temporelles complexes : union d’instants isolés dans le temps et/ou d’intervalles de temps (ex. l’ensemble des périodes de chômage de Durand). Des opérations ont été introduites pour manipuler ces types temporels. Différents opérateurs de comparaisons ont été définis (précède, pendant, succède, …) pour comparer des points de temps, des périodes, des points de temps et des périodes, … les opérations arithmétiques ont également été spécifiées pour additionner, …, supprimer des valeurs des différents types temporels (ex. 20 mars 1995 + 3 jours = 23 mars 1995) (Allen, 84), (Snodgrass, 87), (Navathe, 89).
Le temps au niveau des n-uplets
Les principes définis pour l’intégration du temps au niveau des attributs ont également été appliqués au niveau des n-uplets. Chaque valeur prise par un n-uplet est associée à une date ou une période. Un n-uplet représente donc une même entité du monde réel durant une période donnée du monde réel modélisé. L’intégration du temps dans une relation est spécifiée lors de la définition du schéma.
Exemple I-2 : Dans le modèle intégrant le temps au niveau des n-uplets de Snodgrass (Snodgrass, 87), la définition du schéma d’une relation PERSONNE prenant en compte le temps est la suivante : create interval PERSONNE (Matricule is integer, Nom is char, Adresse is char, Emploi is char) Le mot-clé interval indique que la relation intègre des intervalles de validité. La relation PERSONNE de l’exemple précédent se représente alors comme suit : Matricule Nom Adresse Emploi From To 1000 Durand Paris étudiante 1-1-80 10:00AM 7-31-82 5:00PM 1000 Durand Lyon comptable 7-31-82 5:00PM forever 1001 Lassalle Lyon stagiaire 5-1-85 8:00AM 12-31-88 12:00PM 1001 Lassalle Lyon vendeur 12-31-88 12:00PM forever L’intégration du temps au niveau des n-uplets permet d’obtenir ces relations en première forme normale. Cependant, la création d’un nouvel n-uplet pour une modification de la valeur d’un attribut pose un problème de redondance d’information pour les autres attributs. Pour pallier cet inconvénient, la notion de dépendance temporelle a été introduite (Navathe, 89). Les attributs ou groupe d’attributs dépendants du temps de manière indépendante ont une dépendance temporelle. Le processus de décomposition de relations est appliqué suivant les dépendances temporelles. Les relations obtenues après décomposition sont alors en forme normale temporelle. Exemple I-3 : dans l’exemple précédent, l’attribut Nom, l’attribut Adresse et l’attribut Emploi ont chacun une dépendance temporelle propre ; ces attributs ont des valeurs qui évoluent au cours du temps, indépendamment les uns des autres. Il existe donc les trois dépendances temporelles suivantes : T @ {Nom} T @ {Adresse} T @ {Emploi} T représente le temps Chapitre I. : Etat de l’art 11 La relation R (Matricule, Nom, Adresse, Emploi, From, To) est décomposée suivant les dépendances temporelles. L’attribut Matricule est clé primaire, c’est la clé indépendante du temps. Les trois relations R1, R2 et R3 suivantes sont obtenues: R1 (Matricule, Nom, From, To) R2 (Matricule, Adresse, From, To) R3 (Matricule, Emploi, From, To) R1, R2 et R3 sont en forme normale temporelle, et contiennent les n-uplets suivants : R1 Matricule Nom From To 1000 Durand 1-1-80 10:00AM forever 1001 Lassalle 5-1-85 8:00AM forever R2 Matricule Adresse From To 1000 Paris 1-1-80 10:00AM 7-31-82 5:00PM 1000 Lyon 7-31-82 5:00PM forever 1001 Lyon 5-1-85 8:00AM forever R3 Matricule Emploi From To 1000 étudiante 1-1-80 10:00AM 7-31-82 5:00PM 1000 comptable 7-31-82 5:00PM forever 1001 stagiaire 5-1-85 8:00AM 12-31-88 12:00PM 1001 vendeur 12-31-88 12:00PM forever
Les langages d’interrogation temporels
De nombreux travaux ont traité de l’extension des langages pour prendre en compte les aspects temporels (Tansel, 93). De nombreuses extensions ont été apportées aux langages relationnels notamment au langage SQL (Navathe, 89), (Sarda, 90), (Theodoulidis, 94). Le langage TSQL2 est en cours de normalisation (Snodgrass, 94). Les langages temporels sont essentiellement basés sur l’ajout d’une clause temporelle (clause WHEN) au niveau des requêtes. Des conditions de sélection basées sur l’utilisation d’opérateurs temporels sont spécifiées dans cette clause. Les conditions temporelles portent sur la comparaison de valeurs de types temporelles et plus particulièrement celle de la période de validité des n-uplets. La période de validité des n-uplets est également utilisée au niveau de l’affichage du résultat d’une requête.
Table des matières
Introduction
Chapitre I. : Etat de l’art
1 . L’évolution dans les bases de données orientées objet
2 . L’évolution d’instance
2.1. Les bases de données temporelles
2.1.1. Les modèles relationnels
2.1.1.1. Le temps au niveau des attributs
2.1.1.2. Le temps au niveau des n-uplets
2.1.1.3. Les langages d’interrogation temporels
2.1.2. Les modèles objets et entité/association temporels
2.2. Les modèles de gestion de versions
2.2.1. Les modèles de gestion de versions d’attributs
2.2.2. Les modèles de gestion de versions d’objets
2.2.2.1. Le principe de dérivation
2.2.2.2. Les versions d’objets complexes
2.2.3. Exemple de système gérant des versions d’objets : OVM
2.2.3.1. Le modèle des objets et des versions du système OVM
2.2.3.2. Les opérations dans le système OVM
2.2.3.3. Bilan sur le système OVM
2.2.4. Les modèles Entité/Relation intégrant les versions
2.2.5. La gestion transparente de versions
2.2.6. Gestion de contextes de versions
2.2.6.1. Les versions de bases de données
2.2.6.2. Les versions de configuration dans le système O2
2.2.6.3. Bilan de l’approche contextes de versions
2.2.7. Les langages et interfaces pour versions d’objets
3 . L’évolution de schéma
3.1. Approche modification de schéma
3.1.1. Opérations sur les schémas
3.1.2. Adaptation des données
3.2. Approche versions de schéma
3.3. Approche gestion de vues
4 . L’évolution aux deux niveaux
4.1. Les différentes approches
4.2. Exemples de systèmes gérant des versions aux deux niveaux
4.2.1. Le système ORION
4.2.1.1. Le modèle de versions d’objets de ORION
4.2.1.2. L’évolution de schéma dans ORION
4.2.1.3. Versions de schéma dans ORION
4.2.1.4. Bilan sur le système ORION
4.2.2. Le système Presage
4.2.2.1. Le modèle de versions du système Presage
4.2.2.2. Versions d’objets composés dans Presage
4.2.2.3. Bilan sur le système Presage
5 . Les apports et les limites des travaux existants
6 . Notre approche pour la gestion de versions
Chapitre II. : Un modèle conceptuel intégrant les versions
1 . Orientations
2 . Notre modèle de versions
2.1. Les versions d’objets
2.2. Les versions de classes
2.3. Combinaisons des versions d’objets et de classes .
2.3.1. Gestion simultanée de versions de classes et d’objets
2.3.2. Gestion de versions d’objets seule
2.3.3. Gestion de versions de classes seule
3 . Le modèle sémantique de données intégrant les versions
3.1. Les concepts du modèle objet OMT
3.1.1. Les classes
3.1.2. L’héritage
3.1.3. Les relations entre classes
3.2. Les nouveaux types de classes dus aux versions
3.3. Les opérations
3.3.1. Les opérations sur les objets et les versions d’objets
3.3.2. Les opérations sur les classes
3.4. Héritage et gestion de versions
3.4.1. Les cas d’héritage
3.4.2. Héritage et versions de classes
3.4.3. Synthèse des conséquences des versions sur l’héritage
3.5. Compositions et associations entre tous types de classes
3.6. Stratégie du partage des versions d’objets
3.7. Contraintes sur les instances, inhérentes aux compositions et associations
3.7.1. Composition et association d’objets
3.7.2. Composition et association de versions d’objet
3.7.2.1. La problématique liée au partage de versions
3.7.2.2. Les solutions pour la composition
3.7.2.2.1. L’expression des contraintes sur les versions d’objets
3.7.2.2.2. Respect des contraintes par les opérations
3.7.2.3. Les solutions pour l’association
3.7.2.3.1. L’expression des contraintes sur les versions d’objets
3.7.2.3.2. Respect des contraintes par les opérations
3.7.3. Composition et association entre objets et versions
3.7.3.1. La problématique liée aux différences entre objets et versions
3.7.3.2. Les solutions pour l’expression des contraintes
3.7.3.3. Respect des contraintes par les opérations
3.7.4. Synthèse des contraintes pour la composition et l’association 89
3.7.4.1. Synthèse des contraintes pour la composition
3.7.4.2. Synthèse des contraintes pour l’association
3.7.4.3. Synthèse des conséquences sur les opérations
3.8. Versions de classes et relations de composition et d’associations
3.8.1. Nouvelle version de classe et relations existantes
3.8.2. Conséquences au niveau des instances
4 . Le modèle dynamique intégrant les versions
5 . Le modèle fonctionnel intégrant les versions
6. Bilan
Chapitre III. : Le langage de description et de manipulation VOSQL
1 . Objectifs
2 . Manipulation de schéma
2.1. Création des classes et des liens entre classes
2.2. Dérivation des classes et des liens
2.3. Modification et suppression des classes et des liens
2.4. Gel, dégel, version de classe par défaut
3 . Manipulation des instances
3.1. Création d’instance
3.2. Modification et suppression d’instance
3.3. Dérivation et migration d’instance
3.4. Gel, dégel et version d’objet par défaut
4 . Un langage d’interrogation intégrant les versions
4.1. Principe
4.2. Interrogation de classes simples
4.2.1. Base exemple de classes simples
4.2.2. Interrogation de classes d’objets
4.2.3. Interrogation de classes de versions
4.2.3.1. Les niveaux d’abstraction
4.2.3.2. Les transformations d’ensembles
4.2.3.3. Les critères internes
4.2.3.4. Interrogation de forêts de versions
4.2.3.5. Interrogation aux niveaux arbres et versions
4.2.3.6. Restructuration du résultat
4.2.3.7. Combinaisons de prédicats à différents niveaux
4.2.3.8. Liens entre classes simples de versions
4.2.4. Interrogations entre classes d’objets et de versions
4.3. Interrogation de versions de classes
4.3.1. Base exemple avec versions de classes
4.3.2. Interrogation d’une version de classe
4.3.3. Super-classe commune à plusieurs versions de classe
4.3.4. Interrogation de plusieurs versions de classe
4.3.5. Liens et versions de classes
4.4. Interrogation entre classes simples et versions de classes
5. Bilan
Chapitre IV. : Réalisation
1. Introduction
2 . Principe
2.1. Spécification d’un méta-modèle
2.2. Le langage de manipulation
2.3. La mise en oeuvre des contraintes
3 . Expérimentation
3.1. Le SGBD hôte
3.2. L’architecture du système VOHQL
3.3. Le méta-schéma
3.4. L’exécution des requêtes
3.5. L’implantation du schéma actif Urdos
3.6. L’interface graphique VOHQL
3.6.1. La création d’une base intégrant les versions
3.6.2. La représentation du schéma de la base
3.6.3. La création des instances
3.6.4. L’interrogation d’une base
3.6.4.1. Interrogation de forêts de dérivation
3.6.4.2. Interrogation de versions
3.6.4.3. Interrogation suivant les liens
3.6.5. La visualisation des instances
4. Bilan
Conclusion
Annexe I. : Notre approche et l’approche O2 : un exemple
1 . Gestion des versions dans notre environnement
1.1. Création du schéma de la base
1.2. Création des instances
1.3. Interrogation
2 . Gestion des versions dans O2
2.1. Création du schéma de la base
2.2. Création des instances
2.3. Interrogation
Annexe II. : Extrait de la grammaire LEX&YACC du langage
Références bibliographiques
|
Télécharger le document complet
Admin CliCours
