L’évolution dans les bases de données orientées objet

L’évolution dans les bases de données orientées objet

Certains domaines comme la conception assistée par ordinateur (CAO), la gestion de documentations techniques, le génie logiciel, où les entités du monde réel décrites sont en continuelle évolution au cours du temps, ont besoin de prendre en compte cette évolution. Pour cela, il est important de décrire l’évolution des entités, de la conserver, de la consulter, de la manipuler. Dans les bases de données, une entité du monde réel est représentée par un nuplet (modèle relationnel) ou un objet (modèle objet) suivant un schéma donné (ensemble d’attributs pour le modèle relationnel, attributs et méthodes pour le modèle objet). L’évolution d’une entité du monde réel peut ainsi être traduite au niveau de la base de données au niveau des instances (objet ou n-uplet) et au niveau du schéma. La prise en compte de l’évolution d’une entité au niveau des instances concerne la modification de la valeur représentant l’entité. En revanche, le niveau schéma traduit une évolution de la description de l’entité. Les études réalisées au niveau des instances se scindent en deux approches:
– l’approche des bases de données temporelles ; de nombreux travaux ont été réalisés (Kline, 93), pour le modèle relationnel (Adiba, 87), (Snodgrass, 87), (Gadia, 92) et pour des modèles objet (Rose, 91), (Pissinou, 92),
– l’approche gestion de versions ; la gestion de versions est réalisée au niveau des attributs (Sciore, 91), au niveau des objets pour les bases documentaires (Ben Amouzegh, 86), et pour les bases de données orientées objets avec les systèmes tels que Version Server (Katz, 86)(Katz, 90b), ORION (Kim, 87)(Chou, 88), SHOOD (Rieu, 86)(Nguyen, 89), Ode (Agrawal, 91) et OVM (Käfer, 92), ou au niveau de contextes de versions (Cellary, 90), (Kimball, 91).

Les travaux gérant l’évolution au niveau schéma proposent trois grandes approches :
– l’approche modification de schéma, comme dans les systèmes Gemstone (Penney, 87), OTGen (Lerner, 90)(Lerner, 94) et NO2 (Scherrer, 93),
– l’approche gestion de versions pour des systèmes tels que Encore (Skarra, 86), CloSQL (Monk, 93) et les travaux de Clamen (Clamen, 94),
– l’approche gestion de vues (Bertino, 92), (Souza, 93).

Certains systèmes ont également pris en compte l’évolution aux deux niveaux. C’est le cas notamment des systèmes ORION (Chou, 88)(Kim, 88)(Kim, 89b), IRIS (Beech, 88), AVANCE (Björnerstedt, 89), SHOOD (Nguyen, 89) (Escamilla, 90) et Presage (Talens, 93).

L’évolution d’instance

Habituellement, dans les bases de données, l’évolution d’une entité du monde réel se traduit au niveau de l’instance qui la représente par une modification de la valeur (cf. (Date, 82), concept de base de données opérationnelle). L’entité reste décrite par le même schéma, seule la valeur de l’instance correspondante change. Différentes solutions ont été proposées pour représenter l’évolution de l’entité. Une première solution est celle des bases de données temporelles (ou historiques). Les différentes valeurs prises par un attribut sont conservées, soit systématiquement pour les bases de données historiques, soit selon une fréquence temporelle prédéfinie ou définie par l’utilisateur. Une autre solution est l’approche gestion de versions. Pour chaque entité du monde réel représentée, on conserve différentes valeurs prises par l’instance qui la décrit. Ces valeurs sont conservées sur décision de l’utilisateur ou en fonction de règles qu’il définit.

Les bases de données temporelles

Une première approche pour gérer l’évolution des entités a été d’intégrer le temps au niveau de leur représentation dans la base de données. Les premiers travaux ont porté sur l’extension du modèle relationnel (Snodgrass, 87), (Navathe, 89), (McKenzie, 91). Certains travaux ont ensuite été développés autour de modèles orientés objet (Rose, 91), (Pissinou, 92), (Wuu, 92).

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).

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 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 .

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.

Les modèles objets et entité/association temporels

Avec l’apparition des bases de données orientées objet, des modèles objets ont également été étendus par des notions temporelles (Rose, 91), (Edelweiss, 93), (Pissinou, 92), (Wuu, 92). Les travaux sur les modèles objets, encore peu nombreux, s’inspirent des nombreuses études réalisées pour le modèle relationnel. De plus, en l’absence de norme, les différences entre les modèles objets impliquent des travaux sur l’intégration du temps beaucoup plus hétérogènes que pour l’approche relationnelle. Des travaux récents, sur le système ORES (Theodoulidis, 94), ont également étendu le modèle entité/association à des aspects temporels, en se basant sur les études sur les modèles relationnels temporels (cf. § 2.1.1.).

Les modèles de gestion de versions

Les modèles de gestion de versions permettent également de conserver l’évolution des entités, mais sans être strictement liés au temps. Différentes valeurs d’une instance sont conservées sur décision de l’utilisateur, lorsque celui-ci les juge importantes. Le temps n’est plus le critère principal qui différencie les versions correspondant à une entité modélisée, ce sont les relations entre versions. Le temps n’est plus utilisé comme unique moyen d’obtenir et manipuler des versions données d’entités. La gestion de versions au niveau des instances est divisée en trois grandes approches : la gestion de versions d’attributs (Sciore, 91), la gestion de versions d’objets (Katz, 86), (Rieu, 86), (Chou, 88), (Dittrich, 88), (Agrawal, 91), (Käfer, 92), et la gestion de versions de contextes (Reichenberg, 89), (Cellary, 90), (Kimball, 91), (Gançarski, 94a). Certains travaux intègrent des concepts de plusieurs de ces approches mais aussi des bases temporelles. L’approche gestion de versions est la plus utilisée. Des études ont été menées pour :
– des modèles objet, pour les bases documentaires (Ben Amouzegh, 86) (Chrisment, 91)(Comparot, 94), (Dattolo, 95), et pour les systèmes de gestion de bases de données orientées objet tels que Version Server (Katz, 86) (Katz, 90a), SHOOD (Rieu, 86)(Djeraba, 93), ORION (Kim, 89b), Ode (Agrawal, 91) et OVM (Käfer, 92),
– des modèles de type Entité/Association, avec le modèle O2XER (Dijkstra, 93) et le modèle CERM (Dittrich, 90).

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
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 œuvre 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

Lire le rapport complet