Samovar : un modle pour les objets persistants avec rles

1
Samovar un modèle pour les objets persistants
avec rôles

• Stéphane Coulondre
• LIRMM / Université Montpellier II

2
Contexte

• Les modèles de bases de données (BD) à objets
• Object-Oriented Manifesto
• ODMG standardisation
• Contexte Evolution dans les BD à objets

3
Contexte

• Travaux sur lévolution
• évolution de schéma, migration dinstances, etc.
• versionnement, vues, etc.
• Aspect abordé ici
• évolution de (structure comportement rôle)
  dun objet

4
Plan

• I. Problèmes et objectifs
• II. Eléments de solution
• III. Détails de la proposition
• IV. Applications
• V. Validation
• VI. Travaux relatifs
• VII. Conclusion et perspectives

5
I. Problèmes et objectifs

• La notion de rôle est naturelle
• dans la langue, dans les Systèmes dInformations
• modélisation dune entité évolutive

6
I. Problèmes et objectifs

• modélisation dentités sous divers aspects (génie
  civil, gestion, électronique, informatique
  géographique, etc.)

Un pont ?
et informations communes
7
I. Problèmes et objectifs

• Il faut donc
• prendre en compte lévolution des entités en
  termes de gain et de perte de rôles
• prendre en compte la pluralité des rôles
  (aspects, facettes, points de vue, etc.)
• Pourquoi cette étude
• adaptation des SI au monde réel
• ODMG choix entre robustesse/souplesse
• souplesse nécessaire pour des impératifs
  techniques, scientifiques, financiers

8
I. Problèmes et objectifs

• Principes inviolables et nécessaires du modèle
  ODMG
• caractéristiques de robustesse et dexpressivité
  
• objets complexes, identité dobjet,
  encapsulation, types et classes,
• héritage, redéfinition de méthodes et liaison
  dynamique,
• typage statique et fort, complétude dun langage,
  etc.
• caractéristiques relevant du stockage et du
  traitement
• persistance orthogonale, langage de requêtes,
  etc.

9
I. Problèmes et objectifs

• Forte incompatibilité entre
• pluralité de type, comportement et
  mono-instanciation
• évolution dynamique et typage statique et fort
• Solutions ad-hoc, mais incompatibilité entre
• handles et identité dobjet
• problèmes de référencement, complexité
  utilisateur
• héritage multiple et évolution dynamique
• un seul contexte dobservation

10
I. Problèmes et objectifs

• But de la thèse
• un modèle de SGBD à objets, extension
• dODMG, gérant les rôles de la façon la
• plus inhérente, sûre et intuitive possible
• respectant lintégrité de lobjet
• lui permettant de jouer plusieurs rôles
• permettant lévolution dynamique

Objet
11
I. Problèmes et objectifs

• Contributions
• modèle formel de données (aspect déclaratif)
• langages de définition, de requêtes, de
  programmation et mécanismes associés
• prototype de SGBD

12
I. Problèmes et objectifs

• Autres propositions

13
Plan

• I. Problèmes et objectifs
• II. Elements de solution
• III. Détails de la proposition
• IV. Applications
• V. Validation
• VI. Travaux relatifs
• VII. Conclusion et perspectives

14
II. Eléments de solution

• Réflexion de base
• la classe et la mono-instanciation sont
  nécessaires
• robustesse, optimisation, cohérence conceptuelle
• aspects trop restrictifs pour lévolution un
  seul rôle
• un objet ? un rôle ? une classe
• Proposition
• un objet ? plusieurs rôles ? une classe

15
II. Eléments de solutionHiérarchies

• Classes
• nom
• pas de type ni de méthode
• ensemble de rôles
• Rôle
• descripteur
• un type
• un comportement
• organisés en hiérarchie

16
II. Eléments de solutionHiérarchies
17
II. Eléments de solutionHiérarchies

• Hiérarchie de rôles au sein dune classe
• aucune contrainte sur le type des rôles
• aucune contrainte sur les signatures de méthodes
• ? indépendance des rôles
• Hiérarchie de classes
• sémantique du lien de spécialisation entre
  classes  revisitée 
• héritage et extension des hiérarchies de rôles
• contraintes de sous-typage entre rôles de même
  identificateur
• spécialisation covariante des signatures de
  méthodes

18
II. Eléments de solutionHiérarchies

• Avantages de la double hiérarchisation
• rôles potentiels facilement identifiables
• rôles spécialisables dans les sous-classes
• ? rôles adaptés à la nature des objets
• pas de confusion entre modèles abstraits classes
  et rôles

19
II. Eléments de solutionHiérarchies

• Mais
• niveau de complexité utilisateur supplémentaire
• Solution originale
• rôle identifié par une assertion logique le
  critère de définition
• modélisation entièrement déclarative
• factorisation et partage de propriétés
  implicite/explicite
• contraintes de simultanéité implicites/explicites
• implication logique ? ordre partiel ? hiérarchie
  de rôles induite
• potentiel applicatif intéressant...

20
II. Eléments de solutionInstances

• Un objet
• est instance dune classe
• identifiant unique
• possède un critère courant
• ce critère détermine le sous-ensemble des rôles
  que lobjet joue
• peut gagner ou perdre dynamiquement des rôles

21
II. Eléments de solutionInstances
22
II. Eléments de solutionVues

• Une vue sur un objet
• but de confidentialité ou de visibilité
  volontaire
• permet dagir comme un filtre sur les rôles joués
  par un objet
• définie par lutilisateur (non le concepteur), de
  manière déclarative
• peut être persistante

23
II. Eléments de solutionVues
24
II. Eléments de solutionVues

• Différences avec l ODMG
• double hiérarchisation et spécialisation
  revisitée
• déclarativité
• objets évolutifs
• Différences avec la notion classique de vues en
  objets
• pas de données calculées
• se rapporte à un seul objet ? vue objet (à des
  collections)
• est une valeur dans la base ? vue objet (niveau
  schéma)
• modifiable dynamiquement ? vue objet (recalculée
  mais non modifiée)

25
Plan

• I. Problèmes et objectifs
• II. Eléments de solution
• III. Détails de la proposition
• IV. Applications
• V. Validation
• VI. Travaux relatifs
• VII. Conclusion et perspectives

26
III. Détails de la proposition

• Modèle de données formel
• incorporant les notions précédentes
• langages de définition de données extension dO2
  ODL
• exemples de critère de définition

27
III. Détails de la proposition Mécanismes
communs aux langages

• Mécanismes communs aux langages
• accès aux attributs et envoi de messages
• en spécifiant un ou des rôles
• par lintermédiaire dun critère daccès ltgt
  critère courant
• ? détermine de manière déclarative les rôles
  concernés
• envoi de messages avec liaison statique ou
  dynamique

28
III. Détails de la propositionEnvoi de messages
29
III. Détails de la proposition

• Langage de requêtes VOQL
• extension dODMG OQL
• syntaxe et sémantique formelle
• sécurisation des requêtes
• exemple de requête dans le calcul
• exemple VOQL
• SELECT x
• FROM x in Tout
• WHERE ROLES(x, état (physique))-gtpoids lt 65000

30
III. Détails de la proposition

• Langage de programmation VOPL
• extension dO2 O2C
• syntaxe et sémantique formelle
• spécificités par rapport à VOQL
• modification des racines de persistances
• instanciation
• ajout et suppression de rôle
• auto référence (dans les méthodes)

31
Plan

• I. Problèmes et objectifs
• II. Eléments de solution
• III. Détails de la proposition
• IV. Applications
• V. Validation
• VI. Travaux relatifs
• VII. Conclusion et perspectives

32
IV. Applications

• Application à la sécurité
• Modélisation possible de
• droits par identité
• droits par niveau
• droits temporels
• différence fondamentale droits non révocables
• exemple de critère de définition
• infos(medicales) et niveau(N) et Ngt8 et
  jour(J) et Jltgtvendredi
• exemple de critère daccès
• infos(medicales) et niveau(9) et jour(mardi)

33
IV. Applications

• Simulation du versionnement de schéma
• exemple de critère de définition
• date(D) et Dgt14/12/1999 et Dlt14/12/2000
• exemple de critère d accès
• date(18/01/2000)
• cohabitation de plusieurs versions
• versionnement alternatif et/ou temporel
• réversibilité
• travaux en cours avec lUniversité de Bologne

34
IV. Applications

• Diffusion de composants logiciels
• même composant selon un point de vue particulier
• (ex. composants de gestion pour différents
  métiers)
• exemple de critère de définition
• module(paie) et métier(santé) et
  spécialité(ambulancier)
• versions pouvant cohabiter au sein dun composant
• exemple de critère de définition
• version(2) et sousversion(3) et statut(beta)
• travaux en cours dans l équipe

35
IV. Applications

• Application à la multi-représentation
• un élément admet plusieurs représentations
• exemple un pont
• 1/1000 ? échelle(E) et Egt1/1000
• 1/10000 ? échelle(E) et Egt1/10000 et Elt1/1000
• 1/100000 ? échelle(E) et Egt1/100000 et
  Elt1/10000
• exemple de critère d accès
• échelle(1/5000)
• travaux en cours avec lUniversité de Nottingham

36
Plan

• I. Problèmes et objectifs
• II. Eléments de solution
• III. Détails de la proposition
• IV. Applications
• V. Validation
• VI. Travaux relatifs
• VII. Conclusion et perspectives

37
V. Validation

• Prototype de SGBD Objet avec rôles Samovar
• en C, O2C et Java
• architecture client/serveur
• Construit au dessus dO2 mais
• système de types différent
• notions de classe, dhéritage, et mécanismes
  daccès et denvoi de messages différents
• Documentation utilisateur
• Ensemble dexemples en VODL, VOPL et VOQL

38
V. Validation
Hiérarchie de classes
Type associé au rôle
Méthodes associées au rôle
Hiérarchie de rôles de la classe
39
Plan

• I. Problèmes et objectifs
• II. Eléments de solution
• III. Détails de la proposition
• IV. Applications
• V. Validation
• VI. Travaux relatifs
• VII. Conclusion et perspectives

40
VI. Travaux relatifs

• Approches marquantes relevant des langages
• (Pas daspects SGBD)
• Clovers (1989) Stein et Zdonik
• Multiple Views (1989) Shilling et Sweeney
• ROME (1989, 90) CarréCarré et Geib
• Objets morcelés (1996) Bardou et Dony

Pas de liaison dynamique
Typage dynamique
Pas dévolution
41
VI. Travaux relatifs

• Approches relevant des bases de données
• Iris (1987) Fishman et al.
• Aspects (1991) Richardson et Schwarz
• Fibonacci (1993, 95) Albano et al.
• IQL(2) (1995) Abiteboul et Dos Santos
• Extended Smalltalk (1996) Gottlob et al
• ORM (1997) Papazoglou et Krämer
• DOOR (1997) Wong et al.

Comportement global
Pas de liaison dynamique
Classes non hiérarchisées Liaison dynamique
empirique
Liaison dynamique possible sur les schémas
stricts
Pas dunicité dOID Pas de liaison dynamique
Liaison dynamique ?
Pas dunicité dOID
42
VI. Travaux relatifs

• Samovar fournit, en plus du respect de lODMG
• une synthèse des apports
• lhéritage multiple (rôles et classes) présent
  dans DOOR
• les vues présentes dans IQL(2) mais notion
  classique
• double hiérarchisation présente dans Extended
  Smalltalk et DOOR
• laspect original de la déclarativité
• applications à de nombreuses situations

43
Plan

• I. Problèmes et objectifs
• II. Eléments de solution
• III. Détails de la proposition
• IV. Applications
• V. Validation
• VI. Travaux relatifs
• VII. Conclusion et perspectives

44
VII. Conclusion

• Objectif atteint
• ODMG respecté
• robustesse
• nécessaire pour la migration des bases existantes
• La fonctionnalité dévolution est inhérente
• Application à diverses problématiques
• Prototype en-ligne implantant
• le modèle de données et son langage de définition
• les langages de programmation et de requêtes, et
  les mécanismes mis en jeu

45
Perspectives
VII. Conclusion - Perspectives

• Niveau Modèle
• Contraintes
• rôles exclusifs et plus généralement contraintes
  dintégrité
• exemple employé et chômeur
• masquage/encapsulation de rôles ?
• Raccourcis syntaxiques des critères, inférences ?
• Versionnement de létat des objets

46
VII. Conclusion - Perspectives

• Niveau réalisation
• Prototype ? application
• idéal un SGBD open-source (?-DB ?)
• implantation dans un langage de programmation
• Travaux en cours
• multi-représentation
• versionnement de schéma
• composants logiciels