Cours complet pour apprendre les systèmes de gestion de bases de données

Apparus vers 1986, les SGBD objet n'avaient pas connu le succès escompté cinq ans après leur naissance. Une des difficultés majeures provenait de l'absence de standards. Alors que les applications des bases de données relationnelles pouvaient prétendre à une très bonne portabilité assurée par le standard SQL, du poste de travail au calculateur central sur toute machine et tout système d'exploitation, les SGBD objet présentaient chacun une interface spécifique, avec des langages parfois exotiques. Un groupe de travail fut donc fondé en septembre 1991 à l'initiative de SUN par cinq constructeurs de SGBD objet : O2 Technology, Objectivity, Object Design, Ontos et Versant. Ce groupe prit rapidement le nom de ODMG (Object Database Management Group) et trouva un président neutre chez SUN en la personne de Rick Cattell, auteur de différents bancs d'essai sur les bases de données objet. Le groupe publia un premier livre intitulé The Object Database Management Standard, connu sous le nom ODMG'93. En fait, il ne s'agit pas d'un standard avalisé par les organismes de normalisation, mais plutôt d'une proposition d'un groupe de pression représentant des vendeurs de SGBDO.

Le groupe a continué à travailler et s'est enrichi de représentants de POET Software, UniSQL, IBEX et Gemstone Systems, ainsi que de multiples gourous et observateurs externes. Une nouvelle version du livre a été publiée en 1997, sous le titre ODMG 2.0 ; elle comporte dix auteurs. Le groupe est maintenant bien établi et collabore avec l'OMG et l'ANSI, notamment sur l'intégration à CORBA et à SQL3. Les constructeurs participants s'engagent à suivre les spécifications de l'ODMG, malheureusement sans dates précises. Un des échecs majeurs du groupe est sans doute l'absence de systèmes conformes aux nouvelles spécifications. O2, qui est le système le plus proche, ne répond pas exactement aux fonctionnalités requises [Chaudhri98].

La proposition décrit les interfaces externes d'un SGBDO utilisées pour réaliser des applications. Le SGBDO se fonde sur une adaptation du modèle objet de l'OMG, modèle de référence étudié au chapitre précédent. Il comporte un langage de définition des interfaces des objets persistants dérivés de l'IDL de l'OMG et appelé ODL (Object Definition Language).

Une définition peut aussi être effectuée directement dans l'un des langages supportés. La partie la plus intéressante de la proposition est le langage OQL (Object Query Language).

Une intégration est proposée avec les langages objet C++, Smalltalk et Java. Celle-ci précise les conversions de types effectuées et permet la manipulation des objets gérés par le SGBD depuis le langage. Elle est appelée OML (Object Manipulation Language).

La figure XII.1 illustre les différentes interfaces proposées par le standard ODMG. Ce sont celles permettant de réaliser des applications autour d'un SGBDO. Sont-elles suffisantes pour assurer la portabilité ? Probablement pas, car les interfaces graphiques sont aussi importantes et souvent spécifiques du SGBDO. Quoi qu'il en soit, le respect de ces interfaces par les produits améliorerait beaucoup la portabilité des applications.

La figure XII.2 illustre l'architecture typique d'un SGBDO conforme à l'ODMG. Autour d'un noyau gérant la persistance des objets, l'attribution des identifiants, les méthodes d'accès et les aspects transactionnels gravitent trois composants : le préprocesseur ODL permet de compiler les définitions d'objets et de générer les données de la métabase ; le composant langage OML spécifique à chaque langage de programmation permet de manipuler les objets conformes aux définitions depuis un langage de programmation tel C++, Smalltalk ou Java ; le composant OQL comporte un analyseur et un optimiseur du langage OQL capables de générer des plans d'exécution exécutables par le noyau. Au-dessus de ces trois composants, différents outils interactifs permettent une utilisation facile des bases ; ce sont par exemple un éditeur de classes pour éditer les schémas ODL, un manipulateur d'objets pour naviguer dans la base (les deux réunis constituent souvent le browser), une bibliothèque d'objets graphiques, des débogueurs et éditeurs pour les langages de programmation, etc.

Du côté interface avec les langages de programmation, le schéma préconisé est basé sur un système de type unique entre le langage et le SGBDO, chaque type du modèle objet du SGBDO (en principe celui de l'ODMG) étant traduit directement dans un type correspondant du langage. Un principe de base est aussi de ne nécessiter aucune modification du compilateur du langage. Les déclarations de classes persistantes peuvent être écrites en ODL, ou directement dans le langage de programmation (PL ODL). Un précompilateur permet de charger la métabase du SGBDO et de générer la définition pour le langage de programmation. Les programmes enrichis avec les définitions de classes d'objets persistants sont compilés normalement. Le binaire résultant est lié à la bibliothèque d'accès au SGBD lors de l'édition de liens, ce qui permet la génération d'un exécutable capable d'accéder à la base. La figure XII.3 illustre le processus d'obtention d'un exécutable.

L'OMG - organisme de normalisation de l'objet composé de plus de 800 membres, à ne pas confondre avec l'ODMG - a proposé un modèle standard pour les objets permettant de définir les interfaces visibles par les clients. Le modèle de l'ODMG est une extension du modèle de l'OMG et un candidat pour un profil BD de ce dernier. Il est mis en œuvre à l'aide du langage ODL qui permet de spécifier les schémas de bases de données, alors que le modèle de l'OMG est supporté par le langage IDL (Interface Definition Language). Les bases de données objet nécessitent des adaptations ou extensions ; ODL se veut l'adaptation d'IDL aux bases de données.

Une extension principale est tout d'abord la nécessité de considérer un niveau d'abstraction permettant de manipuler des états abstraits pour les objets. Ce sont ces états qui sont mémorisés plus ou moins directement dans la base pour les objets persistants. En outre, les objets peuvent être groupés en collections beaucoup plus variées que les seules séquences de l'OMG. Ils peuvent aussi être associés par des associations. Tout cela conduit à un modèle et à un langage de définition associé (ODL) beaucoup plus complexe que celui de l'OMG. ODL reste cependant un langage de niveau conceptuel, supportant un modèle objet abstrait, qui peut être implémenté dans différents langages, en particulier C++, Smalltalk ou Java. Chaque construction ODL a donc une implémentation correspondante pour chacun de ces langages. Au contraire d'ODL, OML s'appuie sur une implémentation et est donc spécifique à un langage de programmation objet.

Le modèle de l'OMG comporte des types d'objets avec identifiants et des types de valeurs, ou littéraux. Outre les interfaces qui permettent de spécifier des comportements abstraits, ODL permet de spécifier des classes qui définissent, en plus d'un comportement abstrait, un état abstrait pour des objets d'un même type. On aboutit donc à trois types de définitions d'objets ou valeurs, précisés ci-dessous ; c'est un peu complexe, voire confus, mais nécessaire pour permettre l'implémentation des spécifications de comportement ou d'état en C++, Smalltalk ou Java.

Nous définissons par exemple figure XII.4 une interface calculateur modélisant une machine à calculer.

INTERFACE CALCULATEUR {
    CLEAR();
    FLOAT ADD(IN FLOAT OPERAND);
    FLOAT SUBSTRACT (IN FLOAT OPERAND);
    FLOAT DIVIDE(IN FLOAT DIVISOR);
    FLOAT MULTIPLY (IN FLOAT MULTIPLIER);
    FLOAT TOTAL();
};

Une classe implémente ainsi une ou plusieurs interfaces. En plus d'un comportement, une classe définit un état abstrait. Pour mémoriser les états abstraits de ses instances, une classe possède aussi une extension de classe.

Le comportement abstrait pourra être hérité d'une interface. On voit donc qu'une classe donne une spécification d'une ou plusieurs interfaces en précisant quelques éléments d'implémentation, en particulier l'état des objets (abstrait car indépendant de tout langage) et l'extension qui va les contenir. Dans certains cas complexes, une classe peut d'ailleurs avoir plusieurs extensions. Il est aussi possible de préciser une clé au niveau d'une extension de classe : comme en relationnel, il s'agit d'un attribut dont la valeur détermine un objet unique dans l'extension. La figure XII.5 illustre une définition de classe incorporant l'interface calculateur.

CLASS ORDINATEUR (EXTENT ORDINATEURS KEY ID) : CALCULATEUR {
    ATTRIBUTE SHORT ID ;
    ATTRIBUTE FLOAT ACCUMULATEUR;
    VOID START();
    VOID STOP();
};

Notez qu'une interface peut aussi comporter des attributs abstraits, mais ceux-ci sont vus comme des raccourcis d'opérations, une pour lire l'attribut, l'autre pour l'écrire. Une interface n'a en principe pas d'extension.

Interfaces et classes sont des spécifications de types. Il est aussi possible de spécifier des types de valeurs : ceux-ci sont appelés des littéraux.

Les littéraux correspondent aux types de base tels entier, réel, chaîne de caractères, mais aussi aux structures. Un exemple de littéral est un nombre complexe : struct complex {float re; float im}. Les littéraux sont directement implémentés comme des types de valeurs en C++. Dans les autres langages pur objet (Smalltalk ou Java), ce seront des objets.

En résumé, l'ODMG propose donc un système de types sophistiqué, capable d'être facilement mappé en C++, Smalltalk ou Java. Il y a donc des types, des interfaces, des classes et des littéraux. L'ensemble forme la hiérarchie de spécialisation représentée figure XII.6.

Comme vu ci-dessus, une classe peut hériter d'une interface : il s'agit d'un héritage de comportement. Toutes les opérations de l'interface seront alors définies pour les objets de la classe. Au niveau de l'implémentation, la classe fournira le code des opérations.

En plus de cette relation d'héritage de comportement d'interface vers une classe, l'ODMG propose un héritage de structure abstraite, c'est-à-dire de l'état des objets, cette fois de classe à classe. Cette relation d'héritage d'état est notée EXTENDS (à ne pas confondre avec EXTENT !). Par exemple, nous étendrons la classe ORDINATEUR comme indiqué figure XII.7.

Soulignons que l'héritage de comportement (noté :) peut être multiple : une classe peut implémenter plusieurs interfaces, mais elle ne peut dériver que d'une seule autre classe. En cas de conflits de noms, c'est à l'utilisateur qu'il incombe de distinguer les noms.

CLASS ORDINATEURAREGISTRE EXTENDS ORDINATEUR: CALCULATEUR {
    ATTRIBUTE FLOAT REGISTRE;
    VOID RTOA();
    VOID ATOR ();
};

Les objets sont donc regroupés selon des types. Comme dans tout modèle objet, ils sont identifiés par des OID. Ceux-ci sont des chaînes binaires de format spécifique de chaque implémentation, gérés par le SGBD OO pour distinguer les objets. Un OID permet de retrouver l'objet qu'il identifie pendant toute sa durée de vie. Il reste donc invariant pendant la vie de l'objet.

Classiquement, les objets sont persistants ou transients : les objets persistants sont les objets de la base, les autres restant en mémoire. Les objets persistants peuvent être nommés : les noms sont donnés par les utilisateurs et sont uniques dans une base de données.

Les objets peuvent être atomiques, structurés, ou collections, c'est-à-dire composés de collections d'objets ou de littéraux. Les objets atomiques sont spécifiés par l'utilisateur par des définitions de classes comportant des attributs, des associations et des opérations. Les objets structurés sont prédéfinis et obéissent à des interfaces spécifiques.

Les objets sont créés par une opération new() définie au niveau d'une interface ObjectFactory implémentée par le SGBDO (voir figure XII.8). Ils héritent d'un ensemble d'opérations implémentées par le SGBDO pour le verrouillage - qui peut être bloquant si l'objet est occupé (opération LOCK) ou non (opération TRY_LOCK) -, la comparaison d'identifiants, la copie d'objet avec génération d'un nouvel objet et la suppression (voir figure XII.8).

INTERFACE OBJECTFACTORY {
    OBJECT NEW(); // CRÉATION D'UN NOUVEL OBJET
};
INTERFACE OBJECT {
    ENUM LOCK_TYPE{READ, WRITE, UPGRADE}; // TYPES DE VERROUS
    EXCEPTION LOCKNOTGRANTED(); // ERREUR VERROU REFUSÉ
    VOID LOCK(IN LOCK_TYPE MODE) RAISES (LOCKNOTGRANTED); //VERROUILLAGE BLOQUANT
    BOOLEAN TRY_LOCK(IN LOCK_TYPE MODE);// VERROUILLAGE NON BLOQUANT
    BOOLEAN SAME_AS(IN OBJECT ANOBJECT); // COMPARAISON D'IDENTIFIANTS D'OBJETS
    OBJECT COPY(); // COPIE AVEC GENERATION D'UN NOUVEL OBJET
    VOID DELETE(); // SUPPRESSION D'UN OBJET
};

Les objets structurés s'inspirent des types SQL2 utilisés pour la gestion du temps. L'intérêt de définir ces types comme des objets est de permettre de spécifier leur comportement sous forme d'interfaces. Des structures correspondantes sont aussi fournies dans les types de base proposés par l'ODMG. Les objets seuls offrent des opérations standard. Voici les types d'objets structurés supportés :

• Date représente un objet date par une structure (mois, jour, an) munie de toutes les opérations de manipulation classique des dates.
• Interval représente un objet durée par une structure (jour, heure, minute, seconde) munie de toutes les opérations de manipulation nécessaires, telles que l'addition, la soustraction, le produit, la division, les tests d'égalité, etc.
• Time représente les heures avec zones de temps, en différentiel par rapport au méridien de Greenwich ; l'unité est la milliseconde.
• Timestamp encapsule à la fois une date et un temps. Un objet timestamp permet donc une référence temporelle absolue en millisecondes.

L'ODMG préconise le support de collections homogènes classiques de types SET<t>, BAG<t>, LIST <t> et ARRAY<t>. Une collection un peu moins classique est DICTIONARY<t,v>, qui est une collection de doublets <clé-valeur>. Toutes les collections héritent d'une interface commune COLLECTION, résumée figure XII.9. Celle-ci permet de créer des collections d'une taille initiale donnée par le biais d'une « ObjectFactory », puis de manipuler directement les collections pour récupérer leurs propriétés (taille, vide ou non, ordre ou non, doubles permis ou non, appartenance d'un élément), pour insérer ou supprimer un élément, pour parcourir la collection par le biais d'un itérateur mono ou bidirectionnel.

INTERFACE COLLECTIONFACTORY : OBJECTFACTORY {
    COLLECTION NEW_OF_SIZE(IN LONG SIZE)
};
INTERFACE COLLECTION : OBJECT {
    EXCEPTION INVALIDCOLLECTIONTYPE(), ELEMENTNOTFOUND(ANY ELEMENT);
    UNSIGNED LONG CARDINALITY();
    BOOLEAN IS_EMPTY(),IS_ORDERED(),ALLOWS_DUPLICATES(),CONTAINS_ELEMENT(IN ANY ELEMENT);
    VOID INSERT_ELEMENT(IN ANY ELEMENT);
    VOID REMOVE_ELEMENT(IN ANY ELEMENT) RAISES(ELEMENTNOTFOUND);
    ITERATOR CREATE_ITERATOR(IN BOOLEAN STABLE);
    BIDIRECTIONALTERATOR CREATE_BIDIRECTIONAL_ITERATOR()RAISES(INVALIDCOLLECTIONTYPE);
};

Comme son nom l'indique, un itérateur permet d'itérer sur les éléments. Pour cela, il fournit une interface résumée figure XII.10. Un itérateur bidirectionnel permet d'aller en avant, mais aussi en arrière.

INTERFACE ITERATOR {
    VOID RESET() ; // INITIALISATION AU DÉBUT
    ANY GET_ELEMENT() RAISES(NOMOREELEMENTS); // OBTENTION ÉLÉMENT
    VOID NEXT_POSITION RAISES(NOMOREELEMENTS); // AVANCE POSITION
    REPLACE_ELEMENT (IN ANY ELEMENT) RAISES(INVALIDCOLLECTIONTYPE);
    …
};

Chaque collection possède en plus des interfaces spécifiques classiques. La figure XII.11 présente les opérations spécifiques aux dictionnaires. Il s'agit de la gestion de doublets <clé-valeur>, la clé étant en principe unique. Elle correspond à un mot d'entrée dans le dictionnaire, la valeur étant sa définition (ou son synonyme). L'utilisateur peut lier une clé à une valeur (ce qui revient à insérer ce doublet), délier la clé (la supprimer), rechercher la valeur associée à une clé, et tester si une clé figure dans le dictionnaire. Les dictionnaires peuvent permettre par exemple de gérer des répertoires de noms d'objets, etc.

INTERFACE DICTIONARY : COLLECTION
    EXCEPTION KEYNOTFOUND(ANY KEY);
    VOID BIND(IN ANY KEY, IN ANY VALUE); // INSERTION
    VOID UNBIND (IN ANY KEY)RAISE(KEYNOTFOUND); // SUPPRESSION
    ANY LOOKUP (IN ANY KEY)RAISE(KEYNOTFOUND); // RECHERCHE
    BOOLEAN CONTAINS_KEY(IN ANY KEY) ;
};

Les attributs permettent de modéliser les états abstraits des objets. Un attribut est une propriété permettant de mémoriser un littéral ou un objet. Il peut être vu comme une définition abrégée de deux opérations : Set_value et Get_value. Un attribut possède un nom et un type qui précise ses valeurs légales. Il n'est pas forcément implémenté, mais peut être calculé.

Les associations permettent de compléter la modélisation des états des objets. L'ODMG préconise le support d'associations binaires, bidirectionnelles de cardinalité (1:1), (1:N), ou (N:M), sans données. Une association de A vers B définit deux chemins de traversée inverses, A->B et B->A. Chaque chemin doit être défini en ODL au niveau du type d'objet source par une clause RELATIONSHIP. L'association pointe vers un seul objet cible ou vers une collection. Elle porte un nom et son inverse doit être déclaré. Pour la gestion, le SGBDO doit fournir des opérations sur associations telles que Add_member, Remove_member, Traverse et Create_iterator_for. De fait, les associations sont simplement des déclarations abstraites d'attributs couplés, valués par une valeur simple ou une collection, contenant des identifiants d'objets réciproques. La figure XII.13 illustre l'association classique entre VINS et BUVEURS, mais sans données.

INTERFACE BUVEURS {
    …
    RELATIONSHIP LIST<VINS> BOIRE INVERSE VINS::EST_BU_PAR;
    …
};
INTERFACE VINS {
    …
    RELATIONSHIP SET<BUVEURS> EST_BU_PAR INVERSE BUVEURS::BOIRE;
    …
};

Lorsqu'une association est mise à jour, le SGBDO est responsable du maintien de l'intégrité : il doit insérer ou supprimer les références dans les deux sens si l'option inverse a été déclarée. Il ne doit pas y avoir de référence pointant sur des objets inexistants. Ce n'est pas le cas pour un attribut valué par un objet, d'où l'intérêt d'utiliser des associations plutôt que de définir directement les attributs supports. Par exemple, la déclaration au niveau des buveurs d'un attribut par la clause ATTRIBUT BOIRE LIST<VINS> n'implique pas l'existence d'un chemin inverse ni la gestion de l'intégrité référentielle par le SGBDO. Cependant, les associations de l'ODMG restent assez pauvres puisqu'elles ne peuvent avoir de données associées.

Classiquement, les opérations permettent de définir le comportement abstrait d'un type d'objets. Elles possèdent les propriétés habituelles des opérations sur objet : le nom de l'opération, le nom des conditions d'erreurs (après le mot clé RAISES), le nom et le type des arguments (après le mot clé IN), le nom et le type des paramètres retournés (après le mot clé OUT). L'ensemble constitue la signature de l'opération. La figure XII.14 illustre la définition de l'opération boire dans l'interface buveurs.

INTERFACE BUVEURS {
    …
    INT BOIRE(IN VINS V, IN INT QTE) RAISES(NOVINS); //SIGNATURE DE
        L'OPÉRATION
    …
};

Dans sa nouvelle version 2.0, l'ODMG spécifie un métamodèle objet, c'est-à-dire un modèle objet décrivant son modèle. Ce modèle, plutôt complexe, permet de définir le schéma d'un référentiel objet capable de gérer des schémas de bases de données objet conformes à l'ODMG. Nous en donnons une vue très simplifiée figure XII.15. Il faudrait tout d'abord ajouter les concepts de littéraux, type et interface dont classe hérite. D'autres concepts sont nécessaires, comme MetaObject, Scope, Module, Exceptions. Tout cela est défini dans [ODMG97].

Le langage OQL a été défini à partir d'une première proposition issue du système O2 développé à l'INRIA. Les objectifs des auteurs étaient les suivants :

• permettre un accès facile à une base objet via un langage interactif autonome, mais aussi depuis un langage objet par intégration dans C++, Smalltalk, et plus tard Java ;
• offrir un accès non procédural pour permettre des optimisations automatiques (ordonnancement, index…) ;
• garder une syntaxe proche de SQL au moins pour les questions exprimables en SQL ;
• rester conforme au modèle de l'ODMG, en permettant l'interrogation de toutes les collections d'objets - extensions de classes ou autres collections imbriquées ou non -, le parcours d'association, l'invocation d'opérations, la manipulation d'identifiants, le support de l'héritage et du polymorphisme, etc. ;
• permettre de créer des résultats littéraux, objets, collections… ;
• supporter des mises à jour limitées via les opérations sur objets, ce qui garantit le respect de l'encapsulation.

Ces objectifs sont-ils atteints ? Beaucoup le sont, mais il n'est pas sûr que le langage soit simple, au moins pour les habitués de SQL. La compatibilité avec SQL reste faible, la sémantique étant généralement différente, par exemple pour le traitement des valeurs nulles. Le langage est aussi faiblement assertionnel, en ce sens que les parcours de chemins doivent être explicitement exprimés. Pour le reste, le langage est très riche, plutôt élégant, et il existe une définition formelle, certes assez difficile à lire. La syntaxe est compacte.

Le langage est construit de manière fonctionnelle. Une question est une expression fonctionnelle qui s'applique sur un littéral, un objet ou une collection d'objets, et retourne un littéral, un objet ou une collection d'objets. Les expressions fonctionnelles peuvent être composées afin de constituer des requêtes plus complexes. Le langage est aussi fortement typé, chaque expression ayant un type qui peut être dérivé de la structure de l'expression et du schéma de la base. La correction de la composition des types doit être vérifiée par le compilateur OQL. Du point de vue du typage, OQL est peu permissif et ne fait guère de conversions automatiques de types, à la différence de SQL. Syntaxiquement, beaucoup de questions sont correctes, mais erronées du point de vue du typage. OQL n'est pas seulement un langage d'interrogation, mais bien un langage de requêtes avec mises à jour. En effet, il est possible de créer des objets et d'invoquer des méthodes mettant à jour la base.

OQL permet aussi la navigation via les objets liés de la base, mais seulement avec des expressions de chemins monovaluées.

Il est possible de naviguer par des expressions de chemins un peu particulières, réduites à des chemins simples, que l'on définira comme suit :

Par exemple, voiture.appartient.personne.habite.adresse.ville est une expression de chemin valide sur la base de données exemple.

Pour parcourir les associations multivaluées, OQL utilise la notion de collection dépendante.

Par exemple, chaque buveur référence par l'association Boire une liste de Vins. Si B est un buveur, B.Boire est une collection dépendante, ici une collection de Vins. Par des variables ainsi liées du style B in Buveurs, V in B.Boire, OQL va permettre de parcourir les associations multivaluées. Ceci est puissant pour naviguer, mais plutôt procédural.

Pour présenter un peu plus précisément ce langage somme toute remarquable, nous procédons par des exemples un peu généralisés. Avant de les lire, il est bon de se rappeler que dans toute syntaxe une collection peut être remplacée par une requête produisant une collection. Réciproquement, il est possible de créer des collections intermédiaires et de remplacer chaque sous-requête par une collection intermédiaire. Cela peut permettre de simplifier des requêtes à nombreuses sous-requêtes imbriquées.

Nous présentons OQL à travers des exemples sur la base définie en ODL ci-dessus. Pour chaque exemple ou groupe d'exemples, nous abstrayons une syntaxe type dans un langage intuitif proche de la spécification de syntaxe en SQL : [a] signifie que a est optionnel, [a]* signifie une liste de 0 à N a séparés par des virgules, [a]+ de 1 à N a séparés par des virgules, {a|b} signifie un choix entre a ou b, et… indique une syntaxe libre compatible avec celles déjà introduites. Cette syntaxe peut servir de profil (les patterns sont à la mode) pour formuler un type de requête. Nous appelons aussi l'expression syntaxique un profil, ou plus simplement un format. Chaque profil est précédé d'un nom de trois lettres suivi de « : » servant de référence pour un usage ultérieur éventuel. Nous donnons aussi le type du résultat inféré par le compilateur (après la requête, sous forme ===> type). Le langage étant complexe, nous ne donnons pas une définition, celle-ci pouvant être trouvée dans [ODMG97]. Il y en a d'ailleurs deux, une formelle, une autre en BNF, et elles ne semblent pas totalement cohérentes !

XVII-5-2-1. Calcul d'expressions▲

((STRING) 10*5/2) || "TOTO"
===> string

PEX: (<TYPE>) <EXPRESSION>

XVII-5-2-2. Accès à partir d'objets nommés▲

MAVOITURE.COULEUR
===> LITTÉRAL STRING

MAVOITURE.APPARTIENT.NOM
===> LITTÉRAL STRING

PEO: <NOM OBJET>.<CHEMIN>

XVII-5-2-3. Sélection avec qualification▲

SELECT B.NOM, B.PRENOM
FROM B IN BUVEURS
WHERE B.TYPE = "GROS"
==> LITTÉRAL BAG<STRUCT<NOM:STRING,PRENOM:STRING>>

SELECT [<VARIABLE>.<ATTRIBUT>]+
FROM <VARIABLE> IN <COLLECTION>
WHERE <VARIABLE>.<ATTRIBUT> <COMPARATEUR> <CONSTANTE>

XVII-5-2-4. Expression de jointures▲

SELECT B.NOM, B.PRENOM
FROM B IN BUVEURS, E IN EMPLOYÉS
WHERE B.NSS = E.NSS AND B.TYPE = "GROS"
==> LITTÉRAL BAG<STRUCT<NOM:STRING,PRENOM:STRING>>

(PSJ) SELECT [<VARIABLE>.<ATTRIBUT>]+
      FROM <VARIABLE> IN <COLLECTION>,[<VARIABLE> IN <COLLECTION>]+
      [WHERE <VARIABLE>.<ATTRIBUT> <COMPARATEUR> <VARIABLE>.<ATTRIBUT>
      [AND <VARIABLE>.<ATTRIBUT> <COMPARATEUR> <VARIABLE>.<ATTRIBUT>]*
      [{AND|OR} <VARIABLE>.<ATTRIBUT> <COMPARATEUR> <CONSTANTE>]]*

SELECT ((EMPLOYÉBUVEUR)B).NOM, ((EMPLOYÉBUVEUR)B).PRENOM
FROM B IN BUVEURS
WHERE B.TYPE = "GROS"
==> LITTÉRAL BAG<STRUCT<NOM:STRING,PRENOM:STRING>

PIC: SELECT [((<CLASSE>)<VARIABLE>).<ATTRIBUT>]+
     FROM…
     [WHERE…]

XVII-5-2-5. Parcours d'associations multivaluées par des collections dépendantes▲

SELECT B.NOM, B.PRENOM
FROM B IN BUVEURS, V IN B.BOIRE
WHERE V.CRU = "VOLNAY"
==> LITTÉRAL BAG<STRUCT<NOM:STRING,PRENOM:STRING>

PCD: SELECT [<VARIABLE>.<ATTRIBUT>]+
     FROM…,[<VARIABLE> IN <VARIABLE>.<ATTRIBUT>]+
     [WHERE… ]

XVII-5-2-6. Sélection d'une structure en résultat▲

SELECT STRUCT (NAME: B.NOM, CITY: B.HABITE.ADRESSE.VILLE)
FROM B IN BUVEURS
WHERE B.TYPE = 'GROS'
===> LITTÉRAL BAG <STRUCT(NAME,CITY)>

SELECT DISTINCT (NAME: B.NOM, CITY: B.HABITE.ADRESSE.VILLE)
FROM B IN BUVEURS
WHERE B.NOM = 'DUPONT'
===> LITTÉRAL SET <STRUCT(NAME, CITY)>

PST: SELECT [DISTINCT][STRUCT]([<ATTRIBUT>: <VARIABLE>.<CHEMIN>]+)
     FROM…
     [WHERE…]

XVII-5-2-7. Calcul de collections en résultat▲

LIST(SELECT STRUCT(NOM: B.NOM, VILLE: B.HABITE.ADRESSE.VILLE)
FROM B IN BUVEURS
WHERE B.NOM = "DUPONT")
===> LITTÉRAL LIST <STRUCT(NOM, VILLE)>

PCS: <COLLECTION> (SELECT [DISTINCT]
                  [STRUCT] ([<ATTRIBUT>: <VARIABLE>.<CHEMIN>]+)
                  FROM…
                  [WHERE…])

XVII-5-2-8. Manipulation des identifiants d'objets▲

ARRAY(SELECT V
FROM V IN VOITURES
WHERE B.MARQUE = "RENAULT")
===> LITTÉRAL ARRAY(<OID>)

POI: <COLLECTION> (SELECT <VARIABLE>
                   FROM…
                   [WHERE…])

XVII-5-2-9. Application de méthodes en qualification et en résultat▲

SELECT DISTINCT E.NOM, E.HABITE.ADRESSE.VILLE, E.AGE()
      FROM E IN EMPLOYÉS
      WHERE E.SALAIRE > 10000 AND E.AGE() < 30
===> LITTÉRAL DE TYPE SET <STRUCT>

PME: SELECT [DISTINCT]…,
            [<VARIABLE>.<CHEMIN>.<OPERATION>([<ARGUMENT>]*)]*
     FROM…
     [WHERE….
     [AND<VARIABLE>.<CHEMIN>.<OPERATION>([<ARGUMENT>]*) <COMPARATEUR> <CONSTANTE>]*]

XVII-5-2-10. Imbrication de SELECT en résultat▲

SELECT DISTINCT STRUCT (NOM : E.NOM, INF_MIEUX_PAYES :
         LIST (SELECT I
         FROM I IN E.INFERIEUR
         WHERE I.SALAIRE > E.SALAIRE))
FROM E IN EMPLOYÉS
===> LITTÉRAL DE TYPE SET <STRUCT (NOM: STRING, INF_MIEUX_PAYÉS : LIST<EMPLOYÉS>)>

PQI: SELECT [DISTINCT][STRUCT](…,[<ATTRIBUT>:<QUESTION>…]*)
     FROM…
     [WHERE…]

XVII-5-2-11. Création d'objets en résultat▲

EMPLOYÉ (NSS:15603300036029, NOM:"JEAN", SALAIRE:100000)

EMPLOYÉ(SELECT STRUCT(NSS : B.NSS, NOM: B.NOM, SALAIRE : 4000)
        FROM B IN BUVEURS
        WHERE NOT EXIST E IN EMPLOYÉS : E.NSS=B.NSS)
==> BAG<EMPLOYÉS> INSÉRÉ DANS EMPLOYÉS

PCO : <CLASSE>(<QUESTION>)

XVII-5-2-12. Quantification de variables▲

FOR ALL P IN EMPLOYÉS : P.AGE < 100

PQU: FOR ALL <VARIABLE> IN <QUESTION> : <QUESTION>

EXISTS V IN SELECT V
FROM V IN VOITURES, B IN V.POSSEDE
WHERE V.MARQUE = "RENAULT": B.AGE() > 60

PQE: EXISTS <VARIABLE> IN <QUESTION> : <QUESTION>

XVII-5-2-13. Calcul d'agrégats et opérateur GROUP BY▲

SELECT E
FROM E IN EMPLOYÉS
GROUP BY (BAS : E.SALAIRE < 7000,
          MOYEN : E.SALAIRE £ 7000 AND E.SALAIRE < 21000,
          HAUT : E.SALAIRE ≥ 21000)
===> STRUCT<BAS: SET(EMP.), MOYEN:SET(EMP.),HAUT:SET(EMP.)>

(Q18) SELECT STRUCT(VILLE: E.HABITE.ADRESSE.VILLE, MOY : AVG(SALAIRE))
      FROM E IN EMPLOYÉS
      GROUP BY E.HABITE.ADRESSE.VILLE
      HAVING AVG (SELECT E.SALAIRE FROM E IN PARTITION)> 5000
===> BAG <STRUCT (VILLE: STRING, MOY: FLOAT)>

PAG: SELECT…[<AGGREGAT>(<ATTRIBUT>)]*
     FROM…
     [WHERE…]
     GROUP BY {<ATTRIBUT>+ | <PREDICAT>+}
     HAVING <PRÉDICAT>

XVII-5-2-14. Expressions de collections▲

SELECT E.NOM, E.SALAIRE
FROM E IN EMPLOYÉS
WHERE E.SALAIRE > 21000
ORDER BY DESC E.SALAIRE

PTR: <COLLECTION>
     ORDER BY {DESC|ASC} <ATTRIBUT>+

EMPLOYÉS UNION BUVEURS

PEN : <COLLECTION> {INTERSECT|UNION|EXCEPT} <COLLECTION>

SELECT B.NOM, FIRST(B.BOIRE)
FROM B IN BUVEURS

PFC : FIRST(<COLLECTION>) |
      LAST(<COLLECTION>) |
      <FONCTION>(<COLLECTION>)

XVII-5-2-15. Conversions de types appliquées aux collections▲

ELEMENT (SELECT V.MARQUE
FROM V IN VOITURES
WHERE V.NUMÉRO = "120 ABC 75")
===> STRING

FLATTEN (SELECT B.NOM, SELECT V.MILLÉSIME
FROM V IN B.BOIRE
WHERE V.CRU = "VOLNAY"
FROM B IN BUVEURS)

PCO : LISTTOSET(<COLLECTION>)|
      ELEMENT(<COLLECTION>)|
      DISTINCT(<COLLECTION>)|
      FLATTEN(<COLLECTION>)

XVII-5-2-16. Définition d'objets via requêtes▲

DEFINE IVROGNES AS
SELECT DISTINCT B
FROM B IN BUVEURS
WHERE B.TYPE = "GROS"

PDE : DEFINE <IDENTIFIANT> AS <QUESTION>

OQL est un très puissant langage de requête d'essence fonctionnelle. Nous n'avons donné que quelques exemples de possibilités avec une syntaxe approximative. En fait, OQL est un langage hybride issu d'un mélange d'un langage fonctionnel et d'un langage assertionnel comme SQL. D'ailleurs, SQL est lui-même un mélange d'un langage d'opérateurs (ceux de l'algèbre relationnelle) et d'un langage logique purement assertionnel (QUEL était proche d'un tel langage). Tout cela devient très complexe et la sémantique est parfois peu claire, quoi qu'en disent les auteurs. Pour être juste, disons que SQL3, décrit au chapitre suivant, souffre des mêmes défauts.

Le modèle de l'ODMG est abstrait, c'est-à-dire indépendant de toute implémentation. Pour l'implémenter dans un langage objet spécifique, il est nécessaire d'adapter le modèle. Par exemple, il faut préciser ce que devient un littéral dans un langage pur objet tel Smalltalk, ce que devient une interface en C++, ou une association en Java. Les types de données ODMG doivent être implémentés avec ceux du langage pour conserver un système de type unique. Il faut aussi pouvoir invoquer les requêtes OQL depuis le langage et récupérer les résultats dans des types intégrés au langage, par exemple comme des objets du langage.

L'ODMG propose trois intégrations de son modèle et de son langage de requêtes, une pour C++, une autre pour Smalltalk, une enfin pour Java. Autrement dit, la vision de l'usager d'une BD conforme aux spécifications de l'ODMG est précisée pour ces trois langages objet. Les objectifs essentiels de ces propositions sont :

1. La fourniture d'un système de types unique à l'utilisateur. En principe, le système de types utilisé est celui du langage de programmation parfois étendu, par exemple avec des collections. En effet, les vendeurs de SGBDO ayant longtemps décrié les SGBD relationnels pour l'hétérogénéité des types des langages de programmation et de SQL, ils se devaient d'éviter cet écueil.
2. Le respect du langage de programmation. Cela signifie que ni la syntaxe ni la sémantique du langage ne peuvent être modifiées pour accommoder la manipulation des données. Des classes supplémentaires seront généralement fournies, mais le langage de base ne sera pas modifié.
3. Le respect du standard abstrait ODMG. Ceci signifie que l'intégration proposée doit donner accès à toutes les facilités abstraites du modèle ODMG et de son langage de requêtes OQL. Ce principe n'est que partiellement suivi dans l'état actuel du standard, certaines facilités n'étant pas supportées, par exemple les associations en Java. Mais ceci devrait être le cas dans une future version.

Pour illustrer ces principes, nous traitons ci-dessous de l'intégration à Java, celles avec les autres étant similaires, mais un peu plus complexes. Auparavant, nous allons discuter des interfaces générales de gestion des bases de données et des transactions qui doivent être fournies.

L'accès aux bases de données s'effectue dans un contexte transactionnel. Le langage doit donc fournir des transactions implémentées par le SGBDO. Plus précisément, une transaction est un objet créé par une TransactionFactory qui implémente l'interface comportant les opérations suivantes :

• begin() pour ouvrir une transaction ;
• commit() pour valider les mises à jour de la transaction, relâcher les verrous obtenus et terminer la transaction avec succès ;
• abort() pour défaire les mises à jour de la transaction, relâcher les verrous obtenus et terminer la transaction avec échec ;
• checkpoint() qui a le même effet que commit() suivi de begin(), mais ne relâche pas les verrous ;
• join() pour récupérer l'objet transaction récepteur sous contrôle du contexte d'exécution (thread courant) ;
• leave() pour dissocier un objet transaction du contexte d'exécution courant ;
• isOpen() pour tester si la transaction est ouverte.

Ce type d'opérations sur transactions est commun, à l'exception de join() et leave() prévus pour permettre à un contexte d'exécution de gérer plusieurs transactions, ou à l'inverse pour permettre à une transaction de traverser plusieurs contextes d'exécution.

Avant d'exécuter des opérations au sein de transactions, un utilisateur doit ouvrir un objet base de données. Plus généralement, l'implémentation doit fournir des objets Database (créés à partir d'une DatabaseFactory) qui supportent les opérations suivantes :

• open(in string nom-de-base) pour ouvrir une base de nom donné afin d'y accéder via le langage en transactionnel ;
• close() pour fermer une base ;
• bind(in any unObjet, in string nom) pour donner un nom à l'objet passé en paramètre ; c'est l'opération de base pour nommer un objet dans une base de données, le nom ne devant pas déjà exister dans la base ; un même objet peut avoir plusieurs noms ;
• Object unbind(in string nom) pour enlever un nom à un objet précédemment nommé ;
• Object lookup(in string nom) pour retrouver et charger comme un objet du langage l'objet de la base de nom donné.

L'accès depuis un langage de programmation objet à une base ODMG nécessite donc l'implémentation de ces interfaces dans le langage objet. Ceci est simple puisque le SGBDO doit supporter ces opérations, les interfaces Transaction et Database étant partie intégrante du standard ODMG.

Java est un langage objet à la mode, plus simple et plus sûr que C++, idéal pour réaliser des applications distribuées robustes. Java comporte des littéraux de base (entier, réel, string, etc.) et des objets instances de classes. Il ne supporte pas les associations autrement que par des références interclasses. Tout ceci en fait un langage de choix pour développer des applications bases de données. Nous examinons brièvement les différents aspects de Java OML ci-dessous.

XVII-6-3-1. La persistance des objets▲

XVII-6-3-2. Les correspondances de types▲

XVII-6-3-3. Les collections▲

XVII-6-3-4. La transparence des opérations▲

XVII-6-3-5. Java OQL▲

SET<OBJECT> LESBONSVINS;
LESBONSVINS = VINS.QUERY("QUALITÉ = 'BONS'")

SET BUVEURSCRU;
QUERY = OQLQUERY ("SELECT DISTINCT B FROM B IN BUVEURS,
                   V IN B.BOIRE WHERE V.CRU = $1");
QUERY.BIND("VOLNAY");
BUVEURSCRU = QUERY.EXECUTE();

XVII-6-3-6. Bilan▲