ODMG Object Database Standards and Language Analysis

Debut

Temps

Fin

1

PDT

M

1

APPARTIENT

N

ENSEIGNANT_CHERCHEUR

1

ENSEIGNE

N

FACULTE

FD

N

1

DEPARTEMENT

FNom

Doyen

FBureau

DNom

DPhone

Bureau

12

SESSION

N

1

CS

N

COURS

1

DC

NoS

Annee

Trim

NoC

CNom

CDesc

12

6

Le langage de définition d'objets: ODL

◼ Après cette vue d'ensemble du modèle objet de

l'ODMG, nous allons voir comment ces concepts

peuvent servir à créer un schéma de base de données

objets avec le langage de définition d'objets ODL

(Object Definition Language).

◼ La syntaxe et les types de données d'ODL sont prévus

pour être compatibles avec l'IDL (Interface Definition

Language) de CORBA (Common Object Request

Broker Architecture), avec des extensions pour les

relations et autres concepts des bases de données.

13

13

Le langage de définition d'objets: ODL

◼ ODL est conçu pour prendre en charge les constructions

sémantiques du modèle objet de l'ODMG.

◼ Il est indépendant de tout langage de programmation.

Il sert principalement à créer des spécifications d'objets

• autrement dit des classes et des interfaces.

◼ En conséquence, ODL n'est pas un langage de

programmation à part entière. Un utilisateur peut définir

un schéma de base de données en ODL indépendamment

langage de programmation, puis utiliser une

de tout

liaison de langage (language binding) pour spécifier

comment

les constructions ODL correspondront aux

constructions d'un langage spécifique comme C++,

Smalltalk ou Java.

14

14

7

Le langage de définition d'objets: ODL

◼ On peut considérer la notation graphique d’ODL, comme

une variante des diagrammes EER, avec la notion

supplémentaire d'héritage d'interface mais à laquelle

manquent plusieurs concepts EER,

tels les catégories

(types union) et les attributs de relations.

Interface

Personne_IF

Classe

PERSONNE

Relations

1 :1

1 :N

M :N

15

Héritage

Héritage d’interface

(est-un) utilisant « : »

Héritage de classe

utilisant extends

15

Le langage de définition d'objets: ODL

◼ La figure ci-dessous montre un schéma objet possible

pour une partie de la base de données UNIVERSITE.

PERSONNE

a_etudiants_dominante

DEPARTEMENT

Propose

a_professeurs

Propose_par

COURS

a-sessions

etudiants

SESSION

de_cours

Travaille_dans

PROFESSEUR

ETUDIANT

a_en_dominante

sessions_terminees

inscrit_a

conseiller

comite

EtudDip

conseille

dans_comite_de

16

Etudiants_inscrits

SESSION_COURANTE

16

8

Le langage de définition d'objets: ODL

◼ Le listing suivant présente l’ensemble de définitions de

la base de données

classes possibles en ODL pour

UNIVERSITE.

◼ Il existe généralement plusieurs façons de traduire un

diagramme de schéma objet (ou un diagramme de schéma

EER)

la

représentation la plus simple.

classes ODL. Nous

choisi

avons

en

◼ Les types d'entité sont

traduits en classes ODL et

l'héritage est obtenu au moyen d'extensions.

◼ Mais il n'y a aucun moyen direct de traduire les catégories

(types union) ou de réaliser l'héritage multiple.

17

17

Le langage de définition d'objets: ODL

◼ Les classes Personne, Professeur, Etudiant, et EtudDip ont

professeurs,

extensions

personnes,

respectivement

etudiants et etudiants_dip.

les

◼ Professeur et Etudiant dérivent toutes deux de Personne, et

EtudDip étend Etudiant. De ce fait, on peut forcer la collection

etudiants (et la collection professeurs) à être à tout moment un

sous-ensemble de la collection personnes. De même,

la

collection etudiants_dip sera un sous-ensemble de etudiants.

◼ En même temps, les objets individuels de type Etudiant et

Professeur hériteront des propriétés (attributs et relations) et

des opérations de Personne, et les objets de type EtudDip

hériteront de celles de Etudiant.

18

18

9

Le langage de définition d'objets: ODL

◼ class Personne

(

extent personnes

key

noss )

PNom {string prenom, string

{ attribute struct

deuxiemeprenom, string nomFamille}

attribute string

attribute date

attribute enum Genre {M,F}

attribute struct Adresse {short no, string rue, short noappt,

nom;

noss;

datenaissance;

sexe ;

string ville, string dep, short codepost} adresse;

short

} ;

age() ;

19

19

Le langage de définition d'objets: ODL

◼ class Professeur extends Personne (extent professeurs)

{ attribute string

attribute float

attribute string

attribute string

relationship

relationship

relationship

inverse

inverse

inverse

rang ;

salaire;

bureau;

tel;

Departement travaille_dans

Departement :: a_professeurs;

set<EtudDip>

conseille

EtudDip :: conseiller;

set<EtudDip>

EtudDip :: comite;

augmenter(in float augmentation);

promouvoir(in string nouveau_rang) ;

dans_comite_de

void

void

} ;

20

20

10

Le langage de définition d'objets: ODL

◼ class Etudiant extends Personne (extent etudiants);

{ attribute

attribute

relationship

inverse

relationship

inverse

relationship

inverse

annee;

string

Departement en_sous_dominante;

Departement a_en_dominante

Departement :: a_etudiants_dominante;

set<Note>

Note :: etudiants;

set<Session_Courante> inscrits_a

SessionCourante :: etudiants_inscrits;

sessions_terminees

void changer_dominante(in string dnom) raises (dnom_not_valid);

MP() ;

float

sinscrire(in short nosession) raises (session_not_valid);

void

void note_attribuee(in short nosession ; in ValeursNotes note)

raises (Session_not_valid, note_not_valid); } ;

21

21

Le langage de définition d'objets: ODL

◼ class EtudiantDip extends Etudiant

etudiants_dip)

( extent

{ attribute

relationship

inverse

relationship

set<Diplome> diplomes;

conseiller

Professeur

Professeur:: conseille;

comite

set<Professeur>

void

void

} ;

22

Professeur :: dans_comite_de;

inverse

attribuer_conseiller(in string nom; in string prenom)

raises (professeur_not_valid);

attribuer_comite(in string nom; in string prenom)

raises (professeur_not_valid);

22

11

Le langage de définition d'objets: ODL

◼ Les

classes

et

SessionCourante sont de simples transpositions des types

d'entités correspondants.

Departement,

Session

Cours,

◼ class Cours

( extent cours key nocours )

{ attribute

attribute

attribute

relationship

string

string

string

set<Session> a_sessions

Cnom;

nocours;

description;

relationship

inverse

Session :: de_cours;

Departement propose_par

inverse

Departement:: propose;

23

} ;

23

Le langage de définition d'objets: ODL

◼ class Departement (extent departements key dnom)

dnom;

dtel;

dbureau;

fac;

pdt;

string

string

string

string

Professeur

set<Professeur>

Professeur :: travaille_dans;

set<Etudiant>

Etudiant :: a_en_dominante;

set<Cours> propose

Cours :: propose_par;

a_professeurs

a_etudiants_dominante

{ attribute

attribute

attribute

attribute

attribute

relationship

inverse

relationship

inverse

relationship

inverse

} ;

24

24

12

Le langage de définition d'objets: ODL

◼ class Session (

extent

sessions)

{ attribute

attribute

attribute enum trimestre {printemps, ete, automne, hiver} trim;

relationship

short nosession;

string an;

set<Note>

etudiants

inverse

Note:: session;

relationship Cours

de_cours

inverse

Cours:: a_sessions;

} ;

◼ class SessionCourante extends Session (extent sessions_courantes )

{ relationship

inverse

void

set<Etudiant>

Etudiant:: inscrit_a;

inscrire_etudiant (in string noss)

etudiants_inscrits

raises (etudiant_not-valid, session_pleine);

} ;

25

25

Le langage de définition d'objets: ODL

◼ La

classe Note nécessite quelques

explications. Elle

correspond en effet à la relation M:N qui existe entre les

classes Etudiant et Session.

◼ La raison pour laquelle on a créé une classe séparée (au lieu

d'une paire de relations inverses) est qu'elle comprend un

attribut de relation.

◼ En conséquence, la relation M:N est associée à la classe Note,

et il existe une paire de relations 1:N, l'une entre Etudiant et

Note et l'autre entre Session et Note. Ces deux relations sont

représentées par les propriétés suivantes: sessions_terminees

de Etudiant, session et etudiant de Note, et etudiants de

Session.

26

26

13

Le langage de définition d'objets: ODL

◼ class Note

(extent Notes)

{ attribute

enum ValeursNotes

{A, B, C, D, F, I, P} note;

relationship Session

inverse

relationship Etudiant

session

Session :: etudiants;

etudiant

inverse Etudiant :: sessions_terminees;

} ;

27

27

Le langage de définition d'objets: ODL

◼ Enfin,

la classe Diplome sert à représenter

l'attribut

composite multivalué diplomes de EtudDip.

◼ class Diplome

{ attribute

attribute

attribute

} ;

string

string

string

fac;

diplome;

an;

28

28

14

Héritage d'interface

◼ L'exemple précédent ne contenait aucune interface mais

seulement des classes.

◼ Prenons l’exemple du schéma d'une base de données qui

stocke des objets géométriques pour illustrer les interfaces

et l'héritage d'interface (ou de comportement).

ObjectGeometrique

Rectangle

Triangle

Cercle

29

29

Héritage d'interface

◼ On spécifie une

interface ObjetGeometrique,

avec des

opérations pour calculer le périmètre et la surface d'un objet, ainsi

que des opérations pour translater (déplacer) et faireTourner un

objet.

◼ interface ObjetGeometrique

{ attribute enum Forme {Rectangle,Triangle,Cercle,...} forme;

attribute struct Point {short x, short y} point_de_reference;

float

float

void

perimetre();

aire();

translater(in short x_translation,

in short y_translation);

faire_tourner(in float angle_de_rotation);

30

void

} ;

30

15

Héritage d'interface

◼ Plusieurs classes (Rectangle, Triangle, Cercle,

etc.) héritent de l'interface ObjetGeometrique.

◼ Comme ObjetGeometrique est une interface, elle

n'est pas instanciable - autrement dit, elle ne permet

pas de créer directement des objets.

◼ Mais on peut créer des objets de type Rectangle,

Triangle, Cercle...

◼ Ces objets héritent de toutes les opérations de

l'interface ObjetGeometrique.

31

Héritage d'interface

◼ class Rectangle: ObjetGeometrique ( extent rectangles)

{ attribute struct Point {short x, short y} point_de_reference;

attribute short

attribute short hauteur;

attribute float

longueur;

angle_orientation; } ;

◼ class Triangle: ObjetGeometrique ( extent triangles)

{ attribute struct Point {short x, short y} point_de_reference;

attribute short cote_1 ;

attribute short cote_2 ;

attribute float

attribute float angle_orientation; } ;

cote1_cote2_angle;

◼ class Circle : ObjetGeometrique ( extent circles )

{ attribute struct Point {short x, short y} point_de_reference;

attribute short

rayon;

} ;

32

31

32

16

Héritage d'interface

◼ Notez que, dans l'héritage d'interface, les opérations sont

héritées, mais pas les propriétés (attributs, relations).

◼ En conséquence, si une propriété est nécessaire dans une

classe qui hérite, elle doit être répétée dans la définition

de

l'attribut

cette

point_de_reference.

comme

classe,

pour

◼ Remarquez que les opérations héritées peuvent avoir des

implémentations différentes dans chaque classe. Par

exemple, les implémentations des opérations surface et

perimetre seront différentes pour les objets Rectangle,

Triangle et Cercle.

33

33

Héritage d'interface

◼ Une classe peut hériter de plusieurs interfaces, de

même qu'une interface peut hériter de plusieurs

interfaces.

◼ Mais

avec EXTENDS (héritage de

classe),

l'héritage multiple est interdit.

◼ Une classe ne peut donc hériter via EXTENDS que

d'une seule autre classe (et hériter en plus de zéro

ou plusieurs interfaces).

34

34

17

Plan

◼Préambule

◼Le modèle objet de l'ODMG

◼Objets et littéraux

◼Interfaces du modèle objet de l'ODMG

◼Interfaces, classes et héritage

◼Le langage de définition d'objets ODL

◼Le langage de requête objet: OQL

35

35

Le langage de requête objet: OQL

◼ OQL (Object Query Language) est

le langage de

requête proposé pour le modèle objet de l'ODMG.

◼ Il est conçu pour collaborer étroitement avec les

langages de programmation pour lesquels une liaison

ODMG est définie, par exemple C++, Smalltalk et Java.

◼ Une requête OQL encapsulée dans un de ces langages

peut retourner des objets qui correspondent au langage

utilisé.

◼ En outre, il est possible d'écrire dans le langage en

question les implémentations des opérations des classes

d'un schéma ODMG.

36

36

18

Le langage de requête objet: OQL

◼ La syntaxe des requêtes OQL est semblable à celle

de SQL, le langage de requête standard des bases

de données relationnelles, avec des fonctionnalités

supplémentaires pour les concepts ODMG (identité

des objets, objets complexes, opérations, héritage,

polymorphisme et relations).

◼ Les exemples destinés à illustrer les requêtes OQL

tirés du schéma de la base de données

sont

UNIVERSITE.

37

37

Schéma conceptuel EER de la BD UNIVERSITE

NoSS

DateNaiss

Sexe

NoRue

Rue

NoApt

Ville

Departement

Prenom

2e

Prenom

Nom

Famille

Nom

PBureau

Rang

Salaire

PPhone

PROFESSEUR

PERSONNE

d

Adresse

Code Post

Niveau

ETUDIANT

Diplome

Annee

Diplomes

Niveau = 5

ETUD_DIP

M

INSCRIT

N

Note

M

DOSSIER

N

N

SOUS

DOMINANTE

1

SESSION_COURANTE

Trim = TrimCour

et

Annee = AnCour

N

DOMINANTE

1

1

Faculte

RESP_RECH

N

M

COMITE

N

N

BENEF

M



1

DR

N

NoSub

Titre

SUBVENTION

Admin

DateD

Debut

Temps

Fin

1

PDT

M

1

APPARTIENT

N

ENSEIGNANT_CHERCHEUR

1

ENSEIGNE

N

FACULTE

FD

N

1

DEPARTEMENT

FNom

Doyen

FBureau

DNom

DPhone

Bureau

38

SESSION

N

1

CS

N

COURS

1

DC

NoS

Annee

Trim

NoC

CNom

CDesc

38

19

Requêtes OQL simples

◼ La syntaxe OQL de base est une structure select …

from … where … comme en SQL.

◼ Par exemple, écrire la requête qui extrait les noms

les départements de la faculté «

de tous

Ingénierie » ?

◼ Q0:

SELECT d.dnom

FROM d in departements

WHERE d.fac = 'Ingénierie';

39

39

Points d'entrées dans une base de données

◼ En général, chaque requête nécessite un point d'entrée

dans la base de données, qui peut être un objet persistant

nommé quelconque.

◼ Pour de nombreuses requêtes, ce point d'entrée est le nom

de l'extension d'une classe. Le nom de l'extension est le

nom d'un objet persistant dont le type est une collection

(dans la plupart des cas un set) des objets de la classe.

◼ Si l'on regarde les noms des extensions pour la base de

nommé

données UNIVERSITE en ODL,

départements est de type set<Departement> ; personnes

est de type set<Personne> ; professeurs est de type

set<Professeur> et ainsi de suite.

l'objet

40

40

20

Variable itérateur

◼ L'emploi d'un nom d'extension - departements dans la

requête Q0 - comme point d'entrée référence une

collection persistante d'objets.

◼ Chaque fois qu'une collection est référencée dans une

requête OQL, nous devons définir une variable itérateur

• d dans la requête Q0 - qui parcourt chaque objet de la

collection.

◼ Dans de nombreux cas, comme dans cet exemple,

la

requête sélectionnera dans la collection, en fonction des

conditions spécifiées dans la clause where.

41

41

Requêtes OQL simples

◼ Dans la requête Q0, seuls les objets persistants d de la

collection de departements qui satisfont à la condition d.fac

= 'Ingénierie' sont récupérés dans le résultat de la requête.

◼ Pour chaque objet d sélectionné, la valeur de d.dnom est

retournée. En conséquence, le type du résultat de Q0 est

bag<string>, parce que le type de chaque valeur de dnom

est string (même si le résultat réel de la requête est un set

parce que dnom est un attribut de clé). En général, le résultat

d'une requête est du type bag pour select … from … et de

type set pour select … distinct … from …, comme en SQL

(l'ajout du mot clé distinct élimine les doublons) .

42

42

21

Requêtes OQL simples

◼ Pour

reprendre l'exemple Q0,

il existe trois

syntaxes possibles pour spécifier un itérateur :

◼ d in departments

◼ departements d

◼ departements as d

◼ Nous utiliserons la première syntaxe dans nos

exemples.

◼ Notez que

les deux dernières options

sont

comparables à la spécification de variables de

tuples dans une requête SQL.

43

43

Résultats des requêtes et expressions de chemin

◼ Les objets nommés qui servent de point d'entrée dans les

requêtes OQL ne sont pas limités aux noms d'extensions.

Tout objet persistant nommé, qu'il référence un objet

atomique (isolé) ou un objet collection, peut servir de

point d'entrée.

◼ Le résultat d'une requête peut généralement être de tout

type susceptible d'être exprimé dans le modèle objet de

l'ODMG.

◼ Une requête n'applique pas obligatoirement la structure

select … from … where. Dans le cas le plus simple, tout

nom persistant peut constituer une requête.

44

44

22

Résultats des requêtes et expressions de chemin

◼ Le résultat de cette requête est une référence à cet objet

persistant. Par exemple, la requête:

departments;

◼ Q1:

◼ retourne une référence à la collection de tous les objets

le type est

persistants departements, collection dont

set<Departement>.

◼ De même, si nous avons attribué (via l'opération bind) le

nom persistant csdepartement à un seul objet departement

(le département informatique), la requête:

◼ Q1a:

◼ retourne une référence à cet unique objet de type

csdepartment;

Departement.

45

45

Résultats des requêtes et expressions de chemin

◼ Une fois un point d'entrée spécifié, l'expression de

chemin permet de spécifier un chemin vers les

attributs et les objets associés.

◼ Une

de

expression

commence

habituellement par un nom d'objet persistant, ou

par la variable itérateur qui parcourt

les objets

d'une collection.

chemin

◼ Ce nom est suivi de zéro ou de plusieurs noms de

relations ou de noms d'attributs connectés par des

points.

46

46

23

Résultats des requêtes et expressions de chemin

◼ Par exemple,

les lignes suivantes sont des exemples

d'expressions de chemin, qui sont également des requêtes

valides en OQL :

csdepartment.pdt;

◼ Q2:

◼ L’expression, Q2, retourne un objet de type Professeur,

le type de l'attribut pdt de la classe

parce que c'est

Departement.

◼ C'est une référence à l'objet Professeur qui est lié à l'objet

Departement dont le nom persistant est csdepartment via

l'attribut pdt, autrement dit une référence à l'objet

Professeur

département

informatique.

président

qui

est

du

le

47

47

Résultats des requêtes et expressions de chemin

csdepartment.pdt.rang;

◼ Q2a:

◼ La seconde expression, Q2a, est similaire, excepté

qu'elle retourne le rang de cet objet Professeur

(président du département

informatique) et non la

référence à l'objet.

◼ Le type retourné par Q2a est donc string, c'est-à-dire le

type de données de l'attribut rang de la classe Professeur.

◼ Chaque expression Q2 et Q2a ne retourne qu'une seule

valeur, parce que les attributs pdt (de Department) et

rang (de Professeur) sont tous deux monovalués et sont

appliqués à un seul objet.

48

48

24

Résultats des requêtes et expressions de chemin

csdepartment.a_professeurs;

◼ Q2b:

◼ La troisième expression, Q2b, est différente: elle

retourne un objet de type set<Professeur>, même si

elle est appliquée à un unique objet, parce que c'est le

type de la relation a_professeurs de la classe

Departement.

les

objets Professeur

◼ La collection retournée contiendra des références à

tous

l'objet

departement dont le nom persistant est csdepartement

via la relation a_professeurs, autrement dit des

références à tous les objets Professeur qui travaillent

dans le département informatique.

associés

à

49

49

Résultats des requêtes et expressions de chemin

◼ Mais pour obtenir les rangs des enseignants du

département informatique, nous ne pouvons pas

écrire:

◼ Q3’: csdepartment.a_professeurs.rang;

◼ La raison en est que nous ne savons pas si l'objet

retourné serait de type set<string> ou bag<string>

(le dernier étant le plus probable, puisque plusieurs

enseignants peuvent partager le même rang). Pour

éliminer ce genre d'ambiguïté, OQL n'autorise pas

d'expressions comme Q3'.

50

50

25

Résultats des requêtes et expressions de chemin

◼ Q3a:

◼ En revanche, on doit utiliser un itérateur pour

parcourir ces collections, comme dans les requêtes

Q3a ou Q3b ci-après:

select

from f in csdepartment.a_professeurs;

select

distinct f.rang

from f in csdepartment.a_professeurs;

◼ Q3b:

f.rang

◼ Ici, Q3a retourne bag<string> (des doublons

apparaissent dans le résultat), alors que Q3b

retourne set<string> (les doublons sont éliminés

par le mot clé distinct).

51

51

Résultats des requêtes et expressions de chemin

◼ Les requêtes Q3a et Q3b illustrent toutes deux

la façon dont on peut définir dans la clause

from une variable qui opérera une itération sur

une collection restreinte spécifiée dans

la

requête.

◼ La variable f de Q3a et Q3b parcourt

les

collection

éléments

csdepartement.a_professeurs, qui est de type set

<Professeur>, et n'en extrait que les enseignants

qui sont membres du département informatique.

de

la

52

52

26

Résultats des requêtes et expressions de chemin

◼ En général, une requête OQL peut retourner un résultat

doté d'une structure complexe spécifiée dans la requête

elle-même au moyen du mot clé struct. Par exemple :

csdepartement.pdt.conseille;

◼ Q4:

◼ Ici, Q4 est une requête simple qui retourne un objet de

type set<EtudDip> (la collection d'étudiants diplômés

le président du

dont

département informatique).

le directeur de recherches est

◼ Supposons maintenant que l'on ait besoin d'une requête qui

extraie le nom et le prénom de ces étudiants, ainsi que la

liste de leurs diplômes.

53

53

Résultats des requêtes et expressions de chemin

◼ Nous pouvons écrire la requête Q4a, dans laquelle la

variable s parcourt

la collection d'étudiants diplômés

supervisés par le président, et la variable d parcourt les

diplômes de chaque étudiant s.

◼ Q4a: select struct (

nom:struct(nom_personne: s.nom.nomfamille,

prenom_personne: s.nom.prenom),

diplomes:(select struct( dip: d.diplome,

an: d.an,

fac: d.fac)

from s in csdepartement.pdt.conseille;

from d in s.diplomes)

54

54

27

Résultats des requêtes et expressions de chemin

◼ Le type du résultat de Q4a est une collection de

structs (premier niveau), dans laquelle chaque

structure a deux composants: nom et diplomes.

◼ Le composant nom est une structure de deuxième

niveau, constituée de nomfamille et prenom,

chacun étant formé d'une seule chaîne.

◼ Le composant diplomes est défini par une requête

imbriquée. C'est une collection de structures de

deuxième niveau dont les composants sont trois

chaînes: dip, an et fac.

55

55

Résultats des requêtes et expressions de chemin

◼ Notez que OQL est orthogonal en ce qui concerne la

spécification des expressions de chemin. Autrement dit,

les noms d'attributs, de relations

et d'opérations

(méthodes) sont interchangeables dans les expressions,

tant que le système de types d'OQL n'est pas compromis.

◼ Nous pouvons par exemple écrire les requêtes suivantes

pour extraire la moyenne des points de tous les étudiants

seniors se spécialisant en informatique.

est

◼ Le résultat

l'ordre décroissant des

moyennes, puis dans l'ordre croissant des noms et des

prénoms :

trié dans

56

56

28

Résultats des requêtes et expressions de chemin

◼ Q5a:

select struct(nom_personne : s.nom.nomfamille,

prenom_personne :s.nom.prenom,

mp

: s.mp)

from s in csdepartement.a_etudiants_dominante

where s.annee = 'senior'

order by mp desc, nom_personne asc, prenom_personne asc;

◼ Q5b:

select struct(nom_personne : s.nom.nomfamille,

prenom_personne : s.nom.prenom,

mp

: s.mp)

from s in etudiants

where s.en_dominante.dnom = 'Informatique'

and s.annee = 'senior'

order by mp desc, nom_personne asc, prenom_personne asc;

57

57

Résultats des requêtes et expressions de chemin

◼ Q5a utilise directement

le point d'entrée nommé

csdepartement pour localiser directement la référence au

département informatique, puis localise les étudiants via la

relation a_etudiants_dominante.

◼ Alors que Q5b recherche dans l'extension etudiants pour

le

en_dominante dans

étudiants

les

tous

localiser

département informatique.

les noms d'opérations

◼ Remarquez la façon dont les noms d'attributs, les noms de

sont

relations et

interchangeables (de manière orthogonale) dans les

expressions de

chemin : mp est une opération,

en_dominante et a_étudiants_dominante sont des relations

et annee, nom, dnom, nom et prenom sont des attributs.

(méthodes)

58

58

29

Résultats des requêtes et expressions de chemin

◼ L'implémentation de l'opération mp calcule la

moyenne des points et retourne une valeur de type

float pour chaque étudiant.

◼ La clause order by est similaire à la construction

SQL correspondante, et spécifie dans quel ordre le

résultat de la requête doit être affiché.

◼ C'est pourquoi

la collection retournée par une

requête contenant une clause order by est de type

list.

59

59

Spécification de vues avec des requêtes nommées

◼ Le mécanisme des vues en OQL s'appuie sur le

concept de requête nommée.

◼ Le mot clé define permet de spécifier l'identificateur

de la requête, qui doit être un nom unique parmi tous

les objets nommés, noms de classes, noms de

méthodes ou noms de fonctions du schéma.