III.2. Généralités sur la notion
de modèle des données
Nombres d'études ayant trait à la notion de
modèle de données mobilisent et insiste sur la portion de
système de types qui est issue des langages de programmation. Il
s'ensuit qu'une des caractéristiques importantes d'un système de
types est sa capacité à modéliser plus ou moins facilement
une situation donnée. Cependant, la notion de type est présente
dans tous les modèles ci-dessus mais elle n'est pas seulement
intentionnelle. Or, dire cela revient à que la notion de modèle
des données est intégrée dans des concepts plus globaux
permettant d'exprimer d'autres notions utiles dans les SGBD. Car, par suite, le
concept décrivant le type d'une entité est notamment
utilisé pour définir le contenant de ces entités.
A ce stade de la réflexion, il apparait donc de
supposer que cette spécificité des activités de service
comme les systèmes de types des langages de programmation
décrivent le modèle de mémoire utilisé par
l'environnement d'exécution du langage, d'où les modèles
de données déterminent le modèle mémoire
implanté par les SGBD. Pour répondre à cette question,
nous mettons en lumière deux niveaux de mémoire (mémoire
centrale / mémoire secondaire), ce qui explique que son système
de types soit moins puissant que ceux des langages de programmation.
Ce faisant, ces derniers travaillent en effet exclusivement en
mémoire centrale. Ainsi, nous pouvons donc dire que, pour ces
différents types de SGBD, le modèle de données
associé est grandement influencé par l'efficacité du
modèle de mémoire qui peut être mis en oeuvre (la
réciproque étant vraie aussi), et surtout celle du modèle
de stockage.
III.3. Structure des modèles des données
à objet
Nous avons vu que la notion des modèles d'objets
constitue la portion de système de types qui est issue des langages de
programmation. Par-là même, dans cette partie nous allons parler
des modèles de données à objet. D'où, il en
résulte que la partie principale qui différencie les
modèles à base de valeurs des modèles objets est la
référence.
En ce sens, elle est utilisée pour dissocier
l'identification d'un objet de sa valeur définissant ainsi des objets
abstraits. Ces choses étant dites, nous reviendrons aussi dans ces
modèles d'identificateur d'objet (oid) et d'état d'un objet.
Sachant cela, nous proposons une étude de ces différentes notions
dans différents modèles de systèmes existants.
Par ailleurs, comme nous ne pouvons pas non plus structurer un
attribut en un autre n-uplet, pour pouvoir définir l'abstraction de
l'adresse dans PERSONNE, nous devons
48
III.3.1. Le modèle de données d'Orion [9]
Le modèle des données dit Orion est un SGBD
orienté objet développé au MCC à Austin (USA). On
peut donc dire de ce modèle qu'il s'agit d'une extension du langage
Lisp, dans lequel sont introduits des concepts objets et base de données
à travers la notion de classe. S'il est pour partie imposée, cela
indique que dans le modèle d'Orion, tout est objet ; à cela nous
n'avons la notion de valeur qu'au niveau des attributs d'un objet.
De plus, la classe apporte aussi des fonctionnalités de
la base de données. Mais cela ne change rien à l'affaire, comme
la relation, la classe définit à la fois un type d'objet et
désigne l'ensemble des instances de cette classe.
On peut donc dire de manière structurel que le
modèle d'Orion est très proche du modèle relationnel
puisque d'un côté le constructeur ensemble est mis en oeuvre
seulement au niveau de la classe et d'un autre coté l'état d'un
objet a une structure de n-uplet dont les attributs sont soit des valeurs de
base, soit des objets abstraits.
C'est plutôt que, dans la mesure où le seul moyen
de représenter des attributs multi values est alors de gérer
explicitement des structures de listes comme cela est fait pour les champs
"Prenoms" et "Enfants" de la classe Personne.
49
définir un objet de classe ADRESSE. S'il est clairement
établi que nous considérons l'adresse comme propre à
chaque personne, Orion offre la possibilité de définir des liens
dit "composite" entre objet.
Cela signifie que l'objet Adresse ne peut être
partagé par aucun autre objet et qu'il existe une dépendance
existentielle entre les deux objets (si un objet PERSONNE est détruit,
l'objet "composite" ADRESSE l'est aussi). La sémantique de ces deux
types de liens ne peut être mise en oeuvre qu'au niveau de la
référence ou de l'identificateur de l'objet car c'est une
contrainte dynamique associée à l'objet et non à sa
classe.
Autrement dit, toutes les instances d'une classe Orion sont
persistantes. Nous avons donc deux espaces d'instanciation bien
séparés : l'espace temporaire des données Lisp
(essentiellement composé de listes) et l'espace des objets persistants
décrit par les classes.
Mais ce n'est pas tout, nous constatons que le
dysfonctionnement au niveau du système de type n'a pas été
supprimé. Outre, nous avons deux systèmes de types qui partagent
néanmoins leurs domaines de base, ce qui réduit le
dysfonctionnement. Avec les nouveaux concepts objet et la base de
données ne sont donc pas orthogonaux aux autres concepts du langage
initial.
| 
