III.3.2. EXTRA : un modèle de données pour
EXODUS
Le modèle de données pour EXODUS [12] est un
SGBD extensible développé à l'université de
Wisconsin (USA). De ce modèle, chacun s'accordera à reconnaitre
qu'il s'agit d'une boite à outils devant permettre d'implanter des SGBD
et ce pour n'importe quel modèle de données. En vue de le
concrétiser, un modèle de données, nommé EXTRA et
un langage de requêtes, nommé EXCESS, sont proposés dans
[13].
C'est un modèle d'objets complexes assez proche de ceux
proposés dans Galileo [10] ou dans Fad [10], dans lequel tous les objets
sont des valeurs. Il est même fréquent que l'introduction d'un
constructeur ref permet de manipuler explicitement les références
aux valeurs de la base. En ce sens, la notion de type permet de définir
structurellement ces valeurs.
50
Il sied de dire que seules les valeurs
générées à partir des types du schéma
peuvent être référencées. Cette diversité des
valeurs générées sont introduites par le constructeur own
dans la définition où leur type intervient. En somme, ces valeurs
sont divisées en deux catégories : les valeurs
référençables et celles qui ne le sont pas. Les valeurs
référençables sont introduites par own ref alors que les
autres le sont par own seulement. Le constructeur own introduit dans tous les
cas une dépendance existentielle pour la valeur ainsi
désignée.
Signalons néanmoins que la manipulation des valeurs de
la base rend transparente la notion de référence. Comme
l'accès à une valeur par un nom qui la désigne directement
ou par un nom qui désigne une référence vers cette valeur
se fait de la même manière pour l'utilisateur. Il est alors
possible de dire que le système infère automatiquement, par
rapport au schéma, le fait qu'il accède à cette valeur par
la fonction í ° ñ ou í ° ñ °
ñ (pour les valeurs référencées). Prenons un cas
pratique, si nous supposons que "pers"est un nom qui désigne une valeur
de type "personne", nous accédons de la même manière
"pers.Nom" et "pers.Epoux.Nom" alors que "pers.Epoux" désigne une
référence vers une valeur de type "personne".
Au final, il s'avère que la différence
étant explicite dans le schéma, car elle est prise en compte lors
de l'opération d'affectation. Seulement tel n'est pas forcément
le cas ; de ce fait nous en distinguons deux types : l'affectation de valeur
(copy to...) et l'affectation d'une référence à une valeur
(insert into...).
En revanche, nous pouvons étendre les domaines de base
avec les ADT (types de données abstraits). Les ADT sont des classes
persistantes définies à partir du langage E [14] (extension de
C++). Un cas pratique de leur utilisation est le champ "DateNais" dans le
type
En cela O2 offre donc un modèle d'objets complexes
faisant intervenir de manière orthogonale les constructeurs n-uplet
(tuple), ensemble (set) et séquence (list). Nous n'avons
51
"personne" dont le type Date est un ADT. Un ADT définit
donc une valeur encapsulée par différentes méthodes qui
lui sont attachées.
Cela revient à dire que toutes les valeurs
créées sont persistantes. Et que nous avons donc un seul espace
d'instanciation dont les données sont manipulées à travers
un langage de requêtes (EXCESS) du même niveau qu'un langage comme
SQL. Ce langage de manipulation n'est pas complet ; nous n'avons pas dans ce
système une intégration entre un langage général et
les aspects base de données.
| 
